言語の自動リダイレクトでページが消える—別URLとhreflangで直す
英語版だけが検索結果に出てくる。日本語ページは、いくら待ってもインデックスに載らない。——多言語サイトでこれが起きるとき、疑うべきは記事の中身より先に、アクセス元を見て表示先を勝手に決める仕組みのほうです。
Googleの検索ロボット（クローラー。以下Googlebot）は、既定では米国にあると判定されるIPアドレスからページを取りに来ます。そのうえ、「この言語で見たい」という希望をリクエストに付けずに要求します。Googleの公式ドキュメントは、アクセス元に応じて中身を変えるページがあると、一部の言語のコンテンツをクロール・インデックス登録・ランク付けできない場合があると明記しています。
条件を並べると単純です。米国から来た訪問者。言語の希望なし。自動振り分けの規則をそのまま当てはめれば、返るのは英語版（または既定言語版）になりがちです。ほかの言語のURLが一度も読まれないまま残る、ということが起こり得ます。
「IPで中身を変えない」は公式の推奨
多地域サイトの管理についてGoogleが挙げている注意点のなかに、コンテンツを切り替えるためにIPアドレスの分析を使わない、という一項があります。地域を狙いたいなら、ロケールごとのURLと明示的なhreflang（言語・地域の対応関係を伝えるタグ）を使う。国別ドメイン（.jp や .de など）はロケールの強い手がかりになる。ページ上では言語をはっきり示し、言語の混在や機械的な定型翻訳は避ける。同じ言語で中身が重複するときはcanonical（正規URLの指定）で寄せる——というのが公式に示されている組み立てです。
ここで効いてくるのが、Googlebotの地域分散クロールです。GooglebotはUSのIPアドレスだけでなく、米国外に置かれたIPアドレスからもクロールします。ではドイツのIPから来れば、ドイツ語版がちゃんと読まれるのか。話はそう単純ではありません。Google側の案内は「Googlebotが特定の国から来ているように見えるときは、その地域のユーザーと同じように扱ってください」というものです。特別扱いするな、という指示であって、全言語版が確実に見つかるという保証ではありません。だからこそ、言語ごとに別のURLを用意して rel="alternate" hreflang の注釈を付ける方法が推奨され続けています。
もうひとつ、見落としやすい一項があります。robots.txt や meta タグによるロボット向けの制御を、すべてのロケールで一貫して適用すること。日本語版だけ古い noindex が残っている、といった不一致はここで効いてきます。
Googlebotと同じ条件で自社サイトを叩く
推測で終わらせず、実際の応答を見ます。ブラウザで開くと自分のIPと言語設定が混ざるので、結果が信用できません。素のHTTPリクエストで確かめます。
- 言語の希望を送らずに要求する。
curl -sI https://example.com/ja/page -H 'Accept-Language;'のように、Accept-Language を空にして応答の1行目を見ます。Googlebotが既定でこの状態に近い、というのが出発点です。 - 応答コードと Location を記録する。 200 が返るのか、301や302で別言語へ飛ばされるのか。飛ばされるなら、どのURLへ飛ぶのかまで控えます。
- 海外の出口から同じことを繰り返す。 米国など海外に出口のあるネットワーク（VPSやプロキシ）から同じリクエストを投げます。国内からのアクセスだけでは、IP判定の分岐が動きません。
- 全言語版のURLで一周する。 日本語版だけ確認して終わりにしないこと。トップページは素通しでも、下層の言語別URLだけ飛ばされる実装は珍しくありません。
- robots.txt と meta の noindex を全ロケールで突き合わせる。 言語ごとに配信元やCMSが分かれていると、ここがずれます。
- ブラウザ側の遷移も確かめる。 3〜5が素通しでも、読み込んだあとにJavaScriptが別の言語版へ移動させている場合があります。開発者ツールでネットワークの記録を残したままURLを開き、サーバーの応答とは別に遷移が起きていないかを見ます。
Googlebotを名乗るアクセスが本物かどうかは、逆引きDNSで確認できます。ログ側の点検をするときはこの手を使います。
応答コードで判定する
手順2で控えた結果を、そのまま当てはめてください。
| 言語別URLへの応答 | 何が起きているか | 次にやること |
|---|---|---|
| 200 が返り、その言語の中身が出る | 素通し。設計としては正常 | hreflangの相互リンクとx-defaultの点検へ進む |
| 301 / 302 で既定言語へ飛ぶ | 言語の希望なしのアクセスが全部まとめて既定言語へ寄せられている状態 | 自動転送をやめ、案内バナー＋切り替えリンクに置き換える |
| 200 だが中身が既定言語 | URLは分かれていても、実質は同一URL扱いに近い出し分け | URLごとに中身を固定する。IPでの出し分けをやめる |
| 海外IPのときだけ転送される | IP分析による切り替えが動いている | 公式が「使わない」としている分岐。ここを外す |
| 200 だが noindex が付く | 言語ごとの設定の不一致 | robots関連の指定を全ロケールで揃える |
一つめの行に入れたサイトだけが、次の工程に進めます。二つめと四つめは、さきほどの「米国から来た、言語の希望なし」がそのまま刺さっている状態です。三つめは一見して健全に見えるのがやっかいで、URLを直接開いた人には気づかれないまま放置されがちです。
直し方は「別URL＋hreflang＋自分で選べるリンク」
順番があります。まず自動転送を外す。次に言語ごとのURLを固定する。最後にhreflangで対応関係を伝える。この順を守らないと、hreflangを整えた先で転送が待っている、という噛み合わない構成になります。
hreflangの指定方法は3つあり、HTMLの link タグ、HTTPヘッダー、XMLサイトマップのいずれでも構いません。PDFのようにHTMLを持たないファイルにはHTTPヘッダーが向きます。守るべき点は共通です。すべてのバージョンが互いにリンクし合っていること。言語コードはISO 639-1、地域コードはISO 3166-1 Alpha 2 を使うこと。そして、どの言語にも当てはまらない訪問者向けに x-default を用意すること。相互リンクが片方向で終わっている場合の直し方は、hreflangが効かない原因—自己参照と返りリンクの3要件で点検するで扱っています。
自動転送の代わりに置くのは、押しつけない案内です。別の言語版がある事実をバナーで知らせ、切り替えはフッターなどのリンクに任せる。切り替えリンクはJavaScriptの動的生成だけに頼らず、普通のリンクとして書いておくほうが安全です。クローラーがたどれる形になっているかを、そこで一度確かめてください。
よくある誤解を3つ
「地域分散クロールがあるから、放っておいても全言語が読まれる」。 米国外のIPからもクロールされるのは事実です。ただしGoogle側の案内は、そのアクセスを地域のユーザーと同じに扱えという指示にとどまります。全言語版の発見を保証するものではないので、別URLとhreflangの推奨は今も変わっていません。
「最初だけ自動で振り分けて、手動で切り替えたらCookieに覚えさせればいい」。 訪問者にとっては筋の通った設計に見えます。けれども、この仕組みが効くのは2回目以降です。設定がまだ残っていない最初のアクセスは、自動振り分けのほうを通ります。初回で既定言語へ寄せられる構造が残っているかぎり、ほかの言語版はやはり読まれないままになりがちです。
「Googlebotのときだけ転送を止めればいい」。 これは公式の案内と逆を向いています。Googlebotが特定の国から来ているように見えるなら、その地域のユーザーと同じように扱う、というのが示されている扱い方です。ロボットにだけ別の応答を返す設計に踏み込む理由はありません。
出す前の自己点検
- 言語別URLに、言語の希望を送らないリクエストで200が返る
- 海外の出口から叩いても、応答が変わらない
- 全バージョンのhreflangが相互にリンクしている
- x-default が指定されている
- robots.txt と noindex の設定が全ロケールで揃っている
- 言語の切り替えが、普通のリンクとしてページ上に存在する
6つ全部にチェックが付くまでは、順位や記事の中身を触っても効きにくい段階です。クロールされないままのページは、インデックス登録も順位付けもされないことがあります。言語ごとにURLをどう分けるか自体を決めかねている場合は、サブドメインとサブディレクトリの選び方も合わせて確認してください。
出典