SEO最終更新日: 2026年6月17日初出: 2026年5月4日

canonicalタグとは？重複コンテンツ対策の基本

Q: Q4. ページネーション（1ページ目、2ページ目...）にcanonicalは？

A. 各ページに自己参照canonicalを設定するのが現在の標準です。rel="prev/next"は2019年に廃止されています。1ページ目に集約するのは古いSEO情報なので避けてください。

canonicalタグの役割と正しい使い方を初心者向けに解説。重複コンテンツ問題の解消、自己参照、クロスドメインcanonicalまで実例で紹介します。

文責: LLMOツール編集部

#canonical#重複コンテンツ#正規URL

目次（80項目）

はじめに
canonicalタグとは
なぜcanonicalが必要なのか
重複が引き起こす具体的な問題
自己参照canonicalとは
自己参照canonicalが防ぐ具体的なケース
canonicalの主な用途
用途1：URLパラメータ付きの正規化
用途2：HTTPS化・wwwあり/なしの統一
用途3：類似コンテンツの統合
用途4：クロスドメインcanonical
用途別の優先度比較
canonicalタグの正しい記述方法
必須要件
推奨される書き方
避けるべき書き方
canonical設定の注意点
注意1：複数のcanonicalを設定しない
注意2：相対URLより絶対URLを推奨
注意3：canonicalはヒント、強制ではない
注意4：canonical先がnoindexされていないか
注意5：チェーンcanonicalを作らない
注意6：canonical先がリダイレクトされていないか
hreflangとの関係
canonicalの実装方法
HTML head内で指定（推奨）
HTTPヘッダーで指定（PDFなどHTML以外）
サイトマップで指定（補助）
canonicalの確認方法
ツール別の確認手順
canonical 設定のベストプラクティス
ルール1: 自身を指す canonical を全ページに
ルール2: 完全な絶対URLで記述
ルール3: HTTPS 統一
ルール4: 大文字・小文字の統一
ルール5: パラメータ付きURLは元ページに canonical
ルール6: canonical と内部リンクを一致させる
ルール7: サイトマップに正規URLのみ含める
動的サイトでの実装パターン
Next.js (App Router)
Next.js (Pages Router)
WordPress
EC・CMS
Shopify
Ruby on Rails
業界別の canonical 設計
EC（Eコマース）
メディア・ブログ
多言語・多地域サイト
SaaS・コーポレート
canonical 関連の典型エラー
失敗事例：誤った canonical 設定
事例1: 全ページのcanonicalがトップページを指していた
事例2: HTTPS化後もcanonicalがhttpのまま
事例3: パラメータ付きURLが正規になっていた
事例4: クロスドメインcanonicalで自社評価が消えた
事例5: noindexページにcanonical集約
canonical と noindex / 301 の使い分け
判断フローチャート
hreflang との併用
運用チェックリスト
よくある質問
Q1. canonicalで301リダイレクトの代用になりますか？
Q2. canonicalタグを設定したらすぐ反映されますか？
Q3. canonicalを誤設定するとどうなりますか？
Q4. ページネーション（1ページ目、2ページ目...）にcanonicalは？
Q5. canonicalとnoindexは併用できますか？
Q6. 別ドメインへ転載するときのcanonicalは必須ですか？
Q7. JavaScriptで動的に canonical を書き換えても認識されますか？
Q8. canonical を設定したのにGSCで「Googleが選択した正規URL」が異なる場合は？
canonical と他のSEO要素の連携
内部リンクとの整合
サイトマップとの整合
robots.txtとの整合
構造化データとの整合
リダイレクトとの整合
まとめ
関連用語
関連記事
参考文献・出典

canonicalタグとは？重複コンテンツ対策の基本

この記事の結論: canonicalタグは「複数URLで同じ内容がある場合、どれが正規版か」をGoogleに伝えるタグです。すべてのページで自己参照canonicalを設定するのが2026年の標準です。

最終更新日: 2026-05-05

はじめに

「同じ内容のページが複数あって、Googleに混乱されている気がする」という悩みを持つ方向けの記事です。canonicalタグの役割と、初心者がやるべき対応を解説します。

canonicalタグとは

canonicalタグは、複数のURLで同じか類似のコンテンツがある場合に「正規版はこのURL」を検索エンジンに伝えるためのHTMLタグです。<link rel="canonical" href="...">の形でheadタグ内に記述します。

<link rel="canonical" href="https://example.com/articles/seo-basics">

これは2009年にGoogle・Yahoo・Microsoftが共同で策定した仕組みで、現在はRFC 6596としてIETFの標準にもなっています。検索エンジンに対する「ヒント」であり、絶対的な指示ではない点が特徴で、Googleは内部リンク構造、サイトマップ、リダイレクトなど複数のシグナルから総合的に正規URLを判断します。→ 詳しくはSEO基礎完全ガイド。

問題	症状	canonicalで解決可能か
被リンク評価の分散	同一内容で複数URLにリンクが散る	○（評価集約）
クロール予算の浪費	新規ページのインデックスが遅い	○（クロール削減）
SERP表示URLの汚れ	パラメータ付きURLが検索結果に出る	○（正規URL優先）
インデックスからの除外	ページがインデックスされない	△（誤設定で悪化も）
サイト評価の希薄化	個別ページの順位が伸びない	○（評価一本化）

自己参照canonicalとは

「自己参照canonical（Self-referencing canonical）」とは、自分自身のURLをcanonicalに指定することです。Googleは2026年現在、すべてのページで自己参照canonicalを設定することを推奨しています。

<!-- https://example.com/articles/seo-basics ページに以下を記述 -->
<link rel="canonical" href="https://example.com/articles/seo-basics">

なぜ必要かというと、URLパラメータ（?utm_source=...）が付与されたバリエーションが生まれた時に、自動的に正規版を主張できるからです。

ポイント: WordPressはYoast SEOやRank Mathが自動で自己参照canonicalを出力します。手動運用のサイトは漏れやすいので注意。

自己参照canonicalが防ぐ具体的なケース

自己参照canonicalがあると、外部からの被リンクが?ref=newsletterのようなパラメータ付きで張られても、Googleは正規URLに評価を集約します。逆に、自己参照canonicalがないページに広告クリック計測用のパラメータが付くと、Googleは「パラメータ付きURL」を正規版として選んでしまうこともあります。SNSシェア時のキャンペーンタグも同じ問題を起こします。

用途	推奨度	代替手段	注意点
URLパラメータの正規化	必須	URLパラメータ設定（GSC旧機能で廃止）	機能パラメータは含めても可
HTTPS/www統一	補助	301リダイレクト（推奨）	リダイレクト未設定時の保険
類似商品ページ統合	推奨	バリアント機能（Shopify等）	UX要件で個別ページ必要なら canonical
クロスドメイン転載	必須	noindex（評価ゼロになる）	転載先で必ず元記事を指す
ページネーション	各ページ自己参照	rel=prev/next（廃止済）	一覧1ページ目に集約は非推奨
AMP/モバイル別URL	必須	レスポンシブ（推奨）	別URL運用時のみ

canonical設定の注意点

注意2：相対URLより絶対URLを推奨

× <link rel="canonical" href="/articles/seo">
○ <link rel="canonical" href="https://example.com/articles/seo">

注意3：canonicalはヒント、強制ではない

Googleは複数のシグナルを総合判断します。canonicalだけでなく、内部リンク・サイトマップ・hreflang等と矛盾していると無視されることがあります。

注意5：チェーンcanonicalを作らない

A→B→C のように canonical が連鎖していると、Googleは追跡を途中でやめることがあります。canonicalは1ホップで最終正規URLを指す必要があります。

注意6：canonical先がリダイレクトされていないか

canonical先のURLが301でさらに別URLにリダイレクトされていると、Googleは混乱します。canonical先は200で応答する実URLにします。

hreflangとの関係

多言語サイトの場合、各言語版のページに自己参照canonicalを設定し、加えてhreflangで言語バージョンを伝えます。

<link rel="canonical" href="https://example.com/ja/article">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/article">
<link rel="alternate" hreflang="en" href="https://example.com/en/article">

多言語サイトで最も多い失敗は、英語版ページのcanonicalを日本語版に向けてしまう「言語横断canonical」です。これをやると英語版がインデックスから消えます。各言語ページは必ず自身を canonical に指定し、hreflangで言語バリエーションを示すのが正解です。

canonicalの実装方法

HTML head内で指定（推奨）

<head>
  <link rel="canonical" href="https://example.com/articles/seo">
</head>

HTTPヘッダーで指定（PDFなどHTML以外）

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

PDF・画像・動画などHTMLタグを書き込めないファイルでは、HTTPレスポンスヘッダーでcanonicalを指定します。Apacheなら.htaccess、Nginxならadd_header、CDN（Cloudflare、Fastly）なら配信ルールで設定可能です。

Apache (.htaccess) の例

<Files "whitepaper.pdf">
  Header set Link "<https://example.com/whitepaper.pdf>; rel=\"canonical\""
</Files>

Nginx の例

location /downloads/whitepaper.pdf {
  add_header Link '<https://example.com/downloads/whitepaper.pdf>; rel="canonical"';
}

サイトマップで指定（補助）

サイトマップに含まれるURLは、Googleが正規版とみなすシグナルになります。sitemap.xmlには正規URLのみを含め、パラメータ付きURLや非正規URLを含めないことが重要です。

ツール	確認できる内容	用途
GSC URL検査	指定/選択 canonical、インデックス状況	個別URL深掘り
GSC ページレポート	サイト全体の canonical エラー一覧	全体監査
Screaming Frog	全ページの canonical 一覧、チェーン検出	大規模サイト棚卸
Ahrefs Site Audit	canonical 不一致、HTTPS問題	競合比較込みの監査
Sitebulb	視覚的なクロールマップ、矛盾検出	構造の可視化
ブラウザDevTools	単一ページのHTML確認	開発時の即時確認
curl コマンド	HTTPヘッダーcanonical確認	PDFなどHTML外資源

canonical 設定のベストプラクティス

実装漏れと誤設定を防ぐ運用ルールです。

ルール1: 自身を指す canonical を全ページに

「重複していないページ」も自身のURLを指す canonical を必ず設定します。これにより外部サイトが付加クエリ付きで自社URLを共有しても、Google は同一ページとして集約します。

ルール2: 完全な絶対URLで記述

/article/foo ではなく https://example.com/article/foo の絶対URLを使用。Google公式の正規URLガイドでも推奨されています。

ルール3: HTTPS 統一

http:// ではなく https:// 版に統一。www あり/なしも事前に決めて統一します。

ルール4: 大文字・小文字の統一

URLは大文字小文字を区別するサーバーがあるため、原則すべて小文字に統一します。

ルール5: パラメータ付きURLは元ページに canonical

?utm_source=... のようなトラッキングパラメータが付いたURLは、パラメータなしの正規URLを canonical に指定。

ルール6: canonical と内部リンクを一致させる

サイト内部から張るリンクは canonical で指定したURLと完全一致させます。内部リンクが非正規URLを指していると、Googleは「サイト所有者自身が非正規URLを推している」と判断し、canonical指定を無視することがあります。

ルール7: サイトマップに正規URLのみ含める

サイトマップは「インデックスしてほしいURLリスト」です。canonical で除外したパラメータ付きURLや古いURLを含めると矛盾シグナルになります。

動的サイトでの実装パターン

Next.js (App Router)

export const metadata: Metadata = {
  alternates: {
    canonical: `/articles/${slug}`,
  },
};

App RouterのmetadataAPI使用時、metadataBaseを設定しておけば相対パスでも自動的に絶対URLに変換されます。

// app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL('https://example.com'),
};

Next.js (Pages Router)

import Head from 'next/head';

<Head>
  <link rel="canonical" href={`https://example.com/articles/${slug}`} />
</Head>

WordPress

Yoast SEO / Rank Math が自動で canonical を出力。ただし投稿の編集画面で個別上書き可能なため、定期チェックが必要です。複数のSEOプラグインを同時インストールすると重複出力が起きるので、必ず1つに絞ります。

EC・CMS

商品ページのカラー違い・サイズ違いは、親商品ページを canonical に指定するのが標準です。

Shopify

Shopify は商品バリアントごとに自動で正規URLを設定しますが、コレクションページ経由のURL（/collections/xxx/products/yyy）が多数生成されるため、テーマ側で{{ canonical_url }}変数を出力する必要があります。

Ruby on Rails

<link rel="canonical" href="<%= url_for(only_path: false, host: 'example.com') %>">

業界別の canonical 設計

EC（Eコマース）

ECサイトはバリエーション・絞り込み・並び替え・ページネーションでURLが爆発的に増えます。

シナリオ	推奨canonical
商品カラー違い	親商品ページ
商品サイズ違い	親商品ページ
並び替え（価格順など）	パラメータなし一覧
絞り込み（ブランド・価格帯）	価値ある組み合わせは個別、それ以外は一覧
ページネーション2ページ目以降	各ページ自己参照
検索結果ページ	noindex推奨（canonical不要）

メディア・ブログ

シナリオ	推奨canonical
通常記事	自己参照
AMP版	通常版URL
カテゴリページ	自己参照
タグページ	自己参照（薄ければnoindex）
著者ページ	自己参照
月別アーカイブ	自己参照 or noindex

多言語・多地域サイト

各言語・各地域版で自己参照 canonical + hreflang 相互参照が基本。x-defaultで言語選択ページや英語版を指定するのが一般的です。

SaaS・コーポレート

機能ページ・料金ページ・事例ページは原則自己参照。プレスリリースを別ドメイン（PR TIMES等）に同時配信する場合は、コーポレート側を canonical 元にします。

→ 詳しくは内部・外部リンクのSEO効果。

canonical 関連の典型エラー

Google Search Console（GSC）の「ページ」レポートで以下のエラーが出たら要修正です。

エラー	原因	修正
重複しています。Google が選択した正規 URL がユーザーの選択と異なります	サイト側の指定が無視された	内部リンク・サイトマップを正規URL統一
正規 URL の指定がありません	canonical 未設定	全ページに自己指す canonical を追加
重複しています。送信された URL が正規として選択されていません	サイトマップに非正規URLを送信	サイトマップを正規URLに修正
重複しています。ユーザーにより、正規ページとして選択されていません	別ページがcanonical元に指定	意図と一致するか確認、不要ならcanonical修正
代替ページ（適切な canonical タグあり）	重複ページとして処理済（正常）	修正不要

失敗事例：誤った canonical 設定

実際に起きた典型的な事故パターンと、復旧手順をまとめます。

事例1: 全ページのcanonicalがトップページを指していた

WordPressのテーマ移行時、全ページの<link rel="canonical">がハードコードでトップページURLになっていた事例。1ヶ月後にサイト全体の検索流入が90%減少しました。

復旧手順: 各ページが自身のURLを指すよう修正→GSCで主要URLを「インデックス登録をリクエスト」→2〜4週間で回復。

事例2: HTTPS化後もcanonicalがhttpのまま

サイトをHTTPS化したのに、canonicalだけhttp://を指したままだった事例。Googleは「httpが正規」と判断し、httpsをインデックスから外しました。

復旧手順: canonicalをhttps://に修正→旧http URLからhttpsへの301リダイレクトを確認→GSCで再クロール依頼。

事例3: パラメータ付きURLが正規になっていた

EC商品ページに ?color=red のセッションIDが付いていた事例。商品ページの canonical がセッションごとに異なるURLを指してしまい、Googleが「同一商品の何百もの異なるURL」と認識。

復旧手順: セッションIDをCookieに移行→canonicalをパラメータなしの正規URLに固定→重複URLからの301で集約。

事例4: クロスドメインcanonicalで自社評価が消えた

オウンドメディアの記事をMediumに転載した際、canonicalを設定し忘れた結果、Mediumのほうが検索順位で勝ってしまった事例。

復旧手順: Medium側のcanonicalを自社URLに修正→自社記事の被リンク強化→数ヶ月で順位逆転。

事例5: noindexページにcanonical集約

「重複ページをnoindexしてさらにcanonicalで本物に集約しよう」とした事例。noindexがあるとGoogleはcanonicalシグナルを評価しないため、評価集約が機能しません。

復旧手順: noindexを外しcanonicalだけ残す→または逆にcanonicalを外しnoindexだけにする。併用しないのが鉄則。

→ 詳しくはSEO基礎完全ガイド。

canonical と noindex / 301 の使い分け

3つの似た仕組みは目的と効果が違います。

仕組み	目的	評価の集約	UX影響
canonical	検索エンジンへの正規URLヒント	あり（緩やか）	なし（同URL閲覧可能）
noindex	インデックスから除外	なし	なし（閲覧可能）
301リダイレクト	URL自体の恒久移転	あり（強力）	あり（強制転送）
302リダイレクト	URL自体の一時移転	限定的	あり（強制転送）

判断フローチャート

古いURLを完全に置き換えたい → 301リダイレクト
両方のURLにアクセスさせたい、片方を正規にしたい → canonical
インデックスはさせたくないがアクセスは可能にしたい → noindex
検索結果に出したくないし評価も渡したくない → noindex + 内部リンク削除

301とcanonicalの最大の違いは「ユーザー側の挙動」です。301は強制転送なのでブックマークされた古いURLも自動で新URLに飛びますが、canonicalはユーザーの閲覧URLは変わりません。

→ 詳しくはsitemap.xmlとrobots.txt。

hreflang との併用

多言語サイトでは canonical と hreflang を併用します。各言語ページが自身を canonical に指定し、hreflang で他言語ページを相互参照する構造が標準です。

運用チェックリスト

サイトリニューアルやコンテンツ追加後、以下を順番に確認します。

チェック項目	確認ツール	頻度
全ページに canonical が出力されているか	Screaming Frog	リニューアル時、月次
canonical先が200応答か	Screaming Frog / Ahrefs	月次
canonicalチェーンが発生していないか	Screaming Frog	月次
GSC「ページ」レポートにcanonicalエラーがないか	Google Search Console	週次
サイトマップと canonical が整合しているか	GSC サイトマップ	サイトマップ更新時
内部リンクと canonical が一致しているか	Screaming Frog	月次
HTTPS/wwwの統一	curl / DevTools	リニューアル時
多言語サイトの hreflang 整合	GSC 国際ターゲティング	月次

よくある質問

Q1. canonicalで301リダイレクトの代用になりますか？

A. なりません。リダイレクトはユーザーも転送される強い指示、canonicalは検索エンジンへのヒントです。URL移転は301推奨です。canonicalはあくまで「両方のURLにアクセスさせつつ、どちらを正規版として扱うかを伝える」用途に限定されます。

Q2. canonicalタグを設定したらすぐ反映されますか？

A. 数日〜数週間かかります。Googleが再クロール・再評価する必要があるためです。重要なURLはGSCの「URL検査」から手動でインデックス登録をリクエストすると早まります。

Q3. canonicalを誤設定するとどうなりますか？

A. 別ページに評価が集約されてしまい、本来のページがインデックスされなくなります。最悪サイト全体の検索流入が消えるので慎重に。実装後は必ずGSCで「Googleが選択した正規URL」がユーザー指定と一致しているか確認します。

Q4. ページネーション（1ページ目、2ページ目...）にcanonicalは？

A. 各ページに自己参照canonicalを設定するのが現在の標準です。rel="prev/next"は2019年に廃止されています。1ページ目に集約するのは古いSEO情報なので避けてください。

Q5. canonicalとnoindexは併用できますか？

A. 併用は非推奨です。noindexがあるとGoogleはcanonicalシグナルを無視するため、評価集約が機能しません。「インデックスから除外したいだけ」ならnoindex単独、「評価を別URLに渡したい」ならcanonical単独で使います。

Q6. 別ドメインへ転載するときのcanonicalは必須ですか？

A. はい、ほぼ必須です。転載先ページに元記事URLをcanonicalで指定しないと、転載先のほうが検索評価で勝ってしまうリスクがあります。Medium、note、はてなブログなどへの転載時は必ず元記事URLを canonical に設定してください。

Q7. JavaScriptで動的に canonical を書き換えても認識されますか？

A. Googleはレンダリング後のDOMからcanonicalを読み取りますが、サーバーサイドレンダリング（SSR）または静的生成での出力が確実です。SPA（クライアントレンダリング）の場合、初回HTMLに canonical を含めるか、Next.js等のSSRフレームワーク採用を推奨します。クライアント側でcanonicalを書き換える方式は、Googlebotのレンダリング遅延でインデックスされないリスクがあるため避けるのが安全です。

Q8. canonical を設定したのにGSCで「Googleが選択した正規URL」が異なる場合は？

A. これはGoogleがあなたの canonical 指定を「他のシグナルと矛盾している」と判断したサインです。具体的には、（1）内部リンクの大半が非正規URLを指している、（2）サイトマップに非正規URLが含まれている、（3）外部からの被リンクが非正規URLに集中している、（4）canonical先がnoindexまたは404、のいずれかが原因です。内部リンクとサイトマップを正規URLで統一することで多くのケースは解消します。

canonical と他のSEO要素の連携

canonicalは単独で機能するものではなく、他のSEO要素との整合性が評価のカギです。

内部リンクとの整合

サイト内部から張るリンクはすべて canonical で指定したURLと一致させます。内部リンクが非正規URLを指していると、Googleは「サイト所有者自身が非正規URLを推している」と判断し、canonical指定を上書きすることがあります。

サイトマップとの整合

sitemap.xmlには正規URLのみを含めます。canonicalで除外したパラメータ付きURLや古いURLを含めると、Googleにとって「どちらが本物か」のシグナルが矛盾します。

robots.txtとの整合

canonical先のURLがrobots.txtでDisallowされていると、Googleはそのページをクロールできず canonical も評価できません。canonical先は必ずクロール許可します。

構造化データとの整合

構造化データ（JSON-LD）の@idやurlフィールドは canonical と一致させます。不一致だとGoogleが構造化データを無視することがあります。

リダイレクトとの整合

301リダイレクトのチェーン（A→B→C）の終点と、canonical先のURLは一致させます。リダイレクトの途中URLを canonical に指定すると、評価が分散します。

まとめ

canonicalタグは地味ですが、実装ミスがサイト全体の検索流入を消すほど影響が大きい要素です。基本ルールは「全ページに自己参照canonicalを絶対URLで」「canonical先は200応答かつnoindexでないこと」「内部リンク・サイトマップと一致させる」の3つ。これを守るだけで重複コンテンツ問題の8割は解決します。サイト規模が大きくなったら、Screaming FrogやAhrefs Site Auditで定期監査を組み込み、GSCのページレポートを週次で確認する運用を推奨します。canonicalを軽視するとサイト全体の評価が分散し、本来取れるはずの検索順位を逃します。逆に正しく運用すれば、SEOの基礎体力を底上げする静かな打ち手として長期的に効きます。