canonicalタグとは? — URL正規化のためのHTML要素
canonicalタグの定義と基本の書き方
canonicalタグ(正式名称:rel="canonical")とは、同一または類似のコンテンツが複数URLで存在する場合に、検索エンジンへ「このURLを正規版として扱ってください」と指定するHTML要素です。HTMLの<head>セクション内に、次のように1行記述します。
<link rel="canonical" href="https://example.com/page/" />
この1行が、「このページの正規URLは https://example.com/page/ です」というシグナルをGoogleに伝えます。canonicalタグの目的は、重複・類似ページに分散しがちな評価を、指定した1つのURLへ集約することにあります。
URL正規化とは — 同じ内容に複数URLが生まれる仕組み
URL正規化(URL Canonicalization)とは、同じコンテンツにアクセスできる複数URLの中から、インデックスすべき1つのURLを決定するプロセスです。次のURLは、いずれも同じページを表示してしまう可能性があります。
https://example.com/page
https://example.com/page/
http://example.com/page
https://www.example.com/page
https://example.com/page?ref=twitter
https://example.com/page?utm_source=google
人間には「どれも同じページ」と分かりますが、検索エンジンは原則としてURL単位でページを認識します。これらが別々のページとしてインデックスされると、後述するSEO上の問題が発生します。URL正規化は、テクニカルSEOの基礎の一つです。サイト全体の技術的な健全性を体系的に点検したい場合は、テクニカルSEOのチェックリストもあわせて確認してください。
Googleがcanonicalタグを導入した背景
Googleがrel="canonical"のサポートを開始したのは2009年です。当時のWebにはECサイトの商品ページ、パラメータ付きURL、httpとhttpsの混在など、意図せず重複URLが生成されるケースが非常に多く存在しました。GoogleのMatt Cutts氏が「ウェブの25〜30%は重複コンテンツだ」と述べたことは広く知られています。サイト運営者が自ら正規URLを宣言できる仕組みとして、canonicalタグが用意されたわけです。
canonicalタグが必要な理由 — 重複コンテンツの主なリスク
重複コンテンツがSEOに与える影響
URL正規化を放置すると、次のようなリスクが生じます。影響度が高い順に把握しておきましょう。
| リスク | 説明 | 影響度 |
|---|---|---|
| リンク評価(PageRank)の分散 | 被リンクの評価が複数URLに分かれてしまう | 大 |
| 検索順位の低下 | 評価が分散した結果、本来の順位を取りきれない | 大 |
| クロールバジェットの浪費 | 同じ内容を複数URLで無駄にクロールされる | 中(大規模サイトで顕著) |
| インデックスの混乱 | 意図しないURLが正規版として選ばれてしまう | 中 |
リンク評価(PageRank)の分散が最も痛い
最も深刻なのはリンク評価の分散です。あるページに10本の外部リンクが集まっているとします。正規化ができていないと、その評価がURLごとに分かれてしまいます。
| 状態 | 評価の分配 | SEOインパクト |
|---|---|---|
| canonicalで正規化済み | 10本分が1つのURLに集中 | 評価を最大限に活かせる |
| 未設定で2URLに分散 | おおよそ5本ずつに分かれる | 評価が目減りする |
| 未設定で3URLに分散 | さらに細切れになる | 1つあたりの評価が大きく低下 |
被リンクをどう集約するかは外部SEOの成果を左右します。リンクそのものの考え方は被リンクの基礎と良質なリンクの特徴で解説しています。canonicalタグは、せっかく集めた評価を正規URLへ束ねるための「受け皿」だと考えてください。
クロールバジェットとインデックス品質への影響
数万ページ規模の大規模サイトでは、クロールバジェット——Googleがサイトに割く「クロールの予算」——への影響も無視できません。重複URLが大量にあると、本来クロールしてほしい重要ページが後回しにされます。さらに近年は、単なる技術問題にとどまらない論点もあります。Googleは、サイト品質への懸念が強いとクロールもインデックスも絞る挙動があると説明しており、この点は「クロール済み-未インデックス」とサイト品質・AI生成コンテンツの関係やサイト品質と未インデックスページの関係で詳しく取り上げています。重複URLの整理は、こうした「無駄なページ」を減らし、価値あるページへクロールを集中させる下地づくりにもなります。
canonicalタグを設定すべき5つのケース
実務で正規化が必要になる典型的なケースを、具体的なURL例とあわせて整理します。
ケース1:wwwあり/なしの統一
https://example.com/page
https://www.example.com/page
同じ内容がwwwありとなしの両方で開ける場合、どちらを正規版にするか決めて統一します。canonicalタグでの指定に加え、サーバー側で301リダイレクトをかけるのが確実です。Apacheであれば、.htaccessに次のように記述します。
# wwwありへのアクセスをwwwなしへ301リダイレクト(Apache)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
リダイレクトの種類や設定方法を体系的に知りたい場合は、301・302リダイレクトの違いと設定方法を参照してください。
ケース2:http/httpsの混在
http://example.com/page
https://example.com/page
SSL化が完了していても、httpのURLがインデックスに残ることがあります。httpsへの301リダイレクトを基本としつつ、canonicalタグもhttps側を正規URLとして指定しておきましょう。
ケース3:パラメータ付きURL
https://example.com/page
https://example.com/page?sort=price
https://example.com/page?color=red&size=L
ECサイトの絞り込み・並べ替えや、トラッキング用パラメータ(?utm_source= など)で生成されるURLは、内容が実質的に同じでも別URLとして扱われます。パラメータなしのURLを正規版とするcanonical設定が特に効いてくる場面です。
ケース4:末尾スラッシュの有無
https://example.com/page
https://example.com/page/
末尾スラッシュ(trailing slash)の有無でも、別URLとして認識される場合があります。サイト全体でどちらかに統一し、canonicalとサイトマップの表記もそろえます。
ケース5:モバイル用の別URL構成
| 構成タイプ | canonical設定 | 理由 |
|---|---|---|
| レスポンシブデザイン | 不要 | PC・モバイルでURLが同一のため |
| 動的配信(同一URL・異なるHTML) | 不要 | URLが同一のため |
| 別URL構成(m.example.com 等) | 必要 | モバイルページからPCページへcanonicalを指定 |
Googleはレスポンシブデザインを推奨しており、この構成なら正規化の悩みはほぼ発生しません。別URL構成の場合は、モバイル側からPC側へcanonical、PC側からモバイル側へalternateを相互に設定します。なお、記事一覧などのページ送りは別テーマです。各ページに自己参照canonicalを設定し、無理に1ページ目へ集約しないのが現在の推奨で、詳細はページネーションのSEOに強い実装方法で解説しています。
canonicalタグの正しい書き方 — 実装パターン別コード例
基本のHTML記述
canonicalタグは必ず<head>セクション内に記述します。<body>内に置くと無視されるため注意してください。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>ページタイトル</title>
<link rel="canonical" href="https://example.com/page/" />
</head>
<body>
<!-- ページのコンテンツ -->
</body>
</html>
hrefには必ず絶対URL(https://から始まる完全なURL)を指定します。相対URLはトラブルのもとです。head内の実装は、その他のSEO関連タグとあわせてSEO対策に必須のHTMLタグ一覧でも整理しています。
WordPressでの設定方法
WordPressでは、SEOプラグインを使うのが最も手軽で保守性も高い方法です。
| 方法 | 難易度 | 推奨度 | 特徴 |
|---|---|---|---|
| Yoast SEO | 低 | 高 | 投稿・固定ページごとに管理画面から設定可能 |
| All in One SEO | 低 | 高 | 多機能。自己参照canonicalを自動出力 |
| Rank Math | 低 | 高 | 無料でも高機能 |
| functions.phpに直接記述 | 高 | 低 | プラグイン不要だが保守コストが高い |
| テーマのheader.phpを編集 | 中 | 低 | テーマ更新時に上書きされるリスク |
主要なSEOプラグインは、初期状態で全ページに自己参照canonicalを自動出力します。まずはこの自動出力を活かし、個別に上書きしたいページだけ、各編集画面の「詳細設定(Advanced)」にある正規URL欄で指定する運用が現実的です。
HTTPヘッダーでの指定(PDFなどHTML以外)
PDFや画像など<head>を持たないコンテンツには、HTTPレスポンスヘッダーでcanonicalを指定できます。
Link: <https://example.com/document.pdf>; rel="canonical"
サイトマップは正規URLだけを載せる
XMLサイトマップ(sitemap.xml)に記載するURLは、canonicalで指定した正規URLと一致させます。非正規URLをサイトマップに載せると、Googleへ矛盾したシグナルを送ることになります。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/page/</loc>
<lastmod>2026-03-01</lastmod>
</url>
</urlset>
サイトマップの作り方や運用はXMLサイトマップの作成方法とSEO効果で詳しく解説しています。canonicalとサイトマップ、内部リンク、リダイレクトの向き先——これらの正規URLをすべてそろえることが、正規化を確実にするコツです。
canonicalと他の手段の使い分け — noindex・301リダイレクト
canonical と noindex の違い
canonicalとnoindexは、どちらもインデックスに関わりますが目的が異なります。混同すると評価を失うため、違いを押さえておきましょう。
| 比較項目 | canonical | noindex |
|---|---|---|
| 目的 | 正規URLを指定して評価を集約する | ページをインデックスから除外する |
| リンク評価 | 正規URLへ集約される | 集約されない |
| 使用場面 | 類似・重複コンテンツの正規化 | 検索結果に出したくない低品質・不要ページ |
| 実装 | <link rel=”canonical”> | <meta name=”robots” content=”noindex”> |
判断の目安はシンプルです。内容が同一・類似で評価を束ねたいなら canonical、そのページ自体を検索結果から消したいなら noindex を使います。A/Bテスト中のバリエーションのように「中身はほぼ同じで片方を正規にしたい」ケースは canonical が適切です。
注意したいのは、同じページにnoindexとcanonicalを同時に設定してはいけない点です。Googleに矛盾した指示を送ることになります。
<!-- NG:矛盾した指示(noindexとcanonicalの併用) -->
<meta name="robots" content="noindex">
<link rel="canonical" href="https://example.com/other-page/" />
canonical と 301リダイレクトの違い
「重複URLを整理する」という目的は同じでも、canonicalと301リダイレクトは挙動が根本的に異なります。
| 項目 | canonical | 301リダイレクト |
|---|---|---|
| ユーザーの遷移 | 元のURLに留まる | 正規URLへ転送される |
| 複数URLへのアクセス | 両方アクセスできる | 元URLは正規URLへ飛ばされる |
| 実装場所 | HTMLの<head>内 | サーバー設定(.htaccess等) |
| 効力 | ヒント(無視される場合あり) | 強制的 |
使い分けの原則は、「旧URLを完全に統合したい・アクセスさせたくない」なら301リダイレクト、「両方のURLを残しつつ評価だけ寄せたい」ならcanonical、です。wwwやhttpsの統一のように基盤に関わるものは301、パラメータ違いのように元URLも表示させたいものはcanonical、と考えると整理しやすくなります。両者の詳しい違いと設定手順はリダイレクトとは?301・302の違いから設定方法までで解説しています。
canonicalタグの確認方法
ブラウザのデベロッパーツールで確認
最も手軽なのは、ブラウザのデベロッパーツール(F12)で個別ページのcanonicalを確認する方法です。
- 確認したいページを開き、F12でデベロッパーツールを起動する
- 「Elements」タブで<head>内を表示する
- Ctrl+Fで「canonical」を検索する
- <link rel="canonical" href="…"> の記述と、hrefが意図した正規URLかを確認する
Google Search ConsoleのURL検査で確認
Search Consoleの「URL検査」ツールでは、自分が指定した正規URLと、Googleが実際に選んだ正規URLの両方を確認できます。canonicalはあくまでヒントのため、この2つが食い違うことがあります。
| 確認項目 | 確認場所 | チェックポイント |
|---|---|---|
| ユーザーが指定した正規URL | URL検査 →「ページのインデックス登録」 | 自分が設定したcanonicalと一致するか |
| Googleが選択した正規URL | URL検査 →「ページのインデックス登録」 | Googleの判断が意図どおりか |
| 両者の一致 | 上記2項目を比較 | 不一致なら設定・シグナルを見直す |
重複や404などをまとめて修正した後、Search Consoleの「Validate Fix(修正を検証)」で再クロールを促す運用もあります。ただしこのボタンは問題タイプ全体が対象で、1つのURLだけを直したときはURL検査からの登録リクエストが適切です。使いどころはGSCの「Validate Fix」を使うべき場面で整理しています。日々の運用ノウハウ全般はサーチコンソールの使い方ガイドも参考にしてください。
サードパーティツールで一括チェック
| ツール | 用途 | 無料/有料 |
|---|---|---|
| Screaming Frog SEO Spider | サイト全体のcanonicalを一括抽出 | 500URLまで無料 |
| Ahrefs Site Audit | canonical設定の問題を自動検出 | 有料 |
| Sitebulb | canonical設定の可視化レポート | 有料 |
| SEO META in 1 CLICK(Chrome拡張) | 個別ページの簡易確認 | 無料 |
canonicalタグ設定時のよくあるミスと対処法
ミス一覧と対処法
| ミス | 影響 | 対処法 |
|---|---|---|
| 相対URLで記述している | 正しく解釈されないことがある | 絶対URL(https://〜)で記述する |
| 自己参照canonicalを設定していない | 正規URLが曖昧になる | 全ページに自己参照canonicalを設定する |
| canonicalの向き先が404ページ | canonicalが無視される | 実在するインデックス可能なURLを指定する |
| canonicalのチェーン(A→B→C) | 最終的な正規URLが不明確になる | 直接、最終的な正規URLを指定する |
| noindexページへcanonicalを向けている | 矛盾したシグナルになる | インデックス可能なページを指定する |
| <body>内に記述している | 無視される | <head>内に記述する |
とくに多いのが相対URLの指定です。次のように、絶対URLへ直すだけでシグナルが安定します。
<!-- Before:相対URL(NG) -->
<link rel="canonical" href="/page/" />
<!-- After:絶対URL(OK) -->
<link rel="canonical" href="https://example.com/page/" />
自己参照canonicalを全ページに置く
すべてのページに、そのページ自身のURLを正規URLとして指定する「自己参照canonical」を設定することが推奨されています。
<!-- https://example.com/page/ に設置 -->
<link rel="canonical" href="https://example.com/page/" />
自己参照canonicalがあれば、パラメータ付きURLなどで意図しない重複が発生しても、正規URLが常に明確になります。前述のとおり、主要なWordPress用SEOプラグインはこれを自動で出力します。
canonicalは「ヒント」であって「指示」ではない
canonicalタグはGoogleへの「ヒント」であり、必ず従ってもらえるわけではありません。Googleはcanonical以外にも、次のシグナルを総合して正規URLを判断します。
- サイトマップに含まれているか
- 内部リンクがどのURLに向いているか
- httpsかhttpか
- リダイレクトの設定
- ページ内容の質と独自性
だからこそ、canonicalタグ単体に頼らず、サイトマップ・内部リンク・リダイレクトの向き先をすべて正規URLでそろえる「多重の一貫性」が効きます。内部リンクの設計はSEO内部リンク戦略の設計と実装も参考にしてください。
【実践】WordPress移行時のURL正規化 — 当サイトの実体験
当サイト(scale-basics.com)は2026年7月に、Next.js(SSG)で構築していた旧サイトからWordPressへ移行しました。この移行で最も神経を使ったのが、まさにURL正規化です。抽象論ではなく、実際に行った手順を共有します。
移行で実施したこと
- 旧URLの301リダイレクト:旧構成の /blog/xxx/ 形式のURLを、新しい /xxx/ 形式へ301リダイレクトで引き継ぎました。結果として、インデックスの引き継ぎで大きな問題は発生しませんでした。
- 自己参照canonicalの徹底:全ページに自己参照canonicalが出力される状態を確認し、パラメータ付きURLで意図しない重複が起きても正規URLが揺れないようにしました。
- サイトマップとの整合:sitemap.xmlには正規URLのみを掲載し、canonical・内部リンク・リダイレクトの向き先とすべて一致させました。
実測で確認したこと
移行後は、Search Consoleの「URL検査」で主要ページを1つずつ確認し、「ユーザーが指定した正規URL」と「Googleが選択した正規URL」が一致しているかを目視でチェックしました。機械的に設定して終わりにせず、Googleの認識まで確認するのが重要だと実感しています。あわせてTTFB(サーバー応答時間)は当サイトの実測(2026年7月計測)で平均0.19秒でした。表示速度やHTML実装を含む技術面の実測データはSEOに強いコーディング(実測データ付き)にまとめています。
この経験から言えるのは、URL正規化は「canonicalタグを貼れば終わり」ではなく、301リダイレクト・サイトマップ・内部リンクを含めた一貫した設計と、移行後の実確認までがワンセットだということです。
canonicalとインデックス品質 — 2026年の視点
AI OverviewsやAI Modeといった生成AI検索が広がる中でも、URL正規化の重要性は変わりません。むしろ、評価を分散させないことの意味は増しています。重複URLに評価やシグナルが散らばると、検索エンジンにもAIにも「どのページが決定版か」が伝わりにくくなるからです。canonicalで正規URLへシグナルを集約しておくことは、通常の検索順位だけでなく、AIによる引用・参照でも土台になります。
加えてGoogleは、サイト品質への懸念が強いとインデックスするページ数自体を絞る、と説明しています。重複URLや薄い量産ページを整理し、価値あるページへクロールとインデックスを集中させることは、canonicalの本来の目的と方向が一致します。この点はクロール済み-未インデックスと品質の関係もあわせて読むと理解が深まります。
canonicalに関するよくある質問
Q. canonicalタグは全ページに設定すべき?
はい。全ページに自己参照canonicalを設定することが推奨されます。パラメータ付きURLなどで意図しない重複が発生しても、正規URLが常に明確になるためです。WordPressなら主要なSEOプラグインが自動で出力します。
Q. canonicalと301リダイレクトはどちらを使うべき?
元URLも表示させたいならcanonical、元URLを完全に統合してアクセスさせたくないなら301リダイレクトです。www・httpsの統一のような基盤に関わるものは301、パラメータ違いのようなものはcanonicalが基本です。詳細はリダイレクトの解説記事を参照してください。
Q. canonicalタグは別ドメインのURLを指定できる?
はい。クロスドメインcanonicalも可能で、コンテンツのシンジケーション(転載許可)などで利用します。ただしGoogleはあくまでヒントとして扱うため、意図どおりにならない場合もあります。
Q. hreflangタグとcanonicalタグの関係は?
多言語サイトでは、各言語版のページに自己参照canonicalを設定し、同時にhreflangで各言語版URLを相互参照させるのが正しい実装です。ある言語版のcanonicalを別言語版へ向けてはいけません。
Q. JavaScriptで生成したcanonicalタグは有効?
GoogleはJavaScriptで生成されたcanonicalも認識すると表明しています。ただし、JavaScript実行エラーで出力されないリスクを避けるため、サーバー側(SSR)やHTMLに静的に出力する方が確実です。
まとめ — canonicalはURL正規化でSEOの土台を守る
canonicalタグは、重複コンテンツによる評価分散を防ぎ、検索エンジンの評価を正規URLへ集約するためのHTML要素です。要点を振り返ります。
- canonicalは正規URLを伝える「ヒント」タグ。<head>内に絶対URLで記述する
- www有無・http/https・パラメータ・末尾スラッシュ・別URL構成のケースで設定が必要
- noindex(除外)や301リダイレクト(強制統合)とは目的が異なるため、用途で使い分ける
- 全ページに自己参照canonicalを設定し、サイトマップ・内部リンク・リダイレクトの向き先を正規URLでそろえる
- 設定後はSearch ConsoleのURL検査で、Googleが選んだ正規URLまで確認する
URL正規化は地味な作業ですが、リンク評価とクロールを正しく集約する、SEOの土台となる施策です。canonicalタグを起点に、リダイレクト・サイトマップ・内部リンクまで一貫させていきましょう。
執筆にあたっては、Google 検索セントラルの「正規 URL について」「重複した URL を統合する」の各ドキュメントを一次情報として参照しました。実装コード例は解説用の一般的なサンプルです。文中の「当サイトの実測(2026年7月計測)」は、scale-basics.comがNext.jsからWordPressへ移行した際の運用記録と計測値(TTFB平均0.19秒/curl3回計測、301リダイレクトによる旧URL引き継ぎ)に基づき、詳細はSEOに強いコーディングに記載しています。数値は計測時点のものです。