--- title: 多言語WebサイトSEOとhreflangのベストプラクティス description: 重複コンテンツとクロール予算の浪費を避けるための、hreflang、URL構造、ローカライゼーション選択による多言語SEOの設定方法。 url: https://mighil.com/work/ja/blog/multilingual-website-seo-hreflang pubDate: 2026-09-25 updated: 2026-09-25 relatedService: website-internationalization --- # 多言語WebサイトSEOとhreflangのベストプラクティス 第二言語の出荷は勝ちに見えます。Search Consoleが「Incorrect return tags」で埋まり、Googleがドイツの買い物客に英語を出し続けるまでは。多言語SEOは文字列翻訳より、各市場に安定したURL、明確な言語またはロケールシグナル、そこで実際に買うものに合うコンテンツを与えることの方が中心です。 このガイドは、URL構造の選択、hreflangの仕組み（相互確認とx-default含む）、言語対ロケール、翻訳対ローカライゼーション、よくある失敗モード、クロール予算、CMSの罠、実践シナリオ、出荷チェックリストをカバーします。 ## 何も注釈する前にURL構造を選ぶ HreflangはURLを指すだけです。URLが乱雑、パラメータベース、半移行なら、注釈はプロジェクトを救えません。Googleの[多地域・多言語サイトの管理](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)指針が通常のパターンを示します。主要パターンを1つ選び、それに従います。 | パターン | 例 | 強み | コスト | | --- | --- | --- | --- | | ccTLD | `example.de`、`example.fr` | 強い国シグナル、ローカル信頼 | 別サイト、より多い運用、リンクエクイティ分割 | | サブドメイン | `de.example.com` | 明確な分離、柔軟なホスティング | ccTLDより弱い国シグナル | | サブディレクトリ | `example.com/de/` | 1ドメイン、共有権威、より単純なCMS | 国シグナルはコンテンツとhreflangに依存しやすい | 1ブランドドメインでまだ権威を築いている製品・コンテンツサイトの多くでは、サブディレクトリが勝ちます。ccTLDは、法人、価格、コンプライアンスが本当に国で違い、各サイトに人員を割けるときに意味があります。サブドメインは、例えば中国向けオリジンのように別スタックが必要で、すべてのTLDを買わない中間に座ります。 言語をクエリ文字列（`?lang=de`）にしない。それらのURLは重複しやすく、共有しにくく、アナリティクスに不便です。正しく注釈すればGoogleは理解できますが、パラメータロケールと暮らす運用者は、フィルターとキャンペーンが衝突するとき通常後悔します。 選んだパターンを、エンジニアと翻訳者が両方読む1か所に文書化します。後で`/de/`から`de.example.com`へ変えることは、フルリダイレクトマップとhreflang書き換えを意味します。その移行税が、最初の翻訳ページ出荷前にURL決定が属する理由です。 ![多言語サイト向けの3つのURLパターン：ccTLD、サブドメイン、サブディレクトリ](/work/assets/blog/hreflang-01-url-structures.webp) *図1：同じブランド向けのccTLD、サブドメイン、サブディレクトリレイアウトの並び。* ## hreflangが実際にどう動くか [Hreflang](https://developers.google.com/search/docs/specialty/international/localized-versions)は、指定した言語または言語−地域の組み合わせ向けの意図されたバージョンがどのURLかをGoogleに伝えます。それ自体でランキングは作りません。ほぼ一致するページが複数あるとき、Googleが正しい代替を選ぶ助けになり、そのドイツ語URLが英語の有効な代替なら、ドイツ語ユーザーがドイツ語URLを見る可能性が高まります。 Googleが文書化する宣言方法は3つ： 1. ページ``内のHTML `` 2. 非HTMLファイル（PDFなど）向けのHTTPヘッダー 3. 大規模カタログ向けのXMLサイトマップ注釈 ほとんどのマーケサイトはHTMLタグまたはサイトマップエントリを使います。大規模ECカタログはテンプレートを薄く保つためにサイトマップを好むことが多い。所与のURLセットに主要方法を1つ選び、一貫させる。同じページセットで部分HTMLと部分サイトマップ注釈を混ぜることは、ドリフトのよくある源です。 コードはGoogleが受け入れるBCP 47風の値に従います。`en`や`de`のような言語コード、任意で`en-GB`や`pt-BR`のような地域。ISO 639-1言語コードと、地域が要るときはISO 3166-1 Alpha 2国コードを使う。英国の英語に`uk`のような略語を発明しない（通常は`en-GB`）。地域のみのコードを使わない。 セット内の各ページは、自己参照エントリを含め、すべての代替を列挙すべきです。`https://example.com/pricing/`が英語で`https://example.com/de/pricing/`がドイツ語なら、両ページ（またはサイトマップ行）に、最終のインデックス可能なURLを指す`en`と`de`エントリが必要です。 ### 代替間の相互確認 Googleのローカライズ版ドキュメントは、注釈が相手側から確認されなければならないと明示しています。ページAがページBを`de`として指すなら、ページBはページAを`en`（またはAの言語）として戻さなければならない。片方向リンクはその関係では無視されます。 相互確認は、CMSが「主要」ロケールにだけタグを生成するとき、翻訳者が旧ページを更新せず新言語を公開するとき、またはCDNがライブページが動いたあとも古いheadをキャッシュするときに静かに失敗します。Search Consoleの国際ターゲティング／hreflangレポート（プロパティで利用可能な場合）と、`link[rel=alternate][hreflang]`を抽出するクロールの両方が、目視HTMLより速くこれを捉えます。 ![英語とドイツ語ページ間の相互hreflang矢印](/work/assets/blog/hreflang-02-reciprocal.webp) *図2：各代替は戻し指ししなければならない。片方向矢印は確認済みペアとして数えない。* ## x-defaultと一致しない訪問者 `x-default`は、他のhreflang値がユーザーの言語または地域設定と一致しないときに欲しいURLを印します。Googleは、一致しない言語のフォールバックとして同じ[ローカライズ版](https://developers.google.com/search/docs/specialty/international/localized-versions)ドキュメントで説明しています。 典型的な用途： - 言語選択またはグローバルゲートウェイページ - 別の選択ページを運用しないときの主要英語（または他のハブ）URL - 慎重に選んだ「その他世界」ストアフロント `x-default`は「英語を話す人のページ」ではありません。英語には依然として独自の`hreflang="en"`（または`en-US`、`en-GB`など）が必要です。正直なら`x-default`は`en`と同じURLを指せる。インデックス可能で有用な選択ページを指すこともできる。指すべきでないのはソフト404、落ち着かないgeo-IPリダイレクトの合間ページ、ランダムなブログ投稿です。 ユーザー（またはGooglebot）が安定URLを見る前にIPで自動リダイレクトすると、使いやすさとクロールの両方と戦います。Googleの多地域ガイダンスは、コンテンツ表示をIPだけに頼ることに注意します。ロケールごとの安定URLと見える言語スイッチャーを優先し、照合作業はhreflangに任せる。 ![en、de、frと一致しないときのフォールバックとしてのx-default](/work/assets/blog/hreflang-03-x-default.webp) *図3：x-defaultは注釈セット外の言語の訪問者を捉える。* ## 言語コード対ロケールコード `de`は国に関係なくドイツ語。`de-DE`はドイツで使われるドイツ語。`de-AT`はオーストリアで使われるドイツ語。通貨、配送、法務コピー、綴りが分かれるとき、これらは異なる意図です。 その言語の話者全員を1URLが正直に賄うなら言語のみコードを使う。言語文字列が同じに見えてもページが市場で違うなら言語−地域コードを使う。グローバル読者向けの単一英語ページはしばしば`en`＋`x-default`。価格と綴りが違うUKとUSの別ストアフロントは通常`en-GB`と`en-US`で、それぞれ独自URL。 旗アイコンとCDNエッジだけが違う`en-US`と`en-GB`の重複を作らない。Hreflangは意味のある差を発明できない。ページがほぼ同一なら統合するか、きちんとローカライズする。 スクリプトと地域の中国語には注意が必要。本土向け簡体字と台湾／香港向け繁体字は別の読み体験です。スクリプトを混ぜる1つの`zh`ページより、別URLと精密なコード（`zh-Hans`、`zh-Hant`、またはスタックが一貫して支える地域形）を優先。選んだら、HTML、サイトマップ、言語スイッチャーで同じコード族を保つ。 ![言語のみタグ対言語−地域ロケールタグ](/work/assets/blog/hreflang-04-lang-vs-locale.webp) *図4：言語コードは話者を広くカバー。ロケールコードはコンテンツが実際に違うとき市場を固定する。* ## 翻訳が終わりローカライゼーションが始まるところ USD、米配送マトリクス、米ケーススタディ、米法務フッターを残したまま語だけ入れ替える機械または人手翻訳は、hreflangが完璧でも低パフォーマンスになります。ローカライゼーションは商業面を変えます。通貨、税表示、支払い方法、サポート時間、信頼シグナル、例、規制文はすべて市場パスが必要です。 SEO特に、ローカライゼーションには次も含む： - 英語キーワードの借訳ではなく、その言語での検索の仕方向けに書いたタイトルとメタディスクリプション - 同等があるとき、同じ言語ハブ内に留まる内部リンク - 重要なところではローカルUIまたはキャプション付きの画像とスクリーンショット - 完全な代替としてまだ注釈される薄い「coming soon」ロケールシェルのスキップ 市場の準備ができていなければ、ページが本当に同等になるまでhreflangから外す。プレースホルダーを`fr`として注釈すると、フランス語代替が弱いとGoogleに教える。 > **ベストプラクティス:** サイトマップ全体に半分翻訳のフォルダを10個撒く前に、商業的に完成したロケールを少なく出荷する。 ![生の翻訳を超えるローカライゼーション層：通貨、法務、例、検索フレーズ](/work/assets/blog/hreflang-05-localize.webp) *図5：語の入れ替えを超えて。通貨、証明点、法務面も市場パスを受ける。* ## よくあるhreflangと国際SEOの失敗 これらはほぼすべての多言語クロールレビューに現れます。 **壊れた相互確認。** 新ロケールが旧言語を列挙するタグでローンチするが、旧言語が更新されない。すべてのロケールで完全な代替セットを再生成する単一の真実源（ビルドステップまたはCMSフィールド）で直す。 **誤ったコード。** `eng`、`uk`、`zh-Hans`と一貫しない`zh-CN`の混在、または言語のつもりで地域コード。URL文書で標準化したコード一覧に対して検証。 **非カノニカルまたは非インデックス可能URLの注釈。** Hreflangは最終の優先URLを指さなければならない。ドイツ語ページが英語にカノニカルする、またはnoindexを返すなら、代替セットは嘘をついている。まずカノニカルとインデックスを直す。 **HTTPとHTTPSの混在、またはwwwと非wwwの混在。** 代替セットのすべての`href`は、カノニカルとして選んだ同じホストとプロトコルを使うべき。 **部分カバレッジ。** ホームページだけにhreflangがあり、商品テンプレートにはない。またはサイトマップだけにエントリがありHTMLが矛盾する。トラフィックを稼ぐテンプレートを端から端までカバーする。 **パラメータ重複を作る言語スイッチャー。** カノニカル規律なしに`/de/`の上に`?currency=EUR`を足すスイッチャーはほぼ重複を増やし、クロールを浪費する。 **自動リダイレクトループ。** 言語を検出し、別フォルダへ302、次に別ルールがボットをよそへ送る。Googlebotに安定ロケールURLで200を与える。 > **警告:** Hreflangエラーはめったに見えるオンページバグを投げない。ユーザーはまだ閲覧できる一方、Googleは代替マップを無視し得る。Search Consoleとクロール差分を監視面として扱う。 ![よくある失敗アイコン：片方向タグ、悪いコード、noindexターゲット、混在ホスト](/work/assets/blog/hreflang-06-common-failures.webp) *図6：通常の壊れ方は相互確認、コード、インデックス可能性、ホストの不一致。* ## 多言語サイトのクロール予算 新しいロケールごとにURL数が増える。ページが一意でリンクされていれば問題ない。薄いテンプレート、すべての言語のファセットフィルター、翻訳してほしくなかったタグアーカイブをクローンすると痛い。 クロール予算は神秘のスコアではない。実務では、Googlebotが収益URLに時間を使うかジャンクに使うかを気にする。多言語ジャンクの見え方： - 何千ものほぼ空の一覧を作る翻訳フィルター組み合わせ - すべての言語の薄い投稿のページネーションアーカイブ - フッターからリンクされたままのステージングまたはプレビューロケール - CMS公開失敗後に404またはソフト404する代替 各ロケールの低価値面を、単言語監査と同様に統合またはnoindexする。サイトマップを、代替マップに属するカノニカル・200・インデックス可能URLに限定する。言語を足すとき、保守できるテンプレートだけを足す。 内部リンクは同じロケールパスを優先すべき。ドイツ語記事が英語カテゴリハブにしかリンクしないと、余分なホップが増え、言語クラスターが薄まる。 ![薄い翻訳フィルターより収益ロケールURLを好むクロールパス](/work/assets/blog/hreflang-07-crawl-budget.webp) *図7：言語が増えるとURLが増える。翻訳フィルターノイズより商業テンプレートへのクロールを優先。* ## CMSとプラグインの落とし穴 WordPress、Shopify、Webflow、カスタムNext.jsアプリ、エンタープライズCMSは、それぞれ違う形でhreflangバグを育てます。下にあるパターンは同じです。ページをレンダーするシステムが、代替を所有していると思う唯一のシステムではない。 注意すること： - 2つのプラグインが両方`link rel="alternate"`を出力し、意見が合わない - ヘッドレスCMSがロケールスラッグを保存する一方、フロントエンドが本番でパスを違う形に書き換える - すべてのロケールを列挙するサイトマッププラグインと、サブセットだけを列挙するHTMLタグ - 自己参照を省略する「hreflang」モジュール - `noindex`またはステージングカノニカルをクローンする新ロケールへのコピーワークフロー - ボットとユーザーに違うHTMLを出すCDNまたはリバースプロキシ層（意図的ならまれ、偶発ならmessy） [ウェブサイト国際化](/work/website-internationalization)作業では、hreflangをメジャー変更ごとに再検証するリリースチェックリスト項目として扱う。特にWordPress多言語スタックでは、メジャーなプラグインまたはテーマ更新のあと、各ロケールの収益ページのライブHTMLを検証する。 アプリでタグを生成するなら、テンプレートあたりの期待代替数を数えるCIチェックまたはクロールアサーションを足す。手動スポットチェックは10番目の言語を逃す。 ![hreflang出力で衝突するCMS層：テーマ、プラグイン、サイトマップ、CDN](/work/assets/blog/hreflang-08-cms-pitfalls.webp) *図8：テーマ、プラグイン、サイトマップ、CDN HTMLはそれぞれ違う代替ストーリーを出し得る。* ## リリース日に耐える実装パス 持続可能なロールアウトは次のように見える。 1. **URLパターンを凍結**し、商業的に準備できたロケール一覧を固める。 2. **同等物をスプレッドシートまたはデータベースにマップ。** 各行は1コンテンツ単位。列はロケールURL。空セルは「まだ代替なし」（埋まるまでhreflangから省略）。 3. **そのテンプレートクラスの真実源としてHTML、HTTP、またはサイトマップを選ぶ。** 4. **意図したフォールバックがあるところに`x-default`を含め、自己参照・相互タグを生成。** 5. **カノニカルを揃え、** インデックスすべきロケールURLは自分自身にカノニカルする。 6. **言語スイッチャーを更新**し、ホームページを推測せずマップされた同等へ各ロケールをリンクする。 7. **管理する各プロパティでサイトマップを提出または更新**する。 8. **デプロイ後にクロールと差分。** 収益テンプレートで相互確認またはコード検証が失敗したらリリースを落とす。 9. **監視。** Search Consoleのhreflang問題と、パフォーマンスレポートの予期しない国／言語ランディングパターン。 Googleの[ローカライズページ版](https://developers.google.com/search/docs/specialty/international/localized-versions)ドキュメントが、タグ構文と相互確認の規範参照です。サードパーティバリデータは助けになり、Googleが受け入れるものを決めるのは依然として公式ルールです。 ![URL凍結からクロール検証までの実装ステップ](/work/assets/blog/hreflang-09-implementation.webp) *図9：まず同等をマップし、相互タグを生成し、デプロイ後のクロールで検証する。* ## ドイツ語とフランス語を足すSaaSサイトの実践シナリオ Acmeは`https://www.acme.example/`でB2Bアナリティクス製品を出荷し、ブログと料金は英語。マーケはEU拡大向けにドイツ語とフランス語が欲しい。エンジニアリングは1ドメインを好む。サブディレクトリ`/de/`と`/fr/`を選ぶ。 古いブログタグアーカイブはすべて翻訳**しない**。ホームページ、料金、製品概要、ドキュメント入口、まだパイプラインを稼ぐ20投稿をローカライズ。法務がEU対応のプライバシー追補を書く。料金は必要なところにEURとVAT注記。ケーススタディは使用許可のあるEUロゴに入れ替え。 同等マップ（簡略）： | 単位 | en | de | fr | | --- | --- | --- | --- | | ホーム | `/` | `/de/` | `/fr/` | | 料金 | `/pricing/` | `/de/pricing/` | `/fr/pricing/` | | 製品 | `/product/` | `/de/product/` | `/fr/product/` | これら6 URLのそれぞれ（＋自己）が、英語ホームまたはインデックス可能に保つ小さな地域選択を指す`en`、`de`、`fr`、`x-default`を出す。英語にしかないブログ投稿は翻訳まで`de`／`fr`を省略。ドイツ語ホームをフランス語料金URLに決して向けない。 ローンチ後1週目、クロールが、キャッシュ層が古いheadを出したために英語料金に新しい代替がまだないことを見つける。パージ、再クロール、相互確認。処理後、Search ConsoleはそれらのURLのreturn-tagエラー報告を止める。 成功は、ドイツ語とフランス語クエリが`/de/`と`/fr/`の収益ページに着地することとして測る。インデックス済みURL数だけはここでは弱い成功指標です。 ![マップされたホーム、料金、製品URLで/de/と/fr/を足すSaaSサイト](/work/assets/blog/hreflang-10-worked-scenario.webp) *図10：Acmeは少数の完全な同等をマップし、相互タグを出荷し、薄いアーカイブ翻訳をスキップする。* ## 多言語SEOチェックリスト プロジェクト完了と呼ぶ前に使う。 - [ ] 文書化されたURLパターン（ccTLD、サブドメイン、またはサブディレクトリ）を一貫して使用 - [ ] 商業的に準備できたロケールだけがライブで注釈されている - [ ] 注釈されたすべてのURLが200を返し、インデックス可能で、ランクすべきときは自己カノニカル - [ ] Hreflangコードが言語対ロケール方針と一致（`de`対`de-DE`など） - [ ] 各メンバーページまたはサイトマップ行に自己参照を含む完全な代替セット - [ ] セット全体での相互確認 - [ ] `x-default`が意図したフォールバックを指す - [ ] 言語スイッチャーがパラメータ重複を生まず本物の同等へリンク - [ ] サイトマップがクロールしたいカノニカルロケールURLのみを列挙 - [ ] 薄い翻訳フィルター、タグ、ステージングロケールが代替マップ外 - [ ] デプロイ後クロールが収益テンプレートのタグを検証 - [ ] 管理するホスト向けにSearch Consoleプロパティとサイトマップを更新 ![多言語SEOとhreflangローンチ準備のチェックリストクリップボード](/work/assets/blog/hreflang-11-checklist.webp) *図11：ローンチ準備はURL、コード、相互確認、インデックス可能性、デプロイ後検証をカバーする。* ## よくある質問 ### 言語が1つだけの場合、hreflangは必要？ いいえ。Hreflangは同じコンテンツの代替言語またはロケール版向けです。単言語サイトはクリーンなカノニカルとクロールアクセスに集中すべき。有用な先を指さない装飾的hreflangは監視ノイズを生むだけです。 ### hreflangだけで重複コンテンツは直せる？ 有効な版の間で正しい代替をGoogleが選ぶ助けにはなる。カノニカル規律の代替にはならず、薄いコピーページを更生しない。まず重複と品質を直し、本物の同等を注釈する。 ### すべてのブログ投稿がすべての言語に存在するべき？ 保守するつもりがあるときだけ。部分カバレッジは問題ない。その単位に存在する言語を注釈し、出荷まで残りを代替リストから外す。 ### 国際SEOにccTLDは常に良い？ いいえ。ccTLDは強い国シグナルであり、しばしばローカルユーザーへの信頼シグナルですが、運用コストが高く、各プロパティに投資しなければ権威が分割されます。多くのグローバルブランドはサブディレクトリ＋正しいhreflangでうまくいく。フォーラムスレの経験則ではなく、法務、ホスティング、リソース制約から選ぶ。 ### 大規模カタログのhreflangはどこに置く？ SKUが数万あるときはXMLサイトマップの方がスケールする。サイトマップエントリをカノニカル商品URLと同期させる。スタックがheadタグも出すならHTMLをスポットチェックし、衝突を取り除く。 ### hreflangとcontent-languageメタタグの違いは？ HreflangはGoogle検索向けに言語と地域の代替URLをマップする。`content-language`メタタグはそのマップの代替ではない。代替にはGoogleの[ローカライズ版](https://developers.google.com/search/docs/specialty/international/localized-versions)メカニズムに従う。 ## 結び 多言語SEOは、URLが安定し、ロケールが本物の製品で、hreflangがそれらのURLの相互マップであるときにまとまる。苦戦するチームは通常、先に注釈して後でローカライズするか、第三言語ローンチ後に誰も再検証しないプラグインにタグ出力を任せた。 ロケールロールアウトを計画中、または既存の代替マップを掃除中なら、[お問い合わせフォーム](https://form.ms/ja5zic)から連絡してください。