結論
「代替ページ（適切な canonical あり）」は、Google が重複URL群から別ページを正規ページと判断し、当該URLを検索結果から除外した状態です。
目標は件数をゼロにすることではなく、意図しない重複を排除し、評価を正しく正規URLへ集約させること。本稿では最新のシグナル方針に沿って、診断→修正→再検証の手順をご紹介します。
このテーマの全体像と実践手順は
・【2026年版】SEO対策とは？基本・始め方・手順を完全ガイド
・【2026年版】Google Search Console 完全ガイド
を参照してください。
- まず理解：2026年の正規化シグナル
- 診断：原因特定の方法
- 修正手順：ケース別の対策
- 再検証フロー：反映の確実性を高める
- 絶対に避けるべきNG集
- AI Overviews時代の注意点
- 実装チェックリスト
- 参考リンク / 関連記事
- あわせて読みたい記事
- よくある質問（FAQ）
まず理解：2026年の正規化シグナル
rel="canonical" は 命令ではなく“強いシグナル”です。Google は複数の手掛かりを総合して正規URLを決めます。
- 明示的シグナル：
<link rel="canonical">、HTTP ヘッダーの canonical。 - 構造的シグナル： 301 リダイレクト、サイトマップへの記載、
hreflang相互参照。 - 内容/その他： コンテンツの重複度、HTTPS 優先、内部リンクの一貫性（アンカー/ナビ/パンくず）。
注意
並べ替え/印刷用など意図的な重複が「代替ページ」になるのは正常です。問題は、 「検索に出したいURLが、別ページに正規化されて消えている」ケース。
診断：原因特定の方法
GSCで「Google選定URL」を特定
- ページ インデックス > 除外 > 代替ページ（適切な canonical タグあり） を開く。
- URL一覧から、本来インデックスすべき重要URLが混じっていないか抽出。
- 該当URLで URL検査 → ページのインデックス → Google が選択した正規 URL を確認。
- 一致している： 設定通り（正常）。
- 一致していない： Google が ユーザー指定の canonical を採用していない（修正が必要）。
クローラー（Screaming Frog等）で一括調査
- Canonical Non-Self-Referencing： 自己参照でないURLを抽出。
- Duplicate / Near Duplicates： 類似度の高いページ群を特定。
- Signal Inconsistency： 「リダイレクト先と canonical 先が違う」「サイトマップのURLと canonical が違う」などの矛盾を洗い出し。
修正手順：ケース別の対策
基本：すべての公開ページで 自己参照 canonical を <head> に出力し、内部リンク/サイトマップ/301 と矛盾させない。
記事詳細がカテゴリ/アーカイブへ正規化される
症状： 詳細 /post/123 が /category/aaa に正規化され「代替」扱い。
対策： テンプレの <head> で自己参照 canonical に修正。本文に固有情報（比較表、手順、検証ログ）を追加。
例：
<link rel="canonical" href="https://○○.com/post/123/" />ホスト名のゆらぎ（www / HTTPS / 末尾スラッシュ）
対策： サーバ設定で301リダイレクトを正規ホストへ統一し、すべてのページの canonical を https+正規ホストに統一。内部リンクも正規URLへ揃える。
パラメータ・絞り込み
症状： ?sort=price や ?color=red が大量に「代替」化。
対策： これらのバリエーションから基準URLへ canonical。
計測用の utm_ などは内部リンクで付与しない／サーバ側で除去や 301 で正規URLへ統一。
注： 旧「GSCのURLパラメータツール」は廃止済み。サイト側の設計でコントロールします。
ページネーション（2ページ目以降）
対策： /list?page=2 など各ページは自己参照 canonical。1ページ目に向けない。内部リンク/サイトマップで2ページ目以降の発見性も担保。
hreflang と canonical の整合
- 各言語版は自己参照 canonical。
hreflangは同一コンテンツの言語版同士を相互参照（x-default含む）。別言語に canonical を向けない。
クロスドメイン（転載/ミラー）
対策： 転載先から元記事URLへ rel="canonical" を設定。困難な場合は noindex や短縮版で差別化。
Soft 404 / 薄い重複
対策： 主要クエリに対する固有の解決策・手順・事例・画像などを追加、もしくは統合して1本化。1本化して情報量の増加をするのがおすすめです（内部リンクなどの状況によっても異なります。）
再検証フロー：反映の確実性を高める
- URL検査（公開URLをテスト）：修正が HTMLソース（SSR結果）に出力されているか確認。
※ライブテストは選定canonicalの即時更新までは行いません。ソース確認用途として必須。 - サイトマップ再送信：正規URLのみを列挙して送信、クロールを促進。
- 内部リンクの正規化：グロナビ/パンくず/関連記事が直接正規URLを指すよう再点検（リダイレクトを挟まない）。
- GSCで再確認（1〜2週後）：代替ページの件数が想定通り減少、Duplicate… not selected as canonical の新規発生がないことを確認。
絶対に避けるべきNG集
- シグナルの矛盾： A→B に 301 しているのに、B の canonical が A。
- noindex と canonical の併用： 評価を集約したいなら
noindexを外し、canonicalに一本化。 - JSでの動的書き換え： レンダリング遅延や矛盾のリスク。HTMLの <head> に出力を原則に。
- <body> 内に canonical： 無効扱い。必ず <head> に配置。
AI Overviews時代の注意点
注： Google が AI Overviews の引用選定に canonical を直接使うと公式に明言しているわけではありません。
ただし、正規URLの一貫性は検索機能全般で“どのURLが代表表示されるか”の安定に寄与します。正規化の整備は AIO 時代にも有効です。
実装チェックリスト
実装する際は以下チェックリストを参考に、手順に間違いがないか確認しながら進めていただくとわかりやすいかと思います。
- [ ] すべての公開ページで 自己参照 canonical を <head> に出力
- [ ] 301 で HTTPS/正規ホスト へ統一（www・末尾スラ・大文字小文字）
- [ ] サイトマップは正規URLのみを列挙
- [ ] グロナビ/パンくず/関連記事の内部リンクが正規URLを直接指す
- [ ] パラメータ付与を内部リンクで行わない（計測はサーバ側で除去 or 自動 301）
- [ ] hreflang は相互参照＋各言語は自己参照 canonical
参考リンク / 関連記事
- Canonical のベストプラクティス（方法の強弱、JSの注意点 ほか）
- ページインデックス（除外ステータスの見方）
- rel=prev/next について（非対応方針）
- サイトマップのベストプラクティス
※上記はGoogle検索セントラルの参考リンクです。
あわせて読みたい記事
Search Console全体の見方や、SEO改善でどの指標を優先して確認すべきかを整理したい方は、以下の完全ガイドもご覧ください。
〖2026年版〗Google Search Console 完全ガイド｜SEO改善に使う指標・見方・実務手順
関連記事：
Canonicalタグとは？ SEOへの影響と正しい使い方を徹底解説
よくある質問（FAQ）
- Q. 「代替ページ（適切な canonical あり）」はゼロにすべき？
- A. 目的はゼロ化ではなく、意図しない重複を排除し評価を正規URLに集約することです。並べ替えや印刷用など意図的な重複が代替扱いになるのは正常です。
- Q. 「Google が選択した正規URL」と「ユーザー指定のcanonical」が違う時の優先対応は？
- A. 優先順は①内部リンクの正規化（ナビ/パンくず/関連記事が正規URLを直リンク）→②自己参照canonicalの徹底→③301リダイレクト統一（www・HTTPS・末尾スラ等）→④サイトマップを正規URLのみに、の順で整合を取ります。
- Q. noindex と canonical を同時に使ってもいい？
- A. 推奨されません。評価を統合したい場合はnoindexを外し、canonicalに一本化します。noindexは検索から完全除外の指示です。
- Q. ページネーション（?page=2 以降）の canonical は？
- A. 各ページを自己参照canonicalにします。1ページ目へ向けると不要な正規化が起こります。発見性は内部リンク/サイトマップで担保してください。
- Q. utm などパラメータ付きURLが量産されます。どう対処？
- A. 内部リンクではパラメータを付与しない設計にし、必要な計測はサーバ側で除去や301で正規URLへ統一。バリエーションからは基準URLへcanonicalを付与します。
- Q. hreflang と canonical の正しい関係は？
- A. 各言語ページは自己参照canonical。hreflangは同一コンテンツの言語版同士を相互参照し、別言語へcanonicalは向けません（x-default含む）。
- Q. URL検査の「公開URLをテスト」で何が分かる？
- A. HTMLソースに正しく出力されているか（SSR結果）とレンダリングの概況を確認できます。選定canonicalの即時更新は行われませんが、修正の確認には必須です。
- Q. 反映までの目安とやるべき操作は？
- A. 数時間〜数週間。修正後はインデックス登録をリクエストし、正規URLのみのサイトマップを再送信、さらに内部リンクを正規URLに統一してクロールを促進します。
- Q. サイトマップに「代替ページ」は入れても良い？
- A. 推奨しません。サイトマップは正規URLのみを列挙してください。弱めのシグナルですが、整合が取れているほど判断が安定します。
- Q. SPA/JSレンダリングのサイトで canonical はどう置く？
- A. SSR/静的生成で <head> に出力するのが基本です。クライアントJSで後から書き換える設計は、遅延や矛盾で判断が不安定になります。
