Collection Template Pages
|
This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production. This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages. |
This page describes Collection template pages as they were on 2026-10-28, the date on which their facts were checked against the official documentation. Webflow is a hosted service without version numbers, so the behaviour below is dated rather than versioned, and changes are announced at Webflow updates; the Product Changes and Deprecations page tracks what has changed. Collections and their template pages exist on every Site plan that includes the CMS, and the free Starter plan allows a small number of items and Collections so every step can be tried without paying. Plans are named by tier only and no prices are quoted; the limits that depend on the tier are in CMS Limits and Scaling. The one developer snippet uses the Webflow Data API v2 over plain HTTP, so no package version needs pinning.
A Collection template page is the single page design that Webflow reuses for every item of a Collection. The running
example is the Fernbrook Gardens site, a fictitious botanical garden. Its Plants Collection holds one item per
plant, and one template page, designed once, produces /plants/japanese-maple, /plants/lavender and every other
plant page. The Garden Journal Collection works the same way with its own template. This page explains how the
template is made, which settings it carries, how it ties into the Collections and lists described in
Collections and Field Types and
Collection Lists, and what HTML ends up in the browser.
What a template page is
When a Collection is created, Webflow also creates a template page for it. The page appears in the Pages panel in a section for Collection pages and is shown in a different colour from static pages, which marks it as bound to a Collection. Designing it is the same work as designing any page (elements, classes, breakpoints), with one addition: text, images, links and other elements can be bound to the fields of the item the page is showing.
The idea is the classic template-and-content split that every CMS uses, compared in the CMS landing page:
-
the template is shared design: a heading, an image, a rich-text body and a sidebar, laid out once;
-
the item is content: a name, a photo, a description, filled in by an editor;
-
the page is generated for each published item by merging the two.
Three kinds of people touch it. The designer builds and styles the template and decides which fields appear where. The content editor never sees the template as such: they edit an item, and its page follows. The marketer fills in the SEO and Open Graph patterns described below, once, so that every item gets sensible metadata without per-item work.
One page, many addresses
The template page has one design but many URLs. The address of each page is the Collection’s URL segment followed by the item’s slug:
https://www.fernbrook.example/plants/japanese-maple
^^^^^^ ^^^^^^^^^^^^^^
| item slug (a field of the item)
Collection page URL segment (set on the template)
The first part is a setting of the template page: by default it is the Collection’s plural name in lowercase, and it can be changed in the page settings. The second part is the item’s Slug field, which every Collection has and which Webflow fills from the item name when the item is created. Slugs must be unique within a Collection, and changing one of a published item changes the address of its page, so any link that pointed at the old address breaks unless a redirect is added; see Redirects and Site Migration.
Slugs are deliberately simple: lowercase letters, numbers and hyphens. Naming rules and the matching Data API field are covered in Collections and Field Types.
Which items get a page
A template produces a page only for items that are published. A draft item has no page, and an archived item is removed from the live site. The visitor who asks for the address of an unpublished item receives the site’s 404 page. The template page also has a publishing control in its settings: turning publishing off for the template prevents the Collection’s item pages from going live and from being indexed. That is the right choice for a Collection that exists only to feed lists, such as the Opening Hours Collection that Fernbrook displays in the footer but never needs as pages of their own. Item states, queued publishing and scheduling are covered in Publishing and Scheduling.
Designing the template
Previewing items on the canvas
A template page holds no content of its own, so the Designer needs an item to show. A Collection page menu in the top bar lists the items of the Collection and switches the preview between them. Previewing a long plant name or a plant with no photo is how a designer finds that a heading wraps badly or an image box collapses. It is worth previewing at least three items: one typical, one with the longest text, and one with empty fields.
Choosing a different item changes only what the canvas shows. It does not affect what visitors see.
Binding fields to elements
Any element that can display content has a Get text from, Get image from, Get link from or similar choice in its settings, offering the fields of the page’s Collection. The result is a dynamic element, and the Designer marks it in purple. The common bindings for the Fernbrook Plants template are:
| Element | Bound to | Result in the page |
|---|---|---|
Heading (H1) |
Name field |
The plant’s common name as the page’s only top-level heading |
Image |
Main photo image field |
The |
Text block |
Botanical name plain text field |
A short line of text |
Rich Text element |
Description rich text field |
Paragraphs, headings, lists and images written by the editor |
Link block |
Care guide link field |
An |
Text block with a prefix |
Height in metres number field |
The number, with static text around it in the same element |
Fields that cannot be shown directly can be shown through the element they are connected to. A reference field, such as the Garden zone of a plant, is not displayed as such: the template can show fields of the referenced item (for example the zone name) by choosing the reference field as the source and then the field of the referenced Collection. The details are in Reference and Multi-reference Fields.
Two practical rules keep templates robust:
-
Plan for empty fields. An empty plain-text field renders an empty element, which may still take up space through padding and margins. Elements that depend on an optional field should be hidden when it is empty; see Conditional Visibility and Dynamic Embeds.
-
Bind images with alt text. An image bound to a field takes its alt text from the image asset. A template that binds a photo but leaves the alt text empty produces an inaccessible page for every item. See Images and Assets.
What Webflow generates
The plant template, once published, produces markup such as the following for the item Lavender. Class names are the ones the Fernbrook designer chose, and the structure is simplified.
<main class="plant-page">
<h1 class="plant-name">Lavender</h1>
<p class="botanical-name">Lavandula angustifolia</p>
<img class="plant-photo"
src="https://cdn.prod.website-files.com/EXAMPLE-SITE-ID/lavender-main.jpg"
alt="Purple lavender flowers in the Mediterranean bed"
loading="lazy">
<div class="rich-text w-richtext">
<p>Lavender thrives in full sun and poor, well-drained soil.</p>
</div>
<a class="care-link" href="https://www.fernbrook.example/guides/lavender">Care guide</a>
</main>
The same template, for the item Japanese maple, yields the same markup with other values: that is the whole mechanism. Each page is a complete, static HTML document served from Webflow’s hosting, so visitors and search engines receive finished markup rather than a page that fetches content with JavaScript.
Collection page settings
Hovering over a template in the Pages panel shows a settings icon. The Collection page settings it opens are the template-level equivalents of the page settings of a static page, with one important difference: several fields accept dynamic values, so one setting produces unique information for each item. The settings cover the page’s URL segment, the SEO title and description, the Open Graph title, description and image, an RSS feed, the publishing control already described and custom code.
SEO title and description
The SEO Title tag and Meta description are written as a pattern that mixes static text with field tokens. The Fernbrook title pattern is the plant’s name, followed by a fixed suffix:
{Name} | Plants at Fernbrook Gardens
The braces mark where the Designer inserts a field token with the Add field control; they are not typed by hand. A live preview in the settings shows roughly how the result appears in search results. Fernbrook’s description pattern uses the plant’s short summary field, which the editor is asked to keep under about 160 characters, so that the snippet is not truncated:
{Summary}
What the visitor’s browser and search crawlers receive is the pattern resolved for each item:
<title>Lavender | Plants at Fernbrook Gardens</title>
<meta name="description"
content="Lavender thrives in full sun and poor, well-drained soil.">
Patterns have two weaknesses. If a field used in the pattern is empty, the resolved text has a gap, so patterns should rely on fields that are required in the Collection. And if every item uses the same static text only, the template produces duplicate titles across hundreds of pages, which is exactly what the dynamic tokens are meant to avoid. The wider SEO tooling, such as the sitemap and canonical tags, is in SEO and AEO.
Open Graph title, description and image
The Open Graph tags decide how a link looks when it is shared on a social network or in a chat application. On a template page they are patterns, like the SEO fields. Each of the title and description can be typed, built from field tokens with Add field, or taken from the SEO title and meta description by ticking the corresponding checkbox. The image is chosen from an image field of the Collection or entered as a fixed image or public address, and it is the existing asset that is referenced, not a newly rendered picture.
For Fernbrook, the Open Graph title reuses the SEO title, the description reuses the SEO description, and the image is the plant’s Main photo field, so a shared link to the lavender page shows the lavender photograph. The resolved output is:
<meta property="og:title" content="Lavender | Plants at Fernbrook Gardens">
<meta property="og:description"
content="Lavender thrives in full sun and poor, well-drained soil.">
<meta property="og:image"
content="https://cdn.prod.website-files.com/EXAMPLE-SITE-ID/lavender-main.jpg">
Three points matter in practice. Open Graph settings apply only to the page on which they are set, so there is no site-wide Open Graph setting and each template needs its own. Social platforms cache what they have read, so a corrected image may keep showing the old one until the platform’s cache expires or its debugger tool is used to refresh it. And the image should be a photograph that crops well in a wide, short frame, since platforms crop it automatically.
The book Webflow by Example introduces these dynamic SEO and Open Graph field tokens, and the mechanism is unchanged in principle. Its steps describe a pre-2023 Designer, so panel names and positions differ from today’s.
The same settings in the Editor
Page and Collection settings are also reachable by users with a seat when they edit the site on the canvas, so a content editor or marketer can adjust SEO and Open Graph patterns without opening the Designer. The legacy Editor that the book describes was fully deprecated on 2026-10-05; the canvas replaced it. See Content Editing on the Canvas.
RSS feeds
The Collection page settings include an RSS Feed Settings section with a toggle. Switching it on makes Webflow generate an RSS feed of the Collection’s published items, which feed readers and some automation tools can subscribe to. The settings define the feed’s channel title and channel description, which describe the feed as a whole (for the Fernbrook Garden Journal, the journal and not one article), and the title and content of each feed entry, which are chosen from item fields in the same way as other dynamic values.
The feed only goes live when the site is published, and it contains published items only. Its address is shown in the settings after the feed is enabled; use that address rather than guessing it, and link it from the site with a standard alternate link so that browsers and readers can discover it:
<link rel="alternate" type="application/rss+xml"
title="Fernbrook Garden Journal"
href="https://www.fernbrook.example/garden-journal/FEED-ADDRESS-SHOWN-IN-SETTINGS">
This tag goes in the page’s head custom code, as described in Custom Code in the Head, Footer and Embeds. The feed cannot be styled, because it is data, not a page; formatting of the entries comes from the fields chosen for it.
Linking to the current item and to other items
Link to an item page from a list
A link that opens an item’s page is a Link block or Button whose link settings point to Collection page rather than to a fixed address, with the item’s Collection chosen. Inside a Collection list the link points to the list item that is being rendered, so a card for each plant in the Plants index links to its own page. The same link bound to an element in the template page itself points to the item the page is showing, which is useful for a Share or Permalink control that must contain the page’s own address.
<a class="plant-card" href="/plants/lavender">
<img src="https://cdn.prod.website-files.com/EXAMPLE-SITE-ID/lavender-card.jpg"
alt="Purple lavender flowers">
<span class="plant-card-name">Lavender</span>
</a>
The link target is always the item’s real slug, which is why a slug change changes every list that links to it on the next publish, and breaks only external links.
An "other items" list on the template
Most template pages end with a list of related items: other plants, the next journal entries. That is a Collection list placed on the template page, usually of the template’s own Collection. Placed unfiltered, it would show the page’s own item among the others, which looks like a bug. The fix is a filter on the list: choose the Collection’s name, the condition is not, and the value Current Collection item. For a related-items list the filter instead compares a field with the current item’s value; the Fernbrook template filters plants by Garden zone equal to the current plant’s zone and excludes the current plant, so the list shows neighbours in the same zone.
A reasonable other items list limits the number of items to three or four and sorts them by a field such as the publication date, since the whole list is rendered on every page. List filters, sorting, limits and offsets are explained in Collection Lists. Filters on a list are fixed at design time: they cannot be changed by the visitor at runtime, so a filter plants by zone control on the index page needs custom code or a third-party library.
Galleries from multi-image fields
A Multi-image field holds several images. It cannot be bound to a single image element, because there are many images and one element. Webflow instead exposes the field as a list: a Collection list element can be added inside the template with the multi-image field as its source, and each of its list items holds one image. This is a nested Collection list, because it sits inside the template page (or inside another list) and takes its content from a field of the current item.
The Fernbrook Plants template uses it for the photo gallery below the description. The designer adds a Collection list inside the page, chooses the Gallery multi-image field as the source, places an image inside the list item, and binds that image to the list item’s image. The result is a grid with one image per photo in the field:
<div class="plant-gallery w-dyn-list">
<div role="list" class="gallery-grid w-dyn-items">
<div role="listitem" class="gallery-item w-dyn-item">
<img src="https://cdn.prod.website-files.com/EXAMPLE-SITE-ID/lavender-1.jpg"
alt="Lavender in bloom" class="gallery-image">
</div>
<div role="listitem" class="gallery-item w-dyn-item">
<img src="https://cdn.prod.website-files.com/EXAMPLE-SITE-ID/lavender-2.jpg"
alt="Lavender after cutting" class="gallery-image">
</div>
</div>
</div>
The w-dyn-* classes are added by Webflow’s runtime to mark dynamic lists and items, and the list uses the
list and listitem roles so assistive technology announces the group. The lightbox is the usual way to enlarge the
images: a Lightbox link around the image, with the group enabled, lets a visitor page through the gallery.
Nested lists count against the page limits. A page may hold at most 40 Collection lists, of which at most 10 can be nested, and a nested list shows at most 100 items for each parent item. A template with a gallery, a related-items list and a footer list uses three of the 40, so the budget is rarely a problem, but a template that nests a list inside a list inside a list is a design that should be reconsidered. The limits are listed in CMS Limits and Scaling.
The nested list also exists for reference fields: a multi-reference field shown as a list lets the Plants page show the Pollinators it attracts, each of which is its own item with its own link; see Reference and Multi-reference Fields.
Reading the items a template shows through the API
Everything a template page displays comes from CMS items that the Data API can read, which is how a developer checks what a page should contain without opening the Designer. The call below lists the published items of the Plants Collection on the Developer workspace site. The token and identifiers are placeholders and come from environment variables.
curl --request GET \
--url "https://api.webflow.com/v2/collections/${PLANTS_COLLECTION_ID}/items/live?limit=3" \
--header "Authorization: Bearer ${WEBFLOW_API_TOKEN}" \
--header "accept: application/json"
The response lists items with their fieldData object, in which slug is the final part of the page address and
name is the bound heading:
{
"items": [
{
"id": "EXAMPLE-ITEM-ID",
"isDraft": false,
"isArchived": false,
"fieldData": {
"name": "Lavender",
"slug": "lavender",
"botanical-name": "Lavandula angustifolia"
}
}
]
}
Source: Data API: List Live Items
More about the CMS API is in Data API: CMS.
Pitfalls
-
Editing a slug breaks inbound links. Internal links update on the next publish; external links, bookmarks and search results do not. Add a 301 redirect before renaming.
-
Duplicate or empty SEO patterns. A title pattern without a field token gives every page the same title, and a pattern that relies on an optional field leaves holes.
-
The template is not the item. Fixing a typo in a heading is a content edit of the item, whereas changing the heading’s size is a template change that affects every item. Mixing the two up is the most common surprise for new editors.
-
Unpublished items are invisible. An item that has been created but not published returns a 404, even though the Designer previews it without problems.
-
Open Graph is per template. A new Collection needs its own Open Graph patterns; nothing is inherited from the site.
-
Social caches. A fixed Open Graph image keeps appearing in shares until the platform refreshes it.
-
Every list on the template renders for every page. Heavy lists make every item page heavy.
Where the book disagrees with the current documentation
The book Webflow by Example describes the template page, dynamic SEO and Open Graph tokens, RSS feeds and an "other items" list with a current-item filter, and these ideas still hold. The differences are in the surroundings. It describes the Collection pages of a pre-2023 Designer with different panel labels; it assumes the legacy Editor, which no longer exists, for the editor’s side of the workflow; it limits a Collection to 30 fields, whereas the limit is now 60; and it shows multi-image galleries only with Classic Interactions around them, whereas new sites use Interactions with GSAP (see Interactions with GSAP).