店名・住所・電話番号(NAP: Name, Address, Phone)が、Googleビジネスプロフィール(GBP)・自社サイト・食べログ・ホットペッパーグルメで少しずつ違う。この記事は、Google の公式ヘルプと構造化データの項目定義から「どこを揃えれば同じ店として扱われるか」を決め、四半期ごとに同じ手順で点検する監査表を作る手順書です。
Google ビジネス プロフィール ヘルプは「ビジネスごとに作成できるビジネス プロフィールは 1 つだけです」とし、「同じビジネスの複数のプロフィールは、ユーザーを誤解させるおそれがあり、Google のポリシーに違反します」「プロフィールが重複と見なされた場合、Google 検索やマップに表示されなくなります」と書いています。
NAPの一貫性とは何を揃えることか:Google公式の定義から決める
重複の判定は「同じビジネスか」で決まり、統合には同一の情報が要る
- 既存の確認済みプロフィール: 同じビジネスについて、Google ですでに確認済みのプロフィールが存在する。
- 同じ住所: 複数のプロフィールに同じ住所が設定されている。
- 異なるサービス: 異なるサービスを提供する 1 つのビジネスに複数のプロフィールが存在する。
一方で、同じ住所でも「名前が異なり、看板の違いがはっきりと確認できる、明確に異なるビジネス」で登録資格があれば、それぞれにプロフィールを作れます。別業態を同じ建物に持つ店は、この条件を先に確かめます。
統合の条件は「統合を成功させるには、プロフィールが同一のビジネスを代表し、同一の情報を含んでいる必要があります」です。監査で揃えるのはこの「同一の情報」です。
LocalBusiness構造化データの項目が「揃える単位」になる
分解の物差しにはGoogle 検索セントラルの LocalBusiness 構造化データの定義を使います。「各ローカル ビジネスの拠点を LocalBusiness タイプとして定義します」とあるとおり、単位は会社ではなく拠点です。
| 揃える項目 | プロパティ | 必須/推奨 | 公式の記述 |
|---|---|---|---|
| 店名 | name | 必須 | ビジネスの名前 |
| 住所 | address | 必須 | PostalAddress として streetAddress・addressLocality・addressRegion・postalCode・addressCountry に分ける |
| 電話番号 | telephone | 推奨 | 顧客からの連絡を受けるメインの電話番号。電話番号には、必ず国コードと市外局番を含めてください |
| URL | url | 推奨 | 特定のビジネス拠点の完全修飾 URL。URL は有効なリンクである必要があります |
| 営業時間 | openingHoursSpecification | 推奨 | ビジネスの営業時間(季節営業などの書式は公式ドキュメントで確認) |
必須・推奨の区別は「コンテンツがリッチリザルトとして表示されるようにするには、必須プロパティを含める必要があります」というリッチリザルトの条件で、この定義の範囲では NAP が一致しているかの判定条件ではありません。「構造化データを使用するコンテンツが必ず検索結果に表示されるとは限りません」ともあります。構造化データの実装手順とガイドラインは本記事の対象外です。
四半期に回すNAP監査の手順
自分でできるMEO対策のチェックリストにある「NAP統一」を、四半期ごとに同じ表で点検する運用に格上げします。
Step 1:掲載先を実名で洗い出し、正本を決める
店の情報が載っている場所を全部書き出し、掲載先ごとに店名・住所・電話番号・URL・営業時間の欄を確認します。
| 掲載先 | 扱い |
|---|---|
| Googleビジネスプロフィール(GBP) | 正本(オーナー確認済みのプロフィール) |
| 自社サイト(店舗ページの表示と構造化データ) | GBP と同一にする |
| 食べログ/ホットペッパーグルメ/Retty | GBP に合わせる |
| その他の予約・ポータルサイト | GBP に合わせる |
Step 2:正本と突き合わせ、差分を「表記ゆれ」と「実体の違い」に分ける
表記ゆれは全角と半角、ビル名の有無、ハイフン位置のような同じ実体を指す差です。GBP では「電話番号は自動的にフォーマットされるため、国コード、かっこ、ハイフンを追加する必要はありません」とあるので、ハイフンの違いは GBP を直す対象になりません。
実体の違いは、旧住所・旧電話番号・旧店名が残っている状態です。移転のあとは「ビジネスが移転した場合は、新しい拠点のビジネス プロフィールを新しく作成しないでください。代わりに、既存のプロフィールを新しい住所に更新してください」が原則で、「ビジネスで異なるサービスを提供している場合でも、サービスごとに個別のビジネス プロフィールを作成しないでください。代わりに、各サービスをビジネス プロフィールに列挙してください」です。
電話番号が複数出てきても、すべてが不一致とは限りません。構造化データでは「ビジネスに複数の部門があり、部門ごとに営業時間や電話番号が異なる場合は、department プロパティを使用してそれぞれの部門の要素をマークアップできます」とされています。監査表では「メインの電話番号」だけを突き合わせ、部門の番号は備考に分けます。
Step 3:直す順番と、GBP側で直すときの注意
重複プロフィールを消す前に確認します。「重複するプロフィールを削除すると、すべてのコンテンツとリンクされた管理者が削除されるため、正しいプロフィールを削除してください」と注意があります。Google マップ上の重複の統合は「すべての統合リクエストは審査の対象となります」で、「2 つのプロフィールを統合すると、クチコミは統合されますが、クチコミへの返信は失われる可能性があります」とも書かれています。
- 掲載先を表に書き出し、前回の表と比べて抜けを確かめる
- GBP の値を正本として確定する
- 掲載先ごとに突き合わせ、差分を「表記ゆれ」と「実体の違い」に分ける
- 実体の違いを GBP、自社サイト、外部の掲載先の順で直す
- 重複は削除か統合かを決め、統合前にクチコミ返信を控える
- 監査日・差分・直した内容を記録し、次の四半期に同じ表を使う

計測用の電話番号とNAPの関係:GBPが持てる番号の枠から考える
電話番号の追加のヘルプには「ビジネスのメインの電話番号に加えて、最大 2 件の電話番号を追加できます。携帯電話番号または固定電話番号を追加できますが、FAX 番号は追加できません」とあります。構造化データの telephone も「顧客からの連絡を受けるメインの電話番号」です。
本記事の運用は、揃える対象をメインの電話番号に限り、計測用の番号は追加の枠に置いてメインには入れない、です。番号を出したくない場合は「ビジネス プロフィールで電話番号を非表示にすることもできます」。
計測用番号が Google マップの順位に影響するかどうかは、電話番号の追加のヘルプにも LocalBusiness 構造化データの定義にも書かれていません(「順位」「ランキング」「計測」「トラッキング」で全文を検索して該当なし)。影響しないと分かっている、という言い方は本記事ではしません。
他人が持っているプロフィール・重複が見つかったときの対処
自分が編集できない GBP が見つかったら、オーナー権限のリクエストのヘルプを使います。「ビジネス プロフィールを検索しても [ビジネス オーナーですか?] または [このビジネスのオーナーですか?] ボタンが表示されない場合は、すでにお客様がオーナーである可能性があります」とあります。
この手順は「実店舗のビジネスまたはハイブリッド ビジネスに対して」のものです。business.google.com/add にアクセスし、ビジネスの名前と住所を入力してリストから選び、[アクセス権限をリクエスト] を選択してフォームを送信します。「そのオーナーは 3 日以内に返信する必要があります」とあり、3 日が経過しても返信がない場合は自分でオーナー申請をするという選択が可能な場合があります。ただし「プロフィールの申請は、常にできるわけではありません」。「ビジネスがすでに Google マップに表示されているが、オーナー確認が完了していない場合は、プロフィールの申請とオーナー確認を行えます」。拒否された場合も「プロフィールの編集を提案することはできます。また、決定に対して再審査を請求することもできます」。「客先に出向いてサービスを提供し、実店舗やオフィスを持たない非店舗型ビジネスのオーナー権限をリクエストするには、Google までお問い合わせください」となり、一括確認済みアカウントは一括アップロード用スプレッドシートを使う方法もあります。取り戻したあとのオーナー確認はオーナー確認の記事にまとめています。
「同じビジネスのビジネス プロフィールが 2 つ以上 Google マップに存在する場合は、Google マップで提案を報告して統合をリクエストしてください」が公式の経路です。別々の店が誤って重複と扱われた場合の再審査は本記事の対象外です。
まとめ:四半期の監査を回す最初の一歩
最初の一歩は、今日 GBP の店名・住所・電話番号・URL・営業時間を書き出して正本を確定することです。DigitalGOAT編集部の目安では、今期分を回した人は、掲載先が管理媒体3つ以上に増えて更新漏れが出たときに、手作業で回し続けるか一括で管理する仕組みに載せるかを判断する段階にいます。