多言語サイトを公開したのに、狙った国の検索結果に出てこない。日本語で検索したのに英語版が表示される。翻訳の質は悪くないはずなのに、海外からの流入が増えない。
こうした相談を受けるとき、原因が翻訳の品質だったことはほとんどありません。ほぼすべてが実装の事故です。しかも厄介なことに、事故の多くは「タグが出力されていない」ではなく「タグは出ているが中身が間違っている」という形で起きます。ソースを開いて一見しただけでは正常に見えるため、何年も気づかれないまま放置されます。
この記事では、多言語サイトのSEOで実際に起きる事故を、発生頻度と影響の大きい順に扱います。最後に、自社サイトを10分で診断する手順を付けました。
なお、URL構造をサブディレクトリ・サブドメイン・ccTLDのどれにするかという設計そのものの比較は失敗しないWebサイト多言語化の進め方で詳しく扱っています。この記事は、構造を決めたあとの実装で何を間違えるかに絞ります。
事故1：全言語版が同じURLをcanonicalに指している
最も影響が大きく、かつ最も多い事故です。
canonicalは「このページの正規URLはこれです」と検索エンジンに伝えるタグです。多言語サイトでよく見るのは、英語版にも中国語版にも日本語版トップのURLが書かれているケースです。
<!-- 英語版ページなのに、日本語版を正規URLとして指してしまう -->
<link rel="canonical" href="https://example.com/" />こう書くと、検索エンジンは「英語版は日本語版の複製であり、インデックスすべきは日本語版だけ」と解釈します。英語版は検索結果から消えます。多言語化した意味がなくなる設定です。
正しくは、各言語版が自分自身を指します。これを自己参照canonicalと呼びます。
<!-- 英語版ページ -->
<link rel="canonical" href="https://example.com/en/" />言語版は互いに複製ではなく、それぞれ独立したページとして扱われるべきものです。同じ内容を別の言語で書いたページは、重複コンテンツではありません。
canonicalとhreflangは組み合わせて初めて機能する
役割が違います。canonicalは「このURLが正規版か」を、hreflangは「このURLはどの言語・地域向けか」を伝えます。
両方が正しく揃って初めて、検索エンジンは「これらは互いに複製ではなく、言語違いの対応するページ群である」と理解します。片方だけでは機能しません。hreflangを丁寧に設定しても、canonicalが全部日本語版を指していれば、hreflangの指定ごと無視されます。
そもそも出力されていないことも多い
実務でよく見るのは、canonicalタグが1つも出力されていないケースです。CMSやフレームワークによっては、明示的に設定しない限り出力されません。
実は、この記事を公開しているai-translate.com自身が、つい先日までそうでした。全ページにalternateタグは出ていたのにcanonicalは1つもなく、しかもalternateの中身も誤っていました。詳細は事故3で扱います。
事故2：言語の自動リダイレクトがクローラーを閉じ込める
訪問者のIPアドレスやブラウザの
Accept-Language を見て、自動的に対応言語のページへリダイレクトする実装があります。親切な機能に見えますが、SEOの観点では有害です。Googlebotは主に米国からクロールします。IPで判定して自動リダイレクトしていると、クローラーは常に英語版へ飛ばされ、日本語版を含む他の言語版に到達できません。結果として、リダイレクト先の言語版しかインデックスされない状態になります。
この事故が厄介なのは、人間がブラウザで確認すると正常に見えることです。日本から見れば日本語版が表示されるので、問題に気づけません。Search Consoleで「他の言語版がインデックスされていない」と気づいたときには、何ヶ月も経っています。
ユーザー体験の面でも問題があります。ドイツ在住の日本人が日本語で読みたい場合や、出張中に普段と違う国からアクセスした場合、意図しない言語に飛ばされて戻れなくなります。
正しい対処はリダイレクトしないこと
- 推定した言語のページを提案するバナーやダイアログを表示する
- 選択はユーザーに委ね、選んだ結果をCookieなどに保存する
- どの言語版からも他の言語版へ移動できる切替UIを常設する
リダイレクトではなく案内にすれば、クローラーは元のURLのまま全言語版に到達できます。言語切替UIの設計そのものは多言語切り替えボタンをデザインするためのベストプラクティスを参照してください。
事故3：hreflangは出ているが、中身が間違っている
hreflangは、あるページの他言語版・他地域版を検索エンジンに伝えるタグです。実装方法の詳細はhreflangタグ完全ガイドにまとめているので、ここでは「間違え方」に絞ります。
全ページがルートURLを指している
当社のai-translate.comで実際に起きていた誤実装です。alternateタグは全ページに出力されていました。ソースを見れば「hreflang対応済み」に見えます。
しかし中身は、記事ページからも料金ページからも一律で
https://en.ai-translate.com を指していました。ページ単位の対応関係を一切表していない状態です。検索エンジンから見れば意味をなしません。<!-- 記事ページなのに、英語版トップを指している -->
<link rel="alternate" hreflang="en" href="https://en.ai-translate.com" />正しくは、その記事の英語版を指す必要があります。
<link rel="alternate" hreflang="en" href="https://en.ai-translate.com/guide/xxx" />この誤実装は、テンプレートに固定値を書いたまま忘れると起きます。一度書けば全ページに出力されるので、動作確認をトップページだけで済ませると発見できません。
自己参照がない
各ページのhreflangリストには、他言語版だけでなく自分自身への参照も必要です。日本語ページなら
hreflang="ja" で自分自身を指す行が要ります。これを忘れるとリスト全体が無効と判定されることがあります。当社もこれを忘れていました。hreflangの解説記事を書いている当人がやっていたわけです。
相互参照になっていない
AからBへ設定したなら、BからAへも設定します。片方向だけの参照は無視されます。言語を追加したときに、既存ページ側への追記を忘れて片方向になるパターンが典型です。
x-defaultがない
どの言語にも該当しないユーザー向けのフォールバックです。指定しないと、検索エンジンは想定外の言語のユーザーに何を見せるべきか判断できません。
どう直したか
当社では、メタ情報の生成を1つの純粋関数に切り出しました。共通コンポーネントの中に直接書かれていると、誰も検証しないまま何年も間違ったまま動き続けます。
関数として独立させれば、「x-defaultが出ているか」「自己参照が入っているか」「動的ルートでパスが未解決のときにcanonicalを出力しないか」を自動テストで固定できます。メタ情報は目視で確認するものではなく、テストで固定するものだというのが、この一件から得た結論です。
事故4：言語と地域を不必要に分けている
「英語版」と「アメリカ向け」は同じではありません。英語はイギリス、オーストラリア、シンガポールなどでも使われ、それぞれ通貨・単位・法規制・表記が異なります。
hreflangでは、言語だけを指定することも、言語と地域を組み合わせることもできます。
hreflang="en"— 英語全般。地域を問わない
hreflang="en-gb"— イギリス向けの英語
hreflang="en-us"— アメリカ向けの英語
言語コードはISO 639-1の2文字、地域コードはISO 3166-1の2文字です。よくある誤りは、地域コードに独自の文字列を入れることと、
hreflang="uk" のように国名の通称を使うことです。イギリスの地域コードは gb であり、uk は言語コードのウクライナ語と衝突します。分ける必要が説明できるときだけ分ける
地域まで分けるべきなのは、価格表示や取引条件、法的表示が国ごとに異なる場合です。単に「英語で読めるようにしたい」だけなら、地域を指定しない
en で十分です。不要に細かく分けると、相互参照の組み合わせが言語数の二乗で増えます。3言語なら9通りですが、地域込みで6バリエーションになれば36通りです。管理ミスの温床になり、事故3の「片方向参照」を誘発します。
事故5：URLが言語ごとに分かれていない
最後に、構造そのものの話を1つだけ。
example.com/?lang=en のようなURLパラメータ方式や、Cookieで言語を保持してURLが変わらない実装は避けてください。検索エンジンがパラメータ違いを別ページとして扱うとは限らず、インデックスされない、あるいは日本語版と重複コンテンツと判定されるリスクがあります。パラメータはクロール制御の対象になりやすく、多言語版がまとめて評価対象から外れることもあります。
Cookie方式はさらに明確で、URLが同じであれば、検索エンジンから見て多言語版は存在しません。クローラーはCookieを持たない状態でアクセスするため、常に既定言語のページしか見えません。
同じ理由で、JavaScriptでページを翻訳する方式も、URLが日本語版と同じままでは検索対象になりません。訪問者の利便性としては有効ですが、検索流入を狙うなら別URLで翻訳済みHTMLを配信する必要があります。当社が「SEOオプション」として提供しているのもこの仕組みで、技術的な裏側はサイト翻訳SaaSのインフラ構成で解説しています。
自社サイトを10分で診断する手順
以上を踏まえて、実際に確認する手順です。ブラウザとSearch Consoleだけでできます。
手順1：トップページではなく個別ページを開く
これが最も重要です。事故の大半はテンプレートの固定値に起因するため、トップページでは正常に見えます。記事ページや商品ページを開いてください。
手順2：ソースでcanonicalを確認する
ページのソースを表示し、
rel="canonical" を検索します。- 見つからない → 出力されていない。事故1の予備軍
- 見つかるが、いま開いているページと違うURLを指している → 事故1
- いま開いているページ自身を指している → 正常
手順3：alternateの中身を確認する
同じソースで
rel="alternate" を検索します。- href がルートURL（
https://en.example.comなど）になっている → 事故3
- href がいま開いている記事の他言語版になっている → 正常
- 自分自身の言語の行がない → 自己参照漏れ
x-defaultの行がない → フォールバック未設定
手順4：他言語版を開いて逆方向を確認する
手順3で見つかった英語版URLを開き、そこから日本語版への alternate が出ているか確認します。出ていなければ片方向参照です。
手順5：リダイレクトの有無を確認する
VPNやブラウザの言語設定を変えてアクセスし、URLが自動的に変わるか確認します。変わるなら事故2です。
簡易的には、ブラウザの言語設定を英語にしてシークレットウィンドウで日本語版URLを開いてみてください。英語版に飛んだら自動リダイレクトが働いています。
手順6：Search Consoleでインデックス状況を見る
各言語版のURLをURL検査ツールにかけ、インデックス済みか確認します。「クロール済み - インデックス未登録」が並ぶ場合、事故1か事故2を疑ってください。
公開前チェックリスト
新しい言語版を追加する前に、以下を確認してください。
- URLが言語ごとに分かれている（パラメータやCookieだけで切り替えていない）
- 各言語版に自己参照canonicalが出力されている
- 記事ページのalternateが、ルートURLではなくその記事の他言語版を指している
- 全ページにhreflangの自己参照が含まれている
- 相互参照が双方向になっている
- x-defaultが指定されている
- 言語コードはISO 639-1、地域コードはISO 3166-1に準拠している（
ukではなくgb）
- href が相対パスではなく絶対URLで書かれている
- IPやAccept-Languageによる強制リダイレクトをしていない
- sitemapに全言語版のURLが含まれている
sitemapの設計と分割戦略は多言語ウェブサイトにおけるsitemap.xmlの設計と注意点、被リンクや指名検索を含む海外SEO全般は海外SEOを向上させるための重要な4つのポイントで扱っています。
まとめ
多言語サイトのSEOで起きる事故は、種類が限られています。canonicalが全言語版で同じURLを指す、自動リダイレクトでクローラーが閉じ込められる、hreflangがページ単位になっていない。この3つでほとんどが説明できます。
共通しているのは、どれもソースを一見しただけでは正常に見えることです。タグは出力されているし、人間がブラウザで見れば意図した言語が表示されます。だから何年も気づかれません。
当社自身がそうでした。解説記事を書いている側が誤実装したまま運用していたのです。発見できたのは、メタ情報の生成をテストできる形に切り出したときでした。
目視の確認には限界があります。個別ページを開いて中身を1つずつ確認すること、そして可能なら自動テストで固定すること。この2つが、多言語SEOを維持する唯一の現実的な方法だと考えています。
