カノニカルの衝突：サイトマップとページが一致しないとき

サイトマップエントリは指名です。 それは：この正確な URL、バリエーションではなく、インデックスする価値があるものです。 5月 23 と August 31, 2026 の間で、各サイトが実際に提供しているものと指名をテストしました ― 122 評価は、サイトマップメンバー URL が取得可能だった 29 ドメインで行われました。 その評価の 52% が失敗しました。少なくとも 1 つのサンプリングサイトマップ URL が、サイトマップで指定されたアドレスとは別のアドレスにクローラーを送信したためです。

最新の監査でドメインごとに測定すると、同じチェックは 21% の 29 サイトで失敗します。 両方の数値は正確であり、それらの間の距離は、どちらか一方だけよりも多くの情報を持ちます。

ドメインの 5 分の 1 がこの欠陥を持ち、監査履歴全体にわたってそれを保持します

そのギャップを開く 2 つのメカニズムがあり、両方とも指名する価値があります。 このチェックに失敗するサイトは、通常、実行するすべての監査で失敗します。原因は生成器設定または URL-スキームの移行であり、一時的なものではないため、失敗したドメインは多くの失敗評価に寄与します。 そして、修正したサイトはサイトレベルの率から除外されますが、以前の失敗は評価カウントに残ります。 評価数は、クローラーが到着したときに矛盾がどれだけ頻繁にライブであるかを示します。 サイト数は、今日まだそれを持っているドメインの数を示します。

Methodology: サイトレベルのレートは、各ドメインの最新完了監査スナップショット（約 5 月 23 – August 31, 2026）を使用し、匿名化されています。 Evaluation レベルのレートは、同じウィンドウ内でそのチェックのすべての評価をカウントします。これが 29 ドメインが 122 評価を生成する理由です。 分母はチェックによって 29 から 49 サイトまで変動します。チェックは入力が存在する場所でのみ実行されるため、取得可能なサイトマップメンバーがないドメインはサイトマップページの判定を生成しません。 サンプルは監査を実施したオーナーから自己選択で抽出され、小規模〜中規模に偏っています。したがって、レートはそのセグメントに対する方向性として扱ってください。

目的の URL と実際に読者が受け取る宛先を比較する

重要なページの場合、サイトマップの URL、リダイレクト後の最終アドレス、および宣言された Canonical を記録します。変更前に差異を説明してください。 製品バリアントは親ページに統合できる場合があります。ホスト名移行を忘れたケースは別の状況です。 有用な質問は、現在のシグナルがオーナーの意図した宛先を表しているかどうかです。

その比較は sitemap hygiene を補完します。 サイトマップは XML で有効であり、別のページに転送されるアドレスをリストすることがあります。

Canonical の不一致には実例が必要です

サイトマップに /products/blue-widget がリストされ、/shop/blue-widget/ にリダイレクトされると仮定します。 宛先は /products/blue-widget を Canonical と宣言します。読者はショップページに到達しますが、メタデータは転送先アドレスを指しています。

合理的な修復は、意図した永続的な宛先 を選択することから始まります。 それが /shop/blue-widget/ であれば、サイトマップ、内部リンク、Canonical 宣言を更新して一致させます。 古いリンクには正当な移行リダイレクトを保持します。 その後、宛先がアクセス可能でインデックス可能であり、読者が期待した製品を含むことを確認します。 Google の Canonicalization ガイダンス は、リダイレクト、Canonical、サイトマップのシグナルがその決定にどのように関与するかを説明しています。宣言された Canonical は好みであり、Google が従うべき命令ではありません。

もう一つのパターンは、同一ページ内で矛盾する Canonical 宣言です。 テーマと SEO プラグインはそれぞれタグを生成し、異なる宛先を命名することがあります。 すべての宣言を検査し、意図した値に単一のコンポーネント所有権を与えます。 簡単なテキスト検索は有用な手がかりですが、ドキュメントの解析や HTTP ヘッダーの確認を置き換えるものではありません。

第三のパターンは、移行後にリダイレクトされる正規ターゲットです。 宣言を意図した最終アドレスに更新し、各コンシューマーが古いルートを追跡するのをやめさせます。 indexability conflicts guide は、これを意図的な除外と区別するのに役立ちます。

29% 欠落した正規観測はレビューの機会であり、影響を受けるすべてのページがインデックス不可であるという証拠ではありません。 検索エンジンは明示的な宣言なしに正規を選択できます。 重複またはパラメータ付きURLの場合、一貫した優先順位はサイトの意図を明確にします。 canonical tags guide はその基礎をカバーしています。

第二の正規タグは、誰も監視していないレイヤーから来ます

重複した正規は、2 タグを書いている人から来ることはほとんどありません。 それらは、ドキュメントヘッドを所有していると信じる各 2 レイヤーから来ます。 SEOプラグインは1つを発行し、テーマヘッダー部分は別のものを発行し、フレームワークメタデータエクスポートは3つ目を発行します — 各は単独で正しいが、すべて 3 がレンダリング時に連結されます。 ネストされたルートで2回含まれたレイアウトコンポーネントは同じ結果を生成します。 サーバーがすでに送信した正規の上にクライアント側で正規を注入するタグマネージャコンテナも同様です。

その最後のケースは、配信されたレスポンスを関連性のあるものにします。 ブラウザ専用の変更が疑われる場合、元の HTML とレンダリングされたドキュメントを比較します。 すべてのクローラーが同一にレンダリングするとは仮定せず、実際の差異を記録します。 Rendering evidence は、ページが正しく見える一方で、特定のフェッチが別のものを受け取る理由を示します。

次のリリースを生き残る修復領収書を保管します

blue-widget の例では、古いサイトマップエントリ、選択された宛先、デプロイされたメタデータ、およびリリース後のレスポンスを記録する有用な領収書があります。 カテゴリページからの内部リンクも確認します。 タグを修復してもナビゲーションが古い URL を指し続ける修復は、回避可能な作業を残します。

Search Console は別の観測を追加します：最後の検査時に選択された正規 Google。 検査時間を記録します。 本日デプロイされた正しいレスポンスは、Google のインデックスがすでにそれを取り込んでいることを示すものではありません。 古い証拠に応じて一貫したページを繰り返し変更する代わりに、再クロール後に再確認します。

URL の生成を明確な所有者の下に保つ。 サイトが推奨ホスト名、ロケールレイアウト、またはトレーリングスラッシュ規約を変更した場合、サイトマップエントリとカノニカル宣言を一緒にレビューする。 製品が必要とする意図的な代替パスを保持し、それらが存在する理由を文書化する。

報告書は、レビュアーに影響を受ける URL、観測された不一致、および修正を検証するための十分なコンテキストを提供することで、そのワークフローに位置づけられる。 耐久性のある結果は、意図されたコンテンツへの安定した入口であり、次のデプロイメントと比較できる領収書を伴う。