canonicalタグを間違えると何が起きるか

canonicalタグは重複コンテンツを消す道具ではない

canonicalタグは、同一またはかなり類似したコンテンツを含むURLが複数ある場合に、どのURLを優先するかを検索エンジンに伝えるものです。一般的なHTML版は次のようになります。

<link rel="canonical" href="https://example.com/preferred-page/">

HTTPヘッダー版もあり、主にPDFなどの非HTMLファイルで役立ちます。

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

これだけなら十分に単純に見えます。問題は、チームがcanonicalタグを、扱いにくいものを安全に片付ける手段として使い始めたときに起こります。ファセットナビゲーション、トラッキングパラメータ、印刷用ページ、ほぼ重複した商品ページ、ページネーション、ステージングURL、古いキャンペーンページなどです。

canonicalタグは削除ボタンではありません。リダイレクトでもありません。情報設計の代替でもありません。そして、必ず従われるとは限りません。

検索エンジンはcanonicalを強いヒントとして扱います。canonicalタグを、リダイレクト、内部リンク、サイトマップURL、hreflangアノテーション、コンテンツの類似性、HTTPステータスコード、そしてユーザーやクローラーが実際に遭遇するURLなど、他のシグナルと比較します。これらのシグナルが衝突している場合、検索エンジンはcanonicalを無視したり、まったく別のcanonical URLを選んだりすることがあります。

だからこそ、canonicalの設定ミスは非常に分かりにくくなります。ブラウザ上ではマークアップが正しく見えるのに、検索結果には間違ったページが表示される、あるいは正しいページが消えてしまうのです。

canonicalが誤ったURLを指すと何が起きるか

検索エンジンが重複またはほぼ重複したURLを見つけると、通常それらをクラスターにまとめ、その中から1つのURLをcanonicalとして選びます。選ばれたcanonicalは、インデックスされ、検索結果に表示される可能性が最も高いバージョンです。重複ページからのシグナルは、その選ばれたURLへ統合されることがあります。

canonicalタグが誤ったページを指している場合、いくつかのことが起こり得ます。

1. 間違ったURLがインデックスされる

次の2つのURLがあるとします。

• /mens-running-shoes/
• /sale/mens-running-shoes/

セールページのcanonicalがメインカテゴリページを指している場合、そのコンテンツがほぼ同一で、セールURLが単なるフィルター済みバージョンであれば問題ないかもしれません。しかし、セールページに独自のコピー、独自の商品、独自の検索需要がある場合、そのcanonicalはセールページを抑制してしまいます。

そのページは引き続きクロールされるかもしれません。ユーザーも引き続きアクセスできるかもしれません。しかし検索エンジンは、別のURLが優先バージョンだとあなたが伝えたため、そのページを個別にはインデックスしないと判断することがあります。

これは最も一般的なcanonicalの失敗です。劇的な技術的障害ではなく、インデックスから静かに消えるだけです。

2. ランキングシグナルが誤った場所へ統合される

canonicalは、リンクや重複コンテンツのバリエーションなどのシグナルを統合するためによく使われます。重複が本当に同等であれば、これは有用です。そうでない場合は危険です。

ブログ記事に次のようなトラッキングURLがある場合です。

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

この2つを /guide-to-canonical-tags/ にcanonical化するのは妥当です。

しかし、スペイン語版、追加コンテンツを含む印刷用ページ、または異なる意図を持つ商品バリエーションが同じcanonicalを指している場合、本来分けておくべきシグナルを統合してしまう可能性があります。その結果、すべての関連性が弱まることがあります。

canonicalタグは同等性に関するものです。2つのページが異なる検索意図を満たすなら、おそらく互いにcanonical化すべきではありません。

3. 検索エンジンがタグを無視する

canonicalは命令ではありません。canonicalの対象がリダイレクトする、404を返す、ブロックされている、noindex がある、またはまったく異なるコンテンツを含む場合、検索エンジンはそれを無視することがあります。

これはある意味では良いことです。不適切なcanonicalが常にインデックスを破壊するわけではないからです。しかし同時に、そのタグが自分の意図どおりに機能していると決めつけることはできません。あるページが1つのcanonicalを宣言していても、Googleが別のものを選ぶことがあります。

これは、内部リンク、サイトマップ、canonicalが一致していない場合に特によく起こります。すべての内部リンクが /product を指し、サイトマップには /product/ が記載され、canonicalは https://www.example.com/product?ref=main を指しているなら、自分のシグナル同士で小さな論争を作っていることになります。

検索エンジンはその論争を解決するのが得意です。ただし、あなたが意図した方法で解決してくれるとは限りません。

4. デバッグが不必要に難しくなる

不適切なcanonicalは、ほとんどの場合、大きな音を立てて失敗しません。次のような、他のSEO問題に見える症状を生みます。

• 「検出済み - インデックス未登録」または同等のインデックス保留状態
• クエリに対して誤ったURLが順位表示される
• パラメータ付きURLがレポートに表示される
• クロール可能なのにカテゴリページが表示されない
• 国際向けページが誤った言語バージョンに折りたたまれる
• 新しいテンプレートの公開後、インデックスページ数が想定より少ない

そのため、canonicalのデバッグでは、生のHTML、レンダリング後のHTML、HTTPヘッダー、リダイレクト、サイトマップ項目を確認する必要があります。すでにリダイレクトチェーンやヘッダー不一致を調査しているなら、同じ習慣が役立ちます。本番環境でリダイレクトとHTTPヘッダーをデバッグするための小さなツールキットに関するガイドのような実践的なHTTP検査ワークフローは、CMSの入力欄を眺め続けるよりも早くcanonicalの矛盾を見つけられることが多いでしょう。

最も高くつくcanonicalのミス

すべてをホームページにcanonical化する

これは今でも起こります。テンプレートのフィールドが空のままになり、プラグインがサイトルートにフォールバックし、突然何百ものページがホームページをcanonicalとして宣言します。

コンテンツが明らかに異なるため、検索エンジンはこれを無視するかもしれません。しかし、十分にシグナルが混乱していれば、一部のページが除外されたり、誤ってクラスタリングされたりすることがあります。少なくとも、すべてのページで無意味で矛盾したヒントを送っていることになります。

ホームページが内部ページのcanonicalになることは、ほとんどありません。

ページネーションされたページを1ページ目にcanonical化する

長い間、一部のサイトは /category/page/2/、/page/3/ などを1ページ目へcanonical化していました。意図は、重複したカテゴリページを避けることでした。

問題は、ページネーションされたページは重複ではないという点です。異なる項目を含み、クローラーがより深いコンテンツを発見する助けになります。それらすべてを1ページ目へcanonical化すると、検索エンジンが後続ページを十分に処理する可能性を下げることがあります。

通常、ページネーションされたページには、統合する特別な理由がない限り、自己参照canonicalを設定すべきです。

検索意図を確認せずにフィルター済みページをcanonical化する

ファセットナビゲーションは難しい判断を生みます。一部のフィルター済みURLは不要です。

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

一方で、価値のあるランディングページになり得るものもあります。

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

一律のcanonicalルールは、不要なパラメータノイズと一緒に、有用な検索向けページまで消してしまうことがよくあります。フィルター済みページをcanonical化する前に、そのページに安定したコンテンツ、内部リンク、検索需要、明確なユーザーニーズがあるかを確認してください。

答えが「はい」なら、そのページは自己参照canonicalを持つインデックス可能なページに値するかもしれません。

リダイレクトまたはブロックされたURLをcanonicalの対象にする

canonicalの対象は、クリーンで、インデックス可能で、200 OK を返すべきです。リダイレクトするURL、エラーを返すURL、Cookieを要求するURL、robots.txt でブロックされているURL、または noindex を持つURLをcanonicalの対象にしてはいけません。

これは自動化しやすいチェックの1つです。サイトをクロールし、クリーンな200レスポンスを返さないcanonical対象を検出してください。

canonicalとnoindexを同じ意味で混用する

rel="canonical" と noindex は異なる問題を解決します。

重複があり、シグナルを優先URLへ統合したい場合はcanonicalを使います。ページをまったくインデックスさせたくない場合は noindex を使います。

両方を一緒に使うと、扱いにくいメッセージになります。「このページをインデックスしないでください。ただし、別のページへの重複シグナルとしても使ってください」という意味合いになるからです。検索エンジンは多くの場合これを処理できますが、明確な指示ではありません。ページが重複ならcanonical化します。検索結果に表示すべきでなく、有用な重複関係もないなら、noindex を検討してください。

実践的なcanonical監査

多くのcanonical問題を見つけるために、大規模なSEOプラットフォームは必要ありません。クロール、いくつかのURLサンプル、スプレッドシートから始められます。

重要なテンプレートごとに、次を確認してください。

1. ページにcanonicalタグが正確に1つだけあるか。 複数のcanonicalタグは曖昧さを生みます。
2. canonicalは絶対URLか。 プロトコルとホスト名を含む完全なURLを使います。
3. canonicalの対象は 200 OK を返すか。 リダイレクト、ブロック、エラーの対象は避けます。
4. canonicalの対象はインデックス可能か。 noindex なし、robotsブロックなし、認証要件なしであるべきです。
5. コンテンツは本当に同等か。 似ていることは、常に同等であることを意味しません。
6. 内部リンクは一致しているか。 可能な限りcanonical URL形式へリンクします。
7. サイトマップは一致しているか。 サイトマップには通常、canonicalでインデックス可能なURLを記載すべきです。
8. hreflangタグは一致しているか。 国際向けページでは、canonicalとhreflangの関係が一貫している必要があります。
9. レンダリング後のHTMLは生のHTMLと一致しているか。 JavaScriptがタグを変更または挿入することがあります。
10. 検索エンジンはどのcanonicalを選んだか。 検査ツールを使うと、宣言したcanonicalと選択されたcanonicalが異なる場合を確認できます。

ここではLighthouseも役立ちますが、限界の範囲内でのみです。Lighthouseは一部のクロール可能性やドキュメント上の問題を検出できますが、あなたの商業的意図やcanonical戦略を理解しているわけではありません。判定ではなく、1つの入力として扱ってください。有用な指摘とノイズを落ち着いて切り分ける方法が必要なら、慌てずにLighthouseレポートを読む方法を参照してください。

自己参照canonicalは通常よいデフォルトである

重要なインデックス可能ページは、通常、自分自身をcanonicalとして宣言すべきです。これは、検索エンジンがタグなしでは判断できないからではありません。パラメータ、トラッキングリンク、コピーされたURL、CMSの癖によって同じコンテンツへの別経路が生まれたとき、自己参照canonicalが曖昧さを減らすからです。

クリーンな商品ページでは、通常これが正しい形です。

<link rel="canonical" href="https://example.com/products/linen-shirt/">

トラッキングURLでは、canonicalは通常クリーンなバージョンを指すべきです。

<link rel="canonical" href="https://example.com/products/linen-shirt/">

本当に異なる商品バリエーションの場合、答えは状況によります。赤いシャツ、青いシャツ、黒いシャツが同じ説明を持ち、色だけが変わるなら、1つのcanonical商品ページで十分かもしれません。各バリエーションに個別の需要、レビュー、画像、在庫、内部リンクがあるなら、別々にインデックス可能なページにする意味があるかもしれません。

バリエーションに対する普遍的なcanonicalルールはありません。あるのは1つの問いだけです。これらのページは検索者にとって置き換え可能でしょうか。

canonicalタグはサイトの実際のURLポリシーと一致すべきである

canonicalのバグの多くは、より深いURLポリシー問題の症状です。そのサイトは、末尾スラッシュに意味があるのか、大文字のURLを解決すべきなのか、パラメータを許可するのか、HTTPをHTTPSへリダイレクトするのか、www をcanonicalにするのかを決めていません。

各URLについてクリーンなバージョンを1つ選び、システム全体を一致させてください。

• 非推奨のURLバージョンを推奨バージョンへリダイレクトする。
• 内部リンクでは推奨バージョンへリンクする。
• XMLサイトマップに推奨バージョンを入れる。
• 推奨ページでは自己参照canonicalを使う。
• 本当の重複だけを推奨URLへcanonical化する。

これらすべてのシグナルが同じ方向を指しているとき、canonicalタグは退屈なものになります。それが目標です。

結論

canonicalタグは、インデックスとシグナル統合に影響するため強力です。同じ理由で危険でもあります。

誤ったcanonicalが常にページを検索から削除するわけではありません。検索エンジンはそれを無視することがあります。しかし、悪いシグナルを検索エンジンが救済してくれることに依存するのは戦略ではありません。より安全なのは、canonical化を本当の重複に限定し、対象をクリーンでインデックス可能に保ち、内部リンク、リダイレクト、サイトマップ、canonicalが同じストーリーを語るようにすることです。

canonicalは、混乱した構造を隠す場所ではありません。構造が整理されたことを確認する場所です。