크롤 속도

TL;DR — 크롤 속도는 검색엔진이 사이트의 페이지를 가져오는 속도입니다. Google은 서버 상태를 바탕으로 자동 설정하며 더 이상 사용자가 높이거나 낮추는 버튼은 없습니다. 서버가 과부하라면 성능을 개선하는 것이 근본 해결책이고, 실제 비상 상황에서만 하루나 이틀 동안 “속도를 늦추라”는 오류를 반환할 수 있습니다. 크롤링이 빨라져도 순위가 오르지는 않습니다.

크롤 속도란?

검색엔진은 사이트를 크롤링할 때 모든 페이지를 한꺼번에 가져오지 않고 속도를 조절합니다. 크롤 속도는 크롤러가 일정 시간에 가져오는 페이지 수와 요청 사이의 대기 시간을 뜻합니다. Google에는 Googlebot, Bing에는 Bingbot이 있습니다. Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

속도 조절의 목적은 사이트를 배려하는 것입니다. 크롤러가 초당 수백 페이지를 요청하면 작은 서버는 쉽게 과부하될 수 있으므로, 크롤러는 응답을 관찰하다 서버가 힘들어하면 물러납니다. 빠르게 응답하면 조금 더 빨리 가져오고, 느려지거나 오류가 나면 크롤링을 줄입니다.

크게 달라진 점

오랫동안 “Search Console에서 크롤 속도 슬라이더를 낮추라”는 조언이 통했습니다. 그 슬라이더는 사라졌습니다. Google은 2024년 1월 8일에 제거했습니다. 아직도 조절 방법을 안내하는 글은 오래된 정보입니다. Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation

이제 속도는 자동입니다. 사용자가 다이얼을 돌리는 대신 Google이 서버 응답을 읽고 결정합니다.

Googlebot 속도를 낮추는 방법

서버가 실제로 과부하라면 다음 우선순위를 따르세요.

1. 서버를 더 빠르게 만들거나 자원을 추가하세요. 이것이 근본 해결책입니다. 건강하고 빠른 서버에서는 Googlebot도 자연스럽게 안정적으로 크롤링합니다.
2. 실제 비상 상황에서만: 정상 페이지 대신 500, 503, 429 오류를 반환하세요. Google은 이를 거의 즉시 “속도를 늦추라”는 신호로 읽습니다. 단 최대 하루나 이틀만 사용하세요. 더 오래 지속하면 Google이 검색에서 페이지를 제외하기 시작할 수 있습니다.

하지 말아야 할 일도 있습니다. 403/404 오류로 Googlebot을 차단하지 마세요. 속도는 느려지지 않고 페이지를 잃을 위험만 생깁니다. robots.txt의 crawl-delay에도 의존하지 마세요. Google은 이를 무시하지만 Bing은 준수합니다.

Google의 크롤링을 더 빠르게 만들 수 있나요?

원할 때 바로 높일 수는 없습니다. “더 크롤링” 버튼도 없고 증가를 요청할 수도 없습니다. 더 빠른 서버, 깔끔한 사이트맵, 좋은 내부 링크, 중복·저가치 URL 제거로 간접적으로 유도할 수 있습니다. 그러나 크롤링 증가는 그 자체로 목표가 아니며 순위를 높여 주지 않습니다.

상태 코드의 세부 사항, 지원 종료 과정, Bing과의 차이를 보려면 고급 탭으로 전환하세요.

TL;DR — 크롤 속도는 크롤 예산의 공급 측면으로, 크롤러가 페이지를 얼마나 빨리 가져오는지를 뜻합니다. Google이 말하는 크롤 용량 제한(병렬 연결 + 요청 사이 지연)이 이를 정합니다. 서버 상태에 반응해 자동 조정되며 GSC 수동 슬라이더는 2024년 1월 8일에 제거됐습니다. 이제 Googlebot을 늦추려면 HTTP로 신호를 보냅니다. 500/503/429는 최대 1~2일만 사용하고 401/403/404는 쓰지 마세요. Google은 crawl-delay를 무시하지만 Bing은 준수합니다. 증가를 직접 요청할 수 없고 간접적으로 개선해야 합니다. Bing에는 여전히 수동 Crawl Control 그리드가 있습니다. 크롤 속도는 순위 요소가 아니며 대부분의 사이트는 건드릴 필요가 없습니다.

크롤 속도의 정확한 의미

크롤 속도는 크롤러가 서버에서 페이지를 가져오는 속도, 즉 동시 요청 수와 요청 사이의 지연입니다. Google은 이를 크롤 용량 제한이라고 부르며 “the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (번역) Google이 사이트 크롤링에 사용할 수 있는 최대 동시 병렬 연결 수와 가져오기 사이의 시간 지연이라고 정의합니다. Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

이는 크롤 예산의 절반입니다. 제 Ahrefs 크롤 예산 가이드에서는 크롤 예산을 “crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” (번역) 검색엔진이 사이트에서 크롤링하려는 페이지 수인 크롤 수요와 얼마나 빨리 크롤링할 수 있는지를 나타내는 크롤 속도로 나눕니다. 크롤 속도는 허용 가능한 속도인 공급 측면이고, 크롤 수요는 원하는 양인 수요 측면입니다. 크롤 예산은 둘이 만나는 지점이며 순위는 이 순환 밖에 있습니다.

제 검색 작동 방식 발표 자료에서는 크롤 속도 제한을 단순히 사이트가 감당할 수 있는 양으로 설명합니다. 서버 안정성과 크롤 상태, 느린 응답, 5xx 서버 오류, 429 요청 과다 응답이 좌우합니다. Google은 사이트를 중단시키지 않으려고 서버가 힘들어하면 물러납니다. 놓치기 쉬운 점은 모든 Googlebot이 하나의 크롤 풀을 공유한다는 것입니다. 검색·이미지·광고 등의 봇이 같은 속도 풀을 쓰므로 한 리소스 유형의 폭주가 다른 모든 크롤링을 잠식합니다.

크롤 속도를 정하는 요소

용량 제한은 자동이며 서버에 실시간으로 반응합니다. Google은 “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (번역) 사이트가 한동안 빠르게 응답하면 더 많은 연결을 사용할 수 있도록 한도가 올라가고, 느려지거나 서버 오류를 반환하면 한도가 내려가 Google이 덜 크롤링한다고 설명합니다.

통제할 수 없는 두 번째 제약은 Google 자체의 자원입니다. “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (번역) Google에는 많은 머신이 있지만 무한하지 않으므로 보유 자원 안에서 선택해야 합니다. 서버 상태는 Google이 사용하려는 상한을 정하지만 실제 사용량은 Google의 자체 용량과 사이트의 크롤 수요가 결정합니다.

오해와 사실 문서는 서버 상태의 영향이 양방향임을 확인합니다. “A speedy site is a sign of healthy servers, so it can get more content over the same number of connections,” (번역) 빠른 사이트는 건강한 서버의 신호이므로 같은 연결 수로 더 많은 콘텐츠를 가져올 수 있습니다. 반대로 “a significant number of 5xx HTTP response status codes (server errors) or connection timeouts signal the opposite, and crawling slows down.” (번역) 많은 5xx 응답이나 연결 시간 초과는 반대 신호여서 크롤링이 느려집니다.

크롤 속도가 순위에 영향을 주나요? 아니요.

잘못된 작업을 많이 낳는 오해부터 없애겠습니다. 검색에 나타나려면 크롤링이 필요하지만 순위 신호는 아닙니다. Google은 “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (번역) 크롤 속도를 개선해도 Google 검색 순위가 반드시 좋아지는 것은 아니라고 명시합니다. 더 빠르거나 많은 크롤링은 발견과 색인을 더 최신으로 만들 뿐 순위를 높이지 않습니다. 크롤 속도는 오직 효율성과 서버 상태의 문제입니다.

Googlebot의 크롤 속도를 낮추는 방법

근본 해결책부터 비상 수단까지 순서대로 살펴보겠습니다.

1. 서버를 고치세요(근본 해결책). 속도를 높이거나 자원을 추가하세요. 용량 제한은 응답 시간과 오류를 따라가므로 더 건강한 서버가 크롤링을 안정적인 범위에 두는 지속 가능한 방법이며 색인을 위험에 빠뜨리지 않는 유일한 방법입니다.

2. 비상 수단 — 500/503/429. Google은 크롤 요청에 200 대신 “return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (번역) 500, 503, 429 HTTP 상태 코드를 반환하라고 합니다. 크롤러는 “treat the 429 status code as a signal that the server is overloaded,” (번역) 429를 서버 과부하 신호로 보고, “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (번역) 5xx와 429 오류를 받으면 일시적으로 속도를 낮춥니다. Gary Illyes는 “if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (번역) 여러 URL에서 HTTP 500이 계속 반환되면 Googlebot이 자동으로 거의 즉시 느려진다고 설명했습니다. 가능하면 **429**를 우선하세요. “요청 과다”를 명시하고 Retry-After 헤더를 담을 수 있습니다.

단, 이는 엄격히 일시적인 수단입니다. Google은 “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (번역) 1~2일보다 오래 사용하지 말라고 합니다. 같은 URL에서 여러 날 지속되면 “the URL may be dropped from Google’s index” (번역) URL이 Google 색인에서 제외될 수 있고, Google Ads에서는 “your campaigns may be cancelled or paused, and your ads may not serve.” (번역) 캠페인이 취소·일시중지되고 광고가 게재되지 않을 수 있습니다.

3. 하지 말아야 할 일. 속도 제한에 4xx를 쓰지 마세요. “The 4xx status codes, except 429, have no effect on crawl rate,” (번역) 429를 제외한 4xx는 크롤 속도에 영향을 주지 않으며 Google은 “Don’t use 401 and 403 status codes for limiting the crawl rate.” (번역) 속도 제한에 401과 403을 쓰지 말라고 명시합니다. 2023년 전용 글에서는 “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate. The short version of this blog post is: please don’t do that…” (번역) 사이트 소유자와 일부 CDN이 404 등 4xx로 Googlebot 속도를 낮추려는 사례가 늘었지만 그러지 말라고 경고했습니다. robots.txt의 crawl-delay도 쓰지 마세요. “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (번역) Google 크롤러는 비표준 crawl-delay 규칙을 처리하지 않습니다.

4. 비상이 아닌 요청. 화재 수준은 아니지만 지속되는 문제라면 “file a special request to report a problem with unusually high crawl rate, mentioning the optimal rate for your site.” (번역) 비정상적으로 높은 크롤 속도 문제와 사이트의 적정 속도를 적어 특별 요청을 제출할 수 있습니다. 처리 속도가 느리고 낮추는 방향으로만 작동합니다.

크롤 속도를 높일 수 있나요? 직접은 불가능합니다.

수동 증가는 없습니다. Google은 “You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (번역) 크롤 속도 증가를 요청할 수 없고 요청 평가와 처리에는 며칠이 걸릴 수 있다고 합니다. 대신 간접적으로 개선할 수 있습니다. 제 크롤 예산 가이드의 실제 지렛대는 서버 속도·자원 개선, 중요한 페이지를 깔끔한 사이트맵에 유지, 중복 제거, 외부·내부 링크 확보, 리디렉션 링크 수정, 가능한 곳에서 POST 대신 GET 사용, 자격이 있을 때 Indexing API 사용입니다. “a speedy site… can get more content over the same number of connections” (번역) 빠른 사이트는 같은 연결 수로 더 많은 콘텐츠를 가져올 수 있으므로 서버 상태는 감소와 증가 양쪽에 영향을 줍니다.

Bingbot 크롤 속도를 제어하는 방법

두 검색엔진의 차이는 뚜렷합니다. Google은 수동 제어를 없앴지만 Bing은 유지했습니다. Bing Webmaster Tools의 Configuration 아래에는 Crawl Control이 있습니다. 시간별 벽돌 수로 속도를 표시하며 벽돌이 많을수록 빠르고 적을수록 느립니다. 피크 영업시간에 맞춘 프리셋을 고르거나 Custom으로 하루 패턴을 직접 그릴 수 있습니다. Bing은 Google이 무시하는 robots.txt의 crawl-delay도 준수합니다. 즉 Google에는 서버 응답으로 신호를 보내고 Bing에는 실제 다이얼을 사용합니다.

Search Console 크롤 속도 도구에는 무슨 일이 있었나요?

사라진 도구를 여전히 언급하는 조언이 많으므로 시간순으로 정리합니다.

• 2008년 12월 — Google이 Webmaster Tools에 사용자 크롤 속도 제어를 도입했습니다.
• 2023년 2월 — Google이 “속도 제한에 403이나 404를 쓰지 말라”는 글을 게시했습니다.
• 2023년 11월 24일 — Google이 Crawl Rate Limiter Tool 지원 종료를 발표했습니다. Illyes는 “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (번역) 크롤링 로직 개선과 게시자용 다른 도구로 유용성이 사라졌다고 설명했습니다. 기존 도구는 효과가 “a much slower effect” (번역) 훨씬 느렸고 새 한도가 크롤링에 적용되기까지 “would have taken over a day for the new limits to be applied on crawling,” (번역) 하루 넘게 걸렸습니다. 사용 빈도도 “rarely,” (번역) 드물었으며 사용자는 “in many cases set the crawling speed to the bare minimum.” (번역) 많은 경우 속도를 최저로 설정했습니다.
• 2024년 1월 8일 — 도구가 제거됐습니다. Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation Google은 최저치도 낮추며 “With the deprecation of the crawl limiter tool, we’re also setting the minimum crawling speed to a lower rate, comparable to the old crawl rate limits.” (번역) 기존 한도와 비슷한 더 낮은 최저 크롤 속도를 설정한다고 밝혔습니다.

실무적인 결론은 기존 수동 슬라이더도 24시간 넘게 지연됐다는 것입니다. 현재의 서버 신호 방식(5xx/429)은 Googlebot을 거의 즉시 늦추므로 실제 비상 상황에는 더 낫습니다.

크롤 속도 모니터링 방법

GSC Crawl Stats 보고서는 Google의 실제 동작을 보여 줍니다. 시간별 총 크롤 요청, 총 다운로드 크기, 평균 응답 시간, 최근 약 90일 동안 Google에서 본 사이트 가용성을 나타내는 호스트 상태, 응답 코드·파일 유형·크롤 목적·Googlebot 유형별 내역을 확인할 수 있습니다. 평균 응답 시간과 호스트 상태를 보세요. 응답 시간 상승이나 5xx 급증은 Googlebot이 속도를 낮추는 정확한 원인이므로 스스로 만든 감속을 여기서 먼저 찾을 수 있습니다. Bing에서는 Crawl Control과 Bing Webmaster Tools의 크롤 정보가 대응 기능입니다.

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

다음 개념을 구분하세요.

• 크롤 속도 = 얼마나 빠른지(공급/용량).
• 크롤 수요 = 얼마나 원하는지(인기도 + 오래됨).
• 크롤 예산 = 두 요소의 상호작용, 즉 “the amount of time and resources a search engine allows for crawling a website.” (번역) 검색엔진이 웹사이트 크롤링에 허용하는 시간과 자원의 양입니다.
• 크롤 빈도 = 특정 페이지를 얼마나 자주 재크롤링하는지로, 주로 인기도와 페이지의 최신성·오래됨에 따른 수요 문제입니다.

안심할 부분도 있습니다. 제 일관된 견해는 대부분의 사이트가 이를 걱정할 필요가 없다는 것입니다. “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look” (번역) 대부분은 크롤 예산을 걱정할 필요가 없지만 살펴볼 만한 몇 가지 경우가 있습니다. 페이지가 많은 신규 사이트, 매우 크거나 빠르게 변하는 사이트, GSC에 “발견됨 - 현재 색인이 생성되지 않음” URL이 많이 쌓인 사이트입니다. 해당하지 않으면 크롤 속도를 그대로 두고 Google 자동화에 맡기세요.

AI 요약

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

• 크롤 속도 = 크롤러가 페이지를 가져오는 속도입니다. 병렬 연결과 요청 사이 지연으로 구성된 “크롤 용량 제한”이며 크롤 예산의 공급 측면입니다. 크롤 수요는 수요 측면입니다.
• 자동이며 서버 상태에 반응합니다. 건강하고 빠른 서버에서는 한도가 높아지고 느린 응답이나 5xx/429에서는 Google이 덜 크롤링합니다. Google 자체 용량도 통제할 수 없는 두 번째 상한입니다. 모든 Googlebot은 하나의 크롤 풀을 공유합니다.
• GSC 수동 속도 슬라이더는 2024년 1월 8일에 제거됐습니다. 슬라이더 조절 조언은 오래됐습니다.
• 현재 Googlebot을 늦추는 방법: 서버를 고치는 것이 최선이며, 500/503/429는 최대 1~2일만 사용하세요. 더 오래 쓰면 색인 제외와 Ads 중단 위험이 있습니다. Retry-After를 담는 429를 우선하고 401/403/404는 절대 쓰지 마세요. Google은 crawl-delay를 무시합니다.
• 증가를 요청할 수 없습니다. 더 빠른 서버, 깨끗한 사이트맵, 중복·저가치 URL 감소, 내부·외부 링크, 자격이 있을 때 Indexing API로 간접 개선하세요.
• Bing은 수동 제어를 유지합니다. 시간별 Crawl Control 그리드와 crawl-delay를 지원합니다.
• 크롤 속도는 순위 요소가 아닙니다. Google의 표현대로 “improving your crawl rate won’t necessarily lead to better positions.” (번역) 크롤 속도를 개선해도 순위가 반드시 좋아지지는 않습니다. 대부분의 사이트는 관리할 필요가 없습니다.

공식 문서

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

Google

• Googlebot 크롤 속도 낮추기 — 핵심 방법인 500/503/429, 1~2일 제한, 낮출 수만 있는 요청 양식.
• 크롤 예산 관리 — 크롤 용량 제한과 서버 상태에 대한 반응을 정의합니다.
• HTTP 상태 코드가 Google 크롤러에 미치는 영향 — 크롤링을 늦추는 5xx/429와 늦추지 않는 429 외 4xx.
• 크롤링에 관한 오해와 사실 — crawl-delay 미지원, 크롤 속도와 순위의 차이, 서버 상태의 영향.
• Crawl Rate Limiter Tool 지원 종료 예정(2023년 11월) — 지원 종료 발표.
• 403s·404s로 크롤 속도를 제한하지 마세요(2023년 2월) — 4xx가 잘못된 수단인 이유.
• 새로 개선된 사이트 크롤 통계(2020년 11월) — Crawl Stats 보고서 읽는 법.
• 크롤 예산 최적화 — 용량과 수요, 실제 대상 사이트.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — Google이 없앤 수동 시간별 크롤 속도 그리드.
• Bingbot 지침 — 현재 Bing Webmaster 지침은 1~20초의 crawl-delay 값을 문서화합니다.
• bingbot 시리즈: 크롤 빈도 최적화(2018년 10월) — 재방문 시점에 관한 Bing의 설명.

출처 인용문

Google의 공개 발언입니다. 각 링크는 출처 페이지의 해당 구절로 이동합니다.

Google — 크롤 속도의 의미와 결정 요소

• “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (번역) 사이트가 한동안 빠르게 응답하면 한도가 올라가고, 느려지거나 서버 오류를 반환하면 한도가 내려가 Google이 덜 크롤링합니다. — 크롤 예산 관리. 인용문으로 이동
• “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (번역) Google의 머신도 무한하지 않아 가진 자원으로 선택해야 합니다. 인용문으로 이동

Google — 크롤 속도를 낮추는 방법

• “return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (번역) 크롤 요청에 200 대신 500, 503, 429 HTTP 상태 코드를 반환하세요. — Googlebot 크롤 속도 낮추기. 인용문으로 이동
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (번역) 1~2일보다 오래 사용하지 않는 것이 좋습니다. 인용문으로 이동
• “You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (번역) 크롤 속도 증가를 요청할 수 없으며 요청 평가와 처리에 며칠이 걸릴 수 있습니다. 인용문으로 이동

Google — 크롤링을 늦추는 상태 코드

• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (번역) Google 크롤러는 429를 서버 과부하 신호이자 서버 오류로 취급합니다. — HTTP 상태 코드가 Google 크롤러에 미치는 영향. 인용문으로 이동
• “The 4xx status codes, except 429, have no effect on crawl rate.” (번역) 429를 제외한 4xx 상태 코드는 크롤 속도에 영향을 주지 않습니다. / “Don’t use 401 and 403 status codes for limiting the crawl rate.” (번역) 크롤 속도 제한에 401과 403을 쓰지 마세요. 인용문으로 이동

Google — crawl-delay와 순위

• “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (번역) Google 크롤러는 robots.txt의 비표준 crawl-delay 규칙을 지원하지 않습니다. — 크롤링에 관한 오해와 사실. 인용문으로 이동
• “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (번역) 크롤 속도를 개선해도 Google 검색 순위가 반드시 좋아지지는 않습니다. 인용문으로 이동

Gary Illyes, Google (크롤 속도 도구 지원 종료에 관해)

• “if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (번역) 여러 URL에서 HTTP 500이 계속 반환되면 Googlebot이 자동으로 거의 즉시 크롤링을 늦춥니다. 보도 읽기
• “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (번역) 크롤링 로직 개선과 게시자용 다른 도구로 유용성이 사라졌습니다. 보도 읽기

크롤 속도 체크리스트

Googlebot 크롤 속도를 안전하게 낮추기(순서대로)

• 먼저 크롤러가 실제 문제인지 확인한다. 추측이 아니라 GSC Crawl Stats(평균 응답 시간, 호스트 상태)와 서버 로그를 본다.
• 근본 원인을 고친다. 서버 속도를 높이거나 자원을 추가한다. 색인을 위험에 빠뜨리지 않는 지속 가능한 유일한 해결책이다.
• 실제 비상 상황이면 크롤 요청에 500/503/429를 반환한다. Retry-After가 있는 429를 우선하며 Googlebot은 거의 즉시 느려진다.
• 비상 응답은 최대 1~2일만 유지한다. 더 길면 페이지가 색인에서 제외되고 Ads가 중단될 수 있다.
• 지속되는 비상 아닌 문제는 사이트의 적정 속도를 적어 Google 특별 요청을 제출한다.
• Bing에서는 Crawl Control로 속도를 설정하거나 robots.txt에 crawl-delay를 추가한다.

하지 말아야 할 일

• 401/403/404로 속도를 제한하지 않는다. 속도에는 효과가 없고 페이지를 잃을 수 있다.
• Google에 robots.txt의 crawl-delay를 기대하지 않는다. Google은 무시하고 Bing은 준수한다.
• 2024년 1월 8일 제거된 예전 GSC 크롤 속도 슬라이더를 찾지 않는다.

더 많은 크롤링을 원할 때(강제할 수 없으므로 간접 개선)

• 서버 속도를 높이거나 자원을 추가한다.
• 캐노니컬·색인 가능 URL을 정확한 lastmod와 함께 깔끔한 사이트맵에 유지한다.
• 크롤링을 낭비하는 중복·저가치 URL을 제거한다.
• 내부 링크를 강화하고 외부 링크를 얻는다.
• 가능한 곳에서 POST 대신 GET을 사용하고 자격이 있으면 Indexing API를 사용한다.

크롤 속도 요약표

상태 코드가 Google 크롤 속도에 미치는 영향

핵심 사실

• 크롤 속도 = 얼마나 빠른지(공급), 크롤 수요 = 얼마나 원하는지(수요), 크롤 예산 = 둘의 결합입니다.
• Google 용어는 병렬 연결 + 요청 사이 지연인 크롤 용량 제한입니다. 서버 상태를 따라 자동 조정됩니다.
• 비상 5xx/429 사용 기간은 최대 1~2일이며 더 길면 색인 제외와 Ads 중단 위험이 있습니다.
• 수동 증가는 없습니다. Google에는 낮춰 달라고만 요청할 수 있고 높여 달라고 요청할 수 없습니다.
• GSC 수동 크롤 속도 슬라이더는 2023년 11월 24일 발표 후 2024년 1월 8일 제거됐습니다.
• 모든 Googlebot은 검색·이미지·광고 등을 포함해 하나의 크롤 풀을 공유합니다.
• 크롤 속도는 순위 요소가 아닙니다.
• Bing 대응 기능은 Crawl Control 그리드와 지원되는 crawl-delay입니다.

Googlebot에 일시적으로 속도를 늦추라고 알리기

이는 비상 수단 전용입니다. 크롤러에 200 대신 Retry-After 헤더와 함께 503 또는 429를 반환하세요. Google은 이를 거의 즉시 “속도를 늦추라”는 뜻으로 읽습니다. 최대 하루나 이틀만 유지하세요. 더 길면 영향받은 URL이 색인에서 제외되고 연결된 Google Ads가 중단될 수 있습니다. 장기적인 해결책은 영구 오류 응답이 아니라 더 빠르고 건강한 서버입니다.

Apache (.htaccess) — Retry-After와 함께 503 반환

# Emergency only — remove within 1–2 days.
# Sends Googlebot a "slow down / try later" signal.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Googlebot|bingbot) [NC]
RewriteRule ^ - [R=503,L]
Header always set Retry-After "3600"
ErrorDocument 503 "Server temporarily overloaded — please retry later."

Nginx — 크롤러에 Retry-After와 함께 503 반환

# Emergency only — remove within 1–2 days.
if ($http_user_agent ~* (Googlebot|bingbot)) {
    return 503;
}
# Send a Retry-After hint with the 503 response.
add_header Retry-After 3600 always;

Express / Node.js — Retry-After와 함께 429 Too Many Requests 반환

// Emergency only — remove within 1–2 days.
// 429 explicitly means "too many requests" and carries a Retry-After.
app.use((req, res, next) => {
  const ua = req.get("user-agent") || "";
  if (/Googlebot|bingbot/i.test(ua)) {
    res.set("Retry-After", "3600"); // seconds
    return res.status(429).send("Too many requests — please retry later.");
  }
  next();
});

다시 말해 이 방법은 크롤링을 일시적으로 늦출 뿐입니다. 색인을 일시중지하거나 차단하는 방법도, 서버 용량을 고치는 일을 대신하는 방법도 아닙니다.

크롤 속도를 확인하고 제어하는 도구

• Google Search Console — Crawl Stats 보고서 — 시간별 총 크롤 요청, 총 다운로드 크기, 평균 응답 시간, 약 90일 동안 Google에서 본 사이트 가용성인 호스트 상태, 응답 코드·파일 유형·크롤 목적·Googlebot 유형별 내역을 보여 줍니다. 속도 제한이 실제로 나타나는 곳입니다.
• Bing Webmaster Tools — Crawl Control — 시간대별 Bingbot 속도를 프리셋 또는 직접 그린 패턴으로 설정하는 수동 그리드입니다. Google이 없앤 수동 제어입니다.
• robots.txt crawl-delay — Bing 등 일부 엔진은 준수하고 Google은 무시합니다. Bing에는 유용하지만 Google에는 쓸모없습니다.
• 서버 로그 파일 분석 — 봇이 실제로 얼마나 빠르게 요청하고 어떤 상태 코드를 받는지 보여 주는 근거입니다. 로그 파일 분석을 참고하세요.
• 사이트 감사/크롤러 — Ahrefs Site Audit과 Screaming Frog SEO Spider로 크롤링을 낭비하는 중복, 매개변수, 트랩형 URL을 찾습니다.

크롤 속도에 관해 무엇을 해야 하나요?

사고 대응 절차: 크롤러 트래픽이 오리진에 과부하를 일으킬 때

1. 봇을 검증합니다. 출발 IP가 주장된 크롤러 소유인지 확인합니다. 아니면 일반 보안 제어로 사칭 봇을 차단하거나 속도를 제한하세요.
2. 영향을 측정합니다. 크롤러 요청과 지연, 포화, 시간 초과, 5xx 응답의 상관관계를 확인합니다. 맞지 않으면 실제 부하 원인을 조사하세요.
3. 가용성을 보호합니다. 필요한 트래픽만 줄이세요. Googlebot의 일시적 비상 상황에는 403/404가 아니라 429 또는 503을 사용합니다.
4. 과열 패턴을 찾습니다. 디렉터리, 매개변수, 응답 코드, 바이트별로 요청을 묶습니다. 폭주 URL 공간이 대부분이면 링크나 생성 규칙을 고치세요.
5. 원인을 고칩니다. 용량을 늘리고 안전한 응답을 캐시하며 크롤러 트랩을 제거하거나 해당 크롤러의 지원 제어를 사용합니다.
6. 복구하고 검증합니다. 임시 제한을 제거한 뒤 사용자 지연과 크롤러 오류율이 사이트 기준선으로 돌아왔는지 확인합니다.

크롤 속도 관련 실수

• Googlebot에 crawl-delay 사용. Google은 무시합니다. 비상 상황에서만 일시적 429/503 응답을 사용하고 근본 부하를 고치세요.
• Googlebot을 늦추려고 403 또는 404 반환. 이 상태는 일시적 과부하가 아니라 접근 거부나 부재를 뜻합니다. 올바른 임시 신호를 사용하세요.
• 영구 증가 강제 시도. Search Console 슬라이더는 사라졌고 크롤링 증가는 순위를 높이지 않습니다. 서버 상태와 수요 신호를 개선하세요.
• 사용자 에이전트 문자열 신뢰. 사칭 봇도 Googlebot이라고 주장할 수 있습니다. 사이트 동작을 바꾸기 전에 IP를 확인하세요.
• 비상 속도 제한을 계속 유지. 장기 오류는 크롤링과 색인을 해칠 수 있습니다. 배포 전에 담당자와 제거 조건을 정하세요.

검증 → 보호 → 복구 프레임워크

• 검증: 트래픽이 실제 크롤러이며 서버 피해와 상관관계가 있음을 입증합니다.
• 보호: 사용자 가용성을 지키면서 올바른 HTTP 의미를 전달하는 가장 좁은 임시 제어를 사용합니다.
• 복구: 용량 병목이나 폭주 URL 공간을 없앤 뒤 임시 제어를 철회합니다.

크롤 속도와 크롤 수요를 구분하세요. 건강한 서버는 용량 상한을 높일 수 있지만 검색엔진이 더 많은 URL을 원하게 만들 수는 없습니다.

크롤 속도 개입의 효과 입증

임시 속도 제한 응답

실행할 테스트: 제한 대상 테스트 URL에 curl -I를 요청합니다. 예상 결과: 계획한 429 또는 503이 사고 중에만 나타나고 정상 URL은 계속 이용 가능합니다. 실패 해석: 규칙 범위가 잘못됐거나 잘못된 상태를 반환하고 있습니다. 모니터링 기간: 즉시. 롤백 기준: 사용자나 관련 없는 봇이 예기치 않게 제한 응답을 받습니다.

제한 제거 후 복구

실행할 테스트: 헤더 검사를 반복하고 서버와 액세스 로그를 모니터링합니다. 예상 결과: 정상 200 응답이 돌아오고 크롤러 오류가 줄며 사용자 지연이 기준선에 머뭅니다. 실패 해석: 임시 규칙이 여전히 활성 상태이거나 용량 문제가 지속됩니다. 모니터링 기간: HTTP 동작은 즉시 확인하고 다음 정상 크롤 기간까지 계속합니다. 롤백 기준: 포화나 5xx가 다시 나타나면 사고 계획으로 돌아갑니다.

URL 공간 복구

실행할 테스트: 과도한 요청을 일으킨 매개변수나 경로 패턴을 크롤링하고 로그로 확인합니다. 예상 결과: 새로운 트랩 URL이 더 이상 생성되거나 연결되지 않고 가치 있는 URL은 접근 가능합니다. 실패 해석: 다른 발견 경로가 여전히 패턴을 노출합니다. 모니터링 기간: 동등한 로그 기간을 비교합니다. 롤백 기준: 가치 있는 페이지나 필요한 리소스에 접근할 수 없게 됩니다.

크롤 속도 상태 지표

검증된 크롤러 요청 속도

지표: 검증된 크롤러 IP의 시간 단위당 요청 수. 의미: 실제 크롤러 속도를 보여 줍니다. 확인 방법: 봇 검증 후 액세스 로그를 조회합니다. 벤치마크/현실적 범위: 크롤러와 트래픽 기간별 기준선을 세우세요. 보편적인 안전 속도는 없습니다. 주기: 사고 중 매일, 그 외에는 매월.

크롤러와 연관된 오류·지연 비율

지표: 크롤러 활동 중 5xx/시간 초과와 오리진 지연. 의미: 속도가 용량을 초과하는지 보여 줍니다. 확인 방법: 서버 원격 측정과 크롤러 로그 타임스탬프를 맞춥니다. 벤치마크/현실적 범위: 사이트의 정상 비사고 기준선과 용량 목표를 사용합니다. 주기: 중요 사이트는 지속 경고.

유용한 요청 비율

지표: 가치 있는 200 페이지에 대한 검증된 크롤러 요청과 리디렉션·오류·알려진 트랩 URL의 비율. 의미: 용량이 생산적으로 쓰이는지 보여 줍니다. 확인 방법: 로그 URL과 상태를 분류합니다. 벤치마크/현실적 범위: 사이트 자체 인벤토리 대비 추세를 보고 보편적 목표는 피하세요. 주기: 매월.

테스트: 크롤 속도

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

제 관련 글

• 언제 크롤 예산을 걱정해야 하나요? — 크롤 예산의 절반인 크롤 속도와 감소·증가 지렛대.
• Googlebot이란 무엇이며 어떻게 작동하나요? — Googlebot이 속도와 대상을 정하는 방식, 그리고 이제 지원 종료된 “크롤 속도 변경”.
• 기술 SEO 초보자 가이드 — 더 큰 그림에서 크롤링과 크롤 속도의 위치.

제 강연

• 검색 작동 방식 (SlideShare) — 크롤 속도 제한을 “사이트가 감당할 수 있는 양”으로 설명하고 모든 Googlebot이 하나의 크롤 풀을 공유한다고 언급합니다. 고정 면책 문구: “This is my understanding of systems… not going to be 100% complete or accurate.” (번역) 이는 시스템에 대한 제 이해이며 100% 완전하거나 정확하지 않을 수 있습니다.

다른 자료

• Search Engine Land — Googlebot 크롤 속도 도구 지원 종료와 도구 제거 완료 — Illyes의 설명을 포함한 지원 종료 과정.
• Google의 Crawling December 시리즈 — 집중적으로 모아 둔 공식 크롤링 설명 자료.
• Search Engine Journal — Search Console에서 Crawl Rate Limiter Tool 제거 — 2023년 11월 지원 종료와 자동 설정 최저 속도를 전한 Roger Montti의 보도.
• Search Engine Journal — Googlebot 속도 제한에 클라이언트 오류를 쓰지 마세요 — 4xx로 크롤링 속도를 낮추지 말라는 Google의 2023년 2월 글 보도.
• Bing Webmaster Blog — bingbot 시리즈: 크롤 빈도 최적화 — Bingbot이 재방문 시점을 정하는 방식에 관한 Bing의 설명.
• Bing Webmaster Blog — Bing Webmaster Tools로 Bingbot 최대한 활용하기 — Crawl Control과 다른 BWT 설정으로 Bingbot 속도를 관리하는 방법.

변경 내역