대부분의 robots.txt는 중요한 크롤러가 하나뿐이던 시절에 쓰였습니다. 지금은 글 하나를 두고 학습 데이터를 모으는 봇, AI 검색 색인을 만드는 봇, 그리고 그 페이지에 대해 물어본 사용자 한 명을 대신하는 봇이 각각 찾아옵니다. 같은 회사가 이름만 바꿔 보내는 경우도 많고, 차단했을 때의 결과는 봇마다 다릅니다.
"AI를 막을까, 열어 둘까"는 잘못된 결정 단위입니다. 올바른 단위는 목적입니다. 이 글은 누가 크롤링하는지, 각각을 막으면 무엇을 잃는지 정리한 뒤, 회의에서 근거를 들어 설명할 수 있는 robots.txt 템플릿 세 가지를 제시합니다. GEO·AEO 가이드의 크롤러 정책 섹션보다 훨씬 깊이 들어갑니다.
AI 접근의 세 가지 유형
AI 에이전트는 세 부류로 나뉘고, 각각의 손익 구조는 정반대입니다.
- 모델 학습 크롤러는 학습 데이터가 될 수 있는 페이지를 수집합니다. 가치는 한 방향으로만 흐릅니다. 콘텐츠는 모델을 개선하지만, 돌아오는 링크는 없습니다.
- AI 검색 색인 봇은 AI 답변이 출처를 인용할 때 쓰는 색인을 만듭니다. 막으면 인용 후보에서 빠집니다.
- **사용자 요청형 페처(fetcher)**는 사용자가 어시스턴트에게 요청했기 때문에 특정 페이지 하나를 엽니다. 크롤링이라기보다, 한 단계 건너에서 움직이는 그 사용자의 브라우저에 가깝습니다.
| 에이전트 | 운영사 | 목적 | 차단하면 |
|---|---|---|---|
GPTBot |
OpenAI | 모델 학습 | 이후 페이지가 학습에서 제외되며, ChatGPT 검색에는 영향 없음 |
ClaudeBot |
Anthropic | 모델 학습 | 이후 페이지가 학습에서 제외 |
CCBot |
Common Crawl | 공개 웹 아카이브, 학습 데이터로 널리 쓰임 | 많은 모델 개발사가 쓰는 코퍼스에서 빠짐 |
meta-externalagent |
Meta | AI 학습 및 제품 색인 | 이후 페이지가 해당 용도에서 제외 |
Bytespider |
ByteDance | ByteDance AI 제품과 연관된 크롤링 | 준수한다면 제외되나, 준수 여부에 대한 운영자들의 경험은 엇갈림 |
OAI-SearchBot |
OpenAI | ChatGPT 검색 색인 | ChatGPT 검색 답변에 출처로 노출되지 않음 |
Claude-SearchBot |
Anthropic | Claude 검색 색인 | Claude 검색 답변에서 노출 감소 |
PerplexityBot |
Perplexity | Perplexity 검색 색인 | Perplexity에서 인용될 가능성이 낮아짐 |
ChatGPT-User |
OpenAI | 사용자 요청 시 페이지 조회 | 요청한 사용자에게 ChatGPT가 페이지를 열어 주지 못할 수 있음* |
Claude-User |
Anthropic | 사용자 요청 시 페이지 조회 | 해당 사용자를 위해 Claude가 페이지를 읽지 못할 수 있음* |
Perplexity-User |
Perplexity | 사용자 요청 시 페이지 조회 | 해당 사용자를 위해 Perplexity가 페이지를 열지 못할 수 있음* |
* 벤더가 사용자 요청에도 robots.txt를 적용하는 경우에 한합니다. 아래에서 자세히 다룹니다.
즉, 같은 벤더라도 한 유형은 허용하고 다른 유형은 거부할 수 있습니다. GPTBot은 막고 OAI-SearchBot은 허용하는 것은 일관된 입장이며, 인용을 중시하는 퍼블리셔 대부분이 결국 도달하는 지점입니다. 또한 모든 효과는 앞으로에만 적용됩니다. robots.txt는 앞으로의 수집을 제어할 뿐, 이미 수집된 데이터나 이미 학습된 모델에는 손대지 못합니다.
로그에 절대 나타나지 않는 제어 토큰
AI 정책에 등장하는 이름 중 일부는 크롤러가 아니라 제품 토큰입니다. 벤더의 일반 크롤러가 콘텐츠를 특정 목적에 쓰기 전에 확인하는, robots.txt상의 이름입니다.
| 토큰 | 실제로 가져가는 봇 | 제어하는 것 | 제어하지 않는 것 |
|---|---|---|---|
Google-Extended |
Googlebot | Gemini 모델 학습, Gemini 앱과 Vertex AI의 그라운딩 | Google 검색 포함 여부와 순위(Google 공식 설명) |
Applebot-Extended |
Applebot | Apple 파운데이션 모델 학습 | Siri, Spotlight 등 Apple 검색 기능 노출 |
함정은 여기에 있습니다. AI Overviews와 AI 모드는 Google 검색의 일부이므로 Google-Extended의 적용 대상이 아닙니다. 이를 제어하는 것은 일반 검색 제어 수단인 nosnippet, data-nosnippet, max-snippet, 최종적으로는 noindex이며, 이들은 일반 검색 스니펫에도 똑같이 영향을 줍니다. 이 글을 쓰는 시점에는 AI Overviews에서만 빠지는 스위치가 없습니다. Google의 최신 문서를 확인하세요.
이 토큰들은 액세스 로그에 절대 나타나지 않습니다. 방화벽에서 강제하려 해서도 안 됩니다. 실제 트래픽은 Googlebot과 Applebot이므로, 막는 순간 검색에서 사라집니다.
벤더마다 다르고, 계속 바뀝니다
에이전트 이름은 이 글을 쓰는 시점 기준으로 정확합니다. 하지만 이를 둘러싼 규칙은 이름만큼 안정적이지 않습니다.
- 사용자 요청형 페처는 회색 지대입니다. 이 에이전트에도 robots.txt를 따른다고 밝히는 벤더가 있는 반면, 사람이 직접 요청한 것이므로 robots.txt가 적용되지 않을 수 있다고 명시하는 벤더도 있습니다.
-User에이전트 차단은 보장이 아니라 요청으로 취급하세요. - 에이전트는 분리되고, 이름이 바뀌고, 새로 추가됩니다. 오래된 정책은 새 에이전트를 놓칩니다.
- 모든 크롤러가 자신을 밝히지는 않습니다. robots.txt는 들을 의사가 있는 봇에게만 통합니다.
벤더별 크롤러 문서를 북마크해 두고 분기마다 다시 읽으며, robots.txt에는 검토 날짜를 적어 두세요.
robots.txt에서 자주 틀리는 동작 원리
robots.txt는 RFC 9309로 표준화되어 있습니다. AI 정책 실패의 대부분은 전략이 아니라 파싱 규칙에 대한 오해에서 나옵니다.
크롤러는 하나의 그룹만 따릅니다: 자기 그룹
크롤러는 User-agent가 자기 이름과 일치하는 그룹만 따릅니다. User-agent: *는 전용 그룹이 없는 봇을 위한 대체 규칙이지, 다른 그룹이 상속받는 기본 레이어가 아닙니다. 가장 흔한 버그는 이렇게 생겼습니다.
# WRONG: GPTBot ignores the * group entirely
User-agent: *
Disallow: /dashboard/
Disallow: /account/
User-agent: GPTBot
Allow: /
이제 GPTBot은 /dashboard/와 /account/를 크롤링할 수 있습니다. 이름을 지정한 모든 그룹에 모든 제한을 반복해 적어야 합니다.
# RIGHT: each named group carries the full set of restrictions
User-agent: *
Disallow: /dashboard/
Disallow: /account/
User-agent: GPTBot
Disallow: /dashboard/
Disallow: /account/
Allow: /는 애초에 필요 없었습니다. 금지하지 않은 것은 모두 허용이기 때문입니다. 봇에게 Allow: /를 주는 스니펫을 기존 규칙 아래에 붙여 넣으면, 그 봇은 기존 규칙 전부에서 조용히 면제됩니다. 규칙 묶음 위에 User-agent 줄을 여러 개 쌓으면 하나의 그룹이 되므로, 공통 규칙을 한곳에서 관리할 수 있습니다.
경로는 접두어 매칭이고, 가장 긴 규칙이 이깁니다
Disallow: /app은/apple-pie도 막습니다. 접두어 전체를 막으려는 의도가 아니라면/app/으로 쓰세요.*는 임의의 문자열,$는 끝을 뜻합니다. 예:Disallow: /*.pdf$Allow와Disallow가 동시에 일치하면 더 긴 규칙이 이기고, 길이가 같으면Allow가 이깁니다.
robots.txt의 상태 코드 자체가 지시문입니다
RFC 9309에 따르면 404는 "규칙 없음", 5xx는 "전부 금지로 간주"입니다. 배포 한 번 잘못하면 사이트 전체가 열리거나 닫힐 수 있습니다. 크롤러가 이 파일을 최대 24시간 캐시할 수 있다는 점도 기억하세요.
자물쇠가 아니라 문에 붙인 안내문입니다
robots.txt는 권고일 뿐입니다. 준수하는 크롤러만 따르고, 나머지에게는 강제할 방법이 없습니다. 비공개 영역은 인증으로 보호하세요. 게다가 이 파일은 공개되어 있으므로 Disallow: /internal-admin-2024/는 광고나 다름없습니다.
세 가지 정책 템플릿
예시 경로는 실제 경로로 바꿔 쓰세요. 세 템플릿 모두 공통 제한을 그것이 필요한 모든 그룹에 넣습니다.
A. "인용은 환영, 학습은 사절"
학습 데이터는 제공하지 않으면서 인용은 받고 싶은 퍼블리셔를 위한 템플릿입니다.
# AI crawler policy - reviewed 2026-09-24
# Training crawlers and training tokens: opt out
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: meta-externalagent
User-agent: Bytespider
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /
# AI search indexers: welcome, minus the product
User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Disallow: /app/
Disallow: /account/
Disallow: /api/
# Everyone else, including user-triggered fetchers
User-agent: *
Disallow: /app/
Disallow: /account/
Disallow: /api/
Sitemap: https://www.example.com/sitemap.xml
검색 그룹은 지금은 *와 내용이 같지만, 봇 이름을 명시해 두면 의도가 기록으로 남습니다. Google-Extended는 학습뿐 아니라 그라운딩까지 포괄하므로, 차단하면 Gemini 앱의 그라운딩에서도 빠진다는 점에 유의하세요. Google 검색과 AI Overviews에는 영향이 없습니다.
B. "에디토리얼은 개방, 제품은 차단"
학습을 포함해 공개 콘텐츠의 도달 범위를 최대화하고, 애플리케이션 영역은 전혀 크롤링되지 않게 하려는 경우입니다.
# AI crawler policy - reviewed 2026-09-24
# One group for every bot: nothing to bypass
User-agent: *
Disallow: /app/
Disallow: /account/
Disallow: /settings/
Disallow: /api/
Disallow: /search
Sitemap: https://www.example.com/sitemap.xml
이름을 지정한 그룹이 없으니 실수로 면제되는 봇도 없습니다. 특정 크롤러 하나를 완전히 막으려면 Disallow: / 그룹을 추가하세요. 전면 차단은 새어 나갈 틈이 없습니다. 특정 크롤러를 일부만 다르게 다루려면, 먼저 *의 모든 줄을 그 그룹에 복사하세요.
C. 전면 차단
# AI crawler policy - reviewed 2026-09-24
# Opt out of AI training, AI search and user-triggered AI fetches
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: CCBot
User-agent: meta-externalagent
User-agent: Bytespider
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /
User-agent: *
Disallow: /app/
Disallow: /account/
Sitemap: https://www.example.com/sitemap.xml
잃는 것: ChatGPT 검색, Claude, Perplexity에서의 인용과 리퍼럴, 그리고 사용자가 요청했을 때 이 어시스턴트들이 페이지를 열어 주는 능력. 얻지 못하는 것: AI Overviews에서의 제외, 이미 수집된 데이터의 삭제, robots.txt를 무시하는 봇으로부터의 보호. 차단이 선호가 아니라 법적 요건이라면, robots.txt는 선언이고 강제는 CDN의 몫입니다.
누가 진짜 찾아왔는지 검증하기
user-agent 문자열은 아무것도 증명하지 않습니다
어떤 스크립트든 User-agent: GPTBot을 보낼 수 있습니다. 스크레이퍼가 유명 크롤러를 사칭하는 이유도 사이트들이 그 이름을 통과시켜 주기 때문입니다. 벤더를 탓하기 전에 정말 그 벤더인지부터 확인하세요.
역방향 DNS, 정방향 확인, 공개 IP 대역
Googlebot은 역방향 조회를 한 뒤, 정방향 조회에서 같은 IP가 나오는지 확인하는 방식으로 검증합니다.
$ host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
$ host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1
OpenAI와 Google은 크롤러의 IP 대역을 기계가 읽을 수 있는 형식으로 공개하고 있으며, 그렇게 하는 벤더가 몇 곳 더 있습니다. 아무것도 공개되지 않았다면 user-agent는 신원이 아니라 주장일 뿐입니다.
에이전트별로 로그 읽기
# Hits per AI agent (combined log format)
grep -oiE 'gptbot|oai-searchbot|chatgpt-user|claudebot|claude-searchbot|claude-user|perplexitybot|perplexity-user|ccbot|meta-externalagent|bytespider' access.log \
| tr '[:upper:]' '[:lower:]' | sort | uniq -c | sort -rn
# Top paths requested by one agent
grep -i 'gptbot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
금지한 경로에 대한 요청(그룹 설정 버그이거나 사칭), 처음 보는 에이전트, 대역폭 급증을 찾으세요. 크롤 예산 가이드에서처럼 URL이 아니라 경로 패턴 단위로 집계합니다. 그다음 실제 URL 인벤토리에 정책을 대 보세요. robots.txt와 사이트맵을 함께 읽는 크롤, 예컨대 DeepAnalyzer로 크롤하면 사이트맵의 URL이나 인용받고 싶은 페이지가 금지 접두어 아래에 들어가 있지 않은지 바로 드러납니다.
정말 중요하다면 엣지에서 강제하기
규칙을 따르지 않는 봇, 대역폭 문제, 계약상 의무가 있다면 CDN이나 WAF에서 강제하세요. 예를 들어 Cloudflare는 AI 크롤러 차단 기능을 제공하고, 대부분의 봇 관리 제품은 원시 문자열이 아니라 검증된 신원을 기준으로 매칭합니다. 반대로 robots.txt에서 초대한 봇을 엣지 설정이 막고 있지 않은지도 확인하세요.
robots.txt가 아닌 신호들
noai와 noimageai
<meta name="robots" content="noai, noimageai">는 어떤 표준에도 속하지 않으며, 주요 AI 크롤러가 이를 폭넓게 준수하겠다고 약속한 적도 없습니다. 넣어서 손해 볼 일은 없지만 의존해서는 안 됩니다. IETF의 AI Preferences 작업처럼 이용 선호를 표준화하려는 시도가 있지만, 벤더들이 준수를 약속하기 전까지는 보조 수단으로만 보세요.
llms.txt
llms.txt는 Answer.AI의 Jeremy Howard가 2024년에 내놓은 커뮤니티 제안입니다. /llms.txt에 두는 마크다운 파일로, 추론 시점에 언어 모델이 핵심 콘텐츠를 찾아가도록 안내합니다. 권한을 정하는 파일이 아니라 큐레이션된 지도입니다.
# Example Docs
> Example is an API for scheduling background jobs.
## Docs
- [Quickstart](https://www.example.com/docs/quickstart.md): Install the SDK and run a first job
- [API reference](https://www.example.com/docs/api.md): Endpoints, parameters, errors
## Optional
- [Changelog](https://www.example.com/changelog.md): Release history
개발자 문서라면 비용은 적고 쓸모는 있습니다. 하지만 공개적으로 알려진 범위에서, 주요 AI 검색 제공사 중 이를 순위나 인용 신호로 쓰겠다고 약속한 곳은 없습니다. 반나절이면 만들 수 있으니 만들어 두되, 트래픽은 기대하지 마세요.
정책의 비용과 효과 측정하기
AI 리퍼럴. 애널리틱스에서 리퍼러 기준 세그먼트를 만드세요.
chatgpt\.com|perplexity\.ai|claude\.ai|gemini\.google\.com|copilot\.microsoft\.com
ChatGPT 링크에는 utm_source=chatgpt.com이 붙는 경우가 많으니 캠페인 소스도 함께 확인하세요. 실제보다 적게 잡힌다고 보는 게 맞습니다. 앱에서 온 트래픽은 직접 유입으로 분류되고, AI Overviews 클릭은 일반 Google 자연 검색 유입과 구분되지 않습니다.
크롤러 요청량. 에이전트별 월간 요청 수, 전송 바이트, 금지 경로 요청 수를 봅니다. 한 벤더의 크롤 요청량과 그 벤더의 제품이 보내 주는 리퍼럴을 나란히 놓고 비교하세요.
읽을 수 있는가. 모든 AI 크롤러가 JavaScript를 실행하지는 않습니다. 정책을 열어 두어도 봇이 빈 껍데기만 받는다면 의미가 없습니다. 원본 HTML과 렌더링된 결과를 비교하고(Strong Mode는 헤드리스 브라우저로 페이지를 렌더링합니다), JavaScript 렌더링과 크롤 가능성을 참고하세요.
분기마다 다음을 반복합니다. 벤더 문서를 다시 읽고, 에이전트별 요청 수를 세어 상위 IP를 검증하고, 금지 경로 요청을 하나하나 추적하고, AI 리퍼럴을 이전 분기와 비교하고, 주요 어시스턴트에 대표 질문 10개를 물어 누가 인용되는지 기록한 뒤, robots.txt의 검토 날짜를 갱신합니다.
의사결정 체크리스트
- 인용받을 콘텐츠와 학습에서 뺄 콘텐츠가 문서로 정리되어 있고, 담당자가 정해져 있는가
- 이름을 지정한 모든 AI 그룹이
*의 제한을 빠짐없이 반복하는가 /robots.txt가 200을 반환하고, 배포할 때마다 확인하는가- 비공개 영역은 인증이 필요하고, robots.txt에 비밀 경로가 적혀 있지 않은가
- 방화벽에서
Google-Extended나Applebot-Extended를 "차단"하려는 사람이 없는가 - AI Overviews 노출 여부를 검색 제어 수단의 문제로 의식적으로 결정했는가
- CDN의 봇 설정이 robots.txt와 일치하는가
- AI 리퍼러 세그먼트가 있고, 로그를 매달 에이전트별로 검토하는가
- 분기 검토가 일정에 잡혀 있는가
자주 묻는 질문
GPTBot을 차단하면 ChatGPT에서 우리 콘텐츠가 사라지나요?
아닙니다. 학습용 수집을 앞으로 멈출 뿐, 이미 수집된 데이터를 지우지는 않습니다. ChatGPT 검색 노출은 OAI-SearchBot이, 요청 시 방문은 ChatGPT-User가 담당하므로 셋을 각각 따로 결정하세요.
Google-Extended를 차단하면 순위가 떨어지거나 AI Overviews에서 빠지나요?
Google은 Google-Extended가 Google 검색 포함 여부나 순위에 영향을 주지 않는다고 밝히고 있습니다. AI Overviews는 검색의 일부이므로 nosnippet, max-snippet 같은 검색 제어 수단을 따릅니다. 이 토큰이 제어하는 것은 Gemini 학습과 Gemini 앱의 그라운딩입니다.
금지한 경로를 봇이 크롤링하는 이유는 무엇인가요?
대개 그 봇에게 해당 제한이 빠진 전용 User-agent 그룹이 있어서, * 규칙이 애초에 적용되지 않은 경우입니다. 그게 아니라면 사칭입니다. 그룹 설정을 먼저 확인한 뒤, 역방향 DNS나 벤더의 공개 IP 대역으로 IP를 검증하세요.
llms.txt 파일을 추가해야 하나요?
개발자 문서를 운영한다면 추가하세요. 반나절이면 만들 수 있고, 어시스턴트가 올바른 페이지를 찾는 데 도움이 됩니다. 다만 주요 AI 검색 제공사 중 이를 순위나 인용 신호로 쓰겠다고 공개적으로 약속한 곳은 없으니 트래픽 변화는 기대하지 마세요.
정책은 얼마나 자주 다시 검토해야 하나요?
분기마다, 그리고 벤더가 새 에이전트를 발표할 때마다 검토하세요. 에이전트 이름과 robots.txt 처리 방식은 특히 사용자 요청형 페처를 중심으로 계속 바뀌고 있습니다. 로그에서 뒤늦게 발견하는 것보다 정기 검토가 훨씬 저렴합니다.