Nobody has logged in
since last year
The email from your host landed last Tuesday, flagged urgent, with a subject line about a "critical vulnerability" you never quite got around to opening. Logging into wp-admin told the rest of the story. Half the plugin list wears an orange badge, and a WordPress version that hasn't been updated in months. The agency that built it all has gone quiet since the final invoice cleared.
Calls like this reach us monthly. WordPress maintenance was part of the pitch once, but the builder moved on and day-to-day WordPress operations ended up belonging to nobody. No service agreement ever made it to paper.
Plenty of vendors still run upkeep as a monthly ritual: press "update all", hope nothing breaks, and send the invoice.
Hope is not an operating model.
Share of hacked CMS installs running WordPress
To spot an outage
Uptime guarantee on Pro
Per update, tested through CI/CD
Seven signs your WordPress maintenance is overdue
- 01
Core trails by more than one version. Running 6.4 while 6.7 is current means every hole patched in between is public record.
- 02
Orange update badges fill the plugin screen, and the ones on WooCommerce or Yoast matter most because customer data sits behind them.
- 03
Nobody can say who holds admin access. Past developers still do. So, probably, does the intern from 2023.
- 04
No restore has ever been rehearsed, and "the host handles backups" has never been put to the test.
- 05
The site keeps getting slower even though nothing changed. That is the database growing and idle plugins compounding, month after month.
- 06
Updates go straight to production because no staging environment exists. Tyre changes at motorway speed.
- 07
The agency that built the site has gone quiet — or insists the website is no longer their problem.
The anatomy of
a tested update
Every core or plugin update lands on a staging clone of production first, same database and same PHP 8.4 runtime. Then the gauntlet. Forms get submitted, checkout completes end to end, logins and API integrations are exercised, and a visual regression pass flags any layout drift.
Only on a fully green run does anything ship to production, pushed through CI/CD with WP-CLI — never the blue update button in wp-admin.
Run automatically, the whole cycle wraps up in under 15 minutes, where the same work done by hand swallows the better part of three. The vendor who simply clicks "update all" spends no time at all on it, which holds up nicely right until the day something breaks and the bill arrives with interest.
A white screen
at 03:14
A plugin update drags the whole PHP process down with it — or the server, for reasons nobody will discover until morning, simply stops answering. No warning, no error page. Just a white screen and a clock showing 03:14.
Sixty seconds later our monitoring has flagged the outage and woken the on-call rotation. A senior developer sizes up the damage and starts working the problem immediately, not at 09:00 when the office opens.
Most sites have no use for this, and we will say so unprompted: Basic or Pro serves the great majority of businesses perfectly well. The exception is revenue that never sleeps. Run an online store that sells while you are asleep, or a service customers expect to reach at any hour, and out-of-hours emergency cover stops being a luxury the first time you lean on it.
WordPress maintenance across three SLA tiers
The same site, kept and neglected
No WordPress site stays still. Left alone, the database swells with revisions while idle plugins quietly tax every single request the server handles, and after a year the gap is measured in whole seconds rather than milliseconds [1].
The platform underneath
FrankenPHP with a smarter cache
Defence in depth
Backups proven by restore
Uptime, watched
Inside a WordPress operations agreement
Maintenance and operations get used as synonyms, but they aren't quite the same animal. Maintenance is the task work. Operations means owning the outcome, week after week, with one party accountable for the whole site from launch onwards, no matter which plugin misbehaves. At PXL, an operations agreement bundles both into four standing routines.
Monitoring. Uptime probes fire every minute, so an outage means an alert inside 60 seconds rather than an angry email the next day. Vulnerability scans run daily and cover the whole install, core included.
Updates. No change touches production before staging and the automated test suite have signed off on it. Security patches skip the normal cadence and go out within 48 hours.
Backups and restores. Daily, with restore drills on a fixed schedule and the results checked by a person. An unrestored backup is a rumour.
Response time. The SLA commits us to numbers, from 8 hours on Basic down to 30 minutes on Enterprise. Escalation is agreed in writing before anything ever breaks.
If the budget is still an open question, start with what a WordPress website costs all in, and come back to operations afterwards. If something is on fire right now, emergency WordPress help is the door to knock on first, and the operations conversation can wait until the smoke clears.
Could you run this yourself?
A plain blog with no integrations is fair game to run yourself. The documentation on WordPress.org is genuinely good, and a fair chunk of the routine can be handed to WP-CLI on a cron schedule.
The real test is whether the work keeps happening week in, week out. That means reading the changelog before every update, understanding why WooCommerce 9.4 just broke a payment plugin that had behaved for three years, and being sure the latest backup will restore when you need it to.
Running a company is already a full-time job, and the hours are better spent there.
The arithmetic is sobering once you sit down with it. Cleaning up after a single security incident runs anywhere from NOK 15,000 to 80,000, and a webshop turning over NOK 50,000 a day can lose, in a single day of downtime, enough profit to have funded six months of an SLA. The dent in customer trust, meanwhile, never shows up on any invoice at all.