WordPress revisions are the saved snapshots WordPress creates every time you edit a post, and by default it keeps every one of them forever. A single article edited over a year can accumulate 50 or more revisions, each a full copy of the content stored as its own row in the database. The feature itself is useful, but the unlimited default quietly inflates your wp_posts table until queries slow down, and slower server response feeds directly into the page experience signals that affect rankings. Most site owners never connect a sluggish admin and a weak Core Web Vitals score to WordPress revisions, yet on content-heavy sites the link is direct.
This guide shows you how to limit WordPress revisions, clean out the backlog safely, and keep the database lean without losing the version history you actually need. You’ll work in wp-config.php and one optimization plugin, and the whole job takes about 30 minutes.
WordPress Revisions Bloat the Database and Slow Queries
The performance cost is indirect but real. Revisions live in the same wp_posts table as your published content, so a site with 500 posts and unlimited revisions can carry 15,000 rows where 500 would do. Every query that scans that table works harder, which raises server response time, and response time is a measured input to the Core Web Vitals metrics Google evaluates for page experience.
Autosaves add to the pile. WordPress writes an autosave draft every 60 seconds while you edit, and on a busy editorial site those accumulate alongside manual revisions. None of this breaks anything outright, which is precisely why it goes unmanaged for years until someone audits a database that has grown to several hundred megabytes of mostly duplicate text.
The fix is not to disable WordPress revisions entirely, because version history saves you the day a draft gets overwritten. The goal is a sensible cap, usually 5 to 10 revisions per post, which preserves recent history while stopping unbounded growth. That balance keeps the safety net without the storage tax, and it pairs naturally with broader WordPress database optimization work.
How to Limit WordPress Revisions in 4 Steps
Capping revisions takes a few lines of configuration and no plugin. Follow these 4 steps:
- Add a revision limit to wp-config.php – Insert
define('WP_POST_REVISIONS', 8);above the “stop editing” line. This caps every post at 8 stored revisions, deleting the oldest as new ones are created. - Lengthen the autosave interval – Add
define('AUTOSAVE_INTERVAL', 300);to write autosaves every 5 minutes instead of every 60 seconds, cutting autosave rows by 80% with no practical loss. - Confirm the limit took effect – Edit any long-standing post and check that the revisions counter stops growing past your cap. The setting applies going forward, so existing backlog still needs cleanup.
- Set per-type limits if needed – For sites where only some content needs deep history, a small filter on
wp_revisions_to_keeplets you keep more revisions on posts and fewer on pages.
Keep the cap modest rather than zero. Disabling WordPress revisions completely removes the recovery option that justifies the feature, and a limit of 8 costs almost nothing in storage while still rescuing you from an accidental overwrite. Editors who have ever pasted over a finished draft know exactly why that small recovery option earns its keep.
Clean Existing Revisions Without Breaking Anything
The config cap only controls future revisions, so the historical backlog needs a one-time purge. Never edit the database by hand on a live site for this. Use a maintenance plugin such as WP-Optimize or Advanced Database Cleaner, which delete revision rows through WordPress functions that respect table relationships, rather than raw SQL that can orphan metadata.
Back up the database before you purge, every time, with no exceptions. A revision cleanup is low risk, but a fresh export costs two minutes and turns any surprise into a restore instead of a disaster. Run the backup, run the cleanup in a single pass, then confirm your posts still display correctly across a few templates.
Schedule the cleanup to repeat. Most optimization plugins can purge revisions weekly or monthly on a timer, which stops the backlog from rebuilding between manual checks. Don’t rely on memory for this, because the one month you forget is the month a viral post collects 200 revisions. Pair that schedule with your caching plugin routine so database hygiene and front-end speed get maintained on the same cadence, and neither gets forgotten. It’s the kind of automation you set once and never think about again.
Connect a Lean Database to Faster Pages and Better Rankings
A trimmed database is one input to site speed, not the whole story, so set expectations accordingly. Cutting 14,000 revision rows won’t transform a slow theme into a fast one, but it removes a drag on every query and makes the rest of your optimization work measurable. On shared hosting, where database performance is often the real bottleneck, the effect is more noticeable than on a tuned server.
Measure before and after so you know what the cleanup bought you. Note your server response time in PageSpeed Insights before the purge, run the cleanup, then re-test after caching has rebuilt. A faster Time to First Byte is the signal that database bloat was holding you back, and it flows through to the field data Google collects for Core Web Vitals. If the number barely moves, your bottleneck is elsewhere, and that’s useful to know before you spend hours chasing the wrong fix.
Fold WordPress revisions into your routine maintenance rather than treating cleanup as a one-time event. The config cap handles the bulk automatically, the scheduled purge catches the rest, and a quarterly look at total database size confirms nothing is creeping back. Our full WordPress PageSpeed guide places this work in the wider performance stack, and the consistent pattern is that lean sites are maintained, not rescued. Keep the database tidy and you remove one of the quiet, compounding causes of slow pages that drag rankings down over time.