크롤 수요

TL;DR — 크롤 예산에는 검색엔진이 페이지를 얼마나 빨리 가져올 수 있는지(크롤 속도)와 얼마나 가져오고 싶어 하는지(크롤 수요)라는 두 측면이 있습니다. 크롤 수요는 “원함” 측면입니다. Google은 링크가 많아 인기 있는 페이지, 자주 바뀌는 페이지, 시간을 들일 가치가 있다고 판단한 사이트를 더 크롤링하려 합니다. 버튼으로 수요를 높일 수는 없습니다. 링크, 실제 신선도, 좋은 페이지를 가치 없는 URL 더미에 묻지 않는 구조로 얻어야 합니다.

크롤 수요란?

“크롤 예산”은 사실 별개의 두 요소를 합친 말입니다. 하나는 서버가 크롤링을 얼마나 빠르게, 동시에 몇 페이지까지 감당할 수 있는지입니다. 이는 크롤 속도이며 별도 문서에서 다룹니다. 다른 하나는 검색엔진이 애초에 사이트를 얼마나 크롤링하기 원하는지입니다. 이것이 이 문서의 주제인 크롤 수요입니다.

공급과 수요로 생각하세요. 크롤 속도는 사이트가 지원할 수 있는 크롤링 양인 공급이고, 크롤 수요는 Google이 하려는 양인 수요입니다. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Google이 페이지를 크롤링하고 싶게 만드는 요소

Google은 완전한 단일 체크리스트가 아니라 몇 가지 중요한 요소를 제시합니다. 가장 자세히 설명하는 세 가지는 다음과 같습니다.

• 인기도. 링크가 많이 연결된 페이지는 Google 사본을 최신으로 유지하기 위해 더 자주 크롤링됩니다.
• 오래됨/신선도. 자주 바뀌는 페이지는 더 자주 확인하려 하고, 전혀 바뀌지 않으면 점점 덜 확인합니다.
• Google이 인식하는 URL 수. 사이트가 가치 없는 URL, 중복 URL, 저가치 URL로 가득하면 Google은 실제 페이지 대신 그곳에 크롤링을 낭비합니다. 가장 많이 통제할 수 있는 요소입니다. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Google은 이 세 가지 외에도 사이트 규모, 업데이트 빈도, 페이지 품질, 비슷한 주제의 다른 사이트와 비교한 수준을 사이트 단위 수요 요소로 언급합니다. “인기도, 오래됨, 인지된 인벤토리”를 완전한 공식으로 보지 마세요. 가장 크고 실행 가능한 지렛대이지 전체 목록은 아닙니다.

일시적 요소도 있습니다. 사이트를 새 도메인으로 이전하면 Google이 새 URL에서 모든 것을 다시 크롤링하고 처리해야 하므로 한동안 수요가 급증합니다.

단순히 “크롤 수요를 늘릴” 수 없는 이유

Google을 더 빨리 크롤링하게 만드는 버튼이 없듯 수요에도 조절기가 없습니다. 아무도 링크하지 않고 실제로 유용하지 않다면 하루에 글 열 개를 게시해도 달라지지 않습니다. 효과가 있는 것은 느리고 실제적인 일입니다. 링크를 얻고, 콘텐츠를 진짜 최신으로 유지하고, 가치 없는 URL을 없애 Google의 크롤링이 중요한 페이지에 닿게 하세요.

놀라운 점은 크롤링 증가가 목표조차 아니라는 것입니다. 많이 크롤링된다고 순위가 오르지 않습니다. 필요한 것은 더 많은 수요가 아니라 이미 있는 수요가 올바른 페이지를 향하게 하는 것입니다.

수요와 서버 용량의 상호작용, 사이트 품질이 크롤 스케줄러로 되돌아가는 방식, 수요 문제와 용량 문제 구분까지 자세히 보려면 고급 탭으로 전환하세요.

TL;DR — 크롤 수요는 크롤 예산의 원함 측면이고 크롤 속도/용량은 가능 측면입니다. Google은 인기도(링크/PageRank), 오래됨(페이지 변경 빈도), 인지된 인벤토리(가치 없는 URL까지 포함해 Google이 존재한다고 보는 URL 수이자 가장 적극적으로 통제할 수 있는 요소)를 중요한 일반 수요 요소로 제시하지만 폐쇄된 공식은 아닙니다. 사이트 규모, 업데이트 빈도, 페이지 품질, 비교 관련성도 영향을 줍니다. 사이트 이전은 수요를 일시적으로 높입니다. 이를 연결한 제 종합 모델은 수요가 URL의 우선순위를 정하고 호스트 부하 기반 용량이 Googlebot이 큐를 얼마나 내려갈지 결정한다는 것입니다. Google이 문자 그대로 문서화한 알고리즘은 아니지만 근거와 맞는 모델입니다. 건강한 서버는 수요를 만들지 않고 높은 수요도 용량에 제한될 수 있습니다. 수요는 직접 설정할 수 없고 입력 요소만 바꿀 수 있으며, 색인 품질 신호가 좋아지면 스케줄러가 수요를 높입니다. Google은 더 정확하게 수요를 배분하면서 전체 크롤링은 줄이려 하므로 목표는 양이 아니라 올바른 우선순위입니다. 대부분의 사이트는 관리할 필요가 없습니다.

크롤 수요는 “원함”, 크롤 속도는 “가능”

Google은 크롤 예산에 두 부분이 있다고 명시합니다. 사이트 크롤링에 쓰는 시간과 자원은 크롤 용량 제한과 크롤 수요라는 두 요소로 결정됩니다. 제 Ahrefs 크롤 예산 가이드에서도 크롤 수요는 검색엔진이 사이트에서 크롤링하려는 페이지 수이고 크롤 속도는 얼마나 빨리 크롤링할 수 있는지를 뜻한다고 설명합니다. 수요는 원함, 속도는 가능입니다. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

이 페이지는 원함만 다룹니다. 가능 측면인 크롤 용량 제한, 2024년 1월 제거된 GSC 속도 조절기, 5xx/429 응답이 Googlebot을 늦추는 방식, Bing의 수동 Crawl Control 그리드는 모두 크롤 속도 페이지에 있습니다. 여기서 다시 설명하지 않고 둘이 상호작용할 때 연결하겠습니다.

세 가지 수요 입력

Google의 현재 지침은 인지된 인벤토리, 인기도, 오래됨을 크롤링 의향을 결정하는 중요한 일반 요소로 부르지만 완전하고 폐쇄된 공식으로 제시하지 않습니다. 같은 지침은 사이트 규모, 업데이트 빈도, 페이지 품질, 비슷한 사이트와의 비교도 Googlebot이 고려한다고 말합니다. 아래 세 가지는 Google이 가장 자세히 설명하고 직접 조치할 수 있는 요소입니다. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

인기도

“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (번역) 인터넷에서 더 인기 있는 URL은 시스템에서 최신 상태로 유지하기 위해 더 자주 크롤링되는 경향이 있습니다. URL을 향한 링크와 PageRank가 많으면 수요 신호가 됩니다. 홈페이지는 계속 크롤링되지만 깊숙하고 링크 없는 페이지는 거의 크롤링되지 않는 이유입니다. 제 크롤 예산 가이드에서는 “Popular pages, or those with more links and PageRank, will generally receive priority over other pages.” (번역) 인기 페이지나 링크·PageRank가 더 많은 페이지는 일반적으로 다른 페이지보다 우선한다고 설명합니다. 내부 링크도 포함됩니다. 아무것도 연결하지 않는 고아 페이지에는 수요가 거의 없습니다.

오래됨

“Our systems want to recrawl documents frequently enough to pick up any changes.” (번역) 시스템은 변경사항을 포착할 만큼 자주 문서를 재크롤링하려 합니다. Google은 페이지별 리듬을 학습합니다. 계속 바뀌는 페이지는 자주 재크롤링되고 전혀 바뀌지 않는 페이지는 점점 덜 확인됩니다. 제 크롤 예산 가이드는 정적 페이지의 후퇴를 “if they crawl a page and see no changes after a day, they may wait three days before crawling again, ten days the next time, 30 days, 100 days, etc.” (번역) 하루 뒤 변화가 없으면 다음에는 사흘, 그다음 열흘, 30일, 100일을 기다릴 수 있다고 설명합니다. URL별 재크롤 주기는 실제로 크롤 빈도 문제이지만 그 기저 힘은 수요, 특히 오래됨입니다.

인지된 인벤토리(가장 많이 통제할 수 있는 요소)

핵심 지렛대입니다. 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 (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.” (번역) 안내가 없으면 Google은 알려진 URL 대부분을 크롤링하려 하고, 중복되거나 원치 않는 URL이 많으면 시간을 낭비하며 이것이 가장 적극적으로 통제할 수 있는 요소라고 합니다.

미묘한 부분은 용량뿐 아니라 수요에도 미치는 영향입니다. 가치 없는 URL이 새 콘텐츠 대신 중복 사본을 가져오게 해 “크롤 예산을 낭비”한다는 설명은 맞습니다. 하지만 Google이 알 수 있는 인벤토리 대부분이 저가치 중복과 매개변수 확산인 사이트는 크롤링할 가치도 낮아 보입니다. 인지된 인벤토리를 줄이면 용량이 남을 뿐 아니라 시간이 지나며 가치 있는 URL에 수요가 집중됩니다. 패싯 탐색, 세션 ID, 무한 달력 공간 같은 스파이더 트랩은 대표적인 인벤토리 팽창 및 수요 억제 요소입니다.

사이트 이전과 기타 수요 급증

개별 URL이 아닌 수요 요인도 있습니다. “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (번역) 사이트 이전 같은 사이트 전체 이벤트는 새 URL에서 콘텐츠를 재처리하기 위해 크롤 수요를 높일 수 있습니다. 도메인 마이그레이션이나 대규모 리플랫폼 뒤 몇 주 동안 Googlebot 요청이 평소보다 크게 늘어도 예상된 현상입니다. 새 주소에서 모두 다시 가져와 처리해야 하기 때문입니다. 새 기준선이 아닌 일시적 급증이며 Google 문서에 그대로 있지만 경쟁사 가이드에서는 거의 언급하지 않는 수요 이벤트입니다.

수요와 호스트 부하의 상호작용: 큐 순서와 용량 관문

전체 주제를 이해하게 해 주는 사고 모델이지만 제 종합이지 Google이 문자 그대로 문서화한 알고리즘은 아닙니다. Search Engine Roundtable가 전한 Gary Illyes Q&A를 기반으로 합니다. 호스트 부하는 “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을 중요도순 버킷에 놓고 호스트 부하 일정에 따라 크롤링하며 서버가 감당하면 전체를, 아니면 중단합니다. 같은 Q&A에 따르면 호스트 부하는 URL 원시 개수나 원하는 크롤 수가 아니라 페이지 중요도를 따릅니다. 해당 페이지가 자동 가져오기를 막아 이번에는 실제 출처의 정확한 문구를 다시 확인하지 못했습니다. 1차 출처의 직인용이 아닌 충분히 교차 확인된 의역으로 취급하세요.

주의 깊게 읽으면 다음 관계가 나옵니다. 다시 말하지만 Google이 처음부터 끝까지 명시한 메커니즘이 아니라 제가 요소를 연결한 방식입니다.

• 수요가 순서를 정합니다. “중요도순 URL 버킷”이 크롤 수요입니다. 인기도와 오래됨이 큐 상단의 URL을 정합니다.
• 용량이 진행 깊이를 정합니다. 호스트 부하/크롤 속도가 특정 날 Googlebot이 정렬된 버킷을 얼마나 깊이 크롤링하는지 결정합니다. 서버가 감당하면 전체 버킷을 크롤링하고 아니면 멈춥니다.

둘은 단순 곱셈이 아니라 서로 다른 역할을 합니다. 건강하고 빠른 서버는 수요를 만들지 않습니다. 기존 수요가 실현될 상한만 높입니다. 높은 수요도 용량에 제한될 수 있습니다. 느리거나 오류가 많은 서버는 Googlebot이 아무리 크롤링하고 싶어도 큐 중간에서 멈추게 합니다. “더 빠른 서버를 샀는데 새 페이지가 여전히 크롤링되지 않는다”는 결과가 흔한 이유는 용량이 애초 제약이 아니고 수요가 제약이었기 때문입니다.

수요를 직접 설정할 수는 없지만 스케줄러는 신호를 듣습니다

짧은 답: 수요는 직접 설정하지 못합니다. 색인 신호에 나타나는 실제 링크와 실제 품질 개선을 통해 간접적으로 얻으며 다른 것은 움직이지 않습니다.

수요에는 “더 크롤링” 요청이 없습니다. 하지만 동적이며 Google은 움직이는 방식을 이례적으로 솔직히 설명했습니다. Gary Illyes는 “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.” (번역) 더 많은 크롤링을 원한다면 검색 시스템에 가져올 가치가 있다고 설득해야 한다고 했습니다. 피드백 루프도 거의 실시간입니다. “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (번역) 색인에서 여러 URL의 품질 향상 신호가 돌아오면 수요를 높이기 시작합니다. 반대도 같습니다. “If search demand goes down, then that also correlates to the crawl limit going down.” (번역) 검색 수요가 내려가면 크롤 한도도 내려갑니다. 이번에 Search Engine Journal 보도와 세 문장을 대조해 일치함을 확인했지만 Google의 원본 팟캐스트 오디오/전사는 찾지 못했으므로 충분히 교차 확인된 2차 인용으로 취급하세요.

따라서 “크롤 수요를 늘리는 법”은 요령이 아닙니다. 가짜 lastmod, 사이트맵 핑, 게시량은 스케줄러를 설득하지 못합니다. 효과가 있는 것은 두 가지 어려운 일, 즉 실제 인기도(링크)와 색인 신호에 나타나 스케줄러로 되돌아가는 실제 품질 개선입니다. 나머지는 보여 주기일 뿐입니다.

Google은 더 많이가 아니라 더 적게 크롤링하려 합니다

이 주제의 가장 새로운 관점이자 오래된 가이드가 놓친 부분입니다. Google의 공식 목표는 전체 크롤 양을 늘리지 않고 줄이는 것입니다. Illyes는 2024년 4월 LinkedIn에 “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (번역) 올해 목표는 더 적게 크롤링하고 전송 바이트를 줄이는 것이라고 썼습니다. Google이 크롤링을 크게 줄였다는 주장에는 “we’re crawling roughly as much as before, however scheduling got more intelligent” (번역) 크롤 양은 이전과 비슷하지만 스케줄링이 더 지능적으로 됐다고 반박했고, “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (번역) 크롤 품질을 희생하지 않고 크롤링을 줄이면 모두에게 이익이라고 설명했습니다. 제시한 수단은 “내 사이트를 더 크롤링”하는 것이 아니라 더 나은 캐싱, 사용자 에이전트 간 캐시 공유, 전송 바이트 감소였습니다.

결론은 크롤 수요를 극대화할 대상이 아니었다는 것입니다. Google은 같거나 더 나은 크롤 품질로 전체 크롤링은 줄이고, 가치 있을 가능성이 높은 URL에 수요를 배분하려 합니다. 목표는 더 많은 수요가 아니라 이미 얻은 수요의 올바른 우선순위입니다.

수요 문제가 있기는 한가요?

대부분의 사이트에는 없으며 여기에 시간을 쓸 필요도 없습니다. 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.” (번역) 빠르게 바뀌는 페이지가 아주 많지 않거나 게시 당일 크롤링된다면 이 가이드를 읽을 필요가 없습니다. Search Engine Roundtable이 전한 John Mueller의 트윗도 규모에 단호합니다. 100k URL은 석 달에 분당 한 번보다 훨씬 적으므로 보통 크롤 예산에 영향을 주지 않습니다.

규모가 충분하다면 GSC Crawl Stats 보고서와 서버 로그로 수요와 용량 문제를 구분할 수 있지만, 이는 검증할 가설이지 진단이 아닙니다. 호스트 상태와 평균 응답 시간이 정상인데 특정 URL이 거의 크롤링되지 않고 **“발견됨 - 현재 색인이 생성되지 않음”**에 머문다면 용량보다 수요를 가리키는 근거입니다. Crawl Stats는 수요 점수가 아니라 크롤 활동(용량 측면)을 보여 줍니다. 공개된 사이트별 “크롤 수요 점수”는 없으므로 활동과 색인 상태에서 수요를 추론해야 합니다.

“수요 문제”로 행동하기 전에 같은 증상을 만드는 다른 원인을 배제하세요. Google이 URL을 아직 발견하지 못했거나, 렌더링이 필요한 콘텐츠를 숨기거나, 캐노니컬이 다른 곳을 가리키거나, 실제 품질 문제(얕음, 중복, 저가치)로 크롤링 후 색인에서 제외되거나, 크롤링과 품질이 정상이어도 Google의 색인 선택으로 빠질 수 있습니다. 이 원인을 확인해도 설명되지 않을 때만 낮은 수요를 작업 가설로 삼고 확정 원인이 아닌 가장 근거 있는 가설로 취급하세요. 진짜 수요 문제는 더 빠른 하드웨어로 해결되지 않습니다. 페이지 링크, 재크롤링할 실제 이유, 수요를 묻어 버리는 가치 없는 인벤토리 감소가 해결책입니다.

URL별 실제 크롤 데이터는 로그 분석이 답입니다. 도구 탭에는 제가 직접 설명할 수 있는 최신 도구 하나를 소개합니다.

크롤 수요, 속도, 예산, 빈도의 차이

관련 개념을 정확히 구분하세요.

• 크롤 수요 — Google이 크롤링하기 원하는 양(인기도 + 오래됨 + 인지된 인벤토리). 이 페이지의 주제입니다.
• 크롤 속도 — 얼마나 빨리 할 수 있는지(용량/호스트 부하). 별도 페이지의 주제입니다.
• 크롤 예산 — 둘을 합친 것, 즉 Googlebot이 크롤링할 수 있고 하려는 URL 수입니다.
• 크롤 빈도 — 특정 URL이 얼마나 자주 재크롤링되는지로 수요, 특히 오래됨의 결과입니다.

Bing은 “크롤 수요”라는 용어를 쓰지 않고 전체를 크롤 효율성으로 설명합니다. Fabrice Canel은 이를 “how often we crawl and discover new and fresh content per page crawled,” (번역) 크롤링한 페이지당 새롭고 신선한 콘텐츠를 얼마나 자주 크롤링하고 발견하는가라고 정의합니다. Bing의 철학은 인지된 인벤토리와 같은 수요 측면에서 인벤토리를 먼저 줄이는 것입니다. IndexNow는 스케줄러가 오래됨을 추론하기 전에 수요 관련 변경 이벤트를 Bing에 알리는 방식입니다. 단 Google은 IndexNow를 사용하지 않으므로 Google 수요에는 영향을 주지 않습니다.

AI 요약

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

• 크롤 수요 = 크롤 예산의 “원함” 측면, 크롤 속도/용량은 “가능” 측면입니다. 예산은 Googlebot이 크롤링할 수 있고 하려는 URL 수입니다.
• 중요한 수요 요소이나 폐쇄된 공식은 아님: 인기도(링크/PageRank), 오래됨(페이지 변경 빈도), 인지된 인벤토리(가치 없는 URL을 포함해 Google이 존재한다고 보는 URL 수이자 가장 적극적으로 통제할 수 있는 요소), 그리고 사이트 규모, 업데이트 빈도, 페이지 품질, 비교 관련성.
• 사이트 이전은 수요를 일시적으로 높여 Google이 새 URL에서 콘텐츠를 재처리하게 합니다.
• 수요와 용량 모델(문서화된 Google 알고리즘이 아닌 제 종합): 수요가 URL 우선순위를 정하고 호스트 부하 기반 용량이 Googlebot이 큐를 얼마나 진행할지 정합니다. 빠른 서버는 수요를 만들지 않으며 높은 수요도 용량에 제한될 수 있습니다.
• 수요는 직접 설정할 수 없습니다. 색인 품질 신호가 좋아지면 스케줄러가 “turns up demand”하므로 실제 지렛대는 링크와 진짜 품질·신선도 개선입니다. 가짜 lastmod, 사이트맵 핑, 게시량은 움직이지 않습니다.
• Google은 더 많이가 아니라 전체적으로 더 적게 크롤링하려 하며 수요를 더 정확히 배분합니다. 목표는 양이 아닌 올바른 우선순위입니다.
• 수요와 용량 진단: 정상 호스트 + 낮은 크롤 양 + “발견됨 - 현재 색인이 생성되지 않음”은 수요 가설이지 증명이 아닙니다. 먼저 발견, 렌더링, 캐노니컬, 색인 선택 원인을 배제하세요. 공개된 “크롤 수요 점수”는 없습니다.
• Bing은 이를 크롤 효율성으로 설명합니다. IndexNow는 Bing에 변경을 알리지만 Google에는 알리지 않습니다.

공식 문서

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

Google

• 크롤 예산 최적화 — 크롤 수요, 세 입력(인기도, 오래됨, 인지된 인벤토리), 사이트 이전 수요 급증을 정의하는 출처.
• 크롤 예산 관리 — 용량과 수요 구분, 수요가 맞닥뜨리는 크롤 용량 메커니즘.
• Googlebot에서 크롤 예산의 의미(2017) — Gary Illyes가 Googlebot이 “can and wants to crawl”하는 양으로 정의하고 유효 수요를 낮추는 저가치 URL 범주를 제시한 원문.
• 크롤링에 관한 오해와 사실 — 크롤 속도가 순위 신호가 아니며 의향이 아니라 서버 상태가 용량 상한을 정한다는 확인.
• Crawling December 시리즈(2024) — Googlebot, HTTP 캐싱, 패싯 탐색, 더 적게 크롤링하려는 효율성 관점.

Bing / Microsoft

• bingbot 시리즈: 크롤 효율성 극대화 — 수요 측면에 해당하는 Bing의 “크롤 효율성” 관점.
• bingbot 시리즈: 크롤 빈도 최적화 — 콘텐츠 변경 빈도에 따른 Bing의 재크롤링 주기, 즉 “오래됨”에 해당하는 요소.
• IndexNow / indexnow.org — 추론된 오래됨을 기다리지 않고 Bing과 참여 검색엔진(Google 제외)에 변경 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이 사이트 크롤링에 쓰는 시간과 자원을 크롤 예산이라고 하며 크롤 용량 제한과 크롤 수요로 결정됩니다. — 대규모 사이트 소유자를 위한 크롤 예산 관리 가이드. 인용문으로 이동
• “Each crawler has its own ‘demand’ when it comes to crawling the web.” (번역) 각 크롤러에는 웹을 크롤링하는 고유한 수요가 있습니다. 인용문으로 이동
• “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (번역) 더 인기 있는 URL은 시스템에서 최신으로 유지하기 위해 더 자주 크롤링되는 경향이 있습니다. (인기도) 인용문으로 이동
• “Our systems want to recrawl documents frequently enough to pick up any changes.” (번역) 시스템은 변경사항을 포착할 만큼 자주 문서를 재크롤링하려 합니다. (오래됨) 인용문으로 이동

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 크롤링 시간을 낭비하며 이것이 가장 적극적으로 통제할 수 있는 요소입니다. 인용문으로 이동
• “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (번역) 사이트 이전 같은 전체 이벤트는 새 URL에서 콘텐츠를 재처리하기 위해 크롤 수요를 높일 수 있습니다. 인용문으로 이동
• “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.” (번역) 빠르게 바뀌는 페이지가 아주 많지 않거나 게시 당일 크롤링된다면 이 가이드를 읽을 필요가 없습니다. 인용문으로 이동

Gary Illyes, Google — 수요가 움직이는 방식 (팟캐스트 출연을 다룬 Search Engine Journal 보도)

• “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.” (번역) 더 많이 크롤링되길 원한다면 검색 시스템에 콘텐츠를 가져올 가치가 있다고 설득해야 하며 스케줄러가 그것을 듣습니다. 보도 읽기
• “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (번역) 스케줄링은 매우 동적이며 색인에서 여러 URL의 품질 향상 신호를 받으면 수요를 높이기 시작합니다. 보도 읽기
• “If search demand goes down, then that also correlates to the crawl limit going down.” (번역) 검색 수요가 내려가면 크롤 한도도 내려갑니다. 보도 읽기

Gary Illyes, Google — “더 적게 크롤링” 목표 (LinkedIn, 2024년 4월 — 원문과 대조한 1차 출처)

• “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (번역) 올해 목표는 더 적게 크롤링하고 전송 바이트를 줄이는 방법을 찾는 것입니다. 게시물 읽기
• “we’re crawling roughly as much as before, however scheduling got more intelligent” (번역) 크롤 양은 이전과 비슷하지만 스케줄링은 더 지능적이 됐습니다. 또한 “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (번역) 품질을 희생하지 않고 크롤링을 줄이면 모두에게 이익입니다. 게시물 읽기

Bing / Microsoft — 크롤 효율성(수요 측면의 대응 개념)

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (번역) 크롤 효율성은 크롤링한 페이지당 새롭고 신선한 콘텐츠를 얼마나 자주 크롤링하고 발견하는지입니다. — Fabrice Canel. 인용문으로 이동

크롤 수요 문제인가요? 신경 써야 하나요?

위에서 아래로 확인하세요. 대부분의 사이트는 초기에 “그대로 둔다”로 끝납니다.

크롤 수요 오해와 실수

잘못된 방향으로 보내는 개념 혼동입니다.

“크롤 수요와 크롤 예산은 같다.” 틀린 이유: 수요는 두 구성 요소 중 하나입니다. 예산은 용량 × 수요, 즉 Googlebot이 크롤링할 수 있고 하려는 URL 수입니다. 대신 할 일: 용어를 구분하세요. 예산은 결과이고 수요와 용량은 두 입력입니다. 예산 문제는 실제로 수요 문제, 용량 문제 또는 둘 다입니다.

“빠른 서버가 크롤 수요를 높인다.” 틀린 이유: 서버 속도는 용량 상한만 높여 기존 수요를 더 많이 실현하게 할 뿐 Google이 더 크롤링하고 싶게 만들지는 않습니다. 수요는 하드웨어와 무관한 인기도, 오래됨, 인지된 인벤토리에서 옵니다. 대신 할 일: 정상 서버에서도 페이지가 크롤링되지 않으면 하드웨어 구매를 멈추고 링크, 신선도, 가치 없는 인벤토리 감소 같은 수요 입력을 개선하세요.

“더 자주 게시하면 수요가 높아진다.” 틀린 이유: 실제 중요도나 변화 없는 게시량은 스케줄러를 설득하지 못합니다. 아무도 링크하지 않는 얕은 글을 하루 열 개 올려도 움직이지 않습니다. 대신 할 일: 링크를 얻고 실제로 바뀌거나 개선되는 콘텐츠를 게시하세요. 스케줄러가 듣는 품질 신호입니다. 크롤 빈도 글에서도 더 다룹니다.

“가치 없는 URL을 robots.txt에서 막으면 수요가 즉시 좋은 페이지로 간다.” 틀린 이유: 인지된 인벤토리를 줄이면 Google이 사이트를 재평가하면서 수요가 시간에 따라 집중되지만 즉시 재배분되지는 않습니다. 대신 할 일: 장기적인 집중을 위해 가치 없는 인벤토리를 줄이고 기다리세요. 스위치가 아니라 추세입니다.

“Search Console에서 크롤 수요 점수를 볼 수 있다.” 틀린 이유: 공개된 사이트별 수요 점수는 없습니다. Crawl Stats는 수요 지표가 아니라 용량 측면의 크롤 활동을 보여 줍니다. 대신 할 일: 활동과 색인 상태에서 수요를 추론하세요. 정상 호스트 + 낮은 크롤 양 + “발견됨 - 현재 색인이 생성되지 않음”은 수요 신호입니다. URL별 근거는 로그를 사용하세요.

“IndexNow나 사이트맵 핑이 Google 크롤 수요를 높인다.” 틀린 이유: Google은 IndexNow를 사용하지 않고 사이트맵의 changefreq/priority를 무시합니다. 핑으로 크롤 의향이 늘지 않습니다. 대신 할 일: Bing과 참여 검색엔진에는 IndexNow를 사용하세요. Google에는 정확한 lastmod가 일정 설정에 도움을 주지만 수요 지렛대는 링크, 신선도, 인벤토리입니다.

“더 많이 크롤링되면 나와 Google 모두에게 항상 좋다.” 틀린 이유: 크롤링 증가는 순위를 높이지 않으며 Google 자체도 수요를 더 정확히 배분하면서 더 적게 크롤링하려 합니다. Illyes도 전송 바이트를 줄이면서 더 적게 크롤링하는 것이 목표라고 했습니다. 대신 할 일: 원시 양이 아니라 올바른 우선순위를 목표로 하세요. 이미 있는 수요가 올바른 URL에 가야 합니다.

실행 절차: “서버는 정상인데 Google이 중요 페이지를 크롤링하지 않습니다”

수요 문제를 의심하는 대형 사이트 소유자를 위한 선형 절차입니다. 해결되는 단계에서 멈추세요.

1. 신경 쓸 만큼 큰지 확인합니다. 페이지가 보통 게시 당일 크롤링되거나 사이트 규모가 보통이면 중단하세요. 수요 문제는 없습니다. 이 절차는 1M+ 페이지, 빠르게 변하는 사이트, 또는 “발견됨 - 현재 색인이 생성되지 않음” URL이 많은 사이트용입니다.

2. 용량부터 배제합니다. GSC Crawl Stats를 열고 지난 90일의 호스트 상태와 평균 응답 시간을 봅니다. 5xx/시간 초과 급증이나 응답 시간 상승이 있으면 용량 문제입니다. 크롤 속도 글에 따라 서버 상태를 고친 뒤 다시 실행하세요. 서버가 정상이면 계속합니다.

3. 로그에서 URL별 근거를 가져옵니다. 해당 URL 집합의 서버 로그나 봇 분석 피드를 확보하세요. 중요한 페이지에는 실제 Googlebot 요청이 드물거나 없고 가치 없는 매개변수 URL이 요청을 먹는지 확인합니다. 정상 서버에서 요청이 드문 것은 수요 가설이지 확정 원인이 아닙니다. Google이 URL을 발견하지 못함, 렌더링 실패로 콘텐츠가 숨겨짐, 캐노니컬이 다른 곳을 가리킴, 실제 품질·중복 문제, Google의 색인 선택을 먼저 배제하세요. 각각 Search Console URL 검사와 렌더링 HTML 보기를 확인합니다.

4. 인지된 인벤토리 팽창을 확인합니다. 패싯 탐색 조합, 세션 ID, 정렬·필터 매개변수, 달력·무한 공간, 사이트 내 중복 등 Google이 발견할 수 있는 저가치 URL 수를 셉니다. 실제 페이지보다 훨씬 많다면 수요가 가치 없는 URL에 퍼졌을 가능성이 큽니다.

5. 가치 없는 인벤토리를 줄입니다. 매개변수 처리, 무한 공간의 robots.txt 차단, 스파이더 트랩 수정, 캐노니컬을 통한 중복 통합으로 저가치 URL 공간을 근원에서 줄입니다. 즉시 재배분이 아니라 시간에 따른 집중을 기대하세요.

6. 인기도 입력을 개선합니다. 강한 페이지에서 크롤링이 부족한 페이지로 내부 링크를 추가해 고아 페이지를 없애고 외부 링크도 얻으세요. 인기도는 주요 수요 요인입니다.

7. 품질/신선도 입력을 개선합니다. 페이지를 실제로 개선·업데이트해 색인에서 돌아오는 신호가 스케줄러에 “turn up demand”를 알리게 합니다. 정확한 lastmod는 일정 설정에 도움을 주지만 가짜 신선도는 그렇지 않습니다.

8. 시간을 준 뒤 다시 측정합니다. Google이 재평가할 시간을 준 뒤 Crawl Stats와 로그를 확인하세요. 수요 변화는 점진적입니다. 페이지가 크롤링·색인되면 완료입니다. 아니면 정말 크롤링할 가치가 있는지 다시 검토하세요. 솔직한 답이 “아니다”일 수 있으며 얕은 페이지를 색인에 강제로 넣어서는 안 됩니다.

크롤 수요 체크리스트

진단: 수요인가 용량인가?

• 사이트가 실제로 신경 쓸 만큼 크거나 빠르게 변하는지 확인했다. 아니면 중단한다.
• GSC Crawl Stats에서 호스트 상태가 정상이고 평균 응답 시간이 안정적이며 5xx/시간 초과 급증이 없다.
• 서버 로그나 봇 분석에서 실제 URL별 Googlebot 요청을 검토했다.
• 정상 서버 + 좋은 페이지의 낮은 크롤 양 + “발견됨 - 현재 색인이 생성되지 않음” 패턴은 용량 문제가 아닌 수요 가설이지 증명이 아님을 이해했다.
• 수요를 탓하기 전에 발견, 렌더링, 캐노니컬, 품질/중복, 색인 선택 문제를 배제했다.

직접 조절기는 없으므로 수요 입력 개선

• 인기도: 중요 페이지에 내부 링크가 있고 고아 페이지가 없으며 필요한 곳에서 외부 링크 확보가 진행 중이다.
• 오래됨/신선도: 자주 재크롤링돼야 할 페이지를 실제로 업데이트하고 lastmod를 정확하게 유지한다.
• 인지된 인벤토리: 패싯 탐색, 매개변수, 세션 ID, 무한 URL 공간을 통제하고 스파이더 트랩을 수정하며 중복을 통합했다.

현실 확인

• 빠른 서버가 수요를 높인다고 기대하지 않는다. 서버는 용량 상한만 높인다.
• 가치 없는 URL의 robots.txt 차단이 좋은 페이지로 수요를 즉시 돌린다고 기대하지 않는다. 시간에 따라 집중된다.
• IndexNow/사이트맵 핑으로 Google 수요를 움직이려 하지 않는다. Google은 IndexNow와 changefreq/priority를 무시한다.
• 사이트 이전 뒤 일시적 크롤 급증을 문제가 아닌 예상된 현상으로 본다.
• 크롤링 증가는 목표가 아니며 올바른 우선순위가 목표이고 크롤 양은 순위 요소가 아님을 기억한다.

크롤 수요 요약표

크롤 예산의 두 측면

가장 실행 가능한 세 가지 수요 입력. Google은 사이트 규모, 업데이트 빈도, 페이지 품질, 비교 관련성도 중요한 일반 요소로 제시하므로 폐쇄된 공식은 아닙니다.

핵심 사실

• 크롤 예산 = Googlebot이 크롤링할 수 있고 하려는 URL 수입니다.
• 인지된 인벤토리는 가장 적극적으로 통제할 수 있는 요소입니다.
• 사이트 이전은 새 URL에서 재처리하는 동안 수요를 일시적으로 높입니다.
• 수요가 우선순위를 정하고 호스트 부하 기반 용량이 크롤 깊이를 정합니다. 정상 서버가 수요를 만들지는 않습니다.
• 색인 품질 신호가 개선되면 스케줄러가 “turns up demand”합니다. 링크 외의 유일한 실제 지렛대입니다.
• Google의 목표는 더 많이가 아니라 전체적으로 더 적게 크롤링하는 것입니다(Illyes, 2024). 크롤 양은 순위 요소가 아닙니다.
• 공개된 “크롤 수요 점수”는 없습니다. Crawl Stats는 용량 측면의 활동을 보여 줍니다.
• Bing에는 “크롤 수요” 용어가 없고 크롤 효율성으로 설명합니다. IndexNow는 Google이 아닌 Bing에 변경을 알립니다.

크롤 수요 진단 도구

“수요 측정기”가 없으므로 크롤 활동을 읽고 페이지에 대해 아는 사실과 비교해 진단합니다.

• Google Search Console — Crawl Stats 보고서 — 시간별 총 크롤 요청, 호스트 상태, 평균 응답 시간, 응답 코드·파일 유형·목적·Googlebot 유형별 내역. 용량 보기로 읽으세요. 정상 호스트인데 좋은 페이지의 크롤 양이 낮다면 수요 신호입니다.
• GSC — 페이지 색인 보고서 — **“발견됨 - 현재 색인이 생성되지 않음”**은 전형적인 수요 부족 흔적입니다. Google은 URL을 알지만 아직 크롤링할 만큼 중요하게 보지 않습니다.
• URL 검사(GSC) — 특정 URL의 마지막 크롤 시점과 색인 여부를 확인해 단일 페이지 수요 가설을 검증합니다.
• 서버 로그 파일 분석 — URL별 실제 Googlebot 요청, 빈도, 가치 없는 인벤토리에 낭비되는 크롤링의 근거입니다. 로그 파일 분석을 참고하세요.
• Ahrefs Bot Analytics — 제가 직접 설명할 수 있는 도구입니다. 출시 당시 “Have y’all checked out Bot Analytics in Ahrefs yet? We released a new tool that shows how bots crawl your website. Bot Analytics collects data server-side via Cloudflare integration.” (번역) 봇이 웹사이트를 크롤링하는 방식을 보여 주며 Cloudflare 통합을 통해 서버 측에서 데이터를 수집한다고 소개했습니다. 12개 범주에서 모든 봇과 방문 페이지를 보여 주어 Google의 인지된 인벤토리와 인기도 설명을 실제와 대조할 수 있습니다. Ahrefs는 문제를 “uncontrolled bot traffic wastes crawl budget — bots crawling 404 pages or low-value URLs aren’t crawling the pages you need indexed,” (번역) 통제되지 않은 봇 트래픽이 크롤 예산을 낭비하고 404나 저가치 URL을 크롤링하는 동안 필요한 페이지를 크롤링하지 못한다고 설명하며 전체 크롤러 트래픽의 절반 이상이 낭비된다는 추정치를 인용합니다.
• Ahrefs Site Audit / Screaming Frog SEO Spider — 크롤링을 시뮬레이션해 인지된 인벤토리를 부풀리고 수요를 낮추는 매개변수 확산, 중복, 트랩형 패턴을 찾습니다.

중요도 × 변경 × 인벤토리 프레임워크

크롤 수요 변화를 설명할 때 세 질문을 사용하세요.

1. 중요도: 내부 또는 외부 신호가 URL을 더 중요하거나 덜 중요하게 만들었나요?
2. 변경: 페이지가 의미 있게 바뀌었고 정확한 사이트맵 신호가 이를 전달했나요?
3. 인벤토리: 크롤러가 아는 중복, 매개변수 또는 저가치 URL 집합이 늘었나요?

호스트 상태는 네 번째 수요 입력이 아니라 상한입니다. 로그에 오류나 시간 초과가 보이면 크롤 용량을 별도로 진단하세요. 서버가 정상인데 가치 있는 URL의 크롤 점유율이 줄면 중요도, 변경, 인벤토리 순으로 확인하세요.

디렉터리별 크롤 점유율 비교

다음 셸 파이프라인은 일반 액세스 로그에서 검증된 크롤러 요청을 첫 URL 경로 디렉터리별로 요약합니다.

awk 'BEGIN{IGNORECASE=1} /Googlebot/ {split($7,p,"/"); print "/" p[2] "/"}' access.log | sort | uniq -c | sort -nr

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

Select-String .\access.log -Pattern 'Googlebot' | ForEach-Object { if ($_.Line -match '"(?:GET|HEAD)\s+https?://[^/]+/([^/?\s]*)|"(?:GET|HEAD)\s+/([^/?\s]*)') { '/' + (($Matches[1],$Matches[2] | Where-Object { $_ })[0]) + '/' } } | Group-Object | Sort-Object Count -Descending

변경 전후 같은 길이의 기간을 비교하세요. 특정 디렉터리의 점유율 증가는 스케줄러 배분에 대한 단서이지 품질이나 순위가 높아졌다는 증거는 아닙니다.

크롤 수요 지표

가치 있는 템플릿의 크롤 점유율

지표: 중요 템플릿에 대한 크롤러 요청 ÷ 검증된 전체 크롤러 요청. 의미: 중요한 인벤토리에 수요가 닿는지 보여 줍니다. 확인 방법: 액세스 로그 URL을 템플릿별로 분류합니다. 벤치마크/현실적 범위: 가치 있는 자체 인벤토리와 업데이트 주기에서 목표 조합을 정하세요. 보편적인 비율은 없습니다. 주기: 변화가 많은 대형 사이트는 매주, 그 외는 매월.

의미 있는 변경 후 재크롤링 지연

지표: 실제 페이지 업데이트부터 다음 검증된 크롤러 가져오기까지 시간. 의미: 스케줄러가 페이지 중요도와 변경 패턴을 인식하는지 보여 줍니다. 확인 방법: 배포·콘텐츠 타임스탬프를 액세스 로그와 결합합니다. 벤치마크/현실적 범위: 템플릿별 기준선을 세우세요. 뉴스와 안정적인 참고 페이지는 같은 목표를 가져서는 안 됩니다. 주기: 매월.

저가치 인벤토리 비율

지표: 유용한 URL 대비 알려지고 크롤링된 매개변수, 중복, 빈 페이지, 소프트 404 URL. 의미: 인지된 인벤토리가 관심을 희석하는지 보여 줍니다. 확인 방법: 크롤 내보내기, 사이트맵, 색인 가능성 규칙, 로그를 결합합니다. 벤치마크/현실적 범위: 필요한 리소스를 차단하지 않으면서 사이트 기준선보다 낮추세요. 주기: 매월 및 패싯 탐색·플랫폼 변경 후.

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

제 관련 글

• 언제 크롤 예산을 걱정해야 하나요? — 크롤 예산을 검색엔진이 크롤링하려는 페이지 수인 수요와 속도로 설명하고 인기도, 오래됨 후퇴, 실제 대상 사이트를 다룹니다.
• Googlebot이란 무엇이며 어떻게 작동하나요? — Googlebot이 무엇을 얼마나 크롤링할지 결정하는 방식.
• 기술 SEO 초보자 가이드 — 큰 그림에서 크롤링과 크롤 예산의 위치.

제 강연

• 검색 작동 방식 (SlideShare) — PageRank, 신선도, 마지막 크롤 이후 시간, 대규모 사이트 변경 같은 수요 요소와 별도 용량/호스트 부하 슬라이드를 포함한 크롤링 설명. 고정 면책 문구: “This is my understanding of systems… not going to be 100% complete or accurate.” (번역) 이는 시스템에 대한 제 이해이며 100% 완전하거나 정확하지 않을 수 있습니다.

업계 자료

• Google 크롤링 우선순위: Gary Illyes의 설명 (Search Engine Journal) — 콘텐츠를 가져올 가치가 있다고 설득하는 방식, 수요 증가와 감소에 관한 인용.
• 더 적게 크롤링하려는 Gary Illyes의 목표 (LinkedIn, 2024년 4월) — 더 적은 크롤링·전송 바이트와 더 지능적인 스케줄링에 관한 1차 출처.
• Google의 두 크롤링 유형: 발견과 새로고침 (Search Engine Journal) — 발견·새로고침 크롤에 대한 John Mueller 설명. 새로고침 주기는 순수한 수요 결과입니다.
• Google의 Gary Illyes가 설명하는 크롤 예산·스케줄링·호스트 부하 (Search Engine Roundtable) — 중요도순 URL 버킷과 호스트 부하 설명. 이 글에서는 의역했으며 실제 페이지에서 확인하세요.
• Google: URL 100k개는 크롤 예산에 영향 없음 (Search Engine Roundtable) — John Mueller의 규모 확인 기준. 여기서는 의역했으므로 실제 페이지에서 확인하세요.
• 크롤 예산이란? 작동 방식과 최적화 팁 (Search Engine Land) — 세 가지 수요 요소의 배경을 제공하는 크롤 예산 종합 가이드.
• Ahrefs 봇 분석 — 실제 봇 데이터로 수요와 용량을 진단하고 통제되지 않은 봇 트래픽과 낭비를 설명하는 제품 페이지.

테스트: 크롤 수요

크롤 예산의 “원함” 측면에 관한 다섯 문제입니다. 각각 답을 고른 뒤 확인하세요.

변경 내역