🔧 Flat-price WordPress fixes from $69 — start with a free diagnosis, no card. Get a free diagnosis →

Updates

What to Do When WordPress Breaks After an Update

Nov 9, 2026 · 8 min read · By the Mend engineering team

If your WordPress site broke right after an update, the safest first move is to stop updating anything else and restore the last known good state if you have a recent backup. If you do not, work backward from the change you just made: plugin, theme, WordPress core, PHP, or a caching layer. That narrows the problem fast and keeps you from making it worse.

The good news is that most post-update breakages are caused by a compatibility conflict, not permanent damage. The bad news is that updating again “to see if it fixes itself” can overwrite the clues you need. Take a breath, preserve the current state, and diagnose methodically.

What this usually looks like

A site that breaks after an update does not always look the same. You might see a critical error, a white screen, missing layout styles, a broken menu, checkout failures, admin redirects, or one page that works while another does not. Sometimes the frontend is down but wp-admin still loads. Sometimes the dashboard itself is the thing that is broken.

The timing matters. If the site was healthy before the update and failed immediately after, the update is almost always connected. That does not mean the update itself was “bad”; it often means the updated code exposed an old mismatch somewhere else.

The most likely causes

When a WordPress site breaks after an update, these are the usual suspects:

  • Plugin conflicts — one plugin was updated and no longer plays nicely with another plugin, the theme, or the current WordPress version.
  • Theme incompatibility — a theme update can expose unsupported template code, outdated hooks, or custom code added in a child theme.
  • WordPress core mismatch — the site may be using a plugin or theme that is not ready for the current WordPress version.
  • PHP version changes — some updates depend on a newer PHP version, while others break because the server PHP version is too new for older code.
  • Caching or minification issues — stale cache, merged CSS/JS, or a CDN can keep serving broken assets after the site itself has changed.
  • Database or filesystem permission problems — less common, but updates can fail partway through and leave files or database tables in an inconsistent state.

If you want a broader overview of update-related failures, this guide pairs well with WordPress Site Broke After an Update? Here's What Happened and How to Fix It.

First: protect the current state

Before you change anything else, make a backup of the current site files and database. Even if the site is already broken, the broken state is valuable evidence. If you have a host backup or a backup plugin, save a copy before testing fixes.

If you can still access wp-admin, avoid running more updates until you know what failed. If you cannot access wp-admin, do not start deleting random plugin folders. That can make recovery slower and can erase the exact file set you need to compare later.

Step 1: identify what changed

Start with the simplest question: what update happened most recently?

  1. Check whether WordPress core, a plugin, or the theme was updated just before the break.
  2. Look at the site’s error message, if there is one.
  3. Note whether the break affects the whole site or only specific pages.
  4. Check whether the admin area still works.

If you have server access, review the PHP error log. If you do not, turn on WordPress debugging only if you can do so safely and you know how to view the log without exposing it publicly. The error log often names the exact file and function that failed, which is much more useful than guessing.

Step 2: isolate the update type

The recovery path depends on what was updated.

If a plugin update broke the site

This is the most common scenario. If wp-admin still works, go to the Plugins screen and deactivate the most recently updated plugin first. If you cannot reach wp-admin, use your host’s file manager or SFTP to rename that plugin’s folder inside /wp-content/plugins/. Renaming the folder safely disables the plugin without deleting it.

If the site comes back, you have found the culprit. Keep the plugin disabled, restore the last working version if needed, and check whether the developer has released a compatibility fix.

If a theme update broke the site

Switch temporarily to a default WordPress theme if possible. If wp-admin is available, do that from Appearance. If not, rename the active theme folder through SFTP or file manager. WordPress should fall back to another installed theme, assuming one exists.

Theme breakage often shows up as missing layout, broken menus, or template errors. If the issue started after you edited theme files manually, that is an important clue. For future changes, read Never Edit WordPress Theme Files Directly before touching production theme code again.

If WordPress core updated and the site broke

Core updates are usually reliable, but they can still expose plugin, theme, or hosting problems. Do not immediately roll back WordPress unless you are sure the site was stable on the previous version and you have a safe way to restore it.

First check for plugin and theme compatibility. If the problem began after a core update, deactivate plugins in stages and switch themes if needed. Also verify that your host is running a PHP version supported by your current WordPress version and active extensions.

If PHP changed at the same time

Hosting panels sometimes update PHP automatically or during maintenance. That can break older code instantly. If your host allows it, switch back to the previous PHP version temporarily to confirm the cause. If the site recovers, update the incompatible theme or plugin, or replace it with a maintained alternative.

Step 3: clear the “looks broken but isn’t” layer

Sometimes the update succeeded and the real problem is cached output. Before deeper surgery, clear every cache layer you have:

  • WordPress caching plugin cache
  • Host/server cache
  • CDN cache, if used
  • Browser cache, or test in a private window

Then hard refresh the broken page. If styling or scripts are missing, also check whether file minification or asset optimization is combining files incorrectly. Disable those features temporarily to see whether the site stabilizes.

Step 4: use a safe rollback if you have one

If the site was working before the update and you have a backup, restoring the backup is often the fastest fix. The key is to restore both files and the database from the same point in time, not one without the other.

After restore, do not immediately re-run the same update on the live site. Test the update in a staging environment first if you have one. If you do not, at least verify plugin and theme compatibility notes before trying again.

Step 5: verify whether the problem is actually a deeper conflict

Once the site is back, do not stop at “it loads again.” Find out what broke so it does not happen twice. Check the updated item’s changelog, confirm version compatibility, and look for any custom code that depends on old behavior.

Sites with many plugins are more likely to show hidden conflicts after updates, especially when several extensions touch the same area of the site. If your site has accumulated a lot of add-ons, this related piece can help explain why: How Too Many WordPress Plugins Hurt Performance.

What not to do

When a WordPress site breaks after an update, a few common reactions create more damage than the original problem:

  • Do not keep clicking “update” on other plugins in the hope that something will fix itself.
  • Do not delete random folders unless you know exactly which component you are disabling.
  • Do not edit live files blindly without a backup.
  • Do not ignore server logs if they are available; they often point straight to the cause.
  • Do not assume the update itself is the only issue. Often the update simply revealed an old compatibility problem.

How to prevent this next time

The safest update process is boring on purpose. Back up first, update one thing at a time, and verify the site after each change. If possible, test updates on staging before production. That is especially important for sites with custom code, page builders, ecommerce checkout, or older plugins that may not be actively maintained.

Also keep your update process consistent. Many breakages happen because updates are done in batches with no note of what changed. A simple log of update dates, affected plugins, and outcomes makes future troubleshooting much faster.

If you want a practical checklist for avoiding update-related outages, use Safe WordPress Updates Without Breaking Your Site.

When to call a professional

Call in a WordPress engineer if the site is down, the admin area is inaccessible, the error repeats after rollback, or you do not have a clean backup to restore. You should also get help if the site powers business-critical pages like checkout, lead forms, or member login and you cannot afford a long experiment.

This is exactly the kind of problem Mend handles every day. If you want a fast diagnosis first, start with a free diagnosis and we will identify the issue and quote a flat price before any work. If the site is actively down and you need help now, our Emergency Rescue is built for broken sites; we work backup-first, most fixes are completed the same day, and every paid fix includes a plain-English report of what changed.

If you already know the issue is likely a compatibility problem and want a focused repair, the Quick Fix is a good fit for many update-related breakages. You can also connect your site securely without sharing passwords.

The important thing is to avoid compounding the problem while you troubleshoot it. A careful rollback or a disciplined isolation process usually gets the site back quickly. If that process is already taking too much time, getting a senior engineer involved is often the cheapest next step.

Frequently asked questions

Should I update WordPress again if the site broke the first time?

Usually no. Updating again without knowing what failed can overwrite clues and make recovery harder. Fix the current issue first, then test future updates in staging or on a copy.

Is it safer to restore a backup or to troubleshoot the broken update?

If you have a recent, known-good backup, restoring it is often the fastest and safest way to get the site back. After that, investigate what caused the break before reapplying updates.

What if I can still access wp-admin but the frontend is broken?

That often points to a theme, cache, or asset problem rather than a full site failure. Clear caches first, then check the most recently updated plugin or theme.

Can a PHP update break WordPress even if WordPress itself did not change?

Yes. A newer PHP version can expose older plugin or theme code that was already on the site. If your host changed PHP around the same time, test that first.