Scope
AI crawler user-agent directory explains a focused part of AI crawler control instead of trying to replace security, legal review, or platform documentation.
Reference guide
A robots.txt decision starts with user agents, but it should not end there. The same company may operate separate crawlers for model training, AI search, user-triggered fetching, indexing, or infrastructure testing.
| User agent | Common policy question | Typical review note |
|---|---|---|
| GPTBot | Should public content be available for model training? | Often reviewed separately from AI search visibility. |
| OAI-SearchBot | Should pages be discoverable in OpenAI search experiences? | Blocking may reduce the chance of surfacing or citation. |
| ChatGPT-User | Should a user-requested fetch be allowed for public pages? | Usually treated differently from autonomous training crawlers. |
| ClaudeBot | Should Anthropic training or indexing crawlers access public content? | Review licensing, publisher strategy, and source documentation. |
| Claude-SearchBot | Should content appear in Claude-related search or retrieval experiences? | Consider visibility separately from training restrictions. |
| Google-Extended | Should content be used for certain Google AI products? | Do not confuse this with blocking Googlebot for normal Search. |
| CCBot | Should Common Crawl access public content? | Some teams block it because downstream use can be broad. |
| Bytespider | Should the crawler access publisher or product content? | Useful to review if bandwidth, licensing, or content control is a concern. |
Do not copy a user-agent list blindly. First decide whether the website needs broad visibility, strict content protection, balanced AI search participation, or internal clarity for a regulated workflow. Then test the final robots.txt file against the exact public URLs that matter.
Keep a dated note with each rule. A short note such as "Blocked GPTBot on 2026-07-30 because article archives are licensed separately, allowed OAI-SearchBot for public citation visibility" is more useful than a silent block list. It lets future owners understand the business reason behind the technical file.
AI crawler access control
AI Crawler User-Agent Directory for Robots.txt Planning is maintained for website owners, publishers, SaaS documentation teams, ecommerce operators, and SEO teams who need crawler policy operations. The goal is to help visitors complete a real task and leave with a robots.txt draft, llms.txt draft, crawler audit note, or crawler policy decision record, not only read a generic summary.
AI crawler user-agent directory explains a focused part of AI crawler control instead of trying to replace security, legal review, or platform documentation.
The page should help a visitor produce or validate a concrete policy artifact: robots.txt, llms.txt, a decision note, a test checklist, or an internal review summary.
The final result should be checked against live URLs, current crawler documentation, and the business reason for allowing or blocking each crawler class.
Field workflow
A crawler policy is valuable only when someone can explain it later. Use the notes below to turn this page into a saved decision record instead of a one-time copied snippet.
Before touching robots.txt, write one plain-language sentence: "We want normal search visibility, we want AI answer visibility for public pages, and we do not want training crawlers to collect licensed archives." If the intent is not clear, the file often becomes a long block list that nobody maintains. A short intent statement also helps you decide whether a future crawler belongs with training, search, user-triggered retrieval, or normal indexing.
Do not test only the homepage. Choose one article or documentation page, one product or pricing page, one sitemap URL, one login or account path, and one intentionally private path. The file should express different outcomes where the business logic is different. This matters because broad rules can accidentally block useful search pages while still failing to protect sensitive paths that need authentication.
Save the date, the old rule, the new rule, and the reason for the change. If traffic drops, citations disappear, or a crawler starts hitting expensive paths, that note makes debugging much faster. A good note names the crawler role, the URL group affected, and the review owner who can change the policy later.
This extra review layer is intentionally practical. It helps BotAccess Lab pages answer a real operational question, produce a durable artifact, and avoid the kind of thin, generic explanation that fails when a user has to make a production change.