robots.txt AI 크롤러 차단, 응답 코드·그룹 규칙·로그로 확인

robots.txt의 AI 크롤러 차단 여부는 Disallow 줄만으로 판단할 수 없습니다. 세 가지를 함께 확인해야 합니다. 루트 파일의 응답 코드, 크롤러 이름이 받는 그룹 규칙, 방화벽·CDN(콘텐츠 전송망: 사이트를 여러 지역 서버에 나눠 전달하는 서비스)의 앞단 차단입니다.

셋 중 하나만 어긋나도 결과가 의도와 달라집니다. 파일에는 허용으로 적혀 있어도 수집이 막힐 수 있습니다. 한 줄짜리 규칙이 의도하지 않은 크롤러에 적용되기도 합니다.

어느 호스트의 robots.txt를 열어야 하나요?

Google 문서에 따르면 robots.txt는 사이트 최상위 디렉터리에 있어야 합니다. 하위 폴더에 둔 파일은 무시됩니다. 규칙은 파일이 놓인 호스트·프로토콜·포트에만 적용됩니다.

따라서 www가 붙은 주소와 붙지 않은 주소를 각각 확인해야 합니다. blog·newsroom 같은 하위 도메인도 따로 봅니다. Anthropic 도움말도 차단을 원하는 하위 도메인마다 규칙을 넣으라고 안내합니다.

실무에서는 AI 답변에 인용되기를 원하는 페이지가 어느 호스트에 있는지 먼저 목록으로 만드는 방법을 권합니다. Search Console robots.txt 보고서는 도메인 속성의 상위 20개 호스트에서 Google이 찾은 파일을 보여 주므로 대조 자료가 됩니다. 이 보고서는 Google 크롤러 기준이며, 다른 AI 크롤러는 서버 로그로 확인합니다.

robots.txt가 정상으로 열리는지는 어떻게 판단하나요?

파일을 열면 화면 내용보다 응답 코드를 먼저 봅니다. Google 문서와 robots.txt 표준인 RFC 9309(국제 인터넷 표준 문서)는 응답 코드에 따라 파일을 다르게 해석합니다.

어떤 크롤러 이름을 찾아야 하나요?

User-agent 줄에는 크롤러가 공개한 토큰(크롤러 식별 이름)을 적습니다. 주요 AI 서비스가 공식 문서에 밝힌 토큰은 다음과 같습니다.

Google 문서는 Google-Extended가 Google 검색 포함 여부에 영향을 주지 않는다고 밝힙니다. 이 토큰은 별도의 HTTP 사용자 에이전트가 없습니다. 방문 기록이 따로 남지 않으므로 robots.txt 파일에서만 확인합니다.

Googlebot 그룹의 규칙은 Google 검색, Discover, 이미지 등 여러 제품에 영향을 줍니다. AI 관련 규칙을 고치면서 Googlebot 그룹까지 바뀌지 않았는지도 살핍니다.

파일 속 규칙은 특정 크롤러에 어떻게 적용되나요?

Google 문서와 RFC 9309 기준으로 크롤러는 자기 이름과 일치하는 그룹만 따릅니다. 이름이 맞는 그룹이 있으면 전체 대상(*) 그룹의 규칙은 합쳐지지 않습니다. 크롤러 이름은 대소문자를 구분하지 않지만, 경로는 구분합니다.

토큰 하나를 판정하는 순서는 다음과 같습니다.

1. User-agent 줄에서 확인할 토큰을 찾습니다. 같은 토큰이 여러 그룹에 나오면 규칙을 합쳐서 봅니다.
2. 이름이 맞는 그룹이 없으면 * 그룹을 적용합니다. * 그룹도 없으면 제한이 없습니다.
3. 인용되기를 원하는 URL마다 일치하는 Allow·Disallow 경로를 모두 찾습니다.
4. 가장 긴 경로의 규칙을 따릅니다. 길이가 같으면 덜 제한적인 Allow를 따릅니다.
5. *는 임의의 문자열, $는 URL의 끝을 뜻한다는 점을 반영해 최종 판정합니다.

예를 들어 가상의 ○○ 기업 robots.txt가 다음 두 그룹으로 되어 있다고 가정합니다.

담당자는 모든 크롤러에 관리자 경로를 막고, OAI-SearchBot에는 제품 경로까지 막을 의도였을 수 있습니다. 실제 결과는 다릅니다. OAI-SearchBot은 자기 그룹만 따르므로 /admin/ 차단을 받지 않습니다. 경로는 대소문자를 구분하므로 소문자 /products/ 페이지도 열려 있습니다. 이름이 따로 없는 ClaudeBot은 * 그룹을 따라 /admin/만 막힙니다.

파일은 허용인데 실제로 막히는 원인은 무엇인가요?

파일 판정이 허용이어도 수집이 막혀 있을 수 있습니다. 이상 신호와 원인 후보를 짝지으면 다음과 같습니다.

Search Console 도움말에 따르면 오류는 해당 규칙을 쓸 수 없게 만들고, 경고는 규칙 사용을 막지 않습니다. 원인 후보가 보안 장비 쪽이면 호스팅·보안 담당자에게 다음 문안으로 확인을 요청할 수 있습니다.

1. www, 비 www, 하위 도메인 각각의 robots.txt 응답 코드와 최근 30일 변경 이력을 알려 주십시오.
2. 방화벽·CDN 봇 차단 규칙 가운데 GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot이 포함된 규칙이 있는지 알려 주십시오.
3. 최근 7일간 위 이름으로 들어온 요청의 응답 코드별 건수를 공유해 주십시오.
4. 차단 규칙이 있다면 적용 시점과 설정 사유를 함께 알려 주십시오.

서버 로그와 보고서로 결과를 어떻게 교차 확인하나요?

로그에서 실제 방문을 가려내기

웹 서버 접속 기록에서 사용자 에이전트(요청을 보낸 프로그램이 스스로 밝히는 이름)에 토큰이 들어간 요청을 고릅니다. 요청 경로와 응답 코드를 함께 봅니다.

사용자 에이전트는 다른 프로그램이 흉내 낼 수 있으므로 IP까지 대조합니다. OpenAI와 Perplexity는 크롤러별 IP 대역을 JSON 목록(기계가 읽는 형식의 목록)으로 공개합니다. Perplexity 문서는 최신 목록을 쓰고 주기적으로 받아 갱신하라고 권합니다.

Anthropic은 크롤러 출발 IP를 하나의 목록으로 공개합니다. 다만 IP 차단은 크롤러가 robots.txt를 읽지 못하게 해 의도대로 작동하지 않을 수 있다며, 수집 거부는 robots.txt로 하라고 안내합니다.

• OpenAI 문서 기준으로 GPTBot과 OAI-SearchBot을 모두 허용하면 한 번의 수집 결과를 두 용도에 함께 쓸 수 있습니다. 한쪽 이름만 보여도 다른 쪽이 차단됐다고 단정하지 않습니다.
• ChatGPT-User와 Perplexity-User는 사용자 요청으로 방문하며 robots.txt를 따르지 않을 수 있습니다. Disallow 경로에서 이 방문이 보여도 파일 오류의 증거로 보지 않습니다.

판정 기록 양식

예를 들어 가상의 ○○ 기업이라면 다음처럼 기록할 수 있습니다.

둘째 행처럼 파일 판정은 허용인데 로그가 403이면 앞 절의 첫 번째 이상 신호에 해당합니다.

규칙을 고친 뒤 다시 확인하기

Google 문서는 robots.txt를 대체로 최대 24시간 캐시한다고 설명합니다. RFC 9309도 24시간을 넘는 캐시 사용을 피하라고 정합니다. OpenAI 문서는 검색 반영에 약 하루가 걸릴 수 있다고 하고, Perplexity 문서는 최대 24시간을 밝힙니다.

Search Console robots.txt 보고서에서는 파일마다 재크롤링을 요청할 수 있습니다. 도움말은 차단을 푼 URL을 즉시 다시 크롤링한다는 보장은 없다고 설명합니다. 버전 이력에는 최근 30일 요청 가운데 파일이나 가져오기 결과가 이전과 달라진 것만 표시됩니다.

정리

1. 인용을 원하는 페이지가 있는 호스트를 모두 적고, 호스트마다 robots.txt 응답 코드를 기록합니다.
2. 토큰 표의 이름별로 적용 그룹과 핵심 URL 판정을 기록 양식에 채웁니다.
3. 서버 로그에서 각 서비스의 공개 IP 목록과 일치하는 요청만 골라 응답 코드를 확인합니다.
4. 요청 문안으로 방화벽·CDN 차단 규칙을 담당자에게 확인합니다.
5. 규칙을 고쳤다면 다음 날 Search Console 보고서와 로그를 다시 확인합니다.