Guide · Troubleshooting

An update broke the site. What now?

An order of priority you can apply in ten minutes, to get the site back without making things worse.

Updated 2 September 2026 8 minute read

On this page
  1. Stop right now
  2. Save the current state
  3. Find the last action
  4. Read the logs
  5. Isolate the culprit
  6. Restore or fix
  7. Verify afterwards
  8. Common questions

Short answer

My WordPress site broke after an update. Where do I start?

Stop changing things. The first instinct, rerunning more updates or deactivating plugins at random, adds variables to a problem that already has too many.

Then, in this order: take a copy of the current state, broken as it is, write down the last action performed, look at whether the fault affects the whole site or a single page, then return to your last verified backup if you have one. Redo the updates one at a time to isolate the cause.

Stop right now

Every extra move makes the cause harder to find. An outage with one variable is solved in ten minutes; the same outage with six variables takes half a day.

In practice: do not rerun more updates, do not deactivate plugins at random, do not install a plugin that claims to fix it, and do not clear caches hoping it goes away.

Careful

If the site takes orders or bookings, tell whoever handles them before touching anything. A restore will erase what happened between the backup and now.

Save the current state, broken as it is

It sounds backwards: why back up a site that is down? Because that is what keeps your options open.

Without a copy of the broken state, a restore is a one-way trip: you lose the data that arrived since the backup, and you also lose the ability to examine what happened. With that copy, you can restore, then come back for the orders or messages received in between.

Worth remembering

Keeping a copy of the broken state before restoring preserves material that is useful for diagnosis.

What was the last action?

That is almost always where the answer is. Write down what was done just before, even if it seems unrelated: an update, a settings change, a new plugin, a theme edit.

Then answer one question: does the fault affect the whole site, or a single page?

What you see on screen and where to look first
What you seeWhere to look first
The whole site is blank or erroringThe theme, a central plugin, or the PHP version.
One page is brokenA block, a form or a page builder used on that page.
The site loads but a function is deadThe plugin carrying that function, recently updated.
The admin is unreachableA security or caching plugin, or a session problem.
The layout has slippedThe theme or the page builder, almost always.

Read the logs before guessing

A site in error usually writes down why. You just have to go and read it.

Your host almost always exposes an error log in its control panel. Look for lines timestamped at the moment of the outage, not the oldest ones. The name of a plugin or theme file often appears directly.

Technical detail

If the site shows a blank page with no message, error display is probably switched off, which is the right setting in production. The server-side log keeps writing. That is where to look, rather than turning on debug mode on a site visitors are using.

An error naming a file under wp-content/plugins/ points at the plugin. An error under wp-content/themes/ points at the theme.

Isolate the culprit

If the logs are not enough, elimination works, provided you are methodical rather than fast.

  1. Deactivate the last batch you updated

    Not every plugin: only the ones in the last group. If the site comes back, the culprit is in there.

  2. Reactivate one at a time

    Checking the broken page after each. The first one that reproduces the fault is the one.

  3. If nothing changes, try the default theme

    Temporarily. If the site comes back, the problem is in the theme, not the plugins.

  4. Write down what you find

    So you do not walk the same path next time, and so you can decide whether that component should be replaced.

Careful

Switching theme on a production site changes the appearance for every visitor during the test. Do it outside traffic hours, or on a copy if you have one.

Restore or fix

Two paths, and the right one depends on what you have.

You have a recent, verified backup: restore. It is the shortest path, and you then redo the updates one at a time, calmly.

You do not, or it is too old: you have to fix in place. Remove or replace the faulty component, roll it back to its previous version if the vendor provides one, or wait for a patch if the function is not critical.

Either way, what follows is the same: verify the site actually works before calling the incident closed.

Worth remembering

Restoring is not an admission of failure. It is often the fastest decision, and the only one that does not add variables.

And afterwards, so it does not happen again

An isolated incident happens. An incident that returns is a sign the cause was not addressed.

Three things prevent most repeats: a verified backup before every intervention, updates done in batches in a decided order, and removing components their vendor no longer maintains.

If your site is down right now and you are not already a client, we will say it plainly: we do not do one-off emergency work. Our job is following sites over time. For an immediate outage, an emergency repair service will be faster than us.

Common questions

Can I just deactivate every plugin?

It tells you whether the problem comes from plugins, but it also switches off functions your visitors can see during the test. Deactivating the last batch you updated gives the same information with far less damage.

Should I turn on debug mode?

Not on a site visitors are using: it can show file paths and technical detail to everyone. Your host’s error log gives the same information without exposing anything.

Does restoring erase my recent orders?

Yes, the ones that arrived after the backup point. That is exactly why you copy the current state before restoring: it lets you recover what came in afterwards.

How long before calling someone?

If the site is a source of revenue and you have not identified the cause in thirty minutes, the cost of the outage usually exceeds the cost of help.

Have your site looked at

Describe what happened and what you have already tried. We will tell you what we see, and whether ongoing coverage makes sense for you.

Have my site checked View the free checklist