あなたの多言語サイトは、おそらく一言語しかインデックスされていない
同じ URL 上で JavaScript を使って言語を切り替えるのは、六つの翻訳を検索エンジンから不可視にする最も一般的なやり方です。実際に何がインデックスされるのか、そして静的サイトをどう構成すればそうならないのか。
よく見かけるパターンがあります。ある会社がサイトを六言語に翻訳し、言語切り替えを実装し、そしてどの新市場からも流入が見られない。翻訳の質は良い。誰も見つけられないのです。
原因はほぼ常に同じで、それは編集ではなくアーキテクチャの問題です。
検索エンジンがインデックスするのは URL であって、アプリの状態ではない
言語切り替えがページ上のテキストを差し替え、その選択を localStorage や Cookie に覚えるだけなら、すべての言語が一つの URL を共有します。
クローラーはその URL を要求し、HTML に焼き込まれた言語を受け取り、それをインデックスします。検索の観点では、ほかの六つの翻訳は存在しません。順位をつける二つ目の URL もなく、独立したタイトルも説明文もありません。
これは回避すべきクローラーの制限ではありません。URL がインデックスの単位なのです。一つの URL は、インデックスされた一つの文書を意味します。
テストは単純です。あなたのページを日本語で開くリンクを、誰かに送れますか。送れないなら、Google も日本語版をインデックスできません。
クライアント側切り替えで問題ない場合
この手法にも公平であるべきです。常に間違いというわけではありません。ページが本文の内容で見つけられる類のものでないなら、クライアント側の切り替えはまったく妥当です。
- ログインの内側のアプリ画面
- ダッシュボードや社内ツール
- 流入が広告・紹介・口コミである小規模なサイト
それらの言語で自然検索の流入がほしくなった瞬間に、問題になります。コンテンツマーケティング、ドキュメント、ブログはまさにその場合です。
各言語に本物の URL を与える
よく使われる三つの構成で、どれも検索エンジンは受け入れます。
| 構成 | 例 | 備考 |
|---|---|---|
| サブディレクトリ | example.com/ja/page | 最も簡単。ドメインの評価を引き継ぐ。ふつうはこれが正解。 |
| サブドメイン | ja.example.com/page | 可能だが、DNS と証明書の管理が増える。 |
| 別ドメイン | example.jp/page | 地域シグナルは最強、コストも最大。各ドメインが単独で評価を積む。 |
多くのチームにはサブディレクトリを。評価が積み上がるドメインが一つあり、インフラ作業も増えません。
次に、それらが関連していると検索エンジンに伝える
URL を分けるだけでは新たなリスクが生まれます。同じことを言う七ページが重複に見えかねません。hreflang は「これらは同じページの別言語版なので、適切なものを見せてください」と伝える手段です。
すべての版に、自分自身を含むすべての版を列挙します。
<link rel="alternate" hreflang="en" href="https://example.com/en/page">
<link rel="alternate" hreflang="vi" href="https://example.com/vi/page">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/page">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page">あわせて、各ページに自分自身を指す canonical を。
<link rel="canonical" href="https://example.com/ja/page">これを壊す五つの間違い
- 戻りリンクの欠落。
hreflangは相互でなければなりません。英語ページが日本語を指しても日本語が指し返さなければ、その対応は無視されます。これが圧倒的に多い失敗です。 - canonical が別言語を指している。 日本語ページの canonical が英語 URL を指すのは、検索エンジンにそれを捨てろと指示しているのと同じです。canonical は自分自身を指さなければなりません。
- 言語と地域の混同。
hreflang="ja"は日本語という言語。hreflang="ja-JP"は日本向けの日本語です。地域別の版を実際に持っていない限り、地域なしの言語コードを使ってください。不要に絞ると他地域の読者を失います。 - コードの誤り。 地域サブタグは国コードであって言語コードではありません。英国英語は
en-GBでen-UKではない。中国語では国より文字が重要で、zh-Hansとzh-Hantになります。 - 相対 URL。
hreflangと canonical にはプロトコルとドメインを含む絶対 URL が必要です。
スラッグも翻訳する
簡単に取れるのに飛ばされがちな利点：URL 内の語はその言語における関連性シグナルです。ベトナム語ページが /vi/how-to-look-up-a-character にあるなら、その URL はベトナム語では何も貢献していません。
スラッグを翻訳し、版どうしを対応づける安定した内部識別子を持ってください。このブログはまさにそう構成しています。各記事は決して変わらない id と、言語ごとに変わる slug を持ちます。
IP による自動リダイレクトはしない
魅力的で、実害があります。訪問者の国を判定して強制的にリダイレクトすると：
- クローラーはたいてい一つの国からアクセスするため、一つの版しか見られないことがあります。
- 意図的に別を選んだ人を上書きします。日本にいる多くの人が英語で読みたいと思っています。
強制ではなく提案を。バナーを出し、切り替えを見える場所に置き、内容は URL に決めさせてください。
静的サイトならこれは簡単
ここまでのどれも CMS もサーバーも要りません。ビルド時にページごと・言語ごとに HTML ファイルを 1 つ生成し、正しいタグを焼き込み、フォルダをアップロードするだけです。成果物はただの静的ファイルで、賢さはデプロイ前に走らせるジェネレーターの中にあります。
このブログもそうしています。内容は記事ごと言語ごとに 1 ファイルで管理し、小さなスクリプトが hreflang、canonical、JSON-LD、言語別のサイトマップ項目つきの HTML を生成します。サイト自体は静的ファイルのフォルダのままで、バックエンドは一切ありません。
チェックリスト
- 各言語に、人に送れる固有の URL がある
- 各ページが自分を含む全言語を
hreflangに列挙し、相互に対応している - 合致しない訪問者のための
x-defaultがある - 各ページの canonical が自分自身を指している
- スラッグが翻訳され、内部では安定した id で対応づけられている
- サイトマップが各言語 URL と代替版を列挙している
html langが実際の内容と一致している- IP ベースの強制リダイレクトがない