양용준SEO/GEO 전략 컨설턴트
업데이트 · 최초 게시
XML 사이트맵(XML Sitemap)은 사이트에서 검색엔진이 수집해 가기를 바라는 페이지의 URL과 마지막 수정일 같은 정보를 XML 형식으로 모아 둔 파일입니다. 크롤러가 링크를 따라가지 않고도 주소를 발견하게 해 주는 목록이며, 페이지를 검색 결과에 올려 주겠다는 약속은 아닙니다.
사이트맵 규약(Sitemaps Protocol)은 2005년에 나왔고, 지금은 구글·빙·네이버가 모두 같은 형식(sitemaps.org)을 읽습니다. 구글 검색 센터 문서는 사이트맵을 “사이트의 페이지, 동영상, 기타 파일과 그 관계에 대한 정보를 제공하는 파일”로 정의하고, 검색엔진이 이 파일을 읽어 사이트를 더 효율적으로 크롤링한다고 설명합니다. 가장 단순한 형태는 이렇습니다.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/seo-guide/</loc>
<lastmod>2026-09-28</lastmod>
</url>
<url>
<loc>https://example.com/about/</loc>
</url>
</urlset>크롤러는 원래 이미 아는 페이지의 링크를 따라 새 주소를 찾습니다(크롤링 참고). 사이트맵은 이 과정을 건너뛰고 주소를 직접 건네는 창구입니다. 구글은 XML 외에 RSS·Atom, 한 줄에 URL 하나씩 적은 텍스트 파일도 사이트맵으로 받습니다.
규모가 크거나, 새로 열어 외부 링크가 적거나, 동영상·이미지가 많은 사이트에 필요합니다. 구글 문서는 사이트맵이 필요 없을 수도 있는 경우와 필요한 경우를 나눠서 적어 두었습니다.
| 필요한 사이트 | 없어도 될 수 있는 사이트 |
|---|---|
| 규모가 큰 사이트 | 약 500페이지 이하의 작은 사이트 |
| 외부 링크가 거의 없는 새 사이트 | 홈에서 모든 중요 페이지로 내부 링크가 이어지는 사이트 |
| 동영상·이미지가 많거나 구글 뉴스에 나오는 사이트 | 동영상·이미지·뉴스 페이지가 많지 않은 사이트 |
기준이 이렇다고 작은 사이트가 사이트맵을 두면 손해라는 뜻은 아닙니다. 만들기 쉽고 부작용도 없으니, 대부분은 두는 편이 낫습니다. 워드프레스·윅스 같은 플랫폼은 대개 사이트맵을 자동으로 만들어 주므로 따로 할 일이 없을 때가 많습니다.
기대치는 낮춰야 합니다. 구글의 사이트맵 작성 문서는 “사이트맵 제출은 힌트일 뿐이며, 구글이 사이트맵을 내려받거나 그 URL을 크롤링에 쓴다는 보장은 없다”고 적습니다. 사이트맵은 발견을 돕는 도구이고, 색인 여부는 페이지 자체의 품질과 신호로 정해집니다(인덱싱 참고).
“사이트맵”을 찾아보면 웹사이트 기획 단계에서 메뉴 구조를 그린 도식이나, 사람이 보라고 만든 페이지 목록까지 섞여 나옵니다. 이 글의 XML 사이트맵은 검색엔진이 읽는 기계용 파일입니다. 함께 자주 언급되는 robots.txt와는 역할이 반대에 가깝습니다.
| XML 사이트맵 | HTML 사이트맵 | robots.txt | |
|---|---|---|---|
| 읽는 쪽 | 검색엔진 | 사람(검색엔진도 링크로 따라감) | 검색엔진 |
| 하는 일 | 수집할 URL을 알려 줌 | 사이트의 페이지 목록을 보여 줌 | 접근하지 말 경로를 알려 줌 |
| 형식 | XML 파일 | 일반 웹페이지 | 텍스트 파일 |
| 위치 | 어디든 가능, 보통 루트 | 보통 푸터 링크 | 반드시 루트 |
둘은 함께 씁니다. robots.txt 안에 Sitemap: 줄로 사이트맵 위치를 적어 두면 검색엔진이 알아서 찾아갑니다. 반대로 robots.txt로 막은 URL을 사이트맵에 넣으면 “가져가라”와 “들어오지 마라”를 동시에 말하는 셈이 됩니다.
필수 태그는 <loc> 하나뿐이고, 나머지 세 태그는 검색엔진마다 쓰는 정도가 다릅니다. 구글과 빙은 <priority>와 <changefreq>를 쓰지 않는다고 공식 문서에 밝혔습니다.
| 태그 | 뜻 | 구글 | 빙 |
|---|---|---|---|
| loc | 페이지 URL(필수) | 사용 | 사용 |
| lastmod | 마지막으로 크게 수정한 날짜 | 꾸준히 정확할 때만 사용 | 재크롤링 우선순위의 핵심 신호 |
| changefreq | 변경 빈도 | 무시 | 무시 |
| priority | 사이트 안 중요도 | 무시 | 무시 |
lastmod는 정직해야 쓸모가 있습니다. 구글은 2023년 6월 검색 센터 블로그에서 lastmod를 이미 발견한 URL의 크롤링 일정을 잡는 신호로 쓴다고 밝히면서, 7년 전에 바뀐 페이지를 어제 바뀌었다고 적으면 결국 그 사이트의 날짜를 믿지 않게 된다고 경고했습니다. 본문, 구조화된 데이터, 링크가 바뀌었을 때만 날짜를 올리고, 사이드바나 푸터의 사소한 변경은 수정으로 치지 않습니다. 빙도 2025년 7월 웹마스터 블로그에서 lastmod는 사이트맵 파일이 아니라 페이지 콘텐츠의 실제 수정 시각이어야 한다고 적었습니다.
구글 기준으로 사이트맵 하나에는 URL 50,000개, 압축 전 50MB까지 담을 수 있습니다. 넘으면 여러 파일로 나누고, 그 파일들의 목록인 사이트맵 인덱스를 제출합니다. 글·상품·카테고리처럼 유형별로 나눠 두면 나중에 어느 유형의 색인이 약한지 보기도 쉽습니다.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/post-sitemap.xml</loc>
<lastmod>2026-09-28</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/page-sitemap.xml</loc>
</sitemap>
</sitemapindex>URL은 https://부터 쓰는 절대 주소로 적고, 파일은 UTF-8로 저장합니다. 사이트맵을 하위 폴더에 두면 서치 콘솔로 제출하지 않는 한 그 폴더 아래 URL에만 효력이 있으므로 루트에 두는 편이 안전합니다.
제출 창구는 검색엔진마다 따로 있고, 한쪽에 제출했다고 다른 쪽이 알아서 가져가지는 않습니다. 국내 사이트라면 구글 서치 콘솔과 네이버 서치어드바이저 두 곳에 모두 제출합니다.
서치 콘솔 고객센터 문서의 순서는 이렇습니다. 사이트 소유자 권한을 확인하고, 사이트맵 URL이 Googlebot에 열리는지 URL 검사의 실제 URL 테스트로 확인한 다음, 사이트맵 보고서의 “새 사이트맵 추가” 상자에 URL을 넣고 제출합니다. 제출과 별개로 robots.txt에 Sitemap: https://example.com/sitemap.xml 한 줄을 적어 두면 다른 검색엔진도 같은 파일을 찾을 수 있습니다.
예전에 쓰던 “핑” 방식은 끝났습니다. 구글은 2023년 6월, 인증 없이 사이트맵 주소를 알리던 ping 엔드포인트의 제출 대부분이 스팸이었다며 지원 중단을 발표했고, 이후 이 주소로 보내는 요청은 404를 받습니다. 오래된 플러그인이 여전히 핑을 보내도 해는 없지만 효과도 없습니다.
네이버는 사이트를 등록하고 소유확인을 마친 뒤 웹마스터도구에서 사이트맵을 제출합니다. 서치어드바이저의 RSS 및 사이트맵 제출 가이드에 따르면 네이버 검색로봇은 제출된 RSS와 사이트맵을 “콘텐츠 피드”로 보고 주기적으로 다시 방문하며, 검색 결과에 내 사이트 노출이 적다면 제출을 권장합니다. 네이버는 사이트맵에 사이트의 모든 URL을 넣으라고 권하고, 그 안에서 수집할 URL은 내부 알고리즘으로 골라 우선순위대로 수집한다고 설명합니다.
제출할 때 네이버가 검증하는 조건은 구글과 조금 다릅니다.
RSS도 같은 화면에서 제출할 수 있지만, 네이버는 RSS가 본문까지 담아 많은 URL을 넣기 어렵다며 사이트맵을 더 권합니다.
컨설턴트의 실전 팁
네이버가 사이트맵을 더 권하기는 하지만, 저는 네이버에는 RSS와 사이트맵을 둘 다 제출합니다. 그리고 서치어드바이저의 수집 주기 설정을 가장 빠르게 맞춰 둡니다.
서치 콘솔 사이트맵 보고서의 상태와 발견된 페이지 수를 먼저 봅니다. 상태는 세 가지입니다.
“성공”은 파일을 읽었다는 뜻이지 안의 페이지가 색인됐다는 뜻이 아닙니다. 사이트맵별로 페이지 색인 생성 보고서를 필터링하면 그 사이트맵에 넣은 URL 중 몇 개가 색인됐는지 따로 볼 수 있습니다. 유형별로 사이트맵을 나눠 두면 이 비교가 훨씬 쉬워집니다. “마지막으로 읽은 날짜”가 오래 멈춰 있다면 구글이 그 파일을 다시 가져가지 않고 있다는 신호입니다.
AI 답변은 색인된 페이지를 바탕으로 만들어지므로, 사이트맵의 역할은 AI 검색에서도 같습니다. 새 페이지와 바뀐 페이지를 빨리 알리는 것입니다. 빙은 2025년 7월 글에서 “최신성 신호가 검색 결과와 AI 생성 답변에 업데이트가 반영되는 속도에 직접 영향을 준다”며, lastmod가 정확한 사이트맵과 URL 단위로 즉시 알리는 IndexNow를 함께 쓰라고 권했습니다.
네이버 서치어드바이저도 IndexNow를 지원합니다. 새로 만들거나 수정·삭제한 페이지를 알리면 갱신 정보가 IndexNow에 참여한 다른 검색엔진에도 공유된다고 설명하면서, 변화를 빨리 알리는 역할일 뿐 색인을 보장하지는 않는다고 덧붙입니다. IndexNow 공식 사이트의 참여 검색엔진 목록(2026년 9월 확인)에 구글은 없으므로, 구글에는 사이트맵과 lastmod가 여전히 주된 창구입니다.
