SEO監査したXMLサイトマップの多くは検証に失敗する。自社のものは有効でも間違っていた

2026 年 5 月 5 日から 8 月 15 日の間に、監査を完了したすべてのサイトの XML サイトマップを検証しました — 49 ドメイン、各最新スナップショット。 そのうち 28 件、57.1% が一度に検証に失敗しました：不正な XML、プロトコル名前空間の欠落、壊れた loc エントリ、またはクローラが尊重する必要のない lastmod 値。 これにより、サイトマップは測定した中で最も壊れた発見ファイルとなります。 同じ週にこれらの数値をまとめたとき、私たち自身のドメインで最も教訓的なサイトマップ失敗を発見しました — すべての検証チェックに合格したサイトマップの中で。

サイトマップの半分以上がクローラが最初の URL を読む前に失敗します

サイトマップは 2 つの深さで失敗し、その失敗には明確な順序があります。 検証 — 最も浅いテスト — が最も失敗します。 より深いテストは、リストされた 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 を使用すると述べている；解析できない形式はすべてのエントリでそのシグナルを放棄する。* ファイルが切り捨てられると失敗する：転送途中で切断されたサイトマップは小さなサイトマップではなく、壊れたものだ。 このクラスの失敗はすべて設定層の修正であり、私たちが見つけた同じパターンはthe 10 checks websites fail mostにあります：エラーはブラウザが描画するものの下に存在し、機械が確認しない限り誰もそれを見ません。

有効なサイトマップは依然としてクローラーを死んだページに送ることができる

より深いテストはサイトマップを一連の主張として扱い、各主張をテストする。 サイトマップエントリは：この URL は生きており、インデックス可能で、クローラーの時間を割く価値があると主張する。* リストされた URL を取得すると、3 つの矛盾が明らかになる：*

• Noindexed URLs — 評価されたサイトの33.3%。サイトマップエントリは「このURLをインデックスする」と述べ、同じ 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 ビューを記録しました。 何も警告されず、すべてが通過し続けました。 サイトマップは解析され、名前空間を宣言し、正しい 200 ステータス URL をリストし、正しい lastmod 値を持つページを示しました。 監査対象サイトが失敗する 57.1% の検証基準により、私たちのサイトマップは模範的でした。 それは存在する理由すら欠けていました。 失敗はファイルが構文的に有効であるために不可視でした — 静かに妥当な出力に落ちるフォールバックは、クラッシュより悪いです。クラッシュは同じ日に修正されます。 私たちは 1 日で、4 の移動で修正しました。 認可境界は公開記事の読み取りを明示的に許可します — リスト、スラッグ別、ビューカウンタ — メソッドスコープで、ドラフトと変更はデフォルト拒否のままです。 サイトマップジェネレーターと記事フェッチャーは、エラー レベルで公開表面の失敗をログし、劣化を防ぎます。 ヘルスチェック次元は匿名記事ルートを継続的に監視し、オペレーターが空ページを人間が気付くのを待つ代わりに、この種の障害ページを検知します。 そして、同じ日に完全なURLセットをIndexNow経由で再提出しました — そこからさらに学んだことは、/.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: 反対の指示がない。 なし<meta name="robots" content="noindex">, no X-Robots-Tag: noindex ヘッダーも、robots.txt でパスをブロックするルールもありません。URL がインデックスされるべきでない場合、修正はそれをサイトマップから削除し、noindex を付けてリストしないことです。 rel=canonical が別の場所を指すエントリは、クローラーに提出したものとは別の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"

生成器を正直にします：データソースが失敗したときは大きくログに記録し、ビルドを失敗させます。 サイトマップ生成器は決して小さな有効ファイルに劣化してはなりません。 有料の SEOReport 診断 は、実行のたびに最初の 4 つの約束をテストし、どのエントリがどの約束を破っているかを、正確な URL とともに示します。 5 番目は、あなたのサイトマップに何が含まれるべきかを知る必要があります。これはあなたしか知りません。システマティックな SEO 監査を実行する方法は、システマティックな SEO 監査の実行方法 に記載されています。 検証されたサイトマップは、真実のサイトマップではありません。 57.1% のサイトは床に到達していません、そして床は修正の午後です。 天井 — すべてのエントリが生きており、インデックス可能で、正規化され、正直に日付が付けられ、完全であるファイル — は、クローラーがあなたのサイトマップを真実の源として扱う理由です。 私たちは両方の基準を継続的にチェックしています。なぜなら、私たち自身のドメインで、バリデーターがすべて問題ないと言ったときに、違いを自分たちで学んだからです。