Your WordPress site is slow because one layer is doing the damage, and you probably have not found which one yet. The speed fixes people reach for first — an image plugin, a caching plugin, a theme swap — often target a layer that is not the problem. Measure, fix the slowest layer, change one thing, re-measure.

I run two sites on shared hosting and one on a VPS. The most useful thing I have learned is that a single number tells you which half of the problem to look at.

The short version

• Measure time to first byte before you install anything. It is the one number that separates server-side slowness from front-end weight.
• If TTFB is over a second on a page that is already cached, the problem is hosting, PHP or the database. No front-end trick will fix it.
• Page caching is the biggest cheap win — and the reason a site can be fast for visitors and slow for you.
• Images are usually why a page is heavy, not why it is slow to start.
• Change one thing, re-measure, then change the next. Two at once and you learn nothing.

Measure first, with one command

TTFB is how long your server takes to start answering. Run this three times against your homepage:

curl -o /dev/null -s -w "ttfb=%{time_starttransfer}s total=%{time_total}s\n" https://yourdomain.com/

On shared hosting, a cached page should answer in well under a second. A figure above 1.5 seconds on a page that is already cached means the server is struggling. Then run the same command against a static file on the same host. If the static file is fast and the homepage is slow, WordPress is doing the work. If both are slow, it is the server or the network, and the rest of this article can wait.

Two conditions: log out first, because your own admin session bypasses page caching and will always look slower; and test from elsewhere, since your ISP’s route to the host is not your visitor’s route. How to test your hosting speed properly covers that part.

Layer one: hosting and PHP

If TTFB is high on a cached page, this is where the time is going.

Check the PHP version first: Tools → Site Health → Info → Server. Anything on PHP 7.4 or older is both unsupported and slower than 8.x, and changing it is a dropdown in most control panels. Test on a staging copy if you have one, since an old plugin can break on the newer branch — but that move is worth the risk on its own.

Then look at what your plan actually allows. Shared hosting limits CPU seconds, memory and disk I/O, and when you cross a limit the host throttles you instead of showing an error. A site that is fine at 9am and crawling at 3pm is usually being throttled, not attacked. Check for resource-limit emails and a CPU usage graph in the panel — cheap hosting versus good hosting is about what those limits mean in practice.

If PHP and the limits look sane, ask support two things: whether OPcache is on, and whether the database is local.

Layer two: page caching

A page cache stores the finished HTML so PHP does not rebuild it for every visitor. Done once and properly, it removes most of the load. Done three times, it causes bugs.

• Use one layer. If your host has a built-in cache — LiteSpeed hosts, most managed WordPress plans — turn it on and skip the plugin. Stacking a host cache, a plugin cache and Cloudflare’s HTML cache is how people end up with stale pages and random logouts.
• Exclude what has to stay dynamic: /wp-admin, /wp-login.php, and any cart or checkout page. A rule that bypasses the cache when the logged-in cookie is present is what keeps the admin usable.
• Expect asymmetry. A cached site is fast for visitors and still slow for you while logged in. That is the cache working, not failing.
• Clear it after every change, or you will spend an hour debugging a fix that is already live.

If Cloudflare sits in front of the site, its default static-file cache is the safe setting for WordPress — setting up Cloudflare without breaking a small site covers where that line is.

Layer three: images and front-end weight

Images rarely cause a slow TTFB, but they cause most of the wait after the first byte and they are the easiest layer to fix.

Open the homepage and check total page weight and the largest image. A hero exported at 4000 pixels wide for a slot that renders at 1200 is the most common problem I find on small sites. Resize to the size the theme actually displays and export as WebP or AVIF.

WordPress adds loading="lazy" to images by default since 5.5, which is right everywhere except the image at the top of the page. That one should load immediately — delaying it makes the page feel slower even when the measured numbers improve. Most optimisation plugins let you exclude the first image.

Then fonts and scripts. Every web font is a separate download that blocks text from painting, so two families with four weights is four files before any content appears. If the theme loads a font you cannot see on the page, remove it. Render-blocking CSS and JS are the other half, and the honest fix is usually fewer plugins.

Layer four: plugins and the database

Every active plugin is code that runs on every request, whether or not the page uses it. The reliable way to find the expensive ones:

• Install Query Monitor on a staging copy and open a normal page. It shows the query count, the slowest queries and which plugin caused each one.
• Deactivate plugins in halves on staging, measuring TTFB after each round. You will find the culprit in a few rounds without taking the live site down.

On the database side, the measurement worth taking is autoloaded options — the rows WordPress loads on every single request. In phpMyAdmin:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options WHERE autoload = 'yes';

A few hundred kilobytes is normal. If that number is measured in megabytes, a plugin is stuffing data into the options table and every page load pays for it. Expired transients are the usual offender. Clearing expired transients is safe; deleting rows you do not recognise is not.

Last piece of this layer: WP-Cron. It is triggered by page loads, so on a low-traffic site jobs run late, or several at once on the first visit after a quiet spell — exactly when a visitor notices. A real system cron job on the host is a two-line change.

Symptom, layer, first thing to try

The order I actually work in

Speed work goes wrong when it starts at the bottom of this list. Top to bottom, stopping at the first real improvement:

1. Measure TTFB, logged out, three times, and against a static file as a control.
2. PHP version and host limits — cheapest possible fix, biggest possible jump.
3. One page cache, with the admin and login paths excluded.
4. Images and fonts — dimensions before compression, and never lazy-load the top image.
5. Plugin audit on staging with Query Monitor in hand.
6. Database hygiene — autoloaded options, expired transients, a real cron.

Now the part that saves the most time: write the before number down. Every change feels faster, especially one you spent an hour on. A number on a note is the only thing that tells you whether the caching plugin did anything at all.

Today, do one thing: run that curl command against your homepage three times, logged out, and write the three TTFB numbers down. Under a second, and your next hour belongs to images and fonts. Over one and a half seconds on a cached page, and it belongs to hosting and PHP — no plugin in the directory will change that.

You can harden wp-login.php with things WordPress and your server already give you: a long unique password per admin, XML-RPC switched off, login attempts rate-limited at the CDN or firewall, and the public user list closed. A security plugin mostly packages those same steps and adds alerting and file scanning on top. Here’s the order I do it in, with the settings and the one snippet I actually use.

The short version

• Password first. A generated 20-character-plus password on every admin account, stored in a password manager, removes most of the value of an automated login attack.
• Take away what you don’t use: XML-RPC, incoming pingbacks, and the public list of usernames.
• Rate-limit wp-login.php at the edge — CDN, WAF, or host firewall — not inside PHP.
• Add a real second factor. WordPress core has none, and I won’t pretend otherwise; that step needs either a small plugin or an identity provider in front of the login.
• Put monitoring where you’ll see it. A blocked attack you never hear about is fine. A successful one you never hear about is not.

1. Fix the accounts before you touch the login page

Login hardening does nothing if there are five admin accounts and nobody remembers what two are for. Open Users → All Users, filter by Administrator, and be honest about each one:

• Delete or downgrade anything you don’t recognise. A dormant admin account is a back door with a password you never changed.
• One admin per human. Writers and editors don’t need Administrator — Editor can publish, and it can’t install plugins.
• Change any password that’s a word, a date, or used on another site. Let the password manager generate it; you should never need it in your head.
• Check the admin email while you’re in there — password resets land in that inbox, so it has to be one you read.

If you have WP-CLI, wp user list --role=administrator --fields=ID,user_login,user_email,user_registered gives you the same list in one line, which is faster on a site you inherited.

2. Turn off the parts of the API you’re not using

WordPress exposes more than the login form. Three things get abused over and over:

• XML-RPC. One request can carry hundreds of username/password pairs — the favourite amplifier for guessing — and it’s how incoming pingbacks arrive. If you don’t publish from a desktop app, you don’t need it.
• The REST user list. /wp-json/wp/v2/users answers with your authors’ usernames, which turns “guess a password” into “guess a password for a name I now know”.
• Author archives by ID. ?author=1 redirects to the author’s archive, and the slug in the URL is the login name.

Drop this into login-hardening.php inside wp-content/mu-plugins/, creating the folder if it isn’t there. Must-use plugins load automatically — no activation, and nobody can switch them off from the admin.

<?php
/*
Plugin Name: Login Hardening
Description: Disables XML-RPC, restricts the users endpoint, stops author-ID probing.
*/

// Incoming XML-RPC (and therefore pingbacks) off.
add_filter( 'xmlrpc_enabled', '__return_false' );

// /wp-json/wp/v2/users only answers for people who can list users.
add_filter( 'rest_endpoints', function ( $endpoints ) {
    $routes = array( '/wp/v2/users', '/wp/v2/users/(?P<id>[\d]+)' );
    foreach ( $routes as $route ) {
        if ( empty( $endpoints[ $route ] ) ) {
            continue;
        }
        foreach ( $endpoints[ $route ] as $i => $handler ) {
            $endpoints[ $route ][ $i ]['permission_callback'] = function () {
                return current_user_can( 'list_users' );
            };
        }
    }
    return $endpoints;
} );

// ?author=1 stops redirecting to a login name.
add_action( 'template_redirect', function () {
    if ( is_author() && isset( $_GET['author'] ) ) {
        wp_safe_redirect( home_url(), 301 );
        exit;
    }
} );

This restricts the users endpoint rather than deleting it, because the block editor calls that route to render the author dropdown. If something else breaks afterwards — a newsletter plugin that lists authors, a mobile app — remove the specific block, not the whole file.

3. Rate-limit at the edge, not in PHP

A limiter written in PHP still boots WordPress, loads plugins, and opens a database connection for every attempt — exactly the work an attacker wants. Push the limit out to whatever sits in front of the site:

• Behind a CDN (Cloudflare and similar): a rate-limiting rule where the URI path equals /wp-login.php, a handful of requests per minute per IP, action block for an hour — or challenge, if you’d rather not hard-block shared IPs.
• No CDN: ask your host whether login rate limiting and fail2ban are already on. Most cPanel and Plesk stacks can block an IP after repeated failed logins, and the IP Blocker tool handles repeat offenders by hand.
• Apache with mod_security: a rule scoped to POST requests on wp-login.php costs nothing and never touches your theme.

Keep the threshold generous: five attempts a minute per IP stops a script and lets a person who mistyped three times through. And never block /wp-admin/ as a whole — admin-ajax.php lives there.

4. Hiding the login path is worth doing, but it isn’t a control

Moving wp-login.php to another URL cuts log noise, because generic bots only try the default path. It stops nobody who has decided to target you: they read your homepage and find the new link. Treat it as tidying, not security.

The version that is security: put a real authentication gate in front of the login. Cloudflare Access on /wp-login.php and /wp-admin/ means only the identities you list can see the form at all, and the WordPress password becomes the second lock rather than the only one. Without a CDN, the hosting panel’s “Password Protect Directories” does the same with one shared password — fine solo, wrong for a team.

Whichever you choose, test it the boring way: log out, open a private window, get back in, then confirm comments and contact forms still post.

5. What a plugin adds on top

I do run a security plugin on client sites, for concrete reasons: core has no two-factor login, no record of who tried to log in, and no way to tell you a file changed. Here’s how I split what needs code from what can be settings.

If you install one, install exactly one: two firewalls fighting over the same request is how a site locks its owner out of admin-ajax.php. And a plugin is code — update it, remove it the day you stop using it.

6. Watch the one log line that tells you it happened

Every login attempt reaches your web server before WordPress sees it, so the access log is the honest record. Look for POST requests to wp-login.php: a wall of them from one address is a guessing run, and a 200 in that column instead of a 302 means somebody got in. Compare yesterday’s count with today’s.

Whatever you set up, make sure a change leaves a trace you’ll read — a rate-limit block notification, a host alert, or a weekly glance at the log. Catching it early is the difference between changing a password and working through a full infection check. If you’re already past that point, the steps are in my write-up of cleaning a hacked site — and get a working copy before you edit files, per what to back up and how to test a restore.

Checklist

• Administrator list reviewed; unused admins deleted, writers moved to Editor
• Every admin password generated by a password manager, none reused
• Admin email is one you control and read
• login-hardening.php in mu-plugins; site and block editor still load
• Rate-limit rule on /wp-login.php at the CDN or host firewall
• Second factor added, or an access gate in front of /wp-admin/
• Login tested in a private window, plus one form that uses admin-ajax.php
• One place where failed logins and file changes will actually reach you

Do the first three today — twenty minutes, start to finish: change the admin password, add the rate-limit rule on /wp-login.php, and drop the mu-plugin in. Then log out, log back in, publish a test draft, delete it. If that works, the biggest hole on the site is closed without a new plugin.

Back up two things: the database and wp-content. Everything else on a WordPress install can be downloaded again. Back up daily if the site changes daily, keep at least one copy off the hosting account, and test a restore on a copy before you actually need one — an untested backup is a guess, not a backup.

I learned this the boring way. The one time a fix took a full day instead of ten minutes, the backup existed — it just would not restore, because nobody had ever opened it.

The short version

• Database first. Posts, pages, users, settings, plugin options, menus and widget assignments all live there.
• wp-content second. Uploads, themes, plugins, mu-plugins. Custom code lives here and cannot be re-downloaded.
• Frequency follows how much work you would redo — not a number someone told you.
• One copy must live off the server. A snapshot inside the same hosting account dies with the account.
• Schedule a restore drill. Quarterly is enough for a small site, and it takes about twenty minutes on a copy.

What actually needs to be in the backup

The database is small and changes constantly; the files are large and change rarely. Treat them separately, because that difference decides your schedule and your storage bill.

In the database, the tables that matter are wp_posts (posts, pages, revisions, and the rows that define menus), wp_postmeta (custom fields — page builders store their entire layout here, so a database-only restore brings the layout back but not the images it points to), wp_users and wp_usermeta (logins and capabilities), wp_options (site URL, active plugins, cron schedule, theme settings), and the term tables that hold categories and tags. Plugin tables use their own prefixes and are easy to forget — a shop’s orders may sit in tables a “posts only” export never touches.

In the files, wp-content/uploads is usually the bulk of it, and it is also the part people most often exclude by accident. wp-content/themes and wp-content/plugins can mostly be re-downloaded, except for the child theme you edited and the plugin you patched by hand — those are original work and belong in the backup. wp-content/mu-plugins must always be included; it loads automatically, which is exactly why malware likes to hide there. I covered that pattern in the five-minute infection check.

Two files outside wp-content are worth the extra ten seconds: wp-config.php (database name, user, password, table prefix, and the security salts — losing the salts logs every user out) and .htaccess (redirects and caching rules that a plugin or your host wrote for you). The wp-config constants are covered in the seven settings I change on every new site.

How often you should back up

Ask one question: if the site died right now, how much work would I be willing to redo? That answer is your interval. A blog that publishes twice a week does not need a database dump every hour, but it does need one before every plugin update, because that is when things actually break.

My default for a small site:

• Database: daily. It is small — usually a few megabytes — so there is no reason to be stingy.
• Files: weekly, plus a manual snapshot whenever I install something new or edit a theme file.
• Before anything risky: a manual backup with a name I will recognise, like before-woo-9-update. Updates, migrations, search-replace operations and malware cleanup all qualify.

Retention matters as much as frequency. I keep a rolling window — daily for a week, weekly for a month, one monthly kept a year — because some damage is silent. A hacked file can sit unnoticed for weeks, and by then every recent backup already contains it.

A hosting-provider snapshot is not the same as your own backup. Snapshots are fast and I use them, but they live in the same account — if the account is suspended or deleted, the snapshot goes with it. In my hacked-site recovery, the host’s copy was useful but not sufficient.

Where the backup should live

Keep three copies, on two different kinds of storage, with one of them off-site. That is the whole rule; everything else is detail.

Practically: one copy on the server for fast restores, one on your own machine, one in cloud storage you control. If the backup holds user data, encrypt it — a dump with email addresses and password hashes does not belong in a public bucket.

Two places a backup must never live: inside wp-content (a hack cleanup or a careless migration deletes that folder, and some server configurations will happily serve the archive to anyone who guesses the filename), and only in the same hosting account you are trying to protect yourself from.

There is also a boring test that catches more problems than any checklist: download a backup and open it. If pulling the file takes hours or the archive refuses to open, you do not have a backup. You have a file with a hopeful name.

Taking a backup you can actually restore

On shared hosting, use the host’s own backup tool first — it knows where the database is and it produces an archive you can download in one click. Then keep a second, independent copy through a plugin that ships to remote storage, or by hand if you have SSH access.

If you have WP-CLI, the whole job is three commands:

# 1) Database — dump every table, with DROP statements so it can overwrite cleanly
wp db export ~/backups/db-$(date +%F).sql --add-drop-table

# 2) Files — wp-content plus config, skipping caches and old archives
tar -czf ~/backups/files-$(date +%F).tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/updraft' \
  --exclude='wp-content/ai1wm-backups' \
  wp-content wp-config.php .htaccess

# 3) Pull both copies off the server
scp user@host:~/backups/*-$(date +%F).* ./backups/

Without SSH, the same result comes from cPanel’s Backup tool plus phpMyAdmin: export the database with the “Add DROP TABLE” option enabled, then zip wp-content in File Manager. It is slower, but it works, and slow beats absent.

Whatever route you take, check the excludes. The most common silent failure I have seen is a backup job that skipped wp-content/uploads to save space, so the restore brought back every post with a broken image. Back up uploads separately at a lower frequency instead.

Test the restore, not just the backup

A backup is only proven when it has been restored once. Do it on a copy — a subdomain, a spare folder, or a local install — never on the live site. Twenty minutes, once a quarter:

1. Create a clean target. New database, new directory, nothing shared with production.
2. Import the database dump and unpack the files into the new directory.
3. Point wp-config.php at the new database. If the domain differs, update the siteurl and home rows in wp_options, then run a serialised-safe search-replace so internal links stop pointing at the live domain. Do not do this with a plain text editor on a dump — serialised data breaks silently.
4. Open the site and log in. Check the homepage, one post with images, the media library, permalinks (resave them if 404s appear), and the one plugin the business depends on.
5. Write down the date and anything you had to fix. If the restore failed, you have just found out at the cheapest possible moment.

That drill is also how you discover that your backup excludes were wrong, your archive was truncated, or your plugin’s remote storage credentials expired months ago.

The checklist I actually use

• Database dumped daily, with DROP statements, all prefixed tables included.
• wp-content archived weekly, uploads and mu-plugins included.
• wp-config.php and .htaccess saved alongside it.
• No backup archives stored inside wp-content.
• At least one copy off the hosting account, encrypted if it holds user data.
• A manual snapshot before every update, migration or cleanup, with a dated name.
• A restore tested on a copy this quarter, with the result written down.

The next time you touch this site, take one manual backup first and time how long the download takes. If it is slower than you expected, or the archive will not open, you have found your real problem before it found you.

I install WordPress on a fresh domain a few times a year, and the first thirty minutes decide whether the site is easy to run or a slow pile of annoyances. These are the seven settings I change before I write a single post, in the order I change them. None of them needs a plugin, and all of them are reversible except permalinks — which is exactly why permalinks go first.

The short version

• Permalinks to /post-name/, set before any content exists.
• Time zone and admin email set to something you actually use.
• The “discourage search engines” box checked, then unchecked — and checked again after every migration.
• Comments closed on old posts, pingbacks and trackbacks off.
• File editor disabled and revisions capped in wp-config.php.

1. Permalinks: decide once, before you publish

Settings → Permalinks → Post name. A fresh install defaults to a date-based structure, which is fine for a diary and bad for everything else: the URL carries the month, the day, and no words anyone would search for.

The reason this is step one is that changing it after publishing is the only item here that breaks things: every old URL returns a 404 unless you redirect it, and every link you posted elsewhere stops pointing at the right page.

If the site is already live, change it deliberately: change the structure, then add a redirect from the old pattern. WordPress does that for slugs, not for a permalink change.

2. General: the time zone and the mailbox nobody reads

Settings → General. Three fields matter and two of them get ignored on nearly every install I look at.

• Timezone. Pick your city, not UTC. If you schedule posts, WordPress converts your publish time to UTC and back; a wrong zone means a 9am post goes out at 5pm, and you spend ten minutes convinced the scheduler is broken.
• Administration Email Address. This is where password resets, new-user notices and critical-error recovery links go. Use a mailbox on the domain that you check, not a personal address you set in 2019 and no longer open.
• Site title and tagline. The tagline is not decoration — most themes print it under the logo, and “Just another WordPress site” tells a visitor you did not finish setting up.

While you are here, set the date and time format to something unambiguous. 03/04/2026 means two different days depending on who is reading.

3. Reading: the checkbox that quietly costs you months

Settings → Reading → Search engine visibility. “Discourage search engines from indexing this site” should stay unchecked on production. On a staging copy or a site you are rebuilding, it should be checked.

The failure mode is always the same: you build on staging, launch, and forget. The site looks perfect from your browser because you are logged in and looking at it directly. Google sees a page that asks politely not to be indexed, and six weeks later you are writing forum posts about having zero impressions.

So I check it twice — once during setup, once after any DNS or host change. It takes ten seconds and it is the single most consequential checkbox in the admin.

4. Discussion: close the doors you are not watching

Settings → Discussion. Comments on a small site attract two kinds of traffic: real readers, and bots that found a 2019 post about nothing. The settings that help:

• Uncheck Allow link notifications from other blogs (pingbacks and trackbacks). They are almost entirely noise on a small site, and they are a known way to get junk anchors onto a page.
• Set Automatically close comments on posts older than 14 days. Old posts are where the spam lands, because nobody is reading the moderation queue for them.
• Tick Comment must be manually approved for first-time commenters, and untick nested comments beyond two levels deep if your theme handles them badly.

If you do not want comments at all, uncheck “Allow people to submit comments on new posts” — but do it in the same sitting, because that checkbox lives on this page and nowhere else.

5. Media: stop generating image sizes nobody will use

Settings → Media. Every upload generates several resized copies before you ever insert it. On a site that publishes screenshots and diagrams, that adds up quietly in disk space and in backup size.

My numbers: thumbnail at 300×300 cropped, medium maxed at 768, large maxed at 1200. Those cover a card, a body image, and a full-width image on the layouts I use. Anything larger I upload deliberately, and WordPress makes a “scaled” copy of very large images anyway.

Two habits that go with it: rename the file before uploading (wordpress-permalinks-settings.png, not screenshot-2026-10-23-at-11.04.12.png), because the filename becomes part of the URL and the default alt text; and compress before upload instead of relying on a plugin.

6. wp-config.php: four constants worth typing by hand

This is the only step that is not a screen in the admin. Edit wp-config.php over SFTP and add these above the line that says That’s all, stop editing:

define('DISALLOW_FILE_EDIT', true);   // no theme/plugin editor in the admin
define('WP_POST_REVISIONS', 10);      // cap revisions instead of unlimited
define('WP_DEBUG', false);            // never true on a live site
define('WP_DEBUG_LOG', false);        // no wp-content/debug.log on production

What each one buys you:

• DISALLOW_FILE_EDIT removes the editor from Appearance and Plugins. It also means a stolen admin session cannot turn into code execution by pasting PHP into a theme file. The trade-off is real: you now need SFTP to change anything in code, which is the point.
• WP_POST_REVISIONS stops WordPress storing a new row for every autosave. A long editing session on a single post can otherwise leave dozens of copies in the database forever.
• WP_DEBUG and WP_DEBUG_LOG off on production, because a debug log records file paths and errors you do not want sitting in a web-readable directory. Turn them on for an hour when chasing a fatal error, then off again — the log is what tells you why the site broke, and which log to open is a separate problem.

7. Users, plugins, and the sample content

The last pass is cleanup, and it is the pass people skip.

• Delete the sample post, the sample page, and the default comment. They are published, indexed, and linked from your menu otherwise.
• Delete Hello Dolly. Delete any plugin you cannot explain in one sentence, including the ones that came bundled with a theme.
• Create one admin account with a real display name and a password from a manager, and do not use admin as the username — it is the first guess in every brute-force script. If more than one person needs access, give them Editor, not Administrator.
• On the Plugins screen, turn on auto-updates for the plugins you trust. Core minor releases and security releases already install themselves; the plugin list is where the forgotten one lives.

If you inherited the site rather than built it, run the checks in how to check if your WordPress site is infected in 5 minutes before you touch settings — there is no point tidying a site that is already serving someone else’s links. And if yours has already been hit, the recovery sequence I wrote up in my WordPress site was hacked and serving Japanese spam covers the order to do things in.

The 15-minute checklist

Setting	Where	Value I use
Permalinks	Settings → Permalinks	Post name
Time zone	Settings → General	Your city, not UTC
Admin email	Settings → General	A mailbox you read daily
Visibility	Settings → Reading	Unchecked on live
Pingbacks	Settings → Discussion	Off
Comment ageing	Settings → Discussion	Close after 14 days
Image sizes	Settings → Media	300 / 768 / 1200
File editor	wp-config.php	DISALLOW_FILE_EDIT true
Revisions	wp-config.php	10
Debug	wp-config.php	false on production

Do this one now

If you only have two minutes, open Settings → Permalinks and set it to Post name while the site is still empty. Everything else on this list can be fixed later without breaking a link; that one cannot.

Then keep the list somewhere you will find it: the next time you stand up a staging copy, the checkbox in step three is exactly the one that gets left in the wrong position. Settings are cheap to change and expensive to forget.

A 500 error means the server accepted your request and then crashed while building the page — it is not a WordPress message, not a browser problem, and not something a cache purge will fix. The reason is written in exactly one place: the server’s error log, not the browser console. So the fastest path is always the same: note the time of the failure, open the PHP error log for that minute, and read the first fatal line.

I have chased this error on my own sites and on client sites more times than I want to admit, and the pattern never changes: people start deactivating plugins one by one. The log already says which part failed. Here is the order I use now.

The short version

• 500 = the server failed while generating the page. PHP crashed, or the web server died before PHP even ran. The browser is shown a generic page on purpose.
• The log you want is the PHP error log, or the nginx/Apache error_log if PHP never got a chance to run.
• Read the first fatal error in the time window, not the last line. One crash usually drags a dozen warnings and timeouts behind it.
• 502, 503 and 504 are different animals. Check the status code before you touch anything.
• No log entry at all usually means .htaccess, a firewall rule, wrong permissions, or a PHP handler mismatch after a version change on the host.

First, confirm which error you have

The number matters: each one points at a different layer of the stack. I have wasted an hour reading PHP logs for what was actually an nginx timeout.

Status	What it means	Where to look first
500 Internal Server Error	PHP threw a fatal error, or the web server hit a configuration problem it cannot recover from.	PHP error log, then the web server error_log.
502 Bad Gateway	The web server asked PHP-FPM for the page and got garbage or nothing back.	nginx/Apache error_log, PHP-FPM log (pool crashed, socket missing).
503 Service Unavailable	The server is deliberately refusing work: maintenance mode, overload, or the PHP pool is down.	Host status page, server load, PHP-FPM pool status.
504 Gateway Timeout	The request took longer than the proxy was willing to wait.	PHP max_execution_time, proxy timeouts, a slow external API call.

If the page shows 502 or 504, skip straight to the server logs — WordPress never finished the request, so it has nothing to say.

Where the log actually lives

It depends on who runs PHP. Three places cover almost everything I see.

1. Shared hosting (cPanel-style). The account usually has a logs directory next to public_html with a per-domain error log inside — on LiteSpeed servers it is named after the domain, like example.com.error.log. The cPanel Errors page lists recent PHP errors too, and it is the fastest way in when you only have the file manager.

2. A VPS or dedicated server you manage. The web server and PHP-FPM keep their own logs:

• nginx: /var/log/nginx/error.log
• Apache on Debian/Ubuntu: /var/log/apache2/error.log
• Apache on RHEL/AlmaLinux: /var/log/httpd/error_log
• PHP-FPM: /var/log/php-fpm/www-error.log, or /var/log/php8.x-fpm.log depending on the package

3. Inside WordPress. If you have file access, you can make WordPress keep its own log. This only catches errors that happen after WordPress has loaded, so it is a complement to the server log, not a replacement.

// wp-config.php — log PHP errors to a file instead of printing them
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // keeps errors out of the HTML
@ini_set( 'display_errors', 0 );

Then follow the file while you reload the broken page:

# shared hosting (adjust the account name and domain)
tail -f /home/USERNAME/logs/example.com.error.log

# VPS with nginx + PHP-FPM
sudo tail -n 200 /var/log/nginx/error.log
sudo tail -n 200 /var/log/php-fpm/www-error.log

The log line that answers the question

A typical PHP fatal looks like this, and every part of it is useful:

[21-Oct-2026 13:43:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function
wc_get_orders() in /home/user/public_html/wp-content/plugins/acme-tools/acme.php:42
Stack trace: #0 {main}  thrown in /home/user/public_html/wp-content/plugins/acme-tools/acme.php on line 42

Four things to pull out of it:

1. The timestamp. Compare it to the time the page broke. Logs are often in the server’s timezone or UTC, so account for the offset before deciding the entry is unrelated.
2. The severity. Fatal error and Uncaught Error stop the request. Warning and Notice usually do not, and chasing those first wastes an afternoon.
3. The path and line number. That path is usually the answer: it names the theme or plugin file that was running when the process died.
4. The message. It names the mechanism: undefined function, memory exhausted, execution time exceeded, permission denied.

A few messages come up again and again, and each one has a standard first move:

• “Allowed memory size of N bytes exhausted” — something is loading more than the limit allows. Raise memory_limit a step to confirm, then find the code or import doing it.
• “Maximum execution time exceeded” — a loop, a huge import, or a slow external request. If the same URL hangs in a browser tab, it is a page load, not a background job.
• “Call to undefined function” — a plugin calling code that is not loaded: a plugin deleted while another depends on it, or a PHP extension missing on the new server.
• “Cannot redeclare” — the same function defined twice, usually two plugins from the same codebase.

When you see dozens of warnings in the same minute, ignore them until you find the fatal. The last line in a crash window is almost never the cause.

My five-minute triage order

1. Write down the URL and the time — one line in a notes app. “It broke earlier today” is not a time.
2. Open the account error log from the panel’s file manager or the cPanel Errors page.
3. Find the fatal in that window and read the file path. If it points into a plugin, you know the culprit.
4. If the log is empty, test the three things that produce a 500 without a PHP entry: rename .htaccess to .htaccess.bak and reload (a bad rule leaves no PHP trace); check whether the host changed the PHP version overnight; check the panel’s firewall log for a blocked request.
5. If it is a plugin, rename the plugins folder through the file manager so WordPress disables everything, then put plugins back in halves. Faster than the admin screen when the admin screen also returns 500.
6. Check disk usage. A full disk or exhausted inode limit makes writes fail and pages return 500 with a log entry that looks unrelated.

When it is not your code

Some 500s start and end without you changing anything, and that is a strong signal. If several sites on the same server break in the same minute, the PHP-FPM pool or the web server went down and plugin bisecting will not help. If only one action fails — a form submission, a checkout — check the firewall log first, because a security rule update can start blocking a POST body it used to allow.

Two checks settle it fast: does a plain HTML file in the same account load, and did the failure start without a deploy? A static file that loads while every PHP page fails points at the PHP layer, not the site. And if the log is empty while the site serves pages or links you did not write, treat it as a compromise rather than an error — my five-minute infection check covers the first things to look at, and the recovery walkthrough covers what to do when you find injected files.

What I do after the fix

The fix is only half the job. The other half is making the next 500 take one minute instead of one evening:

• Keep the log path in the notes for every site — host, panel, log location, PHP version.
• Leave WP_DEBUG_LOG on for staging, and WP_DEBUG_DISPLAY off everywhere.
• Watch the size of debug.log. An unrotated debug log can fill a disk, and a full disk causes the exact 500 you were debugging.
• Update plugins one at a time on staging, not twelve at once at midnight.

If you are stuck in the middle of one right now and want a second pair of eyes, my contact page is the place to reach me. Otherwise: open your site’s error log today, before you need it. Ten minutes now saves the panic later, because you will already know where the answer lives.

You can tell whether a WordPress site is infected in about five minutes without installing anything: check five places in order — robots.txt, your sitemap, the administrator list, the plugin list, and the newest files in wp-content. If two or more of those come back with something you did not put there, treat the site as compromised and work from that assumption. The order matters because it runs from cheapest to slowest, and a single odd result is usually a false alarm while a pattern is not.

I ran exactly this sequence on my own blog after it started serving Japanese spam, and the first check was enough to confirm it. Here is the whole thing, with what each result actually means.

The short version

• robots.txt — fetch it raw. Attackers add Disallow or Sitemap lines pointing at paths and domains you never created.
• Sitemap — open /wp-sitemap.xml and look for URLs that are not your posts.
• Users — filter the list to Administrators. Note anything you did not create; delete nothing yet.
• Plugins — compare against what you remember installing. Unknown folders, missing authors, and deactivated-but-present plugins are the tells.
• Files — sort wp-content by modified date. Anything changed in the last 48 hours that you did not touch is a suspect.

Check 1: robots.txt takes ten seconds

Open https://yoursite.com/robots.txt in a browser with no cache, or fetch it from the command line. A normal WordPress install has almost nothing in it:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://yoursite.com/wp-sitemap.xml

What you are looking for is anything extra. Injected lines usually look like this:

User-agent: *
Disallow: /go/
Sitemap: https://example-spam-domain.top/sitemap.xml

A Disallow on a path you never created is the attacker hiding a doorway directory from crawlers. A Sitemap line pointing off your domain is the attacker advertising theirs. Either one is a confirmed infection — nothing legitimate writes those lines into robots.txt.

Note that the file may be generated by a plugin such as Yoast or Rank Math, or it may be a physical file on disk. If it is static, check its timestamp in your file manager as well: a modification date you cannot explain is its own signal.

Check 2: the sitemap shows what got published behind your back

Open https://yoursite.com/wp-sitemap.xml, or /sitemap_index.xml if a plugin manages it. Then open the posts sitemap itself and scan for words you would never write — brand names, a language you do not publish in, or a redirect path like /go/.

Two different things show up here, and they mean different things:

• URLs that resolve to real posts — someone published content through your dashboard. Check the post author and the revision history before deleting anything.
• URLs that 404 or redirect — the entries were injected into the sitemap rather than created as posts. That points at a modified theme file or a plugin, not at a hijacked login.

If your sitemap is clean but robots.txt carried an injected Sitemap: line, the attacker is advertising their own sitemap instead of yours. That is still an infection, and it still needs the same cleanup.

Check 3: the administrator list

In the dashboard go to Users and filter by Administrator. Count them, then look at the email domain and the username pattern of anyone you do not recognise. Attacker accounts very often use a throwaway address and a name that would look like a normal subscriber if you only glanced at it.

Do not delete the account yet. Deleting a user while the malware is still live can trigger a re-creation routine on the next page load, and you lose the only evidence of how it got in. Note the username, change your own password, and enable two-factor authentication first. If a plugin on your site records last login, check whether the suspicious account has ever actually logged in: an administrator that has never logged in was probably created by a script, which means the entry point is still open.

Check 4: plugins and themes

Open Plugins → Installed Plugins and actually read the list rather than scanning for update badges. The tells are boring, which is exactly why they get missed:

• A plugin you did not install, often with a generic name like “WP Cache Manager Pro” or unusual capitalisation.
• A plugin that is deactivated but still present. A deactivated plugin is not executed, so malware packs usually pair it with a must-use plugin that re-activates it.
• An author field that is empty, or a version number that does not match the plugin’s real release history.
• A second theme next to your active one that you never installed.

Now open wp-content/mu-plugins through your host’s file manager. Must-use plugins have no dashboard entry at all, load on every request, and cannot be deactivated from the admin. If that folder holds files you did not add, you have found the loader.

Check 5: files that changed recently

This is the slowest check and the most conclusive. Open the file manager or connect over SFTP, go to wp-content, and sort by last modified, newest first. Then look at three things.

PHP files inside uploads/. There is no legitimate reason for an uploads folder to contain a .php file. One is enough to be certain: that is a backdoor.

Core files. Files in wp-includes/ and wp-admin/ should change only when you update WordPress. If their timestamps do not line up with your last update, compare them against a fresh copy of the same version and diff the two.

Your theme’s functions.php. Attackers like it because it loads on every request and scanners tend to ignore theme files unless they recognise the payload. Look for long base64 blobs, eval(), gzinflate(), or an unexplained block of code at the very top of the file.

What the results mean

What you found	What it usually means	Next step
Injected lines in robots.txt	Confirmed infection, spam injection	Restore robots.txt, then find the loader in mu-plugins
Unknown URLs in the sitemap	Posts created through the dashboard, or an injected sitemap	Check post authors and revisions
An admin you did not create	Dashboard credentials are compromised	Change every password, enable 2FA, then remove the account
Unknown or deactivated plugin	Malware pack left behind after an earlier cleanup	Remove the folder entirely, not just deactivate it
PHP in uploads/ or a modified core file	Active backdoor	Full restore from a clean backup, then rotate keys and passwords
Only old timestamps, nothing unusual	Probably not infected	Re-run in 24 hours; the checks are cheap

A five-minute checklist you can repeat

1. Fetch /robots.txt and read every line.
2. Open the sitemap and scan for foreign URLs.
3. Count administrators against who should be there.
4. Read the plugin list and check mu-plugins.
5. Sort wp-content by modified date and look at the top ten entries.

Run it once a month, and again the moment something changes: a sudden drop in traffic, a manual action in Search Console, or a page ranking in search that you never wrote. The checks do not prevent an infection, but they shorten the gap between the infection and the cleanup — and that gap is the part that actually costs you traffic and trust.

Start with robots.txt today. It is ten seconds, and it is the single check most likely to tell you the truth on the first try. If you have already found something, the full order of operations I used is written up in my post on recovering a hacked WordPress site. If you are unsure whether a specific file is legitimate, send me the first twenty lines through the contact page and I will tell you what it does. More write-ups like this live under the WordPress category.