How should a manufacturer publish a product catalog online?

The key points

• Specs belong in HTML tables that search engines and AI tools can read.
• Filters should match how engineers actually select a part.
• One managed product data source beats copies in spreadsheets.
• Gate CAD files only when the lead is worth the lost downloads.

Why isn't a PDF catalog enough?

Because buyers search for the specification, not the brochure. An engineer types a bore size, a pressure rating or a material grade into Google, and a forty-page PDF rarely surfaces for that query, let alone sends them to the right page of it.

PDFs also go stale quietly. Someone updates the price list or retires a variant, and three versions of the catalog keep circulating on distributors' sites for years. Keep the PDF as a download for people who want it, generated from the same data as the website, but make the web pages the primary catalog.

How should product pages be structured?

Usually one page per product family, with the variants listed inside it, rather than one thin page per part number. A family page can explain applications, materials and options once, then list the variants in a table an engineer can scan.

Individual part pages make sense when each part is searched for by its number, ordered separately, or has its own drawings and certificates. Plenty of manufacturers end up with both: a family page that ranks for the general query, linking to part pages that rank for the exact number.

• A plain description of what the product does and where it's used
• A specification table in HTML, with units shown for every value, which also helps AI assistants read the page
• Variant or part-number table with the attributes that differ
• Downloads: datasheet, drawings, CAD models, certificates, manuals
• Related accessories, spares and compatible products
• A request-a-quote or check-availability action next to the specs

What filters should an industrial catalog have?

The attributes your customers select by, in the order they think about them. Ask your application engineers which three questions they ask first on a technical call; those are your first three filters.

This is called parametric search, and it works only when the underlying data is clean. If one product lists "10 bar" and another "145 psi" in free text, no filter can compare them. Store values as numbers with a unit, convert for display, and use fixed lists for things like material or certification. Filters with dozens of near-duplicate options ("SS304", "SS 304", "304 stainless") are a sign the data needs fixing before the website does.

Should CAD files and datasheets be gated behind a form?

Datasheets, no. Gating a datasheet mostly stops engineers from specifying your part. CAD files are a genuine judgment call.

An open CAD download gets your part into more designs, and a design-in is often worth more than a contact record. A gate gives sales a name, but many engineers will fill in junk details or go to a competitor whose model downloads instantly. A sensible middle ground: open downloads for standard parts, a light gate (email only) for configurable or high-value models, and full contact details only where a sales conversation genuinely has to happen before the model is useful.

Do you need a PIM system, or is a spreadsheet enough?

A spreadsheet is fine for a few hundred products with a few attributes and one person maintaining them. Once you have thousands of variants, several languages, distributors who need feeds, or more than one person editing, a product information management (PIM) system or a structured database usually pays for itself.

The real requirement is a single source. The ERP typically owns part numbers, prices and stock; the product data source owns descriptions, specs, images and documents; the website reads from both. If marketing edits specs in the CMS while engineering updates a spreadsheet, the two drift within months. If you sell into industries that use classification standards such as ETIM, or need GS1 identifiers like GTINs for retail or distribution partners, store those as attributes from the start.

What structured data should a product catalog use?

Use schema.org Product markup that matches what's visible on the page: name, description, image, brand, SKU or manufacturer part number, and offers where you show a price. For families with variants, Google documents ProductGroup markup for variant relationships.

Google draws a distinction worth knowing. Merchant listing markup is for pages where a customer can buy the product. Product snippet markup is for pages where they can't buy directly, and it needs at least one of review, aggregateRating or offers. Many B2B catalog pages sit in the second group because prices are on request. Don't invent ratings or prices to qualify for rich results; mark up what's true and accept that some catalog pages won't get stars.

How should exporters handle units and languages?

Show units the way each market reads them, and convert from one stored value rather than maintaining separate numbers. US buyers often want imperial units alongside metric; most other markets expect metric first.

For translated catalogs, translate the specs and descriptions properly, keep part numbers identical across languages, and link the language versions to each other with hreflang, as covered in what a manufacturing website should include so search engines show the right one. Machine translation is a reasonable first draft for long descriptions, but have a technical speaker check terminology: a wrong word for a thread type or a tolerance class can cost an order.