Why Your WordPress Site Broke — and How to Get It Back Online
White screens, 500 errors, hacked sites and post-update breakages: the real causes behind a broken WordPress site, and the right order to fix them in.
Your site was fine yesterday. Today it’s a white screen, an error, or a page full of pills adverts. The good news: WordPress rarely breaks for mysterious reasons. There’s a short list of usual suspects, and working through it in the right order gets most sites back.
First: don’t start changing things
The instinct is to start deactivating plugins and editing files. Resist it for five minutes. Uncoordinated changes make the original fault harder to find and can turn a recoverable problem into a genuinely lost site.
Do this first: take a backup of the broken site, exactly as it is. Files and database. A broken backup is still evidence, and if a later step makes things worse, it’s your way back. Then find your error logs — your host’s control panel has them, and they usually name the file and line that failed.
The white screen of death
A blank white page almost always means a fatal PHP error. WordPress caught fire and stopped rendering rather than showing you why.
The usual causes are a plugin or theme incompatible with your PHP version, a PHP memory limit that’s too low, or corrupted core files. Turning on WP_DEBUG (or reading the error log) turns the blank page into an actual error message naming the culprit — which is the whole game. Fix the named file, and the screen comes back.
”It broke right after an update”
This is the most common breakage we see, and it’s almost never the update’s fault in isolation — it’s a conflict the update exposed.
A plugin was relying on something that changed. A theme was written against an older API. Two plugins both patch the same behaviour and now disagree. The diagnosis is unglamorous but reliable: deactivate everything, confirm the site loads, then reactivate one at a time until it breaks again. The last one you switched on is your conflict.
Do this on a staging copy if you possibly can. Deactivating plugins on a live store means deactivating your checkout.
500 errors and database connection errors
A 500 Internal Server Error is the server refusing to complete the request — often a corrupted .htaccess, a PHP crash, or a resource limit hit. “Error establishing a database connection” means WordPress can’t reach MySQL: wrong credentials in wp-config.php, a database server that’s down, or — commonly on shared hosting — a resource limit your host has quietly enforced.
Both are worth one call to your host before you spend an afternoon on them. A surprising share of “my site broke” incidents are the host having a bad day, and no amount of plugin debugging fixes that.
If it’s been hacked
Signs: spam pages you didn’t create, redirects to somewhere else, admin users you don’t recognise, or a browser warning shown to your visitors.
The order matters here. Contain first — take that forensic copy, then lock the site down. Then clean — remove the injected code, spam content and backdoors. Then close the hole, because this is the step people skip. Cleaning a hacked site without finding how they got in just schedules the next hack. The entry point is usually an outdated plugin, a weak password, or a compromised neighbour on shared hosting.
Finally, rotate everything: passwords, salts, database credentials, and any API keys the site held. Assume anything on that server was read.
Restore from backup — carefully
If you have a clean backup from before the problem, restoring is often faster than forensics. Two cautions.
First, check the backup is actually clean. Restoring a backup taken after an infection just reinstalls the infection. Second, know what you’ll lose — orders, comments and posts created since that backup will disappear. For a store, that can matter more than the downtime.
And test your backups before you need them. An untested backup isn’t a backup; it’s a hope. That single habit prevents more disasters than any security plugin.
How to not be here again
Most broken sites are preventable, and the prevention is boring: keep core, plugins and themes updated — but apply updates on staging first, so an update never takes the live site down. Keep independent, tested, off-site backups. Use strong passwords with two-factor authentication. Remove plugins you don’t use, because unused code is still an attack surface. And monitor uptime, so you learn about problems before your customers phone you.
That’s exactly what a maintenance and care plan is for — it’s the difference between an incident and an emergency.
When to call someone
If the site is your business, if customer data may be exposed, or if you’ve been going in circles for an hour, stop. The cost of an expert hour is almost always less than the cost of another day down or a botched restore that loses your orders.
Our WordPress rescue & recovery service is exactly this work: triage, contain, recover, harden. If you’re staring at a white screen right now, get in touch and tell us what you’re seeing — we’ll tell you honestly what we think it’ll take.