自分のウェブサイトを翻訳するには:SEOを踏まえた実践的な公開ガイド
ウェブサイトを翻訳し、クロール可能な言語別ページを作る方法を解説。URL、ローカライズの範囲と深さ、AI・MTPEのワークフロー、hreflang、公開チェックリストを紹介します。

ウェブサイトを翻訳するには、CMSで単語を置き換えるだけでは不十分です。どの言語に対応するか、各市場向けにどこまでローカライズするか、そして顧客にもGoogleやBingにも利用できる、クロール可能な言語別ページをどう公開するか、明確な計画が必要です。このガイドでは、検索順位の向上を約束するのではなく、市場の選定からhreflangの設定まで、一連の手順を解説します。
このガイドでわかること
- ウェブサイトの翻訳には、単語の置き換え以外に何が必要?
- 翻訳前に言語と市場をどう選ぶべき?
- 言語ごとに異なるURLは必要?
- ウェブサイトの翻訳とローカライズの違いは?
- 翻訳したサイトでhreflang、canonical、サイトマップはどう使う?
- AI翻訳、人手翻訳、MTPEのどれを選ぶべき?
- 翻訳したウェブサイトに悪影響を及ぼすSEOのミスとは?
- 多言語サイトを安全に公開し、効果を測定するには?
要点:ウェブサイトを翻訳し、クロール可能な言語別ページとして公開する
ウェブサイトを翻訳するとは、実際にアクセスできる言語別ページを公開することです。Cookieやページ内のウィジェットで言語を切り替えるだけではありません。CMSで文字列を置き換えるだけでは不十分です。Googleは、言語版や地域版ごとにクロール可能な個別のURLを用意することを推奨しています。また、言語は画面に表示されるコンテンツから判断します。Cookie、ウィジェット、hreflangタグだけで判断するわけではありません。
長期的に機能する進め方は、次のとおりです。
- 需要があり、サポート体制を確保できる言語と市場を選ぶ。
- 市場ごとに、翻訳とローカライズをそれぞれどこまで行うか決める。
- 主要コンテンツを翻訳し、言語ごとに専用のURLで公開する。
- 相互参照するhreflang、適切なcanonical、サイトマップを設定する。
- 展開を拡大する前に、AI翻訳・MTPE・人手翻訳の品質を確認する。
編集上のコントロールを維持できるウェブサイト翻訳ツールのワークフローが必要なら、検索順位の向上をうたうことではなく、サイト構造と品質チェックの仕組みづくりから始めましょう。
まず言語と市場を決める
ツール選びから始めるのではなく、次の項目を一覧表に整理しましょう。
- 言語(フランス語、ドイツ語、日本語)
- 対象市場の方針(複数の国で同じ言語版を使うか、国ごとのバリエーションを用意するか)
- 事業上の優先事項(収益、サポート、法的対応の準備状況)
- コンテンツの対象範囲(まずはトップページと商品ページから始めるか、サイト全体を対象にするか)
Googleは、多言語サイトと多地域サイトを区別しています。世界中のユーザーに向けてスペイン語に翻訳することと、特定の国を対象にes-MXとes-ESを公開することは異なります。言語を増やすべきか、対象国を増やすべきか、あるいはその両方が必要か判断がつかない場合は、本格的なウェブサイト翻訳プロジェクトを依頼する前に、国際SEOと多言語SEOの違いを確認してください。
実践上の原則は、内容の乏しい言語・地域版を数多く公開するより、まず少数でも質の高いものを公開することです。メニューだけが翻訳され、本文は英語のままの中身に乏しいページでは、ユーザーの期待にも、有用なコンテンツに求められる水準にも応えられません。
ウェブサイトの翻訳とローカライズの違い
ウェブサイト翻訳は、原文の意味に忠実に、コンテンツを別の言語で表現することです。
ウェブサイトのローカライズは、さらに踏み込み、通貨、法的な文言、事例、画像、文化的な表現、市場に合わせたUXまで調整することです。
ヘルプ記事は原文に忠実に翻訳できても、料金表示、購入手続き、規制対象となる訴求表現にはローカライズが必要な場合があります。Googleは「ローカライズ」という名前の独立したランキング要因を設けているわけではありません。ただし、各言語版は大部分が単一の言語で書かれ、ユーザーを第一に考えた主要コンテンツを備えていることが期待されます。共通部分だけの翻訳(ナビゲーションなどは翻訳されていても、本文は英語のまま)では、言語版として不十分です。
判断のポイント:
- 意味をそのまま伝えやすい情報提供ページは、まず翻訳から始める。
- コンバージョンや法務に関わるテンプレート、市場ごとの配慮が必要なテンプレートはローカライズする。
- 用語集を整備し、各言語・地域版でブランドや製品に関する用語の一貫性を保つ。
翻訳ページのURL設計
検索に対応するためにウェブサイトを翻訳するなら、言語ごとに安定した公開URLを用意しましょう。代表的な構成は次のとおりです。
- フォルダ:
example.com/fr/... - サブドメイン:
fr.example.com/... - ccTLD:
example.fr/...(対象国を示すシグナルは強まるものの、運用負担も増える)
Cookieやクライアント側の設定で言語を切り替える単一のURLに依存するのは避けましょう。Googleは、推定した所在地に基づく自動リダイレクトではなく、クロール可能な代替URLと、ユーザーが画面上で操作できる言語・国の選択機能を推奨しています。
どの構成を選ぶ場合も、テンプレート、サイトマップ、アクセス解析、内部リンク全体で統一してください。開発チームとコンテンツチームは、共通の対応表を使う必要があります。
hreflang、canonical、サイトマップ
hreflangは、言語や地域が異なる代替ページの存在をGoogleに伝えます。ページの言語を検出するものではなく、翻訳品質を補うものでもありません。同じグループに属するページは相互に参照する必要があります。各言語・地域版のURLには明確なcanonicalを設定し、重複ページがある場合は、同じ言語の優先ページを正規URLとして指定します。
サイトマップは各言語版の検出を助けます。サイトマップ方式を使う場合は、xhtml:linkによるhreflangアノテーションも記述できます。各言語・地域版のURLをSearch Consoleに送信し、状況を確認しましょう。複数の検索エンジンを対象にする場合は、Bing Webmaster Toolsでも同様に行います。
効果的な実装の順序:
- 主要コンテンツを翻訳した、クロール可能な言語・地域別のHTMLページを公開する。
- canonicalの設定を整合させる。
- 相互参照するhreflangを生成する。
- サイトマップを更新する。
- 展開を拡大する前に、URL検査や公開サイトのクロールで検証する。
AI翻訳・人手翻訳・MTPEのワークフロー
AIウェブサイト翻訳ツールを使えば下訳を効率化できますが、ウェブサイト翻訳では、モデルだけでなく運用も同じくらい重要です。ページのリスクに応じてワークフローを選びましょう。
- 機械翻訳をそのまま使用:リスクの低い社内向けの下訳に限定し、コンバージョンを目的とする公開ページには使用しません。
- MTPE(機械翻訳+ポストエディット):用語集とレビューによる承認プロセスが整っていれば、多くの製品ページやサポートページで標準的な選択肢となります。
- 人手翻訳:法務関連の文章、ブランドの語り口が重要な文章、コンバージョンへの影響が大きい文章、文化的な配慮が必要な文章に適しています。
ユーザーを第一に考えた有用なコンテンツが求められる点は、どの言語でも変わりません。ナビゲーションが翻訳されていても、本文が低品質な機械翻訳のみでは、その言語のユーザーに十分な価値を提供できません。
品質確保に最低限必要な仕組み:
- ブランド用語と製品用語の用語集
- 一貫性と作業スピードを高める翻訳メモリ
- 優先度の高いテンプレートに対する人によるレビュー
- 複数言語が混在したページの公開を防ぐチェック体制
コンテンツ品質とSEOの要件
検索エンジンが評価するのは、翻訳ツールのブランドではなく、クロール可能で役に立つ各言語版のコンテンツです。規模を拡大する前に、次の点を確認しましょう。
- メニューだけでなく、メインコンテンツも翻訳する。
- 各ロケールのURLごとに、タイトル、メタディスクリプション、見出しをローカライズする。
- 各ページは、原則として1つの言語で統一する。
- 見つけやすい言語切り替えメニューを設ける。
- クローラーやユーザーを特定のロケールへ強制的にリダイレクトしない。
- どのロケールでも、組織や製品のエンティティを一貫させる。
Bingでも、クロール可能で有用なコンテンツと明確な構造が求められます。まず共通の基盤を構築し、必要に応じてGoogleとBingの両方でプロパティをモニタリングしましょう。
公開前のチェックリスト
公開対象のロケール向けにウェブサイトを翻訳する準備ができたら、次のチェックリストを活用してください。
サイトを「ただ翻訳する」だけで起こりがちな失敗
- Cookieのみに依存した言語切り替えにより、クローラーが別言語版を発見できない
- 共通部分だけを翻訳し、本文が英語のままになっている
- hreflangの設定不備(戻りリンクの欠落、無効なコード、canonicalとの矛盾)がある
- すべての言語で同じ英語のメタデータを使い回す
- 地域に基づく自動リダイレクトにより、ユーザーやボットが他の言語版にアクセスできなくなる
- 1つのロケールさえ継続的に運用できる体制が整わないうちに、10ロケールへ拡大する
- 翻訳ツールを使えば検索順位が上がると約束する。どのツールであっても、裏付けのない危険な主張です
まずはサイト構造とコンテンツ品質を改善しましょう。ツールは、そのプロセスを確実に実行するために使うべきです。
従来の検索と回答エンジンに共通する基盤
Google、Bing、回答エンジンのいずれでも、ウェブサイト翻訳の共通基盤は重要です。具体的には、クロール可能な各言語版、明確なエンティティ、根拠のある主張、事実に即した構造化データ、そして英語中心の見せかけの対応ではない、実質的なローカライズが求められます。
プラットフォーム別ガイド:Google Search
Google検索にページを発見してもらうには、クロール可能な各ロケールのURL、対象言語に適したHTML、正確なタイトルと見出し、別言語版がある場合は相互参照するhreflangが必要です。技術的な基盤には、インデックス登録可能なコンテンツ(Cookieだけに依存する言語切り替えでは不十分)、ローカライズされたメタデータ、サイトマップ、適切なcanonical管理が含まれます。コンテンツの品質とは、各言語でユーザーを第一に考えたメインコンテンツを提供することです。権威性は、翻訳ツールの宣伝ではなく、組織の明確な身元情報と、それを裏付ける情報源によって築かれます。多言語対応では、各言語のURLが単独で成立している必要があります。Search ConsoleのカバレッジとURL検査を使い、ロケールごとに測定しましょう。確かなことと不確かなことを区別するのも重要です。Googleは多言語サイトとhreflangの動作を文書化していますが、特定のCMSやAI翻訳ワークフローによる検索順位を保証してはいません。
プラットフォーム別ガイド:Bing
Bingは、GoogleがURLやコンテンツの明確さに求めるものと同様に、構造が明確でクロール可能な多言語ページを検出し、インデックスに登録します。技術的な基盤には、取得可能なロケール別URL、有用なコンテンツ、Bing Webmaster Toolsでの監視が含まれます。UI要素だけを翻訳するのではなく、見出し、主張、FAQのローカライズを優先してください。権威性を示す要素としては、引き続き信頼できる情報源と一貫したエンティティが重要です。多言語対応では、クライアント側だけで動作する切り替え機能の背後に各言語版を隠さないでください。Bing Webmaster Toolsでインデックス登録状況とクロール統計を測定しましょう。確かな点と不確かな点:Bingのガイドラインは、クロール可能で有用なコンテンツを重視しています。翻訳ツールに関して、Bing独自のランキング要因を根拠なく想定しないでください。
プラットフォーム別ガイド:ChatGPT
ChatGPTは、言語版が明確で、回答に利用しやすい形で情報が整理されている場合、一般公開されたページを引用・要約することがあります。情報の発見は、従来のクロールに基づく検索順位とは異なります。ここでの露出とは、情報源に選ばれたり、回答内で参照されたりすることです。技術的な基盤となるのは、やはりアクセス可能なHTMLのURLであり、本文を隠してしまうウィジェットのオーバーレイではありません。明快な回答、FAQ、用語集に基づく一貫した用語の使用などが、コンテンツの有用性を高めます。権威性は、根拠と、ロケールをまたいだエンティティの一貫性から生まれます。多言語対応では、各ロケールのページが単独で読んでも理解できる必要があります。測定には限界があるため、引用状況の確認結果は仮説として扱いましょう。確かなことと不確かなことの区別も必要です。どのウェブサイト翻訳ツールについても、ChatGPTで引用されることを保証する文書化された根拠はありません。
プラットフォーム別ガイド:Gemini
Geminiと関連するGoogleのAIサービスでは、一貫したエンティティ、正確な構造化データ、インデックス登録可能なローカライズ済みページが役立ちます。可視性とは、参照・認識されることであり、Gemini独自のランキング要因を根拠なく想定することではありません。技術的な基盤は、Google検索のクロール可能性やメタデータの品質と共通しています。コンテンツでは、各言語で主張や定義を明確に示す必要があります。権威性は、組織情報の一貫性と裏付けに左右されます。多言語対応では、用語集で製品名を統一することで、ロケール間の混乱を減らせます。従来どおりSearch Consoleで測定しつつ、AIの回答を抽出して定性的にも確認してください。確かな点と不確かな点:Geminiの挙動は、hreflangや各言語版に関するGoogle検索の公式ガイダンスの代わりにはなりません。
プラットフォーム別ガイド:Google AI Overviews
Google AI Overviewsは、回答の裏付けとなるページへのリンクを表示することがあります。掲載対象となるための基本は、引き続きユーザーを第一に考えた、インデックス登録可能なコンテンツです。AI Overviewsは言語切り替え機能ではなく、hreflangの代わりにもなりません。技術的な基盤は、クロール可能なロケール別HTMLと、事実に即した構造化データです。コンテンツ面では、各言語での簡潔な回答と明確な見出しが重要です。権威性の評価も、有用なコンテンツに求められる水準に沿ったものです。多言語対応では、翻訳されたページがAI Overviewsに掲載される保証はありません。Search Consoleで生成AI関連のレポートが利用できる場合はそれを使って測定し、従来のインデックス指標とは分けて管理してください。確かな点と不確かな点:どのような翻訳ワークフローでも、AI Overviewsへの掲載を約束することはできません。
GlotEOが担う役割
単一URL上で言語を切り替えるのではなく、クロールとレビューが可能な各言語版としてウェブサイトを翻訳したい場合、GlotEOのウェブサイトローカリゼーションプラットフォームが、用語集の管理、翻訳メモリ、SEOを考慮した公開機能により、多言語コンテンツのワークフローを支援します。
検索を重視するチームで、翻訳に加えてアノテーションやロケールの運用管理も必要な場合は、GlotEOの多言語SEOプラットフォームも検討できます。言語と市場の対応表を実際の運用に移す準備ができたら、GlotEOの料金とプランを比較してください。
参考文献
- この記事で紹介した指針の根拠資料(Bingウェブマスターガイドライン)
- この記事で紹介した指針の根拠資料(rel=canonicalなどの方法で正規URLを指定する方法)
- この記事で紹介した指針の根拠資料(有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成)
- この記事で紹介した指針の根拠資料(ページのローカライズ版をGoogleに知らせる)
- この記事で紹介した指針の根拠資料(多地域・多言語サイトの管理)
- この記事で紹介した指針の根拠となる資料(サイトマップについて学ぶ)