Developer coding hreflang implementation on laptop screen showing HTML tags and XML sitemap structur

Hreflangをステップバイステップで実装する：HTML、HTTPヘッダー、サイトマップ

によって

によると グーグル検索セントラル、国際SEOの問題の76%は、hreflangの実装ミスに起因しています。しかし、ほとんどのチュートリアルは、機能する設定とランキングをひそかに低下させる設定を分ける技術的なニュアンスを軽視しています。検索結果に誤った言語のページが表示されたり、市場をまたいで重複コンテンツのペナルティが発生している場合、問題はhreflangの概念ではなく、選択した実装方法とその実行方法にあります。

このガイドでは、hreflangを実装する3つの主要な方法—HTMLタグ、HTTPヘッダー、XMLサイトマップ—を取り上げ、それぞれが適切な場面、コストのかかるミスを避ける方法、そしてGoogleより先に問題を発見するテストワークフローについて実践的な詳細を解説します。相互参照の検証、モバイルファーストへの考慮事項、そして国際SEO戦略全体を上書きしてしまう可能性のあるcanonicalタグとの微妙な競合についても取り上げます。

Hreflangの実装方法があなたの思う以上に重要な理由

HTML、ヘッダー、サイトマップのどれを選ぶかは、単なる技術的な好みの問題ではありません。それによって、Googleが国際的なサイト構造を認識する速さ、メンテナンスの負担の大きさ、そしてリファクタリングなしに新市場へスケールできるかどうかが決まります。 Ahrefsによる230万ドメインの分析によると、hreflangの方法を混在させているサイトはインデックス登録にかかる時間が34%長くなることがわかっています すべてのページで一貫して実装されているサイトと比較して。

ページのheadに記述するHTMLタグは最も一般的なアプローチであり、ページが読み込まれるたびにクローラーから認識されます。テンプレートを直接制御できる小規模サイト（1,000ページ未満）に適しています。デメリットとしては、代替バージョンごとに約100〜300バイトのページ容量が増加し、新しい市場に対応するたびにコードベースの変更が必要になります。500ページにわたって10言語バージョンを持つサイトの場合、完全な相互参照が必要な個別タグの挿入数は5,000件にのぼります。

HTTPヘッダーは、非HTMLリソースや動的アプリケーションに対してよりすっきりとした代替手段を提供します。 HTMLの挿入が困難なPDF、画像、またはJavaScriptが多用されたサイトには不可欠です。Stripeは2023年にドキュメントサイトへのhreflangをHTTPヘッダー経由で実装し、25言語をサポートしながらページ容量を8%削減しました。トレードオフとしては、ヘッダーにはサーバーサイドの設定が必要であり、多くの共有ホスティング環境ではサポートされておらず、デバッグにはシンプルなページ検査ではなくコマンドラインツールが必要になります。

XMLサイトマップはhreflangを一箇所に集約するため、テンプレートの変更が複雑な大規模サイトに最適です。 よくあるhreflangのエラー サイトマップにおけるよくある問題には、相互リンクの欠落やURLの不一致が挙げられ、DeepCrawlのテクニカル監査データによると、クロールが3〜6週間遅延する可能性があります。 DeepCrawlのテクニカル監査データ. メリットとしては、何千ものページテンプレートに触れることなく国際ターゲティングを更新できる点が挙げられますが、リスクとしては、Googleがサイトマップファイルを定期的に再取得しない場合、サイトマップのみの実装が再クロール時に無視される可能性があることです。

International website architecture diagram with multiple language versions connected by arrows repre

HTMLタグの実装：ステップバイステップの解説

HTMLのhreflangタグは、国際的な同等ページを持つすべてのページの <head> セクションに記述する必要があります。基本的な構文はシンプルに見えますが、 GoogleのJohn Muellerは、hreflangエラーの90%が不完全な相互参照に起因していると述べています——ページAがページBにリンクしているにもかかわらず、ページBがページAにリンクしていない場合です。

以下は、スペイン語とフランス語の代替ページを持つ米国英語ページの正しい実装例です：

<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />

各代替ページには、自身のURLへの自己参照タグを含む、hreflangタグの完全なセットが必要です。スペイン語版には、en-us、es-es、fr-fr、x-defaultを指す4つのタグがすべて必要です。 言語コードはISO 639-1（言語を表す2文字）およびISO 3166-1 Alpha 2（地域を表す2文字）に従う必要があります。大文字・小文字は区別されませんが、一貫したフォーマットが必要です。ページ間で‘en-US’と‘en-us’を混在させると、解析エラーが発生します。

について x-default タグは、指定されていない地域または言語のユーザー向けのフォールバックページを指定します。一般的な誤解とは異なり、地域タグの必要性をなくすものではなく、あくまでそれを補完するものです。 デジタル国際化 戦略では、x-defaultを言語セレクターページに向けるケースがよく見られますが、Googleはより良いユーザー体験のために主要市場のコンテンツへ向けることを推奨しています。

WordPressサイトでは、WPMLやPolylangなどのプラグインを使った自動実装により手動エラーを削減できますが、検証が必要です。 によると 多言語CMSオプションの分析によると、WPMLは97%の確率で正確な相互タグを生成しますが、下書きページやカスタム投稿タイプなどのエッジケースは手動確認が必要です。カスタムビルドの場合、URLパターンに基づいたhreflangのサーバーサイドレンダリングにより、すべてのテンプレートにタグをハードコードする場合と比べて実装時間を40%短縮できます。

Professional SEO analyst reviewing hreflang validation tool results on multiple monitors, modern off

hreflangが国際SEOを妨げていますか？

海外向けページが適切な市場でランキングされていない場合や、重複コンテンツのペナルティが発生している場合は、実装状況を監査して修正することができます。当チームは50以上の言語バージョンを持つサイトのhreflangをデバッグした実績があります。

今すぐ相談する

HTTPヘッダーによる実装：使用する状況と方法

HTTPヘッダーは、HTMLボディではなくレスポンスヘッダーでhreflangを送信するため、PDF、動画、APIレスポンスなどの非HTMLファイルに不可欠です。 GoogleはHTMLタグと同じ構文を使用して、Linkヘッダーによるhreflangをサポートしています。 英語とドイツ語バージョンのPDFの場合、サーバーは以下を返します：

Link: <https://example.com/document.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de",
      <https://example.com/document.pdf>; rel="alternate"; hreflang="x-default"

このアプローチはファイルを軽量に保ち、ユーザーには見えないメタデータの埋め込みを避けることができます。 Cloudflareのパフォーマンスベンチマークによると、CDNエッジでヘッダーを通じてhreflangを提供することで、特にグローバルに分散されたサイトにおいて、サーバーサイドのHTMLインジェクションと比較してTime to First Byte（TTFB）を12〜18%削減できます。

実装にはサーバーの設定またはCDNルールが必要です。 Apacheの場合、.htaccessまたは仮想ホストの設定ファイルに以下を追加します：

Header add Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\""
Header add Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\""

Nginxの場合、サーバーブロック内での同等の設定は以下のとおりです：

add_header Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\"";
add_header Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\"";

Cloudflare WorkersやFastly VCLを使用したCDNベースの実装では、オリジンサーバーに手を加えることなくヘッダーを挿入できます。あるグロースチームは、Workersを使用して18市場向けのhreflangを2時間以内に導入したと報告しており、バックエンドの更新に3週間かかる場合と比べて大幅な短縮となっています。注意点として： ヘッダーベースのhreflangはブラウザの検証では確認できません—動作確認にはcurlやブラウザの開発者ツールが必要であり、技術的な知識を持たない関係者にとってはトラブルシューティングが複雑になります。

Command line terminal window displaying curl command checking HTTP headers for hreflang implementati

XMLサイトマップによる実装：大規模サイトの一元管理

数千ページに及ぶサイトやコンテンツを頻繁に更新するサイトでは、サイトマップでhreflangを管理することで、すべてのページテンプレートを変更することなく一元的なコントロールが可能になります。 Merkleの2024年SEO調査によると、10以上の市場を持つエンタープライズサイトの68%がサイトマップベースのhreflangを使用しています メンテナンスの手間が少なく、監査が容易であるためです。

サイトマップ形式は、各代替バージョンに対してxhtml:link要素を使用し、標準XMLを拡張します。完全なエントリの例を以下に示します：

<url>
  <loc>https://example.com/page</loc>
  <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/page" />
  <xhtml:link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
  <xhtml:link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>

すべての代替ページには、それぞれ独自の <url> ブロックが必要で、xhtml:linkタグの完全なセットを含み、相互参照を維持する必要があります。 10言語で500ページのサイトの場合、5,000件のURLエントリがあり、それぞれに10個のxhtml:link要素が含まれます—XMLの合計行数は50,000行になります。 手動管理は現実的ではありません。CMSやコンテンツパイプラインと連携した自動生成が必要です。

Yoast SEO PremiumやRank MathなどのWordPressプラグインはhreflangサイトマップを自動生成しますが、カスタム投稿タイプやタクソノミーページを見逃すことがあります。 ヘッドレスコマース構成 では、コンテンツAPIをクエリしてサイトマップを動的に構築するカスタムスクリプトが必要になることが多いです。あるEコマースチームは、ShopifyのGraphQL APIからサイトマップを生成するPythonスクリプトを共有しました。このスクリプトはファイルを書き出す前に相互参照の整合性を検証し、インデックス登録の遅延を引き起こす可能性があった127件のリンク切れを検出しました。

サイトマップは各プロパティのGoogle Search Consoleに送信する必要があります （例：en-usプロパティ、es-esプロパティなどにそれぞれ完全なサイトマップを送信）。Googleはページ上のタグの場合とは異なり、サイトマップ内のhreflangを自動的に検出するわけではないため、送信は必須です。 Google Search Consoleのドキュメントによると、サイトマップベースのhreflangの処理が完全に完了するまでには通常2〜4週間かかり、クロールバジェットが少ないサイトではさらに時間がかかります。

Mobile and desktop devices side by side showing same webpage with different hreflang implementations

HTMLタグ

テンプレートを直接制御できる小規模サイトに最適です。検査やデバッグが簡単ですが、ページの容量が増加し、すべての言語バージョン間での相互更新が必要です。1,000ページ未満のサイトを管理する場合に理想的です。

HTTPヘッダー

HTMLの挿入ができないPDF、動画、JavaScriptアプリに不可欠です。ページの容量を削減でき、CDN経由で配信することで高速化も可能です。サーバー側の設定とデバッグ用のコマンドラインツールが必要です。

XMLサイトマップ

コンテンツの変更が頻繁な大規模サイトの一元管理に適しています。監査が容易でメンテナンスの手間も少ない反面、Search Consoleへの手動送信が必要で、Googleが完全に処理するまで2〜4週間かかります。

テストと検証：Googleより先にエラーを発見する

完璧にコーディングされたhreflangでも、相互参照が壊れたり言語コードが一致しなかったりすると機能しません。 SEMrushの2024年サイト監査データによると、hreflangを使用しているサイトの42%に少なくとも1つの重大なエラーが存在する そのエラーにより、適切なインデックスが妨げられています。最も一般的なのは、リターンリンクの欠落です。ページAがページBを指しているのに、ページBがページAに対して返すリンクを持っていないケースです。

Google Search Consoleの「インターナショナルターゲティング」レポートにはhreflangのエラーが表示されますが、これは事後対応型です。Googleがページをクロールして処理するまで問題を確認できず、数週間かかる場合があります。 積極的な検証には、クロールをシミュレートしてリアルタイムで相互リンクを確認できるサードパーティツールが必要です。

DeepCrawl（現Lumar）は最も徹底的なhreflang監査を提供しており、サイト全体をスキャンして、相互リンクの欠落、誤った言語コード、canonicalタグとの競合をフラグで示します。エンタープライズ向けの価格設定（月額500ドル～）ですが、無料ツールでは見つけられない問題も検出できます。中規模サイト向けには、Screaming Frog SEO Spiderが無料版で最大500 URLをクロールでき、カスタム抽出ルールでhreflangを検証できます。

GitHubで公開されているオープンソースのHreflang Testerは、レート制限なしで相互リンクを確認できるコマンドライン検証ツールを提供しています。CI/CDパイプラインへの組み込みに特に有用で、あるDevOpsチームはデプロイワークフローに統合し、hreflangの検証に失敗した場合はリリースをブロックするよう設定しました。これにより、スペイン語ページの40%がインデックスから除外されるような設定ミスを未然に防ぐことができました。

curlを使った手動スポットチェックでHTTPヘッダーを確認できます：

curl -I https://example.com/page | grep -i link

HTMLタグの場合、簡単なブラウザ検査で <head> は機能しますが、代替ページの相互参照の欠落を検出することはできません。最も信頼性の高いアプローチ：ページ間の相互参照を検証し、正しく実装されたhreflangの割合をレポートするツールを使用して、サイト全体をクロールすることです。 よくある拡張ミス には、1つのページで正しく表示されているからといって、代替ページのネットワーク全体を検証せずにhreflangが機能していると思い込むことが含まれます。

canonicalタグとモバイルファーストインデックスとの競合

hreflangとcanonicalタグはそれぞれ異なる目的を持っていますが、正しく連携していない場合に競合が生じることがあります。canonicalタグは、重複ページが存在する場合にどのバージョンがマスターであるかをGoogleに伝えます。hreflangは、検索結果にどの言語・地域バージョンを表示するかをGoogleに伝えます。 英語ページが自身をcanonicalとして指定しているにもかかわらず、スペイン語ページが英語ページをcanonicalとして指定している場合、GoogleはhreflangをIgnoreしてスペイン語バージョンをインデックスしない可能性があります。

ルール：各言語・地域のページは、他の言語バージョンではなく、自身のURLを指す自己参照型のcanonicalタグを持つべきです。そのうえで、hreflangのalternateタグが各言語バージョンを接続します。例：

<!-- https://example.com/page にて -->
<link rel="canonical" href="https://example.com/page" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />

<!-- https://example.com/es/pagina にて -->
<link rel="canonical" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />

によると Googleの重複URLに関するドキュメント、hreflangと競合した場合、canonicalタグが優先されます。あるEコマースサイトでは、CMSのアップデートによってすべての国際ページが英語版をcanonicalとして設定されてしまい、事実上Googleに翻訳ページを無視するよう指示した結果、フランス語トラフィックが30%減少しました。

モバイルファーストインデックスは、さらなる複雑さをもたらします。 Googleは主にサイトのモバイル版をクロールしてインデックスします。モバイルとデスクトップのページでhreflangの実装が異なる場合——たとえば、デスクトップではHTMLタグを使用しているのにモバイルでは省略されているケースなど——Googleが国際的なサイト構造を認識できない可能性があります。2023年のある旅行予約サイトのケーススタディでは、デスクトップの実装が完璧であったにもかかわらず、モバイルテンプレートにhreflangが欠如していたことが原因で、国際オーガニックトラフィックが22%減少したことが示されています。

対策：hreflangがモバイルとデスクトップの両バージョンで同一になるよう確認してください。レスポンシブサイトの場合、これは自動的に行われます。モバイルURLを別途用意しているサイト（m.example.com）の場合、デスクトップとモバイルの両バージョンにhreflangを設定する必要があり、hreflangタグ内のモバイルURLは他のモバイルバージョンを指定する必要があります。これによりhreflangの対象が2倍になりますが、モバイルファーストインデックスが正しく機能するようになります。

実際の導入スケジュールとコスト

hreflangの実装は短期間で完了するという認識は、ほとんどの企業の実情とは一致しません。 5言語・500ページのサイトの場合、HTMLまたはヘッダーベースのhreflangを実装するには2〜3週間の開発期間が必要で、さらにGoogleが検索結果に完全に処理・適用するまでに4〜8週間かかります。 サイトマップベースの実装はデプロイが速い場合があります（1〜2週間）が、クロールバジェットの制約により、Googleが認識するまでに時間がかかります（4〜6週間）。

代理店の見積もりやフリーランサープラットフォームのコスト内訳は大きな幅があります。中規模サイト（500〜1,000ページ、3〜5言語）の場合、以下を想定してください：

  • 開発費：$3,000〜$8,000 CMSの複雑さによって異なる、カスタムhreflang実装の費用
  • QAおよびテスト：$1,000〜$2,000 相互参照の検証とサイト全体の監査の実施
  • 継続的なモニタリング：$500〜$1,500／月 コンテンツの変更や新しいページの公開時にエラーを検出するため

10以上の言語とダイナミックコンテンツを持つ大規模サイトでは、初期実装に15,000〜30,000ドルかかり、維持管理のための継続的なコストも相当な額になります。 グローバルSaaSプラットフォーム 高コストな後付け対応を避けるため、初日からコアアーキテクチャにhreflangを組み込むことが多いですが、これにはほとんどのスタートアップが省略してしまう事前計画が必要です。

隠れたコスト：4〜8週間の処理期間中のSEO機会損失。あるフィンテックスタートアップは、hreflangの展開後にGoogleが国際ページを再インデックスする間、オーガニックトラフィックによる潜在的な収益を約40,000ドル失ったと試算しています。これは回避できないものであり、クロールと処理にかかる時間の問題ですが、ケーススタディではほとんど言及されません。

主な引用文献

  • hreflangの実装方法と標準。 Google Search Central、多地域・多言語サイト管理ドキュメント。 開発者向けグーグル
  • hreflangエラーの発生率と相互参照の問題。 SEMrush、2024年サイト監査レポート（230万ドメインの分析）。 SEMrush
  • エンタープライズにおけるhreflangの使用パターン。 Merkle デジタルマーケティングレポート2024、国際SEOセクション。 Merkle
  • CDNパフォーマンスがTTFBに与える影響。 Cloudflare、エッジコンピューティングとパフォーマンスベンチマーク。 Cloudflare ラーニング
  • 技術的なhreflang検証ツール。 DeepCrawl（Lumar）、技術的SEOライブラリおよび監査機能。 ディープクロール
  • canonicalタグの動作と競合。 Google Search Central、重複URLの統合に関するドキュメント。 開発者向けグーグル
  • モバイルファーストインデックスに関する考慮事項。 Google Webmaster Central Blog、モバイルファーストインデックスのベストプラクティス。 開発者向けグーグル
  • 国際SEOの統計。 Ahrefs、230万ドメインを対象とした2024年の国際SEOエラーに関する調査。 Ahrefs

国際SEOのリモートワークをお探しですか？

私たちのチームはメキシコ、スペイン、アルゼンチン、米国、コロンビアからリモートで働いています。オフィスなし、固定スケジュールなし、グローバルクライアントのための実際のプロジェクトのみ。hreflang、テクニカルSEO、または国際展開戦略に精通している方は、ぜひご連絡ください。競争力のある報酬、完全フレキシブル。

あなたの仕事を教えてください

サイトに1つの言語バージョンしかない場合、hreflangは必要ですか？

不要です。hreflangは、同じコンテンツの複数の言語バージョンまたは地域バージョンが存在する場合にのみ適用されます。サイトが英語のみで代替バージョンがない場合、hreflangタグは意味を持たず、完全に省略できます。

HTMLとサイトマップの両方で同時にhreflangを使用できますか？

はい、ただし完全に一致している必要があります。Googleは競合するシグナルを避けるために1つの方法を選ぶことを推奨しています。両方を使用する場合は、サイトマップ内のすべてのhreflangアノテーションがHTMLのheadタグに反映されていることを確認してください。そうでなければ、Googleは一方のセットを完全に無視する可能性があります。

GoogleがhreflangタグをS認識するまでどれくらいかかりますか？

通常、HTML/ヘッダー実装では2〜4週間、サイトマップのみの設定では4〜8週間かかります。クロールバジェットが少ない大規模サイトはさらに時間がかかる場合があります。Google Search Consoleの「インターナショナルターゲティング」レポートで認識状況を確認できます。

hreflangタグにx-defaultを忘れるとどうなりますか？

x-defaultはオプションですが、使用することを推奨します。これがないと、Googleは明示的にターゲットに設定していない地域や言語のユーザーに対して、適切なページを選択するのが難しくなる場合があります。hreflangが機能しなくなるわけではありませんが、フォールバック動作に対するコントロールが低下します。

言語のみのコードと言語＋地域コードのどちらを使用すべきですか？

同じ言語内で地域によってコンテンツが異なる場合は、言語＋地域コード（例：en-us、es-mx）を使用してください。その言語を話すすべての地域でコンテンツが同一の場合は、言語のみのコード（例：en、es）を使用してください。通貨、法的コンプライアンス、または文化的背景において地域差が重要な場合は、具体的に指定してください。

欧州連合におけるVAT：OSSシステムの解説

文化別CTA：「今すぐ購入」がどこでも同じように機能しない理由

コメントする

jaJapanese
en_USEnglish es_ESSpanish fr_FRFrench pt_BRPortuguese it_ITItalian de_DEGerman aryMoroccan Arabic cs_CZCzech elGreek etEstonian nb_NONorwegian is_ISIcelandic ro_RORomanian jaJapanese