WordPress updates break websites. Not always, not most of the time, but often enough that applying updates directly to a live site is a gamble no organization should take.
WordPress 6.9 broke three major plugins at launch: WooCommerce, Yoast SEO, and Elementor. Millions of sites that had auto-updates enabled were affected. Sites that ran updates through staging first caught the conflicts before visitors ever noticed.
That single incident illustrates why staging environments exist. If you're unfamiliar with the concept, our guide on what a staging site is covers the fundamentals. The question isn't whether an update will eventually cause a problem. The question is whether you'll discover that problem on a staging site or on your live site while your members, donors, and visitors are using it.
Why WordPress Updates Are Riskier Than They Look
WordPress has a plugin ecosystem with over 60,000 plugins, developed by thousands of independent teams on their own timelines. When WordPress core releases a major update, every plugin needs to be compatible with the new version. When a plugin updates, it needs to remain compatible with your specific combination of other plugins, your theme, and your PHP version.
No one tests every possible combination. They can't. Your site's specific plugin stack, theme, customizations, and server environment create a unique configuration that only exists on your site.
The only way to know whether an update is safe for your setup is to test it on a copy of it.
That's what staging is for.
The Plugin Compatibility Chain
Plugin conflicts are the leading cause of WordPress site breakage. They're also the hardest to predict because they involve interactions between independent codebases that were never designed to work together.
Here's a common scenario: Plugin A updates and changes how it handles a particular WordPress hook. Plugin B relies on that hook behaving a specific way. Plugin B still works fine on its own. Plugin A still works fine on its own. Together, after the update, they break your site.
On a production site, that breakage is visible to everyone. On staging, it's visible only to your team, and production stays untouched.
High-risk plugin categories that we always test on staging:
- Page builders (Elementor, Divi, Beaver Builder, Bricks)
- WooCommerce and its extensions
- SEO plugins (Yoast, Rank Math, AIOSEO)
- Caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache)
- Security plugins (Wordfence, Sucuri, Solid Security)
- Form plugins (Gravity Forms, WPForms, Formidable Forms)
- Custom field plugins (ACF, Meta Box)
- CRM integrations and membership plugins
These plugins are deeply integrated into WordPress's core. An update to any of them can have cascading effects across your entire site. For a client like AIER, where we manage 75 active plugins across three interconnected sites with nearly 20,000 published content items, the potential for cascading conflicts is significant. A single plugin update on one site can affect the custom REST API that connects all three properties.
The Scenarios That Make Staging Non-Negotiable
Beyond routine weekly updates, there are situations where testing on staging is the only responsible approach.
The year of neglect. Someone who hasn't updated their site in a year hits "Update All." A site that's been without updates that long is exactly where staging should be used first. In development terms, that's a sandbox: a protected playground where you can discover what breaks before your visitors do.
We've inherited sites in this state, and the answer is never "click Update All and hope." It's always "create staging, test systematically, and identify what's going to break."
The plugin uninstall trap. Someone uninstalls a plugin, thinking they'll try a different one. A well-designed plugin deletes all its data on uninstall. That's actually good practice from a development standpoint, but it's devastating when the user expected the data to survive.
No auto-magic transfers data between plugins. On a staging site, you'd discover this before losing real data. On production, that data is gone.
The "it'll be fine" update. Developers always have a staging site. We call it our "local." We never develop on production, never test plugins on a live site. Even though that's not classic staging in the hosted sense, it shows that testing before deployment is fundamental to professional development.
If your provider is testing on your live site, they've decided your visitors are the QA team.
The Professional Update Testing Workflow
Here's how we handle updates for the WordPress sites we manage. This isn't a simplified tutorial. This is the actual process.
Step 1: Create a Fresh Staging Copy
Every testing cycle starts with a fresh staging site cloned from production. Not last week's staging site, not a staging copy that's been sitting around. A fresh copy that matches production exactly: same plugins, same theme, same content, same configuration. If you haven't set up a staging environment yet, start there before diving into update testing.
This matters because testing against an outdated staging copy means you're testing against a different website. The whole point of staging is environmental parity with production.
Step 2: Apply Updates One at a Time
This is where most people make a critical mistake. They click "Update All" to apply all pending updates simultaneously. When something breaks, they have no idea which update caused the problem.
Our approach: update one plugin at a time on staging. Test after each update. If something breaks, you know exactly which update is responsible. You can report the specific conflict to the plugin developer and make an informed decision about whether to apply the other updates while waiting for a fix.
For routine weekly maintenance where a dozen plugins have pending updates, one-at-a-time testing would be impractical. Automated testing handles that scale (more on that below). But for major version updates, particularly WordPress core, page builders, and WooCommerce, one-at-a-time is the standard. Sites on hosts without built-in staging can use staging plugins to achieve the same workflow.
Step 3: Test What Matters
After applying updates on staging, here's what gets checked:
Visual checks:
- Homepage renders correctly
- Key landing pages and service pages display properly
- Blog listing and individual posts look right
- Navigation works on desktop and mobile
- Footer displays correctly
We've caught page builder rendering issues during visual checks that were invisible in error logs. A plugin update can change how a shortcode renders without throwing an error, and the only way to catch it is to look at the page.
Functional checks:
- Contact forms submit and send notifications
- Search returns results
- Login and registration flows work
- Shopping cart and checkout (if applicable)
- Member portal access (if applicable)
- API integrations respond correctly
For sites with complex form systems, like the 43 Gravity Forms we manage for ACA, form testing after updates is critical. A form plugin update that changes the handling of conditional logic can silently break forms that worked fine last week.
Technical checks:
- PHP error logs reviewed for new warnings or fatal errors
- Console errors checked in browser developer tools
- Page load performance compared to pre-update baseline
- No mixed content warnings
SEO checks:
- Meta tags still present and correct
- Structured data still validates
- Redirects still function
- Sitemap generates properly
Step 4: Document and Decide
After testing, one of three things happens:
Everything passes. The updates are applied to production in the same sequence, following your staging to production deployment process, and the staging site is destroyed.
Something breaks, but it's minor. We identify the specific plugin update causing the issue, roll it back on staging, and apply all other updates to production. The problematic plugin is investigated separately, often by reviewing its changelog, support forums, or contacting the developer.
Something breaks significantly. No updates get applied to production. We investigate the root cause, determine whether a fix is available, and plan an alternative path forward. Production stays completely untouched and unaffected.
In every scenario, the important thing is that production was never at risk.
Automated Testing vs. Manual QA
We use both, and they serve different purposes.
Automated Testing: The Weekly Workhorse
For routine weekly updates, we use SafeUpdates, an automated system provided through Cloudways, our hosting partner. Once a week, on a schedule, it creates a staging site from production, applies all pending updates, and runs multiple layers of testing: log file review and regression testing on key pages.
If everything passes, those same updates run on production, and the staging site is destroyed.
A human never sees the staging site unless something fails. When something does fail, the updates are not applied to production. They only ran on staging, so no harm done. We get an automated email, investigate manually, and step through updates to identify the issue.
Often, the failure is something non-catastrophic, like a premium plugin whose license key didn't carry over to staging, or a minor deprecation warning in the PHP error logs. But sometimes it catches a genuine compatibility conflict that would have broken the site.
This is fundamentally different from WordPress auto-updates. Auto-updates apply changes directly to production with no testing. When they work, you don't notice. When they don't work, your site is broken, and you're in detective mode trying to figure out what happened.
The difference in outcomes is dramatic. Sites with auto-updates enabled during the WordPress 6.9 launch experienced WooCommerce checkout failures, broken SEO metadata, and Elementor rendering issues. Our clients were unaffected because SafeUpdates caught the conflicts on staging before they ever reached production.
Manual QA: The Deep Dive
Automated testing catches many problems, but it can't catch everything. Automated tests verify that pages load and don't throw errors. They don't verify that a form's conditional logic still works correctly, that a specific page builder widget renders its content as expected, or that a custom integration still processes data properly.
Manual QA is essential for:
- WordPress core major version updates
- Page builder major updates
- WooCommerce major updates
- Any update that changes how content is rendered
- PHP version upgrades
- Updates to plugins that handle payment processing, CRM integration, or member authentication
For sites with complex integrations, like an association with SAML SSO authentication and 43 Gravity Forms, or a medical certification board running online exams across five interconnected sites, manual verification after updates is non-negotiable.
WordPress Core Updates Deserve Extra Attention
WordPress core updates come in two flavors: minor releases (6.7.1, 6.7.2) that fix bugs and security issues, and major releases (6.8, 6.9) that introduce new features and potentially change how WordPress works internally. For a deeper look at the distinction, see our guide to WordPress core updates: major vs minor versions.
Minor releases are generally safe and focused on patches. We still test them on staging, but they rarely cause problems.
Major releases are where the risk lives. New features can change hooks, deprecate functions, modify the REST API, or alter how the block editor behaves. Plugins that relied on the old behavior may break.
Our protocol for major WordPress core updates:
- Wait 3-5 days after release. Let the early adopters find the problems. Plugin developers need time to release compatibility patches.
- Read the changelog and developer notes for the release.
- Check that all critical plugins have confirmed compatibility with the new version.
- Create a fresh staging environment from production.
- Apply only the core update first, before any plugin updates.
- Run a full manual QA cycle on staging.
- If the core update passes, then apply pending plugin updates one at a time.
- After everything passes on staging, deploy to production.
- Monitor production closely for 24-48 hours after the update.
Rushing to apply a major WordPress core update on release day is unnecessary and risky. The update will still be there next week, and you'll benefit from any emergency patches released in the interim.
PHP Version Upgrades: Non-Negotiable Staging
PHP upgrades are where staging is absolutely non-negotiable. There is no safe way to upgrade PHP on a production server without testing first. Our complete WordPress PHP version upgrade guide covers the full process.
When PHP releases a new version (e.g., moving from PHP 8.1 to 8.2, or 8.2 to 8.3), functions may be deprecated or removed, behavior may change in subtle ways, and older code that worked fine on the previous version may throw warnings or fatal errors on the new version.
How we handle PHP upgrades:
We stage the site on a server running the newer PHP version. All testing happens there, including a full manual QA cycle and error log review. If everything works, traffic gets redirected to the new server instance. The staging site effectively becomes the new production environment.
This approach avoids the risk of upgrading PHP in place on a running production server. If the new PHP version reveals incompatibilities, production is completely unaffected because it's still running on the original server with the original PHP version.
What to watch for during PHP upgrades:
- Deprecation notices in error logs (functions that still work but will be removed in future PHP versions)
- Fatal errors from removed functions (functions that existed in the old PHP version but are gone in the new one)
- Changed default behaviors (stricter type checking, modified function signatures)
- Plugin compatibility issues (older or abandoned plugins are the usual culprits)
- Custom code that uses PHP features that changed between versions
Theme Updates: The Hidden Risk
Theme updates get less attention than plugin updates, but they can cause significant visual breakage, especially on sites with customizations. For the sites we build, we use custom themes or child themes with template overrides, which means a parent theme update can silently break the visual output without triggering any error.
We've seen theme updates change CSS class names that our custom styles targeted, rename widget areas so content disappeared from sidebars, and modify template structures that child theme overrides relied on. None of these produces PHP errors. They just make the site look wrong, and you only catch them when you look at the site on staging after the update.
What theme updates can break:
- Custom CSS that targeted specific class names or HTML structures, the theme changed
- Child theme template overrides that no longer match the parent theme's template structure
- Customizer settings that get reset or overridden
- Widget areas that get renamed or removed
- Custom page templates that conflict with new theme templates
- Responsive breakpoints that changed
Our testing protocol for theme updates on staging:
- Check all pages that use custom templates
- Verify custom CSS still applies correctly
- Test responsive behavior at all breakpoints
- Confirm widget areas are intact
- Verify customizer settings are preserved
- Check that child theme overrides still function
What Auto-Updates Get Wrong
WordPress introduced auto-updates as a convenience feature. The idea is reasonable: apply security patches automatically so sites stay protected. The problem is what auto-updates skip: the testing step.
Auto-updates apply changes directly to your production site. There is no staging copy, no testing, no verification. When the update is compatible with your specific plugin combination, you never notice.
When it isn't, your site is broken, and you have no idea which update caused the problem, when it happened, or how long visitors have been seeing a broken site.
The WordPress 6.9 launch is the clearest example. Sites with auto-updates enabled experienced WooCommerce checkout failures, broken SEO metadata, and Elementor rendering issues, sometimes all at once. Emergency patches from plugin developers followed within days, but for sites that auto-updated on day one, the damage window was real. Our clients were unaffected because every update ran through staging first.
The distinction matters from an update testing perspective: auto-updates are a deployment strategy that skips testing. Staged updates are a testing strategy that includes deployment. They're not two versions of the same thing.
One treats updates as safe until proven dangerous. The other treats updates as unverified until proven safe. After managing updates across 200 sites for years, we can tell you which approach holds up.
Building Update Testing Into Your Regular Workflow
Update testing shouldn't be a special event. It should be part of your regular maintenance cycle.
Weekly: Automated staging-based testing for all pending plugin, theme, and minor core updates. This runs on a schedule without human intervention, except when a failure is detected.
Monthly: Review error logs and performance metrics to identify any degradation that might be related to recent updates.
Quarterly: Review the plugin stack. Are there plugins that haven't been updated in over a year? Are there plugins that could be consolidated or removed? Fewer plugins mean fewer update conflicts. For a network like the National Peace Corps Association's 50 sites, where we maintain a standardized plugin stack across every affiliate, the quarterly review ensures consistency and catches abandoned plugins before they become security risks.
Per major release: Manual testing cycle for WordPress core major versions, page builder major updates, and WooCommerce major updates.
This cadence keeps sites current without exposing them to unnecessary risk. It's the practice behind the promise that professional WordPress management delivers: your site stays updated, secure, and stable without ever breaking.
For more on integrating staging into your overall WordPress maintenance workflow, including the testing checklists and verification protocols we use, read our staging environment best practices guide.
Want Update Testing That Actually Protects Your Site?
If your current provider applies updates and hopes for the best, your live site is the test environment. Learn about our WordPress maintenance services and how every update gets tested before it touches your production site.