WordPress Update Broke Your Site? Recovery Steps, Then the Real Fix

A WordPress update broke your site, so work by isolation rather than by guessing. Check the admin inbox for the recovery mode link WordPress sends itself when a fatal error fires, turn on error logging, then deactivate every plugin at once by renaming the plugins folder over SFTP. If the site comes back, reactivate one plugin at a time until it breaks again. That is your culprit, and from there you either roll it back or restore the backup taken before the update ran.

The order matters. Each step either restores the site or narrows the suspect list, and none of them assumes you can still log in.

WordPress update broke the site: the recovery order

1. Look for the recovery mode email before you touch a file

Since version 5.2, WordPress has shipped fatal error protection. When a plugin or theme throws a fatal error, visitors get a screen saying the site is experiencing technical difficulties instead of a blank page, and WordPress emails the admin and super admin addresses a secret link. That link switches your browser into recovery mode, which pauses the failing plugin or theme for your session only, letting you reach the dashboard on a site that otherwise will not load (Make WordPress Core).

Two things stop this working: the admin address may be a mailbox nobody checks, and a broken mail configuration means the message never leaves. Check spam, wait five minutes, then move on.

2. Turn on the error log so you stop guessing

Open wp-config.php over SFTP and add the debug constants above the "stop editing" line. The WordPress developer documentation gives these:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

With WP_DEBUG_LOG on, errors go to wp-content/debug.log, and with display off your visitors never see them (developer.wordpress.org). Note the warning that comes with it: "It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs." On a site that is already down, logging with display suppressed is the compromise, and you turn it off again once you have the file name.

Reload the broken page and read the last lines of debug.log. A PHP fatal error names the exact file, which names the exact plugin or theme. Your host's PHP error log usually carries the same line if you would rather not edit wp-config.php at all.

3. Deactivate every plugin at once over SFTP

If you cannot reach wp-admin, WordPress's own troubleshooting guidance is to do it at the filesystem: log in over FTP or SFTP, find wp-content/plugins, and rename the folder to plugins_old. That deactivates all of your plugins at once (developer.wordpress.org).

Reload the site. If it loads, the fault is a plugin. Rename the folder back to plugins, log in, and reactivate one at a time, reloading after each. Whichever reproduces the failure is the one you handle in step 5.

4. Rule out the theme

If the site is still broken with every plugin off, suspect the theme. The same documentation says to activate a default theme such as Twenty Twenty-One and see whether the problem goes away, and recovery mode gives you the dashboard access to do it. A white screen after a WordPress update that survives both a theme switch and a full plugin deactivation is usually a core or PHP version problem, which is step 7.

5. Roll the plugin back to its previous version

Every plugin in the WordPress.org directory has an Advanced View section on its listing page with a previous versions dropdown. Be precise about what it gives you: a download of an older release ZIP that you install yourself, not a one-click rollback, and the page warns that "Previous versions of plugins may not be secure or stable. They are not recommended for use on production websites."

Treat a rollback as hours bought, not a destination. Reverting past a release that fixed a security hole re-opens it, so report the bug to the developer and plan to move forward again. Commercial plugins sold outside the directory have no public archive, so ask the vendor for the prior build.

6. Restore the backup

If isolation has not produced a working site within an hour, restore. Most managed WordPress hosts take a restore point before running updates and expose a one-click rollback in the control panel. Restore files and database together from the same moment, or you get posts referencing rows that no longer exist. Note anything published after the backup ran so you can re-enter it, and confirm the restore point predates the update, not just the outage.

7. When to hand it to the host

Escalate when the error names a missing PHP function, you get a database error instead of a PHP one, file permissions block you, or the restore fails. Those are host-side, and support resolves them in minutes with access you do not have. Send the exact line from debug.log.

Why WordPress updates keep taking sites down

The arithmetic is against you. Patchstack's State of WordPress Security in 2026 puts the 2025 total at 11,334 new vulnerabilities in the ecosystem, 42% more than the year before. Plugins carried 91% of that total and themes carried 9%. Six landed in WordPress core, and the report rates all six as low priority (Patchstack).

2025 in one line: 11,334 new WordPress ecosystem vulnerabilities. 91% plugins, 9% themes, six in core.

That distribution explains the trap. Almost nothing breaks because of WordPress. Things break because of the fifteen or twenty independent codebases you installed for forms, caching, SEO fields, image optimisation and analytics, each shipping on its own schedule to its own testing standard. Deferring is no safer, since most of those releases carry security fixes. You are choosing between an update that breaks the front end today and an unpatched plugin that gets the site defaced next month.

In a 2014 Business 2 Community piece, Barry Roos describes three in a row: a core point release that produced a white screen on one site while twenty others updated cleanly, a shipping plugin update that threw a PHP fatal error when a customer added an item to the cart, and a calendar plugin update that locked everyone out of the dashboard. Two of the three came back with a standard backup restore. The point release did not: that restore failed, and Roos had to FTP the backup files to the site by hand (Business 2 Community via Yahoo). That is what happens when third-party code executes on every page request.

Two ways to make sure there is no next time

Option 1: harden the WordPress install you already have

This is the right answer if the install does more than publish articles. Do all five:

1. Test every update on staging first. Most managed hosts include one-click staging, so a bad release costs an afternoon instead of production traffic.
2. Verify backups run before updates, and that restores actually work. Test one restore to staging this quarter.
3. Cut the plugin count. Fewer plugins means fewer release streams that can break you.
4. Point the admin email at a monitored inbox. The recovery mode link from step 1 is worthless in a mailbox nobody opens.
5. Add uptime monitoring. Hear that the site is down from a monitor, not a customer.

Our WordPress maintenance checklist sets out the weekly, monthly and quarterly version of this work, and WordPress security issues covers the patching side in detail.

Option 2: run the blog somewhere updates cannot break it

Test yourself against this honestly. If WordPress only publishes articles, and the store, app or members area lives elsewhere, the failure mode this article troubleshoots is optional. If WordPress runs commerce or custom logic, stay on option 1.

For a blog, Superblog removes the update cycle rather than managing it.

• There is no update queue. No core release, no PHP version, no plugin list, no patch window. The platform ships changes on its own infrastructure; you own nothing that can fall out of date or fail mid-update.
• A fatal error has nowhere to occur. Posts compile to static HTML served from a CDN. No PHP executes when a reader opens a page and no database is queried, so the architecture this article troubleshoots is not present.
• Writing tools that arrive without an install. Drafts autosave, and a post can carry more than one author, on every plan. Scheduled publishing and collaborative review start at Pro, along with the Admin, Editor and Writer roles. Seat counts: Pro carries 5 team members, Super 10, Business 25.
• SEO that is generated, not configured. Hitting publish writes JSON-LD for Article, WebPage, Organization, ImageObject and FAQ. The same step refreshes your sitemap, sets canonicals and Open Graph tags, pings IndexNow, and rewrites the llms.txt file that AI assistants read. Hreflang and multilingual SEO unlock on Super.
• Research and artwork in the dashboard, on the Business plan. Keyword lookups return volume, competition and CPC for up to 25 terms in a single search, on live DataForSEO data. The same plan generates a featured image and an OG image from the post with AI, one credit per image.
• Traffic numbers without a consent banner. Pirsch analytics, cookie-free, from Pro upward. Google Analytics connects on any plan.
• Speed you never tune. Every page scores 90+ on Lighthouse, images convert themselves to WebP, and there is no caching plugin in the chain to conflict with anything.
• It sits where your blog already sits. One routing rule puts it on yoursite.com/blog, or use a subdomain or a full custom domain. All three are on every plan, SSL included.

Getting the archive across takes a URL, not an export file, once the site is reachable again. The importer needs the WordPress REST API to answer at /wp-json, so get the site back up first with the recovery steps above, then point Superblog at the URL. It pulls the posts over that API, slug intact, so a post sitting at /plugin-conflict-postmortem/ keeps that address and no redirect map is involved. Original publish dates come too, along with tags, Yoast or SEOPress meta fields, and Yoast's JSON-LD. Four gaps to expect. Bylines all point at the account that ran the import. Only the first category on a multi-category post survives. Rank Math fields are ignored. Images stay on their old URLs until a paid plan is active, so a trial import does not re-host them. Expect 5 to 10 minutes for a normal archive and up to half an hour for an image-heavy one. The WordPress migration guide walks through it.

Volume is the usual follow-up question. One finance publication left WordPress carrying an archive above 15,000 posts. Twenty-three blogs here run at 1,000 posts or more, and everything on the platform adds up to over 150,000. PrintStop brought its business blog off WordPress; Elephas skipped WordPress in the first place.

Size your plan before you move, the same way you would size a hosting plan. Pro runs $49 a month: up to 1,000 posts, 5 team members, built for blogs under 100,000 monthly pageviews. Move to Super at $99 once the archive or multilingual SEO needs outgrow that. You get 7 days to try it without a card, and there is a 30-day money-back guarantee. Every tier is on the pricing page, and WordPress blog alternative compares the two routes line by line.

Questions people ask when an update takes the site down

Why did a WordPress update break my site?

Almost always a plugin or theme incompatible with what changed; 91% of new WordPress ecosystem vulnerabilities in 2025 were in plugins, which is also where the update pressure sits. Less often it is a PHP version mismatch or a partial update.

How do I fix a white screen after a WordPress update?

Rename wp-content/plugins to plugins_old over SFTP to deactivate everything, then reload. If the site returns, restore the folder name and reactivate plugins one at a time to find the offender. If it does not, switch to a default theme, and if that fails too, restore the backup.

Can I roll back a WordPress plugin update?

Yes for plugins in the WordPress.org directory. The Advanced View section of the plugin's page lets you download a previous version and install it yourself, with a warning that older versions may not be secure or stable on a production site. Treat it as temporary and report the bug to the developer.

How do I get into wp-admin when the site is down?

Check the admin inbox for the WordPress recovery mode email. The link it contains pauses the plugin or theme causing the fatal error for your session and lets you log in. If no email arrived, deactivate plugins at the filesystem instead.

Will switching hosts stop updates breaking my site?

Most managed hosts reduce the damage with staging, pre-update restore points and one-click rollback. It does not remove the cause, because the plugins are still yours to update. The cycle ends when the plugins do.

The next update is already on the calendar

If the site is back up, do the boring part today: point the admin email at an inbox you read, confirm your last restore point works, and delete the plugins you installed for a campaign that ended months ago.

And if this is the third time an update has taken the blog down, the blog is the part that never needed WordPress in the first place. Try Superblog free for 7 days, point the importer at your live site's URL, and watch the update queue disappear.