8 Reasons WordPress Updates Keep Breaking Your Site

Published 8 November 2026 · Last updated and fact-checked November 2026

Short answer: WordPress updates keep breaking a site when its plugin stack is crowded, partly abandoned or untested. Of 6,942 WordPress.org plugins with 1,000 or more installs, 25.1% had no update in 12 months (WordPress.org API). If the site is down, restore a backup or use Recovery Mode. Fix the named cause first. Rebuild or migrate only when breaks continue.

Key takeaways

• Of 6,942 WordPress.org plugins with 1,000 or more installs, 1,744 (25.1%) had no update in 12 months, and 17.7% had none in 24 months (WordPress.org plugin API).

• 32.4% of WordPress sites run a PHP branch older than 8.2 (WordPress.org PHP statistics), and PHP.net lists no support for any of them.

• Patchstack counted 11,334 new WordPress vulnerabilities in 2025, 91% in plugins, with a 5 hour median to mass exploitation (Patchstack, 2026), so switching updates off trades one risk for a worse one.

• WordPress 6.6 rolls back an auto-update only on a PHP fatal error on the homepage (WordPress Core, 2024). A broken form or layout stays live.

• No peer-reviewed study measures WordPress update failures, so the closest evidence comes from studies of Java and JavaScript libraries.

1. Too many plugins touch the same pages

Every plugin hooks into the same WordPress page load, so each one you add creates new pairs that can collide. Ten plugins make 45 possible pairs. Sixty-five make 2,080. Nobody has published a failure rate for those pairs, so read the count as exposure. I review past about 30 plugins, a rule of thumb, not a measured line.

• What goes wrong: two plugins load different versions of one script, or both rewrite the same form

• The arithmetic: n plugins make n x (n - 1) / 2 possible pairs

• Who gets here: sites that added one plugin per request for years

• First check: deactivate anything no page or person has used in 90 days

Plugin count gets blamed too quickly, and also dismissed too quickly. A well-kept site can run 40 plugins for years. What the count changes is how many things must stay compatible at once, and how long it takes to find the one that failed. When a release breaks a 12-plugin site, you have 12 suspects. On a 65-plugin site you have 65, and the hours spent finding the one that failed are the real cost.

Research on software ecosystems describes the mechanism. Christopher Bogart and colleagues studied how a breaking change in one package creates rework for everything that depends on it, and how each software community decides who carries that cost. A WordPress site owner is as far downstream as it gets, because a marketing lead cannot negotiate with 40 separate plugin authors.

So the fix is subtraction before anything else. Sort the plugin list into three piles: runs the business (forms, CRM sync, checkout), helps a bit (a slider, a social feed), and nobody knows. The third pile goes first, on a staging copy.

"breaking changes may ripple through the ecosystem and trigger rework for users of a package," wrote Bogart, Kästner, Herbsleb and Thung in ESEC/FSE, 2016.

2. Some of your plugins are no longer maintained

A plugin with no recent release stops adapting while WordPress and PHP keep moving, so the next core update can break it. In my WordPress.org directory pull, 25.1% of plugins with 1,000 or more installs had no update in 12 months. According to the same pull, it was 6.8% among the 1,000 most installed plugins.

• Sample: 57,429 unique plugins read from the WordPress.org API on 8 November 2026

• No update in 24 months: 17.7% of plugins with 1,000 or more installs

• Not tested on WordPress 6.9 or newer: 27.2% of plugins with 1,000 or more installs

• Current WordPress: 7.1, on 65.6% of sites

• First check: open each plugin's WordPress.org page and read "Last updated"

Popularity protects you, up to a point. Only 3.0% of plugins with 100,000 or more installs went a year without a release, against 49.8% of everything I sampled (WordPress.org API). The danger zone is the middle: the niche plugin someone installed in 2021 to do one job, used by a few thousand other sites, written by one person who has since moved on.

An old date is not proof of a problem. A small, finished plugin can be fine for years. I treat 12 months as a prompt to look and 24 months as a prompt to replace, because by then WordPress has shipped several major versions the author never tested against. According to my pull, 1,891 plugins with 1,000 or more installs declare no testing on WordPress 6.9 or newer.

Abandonment also has a security cost. Jukka Ruohonen's study of WordPress plugins found that popular plugins collect multiple vulnerabilities, which means a widely installed plugin that stops shipping fixes is the worst combination. Write the last-update date beside every plugin in a shared sheet and review it each quarter.

"plugins with large installation bases have been affected by multiple vulnerabilities," Jukka Ruohonen reported at EASE, 2019.

3. The page builder ties everything to one version

A page builder sits between WordPress and every page you publish, so one builder update can reach the entire site at once. A free builder, its Pro plugin and third-party add-ons all have to agree. That stack is common: HTTP Archive detected Elementor on 86,228 US sites in September 2026.

• Layers to line up: WordPress core, builder, Pro plugin, each add-on

• Rollback path in Elementor: Elementor, then Tools, then Version Control

• Where free rollback tools stop: WP Rollback covers WordPress.org plugins, not paid ones sold elsewhere

• Related speed data: my Elementor and SEO check

The reason builders feel worse than other plugins is reach. If a contact form plugin fails, you lose a form. If the builder fails, headers, footers and every template can lose their layout in one release, and the editor you would use to repair them can fail with it.

Paid add-ons are the weak joint. They update on their own schedule, from their own servers, so a builder release can reach you before the add-on is ready for it. WP Rollback describes itself as working on WordPress.org plugins, themes and blocks, so a paid add-on bought elsewhere usually needs its old file from the vendor's account page. Find out where those files are before you need them.

The practical rule is to treat the builder, Pro and add-ons as one unit. Update them together, on a staging copy, and open the five templates that carry the most traffic. Never let the builder auto-update alone. If three or more add-ons exist only to patch things the builder cannot do, that stack is a rebuild signal, which the decision table further on covers.

4. The server runs an unpatched PHP version

PHP is the language WordPress and its plugins run on, and an old version leaves plugins with nowhere to go. WordPress.org's statistics show 32.4% of sites on a PHP branch below 8.2, and 14.5% still on PHP 7.4. PHP.net lists support only for branches 8.2 to 8.5.

• Below PHP 8.2: 32.4% of WordPress sites

• On PHP 8.2: 22.6%, and security support ends 31 December 2026

• Safest target today: PHP 8.3, supported to 31 December 2027

• Where to check: Tools, then Site Health, then Info, then Server

An old PHP version breaks sites in two directions. Plugin authors raise their minimum version, so an update may refuse to run or may fail on code your server cannot read. According to the WordPress.org API, 4,920 plugins already require PHP 8.0 or newer. Move the server too far ahead without testing, and old plugins fail for the opposite reason: PHP 8 removed behaviour that code written for PHP 7 relied on.

So the host setting and the plugin list have to be planned together. The PHP version often lives in a hosting panel the marketing team has no login for. That is why a site can run for years and then, one Tuesday, fail on a plugin update that assumed a newer server.

According to PHP.net, PHP 8.2 loses security support on 31 December 2026, and another 22.6% of WordPress sites then fall out of coverage. Clone the site to staging, switch it to PHP 8.3, and read the error log before you change anything live.

5. Auto-updates only check for fatal errors

WordPress can reverse a bad plugin auto-update, but only when the update causes a PHP fatal error on the homepage. Since WordPress 6.6, one loopback request decides. A contact form that stops sending, a checkout that fails or a layout that collapses returns no fatal error, so the update stays.

• Added in: WordPress 6.6

• What it checks: one request to the homepage

• What it reverses: a plugin auto-update that causes a PHP fatal error

• What it misses: forms, checkout, tracking, layout, inner pages

• Manual updates: rollback covers a failed install, not a successful update that misbehaves

This is the part most fix-it guides skip, and it explains the email every site owner dreads: the site was updated and something is now wrong. The safety net is real and narrow. It was built to stop a white screen, which is the worst outcome and the easiest one to detect.

Lead capture is what a marketing team actually loses. A form plugin can update cleanly, return a normal homepage and stop passing leads to the CRM for a week. Nobody gets an alert, because from the server's view nothing failed. I treat lost form submissions as the most expensive kind of update failure for exactly that reason.

WordPress's older rollback for manual updates has the same shape: it restores the previous version when an install fails, and the core team says it is not for reverting a successful update. So I leave auto-updates on for security releases and small utility plugins, and turn them off for anything that touches forms, checkout, the builder or tracking.

"Rollback Auto-Update performs a loopback request to the homepage to check for PHP fatal errors," wrote Andy Fragen in the WordPress Core merge proposal, 2024.

6. Custom code and template copies fall behind

Custom code assumes a plugin will keep behaving as it did on the day someone wrote it. Template overrides are the clearest case, because a copied file stops receiving changes. In Java libraries, researchers found about one third of releases introduced a breaking change, though a later replication found far fewer clients were affected.

• Usual suspects: child theme files, code snippets, WooCommerce template copies, custom plugins

• Where WooCommerce flags it: the System Status report

• Evidence limit: the studies cover Java libraries, not WordPress

• First check: list every override and who wrote it

The WooCommerce documentation is direct about this. Copy a template into your theme to change it, and your copy stops following the original. Each store release moves further from the file you froze, until a checkout field or an order email quietly stops matching what the plugin expects.

Snippets are harder to spot, because they hide in a theme's functions file or a snippets plugin with no owner's name on them. A developer who left in 2022 may have written code against a function that the plugin has since renamed.

The academic evidence needs a fair reading. Steven Raemaekers and colleagues found that about one third of Maven releases contained a breaking change. Lina Ochoa and colleagues repeated the work on 119,879 upgrades and found only 7.9% of clients were affected. So a change can be technically breaking and still harm nobody, unless your code happens to use the part that moved. Custom code is what puts you in that minority. Before a large update, search the codebase for every function the customisation calls, and keep a list of what each piece does and who to ask.

"WooCommerce core templates will update, but your custom overrides will not," stated WooCommerce's template structure documentation.

"We find that around one third of all releases introduce at least one breaking change," wrote Raemaekers, van Deursen and Visser in the Journal of Systems and Software, 2017.

7. Nobody tests updates before they go live

Most repeat breakage is a process gap: updates go straight to the live site with no copy to test on and no named owner. Kula and colleagues found 81.5% of over 4,600 studied GitHub projects kept outdated dependencies, a similar habit outside WordPress. A staging pass and a short test list close most of that gap.

• Cadence: security releases as they ship, everything else monthly

• Batch size: builder stack alone, then the rest in groups of five

• Test list: homepage, top landing page, every form, tracking fires, checkout if you sell

• Owner: one named person, with a backup

• If it fails: Recovery Mode gets you into the admin; a backup gets you back

Skipping updates feels safe and is not. Patchstack counted 11,334 new WordPress vulnerabilities in 2025, with heavily exploited flaws reaching mass exploitation in a median of 5 hours (Patchstack, 2026). So the choice is never update or don't. It is update with a test, or update blind.

Why teams skip the test is well documented. Raula Kula and colleagues surveyed developers, and 69% of those interviewed said they were unaware of their vulnerable dependencies. They also found updates get pushed aside because they feel like extra work. A marketing team has even less reason to treat updates as its job, and that is how a site ends up with nobody in charge of it.

When something does break, WordPress has a real recovery tool. Since version 5.2, a fatal error triggers an email to the site admin with a secret link into Recovery Mode, which pauses the failing plugin for that login only. Check that the admin address is one somebody still reads, because that email is the only warning you get.

"It is impossible to automatically fix such errors, but recovery mode allows working around them by pausing the broken extensions," stated WordPress Core's 5.2 announcement.

"developers are not likely to prioritize a library update, as it is perceived to be extra workload and responsibility," wrote Kula, German, Ouni, Ishio and Inoue in Empirical Software Engineering, 2018.

8. The plugin's owner or source changed

A plugin can change hands, change update source or be forked with no action on your part, and the next update may then carry different code. The clearest recent case came in October 2024, when WordPress.org forked Advanced Custom Fields into Secure Custom Fields. I treat a plugin's update source as a dependency that can move.

• Case on record: Advanced Custom Fields to Secure Custom Fields, October 2024

• Directory rule used: point 18 of the plugin guidelines

• Unfixed at disclosure: 46% of vulnerabilities in 2025

• First check: record the author and update source for every plugin

Advanced Custom Fields shows 2,000,000 active installs on WordPress.org today, so this was no small event. Matt Mullenweg's announcement says the ACF team announced on 3 October that updates would come from its own website, and on 12 October WordPress.org forked the plugin in the directory. Sites taking updates from the directory then got them from a different party.

The directory guidelines allow this. Guideline 18 reserves the right to change a plugin without the developer's consent in the interest of public safety (plugin directory guidelines). I take no side here. The point for a marketing lead is that a plugin's source is a dependency too, and it can move.

Quieter versions of this happen all the time: a plugin sold to a new company, a free tool reshaped around upsells, a developer who disappears. Patchstack reports that 46% of the vulnerabilities it tracked did not receive a fix in time for public disclosure (Patchstack, 2026). Ask for a named owner and an update source next to every plugin in your sheet.

"On behalf of the WordPress security team, I am announcing that we are invoking point 18 of the plugin directory guidelines," wrote Matt Mullenweg on WordPress.org News, 2024.

Should you stay, fix, rebuild or migrate?

Use the number of breaks after the fixes, not before them. Stay if the site breaks less than once a quarter. Fix if you can name the cause. Rebuild on WordPress if the builder stack is the cause and you need WordPress features. Migrate if it is a marketing site your team should edit alone.

The 90-day count matters more than it looks. A site that feels beyond saving may have only two or three named causes. My rule is to recommend a rebuild only when the breaks continue after that work, or when a redesign is already due and the money would be spent anyway. If you decide to leave, my guides to WordPress to Framer and WordPress to HubSpot cover the move, and Framer's running cost and whether HubSpot CMS is worth it cover the bill. Headless WordPress is rarely the escape it sounds like for a marketing team, since you still maintain WordPress and now run a front end as well.

How do you price staying against leaving?

No public study compares WordPress maintenance hours with hosted platforms, so measure your own. Add the hours spent on updates and repairs over 90 days, divide by three, and multiply by your loaded hourly rate. Compare that monthly figure with the rebuild price to get a payback period in months.

These are placeholders, not benchmarks. A site with 2 hours of monthly upkeep at the same rate would take far longer to pay back, and in that case staying is the right call. Count leads lost during outages only if you can show them in your CRM.

How I pulled the plugin data

I read the public WordPress.org plugin API on 8 November 2026 and kept each plugin's last update date, tested version and active installs. The API lists 74,368 plugins, and paging through it returned 57,429 unique ones. Install bands of 1,000 or more were complete, so I lead with those figures.

The directory percentages come from those 57,429 records, so the 49.8% all-plugin figure is a sample and may shift by a few points. Active installs are WordPress.org's rounded figures. Paid plugins sold outside the directory are not included, and a plugin with no recent release can still work. PHP and WordPress version shares come from the WordPress.org PHP statistics and version statistics endpoints, read the same day.

Frequently asked questions

These are the questions marketing leads and site owners ask most once updates start breaking things. Each answer gives the action I would take on a business site, with the WordPress setting or rule behind it. Where the honest answer depends on your plugin list, I say which fact decides it and where to find it.

Should I turn off WordPress auto-updates?

Not across the board. Keep them on for WordPress security releases and small utility plugins, because exploited flaws can spread within hours. Turn them off for your page builder, forms, checkout and tracking plugins, then update those monthly on a staging copy with a written test list.

How many plugins is too many for WordPress?

There is no safe number. Forty maintained plugins can run for years, while 12 abandoned ones can fail monthly. I start a review past about 30, because the possible conflicts climb fast. Count how many plugins have an owner, a recent release and a clear job.

How do I update WordPress plugins without breaking my site?

Back up first, then copy the site to staging. Update the builder stack alone, then the other plugins in groups of five. Test your homepage, top landing page, every form and your tracking. Deploy to the live site, then check everything again after 24 hours.

Can I undo a WordPress plugin update?

Yes, if you planned for it. Restore your backup, or install the previous version with WP Rollback for WordPress.org plugins. Paid plugins need the old file from the vendor. WordPress only reverses an update on its own when an auto-update causes a fatal error.

Should I move off WordPress because updates keep breaking?

Only if breaks continue after you fix the named causes for 90 days, and your site is mainly a marketing site. If you depend on WooCommerce, memberships or heavy custom content, rebuild on WordPress with fewer plugins. Moving platforms fixes maintenance, but puts redirects and rankings at risk.

Who should handle this for your team?

Give updates one named owner, inside the company or outside it, because shared responsibility is how sites end up unpatched. If the answer is a rebuild or a move, I run those projects as a solo founder at fixed prices from $3,250 to $14,999, and the first job is counting what actually breaks.

For Snappy Kraken I took a site from Figma to HubSpot in 21 days, and that work contributed to a 30% rise in marketing-qualified leads. That was a build, not a WordPress repair, so read the update advice here as my working method. Before you budget for anything, score the site you have. The Pipeline Leak Scorecard takes about 15 minutes with your site open, and it shows whether updates are your real leak or just the loudest one.

Sources

Peer-reviewed research

• Bogart, C., Kästner, C., Herbsleb, J., and Thung, F. (2016). How to break an API: cost negotiation and community values in three software ecosystems. ESEC/FSE. https://doi.org/10.1145/2950290.2950325

• Kula, R. G., German, D. M., Ouni, A., Ishio, T., and Inoue, K. (2018). Do developers update their library dependencies? Empirical Software Engineering. https://doi.org/10.1007/s10664-017-9521-5

• Ochoa, L., Degueule, T., Falleri, J.-R., and Vinju, J. (2022). Breaking bad? Semantic versioning and impact of breaking changes in Maven Central. Empirical Software Engineering. https://doi.org/10.1007/s10664-021-10052-y

• Raemaekers, S., van Deursen, A., and Visser, J. (2017). Semantic versioning and impact of breaking changes in the Maven repository. Journal of Systems and Software. https://doi.org/10.1016/j.jss.2016.04.008

• Ruohonen, J. (2019). A demand-side viewpoint to software vulnerabilities in WordPress plugins. EASE. https://doi.org/10.1145/3319008.3319029

Industry, vendor and public data (not peer reviewed)

• WordPress.org plugin API, read 8 November 2026: https://api.wordpress.org/plugins/info/1.2/

• WordPress.org PHP version statistics: https://api.wordpress.org/stats/php/1.0/

• WordPress.org WordPress version statistics: https://api.wordpress.org/stats/wordpress/1.0/

• PHP.net supported versions: https://www.php.net/supported-versions.php

• PHP.net, backward incompatible changes in PHP 8.0: https://www.php.net/manual/en/migration80.incompatible.php

• Patchstack, State of WordPress Security in 2026: https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/

• WordPress Core, Merge Proposal: Rollback Auto-Update (2024): https://make.wordpress.org/core/2024/04/19/merge-proposal-rollback-auto-update/

• WordPress Core, Rollback for failed manual plugin and theme updates (2023): https://make.wordpress.org/core/2023/07/11/new-in-6-3-rollback-for-failed-manual-plugin-and-theme-updates/

• WordPress Core, Fatal Error Recovery Mode in 5.2 (2019): https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/

• WordPress.org News, Secure Custom Fields (2024): https://wordpress.org/news/2024/10/secure-custom-fields/

• WordPress.org Detailed Plugin Guidelines: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

• WooCommerce template structure documentation: https://developer.woocommerce.com/docs/theming/theme-development/template-structure/

• Elementor, rollback to a previous version: https://elementor.com/help/rolling-back-to-a-previous-version-of-elementor

• WP Rollback on WordPress.org: https://wordpress.org/plugins/wp-rollback/

• HTTP Archive technology report (Elementor origins, September 2026): https://httparchive.org/reports/techreport/tech

• GoWP maintenance plan pricing, vendor price, read November 2026: https://gowp.com/maintenance-plan/

• Framer pricing, vendor price, read November 2026: https://www.framer.com/pricing