Component vs. Collection: When to Use Each

The core question

Every piece of content on a Webflow site is either a static component (hardcoded in the Designer) or a CMS collection item (stored in the database and rendered dynamically). Choosing correctly saves you hours of rework. Choosing wrong means rebuilding later — or hitting Webflow's 40-collection limit on structures you did not need.

Decision framework: three signals

Ask three questions about any piece of content:

1. Does it repeat? — Does the same content appear in more than one place on the site? If updating it means editing two or more pages manually, it belongs in a collection.
2. Does it grow? — Will the list of items get longer over time? Blog posts, team members, events, and testimonials all grow. A mission statement does not.
3. Does a non-developer need to edit it? — If a client, marketing manager, or content editor needs to update this content without opening the Webflow Designer, it belongs in the CMS.

If all three answers are no, keep it static. If any answer is yes, make it a collection.

Signal table

Content	Repeats?	Grows?	Non-dev edits?	Verdict
Hero section	No	No	No	Static
Blog posts	N/A	Yes	Yes	Collection
Company values (about page only)	No	No	No	Static
Company values (about + careers + footer)	Yes	No	Maybe	Collection
Impact stats on 3 pages	Yes	No	Yes	Collection
Team members	Sometimes	Yes	Yes	Collection
Founder letter	No	No	No	Static
Testimonials	Yes	Yes	Yes	Collection
Footer content	No	No	Rarely	Static
Service offerings	Sometimes	Sometimes	Yes	Collection
Progress tracker on 5 pages	Yes	No	Yes	Collection
One-off landing page section	No	No	No	Static

Real-world examples

Impact stats shown on multiple pages

A nonprofit displays "12M oysters restored" and "400 volunteers" on the homepage, about page, and impact page. Same data, three locations. Without a collection, updating a number means editing three pages. With a collection, update once and every instance reflects the change.

Verdict: Collection — it repeats across pages and a non-technical team member updates the numbers quarterly.

Company values on the about page

Four values with icons, titles, and descriptions. They appear on one page. The founder wrote them two years ago and has not changed them since.

Verdict: Static — one location, no growth, developer-only edits.

Company values on about + careers + footer

Same values, but now the client wants them visible on three pages. If one value changes, someone has to edit three places manually.

Verdict: Collection — the moment content appears in multiple locations, it needs a single source of truth.

Client testimonials

Four testimonials on the homepage. The same four on the pricing page. The client adds two new ones every quarter.

Verdict: Collection — it repeats, it grows, and the client manages it.

The "promote to collection" pattern

The safest approach: start static, promote when the need is real.

Here is the workflow:

1. Build the content as a static component in Webflow Designer.
2. When the content needs to repeat, grow, or be edited by non-developers — promote it.
3. Screenshot the existing component and upload it to Trellis.
4. Trellis analyzes the screenshot and generates the collection structure (fields, types, help text).
5. Review and deploy the collection to Webflow.
6. Rebind the component to the new CMS fields in the Designer.

This pattern means you never over-engineer. You never create collections "just in case." Every collection exists because a real need triggered it.

The reverse — demoting a collection back to static — is wasteful. You delete the collection, lose the structure, and hardcode the content back into the page. Always easier to promote than demote.

Read the full workflow in How to Get Started with Trellis.

When NOT to make a collection

• One-off page sections — an "Our Story" block on the about page does not need a collection.
• Design-specific layouts — a custom hero with a unique layout for a single campaign page. The design is the content.
• Content that changes less than once a year — a copyright notice, a privacy policy intro, a founder quote in the footer. The editing overhead of a CMS entry is not worth it for content that never changes.
• Rich text blocks on a single page — long-form content that lives on exactly one page (a legal page, a detailed guide) is better as a static rich text element.

When you MUST use a collection

• Content with its own URL — if each item has a dedicated page (blog posts, case studies, team bios), it must be a collection. Webflow generates these pages from collection templates.
• Lists that exceed ~10 items — manually managing 20+ cards in the Designer is error-prone and slow. Use a collection list.
• Content managed by non-developers — the Webflow Editor (the content editing interface, not the Designer) only surfaces CMS content. Static components are invisible to editors.
• Filtered or sorted content — collection lists support filtering by category, date, status, and conditional visibility. Static components do not.

Common mistakes

1. Making everything a collection — you hit the 40-collection limit fast. A 15-page site does not need 25 collections. See Webflow CMS Limits.
2. Keeping everything static — the opposite extreme. Sites with 30 pages of manually maintained content become unmaintainable. If your client cannot update their own site, something needs to be a collection.
3. Deciding based on URL only — many collections display as cards, lists, or inline elements without dedicated pages. The "needs a URL" test misses these.
4. Not planning for growth — a "Team" section with 3 people today might have 15 next year. Think about where the content is heading, not just where it is now.

Next steps

• What Is a CMS Collection? — understand the anatomy of a collection.
• Planning CMS Architecture — how to plan your full set of collections before building.
• How to Get Started with Trellis — the full designer's workflow, from screenshot to deployed collection.