例えば、言語コードの形式エラーやリンクパスの不完全さなどの細かい問題があると、検索エンジンがページの対応言語や地域を正しく認識できなくなる可能性があります。多言語ページ同士でトラフィックを奪い合い、ターゲットユーザーを逃すことさえあります。
本記事は技術的な実践の視点から、最もよくあるhreflang設定ミス7つをまとめています。ツールを使って定期的に検証し、小さなミスが全体の最適化効果を損なわないようにすることをおすすめします。
言語または地域コードの形式エラー
例えば、大文字を使う（例：EN-US）や、スペルミス（例：zh-CNをzh-CHと記述）すると、検索エンジンがページの対象地域を正しく解析できず、無効なタグと誤認されることがあります。
コードが一見正しく見えても（例：es-ESではなくesを使うべき）、余計な情報がマッチングロジックを混乱させる場合があります。
影響は大きく、例えばスペインのユーザーの検索トラフィックが誤ってポルトガル語ページに割り振られる可能性があります。
ISO標準コードルール
hreflangコードは「言語」と「地域」の2つの部分から成り、ISO標準を厳守する必要があります：
- 言語コード：ISO 639-1標準の小文字2文字の略語を使用（例：
en、es、zh）。 - 地域コード：省略可。ISO 3166-1標準の大文字2文字の国・地域コードを使用（例：
US、GB、CN）。 - 組み合わせ形式：言語と地域の間はハイフンで区切る（例：
en-US（アメリカ英語）、zh-CN（簡体字中国語））。
例外事項：
- 言語コードのみの場合（例：
fr）は、その言語を話す全ユーザーを対象とし、地域は限定しません。 - 繁体字中国語は
zh-Hant（繁体字中国語）またはzh-Hant-TW（台湾の繁体字）を使い、zh-TWは台湾の簡体字と誤解される恐れがあります。
典型的な誤りのケースと結果
誤り1：大文字・小文字の混同
- 誤例：
EN-us（言語コード大文字+地域コード小文字）、Zh-cn（言語の頭文字大文字）。 - 結果：検索エンジンがこのタグを完全に無視し、ページがターゲットユーザーと一致しなくなる可能性があります。
誤り2：スペルミスや架空コード
- 誤例：
pt-BZ（ブラジルの正しいコードはBR）、eu（バスク語。小規模言語は一部エンジンでサポートされない場合あり）。 - 結果：ニッチな言語や間違った地域コードはページの正しいインデックスを妨げ、トラフィックがデフォルト言語ページに流れることになります。
誤り3：冗長なコードや不正な組み合わせ
- 誤例：
es-ES（スペイン語+スペイン地域、実際にはesのみで十分）、en-US-UK（無効な複数地域の連結）。 - 結果：冗長な情報がエンジンを混乱させ、よりシンプルな競合ページが優先されます。
おすすめツールと検証方法
- Google hreflangテストツール：URLを入力してタグが正しく解析されるかチェック（Search Consoleと併用推奨）。
- Screaming Frog：サイトクロール時にhreflangタグを抽出し、一括でエラーコードをエクスポート可能（有料版）。
- Hreflang Validator（サードパーティツール）：無料オンライン検査で形式エラーやリンクの競合を示します。
実践的な修正ステップ
既存コードのチェック：WordPressサイトの場合、プラグイン（例：Yoast SEO）やページソースで<link rel="alternate" hreflang="..." />タグを確認します。
誤ったコードの一括置換：
- 多言語プラグイン（WPMLなど）を使用している場合は、言語設定で「言語コード」の形式を直接修正してください。
- 手動で修正する場合は、すべてのページで統一した形式にしてください（例：全体的に
ENをenに置換）。
地域コードの追加（任意）：
- 地域を細分化する必要がある場合のみ追加してください（例：
en-GBは英国ユーザー向け）。それ以外の場合は、言語コードのみを保持してください（例：fr）。
再検証：ツールを使って再チェックし、修正後のページが200ステータスコードを返し、クロールエラーがないことを確認してください。
完全な絶対URLを使用していない
多くのサイト運営者は、相対パス（例：/de/page）やプロトコル省略（例：example.com/de）で設定を簡略化できると思い込んでいますが、実際には深刻な問題を引き起こします。
例えば、ページにhttp版とhttps版が存在する場合、プロトコルを省略すると検索エンジンがそれらを別のページとして誤認し、評価が分散されてしまいます。
また、サブドメインやサブディレクトリ構造のサイトで完全なURLを統一していないと、パスの曖昧さによりタグが機能しなくなる場合があります（例：モバイルとPCのURLが混在している場合）。
絶対URLの定義と必要性
絶対URLは、プロトコル（http://またはhttps://）、完全なドメイン名、およびパスを含む必要があります（例：https://www.example.com/de/page）。
必要性：
- 検索エンジンは異なるページを明確に区別する必要があります。相対パス（例：
/de/page）は現在のドメインのどのバージョン（httpまたはhttps）かを曖昧にし、重複コンテンツの原因になります。 - サブドメインやサブディレクトリを跨ぐ場合、完全なURLを記載しないと検索エンジンがページの所属を誤認することがあります（例：
de.example.com/pageとwww.example.com/de/pageが別ページとみなされる）。
典型的な問題シナリオ：
- ページに
http版とhttps版が同時に存在するが、hreflangタグにプロトコルが記載されておらず、評価が分散してしまう。 - モバイルとPCで同じコンテンツを使用しているが、URL構造が異なる（例：
m.example.com/deとexample.com/de）にもかかわらず、絶対URLで関連付けていない。
よくある誤りのシナリオと結果
誤り1：相対パスやプロトコルの省略
誤りの例：
<link hreflang="de" href="/de/page" />（相対パス）<link hreflang="es" href="www.example.com/es/page" />（https://がない）
結果：
- 検索エンジンは
/de/pageをhttp://example.com/de/pageと解釈することがあり、実際はhttps版であるためタグが機能しない。 - 異なるプロトコル（HTTP/HTTPS）のページが別のエンティティとして扱われ、コンテンツの重複と評価の分散が発生する。
誤り2：サブドメイン間の統一がない
- 誤りの例：メインサイトは
https://example.com/fr/pageを使用しているが、フランス語のサブサイトはhttps://fr.example.com/pageで、hreflangが互いに絶対URLで指していません。 - 影響：検索エンジンがサブドメインとメインサイトのページの関連付けを行えず、フランス語ユーザーがデフォルト言語のページに誘導される可能性があります。
エラー3：動的パラメータの非標準化
- エラー例：
<link hreflang="ja" href="https://example.com/page?lang=ja" />（トラッキングパラメータを含む） - 影響：パラメータが検索エンジンによって異なるページとみなされる可能性があります（例：
?lang=jaと?lang=ja&utm=ads）、結果としてタグのカバレッジが不完全になります。
ツールによる検出方法
- Google Search Console：
「カバレッジレポート」で「重複ページ」や「hreflang未設定」によるエラーを確認し、不完全なURLを特定します。 - Screaming Frog：
サイトをクロールした後、hreflangタグをフィルタリングし、すべてのhref属性が絶対URLかどうかを確認します（フィルタ条件：//example.comまたは/path）。 - Sitebulb：
「国際SEO監査」レポートで「不完全なhreflang URL」として直接表示し、修正提案を提示します。
修正方法と実践手順
CMSシステム（例：WordPress）：
プラグイン設定：
Yoast SEOなどのプラグインを使用している場合、「多言語設定」で「絶対URLを生成する」を強制有効にします（通常は「相対パス」オプションをオフにする必要があります）。
データベース一括置換：
SQLコマンドやBetter Search Replaceなどのプラグインを使い、href="/をhref="https://www.example.com/に置換します。
手動コード修正：
HTMLまたはサーバー側のレンダリングロジックで、すべてのhreflangリンクを完全な形式に組み立てるようにします。例：
サーバー設定：
- プロトコルの統一を強制：
.htaccessやNginx設定でhttpを自動的にhttpsにリダイレクトし、混合コンテンツを防ぎます。 - URLの正規化：同じコンテンツの異なるパス（例：
/deと/de/）に301リダイレクトを追加し、一意の絶対URLを保証します。
自己参照hreflangタグの欠如
例えば、フランス語ページが英語やスペイン語など他の言語版へのリンクだけを示し、hreflang="fr"で自身を指していない場合
検索エンジンはページの言語所属を特定できず、フランス語ユーザーの検索結果に正しく分類されない可能性があります。
自己参照タグの役割と必要性
自己参照タグとは、ページ内で自身を指すhreflang宣言のことです（例：フランス語ページは<link rel="alternate" hreflang="fr" href="自身のURL"/>を含む）。
主な役割：
- 検索エンジンに対して現在のページの言語・地域の所属を明確に示し、誤認を防止します。
- 他の言語版と閉ループの関連付けを形成し（すべてのページが互いに宣言）、正しい評価の伝達を保証します。
欠落した場合の影響：
- 検索エンジンはページを「言語未指定」とみなし、デフォルトの言語ディレクトリに割り当てることがあり、ターゲットユーザーからのトラフィックが減少する可能性があります。
- 多言語が競合する状況（例えば、英語ページとスペイン語ページの両方で自己参照がない場合）では、内部の重複コンテンツ問題を引き起こすことがあります。
よくある間違いとケース分析
間違い1：単一言語サイトでのhreflangの誤用
- 状況：言語バージョンが一つしかないページに、存在しない他言語ページを指すhreflangを無理に追加している場合。
- 具体例：英語のみのサイトのページで、自分自身を指す
hreflang="en"を追加しつつ、存在しないhreflang="es"ページに誤ってリンクしており、検索エンジンが混乱する。
間違い2：多言語プラグインの設定漏れ
- 例：WPMLプラグイン使用時に「自己参照hreflangを自動生成する」オプションを選択していない場合。
- 結果：生成されるタグに現在のページの宣言がなく、他言語バージョンのリンクのみが含まれる。
間違い3：動的ページでの完全なタグ未挿入
- 例：ReactやVueのようなJavaScriptレンダリングページで、hreflangタグが正しく内に挿入されていない場合。
- 影響：検索エンジンのクローラーが動的に生成された自己参照タグを認識できない可能性がある。
検証ツールと方法
ステップ1：手動でソースコード確認
- ページで
Ctrl+Uを押してソースを表示し、hreflang="xx"を検索。現在のURLを指すタグがあるか確認（xxは現在ページの言語コード）。
ステップ2：Googleサーチコンソールで確認
- 「URL検査ツール」にページURLを入力し、「国際ターゲティング」レポートを確認。「自己参照hreflangタグが検出されません」と表示された場合は問題あり。
ステップ3：Hreflang Validatorツールの使用
- ページURLを入力すると、関連するhreflangリンク一覧が表示され、自己参照タグが欠落している場合は赤い警告が表示される。
修正方法と実践ステップ
CMSでの修正（WordPressを例に）：
プラグイン設定の修正：
- Yoast SEOを使っている場合：「高度な設定」で「自己参照hreflangを追加」を有効化。
- WPMLを使っている場合：「言語設定」→「SEOオプション」で「自己リンクを含める」をチェック。
手動修正（静的サイトやカスタムコードの場合）：
ページの<head>内に以下のコードを追加（フランス語ページの例）：
動的レンダリングページの修正（例：React）：
サーバーサイドレンダリング（SSR）ロジックにおいて、現在のページ言語に応じて自己参照タグを動的に生成：
閉ループリンクの原則と必要性
hreflangの核心ルールはすべての関連ページが相互にリンクすることで、完全な閉ループを形成する必要がある。例えば：
- ドイツ語ページ（
de）は英語ページ（en）、フランス語ページ（fr）など他の言語版を指す必要がある； - 英語ページやフランス語ページもドイツ語ページを相互に指す必要がある。
必要性：
- 評価の伝達：閉ループリンクは検索エンジンに多言語ページが同等であることを理解させ、評価の分散を防ぐ。
- 重複コンテンツの防止：一方向リンク（例えば英語ページがドイツ語ページを指すが、ドイツ語ページが英語ページを指さない場合）は、検索エンジンがそれらを別々のコンテンツと認識し、重複コンテンツペナルティの対象となる可能性がある。
例外シナリオ：
- 単一言語ページ（例：英語のみ）は閉ループ不要だが、自己参照タグは必要。
- 地域変種（例：
en-USとen-GB）は相互にリンクするが、他言語にリンクする必要はない。
よくあるリンク切れのケースと影響
ケース1：新しい言語版を追加したが既存ページを更新しなかった
- 例：ニュースサイトで日本語ページ（
ja）を追加したが、既存の英語や中国語ページに日本語ページへのhreflangタグを追加しなかった。 - 影響：日本語ページが「孤立ページ」となり、検索エンジンは関連付けされていない他言語ページのみをインデックスする。
ケース2：CMSプラグインのロジック不具合
- 例：WordPressの多言語プラグイン（例：Polylang）がページの一括生成時に既存コンテンツに新しい言語リンクを自動追加しなかった。
- 影響：一部ページのリンクが切れ、ユーザーが既存コンテンツから新しい言語版に切り替えられなくなる。
ケース3：動的パラメータによるリンク不整合
- 例：スペイン語ページのURLにパラメータ（例：
?lang=es）が含まれているが、他言語ページのhreflangタグにそのパラメータが含まれていない。 - 影響：検索エンジンは
esパラメータ付きページを別のコンテンツと見なす。
検査ツールとトラブルシューティング方法
ツール1：Screaming Frog
- クロール結果の「Hreflang」タブで「Missing Reciprocal Links」（相互リンク欠如）をフィルター。
- 対応：エラーリストをエクスポートし、閉ループが形成されていないURLグループを特定。
ツール2：Sitebulb
- 「International SEO Audit」レポートで「Unreciprocated hreflang links」警告を確認し、リンク切れページと不足している言語を表示。
ツール3：DeepCrawl
- カスタムルールを設定し、多言語ページ間の関連性を監視、毎週リンク切れ問題の自動レポートを実施。
修正方法と実施ステップ
方法1：CMSプラグインで一括修正（Shopify例）
多言語プラグイン（例：Langify）の設定で「すべての言語バージョンを自動的にリンクする」オプションを有効化する。
「テンプレート設定」で、hreflangタグのロジックがすべての言語バージョンをループしていることを確認してください：
方法2：手動コード修正（静的サイト）
各言語バージョンごとに関連リスト（Excelなど）を作成し、相互にリンクする必要のあるURLグループをリストアップします。
ページにリストに従ってタグを追加します。例えば：
ドイツ語、フランス語ページも英語ページのリンクを含むように同期させてください。
方法3：サーバー側自動化（例：Nginx）
リバースプロキシとマッピングルールを使用して、hreflangタグを動的に生成します：
Canonicalタグとの競合
例えば、あるドイツ語の商品ページのCanonicalタグが英語のメインサイトページを指している場合、検索エンジンはそのドイツ語ページを英語ページのコピーとして認識し、ドイツ語ユーザーには配信しない可能性があります。
より一般的な問題は、多くのCMSシステムがすべての言語バージョンのCanonicalをメイン言語ページ（例：x-default）に統一してしまい、他の言語ページが独立してインデックスされないことです。
競合の仕組みと優先順位ルール
検索エンジンがhreflangとCanonicalタグを処理する際の優先順位：
Canonicalが優先：ページAのCanonicalがページBを指している場合、検索エンジンはAをBのコピーとみなし、Aのhreflang宣言を無視します。
hreflangが機能しなくなるシナリオ：
- フランス語ページのCanonicalが英語ページを指している → フランス語ページはフランス語ユーザーに配信されません。
- 多言語ページのCanonicalがすべてメインサイトを指している → すべての言語バージョンが重複コンテンツと見なされます。
例外ルール：
- Canonicalタグが自身を指している場合（例：
<link rel="canonical" href="現在のページURL"/>）、hreflangは正常に機能します。
典型的なエラーシナリオとその結果
エラー1：多言語プラグインのデフォルト設定の競合
- 事例：WordPressのYoast SEOプラグインは、多言語ページのCanonicalをデフォルトでメイン言語のページに設定します。例えば、ドイツ語ページのCanonicalタグが
<link rel="canonical" href="https://example.com/en/page"/>となっています。 - 結果：ドイツ語ページは英語ページのコピーとみなされ、ドイツ語の検索結果に表示されず、トラフィックが50％以上減少します。
エラー2：動的パラメータの干渉
- 事例：パラメータ付きのURL（例：
example.com/page?lang=de）のCanonicalがパラメータなしのバージョン（example.com/page）を指しているが、後者にはhreflangが設定されていません。 - 結果：パラメータ付きのドイツ語ページがインデックスされず、ユーザーは検索時にデフォルト言語のページのみを目にします。
エラー3：地域別バリエーションが独立して宣言されていない
- 事例：
en-USページのCanonicalが一般的な英語ページ（en）を指しており、検索エンジンが米国英語ページに独自の価値がないと判断します。 - 結果：米国のユーザーが
enページ（例えばイギリス英語）に誘導され、ローカライズされた体験が低下します。
検出ツールとトラブルシューティング方法
ツール1：Google Search Console
- 「カバレッジ」レポートに入り、「除外」タブの「重複ページ」または「送信されたがインデックス未登録」項目をフィルタリングして、Canonicalの競合によるhreflangの無効化を確認します。
ツール2：Screaming Frog
- サイトをクロール後、hreflangとCanonicalタグの両方があるページをフィルタリングし、Canonicalが自身のURLではなく他のページを指しているか確認します。
- データをエクスポートし、
Canonical != Self-URLの条件でフィルターします。
ツール3：DeepCrawl
- hreflangとCanonicalのターゲットが一致しない場合に警告を出すカスタムアラートルールを設定します。
修正案と実践ステップ
案1：CMSプラグインの修正（Yoast SEOの場合）
- 多言語設定に入り、「Canonicalをメイン言語に統一」オプションをオフにします。
- 「詳細設定」で「各言語バージョンに独立したCanonicalタグを生成」を有効にします。
案2：手動コード修正
ページの<head>内で、Canonicalタグが自身のURLを指すようにします。例：
案3：サーバー側設定（例：Nginx）
現在の言語バージョンに合わせてCanonicalタグを動的に生成：
サーバーエラーまたはHTTPリクエスト未対応
例えば、動的に生成されたページがサーバーのタイムアウトで完全なHTMLを読み込めず、<head>内のhreflangタグが欠落する場合があります。
また、モバイルページが200ではなく302の一時リダイレクトを返すと、検索エンジンがクロールをあきらめる可能性があります。
一部のCDNやファイアウォールルールがクローラーのリクエストをブロックし、特定地域の言語ページが読み取れなくなる場合もあります。
サーバーエラーの種類と影響
重要なステータスコードとその影響：
404 Not Found：
- シナリオ：フランス語ページが他の言語ページのhreflangによって参照されているが、実際のURLが削除されているかパスが間違っている。
- 結果：検索エンジンはhreflangの関連付けを無効と判断し、フランス語ページがインデックスされず、他の言語ページの信頼性も低下する。
500 Internal Error：
- シナリオ：サーバーのクラッシュにより、動的に生成されたhreflangタグが読み込まれない。
- 結果：ページは500エラーを返し、hreflangが完全に機能しなくなり、クローラーにより一時的にサイトがブロックされる可能性がある。
302 Temporary Redirect：
- シナリオ：モバイルページが一時的にデスクトップURLにリダイレクトされるが、hreflangタグが渡されない。
- 結果：検索エンジンはターゲットページ（デスクトップ）のhreflangのみをクロールし、モバイルの言語バージョンを無視する可能性がある。
動的ページの読み込み問題
JavaScriptレンダリングの欠陥：
- ケース：ReactやVueを使ったシングルページアプリケーション（SPA）で、hreflangタグがJSで動的に挿入されているがプリレンダリングされていない。
- 結果：検索エンジンのクローラーがJSを実行しない場合、hreflangタグが読み取れない。
CDN/キャッシュ設定の干渉：
- ケース：CDNのキャッシュ設定が
<head>内のhreflangを無視したり、誤った言語バージョンをキャッシュしている。 - 結果：同じURLにアクセスしても、CDNが異なる言語のキャッシュページを返し、hreflangの関連付けが混乱する。
サーバーのタイムアウトとパフォーマンス問題：
- ケース：ページの読み込み時間が5秒以上かかり、クローラーが途中でクロールを停止しhreflangタグを完全に読み取れない。
- 結果：特に大規模な多言語サイトで、一部の言語の関連付けが失われる。
検出ツールとトラブルシューティング方法
Google Search Console：
- 「カバレッジレポート」を使用し、サーバーエラー（404/500）で除外されたページを確認し、多言語版のURLをフィルタリングする。
Screaming Frog：
- クロール設定で「hreflangのチェック」オプションを有効にする。
- 結果を「サーバーエラー」（4xx、5xx）でフィルタリングし、hreflangに関連するページを確認する。
ログファイル解析：
- サーバーログ（例：Nginxのaccess.log）で検索エンジンクローラー（User-AgentにGooglebotを含む）のリクエストを抽出し、エラーが多発しているURLを特定する。
修正策と実践手順
サーバーエラーの修正：
404問題：
- hreflangでリンクされているすべてのURLが存在するか確認し、リンク切れを修正する。
- ページが削除されている場合、他の言語ページのhreflangからそのリンクを削除する。
500問題：
- サーバーリソース（メモリ追加やデータベース接続プールなど）を最適化し、クラッシュのリスクを減らす。
- New Relicなどの監視ツールを設定し、リアルタイムで問題を検出し修正する。
動的ページの最適化：
プリレンダリングの方法：
- Next.jsやNuxt.jsなどのSSR（サーバーサイドレンダリング）フレームワークを使い、hreflangタグを初回HTML読み込み時に含める。
- Prerender.ioなどのプリレンダリングツールを設定し、クローラーに静的バージョンを提供する。
CDN設定の修正：
- CDN設定で、
/de/、/fr/などの言語パスを「キャッシュなし」または短いキャッシュ期間（例：1時間）に設定する。 - CDNが
<head>の完全な内容を通過させ、HTMLタグの書き換えを禁止する。
パフォーマンスの最適化：
- 画像やCSS/JSなどのページリソースを圧縮し、読み込み時間を3秒以内に短縮する。
- Google Lighthouseなどのツールを使い、レンダリングを妨げる問題を検出・修正する。
動的パラメータによる重複コンテンツ
動的パラメータ（例：?utm_source=adsや?sessionid=123）の乱用は、多言語サイトにおける重複コンテンツ問題の“隠れた原因”です。
例えば、スペイン語ページがパラメータ違いで複数のURL（例：/es/page?ref=facebook、/es/page?ref=email）を持つ場合、検索エンジンはそれぞれを別ページとみなし、重複コンテンツとして扱います。
パラメータの種類の影響と分類
必ず残すべきパラメータ：
- ページネーションパラメータ（例：
?page=2）：異なるコンテンツブロックを区別するために使用されます。残す必要がありますが、正規化する必要があります（例：rel="canonical"でメインページを指す）。 - 言語/地域パラメータ（例：
?lang=de）：URLがパスで言語を区別していない場合（例：/de/）、これらのパラメータは残し、hreflangと一致させる必要があります。
必ず削除すべきパラメータ：
- トラッキングパラメータ（例：
?utm_source、?ref=social）：ページ内容を変更しないため、hreflangから除外する必要があります。 - セッションID（例：
?sessionid=123）：ユーザー行動追跡のためのパラメータで、重複URLが大量に発生しやすいです。
よくある間違いとその結果
間違い1：パラメータが正規化されていない
- 例：同じフランス語ページが複数のトラッキングパラメータ付きURLで存在する（例：
/fr/page?utm=adsと/fr/page?utm=email）、どちらもhreflangで独立したページとして宣言されている。 - 結果：検索エンジンが複数の重複バージョンをクロールし、評価が分散され、フランス語ページの順位が下がる。
間違い2：hreflangにパラメータが欠落している
- 例：英語ページのhreflangが
/de/pageを指しているが、実際のドイツ語URLは/de/page?lang=deで、関連付けが切れている。 - 結果：ドイツ語ページが独立したコンテンツと見なされ、英語ページと多言語関連付けができない。
間違い3：ページネーションパラメータがメインコンテンツに影響を与えている
- 例：製品リストページ
/es/products?page=2のhreflangがメインリストページ/es/productsを指していない。 - 結果：ページネーションページが独立した言語ページと誤解され、メインリストページとトラフィックを競合してしまう。
ツールによる検出方法
Google Search Console：
- 「カバレッジ」レポートに入り、「送信されたがインデックス未登録」のURLをフィルタリングし、パラメータによる重複排除が行われているか確認する。
Screaming Frog：
- サイトをクロールするときに「URLパラメータを無視」オプションを有効にし、パラメータあり・なしのページの内容類似度を比較する。
- hreflangタグをフィルターして、パラメータ付きURLの正規化不足を確認する。
正規表現マッチング：
- ログ解析ツール（例：ELKスタック）で正規表現を使い、特定パラメータ（例：
utm_*）を含むクローラーリクエストをフィルターし、重複クロール回数を統計する。
解決策と実務手順
解決策1：パラメータの正規化（サーバー設定）
Apacheルール例：
- 役割：すべての
utm_パラメータを自動的に削除し、パラメータなしURLへ301リダイレクトする。
解決策2：hreflangとCanonicalの連動
hreflangにはパラメータなしのURLのみを使用（例：/de/page）。
パラメータ付きURLにはcanonicalタグを追加し、パラメータなしのバージョンを指す：
解決策3：Google Search ConsoleでのURLパラメータ設定
- 「URLパラメータ」設定に入り、
utm_、sessionidなどのパラメータを「ページコンテンツに影響なし」とマークする。 - ページネーションパラメータ（例：
page）を「ページネーション」としてマークし、検索エンジンが役割を理解できるようにする。
多言語サイトのhreflang最適化は“一度設定したら終わり”ではありません。
細かい部分の改善は、こうした“見過ごされがちな”技術的ミスを避けることから始まります。
