크롤 예산은 SEO에서 가장 과하게 인용되는 개념 중 하나입니다. 300페이지짜리 마케팅 사이트에는 사실상 무의미합니다. 반면 필터가 조합형 URL을 만들어내는 커머스에서는 신규 상품이 하루 만에 검색에 잡히느냐, 6주 뒤에 잡히느냐를 가르는 문제가 됩니다.
이 글은 두 상황을 구분하고, 두 번째 경우를 해결하는 방법에 대한 것입니다.
크롤 예산이란 무엇인가
크롤량은 두 가지 힘으로 결정됩니다.
크롤 속도 한계 — 크롤러가 서버에 가할 의향이 있는 부하입니다. 응답이 느리거나 5xx가 늘면 내려가고, 빠르고 안정적이면 올라갑니다.
크롤 수요 — 크롤러가 그 URL을 얼마나 원하는지입니다. 인기도, 내부 링크, 실제 콘텐츠 변경 빈도가 좌우합니다.
실제 예산은 둘 중 작은 값입니다. 서버는 빠른데 수요가 없으면 적게 크롤되고, 인기는 많은데 서버가 느리면 스로틀링됩니다.
우리 사이트에 해당되는 문제인가
한 스프린트를 투입하기 전에 냉정하게 판단하세요.
| 상황 | 크롤 예산 고려 |
|---|---|
| URL 1,000개 미만, 변동 적음 | 불필요. 콘텐츠와 링크에 투자 |
| URL 1,000~10,000개 | 경계선. 점검은 하되 프로젝트는 아님 |
| URL 10,000개 초과 | 필요 |
| 패싯 내비게이션·검색 결과 URL 존재 | 규모 무관하게 필요 |
| 자주 갱신되는 카탈로그·피드 | 필요 |
| 느린 서버(TTFB 600ms 이상) | 필요 |
첫 번째 행에 해당한다면 이 글을 닫고 내부 링크 점검에 시간을 쓰는 편이 훨씬 남습니다.
예산이 어디로 새는가: 로그부터 봅니다
진단은 항상 서버 로그에서 시작합니다. 우리가 '그럴 것'이라 가정한 요청이 아니라, 크롤러가 실제로 요청한 것이 로그에 있기 때문입니다. 검증된 검색엔진 UA로 필터링한 뒤 URL 패턴별로 집계합니다.
- 어떤 경로 패턴이 요청을 가장 많이 흡수하는가
- 200 / 3xx / 4xx / 5xx 비중은 어떻게 되는가
- 쿼리 파라미터가 붙은 URL의 요청 비중은 얼마인가
- 중요한 페이지들이 마지막으로 크롤된 시점은 언제인가
전형적인 결과는 이렇습니다. 전체 크롤 요청의 60~80%가 아무도 색인을 원하지 않는 파라미터 URL로 향하고, 정작 중요한 카테고리 페이지는 한 달에 한 번 방문됩니다.
가장 큰 낭비 요인 5가지와 해법
1. 패싯 내비게이션
?color=black&size=m&sort=price&page=3 — 필터 몇 개가 수천 개의 URL 조합을 만들고, 내용은 거의 같습니다.
권장 순서대로의 해법:
- 색인이 불필요한 필터는 크롤 불가능한 방식(POST, 클라이언트 처리
#프래그먼트)으로 구현합니다. - 필터 뷰의 canonical을 필터 없는 카테고리 페이지로 지정합니다.
- 실제 검색 수요가 있는 조합(예: '블랙 원피스')만 깔끔한 URL로 별도 생성하고 링크로 연결한 뒤, 나머지는 크롤 대상에서 제외합니다.
robots.txt차단은 최후의 수단입니다. 크롤은 멈추지만 이미 색인된 URL은noindex를 읽을 수 없어 그대로 남습니다.
2. 리다이렉트 체인
홉 하나가 요청 하나입니다. A → B → C → D는 페이지 하나를 위해 4번을 씁니다. 사이트를 크롤링해 모든 3xx를 뽑고, 각 체인을 1홉으로 줄이세요. 그다음 출발점을 고칩니다. 옛 URL을 가리키는 내부 링크는 최종 목적지로 직접 교체해야 합니다. 리다이렉트는 안전망이지 링크 전략이 아닙니다.
3. 소프트 404와 얇은 페이지
'결과 없음'을 200으로 반환하는 페이지, 비어 있는 카테고리, 종료된 캠페인 페이지는 크롤을 소모하면서 품질 신호까지 희석합니다. 실제로 사라진 콘텐츠는 404 또는 410을 반환하고, 빈 카테고리는 통합하세요.
4. 중복 URL 형태
같은 문서가 /page, /page/, /Page, /page?utm_source=x, http/https, www/비www로 접근 가능하면 한 페이지에 6번의 크롤이 들어갑니다. 서버 리다이렉트로 하나의 정규 형태를 강제하고, 내부 링크도 그 형태로 통일하며, 트래킹 파라미터는 링크 그래프에 들어오기 전에 제거하세요.
5. 느린 응답
크롤 속도는 응답 시간에 직접 반응합니다. TTFB를 800ms에서 200ms로 줄이면 다른 변경 없이도 수 주 내에 일일 크롤량이 눈에 띄게 증가하는 경우가 많습니다. 그 시간이 어디에 숨어 있는지는 Core Web Vitals 가이드에서 다룹니다.
예산을 올바른 페이지에 쓰기
낭비를 줄이는 것은 절반이고, 나머지 절반은 관심을 유도하는 일입니다.
깊이를 줄입니다. 홈에서 4클릭 거리의 페이지는 2클릭 거리보다 훨씬 적게 크롤됩니다. 허브 페이지, 잘 설계된 카테고리 구조, 본문 내 문맥 링크가 중요한 페이지를 위로 끌어올립니다. 여기서 지렛대는 IA입니다. 정보 구조가 깊고 좁으면 사이트맵을 아무리 손봐도 보완되지 않습니다.
고아 페이지를 없앱니다. 사이트맵에는 있는데 내부 링크가 하나도 없는 URL은 발견은 되어도 대체로 무시됩니다. 색인 가치가 있는 페이지는 클릭으로 도달 가능해야 합니다.
lastmod를 정직하게 유지합니다. 정확한 변경 시각은 크롤러가 변하지 않은 페이지를 건너뛰고 바뀐 페이지를 다시 보게 만듭니다. 값을 가짜로 채우면 이 장치 자체가 무력화됩니다(사이트맵 가이드).
사이트맵을 유형별로 분리합니다. 콘텐츠 유형별 파일이 있어야 크롤이 중요한 영역에 닿고 있는지 확인할 수 있습니다.
30일 실행 계획
- 1주차 — 최근 30일 서버 로그를 확보해 경로 패턴·상태 코드별로 분류합니다. DeepAnalyzer로 사이트를 크롤링해 상태 코드와 canonical이 포함된 전체 URL 인벤토리를 내보냅니다.
- 2주차 — 두 결과를 비교합니다. 크롤은 되는데 인벤토리에 없는 것은 낭비이고, 인벤토리에는 있는데 크롤되지 않은 것은 발견 문제입니다.
- 3주차 — 상위 3개 낭비 패턴을 수정합니다. 보통 파라미터 처리, 리다이렉트 체인, 통제되지 않은 패싯 영역 하나입니다.
- 4주차 — 로그를 다시 받습니다. 200 + canonical 페이지로 향하는 요청 비중이 측정 가능하게 올라가야 합니다.
절대 요청 수가 아니라 비율을 보세요. 전체 크롤량은 우리가 통제할 수 없는 이유로도 움직이지만, 색인 대상 페이지로 향하는 비중은 우리가 실제로 움직일 수 있는 숫자입니다.
자주 묻는 질문
크롤 예산이 우리 문제인지 어떻게 판단하나요?
Search Console의 '마지막 크롤 날짜'를 발행 주기와 비교해 보세요. 3주 전에 수정한 페이지가 아직 재크롤되지 않았고 로그에는 파라미터 URL 크롤이 가득하다면 예산 배분 문제입니다. 중요한 페이지가 매일 크롤되는데도 색인되지 않는다면 그건 예산이 아니라 품질 문제입니다.
robots.txt 차단이 크롤 예산을 아껴주나요?
아껴주지만 무딘 도구입니다. 이미 색인된 URL은 콘텐츠 없이 남습니다. 크롤러가 더 이상 noindex를 볼 수 없기 때문입니다. canonical 처리나 링크 제거를 우선하고, robots.txt는 애초에 크롤되면 안 되는 영역에 쓰세요.
내부 링크에 nofollow를 걸면 예산이 절약되나요?
유의미하지 않습니다. nofollow는 과거처럼 흐름을 보존하지 않고, URL은 다른 경로로도 발견됩니다. 링크를 걸지 않거나 URL 자체를 생성하지 않는 구조적 해법이 훨씬 효과적입니다.
사이트맵을 크게 만들면 크롤 예산에 도움이 되나요?
발견에는 도움이 되지만 예산에는 아닙니다. URL 5만 개를 나열한다고 크롤이 늘지는 않습니다. 깊이와 내부 링크를 먼저 고치세요.
효과는 언제쯤 보이나요?
로그 수준 변화는 며칠 내에 보입니다. 색인 커버리지 변화는 보통 2~6주, 대규모 사이트는 더 걸립니다. 한 주에 다섯 가지를 동시에 바꾸지 마세요. 원인 귀속이 불가능해집니다.