Do WordPress post revisions affect SEO?

What a revision is

Each time you save or update a post, WordPress stores the previous version as a separate row in the posts table. That row has the post type revision, the status inherit, and the original post as its parent. The type is registered as not public, which is the important part for SEO: WordPress generates no permalink, no rewrite rule and no template for it.

Autosaves are a special kind of revision. The editor writes one per user per post while you type and overwrites it each time, so they do not pile up.

A crawler can only index what it can request. There is no URL that returns a revision to a logged-out visitor, so there is nothing for Google to find. The preview addresses you see while editing (?preview=true) require a logged-in user with permission to edit the post; to anyone else they show the published version or a 404.

The duplicate content worry

The concern usually runs: "WordPress keeps 40 near-identical copies of my article; won't Google see duplicates?" It will not, because duplicate content is about multiple URLs serving the same text. Copies in a database table that are never served do not count.

For the same reason, revisions do not:

• add to your indexed page count or cause index bloat;
• appear in internal search results;
• get listed in the XML sitemap, which includes published content only;
• show up in Search Console under any status.

If you do find old versions of a page in Google, the cause is elsewhere: a cached copy, a staging site that was crawled, a scraper, or a second published post with similar text.

Do they slow the site down?

This is the more reasonable question, since speed has some bearing on SEO. A site with 2,000 posts and no revision limit can easily hold 30,000 or more revision rows. That makes the posts table bigger, but front-end queries select by post type and status using database indexes, so revision rows are skipped efficiently. On normal hosting, visitors will not notice the difference between 5,000 and 50,000 revisions.

Where a very large revision count does show:

• Backups and migrations take longer and files are bigger.
• The editor loads the revision list for a post, which can be slow on posts with hundreds of versions.
• Poorly written queries in plugins that scan the whole posts table get slower as it grows.

None of that touches Googlebot's experience of your pages. If your server response time is poor, revisions are well down the list of suspects, behind caching, slow plugins and under-powered hosting. Our guide to reducing TTFB covers what to measure first.

Sensible housekeeping

Revisions are useful. They let you recover a paragraph deleted last month and see who changed what. Keep them, with a ceiling.

Set a limit in wp-config.php, above the line that says to stop editing:

define( 'WP_POST_REVISIONS', 15 );

WordPress then keeps the newest 15 for each post and removes older ones the next time that post is saved. Setting it to false switches revisions off except for one autosave, which we do not recommend on a site with more than one editor.

Clean out existing ones only if the database is uncomfortably large. With WP-CLI:

wp post delete $(wp post list --post_type=revision --format=ids) --force

On a large site run it in batches, and take a backup first. Database clean-up plugins do the same job with a button.

Do not expect an SEO result. Treat this as maintenance, like emptying spam comments. Time spent on revisions is better spent on things search engines can see: the pages themselves.

Revisions also make content updates safer. When you refresh an old post, the previous wording is one click away if the new version performs worse.