GEO audit checklist: the access layer of Answer Engine Optimization (AEO)

A GEO audit checklist covers the technical access layer of Answer Engine Optimization (AEO). It checks whether answer systems can fetch, read, and reuse a page before they evaluate its answer.

This checklist is for operators. Each check names what to verify, why it matters, and how to confirm it in one command or one view. Run it against https://yoursite.com from top to bottom.

1. Rendered-page legibility

Verify: the raw HTML response contains your actual copy, not an empty shell.

Why it matters: generative engines work from fetched text. If the response is a loading spinner and a script tag, there is nothing to read, quote, or cite.

Check it:

curl -s https://yoursite.com/ | sed -e 's/<[^>]*>//g' | tr -s ' \n' ' ' | head -c 600

You should recognize your headline and first paragraphs in that output. If you see mostly whitespace or boilerplate, the page is not legible to a text-first fetcher.

2. Server-rendered content, not client-only

Verify: the content that matters exists in the HTML before any JavaScript runs.

Why it matters: some AI crawlers execute little or no JavaScript, and even the ones that render pages give hydrated content less reliable treatment. Client-only rendering makes your most important pages invisible to the least patient readers.

Check it:

curl -s https://yoursite.com/pricing | grep -c "the exact plan name you show on screen"

A count of zero means that copy only exists after client-side rendering. Move it into the server-rendered response.

3. robots.txt allows AI crawlers

Verify: robots.txt does not block GPTBot, ClaudeBot, or PerplexityBot from the pages you want cited.

Why it matters: a disallow rule is a hard stop. No amount of content quality recovers a page the crawler is forbidden to fetch. Blanket-blocking AI crawlers quietly removes you from generative answers.

Check it:

curl -s https://yoursite.com/robots.txt

Read the rules for GPTBot, ClaudeBot, and PerplexityBot by name, then the User-agent: * fallback. index365.co allows AI crawlers on every public route and disallows only authenticated dashboard paths, and the policy is generated from application code rather than a hand-edited file. Auth should protect private data. robots rules should invite readers.

4. llms.txt presence and freshness

Verify: https://yoursite.com/llms.txt exists, returns 200, and describes the site you run today.

Why it matters: llms.txt is a curated inventory for AI readers: what the site is, which pages matter, and where an agent should start. A missing file wastes the one surface built for this audience. A stale one is worse, because engines act on wrong information confidently.

Check it:

curl -s https://yoursite.com/llms.txt | head -20

Confirm the product names, links, and claims match the live site. index365.co generates its llms.txt from application code, so the inventory updates when routes and products change instead of rotting in a static folder. If yours is a static file, put a review date on it and treat drift as a bug.

5. Canonical URLs

Verify: every key template emits one self-consistent canonical URL.

Why it matters: engines consolidate signals per canonical URL. Conflicting or missing canonicals split your identity across www, trailing-slash, and query-string variants, and the engine may cite the version you least want.

Check it:

curl -s https://yoursite.com/ | grep -o '<link rel="canonical"[^>]*>'

The canonical should be absolute, HTTPS, and identical to the URL you promote. Repeat on one product page and one article.

6. Structured data on key templates

Verify: your home, product, and article templates emit valid JSON-LD.

Why it matters: structured data gives engines typed facts instead of inferred ones. An Article with dates, an Organization with a name and logo, a Product with real attributes: these are the fields engines can trust without guessing.

Check it:

curl -s https://yoursite.com/ | grep -c 'application/ld+json'

Then paste the page URL into a schema validator view and read the parsed output. Zero blocks on a key template is a finding. Invalid JSON in a block is a worse one.

7. Heading semantics

Verify: one H1 per page, and H2s that describe the sections under them.

Why it matters: headings are the outline an engine uses to segment your page into answerable chunks. A page with four H1s, or with styled divs instead of headings, reads as one undifferentiated blob.

Check it:

curl -s https://yoursite.com/ | grep -o '<h[123][^>]*>' | sort | uniq -c

Expect exactly one H1 and a sensible count of H2s. Then read the H2 texts alone and ask whether they summarize the page. That is exactly how a machine will read them.

8. Answerable page sections

Verify: each major section opens with a sentence that could stand alone as an answer.

Why it matters: generative engines lift spans of text, not whole pages. A section that starts with a direct, complete statement is quotable. A section that starts with three sentences of wind-up gives the engine nothing to extract.

Check it: open your top three pages and read only the first sentence under each H2. If that sentence does not answer the heading, rewrite it so it does. This is a view check, not a command, and it is the highest-leverage edit on this list.

9. Sitemap lastmod accuracy

Verify: sitemap.xml lists your real URLs and the lastmod dates reflect actual changes.

Why it matters: crawlers use lastmod to budget refetches. Dates that never change tell engines your content is frozen. Dates that update on every deploy without content changes teach engines to ignore your signal entirely.

Check it:

curl -s https://yoursite.com/sitemap.xml | grep -A1 '<loc>' | head -20

Pick one URL you know changed recently and one that did not. Both lastmod values should match reality.

10. Status codes and redirect hygiene

Verify: promoted URLs return a clean 200 without redirect chains.

Why it matters: every redirect hop spends crawl budget and adds a failure point. Chains of two or more hops, or a 200 page whose canonical points somewhere else, dilute the URL identity an engine builds.

Check it:

curl -sIL -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}\n" https://yoursite.com

You want 200, zero or one redirect, and a final URL that matches your canonical.

11. OG and meta completeness

Verify: every public template has a title, meta description, and Open Graph tags that describe the page truthfully.

Why it matters: titles and descriptions are the densest summary an engine reads, and OG data is reused in previews wherever your page gets cited. Empty or duplicated descriptions across templates flatten your pages into one indistinct entry.

Check it:

curl -s https://yoursite.com/ | grep -Eo '<meta (property|name)="(og:[a-z:]+|description|twitter:[a-z]+)"[^>]*>'

Repeat across templates and compare: each page should describe itself, not repeat the homepage.

12. Fact parity across surfaces

Verify: the facts on your rendered page, your structured data, and your llms.txt agree.

Why it matters: engines cross-check. A plan priced one way in visible copy and another way in JSON-LD is a contradiction, and engines resolve contradictions by trusting your site less. Parity is a trust signal that costs nothing but discipline.

Check it: pick your three most-cited facts, such as product names and prices, and grep each surface for them. Any mismatch is a finding with a one-line fix.

Check the supported signals

Marketing Signal checks supported access and page-readiness signals inside one Page Check. It returns the current score, category results, reasoning, and scoped fix prompts.

See what Marketing Signal checks. For the citation-focused pass, use the Answer Engine Optimization audit checklist.