Webflow CMS: How Collections Work for Marketing Teams

The Webflow CMS stores content that appears on your website again and again in the same format. You maintain it once in one place, and Webflow displays it everywhere in the right design. On B2B SaaS websites, that's typically blog posts and customer testimonials, often use cases or job listings too.

We explain the principle here as simply as possible, starting with an example; the technical terms come afterwards. Then we show which content is worth turning into a collection and where the limits are. Our view comes from more than 50 Webflow projects over six years.

The Webflow CMS in five terms

In the Webflow CMS, you create a collection with fields and fill it with items. These items then appear on detail pages or in lists. An example makes this easiest. Take the customer testimonials on your website: each testimonial has a customer name, a logo, a quote and an industry.

Webflow translates exactly this example into five terms:

• Collection: the content type, here "Customer testimonials".
• Fields: the information each testimonial needs, i.e. name, logo, quote and industry.
• Item: a single testimonial, i.e. the one from a specific customer.
• Collection page: the template for the detail page. Webflow generates a separate subpage from it for every item.
• Collection list: a list or grid you can place on any page, such as the latest testimonials on the homepage.

Here's the same example in the Webflow interface. The collection is called Customer testimonials, the fields Logo, Quote and Industry:

The difference from a regular page lies in maintenance. You change static text individually in every place it appears. Dynamic content, by contrast, comes from one source: if you change the quote in the CMS, Webflow updates it everywhere the testimonial is used. With reference fields you can also link collections, for example a customer testimonial with the matching use case.

If you're completely new to Webflow, you'll find the basics in the article What is Webflow? How the CMS differs from WordPress in daily work is covered in the comparison Webflow vs. WordPress.

Marketing use cases for SaaS websites

Anything that's added regularly and always has the same structure is worth a collection. For a single page like the legal notice, you don't need a CMS. The table shows the collections that appear most often on B2B SaaS websites.

Blog and resources

The blog is almost always the first collection. Every post uses the same template, and the overview page fills itself via a collection list. A typical mistake: whitepapers and webinars end up in the same collection as blog posts, even though they need different fields. Better to create a separate collection for resources.

Customer testimonials and case studies

Testimonials appear on many pages, on the homepage as well as on product and use case pages. As a collection, you maintain each testimonial once and show it via reference fields wherever it fits.

Short quotes and detailed case studies don't automatically have to live in separate collections. If the same fields are enough, you can keep both in one collection and use conditional visibility to control which sections appear. A long case text or a download, for example, only shows up if the field is filled. Separate collections are worth it when the fields differ significantly.

Webflow generally creates collection pages for CMS items. If short testimonials don't need their own detail page, you should prevent lots of thin URLs from being indexed. In the item details you can turn off sitemap indexing per item on paid site plans. The item then gets a noindex tag and drops out of the sitemap.

Use cases

Use cases describe how a specific audience uses your product. As a collection, all use case pages get the same structure, and your team adds new use cases without a new layout. A typical mistake: setting up fields so sparsely that in the end the pages differ only in their title.

Features and integrations

Integration pages are tempting because one template quickly produces 50 pages. They're only worthwhile if every page has its own content, such as what the integration actually does and how setup works. Google's spam policies classify mass-produced pages without added value as scaled content abuse. Ten well-maintained integration pages will therefore bring you more than 80 thin ones.

More collections for team and product

Team pages and job listings also work well as collections. A changelog is worth it as soon as your product ships updates regularly. A few fields are enough here, and maintenance can sit with HR or the product team.

Scaling and limits

The Webflow CMS grows with you within your site plan's limits. For most marketing websites, these limits are more than enough. Things get tight more often when collections grow without a plan and nobody remembers what each field is for.

The most important limits according to the Webflow pricing page and the Webflow Help Center (as of 9 Nov 2026):

The list limits only apply to what's displayed on a page. How many items your CMS can store is set by the site plan. By default, a collection list shows up to 100 items. You get more items on the same page via pagination, or by duplicating the list and setting a skip value under Limit items on the copy, for example 100. The first list then shows items 1 to 100, the second items 101 to 200. Plan several clear collections rather than one with a huge number of fields, and maintenance stays manageable even at 500 items. We compare what the plans cost in the article Webflow pricing.

What marketing maintains on its own

With prepared fields and the right permissions, your marketing team creates and publishes items on its own. New collections and changes to templates, on the other hand, remain tasks for design or development. How well this works day to day depends on how roles are assigned and on a few details in the setup.

Webflow distinguishes two roles for this. A Content Editor edits content and CMS items; a Marketer can also build new pages from existing components. From the Growth workspace plan upward, you can turn the right to publish the entire website on or off for roles such as Designer, Marketer or Content Editor. That doesn't replace a binding approval process: even without this right, these people can publish individual CMS items. Deriving a fixed approval workflow from the Growth workspace alone would therefore be wrong.

On the Premium plan, you can publish individual items without republishing the whole website, and schedule items to go live. Required fields prevent items without an image or meta description. Short help texts on the fields explain to your team what belongs in which field.

In our projects, we plan components and CMS fields around the tasks your team handles after launch. During handover, your team practices exactly these tasks, such as adding a new testimonial or publishing a blog post. We describe how we approach this on our Webflow agency page.

When the Webflow CMS isn't the best choice

The Webflow CMS fits as long as your content mainly lives on the website and marketing maintains it. Via the CMS API, you can create, update and publish items. The Content Delivery API also delivers published content to other channels, such as apps or email sequences, serving it from a cache.

Still, Webflow remains a website-bound CMS. The data model follows collections and fields you built for pages. The content lives in Webflow, and a later system switch means migrating it. Sanity, as a headless CMS, is independent of the front end: you model content once as a data source for the website, product app and help center, and you keep it when the website system changes. Webflow is enough if the website is the main channel and other systems occasionally read along. A separate headless CMS is worth it when many systems need the same source, the data model grows more complex or you want to decouple content from the website stack.

These cases also point to an alternative:

• Many channels should use the same content as a central source, or the data model becomes too complex for that.
• Your team works with Git and code review and wants to roll out changes via deployments.
• The data model exceeds the plan limits, such as a catalog with tens of thousands of items.
• Every change should live in the complete source code of your own repository, not just in the Webflow interface.

AI agents can also work in Webflow. The Webflow MCP server gives them access to CMS content, pages, components, styles and other site data, within existing permissions. You don't need your own Git repository for this. Converia often fills its Webflow CMS exactly this way with AI support.

A code-based setup with Astro has different strengths. Changes live in your own repository, with version history and review before anything goes live. Agents work directly with the complete source code there. Webflow MCP is a good fit if your team wants to stay in the platform and prepare content or components with AI. Astro is worth it if you want to own the code and have every change go through Git.

In these cases, we evaluate a setup with Astro and Sanity with you. Content lives there as structured data in Sanity, and the website's code belongs to your team. When the switch is worth it and how it works is covered on our page about migrating from Webflow to Astro.