AEO audit checklist

Set the audit boundary before scoring pages

A useful audit answers a business question: which pages should explain a service, product, policy, or topic accurately when customers research it? Start by naming the site or section, audience, markets, conversion or trust goal, and the answer surfaces you will actually examine. Separate Google Search features from other assistants; their retrieval and reporting are not interchangeable.

Google’s AI features guidance says there is no special technical checklist for AI Overviews or AI Mode: pages must meet Search technical requirements and be eligible for a snippet, but inclusion is never assured. That makes this audit a way to find fixable weaknesses, not a promise of placement. For the complete process context, use the Rankwox AEO audits hub and its companion readiness test.

1. 01Choose the site section and business outcome in scope; do not begin with every URL on a large site.
2. 02Name the target audiences, locations, languages, and a short list of answer experiences that matter.
3. 03Record audit date, data sources, sampled URLs, and exclusions so a later review can reproduce the baseline.
4. 04Separate observed evidence (for example, a blocked page) from interpretation (for example, a page may be hard to cite).

Build a question and page inventory

Create a small, representative query set before opening a crawler. Include the questions that expose different content jobs: definitions, comparisons, procedures, eligibility or policy details, and local or product specific questions where relevant. Pair each question with the page that should own the answer. Mark duplicates, unanswered questions, and pages that compete for the same intent. Then sample priority URLs rather than assigning equal effort to every page. For each one, record its audience, primary question, canonical destination, owner, last meaningful update, and next action.

A page that attracts visits but does not resolve the reader’s decision may need a content change; a useful page that is orphaned may need better linking. Use the content gap analysis guide to expand this map without multiplying near identical pages. Google recommends useful, distinctive content organized for readers; it cautions against creating large quantities of pages merely to target query variations in its generative AI search guidance.

The original GEO benchmark study reports that tested optimization strategies varied by domain, which is a reason to validate priorities on the site and market being audited rather than copy a universal recipe.

Check access, indexability, and page identity

Before rewriting prose, verify that important URLs load reliably and expose the intended content. Review status codes, redirect chains, robots.txt rules, meta robots and X Robots Tag directives, canonical tags, sitemap inclusion, mobile rendering, and whether internal links lead to the final preferred URL. Inspect representative pages in Search Console: compare the user facing page with the crawled or indexed version, and check whether the declared canonical and Google selected canonical differ.

A page can have polished content yet remain unavailable to a crawler because of access controls, a noindex directive, rendering failure, or a conflicting duplicate. Conversely, passing a technical check does not mean a page will be indexed or shown. Google’s technical requirements and AI features documentation makes that distinction explicit. Record the evidence and affected URL, then assign the fix to the right technical owner; do not label every indexing delay an AEO failure.

1. 01Test representative URLs in the browser and with a crawl; note errors, blocked resources, and redirect destinations.
2. 02Check robots directives, canonical selection, index status, and rendered main content in URL Inspection.
3. 03Confirm that the intended text is present in rendered HTML and not hidden behind an inaccessible interaction.
4. 04Review navigation and contextual internal links to ensure important pages are reachable from relevant hubs.

Review answer quality, evidence, and entities

Read each sampled page as a person arriving with one question. Does the opening make a direct, qualified answer clear, or does it delay the answer with generic scene setting? Does the rest of the page explain conditions, exceptions, terminology, and next steps so that a short extract would not become misleading? Check that the subject is named instead of relying on vague pronouns; product names, organizations, experts, locations, and relationships should be consistent with the facts on the page.

Then inspect the important claims: identify which are first party statements, which rely on external evidence, who is responsible for accuracy, and what would make the claim stale. A useful answer is not necessarily the shortest one. It is complete enough to preserve caveats when quoted out of context. Google’s people first content guidance for generative search favors useful, distinctive material and clear organization; it does not endorse a fixed answer block length or a guaranteed citation formula.

Note factual gaps and unsupported claims rather than inventing proof.

1. 01Write the primary question beside the page and highlight the sentence that answers it most directly.
2. 02Check whether the answer states scope, prerequisites, exceptions, and date sensitive details where needed.
3. 03Trace high impact claims to a primary source, documented method, or responsible subject matter owner.
4. 04Resolve conflicting names, descriptions, product facts, and location details across related pages.

Validate structured data and internal relationships

Treat structured data as a consistency check, not a shortcut to visibility. Inventory what is present, choose only types that describe real visible content, and verify that names, URLs, authorship, dates, and other marked up properties agree with the page. Confirm the JSON LD parses, that the page is crawlable, and that a relevant Google test recognizes supported search features when applicable.

A valid Schema.org type does not automatically qualify a page for a Google rich result, and Google explicitly says correct markup does not guarantee a display. Its structured data policies also prohibit marking up content that readers cannot see or data that misrepresents the page.

For instance, a visible FAQ may be represented as a Schema.org FAQPage, but the markup should mirror the real questions and answers; it should not be added to manufacture a ranking signal. Check the internal graph too: a page should link naturally to its parent hub and genuinely relevant sibling resources, with descriptive anchors that help a reader anticipate the destination.

1. 01Compare each markup item with the page’s visible text and remove stale, hidden, irrelevant, or unsupported properties.
2. 02Validate syntax and any Google supported result type separately; a clean test is not a performance guarantee.
3. 03Check breadcrumbs, canonical URLs, and stable identifiers for consistency across the page and site.
4. 04Use contextual internal links to connect the audit to schema validation and related implementation guidance.

Test answers with a repeatable observation protocol

For answer surfaces where no suitable aggregate report answers your question, manual checks can reveal how a page is represented, but they are observations not a controlled ranking experiment. Fix the query wording, market, language, device context, date, and tool or product version as far as practical. Save the exact prompt or query, the response, visible source links, and whether the answer was correct, incomplete, or misleading. Repeat checks over time and distinguish no appearance from an answer that appears without a link.

Do not treat one response as proof of a durable platform rule: results may vary by query, context, and time. For Google, use official Search Console reporting where available rather than inferring AI Overview performance from isolated searches. Google explains that AI Overviews and AI Mode eligibility rests on Search requirements, and that results vary across AI features in its site owner documentation.

For a focused protocol and test log, connect this page to how to test AEO readiness.

Prioritize findings and report measurable change

A checklist is valuable only when it produces an ordered, owned backlog. For each finding, state the affected question and URL, evidence, user or business consequence, proposed action, owner, effort, and verification method. Prioritize a critical access defect ahead of cosmetic wording; among content improvements, favor high value questions with clear evidence gaps and a plausible fix. Keep risk and confidence visible rather than hiding them inside one opaque score.

Build a baseline before release, annotate major changes, and rerun the same site checks and question set after implementation. On Google, the Generative AI performance report in Search Console reports impressions for AI Overviews and AI Mode and can group data by pages, countries, dates, and devices. Its documented dimensions do not provide a query grouping, and an impression is not a citation quality or conversion metric.

Pair that report with conventional search performance and analytics outcomes, where measurable, and maintain a separate manual answer quality log for questions those reports cannot answer. See AEO KPIs and tracking for a measurement design.

1. 01Create a finding record with evidence, impact, confidence, effort, owner, and a testable completion condition.
2. 02Choose a short priority list that teams can implement; group related fixes by technical, editorial, data, or governance owner.
3. 03Track available Search Console impressions separately from clicks, conversions, citation observations, and answer accuracy.
4. 04Compare like for like dates and queries, document changes in coverage or reporting availability, and avoid attributing every movement to one edit.
5. 05Revisit the question map and retire or refresh entries when products, policies, sources, or user needs change.