How Do You Plan a Webflow Site Structure Before You Build?

How do you plan a Webflow site structure before you build?

Start from the content, not the pages. Write down every type of thing the site will hold, decide which of those types will grow, and only then draw the navigation. Teams that start with a sitemap end up retrofitting a CMS. Teams that start with a content model end up with a sitemap that was always going to work.

We build Webflow sites for B2B companies, and the single most expensive mistake we see is structural. Not a design mistake, not a performance mistake. Somebody made twelve static pages that should have been one Collection, and by the time anyone notices, there are twelve pages of content and a navigation menu depending on them.

Restructuring later is possible. It is just slow, and it always costs redirects. Here is how we would plan it instead.

What should you decide before you open the Designer?

Four things, in this order. What types of content exist. Which types will grow in number. What relationships connect them. And what the URL for each type will be.

Notice that none of those are visual. The Designer is a very good tool for making decisions about appearance and a very bad tool for making decisions about structure, because it lets you build a page in twenty minutes and therefore tempts you to build twelve.

Do this part in a document or a spreadsheet. The output is a short list like: services, industries, case studies, team members, job openings, blog posts. Then for each, an honest answer to whether there will be five or five hundred.

How do you decide what becomes a Collection?

Ask whether the items share a shape and whether the list will change. Both yes means a Collection. Either one no usually means a static page.

Shape is the part people get wrong. Five services that each need a completely different layout are not really one type of thing, and forcing them into a Collection produces a template full of conditional visibility that nobody can maintain. Five services that each have a name, a problem, an outcome and three proof points are one type, and they belong in a Collection even if there are only five of them.

Growth is easier to judge. If someone in marketing will add items without a developer, it is a Collection. That is the whole test. We went into the trade-off in detail in deciding between a CMS Collection and a static page.

What about the plan limits?

They exist and they will shape your model, and we are not going to quote numbers at you. Webflow's limits on Collections per site, fields per Collection, items per Collection and items per list vary by plan and have changed more than once. We could not retrieve Webflow's current limits documentation directly this run, so check the live plan comparison in Webflow's help centre rather than trusting any number in a blog post, including ours.

What matters for planning is the shape of the constraint rather than the values. There is a ceiling on how many Collections a site can have, which means a model with a Collection for every small thing will hit a wall. There is a ceiling on fields per Collection, which means a Collection trying to serve three purposes will hit a different wall.

Design so that neither ceiling is close. If your model needs most of the available Collections on day one, the model is wrong, not the plan.

How should you handle relationships between Collections?

Sparingly, and in one direction where you can. Reference and multi-reference fields are powerful and they are also where Webflow site structures become hard to change, because every reference is a dependency you have to unpick later.

A useful discipline: before adding a reference field, name the page that will use it. If you cannot name a template where this relationship gets rendered, you are modelling for completeness rather than for the site, and completeness is not a requirement.

The common good case is a case study referencing an industry and a service, so that a service page can list the work that proves it. That is one reference doing real work on a real template. The common bad case is every Collection referencing every other Collection because it seemed tidy.

What should the URLs look like?

Readable, hyphenated, lowercase, and stable. Google's own guidance is unambiguous on all four. It asks for a simple URL structure constructed logically and in a manner that is most intelligible to humans, and for readable words rather than long ID numbers.

On separators, Google says to use hyphens rather than underscores to separate words in URLs, because it helps users and search engines better identify concepts. On case, the warning is concrete: Google treats an uppercase path and a lowercase path as distinct URLs with their own content, so pick one case and convert everything to it.

The Webflow-specific consequence is that your Collection slug becomes your URL segment, so naming a Collection carelessly names a URL carelessly. A Collection called Resources gives you a resources path forever, and changing it later means redirects on every item. We covered doing that safely in managing 301 redirects in Webflow.

How does navigation fit into this?

Last. Navigation is a view over the structure, and designing it first is how you end up with a structure that exists to satisfy a menu.

Once the content model is settled, the navigation question becomes much easier, because you are choosing which of a known set of things deserve top-level attention. Usually the answer is fewer than the team wants, and the argument is easier to win when there is a model on the table showing what the alternatives are.

The useful check is whether a person can predict where something lives before clicking. If they cannot, the problem is almost never the label, it is that two different types of content have been merged into one section. We went further into that in designing website navigation people can predict.

How do you plan for growth you cannot predict?

Leave space in two places: an unused Collection or two, and a generic content type you can grow into. Do not try to anticipate specific future content, because you will be wrong, and a Collection built for a thing that never happened is worse than no Collection.

The realistic growth patterns for a B2B site are fairly consistent. Blog posts multiply. Case studies multiply slowly. Landing pages for campaigns multiply fast and get abandoned. Team pages churn. Plan for the first and third of those specifically, because they are the ones that turn into hundreds of items and start to matter for both performance and maintenance.

For the campaign pages in particular, decide upfront whether they live in a Collection with a shared template or as one-off static pages. Both are defensible. Not deciding is how you get forty untracked pages.

What should you write down before you build?

A one-page structure document with four sections. The list of content types with an item count estimate. The fields each type needs, which is where you will notice that two types are actually the same type. The relationships, each with the template that uses it. And the URL pattern for every type.

Get that reviewed by whoever will actually add content, not just by whoever is paying for the site. The person who will create a case study every month will find the field you forgot in about ninety seconds.

If you are working in a class system like Client-First, settle the naming conventions at the same time, since structure and naming decay together. We wrote about that setup in using Finsweet Client-First in Webflow.

What does a well-planned site feel like six months later?

Boring, in the good way. Someone adds a case study and it appears on the service page, the industry page and the listing without anyone touching the Designer. A new campaign page reuses a template. Nobody asks a developer to publish content.

That is the whole return on this work. The planning does not make the site prettier or faster. It makes the site something a marketing team can operate without you, which is the difference between a site that compounds and a site that ages.

The teams that skip it are not lazy, they are just optimistic about how much the site will change. In our experience the site always changes more than anyone expected, and the structure is the part that decides whether that is easy or expensive.

If you want a second pair of eyes on a content model before anyone starts building, we are happy to walk through it. You can find us at phoenix.studio.