AI search readiness is the condition in which your important pages can be discovered, accessed, rendered, understood and supported with evidence by search and answer systems. It does not guarantee that Google, ChatGPT, Claude, Gemini, Perplexity or any other platform will cite you. It removes avoidable reasons they cannot.
Use this checklist on three representative URLs: your homepage, one commercial page and one knowledge article. Mark each item Pass, Fail or Needs evidence. A site is not ready if a critical access or delivery check fails—even when its content ranks in conventional search.
Before you start: gather pages, access and baseline evidence
Do not begin with a sitewide score. Begin with a small, repeatable sample that reveals whether the same problem appears across templates. Choose the preferred canonical version of each URL and record why that page matters to the business.
- Homepage: confirms the main organization, navigation and discovery paths.
- Commercial page: confirms that a product, service, category or pricing offer is accessible and understandable.
- Knowledge article: confirms that an answer-led page exposes its main explanation and supporting evidence.
- Additional template: include a help-center, documentation or location page if it runs on a separate platform.
For every URL, save the test date, HTTP status, redirect chain, canonical URL, robots directives, raw HTML, rendered HTML, sitemap presence and at least one internal link. Also note recent migrations, CDN changes, consent tools or security rules. That record lets you distinguish a real improvement from a cache change or unrelated release.
| Evidence | What to record | Why it matters |
|---|---|---|
| HTTP response | Final status, redirects and content type | A crawler cannot use a page that returns an error, loop or misleading response. |
| Access rules | robots.txt, meta robots, X-Robots-Tag and WAF behavior | One control may allow a page while another prevents access or indexing. |
| Page output | Raw HTML and rendered DOM | Important copy may appear visually but be absent from the delivered source. |
| Discovery | Internal link, sitemap entry and canonical | These signals help systems find and consolidate the preferred URL. |
| Meaning | Page purpose, publisher, entities, claims and sources | Clear meaning reduces the effort required to interpret and verify the page. |
Check 1: discovery and crawler access
A page that cannot be reached cannot contribute its full content to an AI answer. Test access at the URL level; a permissive-looking robots.txt file alone is not proof.
1. Confirm the preferred URL is discoverable
- Link to the page from at least one crawlable, relevant page using a normal HTML link.
- Include the canonical URL in a valid XML sitemap when it belongs in search.
- Avoid orphan pages and navigation that only appears after an interaction a crawler may not perform.
- Make internal links point to the final canonical URL rather than redirects or parameter copies.
2. Read robots.txt by user agent
Separate search discovery controls from model-training controls. OpenAI documents OAI-SearchBot for ChatGPT search and GPTBot for potential model training as distinct user agents. Allowing or blocking one does not automatically express the same preference for the other. Anthropic likewise publishes crawler-specific guidance and states that its bots honor robots.txt directives.
- Open the robots.txt file on every relevant subdomain.
- Evaluate the most specific matching group for each crawler you care about.
- Check broad wildcard rules as well as crawler-specific rules.
- Retest after CDN, firewall or WordPress security changes.
- Confirm the crawler receives the same policy you see from your own browser.
3. Test the real HTTP response
Request the page and its assets from outside your office network. A 200 status in your browser can hide a bot challenge, soft 404, login wall or rate limit. Record the final status, response body, headers and redirect chain.
| Result | Pass condition | Failure example |
|---|---|---|
| Robots policy | The intended search crawler is not disallowed from the URL | A broad Disallow: / applies to the crawler. |
| Server access | The crawler receives the real page with a successful response | The WAF returns 403, 429, a CAPTCHA or an empty shell. |
| Canonical route | Redirects resolve once to the preferred URL | Multiple hops, loops or inconsistent HTTP/HTTPS versions. |
| Asset access | CSS, JavaScript and key images needed for rendering are reachable | Scripts containing the main content are blocked. |
Check 2: technical delivery, rendering and index controls
Access is only the first gate. Next, verify that the page actually delivers its main information and remains eligible for indexing where indexing is required.
4. Compare raw and rendered output
- Find the page title, H1, primary answer, product or service description, important links and visible evidence in raw HTML.
- Render the page with JavaScript and compare the result. Note content that appears late, only after a click or only after consent.
- Disable or fail key scripts and observe whether the main information disappears.
- Check mobile output as well as desktop; responsive layouts can hide critical sections.
Client-side rendering is not automatically a failure. It becomes a readiness risk when essential information depends on unreliable execution, blocked resources, authentication or delayed interactions. Google’s official guidance says its AI features rely on the same foundational crawling and indexing systems used by Search, and pages need to meet Search eligibility requirements.
5. Inspect index and canonical controls
- Confirm the preferred page does not carry an unintended
noindexmeta tag or X-Robots-Tag header. - Make sure the canonical points to the preferred, equivalent page—not a staging URL, category page or unrelated duplicate.
- Check hreflang, pagination and parameter rules for conflicts.
- Verify that the page is not hidden behind login, paywall behavior or consent logic inconsistent with your intended access policy.
- Use search-console inspection for Google eligibility, but do not treat one platform’s index status as proof for every other system.
6. Validate page stability
Repeat the request several times and from more than one network location. Intermittent 5xx errors, timeouts and bot-only 403 responses can create a problem that a one-time audit misses. Record a short sample rather than claiming reliability from a single successful fetch.
Check 3: content clarity, entities and citation signals
A technically accessible page can still be difficult to use if the subject, publisher or claim is unclear. Review the page as a source an unfamiliar reader must evaluate.
7. State the page’s purpose early
- Use one descriptive H1 that matches the page’s actual purpose.
- Answer the central question or describe the offer near the beginning.
- Use meaningful headings that let a reader locate definitions, steps, evidence and limitations.
- Avoid opening paragraphs made entirely of slogans, category jargon or unsupported superlatives.
8. Make important entities explicit
Name the organization, product, service, person, location or concept instead of relying on pronouns and visual context. Keep naming consistent across the page, about page, contact details and structured data. Link to authoritative internal pages that explain unfamiliar entities.
- Identify who publishes or is responsible for the information.
- Explain the relationship between the company, product and service.
- Provide current contact, location or support details when relevant.
- Use structured data that matches visible content; do not add claims that users cannot see.
- Resolve ambiguous abbreviations and distinguish similarly named products or organizations.
9. Strengthen verification and citation readiness
Citation readiness means a reader or system can trace a material statement to useful evidence. It is not a schema type and does not guarantee citation.
- Add a visible publication or last-updated date when freshness matters.
- Describe the method, sample and limitations behind original findings.
- Link factual claims to primary or authoritative sources where possible.
- Name the author or reviewer and explain relevant experience.
- Use specific examples, measurements or screenshots that genuinely support the conclusion.
- Correct stale claims instead of changing the date alone.
Google’s current guidance for generative AI search emphasizes valuable, non-commodity content and a clear technical structure. It also says there is no special AI-only markup required for Google’s AI features. Structured data can still support ordinary search features when it accurately represents visible content, but it is not a shortcut to inclusion.
Check 4: platform testing and pass/fail recording
Platform tests are observations, not universal rankings. Test narrow prompts that a potential customer could realistically ask, save the exact wording and date, and separate three outcomes: the platform knew the brand, surfaced the URL or cited the page as support.
| Test | Record | Do not conclude |
|---|---|---|
| Branded discovery | Whether the correct organization and canonical site appear | One correct answer does not prove broad discoverability. |
| Page-specific query | Whether the exact page, title or distinctive fact appears | Absence does not identify the technical cause by itself. |
| Non-branded problem query | Sources and URLs used in the answer | A single citation is not a stable rank position. |
| Freshness query | Whether a recently updated fact is reflected | A delayed update does not prove permanent exclusion. |
| Referral check | Visits tagged from relevant answer platforms | No referral traffic does not prove the page was never used. |
Create an evidence log with: URL, platform, prompt, date, account or location conditions, response, cited sources, screenshot and interpretation. Repeat the same test after meaningful changes. For a step-by-step testing method, see How to Test If a Website Is Ready for AI Search.
Prioritize critical, important and improvement items
Do not average failures into a percentage that hides blockers. A site with excellent content and a crawler-wide access denial is not “90% ready.” Use severity based on which gate the issue stops.
| Priority | Definition | Examples | Action |
|---|---|---|---|
| Critical | Prevents discovery, access or delivery of the main page | Crawler disallow, noindex, 403 challenge, server error, empty rendered content | Fix and retest before lower-priority optimization. |
| Important | The page is accessible but meaning or verification is materially weak | Ambiguous entity, missing ownership, unsupported core claim, conflicting canonical | Assign an owner and resolve in the next content or technical cycle. |
| Improvement | Adds clarity or measurement without repairing a current blocker | Better internal anchors, richer examples, clearer update notes, expanded monitoring | Schedule after critical and important work. |
Recommended pass rule: every sampled priority URL passes discovery, intended crawler access, successful delivery, index controls and essential content rendering. Important clarity and evidence gaps have named owners and deadlines. Platform visibility is tracked separately as an outcome, not used to erase a technical failure.
Evidence and screenshots to include
A useful audit is reproducible. Capture enough evidence for another person to verify the finding without relying on your summary.
- The exact robots.txt group and timestamp.
- Response headers and the relevant part of the returned body.
- Raw HTML and rendered DOM showing the main heading and answer.
- Meta robots, X-Robots-Tag and canonical values.
- The internal link and sitemap entry leading to the preferred URL.
- Visible organization, author, date, method and primary source links.
- Platform test prompt, response, cited links and date.
- Before-and-after evidence using the same test conditions.
Remove private tokens, personal data and admin URLs before sharing screenshots. Do not manufacture dashboard images to make a result look more authoritative.
Common interpretation mistake: rankings are not readiness evidence
A conventional ranking can show that Google discovered and selected a page for a particular query. It does not prove that every AI search product can access, render, interpret or cite that page. The reverse is also true: a technically ready page is not guaranteed to rank or be cited.
Keep the layers separate: readiness covers controllable access and quality conditions; visibility records what platforms actually surfaced; performance measures visits, engagement and business outcomes. This separation makes diagnosis possible.
AI search readiness checklist: compact worksheet
| Checkpoint | Pass when | Status |
|---|---|---|
| Representative pages selected | Homepage, commercial page and knowledge article are documented | ☐ |
| Discovery path exists | Canonical URLs have relevant internal links and, where appropriate, sitemap entries | ☐ |
| Crawler policy checked | Intended search crawlers are not accidentally disallowed | ☐ |
| Server access verified | Real page returns successfully without challenge or soft error | ☐ |
| Main content delivered | Essential copy and links appear in raw or reliably rendered HTML | ☐ |
| Index controls aligned | No unintended noindex, header or canonical conflict exists | ☐ |
| Entities are clear | Publisher, subject and relationships are explicit and consistent | ☐ |
| Claims are verifiable | Dates, authorship, methods and primary sources support material claims | ☐ |
| Platform tests logged | Prompts, dates, responses and citations are saved separately | ☐ |
| Issues prioritized | Blockers, important gaps and improvements have owners and retest dates | ☐ |
Frequently asked questions
What is the minimum AI search readiness test for a small business site?
Test the homepage, one service or product page and one helpful article. Confirm discovery, intended crawler access, successful delivery, index controls, rendered main content, clear business identity and support for important claims. Record the result rather than relying on a score.
Should I allow every AI crawler?
That is a business and content-policy decision. Distinguish search discovery, user-requested access and model-training agents, then choose deliberately. Document the decision per crawler and subdomain so a security change does not accidentally override it.
Does passing this checklist guarantee a ChatGPT or Google AI citation?
No. Passing removes detectable readiness barriers. Platforms still decide what to crawl, index, retrieve, rank and cite. Official Google guidance explicitly notes that meeting requirements does not guarantee crawling, indexing or serving.
Do I need llms.txt or special AI schema?
Not for Google’s AI features: Google states that no special AI text file or schema is required. Other services may evolve their own conventions, so treat any optional file as an experiment with documented outcomes—not a replacement for accessible HTML, sound technical SEO and useful evidence.
How often should the checklist be repeated?
Retest after a migration, redesign, CDN or WAF change, robots update, JavaScript framework release or major template edit. For stable sites, run a representative check monthly or quarterly and monitor server logs continuously enough to notice crawler-wide failures.
Next step
Run this checklist on three URLs today and fix the first critical blocker before adding speculative AI-search tactics. Visible Pilot is being built to help businesses identify the technical, content, SEO and AI-search issues that keep useful pages from being discovered, understood and recommended.
