구글봇 방문이 갑자기 줄었습니다 — 크롤 통계 보고서로 원인 좁히는 순서

어느 날부터 로그에 잡히는 구글봇 요청 수가 눈에 띄게 줄어든다. 새 글을 올려도 색인까지 걸리는 시간이 길어지고, 서치콘솔의 '이 페이지가 색인되지 않은 이유'에 '검색되었지만 아직 색인되지 않음'이 쌓인다. 이럴 때 담당자는 대부분 색인 문제부터 의심하지만, 원인은 한 단계 앞 — 구글이 애초에 사이트를 얼마나 자주, 얼마나 깊게 긁어가고 있는지에 있는 경우가 많다. 이 질문에 답을 주는 것이 서치콘솔의 크롤 통계(Crawl Stats) 보고서다. 설정 메뉴 안쪽에 있어 잘 안 열어보는 보고서지만, 색인 문제를 진단할 때는 페이지 색인 보고서보다 먼저 봐야 하는 자료다.

크롤 통계 보고서, 어디서 무엇을 보나

서치콘솔 좌측 하단 '설정 > 크롤링 > 크롤 통계 보기'로 들어가면 최근 90일간의 일별 크롤링 요청 수, 다운로드 크기, 평균 응답 시간이 그래프로 뜬다. 절대값 자체보다 추세 변화를 본다. 특정 날짜를 기점으로 요청 수가 계단식으로 꺾였다면 그 시점에 무슨 일이 있었는지부터 찾는다. 배포, 호스팅 이전, robots.txt 수정, CDN·방화벽 설정 변경 시점과 겹치는지 대조하는 것이 첫 순서다. 그래프 아래에는 호스트 상태(정상/문제 있음), 응답 코드별 비중, 파일 유형별 비중, 크롤링 목적(새로 발견/새로고침), 구글봇 유형별 비중이 표로 함께 제공된다.

응답 코드 표부터 확인한다

가장 먼저 볼 표는 '응답별 크롤링 요청'이다. 200이 압도적으로 줄고 5xx나 시간 초과 비중이 늘었다면 서버·호스팅 쪽 문제다. 특정 시간대에 서버 부하가 몰려 구글봇 요청에 5xx를 반환한 이력이 있는지 접속 로그와 대조한다. 반대로 301·404 비중이 갑자기 늘었다면 최근 URL 구조를 바꿨거나 대량의 페이지를 삭제·이전한 이력을 의심한다. 리다이렉트가 여러 단계로 이어지는 체인이 생기면 구글봇이 같은 콘텐츠에 도달하기 위해 요청을 여러 번 소모하게 되어, 결과적으로 다른 페이지를 크롤링할 여력이 줄어든다. 이 부분은 사이트를 옮긴 지 얼마 안 됐다면 사이트 이전에서 순위를 지키는 순서에서 다룬 301 매핑 점검과 같은 절차로 다시 확인하는 게 빠르다.

호스트 상태와 robots.txt 접근성

표 위쪽의 '호스트 상태'가 '문제 있음'으로 표시되면 구글이 robots.txt를 가져오지 못했거나, DNS 조회에 실패했거나, 서버 연결 자체가 원활하지 않았다는 뜻이다. robots.txt는 파일이 존재하지 않아도 문제가 되지만, 반대로 파일이 있는데 서버가 5xx를 반환해도 구글은 안전하게 크롤링을 잠시 중단하는 방향으로 동작한다. robots.txt에 접속해 실제로 200이 뜨는지, 최근 배포에서 실수로 차단 규칙이 추가되지 않았는지부터 눈으로 확인한다. 방화벽·CDN에서 구글봇 UA나 IP 대역을 차단 목록에 올린 적이 있는지도 함께 점검한다. 구글봇 UA를 사칭한 스팸 트래픽 때문에 차단 규칙을 걸었다가 진짜 구글봇까지 막히는 경우가 실무에서 자주 나오는데, 이 구분법은 진짜 크롤러인지 가리는 순서에서 정리한 역DNS 검증으로 확인할 수 있다.

크롤 예산이 엉뚱한 곳에 쓰이고 있는지

서버도, robots.txt도 정상인데 크롤링 요청이 줄었다면 남은 후보는 크롤 예산 낭비다. 필터·정렬·페이지네이션 파라미터가 붙은 URL이 무한에 가깝게 생성되는 게시판·쇼핑몰 구조에서 특히 잦다. '파일 유형별' 표에서 HTML이 아닌 이미지·CSS·JS 요청 비중이 비정상적으로 크거나, 크롤링 목적 표에서 '새로고침'만 반복되고 '새로 발견'이 거의 없다면, 구글이 새 페이지를 찾아 나서기보다 기존에 알고 있던 URL만 반복 확인하고 있다는 신호다. 이럴 때는 중복·저가치 URL을 robots.txt나 canonical, 파라미터 처리 설정으로 정리해 구글봇이 실제 콘텐츠 페이지에 요청을 더 쓰도록 유도한다. 사이트맵을 최신 상태로 유지하는 것도 이 단계에서 함께 점검할 부분인데, 사이트맵을 제출했는데도 반영이 더딘 경우는 sitemap.xml이 하는 일과 못 하는 일에서 다룬 한계와 겹치는 지점이 많다.

기준선을 오판하지 않는다

신생 사이트이거나 페이지 수가 적은 사이트라면 크롤링 요청 수 자체가 원래 적다. 하루 수십 건 수준을 '급감'으로 오판해 불필요하게 서버 설정을 건드리는 경우가 있는데, 이때는 절대값보다 자기 사이트의 과거 90일 추세와 비교하는 것이 맞다. 또 CDN이 캐시된 응답을 대신 내려주는 구간이 있으면 오리진 서버 로그와 서치콘솔 수치가 다르게 보일 수 있다. 이 경우 CDN 쪽 엣지 로그도 함께 확인해야 실제로 구글봇이 도달했는지 판단할 수 있다.

점검 순서 요약

• 1) 크롤 통계 보고서에서 꺾인 날짜를 확인하고 배포·이전·설정 변경 이력과 대조한다
• 2) 응답 코드 표에서 5xx·시간 초과 비중, 301·404 급증 여부를 본다
• 3) 호스트 상태와 robots.txt 실제 응답을 눈으로 확인한다
• 4) 방화벽·CDN 차단 목록에 구글봇이 잘못 걸려 있지 않은지 역DNS로 검증한다
• 5) 파일 유형·크롤링 목적 표에서 예산이 저가치 URL에 낭비되고 있는지 본다
• 6) 자기 사이트의 과거 추세와 비교해 절대값만으로 급감을 오판하지 않는다

크롤 통계는 순위를 직접 알려주는 지표는 아니지만, 색인·순위 문제의 상당수가 여기서 신호를 먼저 보낸다. 페이지 색인 보고서에서 원인을 못 찾겠다면 한 단계 앞의 이 보고서부터 열어보는 순서를 권한다.