서치 콘솔 크롤링 통계 보고서 완벽하게 읽는 법

구글 서치 콘솔의 크롤링 통계 보고서는 "구글봇이 내 사이트를 얼마나, 어떻게 돌아다녔는가"를 숫자로 보여주는 화면이다. 위치는 설정(속성 설정) > 크롤링 통계다. 메뉴 이름이 "크롤 통계"가 아니라 "크롤링 통계"라는 점부터 정확히 알아두자.

이 보고서를 처음 열면 숫자와 그래프만 잔뜩 있어 막막하다. 하지만 네 가지 핵심 지표와 네 가지 분류표만 읽을 줄 알면 내 사이트에 구글봇이 문제없이 드나드는지, 어디서 시간을 낭비하는지 바로 진단할 수 있다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 크롤링 통계 보고서의 위치와 접근 조건, 그리고 상단 4대 지표(총 요청 횟수, 다운로드 크기, 응답 시간, 호스트 상태)가 각각 무엇을 뜻하는지
• 호스트 상태가 어떤 세 가지 항목으로 판정되는지, 빨간불이 뜨면 무엇부터 봐야 하는지
• 응답 코드·파일 형식·크롤링 목적·구글봇 유형 4개 분류표를 실전에서 읽는 법과 좋은 예·나쁜 예
• 크롤링 통계와 크롤 버짓은 같은 말이 아니다 — 둘의 관계와 차이
• 2026년 8월 실제로 있었던 데이터 누락 버그 사례로 배우는, 이상 신호와 보고서 자체 오류를 구분하는 법

조금 더 풀어 말하면, 크롤링 통계 보고서는 검색 순위를 직접 보여주지 않는다. 대신 그 앞 단계, 즉 구글봇이 페이지를 발견하고 가져가는 과정 자체의 건강 상태를 보여준다. 이 단계가 막히면 아무리 좋은 콘텐츠를 만들어도 색인조차 되지 않는다.

이 글은 SEO 실무를 처음 맡은 담당자도 오늘 바로 자기 사이트 화면을 켜 놓고 따라 읽을 수 있도록, 화면 구성 순서 그대로 예시와 함께 정리했다. 이미 크롤 버짓 개념을 아는 사람이라면 뒷부분의 보고서를 실제로 읽고 진단하는 절차부터 봐도 좋다.

크롤링 통계 보고서란 무엇인가?

크롤링 통계 보고서는 최근 90일간 구글봇이 내 사이트에 보낸 크롤링 요청을 집계한 공식 데이터다. 여기서 크롤링이란 구글봇이 웹페이지를 방문해 내용을 가져가는 행동을 뜻하고, 그렇게 가져간 내용을 검색 데이터베이스에 등록하는 다음 단계가 색인이다.

이 보고서는 속성 하나가 아니라 도메인 전체(예: 내도메인.com과 그 하위 모든 서브도메인·프로토콜)를 기준으로 집계된다는 점이 특이하다. 서치 콘솔의 다른 보고서 대부분이 등록한 속성 단위로 데이터를 보여주는 것과 다르다.

접근 조건도 알아두자. 구글은 사이트가 최근에 등록되었거나 트래픽이 매우 적으면 데이터가 충분히 쌓이지 않아 보고서가 비어 있거나 부정확할 수 있다고 안내한다. 새로 만든 사이트라면 며칠에서 몇 주 정도는 데이터가 듬성듬성한 것이 정상이다.

크롤링 통계 보고서는 "검색에 얼마나 잘 노출되는가"가 아니라 "구글봇이 내 사이트를 얼마나 원활하게 방문하는가"를 보여주는 인프라 진단 도구다.

크롤링과 색인은 어떻게 이어지나?

결론부터 말하면, 크롤링이 막히면 그 뒤에 오는 색인 단계 자체가 시작되지 않는다. 구글이 페이지를 검색 결과에 올리기까지는 대략 세 단계를 거친다.

1. 발견: 사이트맵, 내부 링크, 외부 링크 등을 통해 새 URL의 존재를 알게 된다.
2. 크롤링: 구글봇이 실제로 그 URL에 접속해 콘텐츠를 가져간다. 크롤링 통계 보고서가 보여주는 부분이 바로 여기다.
3. 렌더링·색인: 가져온 콘텐츠를 해석하고(자바스크립트 실행 포함), 검색 데이터베이스에 등록할지 판단한다.

이 세 단계는 순서대로 진행되기 때문에, 2단계인 크롤링에서 문제가 생기면 3단계인 색인은 아예 시도조차 되지 않는다. 예를 들어 새 블로그 글을 발행했는데 색인 리포트에서 "발견됨, 아직 색인되지 않음"이라는 상태가 오래 유지된다면, 색인 로직을 의심하기 전에 크롤링 통계 보고서에서 해당 시기에 요청 자체가 들어갔는지부터 확인하는 것이 순서에 맞는다.

반대로 크롤링은 정상적으로 이루어지는데 색인만 안 되는 경우도 있다. 이때는 크롤링 문제가 아니라 콘텐츠 품질이나 noindex 태그(검색엔진에 "이 페이지는 색인하지 말라"고 알리는 메타 태그) 설정처럼 3단계의 문제일 가능성이 크다. 두 문제를 구분하는 것만으로도 원인 파악 시간을 절반 이상 줄일 수 있다.

크롤링 통계 보고서는 어디서, 어떻게 보나?

경로는 간단하다. 서치 콘솔 좌측 메뉴에서 설정을 누르고, 크롤링 섹션의 크롤링 통계를 선택하면 "보고서 열기" 버튼이 나온다. 이 버튼을 눌러야 상세 화면으로 들어간다.

화면은 크게 세 구역으로 나뉜다. 맨 위에는 요청 수 추이를 보여주는 꺾은선 그래프, 그 아래 4개의 요약 카드(총 크롤링 요청 횟수, 총 다운로드 크기, 평균 응답 시간, 호스트 상태), 그리고 스크롤을 내리면 호스트 상태 상세와 4개의 분류 표(응답별, 파일 형식별, 목적별, Googlebot 유형별)가 이어진다.

각 분류 표는 항목을 클릭하면 해당 조건에 해당하는 URL 예시 목록까지 펼쳐 보여준다. 예를 들어 "404" 항목을 누르면 최근 구글봇이 404 응답을 받은 실제 URL들이 뜬다. 이 예시 목록이 실전 진단에서 가장 쓸모 있는 부분이다.

상단 4대 지표는 각각 무엇을 뜻하나?

결론부터 말하면, 이 네 카드가 크롤링 통계 보고서의 요약본이다. 나머지 화면은 전부 이 네 숫자를 쪼개서 보여주는 상세 표에 불과하다.

지표	의미	읽는 법
총 크롤링 요청 횟수	성공·실패와 무관하게 구글봇이 보낸 전체 요청 수(중복 요청 포함)	사이트 규모 대비 급격히 늘거나 줄면 원인을 찾아야 한다
총 다운로드 크기	해당 기간 동안 다운로드한 총 바이트	이미지·동영상이 과도하게 무거우면 여기서 튄다
평균 응답 시간	구글봇이 리소스를 가져오는 데 걸린 평균 시간	이 수치가 꾸준히 늘어나면 서버 성능 저하의 조기 신호다
호스트 상태	최근 이용 가능성 문제 여부(양호·과거 문제·최근 문제)	초록이 아니면 다른 지표보다 먼저 확인

총 크롤링 요청 횟수부터 보자. 이 숫자는 "구글이 내 사이트를 얼마나 자주 찾아오는가"를 보여주지만, 요청이 많다고 무조건 좋은 것은 아니다. 필요 없는 URL(예: 파라미터가 계속 바뀌는 중복 페이지)을 계속 요청하고 있다면 오히려 낭비다.

총 다운로드 크기는 이미지·CSS·JavaScript 같은 리소스 무게와 직결된다. 최적화하지 않은 대용량 이미지가 많은 사이트일수록 이 수치가 크다. 예를 들어 상품 이미지 1장이 5MB인 쇼핑몰과, 같은 이미지를 300KB로 압축한 쇼핑몰은 같은 요청 횟수라도 다운로드 크기가 열 배 넘게 차이 난다.

평균 응답 시간은 서버가 얼마나 빨리 응답하는지를 밀리초 단위로 보여준다. 이 값이 짧을수록 구글봇은 같은 시간에 더 많은 페이지를 돌아볼 수 있다. 응답 시간이 느려지는 추세가 보이면 서버 증설이나 캐싱 점검을 검토할 시점이다.

호스트 상태는 어떤 기준으로 판정되나?

호스트 상태는 초록(문제없음)·노랑(과거 문제 있었음)·빨강(최근 문제 있음) 세 단계로 표시된다. 결론은 이렇다. 빨간불이 뜨면 다른 어떤 지표보다 먼저 이것부터 해결해야 한다. 호스트 자체가 불안정하면 나머지 데이터는 의미가 없다.

이 판정은 세 가지 세부 항목의 실패율을 근거로 매겨진다.

• robots.txt 가져오기: 구글봇이 robots.txt 파일을 요청했을 때 실패한 비율. robots.txt는 어떤 페이지를 크롤링해도 되는지 구글봇에게 알려주는 규칙 파일이다. 이 파일 자체를 못 가져오면 구글은 크롤링을 신중하게 줄이기도 한다.
• DNS 조회: 도메인 주소를 실제 서버 위치로 변환하는 과정의 실패율. DNS(도메인 네임 시스템)에 문제가 생기면 구글봇은 아예 사이트에 접속조차 못한다.
• 서버 연결: 구글봇이 서버에 접속을 시도했을 때 응답을 완전히 받지 못한 비율. 서버 과부하, 방화벽 오탐, 호스팅사 네트워크 장애 등이 원인이 된다.

호스트 상태가 노랑이나 빨강으로 바뀌면, 호스팅사에 "최근 서버 다운타임이나 방화벽 정책 변경이 있었는지"부터 물어보는 것이 가장 빠른 원인 파악 방법이다.

나쁜 예는 호스팅사를 저가 공유 호스팅으로 옮긴 뒤 트래픽 급증 시간대에 서버가 자주 응답을 못하는 경우다. 좋은 예는 CDN(콘텐츠 전송 네트워크)과 오토스케일링을 갖춘 인프라를 쓰거나, 최소한 트래픽이 몰리는 시간대의 서버 응답을 주기적으로 모니터링하는 경우다.

robots.txt 항목은 특히 사소한 실수로 실패율이 튀는 경우가 많다. 파일 자체가 없는 것과, 파일은 있지만 서버가 그 요청에 5xx 오류로 응답하는 것은 전혀 다른 문제다. 후자는 robots.txt 파일 하나만의 문제가 아니라 서버 전체가 불안정하다는 신호일 수 있어 더 심각하게 봐야 한다.

상황	robots.txt 상태	구글봇의 반응
좋은 예	200으로 정상 응답, 필요한 경로만 명확히 차단	규칙을 그대로 따르며 안정적으로 크롤링
나쁜 예 1	robots.txt 자체가 404	규칙이 없다고 판단해 크롤링을 이어가지만, 의도한 차단이 적용되지 않는다
나쁜 예 2	robots.txt 요청이 5xx로 실패	사이트 전체가 불안정하다고 판단해 크롤링 속도를 스스로 줄인다

크롤링 통계, AI 검색 시대에도 중요한가?

결론부터 말하면 그렇다. 오히려 더 중요해졌다. GEO(생성형 엔진 최적화)나 AEO(답변 엔진 최적화)라는 말이 낯설게 느껴질 수 있는데, 쉽게 풀면 챗봇형 AI 검색이 답변을 만들 때 내 콘텐츠가 근거로 쓰이도록 최적화하는 작업을 뜻한다.

문제는 AI가 아무리 똑똑해도, 구글봇 같은 전통적인 크롤러가 먼저 그 페이지를 수집하지 못하면 색인도, AI 답변 인용도 시작조차 되지 않는다는 점이다. AI 검색 결과에 쓰이는 콘텐츠 상당수는 여전히 기존 검색 색인 데이터베이스를 기반으로 한다. 즉 크롤링이라는 가장 기초적인 관문을 통과하지 못한 페이지는 AI 검색에서도 처음부터 후보에조차 오르지 못한다.

그래서 화려한 AI 최적화 기법을 고민하기 전에, 크롤링 통계 보고서에서 기본기(호스트 상태, 오류 비율, 응답 시간)부터 안정적으로 유지하는 것이 순서상 먼저다. 기초 공사가 부실한 채로 인테리어만 신경 쓰는 것과 같은 이치다.

응답별 분류는 무엇을 보여주나?

응답별 분류는 구글봇이 받은 HTTP 상태 코드(서버가 요청에 응답할 때 보내는 세 자리 숫자)를 비율로 보여준다. 결론은 이렇다. 200(정상) 비율이 압도적으로 높고, 4xx·5xx 오류 비율이 낮을수록 건강한 사이트다.

주요 코드를 정리하면 다음과 같다.

• 200(정상): 요청이 성공했다는 뜻. 대부분을 차지해야 정상이다.
• 301/302(리다이렉트): 페이지 주소가 다른 곳으로 옮겨졌다는 뜻. 일부는 정상이지만 비율이 지나치게 높으면 리다이렉트가 여러 단계로 이어지는 구조 문제일 수 있다.
• 404(찾을 수 없음): 요청한 페이지가 없다는 뜻. 삭제된 상품, 오래된 블로그 글의 내부 링크가 아직 남아 있을 때 흔히 발생한다.
• 5xx(서버 오류): 서버 쪽 문제로 응답하지 못했다는 뜻. 비율이 조금이라도 꾸준히 나타나면 서버 로그를 확인해야 한다.
• DNS를 찾을 수 없음: 도메인 설정 자체의 문제. 도메인 갱신을 놓쳤거나 네임서버 설정이 잘못됐을 때 나타난다.

나쁜 예는 오래전에 없앤 이벤트 페이지 수백 개로 여전히 내부 링크가 걸려 있어 404 비율이 15%를 넘는 경우다. 좋은 예는 페이지를 없앨 때 관련성 높은 페이지로 301 리다이렉트를 걸어 두고, 남은 내부 링크도 함께 수정해 404 비율을 1–2% 이내로 유지하는 경우다.

사이트 유형별로 "정상 범위"라고 볼 수 있는 대략적인 감(기준)도 함께 알아두면 판단이 쉬워진다. 아래 수치는 구글이 공식적으로 못박은 기준이 아니라, 여러 사이트를 다뤄본 실무 경험치에 가까운 참고값이다.

사이트 유형	200 비율 참고치	흔한 이슈
소규모 기업 홈페이지	약 95% 이상	페이지 수 자체가 적어 대체로 안정적
콘텐츠·블로그 사이트	약 90–95%	오래된 글의 태그·카테고리 URL이 404로 남는 경우
쇼핑몰(커머스)	약 85–92%	품절·단종 상품 URL이 삭제만 되고 리다이렉트가 안 걸리는 경우

쇼핑몰은 상품 등록·품절·재입고가 잦아 다른 유형보다 404 비율이 조금 높게 잡히는 경우가 흔하다. 다만 그렇다고 방치해도 된다는 뜻은 아니다. 품절 상품은 삭제 대신 "품절" 상태로 유지하거나, 진짜로 없앨 때는 유사 상품·카테고리 페이지로 리다이렉트를 걸어주는 것이 기본이다.

파일 형식별 분류는 왜 중요한가?

파일 형식별 분류는 구글봇이 가져간 리소스를 HTML, 이미지, JavaScript, CSS, PDF, 동영상, 기타 등으로 나눠 보여준다. 결론은 이렇다. HTML 문서 비중이 낮고 이미지·스크립트 같은 부속 리소스 비중이 지나치게 높다면, 정작 중요한 페이지 크롤링에 쓸 여력을 부속 파일이 잡아먹고 있다는 신호다.

예를 들어 상품 이미지가 각도별로 10장씩 걸려 있는 쇼핑몰 상세 페이지는 HTML 1건을 가져올 때 이미지 요청이 수십 건씩 따라붙는다. 이 자체는 자연스럽지만, 압축하지 않은 원본 이미지를 그대로 노출하고 있다면 다운로드 크기와 요청 횟수를 동시에 낭비하는 셈이다.

JavaScript 파일 비중이 유난히 높다면 사이트가 클라이언트 사이드 렌더링(브라우저에서 화면을 그리는 방식) 위주로 만들어졌을 가능성이 크다. 이 경우 구글봇은 HTML을 가져온 뒤 다시 스크립트를 실행해야 실제 콘텐츠를 볼 수 있어, 크롤링과 색인 사이의 시간차가 벌어지기 쉽다.

PDF나 XML 피드처럼 페이지가 아닌 파일 형식도 이 표에 함께 잡힌다. 예를 들어 카탈로그 PDF를 대량으로 올려놓은 사이트라면 PDF 비중이 눈에 띄게 늘어난다. 검색 노출에 실제로 도움이 되는 파일인지 먼저 따져보고, 그렇지 않다면 robots.txt로 해당 경로를 크롤링 대상에서 제외하는 것도 방법이다. 다만 robots.txt로 막은 파일은 이미 색인된 상태라도 검색 결과에서 곧바로 사라지지는 않으므로, 이미 노출 중인 파일을 급하게 없애야 한다면 noindex 태그나 정식 삭제 절차를 함께 검토해야 한다.

크롤링 목적별(검색·새로고침) 분류는 무엇을 말해주나?

이 표는 구글봇의 요청을 딱 두 가지로 나눈다.

• 검색(발견): 구글이 이전에 몰랐던 새로운 URL을 처음 방문하는 요청.
• 새로고침: 이미 알고 있는 URL을 다시 방문해 변경 사항이 있는지 확인하는 요청.

결론은 이렇다. 새로 만든 페이지가 많은 시기라면 "검색" 비중이 늘어야 정상이고, 안정기에 접어든 사이트라면 "새로고침" 비중이 높은 것이 자연스럽다. 둘 중 무엇이 더 좋다고 단정할 수 없고, 지금 내 사이트 상황과 맞는지가 기준이다.

새 블로그 글을 매일 발행하는데도 "검색" 비중이 낮고 "새로고침"만 반복된다면, 새 글이 구글에 제대로 알려지지 않고 있다는 신호일 수 있다. 이럴 때는 사이트맵이 최신 상태로 갱신되는지, 새 글에 내부 링크가 걸리고 있는지부터 점검한다.

Googlebot 유형별 분류는 왜 봐야 하나?

이 표는 어떤 종류의 구글봇이 방문했는지 보여준다. 대표적으로 스마트폰, 데스크톱, 이미지, 동영상, 페이지 리소스 로드(자바스크립트·CSS 등 부속 파일을 가져오는 전용 봇), AdsBot, StoreBot 등이 있다.

결론은 이렇다. 일반적인 콘텐츠 사이트라면 "스마트폰" 유형 비중이 압도적으로 높은 것이 정상이다. 구글은 오래전부터 모바일 퍼스트 인덱싱(모바일 화면 기준으로 콘텐츠를 평가하고 색인하는 방식)을 기본으로 쓰고 있기 때문이다. 데스크톱 봇 비중이 유난히 높다면 모바일 화면에서 콘텐츠가 제대로 노출되지 않고 있을 가능성을 의심해 봐야 한다.

페이지 리소스 로드 유형도 눈여겨볼 필요가 있다. 이 봇은 페이지를 제대로 렌더링하기 위해 자바스크립트·CSS·폰트 같은 부속 파일을 별도로 가져간다. 이 유형의 요청이 유난히 많다면, 사이트가 무거운 스크립트를 많이 쓰고 있어 구글봇이 화면 하나를 완성하는 데 그만큼 품을 들이고 있다는 뜻이다. AdsBot과 StoreBot은 각각 광고 품질 점검, 쇼핑 관련 정보 수집에 쓰이는 전용 봇으로, 광고를 집행하거나 구글 쇼핑에 상품을 노출하는 사이트가 아니라면 비중이 낮거나 아예 없는 것이 정상이다.

사이트 유형에 따라 정상 패턴이 다르다

앞서 응답 코드 비율에서 잠깐 다뤘듯, 크롤링 통계는 사이트 유형마다 "정상"으로 볼 수 있는 모양이 다르다. 결론은 이렇다. 다른 사이트, 심지어 업계 평균과 내 숫자를 직접 비교하기보다, 내 사이트의 과거 추이와 비교하는 것이 훨씬 정확한 진단법이다.

사이트 유형	요청 추이 특징	크롤링 목적 비중	눈여겨볼 파일 형식
기업·서비스 홈페이지	페이지 수가 적어 요청 수도 적고 변동이 완만하다	콘텐츠 변경이 적어 새로고침 비중이 높다	HTML 비중이 높고 안정적
블로그·미디어형 사이트	발행 주기에 맞춰 요청이 규칙적으로 오르내린다	새 글 발행 직후 검색(발견) 비중이 잠깐 튄다	이미지·HTML 비중이 고르게 분포
쇼핑몰(커머스)	세일·신상품 등록 시기에 요청이 크게 튄다	상품 회전이 빨라 검색·새로고침이 모두 활발하다	이미지·JSON(상품 데이터) 비중이 높다

기업 홈페이지처럼 페이지 수가 애초에 적은 사이트는 크롤링 요청 총량 자체가 적어도 걱정할 일이 아니다. 오히려 평소보다 갑자기 늘었다면 해킹으로 인한 스팸 페이지 생성, 잘못된 URL 파라미터 조합이 무한히 생성되는 구조적 오류를 의심해야 한다. 반대로 쇼핑몰은 세일 기간에 요청이 크게 튀는 것이 자연스러운 현상이므로, 이 시기의 급증만 보고 놀랄 필요는 없다.

크롤링 통계와 크롤 버짓, 어떻게 다른가?

둘을 같은 말로 쓰는 경우가 많은데, 정확히는 크롤링 통계는 "측정값"이고 크롤 버짓은 "그 측정값을 만드는 배경 개념" 이다.

크롤 버짓(크롤링 예산)이란 구글이 한 사이트에 할애하기로 정한 크롤링 총량을 뜻하는 개념이다. 크롤링 통계 보고서는 그 크롤 버짓이 실제로 어떻게 쓰였는지를 숫자로 보여주는 계기판이다. 자동차에 비유하면 크롤 버짓은 "이번 달 넣을 수 있는 연료의 양"이고, 크롤링 통계 보고서는 "실제로 어디에서 얼마나 연료를 썼는지 알려주는 계기판"에 가깝다.

크롤 버짓 자체의 개념, 즉 어떤 요소가 크롤 버짓을 늘리고 줄이는지, 대형 사이트가 아니어도 신경 써야 하는 이유는 이루웹 블로그의 크롤 버짓 완전 정리 글에서 따로 다뤘다. 이 글은 그 개념을 실제 화면에서 어떻게 확인하고 진단하는지에 집중한다.

2026년 8월, 실제로 있었던 데이터 누락 버그

크롤링 통계 보고서는 구글이 제공하는 공식 데이터이지만, 보고서 자체에 표시 오류가 생기는 경우도 있다. 최근 사례로 실전 감각을 익혀 보자.

2026년 8월 15일과 16일, 여러 SEO 실무자들이 크롤링 통계 보고서에서 해당 이틀치 데이터가 통째로 비거나 다른 날짜 데이터로 뒤바뀌어 표시되는 현상을 발견했다. 8월 20일에서 21일 사이 SNS와 커뮤니티에 신고가 이어졌고, "8월 15일 이후 데이터가 18일 데이터로 표시된다"는 구체적인 제보도 나왔다. 구글은 8월 23일경 이 표시 오류를 해결했다.

여기서 배울 점은 두 가지다.

• 이런 데이터 표시 오류는 처음이 아니다. 2021년 11월, 2022년 2월과 5월, 2025년 10월에도 비슷한 사례가 있었다. 일시적인 보고서 결함은 드물지 않게 발생한다.
• 실제 크롤링 활동 자체가 멈췄던 것은 아니고, 서치 콘솔 화면에 그 활동을 집계·표시하는 과정에서 문제가 생긴 것이었다.

특정 며칠의 크롤링 수치가 갑자기 0에 가깝게 뚝 떨어져 보인다면, 내 사이트 문제인지 서치 콘솔 자체의 일시적 표시 오류인지부터 구분해야 한다. 같은 기간 서버 로그(웹 서버가 실제 요청을 기록한 원본 데이터)를 함께 확인하면 가장 확실하다.

크롤링 요청이 갑자기 튀거나 꺼지면, 무엇부터 확인해야 하나?

결론부터 말하면, 순서를 정해두고 하나씩 지워나가는 방식이 가장 빠르다. 다음 다섯 단계를 위에서부터 따라가 보자.

1. 같은 기간 서버 로그를 대조한다. 서치 콘솔 수치만으로 판단하지 않는다. 실제 서버 접속 로그에도 같은 변화가 보이는지 먼저 확인한다.
2. 호스트 상태부터 본다. 빨간불이면 인프라 문제일 가능성이 크다. 초록불인데 요청 수만 튄다면 다음 단계로 넘어간다.
3. 응답 코드 분류를 연다. 4xx나 5xx 비율이 함께 늘었다면 특정 URL 그룹의 오류가 원인이다. 표에서 항목을 눌러 실제 URL 예시를 확인한다.
4. 최근 변경 사항을 되짚는다. 사이트 개편, 대량 상품 등록·삭제, 플러그인 업데이트, robots.txt 수정, CDN·호스팅 이전 시점과 겹치는지 대조한다.
5. 여전히 원인이 안 보이면 보고서 버그 가능성을 열어둔다. 위 네 단계에서 아무 이상도 못 찾았다면, 앞서 살펴본 사례처럼 서치 콘솔 쪽 표시 문제일 수 있다. 며칠 지켜본 뒤 다시 확인한다.

나쁜 예는 요청 수가 튄 것을 보자마자 "해킹당했나?"라며 급하게 사이트를 통째로 내리는 경우다. 좋은 예는 위 순서대로 서버 로그와 응답 코드부터 차분히 대조해, 실제로는 신상품 500개를 한꺼번에 등록해 "검색(발견)" 요청이 일시적으로 늘어난 정상적인 상황이었음을 확인하는 경우다.

실전 사례로 따라 읽어보기

지금까지 살펴본 지표를 실제 상황에 적용해 보면 이해가 훨씬 빨라진다. 가상의 인테리어 시공 업체 홈페이지를 예로 들어보자.

이 업체는 어느 달 첫째 주부터 크롤링 통계 보고서의 총 크롤링 요청 횟수가 평소보다 두 배 가까이 늘었다. 동시에 검색 노출은 오히려 줄어드는 느낌을 받았다. 아래 순서로 원인을 짚었다.

1. 응답별 분류를 먼저 열었다. 200 비율이 평소 96%에서 78%로 떨어져 있었고, 404 비율이 20%까지 튀어 있었다.
2. 404 항목을 눌러 URL 예시를 확인했다. 몇 달 전 종료한 이벤트 페이지(/event/2026-spring 계열) 수십 개가 목록에 그대로 있었다.
3. 원인을 되짚었다. 봄 시즌 이벤트가 끝나면서 담당자가 페이지를 삭제했지만, 메인 배너와 이전 블로그 글에 걸린 내부 링크는 그대로 남아 있었다는 사실을 확인했다.
4. 조치했다. 삭제된 이벤트 페이지에는 관련성 높은 현재 진행 중인 이벤트 페이지로 301 리다이렉트를 걸고, 배너와 블로그 글 속 링크도 함께 수정했다.
5. 2주 뒤 재확인했다. 404 비율이 3%대로 내려왔고, 총 크롤링 요청도 원래 수준으로 안정됐다. 이후 신규 페이지의 검색(발견) 요청 비중도 다시 늘어난 것을 확인했다.

이 사례처럼 문제는 대부분 한 가지 지표만 봐서는 원인이 안 보이고, 4개 분류표를 순서대로 열어 봐야 실마리가 나온다. 특히 응답별 분류에서 이상 수치를 발견했다면, 곧바로 해당 항목의 URL 예시 목록을 펼쳐 실제 페이지를 확인하는 습관이 진단 시간을 크게 줄여준다.

비슷한 원리는 반대 방향으로도 적용된다. 어떤 카페 체인 홈페이지는 지점을 새로 오픈할 때마다 지점 소개 페이지를 추가했는데, 크롤링 통계에서 검색(발견) 요청 비중이 거의 늘지 않는 것을 발견했다. 원인을 살펴보니 새 지점 페이지가 메인 화면이나 지점 목록 페이지에서 링크로 연결되지 않고, 담당자가 URL을 직접 아는 사람에게만 공유하는 방식으로 운영되고 있었다. 사이트맵에는 등록했지만 내부 링크가 전혀 없는 페이지는 구글이 상대적으로 덜 중요하다고 판단하는 경향이 있어, 지점 목록 페이지에 신규 지점 링크를 추가하자 이후 발견 요청이 눈에 띄게 늘었다. 이 두 사례 모두 결국 크롤링 통계 보고서 하나만 본 것이 아니라, 보고서에서 이상 신호를 잡고 실제 사이트 구조를 되짚어보는 과정이 핵심이었다.

발행 전 체크리스트

매달 한 번씩 크롤링 통계 보고서를 열 때, 아래 순서로 훑으면 5분 안에 이상 유무를 판단할 수 있다.

• 호스트 상태가 초록색인지 먼저 본다
• 총 크롤링 요청이 최근 몇 주 사이 급증하거나 급감하지 않았는지 그래프로 확인한다
• 5xx·DNS 오류 비율이 낮게 유지되는지 본다
• 크롤링 목적(검색 대 새로고침) 비중이 지금 사이트 상황과 맞는지 확인한다
• 파일 형식별로 불필요하게 무거운 리소스가 과도하게 크롤링되고 있지 않은지 본다
• Googlebot 유형이 스마트폰 위주로 잡히는지, 모바일 퍼스트 인덱싱과 어긋나지 않는지 확인한다
• 데이터가 비거나 이상해 보이면 서버 로그부터 대조하고, 원인이 안 보이면 보고서 자체 오류 가능성도 열어둔다

크롤링 통계 보고서를 정기적으로 챙겨보는 습관은 서치 콘솔 전체 활용법과 함께 익히면 더 효과적이다. 서치 콘솔의 다른 보고서들이 비슷한 이유로 일시적인 지연을 겪었던 인덱싱 리포트 지연 사례도 같은 맥락에서 참고할 만하다. robots.txt 설정 자체를 다시 점검하고 싶다면 AI 크롤러·robots.txt 설정 가이드도 함께 보길 권한다.

자주 묻는 질문

크롤링 통계 보고서에 데이터가 아예 안 보여요, 왜 그런가요?

사이트를 서치 콘솔에 등록한 지 얼마 안 됐거나 방문자·페이지 수가 적으면 데이터가 충분히 쌓이지 않아 비어 보일 수 있다. 등록 후 며칠에서 몇 주 정도 기다렸다가 다시 확인하는 것이 정상적인 대응이다.

크롤링 요청이 너무 적으면 문제인가요?

사이트 규모에 비해 지나치게 적다면 신규 페이지가 잘 발견되지 않고 있다는 신호일 수 있다. 사이트맵 최신화, 내부 링크 구조, robots.txt에서 중요한 경로를 실수로 막고 있지 않은지부터 확인한다.

5xx 오류가 몇 퍼센트까지는 괜찮은가요?

정해진 절대 기준은 없지만, 대체로 1–2% 이내면 정상 범위로 보고 그 이상이 꾸준히 나타나면 서버 성능이나 호스팅 환경을 점검하는 것이 안전하다. 일시적으로 튀었다가 곧 가라앉는 정도라면 서버 점검이나 배포 작업 중 발생한 일시적 현상일 수 있다.

호스트 상태가 빨간색인데 사이트는 정상적으로 잘 열려요, 왜 그런가요?

내가 브라우저로 접속했을 때 정상이어도, 구글봇이 요청을 보내는 시점이나 방식이 달라 문제가 감지될 수 있다. 트래픽이 몰리는 특정 시간대에만 서버가 느려지거나, 방화벽이 구글봇 요청을 오탐해 차단하는 경우가 대표적이다. 호스팅사 로그와 방화벽 설정을 함께 확인해야 한다.

크롤링 통계 보고서를 자주 확인하면 순위가 올라가나요?

이 보고서를 본다고 그 자체로 순위가 오르지는 않는다. 다만 크롤링 단계에서 막혀 있던 문제(느린 응답, 높은 오류 비율, 불필요한 리소스 낭비)를 찾아 고치면, 그동안 발견·색인조차 안 되던 페이지들이 정상적으로 검색에 노출되기 시작하면서 결과적으로 순위와 트래픽이 개선되는 경우가 많다. 순위를 직접 높이는 도구가 아니라, 순위 경쟁에 뛰어들 수 있는 최소 조건을 점검하는 도구로 이해하는 것이 정확하다.

새로 만든 사이트인데 크롤링 요청이 너무 몰려요, 서버에 부담이 되지 않나요?

신규 사이트나 대규모 개편 직후에는 구글이 전체 구조를 빠르게 파악하려고 짧은 기간 요청을 늘리는 경우가 있다. 대체로 자연스럽게 가라앉지만, 서버 응답 시간이 함께 느려지고 있다면 호스팅 사양을 점검할 신호로 받아들이는 것이 안전하다.

---

크롤링 통계 보고서는 한 번 읽는 법을 익히면 매달 5분이면 훑을 수 있는 화면입니다. 다만 호스트 상태 적신호나 오류 비율 상승의 원인을 실제로 찾아 고치는 일은 서버 환경, 사이트 구조, robots.txt·사이트맵 설정이 얽혀 있어 손이 많이 갑니다.

이루웹은 SEO 관점에서 사이트를 설계하고, 크롤링·색인 단계부터 막힘없이 흘러가도록 홈페이지 제작과 기술적 SEO 점검을 함께 도와드리고 있습니다. 크롤링 통계 보고서를 직접 열어봤는데 원인을 못 찾겠다면, 이루웹 SEO 서비스 페이지를 살펴보시거나 상담 문의로 편하게 연락 주시면 함께 진단해 드리겠습니다.