Updated on November 13, 2024
·Originally published on March 15, 2022
Years ago, when I was developing websites, I wanted something that would empower my non-developer clients to make updates to their content without having to call me — and so I opted for traditional content management systems (CMSes) packaged with what you see is what you get (WYSIWYG) editors.
This approach worked for smaller websites with only a handful of pages, but for larger websites with hundreds of pages, or with information that changed constantly, it involved a lot of work, and created a lot of problems. Most of those problems came down to the need to manage unstructured content.
In this context, “unstructured” essentially means content that is lumped together with code in the content management system, with no format distinction made between its component parts. In theory, unstructured content can be copied and pasted between different pages, and modified with a CMS’s WYSIWYG editor, which is why it seems fairly simple for non-tech users to get involved in updates. In practice, however, working with unstructured content requires a lot of tedious work and an increased likelihood of errors and glitches creeping into the code and breaking the website.
It’s perfectly possible for non-tech users to get involved in web content management — but realizing that goal might mean thinking differently about how you store and use content within your CMS.
In other words, letting go of your unstructured past, and embracing structured content.
In this post, we’re going to find out why structured content is the future of digital content management, how it helps you build stronger websites and apps, and how you can take your first steps toward using structured content in your tech stack.
Structured content refers to web content that can be broken down into, and organized by, its component parts. Structured content is definable, predictable, and understandable by its relationship to the content around it.
In a content management system and, by extension, on a web page, that means content that is identifiable by its type or its purpose. For example, content that is identifiable as a “header,” like the one you just read (“What is structured content?”), or as “body text,” like you’re reading right now! There are plenty of other types of content (hero banner, image, image caption, author, etc.) and many are being used in the structure of this page.
It can help to define structured content against its counterpart. In an unstructured content environment (the kind you’d find in traditional CMSes), content is all hard coded in the same way, regardless of how it's laid out visually on the page. So, from a coding perspective, there’s no functional distinction between components such as a header or body text.
Structured content does make that functional distinction, and assigns each content component an identifying layer which describes what it does on the page — header, image, hero, text — and how it is related to the content around it. That layer is machine-readable and so CMSes can identify the content types that make up the structure of a given piece of content.
Why opt for structured content? The answer to that question has a lot to do with what businesses and brands want and need their digital content to do for them, and gets us closer to the situation I was talking about earlier, in which non-tech users can be involved in content management. Let me explain.
If you’re running a website, you could take the different components that make up a structured content piece and reuse them in other parts of your website, because you know exactly what each component does functionally, and how they relate to other content elements.
That means you can define rules to govern your content components, and apply those rules in a CMS to build pages. A CTA component, for example, could be made up of a line of body text, and a link, while a hero banner could be made up of an image and a header — and you can just keep using those components, like building blocks, to structure your web pages, regardless of the underlying code.
Here’s an example. A particular CTA component, a button which reads “Contact Us,” could appear on multiple pages on your website, serving as a link to your company’s contact page. In a structured content environment, you wouldn’t need to rewrite the same header every time you wanted to include it because you could just retrieve the “Contact Us” button component and drop it into the structure of your page.
It’s much more difficult to do that with unstructured content because those components can’t just be plucked out of larger content pieces and dropped into other environments.
Sure, it might seem straightforward enough to copy whole or partial sections of a content piece but, as I mentioned earlier, that can get complicated. It’s easy to make mistakes as you copy, and introduce inconsistencies between different pages, or you could just end up spending an inordinate amount of time tediously pasting the same chunk of content across hundreds of pages. Even worse, you could drop in content in a way that ends up breaking the code for that page, which would then require a significant intervention (from someone like me) to fix.
The bigger and more complex your website (or digital channel), or the more frequently your content changes, the less suitable the unstructured approach becomes. As a developer, I have firsthand experience trying to wrangle unstructured website content on traditional CMSes — which tend to use HTML-based content editors. There were three primary issues:
Writing HTML seems simple, but it’s not. My clients wanted to do more with their websites, so they’d go on the internet, find a snippet of code to copy, and paste it into their editor. Then they’d call me to take a look when things went wrong.
HTML is not portable to other channels. If my client wanted to ship content to mobile apps, social media, or different kinds of devices, I’d have to untangle the content from the code.
I couldn’t use my favorite technology. I like to play around with my technologies, such as everything Jamstack, when I’m building things for other people. Unstructured systems that mix HTML, XML, CSS, and JavaScript all together were holding me back.
Those are just a handful of ways that unstructured HTML-based content doesn’t align with the needs of most brands and businesses, especially if they’re trying to expand or keep up with their customers’ content appetites.
On that note, what else does structured content do for us?
Structured content isn’t just a means to side-step annoying HTML challenges. Let’s look at the key benefits:
I’ve touched on this, but structured content can be used, and reused, infinitely within the right infrastructure. I’m not talking about reproducing highly unique context-specific content, like blogs (although you could do that), but other assets, like product reviews, service details, author bios, and case studies. In a structured content environment, these components are typically stored in a database, and then retrieved and dropped into pages when they are needed, quickly and easily. Even better, the structured content approach removes the manual copy-paste tedium of content replication.
Structured content boosts your website’s visibility in organic searches, since labeling and categorizing components helps you to indicate what search engines, and readers, are going to find. You’ll need to apply some judgment about the keywords and metadata that you use for certain content components, but by taking the time to do that, you’ll be helping search engines index and categorize your site.
The inflexibility of unstructured content doesn’t just restrict its use within a website: you also have to adjust it to work across different online channels, such as phones, tablets, watches, and ereaders, and the expanding internet of things (store displays, fridge displays, and so on). Structured content is different because its components are untangled from a specific code environment so you can use them across presentation layers to help create omnichannel experiences. This means that, if you write a product description, for example, you can use that same component on your desktop site, your mobile app, on store display screens, or anywhere else that your CMS reaches, without worrying about formatting or other code-related catastrophes.
Remember the goal of having non-tech users involved in content management? A structured content environment allows us to do that since it enables users to create content, edit, and revise that content, and publish it to the relevant channel from the comfort of the CMS, without any need for coding experience or expertise. The CMS handles the technical heavy lifting and, as long as all the structural components of the content are sound, the content should work anywhere.
It’s arguably an extension of the accessibility benefit, but structured content is also more efficient to produce. Not only can users take content from draft to publication faster, without worrying about technical difficulties, but marketers and other stakeholders don’t need to grind out the same pieces of content ad-nauseum, can update similar content components with the click of a button, and even A/B test new content across different channels.
We’ve talked a lot about reusing content, but structured content also makes it easier for you to create different experiences when you need to. You can use structured content to personalize digital experiences for specific brands and audiences, or localize for specific regions. That flexibility can help you target audience segments, take advantage of regional holidays or events, and deploy content in different languages.
Before you begin structuring content in your CMS, you’ll need to understand what kind of structure your content needs. You’ll do this via content modeling.
Content modeling is the process of determining what content types you need for your website, how they will be organized, and how they’ll function as part of a structured content environment. As you develop your content model, you’ll need to think about how your content helps you communicate, including what your audiences are looking for.
In an ecommerce website, for example, a product page built with structured content would typically need some or all of the following components:
Title
Product description
Product images
Product video
Customer review
Price
Shipping costs
Delivery time
Stock information
Sharing button
That list isn’t exhaustive, and would vary by brand and retailer, but would help developers to begin to model the structured content they’ll need for their site, and understand how individual components relate to each other.
A content model is the bare bones of a structured content framework, so you’ll need one before you can start creating content.
It can help to approach the modeling process in the following way:
Discuss and develop a content strategy that aligns with your business goals. Your strategy will help you identify the content you’ll need on your website and how it can be broken down into content types. Be systematic in your approach in order to capture as many functionalities as possible.
Establish your content types and their relationships by studying existing content, or content that you know will be needed to populate your website. Take the ecommerce example above: if you have existing content pages, you can begin to break each page down to its component parts: title, description, price, and so on. Think about how individual components are, or will be, meaningful: for example, do you need a “currency” component if you’re selling in multiple foreign countries?
You may need to define new content types to meet design and business goals, or even map out an entire structured content framework from scratch. New content types will necessarily involve new structural relationships, and you’ll need to make sure that you can leverage your CMS to implement them.
Going back to our hypothetical ecommerce site: if you’re creating a product review page from scratch, you may need to define a few new content types, perhaps “expert review” and “customer review” components. Then, you’ll need to think about their structural relationships with existing content such as product description, product image, product category link, and so on.
If you’ve mapped all the different content types that your website will need, including their structural relationships, you can pull all that data together and start building out your content model. We won’t dive too deep into the content modeling process here, but certain software tools can help, including a visual modeler or the content type definitions within your CMS.
If you’re ready to start content modeling, or want to know more about how to get started, have a look at Contentful’s content modeling basics.
I’m possibly preaching to the converted by now, but I cannot repeat this often enough: Your content should be structured and ready to go wherever you want to have it.
The Contentful® Composable Content Platform is designed around managing structured content. It makes it possible for you to break down your content into its smallest meaningful components so that you can build any experience you want, and then deliver impact at scale, across any channel.
Let’s explore how we do that.
Contentful provides a set of APIs that deliver structured JSON. Using APIs with structured content enables developers to build whatever they want with the content in our platform — websites, mobile apps, and omnichannel digital experiences. All you have to do is make an API call.
Because making API calls is (pretty much) supported across all languages, platforms, and frameworks, developers using Contentful can choose any technology that they like.
Here’s a summary of the Contentful APIs:
A Content Delivery API, which is read only and RESTful. Use this to pull in the digital content that’s ready for production.
A Content Preview API, which is also RESTful and read only. Use this to build preview functionality so editors can see how content will look in a mobile app or on a web page before they hit publish.
A Content Management API, which is a read-and-write API. This API allows you to change content, add content, and create new content. It’s how you control the content that you put into Contentful. We also provide an editing interface that sits on top of our content management API.
An Images API for managing and transforming images stored in Contentful.
A GraphQL API that lets you query any data that you want.
Below is an example of how Contentful helps you model your structured content, breaking down smaller pieces so that they can be easily assembled into different experiences across channels and devices.
In this example, we’re building a structured content tree of reusable pieces like metadata, navigation, and the slug. You can use all these pieces together when you’re building a page, but you can also use them one by one.
This approach means all your content is reusable, and is just one API call away. You decide what kind of data structures your project or website needs, and then tell the platform to fetch smaller or larger chunks of your content.
All of the above is great for developers because it gets the CMS out of their way, but we want editors to be happy too. And whether you’re an editor, a content marketing manager, or a content strategist, the user experience is where Contentful really delivers.
Since it lowers the technical barriers to content management, a structured content model gives creators the space and security to add the right content in the right places, including strings, numbers, and images, to name just a few of the field types Contentful provides. Got an SEO specialist on your team? No problem. They'll be able to use structured content to start pushing you up the rankings on search engine results pages.
Contentful's structured content approach is designed for flexibility. To create longform content like case studies and white papers, we created a Rich Text field. It’s similar to a WYSIWYG editor, but with some key differences:
The Contentful Rich Text field is stored as pure JSON rather than HTML.
The field can be customized to provide guardrails for editors. For example, you can limit formatting options to provide a consistent look and feel across content entries.
Entries and assets within Contentful can be linked dynamically and embedded within the flow of the text.
With this, and other fields within Contentful, developers can build up a visual entry editor that empowers editors to publish more and more in a predictable way — without needing developer support, and without any fear of breaking things.
And, unlike traditional HTML-based editing, structured content in the Contentful platform is easy to reuse and manage across multiple channels. Editors can save time by updating content in one location, and then see it automatically update in all the other places that it’s been used.
If you want to know more about how Contentful works, take a look at our structured content webinar, where I go into more detail, and we do some live coding on the platform. You’ll see exactly how we define both structured data and structured content, and set up an example project using Next.js and Contentful’s GraphQL API.
If you’re ready to begin your structured content journey, so are we. You can sign-up for a free Contentful account today to get started.
Subscribe for updates
Build better digital experiences with Contentful updates direct to your inbox.