A technical AI SEO checklist should produce verifiable findings, not a speculative score. Start with public pages that explain your product or answer an important buyer question. Check whether those pages return useful content, expose consistent URLs, and can be discovered through actual links.
This checklist complements the technical AI readiness hub. It focuses on page delivery and indexing foundations. It does not imply that every AI provider uses Google's renderer, index, or ranking systems.
Scope the audit before checking the site
Select representative templates: homepage, product page, article, comparison page, and documentation. Include a recently migrated URL if your site has changed. Record the production hostname, expected canonical URL, and the core information each page should expose.
Mark each finding as confirmed, suspected, or unknown. A reproducible wrong canonical is confirmed. Missing from one AI answer is a visibility observation that needs investigation. Keeping these categories separate prevents a speculative diagnosis from becoming an unnecessary engineering project.
1. Confirm the status and final destination
Visit the production URL and inspect the response chain. Check for loops, accidental authentication, redirects to unrelated pages, and successful status codes that conceal an error document. Confirm that a migrated page lands on its meaningful replacement rather than the homepage by default.
Save the final URL and response body. A useful page should communicate the same central subject to a visitor and to a client that retrieves its public content. If access varies by geography or network, document the condition instead of assuming one local visit describes every request.
For deeper network diagnosis, use the AI crawler access audit.
2. Compare initial HTML with rendered content
Inspect the returned HTML for the primary heading, explanation, product facts, and links. Then compare the browser-rendered page. Identify content that depends on a user interaction, client-side request, or authentication state.
Google explains its own rendering process in the JavaScript SEO basics. Use that guidance for Google-specific diagnosis while investigating other clients according to their capabilities. Do not assume that because Google can render a section, every AI fetcher can do the same.
Where the current framework supports it, serving important public text and links in the initial document reduces a delivery dependency. Verify the resulting HTML after a production build rather than judging from a development browser alone.
3. Inspect canonical URL consistency
Check the canonical declaration against the intended public URL, redirects, internal links, and sitemap entry. Avoid conflicting hostname, slash, query, or legacy-path variants. Google's canonicalization documentation explains how canonical signals are interpreted in Google Search.
Treat a canonical as a preference signal within that documented context, not a universal command to every AI product. If a useful article accidentally points to a different article, correct the configuration and verify all templates that share the same metadata logic.
4. Review indexing and snippet controls
Inspect robots meta directives and response headers on the actual deployed page. Check whether a staging restriction leaked into production. Also inspect robots.txt separately: preventing a crawler from fetching a page differs from allowing a fetch and applying an indexing instruction.
Google's robots meta tag documentation explains Google-supported indexing and preview controls. Read the relevant provider's documentation before generalizing those rules. Record whether your finding concerns Google Search, another provider's access, or both.
5. Check discovery through links and sitemaps
Open the XML sitemap and verify that it lists intended canonical public pages. Remove retired or unintended nonindexable URLs from the preferred inventory as appropriate. Compare the inventory with pages reachable through navigation and contextual links.
The Google sitemap overview describes the sitemap's discovery role and limitations. A sitemap entry is not evidence of indexing or inclusion in an AI answer. Keep crawlable internal links so readers and compatible crawlers can reach the page through the site itself.
Use a completion worksheet
The entries below are illustrative checks, not a claim that a particular website has these defects.
| Check | Evidence | Completion condition |
|---|---|---|
| Response and redirect | Saved production headers and body | Expected public destination and useful page content |
| Initial HTML | Main explanation and link inspection | Important text is present or its delivery dependency is documented |
| Canonical | Rendered head and preferred URL record | Metadata, sitemap, redirects, and links agree |
| Indexing directives | HTML meta and response headers | Intentional controls match the page's publishing purpose |
| Discovery | Sitemap entry and referring page | Canonical page has a working discovery path |
| Entity data | Visible facts and emitted JSON-LD | Current organization/product information is consistent |
Assign an owner, deployment date, and repeat check to each confirmed issue. For entity-related findings, continue with the structured data guide. Treat llms.txt as a separate optional experiment rather than a substitute for these checks.
Close the technical issue before interpreting visibility
After deployment, repeat the failed check in production and save the result. Then revisit the AI visibility baseline with the same prompt set and collection conditions. Report that a technical barrier was removed separately from whether the brand's sampled visibility changed.
If the technical checks pass but the page does not answer the buyer's question, move to content optimization. If you want a coordinated review of visibility observations and possible fixes, discuss the evidence with BIU.