多言語ウェブサイトをBing向けに最適化する方法

ロケール別URL、サイトマップ、hreflang、Bing Webmaster Tools、コンテンツ品質チェックを活用し、Bingでクロール・状況監視ができる多言語サイトに。Bing特有の順位決定要因について、根拠のない俗説は持ち込みません。

Grant Davies更新日

多言語サイトをBing向けに最適化する方法：IndexNow風のチップとロケール別URLの行を備えた、Bing Webmaster風のタイル

多言語サイトのBing向け最適化では、まずGoogleが文書で示すのと同じクロール可能性の基準を満たし、そのうえでMicrosoftのチームがインデックス状況の監視に利用しているBing Webmaster Toolsの運用フローを取り入れます。BingはGoogleと同じではありませんが、Bing Webmaster Guidelinesでも、市場をまたいだインデックス登録において、クロール可能で有用なコンテンツと明確なサイト構造が重視されています。

このBingを中心としたガイドでは、ロケール別のURL設計、サイトマップ、hreflang、Bing Webmaster Toolsの設定、コンテンツ品質、効果測定、よくある間違いを解説します。根拠のないBing独自のランキング要因や、Copilotへの掲載保証をうたうことはありません。

このガイドでわかること

  • 多言語URLの設計において、Bingが求めるものは？
  • Bing向けのサイトマップとロケール別ページの検出は、どう整えるべきか？
  • hreflangと言語の明確さは、Bingのインデックス登録にどう影響するか？
  • 市場ごとにBing Webmaster Toolsをどう設定すべきか？
  • 多言語サイトのBingでの露出を損なう、コンテンツ品質の問題とは？
  • 架空の要因に頼らず考える、Bing最適化とCopilotでの発見されやすさの関係とは？
  • チームはどのくらいの頻度で効果測定を行うべきか？
  • 多言語サイトのBing対策で避けるべき、よくある間違いとは？

要点：Bingでも最優先はクロール可能なロケール別URL

結論：Bing独自の近道を探す前に、言語ごとに独立したクロール可能なURLを用意し、コンテンツを原則としてその言語で統一しましょう。対応する別言語・地域版がある場合は相互に参照するhreflangを設定し、サイトマップを更新して、Bing Webmaster Toolsで所有権を確認します。

言語版ごとに独立したクロール可能なURLを用意することは、Bingを含む検索エンジンでのインデックス登録の実務的な基盤です。別のURLを用意せず、Cookieやブラウザーの言語設定だけで言語を切り替えると、MicrosoftがBingや関連サービスで使用するクローラーから各言語版が見えなくなります。

Googleは、Cookieやブラウザーの言語設定だけに頼るのではなく、言語・地域版ごとに異なるクロール可能なURLを用意することを推奨しています。Bingに適したサイトも、同じ設計原則に従っています。

Bing向け多言語サイト設計の要件

Bing Webmaster Guidelinesでは、クロール可能で有用なコンテンツと明確なサイト構造が重視されています。これらの要件は、多言語サイトのロケール別URLにも同様に当てはまります。実用的な構成の選択肢は次のとおりです。

  • サブディレクトリ（example.com/fr/）— Bing Webmaster Toolsで1つのドメインを管理する場合、多くの場合これが最もシンプルです。
  • サブドメイン（fr.example.com）— 個別の所有権確認が必要になる場合があります。所有者を記録しておきましょう。
  • 国別ドメイン（example.fr）— Bing Webmaster Toolsでドメインごとに個別のプロパティを設定します。

どの構成でも、URLが安定しており、内部リンクでつながり、サイトマップに記載されていれば機能します。Googleは主に表示されるコンテンツからページの言語を判断します。各言語版では、コンテンツとナビゲーションを原則として1つの言語に統一しましょう。この明確さは、Bingのインデックス登録にも役立ちます。

推測した言語や所在地に基づいて、ユーザーを自動的にリダイレクトすることは避けましょう。Googleは自動リダイレクトを推奨せず、代わりにユーザーが操作できる言語・国の選択機能を設けるよう勧めています。これにより、Bingのクロール時の混乱も減らせます。

サイトマップ、検出、インデックス登録

XMLサイトマップは各言語版の検出に役立ち、hreflangの実装方法として選ぶ場合は、xhtml:linkによるhreflangアノテーションも記載できます。新しいロケールの公開時や大規模なCMS移行後には、すべての対象URLを網羅したサイトマップをBing Webmaster Toolsに送信しましょう。

Bing向け多言語サイトのサイトマップ管理のポイント：

  1. インデックス登録可能なロケール別URLをすべて含め、孤立したフォルダーを残さない。
  2. パラメーターによる重複URLやセッションIDを除外する。
  3. コンテンツに実質的な変更があった場合は、lastmodを更新する。
  4. 非常に大規模なサイトでは、必要に応じてサイトマップを分割し、サイトマップインデックスで管理する。

各言語・ロケールのURLには、明確なcanonicalを設定しましょう。重複がある場合は、同じ言語の優先URLを指定します。すべての言語版を英語版に集約するようなcanonicalの誤設定は、GoogleとBingの両方がローカライズされたページを理解する妨げになります。

言語の明確さ、hreflang、言語選択機能

hreflangアノテーションは、対応する別言語・地域版のURLをGoogleに伝えるもので、対象となるページ群の間で相互に参照する必要があります。Bingでは、Google Search Consoleと同じようにhreflangエラーが表示されるとは限りませんが、多言語ページ群で代替ページを相互に参照することは、引き続きベストプラクティスです。

実装チェックリスト：

  • 有効なBCP 47コードを使用する（必要に応じてen-US、fr-FR、x-default）。
  • ページ群の各URLが、自身を含むすべての代替ページを参照していることを確認する。
  • アノテーションには絶対URLを優先して使用する。
  • ページの追加や廃止に合わせて、アノテーションの整合性を保つ。

同じURL上でJavaScriptだけで表示を切り替えるのではなく、別言語・地域版のURLにリンクする、目に見える言語選択機能を追加しましょう。ユーザーとクローラーの両方に役立ちます。

多言語サイト向けのBing Webmaster Tools設定

運用する各ドメインまたはサブドメインの所有権を、Bing Webmaster Toolsで確認しましょう。1つのドメイン内でロケールをサブディレクトリに分けている場合は、多くの場合、所有権確認済みのプロパティ1つで対応できます。fr.example.comとde.example.comの場合は、各ホストの所有権を確認してください。

Bing Webmaster Toolsで継続的に行う作業：

  • URL検査 — 各ロケールの代表的なURLをBingが取得できるか確認する。
  • サイトマップ — 送信し、処理エラーを監視する。
  • サイトエクスプローラー — フォルダーの欠落や想定外の重複を見つける。
  • クロール情報 — hreflangやCMSの変更後に急増がないか確認する。

移行中は、Bingで監視しているURLをGoogle Search Consoleでも確認しましょう。検索エンジンごとに異なる問題を、より早く発見できます。

各ロケールのコンテンツ品質

Googleの有用なコンテンツに関するガイダンスは、ユーザーを第一に考えたページを重視しています。内容が乏しい、または定型文だけの言語版は、SEOの面でも回答の情報源としても弱いものです。Bingのインデックス登録でも同様に、形だけの翻訳ページより、有用でクロール可能なページが評価されます。

各ロケールを次の観点で評価しましょう。

  • 本文コンテンツの充実度 — ナビゲーションなど、画面の共通部分だけの翻訳で終わらせない。
  • 各言語に適した用語 — 用語集を使い、製品名に複数の言語が混在するのを防ぐ。
  • 信頼性を示す情報 — お問い合わせ、法的情報、サポートの各ページをローカライズし、ユーザーが探しやすい場所に配置する。
  • 内部リンク — 言語をまたぐリンクを意図的に設ける場合を除き、同じロケール内で完結させる。

構造化データは、不十分な翻訳を補うためではなく、ローカライズされたコンテンツを正確に反映するために使うべきです。

測定と継続的な改善

Bingの多言語施策では、次の作業を毎月実施しましょう。

  1. Bing Webmaster Toolsで、主要なロケール別ランディングページを抽出し、インデックス状況を確認する。
  2. 同じロケールフォルダについて、BingとGoogleのインデックス済みURL数を比較する。
  3. CMSで一括編集を行った後は、hreflangの相互参照を再確認する。
  4. サイトマップの更新後に、Search ConsoleとBingのレポートを確認する。
  5. 翻訳プラグインの更新時に発生した不具合や品質低下を記録する。

Microsoft CopilotやBing Chatは、Bingがインデックス登録できるコンテンツを利用する可能性があります。ただし、hreflangやサイトマップの施策だけでCopilotに引用されることを保証する公開ドキュメントはありません。AIでの露出は、副次的な仮説として扱いましょう。

よくある間違い

  1. Googleだけを監視する — ロケール別URLのBingでのインデックス状況を一度も確認しない。
  2. Cookieだけでロケールを切り替える — Bingbotがクロールできる別言語版が存在しない。
  3. hreflangの相互参照が成立していない — 新しいロケールが一部のテンプレートにしか追加されていない。
  4. ローカライズ済みURLのメタデータが英語のまま — タイトルや説明文が翻訳されていない。
  5. IPアドレスによる自動リダイレクト — ユーザーやクローラーが別言語版にアクセスできなくなる。
  6. 仮のページしかないロケール — 内容の乏しい仮ページをサイトマップに登録している。
  7. サイトマップの更新漏れ — 新しい/pl/フォルダをBingが認識できない。
  8. BingでもGoogleとまったく同じエラーが起きると思い込む — 両方のツールで検証する。

実装チェックリスト

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

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

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

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

Bingは、構造が明確でクロール可能な多言語ページを検出し、インデックスに登録します。これは、GoogleがURLやコンテンツに求める明確さと似ています。技術面の基盤には、取得可能なロケール別URL、有用なコンテンツ、各プロパティまたは所有権確認済みドメインを対象としたBing Webmaster Toolsでの監視が含まれます。ナビゲーションだけが切り替わり、本文は元の言語のままという翻訳ではなく、見出し、訴求内容、FAQまでローカライズしましょう。権威性を示す要素も、引き続き信頼できる情報源と、ロケール間で一貫したエンティティ情報に依存します。多言語対応では、クライアント側だけで動作する切り替えや、単一URL上のCookieによる切り替えの背後に言語版を隠し、クローラーが各言語版を把握できない状態にしてはいけません。Microsoftのインデックス状況を測定する主要なツールは、引き続きBing Webmaster Toolsです。各ロケールを反映したサイトマップを送信し、クロール統計を監視し、サブディレクトリやサブドメインのロケール別パスが、その言語で統一されたHTMLと200レスポンスを返すことを確認してください。Bing Webmaster Guidelinesでは、クロール可能で有用なコンテンツと明確なサイト構造が重視されており、これらの要件は多言語のロケール別URLにも同様に適用されます。Google Search Consoleしか見ていないチームは、Microsoftの利用が多い市場で、Bingのインデックス登録漏れを見逃してしまいます。Bingは、Googleと同一の独立したhreflang仕様を公開していませんが、別言語版の相互参照と、個別にクロール可能なURLは、実務上のベストプラクティスです。Bing独自のランキング要因を作り上げず、クロールのしやすさ、構造、そしてユーザーを第一に考えた現地向けコンテンツに注力しましょう。

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

ChatGPTは、言語版が明確で、回答に使いやすく整理された公開ページを引用・要約する場合があります。ページの発見は、従来のクロールに基づく順位付けとは異なります。露出とは、検索結果ページで順位付きで表示されることではなく、情報源として選ばれたり、回答内で参照されたりすることです。技術面の出発点は、引き続きアクセス可能なHTMLのURLであり、取得側からテキストを隠してしまうウィジェット型のオーバーレイではありません。有用なコンテンツの特徴には、端的な回答、FAQ、ロケールごとに管理された用語集による一貫した用語の使用があります。権威性は、根拠と、言語をまたいで一貫したエンティティ情報から生まれます。多言語対応では、ユーザーが言語を切り替えることを前提にせず、各ロケールのページが単独で理解できる必要があります。測定は完全ではありません。引用の確認はKPIではなく、定性的な仮説の検証として扱いましょう。確かなことと不確かなことを区別する必要があります。構造化データ、hreflang、または特定の翻訳ワークフローによってChatGPTでの引用が得られるという、文書化された保証はありません。

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

Geminiや関連するGoogleのAI機能では、一貫したエンティティ情報、正確な構造化データ、インデックス可能なローカライズ済みページが役立ちます。露出とは、参照されたり認識されたりすることであり、Gemini専用のランキング要因を作り上げることではありません。技術面の基盤は、各ロケール別URLにおけるGoogle Searchのクロール可能性やメタデータの品質と共通しています。コンテンツでは、各言語で主張や定義を明確に示し、ユーザーを第一に考えた十分な内容を提供する必要があります。権威性は、市場をまたいで組織情報が一貫していることと、裏付けに依存します。多言語対応では、用語集で管理された製品名を使うことで、検索でもAI機能でも、ロケール間のエンティティの混同を減らせます。従来どおりSearch Consoleで測定するとともに、対象言語のAI回答を抽出して定性的に確認しましょう。確かなことと不確かなことを区別する必要があります。Geminiの挙動は、hreflangや言語版について文書化されたGoogle Searchのガイダンスに代わるものではありません。

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

Google AI Overviewsは、回答を裏付けるページへのリンクを表示する場合があります。掲載対象となるための基本は、引き続き各言語でユーザーを第一に考えた、インデックス可能なコンテンツです。言語切り替えの機能ではなく、別言語版間のhreflangアノテーションに代わるものでもありません。技術面の基盤となるのは、引き続きクロール可能なロケール別HTMLと、ページ上に表示される内容に合致した正確な構造化データです。コンテンツの重要な要素には、各言語版の簡潔な回答と明確な見出しがあります。権威性を示す要素は、スキーママークアップだけではなく、有用なコンテンツに求められる基準に沿ったものです。多言語対応では、英語版の成果にかかわらず、翻訳ページがAI Overviewsに掲載される保証はありません。Search Consoleで生成AI関連のレポートが利用できる場合はそれを使って測定し、従来のインデックス指標とは分けて管理しましょう。確かなことと不確かなことを区別する必要があります。どのような翻訳ワークフローでも、AI Overviewsへの掲載を約束することはできません。

GlotEOが担う役割

初回公開後にロケール別URL、翻訳、サイトマップの整合性が崩れると、Bing向けの最適化はうまくいきません。GlotEOは、用語集の管理、レビューサイクル、クロール可能な言語版の整備といった多言語SEOガバナンスをチームが日々の運用に組み込めるよう支援し、BingとGoogleの両方が安定したロケール別HTMLを確認できるようにします。

複数市場への展開範囲を検討する際は、GlotEOの料金とプランを比較してください。また、戦略的な背景を理解するために、本ガイドと併せて国際SEOと多言語SEOの違いもご覧ください。

参考文献