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 WP 5.2) 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), find the exact file and line the fatal is coming from, and deactivate or fix whatever plugin/theme it points to. The most common single trigger we see is a PHP version upgrade that a plugin wasn't ready for — 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 it doesn't read .htaccess at all.
  • 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, 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 never gets cleaned up, and the site stays stuck showing "Briefly unavailable for scheduled maintenance" even though nothing is actually still updating. 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.