WordPress White Screen and 500 Errors: Fix Order
5 min read
The site was fine yesterday and today it is a blank page, or a single line of server error text. The easiest mistake at that moment is panic editing: deleting files, switching themes, trying settings one after another. A few rounds of that and nobody can tell what broke in the first place. Below is a fixed order to work through. Most of the time the cause turns up within the first three steps.
Step zero: work out how far it reaches
Spend two minutes on the situation before touching anything. The four answers below decide which direction to look in, and whether this is something you should be doing yourself at all.
Confirm these four things first
- Open it in another browser or a private window. Sometimes your own machine is holding an old copy and everyone else sees a working site.
- Check whether the admin is broken too, or only the public site. Public side only usually means the theme or a plugin. Neither side loading means the problem is wider than that.
- Think back to what was done recently. A plugin update, a theme change, a settings change, or nothing at all? The answer to this one is often the cause.
- Look at the other sites on the same server. If they are all misbehaving, the problem is the host, not WordPress.
Those four take under five minutes and save most of the investigation time. In practice the most common answer is "I think somebody clicked update yesterday". Once that sentence appears there is barely anything left to look for: start from that update.
Step one: get the error message to show up
A white screen is hard to diagnose because WordPress hides the error by default and writes nothing at all to the page. Get it talking first and you have something to follow instead of guessing at settings one by one.
The way to do that is to switch on WordPress debug mode in the configuration file and send the messages to a log file rather than to the screen. Visitors seeing internal paths and file names does you no favours: it lays out the structure of the site for anyone who looks. Turn it on, reload the page, then read the log. It usually names the plugin and the file that failed.
If editing the configuration file is awkward, the hosting control panel almost always has error logs of its own. Some hosts record the same messages there, and they will show which file is complaining just as well.
Step two: rule out plugins and the theme, one at a time
Most white screens and server errors come from a plugin or the theme. The method is crude and effective: turn everything off, then bring them back one at a time. It is not elegant, but it narrows the range faster than anything else.
If you can still reach the admin, deactivate every plugin and see whether the site returns. If it does, activate them one by one until it breaks again, and that is your culprit. If you cannot reach the admin, use the host's file manager or a file transfer tool to rename the plugins folder, which has the same effect as deactivating all of them at once. Nothing is deleted, and renaming it back puts you where you started.
If it is still broken with every plugin off, switch the theme to one of the default WordPress themes and try again. When the public side is broken and the admin is fine, the theme is the stronger suspect.
Step three: failed updates and failed installs
An update that stops halfway, or a plugin that will not install, usually means the site is fine and that permissions, disk space or execution time are not. Each symptom points at a different cause, so reading them off a list beats trying things at random.
| Symptom | Usual cause and fix |
|---|---|
| Stuck in maintenance mode after an interrupted update | The temporary flag file created during the update was never removed. Delete it with a file manager and the site comes back |
| A plugin or theme will not install | Check the disk space on the hosting account first, then whether the upload size limit is too small |
| It asks for connection details before installing | A file permissions problem. Ask the host to adjust it, which is safer than changing permissions yourself |
| It broke right after an update finished | Go back to whatever was just updated. If there is a backup from before it, restoring is the quickest route |
These have something in common: they are limits in the environment, not faults in the content. So the direction to look is the hosting configuration, not the database or the posts. Once the site is back, check whether that update actually completed. A version stuck halfway is more trouble than one that was never applied.
Step four: database connection errors
A page that says it cannot connect to the database is a different category, and it has nothing to do with plugins. Deactivating plugins and switching themes will not help here. The direction has to change completely.
There are usually three causes. The most common is that the database username or password in the configuration file was changed or entered wrongly, which happens most often after a move, a change of host, or a restore from backup. The second is that the database server is not responding, which is usually something at the hosting end, and asking the host is far quicker than investigating yourself. The third is a damaged table, which WordPress sometimes flags with a repair prompt of its own. Following those instructions normally recovers it.
The order to judge by is simple. If the hosting was touched recently or a backup was restored, check the connection details in the configuration file first. If nothing was touched and this appeared out of nowhere, ask the host first. Only when both of those come back clean does table repair come into it.
When to stop and get help
Doing your own triage is worth it. It saves money, and it makes you quicker the next time something breaks. But there are situations where carrying on only makes things worse. Stop when you hit one of them.
Stop if any of these apply
- You have no backup and the next step would change the database. Break it and there is no way back. This is the only step in the whole process with no return.
- You suspect a break-in rather than a plain fault. An admin account you do not recognise, or unfamiliar content injected into pages, means treating this as a security incident. Preserve the scene instead of cleaning up in a hurry.
- The site holds orders or customer accounts and you are not sure whether an action will touch them. Losing a single order usually costs far more than paying somebody to look at it once.
- You have been through the whole list and still cannot find the cause. More trial and error only adds variables, until nobody can say what broke first.
When you do stop, write down what you did: what was changed, when, and what the screen showed at the time. Handing that to whoever takes over usually halves the time it takes them, and it stops them walking back down the paths you already ruled out.
Most WordPress failures are less mysterious than they look. Four in five land in plugins, themes or a failed update. Work through it in order and note what you changed at each step, and even if you end up handing it over, that record saves a lot of time. There is only one thing to genuinely avoid: changing things at random with no backup.
Common questions
- The site is blank and I cannot even reach the admin. What now?
- Use the host's file manager or a file transfer tool to rename the plugins folder, which deactivates every plugin at once. In most cases the admin becomes reachable again. Then rename the folder back and activate the plugins one at a time to find the one at fault. Nothing gets deleted by doing this.
- An update was interrupted and the site is stuck in maintenance mode. How do I fix it?
- WordPress creates a temporary flag file while updating and deletes it when the update finishes. If the update is cut off, the file stays and the site keeps showing the maintenance notice. Delete that file with a file manager and the site returns. Once it is back, check whether that update actually completed.
- Can I just restore an old backup after something breaks?
- You can, but confirm two things first. One: how old the backup is, and whether restoring it loses orders or posts from the period since. Two: if you suspect a break-in rather than a plain fault, restoring may bring a back door back with it. For a straightforward failed update, restoring is the quickest route. A security incident needs handling separately.