Multilingual SEO at Static-Generation Scale

Conventional wisdom says a 14,000-page site needs a CMS. That advice is correct for sites where content changes hour by hour and editors need WYSIWYG tooling. It is exactly wrong for sites where content is structured, the schema is stable, and the bottleneck is search engine indexation rather than authoring throughput. Pillar's content is structured: a domain, a Learn piece, a category landing, a hub page. Each type has a defined data shape. There is no reason to pay the latency and complexity tax of a database lookup on every request when the same HTML will be served to every visitor.

Static delivery also collapses the security surface. There is no admin login to harden, no SQL injection vector, no plugin ecosystem to patch. The build pipeline runs on a developer machine or a CI runner; the output is plain files. This is the foundation we describe in the Zero-Secret Architecture piece, and it is the reason a one-person ops loop is viable at this page count.

Finally, static wins on Core Web Vitals by default. Largest Contentful Paint is bounded by file size and edge latency, not by application server response time. Cumulative Layout Shift is determined by the rendered HTML, which is deterministic. First Input Delay is near zero because there is no hydration step. These are the metrics search engines actually weigh, and a static site starts the race ten meters ahead.

Pillar uses two inventory formats and the choice is deliberate. The domain portfolio is tabular: every row has the same columns (domain, category, price, status, language availability). A CSV is the right tool. It opens in any spreadsheet, diffs cleanly in version control, and parses in three lines of Python. The build script reads the CSV, iterates rows, and emits one HTML file per domain per language. At 6,608 domains across four languages, that single CSV drives over 26,000 generated files if every domain has every language; in practice the count is lower because not every domain ships in every language at launch.

Structured content, Learn pieces and product pages, lives in JSON. A Learn piece has a title, a subhead, a thesis, a framework with named pillars, a tactical checklist, an FAQ. That is not a flat row; it is a nested object. JSON expresses the nesting, validates with a schema, and parses directly into the dict the template expects. The 88 Learn library pages are each one JSON file plus a shared template. Edit the JSON, rerun the generator, the page reflects the change.

What does not belong in either format is a database. A SQL or NoSQL store for a static site is pure overhead: it adds a query latency, a backup obligation, a schema migration burden, and a credential to manage. None of those costs buy you anything the file system does not already provide. The inventory lives in the repo, alongside the templates, under version control. The diff for a content change is a diff to a JSON or CSV file. That is the entire change-management story.

Hreflang correctness is where most multilingual sites fail. The spec requires that every language variant of a page link to every other variant, including itself, plus an x-default. For Pillar's four languages, that is five <link rel="alternate"> tags on every single page. Across 14,000+ files, that is over 70,000 hreflang declarations. Hand-writing them, or relying on an editor to remember them, is not a strategy. The template renders them from the inventory's URL slug plus the language list. Authors cannot omit hreflang because they never touch hreflang.

The same discipline applies to JSON-LD schema. Every page type has a defined schema set: Organization plus WebPage plus BreadcrumbList for most pages; FAQPage added on Learn pieces with FAQs; ItemList on category landings. The template builds the schema object programmatically from the data dict and emits it as a single <script type="application/ld+json"> block. The author writes prose; the template emits machine-readable structured data. Neither side of that division is asked to do the other side's job.

Canonicals, Open Graph tags, Twitter cards, mobile viewport, and font preloads round out the head block. All of it is template-rendered. The author's surface area is the JSON or CSV row. That separation is what makes the system scale: adding a 14,001st page is exactly as hard as adding the first.

Each page type has a dedicated generator: one for domain pages, one for Learn pieces, one for product trees (Studio, Authority, Institute and their subpages), one for category landings, one for the hub pages. Each generator follows the same contract: read inventory, iterate items, render template, write file. A generator is rarely more than 200 lines of Python. Because the contract is uniform, adding a new page type is mechanical: copy the closest existing generator, swap in the new template, point at the new inventory section.

A single orchestration script runs the generators in dependency order: product pages first because hub pages link to them, hub pages next, then Learn pieces, then domain pages, then the sitemap index and the four per-language sitemaps, then llms.txt last because it references everything. The orchestrator is the only entry point anyone needs to know. Run it, and the entire dist directory is regenerated in roughly 30 seconds. Deploy with wrangler pages deploy and the new content is on Cloudflare's edge in about another 30. That one-minute loop is what makes daily content updates frictionless.

Build determinism matters as much as build speed. The same inventory plus the same templates produces byte-identical output. That means a CI check can regenerate the site and diff against the committed dist directory to catch drift. It also means rolling back is a git revert away. There is no database state to reconcile, no cache to invalidate, no eventual-consistency window to wait through. The repo is the system of record.