Programmatic SEO Page Brief Prompt

Create an evidence-led programmatic SEO brief for the following page family.

Inputs
- Programmatic page set: [Programmatic page set]
- Business and conversion goal: [Business and conversion goal]
- Audience and markets: [Audience and markets]
- Site and template context: [Site and template context]
- Keyword and SERP evidence: [Keyword and SERP evidence]
- Source data and approved claims: [Source data and approved claims]
- Internal link inventory: [Internal link inventory]
- Constraints and success criteria: [Constraints and success criteria]

Input requirements
Treat the page set, business goal, intended audience, and site or template context as blocking prerequisites. Reliable keyword targeting also requires supplied keyword or SERP evidence, or public-web research performed with browsing explicitly available. Source data is required before recommending page-specific factual claims at scale.

Useful optional context includes Search Console exports, analytics landing-page data, crawl reports, current rankings, conversion data, editorial policies, brand guidance, schema already in use, competitor URLs, and known canonicalization or indexation rules.

If a blocking prerequisite is missing or conflicting, ask only the questions needed to resolve it. If the missing information does not prevent bounded progress, continue with a clearly labeled provisional brief and preserve the issue as an unknown. Never invent search volumes, rankings, competitor findings, source records, crawl results, conversion performance, or approval.

Tool and evidence boundaries
Use ChatGPT to analyze the supplied materials, structure the brief, compare evidence, and draft recommendations. Inspect public pages only when browsing is available in the current session. State when browsing, private analytics, crawling, or source-system access is unavailable. Do not imply access to Search Console, analytics, a CMS, a crawler, or internal databases unless their exports or results were provided.

For every material conclusion, distinguish among:
- Supplied fact: directly supported by an input or named source.
- Observed evidence: visible in an accessible page, SERP capture, export, or report; identify the source and observation date when available.
- Assumption: a bounded premise used to continue.
- Hypothesis: a proposition requiring validation.
- Unknown or conflict: missing or inconsistent evidence that affects confidence.

Do not publish pages, modify templates, change canonicals, edit internal links, deploy schema, approve claims, or represent recommendations as implemented. These actions require an authorized human owner. Do not expose credentials, personal data, confidential customer records, or licensed data that cannot be reproduced. Flag legal, medical, financial, safety, regulated, or comparative claims for qualified review. Reject tactics that depend on doorway pages, cloaking, keyword stuffing, fabricated reviews, copied competitor text, or pages whose only distinction is a swapped token with no user value.

Workflow
1. Normalize the opportunity
Define the page family, entity and modifier dimensions, audience, search journey, conversion event, geographic or language scope, and proposed scale. Separate fixed template elements from page-level data. Identify dependencies such as data coverage, CMS capabilities, editorial capacity, indexation controls, and update ownership.

2. Audit the evidence
Create an evidence ledger for all supplied sources. Record source name or URL, type, date or freshness, scope, supported conclusion, limitations, and confidence. If SERP evidence exists, compare query variants by market and note dominant intent, ranking page type, result features, recurring subtopics, and meaningful competitor patterns. Do not treat a single undated SERP as universal or stable.

3. Map queries to intent and page purpose
Cluster only where the evidence supports clustering. For each proposed page type, identify the primary intent, secondary needs, funnel stage, desired action, and why a dedicated page is preferable to an existing page, filtered view, category page, editorial article, or consolidated resource. Keep informational and transactional intents separate when combining them would weaken relevance.

4. Make the page eligibility decision
Classify each proposed page type as create and index, create but noindex, consolidate, redirect candidate, or exclude. Base the decision on unique demand, unique user value, data completeness, differentiation, overlap with existing URLs, and maintainability. Explain trade-offs and required approval for canonical, redirect, or indexation recommendations.

5. Control duplication and cannibalization
Build a comparison matrix covering proposed URLs, target intent, existing competing URLs, shared template content, required unique data, minimum differentiation evidence, canonical relationship, and collision risk. Flag near-duplicate combinations, empty or sparse records, synonymous location or category variants, faceted explosions, and pages likely to compete for the same query. Do not prescribe an arbitrary word-count threshold as proof of uniqueness.

6. Design the reusable content and data model
Define every field needed by the template. For each field, specify its purpose, data type, source of truth, required or optional status, validation rule, allowed fallback, refresh trigger, and behavior when missing. Separate factual fields from generated prose. Ensure fallbacks do not create false claims, broken grammar, misleading availability, or identical page bodies.

7. Produce the page brief architecture
Specify URL pattern, title-tag formula, meta-description guidance, H1 rule, introduction requirements, major content modules, conversion components, trust elements, media and accessibility requirements, and conditional sections. For each module, state the user question answered, required evidence, unique-value requirement, and omission condition. Include a representative brief for at least one page type and note controlled variations needed for materially different intents.

8. Plan links, citations, and structured data
Recommend contextual internal-link sources, destination types, anchor-text principles, breadcrumbs, hub relationships, and orphan-page prevention. Use only URLs or inventories supplied or actually inspected; otherwise describe link opportunities without inventing destinations. Identify claims that need first-party or authoritative external citations and specify acceptable source types and freshness needs. Recommend structured data only when the visible content and page type meet the applicable eligibility requirements; label validation and search-engine acceptance as pending until tested.

9. Define generation and editorial controls
Set rules for grounded generation, prohibited unsupported claims, tone, localization, entity naming, duplicate phrase detection, data validation, and human editorial review. Include stop conditions for absent source records, conflicting prices or availability, sensitive claims, excessive page overlap, broken template logic, and insufficient unique value.

10. Define validation and rollout
Recommend a reversible pilot sample that covers high-value, low-data, edge-case, and overlap-risk pages. Specify pre-publication review, rendered-page QA, link and schema validation, indexation review, and post-launch measurement. Keep proposed checks separate from checks actually performed. Any launch, indexation, canonical, redirect, or bulk-generation decision remains pending human approval.

Required output
1. Scope and decision statement
State the proposed page family, scale, audience, business outcome, principal assumptions, and whether the result is evidence-backed, provisional, or blocked.

2. Input and evidence ledger
Use columns for item, classification, source, date or freshness, observation, limitation, confidence, and affected decision.

3. Page-family strategy table
Use columns for page type, entity-modifier pattern, audience need, primary intent, conversion goal, unique-value basis, example URL pattern, indexation recommendation, and rationale.

4. Query and SERP intent map
Use columns for query cluster, evidence source, dominant intent, ranking page types, SERP features, required coverage, proposed destination, confidence, and unresolved question. Mark this section unavailable rather than fabricating it when evidence and browsing are absent.

5. Creation and indexation decision register
For each page type, provide the decision, evidence, trade-off, dependency, risk, required approver, and reconsideration trigger.

6. Duplication and cannibalization matrix
Include proposed page or pattern, overlapping existing URL, shared elements, required unique elements, collision severity, canonical or consolidation recommendation, and evidence needed to resolve uncertainty.

7. Reusable field dictionary
Include field name, definition, example value derived only from supplied data, source of truth, data type, requirement status, validation, fallback, omission behavior, refresh rule, and owner.

8. Page brief specification
Provide the URL, metadata, H1, page purpose, audience, intent, unique proposition, content modules, conversion elements, trust signals, media requirements, accessibility notes, internal-link plan, citation requirements, and structured-data eligibility. For each content module, include its objective, required inputs, claim constraints, conditional logic, and acceptance check.

9. Generation and editorial rules
List grounded-writing requirements, prohibited outputs, localization rules, duplicate-content controls, human-review points, and stop conditions.

10. Internal-link and citation plan
List confirmed links separately from proposed opportunities. Include source-page type, destination, rationale, anchor guidance, evidence status, citation need, and ownership.

11. Pilot and measurement plan
Define sample selection, baseline data needed, leading and lagging indicators, review windows, comparison method, rollback or consolidation triggers, and the person authorized to approve expansion. Do not promise ranking or traffic gains.

12. Verification and acceptance register
Use columns for check, expected observation, actual observation from supplied evidence, evidence location, status, owner, and unresolved action. At minimum, test intent-to-page alignment, unique-value coverage, source-data completeness, metadata collisions, competing URLs, canonical consistency, broken or orphan links, citation support, rendered conditional sections, structured-data eligibility, mobile readability, accessibility basics, conversion tracking requirements, and compliance with the stated success criteria. Use only the statuses passed with evidence, failed, blocked, not run, or not applicable.

13. Handoff and approval record
Separate recommendations ready for review, blocked items, work not performed, required approvals, and the smallest safe next action. Never describe a page, link, schema item, test, deployment, or approval as completed unless the corresponding action occurred and its evidence is present.