Core Web Vitals(LCP/INP/CLS)는 좋아졌는데, Search Console에서 ‘색인 생성’이나 ‘크롤링’ 지표가 흔들리고 검색 유입이 줄어드는 경우가 있습니다. 이때는 “성능 문제”가 아니라 “크롤러가 들어오는 경로(robots/sitemap/redirect)”가 어딘가에서 꼬였을 가능성이 큽니다.
아래는 Cloudflare를 쓰는 사이트에서 자주 놓치는 순서대로, 빠르게 확인하고 되돌리는 체크리스트입니다.
1) 먼저 증상을 ‘CWV’가 아니라 ‘크롤링 경로’로 분리하기
시작은 간단합니다. 성능 지표가 좋으면 “페이지를 못 읽어서 떨어졌다”기보다 “찾아오지 못한다/가야 할 URL이 달라졌다/막혔다” 쪽을 의심하는 게 빠릅니다.
- Search Console > 페이지(색인)에서 ‘제외됨’이 늘었는지 확인
- Search Console > 설정 > 크롤링 통계에서 ‘응답 코드’ 변화(특히 3xx/4xx 증가) 확인
- 서버 로그/Cloudflare Analytics에서 Googlebot 요청이 줄었는지 확인
핵심은 “사용자 체감은 빠른데, Googlebot이 길을 잃었다”는 시나리오를 세우고 아래 항목을 위에서부터 내려오는 것입니다.
2) robots.txt: 차단 규칙·캐시·호스팅 경로를 먼저 의심
Cloudflare를 쓰면 robots.txt도 CDN 경로에서 제공됩니다. 배포 직후/설정 변경 직후에 예전 robots가 남아 있거나, 특정 경로에서 다른 robots가 나오면 크롤링이 바로 흔들립니다.
- https://example.com/robots.txt를 브라우저와 curl로 확인(응답 코드, 내용, 캐시 헤더)
- Disallow: / 같은 강한 규칙이 임시로 들어간 적이 없는지 확인
- 스테이징 규칙이 운영에 섞였는지 확인(예: User-agent: * 아래에 넓은 Disallow)
- 멀티 도메인/서브도메인 운영 시, 도메인마다 robots가 달라지는지 확인
Cloudflare에서 robots.txt가 의도와 다르게 나올 때는, 먼저 해당 파일이 원본(Origin)에서 제대로 제공되는지 확인한 다음 Cloudflare 캐시를 정리하는 순서가 안전합니다. (robots를 HTML처럼 변환/압축하는 설정은 보통 영향이 없지만, 잘못된 캐시 정책이 걸리면 구버전이 오래 남을 수 있습니다.)
3) sitemap: ‘접근 가능(200)’ + ‘정규 URL만 포함’이 핵심
sitemap은 “검색 엔진에게 알려주는 길 안내판”이라서, 내용이 조금만 어긋나도 색인이 흔들립니다. CWV가 좋더라도 sitemap이 잘못되면 유입이 빠질 수 있어요.
- sitemap URL이 200으로 열리는지 (301/302로 다른 곳으로 보내지 않는지)
- sitemap이 gzip/압축되어도 문제 없지만, 응답이 깨지거나 HTML로 렌더링되면 실패할 수 있음
- 사이트가 https로 통일되었는데 sitemap에 http URL이 섞이지 않았는지
- www/논-www, 슬래시(/) 유무, 대소문자 등 정규화 규칙과 sitemap의 URL이 일치하는지
- 품질 측면에서 noindex 페이지, 리다이렉트되는 URL, 404 URL이 sitemap에 포함되지 않았는지
Cloudflare 환경에서는 “sitemap은 열리는데 Search Console에서 읽기 실패”가 가끔 나오는데, 그때는 리다이렉트 체인(다음 섹션)이나 방화벽/봇 정책(특정 User-Agent에만 차단)이 원인인 경우가 많습니다.
4) Redirect: ‘체인 최소화’ + ‘canonical과 일치’가 성능/SEO를 같이 살림
리다이렉트는 SEO 체크리스트 항목이지만, 성능(Core Web Vitals)에도 직결됩니다. 리다이렉트가 한 번 늘어날 때마다 초기 로딩이 지연되고 LCP 기회가 나빠질 수 있어요.
- http → https → www → 최종 URL처럼 2~3단 체인이 생기지 않는지 (가능하면 1번에 끝내기)
- 302(임시)가 남아있지 않은지 (영구 이동이면 301로 정리)
- Cloudflare Redirect Rules/Page Rules와 Origin(Nginx/Apache/App) 리다이렉트가 겹쳐서 루프가 나지 않는지
- 슬래시 유무(/about vs /about/)가 계속 바뀌면서 301이 발생하지 않는지
- 리다이렉트 후 최종 페이지의 canonical이 실제 최종 URL과 일치하는지
권장 흐름은 “정규화는 한 군데에서만”입니다. Cloudflare에서 강제 https/호스트 정규화를 한다면, Origin에서도 중복 리다이렉트를 최소화해 체인을 줄이는 게 CWV에도 유리합니다.
5) Cloudflare에서 크롤러를 막는 흔한 지점: WAF/봇/캐시 예외
robots/sitemap/redirect가 맞는데도 색인이 떨어진다면, 실제로는 Googlebot이 중요한 엔드포인트(robots, sitemap, HTML, 렌더링에 필요한 JS/CSS)를 가져올 때 막히는 경우가 있습니다.
- WAF Managed Rules에서 특정 규칙이 정상 크롤러까지 차단/챌린지하는지(이벤트 로그로 확인)
- Bot Fight Mode / Super Bot Fight Mode 사용 시, 크롤링에 불리한 챌린지가 걸리지 않는지
- Rate Limiting으로 sitemap/카테고리 페이지 접근이 제한되지 않는지
- 캐시 정책 때문에 HTML이 비정상(오래된 canonical/오래된 robots 링크 포함)으로 제공되지 않는지
체감 성능(CWV) 개선 과정에서 보안/캐시 설정을 만지다가, “사람에게는 빠른데 봇에게는 불친절한” 상태가 되기도 합니다. 이때는 Cloudflare의 보안 이벤트/로그를 기준으로, 어떤 경로가 막히는지부터 좁혀가는 게 가장 빠릅니다.
6) 실전 SEO 체크리스트(Cloudflare + CWV 관점): 한 번에 점검하는 순서
- robots.txt: 200 응답, Disallow 과다 여부, 도메인별 일치
- sitemap: 200 응답, 정규 URL만 포함, 리다이렉트/404/noindex 제외
- redirect: 1-hop 목표, 302 제거, 루프/체인 제거, canonical 일치
- Cloudflare 보안: WAF/봇/레이트리밋이 Googlebot 요청에 영향 없는지 로그로 확인
- 성능(CWV): 리다이렉트 감소가 LCP에 즉시 도움, 중요한 리소스(JS/CSS/폰트) 크롤링 가능 여부 확인
이 순서를 추천하는 이유는, 앞의 항목일수록 “사이트 전체에 즉시 영향”을 주고, 뒤로 갈수록 케이스가 다양해져서 진단 시간이 길어지기 때문입니다.
마무리
CWV가 좋아졌는데도 검색 유입이 줄면, 대부분은 “페이지가 느려서”가 아니라 “크롤링이 가야 할 길이 틀어져서” 생깁니다. robots/sitemap/redirect는 작은 변경도 파급이 커서, 반드시 순서대로 확인하는 게 안전합니다.
점검 중에 301 체인이 길거나, sitemap이 리다이렉트되거나, Cloudflare 보안 이벤트에서 크롤러가 챌린지되는 흔적이 보이면 그 지점부터 정리해 보세요.