Should This Be a CMS Collection or a Static Page?

Should this be a CMS Collection or a static page?

Make it a Collection when you have several things that share a layout and will keep arriving. Make it a static page when it is one of a kind and its layout is part of its argument. The test is not how many you have today. It is whether the next one will look like this one.

This decision gets made casually and then governs the site for years. Collections are cheap to add and expensive to unwind, because every item, URL and template depends on the structure you chose in the first week.

We get asked this on nearly every Webflow build, usually about case studies, services, or industry pages. Here is how we actually decide, including the plan limits that quietly constrain the answer.

What does Webflow mean by each of these?

Webflow defines static site pages as pages on your site that are not generated from CMS Collections, like a homepage or contact page. It defines CMS items as individual records, like a blog post or office location, and CMS Collections as groups of those items that share a common template or layout.

The phrase doing the work is "share a common template or layout." A Collection is a promise that these things are the same shape. If they are not the same shape, you will spend the next year adding conditional visibility to pretend they are.

A static page makes no such promise. It can be laid out however the content needs, at the cost of being maintained by hand.

What do the plan limits tell you?

More than most teams realise, and they point in one direction. On Webflow's published site plan comparison, static site pages top out at 300 even on the highest tier, while CMS items go to 20,000 and CMS Collections to 40. Static pages are the scarce resource.

At the entry level the contrast is sharper still. The free Starter plan allows 2 static pages, 50 CMS items and 20 Collections.

So Webflow's own economics assume that repeated content lives in Collections and static pages are reserved for the handful of pages that carry the brand. If you find yourself planning 80 hand built pages, the platform is telling you something.

What is the actual decision rule?

Ask three questions. Will there be more of these? Do they share a structure? Does anyone other than a designer need to add one? Two yes answers means Collection. Fewer than two means static page.

The third question is the one teams skip and the one that matters most in practice. If a marketer needs to publish a new case study without opening the Designer, it must be a Collection, regardless of how many exist today.

Conversely, if only a designer will ever touch it, and its layout is the point, a static page is not a failure of discipline. A homepage is a static page for good reasons.

Where does the line get blurry?

Services and industry pages, almost every time. There are usually five to eight of them, they share most of their structure, and each one has a section that exists nowhere else. Both answers are defensible, which is why the argument recurs.

Our rule for this case: if the differences are content, use a Collection with an optional rich text field for the odd section. If the differences are layout, use static pages. Content differences are a Collection's job. Layout differences are what break them.

The tell that you chose wrong is a template with four conditionally visible blocks, only one of which shows on any given item. At that point you have built four templates inside one and lost the benefit of having a template at all.

What do you give up with a Collection?

Layout freedom, mostly. Every item renders through one template, so a bespoke page for your biggest client is not available without workarounds. You also inherit a URL structure that is awkward to change later.

You give up some editorial nuance too. A static page can put the strongest proof point wherever it belongs for that story. A Collection page puts it where the template says, for everyone.

The compensations are real: one design change updates every item, new items need no designer, and the content becomes available to the APIs. Webflow's content management APIs run from 60 requests per minute at the entry level to 120 on the top tier, which matters if you plan to sync from another system, as we covered in syncing external tools into the Webflow CMS.

What do you give up with static pages?

Consistency and speed, and they degrade quietly. Eight hand built service pages start identical and drift within a year, because each edit happens on one page and nobody reapplies it to the other seven.

You also give up the ability to change anything globally. A new proof section across eight static pages is eight pieces of work and eight chances to differ. Across a Collection it is one.

And you give up the marketer. Static pages require Designer access, and Designer access for a non designer is how sites get broken. That alone decides many of these calls.

Can you change your mind later?

Yes, but it costs more in one direction than the other. Static to Collection is genuinely painful: you rebuild the template, migrate content by hand or by API, and set up redirects because the URLs will change. Collection to static is easier, since you are replacing generated pages with hand built ones.

Plan the redirects before you start either way. A URL change on a page with rankings is the expensive part, not the rebuild, and it is the part people discover afterwards. Our guide to handling redirects in Webflow covers the mechanics.

Given that asymmetry, when a decision is genuinely 50/50, we lean toward the Collection. It is the cheaper mistake to reverse.

What about the pages that are neither?

There is a third option people forget: one static page that renders a Collection list. A single services overview page, hand built, with a Collection list pulling in individual services, gets you a bespoke landing experience and templated detail pages at the same time.

This is usually the right answer for the blurry cases. The parent page carries the argument and the design. The children carry the repeatable detail.

It also keeps your static page count low, which matters given the 300 ceiling, and it keeps the Collection structure simple. How those lists behave is worth understanding properly, which we went into in working with Collection lists.

How many Collections should a site have?

Fewer than you think. The limit is 40 on the top plan, and we have never needed anywhere near that on a marketing site. A typical B2B build uses four to six: blog posts, case studies, services or industries, team, and perhaps open roles.

The failure mode is creating a Collection per content type when several share a shape. Two Collections that differ only by a category are one Collection with a category field, and merging them is much easier before there are 200 items in each.

Name the fields for what they mean rather than where they appear. A field called "hero subtitle" ages badly the first time the hero is redesigned. A field called "summary" does not.

What would we tell a team starting today?

Write down every page type before you build anything, and mark each as one of a kind or repeatable. The repeatable ones are Collections. The one of a kind ones are static pages. Then check the count against the plan limits and see whether the plan you chose actually supports the site you drew.

That exercise takes an hour and prevents the single most common Webflow rebuild we get called in for, which is a site with sixty hand built pages that a marketing team cannot safely touch.

If you are at the structure stage and want a second opinion before it becomes concrete, we are happy to look at your page list and say where we would draw the line. You can find us at phoenix.studio.