カテゴリ・属性・写真・投稿・複数店舗管理を含むGBP全体の最適化方針は、[Googleビジネスプロフィール最適化の実践ガイド](https://rebranding.co.jp/media/google-business-profile-optimization/)で整理しています。
Googleビジネスプロフィール（GBP）の情報は、カテゴリだけ、サービスだけ、設備だけを個別に確認しても、店舗全体の不整合を見落とすことがあります。
たとえば、公式サイトでは新サービスを案内しているのにGBPへ反映されていない、同じ業態の店舗なのに一部店舗だけ古い設備情報が残っている、本部の標準情報を一律反映した結果、実際には提供していないサービスが掲載されている、といった状態です。
本記事が扱うのは、カテゴリ・サービス・設備など複数の属性情報を一つの台帳で横断し、店舗実態・公式サイト・GBPの不一致と更新漏れを店舗別に発見する監査です。
カテゴリそのものの選び方は「Googleビジネスプロフィールのカテゴリ選び方｜メイン・追加カテゴリをどう決めるか」、既存カテゴリの維持・変更・追加・削除を判断する監査手順は「Googleビジネスプロフィールのカテゴリ設定を監査する方法｜主カテゴリ・追加カテゴリの選び方と見直し手順」で扱います。
サービス名・説明・価格・導線などの設定方法は「Googleビジネスプロフィールのサービス・商品設定ガイド｜来店導線まで整える方法」に委ねます。本記事では、それらの設定方法を繰り返さず、複数属性をまたいだ整合性確認と店舗横断の差分検知に限定します。
30秒でわかる結論
GBPの属性情報を横断監査するときは、次の5段階で進めます。
- 属性マスターを作り、店舗ごとの正しい状態を定義する
- 実店舗・公式サイト・GBPの3者を同じ項目で照合する
- 店舗横断で差分を並べ、不整合と更新漏れを検知する
- ユーザー影響と誤情報リスクで変更優先度を決める
- 定期監査と変更履歴を残し、同じ不整合の再発を防ぐ
監査の目的は、項目数を増やすことではありません。「この店舗では何が正しいのか」を基準化し、媒体間・店舗間のズレを再現可能な方法で見つけることです。
属性マスターを作る｜カテゴリ・サービス・設備を同じ台帳で管理する
横断監査では、GBPの管理画面を店舗ごとに開いて目視するだけでは不十分です。先に、確認対象を同じ列で比較できる「属性マスター」を作ります。
カテゴリ・サービス・属性は役割が異なります。本記事では設定方法ではなく、監査対象として一つの台帳に並べます。
最低限、次のような列を用意します。
| 管理列 | 記録する内容 | 監査で見ること |
|---|---|---|
| 店舗ID・店舗名 | 一意に識別できる名称 | 店舗の取り違えを防ぐ |
| メインカテゴリ | 現在のGBP設定 | 店舗実態・標準設定との不一致 |
| 追加カテゴリ | 現在の設定を全件 | 他店舗との差、廃止済み情報 |
| 主要サービス | 店舗で実際に提供する内容 | 未反映、終了済み、店舗限定の差 |
| 設備・属性 | 駐車場、Wi-Fi、支払い、バリアフリー等 | 実態との不一致、未設定 |
| 公式サイト | 対応するページや記載内容 | GBPとの矛盾 |
| 現場確認 | 店舗責任者などの確認結果 | Webだけでは判断できない実態 |
| 判定 | 正常・誤り・不足・要確認 | 修正対象の抽出 |
| 変更履歴 | 日付、変更前後、理由、担当 | 再監査時の比較 |
Googleは、カテゴリを中心事業に合うものから可能な限り少なく選び、サービスや設備をカテゴリで表現しないよう案内しています。また、属性には設備や支払い方法などが含まれ、利用できる項目は業種や地域によって異なる場合があります。
そのため、属性マスターでもカテゴリ、サービス、設備・属性を別列にし、違う役割の情報を一つの項目へ混ぜないことが重要です。
「全店標準」と「店舗固有」を分ける
多店舗企業では、すべての店舗に同じ正解を当てはめないようにします。
たとえば、同一ブランドで基本カテゴリや標準サービスは共通でも、駐車場、決済方法、バリアフリー設備、一部店舗限定サービスは店舗ごとに異なることがあります。
属性マスターには次の2種類を分けて持たせます。
- 全店標準：原則として同一業態の全店舗に共通する情報
- 店舗固有：立地、設備、提供体制などによって店舗ごとに異なる情報
この区別がないと、店舗固有の正しい差まで「不整合」と誤判定したり、本部の標準値を誤って全店へ反映したりします。
実店舗・公式サイト・GBPを三者照合する
属性マスターを作ったら、各項目を実店舗・公式サイト・GBPの3者で照合します。
GBPだけを正解として扱わず、実店舗・公式サイト・GBPの3つを並べて差分を確認します。
監査の基準は次の状態です。
実店舗の実態
＝ 公式サイトなどの自社情報
＝ Googleビジネスプロフィール
ただし、3者が違う場合に「公式サイトが正しい」と即断しないでください。公式サイト側の更新が遅れている可能性もあります。
三者照合で確認する順番
- 現場で現在提供・利用できる内容を確認する
- 公式サイト、予約ページ、店舗案内の記載を確認する
- GBPの現在値を確認する
- 3者の差分を属性マスターに記録する
- 根拠が不足する項目は「要確認」にする
たとえば、公式サイトでは「駐車場あり」、GBPでは未設定でも、現地では提携駐車場が終了している場合があります。このケースではGBPへ追加するのではなく、公式サイト側も含めた修正が必要です。
個別設定の良し悪しまで本記事で決めない
横断監査で「カテゴリに差がある」「サービスが未登録」と判明しても、その場で詳細な設定方法まで判断する必要はありません。
- カテゴリの候補選定が必要なら、カテゴリ選び方の記事へ送る
- 既存カテゴリを変更・追加・削除するか判断するなら、カテゴリ監査の記事へ送る
- サービス名、説明、価格、リンク等を設計するなら、サービス・商品設定の記事へ送る
本記事の完了条件は、どの店舗の、どの属性に、どの種類の差分があるかを特定することです。
店舗横断で不整合と更新漏れを検知する
三者照合ができたら、次は店舗を縦に並べて差分を見ます。ここが個別のカテゴリ監査やサービス設定記事と最も異なる部分です。
単店舗では問題が見えなくても、同業態の店舗を横並びにすると異常値が見つかることがあります。
| 店舗 | メインカテゴリ | 主要サービスA | 駐車場 | 支払い方法 | 判定 |
|---|---|---|---|---|---|
| 店舗A | 標準どおり | 提供・登録済み | あり | 最新 | 正常 |
| 店舗B | 標準どおり | 提供中・未登録 | あり | 最新 | 不足 |
| 店舗C | 旧設定 | 提供・登録済み | なし | 旧情報 | 誤り |
| 店舗D | 店舗固有設定 | 非提供 | あり | 要現地確認 | 要確認 |
不整合は3種類に分類する
監査で見つけた差分は、次の3つに分類します。
| 判定 | 状態 | 例 |
|---|---|---|
| 誤り | 現在の実態と明確に違う | 廃止サービスが掲載、利用不可設備が「あり」 |
| 不足 | 実態として存在するがGBPへ未反映 | 提供中サービス、利用可能設備が未設定 |
| 要確認 | 情報源同士が食い違い、正解を確定できない | 公式サイトと店舗担当者の回答が違う |
横断監査では「差があること」と「間違っていること」を分けます。店舗固有の正当な差は修正対象ではありません。
更新漏れは変更イベントから逆引きする
店舗横断の差分確認に加えて、変更イベントからも監査します。
- 新サービスの開始・終了
- 設備の新設・撤去
- 決済端末や支払い方法の変更
- 移転、改装、業態変更
- 公式サイトのサービスページ更新
- 店舗統合やブランド変更
変更イベントがあった店舗だけを抽出し、公式サイトとGBPの反映状況を確認すると、更新漏れを見つけやすくなります。
特に多店舗では、「変更した店舗一覧」と「GBP更新済み店舗一覧」を突き合わせると、担当者の記憶に頼らず監査できます。
変更優先度を決める｜まず誤情報を止める
監査で差分を見つけても、すべてを同時に直す必要はありません。
原則として、不足情報を増やすことより、ユーザーを誤認させる情報を先に止める方が優先です。
| 優先度 | 状態 | 例 | 対応 |
|---|---|---|---|
| A | 実態と明確に違い、来店・問い合わせ判断に影響 | 廃止サービス、利用不可設備、明白な業態不一致 | 根拠確認後に早期是正 |
| B | 情報源間で矛盾し、正解の確認が必要 | 店舗と公式サイトで設備情報が違う | 担当者を決めて確認 |
| C | 実態に存在するが未反映 | 新サービス、追加設備 | 優先度を付けて追加検討 |
| 維持 | 店舗固有の正当な差 | 一部店舗だけ駐車場あり | 変更せず理由を記録 |
カテゴリの変更が必要な場合は、検索結果への影響もあり得るため、本記事内で即時変更せずカテゴリ監査の判断フローへ送ります。Googleも、選択したカテゴリがローカル検索結果のランキングに影響すると案内しています。
一方で、属性を増やせば自動的に順位が上がると考えるのは避けます。Googleはビジネス情報を正確かつ最新に保つことを推奨しており、横断監査でも正確性と実態一致を優先します。
修正前に残す記録
変更対象には、最低限次を残します。
- 店舗ID
- 対象項目
- 現在値
- 正しい値
- 根拠
- 判定
- 優先度
- 承認者または確認担当
- 変更予定日
- 変更後確認日
これにより、次回監査で「なぜ変えたのか」が追える状態になります。
定期監査で更新漏れを再発させない
横断監査は一度実施して終わりではありません。Googleの属性は、業種や地域によって利用できる内容が異なる場合があり、属性名や表示項目が変わることもあります。
また、店舗側のサービスや設備も変化します。
そのため、定期監査とイベント監査を分けます。
定期監査
定期監査では、全店舗の属性マスターとGBP現在値を照合します。
頻度はGoogleが指定するものではないため、店舗数と変更頻度に合わせて社内基準を決めます。
確認するのは、少なくとも次の項目です。
- 前回監査以降に更新された項目
- 同業態店舗の標準値から外れた店舗
- 長期間確認されていない店舗
- 「要確認」のまま期限を過ぎた項目
- 変更履歴がなく現在値の根拠を説明できない項目
イベント監査
店舗やサービスに変更があった場合は、定期日を待たず対象店舗だけ監査します。
重要なのは、変更をGBP担当者へ伝える運用を作ることです。
たとえば新サービス開始時に、Webサイト更新とGBP更新を別々の依頼にすると、一方だけ完了して不整合が残りやすくなります。変更申請の中に「公式サイト」「予約ページ」「GBP」を同じチェック項目として持たせると、更新漏れを減らせます。
監査チェックリスト
- [ ] 属性マスターに店舗IDと店舗名がある
- [ ] カテゴリ・サービス・設備を別列で管理している
- [ ] 全店標準と店舗固有の項目を分けている
- [ ] 実店舗・公式サイト・GBPの3者を照合した
- [ ] 公式サイトだけを正解として扱っていない
- [ ] 店舗横断で標準値との差を確認した
- [ ] 正当な店舗差と誤設定を分けた
- [ ] 差分を「誤り・不足・要確認」に分類した
- [ ] 変更イベントから更新漏れを逆引きした
- [ ] 修正優先度をユーザー影響と誤情報リスクで決めた
- [ ] カテゴリ選定・カテゴリ変更・サービス設定の詳細は専門記事へ委ねた
- [ ] 変更前後の値、根拠、担当者、確認日を記録した
変更後は管理画面とユーザー表示を分けて確認する
GBPで保存できたことと、Google検索・Googleマップでユーザーに意図どおり表示されていることは別々に確認します。
Googleは、属性編集の審査について通常は短時間で完了するものの、場合によっては最大30日かかることがあると案内しています。
修正後は次の順番で確認します。
- 管理画面で保存状態を確認する
- Google検索で対象店舗の表示を確認する
- Googleマップでも確認する
- 属性マスターへ変更後の値と確認日を記録する
- 未反映なら、即座に再編集せず審査状況と経過を確認する
監査結果と変更履歴が同じ台帳に残っていれば、次回は前回値との差分から確認できます。
まとめ
Googleビジネスプロフィールの属性情報を横断監査するときは、カテゴリ、サービス、設備を個別に最適化するのではなく、店舗単位の正しい状態を属性マスターで定義し、実店舗・公式サイト・GBP、さらに店舗間を横断して差分を見ることが重要です。
この記事の役割は、カテゴリの選び方やサービスの書き方を詳しく説明することではありません。
- 属性マスターを作る
- 三者照合する
- 店舗横断で差分を検知する
- 誤り・不足・要確認に分類する
- 修正優先度を付ける
- 定期監査と変更履歴で再発を防ぐ
この流れを標準化すると、担当者ごとの目視確認から抜け出し、複数店舗でも更新漏れと情報の食い違いを継続的に発見しやすくなります。
参考文献・データ元
- Google「Google に掲載するビジネス情報のガイドライン」：カテゴリと事業実態の考え方、正確なビジネス情報の原則に使用。Google公式ガイドライン
- Google「業種を管理する」：カテゴリの役割、編集時の注意、ローカル検索結果への影響確認に使用。Google公式「業種を管理する」
- Google「ビジネスの属性を管理する」：設備・支払い等の属性、編集条件、審査時間の確認に使用。Google公式「ビジネスの属性を管理する」
- Google「ビジネス プロフィールに表示されるサービスを管理する」：サービス項目の提供条件、追加・編集機能の確認に使用。Google公式「サービスを管理する」
- Google for Developers「Add attributes」：利用可能な属性がカテゴリや国・地域によって異なる仕組みの確認に使用。Google Business Profile API「Add attributes」