How to plan a Webflow CMS your marketing team can actually run

Plan a Webflow CMS around the things your team publishes, not the pages the site has today: one collection per content type, references that connect them, one flexible template per collection, and dedicated SEO fields bound into every template. Get those four right and a marketer can add a case study, a service or a new location page in the Editor without touching the Designer. Get them wrong and every new idea turns into a developer ticket.

Here's how I plan it before any building starts.

Start with an inventory of what you publish

Before you open Webflow, list every type of content the site has now or will need soon. For a SaaS company, that might be blog posts, case studies, integrations, features and team members. For a local service business, it's services, locations, projects and FAQs.

For each type, answer four questions:

• Does each item need its own page? Blog posts do. Testimonials usually don't.
• Do the items share a layout? If they do, they belong in a collection with one template.
• Who will add new ones, and how often? Content that changes often is the strongest case for the CMS.
• What does each item need to show? The answer becomes your field list.

A one-off page, like your home page or pricing page, stays a static page. Anything you'll make more of goes in the CMS.

Decide your URLs now

Webflow puts every CMS item under its collection's path, so a post lives at something like /blog/post-name. You can't publish collection items at the root of the domain. That makes the collection slug one of the most important decisions in the plan: change it later and every URL in the collection changes with it. Pick short, readable paths that describe the content, which is what Google's URL structure guidance recommends anyway.

If you're moving from WordPress, this is where old and new URLs usually part ways. Posts that sat at the root on WordPress end up under a folder on Webflow, and each one needs a redirect. Plan that as part of an SEO-safe migration, not as a scramble in launch week.

Collections: one per content type

Most marketing sites end up with a familiar set:

• Blog posts, with Authors and Categories as collections of their own
• Case studies or projects
• Services, plus Locations for businesses that serve several towns
• Team members
• FAQs and testimonials, which usually appear on other pages rather than their own
• Resources such as guides, webinars or templates

Two decisions come up in almost every plan.

Option field or its own collection?

A category can be an Option field on the post, or a separate Categories collection that posts reference. The Option field is simpler, but it gives you nothing to link to. A Categories collection gives every category its own template page, with its own intro and SEO fields. That page can rank for broader searches and gives visitors somewhere to browse. If a grouping deserves a page, make it a collection.

One collection or two?

If two content types share most of their fields and their layout, they can share a collection, with an Option field to tell them apart. If their layouts differ, split them. A single template stuffed with conditional sections for five kinds of page is hard to design and harder for an editor to fill in correctly.

References: set each link once

References are what turn a list of collections into a site. A Reference field links an item to one other item, like a post to its author. A Multi-reference field links it to several, like a case study to the services involved.

The rule I follow is to set each relationship once, on the child. The case study says which services it relates to. The service template then shows its case studies with a collection list filtered to the current service. Nobody has to update the service page when a new case study goes in.

The alternative is a link kept in two places. I've inherited setups where each service listed its FAQs and each FAQ also pointed back to its service. Every new FAQ had to be linked twice, and sooner or later one side gets missed. If you can't avoid a two-way link, write it into the publishing guide so it becomes part of the routine.

Save nested collection lists, where a list inside another list shows referenced items, for small sets like tags or authors. Webflow limits how you can nest them, so check your plan against those limits before you design around them.

Templates: design for the item you haven't written yet

A collection template has to work for every item that will ever use it, including the ones nobody has thought of yet.

• Everything that varies comes from a field. Hard-coded text and photos only fit the items you had in mind at design time. When I added a new kind of page to an existing Locations collection, the new items inherited headings and photos written for a different service, and needed conditional visibility to hide them.
• Hide empty sections. Use conditional visibility so an item without a gallery or FAQs doesn't show an empty block.
• One H1, from the name field. Rich text in the body should start at H2, and the publishing guide should say so.
• Related content comes from references. Related posts, services and case studies filled in by the CMS give every new item internal links from the day it's published.
• Repeated blocks are components. A call to action used across several templates should be edited in one place.

SEO fields: build them into every template

Many Webflow builds skip this part, and it decides whether new pages are ready for search the moment they're published. Every collection with template pages should carry its own SEO fields, bound in the template's page settings.

• SEO title. A plain text field bound to the title tag, with a maximum length set. Google's title link guidance explains how titles are chosen and when they get rewritten.
• Meta description. A plain text field with a length limit, bound to the meta description. Google's snippet guidance covers how it's used.
• Social image. An image field for Open Graph, or bind Open Graph to the main image if every item has a good one.
• Summary. A short plain text field for cards and listing pages, so editors don't paste in the first paragraph.
• Schema facts. Anything your structured data needs, such as a price, an author, a date or an address, stored as a proper field instead of buried in rich text.

Why a dedicated SEO title field instead of binding the title tag to the item name? Because the name has another job. I've worked on templates where the title tag was the item name plus a fixed suffix. Renaming an item for the page heading changed its title tag too, and editing the suffix changed every page in the collection at once.

Dedicated fields bring their own risk. If the title tag is bound to an SEO title field and an editor leaves it empty, the page goes out with no title. Make the field required, and add help text that says what a good one looks like.

Schema from the CMS

Collection templates accept custom code in the head, and you can insert CMS fields into it. That's how I add JSON-LD to Webflow sites: one block per template, filled from fields. For Kitchen & Bath World, I added CMS fields so each vanity's name and price could feed Product schema. Test with an item that has a quotation mark or an ampersand in its name, because special characters in a field can break the JSON or come out garbled. My schema markup page covers how I plan the types.

Make it runnable for the marketing team

A CMS is only as good as the person filling it in on a busy afternoon. A few habits make the difference:

• Name fields in plain words. "Card summary" beats "Excerpt 2".
• Add help text to every field. Say where it appears, how long it should be and what happens if it's left empty.
• Order fields the way the page reads. Editors fill forms from top to bottom.
• Use required fields and character limits for anything that affects search or layout.
• Write a one-page publishing guide. Cover how to add an item, which fields matter for search, how to set references and what to check before publishing.
• Add a redirect whenever a slug changes. A new slug is a new URL, and the old one needs a 301 in your site settings.

A planning checklist

1. List every content type you publish or plan to publish.
2. Mark which ones need their own pages and which only appear on other pages.
3. Choose collection slugs and the URL pattern each item will get.
4. Write the field list for each collection, including SEO and schema fields.
5. Draw the references and decide which side each one is set on.
6. Design each template with every varying element bound to a field.
7. Bind the title tag, meta description and Open Graph settings on every template.
8. Add JSON-LD to each template and test it with real items.
9. Fill in help text and required settings, then write the publishing guide.
10. Test every template on staging with your longest, shortest and emptiest items.

Where to start

If you already have a Webflow site, open the CMS and look at one collection with fresh eyes. Are the SEO fields there, and bound? Is anything hard-coded in the template that should be a field? Does adding a new item need a developer? Those three answers tell you whether the site needs a tidy-up or a rethink.

If you're planning a new build or a rebuild, I plan the CMS first, build SEO fields and schema into every template, and run my Playwright QA toolkit on the staging site before launch. See how I approach Webflow development, or get in touch with a list of what you publish.