AI 크롤러 제어 가이드: OpenAI의 GPTBot, Anthropic의 Claude-Bot 등 AI 검색 봇의 자사 사이트 접근 허용 및 차단 세팅법

학습용 봇과 검색용 봇을 구분해야 하는 이유

OpenAI·Anthropic 같은 AI 기업들은 크롤러를 목적에 따라 두 종류로 나눠 운영합니다. GPTBot, Google-Extended, ClaudeBot 같은 학습용 크롤러는 웹 콘텐츠를 수집해 AI 모델을 훈련시키는 데 사용되고, OAI-SearchBot, Claude-SearchBot, PerplexityBot 같은 검색용 크롤러는 실시간으로 웹을 검색해 유저 질문에 답변을 생성할 때 그 자리에서 참조하는 용도로 사용됩니다. 이 둘을 구분하지 않고 "AI 봇"이라는 하나의 범주로 뭉뚱그려 전부 차단해버리면, 모델 학습에 콘텐츠가 쓰이는 것은 막을 수 있지만 동시에 실시간 AI 답변에 인용될 기회 자체도 함께 차단해버리는 결과를 낳을 수 있습니다.

학습은 막고 인용은 허용하는 설정은 어떻게 하나

2026년 기준 실무에서 흔히 쓰이는 전략은 학습용 봇 네 종류(GPTBot, ClaudeBot, CCBot, Google-Extended)는 robots.txt에서 차단하고, 검색용 봇 세 종류(OAI-SearchBot, Claude-SearchBot, PerplexityBot)는 허용하는 방식입니다. 이렇게 설정하면 자사 콘텐츠가 AI 모델의 학습 데이터로 무단 활용되는 것은 막으면서도, 유저가 실시간으로 AI에 질문했을 때 자사 콘텐츠가 참조·인용될 자격은 그대로 유지할 수 있습니다. 이 구분은 이 과목 전체가 추구하는 GEO 목표(AI 답변에 인용되기)와 직접 연결되는 매우 실무적인 설정으로, 검색용 봇까지 실수로 차단해버리면 GEO 전략 전체가 무력화될 수 있다는 점을 명확히 인지해야 합니다.

robots.txt만으로 완전한 차단이 안 되는 이유

구글봇·GPTBot·ClaudeBot 같은 주요 크롤러는 대체로 robots.txt의 지시를 준수하지만, 바이트스파이더(ByteSpider) 같은 일부 크롤러는 이 규칙을 무시하고 콘텐츠를 수집하는 것으로 알려져 있습니다. robots.txt는 어디까지나 "이 사이트에 방문하는 봇들에게 보내는 요청"이지, 강제로 접근을 막는 기술적 장벽은 아니기 때문에, robots.txt만으로 모든 학습 크롤러를 완전히 차단할 수 있다고 기대해서는 안 됩니다. 콘텐츠 무단 학습을 정말 엄격하게 막고 싶다면 robots.txt를 1차 방어선으로 두고, 서버 단에서 특정 User-Agent나 IP 대역을 직접 차단하는 추가 조치를 함께 고려해야 합니다.

robots.txt 설정은 왜 기술 문제가 아니라 사업적 판단 문제인가

학습용 봇을 차단할지 허용할지는 단순한 기술 설정이 아니라, "우리 콘텐츠가 AI 모델 학습에 쓰이는 것을 어떻게 볼 것인가"라는 사업적 판단이 먼저 서야 하는 문제입니다. 일부 브랜드는 콘텐츠가 AI 학습에 활용되는 것 자체를 장기적으로 자사 브랜드 노출을 늘리는 기회로 보고 학습용 봇도 허용하는 반면, 콘텐츠 저작권이나 경쟁 정보 유출을 우려하는 브랜드는 학습용 봇을 적극적으로 차단하는 선택을 하기도 합니다. 이 결정은 마케팅팀 혼자 내리기보다, 법무·콘텐츠 저작권 정책과 함께 검토한 뒤 회사 차원의 방침으로 정리하는 것이 안전합니다.

GEO 관점에서 가장 피해야 할 실수는 무엇인가

GEO 성과를 원하는 담당자가 저지르기 쉬운 가장 흔한 실수는, "AI 봇은 다 위험하다"는 막연한 우려로 검색용 봇까지 포함해 모든 AI 관련 크롤러를 한꺼번에 차단해버리는 것입니다. 이렇게 되면 학습 데이터 유출은 막을 수 있어도, 이 과목 전체가 추구하는 목표인 "AI 답변에 인용되기"라는 성과 자체를 스스로 차단하는 자기모순적인 결과가 됩니다. robots.txt를 설정하기 전에 반드시 각 봇의 이름과 목적(학습용인지 검색용인지)을 정확히 확인하고, 최신 봇 목록은 계속 추가되므로 주기적으로 이 목록을 업데이트해 관리하는 루틴이 필요합니다.

설정을 바꾼 뒤에는 어떻게 검증해야 하나

robots.txt를 수정한 뒤에는 실제로 의도한 대로 봇이 접근·차단되고 있는지 검증하는 과정이 필요합니다. 서버 로그에서 각 봇의 User-Agent별 접근 기록을 확인하면, 검색용 봇이 실제로 사이트를 방문하고 있는지, 차단하려던 학습용 봇의 접근이 실제로 줄었는지를 직접 확인할 수 있습니다. 설정만 바꾸고 실제 효과를 검증하지 않으면, 오타나 문법 오류로 인해 의도와 다르게 동작하고 있는 상황을 오랫동안 모른 채 지나칠 수 있습니다. 이 검증은 설정을 바꿀 때마다 매번 진행하는 것이 안전하며, 특히 새로운 AI 봇이 계속 등장하는 만큼 분기 단위로 봇 목록 자체를 재점검하는 루틴도 함께 갖춰두는 것이 좋습니다.

허용해 뒀는데도 못 읽는 경우: 자바스크립트로만 그린 본문

robots.txt에서 검색용 봇을 열어 두는 것은 출입을 허락하는 일일 뿐, 읽을 거리가 있다는 보장은 아닙니다. Vercel이 자사 네트워크의 AI 크롤러 요청을 분석한 결과, GPTBot·OAI-SearchBot·ChatGPT-User·ClaudeBot·PerplexityBot 등은 자바스크립트 파일을 내려받기만 하고 실행하지 않았습니다. 실행하는 쪽은 구글 인프라를 쓰는 Gemini와 브라우저 방식으로 페이지를 그리는 AppleBot이었습니다. 한 회사의 로그 분석이고 크롤러는 계속 바뀌지만, 결론은 분명합니다. 본문과 FAQ 답처럼 인용되길 바라는 정보는 자바스크립트 없이도 원본 HTML에 있어야 어느 크롤러에게도 안전합니다. 확인은 페이지 소스 보기로 원본 HTML에 본문이 있는지 보는 것에서 시작합니다.

검증할 때 하나 더 조심할 점이 있습니다. User-Agent만 GPTBot으로 바꿔 보낸 요청이 403이라고 해서 실제 GPTBot이 막혔다고 단정하면 안 됩니다. 봇 관리 솔루션은 흉내 낸 요청을 따로 막을 수 있으니, 실제 접근은 위에서 말한 서버 로그로 확인합니다.

AI 크롤러 설정 체크리스트

• 학습용 봇과 검색용 봇을 구분해서 robots.txt 규칙을 설정했는가
• 검색용 봇(OAI-SearchBot 등)을 실수로 차단하고 있지 않은가
• robots.txt를 준수하지 않는 크롤러에 대한 서버 단 추가 대응이 필요한지 검토했는가
• 학습용 봇 허용 여부에 대한 회사 차원의 방침이 명확히 정리돼 있는가
• 인용되길 바라는 본문·FAQ 답이 자바스크립트 없이 원본 HTML에 들어 있는가