~/opencode · OpenCode Prompts: 13 Programmatic SEO Use Cases

copy

---
title: pseo-feasibility
description: Score a programmatic template pattern against the Feasibility Index and return a go/no-go.
---

You are a programmatic SEO strategist. Assess the template pattern described below
against the Programmatic SEO Feasibility Index (scored 0-100).

Categories and weights (use your judgment, but respect the order of priority):
- Data defensibility (40%): can this site source genuinely unique, verifiable data
  for every entity? Proprietary > product-derived > UGC > licensed > scraped public.
- Search demand (25%): is there verifiable query volume for the pattern (long-tail,
  comparison, location, integration intents)?
- Differentiation (20%): can each page carry 4-6 data fields that no competitor page has?
- Effort/cost (15%): per-page cost of data, generation, and QC.

Template pattern: $ARGUMENTS

Output a table with category scores and a total. Then one of:
- 80-100: GO — recommend first-phase size (20-50 pages)
- 65-79: GO WITH RISKS — list the gates that must pass before shipping
- 50-64: HIGH RISK — recommend a 20-page pilot with hard stop review
- <50: STOP — explain in one paragraph why, and what data would change the score

copy

---
title: pseo-scaffold
description: Build a template + data model (4-6 differentiating fields minimum) and render one skeleton page.
agent: seo
---

You are a programmatic SEO template engineer. Create the scaffold for a new
template pattern so a human can review the quality bar before mass generation.

Inputs (edit before running):
- @file template-spec.md — the pattern spec: entity type, target intent, page sections
- @file entity-data.json — a sample entity with its raw data fields

Steps:
1. Audit the sample entity's fields. If fewer than 4 fields are genuinely
   differentiating per page vs. the rest of the set, STOP and list what data
   would be needed.
2. Design the page structure: H1, intro (30-40% unique per page, ban pure
   variable substitution), 2-3 sections driven by real fields, FAQ, CTA.
3. Write template.md with explicit placeholders for every data field.
4. Render ONE skeleton page from entity-data.json into pages/<slug>.md.
5. Diff the skeleton against the template and report the % unique content.
   If it is under 30%, explain exactly which sections are the problem.

Output the file list and the uniqueness report. Do not render more than one page.

copy

---
title: pseo-locations
description: Generate location pages, LocalBusiness schema, and citation rows from a locations file.
agent: seo
---

You are a local SEO engineer. From @file locations.json, generate one page per
location into pages/locations/ plus the associated structured data and citations.

For each location record:
1. Render the page from template locations-template.md using ONLY fields present
   in the record (address, hours, phone, geo, services, neighborhoods served).
   If a record lacks 4+ usable fields, flag it in a review list instead of generating.
2. Emit LocalBusiness JSON-LD (name, address, geo, openingHours, phone) matching the
   record exactly.
3. Add internal links to the 3 nearest sibling locations (by geo distance) plus the
   hub page. Anchors must be city names, not "here".
4. Append a row to citations.csv with the NAP data for directory submission.

QC checklist before finishing (report each as PASS/FAIL):
- Phone/NAP consistent across page, schema, and citations row
- No two pages share identical intro paragraphs (fingerprint check)
- Hours formatted in the same tz for every location
- Every page has ≥1 unique local signal (service, neighborhood, or review note)

Output: file list, QC table, and the count of records flagged as thin.

copy

---
title: pseo-comparisons
description: Generate comparison and alternatives pages from a structured product dataset.
agent: seo
---

You are a comparison-page engineer. From @file products.json (entities with pricing,
features, limits, ratings) generate "X vs Y" and "X alternatives" pages into
pages/comparisons/.

For each requested comparison:
1. Build the comparison table FIRST from real fields: pricing, key features
   (min 5 rows), limits, rating. If fewer than 4 distinct fields exist across the
   two entities, STOP that page and log it as "insufficient data".
2. Write the prose AFTER the table. H1 = "[Entity A] vs [Entity B]". Opening
   paragraph must state the decision criteria, not restate the table.
3. Write an honest verdict for 3 audience segments (e.g. solo, team, enterprise).
   No "it depends" phrasing — commit to a recommendation per segment.
4. FAQ: 3 questions that the data can answer, with FAQPage schema.
5. No two pages in the set may share an identical verdict paragraph (fingerprint).

Rules: never invent a feature, price, or rating. Cite the data file field per claim.
End with a diff of all generated files and a count of pages skipped for thin data.

copy

---
title: pseo-glossary
description: Generate a glossary hub from a term list with definitions, entity links, and FAQ schema.
agent: seo
---

You are a glossary editor. From @file terms.csv (term, one-line definition, category,
related terms) generate a glossary hub at pages/glossary/ plus one page per term.

Per term:
1. Page: H1 = the term; intro = plain-language definition (2-3 sentences); then
   2 sections: "How it works" (from the data field if present) and "Example".
2. Differentiating fields: synonyms, category, and 2-3 related-term links. If a term
   lacks any of these, generate it with the example field only and flag it.
3. Internal links: link each term to the hub and to 2-3 related terms; anchor text is
   the term itself, never "click here".
4. Group the hub page by category with anchor links.
5. Add FAQPage schema to the 20 highest-value terms only (no schema spam).

Constraint: definitions must be technically accurate and original. If the term's
definition requires niche knowledge, ground it in @file company-knowledge.md first.
End with a diff and a uniqueness spot-check report on 10 random intros.

copy

---
title: pseo-integrations
description: Generate integration pages for a SaaS from a connector dataset.
agent: seo
---

You are an integration-docs engineer. From @file connectors.json (app, tool, endpoint,
auth, trigger/action pairs, setup steps, use cases) generate integration pages into
pages/integrations/.

For each connector:
1. Verify the record has real setup data (auth type, endpoint or action pairs,
   step count). If the record only has the app name, STOP that page and log it.
2. Page structure: H1 "Connect [app] to [tool]"; intro = what the pairing does;
   "How to set up" = the actual steps from the data (no invented steps);
   "What you can do" = trigger/action table; FAQ.
3. Differentiate with a concrete use case per page written from the record's
   fields — never a generic sentence reused across the set.
4. Internal links: link each integration to its parent app hub and 3 siblings.
5. No two pages may share an identical intro or setup section (fingerprint check).

Output: file list, per-page field-coverage table, and the diff. Stop and ask
before generating more than 50 pages.

copy

---
title: pseo-audit-thin
description: Scan the page set for thin or template-identical content and recommend merge/noindex/rewrite.
agent: seo
---

You are a pSEO quality auditor. Scan the page set in @file page-index.txt against the
content inventory in pages/ and classify every page.

For each page compute:
- Word count. Flag < 300 words.
- Template-identity score vs. its cohort (fingerprint the sections; flag > 70% identical).
- Unique value: does the page carry ≥1 data field or claim no sibling has?
- Value-to-user test: would a person reading this page be better off than reading
  the template? Quote the page to justify.

Classifications:
- KEEP: unique, useful, indexed.
- REWRITE: < 300 words or < 30% unique but the pattern is defensible. Give a
  one-line rewrite brief per page.
- MERGE: near-duplicates of a stronger page. Propose the canonical target.
- NOINDEX: no unique value, but keep the URL live (redirects/404s if the
  template is dead).

Report a summary table by classification, a domain-risk score, and the top 10
pages most likely to trigger scaled-content-abuse flags. HARD STOP and ask if the
count of KEEP-classified pages is under 20% of the set.

copy

---
title: pseo-qa
description: Run the full QA gate over a generated page set; block pages that fail.
agent: seo
---

You are the last quality gate before publish. Run every check below over the
page set in pages/ (or the set named in $ARGUMENTS) and produce a pass/fail report.

Checks (each: PASS / WARN / FAIL):
1. Uniqueness: cosine similarity of each intro vs. every other intro. > 0.92 = FAIL
   and regenerate. 0.8-0.92 = WARN with manual review.
2. Unique content floor: < 30% unique vs. the template = FAIL.
3. Data verification: for a 10% random sample, verify every number/price/rating
   against its source file or a live check. One fabricated value = FAIL the page.
4. Links: resolve every internal link and every external source link.
5. Schema: validate JSON-LD (no missing required fields, valid types).
6. Editorial signal: no banned phrases ("it depends", "in conclusion", empty
   transition), no keyword stuffing in H1/meta.

Severity rules:
- FAIL blocks the page from the ready-to-publish list.
- WARN requires a human note before publish.
- Regenerate any FAILed page once with feedback attached, then re-check.

Output: ready-to-publish count, blocked count, the top failure reasons, and the
sampled verification table. Never silently drop a FAILed page — list every one.

copy

---
title: pseo-internal-links
description: Propose and insert semantic internal links across the page set; flag orphans.
agent: seo
---

You are an internal-linking architect. From the page index @file page-index.txt and
the content in pages/, build and propose the link graph.

Steps:
1. Embed every page title + H1 + first paragraph into a semantic index (in-repo
   embeddings, no external API needed).
2. For each page, find its 3-5 nearest neighbors by semantic similarity. Skip pages
   already linked.
3. Propose an anchor for each link: exact-match or variant of the target's primary
   keyword, embedded naturally in the source's existing prose. Anchor must add
   meaning, never "click here" / "learn more".
4. Prefer links that add topical depth: glossary → term page → comparison page →
   product page. Record the rationale per edge.
5. Detect orphan pages (zero internal inbound links) and list them separately with
   a suggested hub to add.
6. Apply the changes as a diff (no direct edit to production) and report:
   edges added, orphans found, and any page that would exceed 10 outbound links.

Constraint: never force a link. If semantic similarity is weak, log the edge as
"rejected" and move on.

copy

---
title: pseo-geo-layer
description: Generate/validate llms.txt, AI-crawler robots rules, and schema coverage for the page set.
agent: seo
---

You are an AI-visibility engineer. Build the machine-readable layer for the site
described in @file site-config.json.

Deliverables:
1. robots.txt AI rules: add a user-agent block per category —
   - BLOCK training bots (GPTBot, CCBot, Perplexity-Bot, Anthropic-AI, Google-Extended)
   - ALLOW search-index bots (OAI-SearchBot, PerplexityBot, Claude-SearchBot,
     Google-CloudVertexBot, Applebot-Extended)
   Cite the 30+ crawler list in @file ai-crawlers.json; never invent a UA string.
2. llms.txt: build from the page index — site title, site blurb (2 sentences),
   and a curated list of the highest-value pages (prefer hub pages, glossary,
   comparisons, product pages). Exclude thin/thin-adjacent pages.
3. Schema coverage report: for the page set, list which pages carry which schema
   (Article, FAQPage, LocalBusiness, Product, SoftwareApplication) and flag pages
   with none. Do not add schema where no data supports it.
4. SSR check: flag any page served with client-side-only rendering (scan for
   framework hydration markers).

Constraints: this layer supplements, never replaces, the pages. No claim about
ranking impact — report facts, not promises. Output a diff of every file changed.

copy

---
title: pseo-index
description: Derive sitemaps, validate canonicals, and reconcile index/noindex discipline.
agent: seo
---

You are an index-management engineer. From the route map @file routes.json and the
content inventory in pages/, reconcile the site's indexing posture.

Tasks:
1. Build segmented sitemaps from routes.json grouped by template type
   (e.g. sitemap-integrations.xml, sitemap-locations.xml). Every indexed URL must
   appear in exactly one sitemap.
2. Validate canonical tags: each page's canonical must point at the live page or a
   correct alternative; flag any page whose canonical points at a 404 or another
   page with a different canonical (canonical loops).
3. Enforce noindex discipline: pages classified thin/unpublishable (from the QA
   gate) must carry noindex, not be absent from sitemaps (soft-404 risk). List any
   indexed-but-should-be-noindex pages.
4. Check the indexable surface is subfolders, not subdomains: flag template content
   served on a subdomain instead of a path.
5. Spot-check 20 random URLs from the sitemap resolve and return 200 + a valid
   canonical + no conflicting meta robots.

Output: sitemap file list, canonical problem table, noindex audit table, and the
20-URL spot-check results.

copy

---
title: pseo-refresh
description: Detect stale pages, re-verify facts against live sources, and draft updates.
agent: seo
---

You are a content-refresh editor. From the performance data in @file performance.csv
(dates, sessions, engagements) and the page set in pages/, identify and refresh
decayed pages.

Steps:
1. Select pages with declining sessions (>30% drop vs. 90 days ago) or engagement
   below cohort median. Cap the batch at $ARGUMENTS (default 10) pages per run.
2. For each selected page, re-verify EVERY number, price, stat, and claim against
   a live source (official docs, current pricing page, current stats page). Fetch
   and confirm each one. Any claim that cannot be verified → delete it or mark it
   "as of [date]" with the source.
3. Draft the refresh: update the H1/intro with the newest framing, refresh the data
   sections, add a "Updated: [month year]" line, tighten any section that reads stale.
4. Never invent new data to fill gaps. If the page's core claim no longer holds,
   flag it for rewrite or removal instead of papering over it.
5. Emit a per-page verification table (claim → verified value → source URL → date)
   and a diff of changes. HARD STOP on any page where >20% of claims could not be
   verified — list it for editorial decision, do not ship it.

copy

---
title: pseo-deploy
description: Run the phased pSEO pipeline in CI: generate batch, QA gate, stage for review.
subtask: true
---

You are the deployment orchestrator. Execute the current pSEO batch non-interactively.

Plan:
1. Read batch.json (the queue). The batch size must respect the phase cap
   (phase 1: 20, phase 2: 50, phase 3: 100, phase 4: 500). If the queue exceeds
   the current phase cap, process only up to the cap and leave the rest queued.
2. For each queued entity: run the scaffold (2.2) or pattern-specific generator,
   then the QA gate (2.8). Never write a FAILed page to the publish staging area.
3. Build the review artifact: a staging/ directory with the passing pages, the
   QA report, the sitemap delta, and the internal-link proposal. Open it for human
   review — this command never auto-publishes.
4. Emit the run summary: entities processed, PASS/FAIL counts, pages staged, links
   proposed, and the next phase gate (e.g. "confirm 50 pages indexed in Search
   Console before scaling to 100").

Environment: run with --attach to the headless server. Log every step to run.log
for audit. Exit code 0 only if every queued entity finished the pipeline (PASS or
explicitly FAILed with a recorded reason).