店舗サイトの構造化データの作り方。LocalBusinessスキーマ実装入門

店舗サイトの構造化データは、schema.orgのLocalBusinessスキーマをJSON-LD形式で記述するのが標準です。店名・住所・電話番号をGoogleビジネスプロフィールと同じ表記で書くことが最大のポイントです。

構造化データとは何か？

構造化データとは、検索エンジンやAIがページの内容を正確に理解できる形式で、ページ内の情報を記述するマークアップです。語彙はschema.org、記述形式はJSON-LDが現在の標準です。

人間はページを見れば、どれが店名でどれが営業時間か判断できます。しかし検索エンジンやAIにとって、HTMLはただの文字の並びです。構造化データは「この文字列は店名」「この数字は電話番号」と、機械が読める形で意味のラベルを付ける仕組みです。

schema.orgとは、GoogleやMicrosoftなどが共同で策定した構造化データの語彙集です。「店名はname」「住所はaddress」のように、使う項目名が定義されています。JSON-LDとは、その内容をHTML内のscriptタグにJSON形式で書く記述方式です。Googleが公式に推奨しており、ページの見た目には一切影響しません。

なぜ店舗に構造化データが必要なのか？

検索結果でのリッチリザルト表示につながるほか、AI OverviewsなどのAI検索が店舗情報を正確に読み取る材料になるためです。Googleビジネスプロフィールとの情報照合の手がかりにもなります。

リッチリザルトとは、通常のリンクに評価の星や営業時間などが追加表示される、強化された検索結果です。表示面積が増えるためクリック率が上がりやすく、競合との見た目の差になります。

さらに2025年以降は、AI Overviews（Google検索の生成AI回答枠）やChatGPTが店を推薦する時代です。AIはWeb上の情報を読み取って回答を作ります。そのため、構造化データはAIに向けた正確な自己紹介文として機能します。マークアップのないページは、誤読や引用漏れのリスクが高まります。

もう1つの役割が、Googleビジネスプロフィール（店舗情報をGoogleに登録する無料ツール。以下GBP）との照合です。GoogleはGBP・公式サイト・他媒体の情報を突き合わせ、店舗情報の信頼度を判断しています。サイト側に構造化データがあると、この照合が確実になります。MEOの土台である情報の一貫性も強化されます。

LocalBusinessスキーマには何を書くのか？

最低限、店名（name）・住所（address）・電話番号（telephone）の3点を記述します。営業時間・位置情報・価格帯まで書くと、店舗ページとして十分な情報量になります。

LocalBusinessとは、schema.orgが実店舗ビジネス用に定めたタイプです。業種が決まっている場合は、CafeOrCoffeeShopやHairSalonなど、より具体的なサブタイプを使うと正確に伝わります。

JSON-LDの記述例（架空のカフェ）

次のコードを、店舗情報を掲載しているページのhead内に貼り付けます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "CafeOrCoffeeShop",
  "name": "喫茶ひだまり",
  "url": "https://example.com/",
  "image": "https://example.com/images/storefront.jpg",
  "telephone": "+81-3-1234-5678",
  "priceRange": "¥1,000～¥1,999",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "154-0001",
    "addressRegion": "東京都",
    "addressLocality": "世田谷区",
    "streetAddress": "池尻1-2-3 ひだまりビル1F",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.6504,
    "longitude": 139.6852
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday", "Sunday"],
      "opens": "10:00",
      "closes": "18:00"
    }
  ],
  "sameAs": ["https://www.instagram.com/hidamari_cafe/"]
}
</script>

住所はaddressの中で、郵便番号・都道府県・市区町村・番地に分けて書きます。openingHoursSpecificationは曜日ごとの営業時間です。opensとclosesは24時間表記で記述します。geoは緯度・経度で、Googleマップ上で店舗の地点を右クリックすると取得できます。priceRangeはおおよその価格帯です。

注意点は、1つの店舗ページに1つのスキーマを対応させることです。記述する値は、必ずページに実際に表示されている情報と一致させます。

実装後の確認はどうするのか？

Googleの「リッチリザルトテスト」にページのURLを入力し、エラーがないことを確認します。公開後はSearch Consoleのレポートで継続的に検証します。

リッチリザルトテストで検証する

リッチリザルトテストとは、構造化データが正しく書けているかを判定するGoogleの無料ツールです。公開前のコードは「コード」タブに貼り付けて検証できます。結果に「エラー」が出た場合は、必須項目の不足や文法ミスです。必ず修正してから公開します。「警告」は推奨項目の不足を示すもので、可能な範囲で埋めれば十分です。

Search Consoleで継続監視する

Search Consoleとは、検索での表示状況を確認できるGoogleの無料ツールです。ページがインデックスされると、構造化データの検出状況やエラーがレポートに表示されます。実装直後だけでなく、月1回程度の定期確認を習慣にすると更新漏れに早く気づけます。

よくある実装ミスとは？

最も多いのは、Googleビジネスプロフィールと表記が異なるNAP（店名・住所・電話番号）です。営業時間の不一致や、複数店舗での同一データの使い回しも信頼性を下げます。

NAPとは、Name（店名）・Address（住所）・Phone（電話番号）の頭文字で、店舗情報の核になる3項目です。「1-2-3」と「1丁目2番3号」、ビル名の有無といった表記ゆれは、機械には別情報に見える恐れがあります。GBPの表記を正として、サイト側を一字一句そろえてください。

営業時間の不一致も頻発します。GBPだけ営業時間を変更し、サイトの構造化データが古いまま、というケースが典型です。また、ページの内容と無関係なスキーマを置くことはGoogleのガイドライン違反です。ページに表示していない情報をスキーマだけに書くのも避けます。

複数店舗の場合は、全店舗ページに本店のJSON-LDを使い回すミスが目立ちます。店舗ごとに固有の住所・電話番号・営業時間を記述しなければ、各店の情報は正しく伝わりません。

こうした一貫性の維持は、店舗数が増えるほど手作業では追いきれなくなります。きゃくくるは、GBPの情報をもとに各店舗ページの構造化データを自動整備し、表記ゆれや更新漏れを防ぎます。