Skip to content
ThemesIonic — home
Troubleshooting

WordPress Site Not Loading: Work Down the Stack

Before touching WordPress, find out whether DNS resolves, the server answers and PHP runs. Each layer fails differently, and the browser message tells you which one to look at.

3 min read intermediate

Quick fix: read the exact message the browser shows. DNS_PROBE_FINISHED_NXDOMAIN is a name problem, ERR_CONNECTION_REFUSED is a server problem, a 500 is a PHP problem and a white page is usually a fatal error. Each points at a different layer, and the wrong layer wastes the outage.

Read the failure signal

What you see Layer that failed
DNS error, site cannot be found Domain or DNS records
Connection timed out Server unreachable, overloaded, or firewalled
Connection refused Web server not running on that port
502 / 504 gateway error PHP-FPM or the upstream process is down or too slow
500 Internal Server Error PHP fatal or a bad server directive — see the 500 guide
Blank white page PHP fatal with errors hidden — see the white screen guide
Database connection error MySQL down or wrong credentials — see the database guide
Browser warning before the page Certificate problem — see the not-secure guide

Step 1: is it just you?

Check from a second network — mobile data with Wi-Fi off is the fastest test — and from an external uptime checking service. Then flush your local DNS cache and try a private window with extensions disabled.

If the site is up for everyone else, look at:

  • a security plugin or firewall that blocked your IP after failed logins;
  • a stale DNS entry or VPN;
  • a browser extension breaking the page.

Most host firewalls allow you to release your own IP from the control panel.

Step 2: check DNS and the domain

Confirm the domain still resolves to the right address:

dig +short example.com
dig +short www.example.com

Then check the obvious ownership issues: has the domain expired, has a registrar lock or verification email gone unanswered, did the nameservers change during a host migration?

DNS changes take time to propagate. If you moved hosts recently and only some visitors are affected, the old record is still cached somewhere and it will clear on its own.

Step 3: check the server itself

Log into the hosting control panel. If the panel is also down, the answer is the host, and their status page will say so.

If the panel works, look at:

  • Resource usage. Hitting CPU, memory or process limits produces timeouts and 503s. Shared hosts throttle rather than crash.
  • Disk space. A full disk breaks MySQL writes, sessions and caches, and produces confusingly varied errors. Look at large log files first — a runaway error_log can consume a quota overnight.
  • Service status. Restart PHP-FPM or MySQL from the panel if either is stopped.

Ask the host to check the error log for the site if you cannot reach it yourself. Server-level logs sit outside the WordPress install and contain the message you actually need.

Step 4: separate WordPress from the platform

Create a file at the web root:

<?php
// health.php — delete this file once you have your answer.
phpinfo();

Open /health.php. If it renders, the server and PHP are working, and the problem is inside WordPress. If it does not, the platform is at fault and no WordPress change will help. Delete the file immediately afterwards — it exposes configuration details.

Step 5: find the fault inside WordPress

With PHP confirmed working:

  1. Turn on debug mode writing to a log rather than the screen, and reload. The fatal error names a file.
  2. If the file belongs to a plugin, disable plugins without admin access by renaming the plugin folder.
  3. If it belongs to the theme, switch to a default theme by renaming the theme folder.
  4. If memory is exhausted, raise the memory limit and then find what is consuming it.
  5. If the failure began right after a PHP version change, see site not working after a PHP update.

Step 6: intermittent failures

A site that loads sometimes is usually resource exhaustion rather than a code fault. Check whether the failures correlate with traffic peaks, a scheduled task, a backup job, or a bot crawl in the access log.

Common causes worth ruling out:

  • an uncached site with heavy queries and too few PHP workers;
  • wp-cron firing on every request during a traffic spike;
  • an external API call in a plugin with no timeout, holding workers open;
  • a backup plugin running at peak hours.

Caching removes most of it — start with how to speed up a WordPress site.

After the site is back

Write down what failed and what fixed it. Then reduce the chance of a repeat: keep off-site backups you have actually tested restoring, add uptime monitoring that alerts you before customers do, and stage updates rather than applying them to production first. If the outage followed an update, update plugins safely from now on.

Frequently asked

Usually DNS propagation, a cached record, or an IP-level block from a security plugin or firewall. Test from a mobile network and from an external checking service to see which.
No. A timeout means nothing answered within the limit, which can equally be a PHP process stuck in a loop, an exhausted worker pool, or an external API call in a plugin with no timeout set.
Only if the site is a shop losing orders and you have a clean backup. Otherwise diagnose first — restoring over an unknown cause often reintroduces the same failure an hour later.
Tagged Debugging

Related guides