The direct answer
A site is technically ready for ChatGPT Search when its useful public pages are accessible to OAI-SearchBot, return stable indexable responses, and expose the important answer in fetchable page content. GPTBot is a different control for potential model training, while ChatGPT-User represents requests initiated by users. OpenAI documents all three identities and their purposes in its official bot documentation. A publisher can therefore allow search discovery while making a separate decision about training.
Readiness only removes observable technical obstacles. It cannot guarantee that ChatGPT will index, cite, summarize, or send traffic to a page.
Check the search path from policy to page
Start with one high-value public URL, not the whole site. Write down the expected result for OAI-SearchBot, GPTBot, and ChatGPT-User separately. Then work through this sequence:
- Fetch
/robots.txton the exact hostname and evaluate theOAI-SearchBotgroup for the chosen path. A rule onwww.example.comsays nothing aboutdocs.example.com. - Follow redirects for the page and record the final status and URL. A public guide that ends at a login wall, challenge page, soft 404, or retired campaign URL is not ready for reliable retrieval.
- Inspect the final HTML for
noindex, canonical URL, title, main heading, and the text that answers the page’s question. Do not assume content visible after a browser interaction exists in the initial response. - Check that essential CSS, JavaScript, API calls, and images are not blocked when they are required to understand the page. Prefer meaningful server-rendered text for the core answer.
- Confirm the page has ordinary internal links from relevant sections and points to supporting material. The AI search readiness audit explains how to choose a finite priority sample.
The AI Crawler Checker can make a bounded public request and report observable response signals. Use the robots.txt AI Checker when the question is which rule matches a particular path. Neither result proves an OpenAI visit; verified activity requires your own trusted logs.
Keep the three OpenAI decisions separate
Avoid a single “allow ChatGPT” switch in change tickets. Record three rows: identity, business purpose, intended routes, deployed rule, and owner. That prevents a later editor from treating a GPTBot training opt-out as a search outage or from opening private routes for user-triggered retrieval.
Robots directives are crawler preferences, not access control. Account pages, unpublished previews, customer exports, and paid files still need authentication. Also keep WAF behavior separate from robots: an Allow rule does not override an edge challenge or origin denial.
Hypothetical release review
Suppose a fictional software company, Northstar API, wants its authentication guide available to ChatGPT Search but does not want future documentation collected by GPTBot. Its policy explicitly allows OAI-SearchBot on /docs/, disallows GPTBot, and leaves /account/ behind authentication for every client.
The reviewer tests /docs/authentication, which returns 200, but its canonical points to an obsolete /launch/auth URL that now redirects twice. The raw HTML also contains only a heading; the token examples arrive after a client-side API call. The team corrects the canonical and renders the essential steps in the initial HTML. A repeat check records the new response, timestamp, and deployed robots file. The finding is “two retrieval barriers removed on one tested page,” not “ChatGPT visibility improved.” That outcome would require separate, later evidence.
FAQ
Does blocking GPTBot block ChatGPT Search?
No. OpenAI documents GPTBot and OAI-SearchBot as separate identities with different purposes.
Can this site checker confirm that OpenAI crawled my page?
No. It can test public policy and response behavior; actual crawler activity must come from your own logs and identity verification.