How to Recover a WordPress Site That Won't Load

Check the HTTP Status Code First

Before you touch a config file or restart a service, run one command: curl against the site and read the status code it returns. That single response tells you which half of the stack to investigate, and skipping it is the single biggest reason troubleshooting sessions go in circles.

A 5xx status means the request reached the server and something downstream broke while generating the response — PHP-FPM crashed mid-request, a plugin threw a fatal error, or Nginx could not reach the upstream socket at all. A 4xx status means the server answered but decided the request was invalid or forbidden, which usually points to a routing rule, a missing file, or a permissions issue rather than a crash. A connection timeout or a flat refusal to connect is the most serious signal: it means nothing on that port is listening at all, and you should treat this as an infrastructure problem rather than a WordPress problem — jump straight to checking whether Nginx and PHP-FPM are running rather than digging through wp-config.php.

Confirm It Is Not a DNS or Network Problem

If curl from your own machine cannot even resolve or reach the host, rule out your local network and DNS before assuming the server is down. It is common to burn twenty minutes investigating a "dead" server that is actually running fine — the failure was a stale DNS cache, a misbehaving local resolver, or an ISP-level block on your specific connection.

Try the site from a different network entirely — your phone on cellular data rather than the office Wi-Fi, or a colleague on a different ISP — and see whether it loads there. Run a basic ping and traceroute to the server's IP to confirm packets are actually reaching it and see where along the path they stop if they do not. If ping and traceroute both succeed but curl still cannot connect, that confirms the network path is fine and the problem lives on the server itself, which narrows things considerably.

If the CPU, RAM, and disk graphs are all flat at zero or the dashboard itself cannot reach the server, that points to the box being unresponsive at the infrastructure level — a provider outage, an out-of-memory kill, or a network interface issue — which is a different and more urgent problem than anything inside WordPress. If the dashboard shows the server active and reporting normal metrics, move on to checking the web server processes directly.

Verify Nginx and PHP-FPM Are Actually Running

A connection timeout or refusal almost always means one of the two processes that serve every WordPress request has stopped. Check both directly with systemctl rather than guessing from symptoms alone.

If Nginx shows failed, no request is being accepted at all, and every site on that server is down, not just this one — that is a strong clue the issue is server-wide rather than specific to a single WordPress install. If Nginx is running but PHP-FPM is not, Nginx will accept the connection and then have nowhere to send it, which typically shows up as that 502 or 504 status you saw in the first step. PHP-FPM pools crash for a small number of recurring reasons: a fatal PHP error in a plugin that took the whole pool down, the process manager hitting its configured limit on child processes under heavy traffic, or the pool being killed by the kernel's out-of-memory killer when RAM ran out. Whichever service is down, restart it and then immediately check whether it stays up — a service that starts and crashes again within seconds means something is actively causing the crash, and restarting it repeatedly will not fix that; you need the actual error, which is exactly what the logs give you next.

Check the Nginx and PHP-FPM Error Logs

The error logs contain the actual reason the site is down — everything up to this point has only told you where to look, not why. Tail both logs for the site and read the most recent entries around the time the outage started.

A PHP fatal error naming a specific plugin or theme file points you straight at what to deactivate. A line about the upstream socket timing out or being refused usually confirms the PHP-FPM pool crashed, matching what you found in the previous step. A MySQL connection error in the PHP-FPM log — "Error establishing a database connection" or a specific MySQL error number — means the database service itself is the actual root cause, not WordPress or the web server, and is worth its own dedicated fix rather than restarting Nginx repeatedly. If both logs are quiet around the time of the outage, or the entries do not explain a service crash, the next most common silent cause is running out of disk space, which is worth ruling out before assuming the problem is something more exotic in the application code.

Check Disk Space

A full disk breaks WordPress in ways that rarely leave a clear error message, so check it explicitly rather than assuming the logs would have caught it.

When a disk fills up, MySQL can silently fail to write to its tables or binary logs, which surfaces to WordPress as a database that appears to be there but rejects writes, or an admin area that half-loads and then errors out. PHP-FPM can also fail to write session files or cache data to a full disk and crash its worker processes, which is exactly the kind of "restarts, then crashes again seconds later" behavior described in the earlier section on PHP-FPM. Free up space by clearing old log files, expired backups, or leftover update packages, then restart PHP-FPM and MySQL and confirm the site loads again.

Once you have isolated the cause using this order — HTTP status, network/DNS, service status, logs, disk space — you are no longer troubleshooting blind. If the status code and logs pointed at the database specifically, the deeper fix is in the companion article on "Error Establishing a Database Connection." If everything came back healthy but the admin area was stuck showing an old state, that is covered separately in the maintenance-mode article. This triage sequence, together with the other articles in this batch covering white screen of death, memory limits, mixed content warnings, slow admin performance, and image upload errors, is meant to get you to the right specific fix fast rather than guessing at random.