Catalogue pages live at the intersection of product content and reference content. Each catalogue shows a curated set of items (a season range, a parts catalogue, a course catalogue) with prices, availability and short descriptions. The chrome is identical across catalogues: title, intro, item grid, pricing block, availability legend, FAQ. The variation lives entirely in the items, which means every catalogue is fundamentally a data problem with a thin presentation layer on top.

SleekRank reads catalogue rows from Google Sheets, CSV, JSON file or a REST endpoint. The items column carries a JSON array of objects with sku, title, price, image_url and availability fields. A list mapping renders them into a real grid on the base page. Tag mappings handle catalogue title and intro, meta mappings handle description and og:image, and Product or ItemList JSON-LD is populated from the same array per item.

The /catalogues/{slug}/ pattern stays clean as the site scales from five catalogues to five hundred. Adding a row for spring-2026 or replacement-parts-q2 takes a sheet edit and a cache flush, not an editor session per catalogue. Price changes ripple through every catalogue that references the item on the next cache cycle. Deleted rows return a clean 404, so retired catalogues vanish cleanly.

Catalogues are the canonical case for separating data from presentation. The items, prices and availability live in a system that already exists (an inventory database, a course management system, an ERP), and asking editors to keep WordPress catalogue posts in sync with that system is a guaranteed failure mode past the first catalogue. Prices drift, availability flags go stale, SKUs disappear from the page without being removed from the underlying data, and the catalogue loses credibility as a source.

The structured approach treats the catalogue page as a render of the source. Editors maintain the inventory in the system they already use; SleekRank reads it and renders the public surface. Prices reflect the cache cycle, availability flags reflect the source, schema reflects the same array as the visible grid.

Bulk changes (a seasonal markdown, a regulatory price update) ripple through every catalogue automatically on the next cache flush. The audit story matters as much. Operators can ask the source which catalogues a SKU is in, which catalogues need refresh, which categories are underweight.

Those workflows are unimaginable when each catalogue is a separate WordPress post with item details scattered across blocks and custom fields.