What Actually Breaks on a WordPress Site

Ask someone what they are afraid of happening to their website and they will describe a hack. Ask someone who maintains a portfolio of sites what actually goes wrong, and you will get a much duller list.

That gap matters, because the common WordPress problems that cost real money are almost never the ones people insure against. Dramatic failures announce themselves — the site is down, everybody knows within the hour, and it gets fixed. The expensive ones are quiet, and they run for months.

Here are the real ones, from sites we look after.

1. Someone changes something, entirely reasonably

A client’s marketing lead wanted to add a page. She installed a plugin to duplicate an existing one, chose a page as her starting point, and duplicated it. The site broke.

She had done nothing wrong. The plugin does exactly what it advertises. She was doing the thing the site was built to let her do — publish — and hit an edge nobody had anticipated.

We restored it from an earlier version seven minutes after she told us.

But the interesting part came two years later. The duplication had left residue in the site’s URLs: pages ended up on addresses with numeric suffixes appended to avoid collisions, and one page’s address described a completely different topic than the content on it. Nothing looked broken. No error, no alert, no complaint. It simply split that site’s search authority, quietly, for two years, until a routine check surfaced it.

The seven-minute fix was the cheap part. The two years were the expensive part.

2. Email that stops arriving and never says so

A store we maintain stopped receiving internal order notifications. Customer receipts were fine. The message telling the business that an order had come in was not.

Nothing appeared broken. Checkout worked, payments cleared, orders sat correctly in the database. The only symptom was fewer notification emails, which is indistinguishable from a quiet week.

The site was sending through the server’s default mail function, which keeps no send log. So the failures left no trace at all — there was nothing to find, because nothing was recorded. Moving to authenticated SMTP with logging fixed delivery and, more importantly, made the next failure visible.

Any system that can fail without writing that failure down somewhere will eventually cost you more than it should.

3. Slugs, redirects and the slow leak

Related to the first, and common enough to name separately. Pages get renamed. Pages get rebuilt. Somebody creates a draft, abandons it, and it holds the good URL hostage so the real page ends up on a worse one.

Individually, none of this breaks anything. Collectively, it is how a site ends up with three pages competing for one topic, a handful of URLs that describe the wrong content, and inbound links pointing at addresses that quietly 404.

Nobody reports it, because from the inside everything looks fine.

4. The plugin that stops being maintained

Not the plugin that breaks — the one that simply stops being updated. It keeps working, so nothing prompts you to act, right up until a WordPress or PHP release leaves it behind, or a vulnerability gets published against a version nobody is patching any more.

The dangerous case isn’t a plugin that fails. It is one that works perfectly while quietly becoming a liability.

5. Backups that were never tested

Almost everyone has backups. Far fewer have ever restored one.

An untested backup is a belief, not a safeguard. The failure modes are boring and completely fatal: the schedule silently stopped months ago, the backup covers files but not the database, it lives on the same server as the site it is protecting, or it restores into an error because nobody ever tried. The WordPress backup documentation is unambiguous that a backup you have not restored is not yet a backup.

The incident above resolved in seven minutes for exactly one reason — the restore worked, because it had been done before.

How to check for these yourself

Most of the common WordPress problems above can be checked in an afternoon, without a developer. If you do nothing else this month, do these five.

Restore a backup. Not verify one exists — actually restore it, to a staging copy. If you cannot, you do not have backups, whatever your dashboard says.

Send yourself a test order or enquiry. Then check it arrived at every address it was supposed to reach, including the internal ones nobody reads. This is the single highest-value ten minutes in the list.

Open your plugin list and look at the “last updated” dates. Anything untouched for over a year is a decision waiting to be made, even if it currently works perfectly.

Search Google for site:yourdomain.com. You are looking for pages you did not expect, duplicate versions of the same page, and URLs whose address does not match their content. That is where slug residue surfaces.

Click your own main navigation, on a phone. Not to admire it — to find the link that has quietly pointed at a 404 since the last rebuild.

None of this requires technical skill. It requires somebody to spend the afternoon, which is exactly the resource that runs out first — and why these common WordPress problems persist in sites whose owners are perfectly capable of finding them.

What this all has in common

None of these are exotic. There is no hack in the list, no catastrophic host failure, no zero-day. Four of the five produced no visible symptom at all on the day they started.

That is the actual argument for maintenance, and it is not the one usually made. You are not paying for someone to be available when the site goes down — you will notice that yourself, and so will everyone else. You are paying for someone to notice the things that never announce themselves.

Our WordPress Maintenance Plans exist for the quiet list, not the loud one.

And if you want to know which of these is currently true of your own site, our free website audit checks for most of them — thirteen checks, plain English, no obligation.