Content governance, explained without the jargon

This is one of those topics that looks small until it costs you something. Here is content governance without the vocabulary that usually surrounds it.

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. If two people in the business would answer this differently, that gap is the actual problem.

The short version

Someone must own each page or it rots. It is worth being explicit about, because assumptions differ quietly. The version that survives contact with a real deadline is the simple one.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Small and consistent beats large and occasional here.

Set review dates when content is published. The reasoning matters more than the rule, because the rule has exceptions. Budget a little time for it every quarter and it never becomes a project of its own.

Where to go from here

Removing outdated content is maintenance, not loss. The cost of getting this wrong is rarely visible on the day it happens. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

Content is the part of a project most likely to be underestimated and most likely to delay a launch. Three things worth confirming about content governance before you move on:

• Someone can say what the current setup is without going to look
• Removing outdated content is maintenance, not loss — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.