What the surface looks like in production
Twenty-two leaves at /p/{slug}, six spine pieces at /case-study/{slug}, one audit endpoint at /audit, one sitemap.xml at the root. Every leaf renders from the same React component that reads the slug manifest with generateStaticParams. The static export emits 22 leaf HTML files at build time. Lighthouse SEO scores 98 to 100 across the surface, mobile and desktop. The full source for the slug type, the manifest, the build-time validator, and the page renderer is in the open monorepo, so the architecture is auditable end to end.
Why this stack and not a CMS
A pSEO surface lives or dies by the round trip between editorial intent and shipped HTML. A CMS adds two surfaces of state that drift: the database and the front-end. With a TypeScript manifest, every editorial change is a code change with a diff, a commit, and a deploy. The cost is that non-engineers cannot edit. The benefit is that the production HTML is provably consistent with the slug manifest at every point in time. We have shipped CMS-driven pSEO and code-driven pSEO; for surfaces under 200 leaves with a small editorial team, the code path is faster, cheaper, and more honest. Above 200 leaves with a multi-author team, the calculation flips.
What this leaf does not cover
This is the summary. The architecture page in the spine has the longer-form walk-through with the file-by-file structure, the deploy topology, and the bot detection posture. The slug-strategy spine piece covers how we choose what to write about and what to leave on the table. The results spine piece carries the index-coverage and Core Web Vitals numbers. If you want to skip ahead to a specific concern, the related leaves below are linked from inside the body where relevant.
