Jamie Spurrell
Table of Contents
Nothing, for a while. That is the whole problem.
An unmaintained website does not fail on a Tuesday with a bang. It degrades quietly for months while looking completely normal to the one person who checks it most, which is you. Then several things go wrong close together, usually at the worst possible moment, and the bill arrives all at once.
So the useful answer is not a list of risks. It is a sequence: what goes first, what goes next, and what each stage costs to put right. This is the order we tend to find things in when a client hands us a site nobody has touched in a year or two. Your mileage will vary with how the site was built and what it runs on, but the shape holds up remarkably well.
Weeks one to three: genuinely nothing
Skip a month of maintenance and there is no consequence at all. No slowdown, no break, no ranking change. The site you built is the site you have.
This matters more than it sounds, because it is the reason maintenance gets dropped. The feedback loop is broken. You stop doing the thing, nothing bad happens, and you reasonably conclude the thing was not necessary. Nobody ignores a maintenance plan because they think their website does not matter. They ignore it because three weeks of ignoring it looked fine.
Month two to four: the failures you cannot see
This is the expensive stage, and almost nobody writes about it, because it is not dramatic.
Somewhere in here, something on your site stops delivering and does not tell you. The usual suspect is your contact form. A plugin updates itself, or your host changes a mail setting, or a third-party service rotates an API key, and submissions quietly stop arriving. The form still says "thanks, we'll be in touch." It just says it into a void.
We have taken over sites where this had been happening for four months. From the owner's side there was no error, no bounce, no warning. Just a slow quarter they had put down to the market. The cost of that failure is not a repair bill, it is every inquiry that came in during those four months, and you never find out what was in them.
Booking widgets, payment buttons, and automated confirmation emails fail the same silent way. If you want to be sure yours are actually working, the practical checks are in our guide to making sure your website is really capturing leads. Doing that once a month by hand, sending yourself a test inquiry and confirming it lands, catches the single most costly failure on this whole list.
Month four to eight: visible wear
Now things start to show.
Pages get slower as image-heavy content accumulates and caching drifts out of tune. A plugin update you did not apply means two plugins are now a version apart and something in the layout breaks on mobile. Links to other sites rot. A form field stops validating properly. The site starts to feel slightly untended, in ways a visitor registers without being able to name.
Speed is the part with a measurable business cost attached, and we have written separately about what a slow website actually costs you in lost business. At this stage the losses are still small. They are also cumulative, and they are the cheapest thing on this page to fix.
Month six to twelve: the security window opens
Here is where the numbers get real, and where most articles on this topic start and stop.
Patchstack's State of WordPress Security in 2026 counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025, up 42% on the year before. The distribution is the interesting part. Ninety-one percent were in plugins, nine percent in themes, and six were in WordPress core itself, all of them rated low priority.
Read that again, because it reframes the job. Core updates itself now, and core is basically not the problem any more. The risk has moved almost entirely into the plugins nobody is watching, which is exactly the layer that stops getting updated when maintenance lapses.
The same report puts the weighted median time between a vulnerability becoming known and the first exploitation attempt at five hours. That figure deserves its caveats, because it is narrower than it sounds: Patchstack measured the vulnerabilities showing the highest levels of real-world exploitation, a prioritized subset accounting for roughly 95% of observed attack activity, and the clock runs from when Patchstack deployed its own mitigation rule to when its own detection network first saw an attempt. It is not "the average vulnerability is attacked within five hours." It is "the ones worth attacking are attacked fast, according to one vendor's telemetry." Even read conservatively, the practical point survives. The gap between a patch existing and an attack arriving is measured in hours, and a quarterly update cycle is not a defense against that.
Month twelve and beyond: compounding
Past a year, problems stop being independent and start blocking each other.
Your PHP version falls out of support, so your host schedules a forced upgrade, and half your plugins are too old to run on the new version. Updating them requires updating the theme, and the theme has been customized, so the customizations break. Now the cheap fix is gone. You are choosing between a careful, billable untangling and a rebuild.
This is the cliff. Everything before it is maintenance. Everything after it is a project.
What each stage costs to fix
Nobody puts numbers on this, so here are ours. These are typical ranges we see and quote in Ontario, in Canadian dollars, and they are approximate market ranges rather than standardized rates. Yours will vary with how the site was built.
| Stage | What it takes | Typical cost (CAD) |
|---|---|---|
| Caught at weeks 1-3 | Nothing. Routine updates. | $0 extra |
| Silent form failure, caught in month 2 | Diagnose and reconnect delivery, test | $150 - $400 |
| Silent form failure, caught in month 6 | Same repair, plus four months of lost inquiries | $150 - $400, plus what you never received |
| Visible wear at month 4-8 | Update pass, plugin conflict resolution, performance tune | $300 - $900 |
| Compromised site | Malware removal, backdoor sweep, hardening, blacklist removal | $500 - $1,500 |
| Neglected 12+ months, PHP forced upgrade | Staged updates, conflict resolution, custom code repair | $1,200 - $4,000 |
| Past the cliff | Rebuild on a current stack | $6,000+ |
For comparison, a specialist remediation service publishes fixed annual pricing rather than per-incident quotes. Sucuri's website security platform lists plans at $229, $339 and $549 per year in USD, all including unlimited manual cleanups, with the tiers differing mainly on guaranteed first response: 30 hours at the bottom, 6 hours at the top. That pricing structure makes a point on its own. What you arrange in advance mostly buys you response speed, and a site with nothing in place starts that clock only when someone notices, which could be a week after the fact.
The pattern across the whole table is that the repair cost is modest and the loss cost is not. Nobody goes broke paying for a malware cleanup. Losing four months of inquiries is a different kind of number.
Updating everything does not make you safe
This is the part the risk-list articles get wrong, and it matters if you want to make a good decision rather than just feel scared.
In Sucuri's 2023 Hacked Website and Malware Threat Report, 39.1% of the compromised sites they cleaned had an out-of-date CMS at the point of infection. Which means around 61% of them were current. Those sites got hacked anyway.
Caveats first: that data comes from 39,594 sites cleaned by Sucuri's own incident response team plus around 108 million remote scans during 2023, and the report says plainly that it "does not represent the entire web at scale." It is a population of sites that already got hacked and hired a cleanup service, so it tells you about compromised sites, not about all sites. It is also 2023 data, the most recent edition available.
Even with those limits, the conclusion is hard to escape. Updates lower your risk. They do not buy immunity. Attackers use credential stuffing, weak passwords, compromised hosting neighbours, vulnerable code with no patch available yet (Patchstack found 46% of 2025's vulnerabilities had no patch at disclosure), and backdoors left behind from an earlier compromise. Sucuri found at least one backdoor in 49.21% of the sites they cleaned, which is why "we updated everything and it came back" is a story we hear regularly.
The honest framing is that maintenance is about narrowing the window and shortening the recovery, not sealing the site. Anyone promising you a guarantee is selling something they cannot deliver, which is worth remembering when you read a maintenance pitch.
"But my site looks fine"
It probably does. That is not evidence of much.
What you see when you visit your own site is a cached page, in a browser you are logged into, on a connection you already trust, showing content you already know how to read. Almost every failure mode above is invisible from that vantage point. A dead contact form looks identical to a working one. An expired certificate warning may not appear for you. A page that takes six seconds on mobile data takes one on your office wifi.
The version worth checking is the one a stranger sees on a phone. That is a specific check, not a vibe, and we made the same argument at more length about why a site can look fine and still score badly.
What actually needs to happen, and how often
The realistic minimum, if you are doing this yourself:
- Monthly: apply plugin, theme and core updates, ideally on a staging copy first. Send yourself a test inquiry through every form and confirm it arrives. Confirm a backup from this month actually exists.
- Quarterly: restore a backup somewhere and check it works. An untested backup is a guess. Check your certificate expiry and PHP version.
- Twice a year: review what plugins you still use and delete the rest. Unused plugins are still attack surface, and they are the cheapest risk on this page to remove.
- Continuously, if possible: uptime monitoring that tells you the site is down before a customer does.
None of that requires an agency. It requires someone doing it on a schedule, which is the part that tends not to survive a busy quarter. If you want the fuller picture of what a paid arrangement covers and what it should cost, we have written that up separately in what a website maintenance plan actually includes. This piece is about the consequences of the gap, not about what to buy to fill it.
Who can safely leave this alone
Being straight about it: some sites can. A five-page static brochure site with no forms, no logins, no payments and no CMS is genuinely low risk, and treating it like an e-commerce store is a waste of money.
You need someone actively watching if your site takes payments, holds customer data, runs bookings, has user logins, is running on WordPress with more than a handful of plugins, or is the main way people find and contact your business. That last one catches most small businesses. If the site going quietly wrong for a month would cost you real revenue, the calculation is already made.
The rule, in one line
An unmaintained website does not break, it decays, and the cheapest thing on the whole timeline is the test inquiry you send yourself once a month.
Not sure what shape your site is actually in? Our free Website Grader checks it in about a minute and tells you what a first-time visitor on a phone runs into, which is usually the gap between "it looks fine to me" and what is really happening.
Frequently Asked Questions
For the first few weeks, nothing. Over two to four months, things tend to fail silently, with contact form delivery the most common and most costly. Between four and eight months, wear becomes visible as slower pages and small layout or functionality breakages. From roughly six to twelve months, the security exposure grows as unpatched plugin vulnerabilities accumulate. Past a year, problems compound and the fix shifts from routine maintenance to a billable project.
Not necessarily, but your exposure grows. Patchstack recorded 11,334 new WordPress ecosystem vulnerabilities in 2025, 91% of them in plugins, and the vulnerabilities most worth attacking are attacked within hours of becoming known. Worth knowing the other side too: in Sucuri's 2023 data on sites they cleaned, roughly 61% were current on their CMS when they were compromised, so updating reduces risk without eliminating it.
A simple brochure site with no forms or logins can go a long time without real consequence. A site with a CMS, plugins, forms or payments starts accumulating meaningful risk within a few months, and hits a much more expensive category at around the twelve-month mark, when an unsupported PHP version or a stack of skipped plugin updates turns a small job into a large one.
WordPress core auto-updates for minor releases, and core itself is now a small part of the risk: Patchstack found only six core vulnerabilities in 2025, all low priority. The real exposure is plugins and themes, which do not all update themselves and accounted for 100% of the rest of that year's disclosures. An un-updated plugin with a known, published vulnerability is the standard way a small business site gets compromised.
Maintaining it, though the repair bills are not usually what makes the difference. A cleanup or an update pass typically runs a few hundred to a couple of thousand dollars CAD. The costs that actually hurt are the ones with no invoice: the inquiries that vanished while a form was broken, and the rebuild you end up paying for because the incremental path closed.
Send yourself a test inquiry through every form and confirm it arrives, then load the site on a phone on mobile data rather than wifi. Check that your certificate has not expired and that a recent backup exists and restores. Those four checks take fifteen minutes and catch most of what fails quietly.
You can absolutely do it yourself. Monthly updates on a staging copy, a monthly form test, a quarterly backup restore test, and a twice-yearly plugin cull covers most of the risk. The question is not capability, it is whether it will still be happening in month eight. If the honest answer is no, paying someone is cheaper than the alternative.
