多言語サイトのためのSearch Console実践ガイド

Search Consoleのプロパティ構成、ロケールごとのサイトマップとインデックス登録状況の監視、hreflangの問題診断、言語間のパフォーマンス比較、ローカライズの更新サイクルに合わせたSEO運用を解説します。

Grant Davies更新日

多言語サイト向けSearch Console：ロケールを示すチップと抽象的なグラフを備えた、Search Console風のプロパティウィンドウ

Google Search Consoleは、多言語SEOの運用ダッシュボードとして活用できます。ただし、プロパティの設定、レポート、確認頻度を、各言語版の実際の公開運用に合わせることが前提です。このガイドでは、各言語版、hreflangアノテーション、サイトマップ、インデックス登録の監視や、ロケール間のパフォーマンス比較に役立つ、実践的なSearch Consoleのワークフローを紹介します。

要点：デフォルト言語だけでなく、すべてのロケールのURL群を監視する

結論： クロール可能なロケール別URLを軸にSearch Consoleを整理し、インデックス登録、サイトマップ、hreflang関連の問題、パフォーマンスを言語セグメントごとに監視しましょう。デフォルト言語を中心としたサイト全体の集計指標だけでは不十分です。

Googleは、各言語版にそれぞれ異なるクロール可能なURLを用意することを推奨しています。フランス語ページが/fr/配下にある場合は、英語のルートと同様に、/fr/も主要なセグメントとして日常的に監視する必要があります。デフォルト言語のグラフが良好でも、ほかの言語では代替ページへの参照切れ、内容の乏しい未完成のロケールページ、サイトマップの漏れなどが隠れている可能性があります。

hreflangクラスターには相互参照が必要です。戻りリンク、コード、canonicalの競合によってクラスターが崩れたとき、Search Consoleでの診断が出発点になることがよくあります。Bing経由の流入が重要な市場では、Search Consoleでの確認にBing Webmaster Toolsも併用しましょう。

プロパティとドメインの設定方法

多言語サイトのSearch Consoleプロパティは、どう整理すればよいですか？

DNSによる所有権確認が可能なチームの多くは、1つのドメインプロパティ（example.com）を使用しています。サブドメインやプロトコルをまとめてカバーできるためです。対象範囲を絞る必要がある場合は、URLプレフィックスプロパティが適しています。たとえば、単一のサブドメインやサブディレクトリで試験運用する場合です。

ロケールをサブディレクトリ（example.com/fr/）で分けている場合、ドメインプロパティですべてのロケールを一元的に把握できます。URLに/fr/を含む条件でレポートを絞り込むか、利用可能な探索機能で正規表現によるセグメントを使用します。ロケールをサブドメイン（fr.example.com）で分けている場合も、ドメインプロパティではデータが集約されます。どのホスト名がどの言語に対応するかを文書化しておきましょう。

所有権確認は一度行い、その後、SEOやローカライズの関係者に必要最小限の権限でアクセスを付与します。履歴が分散しないよう、所有権未確認の重複プロパティを作成するのは避けましょう。

各言語版で特に重視すべきレポートはどれですか？

まずはページ、インデックス作成、サイトマップ、URL検査から確認しましょう。hreflangに関する兆候を探すには、拡張レポートやインデックス登録の詳細で、代替URLやcanonicalの競合に関する記載に注目します。インデックス登録が正常になったら、パフォーマンスレポートでロケール間を比較できます。

Googleは主にページ上に表示されるコンテンツから言語を判断します。Search Consoleで、インデックス登録済みURLのタイトルやスニペットに複数の言語が混在している場合は、アノテーションの微調整を進める前にコンテンツを修正しましょう。

サイトマップとURL検出の監視

ロケールごとのサイトマップは、どのように送信・監視すればよいですか？

サイトマップには、デフォルト言語だけでなく、すべてのロケールのURLを含めます。XMLサイトマップは各言語版の検出を助けます。また、hreflangの実装方法としてサイトマップを使用する場合は、xhtml:linkのhreflangアノテーションを含めることができます。

サイトマップはプロパティ単位（ドメインまたは適切なプレフィックス）で送信します。新しいロケールの公開後やCMSでの一括公開後には、毎回次の作業を行います。

  1. 新しいロケールのURLとhreflangの代替URLを含めて、サイトマップファイルを再生成します。
  2. Search Consoleのサイトマップレポートで再送信します。
  3. ステータスが「成功しました」になっていることを確認し、取得エラーがないか監視します。
  4. URL検査でサンプルURLを抜き取り確認します。

サイトマップは、各言語版を含むURLの検出をGoogleに促します。また、hreflangの実装方法としてサイトマップを使用する場合は、hreflangアノテーションを含めることができます。英語のURLしか記載されていないサイトマップでは、新しいロケールの検出が遅れます。

最終読み込み日時とエラー件数を監視しましょう。大量の翻訳をまとめて公開した後にサイトマップが更新されないのは、気づかれにくい典型的な不具合です。

カバレッジ、インデックス登録、URL検査

ロケール別ページのURL検査では、何がわかりますか？

URL検査では、Googleが特定のロケールのURLを取得できるか、どのURLがインデックスに登録されているか、検出されたcanonical、さらに情報がある場合は関連付けられたhreflangの代替URLを確認できます。サンプルの組み合わせ表を用意し、ホームページ、商品テンプレート、ブログ記事、法務関連ページを、それぞれ2言語以上で検査しましょう。

確認するポイント：

  • インデックス登録は許可されているか？ — robots、noindex、認証制限によってロケール別のパスがブロックされていないか。
  • canonical — 同じ言語の優先URLが指定されているか。別の言語のURLを誤ってcanonicalに指定していないか。
  • 代替URL／hreflang — 戻りリンクの欠落やコードの誤りがないか。
  • クロールに使用されたユーザーエージェント — ローカライズ済みテンプレートで、PCまたはモバイルのレンダリングに問題がないか。

各言語・ロケールのURLには、明確なcanonicalを設定する必要があります。重複がある場合は、同じ言語の優先URLを指定します。

デプロイ後は、本番環境の英語ページだけでなく、各言語版にもURL検査を実行しましょう。ステージング環境での確認は補助にはなりますが、公開URLをGoogleがどう認識しているかの確認に代わるものではありません。

Search Consoleでhreflangやインデックス登録の問題を確認するには？

正常に対応していることがわかっているロケール間のURLペア一覧を基に進めます。

  1. URL A（英語）とURL B（対応するフランス語ページ）を選びます。
  2. Aを検査し、正しいhreflangでBが代替URLとして表示されることを確認します。
  3. Bを検査し、Aが戻りリンクとして表示されることを確認します。
  4. 見つからない場合は、再公開する前に実装箇所（HTMLのhead、HTTPヘッダー、サイトマップ）をたどって確認します。

hreflangアノテーションは、別の言語や地域に対応する代替URLをGoogleに伝えます。対象となるページ群の間で、相互に参照している必要があります。Search Consoleでは、多くの問題が単一の「hreflangレポート」ではなく、インデックス登録や拡張機能に関する警告として表示されます。詳細パネルを読み解けるよう、チーム内で確認方法を共有しましょう。

まずcanonicalの競合を解消します。代替ページのグループ化よりもcanonicalが優先される場合があるためです。その後、相互参照とロケールコード（en-GBとenの使い分けの一貫性）を修正します。

代替ページの関連付けが崩れたときに備えて、繰り返し使えるワークフローを整備しましょう。

ステップ1 — 公開URLで問題を再現する：ステージング環境のソース表示だけでなく、URL検査を使用します。

ステップ2 — 不具合を分類する：戻りリンクの欠落、コードの誤り、一部のページ間で相互参照が成立していない状態、HTTPとHTTPSの不一致、canonicalが対象ロケール以外のURLを指している状態などに分類します。

ステップ3 — テンプレートレベルで修正する：ページを1つずつ手作業で直すのではなく、次回CMSで公開したときにクラスター全体が再生成されるようにします。

ステップ4 — インデックス登録をリクエストする：デプロイ後にサンプルURLでリクエストし、再クロールを待ってからチケットをクローズします。

ステップ5 — ロケール対応表に記録する：影響を受けたテンプレートと、修正したリリースを記録します。

hreflangクラスターには相互参照が必要です。Search Consoleでの診断は、戻りリンクやコードの不備、canonicalの競合によってクラスターが崩れたことをきっかけに始まる場合がよくあります。

主要な5ページのhreflangだけを編集し、コレクションのテンプレートをそのままにするのは避けましょう。部分的な修正では、同じ問題が毎週繰り返されます。

ロケール間のパフォーマンス比較

言語間のパフォーマンスはどのように比較すべきですか？

公平に比較するためのポイント：

  • 各ロケールに対応するURLプレフィックスまたはサブドメインでセグメントを分けます。
  • 市場の成熟度を考慮して比較条件をそろえます。新しいフランス語コンテンツを、公開初週から5年の実績がある英語コンテンツと同じ基準で評価すべきではありません。
  • クエリ数が十分にある場合は、ブランド検索と非ブランド検索を分けます。
  • まずインデックス登録状況を確認します。インデックスに登録されていないロケール別URLのパフォーマンス指標は、誤った判断につながります。

Search Consoleの検索パフォーマンスにフィルタを適用するか、URLマップのロケール情報をディメンションとしてBIツールにエクスポートします。言語別のアクセス解析のランディングページレポートも併せて確認しましょう。

Googleの有用なコンテンツに関するガイダンスは、ユーザーを第一に考えたページを重視しています。内容が薄い言語版や定型文だけの言語版は、SEOの面でも、回答の情報源としても不十分です。内容が乏しいロケール別の仮ページでクリック数が少ない場合、単に「SEO効果が出るまでの時間差」ではなく、品質が原因かもしれません。

Search Consoleの調整だけで順位が上がると約束してはいけません。クロールのしやすさとコンテンツを改善したうえで、パフォーマンスの推移を慎重に解釈しましょう。

ローカライズと連携した運用サイクル

ローカライズとSEOは、どのような運用サイクルを共有すべきですか？

リリーススケジュールを連携させましょう：

実施頻度SEO／Search Consoleの作業ローカライズの作業
公開前URLパターン、hreflangテンプレート、サイトマップ計画を検証用語集、翻訳メモリ（TM）、レビューの承認工程を整備
公開週サイトマップを送信し、サンプルマトリクスに沿ってURL検査を実施。インデックス登録状況を監視承認済みの修正を除き、一括編集を停止
毎週新たなエラーを確認し、新規URLを抜き取りチェックQAチェックリストを使い、翻訳済みコンテンツをバッチ単位で公開
月払いロケール別セグメントのパフォーマンスを確認し、hreflangを抜き取り監査内容が乏しい仮ページを廃止し、ユーザーの意図が明確な領域のコンテンツ不足を優先的に解消
四半期ごとドメインプロパティへのアクセス権を再確認し、解決済みの問題をアーカイブロケールマトリクスとCMSの実際の状態を照合

ロケールマトリクスを共同で管理すれば、SEO担当が新しい/de/ページの存在をローカライズ担当からではなくSearch Consoleで初めて知る、といった事態を防げます。

Googleは、推測した言語や所在地に基づいてユーザーを自動的にリダイレクトしないよう推奨しています。ローカライズのユーザー受け入れテスト（UAT）では、翻訳文だけでなく、言語セレクターの動作も確認しましょう。

よくある間違い

多言語サイトの診断を遅らせるSearch Consoleのミスには、どのようなものがありますか？

  1. デフォルト言語のパスしか監視しない — トラフィックが途絶えるまで、/fr/のインデックス登録が大幅に失われていることに気づきません。
  2. ロケール公開後にサイトマップを再送信しない — URLの検出が遅いことを「SEOが機能していない」せいにしてしまいます。
  3. 英語ページでしかURL検査を行わない — 他言語版がまったく検証されません。
  4. プロパティが重複している — 履歴が分散し、サイトマップが誤ったプロパティに関連付けられます。
  5. hreflangは一度設定すればよいと考える — CMSのテンプレート変更によって、気づかないうちに相互参照が崩れます。
  6. 別言語のページをcanonicalに指定する — ロケール別コンテンツに対し、Search Consoleで誤ったURLがインデックス登録済みとして表示されます。
  7. Bing Webmaster Toolsを無視する — Bing Webmaster Guidelinesは、クロール可能で有用なコンテンツを重視しています。市場によっては、並行して監視する必要があります。
  8. インデックス登録前にパフォーマンスを心配しすぎる — Googleがまだインデックスに登録していないURLのタイトルを最適化してしまいます。

単一のプロパティ画面でキーワード単位の微調整を追い求める前に、サイト構造とアノテーションを修正しましょう。

実装チェックリスト

従来の検索と回答エンジンに共通する基盤

Google、Bing、回答エンジンのいずれでも、共通の基盤は引き続き重要です。クロール可能な各言語版、明確なエンティティ、根拠のある主張、実態に即した構造化データ、そして英語のままの外枠ではなく、実質的なローカライズが求められます。以下のガイドは、同じ多言語配信の基準をプラットフォーム別の視点から捉えたものとして活用してください。

Google検索でページが検出されるには、各言語に適したHTMLを備えたクロール可能なロケール別URL、正確なタイトルと見出し、そして代替ページがある場合は相互参照するhreflangが必要です。技術的な基盤には、Cookieのみに依存した言語切り替えではなくインデックス登録可能なコンテンツ、ローカライズされたメタデータ、サイトマップ、適切なcanonical管理が含まれます。コンテンツ品質とは、各言語でユーザーを第一に考えたメインコンテンツを提供することです。権威性は、組織の明確な身元と裏付けとなる情報源から生まれるものであり、翻訳ツールの宣伝から生まれるものではありません。多言語対応で重要なのは、市場別・言語別の各URLが単独で成立することです。Search ConsoleのカバレッジとURL検査を使い、ロケールごとに測定してください。確かな点と不確かな点を区別しましょう。Googleは多言語対応とhreflangの動作を文書化していますが、特定のCMSや翻訳ワークフローによる検索順位の向上を保証してはいません。

プラットフォーム別ガイド：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が担う役割

Search Consoleはロケール別URLの不具合を知らせてくれますが、予防にはワークフローの整備が必要です。GlotEOは、hreflangに対応したロケール構成表、用語集に準拠した翻訳、公開前の承認プロセスを、Search Consoleの監視項目と整合させるために役立ちます。これにより、URLがインデックスに登録される前に、SEOとローカライゼーションの両チームが信頼できる共通の情報源を参照できます。

翻訳ワークフローとあわせてアノテーションを適切に管理できる多言語SEOプラットフォームをご覧ください。ロケール数の増加に伴ってSearch Consoleのエラー件数が増えてきたら、GlotEOの料金とプランもご確認ください。戦略の背景については、国際SEOと多言語SEOの違いで解説しています。

参考文献