多言語サイト：hreflang、URL、よくあるミス
明確な URL 設計と正しい hreflang がない 多言語サイト は、トラフィックを失いがちです。検索エンジンがバージョンを混同し、別の言語を表示したり、ページを重複とみなしたりします。以下では、アドレス構造の選び方、ロケールのつなぎ方、2026年に多いミスを整理します。
- hreflang - どの言語／地域版がどのオーディエンス向けかを検索エンジンに伝える信号
- URL - パス接頭辞、サブドメイン、または別ドメイン。方式は一貫して予測可能であること
- Canonical - ロケール間の関係を壊してはいけない
- コンテンツ - 翻訳またはローカライズ。未校正の機械翻訳コピペではない
- ルール - 各ロケールは他のすべてと自分自身を指す
なぜ hreflang と URL 設計が必要か
ドイツのユーザーにはドイツ語版、ブラジルではポルトガル語版、米国では英語版が見えるべきです。明示的な信号がないと、検索エンジンは IP、ブラウザ言語、リンクから推測し - しばしば誤ります。
hreflang 自体が順位を上げるわけではありません。対等なページ群の中から 適切なバージョン を選ぶ助けになります。URL 設計は、人がボットがそれらの版をどう見つけるかを決めます：/de/、de.example.com、または example.de。
多言語向けの URL 方式
| 方式 | 例 | 利点 | 欠点 |
|---|---|---|---|
| パス接頭辞 | example.com/de/blog/ |
ドメインが一つ、分析と証明書が簡単 | ルーティングと sitemap の規律が必要 |
| サブドメイン | de.example.com/blog/ |
ホスティングとチームの柔軟性 | ドメイン評価の共有が難しく、インフラが増える |
| 別ドメイン | example.de/blog/ |
強いローカル信号 | 運用コストが高く、SEO キャンペーンが分かれる |
2026年の多くのコーポレートサイトやブログでは パス接頭辞 が現実的です：スタック一つ、分析一つ、デプロイが簡単。サブドメインや ccTLD は、強いローカルブランド、別法人、市場専任チームがある場合に向きます。
デフォルト言語 を決めましょう：接頭辞なしのルート（/）、または明示的な /en/。「時々接頭辞あり、時々なし」の混在は重複を生みます。
hreflang の正しい設定
- 各ページですべての利用可能な同等ページを列挙：
hreflang="ru"、hreflang="en"、hreflang="de"など。 - 自己参照 を追加：ページは自分自身も指す。
- セットは 相互参照 であること：A が B を指すなら、B も A を指す。
- BCP 47 コードを使う：言語（
en）または言語-地域（en-GB、pt-BR）。 - 必要なら
x-default- 一致しないロケール向けの既定ページ（言語セレクタや EN が多い）。 - 同じ注釈を HTML の
<link rel="alternate" hreflang="...">および／または XML sitemap に重複させる。
<head> の例：
<link rel="alternate" hreflang="ru" href="https://example.com/blog/post/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/post/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/post/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/post/" />
よくあるミス
1. 相互参照がない
ロシア語ページは EN を指すが、英語ページに RU への戻りがない。検索エンジンはグループ全体を無視することがあります。
2. Canonical が「メイン」言語を指す
ロシア語ページの canonical が英語版を「オリジナル」として指す。するとロケールは代替ではなく重複に見えます。Canonical は 自分自身（または同一ロケールの正規 URL）を指すべきで、別言語ではありません。
3. IP / Accept-Language による自動リダイレクト
ユーザーもボットも、意図した版を安定して開けません。望ましいのは、ロケールごとの専用 URL ＋言語切替で、ルートから全員に「推測した」言語へ強制リダイレクトしないことです。
4. ロケール集合が不完全
メニューは 5 言語、hreflang は 2。あるいはある記事は翻訳があり隣はなく、マップには壊れた代替が残る。正直な集合を：実在する URL だけ。
5. 言語と地域を混同する
de はドイツ語。de-AT はオーストリア向けドイツ語。DE/AT/CH で中身が同じなら、価格・配送・法務文の本当のローカライズなしにほぼ同一の 3 ページを増やさないこと。
6. 「翻訳」の下で意味が違う
URL は「翻訳」されているが、オファー、通貨、CTA は別市場のまま。SEO 上はもう同等ではなく - ここで hreflang は害になり得ます。
7. sitemap と内部リンクを忘れる
<head> にタグはあるが、XML sitemap に xhtml:link がなく、フッターの言語リンクは常にトップへ行き、現在記事の同等ページではない。ロケール間の内部リンクは信号を強めます。
公開前チェックリスト
- サイト全体で一つの URL 方式。
- インデックス対象の各ページに、完全で相互の hreflang セット＋ self。
- Canonical が異なる言語をくっつけない。
- インデックスを妨げる攻撃的な geo-redirect がない。
- sitemap にすべてのロケールと注釈がある。
- 言語切替は同等ページへ、ホームページだけではない。
- 404 と「未翻訳」は明示的に処理（ソフトフォールバックまたは正直な 404）。同じ URL の下で別言語を静かに出さない。
まとめ
多言語サイト は、各オーディエンスに安定した URL があり、hreflang が同等ページを正直につなぐときに機能します。アドレス方式を一つ選び、注釈の相互性を保ち、canonical や geo-redirect でロケールを壊さない - そうすれば検索エンジンは言語を代わりに推測しなくなります。
スタック向けの URL 設計、hreflang、sitemap の設計、または現行サイトのミス確認が必要なら、ご連絡ください。
よくある質問
言語が 2 つだけでも hreflang は必要？
はい。両方の版をそれぞれのオーディエンス向けに検索に出したいなら必要です。 相互注釈のない RU/EN でも、誤った言語表示や重複感がよく起きます。
/en/ パスとサブドメイン、どちらが良い？
多くのプロジェクトではパス接頭辞です。 サブドメインは、ホスティング・チーム・市場の強い分離がある場合に向きます。別 ccTLD は、ブランドと法人が本当にローカルなとき。
x-default は必須？
必須ではないが有用です。 通常は言語セレクタや国際向けメイン版（多くは EN）を指します。ないと検索エンジンがフォールバックを選びます。
hreflang を sitemap だけに置ける？
はい。Google は sitemap の注釈を理解します。 実務では HTML と sitemap の両方に置く方が安全です - デバッグしやすく、部分デプロイでのずれも減ります。
hreflang 設定後も検索の言語が間違うのはなぜ？
タグではなく周囲の信号が原因であることが多いです： 別言語への canonical、リダイレクト、薄い／機械的な「翻訳」、セット内の壊れた URL、同等ページへの内部リンク不足。相互参照と、両ページが実際にインデックスされているかを確認してください。