GEO checklist: A practical audit for AI search

A GEO checklist is a practical way to assess whether your website can be found, understood, and used as a source in AI search. Start with access and eligibility, then check the accuracy of your content and business information. Finish by measuring what actually changed. Each item needs evidence and an owner; a completed checklist alone does not demonstrate stronger visibility.

GEO stands for generative engine optimization. The work concerns how your content or brand appears in generated answers, including whether a page receives a source link and whether the answer represents your offering correctly. Those outcomes deserve separate checks. A product recommendation with the wrong eligibility conditions can create problems even when it puts your brand in front of a potential customer.

Begin with the questions your audience needs answered. Someone comparing software platforms needs different information from a customer troubleshooting an existing subscription. Select the pages that support those decisions and identify the AI experiences you want to examine. A small, relevant starting group makes findings easier to act on and explain than a sitewide score built from unrelated checks.

Include questions that mention your brand and questions that do not. Branded questions help assess whether your business is represented accurately. Category and use-case questions help examine discovery among competing options. Keep the two groups separate in reporting. Otherwise, a strong result for people who already know your name can obscure weak visibility during the earlier stages of product research.

Record language, market, platform, date, and the complete question with each observation. If web search or another retrieval option was available, record that too. An English query about a US service should not inherit the assumptions of a Turkish product page. Save the answer and its source URLs rather than keeping only a screenshot or a single presence score.

This checklist combines official documentation and GEO guides; prioritization, ownership, and evidence-based closure are practical recommendations. Use the following checks on your selected page group. For every finding, record the status, supporting evidence, owner, and next review date. Explain anything that does not apply.

• Define your target AI experiences and customer decisions; separate branded questions from category and use-case questions.
• Save baseline answers with their date, language, market, platform, and source URLs; flag incorrect business information separately.
• Confirm priority URLs return the expected content successfully without requiring a login or presenting an unexpected verification screen.
• Review robots rules, page directives, and HTTP headers together; identify restrictions that conflict with your visibility policy.
• Check Google indexing, the selected canonical URL, and the property's Search generative AI participation setting.
• Distinguish search crawlers, training crawlers, and user-initiated fetches; document access decisions for each purpose.
• Examine CDN, firewall, and bot-protection behavior to ensure intended access is not blocked outside your robots configuration.
• Verify important headings, explanations, prices, and conditions are readable after processing; do not rely only on visual appearance.
• Align sitemap entries, redirects, canonical signals, and internal links around the intended current URL for each page.
• Review language versions and market applicability; avoid directing readers to conditions that belong to another country.
• Check that each priority page answers its main question early and includes the conditions needed to make a decision.
• Compare alternatives using consistent criteria; disclose relevant pricing, limits, exclusions, availability, and service requirements.
• Attach sources, periods, and scope to numerical claims; distinguish illustrative calculations from observed business performance.
• Identify the author or reviewer where appropriate; remove experience claims and credentials that cannot be verified.
• Use consistent business and product names; add enough context to distinguish similarly named services and different versions.
• Reconcile prices, eligibility, service regions, and support information across pages with the responsible product owner.
• Validate structured data against visible content; exclude ratings, reviews, or business details that the page cannot substantiate.
• Connect relevant pages around the reader's next question; verify that internal links reach the intended live destination.
• Verify external sources at claim level; trace recycled research findings back to their original evidence where possible.
• Record native platform metrics with their definitions and coverage; do not combine incompatible measurements into one total.
• Examine identifiable AI referral visits and relevant actions; state what missing referral information prevents you from measuring.
• Log changes by date and URL; retain a consistent question group and comparable conditions for follow-up observations.
• Assign ownership for outdated facts and inaccurate representation; reopen affected checks when important product conditions change.
• Close work with evidence, then assess visibility, representation accuracy, and business outcomes as separate results.

Not every check deserves the same treatment on every website. A local retailer needs accurate location information; a software business may need detailed integration limits instead. Mark an irrelevant item as not applicable and record why. Keep that status distinct from an unresolved issue. This makes later reviews easier when the business adds a service, changes markets, or expands the audit scope.

Opening a page in your browser demonstrates one access path. It does not prove that a crawler receives the same response or that important information survives processing. Inspect the response status, returned content, and rendered page where relevant. If a price or eligibility condition loads separately, test that part explicitly. Capture failures with the affected URL and the conditions under which they occur.

Google also provides a separate participation control. Its Search generative AI control documentation describes how inclusion works, including inheritance from parent properties. Record the effective setting for the property being audited. A child property's inherited preference may explain a result that page-level inspection misses. Treat this as a policy check, and obtain the appropriate business decision before changing the setting.

Crawler names need similar care. OpenAI's bot documentation distinguishes OAI-SearchBot, which supports search, from GPTBot, which may collect content for model training. Allowing training is not a prerequisite you should assume from a search visibility objective. Review access purpose by purpose. Ask the technical team to verify the intended route rather than removing all bot protection across the site.

Perplexity's crawler documentation also separates its search crawler from user-initiated requests. Use the platform's published identification information when examining server logs or firewall rules. A user-agent label alone is insufficient evidence that a request genuinely comes from the named service. Record the response received by verified requests and retain the investigation outcome with the access finding.

For each page, identify the decision a reader should be able to make after visiting. Then check whether the page supplies the necessary conditions. Consider a hypothetical scheduling product that advertises team booking. A useful explanation would clarify supported calendars, account requirements, and relevant limits. The example illustrates a review method; it does not describe an actual product or claim that a particular format earns citations.

Comparisons require the same discipline. Evaluate alternatives using shared criteria and disclose when the available information is incomplete. A table that compares your current price with a competitor's outdated promotion can mislead even if every row looks tidy. Product owners should verify changing commercial facts. Editors should check that those facts stay consistent across landing pages, support articles, and comparison content.

Evidence belongs close to the claim it supports. If a report studied a particular platform, time period, or question sample, keep those limits in the explanation. Do not convert an experimental improvement into a promised result for every business. When several articles repeat the same finding, they still share one evidence origin. Trace that origin before using the figure in your own content.

Prioritize by the decision affected, the seriousness of incorrect information, and the number of pages involved. A shared template problem can justify an earlier fix than an isolated editing issue. The table below gives examples of findings and acceptance evidence. It is a planning aid, with no universal timing thresholds or promise that closing an item produces an AI citation.

Give each task one accountable owner and a clear acceptance condition. Technical teams can resolve access problems, while product teams verify commercial facts and editors improve explanations. A ticket marked done without the tested URL or result leaves the next reviewer guessing. Retain enough evidence to distinguish a confirmed fix from an implementation that has not yet been checked in the intended environment.

Google's Generative AI performance report documents impressions for supported Search features and provides page, country, device, and date views. It does not measure your presence across every AI service. Use its definitions when comparing periods, including the different aggregation rules for property and page views. An account-specific absence of data also needs investigation rather than an immediate conclusion that your pages are ineligible.

The Bing AI Performance announcement describes citation counts and cited pages across supported experiences. Those measurements are different from Google's impressions. Keep separate trend lines and document each report's coverage. A citation count does not tell you the prominence of the source inside an answer or establish that a user read it, preferred your product, or visited your website.

For visits with identifiable AI referrals, examine the actions that matter to the business. A documentation publisher might care about useful engagement; a product site might care about sign-ups or qualified enquiries. Calculate conversion rates using the defined visit group. The site's marketing calculators can help with the calculation framework, but the quality of the result still depends on attribution and a correctly defined denominator.

Manual question tracking adds context that aggregate reports can miss. Repeat a stable question group under comparable conditions and retain the answers. As a hypothetical example, source links in six of twenty recorded answers mean a thirty percent linked-source rate for that observation group. They do not establish market share or describe what all customers saw. Always report the sample and explain what the percentage represents.

Write a hypothesis before changing a page. For example, a team might expect that clarifying an integration requirement will reduce inaccurate descriptions in its recorded answers. Specify the affected pages, the change, and the observation method. If access, copy, pricing, and navigation all change together, the result may still be useful, but attributing it to a single intervention becomes much harder.

The A/B test library offers examples of specifying a variable and a primary metric. Apply that discipline while recognizing that AI answer monitoring often involves observational comparisons rather than randomly assigned users. Similar unchanged pages can provide context when a suitable comparison exists. Seasonality, campaigns, and platform changes remain possible explanations for a difference between the before and after periods.

Google's official optimization guide says its Search features do not require special AI files, tiny content chunks, or special schema markup. Do not mark llms.txt as a mandatory Google visibility requirement. If another system gives you a specific reason to test such a file, define that use case and measurement. Keep the experiment behind verified access problems and inaccurate customer information.

Avoid making every possible wording of a question into a separate article. Closely overlapping pages create additional places to maintain product facts, and outdated copies can contradict current terms. Review whether each page serves a distinct reader need before expanding the inventory. Sometimes the most useful change is consolidating an explanation, removing an obsolete link, or asking the product team to resolve an unclear condition.

Reopen relevant checks when prices, eligibility, service regions, integrations, or templates change. Match the review schedule to the pace of change, with additional checks for important product events. Minor wording edits do not require repeating the entire research process. Keep dated evidence from previous reviews so the team can identify when an inaccurate statement appeared and whether the correction reached the affected pages.

A completed review should leave you with an actionable record: accessible pages, verified facts, observed representation, and separately measured customer actions. Use that record to choose the next task. Close findings that have evidence, keep uncertain results open, and preserve their limitations. This is what makes a GEO checklist useful across technical, editorial, and product teams as the website and its audiences change.