Setting Up Collections and Entries in Statamic: A Flexible Content Structure

Statamic: why content structure breaks as a project grows

At the start, content structure in Statamic barely requires any decisions: one collection, a dozen fields, a template outputs them directly.

Problems begin at the second or third dozen content types, when content managers ask for "one more block on the service page," and the developer adds fields point by point — and six months later the collection contains three variants of the same heading, half the entries are unfilled, and some fields duplicate data from related entries.

Then coherence breaks. Entries reference each other through free text instead of a relation field, and when a section is renamed, the link quietly turns into a broken one.

Queries start being assembled manually in the template, filtering logic sprawls across several files, and no one remembers anymore which field is required and which is left over from an old iteration.

The third typical failure is manual template edits with every new section. Adding a block turns into a task for the developer: editing the markup, checking across all page types, regression on neighboring ones.

The content team waits, the developer spends time on mechanical work instead of product development, and the speed of shipping new pages drops.

The root of all three failures is the same: the structure grew around the current task, not around the domain model.

Collections and entries in Statamic provide flexible fields and inheritance, but without a pre-designed schema — blueprint, field sets, relations-based links — flexibility turns into entropy.

Let's break down how this is addressed at the level of content architecture rather than patches in templates.

What a managed content structure provides

When content structure is described in configuration rather than "in the editor's head," it's not just the speed of work that changes — the class of tasks that arise at all changes. Let's break down exactly what a managed model on Statamic provides and how it's measured.

Publishing speed. Fields, types, and relationships are defined in advance: the editor fills out a form rather than assembling a page from blocks manually.

Material goes out in minutes instead of hours, and a new section is added by changing a set of fields, without rewriting templates.

Data consistency. The same record type always has the same set of attributes — dates, authors, categories, images. This eliminates discrepancies between sections and makes queries predictable: what works on one page works on ten.

Fewer manual edits. Relationships between records (category → material, author → publications) are described by references rather than by copying text. Changed the category name — it updated everywhere. Less manual synchronization — fewer edits after publication.

Predictable output. Templates receive data in a known form, so the layout doesn't "drift" when new materials are added. This eliminates an entire class of errors: broken relationships, empty blocks, duplicates in lists.

Eliminated class of relationship errors. When a record references an entity rather than its text, deletion or renaming doesn't break pages — the system will indicate where the relationship is used. Errors are caught at the editing stage, not in production.

Bottom line: the team spends time on content and development, not on dealing with the consequences of manual edits.

Approaches to organizing collections and entries

In Statamic, content structure is defined not by database tables but by files: a collection is a folder with entries and its own set of fields (a blueprint), and relationships between sections are built through relationship fields.

This gives rise to three working schemes, and the choice between them determines how easy it is for an editor to publish and for a developer to migrate and extend the project.

How to choose in practice

A single collection with a type field works well as long as the types differ by one or two fields: the editor sees one section in the panel, and the developer doesn't multiply templates.

As soon as a type gets its own publishing logic and its own relationships, conditional fields turn into a fragile construct, and it's cheaper to split it into separate collections.

The hybrid scheme is a compromise for large sites: shared field sets (author, cover, tags, SEO) are moved into reusable blueprints, and each collection includes them and adds its own.

Relationships between sections are made through relationship fields and taxonomies, so a single entry can simultaneously appear in the blog feed, in a service selection, and in a "related" block — without duplicating content.

We lock down the collection scheme before layout: it's cheaper than rebuilding the structure once hundreds of entries have already been loaded into it.

How we design and implement structure

We start designing the structure not with code, but with a content audit: we export all current materials, mark up the entity types and the relationships between them.

At this stage it becomes clear where content is duplicated, where it lives in free-form text blocks, and why editors assemble the page manually every time. The audit produces a map that the data schema is then built on — without it, any collection setup turns into guesswork.

1. Content audit. We build an inventory: what types of materials exist, who creates them, how often they are updated, which fields are actually filled in and which remain empty. Separately, we record the places where an editor asks a developer to "fix the text" — this is a marker that the structure does not cover the need.
2. Relationship schema. We sort entities into collections and define the relationships: what references what, where a one-to-many is needed, and where a taxonomy is enough. The output is an agreed schema that shows how a page is assembled from blocks and what queries will be needed.
3. Setting up collections and fields. We create collections, field sets and output templates: text, media, relationships, repeatable groups. We make fields required where the layout breaks without them, and leave them free where the editor needs flexibility.
4. Output validation. We run real scenarios: create a material, publish it, see how it is rendered on the page, in lists and in search. We check that relationships do not break when a parent is deleted, and that drafts do not leak into public output.
5. Handover and training. We show editors how to add materials and fields, and provide a short guide and a recording of the walkthrough. After that they work with content on their own, without going to developers for every edit.

This order removes the main pain point — the structure grows together with the content instead of breaking on the very first new page type.

What the client is left with after implementation

After implementation, the content structure lives in the repository, not in the developer's head. Collections, fields, relations, and templates are described declaratively — as configuration files that are versioned alongside the code.

This means the structure can be moved to another environment with a single command, a change can be rolled back, two branches can be compared, and you can see exactly what changed in the data model.

The editor gets a clear interface instead of "raw" pages: fields are labeled, required ones are marked, and each record type has its own set of attributes.

Publishing stops being a manual operation of "editing a file on the server" — it follows a procedure where a piece of content has a status, an owner, and an approval flow. Below is exactly what you are left with.

• Collection configuration — descriptions of all content types: which fields are required, which data types, where versioning and drafts are enabled.
• Relation schemas — how records reference each other: content to sections, products to categories, authors to publications, without duplicating data.
• Output templates — markup for lists and detail pages, pagination, related blocks, handling of empty states and missing fields.
• Publishing procedure — the order of statuses, roles and permissions, what happens when content is unpublished and how it returns to work.
• Instructions for editors — short scenarios for each role: how to add a record, replace an image, translate content, roll back a version.
• Structure map — a diagram of all collections and relations in a single document, so a new developer or contractor can join the project without reverse engineering.
• Set of checks — automated tests for relation integrity and validation of required fields before deployment.

Each artifact is handed over in working form: configurations are in the repository, instructions are next to the project, and access is set up on your accounts. Describe the task — we will come back with an estimate and a plan for what we migrate and in what order.

Case study: how content structure stopped slowing down releases

The client is a media outlet with a catalog and regular special projects, a content team of six editors, and weekly releases.

Before us, the content structure lived in a set of disconnected fields: a material had no explicit relationships with its category and author, and a new section could only be added through a developer.

Publishing a single card took 40-60 minutes, because the editor manually set the relationships and duplicated tags between sections.

We moved the content to Statamic and organized it into Collections with an explicit model: separate sets for materials, categories, authors, and special projects, with relationships between them through relationship fields rather than manual input.

Entries got a predictable structure — the editor selects a category and author from a list instead of creating them anew. Output templates and validation rules were locked in at the set level, so required fields cannot be skipped.

What changed in numbers

We also eliminated a whole class of errors that previously surfaced only in production: when a category was renamed, some materials remained stuck on the old value.

Now a relationship is a reference to a record, renaming is pulled in automatically, and deleting a category is blocked while materials still reference it.

Release speed grew not by speeding up the build, but because content stopped being the bottleneck. The editorial team prepares a special project in parallel with development, not after it, and publishes without involving engineers.

How does a collection differ from a taxonomy in Statamic?

A collection is a container for records of the same type: it has its own set of fields, output templates, and routes. When you create a "Projects" collection, each record inside it gets the same structure — a title, a description, a gallery, a date.

This is precisely the grouping of content by entity type: the editor always knows which fields to fill in, and the template knows how to output the record on the page.

A taxonomy solves a different problem — it does not store content, but tags it. It is a reference list of values that can be assigned to a record from any collection: tags, categories, topics, authors.

A single record can carry several taxonomy terms at once, and this is exactly what filtering is built on — selecting all materials with the desired term without duplicating the records themselves.

The practical difference becomes apparent at the moment when content needs to be reused. If an entity exists on its own and has its own page, it is a collection. If a value merely helps group and filter already existing records, it is a taxonomy.

Mixing up these roles leads to duplicates: trying to make a category into a collection produces empty pages and extra entities in the tree.

In practice, they are almost always combined. A "Articles" collection defines the structure of a publication, while the "Topics" and "Authors" taxonomies provide cross-cutting navigation and filters across the archive.

The editor fills in the fields once, and the system itself assembles term pages with a list of related records — without manual duplication or desynchronization.

Routes and relationships deserve separate consideration. A collection has a URL template configured for each record, while a taxonomy has addresses for term pages.

The relationship between them is described in the collection settings, so adding a new term does not require code changes — only an entry in the reference list. This is what provides a flexible content structure that scales without rewriting templates.

Common technical concerns before starting

Before starting, almost every team asks the same set of questions: what will happen to the content already accumulated, will templates have to be rewritten, how long will it take, and who will stay in touch after launch. Below are direct answers without marketing, so you can compare them with your situation.

Are the new templates compatible with the current design and markup?

Yes. Templates are transferred to the new markup system, the visual part and block structure are preserved — only the layer responsible for data output changes.

If the current markup has non-standard components, they are described as separate templates and reused across all pages. As a result, you get the same markup, but with a manageable content structure.

How long does implementation take and what does the timeline depend on?

A basic launch with content migration and Collections setup takes several weeks. The timeline grows if the project has many record types, complex relationship logic, or requires integration with external services.

We provide an exact estimate after reviewing the current structure — then it becomes clear which blocks are transferred as is and which need to be redesigned.

What is included in support after launch?

Support includes system updates, backups, availability monitoring, and refinement of the content structure as the project grows. Separately, we establish a regulation: how new record types are added, who is responsible for content, and how changes are rolled back. This removes dependence on a single developer and makes the system predictable.

Describe your task and current stack — we will get back to you with a timeline estimate and a migration plan.

Let's discuss your content structure task

To come back with an estimate and a plan rather than generalities, we need to understand your subject area and the current state of your content. Below is what we clarify during the first conversation and what input data we ask you to prepare.

This is not a formality: these details determine how many collections to set up, which fields to make required, and how to build relationships between materials.

What we clarify about the task:

• What content types exist now and which will appear: pages, articles, product cards, case studies, job openings, events.
• Who edits materials and how often — a single content manager or several teams with different permissions.
• Whether multilingual support, versioning, drafts, and scheduled publishing are needed.
• How content is related to each other: categories, tags, authors, related materials, recommendation blocks.
• Where the data comes from — manual entry, import from an external system, synchronization with a catalog.
• Which sections are already laid out and what needs to be preserved unchanged, and what we are restructuring.

What we ask you to send:

• A list of content types with examples of real entries — 2-3 for each.
• Prototypes or links to current pages so we can see the structure of fields and blocks.
• A description of roles and permissions: who creates, who approves, who publishes.
• Requirements for search, filters, and sorting within sections.
• If available — the current data schema or an export, so we can estimate the volume of migration.

Based on this, we design the structure of collections and fields, estimate the effort, and come back with a plan: which collections we create, which fields and relationships we configure, in what order we migrate content, and how we verify the result. Describe your task — we'll come back with an estimate and a plan.