Design a programmatic SEO system for 1 million landing pages

Tests data infrastructure thinking, not content generation. Covers one-row-one-page schema, template rendering with edge caching, hierarchical routing, and crawl-budget controls via sitemaps. Red flag: AI bulk writing without structured data or caching.
What's really being asked
This question tests whether you view programmatic SEO as a data engineering and infrastructure problem rather than a content creation exercise. At one million pages, manual authoring is economically impossible, so the interviewer wants to see a systems mindset that separates structured data from presentation, manages crawl budget, and guarantees performance. They are looking for familiarity with ETL pipelines, rendering strategies, and search engine discovery protocols.
The full answer
First, data ingestion and schema design. You need an ETL pipeline that normalizes proprietary or third-party data into a strict schema where one row equals one URL. Include validation gates to prevent empty or duplicate records from generating thin pages. Second, page generation and rendering. Use deterministic templates married to structured data, rendered via SSR, SSG, or ISR depending on update frequency. Pre-generate static pages for stable data and use incremental regeneration for volatile slices. Third, URL routing and slug architecture. Implement a hierarchical slug strategy that mirrors category intent, plus a reverse index or lookup table so the router resolves any valid URL in constant time. Handle 301 redirects and 404s cleanly when data rows are deprecated. Fourth, performance and discoverability. Serve pages through a CDN with edge caching to keep TTFB under 100 milliseconds. Generate segmented XML sitemaps capped at 50,000 URLs each and expose them through a sitemap index. Add schema.org JSON-LD, canonical tags, and robots meta tags to manage indexation. Fifth, crawl budget protection. Build noindex gates for pages below a quality threshold, use log file analysis to detect bot traps, and prevent index bloat by excluding near-duplicate parameter variations.
The mistakes people make
Treating the problem as an LLM bulk-writing task instead of database-driven infrastructure. Proposing on-demand database queries for every page request without caching or edge distribution. Ignoring crawl budget and suggesting all one million pages should be indexed immediately without quality thresholds. Failing to mention XML sitemaps, canonical tags, or duplicate content prevention. Suggesting a monolithic CMS to store one million pages as individual documents.
What usually comes next
How would you handle a data update that affects half the pages without rebuilding everything? What signals would you use to decide whether a generated page deserves indexation? How do you prevent duplicate content when multiple data rows produce similar output? What is your strategy for internationalization or localization at this scale? How would you measure revenue attribution per programmatic page cluster?
A concrete example
Zapier programmatically generates over ten thousand integration pages such as Connect Gmail to Slack. Each page is not hand-written; it is a database row rendered through a template that injects specific app names, descriptions, and use cases into a consistent layout. The engineering effort is fixed, but the system captures thousands of long-tail queries that a content team would need eighteen months and three hundred thousand euros to cover manually.
Interview question
How should a programmatic SEO system handle a data update affecting half of one million pages without rebuilding everything?
- a.Switch to on-demand server rendering with database lookups and a short edge cache TTL
- b.Regenerate every page to maintain consistency and immediately resubmit all sitemaps
- c.Update the source rows and rely on CDN cache invalidation during natural search bot recrawling
- d.Apply incremental regeneration to updated slices while keeping stable pages in edge cacheCorrect
Why? this is the answer
The card explicitly recommends incremental regeneration for volatile slices while pre-generating static pages for stable data and caching at the edge. Option A is tempting because it mentions caching, but on-demand database lookups per request represent the flagged anti-pattern for performance at this scale.
Just read this? Test yourself on what you have been reading.
Read the original → nikoalho.fi
- #programmatic-seo
- #system-design
- #growth-engineering
- #crawl-budget
- #etl-pipelines
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles