SiteGround inode limits: find file growth before upgrading

A SiteGround inode warning concerns the number of filesystem entries in your account, not just their total size. Thousands of tiny cache files can approach a file-count limit while the disk-space meter still looks comfortable.

First confirm the allowance shown for your subscription and identify the directories responsible for growth. Cleaning the wrong folder can remove important mail or media without addressing the process producing new files.

Published inode limits and the account check

When checked for this article, SiteGround’s fair-use page lists these shared-hosting inode limits. The page itself carries an October 2021 update date, so verify applicability to your current or legacy subscription in the account or with support.

The policy includes files, folders, and email messages in its explanation. It also describes warnings and possible restrictions for excessive resource use. Ask support what your warning means operationally and when any restriction takes effect; do not infer an automatic deletion policy.

Locate growth before deleting

Record the current count and compare it with an earlier reading. Request a directory-level breakdown from SiteGround if the panel does not expose enough detail. Check all websites and related storage within the allowance, not only the domain that first displayed a warning.

Candidate locations include caches, image variants, abandoned staging copies, logs, backup work directories, and mail stored in the account. These are places to inspect, not proof of the cause. A site that uses external email should not start by deleting mail folders it does not understand.

Compare file creation times with plugin changes or scheduled jobs. If a cache regenerates thousands of files every hour, deleting it once provides temporary headroom while leaving the growth mechanism intact.

Clean through the tool that owns the files

Use the relevant plugin’s cache purge or retention settings where possible. Check that backup archives have verified independent copies before removing local ones. Confirm that an old staging site is no longer needed and that its directory does not contain live uploads.

Avoid bulk deletion of “unused” images solely because they are unattached in the media library. Themes, builders, custom fields, and external pages may still reference them. Preserve a recovery copy and verify the business-critical pages after cleanup.

If image variants are responsible, review the registered sizes and plugin behavior with a developer. Regenerating thumbnails without a cleanup strategy can temporarily increase file count further.

Choose between cleanup, offload, and more capacity

Cleanup fits obsolete or runaway files. More capacity fits a legitimate working set that exceeds the current allowance. Media offload can help when uploads dominate, but only if the integration’s local-retention behavior actually removes the intended local copies after verification.

Our WordPress R2 guide explains the storage, URL, and rollback work involved. Offloading public media does not reduce unrelated cache, mail, or plugin files.

If considering a plan change, compare the new inode allowance with the growth rate and renewal cost. Doubling headroom for a runaway process may buy only a short delay.

Watch the count after the fix

Check the count after a normal cache cycle, scheduled backup, and publishing session. Account statistics may update on a delay, so ask when the panel refreshes before assuming cleanup failed. Keep the before-and-after counts and the responsible directory in your support record. A stable growth rate is better evidence of a lasting fix than a single lower reading.