Cloudflare를 붙인 뒤부터 robots.txt를 수정해도 반영이 늦거나(혹은 안 되는 것처럼 보이거나), Googlebot/Bingbot이 엉뚱한 판단을 하는 사례가 종종 있습니다. 실제 원인은 robots.txt 문법보다 캐시·리다이렉트·응답코드 쪽에서 더 자주 나옵니다.
아래는 “운영 중 당장 복구” 관점의 점검 루트입니다.
1) 먼저 확인할 것: robots.txt가 어떤 URL로 제공되는지
robots.txt는 원칙적으로 사이트 루트의 단일 경로로만 봅니다. 즉 아래가 기준입니다.
- 정상 기준: https://example.com/robots.txt
- 서브도메인 별도 운영이면: https://www.example.com/robots.txt, https://m.example.com/robots.txt 각각 따로 관리
Cloudflare를 쓸 때 특히 흔한 함정이 “www → non-www(또는 반대)” 리다이렉트 구조입니다. 크롤러가 어떤 호스트로 먼저 접근하느냐에 따라 robots.txt를 다르게 가져갈 수 있습니다.
- Search Console에서 속성을 여러 개(도메인/URL 접두어)로 나눠 쓰고 있다면, 각 속성에서 robots.txt 접근 호스트가 일치하는지 확인합니다.
- Canonical, sitemap URL, 내부 링크가 모두 같은 호스트 정책을 따르는지 같이 봅니다.
2) 핵심: Cloudflare 캐시가 robots.txt를 “오래” 붙잡고 있는지
robots.txt는 자주 바뀌지 않는 파일이라 중간 캐시가 길게 잡혀도 이상하지 않습니다. 하지만 운영 중 긴급 차단/해제처럼 변경이 잦으면 robots.txt는 오히려 짧게 캐시하는 편이 안전합니다.
- Cloudflare 캐시(Hit)가 계속 나오면, 원본 수정이 즉시 반영되지 않을 수 있습니다.
- Browser cache보다 CDN edge 캐시가 문제인 경우가 많습니다.
실전 권장 순서:
- Purge: Cloudflare에서 robots.txt만 선택적으로 Purge(가능하면 URL 단위)합니다.
- 캐시 정책 조정: robots.txt에 대해 Cache-Control을 짧게(예: max-age를 낮게) 운영하거나, Cloudflare Rules에서 해당 경로만 캐시를 약하게 설정합니다.
- 확인: 응답 헤더에서 CF-Cache-Status가 MISS/BYPASS로 바뀌는지 확인합니다.
주의: “Cache Everything” 같은 규칙을 이미 쓰고 있다면 robots.txt까지 HTML처럼 강캐시될 수 있습니다. 이 경우 /robots.txt는 예외로 빼는 게 안전합니다.
3) 리다이렉트(301/302/307/308)가 robots.txt에 걸려 있지 않은지
robots.txt 자체가 리다이렉트 되는 구성은 의도치 않은 부작용을 만들 수 있습니다. 크롤러가 리다이렉트를 따라가긴 하지만, 중간에 규칙/캐시/보안 요소가 얽히면 “가져오지 못함”으로 처리될 여지가 커집니다.
- /robots.txt → /robots.txt/ (슬래시 붙이기) 같은 리다이렉트
- http → https, non-www → www가 robots.txt에까지 적용
- 국가/언어 리다이렉트(Geo Redirect)가 robots.txt에도 적용
운영 관점 권장: /robots.txt는 최종 200 OK로 바로 응답되게 만들고, 불필요한 리다이렉트를 제거합니다.
4) 응답코드/콘텐츠 타입/본문이 크롤러 친화적인지
robots.txt는 단순 텍스트 파일이라, 기본이지만 아래가 깨지면 크롤러 판단이 급격히 흔들립니다.
- HTTP 200으로 안정적으로 내려오는지(간헐적 5xx, 403이 있는지)
- Content-Type이 text/plain(혹은 호환되는 텍스트 타입)인지
- 본문이 HTML(에러 페이지)로 대체되지 않았는지
- UTF-8 인코딩 깨짐으로 규칙이 이상하게 해석되지 않는지
특히 Cloudflare에서 WAF/봇 보호가 강할 때, 일반 브라우저는 통과하지만 특정 크롤러 요청이 403/401을 받는 케이스가 있습니다. robots.txt가 막히면 크롤러는 보수적으로 행동해서 “차단된 것처럼” 보일 수 있습니다.
5) Cloudflare Rules/WAF/봇 관련 설정이 robots.txt에만 과하게 적용되는지
운영 중 흔한 패턴은 “보안 강화”를 하면서 /wp-login.php, /admin 같은 경로만 막으려 했는데, 룰이 넓게 잡혀 /robots.txt나 /sitemap.xml까지 영향을 주는 경우입니다.
- Firewall Rules(또는 WAF Managed Rules)에서 User-Agent/ASN/IP 조건이 광범위한지
- Bot Fight Mode/슈퍼 봇 차단 계열 기능이 robots.txt 요청에 영향을 주는지
- Rate Limiting이 특정 패턴에 걸려 크롤러가 robots.txt를 주기적으로 못 가져가는지
권장 접근은 “전체 완화”가 아니라 /robots.txt, /sitemap.xml만 예외적으로 안정 통과시키는 방식입니다. 크롤링 기반 유입을 쓰는 사이트라면 이 두 개는 가급적 예측 가능하게 열어두는 편이 운영 리스크가 적습니다.
6) 재검증 체크리스트(운영자가 빠르게 보는 버전)
- 접근 URL: https://대표호스트/robots.txt 가 맞나?
- 응답코드: 200 OK로 즉시 떨어지나? 중간 3xx는 없나?
- 본문: 에러 HTML이 아니라 실제 robots 규칙 텍스트인가?
- 캐시: Cloudflare에서 robots.txt가 과캐시되지 않나? Purge 후 갱신되나?
- 보안: WAF/Bot 설정이 robots.txt를 403으로 만들지 않나?
- 일관성: www/non-www, http/https, 국가리다이렉트가 robots.txt에 적용되지 않나?
체크 후에도 이상하다면, 문제를 빠르게 좁히는 방법은 “Cloudflare를 우회한 원본 응답”과 “Cloudflare 경유 응답”을 비교해 차이가 나는 지점을 찾는 것입니다(응답코드/헤더/본문/캐시상태 중심).
마무리
Cloudflare 환경에서 robots.txt 이슈는 문법 문제가 아니라 캐시와 경로(리다이렉트), 그리고 보안 룰이 겹치면서 생기는 경우가 많습니다. 먼저 robots.txt를 200 OK로 단순화하고, 캐시를 짧게 가져가며, 보안 예외를 최소 범위로 주는 순서가 운영적으로 가장 안전합니다.
한 번 안정화해두면 이후엔 robots 변경이 필요한 상황에서도 “왜 반영이 안 되지?” 같은 불확실성을 크게 줄일 수 있습니다.