XML 사이트맵 검사 도구

XML 사이트맵을 검사하는 방법

세 단계 모두 이 페이지 안에서 끝납니다. 검사 대상은 당신이 건넨 파일입니다. 사이트를 가져오지 않으므로 URL을 입력하는 대신 XML을 붙여넣거나 파일을 끌어다 놓아 주세요.

1. 붙여넣거나 파일을 놓습니다. 왼쪽 상자에 XML을 붙여넣거나 sitemap.xml(또는 sitemap.xml.gz — 브라우저가 압축을 풉니다)을 그 위로 끌어다 놓으세요. 한 글자 칠 때마다 바로 검사합니다.
2. 지적 사항을 위에서부터 처리합니다. 모든 지적에는 줄 번호와 고치는 법이 붙습니다. 오류는 크롤러가 거부하거나 잘못 읽는 것이고, 경고는 XML로는 올바른데도 손해가 나는 것입니다(미래 날짜의 lastmod, 중복 URL 같은 것들).
3. 보고서를 복사하고, 고치고, 다시 검사합니다. 오른쪽에는 파일 종류, 50,000개 URL과 50MB 상한까지 남은 여유, 모든 지적 사항이 담긴 일반 텍스트 보고서가 있습니다. 그대로 이슈에 붙여 넣으세요. 고친 파일을 다시 붙여넣어 깨끗하게 돌아오는지 확인합니다.

이 사이트맵 검사 도구가 보는 것

붙여넣은 파일을 세 번 훑습니다. 먼저 XML로서 올바른지 —— 닫히지 않은 태그, 어긋난 중첩, 쿼리 문자열 속의 맨 &, 선언되지 않은 네임스페이스 접두사를, 「파싱 오류」 한 줄이 아니라 문제가 난 줄마다 알려 드립니다. 다음은 sitemaps.org 프로토콜 —— 루트가 http://www.sitemaps.org/schemas/sitemap/0.9 네임스페이스의 <urlset>이나 <sitemapindex>인지, 항목마다 절대 URL의 <loc>이 정확히 하나인지, <lastmod>이 진짜 W3C Datetime인지, <priority>가 0.0에서 1.0 사이인지, <changefreq>가 정해진 일곱 단어 중 하나인지. 마지막으로 상한과 상호 참조 —— 50,000개 URL, 비압축 50MB, 중복 URL, 호스트 혼재, 그리고 xhtml:link hreflang 주석의 양방향 확인입니다.

XML 사이트맵은 고정된 URL에 두는 파일로, 크롤링되기를 바라는 페이지를 하나씩 <loc> 요소로 적고, 필요하면 <lastmod>를 덧붙여 <urlset> 루트 아래에 묶은 것입니다. 여러 사이트맵을 가리킬 때는 루트를 <sitemapindex>로 씁니다. 프로토콜은 이게 전부이고, 지금도 검색엔진들이 합의한 0.9 스키마 그대로입니다. 그래서 사이트맵 검사는 「생성기를 바꿀 때 한 번」이면 충분합니다. 실패가 기계적이고, 줄만 알면 대부분 한 줄 수정이기 때문입니다.

네이버와 구글은 사이트맵을 같은 방식으로 대하지 않습니다

한국에서 사이트맵을 만드는 사람은 검색엔진을 하나가 아니라 둘 상대합니다. 그런데 영어권 자료는 Google 쪽만 답해 놓고 끝납니다. 두 쪽을 갈라서 사실만 적으면 이렇습니다.

파일 형식은 같습니다. 네이버 서치어드바이저도 sitemaps.org 0.9 형식의 XML 사이트맵을 받습니다. 이 페이지에서 잡히는 오류 —— 닫히지 않은 태그, 맨 &, 상대 경로 <loc>, 형식이 틀린 <lastmod> —— 는 어느 쪽에 내든 똑같이 문제입니다. 그러니 검사는 한 번만 하면 됩니다.

제출 방식이 다릅니다. Google 쪽에서 오래 쓰이던 google.com/ping?sitemap=은 2023년에 없어졌고, 지금은 robots.txt의 Sitemap: 지시문과 서치 콘솔 1회 제출이 전부입니다. 네이버 쪽은 여전히 제출 중심입니다. 서치어드바이저에서 사이트 소유 확인을 마친 뒤 「요청 → 사이트맵 제출」에 절대 URL로 넣고, robots.txt에도 Sitemap: 줄을 같이 둡니다. 네이버 크롤러(Yeti)가 robots.txt에서 막혀 있지 않은지도 같이 보세요. 두 엔진 모두 재제출을 반복한다고 빨라지지는 않습니다.

상한 수치는 출처를 구분해야 합니다. 이 도구가 재는 50,000개 URL / 비압축 50MB는 sitemaps.org와 Google이 문서화한 값입니다. 네이버가 공개하는 자체 기준은 서치어드바이저 도움말에서 확인하세요 —— 여기 적힌 숫자를 네이버 기준으로 가져다 쓰지 마시라는 뜻입니다. 보고서에 상한까지 남은 여유를 퍼센트로 같이 찍어 두는 이유도 그것입니다. 어느 쪽 기준이든 자기 파일이 어디쯤 있는지는 알 수 있습니다.

남의 도메인 URL은 넣지 마세요. 자사 사이트맵에 블로그나 카페 글 URL을 함께 넣는 경우가 있는데, 프로토콜상 다른 호스트의 URL은 그 호스트의 소유권을 확인했거나 그 호스트의 robots.txt가 이 파일을 가리킬 때만 유효합니다. 위의 「오류가 있는 예시」에 이 상황을 넣어 두었습니다 —— blog.naver.com URL이 자사 사이트맵에 섞이면 호스트 혼재 경고가 뜹니다.

마지막으로 한국어 사이트에만 있는 함정 하나. 다국어 주석을 쓸 때 hreflang="kr"는 어떤 도구도 잡아 주지 않습니다. kr이 ISO 639-1에 실제로 존재하는 코드이기 때문입니다 —— 다만 그 뜻은 한국어가 아니라 카누리어입니다. 이 검사 도구도 kr에는 아무 말을 하지 않습니다. 규격상 유효하니까요. 그래서 더 위험합니다. 한국어는 ko, 한국 대상 한국어를 명시하려면 ko-KR입니다(국가 코드 KR은 뒤에 붙는 자리에서만 옳습니다). 반대로 ko_KR처럼 밑줄로 쓴 것은 오류로, ko-kr처럼 소문자로 쓴 것은 경고로 잡아 드립니다. 주석을 처음부터 만들려면 hreflang 태그 생성기에서 만들어 여기에 붙여 넣으면, 되짚는 링크가 구조적으로 맞습니다.

50,000개와 50MB, 그리고 사이트맵 색인으로 나누는 법

딱딱한 숫자 둘: 사이트맵 파일 하나에 50,000개 URL, 비압축 50MB. 크기는 gzip 전에 잽니다. 60MB짜리를 압축해도 상한 아래로 내려가지 않고, 내려받는 시간만 짧아집니다. 지적 사항 위의 보고서가 두 값에 대해 얼마나 남았는지 보여 줍니다. 사이트가 커지는 중이라면 지켜볼 숫자가 이것입니다. 상한을 넘으면 파일이 잘리는 게 아니라 통째로 무효가 되기 때문입니다.

그다음은 영역별로 나누고 <sitemapindex>를 하나 발행합니다. 콘텐츠 종류별로 한 파일씩, 또는 월별로 —— <lastmod> 값이 정직해지는 쪽으로 고르세요. 색인 하나에는 <sitemap> 항목을 50,000개까지 담을 수 있고, 항목마다 <loc> 하나와 선택적인 <lastmod>만 들어갑니다. <priority>도, <changefreq>도, 섞여 들어간 <url>도 안 됩니다 —— 이 도구가 전부 잡습니다. 프로토콜은 색인이 색인을 담는 것을 허용하지 않으므로 트리는 정확히 두 층입니다. 색인 파일을 붙여넣으면 검사 규칙이 자동으로 색인용으로 바뀌며, 자식 사이트맵을 따라가지는 못합니다. 아무것도 가져오지 않으니까요.

상한은 아니지만 상한처럼 구는 것이 하나 더 있습니다. 파일을 정직하게 유지하세요. 안에 든 URL은 모두 200을 반환하고 색인 가능해야 합니다. 리디렉션되거나 404이거나 noindex가 붙은 <loc>은 크롤러에게 「이 사이트맵은 덜 믿어도 된다」고 가르치는 것과 같습니다. 이걸 확인하려면 URL마다 한 번씩 가져와야 하므로 서버 쪽 일이고, 브라우저 안의 페이지가 답할 수 있는 종류의 질문이 아닙니다.

URL 대신 파일을 받는 이유

다른 무료 사이트맵 검사 도구는 대부분 URL을 받아 서버에서 가져옵니다. 이 도구는 지금 보고 계신 페이지 안에서 전부 돌아가는데, 브라우저는 상대 도메인이 명시적으로 허용하지 않는 한 다른 도메인의 파일을 읽을 수 없습니다 —— 동일 출처 정책, CORS로 강제됩니다. 사이트맵에 Access-Control-Allow-Origin을 붙여 두는 사이트는 사실상 없으므로, 여기에 URL 입력창을 두면 입력하는 거의 모든 주소에서 실패합니다. 대부분 오류만 내는 입력창을 내놓느니, 파일을 받기로 했습니다.

그리고 그 선택은 URL 입력창으로는 아예 닿지 못하는 경우들을 덮습니다.

• 아직 배포 전 —— 방금 로컬에서 생성기가 써 놓은 파일을, 올리기 전에.
• CI에서 만들어진 산출물 —— 파이프라인의 아티팩트를, 호스트에 닿기 전에.
• 로그인·VPN·스테이징 비밀번호 뒤 —— 가져오는 방식의 검사기는 로그인 페이지를 받아 와서 「깨진 XML」이라고 보고합니다.
• 사내망이나 폐쇄망 —— 파일이 기기 밖으로 나가지 않으므로, 외부 서버에 넘길 수 없는 사이트맵도 검사할 수 있습니다.

대가는 분명히 적어 둡니다. 이 도구는 https://yourdomain.co.kr/sitemap.xml이 실제로 200을 반환하는지, robots.txt가 그걸 가리키는지, 안의 URL들이 살아 있는지는 알려 줄 수 없습니다. 건네받은 바이트를 읽을 뿐입니다. 이미 배포된 파일을 보려면 직접 가져와서 —— curl -s https://yourdomain.co.kr/sitemap.xml, gzip이면 curl -s https://yourdomain.co.kr/sitemap.xml.gz | gunzip —— 그 출력을 붙여넣으세요. 파싱 이후의 일은 전부 서버 쪽 작업이고, Agent SEO가 맡는 부분이 그쪽입니다. 기계가 읽는 파일이라는 점에서 이웃한 두 도구도 같은 원칙 위에 있습니다: 하나의 원본에서 생성하고 손으로 고치지 않는다 —— AI가 읽는 색인을 위한 llms.txt 검사 도구, 화면에 보이는 문장과 한 글자도 어긋나면 안 되는 마크업을 위한 FAQ 스키마 생성기.

$ npm i -g @clize/clize && clize install
$ clize seo check --domain yourdomain.co.kr