Catch the breakage that returns HTTP 200
An update can leave every page returning a successful status code while the layout has collapsed, the hero image has vanished, or the checkout button has moved off screen. Status checks do not see that. Pixel comparison does.
Free during early access. No credit card required.
Updated
What is visual regression testing for WordPress?
Visual regression testing compares screenshots of a page before and after a change, such as a plugin or theme update, to catch breakage a status check cannot see: a collapsed layout, a missing image or a button pushed off the screen. A broken page still answers with HTTP 200, so only comparing what it looks like reveals it.
WPCentrify compares how a page looks before and after a WordPress plugin or theme update, and a visual break is one of the three things that roll an update back automatically, alongside a PHP fatal error and a 5xx server error. Our article on WordPress update testing shows how this plays out on desktop and mobile.
WPCentrify visual checks at a glance
- Before and after comparison of the page around every plugin or theme update.
- A visual break rolls the update back automatically, like a PHP fatal error or a 5xx server error.
- Catches the breakage that still returns HTTP 200.
- The result is recorded with the update in the activity log.
Successful updates that break the site anyway
The most dangerous update outcome is not the one that takes the site down. A site that is down gets noticed within minutes, by monitoring or by the client. It gets fixed.
The dangerous outcome is the update that succeeds technically while breaking something visually. A CSS change in a plugin release shifts the layout. A JavaScript conflict stops a slider rendering. A form plugin update moves the submit button below the fold on mobile. Every page returns HTTP 200. Every health check passes. Nothing alerts. Our article on WordPress update testing shows how this plays out on desktop and mobile.
This breakage persists until a human looks at the page, which on a client site nobody visits daily can be weeks. By then the client has usually found it themselves, and the conversation is about why you did not notice. It is likeliest on the releases you ship to every site in one pass.
What pixel comparison catches
- Layout collapse from a CSS conflict
- Missing images or broken image paths
- Sliders, carousels and galleries that stopped rendering
- Fonts failing to load and falling back
- Buttons and calls to action moving or disappearing
- Mobile layouts breaking while desktop stays fine
- Cookie banners and overlays covering content
Reference, compare, decide
Comparison runs automatically as part of every safe update, not as a separate step someone has to remember.
Reference captured
Before the update runs, screenshots are taken of the pages that matter on that site, at desktop and mobile widths. Which pages are captured is configurable per site, and defaults to the homepage plus your highest-traffic templates.
Update applied
The update runs after a restore point has been taken, so a rollback is always available regardless of what the comparison finds.
Compared pixel by pixel
New screenshots are captured and compared against the references. Difference is measured as a percentage of changed pixels, with regions that legitimately change on every load excluded.
Kept, flagged or rolled back
Below your threshold, the update is kept and the evidence is stored. Above it, the site is rolled back automatically and you are shown exactly what changed, side by side.
How comparison is configured
Per-site page selection
Choose which pages are compared on each site. A store compares product and checkout pages; a publication compares article templates.
Desktop and mobile
Both viewports captured and compared, because mobile-only breakage is common and invisible from a desktop check.
Configurable thresholds
Set how much visual change is acceptable per site. A marketing site with rotating content needs a higher tolerance than a static brochure site.
Dynamic region masking
Exclude areas that legitimately change on every load, such as carousels, timestamps and randomized testimonials, so they do not generate false positives.
Automatic rollback
Exceeding the threshold triggers the same rollback path as a failed health check, with no human in the loop required.
Evidence for clients
Before and after images stored against the change record, which turns a rolled-back update into a line in the client report you send that month.
Getting thresholds right
The failure mode of visual regression testing is not missing breakage. It is generating so many false positives that people start ignoring the alerts, at which point the system is worse than useless because it has consumed attention and produced nothing.
Most false positives come from content that legitimately changes: a rotating testimonial, a recent-posts widget, a carousel on a different slide, an advertisement, a relative timestamp. Masking those regions once per site removes the overwhelming majority of noise permanently.
The second source is threshold settings that are too tight. A one percent difference threshold sounds rigorous and produces constant alerts. Starting around five percent and tightening for specific high-value pages is more workable, because the breakage that actually matters is rarely subtle. A collapsed layout is a forty percent difference, not a two percent one.
Why status-code monitoring misses this
- A broken layout still returns HTTP 200
- A missing image still returns a rendered page
- A non-functional slider returns valid HTML
- A button moved off screen is still in the DOM
- Mobile breakage is invisible to a desktop check
Related capabilities
Safe updates
The full workflow: restore point, update, health checks, visual comparison, rollback.
See safe updatesBulk updates
Running updates across a portfolio without doing it forty times by hand.
Read moreClient reports
Turning a caught and rolled-back update into evidence the client values.
Read moreQuestions about visual regression
It is configurable. The default is the homepage plus a representative page from each major template, which for most sites is four to eight pages. Stores usually add product and checkout pages. Comparing every page on a large site is possible but rarely worth the time it adds to each update.
It will if you do not mask dynamic regions. Carousels, recent-posts widgets, rotating testimonials and timestamps all change legitimately on every load. Masking those once per site removes most noise, and the default thresholds are set to tolerate small legitimate variation.
It adds time, typically under a minute per site because captures run in parallel. Since updates run on a schedule rather than while you wait, the added duration is not usually noticeable in practice.
Yes. You can set comparison to flag rather than roll back automatically, which suits sites where content changes frequently and you would rather make the call yourself. Automatic rollback is the default because the alternative depends on someone being available.
Yes. The connector authenticates directly, so comparison works on sites behind HTTP authentication, maintenance mode or a staging environment.
Check the site straight after each update in three ways: that pages still answer without a server error, that PHP has not hit a fatal error, and that the pages still look right. WPCentrify does all three after every plugin and theme update and rolls the update back automatically when one fails.
Yes. That is what it is for. A broken layout still returns HTTP 200, so uptime and status checks miss it, while a before and after comparison shows the change. In WPCentrify a visual break found this way rolls the update back automatically.
See what changed, not just whether it responded
Pixel comparison on every update, at desktop and mobile widths, with automatic rollback of plugin and theme updates when a page breaks.
Free during early access. No credit card required.