ウェブサイト翻訳とローカライズの違い：SEOで実際に変わること

「サイトを翻訳すること」と「サイトをローカライズすること」は、同じプロジェクトとして扱われがちです。両者には関連がありますが、対応する範囲は異なります。翻訳は言語を変える作業です。一方、ローカライズは、通貨、法的な文言、事例、画像、単位、サポート情報、文化的に期待される要素などを市場に合わせて調整する作業です。単に読めるだけでなく、その地域向けに作られたと感じられるページを目指します。

Googleのドキュメントでは、「ローカライズ」を独立したランキング要因とは定義していません。一方、多言語・多地域サイトの扱いは定められており、各言語版には、クロール可能なURL、単一の言語であることが明確なページ、適切なアノテーション、ユーザーが選択できる仕組みといった厳格な要件があります。このガイドでは、業界で使われる翻訳とローカライズの区別を説明し、それぞれを検索上の要件に対応づけます。これにより、SEO、コンテンツ、ローカライズの各チームが共通の判断基準を持てるようにします。

このガイドでわかること

• ウェブサイトの翻訳とローカライズは何が違う？
• 翻訳品質に関わる言語版の要件について、Googleは何を示している？
• 翻訳だけで十分なのはどんな場合？ローカライズが必要なのは？
• ローカライズの方針によって、URL構造やhreflangの設計はどう変わる？
• 定型部分だけを翻訳するとどうなる？
• 同じ言語の中での地域差にはどう対応すべき？
• 翻訳プロジェクトとローカライズ施策を混同する、よくある間違いとは？
• SEO、コンテンツ、ローカライズの各チームは、どう責任を分担すべき？

要点：翻訳とローカライズの違い

ウェブサイトの翻訳は、原文の意味をできるだけ保ちながら、コンテンツを別の言語に置き換えることです。主な役割は言語の変換であり、見出し、本文、UIの文字列、ヘルプテキストを対象言語で読めるようにします。

ウェブサイトのローカライズは、さらに踏み込んだ対応です。現地通貨、税金に関する表記、日付形式、事例、画像、サポート窓口、法令遵守に関する文言、文化的な言及など、コンテンツとUXを特定の利用者層や市場に合わせて調整し、その市場の購買行動や読み方に合った体験を提供します。

Googleの用語では、どちらも通常、多言語サイトや多地域サイトの言語版（場合によっては地域版）に当たります。検索で重視されるのは、各URLが特定の言語で明確な体験を提供し、クロール可能であるかどうかです。社内の作業チケットに「翻訳」と書かれていたか、「ローカライズ」と書かれていたかではありません。

ワークショップでは、市場ごとに「この地域のユーザーに必要なのは…」で始まる一文を書いてみると役立ちます。内容の理解に関する文なら、翻訳の領域です。お金、法律、受注から配送までの対応、裏付けとなる根拠、文化との適合に関する文なら、ローカライズの領域です。多くのサイト公開では、両方が必要になります。

この違いがSEOで重要な理由

大量の翻訳を発注しても、公開したページが市場に合っていなければ、SEOはうまくいきません。市場向けにローカライズしても、クロール可能な個別のURLやアノテーションがなければ同様です。

Googleは、1つのURLでCookieやブラウザ設定に応じて言語を切り替えるのではなく、言語版ごとに異なるURLを使うことを推奨しています。言語は画面に表示されるコンテンツから判断され、lang属性、URLパス、hreflangから判断されるわけではありません。hreflangは各バージョンの関係を示すものであり、品質を生み出すものではありません。

そのため、コンテンツに関する判断（翻訳かローカライズか）と、技術的な判断（URL、hreflang、canonical、切り替え機能）は、一緒に計画する必要があります。どれほど優れたローカライズでも、クロールできないCookieベースの切り替えでは、検索エンジンに見つけてもらえません。翻訳版のURLがクロール可能でも、ナビゲーションしか翻訳されていなければ、内容の乏しい言語版になってしまいます。

海外展開では、対応言語の拡大と進出国の拡大も混同されがちです。翻訳が答えるのは「どの言語に対応するか」という問いです。ローカライズが答えるのは、多くの場合「どの市場の実情に合わせるか」という問いです。この2つを混同すると、グローバル向けページに必要以上の翻訳を施したり、国別サイトのアノテーションが不十分になったりします。

比較表

Googleが各言語版に求めること

作業を翻訳と呼ぶかローカライズと呼ぶかにかかわらず、Googleの多言語サイト向けガイダンスは適用されます。

1. 言語版ごとに異なるURLを使用する。
2. hreflangやサイトマップなどの方法で、各バージョンを明示する。
3. 各ページのコンテンツとナビゲーションは、原則として1つの言語で統一し、2言語を併記するページは避ける。
4. 他の言語版や地域版へ移動できるユーザー向けリンクを設ける。
5. 推測した言語に基づく自動リダイレクトは避ける。

適切にエンコードされていれば、URLや国際化ドメイン名（IDN）に各言語の単語を使っても問題ありません。ただし、パス内のコードだけでは、対象ユーザーをGoogleに伝えることはできません。hreflangなどで対応関係を明示することが、引き続き重要です。

これらのルールは、ベンダーの作業フローには左右されません。翻訳管理システム（TMS）上で作業を「MTPE翻訳」と呼んでいても、「完全なローカライズ」と呼んでいても、検索エンジンには、クロール可能で言語的な一貫性のあるページが必要です。

定型部分だけの翻訳と、内容の乏しい言語版

Googleは、本文を単一言語のままにして共通部分だけを翻訳すると、共通部分の言語だけが異なる同じコンテンツが検索結果に繰り返し表示され、ユーザー体験を損なう可能性があると警告しています。このパターンは、ユーザー生成コンテンツ（UGC）が中心のページや、画面の共通UIだけを翻訳して「ドイツ語対応」を急いで公開した場合によく見られます。

SEOと信頼性の観点では、共通部分だけの対応は、質の高い翻訳ともローカライゼーションともいえません。メニューだけが異なる、ほぼ重複した本文を生み出すことになるからです。不十分な言語版を数多く公開するより、数を絞って完成度の高い言語版を公開しましょう。

運用上の見極め方：QAチェックリストでメニューの文言は確認していても、対象言語の記事本文を一度も読んでいないなら、公開しているのは言語版ではなく、共通UIにすぎません。

翻訳だけで十分な場合

次のような場合は、翻訳を中心とした取り組みで十分なことがあります。

• 提供内容、料金体系、法的な位置づけが言語によって変わらない
• 具体例や画像が、文化的な違和感なく通用する
• 市場に合わせた再設計よりも、内容を理解してもらうことが重要である
• 共通UIだけでなく、各言語でページ本文全体を公開できる

その場合でも、翻訳品質はSEOを左右する要素として扱いましょう。Googleは、画面に表示される言語を読み取ります。機械が作成した文章をレビューせずに公開すると、独自性に乏しく信頼性の低いページになりやすく、従来の検索結果でもAIを活用した情報探索でも見つけてもらいにくくなります。

翻訳だけで十分だからといって、「URL設計は不要」という意味ではありません。複数の言語で公開するなら、それぞれ固有のURL、アノテーション、切り替え機能が必要です。

ローカライゼーションが必要な場合

通常、次のような場合にはローカライゼーションが必要です。

• 通貨、税金、配送、商品ラインアップが市場によって異なる
• 法的な記述や規制対象の訴求表現を変更する必要がある
• 具体例、導入事例、ユーモアがそのままでは通じない
• サポート窓口、電話番号の形式、住所の表記方法が異なる
• 対応言語の拡大と国別ターゲティングを同時に進めている

ある市場のユーザーに異なる取引条件や提供内容が必要なら、グローバル向けページを忠実に翻訳しても、訳は正確なのに内容は不適切ということが起こります。その場合、ローカライゼーションがコンテンツ戦略となり、翻訳はその中の制作工程の一つになります。

実務上の進め方のヒント：大量の翻訳を発注する前に、市場への適合方針（言葉以外に何を変える必要があるか）を確定させましょう。そうしないと、翻訳者が訳した文章を、その1週間後に現地市場のチームが書き直すことになります。

同じ言語内での地域差

すべての市場で新たな言語が必要になるわけではありません。米国向けと英国向けでは、同じ英語でも綴り、通貨、法的な文言が異なることがあります。Googleの代替ページに関するガイダンスでも、同一言語内の小さな地域差は有効なケースとして扱われています。ローカライズ版が重複と見なされるのは、メインコンテンツが翻訳されていない場合に限られます。

同じ言語で内容が似ている複数地域向けのURLでは、優先するバージョンを選び、rel="canonical"をhreflangと併用します。hreflangを使用する場合は、同じ言語の正規URLを指定してください。同じ言語の正規URLがない場合は、代替として最も適切な言語のものを指定します。

ここで登場するのが「翻訳を伴わないローカライゼーション」です。言語は同じでも、市場ごとの詳細が異なります。後付けで対応するのではなく、マトリクスの中で正式な区分として扱いましょう。

コンテンツ方針を決めてから構成を設計する

市場ごとに翻訳のみで対応するか、ローカライゼーションを行うかを決めたら、その判断をマトリクスにまとめます。

続いて、次の対応を行います。

• 各URLをクロール可能にし、それぞれ独立したURLを維持する
• 相互参照するhreflangクラスターを生成する
• 画面上に言語・地域の切り替え機能を設ける
• 他の言語・地域版にアクセスできなくなるような、ロケールに基づく強制リダイレクトを避ける

hreflangの詳しい仕組みは専用の実装ガイドに譲り、ここでは順序が重要です。まずコンテンツ対応方針を決め、その後でアノテーションを設定します。マトリクスが曖昧だと、開発側がフォルダの意味を独自に解釈することになり（/de/は言語なのか、国なのか、その両方なのか）、後で作り直しが必要になります。

役割分担：SEO、コンテンツ、ローカライゼーション

マトリクスができる前に開発チームが「すべての文字列」を要求したり、SEOチームがURLとアノテーションへの対応能力を確認する前にローカライズチームが対象市場を確保したりすると、ワークショップはうまくいきません。ブリーフにマトリクスを組み込み、すべてのチームが同じ成果物を編集するようにしましょう。

マトリクスを確定する前に、候補となる各ロケールについて、売上上位10件のURLを対象にコンテンツ対応方針の妥当性チェックを行いましょう。各URLについて、その市場のユーザーに必要なのは単なる言葉の置き換えなのか、それとも通貨、法的な文言、配送・提供の詳細、裏付けとなる情報も変える必要があるのかを確認します。変更が必要なら、同じ言語であっても、そのセルを「ローカライズ対象」とします（英国英語と米国英語など）。この10件のURLの確認によって、開発チームがフォルダーの命名規則を実装した後に発生する、コストの高い手戻りを防げます。

運用チームにとっても、文字列数ではなく完成度に基づく公開判定基準を設けることは有効です。ナビゲーションやフッターの文字列がQAを通過していても、本文、タイトルタグ、主要なCTAが原文の言語のままなら、公開を止めましょう。Googleは目に見える言語を総合的に評価します。部分的な翻訳では内容の薄い代替バージョンとなり、従来の検索結果でもAIを通じた情報発見でも十分な成果が得られません。この判定基準に加えて、元のブリーフを書いていない人が言語面を短時間で通読確認する工程も設けましょう。新たな視点で読む人は、チケットの指標よりも早く「UIは翻訳済みなのに、記事は英語のまま」という状態を見つけられます。

よくある間違い

翻訳プロジェクトとローカライズ施策を混同する、よくある間違いとは？

1. UI周りだけの翻訳を、その言語版の公開と見なす
2. Cookieで表示を切り替える単一URLでオファーをローカライズする
3. ユーザーを別バージョンから自動的にリダイレクトする
4. Googleはフォルダーのコードで言語を判別すると考える
5. 少数の完成度の高いロケールではなく、多数の内容の薄いロケールを公開する
6. hreflangで翻訳品質を補えると考える
7. 各国版のcanonicalをすべて1つのグローバルURLに向けながら、地域別バージョンの上位表示を期待する
8. コンテンツ対応方針のマトリクスに合意する前に、デザインシステムの構築を始める
9. 市場適合性やインデックス可能な言語版ではなく、「翻訳した単語数」だけで成果を測る
10. SEOとローカライズを切り離し、アノテーションの実装がコンテンツ公開より数か月遅れる

実装チェックリスト

• 今後12〜24か月を見据えた市場 × 言語のマトリクスを作成する
• 各セルを「翻訳のみ」「軽度のローカライズ」「全面的なローカライズ」に分類する
• 主要コンテンツが各言語で完全に用意されていることを確認する（定型部分だけを翻訳した状態では公開しない）
• セルごとにクロール可能なURLパターンを選ぶ
• hreflangクラスターと同一言語内のcanonicalルールを計画する
• ユーザー向けの言語・地域切り替え機能を追加する
• 他のバージョンへのアクセスを妨げる、ロケールに基づく強制リダイレクトを無効にする
• 言語品質のQAと市場適合性のQAに、それぞれ責任者を割り当てる
• 各ロケールの公開後に、インデックス可能かどうかをQAで確認する
• 更新されなくなった内容の薄い言語別テンプレートを廃止するか、noindexを設定する

検索順位とAIの回答への影響

Google Searchは今も、UI周りだけの表面的な翻訳と、主要コンテンツまで翻訳された本来の言語版を区別しています。Bingでも同様に、インデックス登録を有意義なものにするには、内容の充実したロケール別ページが必要です。ChatGPT、Claude、Perplexityでは、ローカライズの品質が、その市場で回答が役立つかどうかを左右します。地域に合った用語や事例、裏付けとなる情報源は、直訳よりも効果的です。翻訳が決めるのは言語ですが、ローカライズが決めるのは、そのページが地域の検索意図に対して上位表示されるかどうか、そして信頼できる回答の情報源になれるかどうかです。2言語対応のテーマを導入するだけで、どちらかの成果が保証されるわけではありません。

プラットフォーム別ガイド：Google Search

Googleは今も、定型部分だけの翻訳と、主要コンテンツまで翻訳された本来の言語版を区別しています。ローカライズの品質は、インデックス登録がどれほど有用になるかに影響します。既知の制約を明記しましょう。根拠のないランキング要因を作り出さず、従来のインデックス関連指標と、回答エンジンでの引用確認は分けて扱ってください。

プラットフォーム別ガイド：Bing

Bingでも同様に、市場向けコンテンツを有意義にインデックス登録するには、UI周りの差し替えだけでなく、内容の充実したロケール別ページが必要です。既知の制約を明記しましょう。根拠のないランキング要因を作り出さず、従来のインデックス関連指標と、回答エンジンでの引用確認は分けて扱ってください。

プラットフォーム別ガイド：ChatGPT

地域に即した質問には、地域に即した回答が必要です。アシスタントの有用性を高めるには、直訳よりも適切な用語や事例が重要になります。既知の制約を明記しましょう。根拠のないランキング要因を作り出さず、従来のインデックス関連指標と、回答エンジンでの引用確認は分けて扱ってください。

プラットフォーム別ガイド：Claude

ローカライズが不十分だと、内容の深さと根拠の質が損なわれます。Claudeのような説明型の回答では、その弱点がすぐに表れます。既知の制約を明記しましょう。根拠のないランキング要因を作り出さず、従来のインデックス関連指標と、回答エンジンでの引用確認は分けて扱ってください。

プラットフォーム別ガイド：Perplexity

調査目的のクエリでは、市場に特化した情報源が重視されます。ローカライズでは、引用可能な地域固有の裏付け情報を保持する必要があります。既知の制約を明記しましょう。根拠のないランキング要因を作り出さず、従来のインデックス関連指標と、回答エンジンでの引用確認は分けて扱ってください。

GlotEOが担う役割

開発チームがマトリクスの完成を待つ一方で、調査、ブリーフ、各言語版の間にずれが生じると、翻訳・ローカライズの取り組みは停滞します。GlotEOのウェブサイトローカライズソリューションは、上記のコンテンツ対応方針に関する意思決定を置き換えることなく、多言語チームの編集ワークフローを支援できます。

対応言語の拡大を検討しているなら、まず市場ごとに翻訳とローカライズのどちらが必要かを決め、そのうえで体系的なコンテンツ制作プロセスに沿って実行しましょう。

GlotEOのウェブサイトローカライズプラットフォームをご覧いただくか、多言語ウェブサイトの料金プランを比較してみてください。

戦略の背景については、国際SEOと多言語SEOの違いをご覧ください。hreflangの実装は、コンテンツの提供方式を決めた後に取り組む技術的な作業として位置づけましょう。URL構造の設計とツールの評価も、上記のコンテンツ提供方式に関する決定と整合させる必要があります。