The CMS Mistake Almost Every Webflow Site Makes

About half the Webflow work I get hired for isn't a new build. It's a fix. And an unfair number of those projects share the exact same root problem: the CMS was structured for what the site needed on launch day, not for what it actually needed six months later.

The "one big collection" trap

It usually looks like this: everything gets crammed into a single Blog Posts collection, because that's the first collection type anyone learns in Webflow. Team members become blog posts tagged "team." Case studies become blog posts tagged "work." FAQs become blog posts tagged, somehow, "faq." It works, right up until you need a field that only makes sense for one of those content types, and now every other item in the collection is carrying a field it'll never use.

A real example

I worked on a clinic site where every practitioner had been added as a blog post with a "type: team" tag, because the original build just needed headshots and bios on one page. Later, the client wanted to filter practitioners by service and by location — reasonable, normal request. It wasn't possible without restructuring the whole collection, because there was nowhere for a proper reference field to live. What should've been a half-day update became a rebuild.

Reference fields are where the real leverage is

Webflow's multi-reference and reference fields let collections actually talk to each other — a Service can list which Team members deliver it, a Case Study can pull in the Service it belongs to, a Location can show its own Team automatically. None of that works if everything's flattened into one collection with tags standing in for real relationships. Planning those connections before you build is the difference between a client updating content themselves in five minutes and emailing you to do it.

Static content that should stay static

The opposite mistake happens too, and I probably made it myself early on: turning everything into a CMS collection out of habit. If a section only ever has three items, never changes, and is laid out in a way that's genuinely custom per item, a collection just adds overhead — one more thing that can break, one more editor field that goes stale. Not everything needs to be dynamic.

• It has one to three items and there's no realistic plan to add more
• The content hasn't changed in the last year and probably won't
• Each item needs a meaningfully different layout, not just different text
• It's something only you will ever edit, never the client

How I plan collections before I build anything

Before I open Webflow, I sketch the content model on paper or in FigJam: every entity the site needs (services, team, locations, case studies, testimonials), and how they relate to each other. Only after that's settled do I decide what's a collection, what's static, and what needs a reference field. It's an extra hour up front. It's saved every client I've done this for a rebuild later.

See how I structure Webflow CMS builds

Plan it once, save the rebuild

Webflow's CMS can genuinely handle complex, relational content — it's more capable than it gets credit for. The sites that struggle aren't hitting a platform limit. They're paying for a structure that was never actually planned, just accumulated one launch-day shortcut at a time.