Digitalisierung

WordPress Maintenance & Operations: planned, not firefighting

1. The invisible part that decides everything

No one gets an award for a maintained WordPress site. Maintenance is the invisible part — and in mid-sized companies it's the first thing cut when the budget gets tight. Right up until the day the site stays blank after an update and no one knows how to get yesterday's state back.

We run this ourselves, not in theory: staging, monitoring that warns us before the client does, automated backups that get restored regularly — for our own sites and client projects. This article is the honest version of what operating actually means.

It's the operational deep dive into the WordPress Enterprise Guide. If the security side weighs on you more, read WordPress Security alongside it — operations and security are two sides of the same coin.


2. The four pillars of operation

Operation isn't a vague "taking care of things." It's four concrete pillars: updates, backups, monitoring, and staging. If one is missing, the other three don't hold.

The four pillars — one is missing, all wobble Updates Core, theme, plugins current closes known holes Backups tested, not merely present the emergency exit when everything burns Monitoring Uptime, speed, certificates you know it, not the boss Staging identical copy for testing no more testing in production Updates without staging is roulette · backups without a test is hope The pillars only work together — individually they're a false sense of security Source: Medienstürmer

3. Updates: not whether, but how

The most common question in mid-sized companies: "Do we really have to update every plugin?" The honest answer: not every update immediately — but every security-relevant one promptly, and you have to know which those are.

The reflex "better not touch it, it runs" is understandable but wrong. A site that isn't updated is not stable, it just hasn't been noticed yet. Outdated plugins are the most common point of entry for automated attacks — the holes are publicly documented.

The right approach is "controlled updating": apply it to staging first, click through the core flows there (homepage, form, login, checkout), and only adopt it in production after a successful smoke test — with a fresh backup beforehand. That turns the risk into a reversible routine.

When NOT to update immediately: for large major versions of central plugins (page builder, shop, multilingual setup) it's worth waiting a few days until follow-up bugs are reported and fixed — but only if it's not a security update. Security updates have no waiting period.

4. Backups: the only thing that counts in an emergency

This is where the most dangerous blind spot in mid-sized companies sits. Almost every site has "backups." Almost none has an ever-tested restore. In an emergency, that's the difference.

A backup consists of two parts, both of which must be complete: the files (core, theme, plugins, uploads) and the database (content, settings, users). If one is missing, it's worthless. We've seen cases where the database was backed up for months but not the upload directory — that only surfaces when you want to restore and all the images are gone.

The rule we work by: a backup whose recovery hasn't been tested does not exist. We restore backups on a schedule in isolation and check whether the site comes up completely. That sounds like effort — until the day it's the difference between "twenty minutes of downtime" and "three days and a lost client."

"Backup present" is not "backup works" The fallacy "We have a backup plugin" → never restored → DB saved, uploads not → only surfaces in an emergency The practice that holds files + database complete stored externally, versioned automated, daily restore tested on a schedule An untested backup is not a backup It's a hope in file form — and the emergency is the wrong time to find that out Source: Medienstürmer

5. Monitoring: so you know first

The worst way to find out the website is down is a phone call from the boss. Monitoring makes sure you know before everyone else — and can react before anyone notices.

Sensible monitoring covers more than "the page responds." It checks reachability from several regions, the response time (slow pages are an early warning sign, not a comfort topic), the expiry of the SSL certificate (an expired one locks out visitors with a browser warning — completely avoidable), and ideally a content check: does the page show not only HTTP 200 but also the expected content? A hacked or emptied-out page often dutifully returns a 200 — and still garbage.

We run exactly this setup for the sites we look after. The value isn't in the dashboard but in the alert at the right moment.

6. Staging: the insurance you take out beforehand

Staging is a complete, separate copy of your live site for testing before real visitors see the change. It's the pillar most often missing in mid-sized companies — because it's seen as "double the effort." In fact it's the opposite: the only pillar that prevents the other three from letting you down at the wrong moment.

Without staging there's only one environment — every test runs in production, in front of real customers, with real revenue at risk. With staging, every risky operation — a big update, a theme rebuild, a new plugin, a PHP version jump — is run through on a copy first. If it doesn't work there, no one but you has seen it.

When staging is less critical: for a never-changing business-card site with no forms, shop, or editorial work, the effort is hard to justify. But as soon as content or updates are added regularly — the case for almost any business-relevant site — staging is not an option but basic equipment.

7. Do it yourself or outsource — the honest math

We answer this without a sales interest: you can do a lot yourself. Test updates on staging, set up backups, set up uptime monitoring — that's learnable and doable for a motivated internal team.

The point at which outsourcing becomes cheaper isn't technical but organizational. It's reached when (a) no one internally is clearly responsible and so it factually doesn't happen, (b) the person who can do it is a single point of failure who is on holiday or sick, or (c) the internally spent time is more expensive than a maintenance contract and is being taken away from more valuable work.

Our honest recommendation: if you have an internal team that does it reliably and documented — do it yourself, keep control. If "someone sort of does it" is the status, then no one does it, and outsourcing isn't convenience but risk management. The platform question behind it is covered in the Enterprise Guide; if the need goes beyond a CMS, the Guide to Custom Software Development is worth a look.

8. Conclusion

WordPress operation is invisible until it's missing — then it's the most expensive thing about the website. The four pillars only work together: updates without staging is roulette, backups without a tested restore is hope, monitoring without reaction is decoration.

You don't have to outsource everything, but you do have to make an honest decision: is there a named person responsible who does it reliably and documented? If yes — do it yourself. If the answer is "someone sort of does it," then no one does — and you only notice that in an emergency.

9. Next steps

Want to know whether your WordPress operation stands on four pillars or on hope? We operate staging, monitoring, and tested backups ourselves, every day. Let us take an honest look at your setup — before the emergency exposes the gap.

10. Sources