크롤링 속도 제어 가이드, Retry-After까지

서버가 갑자기 버거워졌을 때 구글봇의 방문 속도를 낮추는 공식 방법은 딱 하나다. 응답 코드를 500·503·429 중 하나로 바꿔 보내는 것이다. robots.txt에 크롤링 속도를 적어 넣는 방법은 구글에는 통하지 않는다.

2026년 10월, 구글은 이 내용을 담은 "크롤링 속도 낮추기" 문서를 손봤다. 핵심 변화는 긴급 상황 섹션에 Retry-After HTTP 헤더 사용법을 명시적으로 추가한 것이다. 다만 이것이 완전히 새로운 기능은 아니라는 점부터 분명히 해 둔다.

이번 업데이트는 새로운 스로틀링 방식이 등장한 것이 아니라, 기존에도 쓸 수 있던 안내를 찾기 쉬운 자리로 재배치하고 명확히 설명한 것에 가깝다. 실무자가 헷갈리지 않도록 이 글에서 정확히 구분해 다룬다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• robots.txt의 크롤 지연(crawl-delay) 지시어는 구글이 2019년부터 공식적으로 지원하지 않는다 — 다른 방법을 써야 한다
• 긴급히 속도를 낮춰야 할 때는 500·503·429 중 하나를 반환해야 하며, 세 코드의 쓰임이 조금씩 다르다
• 2026년 10월 문서 업데이트로 Retry-After 헤더의 두 가지 값 형식(지연 초·절대 날짜)이 긴급 섹션에 명시적으로 들어갔다
• 이 방법은 1–2일 이내의 단기 처방이며, 길게 끌면 해당 URL이 색인에서 빠질 위험이 있다
• 크롤링 속도와 크롤 버짓은 같은 말이 아니다 — 서로 다른 질문에 답하는 개념이다

조금 더 풀어 말하면, 이 글은 "서버가 느려졌다"는 모든 상황에 다 적용되는 글이 아니다. 평상시 크롤 효율을 높이는 문제라면 크롤 버짓 관점으로 접근해야 하고, 지금 당장 서버가 다운될 위기라면 긴급 조치가 필요하다. 두 상황을 가르는 기준부터 짚고 들어간다.

크롤링 속도란 정확히 무엇인가?

크롤링 속도는 구글봇이 특정 사이트에 초당 몇 건의 요청을 보낼지 구글이 자체 알고리즘으로 정한 값이다. 사이트 운영자가 숫자를 직접 설정하는 항목이 아니다.

구글은 이 값을 정할 때 두 가지를 동시에 본다. 하나는 서버가 버틸 수 있는 한계(크롤 용량 한도), 다른 하나는 구글이 그 사이트를 얼마나 자주 다시 와서 볼 필요가 있는지(크롤 수요)다. 서버 응답이 빠르고 오류가 없으면 구글은 더 많이 가져가도 된다고 판단해 속도를 자연스럽게 높인다.

반대로 응답이 느려지거나 오류가 늘면 구글은 스스로 속도를 낮춘다. 구글봇은 사이트를 다운시키지 않으려고 알아서 조심하는 쪽으로 설계돼 있다. 하지만 이 자동 조절에는 시간이 걸리기 때문에, 지금 당장 서버가 위험하다면 사이트 운영자가 능동적으로 신호를 보내야 한다.

평소에 느껴지는 "너무 자주 온다"는 불편함과, 서버가 실제로 과부하로 다운되기 직전인 긴급 상황은 처방이 다르다. 이 둘을 섞어서 접근하면 엉뚱한 해결책을 쓰게 된다.

robots.txt로 크롤링 속도를 낮출 수 있을까?

결론부터 말하면 안 된다. 일부 검색엔진(빙, 얀덱스 등)은 robots.txt에 Crawl-delay 지시어를 적으면 그대로 따르지만, 구글은 2019년에 이 지시어를 공식적으로 지원하지 않는다고 밝혔다. 이후 지금까지 이 방침은 바뀌지 않았다.

당시 구글은 noindex, nofollow와 함께 crawl-delay도 robots.txt에서 지원을 중단한다고 공지했다. 이유는 간단하다. 비표준 지시어를 구글봇마다 다르게 해석하게 두면 전체 생태계가 혼란스러워진다는 것이었다.

국내 실무에서 흔한 오해 — 나쁜 예 vs 좋은 예

상황	나쁜 예	좋은 예
서버가 가끔 느려짐	robots.txt에 Crawl-delay: 10 추가	호스팅 등급 상향·캐시 적용으로 응답 속도 자체를 개선
특정 구간만 느림(필터·검색 결과)	전체 사이트 속도를 낮추려 함	해당 패턴만 Disallow로 크롤링 자체를 차단
서버가 당장 위험	아무 조치 없이 방치	500·503·429 응답 + Retry-After로 긴급히 신호를 보냄

robots.txt는 "이 경로는 크롤링하지 말라"는 출입 허가의 언어다. "얼마나 천천히 들어오라"는 속도 조절의 언어가 아니다. 이 둘을 구분하는 것이 이번 글 전체를 이해하는 전제다.

지금 당장 서버가 위험할 때, 무엇부터 해야 하나?

서버 과부하가 눈앞에 닥쳤다면 가장 먼저 할 일은 크롤 요청에 정상 응답(200) 대신 오류·일시중단 상태 코드를 돌려주는 것이다. 순서로 정리하면 아래와 같다.

1. 원인부터 진단한다. 서버 로그로 어떤 요청이 몰리는지 확인한다. 필터·정렬 조합으로 생기는 URL 폭증, 캘린더형 페이지, 광고용 크롤러(AdsBot) 요청이 흔한 원인이다.
2. 단기 응급 처치인지 판단한다. 몇 시간에서 1–2일 안에 해결될 문제라면 응답 코드를 바꿔 구글봇에 신호를 보낸다.
3. 500·503·429 중 하나를 선택한다. 아래 섹션에서 세 코드의 차이를 다룬다.
4. 가능하면 Retry-After 헤더를 함께 보낸다. 언제 다시 와도 되는지 구체적으로 알려주면 회복이 더 매끄럽다.
5. 원인을 해결하면서 모니터링한다. 오류 응답이 줄면 구글은 크롤 속도를 자동으로 다시 올린다.

이 절차는 "지금 당장" 쓰는 응급 처치다. 평상시 크롤 효율을 관리하는 일(아래 크롤 버짓 섹션 참고)과는 성격이 다르므로 혼동하지 않아야 한다.

500·503·429, 어떤 상태코드를 언제 쓰나?

세 코드 모두 구글에 "지금은 정상적으로 받아갈 상황이 아니다"라는 신호를 주지만, 원래 의미는 각각 다르다. 의미에 맞게 고르는 것이 좋은 예, 아무거나 쓰는 것이 나쁜 예다.

• 500(Internal Server Error): 서버 내부에서 처리 중 오류가 발생했다는 뜻. 의도적으로 보낸다면 "지금 서버 상태가 정상이 아니다"는 신호로 쓸 수 있다.
• 503(Service Unavailable): 서버가 일시적으로 요청을 처리할 수 없다는 뜻. 점검·과부하로 잠깐 멈췄을 때 가장 정확한 의미를 전달하는 코드다.
• 429(Too Many Requests): 클라이언트(여기서는 구글봇)가 너무 자주 요청하고 있다는 뜻. "속도를 줄여 달라"는 의미에 가장 가까운 코드다.

실전 좋은 예 vs 나쁜 예

나쁜 예: 원인 분석 없이 사이트 전체를 임의로 404로 돌리며 "이러면 안 오겠지"라고 기대한다. 404는 "이 페이지가 없다"는 뜻이라, 구글은 이를 삭제 신호로 받아들여 색인에서 더 빨리 뺀다. 속도 조절 용도가 아니다.

좋은 예: 과부하가 특정 하위 경로(예: 검색 결과 페이지)에서만 발생한다면 그 경로에만 503을 걸고, 나머지 페이지는 정상 응답을 유지한다. 영향 범위를 필요한 만큼으로 좁히는 것이다.

한 가지 중요한 전제를 짚어 둔다. 구글은 이 세 코드가 같은 호스트 이름 전체에 걸쳐 많이 발견될 때 크롤 속도를 낮춘다. 즉 테스트용으로 한두 번 503을 보냈다고 즉시 속도가 떨어지는 것은 아니며, 일정 수준 이상 반복적으로 감지되어야 효과가 나타난다.

Retry-After 헤더는 어떻게 쓰는 것인가?

이번 2026년 10월 문서 업데이트의 실질적인 핵심이다. 구글은 "크롤러 트래픽을 긴급히 줄이기" 섹션에, 500·503·429 응답과 함께 Retry-After HTTP 헤더를 보내 다시 요청해도 되는 시점을 알려줄 수 있다는 설명을 명시적으로 넣었다.

Retry-After는 RFC 9110(HTTP 표준 중 하나)에 정의된 헤더이며, 값은 두 가지 형식 중 하나로 쓴다.

Retry-After: 120

이렇게 초 단위 지연 시간으로 쓰면 "지금부터 120초 뒤에 다시 와도 된다"는 뜻이다.

Retry-After: Wed, 14 Oct 2026 09:00:00 GMT

이렇게 UTC 기준 절대 날짜·시간으로 쓰면 "이 시각 이후에 다시 와도 된다"는 뜻이다.

Retry-After 자체는 새로 생긴 헤더가 아니다. 이전에도 "웹사이트 일시 중단" 관련 문서에 쓰여 있었다. 2026년 10월 변화는 이 설명을 긴급 크롤러 트래픽 감소 섹션으로 옮겨 와 한 곳에서 보기 쉽게 정리한 것이다. 메커니즘 자체(500·503·429를 크롤 축소 신호로 쓰는 것)는 바뀌지 않았다.

실무에서는 보통 초 단위 형식이 더 다루기 쉽다. 복구까지 걸릴 시간을 대략 추정해 여유 있게 넣으면 된다. 예를 들어 서버 점검이 30분 걸릴 것으로 예상되면 Retry-After: 2400처럼 조금 더 넉넉하게 잡는 식이다.

다만 Retry-After를 넣지 않아도 500·503·429 자체만으로 신호는 전달된다. 헤더는 "언제 다시 오면 되는지"를 더 구체적으로 알려주는 보조 장치이지, 반드시 있어야만 작동하는 필수 조건은 아니다.

이 조치, 언제까지 써도 되나?

1–2일을 넘기지 않는 것이 원칙이다. 구글 문서는 이 방법을 장기간(2일 이상) 쓰는 것을 권장하지 않는다고 분명히 적고 있다.

이유는 명확하다. 같은 URL에서 오류·일시중단 코드가 며칠째 계속 감지되면, 구글은 "이 페이지가 더 이상 존재하지 않는 것"으로 판단해 색인에서 제거할 수 있다. 서버를 보호하려다 검색 노출 자체를 잃는 셈이니, 득보다 실이 커진다.

영향은 검색에만 머물지 않는다. 크롤 속도가 낮아진 채 오래 유지되면 다음과 같은 문제가 함께 생길 수 있다.

• 새 페이지 발견이 늦어진다
• 가격·재고 같은 기존 페이지의 업데이트 반영이 지연된다
• 이미 삭제한 페이지가 색인에 더 오래 남는다
• 구글 애즈(Ads)를 쓰는 경우 캠페인이 일시중지되거나 광고 노출이 끊길 수 있다

긴급 조치는 "숨 돌릴 시간을 버는 것"이지 "영구적인 해결책"이 아니다. 같은 기간 동안 반드시 근본 원인(서버 증설, 캐시 적용, 비효율적 URL 구조 정리)을 함께 처리해야 한다.

만약 오류 응답을 보내기 어려운 인프라 구조라면, 서치 콘솔의 Googlebot 보고서를 통해 특별 요청을 제출해 구글에 직접 속도를 낮춰 달라고 알릴 수 있다. 다만 이 방법은 속도를 늘려 달라는 요청은 받지 않으며, 심사에 며칠이 걸릴 수 있다는 점을 함께 알아 둘 필요가 있다.

매번 사람이 직접 해야 하나, 자동화할 수 있나?

규모가 있는 사이트라면 사람이 모니터링 화면을 보고 그때그때 수동으로 응답 코드를 바꾸는 방식은 늦을 수 있다. 서버 모니터링 도구와 연동해 응답 시간이나 CPU 사용률이 특정 임계치를 넘으면 자동으로 503과 Retry-After를 반환하도록 구성하는 것도 가능하다.

좋은 예: 평소 응답 시간의 몇 배를 넘는 구간이 몇 분 이상 지속될 때만 자동으로 503을 켜고, 수치가 정상으로 돌아오면 자동으로 해제되도록 설정한다. Retry-After 값도 "지금 걸린 시간의 평균 복구 시간"을 기준으로 동적으로 계산해 넣는다.

나쁜 예: 한 번이라도 응답이 느려지면 무조건 긴 시간(예: 24시간) 동안 503을 고정해 버린다. 과부하가 10분 만에 풀렸는데도 하루 종일 크롤링이 막혀 있게 되고, 결국 색인 지연이라는 부작용만 남는다.

자동화할 때도 원칙은 같다. 범위는 좁게, 기간은 짧게, 해제는 자동으로. 임계치를 너무 민감하게 잡으면 정상적인 트래픽 변동에도 불필요하게 크롤링을 막아버릴 수 있으니, 몇 차례 데이터를 쌓아보고 기준값을 조정하는 과정이 필요하다.

크롤링 속도와 크롤 버짓은 같은 말인가?

아니다. 크롤링 속도는 "얼마나 빠르게 오는가"에 대한 답이고, 크롤 버짓은 "전체적으로 얼마나 많이 가져가는가"에 대한 답이다. 두 개념은 연결돼 있지만 같은 질문을 가리키지 않는다.

구분	크롤링 속도(Crawl rate)	크롤 버짓(Crawl budget)
던지는 질문	초당 몇 건 요청하는가	전체적으로 몇 개 URL을 가져가는가
결정 요인	서버 응답 속도, 오류율	크롤 용량 한도 × 크롤 수요
조절 방법	500·503·429 (단기·긴급)	URL 구조 정리, 내부 링크, 사이트맵 (장기)
주로 필요한 사이트	모든 사이트(과부하 시)	페이지 수가 매우 많은 대형 사이트

크롤 버짓이라는 개념 자체와, 무엇이 이를 늘리고 줄이는지는 이루웹 블로그의 크롤 버짓 완전 정리 글에서 따로 깊게 다뤘다. 새로 만든 사이트라면 이 단계에서는 지나치게 걱정할 필요가 없다는 점만 짚어 둔다.

반대로 지금 서버가 눌리고 있다면, 그 순간에 필요한 것은 크롤 버짓 최적화가 아니라 이번 글에서 다룬 상태 코드·Retry-After 조치다. 둘을 혼동하면 긴급한 순간에 엉뚱한 작업(사이트맵 재정비 같은)에 시간을 쓰게 된다.

크롤 수요는 왜, 어떻게 달라지나?

크롤 버짓을 결정하는 두 요소 중 크롤 수요는 사이트 운영자가 어느 정도 영향을 줄 수 있는 변수다. 구글이 "이 사이트를 다시 와서 볼 필요가 있다"고 느끼게 만드는 요인들이 따로 있다는 뜻이다.

대표적으로 세 가지가 꼽힌다. 첫째는 인기도다. 외부에서 들어오는 링크가 많고 실제 방문자가 꾸준한 페이지는 구글이 더 자주 들여다본다. 둘째는 콘텐츠 신선도다. 가격·재고·뉴스처럼 자주 바뀌는 정보를 담은 페이지는 변경을 놓치지 않으려고 방문 빈도가 올라간다. 셋째는 URL 전체의 품질이다. 중복 페이지나 의미 없는 파라미터 조합이 많을수록, 구글은 "여길 다시 가 봐도 새로운 게 없다"고 학습해 수요 자체를 낮춘다.

크롤 수요가 낮다는 신호가 반복되면, 서버가 멀쩡해도 크롤링 속도 자체가 서서히 내려간다. 서버 과부하로 인한 긴급 조치와는 원인이 전혀 다르다는 점을 다시 한번 구분해 둘 필요가 있다.

반대로 긴급 상황에서 보낸 500·503·429는 크롤 수요를 낮추려는 목적이 아니다. 어디까지나 "지금 서버 용량이 부족하니 속도만 늦춰 달라"는 신호다. 과부하가 끝난 뒤 정상 응답으로 돌아가면 구글은 다시 원래 수준으로 속도를 회복시킨다. 두 메커니즘을 섞어서 "수요까지 영구적으로 깎였다"고 오해하지 않는 것이 중요하다.

CDN·방화벽 설정이 구글봇을 실수로 막을 수도 있다

의도치 않게 크롤링 속도가 떨어지는 경우도 흔하다. 가장 흔한 원인은 CDN·방화벽의 봇 차단 규칙이 구글봇까지 함께 걸러내는 것이다.

예를 들어 트래픽이 갑자기 몰릴 때 CDN의 "공격 방어 모드"나 요청 속도 제한(rate limiting) 규칙을 급하게 켜는 경우가 있다. 이때 규칙이 지나치게 넓게 걸려 있으면 실제 악성 트래픽뿐 아니라 구글봇의 정상적인 요청까지 차단당한다. 겉으로 보기에는 크롤링 속도가 "스스로 줄어든 것"처럼 보이지만, 실제 원인은 구글의 알고리즘 판단이 아니라 방화벽이 구글봇을 막은 것인 경우가 많다.

이 둘을 구분하는 가장 빠른 방법은 서치 콘솔 크롤링 통계 보고서의 호스트 상태와, CDN·서버 쪽 접근 로그를 나란히 놓고 비교하는 것이다. 구글 쪽에서는 요청을 보냈는데 서버 로그에는 해당 요청이 거부된 기록(403 등)으로 남아 있다면, 방화벽 설정 문제일 가능성이 크다.

나쁜 예: 과부하가 걱정된다는 이유로 알려진 모든 크롤러 봇 차단 규칙을 한꺼번에 켠다. 이러면 악성 스크래퍼뿐 아니라 구글봇까지 통째로 막혀, 긴급 상황이 지나간 뒤에도 색인 반영이 한참 늦어진다.

좋은 예: 구글봇으로 알려진 IP 대역이나 역방향 DNS 검증을 거쳐 신원이 확인되는 요청은 예외로 두고, 그 외의 수상한 트래픽에만 제한 규칙을 적용한다. CDN 환경에서 구글봇이 실수로 막히는 유형과 점검 체크리스트는 CDN·방화벽의 구글봇 차단 가이드에서 더 자세히 다뤘다.

실전 타임라인으로 보는 긴급 조치 적용 흐름

글로만 읽으면 순서가 손에 잘 안 잡힐 수 있다. 다음은 흔히 일어나는 상황을 가정한 예시 타임라인이다. 실제 수치는 사이트마다 다르지만 흐름 자체는 참고할 만하다.

1. 0분: 신상품 공개와 함께 방문자가 몰리면서 서버 응답 시간이 평소보다 몇 배로 느려졌다는 것을 모니터링 알림으로 확인한다.
2. 5분: 로그를 확인해, 사람 방문자뿐 아니라 구글봇의 요청도 같은 시간대에 겹쳐 서버 부담을 키우고 있다는 것을 파악한다.
3. 10분: 검색 노출에 필수적인 핵심 페이지(상품 상세, 홈)는 그대로 두고, 상대적으로 덜 중요한 페이지(필터 조합이 많은 목록 페이지)에만 503 응답과 Retry-After: 1800(30분 뒤 재시도)을 적용한다.
4. 30분–2시간: 서버 증설이나 캐시 적용으로 근본 원인을 처리하는 동안, 해당 구간의 응답은 계속 503으로 유지한다.
5. 2시간 후: 서버가 안정되면 즉시 해당 경로를 정상 응답(200)으로 되돌린다. 상태 코드를 오래 방치하지 않는 것이 핵심이다.
6. 다음 날: 서치 콘솔 크롤링 통계 보고서에서 해당 시간대의 503 비율이 올라갔다가 다시 정상으로 돌아왔는지 확인하고, 호스트 상태에 이상 신호가 남아 있지 않은지 점검한다.

이 흐름에서 가장 자주 생기는 실수는 두 가지다. 하나는 영향 범위를 지나치게 넓혀 핵심 페이지까지 503으로 막아 버리는 것이고, 다른 하나는 상황이 끝났는데도 상태 코드를 되돌리는 것을 잊는 것이다. 둘 다 앞서 설명한 "1–2일을 넘기면 색인에서 빠질 위험"으로 바로 이어지는 실수이니 주의가 필요하다.

robots.txt는 그럼 아예 쓸모가 없는 걸까?

그렇지 않다. robots.txt는 속도 조절에는 못 쓰지만 접근 차단에는 여전히 핵심 도구다. 과부하 원인이 특정 패턴(예: 끝없이 생성되는 필터 조합 URL)이라면, 그 패턴을 Disallow로 아예 크롤링 대상에서 빼는 것이 가장 근본적인 해법일 수 있다.

응급 처치(상태 코드+Retry-After)로 숨을 돌린 다음, robots.txt와 URL 구조 자체를 점검해 같은 상황이 반복되지 않게 막는 것이 올바른 순서다.

robots.txt 설정을 전반적으로 다시 점검하고 싶다면 robots.txt 설정 가이드를 함께 참고하면 도움이 된다. 이 글이 긴급 대응을 다룬다면, 그 글은 평상시 접근 제어 설계를 다룬다는 점에서 역할이 다르다.

지금 내 사이트의 크롤 상태는 어디서 확인하나?

서치 콘솔의 설정 > 크롤링 통계 메뉴에서 확인한다. 여기서 최근 90일간 구글봇의 요청 횟수, 응답 시간, 호스트 상태를 볼 수 있다. 응답 코드별 분류표를 보면 503·429가 실제로 얼마나 발생했는지, 그 결과 크롤 속도가 실제로 떨어졌는지를 함께 가늠할 수 있다.

이 보고서를 화면 구성 그대로 따라가며 읽는 방법은 서치 콘솔 크롤링 통계 보고서 완벽 가이드에 자세히 정리해 두었다. 긴급 조치를 취한 뒤에는 이 보고서로 실제로 속도가 내려갔는지, 오류가 줄면서 회복되는지를 지켜보는 것이 마무리 단계다.

발행 전에 점검할 7가지

1. 과부하의 정확한 원인(어떤 URL 패턴, 어떤 크롤러)을 로그로 확인했는가
2. 영향을 필요한 경로에만 좁혔는가, 사이트 전체로 과도하게 넓히지 않았는가
3. 500·503·429 중 상황에 맞는 코드를 선택했는가(404로 대체하지 않았는가)
4. Retry-After 값을 현실적인 복구 시점으로 넣었는가
5. 1–2일 이내에 해제할 계획을 세워 두었는가
6. 같은 기간 근본 원인(서버·캐시·URL 구조)을 함께 손보고 있는가
7. 서치 콘솔 크롤링 통계 보고서로 회복 여부를 모니터링할 준비가 되었는가

자주 묻는 질문

Retry-After 헤더를 안 넣으면 효과가 없나요?

아니다. 500·503·429 상태 코드 자체가 핵심 신호이며, 이것만으로도 구글은 크롤 속도를 낮춘다. Retry-After는 언제 다시 와도 되는지 더 구체적으로 알려주는 보조 정보다. 없어도 작동하지만, 있으면 회복 타이밍이 더 매끄러워진다.

robots.txt에 Crawl-delay를 적어 두면 구글이 참고라도 하나요?

하지 않는다. 구글은 2019년부터 이 지시어를 공식적으로 지원하지 않는다고 밝혔고, 지금도 마찬가지다. 다른 검색엔진은 참고할 수 있지만 구글봇에는 영향을 주지 않는다.

긴급 조치를 썼는데 왜 속도가 바로 안 줄어드나요?

구글은 이 상태 코드들이 호스트 전체에서 충분히 많이 감지될 때 속도를 조절한다. 한두 건의 오류 응답으로는 반영되지 않을 수 있고, 어느 정도 누적된 뒤 반영되기까지 시간 차가 있을 수 있다.

CDN이 구글봇을 막은 것 같은데, 크롤링 속도 문제인가요?

아니다. 이는 구글의 알고리즘이 속도를 낮춘 것이 아니라 방화벽·CDN 규칙이 정상 요청까지 걸러낸 것이다. 서치 콘솔의 호스트 상태와 서버·CDN 접근 로그를 함께 비교해, 구글이 보낸 요청이 거부된 흔적이 있는지부터 확인하는 것이 먼저다.

모바일과 데스크톱 구글봇의 크롤링 속도도 따로 조절해야 하나요?

따로 조절할 방법은 없다. 크롤링 통계 보고서는 구글봇 유형별 요청 비율을 보여주긴 하지만, 500·503·429 응답과 Retry-After는 요청을 보낸 구글봇의 종류와 무관하게 호스트 단위로 동일하게 적용된다. 특정 유형만 골라 속도를 다르게 줄 수는 없다.

Retry-After 값을 넉넉하게 길게 잡아 두면 더 안전한가요?

꼭 그렇지는 않다. 값을 지나치게 길게 잡으면 실제로 서버가 회복된 뒤에도 구글봇이 한참 뒤에야 다시 찾아오는 부작용이 생긴다. 그만큼 새 콘텐츠 발견과 기존 페이지 갱신이 늦어진다. 예상 복구 시간에 약간의 여유만 더하는 수준이 적당하며, 복구가 끝나면 정상 응답으로 먼저 되돌리는 쪽이 Retry-After 값을 길게 잡아 두는 것보다 낫다.

다른 검색엔진과의 차이도 참고할 만하다. 일부 검색엔진은 robots.txt의 비표준 Crawl-delay 지시어를 그대로 따르지만, 그 사이트들에 대해서도 긴급 상황이라면 상태 코드 기반 방식이 더 즉각적으로 통한다. 결국 이 글에서 다룬 500·503·429와 Retry-After 조합은 특정 검색엔진에 종속되지 않는, 범용성이 가장 높은 긴급 대응 수단이라고 볼 수 있다.

서버 과부하가 아니라 단순히 "구글봇이 너무 자주 온다"고 느껴질 때도 이 방법을 써야 하나요?

꼭 그렇지는 않다. 실제로 서버가 위험한 수준이 아니라면, 긴급 코드를 쓰기보다는 캐시 설정이나 서버 자원 증설, 혹은 불필요한 URL 패턴을 robots.txt로 막는 방향이 먼저다. 긴급 조치는 진짜 긴급할 때를 위해 아껴 두는 쪽이 안전하다.

---

이루웹은 홈페이지 제작 단계에서부터 서버 구조와 크롤링 효율을 함께 설계해, 트래픽이 몰려도 검색 노출에 문제가 생기지 않도록 돕고 있습니다. 지금 서버 과부하로 급하게 상태 코드를 적용해야 하는 상황이거나, 애초에 이런 일이 반복되지 않을 구조가 필요하시다면 이루웹 SEO 서비스 페이지를 살펴보시고 상담 문의로 편하게 연락 주시면 함께 진단해 드리겠습니다.