多言語ページを結ぶ4つの指定｜言語の取り違えを防ぐ

海外の見込み客に届けたいという話が出て、英語版のページを用意した。ここまでは順調です。ところが公開してしばらくすると、日本から検索した人に英語版が出る、英語圏の人に日本語版が出るという取り違えが起きます。原因はページの中身ではなく、版と版を結ぶ指定の不備です。ここでは何をどう書けば取り違えが止まるのかを、必要な4つの指定として順に整理します。

同じ内容の別言語ページで起きること

多言語のサイトでは、同じ内容がURLだけを変えて複数存在します。検索エンジンから見ると、これはよく似た中身のページが並んでいる状態です。どれを誰に出すべきかという判断が、中身だけからは決まりません。

結果として2つの困りごとが起きます。1つは表示の取り違えです。日本語を使う人に英語版が出る、英語圏の人に日本語版が出る。訪れた人は読めないページに着地し、すぐに離れます。

もう1つは評価の分散です。同じ内容の版が別々に扱われると、集まるはずだった評価が分かれます。どちらの版も中途半端な位置に留まる、という結果になりがちです。版が増えるほどこの傾向は強まります。

困るのは、この2つが数字に出にくいことです。訪問の数は伸びているのに問い合わせが増えない、海外からの流入はあるのに滞在が極端に短い。取り違えは離脱として記録されるため、原因が見えにくいのです。

各版に独自のURLを与える

指定の話に入る前に、前提となる構造を押さえます。検索エンジンはページごとに言語を識別しています。つまり、言語の版それぞれが独自のURLを持っていることが出発点になります。

同じURLのまま、訪問者の環境を見て表示する言語を切り替える作り方は、この前提を満たしません。URLが1つしかなければ、検索エンジンから見える版も1つだけです。他の言語の版は存在しないものとして扱われます。

URLの分け方は3通りあります。国ごとに別のドメインを使う形、同じドメインの下に言語ごとの区画を作る形、そしてアドレスの末尾に条件を付け足して切り替える形です。このうち3つ目は、地域の対象を認識できない可能性があるとして公式に勧められていません。

実務では、区画を分ける形が扱いやすい選択です。1つのドメインに評価を集められ、設定の手間も国別のドメインより軽くなります。国ごとに法人や担当が分かれている場合に限り、別ドメインを検討する、という順序で考えると迷いません。

言語の指定は何を伝えているのか

ここで誤解が生まれやすいので先に整理します。版どうしを結ぶ指定は、順位を上げるための指定ではありません。伝えているのは「これらは同じ内容の別の言語版である」という関係だけです。

この関係が伝わると、検索エンジンは似た内容の重複として扱わず、利用者の言語や地域に合う版を選んで出せるようになります。つまり効き目が出るのは順位ではなく、誰にどの版を見せるかという出し分けの部分です。

もう1つ押さえておくことがあります。Googleは、この指定やページに書いた言語の属性から言語を判定していません。言語の判定は本文の内容から独自に行われます。指定は関係を伝えるためのもので、言語を宣言するためのものではないと理解しておくと混乱しません。

指定を書く3つの場所

指定を書ける場所は3つあり、どれを選んでも効果は同じです。違うのは書きやすさと管理のしやすさです。自社のページ数と体制で選びます。

書く場所	向いている規模	注意点
ページの案内書きの領域	少数の版・少数のページ	版が増えると行数が膨らむ
サーバーが返す通信の見出し	文書ファイルも含む場合	サーバー側の設定が必要
サイトの地図のファイル	ページ数が多い場合	生成の仕組みが必要

最初に選ぶなら、ページの案内書きの領域が扱いやすいです。書いた内容がそのまま目で確認できるため、間違いに気づきやすいという利点があります。小規模なサイトではこれで十分です。会社の案内と主要なサービスの説明だけを訳す段階なら、この形で始めて構いません。

一方、ページ数が増えると案内書きの領域が肥大化します。版が5つあるサイトで千ページを扱うなら、1ページあたり5行を全ページに入れる計算になります。ページ数が多い場合はサイトの地図のファイルに寄せるほうが管理が破綻しません。

指定1：自分自身も一覧に入れる

1つ目の必須の指定は自己参照です。各ページに書く版の一覧には、そのページ自身も含めます。他の言語版だけを並べる書き方は不完全な指定として扱われます。

日本語版のページに書く一覧の例
ja        https://example.com/ja/   自分自身
en        https://example.com/en/
zh-Hant   https://example.com/tw/

自己参照が抜けやすいのは、道具で自動生成しているときです。「他の言語版を列挙する」という考え方で作ると、自分を含めるという発想が漏れます。確認の際は、まず自分自身の行があるかを見ます。

この指定が必要な理由は、一覧の完全性です。どの版から見ても同じ顔ぶれの一覧が返る状態が正しい形です。版ごとに一覧の中身が違うと、関係が成立しません。版が3つあるなら、3つのページすべてに3行の一覧が入るのが完成した状態です。

指定2：互いを指し合う

2つ目は相互参照です。ページXがページYを別の版として指すなら、ページYもページXを指していなければなりません。片方向だけの指定は無視される可能性があります。

この決まりには理由があります。片方向で成立してしまうと、無関係な第三者が「このページは自分のページの別の言語版だ」と勝手に申告できてしまいます。双方が指し合っていることを、正しい申告の条件にしているわけです。

実務でここが崩れる原因は、版の追加です。後から中国語版を足したとき、中国語版には日本語版と英語版への指定を入れたが、既存の2つの版に中国語版への指定を足し忘れる。この形が最も多い失敗です。版を足すときは、既存の全ページの一覧も同時に更新します。

指定3：言語と地域のコードを正しく書く

3つ目はコードの書き方です。言語のコードと地域のコードは、それぞれ国際的な規格で決まった2文字を使います。組み合わせるときは、言語のコードのあとに地域のコードを続けます。

ここで最も多い間違いは、地域のコードだけを書いてしまうことです。言語のコードは必須で、地域だけの指定は無効です。たとえばベルギー向けにと考えて be と書くと、地域ではなくベラルーシ語として解釈されます。

日本語でも同じ取り違えが起きます。日本だから jp と書いてしまう例です。正しいのは言語のコードの ja、地域まで指定するなら ja-JP です。先に来るのは常に言語と覚えておけば、この種の間違いは防げます。

• 日本語を jp と書く（正しくは ja または ja-JP）
• 英国向けに uk と書く（地域のコードは gb）
• 欧州連合や国際機関の略称を地域として書く
• 地域のコードだけを書き、言語のコードを省く
• 中国語で文字体系を区別せず、簡体と繁体を1つにまとめる

中国語は特に注意が必要です。簡体と繁体は文字体系が違うため、別の規格の表記で区別します。1つにまとめると、読める版があるのに読めない版が出るという取り違えが残ります。

コードの確認は生成AIに任せると速いです。対象の国と言語の一覧を渡して、規格に沿った表記に直させる。そのうえで公式の一覧と照らせば、思い込みによる間違いを減らせます。

指定4：どれにも当てはまらない人の受け皿

4つ目は受け皿の指定です。用意した版のどれにも利用者の言語の設定が当てはまらない場合に、どのページを見せるかをあらかじめ決めておく指定です。

日本語版と英語版だけを持つサイトに、スペイン語の設定で検索する人が来たとします。受け皿の指定がなければ、どちらが出るかは運任せです。受け皿を決めておけば、迷わせずに入口へ案内できます。

何を受け皿にするかは2択です。言語を選ばせる案内のページか、最も広く読まれる版のトップページ。選ばせる形のほうが親切ですが、そのページを作る手間がかかります。用意がなければトップページで構いません。

受け皿の指定も、他の指定と同じ一覧の中に並べて書きます。特別な場所に書くわけではありません。そして受け皿の行も、すべての版の一覧に同じように入れます。1つの版だけに書いても、一覧の顔ぶれが揃わなくなるだけです。

地域まで分けるか、言語だけで足りるか

設計でよく迷うのがここです。英語の版を1つ用意すれば足りるのか、米国向けと英国向けに分けるべきなのか。判断の軸は中身が実際に違うかどうかだけです。

価格の通貨が違う、対応できる地域が違う、法令にもとづく表記が違う。こうした差が本当にあるなら、地域まで分ける意味があります。逆に中身が同じなのに地域だけ分けるのは、管理の手間を増やすだけです。指定の行数も版の数だけ増えます。

BtoBでは、まず言語だけで分けるところから始めるのが現実的です。問い合わせが特定の国に集まってきた段階で、その国向けの版を足す。需要が見えてから分ける順序にすれば、無駄な版を抱えません。

• 中身が同じなら地域まで分けない
• 通貨や法令の表記が違うときだけ地域を足す
• 版を足すほど相互参照の管理が重くなる

機械翻訳のページに指定してよいか

版を増やす手段として、機械による翻訳を使う相談は多くあります。速く安く版を増やせるため、魅力的に見えます。ただし、そのまま公開する形には明確な問題があります。

Googleのスパムに関する方針では、機械による翻訳を人が確認せずに公開することが禁じられています。版と版を結ぶ指定を正しく書いても、中身の質が方針に反していれば評価は得られません。

現実的な進め方は、翻訳の下書きを機械に任せ、その言語がわかる人が中身を確認して直す形です。特に社名や製品名、法令にもとづく表記は機械が取り違えやすい箇所です。確認の工程を省かないことが、版を増やす条件になります。

確認の負荷を下げる工夫もあります。版を増やすページを絞ることです。全記事を翻訳するのではなく、問い合わせにつながるページだけを先に訳す。会社の案内、主要なサービスの説明、問い合わせの入口の3つで十分に機能します。

この絞り方には副次的な利点もあります。版の数が少なければ、相互参照の管理も軽くなります。翻訳の質と指定の正しさを同時に保てる範囲から始めるのが、崩れない多言語化の順序です。

コードの表記を確かめる手順

コードの誤りは、書いた本人には見つけにくい種類の間違いです。思い込みで書いた2文字は、何度読み返しても正しく見えます。そのため、確認は人の目ではなく一覧との突き合わせで行います。

手順は3段階です。対象の言語と国を表にする、規格の一覧から該当する2文字を引く、そして書いた指定と表を照合する。この形にすれば、記憶に頼る場面がなくなります。

生成AIを使うなら、表を作らせる工程に向いています。対象の国と言語を渡して、規格に沿った表記の一覧を出させる。ただし出てきた値はそのまま信じず、公式の一覧で裏を取ります。コードは取り違えても動いてしまうため、間違いが残りやすい箇所です。

導入の手順

4つの指定を実際に入れる順番を示します。先に設計を固めてから書き始めるのが、やり直しを減らす近道です。書きながら考えると、必ず不整合が残ります。

この5工程のうち、抜けやすいのは最後の確認です。指定は書いた時点では正しく見えても、片方向になっているかどうかは全体を突き合わせないと分かりません。目視では見つかりません。

URLの書き方で無効になる例

コードが正しくても、URLの書き方で無効になることがあります。決まりは単純で、プロトコルを含む完全なURLで書くことです。省略した形は受け付けられません。

よくあるのは、サイトの内側だけを表す短い書き方です。普段のリンクでは通用しますが、この指定では無効になります。ドメイン名から始まる形も、通信の方式が欠けているため不十分です。

もう1つの落とし穴が、版によってドメインが違う場合です。国別のドメインを使い分けているサイトでは、指定先のドメインを取り違えても見た目には正しく見えます。表を作って突き合わせる工程を省かないことが防止策になります。

暗号化のあり・なしの取り違えも同じ種類の失敗です。サイト全体を暗号化した通信に移したあと、指定の中だけ古い形式のURLが残る。転送は効いているため画面上は正常に見えますが、指定としては別のURLを指したままです。

サイトの地図に書く形

ページ数が増えたら、指定はサイトの地図のファイルに寄せます。この形なら、各ページのHTMLに1行も足さずに済みます。更新も1つのファイルの生成をやり直すだけで完了します。

書き方は、各URLの項目の中に、対応する版の一覧を子の要素として並べる形です。ここでも決まりは変わりません。自分自身を含めること、すべての版を並べること、完全なURLで書くこと。この3つは書く場所が変わっても同じです。

この形の利点は、相互参照が自動的に成立することです。1か所にまとめて書くため、片方向になる余地がそもそもありません。版の追加でよく起きる失敗を、構造で防げるという意味があります。

注意点は、ファイルを作る仕組みが必要になることです。手で書き続けられる規模ではありません。記事の管理に使っている道具が対応しているかを先に確認してから、この方式を選びます。対応していなければ生成の仕組みを別に用意します。

正規化の指定との関係

同じ内容が複数のURLから見える場合、どれを代表とするかを伝える正規化の指定があります。多言語のサイトでは、この指定と版を結ぶ指定が矛盾しやすい組み合わせになります。

典型的な誤りは、英語版の代表を日本語版に向けてしまう形です。これは「英語版は日本語版と同じものだから日本語版を見てほしい」と伝えることになり、英語版を独立したページとして扱ってほしいという意図と衝突します。

正しい形は単純です。各版の代表は、その版自身に向けます。版を結ぶ指定で関係を伝え、正規化の指定では各版が独立していることを示す。役割が違う2つの指定だと切り分けて考えます。

この誤りが生まれる背景には、重複を避けたいという善意があります。同じ内容が複数あると評価が分かれると聞いて、1つに寄せようとしてしまう。別の言語の版は、そもそも重複として扱う対象ではありません。寄せる必要はないのです。

設定できたかを確かめる

書いたあとの確認には3つの手段があります。1つで済ませず、組み合わせて使うと見落としが減ります。どれも無料で始められます。

• 検索の管理画面で言語と地域に関する報告を見る
• 個別のURLの検査で、実際に読み取られた指定を確かめる
• サイト全体をたどる道具で、片方向の指定を洗い出す
• 版を追加したあとに、既存の全ページの一覧を再確認する

管理画面で見つかること

検索の管理画面では、指定に関する誤りがまとまって報告されます。特に見るべきは、対応する指定が見つからないという報告です。これが片方向になっている箇所を示しています。

報告は即座には出ません。読み取りが済んでから集計されるため、設定した翌日に何も出ていなくても異常ではありません。数日から数週間の幅で待ちます。

報告が減らない場合は、指定の書き方ではなく反映の経路を疑います。使っている道具が上書きしている、キャッシュが古い内容を返している、といった原因が考えられます。

サイト全体をたどる道具を併用すると、管理画面より早く原因が絞れます。全ページの指定を一覧で書き出せるため、どの版の一覧に何が欠けているのかが一目で分かります。版が3つ以上あるサイトでは、この確認を手作業で行うのは現実的ではありません。

運用で崩れる場面と防ぎ方

最初に正しく設定できても、運用のなかで崩れます。崩れる場面は決まっているため、あらかじめ手順に組み込んでおけば防げます。崩れてから直すより、崩さない段取りのほうが楽です。

崩れる場面は3つです。版を追加したとき、ページのURLを変えたとき、そして片方の版だけでページを削除したときです。3つ目は特に気づきにくく、指定の先が存在しないページを指したまま残ります。

防ぎ方は、これらの作業に確認を紐づけることです。版の追加とURLの変更とページの削除を、指定の見直しとセットの作業として手順書に書く。担当が変わっても引き継げる形にしておきます。

片方の版だけ更新が止まる問題

もう1つ、指定とは別に起きる崩れがあります。日本語版だけ記事を更新し続け、英語版が古い内容のまま取り残される状態です。指定は正しいまま、中身の対応関係が失われます。

この状態は、訪れた人の不信につながります。同じ会社の説明が言語によって違うことに気づかれるためです。更新の対象に全版を含めるか、更新の頻度を落として全版を揃えるかを決めておきます。

判断の基準は、その言語からの問い合わせの実績です。実績がない版を維持するために全体の更新を止めるのは本末転倒です。使われていない版は畳む選択も含めて、年に一度は見直します。

まとめ

別の言語のページが検索に出る取り違えは、中身の問題ではなく指定の不備で起きます。必要なのは4つです。自分自身も一覧に含めること、版どうしが互いを指し合うこと、言語のコードを必ず先に置いて規格に沿って書くこと、そしてどの版にも当てはまらない人の受け皿を決めておくこと。この4つを設計の段階で決めてから書き始めれば、やり直しは起きません。書く場所はページ数で決め、ページ数が多ければサイトの地図に寄せる。地域まで分けるのは、通貨や法令の表記に実際の違いがあるときだけにする。そして版を追加するときとURLを変えるときに必ず見直す。その運用まで手順にできれば、多言語のサイトは崩れずに育ちます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。