AI 크롤러 17종, 무엇을 허용하고 무엇을 막을까 — robots.txt·llms.txt 점검 가이드

"AI 크롤러 허용"이 한 줄짜리 설정이 아닌 이유

AEO·GEO를 시작하는 팀이 가장 먼저 묻는 것이 "robots.txt에 GPTBot을 열어두면 되나요?"입니다. 그런데 AI 회사들은 크롤러를 하나가 아니라 용도별로 쪼개서 운영합니다. 모델 학습을 위해 대량 수집하는 봇, 답변에 쓸 검색 인덱스를 만드는 봇, 사용자가 질문하는 순간 해당 페이지를 직접 열어보는 봇이 서로 다른 이름을 씁니다. 이름이 다르다는 것은 허용·차단 결정도 따로 할 수 있다는 뜻이고, 동시에 하나만 열어두고 안심하면 놓치는 부분이 생긴다는 뜻이기도 합니다.

세 가지 용도, 그리고 하나의 예외

학습용 크롤러는 언어모델을 만들거나 개선하기 위해 웹 콘텐츠를 대량 수집합니다. GPTBot, ClaudeBot, CCBot 등이 여기에 속합니다. 이 봇을 허용하는 것은 "내 콘텐츠를 모델 학습에 사용해도 좋다"는 정책 선택에 가깝고, 허용한다고 특정 질문에서 인용이 보장되는 것은 아닙니다.

검색·색인용 크롤러는 AI 검색 서비스가 답변에 쓸 인덱스를 구축합니다. OAI-SearchBot, Claude-SearchBot, PerplexityBot이 대표적입니다. 이 봇이 막혀 있으면 해당 서비스의 검색 기반 답변에 사이트가 후보로 오르기 어렵습니다. GEO 관점에서는 학습용보다 이쪽의 영향이 직접적입니다.

사용자 요청용 에이전트는 사용자가 대화 중 링크를 주거나 AI가 근거 확인이 필요할 때 그 순간 페이지를 가져옵니다. ChatGPT-User, Claude-User, Perplexity-User가 여기에 해당합니다. 일부 서비스는 이 유형이 사람의 요청을 대신하는 것이라는 이유로 robots.txt 적용 방식을 다르게 안내하므로, 각 사 문서를 확인해야 합니다.

하나의 예외는 제어 토큰입니다. Google-Extended와 Applebot-Extended는 별도로 크롤링하러 오는 봇이 아니라, 이미 수집된 콘텐츠를 생성형 AI 학습·활용에 쓸지를 알려주는 신호입니다. Google은 Google-Extended가 검색 포함 여부나 순위에 영향을 주지 않는다고 설명합니다. 이 점을 혼동해서 "구글 AI에서 빠질까 봐" 허용 여부를 잘못 판단하는 경우가 많습니다.

17종 한눈에 보기

운영사	User-Agent	용도
OpenAI	GPTBot	학습
OpenAI	OAI-SearchBot	검색·색인
OpenAI	ChatGPT-User	사용자 요청
Anthropic	ClaudeBot	학습
Anthropic	Claude-SearchBot	검색·색인
Anthropic	Claude-User	사용자 요청
Anthropic	anthropic-ai	구형 학습 식별자
Perplexity	PerplexityBot	검색·색인
Perplexity	Perplexity-User	사용자 요청
Google	Google-Extended	제어 토큰 (생성형 AI 학습·활용)
Apple	Applebot	검색·색인
Apple	Applebot-Extended	제어 토큰 (AI 학습 활용)
Meta	meta-externalagent	Meta AI 관련 수집
Meta	FacebookBot	Meta 서비스 관련 수집
Amazon	Amazonbot	Amazon 서비스(Alexa 등)
ByteDance	Bytespider	학습
Common Crawl	CCBot	공개 데이터셋 구축(다수 모델이 학습에 활용)

이 표의 용도 구분은 각 운영사가 공개한 문서를 바탕으로 한 일반적인 분류이며, 정책은 수시로 바뀝니다. 실제 적용 전에는 반드시 해당 사의 최신 크롤러 문서를 확인하세요.

무엇을 열고 무엇을 막을까

정답은 하나가 아니지만 판단 순서는 있습니다. 먼저 검색·색인용과 사용자 요청용은 AI 답변에 인용될 가능성과 직결되므로, 인용을 원한다면 열어두는 것이 기본입니다. 그다음 학습용은 콘텐츠 저작권 방침, 경쟁사 학습 활용에 대한 입장, 브랜드 정보가 모델 안에 정확히 반영되기를 바라는 정도에 따라 달라집니다. 브랜드 노출이 목적인 마케팅 사이트라면 대체로 허용하는 쪽이 유리하고, 유료 콘텐츠나 독점 데이터를 가진 사이트라면 학습용만 선별 차단하는 구성이 현실적입니다.

robots.txt 점검 — 자주 틀리는 네 곳

점검 항목	흔한 문제
와일드카드(User-agent: *) 블록	Disallow: / 로 전체를 막아두고 봇별 예외를 안 열어줌
봇 이름 표기	대소문자·하이픈 오타로 규칙이 매칭되지 않음 (예: Claude-SearchBot)
CDN·방화벽(WAF)	robots.txt는 열려 있는데 서버 앞단이 AI 봇 요청을 차단
본문 렌더링 방식	접근은 되지만 자바스크립트로만 그려지는 본문이 크롤러에게는 빈 페이지로 보임

특히 마지막 항목은 허용 설정만큼이나 중요합니다. 크롤러는 대체로 자바스크립트를 실행하지 않는 것으로 알려져 있기 때문에, 열어준 문으로 들어왔는데 보이는 것이 빈 껍데기라면 인용 가능성은 사실상 없습니다. 이 부분은 다음 글에서 별도로 다룹니다.

llms.txt, 어디까지 기대할까

llms.txt는 사이트 루트에 마크다운 형식으로 핵심 페이지를 안내해 AI가 사이트 구조를 이해하기 쉽게 하자는 제안형 규약입니다. 만드는 데 드는 비용이 낮아 갖춰두는 것을 권하지만, 주요 AI 서비스가 이를 인용 선정에 사용한다고 공식 확인한 사례는 현재 알려진 바 없습니다. 따라서 llms.txt는 "인용을 올리는 장치"가 아니라 "사이트의 정보 구조를 사람과 기계가 함께 읽을 수 있게 정리해 두는 보조 문서"로 두는 것이 정직한 위치 설정입니다.

marketing-pivot 사이트 점검 사례

저희 사이트의 robots.txt는 와일드카드 블록에서 전체를 허용하면서, 그 아래에 AI 봇 12종을 명시적으로 Allow로 적어 두었습니다. 그런데 AEGIS Insight의 AI 크롤러 진단은 17종을 검사합니다. 진단 도구를 점검하면서 학습용만 보던 목록을 실시간 답변용 봇까지 확장해 9종에서 17종으로 늘렸고, 그 과정에서 저희 robots.txt에 Claude-User, Applebot, meta-externalagent, FacebookBot, Amazonbot, Bytespider가 명시되어 있지 않다는 점도 확인했습니다.

다행히 와일드카드가 이미 전체를 허용하므로 명시되지 않은 봇도 막히지는 않습니다. 이 경험이 말해주는 것은 두 가지입니다. 첫째, 봇별 Allow는 와일드카드가 열려 있다면 실효보다 의도 표명의 성격이 강합니다. 둘째, 진단은 "robots.txt에 적혀 있는가"가 아니라 "실제로 막혀 있지 않은가"를 기준으로 판정해야 합니다. Insight는 와일드카드 차단 여부까지 함께 계산해 봇별 허용 상태를 판정합니다.

자가진단 — 지금 어디서 시작할지

먼저 도메인/robots.txt 원문을 열어 와일드카드 블록부터 확인하세요. 그다음 AEGIS Insight로 17종 허용 상태를 한 번에 점검하고, CDN·방화벽 로그에서 실제 응답 코드를 대조하면 됩니다. 구조 진단이 인용 준비도를 보여주는 선행 지표라는 점, 그리고 인용 자체를 자동 집계하는 도구는 아직 없다는 점은 AEO KPI 설계 글에서 다뤘습니다.

마치며

AI 크롤러 설정의 핵심은 "다 열어라"도 "다 막아라"도 아닙니다. 어떤 봇이 어떤 용도로 오는지 구분하고, 인용에 직결되는 검색·사용자 요청용은 막혀 있지 않은지 확인하며, 학습용은 콘텐츠 정책에 따라 의식적으로 결정하는 것입니다. 그리고 문을 열어준 뒤에는 그 안에서 크롤러가 실제로 무엇을 읽는지까지 확인해야 설정이 의미를 갖습니다.