상품 수만 개 규모의 몰에서 크롤 예산과 색인 누락을 관리하는 방법

상품이 수만 점인 몰에서 신상품 색인이 느려지고, Search Console의 '발견됨 - 현재 색인이 생성되지 않음'이 만 단위로 쌓이는 상황이 있습니다. 크롤 예산 관리와 색인 누락을 함께 다뤄야 하는 국면입니다.

이 규모에서는 크롤러가 일정 기간에 처리할 수 있는 URL 수의 상한이 색인 누락의 직접 원인이 됩니다. 수천 점까지는 신경 쓰지 않아도 됐던 요소가 수만 점을 넘으면 결과를 좌우합니다.

답은 4가지 작업을 한 세트로 운영하는 방식입니다. 사이트맵 분할과 lastmod의 정확도, 저가치 URL 차단이 둘입니다. 내부 링크로 우선순위 전하기와 봇 로그 관측이 나머지 둘입니다. 어느 하나만으로는 효과가 없습니다.

결론: 4가지를 한 세트로 운영한다

작업	목적	단독으로 했을 때의 한계
사이트맵 분할과 lastmod	"무엇을, 언제 갱신했는지"를 정확히 전달한다	저가치 URL이 대량으로 있으면 크롤러는 사이트맵보다 발견한 링크를 우선하는 경우가 있다
저가치 URL 차단	필터·정렬·중복 URL에 예산을 쓰게 하지 않는다	차단해도 내부 링크가 가리키고 있으면 발견은 계속된다
내부 링크의 우선순위	중요한 페이지에 링크를 많이 모으고, 깊은 계층을 얕게 한다	사이트맵과 lastmod가 부정확하면 갱신 감지가 늦어진다
봇 로그 관측	실제로 어떤 URL이 수집되고 있는지 본다	관측만으로는 개선되지 않는다. 위 3가지의 효과 검증에 쓴다

중요한 관점: 크롤 예산은 크롤러가 그 사이트에 쓰는 시간과 횟수입니다. 사이트 규모와 응답 속도, 크롤러가 발견하는 URL 수로 정해집니다. 창고 점검 시간이 정해져 있다면 빈 선반부터 치워야 하는 것과 같습니다. 먼저 "봐 주었으면 하는 URL"과 "안 봐도 되는 URL"을 가릅니다.

색인 누락이 생기는 구조

수만 점 규모의 몰에서 색인 누락이 생기는 전형적인 경로입니다.

필터·정렬·페이지네이션으로 상품 수의 수십 배에 달하는 URL이 생긴다
크롤러는 이것들을 발견하고 수집한다(canonical이나 noindex는 수집 후에 읽힌다)
예산의 대부분이 저가치 URL 수집에 쓰인다
신상품·갱신 상품의 발견이 늦어지고 "발견됨 - 현재 색인이 생성되지 않음"이 늘어난다
게재 종료된 상품의 URL이 그대로 남아 오류나 빈약한 페이지로서 예산을 더 쓴다

Search Console에서 "크롤됨 - 현재 색인이 생성되지 않음"과 "발견됨 - 현재 색인이 생성되지 않음"의 URL을 종류별로 나눕니다. 그러면 이 경로의 어디에서 막혀 있는지 보입니다. 두 항목의 URL을 필터·정렬·상품으로 분류하는 데서 시작합니다.

사이트맵 운영: 분할과 lastmod

항목	권장	이유
분할 단위	상품·카테고리·콘텐츠로 나누고, 1파일당 5만 URL 이하	종류별로 색인 상황을 추적할 수 있다
인덱스 파일	사이트맵 인덱스로 묶는다	전송 대상을 하나로 할 수 있다
lastmod	실제로 내용이 바뀐 일시만 갱신	모든 URL을 매일 갱신하면 lastmod가 신뢰받지 못하게 된다
게재 종료 상품	사이트맵에서 빼고 404 또는 410을 반환	존재하지 않는 URL에 대한 수집을 줄인다
게재 대상	canonical이 자기 자신을 가리키는, index 가능한 URL만	중복 URL을 실으면 예산을 낭비한다

lastmod의 정확도가 특히 결과를 좌우합니다. 재고 수가 바뀔 때마다 lastmod를 갱신하면 크롤러는 항상 갱신되는 사이트로 받아들이고, 이 값을 갱신 신호로 쓰지 않게 됩니다. 가격·설명·사양이 바뀔 때만 lastmod를 갱신하도록 바꿉니다.

저가치 URL 차단: 종류별 처리

URL의 종류	예	처리
정렬	?sort=price	robots.txt로 크롤을 금지하거나 canonical을 부모로 향하게 한다
필터(수요 없음)	?color=red&size=M	robots.txt로 금지
필터(수요 있음)	"남성 방수 재킷" 등 검색되는 조합	설명문을 가진 정식 카테고리 페이지로 승격하고 index로 한다
페이지네이션	?page=2	index 가능한 상태로 두고, canonical은 각 페이지 자신
세션·트래킹	?utm=, ?sid=	robots.txt로 금지
게재 종료 상품	구 URL	404/410. 후속 상품이 있으면 리다이렉트

robots.txt로 크롤을 막은 URL은 canonical도 noindex도 읽히지 않습니다. 문을 잠그면 안에 붙인 안내문도 볼 수 없는 것과 같습니다. 이미 색인된 URL을 빼려면 먼저 noindex로 색인에서 지웁니다. 색인에서 사라진 뒤에 robots.txt로 막는 순서를 지킵니다.

내부 링크로 우선순위를 전달한다

크롤러는 링크가 많이 모이는 페이지와 톱 페이지에서 가까운 페이지를 우선합니다. 수만 점 규모에서는 아래 3가지를 확인합니다.

주력 상품·주력 카테고리가 톱 페이지에서 3클릭 이내에 있는가
카테고리 페이지의 페이지네이션이 너무 깊지 않은가(한 카테고리에 수백 페이지가 이어진다면 서브카테고리로 나눈다)
상품 페이지에서 관련 상품·상위 카테고리로의 링크가 템플릿에서 일관되게 나오는가

봇 로그 관측

위 3가지의 효과는 봇 로그로만 검증됩니다. 최소한 아래 항목은 주간으로 확인합니다.

지표	봐야 할 변화
수집 URL 중 저가치 URL의 비율	줄고 있는가
수집 URL 중 상품 페이지의 비율	늘고 있는가
신상품이 공개부터 수집되기까지의 일수	짧아지고 있는가
4xx·5xx 응답 수	줄고 있는가
Googlebot 이외(GPTBot, PerplexityBot 등)의 수집 대상	상품 페이지에 도달하고 있는가

마지막 항목은 AI 검색의 상품 추천에 직결됩니다. AI 쪽 봇이 저가치 URL에 예산을 다 써서 상품 페이지까지 가지 못하는 사례가 드물지 않습니다. AI 봇 로그에서 상품 페이지 도달 여부를 확인합니다.

수만 점 규모의 운영은 수작업으로는 이어지지 않는다

여기까지의 작업은 한 번 하면 끝나지 않습니다. 상품은 매일 추가되고 종료됩니다. 필터 조건은 늘고 템플릿은 바뀝니다. 사이트맵은 검색 엔진에 넘기는 페이지 URL 목록입니다. 사이트맵의 정확도, 차단 규칙의 타당성, 내부 링크 상태, 봇의 수집 경향을 계속 다시 봐야 합니다.

Search OS는 이 지속적인 부분을 운영으로 맡습니다. 기존 몰의 구조는 바꾸지 않습니다. 검색 엔진과 AI 크롤러용 사이트맵·canonical·메타데이터·구조화 데이터를 별도 층으로 제공합니다. 봇 로그로 Googlebot·GPTBot·PerplexityBot이 어떤 URL을 얼마나 가져가는지 계속 관측합니다. 그렇게 색인 누락의 원인이 되는 URL군과 우선 고칠 곳을 정리합니다. 수백만 페이지 규모에서도 크롤러가 "봐 주었으면 하는 페이지"에 도달하는 상태를 유지하는 것이 목적입니다.

자주 묻는 질문

크롤 예산은 신청해서 늘릴 수 있나요?

늘릴 수 없습니다. 사이트 응답 속도를 높이고 불필요한 URL을 줄이면, 같은 예산으로 처리되는 중요 URL이 늘어납니다.

필터 URL을 모두 noindex로 하면 해결되나요?

noindex는 색인에서 빼지만 수집은 계속됩니다. 예산을 줄이려면 robots.txt로 막아야 합니다. 다만 검색 수요가 있는 조합은 정식 페이지로 승격시킵니다.

AI 검색의 봇도 크롤 예산의 영향을 받나요?

받습니다. GPTBot 등은 사이트 구조와 응답 속도에 따라 수집 범위를 정합니다. 저가치 URL이 많은 사이트에서는 상품 페이지에 닿기 전에 수집을 끝내기도 합니다. GPTBot이 상품 페이지에 도달했는지 로그로 확인합니다.

함께 읽기

참고 자료

Google Search Central: Managing crawl budget for large sites
Google Search Central: Managing large sitemaps
Google Search Central: Faceted navigation best practices
Google Search Central: Page Indexing report