An AEO audit checklist for B2B SaaS websites

Choose the pages and questions before auditing

List the pages that support a real buying decision: the product overview, high-value use cases, integrations, security or compliance explanation where relevant, comparison pages, pricing, and documentation. Map each page to a buyer question and stage. A generic AEO landing page cannot substitute for product facts scattered across the site.

Choose a small fixed question set from sales calls, Search Console queries, support tickets, and competitive comparisons. Record exact wording and target page. This becomes the baseline for later answer observations rather than a one-time collection of favorable prompts.

Build a question-to-page map a SaaS team can maintain

Begin with the questions that arise before a buyer books a demo. A project-management product might need to explain its permission model, migration path, integrations, and the difference between a free plan and a trial. A security product might need to explain data residency, retention, and the scope of a compliance claim. These are examples of information needs, not suggested claims to publish without product review. Give each question one primary page and one person who can verify the answer.

Include the exact query or customer wording, the decision stage, a current URL, the best answer on that URL, and whether the answer requires a salesperson to interpret it. If the answer exists only in an old PDF, a sales deck, or a support reply, decide whether a public page should carry an approved version. A visitor and a search system should be able to find the relevant fact without knowing your internal document names.

Audit related pages as a path, not isolated URLs. A use-case page can introduce a workflow and link to a product capability page for specifics; the capability page can link to implementation documentation; the documentation can link back to the commercial explanation. The links should describe the destination in ordinary language. This helps a buyer move from a broad question to evidence while giving crawlers a route to the same pages.

Sources for this section: Google: creating helpful, reliable, people-first content, Google: AI features and your website.

Pass 1: access, indexing, and internal discovery

Check the canonical URL, HTTP response, robots directives, noindex and snippet controls, rendered main content, sitemap inclusion, and in-content links. In Search Console, compare indexed status with a live URL test. The live test checks current access but does not guarantee index inclusion or predict Google's canonical choice.

Google says an AI Overview or AI Mode supporting link must be indexed and snippet-eligible. It also says no special AI schema or AI file is required. For ChatGPT search, check whether OAI-SearchBot can access the page according to OpenAI's publisher guidance; treat that as a separate platform check.

Sources for this section: Google: AI features and your website, Google: URL Inspection tool, OpenAI: Publishers and Developers FAQ.

Pass 2 and 3: answer coverage and verifiable facts

For each target question, find the page section that answers it directly. Can a buyer learn who the product is for, what it does, how it integrates, what constraints apply, and what action to take next? Replace broad claims with specific capabilities, prerequisites, and limits. Keep current information visible in text, not solely inside a graphic or demo video.

Separate evidence from interpretation. If you mention a performance result, give a source, period, metric definition, and limitations where publication is permitted. If those facts are private, use process examples clearly labeled as examples instead of invented percentages or anonymous outcomes that cannot be checked.

• Product: category, audience, core jobs, differentiators, and limitations are explicit.
• Comparison: the actual selection criteria and tradeoffs are stated fairly.
• Proof: claims have a public method, source, or clearly marked example.
• Navigation: related product and help pages link to each other with descriptive anchor text.

Sources for this section: Google: creating helpful, reliable, people-first content, Google: AI features and your website.

Write findings as evidence, impact, and a proposed fix

A useful audit finding is reproducible. Record the inspected URL, date, current response or rendered state, the question it should answer, and the source of the observation. Then describe the buyer impact and the smallest change that can address it. For example: a comparison page loads, but its only pricing difference is inside an image; add a visible, current explanation of the relevant plan limits and ask the product owner to approve it. That is more actionable than assigning the page a low content score.

For technical issues, keep Search Console's indexed view and live test separate. The indexed view describes Google's known version and selected canonical; the live test checks whether Google can access the page now. If the live test succeeds after a fix, document the fix and wait for recrawl before calling the indexing problem resolved. For content issues, save the before-and-after section and source of each product fact. For answer observations, save the exact question, answer, date, search mode, and linked URL. A screenshot without those conditions is hard to interpret later.

Use a confidence column. A blocked page supported by a live error is a high-confidence technical finding. A missing brand in one AI answer is a low-confidence observation because answers vary. The confidence rating is about the quality of evidence for the diagnosis, not a prediction that a fix will earn a citation. This distinction keeps the team from spending a sprint on one unusual response while leaving confirmed page defects unresolved.

Sources for this section: Google: URL Inspection tool, Google: Generative AI performance report.

Pass 4 and 5: observe answers and business signals

Run the fixed buyer questions in the actual search experiences you want to study, where access and terms allow. Save the prompt, date, region, language, search mode, answer, brand mention, recommendation, and linked source URL. A single answer is a sample, not an overall ranking. Keep Google's AI-feature impressions, consumer answer samples, attributed referrals, and leads in separate series.

In GA4, verify your important key events and inspect the AI Assistant channel and Session source / medium for identifiable assistant referrals. Google AI Overview traffic is part of Organic Search, not that assistant channel. A referral can help prioritize the landing page, but it does not prove which answer caused the lead. Log each proposed fix with an owner and recheck date, then repeat the same question set after the change.

Sources for this section: Google: GA4 Traffic acquisition, Google: GA4 default channel group, Google: Generative AI performance report.

Prioritize by buyer impact and confidence

Put blockers first: a broken or noindexed revenue page, a missing product answer for a frequent buyer question, or an untracked demo event. Next, improve pages where the evidence suggests a realistic opportunity. Save the original finding and the completed change so a later review can distinguish implementation from outcome.

The downloadable worksheet leaves status and evidence fields blank on purpose. It does not imply your site passed or failed any item, and it can be reused for each page or product line.

Turn the audit into a four-week work plan

In week one, confirm analytics ownership, freeze the buyer-question set, and inspect a small number of revenue pages. Fix severe access defects and missing key-event tracking before interpreting performance. In week two, work with product and sales to verify facts on the most important page: supported integrations, plan constraints, setup requirements, and the outcome the feature actually enables. Publish the approved answer where it belongs, then connect it to related pages with useful links.

In week three, repeat the same consumer search questions and record what changed. Compare them with Search Console and GA4 in separate columns. If a page is newly indexed but is still absent from an answer sample, there may be no technical issue left to fix; examine whether the page actually answers that question better than the sources shown. In week four, review completed changes and remaining uncertainties with the page owner. Decide which question or URL gets the next cycle. This cadence is a planning example, not an expected timetable for Google to crawl or show a page.

Define an acceptance check for every task. A developer can confirm the intended canonical, HTTP status, robots directives, and rendered text. A product reviewer can confirm the public accuracy of a capability statement. An analyst can confirm that a key event fires and appears under the correct source scope. An editor can verify that the revised page leads with an answer and cites its primary source. Those checks establish that the work was done correctly; search visibility remains a later outcome to observe.

Sources for this section: Google: URL Inspection tool, Google: GA4 default channel group, Google: AI features and your website.