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 been used before it was needed.
The detail
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
- Updates triaged by risk, risky ones staged first
- Monitors the journeys that make you money
- The backup restored, to prove it restores
- What changed, what we skipped, 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 run for real. 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 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 together
- Purge rules tested against what editors do
- Logged-in HTML kept out of the edge cache
- Catches faults that never show up as downtime
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 need that month, not on looking 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
- Load more worked in testing, failed for visitors
- Nonce baked into HTML held at the edge for days
- Expired nonces drew a 403 from the AJAX endpoint
- Proved by comparing a cached nonce with a fresh one
Bug two
Purge site cache does not clear OPcache
- Cloudways Purge Site Cache leaves OPcache untouched
- Only a php-fpm restart clears it
- Old compiled code makes a good fix look broken
- Ten minute deploy, not an afternoon chasing a dead bug
Also on the list
Personalised HTML is guarded so logged-in users are never edge cached. That is a cache poisoning risk, not a performance detail, and it belongs in the security column. 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 hammering
wp-login.php - Roughly 46% of every request to the origin
- Blocked at the edge by a Cloudflare Managed Challenge
- Admin IP allowlisted so nobody legitimate was locked out
The more useful half
Proving it was not the cause
- Client about to pay for a bigger server
- Origin at 7.5% CPU throughout
- Noisy, but not the performance problem
- Advised against hosting it did not need
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 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
- An outage costs more than the plan does
- Custom code, a modified theme or an integration
- Updates sitting unapplied, and nobody owns the site
- Hacked before, or getting login attempt emails
Do not hire us if
- The cheapest plan, an automated £15 a month script
- Simple brochure site on a good managed host
- Guaranteed 24/7 response, since we work UK hours
- A page builder we did not choose and cannot change
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 10 minute first callGet it to a safe baseline
Backups proven, rollback path tested, the urgent security gaps closed, and the update backlog cleared carefully, not 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 ask
What is in most WordPress maintenance plans?
An automated update script, an uptime pinger and a monthly PDF generated from a plugin. That is all it is, 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, not 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 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 silently 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 clear 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.