크롤링 요청 횟수: 서버 로그의 총량이 좋은 신호가 아닌 이유

서버 로그를 열어보니 지난달보다 Googlebot 요청이 두 배로 늘었습니다. 개발팀은 크롤링이 활발해졌다고 보고하고, 마케팅팀은 색인과 노출이 따라 올라갈 것으로 기대합니다. 몇 주가 지나도 색인된 페이지 수는 그대로입니다.

크롤링 요청 횟수는 사이트가 검색엔진에게 얼마나 잘 읽히는지를 재는 지표가 아닙니다. 요청 한 건이 무엇을 가져갔는지, 어떤 응답을 받았는지, 그 URL이 애초에 검색 결과에 있어야 할 페이지였는지를 나누기 전까지 총량은 해석되지 않은 숫자입니다. 구글도 크롤링에 관한 오해 문서에서 크롤링은 페이지가 검색 결과에 오르기 위한 필요조건이지 순위 신호가 아니라고 명시합니다.

이 글은 서버 로그와 서치콘솔 크롤링 통계에서 요청 총량이 무엇으로 채워지는지 나누고, 총량이 늘었을 때 좋은 신호인 경우와 문제의 증상인 경우를 구분하는 기준을 정리합니다. 총량이 여전히 1차 신호로 쓸모 있는 예외도 마지막에 적었습니다.

요청 한 건은 페이지 한 장이 아니다#

로그의 한 줄은 URL 하나를 한 번 가져간 기록입니다. 사람이 세는 "페이지"와 단위가 다릅니다. 구글이 2026년 3월에 공개한 크롤링 인프라 설명에 따르면, HTML이 참조하는 리소스는 렌더링 서비스가 부모 HTML과 마찬가지로 Googlebot으로 가져가고 리소스마다 별도의 바이트 카운터를 갖습니다. 같은 글은 Googlebot이 URL 하나당 2MB까지 가져오며, PDF는 64MB, 한도를 따로 정하지 않은 크롤러는 15MB가 기본이라고 적습니다.

그래서 상세 페이지 한 장이 처리될 때 로그에는 이런 줄들이 남습니다.

GET /products/1024                200  text/html
GET /_next/static/chunk-a1b2.js   200  application/javascript
GET /_next/static/chunk-c3d4.js   200  application/javascript
GET /_next/static/main.css        200  text/css
GET /api/products/1024/reviews    200  application/json

콘텐츠는 한 건인데 요청은 다섯 건입니다. 이 배수는 렌더링 방식과 파일을 나누는 방식이 정합니다. 앞의 오해 문서도 CSS와 자바스크립트, XHR 요청처럼 페이지에 딸려 오는 파일이 크롤링 예산을 함께 쓴다고 적습니다. 빌드 구성을 바꿔 파일이 잘게 쪼개지면, 글을 한 편도 발행하지 않은 달에도 요청 총량은 늘어납니다.

서치콘솔 크롤링 통계 보고서가 요청을 파일 유형별로 나눠 보여주는 이유가 여기 있습니다. 이 보고서는 최근 90일 데이터를 응답, 파일 유형, 목적, Googlebot 유형 네 기준으로 분류합니다. 총량을 읽기 전에 HTML이 그중 몇 퍼센트인지부터 봐야 합니다.

로그의 Googlebot에는 검색 밖의 요청이 섞인다#

구글은 앞의 인프라 설명에서 "서버 로그에서 Googlebot을 본다면 그것은 구글 검색을 보고 있는 것"이라고 적었습니다. 쇼핑, 애드센스를 비롯한 여러 제품이 같은 크롤링 인프라를 쓰지만 각자 다른 크롤러 이름으로 요청합니다. 공통 크롤러 목록에서 성격이 다른 것만 골라도 이렇습니다.

Googlebot                검색, 이미지, 비디오, 뉴스, Discover
Googlebot-Image          이미지 검색과 Discover
Storebot-Google          쇼핑 관련 화면
Google-InspectionTool    리치 결과 테스트와 URL 검사
GoogleOther              여러 제품팀의 공개 콘텐츠 수집
Google-Extended          Gemini 모델 학습과 답변 근거 수집

색인과 무관한 요청이 총량에 섞여 있다는 뜻입니다. 사이트를 새로 배포한 뒤 URL 검사를 여러 번 돌린 날이나, 상품 피드가 갱신된 날의 증가분을 검색 크롤링의 증가로 읽으면 진단이 어긋납니다.

집계를 더 크게 흔드는 것은 위조입니다. 사용자 에이전트 문자열은 누구나 그대로 적어 보낼 수 있어서, 이 문자열만 보고 세면 긁어가는 봇들이 Googlebot 칸에 들어옵니다. 구글 크롤러 검증 문서는 역방향 조회와 정방향 조회를 함께 쓰라고 안내합니다.

$ host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

$ host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

접속 IP를 역방향 조회했을 때 도메인이 googlebot.com, google.com, googleusercontent.com 중 하나여야 하고, 그 호스트명을 다시 정방향 조회한 결과가 원래 IP와 같아야 합니다. 매번 조회하기 어렵다면 구글이 공개하는 IP 대역 목록 (https://www.gstatic.com/static/crawling/ipranges/)과 대조하는 방식으로 자동화할 수 있습니다.

총량이 늘었다면 세 가지로 나눠 봐야 한다#

검증을 마친 요청만 남겼다면, 그다음은 분해입니다. 크롤링 통계 보고서와 서버 로그에서 같이 볼 수 있는 축이 세 가지 있습니다. 요청의 목적이 첫 크롤링(discovery)인지 재수집(refresh)인지, 어떤 응답 코드를 받았는지, 어떤 URL 묶음을 향했는지입니다.

같은 "요청 두 배"가 정반대 진단으로 갈리는 지점이 여기입니다.

구성 A
  목적  첫 크롤링 비중이 뚜렷하게 늘었다
  대상  최근 발행한 상세 URL과 사이트맵에 있는 주소
  응답  대부분 200이고 HTML 비중이 유지된다
  읽기  새 콘텐츠가 발견되고 있다

구성 B
  목적  재수집이 대부분이다
  대상  필터와 정렬 매개변수가 붙은 목록 URL
  응답  301 리디렉션과 200으로 응답하는 빈 결과 페이지가 섞여 있다
  읽기  같은 콘텐츠를 다른 주소로 반복해서 가져가고 있다

구성 B에서 총량을 성과로 보고하면, 정리해야 할 문제가 개선의 근거로 뒤집힙니다. 분해 없이 총량만 추적하는 대시보드가 위험한 이유입니다.

크롤링이 늘어도 색인과 순위는 따라오지 않는다#

크롤링 예산 문서는 크롤링 예산(크롤 버짓)을 크롤링 용량 한도와 크롤링 수요의 조합으로 정의하면서, 구글 검색에서 크롤된 모든 페이지가 반드시 색인되지는 않는다고 적습니다. 크롤링은 색인 판정의 입구일 뿐이고, 그 뒤에는 중복 판정, 대표 URL 선택, 품질 평가가 남아 있습니다.

순위 쪽은 더 분명합니다. 오해 문서는 크롤링 속도를 개선한다고 검색 결과의 위치가 좋아지지는 않으며, 크롤링은 페이지가 검색 결과에 오르기 위해 필요하지만 순위 신호는 아니라고 적습니다.

두 서술을 합치면 요청 총량은 성과 지표가 될 수 없습니다. 크롤링은 색인 처리의 첫 단계이고, 유입이 나오지 않는 원인은 대개 그 뒤 단계에 있습니다. 페이지가 어느 단계에서 이탈했는지 판정하는 절차는 구글 색인 문제 진단에서 다뤘습니다.

총량이 문제의 증상인 경우#

요청이 늘어나는 흔한 원인 중 상당수는 사이트가 크롤러에게 같은 내용을 다른 주소로 계속 내주고 있다는 신호입니다.

가장 규모가 큰 것은 목록 페이지의 조합입니다. 패싯 내비게이션 문서는 필터 조합의 수가 곧 URL의 수가 된다고 설명하고, 쓸모없는 URL에 크롤링이 소비되면 새롭고 유용한 URL에 쓸 시간이 줄어든다고 적습니다. 필터 다섯 개에 각각 값이 몇 개씩만 있어도 목록 하나가 수천 개의 주소로 늘어납니다.

끝없이 이어지는 주소도 같은 구조입니다. 다음 달로 계속 넘어가는 달력, 번호가 끝없이 늘어나는 목록, 접속할 때마다 세션 값이 붙는 주소가 여기 해당합니다. 대표 호스트가 정리되지 않은 사이트는 같은 문서를 두 벌로 내주기도 합니다. 이 경우는 www non-www 리디렉션에서 다룬 대표 호스트 문제와 같은 지점에서 만납니다.

soft 404는 특히 조용히 누적됩니다. 화면에는 결과가 없다고 표시되는데 서버는 200을 반환하므로, 크롤러는 이 주소를 유효한 페이지로 보고 계속 다시 가져갑니다. 크롤링 예산 문서가 soft 404 제거와 긴 리디렉션 체인 회피를 권고하는 이유가 이것입니다.

여기서 과잉 교정을 막을 예외 두 가지를 함께 적어둡니다. 오해 문서는 429를 제외한 4xx 응답이 크롤링 예산을 낭비하지 않는다고 말합니다. 구글이 요청했고 상태 코드만 받았기 때문입니다. 404가 로그에 많다는 것은 예산 문제라기보다, 사이트맵과 내부 링크가 없는 주소를 계속 가리키고 있다는 별개의 신호로 읽어야 합니다. 또 하나, 같은 문서는 구글이 매개변수를 크롤링할 수 있다고 밝힙니다. 문제는 물음표가 붙은 주소 자체가 아니라, 같은 내용을 끝없이 다른 주소로 만들어내는 조합 규칙입니다.

요청이 몰리면 크롤링 용량은 스스로 내려간다#

크롤링 예산 문서에 따르면 크롤링 용량 한도는 사이트의 응답을 보고 자동으로 조정됩니다. 응답이 안정적이고 응답 시간이 유지되거나 개선되면 한도가 올라가고, 느려지거나 5xx 또는 429가 나오면 한도가 내려갑니다. 오해 문서도 5xx와 연결 타임아웃이 상당수 발생하면 크롤링이 느려진다고 적습니다.

그래서 높은 요청 총량은 그 자체로 다음 달 감소의 원인이 되기도 합니다. 크롤러가 무의미한 URL을 대량으로 훑는 동안 서버 응답 시간이 늘어나면, 정작 중요한 페이지의 재수집 빈도까지 같이 내려갑니다. 로그에서 먼저 볼 것은 요청 건수가 아니라 HTML 요청의 응답 시간 분포와 5xx 비율입니다.

조절 수단이 서버 응답뿐이라는 점도 알아둘 필요가 있습니다. 서치콘솔의 크롤링 속도 제한 도구는 2024년 1월 8일에 종료되었습니다. crawl-delay 규칙은 구글이 처리하지 않습니다. 크롤링이 서버를 위협하는 응급 상황의 대처는 크롤링 속도 줄이기 문서에 정리되어 있습니다.

크롤링 요청 횟수 대신 기록할 지표#

크롤링 요청 횟수 하나를 그래프로 두는 대신, 판정이 가능한 항목으로 바꿔 기록하는 편이 낫습니다. 아래는 검증된 Googlebot 요청만 남긴 로그를 전제로 합니다.

주 단위
  새로 발행한 URL이 처음 크롤될 때까지 걸린 시간
  첫 크롤링 요청이 향한 URL 중 사이트맵에 들어 있는 비율
  5xx와 429 응답 비율, HTML 요청의 응답 시간 분포

월 단위
  전체 요청 중 200으로 응답한 HTML의 비중
  요청이 가장 많은 URL 100개와 유입이 가장 많은 URL 100개의 겹침
  색인 대상 URL 중 최근 30일 안에 한 번 이상 크롤된 비율
  리디렉션이 두 번 이상 이어진 요청의 수

이 중 판정이 가장 빠르게 갈리는 것은 월 단위의 겹침 항목입니다. 크롤러가 시간을 가장 많이 쓴 주소와 사업 성과가 나오는 주소가 겹치지 않는다면, 총량이 얼마든 그 사이트의 크롤링은 목적을 벗어나 있습니다.

바뀌지 않은 페이지를 다시 요청받았을 때 304 (Not Modified)로 답하는 것도 크롤링 예산 문서의 권고 사항입니다. 다시 가져가는 주기는 그대로 두면서 주고받는 데이터와 서버 부담만 줄이는 방법입니다.

총량이 실제로 의미 있는 순간#

지금까지의 서술이 로그의 요청 수를 보지 말라는 뜻은 아닙니다. 총량이 1차 신호로 쓸모 있는 상황이 두 가지 있습니다.

첫째는 급락입니다. 요청이 갑자기 사라지면 구성보다 접근 자체를 의심해야 합니다. 크롤링 통계 보고서의 호스트 상태는 robots.txt 가져오기, DNS 확인, 서버 연결 세 가지를 점검합니다. robots.txt 요청이 유효한 파일도 404도 아닌 응답을 받으면 구글은 크롤링을 늦추거나 멈춥니다. 배포 사고나 인증서 만료가 이 형태로 나타납니다.

둘째는 예고된 변경과의 대조입니다. 사이트 이동, 대량 발행, robots.txt 차단 해제 뒤에는 요청이 늘어나는 것이 기대되는 결과입니다. 이때는 총량이 기대와 맞는지가 정보가 됩니다. 아무것도 바꾸지 않았는데 총량이 움직였을 때만 원인 조사가 필요하고, 그 조사는 다시 목적과 응답, 대상으로 나누는 데서 시작합니다.

로그에서 답을 얻으려면 질문을 바꿔야 한다#

크롤링 요청 횟수는 답이 아니라 질문입니다. 물어야 할 것은 "얼마나 많이 왔는가"가 아니라 "크롤러가 시간을 쓴 대상이 우리가 검색 결과에 두고 싶은 페이지와 얼마나 겹치는가"입니다. 이 질문으로 바꾸면 개선 작업의 방향도 달라집니다. 요청을 늘리는 일이 아니라 요청이 향하는 주소를 정리하는 일이 됩니다.

작업 순서는 대체로 같습니다. 로그에서 검증되지 않은 요청을 걷어내고, 남은 요청을 목적과 응답, 대상으로 나눠 기준값을 기록합니다. 그다음 총량을 부풀리는 구조를 찾아 정리하고, 정리 후 같은 기준으로 다시 수집해 비교합니다. 배포마다 이 설정이 유지되는지 확인하는 문제는 SEO 유지보수에서 다뤘습니다.

로그를 모으고 검증하는 절차가 아직 없다면, 사이트 전체 URL을 응답 코드와 canonical, 렌더 결과 기준으로 한 번 수집해 기준값을 만드는 작업이 먼저입니다.