--- name: programmatic-seo-templates slug: programmatic-seo-templates description: This skill should be used when the user asks to "design a pSEO template", "build a programmatic SEO page template", "structure a pSEO page", "create a template for programmatic pages", "design a page layout for pSEO", "build an alternatives page template", "create a comparison page template", "design an integration page template", "structure pages generated from data", or any variation of designing page templates for programmatic SEO in B2B SaaS. category: general --- # Programmatic SEO Templates A pSEO template is a reusable page structure that renders unique content from a data source for every variation. The template determines whether each generated page is genuinely useful or a thin shell around swapped keywords. A good template produces pages that pass the editorial test: "Would a human editor publish this as a standalone piece?" The principle: templates have static sections (same on every page) and dynamic sections (unique per page). At least 40% of each rendered page must be unique. Below that threshold, Google treats the pages as near-duplicates. ## Template Architecture Every pSEO template has 7 layers. Each layer is either static (same on all pages), dynamic (unique per page from data), or semi-dynamic (template sentences with data-filled slots). | Layer | Type | Purpose | |-------|------|---------| | 1. SEO metadata | Dynamic | Title tag, meta description, OG tags, canonical URL | | 2. Hero section | Dynamic | H1, subtitle, key metric or value prop | | 3. Introduction | Semi-dynamic | Context paragraph, why this page exists | | 4. Core content blocks | Dynamic | The main data-driven sections (comparisons, features, details) | | 5. Supporting content | Semi-dynamic | Methodology, buyer's guide, editorial commentary | | 6. FAQ | Dynamic | Questions generated from related searches | | 7. CTA | Static | Call-to-action, consistent across pages | --- ## Template Blueprints ### Blueprint 1: Alternatives Page **Target keyword:** "[Competitor] alternatives" ``` ┌─────────────────────────────────────────┐ │ H1: {count} Best {competitor} Alts │ ← Dynamic │ in {year} │ │ Subtitle: Updated {month} {year} │ ← Dynamic ├─────────────────────────────────────────┤ │ INTRO (80-120 words) │ │ {competitor} is known for {strength}. │ ← Semi-dynamic │ Teams look for alternatives because │ │ {limitation_1}, {limitation_2}, or │ │ {limitation_3}. │ ├─────────────────────────────────────────┤ │ YOUR PRODUCT (#1) │ ← Dynamic │ - Overview (100-150 words) │ │ - 3 differentiators vs {competitor} │ │ - Pricing │ │ - Best for: {segment} │ │ - Limitations (1-2) │ ├─────────────────────────────────────────┤ │ ALTERNATIVES #2-8 (100-150 words each) │ ← Dynamic │ For each: │ │ - Overview │ │ - Strengths (2-3) │ │ - Limitations (2-3) │ │ - Pricing │ │ - Best for │ ├─────────────────────────────────────────┤ │ COMPARISON TABLE │ ← Dynamic │ 5-7 dimensions x all products │ ├─────────────────────────────────────────┤ │ HOW TO CHOOSE (150-200 words) │ ← Static │ Criteria-based buying guide │ ├─────────────────────────────────────────┤ │ FAQ (4-6 questions) │ ← Dynamic ├─────────────────────────────────────────┤ │ CTA: Try {your_product} free │ ← Static └─────────────────────────────────────────┘ ``` **Data requirements per variation:** | Field | Required | Notes | |-------|----------|-------| | competitor_name | Yes | Primary keyword anchor | | competitor_description | Yes | 50-100 words | | competitor_strengths | Yes | Array, min 2 | | competitor_limitations | Yes | Array, min 2. Source from G2 reviews | | competitor_pricing | Yes | Starting price or range | | competitor_g2_rating | Yes | Float | | competitor_best_for | Yes | One-sentence segment description | | alternative_products | Yes | Array of 5-8 product objects with same fields | | your_differentiators | Yes | Array of 3, specific to this competitor | | faq_questions | Yes | Array of 4-6, sourced from "People Also Ask" | ### Blueprint 2: VS Comparison Page **Target keyword:** "[Product A] vs [Product B]" ``` ┌─────────────────────────────────────────┐ │ H1: {product_a} vs {product_b}: │ ← Dynamic │ Honest Comparison ({year}) │ ├─────────────────────────────────────────┤ │ VERDICT BOX │ ← Dynamic │ Quick answer: Choose {a} if {cond}. │ │ Choose {b} if {cond}. Choose │ │ {your_product} if {cond}. │ ├─────────────────────────────────────────┤ │ COMPARISON TABLE │ ← Dynamic │ 8-10 dimensions, side by side │ ├─────────────────────────────────────────┤ │ DETAILED BREAKDOWN │ ← Dynamic │ For each dimension: │ │ - H3: {dimension} │ │ - {product_a} approach (50-80 words) │ │ - {product_b} approach (50-80 words) │ │ - Verdict: "Better for {use case}" │ ├─────────────────────────────────────────┤ │ PRICING COMPARISON │ ← Dynamic │ Plan-by-plan breakdown │ ├─────────────────────────────────────────┤ │ WHERE {YOUR_PRODUCT} FITS │ ← Semi-dynamic │ Position as third option (150 words) │ ├─────────────────────────────────────────┤ │ FAQ (4-6 questions) │ ← Dynamic ├─────────────────────────────────────────┤ │ CTA │ ← Static └─────────────────────────────────────────┘ ``` **Data requirements per variation:** | Field | Required | Notes | |-------|----------|-------| | product_a_name | Yes | | | product_b_name | Yes | | | comparison_dimensions | Yes | Array of 8-10 objects: {name, product_a_approach, product_b_approach, verdict} | | product_a_pricing | Yes | Plan-level detail | | product_b_pricing | Yes | Plan-level detail | | product_a_best_for | Yes | | | product_b_best_for | Yes | | | your_product_positioning | Yes | Why you're a better fit for a specific segment | | faq_questions | Yes | Array of 4-6 | ### Blueprint 3: Integration Page **Target keyword:** "[Your Product] + [Integration]" or "[Your Product] [Integration] integration" ``` ┌─────────────────────────────────────────┐ │ H1: Connect {your_product} with │ ← Dynamic │ {integration} │ │ Subtitle: {one-line benefit} │ ├─────────────────────────────────────────┤ │ INTEGRATION OVERVIEW (100-150 words) │ ← Semi-dynamic │ What it does, who it's for │ ├─────────────────────────────────────────┤ │ KEY FEATURES │ ← Dynamic │ 3-5 specific sync/automation features │ │ Each: icon + title + 1-2 sentences │ ├─────────────────────────────────────────┤ │ HOW IT WORKS │ ← Semi-dynamic │ 3-4 steps with screenshots │ │ Setup time: {setup_time} │ ├─────────────────────────────────────────┤ │ USE CASES │ ← Dynamic │ 2-3 specific workflows enabled │ │ Each: title + 2-3 sentence description │ ├─────────────────────────────────────────┤ │ REQUIREMENTS │ ← Dynamic │ Plans, permissions, prerequisites │ ├─────────────────────────────────────────┤ │ FAQ (3-5 questions) │ ← Dynamic ├─────────────────────────────────────────┤ │ CTA: Try the integration free │ ← Static └─────────────────────────────────────────┘ ``` ### Blueprint 4: Use Case Page **Target keyword:** "[Product] for [use case]" or "[use case] software" ``` ┌─────────────────────────────────────────┐ │ H1: {your_product} for {use_case} │ ← Dynamic │ Subtitle: {outcome statement} │ ├─────────────────────────────────────────┤ │ PROBLEM STATEMENT (100-150 words) │ ← Dynamic │ The pain of doing {use_case} without │ │ proper tooling │ ├─────────────────────────────────────────┤ │ HOW {YOUR_PRODUCT} SOLVES IT │ ← Dynamic │ 3-4 feature → benefit blocks │ │ Each: screenshot + feature + outcome │ ├─────────────────────────────────────────┤ │ RESULTS / PROOF │ ← Dynamic │ 1-2 customer proof points specific │ │ to this use case │ ├─────────────────────────────────────────┤ │ COMPARISON TO ALTERNATIVES │ ← Dynamic │ Brief table: your product vs 2-3 │ │ alternatives for this specific use case│ ├─────────────────────────────────────────┤ │ FAQ (3-5 questions) │ ← Dynamic ├─────────────────────────────────────────┤ │ CTA │ ← Static └─────────────────────────────────────────┘ ``` ### Blueprint 5: Glossary / Definition Page **Target keyword:** "What is [term]" or "[term] definition" ``` ┌─────────────────────────────────────────┐ │ H1: What is {term}? │ ← Dynamic ├─────────────────────────────────────────┤ │ DEFINITION BOX │ ← Dynamic │ One-paragraph plain-language definition│ │ (50-80 words, featured snippet format) │ ├─────────────────────────────────────────┤ │ DETAILED EXPLANATION (200-400 words) │ ← Dynamic │ Context, examples, why it matters │ ├─────────────────────────────────────────┤ │ KEY COMPONENTS / TYPES │ ← Dynamic │ Breakdown of subtopics within the term │ │ 3-5 subsections │ ├─────────────────────────────────────────┤ │ EXAMPLES │ ← Dynamic │ 2-3 concrete real-world examples │ ├─────────────────────────────────────────┤ │ {TERM} VS RELATED TERMS │ ← Dynamic │ Comparison table with 2-3 related terms│ ├─────────────────────────────────────────┤ │ HOW {YOUR_PRODUCT} HELPS WITH {TERM} │ ← Semi-dynamic │ Soft product tie-in (80-120 words) │ ├─────────────────────────────────────────┤ │ FAQ (3-5 questions) │ ← Dynamic ├─────────────────────────────────────────┤ │ RELATED TERMS (internal links) │ ← Dynamic └─────────────────────────────────────────┘ ``` --- ## Dynamic Text Patterns The hardest part of template design is writing dynamic text that reads naturally, not like a mail merge. ### Bad dynamic text (reads like a robot) ``` {competitor} is a tool in the {category} space. It is used by {audience}. Its main features include {feature_1}, {feature_2}, and {feature_3}. It costs {price}. ``` ### Good dynamic text (reads like a human) ``` {competitor} built its reputation on {core_strength}, which is why {audience} adopted it early. But as teams scale past {growth_threshold}, the gaps show up: {limitation_1} becomes a bottleneck, and {limitation_2} adds friction that wasn't there at smaller volumes. ``` ### Dynamic text rules - **Vary sentence structure.** Not every sentence should be "[Subject] [verb] [object]." Mix in subordinate clauses, questions, and short punchy sentences - **Use conditional logic for depth.** If the data entry has a `migration_story` field populated, render a migration section. If not, skip it. Pages with more data should be longer and richer - **Don't force data into every sentence.** Some sentences should be template-static and provide context. A paragraph that's 100% data-filled variables reads like a form letter - **Write 3-4 template variants for key sentences.** Randomly select one per page. This prevents Google from seeing identical sentence patterns across hundreds of pages - **Test with the worst data entry.** Render the page using the entry with the least data. If it produces a stub, either enrich the data or add conditional logic to handle sparse entries gracefully ### Sentence variant example For the intro paragraph, write 3 variants: **Variant A:** ``` {competitor} has been a go-to choice for {audience} since {founded_year}. Teams pick it for {core_strength}. But as the market has evolved, {limitation_1} has pushed many to explore alternatives. ``` **Variant B:** ``` If you're evaluating {competitor}, you already know it's strong on {core_strength}. The question is whether {limitation_1} and {limitation_2} are dealbreakers for your team. ``` **Variant C:** ``` {competitor} dominates {category_short} for a reason: {core_strength} is genuinely best-in-class. Still, {audience_specific_segment} often outgrow it when {growth_trigger} kicks in. ``` --- ## Content Uniqueness Checklist For each generated page, verify: | Check | Threshold | How to verify | |-------|-----------|---------------| | Unique word count | ≥ 300 words unique to this page | Diff against other generated pages | | Unique content ratio | ≥ 40% of total page content | (Unique words / total words) per page | | Data fields rendered | ≥ 5 unique data points | Count non-empty dynamic fields | | No identical paragraphs | 0 paragraphs shared verbatim with another page | Automated comparison | | Unique title tag | 100% unique across all pages | Automated check | | Unique meta description | 100% unique across all pages | Automated check | | Unique H1 | 100% unique across all pages | Automated check | ### Uniqueness rules - Run the uniqueness check before every batch launch. Automated script, not manual review - Pages below the 40% unique threshold should either be enriched with more data or excluded from the launch - If two pages are too similar (> 70% overlap), either merge them into one page or differentiate them further - Title tags, meta descriptions, and H1s must be 100% unique. Duplicate titles cause Google to ignore the duplicates --- ## Responsive Design Requirements pSEO pages must work on mobile. 60%+ of B2B search traffic is mobile. Templates that break on small screens lose rankings. | Element | Desktop | Mobile | |---------|---------|--------| | Comparison tables | Full table, horizontal scroll if needed | Stacked cards or accordion | | Feature lists | Multi-column grid | Single column | | Screenshots | Full-width | Swipeable carousel or stacked | | FAQ | Expanded by default | Accordion (collapsed by default) | | CTA | Inline with content | Sticky bottom bar | | Pricing comparison | Table format | Stacked plan cards | ### Mobile rules - Test every template on a 375px viewport (iPhone SE) before launch - Comparison tables must have a mobile fallback. A 7-column table on mobile is unusable - Loading speed matters more for pSEO than editorial content because Google evaluates page quality at scale. Target Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms --- ## Schema Markup Every pSEO template should include structured data for potential rich results. | Page type | Schema type | Key fields | |-----------|------------|-----------| | Alternatives | ItemList + Article | List items, article author, dateModified | | VS comparison | Article + Product (x2) | Product names, ratings, pricing | | Integration | SoftwareApplication + HowTo | Application name, steps, requirements | | Use case | Article + Product | Product name, use case description | | Glossary | DefinedTerm + FAQPage | Term, definition, FAQ questions/answers | | All pages | BreadcrumbList | Navigation path | | All pages with FAQ | FAQPage | Question/answer pairs | ### Schema rules - Validate schema with Google's Rich Results Test before launch - FAQPage schema on every page type. FAQ sections are universal and FAQ schema frequently earns rich results - BreadcrumbList on every page. Helps Google understand the site hierarchy - Don't add schema for features the page doesn't have. Review schema without actual user reviews will be flagged --- ## Template Testing Protocol Before launching any template at scale: ### Test 1: Content quality (manual) Render 10 pages using data entries of varying quality (best, average, worst). Review each: - [ ] Does the page read like it was written by a human? - [ ] Would a subject-matter expert consider this page useful? - [ ] Is each page meaningfully different from the others? - [ ] Does the worst-data page still meet the 300-word unique content threshold? ### Test 2: SEO validation (automated) - [ ] Every page has a unique title tag ≤ 60 characters - [ ] Every page has a unique meta description ≤ 155 characters - [ ] Every page has a unique H1 - [ ] Every page has a self-referencing canonical tag - [ ] No page has fewer than 300 words of unique content - [ ] Schema markup validates on every page - [ ] All internal links resolve (no 404s) ### Test 3: Performance (automated) - [ ] Page load time < 3 seconds on 4G - [ ] Core Web Vitals pass on mobile and desktop - [ ] No render-blocking resources from dynamic data loading - [ ] Images are lazy-loaded and properly sized ### Test 4: Mobile (manual) - [ ] Comparison tables render correctly on 375px viewport - [ ] No horizontal scroll on any content section - [ ] CTA is visible and tappable without scrolling - [ ] FAQ accordion works on touch devices --- ## Anti-Pattern Check - Template produces pages with < 300 words of unique content. These are thin pages. Google will deindex them and may penalize the entire section. Enrich the data or exclude sparse entries - Same intro paragraph on every page with only the competitor name swapped. This is the #1 pSEO template failure. Write 3-4 sentence variants and use conditional logic to vary the introduction - Comparison table has 10+ columns. Unreadable on any screen. Cap at 6-7 columns. Use a separate detailed section for additional dimensions - No mobile fallback for tables. Tables are the most-viewed section on comparison pages. A table that breaks on mobile loses 60% of visitors - FAQ section is identical across pages. FAQs must be unique per page, sourced from "People Also Ask" for each specific keyword. Identical FAQs across pages signal duplicate content - No conditional logic for sparse data. A page rendered with 3 empty fields and placeholder text ("No data available") is worse than a shorter page that skips those sections entirely - Template never tested with worst-case data. The template should produce a usable page even from the weakest data entry. If it doesn't, add quality gates that exclude entries below a minimum threshold - All dynamic text uses the same sentence structure. "{X} is a {category} tool. It does {thing}. It costs {price}." repeated 500 times is a pattern Google detects. Vary sentence structure and use template variants