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

2026년 5월 5일부터 8월 15일까지, 우리는 감사를 마친 모든 사이트의 XML 사이트맵을 검증했습니다 — 49개 도메인, 각 도메인의 최신 스냅샷. 그 중 28개, 즉 57.1%가 바로 검증에 실패했습니다: 잘못된 XML, 프로토콜 네임스페이스 누락, 끊어진 loc 항목, 또는 크롤러가 존중해야 할 필요가 없는 lastmod 값. 이는 우리가 측정한 가장 파손된 탐색 파일이 사이트맵임을 의미합니다. 같은 주에 이 숫자들을 정리하던 중, 우리는 우리 도메인에서 가장 교육적인 사이트맵 실패를 발견했습니다 — 모든 검증을 통과한 사이트맵 안에 있었던 것입니다.

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

우리의 엔진은 4개의 별도 사이트맵 검사를 수행하며, 그 실패는 의미 있는 순서로 나타납니다. 검증 — 가장 얕은 검사 — 가 가장 많이 실패합니다. 더 깊은 검사는 나열된 URL을 가져와 각 URL이 사이트맵에 포함될 자격이 있는지 테스트합니다. 이 검사는 덜 자주 실패하지만, 실패할 때는 비용이 더 듭니다.

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

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

사이트맵 프로토콜은 작으며, 바로 그 이유로 실패를 피할 수 있습니다. 우리의 검증기는 실제로 프로토콜이 요구하는 것을 확인합니다: 문서는 XML로 파싱되며, 루트 요소는 urlset 또는 sitemapindex이며 사이트맵 네임스페이스를 선언하고, 모든 항목은 동일한 사이트에 있는 사이트맵과 같은 절대 HTTP 또는 HTTPS URL인 정확히 1개의 비어 있지 않은 loc을 가지고 있으며, 모든 lastmod은 유효한 W3C 날짜 또는 타임존이 지정된 날짜/시간입니다. 실패는 마지막 2 규칙에서 집중됩니다. 교차 사이트 loc 항목은 일반적으로 스테이징 호스트명 또는 CDN 출처가 프로덕션에 유출된 것을 의미합니다. 그리고 lastmod은 무효 값의 조용한 챔피언입니다: 생성기는 2026-07-14 19:10:31처럼 데이터베이스 타임스탬프를 기록하는 것을 좋아합니다 — T 대신 공백, 타임존 없음 — 이는 W3C 날짜/시간이 아닙니다. Google의 사이트맵 문서는 값이 일관되고 검증 가능할 때 lastmod을 사용한다고 말합니다; 구문 분석할 수 없는 형식은 모든 항목에서 해당 신호를 포기합니다. 잘린 파일도 실패합니다: 전송 중간에 잘린 사이트맵은 더 작은 사이트맵이 아니라 깨진 사이트맵입니다. 이 클래스의 모든 실패는 구성 레이어 수정을 의미하며, 우리는 가장 많이 실패한 감사 체크에서 10 체크 웹사이트가 가장 많이 실패하는 동일한 패턴을 발견했습니다: 오류는 브라우저가 렌더링하는 것보다 아래에 있으므로 기계가 확인하지 않는 한 아무도 보지 못합니다.

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

3 더 깊은 체크는 사이트맵을 주장 집합으로 간주하고 각각을 테스트합니다. 사이트맵 항목은: 이 URL는 살아 있고, 색인 가능하며, 크롤러의 시간을 가치 있게 사용합니다. 우리의 엔진은 샘플링된 나열된 URL을 가져와 3 모순을 찾습니다:

• Noindexed URLs — 평가된 사이트의 33.3%. 사이트맵 항목은 "이것을 색인하십시오"라고 말하고, 동일한 URL에 대한 noindex robots 지시문은 "하지 마십시오"라고 말합니다. 크롤러는 당신이 원하지 않는 방향으로 모순을 해결하며, 혼합 신호는 파일의 나머지 부분에 대한 신뢰를 저하시킵니다. 1 3 사이트에서 사이트맵 멤버를 가져올 수 있었던 곳은 최소 1 이 이러한 모순이 존재했습니다.
• URL 리다이렉트 — 26.3%. 301 또는 302 다른 곳으로 이동하는 항목. 사이트맵은 최종 URL을 나열해야 합니다; 그 안의 모든 리다이렉트는 오래된 주장이며 크롤링마다 추가 왕복을 초래합니다.
• 부드러운 404s — 21.7%. 200에 답하지만 실제로 존재하지 않는 페이지: 제목, 헤딩, 또는 시작 텍스트가 "찾을 수 없음"이라고 말하는 얇은 응답, 거의 단어가 없는 페이지, 또는 홈페이지로 정규화되는 페이지. 각각은 크롤링 예산을 소모하고 크롤러에게 사이트맵이 과장되었다는 것을 가르칩니다.

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

우리 자체 사이트맵은 검증을 통과했지만 모든 기사를 숨겼습니다

2026년 8월 15일, 우리는 seoreport.dev의 사이트맵이 모든 기사를 조용히 생략하고 있다는 것을 발견했습니다 URL 우리가 지금까지 게시한 모든 기사. 원인은 8월 1에 배포한 권한 강화였습니다. API의 플러그인 경로를 기본 거부로 이동했습니다 — 올바른 보안 태세 — 그러나 허용 목록은 내부 표면 1개만 허용했습니다. 공개 기사 엔드포인트는 익명 호출자에게 401에 응답하기 시작했습니다, 우리 자체 사이트맵 생성기와 우리 자체 기사 페이지를 포함하여. 생성기는 실패를 포착하고 아무것도 기록하지 않았으며, 정적 페이지만 포함하는 완전히 유효한 사이트맵을 발행했습니다. 기사 페이지는 빈 목록을 렌더링했습니다. 게시된 모든 기사는 창문 에서 0 조회수를 기록했습니다. 모든 것이 계속 통과했기 때문에 경고가 없었습니다. 사이트맵은 파싱되어 네임스페이스를 선언하고, 잘 형성된 lastmod 값을 가진 실제 200-상태 URL을 나열했습니다. 검증 기준에 따라 57.1% 감시 사이트가 실패하는 경우, 우리 것은 모범적이었습니다. 또한 존재 이유 전체가 누락되었습니다. 실패는 파일이 구문적으로 유효하게 유지되기 때문에 완전히 보이지 않았습니다 — 무시되는 출력으로 부드럽게 전환되는 대체는 충돌보다 나쁩니다, 충돌은 같은 날에 수정됩니다. 우리는 1 일에, 4 이동에서 고쳤습니다. 권한 경계는 이제 게시된 기사 읽기를 명시적으로 허용합니다 — 목록, 슬러그별, 조회수 카운터 — 메서드 범위, 초안 및 변형은 기본 거부를 유지합니다. 사이트맵 생성기와 기사 가져오기 도구는 이제 오류 수준에서 공개 표면 실패를 기록합니다, 저하 대신. 건강 점검 차원은 익명 기사 경로를 지속적으로 탐지하므로, 이 종류의 중단 페이지는 운영자가 빈 페이지를 인간이 인지하기를 기다리는 대신에 탐지합니다. 그리고 우리는 같은 날 IndexNow을 통해 전체 URL 세트를 재제출했습니다 — 그 과정에서 또 다른 교훈이 드러났습니다: /.well-known/ 아래에 호스팅된 IndexNow 키 파일은 해당 경로 아래의 URL만을 보증할 수 있으므로, 키를 사이트 루트에 두거나 모든 사이트 전역 제출이 422를 반환하도록 해야 합니다.

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

검증은 바닥입니다. 보유할 가치가 있는 표준은 모든 항목이 4 약속을 지키고, 파일 자체에 대해 1 약속을 추가로 지키는 것입니다. 3xx가 없으면, 404이 없으면, 도전 페이지가 없습니다. 최종 URL만 나열하십시오. 기계적으로 확인하십시오: 1. Alive: URL가 200을 직접 반환합니다.

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' \
  | xargs -n1 -P4 curl -s -o /dev/null -w '%{http_code} %{url_effective}
' \
  | grep -v '^200'

출력이 있으면 위반입니다. 2. Indexable: 모순되는 지시가 없습니다. No <meta name="robots" content="noindex">, no X-Robots-Tag: noindex 헤더, robots.txt 규칙이 경로를 차단하지 않습니다. URL가 색인되지 않아야 한다면, sitemap에서 제거하고 noindex를 붙여 목록에 넣지 않는 것이 해결책입니다. rel=canonical가 다른 곳을 가리키는 항목은 크롤러에게 제출한 것과 다른 URL를 색인하도록 지시합니다. 정규 URL을 나열하고 변형은 버리십시오. 3. Canonical: 페이지가 자신을 정규화합니다. W3C 형식만 — 2026-08-24 또는 2026-08-24T08:00:00-05:00 — 실제 콘텐츠 변경에 의해 주도됩니다. 모든 항목에 배포 시간을 스탬프하는 빌드 파이프라인은 당신의 lastmod가 아무 의미가 없음을 알리고, 크롤러는 그렇게 대우하도록 학습합니다. 4. 정직한 lastmod. 이것은 우리 자체 사건이 깨뜨린 약속입니다. XML 유효성은 구성을 말하지 않으므로 구성을 직접 모니터링하십시오 — 각 예상되는 URL 클래스가 존재하는지 확인하고, 클래스가 0으로 붕괴될 때 경고하십시오: 5. 완료: 파일이 포함해야 할 내용을 포함하고 있으며, 누군가가 확인하고 있습니다.

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

생성기를 정직하게 만드십시오: 데이터 소스가 실패하면 크게 로그를 남기고 빌드를 실패시키십시오. 사이트맵 생성기는 더 작은 유효 파일로 변질되어서는 안 됩니다. 첫 번째 4개의 약속은 매 실행 시 우리의 감사가 확인하는 내용이며 — 무료 보고서는 어떤 항목이 어떤 약속을 깨는지와 정확한 URL을 보여줍니다. 다섯 번째는 사이트맵에 무엇이 포함되어야 하는지 아는 것이 필요하며, 이는 오직 당신만이 알고 있습니다; 이를 반복 가능한 루틴에 통합하는 체계적인 방법은 시스템적 SEO 감사를 수행하는 방법에 다루어집니다. 검증된 사이트맵은 진실한 사이트맵이 아닙니다. 57.1% 사이트는 바닥에 도달하지 못했으며, 바닥은 수리의 오후입니다. 천장 — 모든 항목이 살아 있고, 색인 가능하며, 정규화되고, 정직하게 날짜가 매겨지고, 완전한 파일 — 은 크롤러가 당신의 사이트맵을 진실의 출처로 취급하게 만드는 것입니다. 우리는 지금 두 가지 기준을 지속적으로 점검하고 있습니다. 왜냐하면 우리는 자체 도메인에서 차이를 스스로 배우고, 검증기가 모든 것이 괜찮다고 말했을 때 어려운 방법으로 배웠기 때문입니다.