AI 크롤러 robots.txt 설정법 — GPTBot·클로드봇

결론부터 말하면 이렇다. "AI 크롤러는 무조건 막아야 한다" 혹은 "무조건 열어 둬야 한다"는 말은 둘 다 틀렸다. 같은 회사 안에서도 학습용 크롤러와 실시간 검색·답변용 크롤러의 역할이 전혀 다르기 때문에, robots.txt 한 줄로 뭉뚱그려 처리하면 원하는 결과를 얻지 못한다.

GPTBot을 막으면 챗GPT의 미래 학습 데이터에서는 빠지지만, 지금 당장 챗GPT가 웹 검색으로 우리 페이지를 찾아 답변에 인용하는 것까지 막지는 못한다. 그 역할은 OAI-SearchBot과 ChatGPT-User라는 완전히 다른 크롤러가 맡고 있어서다. 크롤러 이름 하나만 알고 있으면 오히려 잘못된 설정을 하게 된다는 것이 이 글에서 가장 먼저 짚어야 할 사실이다.

2026년 현재 robots.txt로 개별 제어할 수 있는 AI 크롤러는 열 종류를 훌쩍 넘는다. 게다가 이 목록은 고정되어 있지 않다. 새 서비스가 나올 때마다 새 이름의 크롤러가 추가되고, 기존 크롤러의 역할이 세분화되기도 한다. 한 번 설정해 두고 잊어버릴 수 있는 영역이 아니라는 뜻이다.

이 글은 각 크롤러의 정확한 역할, 목적별로 바로 쓸 수 있는 실전 코드, 그리고 규칙을 지키지 않는 크롤러가 실제로 존재한다는 사실까지 예시 중심으로 정리한다. 크롤러 이름을 외우는 것 자체가 목표가 아니라, "학습용인가, 검색·에이전트용인가"를 구분하는 사고방식을 갖추는 것이 이 글의 진짜 목표다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• OpenAI·Anthropic 등 주요 AI 기업은 학습용·검색용·에이전트용 크롤러를 각각 따로 운영하며, 이름이 다르면 목적도 다르다
• 같은 회사 크롤러라도 하나만 차단하고 나머지는 그대로 두면 의도와 반대되는 결과가 나올 수 있다
• 2025년 8월에는 퍼플렉시티(Perplexity)가 robots.txt 차단을 우회해 접근했다는 사실이 클라우드플레어 조사로 드러났다
• 2025년 9월에는 클라우드플레어가 콘텐츠 신호(Content-Signal)라는 새로운 robots.txt 표기법을 제안했지만, 아직 모든 크롤러가 지키기로 약속한 표준은 아니다
• AI 크롤러를 막을지 열지는 정답이 하나로 정해진 문제가 아니라, GEO(생성형엔진최적화) 전략과 함께 판단해야 하는 선택이다

이 글은 SEO를 처음 접하는 사업가와 실무자를 기준으로 쓴다. robots.txt 자체의 기본 문법(User-agent, Disallow, Allow, Sitemap)은 robots.txt란 무엇인지 정리한 글에서 이미 다뤘으므로, 이 글에서는 그 기초 위에서 AI 크롤러에 특화된 실전 설정만 집중적으로 다룬다. 기본 문법이 낯설다면 그 글을 먼저 읽고 오는 편이 이해가 빠르다.

실제로 상담을 하다 보면 "AI한테는 우리 콘텐츠 다 보여줘도 되나요, 아니면 막아야 하나요"라는 질문을 자주 받는다. 이 질문에는 정답이 하나로 정해져 있지 않다는 것이 이 글의 첫 번째 결론이지만, 적어도 "몰라서 방치하는 상태"만큼은 벗어나야 한다는 것이 두 번째 결론이다. 지금 robots.txt를 열어 본 적이 없다면, 이 글을 읽는 지금이 처음 확인해 볼 좋은 기회다.

AI 크롤러란 정확히 무엇이고, 왜 따로 다뤄야 하나?

AI 크롤러란 인공지능 모델의 학습이나 AI 검색·챗봇 서비스를 위해 웹페이지를 자동으로 읽어 가는 프로그램이다. 구글봇(Googlebot)처럼 전통적인 검색엔진 로봇과 큰 틀에서는 비슷하지만, 수집한 콘텐츠를 쓰는 목적이 다르다는 점이 핵심이다.

전통적인 검색엔진 로봇은 콘텐츠를 읽어 검색 결과 목록에 올리는 것이 목적이다. 반면 AI 크롤러는 크게 세 가지 목적 중 하나(또는 여러 개)를 위해 움직인다.

목적	하는 일	대표 예시
모델 학습	콘텐츠를 대규모로 수집해 AI 모델을 훈련하는 데이터로 사용	GPTBot, ClaudeBot, Google-Extended
실시간 답변(에이전트)	사용자가 질문을 던진 순간, 그 질문에 답하려고 즉시 특정 페이지를 조회	ChatGPT-User, Claude-User
AI 검색 색인	챗봇 안의 검색 기능을 위해 구글봇처럼 주기적으로 재방문하며 색인 구축	OAI-SearchBot, Claude-SearchBot

이 구분이 왜 중요한가. 학습용 크롤러를 막는다고 실시간 답변용 크롤러까지 함께 막히는 것이 아니기 때문이다. 반대의 경우도 마찬가지다. 이 셋을 하나로 뭉뚱그려 생각하면, "GPTBot을 막았으니 챗GPT에서는 이제 우리 사이트가 전혀 안 나올 것"이라는 흔한 오해로 이어진다.

AI 크롤러는 이름 하나가 아니라 회사마다 최소 두세 개씩 묶음으로 움직인다. 하나만 보고 판단하면 절반만 맞는 설정이 된다.

비유하자면 이렇다. 학습용 크롤러는 "책을 통째로 사서 서재에 꽂아 두는 손님"에 가깝고, 검색·에이전트용 크롤러는 "서점에 들러 필요한 페이지만 확인하고 나가는 손님"에 가깝다. 전자를 막는다고 후자의 발걸음까지 막히지는 않으며, 두 손님을 대하는 태도는 사업 성격에 따라 얼마든지 다를 수 있다.

이 비유를 조금 더 밀어붙이면, 검색·색인용 크롤러는 "책 내용을 목차 카드에 옮겨 적어 두는 사서"에도 비유할 수 있다. 이 사서는 책을 통째로 가져가지 않고, 필요할 때마다 다시 찾아와 최신 내용으로 카드를 갱신한다. 학습용 크롤러가 한 번 방문으로 콘텐츠를 통째로 흡수해 가는 것과는 방문 패턴 자체가 다르다는 뜻이다.

또 하나 짚어야 할 차이가 있다. 전통적인 검색엔진 로봇은 국제 표준(RFC 9309)에 따라 robots.txt를 성실히 지키는 것이 업계 관행으로 굳어져 있다. 하지만 AI 크롤러 생태계는 아직 역사가 짧고, 일부 서비스는 "이것은 크롤러가 아니라 사용자를 대신하는 에이전트"라는 논리로 robots.txt 적용 대상 자체가 아니라고 주장하기도 한다. 이 논쟁은 뒤에서 실제 사례로 다시 다룬다.

2026년 현재 활동 중인 주요 AI 크롤러는 무엇인가?

지금 웹에서 실제로 활동 중인 AI 관련 크롤러를 회사별로 정리하면 아래와 같다. 표를 훑어보는 것만으로도 "우리 사이트에 어떤 손님들이 다녀가고 있는지" 감이 잡힌다.

크롤러 이름	운영사	목적
GPTBot	OpenAI	AI 모델(GPT 계열) 학습용 데이터 수집
ChatGPT-User	OpenAI	사용자가 챗GPT에서 질문할 때 실시간으로 특정 페이지 조회
OAI-SearchBot	OpenAI	챗GPT 검색 기능의 색인 구축·유지
ClaudeBot	Anthropic	AI 모델(클로드 계열) 학습용 데이터 수집
Claude-User	Anthropic	사용자 질문에 답하기 위한 실시간 웹페이지 조회
Claude-SearchBot	Anthropic	검색 결과 품질·관련성 향상을 위한 색인용 크롤링
Google-Extended	구글	제미나이 등 생성형 AI 모델의 학습 여부 제어(일반 구글봇과 별개)
Applebot-Extended	애플	애플 AI 기능 학습 여부 제어(일반 Applebot과 별개)
PerplexityBot	퍼플렉시티	AI 검색·답변 생성을 위한 콘텐츠 수집
Perplexity-User	퍼플렉시티	사용자 질문에 실시간으로 응답하기 위한 페이지 조회
Meta-ExternalAgent	메타	AI 모델 학습용 데이터 수집
Meta-ExternalFetcher	메타	사용자가 제공한 링크를 실시간으로 가져오는 용도
CCBot	Common Crawl	공개 데이터셋 수집(여러 AI 기업이 재활용)

여기에 더해 아마존의 Amazonbot, 중국 바이트댄스가 운영하는 Bytespider, 그리고 코히어(Cohere)의 cohere-ai처럼 특정 서비스에 종속된 크롤러도 있다. 이런 크롤러는 방문 빈도가 상대적으로 낮거나 국내 사이트에서는 자주 마주치지 않는 편이지만, 서버 로그에 낯선 이름이 찍혔을 때 무엇인지 확인할 수 있도록 이름 정도는 알아 두는 편이 좋다.

이 표에서 가장 먼저 눈여겨봐야 할 지점은 "회사 하나에 크롤러가 하나가 아니다"라는 사실이다. 다음 섹션에서 이 구조를 조금 더 깊게 들여다본다.

여기서 각 크롤러를 조금 더 구체적으로 짚어 두면 실전에서 헷갈릴 일이 줄어든다.

Google-Extended는 일반 검색 결과와 AI 오버뷰를 담당하는 구글봇(Googlebot)과는 완전히 별개의 크롤러다. Google-Extended를 차단해도 구글 검색 노출에는 영향이 없으며, 오직 제미나이 같은 생성형 AI 모델의 학습 데이터로 콘텐츠가 쓰이는지 여부만 제어한다. 이 둘을 혼동해 검색 노출까지 줄었다고 오해하는 사례가 실무에서 자주 나온다.

Applebot-Extended 역시 애플 지도·시리 검색에 쓰이는 일반 Applebot과는 분리된 존재다. 애플의 온디바이스·생성형 AI 기능이 콘텐츠를 학습에 활용하는지 여부만 이 크롤러 하나로 결정된다.

PerplexityBot과 Perplexity-User는 이름은 비슷하지만 역할이 다르다. PerplexityBot은 답변 품질을 위한 콘텐츠 수집용이고, Perplexity-User는 사용자가 실제로 질문을 던졌을 때 그 순간 특정 페이지를 조회하는 실시간 에이전트다. 이 구분이 왜 중요한지는 바로 다음 섹션에서 실제 논란 사례로 다시 설명한다.

Meta-ExternalAgent는 메타의 학습용 크롤러이고, Meta-ExternalFetcher는 성격이 전혀 다르다. 공식 문서에 따르면 Meta-ExternalFetcher는 "사용자가 직접 제공한 링크를 가져오는" 용도이며, 이 경우 사용자 제공 주소에 한해 robots.txt 규칙을 우회할 수 있다고 명시되어 있다. 즉 이 크롤러는 애초에 robots.txt만으로는 완전히 통제되지 않는 성격을 가진다.

CCBot은 커먼크롤(Common Crawl)이라는 비영리 단체가 운영하는 크롤러로, 이 단체가 수집해 공개하는 데이터셋은 여러 AI 기업이 자사 모델 학습에 재활용한다. CCBot 하나를 차단한다고 이미 배포된 과거 데이터셋에서 콘텐츠가 빠지는 것은 아니라는 점도 함께 알아 두어야 한다.

이 목록을 처음 접하면 이름이 많아 부담스러울 수 있다. 하지만 실무에서 매일 이 이름을 전부 외우고 있을 필요는 없다. robots.txt 파일 안에 한 번 정확히 적어 두면, 그 뒤로는 크롤러가 스스로 규칙을 읽고 판단한다. 사람이 해야 할 일은 처음에 정확히 설정하고, 새 크롤러가 등장했을 때 목록에 추가하는 정도다.

학습용 크롤러와 검색·에이전트용 크롤러, 왜 다르게 다뤄야 하나?

같은 회사의 크롤러라도 무엇을 차단하느냐에 따라 결과가 완전히 달라진다. OpenAI와 Anthropic의 사례로 구체적으로 살펴본다.

OpenAI: GPTBot·ChatGPT-User·OAI-SearchBot

OpenAI는 역할이 다른 크롤러 세 개를 운영한다. 각각을 막았을 때 실제로 일어나는 일은 이렇다.

크롤러	막으면 일어나는 일
GPTBot만 차단	향후 모델 학습 데이터에서 제외. 챗GPT의 실시간 검색·인용에는 영향 없음
ChatGPT-User만 차단	사용자가 실시간으로 챗GPT에 질문했을 때 우리 페이지를 조회해 답하는 기능이 막힘
OAI-SearchBot만 차단	챗GPT 검색 기능의 색인에서 제외되어 검색형 질문 답변에서 노출되기 어려워짐
셋 다 차단	학습 기여, 실시간 인용, 검색 노출을 모두 포기하는 선택

GPTBot 하나만 막아 놓고 "우리는 AI 크롤러를 차단했다"고 안심하는 경우가 실무에서 흔히 보인다. 실제로는 세 크롤러 중 하나만 처리한 것이다.

콘텐츠가 챗GPT 답변에 인용되기를 원하면서 학습 데이터로는 쓰이지 않길 원한다면, GPTBot만 차단하고 ChatGPT-User와 OAI-SearchBot은 열어 두는 절충안이 가능하다. 반대로 AI 관련 노출 자체를 원하지 않는다면 세 개 모두 차단하면 된다.

Anthropic: ClaudeBot·Claude-User·Claude-SearchBot

Anthropic도 2026년 초 크롤러 문서를 정비하면서 이 구조를 더 명확히 밝혔다. 세 크롤러의 역할은 이렇다.

크롤러	목적
ClaudeBot	공개 웹 콘텐츠를 수집해 클로드 모델 학습에 사용
Claude-User	사용자 질문에 답하기 위해 특정 웹페이지 콘텐츠를 실시간으로 조회
Claude-SearchBot	검색 결과의 품질과 관련성을 높이기 위한 색인용 크롤링

구조 자체는 OpenAI와 거의 동일하다. 학습(ClaudeBot)과 실시간 답변·검색(Claude-User, Claude-SearchBot)이 분리되어 있다는 점이 핵심이며, 이 셋을 각각의 User-agent 블록으로 나눠 다뤄야 원하는 결과를 얻을 수 있다.

구글·애플·메타는 왜 크롤러가 두 개뿐인가?

구글과 애플은 OpenAI·Anthropic과 달리 크롤러를 세 개가 아니라 두 개 단위로 나눠 둔 경우가 많다. 구글은 일반 검색·AI 오버뷰용 Googlebot과, 생성형 AI 모델 학습 여부만 결정하는 Google-Extended로 나뉜다. 애플도 지도·시리 검색용 Applebot과, 애플 AI 기능 학습 여부를 결정하는 Applebot-Extended로 나뉜다.

이 구조에서 알 수 있는 공통점은, "일반 검색·서비스용"과 "생성형 AI 학습용"을 분리해 두었다는 점에서는 OpenAI·Anthropic과 방향이 같다는 것이다. 다만 구글·애플은 "실시간 에이전트 조회"라는 세 번째 갈래를 아직 별도 이름으로 분리해 두지 않았다는 차이가 있다. 메타는 반대로 학습용(Meta-ExternalAgent)과 사용자 요청 조회용(Meta-ExternalFetcher)으로 나뉘어 있어 OpenAI·Anthropic의 구조에 조금 더 가깝다.

결국 회사마다 크롤러를 나누는 기준과 개수는 조금씩 다르지만, "학습에 쓰이는가"와 "지금 이 순간 검색·답변에 쓰이는가"를 구분한다는 원칙만큼은 공통적으로 자리 잡아 가고 있다. 이 원칙 하나만 기억해 두면, 새로운 회사의 크롤러를 처음 마주치더라도 어떤 질문을 먼저 던져야 할지 알 수 있다.

회사 이름만 보고 크롤러 하나로 뭉뚱그려 판단하지 말고, 학습·에이전트·검색 세 갈래로 나눠 각각 결정하는 것이 2026년 기준 올바른 접근이다.

AI 크롤러 트래픽은 실제로 얼마나 늘었나?

빠르게, 그리고 계속 늘고 있다. 클라우드플레어가 자사 네트워크의 실제 요청량을 분석해 공개한 자료에 따르면, 2024년 5월부터 2025년 5월 사이 GPTBot의 요청 비중은 전체 크롤러 트래픽의 약 2.2퍼센트에서 7.7퍼센트로, 1년 만에 약 305퍼센트 늘었다. 같은 기간 챗GPT의 실시간 조회용 크롤러인 ChatGPT-User의 요청량은 약 2,825퍼센트, 퍼플렉시티봇은 기존 수치 자체가 매우 낮았던 만큼 수만 퍼센트 단위로 급증했다.

물론 이 시기에도 구글봇이 전체 크롤러 트래픽의 절반 정도를 차지하며 여전히 압도적인 1위였다. AI 크롤러가 빠르게 늘고 있다고 해서 전통적인 검색엔진 크롤링이 줄어든 것은 아니라는 점도 함께 봐야 한다.

이런 흐름 속에서 클라우드플레어는 2025년 7월, 신규로 만드는 도메인에 한해 AI 크롤러 접근을 기본값으로 차단하는 정책을 발표했다. 과거에는 사이트 운영자가 하나하나 직접 차단 규칙을 걸어야 했다면, 이제는 반대로 명시적으로 허용하지 않는 한 기본이 차단인 구조로 바뀐 것이다. 동시에 콘텐츠 제작자가 AI 기업에 크롤링 대가를 받고 접근을 허용할 수 있는 "페이 퍼 크롤(Pay Per Crawl)"이라는 유료 마켓플레이스 개념도 함께 선보였다.

이 정책은 클라우드플레어의 네트워크를 쓰는 사이트에 한정된 이야기이지만, 방향성은 뚜렷하다. AI 크롤러 접근을 "당연히 열려 있는 것"이 아니라 "협상 가능한 선택"으로 다루는 흐름이 업계 전반에 퍼지고 있다.

신규로 사이트를 여는 사업자라면, 사용 중인 호스팅사나 CDN이 AI 크롤러를 기본값으로 어떻게 처리하고 있는지부터 확인하는 것이 순서다. 아무 설정도 하지 않았는데 AI 검색에서 우리 콘텐츠가 전혀 인용되지 않는다면, robots.txt 문제가 아니라 CDN·호스팅 단의 기본 정책 때문일 수도 있다.

이 성장세를 두고 "그러니 AI 크롤러를 막아야 위기를 피한다"고 해석하는 시각도 있고, "그러니 AI 크롤러를 열어 두어야 새로운 유입 채널을 놓치지 않는다"고 해석하는 시각도 있다. 두 해석 모두 일리가 있으며, 이 글이 굳이 하나의 정답을 강요하지 않는 이유도 여기에 있다. 중요한 것은 이 숫자가 보여주는 변화의 속도 자체를 인지하고, 자기 사업에 맞는 판단을 의식적으로 내리는 것이다.

AI 크롤러 관련 규칙은 왜 이렇게 자주 바뀌나?

이 영역의 규칙이 몇 년 새 계속 바뀌어 온 것은 이 생태계 자체가 아직 자리를 잡아가는 중이기 때문이다. 지금까지의 흐름을 짧게 짚어 두면, 앞으로 새 크롤러가 등장했을 때도 당황하지 않고 같은 틀로 이해할 수 있다.

시점	주요 변화
2023년	OpenAI가 GPTBot을 공개하며 robots.txt로 학습용 크롤러를 개별 차단할 수 있는 방식을 처음 제시
2023년	구글이 Google-Extended를 도입해, 일반 검색과 AI 모델 학습 여부를 분리 제어하는 구조를 선보임
2024–2025년	Anthropic·메타·퍼플렉시티 등이 잇달아 각자의 크롤러를 문서화하며 생태계 참여자가 급격히 늘어남
2025년 7–8월	클라우드플레어의 신규 도메인 기본 차단 정책 발표, 이어 퍼플렉시티의 robots.txt 우회 논란
2025년 9월	클라우드플레어가 Content-Signal이라는 새로운 robots.txt 표기법을 제안
2026년 2월	Anthropic이 ClaudeBot·Claude-User·Claude-SearchBot 세 크롤러의 역할을 문서로 명확히 구분

이 표에서 알 수 있듯, "크롤러 하나로 뭉뚱그려 판단하던 시기"에서 "학습·검색·에이전트를 나눠 다루는 시기"로 넘어온 지 얼마 되지 않았다. 2023년 초창기에는 GPTBot 하나만 알아도 충분했지만, 2026년 현재는 회사마다 최소 두세 개의 크롤러를 구분해서 다뤄야 하는 상황으로 바뀐 것이다. 이런 흐름을 감안하면, 앞으로도 새로운 이름의 크롤러가 등장할 가능성은 매우 높으며, robots.txt는 한 번 설정하고 끝내는 파일이 아니라 주기적으로 다시 열어 봐야 하는 파일이라는 결론에 다다른다.

목적별로 바로 쓰는 robots.txt 코드는 어떻게 짜나?

실전에서 가장 많이 쓰이는 네 가지 전략을 코드와 함께 정리한다. 자기 사업 방향에 맞는 전략 하나를 고른 뒤, 경로만 실제 사이트에 맞게 바꾸면 그대로 쓸 수 있다.

전략 1. AI 관련 노출을 원하지 않는 경우(전면 차단형)

콘텐츠가 AI 학습에도, AI 검색 답변에도 쓰이지 않기를 원하는 사업자를 위한 구성이다.

User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Disallow: /

User-agent: Claude-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Perplexity-User
Disallow: /

일반 검색엔진(구글봇, 네이버 예티 등)은 User-agent: * 규칙만 따르므로 평소처럼 검색에는 그대로 노출된다. AI 관련 크롤러만 이름을 하나씩 지정해 개별적으로 차단한 구성이다.

이 전략은 유료 구독 기반 저널리즘, 자체 데이터·리서치를 판매하는 매체, 독점 인터뷰·취재 콘텐츠처럼 콘텐츠 자체가 상품인 사업에 어울린다. 반대로 검색만으로 신규 고객을 유입시켜야 하는 대다수 지역 사업자나 서비스 소개 사이트에는 지나치게 방어적인 선택일 수 있다는 점도 함께 고려해야 한다.

전략 2. 학습에는 쓰이지 않되 AI 검색·답변에는 인용되고 싶은 경우(절충형)

가장 많은 콘텐츠 발행 사업자가 선택하는 방향이다. 콘텐츠가 통째로 학습 데이터가 되는 것은 원하지 않지만, 잠재 고객이 AI 검색에서 우리를 찾아내는 것은 원하는 경우에 해당한다.

User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

학습 전용 크롤러(GPTBot, ClaudeBot, Google-Extended, Meta-ExternalAgent)만 차단하고, 실시간 검색·답변용 크롤러는 명시적으로 Allow: /를 선언해 열어 둔 구성이다. 이렇게 하면 AI 챗봇 답변에 인용될 기회는 유지하면서, 콘텐츠 자체가 모델 재학습에 그대로 흡수되는 것은 막을 수 있다.

한 인테리어 시공업체를 예로 들면 이렇다. 시공 갤러리와 후기는 잠재 고객이 챗GPT나 퍼플렉시티에 "우리 동네 인테리어 잘하는 곳"을 물었을 때 인용되길 바라지만, 견적 산출 로직이나 상세 시공 노하우가 통째로 다른 회사의 학습 데이터가 되는 것은 원하지 않는다. 이런 경우 절충형이 정확히 들어맞는다. 명시적으로 Allow: /를 적어 두는 이유는, 나중에 User-agent: * 블록에 새로운 차단 규칙이 추가되더라도 검색·에이전트용 크롤러의 허용 의사를 분명히 남겨 두기 위해서다.

전략 3. AI 검색·GEO 노출을 적극적으로 원하는 경우(전면 개방형)

신생 브랜드이거나, 인지도를 높이는 것이 우선인 사업자에게 맞는 방향이다.

User-agent: *
Disallow: /admin/
Disallow: /cart/
Sitemap: https://example.com/sitemap.xml

AI 크롤러를 별도로 지정하지 않으면, 그 크롤러들은 User-agent: * 규칙을 그대로 적용받아 일반 검색엔진과 동일하게 전체가 열린 상태가 된다. 별도 설정이 필요 없다는 것 자체가 이 전략의 장점이다.

이제 막 사업을 시작한 신규 브랜드, 아직 브랜드 검색량 자체가 적은 지역 사업자라면 이 전략이 실무에서 가장 무난하다. AI 검색·챗봇 답변에서 한 번이라도 더 언급되는 것이 지금 단계에서는 학습 데이터 유출 우려보다 실익이 큰 경우가 많기 때문이다. 다만 이 전략을 택했더라도 앞서 설명한 클라우드플레어처럼 CDN 단에서 AI 크롤러를 기본 차단하는 서비스를 쓰고 있다면, robots.txt와 별개로 CDN 설정도 함께 확인해야 진짜 "전면 개방" 상태가 된다.

전략 4. 결제·계정 페이지만 공통으로 지키고, 특정 크롤러 한둘만 선별 차단(선별형)

특정 크롤러 하나(예: 논란이 있었던 크롤러)만 신뢰하지 않는 경우처럼, 세밀한 조정이 필요할 때 쓴다.

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Sitemap: https://example.com/sitemap.xml

User-agent: Bytespider
Disallow: /

이 전략은 대부분의 AI 크롤러는 신뢰하되, 특정 크롤러 하나만 콕 집어 걸러내고 싶을 때 쓴다. 예컨대 서버 로그에서 유독 한 크롤러의 방문 빈도가 지나치게 높아 부담이 된다거나, 뒤에서 다룰 것처럼 규칙 준수 여부가 논란이 된 크롤러가 있다면 이런 방식으로 개별 대응할 수 있다.

네 가지 전략은 서로 섞어 쓸 수도 있다. 예를 들어 절충형(전략 2)을 기본 틀로 쓰면서, 특정 크롤러 하나만 선별형(전략 4)처럼 추가로 차단하는 조합도 얼마든지 가능하다. robots.txt는 크롤러 이름 단위로 블록을 쌓아 가는 구조이기 때문에, 전략을 하나로 딱 고정할 필요 없이 필요에 따라 조합하면 된다.

네 전략 중 정답은 하나로 정해져 있지 않다. 콘텐츠가 AI 검색·챗봇 답변에 인용되어 신규 방문으로 이어지길 원하는지, 아니면 콘텐츠가 다른 서비스의 학습 재료로 그대로 쓰이는 것을 원하지 않는지, 이 두 질문에 대한 답이 사업마다 다르기 때문이다.

새로 나온 콘텐츠 신호(Content-Signal)는 지금 써도 되나?

2025년 9월, 클라우드플레어가 robots.txt에 콘텐츠 사용 목적을 더 세밀하게 표기하는 방식을 새로 제안했다. 기존 Disallow는 "방문 자체"만 허용·차단할 수 있었는데, 이 새로운 콘텐츠 신호(Content-Signal)라는 표기법은 "방문은 허용하되, 그 콘텐츠를 무엇에 쓸 수 있는지"까지 나타내려는 시도다.

표기 방식은 이렇다.

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

search는 검색 색인 구축에, ai-input은 실시간 AI 답변(검색증강생성 등)에, ai-train은 모델 학습·미세조정에 콘텐츠를 사용해도 되는지를 각각 나타낸다. 이 표기는 contentsignals.org라는 별도 사이트를 통해 관리되는 새로운 제안이다.

Content-Signal은 아직 "모든 AI 기업이 반드시 지키기로 서명한 국제 표준"은 아니다. Disallow처럼 오랜 시간에 걸쳐 업계 관행으로 굳어진 규칙과는 무게감이 다르다.

실무에서는 이 표기를 기존 Disallow·Allow 규칙을 대체하는 용도가 아니라, 보조 신호로 추가하는 용도로 쓰는 것이 안전하다. 즉 지금 당장 이 문법 하나만 믿고 Disallow 규칙을 빼 버리는 것은 이르다. 클라우드플레어를 사용하는 사이트라면 관리자 화면에서 이 신호를 자동으로 추가해 주는 기능도 제공하고 있으므로, 이미 쓰고 있다면 굳이 걷어낼 필요는 없다.

이 제안은 클라우드플레어 혼자 밀어붙이는 것이 아니라, 콘텐츠 저작권·퍼블리셔 업계 단체들과 함께 별도의 사이트(contentsignals.org)를 통해 공동으로 관리하는 방식으로 운영되고 있다. 워드프레스 생태계에도 이 신호를 자동으로 robots.txt에 추가해 주는 플러그인이 나올 정도로 확산 초기 단계의 관심은 꽤 높은 편이다.

다만 이 신호를 읽고 실제로 지키겠다고 공개적으로 약속한 AI 기업이 아직 소수라는 점은 분명히 짚어야 한다. Disallow는 30년 가까이 쌓인 관행 위에 2022년 정식 국제 표준(RFC 9309)으로 굳어진 반면, Content-Signal은 이제 막 제안된 지 1년이 채 되지 않은 개념이다. "새로운 문법이 생겼으니 안심"이 아니라 "지켜보되 기존 방식과 병행"하는 태도가 2026년 현재로서는 합리적이다.

규칙을 지키지 않는 크롤러가 있다는데, 어떻게 대응하나?

있다. 그것도 실제로 확인된 사례가 있다. robots.txt는 강제력이 있는 자물쇠가 아니라 정직한 손님에게만 통하는 안내판이라는 점을 다시 한번 짚어야 하는 이유다.

2025년 8월, 클라우드플레어는 고객사들의 신고를 받고 조사에 나섰다. 고객들은 PerplexityBot과 Perplexity-User를 robots.txt로 명시적으로 차단했는데도 퍼플렉시티 서비스가 콘텐츠에 접근했다고 신고했다. 조사 결과, 문제의 접근은 이 두 이름이 아니라 일반 크롬 브라우저(맥OS)를 흉내 낸 위장 User-agent와, 공식적으로 알려지지 않은 IP 대역을 통해 이뤄진 것으로 나타났다.

퍼플렉시티 측은 이에 대해 "이것은 자동화된 크롤러가 아니라, 사용자의 특정 질문에 답하기 위해 관련 웹사이트를 방문하는 AI 에이전트"라는 입장을 밝혔다. 크롤러와 에이전트를 구분해, 에이전트는 robots.txt의 적용 대상이 아니라는 논리다.

이 설명에는 반박도 뒤따랐다. 크롤러든 에이전트든 웹사이트 운영자 입장에서는 똑같이 서버 자원을 쓰고 콘텐츠를 가져가는 방문자이며, 스스로 이름을 밝히지 않고 일반 브라우저처럼 위장했다는 사실 자체가 문제라는 지적이다. 이 논쟁은 2026년 현재도 완전히 정리되지 않은 상태이며, "에이전트는 robots.txt 예외"라는 주장에 업계 전체가 동의한 것은 아니라는 점을 알아 두어야 한다.

이름을 정확히 차단해도 100퍼센트 차단이 보장되지 않는다는 사실을 실제 사례로 보여준 사건이라는 점에서, 이 논란은 robots.txt를 다루는 모든 사업자가 알아 둘 만하다. 이 사례가 주는 실무적인 교훈은 이렇다.

• 크롤러 이름을 robots.txt에 정확히 적어 두는 것만으로 100퍼센트 차단이 보장되지는 않는다
• 정말 민감한 콘텐츠는 robots.txt만 믿지 말고, 로그인 인증이나 방화벽(WAF) 차원의 접근 제어를 함께 걸어야 한다
• 서버 로그를 주기적으로 확인해, 선언하지 않은 낯선 User-agent나 이상 트래픽 패턴이 없는지 점검하는 습관이 필요하다

의심되는 접근을 발견했을 때는 아래 순서로 확인하는 것이 효율적이다.

1. 서버 로그에서 User-agent와 접속 IP를 함께 확인한다. 이름만으로는 진짜인지 확인할 수 없다.
2. 공식 IP 대역과 대조한다. OpenAI와 Anthropic은 각각 자사 크롤러의 IP 대역 목록을 공개해 두고 있어, 이 목록과 실제 접속 IP를 대조하면 사칭 여부를 가릴 수 있다.
3. robots.txt 규칙이 정확히 적용되고 있는지 다시 확인한다. 오타나 위치 오류로 규칙 자체가 무시되고 있을 수 있다.
4. 그래도 반복되면 방화벽(WAF)이나 CDN의 봇 관리 기능으로 IP·User-agent 기준 차단을 추가한다. 클라우드플레어 같은 CDN은 AI 크롤러를 자동으로 식별해 관리하는 기능을 별도로 제공한다.

실제 검증 과정을 예로 들면 이렇다. 서버 로그에서 ClaudeBot이라는 이름의 접속 기록을 발견했다면, 그 요청이 남긴 접속 IP를 확인한 뒤 Anthropic이 공개해 둔 공식 IP 대역 목록과 대조한다. IP가 목록에 없다면 이름만 같을 뿐 실제로는 다른 프로그램일 가능성을 의심해야 한다. OpenAI 역시 자사 크롤러의 IP 대역을 공개 저장소로 제공하고 있어 같은 방식으로 대조할 수 있다. 이런 IP 대역 공개 자체가, 최근 들어 AI 기업들이 "우리 크롤러가 맞는지 스스로 검증하라"는 요구에 대응해 점차 늘려 가고 있는 신뢰 조치라고 볼 수 있다.

이 문제를 두고 "그러니 AI 크롤러는 다 위험하다"고 단정할 필요는 없다. OpenAI, Anthropic처럼 IP 대역을 공개하고 robots.txt를 성실히 따른다고 알려진 크롤러도 다수이며, 이번 사례는 특정 서비스 하나를 둘러싼 논쟁이라는 점을 함께 알아 두어야 한다.

AI 크롤러가 서버에 주는 부담은 어떻게 관리하나?

앞서 살펴본 것처럼 AI 크롤러의 요청량 자체가 짧은 기간에 몇 배씩 늘어나는 경우가 흔하다. 페이지 수가 많은 쇼핑몰이나 대형 미디어라면, AI 크롤러의 반복 방문만으로도 서버 자원을 상당히 소모할 수 있다는 점을 함께 고려해야 한다.

robots.txt의 Disallow는 이런 부담을 줄이는 가장 손쉬운 첫 단계다. 검색·상품 필터 조합처럼 사실상 같은 콘텐츠를 반복하는 경로, 로그인 이후에만 의미 있는 마이페이지 경로는 AI 크롤러 여부와 무관하게 애초에 막아 두는 것이 크롤링 예산 관점에서도 유리하다.

다만 구글이 지원하지 않는 crawl-delay 지시어처럼, 일부 AI 크롤러도 "몇 초에 한 번만 방문해 달라"는 요청을 지원하지 않을 수 있다. 방문 빈도 자체를 강제로 조절하고 싶다면 robots.txt보다 서버·CDN 단의 속도 제한(레이트 리미팅) 기능을 쓰는 것이 더 확실하다. 클라우드플레어를 비롯한 주요 CDN은 AI 크롤러로 식별된 트래픽에 한해 속도를 조절하거나 우선순위를 낮추는 기능을 제공하고 있어, 서버 부담이 심할 때는 이런 인프라 차원의 대응도 함께 검토할 만하다.

AI 크롤러 차단이 GEO와 검색 노출에 어떤 영향을 미치나?

AI 크롤러 차단 여부는 일반 구글 검색 순위와는 직접적인 관계가 없다. 앞서 설명했듯 Google-Extended를 막아도 일반 구글 검색 결과나 구글봇의 크롤링에는 영향이 없는 것처럼, 대부분의 AI 학습용 크롤러는 전통적인 검색 순위와 분리된 별개의 트랙이다.

다만 AI 검색·챗봇 답변에서의 노출(GEO)만큼은 이야기가 다르다. 검색·에이전트용 크롤러(OAI-SearchBot, ChatGPT-User, Claude-User, Claude-SearchBot, PerplexityBot 등)를 차단하면, 그 서비스 안에서 우리 콘텐츠가 답변 근거로 인용될 기회 자체가 사라진다.

학습용 크롤러 차단은 "미래에 내 글이 모델 통째로 흡수되는가"의 문제이고, 검색·에이전트용 크롤러 차단은 "지금 당장 잠재 고객이 AI 답변 안에서 나를 발견하는가"의 문제다. 이 둘을 같은 잣대로 판단하면 안 된다.

AI 검색 유입이 갈수록 늘어나는 지금 시점에서는, 검색·에이전트용 크롤러까지 전부 차단하는 선택은 신중하게 접근할 필요가 있다. 특히 신뢰가 중요한 업종(의료, 법률, 전문 서비스)일수록 AI 답변에 정확한 정보로 인용되는 것이 브랜드 노출에 도움이 될 수 있다. AI 검색 시대의 노출 전략 전반은 GEO 생성형엔진최적화 글에서, AI 유입이 실제로 얼마나 되는지 확인하는 방법은 서치 콘솔 AI 성능 보고서 보는 법에서 각각 자세히 다루고 있다.

실제로 이런 장면을 가정해 볼 수 있다. 한 원두 쇼핑몰 운영자가 신제품 출시 전 "AI 크롤러는 다 위험하다"는 이야기만 듣고 GPTBot부터 PerplexityBot까지 모두 차단해 버렸다고 하자. 몇 달 뒤 챗GPT나 퍼플렉시티에서 "핸드드립 원두 추천"을 물어보는 잠재 고객이 늘어도, 이 쇼핑몰은 애초에 답변 후보에 오를 기회조차 없다. 반대로 학습용 크롤러만 선별 차단하고 검색·에이전트용은 열어 두었다면, 같은 질문에 인용되어 신규 방문으로 이어질 여지가 남는다. AI 크롤러 설정은 "위험을 피하는 문제"이기 이전에 "기회를 여는 문제"이기도 하다는 것이 이 사례가 보여주는 지점이다.

업종·목적별로 어떤 전략을 택해야 하나?

같은 문법이라도 사업 성격에 따라 유리한 선택은 달라진다. 실무에서 자주 나오는 상담 사례를 기준으로 정리한다.

정보성 블로그·미디어

콘텐츠가 곧 자산이자 트래픽 유입원이다. 검색·에이전트용 크롤러는 열어 두고, 학습용 크롤러만 선별 차단하는 절충형(전략 2)이 대체로 유리하다. AI 답변에 인용되면서 원문 링크로 트래픽이 유입될 여지를 남겨 둘 수 있어서다.

이커머스·쇼핑몰

상품 정보가 AI 쇼핑 추천에 인용되는 것이 매출과 연결될 수 있다. 다만 가격·재고처럼 실시간으로 바뀌는 정보가 학습 데이터로 그대로 박제되는 것은 부담일 수 있으므로, 절충형을 기본으로 하되 상품 상세 페이지의 재고·가격 API 경로는 별도로 Disallow하는 조합이 안전하다.

병원·법률처럼 신뢰가 핵심인 전문 서비스

정확한 정보로 AI 답변에 인용되는 것이 신규 문의로 이어질 가능성이 크다. 검색·에이전트용 크롤러는 적극적으로 열어 두는 편이 유리한 경우가 많다. 다만 예약 폼이나 개인정보 관련 경로는 AI 크롤러 여부와 무관하게 이미 기본 robots.txt 설정에서 차단해 둬야 한다.

독점 콘텐츠·유료 구독 기반 매체

콘텐츠 자체가 상품인 경우, 학습용·검색용을 가리지 않고 대부분 차단하는 전면 차단형(전략 1)을 선택하는 경우가 많다. 다만 이 경우 AI 검색에서의 노출 기회 자체를 포기하는 셈이므로, 다른 채널(뉴스레터, 소셜, 직접 방문)로 신규 유입을 얼마나 확보하고 있는지와 함께 판단해야 한다.

스타트업·SaaS(구독형 소프트웨어) 서비스

잠재 고객이 "이런 기능을 하는 툴이 있나?"처럼 문제 해결형 질문을 AI 챗봇에 던지는 경우가 늘고 있다. 이 업종은 전면 개방형(전략 3)이나 절충형(전략 2)으로 검색·에이전트용 크롤러를 열어 두는 편이, 아직 브랜드 검색량이 적은 단계에서는 유리한 경우가 많다. 다만 요금제·계약 조건처럼 자주 바뀌는 페이지는 AI 답변에 오래된 정보로 인용될 위험이 있으므로, 해당 페이지의 최신성을 주기적으로 점검하는 절차를 함께 마련해 두는 것이 좋다.

이렇게 업종별로 나눠 보면 공통된 질문 하나가 남는다. "이 콘텐츠가 인용돼서 새 손님이 늘어나는 것이 이득인가, 아니면 그대로 학습에 흡수되는 것이 손해인가" — 이 질문에 스스로 답할 수 있다면 전략은 자연스럽게 정해진다.

카페24·아임웹 같은 플랫폼으로 만든 사이트도 이 설정이 필요한가?

필요하다. 다만 접근 방식이 자체 개발 사이트와 조금 다르다. 카페24·아임웹·윅스처럼 종합 홈페이지 빌더를 쓰는 경우, 관리자 화면 안에 "SEO 설정" 또는 "검색엔진 최적화" 메뉴에서 robots.txt 내용을 직접 편집할 수 있는 기능을 대개 제공한다.

이런 플랫폼을 쓰고 있다면 아래 순서로 확인하면 된다.

1. 관리자 화면에서 robots.txt 편집 메뉴를 찾는다. 대개 SEO나 검색 노출 관련 설정 안에 있다.
2. 현재 내용에 이미 어떤 규칙이 들어 있는지 먼저 확인한다. 플랫폼이 기본으로 넣어 둔 규칙이 있을 수 있으므로, 이를 지우지 않고 그 아래에 AI 크롤러 규칙을 추가하는 방식이 안전하다.
3. 이 글에서 소개한 전략 중 하나를 골라 크롤러별 블록을 추가한다. 문법 자체는 자체 개발 사이트와 완전히 동일하다.
4. 저장 후 반드시 내도메인.com/robots.txt로 접속해 반영 여부를 확인한다. 일부 플랫폼은 규칙 저장부터 실제 반영까지 시간이 걸릴 수 있다.

만약 사용 중인 플랫폼에 robots.txt를 직접 수정하는 메뉴가 보이지 않는다면, 고객센터에 AI 크롤러별 세부 설정이 가능한지 문의하는 것이 먼저다. 플랫폼이 자동으로 생성해 주는 기본 robots.txt에는 대개 AI 크롤러에 대한 별도 규칙이 포함되어 있지 않으므로, 아무 설정도 하지 않았다면 이 글에서 다룬 전략 중 하나가 아니라 사실상 "전면 개방형"에 가까운 상태로 방치되어 있을 가능성이 크다.

자체 개발 사이트를 운영 중이라면 개발팀이나 운영 중인 웹 에이전시에 이 글의 코드를 그대로 전달해 반영을 요청하면 된다. 어느 쪽이든 "누가 이 파일을 관리하는지"를 먼저 파악해 두는 것이 실무에서 가장 먼저 할 일이다. robots.txt는 관리 주체가 불분명한 채로 방치되기 쉬운 파일 중 하나이기 때문이다.

설정 후 어떻게 검증하나?

robots.txt를 수정한 뒤에는 반드시 확인 절차를 거쳐야 한다. 적어 둔 규칙이 실제로 반영되고 있는지 눈으로 확인하지 않으면, 의도와 다른 상태로 오래 방치될 수 있다.

가장 기본적인 확인은 브라우저 주소창에 내도메인.com/robots.txt를 직접 입력해 새로 추가한 크롤러별 규칙이 정확히 보이는지 확인하는 것이다. User-agent 이름의 대소문자나 철자가 틀리면 그 규칙 전체가 무시될 수 있으므로, 각 크롤러 이름은 공식 문서에 적힌 그대로 정확히 옮겨 적어야 한다.

구글 서치 콘솔의 설정 메뉴 안 크롤링 통계 보고서에서는 구글봇 관련 크롤링 현황을 확인할 수 있지만, AI 크롤러별 방문 현황까지는 보여주지 않는다. AI 크롤러의 실제 방문 여부는 서버 접근 로그에서 User-agent 문자열을 직접 검색해 확인하는 방법이 현재로서는 가장 정확하다. 대부분의 호스팅사나 CDN 관리자 화면에서 최근 접근 로그를 기간별로 조회할 수 있다.

실제 로그는 대략 이런 모습으로 남는다.

203.0.113.42 - - [27/Jul/2026:09:14:02 +0900] "GET /blog/ai-crawler-robots-txt-2026 HTTP/1.1" 200 18421 "-" "Mozilla/5.0 (compatible; ClaudeBot/1.0; +claudebot@anthropic.com)"

이 한 줄에서 확인할 방법이 세 가지다. 첫째, 맨 끝의 User-agent 문자열에서 어떤 크롤러가 다녀갔는지 확인한다. 둘째, 앞부분의 접속 IP를 앞서 설명한 공식 IP 대역 목록과 대조한다. 셋째, 응답 코드(200)를 확인해 실제로 콘텐츠를 정상적으로 가져갔는지, 혹은 이미 차단되어 다른 코드로 응답했는지를 본다. 로그 파일이 방대하다면 grep -i "claudebot" access.log처럼 크롤러 이름으로 검색해 필요한 줄만 골라내는 방식이 실무에서 가장 빠르다.

명령줄에 익숙한 실무자라면 curl 같은 도구로 특정 User-agent를 지정해 직접 요청을 보내 보는 방법도 있다. 예를 들어 아래처럼 요청을 보내면 서버가 그 크롤러를 실제로 어떻게 응대하는지(정상 응답인지, 차단 페이지인지) 확인할 수 있다.

curl -A "GPTBot" -I https://example.com/
curl -A "ClaudeBot" -I https://example.com/

이 방법은 robots.txt 규칙 자체가 문법적으로 올바르게 파싱되는지를 서드파티 검증 도구로 확인하는 것과 병행하면 더 확실하다. 다만 이 요청은 robots.txt 규칙을 직접 읽어 판단을 내리는 것이 아니라 서버 응답만 확인하는 방식이므로, 방화벽·CDN 단에서 별도로 차단을 걸어 둔 경우와 robots.txt만으로 안내하는 경우를 구분해서 해석해야 한다.

규칙을 바꾼 직후에는 검증하고, 그 뒤로는 3개월에 한 번 정도 정기적으로 다시 열어 보는 습관을 들이면 충분하다. AI 크롤러 생태계는 새 이름이 계속 추가되는 만큼, 완전히 잊고 지낼 파일은 아니다.

다시 점검해야 할 시점을 굳이 달력에 표시해 두고 싶다면, 아래 네 가지 상황을 계기로 삼으면 된다.

• 새로운 AI 서비스나 크롤러 이름이 뉴스에 등장했을 때 — 관련 언론 보도나 각 회사의 공식 문서를 확인해 새 크롤러를 우리 전략에 포함할지 결정한다
• 사업 방향이 바뀌었을 때 — 콘텐츠를 유료화하기로 했거나, 반대로 인지도 확보가 급해졌다면 기존 전략을 다시 검토한다
• 호스팅사·CDN을 옮겼을 때 — 새 서비스가 AI 크롤러를 기본값으로 다르게 처리할 수 있으므로 이전 설정이 그대로 유지되는지 확인한다
• 서버 로그에서 낯선 트래픽 패턴을 발견했을 때 — 앞서 설명한 검증 절차를 다시 밟아 본다

참고로 이 글에서 다룬 robots.txt AI 크롤러 제어는 llms.txt와는 별개의 장치다. llms.txt는 사이트 정보를 AI가 이해하기 쉬운 형태로 요약해 두는 별도의 안내 파일이고, robots.txt는 크롤링 자체의 허용 여부를 다룬다. 이 둘의 정확한 관계와 llms.txt의 실제 효과는 llms.txt는 정말 필요할까 글에서 따로 다루고 있다.

AI 크롤러 규칙을 추가할 때 흔히 저지르는 실수는?

기본 문법은 단순하지만, 크롤러가 여러 개로 늘어나면서 새로 생기는 실수 유형이 있다. 실무에서 자주 나오는 세 가지를 좋은 예·나쁜 예로 비교한다.

첫째, 크롤러 이름 하나만 처리하고 나머지 형제 크롤러를 잊는 실수다.

구분	예시
나쁜 예	User-agent: GPTBot / Disallow: / 만 적어 두고 안심
좋은 예	GPTBot·ChatGPT-User·OAI-SearchBot 세 개를 각각 목적에 맞게 개별 설정

앞서 여러 차례 강조했듯, 회사 하나의 크롤러를 하나만 처리하면 나머지는 기본값인 User-agent: * 규칙을 그대로 따른다. 의도한 크롤러만 막고 나머지는 활짝 열어 둔 상태가 되는 셈이라, 반드시 형제 크롤러까지 함께 챙겨야 한다.

둘째, User-agent 이름의 철자나 대소문자를 다르게 적는 실수다.

구분	예시
나쁜 예	User-agent: Chatgpt-user (공식 표기와 다른 대소문자)
좋은 예	User-agent: ChatGPT-User (공식 문서 그대로)

robots.txt의 User-agent 이름은 대소문자를 구분하지 않는 것이 일반적인 관행이지만, 크롤러마다 하이픈 위치나 표기 방식이 미묘하게 다르므로 공식 문서에 적힌 그대로 옮겨 적는 것이 가장 안전하다. 자체적으로 줄여 쓰거나 변형하면 그 규칙 전체가 조용히 무시될 위험이 있다.

셋째, User-agent: * 블록 안에 AI 크롤러까지 함께 넣으려다 규칙이 꼬이는 실수다.

특정 크롤러만 다르게 다루고 싶다면, 그 크롤러 이름으로 별도의 블록을 새로 만들어야 한다. User-agent: * 블록 안에는 아무리 규칙을 추가해도 특정 크롤러 하나만 예외로 다르게 처리할 수 없다. 회사마다 크롤러가 여러 개로 늘어난 지금은, 블록 수가 많아지더라도 이름 하나당 블록 하나씩 정확히 나누는 편이 나중에 유지보수하기 훨씬 수월하다.

자주 묻는 질문

GPTBot을 차단하면 챗GPT 검색에서 아예 안 나오나요?

아니다. GPTBot은 모델 학습용 크롤러이고, 챗GPT의 실시간 검색·답변 인용은 OAI-SearchBot과 ChatGPT-User가 담당한다. GPTBot만 차단했다면 이 두 크롤러는 여전히 활동하므로 검색·답변 노출에는 영향이 없다.

ClaudeBot을 차단하면 클로드가 답변에서 우리 사이트를 인용하지 못하나요?

그렇지 않다. ClaudeBot은 학습용이고, 실시간 답변은 Claude-User가 맡는다. 답변 인용 자체를 막고 싶다면 Claude-User와 Claude-SearchBot을 별도로 차단해야 한다.

robots.txt 하나로 모든 AI 크롤러를 한꺼번에 다 막을 수 있나요?

공식적으로 알려진 크롤러 이름만 대상이라면 가능하다. 하지만 앞서 살펴본 퍼플렉시티 사례처럼, 일부 서비스는 정식 이름이 아닌 다른 방식으로 접근하기도 한다. 완전한 차단을 원한다면 robots.txt와 함께 방화벽(WAF) 차원의 접근 제어를 병행하는 것이 안전하다.

AI 크롤러를 지금 차단하면 이미 학습된 데이터도 지워지나요?

아니다. robots.txt 차단은 앞으로의 수집을 막는 것이지, 과거에 이미 수집·학습에 쓰인 데이터를 소급해서 제거하는 효력은 없다. 이미 학습에 반영된 콘텐츠에 대한 처리는 각 AI 기업이 별도로 운영하는 옵트아웃·삭제 요청 절차를 통해 문의해야 한다.

네이버는 AI 크롤러 관련 정책이 따로 있나요?

네이버는 자체 서비스(블로그, 카페, AI 브리핑 등) 비중이 커서, 해외 AI 크롤러와는 접근 방식 자체가 다르다. 네이버 자체 도메인 블로그는 네이버가 알아서 수집·색인하므로 이 글에서 다룬 robots.txt AI 크롤러 개념이 그대로 적용되지 않으며, 자체 도메인 홈페이지라면 일반적인 robots.txt 규칙과 네이버 서치어드바이저 등록을 함께 챙기면 된다.

크롤러 이름을 잘못 적으면 어떻게 되나요?

그 규칙 전체가 조용히 무시된다. robots.txt는 오타나 존재하지 않는 이름에 대해 오류를 알려주지 않고 그냥 건너뛴다. 크롤러 이름은 반드시 공식 문서에 적힌 대소문자와 철자 그대로 옮겨 적어야 하며, 수정 후에는 앞서 설명한 검증 절차를 거치는 것이 안전하다.

스타트업처럼 아직 인지도가 낮은 사업자는 어떤 전략이 유리한가요?

대체로 검색·에이전트용 크롤러는 열어 두는 편이 유리하다. 인지도가 낮은 단계에서는 어디서든 발견되는 것 자체가 이득인 경우가 많고, AI 답변에 인용되는 것도 하나의 노출 채널이 될 수 있다. 학습용 크롤러 차단 여부는 콘텐츠의 독점성과 별개로 판단하면 된다.

클라우드플레어를 쓰지 않는 사이트도 신경 써야 하나요?

그렇다. 클라우드플레어의 신규 도메인 기본 차단 정책은 클라우드플레어 네트워크를 쓰는 사이트에만 적용된다. 다른 호스팅사나 CDN을 쓰고 있다면, 자사 서비스가 AI 크롤러를 기본값으로 어떻게 처리하는지 별도로 확인해야 하며, 결국 이 글에서 다룬 robots.txt 설정을 직접 챙기는 것이 가장 확실한 방법이다.

robots.txt에 AI 크롤러 규칙을 추가하면 사이트 속도가 느려지나요?

아니다. robots.txt는 텍스트 파일 하나에 몇 줄을 추가하는 것뿐이라 사이트 속도나 서버 성능에는 영향을 주지 않는다. 오히려 불필요한 크롤러의 반복 방문을 줄이면 장기적으로 서버 부담을 더는 효과를 기대할 수 있다.

이미 발행한 오래된 글도 AI 크롤러 설정의 영향을 받나요?

받는다. robots.txt 규칙은 파일이나 페이지 하나하나가 아니라 경로(폴더) 단위, 그리고 도메인 전체 단위로 적용되므로, 몇 년 전에 쓴 글이든 오늘 발행한 글이든 같은 규칙이 동일하게 적용된다. 오래된 글만 따로 예외를 두고 싶다면 그 글들이 모여 있는 경로를 별도로 지정해야 한다.

한 번 차단한 크롤러를 나중에 다시 허용으로 바꿀 수 있나요?

언제든 가능하다. robots.txt는 파일을 수정하고 저장하는 즉시(검색엔진의 캐시 주기를 감안하면 최대 하루 이내) 새 규칙이 적용되는 구조라, 처음에 전면 차단형을 골랐다가 나중에 절충형이나 개방형으로 바꾸는 것도 문제없다. 다만 학습용 크롤러를 뒤늦게 허용으로 바꾼다고 해서, 차단 기간 동안 놓친 학습 기회가 소급 적용되지는 않는다는 점은 알아 두어야 한다.

우리 콘텐츠가 이미 다른 AI 모델의 학습 데이터에 포함됐는지 확인할 방법이 있나요?

일반 사업자가 직접 확인하기는 현실적으로 어렵다. 각 AI 기업은 학습에 쓰인 개별 문서 목록을 공개하지 않는 경우가 대부분이다. 콘텐츠가 이미 학습에 반영됐을 가능성이 있다고 판단되면, robots.txt로 향후 수집을 막는 동시에 각 AI 기업이 운영하는 별도의 옵트아웃·삭제 요청 창구에 문의하는 것이 현재로서는 가장 현실적인 절차다.

robots.txt 말고 메타 태그로도 AI 크롤러를 막을 수 있나요?

일부 가능하다. 페이지의 <head> 안에 <meta name="robots" content="noai, noimageai">처럼 AI 학습 관련 메타 태그를 추가하는 방식도 논의되고 있지만, robots.txt의 User-agent 지정만큼 세밀하게 크롤러별로 구분하지는 못한다. 현재로서는 robots.txt가 AI 크롤러를 이름 단위로 통제할 수 있는 가장 표준적이고 구체적인 방법이다.

이 글에서 소개한 코드를 그대로 복사해서 붙여넣어도 되나요?

가능하다. 다만 example.com 부분은 반드시 자기 사이트 도메인으로 바꾸고, /admin/이나 /cart/처럼 예시로 든 경로도 실제 사이트 구조에 맞게 확인한 뒤 적용해야 한다. 적용 후에는 이 글의 검증 절차대로 내도메인.com/robots.txt를 직접 열어 규칙이 정확히 반영됐는지 확인하는 과정을 반드시 거쳐야 한다.

마무리: 크롤러 이름을 알아야 정확한 설정이 나온다

AI 크롤러 대응은 더 이상 "막을 것인가, 열 것인가"라는 이분법으로 끝나지 않는다. 같은 회사 안에서도 학습용과 검색·에이전트용 크롤러가 나뉘어 있고, 이 둘을 구분해서 설정해야 원하는 결과가 나온다는 것이 이 글의 핵심이다.

오늘 다룬 내용을 정리하면 이렇다.

• OpenAI·Anthropic 등은 학습·에이전트·검색용 크롤러를 각각 따로 운영하며, 이름마다 역할이 다르다
• 목적에 맞는 네 가지 실전 전략(전면 차단·절충·전면 개방·선별 차단) 중 하나를 골라 코드를 그대로 적용할 수 있다
• robots.txt는 강제력이 없는 안내판이며, 정말 민감한 콘텐츠는 방화벽·인증 같은 실질적인 장치도 함께 필요하다
• AI 크롤러 차단 여부는 GEO와 AI 검색 노출에 직결되므로, 콘텐츠의 성격과 사업 방향을 함께 고려해 결정해야 한다

지금 바로 자기 사이트의 robots.txt를 열어, 이 글에서 소개한 크롤러 이름 중 몇 개가 이미 적혀 있는지, 혹시 의도와 다른 설정이 남아 있지는 않은지 확인해 보는 것으로 충분한 첫걸음이 된다. 아무 규칙도 없다면 그것 역시 하나의 선택지이지만, 적어도 "선택하지 않은 것"이 아니라 "의도적으로 열어 둔 것"이 되도록 확인하고 넘어가는 편이 안전하다.

무인도에 아무리 예쁜 호텔을 지어도 손님이 존재를 모르면 소용없다는 말처럼, AI 검색 시대에는 AI가 존재를 알아야 손님을 데려온다. robots.txt 설정 하나가 그 통로를 열어 둘지 닫아 둘지를 가른다.

이런 세밀한 기술적 SEO 설정부터 AI 검색 노출 전략까지, 처음 사이트를 설계하는 단계부터 함께 고민하는 것이 이루웹이 하는 일입니다. 우리 사이트의 AI 크롤러 설정이 지금 사업 방향과 맞는지 점검이 필요하시다면 SEO 최적화 홈페이지 제작 서비스와 AEO·GEO 최적화 서비스를 살펴보시고, 무료 상담으로 현재 상태를 진단받아 보시길 권해 드립니다. 작은 크롤러 이름 하나까지 놓치지 않고 꼼꼼히 챙겨 드리겠습니다.