sitemap.xml 만들기와 제출: 색인을 앞당기는 법

sitemap.xml은 “우리 사이트에 이런 URL들이 있다”를 검색엔진에게 알려주는 목록 파일이다. 역할을 정확히 이해하는 게 먼저다. 사이트맵은 발견(discovery)을 돕는 보조 수단이지, 순위를 올려주는 신호가 아니고, 등록했다고 색인을 보장하지도 않는다. 내부링크가 촘촘한 소규모 사이트라면 사이트맵 없이도 구글은 대부분의 페이지를 찾는다. 반대로 신규 사이트, 페이지가 수천 개인 사이트, 내부링크로 도달하기 어려운 페이지(아카이브·필터 뒤에 숨은 상세 페이지)가 있는 사이트에서는 사이트맵이 색인 속도를 실제로 앞당긴다.

이 가이드는 최소 형식의 사이트맵을 손으로 작성하는 것부터 시작해, lastmod를 구글이 신뢰하게 쓰는 법, 50,000개 URL 제한과 사이트맵 인덱스, 넣어야 할 URL과 절대 넣으면 안 되는 URL, 그리고 구글 서치콘솔·네이버 서치어드바이저·빙 웹마스터에 제출하고 결과를 해석하는 법까지 순서대로 다룬다. 작성이 끝나면 사이트맵 검사기로 XML 형식과 URL 상태를 먼저 점검하고 제출하는 걸 권한다.

최소 형식: urlset, url, loc 세 가지면 충분하다

사이트맵은 UTF-8 XML 파일이고 필수 요소는 <urlset>(네임스페이스 포함), URL마다 하나씩의 <url>, 그 안의 <loc> 셋뿐이다. 페이지 5개짜리 사이트라면 아래가 완성본이다.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-15</lastmod>
  </url>
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2026-03-02</lastmod>
  </url>
  <url>
    <loc>https://example.com/pricing</loc>
    <lastmod>2026-06-28</lastmod>
  </url>
</urlset>

• <loc>는 프로토콜부터 시작하는 절대 URL이어야 한다. /about 같은 상대 경로는 무효.
• 파일 위치는 보통 루트(https://example.com/sitemap.xml)에 둔다. 규격상 사이트맵은 자기가 놓인 디렉터리 이하의 URL만 포함할 수 있으므로 루트가 가장 안전하다.
• XML 특수문자는 이스케이프해야 한다. URL에 &가 있으면 &로 쓴다.
• <priority>와 <changefreq>는 구글이 무시한다고 공식 문서에 명시돼 있다. 넣어도 해는 없지만 관리 비용만 늘어난다. 생략하자.

lastmod: 진짜 날짜만 쓰거나, 아예 빼거나

<lastmod>는 구글이 실제로 참고하는 유일한 선택 요소다. 재크롤링 우선순위를 정하는 힌트로 쓰이는데, 조건이 있다 — 일관되게 정확할 때만 신뢰한다. 구글은 lastmod 값이 실제 페이지 변경과 어긋나는 패턴이 반복되면 그 사이트의 lastmod를 통째로 무시한다고 공식적으로 밝혔다.

• 전 URL이 같은 날짜: 사이트맵 생성 시각을 모든 URL에 찍는 흔한 실수. “모든 페이지가 오늘 바뀌었다”는 뜻이 되므로 즉시 신뢰를 잃는다.
• 요청 때마다 현재 시각: 동적으로 사이트맵을 생성하면서 now()를 넣는 경우. 위와 같은 이유로 무시 대상 1순위다.
• 올바른 값: 본문·구조화 데이터 등 의미 있는 콘텐츠가 마지막으로 바뀐 날짜. CMS의 수정일, 파일의 실제 갱신일을 연결한다. 사소한 오탈자 수정까지 갱신할 필요는 없다.
• 정확한 날짜를 뽑을 수 없다면 lastmod를 아예 생략하는 쪽이 낫다. 틀린 날짜보다 없는 날짜가 낫다.

형식은 W3C Datetime이다. 날짜만(2026-07-15) 써도 되고, 시각까지 쓰려면 타임존을 포함해 2026-07-15T09:30:00+09:00처럼 쓴다.

무엇을 넣고 무엇을 빼나 + 50,000개 제한

원칙은 하나다. 검색결과에 나오길 원하는, 200을 반환하는 표준(canonical) URL만넣는다. 사이트맵은 “이 URL들이 우리 사이트의 대표 URL”이라는 선언이므로, 여기에 쓰레기가 섞이면 크롤링 예산이 낭비되고 서치콘솔 리포트도 읽기 어려워진다.

크기 제한은 사이트맵 파일 하나당 URL 50,000개 또는 비압축 50MB다. 넘으면 파일을 쪼개고, 쪼갠 파일들을 묶는 사이트맵 인덱스를 만들어 인덱스 하나만 제출한다. gzip 압축(sitemap.xml.gz)은 전송량만 줄일 뿐 50MB 제한은 압축 해제 기준이라는 점에 주의.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>

생성 방법은 규모에 따라 고르면 된다. Next.js·Astro·WordPress(Yoast/RankMath) 등 대부분의 프레임워크·CMS는 사이트맵을 자동 생성하며, 이 경우 lastmod가 실제 수정일과 연결되는지만 확인하면 된다. 페이지 수십 개짜리 정적 사이트는 위 예시처럼 손으로 써도 충분하고, 배포 파이프라인에서 스크립트로 뽑는 방법도 있다. 어느 쪽이든 배포 후 사이트맵 검사기에 URL을 넣어 XML 파싱 오류, 리다이렉트/404 섞임, 절대 URL 여부를 한 번에 점검하자.

제출: 서치콘솔·네이버·빙 + robots.txt 한 줄

1. 구글 서치콘솔: 속성 선택 → 색인 생성 → Sitemaps → 사이트맵 URL 입력 후 제출. 상태가 “성공”이 되고 “발견된 페이지” 수가 표시될 때까지 수 시간~수일 걸릴 수 있다.
2. 네이버 서치어드바이저: 웹마스터 도구 → 요청 → 사이트맵 제출. 한국 트래픽이 목표라면 필수다. 네이버는 사이트맵 반영이 구글보다 느린 편이니 제출 후 일주일 단위로 확인하자.
3. 빙 웹마스터 도구: Sitemaps 메뉴에서 제출. 구글 서치콘솔 계정 연동으로 속성을 가져오면 사이트맵도 함께 인식되는 경우가 많다.
4. robots.txt에 선언: 아래 한 줄이면 별도 제출 없이도 모든 크롤러가 사이트맵 위치를 알 수 있다. 값은 절대 URL이어야 한다.

Sitemap: https://example.com/sitemap.xml

robots.txt를 처음 만든다면 robots.txt 생성기로 Sitemap 줄까지 포함해 생성하고, 배포 후에는 robots.txt 검사기로 사이트맵에 넣은 경로가 실수로 Disallow에 걸려 있지 않은지 확인하자. 사이트맵에 있는데 robots.txt로 차단된 URL은 서치콘솔에서 오류로 잡히는 대표적인 자기모순이다.

실전 예시: 8페이지 사이트 제출 후 서치콘솔 읽기

페이지 8개짜리 포트폴리오 사이트를 예로 들자. 위 최소 형식으로 sitemap.xml을 손으로 작성해 루트에 올리고, robots.txt에 Sitemap 줄을 추가한 뒤 서치콘솔에 제출했다. 일주일 뒤 리포트가 이렇게 나왔다.

발견 8 대 색인 5의 간극이 정상인지가 관건이다. 페이지 색인 생성 리포트에서 사이트맵 필터를 걸고 제외 사유를 보면 된다. “크롤링됨 - 현재 색인되지 않음”은 품질·중복 판단 보류로, 얇은 페이지에 흔하며 콘텐츠 보강과 내부링크로 풀어야 한다. “리디렉션이 포함된 페이지”나 “noindex 제외”가 보이면 사이트맵에 넣지 말았어야 할 URL이 섞인 것이므로 사이트맵을 고쳐야 한다. 즉 이 간극은 “구글의 판단”과 “내 사이트맵의 오류” 두 원인이 섞여 있고, 후자는 전부 내가 없앨 수 있다.