How to Limit WordPress Post Revisions

What a revision actually is in the database

Every save in WordPress writes a new row to the posts table with the type revision, holding a full copy of that post. Autosave adds one every 60 seconds while you edit. Nothing prunes them unless you set a limit.

• Revisions live in wp_posts with post_type = 'revision', and their fields in wp_postmeta.
• A published update, a saved draft, and an autosave all create a revision.
• Default behaviour is unlimited, so a post edited forty times keeps forty full copies of its content.
• The revision screen in the editor (Revisions in the sidebar) reads those rows, which is why older copies cost nothing on page load but everything on disk.

That distinction matters on shared hosting. Revisions do not slow the front end, because your visitors never query them. They do enlarge the database, and a larger database makes every backup, export, and migration slower and heavier.

Set the limit in wp-config.php

One line controls it. Open wp-config.php in File Manager, or over SFTP, and add the constant above the comment that reads "That's all, stop editing! Happy publishing."

1. Back up the file by copying it to wp-config.php.bak before you edit.
2. Add define( 'WP_POST_REVISIONS', 5 ); on its own line, above the stop-editing comment.
3. Save the file and reload the site once to confirm it still loads.
4. Edit a post, save it several times, and watch the revision count in the editor stop at five.

You know it worked when the count stops climbing at the number you set. If the site returns a white screen after the edit, the constant was pasted inside another block or with a missing semicolon; restore the .bak file and try again.

Choose a number, not zero

The constant accepts three kinds of value, and the difference between them is whether you can undo a mistake.

A limit of three to five covers normal editing. Agencies and multi-author blogs often use ten, because a copy editor and a client reviewer can each roll a post back several times in one afternoon. Zero removes the undo button entirely, which is a steep price for a few megabytes.

Clean up the revisions already stored

A new limit applies to each post the next time it is saved. It does not purge the rows that already exist, so a site that has been running for years keeps its backlog until each post is edited. Clear it deliberately.

1. Take a database backup from cPanel, and confirm the file exists before you touch anything else.
2. Install a cleanup plugin such as WP-Sweep or WP-Optimize, or work in phpMyAdmin if you prefer SQL.
3. In phpMyAdmin, select the site database, open the SQL tab, and run DELETE FROM wp_posts WHERE post_type = 'revision'; after checking your table prefix.
4. Use the Simulate query button first. It reports how many rows would be deleted, which is the number you should expect.
5. Then delete orphaned meta rows with the same plugin, or leave them; they are small but they do accumulate. The wp_options cleanup guide covers the table that usually grows second.

Two cautions. If your prefix is not wp_, the query silently deletes nothing, which looks like success. And never run the DELETE on a database you have not backed up in the last hour, because there is no undo for a SQL delete.

Why this matters on shared hosting

Shared plans meter disk space and database size, and every backup your host takes has to copy those revision rows. A blog with 800 posts and heavy editing can carry hundreds of megabytes of revisions that no reader will ever see.

Those megabytes show up in three places: your disk quota, the size of each cPanel backup, and the time a migration takes. If a host quotes a database limit and your site sits near it, revisions are usually the first place to look and the easiest place to reclaim space.

Clearing them is also safer than deleting old media, because a revision is redundant by definition. Once you are happy with the current version of a post, its earlier copies have no reader-facing purpose.

Autosave, and the other interval worth changing

Autosave is a separate constant. AUTOSAVE_INTERVAL controls how often the editor writes a copy while you type, and it defaults to 60 seconds. On a site with several editors working at once, the browser sends a request every minute per open editor.

Setting define( 'AUTOSAVE_INTERVAL', 120 ); halves that traffic at the cost of up to two minutes of unsaved work if a laptop dies. For a single author the default is fine; for a newsroom it is worth the trade.

Do not confuse the two. AUTOSAVE_INTERVAL changes how often a draft is written. WP_POST_REVISIONS changes how many of those writes are kept. Setting only the second still generates the traffic; setting only the first still fills the table.

Check the result, and keep it checked

Two numbers tell you whether the change is working: the revision count in the editor, and the size of the database in cPanel.

1. Open a busy post, make five small edits, and confirm the revision list stops at your limit.
2. Note the database size in cPanel, then compare it a week later. It should grow far more slowly than before.
3. Run the cleanup query once or twice a year, and after any content migration, since imported databases bring their revision rows with them.

If the count keeps climbing past your limit, the constant is in the wrong place or duplicated below the stop-editing line, where WordPress ignores it. Search the file for WP_POST_REVISIONS and keep exactly one definition.

When a plugin is the better choice

The constant is enough for most sites. A plugin earns its place when you want a schedule, a log, or per-post control without editing theme code.

WP-Sweep and WP-Optimize both delete revisions and other accumulated rows, and both can run on a schedule. The wp_revisions_to_keep filter is the option for developers who need a different limit per post type, for example keeping more revisions on long articles than on product pages.

Whatever you choose, keep the constant as the floor. A plugin that stops being updated should not be the only thing standing between your database and unlimited revision growth. Hosting plans and database limits for WordPress sites are on the WordPress hosting page; if a database has already outgrown its quota, email support@webji.services and we will look at it with you, 24/7 in Hindi and English with an average first reply under 60 minutes.