크롤 버짓은 Google이 한 사이트의 크롤링에 배정하는 시간과 자원의 규모입니다. 서버에 부담 없이 보낼 수 있는 요청량과 Google이 수집할 필요가 있다고 판단한 URL에 따라 크롤링 범위가 달라집니다. 사이트마다 고정된 일일 URL 할당량이 있는 것은 아닙니다.
새 글의 수집은 페이지를 발견하지 못했거나 서버가 정상 응답하지 못해서 늦어질 수도 있습니다. URL 수가 적은 사이트라면 크롤 버짓을 조정하려 하기 전에 내부 링크와 서버 오류부터 살펴야 합니다.
크롤 수용 한도와 크롤 수요
| 구성 요소 | 뜻 | 영향을 주는 조건 |
|---|---|---|
| 크롤 수용 한도 | 서버 과부하를 피하기 위해 제한하는 연결 수와 연결 유지 시간입니다. | 응답 속도, 5xx 오류나 429 응답, Google의 자원 한계 |
| 크롤 수요 | Google이 어떤 URL을 얼마나 자주 수집하려고 하는지 나타냅니다. | 파악한 URL 목록, 페이지 인기도, 변경 빈도, 콘텐츠 품질과 관련성 |
서버가 느려지거나 오류가 늘면 Google은 요청을 줄일 수 있습니다. 반대로 서버가 빨라도 다시 수집할 필요가 적다고 판단하면 방문을 크게 늘리지 않습니다.
Google은 이 예산을 호스트 이름별로 관리합니다. 예를 들어 www.example.com과 shop.example.com은 별도 사이트로 취급합니다. 같은 호스트를 방문하는 Google 크롤러들은 수요는 각각 다르지만 크롤 수용 한도는 공유합니다.
관리가 필요한 사이트의 규모와 상태
Google 가이드는 주로 다음 사이트를 대상으로 합니다.
- 고유 페이지가 100만 개 이상이며 콘텐츠가 주 단위로 바뀌는 사이트
- 고유 페이지가 1만 개 이상이며 콘텐츠가 매일 빠르게 바뀌는 사이트
- 전체 URL 중 Search Console의 “발견됨 – 현재 색인이 생성되지 않음” 상태가 큰 비중을 차지하는 사이트
이 숫자는 관리 대상을 가늠하는 대략적인 기준입니다. 작은 사이트에서 새 페이지가 발행 당일 정상적으로 크롤링된다면 사이트맵과 색인 상태를 관리하는 것으로 충분한 경우가 많습니다.
크롤링 효율을 떨어뜨리는 원인
비슷한 URL을 반복 수집하거나 오류 응답을 처리하는 데 자원을 쓰면 중요한 새 페이지의 수집이 늦어질 수 있습니다.
- 필터와 정렬 조합이 비슷한 URL을 끝없이 만듭니다.
- 같은 콘텐츠가 여러 주소에서 열립니다.
- 삭제된 페이지처럼 보이는데 200을 반환하는 소프트 404가 남아 있습니다.
- 여러 단계의 리디렉션을 거쳐야 최종 페이지에 도달합니다.
- 중요하지 않은 URL이 사이트맵과 내부 링크에 계속 노출됩니다.
- 서버 응답이 느리거나 5xx 오류가 자주 발생합니다.
불필요한 URL과 서버 응답 정비
- 검색에 제공할 중요 URL 목록을 정리합니다.
- 중복 콘텐츠는 대표 URL로 통합합니다.
- 대체 페이지 없이 영구 삭제한 URL은 404 또는 410으로 응답합니다.
- 소프트 404가 발생했다면 삭제한 페이지인지 정상 콘텐츠의 로딩이 실패한 것인지 구분해 응답 코드나 콘텐츠를 고칩니다.
- 사이트맵에는 중요 URL과 정확한
lastmod를 유지합니다. - 긴 리디렉션 체인은 최종 주소로 바로 연결합니다.
- 느린 서버 응답과 5xx 오류의 원인을 개선합니다.
사용자에게는 필요하지만 Google이 수집할 필요는 없는 정렬 URL 등은 통합 가능성을 먼저 검토하고, 통합하기 어렵다면 robots.txt로 크롤링을 제한할 수 있습니다. noindex는 Google이 페이지를 요청한 뒤 읽는 지시이므로 크롤 요청 자체를 줄이는 수단으로 쓰지 않습니다.
차단 이후의 효과 측정
Google이 이미 사이트의 크롤 수용 한도에 도달한 경우가 아니라면, 일부 URL을 막아도 남은 여력을 다른 페이지에 자동으로 배분하지 않습니다. 열 개를 막으면 다른 열 개를 더 방문하는 고정 할당 방식이 아닙니다. 다른 페이지를 잠시 더 수집하게 하려는 목적으로 차단을 반복하지 말고, 수집할 필요가 없는 URL을 정리해야 합니다.
필터 조합으로 수천 개 URL이 생긴 쇼핑몰이라면 서버 로그에서 Googlebot 요청 중 필터 URL의 비중을 계산합니다. Search Console 크롤링 통계에서는 전체 요청 추세와 응답 문제를 살핍니다. 수정 뒤에는 중요한 상품과 카테고리의 재수집 간격, 새 페이지가 처음 수집되기까지 걸린 시간과 색인 상태를 비교합니다. 전체 요청이 줄었더라도 중요한 페이지의 수집이 나아지지 않았다면 원인을 더 찾아야 합니다.
자주 묻는 질문
작은 블로그도 크롤 버짓을 관리해야 하나요?
URL 수가 적고 새 글이 빠르게 크롤링된다면 대개 별도 관리가 필요하지 않습니다. 수집이 늦다면 내부 링크와 사이트맵, 서버 오류부터 확인합니다.
사이트맵을 제출하면 크롤 버짓이 늘어나나요?
사이트맵은 URL과 변경 내용을 알리는 수단입니다. 새 URL을 발견하는 데 도움을 줄 수 있지만 제출만으로 크롤 수용 한도나 요청량이 늘어난다고 보장하지는 않습니다.
크롤링된 페이지는 모두 색인되나요?
아닙니다. Google은 가져온 페이지의 내용과 품질을 평가하고 중복 페이지를 통합합니다. 서버 로그에 수집 기록이 있더라도 색인됐다는 뜻은 아니므로 Search Console의 페이지 색인 상태를 별도로 확인해야 합니다.
함께 알아두면 좋은 용어
- 크롤링: 검색로봇이 URL을 발견하고 내용을 가져오는 과정
- 사이트맵: 검색엔진에 중요 URL과 변경 정보를 알려 주는 파일
- 소프트 404: 오류처럼 보이지만 정상 응답을 반환하는 페이지
- HTTP 상태 코드: 서버가 요청 처리 결과를 알리는 코드