Most teams discover the omnichannel problem the hard way. They build a website, the content lives happily inside web pages, and then someone asks for the same content in the app, or on a partner site, or in an email system, and it turns out the content is so tangled up with the website that pulling it out to use elsewhere means basically rewriting it. Do that across enough channels and you’ve got the same information maintained in five places, drifting out of sync, aging badly.
The fix isn’t a tool. It’s how you structure the content in the first place. Content built to live in one specific place is trapped there. Content built as clean, independent pieces can flow anywhere. This is about the second kind: how to structure content so one version can serve many channels without being redone for each.
The plain version: stop thinking of content as finished pages and start thinking of it as reusable pieces plus rules for assembling them. Structure it once, cleanly, separate from how any single channel displays it, and you can send it wherever you need without starting over. Get this wrong and every new channel is a rebuild. Get it right and new channels get much cheaper.
What’s in this guide
- Why page-shaped content traps you
- The core idea: content as pieces, not pages
- Separating content from presentation
- Structuring a piece so it travels
- A structuring worksheet
- Where this goes wrong
- The stuff worth remembering
Why pages trap you
To see why structure matters, it helps to understand exactly how page-shaped content boxes you in, because the trap is subtle until you hit it.
When content is created as web pages, the words, images, and formatting get fused with the layout of that page. The headline is where the headline goes on the website. The image is sized for the website. The text assumes the website’s context around it. It all works beautifully on the website, which is why nobody notices the problem until later.
Then a second channel appears. The app doesn’t have the website’s layout. The email system doesn’t want the website’s formatting. The partner site needs just the core facts without the website’s framing. And now that lovely web page is the wrong shape for all of them. You can’t just send it over. You have to extract the actual content from the page structure, which is fiddly, and reformat it for each new place, which is work, and then do that again every time the content changes.
Multiply that by several channels and the cost is brutal. The same product description exists in the website’s version, the app’s version, the email version, each maintained separately, each a chance to drift. Someone updates the price on the website and forgets the app. The trap isn’t that the content is bad; it’s that it was built shaped like a website, so it only fits a website. Everything downstream pays for that original shape.
Content as pieces
The shift that fixes this is to stop building pages and start building pieces, which sounds abstract but changes everything in practice.
Instead of creating “the product page,” you create the pieces that a product page is made of: the name, the description, the price, the images, the specifications, the reviews. Each is a clean, self-contained chunk of content that doesn’t assume where it’ll appear. The page is then just one particular arrangement of those pieces, and crucially, not the only possible one.
Once content exists as independent pieces, channels stop competing for a single fixed layout. The website arranges the pieces its way. The app arranges the same pieces its way. The email pulls the two or three pieces it needs. The partner feed takes just the facts. Nobody’s rewriting anything, because they’re all drawing from the same clean pieces and each just assembles what it needs. Update the price piece once and every channel that uses it is current, because they all point at the same piece rather than holding their own copy.
This is the whole trick, and it’s more a mindset than a technology. Content that knows what it is (a price, a description, a headline) rather than where it goes (the top of the product page) can go anywhere. Content defined by its location is stuck in that location. The move is from “content is pages” to “content is pieces plus rules for assembling them,” and once a team internalises it, the omnichannel problem largely dissolves.
One product, four channels
The abstract idea gets concrete fast with a worked example, so here’s a single product handled the trapped way and the portable way.
Take a pair of running shoes. The trapped approach: someone builds a beautiful product page on the website. The name, a marketing paragraph, the price, a gallery, the spec table, and a reviews section, all laid out together as one web page, styled for the website, living as a single unit. It looks great. It is also stuck.
Now the requests come in. The mobile app wants the same shoe, but it needs the name, price, one image, and a short description, laid out the app’s way. The email team wants to feature the shoe: just the name, one image, the price, and a buy link. A retail partner wants a feed of your catalogue: name, price, key specs, no marketing fluff. With the trapped page, each of these means someone extracting bits out of the web page by hand and reformatting them, then redoing it every time the shoe’s price or description changes. Four channels, four separate copies, four things to keep in sync, and they won’t stay in sync.
The portable approach structures the same shoe as pieces from the start: a name piece, a description piece, a price piece, an images piece, a specs piece, a reviews piece, each typed, presentation-free, and linked to the shoe. Now the website assembles all of them into its rich page. The app takes name, price, one image, description, and lays them out its way. The email pulls name, image, price. The partner feed takes name, price, specs. Nobody rewrote anything. And when the shoe goes on sale, you change the price piece once, and the website, app, email, and partner feed are all correct immediately, because every one of them reads the same price piece rather than its own copy.
The instructive contrast is the sale-price moment. In the trapped version, a price change is four edits in four places with four chances to miss one. In the portable version it’s one edit that propagates everywhere. That difference, one update versus four-and-praying, is the entire return on structuring content properly, and it only compounds as you add channels.
Separating presentation
The principle underneath “pieces not pages” is separating content from presentation, which is worth understanding directly because it’s the load-bearing idea.
Content is what you’re saying: the actual words, the facts, the images, the meaning. Presentation is how it looks in a given place: the fonts, the layout, the spacing, the visual treatment. When these are fused, content can only exist in the one presentation it was built for. When they’re separate, the same content can be presented many ways for many channels without touching the content itself.
A clean piece of content carries no presentation. A price is the number and the currency, not “displayed in bold red at the top right.” A description is the text, not “two columns with a drop cap.” Strip the presentation out of the content and store just the meaning, and then each channel applies its own presentation when it displays the piece. The website makes the price look like the website wants; the app makes the same price look like the app wants; the content underneath is identical and shared.
This is the same principle that makes a headless CMS work, and it’s why headless and omnichannel come up together so often. But you don’t strictly need any particular tool to benefit from the idea. Even within a traditional setup, the more you can keep your content clean of presentation and think of it as portable meaning rather than finished pages, the easier every future channel becomes. The tool helps; the discipline is what actually matters.
Structuring a piece
Getting practical: here’s what actually makes a single piece of content travel well, because “clean pieces” needs to mean something concrete.
Give it a clear type. A piece should know what it is: this is a product description, that is an author bio, this is a price. Typed content can be handled sensibly by any channel, because each channel knows what it’s dealing with and how to treat it. Untyped blobs of “some content” can’t be, since nothing downstream knows what they represent.
Break it down sensibly. A product isn’t one giant lump; it’s a name, a description, a price, images, specs. Break content into the natural pieces that might be used independently, because a channel might want the price without the full description, or the images without the specs. Break it too coarsely and channels are forced to take more than they need; too finely and it’s a mess to manage. Aim for the pieces that genuinely get used on their own.
Keep it presentation-free. As covered above, store the meaning, not the styling. This is the discipline that makes everything else work.
Make relationships explicit. Pieces relate to each other: this description belongs to this product, these reviews are about this item. Capturing those relationships as real connections, rather than by two things happening to sit on the same page, lets channels assemble pieces correctly without relying on page layout to imply what goes with what.
Add useful metadata. Information about the piece, when it was updated, what language it’s in, who owns it, helps channels use it correctly and helps you manage it at scale. This is also where a content hub earns its place, giving pieces a proper home with this kind of structure around them, which we’ve written about separately.
Do these five things and a piece of content becomes genuinely portable: any channel can understand it, take the parts it needs, present it its own way, and stay in sync when it changes. Skip them and you’re back to page-shaped content that fights every channel but the one it was born in.
A structuring worksheet
The decision is really about breaking your content into clean, typed, presentation-free pieces with clear relationships, so it can be assembled by any channel, rather than building finished pages for one channel and extracting later.
We’ve put it into a short structuring worksheet: a way to take one important content type, a product, an article, whatever matters most to you, and break it into its natural pieces, mark each with a type, strip out anything that’s really presentation, and map how the pieces relate. Do it once for your most-reused content type and the pattern becomes obvious for the rest. The exercise is more valuable than it looks, because seeing your own content broken into pieces is when the omnichannel logic finally clicks.
Where it goes wrong
Structuring content for omnichannel is a genuinely good idea that teams still manage to botch, so here are the common ways, worth avoiding on purpose.
Over-structuring everything. The most common mistake is treating every scrap of content as if it needs elaborate structure. If some content really only ever lives in one place, forcing it into a complex piece-based model is wasted effort. Structure the content that genuinely needs to travel; don’t impose it on content that doesn’t. The discipline is a means, not a virtue in itself.
Breaking pieces down too far. It’s possible to atomise content into so many tiny pieces that managing them becomes its own nightmare, with editors assembling twenty fragments to make one simple thing. Break content into pieces that get used independently, not into the smallest theoretical units. Usefulness, not granularity, is the target.
Structuring for channels you’ll never have. Some teams build for a dozen hypothetical future channels and carry all that complexity forever while using two. Structure for the channels you have and the ones genuinely coming, not for an imagined omnichannel empire. You can always structure further later when a real need appears.
Confusing the tool with the discipline. Buying a headless CMS or a content hub and assuming structure will follow. The tools help enormously, but if you pour page-shaped thinking into them, you get page-shaped content in a fancier container. The structure has to happen in how you model your content, not just in what you buy.
None of these are reasons to skip structuring. They’re reasons to do it proportionately: structure what needs to travel, break it into genuinely useful pieces, build for real channels, and remember the discipline matters more than the tool. Done with that restraint, structuring for omnichannel saves enormous effort. Done as a maximalist exercise, it becomes its own burden.
The stuff worth remembering
- The omnichannel problem is usually a structure problem. Content built shaped like a website only fits a website, so every new channel becomes a rewrite.
- The fix is to stop building pages and start building pieces: clean, self-contained chunks that don’t assume where they’ll appear. A page is just one arrangement of pieces.
- Underneath it all is separating content from presentation. Store the meaning, not the styling, and let each channel apply its own presentation.
- A piece travels well when it has a clear type, is broken down sensibly, carries no presentation, has explicit relationships, and includes useful metadata.
- Update a shared piece once and every channel using it stays current, because they point at the same piece rather than holding copies that drift.
- This is the same principle behind headless CMS and content hubs, but it’s a discipline first and a tool second. Page-shaped thinking in a fancy tool still gives you page-shaped content.
- It goes wrong through over-structuring, atomising too far, building for channels you’ll never have, and confusing the tool with the discipline. Do it proportionately.
Want help structuring your content so it travels?
This works best with a content lifecycle behind it, a content hub to manage it, and solid digital asset management.
The useful version of this conversation starts with the content you’re currently maintaining in more than one place, and which types genuinely need to reach multiple channels, not with buying a platform and hoping. If you’d like a second opinion on how to structure your content so one version can serve many channels, get in touch and we’ll work through it with you.