사이트맵은 페이지를 색인시켜 주는 도구가 아닙니다. 페이지의 존재를 알리는 도구입니다. 이 차이를 이해하면 "사이트맵 제출했는데 왜 40%만 색인됐죠?"라는 대화가 훨씬 짧아집니다.
이 글에서는 사이트맵이 할 수 있는 일과 할 수 없는 일, 수천 개 URL을 가진 사이트에서의 구조 설계, 그리고 제출 후 확인해야 할 지표를 정리합니다.
사이트맵이 실제로 필요한 순간
검색엔진이 URL을 발견하는 경로는 두 가지입니다. 링크를 따라가는 방식과, 우리가 건네준 목록을 읽는 방식입니다. 링크 기반 발견이 기본이며, 여기에는 중요도 신호까지 포함됩니다. GNB에 노출된 페이지는 4뎁스 아래 묻힌 페이지보다 명백히 중요합니다. 사이트맵에는 그런 신호가 없습니다. 사이트맵은 재고 목록입니다.
그래서 사이트맵이 결정적으로 유용한 상황은 다음 세 가지입니다.
- 링크가 약한 페이지 — 신규 아티클, 시즌 랜딩, 필터 뒤 페이지네이션에만 노출되는 상품 상세
- 대규모 사이트 — URL 1만 개를 넘어가면 순회만으로 전체를 발견하기 어렵습니다
- JavaScript 내비게이션 사이트 — 메뉴가 프레임워크 라우터로만 동작하고 실제
href가 없다면 링크 발견이 거의 작동하지 않습니다 (JS 렌더링과 크롤링 참고)
HTML 메뉴가 깔끔한 200페이지 사이트라면 사이트맵은 있으면 좋은 수준입니다. 4만 SKU 커머스라면 사이트맵은 인프라입니다.
구조: 단일 파일과 사이트맵 인덱스
단일 사이트맵은 URL 5만 개, 압축 해제 기준 50MB가 상한입니다. 그 이상이면 다른 사이트맵 파일을 나열하는 사이트맵 인덱스가 필요합니다.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-08-28</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-09-01</lastmod>
</sitemap>
</sitemapindex>
분할 기준은 숫자가 아니라 콘텐츠 유형이어야 합니다. sitemap-1.xml ~ sitemap-9.xml보다 sitemap-pages / products / blog 구성이 훨씬 낫습니다. Search Console이 사이트맵 파일 단위로 색인 현황을 보여주기 때문입니다. 상품 색인이 30% 빠졌을 때, 유형별 분할이면 즉시 원인 영역이 보이지만 번호별 분할이면 아무것도 알 수 없습니다.
4개 태그의 실제 가치
| 태그 | 실효성 | 권장 |
|---|---|---|
<loc> |
필수 | canonical과 완전히 동일한 절대 URL(프로토콜·호스트·슬래시 규칙 포함) |
<lastmod> |
정직하면 유효 | 실제 콘텐츠 변경 시각. 매일 전체가 갱신되면 신뢰도를 잃습니다 |
<changefreq> |
사실상 무시 | 생략 가능 |
<priority> |
사실상 무시 | 생략 가능 |
실무에서 가장 자주 발목을 잡는 건 lastmod입니다. CMS가 배포 시각이나 오늘 날짜를 자동으로 찍으면, 크롤러는 이 값이 노이즈라고 학습합니다. 그러면 정작 필요한 페이지에서도 재크롤 힌트로 쓰이지 않습니다.
canonical 일관성이 핵심입니다
사이트맵의 모든 URL은 "이 주소로 색인되길 원한다"는 선언입니다. 이 선언을 다른 곳에서 뒤집는 것이 '발견됨 – 현재 색인되지 않음' 상태의 가장 흔한 원인입니다.
다음 네 가지는 항상 함께 점검하고, 서로 모순되지 않아야 합니다.
- 사이트맵에 적힌 URL
- 해당 페이지의
rel="canonical" - 해당 페이지의
meta robots robots.txt의 해당 경로 허용 여부
다른 주소로 canonical이 걸린 URL을 사이트맵에 넣는 것은 낭비입니다. robots.txt로 막힌 URL을 넣는 것은 더 나쁩니다. 크롤러가 페이지를 읽을 수 없으니 함께 설정한 noindex도 볼 수 없고, 결과적으로 내용 없는 URL이 색인에 남을 수 있습니다. 색인에서 빼고 싶다면 크롤은 허용하고 noindex를 내려주세요. robots.txt 차단은 같은 의미가 아닙니다.
넣을 것과 빼야 할 것
색인 대상 canonical 주소가 아니면 모두 제외합니다.
- 리다이렉트(3xx)·오류(4xx/5xx) URL
- 다른 URL로 canonical이 걸린 페이지
noindex페이지- 2페이지 이후의 페이지네이션(대부분의 경우)
- 필터·패싯 조합 URL — 전형적인 크롤 예산 낭비 요인입니다(크롤 예산 최적화)
?sort=,?utm_, 세션 ID 등 파라미터 중복
검색 결과에 그대로 노출되어도 괜찮은 주소만 남기면 됩니다.
다국어 사이트: 사이트맵 안의 hreflang
한국어·영어 버전을 함께 운영한다면, 모든 페이지 <head> 대신 사이트맵에서 언어 대체 관계를 선언할 수 있습니다.
<url>
<loc>https://example.com/en/pricing</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
<xhtml:link rel="alternate" hreflang="ko" href="https://example.com/ko/pricing"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
</url>
가장 많이 틀리는 규칙은 상호 참조와 자기 참조입니다. 각 URL은 자기 자신을 포함해 모든 대체 버전을 나열해야 합니다. 한쪽만 선언하면 전체가 무시됩니다. 자세한 실패 사례는 hreflang 가이드에서 다룹니다.
제출과 모니터링
어떤 크롤러든 찾을 수 있도록 robots.txt에 위치를 명시합니다.
Sitemap: https://example.com/sitemap.xml
그다음 Google Search Console과 네이버 서치어드바이저에 제출합니다. 이후 볼 지표는 '제출 수'가 아니라 사이트맵 파일별 제출 대비 색인 비율의 추세입니다.
정상 패턴은 몇 주에 걸쳐 색인 수가 제출 수에 근접한 뒤 함께 움직이는 형태입니다. 비정상 패턴은 제출은 늘어나는데 색인은 정체되는 형태이고, 이 격차의 원인은 거의 항상 발견이 아니라 품질이나 중복입니다. 재제출로는 해결되지 않습니다.
실무 점검 루틴
월 1회, 또는 URL 구조를 건드리는 릴리즈 전에 다음을 수행합니다.
- 사이트를 크롤링해 전체 URL 인벤토리를 추출합니다. (DeepAnalyzer는 IA 시트와 함께 이 목록을 만들어 줍니다.)
- 크롤 결과와 사이트맵을 비교합니다. 크롤에는 있는데 사이트맵에 없으면 발견 누락, 사이트맵에만 있으면 대개 고아 페이지이거나 오래된 항목입니다.
- 사이트맵 URL의 상태 코드와 canonical을 확인합니다. 200 + 자기 참조 canonical이 아닌 것은 제외합니다.
- 사이트맵 파일별 제출/색인 비율을 지난달과 비교합니다.
이 루프만 돌려도 색인 관련 회귀의 대부분을 트래픽 변화가 보고되기 전에 잡아낼 수 있습니다.
자주 묻는 질문
사이트맵을 제출하면 반드시 색인되나요?
아닙니다. 사이트맵은 발견을 돕는 장치입니다. 색인 여부는 크롤 가능 여부, canonical 정합성, 저장할 가치가 있는 콘텐츠인지에 따라 결정됩니다. 내용이 얇거나 중복된 페이지는 아무리 제출해도 색인되지 않는 경우가 많습니다.
사이트맵은 얼마나 자주 갱신해야 하나요?
URL 인벤토리가 바뀔 때마다입니다. CMS나 커머스라면 동적으로 생성해 페이지 발행과 동시에 반영되게 하세요. 분기마다 수동 갱신하는 정적 파일은 없는 것보다 나쁩니다. lastmod를 믿지 않도록 학습시키기 때문입니다.
페이지네이션도 사이트맵에 넣어야 하나요?
보통 1페이지만 넣습니다. 나머지는 크롤로 도달 가능하고 자기 참조 canonical만 갖추면 충분합니다. 전부 넣으면 사이트맵만 비대해지고 개별 아이템 발견에는 도움이 되지 않습니다.
어느 규모에서 사이트맵을 분할해야 하나요?
하드 리밋은 URL 5만 개·50MB이지만 훨씬 이전에 콘텐츠 유형 기준으로 나누세요. 5만 개짜리 1개 파일보다 5천 개짜리 유형별 10개 파일이 진단에 훨씬 유용합니다.
HTML 사이트맵 페이지도 여전히 필요한가요?
사용자를 위해서라면 경우에 따라 필요합니다. 크롤러를 위해서라면 잘 설계된 GNB와 XML 사이트맵이 더 낫습니다. 실제 방문자가 사용하는 경우에만 만드세요.