구글 서치 콘솔(Google Search Console)의 '크롤링 예산(Crawl Budget)' 낭비를 막기 위해 robots.txt와 sitemap.xml을 설계하는 정석 공식은?

페이지 수가 1만 개 이하이고 주간 단위로 업데이트되는 중소형 사이트라면 크롤링 예산을 크게 신경 쓸 필요가 없습니다 — 사이트맵을 최신 상태로 유지하는 정도면 충분합니다. 크롤링 예산 최적화가 실제로 중요해지는 건 이커머스·뉴스·엔터프라이즈처럼 페이지 수가 매우 많은 대형 사이트입니다. 브랜드사 자사몰이라도 상품 수가 수만 개를 넘지 않는다면, 아래 원칙을 몰라도 크게 손해 보지 않습니다.

규모가 크다면 개념부터 정확히 아셔야 합니다. 크롤링 예산은 크롤링 속도 제한(구글봇이 보낼 수 있는 최대 요청 수, 서버 부하 감당 능력)과 크롤링 수요(콘텐츠 인기도·신선도에 기반한 구글의 관심도) 중 더 작은 값으로 결정됩니다. 서버 성능을 올려 속도 제한을 늘려도 크롤링 수요 자체가 낮으면 실제 크롤링 빈도는 늘지 않습니다.

robots.txt를 설계할 때 흔한 오해가 하나 있습니다. robots.txt는 크롤링 예산을 일시적으로 다른 곳에 재배분하는 용도가 아닙니다. 필터·정렬 파라미터, 내부검색 결과처럼 원치 않는 페이지를 차단하는 용도로만 써야 하며, 이미 사이트가 크롤링 한계치에 도달한 상태가 아니라면 robots.txt로 새로 확보된 여유 예산이 자동으로 다른 중요 페이지에 옮겨가지 않습니다. 즉 '중요하지 않은 페이지를 막으면 중요한 페이지가 더 잘 크롤링된다'는 기대는 이미 예산이 꽉 찬 대형 사이트에만 해당합니다.

sitemap.xml에는 크롤링을 원하는 모든 URL을 포함하고 lastmod 태그로 변경 시점을 알려야 구글이 더 효율적으로 재방문합니다. 사이트맵을 제출한 뒤에는 서치 콘솔에서 '제출된 URL'과 '색인된 URL' 수를 비교해, 그 격차가 robots.txt 차단 규칙 때문에 생긴 것은 아닌지 점검하는 루틴을 만들어두세요. 마지막으로 영구 삭제한 페이지는 반드시 404나 410 상태 코드를 반환하도록 처리해 구글에 재크롤링 불필요 신호를 명확히 보내야 낭비를 줄일 수 있습니다.