【Google検索セントラル解説】正規化に関する問題の修正｜Googleが選んだ正規URLの確かめ方と、よくある6つの原因

2026年10月8日

中野輝規

同じ内容のページが複数のURLで見つかると、Googleはその中から代表のURL（正規URL）を1つ選びます。自分で「こちらが代表です」と指定していても、Googleが別のURLを選ぶことがあります。

この記事では、Google検索セントラルの「正規化に関する問題の修正」を、英語版の原文から読みます。どこを見て、何を直し、どれくらい待つかを、中小企業のサイトに当てはめて整理します。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。記事を出しても検索に出てこないとき、代表のURLが意図と違っていないかは、最初に見ておきたい点なので、このページを読みました。

結論：3行で言うと

正規URLを指定しても、Googleが別のURLを選ぶことがあると、原文は冒頭で述べています。まずSearch ConsoleのURL検査ツールで、Googleが選んだ正規ページを確かめます
直し方の核心は、グループにまとめられたページどうしを、十分に違うものにすることです。直したあとも、Googleは最長2週間、ページを重複のグループに置くことがあります
Googleが別のURLを選ぶ原因として、原文は6つを挙げています。言語バージョンの注釈漏れ、CMSの誤り、サーバー設定、ハッキング、転載、コピーサイトです

このページの基本情報

項目	内容
原題（英語）	Fix canonicalization issues
日本語版の題名	正規化に関する問題の修正
英語版の最終更新日	2026-08-21
日本語版の最終更新日	2026-09-11
Google検索セントラルの中の位置	「クロールとインデックス登録」の章。左メニューの名前は「Fix canonicalization issues」
直近の主な更新	2026-08-21に内容が4つの手順へ組み替えられました。2026-07-10には、再評価の時間の説明が加わっています

原文はこちらです。英語版、日本語版。

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

原文は短く、4つの手順と「よくある問題」の表で構成されています。

冒頭：指定しても、別のページが選ばれることがある

最初の段落が、このページの前提です。原文は次のように書いています。

「Even if you explicitly designate a canonical page, Google might choose a different canonical for various reasons, such as the quality of the content or technical signals.」（正規ページを明示的に指定していても、コンテンツの品質や技術的なシグナルなどの理由で、Googleが別の正規ページを選ぶことがあります。）

この「正規化」は、重複したページの中から代表のURLを選ぶ作業です。仕組みの全体像は、同じ章の「What is canonicalization」が説明しています。

その解説ページは、正規URLの指定を「ヒント」と呼んでいます。命令ではありません。

手順1：Googleが正規と見なしたページを確かめる

URL検査ツールで、Googleが正規と考えているページを調べます。次に、その選ばれたページのほうが、Google検索から来る利用者にとって適切ではないか、と考えてみるよう原文は求めています。

注意書きが1つあります。正規URLが、自分の持っていないSearch Consoleプロパティの中にあると、重複側のページのトラフィックは見えません。

手順2：技術的な問題を探す

意図しない正規URLの指定が、設定ミスで送られていないかを確かめます。原文は、後ろの「よくある問題」の表で、誤った正規化の要素、サーバーの設定ミス、ローカライズの注釈漏れなどを調べるよう案内しています。

手順3：まとめられたページが、十分に違うことを確かめる

原文は、正規化の問題を技術的に直すことは、要するに、グループ（原文の語はクラスタ）にまとめられたページどうしを十分に違う状態にすることだ、と書いています。そのうえで、2つの注意点を挙げます。

再評価には時間がかかる：内容の問題を直したあとも、Googleは最長2週間、ページを重複のグループに置くことがあります
内容の違いが大事：ほかのページとの違いが明確で大きいほど、早くグループから分かれるのが一般的です

手順4：再インデックス登録をリクエストする

内容を直したら、URL検査ツールの「インデックス登録をリクエスト」で、グループ内のページの再評価をGoogleに頼めます。ただし、この機能には割り当て（回数の上限）があるため、いちばん大事なURLだけに使うよう、原文は書いています。

よくある問題：6つの原因

指定したURLと、実際に選ばれたURLが食い違う理由のうち、よくあるものを原文は6つ挙げています。

原因	原文の説明	原文が示す対処
ローカライズの注釈がない言語バージョン	同じ内容を世界の利用者向けにローカライズした複数のサイトがある。例：米国・英国・オーストラリアの英語圏向けに、同じ内容のサイトを分けて持つ	hreflangの注釈をページに加えると、地域ごとに適切なページが出やすくなる。ローカライズサイトのガイドラインに従う
誤った正規化の要素	CMSやそのプラグインが、望ましくないURLを指す正規化の手法を誤って使うことがある	ブラウザの開発者ツールでHTMLを確かめる。想定外の指定が見つかったら、CMSの提供元に報告する
サーバー設定の誤り	別のドメインのURLへのリクエストに、自社ドメインの内容を返してしまう。無関係な2台のサーバーが、同一のソフト404ページを返し、Googleがエラーページと見抜けない	ホスティング事業者に連絡する
悪意のあるハッキング	3xxのリダイレクトや、別ドメインを指す正規化の指定を、HTMLの`<head>`またはHTTPヘッダーに挿入する攻撃がある。指す先は悪質またはスパムの内容が多く、被害を受けたサイトのURLの代わりに、そちらがGoogleに選ばれることがある	原文は説明にとどまり、「被害を受けたサイト」の語に、ハッキングを扱うweb.devの記事へのリンクを付けている
シンジケーション（転載）されたコンテンツ	転載先のページと元のページは、内容が大きく違うことが多い	転載先に重複を避けさせる目的では、正規化の指定は勧めない。最も効果的なのは、転載先がインデックス登録をブロックすること
コピーサイト	まれに、無断で内容を載せている外部サイトのURLが選ばれる	著作権法に違反する複製と考える場合は、そのサイトのホストに削除を求める。デジタルミレニアム著作権法に基づく申請で、検索結果からの削除をGoogleに頼むこともできる

原文がリンクするGoogleニュースのヘルプも開きました。noindexのメタタグは、Googleニュースだけを止めるものと、Google検索も含めて止めるGooglebot向けのものが紹介されています。

英語版と日本語版の違い

最終更新日は、英語版が2026-08-21、日本語版が2026-09-11です。日本語版のほうが新しく、4つの手順に組み替えられた内容も、日本語版に入っています。

本文を突き合わせたところ、実務の判断を変える差は見つかりませんでした。ただし、言い回しの差が3か所あります。

箇所	英語版	日本語版	読み取れる差
コピーサイトの連絡先	「the site’s host」（サイトのホスト）に削除を求める	「そのサイトの所有者」に削除を求める	英語版は、サイトを置いている事業者を指す語と読めます。所有者と、ホスティング事業者は別の相手になりえます
ローカライズの注釈がない言語バージョン	「localized to different users around the world」（世界の利用者向けにローカライズ）。例は、英語圏3か国向けの同じ内容のサイト	「さまざまな言語にローカライズ」。例は英語圏3か国	日本語版は、言語を変えた翻訳サイトの話にも読めます。例は同じ言語の地域違いです
ハッキングの挿入先	HTMLの`<head>`、または（or）HTTPヘッダー	HTMLの`<head>`（HTTPヘッダー）と、カッコでつなぐ	HTTPヘッダーが、HTMLとは別の場所である点が、日本語版では見えにくくなっています

ローカライズの行は、同じ章の「What is canonicalization」の記述で補えます。そのページは、別の言語のページどうしを重複と見なすのは、本文が同じ言語のままのときだけだと書いています。

更新の経緯：変更履歴にある更新と、ない更新

Googleの変更履歴（Search Central updates）と、Internet Archiveの保存版で、このページの変化を追いました。保存版は、最終更新日の表示が2023-02-20、2025-03-06、2025-12-18、2026-07-10の4通りを取り寄せ、現在の版と比べました。

時期	確かめた変化
2023年2月2日	変更履歴に「正規化の解説を3つに分けた」と載っています。このページはその1つで、「Fix canonicalization issues」です
最終更新日の表示が2023-02-20の版	原因は5つで、シンジケーション（転載）の項はまだありません。Search Consoleプロパティの注意書きは、末尾にありました
2023年5月2日と、最終更新日の表示が2025-03-06の版	変更履歴に、正規化の解説へ転載コンテンツの推奨を明示した、との項目があります（対象のページ名は書かれていません）。2025-03-06表示の保存版には、転載の項が入り、「誤った正規化の要素」の説明も「外部サイトのURLを指す」から「望ましくないURLを指す」へ変わっています。間の版は取り寄せられず、転載の項がこの日に入ったのか、後者がいつ変わったのかは分かりません
2025-12-18	本文の文章は同じで、ソフト404の説明へのリンク先が変わりました
2026年7月10日	変更履歴に載っています。再評価にかかる時間の説明が加わりました。保存版では、最長2週間と、内容の違いが大きいほど早く分かれる点を確認しました
2026-08-21（現在の版）	変更履歴に載っていない更新です。内容が4つの手順に組み替えられ、「URL Testing Tool」という呼び名が「URL Inspection tool」に変わっています。Search Consoleプロパティの注意書きは、手順1に移りました

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

言えること	言えないこと
正規ページを指定しても、Googleが別のページを選ぶことがある	指定の記述が無視された。原文は、品質や技術的なシグナルなどが理由になりうると書くだけで、個別の原因は示していません
修正後、Googleがページを重複のグループに最長2週間置くことがある	2週間待てば必ず直る。原文が書くのは「最長」の期間で、結果の保証ではありません
転載先の重複には、正規化の指定より、転載先でのインデックス登録のブロックが効果的	転載された記事は、必ず原文側が正規として選ばれる。このページに、そうした保証は書かれていません

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

ここからはGoogleの説明とは別の、私の読み取りです。確かめやすい順に並べました。

1. 主要なページで、Googleが選んだ正規URLを見る

Search Consoleの画面上部にある検査検索バーに、集客したいページのURLを入れます。ヘルプによると、入れるURLは、いま開いているプロパティのものです。

結果の「ページのインデックス登録」の中に、「Google が選択した正規 URL」の欄があります。これが自分の指定と同じかを見比べます。

この欄名はSearch Consoleのヘルプ（取得日2026-10-08）の表記で、管理画面そのものは今回開いていません。

ヘルプによると、正規ページは登録済みのデータからしか確認できず、ライブテストでは予測できません。公開直後のページは、登録を待ちます。

2. 食い違っていたら、ページのソースで正規の指定を読む

該当ページのソースをブラウザで表示し、「canonical」を探します。rel="canonical"の行が、そのページ自身のURLを指しているかを見ます。

WordPressでは、SEO用のプラグインがこの行を出している場合があります。ページを複製して新しい記事を作ったとき、指定が複製元を向いたままになる例は、公開した記事が検索に出てこないときの診断手順に書きました。

この記事はGoogleの公式ページの解説、診断手順の記事は実務の切り分けと、役割を分けています。

想定外の指定が出ていたら、原文は、CMSの提供元に報告するよう勧めています。

3. 似たページを作っていないか、一覧で見直す

地域別、店舗別、サービス別に、本文がほぼ同じページを並べていないかを見直します。「十分に違う」状態にするには、書き分けるか、1つに統合するかだと、私は読みました。

直したあとは、最長2週間は様子を見ます。ヘルプによると、検査のリクエストには1日あたりの上限があるため、リクエストは大事な1〜2ページに絞ります。

4. 見覚えのないドメインが選ばれているときは、サイトの異常を疑う

自社と無関係のドメインが選ばれているときは、サーバー設定、ハッキング、転載、コピーサイトのどれに当たるかを順に考えます。

ページのソースやHTTPヘッダーに、身に覚えのない正規の指定やリダイレクトがあれば、ハッキングの可能性があります。原文は、web.devの記事へのリンクを付けています。

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

2026年10月8日に、弊社サイト（kenkyo.ai）の正規化に関わる点を、コマンドで確かめました。Search Consoleの画面の数字は私には見られないため、外から確かめられた範囲だけを載せています。

ページ内の正規の指定：トップページと記事3本を、Googlebotを名乗るUser-Agentで取得しました（curl -sL -A "…Googlebot…"）。4ページとも、HTMLにrel="canonical"の行が1つだけあり、そのページ自身のhttpsのURLを指していました。確かめた記事1本では、HTTPヘッダーに正規の指定はありませんでした
パラメータ付きのURL：記事に?utm_source=testを付けて取得すると、HTTP 200で表示され、正規の指定はパラメータの無いURLを指していました
転送：記事1本で、末尾のスラッシュを省いたURL、?p=に記事番号を付けたURL、www付きのURLは、いずれも301で記事の正規URLへ移りました
サイトマップとの一致：post-sitemap.xmlの記事URL（パラメータの付かないもの）から無作為に20件を取得しました。20件すべてがHTTP 200で、rel="canonical"が1つ、サイトマップのURLと同じページを指していました
言語の注釈：トップと記事3本のソースに、hreflangの記述はありません