rel=”canonical”タグは、検索エンジンに「コンテンツの正規版であるURL」を伝えることで、評価の分散を防ぎます。
Google SEOでは、ページの<head>内に<link rel=”canonical” href=”正規URL”>を追加して使用します。
データによると、Canonicalタグを正しく実装したEコマースサイトでは、商品一覧ページのインデックス率が平均28%向上し、重複URLのクローラーによるクロール回数が40%〜60%削減されています。
ニュース系サイトでは、正規タグで類似記事を統合することで、コアコンテンツの検索クリック数が平均19%増加しています。
しかし、実際の調査では、このタグを100%正しく使用できているウェブサイトはわずか31%です（一般的なエラーには、間違ったURLへの指定、プロトコル/ドメインをまたいだ非正規化、複数タグの重ね合わせなどが含まれます）。
canonicalタグを使用する必要がある理由
Google検索エンジンの日常的なクロールにおいて、65%以上のウェブサイトでURL構造設計の不備に起因する重複コンテンツの問題が発生しています。
具体的な例:
- 同一の記事に、パラメーター付きのURL（例：?utm_source=xxx）でアクセスできる
- ディレクトリのサフィックス（例：/page/ や /page/index.html）が付いている
- 異なるサブドメイン（例：www と非www）がある
GoogleのJohn Mueller氏は、公式の質疑応答で、検索エンジンが「複数のURLが非常に類似した、あるいは完全に同じコンテンツを表示している」ことを発見した場合、「どのURLに評価を割り当てるべきか」という判断の難しさに直面すると繰り返し述べています。
あるEコマースの商品ページは、色フィルターやソートパラメーターによって10数個の異なるURLが生成される可能性があり、あるニュース記事は複数のセクションに配信され、複数のエントリリンクが形成される可能性があります。
canonicalタグを使用することで、検索エンジンに明確に伝えます。「このコンテンツは複数のURLからアクセスできるが、評価とランキングの焦点を私が指定したこのURLに合わせてほしい」と。
重複コンテンツがSEOに与える影響
重複コンテンツ自体が直接的に検索エンジンのペナルティを引き起こすわけではありませんが（Googleは「単純なコンテンツの重複でサイトを罰することはない」と明言しています）、評価の分散を引き起こします。
同じコンテンツが複数のURLからアクセス可能な場合、検索エンジンはこれらのURLを「異なるページ」として個別に処理します。
例えば、あるオリジナル記事が以下の4つのURLで表示されているとします。
https://example.com/articlehttps://example.com/article?source=newsletterhttps://example.com/article#commentshttps://www.example.com/article（www付きバージョン）
正規の識別子がなければ、検索エンジンはこれら4つのURLを同時にクロールし、それぞれにインデックス評価を計算する可能性があります。
しかし、ユーザーの検索ニーズは本質的に一つの回答しか必要としません。最終的に、これら4つのバージョンのランキングはすべて低くなる可能性があり（評価が分散されるため）、あるいはそのうちの一つだけがたまたまインデックスされ、他のバージョンは長期的に「未インデックス」または「低ランキング」の状態にとどまります。
Eコマースサイトでは、パラメーター（例：?size=XL、?color=red）によって生成される商品詳細ページの重複URLは平均8〜12個に達し、これらのページのクローラーによるクロール占有率は、全体のクロール量の15%〜20%に及ぶ可能性があります（これは、より価値のある新しいページに割り当てるべきクロール量です）。
ニュース系サイトでは、コンテンツが複数のセクション（例：「最新ニュース」「業界動向」「人気推奨」）に配信されるため、単一の記事で3〜5個の異なるエントリURLが生成される可能性があります。
より具体的な事例：ある中規模Eコマースサイトは、URLを正規化する前、商品一覧ページのインデックス率がわずか62%でした（つまり、100ページ中62ページのみがGoogleに登録され、ランキングに参加する可能性がありました）。
パラメーター付きの一覧ページ（例：?category=shoes&sort=price）にcanonicalタグ（パラメーターなしの基本URL、例：/shoes、を指す）を追加したところ、3か月後にはインデックス率が81%に向上し、対応する商品の自然検索トラフィックが17%増加しました。
「重複の削除」ではなく「権威あるバージョンの指定」
多くのウェブマスターはcanonicalタグの理解に誤解があり、それを「重複ページを削除するためのもの」と考えています。
実際、その核となる機能は、「同じコンテンツを表示する複数のURLの中で、検索エンジンが優先的にクロール、インデックス、およびランキングの評価を与えるべきバージョンはどれか」を教えることです。
あるページの<head>部分に以下のコードを追加する場合：
<link rel=“canonical” href=“https://example.com/正規URL” />
あなたは検索エンジンに明確なシグナルを送っています。「このページ（例：パラメーター付きの/article?source=email）からもコンテンツにアクセスできるが、その評価とランキングの機会を、https://example.com/正規URLというアドレスに集中させてほしい」と。
Googleの公式ドキュメントと実際のクロールデータ観察に基づくと：
- クロール面：検索エンジンは引き続きすべてのバージョン（パラメーター付き、ディレクトリ付きのURLを含む）をクロールしますが、canonicalタグを参照してこれらのページへの「重視の度合い」を調整します。例えば、パラメーター付きのURLはクロールされるかもしれませんが、クローラーは正規バージョンほど頻繁に再訪問したり、深くインデックスしたりはしません。
- インデックス面：複数のURLのコンテンツが非常に類似している（重複率が80%を超える）場合、検索エンジンは通常、正規バージョンをインデックスに含め、他のバージョンは個別にインデックスされないか、インデックスされてもコアなランキング競争に参加しない可能性があります。
- 評価面：外部リンクが重複バージョンのいずれかのURLを指している場合、検索エンジンはcanonicalタグの指示に従って、その外部リンクの評価を正規バージョンに「転送」または「関連付け」ます（100%完全に転送されるわけではありませんが、ほとんどの状況で効果は近似します）。
具体的な例を挙げます。あるブログサイトの記事が「トップページ推奨」と「技術コラム」の2つのセクションに同時に公開され、2つのURLが生成されました。
https://example.com/home/recommend/123（トップページ推奨エントリ）https://example.com/tech/article/123（技術コラムエントリ）
両者のコンテンツは完全に一致していますが、トップページ推奨のURLはトラフィックが大きいため、いくつかの外部リンクを引き付けました。
canonicalタグがない場合、検索エンジンはこれら2つのページを独立したコンテンツとして扱う可能性があり、トップページ推奨のURLには外部リンクがあるものの、セクションの目的が垂直的でないため（トップページ推奨は通常、総合的なコンテンツです）、技術コラムほどのランキングポテンシャルはないかもしれません。
技術チームが両方のページにcanonicalタグを追加し、コンテンツのテーマに適合するhttps://example.com/tech/article/123を指すようにした場合、検索エンジンは明確に「このコンテンツの権威あるバージョンは技術コラムのURLである」と認識し、トップページ推奨の外部リンク評価も関連付け、そのページの「技術関連キーワード」におけるランキング競争力を向上させます。
Canonicalタグを使用しないとどうなるか
クローラーのクロール予算が無駄になる
検索エンジンが各ウェブサイトに割り当てる「1日のクロール回数」は限られています（「クロール予算」と呼ばれます）。重要なページ（トップページ、更新頻度の高いコンテンツページなど）のクロールが優先されます。
サイトに大量の重複URLがある場合（例えば、Eコマースサイトの商品詳細ページに10種類のソートパラメーターがあり、1000以上の異なるURLが生成される）、クローラーはこれらの「コンテンツは同じだがURLが異なる」ページに予算の一部を費やし、本当にクロールされるべき新しいページ（新しく出品された商品、更新されたニュースなど）のクロール頻度が低下します。
データによると、あるアパレルEコマースサイトのクローラーログ分析では、パラメーター付きの重複商品ページ（例：?size=M、?color=blue）が総クロール量の22%を占めており、これらのページの離脱率は85%にも上っていました（ユーザーが検索しているのは具体的な商品であり、パラメーター付きのURLから流入することはありません）。
このサイトが商品詳細ページに統一してcanonicalタグ（パラメーターなしの基本URLを指す）を追加した後、コア商品ページへのクローラーのクロール頻度が30%向上し、新しく出品された商品のインデックスにかかる時間が平均7日から3日に短縮されました。
インデックスバージョンの混乱、ランキングの不安定化
正規の識別子がない場合、検索エンジンはランダムに1つのURLを「デフォルト表示バージョン」として選択する可能性がありますが、この選択は固定されていません。
例えば、ユーザーが特定のキーワードを検索した際、www付きのバージョン（https://www.example.com/page）が表示されたり、wwwなしのバージョン（https://example.com/page）が表示されたり、あるいはパラメーター付きのバージョン（https://example.com/page?from=social）が表示されることがあります。
事例：ある地域サービスサイトの「お問い合わせ」ページには、https://example.com/contactとhttps://example.com/contact-usの2つのバージョンが同時に存在し（内容は完全に一致）、canonicalタグは設定されていませんでした。Googleは異なる期間にこれら2つのURLを個別にインデックスし、「XX市の修理サービス連絡先」を検索したユーザーが、ある時は最初のバージョンが上位に、別の時は2番目のバージョンが表示されるという状況になりました。
ユーザーがクリックした後、主要なバージョンではない方（例：contact-us）に入った場合、ページナビゲーションの設計の違い（例：オンライン予約ボタンがないなど）により、コンバージョン率が低下する可能性があります。
その後、このサイトは両方のバージョンにcanonicalタグを追加し、https://example.com/contactを指すようにしたところ、3か月後にそのページのランキングが向上し、検索クリック率（CTR）が11%増加しました。
外部リンクの評価分散
複数の重複バージョンのURLが外部サイトからリンクされている場合（例えば、誰かがコンテンツを転載する際にパラメーター付きのURLを使用したり、セクションページへの配信時に新しいリンクが生成されたりする）、これらの外部リンクが異なるアドレスに分散していると、検索エンジンは自動的に評価を統合できません。
データ比較：ある教育系サイトの「大学院入試攻略法」の記事が5つの外部サイトで転載され、そのうち3つはパラメーターなしのバージョン（https://example.com/guide/kaoyan）に、2つはパラメーター付きのバージョン（https://example.com/guide/kaoyan?from=partner）にリンクしていました。
canonicalタグが設定されていない場合、検索エンジンはこれら5つの外部リンクを別々のURLに関連付けます。このサイトがすべてのバージョンにcanonicalタグ（パラメーターなしのバージョンを指す）を追加した後、6か月以内にそのページの自然検索トラフィックが24%増加しました。
canonicalタグの基本的な構文と記述方法
約32%のページがcanonicalタグを<body>部分（必須の<head>領域ではなく）に配置しており、19%がhref属性値に完全なプロトコルを欠いており（例：https://example.comではなくexample.comとだけ書かれている）、また15%のページが複数の重複URLで異なる「正規バージョン」を指していました（検索エンジンの混乱を招く）。
技術的な実装から見ると、canonicalタグは本質的にシンプルなHTMLリンクタグですが、タグの位置（<head>内に必須）、構文形式（HTML仕様に厳密に従う）、指すURL（実際のコンテンツに完全に一致し、アクセス可能である必要がある）が重要です。
データによると、canonicalタグが標準的な記述法に従ってデプロイされている場合（つまり、<head>のトップに配置され、完全なHTTPSプロトコルを使用し、一意かつ正しい正規URLを指している場合）、検索エンジンがそのタグを正しく識別し適用する確率は95%を超えます。
一方、記述が間違っているページでは、約60%の正規化意図が検索エンジンに採用されず、重複コンテンツの問題が依然として存在していました。
例えば、あるEコマースサイトが商品詳細ページ（例：パラメーター付きの?color=redバージョン）にcanonicalタグを追加する際、プロトコルヘッダーを書き忘れた（//example.com/product または example.com/product と書いた）ため、GoogleがターゲットURLを正しく解析できませんでした。
標準的な構文構造
canonicalタグの完全な構文は一行のHTMLコードのみです：<link rel=“canonical” href=“https://www.example.com/正規ページの完全なURL” />
この行のコードは3つのコア要素で構成されており、どれも欠かせず、順番も固定されています。
タグの種類：<link>
- これはHTMLでドキュメントと外部リソースとの関係を定義するために使用されるタグで、canonicalタグは「リンク関係」の一種であり、
<link>を基本構造として使用する必要があります。
属性：rel="canonical"
relは<link>タグの必須属性であり、現在のリンクと現在のドキュメントの関係を説明するために使用されます。その値がcanonicalに設定されている場合、検索エンジンに明確に「このタグは現在のページコンテンツの正規（権威ある）バージョンを定義している」と伝えます。
属性：href="URL"
hrefは<link>タグのもう一つの必須属性であり、正規バージョンの具体的なウェブアドレスを指定するために使用されます。このURLは完全でアクセス可能である必要があり、プロトコル（httpまたはhttps）、ドメイン（wwwまたは非www）、パス、およびパラメーター（必要な場合）を含める必要があります。
例：
- 正しい記述：
href="https://www.example.com/products/shoes" - 間違った記述1（プロトコル欠落）：
href="//www.example.com/products/shoes"（ブラウザは自動補完するかもしれませんが、検索エンジンは正確に解析できない可能性があります） - 間違った記述2（ドメイン欠落）：
href="/products/shoes"（相対パスであり、検索エンジンはどのサイトのページか特定できません） - 間違った記述3（スペルミス）：
href="https://www.exaple.com/products/shoes"（ドメインのスペルが間違っており、存在しないページを指します）
その他の詳細：
- このタグは
/で終わる必要があります（URL自体が末尾スラッシュを必要とする場合）、ただしほとんどの場合、現代の検索エンジンはスラッシュの有無に対する許容度が高くなっています（正規化が統一されていれば問題ありません）。 - タグは1行で記述する必要があります（改行すると一部の解析ツールでエラーが発生する可能性がありますが、検索エンジンは通常自動的に修復できます）。
- タグの閉じ部分は
/>です（自己閉鎖タグ、HTML5規格では最後の/の省略が許可されていますが、互換性のために保持することをお勧めします）。
なぜ<head>内に必須なのか
検索エンジンのクローラープログラムがページをクロールする際、<head>領域の内容（特にメタ情報、タイトル、正規タグなどの「制御命令」）を優先的に解析し、その後で<body>内の実際のコンテンツを処理するからです。
canonicalタグが誤って<body>内に配置された場合（例えば、記事の段落やフッターコードにネストされている場合）、検索エンジンは<body>内の<link rel="canonical">タグを直接無視します。
その他の補足：
- 1つのページにはcanonicalタグは1つしか存在できません（複数出現した場合、検索エンジンは通常最初のものだけを識別し、残りは無視されます）。
- このタグは他のタグ内にネストすることはできません（例えば、
<div>や<script>内には配置できません）。 - 動的に生成されるページ（PHP、Pythonなどのバックエンド言語を介して出力されるページなど）については、テンプレートエンジンがHTMLを出力する際に、canonicalタグが
<head>領域に正しく挿入されていることを確認する必要があります（通常、テンプレート変数によって制御されます）。
最も一般的な5つのエラー
エラー1：間違ったURLを指している（正規バージョンが実際のニーズと一致しない）
- 現象：canonicalタグがコンテンツが完全に一致しない（またはまったく同じコンテンツではない）URLを指している。例えば、商品詳細ページ（赤い靴を表示）のcanonicalが白い靴のページを指している。
- 結果：検索エンジンは誤った指示に従って無関係のページに評価を集中させ、コアコンテンツのランキングが低下します。
- 修正：現在のページの実際のコンテンツを確認し、href内のURLが「完全に同じコンテンツを表示する」正規バージョンを指していることを確認します（例えば、パラメーターなしの基本URL、またはユーザーの検索意図に最も合致するセクションページに統一します）。
エラー2：プロトコルヘッダーの欠落（ドメインのみを記述、または相対パスを使用）
- 現象：コードが
href="//example.com/page"（プロトコル相対パス）またはhref="/page"（相対パス）と記述されている。 - 結果：検索エンジンはターゲットURLの完全なアドレスを正確に解析できない可能性があり（特にプロトコルやドメインをまたぐ場合）、正規化の意図が無効になります。
- 修正：常に完全なプロトコル+ドメイン+パスを使用し、形式は
href="https://www.example.com/page"（セキュリティのためにhttpsプロトコルを推奨）とします。
エラー3：パラメーター付きURLと正規バージョンとの競合
- 現象：商品一覧ページのパラメーターなしバージョン（
https://example.com/products）が正規バージョンであるが、パラメーター付きバージョン（例：https://example.com/products?sort=price）がそれを正しく指しておらず、代わりに別のパラメーター付きのURL（例：?sort=date）を指している。 - 結果：複数のパラメーターバージョンが互いに異なるURLを指し合い、「循環正規化」または評価分散を形成します。
- 修正：すべてのパラメーター付きURLのcanonicalがパラメーターなしの基本バージョン（または最も頻繁に使用されるソート/フィルターバージョン）を指すように統一し、すべてのバリエーションバージョンが同じ正規アドレスを指すようにします。
エラー4：タグが<body>内に配置されている
- 現象：CMSのバックエンドでページを編集する際、canonicalコードをサイトテンプレートの
<head>領域ではなく、誤って記事コンテンツ領域（<body>部分）に貼り付けてしまった。 - 結果：検索エンジンクローラーがそのタグを無視する可能性があり、重複ページが正しく正規化されないままになります。
- 修正：技術チームにテンプレートファイル（WordPressのheader.php、Shopifyのtheme.liquidなど）をチェックさせ、canonicalタグがHTMLの
<head>タグ内に出力されていることを確認します。
エラー5：複数のcanonicalタグの重ね合わせ
- 現象：テンプレートエラーまたは手動追加により、1つのページに複数の
<link rel="canonical">タグが出現した（例：/page と /page/ の両方を指している）。 - 結果：検索エンジンは通常、最初のタグのみを識別し、後続のタグは無視されるため、正規化の意図が混乱する可能性があります。
- 修正：コードをチェックし、余分なcanonicalタグを削除し、各ページに1つの正規化指示のみが存在することを確認します。
canonicalとその他のタグ（noindex、301リダイレクトなど）の違い
canonicalタグは「同一コンテンツの権威あるバージョンの指定」（すべてのURLを保持しつつ評価を集中）であり、noindexタグは「検索エンジンの現在のページのインデックスを禁止」（クロールは許可するが検索結果には表示しない）であり、301リダイレクトは「古いURLから新しいURLへの恒久的な転送」（トラフィックと評価を完全に移行）です。
正規化、禁止、転送の本質的な違い
canonicalタグ（正規化タグ）：は「同一コンテンツの複数URLのシナリオ」に使用され、検索エンジンに「これらのページコンテンツは実際には同じだが、私が指定したこのURL（正規バージョン）にのみ注目し、評価をここに集中させてほしい」と伝えることが目的です。
- 典型的なシナリオ：パラメーター付きのEコマース商品詳細ページ（例：?color=red と ?color=blue）、複数のセクションに配信されたニュース記事（例：「最新ニュース」と「業界動向」）、モバイル版とPC版でURLが異なるがコンテンツが一致している場合。
noindexタグ（インデックス禁止タグ）：は「クロールは許可するが検索結果への表示は禁止するシナリオ」に使用され、検索エンジンに「このページはクロールしても構わないが、検索結果のインデックスには含めないでほしい」と伝えます。
- 典型的なシナリオ：内部管理ページ（例：ログインページ、バックエンド統計ページ）、一時的なイベントページ（イベント終了後にランキングを保持する必要がない）、価値の低いコンテンツページ（例：印刷バージョン、繁体字/簡体字変換ページ）。
301リダイレクト（恒久的な転送）：は「コンテンツが恒久的に移行したシナリオ」に使用され、サーバー設定（例：.htaccessファイルやNginxルール）を介して、ユーザーと検索エンジンを古いURLから新しいURLに自動的に転送します。古いURLの評価（ランキング、外部リンク、ユーザー信頼度を含む）は新しいURLに徐々に移行し、最終的に古いURLはアクセスされなくなる可能性があります（ただし、転送は引き続き有効です）。
- 典型的なシナリオ：ウェブサイトのドメイン変更（例：example.comからnewexample.comへの移行）、URL構造の調整（例：/old-product/を/products/new-product/に変更）、複数の古いページを1つの新しいページに統合。
| ツール | クロールを許可するか | インデックスを許可するか | URLを変更するか | 核となる目的 |
|---|---|---|---|---|
| canonical | ✅ 許可 | ❌ インデックスしないことを推奨（ただしインデックスされる可能性あり） | ❌ 変更しない | 複数の同一コンテンツの評価を正規バージョンに集中させる |
| noindex | ✅ 許可 | ❌ 禁止 | ❌ 変更しない | ページが検索結果に表示されるのを阻止する |
| 301リダイレクト | ❌ 自動転送 | ❌ 古いURLはインデックスされない | ✅ 新しいURLに転送する | 古いURLの評価とトラフィックを新しいアドレスに移行する |
4つの一般的なシナリオで用法を比較
シナリオ1：同一コンテンツに複数のURLがある（例：パラメーター付きの商品ページ）
- 問題：商品詳細ページに
https://example.com/productとhttps://example.com/product?color=redの両方からアクセスでき、コンテンツは完全に一致している。 - 正しいツール：canonical。パラメーター付きのURL（
?color=red）にcanonicalタグを追加し、パラメーターなしの基本URL（https://example.com/product）を指すようにすることで、検索エンジンに「このコンテンツの権威あるバージョンはパラメーターなしのページである」と伝えます。 - noindex/301を選ばない理由：noindexはパラメーター付きのページをインデックスさせないようにしますが（ただしクロールされる可能性はあります）、ユーザーはそのリンクから流入する可能性があり、検索エンジンは依然としてどちらが主要バージョンかを判断する必要があります。301リダイレクトはユーザーとクローラーを強制的に転送する必要がありますが、ユーザーは異なるパラメーターを介してアクセスする必要がある場合があり（例：異なる色を比較するため）、強制的な転送には適していません。
シナリオ2：ページが検索結果に表示される必要がなくなった（例：期限切れのイベントページ）
- 問題：あるプロモーションイベントページ（
https://example.com/promo）は終了したが、ユーザーがブックマークや外部リンクを通じてアクセスする可能性があり、ランキングは必要ない。 - 正しいツール：noindex。イベントページの
<head>に<meta name="robots" content="noindex">タグを追加し（またはCMSを通じて設定）、検索エンジンにページをクロールすることは許可するが（例えばイベント記録を確認するため）、インデックスには含めないようにします。 - canonical/301を選ばない理由：canonicalは「ページを検索結果に表示させない」という問題を解決できません（それは評価を集中させるだけです）。301リダイレクトは新しいURLを指定する必要がありますが（イベントページに対応する新しいアドレスがない）、ユーザーは履歴情報を確認するために元のページにアクセスする必要があるかもしれません。
シナリオ3：ウェブサイトのドメイン変更またはURL構造の調整（例：古い製品ページの移行）
- 問題：古い製品ページ（
https://old.example.com/item1）が恒久的に新しいアドレス（https://new.example.com/products/item1）に移行し、元の外部リンク評価とユーザーのアクセス習慣を保持する必要がある。 - 正しいツール：301リダイレクト。サーバー設定（例えばApacheの.htaccessファイル）を通じて、ユーザーまたはクローラーが古いURLにアクセスした際に自動的に新しいURLに転送されるように設定します。古いURLのランキング、外部リンク評価は新しいURLに徐々に（通常は数週間から数か月）移行します。
- canonical/noindexを選ばない理由：canonicalはトラフィックの転送を実現できません（ユーザーは古いURLにとどまります）。noindexは古いURLをインデックスさせないようにしますが、外部リンク評価は転送されず、ユーザーは古いリンクから新しいコンテンツにアクセスできません。
シナリオ4：モバイル版とPC版のURLが独立している（例：m.example.com と www.example.com）
- 問題：同一コンテンツがモバイル版（
https://m.example.com/page）とPC版（https://www.example.com/page）で独立したURLを持ち、コンテンツは完全に一致している。 - 正しいツール：canonical（PC版URLを指す）を優先するか、レスポンシブデザインでURLを統一します。モバイル版が必須のエントリポイントである場合（例えば、ユーザーがm.example.com経由でアクセスする習慣がある）、モバイル版ページにcanonicalタグを追加してPC版の正規URLを指すようにし、同時に301リダイレクトで一部の古いモバイル版リンクをPC版に転送します（オプション）。
- noindexを選ばない理由：noindexはモバイル版またはPC版のどちらかのバージョンをインデックスさせないようにし、一部のユーザーの検索ニーズが満たされない可能性があり（例えば、モバイルユーザーが適合したコンテンツを検索時に見られない）。
コードの記述方法と、効果のロジックの違い
canonicalタグ：HTMLコード、検索エンジンの解析に依存
- コードの記述：正規化が必要なページの
<head>部分に<link rel="canonical" href="https://規範URL" />を追加します（前述の章で説明）。
効果のロジック：検索エンジンがページをクロールする際、このタグを読み取り、「このページの正規バージョンはXXXである」と記録し、その後のランキング計算や評価割り当てにおいて正規バージョンを優先的に考慮します。ただし、他のバージョンのページも引き続きクロールされる可能性があります（他の制限がない限り）。
noindexタグ：HTMLメタタグまたはHTTPレスポンスヘッダー、クローラーのルール遵守に依存
- コードの記述：通常、ページの
<head>内に<meta name="robots" content="noindex">を追加します（ほとんどの状況に適用）、またはサーバーを介してHTTPレスポンスヘッダーX-Robots-Tag: noindexを返します（動的ページに適用）。
効果のロジック：検索エンジンはページをクロールする際にこの指示を検出し、ページがnoindexの条件を満たしていることを確認した場合（例えばスパムページではない）、インデックスには追加しません。ただし、ページは依然としてクロールされます（robots.txtでクロールをブロックしない限り）、ユーザーは直接リンクを介してアクセスできます。
301リダイレクト：サーバー設定、強制的なトラフィック転送
コードの記述：サーバー技術を介して実装されます。例えば：
- Apacheサーバー：.htaccessファイルに
Redirect 301 /old-page https://example.com/new-pageを追加。 - Nginxサーバー：設定ファイルに
return 301 https://example.com/new-page;を追加。 - CMSシステム（WordPressなど）：プラグイン（例：Redirection）を通じて転送ルールを設定。
効果のロジック：ユーザーまたは検索エンジンが古いURLにアクセスすると、サーバーは自動的に301ステータスコードを返し、新しいURLに転送し、ブラウザのアドレスバーには新しいアドレスが表示されます。古いURLの評価は新しいURLに徐々に（通常は数週間から数か月）転送され、最終的に古いURLは直接アクセスされなくなる可能性があります（ただし、転送機能は保持されます）。
