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

サイトマップエントリは指名です. それはこう言っています：この正確な URL、それの変種ではなく、インデックスする価値があるものです。 5月 23 と August 31, 2026 の間で、各サイトが実際に提供するものと指名をテストしました ― 122 評価は 29 ドメインで、サイトマップメンバー URL を取得できました. その評価の 52% が失敗しました。少なくとも 1 つのサンプリングサイトマップ URL が、サイトマップで指定されたアドレスとは別のアドレスにクローラーを送信したためです。 最新の監査でドメインごとに測定すると、同じチェックは 21% の 29 サイトで失敗します. 両方の数値は正確であり、二つの間の距離はどちらか一方だけよりも多くの情報を持ちます.

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

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

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

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

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

カノニカルの不一致には実例が必要です

サイトマップに /products/blue-widget がリストされ、これは /shop/blue-widget/ にリダイレクトされると仮定します。 宛先は /products/blue-widget をカノニカルとして宣言します。読者はショップページに到達しますが、メタデータは転送先アドレスを指しています。 合理的な修復は、意図した永続的な宛先 を選択することから始めます. それが /shop/blue-widget/ であれば、サイトマップ、内部リンク、カノニカル宣言を更新して一致させます。 古いリンクには正当な移行リダイレクトを保持します. その後、宛先がアクセス可能でインデックス可能であり、読者が期待した製品を含むことを確認します. Google のカノニカル化ガイダンス は、リダイレクト、カノニカル、サイトマップシグナルがその決定にどのように関与するかを説明しています。宣言されたカノニカルは好みであり、Google が従うべき命令ではありません。 もう一つのパターンは、同一ページ内で矛盾するカノニカル宣言です. テーマと SEO プラグインはそれぞれタグを生成し、異なる宛先を命名します. すべての宣言を検査し、意図した値に対して単一のコンポーネント所有権を与えます. 簡易テキスト検索は有用な手がかりですが、ドキュメントの解析や HTTP ヘッダーの確認を置き換えるものではありません 第三のパターンは、移行後にリダイレクトされる正規ターゲットです. 宣言を意図した最終アドレスに更新し、各コンシューマーが古いルートを追跡するのをやめさせます. indexability conflicts guide は、これを意図的な除外と区別するのに役立ちます. 29% missing-canonical 観測はレビューの機会であり、影響を受けるすべてのページがインデックス不可であるという証拠ではありません. 検索エンジンは明示的な宣言なしに正規を選択できます. 重複またはパラメータ付きURLの場合、一貫した優先順位はサイトの意図を明確にします. canonical tags guide はその基礎をカバーしています.

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

重複した正規は、2 タグを書いている人から来ることはほとんどありません. それらは、ドキュメントヘッドを所有していると信じる各 2 レイヤーから来ます. SEOプラグインは1つを発行し、テーマヘッダー部分は別のものを発行し、フレームワークメタデータエクスポートは3つ目を発行します—それぞれが単独では正しいが、すべて 3 がレンダリング時に連結されます. ネストされたルートで2回含まれたレイアウトコンポーネントは同じ結果を生成します. サーバーがすでに送信した正規の上にクライアント側で注入するタグマネージャーコンテナも同様です. その最後のケースは、配信されたレスポンスを関連性のあるものにします. ブラウザ専用の変更が疑われる場合、元の HTML とレンダリングされたドキュメントを比較してください すべてのクローラーが同一にレンダリングするとは仮定せず、実際の差異を記録します. Rendering evidence は、ページが正しく見える一方で、特定のフェッチが別のものを受け取る理由を示しています.

次のリリースを生き残る修復領収書を保管してください

blue-widget の例では、古いサイトマップエントリ、選択された宛先、デプロイされたメタデータ、およびリリース後のレスポンスを記録する有用な領収書があります. カテゴリページからの内部リンクも確認してください. タグを修復してもナビゲーションが古い URL を指し示し続ける修復は、回避可能な作業を残します。 Search Console は別の観測を追加します：最後の検査時に選択された正規 Google。 検査時間を記録します. 本日デプロイされた正しいレスポンスが、Google のインデックスにすでに組み込まれていることを示すわけではありません。 古い証拠に応じて一貫したページを繰り返し変更する代わりに、再クロール後に再確認してください. URL の生成を明確な所有者の下に保つ。 サイトが推奨ホスト名、ロケールレイアウト、またはトレーリングスラッシュ規約を変更した場合、サイトマップエントリとカノニカル宣言を一緒にレビューする. 製品が必要とする意図的な代替パスを保持し、それらが存在する理由を文書化する. 報告書は、レビュー担当者に影響を受ける URL、観測された不一致、および修正を検証するための十分なコンテキストを提供することで、そのワークフローでの位置を確立する。 耐久性のある結果は、意図されたコンテンツへの安定した入口であり、次のデプロイメントと比較できる領収書を伴う.