WordPressの多言語サイトで海外SEOに対応する設計とhreflang設定ガイド

WordPress で海外向けの多言語サイトを作るときは、「URL の構成を決める」「各言語のページを hreflang で正しく結び付ける」「出力を検証する」の3つを順に押さえると、検索エンジンに言語ごとのページを正しく伝えられます。この記事では、多言語プラグインを選ぶ前に決めておくべき設計と、hreflang の書き方の規則、よくある間違いの見つけ方を説明します。

hreflang は「この内容の別の言語版はここにあります」と伝えるための注釈で、順位を上げる仕組みではありません。正しく設定すると、たとえば英語で検索した人に日本語版ではなく英語版が表示されやすくなります。

最初に決める：言語だけか、国・地域も分けるか

多言語化の目的を一文で書けるようにしておくと、後の判断がぶれません。

• 言語で分ける：日本語版と英語版を用意し、英語圏の読者全体に英語版を見せたい。ブログや技術情報のサイトはたいていこちらです。
• 国・地域で分ける：同じ英語でも、アメリカ向けとイギリス向けで価格や配送条件が違う。EC サイトやサービスサイトで必要になります。

国・地域まで分けるとページ数が増え、翻訳や更新の手間も増えます。内容に違いが無いのに地域別のページを作ると、ほぼ同じページが並ぶだけになるので、本当に内容が変わる場合だけ分けます。

URL の構成を選ぶ

言語版ごとの URL の分け方には主に次の形があります。

小規模から中規模の WordPress サイトなら、サブディレクトリが扱いやすい選択です。どの形式でも、言語ごとに URL が分かれていることが前提で、同じ URL で言語だけを切り替える作りは避けます。

多言語プラグインを選ぶ

hreflang を手で書くこともできますが、記事が増えると対応関係の管理が追いつかなくなります。翻訳の対応関係を管理し、hreflang を自動で出力してくれる多言語プラグインを使うのが現実的です。

• WPML：有料。機能が多く、WooCommerce や主要なページビルダーとの連携に強い
• Polylang：無料版と有料の Pro 版がある。投稿ごとに翻訳を結び付ける方式で軽量
• TranslatePress：無料版と有料版がある。フロント側で画面を見ながら翻訳できる
• Weglot：外部の翻訳サービスと連携する方式。翻訳データは Weglot 側に保存される
• MultilingualPress：WordPress マルチサイトで言語ごとにサイトを分ける方式

無料版と有料版でできることの範囲や画面の表記は変わるので（2026年10月現在）、導入前に各プラグインの公式ドキュメントで、hreflang の出力と URL 構成の選択肢を確認してください。導入はバックアップを取ったうえで、ステージング環境で試してから本番に入れます。複数の多言語プラグインを同時に有効にすると、hreflang や URL の書き換えが競合します。

hreflang の規則を正しく理解する

プラグイン任せでも、規則を知らないと出力の誤りに気づけません。Google Search Central の説明に沿って、押さえるべき点をまとめます。

値の書き方

• 言語は ISO 639-1 の2文字コードで書きます。日本語は ja、英語は en です。jp は国コードなので言語としては誤りです。
• 地域を付けるときは、言語のあとに ISO 3166-1 の2文字コードを付けます。イギリス英語は en-GB で、en-UK は誤りです。
• 地域コードだけ（GB だけなど）は指定できません。

相互リンクと自己参照

• 日本語版が英語版を指すなら、英語版も日本語版を指し返す必要があります。片方向だけのリンクは無視されることがあります。
• 各ページは、ほかの言語版に加えて自分自身も一覧に含めます。
• どの言語にも当てはまらない人に見せるページとして x-default を指定できます。言語選択ページや、主に使う言語のページを指定するのが一般的です。

canonical との関係

各言語版の canonical は、その言語版自身を指すようにします。英語版の canonical を日本語版に向けてしまうと、英語版は日本語版の重複として扱われ、hreflang が機能しなくなります。SEO プラグインと多言語プラグインを併用しているときに起きやすい誤りです。

書く場所は1つに

hreflang は HTML の head、HTTP レスポンスヘッダー、XML サイトマップのいずれかで指定できます。複数の場所で書くと食い違いが起きやすいので、1つの方法に統一します。WordPress では head に出す方法が一般的で、PDF のような HTML 以外のファイルにはヘッダーを使います。

日本語版のページの head には、たとえば次のような出力が並びます。

<link rel="alternate" hreflang="ja" href="https://example.com/sample-page/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/sample-page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/sample-page/" />

英語版のページにも、同じ3行がそのまま出ている必要があります。

出力を検証する

設定したら、実際の出力を確かめます。ブラウザでページのソースを表示して hreflang で検索するか、コマンドラインで取り出します。

curl -s https://example.com/en/sample-page/ | grep -i 'hreflang'

確認する順番は次のとおりです。

1. すべての言語版に hreflang が出ているか：翻訳を作っていない記事では出ないのが正しい動作です。翻訳済みなのに出ないなら、翻訳の結び付けが外れています。
2. 相手のページも同じ一覧を出しているか：各言語版を開いて、指し返しがあるかを見ます。
3. リンク先が 200 で開くか：リダイレクトや 404 になる URL を指していないか確認します。
4. canonical が自分自身を指しているか：head の rel="canonical" を見ます。
5. html 要素の lang 属性が言語と合っているか：テーマが language_attributes() を使っていれば、多言語プラグインが切り替えた言語が反映されます。

キャッシュプラグインを使っている場合、言語ごとにキャッシュが分かれていないと、別の言語のページが表示されることがあります。多言語プラグインとキャッシュプラグインの相性は、双方のドキュメントで確認しておきます。

避けたい設計

• IP アドレスやブラウザの言語による自動リダイレクト：Google のクローラーは主にアメリカの IP アドレスからアクセスするため、自動で振り分けると他の言語版を見つけられないことがあります。振り分けるなら、言語を提案するバナーを出して読者に選んでもらう形にします。
• 機械翻訳をそのまま大量に公開する：読者にとって質の低いページは、言語版として結び付けても評価されにくくなります。主要なページから順に、人の目で確認した翻訳を用意します。
• 言語切り替えを JavaScript だけで行う：URL が変わらない切り替えでは、検索エンジンは別の言語版を認識できません。

なお、Search Console にあった「インターナショナル ターゲティング」レポートは提供が終了しています。hreflang の誤りは、上の検証手順で自分で確かめる必要があります。Bing は hreflang よりも content-language の meta タグや html の lang 属性を手がかりにするとしているので、Bing からの流入も重視するなら lang 属性が正しいかも見ておきます。

まとめ

• 先に「言語で分けるか、国・地域まで分けるか」と URL 構成を決める。WordPress ではサブディレクトリが扱いやすい
• hreflang は多言語プラグインに出力させ、規則（ISO コード、相互リンク、自己参照、x-default）を知ったうえで検証する
• 各言語版の canonical は自分自身に向け、hreflang を書く場所は1つにする
• 自動リダイレクトや URL の変わらない切り替えは避け、読者が言語を選べるようにする
• hreflang は正しい言語版を見せるための注釈で、順位を上げる仕組みではない

• Polylangで多言語サイトを作る設定方法
• WordPressのXMLサイトマップを設定する方法