The short answer
A public website does not become visible to AI search in one step. A system has to discover a URL, fetch it, decide whether to index it, understand what the page says, and select it when a relevant question arrives. Passing one stage does not prove the next.
That distinction changes the audit. If a crawler cannot fetch a product page, rewriting its copy is premature. If the page is indexed but never answers the questions a buyer asks, submitting the sitemap again will not repair the content. A useful GEO audit locates the first broken stage, assigns the right owner, and defines evidence that can close the finding.
Start with the visibility states
Imagine a team checking a new service page. The browser returns a polished page and the deployment is green. Search Console may still report that Google has not discovered the URL, has discovered but not crawled it, has crawled but not indexed it, or has indexed it without showing it for the questions the team cares about.
Those outcomes belong to different layers.
- Published means the intended production URL serves the page.
- Discovered means a search system knows the URL exists through links or a sitemap.
- Crawled means its crawler successfully fetched the resource.
- Indexed means the system processed the page and retained it in an index.
- Surfaced or cited means the page was selected for a particular result or answer.
Traffic and inquiries sit further downstream. Analytics may record a visit from a search result or an AI citation. A form or CRM may record an inquiry. Neither event should be folded into a vague “visibility score.” Code completion, indexing, impressions, clicks, and commercial conversion need separate evidence.
Google's own description of Search makes the same core distinction between crawling, indexing, and serving results. It also states that compliance with technical requirements does not guarantee that a page will be crawled, indexed, or served. That is a useful limit for any GEO plan.
Crawlability and indexability
Begin with one commercially important URL and inspect what an unauthenticated crawler receives. Record the status code, final URL after redirects, robots directives, canonical link, initial HTML, and internal links. Then compare that response with a live URL test in Search Console.
Robots rules, sitemaps, and canonical annotations solve different problems. Robots rules control which resources a crawler may request. A sitemap suggests URLs that the site considers important. A canonical annotation expresses a preferred representative among duplicate or similar URLs. Google treats sitemap submission and canonical preferences as signals, not commands.
The signals should agree. If navigation links point to one URL, the sitemap lists another, and the page declares a third canonical, the audit has found a concrete remediation task. The task is not “improve SEO.” It is to align those references on the production URL and verify the fetched response afterward.
JavaScript adds another checkpoint. Google can render JavaScript, but rendering is a separate processing stage, and not every crawler runs scripts. Put the product definition, core answer, and meaningful links in the HTML response whenever the architecture allows it. Also test the CDN and web application firewall. A normal browser session does not prove that a crawler avoids bot challenges, rate limits, or a 403 response.
OpenAI gives publishers a similarly narrow instruction for ChatGPT search. Content intended for summaries and citations should not block OAI-SearchBot. Allowing access creates an opportunity for discovery; it does not create a citation guarantee.
Buyer-question coverage
Once a page is fetchable and indexable, read it as a buyer would. Many corporate pages name a category and make a broad promise, then leave the decision-making questions unanswered.
A strong commercial page should make it possible to locate answers to questions such as these.
- What operational problem does the product address?
- Who is it for, and when is it a poor fit?
- What data, access, and human review are required?
- What does the customer receive?
- How is the result verified?
- What happens when the system is uncertain or fails?
- What are the deployment, privacy, cost, and responsibility boundaries?
Do not turn this into a generic FAQ factory. Match each important page to the questions it is qualified to answer. A service page may explain fit and delivery. A product page may explain inputs, outputs, and limitations. An evidence page may support a claim with a reproducible method or a reviewed public artifact.
Google's current guidance for generative AI features prioritizes useful, reliable, non-commodity content and warns against treating GEO labels or special files as shortcuts. The practical test is whether a reader can make a better decision after reading the page. Original constraints, methods, evidence, and trade-offs do more work than another summary of familiar advice.
Entity clarity and citation readiness
The next pass follows facts across the site. The company name, product name, service description, official domain, contact route, and stated boundaries should describe the same entity on the home page, product pages, articles, and structured data.
Schema can clarify relationships among an organization, a service, and an article. It cannot rescue contradictory copy or manufacture evidence. If the visible page describes consulting while the structured record describes a software product, the first job is to resolve the underlying fact.
Citation readiness is equally concrete. A technical finding should point to an observed response, directive, or HTML element. A product claim should connect to an approved product description or public documentation. External claims should link to the original source. Customer outcomes, rankings, and citation gains should stay out unless the organization can substantiate them.
This is also where language variants need care. A reviewed English article should contain an English body, its own canonical URL, and reciprocal language annotations with the Chinese article. Translating the navigation while leaving the main article in Chinese creates a weak language variant and can confuse both readers and canonical selection.
Remediation ownership
An audit becomes useful when every finding can leave the report and enter someone's queue.
| Finding | Primary owner | Closing evidence |
|---|---|---|
| Important URL is blocked, challenged, or returns an error | Engineering or operations | Public fetch returns the intended response and live inspection can read it |
| Sitemap, internal links, and canonical disagree | Engineering and SEO | All three identify the same production URL |
| Indexed page misses a high-intent buyer question | Product and content | Approved answer and boundary appear on the intended page |
| Product or organization facts conflict | Business fact owner | Visible copy and structured data use the reviewed fact |
| Material claim has no traceable support | Content and evidence owner | Original source or explicit internal evidence is attached |
Priority follows dependency. Access failures come before copy refinements because they block every downstream stage. Among content gaps, start with questions tied to an actual buying decision. Give every task a URL, owner, expected change, verification method, and review date.
Boundaries
This audit applies to public company websites, service pages, product pages, articles, and reviewed public evidence. It should not expose pages that require credentials, contain access tokens, or hold customer-confidential material.
GEO work can improve the conditions for discovery, interpretation, and citation. It does not control a search provider's index or answer selection, and it cannot create product demand. It does not guarantee indexing, citations, rankings, traffic, or inquiries. A single model response is an observation at a particular time, not a durable performance result.
A practical audit sequence
1. Fix the scope
Choose the home page, core product or service pages, and a small set of supporting articles. Record the production URL, intended language, business owner, and buyer question for each page.
2. Test the discovery chain
Confirm that internal links and the sitemap expose the URL. Inspect robots rules, status codes, redirects, canonical annotations, initial HTML, and edge-security behavior. Use live URL inspection where account access is available. Request indexing once for an eligible priority page; repeated daily requests are not a substitute for diagnosis.
3. Map questions to evidence
For each page, list the questions it must answer and the evidence behind each answer. Separate approved product facts, delivery process, public documentation, and external primary sources. Remove unsupported promotional claims.
4. Assign remediation
Turn every gap into a bounded task with an owner and closing evidence. Engineering owns fetch and rendering failures. Product and content own buyer-question coverage. The person authorized to approve a company or product fact owns factual conflicts.
5. Verify with the same inputs
Fetch the same URLs again and repeat the same question set. Record deployment, index status, impressions, visits, and inquiries separately. If the external state has not changed, preserve that result and wait for a later crawl rather than presenting local validation as search performance.
Verification checklist
- Priority pages return the intended public response without authentication
- Internal links, sitemap entries, canonicals, and language annotations use production URLs
- Titles, summaries, main content, and meaningful links are available to crawlers
- Live URL inspection receives the expected page where Search Console access exists
- Each priority page answers at least one reviewed buyer question
- Organization, product, service, author, and contact facts remain consistent
- Material claims have traceable sources and unknown outcomes remain unknown
- Every remediation has an owner, priority, closing evidence, and review date
- Indexing, impressions, clicks, and inquiries are measured as separate states
- The report carries no guarantee of search or business outcomes
Sources
- How Google Search works
- Google guidance for generative AI features
- Google documentation on canonicalization
- Google guidance on helpful, reliable content
- OpenAI publishers and developers FAQ
- Open GEO Console in English
Next step
If you already have a short list of priority URLs, Open GEO Console can start with a public homepage check covering the homepage, robots.txt, sitemap.xml, and optional public files. Its private deep report analyzes valid pages, evidence-backed findings, coverage limits, and a remediation roadmap. Any on-page product demo uses simulated data and is not evidence about your website.
You can also review the Open GEO Console project boundary, see how enterprise AI delivery is structured, or browse the other public projects. When the production URLs, business questions, and desired deliverables are ready, submit the problem for a scoped discussion.