SEOガイド ステップ10: 多言語SEO — ランキングを薄めることなく、グローバルなオーディエンスにリーチする
SEOガイド ステップ10: 多言語SEO
これは13段階のSEOガイドのステップ10です。多言語SEOを活用すれば、各市場にその言語でサービスを提供することでオーガニックトラフィックを増加させられます — しかし、間違った方法で行うと重複コンテンツの混乱を引き起こします。
追加する言語の数が多いほど、既存のコンテンツに対するマルチプライヤーとなります。1言語で50ページのサイトは50のインデックス可能なURLを持っています。5つの言語を追加すれば250、20の言語を追加すると1,000になります。これらのURLのそれぞれが、現地のGoogleの検索結果で独立してランク付けされる可能性があります。
しかし、多言語SEOはSEOの中でも特に技術的に複雑な分野の一つです。誤った実装は重複コンテンツ、ランキングの希薄化、クローリング予算の無駄を引き起こします。正しく国際化されたサイトと誤って国際化されたサイトの間のトラフィックの違いは10倍になることもあります。
LANGR自体は89のアクティブロケールで108言語で運営されており、これらの問題をスケールで解決してきました。このガイドでは私たちが学んだすべてを共有します。
多言語SEOのカバー範囲
多言語SEOは8つの重要な領域にわたります：
- Hreflangの実装 — Googleにどのページがどの言語を提供しているかを伝える
- ロケールルーティング戦略 — サブドメイン vs サブフォルダ vs TLD
- 翻訳の質 — 機械翻訳 vs 人間翻訳 vs ハイブリッド翻訳
- 国際ターゲティング — サーチコンソールの設定
- コンテンツのローカライズ — 翻訳を超えて: 文化的適応
- RTLサポート — 右から左への言語（アラビア語、ヘブライ語、ペルシャ語）
- 言語検出 — 自動的に適切なバージョンを提供する
- 重複コンテンツ — クロスランゲージのカニバリゼーションを防止する
1. Hreflangの実装
Hreflangタグは、検索エンジンにどのURLがどの言語と地域に対応しているかを伝えます。これは多言語SEOの技術的基盤であり、最も一般的に誤設定される要素です。
基本的なhreflang構文：
<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="da" href="https://example.com/da/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />重要なルール：
- すべてのページは、すべての代替バージョン（自分自身を含む）を参照する必要があります
x-defaultはフォールバックを指定します（通常は英語または言語選択）- Hreflangタグは相互である必要があります（ページAがBにリンクしていれば、BもAにリンクしなければなりません）
- ISO 639-1の言語コードを使用（
en、da、de）して国コードを使用しないでください - 地域固有のコンテンツの場合:
en-us、en-gb、pt-br（言語-地域） - ページあたり最大約50のhreflangエントリ（パフォーマンス制限）
三つの配置オプション：
| 方法 | 最適 | 欠点 | |--------|----------|-----------| | を内に | 小サイト（< 10言語） | HTMLが膨らむ、パースが遅くなる | | HTTPヘッダー | 非HTMLファイル（PDF、API） | 幅広くサポートされていない | | XMLサイトマップ | 大サイト（10+言語） | クロールによる発見が遅れる |
サイトマップのhreflang例：
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="da" href="https://example.com/da/page" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>一般的なhreflangエラー：
- 自己参照タグが欠落（ページが自分自身を含めていない）
- 非相互なタグ（AがBを参照しているが、BがAを参照していない）
- 誤った言語コード（デンマーク語に対して
dkの代わりにda） - 200以外のURLを指している（リダイレクト、404）
- 言語特定のページと
x-defaultを混同
クイックウィン： サイトをクローリングしてすべてのhreflangタグをエクスポートします。非相互関係をチェックしてください — これは最も一般的なエラーであり、Googleがあなたのhreflang設定全体を無視する原因になります。
2. ロケールルーティング戦略
異なる言語のためにURLを構造化する方法は、SEO、ユーザー体験、技術的な複雑さに影響を与えます。主に三つのアプローチがあります：
サブフォルダ（推奨）
example.com/en/page
example.com/da/page
example.com/de/page利点: 単一のドメイン権威、管理が容易、一つのSSL証明書、一つのアナリティクスプロパティ、一つのサーチコンソールプロパティ、ほとんどのサイトに最適。
欠点: ccTLDよりも地理的ターゲティング信号が少ない。
サブドメイン
en.example.com/page
da.example.com/page
de.example.com/page利点: 地域ごとに異なるサーバー/CDNでホスティング可能、クローリング予算が分離される。
欠点: 各サブドメインが独立して権威を構築する（リンクエクイティは自動的に流れない）、複数のサーチコンソールプロパティ、構成が複雑。
国コードTLD (ccTLD)
example.com (英語)
example.dk (デンマーク語)
example.de (ドイツ語)利点: 最強の地理的ターゲティング信号、ユーザーはローカルTLDを信頼する、各ドメインは独立している。
欠点: 高コスト（20以上のドメインを購入する必要がある）、ドメインごとに権威が分かれる、リンクビルディングが複雑、分析/コンソールを分ける必要がある。
私たちの推奨: 90%のサイトにはサブフォルダルーティングを推奨します。これにより、すべてのリンク権威が単一のドメインに集中し、明確なロケール信号を提供します。/{locale}/pageフォーマットを使用してください。
https://langr.org/page (英語, デフォルト)
https://langr.org/da/page (デンマーク語)
https://langr.org/de/page (ドイツ語)
https://langr.org/ja/page (日本語)クイックウィン: サブドメインを使用していて権威に苦しんでいる場合、サブフォルダに移行することを検討してください。サブドメインからサブフォルダに移行するサイトは、リンクエクイティが統合されることで、通常3〜6ヶ月内に20〜50%のオーガニックトラフィックの増加を見ます。
3. 翻訳の質 vs 機械翻訳
翻訳の質はランキングに直接影響します。Googleは機械翻訳を検出可能で、質の低い翻訳ページは評価を下げるかもしれません。しかし、2026年のAI翻訳は2020年の経験則よりも劇的に優れています。
翻訳の質スペクトル：
| レベル | 方法 | 質 | コスト | 最適 | |-------|--------|---------|------|----------| | 1 | 生のGPT/DeepL出力 | 60-75% | ~$0 | 内部使用、ドラフト | | 2 | AI + ポストエディティングプロンプト | 75-90% | ~$0 | ブログコンテンツ、非重要なページ | | 3 | AI + 人間レビュー | 90-97% | $0.03-0.08/単語 | 商品ページ、主要ランディングページ | | 4 | プロのネイティブ翻訳者 | 97-100% | $0.10-0.25/単語 | 法律、医療、ブランドクリティカル |
2026年の重要な洞察： レベル2（質の良いプロンプトを使用したAI）は、現在ほとんどのwebコンテンツにとって十分です。Googleの重複コンテンツアルゴリズムは、適切に実施された機械翻訳をもはや罰しません — 価値のない悪い翻訳を罰します。
SEOを損なう翻訳の兆候：
- 翻訳されたコンテンツと混合された未翻訳のセグメント
- UI要素（ボタン、ラベル）がソース言語のまま
- 地域固有のフォーマットが適応されていない（日時、通貨、電話番号）
- 翻訳できない文化的参照（イディオム、ジョーク、例）
- すべての言語で同じメタタイトル/ディスクリプション
翻訳の質を検証する方法：
- すべての可視テキストが翻訳されているか確認する（ナビゲーション、フッター、フォームを含む）
- 地域固有のフォーマットを確認する（DD/MM/YYYY vs MM/DD/YYYY）
- CTAをテスト — 目標言語で自然に聞こえるか？
- メタタグを確認 — タイトルとディスクリプションは各言語ごとに独立して書かれている必要があります
- 生のi18nキーが露出していないことを確認する（例:
nav.homeの代わりに「ホーム」）
クイックウィン: 翻訳されたページで混合言語コンテンツがないか確認してください。ボタン、ラベル、またはUI要素がソース言語のままだった場合、すぐに修正してください — 混合言語ページはGoogleに低品質を示します。
4. サーチコンソールでの国際ターゲティング
Googleサーチコンソールの国際ターゲティング設定は、どのページがどの国でランク付けされるべきかをGoogleに理解させる手助けをします。
サブフォルダセットアップの場合：
- サブフォルダごとに国ターゲティングを設定することはできません（ドメイン/サブドメインごとにのみ）
- 代わりにhreflang + コンテンツ言語 + ユーザー信号に依存してください
- 各ロケール別のサイトマップを提出：
sitemap-en.xml,sitemap-da.xml
ccTLDの場合：
.dkは自動的にデンマークにターゲットされます.deは自動的にドイツにターゲットされます- 手動の設定は必要ありません
汎用TLD（.com、.org、.net）の場合：
- サーチコンソール内でプロパティごとに「国際ターゲティング」を設定します
- hreflangを主要な信号として使用します
実践的な手順：
- サーチコンソールであなたのサイトを確認（サブフォルダセットアップの場合は一つのプロパティ）
- hreflang注釈付きのサイトマップを提出します
- エラーのために「国際ターゲティング」レポートを確認します
- 各言語に対する「カバレッジ」レポートを監視します（URLパラメータフィルタリングを使用）
- "ユーザーが選択したカノニカルがない重複"の警告を確認 — これらはしばしばhreflangの問題を示します
クイックウィン: サーチコンソール > パフォーマンス > 国でフィルタリングに移動します。ドイツのユーザーがあなたの英語ページにアクセスしているかどうかを確認します。はいなら、あなたのhreflang設定にエラーがあります。
5. コンテンツのローカライズ（単なる翻訳以上）
ローカライズは単なる逐語的な翻訳を超えています。文化的文脈、地域の検索行動、および市場固有のニーズに対してコンテンツを適応させます。
ローカライズすべきこと：
- 通貨と価格設定: 現地通貨を表示（ドイツでは€、デンマークではkr、日本では¥）
- 日付/時間フォーマット: 25/06/2026（EU）vs 06/25/2026（US）vs 2026/06/25（ISO/日本）
- 電話番号: 国際用の国コード付きローカルフォーマット
- 住所: 現地の郵便形式に合わせる
- 社会的証明: ローカルの顧客名、ローカル企業、ローカルのケーススタディ
- CTA: トーンを適応（ドイツ語/日本語ではフォーマル、英語/デンマーク語ではカジュアル）
- 画像: 画像内のテキストをローカライズし、文化的に適切なビジュアルを使用
- 法律: EUのGDPR、国ごとのクッキーの同意要求の違い
- 例: ローカルブランド、ローカルウェブサイト、ローカル参照
直接翻訳すべきでないコンテンツ：
- 地元のトピックに関するブログ投稿（市場ごとにユニークに書く）
- ケーススタディ（地元のビジネスを使用）
- 価格ページ（市場ごとに異なる価格が有効）
- ニュースコンテンツ（地域の関連性は異なります）
キーワードのローカライズ： キーワードは翻訳しないでください — 現地でリサーチします。「自動車保険」は英語で「car insurance」ですが、デンマーク語では「bilforsikring」、「forsikring bil」など異なる単語の順が検索ボリュームリーダーかもしれません。ローカルなキーワードリサーチツールを使用してください。
クイックウィン: すべての言語で価格ページをチェックしてください。正しい現地通貨が表示されていますか？あなたのCTAは文化的に適切ですか？「無料で始める」のCTAはドイツ語では「Jetzt kostenlos testen」にする必要があります — 直訳ではなく、ドイツのユーザーが期待する内容です。
6. RTLサポート
右から左への言語（アラビア語、ヘブライ語、ペルシャ語/ウルドゥー語、パシュトー語）にはかなりのレイアウトの適応が必要です。RTLコンテンツを左から右のレイアウトで提供することは、約5億人のネイティブスピーカーにとってサイトを使用不可能にします。
技術的実装：
<!-- 方向を検出して適用 -->
<html lang="ar" dir="rtl">RTLで反転すべきこと：
- テキストの配置（本文テキストは右揃え）
- レイアウトの方向（サイドバーは左から右に移動）
- ナビゲーション順序（逆にする）
- 方向を持つアイコン（矢印、進捗バー）
- パディングとマージン（左右の値を交換）
- ボーダー半径（角の値を交換）
- CSSフレックスボックス/グリッドの方向
RTLで反転すべきでないこと：
- 電話番号や数学的表現
- 左から右のブランド名やロゴ
- オーディオ/ビデオプレーヤーコントロール
- 水平スクロールインジケーター
- 埋め込まれたコードブロック
CSSのアプローチ（モダン）：
/* 論理プロパティを使用 */
.card {
margin-inline-start: 1rem; /* margin-leftの代わり */
padding-inline-end: 0.5rem; /* padding-rightの代わり */
border-start-start-radius: 8px; /* LTRの上左、RTLの上右 */
}RTLのテスト：
にdir="rtl"を追加し、すべてのページをチェック- アラビア語/ヘブライ語のテキストが読めるか確認（壊れたUnicodeでないこと）
- フォーム入力をテスト（テキストの入力方向）
- RTLテキスト内で数値が正しく表示されるか確認
クイックウィン: アラビア語やヘブライ語をサポートする場合、そのロケールのHTML要素にdir="rtl"を追加し、CSS論理プロパティ（margin-inline-startの代わりにmargin-left）を使用します。この一つの変更がRTLレイアウトの80％の問題を修正します。
7. 言語検出とルーティング
どの言語バージョンをユーザーに表示するかを決定する方法は、UXとSEOの両方に影響を与えます。
ベストプラクティス: URLベースのプログラミングクッキー
- 最初の訪問: URLに基づいてコンテンツを表示（例：
/da/page= デンマーク語） - ルートURL (
/):Accept-Languageヘッダーに基づいてリダイレクトするか、デフォルトを表示（英語） - 手動スイッチ: ユーザーが言語を選択したとき、クッキーを設定し、今後の訪問で尊重する
- 絶対に避けるべきこと: 言語固有のURLから自動的にリダイレクトしないこと
避けるべきこと：
- IPベースのリダイレクト（GoogleはUS IPからクロール → 英語のみインデックスする）
- JavaScriptのみの言語検出（検索エンジンはJSを信頼性高く実行できない）
/de/pageを英語ユーザーに対して/en/pageにリダイレクトする（hreflangを壊す）- クローキング（ユーザーエージェントに基づいて異なるコンテンツを表示する）
正しいリダイレクト動作：
ユーザーが訪問: / → 302リダイレクトで /{detected-locale}/
ユーザーが訪問: /da/page → デンマーク語コンテンツを提供（絶対にリダイレクトしない）
ユーザーが訪問: /nonexistent → 404（デフォルト言語にリダイレクトしない）SEOにとっての重要ルール: 各言語URLは、リダイレクトなしでGooglebotが直接アクセスできる必要があります。Googleが/da/pageをクロールして/en/pageにリダイレクトされると、デンマーク語コンテンツは決してインデックスされません。
クイックウィン: Googlebotがすべての言語URLに直接アクセスできるか確認してください。サーチコンソールで非英語URLに対してURL検査ツールを使用します。リダイレクトが表示される場合は、ルーティングロジックを修正してください。
8. 多言語間での重複コンテンツ
多言語サイトは、一つの言語での類似ページが他の言語と競合できる独自の重複コンテンツの課題に直面しています。
重複コンテンツが問題になるとき：
- 言語間で90％以上同一のページ（未翻訳コンテンツ）
- 同じURLがロケールプレフィックスの有無でアクセス可能（
/pageと/en/page） - カノニカルタグが欠落し、両方のバージョンがインデックスされることを許可する
- hreflangエラーが「間違った」バージョンを選択するGoogleの原因に
解決策：
| 問題 | 解決策 | |---------|----------| | 未翻訳のページ | 翻訳されるまでnoindexを使用、または明確な言語インジケーターで英語を表示 | | 二重URL（/page + /en/page） | 301リダイレクトしてどちらかに | | Googleが誤った言語をインデックス | hreflangの相互性を修正し、サーチコンソールで確認 | | 質の低い翻訳がインデックスされる | 翻訳の質を改善するか、より少ない言語に統合 |
カノニカルタグ戦略：
<!-- 各言語ページはそれぞれのカノニカル -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />
<!-- /da/page -->
<link rel="canonical" href="https://example.com/da/page" />絶対に一つの言語から別の言語へのカノニカルを指さないでください（例：デンマーク語のカノニカルが英語を指す） — これはGoogleにデンマーク版を完全に無視するように指示します。
クイックウィン: Googleでsite:yourdomain.com "your page title"を検索します。英語と翻訳版の両方が同じクエリで表示されている場合、重複コンテンツまたはhreflangの問題があります。
多言語SEOチェックリスト
各国際化サイトで確認すること：
- [ ] すべてのページにhreflangタグあり、自己参照およびx-defaultを含む
- [ ] すべてのhreflang関係が相互関係（クローラーでチェック済）
- [ ] 正しいロケールルーティング（サブフォルダ推奨）：
/{locale}/page - [ ] 言語固有のURLから自動リダイレクトしない
- [ ] 翻訳の質が検証済み（混合言語ページなし）
- [ ] メタタイトルとディスクリプションが各言語ごとに独立してユニーク（重複なし）
- [ ] 通貨、日付、フォーマットが市場ごとにローカライズ済
- [ ] アラビア語/ヘブライ語/ペルシャ語に対するRTLサポートが実施済み（該当する場合）
- [ ] 各ロケール用のサイトマップがサーチコンソールに提出済み
- [ ] 各言語ページには独自のカノニカルURLがあり（別の言語を指さない）
- [ ] すべてのページで生のi18nキーが表示されていない
- [ ] 言語スイッチャーがすべてのページでアクセス可能（同等のページにリンク、ホームページではない）
LANGRが多言語SEOをチェックする方法
LANGRには多言語SEO用の二つの専用モジュールがあります：
i18n-checker: 最大5つのロケールバリアントのページをクローリングし、以下をチェックします：
- hreflangタグの完全性と相互性
- アクセス不可のロケールURL（404またはリダイレクト）
- ロケール間でのハードコーディング/未翻訳の文字列（フォールバック検出）
- 生のi18nキーが可視テキストとして露出しているか
- 翻訳のカバレッジパーセンテージ
翻訳スキャナー: AI駆動の品質評価：
- 翻訳の自然さを0-100スケールで評価
- 機械翻訳のアーティファクトを検出
- その他の翻訳ページ内の未翻訳セグメントを特定
- UI要素（ボタン、ラベル、ナビゲーション）を本文コンテンツから独立してチェック
これらのモジュールを組み合わせることで、技術的（hreflang、ルーティング、カノニカル）および品質（翻訳、ローカライズ）の両方の視点からの多言語実装をチェックします — LANGRの13のSEO分野のうちの二つです。
一般的な多言語の間違い（影響の大きさでランク付け）
- 非相互のhreflang — Googleが全体の設定を無視
- IPに基づく自動リダイレクト — Googlebotが非英語版をインデックスできない
- 言語間で同じメタタグ — 翻訳ページのランキング潜在能力を無駄にする
- 混合言語ページ — 英語のボタン、ドイツ語のコンテンツ = 低品質信号
- x-defaultなし — Googleがフォールバックバージョンを決定できない
- URLを逐語的に翻訳する —
/about-us→/uber-unsは問題ありませんが、一貫性を保つ - RTLを無視する — 5億人以上のネイティブスピーカーに対する破損したレイアウト
- カノニカルが他の言語を指す — Googleのインデックスで翻訳版を消滅させる
次は何か？
ステップ11: B2Bリード発見 — 自動化された見込み客発掘、ドメインベースのリードスコアリング、SEOの発見によるアウトリーチでSEOデータを質の高いリードに変換します。
このガイドはLANGRの13段階のSEOシリーズの一部です。無料監査を実施して、あなたのサイトが13の分野全体でどのように立つか確認してください。