# Structured Content Explained

> Source: https://agilitycms.com/docs/developers/structured-content-explained

**Structured content** means storing content as named, typed pieces (a title, a date, a price, an author, a list of features) instead of as finished pages. The pieces are defined by a model, so every item of the same kind has the same shape. Your website, app or any other channel then decides how to present them.

It's the idea that the rest of Agility is built on. This page explains it in plain terms, shows how Agility implements it, and lists what it costs as well as what it gives you.

## Pages versus pieces

Imagine an event announced on a website.

**As a page**, the event is one block of formatted text: a heading, a paragraph with the date and venue somewhere in it, a photo and a "Register" link. It looks right on that page. But a computer can't reliably tell which part is the date, so it can't sort events by date, show "upcoming events" in an app, put the event in an email, or hide it once it's over.

**As structured content**, the event is an item with fields:

| Field | Value |
| --- | --- |
| Title | Spring Open House |
| Start date | 2026-04-18 10:00 |
| Venue | Main campus, Hall B |
| Summary | Tour the labs and meet the faculty. |
| Image | (an image asset) |
| Registration link | (a URL) |

Now any channel can ask for "events after today, sorted by start date", and each channel lays them out its own way. The content is written once and reused everywhere it's needed.

## How Agility structures content

![Diagram of the Agility data model. A top row of models (page model, component model, content model) defines a row of instances below it. The sitemap maps the URL /blog/first-post to page 4 and content item 6. Page 4's main content zone uses a PostDetails component, the component displays content item 6 (a Post), and that post links to an Author content item.](https://cdn.aglty.io/agility-cms-docs/images/training-guide/docs-diagram-data-model.svg)

Agility separates **models**, which define structure, from the **content** created from them:

- **Content Models** define a kind of content, such as Event, Post or Author, as a set of typed fields: text, rich text, dates, numbers, images, links, choices and more. Items are kept in **content lists** (or as single items).
- **Linked Content** fields connect items: a post links to its author, an event to its venue. Shared content is written once and linked wherever it's used.
- **Component Models** define the blocks editors place on pages, such as a hero or an event listing. A Component can hold its own fields or display content items.
- **Page Models** define page templates as zones where Components can go.
- **The sitemap** maps URLs to pages.

So a website gets pages built from Components, while an app or another system can ignore pages entirely and read the content lists directly. Both read from the same structured content through the APIs: the Content Fetch API (REST), GraphQL, or Content Sync. See [Beyond the Website](/docs/developers/beyond-the-website).

## What it gives you

- **Reuse across channels.** The same items feed the website, apps, email and other systems, because no channel's layout is baked into the content.
- **Consistency.** Every item of a kind has the same fields, required fields can't be skipped, and validation rules (such as a maximum length or a pattern) are checked as editors work.
- **Querying.** You can filter and sort on field values, for example events by date or articles by category.
- **Redesigns without re-entry.** A new design is a front-end change. The content stays where it is.
- **Translation at the right level.** Each locale holds its own field values, and fields that must never differ can be kept constant across languages.
- **Content that machines can read.** Search indexes, structured data for search engines and AI agents all work better with labeled fields than with a block of HTML.

## What it costs

Structured content isn't free, and it's worth knowing the trade-offs before you start:

- **You design a model up front.** Someone has to decide what the content types and fields are. A poor model is expensive to change once content exists. See [Content Modeling Anti-Patterns](/docs/developers/content-modeling-anti-patterns).
- **Your front end does the presentation.** Agility delivers content through APIs; your developers build how it looks, in the framework of their choice.
- **Editors work in forms as well as on pages.** Agility's visual editing ([Web Studio](/docs/overview/web-studio)) and page management keep page-building visual, but structured fields are still edited as fields.

For most teams the trade is worth it as soon as content is reused in more than one place, or needs to outlive the current design.

## Questions to ask about your own content

- Which kinds of content do you have, and what fields does each one need?
- Which content appears in more than one place?
- Which values do you need to filter or sort on?
- Which channels need this content now, and which might need it in two years?
- Who maintains each kind of content, and what do they need to see while editing?

The answers are the start of your content model.

## Related

- [Content Architecture](/docs/overview/content-architecture)
- [Content-first Approach](/docs/developers/content-first)
- [Data Model Deep Dive](/docs/training-guide/architect-data-model)
- [Nest, Link or Share? Choosing Linked Content Field Types](/docs/developers/linked-content-field-types)
- [Beyond the Website: Apps, Kiosks, Email and In-App](/docs/developers/beyond-the-website)