How structured content is different in headless CMSs

What’s different about headless content management?

Let’s cover a few characteristics of headless content management that you’ll care about as a writer, especially for those who aren’t familiar with the approach.

Unlike most CMSs, a headless CMS doesn’t decide how content is displayed. There’s no one way to present the content. How the content is displayed to customers will depend on the destination where it appears. In fact, the same content might be displayed in several different ways—all at once! Headless allows content published to many different platforms: multiple websites, apps, kiosks, wherever you want. Designers have lots of options about how to present the content when using headless. It supports enormous creative freedom and the ability to provide the most up-to-date experiences without requiring any modification to the content. That’s possible because content is independent of its presentation.

Because writers aren’t distracted by how the content is styled or rendered, they can focus on the content itself. In a headless CMS, the content is structured according to its meaning and purpose. Bigger content themes and topics are broken into chunks that get used in multiple ways. Writers create chunks of content that can be assembled and presented together as larger items. The structuring of all the chunks of content is handled by what’s called a content model within the headless CMS. 

How these content chunks are directed to where they will appear happens through something called an API. APIs connect the various user interfaces where people access content (websites, smartphone apps, chatbots, or wherever) with the content model that manages the chunks. That allows the content that’s seen by users to match what they need. Again, it’s a big win for the customer.

Headless is gaining adoption because it makes content more flexible. Many vendors are now offering headless CMSs, including a few who are surfing the wave of popularity with products that don’t really work the way a headless CMS is intended. 

So, if you are curious what makes a headless CMS distinctive, keep in mind these three characteristics:

1. It only deals with the content—it doesn’t force you to render the content into a presentational styling, layout, or format.
2. It allows you to structure the content into chunks that are managed by a content model.
3. The chunks are free to move around to where they are needed on the front end via an API.

Bottom line: the headless approach gives publishers more control over how they can use content compared with other content management approaches. 

Leverage the full benefits from structuring content

Structuring content gives it greater clarity, precision, and flexibility. It makes content better—for both content creators and content users. Here are the main benefits of structuring content—if it is done right:

1. It helps writers and editors focus on the purpose and meaning of different chunks.
2. You can track how different chunks perform.
3. It can be faster to create or revise a chunk once and use it many places, rather than duplicate it.
4. You can reuse chunks in different ways, making the content more versatile.
5. Customers can get the precise chunk they need where they need it.
6. Developers find accessing chunks via an API easier than accessing big blobs of content.
7. The designs that customers view and use are more interesting and enjoyable because the content is structured rather than formatted in advance.

While structuring content can provide numerous benefits, that doesn’t mean that any approach to structuring content will deliver them all. It’s important to choose the right approach. 

How the structuring of content can vary

Think about content as coming in two flavors: structured and unstructured. For many years, content strategists have referred to these flavors by the monikers of chunks (for structured content items labeled with clearly defined meanings) and blobs (for unstructured content objects where the inner meaning of the text isn’t clear). 

When structured, the item can be reordered, reused, moved around, and combined easily with other items. And structured content can be used on any platform, because it is pure content.

Karen McGrane notes in her book Content Strategy for Mobile: “What happens to that giant blob of stuff—that’s the technical term—when it’s time to put it on another platform? Your content can’t be broken up into smaller pieces for display and reading on different screens. Your content can’t be targeted differently to different platforms.”

So far it seems straightforward: structured content is good, blobs are bad. You want to convert blobs into chunks.

But there’s another dimension to consider that gets overlooked: changes over time. We need to ask: At what point is the content structured, and when might it stop being structured? Many people who seek the benefits of structured content don’t notice that their chunks begin reverting to a blob-like state when they aren’t watching. 

How chunks lose their chunkiness

When a chunk gets formatted into a bigger piece, it loses its independent identity as a chunk. The content within the chunk gets locked in place within the formatted content. Even the routine creation of a web page in HTML will start a process of change: the meaning of the individual chunks is degraded, and the content becomes less flexible. The independent chunks transform into elements to display within the body of a page. The autonomy of the individual chunks appearing within the page is lost, and their distinct meaning becomes less clear. 

Obviously, this rendering needs to happen sooner or later, but you’ll have more flexibility if you can delay this formatting of the larger content item until the user is ready to access the content. You want to preserve the meaning of the chunks you have created.

Many content creators start with the best of intentions to structure their content, but they don’t realize their structuring has lost its punch after they’ve worked on it. Fortunately, headless CMSs are designed to prevent such problems.

The first way chunks get lost is when writers use a “structured writing” tool outside of the CMS. They organize their writing in a clear and logical way. But when it gets pulled into their CMS, the structure gets lost, and it becomes a bunch of text that doesn’t have a formal structure.

The second way that chunks can vanish is when the writer’s CMS structures the content within a content model, but the content gets fully formatted before the user is ready to access it. The CMS turns the chunks into one big object before the content leaves the CMS on its way to the user. In some cases, that’s not a problem if the user wants to see exactly what’s delivered and doesn’t need to request anything relating to the content. But as soon as the user decides they want to interact with the content in some way, the formatted asset is hard to adapt because it is no longer chunky. 

Keep your content chunky

The distinctive value of the headless approach is that it helps you keep the content chunky. You never lose the structure you created. It sends the structured content to the user’s screen via an API. The headless content API preserves the structure of the content. APIs in monolithic (non-headless) CMSs, if used, don’t preserve the structure like this.

The user interface can read the content structure and decide the chunks to display. It can request updates for chunks. The interface with which customers interact is able to talk directly to the content model that’s organizing the details of the content. That allows the chunk of content to be updated or switched out if appropriate. Readers can access content that matches their situation and responds to their requests, instead of settling for a fixed page of text.

When the structure is preserved throughout the whole process of the content—from creation to access—the content is genuinely adaptive. It’s able to respond to the reader’s needs.

Content structuring after headless

Headless CMSs have enhanced the value of content structuring. It’s no longer primarily an internally focused activity centered on making content creation more efficient. While headless maintains those benefits, it adds an even more important benefit: improving the user experience of the content so that it delivers more value to customers and the publisher. 

Before headless, content structuring was a discrete phase of the content management process. After headless, content structure is baked into the DNA of the content. The structure is used throughout the whole content process, from creation to access.

Don’t assume that because you structured your content when you created it, itʼs ready for anything. You need your content model to connect with an API that understands that model. Headless content is still structured when the customer is ready for it. Finally, your content will truly be prepared for anything.