機能プラグイン料金リソース
言語を変更
リソースマルチリンガルWordPressでhreflangタグを実装する方法

マルチリンガルWordPressでhreflangタグを実装する方法

SimplePoTranslate Team2026年5月31日
マルチリンガルWordPressでhreflangタグを実装する方法

WordPressサイト全体を6つの言語に翻訳しました。.poファイルはきれいで、.moファイルはコンパイルされ、すべての文字列がフランス語、ドイツ語、日本語で完璧に表示されます。しかし、公開から数週間後、Google Search Consoleを確認すると、不可解なことに出くわしました。フランス語のページがドイツ語のクエリでランク付けされ、スペイン語(メキシコ)のページがスペインの検索ユーザーに提供され、2つの言語バージョンがランキングでお互いを静かに共食いしていました。コンテンツに問題はありません。問題は、Googleがどのバージョンがどのオーディエンスに属するのかを全く理解していないことです。

これこそが、hreflang WordPressタグが解決するために設計された問題です。Hreflangは、検索エンジンに対し、ページのどの言語および地域バージョンをどのユーザーに提供すべきかを伝えるシグナルです。これを間違えると、重複コンテンツによる希薄化、誤った言語の結果、クロールバジェットの無駄に苦しむことになります。正しく設定すれば、各翻訳ページはそれが書かれたオーディエンスに届きます。このガイドでは、構文、言語と地域言語コードの違い、必須のx-default、リターンタグの相互関係、そしてWordPressでこれを実装する3つの実践的な方法について説明します。

hreflangが実際にすること

Hreflangは何も翻訳しません。それは関係性マップです。複数の言語で同じページがある場合、hreflangアノテーションはGoogleに「このURLは英語版、これはドイツ語版、これはメキシコのスペイン語話者向けです」と伝えます。Googleはそのマップを使用して、ユーザーの言語設定と位置に基づいて検索結果に正しいバージョンを提供します。

このアノテーションは、HTMLの<head>内に<link>要素のセットとして存在します。各要素はターゲットページとそれが提供する言語(およびオプションで地域)を指します。以下に、米国英語、英国英語、メキシコスペイン語で利用可能なページに対する、デフォルトのフォールバックを含む正しいhreflangタグのセットを示します。

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

セット内のすべてのページは、自身を含むすべての代替ページをリストアップし、この同じブロックを出力する必要があります。この最後の点がほとんどの人にとってつまずきやすいポイントであり、後ほどこれに戻ります。

SEOにとってこれが重要な理由

hreflangがない場合、Googleは翻訳されたページを、同じキーワードを競合するほぼ重複したコンテンツとして扱います。その結果、ランキングシグナルが統合されずにバージョン間で分散し、希薄化が生じます。正しいhreflangを使用すれば、各バージョンはセット全体の権威を継承し、適切な検索ユーザーに表示されます。これは多言語サイトが行える最も影響力の大きいSEO対策の1つであり、.poファイル内の実際のコンテンツ翻訳を置き換えるのではなく、補完するものです。コンテンツ側については、POファイルを翻訳することがGoogleランキングにどう影響するかに関するガイドで詳しく説明しています。

言語コード vs 言語-地域コード

enen-GBのどちらを使用すべきでしょうか? 真実である最もシンプルなコードを使用してください。英語のコンテンツが一般的で、イギリス版とアメリカ版を個別に維持していない場合は、enのみを使用します。異なる国に異なるコンテンツを実際に提供する場合にのみ、地域のサブタグを追加してください。

Hreflangの値はlanguageまたはlanguage-regionの形式に従います。言語部分はISO 639-1コード(enesdept)です。オプションの地域はISO 3166-1 Alpha 2国コード(USGBMXBR)です。したがって:

  • en は国に関係なくすべての英語話者をターゲットにします。
  • en-GB はイギリスの英語話者をターゲットにします。
  • es はすべてのスペイン語話者をターゲットにします。
  • es-MX は特にメキシコのスペイン語話者をターゲットにします。

重要な詳細:地域サブタグは言語のバリアントではなくです。es-MXは「メキシコスペイン語の方言」を意味するのではなく、「メキシコのユーザーに表示されるスペイン語」を意味します。Googleは引き続きユーザーの所在地に基づいてこれを配信します。翻訳で地域の方言を維持している場合、地域コードはそれらをルーティングする方法となります。これの言語学的側面については、スペイン語とポルトガル語の地域バリアントに関するガイドで詳しく掘り下げています。

よくある誤った例

以下に、私たちが常に目にする壊れたhreflangブロックを示します。

<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />

3つのエラーがあります。en-ukは、イギリスの国コードがGBでありUKではないため無効です。spは言語コードとして全く存在しません。スペイン語はesです。そして、pt-PT_BRはhreflangにおいて意味を持たないアンダースコアで2つの地域を混在させています。検索エンジンは不正な値を黙って無視するため、エラーもメリットも得られず、何時間もデバッグに費やしても何も変わらないと途方に暮れるだけです。

hreflangはハイフン(en-GB)を使用しますが、WordPressのロケールファイルはアンダースコア(en_GB)を使用することに注意してください。.poファイル名のコードをhreflangタグに直接コピーしないでください。

x-defaultとリターンタグの相互関係

他の何よりもhreflangのサイレントな失敗を引き起こす2つのルールがあります。それはx-defaultの欠如と、壊れた相互関係です。

x-defaultの値は、Googleに対し、ユーザーに合致する他の言語がない場合にどのページを提供すべきかを伝えます。これはあなたのフォールバックであり、通常は言語セレクターかプライマリー市場のホームページです。仕様上は厳密には必須ではありませんが、実際には常に含めるべきです。これがないと、ポルトガル語版がないポルトガル語話者の訪問者は、意図的なデフォルトではなく、ランダムな結果を受け取ることになります。

リターンタグの相互関係は譲れません。hreflangセット内のすべてのページは、自身を含む他のすべてのページを指し示す必要があります。もしあなたの英語ページがドイツ語を代替としてリストしているなら、ドイツ語ページは英語を代替としてリストしなければなりません。ドイツ語ページがリターン参照を省略すると、Googleは全体の関係性を信頼せず、アノテーションを無視します。

<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />

自己参照(ドイツ語ページを閲覧しているときに、deがドイツ語ページを指す)は必須であり、オプションではありません。5つの言語バージョンのセットは、5つの各ページが5つのすべての<link>タグとx-defaultを出力することを意味します。

WordPressでhreflangを実装する3つの方法

完全に手動で制御する方法から、完全に自動化された方法まで、3つの実践的なオプションがあります。

方法1:wp_headによる手動設定

小規模な静的ページセットの場合、テーマのfunctions.phpにあるwp_headアクションを通じてhreflangタグを直接挿入できます。

add_action( 'wp_head', function () {
    if ( ! is_page( 'pricing' ) ) {
        return;
    }
    $alternates = array(
        'en-US' => 'https://example.com/en-us/pricing/',
        'es-MX' => 'https://example.com/es-mx/pricing/',
        'x-default' => 'https://example.com/pricing/',
    );
    foreach ( $alternates as $lang => $url ) {
        printf(
            '<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
            esc_attr( $lang ),
            esc_url( $url )
        );
    }
} );

これにより正確な制御が可能になりますが、スケーラブルではありません。何百もの投稿にわたって相互関係を手動で維持することは、メンテナンスの落とし穴となります。

方法2:多言語プラグインの使用

Polylang、WPML、またはTranslatePressを実行している場合、hreflangは翻訳関係に基づいて自動的に生成されます。ほとんどのサイトにとってこれが適切な解決策です。なぜなら、プラグインはどの投稿がどの翻訳であるかをすでに知っているため、相互関係とx-defaultが自動で処理されるからです。その代償として、これらのプラグインが追加するランタイムオーバーヘッドがあり、これについては手動翻訳とAI翻訳のアプローチの比較で詳しく検討しています。

方法3:xhtml:linkを使用したXMLサイトマップ

hreflangをすべてのページの<head>に配置する代わりに、xhtml:link名前空間を使用してXMLサイトマップで関係性を宣言できます。各<url>エントリには、そのすべての言語代替がリストされます。

<url>
  <loc>https://example.com/en/about/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>

これにより、ページのHTMLは簡潔に保たれ、言語マップはクロール可能な単一ファイルに一元化されます。これはGoogleが喜んで読み取ります。ほとんどのSEOプラグインはこれを自動的に生成できます。

hreflangは翻訳を補完するものであり、置き換えるものではない

皆が見落とす点があります。それは、基になるページが実際に翻訳されていなければ、hreflangは無意味であるということです。このタグはGoogleに「これはドイツ語版です」と伝えますが、ドイツ語のURLがまだ英語のプラグイン文字列、未翻訳のチェックアウトラベル、または未完成の.poファイルを表示している場合、あなたは単にGoogleに対し、ドイツ語ユーザーに壊れたコンテンツを自信満々に提供するように指示したことになります。

真の多言語SEOは2つの層で構成されます。コンテンツ層は、翻訳された.po、.pot、.json、および.xliffファイルであり、すべてのテーマおよびプラグインの文字列をターゲット言語に変換します。シグナル層は、完成した各バージョンをそのオーディエンスにルーティングするhreflangです。どちらも堅固である必要があります。40パーセントしか翻訳されていないサイトの上に完璧なhreflangセットがあっても、単により悪い体験を迅速に保証するだけです。

ここで、翻訳層をきれいに保つことが最も重要になります。インターフェースファイルを翻訳する際、%s%1$s{name}のようなプレースホルダーは無傷で残らなければなりません。さもなければ、「翻訳された」ドイツ語ページは、ユーザーにも検索エンジンにも壊れて見えるリテラルな%sトークンで表示されます。構文ロックを備えたgettext対応の翻訳パイプラインは、これらのトークンを自動的に保護するため、hreflangが指すすべての代替ページは真に本番環境で利用可能になります。スマートバッチングによりクラウドで動作するため、それらのページを提供するランタイムを肥大化させる翻訳プラグインをインストールすることなく、サイト全体の複数ロケールを処理できます。

まずコンテンツを正しく設定し、それからhreflangにその仕事をさせましょう。この2つが合わさることで、ランキングシグナルを統合し、誤った言語の結果を排除し、各翻訳ページをそれを読める人々の前に表示します。

誤った言語の検索結果を根本から修正する準備はできていますか? SimplePoTranslateを無料でお試しください — クレジットカードは不要です。無料プランで.po、.pot、.jsonファイルを翻訳し、hreflangタグをすべての市場で実際に利用可能なページに設定しましょう。