GBPの店舗名とサイトの屋号が違うときの正解｜alternateNameとCIDで名寄せする
GBPの店舗名とサイトの屋号が違うときの正解｜alternateNameとCIDで名寄せする
「Googleビジネスプロフィールに登録している店舗名と、ホームページに出している屋号が違います。揃えた方がいいですか」
先に答えを書きます。まずGoogleビジネスプロフィール（以下GBP）側の名称は触りません。サイトの表示名を正として、GBPの登録名を構造化データの alternateName に入れ、sameAs にGBPのURLを「CID形式」で書く。これで機械側の名寄せは成立します。 名称そのものを変更するかどうかは、その後で検討すれば十分です。
順番をこうする理由は単純です。GBPの店舗名変更には審査が入ります。すぐ反映される保証はなく差し戻されることもあり、その間はどちらの名前で探されても中途半端な状態が続きます。対して alternateName と sameAs はサイト側だけで完結し、当日反映でき、将来名前が揃ったら消すだけです。リスクの小さい方から先に打つ、というだけの話です。
以下、実案件で名称差分を吸収した実装と、多店舗サイトの構造化データ点検で出た穴を土台に、手順と判断基準を書きます。
名前が割れていると、何を損しているのか
不利益は2つです。検索エンジンとAIに「別の事業者」と判定されうること、そして店名で検索する人（指名検索）に対してGBPの枠と自社サイトが揃って出ないこと。効くのは後者です。指名検索は、広告費もポータル手数料もかからない唯一の入口だからです。
弊社が支援している埼玉県の排水管清掃の専門事業者は、GBPの登録名が「◯◯ 排水管高圧洗浄」、サイトの表示名が「排水管高圧洗浄専門店 ◯◯」で、語順が違っていました。この事業者は受注の約7割が、ある作業マッチングのプラットフォーム経由で、支払う手数料は年間で乗用車1台分にあたります。しかも規約上、事業者側から自社サイトへ誘導する行為は禁止されています。
ただし、禁止されているのは「事業者が誘導すること」であって、利用者が自分の意思で店名を検索するのは自由です。つまり店名で検索されたときに自社サイトが確実に出る状態を作ることが、規約に触れずに手数料を圧縮できる唯一の経路でした。名前が割れていると、その入口が弱くなります。
なお、この名称差分はヒアリングシートの回答からは出てきませんでした。GBPの共有用短縮URLを展開し、実データを見て初めて分かっています。申告された店舗名と、GBPに実際に登録されている文字列は、別々に確認してください。 事業者本人も登録時の表記を正確には覚えていないことがあります。
実装1：name と alternateName を分ける
構造化データ（JSON-LD）で、表示名と登録名を分けて持ちます。
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "排水管高圧洗浄専門店 ◯◯",
"alternateName": "◯◯ 排水管高圧洗浄",
"url": "https://example.co.jp/",
"address": {
"@type": "PostalAddress",
"postalCode": "000-0000",
"addressRegion": "◯◯県",
"addressLocality": "◯◯市◯◯区",
"streetAddress": "◯◯1-2-3",
"addressCountry": "JP"
},
"sameAs": [
"https://www.google.com/maps?cid=9656214399546362411",
"https://www.instagram.com/example/"
]
}押さえる点は3つ。
name はサイトの表示名にする。 画面に出ている名前と機械に渡す名前を一致させます。ここをGBP登録名にすると、閲覧者が見ている名前と食い違い、新しいズレを作ります。
alternateName にGBPの登録名を入れる。 「この名前でも同じ事業者です」と明示するのが役割です。屋号・旧社名・略称も同じ扱いで入れられます。
Organization にも同じ alternateName を入れる。 見落としやすい箇所です。会社概要ページだけ Organization を出す構成にしていると、そのページだけ別名の情報が消えます。ページによって主張が変わる状態は避けます。
加えて、2つの名前が同じ値になったときは出力しない条件を書いておきます。
$name = get_option('biz_name'); // サイト表示名
$alt = get_option('biz_name_gbp'); // GBP登録名
$node = ['@type' => 'LocalBusiness', 'name' => $name];
if ($alt !== '' && $alt !== $name) {
$node['alternateName'] = $alt;
}こうしておけば、将来GBP名を揃えたときに同じ文字列が二重に並ぶ状態を自動で回避できます。納品後にコードを触らない事業者ほど、この種の「自然に消える実装」が効きます。
実装2：sameAs にGBPを「CID形式」で入れる
alternateName は「別名がある」という主張にすぎません。それがどのGBPを指すのかは、sameAs で名指しして初めて機械に伝わります。
ここでやってはいけないのが、共有ボタンで出る短縮URL（maps.app.goo.gl/...）をそのまま書くことです。短縮URLは転送に依存しており、仕組みが変われば切れます。構造化データは長期間そのまま置かれるデータなので、寿命の短いURLは書きません。正しいのはCID形式です。
https://www.google.com/maps?cid=9656214399546362411CIDの取り方（手作業で3分）
- GBPの管理画面またはGoogleマップで対象の店舗を開き、共有から短縮URLを取得する
- 短縮URLの転送先を展開する
curl -sIL "https://maps.app.goo.gl/xxxxxxxx" | grep -i "^location:"- 展開後のURLに含まれる
ftid=0x〜:0x〜を探す。コロンの後ろの16進数がCIDです（data=の中に!1s0x〜:0x〜の形で入っている場合もあります。同じくコロンの後ろを使います） - 16進を10進に変換する
python3 -c "print(int('0x8601c3d5e7f90a2b', 16))"
# → 9656214399546362411- 出た10進数を
https://www.google.com/maps?cid=の後ろに付ける - 必ずブラウザで開いて、目的の店舗が表示されることを目視確認する
6を省かないでください。sameAs のURLは、機械が「この2つは同一である」と受け取る根拠になります。間違ったCIDを書けば、名寄せどころか他店と紐づけてしまいます。Instagramなどの公式アカウントも同様で、クエリパラメータを全部落とした正規形にし、開けることを確認してから書きます。
Place IDとCIDを混同しない
同じ「場所の識別子」でも、CIDとPlace IDは別物です。用途が違うため、片方だけ取って後で足りなくなりがちです。
| 識別子 | 形式 | 主な用途 |
|---|---|---|
| CID | 19桁前後の数字 | GoogleマップのURL（sameAs に書くのはこれ） |
| Place ID | ChIJ で始まる文字列 |
Places API、クチコミ投稿用の直リンク |
特に、クチコミ投稿URL（https://search.google.com/local/writereview?placeid=◯◯◯）にはPlace IDが必要で、CIDからは生成できません。クチコミ集めのQRコードを作る予定があるなら、sameAs 用のCIDとは別に、Place IDもGBPの管理画面から取得しておきます。GBPの情報を触るタイミングで両方まとめて控えておけば、後から取得作業をやり直さずに済みます。
揃えるべき表記ゆれ、揃えなくていい表記ゆれ
名前と同じ問題は住所でも起きますが、1文字単位で完全一致させる必要はありません。
揃えるもの
- 郵便番号
- 都道府県（
addressRegion） - 市区町村（
addressLocality） - 町域名
- 電話番号
揃えなくていいもの
- 番地の全角・半角（「１−２−３」と「1-2-3」）
- ハイフンの種類
- ビル名の「3階」と「3F」
前者は検索側で別物として扱われうる粒度、後者は正規化される粒度、という線引きです。GBPが全角番地でサイトが半角番地という差は放置して問題ありません。ここを揃えるためにクライアントへGBPの修正を依頼するのは、手間に対して得るものがありません。
住所で気をつける点が2つあります。
郵便番号は推測しない。 同じ市区内でも町域ごとに番号が違います。日本郵便の町域一覧で対象の町域を引き、周辺の町域も一緒に取って読み違いがないか確認したうえで、GBPの登録住所と突き合わせます。
登記上の住所と、実際の営業拠点は違うことがある。 前述の事業者も、登記住所は関係者の住居で、現場へ出発する実拠点は別の県でした。この違いはNAP（名称・住所・電話）統一の結論を変え、「どのエリアの事業者として語るか」にも直結します。サイトの構成や構造化データを書き始める前に、「実際にどこから現場へ向かうか」を聞いてください。
多店舗サイトで追加で点検する3項目
弊社は愛知県内を中心に25店舗を展開する白髪染め専門サロンのフランチャイズで全店舗サイトを運用しており、全店の構造化データを点検したときに出た穴が、そのまま横展開のチェック項目になりました。
1. addressLocality（市区町村）が全店で欠落していた。 住所を1本の文字列として持っていると起きます。postalCode / addressRegion / addressLocality / streetAddress の4項目に分けて保持し、出力時に組み立てる形にします。
2. addressRegion（都道府県）が1店だけ誤っていた。 隣県にある店舗に、本部所在地の県名が入っていました。テンプレートの初期値がそのまま残る典型パターンです。目視で全店を確認するのは現実的でないので、住所文字列に含まれる県名を優先するロジックで機械的に是正するのが確実です。
3. areaServed（商圏）が無かった。 どの市区を対象にした店舗かを機械可読で示す項目。「◯◯市 白髪染め」のように地域名で探す人に対し、そこが対象エリアだと明示できるのはこの項目になります。
このほか hasMap（マップURL）も入れられますが、全店分をすぐ揃えられないことが多い項目です（このときは25店中5店しか確定できませんでした）。揃わない項目は空のまま出力せず、値がある店だけ出力して、値が入った時点で自動的に現れる実装にしておきます。
出力を直しても、生成元を直さないと戻る
多店舗で最も起きやすい事故がこれです。公開されているHTMLだけを修正し、そのHTMLを生成している設定ファイルを直さないと、次のデプロイで誤りが復活します。 前述の都道府県の誤りも、公開側を是正した時点では生成元の店舗設定が未修正で、再ビルドすれば元に戻る状態でした。修正は「公開HTML」「生成スクリプト」「元データ（店舗マスタ）」の3層があると考え、どの層まで直したかを記録してから作業を終えるのが安全です。
もう1点、多店舗には前提があります。GBP側そのものが重複していることがあるという点です。同一のPlace IDに対して名称違いのロケーションが3件ぶら下がっている状態を、実際に確認しています。この状態でサイト側から片方だけを sameAs で指しても効果は薄くなります。ロケーション一覧を取得できる立場なら、Place IDで重複を検出し、正規のロケーションを1件決めてからサイト側の実装に入ってください。
プラグインとの二重出力を避ける
構造化データを自前で書くなら、SEOプラグイン側のschema出力は必ず止めます。 両方から LocalBusiness が出ると、内容の違う同じ型のノードが1ページに2つ並び、どちらが正なのか機械には判断できません。設定でOFFにしても更新で初期値に戻ることがあるため、自前で持つ方針なら最初からプラグインを入れない選択も有効です。
そのうえで、JSON-LDを出力するファイルを1つに限定します。 直近案件ではテーマ内の1ファイルに集約し、他から出力されていないことをgrepで実測しました。「どこかで出ているかもしれない」状態だと、二重出力に気づけません。
直した後の確認手順
- 対象ページのHTMLからJSON-LDを取り出し、JSONとして壊れていないか確認する
- 1ページに同じ型のノードが2つ出ていないか確認する
name/alternateName/sameAsが意図した値になっているか確認するsameAsのURLを実際に開き、目的のGBPが表示されるか目視で確認する- Schema Markup Validatorとリッチリザルトテストに通す
5について1つ注意があります。ValidatorもリッチリザルトテストもURLを1ページずつしか通せません。 10ページを超えるサイトでは、貼って確認する途中でエラーを見つけ、直してまた貼り直す手戻りが起きやすくなります。
そこで、1〜4を自前のスクリプトで先に潰してから、最後の確認としてValidatorに通す手順を推奨します。弊社の直近案件では13ページ分のJSON-LDを一括検査するスクリプトを用意し、貼る前にエラー0を確認してから公開作業に入りました。公開後の更新でschemaが壊れたときの検知にも、そのまま使えます。
まとめ
- 最初にやるのは名称変更ではなく構造化データでの吸収。
name＝サイト表示名、alternateName＝GBP登録名、sameAs＝GBPのCID形式URL alternateNameはLocalBusinessとOrganizationの両方に入れ、同値なら出力しない条件も書いておく- 短縮URLをschemaに書かない。CIDに変換し、開いて目視確認する
- Place IDはCIDと別物。クチコミ投稿URLにはPlace IDが必要なので同時に控えておく
- 住所は郵便番号・都道府県・市区町村・町域まで揃える。番地の全半角は揃えなくてよい
- 多店舗は
addressLocality/addressRegion/areaServedを点検し、生成元まで直す
名前を揃えるかどうかは、見た目の整合の話ではありません。店名で検索した人に自社サイトが確実に出るかどうかの話です。ポータルへの依存を減らしたい事業者ほど、この作業の利回りは高くなります。審査を伴うGBPの名称変更に手を出す前に、サイト側だけで完結する alternateName と sameAs から着手してください。