「適切な canonical タグあり代替ページ」の意味と修正方法
「ページのインデックス登録」レポートを開いたら「適切な canonical タグあり代替ページ」と表示された URL の一覧が見つかり、何か壊れているのではないかと気になっている。
Google Search Console で URL に**「適切な canonical タグあり代替ページ」**と表示されている場合、Google がページの重複版や代替版を見つけ、正規版を指す canonical タグを検出して、代わりにその正規 URL をインデックスに登録したという意味です。ほとんどの場合、仕組みは想定どおりに動いています。
このガイドでは、このステータスの意味、正常なケース、本当の問題を示すケース、そして WordPress、Shopify、Squarespace、Wix での修正方法を解説します。SEOcrawl AI の Indexation ビューでは、このステータスのすべての URL について、ユーザーが指定した正規 URL と Google が選択した正規 URL を並べて表示するので、サイト全体で本当に対応が必要な少数の URL をすぐに見つけられます。
Google Search Console の「適切な canonical タグあり代替ページ」とは？
このステータスは、Google が同じ canonical を指す複数のバージョンのページを見つけ、canonical タグに従って正規 URL をインデックスに登録したことを示します。対象の代替ページは訪問者には引き続き表示されますが、Google はそのページを個別にはインデックスしません。
**「適切な」という言葉は、Google が canonical の設定に同意しているという意味です。Google が指定した canonical を上書きする「重複しています。Google により、ユーザーがマークしたページとは異なる正規ページが選択されました」**のようなステータスとは、ここが大きく異なります。
GSC でこのステータスが表示される場所
Google Search Console でインデックス作成 › ページに移動し、**「ページがインデックスに登録されなかった理由」**の表を確認します。「適切な canonical タグあり代替ページ」をクリックすると対象の URL が表示され、エクスポートで全リストをダウンロードして分析できます。
代替、canonical、重複をひと言で
canonical URL は、正規版として指定したメインのバージョンです。代替 URL は同じまたは似たコンテンツを表示し、その canonical タグが正規版を指しています。**重複コンテンツ**とは、同じコンテンツが複数の URL で表示される状態です。canonical タグは、ランキングのシグナルをメインの URL に統合することでこれを解決します。
完全に正常なケース（何もしなくてよい）
このステータスの URL のほとんどは対応不要です。代替 URL がインデックス済みの正規ページの正しいバリエーションであれば、このステータスは canonical の設定が正しく機能していることを示しています。 よくある想定どおりのケースは次のとおりです。
- URL パラメータとフィルタ： トラッキングパラメータ、並べ替えオプション、ファセットナビゲーション（例：
?color=blueや?utm_source=...）。 - セッション ID とトラッキングタグ： ページの内容を変えずに固有の識別子を付け加えるパラメータ。
- URL 構造のバリエーション： 末尾のスラッシュ、大文字、HTTPS の正規 URL を指す HTTP 版。
- 印刷用ページと AMP 版： メインのページを正しく canonical に指定している別形式。
- 配信先サイトのコンテンツ： 元の記事を指す canonical タグ付きで、あなたのコンテンツを再掲載している外部サイト。
対象の URL がこれらに当てはまるなら、そのままにしておきましょう。インデックスを無理に登録させたり canonical タグを削除したりすると、重複コンテンツの問題が再発するおそれがあります。
ページの canonical が正しく設定されているか確かめるには、無料の canonical タグチェッカーで確認しましょう。
本当に問題になるケース
このステータスが問題になるのは、インデックスさせたいメインのページが代替ページとして扱われている場合や、canonical タグが誤った URL を指している場合です。次の 5 つのケースを確認しましょう。
1. canonical が誤った URL を指している
テンプレートのミスやプラグインの設定ミスによって、ページがトップページや上位カテゴリーページなど、無関係な URL を canonical に指定してしまうことがあります。重要なページが対象になっていて別の URL を指しているなら、canonical の指定先を修正しましょう。
2. canonical がインデックス不可のページを指している
canonical タグは、ステータスコード 200 を返し、自分自身を canonical に指定している、公開中でインデックス可能な URL を指す必要があります。指定先がリダイレクトする、404 を返す、robots.txt でブロックされている、または noindex タグが付いている場合、Google は別の canonical を選んだり、そのコンテンツをインデックスに登録しなかったりすることがあります。
3. ページネーションやパラメータの URL が誤って統合されている
EC サイトでは、ページ分割されたページや絞り込み表示が、誤って 1 ページ目を canonical に指定していることがよくあります。その結果、奥の商品や一覧がインデックスされなくなります。掲載アイテムが見つけてもらえるように、ページ分割されたページは通常、自己参照 canonical にすべきです。
4. hreflang と canonical の競合
多言語サイトでは、各言語版が自分自身を canonical に指定し、hreflang タグでほかの言語版にリンクする必要があります。すべての言語版の canonical を 1 つのデフォルト言語に向けてしまうと、それらの言語版はインデックスから外れ、hreflang のクラスタも壊れます。
5. 統合の向きが逆になっている本物の重複
canonical タグがメインのページではなく弱いほうの重複ページを指していると、Google は指定されたほうをインデックスに登録します。canonical タグ、内部リンク、サイトマップがすべて同じ正規 URL で一致しているか確認しましょう。
ほかのインデックス登録ステータスについては、「見つかりませんでした（404）」やその他の 4xx エラーによるブロックのガイドをご覧ください。
URL 検査で診断する方法
何かを変更する前に、Google がページをどう見ているかを確認しましょう。
Google が選択した正規 URL とユーザーが指定した正規 URL を比べる
対象の URL を Search Console 上部の URL 検査バーに貼り付け、ページのインデックス登録のセクションを展開します。**「ユーザーが指定した正規 URL」と「Google が選択した正規 URL」**を比べましょう。どちらも意図した正規 URL を指していれば、設定は正しくできています。異なる場合や、指定先が間違っている場合は、タグを修正します。
実際に送っている内容を確認する
canonical は、HTML の <head> か HTTP の Link レスポンスヘッダーで指定できます。無料の canonical タグチェッカーは両方を読み取り、URL が自己参照か、クロスドメインか、canonical がないか、HTML の canonical とヘッダーの canonical が食い違っていないかを教えてくれます。
サイト全体で問題のある URL をすべて見つける
URL を 1 つずつ検査する方法では規模が大きくなると対応できません。SEOcrawl AI の Crawler はサイト全体をクロールし、誤った URL、リダイレクト、エラーページを指す canonical などの問題を、各ページのインデックス可否とあわせて検出します。SEOcrawl AI の Indexation ビューでは、Search Console のカバレッジ状態ごとに URL をまとめ、それぞれの Google が選択した正規 URL と指定した正規 URL を表示します。問題のある URL には、ルールまたは手動でタグを付けられます。AI アシスタントを使っているチームは、SEOcrawl AI の MCP サーバーから同じデータを URL ごとに取得できます。
「適切な canonical タグあり代替ページ」の修正方法
診断結果に合った修正を適用します。目標は常に同じで、canonical タグ、内部リンク、XML サイトマップのすべてを、インデックス可能な 1 つのメイン URL に向けることです。
rel=canonical タグを修正する
上位表示させたいページには、HTML の <head> に自己参照の canonical タグを設定します。
<link rel="canonical" href="https://example.com/your-page" />
ステータスコード 200 を返す絶対 URL を使いましょう。同じページにある 2 つ目の canonical タグは削除します。 矛盾する canonical を宣言しているページでは、Google がそのすべてを無視することがあります。
内部リンクとサイトマップを修正する
内部のシグナルを canonical の構成にそろえます。内部リンクはパラメータ付きの URL や代替版ではなくメインの canonical URL に張り、XML サイトマップにはインデックス可能な正規 URL だけを載せましょう。
WordPress で重複したテンプレートを修正する
WordPress では、canonical タグは通常 SEO プラグインが生成します。Yoast SEO では、投稿を開き、Yoast のメタボックスの Advanced タブで Canonical URL 欄を確認するか、空欄にします。Rank Math と All in One SEO では、Advanced タブの Canonical URL 設定を確認します。欄を空欄にすると、デフォルトの自己参照 canonical に戻ります。
Shopify で修正する
Shopify は canonical タグを自動で生成します。コレクション経由でアクセスした商品 URL（/collections/x/products/y）は、デフォルトでシンプルな商品 URL（/products/y）を canonical に指定します。これは先ほどの想定どおりのケースそのものです。メインのページが誤った URL を canonical に指定している場合は、theme.liquid の canonical タグと、それを書き換える SEO アプリを確認しましょう。
Squarespace と Wix で修正する
Squarespace は canonical タグを自動で管理します。重複ページに対処するには、ページを統合するか、サイト設定の URL Mappings パネルで 301 リダイレクトを追加します。Wix はすべてのページに自己参照 canonical を追加します。複製したページが誤った URL を指している場合は、そのページの SEO 設定を開き、Advanced SEO で canonical を確認しましょう。
重複ページが不要なら 301 リダイレクトを使う
代替 URL がユーザーにとって何の役にも立たないなら、canonical タグだけに頼らず、メインのページへの 301 リダイレクトを設定しましょう。
修正を検証する
canonical を更新したら、Google に再評価を促します。
- Search Console で URL を検査し、公開 URL をテストをクリックして、ユーザーが指定した正規 URL が意図した URL になっていることを確認します。
- インデックス登録をリクエストをクリックして、ページをクロールのキューに追加します。
- 問題の詳細ページで修正を検証を使い、グループ全体を再確認してもらいます。
- メインの canonical URL だけを載せた、更新済みの XML サイトマップを送信します。
代替ページと GSC のほかの重複ステータスの違い
Search Console には、よく似たステータスがいくつかあります。意味はそれぞれ異なり、対応が必要なのは一部だけです。
- 適切な canonical タグあり代替ページ： Google は canonical に同意し、正規 URL をインデックスに登録しています。通常は対応不要です。
- 重複しています。Google により、ユーザーがマークしたページとは異なる正規ページが選択されました： Google は canonical を無視して別の URL を選びました。原因を調べてシグナルをそろえましょう。
- 重複しています。ユーザーにより、正規ページとして選択されたページはありません： ページに canonical がないため、Google が代わりに選びました。canonical を追加して主導権を取り戻しましょう。
- noindex タグによって除外されました： ディレクティブによってページがインデックスから外されています。noindex は重複ページではなく、検索に一切表示させたくないページに使いましょう。
今後防ぐには
サイトを更新するたびに canonical の問題が紛れ込まないようにするには、次の点を守りましょう。
- インデックス可能なすべてのページで、自己参照 canonical をデフォルトにする。
- URL 構造をシンプルに保ち、不要なパラメータのバリエーションを減らす。
- XML サイトマップには、canonical でインデックス可能な URL だけを載せる。
- テンプレートの変更、プラグインの更新、移行のたびにサイトをクロールし、クロール結果を比較して、どの canonical が変わったかを確認する。
**SEO Monitor は、重要なページの canonical タグが変更されたり、壊れたり、消えたりしたときに通知し、**インデックス登録の状態も追跡します。そのため、Search Console より先に誤った canonical に気づけます。
よくある質問
「適切な canonical タグあり代替ページ」はエラーですか？
いいえ。Google が canonical タグに従い、正規版をインデックスに登録したことを示す情報ステータスです。対応が必要なのは、単独でインデックスさせたいページが代替ページとして扱われている場合や、canonical が誤った URL や無効な URL を指している場合だけです。
修正する必要はありますか？
上位表示させたいメインのページが対象になっている場合だけです。対象の URL がトラッキングパラメータ、フィルタ、並べ替えオプション、またはインデックス済みページの別形式であれば、変更は必要ありません。
Google が、設定したものとは別の canonical を選ぶのはなぜですか？
Google は rel=canonical を命令ではなく、強力なヒントとして扱います。 内部リンク、サイトマップ、リダイレクト、hreflang タグが canonical タグとは別の URL を指していると、Google はそちらを選ぶことがあります。これらのシグナルをすべて同じ正規 URL にそろえましょう。
正しい canonical タグはどう設定すればよいですか？
HTML の head に、正規ページの絶対 URL を指す rel=canonical タグを 1 つだけ追加します。WordPress の SEO プラグインでは、意図的に重複ページを統合する場合を除き、canonical の欄を空欄にしてデフォルトの自己参照 canonical を維持しましょう。
URL と canonical URL の違いは何ですか？
URL はページを読み込むあらゆるウェブアドレスです。canonical URL は、メインとして指定したバージョンのことで、複数の URL が同じコンテンツを表示するときに、検索エンジンにインデックスさせて順位を付けてほしい URL です。
このステータスは検索順位に悪影響がありますか？
いいえ。重複 URL を 1 つの canonical に統合すると、シグナルが 1 ページに集まるため、検索順位を守ることにつながります。 トラフィックを失うのは、メインのページが誤って別の URL の代替ページとして扱われた場合だけです。
著者: David Kaufmann
私はこの10年以上、SEOに完全に夢中になって過ごしてきました。正直なところ、他の生き方は考えられません。
私のキャリアが新たな次元に到達したのは、Chess.com でシニアSEOスペシャリストとして働いたときでした。Chess.com はインターネット全体で最も訪問数の多い上位100サイトの1つです。数百万ページ、数十言語、そして最も競争の激しい SERPs の1つという規模で仕事をした経験は、どんなコースや資格でも得られないことを教えてくれました。あの経験は、本当に優れたSEOとは何かという私の視点を一変させ、それ以降に私が築いてきたすべての土台となりました。
その経験から、私は SEO Alive を創業しました。オーガニック成長に本気で取り組むブランドのためのエージェンシーです。私たちは dashboards や月次レポートを売るためにここにいるのではありません。本当に成果を動かす戦略を構築するためにここにいます。クラシカルなSEOの最良の部分と、Generative Engine Optimization (GEO) というエキサイティングな新しい世界を組み合わせ、あなたのブランドが Google の青いリンクだけでなく、ChatGPT、Perplexity、Google AI Overviews が毎日何百万人もの人々に届けている AI 生成の回答の中にも確実に表示されるようにします。
そして、この両方の世界をきちんと扱えるツールが見つからなかったので、自分で作りました。それが SEOcrawl AI です。rankings、テクニカル監査、backlinks モニタリング、crawl ヘルス、そして AI ブランド可視性トラッキングを1つの場所に統合した、エンタープライズ向けのSEOインテリジェンスプラットフォームです。まさに、ずっと存在してほしいと願っていたプラットフォームです。
この著者の他のコンテンツをご覧ください
