robots.txt가 GPTBot을 허용해도 서버는 여전히 403 응답할 수 있습니다.

저는 소규모 사업체 웹사이트들이 AI 답변 엔진에 얼마나 읽기 쉬운지 확인해 보았는데, 항상 같은 현상을 발견했습니다. robots.txt에는 GPTBot과 ClaudeBot이 허용되어 있지만, 서버는 어쨌든 403 응답을 보내고 있습니다.

robots.txt를 읽는 사람은 아무도 알아차리지 못할 것입니다. robots.txt 검사기는 'AI 크롤러가 허용됨'이라고 보고할 것입니다. 하지만 차단은 웹 서버나 보안 플러그인에서 한 단계 낮은 곳에 위치하며, 사용자 에이전트(user-agent) 문자열과 일치하는지 확인합니다.

제가 측정한 내용

2026년 10월 4일, 저는 일본의 소규모 관광 사업체 26곳(게스트하우스, 쿠킹 클래스, 기모노 대여, 도자기 및 다도 체험 스튜디오)을 테스트했습니다. 이 사이트들은 검색과 해당 카테고리에 대한 AI 답변 질의를 통해 찾았기 때문에 무작위 표본이 아닌 편의 표본입니다. 각 사이트는 일본 내 거주지 연결에서 사용자 에이전트를 이용해 한 번의 요청을 받았습니다.

• 26곳 중 3곳은 아무런 응답도 하지 않았습니다(타임아웃 또는 연결 오류). 따라서 23곳으로 남게 되었습니다.
• 나머지 23곳 중 5곳은 GPTBot과 ClaudeBot 사용자 에이전트에게는 403을 반환했지만, 브라우저 사용자 에이전트에게는 200을 받았습니다. 이 5곳 모두 크롤러를 허용하는 robots.txt를 가지고 있었습니다.
• 또 다른 1곳은 ClaudeBot에게만 403을 반환했습니다. 그 사이트는 읽기 쉬운 robots.txt가 없었습니다.
• 같은 5곳의 사이트들은 OAI-SearchBot과 PerplexityBot에게는 200을 반환했습니다. 이 규칙은 모든 봇이 아닌 이름으로 지정된 학습 크롤러를 대상으로 합니다.
• 5곳 중 4곳은 Server: nginx를 보내고, 그 4곳에서는 GPTBot으로 요청할 경우 /robots.txt조차도 403을 반환합니다. 즉, 환영한다고 말하는 파일에 접근하려 할 때 크롤러가 거부되는 것입니다.

따라서 이 표본에서 도달 가능한 23개 사이트 중 6곳(약 4분의 1)은 서버 수준에서 최소한 두 학습 크롤러 중 하나를 거부하며, 그 어떤 곳도 robots.txt에 이를 명시하지 않았습니다. 저는 이 비율을 일반적인 '소규모 사업체 사이트' 전체로 확대 해석하지 않을 것입니다. n은 23이고 표본이 일본 관광 쪽으로 치우쳐 있습니다. 패턴 자체가 유용한 부분이며, 여러분의 사이트는 1분도 안 되어 확인할 수 있습니다.

curl로 직접 테스트해 보세요

다음은 크롤러들이 공개하는 사용자 에이전트 문자열입니다. https://example.com/을 자신의 사이트로 교체하십시오.

URL=https://example.com/
BROWSER='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128 Safari/537.36'
GPTBOT='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.1; +https://openai.com/gptbot)'
...

glovrex.com에서 제가 운영하는 사이트(Vercel에 호스팅되었으며, robots.txt는 모두 허용하고 서버에 사용자 에이전트 규칙이 없음)에서는 네 줄 모두 200을 출력합니다:

browser   200
GPTBot    200
ClaudeBot 200
...

샘플의 네 가지 nginx 사이트에서 나온 결과는 다음과 같았습니다:

browser   200
GPTBot    403
ClaudeBot 403
...

만약 두 번째 형태를 보았다면, curl -s "${URL}robots.txt"도 실행하여 robots.txt가 실제로 무엇을 말하는지 읽어보세요. 만약 크롤러는 허용하지만 서버가 거부한다면, 이 두 계층이 불일치하며, 서버의 규칙이 우선합니다. robots.txt 라인에서 404가 나오는 것은 괜찮습니다. 단지 robots.txt가 없다는 의미일 뿐입니다. -A GPTBot만 전송해도 네 개의 nginx 사이트 모두에서 동일한 403 응답이 나왔는데, 이는 사용자 에이전트에 대한 단순 문자열 일치(plain substring match)를 가리킵니다.

AI 답변에 중요한 이유

AI 어시스턴트가 비즈니스에 대해 무언가를 말하는 방식은 두 가지입니다. 질문 시점에 OAI-SearchBot이나 Claude-SearchBot 같은 크롤러를 사용하여 웹을 검색할 수 있습니다. 또는 모델이 훈련 과정에서 이미 흡수한 내용(training)을 바탕으로 답변할 수도 있으며, 여기에 GPTBot과 ClaudeBot이 관련됩니다.

위의 사이트들은 여전히 검색 시점의 크롤러들을 통과시키므로, 브라우징 어시스턴트는 이들 페이지를 읽을 수 있습니다. 하지만 그들이 잃는 것은 두 번째 경로입니다. 모델이 검색 없이 답변할 때, 그것은 보통 예약 플랫폼(booking platforms), 목록형 콘텐츠(listicles) 및 리뷰 사이트 등 언급하는 다른 페이지들을 통해서만 비즈니스를 알게 됩니다. 제가 이 그룹의 한 게스트하우스에서 실행한 샘플 확인 중에는, 해당 비즈니스에 대한 AI 답변이 오직 예약 플랫폼만을 인용했고, 제시된 가격은 공식 사이트의 가격이 아니라 플랫폼의 가격이었습니다. 이는 하나의 엔진에서 나온 답변일 뿐 원인 증명(proof of cause)은 아니지만, 만약 공식 사이트가 훈련 데이터에 누락되었다면 예상할 수 있는 결과입니다.

무언가를 변경하기 전 주의사항(Caveats)

학습 크롤러를 차단하는 것은 합법적인 선택입니다. 많은 사이트 소유자가 의도적으로 그렇게 하며, 크롤러 운영자들은 바로 그 이유로 어떻게 옵트아웃(opt out)할 수 있는지 문서화하고 있습니다. 제가 지적하는 문제는 아무도 선택하지 않은 경우에만 해당됩니다. 즉, robots.txt를 작성하여 크롤러를 허용했지만, 호스팅 기본 설정이나 보안 플러그인이 이를 무심코 덮어쓴 경우입니다.

제가 사용하는 프로브(probe)는 일반 IP에서 게시된 사용자 에이전트(user-agent) 문자열을 전송합니다. 실제 크롤러들은 운영자의 IP 범위에서 오며, 일부 설정(예: Cloudflare의 봇 설정)은 검증된 크롤러를 단순히 사용자 에이전트를 복사한 사람과 다르게 취급합니다. 샘플에 있는 5개 사이트 중 하나는 Cloudflare 뒤에 있기 때문에, 그 결과는 실제 크롤러가 보는 것과 일치하지 않을 수 있습니다. 확실한 방법은 서버의 접근 로그(access log)를 확인하는 것입니다. 여기에 GPTBot과 ClaudeBot을 검색하고 상태 코드(status code)를 살펴보세요.

서버에서 200 응답 코드를 받았다고 해서 AI 답변에 무언가 표시될 것이라는 보장은 아닙니다. 오프사이트 평판(Off-site reputation)이 누가 언급되는지를 결정하는 대부분의 요인입니다. 이 점검은 단지 여러분이 놓치고 있을 수 있는 하나의 이유를 제거해 줄 뿐입니다.

더 나아가고자 한다면

geo-checker는 제가 작성한 무료 MIT 도구로, 페이지의 구조화된 데이터(structured data), 제목(headings), 그리고 robots.txt 규칙에 점수를 매깁니다. 이 도구는 robots.txt만 읽기 때문에 위에 언급된 6개 사이트 중 어느 것도 포착하지 못했을 것입니다. 저장소는 아카이브되었으니 있는 그대로 받아들여 주십시오. 만약 사람이 직접 네 개의 AI 엔진에 실제 질문을 포함하여 전체 점검을 받기를 원하신다면, 저는 한 사이트에 대해 GEO mini audit를 수행합니다.