A business website doesn't run on one update schedule, it runs on three that overlap: security patches on a monthly cadence (sooner for anything actively exploited), content and copy revisited every one to three months as the business itself changes, and a full technical rebuild roughly every two to three years before the framework underneath it falls out of support. Most owners only ever think about the middle one.
We see the gap between those three clocks most clearly when we take over a site someone else built. The pattern is almost always the same: the homepage still reads fine, the contact form still submits, and nobody noticed the CMS core hasn't been patched since the site launched. The site looks maintained because it still works. It isn't, because "still works" and "still current" measure completely different things.
The clock nobody watches: security patches
This is the one with no flexibility in it. CMS platforms, plugins and the libraries underneath them get security fixes on their own release schedule, not the business's — and the gap between a patch shipping and an automated scanner probing for the unpatched version is now measured in days, sometimes hours, for anything popular enough to be worth attacking. A monthly patch cycle is the reasonable floor for a normal business site; anything flagged as actively exploited in the wild jumps the queue and gets applied immediately, not at the next scheduled window. None of this is visible to a visitor, which is exactly why it's the clock that stops first when nobody is explicitly responsible for it.
Content and design sit on a much looser rhythm, and that's fine — a stale price list or a portfolio missing your last three projects is a credibility problem, not a security one, so a quarterly look is a sensible default rather than a rule. The rebuild clock is the one that surprises people: it isn't driven by a design going out of fashion, it's driven by the framework or theme the site was built on approaching its own end of support, the same way an old phone eventually stops receiving updates. A rebuild planned a year ahead of that date is a normal project scoped on your timeline. A rebuild forced by an unsupported platform breaking in production is an emergency scoped on nobody's timeline, done under pressure, usually at a worse price.
All three clocks are exactly what the maintenance plan we described in an earlier guide is meant to keep running without the owner having to track any of them manually — patches on schedule, a periodic content check, and enough advance warning on the rebuild clock that it never becomes a fire drill. If you'd rather see what that actually looks like for your own site than read another list of best practices, our maintenance and support work starts with exactly that audit.
Frequently asked questions
How often should a WordPress or CMS site be updated?
Core, theme and plugin security patches should go out at least monthly, and immediately for anything flagged as actively exploited. That schedule is independent of whether the business has changed anything about the site itself that month.
Is a website that still loads fine actually out of date?
Loading correctly and being current are different things. A site can render perfectly while running a plugin version with a known vulnerability, or while quoting prices, hours or a phone number the business changed a year ago. Uptime is not the same signal as maintenance.
How often should website content actually change?
There's no fixed number, but a useful test is whether anything about the business has changed since the last edit — new services, new pricing, a closed location, a finished project worth adding to a portfolio. For most SMEs that works out to a look every one to three months, not a calendar reminder.
When does a website need a full rebuild instead of an update?
Roughly every two to three years for most business sites, driven less by a design going stale and more by the underlying framework or theme approaching end of support. A rebuild planned ahead of that date is a project; one forced by an unsupported platform breaking is an emergency.
Does a small business site need updating if the business itself hasn't changed?
The security clock still runs regardless. Patches address vulnerabilities in the software the site is built on, not changes the business made, so a site with an unchanged offering can still be running dangerously outdated plugins underneath it.