5 Reasons WordPress Sites Suddenly Get Slow

“The site has gotten really slow” is the most common message we get from a new client. Not “it’s down” — slow. Pages that used to load in a second now take five, the admin is sluggish, and nobody changed anything.

Somebody always changed something. The trick is finding out what. After doing this on a lot of sites, the cause is nearly always one of these five, and we check them in this order because the early ones are the cheapest to rule out.

1. A plugin or theme update changed the workload

Auto-updates are good for security and occasionally bad for performance. A plugin update can add a new database query to every page, start loading a script on pages that never needed it, or begin calling an external API on each request.

How to check: look at the update history (Dashboard → Updates, or your host’s activity log) for anything applied around the time the slowdown started. Then use Query Monitor on a slow page — it lists every database query and HTTP call by the plugin that made it. The culprit is usually obvious: one component responsible for a disproportionate share of the time.

Red flag: a page-builder, SEO or security plugin that was updated the week the site got slow.

2. The database has quietly grown

WordPress databases accumulate. Post revisions, transients that never expire, autoloaded options from plugins that were removed years ago, WooCommerce sessions, form entries, logs from a “security” plugin that records every visit. None of it is a problem until the tables are large enough that the queries WordPress runs on every page start to take real time.

The wp_options table is the usual offender. Every page load fetches every row marked autoload, and we regularly see sites where that is 5–10 MB of serialized data per request.

How to check: the size of wp_options, and the total size of autoloaded data. A simple query in phpMyAdmin or via WP-CLI will tell you. Anything over about 1 MB of autoloaded data is worth cleaning up.

Red flag: the database is several times larger than the uploads folder would suggest, or you have never looked.

3. Caching stopped working (or never did)

Most “fast” WordPress sites are fast because a cache is answering requests instead of PHP. When that cache stops hitting — because a plugin update changed a setting, a cookie is now being set on every page, or a second caching layer was added that conflicts with the first — every visitor becomes a full PHP and database request, and the site feels like it did before the cache existed.

How to check: load a page while logged out and look at the response headers. Most caches announce themselves (x-cache: HIT, cf-cache-status, x-litespeed-cache, and so on). If you see MISS or BYPASS on every load, the cache is not doing its job. Also check that only one caching plugin is active.

Red flag: two caching plugins, or a caching plugin plus a host-level cache, with nobody sure which is in charge.

4. The server ran out of something

CPU, memory, disk, or PHP workers. A site that shares a server with other sites (most shared hosting) can be slowed by a neighbour. A site on its own VPS can outgrow the PHP-FPM worker count it was set up with, so requests queue up behind each other during busy periods and the site feels slow only sometimes.

A disk at 95% is a special case: MySQL starts failing writes, sessions cannot be saved, and the symptoms look like random errors rather than slowness.

How to check: on a VPS, top, free -m and df -h answer three of the four questions in ten seconds. PHP-FPM’s status page or its error log will tell you if the pool is hitting its max_children limit. On shared hosting, ask the host for resource usage graphs — they have them.

Red flag: the site is slow at the same times every day, which is a resource ceiling, not a code problem.

5. Traffic changed — and it isn’t customers

Bots. Scrapers, vulnerability scanners, AI crawlers, and brute-force login attempts against wp-login.php and xmlrpc.php. A modest business site can receive tens of thousands of automated requests a day, each of which bypasses the cache (because they hit login pages, search, or random query strings) and consumes PHP time.

How to check: the access log. Group requests by IP and by path for the last day. If the top entries are login attempts, xmlrpc.php, or a user agent you have never heard of, that is your traffic.

Fix: put the site behind Cloudflare (or similar) with bot protection and rate limiting on the login endpoints, disable XML-RPC if nothing uses it, and block the obviously abusive networks. This usually returns 20–40% of the server’s capacity to real visitors.

What we’d do first

If you only have an hour: check the update history (1), look at response headers for cache hits (3), and look at the access log for bot traffic (5). Those three are quick and account for most cases. The database (2) and server resources (4) take longer but are the ones that get worse on their own if ignored.

If you would rather not spend the hour, our website management service does this on a schedule, before the site gets slow. And if you want to know where your site stands today, the 27-Point Website & Infrastructure Health Checklist covers caching, database health and server resources in more detail.