Structured Content Explained: Fields, Reuse, Limits

Structured content is content stored as separate typed fields, not one blob of formatted text. A blog post becomes a title, a slug, an author reference, a publishedAt date, and a body. Each has its own type. That's it. Why care? Reuse. Fields can be queried, checked, and sent to a website, an app, and an email with no rewriting. Draftbase is built on this idea, and the structure is what makes MDX components with typed props work. This guide covers what counts as structured, what doesn't, the term people mix it up with, and the test that tells you your model is leaking. The headless CMS pillar has the wider context.

What is structured content?

Content that follows a schema. Every piece belongs to a type. Every type names its fields. Every field has a data type and a job.

The opposite is one rich-text field holding everything. Take a WordPress post body with the author's name typed into the first line. You can read it. Your code can't, not reliably. Neither can anything else you might send it to.

Draftbase calls the schema a template. Fields are typed: text, richText, number, boolean, date, media, reference, and JSON. Any of them can be localized. The type isn't decoration. It's what lets the API hand back a real date instead of a string that looks like one.

The quick test for whether content is structured

Ask if you could change how something looks without editing the content. If making author names bold means opening 400 posts, the name isn't a field. It's formatting pretending to be data.

Why does structured content matter?

Three payoffs, and only one of them gets talked about.

Query. Fields you can filter on. "Every post by this author, from this year, tagged React" is one query against a schema. Against a text blob it's a regex and a prayer.

Reuse. One entry feeds a web page, a mobile app, and a newsletter. Each draws the same fields its own way. The content doesn't know or care what's reading it.

Validation. An empty required field fails at save time, not at render time. That's the payoff nobody mentions. It's also the one that saves your weekend.

Structured content is not structured data

Here's the mix-up that costs people the most time. Both terms are correct. They mean different things.

Structured content is your internal model. It lives in your CMS and names your fields. It exists so your team and your code can work with content the same way twice.

Structured data is markup for search engines. Google calls it "a standardized format for providing information about a page and classifying the page content." It recommends JSON-LD as the format, per Google Search Central. It uses the Schema.org word list to describe what's already on the page.

They're linked in one direction only. A good content model makes the markup easy. headline, author, and datePublished are already fields you can map. A rich-text blob turns it into guesswork.

One rule trips teams up. Google says structured data should only describe content the reader can see on that page. So you can't emit an FAQPage block for hidden questions. Not even if the answers are right there in your CMS.

What structured content looks like in practice

Take a blog post. Here's the same content, modeled two ways.

Unstructured	Structured
One body field with everything	title, slug, author (reference), publishedAt (date), body (richText)
Author bolded in paragraph one	author points at an author entry
Date typed as "Aug 2026"	publishedAt is a real date
Tags written in a footer line	tags is a JSON array

The structured version costs ten extra minutes up front. You get sorting by date. You get an author page listing every post they wrote. And you get a BlogPosting JSON-LD block built from fields, not parsed out of prose.

References are the part people skip. An author reference means the bio exists once. Change their job title and it changes everywhere. The CMS can also refuse to delete an author that posts still point at.

How structured should content be?

There's a real ceiling here, and the vendors selling deep node trees don't mention it.

Split a page into 30 fields and you've built a form nobody wants to fill in. Editors then paste whole paragraphs into a subtitle field to dodge the model. Now your schema describes a workflow nobody follows.

The useful line: structure what you query or reuse, keep the rest as prose. A date is a field because you sort by it. A pull quote mid-article isn't a field, because nothing else reads it. It's a component inside the body.

That's the case for MDX over a rich-text node tree. Prose stays prose. Typed components sit inside it when a section really needs structure. We compared the two storage formats in MDX vs rich text.

What goes wrong when the model is too loose?

Under-structuring fails quietly, which is why it survives longer than over-structuring.

A single body field works fine for a year. Then someone asks for a page listing every article by publish date, and the date is a sentence inside the prose. Now you're writing a parser. Parsers over human writing fail on the tenth case, always, and usually in production.

The second symptom is duplicate truth. The same product description gets pasted into a landing page, a docs page, and an email. Three copies, three chances to be wrong, and no way to find them all when the price changes.

The third is silent drift between entries. One post says "Aug 12, 2026" and another says "12/08/2026" because nothing enforced a shape. Both look fine to a reader. Sorting them puts December before August.

None of these show up on day one. They show up when the site gets big enough to be worth fixing, which is the worst time to migrate a schema.

The cheap insurance is small: give anything you might sort, filter, or reuse its own typed field on day one. You can always render two fields as one line. You can't reliably pull one line apart into two fields.

The underused angle: presentation leaking into your model

Here's the failure mode that kills reuse. It looks like good modeling the whole time it's happening.

Look for field names that describe looks, not meaning. heroImageDesktop. boldSubhead. ctaButtonColor. section2Text. Each one is a design choice that got saved into the database.

Each one breaks the moment a second surface reads the content. Your iOS app has no desktop hero. Your email template has no section 2. So you either ship fields the client throws away, or add heroImageMobile and double the problem.

The fix is a naming rule you can run in ten minutes. If a field name would stop making sense after a redesign, rename it to what the content is. heroImageDesktop becomes featuredImage. section2Text becomes what that section actually says: pricingSummary, warranty, shippingPolicy.

It's also the line between a model that survives a redesign and one that gets migrated during it.

Does structured content help AI systems read your site?

Yes, and more than it helps humans. A model can't guess what a bolded line was supposed to mean.

Typed fields give an answer engine clean edges. A price field is a price. A number in a paragraph might be a price, a SKU, or a page count. That's the gap between a citation and a wrong answer.

We dug into the retrieval side in structured content for LLMs and AI agents, including which JSON shapes models pull from best. Short version: the shape matters as much as the structure.

Where to start

Model the fields you query, reuse, or check. Leave the rest as prose. Then sweep your field names for design words. That's where reuse quietly dies.

Sending content into React, and don't want a renderer per node type? Draftbase stores richText as plain MDX strings with typed component props. You also get references, field validation, and a typed SDK with codegen, so your schema lands in TypeScript. Hobby is free with no card and covers 1,000 entries. That's enough to model a real site before deciding. Startup is $49/mo. Plans are on the page.