On this page
Ask ten business owners what website maintenance is, and nine will give you almost the same answer: update the software, take a backup, check the site hasn't gone down. And the frequency is a given: a monthly plan.
I understand why that view is so common. It's tidy, easy to quote, easy to put in a contract.
It's also wrong — and I'll prove it with a single number: 5 hours.
That's the median time between a vulnerability being disclosed and it being exploited at scale, according to Patchstack's State of WordPress Security in 2026 report: "the weighted median time to first exploit is 5 hours" (Patchstack).
Five hours. Your maintenance plan runs once every 30 days.
The question isn't whether you maintain your site. It's that you're running every task on the same clock — when they need four.
Why "monthly" is the wrong answer
Let's do the simplest math in this post.
A critical vulnerability is disclosed on the 3rd. Your maintenance plan runs on the 1st of every month. That means your site sits exposed for 29 days to something attackers start exploiting after 5 hours.
This isn't hypothetical. On September 22, 2026, WordPress shipped a patch for a vulnerability that allowed code execution. In under 5 hours, Patchstack's monitoring had already logged the first probes (Patchstack) — I covered it in detail in my CVE-2026-87902 analysis.
Meanwhile, that same monthly plan has you paying someone to check the copyright year in the footer twelve times a year. Something that changes exactly once a year.
That's the whole problem: you're too slow on the thing that can kill you, and too diligent on the thing that never changes.
The right question isn't "how often should we do maintenance?" It's: "Whose rhythm does this task run on — the attacker's, the platform's, the market's, or my business's?" Each answer is a different clock.
First: what your platform handles, and what it DOESN'T
This is the root principle, and it decides whether your task list is long or short.
Every platform takes care of part of the job. Squarespace, Shopify and Wix handle the servers, the CMS core, system security patches, SSL, the CDN and uptime. With self-hosted WordPress, you handle almost all of it — which is why WordPress maintenance is so much heavier.
But no platform handles these four things for you. They are always yours:
- Custom code — the JS/CSS someone bolted onto your site.
- Complete backups — something most SaaS platforms only half provide.
- Third-party scripts and integrations — pixels, forms, CRM, chat.
- Access — who holds the keys to your house.
Patchstack's numbers say exactly this. Of the 11,334 new vulnerabilities found in the WordPress ecosystem in 2025 (up 42% on 2024), 91% were in plugins, 9% in themes — and only 6 vulnerabilities were in WordPress core.
Read that ratio again. The core software is barely the problem. The things you, or your web agency, added on top are the problem.
And before you think "my host has a WAF": the same report found that in penetration tests, common defensive layers (hosting WAFs, Cloudflare) blocked only 26% of attacks — and for vulnerabilities already known to be exploited, just 12%.
The four clocks
This is the framework I use to design every maintenance plan. Not one schedule. Four parallel rhythms.
Clock 1 — Security & access: runs on the attacker's time
Rhythm: as soon as a patch exists, no waiting for the schedule. Plus a quick review every month.
This is the only group that must never sit on a fixed schedule. Specifically:
- Apply security patches within 24–48 hours, not "at the next maintenance window". Turn on automatic updates for security patches and confirm they actually ran — by version number, not by feel.
- Review who has access. Is your previous agency's Administrator account still there? Can the employee who left three months ago still log in?
- Check 2FA is still on for every account. It takes 5 minutes and they're the most valuable 5 minutes on the whole list. On SaaS platforms, the most common way in isn't a code vulnerability — it's an admin account.
- Compare the scripts running on the site against your inventory. An unfamiliar domain means someone injected code you don't know about.
- Check domain expiry and transfer lock. Losing your domain is far harder to recover from than losing your website.
Why does this group come first? Because VulnCheck's data shows that in the first half of 2026, 23.43% of known-exploited vulnerabilities had evidence of exploitation on or before the day the CVE was published (VulnCheck). In nearly a quarter of cases, the patch arrived after the attacker.
Clock 2 — Things that break silently: monthly
Rhythm: once a month. This is the part that genuinely is "monthly".
This is the group I'd argue holds all the real value of a maintenance plan — and it almost never comes up when the plan is quoted. What these items share: nobody tells you when they break. The site still loads, still looks good, still ranks on Google. The money just stops coming in.
From our own maintenance logs, the four quietest failures:
- Forms submitting into the void. The connection from a form to Mailchimp or Google Sheets drops after a while, with no warning. The only way to know: submit a test form yourself every month from an incognito window, and check the destination inbox — including spam.
- Custom code breaking quietly after a platform update. Nobody gets a warning. The page still loads; the button just doesn't work on mobile anymore.
- Tracking stops firing. GA4, GTM and the Meta Pixel stop recording events. You still open the weekly report, you still see a chart — but you're making budget decisions on dead data. (Directly related: the two September Google Analytics updates.)
- Missing redirects after a URL change. Changing a page's slug creates a 404 instantly. Many platforms don't create the redirect automatically. That page's backlinks and rankings evaporate without a sound.
On top of that: check for new 404s in Search Console, meta titles/descriptions for new pages and posts, alt text for newly uploaded images, unusually heavy images, and licence renewals for paid scripts.
Clock 3 — Performance, backups & technical SEO: quarterly
Rhythm: every three months, done properly.
Work that isn't worth doing monthly, but that piles up technical debt if you skip it entirely:
- A restore drill. Try rebuilding the site from the backups you actually have. This is the most-skipped task, and the most expensive one to have skipped. A backup that has never been restored isn't a backup — it's a file you hope is correct.
- Measure Core Web Vitals on real-user data (field data), not lab scores: LCP > 2.5s, INP > 200ms and CLS > 0.1 are the thresholds that need action.
- A deep audit of accounts and activity logs, not just the quick monthly check.
- Re-read all custom code and third-party plugins: still needed? Is the vendor still alive? Does the platform now have a built-in replacement? Dead code is a breakage risk every time the platform updates.
- Review alt text across the whole site, not just the month's new images.
Why does performance deserve its own clock rather than a "nice to have" line item? Google and Deloitte's Milliseconds Make Millions study, covering 37 brands and more than 30 million sessions, found that just a 0.1-second improvement in load time produced +8.4% conversion rate and +9.2% average order value for retail, and +21.6% more users progressing to the form-submission step for lead generation (web.dev).
One tenth of a second. That's the kind of gap a decent round of image optimization can close.
Clock 4 — Content & strategy: yearly
Rhythm: once a year, with a dedicated session.
- A content and SEO audit: pages with lots of impressions but few clicks get rewritten; dead pages get merged or removed, with redirects.
- Review the about page, legal entity details, team, and the year in the footer.
- A site-wide image sweep: crawl, flag heavy images, compress, replace, verify.
- Compare actual hours against quoted hours. If they're off by more than 30%, adjust the price or the scope.
One important note: major upgrades and platform migrations are NOT maintenance. They're a separate project, with their own scope and their own quote. Anyone folding them into a monthly maintenance plan has either never done one, or is under-pricing.
So how much time does it really take?
This is the part most articles on the subject avoid. I'll give you real numbers, from our own maintenance logs.
For a mid-sized SaaS site (Squarespace/Shopify, no complex e-commerce):
| Cycle | Actual time | Notes |
|---|---|---|
| Monthly | 1.5 – 2.5 hours | A stable month, no incidents |
| Monthly (complex) | 3 – 4 hours | Selling online, many scripts, lots of custom code |
| First month | Always longer | Building the inventory, no baseline to compare against |
| Quarterly (extra) | 2 – 3 hours | The restore drill takes ~1 hour of that |
| Yearly (extra) | 4 – 6 hours | The content audit is most of it |
For self-hosted WordPress, multiply the monthly workload by roughly 1.5–2x — because you're carrying the part a SaaS platform handles: core, plugin, theme and PHP updates, plus active security monitoring.
And here's the most important detail about those numbers: if you add up every item on our checklist, the total comes to around 5 hours. In practice it takes 1.5–2.5 — because most of it is checking and finding nothing.
That's the nature of maintenance, and it's why it's hard to sell: you're paying for the checking, not the fixing. Every "nothing to report" month is a successful month. The first month that catches a form that's been dead for three weeks is the month the plan pays for itself.
Where I got it wrong: years ago I sold a "1 hour/month" maintenance plan and thought I was being generous. I was wrong — but not because it was cheap. I was wrong because I put security checks on the same rhythm as swapping banner images. When a critical vulnerability landed between two cycles, nothing in my contract allowed me to act on it immediately. Now the security clause always sits outside the schedule: when a patch lands, it gets applied, billed separately.
Three questions to grade the maintenance plan you're buying
You don't need to be technical. Just ask three questions and listen to how they're answered:
- "If a critical vulnerability drops next week, how fast will you deal with it?" — The right answer is a timeframe (24 hours, 48 hours). The wrong answer is "at the next maintenance window".
- "When did you last try restoring my site from a backup?" — If never, you're paying for a file, not a backup.
- "What did you find last month?" — A good maintenance report always has a what we found and a what's still open section. If every month just says "updated, backed up, all normal", there's a good chance nobody is really looking.
The cost of running on the wrong rhythm
Let's bring it back to money, because that's what's worth discussing.
A compromised website doesn't just cost a few days of recovery. It costs rankings built over years, the trust of customers who were mid-checkout, and potentially legal liability if customer data leaks.
A form that's been dead for three weeks without anyone noticing is three weeks of prospects knocking on a door nobody opens. I run into this more often than actual hacks — and it never shows up in any alert.
What percentage of revenue is a page that's 0.1 seconds slower? Google and Deloitte already answered that above.
Maintenance isn't the cost of keeping your website from going down. It's the cost of keeping your website doing the job you paid for it to do. If the site goes down, you know within ten minutes. A site that's still up but has stopped producing customers — that's what quietly costs the most, and that's exactly what maintenance on the right rhythm catches.
If you remember one line from this post, make it this: don't ask "how often should we do maintenance?" Ask "whose rhythm does this task run on?" Security runs on the attacker's clock. Integrations run monthly. Performance runs quarterly. Content runs yearly.
Forcing all four onto a single schedule is the surest way to spend more and still not be safe.
Want to know which clock your website is leaking on? Send me your site's address — I'll review what's visible from the outside for free and tell you plainly what's missing. If the problem is speed and rankings, have a look at SEO & performance optimization.
