結論から言うと、canonicalタグは「同じ、または非常によく似た内容を持つ複数URLのうち、検索結果で代表にしてほしいURL」を伝えるために使います。ただし、設定したURLが必ず採用される命令ではありません。ページ内容、内部リンク、リダイレクト、サイトマップ、HTTPS、hreflangなどが矛盾していると、Googleが別のURLをcanonicalとして選ぶことがあります。
URLを残すならcanonical、廃止するならリダイレクト、検索に出さないならnoindex
最初に「そのURLをユーザーが今後も利用するか」を決めると、手段を選びやすくなります。canonicalは重複ページを残しながら代表候補を示す方法であり、URL移転や検索除外の代替ではありません。
基本情報・用語の早見表
| 正式な記述 | <link rel="canonical" href="正規URL"> |
|---|---|
| 主な目的 | 重複・類似URLの代表候補を示し、検索シグナルや計測を集約しやすくする |
| 設置場所 | HTML文書の<head>内。PDFなどHTML以外はHTTPヘッダーも利用可能 |
| URL形式 | 誤解を避けるため、原則としてHTTPSから始まる完全な絶対URL |
| Googleでの扱い | 強いシグナルだが命令ではない。別URLが選ばれることもある |
| 推奨確認方法 | HTMLソース、HTTPレスポンス、Search ConsoleのURL検査 |
| 公式情報確認日 | 2026年7月29日 |
canonicalタグとは、重複URLの代表候補を伝えるlink要素
canonical（カノニカル）は「正規の」「標準の」という意味です。SEOでは、同じ内容または非常によく似た内容へ複数のURLからアクセスできるとき、検索エンジンに代表として扱ってほしいURLを伝える仕組みを指します。
一般には「canonicalタグ」と呼ばれますが、HTML上は<link>要素です。重複ページ側だけでなく、代表ページ自身にも自分自身を指す自己参照canonicalを設定すると、パラメータ付きURLや意図しないURL表記が発生した際にも方針を明示できます。
内容は同じだがURLだけが増える
- 広告計測のUTMパラメータ
- 並び替え・フィルターURL
- 印刷用ページや共有用URL
- 商品バリエーションの一部
- セッションIDや表示形式によるURL差分
URLの役割そのものが違う
- 旧URLを完全に廃止する移転
- 検索結果に出したくない管理ページ
- 内容や検索意図が大きく異なるページ
- アクセスを止めたい機密ページ
- 存在しないページや削除済みページ
重複URLは、それだけでペナルティになるわけではない
ECサイトのパラメータや複数端末向けURLなど、重複は通常のサイト運用でも発生します。問題は、検索エンジンと運用担当者が代表URLを判断しにくくなることです。canonicalを含む正規化設計は、クロール・評価・レポートを一つのURLへ揃えやすくします。
canonical・301・noindex・robots.txt・サイトマップの違い
正規化で最も多い失敗は、目的の異なる手段を同じものとして扱うことです。まず「URLを残すか」「ユーザーを転送するか」「検索から外すか」「クロールを制御するか」を決めてください。
| 手段 | 主な役割 | ユーザーの表示 | 向いている場面 | 注意点 |
|---|---|---|---|---|
| rel="canonical" | 強いシグナル 代表URLの候補を示す |
元のURLをそのまま表示 | 重複・類似ページを残す | Googleが別URLを選ぶ場合がある |
| 301 / 308 | 恒久転送 旧URLから新URLへ移す |
新URLへ自動移動 | URL変更、統合、サイト移転 | チェーンやループを避け、最終URLへ直接転送 |
| noindex | 検索除外 検索結果に掲載しない |
ページは通常表示 | 検索価値のない完了画面、内部検索など | Googleが読めるようrobots.txtで遮断しない |
| robots.txt | クロール制御 取得を許可・制限する |
直接アクセスは可能 | 不要なクロール負荷を抑える | 正規化や確実な検索除外には使わない |
| XMLサイトマップ | 弱いシグナル 正規URLを発見しやすくする |
表示に影響しない | 正規URL一覧を検索エンジンへ送る | canonicalや内部リンクと同じURLだけを載せる |
迷ったときは「そのURLを今後も使うか」で判断する
-
旧URLを廃止し、訪問者も新URLへ移したい
301または308の恒久リダイレクトを使います。canonicalだけではユーザーは移動しません。
-
URLは残すが、内容は代表ページと同じ・非常に似ている
canonicalを使い、内部リンク・サイトマップ・hreflangも代表URLへ揃えます。
-
ページは利用するが、検索結果には出したくない
noindexを検討します。検索エンジンがnoindexを読めるよう、robots.txtではブロックしません。
-
内容も検索意図も異なる独立ページ
原則として自己参照canonicalにします。関連性だけを理由に別ページへcanonicalしないでください。
canonicalタグの正しい書き方と実装例
HTMLページでは、<head>内へlink要素を1つ出力します。正規URLは、実際に公開されているHTTPSの絶対URLを指定するのが安全です。
基本形：代表ページ自身に自己参照canonicalを置く
<head>
<link
rel="canonical"
href="https://example.com/products/shoes/"
>
</head>重複ページ：代表URLを指定する
https://example.com/products/shoes/?utm_source=newsletterのような計測用URLが同じ本文を返す場合、重複ページ側でもパラメータなしの代表URLを指定します。
<!-- /products/shoes/?utm_source=newsletter のhead内 -->
<link
rel="canonical"
href="https://example.com/products/shoes/"
>HTML以外：PDFはHTTP Linkヘッダーでも指定できる
PDFやダウンロード資料など、HTMLの<head>を持たないファイルでは、HTTPレスポンスのLinkヘッダーを利用できます。
Link: <https://example.com/guides/canonical/>; rel="canonical"実装前に守る6つの原則
head内に1つだけ置く
body内のcanonicalは無視され得ます。CMS、テーマ、SEOプラグインの重複出力も確認します。
完全な絶対URLを使う
プロトコル、ホスト名、パスを含めます。http/https、www、末尾スラッシュの方針も統一します。
200で取得できる最終URLを指す
404、ソフト404、ログイン必須、noindex、リダイレクト途中のURLをcanonical先にしないでください。
同じ、または非常によく似た内容だけをまとめる
検索意図や主要内容が異なるページを無理に一つへ寄せると、指定が採用されにくくなります。
自己参照canonicalを基本にする
検索対象にしたいページ自身にも、そのページの正規URLを明示します。
JavaScriptで後から書き換えない
可能な限りサーバーが返すHTMLソースへ直接出力し、実行後DOMと矛盾させないようにします。
https://example.com/page/#sectionの#section部分は正規URLの区別に使わず、フラグメントなしのURLを指定してください。Googleがcanonicalを選ぶシグナルとSEOへの影響
Googleはcanonical要素だけでなく、複数のシグナルを組み合わせて代表URLを判断します。公式ドキュメントでは、リダイレクトとrel="canonical"は強いシグナル、サイトマップへの掲載は弱いシグナルとして整理されています。
恒久リダイレクト
廃止したURLから最終URLへ直接転送します。訪問者とクローラーの両方が移動します。
rel="canonical"
ページを残したまま、代表URLの候補を明示します。採用を保証する命令ではありません。
XMLサイトマップ
正規URLの発見を助けますが、単独で重複URLを統合する方法ではありません。
複数のシグナルは、同じURLへ揃えるほど明確になる
- 内部リンクはパラメータなしの正規URLへ向ける
- XMLサイトマップには正規URLだけを掲載する
- HTTPからHTTPSへ移行済みならHTTPSを指定する
- リダイレクトはcanonical先と同じ最終URLへ着地させる
- 多言語ページでは、各言語の自己参照canonicalとhreflangを整合させる
- OGP、構造化データ、パンくず、共有リンクも正規URLに統一する
canonicalによって期待できること
- 重複URLに分散し得る検索シグナルを集約しやすくする
- 検索結果に表示する代表URLを伝える
- Search Consoleの集計対象を整理しやすくする
- 重複URLのクロールを減らし、重要ページへ集中させやすくする
- 設定したURLが必ず検索結果に表示される
- canonicalだけで順位が上がる
- 低品質ページが高品質になる
- クロールやインデックスが直ちに更新される
ケース別に見るcanonicalの設計
一律に「すべて同じURLへcanonical」とするのではなく、ページが持つ検索価値とユーザー価値で判断します。特にEC、ページネーション、多言語サイトでは誤設定の影響が大きくなります。
UTMパラメータ付きURL
?utm_source=などで本文が変わらないなら、パラメータなしURLへcanonicalします。内部リンクも可能な限り正規URLを使います。
価格順・新着順のURL
商品集合が同じで順序だけが変わる場合、基本のカテゴリURLへまとめる選択肢があります。ただし、並び替えページ自体に独自の検索価値があるなら別設計です。
色・サイズ・ブランドのフィルター
検索需要がなく組み合わせが無限に増えるなら、canonicalだけでなく内部リンクやクロール制御も検討します。需要のある条件ページは独立URLとして最適化する場合があります。
色違い・容量違いの商品
差が小さく共通商品ページで十分なら代表商品へまとめられます。画像、価格、在庫、検索意図が明確に異なるバリエーションは、個別URLを自己参照canonicalにする方が自然です。
ページネーション
2ページ目以降をすべて1ページ目へcanonicalしないでください。/category/?page=2には、その2ページ目自身のcanonicalを設定します。
日本語・英語・中国語ページ
各言語ページは原則として自己参照canonicalにし、対応する言語URLをhreflangで相互指定します。日本語ページから英語ページへcanonicalすると、日本語版が検索対象から外れやすくなります。
HTML記事とPDF版
HTMLを代表にしたいなら、PDFのHTTP LinkヘッダーからHTML記事をcanonicalに指定できます。PDFも独立検索させたい場合は、無理に統合しません。
旧ドメインから新ドメイン
旧URLを残す理由がなければ、旧URLから対応する新URLへ301または308で直接転送します。新URLは自己参照canonicalにし、サイトマップと内部リンクも更新します。
WordPressでcanonicalを設定・確認する方法
WordPress本体には、個別投稿や固定ページなどの単一ページでcanonicalを出力する仕組みがあります。ただし、テーマやSEOプラグインも同じタグを出力すると重複するため、「どの機能がcanonicalを生成しているか」を確認してください。
まずHTMLソースで1つだけ出ているか確認する
-
対象ページを開く
ブラウザで投稿・固定ページ・カテゴリ・タグ・カスタム投稿を個別に確認します。
-
ページのソースを表示する
開発者ツールのElementsではなく、まずサーバーが返した「ページのソース」で
rel="canonical"を検索します。 -
件数とURLを確認する
1ページにつき1つで、HTTPS、ドメイン、末尾スラッシュ、パスが実際の正規URLと一致するかを確認します。
-
重複出力の発生源を止める
テーマ、SEOプラグイン、独自コードのうち一つに出力を集約し、二重・三重出力を解消します。
SEOプラグインを使う場合の注意
- 通常の記事では自動生成された自己参照canonicalを不用意に変更しない
- カテゴリ、タグ、著者、日付アーカイブの扱いをサイト方針に合わせる
- カスタム投稿タイプやカスタムタクソノミーも確認する
- ステージングURLや旧ドメインが残っていないか確認する
- HTTP、www有無、末尾スラッシュがWordPress設定と一致しているか確認する
- 多言語プラグインではcanonicalとhreflangの組み合わせを実ページで確認する
canonical実装後の確認方法
実装後は「自分が指定したURL」と「Googleが選択したURL」を分けて確認します。タグが正しく見えていても、内容や内部リンクが矛盾していればGoogleが別URLを選ぶことがあります。
1. HTMLソースを確認する
ブラウザの「ページのソースを表示」でrel="canonical"を検索し、head内に1つだけ存在するか確認します。JavaScript実行後のDOMだけでなく、最初に返されたHTMLを見るのがポイントです。
2. curlでHTTPレスポンスを確認する
# GETでHTMLとレスポンスヘッダーを別々に保存
curl -sS -L --max-redirs 5 -D /tmp/canonical-headers.txt \
-o /tmp/canonical-page.html "https://example.com/page/"
# PDFもGETの応答ヘッダーを確認（本文は保存しない）
curl -sS -L --max-redirs 5 -D - -o /dev/null \
"https://example.com/file.pdf"3. Search ConsoleのURL検査を使う
URL検査では、インデックス登録済みデータに表示される「ユーザーが指定した正規URL」と「Googleが選択した正規URL」を比較します。両者が異なる場合は、次の項目を同じURLへ揃えてください。
| 確認項目 | 正常な状態 | 差がある場合の確認 |
|---|---|---|
| ページ内容 | canonical先と同じ、または非常によく似ている | タイトル、本文、主画像、構造化データ、検索意図を比較 |
| HTTP状態 | canonical先が200で直接表示される | リダイレクト、404、5xx、認証、ソフト404を確認 |
| 内部リンク | 正規URLへ一貫してリンク | ナビ、パンくず、関連記事、言語切替を確認 |
| サイトマップ | 正規URLだけを掲載 | 重複URLや旧URLを削除 |
| インデックス指示 | 正規URLがindex可能 | noindex、robots.txt、X-Robots-Tagを確認 |
| 言語・地域 | canonicalとhreflangが整合 | 自己参照、相互参照、言語コードを確認 |
4. 修正後は再クロールと再評価を待つ
canonicalの変更は即時反映ではありません。重要URLはURL検査からインデックス登録をリクエストできますが、すべての重複URLへ繰り返し送る必要はありません。内部リンクとサイトマップを直したうえで、Googleの再クロールとクラスタ再評価を待ちます。
「指定したURL」と「Googleが選んだURL」を照合する
例として /guide/?ref=mail を /guide/ に正規化する場合、設定画面・公開レスポンス・インデックスの3つを分けて記録します。
| 確認段階 | 合格の目安 |
|---|---|
| 公開HTMLとヘッダー | canonicalが複数の異なるURLを指していない。HTTPのLinkヘッダーも確認する。 |
| 代表URL | /guide/ が200で取得でき、意図しないnoindexや別URLへの転送がない。 |
| サイト内の指定 | 本文リンクとサイトマップが /guide/ を使い、重複URLを代表扱いしていない。 |
| URL検査 | ユーザー指定とGoogle選択のcanonical、最終クロール日を記録。ライブテストだけで選択結果を断定しない。 |
Googleのトラブルシューティング資料は、内容を修正しても最大2週間ほど重複グループに残る場合があると説明しています。これは全URLの反映期限の保証ではありません。日々指定先を変えず、再クロールと本文の違いを確認します。
保存したHTMLのhead内と各応答のLinkヘッダーを確認します。単純な文字列検索では属性順・引用符・JavaScriptによる差分を見落とすため、ブラウザーのDOMとURL検査も照合してください。
canonicalでよくある失敗と修正方法
body内へ置いている
canonicalはhead内へ移します。テンプレートの閉じタグやHTML崩れも検証してください。
1ページに複数のcanonicalがある
CMS、テーマ、プラグイン、HTTPヘッダーの出力元を調べ、代表指定を一つへ統一します。
canonical先が404・noindex・リダイレクト
200で直接取得でき、index可能な最終URLへ修正します。
内容が異なるページへ向けている
検索意図が独立しているなら自己参照canonicalに戻し、ページ品質を個別に改善します。
内部リンクやサイトマップが別URLを指す
canonical、リダイレクト、内部リンク、サイトマップを同じ正規URLへ揃えます。
robots.txtで重複ページを遮断する
Googleがcanonicalやnoindexを読めなくなります。正規化目的ではクロール可能な状態を基本にします。
ページネーションを全部1ページ目へ向ける
各ページには固有コンテンツがあるため、2ページ目以降も原則として自己参照canonicalにします。
JavaScriptで別URLへ上書きする
初期HTMLとレンダリング後DOMを一致させ、サーバー側テンプレートで出力します。
多言語ページを一言語へ統合する
翻訳ページは各言語で自己参照し、対応関係はhreflangで伝えます。
クエリ付きURLを一律noindexにする
検索価値のある絞り込みページまで消える恐れがあります。パラメータの意味ごとに分類して判断します。
canonicalタグに関するよくある質問
canonicalを設定すれば、必ず指定URLが検索結果に出ますか？
いいえ。canonicalは強いシグナルですが命令ではありません。Googleはページ内容、リダイレクト、内部リンク、サイトマップ、HTTPSなどを総合し、別URLを代表として選ぶことがあります。
すべてのページに自己参照canonicalは必要ですか？
Googleは必須とはしていませんが、検索対象にするページへ自己参照canonicalを設定すると、パラメータやURL表記の揺れが発生した際にも意図を明示しやすくなります。
canonicalとnoindexを同じページに設定してもよいですか？
目的が矛盾しやすいため、通常は避けます。canonicalは代表URLへの統合、noindexは当該ページの検索除外です。どちらを優先したいかを決め、明確な一つの方針にします。
相対URLでもcanonicalは機能しますか？
解決可能な相対URLでも処理される場合はありますが、Googleは絶対URLの使用を推奨しています。ステージングドメインや基準URLの誤りを避けるため、完全なHTTPS URLを指定するのが安全です。
canonical先に301リダイレクトされるURLを指定してよいですか？
避けてください。リダイレクト途中ではなく、最終的に200で表示される代表URLを直接指定します。余分な転送をなくすことで、シグナルとクロール経路が明確になります。
ページネーションの2ページ目は1ページ目へcanonicalしますか？
しません。各ページには異なる商品・記事が含まれるため、2ページ目には2ページ目自身、3ページ目には3ページ目自身のcanonicalを設定します。
Search Consoleで「Googleが選択した正規URL」が違う場合はどうしますか？
canonical先の内容、HTTPステータス、内部リンク、サイトマップ、リダイレクト、noindex、hreflangを確認します。修正後は再クロールと再評価を待ち、URL検査で再確認してください。
canonicalはクロールバジェットの改善に使えますか？
重複URLの代表を理解させる助けにはなりますが、無限に増えるフィルターURLをcanonicalだけで制御するのは不十分です。URL設計、内部リンク、パラメータ生成、robots.txtなどを含めてクロール経路を整理します。
参照した公式情報
以下は本記事の基礎説明の参考資料です。主要項目の再確認日は2026年9月16日。確認対象と参照先は末尾の補足に記載しています。過去の撮影日・測定日は各資料の説明を参照してください。
まとめ：canonicalはタグ単体ではなく、URL設計全体で揃える
canonicalは、重複または非常によく似たページを残しながら、代表URLの候補を検索エンジンへ伝える重要な仕組みです。一方で、旧URLを廃止するなら恒久リダイレクト、検索結果から外すならnoindexを使います。
- 検索対象にするページは自己参照canonicalを基本にする
- head内へ1つだけ、HTTPSの絶対URLで出力する
- canonical先は200で取得でき、index可能な最終URLにする
- 内部リンク、サイトマップ、リダイレクト、hreflangを同じ方針へ揃える
- ページネーションや多言語ページを一律に1ページへまとめない
- Search Consoleで「指定したURL」と「Googleが選んだURL」を比較する
まずはサイト内の重複URLを「残す」「廃止する」「検索から外す」「独立ページとして育てる」の4種類に分け、その後にcanonicalを実装してください。
