본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.
[크롤링] 데이터 수집을 위한 크롤링 10편 : Sitemap XML과 sitemap index 사용법
Sitemap은 크롤러가 어떤 URL을 우선 발견해야 하는지 전달하는 표준 형식이다. 2026년 6월 11일 기준으로 확인한 sitemaps.org 프로토콜 문서와 Google Search Central 문서를 보면, Sitemap은 색인 보장을 약속하는 수단이 아니라 URL 발견과 메타데이터 전달을 돕는 입력에 가깝다.
실무에서 핵심은 세 가지다. XML sitemap에 어떤 태그가 실제로 필요한지, URL이 많을 때 sitemap index를 언제 써야 하는지, 그리고 robots.txt나 Search Console 제출과 어떤 관계인지다. 이 글은 그 기준만 짧게 정리한다.
Sitemap은 무엇을 해 주고 무엇은 보장하지 않을까?
sitemaps.org는 Sitemap을 사이트에서 크롤링 가능한 URL 목록을 검색엔진에 알리기 위한 방법으로 설명한다. Google 문서도 Sitemap이 페이지와 파일, 동영상 같은 콘텐츠 정보를 제공한다고 설명하지만, Sitemap에 넣었다고 해서 반드시 크롤되거나 색인된다고 말하지는 않는다.
즉 내부 링크가 약하거나 최근에 생성된 URL이 많거나, 대규모 사이트라서 발견 경로를 분명히 하고 싶을 때 Sitemap의 가치가 커진다. 반대로 작은 사이트에서 모든 페이지가 내부 링크로 잘 연결되어 있다면 반드시 필요한 것은 아니다.
XML sitemap의 최소 구조는 무엇일까?
sitemaps.org 프로토콜 기준으로 XML sitemap의 루트는 <urlset>이고 각 URL은 <url> 안에 넣는다. 각 URL에서 필수인 태그는 <loc> 하나뿐이다.
| 태그 | 필수 여부 | 의미 |
|---|---|---|
<loc> |
필수 | 정규화된 절대 URL |
<lastmod> |
선택 | 페이지가 마지막으로 수정된 날짜 또는 시각 |
<changefreq> |
선택 | 변경 빈도에 대한 힌트 |
<priority> |
선택 | 사이트 내부 URL 사이의 상대적 우선순위 힌트 |
기본 예시는 아래처럼 단순하다.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/docs/sitemap</loc>
<lastmod>2026-06-11</lastmod>
</url>
</urlset>
Google 문서는 XML 외에도 RSS, Atom, 텍스트 형식 Sitemap을 지원한다고 설명한다. 다만 메타데이터를 함께 전달해야 하거나 확장 네임스페이스를 쓸 가능성이 있으면 XML이 가장 일반적이다.
lastmod, changefreq, priority는 어떻게 써야 할까?
lastmod는 페이지가 실제로 의미 있게 변경된 시점을 넣는 편이 안전하다. sitemaps.org는 이 값이 서버의 If-Modified-Since 헤더가 반환하는 시간과는 별개라고 설명한다. 즉 파일을 재생성한 시각을 기계적으로 넣는 것보다, 사용자가 보게 되는 내용이 바뀐 시점을 반영해야 한다.
changefreq와 priority는 명령이 아니라 힌트다. sitemaps.org는 검색엔진 크롤러가 이 값을 다르게 고려할 수 있다고 설명한다. 따라서 모든 URL에 같은 높은 값을 넣는 방식은 정보량이 거의 없다.
운영 기준으로는 lastmod만 정확하게 관리해도 실효성이 높고, 나머지 두 태그는 실제로 구분할 근거가 있을 때만 쓰는 편이 낫다.
Sitemap index는 언제 필요할까?
URL 수가 많거나 섹션별로 파일을 나눠 관리해야 하면 sitemap index를 쓴다. Google 문서는 sitemap 한 개가 최대 50MB 비압축 크기 또는 URL 50,000개 제한을 가진다고 설명하고, 여러 파일을 묶을 때 sitemap index를 사용할 수 있다고 안내한다.
예를 들어 상품, 게시글, 문서, 이미지처럼 생성 경로가 다른 URL을 따로 만들고 싶다면 post-sitemap.xml, product-sitemap.xml처럼 분리한 뒤 index 파일에서 참조하는 편이 운영과 장애 추적에 유리하다.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemaps/post-sitemap.xml</loc>
<lastmod>2026-06-11</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemaps/product-sitemap.xml</loc>
</sitemap>
</sitemapindex>
robots.txt와 Search Console 제출은 어떤 차이가 있을까?
Google 문서는 Sitemap을 알리는 방법으로 두 가지를 먼저 제시한다. 하나는 robots.txt에 Sitemap URL을 적는 방법이고, 다른 하나는 Search Console을 통한 제출이다. robots.txt 방식은 배포가 단순하고 여러 크롤러에게 한 번에 힌트를 줄 수 있다는 장점이 있다.
반면 Search Console 제출은 Google 관점에서 처리 상태를 확인하기 쉽다. 제출 결과, 읽기 오류, 발견 URL 수 같은 운영 신호를 보기 좋기 때문이다. 둘은 상호 배타적이지 않아서, 배포는 robots.txt로 하고 모니터링은 Search Console로 하는 조합이 일반적이다.
여러 도메인을 한 Sitemap에 넣어도 될까?
sitemaps.org 프로토콜 문서는 Sitemap에 들어가는 모든 URL이 같은 호스트에 속해야 한다고 설명한다. 기본 규칙만 보면 https://example.com/sitemap.xml 안에 다른 호스트 URL을 함께 넣는 것은 피하는 편이 맞다.
다만 Google 문서는 소유권이 검증된 여러 사이트라면 한 위치의 Sitemap에서 여러 검증 사이트 URL을 참조하는 교차 제출(cross-site submission) 시나리오를 별도로 설명한다. 이것은 검색엔진별 지원 범위가 다를 수 있다는 뜻이다. 실무에서는 특정 엔진 전용 예외를 기대하기보다, 사이트 단위로 파일을 분리하는 구성이 더 보수적이다.
운영 기준만 빠르게 정리하면?
| 상황 | 권장 기준 |
|---|---|
| URL 수가 적고 내부 링크가 충분함 | Sitemap은 선택 사항이지만 있으면 운영 추적이 쉬워진다 |
| 신규 URL이 자주 생기거나 대규모 사이트임 | XML sitemap을 두고 lastmod를 정확히 관리한다 |
| 50,000 URL 또는 50MB 제한에 근접함 | 파일을 분리하고 sitemap index로 묶는다 |
| 검색엔진 처리 상태를 추적해야 함 | robots.txt 공개와 Search Console 제출을 함께 쓴다 |
| 여러 도메인이나 서브사이트를 운영함 | 기본값은 사이트별 분리, 예외는 엔진별 문서를 따로 확인한다 |
자주 묻는 질문
Q. Sitemap에 없는 URL은 색인될 수 없을까?
그렇지 않다. Sitemap은 발견을 돕는 입력이지 유일한 발견 경로가 아니다. 내부 링크나 외부 링크를 통해서도 URL은 크롤될 수 있다.
Q. 모든 URL에 priority를 1.0으로 넣으면 더 유리할까?
그렇게 볼 근거는 없다. sitemaps.org는 priority를 사이트 내부 URL 간 상대값으로 설명한다. 대부분을 최고값으로 채우면 구분 신호가 사라진다.
Q. lastmod는 배포 시각을 자동으로 넣어도 될까?
항상 적절하지는 않다. 실제 내용 변경이 없는데 매 배포마다 값을 바꾸면 메타데이터 신뢰도가 떨어질 수 있다. 문서 내용 변경 시점과 연결되는 방식이 더 안전하다.
정리
Sitemap 운영에서 가장 중요한 것은 형식을 복잡하게 만드는 것이 아니라, 검색엔진이 이해할 수 있는 안정적인 URL 목록과 신뢰할 수 있는 갱신 신호를 제공하는 것이다. 대부분의 서비스에서는 XML sitemap 하나로 시작하고, URL 규모가 커질 때 sitemap index로 분리하는 순서가 무난하다.
크롤링 파이프라인 관점에서도 같은 기준이 적용된다. 수집 대상 URL 목록을 정기적으로 갱신해야 한다면, 내부 링크만 믿기보다 Sitemap을 명시적으로 관리하는 편이 장애 분석과 재수집 범위 판단에 유리하다.
참고 자료
'시리즈물 > 데이터 수집을 위한 크롤링' 카테고리의 다른 글
| [크롤링] 데이터 수집을 위한 크롤링 9편 : Last-Modified와 If-Modified-Since 사용법 (0) | 2026.05.22 |
|---|---|
| [크롤링] 데이터 수집을 위한 크롤링 8편 : ETag와 If-None-Match로 변경된 페이지만 다시 받는 방법 (0) | 2026.05.14 |
| [크롤링] 데이터 수집을 위한 크롤링 5편 : Yahoo 파이낸스를 이용한 환율 크롤링 (422) | 2019.03.02 |
| [크롤링] 데이터 수집을 위한 크롤링 4편 : Java의 설치와 간단한 Jsoup 예제 (1) | 2019.03.02 |
| [크롤링] 데이터 수집을 위한 크롤링 3편 : JSON, 더 자세한 설명 (434) | 2019.03.02 |