Theme broke after a WordPress update? Here's how to fix it

01Why a WordPress update breaks a theme

A theme that worked yesterday and breaks after an update didn't change — the ground under it did. WordPress core, PHP, and the block editor all move forward, and a theme that wasn't kept current can fall through the gap. Knowing which gap helps you fix it faster.

• Deprecated functions — WordPress removes old functions over time. A theme calling one that's finally gone throws a fatal error the moment core updates.
• A PHP version bump — updating WordPress or your host's PHP can jump you to a newer PHP. Old theme code that relied on lax, deprecated syntax stops running.
• Block editor changes — the block (Gutenberg) editor and block themes evolve quickly. A theme built against an older version can break layouts or the editor itself.
• An unmaintained theme — the common thread. A theme still actively updated keeps pace with all of the above. An abandoned one accumulates the breakage until something snaps.

That last point is the real story most of the time. If you find yourself fixing the same theme after every major WordPress release, the update isn't the problem — the theme's lack of upkeep is. We'll come back to that at the end.

02First, don't panic: roll back to a working state

Before you diagnose anything, get your site back to working if you can. A broken live site is a clock ticking; a broken staging copy is a puzzle you can take your time with. The fastest route back is almost always a restore, not a repair.

If you took a backup before the update — or your host takes automatic daily ones — restore it. That returns your files and database to the last good state and buys you breathing room. Confirm the restore includes the database, since theme settings and content live there, not in the files.

If you have a staging environment, reproduce the break there and fix it in private, then push the fix live in one clean step. Managed WordPress hosts make this easy — you clone live to staging from the dashboard, apply the update there first, and only a working result ever reaches visitors. Cloudways is one we've used this way; it's exactly the safety net that turns an update scare into a non-event.

No backup and no staging? Then skip ahead — you'll diagnose on the live site, which is slower and riskier, but the steps are the same. Take a backup now, before you change a single thing, so you don't dig the hole deeper.

03Diagnosing the cause: theme vs. plugin conflict

Most "the theme broke" reports are actually a conflict between the theme and a plugin, not the theme alone. WordPress is a stack of independent parts, and an update can change how two of them get along. The goal of diagnosis is to isolate which part is really at fault — and the method is simple subtraction.

Step 1: deactivate all plugins

Go to Plugins, select all, and deactivate everything. If the site comes back to life, a plugin was the culprit. Reactivate them one at a time, checking the site after each, until it breaks again — the one that breaks it is your conflict. If you're locked out of the admin, rename the wp-content/plugins folder over FTP to force-deactivate all plugins at once.

Step 2: switch to a default theme

Activate a default WordPress theme (one of the Twenty-something themes). If the problem vanishes, it really is your theme — not a plugin and not core. If the problem persists even on a default theme, the cause lives elsewhere, usually a plugin or a server-level issue, and you've just saved yourself from chasing the wrong thing.

Run these two tests on staging if you can. They flip your front end around while you work, which is fine in private and disruptive in public. Either way, the pair of results tells you exactly where to point the next fix.

04Enable debug logging to find the actual error

Guessing is slow. WordPress will tell you exactly what broke if you ask it to. A blank page or a generic error is just debug output being hidden — turn it on and the real message appears, complete with a file path and a line number.

Edit your wp-config.php (over FTP or your host's file manager) and set these constants, placing them above the line that says to stop editing:

• define( 'WP_DEBUG', true ); — turns on error reporting.
• define( 'WP_DEBUG_LOG', true ); — writes errors to wp-content/debug.log instead of the screen.
• define( 'WP_DEBUG_DISPLAY', false ); — keeps the errors out of public view while you work.

Reload the broken page, then open wp-content/debug.log. A line like "Fatal error: Call to undefined function ... in /wp-content/themes/yourtheme/functions.php on line 214" hands you the exact file and line. That single line usually turns a mystery into a five-minute fix. When you're done, set the debug constants back to false so nothing leaks in production.

05Common fixes, in order

Once you know it's the theme and you've seen the error, work through these from easiest to hardest. Most breaks are solved at step one or two.

• Update the theme — the author may have already shipped a compatibility fix. Check Appearance → Themes for an available update, or grab the latest version from where you bought it. An update is the cleanest fix because it keeps you on the supported path.
• Fix PHP-incompatible code — if the error names a deprecated or undefined function in a theme file, that line needs updating to current PHP/WordPress. If the theme is supported, the author's update will do this; if you must patch it yourself, do it in a child theme, never the parent.
• Use child-theme overrides — copy the broken template into your child theme and correct it there, so your fix survives the next parent update. This is the right home for any hand edit. If you don't have a child theme yet, make one before you touch code.
• Contact the theme's support — a paid theme comes with support for exactly this. Send them the error from your debug log, your WordPress and PHP versions, and the steps you've already tried. A maintained theme's author will usually have a patch fast.

Notice the pattern: every durable fix assumes the theme is still maintained. If updating isn't an option because nobody ships updates anymore, you're not really fixing the theme — you're propping it up. Hold that thought for the last section.

06White screen / fatal error: recovery via FTP

When an update leaves you with a blank white page — the white screen of death — and you can't even reach wp-admin, you recover from outside WordPress, through FTP or your host's file manager. The trick is that WordPress falls back to a default theme automatically if it can't find the active one.

Connect via FTP/SFTP and open wp-content/themes/. Rename the broken theme's folder — add -broken to the end, for example. WordPress can no longer load it, so it activates a default theme instead, and your admin usually comes straight back. From there you can update the theme, fix it in a child theme, or switch to a replacement deliberately.

If renaming the theme doesn't restore the site, the fatal error is elsewhere — rename the plugins folder too, using the same trick to force every plugin off. Between those two moves and the debug log, you can recover almost any white-screen break without touching the database.

And the obvious note: a white screen on the live site is precisely what a staging copy or a fresh backup would have prevented. The recovery above works, but it's a scramble you only have to do when the update went straight to production.

07Preventing it next time

A post-update break is almost always preventable. The habits that prevent it are cheap, and they turn updates from a gamble into routine maintenance.

• Update on staging first — never run a major WordPress, theme, or plugin update directly on live. Apply it to a staging clone, confirm the site still works, then push it. This single habit removes the public white screen entirely.
• Keep a current backup — back up files and database before every update, and verify a restore actually works before you trust it. A backup you've never tested is a guess.
• Update with discipline — update during low-traffic hours, one major thing at a time so you know what changed, and read the changelog for breaking-change notes before you click.
• Run a maintained theme — the biggest single factor. A theme that's actively updated keeps pace with core, PHP, and the block editor, so the gap that breaks things never opens.

Managed hosts that bundle staging and automated backups make most of this automatic, which is why they're worth it for a site you can't afford to have down. The tooling matters less than the habit, though — staging plus a tested backup is the whole game.

08When the real fix is replacing an abandoned theme

Sometimes the honest answer is that the theme is the problem and no patch changes that. If a theme breaks on every major WordPress release, hasn't been updated by its author in a year or more, and its support forum is a graveyard of unanswered posts, you're not maintaining a theme — you're maintaining a liability.

Each patch you apply to an abandoned theme is rework you'll do again next quarter, and the security risk compounds the longer it goes unmaintained. At some point the time you spend nursing it past every update costs more than a clean switch would.

The durable fix is migrating to a maintained, block-friendly theme — one whose author still ships updates against current WordPress. It's more work than renaming a folder, but it's work you do once instead of forever. Switching themes carefully, without losing your content or rankings, is its own subject, and worth doing on staging with a backup in hand.

If you keep meeting the same theme at the bottom of every update, treat that as the signal it is. The fix isn't another patch — it's a theme that won't need one every time WordPress moves.

09FAQ

Can I roll back a WordPress update to un-break my theme?

You can restore from a backup taken before the update, which effectively rolls everything back. Rolling back core itself is possible with a plugin like WP Downgrade, but it's a stopgap — staying on an old WordPress version to keep an old theme alive just delays the same break. Fixing or replacing the theme is the real answer.

How do I know if it's the theme or a plugin?

Deactivate all plugins; if the site recovers, a plugin is involved, and you reactivate one at a time to find it. Then switch to a default theme; if that fixes it, the theme is at fault. Running both tests tells you which side broke before you spend time on either.

I'm locked out of wp-admin. What now?

Use FTP or your host's file manager. Rename the active theme's folder in wp-content/themes/ to force WordPress onto a default theme, and rename wp-content/plugins to force every plugin off. One or both usually restores admin access so you can finish the fix from inside.

Will updating my theme delete my customizations?

It will if you edited the parent theme's files directly — that's why those edits should live in a child theme or the Customizer's Additional CSS, both of which survive updates. Customizations stored that way are safe across a theme update; hand edits to parent files are not.

How often do WordPress updates actually break themes?

For a well-built, actively maintained theme, rarely — most updates pass without a hitch. Breaks cluster around major core releases, big PHP version jumps, and themes that haven't been updated in a long time. Keeping your theme and PHP current is what keeps updates uneventful.

One honest caveat: this is a general how-to, not financial, business, or professional advice. Every site is different, so test changes on a staging copy with a working backup before you trust them in production.