A URL architecture the product suite could grow into

The first decision was to stop treating product pages as pages. A product page is a content type — it has a name, a positioning line, a set of capability blocks, proof, and a call to action — and it repeats. Once you model it that way, the work moves from producing markup to producing a schema and the components that render it. I built that model in headless WordPress, using ACF and Gutenberg so the content team edited structured fields rather than layouts, and rendered it through React on a Gatsby build.

The URL structure was the other half of the architecture. Product family sections were organized under a shared /{family}/{use-case}/ pattern rather than each page getting its own bespoke route, which sounds like a routing detail and is actually a product decision: it forced a family to express how its capabilities were organized, gave it room to accept new members, and made the shape of the navigation follow from the shape of the catalog rather than from whatever had been added most recently.

Decoupling the CMS from the front end is what made the rest safe. Content changes stopped touching render code, so the marketing and content teams could work on pages without a deploy on the critical path, and I could change how a component rendered everywhere at once without opening every page. That separation is the whole point of a headless stack, and it only pays off if the component library on the front end is disciplined enough to be the single place a pattern lives.

The thing I care about in this build is what it removed. Before, launching a product page meant a scoping conversation, an engineering ticket, and a bespoke template. After, it meant a content record and a composition of existing components — cutting launch times from 72 to 24 hours. The platform absorbed the next launch instead of the team absorbing it.

Years later I went back to check which half of that claim held. Pendo has since moved the site off WordPress onto a different front end entirely, which is the real test of an information architecture: the thing it was built in got replaced, and the structure stayed. Of the twenty-seven pages live when I left, twenty still serve at the same URLs, including all fourteen use-case pages under the two solution families. The suite tier above them is gone, and a later team re-expanded some of the feature pages I had flattened — which is what it looks like when an architecture is being used rather than preserved.

This is the version of a marketing site I keep building toward: not a set of pages that happen to describe a product, but a system whose structure mirrors the product it sells, so that growth in one shows up as configuration in the other rather than as a rebuild.