Every update is risk-scored, backed by a restore point, tested visually and functionally, then kept or rolled back automatically. You decide the policy once and stop losing evenings to a plugin release you did not choose.
Included on every plan. No add-on pricing.
Updated
A safe WordPress update is one with a way back and a check afterwards: the previous version is kept before the update runs, the site is checked once it has run, and the update is undone automatically if the check fails. It is how you keep sites up to date without finding out from a client that an update broke something.
WPCentrify updates WordPress plugins, themes and core on every site you manage and keeps a way back for each one. After a plugin or theme update it checks the site, and it rolls the update back automatically if the update causes a PHP fatal error, a 5xx server error or a visual break found by comparing the page before and after. Our guide to WordPress automatic updates explains what WordPress already does on its own.
A WordPress site is not one piece of software. It is a WordPress core release, a theme, and typically twenty to thirty plugins, each maintained by a different team on a different schedule with different testing standards. Nobody tests that exact combination except you, in production, at the moment you press update. Multiply that by a portfolio and the arithmetic is what makes bulk updating plugins across multiple sites a risk decision rather than a convenience.
Most breakage comes from a small number of predictable causes: a major version bump that changes an API other plugins depend on, a page builder update that shifts CSS, a PHP version requirement that your host has not met, or two plugins that both want to control the same hook. None of these announce themselves in the update notification. All of them are detectable before the update reaches a live site, which is the argument for checking anything risky automatically the moment it lands, with a restore point ready. If one has already gone wrong, our guide to recovering a site a plugin update has broken covers the way back.
WordPress's own auto-updates only roll back a plugin that crashes the home page. Our guide to WordPress automatic updates explains what they cover; here is what WPCentrify adds before and after every update.
A patch release from 4.2.1 to 4.2.2 is a different proposition from 4.x to 5.0. WPCentrify reads the semantic version jump, the changelog, and whether the release is flagged as a security fix, then weights the risk accordingly. Security patches on low-risk plugins can be fast-tracked; major versions never are.
The update is checked against published vulnerability databases in both directions: whether the current version is vulnerable, which raises urgency, and whether the new version has any reported issues of its own, which raises caution.
If the same plugin version has caused health check failures or visual regressions on other portfolios, that signal raises the risk score before the update reaches you. The more sites running WPCentrify, the earlier a bad release is caught.
The same plugin update carries different risk on a brochure site and a WooCommerce store taking four hundred orders a day. You tag sites by criticality and business hours, and the policy engine treats them differently. Those tags are what the maintenance rules you set once read when they decide what ships unattended and what waits for you.
HTTP status on key URLs, PHP fatal error detection, database integrity, admin reachability, and REST API response. Anything that returns a 500 stops the rollout immediately. Fatal errors are what produce the WordPress critical error message and the white screen of death.
Screenshots of your key templates before and after, compared pixel by pixel. You set the tolerance: 2 percent movement on a blog page might be fine, while any movement on a checkout template is not.
Contact form submission, add to cart, checkout page load, login flow and search. The things that earn money get tested explicitly rather than inferred from a page returning 200.
If any check fails, the restore point taken moments before the update is applied, the plugin version is pinned so it cannot be retried by accident, and you get an alert explaining exactly which check failed and why.
Comparison is set per site rather than per portfolio: its own pages, its own masked regions and its own tolerance, because a marketing site with rotating content and a static brochure site cannot sensibly share a threshold. Masking, page selection and where to start that threshold are covered on the visual regression testing page. The controls below decide how an update that passes then reaches everything else.
What people ask before they turn this on.
The rollback runs without you. The restore point taken immediately before the update is applied, the failing version is pinned, and an alert is sent through whichever channel you configured. In the morning you get a change record explaining which check failed, with the before and after screenshots attached.
Yes. Every automation is a default you can override. You can push a single update immediately or run the full verification sequence on demand from any site's detail view.
Yes. WPCentrify can authenticate against a test account to capture screenshots of dashboards, account pages and checkout steps that are not visible to anonymous visitors.
WordPress has some protection built in: since version 6.3 it restores the previous version when a plugin or theme update fails to install, and since 6.6 it rolls back a plugin auto-update that causes a PHP fatal error. It does not take a full backup first, check your pages for server errors or visual breaks afterwards, or undo an update that breaks the layout without crashing the site. WPCentrify wraps every update in those checks, then rolls back a plugin or theme update automatically when one fails.
The risk score falls back to version distance, install base across the network, historical failure rate for that developer, and the criticality of the site. A missing changelog raises risk rather than lowering it.
It is safe when every update has a way back and a check afterwards. WPCentrify keeps a copy of the plugin folder an update replaces, checks the site after the update, and rolls the update back automatically if it causes a PHP fatal error, a 5xx server error or a visual break.
For a free plugin, WordPress.org keeps previous versions under Advanced View on the plugin's page, which you can upload to replace the new one. With WPCentrify the website keeps a copy of the folder the update replaced, so you can put the previous version back in one step from the dashboard, and a broken update is rolled back automatically.
Usually because of a combination nobody tested: a new plugin version that needs a newer PHP than the host runs, two plugins that clash, a major version that changes how other plugins call it, or a theme or page builder update that shifts the layout. Most of these can be caught by checking the site straight after the update.
Every update has a way back. The website keeps a copy of each plugin or theme folder an update replaces, and a WordPress core update also copies the database and WordPress's own files first. For bulk plugin and theme updates, the workspace owner can also switch on a database copy before each run.
The restore point every safe update depends on
Read moreApply verified updates across the whole portfolio
Read moreMore on this topic: WordPress update testing
Connect a site in under two minutes and see this working against something real. Free during early access.
Free during early access. Keep your data, export any time.