Cloudflare를 붙인 뒤 “사이트는 잘 열리는데 Google에서만 페이지가 덜 잡히는” 상황이 종종 생깁니다. 대개 서버가 죽은 게 아니라, 크롤러가 보는 응답(상태코드/헤더/리다이렉트/캐시)이 바뀌면서 검색/크롤링 신호가 흔들리는 경우가 많아요.
아래는 문제 징후 → 원인 → 해결 → 재검증 순서로, SEO 관점에서 빠르게 복구하는 점검 루트입니다.
1) 문제 징후: Search Console에 ‘크롤링됨 - 현재 색인 생성되지 않음’이 늘고, 크롤링 통계가 떨어짐
특히 Cloudflare 적용 직후 또는 WAF/봇 관련 설정을 손댄 직후, 색인이 느려지거나 누락되는 패턴이 자주 보입니다. 사용자 브라우저에서는 정상인데, 크롤러가 받는 응답이 다르면 이런 현상이 생깁니다.
- Search Console: 발견됨/크롤링됨이 늘고 ‘색인 생성되지 않음’이 증가
- 특정 경로(예: /category/, /tag/, /page/)만 유독 덜 잡힘
- 서버 로그에서 Googlebot 요청이 403/429/5xx로 섞임
2) 원인 후보 A: Cloudflare WAF/봇 정책이 Googlebot을 오탐으로 막음(403/1020/429)
SEO 관점에서 가장 치명적인 건 “크롤러에만 차단/지연”이 발생하는 케이스입니다. Cloudflare의 WAF, Bot Fight Mode, Rate Limiting(또는 WAF Rate limiting), 특정 Firewall Rule이 Googlebot의 패턴을 공격으로 오탐할 수 있어요.
해결
- Cloudflare 이벤트 로그(Security Events)에서 차단된 요청의 User-Agent, 경로, Rule ID를 확인합니다.
- Googlebot 관련 차단이 의심되면, 우선 해당 Rule을 “로그만”으로 바꾸거나 예외(Allow) 범위를 최소로 추가합니다.
- Rate Limiting을 사용 중이면, 크롤러가 많이 접근하는 경로(예: sitemap, 카테고리 목록, 페이지네이션)에 과도한 제한이 걸리지 않게 조정합니다.
- Bot Fight Mode를 켰다면, 영향 범위를 재점검합니다(특히 비로그인 공개 페이지).
재검증
- Search Console의 ‘URL 검사’로 해당 URL을 “실제 테스트”하고, 크롤링 가능/차단 여부를 확인합니다.
- 서버 접근 로그(원본 서버)에서 Googlebot 요청이 정상적으로 200을 받는지 확인합니다.
- Cloudflare Security Events에서 같은 URL에 대한 차단 이벤트가 사라졌는지 확인합니다.
3) 원인 후보 B: HTML이 캐시에 잘못 고정되어 noindex/잘못된 canonical이 퍼짐
Cloudflare 캐시가 “정상 페이지”를 빠르게 배달해주는 건 장점이지만, 반대로 잠깐 잘못 나간 HTML이 캐시로 고정되면 검색 신호가 크게 흔들릴 수 있습니다. 예를 들면 점검 페이지/임시 noindex/잘못된 canonical/언어 태그가 캐시되어 크롤러가 그것만 계속 보는 상황이죠.
대표 징후
- Firefox에서는 정상인데, 다른 환경(크롤러/해외 POP)에서만 meta robots가 다르게 보임
- canonical이 http로 나오거나, 다른 도메인으로 고정됨
- 페이지마다 같은 canonical(홈으로)로 찍힘
해결
- HTML(문서) 캐시 정책을 먼저 확인합니다. “모든 것을 캐시(Cache Everything)”류의 규칙을 쓰고 있다면, 로그인/개인화/상태에 따라 HTML이 달라지는 구간은 예외 처리합니다.
- Cloudflare에서 해당 경로를 Cache Bypass 또는 Respect Existing Headers로 돌리고, 원본 서버의 Cache-Control을 의도대로 정리합니다.
- 잘못 캐시된 문서를 정리하기 위해 Purge(해당 URL 또는 prefix)를 수행합니다.
재검증
- Firefox에서 개발자도구(Network)로 문서 응답 헤더를 확인해 CF-Cache-Status(HIT/MISS)와 Cache-Control을 비교합니다.
- Search Console ‘URL 검사’의 렌더링 결과에서 meta robots/canonical이 의도대로인지 확인합니다.
4) 원인 후보 C: http→https, www/non-www, trailing slash 리다이렉트가 꼬여 크롤링 예산을 낭비
Cloudflare의 Redirect Rules / Page Rules, 원본 서버(Nginx/Apache), 애플리케이션(예: CMS) 리다이렉트가 겹치면 301 체인이 길어지거나 루프가 생길 수 있습니다. 사용자는 눈치 못 채도 크롤러는 리다이렉트 체인을 비용으로 계산하고, 최악이면 색인을 포기합니다.
해결
- 리다이렉트의 “단일 책임”을 정합니다. Cloudflare에서 할지, 원본에서 할지 한쪽으로 정리하는 게 안전합니다.
- 정규화 규칙을 1~2스텝으로 줄입니다: http→https, non-www→www(또는 반대), slash 정책을 일관되게.
- 모든 리다이렉트는 최종 URL에서 200(또는 304)으로 끝나야 합니다. 중간에 302가 섞이면 의도치 않은 신호가 될 수 있습니다.
재검증
- Firefox에서 문제가 되는 URL을 입력하고 최종 도착 URL이 한 번에 결정되는지 확인합니다.
- Search Console의 “리디렉션 오류”, “소프트 404” 보고서 변화를 며칠 단위로 확인합니다.
5) 원인 후보 D: robots.txt / sitemap이 Cloudflare 뒤에서 다르게 제공되거나 캐시로 꼬임
robots.txt와 sitemap.xml은 SEO에서 ‘교통정리 표지판’ 같은 역할인데, Cloudflare 설정 변경 후 서로 다른 내용이 캐시되거나, 특정 국가/POP에서 403/404가 나면 크롤링 흐름이 무너질 수 있습니다.
해결
- robots.txt는 반드시 200으로 제공되고, 중요한 경로(예: /wp-admin/ 같은 관리영역)만 제한되는지 확인합니다. 실수로 Disallow: / 를 배포하는 경우가 의외로 흔합니다.
- sitemap.xml이 리다이렉트 체인을 타지 않고 200으로 응답하는지, gzip/캐시로 깨지지 않는지 확인합니다.
- Cloudflare에서 robots/sitemap 경로는 과한 보안/레이트리밋/캐시 규칙의 영향을 덜 받게 예외를 둡니다(필요 시).
재검증
- Search Console에서 sitemap 재제출 후, “가져올 수 없음”/“리디렉션됨” 같은 상태가 없는지 확인합니다.
- robots.txt 테스트(또는 URL 검사)를 통해 차단 규칙이 의도대로 동작하는지 확인합니다.
6) 빠른 체크리스트: 원인 좁히기용(10분 컷)
- Search Console: 영향 범위가 전체인지 특정 디렉터리인지 먼저 분리
- Cloudflare Security Events: 403/1020/429가 Googlebot에서 발생하는지 확인
- 캐시: HTML에 noindex/canonical이 캐시로 고정되는 구조인지 점검
- 리다이렉트: http/https, www, slash 정규화가 1~2번 이내로 끝나는지
- robots/sitemap: 200 응답, 내용 정상, 불필요한 캐시/차단 규칙 없는지
마무리
Cloudflare 이후 SEO가 흔들릴 때는 “페이지가 열리냐”보다 크롤러가 어떤 응답을 받느냐가 핵심입니다. 차단(403/429) → 잘못 캐시된 HTML → 리다이렉트 체인 → robots/sitemap 순서로 보면 대체로 빠르게 원인이 좁혀집니다.
한 번에 다 바꾸기보다, 한 가지 수정 후 Search Console과 로그로 재검증하며 단계적으로 되돌리는 게 가장 안전합니다.