크롤 예산

TL;DR — 크롤 예산은 검색엔진이 사이트를 크롤링하려는 양입니다. 서버가 감당할 수 있는 양과 Google이 크롤링하기를 원하는 양을 함께 고려합니다. 더 많이 크롤링된다고 순위가 오르지는 않으며 대부분의 사이트에는 문제가 되지 않습니다. 페이지가 게시 당일 크롤링된다면 크롤 예산 문제는 없습니다.

크롤 예산이란?

검색엔진은 사이트를 끝없이 크롤링하지 않습니다. 일정 시간 동안 일부 URL을 크롤링한 뒤 다른 곳으로 이동합니다. SEO 업계에서는 이 양을 크롤 예산이라고 부릅니다.

검색엔진이 계속 답하는 두 질문으로 요약할 수 있습니다.

• 얼마나 크롤링할 수 있는가? 서버는 어느 수준을 넘으면 느려지거나 오류를 냅니다. Google은 이를 감지해 속도를 줄입니다. 이것이 크롤 용량이며 이전 문서에서는 크롤 속도 제한이라고 불렀습니다.
• 얼마나 크롤링하고 싶은가? 인기 페이지와 자주 바뀌는 페이지는 더 자주 크롤링됩니다. 링크가 없거나 전혀 바뀌지 않는 페이지는 드물게 크롤링됩니다. 이것이 크롤 수요입니다.

두 요소를 결합하면 크롤 예산, 즉 Google이 크롤링할 수 있고 하려는 URL 수가 됩니다. Evidence for this claim Google defines crawl budget using crawl capacity limit and crawl demand. Scope: Google Search crawling for larger sites. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

초기에 구분할 점이 있습니다. 크롤 예산은 Google이 URL을 가져오는지에 관한 것입니다. 가져온 내용을 색인하는지는 별도의 후속 결정입니다. 페이지는 크롤링되고도 색인되지 않을 수 있습니다. 크롤링은 색인을 보장하지 않고 먼저 통과해야 할 관문일 뿐입니다.

먼저 알아둘 점: 아마 걱정할 필요가 없습니다

많은 글이 숨기는 부분입니다. 대부분의 사이트에는 크롤 예산 문제가 없습니다. Google도 직접 말합니다. 페이지가 게시 당일 크롤링되거나 사이트가 매우 크고 빠르게 변하지 않는다면 이 주제 전체를 건너뛰어도 됩니다. Evidence for this claim Google says sites without many rapidly changing pages, or whose pages are crawled the day they publish, generally do not need crawl-budget guidance. Scope: Google's rough applicability guidance, not a guarantee for every site. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

간단히 확인하려면 Google에서 URL 몇 개를 검색하거나 Search Console의 URL 검사 도구를 사용하세요. 새 페이지가 하루나 이틀 안에 나타난다면 크롤 예산은 충분합니다. 대신 콘텐츠와 링크에 시간을 쓰세요.

크롤 예산은 사이트에 수십만 또는 수백만 개의 페이지가 있고 그중 많은 페이지가 계속 바뀔 때 중요해지기 시작합니다. 대형 전자상거래나 뉴스 사이트가 대표적입니다.

크롤링이 많다고 순위가 좋아지지 않습니다

초기에 없애야 할 오해가 있습니다. 페이지를 더 자주 크롤링한다고 검색 결과에서 올라가지 않습니다. 크롤링은 검색엔진이 페이지를 찾고 다운로드하는 과정일 뿐입니다. 순위를 얻으려면 통과해야 하지만, 그 뒤 재크롤링 빈도는 순위 요소가 아닙니다.

따라서 목표는 “더 많이 크롤링되기”가 아닙니다. 중요한 페이지가 크롤링되고 검색엔진이 가치 없는 URL에 시간을 낭비하지 않도록 하는 것입니다.

크롤 예산을 낭비하는 요소

대형 사이트에서는 다음 요소가 예산을 소모합니다.

• 필터·정렬 URL(패싯 탐색) — 전자상거래의 필터 조합마다 거의 같은 URL 수천 개가 생길 수 있습니다.
• 중복 페이지 — 같은 콘텐츠가 www 유무나 추가 매개변수 등 여러 URL에서 열립니다.
• 소프트 404s — “찾을 수 없음” 페이지가 200 OK 상태를 반환해 검색엔진이 계속 크롤링합니다.
• 끊어진 리디렉션 체인과 느린 페이지 — 각 크롤링 비용을 높입니다.

해결책은 거의 항상 Google에 “더 많이” 크롤링하라고 설득하는 것이 아니라 낭비를 없애 실제 페이지에 예산이 쓰이게 하는 것입니다.

크롤 용량과 수요의 전체 모델, 정확한 규모 기준, 패싯 탐색 대응, Bing의 차이, 측정 방법까지 보려면 고급 탭으로 전환하세요.

TL;DR — 크롤 예산 = 크롤 용량 제한(서버가 감당하는 양) × 크롤 수요(인기도 + 오래됨 + 인지된 인벤토리)입니다. 순위 신호가 아니라 효율성 문제입니다. 내부적으로는 사이트별 고정 할당량이 아니라 호스트 부하를 상한으로 둔 중요도 기반 스케줄링입니다. 대부분의 사이트는 무시해도 됩니다. Mueller는 100k URL은 “usually not enough”이라고 했고 Google은 게시 당일 크롤링되는 사이트에 가이드를 건너뛰라고 합니다. 약 1M+ 페이지가 매주 바뀌거나 10k+ 페이지가 매일 바뀌거나 “발견됨 - 현재 색인이 생성되지 않음” URL이 크게 늘 때 문제가 됩니다. 가장 효과적인 조치는 패싯 탐색, 중복, 소프트 404s, 무한 공간 같은 낭비를 줄여 중요한 URL에 예산을 집중하는 것입니다.

두 요소 모델

Google의 정의는 명확합니다. “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (번역) Google이 사이트 크롤링에 들이는 시간과 자원을 크롤 예산이라고 하며 크롤 용량 제한과 크롤 수요라는 두 요소로 결정됩니다. Gary Illyes가 2017년에 제시한 한 줄 정의도 유용합니다. 크롤 예산은 “the number of URLs Googlebot can and wants to crawl.” (번역) Googlebot이 크롤링할 수 있고 하려는 URL 수입니다. Evidence for this claim Google defines crawl budget using crawl capacity limit and crawl demand. Scope: Google Search crawling for larger sites. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide 범위를 지키세요. 크롤 예산은 가져오기를 통제하지 색인을 통제하지 않습니다. 크롤링된 URL도 별도 색인 결정을 거칩니다. 둘을 합치면 크롤 예산의 영향력을 과장하게 됩니다.

크롤 용량 제한(공급 측면). 이는 “the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (번역) Google이 사이트 크롤링에 사용할 수 있는 최대 동시 병렬 연결 수와 가져오기 사이의 시간 지연입니다. 서버 상태에 따라 움직입니다. 빠르고 정상적으로 응답하면 한도가 올라가고, 느린 응답이나 5xx, 429 오류가 나오면 Googlebot이 물러납니다. 제 How Search Works 발표 자료도 서버 안정성, 느린 응답, 5xx 서버 오류, 429(요청 과다)를 속도 제한 원인으로 나열합니다. 이것이 “가능” 측면입니다.

크롤 수요(수요 측면). 인기도(URL에 연결된 링크와 중요도)와 오래됨(마지막 크롤 이후 시간과 변경 빈도)의 영향을 받습니다. 같은 발표 자료는 PageRank, 페이지 변경 빈도, 마지막 크롤 이후 시간, 대규모 사이트 변경으로 수요를 나눕니다. 특히 Google은 인지된 인벤토리를 가장 잘 통제할 수 있는 요소로 꼽습니다. “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason… this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (번역) 별도 안내가 없으면 Google은 알려진 URL 대부분을 크롤링하려 합니다. 중복되거나 원치 않는 URL이 많으면 크롤링 시간을 낭비하며, 이것이 가장 적극적으로 통제할 수 있는 요소입니다.

사람들이 놓치기 쉬운 구조적 사실도 있습니다.

• 예산은 호스트 이름별입니다. “https://www.example.com/ and https://code.example.com/ are two different hostnames, and therefore have separate crawl budgets.” (번역) 두 주소는 서로 다른 호스트 이름이므로 별도 크롤 예산을 가집니다. 서브도메인은 공유하지 않습니다.
• 서로 다른 Googlebot 유형은 하나의 풀을 사용할 가능성이 큽니다. 제 조사에서는 이미지, 뉴스, 동영상, 광고 등이 같은 사이트별 예산을 쓰는 것으로 보입니다. 이를 정확히 확정하는 최신 Google 1차 출처는 없으므로 문서화된 정책이 아닌 실무자 관찰로 취급하세요. 한 유형이 다른 유형을 밀어낸다고 의심되면 Crawl Stats 보고서의 크롤러 유형별 내역을 확인할 가치가 있습니다.

내부에서 실제로 일어나는 일: 중요도 기반 스케줄링

“크롤 예산”은 SEO 업계가 만든 포괄 용어입니다. 내부적으로는 호스트 부하가 제한하는 스케줄링에 가깝습니다. Illyes의 설명에 따르면 Google 스케줄러는 “sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (번역) 호스트 부하가 URL을 중요도순 버킷에 놓고 Googlebot은 그 일정에 따라 크롤링합니다. 서버가 감당할 수 있다고 보면 전체 버킷을 크롤링하고 아니면 멈춥니다.

이 설명은 주제를 다르게 보게 합니다. 하루에 N개라는 고정 할당량이 아니라 우선순위 큐이며 크롤링은 검색 수요를 따릅니다. Illyes는 “If search demand goes down, then that also correlates to the crawl limit going down,” (번역) 검색 수요가 줄면 크롤 한도도 줄어든다고 했습니다. 또 “if you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” (번역) 더 많이 크롤링되길 원한다면 검색 시스템에 콘텐츠를 가져올 가치가 있다고 설득해야 하며 스케줄러가 바로 그것을 듣는다고 설명했습니다. Search Relations 팀은 “고정된 일일 페이지 할당량”을 명시적으로 오해라고 했습니다.

사이트에 정말 크롤 예산 문제가 있나요?

가장 중요한 부분이므로 단도직입적으로 말하겠습니다. 대부분의 사이트는 크롤 예산을 걱정할 필요가 없습니다. Google 가이드도 이렇게 시작합니다. “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide. For Google Search specifically, merely keeping your sitemap up to date and checking your index coverage regularly is adequate.” (번역) 빠르게 변하는 페이지가 아주 많지 않거나 게시 당일 크롤링된다면 이 가이드를 읽을 필요가 없습니다. Google 검색에서는 사이트맵을 최신으로 유지하고 색인 범위를 정기 확인하는 것으로 충분합니다. Evidence for this claim Google says sites without many rapidly changing pages, or whose pages are crawled the day they publish, generally do not need crawl-budget guidance. Scope: Google's rough applicability guidance, not a guarantee for every site. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

John Mueller는 구체적인 수치를 제시했습니다. “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (번역) 100k URL은 보통 크롤 예산에 영향을 줄 만큼 많지 않으며 3개월 동안 분당 1개 미만입니다. URL이 여섯 자리 수보다 적고 페이지가 빠르게 크롤링된다면 다른 문제로 넘어가세요.

문제가 되는 경우 Google의 대략적인 기준은 다음과 같습니다.

• 대형 사이트 — 약 매주처럼 중간 정도로 자주 바뀌는 고유 페이지 1 million+개.
• 중형 이상 사이트 — 매일처럼 매우 빠르게 바뀌는 고유 페이지 10 000+개.
• Search Console에서 URL의 상당 부분이 **“발견됨 - 현재 색인이 생성되지 않음”**으로 분류된 사이트 — Google이 URL을 알지만 가져오지 못한다는 경고등입니다.

Google은 “the numbers given here are a rough estimate… not exact thresholds.” (번역) 제시된 수치는 대략적인 추정이며 정확한 기준값이 아니라고 덧붙입니다. 큰 사이트에서도 제 경험상 지연되는 것은 보통 새 페이지, 내부 링크가 약한 페이지, 정적 페이지이지 인기 페이지가 아닙니다.

크롤 예산은 순위에 영향을 주나요? 아니요.

크롤링은 순위에 필요하지만 순위 신호는 아닙니다. Google은 2017년에 “An increased crawl rate will not necessarily lead to better positions in Search results. Google uses hundreds of signals to rank the results, and while crawling is necessary for being in the results, it’s not a ranking signal.” (번역) 크롤 속도가 높아져도 검색 순위가 좋아지는 것은 아니며 Google은 수백 가지 신호를 사용하고 크롤링은 검색 결과에 필요하지만 순위 신호는 아니라고 했습니다. 제 Ahrefs 가이드도 “More crawling doesn’t mean you’ll rank better, but if your pages aren’t crawled and indexed they aren’t going to rank at all.” (번역) 더 많이 크롤링된다고 순위가 좋아지지는 않지만 크롤링·색인되지 않으면 아예 순위를 얻을 수 없다고 설명합니다. 크롤 예산은 오직 효율성 문제로 다루세요.

크롤 예산을 낭비하는 요소

Illyes가 “in order of significance”로 발표한 저가치 URL 목록은 다음과 같습니다.

1. 패싯 탐색과 세션 식별자 — #1 원인입니다. 특히 전자상거래 필터·정렬 조합이 URL을 조합 폭발시킵니다.
2. 사이트 내 중복 콘텐츠 — HTTP/HTTPS, non-www/www, 슬래시 유무, 대소문자, 기본/index 페이지, URL 매개변수 같은 기술 변형입니다. Google 내부 추정으로 웹의 약 60%가 중복 콘텐츠입니다.
3. 소프트 오류 페이지 — 200을 반환하는 소프트 404s는 계속 크롤링됩니다.
4. 해킹된 페이지.
5. 무한 공간과 프록시 — 달력, 중복을 만드는 무한 스크롤 페이지네이션, 패싯 조합 같은 스파이더 트랩입니다.
6. 저품질·스팸 콘텐츠.

비용은 구체적입니다. “Wasting server resources on pages like these will drain crawl activity from pages that do actually have value, which may cause a significant delay in discovering great content on a site.” (번역) 이런 페이지에 서버 자원을 낭비하면 실제 가치 있는 페이지의 크롤 활동이 줄어 좋은 콘텐츠 발견이 크게 지연될 수 있습니다. 또한 긴 리디렉션 체인은 크롤링에 부정적인 영향을 주며 느리고 무거운 페이지는 모든 가져오기 비용을 높입니다.

최적화 방법

전체 목표는 중요한 URL에 예산을 집중하는 것입니다.

• 중복을 통합하세요. Google은 “Consolidate duplicate content to focus crawling on unique content rather than unique URLs.” (번역) 고유 URL이 아니라 고유 콘텐츠 크롤링에 집중하도록 중복 콘텐츠를 통합하라고 합니다. 호스트, 프로토콜, 끝 슬래시 규칙을 하나씩 정하고 캐노니컬과 매개변수를 처리하세요.
• 정말 가치 없는 경로는 robots.txt로 차단하세요. 절대 크롤링할 필요가 없는 경로만 대상입니다. 패싯 탐색은 보통 매개변수 경로를 robots.txt에서 막거나 ? 대신 # 뒤에 배치해 처음부터 크롤링할 수 없게 합니다.
• 예산 절약에 noindex를 쓰지 마세요. Google은 “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (번역) 먼저 요청하고 noindex를 본 뒤 버리므로 크롤링 시간을 낭비한다고 합니다. 가져오기를 원치 않으면 robots.txt에서 차단하세요.
• robots.txt가 예산을 재배분한다고 기대하지 마세요. “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s serving limit.” (번역) Google이 이미 사이트의 제공 한도에 도달하지 않았다면 새로 남은 예산을 다른 페이지로 옮기지 않습니다. 가치 없는 URL 차단은 좋은 위생이지만 용량 한도에 걸린 상태가 아니라면 좋은 페이지에 크롤이 자동 배분되지 않습니다.
• 소프트 404s를 고치고 사라진 페이지에는 실제 404/410을 반환하세요. “A 404 status code is a strong signal not to crawl that URL again.” (번역) 404 상태 코드는 해당 URL을 다시 크롤링하지 말라는 강한 신호입니다.
• 리디렉션 체인을 줄이고 사이트맵을 정확한 lastmod로 최신 유지하며 서버 속도를 개선하세요.
• 중요하거나 새로 만든 페이지의 내부 링크를 강화하세요. 완전히 통제할 수 있어 가장 쉽습니다.

Google이 말하는 예산을 실제로 늘리는 방법은 단 두 가지입니다. “Add more server resources… [and] optimize your content’s quality.” (번역) 서버 자원을 더하고 콘텐츠 품질을 최적화하세요. 함정은 빠른 서버가 용량 상한만 높인다는 점입니다. 수요가 낮으면 Google은 여전히 덜 크롤링하므로 둘 다 필요합니다.

측정 방법

• GSC > 설정 > Crawl Stats 보고서 — 시간별 총 크롤 요청, 평균 응답 시간, 호스트 상태, 응답 코드·파일 유형·Googlebot 유형별 내역. Google이 사이트를 크롤링하는 방식을 보여 주는 자체 데이터입니다.
• 서버 로그 파일 분석 — 실제 근거입니다. URL 패턴별 실제 Googlebot 요청으로 낭비와 크롤링되지 않은 중요 페이지를 확인합니다. 역방향·정방향 DNS 또는 Google 공개 IP 범위로 진짜 Googlebot인지 검증하세요. 사용자 에이전트를 위조하는 가짜 봇이 많습니다.
• GSC의 “발견됨 - 현재 색인이 생성되지 않음” — 이 URL 묶음이 커지면 크롤 예산 경고등으로 보세요. Google은 URL을 알지만 가져오지 못하고 있습니다.

Bing과 다른 검색엔진: “크롤 효율성”

Bing은 이 주제를 예산이 아닌 크롤 효율성으로 설명합니다. Fabrice Canel의 정의는 “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (번역) 크롤링한 페이지당 새롭고 신선한 콘텐츠를 얼마나 자주 크롤링하고 발견하는가입니다. 목표는 “crawl an URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).” (번역) 콘텐츠가 추가되거나 업데이트됐을 때만 URL을 크롤링하는 것입니다. Bing은 “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (번역) SEO에서는 적을수록 좋으며 크롤링할 URL이 적을수록 좋다고 단언합니다.

Bing이 선호하는 해결책은 변경된 URL을 전송해 bingbot의 탐색 크롤을 줄이는 IndexNow와, 시간대별 bingbot 일정을 설정해 서버 부하를 보호하는 Bing Webmaster Tools의 Crawl Control입니다. Google은 Search Console의 예전 크롤 속도 제한 기능을 폐기했지만 Bing은 여전히 일정을 직접 조정할 수 있다는 중요한 차이가 있습니다.

크롤 예산 오해 바로잡기

• “모든 사이트가 크롤 예산을 최적화해야 한다.” 아닙니다. 대부분은 할 필요가 없습니다. 게시 당일 크롤링되고 URL이 100k 미만이면 괜찮습니다.
• “크롤링 증가 = 순위 상승.” 아닙니다. 크롤링은 필요하지만 순위 신호가 아닙니다.
• “고정된 일일 페이지 할당량이다.” 아닙니다. 호스트 부하가 제한하는 중요도 기반 스케줄링입니다.
• “예산 절약에 noindex를 사용한다.” 아닙니다. Google은 먼저 페이지를 요청합니다.
• “robots.txt에서 페이지를 막으면 다른 페이지에 예산이 간다.” 이미 제공 한도에 도달한 경우가 아니면 일반적으로 아닙니다.
• “서버만 빨라지면 예산이 늘어난다.” 용량 상한만 높습니다. 수요가 낮으면 크롤링은 여전히 적습니다.

이 주제가 속한 더 넓은 파이프라인, 즉 발견, 크롤 스케줄러, 렌더링, 크롤링과 색인의 차이는 크롤링 허브에서 확인하세요. 크롤 속도, 크롤 빈도, 스파이더 트랩, 로그 파일 분석 글은 각각 한 부분을 더 깊게 다룹니다.

AI 요약

고급 버전의 핵심을 압축하면 다음과 같습니다.

• 크롤 예산 = 크롤 용량 제한 × 크롤 수요. 용량은 서버가 감당할 수 있는 양으로 빠르고 정상적인 응답에서는 올라가고 5xx/429에서는 내려갑니다. 수요는 인기도 + 오래됨 + 인지된 인벤토리입니다. Google의 한 줄 정의는 Googlebot이 크롤링할 수 있고 하려는 URL 수입니다.
• 순위 요소가 아닙니다. 순위를 얻으려면 크롤링이 필요하지만 더 많이 크롤링된다고 순위가 오르지는 않습니다. 오직 효율성 문제입니다.
• 내부적으로는 호스트 부하가 제한하는 중요도 기반 스케줄링입니다. 고정 일일 할당량이 아닌 우선순위 큐이며 검색 수요를 따릅니다.
• 대부분의 사이트는 관리할 필요가 없습니다. Mueller는 보통 100k URL로는 문제가 되지 않는다고 했고 Google은 게시 당일 크롤링되면 가이드를 건너뛰라고 합니다. 약 1M+ 페이지가 매주 바뀌거나 10k+가 매일 바뀌거나 “발견됨 - 현재 색인이 생성되지 않음” URL이 많을 때 문제가 됩니다.
• 낭비 요소(Google 순서): 패싯 탐색/세션 ID, 중복 콘텐츠, 소프트 404s, 해킹 페이지, 무한 공간, 저품질 콘텐츠, 그리고 리디렉션 체인과 느린 페이지.
• 낭비를 제거해 최적화: 중복 통합, 가치 없는 경로를 robots.txt로 차단, noindex는 사용하지 않기, 소프트 404s 수정, 리디렉션 단축, 깨끗한 사이트맵, 내부 링크 강화. 예산을 실제로 늘리는 두 방법은 서버 용량과 콘텐츠 품질 향상뿐입니다.
• 측정 도구: GSC Crawl Stats, 서버 로그 분석, “발견됨 - 현재 색인이 생성되지 않음” 보고서.
• Bing은 이를 크롤 효율성이라고 하며 “less is more” 원칙과 IndexNow + Crawl Control을 사용합니다.

공식 문서

검색엔진의 1차 출처 문서입니다.

Google

• 크롤 예산 최적화 — 기준 문서. 이전 “대형 사이트 소유자 가이드” URL에서 Google 크롤링 인프라 문서로 이동했고 2025년 12월에 마지막 업데이트되었습니다. 크롤 용량 + 수요, 대상 사이트, 낭비 목록, 최적화 방법을 다룹니다. 여기서 시작하세요.
• Googlebot에서 크롤 예산의 의미(Gary Illyes, 2017) — 크롤 속도 제한 + 크롤 수요와 저가치 URL 범주를 제시한 원래 설명.
• 크롤링 및 색인 생성 — robots, 사이트맵, 캐노니컬, 크롤 제어 허브.
• Crawling December 시리즈(2024) — Googlebot, HTTP 캐싱, 패싯 탐색, CDN.

Bing / Microsoft

• bingbot 시리즈: 크롤 효율성 극대화 — Bing의 “크롤 효율성” 관점과 핵심 목표.
• bingbot 시리즈: 크롤 빈도 최적화 — Bing의 재크롤링 주기 결정 방식.
• Bing 웹마스터 도구 — 크롤 제어 — 시간대별 bingbot 크롤 일정.
• IndexNow / indexnow.org — 변경 URL을 전송해 탐색 크롤을 줄입니다.

출처 인용문

Google과 Bing의 공개 발언입니다. 각 링크는 출처 페이지의 인용 구절로 바로 이동합니다.

Google — 정의

• “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (번역) Google이 사이트 크롤링에 쓰는 시간과 자원을 크롤 예산이라고 하며 크롤 용량 제한과 크롤 수요로 결정됩니다. — Google Search Central 문서. 인용문으로 이동
• “Google’s crawlers calculate a crawl capacity limit, which is the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (번역) Google 크롤러는 최대 동시 병렬 연결 수와 가져오기 사이 지연인 크롤 용량 제한을 계산합니다. 인용문으로 이동
• “Taking crawl rate and crawl demand together we define crawl budget as the number of URLs Googlebot can and wants to crawl.” (번역) 크롤 속도와 수요를 합쳐 Googlebot이 크롤링할 수 있고 하려는 URL 수를 크롤 예산이라고 정의합니다. — Gary Illyes, Google (2017). 인용문으로 이동

Google — 걱정할 필요가 없는 경우

• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (번역) 빠르게 바뀌는 페이지가 아주 많지 않거나 게시 당일 크롤링된다면 이 가이드를 읽을 필요가 없습니다. 인용문으로 이동
• “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (번역) 100k URL은 보통 크롤 예산에 영향을 주지 않으며 3개월간 분당 1개 미만입니다. — John Mueller, Google (2021). 보도 읽기

Google — 통제할 수 있는 요소와 크롤링·순위의 차이

• “If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (번역) 중복되거나 원치 않는 URL이 많으면 Google 크롤링 시간을 낭비하며, 이것이 가장 적극적으로 통제할 수 있는 요소입니다. 인용문으로 이동
• “An increased crawl rate will not necessarily lead to better positions in Search results. Google uses hundreds of signals to rank the results, and while crawling is necessary for being in the results, it’s not a ranking signal.” (번역) 크롤 속도가 높아져도 검색 순위가 좋아지는 것은 아니며 크롤링은 검색 결과에 필요하지만 순위 신호가 아닙니다. — Gary Illyes, Google (2017). 인용문으로 이동

Google — 낭비 목록과 하지 말아야 할 일

• “Faceted navigation and session identifiers / On-site duplicate content / Soft error pages / Hacked pages / Infinite spaces and proxies / Low quality and spam content” (번역) 패싯 탐색과 세션 식별자 / 사이트 내 중복 콘텐츠 / 소프트 오류 페이지 / 해킹 페이지 / 무한 공간과 프록시 / 저품질·스팸 콘텐츠. — 중요도순 저가치 범주. — Gary Illyes, Google (2017). 인용문으로 이동
• “Consolidate duplicate content to focus crawling on unique content rather than unique URLs.” (번역) 고유 URL이 아닌 고유 콘텐츠 크롤링에 집중하도록 중복 콘텐츠를 통합하세요. 인용문으로 이동
• “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (번역) Google은 여전히 요청한 뒤 noindex를 보고 버리므로 크롤링 시간을 낭비합니다. 인용문으로 이동
• “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s serving limit.” (번역) Google이 이미 제공 한도에 도달하지 않았다면 새로 남은 예산을 다른 페이지로 옮기지 않습니다. 인용문으로 이동

Gary Illyes, Google — 스케줄링과 호스트 부하 (Stone Temple Q&A를 다룬 Search Engine Roundtable 보도)

• “Host load kind of sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (번역) 호스트 부하가 URL을 중요도순 버킷에 놓고 Googlebot은 그 일정대로 크롤링합니다. 서버가 감당할 수 있으면 전체를 크롤링하고 아니면 멈춥니다. 인용문으로 이동

Fabrice Canel, Microsoft Bing

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (번역) 크롤 효율성은 크롤링한 페이지당 새롭고 신선한 콘텐츠를 얼마나 자주 크롤링하고 발견하는지입니다. 인용문으로 이동
• “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (번역) SEO에서는 적을수록 좋습니다. 크롤링할 URL이 적을수록 SEO에 좋습니다. 인용문으로 이동

크롤 예산 최적화 체크리스트

실제 예산 문제를 확인한 경우에만 수행할 가치가 있습니다. 대형 사이트, 게시 당일 크롤링 지연, 또는 늘어나는 “발견됨 - 현재 색인이 생성되지 않음” 묶음이 기준입니다.

• 최적화 전에 GSC Crawl Stats와 “발견됨 - 현재 색인이 생성되지 않음”을 확인해 문제가 실제인지 검증했다.
• 호스트, 프로토콜, 끝 슬래시, 대소문자에 하나의 캐노니컬 규칙을 정하고 중복을 통합했다.
• URL 매개변수를 처리했다. 캐노니컬을 지정하거나 중복·저가치 변형만 만드는 매개변수를 차단했다.
• 가치 없는 필터·정렬 조합을 robots.txt에서 차단하거나 크롤링되지 않도록 # 뒤로 옮겨 패싯 탐색을 통제했다.
• 소프트 404s를 고치고 영구 삭제 페이지에 실제 404/410을 반환한다.
• 리디렉션 체인을 제거하거나 줄였다.
• 사이트맵에는 정확한 lastmod를 가진 캐노니컬·색인 가능 URL만 있다.
• 예산 “절약”에 noindex를 사용하지 않았고(Google이 어차피 요청함) robots.txt 차단이 다른 페이지로 예산을 재배분한다고 기대하지 않는다.
• 중요하거나 새로 게시한 페이지의 내부 링크를 강화했다.
• 서버 응답 시간과 페이지 로드 효율을 개선했다.
• Bing에서는 IndexNow로 변경사항을 전송하고 서버 부하가 제약이면 Crawl Control을 사용했다.

사고 모델

1. 예산 = 용량 × 수요. 크롤 용량은 서버가 감당하는 양이고 크롤 수요는 인기도 + 오래됨 + 인지된 인벤토리입니다. 빠른 서버라도 수요가 낮으면 덜 크롤링되고, 수요가 높아도 불안정한 서버에서는 제한됩니다. 유효 예산을 높이려면 “더 요청”하기보다 낭비를 없애는 경우가 거의 전부입니다.

2. “정말 문제가 있는가?” 관문. 무언가 바꾸기 전에 확인하세요.

• 게시 당일 크롤링되는가? → 문제없음. 여기서 중단.
• URL이 약 100k 미만인가(Mueller의 경험칙)? → 거의 확실히 문제없음.
• 매주 바뀌는 1M+ 페이지, 매일 바뀌는 10k+ 페이지, 또는 큰 “발견됨 - 현재 색인이 생성되지 않음” 묶음인가? → 이제 시간을 들일 가치가 있음.

3. Google에 더 많이 크롤링하라고 하기 전에 낭비를 없애세요. 이 문서에서 가장 효과적인 원칙입니다. Google은 알려진 모든 URL을 크롤링하려 합니다. 절반이 중복, 패싯, 소프트 404s라면 예산을 낭비하는 것입니다. 이를 줄이면 중요한 페이지에 예산이 집중되며, 이것이 가장 적극적으로 통제할 수 있는 요소입니다.

4. 크롤링 ≠ 순위. 크롤링은 관문이지 점수판이 아닙니다. 크롤링 증가로 순위가 오르지 않으므로 목표는 원시 크롤 양이 아니라 올바른 URL의 범위입니다.

5. 할당량이 아니라 우선순위 큐. 내부적으로는 호스트 부하가 제한하는 중요도 기반 스케줄링입니다. “하루 N페이지”가 아닌 우선순위 URL 버킷입니다. 링크와 수요로 중요도를 높이고 낭비를 줄여 큐에서 앞쪽으로 이동합니다.

크롤 예산 요약표

낭비 요소(Google의 중요도순)

여기에 긴 리디렉션 체인과 느리고 무거운 페이지가 모든 가져오기 비용을 높입니다.

정말 신경 써야 하나요?

• 게시 당일 크롤링 → 아니요.
• < 약 100k URL(Mueller) → 거의 확실히 아니요.
• 매주 바뀌는 1M+ 페이지, 매일 바뀌는 10k+ 페이지, 큰 “발견됨 - 현재 색인이 생성되지 않음” 묶음 → 예.

효과적인 수정

• 중복 통합 / 캐노니컬 지정.
• 가치 없는 경로(패싯, 매개변수)를 robots.txt에서 차단. 예산 “절약”에 noindex를 쓰지 않음.
• 소프트 404s를 고치고 실제 404/410 반환.
• 리디렉션 체인을 줄이고 서버 속도 개선.
• 사이트맵 정리와 내부 링크 강화.

Google이 말하는 예산을 늘리는 두 방법: 더 많은 서버 용량 그리고 더 높은 콘텐츠 품질입니다. 하나만으로는 부족합니다.

Bing: “크롤 효율성”으로 부르며 IndexNow로 전송하고 Crawl Control로 일정을 설정합니다.

크롤 예산 측정·관리 도구

• Google Search Console — Crawl Stats 보고서(설정 → Crawl Stats) — 시간별 총 요청, 평균 응답 시간, 호스트 상태, 응답 코드·파일 유형·Googlebot 유형별 내역을 보여 주는 Google 자체 데이터. 여기서 시작하세요.
• GSC “발견됨 - 현재 색인이 생성되지 않음”(페이지 보고서) — Google이 알지만 크롤링하지 않는 URL의 경고등.
• 서버 로그 파일 분석 — 봇이 실제 요청한 URL과 빈도의 근거. Screaming Frog Log File Analyser를 쓰거나 BigQuery/로그 플랫폼으로 보낼 수 있습니다. 로그 파일 분석을 참고하세요.
• Ahrefs Site Audit / Screaming Frog SEO Spider — 크롤링을 시뮬레이션해 중복 URL, 리디렉션 체인, 소프트 404s, 차단 URL, 트랩형 패싯 공간을 찾습니다.
• Ahrefs Webmaster Tools — 검증한 사이트의 무료 크롤·감사.
• URL 검사(GSC) — 단일 URL의 게시 당일 크롤링 여부를 빠르게 확인.
• Bing Webmaster Tools — Crawl Control — 서버 부하가 제약일 때 시간대별 bingbot 일정을 설정.

크롤 예산 문제가 있나요?

월간 크롤 예산 상태 점검

1. 매월 같은 보고 기간의 검색 크롤러 요청을 서버 로그에서 내보냅니다.
2. 상태 코드, 디렉터리, 페이지 유형, URL 색인 가능 여부로 요청을 나눕니다.
3. 요청량이 많은 매개변수 패턴, 중복 경로, 리디렉션, 소프트 404s, 서버 오류를 검토합니다.
4. 가치 있는 템플릿의 크롤 점유율을 이전 기간과 비교하고 출시·마이그레이션을 표시합니다.
5. 새 낭비 패턴마다 담당자와 제어 수단(링크, 매개변수, 리디렉션, 캐노니컬, 제거, 서버 복구)을 지정합니다.
6. 다음 로그 기간에 해당 패턴을 다시 확인합니다. 가치 있는 URL의 접근성이 유지되고 자체 기준선 대비 낭비가 줄면 SOP가 끝납니다.

크롤 예산 실수

• 더 큰 요청 수를 좇음. 크롤링 증가는 순위를 높이지 않습니다. 중요 URL이 필요할 때 크롤링되는지 추적하세요.
• robots.txt에서만 낭비를 차단함. 가져오기는 막아도 발견된 URL이나 이를 만드는 링크는 남을 수 있습니다. 크롤 경로를 제거하고 필요하면 인벤토리를 통합하세요.
• 모든 빌드에서 사이트맵 lastmod를 갱신함. 거짓 신선도는 크롤러가 신호를 믿지 않게 합니다. 의미 있는 페이지 변경에만 바꾸세요.
• URL 패턴을 조정하며 서버 오류를 무시함. 용량 문제는 유용한 크롤링을 제한합니다. 시간 초과와 5xx 응답부터 고치세요.
• 모든 제외 URL을 낭비로 취급함. 일부 비색인 리소스는 렌더링이나 발견을 지원합니다. 차단 전에 목적을 분류하세요.

프롬프트: 크롤 로그 낭비 분류

URL, 템플릿, 상태, 봇, 요청 수, 바이트, 색인 가능 여부가 포함된 로그 기반 CSV를 붙여 넣으세요. 먼저 쿼리 값이나 사용자 데이터를 제거하세요.

Act as a technical SEO analyst. Classify each URL pattern as valuable crawling, necessary support crawling, redirect/error waste, duplicate/parameter waste, or unclear. Do not infer intent from the URL alone: list the evidence needed for every unclear row. Rank patterns by crawler requests and bytes, propose the safest control, and state what could break if that control is wrong. Return a table plus a short validation plan.

프롬프트: 크롤 예산 진단 검증

Review the crawl-budget diagnosis below. Separate evidence of capacity, demand, discovery, and URL-inventory problems. Flag claims that confuse crawling with indexing or rankings. Then give the three smallest tests that would confirm or reject the diagnosis. Do not invent thresholds; use changes against the site's own baseline.

[PASTE DIAGNOSIS AND OBSERVATIONS]

액세스 로그에서 크롤러 상태 코드 요약

검증된 크롤러 트래픽에 맞게 봇 패턴을 조정한 뒤 nginx/Apache 형식 로그에 실행하세요.

awk 'BEGIN{IGNORECASE=1} /Googlebot|bingbot/ {print $9}' access.log | sort | uniq -c | sort -nr

PowerShell에서는 다음과 같습니다.

Select-String -Path .\access.log -Pattern 'Googlebot|bingbot' | ForEach-Object { if ($_.Line -match '"\s(\d{3})\s') { $Matches[1] } } | Group-Object | Sort-Object Count -Descending

쿼리 매개변수 계열 추출

크롤러 내보내기나 텍스트 편집기에서 다음 정규식으로 첫 번째 쿼리 매개변수 이름을 캡처하세요.

\?([^=&]+)(?:=[^&]*)?

그룹 1이 매개변수 이름입니다. 요청 수가 많다는 것은 조사할 패턴을 뜻할 뿐 자동 차단할 URL을 뜻하지 않습니다.

테스트: 크롤 예산

시간을 들일 가치가 있는 자료

제 관련 글

• 언제 크롤 예산을 걱정해야 하나요? — 최적화 세부 사항과 패싯 탐색 결정을 담은 전체 Ahrefs 가이드.
• “발견됨 - 현재 색인이 생성되지 않음” 해결 방법 — 크롤 예산 경고등이기도 한 GSC 신호.
• 기술 SEO 초보자 가이드 — 큰 그림에서 크롤 예산의 위치.
• 엔터프라이즈 SEO 전략 — 실제로 이 문제가 있는 소수 대형 사이트 대상.

제 강연

• 검색 작동 방식 (SlideShare) — 크롤 수요와 크롤 속도 제한 모델 설명. 고정 면책 문구가 적용됩니다. “This is my understanding of systems… not going to be 100% complete or accurate.” (번역) 이는 시스템에 대한 제 이해이며 100% 완전하거나 정확하지 않을 수 있습니다.

업계 자료

• Google의 Crawling December 시리즈 — 패싯 탐색을 포함한 집중 크롤링 설명 자료.
• 웹마스터를 위한 Google의 “크롤 예산” 설명 (Barry Schwartz, Search Engine Land, 2017) — Google 원문을 쉽게 요약하고 “most sites don’t need to worry” (번역) 대부분의 사이트는 걱정할 필요가 없다는 맥락 제공.
• Gary Illyes가 설명하는 크롤 예산·스케줄링·호스트 부하의 차이 (Search Engine Roundtable) — 고정 할당량이 아닌 우선순위 큐임을 보여 주는 중요도 버킷/호스트 부하 설명 출처.
• Google: URL 100,000개는 보통 크롤 예산에 영향 없음 (Search Engine Roundtable, 2021) — Mueller의 100k 기준과 3개월 동안 <1/minute 맥락.
• Google 크롤링 우선순위: Gary Illyes의 설명 (Search Engine Journal) — 고정 일일 할당량 반박과 검색 시스템에 가져올 가치가 있다고 설득하는 관점.
• 크롤·렌더링·색인의 다섯 인프라 관문 (Search Engine Land) — Fabrice Canel의 “Less is more for SEO”와 Bing의 크롤 효율성 관점 출처.
• bingbot 시리즈: 크롤 빈도 최적화 (Bing Webmaster Blog, Fabrice Canel) — Bing의 재크롤링 주기 결정 방식.
• r/TechSEO — 크롤·색인 디버깅 커뮤니티.

인용할 만한 통계

• 100k URL은 보통 문제가 되지 않습니다. John Mueller의 구체적 기준은 *“100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).”*입니다. 크롤 예산 걱정을 낮추는 데 가장 유용한 수치입니다. 출처
• 문제가 시작되는 기준: 대략 매주 바뀌는 1 million+ 페이지 또는 매일 바뀌는 10 000+ 페이지입니다. Google의 대략적 추정이지 정확한 기준은 아닙니다. 출처
• 웹의 약 60%는 중복 콘텐츠라는 Google 내부 추정은 중복 URL이 크롤 예산을 안정적으로 소모하는 이유를 보여 줍니다. 출처

크롤 효율성의 상시 KPI

Google은 크롤 예산이라는 수치를 직접 주지 않습니다. Googlebot이 실제로 요청을 어디에 쓰는지에서 추론합니다. KPI는 색인을 원하는 페이지와 순수 낭비 페이지에 쓰인 크롤링의 분할입니다. 먼저 정직한 확인이 필요합니다. 이는 규모가 클 때만 중요합니다. Google은 주로 약 1M+ 페이지 사이트나 자동 생성 URL이 많은 중형 사이트의 문제라고 합니다. 소규모 정적 사이트는 이 지표를 건너뛰어도 됩니다.

크롤 배분 — 가치 있는 요청과 낭비 요청

• 지표 — 검증된 Googlebot 요청 중 중요하고 색인 가능한 URL과 낭비 URL(중복, 매개변수/패싯 URL, 비캐노니컬 변형, 리디렉션 단계, 4xx/5xx)의 비율.
• 의미 — 크롤 용량이 순위를 얻을 수 있는 페이지에 쓰이는지 보여 줍니다. 낭비 비율 상승은 순위 문제로 나타나기 전 발견·색인 지연의 선행 지표입니다.
• 확인 방법 — 서버 로그를 로그 파일 분석기에 넣어 검증된 Googlebot 요청을 URL 등급별로 나누고 GSC Crawl Stats 보고서(총 요청, 응답별, 파일 목적별, 호스트 상태)와 대조합니다.
• 벤치마크/현실적 범위 — URL 구조에 따라 달라지므로 정직한 보편적 “낭비 %“는 없습니다. 자체 기준선을 세워 낭비 비율을 줄이세요. 임의 절대값이 아니라 추세가 신호입니다.
• 주기 — 매월, 새 패싯이나 마이그레이션 같은 구조 변경 직후 또는 Crawl Stats에서 요청이나 4xx/5xx가 급증할 때 더 자주 봅니다. 낭비 크롤링은 선행 지표이고 색인 페이지 수는 후행합니다.

변경 내역