What Actually Breaks WordPress Sites: Data From Real Rescues

Most “broken” WordPress sites trace back to just five causes: a plugin update gone wrong, a hack through an outdated component, a hosting failure, an end-of-life PHP version, or a small incident turned catastrophic by a missing backup. Hackers get the headlines, but routine neglect breaks far more sites — in 2025 alone, Patchstack logged 11,334 new WordPress vulnerabilities, and 91% of them were in plugins, not WordPress itself.

I’ve spent 7+ years fixing broken WordPress sites across 500+ client projects, and the same patterns show up on repeat — the causes rarely surprise me anymore, only the timing does. Here’s what actually breaks WordPress sites in 2026, backed by current data, and the specific habit that prevents each one.

What breaks WordPress sites most often?

Project after project, my emergency fix work lands in the same five buckets, in roughly this order:

Notice what’s missing: sophisticated attackers, mysterious server gremlins, WordPress core itself. Out of 11,334 vulnerabilities found in 2025, only six were in WordPress core. The platform is solid — it’s the stack of third-party code and skipped maintenance around it that fails.

Why do plugin updates break more sites than hackers?

A typical business site runs 20–30 plugins, each on its own release schedule, plus a theme, a page builder, and a PHP version underneath — every update is a compatibility roll of the dice across that whole stack. And the blast radius is huge: W3Techs data shows Elementor alone runs on about 31% of all WordPress sites, so a single bad builder release ripples across a third of the WordPress web overnight.

Auto-updates cut your security risk, but unattended they create a different failure mode: the update runs at 3 a.m., something conflicts, and nobody notices the broken checkout until customers start emailing. Most of the “my site suddenly broke” calls I get aren’t sudden at all — an automatic update fired days earlier and the site had been quietly failing since.

How do WordPress sites actually get hacked?

Almost never through a genius attack — hacks walk through doors that were left open. Patchstack’s State of WordPress Security in 2026 report puts numbers on how little margin there is: of the 11,334 vulnerabilities logged in 2025, 46% had no patch available when they were publicly disclosed, and the median time from disclosure to first exploitation attempt was five hours. Bots weaponize a published vulnerability faster than most owners read the update notice.

Sucuri’s hacked-website research shows the other side of the same coin: 39% of compromised sites were running outdated software at the point of infection, and 49% of cleaned sites contained at least one backdoor — meaning attackers had left themselves a way back in. That’s why a “cleaned” site that was never properly hardened so often gets reinfected within weeks.

Two more findings worth internalizing:

• Your host won’t save you. Patchstack’s testing found hosting-level defenses blocked only 12–26% of vulnerability exploits. Hosting security is a seatbelt, not a force field.
• Abandoned plugins are a time bomb. Over 1,600 abandoned plugins were closed on WordPress.org in a single year after unpatched vulnerabilities were reported — and removal from the directory doesn’t uninstall them from your site. If a plugin hasn’t been updated in a year, plan its replacement.

Is outdated PHP really a problem?

It’s the quietest way sites break. WordPress.org’s own statistics show roughly 18% of WordPress sites still run PHP 7.4 — a version that stopped receiving security fixes in November 2022 — and about a quarter run PHP 7.4 or older. Meanwhile around 44% of sites aren’t on the latest WordPress branch.

Old PHP breaks sites in two ways. Directly: it’s unpatched, slower, and a compliance problem. Indirectly, and more often: plugin developers eventually drop support for EOL versions, so one day a routine plugin update ships code your server literally cannot run — and the site fatals. The owner blames the plugin; the real cause is a PHP version that should have been retired years earlier. Upgrading PHP takes minutes on decent hosting and is the single cheapest fix on this list.

When is it the hosting, not WordPress?

A meaningful share of “WordPress problems” I’m hired to fix turn out to be hosting problems wearing a WordPress costume: memory limits killing image uploads, database connections dropping under modest traffic, mystery 503s at the exact hour a newsletter goes out. Bargain shared hosting oversells resources, and WordPress — being the layer you actually see — takes the blame.

Downtime isn’t just annoying; the real cost climbs quickly once lost sales, ad spend, and support time are counted. If your site matters to revenue, hosting is the wrong place to save a few dollars a month — I’ve written about why I moved my client sites to better hosting, and I offer managed hosting precisely because so many rescues end with a migration.

Why is the missing backup the real disaster?

None of the incidents above have to be serious. A broken update, a hack, even a dead server — with a current, working backup, each is an hour of inconvenience. Without one, the same incident is a rebuild. The pattern in my rescue work is consistent: the sites that suffer real damage aren’t the ones that got unluckiest, they’re the ones where the backup didn’t exist, lived on the same server that failed, or had never once been test-restored. Industry surveys keep finding the same thing — a large share of backups fail at the moment they’re actually needed, and in Kaseya’s 2025 State of Backup and Recovery report, 36% of organizations needed one to three days to fully recover.

DIY maintenance or a care plan?

Everything above is preventable with a boring weekly routine: staged updates, security monitoring, off-site backups, a supported PHP version, and someone who actually looks at the site. The only real question is who does it — you, or someone whose job it is. Honest comparison:

DIY is completely viable if you’ll genuinely do the routine — the checklist above is the whole job. If you’d rather not be the 3 a.m. responder, that’s exactly what my WordPress maintenance plans exist for.

7+ years of rescues, one conclusion: WordPress sites almost never break — they get broken by skipped maintenance, and every item on this list is cheap to prevent and expensive to fix. If you’d like your site checked against it before it becomes an emergency, book a free 30-minute call and I’ll take a look with you.