Webflow SEO

What the work covers

Your CMS collections are an SEO decision, not a design decision

Webflow projects usually get structured by whoever built the design, in an afternoon, before anyone has looked at a keyword. That afternoon sets your URLs.

The collection you create is the folder you keep

Every collection has one URL prefix, chosen when you create it. Blog posts live at /blog/[slug], projects at /projects/[slug]. Every item sits in that folder, with no exceptions.

So if someone builds a single Resources collection holding articles, guides and case studies, all of it lives at /resources/ forever. Split it later and every URL changes at once. Webflow has added nesting options over the years, so check what your plan supports, and check the collection and item limits while you're there. Both are on our Webflow website design page.

The practical rule: one collection per page type with its own search intent and its own template.

When you need a page type the collection wasn't built for

This is where Webflow sites go sideways. You have a Services collection at /services/[slug]. Two years on you want service by suburb pages, with three ways out.

Add fields and conditional visibility, and every variant still sits in /services/ sharing a template that fills with conditional blocks. Create a second collection, and you get clean URLs and a clean template, at the cost of another collection against your limit and content kept in step in two places. Build static pages, and you've broken the pattern for whoever edits next.

The common failure is the first one repeated. One collection, a type field, eleven conditional sections, and a flat folder holding four page types that should never have shared one. Deciding up front costs an hour. Undoing it costs a redirect project.

Reference fields are your internal linking engine

A reference field pointing a blog post at a category, or a service at a location, lets a Collection List build category pages, related item blocks and hub pages on its own. That's how internal linking scales past the point a human will maintain it.

Two things to know. Nested collection lists are capped at a small number of items, so a hub meant to list thirty children needs a filtered Collection List instead. And references only run one way unless you build the return path, so a hub linking down doesn't give you children linking back. Put that link in the template deliberately.

Redirects, and why Webflow punishes you harder

Webflow does not create redirects for you. Change an item slug, or a collection's URL prefix, and the old URLs stop existing the moment you publish. Change a prefix and every item moves at once, silently, in one click.

There's no record of the old URLs inside Webflow afterwards, which is the part that hurts. So before any structural change: export the collections as CSV to capture the slugs, crawl the live site, then write the redirect table. The redirect tool takes wildcard patterns, which is what saves you when a whole prefix moves, and there's a cap on stored rules, so patterns beat one row per URL. Bigger moves belong in an SEO migration plan, and the crawl side sits on technical SEO.

How the work runs

1. We map the collections

   What exists, what it commits you to, and what it'll block later.

2. We fix structure before content

   URLs, redirects, templates and reference fields.

3. We build the linking layer

   Hubs, category pages and related blocks running off the CMS.

4. We report and keep publishing

   Traffic and enquiries by page type, then the next tier.

Who this suits, and who it doesn't

It suits marketing sites of twenty to a couple of hundred pages, teams inheriting a build from a designer who left, and anyone about to restructure. Weaker fit for large catalogues. See eCommerce SEO for how platforms compare.

Why people pick us for this