店舗サイトに住所や営業時間を書いていても、構造化データには本店の住所が残り、別店舗の電話番号が混ざっている。多店舗サイトでは、画面に見える店舗情報と、検索エンジンへ伝える情報が別々に更新されると、このようなずれが起きます。
LocalBusiness構造化データは、店舗ページの内容を機械が理解しやすい形で伝える記述です。最初から全店へ入れるのではなく、1店舗のページで「画面に見える情報 → 構造化データ → テスト結果」の順にそろえてから、共通テンプレートへ広げます。
先に結論 店舗ごとに固有のページURLを決め、ページ上の店舗名・住所・電話・営業時間を正します。その内容だけをJSON-LDへ入れ、テスト後も実ページと一緒に更新できる仕組みにすることが、多店舗運用の基本です。
まず「その店舗のページ」を1本決める
構造化データは、記述したページの内容を説明するものです。全店舗を一覧にしたページへ、各店の詳しい住所や営業時間を一つの店舗として詰め込むより、まず店舗ごとの詳細ページを用意します。
駅前店を扱うページなら、画面上で次の情報を読める状態にします。
- 正式な店舗名
- 郵便番号、都道府県、市区町村、番地
- お客様が問い合わせに使う電話番号
- 通常の営業時間と定休日
- その店舗へ来店・予約・問い合わせるための案内
- そのページ自身の正規URL
店舗情報を画像の中だけに載せず、本文の文字でも示します。Googleの構造化データ一般ガイドラインは、読者に見えない内容や、ページの主題を正しく表さない内容をマークアップしないよう案内しています。
入れる項目を店舗台帳と対応させる
GoogleのLocalBusiness公式資料では、nameとaddressが必須項目です。telephone、店舗固有のurl、openingHoursSpecificationなどは推奨項目として示されています。
多店舗では、コードを書く前に「どの台帳の値を使うか」を決めます。
| 店舗ページの項目 | 決めておくこと |
|---|---|
| 店舗名 | 看板・公式サイト・ビジネスプロフィールで使う正式名 |
| 住所 | 郵便番号から番地・建物名までの店舗別データ |
| 電話 | お客様向けの主な問い合わせ先 |
| 営業時間 | 通常営業と期間限定の変更を分けた更新元 |
| URL | その店舗の詳細ページの完全なHTTPS URL |
「店舗ページの画面はCMS、本部台帳はスプレッドシート、構造化データは制作会社のテンプレート」という分担でも構いません。ただし、同じ項目を誰がどこで直すかを決めないと、次の改定で再び食い違います。
1店舗分のJSON-LDを作る
GoogleはJSON-LD、Microdata、RDFaをサポートし、多くの場合は実装・保守しやすいJSON-LDを推奨しています。CMSやサイト制作環境によって編集方法が異なるため、コードの設置は制作会社またはサイト担当者へ依頼してください。
以下は、架空の「青空ベーカリー駅前店」を使った説明用の例です。実在店舗のデータではなく、そのまま公開するものでもありません。ここではJSON-LD本体だけを示しており、設置用HTML全体ではありません。公開ページでは、制作環境に合わせてtype="application/ld+json"のscript要素へ入れます。
{
"@context": "https://schema.org",
"@type": "Bakery",
"name": "青空ベーカリー駅前店",
"url": "https://example.jp/stores/ekimae/",
"telephone": "+81-3-1234-5678",
"address": {
"@type": "PostalAddress",
"postalCode": "100-0000",
"addressRegion": "東京都",
"addressLocality": "サンプル区",
"streetAddress": "青空1-2-3",
"addressCountry": "JP"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"opens": "09:00",
"closes": "18:00"
}
]
}
業種は、該当する最も具体的なLocalBusinessのサブタイプを選びます。飲食店ならRestaurant、理美容なら業態に合う型など、実際のページ内容と一致する型を制作担当者と確認します。複数業種を扱う場合の配列や、店舗内の部門ごとに電話・営業時間が異なる場合のdepartmentも公式資料に例がありますが、違いのない部門を見栄えのために増やす必要はありません。
営業時間は曜日ごとの通常時間を記述できます。日付を区切った休業や季節営業時間にはvalidFromとvalidThroughを使う例も示されています。画面上の年末年始案内だけを直し、構造化データが通常営業のままにならないよう、同じ更新作業に含めます。
多店舗テンプレートへ広げる前に3点を照合する
ステップ1: 画面上の店舗情報と見比べる
店舗名、住所、電話、営業時間、URLを一項目ずつ読み、JSON-LDの値と一致するか確認します。
ステップ2: 構造化データを2種類のテストで確認する
リッチリザルト テストでGoogle検索向けの対象と重大なエラーを、Schema Markup ValidatorでSchema.orgとしての記述を確認します。
ステップ3: 公開した実URLをURL検査で確認する
テスト用コードではなく公開後の店舗ページをURL検査し、Googleが取得できるか、正規URLはどれかを確認します。
Googleの構造化データ検査案内は、リッチリザルト テストとSchema Markup Validatorの役割を分けています。テストで「有効」と出ても、実ページがnoindexだったり、Googlebotから取得できなかったりすれば公開後の確認は終わりません。
一方、警告は推奨項目が足りない場合にも表示されます。警告を消すために、ページにないメニュー、画像、評価、価格帯などを推測で追加しないでください。まず重大なエラーを直し、推奨項目は店舗が確認でき、画面上の内容と整合するものから追加します。
全店展開で起きやすい4つの失敗を防ぐ
本店の値を全ページへ固定しない
テンプレートの初期値に本店の住所や電話を入れたままにすると、駅前店ページにも本店情報が出ます。店舗IDから店舗別データを取得できなかった場合は、誤った初期値を表示するより、公開前のエラーとして止める設計を制作担当者へ相談します。
ページURLをトップページへそろえない
urlは、その店舗固有の完全なURLを指定する推奨項目です。全店でトップページを指定すると、どの店舗ページを説明しているか分かりにくくなります。URLの末尾、HTTP／HTTPS、wwwの有無まで正規URLと合わせます。
口コミの星を自己判断で追加しない
公式資料のaggregateRatingとreviewは、他のローカルビジネスについての口コミを収集するサイト向けに推奨されています。自店が管理するHPへ自店のGoogle口コミを載せれば星付き表示の対象になる、という意味ではありません。詳しい条件はGoogle口コミを店舗HPに載せると検索結果にも星が出る？で整理しています。
ビジネスプロフィールの更新と混同しない
サイトの構造化データを直すことと、Googleビジネスプロフィールの編集は別の作業です。店舗名、住所、電話、営業時間を変更した日は、サイト本文、構造化データ、ビジネスプロフィール、予約ページを同じ店舗事実へそろえます。
構造化データの修正だけで、ビジネスプロフィールが指定どおり更新されるわけではありません。 Google側で情報変更が見つかった場合の確認は、Googleビジネスプロフィールの情報が変更されたときの進め方も参照してください。
更新を「公開後の保守」まで設計する
全店へ広げるときは、店舗ごとに次の確認メモを残します。
- 店舗ページURLと店舗ID
- ページ上の店舗名・住所・電話・営業時間
- 構造化データの生成元
- リッチリザルト テストの確認日と重大なエラー
- URL検査で確認した正規URLと取得状態
- 次に営業時間や住所が変わるときの担当者
Googleは、構造化データを正しく設定しても検索結果で特別な表示が出るとは保証していません。構造化データは順位を約束するためではなく、ページに書いた店舗情報の意味を明確に伝え、サイト内の食い違いを減らすために整えます。
公式資料確認日：2026年10月28日。構造化データの対象仕様や検索結果の表示は更新されることがあります。実装時はGoogle Search Centralの現行資料と、公開中の実ページを確認してください。
