Key Takeaways:
- Separate Training From Search: Blocking GPTBot expresses a training opt-out. OAI-SearchBot controls automated crawling for ChatGPT search, so the two decisions can differ.
- Match The Rule To The Business: Publishers protecting original research may restrict training while keeping public product pages available for search discovery.
- Verify More Than robots.txt: Check live rules, CDN settings, and verified crawler requests. Crawl permission does not guarantee citations, and robots.txt does not secure private content.
Should I block GPTBot if I still want customers to find my website through ChatGPT? Yes, if your goal is to opt out of potential OpenAI model training while retaining search access. OpenAI documents separate controls for those purposes; blocking GPTBot alone is not a ChatGPT search opt-out.[1]
At QCK, our AEO and GEO work includes crawlability, answer-focused content, and measurement. We recommend treating crawler policy as a business decision before treating it as a technical fix.
This guide explains which OpenAI agents do what, when a training block makes sense, and how to implement and verify rules without confusing access with visibility.
Know Which OpenAI Agent You Are Blocking
The OpenAI crawler documentation distinguishes three roles relevant to this decision. A blanket “block OpenAI” rule overlooks those differences.[1]
|
Agent |
Documented Purpose |
Practical Meaning |
|
GPTBot |
Crawls content that may be used to train generative AI foundation models |
Disallow it to signal that content should not be used for training. |
|
OAI-SearchBot |
Surfaces websites in ChatGPT search features |
Allow it if search discovery is the goal; access does not guarantee selection. |
|
ChatGPT-User |
Visits pages for certain user-initiated actions |
It is not an automatic search crawler; robots.txt rules may not apply. |
These settings are independent. OpenAI explicitly describes allowing OAI-SearchBot while disallowing GPTBot. If both are allowed, OpenAI may use one crawl for both purposes to avoid duplicate crawling. Separate policies do not necessarily mean separate requests in your logs.[1]
Blocking ChatGPT-User is not a substitute for managing search access. Likewise, permitting OAI-SearchBot does not mean you must allow gptbot for training. Evaluate user-directed retrieval separately, especially where content requires authentication.[1]
Decide What Your Content Policy Needs To Protect
Start with the asset and the business objective. Public marketing content, licensed datasets, subscription reporting, and customer records should not share an undifferentiated access policy.
When A Training Block Makes Sense
Consider disallowing GPTBot when your organization does not want its public content used for potential model training. Original reporting, research sold under license, or material subject to contractual restrictions deserves an explicit policy review.
A training block can also be a conservative interim decision while legal, editorial, and commercial stakeholders agree on reuse terms. Document that rationale rather than presenting the change as a guaranteed traffic improvement.
When Allowing Training Fits Your Policy
Allowing GPTBot can fit an organization that accepts potential model-training use of its public material. Make that decision deliberately. Do not allow it solely because someone promises that training inclusion will produce citations, rankings, or customers. OpenAI's documented distinction does not establish those outcomes.[1]
For many commercial sites, the useful middle ground is to restrict training while preserving search access to public pages. For a publisher seeking broader restrictions, search may be a separate opt-out. OpenAI says sites opting out of OAI-SearchBot will not appear in ChatGPT search answers, although navigational links may still appear.[1]
Keep the decision owner visible. Marketing can define discovery goals, legal can assess reuse obligations, and engineering can implement the agreed boundaries. None should have to infer policy from an unexplained block added years ago.
Add Valid robots.txt Rules Without Replacing Your File
For the common “block training, allow search” policy, the following is a complete two-group example:
User-agent: GPTBot Disallow: / User-agent: OAI-SearchBot Allow: /
Merge the relevant groups into your existing file. Do not replace working directives for other crawlers, sitemap records, or platform-generated rules. This example intentionally allows OAI-SearchBot across the host; it is unsuitable if some paths should remain excluded from search crawling.
The Robots Exclusion Protocol specification defines how named groups, wildcard groups, and path rules work. An explicit matching bot group does not simply inherit every restriction in the wildcard group. Repeat any required path restrictions in the named group.[2]
For a hypothetical site that permits training on most public pages but excludes a research directory, a separate alternative is:
User-agent: GPTBot Disallow: /research/
This alternative does not block the entire site. Paths outside that prefix remain allowed unless another applicable rule restricts them. Do not combine both examples without evaluating the result: an existing sitewide GPTBot disallow would change the intended outcome.[2]
If you searched for “block gptbot robots txt,” the critical details are the named user agent, the slash, and the live file location. Serve plain UTF-8 text at /robots.txt on the relevant host, not inside a blog post or an HTML page. Review subdomains separately.[2]
Verify The Policy At The File And Network Layers
A saved edit is not proof that the intended policy is live. Use a repeatable check before reporting the change complete.
- Capture The Baseline: Save the current file, the reason for the change, and the affected hosts. Preserve a rollback copy.
- Inspect The Published Response: Fetch the public /robots.txt after deployment. Confirm it contains the expected text rather than a login page, an old cached version, or a challenge screen.
- Evaluate Each Bot Separately: Use our AI Crawler Access Tester to inspect the pasted rules. It evaluates the file you supply; it does not contact OpenAI or prove a crawler visited.
- Check Edge Controls: Review your CDN, web application firewall, bot-management settings, and rate limits. An allowed search crawler may still receive a block or challenge before it reaches the page.
- Review Verified Requests: Inspect timestamps, paths, status codes, and source IPs. Compare addresses with OpenAI's current published ranges, available through its crawler documentation. A user-agent string is self-declared and can be spoofed; it is not sufficient authentication.
- Retest After Caching Changes: OpenAI says search systems can take approximately 24 hours to adjust to a robots.txt update. That is search guidance, not a guaranteed deadline for every crawler or a citation promise.[1]
Do not disable broad security protections just to remove a crawler error. Narrowly scope any verified-bot exception, and keep authorization in place for private resources. A successful response to your own test request does not prove a genuine OpenAI request will receive the same response.
Our Free SEO Tools collection supports related technical checks once access rules are settled. Keep configuration findings separate from measured search performance.
Understand What Blocking Does Not Accomplish
A GPTBot restriction is not a retrospective deletion request. The current crawler documentation describes a training preference; it does not promise to remove previously collected material or reverse training already completed. Do not report the edit as erasing your content from an existing model.[1]
It also does not control every AI provider, every third-party copy, or every request made by a user. Review other providers independently rather than assuming that one OpenAI directive creates a universal opt-out.
For confidential content, the distinction is stronger: robots.txt is not security. The protocol explicitly states that its rules are not access authorization. Listing a sensitive path can make its location public. Protect restricted material through authentication and application-level authorization, with server or edge controls where appropriate.[2]
The llms.txt proposal serves a different purpose again: providing context and curated links for agents. Our llms.txt Generator helps prepare that kind of file. It does not enforce access, override robots.txt, or guarantee that an assistant will read or cite your pages.[3]
Measure Search Outcomes Separately From Training Access
Treat gptbot website access as a policy setting, not a performance metric. Count verified requests to understand crawling, then evaluate business outcomes through referral visits, engagement, and conversions. Keep those observations distinct from whether a page appears in a particular answer.
For a practical review, record a small set of relevant questions, the platform used, the observation date, and the cited URLs. Repeat consistently, recognizing that answers can vary. This is a monitoring method, not proof that a robots.txt change caused any movement.
Once intended access works, use our AEO Checker to assess the HTML you provide for answer-friendly structure. Its score is diagnostic, not confirmation that ChatGPT has indexed the page. Our AI Search Visibility guide covers the broader content and authority work that follows an access review.
Final Thoughts
Block GPTBot when potential training use conflicts with your content policy. Keep OAI-SearchBot available when ChatGPT search discovery remains a goal, and consider user-directed retrieval separately.
The useful outcome is a documented decision that survives deployment: valid rules, appropriate security controls, and checks against the live response. We recommend resolving that foundation before investing in more content or interpreting changes in AI referrals.
Frequently Asked Questions About Blocking GPTBot
Will blocking GPTBot remove my website from ChatGPT search?
Not by itself. OpenAI separates GPTBot training preferences from OAI-SearchBot search controls. Other access problems can still affect search crawling.[1]
Does blocking GPTBot delete content from existing models?
Do not assume so. The documented crawler control is not a promise of retrospective data deletion or reversal of completed model training.[1]
Can I block only one directory?
Yes. A GPTBot group can disallow a path prefix such as /research/. Check all applicable groups so a broader rule does not defeat the intended partial policy.[2]
Is blocking ChatGPT-User enough to stop search crawling?
No. OpenAI identifies OAI-SearchBot as the search crawler. ChatGPT-User supports certain user actions, for which robots.txt rules may not apply.[1]
Why do requests still appear after I add a block?
Investigate the requested resource, identity, and timestamp. A bot may fetch robots.txt to check policy, while an unrelated client can imitate a bot's user-agent string.
Can a robots.txt tester confirm my firewall allows OpenAI?
No. A rules parser evaluates the supplied file. Firewall behavior requires separate network-level checks and inspection of genuine, verified crawler requests.
Should I put private URLs in llms.txt?
No. Treat it as a public guide to content intended for discovery. Curated links are not authorization controls, and private resources still need enforced access restrictions.[2][3]
When should we review our crawler policy again?
Review it after a migration, robots.txt deployment, CDN change, or provider guidance update. Assign an owner so the policy remains an intentional business decision.
Sources:
- OpenAI. (n.d.). Overview of OpenAI crawlers. Retrieved October 15, 2026, from https://developers.openai.com/api/docs/bots
- Koster, M., Illyes, G., Zeller, H., & Sassman, L. (2022). Robots exclusion protocol (RFC 9309). RFC Editor. Retrieved October 15, 2026, from https://www.rfc-editor.org/rfc/rfc9309
- Howard, J. (2026, August 10). The /llms.txt file, v2. Retrieved October 15, 2026, from https://llmstxt.org/



