WordPress storage problems typically do not announce themselves until they become urgent. Storage warnings arrive when you are 90% full, not at 50%. Backup timeouts happen during the overnight job, discovered in the morning. Inode limits surface when someone tries to upload a new product image and gets an unexplained error. By the time any of these become visible, the underlying cause has been accumulating for months or years.
A storage audit conducted before the warning stage finds the leaks while they are still manageable. It identifies exactly where storage is going, which categories of files are growing fastest, which files are genuinely unused, and what the growth trajectory looks like so you can make infrastructure decisions with actual data rather than in response to an alert.
This guide provides a complete 90-day media audit methodology: what to measure, how to measure it, what the findings mean, and what to do about each category of finding. The audit takes about two hours to complete and produces a clear picture of your storage situation and the action plan for addressing it. The 90-day framing means you conduct the audit, implement changes, and measure the results within a single fiscal quarter.
Phase 1 (Days 1 to 7): Baseline measurement
The audit begins with a precise measurement of your current storage state. Do not rely on cPanel’s disk usage summary, which rounds to the nearest gigabyte and does not break down by directory type. You need specific numbers by category to understand what is actually consuming your storage.
du -sh /home/[user]/public_html/wp-content/uploads/
# Total inode count
find /home/[user]/public_html/wp-content/uploads/ -type f | wc -l
# Size by year directory
du -sh /home/[user]/public_html/wp-content/uploads/*/
Run these commands via SSH or cPanel’s Terminal. Record the output in a spreadsheet. The year-by-year breakdown reveals growth patterns — a large 2022 directory versus a small 2024 directory suggests the site had a content period that has since slowed, or that files are accumulating from a specific year’s import. These numbers are your baseline.
find uploads/ -type f -name “*.jpg” | wc -l
find uploads/ -type f -name “*.jpeg” | wc -l
find uploads/ -type f -name “*.png” | wc -l
find uploads/ -type f -name “*.webp” | wc -l
find uploads/ -type f -name “*.pdf” | wc -l
# Total size for each type
find uploads/ -name “*.jpg” -exec du -ch {} + | tail -1
Knowing the split between JPEG, PNG, WebP, and PDF reveals whether image optimization has been applied (a high WebP count suggests it has), whether legacy formats dominate (mostly JPEG with no WebP suggests optimization has not run), and whether non-image files are a significant contributor to total storage.
SELECT COUNT(*) FROM wp_posts
WHERE post_type = ‘attachment’
AND post_status = ‘inherit’;
Compare the database attachment count against the filesystem file count. If the filesystem has significantly more files than the database has attachments (multiplied by typical thumbnail count), you likely have orphaned files — images that were deleted from the media library but whose physical files were never removed. If the database has more attachments than files exist, you have broken attachment records referencing missing files.
By the end of Phase 1, you should have: total uploads directory size in GB, total file count, size breakdown by year directory, size breakdown by file type, database attachment count, and a calculated “expected file count” (DB attachments × average thumbnail sizes per attachment). Record these in a spreadsheet. These are the numbers you will compare against on Day 90.
Phase 2 (Days 8 to 21): The six categories of WordPress storage waste
Phase 2 investigates each category of storage waste systematically. Not every site has all six categories, but most sites have at least three in significant quantities. Understanding which categories are present and their approximate sizes determines the priority order for remediation.
Find images larger than 500KB in the uploads directory. On a site that has been running without an image optimization plugin, this command often returns thousands of results.
find uploads/ -type f -size +500k ( -name “*.jpg” -o -name “*.jpeg” -o -name “*.png” ) -exec du -ch {} + | tail -1
Every theme and plugin that registers custom image sizes creates those sizes for every image uploaded while active. When you switch themes, the old theme’s custom sizes remain on disk but are no longer used. Identify orphaned sizes by listing all distinct filename patterns in your uploads directory.
find uploads/ -type f -name “*-[0-9]*x[0-9]*.jpg” | sed ‘s/.*-([0-9]*x[0-9]*)..*/1/’ | sort | uniq -c | sort -rn | head -20
Unattached media are images that exist in the media library but are not referenced in any post, page, or widget. They were uploaded and either never used or forgotten after being replaced with a different image. WordPress’s built-in Media Library filter can show unattached items, or you can query the database directly.
SELECT COUNT(*), SUM(LENGTH(guid)) FROM wp_posts
WHERE post_type = ‘attachment’
AND post_parent = 0
AND post_status = ‘inherit’;
Several categories of plugin generate files in the uploads directory silently: WooCommerce generates invoice PDFs for every order. Form plugins store uploaded files in uploads subdirectories. Backup plugins may store local backup archives in uploads. Security plugins generate log files. Cache plugins may write CSS and JS files. Many of these accumulate indefinitely with no cleanup mechanism. Look for non-image subdirectories within uploads.
Sites managed by teams or content agencies frequently accumulate duplicate images: the same product photo uploaded three times with names like product-hero.jpg, product-hero-final.jpg, and product-hero-final-v2.jpg. Each duplicate generates a full set of thumbnail variants. Finding duplicates requires comparing file hashes.
find uploads/ -name “*.jpg” -not -name “*-[0-9]*x[0-9]*.*” -exec md5sum {} + | sort | awk ‘BEGIN{last=””} $1==last{print} {last=$1}’ | head -20
WordPress core registers thumbnail, medium, medium_large, and large sizes. Each active theme adds 3 to 8 more. Many plugins add additional sizes. A WordPress installation with 15 registered sizes generates 16 files per uploaded image (source plus 15 thumbnails). If your audit reveals 15 or more registered sizes, auditing which sizes are actually referenced in templates versus registered but unused is a meaningful size reduction opportunity.
Phase 3 (Days 22 to 45): Remediation by category
Phase 3 addresses each identified waste category in priority order from largest to smallest storage impact. Each category has a specific remediation approach.
Every deletion step in Phase 3 should be preceded by a verified full backup including the uploads directory. Orphaned thumbnail identification is not perfect — a thumbnail that appears orphaned may be referenced by a plugin or widget in a non-standard way. Unattached media review can miss images used via hardcoded URLs in page builders or custom fields. Make the backup, verify it restores correctly on a staging environment, then proceed with deletions.
Phase 4 (Days 46 to 90): Structural fix with FTP offloading
Phases 1 through 3 address the accumulated waste. Phase 4 implements the structural change that prevents the waste from accumulating again. Without a structural fix, the site returns to its pre-audit state within 12 to 18 months as the same patterns reassert themselves.
The structural fix is FTP offloading with automatic upload and local deletion. Once implemented, new uploads go immediately to FTP and are deleted from the hosting server. The hosting server’s uploads directory stays near-empty regardless of how many new images are uploaded. Storage growth on the hosting server effectively stops. The audit’s remediation work does not need to be repeated.
Running the FTP migration after cleanup rather than before means you transfer only your clean, optimized library to FTP storage. If you offload first and clean up second, you transfer all the waste to FTP and then have to manage deletion from the FTP server as well. Cleaning first results in a smaller, faster initial migration and a cleaner FTP library going forward.
After the initial sync completes and CDN delivery is verified, enable auto upload (new uploads go directly to FTP) and local deletion after upload (hosting server files deleted after FTP transfer confirms). This is the configuration that makes the storage growth problem self-correcting going forward.
Day 90 measurement and ongoing monitoring cadence
On Day 90, rerun the baseline measurements from Phase 1. Compare the Day 90 numbers against the Day 1 numbers. A successful audit and remediation should show the hosting server’s uploads directory reduced significantly, file count reduced substantially, and backup sizes reduced proportionally.
For ongoing monitoring, a quarterly 30-minute check is sufficient after FTP offloading is in place. Verify that the FTP server’s storage usage is growing at the expected rate (new uploads only, no orphaned accumulation), that the hosting uploads directory remains near-empty, and that backup jobs are completing within their allocated window. The detailed audit from this guide only needs to be repeated if something unexpected appears in the quarterly check.
According to WPBeginner’s guide to WordPress file structure, the uploads directory is the fastest-growing part of a WordPress installation after the first year of operation, consistently outpacing growth in other directories. This growth is why proactive auditing matters — storage management that is reactive to warnings is always more expensive than storage management that is structural.
WP FTP Media’s WordPress storage audit companion plugin implements the structural fix that makes quarterly audits a brief confirmation rather than an extended investigation — ensuring the leaks you found and fixed in this 90-day cycle stay fixed permanently.
Your storage problem grew slowly. The fix is structural, not reactive.
WP FTP Media implements the Phase 4 structural fix from this audit — offloading cleaned media to FTP storage and routing delivery through CDN so that hosting server storage growth stops permanently, backup jobs complete in minutes, and the six categories of storage waste cannot accumulate again.
This guide was an absolute lifesaver when our nonprofit's website was about to crash from storage issues. we kept getting warnings out of nowhere, and I had zero clue what was eating up all the space until this audit pinpointed the exact folders where old event photos and unused plugin files were just sitting there.
just ran through this audit last week and wow caught a bunch of old plugin thumbnails eating up space I didn't even know existed.
Finally found a guide that doesn't just say "check cPanel's rounded numbers." The directory breakdown alone saved me hours of guessing which plugins were bloating my site. Totally worth it for the clarity