spider.es

크롤 버짓 최적화: 모든 봇 방문을 가치 있게 만드세요

게시일

크롤 버짓 최적화: 모든 봇 방문을 가치 있게 만드세요

검색 엔진 봇은 무제한의 시간이나 리소스를 가지고 있지 않습니다. 모든 사이트는 유한한 양의 크롤링 관심을 받으며, 이 관심이 어떻게 사용되는지가 어떤 페이지가 발견되고, 색인되고, 최신 상태로 유지되는지를 결정합니다. 이 유한한 할당을 크롤 버짓이라고 합니다. 수백 페이지의 작은 사이트에서는 병목이 되는 경우가 드뭅니다. 그러나 이커머스 스토어, 뉴스 퍼블리셔, 사용자 생성 콘텐츠가 있는 SaaS 플랫폼, 또는 수천 개의 URL을 넘어 성장하는 모든 사이트에서 크롤 버짓 최적화는 핵심 SEO 분야입니다.

크롤 버짓이 실제로 무엇인가

Google은 크롤 버짓을 두 가지 요소의 교차점으로 정의합니다:

크롤 속도 제한

이것은 Googlebot이 사용자 경험을 저하시키지 않으면서 서버에 대해 생성하는 최대 동시 연결 수와 요청 수입니다. 서버의 응답 속도와 안정성에 의해 결정됩니다. 서버가 200 상태 코드로 빠르게 응답하면 크롤 속도가 올라갑니다. 5xx 오류를 반환하거나 느려지기 시작하면 Googlebot은 인프라에 과부하를 주지 않도록 자동으로 속도를 줄입니다. Google Search Console에서 크롤 속도를 조정할 수도 있지만, 이것은 상한선만 설정할 뿐 — Googlebot에게 더 크롤하라고 강제하지는 않습니다.

크롤 수요

이것은 Google이 사이트를 얼마나 크롤하고 싶어하는지로, 두 가지 신호에 의해 결정됩니다: 인기도(더 많은 인바운드 링크와 사용자 참여가 있는 페이지는 더 많은 크롤링을 유도)와 오래됨(자주 변경되는 페이지는 인덱스를 최신 상태로 유지하기 위해 더 자주 재크롤링됩니다). 10분마다 업데이트되는 뉴스 홈페이지는 변하지 않는 "회사 소개" 페이지보다 훨씬 더 많은 크롤 수요를 받습니다.

효과적인 크롤 버짓은 이 두 가지 중 더 낮은 것입니다. 수요가 낮은 빠른 서버는 여전히 적당한 크롤링을 받습니다. 느린 서버의 높은 수요 사이트는 모든 중요한 페이지에 도달하기 전에 속도 제한에 걸립니다. 최적화의 목표는 받는 버짓 내에서 봇이 비즈니스 가치를 이끄는 페이지에 방문을 사용하도록 보장하는 것입니다.

크롤 버짓을 낭비하는 것들

최적화하기 전에, 흔한 낭비 요인을 식별해야 합니다. 이것들은 봇이 검색 노출에 아무것도 추가하지 않는 페이지에 방문을 소모하게 하는 문제입니다.

파라미터 URL과 패싯 내비게이션

색상, 사이즈, 가격 범위, 브랜드, 정렬 순서 필터가 있는 이커머스 사이트는 수천 개의 상품에서 수백만 개의 URL 변형을 생성할 수 있습니다. /shoes?color=red&size=10&sort=price와 /shoes?size=10&color=red&sort=price 같은 URL은 다른 URL로 동일한 콘텐츠를 렌더링할 수 있습니다. 각각이 크롤 슬롯을 소비합니다. 방치하면 봇은 실제 상품 페이지 대신 중복 필터 조합을 크롤링하는 데 대부분의 버짓을 소비합니다.

리다이렉트 체인

URL A가 URL B로, B가 URL C로, C가 최종적으로 URL D에 도달하면, 봇은 단일 목적지에 네 개의 크롤 슬롯을 소비합니다. 체인은 사이트 마이그레이션, CMS 변경 또는 URL 재구성 중에 축적되는 경향이 있습니다. Google은 포기하기 전에 약 10개의 리다이렉트를 따르지만, 각 홉은 낭비된 요청입니다.

소프트 404 페이지

소프트 404는 200 OK 상태를 반환하지만 "페이지를 찾을 수 없음"이라고 표시하거나 빈 상품 목록을 보여주는 페이지입니다. 봇은 이 페이지를 크롤링하고 전체 HTML을 다운로드한 다음 콘텐츠가 가치 없다는 것을 파악해야 합니다. 실제 404 또는 410 상태 코드는 봇이 즉시 넘어가게 합니다. 소프트 404는 대역폭과 처리 시간 모두를 낭비합니다.

canonical 없는 중복 콘텐츠

URL의 세션 ID, www vs non-www 변형, HTTP vs HTTPS 버전, 후행 슬래시, 대소문자 변형 — 이 모두가 같은 콘텐츠에 대한 중복 진입점을 만듭니다. 적절한 canonical 태그와 리다이렉트 없이 봇은 각 변형을 별도로 크롤링하여 동일한 페이지에 버짓을 분산시킵니다.

무한 공간과 달력 트랩

일부 CMS 구성은 사실상 무한한 수의 URL을 생성하는 달력 위젯이나 페이지네이션 패턴을 만듭니다. 2099년까지 클릭할 수 있는 달력은 수천 개의 빈 페이지를 생성합니다. 마찬가지로 크롤 가능한 URL로 결과를 노출하는 검색 기능은 봇이 트리거한 쿼리에서 무한한 저가치 페이지를 생성할 수 있습니다.

큰 미디어 파일과 최적화되지 않은 리소스

봇이 모든 페이지에서 불필요하게 큰 이미지, 비축소 JavaScript 번들 또는 임베디드 비디오를 다운로드할 때 전송 시간이 크롤 윈도우 내에서 도달할 수 있는 페이지 수를 줄입니다. 이는 페이지 콘텐츠 이해에 필수적이지 않은 무거운 리소스일 때 특히 영향이 큽니다.

크롤 버짓을 최적화하는 방법

깨끗한 URL 구조 구축

기반부터 시작하세요. 색인 가능한 모든 URL은 고유하고 가치 있는 콘텐츠를 제공해야 합니다. 다음의 구조적 제어를 구현하세요:

  • 콘텐츠의 선호 버전을 가리키는 모든 페이지의 canonical 태그.
  • 파라미터 처리: robots.txt를 사용하여 알려진 불필요한 파라미터 조합을 차단하거나, 파라미터 변형에 대해 canonical 태그 또는 301 리다이렉트를 반환하는 서버 측 로직을 구현하세요.
  • 일관된 URL 형식: 하나의 규칙(소문자, 후행 슬래시 없음, HTTPS, www 포함 또는 불포함)을 선택하고 리다이렉트로 강제하세요.
  • 목적 있는 페이지네이션: 지원되는 곳에서 rel="next"와 rel="prev"를 사용하고, 페이지네이션 페이지가 내부 링크와 사이트맵을 통해 발견 가능하도록 보장하세요.

리다이렉트 체인 수정

리다이렉트를 감사하고 체인을 평탄화하여 모든 리다이렉트가 소스에서 최종 목적지로의 단일 홉이 되도록 합니다. 사이트 마이그레이션 후 내부 링크를 리다이렉트 체인에 의존하지 않고 새 URL을 직접 가리키도록 업데이트합니다. 콘텐츠가 진화함에 따라 새 체인이 생기는지 모니터링하세요 — 조용히 축적되는 경향이 있습니다.

적절한 HTTP 상태 코드 반환

삭제된 페이지는 404(찾을 수 없음) 또는 410(사라짐)을 반환해야 합니다. 이동된 페이지는 301(영구 리다이렉트)을 반환해야 합니다. 일시적으로 사용 불가능한 페이지는 Retry-After 헤더와 함께 503을 반환해야 합니다. 존재하지 않는 콘텐츠에 200 상태 코드를 제공하지 마세요 — 이는 크롤 버짓을 낭비하고 인덱스를 혼란시키는 소프트 404를 만듭니다.

서버 응답 시간 개선

서버가 빠르게 응답할수록 봇이 속도 제한 내에서 더 많은 페이지를 크롤링할 수 있습니다. 주요 레버:

  • 서버 측 캐싱: 가능하면 봇 요청에 대해 사전 렌더링된 HTML을 제공합니다.
  • CDN 배포: 봇의 위치에 가까운 엣지 노드에서 응답을 제공하여 지연 시간을 줄입니다.
  • 데이터베이스 최적화: 페이지 생성 시간에 영향을 미치는 느린 쿼리는 크롤 처리량을 직접 줄입니다.
  • HTTP/2 지원: 멀티플렉싱된 연결이 봇과 사용자 모두의 효율성을 향상시킵니다.
  • TTFB 모니터링: 중요한 페이지의 Time To First Byte를 200ms 이하로 유지합니다.

XML 사이트맵 관리

사이트맵은 봇에게 어떤 URL이 중요한지에 대한 직접적인 신호입니다. 다음으로 최적화하세요:

  • 색인 가능한 canonical URL만 포함 — 리다이렉트, noindex 페이지, 차단된 URL은 절대 나열하지 않습니다.
  • 콘텐츠 유형별(상품, 기사, 카테고리)로 사이트맵을 세분화하여 봇이 우선순위를 정할 수 있게 합니다.
  • 정확한 <lastmod> 날짜를 설정 — 콘텐츠가 실제로 변경될 때만 업데이트합니다. 거짓 최신 신호는 신뢰를 훼손합니다.
  • 파일당 50,000개 URL 또는 50MB 이하로 사이트맵을 유지하고, 대규모 사이트에는 사이트맵 인덱스를 사용합니다.
  • robots.txt 파일에서 사이트맵을 참조합니다.

내부 링크 강화

내부 링크를 통해 잘 연결된 페이지는 더 자주, 더 빠르게 크롤링됩니다. 내부 링크가 없는 고아 페이지는 사이트맵에 있더라도 발견되지 않을 수 있습니다. 브레드크럼 내비게이션, 관련 콘텐츠 모듈, 푸터 링크, 본문 내 맥락적 링크를 사용하여 밀도 있고 논리적인 링크 그래프를 만드세요.

저가치 영역의 크롤링 차단

robots.txt를 사용하여 검색 가치가 없는 경로를 차단하세요: 관리자 패널, 로그인 페이지, 내부 검색 결과, 장바구니 페이지, 인쇄용 중복본. 봇이 렌더링에 필요한 CSS, JavaScript, 이미지를 차단하지 않도록 주의하세요 — 이는 순위에 도움이 되기보다 해를 끼칠 수 있습니다.

서버 로그로 모니터링

봇이 사이트와 실제로 어떻게 상호작용하는지 이해하는 가장 신뢰할 수 있는 방법은 서버 로그 분석입니다. Search Console은 유용한 데이터를 제공하지만, 로그는 완전한 그림을 제공합니다.

로그에서 추출할 내용

  1. 봇 식별: User-Agent별로 요청을 필터링하여 Googlebot, Bingbot 및 기타 크롤러를 분리합니다.
  2. 일일 크롤링 페이지 수: 시간에 따른 총 봇 요청을 추적하여 추세와 이상 징후를 파악합니다.
  3. 상태 코드 분포: 봇 요청의 몇 퍼센트가 200, 301, 404, 5xx를 반환하는지?
  4. 요청당 응답 시간: 병목이 되는 느린 페이지를 식별합니다.
  5. 가장 많이/적게 크롤링되는 섹션: 봇의 관심을 비즈니스 우선순위와 비교합니다. 봇이 방문의 60%를 필터 페이지에, 5%를 상품 페이지에 소비한다면 버짓 할당 문제가 있습니다.
  6. URL별 크롤링 빈도: 핵심 페이지가 얼마나 자주 재방문되는지? 새 페이지가 신속하게 발견되는지?

로그 기반 모니터링 설정

접근 로그를 로그 관리 플랫폼(ELK 스택, Datadog, Splunk 또는 접근 로그를 파싱하는 간단한 스크립트)으로 전달합니다. 다음을 강조하는 대시보드를 구축하세요:

  • 봇별 일일 크롤링 볼륨.
  • 가장 많이 크롤링되는 상위 50개 URL.
  • 봇에 오류를 반환하는 URL.
  • 봇 요청의 평균 및 p95 응답 시간.

이 대시보드를 주간으로 검토하세요. 크롤링 볼륨의 갑작스러운 감소는 서버 문제, 실수로 인한 robots.txt 변경 또는 페널티를 나타낼 수 있습니다. 급증은 봇 루프나 크롤 트랩을 신호할 수 있습니다.

크롤 버짓과 Spider.es

Spider.es는 검색 엔진 봇이 사이트를 경험하는 방식을 시뮬레이션합니다. 링크를 따르고, robots.txt를 읽고, 상태 코드를 확인하고, 응답 시간을 측정하고, 내부 링크 그래프를 매핑합니다 — 크롤러와 동일한 관점을 제공합니다. 다음에 사용하세요:

  • 리다이렉트 체인을 식별하고 축적되기 전에 수정합니다.
  • 정상적인 크롤링으로는 봇이 도달할 수 없는 고아 페이지를 찾습니다.
  • 소프트 404와 잘못 구성된 상태 코드를 감지합니다.
  • 사이트맵에 깨끗하고 색인 가능한 URL만 포함되어 있는지 확인합니다.
  • 시뮬레이션된 봇 부하에서 서버 응답 시간을 측정합니다.

마치며

크롤 버짓은 대시보드에서 조회할 수 있는 숫자가 아닙니다 — 서버 성능, 콘텐츠 구조, 검색 엔진에 보내는 신호의 결과물입니다. 모든 리다이렉트 체인, 모든 파라미터 URL, 모든 소프트 404는 가치를 추가하지 않는 것에 낭비된 방문입니다. 누수를 수리하고, 신호를 강화하고, 로그를 통해 결과를 모니터링하세요. 모든 봇 방문이 중요할 때, 크롤링되는 모든 페이지는 그럴 가치가 있어야 합니다.

블로그 목록으로 돌아가기