【Google検索セントラル解説】正規URLの指定方法｜転送・rel=canonical・サイトマップの強さの順と注意点

2026年10月8日

同じ内容のページに、複数のアドレスでたどり着けてしまうことがあります。そのとき、どのアドレスを検索結果に出してほしいかを、Googleにどう伝えればよいのでしょうか。

この記事は、Google検索セントラルの「How to specify a canonical URL with rel=”canonical” and other methods」を、英語版の原文から読んで整理します。3つの方法の強さの順と注意点に加え、日本語版との違い、書き換えの経緯、弊社のサイトで確かめたことも書きます。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。アドレスが揺れると計測も分かれてしまうため、正規URLの伝え方を公式の原文で確かめました。

結論：3行で言うと

正規URLを伝える方法は3つで、効き目の強い順に転送、rel=”canonical”、サイトマップです。重ねると効果が増しますが、どれも必須ではありません
方法どうしを食い違わせないことが要です。robots.txtとURL削除ツールは正規化に使わず、noindexも勧められていません
本文は2025年12月から2026年7月までに3回書き換わりました。日本語版には、転送の説明が英語版と逆向きに読める箇所があります

このページの基本情報

項目	内容
原題（英語）	How to specify a canonical URL with rel=”canonical” and other methods
日本語版の題名	rel=”canonical” などを利用して正規 URL を指定する方法
英語版の最終更新日	2026年7月10日
日本語版の最終更新日	2026年7月14日
Google検索セントラルの中の位置（章）	左の目次の「Crawling and indexing」（クロールとインデックス登録）の章にある「Canonicalization」の項目です
直近の主な更新	変更履歴にあるのは2025年12月17日（JavaScript利用時の注意の追加）まで。2026年3月27日と7月10日のページ日付にあたる書き換えは、変更履歴にありません

原文はこちらで読めます。英語版／日本語版。

Googleがこのページで言っていること

導入：3つの方法と、強さの順

転送（リダイレクト）：転送先が正規になるべきことを示す、強いシグナルです
rel=”canonical”のlink注釈：指定したURLが正規になるべきことを示す、強いシグナルです
サイトマップに載せる：載せたURLが正規になる助けになる、弱いシグナルです

方法は重ねられ、2つ以上を使うと、希望するURLが検索結果に出る可能性が高まる、とあります。一方で、ページは次の1文を置いています。

“none of them are required; your site will likely do just fine without specifying a canonical preference.”（どれも必須ではありません。正規の希望を指定しなくても、サイトはおそらく問題なく動きます）

指定しないときは、Googleがユーザーに見せるのに最良のバージョンを判断します。

正規URLを指定する理由

通常は重要ではないとしつつ、明示する理由を4つ挙げています。

検索結果で見せたいURLを決める（例：広告のクリックID付きのURLでなく、整った商品ページのURL）
重複や類似のページに向いたシグナル（他サイトからのリンクなど）を、1つのURLに集める
同じ内容の計測を楽にする
重複ページより、新しいページや更新したページのクロールに時間を回してもらう

ベストプラクティス

すべての方法に共通する注意が、9つあります。まず、避けることです。

robots.txtを正規化に使わない。許可されていないURLも、内容なしで登録されることがあります
URL削除ツールを使わない。そのURLのすべてのバージョンが、検索から隠れます
同じページに、方法ごとに別のURLを指定しない（サイトマップではA、rel=”canonical”ではB、など）
URLのフラグメント（#以降）を正規にしない
単一のサイト内で、正規ページの選択を妨げる手段としてnoindexを使うことは勧めない。ページが検索から完全にブロックされ、勧める方法はrel=”canonical”です

次に、行うことです。

正規ページ自身にも、rel=”canonical”のリンクを入れる（自己参照）
hreflangを使うときは、同じ言語の正規ページを指定する。なければ、最も近い代替の言語にする
サイト内でリンクするときは、重複URLでなく正規URLに向ける
JavaScriptで描画するサイトは、正規URLをHTMLのソースに書き、JavaScriptで変えない。書けなければ、JavaScriptだけで設定する

方法の比較

原文の表には転送とAMP版の行もあり、長所と短所の欄はありません。

方法	長所	短所
rel=”canonical”のlink要素	対応づけられる重複ページの数に上限がない	大きなサイトやURLがよく変わるサイトは、管理が複雑になる。PDFなどには使えない
rel=”canonical”のHTTPヘッダー	ページの大きさが増えない。数に上限がない	管理の複雑さは、link要素と同じ
サイトマップ	実装と維持が簡単。特に大きなサイトで楽	重複ページの特定は、Googleが行う。rel=”canonical”より弱いシグナル

rel=”canonical”の指定のしかた

Googleは、RFC 6596にある明示的な注釈に対応しています。hreflang、lang、media、typeの属性を持つrel=”canonical”は、正規化には使われません。

別バージョンを示すときは、rel=”alternate” hreflangなどを使います。

指定の方法は、HTMLのlink要素とHTTPヘッダーの2通りです。両方を使うと、別々のURLを書く間違いが起きやすいため、どちらか一方を勧めています。

link要素は、重複ページの<head>に入れます。正規ページ自身にも同じ要素を入れることを勧めています。

URLは絶対パスで書きます。相対パスにも対応していますが、長い目で見ると問題が起きうるため勧めていません。

例として、テスト用のサイトを誤ってクロールさせた場合が挙げられています。

link要素は、<head>の中にあるときだけ受け付けられます。

HTTPヘッダーは、サーバーの設定を変えられるときの方法で、PDFのようなHTML以外の文書にも使えます。対応はウェブ検索の結果だけです。

サイトマップと転送

サイトマップは、ページごとに正規URLを選んで送ります。載せたページはすべて正規の候補として示され、どれが重複かはGoogleが内容の似かたで決めます。

転送は、すでにある重複ページを無くしたいときの方法です。永続的な転送はどれも検索への効果が同じで、気づくまでの時間だけが違いうる、とあります。

最も早いのは、サーバー側のHTTPの転送です。複数のアドレスで同じページに届くなら、1つを選び、残りから転送します。

その他のシグナル：HTTPSとhreflang

Googleは、HTTPSのページを同等のHTTPのページより優先して正規にします。例外は、証明書が無効、画像以外に安全でない読み込みがある、HTTPのページへ転送している、HTTPのページへrel=”canonical”を向けている、などです。

確実にするには、HTTPからHTTPSへの転送、同じ向きのrel=”canonical”、HSTSのどれかを使います。不適切な証明書とHTTPSからHTTPへの転送は、HTTPを強く選ばせ、HSTSでも覆せません。

hreflangで相互に指し合うページは、まとまりに入っていないページより、正規として優先されます。例は、de-deとde-chが優先され、de-atが外れる場合です。

英語版と日本語版の違い

英語版は2026年7月10日、日本語版は2026年7月14日の更新で、日本語版のほうが4日新しい状態です。

2026年10月8日に、両方を取り直して比べました。見出し12個、箇条書き43個、リンク27個、表4個は同じで、内容の差は次の1点でした。

箇所	英語版	日本語版
比較表の「転送」の説明	“Use permanent redirects to tell Google that a redirected URL is a worse version than the URL it redirects to.”（転送されるURLは、転送先のURLより劣る版だと伝える）	「リダイレクト先の URL よりもリダイレクト元の URL の方が適したバージョンであることを Google に伝えます」。転送元のほうが適している、という意味になります

向きの正しさは、ページの別の節から分かります。「転送を使う」の節は、複数のURLから1つを選び、ほかのURLをそこへ転送する手順です。

劣る側は、転送元です。

向きは、この節の手順でも確かめてください。

更新の経緯

変更履歴（同日に取得）と、Internet Archiveの保存版の本文を突き合わせました。

2023年2月2日：変更履歴に、正規化の文書を3つに分けた、とあります。そのうちの1つが、このページです
2023年12月の保存版：noindexの扱いが変わっていました。2023年3月の「正規ページの選択のために使わない」が、「単一のサイト内では勧めない。ページが検索から完全にブロックされるため」になっています。この書き換えに当たる変更履歴の項目は、見つけられませんでした
2024年2月15日：変更履歴に、hreflangなどの属性を持つrel=”canonical”は正規化に使わない、と明確にした、とあります。Googleは、文書の変更のみで以前から無視していた、と説明しています
2025年12月17日：変更履歴に、JavaScript利用時の正規URLの扱いを加えた、とあります。保存版でも、この日付の版から該当の項目があります
2026年3月27日のページ日付：2026年3月4日と4月3日の保存版の間で、転送の行の説明が「転送されたURLは、あるURLより良い版」から「転送元は転送先より劣る版」に変わりました。「すべての転送の方法（301、302、meta refresh、JavaScript）」は「永続的な転送の方法」になり、現在の文は302に触れていません。robots.txtの項目にも1文が加わっています。変更履歴には載っていません
2026年7月10日のページ日付：2026年6月2日と7月13日の保存版の間で、正規ページ自身にもrel=”canonical”を入れる項目が加わりました。同じ日の変更履歴は、別ページ（正規化のトラブルシューティング）の更新です

このページから、言えること・言えないこと

言えること	言えないこと
転送とrel=”canonical”は強いシグナルで、サイトマップは弱いシグナルです	rel=”canonical”を付ければ、Googleが必ずそのURLを正規にする。トラブルシューティングのページは、明示しても別のURLが選ばれることがある、と書いています
どの方法も必須ではなく、指定しなくてもGoogleが正規を選びます	指定しなくても、自社が望むURLが選ばれる。選ぶのはGoogleです
noindexは、単一のサイト内での正規の選択には勧められません	重複ページはnoindexにしておけば安全。ページが検索から完全にブロックされます
理由は、表示するURLの指定、シグナルの集約、計測の簡素化、クロール時間の節約です	正規URLを指定すると順位が上がる。順位の向上は、理由に書かれていません

中小企業の視点で、どう受け取るか

ここからはGoogleの説明とは別の、私の読み取りです。従業員が数人から数十人で、WordPressのサイトを持つ会社を想定します。

1. 自社のページが、いくつのアドレスで開けるかを確かめる

主力のページ1本で、末尾のスラッシュの有無、wwwの有無、末尾に「?utm_source=test」を足した形を、ブラウザに入れます。

1つのアドレスへ転送されるか、別のアドレスのまま開くかが分かります。転送されないアドレスは、次の手順のcanonicalが扱いを決めます。

2. ページのソースで、rel=”canonical”を読む

ブラウザで右クリックし、「ページのソースを表示」で「canonical」を検索します。1つだけあること、https://から始まる絶対のアドレスであること、そのページ自身を指していること、の3点を見ます。

2つ以上あるときや、別のページを指しているときは、制作会社に出力元を尋ねます。CMSやプラグインが意図しないURLを示す問題は、Googleもよくある原因に挙げています。

3. Search Consoleで、Googleが選んだ正規を見る

Search Consoleの上部の検索窓にURLを入れ、URL検査にかけます。Googleが正規と見なしているページを確認できます。

正規化のトラブルシューティングのページも、この確認を最初の手順に置いています。指定と違うURLが選ばれていたら、設定の誤りと、ページどうしの内容の違いを見ます。

4. サイトマップとの食い違いを点検する

サイトマップのURLと、ページのrel=”canonical”のURLが同じかを、数本で比べます。別々の設定から出ている場合は、食い違いが起こりえます。

弊社のサイトで確かめたこと

2026年10月8日に、kenkyo.aiに次の確認をしました。Googleがどのアドレスを正規に選んでいるかは、Search Consoleの数字を使っていないため、この確認の範囲外です。

確認	結果
`curl -sL` でトップページと記事1本のHTMLを取得し、canonicalを検索	どちらも、`<head>`の中に`rel="canonical"`が1つだけありました。絶対のアドレスで、そのページ自身を指しています
同じ記事の末尾に`?gclid=TEST123`を付けて取得	200で返り、canonicalは、付けない形のアドレスを指していました。このページが例に挙げる形です
`curl -sI` で、記事のレスポンスヘッダーを確認	Linkヘッダーの中身は、APIの案内、JSON版、短縮URLの3件でした。`rel="canonical"`は0件で、正規の指定はHTMLの要素1本です
末尾スラッシュなし、wwwあり、短縮URL（`?p=`の形）で記事にアクセス	3つとも301で、記事の正規のアドレスへ転送されました
robots.txtが案内するサイトマップのうち、記事と固定ページの3ファイル（1,083URL）から、無作為に30URLを選び、各ページのcanonicalを取得	30ページとも、canonicalは1つで、サイトマップに載るアドレスと同じ宛先でした。日本語を含むアドレスは、文字の表記方式の違いを同じものとして比べています