My website looks broken after an update

Something was updated and the site changed. Before doing anything, find out what was applied and when, because the answer decides whether this takes ten minutes or a day.

The instinct is to restore a backup immediately. That is often the wrong first move: it reverses the update along with the damage, so the same failure returns the next time it is applied, and it discards anything added since the backup was taken.

The first five minutes

1. Check it is not only you. Load the site on a phone with wi-fi off, and in a browser you do not normally use. A page cached mid-update looks broken to you and fine to everyone else.

2. Find the update log. Most platforms record what was updated and when. That list, with a timestamp, is the diagnosis.

3. Write down what is actually wrong. Layout collapsed, images missing, a section gone, an error message, the editor unusable. Different symptoms point at different components and the description saves diagnostic time you would otherwise pay for.

4. Check whether it is only the appearance. A site that looks wrong but takes enquiries is a different urgency from one where the form has stopped. Test the form specifically — that failure is silent and it is on enquiries that never arrive.

Finding the culprit: which plugin or theme update caused it

Symptom	Usual cause
Layout collapsed, unstyled text	Theme, or a stylesheet not loading
One section or feature gone	The plugin providing it
Images missing	Media handling, or a path change
Error message instead of a page	A fatal conflict between components
Editor unusable, front end fine	The platform’s own update
Slow rather than broken	A component doing more work than before

The method is the same regardless: disable the most recently updated components one at a time, checking after each. The one that clears the fault is the cause. Disable rather than delete, so the finding is reversible and the evidence remains.

If disabling everything recent does not clear it, the platform’s own update is the likely cause and that is a different, larger job.

If the admin dashboard itself will not load: a blank white screen

On WordPress specifically, an update that fatally conflicts with something else often produces a completely blank page — the white screen of death — with no error message and no way to reach the dashboard to disable anything through the admin interface. When that happens, the fix moves from the dashboard to the file system: connect via SFTP (or the hosting control panel’s file manager), go into the wp-content/plugins folder, and rename the folder of the plugin you suspect, or each plugin folder in turn, to deactivate it without needing admin access at all — WordPress treats a renamed plugin folder as missing and simply stops loading it. Turning on debug mode (WP_DEBUG) in the site’s configuration file, if a developer is comfortable doing so, replaces the blank white screen with the actual PHP error and the specific file it came from, which turns a guessing exercise into a direct answer. Before any of this, load the site in an incognito or private browsing window first, to rule out a cached copy of the page in your own browser being the actual cause.

Restoring a backup, done properly

Sometimes it is the right answer — when the site is unusable, when the cause cannot be found quickly, or when the business is losing enquiries.

Three things to establish first:

When was it taken? Anything added since will be lost. On a site with orders, bookings or form submissions stored in the database, that can matter a great deal.

What does it contain? Files, database, or both. A files-only backup restored over a changed database produces a new and more confusing failure.

Have you ever restored one? This is the question that matters. A backup nobody has ever restored is an assumption, not a backup, and the moment you discover it is incomplete is always this moment.

After a restore, the update is still pending and will be applied again by whatever applied it the first time. So the cause has to be identified anyway, or this repeats on a schedule.

Why the answer is not to stop updating

Out-of-date software is the most common way a small business website is compromised, and the compromise is a far worse day than a broken layout. Turning updates off trades a visible problem for an invisible one, which is on responding to a compromised site.

The real answer is to update in a place where breakage cannot reach customers: apply it to a staging copy, look at it, then apply it to the live site. That is what staging is for, and it is the difference between an update being a routine task and an update being an event. The mechanics of staging are on the launch switch.

The pattern underneath this

A site broken by an update is usually a site carrying more components than it needs. Every plugin is code from a third party that can conflict with another, and each one is an ongoing dependency rather than a one-off feature.

Two habits reduce the surface. Remove components that are no longer used rather than leaving them disabled. And before adding one, ask whether the feature is worth a permanent dependency — a plugin added for a campaign three years ago is still a thing that can break the site.

Who fixes it, and who should have prevented it

Reversing a bad update is developer work, usually short. The larger question is who was responsible for applying it.

Where updates are somebody’s contractual responsibility, breakage caused by them applying one is their problem to resolve and it is worth establishing that before the invoice. Where nobody is responsible, that is the finding, and it is more important than this incident: an unmaintained site is not stable, it is untouched, and it will eventually be compromised rather than broken.

What an ongoing arrangement should cover, and what it should say about updates specifically, is on website maintenance cost.

What to do next

Find the update log and read the last ten entries with their dates. That single list resolves most of this. Then, whatever the outcome, restore a backup to a test location once this month — not because you need it now, but so you know whether it works before you do. The technical scope for all of this sits under web development services.