For manufacturers with complex product ranges, a website that's hard to navigate is rarely a design problem. It's usually a data issue.
ACO USA is the American arm of ACO Group, a global manufacturer of drainage and water management systems. Their catalog spans hundreds of SKUs across multiple industries, each with technical parameters, load classifications, compatible accessories, and documentation that needs to live alongside it. When a catalog like this grows without a clear content architecture, the information doesn't disappear — it just ends up in the wrong places. Product pages disconnected from relevant documentation. Spreadsheets running in parallel with a CMS. Engineers cross-reference specs manually because the website doesn't do it for them.
We were brought in to fix that. The visible result is a rebuilt website. The actual work was a data architecture project.
Your product catalog doesn't fail because it looks bad — it fails because the data is built wrong.
An engineer specifying drainage for a construction project doesn't start with a product name. They start with requirements: load class, material type, channel dimensions, and applicable standard. If the website can't handle that starting point, they call a sales rep or go to a competitor.
The cost is real but hard to see in analytics. It shows up as a sales team fielding questions the website should answer, quote cycles stretched because a specifier waited on documentation, and reps repeating themselves about products that have been live for years.
For ACO USA, the specific issues were:
- product data across multiple sources with no single system of record,
- documentation not linked to the products it covered,
- no filtering that matched how engineers specify,
- no path from finding a product to knowing who to contact without leaving the site.
How we rebuilt it: structure before anything else
Before development started, we mapped what existed in the catalog and how the pieces related to each other:
With relationships built explicitly into the system, a product page automatically surfaces the right documentation, the relevant industries, and the nearest distributor. Nobody has to maintain those links by hand across hundreds of products.
Two ways into the catalog
Buyers approach a catalog differently depending on where they're starting from. A specifying engineer works from product type and technical parameters. A facility manager starts from the application — what problem they're trying to solve. We built the catalog to accommodate both entry points, with both paths reaching the same depth of information.
Why do we choose WordPress to manage complex product data?
The platform is WordPress with a structured content layer. The main reason: ACO USA's team needs to manage the catalog without developer involvement on routine updates. Adding a product, updating a data sheet, adjusting which industries a product appears in — these are tasks a product manager handles independently. A more custom solution might have offered other advantages, but at the cost of making that day-to-day work harder.
Filtering built for engineers, not product managers
Filtering was the most impactful part of the project from a commercial standpoint and the most demanding to build properly.
Generic filtering treats product attributes as broad tags. That falls apart when users are engineers working to precise specifications — load class, channel dimensions, outlet configuration, certification standard. It also falls apart when filters work independently of each other: a user combines three criteria, gets zero results, and concludes the product doesn't exist. The product probably does exist; the filter logic just isn't intersecting the selections correctly.
“The filtering system is built on top of a structured data model using custom post types and taxonomies. Each product is mapped against multiple technical parameters - such as load class, material, application type, or outlet configuration - and the filtering logic ensures that only results matching all selected criteria are returned. From a development perspective, the challenge wasn’t just performance, but maintaining data consistency and relationships across a highly interconnected system.” - Łukasz Kunicki, Software Engineer at xfive
Search results are grouped by content type — products first, then documentation, then application pages. Someone who knows the problem but not the product name can still navigate to the right place.
Data migration: where AI changed the timeline
Getting the architecture right gets written about. Getting the data into it accurately is harder, and on this project, it was a significant part of the work.
ACO USA's product information had built up across multiple systems over the years: spreadsheets with inconsistent structures, exports from older platforms, static files with specs that contradicted the spreadsheet values, and documentation stored with no link to the products it covered.
“We used AI to support two key stages of the process. First, during data mapping, aligning multiple inconsistent data sources into a unified content model, resolving conflicts, and identifying edge cases. Second, during import automation, helping us build and validate scripts that ensure data integrity while populating the system at scale. AI wasn’t making decisions for us, but it significantly accelerated structured data transformation and reduced manual effort.” - Łukasz Kunicki, Software Engineer at xfive
Without AI at these stages, the migration would have needed either more time or more people. What it changed was that the judgment-heavy parts — defining the rules, reviewing outputs, handling exceptions — could scale without becoming a bottleneck on every routine record.
From product to purchase: reps, distributors, HubSpot
A catalog that gets someone to the right product but leaves them to figure out how to buy it has done half the job.
We built a ZIP code–based lookup for distributors and sales reps, maintained through the same CMS as the rest of the site. Contact forms on product and application pages connect to HubSpot — so an inquiry arrives with context about which product and application the person was looking at. The sales rep picking it up already has a starting point for the conversation.
What changed
After launch, ACO USA's team had one place where product data lived and a system to keep it consistent. Updating one record propagates to everything that references it. Product managers can add SKUs, attach documentation, set industry relationships, and publish without involving a developer.
“For the end user, especially engineers and procurement teams, the experience is now much more direct. Instead of navigating multiple disconnected sources, they can define their requirements, find the right product, access technical documentation, and identify a local contact - all within a single flow. That level of clarity and efficiency should be standard, but in complex manufacturing environments, it’s still surprisingly rare.” - Magdalena Bondarenko, Project Manager at xfive.
Fixing a manufacturer's catalog is rarely about redesigning it. It's about deciding how the data is structured, building it correctly from the start, and ensuring the people who manage the products can keep it current.
FAQ: product catalog websites for manufacturers
Our manufacturing website has hundreds of products, but customers still can't find what they need — what's the problem?
Almost always, it's a data architecture issue, not a design one. If products exist as flat pages without structured attributes, there's nothing for a filter or search to work with — users browse instead of specifying, and most give up. The fix starts with how data is modeled.
How do I add advanced product filtering to a WordPress manufacturer website?
Build it on structured data — technical attributes stored as discrete, queryable values, not freeform text or tags. The data model determines whether filtering works; the interface is straightforward.
What's the best way to manage product data across a large manufacturing catalog without it becoming a maintenance nightmare?
One record per product, with relationships to everything connected to it — documentation, applications, distributors. Update it once, and it propagates. The right platform is whichever one your product team actually uses consistently, without needing a developer for every change.
How can a manufacturer's website generate more leads instead of just listing products?
Build the catalog and lead generation together, not separately. Product pages need clear paths to contact forms and distributor finders, and form submissions should carry context — which product, which application — so the sales team gets an inquiry they can act on, not just a name and email.
We have product data in spreadsheets, legacy systems, and PDFs—how do you migrate all of that accurately?
It's the hardest part of most catalog projects. For larger catalogs with data from multiple inconsistent sources, AI tooling has become necessary at the mapping and import stages — the alternative is a timeline that doesn't fit a typical project budget.
How much does it cost to rebuild a manufacturer's product catalog website?
It depends on data model complexity, the volume and condition of existing data, and required integrations. A scoping conversation that looks at the actual data first is the most reliable way to get to an accurate number.
About the author
