hreflangと多言語SEOを実務で動かす 4つの設計順序と検証軸

海外向けページを増やしたのに、日本の検索結果に英語版が出る。台湾向けページを作ったのに、シンガポール向け英語ページと評価がぶつかる。制作側は `hreflang` を実装済みだと言うのに、実際の流入を見ると想定外の国から来訪が続く。多言語SEOの現場では、この三つが同時に起こることも珍しくありません。

理由は単純です。`hreflang` を「タグの書き方」の問題として扱い、どの市場にどのページを残すのか、URL をどうそろえるのか、`canonical` をどこへ向けるのかという上流の判断を後回しにしているからです。`hreflang` は魔法ではなく、運用方針を検索エンジンへ伝える最後の整備項目です。方針そのものが曖昧なら、タグだけ整えても露出の混線は止まりません。

結論から述べます。多言語SEOを安定させたいなら、最初に決めるべきなのはタグではなく「市場ごとに残すページの範囲」です。 そのうえで URL 構造を固定し、独立ページとして残す条件を数値で決め、`canonical` と `hreflang` の役割をそろえます。URL 変更があるなら移行案件として扱い、公開後は八週間を区切って混線を監視する。この順序を崩さないことが最重要です。

Google の 多言語サイトの管理 と 複数地域向けサイトの管理 を読むと、見られているのはタグ単体ではなく、ページ同士の関係、表示コンテンツ、利用者向けの整合だと分かります。実務では、その原則を運用判断へ落とし込めるかどうかで差がつきます。

市場ごとの役割を公開前に固める判断基準

`hreflang` を単なる翻訳タグと捉えると、設計はほぼ確実に崩れます。役割は、同じ主題を扱う複数ページのうち、どの市場の利用者にどの版を優先して見せるかを伝えることです。つまり、翻訳の有無より先に「その市場で何を売るページなのか」を決めなければなりません。料金を問い合わせにつなげるのか、事例で比較検討を進めるのか、資料請求を増やすのか。ここが曖昧なままページだけ増やすと、言語版と国別版が混ざり、検索結果も商談導線も不安定になります。

Google は 複数地域向けサイトの管理 で、言語判定は URL や `lang` 属性だけではなく、実際に表示される本文をもとに行うと案内しています。日本語版の導線に英語ナビゲーションが大量に混ざるページや、日英併記を一画面に押し込んだページは、想定より判定がぶれやすい構成です。同じ文書では、IP やブラウザ言語だけを根拠にした自動転送も避けるよう示されています。したがって、入口で利用者を強制的に別版へ飛ばす設計は避けるべきです。 クローラーが全版へ到達しにくくなるうえ、利用者の選択肢も狭まります。

ここでの推奨は明確です。市場差が小さい段階では、まず「言語別」で始めるべきです。国別で分けるのは、売上・法規制・訴求内容の差が確認できてからで十分です。 実務では、次の三条件のうち二つ以上を満たすまでは、国別ディレクトリを増やさないほうが安定します。

• 海外売上のうち、対象国が全体の 10% 以上を占めている
• その国からの月間問い合わせが 15 件以上あり、専用導線の必要性が見えている
• 価格、契約条件、導入事例、法務表現のうち二項目以上が他国と異なる

逆に、この条件を満たさないまま国別ページを量産すると、半年後には「翻訳はあるのに更新が止まったページ」が積み上がります。月間 PV 10万未満のサイトでこれを進めると、国別ページを持つこと自体が負担となり、検索評価より先に運用が息切れしがちです。最初にページ数を増やすより、主要ページの役割を言語別でそろえるほうが成功率は高くなります。

判断に迷う場合は、次の三つで決めるのが現実的です。

• 月間 PV 10万未満で、海外向け導線をこれから整える段階なら、日本語版とグローバル英語版の二層から始めるべきです。 料金、問い合わせ、主要サービスだけ先に翻訳し、ブログや採用情報まで広げないほうが失敗しません。
• 月間 PV 10万から100万で、英語圏と繁体字圏の両方を狙うなら、売上比率 10% 以上または問い合わせ比率 15% 以上の市場だけ国別ページを作るべきです。 それ以外は言語別ページへ集約します。
• 月間 PV 100万以上で、法務、価格、事例の差が大きいなら、料金、事例、契約条件の三つだけ先に国別化すべきです。 ブログやコラムまで同じ粒度で国別化すると、更新負担のほうが先に膨らみます。

例外もあります。現地法規制で独自ドメインや独自表記が求められる国、現地営業組織が独立して予算を持つ国、国別の価格表示が売上に直結する国です。こうした市場は、初期段階でも国別ページを持つ価値があります。ただし、その場合でも国別化の対象は全ページではありません。まずは商談に近いテンプレートへ絞るべきです。

URL構造はサブディレクトリを軸に決める

URL 構造は早い段階で固定する必要があります。ここが曖昧なまま進むと、`hreflang`、`canonical`、内部リンク、サイトマップ、計測設計まで一緒に揺れます。新規に多言語展開を始めるなら、最初の選択肢はサブディレクトリです。 たとえば `/ja/` `/en/` `/zh-tw/` のように、1 ドメイン配下で言語や地域を切る構成です。これは Google: 複数地域向けサイトの管理 と Google: URL 構造のガイドライン の考え方とも整合します。

理由は三つあります。第一に、既存ドメインの評価を分散させにくいこと。第二に、Search Console、解析、テンプレート管理、配信設定を一本化しやすいこと。第三に、運用人数が少なくても保守しやすいことです。海外展開の初期段階で ccTLD やサブドメインを増やすと、SEO の難易度より先に運用の難易度が跳ね上がります。DNS、証明書、リダイレクト、サイトマップ、計測タグ、CDN 設定まで分散し、担当者が少ない事業組織では整合を保ちにくくなります。

比較すると差は明確です。

月間 PV 30万未満の段階で ccTLD を先行させる判断は勧めにくいと言えます。国ごとの独立性を持たせても、その独立性を支える更新体制がないからです。ページを分けるだけでは成果にならず、中身の薄い国別サイトが複数残りやすい。「いつか現地運用するかもしれない」程度の理由なら、サブディレクトリにとどめるべきです。

URL の命名ルールも甘く見ないほうがいいポイントです。Google: URL 構造のガイドライン が示す通り、URL は短く、意味が分かり、表記ルールが一貫していることが前提です。実務では、次の四つを固定しないまま公開すると、後で必ず移行コストが発生します。

• 言語コードは `en` と `en-us` を混在させず、運用ルールを一つに絞る
• 末尾スラッシュの有無を統一する
• `/service/` と `/services/` のような複数形の揺れをなくす
• 国別ページだけ和文スラッグにするなど、言語横断で命名基準を変えない

判断に迷うなら、次のように割り切るべきです。

• 国内本体サイトに英語版を足すだけなら、サブディレクトリ一択です。
• ある一国が海外売上の 30% 以上を占め、法規制も別運用なら、その市場だけ ccTLD を検討すべきです。
• すでにサブドメインが乱立しているなら、新規市場はサブディレクトリへ寄せ、旧構成は主要テンプレートから段階的に統合すべきです。 全面移行を急ぐより安全です。

記事ページやお役立ち資料まで国別で分けるかどうかも悩みどころですが、記事は原則として言語別、商談に近いページだけ国別を推奨します。記事まで国別で分けると、検索意図の差より更新停止のリスクが先に大きくなるからです。

国別ページを残す条件を数値で切り分ける

`hreflang` が効かない案件の多くは、タグ設定の前に「残すべきページ」と「統合すべきページ」の判断を誤っています。内容差が弱い国別ページは、残すべきではありません。 国名だけ変えた導入事例、通貨表記だけ変えた料金ページ、問い合わせ先だけ差し替えたランディングページを大量に持っても、評価は分散しやすく、更新管理も崩れやすい。検索流入を増やすどころか、どの版を正本として扱うべきか自分たちで迷う状態になります。

判断基準は感覚ではなく数値で持つべきです。実務では、次の三条件のうち二つ以上を満たす場合だけ、国別に残す判断が安定します。

• 本文差分が 30% 以上ある
• 価格、納期、提供条件、事例、法務表現、問い合わせ導線のうち二項目以上が市場別で異なる
• その市場向けに独立した検索需要が確認できる

反対に、本文差分が 20% 未満で、変わるのが通貨と数行の注意書きだけなら、統合したほうが強くなります。ページを分ける理由が弱く、`canonical` と `hreflang` の整合も取りづらくなるからです。「翻訳済みだから残す」は判断理由になりません。 残すべきかどうかは、利用者にとって別ページである意味があるかで決めるべきです。

実務では、テンプレート単位で判断すると迷いません。

テンプレート設計の考え方は、ECサイト商品ページSEOの実務基準 商品情報と構造設計で評価を積み上げる とも共通しています。ページ単位で悩むより、サービス詳細、料金、FAQ、事例、資料請求完了ページといった「型」で決めるほうが、後からぶれません。

構造化データもここで足並みをそろえる必要があります。市場別ページで価格や提供地域を変えるなら、本文だけでなくマークアップも市場ごとに整えるべきです。HTML では別市場向けの説明をしているのに、構造化データは共通のままという状態は避けたいところです。その整理は JSON-LDの書き方を実務で整理 ツールを使って安全に実装する基本手順 と Schema.orgマークアップの最新トレンド Google対応と実務設計のずれを埋める が参考になりますが、順序は変わりません。先に残すページを決め、その後で構造化データを合わせます。

ケース別に言い切ると、こうなります。

• 価格、サポート範囲、問い合わせ窓口が国ごとに違うなら、そのテンプレートは国別ページとして残すべきです。
• 本文差分が 20% 未満で、変更点が通貨と注意書きだけなら、統合すべきです。
• ブログやお役立ち記事のように市場差が小さい領域は、原則として言語別へ寄せるべきです。 国別化は検索意図が明確に違うテーマだけに絞ります。

例外はあります。補助金制度、医療、金融、法規制対応のように、本文差分が 20% を超えなくても利用者の意思決定に大きく影響する情報がある場合です。こうした領域では、差分量ではなく責任範囲で独立ページを持つ価値があります。

canonicalとhreflangの役割を整理する

ここは誤解が非常に多い箇所です。`canonical` は「このページ群の正本はどれか」を伝える信号で、`hreflang` は「言語や地域の違いに応じてどの版を見せたいか」を示す信号です。役割が違う以上、出し分けたいページに対して、別ページへ `canonical` を向けるべきではありません。 これをすると、残したいのか統合したいのかという意図が検索エンジンへ矛盾して伝わります。

Google: 重複 URL の統合 と Google: 重複した URL の正規化 を読むと、`hreflang` を使う場合は、同じ言語の `canonical`、または最も近い代替言語を選ぶ考え方が前提です。つまり、米国向け英語ページと英国向け英語ページを別々に出し分けたいなら、それぞれが自己参照の `canonical` を持つのが基本です。国別に残すなら自己参照、統合したいなら最初からページを減らす。 この二択で考えるべきです。

実務では、次の四ルールで整理すると判断しやすくなります。

• 別市場へ出し分けたいページは、自己参照 `canonical` を基本にする
• 内容差が弱く統合するページは、統合先へ `canonical` を向け、`hreflang` の対象から外す
• `hreflang` は、対応するページ同士で相互参照が成立していることを前提にする
• `x-default` は、言語選択ページや地域選択ページのように、未確定利用者の着地点がある場合だけ使う

Google: 多言語サイトの管理 でも、相互参照がそろっていない `hreflang` は無視されうると案内されています。トップページだけ整っていても足りません。成果に直結するのは下層ページです。料金、サービス詳細、事例、FAQ など、商談に近いページから相互参照をそろえるべきです。

実装前には、少なくとも次の六項目を機械的に確認したほうが安全です。

• 各言語版・地域版の URL 一覧が確定している
• 対象ページがすべて 200 を返している
• `canonical` が自己参照または正しい統合先を向いている
• `hreflang` が双方向で成立している
• `x-default` の着地点が実態と合っている
• サイトマップ、パンくず、言語切替リンクが同じ URL 一覧を参照している

例外として、新市場を後から追加する場面では、過去の全ページを一気に直すのが難しいことがあります。その場合でも、基準言語ページとの双方向参照だけは先にそろえるべきです。 主要言語と新市場の組み合わせから整え、下層ページへ広げる順で進めるほうが安全です。

移行案件はURL対応表から逆算して進める

多言語対応では、旧 `/english/` を `/en/` へ統一したり、国別ディレクトリを新設したりと、URL 変更が起こりやすくなります。このときにやるべきことは一つです。URL が変わるなら、軽い修正ではなく移行案件として扱うべきです。 Google: 301 リダイレクトの使い方 が示す通り、検索結果に出る URL を変えるなら、恒久的なサーバー側リダイレクトを使うのが原則です。JavaScript やメタリフレッシュで済ませるべきではありません。

さらに Google: URL 変更を伴うサイト移行 では、旧 URL と新 URL の対応表を作り、新 URL 側の `canonical` と `hreflang` を更新し、内部リンクも差し替え、リダイレクトを十分に検証する流れが整理されています。実務では、翻訳表より先に URL 対応表を作るべきです。 これがない移行は、ほぼ必ず漏れます。HTML だけでなく、PDF、画像、資料請求 URL、埋め込みフォーム、カテゴリ一覧、絞り込みページまで含めて管理する必要があります。

公開前の移行準備で重視したいのは、量ではなく対応の正確さです。実務では、次の基準で進めると漏れが減ります。

• 主要テンプレートごとに 20 URL 以上を抽出して転送試験を行う
• 旧 URL から新 URL への転送は、原則として 1 対 1 にする
• 関係のないページをまとめてトップページへ飛ばさない
• `canonical`、内部リンク、サイトマップは公開前に新 URL へ切り替える
• リダイレクトは少なくとも 1 年維持する

この「1 年維持」は軽く見ないほうがいい条件です。Google: URL 変更を伴うサイト移行 でも同様の考え方が示されています。公開後 2 週間で旧 URL を止める運用は危険です。外部リンク、ブックマーク、古い検索結果、提携先サイトからの参照が残るため、早く切るほど損をします。

加えて、`hreflang` 案件では HTTP ステータスも軽視できません。Google: HTTP ステータス コード を踏まえると、`hreflang` の参照先が 404 や 5xx を返している状態は論外です。切替ページがスマートフォン表示でだけ失敗するケースもあるため、Google: モバイル ファースト インデックスのベスト プラクティス を前提に、スマートフォン表示でも同じ本文と同じリンク構造が確認できるようにしておくべきです。

多言語移行でやるべきことと避けるべきことを並べると、判断しやすくなります。

例外は、統合して消すページです。統合先が明確で、検索意図も一致しているなら、1 対 1 ではなくカテゴリページや統合ページへ寄せる判断もあり得ます。ただし、その場合は「なぜその統合先なのか」を説明できることが条件です。説明できないなら、転送先の選定が粗いと言えます。

公開後八週間で混線を止める確認の進め方

多言語SEOの成否は、公開日の実装完了では決まりません。本当の勝負は公開後八週間です。 `hreflang` の実装が正しくても、内部リンク、サイトマップ、転送、クロールの入り方にズレがあれば、露出は簡単に混線します。公開後に何を見るかまで決めていない案件は、問題が起きても原因を切り分けられません。

監視は、インデックス数だけでは足りません。見るべきなのは「想定した市場で、想定した版が出ているか」です。実務では、八週間を次の三段階で見ます。

• 1週目: 主要ブランド語と主要商材語で、誤った言語版が出ていないかを確認する
• 2週目から4週目: 旧 URL の残存、転送エラー、サイトマップ反映、代表テンプレートの到達先を確認する
• 5週目から8週目: 国別・言語別の表示 URL の比率を見て、誤出現が収束しているかを確認する

基準を数字で持つと判断が速くなります。たとえば、主要商材語 20 件を目視確認したとき、誤った言語版や国別版が 3 件以上混ざるなら、まだ設計か実装のどこかが揺れています。主要テンプレート 20 件で `canonical`、`hreflang`、200 応答、言語切替リンクを再点検したほうがいい段階です。公開後四週間時点で誤出現率を 10% 未満、八週間で 5% 未満へ下げることを一つの目安にすると、判断しやすくなります。

よくある誤設定は、結局この四つに集約されます。

• 国別ページを作ったのに、`canonical` が共通英語ページを向いている
• トップページだけ `hreflang` がそろい、下層ページが片方向のまま
• ブラウザ言語や IP で自動転送し、他言語版へ入れない
• 旧 URL の転送先が粗く、関連の薄いページへ飛ばしている

この四つはどれもタグの知識不足ではなく、設計の矛盾が原因です。だから対処も同じです。タグを書き換える前に、残すページ、URL の正本、転送先、内部リンクの規則を見直します。`hreflang` が効かない案件ほど、問題はタグの一行ではなく、上流の判断にあります。

更新停止ページも見落としやすいポイントです。半年以上更新されず、料金や事例が古い国別ページは、`hreflang` が正しくても成果を出しません。検索エンジンへ「この市場向けに独立して価値がある」と伝えたいなら、その市場向けに情報を更新し続ける責任も必要です。更新できない国別ページは、無理に残すべきではありません。 言語別ページへ寄せたほうが、結果として強いことは珍しくありません。

今日から着手する七つの実務確認項目

ここまでの話を、実務で動かせる順番に落とすと七項目です。多言語SEOは論点が多く見えますが、現場で先に片づけるべき項目はそこまで多くありません。

• 主要市場ごとに、残すテンプレートと統合するテンプレートを一覧化する
• 国別に残す条件を、本文差分 30% 以上または差分二項目以上と明文化する
• URL 構造をサブディレクトリ中心で固定し、命名ルールの揺れを止める
• `canonical` と `hreflang` の対応表を作り、自己参照と相互参照の整合を確認する
• URL 変更がある場合は、旧 URL と新 URL の対応表を先に作る
• 公開前に主要テンプレート 20 件以上で、200 応答、転送、言語切替、サイトマップを点検する
• 公開後八週間の監視対象を決め、誤出現率と旧 URL 残存を週次で確認する

この七項目を先に片づけるだけで、`hreflang` は「分かりにくい技術設定」から「運用の整合を保つ管理項目」へ変わります。逆に、この順序を飛ばしてタグだけ追加すると、三か月後も同じ原因調査を続けることになりかねません。

JPSM SEO 編集事業部でも、多言語サイトの見直しではまずテンプレート一覧と URL 対応表の整備から入ります。ここが曖昧な案件ほど、`hreflang` の修正回数だけ増え、成果が安定しません。現場で効くのは、タグの小手先ではなく、残すページを減らし、正本をそろえ、公開後の監視をやり切る運用です。

最初の一歩は明確です。今日中に、主要市場ごとの「残すテンプレート」「統合するテンプレート」「URL 変更の有無」の三列だけでも一覧にしてください。 その表ができれば、`hreflang` を入れる前に直すべき箇所が見えてきます。そこまで整理してから実装に入るほうが、結果として早く、事故も少なく済みます。