A 460 page catalog site is not 460 pages of writing. It is one dataset, rendered. Once you see it that way the engineering question changes: the pages are cheap, and the site is exactly as good as the data pipeline behind it. Most of the work that matters happens before any page template exists.
We hold that view because we have tested it at scale, twice, on catalog builds for Belzona distributors: Belzona Baton Rouge, a 460 page site for Louisiana, and IMS, a 492 URL site serving Virginia, Maryland, DC, and West Virginia. Both migrate an entire legacy CMS into typed data files and statically generate every page from them.
What a typed pipeline actually does
On the Baton Rouge build, 893 CMS items came out of the old platform: 112 products, 231 product FAQs, 65 case studies, industries, certifications, application scenarios, and more. A schema-driven transform reads the raw export alongside each collection's field schema and normalizes every field by type. References resolve to slugs, images become URL and alt-text pairs, switches become booleans, numbers get coerced.
The transform also counts its own failures. Every cross-reference is checked, and the migration landed at zero orphans: no product pointing at a category that does not exist, no case study citing a missing product.
The IMS build shows the density involved: each of its 112 products carries 41 fields, spanning technical data, cure times, service temperature limits, safety documents, spec sheets, videos, related products. That density is exactly why hand-maintained pages fail. Nobody keeps thousands of fields consistent across a redesign by hand. A pipeline does it every build.
Those fields are not decoration, either. They carry the documents a maintenance engineer actually asks for: safety data for the base and the solidifier, chemical-resistance charts, instructions for use. When the data layer holds all of it, the page can answer the question instead of forwarding it to a phone call.
Gaps are surfaced, never guessed
The hardest rule in catalog work is also the simplest: when the data does not say, the website does not say. Every migration finds holes. A product with no cure-time value, a field nobody filled in for years. The tempting move is to write in something plausible. On an industrial repair product, a guessed spec is not a typo. It is a liability.
So the transform writes a gap report automatically. Every empty field in every collection is listed per record, and the report becomes a work list for the client. On the IMS build it reads like an honest audit: one technical-data field empty on 25 of 112 products, surfaced for the client to fill rather than papered over.
“Surfaced, never guessed.”
— The rule written into both migration pipelines
Fail loud or fail in production
Guards are the other half of the discipline. Both builds re-host every asset from the old platform's CDN into first-party storage: 1,507 files on the Baton Rouge build alone. The old CDN host was then removed from the image configuration entirely, which means any image still pointing at it would visibly break in production.
So the transform refuses to finish while one old-CDN URL survives anywhere in the data. It exits with an error and the build never ships. A lingering dependency on the old platform cannot sneak through, because the pipeline is physically incapable of passing one along.
- Every field normalized by its schema type, with references resolved and zero orphans
- Every missing value listed in an auto-generated gap report, per collection, per record
- A fail-loud guard: one leftover old-CDN URL and the transform exits non-zero
- Accessibility enforced at data-build time: rich-text headings flattened so rendered pages never skip a heading level
- Hand-authored additions kept in separate files the transform can never overwrite
Why this makes 400 pages maintainable
Once the data is typed and trustworthy, everything downstream is a projection of it. The same dataset feeds the page templates, the sitemap, the search index, and the structured data that tells search engines each product's SKU, brand, and FAQ answers. Change a spec in one file and every surface updates on the next build.
It also multiplies. On the Baton Rouge build, 69 application scenario records were expanded into 205 canonical application pages, each linked back to the real products that solve the problem. That is how a 112 product catalog becomes a 460 page problem-to-solution site without anyone writing 460 pages.
And it protects the client's team. Curated relationships come with fallbacks, so a product with thin data still renders a complete page from what does exist, and the industry pages list only products explicitly named in the migrated copy. Accurate and curated, never inferred.
The pages are just the render
The lesson travels well beyond industrial catalogs. Whatever your site presents, that content is data, and it deserves the same discipline as the code: types, guards, and an honest report of what is missing. Get the dataset right and 400 pages is not a maintenance burden. It is one build command.
