Webflow CMS tricks that few agencies actually know (filters, multi-collection reference)

Why most agencies only use 30% of Webflow CMS

Because they treat it like a regular CMS. Webflow CMS is not WordPress with a nice visual editor: it is a relational database disguised as a design tool. And that confusion is expensive. At Mazette.co, we have taken over dozens of Webflow projects built by other agencies where every collection lived in its own bubble, with no relationship between them — the result: duplicated text fields everywhere, manual updates across twelve different pages, and a client calling in a panic because they need to change a price on 40 product sheets one by one.

The truth is that Webflow allows for far more refined architectures than most tutorials show. Reference and Multi-reference fields are not just for showing "the author of the article" — they let you build complex many-to-many relationships, provided you understand their real limits and know how to work around them intelligently.

Multi-collection reference: what it actually enables

A Multi-reference field lets an item in one collection point to several items in another collection, and vice versa if you duplicate the relationship in both directions. This is the building block that turns a static catalog into a truly modular system.

A real case: a product catalog with cross-filters

On an e-commerce project for a furniture brand, we built three linked collections: Products, Materials, Seasonal Collections. Each product references several materials (Multi-reference) and belongs to one seasonal collection (simple Reference). The result: the "Materials" page automatically displays every product using that material, with no data duplicated anywhere. A single update to the "solid oak" material cascades across the 60 relevant product pages.

The classic trap: many agencies create a single "Products" collection with free-text fields like "Material: oak", hoping to filter on it later. That does not work properly — no relationship, no reliable filter, no automatic per-material page.

The limit you need to know: the 5-reference cap per collection

Webflow limits the number of Reference/Multi-reference fields per collection. On large projects (more than 5 relationships needed), you have to create intermediate "pivot" collections — a trick borrowed directly from the classic SQL relational model. This kind of workaround is exactly what separates a CMS architecture planned in advance from one improvised on the fly.

CMS filters: beyond the basic Collection List

Most agencies use Webflow native filters (via the Collection List settings) to sort by category or date. That works, but it is limiting as soon as you want dynamic, visitor-side filtering with several combined criteria.

Multi-criteria filtering without heavy code

For a truly interactive filter — checking "oak" and "summer collection" at the same time — the native interface is not enough. That is where Finsweet Attributes comes in: its CMS Filter attributes let you wire up visual filters on reference fields without writing a single line of custom JavaScript. We implemented this on a real estate site with over 300 listings: filters by city, surface area, number of rooms and property type, all combinable in real time, with no page reload.

The trap of filtering on a Reference field

Filtering directly on a Multi-reference field does not always work natively with Finsweet attributes, depending on the version used. The lesser-known trick: create a "mirror" text field (visually hidden) that lists the slugs or names of the referenced items, updated via a calculated field or manually when entering CMS content. It is a bit manual, but it works reliably and avoids jumping to costly custom development.

Structuring your collections before designing: the real trick

Most missteps come from a single bad reflex: designing the page before modeling the data. We still see sites where the "Blog Articles" collection has a "Category" free-text field instead of a reference to a dedicated "Categories" collection — making it impossible to later generate a page per category automatically, or display an article count per topic.

• List every entity in the project (products, authors, categories, tags, locations) before opening the visual editor
• Identify many-to-many relationships from the start — there are always more of them than you think at the first briefing
• Anticipate the 5-reference-per-collection limit by prioritizing the relationships that will actually be used on the front end
• Plan for mirror text fields if a Finsweet filter is planned on a Multi-reference relationship

This modeling phase takes half a day longer upfront. It saves dozens of hours in maintenance down the line, and it is exactly what separates a Webflow architecture built to last from a site that ages badly the moment content gets updated at scale.

The case of multilingual sites with a relational CMS

Add localization with Weglot on top of a multi-reference architecture, and complexity climbs another notch. Referenced fields do not translate automatically the same way static text fields do: you need to check that translated slugs stay consistent across linked collections, or you risk broken links on the English or German version. This is something very few agencies test before going live — and it usually gets discovered at the worst possible moment, right in the middle of an acquisition campaign in a foreign market.

{{webflow}}

The Mazette.co take: the invisible technical work that makes the difference

We say it often internally: a well-built Webflow CMS does not show — and that is exactly what proves it is well built. The client never sees the mirror field, the pivot collection, or the trade-off around the 5-reference limit. They just see that updating a price takes one click, and that the "oak products" page exists without anyone having to design it by hand.

This invisible layer is what separates a Webflow site delivered quickly from a Webflow site that will hold up for three years without a rebuild. We have seen too many projects rush into custom development simply because nobody anticipated the relationships between collections when writing the spec. A good Webflow CMS is 80% data modeling and 20% visual formatting — the opposite of what most people assume when they first discover the tool.

{{seo-aeo}}

What this means for SEO and content structure

A well-thought-out relational architecture directly serves SEO. Pages automatically generated by material, city or category create a natural, massive internal linking structure — exactly the kind of structure Google values for programmatic content, and that generative AI cites more readily because the information is organized coherently and exhaustively rather than scattered across isolated static pages. This ties directly into the Webflow SEO best practices we cover elsewhere, and it also lays the groundwork for AEO, where data structure matters just as much as the content itself.