사이트맵 검사 (sitemap.xml)

입력한 주소는 microlab scan-api 로 전송되고, scan-api 는 그 사이트의 robots.txt 와 사이트맵 원본 바이트를 받아 그대로 돌려줍니다. 압축 해제와 XML 해석, 규칙 판정은 전부 이 브라우저 안에서 하며, 결과는 어디에도 저장되지 않습니다.

sitemaps.org 프로토콜과 구글 문서를 따릅니다. 파일 하나에 URL 5만 개·압축을 푼 크기 50MB(52,428,800 바이트)까지, <loc> 은 http(s) 로 시작하는 2,048자 미만의 전체 주소이고 사이트맵과 같은 호스트·프로토콜이어야 합니다(www 유무도 다른 호스트). lastmod 는 W3C Datetime 형식(2026-09-27 또는 시간대까지 적은 2026-09-27T10:00:00+09:00)이어야 하고, 같은 주소가 두 번 나오면 중복으로 셉니다. 사이트맵은 UTF-8 이어야 하며, & 는 &amp; 로 써야 XML 로 읽힙니다.

sitemaps.org 규칙상 사이트맵의 URL 은 사이트맵 파일과 같은 호스트에 있어야 합니다. https://example.com/sitemap.xml 에 https://www.example.com/ 주소를 넣으면 다른 호스트라 무시될 수 있습니다. 다만 robots.txt 가 다른 호스트의 사이트맵을 가리키는 교차 제출이면 robots.txt 호스트의 URL 은 정상으로 보고, Search Console 에서 두 사이트를 모두 확인했다면 구글은 받아 줍니다. 사이트맵이 /blog/ 같은 폴더 안에 있으면 그 폴더 위쪽 주소는 안내로 알립니다.

흔한 오해입니다. 구글은 priority 와 changefreq 를 쓰지 않는다고 문서에 밝히고 있습니다. 그래서 이 도구는 두 값이 규격에서 벗어나도 오류가 아니라 안내로만 알립니다. lastmod 는 구글이 쓰지만, 페이지가 실제로 바뀐 날짜와 일관되게 맞을 때만 씁니다 — 모든 URL 에 오늘 날짜를 넣거나 미래 날짜를 넣으면 무시될 수 있습니다. 사이트맵에 있다고 해서 색인이 보장되는 것도 아닙니다.

검사 한 번에 받을 수 있는 양(파일당 원본 5MB, 합계 8MB)이 정해져 있어서, 색인이 가리키는 수십 개 파일을 한꺼번에 받지 않습니다. 대신 색인을 풀어 하위 목록을 보여 주고, 원하는 하위 사이트맵의 [검사]를 누르면 그 파일을 따로 검사합니다. gzip 으로 압축된 색인(.xml.gz)도 이 브라우저가 풀어서 목록을 만듭니다.

원본이 5MB 를 넘으면 앞 5MB 만 받고, gzip 파일은 풀린 크기가 50MB 를 넘는 순간 멈춥니다(압축 폭탄 방어이자 sitemaps.org 한도). 서버가 전송 압축(Content-Encoding)으로 보내면 1MB 까지만 받습니다. 이때 URL 수와 오류는 받은 앞부분 기준이고, 파일이 중간에서 끊긴 것은 XML 오류로 세지 않습니다. 50MB 를 넘어 멈췄다면 그 자체로 한도 위반입니다.

robots.txt 에 막힌 URL 은 사이트맵 앞쪽 1,000개 표본만 Googlebot·네이버 Yeti 기준으로 확인합니다. 각 URL 에 실제로 접속해 상태 코드나 canonical 을 확인하지는 않습니다. 이미지·동영상·뉴스·hreflang 확장 태그는 개수만 세고 세부 규칙은 검사하지 않으며, RSS·Atom 피드는 종류만 알려 줍니다. XML 형식 오류는 처음 하나에서 읽기를 멈추므로, 고친 뒤 다시 검사하면 그 뒤의 문제가 나올 수 있습니다.