多言語サイトを公開したのに、狙った国の検索結果に出てこない。日本語で検索したのに英語版が表示される。翻訳の質は悪くないはずなのに、海外からの流入が増えない。
こうした相談を受けるとき、原因が翻訳の品質だったことはほとんどありません。ほぼすべてが実装の事故です。しかも厄介なことに、事故の多くは「タグが出力されていない」ではなく「タグは出ているが中身が間違っている」という形で起きます。ソースを開いて一見しただけでは正常に見えるため、何年も気づかれないまま放置されます。
この記事では、多言語サイトのSEOで実際に起きる事故を、発生頻度と影響の大きい順に扱います。最後に、自社サイトを10分で診断する手順を付けました。
なお、URL構造をサブディレクトリ・サブドメイン・ccTLDのどれにするかという設計そのものの比較は失敗しないWebサイト多言語化の進め方で詳しく扱っています。この記事は、構造を決めたあとの実装で何を間違えるかに絞ります。
前提：URLのどこに言語を持たせるか
ここから先の事故は、いずれも「URLが言語を持っている」ことを前提にしています。まずその前提を確認しておきます。多言語化で最初に決めるのがURL構造で、後から変えると全ページのURLが変わるため、やり直しが最も高くつく判断です。
URLが言語を持たないと、検索エンジンには1ページしか見えない
?lang=en のようなクエリパラメータや、localStorage・Cookie で言語を切り替える実装は、閲覧者には正しく動きます。しかし検索エンジンには言語版が存在しないのと同じです。クローラーは localStorage も Cookie も持たず、原文のページだけを見て帰ります。当社のスクリプトでも、URL に固定された言語（サブドメインまたはディレクトリ）は、クエリパラメータや localStorage より優先する設計にしています。URL が言語を持っていれば、エッジ側でその言語の翻訳済みHTMLを返せるため、クローラーは JavaScript を実行しなくても訳文を読めます。逆に URL が言語を持たない設定では、返せるのは原文のままです。
これは翻訳の品質以前の話です。URL構造を決めていない多言語サイトは、何ページ翻訳しても検索結果には1言語ぶんしか出ません。
3つの方式と選び方
言語をURLに持たせる方法は3つあります。
- ccTLD —
example.deのように国別のトップレベルドメインを使う
- サブドメイン —
en.example.comのようにホスト名の先頭で分ける
- サブディレクトリ —
example.com/en/のようにパスの先頭で分ける
判断の基準は次のとおりです。
ccTLD は、国ごとに法人・在庫・価格・法規制が分かれている場合にだけ選びます。国を明示できる反面、ドメインごとに検索エンジンの評価がゼロから積み上がるため、既存ドメインの評価を引き継げません。運用コストも国の数だけ増えます。多言語化の入口としては重すぎる選択です。
サブドメイン は、既存サイトの構成に手を入れずに始められるのが利点です。DNS を1本足すだけで済み、本体のアプリケーションやサーバー構成を変更する必要がありません。評価はドメイン本体とある程度共有されますが、サブディレクトリほど一体ではないと考えられています。
サブディレクトリ は、ドメインの評価を1本に集約できるのが最大の利点です。ただしパスの先頭で言語を判定して振り分ける必要があるため、リバースプロキシかエッジでの経路制御が要ります。既存サイトの構成によっては、この経路制御が導入の障壁になります。
当社での扱い
AIシュリーマン自身のサイトは
en.ai-translate.com fr.ai-translate.com のサブドメイン方式です。顧客サイトへはサブドメインとサブディレクトリの両方を提供しています。サブドメイン方式はホスト名の先頭セグメントを言語コードとして解釈するため設定なしで動き、サブディレクトリ方式はサイトごとの設定で有効にします。ディレクトリ方式では、パスの先頭セグメントを言語コードとして解釈します。
どちらの方式でも、URL に言語が固定されているページはエッジ側で翻訳済みのHTMLを返し、ブラウザ側での初回の全体翻訳を省略します。表示までの時間が短くなり、クローラーにも訳文がそのまま渡ります。
決め直しのコストを最初に見積もる
URL構造を後から変えると、全ページで301転送が必要になります。評価の受け渡しには数か月かかり、その間は順位が不安定になります。
言語を増やす予定があるか、国ごとに内容を出し分ける予定があるかを先に確認してください。「とりあえず英語だけ」で始めても、URL構造だけは将来の言語数を見込んで決めておくべきです。
事故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のインフラ構成で解説しています。
事故6：メタデータが日本語のまま残っている
ここまでは検索エンジンへ構造を伝えるタグの話でしたが、検索結果に実際に表示される文字も忘れてはいけません。
本文は翻訳されているのに、タイトルタグとメタディスクリプションが日本語のままというサイトをよく見ます。翻訳スクリプトが
<body> の中だけを処理し、<head> に触れていない場合に起きます。何が問題かというと、検索結果に出るのはこの2つだからです。英語圏のユーザーが検索して、結果一覧に日本語のタイトルが並んでいれば、内容が読めるかどうか以前にクリックされません。
確認の仕方
英語版ページのソースを開き、次の2つを見てください。
<title>…</title>
<meta name="description" content="…">どちらかが日本語なら未対応です。ブラウザのタブに表示される文字を見るだけでも、タイトルが日本語のままかどうかは分かります。
機械翻訳のままでよいか
タイトルとディスクリプションは、本文と違って文字数の制約があります。検索結果で切られない長さに収める必要があり、日本語から機械翻訳すると長くなりがちです。
流入を取りたい主要ページについては、翻訳ではなく現地語で書き下ろすことをおすすめします。全ページに人手をかける必要はありません。トップページ、主要な製品・サービスページ、流入の多い記事の3種類に絞れば、労力は現実的な範囲に収まります。
それ以外のページは機械翻訳のままで構いません。日本語が残っているよりはるかに良い状態です。
言語ごとにキーワードが違う
もうひとつ見落とされるのが、検索されている言葉が言語圏によって違うことです。
日本語で「多言語化」と呼んでいるものが、英語圏では localization、internationalization、translation のどれで検索されているか。直訳したタイトルが、その言語圏で実際に使われている言葉と一致しているとは限りません。
主要ページだけでも、対象言語での検索需要を確認してからタイトルを決める価値があります。どの言語に投資するかの判断はウェブサイトを多言語化するならどの言語が必須？で扱っています。
自社サイトを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を維持する唯一の現実的な方法だと考えています。
