A specification-led content architecture for an industrial catalogue

Industrial catalogues are built by division, by product line, and by the order things were introduced, because that is how the company thinks about itself and how the data arrives from the ERP. Buyers arrive with a different vocabulary entirely: the application they are solving for, the specification they have to meet, or the part number they are replacing. The architecture exists to put a page in front of each of those three arrivals without maintaining three copies of the same specification.

The catalogue is organised by product line. The buyer searches by the specification of the part they are replacing, and the two have almost no words in common.

1. 01

   One canonical specification table per part family, generated from one record

   The same tolerance appearing in three formats on three pages is not a formatting problem, it is three chances to be wrong and one certainty that two of them are stale. The table is generated from the product record, so a correction is made once.

2. 02

   Application pages are the buying pages; product pages are the checking pages

   An application page answers 'will this work for what I am doing'. A product page answers 'what exactly is this'. They need different structures, different depth and different calls to action, and collapsing them into one page serves neither reader.

3. 03

   Comparison and replacement pages are the pages competitors do not write

   'Equivalent to', 'replacement for', 'alternative to' — these are the highest-intent queries in an industrial catalogue and the ones an internal team is most reluctant to publish, because they name a competitor. That reluctance is why the queries are uncontested.

4. 04

   Structured data is how a machine reads a specification

   Marking up the page is not the same as marking up the specification table inside it. If the values are only in a rendered table, a summariser has to infer them, and inference on a tolerance is worse than no answer.

**95% of B2B purchases go to a vendor on the buyer's day-one shortlist**, and buyers complete ~**60% of the journey independently** before contacting sales (6sense *2025 Buyer Experience Report*). If your spec pages aren't found during that independent research, you're not on the shortlist that decides the deal.

The architecture runs from a single product record. That record generates the canonical specification table, which is embedded rather than retyped on every page that needs it. Product pages carry the record and the table. Application pages are written per use case and link down into the products that satisfy it, with the specification presented as a constraint the buyer is trying to meet rather than as a feature list. Comparison and replacement pages are built per competitor part number where a genuine equivalent exists. Every page type has one enquiry route attached, tagged by application rather than by product, so the enquiry arrives with the buyer's own framing intact. Structured data is applied to the specification values themselves.

1. 1

   Weeks 1–3

   Data and inventory

   Product record audit, specification field mapping, duplicate and stale value list

   Owner: OmniFlow + client engineering

2. 2

   Weeks 3–5

   Page types

   Product, application and comparison templates defined with distinct structures

   Owner: OmniFlow

3. 3

   Weeks 5–10

   Build

   Canonical tables generated, application pages written per use case, schema applied

   Owner: OmniFlow

4. 4

   Weeks 8–11

   Enquiry routing

   One route per page type, tagged by application, with a named response owner

   Owner: OmniFlow + client

This entry makes no performance claim. It documents a content architecture and the structural mismatch it was built to resolve: a catalogue organised by product line serving buyers who search by application and by part number.

These are the surfaces this engagement is run and measured from, shown with representative figures built around the benchmarks cited on this page. Every account we run reports into views like these, and you keep ownership of all of them.

The comparison and replacement pages were built last because they were the hardest to get internal sign-off on. They should have been first. They carry the clearest query intent in the whole architecture and they took the longest to review, so putting them at the end of the build put the highest-value pages behind the longest approval queue.

Real client work that shipped. No performance figures are published, because none have been verified and approved for release. See all our work