크롤 예산

두 개의 절반, 용량과 수요

용량은 Google이 스스로에게 두는 상한입니다. 서버가 얼마나 빨리 응답하고 얼마나 자주 오류를 내는지 지켜보다가 사이트가 느려지면 물러섭니다. 목적은 사이트를 넘어뜨리지 않으면서 크롤하는 것입니다. 수요는 나머지 절반으로, Google이 내 URL을 애초에 얼마나 원하는지입니다. 인기와, 자기가 가진 사본이 얼마나 오래되었는지가 좌우합니다. 서버가 빨라도 다시 가져올 만한 변화가 없다면 크롤은 여전히 가볍습니다. 제약이 용량이 아니었기 때문입니다.

• 용량을 올리는 것 — 일관되게 빠르고 오류 없는 응답. 크롤 속도는 서버 건강도를 따라가므로 Core Web Vitals 작업과 값싼 사전 렌더링은 두 번 값을 합니다.
• 용량을 내리는 것 — 타임아웃, 5xx 오류, 부하 상황의 느린 응답. 오류를 만나기 시작한 크롤러는 속도를 줄이고 한동안 회복하지 않습니다.
• 수요를 올리는 것 — 트래픽과 링크를 얻는 페이지, 그리고 실제로 바뀌는 콘텐츠. 사이트맵과 내부 링크는 URL을 찾게 해 주지만, 발견되는 것과 원해지는 것은 다릅니다.
• 둘 다 낭비하는 것 — 패싯 필터, 세션 id, 끝없는 달력 같은 무한 URL 공간, 그리고 소프트 404와 리디렉션 사슬, 캐노니컬 태그를 달았어야 할 유사 중복 페이지.

진짜 문제일 때와 그냥 산만함일 때

누가 신경 써야 하는지에 대해 Google의 안내는 드물게 단호합니다. 대형 사이트용 크롤 예산 가이드는 세 부류를 지목합니다. 콘텐츠가 주 1회 정도 바뀌는 고유 URL 100만 개 이상 사이트, 콘텐츠가 매일 바뀌는 고유 URL 1만 개 이상 사이트, 그리고 Search Console이 URL의 상당 부분을 *발견됨 — 현재 색인되지 않음*으로 분류하는 사이트입니다. 어디에도 해당하지 않으면 사이트맵을 최신으로 유지하고 페이지 색인 생성 보고서를 지켜보는 것으로 충분하다는 것이 Google의 말입니다.

세 번째가 쓸모 있는 이유는 그것이 규모가 아니라 증상이기 때문입니다. 크롤과 색인을 구분하는 것도 중요합니다. Google은 크롤된 모든 페이지가 색인되지는 않는다고 분명히 말합니다. *크롤됨 — 현재 색인되지 않음*에 머무는 URL은 크롤 예산이 모자랐던 것이 아니라, 가져와서 평가한 뒤 통과시킨 것입니다. 대역폭이 아니라 콘텐츠와 중복의 문제입니다. 이 둘을 혼동하는 것이 이 용어를 잘못 쓰는 가장 흔한 방식이고, 빈약한 페이지를 통합해야 할 때 robots.txt를 만지작거리게 만듭니다.

롱테일 사이트의 크롤 트래픽은 실제로 어떤 모습인가

우리 로그로 여기에 숫자를 붙일 수 있고, 그 숫자가 우리를 놀라게 했습니다. 우리 마케팅 사이트는 8개 언어로 약 3천 페이지를 사전 렌더링합니다. 창업자들이 이 문제를 걱정하기 시작하는 딱 그 구간입니다. 오리진 요청을 세 시간 표본으로 뽑아 보니 서로 다른 558개 URL에 대해 총 1,438회의 요청이었습니다. URL당 약 2.6회이고, 대부분에게는 그날 받은 유일한 방문이었습니다.

두 번째 발견이 더 중요했습니다. 그 트래픽의 약 4분의 3은 검색엔진이 아예 아니었고, 사용자 에이전트를 위조하거나 비운 데이터센터 스크레이퍼였습니다. 이름이 알려진 AI 크롤러는 일부러 막지 않습니다. 읽히는 것 자체가 생성형 엔진 최적화의 목적이기 때문입니다. 실무적 함의는 둘입니다. 크롤 압박처럼 보이는 것의 대부분은 내가 최적화하려는 그 크롤러가 아니라는 것, 그리고 짧은 CDN 캐시 수명은 롱테일 자산에 거의 도움이 되지 않는다는 것입니다. 각 URL이 너무 드물게 요청되어 다음 순회 때는 이미 식어 있기 때문입니다. 검색엔진 쪽 절반을 내 사이트에서 지켜보고 싶다면 CrawlSEO 같은 셀프호스팅 모니터가 Search Console에서 바로 읽어 줍니다.