Six months after the redesign, the content looks worse than it did on launch day.
Links rot. Standards drift. The tidy new templates fill up with the same inconsistencies the project was supposed to bury. And the working theory, spoken or not, is that the team stopped caring.
They didn't. I've heard that theory in more than one post-launch review, and it's wrong.
What happened is quieter and more structural than apathy. Nothing about how content actually gets made, reviewed, and governed changed during the redesign. You rebuilt the surface and left the operating model untouched, so the estate outgrew that model all over again, on the same schedule as last time.
That's the argument of this piece, and it's what Siteimprove's analysis of post-redesign decay keeps finding: content quality decays because content operations stay ad hoc as your digital estate scales. Maturing that operating model, from ad hoc to governed, is the lever. Not another cleanup.
We'll work from a plain definition of content operations, through a content operations maturity model that turns quality into a question of capability stage, to the honest steps, and the honest role of tooling, that move you up the ladder.
Content operations is an operating model, not a CMS or a strategy
Ask a team whether they have content operations and most will point at two things: a content strategy deck and a CMS. Neither one is content operations.
Your strategy is the plan. It says what content should exist, for whom, and why. Your CMS is the machine that stores and publishes it. Content operations is the layer in between, and it's the layer nobody owns by default: the standards content has to meet, the people accountable for meeting them, the policies that make those standards enforceable, and the monitoring that tells you when they slip.
Put plainly, content operations is the operating model for content at scale.
That distinction isn't academic. A team with a sharp strategy and a capable CMS can still produce inconsistent, decaying, non-compliant content. But a plan and a tool don't govern anything on their own. Somebody has to define the standard, somebody has to own it, and something has to catch it when it breaks. When those three are missing, you don't have operations.
You have publishing.
And you can't mature a capability you haven't named. Before we talk about stages, get honest about whether your organization treats content operations as a discipline or just assumes it happens somewhere between the strategy and the CMS.
Content quality is capped by capability stage, not by effort
Here's why a maturity model is worth your time, and it isn't the diagram.
A maturity model is a framework that describes progressive stages of capability. The concept isn't new. Software teams have staged their processes this way for decades, from ad hoc and reactive up to measured and optimized. But applied to content, it does one useful thing above all. It reframes the problem.
Left alone, a team explains bad content as an effort problem. People are busy. The freelancer rushed. Nobody proofread. And the fix is always the same, work harder next time, and the decay comes back anyway.
A maturity model says something less flattering and more useful.
Your content quality is capped by the stage your operating model sits at. Not by how hard your people try.
That reframe matters because it makes the problem locatable. If quality is a function of effort, you're stuck exhorting people. If quality is a function of capability stage, you have somewhere to go. You find your stage, and you advance it. Each stage sets a ceiling on the quality you can hold after launch, and you don't raise the ceiling by pushing harder against it. You raise it by moving up.
Each maturity stage carries the risk the next stage resolves
Siteimprove's Content Operations Maturity Model earns its place because each rung names the specific failure the next rung resolves. Most maturity ladders don't. They're four boxes and an arrow pointing up and to the right, with no consequence attached to standing in any particular box.
Read the one below by its third column, the risk each stage carries, not by its label.
| Stage | What it looks like | The risk it carries | Where it leaves you |
|---|---|---|---|
| Ad Hoc | Content is made on demand, with no shared standards and no clear owners. Quality depends on whoever happens to do the work. | Every kind of content problem, uncontained. Nothing catches errors, drift, or decay until someone notices in public. | Quality swings with staffing. A redesign resets the surface and the decay returns. |
| Defined | Standards and guidelines exist and are written down. Ownership is named, at least on paper. | Standards without enforcement. The documentation reads as governance but behaves as advice nobody has to take. | Better than ad hoc on paper, no better in practice, because nothing checks compliance. |
| Managed | Standards are enforced through review, and ownership is real. Compliance is checked, mostly by hand, at known moments. | Coverage gaps. Manual checks scale with headcount, so parts of the estate go unwatched between reviews. | Quality holds where people are looking and slips where they aren't. |
| Governed | Standards are defined, owned, enforceable, and continuously monitored across the whole estate. | Residual risk only. The model catches drift as it happens instead of at the next audit. | Quality is sustained through change, including the next redesign. |
Now find your organization in the third column. The rung you're standing on names the risk you're carrying, and the rung above it names your next fix.
That's the whole use of the model.
Unmonitored standards read as governance but behave as ad hoc
Ask a team to rate its own content operations maturity and it grades itself on the standards it wrote, not the standards it enforces. That's the single most common assessment error, and it inflates almost everyone by a stage.
Don't ask people how mature they are. Look at three signals instead.
The first is ownership. Can you name the person accountable for a given standard on a given section of the site, or does accountability dissolve into "the web team"? The second is enforcement. When content violates a standard, does anything stop it before it publishes, or does it go live and wait to be noticed? The third is coverage. What fraction of your estate is actually monitored, and what fraction just isn't looked at between quarterly reviews?
Run those three honestly and most organizations land a stage below where they placed themselves.
The tell is a documented standard nobody is watching. It reads as governed, because it's written down and someone's name is next to it. But it behaves as ad hoc, because nothing enforces it and nothing catches it when it breaks. Written but unwatched isn't governed.
It's ad hoc with better paperwork.
At enterprise scale you can't run this assessment by hand, and that's where a platform earns its place. Siteimprove.ai gives you continuous visibility into where standards are met and where they break across the whole estate, which is what makes an honest maturity assessment possible when the site is too large to inspect page by page. It surfaces the evidence.
It doesn't do the governing for you.
Continuous monitoring separates governed operations from documented intentions
Governed content operations rests on four things working together: defined standards, assigned ownership, enforceable policy, and continuous monitoring. That combination is what content governance actually means. Not a policy document, but an enforced operating model.
Three of those, most enterprises can produce in a quarter. You can write standards. You can name owners. You can codify policy. But what almost everyone skips is the fourth one, and skipping it quietly collapses the other three.
Standards you don't monitor become suggestions. Ownership you don't monitor becomes a name in a document. Policy you don't monitor becomes a PDF. Without monitoring, the first three decay into documented intentions, and documented intentions are exactly what a maturity assessment mistakes for governance.
So monitoring isn't the nice-to-have at the end of the list.
It's the thing that keeps the list from lying to you.
This is also where the ownership line has to be clear. Your organization owns the standards and the decisions. It decides what "good" means, who's accountable, and what the policy is.
A platform's job is narrower: make enforcement visible across an estate no team can watch by hand. Siteimprove.ai monitors quality, accessibility, and discoverability continuously and flags drift as it happens, so the standards your organization set stay enforced between the moments people are paying attention.
The platform sees. Your team governs.
Ad hoc operations are why redesign decay returns on schedule
Staying ad hoc isn't one risk. It's three, and they compound. Siteimprove groups them as Content Risk, Governance Risk, and Transformation Risk.
Content Risk is the visible one. Broken links, stale pages, inconsistent voice, orphaned content, metadata that degrades every time the estate grows. Governance Risk is the structural one. No clear ownership, no enforceable standard, no accountability when something breaks, which means every content problem is also a decision nobody can be held to. Transformation Risk is the slow one. The organization treats each redesign as a finish line, the project team disbands, and quality management leaves with them.
These aren't three separate problems you can triage separately. They're what one ad hoc operating model produces as it scales.
Which brings us back to where we started. A redesign resets the surface, but it doesn't touch the operating model underneath, so the same decay returns on a predictable schedule. Fix the pages, keep the model, and you've bought yourself maybe eighteen months before the next emergency cleanup. That's not a content problem you can out-work. It's a maturity problem, and the only thing that breaks the cycle is advancing the stage the redesign leaves alone.
I've watched this happen to teams on their second redesign in five years. The decay isn't random and it isn't a discipline failure. It's the predictable output of a model that was never matured, and it keeps returning until the model is.
Buying a platform before defining standards just automates ambiguity
So how do you actually move up? Not by buying something. Advancing content operations maturity is a sequence, and the order isn't optional:
- Define the standard. Decide what good content is, concretely enough that two people would grade the same page the same way.
- Assign ownership. Put a name against each standard and each section, so accountability doesn't dissolve into the team.
- Make policy enforceable. Turn the standard into rules that can be checked, not guidance people are trusted to remember.
- Instrument monitoring. Watch compliance continuously across the estate, so drift surfaces when it happens instead of at the next audit.
Technology enters at steps three and four, where enforcement and visibility have to run at a scale people can't. That's the honest role of a platform like Siteimprove.ai: it enforces and monitors the standards you've already defined and assigned. It isn't a service that governs for you, it isn't a consultancy, and it isn't a migration tool.
Which is why buying the platform first is a mistake I watch teams make constantly. A tool pointed at undefined standards doesn't create governance. It automates ambiguity, at scale, with a dashboard. The commitment and the process design come first. The platform makes them operational.
In that order, or not at all.
Take Away
Content quality isn't a campaign you win and then defend. It's a byproduct of how mature your operating model is.
The ladder gives you a diagnosis and a next move. Governed operations is the only stage that holds quality through change, including the next redesign. And the redesign itself is the moment to advance your operating model, not a substitute for doing it.
So stop treating the post-launch cleanup as the fix. Treat your maturity stage as the thing to advance, and judge any platform you're weighing by one question: does it make your standards enforceable and visible, or does it just add features?
Everything else is paperwork.