WordPress maintenance and support
WordPress maintenance that is more than clicking update.
Most maintenance plans are an automated update script and a monthly PDF. Nothing gets tested, nobody looks at the site afterwards, and the first person to notice a broken form is a customer. This is the version where a person checks, where risky updates get staged, and where the rollback path has actually been used before it was needed.
The honest version
A green uptime chart is not proof anything works.
Your site can return a perfect 200 on the homepage while the contact form silently fails, the search returns nothing and a plugin with a known vulnerability sits there for three months because it was two majors behind and the script skipped it.
What the cheap plan does
- Runs every available update at 3am, unattended
- Pings the homepage every five minutes and calls that monitoring
- Takes a backup nobody has ever restored
- Emails you a PDF listing what it clicked
What this does instead
- Triages updates by risk, tests the risky ones on a staging copy
- Monitors the journeys that make you money, not just whether the server is up
- Restores the backup to prove it restores
- Tells you in plain English what changed, what we chose not to do, and why
Scope
What WordPress website maintenance covers here.
Tested updates
Core, plugins, themes and PHP version, applied in a considered order. Anything that touches the theme, the checkout or a custom integration is run on a staging copy first and the key journeys are walked through by hand.
A rollback path that works
Files and database, versioned, with a restore that has been performed rather than assumed. Theme and custom code under Git so any change can be reverted cleanly instead of being unpicked by hand at 9pm.
Plugin vulnerability triage
Known CVEs checked against what you actually run. Abandoned plugins flagged before they become the story. Sometimes the right answer is not an update, it is removing a plugin doing 40 lines of work you no longer need.
Edge security
Bot and brute force mitigation at Cloudflare with challenge rules and an allowlist for your own team, honeypots on forms, REST API and XML-RPC restricted where they are not in use, HSTS and sensible response headers.
Monitoring that means something
Uptime, yes, but also whether the form submits, whether search returns results, whether SSL is about to expire and whether a template stopped rendering. Alerts that reach us, not just a dashboard nobody opens.
Caching and cache correctness
Edge, OPcache, object cache and transients checked against each other, purge rules checked against what editors actually do, and logged-in HTML kept out of the edge cache so nobody is served somebody else's page. Cache faults do not show up as downtime, so nothing in a standard plan looks for them.
Small changes, done properly
The queue of little jobs that never get done. A field added, a template tweaked, a redirect set up. Included hours go on whatever you actually need that month rather than being spent to look busy.
The silent failures
Two cache bugs that do not look like cache bugs.
These are the sort of thing a monthly update script will never catch, because nothing is down, nothing errors in a log you are watching, and the homepage still returns 200. Both are real, from a high traffic directory site we own end to end.
Bug one
A button that only failed on cached pages
A load more button worked fine in testing and failed for real visitors. The WordPress nonce was being baked into the HTML, and that HTML was then held at the edge for days. The nonce expires in 12 to 24 hours, so the AJAX endpoint kept rejecting it with a 403.
We proved it by comparing a nonce from a cached response against a fresh one. Different values, same page. No plugin update caused it and no monitor would ever have flagged it.
Bug two
Purge site cache does not clear OPcache
On Cloudways, the Purge Site Cache button does not touch OPcache. You have to restart php-fpm. Deploy a PHP change, purge, reload, and the old compiled code is still running, which looks exactly like a fix that did not work.
People then go and change the fix, which was correct in the first place. Knowing this about a specific host is the difference between a ten minute deploy and an afternoon of chasing a bug that was already dead.
Also on the list
Personalised HTML is guarded so logged-in users are never edge cached. That is a cache poisoning risk rather than a performance detail, and it is worth treating as a security item. On one site a security product, Imunify360 WebShield, was itself poisoning the cache and had to be disabled by the host. Neither of those gets found by clicking update.
Evidence
A brute force attack, and the server nobody needed to buy.
Security
21,626 hits a day to zero, in 15 minutes
An automated attack was hammering wp-login.php. It was absorbing roughly 46% of every request hitting the origin, which is an absurd share of a server's attention for one file that no genuine visitor loads that often.
Fixed at the edge with a Cloudflare Managed Challenge on that path, plus a skip rule allowlisting the admin IP so nobody legitimate got locked out. Attack traffic went to zero within 15 minutes.
The more useful half
Proving it was not the cause
The client had been told the site felt slow because of the attack and was about to pay for a bigger server. The origin was running at 7.5% CPU throughout. The attack was noisy, but it was not the performance problem.
So the honest answer was: block this because it is a security risk and it is wasting requests, and do not spend money on hosting you do not need. Saying that costs us an invoice and it is still the right call.
Plans
WordPress maintenance packages.
These are indicative and priced from our normal rates, which run £90 to £110 an hour for technical work and a £95 blended rate for mixed engagements. Every site is scoped individually, because a five page brochure site and a WooCommerce store with three integrations are not the same job.
Essential
From £190 a month
Around two hours. Tested updates, backups with a restore proven at least once, vulnerability triage, uptime and SSL monitoring, and a short note on what changed. Suits stable brochure sites that still need someone paying attention.
Standard
From £380 a month
Around four hours. Everything above, plus staged testing of risky updates, edge security hardening at Cloudflare, journey monitoring on your key forms and pages, and time for small changes. Suits most business sites.
Priority
From £760 a month
Around eight hours. Everything above, faster response when something is on fire, performance and Core Web Vitals watched for regressions, and enough time to actually build things. Suits ecommerce and sites with custom code.
Indicative only. Unused hours do not roll over indefinitely, and we will say so if you are on a bigger plan than you need. Time is logged as it is spent and the ledger is open to you. Full breakdown on the rates page.
Fit
Worth reading before you enquire.
Good fit if
- The site earns money and an outage costs you more than the plan does
- There is custom code, a modified theme, or an integration that would notice a bad update
- Nobody internally owns the site and updates have been sitting unapplied
- You have been hacked before, or you keep getting login attempt emails
- You want the people who maintain it to be able to build on it as well
Do not hire us if
- You want the cheapest plan on the market. There are £15 a month options and they are automated scripts. That is a fine trade if you understand you are making it
- Your site is a simple brochure on a good managed host with nothing custom. You may genuinely not need this
- You want 24/7 cover with a guaranteed response overnight. We work UK hours, so we will not promise that
- You want us to maintain something built in a page builder we did not choose, without being allowed to change anything about it
Tools
What we work with.
Nothing exotic. WordPress and PHP, WP-CLI for anything at scale, MySQL, Sage themes, Git and SSH, Cloudflare for the WAF, cache rules and API work, Cloudways, Redis and Object Cache Pro, OPcache, Nginx and Apache.
Take stock
What is running, what is out of date, what is exposed, and what has been bolted on over the years. You get this written down whether or not you go ahead.
Free 20 minute first callGet it to a safe baseline
Backups proven, rollback path tested, the urgent security gaps closed, and the update backlog cleared carefully rather than all at once. Quoted separately if there is a lot of it.
Scoped in writing firstKeep it there
Monthly cycle of triaged updates, monitoring and small changes, with a short plain English note each month. Cancel with a month's notice and you keep everything.
No lock inFAQ
Questions clients actually ask
What is actually in most WordPress maintenance plans?
An automated update script, an uptime pinger and a monthly PDF generated from a plugin. That is genuinely it for a lot of them. The report says 14 plugins updated and uptime 99.9%, which tells you nothing about whether anything broke.
The give away is that nobody looked at the site after the updates ran. If a checkout form stopped submitting on the 3rd, you would find out from a customer, not from the plan you are paying for.
Do you update everything, every time?
No, and that is deliberate. Updates get triaged. Security releases go on fast. Major version jumps on anything that touches the theme, the checkout or a custom integration get tested on a staging copy first, with the key user journeys walked through by a person.
Occasionally the right call is to hold an update and pin the version, usually when a plugin has just shipped a bad release. We will tell you when we have done that and why.
What happens when an update breaks the site?
It gets rolled back, then investigated. Every site on a plan has a rollback path that has been tested rather than assumed, and that includes the database, not just the files. A backup you have never restored from is not a backup, it is a hope.
Then we find out what actually conflicted and either fix it or hold that plugin until the author does.
Is a security plugin enough?
It helps, but a security plugin runs inside WordPress, which means PHP has already booted and your database is already involved by the time it makes a decision. Blocking at the edge is cheaper and happens before any of that.
Rate limiting, bot mitigation and challenge rules at Cloudflare, restricting the REST API and XML-RPC where they are not needed, HSTS, sensible headers and a login page that is not sitting wide open. The plugin then handles what is left.
My host says they handle maintenance. Do I need this?
Sometimes not, and we would rather you kept your money. Managed hosts do backups, server patching and often core updates well. What they do not do is judge whether a plugin update is safe for your specific customisations, or notice that a template quietly stopped rendering.
If you are a simple site on a good managed host and nothing custom is going on, you may not need a plan at all. Ask us and we will give you a straight answer.
Am I locked in?
No. Monthly, cancel with a month's notice, and nothing is held hostage. You keep your hosting, your domain, your Cloudflare account and your repository, all in your own name. If you leave, everything we built stays working without us.
Keep reading
Related services
Book me
Not sure what state your site is in?
Send us the URL. We will look at what is running, what is exposed and what has been left unpatched, then tell you whether you need a plan at all.