Cloudflare를 붙인 뒤 검색이 흔들린다면 — 기본값 그대로 두면 위험한 5가지

Cloudflare는 무료 플랜만으로도 SSL·DDoS 방어·CDN을 한 번에 해결해 주는 도구입니다. 문제는 붙이는 순간 사이트 앞단에 새로운 층이 하나 생긴다는 점입니다. 이 층이 검색엔진에게 무엇을 보여 주느냐에 따라 색인과 순위가 조용히 흔들립니다. 실제 운영에서 반복해서 마주친 다섯 가지를 정리합니다.

1. 주황 구름과 회색 구름 — 켜는 게 항상 정답은 아닙니다

DNS 레코드 옆 구름 아이콘이 주황색이면 트래픽이 Cloudflare를 거쳐 갑니다(프록시 ON). 회색이면 DNS 조회만 대신하고 접속은 서버로 직접 갑니다(DNS only). 프록시를 켜면 원본 IP가 숨겨지고 방화벽과 캐시를 쓸 수 있지만, 모든 요청이 엣지를 한 번 더 경유합니다. 방문자가 사실상 전부 국내이고 서버도 국내에 있다면, 이 경유가 오히려 응답 시간을 늘리는 경우가 있습니다. 국내 사용자 비중이 높은 사이트를 DNS only로 되돌렸을 때 체감 속도가 개선된 사례가 실제로 있습니다. 켜고 끄고를 취향으로 정하지 말고 전환 전후 TTFB를 실측해 판단해야 합니다.

2. robots.txt는 캐시됩니다 — 고쳤는데 반영이 안 되는 이유

가장 헷갈리는 지점입니다. Cloudflare는 robots.txt처럼 확장자가 정적인 파일을 정적 자원으로 보고 엣지에 캐시합니다. 그래서 서버에서 파일을 고쳐도 몇 시간 동안 예전 내용이 그대로 응답됩니다. 반면 sitemap.xml을 PHP로 동적 생성하는 구조라면 캐시 대상이 아니라 수정이 즉시 반영됩니다. 같은 날 같은 방식으로 고쳤는데 하나만 반영되는 것처럼 보이는 이유가 이것입니다. robots.txt를 수정했다면 캐시 퍼지를 실행하고, 외부 네트워크에서 실제 응답 본문을 직접 확인하십시오. 브라우저 새로고침만으로는 확인되지 않습니다.

3. 봇 차단이 검색엔진까지 막는 사고

이게 가장 위험합니다. Bot Fight Mode를 켜거나 Security Level을 높이면 크롤러 요청이 챌린지 페이지를 받게 됩니다. 검색엔진 입장에서는 본문 대신 자바스크립트 검증 화면을 수집하는 셈이라, 페이지가 통째로 색인에서 빠질 수 있습니다. 트래픽의 상당 부분이 상업용 크롤러라 이를 차단하는 것 자체는 합리적인 선택이지만, 차단 규칙을 넣은 뒤에는 반드시 검색엔진 UA로 200 응답을 확인해야 합니다. 서버 로그에서 Googlebot·Yeti 요청의 상태 코드를 뽑아 보는 것이 가장 확실하고, 서치콘솔의 URL 검사에서 '실제 페이지 테스트'를 돌려 렌더링 결과를 눈으로 보는 방법도 있습니다.

4. SSL/TLS 모드가 만드는 무한 리다이렉트

SSL/TLS 설정을 Flexible로 두면 Cloudflare는 방문자와 HTTPS로, 서버와는 HTTP로 통신합니다. 그런데 서버 쪽에 "HTTP로 오면 HTTPS로 보내라"는 규칙이 있으면 둘이 서로에게 요청을 떠넘겨 리다이렉트 루프가 생깁니다. 브라우저는 ERR_TOO_MANY_REDIRECTS를 띄우고 크롤러는 그 URL을 포기합니다. 서버에 정상 인증서가 있다면 Full (strict)가 정답입니다. 인증서 발급이 어려운 상황이라면 Flexible을 임시로 쓰되, 서버 쪽 강제 HTTPS 규칙을 함께 손봐야 합니다.

5. 자동 최적화가 렌더링을 깨는 경우

Rocket Loader, 자동 축소(Minify), Mirage 같은 기능은 켜기만 하면 속도가 좋아질 것처럼 보입니다. 그러나 Rocket Loader는 스크립트 실행 순서를 바꾸기 때문에 구조화 데이터를 주입하는 스크립트나 메뉴 동작이 깨지는 사고가 종종 발생합니다. 기능을 켠 뒤에는 구조화 데이터 검사 도구로 스키마가 그대로 읽히는지, 모바일에서 메뉴가 실제로 열리는지 확인해야 합니다. 속도 점수를 몇 점 올리려다 핵심 기능을 잃으면 손해입니다. 무엇을 먼저 고쳐야 하는지는 Core Web Vitals 우선순위 정리에서 다뤘습니다.

붙인 다음 날 해야 할 점검 순서

• 외부 네트워크에서 robots.txt·sitemap.xml 본문을 직접 열어 최신 내용인지 확인
• 검색엔진 UA로 주요 페이지 요청 → 200 응답과 본문 정상 여부 확인
• 서치콘솔 URL 검사에서 실제 페이지 테스트 → 렌더링 화면 육안 확인
• www·비www, http·https 네 가지 조합이 모두 한 번의 리다이렉트로 대표 주소에 도달하는지 확인
• 자동 최적화 기능을 켰다면 스키마·메뉴·폼 동작 재확인

정리 — 도구가 아니라 설정이 문제입니다

Cloudflare 자체가 검색에 불리하다는 말은 사실이 아닙니다. 다만 기본값이 모든 사이트에 맞게 조율되어 있지도 않습니다. 앞단에 층을 하나 더 놓았다면 그 층이 크롤러에게 무엇을 응답하는지 직접 확인하는 절차가 반드시 따라와야 합니다. 도입 이후 색인 수나 노출이 계단식으로 떨어졌다면 콘텐츠를 고치기 전에 이 다섯 가지부터 점검하십시오. 사이트 관리 항목 전반은 유지관리 서비스 페이지에 정리해 두었습니다.