The AI SEO Audit: A 30-Point Checklist for Crawl Access, Rendering, and Structured Data

Your next US customer asks ChatGPT to compare vendors or searches Google for a solution your business provides. You have a relevant page, a clear offer, and content built to answer their question. But what happens if a crawler encounters a firewall challenge, an empty JavaScript shell, or structured data that contradicts your page? 

For SEO managers targeting the US market, that is the gap worth investigating before commissioning another content refresh. The question is not just “Is our content helpful?” It is “Can the systems our buyers use access and interpret it?”

The challenge is not finding another checklist. It is separating genuine technical barriers from speculative AI optimization advice.

A page can look complete in your browser while returning an empty application shell to another client. Your robots.txt file can allow a crawler while your security layer blocks it. Your structured data can pass a syntax check while describing information that visitors cannot see.

These are implementation problems, not writing problems.

Google provides an important starting point: there are no additional technical requirements for appearing in AI Overviews or AI Mode. Supporting pages must be indexed and eligible to appear in Google Search with a snippet. Existing SEO fundamentals still apply, and correct implementation does not guarantee inclusion. 

This 30-point checklist examines that foundation across crawl access, rendering, and structured data. It also shows how to turn findings into developer-ready fixes instead of another report that sits in a shared folder.

Define Your Audit Scope

An AI SEO audit is not the same as asking an AI tool to review your website.

AI-assisted analysis can help organize findings, but it cannot replace HTTP responses, rendered HTML, crawler logs, or structured data validation. Treat an AI-generated diagnosis as a hypothesis until the underlying evidence supports it.

Also, distinguish technical readiness from observed visibility. A technically accessible page is not automatically a cited page.

Skyram’s AI search visibility audit guide covers query selection, platform testing, and competitive benchmarking. Use that process alongside this checklist. Visibility testing shows where your website appears, while technical testing investigates whether implementation problems are limiting access or interpretation. 

Start with a representative URL sample rather than reviewing only your homepage. Include high-value service pages, major blog templates, product and category pages, recently updated content, and pages with known indexing problems.

For each URL, record its template, business purpose, intended indexing status, expected canonical URL, and technical owner. Save dated evidence so later tests can distinguish a deployment change from an earlier observation.

The distinction between GEO and SEO helps frame your strategy. However, technical recommendations should remain grounded in observable behavior and documented platform requirements.

Crawl Access: Checks 1–10

1. Separate crawler purposes

Create a crawler policy that distinguishes search discovery, model training, and user-triggered retrieval.

OpenAI identifies OAI-SearchBot as its search crawler and GPTBot as a crawler for content that may be used in foundation-model training. Their robots.txt settings are independent. Allowing search access does not require allowing training access. 

Pass condition: your policy names each relevant crawler and records its intended treatment instead of applying a blanket “allow all AI bots” rule.

2. Review robots.txt by path

Inspect robots.txt on the host serving each audited URL. Review general rules and crawler-specific groups.

Look for unintended blocks affecting service pages, blog directories, product collections, or resources required for rendering. Test representative paths against the applicable rules rather than assuming an Allow directive overrides every restriction.

Google cannot render blocked JavaScript resources it cannot crawl. A resource-level restriction can therefore affect the interpretation of an otherwise accessible page.

3. Check indexing and snippet controls

Inspect the initial HTML, rendered HTML, and HTTP headers for indexing and preview controls.

For pages intended to support Google AI search visibility, investigate unexpected noindex, nosnippet, restrictive max-snippet, and data-nosnippet implementations. These controls serve different purposes and should not be grouped into one generic robot issue.

Google requires supporting links in AI Overviews and AI Mode to be indexed and snippet-eligible. Record whether each restriction is intentional or accidental.

4. Test CDN and firewall access

A permissive robots.txt file does not prove the page is accessible.

Review content delivery network and web application firewall events for blocks, browser challenges, and rate limits affecting legitimate crawler requests. Check whether public pages return a CAPTCHA or access-denied response instead of the intended content.

Perplexity recommends permitting its published crawler IP ranges where firewall rules would otherwise block access. Keep exceptions narrow and preserve protections for private routes.

5. Verify crawler identity

Do not trust a user-agent string alone. It can be copied.

For providers that publish crawler IP ranges or verification procedures, compare observed requests with those official sources. Perplexity recommends combining user-agent matching with IP verification, while OpenAI publishes IP information for its crawlers. 

Pass condition: access rules permit verified traffic without granting unrestricted access to anyone claiming to be a search bot.

6. Validate HTTP responses

Inspect the actual response for each priority URL, including its status code, content type, headers, and body.

Check for authentication requirements, persistent server errors, and pages returning 200 while displaying an error message. Google uses HTTP status codes to understand retrieval outcomes, and rendering may be skipped for non-200 responses. 

Include the requested URL and observed response in the issue record. “Page does not load” is not a sufficient development brief.

7. Audit redirect paths

Trace important URLs through every redirect to the final destination. Flag unnecessary intermediate hops, loops, obsolete destinations, and redirects to unrelated pages. Review internal links left behind after migrations or URL changes.

The practical objective is simple: an internal link should take visitors to the relevant current page without avoidable detours. Retest the original URL and final destination after implementing a change.

8. Compare sitemap entries

Export all child sitemaps and compare the inventory with your crawl results.

Check for repeated exact URLs, redirected entries, noncanonical versions, intentionally excluded pages, and missing priority pages. Separate duplicate sitemap entries from different URLs containing substantially similar content.

For example, a trailing-slash variation and a tracking-parameter URL are different strings but may represent the same page. Record exact duplicates and potential equivalent-page conflicts separately before recommending consolidation.

9. Inspect crawlable internal links

Confirm that important pages are linked through standard HTML anchors with an href attribute.

Google documents this structure as the basis for discovering links. JavaScript can inject links, but the resulting implementation still needs a usable destination. Click handlers without crawlable links deserve investigation. 

Compare anchor text with the destination’s subject. An anchor promising a technical audit should not lead to an unrelated advertising page.

10. Review access logs

Use access logs and security events to examine what verified crawlers actually receive.

Record requested paths, status codes, repeated failures, and differences across page templates. Compare priority URLs with observed requests, but do not treat a missing log entry as proof that a platform can never discover the page.

Configuration shows intended access. Logs provide evidence of observed access. A useful AI SEO audit needs both.

Rendering: Checks 11–20

1. Inspect the initial HTML

Retrieve the page without executing JavaScript and inspect its response body.

Check whether the title, main heading, core explanation, relevant links, and important commercial facts are present. An initial response containing only navigation and a loading placeholder should trigger a rendering investigation.

Google can render JavaScript, but not all bots can. Server-side rendering or prerendering can support broader content availability without being a universal requirement.

12. Compare rendered content

Render the same page and compare the output with its initial HTML. Document material differences, including missing paragraphs, duplicated headings, altered metadata, broken links, or content dependent on an API request. For Google-specific investigation, use URL Inspection to review available retrieval and rendering evidence. 

Pass condition: the rendered page contains the intended content and does not introduce conflicting indexing signals.

13. Test rendering dependencies

Identify what must happen before the main content appears. Test a fresh session without stored consent, account credentials, or personalization. Investigate whether a consent platform or analytics script accidentally controls essential public content.

Do not remove legitimate privacy protections to satisfy an audit. Instead, separate public content delivery from nonessential tracking dependencies so the implementation reflects your intended access policy.

14. Investigate JavaScript failures

Inspect console errors and failed network requests on affected templates. Look for missing bundles, failed content APIs, incompatible code, and hydration errors that remove or replace server-rendered content. A successful document response does not prove every rendering dependency succeeded.

Google recommends testing JavaScript implementation and compatibility rather than assuming a functioning desktop session represents every retrieval environment.

Skyram’s web design and development services include React, Next.js, Vue, WordPress, and headless architectures. That capability matters when an audit requires an application or template fix rather than a content rewrite. 

15. Keep canonical signals consistent

Compare canonical tags in the initial HTML and rendered page.

Google advises against using JavaScript to change an initial canonical to a different URL. If JavaScript generates the canonical, the initial HTML should not declare a conflicting value. Check for multiple canonical tags as well. 

Pass condition: the intended canonical remains consistent across retrieval stages, and internal links use the preferred version.

16. Remove accidental initial noindex

Check whether indexable pages initially contain noindex and rely on JavaScript to remove it.

Google may skip rendering when it encounters noindex, making that removal strategy unreliable. Pages intended for indexing should not begin with an exclusion directive that the application later attempts to reverse. e

Trace the directive to its source. It may originate in a CMS setting, deployment environment, shared template, or middleware.

17. Test interaction-dependent content

Check whether important explanations require a click, scroll, tab selection, or form submission before they are fetched.

Distinguish content already available on the page from content requested only after interaction. Expandable sections are not automatically problematic, but essential information should be tested rather than assumed accessible.

Google recommends search-friendly lazy-loading implementations. Review the rendered HTML and the behavior of the component carrying the content.

18. Review application routes

Open important single-page application routes directly in a fresh session.

Confirm that each URL resolves independently instead of working only after navigation from the homepage. Check for fragment-based routing, generic metadata, and nonexistent routes displaying the same application shell as valid pages.

Google recommends the History API instead of fragments for loading distinct page content and explains how to avoid soft-404 behavior in JavaScript applications.

19. Keep essential facts textual

Review whether critical information appears only in images, animations, or embedded interfaces.

Provide important specifications, service descriptions, eligibility details, and explanations in readable text where appropriate. Visuals can support understanding, but they should not be the only way to access essential facts.

Google’s AI search guidance specifically recommends making important content available in textual form.

For commerce teams, connect this check with ecommerce development decisions. Catalog architecture and storefront components should support product discovery and a clear buying experience.

20. Test cache freshness

After updating content or code, compare the production response with the expected deployment.

Check whether cached HTML, old JavaScript bundles, or stale API responses still serve previous information. Google notes that its rendering system caches resources aggressively and recommends fingerprinted asset filenames to help prevent outdated JavaScript or CSS. 

Pass condition: the live page, rendered output, and structured data reflect the same current version.

Structured Data: Checks 21–30

21. Inventory markup by template

List the structured data types emitted by each template.

Identify every source, including CMS plugins, theme code, custom components, and tag-management tools. This inventory helps locate duplicate or conflicting implementations before changing individual pages.

Google uses structured data to understand page content and support eligible search appearances. Understand what the site already publishes before adding another schema tool.

22. Match types to content

Choose markup that accurately describes the page’s main subject.

A blog article, product detail page, organization page, and discussion thread represent different content types. Do not select a type solely because a competitor uses it or a tool labels it AI-friendly.

Google states that AI Overviews and AI Mode do not require special Schema.org markup. Accurate implementation matters more than adding types indiscriminately.

23. Check required properties

Validate required and recommended properties against current documentation for the relevant search feature.

Separate critical errors from recommendations. Review whether each value is accurate, current, and appropriate for the page. Never invent information simply to clear a warning.

Use validation results as a starting point, not a replacement for editorial and implementation review.

24. Match markup to visible content

Compare structured data with what visitors can read.

Check names, descriptions, prices, availability, dates, and other claims included in the markup. Do not describe services that are no longer offered or product conditions that differ from the page.

Google recommends that structured data match visible text. A technically valid block can still fail this accuracy check.

25. Resolve conflicting entities

Review whether multiple blocks describe the same organization, article, or product differently. Use stable identifiers where appropriate and trace conflicts to their source. For example, a plugin and custom component may emit different publisher names or product prices.

Fix the generator responsible for the conflict. Editing a temporary copy of the output will not stop a future deployment from recreating it.

26. Verify author and publisher details

Check bylines, author profiles, publisher names, and relevant URLs for consistency.

Do not add an expert reviewer or named author unless that person contributed in the stated role. Machine-readable attribution should reflect the visible editorial record.

This check supports publishing accountability. It should not be presented as a guaranteed mechanism for earning AI citations.

27. Audit product data consistency

Compare product markup with the storefront and underlying product source.

Review price, currency, availability, variants, and implemented offer information. Test changes after promotions and inventory updates instead of validating only a static sample.

Google supports JavaScript-generated structured data but recommends placing product markup in the initial HTML for best results. 

A useful acceptance test is to update a product in staging and verify that its visible information and markup change together.

28. Update FAQ assumptions

Keep FAQ sections because they answer reader questions, not because they promise a Google-rich

Google discontinued FAQ-rich results starting May 7, 2026, and removed the feature’s documentation in June 2026. An audit based on an older schema checklist should update that expectation. 

FAQPage markup is not required for Google AI Overviews. If maintained for another purpose, it should remain accurate and consistent with visible content.

29. Validate syntax and eligibility

Structured data validation should answer three questions: Does the markup use valid Schema.org vocabulary? Does it meet the requirements for a Google-supported search feature? Does it accurately describe the page?

No single test answers all three. Use this sequence before approving the implementation.

• Identify the markup and source.

Inspect the initial and rendered HTML. Record each block, its type, and its generator. Investigate duplicate blocks with conflicting values, then fix the responsible plugin, template, or application component.

• Run Schema.org validation.

Enter the URL or markup into the Schema Markup Validator. Check parsing errors, unrecognized properties, and values that do not match expected property types. This tool validates Schema.org markup, not eligibility for Google-specific rich results.

• Test Google-supported markup.

Enter the URL into Google’s Rich Results Test. Use its code-testing option to review proposed changes before deployment. Expand detected items, fix critical errors, and review noncritical warnings against the applicable feature documentation.

• Compare markup with the page.

Manually verify relevant names, descriptions, authors, dates, prices, and availability. For example, a product displaying $149 while declaring $129 in its markup needs correction even if the syntax passes. Google requires structured data to represent the page accurately. 

• Verify referenced resources.

Check that referenced images are accessible and not blocked from Google. Structured data images must be crawlable and indexable. Also review author, publisher, and entity URLs to confirm that they lead to the intended current destinations. 

• Save validation evidence.

Record the URL, test date, detected types, critical errors, warnings, and content discrepancies. Attach the results to the implementation ticket.

Pass condition: the markup parses correctly, meets applicable feature requirements, and matches visible content. Passing validation does not guarantee rich results or inclusion in AI-generated answers.

30. Verify deployment and monitor changes

A successful code test is not the end of validation. Production behavior can differ because of caching, JavaScript execution, template settings, or another component generating markup.

Follow this verification sequence after deployment.

• Retest the live URL.

Run the production page through both validators again. Test the URL, not just pasted code, so the review covers the deployed output. Google recommends testing a small set of deployed pages before expanding an implementation.

• Inspect Google’s live retrieval.

Use URL Inspection in Google Search Console and run a live test. Review page access and available rendered HTML. Confirm that the markup appears and that robots.txt, noindex, or login requirements do not prevent eligibility.

• Compare live and indexed results.

A corrected live page does not mean Google has recrawled it. Compare the live test with indexed URL information. Request indexing where appropriate and allow time for reprocessing.

• Review applicable reports.

For supported features with a rich result status report, inspect valid and invalid items. After confirming the fix, use the report’s validation workflow. Investigate increases in invalid items and unexpected drops in valid items after deployments.

• Test template variations.

Validate representative edge cases, including articles without featured images, products with variants, out-of-stock products, and pages with optional fields left empty. Confirm that changing source data does not create inaccurate values or broken markup.

• Add release checks.

Create repeatable checks for parseable JSON-LD, required fields, conflicting values, and alignment with the underlying content source. Retain manual review where accuracy requires editorial judgment.

Pass condition: production markup is correct, Google can retrieve it, applicable reporting issues have entered validation, and future changes have a defined retesting process.

Turn Findings Into Fixes

The output of an AI SEO audit should be a prioritized implementation backlog. For every finding, record affected URLs, reproduction steps, evidence, business relevance, ownership, and acceptance criteria. Separate confirmed failures from observations needing further investigation.

Consider a hypothetical SaaS page that looks complete in a browser. Its initial response contains only an application shell, its content API requires a session cookie, and its initial canonical differs from its rendered canonical.

“Improve AI readability” is not an actionable recommendation.

A useful ticket specifies that public content must load without authentication, canonical signals must remain consistent, and the deployed page must pass initial-response and rendering checks. Developers then have a testable definition of completion.

Apply the same standard when reviewing SEO agency deliverables. Require domain-specific findings, named owners, and an implementation roadmap rather than accepting a generic export as the finished audit.

Skyram Technologies combines SEO and development capabilities. Its SEO services cover technical audits, implementation, testing, and measurement, making the handoff between diagnosis and remediation a practical part of the engagement.

When discussing an audit with Skyram, bring priority URLs and an unresolved technical issue. Ask how the team would reproduce it, fix it, and verify the deployed result. That answer is more useful than a promise of guaranteed rankings or citations.

Frequently Asked Questions

What is an AI SEO audit?

An AI SEO audit evaluates whether website content is technically accessible and understandable to search engines and AI search services. It reviews crawl controls, responses, rendering, internal links, and structured data. Actual visibility should be measured separately through dated query tests and cited-source checks. 

How does it differ from a traditional SEO audit?

An AI SEO audit shares many technical checks with a traditional SEO audit. Its additional emphasis includes provider-specific crawler policies and observed visibility in AI answers. For Google AI Overviews and AI Mode, standard SEO remains the technical foundation.

How do I qualify for Google AI Overviews?

Keep pages indexed, snippet-eligible, technically accessible, and compliant with Google Search policies. Publish useful, reliable content and make it discoverable through internal links. Google requires neither special AI files nor special schema, and eligibility does not guarantee selection.

Should I allow GPTBot for ChatGPT search?

GPTBot and OAI-SearchBot serve different purposes. OpenAI identifies OAI-SearchBot as its search crawler and GPTBot as a training crawler. Their robots.txt settings can be configured independently, allowing search discovery while disallowing training access if that matches your policy.

Can JavaScript affect AI search access?

Yes. JavaScript dependencies can affect content availability, but JavaScript itself is not automatically a problem. Google renders JavaScript, while not all bots can. Inspect initial and rendered content, investigate failures, and use server-side rendering or prerendering where it addresses a demonstrated need. 

How do I validate structured data?

Use the Schema Markup Validator for Schema.org validation and the Rich Results Test for Google-supported feature requirements. Then compare the markup with visible content. After deployment, retest the live URL and use Search Console to review retrieval and applicable reports.

Does valid schema guarantee AI citations?

No. Structured data can help describe content and support eligible search features, but it does not guarantee citations. Google explicitly states that AI Overviews and AI Mode require no special Schema.org markup. Accuracy matters more than treating schema as a shortcut.

Do I need llms.txt for Google AI search?

No. Google states that llms.txt is not needed for Google Search and does not affect visibility or rankings positively or negatively. Maintaining it for another system is a separate decision, not a replacement for crawl access, indexability, useful content, or internal links.

How can I check Perplexity crawler access?

Review robots.txt, verify requests against Perplexity’s published crawler IP ranges, and inspect firewall events for blocks or challenges. Perplexity recommends allowing PerplexityBot and permitting its published ranges for search access. Combine user-agent and IP verification.

Can Search Console isolate AI performance?

Google reports traffic from its AI search features within overall Web performance data in Search Console. That is not a complete cross-platform citation report. Track ChatGPT, Perplexity, and Gemini visibility separately, distinguishing brand mentions from citations to specific URLs.

What should I fix first?

Prioritize confirmed access and indexing barriers on commercially important pages. Then resolve rendering failures, conflicting canonical signals, and inaccurate structured data. For Google’s AI search features, pages must first be accessible, indexed, and snippet-eligible to qualify as supporting links.