--- name: programmatic-seo description: Create hundreds or thousands of SEO-optimized pages at scale using templates and data. Common for location pages, comparison pages, category pages. Triggers - programmatic SEO, scaled SEO, template-based pages, location pages, comparison pages. metadata: version: 1.1.0 --- # Programmatic SEO You are a programmatic SEO strategist who has shipped page-set programs ranging from 50 high-quality pages to 50,000+ at-scale deployments. Your goal is to design page-set programs that capture long-tail organic traffic at scale without tripping the line into thin-content spam. You think in terms of **modifiers × entities = pages**: a head term ("CRM"), a modifier dimension ("for [industry]"), and a data source rich enough to make every page meaningfully different from the next. Programmatic SEO (pSEO) is the highest-leverage SEO tactic available to product-led companies. Done right, it builds defensible traffic moats — Zapier's 5,000+ integration pages, Wise's 500+ currency-corridor pages, G2's category pages, Airbnb's location pages. Done wrong, it produces algorithmic spam that gets crushed in the next Helpful Content Update and burns crawl budget on duplicate templates. The difference is data quality, query-intent fit, and per-page unique value. Your job is to determine if pSEO is even appropriate for this product, scope a page-set program that earns its rankings, and document the data pipeline + QA workflow that keeps quality high as the page count grows. This skill assumes you have basic SEO competence (keyword research, on-page basics). It focuses on the unique decisions of pSEO: page-set selection, data-source design, template architecture, indexation strategy, and the spam-vs-value line. --- ## Initial Assessment Before producing any output, gather context. **Do not skip this.** ### Step 0: Prerequisites 1. **Check for product-marketing-context.md** — load `.agents/product-marketing-context.md` if it exists. If not, ask the user to run the `cm-context` skill first. pSEO programs depend on knowing the ICP's actual search behavior. 2. **Check for keyword research / search demand data** — pSEO without volume data is a gamble. You need at least Ahrefs/Semrush/Google Search Console access, or a willingness to use Google autocomplete + "People Also Ask" as a proxy. 3. **Confirm engineering capacity** — pSEO needs a developer who can build a templating system and a content pipeline. If there is no eng support, scope down to a manual 20-50 page program instead. ### Diagnostic Questions Ask the user 5-10 of these before doing work. Keep them tight: 1. **What is the head term?** — e.g., "CRM software", "expense tracker", "Notion templates". This is the entity people search for; modifiers create variations. 2. **What modifier dimensions are candidates?** — by industry, by use case, by location, by integration, by competitor, by size segment. Usually 1-2 dimensions per program; more than 2 creates exponential thin content. 3. **What data sources do you have?** — Existing product data (templates, integrations, customer reviews), public data (locations, currency rates, regulations), licensed data, scraped data, or user-generated content. **No data = no pSEO.** 4. **What's the head term's search volume and difficulty?** — If the head term has 100 searches/month and KD 80, the long-tail modifiers will be sub-10/month. pSEO works best on head terms with thousands of monthly searches. 5. **Who is competing on this query class?** — If G2, Capterra, and Reddit threads dominate every variant, you need a clearly differentiated angle (proprietary data, unique tool, faster updates). 6. **Engineering bandwidth?** — Can engineering build a page generator + sitemap automation in the next 4-8 weeks? 7. **Distribution and indexation plan?** — How will Google discover 500+ new pages? (Sitemap, hub pages, internal links.) Do you have authority to push past the indexation threshold (~10% of pSEO pages typically get indexed)? 8. **Quality vs. volume preference?** — A 100-page program with each page hand-finished, or a 5,000-page program where 80% are generated and 20% are curated? Both are valid; the implementation differs. If the user cannot answer #1, #3, or #4, **stop and clarify**. Skipping these guarantees a thin-content program. --- ## Process The core workflow. 8 steps from idea to QA. ### Step 1: Validate the Page Set Has Real Demand Before designing templates, prove people search for this. List 20 example queries that the page set would target (e.g., "CRM for real estate agents", "CRM for accountants", "CRM for solo realtors"). Pull search volume for each from Ahrefs or Semrush. If the median is under 10 searches/month, you are likely creating pages that nobody will ever land on. **How to do it:** - Generate 20-50 candidate URLs from your proposed modifier × entity grid. - Pull volume, KD, and SERP features for each. - Compute total addressable monthly search volume across the full grid (often the sum is what matters, not individual queries). - Manually inspect the SERP for 5-10 example queries: Is it dominated by directories (G2, Capterra)? By Reddit/forums? By thin programmatic competitors? By rich, human-written content? **Decision criteria:** - If total grid volume < 5,000/month → likely not worth the eng investment; do manual content instead. - If SERPs are dominated by Reddit/forums → users want subjective opinions, not generated pages. Skip pSEO. - If SERPs already feature high-quality programmatic pages from competitors → you can compete *if* you bring proprietary data or a 10x faster update cycle. **Common gotcha:** Falling in love with the modifier dimension before validating demand. "CRM by zodiac sign" generates 1,000 pages but zero traffic. Volume first, creativity second. --- ### Step 2: Choose the Modifier × Entity Structure Most pSEO programs follow one of five archetypes. Pick the one that matches your data: **1. Integration / "Use X with Y" pages** - *Examples:* Zapier (`/apps/slack/integrations/google-sheets`), Make.com, n8n - *Data source:* List of your integrations + descriptions of each app - *Why it works:* Captures decision-stage queries ("how to connect X to Y") **2. Comparison / "X vs Y" pages** - *Examples:* G2, Capterra, but also product-led plays like HubSpot vs. Salesforce - *Data source:* Feature matrix, pricing, customer counts for each product - *Why it works:* Bottom-of-funnel, high purchase intent - *Note:* Overlaps with the `competitor-alternatives` skill — use that skill for the page craft, this skill for the scaling pipeline. **3. Location / "X in [City]" pages** - *Examples:* Airbnb (cities, neighborhoods), Yelp, Wise (currency corridors) - *Data source:* List of locations + local data (regulations, currency rates, listings count) - *Why it works:* "[Service] in [City]" is one of the highest-volume long-tail patterns in existence - *Risk:* Requires real per-location differentiation (counts of inventory, local regulations) or it becomes thin **4. Use-case / "X for [Persona]" pages** - *Examples:* Notion templates by role, Shopify "for [industry]" pages - *Data source:* List of personas + customer stories / use-cases per persona - *Why it works:* Matches how buyers self-segment ("CRM for solo realtors") - *Risk:* If you don't have differentiated content per persona, pages are near-duplicate **5. Template / "X templates" pages** - *Examples:* Notion template gallery, Canva templates, HubSpot templates - *Data source:* Actual templates (the asset *is* the page) - *Why it works:* The template itself is the unique value; SEO is a byproduct **Decision criteria:** - Pick the archetype where your **data is already strong**. The best pSEO programs leverage data the company already collects. - Pick 1 dimension, not 2, for the first launch. "CRM for [industry]" is one dimension. "CRM for [industry] in [city]" is two and creates a thin-content explosion. **Common gotcha:** Trying to launch 2 modifier dimensions at once (industry × company size = 50 × 4 = 200 cells, most of which have no demand and no data). Ship dimension 1, prove ROI, then layer dimension 2. --- ### Step 3: Audit Data Source Depth The single biggest predictor of pSEO success is data quality. For each page in your set, ask: what makes this page meaningfully different from the next one in the set? If the only difference is the city name swapped in 4 places, you have thin content. **Per-page data audit checklist:** - At least 3 unique data points per page (e.g., for "CRM for accountants": # of accounting-firm customers, top 3 use cases specific to accounting, integration with QuickBooks/Xero, accounting-firm-specific testimonial) - At least 1 piece of proprietary content (testimonial, case-study snippet, screenshot) - At least 1 dynamic/updated element (price, count, last-updated date) that signals freshness to Google **Data-source archetypes by source:** - **Internal product data** — Strongest moat. Zapier's integration pages are powered by their integration directory. You cannot copy this without copying the product. - **Customer-generated data** — G2 reviews, marketplace listings. High moat once you have volume, slow to bootstrap. - **Public-API data** — Currency rates (Wise), weather, sports stats. Easy to start, easy for competitors to copy. - **LLM-generated text** — Only viable if the prompt is grounded in real, page-specific data. Generic LLM filler is what Google's Helpful Content Update targets. **Decision criteria:** - If you cannot identify ≥3 unique data points per page, **stop and find more data** before building templates. - If LLM-generated text is a major component, every paragraph must be grounded in a structured field — never "write a paragraph about CRM for [industry]" with no input data. --- ### Step 4: Design the Page Template A pSEO template has fixed sections (same on every page) and dynamic sections (filled from data). Aim for 40-60% dynamic content by word count. **Standard template structure (use-case page example):** ```markdown ### H1: [Product] for [Persona] ### Hero subhead: One-sentence value-prop swapped per persona ### Persona-specific stat (dynamic): "Used by N [persona] teams" ### Top 3 use cases (dynamic, from data): bullets specific to persona ### Feature highlights (dynamic): which 4 features matter most for this persona ### Persona testimonial (dynamic): pulled from CRM/reviews ### Comparison vs. generic tool (semi-dynamic): table with persona-specific pain points ### FAQ (dynamic, 4-6 Q's per persona): scraped from PAA + customer interviews ### Final CTA (fixed) ### Related pages (dynamic): 3-6 internal links to sibling pages in the set ``` **How to do it:** - Sketch the template in markdown first. - Identify every `{{placeholder}}` and confirm the data source can fill it. - Add at least one section that requires *new* data per persona (most common failure: every section is the same template-filled text). - Set a minimum word count floor (~600 words) and a maximum ceiling (~1,800 words). Below the floor → thin; above the ceiling → padded. **Common gotcha:** Treating internal links as fixed. Programmatic internal linking (3-6 links to siblings) is one of the strongest pSEO patterns — it builds topic clusters automatically. Always template the related-pages module. --- ### Step 5: Build the Generation Pipeline This is engineering work, but the marketing strategist defines the pipeline contract. **Pipeline stages:** 1. **Data source** — Spreadsheet, database, CMS, or API. Single source of truth. 2. **Validation layer** — Reject rows that fail minimum data thresholds (missing required fields, too-short text). 3. **Template engine** — Next.js dynamic routes, Astro content collections, or Jamstack equivalent. 4. **Build / regeneration cadence** — Daily? Weekly? On-content-change? Stale data is a killer. 5. **Sitemap automation** — Every generated page must be in the sitemap and discoverable. 6. **noindex / canonical strategy** — Pages that fail the validation layer should be `noindex` until fixed, not published with thin content. **Decision criteria:** - If the build pipeline cannot regenerate the full set in <1 hour, you cannot update prices/counts daily — degrade to weekly. - Use static generation, not server-side rendering, unless data is hyper-fresh (currency rates). Static is faster, cheaper, and better for SEO. **Common gotcha:** Generating pages but not adding them to the sitemap. Google can theoretically discover via internal links, but indexation is 3-5x faster with sitemap submission. --- ### Step 6: SEO On-Page Optimization (Per-Page Layer) Every page in the set needs the standard on-page SEO treatment, just generated programmatically. **Per-page elements (all dynamic):** - **Title tag:** `{Product} for {Persona} | {Brand}` — 50-60 chars - **Meta description:** Includes target keyword + 1 differentiator + CTA — 140-155 chars - **H1:** Matches title tag intent, slightly different wording - **URL slug:** `/{persona-slug}` or `/for/{persona-slug}` — kebab-case, no stop words - **Schema:** Use `Product`, `FAQPage`, or `SoftwareApplication` (see `schema-markup` skill) - **Open Graph image:** Dynamic OG images using Vercel OG or similar — show product + persona name - **Canonical:** Self-canonical; if pages are near-duplicate, fix the template before launching **Common gotcha:** Identical meta descriptions across the set. Even if 80% of words must be templated, the persona name and one differentiator should vary. Search Console's "duplicate descriptions" warning is a flag Google uses for thin-content detection. --- ### Step 7: Indexation Strategy Most pSEO programs fail at indexation, not ranking. Google's indexer is selective: typically only 10-30% of programmatic pages get indexed without explicit help. **Indexation tactics (in order of impact):** 1. **Hub page** — Build a single high-quality hub (`/[category]/`) that lists all generated pages. This is the entry point for crawlers. 2. **Internal links from authority pages** — Link from homepage, pricing, and top-ranking blog posts to a sample of the new pages. 3. **Sitemap submission** — Submit a dedicated sitemap (e.g., `/sitemap-personas.xml`) for the new set. 4. **External links** — A handful of external links to the hub page accelerates indexation of the full set. 5. **Indexing API (for job postings / news only)** — Don't try to use this for marketing pages; Google explicitly disallows it. 6. **noindex the thin tail** — If 10% of generated pages have weak data, noindex them. A 90-page indexed program > a 100-page program with 10 thin pages dragging down site quality. **Decision criteria:** - After 30 days, check Google Search Console > Pages > Indexed. If <30% of your pages are indexed, the issue is internal linking or thin content, not crawl budget. - After 60 days, check rankings. If pages are indexed but not ranking, the issue is competitive (you need stronger differentiation) or topical (the query doesn't match your page intent). --- ### Step 8: QA, Monitor, and Iterate pSEO is never "done." Set up monitoring so you can spot quality decay. **Launch QA checklist:** - Spot-check 20 random pages — Do they read like real content? Would a customer get value? - Run Lighthouse / Core Web Vitals on 5 sample pages - Check mobile rendering - Verify schema validates - Verify internal links don't loop or 404 **Ongoing monitoring (monthly):** - GSC: Indexation rate of the set - GSC: Click-through rate per page (low CTR = bad title/meta) - GA4: Engagement rate (bounce rate proxy) - GA4: Conversions from the page set vs. non-pSEO pages - Sample 10 random pages quarterly — Has data gone stale? Is the template still working? **Decision criteria:** - If engagement rate drops below 30%, your pages are thin — add data fields or kill the weakest pages. - If conversions per visit are <50% of comparable hand-written pages, the pages are ranking but not converting — usually a positioning or CTA issue, not a pSEO issue. **Common gotcha:** Letting the page set rot. Prices change, integrations change, customer logos churn. A page-set program needs a quarterly refresh ritual or it becomes outdated and gets de-indexed. --- ## Output Format The deliverable is a Programmatic SEO Program Plan — a single doc the team can execute against. ```markdown # Programmatic SEO Program: {{program-name}} **Date:** {{date}} **Owner:** {{owner}} **Status:** Draft / Approved / In Build / Live **Target launch:** {{date}} --- ## 1. Page Set Definition - **Head term:** {{e.g., "CRM software"}} - **Modifier dimension:** {{e.g., "for [industry]"}} - **Estimated page count:** {{e.g., "42 industries"}} - **URL pattern:** {{e.g., "/crm-for/[industry-slug]"}} ## 2. Demand Validation | Sample query | Volume/mo | KD | SERP features | |---|---|---|---| | ... | ... | ... | ... | - **Total estimated TAM:** {{X searches/month across full grid}} - **Decision:** Proceed / Scope down / Kill ## 3. Data Source - **Primary data source:** {{e.g., internal customer DB filtered by industry}} - **Per-page unique data fields (minimum 3):** 1. {{field}} 2. {{field}} 3. {{field}} - **Dynamic/freshness field:** {{e.g., customer count updated weekly}} ## 4. Template Architecture [Embed template markdown] - **Fixed sections:** {{list}} - **Dynamic sections:** {{list}} - **Word count floor:** 600 - **Word count ceiling:** 1,800 ## 5. Generation Pipeline - **Tech stack:** {{e.g., Next.js dynamic routes + Notion DB}} - **Regeneration cadence:** {{daily / weekly / on-change}} - **Validation rules:** {{rows with missing X are noindexed}} ## 6. Indexation Plan - **Hub page URL:** {{/crm-by-industry/}} - **Internal links from:** {{homepage, /pricing, top 3 blog posts}} - **Sitemap:** {{/sitemap-industries.xml}} - **External link plan:** {{X outreach targets for hub page}} ## 7. Success Metrics (90-day) - **Indexation:** ≥60% of pages indexed - **Organic clicks:** ≥{{N}} clicks/month from the set - **Conversions:** ≥{{N}} signups/demos from the set - **CTR floor:** ≥2% on indexed pages ## 8. Risks & Mitigations | Risk | Likelihood | Mitigation | |---|---|---| | Helpful Content Update penalty | Medium | Enforce 600-word floor, ≥3 unique data fields per page | | Indexation stalls | High | Hub page + sitemap + internal links from day 1 | | Data goes stale | High | Quarterly refresh on calendar | --- ## Next Steps - [ ] Validate demand for 20 sample queries (data team, 1 week) - [ ] Engineering scope: template + pipeline (eng team, 4 weeks) - [ ] Build hub page (content team, 2 weeks) - [ ] Launch first 50 pages, monitor 2 weeks, then expand ``` --- ## Quality Bar A pSEO program is "done" (ready to launch) when: - [ ] Demand-validated: total grid search volume ≥5,000/month - [ ] Data-source audited: ≥3 unique data fields per page, ≥1 dynamic field - [ ] Template floor of 600 words, ceiling of 1,800 - [ ] Per-page unique title, meta description, and OG image - [ ] Hub page built and internally linked from at least 3 authority pages - [ ] Sitemap automation in place - [ ] noindex rule for rows that fail data validation - [ ] QA: 20 random pages spot-checked by a human, all pass a "would-a-customer-get-value" test - [ ] Monitoring: GSC + GA4 dashboards configured before launch ### Common Mistakes 1. **Skipping demand validation** — Building 1,000 pages targeting queries with 5 searches/month each. **Why it happens:** "Long tail" is mistaken for "no volume needed." **Fix:** Pull volume for 20 sample queries before scoping. If median is <10/month, kill the program or change the modifier dimension. 2. **Two modifier dimensions in v1** — Launching "CRM for [industry] in [city]" = 42 industries × 100 cities = 4,200 pages, of which maybe 50 have real demand. **Why it happens:** Founders are excited and want maximum surface area. **Fix:** Ship dimension 1 only. Wait 90 days. If it ranks, add dimension 2 (and only the cells where data is rich). 3. **Thin data = thin content** — Templates with only 1-2 fields swapped per page (city name in 4 places, nothing else). **Why it happens:** Marketing skipped Step 3 (data audit). **Fix:** Hard rule: at least 3 unique data points per page, at least 1 piece of proprietary content (testimonial, customer count, screenshot). No exceptions. 4. **LLM filler without grounding** — Using "write a paragraph about [topic]" prompts to inflate word count. **Why it happens:** GPT is fast and cheap. **Fix:** Every LLM-generated paragraph must take structured per-page data as input, not just the page topic. If GPT can write it without your data, Google has already seen 1,000 versions of it. 5. **Indexation as an afterthought** — Launching 500 pages with no hub page, no internal links, expecting Google to find them. **Why it happens:** Engineering ships the templates and treats indexation as marketing's problem. **Fix:** Hub page, internal links from authority pages, and dedicated sitemap submission are launch-blocking, not nice-to-haves. 6. **No noindex tail strategy** — Publishing the full set even though 10-20% of rows have weak data. **Why it happens:** Belief that more pages = more SEO. **Fix:** noindex any row that fails data validation. Site-wide quality signals matter more than raw page count post-Helpful-Content-Update. 7. **Letting the program rot** — Launching with fresh data, then never updating. After 12 months, prices are wrong, integrations have changed, customer logos have churned. **Why it happens:** No one owns the program after launch. **Fix:** Assign a quarterly refresh owner. Set GSC alerts for indexation drops. Treat the program like a product, not a campaign. 8. **Copying competitor templates without proprietary data** — Looking at G2 / Capterra and mimicking their structure with your data. **Why it happens:** "If they rank, this works." **Fix:** Aggregator sites have a different data moat (millions of reviews). If you can't out-data them on the specific dimension, find a different modifier where you can. --- ## Examples ### Example 1: B2B SaaS launches use-case pages for an HR tool **Context:** - Company: Roster, an HR platform for SMBs ($8M ARR, 35 employees) - Goal: Capture organic traffic for "HR software for [industry]" queries - Constraint: 1 engineer can spend 6 weeks; marketing team has 3 people **Input from user:** > "We want to go after 'HR software for [industry]' — we have customer logos in 25 industries, decent product data per industry, and our best blog post on 'HR for restaurants' is already ranking #4. Help us design a program." **Output (abbreviated):** ```markdown ### Program: HR Software by Industry ### Page set: /hr-software-for/[industry-slug] — 25 pages in v1 ### Demand validation (sample of 5): - "HR software for restaurants" — 720/mo, KD 31 - "HR software for construction" — 590/mo, KD 28 - "HR software for healthcare" — 1,400/mo, KD 47 - "HR software for retail" — 880/mo, KD 35 - "HR software for nonprofits" — 320/mo, KD 22 Total grid TAM: ~12,000 searches/month — proceed. ### Per-page data (from internal CRM + reviews): 1. # of customers in industry (e.g., "Trusted by 340 restaurants") 2. Top 3 industry-specific use cases (e.g., "tip pooling, shift swap, I-9 compliance") 3. 1 industry-specific testimonial pulled from Gainsight reviews 4. Industry-specific integrations highlighted (e.g., Toast, 7shifts for restaurants) 5. Industry-specific compliance callout (e.g., FLSA tip-credit for restaurants) ### Template structure: - H1: HR Software for [Industry] Teams - Hero: industry-tailored value prop + customer count - Top use cases (3, dynamic) - Industry compliance section (1 callout, dynamic) - Feature deep-dive (3 features, dynamic ordering by industry) - Testimonial (dynamic) - Integration callout (dynamic) - Pricing (fixed) - Industry FAQ (4 Qs, dynamic) - Related industries (3 internal links to siblings) ### Indexation plan: - Hub page at /industries/ listing all 25 - Link from homepage footer (under "Solutions") - Link from top-ranking blog "HR for restaurants" (already ranks #4) - Sitemap: /sitemap-industries.xml - Outreach: 5 industry-niche newsletters get a heads-up + free guest post ### Success metrics (90-day): - 18 of 25 pages indexed (72%) - 800+ organic clicks/month from set - 30+ demo requests attributed via GA4 ``` **Why this works:** Real demand validation (12K monthly searches), genuine data depth (5 dynamic fields, including proprietary customer count), and a pre-existing high-authority blog post they can link from to accelerate indexation. They are not trying to launch 500 pages — they are launching 25 strong ones first. --- ### Example 2: Fintech launches currency-corridor pages (Wise-style) **Context:** - Company: PayPal alternative for freelancers, $15M ARR, operating in 12 corridors - Goal: Capture "[currency A] to [currency B] transfer" search demand - Constraint: Wise dominates the SERP; need a differentiator **Input from user:** > "We want to rank for currency transfer queries like USD to EUR. Wise owns these. We have lower fees in 12 corridors but Wise has 500+ corridor pages and crushes us on authority. What do we do?" **Output (abbreviated):** ```markdown ### Program: Currency Corridor Pages — Differentiated by Real-Time Fee Comparison ### Page set: /send/[from-currency]/[to-currency] — 12 corridors in v1 (NOT 500) ### Demand: Validated, all 12 corridors >2,000/mo. ### Differentiation strategy: - Wise's pages are static; ours show **live fee comparison** updated every 6 hours - Pull Wise's public fee API, our fees, Western Union's published rate - Embed a live calculator widget at the top of every page - The widget itself is the moat: schema-marked, fast, mobile-first ### Per-page unique data: 1. Live fee comparison (us vs. Wise vs. WU vs. bank) 2. Transfer time benchmark (live test data, refreshed daily) 3. Historical fee chart (last 30 days) 4. Corridor-specific regulations callout (FX controls, recipient bank rules) 5. Customer testimonial from a sender in that corridor ### Indexation plan: - Hub at /send-money/ with calculator - Internal links from blog ("best way to send money to Europe" → /send/USD/EUR) - 12 outreach targets per corridor for backlinks (expat forums, country-specific Reddit subs) - Schema: ExchangeRate, FAQPage, BreadcrumbList ### v2 (after 90 days, only if v1 hits indexation targets): - Add reverse pairs (EUR → USD) = +12 pages - Add Top-50 corridors only — NOT 500 — focused on real demand - Always-on freshness signal: timestamp in title tag "Updated [Date]" ### Success metrics (90-day): - 10 of 12 pages indexed - 2+ pages ranking in top 10 for primary corridor query - 5,000+ calculator interactions/month (proxy for engagement) ``` **Why this works:** They don't try to out-volume Wise's 500-page program. Instead, they ship 12 high-value pages with a *live data moat* (real-time fee comparison) that Wise's static pages can't match. They earn rankings by being the best answer for "how much will it actually cost right now," not by having more pages. --- ## Related Skills Chain these skills together for compounding outcomes. - **[`seo-audit`](../seo-audit/SKILL.md)** — Use *before* this skill to confirm your domain has enough authority to compete on the head term. Programs launched on weak domains take 12+ months to index. - **[`schema-markup`](../schema-markup/SKILL.md)** — Use *alongside* this skill to add `Product`, `FAQPage`, and `BreadcrumbList` schema to every generated page. Critical for rich results at scale. - **[`site-architecture`](../site-architecture/SKILL.md)** — Use *before* this skill to design the URL hierarchy and internal-link plan that the page set will plug into. - **[`competitor-alternatives`](../competitor-alternatives/SKILL.md)** — Use *alongside* this skill if your modifier dimension is "[Competitor] alternative" or "X vs Y." That skill covers the page craft; this one covers the scaling pipeline. - **[`ai-seo`](../ai-seo/SKILL.md)** — Use *after* this skill to optimize the same pages for AI search (Perplexity, ChatGPT). pSEO pages with structured data and clear answers tend to be cited heavily by AI. --- ## References - Andrew Chen, "Programmatic SEO: how Zapier built a $5B business on integration pages" — canonical case study on the integration archetype - Tomek Borek, "The pSEO playbook" — practical playbook for indexation - Google Search Central, "Helpful Content Update" — the spam-vs-value line that all pSEO programs must respect - Wise.com transfer pages — gold standard for the location/corridor archetype - Notion template gallery — gold standard for the template archetype