AI 크롤러를 위한 robots.txt: 2026년 가이드

결론부터 말하면

"AI 봇"을 하나의 덩어리로 생각하는 것부터 그만두어야 한다. 경제적 계산이 완전히 다른 세 부류가 있고, 그 전부에 Disallow 한 줄을 똑같이 적용하는 것은 거의 언제나 잘못된 거래다.

학습 크롤러는 당신의 카탈로그로부터 배우게 해 달라고 요청하는 쪽이다. 검색 색인기는 그것을 인용할 수 있게 해 달라고 요청하는 쪽이다. 사용자 요청형 페처는 바로 지금 당신의 제품을 두고 질문하고 있는 고객이다. 첫 번째를 차단하는 것은 라이선스에 관한 결정이다. 세 번째를 차단하는 것은 걸려 온 전화를 끊는 일이다.

Forrester 조사에 따르면 기업 구매 담당자의 94%가 가장 최근 구매 과정에서 AI를 사용했다. AI user-agent를 달고 당신의 오리진에 도달하는 요청 가운데 상당수는 스크래핑이 아니다. BOM을 열어 놓고 결정을 앞둔 누군가다. robots.txt는 이 둘을 구분해야 하지만, 대부분은 그렇지 않다.

2026년에 중요한 모든 AI user-agent

이 표에서 으레 오해되거나 놓치는 지점이 다섯 가지 있으며, 명시해 둘 가치가 있다.

`Google-Extended`와 `Applebot-Extended`는 크롤러가 아니다. 둘 다 무언가를 가져오지 않는다. 이들은 권한 토큰이다. Google-Extended는 Googlebot이 이미 크롤링한 콘텐츠를 Gemini 학습과 답변 그라운딩에 쓸 수 있는지를 통제하고, Apple 문서는 Applebot-Extended가 "웹페이지를 크롤링하지 않으며" "Applebot user agent가 크롤링한 데이터를 어떻게 사용할지 결정하는 데에만 쓰인다"고 분명히 밝히고 있다. Applebot-Extended를 disallow해도 Siri, Spotlight, Safari 결과에서 빠지지는 않는다.

사용자 요청형 조회에서는 Anthropic이 예외다. OpenAI는 ChatGPT-User에 대해 "이 동작은 사용자에 의해 시작된 것이므로 robots.txt 규칙이 적용되지 않을 수 있다"고 밝힌다. Perplexity는 Perplexity-User가 "robots.txt 규칙을 대체로 무시한다"고 적는다. Google 문서는 자사 사용자 요청형 페처에 대해 "가져오기를 사용자가 요청한 것이므로 이 페처들은 robots.txt 규칙을 대체로 무시한다"고 말한다. Amazon은 Amzn-User가 "모든 robots.txt 지시문을 따르지는 않을 수 있다"고 밝힌다. 반면 Anthropic은 자사 봇이 robots.txt를 준수한다고 문서화하고, 사이트 소유자가 사용자 개시 요청을 통제할 때 쓸 수 있는 토큰으로 Claude-User를 명시한다. 전체를 한꺼번에 disallow하면 실제로 멈추는 쪽은 Claude다. 대부분이 의도한 것과 정반대의 결과다.

Amazon과 Meta는 각각 역할이 나뉜 봇 편대를 운영한다. Amazon은 Amazonbot 외에도 Amzn-SearchBot(Alexa와 Rufus를 포함한 검색 경험)과 Amzn-User(실시간 사용자 동작)를 문서화하고 있으며, 둘 다 생성형 AI 학습을 위해 크롤링하지는 않는다고 밝힌다. Meta는 학습과 색인용으로 Meta-ExternalAgent를, 사용자 요청 조회용으로 Meta-ExternalFetcher를 운영하는데, 후자는 robots.txt를 우회할 수 있다.

Bytespider는 robots.txt의 문제가 아니라 정책의 문제다. ByteDance는 robots.txt를 존중한다고 밝히지만, 사이트 운영자들의 보고는 널리 그 반대다. 막고 싶다면 엣지에서 막아야 하며, 이 파일에 기대서는 안 된다.

`Gemini-Deep-Research`에 관한 참고: Google이 공개한 크롤러 문서는 아직 이 토큰을 일반 크롤러에도, 사용자 요청형 페처에도 올려 두지 않았다. 그러나 실제로는 활발히 쓰이고 있고, 주요 유통사들은 이미 이름을 지목해 다루고 있다. Digi-Key의 robots.txt는 GPTBot, ChatGPT-User, OAI-SearchBot, PerplexityBot, Perplexity-User, ClaudeBot, Claude-User, Claude-SearchBot과 나란히 Google-Extended와 Gemini-Deep-Research를 명시적으로 허용한다. 함께 넣어 두는 편이 낫다. robots.txt에 인식되지 않는 토큰이 들어 있어도 해롭지 않다.

각 부류를 차단하면 실제로 무엇을 치르는가?

카탈로그가 이미 공개돼 있고 애그리게이터 전반에 복제돼 있는 제조사나 유통사라면, 학습 부류를 차단하는 것은 대체로 상징적인 행위다. 데이터는 유통사 리스팅과 Common Crawl을 거쳐 어차피 모델에 도달한다. 달라지는 것은 모델이 들고 있는 것이 누구의 데이터 버전이냐다. 나머지 두 부류를 차단하는 데에는 공개 카탈로그 기준으로 아무런 이득이 없다.

그대로 붙여 쓰는 robots.txt

레시피 A: 에이전트 가시성 극대화

카탈로그가 공개돼 있고 정확하게 발견되고 인용되는 것이 상업적 이익인 제조사와 유통사에게 맞는 기본값이다.

# --- Answer engines and user-triggered fetchers ---
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
User-agent: Amzn-SearchBot
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Allow: /

# --- Training crawlers and permission tokens ---
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Meta-ExternalAgent
User-agent: Amazonbot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Allow: /

# --- Everything else ---
User-agent: *
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/

Sitemap: https://www.example.com/sitemap.xml
Sitemap: https://www.example.com/sitemap-products.xml

레시피 B: 검색은 허용하고 학습은 거부

모델 학습에 기여하지 않기로 의도적으로 결정했지만 여전히 발견되고 인용되기를 원하는 조직에 맞는다. 대가가 무엇인지는 알아 두어야 한다. Google-Extended를 disallow하면 학습뿐 아니라 Gemini의 그라운딩에서도 콘텐츠가 빠진다.

User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
Allow: /

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Bytespider
User-agent: Meta-ExternalAgent
User-agent: Amazonbot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /

User-agent: *
Disallow: /account/

레시피 C: 카탈로그만 열고 나머지는 닫기

카탈로그와 문서 라이브러리가 드러내고 싶은 자산이고 나머지 영역은 잡음일 때 쓸 만하다.

User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: ClaudeBot
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
Disallow: /
Allow: /products/
Allow: /catalog/
Allow: /datasheets/
Allow: /documents/
Allow: /sitemap-products.xml

RFC 9309에서는 가장 길게 일치하는 경로 규칙이 이기므로, 해당 접두사에 대해서는 Allow 줄이 전면적인 Disallow: /를 덮어쓴다. 그렇게 되리라 가정하지 말고 결과를 검증해야 한다. 경계 사례에서의 파서 동작은 아직도 제각각이다.

통하는 방식으로 "아니오"를 표현하기: Content Signals

robots.txt가 통제하는 것은 접근이다. 바이트가 전달된 뒤의 사용에 대해서는 아무 말도 하지 않는다. 2025년 9월 24일에 공개된 Cloudflare의 Content Signals Policy는 같은 파일에 기계가 읽을 수 있는 사용 선호를 추가하며, 신호는 세 가지다. search(검색 색인 구축과 검색 결과 제공), ai-input(하나 이상의 AI 모델에 콘텐츠를 입력), ai-train(AI 모델의 학습 또는 파인튜닝).

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Disallow: /account/

Cloudflare는 관리형 robots.txt를 켜 둔 380만 개가 넘는 도메인에 search=yes, ai-train=no를 적용하면서, 짐작으로 채우는 대신 ai-input은 의도적으로 비워 두었다. 이것은 강제 수단이 아니라 표명된 선호다. 그러나 날짜가 찍힌, 기계가 읽을 수 있는 명확한 의사 표시이며, 그것만으로도 가질 가치가 있다.

침묵이 "아니오"가 되어 가는 이유

지난 20년 동안 robots.txt에 규칙이 없다는 것은 "예"를 뜻했다. 그 기본값이 인프라 계층에서 철회되고 있고, 이 파일을 한 번도 건드린 적 없는 제조사들이 자사 CDN에 의해 옵트아웃되고 있다.

• 2025년 7월 1일 — 웹의 약 5분의 1 앞단에 자리한 Cloudflare가 주요 인프라 제공자 가운데 처음으로 AI 크롤러를 기본 차단하기 시작했고, 새로 온보딩되는 모든 도메인에 허용 여부를 먼저 묻게 됐다.
• 2025년 9월 24일 — Content Signals Policy가 출시되면서 관리형 도메인 380만 개에 ai-train=no가 기본 적용됐다.
• 2026년 7월 1일 — Cloudflare가 2026년 9월 15일부터 신규 도메인, 기존 고객의 신규 사이트, 그리고 모든 기존 무료 요금제 고객에 대해 광고가 노출되는 페이지에서 Training 및 Agent 크롤러 범주를 기본 차단한다고 발표했다. Search는 계속 허용된다. Search와 Training을 함께 수행하는 다목적 크롤러에는 가장 제한적인 규칙이 적용된다.

마지막 항목은 정확히 읽어야 한다. 널리 잘못 인용되고 있기 때문이다. 적용 범위는 광고로 수익을 내는 페이지이며, 대부분의 제조사 카탈로그는 여기에 해당하지 않는다. 이미 당신에게 영향을 주고 있는 변화는 2025년 쪽이다. 사이트를 최근에 현대적인 CDN에 올렸거나 무료 요금제를 쓰고 있다면, 아무도 그렇게 결정한 적이 없는데도 이미 AI 크롤러를 거부하고 있을 수 있다. 가정하지 말고 확인해야 한다.

robots.txt는 요청이고, 강제하는 것은 WAF다

선의로 만든 설정이 대부분 여기서 무너진다. robots.txt는 규약을 따르는 클라이언트가 읽는 자발적 프로토콜이다. 반면 봇 관리 솔루션은 검증된 소스 IP로 분류하는 단단한 관문이고, 기본 규칙 세트는 브라우저처럼 보이지 않는 것이면 무엇이든 챌린지를 걸거나 차단하는 것이 보통이다. Allow: /를 읽고 나서 JavaScript 챌린지를 받은 크롤러는 파일에 무엇이라 적혀 있든 차단당한 것이다.

주요 운영 주체는 제대로 허용 목록에 넣을 수 있도록 각자의 IP 대역을 공개하고 있다.

로그에 찍힌 특정 주소가 정말 OpenAI인지 확인하려면 다음과 같이 한다.

python3 - <<'EOF'
import ipaddress, json, urllib.request
probe = ipaddress.ip_address("132.196.86.5")
data = json.load(urllib.request.urlopen("https://openai.com/gptbot.json"))
nets = [ipaddress.ip_network(p.get("ipv4Prefix") or p.get("ipv6Prefix"))
        for p in data["prefixes"]]
print(any(probe in n for n in nets if n.version == probe.version))
EOF

엣지 규칙 세 가지면 대부분이 해결된다.

1. 01봇 스코어 규칙이 발동하기 전에 검증된 IP 대역을 허용 목록에 넣는다. 적용 범위는 공개 카탈로그와 문서 경로로만 한정한다.
2. 02해당 경로는 JavaScript 챌린지와 속도 제한에서 제외한다. 브라우저가 아닌 클라이언트는 챌린지를 풀 수 없고, SKU 4만 개를 색인하는 크롤러는 사람 기준으로 맞춰 둔 속도 제한에 걸린다.
3. 03user-agent 문자열로 허용 목록을 만들지 않는다. 그것은 자유 입력 헤더다. IP로 먼저 매칭하고, 필요하면 그다음에 user-agent를 본다.

오리진마다 설정이 별개라는 점을 잊지 말아야 한다. 제품 사이트, 문서 서브도메인, CDN 호스트명은 각각 자기 몫의 robots.txt와 자기 몫의 WAF 정책이 필요하다.

로그에서 제대로 됐는지 어떻게 확인하는가?

로그로 검증하지 않은 설정은 가설일 뿐이다. 결과를 판단하기 전에 며칠은 두고 봐야 한다. 운영 주체는 robots.txt를 캐시하며, Meta 문서는 변경이 반영되기까지 최대 24시간이 걸릴 수 있다고 안내하고, Amazon은 자사 크롤러가 최근 30일 이내에 캐시된 사본을 쓸 수 있다고 밝힌다. 그다음에는 이렇게 한다.

grep -aiE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Gemini-Deep-Research|Applebot|Amazonbot|Bytespider|CCBot|Meta-External" access.log | wc -l

그다음에는 에이전트별, 상태 코드별로 쪼개 본다. 중요한 것은 이 숫자다.

awk '/GPTBot/ {print $9}' access.log | sort | uniq -c | sort -rn

확인해야 할 것은 다음과 같다.

1. 01에이전트별로 0이 아닌 요청량. 공개 카탈로그인데 72시간 동안 어떤 AI 에이전트로부터도 요청이 없었다면, 인기가 없는 것이 아니라 상류에서 차단당하고 있다는 뜻이다.
2. 022xx가 지배하는 상태 코드 분포. 403이 벽을 이루고 있다면 WAF가 robots.txt를 덮어쓰고 있는 것이다. 404가 줄지어 있다면 sitemap이나 내부 링크가 더 이상 존재하지 않는 URL을 가리키고 있는 것이다.
3. 03제품 경로만이 아니라 문서 경로도 나타나는지. /datasheets/가 한 번도 보이지 않는다면 기술 자료실은 보이지 않는 상태다.
4. 04말이 되는 응답 크기. 제품 URL에서 4~15KB짜리 200 응답이 반복된다면, 크롤러가 클라이언트에서 렌더링되는 빈 껍데기를 받고 있다는 뜻인 경우가 많다. 형식상으로는 허용된 것이지만 실질적으로는 쓸모가 없다.
5. 05사용자 요청형 에이전트가 아예 등장하는지. ChatGPT-User, Claude-User, Perplexity-User 트래픽은 구매자 관심을 실시간으로 보여 주는 신호에 가장 가깝다. 따로 떼어 보고할 가치가 있다.

흔한 실수

• 학습 크롤러를 겨냥한 일괄 규칙으로 사용자 요청형 페처까지 실수로 차단하는 것.
• robots.txt는 제대로 설정해 놓고 WAF는 손대지 않는 것. 스위치는 두 개이며 둘 다 올려야 한다.
• 문서 서브도메인과 DAM, CDN을 잊는 것. RFC 9309 기준으로 각각이 별개의 오리진이다.
• CSS와 JavaScript 자산에 대한 크롤러 접근을 막는 것. 텍스트만 읽는 크롤러에게는 상관없지만 Googlebot과 Applebot은 둘 다 렌더링하므로, 자산을 굶기면 그들이 보는 내용이 나빠진다.
• 애그리게이터가 당신의 데이터를 정확히 싣고 있으리라 가정하는 것. 애그리게이터가 싣고 있는 것은 언젠가 긁어 간 그 시점의 그 내용일 뿐이다.
• llms.txt를 대체재로 여기는 것. 이를 읽겠다고 약속한 주요 운영 주체는 없고, 로그를 보면 대체로 한 번도 요청되지 않는다.

Partsgraph는 2026년 8월 북미와 유럽, 아시아에 걸쳐 전 세계 유통사·제조사 도메인 984곳을 감사했다. 어떤 형태로든 명시적인 AI 크롤러 정책을 게시한 곳은 19%에 불과했고, 그중에서도 주요 AI 크롤러를 차단한 곳이 받아들인 곳보다 두 배 넘게 많았다. MCP 엔드포인트를 알린 곳은 한 군데도 없었다. AI 가시성 점수 중앙값은 100점 만점에 50점이었다. 이 격차는 아직 경쟁 우위로 굳어지지 않았다. 그리고 바로 그렇기 때문에, 잘 짜인 robots.txt는 여전히 제품 데이터 팀이 투입할 수 있는 가장 레버리지 높은 몇 시간의 작업 가운데 하나다.

AI 크롤러가 당신의 도메인에서 실제로 어디까지 도달할 수 있는지는 무료 Partsgraph 그레이더 [/audit](/audit)에서 확인할 수 있다.