A five year old WordPress site is usually not running worse code than it ran on day one. It is carrying more rows. Some of those rows get read on every single page view, and nobody ever deleted them.
The part of your database that gets read on every visit
WordPress keeps settings in a table called options. Your theme writes there. So do your plugins. Some of those rows are marked to load automatically, which means WordPress pulls them all in at the start of a page request, whether that page uses them or not.
That is the part that grows. One plugin writes a little. Twenty plugins over five years write a lot. Deleting a plugin does not always take its rows with it. The plugin developer handbook page on uninstall methods, first published September 16, 2014 and last updated February 20, 2024, tells plugin authors they will want to clear out any options and settings specific to their plugin when it is uninstalled, and gives them two ways to do it. The cleanup is the author’s job. A plugin that never did it leaves its rows sitting there, still marked to load, still read on every visit.
Make WordPress Core, the development blog for WordPress itself, published a post on this on June 18, 2024, titled Options API: Disabling autoload for large options. It describes autoloading as a way to load multiple options in a single query on each page request, and says that autoloading a large amount of data that is not used hurts performance.
The 800 KB line, and where to find your own number
Here is a number you can go and check on your own site tonight.
WordPress 6.6 added a check to Site Health that flags a critical issue reading “Autoloaded options could affect performance” once the total size of your autoloaded options passes 800 KB. That is stated in the June 18, 2024 post above. The developer documentation for the method behind the check, WP_Site_Health::get_test_autoloaded_options, gives the default limit as 800,000 bytes and lists the check as arriving in version 6.6.0. That page was published July 16, 2024 and last modified August 20, 2026.
To see yours: log in, open Tools, then Site Health. If the check has fired, it names your size.
Now the limit on that number. 800 KB is a warning line somebody picked, not a measurement of how slow your site is. The same documentation says a developer can move that line with a filter. A site under 800 KB can still be slow, and a site over it may still feel fine to a customer. Treat it as a reason to look, not as a diagnosis.
Why an old site carries more of this than a new one
This is the part that explains the five years.
That June 2024 post changed a default. The setting that decides whether an option loads on every request used to default to yes. From WordPress 6.6, an option larger than 150k bytes that does not explicitly ask to be autoloaded is no longer set to autoload.
Then comes the sentence that matters for an old site. The post says no upgrade routine is planned for the change, so options added before it keep the values they were already stored with. The newer rule applies to rows as they get written. It does not go back through a table that filled up in 2021 and sort it out.
So two sites can run the identical version of WordPress today and carry very different loads. The one built last month started under the newer rule. The one built five years ago is still carrying rows that were marked to load on every visit under the old default, including rows written by plugins that were deleted years ago. Those leftovers are worth a look on their own, and so are the plugins still sitting there that nobody maintains anymore.
Revisions live in the same table as your pages
Every time you save a page, WordPress keeps the old copy.
The WordPress developer reference for wp_revisions_to_keep says in its description that by default an infinite number of revisions are kept. The function has been in WordPress since version 3.6.0. That page was published April 25, 2014 and last modified August 20, 2026.
The WordPress.org documentation article Revisions says revisions are stored in the posts table, as children of the post they belong to, with a post type of revision. It was first published February 24, 2019 and last updated May 1, 2026. It also notes there is a function to delete revisions but no screen in the admin for doing it.
The same page kills off a common worry. There is only ever a maximum of one autosave per user for any given post, and new autosaves overwrite old ones. In its own words, your tables do not grow by one row every 60 seconds. The pile is made of saves you made on purpose.
It also gives the fix. A line in wp-config.php sets WP_POST_REVISIONS to a number you pick, and old revisions past that number are deleted when the post is updated again.
Be honest about the effect, though. A service page you have edited forty times holds forty old copies, and that is real size in your database and slower backups. It is not the same as an autoloaded option, which is read on every single visit. Revisions make the database fatter. They are not being pulled in every time a customer opens your homepage.
Transients that were never cleaned out
Transients are values a plugin saves for a while so it does not have to go and fetch the same thing twice. Prices, feeds, license checks, that sort of thing.
The page on transients in the WordPress developer documentation was first published August 12, 2019 and last updated November 21, 2022. It says WordPress infrequently cleans out expired transients, and tells developers it is good practice to remove their own once they are done with them. Expired does not reliably mean gone.
How much of this is actually sitting in your database depends on your setup. The same page notes that an outside cache can hold this data instead, and that a transient can vanish before its expiration time. So this one is worth checking rather than assuming.
What to do next
In order, and none of it is urgent unless Site Health is shouting at you.
- Take a backup, and open it to confirm it really restores. Do this before anything else on this list.
- Log in, go to Tools, then Site Health. Find the autoloaded options check and write the number down.
- If it has fired, hand that number to whoever maintains the site. The June 2024 post says you can audit the site for large options that are being autoloaded by running an enhanced version of the same Site Health check, through the Performance Lab plugin from the WordPress Performance Team.
- If you edit pages often, cap revisions in wp-config.php and leave it capped.
- Do not start deleting rows out of the options table by hand. A wrong delete takes a real setting with it, and you will not know which one until something breaks.
Two honest limits. If Site Health is not raising that check, your database is probably not your problem, and a cleanup is not worth paying anyone for. Spend the money on your photos instead. And if the site is slow across the board, the usual causes sit somewhere else entirely.
If the yearly cleanup keeps coming back and you are tired of it, the other path is a site with nothing to clean out. Pages built once and served as plain files run no database read at all when a customer taps the link, which is how the website build here works.