多言語サイトのSEO設定において、最も見過ごされがちなのは翻訳品質ではなく、ページ間の国際化に関する関係性が明確であるかどうかです。多くのサイトでは英語、フランス語、ドイツ語、日本語のページがすでに用意され、正常にアクセスできるように見えても、検索エンジンはその一部しかインデックスしなかったり、ある国向けのバージョンを別の地域のユーザーに誤って表示したりする場合があります。調査すると、よくある原因はコンテンツ自体ではなく、hreflangの指定の競合、不足、または正規化リンクとの不整合です。
hreflangの役割は、単に検索エンジンに「これは外国語ページである」と伝えることではありません。どのURLが同一コンテンツ群に属するのか、それぞれがどの言語または地域を対象としているのか、特定の言語環境で検索したユーザーにどのバージョンを優先表示すべきかを明確に示すものです。海外向けコーポレートサイト、越境ECモール、多地域展開ブランドサイトでは、この関係性を一度誤ると、その後のコンテンツ更新、広告ランディングページの拡張、地域市場の運営において技術的負債が蓄積し続けます。
実際のプロジェクトでは、技術担当者が問題を「タグが記述されているかどうか」と捉えがちです。しかし、これは第一段階にすぎません。検索エンジンは国際版を判断する際、hreflang、canonical、ページの実際の言語、リダイレクトルール、サイトマップ、クロール可能な状態を同時に参照します。これらのシグナルが異なる方向を示している場合、ページソースにhreflangが存在していても採用されるとは限りません。
たとえば、ドイツ市場向けのページがhreflangではドイツ語・ドイツ向けバージョンとして指定されている一方で、canonicalが英語のグローバルサイトを指している場合があります。また、そのURLが訪問者のIPに応じて別のページへ自動転送されることもあります。検索エンジンにとっては、サイトが一方で「これは独立したドイツ向けバージョンです」と伝えながら、他方で「英語ページをメインバージョンとして扱ってください」と伝えていることになり、最終的に指定が無視される可能性が高くなります。
さらに見つけにくい競合として、CMSが言語リンクを一括生成する際に発生するものがあります。商品詳細ページにスペイン語版を追加したものの、英語ページ、フランス語ページ、サイトマップにはそのURLが同期して追加されていないケースです。あるいは、新しいページから旧ページへのリンクだけがあり、旧ページからの逆方向リンクがない場合もあります。hreflangは検証可能な双方向の関係を構成する必要があり、一方向の通知ではありません。1つの言語セット内のページは相互に確認し合う必要があり、戻りリンクが欠けると、指定グループ全体の信頼性が低下します。

多言語サイトのSEO設定では、URLアーキテクチャとしてサブディレクトリ、サブドメイン、国別ドメインがよく用いられます。どの方法が絶対的に優れているということはなく、重要なのはアーキテクチャ、コンテンツ、指定を長期的に一貫させられるかどうかです。本当に問題になりやすいのは、企業が「英語ページ」を当然のように「米国向けページ」と見なしながら、英国、オーストラリア、カナダ向けにも複数の英語版を設定し、それらのページが通貨記号や連絡先を除けばほぼ完全に同じであるケースです。
ページが地域ごとに異なる価格、税金の説明、配送対応、コンプライアンス情報、連絡先、購買条件を実際に提供している場合、地域別の設定は合理的です。一方、コンテンツや取引条件に明確な違いがない場合、過度な細分化は保守コストを増加させ、誤ったマッピングの可能性も高めます。特にB2B製造業サイトでは、多くの問い合わせページは本質的に世界中の購買担当者を対象としています。多数の国別ページを個別に作成する前に、その市場に独立した営業対応とコンテンツのニーズがあるかを判断すべきです。
言語と地域の定義も、サイト全体のルールとして統一する必要があります。簡体字中国語は中国本土向け、繁体字中国語は特定地域向け、英語はグローバル向けか特定国向けかを、運営担当者ごとに個別に決めるべきではありません。プロジェクトの立ち上げ段階で、「ページ言語―対象市場―URL―正規ページ―代替ページ」のマッピング表を作成することを推奨します。この表は複雑である必要はありませんが、サイト構築、コンテンツ、広告運用、技術チームが共通して使用する基礎資料でなければなりません。
1つ目は、言語コードとページの実際のコンテンツが一致しないことです。ページの本文が明らかに英語であるにもかかわらず、中国語の言語識別子を使用している、あるいは機械翻訳が未完了で、ナビゲーションは英語なのに本文は中国語のままである、といったケースです。検索エンジンはタグだけを読み取るのではなく、ページテキストの言語も識別します。タグとコンテンツが明らかに一致しない場合、指定は無効になりやすくなります。
2つ目は、URLの状態が要件を満たしていないことです。hreflangの関係に参加するページは、通常のコンテンツを安定して返す必要があり、リダイレクトページ、noindexページ、ログインページ、ソフト404ページであってはならず、robotsルールによってクロールを妨げられていてもいけません。多くのサイトではリニューアル後に旧言語URLが残され、hreflangがすでにリダイレクトされたアドレスを指し続けています。このような問題は一括移行でよく見られます。
3つ目は、canonicalが言語をまたいで不適切に指定されることです。通常、各言語または地域ページは自分自身を指す正規化リンクを使用し、そのうえでhreflangにより代替バージョンを宣言するべきです。複数のページが実際に完全に重複しており、独立して表示する価値がない場合を除き、フランス語、日本語、地域別バージョンをすべて英語ページへ正規化しないでください。canonicalは「同一ページの優先URL」を決定し、hreflangは「異なる対象者に対応する代替URL」を示すものであり、両者は互いに代用できません。
4つ目は、デフォルトバージョンの設定が実態と乖離していることです。言語または地域を正確に一致させられないユーザー向けには、デフォルトのランディングバージョンを設定できます。ただし、デフォルトバージョンがすべてのページの代替となるべきではなく、特定の国市場向けページとして誤って設定してはいけません。グローバル企業にとって、デフォルトページは一般的な英語コンテンツまたは言語選択ページの受け皿として適していることが多いですが、それ自体がアクセス可能で理解しやすく、ユーザーの選択を強制的に妨げないことが前提です。
hreflangはページヘッダーに配置することも、XMLサイトマップで管理することもできます。一部の非HTMLファイルでは、HTTPレスポンスヘッダーによる宣言も可能です。大半の企業サイトでは、ページヘッダーをシステムが自動生成する方法のほうが一般的に直感的で、個別ページの抜き取り確認にも便利です。言語バージョン数が多く、商品SKUの変更が頻繁な場合は、サイトマップで一元管理することにも利点があります。両方式は併用できますが、同じURLの関係は完全に一致していなければなりません。重複した宣言は問題ではありませんが、不一致は危険です。
方法が信頼できるかどうかは、非常に実務的な問いで判断できます。新しい商品を追加する、ある地域バージョンを終了する、URLを変更する、ドメインを移行する際、システムは関連する言語セットを自動的に同期できるでしょうか。答えが担当者によるページごとのコードコピーに依存するなら、規模が少し大きくなっただけでも、ほぼ確実にミスが発生します。易営宝のように、スマートサイト構築、越境ECモール、SEO、海外マーケティングを同一ワークフローに統合したプラットフォームの価値は、多言語ページを生成することだけではありません。ページ言語、地域ディレクトリ、正規リンク、サイトマップを統一ルールに基づいて管理できることにあります。継続的な新商品追加や広告ランディングページの運用が必要なチームにとって、これは一時的なタグ補完よりも重要です。
hreflangを確認する際、ブラウザでソースコードを表示しても「タグが存在する」ことしか確認できず、「関係性が有効である」ことは証明できません。より確実な方法は、トップページ、主要カテゴリページ、商品ページ、コンテンツページ、広告ランディングページを抽出し、各ページグループに自己参照が含まれているか、双方向に相互リンクされているか、URLが正常な状態を返すか、canonicalがそれぞれ正しいページを指しているかを確認することです。サイトマップ内のURL数と実際にインデックス可能なページ数も、定期的に照合する必要があります。
自動言語リダイレクトにも注意が必要です。ブラウザ言語に応じて控えめな案内を表示することは検討できますが、検索エンジンや一般ユーザーに対して、サーバーが制御不能な強制リダイレクトを実行することは推奨されません。ユーザーは日本にいても英語の技術資料を閲覧したい場合があり、海外の調達プラットフォームを通じて特定言語のページへ直接アクセスする場合もあります。目に見える言語切り替え入口を残し、各バージョンに独立して安定したURLを持たせることは、通常、「ユーザーに代わって決める」よりも堅実です。
多言語SEOで本当に難しいのは、サイト構築ルール、コンテンツ制作、市場運営が長期的に同じ言語で意思疎通できるようにすることです。特にサイトを北米、欧州、東南アジア、中東、ラテンアメリカへ拡大した後は、市場を追加するたびに、まずマッピング関係を完全に整えてからページを公開すべきです。hreflangを公開直前の最後の一分間に行うコード作業と捉えると、問題を修正することしかできない場合が多くなります。これを情報アーキテクチャに組み込むことで、各地域ページが本来得るべき表示機会を得やすくなります。
関連記事
関連製品