Your website was true the day it launched. Then the business moved.

Drift is structural, not careless

Nobody decides to let the website rot. It happens because keeping a site true requires three things that almost never live in one place: knowing what changed in the business, being able to change the site, and a standing rhythm that makes the change happen without anyone requesting it.

The founder knows what changed but has no rhythm and often can't touch the site. The marketing person can write but can't touch structure. The developer can touch everything but has no idea the flagship offer was repriced last month. So each change in the business generates a small site update that is nobody's job, and the gap compounds quietly.

The cost compounds too, and faster than it used to. Machines now repeat your website to your buyers. When the site said the old thing, a stale page used to cost you one visitor at a time. Now it gets baked into AI answers about your business and served to people who never visit at all. Drift used to be cosmetic. Now it's misinformation you're publishing about yourself.

Why the maintenance retainer doesn't stop it

The standard answer is a maintenance retainer with an agency or a freelancer. Retainers are good at what they're scoped for: uptime, plugin updates, and responding to tickets. The problem is that drift doesn't file tickets.

Nobody notices that the services page describes last year's offer. So nobody requests the fix. So the retainer hums along maintaining the software while the story rots on top of it. A year in, the site is fully patched, fully backed up, and describes a business that no longer exists.

The missing function isn't responsiveness. It's noticing. And noticing requires someone who sits close enough to the business to know what changed, and close enough to the site to see that the change never landed.

What a working rhythm looks like

The fix is boring, which is why it works: a short, standing monthly cycle that closes the gap between the business and the site while the gap is still small.

• A monthly review, 45 minutes, on the calendar. What changed in the business this month? New offer, new price, new proof, new hire, a service you quietly stopped selling. This meeting is the noticing function, made structural.
• The site updated to match, same cycle. Not logged in a backlog — shipped. Small monthly updates cost minutes. The same updates, batched for two years, cost a rebuild.
• Visibility watched, fixes shipped. What do search results and AI engines say about the business this month? Where it's wrong, fix the page that's feeding the error. A report that lists problems without shipping fixes is drift with a dashboard.
• One new asset a month. A page that answers a real buyer question, a case study, a guide. Twelve a year compounds into the content depth that earns rankings and citations — without ever feeling like a content push.

Run it with your own team

This rhythm doesn't require hiring anyone if three conditions hold. First, the site itself is runnable — your team can change content and pages without a developer. If it isn't, fix that first; a rhythm can't run on a site only outsiders can touch (that's the case for rebuilding it as an operating surface). Second, one named person owns the monthly review — the meeting exists on the calendar with the same seriousness as your pipeline review. Third, the review has a written checklist: what changed, what the machines say, what ships this month.

Where it falls apart in practice: the owner is the founder, the meeting gets eaten by delivery work, and by month four the rhythm is dead. If that's the honest forecast for your team, the function is worth buying rather than pretending.

The monthly checklist, if you want to start now

Here's the review agenda that makes the rhythm real. Forty-five minutes, one owner, every month, no exceptions:

• What changed in the business? Offers, prices, team, proof, positioning. Five minutes with the founder or their calendar. Anything that changed and isn't on the site goes on this month's ship list.
• What do the machines say? Ask two AI engines the top three questions your buyers ask. Search your name and your category. Note what's wrong and which page is feeding the error. That page goes on the ship list.
• What did last month's asset do? The page you shipped last month — is it indexed, is it getting read, did anyone arrive through it? Thirty seconds per asset. You're not building a dashboard; you're checking the work landed.
• What ships this month? The updates from the first two items, plus one new asset: a page that answers a real buyer question. Named, owned, dated before the meeting ends.

The whole system is four questions and a ship list. What makes it work isn't sophistication — it's that it happens every month whether or not anything feels urgent, because drift never feels urgent while it's happening.