11월 14, 2026 가이드 읽는 시간 3분

모든 웹사이트를 위한 XML 사이트맵 만들기

XML 사이트맵은 사이트 루트에 두고, 검색 엔진이 찾아 주길 바라는 URL을 나열해 둔 단순한 파일입니다. 색인을 강제하지도 않고 랭킹 요소도 아니지만, 새 사이트, 규모가 큰 사이트, 내비게이션 깊숙이 묻혀 있는 페이지에는 직접 통제할 수 있는 가장 확실한 발견 시그널 중 하나입니다. 이 가이드에서 다루는 내용: sitemap.xml에 무엇이 들어가는지, 선택 태그 중 무엇을 채우고 무엇을 Google이 무시하는지, 사이트맵과 다른 호스트의 URL을 검색 엔진이 소리 없이 버리게 만드는 단일 호스트 규칙, 그리고 무료 XML Sitemap Generator로 규격에 맞는 파일을 만들어 Google Search Console에 제출하는 방법.

XML 사이트맵이란 무엇인가요?

XML 사이트맵은 UTF-8 XML 파일로, 보통 사이트 루트의 sitemap.xml이며 sitemaps.org에 정의된 프로토콜을 따릅니다. 이 프로토콜은 Google, Yahoo, Microsoft가 지원하는 2006년의 개방형 표준입니다. 형식은 극히 단순합니다. 모든 URL은 <loc> 자식 요소를 가진 <url> 항목에 자리하고, 나머지는 전부 선택 사항입니다.

<?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-11-02</lastmod>
  </url>
  <url>
    <loc>https://example.com/pricing/</loc>
    <lastmod>2026-10-18</lastmod>
  </url>
</urlset>

검색 엔진은 이 목록을 읽고 이미 크롤링한 것과 대조한 뒤 새로운 것을 가져갑니다. 사이트맵은 링크 기반 발견이 약할 때 가장 큰 역할을 합니다. 백링크 없는 새 사이트, 방대한 카탈로그, 깊숙한 아카이브, 혹은 이제 막 마친 사이트 이전이 그런 사례입니다.

lastmod, changefreq, priority: 무엇을 채우고 무엇을 넘길 것인가

대부분의 튜토리얼은 <lastmod>, <changefreq>, <priority> 태그를 잔뜩 채운 사이트맵을 보여줍니다. 하지만 이 셋 중 둘은 Google에서 쓸모 없는 짐이고, 나머지 하나도 값을 꾸며내면 오히려 발목을 잡습니다.

<lastmod> — 채우되, 실제 날짜로만 채우세요. 값은 W3C Datetime 형식을 사용하며 단순한 YYYY-MM-DD로도 충분합니다. Google은 값이 “일관되고 검증 가능할 만큼 정확한” 경우에만 lastmod를 크롤 일정에 활용하며, 프로토콜이 요구하는 것은 페이지가 마지막으로 수정된 날짜이지 사이트맵이 생성된 날짜가 아닙니다. CMS가 실제 수정 시각을 안다면 포함하고, 재빌드할 때마다 모든 URL에 오늘 날짜가 찍히게 된다면 태그를 생략하세요.

<changefreq> — 생략하세요. 프로토콜은 daily, monthly 같은 값을 명령이 아닌 힌트로 정의할 뿐이고, Google 문서도 “Google은 <priority>와 <changefreq> 값을 무시합니다”라고 못 박고 있습니다.

<priority> — 이것도 생략하세요. 값은 0.0부터 1.0까지이며 사이트 내 다른 URL과의 상대값입니다. Google은 이를 무시하며, 모든 값을 1.0으로 놓는 것이 이 태그를 무의미하게 만드는 가장 흔한 방식입니다.

단일 호스트 규칙

사이트맵에는 단 하나의 호스트에 속한 URL만 담을 수 있으며, 어떤 URL이 해당되는지는 사이트맵 자신의 위치가 결정합니다. https://www.example.com/sitemap.xml에 있는 사이트맵은 https://www.example.com/… URL은 나열할 수 있지만, https://example.com/…(www가 없으면 다른 호스트)도, https://blog.example.com/…(서브도메인은 별개의 호스트)도, 아예 다른 도메인은 더더욱 담을 수 없습니다. 외부 URL은 후보에서 버려집니다. 파일은 가져가지만 해당 URL은 어디로도 전달되지 않습니다. 도메인의 www와 non-www 형식이 모두 응답한다면, 사이트맵 파일 자체는 정규(canonical) 호스트로 정한 쪽에 두어야 합니다.

그러니 정규 호스트를 — www 유무는 하나로 정하고 HTTPS로만 — 고르고, 모든 <loc>가 정확히 그 형식을 쓰게 한 뒤, 사이트맵은 사이트 루트에 두세요. 프로토콜은 사이트맵의 범위를 자기 경로로 한정하므로 /catalog/sitemap.xml은 /catalog/ URL만 포함할 수 있습니다.

XML 사이트맵 단계별로 만들기

1단계: 정규 URL 수집하기

색인하려는 모든 URL을 최종 정규 형식으로 나열하세요. 출처는 CMS 내보내기, 애널리틱스 상위 페이지, 크롤링 결과 어느 것이든 좋습니다. 사이트가 새로 생겨 규모가 작다면(예: 스무 페이지 정도) 가장 빠른 출처는 바로 사이트 내비게이션입니다. 모든 메뉴를 훑으며 페이지를 하나하나 적어 내세요. 200을 반환하면서 색인 가능한 페이지는 포함하고, 리다이렉트, 404, noindex 페이지, 파라미터 중복은 제외하세요. 리다이렉트와 죽은 링크는 크롤 예산을 낭비합니다. 길고 지저분한 목록보다 짧고 깨끗한 목록이 낫습니다.

2단계: 위험한 URL이 깨끗하게 응답하는지 확인

최소한 마지막 사이트 이전이나 리디자인보다 오래된 URL은 전부 확인하고, 나머지는 표본만 뽑아 확인하세요. 죽은 링크는 대개 오래된 URL에 숨어 있습니다. redirect chain checker는 한 번에 URL 하나를 다룹니다. URL을 붙여넣고 Check redirects를 누른 뒤, 정규 호스트에서 불필요한 홉 없이 200을 반환하는지 확인하세요. 그렇지 않은 URL은 최종 목적지로 교체하세요.

3단계: 무료 XML Sitemap Generator로 파일 생성하기

XML Sitemap Generator를 열고 Your URLs 박스에 URL을 붙여넣으세요. 한 줄에 절대 URL 하나씩, 최대 500개까지입니다. 그다음 세 가지 옵션을 설정합니다. Last modified date의 선택 기본값은 Use today입니다. 도구가 목록 전체에 하나의 날짜를 일괄 표기하므로, 모든 페이지가 실제로 오늘 바뀐 게 아니라면 Omit lastmod로 전환하세요. Custom date는 페이지가 실제로 그날 변경된 경우에만 사용합니다. Change frequency와 Priority에서는 앞서 설명한 이유로 Omit changefreq와 Omit priority를 고르세요. Generate sitemap.xml을 클릭하고 검사 결과를 읽으세요. 도구는 중복 줄은 건너뛰고, 형식이 잘못된 URL은 거부하며, 서로 다른 호스트의 URL이 섞인 목록에는 경고가 아니라 오류를 표시합니다. 목록을 먼저 고치라는 신호입니다. 검사가 모두 통과하면 Copy code 또는 Download sitemap.xml을 사용하세요. 올바른 네임스페이스가 붙고 엔티티 이스케이프 처리된 XML이 나오므로 그대로 업로드하면 됩니다.

URL이 500개를 넘나요? 목록을 나눠 sitemap-1.xml, sitemap-2.xml 등을 생성하고 업로드한 뒤, 하나의 사이트맵 인덱스가 이들을 가리키게 하고 Search Console에는 자식 파일이 아니라 인덱스를 제출하세요:

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

4단계: 사이트 루트에 업로드하고 robots.txt에 선언하기

먼저 파일을 업로드할 수 있는 환경인지부터 확인하세요. 호스팅 플랫폼은 사이트맵을 대신 관리해 줍니다. Shopify, Wix, Squarespace는 모두 /sitemap.xml에서 자동 사이트맵을 제공합니다. 이런 플랫폼을 쓰고 있다면 5단계로 건너뛰어 그 URL을 제출하세요. 그렇지 않다면 SFTP나 호스팅 업체의 파일 매니저로 파일을 https://yourdomain.com/sitemap.xml에 업로드한 뒤 robots.txt에 선언하세요:

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

이 지시어는 어떤 User-agent 블록과도 무관하며 여러 번 선언할 수 있습니다. 어차피 robots.txt를 새로 쓴다면 무료 Robots.txt Generator가 Sitemap 줄을 포함한 파일을 만들어 줍니다. 아울러 robots.txt가 나열한 페이지를 차단하지 않는지도 확인하세요. 사이트맵은 disallow를 뒤집을 수 없습니다.

5단계: Google Search Console에 제출하기

robots.txt는 발견을, Search Console은 진단을 책임집니다. 사이트가 아직 GSC에 없다면 먼저 추가하세요. Domain 속성(모든 서브도메인과 두 프로토콜 모두) 또는 URL prefix 속성(정확히 하나의 프리픽스)으로 만들고 소유권 확인을 마칩니다. 그런 다음 Indexing → Sitemaps를 여세요. 속성 주소가 미리 채워져 있으니 sitemap.xml만 입력하고 Submit을 클릭하면 됩니다. 하루 안에 보고서에 Google이 파일을 가져갔는지, URL이 몇 개 발견되었는지 표시됩니다. 큰 변경이 있을 때마다 다시 제출하세요. 참고 두 가지: 예전 /ping?sitemap= 엔드포인트는 2023년 6월에 폐지되었으니 핑을 자동화하지 마세요. 또 Bing Webmaster Tools는 Search Console에서 사이트를 가져올 수 있지만(My Sites → Import), 이때 가져오는 것은 사이트이지 사이트맵 제출 기록이 아니므로 BWT의 Sitemaps 페이지에서 사이트맵을 별도로 제출해야 합니다.

XML 사이트맵에서 흔히 하는 실수

리다이렉트되거나 죽은 URL 나열. 하나같이 크롤 예산을 낭비합니다. 생성하기 전에 위험한 URL을 — 최소한 마지막 사이트 이전보다 오래된 URL은 — 확인하세요.
호스트 섞기. 한 파일에 www와 non-www를 함께 넣는 것이 전형적인 사례입니다. 프로토콜은 외부 호스트의 URL을 버립니다.
빌드 날짜로 lastmod 찍기. 사이트맵을 다시 생성해도 페이지가 수정되지는 않습니다. Google은 값이 일관되게 정확할 때만 lastmod를 사용합니다. 부풀린 날짜는 Google이 여러분의 값을 무시할 명분을 줄 뿐입니다.
noindex 또는 정규화된 페이지 포함. “이건 크롤하라”와 “이건 색인하지 마라”라는 상충하는 시그널입니다.
사이트맵 방치. 석 달 전에 새 섹션을 내보냈는데 파일에 없다면? 그건 Google 탓이 아니라 사이트맵 탓입니다.
robots.txt로 차단. /sitemap.xml에 걸리는 Disallow: 규칙은 이 지시어를 존중하는 크롤러로부터 파일을 숨겨버립니다.

자주 묻는 질문

사이트맵에 changefreq와 priority가 꼭 필요한가요?

아니요. Google 문서는 <priority>와 <changefreq> 값을 모두 무시한다고 명시합니다. Google이 참고하는 유일한 선택 태그는 <lastmod>이며, 그마저도 날짜가 실제 페이지 변경 시점과 검증 가능하게 일치할 때뿐입니다. <loc> URL에 정직한 lastmod 날짜를 더하는 것이 요즘의 모범 사례입니다.

sitemap.xml 파일 하나에 URL을 몇 개까지 담을 수 있나요?

sitemaps.org 프로토콜 기준으로 사이트맵 파일 하나에는 최대 50,000개 URL 또는 압축 해제 시 50 MB 중 먼저 도달하는 쪽까지만 담을 수 있습니다. sitemap.xml.gz로 압축해 제공할 수는 있지만 한도는 여전히 압축 해제 크기 기준입니다. 이를 넘으면 목록을 여러 파일로 나누고 사이트맵 인덱스로 참조한 뒤, Search Console에는 인덱스를 제출하세요. 무료 생성기는 파일 하나를 500개 URL로 제한합니다. 더 긴 목록은 덩어리마다 sitemap-1.xml, sitemap-2.xml을 만들어 3단계의 인덱스로 묶으세요.

서버의 어디에 sitemap.xml을 두어야 하나요?

도메인의 루트 디렉터리에 두어 https://yourdomain.com/sitemap.xml로 제공되게 하세요. 위치는 콘텐츠 범위도 결정합니다. 서브디렉터리의 사이트맵은 그 경로 아래의 URL만 담을 수 있고, 언제나 자기 호스트의 URL만 담을 수 있습니다. www와 non-www가 모두 응답한다면 파일은 정규 호스트에 있어야 합니다. 정규 호스트의 루트에 두면 이런 문제를 모두 피할 수 있습니다.

사용 중인 플랫폼이 사이트맵을 만들어주나요? 얼마나 자주 업데이트해야 하나요?

아마 그럴 겁니다. WordPress는 버전 5.5부터 /wp-sitemap.xml에 사이트맵을 생성하며, Rank Math나 Yoast 같은 SEO 플러그인은 자체 인덱스(보통 /sitemap_index.xml)로 대체합니다. Shopify, Wix, Squarespace는 /sitemap.xml을 자동으로 관리합니다. CMS가 관리해 준다면 다시 생성할 것이 없습니다. Search Console에서 확인만 하고, 플러그인 설정에서 noindex 포스트 타입은 제외하세요. 파일을 직접 만들었다면 주요 페이지를 추가하거나 폐기할 때마다 다시 생성해 제출하세요.

제출 후 색인까지 얼마나 걸리나요? 색인이 보장되나요?

가져오기 보고서는 보통 하루 안에 업데이트됩니다. 색인은 별개입니다. 페이지가 나타나기까지 며칠에서 몇 주가 걸릴 수 있고, 제출이 보장하는 것은 없습니다. 사이트맵은 발견을 돕는 보조 수단일 뿐이며, 색인은 여전히 크롤 예산, 콘텐츠 품질, robots.txt나 noindex 차단에 달려 있습니다. 발견된 URL이 색인된 URL보다 훨씬 많아 보이는 것은 정상입니다. 색인 문제가 계속된다면 원인은 보통 파일이 아니라 페이지에 있습니다.

Search Console에서 사이트맵을 가져올 수 없다고 합니다. 무엇을 확인해야 하나요?

세 가지 원인입니다. “가져올 수 없음(Couldn’t fetch)”은 대개 파일이 제대로 제공되지 않는다는 뜻입니다. 브라우저에서 /sitemap.xml을 열어 200을 확인한 다음 robots.txt를 확인하세요. 해당 경로에 걸리는 Disallow: 규칙은 Googlebot을 차단합니다. 개별 URL에 “URL blocked by robots.txt”가 표시된다면 사이트맵이 robots.txt가 금지한 페이지를 나열하고 있다는 뜻입니다. 목록이나 robots.txt에서 해당 페이지를 제거하세요. 형식 오류는 XML이 깨졌다는 뜻입니다. 루트 요소가 sitemaps.org 네임스페이스를 가진 <urlset>인지, 앰퍼샌드가 &로 이스케이프되었는지 확인하세요.