크롤 버짓(crawl budget, 크롤링 예산)은 구글 같은 검색 엔진의 크롤러가 한 사이트에서 일정 기간 크롤링할 수 있고 크롤링하려는 URL의 양으로, 서버가 감당하는 용량 한도와 구글이 읽고 싶어하는 수요로 정해진다.
구글은 “Google이 단일 사이트를 크롤링하는 데 쓸 수 있는 시간과 리소스에는 제한이 있습니다. 이러한 리소스의 할당을 일반적으로 사이트의 크롤링 예산이라고 합니다”라고 정의한다 (Google 검색 센터, 크롤링 예산 최적화). 한국어 공식 문서의 표기는 “크롤링 예산”이고, 국내 SEO 업계에서는 “크롤 버짓”이 더 많이 쓰인다.
크롤링 용량 한도와 크롤링 수요, 두 요소다. 구글은 이 둘을 함께 고려해 “Google이 크롤링할 수 있고 크롤링하려는 URL 집합”을 그 사이트의 크롤 버짓으로 정의한다 (Google 검색 센터, 크롤링 예산 최적화).
| 요소 | 뜻 | 올리는 조건 | 내리는 조건 |
|---|---|---|---|
| 크롤링 용량 한도 (crawl capacity limit) | 서버에 과부하를 주지 않기 위해 구글이 계산하는 최대 동시 연결 수와 요청 사이 지연 시간 | 응답 시간이 안정적이거나 빨라짐 | 응답이 느려지거나 5xx 오류, 429 응답이 늘어남 |
| 크롤링 수요 (crawl demand) | 구글이 그 사이트를 얼마나 읽고 싶어하는지 | 인기 있는 URL, 자주 바뀌는 콘텐츠, 사이트 이동 같은 전체 이벤트 | 중복 URL, 삭제된 URL, 중요하지 않은 URL이 많은 인벤토리 |
용량 한도는 모든 사이트가 같은 보수적 기본값에서 출발하고, 서버가 정상이면 시간이 지나면서 자동으로 올라간다. 2017년 첫 공식 설명에서는 이 값을 “크롤 속도 한도(crawl rate limit)“라고 불렀는데, 개념은 같다 (Google Search Central Blog, What Crawl Budget Means for Googlebot, 2017-01-16).
수요가 낮으면 용량 한도에 닿지 않아도 크롤링이 준다. 서버가 아무리 빨라도 구글이 다시 읽을 이유가 없는 페이지는 자주 크롤링되지 않는다.
크롤 버짓은 호스트 이름 단위로 배정된다. 구글 문서는 www.example.com과 code.example.com을 별도 사이트로 취급해 크롤 버짓도 따로 준다고 설명하고, 구글봇과 AdsBot 같은 여러 크롤러가 수요는 따로 갖되 용량 한도는 공유한다고 밝힌다.
대부분은 아니다. 구글의 최적화 가이드가 대상으로 삼는 사이트는 “고유한 페이지 수가 1백만 개 이상이며 콘텐츠가 적당한 간격으로 변경됨(1주일에 한 번)” 또는 “고유한 페이지 수가 1만 개 이상이며 콘텐츠가 매우 빠르게 변경됨(매일)“인 곳, 그리고 서치콘솔에서 “발견됨 - 현재 색인이 생성되지 않음” URL이 상당 부분을 차지하는 곳이다 (Google 검색 센터, 크롤링 예산 최적화).
구글이 2017년에 처음 이 개념을 설명했을 때도 결론은 같았다.
“새 페이지가 게시된 당일에 크롤링되는 경향이 있다면 크롤 버짓은 신경 쓸 대상이 아니다. 마찬가지로 사이트의 URL이 수천 개 미만이면 대부분 효율적으로 크롤링된다” (Google Search Central Blog, What Crawl Budget Means for Googlebot, 2017-01-16).
서치콘솔의 크롤링 통계 보고서 도움말도 “사이트에 페이지 수가 1,000개 미만인 경우 이 보고서를 사용하지 않거나 이 정도 수준의 크롤링 세부정보는 신경 쓰지 않아도 됩니다”라고 적는다 (Google Search Console 고객센터, 크롤링 통계 보고서).
서치폴라리스 도메인이 그 예다. 2026년 9월 16일 기준 사이트맵 두 개에 실린 URL은 205개이고, 2026년 8월 16일부터 9월 15일까지 발행한 위키 문서 74편을 서치콘솔 URL 검사 API로 조회하니 발행 10일 이상 지난 65편 중 63편이 크롤링을 마쳤다. 크롤 버짓이 아니라 발행 직후의 발견 속도가 변수였는데, 이 수치는 아래 확인 방법 절에서 다시 다룬다.
가치가 낮은 URL을 대량으로 만들어 내는 사이트 구조에서 낭비된다. 구글은 2017년 분석에서 낭비를 일으키는 URL 유형을 영향이 큰 순서로 여섯 가지 제시했다 (Google Search Central Blog, What Crawl Budget Means for Googlebot, 2017-01-16).
9년이 지나도 1위는 바뀌지 않았다. 구글의 게리 일리스는 2025년 연말 크롤링 문제 보고를 근거로, 크롤링 문제의 50%가 패싯 내비게이션에서, 25%가 장바구니 담기 같은 동작 파라미터에서, 10%가 세션 ID와 UTM 같은 무의미한 파라미터에서, 5%가 플러그인과 위젯에서 나온다고 밝혔다 (Search Engine Land, Google: 75% of crawling issues come from two common URL mistakes, 2026-02-03).
구글 공식 블로그도 패싯 내비게이션을 “사이트 소유자가 우리에게 보고하는 과다 크롤링 문제의 단연 가장 흔한 원인”으로 지목하며, 필터 조합 하나하나가 새 URL을 만들어 사실상 무한한 URL 공간이 생긴다고 설명한다 (Google Search Central Blog, Crawling December: Faceted navigation, 2024-12-17).
HTML 페이지만 크롤 버짓을 쓰는 것이 아니다. 페이지를 렌더링하는 데 필요한 자바스크립트와 CSS도 그 리소스를 호스팅하는 호스트의 크롤 버짓을 깎는다.
구글의 렌더링 서비스(WRS)는 이런 리소스를 HTTP 캐시 지시와 무관하게 최대 30일 캐시해 크롤 버짓을 아끼므로, 캐시를 무효화하는 파라미터를 리소스 URL에 자주 바꿔 붙이면 그만큼 다시 크롤링된다 (Google Search Central Blog, Crawling December: Page resources, 2024-12).
한 URL에서 가져오는 양에도 한도가 있다. 구글봇은 URL 하나당 HTTP 헤더를 포함해 처음 2MB까지만 가져오고(PDF는 64MB), 그 뒤 바이트는 렌더링도 색인도 되지 않는다 (Google Search Central Blog, Inside Googlebot: demystifying crawling, fetching, and the bytes we process, 2026-03-31).
버짓을 더 받는 것이 아니라 낭비를 없애는 것이 최적화의 대부분이다. 구글 문서의 권장사항을 문제 유형별로 정리하면 다음과 같다 (Google 검색 센터, 크롤링 예산 최적화).
| 문제 | 처방 | 이유 |
|---|---|---|
| 같은 콘텐츠가 여러 URL로 열림 | 캐노니컬 태그와 리디렉션으로 중복 통합 | 고유한 URL이 아니라 고유한 콘텐츠에 크롤링을 집중 |
| 필터, 정렬, 무한 스크롤 페이지 | robots.txt로 크롤링 차단 | 차단된 URL은 크롤링 자체가 일어나지 않음 |
| 영구 삭제된 페이지 | 404 또는 410 반환 | 404는 “다시 크롤링하지 말라는 강력한 신호” |
| 빈 페이지가 200을 반환 | 소프트 404 제거 | 소프트 404 페이지는 계속 크롤링되며 예산을 낭비 |
| 구글이 새 페이지를 늦게 발견 | 사이트맵을 최신으로 유지하고 lastmod 기록 | 구글이 사이트맵을 정기적으로 읽음 |
| 여러 단계 리디렉션 | 301 리디렉션 체인 제거 | 체인의 요청 하나하나가 별도 크롤링으로 집계 |
| 서버 응답이 느림 | 응답 시간 단축, 304 Not Modified 지원 | 빠른 서버는 용량 한도를 올리고, 304는 캐시 재사용으로 대역폭 절약 |
주의할 점이 둘 있다. 하나는 크롤링을 막으려고 noindex를 쓰지 않는 것이다. 구글은 noindex가 붙은 페이지도 계속 요청한 뒤에야 버리므로 크롤링 시간이 그대로 낭비된다.
다른 하나는 robots.txt로 어떤 페이지를 차단해도 그 예산이 다른 페이지로 옮겨 가지 않는다. 구글 문서는 이미 용량 한도에 도달한 경우가 아니면 “새로 제공된 이 크롤링 예산을 다른 페이지로 이전하지 않습니다”라고 명시한다.
버짓 자체를 늘리는 길은 둘뿐이다. 서버 용량 부족이 원인이면 서버 리소스를 추가하고, 그렇지 않으면 인기도와 콘텐츠 고유성 같은 품질 요소를 올린다. 구글은 이 두 가지 외의 방법을 문서에 두지 않았다.
구글 서치콘솔의 크롤링 통계 보고서다. 설정 메뉴 안에 있고, 총 크롤링 요청 횟수, 총 다운로드 크기, 평균 응답 시간, 호스트 상태, 응답 코드별, 파일 형식별, 크롤링 목적별, 구글봇 유형별 데이터를 90일 범위로 보여 준다 (Google Search Console 고객센터, 크롤링 통계 보고서).
도메인 속성이나 루트 수준 URL 접두어 속성에서만 열린다.
페이지 단위로는 URL 검사 도구가 마지막 크롤링 시각과 색인 상태를 알려 준다. 페이지 색인 보고서의 “발견됨 - 현재 색인이 생성되지 않음” 항목이 늘어나면 구글이 URL을 알면서도 크롤링을 미루고 있다는 뜻이라, 구글이 크롤 버짓 관리 대상의 세 번째 기준으로 이 항목을 든다.
2026년 9월 16일 서치폴라리스 위키 문서 74편을 URL 검사 API로 확인한 결과다. 발행 경과 시간에 따라 상태가 갈렸다.
| 발행 시점 | 편수 | 크롤링 완료 | 구글이 아직 모르는 URL |
|---|---|---|---|
| 발행 10일 이상 (8월 16일부터 9월 5일) | 65 | 63 | 1 (나머지 1편은 발견됐지만 미크롤링) |
| 발행 3일 이내 (9월 13일부터 15일) | 9 | 3 | 6 |
페이지 205개짜리 사이트에서 크롤 버짓이 모자라 크롤링이 안 된 흔적은 없었다. 다만 새 문서가 구글에 알려지기까지 며칠이 걸렸고, 이 지연은 버짓이 아니라 발견 경로(사이트맵, 내부 링크, 색인 요청)의 문제다. 구글이 “게시 당일에 크롤링되면 신경 쓸 필요 없다”고 말한 기준을 스스로 확인해 보는 가장 빠른 방법이 이 조회다.
페이지 수가 많고 자주 바뀌는 사이트다. 구글 기준으로는 고유 페이지 100만 개 이상, 또는 매일 콘텐츠가 바뀌는 1만 페이지 이상 사이트이고, 실제로는 필터 조합으로 URL이 무한히 생기는 이커머스, 분류 광고, 부동산, 채용 사이트가 대부분을 차지한다.
크롤 버짓을 숫자 하나로 보여 주는 도구는 없다. 구글이 실제로 얼마나 요청했는지는 서치콘솔 크롤링 통계 보고서와 서버 로그가 1차 소스이고, Screaming Frog나 Botify 같은 크롤러는 구글이 아니라 내 사이트의 URL 구조에서 낭비 후보(중복, 파라미터, 리디렉션 체인)를 찾는 용도다.
robots.txt다. 구글 문서는 크롤 버짓 목적으로 noindex를 쓰지 말라고 명시한다. noindex는 페이지를 가져와 태그를 읽은 뒤에야 버리므로 크롤링은 그대로 일어나고, robots.txt 차단은 요청 자체를 막는다.
단 색인에서 확실히 빼야 하는 페이지라면 목적이 다르므로 noindex가 맞다.
구글의 크롤 버짓은 구글 크롤러들의 몫이라 AI 크롤러가 직접 깎지는 않는다. 다만 크롤링 용량 한도는 서버 응답 속도로 정해지므로, AI 크롤러 트래픽이 서버를 느리게 만들면 구글봇의 용량 한도도 내려간다. 서버 로그에서 봇별 요청량을 보고 robots.txt로 허용 범위를 정하는 것이 관리의 시작이다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.