The two halves of a working catalogue

A catalogue has to satisfy two audiences that behave nothing alike: the visitor already on your site, and the search engine deciding whether to send you visitors at all. Most catalogues are built for the first and quietly fail the second.

For the visitor, the requirements are ergonomic. Filters that respond without reloading, so narrowing a selection feels immediate. A filtered view that has its own address, so it can be sent to a colleague or reopened tomorrow. Sensible behaviour when nothing matches — nearest alternatives rather than an empty page. And speed that doesn't degrade as the catalogue grows.

For search engines, the requirement is different: something to index. Dynamically generated filter results usually aren't indexed, which is why so many catalogues rank for the company name and nothing else. The fix is dedicated pages for the combinations that carry real demand — a category within a location, a parameter range, a type of product — each with its own address, its own text and its own selection of items. That's where catalogue traffic actually comes from.

Then there's the part nobody sees until it fails: the connection to your data. If items live in a CRM, an ERP or a spreadsheet and the site is maintained separately, the two will drift. Automatic synchronisation isn't a convenience feature — it's what keeps the catalogue trustworthy.

This applies well beyond any single industry. A property catalogue, an equipment rental fleet, a B2B supplier's product range, a manufacturer's specification-driven line-up — the parameters differ, the structure doesn't. A real estate catalogue I built runs in four languages and brings over 1,500 organic visits a month with no ad spend, and it does so because of dedicated pages behind the filters, not the filters alone.