メインコンテンツにスキップ

自社サイト×GBP連動が決め手になる時代——2026年Googleビジネスプロフィール評価軸の変化を読み解く

自社サイト×GBP連動が決め手になる時代——2026年Googleビジネスプロフィール評価軸の変化を読み解く

「Googleビジネスプロフィール(GBP)さえちゃんとしていれば、公式サイトは無くてもいい」——2010年代後半に広まったこの常識が、2026年に入って静かに崩れている。hanjo-guide.jpが2026年4月にまとめた整理によれば、GoogleはGBPの評価において「登録されている自社サイトの存在・品質・GBP...

「Googleビジネスプロフィール(GBP)さえちゃんとしていれば、公式サイトは無くてもいい」——2010年代後半に広まったこの常識が、2026年に入って静かに崩れている。hanjo-guide.jpが2026年4月にまとめた整理によれば、GoogleはGBPの評価において「登録されている自社サイトの存在・品質・GBP情報との関連性」を新たに重く扱い始めた。食べログ・ホットペッパーを公式サイト代わりにしてきた飲食店が、いまGBP順位で目に見えて不利になり始めている。先日書いたLLMO×MEOの二層設計と地続きの話で、AIにもGoogleにも「自社ドメインが情報の正本」だと示せるかどうかが、これからの集客の前提条件になる。

📌 表面と深層

レイヤー内容
📰 表面GBPの評価アルゴリズム調整。自社サイトとの整合性が評価軸に追加
🔍 深層Googleは「店の正本情報がどこにあるか」を判定したがっている。食べログのページではその役割を担いきれない
⚠️ 影響食べログ・ホットペッパーをHPリンクに登録している店は、GBP順位で相対的に不利
🛠️ 打ち手自社ドメイン取得 → Restaurant/FAQPage の JSON-LD → GBPと営業時間・住所・電話を完全一致
🔗 関連4/29のLLMO×MEO二層設計と接続。AIにもGoogleにも「正本」を見せる

hanjo-guide.jpの整理が示した評価軸の動き

2026年4月、繁盛ガイド(hanjo-guide.jp)が公表したMEO総括記事で、GBP評価軸の変化が業界向けに整理された。

変化の中身は地味だが構造的に深い。GBPの順位を決める要素として従来から言われてきた「関連性・距離・知名度」のうち、関連性の評価方法に「登録された自社サイトとGBP情報の整合性」が明確に組み込まれた。サイトのドメインが食べログやホットペッパー配下のページではなく、自店独自ドメインであるか。そのサイト内に店名・住所・電話・営業時間が正しく記述されているか。サイトに構造化データが入っているか。これらがGBPの「関連性」スコアに乗ってきている、という整理である。

この変化を「Googleが意地悪になった」と読むのは表層的だ。本質は、Googleが「店の情報の正本(source of truth)はどこにあるべきか」を判定したがっている、という意思の表れである。

食べログのページは「正本」になれない構造的理由

食べログやホットペッパーは集客プラットフォームとしては優秀だが、Googleから見ると「店の正本」の役割を担えない構造を持っている。

第一に、ドメインが店のものではない。tabelog.comやhotpepper.jpのサブパスに置かれた店舗ページは、Googleから見れば「食べログが書いている店の紹介」であって「店自身が公開している情報」ではない。第二に、編集主体が店ではない。価格や写真は店が更新できても、ページの構造・テンプレート・スキーマは食べログ側が決める。第三に、情報の更新頻度・正確性を店が完全には管理できない。営業時間を変えても食べログ側の反映が遅れる、というのは現場ではよくある話だ。

Googleが「関連性」を評価する際、この三つの構造的限界は無視できない。GBPに登録されているHPが食べログのページだった場合、Googleはそれを「店の周辺情報の一つ」としてしか扱えない。一方で自社ドメインのサイトを登録していれば、それを「店が自分で発信している正本」として高く評価できる。

AI引用とGBP評価が同じ方向に動いている

4月29日に書いたLLMO×MEOの二層設計と、今回のGBP評価軸変化は、まったく同じ方向を指している。

LLMO層では、ChatGPTやPerplexityが「新宿の個室和食」と聞かれて答えを生成する瞬間、AIは食べログ・Retty・ホットペッパーの記述だけでなく、自店の公式サイトを参照しに行く。公式サイトに整理された情報があるかどうかが、AIに引用されるかを左右する。

MEO層でも、いまGoogleは同じ判断をしようとしている。AIもGoogleも、「店が自分のドメインで体系的に情報を発信しているか」を品質シグナルとして使い始めた。両方の評価エンジンが同じ方向に動いているのは偶然ではない。AIとGoogleはどちらも「誰がこの店の情報を保証しているのか」を問うている。掲載媒体が保証する情報よりも、店自身が自社ドメインで保証する情報を、より強く採用する設計に向かっている。

GBPで有利になるサイトの条件

「自社ドメインがあればよい」だけでは足りない。Googleと相性のいいサイト構造を備えている必要がある。

まず、Restaurant の JSON-LD が入っていること。schema.org/Restaurant に従って、店名・住所・電話・営業時間・cuisine・priceRange・受付予約可否を構造化データで記述する。これがGBPの登録情報と一字一句一致していると、Googleは「この店の正本はここだ」と判定しやすくなる。

次に、FAQPage の JSON-LD。「個室はありますか」「アレルギー対応はできますか」「子連れは大丈夫ですか」といった想定質問を、見出しとFAQPage構造化データで二重に置く。これは前述のとおりLLMOにも効くため、一回の実装で二層に効果が及ぶ。

三つ目は、メニューのHTML構造化。PDFメニューは事実上GoogleにもAIにも見えない。メニュー名・価格・カテゴリ・アレルゲンをHTMLで構造化し、可能ならMenu/MenuItemスキーマも入れる。

四つ目が、GBPと公式サイトの情報整合性。営業時間が一秒でもズレていると、Googleはどちらが正しいか判断できず関連性スコアを下げる。月次でGBP・公式・食べログ・ホットペッパー・Rettyの五箇所を突き合わせて差分を解消する運用が必須になる。

食べログ依存のリスクが顕在化する

「食べログのページがあるからHPは要らない」という運用は、これからGBP順位の足を引っ張る。

具体的には、GBPのウェブサイト欄に食べログのURLしか入れていない店は、自社ドメインを入れている同地域の競合店に対して関連性スコアで劣後する可能性が高くなる。掲載料を払って食べログ内順位を上げても、その食べログ自体がGBPの正本になれない以上、Google検索でユーザーが店名を叩いた時の見え方は不利になる。

逆に、自社ドメインを取って最低限の情報を整備すれば、それだけで競合と差がつく局面にいま入りつつある。情報設計は派手な投資ではないが、これからの12ヶ月で集客の前提条件として急速に重要度を増す領域だ。

飲食店オーナーが今期やるべきこと

順番が大事だ。ドメインだけ取っても、整合性が取れていなければ意味がない。

第一歩は自社ドメインの取得と、最低限のサイト立ち上げ。トップページ・店舗情報・メニュー・予約・お問い合わせの5ページで十分始められる。第二歩は店舗情報ページに Restaurant の JSON-LD を入れ、GBPと一字一句揃える。第三歩はFAQページの整備とFAQPageのJSON-LD。第四歩はメニューのHTML構造化。第五歩はGBPと食べログ・ホットペッパー・Retty・公式サイトの情報整合性月次チェック。

このうち最初の三歩は、外部委託しても20〜30万円の範囲で実装できる。年間数百万円の掲載料に比べれば桁違いに安い投資で、AIとGoogleの両方に「自店の正本はここだ」と示せるようになる。

正本を持つ店、持たない店

2010年代の「GBPだけで戦える」時代は、Googleが店の情報をクロスチェックする手段を持っていなかった頃の話だ。生成AIが普及し、Googleがアルゴリズムを更新し続けるなかで、いま起きているのは「店自身が自分の情報を保証しているか」を見る評価軸の追加である。

この問いに対して、自社ドメインを持ち、構造化データを整え、GBPと整合した情報を発信している店だけが、Yes と答えられる。食べログとホットペッパーに依存してきた店は、「他社が代わりに保証しています」と答えるしかなく、その答えはこれからのアルゴリズムには通じにくくなる。導線の入口が変わる時、ルールも変わる。今期の宿題は、自店のための正本を作ることだ。

参考資料

  • 繁盛ガイド — MEO対策総括(2026年4月)
  • schema.org — Restaurant
  • schema.org — FAQPage
  • MenuMenu — AIに先に聞かれる飲食店になる:LLMO×MEO二層設計(2026/4/29)
メニューメニュー
サービス料金プランブログ
ホーム/ブログ/自社サイト×GBP連動が決め手になる時代——2026年Googleビジネスプロフィール評価軸の変化を読み解く
MEO対策

自社サイト×GBP連動が決め手になる時代——2026年Googleビジネスプロフィール評価軸の変化を読み解く

2026年4月30日MenuMenu Team7分で読めます
自社サイト×GBP連動が決め手になる時代——2026年Googleビジネスプロフィール評価軸の変化を読み解く

「Googleビジネスプロフィール(GBP)さえちゃんとしていれば、公式サイトは無くてもいい」——2010年代後半に広まったこの常識が、2026年に入って静かに崩れている。hanjo-guide.jpが2026年4月にまとめた整理によれば、GoogleはGBPの評価において「登録されている自社サイトの存在・品質・GBP情報との関連性」を新たに重く扱い始めた。食べログ・ホットペッパーを公式サイト代わりにしてきた飲食店が、いまGBP順位で目に見えて不利になり始めている。先日書いたLLMO×MEOの二層設計と地続きの話で、AIにもGoogleにも「自社ドメインが情報の正本」だと示せるかどうかが、これからの集客の前提条件になる。

📌 表面と深層

レイヤー内容
📰 表面GBPの評価アルゴリズム調整。自社サイトとの整合性が評価軸に追加
🔍 深層Googleは「店の正本情報がどこにあるか」を判定したがっている。食べログのページではその役割を担いきれない
⚠️ 影響食べログ・ホットペッパーをHPリンクに登録している店は、GBP順位で相対的に不利
🛠️ 打ち手自社ドメイン取得 → Restaurant/FAQPage の JSON-LD → GBPと営業時間・住所・電話を完全一致
🔗 関連4/29のLLMO×MEO二層設計と接続。AIにもGoogleにも「正本」を見せる

hanjo-guide.jpの整理が示した評価軸の動き

2026年4月、繁盛ガイド(hanjo-guide.jp)が公表したMEO総括記事で、GBP評価軸の変化が業界向けに整理された。

変化の中身は地味だが構造的に深い。GBPの順位を決める要素として従来から言われてきた「関連性・距離・知名度」のうち、関連性の評価方法に「登録された自社サイトとGBP情報の整合性」が明確に組み込まれた。サイトのドメインが食べログやホットペッパー配下のページではなく、自店独自ドメインであるか。そのサイト内に店名・住所・電話・営業時間が正しく記述されているか。サイトに構造化データが入っているか。これらがGBPの「関連性」スコアに乗ってきている、という整理である。

この変化を「Googleが意地悪になった」と読むのは表層的だ。本質は、Googleが「店の情報の正本(source of truth)はどこにあるべきか」を判定したがっている、という意思の表れである。

食べログのページは「正本」になれない構造的理由

食べログやホットペッパーは集客プラットフォームとしては優秀だが、Googleから見ると「店の正本」の役割を担えない構造を持っている。

第一に、ドメインが店のものではない。tabelog.comやhotpepper.jpのサブパスに置かれた店舗ページは、Googleから見れば「食べログが書いている店の紹介」であって「店自身が公開している情報」ではない。第二に、編集主体が店ではない。価格や写真は店が更新できても、ページの構造・テンプレート・スキーマは食べログ側が決める。第三に、情報の更新頻度・正確性を店が完全には管理できない。営業時間を変えても食べログ側の反映が遅れる、というのは現場ではよくある話だ。

Googleが「関連性」を評価する際、この三つの構造的限界は無視できない。GBPに登録されているHPが食べログのページだった場合、Googleはそれを「店の周辺情報の一つ」としてしか扱えない。一方で自社ドメインのサイトを登録していれば、それを「店が自分で発信している正本」として高く評価できる。

AI引用とGBP評価が同じ方向に動いている

4月29日に書いたLLMO×MEOの二層設計と、今回のGBP評価軸変化は、まったく同じ方向を指している。

LLMO層では、ChatGPTやPerplexityが「新宿の個室和食」と聞かれて答えを生成する瞬間、AIは食べログ・Retty・ホットペッパーの記述だけでなく、自店の公式サイトを参照しに行く。公式サイトに整理された情報があるかどうかが、AIに引用されるかを左右する。

MEO層でも、いまGoogleは同じ判断をしようとしている。AIもGoogleも、「店が自分のドメインで体系的に情報を発信しているか」を品質シグナルとして使い始めた。両方の評価エンジンが同じ方向に動いているのは偶然ではない。AIとGoogleはどちらも「誰がこの店の情報を保証しているのか」を問うている。掲載媒体が保証する情報よりも、店自身が自社ドメインで保証する情報を、より強く採用する設計に向かっている。

GBPで有利になるサイトの条件

「自社ドメインがあればよい」だけでは足りない。Googleと相性のいいサイト構造を備えている必要がある。

まず、Restaurant の JSON-LD が入っていること。schema.org/Restaurant に従って、店名・住所・電話・営業時間・cuisine・priceRange・受付予約可否を構造化データで記述する。これがGBPの登録情報と一字一句一致していると、Googleは「この店の正本はここだ」と判定しやすくなる。

次に、FAQPage の JSON-LD。「個室はありますか」「アレルギー対応はできますか」「子連れは大丈夫ですか」といった想定質問を、見出しとFAQPage構造化データで二重に置く。これは前述のとおりLLMOにも効くため、一回の実装で二層に効果が及ぶ。

三つ目は、メニューのHTML構造化。PDFメニューは事実上GoogleにもAIにも見えない。メニュー名・価格・カテゴリ・アレルゲンをHTMLで構造化し、可能ならMenu/MenuItemスキーマも入れる。

四つ目が、GBPと公式サイトの情報整合性。営業時間が一秒でもズレていると、Googleはどちらが正しいか判断できず関連性スコアを下げる。月次でGBP・公式・食べログ・ホットペッパー・Rettyの五箇所を突き合わせて差分を解消する運用が必須になる。

食べログ依存のリスクが顕在化する

「食べログのページがあるからHPは要らない」という運用は、これからGBP順位の足を引っ張る。

具体的には、GBPのウェブサイト欄に食べログのURLしか入れていない店は、自社ドメインを入れている同地域の競合店に対して関連性スコアで劣後する可能性が高くなる。掲載料を払って食べログ内順位を上げても、その食べログ自体がGBPの正本になれない以上、Google検索でユーザーが店名を叩いた時の見え方は不利になる。

逆に、自社ドメインを取って最低限の情報を整備すれば、それだけで競合と差がつく局面にいま入りつつある。情報設計は派手な投資ではないが、これからの12ヶ月で集客の前提条件として急速に重要度を増す領域だ。

飲食店オーナーが今期やるべきこと

順番が大事だ。ドメインだけ取っても、整合性が取れていなければ意味がない。

第一歩は自社ドメインの取得と、最低限のサイト立ち上げ。トップページ・店舗情報・メニュー・予約・お問い合わせの5ページで十分始められる。第二歩は店舗情報ページに Restaurant の JSON-LD を入れ、GBPと一字一句揃える。第三歩はFAQページの整備とFAQPageのJSON-LD。第四歩はメニューのHTML構造化。第五歩はGBPと食べログ・ホットペッパー・Retty・公式サイトの情報整合性月次チェック。

このうち最初の三歩は、外部委託しても20〜30万円の範囲で実装できる。年間数百万円の掲載料に比べれば桁違いに安い投資で、AIとGoogleの両方に「自店の正本はここだ」と示せるようになる。

正本を持つ店、持たない店

2010年代の「GBPだけで戦える」時代は、Googleが店の情報をクロスチェックする手段を持っていなかった頃の話だ。生成AIが普及し、Googleがアルゴリズムを更新し続けるなかで、いま起きているのは「店自身が自分の情報を保証しているか」を見る評価軸の追加である。

この問いに対して、自社ドメインを持ち、構造化データを整え、GBPと整合した情報を発信している店だけが、Yes と答えられる。食べログとホットペッパーに依存してきた店は、「他社が代わりに保証しています」と答えるしかなく、その答えはこれからのアルゴリズムには通じにくくなる。導線の入口が変わる時、ルールも変わる。今期の宿題は、自店のための正本を作ることだ。

参考資料

  • 繁盛ガイド — MEO対策総括(2026年4月)
  • schema.org — Restaurant
  • schema.org — FAQPage
  • MenuMenu — AIに先に聞かれる飲食店になる:LLMO×MEO二層設計(2026/4/29)
#MEO対策#GBP#Googleビジネスプロフィール#自社サイト#構造化データ#FAQPage#Restaurant#飲食店DX
MenuMenu

MenuMenu Team

観光業界のDX推進とAIソリューションを提供するMenuMenuのチームブログです。

共有

インバウンド集客、始めてみませんか?

MEO対策・AI検索最適化・多言語メニューで、外国人観光客に「見つかるお店」へ。
まずは無料診断で、お店の現状をチェックしましょう。

無料診断を受ける料金プランを見る
ブログ一覧に戻る
メニューメニュー

多言語対応デジタルメニューシステム

[email protected]070-3198-5799平日 10:00-18:00

Copyright © 2026 MenuMenu Co., Ltd. All rights reserved.

友だち追加
プライバシーポリシー利用規約