Share this post using the buttons provided below:
I got a notification from SiteGround recently that stopped me in my tracks.
My hosting account was sitting at 90% inode usage. Not disk space — inodes. And if you’ve never had to deal with this before, you might be wondering what that even means. I was in the same position the first time it happened. The difference now is that I knew exactly what to do — and I had a powerful AI assistant helping me work through it methodically.
This article covers what inodes are, why WordPress sites accumulate them silently over time, and the exact process I used to recover over 14,000 inodes across a 7-year-old WordPress installation in two days. If you’re a creative professional running your own website and you’ve received a similar warning from your host, this is for you.
A quick note before we go further: some of what follows involves SSH access, terminal commands, and direct server file management. If that sounds unfamiliar or uncomfortable, that’s completely normal — and it’s exactly the kind of task I help creative professionals navigate through my consultations. There’s a link at the bottom of this article if you’d rather have someone handle this for you.
What Are Inodes — And Why Should You Care?
Most hosting plans talk about storage in gigabytes. You get 10GB, or 20GB, or whatever the plan allows. That number measures how much data you can store.
Inodes measure something different. An inode is a count of files and folders — not their size. Every single file on your server counts as one inode, regardless of whether it’s a 2MB photograph or a 1KB text file. A folder counts as one inode too.
SiteGround’s shared hosting plans have an inode limit. On the GrowBig plan, that limit is 400,000. Hit that ceiling and your site stops working — WordPress can’t create new files, which means it can’t process uploads, write cache files, or in some cases even send emails.
The insidious thing about inodes is that you can be well within your disk space limit and still run out of them. That’s exactly what happened to me.
Why WordPress Sites Accumulate Inodes Over Time
A fresh WordPress installation uses a few thousand inodes. After several years of running a real business — adding plugins, removing plugins, uploading media, changing themes, installing WooCommerce, adding a booking system — that number grows quietly in the background.
Here’s where the accumulation happens:
Retired plugin leftovers. When you deactivate and delete a plugin through WordPress, it removes the plugin files. But it doesn’t always clean up the folders that plugin created inside your uploads directory. Slider Revolution, Elementor, WPBakery, old gallery plugins, Yoast redirects — all of these leave folders behind that continue to sit on the server doing nothing.
Orphaned thumbnails. Every image you upload to WordPress generates multiple resized versions — typically four to six thumbnail variants. When you delete an image through the Media Library, WordPress deletes the original and its database entry. But it often leaves the thumbnail variants as orphaned files on disk. On a site with years of media uploads, this adds up to thousands of files.
Language packs. This one surprised me. WordPress automatically downloads translation files for over 20 languages — Danish, Greek, Spanish, Finnish, French, Japanese, Korean, Chinese, and more — even if your site operates entirely in English and your visitors use browser-based translation. Each language pack can add hundreds of files. Across 25 language packs on a 7-year-old site, this contributed over 14,000 inodes.
Email. Each email in each inbox on your hosting account counts as one inode. Years of accumulated newsletters, notifications, and spam add up faster than you’d expect.
Old backup files. If you’ve ever used a backup plugin that stores copies locally rather than offloading them to Dropbox or Google Drive, those archives can be enormous inode consumers.
How I Found the Problem — And How Claude Helped
When the 90% warning arrived, I opened a conversation with Claude and worked through the entire audit systematically over two days.
What I want to be honest about here is that I’m not a developer. I’m a web designer and fine art photographer with an IT background — comfortable with systems, but not someone who writes terminal commands from memory. Claude acted as the thinking partner and technical navigator throughout this process. It explained what each command would do before I ran it, flagged things that looked suspicious, and helped me make decisions about what was safe to delete versus what needed more investigation.
That kind of AI-assisted technical work is something I now help my own clients access through my consultations. You don’t need to understand every line of a terminal command to use one safely — you need the right guidance and the confidence to act on it.
The audit process worked like this: connect to the server via SSH, run a series of commands that show inode counts per folder from the top down, then drill into whatever folder is the biggest contributor. Think of it like peeling an onion — each layer reveals where the next problem lives.
On juliusjooste.com, the breakdown looked like this when we started:
- wp-admin: 612 inodes
- wp-includes: 3,290 inodes
- wp-content: 91,391 inodes
Everything was in wp-content. Drilling further revealed that plugins held 60,293 inodes — most of it from active, necessary plugins — and uploads held 14,338 inodes, which is where the real cleanup opportunity lived.
What We Cleaned — And What It Recovered
Retired upload folders were the first quick win. Inside the uploads directory, I found folders from Slider Revolution, Elementor, WPBakery, an old photo gallery plugin, Yoast redirect data, and a Mailchimp plugin I’d moved away from years earlier. None of these plugins were installed anymore — but their upload folders were still sitting on the server. Removing them recovered approximately 1,840 inodes in one command.
Orphaned thumbnails were the biggest single recovery. Using a plugin called Media Cleaner Pro, I ran a filesystem scan that compared every physical file in the uploads folder against the WordPress database. Anything on disk with no corresponding database entry is orphaned — either a deleted image whose thumbnails were never cleaned up, or a resized variant from a thumbnail size that no longer exists in the theme settings. The scan found and deleted 4,614 orphaned thumbnails across juliusjooste.com alone.
Language packs were the most surprising discovery. Drilling into the languages folder revealed 25 language packs — over 14,000 inodes — on a site that operates entirely in English. None of these files were serving any visitors. Browser-based translation (Google Translate, Chrome’s built-in translation) works entirely on the visitor’s end and doesn’t rely on server-side language files at all. I deleted 23 of the 25 language packs and added a code snippet to prevent WordPress from automatically re-downloading them on future updates.
A 2016 theme framework was sitting inside the uploads folder — not where theme files should ever live. It was a leftover from a theme called LuvThemes that had been removed years earlier. 957 inodes recovered.
Across two days, the total recovery was 14,335 inodes — dropping overall account usage from 89% to 85.4% and freeing up 14,000+ inodes of breathing room.
What You Should Know Before Attempting This Yourself
A few things worth being clear about before you try any of this on your own site.
Back up first. Always. Before running any terminal command that deletes files, run a full backup through UpdraftPlus or your backup plugin of choice. This is non-negotiable. Terminal commands don’t have an undo button.
Not all language files are safe to delete. If you run a multilingual site with WPML or Polylang, language packs are actively serving your visitors. Don’t touch them. This cleanup only makes sense on English-only sites where browser translation handles international visitors.
Media Cleaner Pro is worth the $39. The free version of Media Cleaner doesn’t include filesystem analysis — the feature that compares what’s on disk against what’s in the database. That’s the specific thing you need for orphaned thumbnail cleanup. It’s a one-time cost, not a subscription, and for a site with years of accumulated media it pays for itself in the first scan.
The WPCode snippet to block language pack re-downloads needs to be added to every WordPress installation on your account. Each subdomain runs its own WordPress install, so the snippet needs to be installed independently on each one.
If You’d Rather Not Do This Yourself
This kind of work sits at the intersection of web hosting, WordPress administration, and server management. It’s not complicated once you know what you’re looking at — but if you’ve never used SSH before, working through an audit like this alone can feel like navigating in the dark.
I offer consultations for exactly this kind of task. If your site is hitting inode limits, running slowly, or you’re not sure what’s accumulating on your server — I can work through it with you directly.
Or if you’re a creative professional thinking about a more comprehensive web presence overhaul, the place to start is the Readiness Quiz.
Julius Jooste is a web designer, fine art photographer, and coach working with established career creatives. He builds high-performance WordPress sites and helps creative professionals build the digital infrastructure to scale their work.
Share this post using the buttons provided below:
