robots.txt는 허용인데 왜 안 읽히나?

AI봇 접근 편에서 robots.txt로 문을 여는 법을 다뤘습니다. 그 글의 전제는 "허용해 두면 들어온다" 였습니다.

그 전제가 항상 성립하지는 않습니다.

robots.txt는 선언입니다. 크롤러가 실제로 받아가는 것은 서버의 응답입니다. 이 둘은 서로 다른 층에 있고, 서로를 모릅니다. 문패에는 "영업 중"이라고 붙어 있는데 안내데스크에서 돌려보내는 상황이 실제로 자주 일어납니다.

이 글은 그 간극을 다룹니다. 진단 점수로는 "AI봇 접근: 허용"이 나오는데도 AI가 우리 회사를 모르는 경우, 여기부터 의심하시면 됩니다.

유형 1 — 보안장비가 먼저 끊는다

robots.txt는 크롤러에게 보내는 요청입니다. 반면 CDN·방화벽·봇 관리 서비스는 요청을 실제로 차단합니다. 후자가 먼저 작동합니다.

홈페이지 담당자가 robots.txt를 손본 적이 없어도, 호스팅이나 보안 설정이 기본값으로 AI 크롤러를 막고 있을 수 있습니다. 이 경우 크롤러는 403이나 자바스크립트 챌린지 페이지를 받습니다. 사람이 브라우저로 열면 멀쩡하기 때문에 눈으로는 절대 발견되지 않습니다.

2026년 9월 15일 — 클라우드플레어 기본값 변경

최근 이 영역에서 실제 변화가 있었습니다. 클라우드플레어가 AI 트래픽을 세 갈래로 나눠 관리하도록 바꿨습니다.

여기서 범위를 정확히 짚는 게 중요합니다. 이 변경을 다룬 기사 중에는 "기존 무료 요금제 사용자도 자동 적용"이라고 쓴 것들이 있는데, 클라우드플레어 공식 체인지로그는 다르게 말합니다.

Only new domains onboarding to Cloudflare after September 15, 2026 (…) Existing customers are not affected unless they choose to adopt the new defaults. — Cloudflare Changelog — New options to manage AI traffic

정리하면 이렇습니다.

• 9월 15일 이후 새로 등록한 도메인에만 새 기본값이 적용됩니다
• 기존 도메인은 직접 적용하지 않는 한 그대로입니다
• 차단되는 것도 전면이 아니라 광고를 표시하는 페이지이고, Search 분류는 허용으로 남습니다

대부분의 중소기업 홈페이지는 광고를 싣지 않으므로 이 기본값 자체로 당장 막히지는 않습니다. 그러니 "9월 15일부터 AI가 우리 사이트를 못 읽는다"는 말은 과장입니다.

다만 실제로 조심해야 할 건 따로 있습니다. 학습만 막으려고 설정을 켰을 때 학습과 검색을 겸하는 크롤러까지 함께 막힌다는 점입니다. 클라우드플레어는 Training 분류를 "혼합 목적 크롤러를 포함한다"고 정의합니다. AI 학습이 싫어서 켠 스위치 하나에 검색 노출이 딸려 나갈 수 있습니다.

확인할 곳은 Security Settings → Block AI bots이고, 선택지는 전체 차단 / 광고 페이지만 차단 / 허용 셋입니다.

유형 2 — 없는 경로에도 200을 주는 서버

두 번째는 조용해서 더 나쁩니다.

정상적인 서버는 없는 주소를 요청받으면 404를 돌려줍니다. 그런데 아무 주소나 요청해도 200 OK와 함께 예쁜 안내 페이지를 돌려주는 서버가 꽤 있습니다. 구글은 이 상태를 소프트 404라고 부릅니다.

If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error. — Google — HTTP status codes and network errors

이게 왜 AI 가독성 문제가 되냐면, 파일이 있는지 없는지를 판단할 수 없게 되기 때문입니다. robots.txt를 요청했는데 200이 왔다고 해서 그게 진짜 robots.txt라는 보장이 없습니다. 사이트 홈페이지의 HTML이 그 자리에 대신 와 있을 수 있습니다. sitemap.xml도, llms.txt도 마찬가지입니다.

솔직히 말씀드리면 저희도 이 함정에 빠졌습니다. 루트 파일의 존재 여부를 응답 코드만 보고 판정하던 시기가 있었고, 그래서 "이 파일을 갖춘 사이트"를 실제보다 많게 세었습니다. 내용까지 확인하도록 고친 뒤 전체를 다시 채점했습니다. 판정 기준을 바꾼 것이지 사이트가 바뀐 것이 아니었습니다.

유형 3 — 봇에게만 다른 화면을 준다

서버가 요청 헤더의 User-Agent를 보고 응답을 바꾸는 경우입니다. 브라우저에는 정상 페이지를, 봇에는 빈 페이지나 로그인 화면을 줍니다.

의도적으로 이렇게 설정하는 곳은 드뭅니다. 대개는 봇 차단 플러그인, 캐시 설정, 또는 "모바일/데스크톱 분기"가 낡아서 생긴 부작용입니다.

주의할 점 하나. 반대 방향, 즉 봇에게만 더 좋은 내용을 주는 것은 클로킹이라 검색엔진 정책 위반입니다. 여기서 말하는 건 그걸 하라는 게 아니라, 의도치 않게 봇에게만 나쁜 화면이 나가고 있지 않은지 확인하자는 것입니다.

유형 4 — 주소가 여러 개다

www 있는 주소와 없는 주소, http와 https, 끝의 슬래시 유무가 서로 다른 페이지로 살아 있는 경우입니다. 각각이 다른 robots.txt를 보게 되거나, 리다이렉트가 꼬여 크롤러가 중간에 포기합니다.

리다이렉트는 한 번에 최종 주소로 보내는 게 원칙입니다. http://example.co.kr → https://example.co.kr → https://www.example.co.kr → https://www.example.co.kr/ko/ 처럼 이어지면, 사람은 기다려 주지만 수집기는 그렇지 않습니다.

유형 5 — 느려서 못 읽는다

응답이 오긴 오는데 몇 초씩 걸리는 경우입니다. 크롤러는 사람보다 참을성이 없고, 타임아웃되면 그 페이지는 내용이 없는 페이지와 같은 취급을 받습니다.

특히 첫 방문 시에만 느린 사이트가 위험합니다. 담당자가 자주 열어보는 페이지는 캐시가 살아 있어 빠르고, 크롤러가 처음 만나는 페이지만 느립니다. 그래서 내부에서는 문제를 못 느낍니다.

어떻게 확인하나

브라우저로 여는 것은 확인이 되지 않습니다. 크롤러와 같은 조건으로 요청해야 합니다.

1. 세 가지 신분으로 같은 페이지를 요청해 봅니다

URL=https://example.co.kr

# 브라우저인 척
curl -s -o /dev/null -w "browser %{http_code} %{size_download}\n" \
  -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)" "$URL"

# AI 검색 크롤러인 척
curl -s -o /dev/null -w "oai     %{http_code} %{size_download}\n" \
  -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot" "$URL"

# 아무 신분도 밝히지 않고
curl -s -o /dev/null -w "plain   %{http_code} %{size_download}\n" "$URL"

세 줄의 응답 코드와 크기가 비슷해야 정상입니다. 봇 쪽만 403이거나 크기가 확연히 작으면 유형 1 또는 유형 3입니다.

2. 없는 주소를 일부러 요청해 봅니다

curl -s -o /dev/null -w "%{http_code}\n" https://example.co.kr/zzz-does-not-exist-4821

404가 나와야 정상입니다. 200이 나오면 유형 2이고, 이 서버에서는 "파일이 있다"는 판정을 믿을 수 없습니다. 이럴 때는 내용까지 봐야 합니다.

# robots.txt 자리에 HTML이 와 있지 않은지
curl -s https://example.co.kr/robots.txt | head -3

첫 줄이 <!DOCTYPE html> 이면 그건 robots.txt가 아닙니다.

3. 리다이렉트 경로를 펴 봅니다

curl -sIL https://example.co.kr | grep -E '^(HTTP/|location:)' 

HTTP/ 줄이 여러 개면 그만큼 거쳐 간다는 뜻입니다. 두 번을 넘기면 정리 대상입니다.

4. 로그에서 진짜 봇인지 확인합니다

서버 로그에 GPTBot이 찍혔다고 해서 진짜 OpenAI는 아닙니다. User-Agent는 누구나 흉내 낼 수 있습니다. OpenAI는 크롤러별 IP 대역을 공개하고 있어서 대조할 수 있습니다.

• https://openai.com/gptbot.json (학습용 수집)
• https://openai.com/searchbot.json (검색 노출용)
• https://openai.com/chatgpt-user.json (사용자 요청 방문)

이게 실무에서 쓸모 있는 이유는 반대 방향입니다. "AI 크롤러가 오긴 하나"를 확인하고 싶을 때, 로그에 이 대역의 접속이 있는지 보면 됩니다. 한 건도 없다면 robots.txt가 아니라 앞단에서 끊기고 있을 가능성이 큽니다.

자주 틀리는 것

정리

• robots.txt는 선언이고, 실제로 읽히느냐는 서버 응답이 정합니다. 둘은 따로 놉니다
• 클라우드플레어 9월 15일 기본값 변경은 신규 도메인 + 광고 표시 페이지 + Training·Agent 분류에 한정됩니다. "9월부터 AI가 못 읽는다"는 과장입니다
• 다만 학습 차단 하나가 검색 노출을 함께 끊을 수 있다는 점은 실제 위험입니다
• 확인은 브라우저가 아니라 봇과 같은 조건의 요청으로 합니다
• 응답 코드만 믿지 마세요. 내용까지 확인해야 합니다 — 저희도 여기서 틀렸습니다

출처

• Cloudflare Changelog — New options to manage AI traffic
• Cloudflare — Block AI Bots
• OpenAI — Bots
• Google — HTTP status codes and network errors

최종 확인 2026-09. ⚠️ 봇 분류 정책과 크롤러 IP 대역은 예고 없이 바뀝니다. 설정을 바꾸기 전에 위 문서를 다시 확인하시기 바랍니다.

---

다음 단계 — 문이 실제로 열려 있다는 걸 확인했다면, 그다음은 들어와서 읽을 것이 있느냐입니다.

• AI봇이 우리 사이트에 들어올 수 있나? — 이 글의 앞 단계
• 이미지에 담긴 정보는 AI가 못 읽나? — 다음 지표
• AI 가독성이란 무엇인가 — 8개 지표 전체 보기
• 무료 진단 받기 — 우리 사이트의 AI봇 접근 상태 확인