The AEO audit, end to end, on a sample site

An AEO audit has five stages: scope, access, crawl, triage, and re-crawl. Scope decides which pages and which questions count. Access confirms the crawlers you care about can fetch those pages at all. The crawl scores every URL. Triage turns the findings into a short, ordered list of fixes. The re-crawl proves each fix landed and nothing else broke. Skip a stage and the audit still produces a document, but not one you can defend.

This post walks all five on one site. The site is acme-robotics.com, which is fictional: it is the demo dataset behind the interactive crawl on this site’s homepage, a 20-URL industrial-robotics site with a product line, documentation, a blog, and a few neglected corners. Every URL, score, and finding below comes from that demo. Nothing here describes a real company.

The method is the one in How to audit a site for AEO and GEO, applied rather than described. Where that guide explains why each stage exists, this one shows what each stage produces.

Stage 1: What is in scope?

Scope is three decisions written down before anything is crawled: which hosts and sections, which questions the site should be able to answer, and what counts as done.

For Acme, the scope note read like this:

The question list is the part most audits skip, and it changes everything downstream. A finding on a page that answers one of those four questions is worth more than the same finding on a page that answers none of them. Write the questions from sources you have: question-phrased queries in Search Console, the support inbox, the sales team’s most common objections. Four to ten is enough.

“Done means” protects you at the end. Without it, an audit finishes when someone stops reading the report.

Stage 2: Can the crawlers reach the pages?

Access comes before content, because a page a crawler is told not to fetch gets nothing from any other fix. Do this stage by hand before the crawl. It takes fifteen minutes and it frames everything else.

1. Read robots.txt on every host in scope. For each AI crawler that matters to the client, note which paths it is disallowed from. Acme’s file disallowed every AI crawler from /products/arm-x9/downloads and disallowed GPTBot from /careers/.
2. Ask whether each block was deliberate. The /careers/ rule may have been a decision. Record who made it. The downloads rule turned out to be a leftover from a time when datasheets were gated.
3. Check the Google side separately. Google’s AI features use Googlebot, and eligibility depends on indexing and snippet directives rather than any AI-specific crawler. AI Overviews eligibility has the four checks.
4. Fetch one page per template as a bot. How to check whether AI crawlers can actually reach you covers the requests and what a CDN block looks like in the response.

The output of this stage is a short list of access findings with a decision attached to each: fix, or accepted with a name and a date.

Stage 3: The crawl

Run a quick scan first. It reads the raw HTML, which is what most AI crawlers receive, and it is fast enough to re-run freely. Switch to a deep scan only if the site is client-rendered and important links appear only after JavaScript runs (Scan modes covers the difference). Acme is server-rendered, so the whole audit used quick scans, and the re-crawl will too.

Before reading any number, note what the crawl did not score. Acme’s crawl found 20 URLs and scored 16 of them. The other four were two 301 redirects (/blog and /products), one 404 (/docs/v1/quickstart, linked from three pages), and a PDF. Redirects, errors, and non-HTML responses read as “not scored” rather than zero, so they don’t drag the averages down (The Overview & grid). The 404 is still a finding; it just isn’t averaged in.

The Overview for the 16 scored pages, all fictional demo values:

The spread matters more than the averages. Five pages scored 80 or better on AEO: the homepage, two documentation pages, the ARM-X9 product page, and a solutions page. Four scored below 35: the downloads page, careers, /tag/uncategorized, and a legacy support portal. A site average of 60 describes none of them.

Stage 4: Triage

Triage turns a list of findings into a list of fixes. Do it in three passes: group, separate, then order.

Group by fault, not by page. Acme’s sixteen findings collapse into seven fault classes, most of which trace to a template or a single decision:

Seven rows is a meeting. Sixteen findings across twenty URLs is a spreadsheet nobody opens twice.

Separate the pages with low scores and no findings. Three Acme pages scored below 50 on GEO without a listed finding: /about (46), /case-studies/nordic-logistics (44), and /docs/troubleshooting (49, with schema marked Partial). A low lens score with no Critical or Warning means several signals each earned partial credit. Open the GEO tab in the detail panel and read which ones. On pages like these the usual gaps are authorship, entity markup, and citations, and they need a person to look rather than a fix to paste. Author bylines and Person schema covers the first.

Order with severity and value. Prioritizing AEO fixes: severity × page value scores five of these same Acme findings in a spreadsheet, so the arithmetic isn’t repeated here. Its result is the order the audit used: the downloads-page block first (a gate on a page that answers a demonstrated question, fixed in one line), pricing second (no gate, but the highest-value page on the site), the legacy portal last despite having the lowest scores.

One rule from that post decides a lot of Acme’s order: on a single URL, clear the gate before anything else. Writing an overview paragraph for the downloads page while AI crawlers are disallowed from it changes nothing those crawlers can see.

Check the scope questions against the result. Each of the four questions should map to a page and a fix list. “What does the ARM-X9 cost?” maps to /pricing, whose answer is in images. “Payload and reach?” maps to /products/arm-x9/specs, whose first paragraph doesn’t answer it. “Is a cobot safe without a cage?” maps to the cobots blog post, whose answer appears after 420 words. “How do I troubleshoot a fault?” maps to /docs/troubleshooting, plus the legacy portal competing with it. If a question had mapped to no page at all, that would be a content gap, which belongs in the report even though no crawler finds it.

Stage 5: Fix, then re-crawl

Write each fix as a ticket a developer or editor can complete without reading the audit. A ticket has five fields:

The last field is what makes the audit re-runnable. A fix without a verification method is closed when someone says it is done.

After the fixes ship, re-crawl the same site in the same scan mode. In GEOBee, the project’s Re-crawl captures a fresh snapshot, and Compare lines it up against the baseline (Projects & compare). Read the result in this order:

1. Regressed rows first. A template change that adds Product markup to pricing can break another page that shares the template. A regression found in the diff costs ten minutes; one found by a client costs more.
2. Removed rows. The 404 should be gone, replaced by a redirect, which will read as not scored. If the legacy portal was merged and redirected, it leaves the scored set too. Both are intended. A Removed row you didn’t plan is a page that broke.
3. The Critical delta. Fewer Criticals is the good direction. Every Critical that remains should map to an accepted row in the triage sheet.
4. Improved rows last. These are confirmation, not news.

Expect lens scores to move in proportion to the weights, not to the effort. Lifting the downloads-page block restores one GEO signal worth 10 of 100 (the three lenses). The page stays weak until the thin content is fixed too. Explain this before the re-crawl, or the first question in the review meeting will be why a fix that took a week moved the score by ten points.

Removing a page from the scored set also moves the averages, in a direction unrelated to quality: dropping the legacy portal raises the site average whether or not anything else improved. Report per-page deltas next to the averages so nobody mistakes one for the other.

What the deliverable contains

The finished audit is short. It has the scope note from stage 1, the access decisions from stage 2, the crawl summary from stage 3 with the not-scored URLs listed, the fault-class table and ordered fix list from stage 4, and the compare summary from stage 5. Attach the exports: the CSV for scores, the JSON for every finding with its fix.

It doesn’t contain a prediction about citations, because the audit can’t support one. What it can support is narrower: on these dates, these pages could not be fetched, parsed, or lifted from, and now they can. That claim is checkable, and it is the one an audit should make.

To run the same five stages on your own site, download GEOBee. The 7-day trial includes projects, re-crawl, and compare.