WPFIX STACK — home
WordPress Errors

Common WordPress Errors and How to Fix Them

A field guide to common WordPress errors: what each one means, how to tell them apart, and a link to the exact fix for each.

By Published Updated 5 min read

A frustrated man sits at his home office desk holding his head while looking at his laptop screen.
Photo by Gustavo Fring on Pexels

If your site is currently broken, the fastest way to the right fix is to identify exactly what you're seeing: a blank white screen means a PHP fatal error; "There has been a critical error" means WordPress caught the fatal and is showing you its own error page; a 404 on some or all pages means the rewrite rules aren't matching; a login loop that keeps bouncing you back to wp-login.php means something (often Cloudflare) is stripping your auth cookie; and "Briefly unavailable for scheduled maintenance" means an update didn't finish cleanly. The rest of this guide breaks down what causes each one and links to the full fix.

White screen vs. critical error — these are the same underlying problem

Both are caused by a PHP fatal error — a plugin, theme, or core file throwing an error WordPress can't recover from mid-request. The difference is just whether WP_DEBUG and friendly-error-page handling are catching it:

  • Blank white screen ("The White Screen of Death") — the fatal error happens, but nothing is configured to catch and display it. You get an empty page and no clue what broke.
  • "There has been a critical error on this website" — WordPress's built-in fatal error handler (added in WordPress 5.2 (opens in a new tab)) caught the same kind of error and is showing you a generic message instead of a blank page. Log in as admin and you'll usually see more detail; check your email too, since WordPress emails admins on a new fatal error by default.

Either way, the fix is the same: get to the PHP error log (or turn on WP_DEBUG_LOG (opens in a new tab), which writes to wp-content/debug.log when WP_DEBUG is also enabled), find the exact file and line the fatal is coming from, and deactivate or fix whatever plugin/theme it points to. If the error started right after a PHP version upgrade, a plugin that wasn't ready for the new version is the likely cause; see the dedicated PHP 8.1 guide below.

404 errors — check whether it's every page or just some

  • Every page 404s, including the homepage — the rewrite rules themselves aren't being read, almost always right after changing the permalink structure in Settings → Permalinks. This is a server config issue: Apache needs AllowOverride All and a working .htaccess, Nginx needs the try_files rule regenerated manually since Nginx has no .htaccess equivalent at all (opens in a new tab).
  • Only some pages 404 — specifically products, portfolio items, or another custom post type — this is narrower: either the custom post type's rewrite slug collides with a page slug, or the permalink flush didn't pick up the CPT's rules. Different fix from the site-wide case above.

Telling these two apart before you start is the single biggest time-saver — the site-wide fix (server config) won't do anything for a CPT-only 404, and vice versa.

Login loops — usually Cloudflare, not WordPress itself

If wp-admin keeps bouncing you back to the login screen after you enter correct credentials, the cookie WordPress sets to keep you logged in isn't surviving the round trip. On sites behind Cloudflare, this is almost always one of: Cloudflare's SSL/TLS mode mismatched with the origin certificate, Bot Fight Mode or a WAF rule flagging wp-login.php requests, or a security plugin's own 2FA/Turnstile step conflicting with a caching layer. Confirm you're behind Cloudflare and check the SSL/TLS mode first — it's the most common root cause and takes 30 seconds to check.

Stuck in maintenance mode — an update didn't finish

WordPress puts the site into maintenance mode automatically during core, plugin, or theme updates by creating a .maintenance file in the WordPress root, then removes it when the update finishes. If the update process gets interrupted — a timeout, a lost connection, hitting a PHP memory or execution-time limit mid-update — that file can be left behind, and visitors see "Briefly unavailable for scheduled maintenance". WordPress itself stops honoring a leftover .maintenance file after 10 minutes (opens in a new tab), so if the message persists longer than that, also check whether a page cache or CDN is still serving a cached copy of it. Deleting the file resolves the symptom, but check whether the update actually completed first so you're not just clearing the flag on a half-finished update.

Common WordPress errors (and where to fix them)

FAQ

What's the difference between a white screen and "There has been a critical error"?

They're caused by the same thing — a PHP fatal error — but WordPress 5.2+ added a fatal error handler that catches the crash and shows a readable message instead of leaving you with a blank page. If you're still seeing a true blank white screen on a modern WordPress install, the fatal is likely happening early enough (or is severe enough) that even the error handler can't catch it — check your host's raw PHP error log instead of relying on the on-screen message.

How do I find out what's actually causing a WordPress error?

Turn on WP_DEBUG_LOG in wp-config.php (or check your host's PHP error log directly, which usually doesn't require touching code) and reproduce the error — the log will name the exact file, line, and plugin or theme involved. Guessing and deactivating plugins one at a time works but is much slower than reading the log first.

Should I fix the error live, or take the site offline first?

For anything beyond a quick config check, work from a staging copy or at minimum have a fresh backup ready before you start — several of these fixes involve editing server config or switching PHP versions, and it's much less stressful to test a fix somewhere that isn't your live site under time pressure.

Stefan Nistor

Founder, WP Fix Stack

Stefan runs WP Fix Stack. Every guide checks its commands, menu paths and limits against the official documentation of WordPress, PHP, the hosting panel, Cloudflare or the plugin involved, and links those sources so you can verify them. Fixes are ordered from the least risky step, each guide ends with a way to confirm the fix and roll it back, and guides are corrected, with a new Updated date, when the documentation or the software changes.

Every guide explains the symptom, likely causes, the safest order of checks and how to confirm the fix. How we check our guides.

On this page