The working playbook for being found by search engines and quoted by answer engines — generated from topic-seo-geo.yaml (OI-074).
Being found by Google was the old game. Being QUOTED by ChatGPT, Perplexity, and Gemini is the new one — and it runs on the same foundations. This page is the working playbook, built from Session 23's deep extraction and kept practitioner-first for Paul's own sites.
updated 2026-08-28
| Term | What it means here |
|---|---|
| SEO | Search Engine Optimization — ranking in Google-class search. The point system: quality content answering real questions, backlinks, domain authority, correct H1/H2 structure, image metadata, keywords. |
| AEO | Answer Engine Optimization — structuring content so a real question gets answered clearly enough for an AI to USE your answer. Effectively the same discipline as GEO. |
| GEO | Generative Engine Optimization — making first-party knowledge easy for LLMs to retrieve, cite, and represent correctly. The engines: ChatGPT, Claude, Gemini, Perplexity, Google AI mode. |
| The relationship | SEO is the FOUNDATION of GEO. LLMs behave as 'very good RAG' over everything crawlable about you — the same signals that rank you decide what the model learned about you. Do both; they share ~90% of the work. |
The five-minute audit for any site: search your core topic in Google, then ask the same question in ChatGPT (and Perplexity). Compare how the site is represented in each. The gap between the two representations is the GEO backlog. Corollary from Session 23: "whatever Google discovers, that becomes the answer the next time someone asks on ChatGPT."
The machine-readable front door — a fixed, finite checklist every site either has or lacks. Eligibility, not merit: the skill's own disclaimer is "it does not guarantee AI citation, ranking, or crawling. It does not replace public evidence." Files live in the repo and ship with the site.
| File | Role |
|---|---|
| robots.txt | Access policy. Must ALLOW the AI crawlers by name — GPTBot, ClaudeBot, PerplexityBot. Blocking them is opting out of the answer layer. |
| llms.txt | Short first-party identity — who this site is, in AI-readable form. |
| llms-full.txt | Extended catalog for agents needing richer route and service detail. |
| humans.txt | Stewardship and site context for human readers. |
| .well-known/security.txt | RFC 9116 security contact. A trust signal; missing on most sites (including the trainer's, until the audit added it). |
| sitemap.xml | The page map crawlers walk. Generated, current, referenced from robots.txt. |
| ai.txt / ads.txt | The trailing set — present where applicable. |
Order of operations: Access first (robots.txt), description second (llms.txt) — an identity file behind a blocked crawler is invisible.
Session 23's most useful split. His technically perfect site scored 64/100 — "strong access, weakest at authority." Budget the two tracks separately or the plateau after the technical pass looks like failure.
The working procedure — audit as a skill, remediation as an agent, run INSIDE the repo so the auditor sees source truth and can fix what it finds.
What it found live: What the loop found on the trainer's own production site, live: 148 pages crawled-but-not-indexed, apex and www both returning 200 (split identity, canonical mismatch), missing security.txt, schema misalignment — defects invisible for the site's whole life, fixed within the session.
A cohort member's audit: her homepage "returns only 3 words to crawlers." Client-side JavaScript builds the page AFTER the HTML arrives — crawlers and LLM scrapers reading the initial response get an empty app shell: no text to quote, no metadata, no Open Graph, no schema. "The site can look perfect visually while being weak for SEO and GEO." This is the defect class Paul's TanStack Start migrations exist to fix — and the CRAWLER-VIEW WORD COUNT is the measurable before/after metric for every migration.
The test: Fetch the page's raw HTML (no JS) and count meaningful words. Under ~50 on a content page = the shell problem.
The scenario every agency hits: the client's site is outdated but its blog has years of accumulated SEO, and their first objection to a redesign is 'how will you protect it?' The Office Hours XI answer, distilled — the equity lives in URL + content + structure signals, so a reskin must hold the first two fixed and only then modernize the rest.
Visibility without operations is a leaky bucket — Session 24's half of the week. The owned-audience machine that GEO traffic should land in.
Tools and artifacts to track — snapshots of a weeks-old discipline; verify before depending.
| Item | Why it's here |
|---|---|
| skills.sh SEO Auditor + the community GEO-first skill | The two audit skills from Session 23; run in-repo. Links in the harvested session attachments. |
| Firecrawl | The crawler for auditing sites you don't own — reads the front-end surface engines see; branding-scrape mode also generates design.md brand files. |
| PolarMirror (as heard) | Cohort-built AEO/GEO audit product — brand visibility across ChatGPT/Perplexity/Gemini/AI Overviews vs 5 competitors, 3-tier reports with 30/60/90-day plans. Sighted twice in 48 hours (sprint showcase + independently). Evaluate before building equivalents. |
| SEMrush / Ahrefs | The pre-AI keyword-intelligence incumbents — still the trainer's picks above Google Trends. |
| The Session 23 attachment pack | 18 harvested documents: AEO/GEO audit guides, both agent-harness variants (Ego Browser / Vercel Agent Browser), prompt + verification checklists, his own site's remediation report. In the media library under week9-12-attachments. |
| The $8 gated audit-report tool | Built live in Session 23 (Firecrawl + both skills + dashboard + paywall UI), MIT on GitHub — the audit-as-product pattern, and a plausible agency offering. |
The standing per-property checklist, in order of cost.