Most building product manufacturers we work with as a construction marketing agency UK have the same problem with their websites. They list every product variant as a separate entry in their CMS, creating a flat database of hundreds of SKUs that forces specifiers to scroll, filter, and guess their way to the right product. It makes navigation painful and wastes the time of exactly the people you need to engage: architects, M&E engineers, and specifiers who are trying to understand your systems, not memorise your stock codes.
The issue is not Webflow. It's how the CMS collections are structured. Most manufacturers treat products the way their ERP system does, as individual line items. But specifiers do not think in SKUs. They think in ranges, systems, and applications. A good Webflow CMS structure should reflect that logic, and it is entirely possible to build it that way from the start.
When every product variant gets its own CMS entry with no clear hierarchy, the result is a catalogue that works for internal stock management but not for external decision-making. A specifier looking for a fire-rated cavity barrier should not have to scroll past pipe insulation, acoustic boards, and unrelated SKUs. They need to land on the cavity barrier range, understand the options within that family, then drill into the variant that meets their performance spec.
A flat structure also makes it difficult to communicate the logic of a product system. If you manufacture modular drainage channels, for example, the specifier needs to see how outlet units, grates, and edge rails work together. Listing them as separate, unconnected products hides that relationship and increases the chance they look elsewhere for a supplier who makes it clearer.
This is not just a UX issue. It directly affects whether your product gets specified. If the information architecture does not match the way specifiers evaluate and compare products, you lose them before they reach the technical datasheets.
The solution is to build your CMS with parent and child relationships that mirror how products are actually organised and specified. Instead of one giant "Products" collection, you create multiple collections that relate to each other through Webflow's reference fields.
Here is a typical structure we use for building product manufacturers:
Product ranges collection
This is the top level. Each entry represents a product family or system: cavity barriers, acoustic panels, drainage channels, pipe supports, whatever makes sense for your catalogue. This collection holds the range-level messaging, key applications, technical overview, and imagery that introduces the system as a whole.
Product variants collection
This holds the individual SKUs. Each variant entry references a parent range using a reference field. This is where the detailed spec lives: dimensions, fire ratings, colours, finishes, compliance docs, NBS clauses, BIM objects, installation guides.
Optional: applications or sectors collection
If your ranges serve multiple applications (e.g. wet rooms, plant rooms, external facades), you can add a third collection and link it to ranges via multi-reference fields. This lets specifiers filter or browse by use case before drilling into product families.
The key is the reference field. It creates a relationship between collections, so each product variant knows which range it belongs to, and each range can dynamically pull in its related variants. You are not duplicating content or manually updating lists. The structure does the work.
A good CMS structure means nothing if the website does not surface it clearly. The front-end templates need to reflect the parent-child logic and guide specifiers through a logical journey: application or sector, then range, then variant.
We typically design three template types for manufacturers:
Range overview pages
These are the landing pages for each product family. They explain what the range does, where it is used, and what makes it different. Below that, a dynamic list of variants pulls in every product that references this range, displayed as filterable cards or a comparison table. The specifier sees the whole family at a glance and can compare performance specs without jumping between pages.
Variant detail pages
Each SKU gets its own page with full technical information, downloads, related products (pulled dynamically via shared range or application), and imagery. Breadcrumbs and a "view full range" link make it easy to navigate back up the hierarchy.
Application or sector landing pages (optional)
If relevant, these pages explain the technical challenge (e.g. fire stopping in timber frame construction) and showcase the ranges that solve it, with each range linking through to its overview page.
The goal is to let specifiers browse the way they think. Not by scrolling a list of SKUs, but by narrowing down from application to system to variant.
When your Webflow CMS reflects how products are specified, you make it easier for architects and engineers to do their job. That builds trust. It signals that you understand their workflow and that your business is organised around solving their problems, not just shifting stock.
It also gives you more control over messaging. At the range level, you can pitch the system benefits and applications without getting lost in SKU-level detail. At the variant level, you can provide the granular technical data that supports the specification. Each page has a clear job, and nothing is trying to do too much.
And from a practical content management perspective, it scales. When you launch a new variant, you add one CMS entry and assign it to the relevant range. It appears automatically on the range page, in filtered views, and in related product lists. No need to manually update five different pages or risk orphaned content.
We have built dozens of product catalogues for construction supply chain businesses, and the CMS structure is always the first conversation. Before we design a single page or write a line of copy, we map out how the products relate to each other, how specifiers will navigate them, and what content belongs at each level of the hierarchy.
That means working closely with your technical and commercial teams to understand the product architecture, not just accepting a spreadsheet of SKUs. It also means designing templates that make the hierarchy visible and intuitive, using filters, comparison tables, breadcrumbs, and dynamic lists to guide users through the catalogue.
If your current website lists every product as a flat database, restructuring it in Webflow is not a small task. But it is worth doing properly. The alternative is a catalogue that looks comprehensive but functions like a stock list, and that does nothing to help specifiers choose your products over the competition.
We are happy to talk through how this would work for your range. Get in touch if you would like to discuss a better way to structure your product catalogue.
Trusted by 23+ clients
