Imagine you have a new website project ahead of you. You probably have technologies you’d prefer to work in. Maybe it’s Next.js, SvelteKit, or Nuxt.js. Or maybe you’re curious about the buzz around Remix. You’re pretty sure the styling will happen in Styled Components, or maybe Tailwind is your go-to, or maybe you prefer writing your CSS the good old-fashioned way. Nothing wrong with that!

For your own blog, you’ve got some static site generator that sits on top of Markdown files. It floats your boat and updating the blog is as easy as pushing to your main branch on GitHub. But you don’t want to do that for this website project. Because your clients shouldn’t have to commit to GitHub to get their content out. And you’re not sure if having them write Markdown is going to fly either. So… what do you do?

You figure out that you need a Content Management System – a CMS – that gives your clients a dashboard where they can log in, create, update, and maintain their content. And if you plan to use a modern frontend framework, then you’ll need that CMS to have an API. Because most modern website frameworks come with ways of doing a request when the site builds or renders that can be used inside of its templating language.

Luckily for you, for the last couple of years, there has been a slew of CMSes that offer APIs you can use with your frontend technology of choice. It doesn’t take long before you figure out they’re often called “headless CMSes.” And contrary to “monolithic CMSes,” they don’t come with any way of rendering content as part of their software. They specialize in offering an editorial experience and then delivering content over the API, most often in a JSON format.

After some digging, you’ll also find that people are discussing whether or not a headless CMS is the right fit, and which of the headless CMSes is the best. These solutions are evaluated based on pricing and features, but very seldom on what they actually do to your content. Which, arguably, has some pretty dire implications for both how you can work and the longevity of your efforts. For example, storing your rich text as HTML makes it harder to migrate and integrate.

Headless or not, the big question you should be answering is really about whether the system lets you structure your content in a way that makes sense for your business goals, user journeys, and technical stack. Structured Content is content that is broken down into reasonably reusable pieces that can be presented from a single source of truth, re-composed in different settings, and queried and changed programmatically.

For web developers, structured content is what lets you:

• map content directly to components as data without having to dangerouslySetInnerHTML
• treat content as data in ways that let you build more resilient frontends using modern tools
• use the same content source across components, templates, and even sites and services without requiring editors to copy-paste it across or having to set up sync jobs
• make your content interoperable with other systems in order to make better editorial workflows and better end-user experiences
• find all instances of certain content using queries and easily change it using scripting

Imagine being able to use TypeScript for all of your content, including rich text, or more easily prevent the website from deploying if some crucial content is missing. Or being able to quickly gain confidence that you have migrated everything you need to before making a big change. Or to leverage a product catalog directly, so that editors don’t have to copy-paste stuff over (and keep everything up to date at all times). In other words, imagine having most of the benefits that come with databases – but for content. That’s the potential and value of structured content!

At Sanity.io, we see new cool uses of structured content every day. We’ve seen how it enables teams to work together in different ways, in ways where developers can really empower editors without having to “hack the CMS”. And where you can get the boring stuff done quicker, leaving more room for the fun stuff. We believe that web development is about making remarkable experiences that leave an impression and connect us.

That’s why we’re also inviting developers to Structured Content 2022. To be inspired by folks who have done cool things, to get insights on how digital leaders think about technology choices, and to make some new friends. If you’re reading this, we’re pretty sure you’re one of those who should be part of figuring out more exciting implications of structured content. Welcome – can’t wait to see you there!

Register for Structured Content 2022 now.