대부분의 사이트맵이 검증에 실패합니다. 우리의 사이트맵은 유효했지만 여전히 잘못되었습니다

2026년 5월 5일부터 8월 15일까지, 우리는 감사를 마친 모든 사이트의 XML 사이트맵을 검증했습니다 — 49개 도메인, 각 최신 스냅샷. 그 중 28개, 57.1%,는 바로 검증에 실패했습니다: 잘못된 XML, 프로토콜 네임스페이스 누락, 끊어진 loc 항목, 또는 크롤러가 존중해야 할 필요가 없는 lastmod 값.

이는 우리가 측정한 가장 파손된 탐색 파일이 되는 사이트맵입니다. 같은 주에 이 숫자들을 정리하던 중, 우리는 전체 데이터셋에서 가장 교육적인 사이트맵 실패를 우리 도메인에서 발견했습니다 — 모든 검증을 통과한 사이트맵 안에서.

사이트맵의 절반 이상이 크롤러가 첫 번째 URL을 읽기 전에 실패합니다

사이트맵은 두 가지 깊이에서 실패하며, 의미 있는 순서로 실패합니다. 검증 — 가장 얕은 테스트 — 이 가장 자주 실패합니다. 더 깊은 테스트는 나열된 URL을 가져와 각 URL이 애초에 사이트맵에 있을 자격이 있는지 묻습니다. 이들은 덜 자주 실패하지만, 실패할 때 비용이 더 듭니다.

방법론: 현재 체크셋에서 각 도메인별 최신 완료된 감사 스냅샷, 5월 5 – August 15, 2026, 익명화됨. 49 감사 사이트; 각 체크별 분모는 19와 49 사이에서 변동하며, 더 깊은 테스트는 사이트맵과 나열된 URL을 실제로 가져올 수 있을 때만 적용됩니다. 샘플은 자체 선택적이며, 감사를 실행한 사이트 소유자가 포함되어 있어 소규모에서 중간 규모로 편향됩니다. 비율을 방향성으로 취급하십시오.

검증은 대부분 생성기가 테스트하지 않는 세부 사항에서 실패합니다

사이트맵 프로토콜은 작으며, 바로 그 이유로 실패를 피할 수 있습니다. 프로토콜이 요구하는 것은 많지 않습니다: 문서는 XML으로 파싱되며, 루트 요소는 urlset 또는 sitemapindex이며 사이트맵 네임스페이스를 선언하고, 모든 항목은 비어 있지 않은 단일 loc을 가지고 있으며, 이는 절대 HTTP 또는 HTTPS URL이며 사이트맵과 동일한 사이트에 있습니다. 또한 모든 lastmod은 유효한 W3C 날짜 또는 타임존이 지정된 날짜/시간입니다.

실패는 마지막 2 규칙에 집중됩니다. 교차 사이트 loc 항목은 일반적으로 스테이징 호스트명 또는 CDN 출처가 프로덕션에 유출되었음을 의미합니다. 그리고 lastmod은 무효 값의 조용한 챔피언입니다: 생성기는 2026-07-14 19:10:31처럼 데이터베이스 타임스탬프를 작성하는 것을 좋아합니다 — T 대신 공백, 타임존 없음 — 이는 W3C 날짜/시간이 아닙니다. Google의 사이트맵 문서는 값이 일관되고 검증 가능할 때 lastmod을 사용한다고 말합니다; 구문 분석할 수 없는 형식은 모든 항목에서 해당 신호를 포기합니다. 잘린 파일도 실패합니다: 전송 중간에 잘린 사이트맵은 더 작은 사이트맵이 아니라 깨진 사이트맵입니다.

이 클래스의 모든 실패는 구성 레이어 수정을 의미하며, 우리는 10개의 체크에서 가장 많이 실패하는 웹사이트에서 발견한 동일한 패턴을 찾았습니다: 오류는 브라우저가 렌더링하는 것보다 아래에 있으므로 기계가 확인하지 않으면 아무도 보지 못합니다.

유효한 사이트맵은 여전히 크롤러를 죽은 페이지로 보낼 수 있습니다

더 깊은 테스트는 사이트맵을 주장 집합으로 간주하고 각 주장을 테스트합니다. 사이트맵 항목은: 이 URL이 살아 있고, 색인 가능하며, 크롤러의 시간을 가치 있게 사용한다는 것을 주장합니다. 나열된 URL을 가져오면 3 모순이 드러납니다:

• Noindexed URL — 평가된 사이트의 33.3%. 사이트맵 항목은 "이것을 색인하십시오"라고 말하고, 동일한 URL에 대한 noindex 로봇 지시문은 "하지 마십시오"라고 말합니다. 크롤러는 원하지 않는 방향에서 모순을 해결하고, 혼합 신호는 파일의 나머지 부분에 대한 신뢰를 저하시킵니다. 1는 우리가 사이트맵 멤버를 가져올 수 있었던 사이트의 3에서 최소 1 이상의 이러한 모순이 존재했습니다.
• URL 리다이렉션 — 26.3%. 301 또는 302가 다른 곳에 있는 항목. 사이트맵은 최종 URL을 나열해야 합니다; 그 안의 모든 리다이렉트는 오래된 주장이며, 각 크롤마다 추가 왕복을 초래합니다.
• 소프트 404s — 21.7%. 200에 답하지만 실제로 존재하지 않는 페이지, 예를 들어 성공 상태로 제공되는 "찾을 수 없음" 메시지나 빈 템플릿. 각각은 크롤 예산을 소모하고 크롤러에게 사이트맵이 과장되었다는 것을 가르칩니다.

이 비율은 검증 숫자보다 낮게 실행되지만, 결과를 가중치할 때 순서가 뒤집힙니다. 무효한 lastmod는 스케줄링 힌트를 잃게 합니다. 모순과 소프트 404s가 가득한 사이트맵은 파일 전체에 대한 크롤러 신뢰를 잃게 합니다.

우리 자체 사이트맵은 모든 기사를 숨기면서도 검증을 통과했습니다

2026년 8월 15일, 우리는 seoreport.dev의 사이트맵이 URL 우리가 지금까지 게시한 모든 기사를 조용히 생략하고 있음을 발견했습니다.

원인은 8월 1에 배포한 권한 강화였습니다. API의 플러그인 라우트가 기본 거부로 이동했습니다 — 올바른 보안 태세 — 그러나 허용 목록은 단일 내부 표면만 허용했습니다. 공개 기사 엔드포인트는 익명 호출자에게 401로 응답하기 시작했으며, 우리 자체 사이트맵 생성기와 기사 페이지도 포함되었습니다. 생성기는 실패를 포착했지만 아무 것도 기록하지 않았고, 정적 페이지만 포함된 완전히 유효한 사이트맵을 발행했습니다. 기사 페이지는 빈 목록을 렌더링했습니다. 게시된 모든 기사는 창에서 0 조회수를 기록했습니다.

모든 것이 계속 통과했기 때문에 경고가 없었습니다. 사이트맵은 파싱되어 네임스페이스를 선언하고, 잘 형성된 lastmod 값을 가진 실제 200-상태 URL을 나열했습니다. 검증 기준에 따라 57.1%가 실패하는 감사 사이트 중 우리 사이트는 모범 사례였습니다. 또한 존재 이유 전체가 누락되었습니다. 실패는 파일이 구문적으로 유효하게 유지되었기 때문에 정확히 보이지 않았습니다 — 무시되고 합리적인 출력으로 서서히 전환되는 대체는 충돌보다 나쁩니다, 충돌은 같은 날 바로 수정됩니다.

우리는 같은 날 4 이동에서 이를 수정했습니다. 권한 경계는 이제 게시된 기사 읽기를 명시적으로 허용합니다 — 목록, 슬러그별, 조회수 카운터 — 메서드 범위, 초안 및 변형은 기본 거부 상태를 유지합니다. 사이트맵 생성기와 기사 가져오기 도구는 이제 오류 수준에서 공개 표면 실패를 기록합니다, 저하 대신. 헬스‑체크 차원은 익명 기사 경로를 지속적으로 탐지하므로, 이 종류의 장애 페이지는 운영자가 빈 페이지를 인간이 인지하기를 기다리는 대신에 자동으로 처리합니다. 그리고 우리는 같은 날 IndexNow를 통해 전체 URL 세트를 재제출했습니다 — 이는 추가 교훈을 가져왔습니다: /.well-known/ 아래에 호스팅된 IndexNow 키 파일은 해당 경로 아래의 URL만 보증할 수 있으므로, 키를 사이트 루트에 두거나 사이트 전체 제출이 422를 반환하도록 해야 합니다.

위생 계약: 사이트맵은 그 안의 모든 URL에 대한 약속 세트입니다

검증은 바닥입니다. 보유할 가치가 있는 표준은 모든 항목이 4 약속을 지키고, 파일 자체에 대해 1 약속을 추가로 지키는 것입니다:

1. 살아 있음: URL이 직접 200을 반환합니다. 3xx, 404, 챌린지 페이지는 없습니다. 최종 URL만 나열합니다. 기계적으로 확인합니다:

  | xargs -n1 -P4 curl -s -o /dev/null -w '%{http_code} %{url_effective}
' \
  | grep -v '^200'

출력이 있으면 위반입니다.

2. 색인 가능: 모순되는 지시어가 없습니다. ``, no X-Robots-Tag: noindex 헤더도 없고, robots.txt 규칙이 경로를 차단하지도 않습니다. URL이 색인되지 않아야 한다면, 이를 사이트맵에서 제거하고 noindex와 함께 나열하지 않아야 합니다.<meta name="robots" content="noindex">, no X-Robots-Tag: noindex` 헤더, robots.txt 규칙이 경로를 차단하지 않음. 만약 URL이 인덱싱되지 않아야 한다면, 해결책은 sitemap에서 제거하고 noindex를 붙여서 목록에 포함시키지 않는 것입니다.

3. 정규: 페이지가 자신을 가리키도록 정규화됩니다. rel=canonical가 다른 곳을 가리키는 항목은 크롤러에게 제출한 것과 다른 URL를 색인하도록 지시합니다. 정식 항목을 나열하고 변형은 제외합니다.

4. 진실된 lastmod. W3C 형식 전용 — 2026-08-24 또는 2026-08-24T08:00:00-05:00 — 실제 콘텐츠 변경에 의해 주도됨. 배포 시간을 찍는 빌드 파이프라인은 당신의 lastmod가 아무 의미가 없다고 알리고, 크롤러가 그렇게 대우하도록 학습합니다.

5. 완전: 파일에는 필요한 내용이 포함되어 있고 누군가가 확인 중입니다. 이것은 우리 사건이 깨뜨린 약속입니다. XML 유효성은 구성을 말하지 않으므로 구성을 직접 모니터링합니다 — 각 예상되는 URL 클래스가 존재함을 단언하고, 클래스가 0으로 붕괴될 때 알림을 보냅니다:

count=$(curl -s https://example.com/sitemap.xml | grep -c '/articles/')
[ "$count" -ge 1 ] || echo "ALERT: sitemap lost its article URLs"

사이트맵 생성기는 더 작은 유효 파일로 퇴화해서는 안 됩니다. 사이트맵 생성기는 절대로 더 작은 유효 파일로 변환돼서는 안 된다.

유료 SEOReport 진단은 매 실행 시 첫 번째 4개의 약속을 테스트하고, 어떤 항목이 어떤 약속을 깨는지 정확한 URL과 함께 보여줍니다. 다섯 번째는 당신의 사이트맵에 무엇이 포함되어야 하는지 아는 것이 필요하며, 이는 오직 당신만이 알 수 있습니다; 이를 반복 가능한 루틴에 통합하는 체계적인 방법은 체계적인 SEO 감사를 수행하는 방법에 다루어집니다.

검증된 사이트맵은 진실한 사이트맵이 아니다. 57.1% 사이트는 바닥에 도달하지 못했고, 바닥은 수리의 오후이다. 천장 — 모든 항목이 살아 있고, 색인 가능하며, 정식이며, 정직하게 날짜가 매겨지고, 완전한 파일 — 은 크롤러가 귀하의 사이트맵을 진실의 출처로 취급하게 만드는 것이다. 우리는 지금 두 가지 표준을 지속적으로 점검하고 있다. 우리는 자체 도메인에서 차이점을 스스로 배웠고, 검증기가 모든 것이 괜찮다고 말했을 때 어려운 방법으로 배웠다.