크롤 버짓: 대형 웹사이트를 위한 실용 가이드

800페이지짜리 웹사이트가 "크롤 버짓을 더 얻어야" 하는 경우는 드뭅니다. 필터 조합으로 만들어진 URL 80,000개짜리 사이트는 Googlebot이 아무도 색인되길 원하지 않는 페이지에 대부분의 시간을 쓰게 만들 수 있습니다. 증상은 Search Console에서 비슷해 보일 수 있지만 해결책은 완전히 다릅니다.

이 가이드는 "Discovered – currently not indexed" 상태에 머문 URL이 많거나, 사이트맵 발견이 늦거나, 서버 로그가 파라미터 페이지로 가득한 이커머스 사이트, 퍼블리셔, 마켓플레이스, 프로그래매틱 SEO 프로젝트를 위한 것입니다.

크롤 버짓이란?

크롤 버짓은 일정 기간 동안 구글이 사이트에서 크롤링할 수 있고 크롤링하고 싶어 하는 URL의 집합입니다. 두 가지 구성 요소가 있습니다.

• 크롤링 용량 한도(Crawl capacity limit): Googlebot이 서버에 부담을 주지 않고 보낼 수 있는 요청 수.
• 크롤링 수요(Crawl demand): 최신성, 인기도, 품질, 가치에 따라 구글이 URL을 다시 방문하고 싶어 하는 정도.

서버가 빨라지면 용량은 개선되지만 더 많이 크롤링한다는 보장은 없습니다. 수천 개의 URL이 빈약하거나, 거의 동일하거나, 검색 수요가 없다면 크롤링 수요는 여전히 낮습니다.

구글은 크롤 버짓이 주로 매우 큰 사이트, 매일 변경되는 URL이 약 10,000개 이상인 사이트, 또는 "Discovered – currently not indexed" URL의 비중이 큰 사이트와 관련이 있다고 말합니다. 작은 블로그라면 깔끔한 사이트맵과 합리적인 내부 링크로 보통 충분합니다.

먼저 크롤 버짓이 문제인지 확인하기

robots.txt를 수정하는 것으로 시작하지 마세요. 네 가지 질문에 답해 보세요.

1. 중요한 URL이 발행이나 의미 있는 업데이트 직후 크롤링되나요?
2. 유효한 URL이 많이 몇 주째 "Discovered – currently not indexed" 상태인가요?
3. 크롤링 통계(Crawl Stats)에서 Googlebot이 파라미터, 내부 검색, 중복 페이지에 요청을 쓰는 것으로 나오나요?
4. 크롤링이 급증할 때 서버가 5xx, 타임아웃, 느린 응답을 자주 반환하나요?

모든 답이 아니오라면 크롤 버짓보다 품질, 내부 링크, 색인 가능성이 원인일 가능성이 높습니다.

직감이 아니라 서버 로그에서 시작하기

GA4는 서버 액세스 로그를 제공하지 않습니다. 요청 URL, 상태 코드와 시각은 접근 권한이 있는 로그에서 확인하세요. 공개 태그 검사로는 이러한 기록을 얻을 수 없습니다.

유용한 기준선 보고서에는 다음이 포함됩니다.

user agent를 맹목적으로 믿지 마세요. 악성 봇은 Googlebot을 사칭할 수 있습니다. 요청을 크롤링 보고서에 포함하기 전에 리버스 DNS나 공식 IP 대역을 확인하세요.

크롤 효율을 높이는 일곱 가지 방법

1. 구글이 발견할 수 있는 URL 인벤토리 줄이기

패싯 내비게이션이 흔한 원인입니다. 필터가 10개이고, 필터마다 여러 값이 있고, 조합에 제한이 없는 카테고리는 수만 개의 URL을 만들어 낼 수 있습니다.

세 그룹으로 나누세요.

• 검색 수요와 고유한 가치가 있음: 색인하고, 자기 참조 canonical을 두고, 내부 링크로 연결합니다.
• 방문자에게는 유용하지만 검색용은 아님: 크롤링과 색인을 의도적으로 제어합니다.
• 가치 없음: 생성과 링크를 중단합니다.

canonical 태그는 크롤링을 없애지 못합니다. 구글이 태그를 읽으려면 페이지를 내려받아야 하기 때문입니다. 가장 효과적인 해결책은 쓸모없는 URL을 퍼뜨리지 않는 것입니다.

2. 사이트맵을 우선순위 목록으로 다루기

사이트맵은 데이터베이스 덤프가 아닙니다. 다음 조건을 만족하는 URL만 포함하세요.

• canonical;
• 200 반환;
• 색인 가능;
• 유용할 만큼 충분한 분량;
• 사실에 맞는 <lastmod> 날짜가 지정됨.

푸터를 배포할 때마다 lastmod를 바꾸면 신호의 유용성이 떨어집니다. 주요 콘텐츠, 상품 데이터, 의미 있는 정보가 바뀔 때 업데이트하세요.

사이트맵 검사기로 사이트맵 인덱스, URL 수, lastmod 적용 범위를 점검하세요.

3. 리디렉션 체인과 오래된 링크 제거

Googlebot은 리디렉션을 따라갈 수 있지만 A → B → C → D는 도착을 늦추고 유지 보수 부담을 키웁니다. 내부 링크는 D를 직접 가리켜야 하고 사이트맵에는 D만 있어야 합니다.

마이그레이션 후에는 오래된 리디렉션을 너무 일찍 제거하지 마세요. 체인을 한 홉으로 줄이고 로그를 모니터링해 레거시 URL이 여전히 요청을 받는지 확인하세요. 리디렉션 체인 검사기는 모든 홉을 빠르게 보여 줍니다.

4. 의미 있는 상태 코드 반환

영구 삭제된 상품은 상태 200의 "찾을 수 없음" 페이지가 아니라 404나 410을 반환해야 합니다. 소프트 404는 크롤러가 가치 없는 URL을 계속 처리하게 만듭니다.

반복되는 5xx 오류와 타임아웃은 더 심각합니다. 서버에 오류가 생기면 추가 부하를 피하려고 크롤링 용량이 줄어들 수 있습니다. 템플릿과 시간대별로 오류를 묶어 보면 애플리케이션 결함과 트래픽 급증을 구분할 수 있습니다.

5. 페이지를 가져오고 렌더링하는 비용 낮추기

빠른 응답, 간결한 HTML, 안정적인 리소스는 구글이 같은 조건에서 더 많은 콘텐츠를 처리하게 해 줍니다. TTFB, 캐시, 데이터베이스 쿼리, 이미지, JavaScript는 사용자 경험뿐 아니라 크롤링 효율에도 영향을 줍니다.

JavaScript가 많은 페이지는 HTML이 크롤링된 뒤 렌더링 단계도 필요합니다. 핵심 콘텐츠를 서버 사이드 렌더링하거나 사전 렌더링하면 렌더링 대기열에 대한 의존도가 줄어듭니다.

6. 비즈니스 가치를 중심으로 내부 링크 구축

사이트맵에만 존재하는 중요한 URL도 약해 보일 수 있습니다. 카테고리, 허브, 브레드크럼, 관련 콘텐츠가 우선 상품과 랜딩 페이지로 이어지는 자연스러운 크롤링 경로를 만들어야 합니다.

실용적인 규칙 하나: 콘텐츠 팀이 방문자가 페이지에 어떻게 도달하는지 설명하지 못한다면 크롤러도 같은 어려움을 겪을 수 있습니다.

7. 대규모 발행·업데이트 배치 계획

퍼블리셔와 마켓플레이스는 수십만 건의 레코드를 한꺼번에 바꿔 부하 급증을 만들 수 있습니다. 합리적인 배치 분할, 콘텐츠 유형별 사이트맵 인덱스, 정확한 lastmod 값은 크롤러가 바뀐 부분에 집중하도록 돕습니다.

역효과를 내는 크롤 버짓 "꼼수"

모든 곳에 noindex 추가

구글은 noindex를 보려면 URL을 크롤링해야 하므로 요청이 사라지지 않습니다. robots 규칙도 버짓을 마음대로 조절하는 손잡이처럼 다뤄서는 안 됩니다. 차단된 URL도 오랫동안 알려지고 대기열에 남아 있을 수 있습니다.

CSS와 JavaScript 차단

구글은 페이지를 렌더링하고 평가하려면 핵심 리소스가 필요합니다. 이를 차단하면 페이지가 불완전하거나 모바일에 친화적이지 않게 보일 수 있습니다.

우선순위를 강제하려고 사이트맵 교체

사이트맵은 발견을 돕는 것이지 할당량을 보장하지 않습니다. 깔끔한 사이트맵은 인벤토리를 명확히 하지만 빈약한 콘텐츠를 크롤링할 가치가 있는 것으로 만들 수는 없습니다.

무슨 수를 써서라도 크롤링 속도 올리기

서버가 느리거나 실패하고 있다면 크롤링 활동을 늘리는 것은 문제를 악화시킬 뿐입니다. 크롤링 양을 걱정하기 전에 크롤링 건강 상태를 먼저 회복하세요.

대형 사이트를 위한 14일 계획

1~3일: 기준선 수립

크롤링 통계, 색인 보고서, 7~14일치 접근 로그를 내보내세요. URL을 템플릿, 상태, 파라미터 유형, 응답 시간별로 묶으세요.

4~6일: 가장 큰 낭비 원인 세 가지 선택

대개 패싯 URL, 리디렉션 체인, 소프트 404입니다. 20가지 문제를 한꺼번에 고치면 무엇이 효과를 냈는지 알 수 없습니다.

7~10일: 생성기 수정

컴포넌트에서 파라미터 링크를 제거하고, URL 생성을 표준화하고, 사이트맵 생성기를 업데이트하고, 올바른 상태 코드를 반환하세요. 스테이징에서 테스트하되 크롤러는 공개 환경을 평가한다는 점을 기억하세요.

11~14일: 배포 모니터링

우선 URL로의 요청, 5xx 빈도, 응답 시간, 색인 변화를 비교하세요. 크롤링 패턴은 하룻밤 사이에 바뀌지 않지만 로그는 종합 보고서보다 더 일찍 증거를 제공합니다.

Search Console과 로그 비교

Search Console은 크롤링 추세, 색인 상태, 사이트 전반의 오류를 보기에 가장 좋습니다. 로그는 상세한 질문에 답해 줍니다. 어떤 봇이 어떤 URL을 언제, 어떤 상태와 지연 시간으로 요청했는지 알려 줍니다.

두 소스는 서로를 보완합니다. Search Console은 지도를 제공하고 로그는 발자국을 보여 줍니다.

성공은 어떤 모습이어야 할까

Googlebot의 총 요청 수로 프로젝트를 평가하지 마세요. 성공적인 크롤링 효율 개선은 요청량은 그대로 두면서 그 요청이 향하는 곳을 바꿀 수 있습니다.

4~6주 동안 작은 스코어카드를 추적하세요.

• canonical 200 페이지에 도달하는 Googlebot 요청의 비율;
• 파라미터, 리디렉션, 소프트 404, 오류에 낭비된 요청;
• 가장 많이 크롤링되는 템플릿의 응답 시간 중앙값;
• 중요한 URL을 발행한 뒤 첫 크롤링까지의 시간;
• 발견은 되었지만 색인되지 않은 채 남은 가치 있는 URL의 수;
• 크롤링이 몰릴 때의 서버 오류.

가장 좋은 결과는 그 자체로 "더 많은 크롤링"이 아닙니다. 중요한 변경을 더 빨리 발견하고, 쓸모없는 변형으로 가는 요청을 줄이고, 서버 성능을 안정적으로 유지하는 것입니다.

계절성도 중요합니다. 대규모 세일 전의 마켓플레이스, 속보가 터진 퍼블리셔, 마이그레이션 직후의 카탈로그는 일시적인 수요 변화를 겪을 수 있습니다. 같은 기간끼리 비교하고 릴리스에 주석을 달아 바쁜 한 주가 잘못된 결론이 되지 않도록 하세요.

마지막으로 크롤링과 색인을 구분하세요. URL이 자주 크롤링되더라도 콘텐츠가 빈약하거나, 중복되거나, 충분히 유용하지 않으면 색인되지 않은 채로 남을 수 있습니다. 로그에서 구글이 페이지에 안정적으로 도달한다는 것이 확인되면 크롤링 규칙을 더 조정하지 말고 페이지 자체를 개선하세요.

시작 단계: 무료 SEO 감사를 실행해 사이트맵, robots, 리디렉션, 색인 가능성 문제를 찾은 다음 서버 로그로 대형 사이트의 실제 크롤링을 측정하세요.

결론

크롤 버짓 최적화는 Googlebot이 더 자주 방문하게 만드는 요령을 찾는 일이 아닙니다. 서버가 빠르고 안정적으로 응답하는 가운데 기존 크롤링 활동을 가치 있는 URL로 향하게 하는 것입니다. 낭비되는 인벤토리를 줄이고, 사이트맵을 정직하게 유지하고, 상태 코드를 고치고, 리디렉션을 줄이고, 우선순위에 따라 내부 링크를 연결하세요. 사이트가 크롤 버짓이 중요할 만큼 크지 않다면 콘텐츠 품질을 높이는 것이 보통 더 나은 투자입니다.

참고 자료: Google Search Central – 크롤 버짓 관리 및 Googlebot 문서.