[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KAGMGPFZP1N16KBY4717R":3,"skill-same:01M71KAGMGPFZP1N16KBY4717R":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71KAGMGPFZP1N16KBY4717R","programmatic-seo",null,"Build SEO-optimized pages at scale using templates and data.","clawdsolana\u002FOpenClawd","clawdsolana","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279036008?v=4","01M71JTVF9FNGKE2SVJRPTQM31","OpenClawd","01M71JTVGCKWBSS8ZYC1HYWVA5",2,"MIT","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fsecondary_skills\u002Fprogrammatic-seo\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000019","营销推广","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37],"programmatic seo","seo","programmatic","at","build","templates","scale","data","pages","2026-11-10 10:12:30",false,"---\nname: programmatic-seo\ndescription: Build SEO-optimized pages at scale using templates and data.\n---\n\n# Programmatic SEO\n\n## OpenClawd Operator Adaptation\n\nRun this skill as part of the OpenClawd operator deck. Preserve the skill-specific workflow below, but frame outputs for Solana-native agents when relevant: prefer OpenClawd language, note whether the work can support autonomous agent operations, and keep financial, legal, tax, hiring, medical, or other regulated outputs informational unless the skill already requires a stricter disclaimer. Use the Llobster Legend persona only as light operator framing; do not let branding override accuracy, safety, or the user's stated domain.\n\n\nBuild SEO-optimized pages at scale using templates and data. Create page generators that target keyword patterns and produce unique, valuable content for each variation.\n\n## When to Use\n\n- User wants to create many SEO-driven pages from a template (e.g., \"[product] vs [competitor]\", \"[service] in [city]\")\n- User mentions programmatic SEO, template pages, directory pages, location pages, or comparison pages at scale\n\n- User wants to build an \"alternatives to X\" page set, integrations directory, or glossary\n- User has a data set they want to turn into individual landing pages\n\n## When NOT to Use\n\n- Auditing existing SEO issues (use seo-auditor skill)\n- Writing a single blog post or landing page (use content-machine skill)\n\n- One-off competitive analysis (use competitive-analysis skill)\n\n## Core Principles\n\n1. **Information gain is everything** — Every page must contain information the user cannot find on existing top-10 results. Proper H1s, keyword density, and clean structure are baseline hygiene, not a ranking advantage. Pages that \"look like SEO\" but add no new information are what Google's spam systems now target.\n2. **Unique value per page** — Every page must provide value specific to that page, not just swapped variables in a template. If you removed the entity name, would two pages be indistinguishable? If yes, don't publish.\n\n3. **Proprietary data wins** — Hierarchy: proprietary > product-derived > user-generated > licensed > public (weakest). The strongest pSEO pages contain data no one else has — original tests, first-party metrics, real user reviews, proprietary calculations.\n4. **Subfolders, not subdomains** — `yoursite.com\u002Ftemplates\u002Fresume\u002F`not`templates.yoursite.com\u002Fresume\u002F`\n\n5. **Match search intent precisely** — Pages must match the intent behind the query, not just contain the keywords. This means choosing the right page type (blog post vs. comparison table vs. tool vs. directory listing), answering the actual question, and structuring content the way users expect for that query type.\n6. **Quality over quantity** — 100 great pages beat 10,000 thin ones. Scale without information gain is just industrialized noise. Google has more content than it needs — your pages must earn their place by being genuinely better than what already ranks.\n\n7. **Topical authority compounds** — A site that demonstrates deep expertise in a specific topic earns trust signals that lift all pages in that topic cluster. Scattered, shallow coverage across unrelated topics builds no authority.\n\n---\n\n## ⚠️ CRITICAL: Check the App's Rendering Strategy First\n\n**Before writing a single line of code**, determine whether the existing application is a Single Page Application (SPA).\n\n**SPAs (React, Vue, Angular, Svelte) are invisible to Googlebot.** Googlebot fetches raw HTML and does not execute client-side JavaScript. A React component that renders `\u003Ch1>Currency Converter\u003C\u002Fh1>`only works in a browser — Googlebot sees an empty`\u003Cdiv id=\"root\">\u003C\u002Fdiv>`.\n\n### Decision Tree\n\n```text\n\nIs the app a SPA (React\u002FVue\u002FAngular)?\n\n│\n\n├── YES → SEO pages MUST be server-rendered (SSR)\n\n│ Options:\n\n│ A. Express\u002FFastify route returning a complete HTML string ← simplest for existing SPAs\n\n│ B. Migrate to Next.js\u002FNuxt\u002FSvelteKit with SSR support\n\n│ C. Add a static site generator (Astro) alongside the SPA for SEO pages only\n\n│\n\n└── NO (already Next.js, Nuxt, etc.) → Use the framework's built-in SSR\u002FSSG\u002FISR patterns (see Step 6)\n\n```\n\n**The SPA trap:** The most common pSEO mistake is adding routes to a React Router \u002F Wouter \u002F Vue Router app and assuming they will be indexed. They will not. Always verify by `curl`-ing the URL and checking if the content is present in the raw HTML response:\n\n```bash\n\ncurl -s https:\u002F\u002Fyoursite.com\u002Fyour-seo-page | grep \"target keyword\"\n\n# If empty or only returns \u003Cdiv id=\"root\">\u003C\u002Fdiv> → not crawlable\n\n```\n\n---\n\n## Content Authenticity — Don't Hallucinate Business Data\n\nWhen building programmatic SEO for **the user's own company**, you will not have access to their internal data (customer stories, case studies, testimonials, product metrics, pricing, team bios, etc.). **Do not fabricate this information.**\n\n### Before generating any company-specific content, ask the user for\n\n- Customer names, logos, or testimonials they want featured\n- Case study data (metrics, outcomes, quotes)\n\n- Product-specific details (features, pricing tiers, integrations list)\n- Any proprietary data that should populate template variables\n\n#### If the user hasn't provided this data, default to safe content patterns\n\n- Industry research and statistics (sourced via `webSearch`)\n- General descriptions of the problem\u002Fsolution category\n\n- Feature explanations based on what's publicly visible on their site (use `webFetch` on their domain)\n- Placeholder blocks clearly marked `[INSERT: customer testimonial]`or`[INSERT: case study metrics]`\n\n- Comparison data pulled from public sources (G2, Capterra reviews via `webSearch`)\n\n**Never generate:** fake customer quotes, fabricated ROI numbers, invented case studies, made-up testimonials, or fictional company metrics. These damage trust and can create legal liability.\n\nFor **generic\u002Fresearch topics** (e.g., \"[city] cost of living\", \"[tool A] vs [tool B]\", glossary terms), use `webSearch` to gather real data and cite sources.\n\n---\n\n## ⚠️ Strategic Judgment — What AI Cannot Do For You\n\n**This is the most important section in this skill.** AI excels at scaling execution — drafting content, structuring pages, generating variations. But it cannot make the strategic decisions that determine whether a pSEO campaign succeeds or fails. These decisions must come from the user (or a human SEO strategist), and the agent must actively prompt for them rather than making assumptions.\n\n### Decisions that require human judgment\n\nBefore building anything, the user must answer (or the agent must ask):\n\n1. **Is this keyword worth a page at all?** Not every keyword with search volume deserves a page. If the top 10 results are dominated by high-authority brands and the user's site has no topical authority, building 500 pages won't help.\n2. **What page type matches the query intent?** The same topic might need a blog post, a comparison table, an interactive tool, a directory listing, or a data profile. Getting the page type wrong means the page will never rank, regardless of content quality. For example:\n\n- \"best CRM for real estate\" → listicle\u002Fcomparison (not a product page)\n- \"HubSpot vs Salesforce\" → head-to-head comparison (not a blog post)\n\n- \"what is a CRM\" → educational\u002Fglossary (not a product page)\n- \"CRM pricing\" → pricing table with real numbers (not a blog post about pricing)\n\n1. **What information gain does this page offer over the current top 10?** If the answer is \"nothing — we're just rewriting what's already there with AI,\" do not build the page. Specifically ask: do we have original data, unique analysis, proprietary metrics, real case studies, or first-hand experience that the current results lack?\n2. **Does the user's site have topical authority in this area?** A brand-new domain publishing 200 glossary pages on a topic it has no track record in will be ignored. Topical authority is built through depth (many related, high-quality pages), external trust signals (backlinks from relevant sites), and user engagement over time.\n\n3. **What is the commercial intent and conversion path?** Pages that attract traffic but have no clear next step for the user waste crawl budget and dilute site quality. Every pSEO page should have a purpose beyond \"get impressions.\"\n\n### What the agent should do\n\n- **Always ask the user** what unique data, experience, or perspective they can bring to the topic before generating content. If they say \"just write something about X,\" push back and explain that pages without information gain will not rank.\n- **Never assume scale equals strategy.** If the user asks for \"500 SEO articles,\" the correct response is to first validate whether 500 pages is the right number, whether the topics have demand, and whether the user has enough unique data to make each page valuable.\n\n- **Recommend starting small.** Build 10-20 high-quality pages first, validate they get indexed and earn impressions, then scale what works. This is the opposite of the \"blast 500 pages and hope\" approach.\n- **Be explicit about what AI is doing vs. what requires human input.** AI writes the page. The human decides whether the page should exist.\n\n### The \"SEO cosplay\" trap\n\nA page can have perfect H1 tags, clean H2\u002FH3 hierarchy, optimized meta descriptions, proper schema markup, good keyword density, and fast load times — and still rank nowhere. These are table stakes, not differentiators. Google's ranking systems evaluate whether a page genuinely satisfies the user's query better than alternatives. Structure without substance is what practitioners call \"SEO cosplay\" — it looks like SEO but doesn't perform.\n\n**The agent must not conflate technical SEO hygiene with content quality.** Both are necessary. Neither is sufficient alone.\n\n---\n\n## Information Gain — The Core Quality Signal\n\nGoogle's systems increasingly evaluate \"information gain\" — whether a page adds something new to the corpus of existing results for a query. This is the single most important concept in modern pSEO.\n\n### What counts as information gain\n\n| Source of gain | Example | Strength |\n\n|---|---|---|\n\n| **Original data \u002F metrics** | Your own A\u002FB test results, proprietary benchmarks, internal analytics | Strongest — impossible to replicate |\n\n| **First-hand experience** | Actual product reviews you conducted, real case studies with named clients | Very strong — hard to fake |\n\n| **Unique analysis** | Novel comparisons, calculated scores, derived insights from raw data | Strong — requires expertise |\n\n| **Curated judgment** | Expert picks, opinionated rankings with reasoning, \"here's what we'd actually use\" | Moderate — requires credibility |\n\n| **Structured aggregation** | Data from multiple sources combined into a single useful view (with attribution) | Moderate — useful but reproducible |\n\n| **Rewritten common knowledge** | The same information available on 50 other sites, just rephrased | Zero — this is what gets penalized |\n\n### The information gain test\n\nBefore publishing any pSEO page set, run this test on 5 random pages:\n\n1. Search Google for the target keyword\n2. Read the top 3 results\n\n3. Read your generated page\n4. Ask: **\"Does our page contain at least one piece of information, data point, or insight that none of the top 3 results have?\"**\n\n5. If no → do not publish. Improve the data source or reduce the page set to only pages where you have genuine information gain.\n\n### Scaled content abuse (Google's 2024+ spam policy)\n\nGoogle now explicitly targets \"scaled content abuse\" — content produced at scale (whether by AI, humans, or automation) that exists primarily to manipulate rankings rather than help users. The pattern Google detects is:\n\n- Many pages with similar structure\n- Smooth, readable prose with no new information\n\n- Comprehensive coverage that is really just reorganized common knowledge\n- High page count with no corresponding trust signals or user engagement\n\n- Each page is readable, but after reading it you've learned nothing new\n\n**This pattern triggers penalties regardless of whether AI wrote the content.** A human content farm producing the same pattern gets the same treatment. The issue is not AI — it is the absence of value at scale.\n\n---\n\n## Proven Playbooks (Real Traffic Numbers)\n\n| Playbook | URL pattern | Who does it | Scale |\n\n|---|---|---|---|\n\n| **Integrations** | `\u002Fapps\u002F[A]\u002Fintegrations\u002F[B]` | **Zapier** — ~56k pages, 5.8M+ monthly organic visits, ranks for 1.3M keywords. Proprietary data (triggers\u002Ftemplates per app pair) no one else can replicate. | N² combinations |\n\n| **Conversions** | `\u002Fcurrency-converter\u002F[from]-to-[to]-rate` | **Wise** — 8.5M pages across locale subfolders, 60M+ monthly visits. Live exchange-rate data + fee calculators = unique value per page. | N² × locales |\n\n| **Locations** | `\u002FRestaurants-[city]`,`\u002F[cuisine]-Restaurants-[city]`,`\u002FRestaurants-[neighborhood]` | **Tripadvisor** — 700M+ pages, 226M+ monthly visits. UGC reviews keep pages fresh; layered matrix (city × cuisine × neighborhood). | city × category × modifier |\n\n| **Data profiles** | `\u002F[city-slug]` | **Nomad List** — cost-of-living, internet speed, safety scores per city. Pages are pure data tables — minimal prose, high value. | N entities |\n\n| **Comparisons** | `\u002F[A]-vs-[B]`,`\u002Falternatives\u002F[A]` | **G2, Capterra** — \"vs\" pages + \"alternatives\" pages, populated by user reviews. | N² \u002F 2 |\n\n| **Templates** | `\u002Ftemplates\u002F[type]` | **Canva, Notion** — each template is a landing page. | N types |\n\n| **Glossary** | `\u002Flearn\u002F[term]` | **Ahrefs, HubSpot** — definition pages cluster topical authority. | N terms |\n\n| **How-to guides** | `\u002Fguides\u002F[task]-with-[tool]` | Documentation sites — step-by-step guides, HowTo schema | N tasks × M tools |\n\n| **Personas** | `\u002F[product]-for-[audience]` | \"CRM for real estate agents\" | N × M |\n\n**The test:** If your data doesn't meaningfully change between page variations, don't build it. Zapier works because Slack+Asana genuinely differs from Slack+Trello. \"Plumber in Austin\" vs \"Plumber in Dallas\" with identical boilerplate = thin content penalty.\n\nLayer playbooks for long-tail: Tripadvisor's \"Best Italian Restaurants in Chinatown NYC\" = curation × cuisine × neighborhood.\n\n### Why these playbooks work — and why copycats fail\n\nEvery successful pSEO example above shares one trait: **the data genuinely changes between pages.** Zapier's Slack+Asana page has different triggers, different actions, and different templates than Slack+Trello. Wise's USD-to-EUR page has a different exchange rate, different fee structure, and different historical chart than USD-to-GBP. Tripadvisor's pages have different restaurants, different reviews, and different ratings per city.\n\nCopycats fail because they replicate the URL structure without replicating the information gain. Creating 500 \"\u002Fservice-in-city\" pages where only the city name changes and the rest is identical prose is not programmatic SEO — it is spam at scale. Google's systems detect this pattern reliably: many pages, similar structure, no meaningful data variation.\n\n**Before choosing a playbook, ask:** \"Do I have genuinely different data for each page variation, or am I just swapping one variable into the same template?\" If the latter, reduce the page count to only variations where you have real data, or choose a different playbook entirely.\n\n---\n\n## Implementation\n\n### Step 1: Keyword Pattern Research\n\n- Identify the repeating structure and variables\n- Count how many unique combinations exist\n\n- Validate demand: aggregate search volume, distribution (head vs. long tail), trend direction\n\n### Step 2: Data Requirements\n\n- What data populates each page?\n- Is it first-party, scraped, licensed, or public?\n\n- How is it updated and maintained?\n\n### Step 3: Template Design\n\n#### Page structure\n\n- H1 with target keyword\n- Unique intro (not just variables swapped — conditional content based on data)\n\n- Data-driven sections with original insights\u002Fanalysis per page\n- Related pages \u002F internal links\n\n- CTAs appropriate to intent\n\n##### Ensuring uniqueness — critical to avoid thin content penalties\n\n- Conditional content blocks that vary based on data attributes\n- Calculated or derived data (not just raw display)\n\n- Editorial commentary unique to each entity\n- User-generated content where possible\n\n### Step 4: Internal Linking Architecture\n\n#### Hub and spoke model\n\n- Hub: Main category page (e.g., \"\u002Fintegrations\u002F\")\n- Spokes: Individual programmatic pages (e.g., \"\u002Fintegrations\u002Fslack-asana\u002F\")\n\n- Cross-links between related spokes\n\nEvery page must be reachable from the main site. **Update the main app's footer and navigation to include links to SEO hub pages** — SEO pages that aren't linked from the main site are orphan pages that Google may never discover or trust.\n\nInclude XML sitemap and breadcrumbs with structured data.\n\n### Step 5: Indexation Strategy\n\n- Prioritize high-volume patterns for initial crawling\n- Noindex very thin variations rather than publishing them\n\n- Manage crawl budget (separate sitemaps by page type)\n- Monitor indexation rate in Search Console\n\n### Step 6: Build the Page Generator\n\n#### Rendering strategy decision\n\n| Page count | Data freshness | Strategy |\n\n|---|---|---|\n\n| \u003C1,000 | Rarely changes | **SSG** — pre-render everything at build |\n\n| 1,000-100,000 | Changes daily\u002Fweekly | **ISR** — pre-render popular subset, generate rest on-demand + cache |\n\n| 100,000+ or live data | Real-time (prices, rates) | **ISR with short revalidate** or SSR |\n\nSSG is fastest but build time scales linearly — 50k pages can mean 30+ min builds. ISR is the pSEO sweet spot: instant deploys, pages generate on first request then cache.\n\n#### For SPAs: Express SSR pattern\n\nWhen adding pSEO to an existing SPA, the simplest approach is adding Express routes that return complete HTML strings. Organize into three layers:\n\n##### 1. Shared HTML shell (create this first)\n\n```typescript\n\n\u002F\u002F server\u002FssrShared.ts — create before writing any individual page\n\nexport function ssrHtmlShell({ title, description, canonical, schemaJson, css, body, ...}): string {\n\nreturn `\u003C!DOCTYPE html>\n\n\u003Chtml lang=\"...\">\n\n\u003Chead>\n\n\u003Cmeta charset=\"UTF-8\" \u002F>\n\n\u003Ctitle>${title}\u003C\u002Ftitle>\n\n\u003Cmeta name=\"description\" content=\"${description}\" \u002F>\n\n\u003Clink rel=\"canonical\" href=\"${canonical}\" \u002F>\n\n\u003C!-- OG tags, fonts, schema -->\n\n\u003Cstyle>${sharedCss()}${css ?? \"\"}\u003C\u002Fstyle>\n\n\u003C\u002Fhead>\n\n\u003Cbody>\n\n${header()}\n\n${body}\n\n${footer()}\n\n\u003C\u002Fbody>\n\n\u003C\u002Fhtml>`;\n\n}\n\n```\n\nCreate this shared shell **before** writing any individual page. Every new SEO page reuses it. This ensures consistent branding (header, footer, fonts, base CSS) across all SSR pages without duplication.\n\n###### 2. Data + page generator modules (one per playbook)\n\n```typescript\n\n\u002F\u002F server\u002Fglossary.ts\n\nexport const TERMS: GlossaryTerm[] = [ \u002F* structured data *\u002F ];\n\nexport function getTermHtml(slug: string, logoBase64: string): string | null { ... }\n\nexport function getTermIndexHtml(logoBase64: string): string { ... }\n\n```\n\nKeep data as typed arrays\u002Fobjects in the same file as the generator. This makes content easy to update without touching routing logic.\n\n###### 3. Routes (thin, just wiring)\n\n```typescript\n\n\u002F\u002F in routes.ts\n\napp.get(\"\u002Fglossary\u002F:slug\", (req, res) => {\n\nconst html = getTermHtml(req.params.slug, LOGO_BASE64);\n\nif (!html) { res.status(404).end(); return; }\n\nres.setHeader(\"Cache-Control\", \"public, max-age=86400\");\n\nres.setHeader(\"Content-Type\", \"text\u002Fhtml; charset=utf-8\");\n\nres.send(html);\n\n});\n\n```\n\n#### Cache headers per page type\n\nSet cache headers based on data freshness — not one-size-fits-all:\n\n| Page type | Recommended header | Reason |\n\n|---|---|---|\n\n| Static content (glossary, guides) | `public, max-age=86400` | Content rarely changes; CDN can serve |\n\n| Live data (exchange rates, prices) | `no-cache`or`s-maxage=60` | Must be fresh; stale data damages credibility |\n\n| Semi-dynamic (weekly updates) | `public, s-maxage=3600, stale-while-revalidate=86400` | Balance freshness vs. load |\n\n#### For Next.js App Router\n\n```tsx\n\nexport async function generateStaticParams() {\n\nconst popular = await db.query('SELECT slug FROM entities ORDER BY search_volume DESC LIMIT 500');\n\nreturn popular.map(e => ({ slug: e.slug }));\n\n}\n\nexport const dynamicParams = true;\n\nexport const revalidate = 3600;\n\nexport async function generateMetadata({ params }) {\n\nconst { slug } = await params;\n\nconst entity = await getEntity(slug);\n\nreturn {\n\ntitle: `${entity.name} — ${entity.category} | Brand`,\n\ndescription: entity.summary,\n\nalternates: { canonical: `https:\u002F\u002Fsite.com\u002F${entity.category}\u002F${slug}` },\n\n};\n\n}\n\nexport default async function Page({ params }) {\n\nconst { slug } = await params;\n\nconst entity = await getEntity(slug);\n\nif (!entity) notFound();\n\n}\n\n```\n\n**Critical ISR rules:** `generateStaticParams`is NOT re-run on revalidation. Must return an array (even`[]`) or the route becomes fully dynamic. Set`dynamicParams = false` only if you want 404s for anything not pre-generated.\n\n#### Astro alternative\n\nBetter for content-heavy, less-interactive pages. Ships zero JS by default — better Core Web Vitals.\n\n```js\n\nexport async function getStaticPaths() {\n\nconst entities = await loadEntities();\n\nreturn entities.map(e => ({ params: { slug: e.slug }, props: { entity: e } }));\n\n}\n\n```\n\nNo native ISR; use on-demand rendering + `Cache-Control: s-maxage=3600, stale-while-revalidate`.\n\n#### Sitemaps at scale\n\nGoogle's limit is 50,000 URLs per sitemap file. Shard into `sitemap-1.xml`,`sitemap-2.xml`... referenced by a sitemap index. For ISR\u002FSSR sites, generate sitemaps server-side from the DB, not at build time. **Warning:** Google will NOT index all pages immediately — indexation at scale takes weeks\u002Fmonths. Prioritize high-volume slugs in the first sitemap.\n\n---\n\n## SSR-Specific Implementation Notes\n\n### Asset handling in SSR\n\nFrontend assets (images, fonts) processed by Vite\u002Fwebpack\u002Fesbuild are **not** directly accessible to server-side routes. Common problems:\n\n- Images imported with `import logo from \"@assets\u002Flogo.png\"` work in React but not in Express route handlers\n- Files copied to `public\u002F` by the build tool may not be served correctly in development\n\n- Files with restricted permissions (`rw-------`) will throw EACCES errors when read from disk\n\n#### Solutions by asset type\n\n| Asset | Recommended approach |\n\n|---|---|\n\n| Logo \u002F brand images | Base64-encode at server startup; embed inline in `\u003Cimg src=\"data:...\">` |\n\n| Small icons | Inline SVG string in the HTML template |\n\n| External fonts | Google Fonts CDN link in `\u003Chead>` |\n\n| Background images | Use CSS gradients or CDN URLs |\n\n```typescript\n\n\u002F\u002F Base64 encode logo once at startup — safe for all SSR pages\n\nimport fs from \"fs\";\n\nconst logoBuffer = fs.readFileSync(\".\u002Fattached_assets\u002Flogo.png\");\n\nconst LOGO_BASE64 = `data:image\u002Fpng;base64,${logoBuffer.toString(\"base64\")}`;\n\n```\n\n### Header\u002Ffooter consistency\n\nSSR pages and the React\u002FVue\u002FSPA app will share the same domain. Users will navigate between them. **Brand consistency is critical** — a mismatch between the main app's header and the SSR page's header breaks trust.\n\nSteps:\n\n1. Study the main app's header\u002Ffooter colors, logo treatment, link structure, and typography\n2. Replicate them in the shared `ssrShared.ts` shell functions — not approximations, pixel-for-pixel matches\n\n3. When the main app's footer is updated (new links, new columns), update the SSR footer function too\n4. Conversely, when new SSR hub pages are added (e.g., `\u002Fglossary`,`\u002Fguides`), add them to the main app's footer navigation\n\n### Logo rendering in SSR\n\nIf the logo image has a non-standard aspect ratio or significant whitespace, a plain `height: 48px` will render it incorrectly. Inspect how the main React app clips and positions the logo, then replicate exactly:\n\n```html\n\n\u003C!-- If the main app uses overflow-hidden clipping to show only part of the image: -->\n\n\u003Cdiv style=\"height:56px; width:160px; overflow:hidden; display:flex; align-items:center; justify-content:center;\">\n\n\u003Cimg src=\"${LOGO_BASE64}\" style=\"width:auto; height:250%; object-fit:contain; margin-top:-5%;\" \u002F>\n\n\u003C\u002Fdiv>\n\n```\n\nDon't guess — read the main app's logo component before writing the SSR equivalent.\n\n### Breadcrumb placement and negative margins\n\nA common hero design pattern uses negative `margin-top` on the content section to create a \"card floating up into the hero\" visual effect:\n\n```css\n\n.hero { padding-bottom: 72px; }\n\n.main { margin-top: -32px; } \u002F* pulls first card up into hero *\u002F\n\n```\n\n**This breaks breadcrumbs.** If a breadcrumb element sits between the hero and `.main`in the HTML, the negative margin on`.main` will pull the main content over the breadcrumb, hiding it.\n\n**Rule: breadcrumbs must always be the first child inside `.main`**, never between`.main` and the preceding section.\n\n```html\n\n\u003C!-- WRONG: breadcrumb between hero and main -->\n\n\u003Cdiv class=\"hero\">...\u003C\u002Fdiv>\n\n\u003Cnav class=\"breadcrumb\">...\u003C\u002Fnav> \u003C!-- will be covered by .main -->\n\n\u003Cdiv class=\"main\">...\u003C\u002Fdiv>\n\n\u003C!-- CORRECT: breadcrumb inside main -->\n\n\u003Cdiv class=\"hero\">...\u003C\u002Fdiv>\n\n\u003Cdiv class=\"main\">\n\n\u003Cnav class=\"breadcrumb\">...\u003C\u002Fnav> \u003C!-- safely in the content flow -->\n\n\u003Cdiv class=\"card\">...\u003C\u002Fdiv>\n\n\u003C\u002Fdiv>\n\n```\n\nAdditionally, if a page has a breadcrumb and the hero uses large `padding-bottom` (designed to pair with negative margin), that padding becomes wasted dark space. Override it on breadcrumb pages:\n\n```html\n\n\u003Cdiv class=\"hero\" style=\"padding-bottom: 32px;\">\n\n```\n\n---\n\n## Schema Markup by Playbook\n\nMatch schema type to content type — don't use a generic WebPage schema when a more specific type exists:\n\n| Playbook | Schema type | Key properties |\n\n|---|---|---|\n\n| Glossary \u002F definitions | `DefinedTerm`+`DefinedTermSet`|`name`,`description`,`inDefinedTermSet` |\n\n| How-to guides | `HowTo`|`step[]`with`HowToStep`,`tool`,`supply` |\n\n| FAQ sections | `FAQPage`|`mainEntity[]`with`Question`+`Answer` |\n\n| Comparisons | `ItemList`or`Review`|`itemListElement[]`,`ratingValue` |\n\n| Data profiles | `Dataset`or`Place`|`name`,`description`,`spatialCoverage` |\n\n| Recipes\u002Ftemplates | `CreativeWork`|`name`,`description`,`genre` |\n\nMultiple schema types can appear on the same page (e.g., a HowTo guide can also have a FAQPage block at the bottom).\n\n---\n\n## Internationalization and Locale Handling\n\nOnly add multilingual pSEO when you have **genuinely translated data** — not machine-translated boilerplate. Machine-translating 10,000 thin pages at once is one of the fastest ways to trigger a spam manual action.\n\n### URL structure — subfolders win\n\n| Approach | Example | SEO verdict |\n\n|---|---|---|\n\n| Subfolder | `yoursite.com\u002Fes\u002Fglosario\u002Fpresupuesto` | **Preferred** — consolidates domain authority |\n\n| ccTLD | `yoursite.es\u002Fglosario\u002Fpresupuesto` | Strong signal but costly to maintain |\n\n| Subdomain | `es.yoursite.com\u002F...` | Treated as separate site; avoid for pSEO |\n\n| Query param | `yoursite.com\u002Fglossary?lang=es` | Not crawlable reliably; never use |\n\n### hreflang implementation\n\nEvery page that has a locale variant must declare all variants (including `x-default`) in`\u003Chead>`:\n\n```html\n\n\u003Clink rel=\"alternate\" hreflang=\"en\" href=\"https:\u002F\u002Fsite.com\u002Fglossary\u002Fbudget\" \u002F>\n\n\u003Clink rel=\"alternate\" hreflang=\"es\" href=\"https:\u002F\u002Fsite.com\u002Fes\u002Fglosario\u002Fpresupuesto\" \u002F>\n\n\u003Clink rel=\"alternate\" hreflang=\"x-default\" href=\"https:\u002F\u002Fsite.com\u002Fglossary\u002Fbudget\" \u002F>\n\n```\n\nRules:\n\n- Every page in the set must list **all** pages in the set (bidirectional)\n- Omitting a language from even one page breaks the cluster for Google\n\n- `x-default` should point to the most general version (usually English or a language-selector page)\n- Validate with Google Search Console → Enhancements → International targeting\n\n### Data structure for multilingual pages\n\nStore translations as a map keyed by locale so the generator stays clean:\n\n```typescript\n\nconst TERM = {\n\nslug: { en: \"budget\", es: \"presupuesto\" },\n\nname: { en: \"Budget\", es: \"Presupuesto\" },\n\ndefinition: { en: \"...\", es: \"...\" },\n\n};\n\nfunction getTermHtml(slug: string, locale: \"en\" | \"es\"): string { ... }\n\n```\n\n### Machine-translation risk\n\nMachine-translated prose is detectable by Google and often results in near-duplicate content across locales. Only translate if:\n\n- A human reviews\u002Fedits the output, OR\n- The page is primarily structured data (tables, numbers, steps) with minimal prose\n\n---\n\n## Content Freshness Signals\n\nGoogle rewards pages that are genuinely kept up to date. Stale pSEO pages — especially data-driven ones — gradually lose rankings as fresher competitors appear.\n\n### `dateModified` in schema\n\nEvery page with structured data should carry a timestamp:\n\n```json\n\n{\n\n\"@type\": \"WebPage\",\n\n\"datePublished\": \"2024-01-15\",\n\n\"dateModified\": \"2025-03-01\"\n\n}\n\n```\n\n**Only update `dateModified`when content actually changes.** Bumping it on a schedule without real changes is a deception signal that Google penalises. If you auto-regenerate pages, tie`dateModified`to the data source's`updatedAt`, not the deploy timestamp.\n\n### When and how to regenerate\n\n| Data type | Trigger strategy |\n\n|---|---|\n\n| Exchange rates \u002F prices | SSR with short cache (`s-maxage=60`); no static generation |\n\n| Product\u002Fcompany data | Webhook from data source on change → re-render and invalidate CDN cache |\n\n| Weekly-updated datasets | Nightly cron job → regenerate changed pages → update sitemap `\u003Clastmod>` |\n\n| Static reference content (glossary, guides) | Regenerate on code deploy only |\n\nFor Express SSR, the page is always fresh — no regeneration needed. The cost is latency; mitigate with a CDN in front.\n\nFor ISR (Next.js), trigger on-demand revalidation via the revalidation API when upstream data changes:\n\n```typescript\n\n\u002F\u002F When data changes, invalidate the specific path\n\nawait fetch(`\u002Fapi\u002Frevalidate?secret=TOKEN&path=\u002Fglossary\u002F${slug}`, { method: \"POST\" });\n\n```\n\n### Signals that indicate staleness to Google\n\n- Dates in page content (e.g., \"Updated January 2022\") that are old\n- Prices or rates that no longer match the live source\n\n- Links to pages that now 404\n- Schema `dateModified` older than 12 months for competitive queries\n\n---\n\n## Crawl Budget Management at Scale\n\nCrawl budget is the number of pages Googlebot will crawl on your site per day. For sites with 10k+ URLs it becomes a real constraint — Googlebot will simply stop crawling before it reaches all your pages, and newly added pages may take weeks to be discovered.\n\n### What wastes crawl budget\n\n- **Faceted navigation**: Filter\u002Fsort URLs like `?color=red&size=M` that produce near-duplicate pages\n- **Pagination**: `\u002Fpage\u002F2`,`\u002Fpage\u002F3`... where the same products appear on multiple pages\n\n- **Session IDs \u002F tracking params**: `?sessionid=abc123` creating millions of unique URLs\n- **Internal search results**: `\u002Fsearch?q=anything` — never crawlable, always thin\n\n### Solutions\n\n**Block via `robots.txt`** (prevents crawling, doesn't affect indexation of already-indexed pages):\n\n```text\n\nUser-agent: Googlebot\n\nDisallow: \u002Fsearch\n\nDisallow: \u002F*?sessionid=\n\n```\n\n**`noindex` on parameterized URLs** (crawled but not indexed — use when the URL must exist for users):\n\n```html\n\n\u003Cmeta name=\"robots\" content=\"noindex, follow\" \u002F>\n\n```\n\n**Canonical for near-duplicates** (one sorted\u002Ffiltered variant is canonical; others point to it):\n\n```html\n\n\u003C!-- On \u002Fproducts?sort=price-asc -->\n\n\u003Clink rel=\"canonical\" href=\"https:\u002F\u002Fsite.com\u002Fproducts\" \u002F>\n\n```\n\n**Pagination**: Use `rel=\"next\"`\u002F`rel=\"prev\"` or consolidate paginated content into one long page. Don't noindex paginated pages if they contain unique products not on page 1.\n\n### Diagnosing crawl budget problems\n\nIn Google Search Console → Settings → Crawl stats:\n\n- **Crawled pages\u002Fday declining** → Googlebot is throttling due to slow responses or crawl errors\n- **Response codes: high 404 rate** → fix broken links; they waste crawl budget\n\n- **Crawled but not indexed** rising → thin content or crawl budget exhausted before quality assessment\n\nFor large sites, use separate sitemaps per page type (`sitemap-glossary.xml`,`sitemap-guides.xml`) and prioritize high-value pages in the first sitemap.\n\n---\n\n## AI-Generated Content Policy\n\n### What Google actually detects\n\nGoogle does not need to determine whether content was written by AI or a human. It identifies a **pattern**: low-cost mass production where pages look different on the surface but are essentially repetitive underneath. The signals of this pattern include:\n\n- Many pages with similar titles and angles\n- Smooth, grammatically correct prose with no new information\n\n- Comprehensive coverage that is really just reorganized common knowledge\n- Each page is readable, but after reading it you've learned nothing new\n\n- High page count with no corresponding user engagement or trust signals\n\n**This pattern triggers penalties regardless of authorship.** A human content farm producing the same pattern gets the same treatment. The issue is never \"AI wrote this\" — it is \"this adds nothing.\"\n\n### The correct framing\n\nThe question is not: \"Is it safe to use AI for SEO content?\"\n\nThe question is: **\"Does this page contain enough information gain, search intent match, and trust signals that Google would rank it — regardless of how it was produced?\"**\n\nIf yes, AI is a powerful accelerator. If no, AI just lets you produce worthless pages faster.\n\n### Where AI helps in pSEO\n\n| Use case | Why it works |\n\n|---|---|\n\n| Summarising structured data into readable prose | Each page's data is unique → output is unique |\n\n| Generating FAQ blocks from a data object | Templated but data-driven → not boilerplate |\n\n| Translating + adapting content (with review) | Saves time; review catches errors |\n\n| Writing meta descriptions from page data | Short, formula-driven → low risk |\n\n| Structuring raw data into tables and comparisons | Saves formatting time; data does the heavy lifting |\n\n| Drafting initial content for human review and enrichment | Faster starting point; human adds the information gain |\n\n### Where AI hurts in pSEO\n\n| Anti-pattern | Risk |\n\n|---|---|\n\n| Generic \"overview\" paragraphs with no data | Identical across all pages → thin content |\n\n| AI-expanded boilerplate (\"X is a type of Y that...\") | Detectable by pattern; no unique value |\n\n| Mass-generating content without data variation | Amplifies the thin content problem at scale |\n\n| Fabricating entity-specific facts | Hallucinations become trust\u002Flegal liabilities |\n\n| Using AI to \"rewrite the top 10 results\" for a keyword | Produces content with zero information gain — just reshuffled common knowledge |\n\n| Letting AI make strategic decisions (keyword selection, page type, whether to publish) | AI will confidently produce content for keywords where the user has no chance of ranking |\n\n### The role boundary\n\n**AI is an execution tool, not a strategy tool for SEO.** AI should:\n\n- ✅ Draft content from structured data the user provides\n- ✅ Format, structure, and polish pages\n\n- ✅ Generate meta descriptions, FAQ blocks, schema markup\n- ✅ Help with technical implementation (SSR, sitemaps, caching)\n\nAI should NOT:\n\n- ❌ Decide which keywords to target\n- ❌ Determine whether a page has enough information gain to publish\n\n- ❌ Replace competitive analysis and intent matching\n- ❌ Assess whether the user's site has enough authority to compete\n\n- ❌ Generate \"content\" without underlying data that varies per page\n\nWhen the user asks for \"SEO content,\" the agent's first job is to ensure there is a real data source and strategic rationale — not to start generating pages.\n\n### Practical checklist before publishing AI-assisted content\n\n- [ ] Does each page's AI output differ meaningfully from every other page? (run a diff on 5 random pages)\n- [ ] Is the AI prose grounded in real data from the data source, or is it freestanding prose?\n\n- [ ] Does each page contain at least one data point or insight not found in the current top 10 results?\n- [ ] Could a human reviewer catch factual errors before publish? (build a review step for high-stakes verticals)\n\n- [ ] Would a user who arrived from Google find this page more useful than the search results they came from?\n- [ ] Has the page type been matched to the query intent (not just a blog post by default)?\n\nIf all answers are yes, the content is likely safe. If any is no, rethink the content strategy before scaling.\n\n---\n\n## Performance and Core Web Vitals for SSR Pages\n\npSEO pages are often deprioritized for performance work because they're \"just content pages.\" But Core Web Vitals are a confirmed ranking factor, and a slow pSEO page competes against well-optimized competitors who target the same keyword.\n\n### The three metrics that matter\n\n| Metric | Threshold | Common cause in pSEO |\n\n|---|---|---|\n\n| **LCP** (Largest Contentful Paint) | \u003C 2.5s | Hero image without dimensions\u002Fpreload; render-blocking CSS |\n\n| **CLS** (Cumulative Layout Shift) | \u003C 0.1 | Images without `width`\u002F`height`; fonts causing FOUT |\n\n| **INP** (Interaction to Next Paint) | \u003C 200ms | Large JS bundles blocking the main thread |\n\n### For SSR Express pages specifically\n\n#### Eliminate render-blocking resources\n\n```html\n\n\u003C!-- WRONG: blocks render until stylesheet loads -->\n\n\u003Clink rel=\"stylesheet\" href=\"https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter\" \u002F>\n\n\u003C!-- CORRECT: preconnect + async load -->\n\n\u003Clink rel=\"preconnect\" href=\"https:\u002F\u002Ffonts.gstatic.com\" crossorigin \u002F>\n\n\u003Clink rel=\"preload\" as=\"style\" href=\"https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter&display=swap\" \u002F>\n\n\u003Clink rel=\"stylesheet\" href=\"https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter&display=swap\" media=\"print\" onload=\"this.media='all'\" \u002F>\n\n```\n\n**Inline critical CSS** (the styles needed to render above-the-fold content):\n\n- Inline it in `\u003Cstyle>`tags in`\u003Chead>` — eliminates one round trip\n- Load remaining CSS asynchronously or omit it (pSEO pages rarely need large stylesheets)\n\n**Images must have explicit dimensions** to prevent CLS:\n\n```html\n\n\u003C!-- WRONG: browser doesn't know height → layout shift on load -->\n\n\u003Cimg src=\"${hero}\" alt=\"...\" \u002F>\n\n\u003C!-- CORRECT -->\n\n\u003Cimg src=\"${hero}\" width=\"1200\" height=\"630\" alt=\"...\" loading=\"lazy\" \u002F>\n\n```\n\n**No JavaScript is ideal.** SSR content pages need zero client-side JS. If you must include JS (analytics, interactivity), load it `defer`or`async`.\n\n### Measuring pages not yet in Chrome UX Report\n\nNew pages have no real-user data (CrUX) for 28 days. Use:\n\n- **Lighthouse** (Chrome DevTools or CLI): `lighthouse https:\u002F\u002Fyoursite.com\u002Fglossary\u002Fterm --only-categories=performance`\n- **PageSpeed Insights API**: programmatic scoring for a batch of URLs\n\n- **WebPageTest**: detailed waterfall view to identify bottlenecks\n\nRun Lighthouse on a representative sample of pages (hub, high-volume spoke, low-volume spoke) — don't assume all pages perform equally.\n\n---\n\n## Monitoring and Iteration Loop\n\nShipping pSEO pages is not a one-time event. The standard pattern is: launch → wait 4-8 weeks → analyze → iterate. Most pSEO playbooks fail because teams skip the iteration step.\n\n### What to track in Search Console (per page type)\n\nOpen the **Performance** report, filter by URL prefix for each playbook (`\u002Fglossary\u002F`,`\u002Fguides\u002F`, etc.):\n\n| Signal | Healthy | Problem indicator |\n\n|---|---|---|\n\n| **Impressions growing** | Steady week-over-week increase | Flat after 8 weeks → pages not indexed or no demand |\n\n| **CTR** | >2% for informational, >5% for navigational | Low CTR → title\u002Fdescription not compelling |\n\n| **Average position** | Trending toward \u003C20 | Stuck at 30-50 → content quality or authority issue |\n\n| **Coverage: Crawled, not indexed** | Decreasing | Increasing → thin content signal |\n\n| **Coverage: Excluded (noindex)** | Matches intentional noindex count | Higher than expected → template accidentally sets noindex |\n\n### Decision framework per page set\n\n```text\n\n8 weeks post-launch:\n\n│\n\n├── Indexed AND getting impressions?\n\n│ ├── YES, position \u003C10 → monitor; optimize title\u002Fmeta for CTR\n\n│ ├── YES, position 11-30 → improve content depth, add internal links\n\n│ └── YES, position >30 → thin content; merge with a stronger page or rewrite\n\n│\n\n├── Not indexed (Crawled, not indexed)?\n\n│ ├── Low page count (\u003C100) → submit to Search Console for inspection\n\n│ └── High page count (100+) → thin content; noindex worst pages, improve rest\n\n│\n\n└── Not even crawled?\n\n├── Check sitemap submission\n\n├── Check robots.txt for accidental blocks\n\n└── Check crawl budget — too many thin pages may be crowding out good ones\n\n```\n\n### When to kill a playbook\n\nKill it (noindex + 301 redirect survivors to a hub) when after 6 months:\n\n- Zero pages from the set are in the top 50 for any target keyword, AND\n- Impressions are flat or declining, AND\n\n- The page type is consuming crawl budget (visible in crawl stats)\n\nKeeping dead pages alive harms the rest of the site — Google distributes trust across the whole domain. A smaller set of high-quality pages consistently outperforms a large set of mediocre ones.\n\n### Iteration cadence\n\n| Frequency | Action |\n\n|---|---|\n\n| Weekly | Check indexation coverage for errors |\n\n| Monthly | Review impressions\u002FCTR per playbook; update titles on underperformers |\n\n| Quarterly | Full content audit — merge, improve, or kill underperforming page sets |\n\n| On data change | Regenerate affected pages; update `dateModified` in schema |\n\n---\n\n## Quality Checks\n\n### Pre-Strategy (before writing any code)\n\n- [ ] User has identified unique data source that varies meaningfully per page\n- [ ] Page type matches query intent (blog vs. comparison vs. tool vs. directory)\n\n- [ ] Information gain validated: each page offers something the current top 10 results don't have\n- [ ] Competitive viability assessed: user's site has (or is building) topical authority in this area\n\n- [ ] Starting with a small batch (10-20 pages) before scaling to hundreds\n- [ ] Human has made the strategic decisions; AI is handling execution only\n\n### Pre-Launch (technical and content)\n\n- [ ] `curl` the URL and verify target keywords appear in raw HTML (not rendered by JS)\n- [ ] Each page provides unique value beyond variable substitution — if you removed the entity name, pages would NOT be indistinguishable\n\n- [ ] Information gain test passed: 5 random pages each contain data\u002Finsights not in the current top 10 results\n- [ ] Answers search intent for the target keyword with the correct page type\n\n- [ ] Unique titles and meta descriptions per page\n- [ ] Proper heading structure (one H1, logical H2\u002FH3 hierarchy)\n\n- [ ] Correct schema markup with no validation errors (test at schema.org\u002Fvalidator)\n- [ ] Page speed acceptable — LCP \u003C2.5s, CLS \u003C0.1, no render-blocking resources\n\n- [ ] Images have explicit `width`and`height` attributes\n- [ ] Connected to site architecture (footer\u002Fnav links to hub pages; hub links to spokes)\n\n- [ ] Breadcrumbs render correctly and are not obscured\n- [ ] Logo and branding match the main application exactly\n\n- [ ] In XML sitemap and crawlable (no `noindex` accidentally set)\n- [ ] 404s return proper status codes (no pages for invalid slugs)\n\n- [ ] Cache headers set appropriately per page type (live data: no-cache; static: max-age=86400)\n- [ ] Faceted\u002Ffiltered URLs blocked via `robots.txt`or marked`noindex`\n\n- [ ] Multilingual pages: hreflang tags present, bidirectional, with `x-default`\n- [ ] AI-assisted content: each page's output meaningfully differs from every other page\n\n- [ ] `dateModified` in schema tied to actual data change, not deploy date\n\n### Post-Launch Monitoring\n\nTrack (per playbook URL prefix in Search Console): indexation rate, impressions, average position, CTR\n\n8-week review: assess which page sets are indexed and gaining impressions, which are stuck, which are excluded. Apply the decision framework above.\n\nWatch for: \"Crawled, not indexed\" count rising (thin content), crawl budget errors, manual actions, ranking drops after content updates.\n\n---\n\n## Common Mistakes\n\n### Strategic mistakes (most damaging)\n\n- **Confusing scale with strategy**: Believing \"more pages = more traffic\" without validating that each page has information gain. This is the single most common pSEO failure mode in 2025+.\n- **SEO cosplay**: Pages with perfect technical structure (H1, H2, meta tags, schema) but zero information gain over existing results. Structure is table stakes, not a ranking advantage.\n\n- **No information gain audit**: Publishing pages without checking whether they add anything the current top 10 results don't already have.\n- **Skipping intent matching**: Building blog posts when the query demands a comparison table, or building a product page when the query demands educational content. Wrong page type = won't rank regardless of quality.\n\n- **Ignoring topical authority**: Publishing hundreds of pages in a domain where the site has no track record. Authority is earned through depth and trust signals, not page count.\n- **Letting AI make strategic decisions**: AI generates confidently even when the keyword is unwinnable, the page type is wrong, or the content has no unique value. Human judgment is required for: keyword selection, page type, competitive viability, and publish\u002Fno-publish decisions.\n\n- **Treating AI output as finished content**: AI drafts need human enrichment — original data, case studies, expert judgment, first-hand experience. Raw AI output is a starting point, not a final product.\n\n### Content mistakes\n\n- **Thin content**: Just swapping entity names in identical boilerplate (Google will deindex)\n- **AI prose with no data variation**: All pages share the same generic paragraphs — amplifies thin content at scale. If you removed the entity name, pages would be indistinguishable.\n\n- **Rewriting the top 10 results**: Using AI to rephrase what already ranks is zero information gain. Google doesn't need another version of existing content.\n- **Keyword cannibalization**: Multiple pages targeting the same keyword\n\n- **Over-generation**: Creating pages with no search demand\n- **Poor data quality**: Outdated or incorrect information erodes trust\n\n### Technical mistakes\n\n- **SPA without SSR**: Adding pSEO pages to a React\u002FVue app without server-rendering — Google sees nothing\n- **Orphan pages**: New SEO pages not linked from anywhere in the main site's navigation or footer\n\n- **Inconsistent branding**: SSR pages that look different from the main app break user trust\n- **Breadcrumb obscured by layout tricks**: Negative margin patterns hiding breadcrumb navigation\n\n- **Wrong cache headers**: Live-data pages cached for 24h showing stale rates; static pages uncached causing unnecessary server load\n- **Asset permission errors**: Referencing frontend assets from SSR routes that can't read them\n\n- **Machine-translating pSEO content at scale**: Produces near-duplicate content across locales; triggers spam signals\n- **Missing or asymmetric hreflang**: One page in the set not listing all variants breaks the entire locale cluster\n\n- **Bumping `dateModified` without real content changes**: Deception signal; Google can detect and penalise it\n- **Faceted navigation URLs not blocked**: Filter\u002Fsort param combinations create thousands of near-duplicate crawlable URLs, wasting crawl budget\n\n- **No crawl budget monitoring**: Teams discover Googlebot stopped crawling new pages only after rankings plateau\n- **Skipping Core Web Vitals on pSEO pages**: Slow LCP or high CLS on \"just content\" pages loses rankings to faster competitors\n\n- **Images without dimensions**: Causes CLS on SSR pages (browser doesn't know reserved height until image loads)\n\n### Process mistakes\n\n- **Blasting hundreds of pages at once**: Instead of starting with 10-20 pages, validating indexation and impressions, then scaling what works\n- **No iteration loop**: Shipping pSEO and never reviewing Search Console — dead pages accumulate and drag down domain trust\n\n- **No freshness strategy for live-data pages**: Exchange rates or prices cached for 24h showing stale data destroys credibility\n- **Ignoring UX**: Pages that exist for Google but not for users — no conversion path, no value to visitors\n\n---\n\n## Output Format\n\nDeliver strategy validation first, then implementation. **Do not skip straight to building pages.**\n\n1. **Strategic validation** (before any code):\n\n- What unique data does the user have that varies per page?\n- What page type matches the query intent?\n\n- What information gain does each page offer over current top 10 results?\n- Does the user's site have topical authority in this area?\n\n- Recommended initial batch size (start small, validate, then scale)\n\n1. **Rendering audit**: Confirm whether the app is a SPA and what SSR approach to use\n2. **Strategy**: Opportunity analysis, chosen playbook(s), keyword patterns, data sources, page count estimate\n\n3. **Shared infrastructure**: `ssrShared.ts` (or equivalent) HTML shell before any individual pages\n4. **Template**: URL structure, title\u002Fmeta templates, content outline, schema markup\n\n5. **Implementation**: Working server-rendered pages that return full HTML to `curl`\n6. **Integration**: Footer\u002Fnav updates in the main app linking to the new hub pages\n\n7. **Validation plan**: How to verify pages are indexed, earning impressions, and when to scale or kill the campaign\n\n## Limitations\n\n- Cannot access Search Console data to monitor indexation\n- Cannot check existing backlink profiles\n\n- Data quality depends on the source — always validate before publishing\n- Cannot guarantee rankings — SEO involves many factors beyond on-page optimization\n","# Programmatic SEO\n\n## OpenClawd Operator Adaptation\n\nRun this skill as part of the OpenClawd operator deck. Preserve the skill-specific workflow below, but frame outputs for Solana-native agents when relevant: prefer OpenClawd language, note whether the work can support autonomous agent operations, and keep financial, legal, tax, hiring, medical, or other regulated outputs informational unless the skill already requires a stricter disclaimer. Use the Llobster Legend persona only as light operator framing; do not let branding override accuracy, safety, or the user's stated domain.\n\n\nBuild SEO-optimized pages at scale using templates and data. Create page generators that target keyword patterns and produce unique, valuable content for each variation.\n\n## When to Use\n\n- User wants to create many SEO-driven pages from a template (e.g., \"[product] vs [competitor]\", \"[service] in [city]\")\n- User mentions programmatic SEO, template pages, directory pages, location pages, or comparison pages at scale\n\n- User wants to build an \"alternatives to X\" page set, integrations directory, or glossary\n- User has a data set they want to turn into individual landing pages\n\n## When NOT to Use\n\n- Auditing existing SEO issues (use seo-auditor skill)\n- Writing a single blog post or landing page (use content-machine skill)\n\n- One-off competitive analysis (use competitive-analysis skill)\n\n## Core Principles\n\n1. **Information gain is everything** — Every page must contain information the user cannot find on existing top-10 results. Proper H1s, keyword density, and clean structure are baseline hygiene, not a ranking advantage. Pages that \"look like SEO\" but add no new information are what Google's spam systems now target.\n2. **Unique value per page** — Every page must provide value specific to that page, not just swapped variables in a template. If you removed the entity name, would two pages be indistinguishable? If yes, don't publish.\n\n3. **Proprietary data wins** — Hierarchy: proprietary > product-derived > user-generated > licensed > public (weakest). The strongest pSEO pages contain data no one else has — original tests, first-party metrics, real user reviews, proprietary calculations.\n4. **Subfolders, not subdomains** — `yoursite.com\u002Ftemplates\u002Fresume\u002F`not`templates.yoursite.com\u002Fresume\u002F`\n\n5. **Match search intent precisely** — Pages must match the intent behind the query, not just contain the keywords. This means choosing the right page type (blog post vs. comparison table vs. tool vs. directory listing), answering the actual question, and structuring content the way users expect for that query type.\n6. **Quality over quantity** — 100 great pages beat 10,000 thin ones. Scale without information gain is just industrialized noise. Google has more content than it needs — your pages must earn their place by being genuinely better than what already ranks.\n\n7. **Topical authority compounds** — A site that demonstrates deep expertise in a specific topic earns trust signals that lift all pages in that topic cluster. Scattered, shallow coverage across unrelated topics builds no authority.\n\n---\n\n## ⚠️ CRITICAL: Check the App's Rendering Strategy First\n\n**Before writing a single line of code**, determine whether the existing application is a Single Page Application (SPA).\n\n**SPAs (React, Vue, Angular, Svelte) are invisible to Googlebot.** Googlebot fetches raw HTML and does not execute client-side JavaScript. A React component that renders `\u003Ch1>Currency Converter\u003C\u002Fh1>`only works in a browser — Googlebot sees an empty`\u003Cdiv id=\"root\">\u003C\u002Fdiv>`.\n\n### Decision Tree\n\n```text\n\nIs the app a SPA (React\u002FVue\u002FAngular)?\n\n│\n\n├── YES → SEO pages MUST be server-rendered (SSR)\n\n│ Options:\n\n│ A. Express\u002FFastify route returning a complete HTML string ← simplest for existing SPAs\n\n│ B. Migrate to Next.js\u002FNuxt\u002FSvelteKit with SSR support\n\n│ C. Add a static site generator (Astro) alongside the SPA for SEO pages only\n\n│\n\n└── NO (already Next.js, Nuxt, etc.) → Use the framework's built-in SSR\u002FSSG\u002FISR patterns (see Step 6)\n\n```\n\n**The SPA trap:** The most common pSEO mistake is adding routes to a React Router \u002F Wouter \u002F Vue Router app and assuming they will be indexed. They will not. Always verify by `curl`-ing the URL and checking if the content is present in the raw HTML response:\n\n```bash\n\ncurl -s https:\u002F\u002Fyoursite.com\u002Fyour-seo-page | grep \"target keyword\"\n\n# If empty or only returns \u003Cdiv id=\"root\">\u003C\u002Fdiv> → not crawlable\n\n```\n\n---\n\n## Content Authenticity — Don't Hallucinate Business Data\n\nWhen building programmatic SEO for **the user's own company**, you will not have access to their internal data (customer stories, case studies, testimonials, product metrics, pricing, team bios, etc.). **Do not fabricate this information.**\n\n### Before generating any company-specific content, ask the user for\n\n- Customer names, logos, or testimonials they want featured\n- Case study data (metrics, outcomes, quotes)\n\n- Product-specific details (features, pricing tiers, integrations list)\n- Any proprietary data that should populate template variables\n\n#### If the user hasn't provided this data, default to safe content patterns\n\n- Industry research and statistics (sourced via `webSearch`)\n- General descriptions of the problem\u002Fsolution category\n\n- Feature explanations based on what's publicly visible on their site (use `webFetch` on their domain)\n- Placeholder blocks clearly marked `[INSERT: customer testimonial]`or`[INSERT: case study metrics]`\n\n- Comparison data pulled from public sources (G2, Capterra reviews via `webSearch`)\n\n**Never generate:** fake customer quotes, fabricated ROI numbers, invented case studies, made-up testimonials, or fictional company metrics. These damage trust and can create legal liability.\n\nFor **generic\u002Fresearch topics** (e.g., \"[city] cost of living\", \"[tool A] vs [tool B]\", glossary terms), use `webSearch` to gather real data and cite sources.\n\n---\n\n## ⚠️ Strategic Judgment — What AI Cannot Do For You\n\n**This is the most important section in this skill.** AI excels at scaling execution — drafting content, structuring pages, generating variations. But it cannot make the strategic decisions that determine whether a pSEO campaign succeeds or fails. These decisions must come from the user (or a human SEO strategist), and the agent must actively prompt for them rather than making assumptions.\n\n### Decisions that require human judgment\n\nBefore building anything, the user must answer (or the agent must ask):\n\n1. **Is this keyword worth a page at all?** Not every keyword with search volume deserves a page. If the top 10 results are dominated by high-authority brands and the user's site has no topical authority, building 500 pages won't help.\n2. **What page type matches the query intent?** The same topic might need a blog post, a comparison table, an interactive tool, a directory listing, or a data profile. Getting the page type wrong means the page will never rank, regardless of content quality. For example:\n\n- \"best CRM for real estate\" → listicle\u002Fcomparison (not a product page)\n- \"HubSpot vs Salesforce\" → head-to-head comparison (not a blog post)\n\n- \"what is a CRM\" → educational\u002Fglossary (not a product page)\n- \"CRM pricing\" → pricing table with real numbers (not a blog post about pricing)\n\n1. **What information gain does this page offer over the current top 10?** If the answer is \"nothing — we're just rewriting what's already there with AI,\" do not build the page. Specifically ask: do we have original data, unique analysis, proprietary metrics, real case studies, or first-hand experience that the current results lack?\n2. **Does the user's site have topical authority in this area?** A brand-new domain publishing 200 glossary pages on a topic it has no track record in will be ignored. Topical authority is built through depth (many related, high-quality pages), external trust signals (backlinks from relevant sites), and user engagement over time.\n\n3. **What is the commercial intent and conversion path?** Pages that attract traffic but have no clear next step for the user waste crawl budget and dilute site quality. Every pSEO page should have a purpose beyond \"get impressions.\"\n\n### What the agent should do\n\n- **Always ask the user** what unique data, experience, or perspective they can bring to the topic before generating content. If they say \"just write something about X,\" push back and explain that pages without information gain will not rank.\n- **Never assume scale equals strategy.** If the user asks for \"500 SEO articles,\" the correct response is to first validate whether 500 pages is the right number, whether the topics have demand, and whether the user has enough unique data to make each page valuable.\n\n- **Recommend starting small.** Build 10-20 high-quality pages first, validate they get indexed and earn impressions, then scale what works. This is the opposite of the \"blast 500 pages and hope\" approach.\n- **Be explicit about what AI is doing vs. what requires human input.** AI writes the page. The human decides whether the page should exist.\n\n### The \"SEO cosplay\" trap\n\nA page can have perfect H1 tags, clean H2\u002FH3 hierarchy, optimized meta descriptions, proper schema markup, good keyword density, and fast load times — and still rank nowhere. These are table stakes, not differentiators. Google's ranking systems evaluate whether a page genuinely satisfies the user's query better than alternatives. Structure without substance is what practitioners call \"SEO cosplay\" — it looks like SEO but doesn't perform.\n\n**The agent must not conflate technical SEO hygiene with content quality.** Both are necessary. Neither is sufficient alone.\n\n---\n\n## Information Gain — The Core Quality Signal\n\nGoogle's systems increasingly evaluate \"information gain\" — whether a page adds something new to the corpus of existing results for a query. This is the single most important concept in modern pSEO.\n\n### What counts as information gain\n\n| Source of gain | Example | Strength |\n\n|---|---|---|\n\n| **Original data \u002F metrics** | Your own A\u002FB test results, proprietary benchmarks, internal analytics | Strongest — impossible to replicate |\n\n| **First-hand experience** | Actual product reviews you conducted, real case studies with named clients | Very strong — hard to fake |\n\n| **Unique analysis** | Novel comparisons, calculated scores, derived insights from raw data | Strong — requires expertise |\n\n| **Curated judgment** | Expert picks, opinionated rankings with reasoning, \"here's what we'd actually use\" | Moderate — requires credibility |\n\n| **Structured aggregation** | Data from multiple sources combined into a single useful view (with attribution) | Moderate — useful but reproducible |\n\n| **Rewritten common knowledge** | The same information available on 50 other sites, just rephrased | Zero — this is what gets penalized |\n\n### The information gain test\n\nBefore publishing any pSEO page set, run this test on 5 random pages:\n\n1. Search Google for the target keyword\n2. Read the top 3 results\n\n3. Read your generated page\n4. Ask: **\"Does our page contain at least one piece of information, data point, or insight that none of the top 3 results have?\"**\n\n5. If no → do not publish. Improve the data source or reduce the page set to only pages where you have genuine information gain.\n\n### Scaled content abuse (Google's 2024+ spam policy)\n\nGoogle now explicitly targets \"scaled content abuse\" — content produced at scale (whether by AI, humans, or automation) that exists primarily to manipulate rankings rather than help users. The pattern Google detects is:\n\n- Many pages with similar structure\n- Smooth, readable prose with no new information\n\n- Comprehensive coverage that is really just reorganized common knowledge\n- High page count with no corresponding trust signals or user engagement\n\n- Each page is readable, but after reading it you've learned nothing new\n\n**This pattern triggers penalties regardless of whether AI wrote the content.** A human content farm producing the same pattern gets the same treatment. The issue is not AI — it is the absence of value at scale.\n\n---\n\n## Proven Playbooks (Real Traffic Numbers)\n\n| Playbook | URL pattern | Who does it | Scale |\n\n|---|---|---|---|\n\n| **Integrations** | `\u002Fapps\u002F[A]\u002Fintegrations\u002F[B]` | **Zapier** — ~56k pages, 5.8M+ monthly organic visits, ranks for 1.3M keywords. Proprietary data (triggers\u002Ftemplates per app pair) no one else can replicate. | N² combinations |\n\n| **Conversions** | `\u002Fcurrency-converter\u002F[from]-to-[to]-rate` | **Wise** — 8.5M pages across locale subfolders, 60M+ monthly visits. Live exchange-rate data + fee calculators = unique value per page. | N² × locales |\n\n| **Locations** | `\u002FRestaurants-[city]`,`\u002F[cuisine]-Restaurants-[city]`,`\u002FRestaurants-[neighborhood]` | **Tripadvisor** — 700M+ pages, 226M+ monthly visits. UGC reviews keep pages fresh; layered matrix (city × cuisine × neighborhood). | city × category × modifier |\n\n| **Data profiles** | `\u002F[city-slug]` | **Nomad List** — cost-of-living, internet speed, safety scores per city. Pages are pure data tables — minimal prose, high value. | N entities |\n\n| **Comparisons** | `\u002F[A]-vs-[B]`,`\u002Falternatives\u002F[A]` | **G2, Capterra** — \"vs\" pages + \"alternatives\" pages, populated by user reviews. | N² \u002F 2 |\n\n| **Templates** | `\u002Ftemplates\u002F[type]` | **Canva, Notion** — each template is a landing page. | N types |\n\n| **Glossary** | `\u002Flearn\u002F[term]` | **Ahrefs, HubSpot** — definition pages cluster topical authority. | N terms |\n\n| **How-to guides** | `\u002Fguides\u002F[task]-with-[tool]` | Documentation sites — step-by-step guides, HowTo schema | N tasks × M tools |\n\n| **Personas** | `\u002F[product]-for-[audience]` | \"CRM for real estate agents\" | N × M |\n\n**The test:** If your data doesn't meaningfully change between page variations, don't build it. Zapier works because Slack+Asana genuinely differs from Slack+Trello. \"Plumber in Austin\" vs \"Plumber in Dallas\" with identical boilerplate = thin content penalty.\n\nLayer playbooks for long-tail: Tripadvisor's \"Best Italian Restaurants in Chinatown NYC\" = curation × cuisine × neighborhood.\n\n### Why these playbooks work — and why copycats fail\n\nEvery successful pSEO example above shares one trait: **the data genuinely changes between pages.** Zapier's Slack+Asana page has different triggers, different actions, and different templates than Slack+Trello. Wise's USD-to-EUR page has a different exchange rate, different fee structure, and different historical chart than USD-to-GBP. Tripadvisor's pages have different restaurants, different reviews, and different ratings per city.\n\nCopycats fail because they replicate the URL structure without replicating the information gain. Creating 500 \"\u002Fservice-in-city\" pages where only the city name changes and the rest is identical prose is not programmatic SEO — it is spam at scale. Google's systems detect this pattern reliably: many pages, similar structure, no meaningful data variation.\n\n**Before choosing a playbook, ask:** \"Do I have genuinely different data for each page variation, or am I just swapping one variable into the same template?\" If the latter, reduce the page count to only variations where you have real data, or choose a different playbook entirely.\n\n---\n\n## Implementation\n\n### Step 1: Keyword Pattern Research\n\n- Identify the repeating structure and variables\n- Count how many unique combinations exist\n\n- Validate demand: aggregate search volume, distribution (head vs. long tail), trend direction\n\n### Step 2: Data Requirements\n\n- What data populates each page?\n- Is it first-party, scraped, licensed, or public?\n\n- How is it updated and maintained?\n\n### Step 3: Template Design\n\n#### Page structure\n\n- H1 with target keyword\n- Unique intro (not just variables swapped — conditional content based on data)\n\n- Data-driven sections with original insights\u002Fanalysis per page\n- Related pages \u002F internal links\n\n- CTAs appropriate to intent\n\n##### Ensuring uniqueness — critical to avoid thin content penalties\n\n- Conditional content blocks that vary based on data attributes\n- Calculated or derived data (not just raw display)\n\n- Editorial commentary unique to each entity\n- User-generated content where possible\n\n### Step 4: Internal Linking Architecture\n\n#### Hub and spoke model\n\n- Hub: Main category page (e.g., \"\u002Fintegrations\u002F\")\n- Spokes: Individual programmatic pages (e.g., \"\u002Fintegrations\u002Fslack-asana\u002F\")\n\n- Cross-links between related spokes\n\nEvery page must be reachable from the main site. **Update the main app's footer and navigation to include links to SEO hub pages** — SEO pages that aren't linked from the main site are orphan pages that Google may never discover or trust.\n\nInclude XML sitemap and breadcrumbs with structured data.\n\n### Step 5: Indexation Strategy\n\n- Prioritize high-volume patterns for initial crawling\n- Noindex very thin variations rather than publishing them\n\n- Manage crawl budget (separate sitemaps by page type)\n- Monitor indexation rate in Search Console\n\n### Step 6: Build the Page Generator\n\n#### Rendering strategy decision\n\n| Page count | Data freshness | Strategy |\n\n|---|---|---|\n\n| \u003C1,000 | Rarely changes | **SSG** — pre-render everything at build |\n\n| 1,000-100,000 | Changes daily\u002Fweekly | **ISR** — pre-render popular subset, generate rest on-demand + cache |\n\n| 100,000+ or live data | Real-time (prices, rates) | **ISR with short revalidate** or SSR |\n\nSSG is fastest but build time scales linearly — 50k pages can mean 30+ min builds. ISR is the pSEO sweet spot: instant deploys, pages generate on first request then cache.\n\n#### For SPAs: Express SSR pattern\n\nWhen adding pSEO to an existing SPA, the simplest approach is adding Express routes that return complete HTML strings. Organize into three layers:\n\n##### 1. Shared HTML shell (create this first)\n\n```typescript\n\n\u002F\u002F server\u002FssrShared.ts — create before writing any individual page\n\nexport function ssrHtmlShell({ title, description, canonical, schemaJson, css, body, ...}): string {\n\nreturn `\u003C!DOCTYPE html>\n\n\u003Chtml lang=\"...\">\n\n\u003Chead>\n\n\u003Cmeta charset=\"UTF-8\" \u002F>\n\n\u003Ctitle>${title}\u003C\u002Ftitle>\n\n\u003Cmeta name=\"description\" content=\"${description}\" \u002F>\n\n\u003Clink rel=\"canonical\" href=\"${canonical}\" \u002F>\n\n\u003C!-- OG tags, fonts, schema -->\n\n\u003Cstyle>${sharedCss()}${css ?? \"\"}\u003C\u002Fstyle>\n\n\u003C\u002Fhead>\n\n\u003Cbody>\n\n${header()}\n\n${body}\n\n${footer()}\n\n\u003C\u002Fbody>\n\n\u003C\u002Fhtml>`;\n\n}\n\n```\n\nCreate this shared shell **before** writing any individual page. Every new SEO page reuses it. This ensures consistent branding (header, footer, fonts, base CSS) across all SSR pages without duplication.\n\n###### 2. Data + page generator modules (one per playbook)\n\n```typescript\n\n\u002F\u002F server\u002Fglossary.ts\n\nexport const TERMS: GlossaryTerm[] = [ \u002F* structured data *\u002F ];\n\nexport function getTermHtml(slug: string, logoBase64: string): string | null { ... }\n\nexport function getTermIndexHtml(logoBase64: string): string { ... }\n\n```\n\nKeep data as typed arrays\u002Fobjects in the same file as the generator. This makes content easy to update without touching routing logic.\n\n###### 3. Routes (thin, just wiring)\n\n```typescript\n\n\u002F\u002F in routes.ts\n\napp.get(\"\u002Fglossary\u002F:slug\", (req, res) => {\n\nconst html = getTermHtml(req.params.slug, LOGO_BASE64);\n\nif (!html) { res.status(404).end(); return; }\n\nres.setHeader(\"Cache-Control\", \"public, max-age=86400\");\n\nres.setHeader(\"Content-Type\", \"text\u002Fhtml; charset=utf-8\");\n\nres.send(html);\n\n});\n\n```\n\n#### Cache headers per page type\n\nSet cache headers based on data freshness — not one-size-fits-all:\n\n| Page type | Recommended header | Reason |\n\n|---|---|---|\n\n| Static content (glossary, guides) | `public, max-age=86400` | Content rarely changes; CDN can serve |\n\n| Live data (exchange rates, prices) | `no-cache`or`s-maxage=60` | Must be fresh; stale data damages credibility |\n\n| Semi-dynamic (weekly updates) | `public, s-maxage=3600, stale-while-revalidate=86400` | Balance freshness vs. load |\n\n#### For Next.js App Router\n\n```tsx\n\nexport async function generateStaticParams() {\n\nconst popular = await db.query('SELECT slug FROM entities ORDER BY search_volume DESC LIMIT 500');\n\nreturn popular.map(e => ({ slug: e.slug }));\n\n}\n\nexport const dynamicParams = true;\n\nexport const revalidate = 3600;\n\nexport async function generateMetadata({ params }) {\n\nconst { slug } = await params;\n\nconst entity = await getEntity(slug);\n\nreturn {\n\ntitle: `${entity.name} — ${entity.category} | Brand`,\n\ndescription: entity.summary,\n\nalternates: { canonical: `https:\u002F\u002Fsite.com\u002F${entity.category}\u002F${slug}` },\n\n};\n\n}\n\nexport default async function Page({ params }) {\n\nconst { slug } = await params;\n\nconst entity = await getEntity(slug);\n\nif (!entity) notFound();\n\n}\n\n```\n\n**Critical ISR rules:** `generateStaticParams`is NOT re-run on revalidation. Must return an array (even`[]`) or the route becomes fully dynamic. Set`dynamicParams = false` only if you want 404s for anything not pre-generated.\n\n#### Astro alternative\n\nBetter for content-heavy, less-interactive pages. Ships zero JS by default — better Core Web Vitals.\n\n```js\n\nexport async function getStaticPaths() {\n\nconst entities = await loadEntities();\n\nreturn entities.map(e => ({ params: { slug: e.slug }, props: { entity: e } }));\n\n}\n\n```\n\nNo native ISR; use on-demand rendering + `Cache-Control: s-maxage=3600, stale-while-revalidate`.\n\n#### Sitemaps at scale\n\nGoogle's limit is 50,000 URLs per sitemap file. Shard into `sitemap-1.xml`,`sitemap-2.xml`... referenced by a sitemap index. For ISR\u002FSSR sites, generate sitemaps server-side from the DB, not at build time. **Warning:** Google will NOT index all pages immediately — indexation at scale takes weeks\u002Fmonths. Prioritize high-volume slugs in the first sitemap.\n\n---\n\n## SSR-Specific Implementation Notes\n\n### Asset handling in SSR\n\nFrontend assets (images, fonts) processed by Vite\u002Fwebpack\u002Fesbuild are **not** directly accessible to server-side routes. Common problems:\n\n- Images imported with `import logo from \"@assets\u002Flogo.png\"` work in React but not in Express route handlers\n- Files copied to `public\u002F` by the build tool may not be served correctly in development\n\n- Files with restricted permissions (`rw-------`) will throw EACCES errors when read from disk\n\n#### Solutions by asset type\n\n| Asset | Recommended approach |\n\n|---|---|\n\n| Logo \u002F brand images | Base64-encode at server startup; embed inline in `\u003Cimg src=\"data:...\">` |\n\n| Small icons | Inline SVG string in the HTML template |\n\n| External fonts | Google Fonts CDN link in `\u003Chead>` |\n\n| Background images | Use CSS gradients or CDN URLs |\n\n```typescript\n\n\u002F\u002F Base64 encode logo once at startup — safe for all SSR pages\n\nimport fs from \"fs\";\n\nconst logoBuffer = fs.readFileSync(\".\u002Fattached_assets\u002Flogo.png\");\n\nconst LOGO_BASE64 = `data:image\u002Fpng;base64,${logoBuffer.toString(\"base64\")}`;\n\n```\n\n### Header\u002Ffooter consistency\n\nSSR pages and the React\u002FVue\u002FSPA app will share the same domain. Users will navigate between them. **Brand consistency is critical** — a mismatch between the main app's header and the SSR page's header breaks trust.\n\nSteps:\n\n1. Study the main app's header\u002Ffooter colors, logo treatment, link structure, and typography\n2. Replicate them in the shared `ssrShared.ts` shell functions — not approximations, pixel-for-pixel matches\n\n3. When the main app's footer is updated (new links, new columns), update the SSR footer function too\n4. Conversely, when new SSR hub pages are added (e.g., `\u002Fglossary`,`\u002Fguides`), add them to the main app's footer navigation\n\n### Logo rendering in SSR\n\nIf the logo image has a non-standard aspect ratio or significant whitespace, a plain `height: 48px` will render it incorrectly. Inspect how the main React app clips and positions the logo, then replicate exactly:\n\n```html\n\n\u003C!-- If the main app uses overflow-hidden clipping to show only part of the image: -->\n\n\u003Cdiv style=\"height:56px; width:160px; overflow:hidden; display:flex; align-items:center; justify-content:center;\">\n\n\u003Cimg src=\"${LOGO_BASE64}\" style=\"width:auto; height:250%; object-fit:contain; margin-top:-5%;\" \u002F>\n\n\u003C\u002Fdiv>\n\n```\n\nDon't guess — read the main app's logo component before writing the SSR equivalent.\n\n### Breadcrumb placement and negative margins\n\nA common hero design pattern uses negative `margin-top` on the content section to create a \"card floating up into the hero\" visual effect:\n\n```css\n\n.hero { padding-bottom: 72px; }\n\n.main { margin-top: -32px; } \u002F* pulls first card up into hero *\u002F\n\n```\n\n**This breaks breadcrumbs.** If a breadcrumb element sits between the hero and `.main`in the HTML, the negative margin on`.main` will pull the main content over the breadcrumb, hiding it.\n\n**Rule: breadcrumbs must always be the first child inside `.main`**, never between`.main` and the preceding section.\n\n```html\n\n\u003C!-- WRONG: breadcrumb between hero and main -->\n\n\u003Cdiv class=\"hero\">...\u003C\u002Fdiv>\n\n\u003Cnav class=\"breadcrumb\">...\u003C\u002Fnav> \u003C!-- will be covered by .main -->\n\n\u003Cdiv class=\"main\">...\u003C\u002Fdiv>\n\n\u003C!-- CORRECT: breadcrumb inside main -->\n\n\u003Cdiv class=\"hero\">...\u003C\u002Fdiv>\n\n\u003Cdiv class=\"main\">\n\n\u003Cnav class=\"breadcrumb\">...\u003C\u002Fnav> \u003C!-- safely in the content flow -->\n\n\u003Cdiv class=\"card\">...\u003C\u002Fdiv>\n\n\u003C\u002Fdiv>\n\n```\n\nAdditionally, if a page has a breadcrumb and the hero uses large `padding-bottom` (designed to pair with negative margin), that padding becomes wasted dark space. Override it on breadcrumb pages:\n\n```html\n\n\u003Cdiv class=\"hero\" style=\"padding-bottom: 32px;\">\n\n```\n\n---\n\n## Schema Markup by Playbook\n\nMatch schema type to content type — don't use a generic WebPage schema when a more specific type exists:\n\n| Playbook | Schema type | Key properties |\n\n|---|---|---|\n\n| Glossary \u002F definitions | `DefinedTerm`+`DefinedTermSet`|`name`,`description`,`inDefinedTermSet` |\n\n| How-to guides | `HowTo`|`step[]`with`HowToStep`,`tool`,`supply` |\n\n| FAQ sections | `FAQPage`|`mainEntity[]`with`Question`+`Answer` |\n\n| Comparisons | `ItemList`or`Review`|`itemListElement[]`,`ratingValue` |\n\n| Data profiles | `Dataset`or`Place`|`name`,`description`,`spatialCoverage` |\n\n| Recipes\u002Ftemplates | `CreativeWork`|`name`,`description`,`genre` |\n\nMultiple schema types can appear on the same page (e.g., a HowTo guide can also have a FAQPage block at the bottom).\n\n---\n\n## Internationalization and Locale Handling\n\nOnly add multilingual pSEO when you have **genuinely translated data** — not machine-translated boilerplate. Machine-translating 10,000 thin pages at once is one of the fastest ways to trigger a spam manual action.\n\n### URL structure — subfolders win\n\n| Approach | Example | SEO verdict |\n\n|---|---|---|\n\n| Subfolder | `yoursite.com\u002Fes\u002Fglosario\u002Fpresupuesto` | **Preferred** — consolidates domain authority |\n\n| ccTLD | `yoursite.es\u002Fglosario\u002Fpresupuesto` | Strong signal but costly to maintain |\n\n| Subdomain | `es.yoursite.com\u002F...` | Treated as separate site; avoid for pSEO |\n\n| Query param | `yoursite.com\u002Fglossary?lang=es` | Not crawlable reliably; never use |\n\n### hreflang implementation\n\nEvery page that has a locale variant must declare all variants (including `x-default`) in`\u003Chead>`:\n\n```html\n\n\u003Clink rel=\"alternate\" hreflang=\"en\" href=\"https:\u002F\u002Fsite.com\u002Fglossary\u002Fbudget\" \u002F>\n\n\u003Clink rel=\"alternate\" hreflang=\"es\" href=\"https:\u002F\u002Fsite.com\u002Fes\u002Fglosario\u002Fpresupuesto\" \u002F>\n\n\u003Clink rel=\"alternate\" hreflang=\"x-default\" href=\"https:\u002F\u002Fsite.com\u002Fglossary\u002Fbudget\" \u002F>\n\n```\n\nRules:\n\n- Every page in the set must list **all** pages in the set (bidirectional)\n- Omitting a language from even one page breaks the cluster for Google\n\n- `x-default` should point to the most general version (usually English or a language-selector page)\n- Validate with Google Search Console → Enhancements → International targeting\n\n### Data structure for multilingual pages\n\nStore translations as a map keyed by locale so the generator stays clean:\n\n```typescript\n\nconst TERM = {\n\nslug: { en: \"budget\", es: \"presupuesto\" },\n\nname: { en: \"Budget\", es: \"Presupuesto\" },\n\ndefinition: { en: \"...\", es: \"...\" },\n\n};\n\nfunction getTermHtml(slug: string, locale: \"en\" | \"es\"): string { ... }\n\n```\n\n### Machine-translation risk\n\nMachine-translated prose is detectable by Google and often results in near-duplicate content across locales. Only translate if:\n\n- A human reviews\u002Fedits the output, OR\n- The page is primarily structured data (tables, numbers, steps) with minimal prose\n\n---\n\n## Content Freshness Signals\n\nGoogle rewards pages that are genuinely kept up to date. Stale pSEO pages — especially data-driven ones — gradually lose rankings as fresher competitors appear.\n\n### `dateModified` in schema\n\nEvery page with structured data should carry a timestamp:\n\n```json\n\n{\n\n\"@type\": \"WebPage\",\n\n\"datePublished\": \"2024-01-15\",\n\n\"dateModified\": \"2025-03-01\"\n\n}\n\n```\n\n**Only update `dateModified`when content actually changes.** Bumping it on a schedule without real changes is a deception signal that Google penalises. If you auto-regenerate pages, tie`dateModified`to the data source's`updatedAt`, not the deploy timestamp.\n\n### When and how to regenerate\n\n| Data type | Trigger strategy |\n\n|---|---|\n\n| Exchange rates \u002F prices | SSR with short cache (`s-maxage=60`); no static generation |\n\n| Product\u002Fcompany data | Webhook from data source on change → re-render and invalidate CDN cache |\n\n| Weekly-updated datasets | Nightly cron job → regenerate changed pages → update sitemap `\u003Clastmod>` |\n\n| Static reference content (glossary, guides) | Regenerate on code deploy only |\n\nFor Express SSR, the page is always fresh — no regeneration needed. The cost is latency; mitigate with a CDN in front.\n\nFor ISR (Next.js), trigger on-demand revalidation via the revalidation API when upstream data changes:\n\n```typescript\n\n\u002F\u002F When data changes, invalidate the specific path\n\nawait fetch(`\u002Fapi\u002Frevalidate?secret=TOKEN&path=\u002Fglossary\u002F${slug}`, { method: \"POST\" });\n\n```\n\n### Signals that indicate staleness to Google\n\n- Dates in page content (e.g., \"Updated January 2022\") that are old\n- Prices or rates that no longer match the live source\n\n- Links to pages that now 404\n- Schema `dateModified` older than 12 months for competitive queries\n\n---\n\n## Crawl Budget Management at Scale\n\nCrawl budget is the number of pages Googlebot will crawl on your site per day. For sites with 10k+ URLs it becomes a real constraint — Googlebot will simply stop crawling before it reaches all your pages, and newly added pages may take weeks to be discovered.\n\n### What wastes crawl budget\n\n- **Faceted navigation**: Filter\u002Fsort URLs like `?color=red&size=M` that produce near-duplicate pages\n- **Pagination**: `\u002Fpage\u002F2`,`\u002Fpage\u002F3`... where the same products appear on multiple pages\n\n- **Session IDs \u002F tracking params**: `?sessionid=abc123` creating millions of unique URLs\n- **Internal search results**: `\u002Fsearch?q=anything` — never crawlable, always thin\n\n### Solutions\n\n**Block via `robots.txt`** (prevents crawling, doesn't affect indexation of already-indexed pages):\n\n```text\n\nUser-agent: Googlebot\n\nDisallow: \u002Fsearch\n\nDisallow: \u002F*?sessionid=\n\n```\n\n**`noindex` on parameterized URLs** (crawled but not indexed — use when the URL must exist for users):\n\n```html\n\n\u003Cmeta name=\"robots\" content=\"noindex, follow\" \u002F>\n\n```\n\n**Canonical for near-duplicates** (one sorted\u002Ffiltered variant is canonical; others point to it):\n\n```html\n\n\u003C!-- On \u002Fproducts?sort=price-asc -->\n\n\u003Clink rel=\"canonical\" href=\"https:\u002F\u002Fsite.com\u002Fproducts\" \u002F>\n\n```\n\n**Pagination**: Use `rel=\"next\"`\u002F`rel=\"prev\"` or consolidate paginated content into one long page. Don't noindex paginated pages if they contain unique products not on page 1.\n\n### Diagnosing crawl budget problems\n\nIn Google Search Console → Settings → Crawl stats:\n\n- **Crawled pages\u002Fday declining** → Googlebot is throttling due to slow responses or crawl errors\n- **Response codes: high 404 rate** → fix broken links; they waste crawl budget\n\n- **Crawled but not indexed** rising → thin content or crawl budget exhausted before quality assessment\n\nFor large sites, use separate sitemaps per page type (`sitemap-glossary.xml`,`sitemap-guides.xml`) and prioritize high-value pages in the first sitemap.\n\n---\n\n## AI-Generated Content Policy\n\n### What Google actually detects\n\nGoogle does not need to determine whether content was written by AI or a human. It identifies a **pattern**: low-cost mass production where pages look different on the surface but are essentially repetitive underneath. The signals of this pattern include:\n\n- Many pages with similar titles and angles\n- Smooth, grammatically correct prose with no new information\n\n- Comprehensive coverage that is really just reorganized common knowledge\n- Each page is readable, but after reading it you've learned nothing new\n\n- High page count with no corresponding user engagement or trust signals\n\n**This pattern triggers penalties regardless of authorship.** A human content farm producing the same pattern gets the same treatment. The issue is never \"AI wrote this\" — it is \"this adds nothing.\"\n\n### The correct framing\n\nThe question is not: \"Is it safe to use AI for SEO content?\"\n\nThe question is: **\"Does this page contain enough information gain, search intent match, and trust signals that Google would rank it — regardless of how it was produced?\"**\n\nIf yes, AI is a powerful accelerator. If no, AI just lets you produce worthless pages faster.\n\n### Where AI helps in pSEO\n\n| Use case | Why it works |\n\n|---|---|\n\n| Summarising structured data into readable prose | Each page's data is unique → output is unique |\n\n| Generating FAQ blocks from a data object | Templated but data-driven → not boilerplate |\n\n| Translating + adapting content (with review) | Saves time; review catches errors |\n\n| Writing meta descriptions from page data | Short, formula-driven → low risk |\n\n| Structuring raw data into tables and comparisons | Saves formatting time; data does the heavy lifting |\n\n| Drafting initial content for human review and enrichment | Faster starting point; human adds the information gain |\n\n### Where AI hurts in pSEO\n\n| Anti-pattern | Risk |\n\n|---|---|\n\n| Generic \"overview\" paragraphs with no data | Identical across all pages → thin content |\n\n| AI-expanded boilerplate (\"X is a type of Y that...\") | Detectable by pattern; no unique value |\n\n| Mass-generating content without data variation | Amplifies the thin content problem at scale |\n\n| Fabricating entity-specific facts | Hallucinations become trust\u002Flegal liabilities |\n\n| Using AI to \"rewrite the top 10 results\" for a keyword | Produces content with zero information gain — just reshuffled common knowledge |\n\n| Letting AI make strategic decisions (keyword selection, page type, whether to publish) | AI will confidently produce content for keywords where the user has no chance of ranking |\n\n### The role boundary\n\n**AI is an execution tool, not a strategy tool for SEO.** AI should:\n\n- ✅ Draft content from structured data the user provides\n- ✅ Format, structure, and polish pages\n\n- ✅ Generate meta descriptions, FAQ blocks, schema markup\n- ✅ Help with technical implementation (SSR, sitemaps, caching)\n\nAI should NOT:\n\n- ❌ Decide which keywords to target\n- ❌ Determine whether a page has enough information gain to publish\n\n- ❌ Replace competitive analysis and intent matching\n- ❌ Assess whether the user's site has enough authority to compete\n\n- ❌ Generate \"content\" without underlying data that varies per page\n\nWhen the user asks for \"SEO content,\" the agent's first job is to ensure there is a real data source and strategic rationale — not to start generating pages.\n\n### Practical checklist before publishing AI-assisted content\n\n- [ ] Does each page's AI output differ meaningfully from every other page? (run a diff on 5 random pages)\n- [ ] Is the AI prose grounded in real data from the data source, or is it freestanding prose?\n\n- [ ] Does each page contain at least one data point or insight not found in the current top 10 results?\n- [ ] Could a human reviewer catch factual errors before publish? (build a review step for high-stakes verticals)\n\n- [ ] Would a user who arrived from Google find this page more useful than the search results they came from?\n- [ ] Has the page type been matched to the query intent (not just a blog post by default)?\n\nIf all answers are yes, the content is likely safe. If any is no, rethink the content strategy before scaling.\n\n---\n\n## Performance and Core Web Vitals for SSR Pages\n\npSEO pages are often deprioritized for performance work because they're \"just content pages.\" But Core Web Vitals are a confirmed ranking factor, and a slow pSEO page competes against well-optimized competitors who target the same keyword.\n\n### The three metrics that matter\n\n| Metric | Threshold | Common cause in pSEO |\n\n|---|---|---|\n\n| **LCP** (Largest Contentful Paint) | \u003C 2.5s | Hero image without dimensions\u002Fpreload; render-blocking CSS |\n\n| **CLS** (Cumulative Layout Shift) | \u003C 0.1 | Images without `width`\u002F`height`; fonts causing FOUT |\n\n| **INP** (Interaction to Next Paint) | \u003C 200ms | Large JS bundles blocking the main thread |\n\n### For SSR Express pages specifically\n\n#### Eliminate render-blocking resources\n\n```html\n\n\u003C!-- WRONG: blocks render until stylesheet loads -->\n\n\u003Clink rel=\"stylesheet\" href=\"https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter\" \u002F>\n\n\u003C!-- CORRECT: preconnect + async load -->\n\n\u003Clink rel=\"preconnect\" href=\"https:\u002F\u002Ffonts.gstatic.com\" crossorigin \u002F>\n\n\u003Clink rel=\"preload\" as=\"style\" href=\"https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter&display=swap\" \u002F>\n\n\u003Clink rel=\"stylesheet\" href=\"https:\u002F\u002Ffonts.googleapis.com\u002Fcss2?family=Inter&display=swap\" media=\"print\" onload=\"this.media='all'\" \u002F>\n\n```\n\n**Inline critical CSS** (the styles needed to render above-the-fold content):\n\n- Inline it in `\u003Cstyle>`tags in`\u003Chead>` — eliminates one round trip\n- Load remaining CSS asynchronously or omit it (pSEO pages rarely need large stylesheets)\n\n**Images must have explicit dimensions** to prevent CLS:\n\n```html\n\n\u003C!-- WRONG: browser doesn't know height → layout shift on load -->\n\n\u003Cimg src=\"${hero}\" alt=\"...\" \u002F>\n\n\u003C!-- CORRECT -->\n\n\u003Cimg src=\"${hero}\" width=\"1200\" height=\"630\" alt=\"...\" loading=\"lazy\" \u002F>\n\n```\n\n**No JavaScript is ideal.** SSR content pages need zero client-side JS. If you must include JS (analytics, interactivity), load it `defer`or`async`.\n\n### Measuring pages not yet in Chrome UX Report\n\nNew pages have no real-user data (CrUX) for 28 days. Use:\n\n- **Lighthouse** (Chrome DevTools or CLI): `lighthouse https:\u002F\u002Fyoursite.com\u002Fglossary\u002Fterm --only-categories=performance`\n- **PageSpeed Insights API**: programmatic scoring for a batch of URLs\n\n- **WebPageTest**: detailed waterfall view to identify bottlenecks\n\nRun Lighthouse on a representative sample of pages (hub, high-volume spoke, low-volume spoke) — don't assume all pages perform equally.\n\n---\n\n## Monitoring and Iteration Loop\n\nShipping pSEO pages is not a one-time event. The standard pattern is: launch → wait 4-8 weeks → analyze → iterate. Most pSEO playbooks fail because teams skip the iteration step.\n\n### What to track in Search Console (per page type)\n\nOpen the **Performance** report, filter by URL prefix for each playbook (`\u002Fglossary\u002F`,`\u002Fguides\u002F`, etc.):\n\n| Signal | Healthy | Problem indicator |\n\n|---|---|---|\n\n| **Impressions growing** | Steady week-over-week increase | Flat after 8 weeks → pages not indexed or no demand |\n\n| **CTR** | >2% for informational, >5% for navigational | Low CTR → title\u002Fdescription not compelling |\n\n| **Average position** | Trending toward \u003C20 | Stuck at 30-50 → content quality or authority issue |\n\n| **Coverage: Crawled, not indexed** | Decreasing | Increasing → thin content signal |\n\n| **Coverage: Excluded (noindex)** | Matches intentional noindex count | Higher than expected → template accidentally sets noindex |\n\n### Decision framework per page set\n\n```text\n\n8 weeks post-launch:\n\n│\n\n├── Indexed AND getting impressions?\n\n│ ├── YES, position \u003C10 → monitor; optimize title\u002Fmeta for CTR\n\n│ ├── YES, position 11-30 → improve content depth, add internal links\n\n│ └── YES, position >30 → thin content; merge with a stronger page or rewrite\n\n│\n\n├── Not indexed (Crawled, not indexed)?\n\n│ ├── Low page count (\u003C100) → submit to Search Console for inspection\n\n│ └── High page count (100+) → thin content; noindex worst pages, improve rest\n\n│\n\n└── Not even crawled?\n\n├── Check sitemap submission\n\n├── Check robots.txt for accidental blocks\n\n└── Check crawl budget — too many thin pages may be crowding out good ones\n\n```\n\n### When to kill a playbook\n\nKill it (noindex + 301 redirect survivors to a hub) when after 6 months:\n\n- Zero pages from the set are in the top 50 for any target keyword, AND\n- Impressions are flat or declining, AND\n\n- The page type is consuming crawl budget (visible in crawl stats)\n\nKeeping dead pages alive harms the rest of the site — Google distributes trust across the whole domain. A smaller set of high-quality pages consistently outperforms a large set of mediocre ones.\n\n### Iteration cadence\n\n| Frequency | Action |\n\n|---|---|\n\n| Weekly | Check indexation coverage for errors |\n\n| Monthly | Review impressions\u002FCTR per playbook; update titles on underperformers |\n\n| Quarterly | Full content audit — merge, improve, or kill underperforming page sets |\n\n| On data change | Regenerate affected pages; update `dateModified` in schema |\n\n---\n\n## Quality Checks\n\n### Pre-Strategy (before writing any code)\n\n- [ ] User has identified unique data source that varies meaningfully per page\n- [ ] Page type matches query intent (blog vs. comparison vs. tool vs. directory)\n\n- [ ] Information gain validated: each page offers something the current top 10 results don't have\n- [ ] Competitive viability assessed: user's site has (or is building) topical authority in this area\n\n- [ ] Starting with a small batch (10-20 pages) before scaling to hundreds\n- [ ] Human has made the strategic decisions; AI is handling execution only\n\n### Pre-Launch (technical and content)\n\n- [ ] `curl` the URL and verify target keywords appear in raw HTML (not rendered by JS)\n- [ ] Each page provides unique value beyond variable substitution — if you removed the entity name, pages would NOT be indistinguishable\n\n- [ ] Information gain test passed: 5 random pages each contain data\u002Finsights not in the current top 10 results\n- [ ] Answers search intent for the target keyword with the correct page type\n\n- [ ] Unique titles and meta descriptions per page\n- [ ] Proper heading structure (one H1, logical H2\u002FH3 hierarchy)\n\n- [ ] Correct schema markup with no validation errors (test at schema.org\u002Fvalidator)\n- [ ] Page speed acceptable — LCP \u003C2.5s, CLS \u003C0.1, no render-blocking resources\n\n- [ ] Images have explicit `width`and`height` attributes\n- [ ] Connected to site architecture (footer\u002Fnav links to hub pages; hub links to spokes)\n\n- [ ] Breadcrumbs render correctly and are not obscured\n- [ ] Logo and branding match the main application exactly\n\n- [ ] In XML sitemap and crawlable (no `noindex` accidentally set)\n- [ ] 404s return proper status codes (no pages for invalid slugs)\n\n- [ ] Cache headers set appropriately per page type (live data: no-cache; static: max-age=86400)\n- [ ] Faceted\u002Ffiltered URLs blocked via `robots.txt`or marked`noindex`\n\n- [ ] Multilingual pages: hreflang tags present, bidirectional, with `x-default`\n- [ ] AI-assisted content: each page's output meaningfully differs from every other page\n\n- [ ] `dateModified` in schema tied to actual data change, not deploy date\n\n### Post-Launch Monitoring\n\nTrack (per playbook URL prefix in Search Console): indexation rate, impressions, average position, CTR\n\n8-week review: assess which page sets are indexed and gaining impressions, which are stuck, which are excluded. Apply the decision framework above.\n\nWatch for: \"Crawled, not indexed\" count rising (thin content), crawl budget errors, manual actions, ranking drops after content updates.\n\n---\n\n## Common Mistakes\n\n### Strategic mistakes (most damaging)\n\n- **Confusing scale with strategy**: Believing \"more pages = more traffic\" without validating that each page has information gain. This is the single most common pSEO failure mode in 2025+.\n- **SEO cosplay**: Pages with perfect technical structure (H1, H2, meta tags, schema) but zero information gain over existing results. Structure is table stakes, not a ranking advantage.\n\n- **No information gain audit**: Publishing pages without checking whether they add anything the current top 10 results don't already have.\n- **Skipping intent matching**: Building blog posts when the query demands a comparison table, or building a product page when the query demands educational content. Wrong page type = won't rank regardless of quality.\n\n- **Ignoring topical authority**: Publishing hundreds of pages in a domain where the site has no track record. Authority is earned through depth and trust signals, not page count.\n- **Letting AI make strategic decisions**: AI generates confidently even when the keyword is unwinnable, the page type is wrong, or the content has no unique value. Human judgment is required for: keyword selection, page type, competitive viability, and publish\u002Fno-publish decisions.\n\n- **Treating AI output as finished content**: AI drafts need human enrichment — original data, case studies, expert judgment, first-hand experience. Raw AI output is a starting point, not a final product.\n\n### Content mistakes\n\n- **Thin content**: Just swapping entity names in identical boilerplate (Google will deindex)\n- **AI prose with no data variation**: All pages share the same generic paragraphs — amplifies thin content at scale. If you removed the entity name, pages would be indistinguishable.\n\n- **Rewriting the top 10 results**: Using AI to rephrase what already ranks is zero information gain. Google doesn't need another version of existing content.\n- **Keyword cannibalization**: Multiple pages targeting the same keyword\n\n- **Over-generation**: Creating pages with no search demand\n- **Poor data quality**: Outdated or incorrect information erodes trust\n\n### Technical mistakes\n\n- **SPA without SSR**: Adding pSEO pages to a React\u002FVue app without server-rendering — Google sees nothing\n- **Orphan pages**: New SEO pages not linked from anywhere in the main site's navigation or footer\n\n- **Inconsistent branding**: SSR pages that look different from the main app break user trust\n- **Breadcrumb obscured by layout tricks**: Negative margin patterns hiding breadcrumb navigation\n\n- **Wrong cache headers**: Live-data pages cached for 24h showing stale rates; static pages uncached causing unnecessary server load\n- **Asset permission errors**: Referencing frontend assets from SSR routes that can't read them\n\n- **Machine-translating pSEO content at scale**: Produces near-duplicate content across locales; triggers spam signals\n- **Missing or asymmetric hreflang**: One page in the set not listing all variants breaks the entire locale cluster\n\n- **Bumping `dateModified` without real content changes**: Deception signal; Google can detect and penalise it\n- **Faceted navigation URLs not blocked**: Filter\u002Fsort param combinations create thousands of near-duplicate crawlable URLs, wasting crawl budget\n\n- **No crawl budget monitoring**: Teams discover Googlebot stopped crawling new pages only after rankings plateau\n- **Skipping Core Web Vitals on pSEO pages**: Slow LCP or high CLS on \"just content\" pages loses rankings to faster competitors\n\n- **Images without dimensions**: Causes CLS on SSR pages (browser doesn't know reserved height until image loads)\n\n### Process mistakes\n\n- **Blasting hundreds of pages at once**: Instead of starting with 10-20 pages, validating indexation and impressions, then scaling what works\n- **No iteration loop**: Shipping pSEO and never reviewing Search Console — dead pages accumulate and drag down domain trust\n\n- **No freshness strategy for live-data pages**: Exchange rates or prices cached for 24h showing stale data destroys credibility\n- **Ignoring UX**: Pages that exist for Google but not for users — no conversion path, no value to visitors\n\n---\n\n## Output Format\n\nDeliver strategy validation first, then implementation. **Do not skip straight to building pages.**\n\n1. **Strategic validation** (before any code):\n\n- What unique data does the user have that varies per page?\n- What page type matches the query intent?\n\n- What information gain does each page offer over current top 10 results?\n- Does the user's site have topical authority in this area?\n\n- Recommended initial batch size (start small, validate, then scale)\n\n1. **Rendering audit**: Confirm whether the app is a SPA and what SSR approach to use\n2. **Strategy**: Opportunity analysis, chosen playbook(s), keyword patterns, data sources, page count estimate\n\n3. **Shared infrastructure**: `ssrShared.ts` (or equivalent) HTML shell before any individual pages\n4. **Template**: URL structure, title\u002Fmeta templates, content outline, schema markup\n\n5. **Implementation**: Working server-rendered pages that return full HTML to `curl`\n6. **Integration**: Footer\u002Fnav updates in the main app linking to the new hub pages\n\n7. **Validation plan**: How to verify pages are indexed, earning impressions, and when to scale or kill the campaign\n\n## Limitations\n\n- Cannot access Search Console data to monitor indexation\n- Cannot check existing backlink profiles\n\n- Data quality depends on the source — always validate before publishing\n- Cannot guarantee rankings — SEO involves many factors beyond on-page optimization\n",{"name":5,"description":7},"main","6b4a291df75c639681e93b4b5b812126443fd6ed","secondary_skills\u002Fprogrammatic-seo",3,"https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd","https:\u002F\u002Fsolanaclawd.com\u002Fopenclawd","https:\u002F\u002Fgithub.com\u002Fclawdsolana","https:\u002F\u002Fmusebook.trade","Welcome to Open Clawd. The future of Ai on and off chain. Bringing webMCP to web 3 using X402, A2A, MPP and so much more!","2026-08-01 09:30:51",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add clawdsolana\u002FOpenClawd --skill programmatic-seo",{"tool":59,"command":60},"bunx","bunx skills add clawdsolana\u002FOpenClawd --skill programmatic-seo",{"tool":62,"command":63},"pnpm","pnpm dlx skills add clawdsolana\u002FOpenClawd --skill programmatic-seo","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fsecondary_skills\u002Fprogrammatic-seo\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},".fingerprint","OTHER","其他",32,"https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fsecondary_skills\u002Fprogrammatic-seo\u002F.fingerprint",[74,105,133,159,169,193],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":83,"publishedAt":104},"01M71KRBD0W01EAXJ8YM4M1SJ2","solana-dev","End-to-end Solana development playbook (Jan 2026). Prefer Solana Foundation framework-kit (@solana\u002Fclient + @solana\u002Freact-hooks) for React\u002FNext.js UI. Prefer @solana\u002Fkit for all new client\u002FRPC\u002Ftransaction code. When legacy dependencies require web3.js, isolate it behind @solana\u002Fweb3-compat (or @solana\u002Fweb3.js as a true legacy fallback). Covers wallet-standard-first connection (incl. ConnectorKit), Anchor\u002FPinocchio programs, Codama-based client generation, LiteSVM\u002FMollusk\u002FSurfpool testing, and security checklists.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fsolana-dev\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],"solana dev","dev","solana","Wallet","end","testing","hooks","kit","new","when","web3","code","react","next","2026","playbook","security","ui","fallback","framework","2026-11-10 10:56:23",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":114,"publishedAt":104},"01M71KR8QPESSY61SVE8ZTFNVT","xurl","A CLI tool for making authenticated requests to the X (Twitter) API. Use this skill when you need to post tweets, reply, quote, search, read posts, manage followers, send DMs, upload media, or interact with any X API v2 endpoint.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fxurl\u002FSKILL.md",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[107,115,116,117,118,119,120,93,121,122,123,124,125,126,127,128,129,130,131,132],"posts","Media","x api","search","send","tap","you","api","cli","read","install","cli tool","endpoint","brew","for","manage","tool","twitter",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":104},"01M71KR6FSXV88YDKWP7NBY3SH","wurk-integration","WURK API integration for monetizing agents with x402 payments on Solana\u002FBase - create social jobs, custom challenges, and agent help tasks","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fwurk-integration\u002FSKILL.md",[139],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[141,142,143,144,145,146,147,148,122,149,150,151,152,153,154,155,129,156,157,158],"wurk","wurk integration","integration","x402","social","payments","tasks","team","create","social-jobs","command","agent-help","custom-jobs","clawd","safe","api integration","custom","true",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":104},"01M71KR4HCX41BPAK9GP7RPRRP","workflows","Manage application workflows including configuration, restart, and removal.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002FSKILL.md",[],[161,130,166,167,168],"configuration","application","restart",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":104},"01M71KR1VM0F5GPEQDNG5J7A0H","web-search","Search the web, fetch content, extract branding profiles, and capture screenshots from URLs. Use for real-time information, API documentation, current events, design matching, and visual reference.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fweb-search\u002FSKILL.md",[],[176,118,177,178,179,129,180,181,182,183,184,185,186,122,187,188,189,190,191,192],"web search","web","fetch","api documentation","real-time","time","profiles","design","use","information","visual","documentation","branding","matching","reference","capture","content",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":104},"01M71KQZN5MR1JFQHG5GWXYAHS","weather","Get current weather and forecasts via wttr.in or Open-Meteo. Use when: user asks about weather, temperature, or forecasts for any location. NOT for: historical weather data, severe weather alerts, or detailed meteorological analysis. No API key needed.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[195,200,129,201,184,93,202,122,203,204,205,206,207,208,209,210,36,211],"get","open","analysis","alerts","temperature","curl","via","help","about","https","location","user"]