seo-geo-audit

name	seo-geo-audit
description	Use when auditing a website or blog for technical SEO and AI-answer-engine discoverability (GEO) — checking whether ChatGPT, Perplexity, Gemini, Claude and Google can crawl, understand, and cite a site. Covers canonicals, hreflang, structured data, robots.txt, llms.txt, edge caching, sitemaps, and AI-crawler access.

SEO / GEO Audit

Overview

Audit a live site for technical search and AI-answer-engine discoverability, and emit the result as a single evidence-bearing table.

You already know general SEO. This skill exists for the parts that get missed: checks that require fetching the site a specific way rather than reading its markup, and facts that changed recently. Run references/checks.md — it is the check list and the report skeleton in one.

Core principle: a check is not done until you have the bytes. Reading a robots.txt that allows PerplexityBot is not evidence that PerplexityBot can fetch the site. Fetch it as PerplexityBot and compare.

When to Use

• "Audit my site for SEO", "why doesn't ChatGPT cite us", "GEO audit", "AI visibility"
• Before or after a blog launch, migration, or CDN change
• When a site is technically fine but absent from AI answers

Not for: content/editorial quality, keyword research, backlink analysis. Those are different jobs — say so explicitly rather than silently skipping them.

Workflow

1. Scope it. Identify the canonical host, one representative article URL, the index/listing URL, and every language variant. Audit at least one article and one listing page — they differ in structured data.
2. Gather evidence first, judge second. Work through references/checks.md top to bottom, running the stated command for each check and saving the output. Do not skip a check because the answer seems obvious from markup you already read — several checks exist precisely because markup lies.
3. Emit the table (contract below). One row per check in the reference, including the ones that passed.
4. List what you could not check. Anything needing owner-level access (Search Console, Bing Webmaster, GA4, real-user Core Web Vitals, backlinks) goes in a short closing list, not in the table.
5. Offer a PDF (optional). Only if the report is a deliverable for someone else, and only if asked — do not generate one unprompted.

PDF Output — strictly optional

The markdown table is the deliverable. The audit is complete without a PDF. Never make the report conditional on PDF tooling, never install anything to produce one, and never withhold or delay findings because rendering failed.

If the user asks for a PDF:

node scripts/report-to-pdf.mjs report.md audit.pdf --site example.com

Requirements are Node (any version from the last few years) and any Chromium-based browser already on the machine — Chrome, Chromium or Edge. There are no npm dependencies, no npm install, and no framework involved; the script imports only node:fs, node:child_process and node:path.

Degrade in this order, and say which one happened:

Situation	What to do
Chrome not found	The script writes the styled HTML anyway and exits 2 with its path. Hand over the HTML — it prints to PDF from any browser
Browser present, wrong path	Re-run with CHROME=/path/to/chrome
No browser at all	Run with --html and deliver the HTML
Node not installed	Deliver the markdown table. That is the deliverable; do not install Node to make a PDF

Escape literal | inside table cells as \| or the row splits into the wrong number of columns. The renderer unescapes them.

Report Contract

The deliverable is one markdown table, plus a one-line verdict above it and the could-not-check list below it. No sections, no narrative write-up.

Column	Contents
Check	The check name from references/checks.md, verbatim
Pass/Fail	PASS · PASS* · FAIL · WARN · ABSENT · N/A
Severity	P1 breaks indexing or citation · P2 real measurable loss · P3 polish · — for PASS · N/A where the check does not apply
Action	One imperative sentence, specific to what you observed
Evidence	Verbatim observed bytes — one header line, tag, or command output. Never a paraphrase

Every row carries all five cells. No blanks. A PASS row still states its severity (—) and an action — what to keep doing, so it does not silently regress ("Keep the apex 301; re-test after any DNS change"). An N/A row states why it does not apply ("Single-language site"). A cell you cannot fill means the check was not really run — go run it.

Two verdicts exist because the obvious four are not enough:

• ABSENT — a [bet]-tier item is missing. Never score this as FAIL. llms.txt, FAQPage, .md alternates and RSS are optional bets; a site without them is not broken. Severity is always P3. Write the action as an offer ("optional — add if cheap"), not a defect.
• PASS* — the check passes on its own terms but something adjacent undercuts it. Say both halves in the action. The canonical example: bot and human get the same content, so there is no cloaking — but both are an empty JS shell, so the pass buys nothing. PASS* on cloaking, FAIL on C5.

Row order: FAIL/WARN first sorted by severity, then PASS*, PASS, ABSENT, N/A.

Keep evidence cells short — one header line or one tag. If output is long, truncate with … rather than reflowing it into prose.

Confidence Tiers

references/checks.md tags every check with a tier. Carry the tag into the Action cell when it is not [proven], so the reader knows what they are buying:

• [proven] — documented behavior, or it plainly breaks something. State plainly.
• [bet] — plausible, unmeasured, cheap. Say "cheap bet, unproven" in the fix.
• [contested] — official docs downplay it, field experience disagrees. Say so and give both sides.

Do not upgrade a [bet] to a recommendation because it would make the report look more decisive.

Common Mistakes

• Auditing markup instead of behavior. Half these checks require a specific request — a bot user-agent, a second fetch, a bare-apex hostname. Reading HTML cannot answer them.
• Reporting only failures. Passes belong in the table; they are what tells the owner not to regress.
• Stale facts. Several things changed in 2026 (see references/checks.md). Trust the reference over your training data.
• One page audited. Article and listing pages carry different schema and often different cache rules.