Updates, and who is responsible when one breaks something

“How often should a website be updated” measured zero Google searches and zero AI-assistant prompts under that exact phrasing, checked 31 July 2026 — a genuinely basic question nobody seems to type directly, which does not make it unimportant. The honest answer sits between two extremes, and it is worth stating the extremes first because most bad outcomes come from sitting at one of them rather than in the sensible middle.

Software updates vs content updates: two different maintenance clocks

“How often should a website be updated” gets asked about two different things that run on different schedules. Software updates — core, theme and plugin patches, the subject of this page — are about security and compatibility, not freshness, and the cadence question is “how often is it safe to leave a disclosed vulnerability unpatched”, not a marketing decision. Content updates — refreshing the words, prices and images on existing pages — are a separate maintenance task, driven by accuracy and SEO freshness rather than security, and covered in the annual review a small business site needs. Treating both as the same “how often should I touch the website” question is what produces either an outdated site regularly losing content but never patched, or a site patched on schedule that nobody has looked at with fresh eyes in years.

The two extremes in how often to update a website, and why both are wrong

Updating everything the instant it is released, on every site, with no testing step, occasionally breaks something that was working — a plugin conflict, a theme incompatibility — at a moment nobody chose and with no rollback prepared. Never updating at all leaves a site accumulating known, disclosed vulnerabilities indefinitely, covered fully in why small-business websites get compromised. Neither extreme is a defensible position, and most sensible maintenance practice sits deliberately between them.

What a sensible update cadence actually looks like

Security-specific updates — fixes addressing a disclosed vulnerability — are generally applied promptly, often within days, because the exposure they close is actively time-sensitive. Ordinary feature updates are generally applied on a routine schedule, commonly weekly or monthly, tested on a staging copy of the CMS first where one exists, rather than immediately on release. This is not a universal rule for every site — a site with unusual customisations may need a more cautious cadence, and a simple, lightly customised site can generally move faster — but “somewhere sensible, on a defined schedule” is the position almost every credible practitioner actually holds, regardless of how it gets phrased in marketing material.

Why testing before applying matters as much as the schedule itself

A staging copy of the site, with an update applied and checked before it reaches the live site, catches the specific, occasional case where an update breaks something — a theme built against an older core version, two plugins conflicting only after one updates. Where no staging environment exists, a recent, verified backup taken immediately before an update at least makes a failed update quickly reversible, covered in backups you have actually tested.

Who is actually responsible when an update breaks something

This is the question a maintenance arrangement should answer explicitly, in writing, before it is needed rather than during the incident. If a supplier is applying updates as part of a paid arrangement, the reasonable expectation is that they identify and fix a problem their own update caused, promptly and without a separate emergency invoice — that expectation should be stated in the agreement, not assumed. If updates are being applied by the business itself with no such arrangement, the business is, by definition, its own safety net, and that is worth being honest about rather than discovering during an actual failure.

Why “if it isn’t broken, don’t touch it” is the wrong instinct for a security update

This general engineering caution makes sense for most software; it is close to backwards for a security-relevant update, because the update is very often patching a vulnerability that is already public and already being scanned for — delaying it does not avoid a risk, it extends a known one. The genuine caution that does make sense is testing before applying, not avoiding the update altogether.

Why an update log is worth keeping

A simple record of what was updated and when, kept over time, makes it far easier to identify what changed if a problem appears shortly after an update — without a log, diagnosing “what broke this” after several updates have accumulated since the last check becomes considerably harder than it needs to be.

What “tested on staging” should actually involve

Beyond simply loading the homepage and confirming it still appears correctly, a genuine test after an update checks the specific features most likely to be affected — forms, any custom functionality, checkout if the site sells anything — rather than a superficial glance that would miss a problem confined to one particular feature.

Coordinating updates across interdependent CMS components

Where a theme and several plugins are all built to work together, updating one in isolation can occasionally break the interaction between them even though each individually updates without issue — a further reason a staging test matters more on a site with several interdependent, customised components than on a simple, largely default installation.

What to do if a site has clearly gone outdated from neglected updates

Rather than applying every outstanding update at once and hoping for the best, working through them incrementally, testing after each significant step, and being prepared for the process to take longer and surface more issues than a routine update cycle would, respects the genuine risk a large accumulated gap carries. This is also the point at which professional help is most worth engaging if it has not been already, because the risk of a self-managed catch-up going wrong rises with the size of the gap being closed.

Why documenting the outcome of each update matters

A brief note after each update — what was updated, whether anything needed fixing afterwards — builds a track record that makes the next update, and any eventual troubleshooting, faster and better informed than starting from nothing each time.

Where to go from here

The layers that each need independent attention — core, theme, every plugin — are set out in plugins and extensions, and the dependency you inherit. And who holds the responsibility described above, in writing, is worth confirming as part of what website maintenance costs.