Start with eligibility, then evidence
Google's current optimization guide says supporting pages must be indexed and eligible for a Search snippet, and the site must be included in Search generative AI features through its Search Console setting. Inspect the effective property setting as well as page-level controls. Meeting these requirements does not guarantee crawling, indexing or selection; special AI schema and llms.txt do not provide a shortcut.
For an audit, treat eligibility and selection as separate questions. First establish whether the page can be reached and understood. Then ask whether it contains a useful, checkable answer to the reader's question. A valid sitemap cannot compensate for an unsupported claim, and a strong article cannot help a visitor who receives an error page.
Google: AI optimization guide · provider-specific crawler controls
Record what a real request receives
Use a small URL inventory rather than a homepage-only score. Include a product page, a substantive resource, pricing and any evidence page. Save the response and the test conditions so another person can repeat the check.
- Response: record status, redirect destination, content type and any indexing or snippet controls.
- Discovery: follow ordinary navigation links, check the canonical URL and inspect the sitemap's page list.
- Text: read the main explanation, headings, source references and limitations without interacting with a dashboard.
- Evidence: distinguish observed results, illustrative figures, third-party reporting and claims about the whole market.
- Access: investigate CDN or hosting rules as well as robots.txt. A permissive text file does not prove that every request gets through.
A measured example: a dashboard on a homepage
Beacon's October 2026 audit found an interactive illustrative console with three brands and every module serialized into the homepage. Independent verification of all retained response bytes is incomplete; the following counts are producer-reported local observations. Earlier local measurement outputs reported 915,784 HTML bytes and 1,564,182 explicit script bytes before a revision, then 337,676 HTML bytes and 835,286 script bytes at an intermediate stage. Those historical outputs remain available, but their original HTML, script inputs and exact build identifiers were not retained; treat those figures as local reported results.
A separate capture on 1 October 2026 at 20:54:06 UTC fetched the unchanged live homepage at https://beacon.evaa.sg/ and a local candidate built from commit 632b481. Both returned HTTP 200 with identity content encoding. The live response contained 917,079 HTML bytes and 1,564,670 bytes across ten explicit script files; the local candidate contained 337,926 HTML bytes and 836,896 bytes across eleven files. The manifest records request times, URLs, headers and SHA-256 hashes, with raw inputs retained in the private audit package. It records local build ID u1Eqp87edWhm_G9Zg6rZ6; no live Next build ID was exposed by the extraction method.
The local candidate kept the full console on a dedicated, labelled demo page and a server-rendered overview on the homepage, with an ordinary link and prefetch disabled. Its captured HTML and explicit script totals were about 63.2% and 46.5% smaller than live production. This compares different hosted and local builds, with framework and content differences; it does not isolate the console change as the cause. It is not a deployed result, search-ranking gain or Core Web Vitals result.
Script totals cover same-origin /_next/static files explicitly referenced in each captured document and exclude later dynamic imports, CSS, images and fonts. Gzip estimates use local compression. Requests sent no credentials or cookies; raw response-body bytes exclude HTTP headers, framing and TLS. Browser measurements and field data are still needed to establish loading and interaction performance.
Give people and crawlers the same useful explanation
A lightweight overview should answer the basic question on its own. Moving an expensive example to another page should give every visitor the same choice, with clear navigation and a meaningful destination. Keep its generated-data labels visible at the example itself.
When testing this pattern, check a direct request to the demo as well as navigation from the homepage. Confirm that ordinary links work without client JavaScript, that the demo can be reached from the keyboard, and that its brand and agency modes still work. Do not infer those interaction results solely from a successful build.
Make the evidence worth linking to
For this experiment, the useful asset is the reproducible measurement: define the baseline, describe the change, expose the counts and name the limitations. A reader should be able to assess the result without trusting a marketing headline. A more general resource might provide a documented dataset, a tested workflow or a comparison with an explicit scope.
Google's link-spam policy covers purchased ranking links, automated link creation, excessive reciprocal linking and low-value content made to manipulate links. A backlink count therefore needs context. Record the referring page, relevance and why its reader benefits from the reference; do not substitute paid placement or a large directory list for evidence.
What to check after an approved release
Repeat the same URL and payload checks on the live deployment, using the final canonical host. Keep before and after records. Use authorized webmaster access to inspect indexing, and verify source citations against the published page rather than a local draft.
Choose a documented set of buyer questions and record the assistant, date, search setting, language and location for each observation. Keep citation observations separate from referral visits and business outcomes. An absent mention in one answer is a sample observation, not proof that a site is excluded from every AI answer.