What is a Template?
A template is a page shape: an ordered stack of sections that renders one whole page on your site. A connected template binds to a content type and renders every entry of it at a URL pattern, so one template produces many live pages.
If a section is a part of a page, a template is the whole page made of them.
Do It With a Skill
understand-templates is this page as a conversation. build-connected-template builds one.
curl -fsSL https://studio-documentation.contentstackapps.com/install.sh | sh
Templates Hold Sections, Not Fields
A template is a page-level container, and sections fill it. Templates do not model fields directly. Each section inside carries its own binding to a content type, Group, Block or Reference.
That makes the order fixed: build the sections first, then arrange them into a template. If you want to put a raw field on a page, build a section for that shape first. Bindings travel with sections, which is what makes them reusable across templates.
A template’s only job is which sections, in what order, with what per-instance overrides.
One Template, Many Pages
A template called Blog Post holding three sections:
Template "Blog Post" ├── BlogArticleHeader (title, subtitle, cover) ├── ArticleBody (rich-text body and side rail) └── RelatedPosts (grid of three other articles)
Connect it to the blog_post content type and publish twelve entries. Each entry’s URL resolves against the same template, so one template renders twelve live pages, each driven by its own entry. Nobody touched code to add a post. An author created an entry.
| Connected to | Renders |
|---|---|
| blog_post | /blog/the-launch-post, /blog/why-studio, … |
| product | /products/widget-a, /products/widget-b, … |
| case_study | /case-studies/acme, /case-studies/globex, … |
The template defines the shape. The URL pattern, such as /blog/{{entry.slug}}, defines the path. See URL variables for everything a pattern can contain.
How a Template Becomes a Live Page
- You author the template in Studio: drop sections, arrange, save.
- Studio stores it as a composition spec. Data, not code.
- A visitor requests /blog/the-launch-post.
- Your app’s catch-all route mounts <StudioComponent />, which calls fetchCompositionData for that URL.
- The SDK matches the URL against published templates and finds Blog Post, because its pattern matches an entry.
- The spec comes back with every section and component the template uses, bindings resolved against that entry.
- <StudioComponent /> renders it with your React components, your design system, your bundle.
No special server, no static export, no per-page code. A new entry gets a live URL because the template plus the entry are already enough.
What the Author Sees is What Ships
Opening a template in Studio iframes the environment base URL plus the resolved page URL, not the canvas URL, which serves sections only. Your route mounts the same <StudioComponent /> used in production; it detects Studio’s iframe and renders the unsaved working spec instead of the published one.
Same renderer, same components, same data. Only the saved-versus-published variant differs. The Preview Entry control in the top bar swaps which entry the canvas draws against.
Why Connected Templates Suit Almost Every Page
- They scale with content. A new page is a new entry, not a new template.
- They auto-bind. template.* resolves against the connected entry through linked schemas, with no per-binding wiring.
- They support URL variables, so the path can be derived from the entry.
- They inherit content-type governance: validation, locales, variants, workflows, scheduled publishing and role-based access.
- They cover one-off pages too. A homepage, an about page or a contact page has a stable shape; model it as a content type with a single entry.
Freeform templates are the exception, for a page tied to no single entry.
What a Template is Not
| Misconception | Reality |
|---|---|
| A template is a React component | No. It is composition data: which sections, in what order, with what overrides. The React lives in your repo and is referenced by ID |
| I need one template per published page | No. One connected template renders one page per entry of its content type |
| A template and a page are the same thing | A template is the recipe. The recipe plus one entry is a page; the same recipe with another entry is a different page |
| A template cannot change once created | It can. Save it and every page using it re-renders with the new layout |
A Mistake Worth Avoiding
New users often skip sections and templates and drop atomic components straight onto a route. It works on day one and kills reuse: every page becomes a one-off composition that transfers nowhere.
The pattern that compounds is the full ladder. Register atomic components, compose them into sections, arrange sections into templates, and let templates render the pages.
Next
- Templates: the chapter, including the Templates tab
- The connected content type: choosing what a template binds to
- Use sections and components: what can go on a template
- Templates or sections?: which one a given problem needs
- build-connected-template: have an LLM create one with you