Confirm it’s actually down.
Before anything else: down, or down for you? Put the URL into downforeveryoneorjustme.com or any “is it up” checker. Then try it from your phone on mobile data — not your wifi — and in a private browser window.
If it loads for the checker, the problem is on your side: local DNS, the office network, a VPN, a stale cache. Annoying, but invisible to your visitors — the emergency just became a nuisance. If the checker agrees it’s down, keep going.
Check the boring externals.
The most embarrassing outages have nothing to do with WordPress. Three quick lookups before touching any code:
- 01Domain expiry. Run a whois lookup on your domain. An expired domain is the most total outage there is, and the renewal warnings went to an inbox nobody reads.
- 02SSL certificate. If browsers show a security warning instead of an error page, your certificate has expired. Most hosting panels reissue one in minutes.
- 03Hosting status page and DNS. Check your host’s status page — if they’re having an incident, that’s your answer; skip to step six. And if anyone touched DNS in the last 48 hours, that change is your prime suspect.
Read the error like a map.
Whatever the browser shows you narrows the search enormously. Match the symptom:
| what you see | usually means | first move |
|---|---|---|
| White screen, nothing at all | Fatal PHP error — usually a plugin or the theme | Check email for the WordPress recovery link, then step 4 |
| 500 Internal Server Error | Server-side error — often a plugin or a broken .htaccess | Step 4; renaming .htaccess over SFTP is a fair second test |
| 502 / 503 / 504 | The server behind the site is overloaded or down | Usually the host's side — status page, then step 6 |
| Error establishing a database connection | Database credentials wrong or the database server is down | If you changed nothing, it's the host's — step 6 |
| Browser security warning | Expired or misconfigured SSL certificate | Reissue from the hosting panel (step 2) |
One shortcut worth knowing: since WordPress 5.2, many fatal errors email the site’s admin address a recovery-mode link. Search your inbox for “Your Site is Experiencing a Technical Issue” — that email names the exact plugin or theme at fault, which is the fastest diagnosis you will get today.
Ask the only question that matters: what changed?
Sites rarely fall over spontaneously. Did a plugin auto-update overnight? Did someone install something yesterday? Edit the theme? In our rescue work, the last change is the culprit in most self-inflicted outages — and updates are the most common last change.
If wp-admin is unreachable, you can still disable the suspect without touching the database, using the rename trick. Carefully:
- 01Connect to your server with SFTP or your host’s file manager and open wp-content/plugins/.
- 02Rename the suspect plugin’s folder — say, from woo-addon to woo-addon.off. Renaming the folder deactivates that one plugin. Nothing is deleted; nothing touches the database.
- 03Reload the site. If it comes back, you have your culprit: leave it off, and either roll it back to the previous version or contact its developer.
- 04No obvious suspect? Rename the whole plugins folder to plugins.off. If the site returns, rename it back — WordPress will have deactivated everything — then reactivate plugins one at a time in wp-admin until the site breaks again. The last one you touched is the offender.
- 05Theme suspected? The same rename trick in wp-content/themes forces WordPress to fall back to a default theme, if one is installed.
Restore from backup — if you trust it.
If nothing above worked, or the site is visibly damaged — defaced, malware warnings, database errors that survive a host reboot — restoring the most recent clean backup is usually the fastest route back. One click on managed setups; a files-plus-database import elsewhere.
Two catches. First, everything since that backup — orders, form entries, edits — disappears unless you deliberately merge it back; know what you’re giving up before you click. Second, the big one: a restore is only as good as the backup behind it, and mid-outage is the worst possible moment to discover yours has been quietly broken for months. Whether you can trust a backup you’ve never tested is the entire subject of our backup strategy guide. Read it on a calmer day than this one.
Your problem, or the host’s?
Call the host when the evidence points below your site: their status page shows an incident, the error is a 502/503/504, the database server is unreachable and you changed nothing, or SFTP itself won’t connect. Open the ticket with what you’ve ruled out — “not the domain, not the SSL, all plugins disabled” — and you skip the first forty minutes of script.
It’s on you (or whoever maintains the site) when the timeline says update, install or edit. The host will confirm the server is healthy, and they’ll be right. That’s not a dead end — it’s a diagnosis: back to step four, or hand it to someone who does this every day.
Make the next one quieter.
Two habits turn outages from crises into blips. First, monitoring that tells you before a customer does: one-minute uptime checks mean you hear about a 4am outage at 4:01, not in a 9am email — our Extended plan checks every minute with instant alerts, and every plan at least every five.
Second, remove the most common cause: updates with a restore point, before/after screenshots and automatic rollback catch the regression before it becomes the outage. Between those two habits sits most of the difference between sites that go down monthly and sites that don’t.