An update broke it
Almost every one of these is a single plugin conflicting with something. The site is recoverable, usually without losing anything, as long as you isolate the cause instead of changing five things at once.
First four minutes
The order is: regain access, identify the culprit, undo that one thing, then work out how to update safely next time. Skipping to the last part is how people end up rebuilding a site that only needed a plugin rolled back.
When a plugin or theme causes a fatal error, WordPress puts the site into recovery mode and emails a special login link to the site administration email address. That link gets you into the dashboard with the offending extension paused, so you can deactivate it normally. Check spam. This is the easiest possible ending, and most people never learn it exists.
A blank white page tells you nothing on purpose, because error display is off in production. Turn on debug logging in wp-config.php by setting WP_DEBUG and WP_DEBUG_LOG to true, with WP_DEBUG_DISPLAY set to false so visitors still see nothing. Reload the site, then read wp-content/debug.log. It usually names the exact plugin file that failed on the first line. Turn debugging off again when you are done.
If you cannot log in at all, use the hosting file manager or an FTP client and rename the folder wp-content/plugins to something like plugins-off. That deactivates every plugin at once. If the site comes back, a plugin is your culprit and you have proved it in one move. Rename the folder back, then rename individual plugin folders one at a time until the site breaks again.
If disabling plugins did not fix it, switch to a default WordPress theme. You can do this by renaming the active theme folder, which makes WordPress fall back to a default theme automatically. If the site returns, the theme or a theme update is the problem, and if you are using a child theme the conflict is often between the two.
Hosts upgrade PHP, sometimes on a schedule you did not notice, and older plugins can stop working the same day. If the site broke without you updating anything, look at the PHP version in the hosting control panel. Setting it back one version is a two-minute test and tells you immediately whether that was it. Treat that as a diagnosis, not a permanent fix: staying on an unsupported PHP version is its own risk.
Once you know which plugin it is, install the previous version rather than restoring the entire site. There are plugins built specifically to roll a single extension back to an earlier release, and the WordPress plugin directory publishes previous versions for download. Rolling back one plugin costs you nothing else. Restoring the whole site loses every order and form submission since the backup.
If nothing isolates cleanly, restore the most recent backup from before the update. Export anything that arrived since first: orders, form entries, new posts. Then, before you update again, do it on a staging copy rather than repeating the same afternoon.
These account for nearly all of it. The symptom pattern tells you which one you are looking at.
Most common
How to check: Disabling all plugins fixes it, and re-enabling them one at a time reproduces it at a specific plugin. Often two plugins that both do caching, or both do SEO, or both touch the same part of a page.
The fix: Roll that plugin back to its previous version, then decide whether you need both plugins. Two plugins doing the same job is a recurring source of this.
Common
How to check: Plugins are not the cause, and switching to a default theme brings the site back. Common after a parent theme update when the child theme was overriding something that changed.
The fix: Roll the theme back and look at what the update changed. If the child theme is copying large parts of the parent, this will keep happening, and that is worth fixing properly.
Common, and confusing
How to check: The site broke without you touching it, or right after a routine update on a plugin that had been fine for years. The error log mentions a syntax error or an undefined function.
The fix: Confirm by switching PHP back one version. Then update or replace whatever is incompatible so you can move forward again, rather than staying behind permanently.
Common
How to check: The site shows "briefly unavailable for scheduled maintenance" and never comes out of it. That message means a file named .maintenance was left behind when an update was interrupted.
The fix: Delete the .maintenance file in the WordPress root directory using the file manager or FTP. The site comes straight back. Then re-run the update that was interrupted.
Less common
How to check: The error log mentions allowed memory size exhausted, or the update fails at the same point every time. Often on shared hosting with a low limit and a heavy plugin.
The fix: Raise the PHP memory limit if your host allows it. If the site genuinely needs more than the plan provides, that is a hosting conversation rather than a WordPress one.
Less common
How to check: The site loads but looks wrong: unstyled, or with pieces in the wrong place. Nothing has crashed, so there is no error to find.
The fix: Clear every cache: the caching plugin, the host cache, any CDN, and your own browser. Stale cached stylesheets after an update explain most of these and cost nothing to rule out.
The line is roughly where an undo becomes impossible.
cPanel support
Help using the file manager, backups, and PHP settings when you need to work outside the dashboard.
OpenWordPress backups guide
How to set up the backup that turns this whole page into a five-minute problem.
OpenStaging sites
Test updates on a copy first. This is the actual fix for it happening again.
OpenRestore a backup
Step by step, for when rolling back one plugin is not enough.
OpenWebsite maintenance plans
Updates run on a staging copy by someone whose job it is, with a backup taken first.
OpenMy website is down
If you are not certain the update is what broke it, start with the wider diagnosis.
OpenCheck the site admin email for a WordPress recovery link first, which logs you in with the broken extension paused. If there is none, use the hosting file manager to rename wp-content/plugins, which deactivates every plugin at once and usually gets the dashboard back.
Yes, and it is almost always the right move. Previous versions are published in the WordPress plugin directory, and there are plugins that do the rollback for you in a couple of clicks. It beats restoring the whole site, which throws away everything that happened since the backup.
An update was interrupted and left a file called .maintenance in the WordPress root folder. Delete that file with your file manager or FTP client and the site returns immediately. Then re-run the update that did not finish.
No. Out-of-date plugins are the most common way small business sites get hacked, and turning updates off trades a rare broken afternoon for a much worse problem. Keep automatic security updates and test the bigger ones on a staging copy.
Three things: a backup that runs automatically and that you have actually tested restoring, a staging copy to run updates on first, and fewer plugins. Most sites carry several plugins nobody can justify, and each one is another thing that can break on a Tuesday.
Usually. Tell me what you tried and in what order, honestly, including anything you deleted. That history is genuinely useful and nobody is judging it.
The domain, what you updated, and any error text. Most of these are a rollback rather than a rebuild, and I will tell you which one you have before doing anything.
