Why your website project is actually a content strategy problem

When clients say “we need a new website, and a new CMS,” they’re often right that their CMS is outdated and needs replacing. But a new CMS on its own won’t fix what’s actually slowing these organizations down. The deeper issue is usually how content is owned, structured, and reused across the business, and that problem, if not addressed, follows them onto the new platform.

Almost no organization has figured this out fully, even the ones that pretend to have. We see enterprises consolidate their assets into DAMs (digital asset management) and manage their product data in centralized PIMs (product information management). But, when it comes to content, campaign messaging, editorial, service descriptions, and localized variants, it still lives in page templates, shared drives, and channel-specific tools. That’s the gap content operations is designed to close.

For long-term success, we need to stop thinking of the CMS as the website’s backend. What we actually need is a content operating system: the layer that feeds every channel the business publishes to. This is why we at Codal believe in content operations.

The maturity spectrum: from pages to entities

Content maturity isn’t a switch you flip. It’s a spectrum, and most organizations sit somewhere in the middle, doing parts of it well and parts of it less well. One key shift is the move from designing content for one surface (the website) to modeling it as a strategic asset for the business, then letting any surface consume it.

We break this down into three typical stages.

Level 1: web management

Web management is where most organizations operate. The CMS is the website’s backend. Marketing or web teams update existing pages and create new ones from pre-set templates. Content lives and dies in this one channel.

The content has no independent life outside the page it sits on. If marketing wants to use the same product description in an email campaign, they copy and paste it. If the app team wants it, they copy and paste it again. Three months later there are four versions, and nobody knows which one is current.

Level 2: content management

At the content management level, multiple teams share the CMS and there’s some reuse, but content is still organized around pages and templates. The first move toward maturity is decoupling content structure from presentation. Content structure is a strategic decision about what the business cares about; presentation is how a given channel renders it. They shouldn’t be the same thing.

This is the original premise behind decoupled and headless architectures: separate content from any one presentation layer so that the content itself can become the single source of truth, with each channel rendering it on its own terms.

Instead of building a service page, you define a service entity with its own attributes: what it does, who it’s for, what it costs, and what it relates to. Once those attributes are defined, the content becomes reusable.

A practical example: when a service should appear in a carousel on the homepage, you don’t copy and paste the description in. The carousel pulls directly from the service entity itself. When someone updates that service, every surface that consumes it, the dedicated service page, homepage carousel, related-services widget on a case study, and partner portal, updates with it. You’re no longer maintaining a web page; you’re maintaining an organizational asset.

Level 3: content operations

At this stage, content is a shared strategic asset with governance, ownership, and a model that reflects the business domain rather than the website’s information architecture. This is the distinction between managing a website and operating content as a business function. It’s also the point at which AI, personalization, and new channels stop being projects and start being configuration.

Governance should be an enabler, not a bureaucracy

The platform is the easiest part of the transformation. The hard part is the governance: getting marketing, product, engineering, and local teams to agree on shared content models and ownership.

In discovery sessions, we routinely watch competing mental models clash. Marketing thinks in hero banners. Engineering thinks in data entities. Local teams think in approval workflows. The breakthrough usually arrives when teams realize they’ve been manually maintaining five different versions of the same product description across five different silos, and that nobody owns the canonical one.

This is where governance becomes an enabler rather than a bureaucracy. Governance isn’t an extra process to slow people down. It’s guardrails that let teams move faster. When everyone agrees on the structure of the underlying entities, product, service, event, article, marketing can launch campaigns in minutes instead of weeks, because the content is already structured and ready to be pulled into any channel.

The cost of staying in web management mode

Staying in web management mode eventually caps the organization’s velocity. Content locked into templates means every new request, channel, market, or campaign format, becomes a project rather than a configuration change.

The costs are both visible and invisible:

• Duplicated effort: Teams go rogue because it’s faster to build one-off pages than to navigate a rigid and complex CMS. We’ve seen teams ship campaigns without the brand system because they needed something live by Friday.
• Inconsistent messaging: Without a single source of truth, the same product description ends up in five forms across the website, sales decks, partner portals, and the help center. Each one drifts from the others. Brand and voice become whatever the latest team needed at the time.

AI and personalization roadblocks: You can’t ship useful personalization on top of unstructured content. AI agents need typed entities, explicit relationships, and semantic metadata to give accurate answers. Feed them a flat HTML page and they’ll guess. Most “AI hallucination” problems are actually content architecture problems in the first place.

Content operations unlocks capabilities web management can’t

Moving to content operations unlocks capabilities that are practically impossible in a web management environment.

The current debate is whether AI has become capable enough that structure no longer matters. It hasn’t. Large language models can read unstructured content, but they can’t reliably reason over it. They can’t tell a product name from a passing mention in a blog. They can’t distinguish current pricing from a quote in last year’s case study. Structured content gives AI typed entities, explicit relationships, and queryable metadata, the difference between an agent that answers your customer’s question and one that confidently makes something up.

The same is true of personalization, search, and every new surface that wants to consume your content. Without structure, you’re rebuilding for each one. With structure, you author once and distribute everywhere.

The evolving role of content infrastructure

What we used to call a CMS is becoming less of a web publishing tool and more of a content operating system. It’s the layer that serves humans, frontends, and AI agents from a single source of truth. As surfaces multiply, chat, voice, in-product experiences, agentic interfaces, the question isn’t which channel to build for next. It’s whether your content is modeled well enough to be consumed by any of them. The content operating system becomes the contract between the organization and every system, human or machine that needs its content.

Start small

Our advice for organizations starting this work: start small. You don’t need a full transformation on day one. We’ve learned this the hard way ourselves, and so have most of the clients we work with. The biggest unlock isn’t a new platform, it’s a process change. Begin content modeling in the discovery phase, before design starts. Identify the three or four entities that matter most to the business and model those properly. Get one channel beyond the website consuming structured content. Then expand.

Moving from managing a website to operating content as a business function is a strategic shift, not a one-off project. It evolves as the organization does. Recognizing that your website project is actually about resolving a content strategy problem is where it begins.

From content management to content orchestration

Most organizations are still operating in web management mode, even when they have invested in modern CMS, DAM, PIM, and commerce platforms. The technology may be improving, but the content model, ownership structure, and governance often remain fragmented.

Moving to true content operations means treating content as infrastructure: structured, reusable, governed, and ready to serve every channel, market, and experience.

That is where content orchestration comes in. It connects the strategy, systems, workflows, and governance needed to move content through the business with less duplication, more consistency, and greater speed.

For organizations planning a website rebuild, CMS migration, or broader digital transformation, the question is no longer just “which platform should we use?” It is “is our content mature enough to support the experiences we want to create next?”

At Codal, we help enterprise teams design the content models, CMS architectures, and orchestration strategies that make this shift possible.

Markus Schork

Director of Technology Solutions

Read Markus’s full bio