WordPress HTTP Errors: Fixing Critical Errors, 503s and wp-cron

What each error usually means on WordPress

The status code tells you which part of WordPress to suspect before you open a single file.

Since WordPress 5.2, fatal error protection catches most PHP fatal errors, shows the "critical error" message to visitors, and emails the site's admin address a link to recovery mode. That email is the fastest route in, because it usually names the plugin or theme that failed and lets you log in with that one component paused.

The fix, step by step

The settings you will need

Debug logging in wp-config.php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', 0 );

Create the logs folder first and make sure the PHP user can write to it. If your host does not allow paths outside the web folder, use true and block public access to wp-content/debug.log in the server configuration.

Standard .htaccess rules for Apache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If WordPress lives in a subfolder, such as /blog/, the RewriteBase and final rule change to /blog/ and /blog/index.php. Keep your own rules, such as redirects and security headers, outside the markers, because WordPress rewrites everything between them when permalinks are saved.

The equivalent for nginx

location / {
    try_files $uri $uri/ /index.php?$args;
}

Plugin and theme failures in more depth

Most WordPress fatal errors follow an update. The usual patterns are:

• PHP version mismatch. A plugin updated to require a newer PHP version than your host runs, or your host upgraded PHP and an old plugin uses functions that no longer exist. The log line will mention an undefined function, a type error or a syntax error in a file that has not changed for years.
• Two plugins declaring the same thing. "Cannot redeclare function" or "Cannot declare class, because the name is already in use" means two plugins bundle the same library. Update both, or replace one.
• Memory exhausted. "Allowed memory size of ... bytes exhausted" names the file that happened to be running when memory ran out, which is not always the one using it. Raise WP_MEMORY_LIMIT only as far as your host's PHP limit allows, and look for the plugin doing heavy work on that page.
• Drop-ins. Files such as object-cache.php and advanced-cache.php in wp-content load before any plugin. If a caching plugin is removed but its drop-in stays, the site can fail in ways that disabling plugins does not fix. Rename the drop-in to test.
• Custom code snippets. Code pasted into functions.php or a snippets plugin is a frequent cause, because it has never been tested against later versions.

With WP-CLI you can test without touching the live settings at all. wp --skip-plugins --skip-themes option get home proves the core and database work, and wp plugin list --status=active gives you the list to reactivate afterwards.

WordPress 404 quirks

Beyond broken rewrite rules, a few WordPress behaviours produce 404s, or hide them, in ways that confuse audits:

• Slug changes. WordPress remembers old slugs for posts and redirects them, but not always for pages, categories or custom post types. Add redirects for those yourself when you rename them.
• Guessing redirects. For some missing URLs WordPress looks for a post with a similar slug and redirects there. That can send visitors to the wrong post and hide a real 404 from the audit. Check a few redirected URLs to make sure the guesses are sensible.
• Pagination past the end. /blog/page/40/ on a blog with 12 pages returns 404, which is correct. If a theme links to pages that do not exist, fix the theme's pagination.
• Custom post types and WooCommerce. After activating a plugin that adds new URL types, save permalinks once so the new rules are written.

For deciding what to do with a large list of 404s once the rules are working, including when to redirect and when to let a URL go, see the 404 Not Found guide. Redirect plugins and their conflicts are covered in fixing WordPress redirects.

Why wp-cron causes errors on busy and quiet sites

WP-Cron is not a real scheduler. On each page load WordPress checks whether any task is due and, if so, fires a background request to wp-cron.php on the same site. That design causes problems at both ends of the traffic scale.

• Busy sites and crawls. During a crawl or a traffic spike many requests arrive together, background cron requests pile up, and heavy tasks such as backups, feed imports, email queues or sitemap rebuilds compete with visitors for the same PHP workers. The result is 502s and 504s at the moments you can least afford them.
• Quiet sites. With few visitors, tasks run late or not at all, so scheduled posts miss their time and caches are not refreshed.
• Blocked loopback requests. If the server cannot request its own address, for example because of a firewall or basic authentication on a staging site, cron never runs and Site Health reports a loopback failure.

A server cron job fixes all three. In Plesk this is under Scheduled Tasks for the domain, and in cPanel under Cron Jobs; the Plesk and cPanel guide covers the panel side. A typical entry looks like this:

*/5 * * * * cd /var/www/example.co.uk/httpdocs && wp cron event run --due-now --quiet

Schedule the heaviest jobs, such as full backups, for the quietest hours rather than letting a plugin choose.

Stopping the next update breaking the site

• Update on staging first where your host provides one, and click through the key templates and checkout before updating live.
• Back up before updates, files and database together, and know how to restore without the dashboard.
• Be selective with automatic updates. Minor core and security updates are usually safe to automate; large plugin updates, especially page builders and shop plugins, deserve a check first.
• Remove plugins you do not use. Deactivated plugins still sit on the server, and every active one is another thing that can fail.
• Keep PHP current and check plugin compatibility before your host moves you to a new version.
• Keep WP-CLI available. When the dashboard is down it is the quickest way to switch plugins and themes.
• Run the HTTP Error Audit after updates, since a plugin can break one template while the homepage still looks fine.