WordPress Site Down: A Diagnostic Order That Finds It Fast

Q: My site shows a maintenance message that will not go away.

A failed update left a .maintenance file in the WordPress root. WordPress creates it during updates and deletes it when finished, so an interrupted update strands it. Delete the file and the site returns immediately.

Q: How do I disable WordPress plugins without dashboard access?

Rename wp-content/plugins to something else, which deactivates everything at once, then rename it back and re-enable plugins individually. With shell access, wp plugin deactivate --all is cleaner because WordPress records the state properly.

Work outward from the network, not inward from the application. Domain, DNS, server reachable, HTTP status, PHP, then plugins and themes. Most people start by disabling plugins, and roughly a third of the time the actual answer was an expired domain or a certificate that lapsed overnight.

Down is not one symptom. A white page, a critical error message, a redirect loop, and a browser DNS error have completely different causes, and the error you are looking at narrows the search enormously before you touch anything. Read it properly first — it is free information and it is the difference between five minutes and an hour.

Step one: is it actually down?
Step two: domain and DNS
Step three: the HTTP status code
Step four: the critical error
Step five: redirect loops and mixed HTTPS state
What to do afterwards
How this fits the rest of the stack
FAQ

Step one: is it actually down?

Before anything else, confirm the problem is not local to you.

Check from another network — mobile data rather than office wifi.
Check from a third-party availability checker, which tells you whether the site is down for everyone.
Check your host’s status page. If the platform is having an incident, nothing you do to the site will help.
Try an incognito window, which rules out a cached redirect or a stale service worker in your browser.

A stale browser cache is a genuinely common false alarm, particularly after an HTTPS change — a permanent redirect that got cached will keep sending you somewhere broken long after the server was fixed. Incognito bypasses it in two seconds.

Also check the exact URL. A site that works on example.com and fails on www.example.com is a DNS or redirect problem, not an application one, and that distinction saves you looking in the wrong place entirely.

Step two: domain and DNS

If the browser shows a DNS error rather than a page, the request never reached your server. Nothing in WordPress is involved.

whois example.com | grep -i expiry
dig example.com +short
dig www.example.com +short
nslookup example.com 1.1.1.1

Domain expired. Check the expiry date. This is more common than anyone admits, usually because the renewal card expired or the notice went to an old address. The symptom is a registrar parking page or NXDOMAIN.
Nameservers changed or wrong. Someone edited them, or a transfer completed and reset them.
A record points at an old server. After a migration, if the record was never updated or is still cached.
DNS provider outage. Rare, dramatic, and outside your control.

Errors like DNS_PROBE_FINISHED_NXDOMAIN say the name does not resolve at all — that is registration or nameservers, not hosting. Query an authoritative nameserver directly to see ground truth, since your local resolver may be serving a cached answer from before the change.

Step three: the HTTP status code

If DNS resolves, get the status code. It narrows the cause immediately.

curl -sSI https://example.com | head -n 12
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com

500 — server-side error. PHP fatal error, exhausted memory, or a broken .htaccess. Go to the error log.
502 or 504 — the web server could not get a response from PHP. PHP-FPM down, or a request timing out.
503 — service unavailable. Often WordPress’s own maintenance mode left behind by a failed update.
403 — permissions, or a security rule blocking the request.
Connection refused or timeout — the server is down, or a firewall is dropping traffic.
Certificate error — the certificate expired or does not cover the hostname. The server is fine; the browser is refusing to talk to it.
ERR_TOO_MANY_REDIRECTS — a redirect loop, discussed below.

The 503 case has a two-second fix worth knowing. WordPress writes a .maintenance file in the root during updates and deletes it when finished. If an update fails partway, the file stays and the site serves a maintenance page forever. Delete .maintenance and the site returns.

Step four: the critical error

There has been a critical error on this website is WordPress catching a PHP fatal error. The cause is almost always a plugin or theme, and WordPress emails the admin address with details, including a link that logs you into recovery mode.

Check that inbox first. The email names the offending plugin and file, which skips the entire elimination process.

If you cannot get the email, turn on logging and read the actual error:

// wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
// writes to wp-content/debug.log

WP_DEBUG_DISPLAY false is important on a live site — you want the error in a file, not printed to visitors, since PHP errors leak file paths and other details.

With no dashboard access, disable plugins from the filesystem:

# rename the whole directory: disables everything at once
mv wp-content/plugins wp-content/plugins-off

# or with WP-CLI, which is cleaner
wp plugin deactivate --all
wp plugin activate --exclude=suspect-plugin --all

If the site returns with plugins off, rename the directory back and re-enable them one at a time, checking after each. Tedious and reliable. WP-CLI makes it much faster where you have shell access.

For a theme fatal error, rename the active theme’s directory. WordPress falls back to a default theme automatically, which usually restores access to the dashboard.

Step five: redirect loops and mixed HTTPS state

ERR_TOO_MANY_REDIRECTS means two things are each redirecting to the other. The usual pairing is your server forcing HTTPS while a proxy or CDN is configured to talk to your origin over HTTP, so each hands the request back.

Things to check, in order:

CDN or proxy SSL mode. A flexible mode that connects to your origin over HTTP while the origin forces HTTPS produces exactly this loop. Set it to full so the connection to your origin is also encrypted.
siteurl and home in wp_options. If one says http:// and the other https://, WordPress redirects between them forever.
Multiple HTTPS-forcing plugins doing the same job at once.
.htaccess rules added by a plugin and never removed.

wp option get siteurl
wp option get home
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

You can also set these in wp-config.php with WP_SITEURL and WP_HOME constants, which override the database. That is the emergency route when the loop prevents you reaching the dashboard to fix the database values.

What to do afterwards

Once the site is back, the ten minutes that stop it happening again:

Note the cause. In writing. The next occurrence will feel unfamiliar otherwise.
Check when the domain and certificate expire. Set a calendar reminder, or enable auto-renewal.
Set up uptime monitoring that alerts you rather than a customer. External to your host, so it survives a platform incident.
Enable error logging permanently, with display off. A log that only exists during an incident is not there when you need to read it.
Take a backup. If this incident started with an update, the pre-update backup is what you wish you had.
Stage updates. A staging copy where updates run first turns a site-down event into a staging-down event.

The pattern behind most repeat incidents is an update applied straight to production with no backup and no staging. That is one habit, and changing it removes a whole category of outage.

How this fits the rest of the stack

Most of the difficulty above comes from having to reach the filesystem and the database through separate tools while the site is down and the clock is running. Managed WordPress on RunxBuild puts a file manager in the dashboard — so renaming a plugin directory or deleting a stuck .maintenance file is a click — and a database browser beside it for checking siteurl and home without a separate SQL client. Plans start at $3 a month. WordPress files on RunxBuild and WordPress database on RunxBuild cover both, and the RunxBuild hosting calculator shows the site plan, storage, and bandwidth separately when you are sizing a move.

Useful related references:

FAQ

Why is my WordPress site down?

Work outward: check whether it is down for everyone, then the domain registration and DNS, then the HTTP status code, then PHP errors, then plugins and themes. Starting at the plugin end wastes time — a meaningful share of outages turn out to be an expired domain or a lapsed certificate.

How do I fix the WordPress critical error?

Check the admin email first — WordPress sends the failing plugin and file, plus a recovery mode link. Failing that, enable WP_DEBUG_LOG with display off and read wp-content/debug.log. To regain access, rename the plugins directory or run wp plugin deactivate --all, then re-enable one at a time.

What does ERR_TOO_MANY_REDIRECTS mean on WordPress?

Two things are redirecting to each other. The most common cause is a CDN or proxy set to connect to your origin over HTTP while the origin forces HTTPS. Also check that siteurl and home in wp_options both use the same scheme, and that only one HTTPS-forcing plugin is active.

My site shows a maintenance message that will not go away.

A failed update left a .maintenance file in the WordPress root. WordPress creates it during updates and deletes it when finished, so an interrupted update strands it. Delete the file and the site returns immediately.

How do I disable WordPress plugins without dashboard access?

Rename wp-content/plugins to something else, which deactivates everything at once, then rename it back and re-enable plugins individually. With shell access, wp plugin deactivate --all is cleaner because WordPress records the state properly.