ローカルビジネス構造化データ：JSON-LDの完全な例、Googleのルール、避けるべきミス

ローカルビジネス構造化データは、店舗、レストラン、クリニック、代理店などの連絡先ブロックを機械が読めるデータに変えるスキーママークアップの一種です。Google はローカルビジネスの構造化データに関するガイドで仕様を公開しており、語彙は schema.org/LocalBusiness に由来します。このガイドでは、そのまま応用できる完全な例、押さえるべきルール、そしてマークアップを無意味にしてしまうミスを紹介します。

LocalBusiness スキーマとは？

LocalBusiness は schema.org の型で、「特定の実店舗ビジネス、または組織の支店」を表します。Organization と Place という 2 つの親の型を継承しているため、企業のプロパティ（ロゴ、電話番号、SNS のプロフィール）と場所のプロパティ（住所、座標、地図、営業時間）の両方を使えます。

schema.org には 30 の直接のサブタイプがあり、その多くにさらに下位の型があります。Google は利用可能な最も具体的なサブタイプを使うよう求めています。歯科医院なら Dentist、パン屋なら Bakery、法律事務所なら LegalService または Attorney です。よく使われる型は次のとおりです。

複数の型に当てはまる場合、Google は配列を受け付けます。たとえば ["Store", "AutoRepair"] です。この目的での additionalType はサポートされていません。

Google が必須・推奨とするプロパティは？

Google のドキュメントでは、プロパティが 2 つのグループに分かれています。必須は 2 つだけで、マークアップを役立つものにするのは推奨プロパティです。

最後の行は AI での可視性にとって重要です。sameAs はページをビジネス プロフィール、SNS アカウント、ディレクトリの掲載情報と結びつけ、これらのプロフィールが同じエンティティを表していることをあらゆるシステムが確認しやすくします。

JSON-LD によるローカルビジネス構造化データの完全な例

JSON-LD は Google が推奨する形式で、タイプが application/ld+json の script タグを、店舗ページの head または body に配置します。架空の歯科医院の完全な例を示しますので、自社のデータに合わせて調整してください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example-dental.com/lyon/#business",
  "name": "Example Dental Lyon",
  "url": "https://www.example-dental.com/lyon/",
  "image": "https://www.example-dental.com/images/lyon-front.jpg",
  "logo": "https://www.example-dental.com/images/logo.png",
  "telephone": "+33 4 00 00 00 00",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Rue de la République",
    "addressLocality": "Lyon",
    "postalCode": "69002",
    "addressRegion": "Auvergne-Rhône-Alpes",
    "addressCountry": "FR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.76012,
    "longitude": 4.83584
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "12:30"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/exampledentallyon",
    "https://www.linkedin.com/company/example-dental"
  ]
}
</script>

この例を堅牢にしているポイントは 3 つあります。@id はビジネスに固定の識別子を与え、サイト内の他のブロック（Organization、Service、Review）から参照できるようにします。座標は Google の求めるとおり小数点以下 5 桁です。そして url はトップページではなく店舗ページを指しています。コードを手書きしたくない場合は、無料のスキーマジェネレーターでフォームからブロックを作成できます。

営業時間、祝日、複数店舗はどうマークアップする？

営業時間

営業時間が同じ曜日のグループごとに OpeningHoursSpecification オブジェクトを 1 つ使います。Google のドキュメントは次のような特殊なケースもカバーしています。

• 深夜営業：1 つのオブジェクトで日付をまたげます（土曜 18:00 から 03:00 まで）。
• 24 時間営業：opens を "00:00"、closes を "23:59" にします。
• 終日休業：opens と closes をどちらも "00:00" にします。
• 季節営業や祝日の休業：オブジェクトに validFrom と validThrough の日付（YYYY-MM-DD）を追加します。

営業時間が変わったら、ビジネス プロフィールと同時にマークアップも更新してください。両者の営業時間の食い違いは、Google や AI の回答で誤った情報が出るよくある原因です。

複数の店舗

各店舗には、専用のページと、専用の LocalBusiness ブロック、住所、電話番号、営業時間が必要です。トップページの 1 つのブロックに 10 件の住所を詰め込まないでください。トップページにはブランドの Organization ブロックを置き、各店舗ページは parentOrganization でそれを参照します。こうしたページの作り方は、複数店舗の SEO と地域別ランディングページのガイドで解説しています。

部門

スーパー内の薬局や自動車ディーラー内のサービスセンターは department 配列に入れ、本体のビジネスと異なるプロパティだけを記述します。Google は、部門に独自のブランドがない限り、「{店舗名} {部門名}」という名前を付けることを推奨しています。

出張型ビジネス

顧客の自宅で作業する配管業者でも、登記上の事業所の住所で LocalBusiness を使い、対応エリアを areaServed で記述できます。Google は areaServed を自社のプロパティ一覧に含めていませんが、schema.org では有効で、対応エリアを設定したビジネス プロフィールとページの整合性を保てます。

ローカルビジネス構造化データは Google ビジネス プロフィールの代わりになる？

なりません。Google ビジネス プロフィールは、ローカルパックと Google マップの主な情報源であり続けます。Google のヘルプセンターによると、ローカル検索結果は主に関連性、距離、知名度によって決まり、「完全かつ正確な情報を掲載しているビジネスほど表示されやすくなります」。スキーママークアップは別の側面に働きかけます。プロフィールと同じ内容を、機械が推測せずに読める形式でサイトに語らせるのです。

両者をつなぐのが NAP の一貫性です。名称（Name）、住所（Address）、電話番号（Phone）を、プロフィール、サイト、マークアップ、ディレクトリで同じ表記にします。ルールの詳細は NAP の定義で、他のローカルシグナルの中でのスキーマの位置づけはローカル SEO のページで解説しています。

LocalBusiness マークアップの検証方法とよくあるミスは？

店舗ページのテンプレートはすべて 2 つのツールでテストしましょう。Google の機能の対象になるかを確認するリッチリザルト テストと、schema.org に照らして構文を確認する Schema Markup Validator です。当社の構造化データ検証ツールなら、任意の URL をすばやくチェックできます。公開後は、Search Console の拡張レポートでエラーを一括で確認できます。

Google の構造化データに関するポリシーが枠組みを定めています。「ページの読者に表示されないコンテンツをマークアップしないでください。」違反すると手動による対策を受け、リッチリザルトの対象外になることがあります。よく見かけるミスは次のとおりです。

レビューに関するミスには特に注意が必要です。2019 年以降、Google は LocalBusiness や Organization が自社について掲載する「自己宣伝的な」レビューに星を表示しなくなりました。詳しくはレビューの構造化データに関するガイドで解説しています。同じ考え方は FAQ スキーマにも当てはまります。ページに表示されている内容だけをマークアップしてください。

ローカルビジネス構造化データと GEO：AI アシスタントはどう使うのか

誰かが ChatGPT、Gemini、Perplexity に「リヨンで土曜日に開いている歯医者」を尋ねると、回答はアシスタントが読み取り、照合できる情報源から組み立てられます。ビジネス プロフィールのデータ、ディレクトリ、レビュープラットフォーム、そして各ビジネス自身のウェブサイトです。当社のAI の回答におけるディレクトリの調査では、こうした第三者の掲載情報がどれくらいの頻度で引用されるかを示しています。

構造化データは 2 つの面で役立ちます。フッターの解析に頼らない明確な事実（営業時間、住所、業種）をクローラーに提供すること、そして sameAs と一貫した NAP によって、サイトを他のプロフィールと同じエンティティに結びつけることです。全体像はAI 検索のための構造化データのガイドで解説しており、LLM 向け構造化データ監査では言語モデルがあなたのページから何を抽出するかを確認できます。マークアップだけでは決して十分ではありません。多くのアシスタントは JSON-LD だけでなくページそのものを読むため、事実は表示テキストにも書いておく必要があります。

取り組みの効果を確かめるには、Sorank の AI 言及トラッキングが顧客の尋ねるローカルな質問を追跡し、あなたのビジネスが引用されているかを示します。また GEO 最適化は、アシスタントが引用する店舗やサービスのコンテンツの公開を支援します。考え方の全体は地域ビジネス向けのページにまとめています。

覚えておきたいルール：1 店舗につき 1 ページ、1 つの LocalBusiness ブロック、そしてビジネス プロフィールと同じ名称、住所、電話番号、営業時間。追加し、検証し、ビジネスに変化があるたびに更新しましょう。