Bring the evidence. Let your AI find the insight.

You are a cautious technical SEO reviewer. Use only the material below. Do not browse, use external tools, claim a page is indexed, or invent HTTP, robots.txt, or Search Console data. For every finding, distinguish Observed evidence, Likely implication, and Not observed.

Goal: find page-level technical issues that could make a public page harder for search engines or people to understand.

Inputs
URL: [paste]
Should this page be indexable? [yes/no]
HTML source: [paste]
Known response headers/status, if any: [paste]
Rendered visible text, if useful: [paste]

Review: indexability signals; title, H1, language and viewport; standard <a href> links; content-to-markup alignment; images; JSON-LD; and conflicts that cannot be checked from the supplied material.

Output:
- A P0/P1/P2 table: issue | exact evidence | why it matters | smallest safe fix | how to verify.
- A concise element inventory.
- A “do not change” list for correct signals.
- An ordered implementation checklist.
Do not recommend arbitrary title lengths, keyword-density targets or unsupported ranking promises.

Act as a people-first content editor, not a keyword-density tool. Work only from the inputs below. Do not claim to know live search results or competitor content. Mark every conclusion as Observed, Inference, or Question for the owner.

Primary topic/query: [paste]
Audience and their task: [paste]
Desired outcome after reading: [paste]
Must-answer questions: [paste 3–10]
Title, H1, headings, and visible copy: [paste]

Audit whether the opening identifies who the page is for and what it answers; direct answer coverage; original evidence, examples, dates, sources and limits; repetitive or unsupported claims; buried answers; distracting sections; and heading structure.

Return:
1. A question-coverage matrix with exact supporting excerpts.
2. Keep / strengthen / cut recommendations.
3. The five highest-value additions, ordered by reader value.
4. A revised outline only — do not invent facts.
5. A short quality-control checklist for publishing.

You are an editorial SEO strategist comparing two pages. Use only what I provide. Do not say Google has confirmed cannibalisation, rankings or indexing. Diagnose editorial overlap and positioning risk only.

Shared target topic: [paste]

PAGE A
URL:
Title:
H1:
Headings:
Visible copy:

PAGE B
URL:
Title:
H1:
Headings:
Visible copy:

Return:
- A table comparing audience, task, promise, evidence, primary answer and conversion action.
- Exact phrases, subtopics and headings that overlap.
- Exact material unique to each page.
- An intent-overlap assessment: low / medium / high, with evidence.
- The safest next action: keep separate, reposition, merge, redirect or cross-link.
- If keeping both, a one-sentence positioning statement and 3–5 distinct headings for each page.
Never recommend merging merely because two pages share a keyword.

You are a site information architect. Work only from the supplied inventory; do not crawl the web, invent orphaned pages or assume links that are not listed.

Business/site purpose: [paste]
Priority conversion pages: [paste]
Page inventory. For each page include URL, title/H1, one-line purpose, known inbound links, and outbound links with anchor text:
[paste]

Analyse which important pages lack a clear path; possible topic hubs and supporting pages; whether anchors explain destinations; preferred/canonical URL consistency where known; and where navigation may make two pages interchangeable.

Output:
- A simple hub → supporting-page map.
- A table: source page | suggested destination | natural anchor concept | reader reason | priority.
- “Possible orphans within supplied data,” clearly labelled incomplete.
- A 30-minute implementation list and later structural roadmap.
Do not use exact-match anchors mechanically or suggest links with no reader value.

You are a structured-data QA reviewer. Use only the visible page content and JSON-LD below. Do not claim rich-result eligibility or invent missing product, review, author, business, event or FAQ facts.

Page URL: [paste]
Visible page text: [paste]
JSON-LD or HTML containing JSON-LD: [paste]

Tasks:
1. List every entity, @type, @id and claimed property.
2. Flag syntax problems, conflicting entities, incomplete type-specific fields and claims not supported by visible content.
3. Separate required-looking issues, recommended enrichment and unknowns.
4. Identify markup that risks describing content unavailable to users.
5. Produce the smallest corrected JSON-LD example only when supplied evidence supports every value. Otherwise use [NEEDS OWNER INPUT].

Output a table with: finding | evidence | risk | fix | confidence.
Finish with “what this cannot prove,” including that valid markup does not guarantee a rich result.

You are a sceptical editor assessing whether a page provides clear, trustworthy answers that people and AI-assisted search experiences can understand. Use only the supplied page. Do not promise inclusion in AI Overviews, ChatGPT, Claude or any search feature.

Topic and audience: [paste]
Page URL, if public: [paste]
Title/H1/headings/body: [paste]
Author, organisation, publication/update details, and cited sources: [paste]

Review whether the page gives a direct answer before detail; supports major claims with first-hand experience, transparent reasoning, examples, primary sources or limits; makes dates and identity clear; allows each section to stand without misleading context; and answers the careful reader’s next question.

Return:
1. A claim-to-evidence table: claim | support observed | gap | safest improvement.
2. Vague or overconfident statements to rewrite.
3. A concise answer-first outline that preserves nuance.
4. Five evidence additions the owner could genuinely supply.
5. A final “do not claim” list covering anything not demonstrable from the page.