크롤링 예산이란? Search Console 진단부터 최적화까지

크롤링 예산이란?

웹사이트 내 페이지가 있다고 해서 구글이 모든 URL을 같은 빈도로 방문하는 것은 아닙니다.

Googlebot이 한 사이트에서 크롤링할 수 있고, 실제로 크롤링하려고 하는 URL의 범위를 크롤링 예산(Crawl Budget)이라고 합니다.

Google은 이를 크게 두가지로 설명합니다.

크롤링 용량 한도(Crawl Capacity Limit)

Googlebot이 서버에 과도한 부담을 주지 않으면서 요청할 수 있는 수준입니다.

서버 응답이 안정적이고 빠르면 Googlebot이 더 많은 요청을 처리할 여지가 생깁니다. 반대로 응답 시간이 길어지거나 5xx 서버 오류, 429 Too Many Requests가 반복되면 Google은 서버 부하를 고려해 크롤링 강도를 낮출 수 있습니다.

크롤링 수요(Crawl Demand)

Google이 해당 URL을 얼마나 다시 확인할 필요가 있다고 판단하는지와 관련됩니다.

페이지의 변경 빈도, 콘텐츠의 고유성, 사이트에서 발견되는 전체 URL 공간, 페이지의 중요도 등이 영향을 줍니다. 사이트 이전이나 대규모 URL 변경처럼 Google이 사이트 구조를 다시 파악해야 하는 상황에서도 크롤링 수요가 달라질 수 있습니다.

따라서 크롤링 예산을 단순히 ‘Googlebot이 하루에 몇 번 방문했는가’로 이해하면 실제 문제를 놓치기 쉽습니다.

예를 들어 하루 크롤링 요청은 많지만 대부분이 정렬 URL이나 중복 필터 URL에 집중되어 있다면 신규 상품이나 핵심 콘텐츠의 발견은 오히려 늦어질 수 있습니다.

크롤링 예산 최적화는 Googlebot의 방문 횟수를 무조건 늘리는 작업이 아니라 Google이 중요한 URL을 효율적으로 발견하고 다시 방문할 수 있도록 URL 구조를 정리하는 작업에 가깝습니다.

---

모든 사이트에 크롤링 예산 최적화가 필요한 것은 아니다.

페이지가 몇백 개 수준인 기업 홈페이지에서 색인이 늦는다고 바로 크롤링 예산을 의심할 필요는 없습니다.

Google은 크롤링 예산 관리 가이드를 주로 페이지 수가 많고 콘텐츠 변경이 빈번한 사이트를 대상으로 설명합니다.

이 숫자는 절대적인 기준이라기보다 사이트의 규모와 변경 빈도를 판단하기 위한 참고 범위로 보는 편이 적절합니다.

특히 쇼핑몰, 채용, 부동산, 여행 플랫폼처럼 실제 콘텐츠 수보다 생성 가능한 URL의 수가 훨씬 많은 사이트에서 크롤링 예산 문제가 발생하기 쉽습니다.

상품이 5만 개라고 하더라도 브랜드, 가격, 색상, 재고, 정렬 조건이 URL에 각각 반영되면 Google이 발견하는 주소는 수십만 또는 수백만 개까지 늘어날 수 있습니다.

반대로 URL 수가 많더라도 콘텐츠 변경이 적고 canonical, 내부 링크, 사이트맵과 URL 구조가 안정적으로 관리되고 있다면 크롤링 예산이 가장 먼저 해결해야 할 문제는 아닐 수 있습니다.

소규모 사이트에서 먼저 확인해야 할 것

수백~수천 페이지 규모의 일반적인 사이트라면 크롤링 예산보다 다음 문제를 먼저 확인하는 편이 낫습니다.

• 페이지가 noindex 상태인지
• canonical이 다른 URL을 가리키고 있는지
• 내부 링크가 끊겨 중요한 페이지를 발견하기 어려운지
• JavaScript 렌더링 이후 실제 본문이 정상적으로 노출되는지
• 다른 페이지와 콘텐츠가 지나치게 중복되지 않는지

특히 Search Console에 ‘크롤링됨 - 현재 색인이 생성되지 않음’이 나타났다면 이미 Google이 URL을 가져간 상태입니다.

이 경우에는 크롤링 부족보다 콘텐츠 품질, 중복, canonical, 렌더링 결과, 페이지 고유성을 먼저 보는 편이 진단 순서에 맞습니다.

---

크롤링 예산 문제는 Search Console에서 어떻게 확인할까?

크롤링 예산은 총 크롤링 요청 수 하나만 보고 판단하기 어렵습니다.

Google Search Console의 크롤링 통계와 페이지 색인 생성 보고서를 함께 봐야 합니다.

크롤링 통계에서는 Googlebot이 사이트에 어떻게 접근했는지를 확인하고, 페이지 색인 생성 보고서에서는 그 결과가 URL 단위에서 어떻게 처리됐는지를 확인합니다.

크롤링 통계에서 확인할 항목

총 크롤링 요청 수보다 먼저 확인할 것은 요청의 상태입니다.

평균 응답 시간이 갑자기 증가했는지, 5xx 응답이 늘어났는지, 429 응답이 반복되는지, 특정 호스트나 Googlebot 유형에서 요청이 비정상적으로 증가했는지를 살펴봅니다.

예를 들어 크롤링 요청이 늘어나는 동시에 응답 시간이 악화되고 5xx까지 증가했다면 이를 긍정적인 크롤링 증가로 해석하기 어렵습니다.

서버 또는 애플리케이션이 Googlebot 요청을 안정적으로 처리하지 못하고 있을 가능성을 먼저 확인해야 합니다.

페이지 색인 생성 보고서와 함께 보는 이유

‘발견됨 - 현재 색인이 생성되지 않음’은 Google이 URL을 알고 있지만 아직 크롤링하지 않은 상태입니다.

이때는 해당 URL이 사이트맵에 들어 있는지만 볼 것이 아니라 중요한 카테고리와 내부 링크에서 실제로 발견할 수 있는지 확인해야 합니다.

반대로 ‘크롤링됨 - 현재 색인이 생성되지 않음’은 이미 Googlebot이 콘텐츠를 가져간 상태이므로 크롤링 예산 문제로만 접근하면 진단 방향이 어긋날 수 있습니다.

---

Googlebot이 어떤 URL을 크롤링하고 있는지 분류

크롤링 예산 최적화를 하기 위해 바로 robots.txt를 수정하는 것은 좋은 방법은 아닙니다.

먼저 Google이 발견할 수 있는 URL 전체를 유형별로 나눠야 합니다.

쇼핑몰을 예로 들면 ?sort=price_asc 같은 정렬값 URL, 색상·브랜드 필터 URL, UTM 등 추적 파라미터, 세션 ID, 내부 검색 결과, 필터 조합 등이 대표적입니다.

여기서 이슈는 파라미터의 존재여부가 아니라, 동일하거나 유사한 화면을 보여주는 주소가 반복적으로 내부 링크에 노출되고, 조합 수까지 커질 때 Googlebot이 탐색하는 URL 영역이 불필요하게 넓어진다는 것 입니다.

그렇다고 파라미터 URL을 모두 없애야 하는 것은 아닙니다.

예를 들어 ‘특정 브랜드 + 특정 상품군’처럼 실제 검색 수요가 있고 고유한 상품 목록을 제공하는 필터 페이지는 독립적인 SEO 랜딩 페이지로 운영할 수 있습니다.

반대로 정렬 순서만 다르거나 결과가 비어 있거나 세션에 따라 주소만 달라지는 페이지는 검색 결과에 별도로 남길 필요가 거의 없습니다.

따라서 URL을 판단할 때는 주소보다는 검색 가치와 페이지의 역할을 봐야 합니다.

이 기준으로 먼저 전략 URL과 비전략 URL을 구분해야 이후 canonical, robots.txt, noindex 같은 처리 수단도 제대로 선택할 수 있습니다.

---

파라미터 URL은 목적에 따라 처리 방법이 달라진다

여기서 가장 많이 발생하는 오류가 canonical, robots.txt, noindex를 같은 방식으로 활용하는 것입니다. 각각의 태그들은 그 역할을 다르게 해야합니다

canonical

Canonical은 중복되거나 매우 유사한 여러 URL 가운데 어떤 URL을 대표 페이지로 봐야 하는지 Google에 전달하는 신호입니다.

예를 들어 정렬 방식이나 추적 파라미터만 다른 URL이 동일한 내용을 제공한다면 대표 URL을 canonical로 지정할 수 있습니다.

여기서 많은 분들이 오해하는 부분이 canonical을 크롤링 차단 명령이라고 생각하는 것입니다. URL 대표 선언일 뿐 색인을 막는 태그는 아닙니다.

Googlebot이 해당 URL을 발견하면 여전히 접근할 수 있으므로 내부 링크와 XML 사이트맵에서도 대표 URL을 일관되게 사용하는 것이 중요합니다.

robots.txt

robots.txt는 크롤러가 특정 URL이나 경로를 요청하지 않도록 제어하는 수단입니다.

필터 조합이나 내부 검색 결과처럼 URL이 계속 생성되고 Google이 해당 페이지를 크롤링할 이유가 없다면 robots.txt를 검토할 수 있습니다.

다만 검색 가치가 있는 필터 랜딩 페이지까지 같은 규칙으로 차단해서는 안 됩니다.

noindex

Noindex는 페이지를 Google 검색 결과에 포함하지 말라는 지시입니다. 사용자는 접근해야 하지만 검색 결과에는 노출할 필요가 없는 페이지에 사용할 수 있습니다. 대표적인 예시로 고객의 마이페이지 등이 될 수 있습니다.

404·410과 301

실제로 삭제된 콘텐츠에는 404 또는 410을 사용합니다.

대체할 수 있는 새로운 URL이 명확하게 존재한다면 301 리디렉션을 적용합니다. 만약 리뉴얼을 진행하였을 경우 301 리디렉션 처리를 하지 않는다면, 기존 도메인 권위는 휘발될 가능성이 높습니다.

삭제된 페이지를 모두 홈페이지로 보내거나 관련성이 없는 주소로 일괄 리디렉션하는 방식은 적절하지 않습니다.

---

페이지네이션을 무조건 중복 페이지로 처리하면 안 되는 이유

페이지네이션은 파라미터 URL과 함께 정리 대상처럼 취급되기 쉽지만 역할이 다릅니다.

각 페이지가 서로 다른 상품이나 콘텐츠 목록을 보여주고 다음 목록을 발견하기 위한 실제 탐색 경로라면 크롤러가 접근할 수 있어야 합니다.

예를 들어 상품 100개가 20개씩 5페이지에 나뉘어 있는데 모든 페이지를 첫 번째 페이지로 canonical 처리하거나 뒤쪽 페이지를 모두 차단한다면 이후 상품을 발견할 수 있는 내부 링크 경로가 약해질 수 있습니다.

무한 스크롤 역시 JavaScript 동작만으로 콘텐츠를 불러오기보다는 Google이 접근할 수 있는 URL과 링크 구조를 마련하는 편이 안정적입니다. 하나의 콘텐츠에 하나의 URL을 맵핑하는 것은 SEO에서 매우 중요합니다.

---

내부 링크를 통한 중요 URL 명시화

불필요한 URL을 정리했다면 다음 단계는 중요한 URL을 더 쉽게 발견할 수 있도록 만드는 것입니다.

메인 메뉴와 카테고리에서는 표준 카테고리 URL을 연결하고, 상품 목록에서는 추적 파라미터나 세션 값이 없는 표준 상품 URL을 사용합니다.

관련 콘텐츠나 추천 상품 모듈도 마찬가지입니다.

반대로 모든 상품 카드와 필터 버튼에서 정렬·필터 파라미터 URL이 계속 생성되면 Googlebot이 탐색할 URL도 불필요하게 넓어집니다.

검색 수요가 확인된 필터 랜딩 페이지라면 예외적으로 주요 카테고리나 관련 페이지에서 자연스러운 내부 링크를 제공할 수 있습니다. 즉 내부 링크 최적화는 단순히 링크 수를 늘리는 작업이 아니라 Googlebot이 사이트에서 어떤 URL을 반복적으로 발견하도록 만들 것인지 설계하는 작업입니다.

---

XML사이트맵에는 색인할 표준 URL등록

XML 사이트맵은 사이트에 존재하는 모든 URL을 모아두는 목록으로 생각하기 쉽지만 SEO에서는 조금 다르게 접근하는 편이 좋습니다.

Google에 발견과 크롤링을 권장할 표준 URL을 중심으로 구성합니다.

일반적으로 사이트맵에는 자체 canonical을 가진 색인 대상 URL을 넣고, 404·410 페이지, 리디렉션 URL, noindex URL, 세션이나 미리보기처럼 검색용이 아닌 URL은 제외합니다.

내부 링크에서는 A URL을 주요 페이지로 가리키는데 사이트맵에서는 B URL을 제출하고 canonical은 다시 C URL을 지정하는 식으로 신호가 갈리면 대표 URL 관리가 복잡해집니다.

lastmod는 실제 변경이 있을 때 갱신한다

lastmod는 페이지가 마지막으로 의미 있게 수정된 시점을 전달하는 정보입니다.

본문, 상품 가격·재고, 목록 구성 등 검색 결과에 영향을 줄 수 있는 변경이 있을 때 갱신하는 것이 적절합니다.

단순 배치 작업이 실행됐다는 이유로 모든 URL의 날짜를 매일 현재 시간으로 변경하는 방식은 피하는 편이 좋습니다.

---

내부 링크가 끊긴 페이지도 함께 확인

사이트맵에는 포함되어 있지만 사이트 내부 어디에서도 링크를 받지 못하는 페이지가 있을 수 있습니다.

신규 상품, 카테고리 개편 과정에서 빠진 콘텐츠, 과거 URL 구조에 남아 있는 랜딩 페이지 등이 대표적입니다.

이런 페이지는 정상적으로 존재하고 200 상태 코드를 반환하더라도 내부 탐색 경로가 없으면 Googlebot과 사용자가 발견하기 어렵습니다.

색인할 가치가 있는 페이지라면 의미 있는 내부 링크를 받을 수 있는 구조를 만드는 편이 좋습니다.

사이트 크롤링으로 발견한 URL, XML사이트맵 URL, 서버 로그에서 Googlebot이 요청한 URL을 비교하면 내부 링크가 끊긴 페이지를 찾기 쉽습니다.

사이트맵에는 존재하나, 내부 크롤링에서는 발견되지 않는다면 내부 링크 구조를 점검할 필요가 있습니다. 반대로 사이트맵과 내부 링크 어디에도 없는데 서버 로그에서 Googlebot 요청이 반복된다면 오래된 외부 링크나 리디렉션, 파라미터 URL 확산 등을 의심할 수 있습니다.

---

서버 응답이 불안정하면 URL을 정리해도 효과가 제한된다

크롤링 예산관리는 매우 복잡한 영역으로 URL 구조만 정리한다고 크롤링 환경이 모두 개선되는 것은 아닙니다.

Googlebot이 중요한 URL을 발견하더라도 서버가 요청을 빠르고 안정적으로 처리하지 못하면 크롤링 용량 자체가 제한될 수 있습니다.

5xx가 증가하는 경우

애플리케이션 오류, DB 부하, 배포 문제, 외부 API 장애 등을 확인합니다.

전체 평균만 볼 것이 아니라 어떤 URL 유형에서 오류가 발생하는지도 중요합니다.

상품 상세는 정상인데 필터 조합 URL에서만 오류가 발생한다면 조건 처리 쿼리나 캐시 구조가 원인일 수 있습니다.

429가 발생하는 경우

CDN, WAF, Rate Limit, 원본 서버의 요청 제한 정책을 확인합니다.

Googlebot을 일반적인 공격성 봇과 동일하게 처리하는 정책이 적용되고 있지 않은지도 봅니다.

다만 User-Agent 문자열만 보고 Googlebot을 허용하기보다는 실제 Googlebot 여부를 검증할 필요가 있습니다

변경되지 않은 페이지는 304를 활용할 수 있다

페이지가 이전 크롤링 이후 변경되지 않았다면 304 Not Modified 응답을 활용할 수 있습니다.

이는 해당 페이지를 색인에서 제외한다는 뜻이 아니라 콘텐츠 전체를 다시 전송하지 않고 기존 캐시를 사용하도록 알려 서버 자원과 전송량을 줄이는 방식입니다.

---

크롤링 예산 최적화 성과는 ‘요청 수’보다 중요 URL로 판단

전체 크롤링 요청 수가 증가했다고 해서 최적화가 성공한 것은 아닙니다.

사이트 이전이나 URL 규칙 변경 직후에는 Google이 새로운 구조를 파악하는 과정에서 크롤링 요청이 일시적으로 증가할 수 있습니다.

반대로 불필요한 정렬·세션·필터 URL에 대한 크롤링이 줄면서 신규 상품과 핵심 콘텐츠의 발견이 빨라졌다면 전체 요청 수가 감소해도 더 좋은 결과입니다.

따라서 수정 전후에는 URL 유형을 동일하게 나누고 비교해야 합니다.

크롤링 예산 관련 작업 전에 배포 날짜와 수정 내용을 함께 기록해 두는 것이 매우 중요합니다.

robots.txt, canonical, 사이트맵, 내부 링크, CDN·WAF 설정을 동시에 수정하고 기록을 남기지 않으면 이후 크롤링 통계가 변했을 때 어떤 작업이 영향을 줬는지 판단하기 어렵기 때문입니다.

---

크롤링 예산 FAQ

1. 크롤링 예산이 검색 순위에 직접 영향을 주나요?

크롤링 요청 수 자체가 검색 순위를 올려주는 구조는 아닙니다. 다만 페이지가 Google에 발견되고 크롤링되어야 이후 색인과 검색 결과 평가 과정으로 이어질 수 있습니다. 따라서 크롤링 예산은 순위 요소라기보다 대규모 사이트에서 중요한 콘텐츠가 검색 시스템에 정상적으로 전달될 수 있도록 관리하는 기술 SEO 영역으로 이해하는 것이 적절합니다.

2. 소규모 사이트도 크롤링 예산을 관리해야 하나요?

대부분의 소규모 사이트에서는 크롤링 예산보다 색인 차단, canonical, 콘텐츠 중복, 내부 링크, 렌더링 오류를 먼저 확인하는 편이 효율적입니다.

3. robots.txt로 차단하면 검색 결과에서도 사라지나요?

차단 명령이기는 하나 이미 색인이 되어 있다면 차단까지의 기간이 오래걸릴 수 있습니다. robots.txt는 크롤링을 제어하는 파일입니다. 만약 Google이 외부 링크 등으로 URL을 이미 알고 있다면 콘텐츠를 크롤링하지 못하더라도 URL 자체가 검색 결과에 나타날 수 있습니다.

4. robots.txt와 noindex를 같이 사용해도 되나요?

검색 결과에서 제거하기 위해 noindex를 사용한다면 Googlebot이 해당 페이지를 읽을 수 있어야 합니다. robots.txt로 접근을 차단하면 noindex 지시를 확인할 수 없으므로 두 설정을 같은 목적에서 동시에 적용하는 것은 피해야 합니다.

5. 파라미터 URL은 모두 차단해야 하나요?

아닙니다. 실제 검색 수요가 있고 다른 페이지와 구분되는 상품이나 콘텐츠 목록을 제공한다면 하나의 전략 랜딩 페이지로 운영할 수 있습니다. 반대로 정렬, 추적, 세션, 빈 검색 결과처럼 독립적인 검색 가치가 거의 없고 조합이 계속 증가하는 URL은 크롤링과 색인 관리 대상이 됩니다.

---

크롤링 예산 최적화를 위한 URL 인벤토리 정리 순서

실제 작업에서는 다음 순서로 진행하는 것이 가장 효율적입니다.

1. 중요 URL을 먼저 정의한다. 핵심 카테고리, 상품, 콘텐츠, 검색 수요가 검증된 필터 랜딩 페이지를 구분한다.
2. Search Console 기준선을 남긴다. URL 유형별 색인 상태와 크롤링 요청, 5xx·429, 응답 시간을 기록한다.
3. URL 인벤토리를 만든다. 필터, 정렬, 검색, 페이지네이션, 세션, 추적 파라미터, 삭제 URL을 패턴별로 분류한다.
4. URL 역할에 맞는 처리 방식을 결정한다. canonical, robots.txt, noindex, 301, 404·410을 각각의 목적에 맞게 적용한다.
5. 내부 링크와 사이트맵을 표준 URL로 정리한다.
6. 서버 로그와 CDN·WAF를 확인한다. 실제 Googlebot 요청과 응답 코드, 응답 시간을 URL 패턴별로 확인한다.
7. 수정 후 전략 URL의 변화를 비교한다. 전체 크롤링 요청 수보다 중요한 페이지의 발견·재크롤링·색인 상태가 개선됐는지를 확인한다.

다시 말씀드리지만, 크롤링 예산을 관리한다는 것은 Googlebot을 더 많이 방문하게 만드는 것이 아닙니다.

사이트에서 생성되는 URL을 모두 같은 가치로 취급하지 않고, 검색에 남겨야 할 URL과 그렇지 않은 URL을 구분해 Googlebot의 탐색 경로를 정리하는 것이 핵심입니다.

불필요한 URL을 줄이는 것과 동시에 중요한 URL의 내부 링크와 사이트맵 신호를 명확하게 만들고, 서버가 해당 요청을 안정적으로 처리할 수 있어야 크롤링 예산 최적화가 실제 색인 개선으로 이어질 수 있습니다.