How to test WordPress updates before your client finds the breakage

Uptime monitoring has a blind spot

Every WordPress update is a small bet. Most of the time it pays off. Occasionally a theme update leaves a homepage as a column of unstyled text, and the site keeps answering 200 OK to every check anybody has pointed at it. Uptime says fine. The plugin reports its new version. The client finds out first.

That gap is the whole problem. Uptime monitoring answers a deliberately narrow question: did the server respond. It cannot tell you whether the page that came back still has a layout, a stylesheet or a working navigation. Neither can a plugin version number, which only confirms that a file was replaced.

Why counting pixels is not enough

The hard part was never spotting a difference. It is knowing which differences matter.

Compare two screenshots by counting pixels and you hit a wall immediately. A plugin update adds a cookie banner. Everything below it shifts down by 120 pixels. Now four fifths of the page is different, which by arithmetic is the same score you would get from a page whose layout had collapsed entirely.

A tool that only counts pixels has to pick a side. Halt on that, and you stop a 200 site rollout over a cookie banner: somebody investigates, finds nothing wrong, and within a fortnight the check gets switched off. Ignore it, and you miss the real thing. A check nobody trusts protects nothing.

So the comparison looks at the structure of the page, where elements sit, how large they are and whether they still have styling, rather than a raw percentage of changed pixels. That is what separates "everything moved down together and nothing fell over" from "the layout collapsed".

Four outcomes, and only one stops a rollout

• Looks the same. Nothing moved, and the rollout carries on.
• Changed, but the layout held. Something appeared or shifted, a banner or a new block of content. The rollout carries on and the difference is shown to you.
• Broke. Blank, collapsed, unstyled, erroring, or it will not load when it loaded before. The rollout stops and the change is put back.
• Could not tell. The check itself could not run. The rollout carries on and says so plainly.

That last one matters more than it looks. "We could not tell" is never dressed up as "it is fine". Stopping a hundred sites because our own check failed would be a worse outcome than the risk it was avoiding, but so would quietly calling it a pass.

When a page breaks, it goes back

A broken page does not just get flagged. A rollback point is held through the whole check and only released once the pages have been confirmed. If they have not been, the change is reversed: the specific plugin or theme that was updated, nothing else, and never your database.

You can also press Put it back yourself, from the site's own page, for as long as the rollback point is held. It is the same safety net that sits behind safe updates, applied to the one thing a version number cannot tell you.

Desktop and mobile, because they break differently

A theme update that collapses a mobile menu and leaves the desktop layout untouched is one of the most common ways this goes wrong. Both sizes are checked, and a good result on one never covers for a bad result on the other.

The before picture is also taken immediately before the update runs, not pulled from last week's routine snapshot. Comparing against a picture from six days ago blames the update for every edit your client made in the meantime, and the point is to blame the update only for what the update actually did.

What you see

Each watched page shows its latest picture on desktop and on mobile, side by side. Open a comparison and a slider wipes between before and after, with the area that moved highlighted.

Anything that changes on its own, a rotating banner, a live chat bubble or a latest-posts block, can be excluded before the picture is taken. Without that, every comparison reports a change that is only ever the clock. Each page also carries its own sensitivity setting, which decides how much ordinary movement is worth mentioning and has nothing to do with safety. Relaxing it cannot let a broken page through, because whether a page broke is decided by whether its layout collapsed, never by a percentage.

The honest limits

• It checks the pages you tell it to watch, not every page on the site.
• It confirms your pages still render. It is a picture, not a click-through, so it does not submit your contact form or run a test checkout on a live site.
• Rolling back reverses the plugin or theme that was updated. It never touches your database or unrelated code.

For the full picture of how the comparison fits the rest of the update pipeline, see visual regression testing, and if an update has already gone wrong on a site you manage, the recovery steps are in a plugin update broke my site.