---
title: "The AI Readiness Review: The Complete Checklist for Getting Cited by AI"
slug: /ai-readiness
description: "A 59-check, weighted AI Readiness review covering crawlability, LLM-readable surfaces, structured data, entity clarity, content extractability, trust signals and off-site corroboration — including a dedicated audit for a robust About page."
author: "AEO Engine"
last_updated: "2026-10-28"
---

# The AI Readiness Review

**Everything we check when we ask: can an AI engine find this site, understand it, trust it, and quote it?**

AI visibility is not a separate internet. Google AI Overviews, AI Mode, ChatGPT Search, Perplexity, Copilot and Claude all read the same web your customers read. What changes is the *mechanics* of being read: which crawlers you admit, whether your facts are typed rather than implied, whether a page can be lifted cleanly into an answer, and whether the entity behind the page is legible and corroborated.

This is the full list. It is written so a marketing lead, an SEO, and a developer can all work from the same document. Every item states what we check, what passing looks like, why it matters, and the smallest fix.

It also includes the check most audits still miss: **a robust About page** — the page that is quietly outperforming homepages in AI answers for brands that invested in it.

---

## The one principle that shapes this entire review

Before the checklist, the framing, because it changes which fixes are worth doing.

We do not recommend building a separate website for LLMs. We do not recommend shadow markdown clones of your site, hidden text "for the AI", or a special page no human would ever want to read. Those create an easily gameable surface, and no major AI vendor has asked for them. Google, OpenAI and Anthropic have consistently pointed at the same thing: readable, well-structured, trustworthy pages that already serve humans.

The strongest AI visibility asset is usually a page that would pass an editor's review in 2015. It is comprehensive, specific, well-organized, current, and clearly owned by a named, credible entity.

### The About page signal

Here is the pattern worth internalizing. On an enterprise brand's site, the page with the most impressions in Google Search Console's Gen AI report — five times the homepage — was the **About page**.

Not a landing page. Not a page built for LLMs. A long, detailed, visually normal page covering the company's history, background, and evolution over time.

Why does that happen? Because AI answers are largely *entity* answers. When a model needs to describe who a company is, how long it has operated, who runs it, what it has done, and whether it is a real, durable thing, the About page is the densest concentration of exactly those facts on the entire domain. It is also usually the page where those facts are stated in prose a human wrote, with dates, names, and specifics — which is precisely what an extraction step needs.

That is the GEO recommendation hiding in plain sight: **make the entity obvious.** Build a comprehensive, accurate, human-readable About page, keep it current, and mark it up properly. It outperforms the clever workaround, and it keeps compounding because it is also the page buyers read before they trust you.

The rest of this document is the full system around that insight.

*Canonical: https://aeoengine.ai/ai-readiness*

---

## How the review is scored

Fifty-nine checks across nine weighted categories, plus an optional advanced track. The score is an index, not a grade: it tells you where the next hour of work buys the most visibility.

| Category | Weight | What it covers |
|---|---|---|
| F — Foundations | 15 | Fetchable, indexable, canonical, stable, semantic HTML |
| R — Crawl & AI policy | 10 | robots.txt, named AI user agents, sitemaps, Content-Signal |
| M — Machine-readable surfaces | 15 | llms.txt, llms-full.txt, per-page markdown, feeds, Link headers |
| S — Structured data & entity markup | 15 | JSON-LD coverage, Organization/Person/Article, sameAs consistency |
| E — Entity & About page | 15 | Depth, accuracy, history, leadership, authorship, entity corroboration |
| C — Content extractability | 12 | Answer-first structure, stats, definitions, freshness, citability |
| T — Trust & security | 8 | HTTPS/HSTS, CSP, security.txt, TDM signals |
| O — Off-site corroboration | 5 | Third-party mentions, profiles, consistency |
| X — Measurement | 5 | GSC Gen AI report, prompt-level citation probes |
| **Total** | **100** | |
| D — Advanced discovery (bonus) | +10 | MCP, A2A, Agent Skills, NLWeb, WebMCP, ARD, DNS-AID, schemamap |

**Verdict bands**

- **90–100 — AI-ready leader.** Defensible. Optimize for citation quality and coverage.
- **75–89 — Ready.** Strong substrate; remaining gaps are usually content depth or entity clarity.
- **55–74 — Mostly ready.** Machines can read you, but they cannot confidently attribute facts to you.
- **35–54 — At risk.** You are being crawled without being understood. Citation share will lag competitors with worse content.
- **Under 35 — Not ready.** Fix foundations before spending anything on content or links.

**Blocker rule:** any open **P0** item caps the verdict at *Mostly ready* regardless of score. A site that cannot be fetched, or that blocks the crawlers it wants, has no AI visibility problem to optimize — it has an access problem.

Priority labels used throughout: **P0** = blocks AI visibility outright; **P1** = high-leverage, do this quarter; **P2** = polish and defense; **P3** = optional / emerging.

---

## F — Foundations (15 points)

The substrate every model and crawler depends on. Nothing downstream survives a failure here.

**F1 · P0 · Page returns 200 over HTTPS at a stable final URL**
What we check: status code, redirect chain length, final URL, TLS validity and expiry.
Pass: single 200, no more than one permanent redirect, valid cert, no mixed content on the primary template.
Why: a redirect chain is a lossy path. Each hop is a chance for a crawler to record a different URL than the one you cite.
Fix: collapse to one canonical host (apex or www, pick one), 301 everything else, renew certs on a schedule.

**F2 · P0 · Stable URLs**
What we check: sampled URL set against the last 90 days of 404s, redirect maps, and CMS slug changes.
Pass: previously published URLs still resolve, or permanently redirect to a genuine equivalent.
Why: URLs are public contracts. Breaking them invalidates citations, bookmarks, and agent caches — and an AI answer that cites a dead URL is an answer you lost.
Fix: never recycle a slug; add redirects at publish time, not at audit time.

**F3 · P0 · Indexable core pages**
What we check: `noindex` directives, meta robots, X-Robots-Tag, accidental `Disallow` overlap, JS-only rendering of primary content.
Pass: homepage, About, services/products, and primary category pages are indexable and contain their main content in the initial HTML.
Why: if the text arrives only after client-side hydration, some crawlers see an empty shell.
Fix: server-render or pre-render core templates; keep primary copy in HTML.

**F4 · P1 · Semantic document structure**
What we check: `lang`, exactly one H1, `main` element, heading order, landmark elements.
Pass: valid `lang`, one H1 matching page intent, no skipped heading levels in the body, `main` present.
Why: structure is how an extraction pipeline decides what is a section, a summary, or a footnote.
Fix: template-level corrections, not per-page patching.

**F5 · P1 · Title and meta description quality**
What we check: uniqueness across the sampled set, length, presence of the entity name, absence of boilerplate duplication.
Pass: unique titles, entity + topic + qualifier, 50–60 characters; descriptions 140–160 characters that state the value plainly.
Why: titles and descriptions are the cheapest summary an engine can quote.
Fix: generate from a template with real per-page variables.

**F6 · P1 · Canonical discipline**
What we check: self-referencing canonicals, canonical vs. hreflang vs. sitemap agreement, parameter handling.
Pass: every indexable page self-canonicalizes; no canonical points to a redirect or a 404; paginated series handled deliberately.
Why: conflicting canonicals split the entity's evidence across duplicate URLs.
Fix: fix at the template level; audit faceted and parameterized URLs separately.

**F7 · P1 · Crawl performance and Core Web Vitals**
What we check: TTFB, LCP, CLS, INP on mobile templates, render-blocking assets.
Pass: LCP under 2.5s, CLS under 0.1, INP under 200ms on the primary templates.
Why: primarily a human-experience and crawl-budget tax, and AI crawlers are not generous with slow origins.
Fix: image compression, font strategy, defer non-critical JS.

**F8 · P2 · Sitemap accuracy**
What we check: sitemap presence, freshness of `lastmod`, inclusion of only 200-status canonical URLs, index structure at scale.
Pass: valid XML, only canonical 200s, `lastmod` reflects real content change.
Why: a sitemap full of redirects teaches a crawler to trust you less.
Fix: generate from published content, exclude noindex and redirected URLs.

---

## R — Crawl and AI policy (10 points)

Who is allowed in, and what you are telling them about usage.

**R1 · P0 · robots.txt exists and is syntactically valid**
What we check: fetchability, no wildcard catastrophe, no accidental site-wide block, correct directive syntax.
Pass: returns 200 `text/plain`, explicit `User-agent` groups, no `Disallow: /` outside intentional staging.
Why: a broken robots file is the most common cause of "we get no AI traffic".
Fix: one file, reviewed in version control, not edited live from memory.

**R2 · P1 · Named AI crawler policy is explicit**
What we check: `User-agent` entries for the major named AI crawlers — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended, CCBot, Bytespider, Meta-ExternalAgent, Amazonbot — and whether the resulting policy matches business intent.
Pass: a deliberate allow/deny per agent, documented, with the business rationale attached.
Why: omission is not neutrality. Different crawlers treat silence differently, and you cannot answer "are we visible to ChatGPT" while leaving it ambiguous.
Fix: write the policy down, put it in robots.txt, review when vendors change user agents.
Note: search/answer crawlers and training crawlers are different decisions. Blocking training is legitimate; blocking answer engines is usually self-harm.

**R3 · P1 · Sitemaps referenced from robots.txt**
What we check: `Sitemap:` directive, absolute URLs, index coverage.
Pass: declared, absolute, resolves to a valid sitemap.
Fix: one line.

**R4 · P2 · Content-Signal directives (optional, emerging)**
What we check: presence of `Content-Signal:` declarations for search, ingest, and train.
Pass: present and intentional where the organization has a position on AI training.
Why: it makes your usage position machine-readable instead of implied.
Caveat: emerging convention (IETF AI Preferences / IAB proposal), not a ratified standard. Treat as a defensive nice-to-have.

**R5 · P2 · No accidental blocking of answer engines via WAF or CDN**
What we check: 403/418/202 responses to AI user agents, bot-management rules, geo-blocking, JS challenges.
Pass: target crawlers receive 200 with real content.
Why: enterprise WAF defaults routinely block AI crawlers, and the site owner never sees an error because humans are unaffected.
Fix: allowlist verified crawler ranges, or exempt the content paths.

**R6 · P2 · Crawl-budget hygiene**
What we check: parameter sprawl, infinite calendar/filter spaces, thin duplicate pages, orphan pages.
Pass: no unbounded crawl traps; important pages within three clicks of the homepage.
Fix: canonicalize, noindex thin variants, link your money pages from navigation.

---

## M — Machine-readable surfaces (15 points)

Conventions that let an engine pull your content as source instead of scraping your layout.

**M1 · P1 · `/llms.txt`**
What we check: presence at the root, valid markdown, curated (not dumped), links resolving, a one-line description of the entity at the top.
Pass: a short, human-maintained index of the pages that matter, each with a one-line summary and a live URL; discoverable via `<link rel="alternate" type="text/markdown">`.
Why: it is a curated map instead of a crawl guess. Note the status honestly: **a convention, not a standard.** llms.txt v2 makes it discoverable by link relation rather than by path guessing, which is the real improvement.
Fix: generate from your top 20–50 URLs; keep it current; never ship a 404 or a wall of links with no descriptions.

**M2 · P2 · `/llms-full.txt`**
What we check: presence, size, whether it duplicates pages or genuinely concatenates key content.
Pass: for small sites and documentation sets, a single concatenated file of the core corpus.
Why: one fetch beats twenty. Costly and low-value for large sites — we often recommend against it there.
Fix: build from the same source of truth as M1.

**M3 · P2 · Per-page markdown source endpoints**
What we check: `page.md`, a `.md` suffix on canonical URLs, or `Accept: text/markdown` content negotiation.
Pass: at least the key evergreen pages expose clean markdown.
Why: agents pull source instead of parsing HTML; you control the exact text they see.
Fix: add a build step that emits markdown alongside HTML.

**M4 · P2 · Feeds and typed endpoints**
What we check: RSS/Atom for content sites, JSON endpoints for structured data (products, locations, people).
Pass: feed exists, validates, includes full or near-full content, updates on publish.
Fix: most CMSs have this; turn it on and keep it un-truncated.

**M5 · P2 · HTTP `Link` header discovery**
What we check: `Link:` headers advertising llms.txt, sitemap, api-catalog, RSS.
Pass: present on HTML responses with correct `rel` values.
Why: an agent that never parses your HTML can still find everything.
Caveat: not controllable on some hosted platforms (notably Shopify Standard). Use HTML `<link>` tags in `<head>` instead and record the platform limitation.

**M6 · P2 · HTML `<link>` / `<a>` machine discovery**
What we check: `rel="alternate"`, `rel="sitemap"`, `rel="author"`, `rel="mcp"` where applicable.
Pass: machine resources are linked from the document, not just documented in a blog post.
Fix: add to the head template once.

---

## S — Structured data and entity markup (15 points)

Typed facts. This is where "the model guessed" becomes "the model knew".

**S1 · P1 · Valid JSON-LD present**
What we check: `application/ld+json` blocks, parse validity, schema.org type correctness, absence of conflicting duplicates.
Pass: parses cleanly, no placeholder values, one coherent graph per page.
Fix: validate in CI, not by hand.

**S2 · P1 · Organization markup on the site root**
What we check: `Organization` or `Corporation` with `name`, `url`, `logo`, `description`, `foundingDate`, `founder`, `sameAs`, `address`, `contactPoint`.
Pass: every field true and current; `sameAs` points to real, live profiles.
Why: this is the machine-readable version of your About page, and the anchor for entity resolution.
Fix: one canonical block on the homepage and About page.

**S3 · P2 · Person markup for leadership and authors**
What we check: `Person` entities with `name`, `jobTitle`, `worksFor`, `sameAs`, and links to author archive pages.
Pass: real bios exist and are linked; markup matches the visible text.
Why: E-E-A-T and AI answers both reward named, findable expertise.
Fix: author pages with real bios, then markup.

**S4 · P2 · Page-type markup matches the page**
What we check: `AboutPage`, `Article`/`BlogPosting`, `Product`, `Service`, `FAQPage`, `BreadcrumbList`, `WebSite` with `SearchAction`.
Pass: the type describes what the page actually is; no `FAQPage` markup on a page with no visible FAQ.
Why: mismatch is a trust signal in the wrong direction.
Fix: map templates to types, apply at the template.

**S5 · P2 · Dates in markup**
What we check: `datePublished`, `dateModified`, and visible dates agreeing.
Pass: dates are real, updated when content materially changes, never auto-bumped for freshness theater.
Why: freshness that is faked is detectable and costs credibility.
Fix: wire to the CMS edit timestamp, and actually edit.

**S6 · P2 · Entity consistency across the site**
What we check: legal name, trading name, address, phone, founding year, and leadership names identical across About, Contact, footer, schema, and social profiles.
Pass: one version of the truth everywhere.
Why: inconsistent entity facts are the main cause of a model describing you incorrectly or not at all.
Fix: a single canonical brand-facts block in the CMS, reused.

---

## E — Entity and About page (15 points) — the check most audits miss

This is the section the rest of the industry under-weights. If the About page is your highest-impression page in AI answers, it deserves a real audit, not a "does it exist" checkbox.

We score the About page on depth, specificity, structure, and corroboration — the four things that make it both human-credible and machine-extractable.

**E1 · P0 · An About page exists at a stable, linked URL**
What we check: `/about` (or `/about-us`, `/company`) returns 200, is reachable from the primary navigation and footer, and is not buried in a dropdown three levels deep.
Pass: one canonical About URL, linked sitewide, indexed, in the sitemap.
Why: it is the page an engine reaches for when asked who you are. Make it findable.
Fix: create it, link it, canonicalize it, then stop renaming it.

**E2 · P1 · Company history with real chronology**
What we check: founding year and story, key milestones with dates, origin of the name or product, evolutions, pivots, acquisitions, offices.
Pass: a dated timeline with at least 5–8 substantive milestones, each with a year and a specific event.
Why: this is exactly the fact pattern a model needs to answer "how long has this company existed", "what do they do now", "how did they get here". Undated claims are unusable.
Fix: interview the founders, pull the incorporation date, write the timeline. This is the highest-leverage content task in the entire review.

**E3 · P1 · Specific, verifiable facts rather than adjectives**
What we check: counts of employees, customers, locations, years in operation, product lines, certifications, awards, named markets.
Pass: numbers and names, each either public or explicitly labeled as company-reported.
Why: "leading provider" is unquotable. "Founded in 2009, 140 employees, operations in 6 countries" is quotable.
Fix: replace every superlative with a fact. Where a fact is unverified, label it.

**E4 · P1 · Named leadership with real bios**
What we check: founders and executives with full names, roles, tenure, prior background, and links to LinkedIn or personal sites.
Pass: each leader has a paragraph, not a job title; bios are consistent with Person markup and press mentions.
Why: people are the fastest entity-resolution shortcut a model has. Faceless companies get vague answers.
Fix: write real bios; add `Person` schema; link author pages.

**E5 · P1 · Clear statement of what the company does, in plain language**
What we check: a short, quotable definition near the top — what you sell, to whom, and the outcome.
Pass: one to three sentences that could be lifted verbatim into an answer without losing meaning. No jargon that requires the rest of the page to decode.
Why: this is the single most-cited sentence on most About pages.
Fix: write it first, before the history.

**E6 · P2 · Who you serve and how you are different**
What we check: named customer segments, industries, geographies, and a defensible articulation of difference.
Pass: specific segments and a differentiator that is a claim about method or scope, not "quality" or "passion".
Fix: one section each.

**E7 · P2 · Credentials, compliance and proof**
What we check: certifications, registrations, licenses, memberships, awards (with awarding body and year), security/compliance posture.
Pass: verifiable, dated, linked where possible.
Why: these are trust facts that models weigh and buyers check.
Fix: list them plainly; do not bury them in a badge carousel.

**E8 · P2 · Structure that survives extraction**
What we check: descriptive H2/H3s, short paragraphs, a scannable timeline, a leadership grid, an at-a-glance fact block.
Pass: an engine could reconstruct the company summary from headings alone.
Why: heading-based chunking is how modern extraction works.
Fix: add an "At a glance" block — founded, headquarters, leadership, employees, markets, products.

**E9 · P2 · Media and human quality**
What we check: real photography, office and team images, a designed layout, readable typography, mobile behavior.
Pass: a page a human would actually read and trust, not a wall of text.
Why: the whole premise is that the page serves humans first and is legible to machines as a side effect. Pages built awkwardly "for AI" are the ones that fail both tests.
Fix: invest in design here. This page is a sales asset too.

**E10 · P2 · Marked up and corroborated**
What we check: `AboutPage` + `Organization` JSON-LD on the page, `foundingDate`, `founder`, `sameAs`, and cross-checks against Wikipedia/Wikidata, LinkedIn, Crunchbase, press, and industry directories.
Pass: markup matches visible content; at least three independent third-party sources state the same founding year, leadership, and description.
Why: corroboration is what turns a self-description into an established entity.
Fix: fix inconsistencies off-site first, then markup.

**E11 · P3 · Kept current**
What we check: last meaningful edit date, whether leadership and headcount are stale, whether recent milestones are missing.
Pass: reviewed at least twice a year; updated within a month of a material change.
Why: a 2019 About page actively teaches models that you are smaller and older than you are.
Fix: put it on the content calendar as a recurring task, not a one-off project.

**About page red flags we mark down**

- A vision statement and three stock photos, no dates, no names.
- "Our team" with no names, or names with no roles.
- An About page that is really a sales landing page with a paragraph of history.
- Founding year that disagrees with LinkedIn, Crunchbase, or the footer.
- Leadership that changed two years ago and is still listed.
- A separate hidden "about page for LLMs" — this is the anti-pattern, not the fix.

**Minimum viable About page (if you have nothing)**

1. One-paragraph definition: what we do, for whom, since when.
2. At-a-glance block: founded, HQ, employees, markets, products, leadership.
3. Founding story: 300–600 words with real specifics.
4. Timeline: 6–10 dated milestones.
5. Leadership: 4–6 bios at 100–200 words each.
6. What we do / who we serve: two short sections.
7. Credentials and awards.
8. Contact and locations, consistent with the footer and Contact page.
9. `AboutPage` + `Organization` + `Person` JSON-LD.

Length is not the goal; specificity is. A tight 1,200-word page with dates and names beats a 4,000-word page of adjectives.

---

## C — Content extractability and citability (12 points)

Being readable is not the same as being quotable. These are the properties that make a passage lift cleanly into an answer.

**C1 · P1 · Answer-first structure**
What we check: does each key section lead with a direct answer before elaboration?
Pass: the first 40–60 words after a heading resolve the question the heading implies.
Why: extraction favors self-contained, front-loaded passages.
Fix: rewrite intros as answers; move context below.

**C2 · P1 · Self-contained passages**
What we check: whether paragraphs make sense without the surrounding page (pronouns resolved, entity named, units given).
Pass: a passage can be quoted alone and still be correct.
Fix: name the company and the subject in the first sentence of key sections.

**C3 · P1 · Specificity and statistics**
What we check: numbers, dates, named examples, methodology, sources.
Pass: claims carry a number, a date, or a citation; statistics name their source.
Why: specificity is what makes a page worth citing over a competitor's.
Fix: add one concrete data point per major section.

**C4 · P2 · Definitions and terminology**
What we check: does the page define the terms it uses, in the way the market searches them?
Pass: a definitional sentence for each key concept, in plain language.
Why: definitional passages get lifted into "what is X" answers constantly.
Fix: add a short glossary or inline definitions.

**C5 · P2 · Freshness with real updates**
What we check: visible dates, `dateModified`, and whether the content actually changed.
Pass: updated on a cadence tied to the subject's rate of change, with substantive edits.
Fix: a content refresh calendar per cluster.

**C6 · P2 · Authorship and expertise**
What we check: bylines, author bios, credentials, reviewer attribution on sensitive topics.
Pass: a named human with a real bio and relevant background.
Why: E-E-A-T and AI answer quality both lean on provenance.
Fix: real author pages, linked from every article.

**C7 · P2 · Internal linking to entity pages**
What we check: whether commercial and editorial pages link to About, leadership, methodology, and contact.
Pass: the entity pages are in the link graph, not orphaned.
Why: linking is how a crawler learns which pages define the brand.
Fix: contextual links from key pages plus sitewide footer.

**C8 · P3 · Multimodal clarity**
What we check: image alt text, descriptive filenames, captions, transcript availability, table structure.
Pass: alt text describes content; tables have headers; video has transcripts.
Fix: template-level alt enforcement; transcripts on media pages.

---

## T — Trust and security signals (8 points)

Boring, cheap, and used by both crawlers and procurement teams.

**T1 · P1 · HTTPS everywhere with HSTS**
Pass: no mixed content; `Strict-Transport-Security` with a sensible max-age.
**T2 · P2 · Content-Security-Policy present**
Pass: a real policy, not `unsafe-inline` everywhere.
**T3 · P2 · `X-Content-Type-Options: nosniff`**
**T4 · P2 · `Referrer-Policy` and `Permissions-Policy`**
**T5 · P3 · `/.well-known/security.txt`**
Pass: contact and expiry present. Signals a maintained security posture.
**T6 · P3 · TDM reservation (optional)**
Pass: a deliberate position on text and data mining, expressed in `tdm-reservation` header, meta tag, or `/.well-known/tdmrep.json`. Its force is legal, not technical — decide with counsel, not with the SEO.

---

## O — Off-site corroboration (5 points)

Models do not only read your site. They read what others say about you.

**O1 · P2 · Full-depth brand mention inventory**
What we check: up to 100 organic results for the brand across pages 1–10 of the SERP, excluding your own domain, classified by control: **editable** (official/claimable profiles), **influenceable** (community, UGC, reviews), **independent** (editorial, press, directories).
Why: you cannot fix a fact you have not inventoried, and page one hides most of the story.
**O2 · P2 · Profile consistency**
What we check: LinkedIn, Crunchbase, Wikipedia/Wikidata (if eligible), industry directories, review platforms — founding year, HQ, leadership, description.
Pass: identical facts across all claimable profiles.
**O3 · P2 · Entity anchors**
What we check: at least three independent sources that describe the company in comparable terms.
Why: corroboration is what makes an entity resolvable rather than merely present.
**O4 · P3 · Earned coverage with quotable facts**
What we check: press, podcasts, and interviews that contain specific, citable claims about the company.

---

## X — Measurement (5 points)

If you cannot see it, you cannot defend the budget.

**X1 · P1 · Google Search Console Gen AI visibility**
What we check: the Gen AI / AI Mode reporting, top cited pages and queries, and whether impressions concentrate on unexpected pages (About pages, comparison pages, docs).
Why: it is the only first-party view of AI-surface impressions at scale. The About-page outlier pattern above was found exactly this way.
**X2 · P1 · Prompt-level citation probes**
What we check: a fixed prompt set run across ChatGPT, Perplexity, Grok, Claude and Google AI, recording whether the brand is mentioned, cited, and described accurately.
Pass: a repeatable panel with a stable prompt list, tiered by intent — direct competitor comparisons, category authority, use case, and category awareness — run on a schedule.
**X3 · P2 · Competitor citation share**
What we check: the same prompts, scored for which competitors appear and which sources they cite.
**X4 · P2 · Answer accuracy audit**
What we check: whether the model's description of the company is correct — size, founding year, products, leadership.
Why: being cited incorrectly is worse than being omitted. It also tells you exactly which entity fact is broken.

---

## D — Advanced discovery (bonus, up to +10)

Emerging, mostly optional, and worth shipping only where the effort is small and the surface is genuinely public. Label these honestly as draft or emerging conventions — not requirements.

- **MCP server card** at `/.well-known/mcp/server-card.json`, plus a public, read-only MCP endpoint where your data is worth querying.
- **API catalog** at `/.well-known/api-catalog`.
- **A2A agent card** at `/.well-known/agent-card.json`, if you expose delegated agent behavior.
- **Agent Skills discovery** — a well-known URI listing short, scoped instructions. Draft, cheap.
- **NLWeb** — an `/ask`-style conversational endpoint advertised via `rel="nlweb"`.
- **WebMCP** — in-page tools via `document.modelContext`. Browser-native, experimental.
- **Agentic Resource Discovery** — `/.well-known/ai-catalog.json`.
- **DNS-AID** — SVCB/HTTPS records under `_agents.` with DNSSEC.
- **Schemamap** — `/schemamap.xml` indexing one JSON-LD endpoint per resource.
- **Universal Commerce Protocol** — `/.well-known/ucp` for stores that want agent-assisted checkout.
- **OKF bundle** — the corpus as typed markdown for one-fetch ingestion.

We score these as upside, never as a failure. A site with a superb About page and clean structured data will out-cite a site with a perfect MCP card and a vague entity.

---

## Platform-specific gotchas we check for

**Shopify.** Store pages are store-level records, not theme assets — a theme switch or admin cleanup can silently delete agent pages; verify every agent-readable URL returns 200 after any theme change. Dot-prefixed `/.well-known/*` paths generally 404 regardless of redirect configuration; use `/pages/<handle>` surfaces instead. Custom HTTP headers are not controllable on Standard, so use HTML `<link>` tags. Edge cache can serve stale content for minutes to hours after a change — verify without cache-busting before declaring a page live.

**WordPress.** Watch for SEO plugin canonical/sitemap conflicts, `noindex` left on from staging, page builders injecting content outside the main content element, and WAF rules returning 403 to non-browser user agents.

**Webflow / hosted site builders.** Limited header control, so lean on HTML discovery links and structured data; confirm custom code survives template updates.

---

## How we run the review

1. **Normalize** the target to its canonical origin and page path.
2. **Probe** the live site: status, headers, TLS, semantics, JSON-LD, robots, sitemap, llms.txt, llms-full.txt, feeds, and well-known endpoints.
3. **Pull the live reference checklist** (agent-readiness, plus SEO, well-known, and security categories for broader work) so the review reflects current guidance rather than remembered rules.
4. **Read the machine-readable files** rather than judging their existence — an llms.txt full of dead links is worse than none.
5. **Crawl** the site for stability, redirects, canonicals, orphans, and duplicate templates.
6. **Audit the entity layer**: About page against E1–E11, structured data against S1–S6, and off-site consistency against O1–O3.
7. **Probe the answer engines** with a fixed, tiered prompt set and record mention, citation, and accuracy.
8. **Score, rank by leverage, and hand back a punch list** — smallest correct fix first, with owners and effort estimates.

**Deliverables**

- Weighted score with blockers named.
- Evidence per item: URL, header, or file content — not opinions.
- A prioritized fix list split into *this week*, *this quarter*, *defensive*.
- An About-page scorecard with the specific missing facts listed.
- A before/after prompt panel so the next run has a baseline.

---

## The 30/60/90

**First 30 days — access and truth**
Fix fetchability and canonicalization. Write and publish the AI crawler policy. Get sitemaps right. Audit the About page against E1–E11 and commission the missing history, dates, and bios. Publish Organization markup. Run the first prompt panel so you have a baseline.

**Days 30–60 — structure and surfaces**
Ship the About page rewrite with `AboutPage` + `Person` markup. Publish a curated llms.txt. Fix answer-first structure on the top 20 revenue pages. Add author pages and bylines. Standardize entity facts across all claimable profiles.

**Days 60–90 — depth and defense**
Expand the content that earns citation: definitions, comparisons, methodology, original data. Add per-page markdown where the build supports it. Add security headers and security.txt. Re-run the prompt panel; compare against baseline. Add the advanced discovery surfaces only where they are cheap and real.

---

## What we deliberately do not recommend

- **A separate site or shadow pages for LLMs.** No vendor asked for it, it fragments your entity, and it is trivially gameable by competitors and by you.
- **Hidden text, prompt injection, or invisible instructions.** Detected, penalized, and reputationally expensive.
- **Keyword-stuffed llms.txt files.** It is an index, not a stuffing surface.
- **Freshness theater** — auto-bumping dates without editing content.
- **Fake or embellished About pages.** Invented founding stories and unnamed "advisors" are the fastest way to make a model describe you incorrectly.
- **Treating draft conventions as standards.** MCP, A2A, NLWeb, WebMCP, ARD, DNS-AID and Agent Skills discovery are genuinely interesting and mostly optional. Ship them for capability, not for score.

---

## The short version

Be findable. Be typed. Be specific. Be attributable. Be corroborated.

Then make the About page the best page on the site, because it is the page that answers "who are you" — to a buyer and to a model at the same time.

---

*Reference standard for agent-readiness items: [specification.website](https://specification.website/). llms.txt, Content-Signal, MCP, A2A and related surfaces are conventions or emerging proposals, not ratified standards, and are labeled as such throughout. This document is a living checklist; the review is re-run as vendors change crawler behavior and answer surfaces.*