XML 사이트맵 만들기: Google에 제출하고 점검하는 방법

핵심 답변: XML 사이트맵은 검색엔진이 알았으면 하는 주소를 나열한 파일입니다. 페이지마다 <url> 항목이 하나씩 있고, 주소는 <loc>에, 정확하다면 마지막 변경 날짜가 <lastmod>에 들어갑니다. CMS나 사이트 자체의 데이터로 만들고, 파일 하나당 주소 50,000개와 50 MB 이내로 유지하며, robots.txt에 적고 Search Console의 「Sitemaps」 보고서에 제출하세요. 제출은 힌트일 뿐 약속이 아닙니다. Google은 파일에 나열된 주소를 크롤링하거나 색인한다고 보장하지 않습니다.

XML 사이트맵에는 무엇이 들어 있을까?

다음은 2026년 11월 4일에 가져온 seogrinder.com 사이트맵의 시작 부분입니다(curl -sS https://seogrinder.com/sitemap.xml | head -5).

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://seogrinder.com/</loc><lastmod>2026-11-04</lastmod></url>
  <url><loc>https://seogrinder.com/imprint</loc><lastmod>2026-11-02</lastmod></url>
  <url><loc>https://seogrinder.com/privacy</loc><lastmod>2026-11-02</lastmod></url>

sitemaps.org 프로토콜은 세 가지를 요구합니다. 네임스페이스가 있는 여는 <urlset> 태그, 페이지마다 하나의 <url> 항목, 각 항목 안의 <loc>입니다. 그 밖의 태그는 모두 선택이며, 선택 태그를 지원하는지는 “may vary among search engines”, 즉 검색엔진마다 다를 수 있습니다. 파일은 UTF-8이어야 하고, & 같은 문자는 이스케이프해야 하며(&), 한 파일의 모든 주소는 하나의 호스트에 속해야 합니다.

우리 파일에서 <loc> 항목은 425개입니다(curl -sS https://seogrinder.com/sitemap.xml | grep -o '<loc>' | wc -l, 2026년 11월 5일). 구성은 시작 페이지 1개, 법적 고지 페이지 4개(Impressum과 개인정보 처리방침, 각각 독일어판과 영어판), 블로그 목록 페이지 12개, 글 408개입니다. 모든 항목에는 <loc>과 <lastmod>만 있고, <changefreq>도 <priority>도 hreflang 표기도 없습니다. 파일 크기는 45,765바이트입니다(curl -sS https://seogrinder.com/sitemap.xml | wc -c).

XML 사이트맵이 꼭 필요할까?

항상 필요한 것은 아닙니다. Google의 사이트맵 개요에는 페이지가 제대로 링크되어 있으면 Google이 대개 사이트의 대부분을 스스로 찾아낼 수 있다고 적혀 있습니다. 사이트맵이 가장 도움이 되는 곳은 큰 사이트, 외부 링크가 적은 새 사이트, 동영상·이미지·뉴스가 많은 사이트입니다. 사이트가 작고(페이지 약 500개 이하, 검색결과에 나타나길 원하는 페이지만 셉니다) 중요한 페이지를 모두 홈페이지에서 링크를 따라 갈 수 있다면 없어도 될 수 있습니다. 그래도 Google은 대부분의 사이트가 사이트맵의 도움을 받는다고 덧붙입니다.

WordPress, Wix, Blogger를 쓴다면 Google에 따르면 CMS가 이미 사이트맵을 제공하고 있을 가능성이 큽니다. 두 번째 파일을 만들기 전에 내 사이트의 /sitemap.xml을 열어 보세요.

사이트맵은 링크를 대신하지 못합니다. 예상한 페이지가 Google에 보이지 않을 때 사이트맵이 없는 것은 여러 원인 중 하나일 뿐입니다. 새로 만든 페이지에서도 사이트맵은 전체 과정의 일부일 뿐이며, 사이트맵이 있다고 크롤링이나 색인이 보장되지는 않습니다.

XML 사이트맵 만드는 방법

도구가 아니라 주소 목록부터 시작하세요. Google은 사이트맵이 검색결과에 보여 주고 싶은 URL, 즉 canonical URL을 담는 것이라고 말합니다. 같은 콘텐츠가 여러 주소로 접근된다면 선호하는 주소 하나만 적으세요. 어떤 주소를 선호 주소로 삼을지는 canonical 태그로 알립니다.

그다음 방법을 고릅니다. Google의 사이트맵 만들기와 제출 페이지는 다음 방법을 설명합니다.

• CMS가 만들게 하기. CMS가 지원한다면 이 방법이 가장 쉽습니다.
• 직접 쓰기. 주소가 몇십 개 미만일 때입니다. Google은 더 큰 파일을 직접 만드는 것을 번거롭고 관리하기 어렵다고 말합니다.
• 생성하기. 주소가 더 많다면 내 데이터로 생성합니다. Google은 웹사이트 소프트웨어가 파일을 쓰게 하는 것이 가장 좋다고 말합니다. 항목의 순서는 Google에게 중요하지 않습니다.

우리 사이트맵은 생성합니다. 스크립트가 글 파일로부터 블로그 항목을 쓰고, 시작 페이지와 법적 고지 페이지는 건드리지 않습니다.

파일에 들어갈 것은 다음과 같습니다.

• 넣을 것: 상태 코드 200으로 응답하고, 색인될 수 있으며, 검색에 나타나야 하는 페이지의 https://를 포함한 전체 주소입니다. Google은 전체 주소를 요구하며, 적힌 그대로 크롤링합니다.
• 뺄 것: 리디렉션되는 주소(Search Console 도움말은 크롤링되길 원하는 주소로 바꾸라고 합니다), 오류를 반환하는 페이지, 이미 나열한 페이지의 중복입니다. 우리의 판단으로는 noindex가 걸린 페이지도 빼야 합니다. 사이트맵은 Google을 초대하는데 태그는 돌려보내기 때문입니다.

파일은 루트에 두세요. 예를 들면 https://example.com/sitemap.xml입니다. Google은 루트를 권합니다. 하위 폴더에 둔 사이트맵은 Search Console로 제출하지 않는 한 그 아래의 주소에만 적용됩니다.

XML 사이트맵은 얼마나 클 수 있을까?

파일 하나에는 주소를 최대 50,000개까지 담을 수 있고, 압축하지 않은 크기가 최대 50 MB여야 합니다. gzip으로 압축해도 되지만 압축을 푼 크기가 기준입니다(sitemaps.org). 한도를 넘으면 목록을 나누고 사이트맵 인덱스 파일에 파일 이름을 적으세요. 인덱스 파일에는 사이트맵을 최대 50,000개까지 나열할 수 있고, 자기 사이트의 사이트맵만 나열할 수 있습니다. 우리 파일은 두 한도 모두에 한참 못 미치므로 인덱스가 필요 없습니다.

lastmod: 페이지가 실제로 바뀌었을 때만 설정하기

<lastmod>는 정확하게 쓸 가치가 있는 유일한 선택 태그입니다. Google은 이 값이 “consistently and verifiably”, 즉 일관되고 검증 가능하게 정확할 때 쓴다고 말합니다. 의미 있는 변경이란 주요 콘텐츠, 구조화된 데이터, 링크의 변경이며, 저작권 연도만 바꾸는 것은 해당하지 않습니다. 프로토콜은 더 단호합니다. 날짜는 “the date the linked page was last modified, not when the sitemap is generated”, 즉 사이트맵을 생성한 날이 아니라 연결된 페이지가 마지막으로 수정된 날이어야 합니다.

그러니 빌드할 때마다 모든 항목에 오늘 날짜를 넣지 마세요. Google은 <priority>와 <changefreq>를 무시하므로 둘 다 빼세요.

우리 파일에서는 425개 항목 중 313개가 2026-11-04를, 108개가 2026-11-05를, 4개가 2026-11-02를 가집니다(curl -sS https://seogrinder.com/sitemap.xml | grep -o '<lastmod>[^<]*' | sort | uniq -c, 2026년 11월 5일). 글 항목은 각 글의 updated 줄에서 날짜를 가져오므로, 글을 같은 날 쓰거나 고치면 많은 항목이 같은 날짜를 공유합니다.

XML 사이트맵을 Google에 제출하는 방법

방법은 세 가지이며 함께 쓸 수 있습니다.

1. robots.txt. 전체 주소로 Sitemap: https://example.com/sitemap.xml을 추가하세요. 이 줄은 어떤 user-agent 그룹에도 속하지 않으므로 파일 안의 위치는 상관없고, 여러 개를 적을 수 있습니다. Google은 다음에 robots.txt를 크롤링할 때 이 줄을 찾습니다. 인덱스 파일이 있다면 인덱스 파일을 제출합니다. 우리 사이트에서는 2026년 11월 4일 기준 robots.txt의 마지막 줄입니다. Sitemap: https://seogrinder.com/sitemap.xml
2. Search Console의 「Sitemaps」 보고서. 단계는 아래에 있습니다.
3. Search Console API. 코드에서 제출하고 싶을 때 씁니다.

제출한다는 것은 Google에 파일이 어디 있는지 알려 주는 것입니다. Google의 사이트맵 보고서 도움말은 “You cannot actually upload a sitemap to Google.”라고 말합니다. 즉 사이트맵을 Google에 실제로 업로드할 수는 없습니다. 단계는 다음과 같습니다.

1. 속성(property)에 대한 소유자 권한이 있는지 확인하세요. 없다면 robots.txt에 사이트맵을 적으세요.
2. 사이트에 사이트맵을 게시하세요.
3. URL 검사에서 그 주소의 라이브 URL 테스트를 실행하고, 페이지 가져오기가 “성공”인지 확인하세요.
4. 「Sitemaps」 보고서를 열고 「새 사이트맵 추가」에 주소를 붙여 넣은 뒤 「제출」을 클릭하세요.

Google은 파일이 보통 즉시 가져와져야 하지만, 그 안의 주소를 크롤링하는 데는 시간이 걸릴 수 있고 모두 크롤링되지는 않는다고 말합니다. Google의 표현으로는 “submitting a sitemap is merely a hint”, 즉 사이트맵 제출은 힌트일 뿐입니다(Google). 보고서는 사이트맵마다 상태(성공, 가져올 수 없음, 오류 N개 같은 상태), Google이 마지막으로 읽은 시점, 발견한 페이지 수를 보여 줍니다. 발견되었다는 것이 색인되었다는 뜻은 아닙니다. Google은 발견된 페이지가 크롤링되었거나 앞으로 크롤링·색인된다는 보장은 없다고 말합니다. 또 이 보고서에는 보고서나 API로 제출한 사이트맵만 나오고, Google이 robots.txt를 통해 찾은 사이트맵은 나오지 않습니다.

이 글은 Google 문서를 따릅니다. Search Console 스크린샷은 싣지 않았고, 우리 파일에 대한 제출 결과도 보고하지 않습니다.

XML 사이트맵 점검하는 방법

1. 가져오기. curl -sSI https://example.com/sitemap.xml은 상태 200과 XML 콘텐츠 타입을 보여 줘야 합니다. 우리 사이트에서는 2026년 11월 4일에 HTTP/2 200과 content-type: application/xml; charset=utf-8이 나왔습니다.
2. 시작 부분 읽기. 파일은 <urlset과 네임스페이스로 시작하고, UTF-8이며, 상대 주소가 없어야 합니다.
3. 모든 주소 요청하기. 아래 반복문은 리디렉션을 따라가지 않으므로, 리디렉션은 301이나 302로 나타납니다.
4. Google이 가져올 수 있는지 확인하기. 위의 라이브 URL 테스트를 쓰세요. Google은 사이트맵을 가져올 때도 robots.txt를 따르므로, 그 파일을 막는 규칙이 있으면 가져오지 못합니다.
5. 제출한 뒤 「Sitemaps」 보고서 읽기. 오류가 있는 사이트맵을 클릭하면 자세한 내용이 나옵니다.

for u in $(curl -sS https://seogrinder.com/sitemap.xml | grep -o 'https://seogrinder.com/[^<]*'); do
  curl -sS -o /dev/null -w '%{http_code}\n' "$u"
done | sort | uniq -c

2026년 11월 5일 13:40 UTC 무렵에 이 반복문은 425 200을 출력했습니다. 425개 주소가 모두 200으로 응답했다는 뜻입니다.

SEOgrinder는 우리 자체의 무료 도구이며, 우리가 만듭니다. 페이지를 스캔하고 「할 일」 탭의 목록을 보세요. 「AI 준비도」 탭의 「에이전트에게 길을 알려주기」 항목(태그 「Sitemap」)도 함께 보세요. SEOgrinder는 robots.txt에 적힌 사이트맵을 읽고, robots.txt에 없다면 /sitemap.xml을 읽으며, 다음을 보고할 수 있습니다.

SEOgrinder는 목록 전체에 고르게 퍼진 최대 15개 주소를 표본으로 점검하며, 모든 주소를 점검하지는 않습니다. 그래서 위의 반복문을 돌려 볼 가치가 있습니다. 또한 파일 하나당 최대 3 MB, 인덱스에 든 사이트맵은 최대 10개까지만 읽고, 더 큰 것은 전부 읽지 못했다고 표시합니다.

자주 하는 실수

• 리디렉션되거나, 오류를 반환하거나, noindex가 걸린 주소. Search Console은 접근할 수 없는 주소를 알려 줍니다. 리디렉션되는 주소는 그 대상으로 바꾸세요.
• 한 페이지의 모든 변형. http와 https, www 유무, 파라미터 버전을 모두 나열하지 마세요. canonical 주소를 적으세요.
• 빌드할 때마다 오늘 날짜를 lastmod로 쓰기. Google은 날짜가 일관되고 검증 가능하게 정확할 때 그 날짜를 씁니다.
• 파일에 넣을 수 없는 주소. 보고서는 이것을 “URL not allowed”라고 부릅니다. 다른 도메인, 다른 프로토콜, 사이트맵 자신의 위치보다 위에 있는 폴더입니다.
• “제출됨”을 “색인됨”으로 읽기. 제출한 사이트맵은 아무것도 보장하지 않습니다.
• 오류가 난 파일을 방치하기. Google은 가져오기에 실패하면 며칠 동안 다시 시도하다가 멈춥니다. 원인을 고치고 다시 제출하세요.

자주 묻는 질문

robots.txt에 이미 적혀 있다면 제출해야 하나요?

아니요. Google은 robots.txt에 적힌 사이트맵을 그 파일을 다음에 크롤링할 때 찾습니다. 제출하면 보고서를 얻습니다. Googlebot이 파일에 언제 접근했는지, 어떤 오류를 만났는지 볼 수 있습니다.

XML 사이트맵이 순위를 올려 주나요?

Google은 사이트맵의 목적을 발견이라고 설명합니다. 검색엔진이 주소를 찾도록 돕고, 더 크거나 복잡한 사이트의 크롤링을 개선할 수 있다는 것입니다. 우리가 인용한 페이지는 순위에 대해 아무것도 약속하지 않으며, 누구도 약속할 수 없습니다.

다음 단계

내 사이트맵에 위의 반복문을 실행하고, 200으로 응답하지 않는 주소를 모두 고치세요. 그런 다음 SEOgrinder로 사이트를 스캔하고 할 일 목록을 열어 사이트맵 발견 항목부터 시작하세요. 변경한 뒤에는 다시 확인을 누르고, 아직 하지 않았다면 Search Console의 「Sitemaps」 보고서에 파일을 제출하세요.

함께 읽어 보세요

• 구글 사이트 검색 안됨: 순서대로 확인할 7가지 원인
• 구글 색인 등록: Google이 새 페이지를 찾게 돕는 5단계 (직접 테스트함)
• canonical 태그: 언제 필요한지, 흔한 실수 5가지 (+ 점검 명령)