複数拠点のLocalBusinessスキーマ設定方法：JSON-LD例付きで解説

複数の拠点を管理している場合、LocalBusinessスキーマは、拠点の全体像を検索エンジンにわかりやすく伝える武器にもなれば、気づかないうちに混乱を広げる原因にもなります。筆者はそのどちらのケースも見てきました。

うまくいくパターンはシンプルです。実在するすべての拠点について、その拠点を代表するページに正確なLocalBusinessスキーマを設置します。

親ブランドには適切な場所にOrganizationスキーマやWebSiteスキーマを置き、両者をきちんと関連付けます。そして、その内容を、お客様やGoogleがすでにGoogleビジネスプロフィール、ウェブサイト、サイテーションで目にしている情報と一致させます。

一方で、うまくいかないパターンもよく見かけます。1つのLocalBusinessスキーマが全ページにコピーされている、JSON-LDに古い電話番号が残っている、入れるべきでない場所にレビューのマークアップが追加されている、トップページで全拠点を一度に説明しようとしている、といったケースです。

そこで本記事では、複数拠点のLocalBusinessスキーマをどう構成するか、どのスキーマタイプが重要か、どこに設置するか、そして拠点が増えてもデータを正確に保つにはどうすればよいかを解説します。

LocalBusinessスキーマとは？

LocalBusinessスキーマとは、ビジネスの拠点情報を検索エンジンが読み取れる形式で記述する構造化データ（スキーママークアップ）のコードです。ローカルSEOでは、標準化された語彙としてSchema.orgを使い、実装形式にはJSON-LDを用います。

わかりやすく言えば、LocalBusinessスキーマは検索エンジンに次のことを伝えます。

• ビジネスの名称
• ビジネスの種類
• 所在地
• お客様からの連絡方法
• 営業時間
• その拠点を代表するページ
• その拠点と親ブランドとの関係

拠点が1つだけのビジネスなら、設定は通常それほど難しくありません。

多拠点ビジネスで重要なのは「分けること」です。拠点ごとに専用の拠点ページと、その拠点専用のスキーマが必要になります。

親ブランドがすべての住所に存在するかのように扱ってはいけませんし、すべての拠点が同じ汎用的なマークアップを引き継ぐのも避けるべきです。

覚えておくべきキーワードは「正確さ」です。

LocalBusinessスキーマは、ウェブサイトのコンテンツ、Googleビジネスプロフィール、サイテーションの代わりになるものではありません。それらすべてが同じ情報を示しているときに、その情報を補強する役割を果たします。すでに複数のGoogleビジネスプロフィールを管理しているなら、その正確さを検索結果にまで届けるのがスキーマの役割です。

使えるLocalBusinessスキーママークアップの種類

ローカルSEOのあらゆる課題を1つで解決できるスキーマタイプはありません。

実際には、ビジネスモデル、サイト構造、拠点ページの内容に応じて、いくつかのスキーマタイプを組み合わせて使います。

LocalBusinessスキーマ

LocalBusinessは、実店舗のある拠点や地域密着型のサービス業を表す中心的なスキーマタイプです。実在する店舗、支店、オフィス、クリニック、レストラン、ショールーム、サービス提供エリアの拠点があるなら、通常はこれが基本のタイプになります。

可能であれば、LocalBusinessで止めずに、より具体的なサブタイプを選びましょう。レストランチェーンならRestaurant、歯科医院グループならDentist、ホテルブランドならHotelといった具合です。具体的であるほど、検索エンジンは拠点の内容を正しく理解できます。

このスキーマタイプのサンプルは次のとおりです。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/locations/shibuya/#localbusiness",
  "name": "サンプルピザ 渋谷店",
  "url": "https://example.com/locations/shibuya/",
  "telephone": "+81-3-1234-5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "渋谷2-21-1",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0002",
    "addressCountry": "JP"
  }
}

Organizationスキーマ

Organizationスキーマは親となる組織を表します。 会社、フランチャイズブランド、グループ、代理店、運営企業などです。通常はトップページや会社概要ページに設置し、固定の@id（エンティティを一意に識別するためのURL形式の識別子）を使って各拠点をこの組織に関連付けます。

このスキーマタイプのサンプルは次のとおりです。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "サンプルピザ",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png"
}

LocalBusinessスキーマとOrganizationスキーマの使い分け

ブランドにはOrganizationスキーマを使います。

実在する各拠点にはLocalBusinessスキーマを使います。

この区別が重要なのは、トップページは通常、会社全体を表すのに対し、拠点ページは1つの住所、1つの電話番号、1つの営業時間、1つのURLを持つ1拠点を表すからです。

注意： 全拠点のLocalBusinessスキーマをトップページに置くと、ページの内容が解釈しにくくなる場合があります。逆に、すべての拠点ページにOrganizationスキーマしか置かないと、ユーザーが探している拠点固有の情報が伝わりません。

Placeスキーマ

Placeは、物理的な場所を表すより広い概念のスキーマタイプです。LocalBusinessはすでにPlaceをより具体化したタイプなので、ビジネスの拠点にPlaceを単独で使うことはほとんどありません。複数の部門やテナントが入る施設、ランドマーク、上位の場所をマークアップするときに役立ちます。

このスキーマタイプのサンプルは次のとおりです。

{
  "@type": "Place",
  "name": "サンプルメディカルセンター",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "西新宿1-1-1",
    "addressLocality": "新宿区",
    "addressRegion": "東京都"
  }
}

PostalAddressスキーマ

PostalAddressは、LocalBusiness、Organization、Placeの各スキーマの中に入れ子にして使います。実際の住所の各項目を定義する部分です。Googleビジネスプロフィールや拠点ページの表記と一致させてください。

このスキーマタイプのサンプルは次のとおりです。

{
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "新宿3-1-1 サンプルビル2階",
    "addressLocality": "新宿区",
    "addressRegion": "東京都",
    "postalCode": "160-0022",
    "addressCountry": "JP"
  }
}

GeoCoordinatesスキーマ

GeoCoordinatesは、拠点の緯度と経度を検索エンジンに伝えます。データが信頼できる場合は含めるようにしています。特に、同じ市区町村に複数の拠点がある場合や、サービス提供エリアが近接している場合に有効です。

このスキーマタイプのサンプルは次のとおりです。

{
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.6909,
    "longitude": 139.7044
  }
}

OpeningHoursSpecificationスキーマ

OpeningHoursSpecificationは、営業時間を構造化された形式で定義します。祝日の営業時間、季節ごとの営業時間、臨時休業などで頻繁に変わるため、最も情報が古くなりやすい項目の1つです。

このスキーマタイプのサンプルは次のとおりです。

{
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}

Serviceスキーマ

Serviceスキーマは、拠点が提供するサービスを記述するのに役立ちます。ページ上のサービス紹介コンテンツの代わりに使うものではありません。本文ですでに紹介しているサービスを補強するために使います。

このスキーマタイプのサンプルは次のとおりです。

{
  "makesOffer": {
    "@type": "Offer",
    "itemOffered": {
      "@type": "Service",
      "name": "水まわりの緊急修理"
    }
  }
}

Departmentスキーマ

Departmentスキーマは、1つの拠点の中に、名称、電話番号、営業時間、予約方法が異なる部門がある場合に役立ちます。病院の診療科、自動車ディーラーのサービス部門、大学の事務窓口、大型店舗の売り場などをイメージしてください。

このスキーマタイプのサンプルは次のとおりです。

{
  "department": {
    "@type": "LocalBusiness",
    "name": "サンプル自動車 サービス部門",
    "telephone": "+81-3-2345-6789",
    "openingHours": "Mo-Fr 07:00-18:00"
  }
}

WebSiteスキーマ

WebSiteスキーマは、拠点ではなくサイトそのものを表します。通常はサイト全体またはトップページのレベルで設置します。特に、サイト内検索や店舗検索の機能が明確にある場合に有効です。

このスキーマタイプのサンプルは次のとおりです。

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com/",
  "name": "サンプルピザ"
}

ReviewスキーマとAggregateRatingスキーマ

ReviewスキーマとAggregateRatingスキーマは慎重に扱う必要があります。Googleは、ローカルビジネスが自社に関するレビューを自らマークアップすること（自己宣伝目的のレビュー）について厳しいルールを設けています。自社サイトから引用したレビューや、Googleの構造化データに関するポリシーに反する形で表示したレビューは、マークアップが無視されたり、品質上の問題につながったりする可能性があります。

実践的なルール： レビューがあるからといって、それだけでレビュースキーマを追加しないでください。レビューの内容、出典、ページの文脈がGoogleのガイドラインに沿っている場合にのみ追加します。

FAQスキーマ

FAQスキーマは、実際の質問と回答のコンテンツを補強するのに使えますが、キーワードのバリエーションを詰め込む場所にしてはいけません。FAQを追加するなら、実際にある質問にわかりやすく答え、ページのテーマと一致させてください。

複数拠点のLocalBusinessスキーマを設定する方法

多拠点ビジネスに最適なスキーマ構成は、きれいな階層構造です。

• トップページまたは会社概要ページ： 親ブランドのOrganizationスキーマとWebSiteスキーマ
• 店舗検索ページ： 必要に応じてItemListやナビゲーション用のコンテンツ
• 各拠点ページ： その拠点専用のLocalBusinessスキーマを1つ
• 部門やサービスの詳細： ページの内容が裏付けている場合にのみ補助的なスキーマ

ステップ1：親組織を特定する

まず、親となるビジネスエンティティを定義します。拠点網を所有、運営、または代表するブランドや会社のことです。

親組織には、次のような固定の@idを付けます。

{
  "@id": "https://example.com/#organization"
}

この@idが、各拠点を関連付けるための基準点になります。これがないと、各拠点は大きなブランドの一部ではなく、それぞれ独立したエンティティのように見えてしまう可能性があります。

ステップ2：拠点ごとに適切なスキーマタイプを選ぶ

次に、拠点ごとに最も正確なスキーマタイプを選びます。LocalBusinessでも問題ありませんが、当てはまるサブタイプがあればそちらのほうが適しています。

例：

• レストランチェーンならRestaurant
• 歯科医院ならDentist
• クリニックならMedicalClinic
• 自動車ディーラーならAutoDealer
• 小売店ならStore
• 一部の住宅関連サービス業ならHomeAndConstructionBusiness

競争上有利に聞こえるという理由でスキーマタイプを選ぶのはやめましょう。ビジネスの実態を正しく表すタイプを選んでください。

ステップ3：必要な拠点データを集める

JSON-LDのコードを書く前に、各拠点のデータを1か所に集めます。多拠点を運営するチームが覚えておくべきなのは、スキーマの追加自体は難しくないものの、元になるデータが一貫している必要があるという点です。

最低限、次の情報を集めてください。

• ビジネス名
• ビジネスのカテゴリまたは種類
• 番地
• 市区町村、都道府県、郵便番号、国
• 電話番号
• 拠点ページのURL
• 営業時間
• 地図のURL
• 緯度と経度
• 提供しているサービス
• 画像またはロゴ

注意： LocalBusinessスキーマで特に重要なプロパティは、通常name、address、telephone、url、openingHoursSpecification（営業時間）、geo（緯度経度）、sameAs（同じ拠点を表す外部プロフィールのURL）、hasMap（地図のURL）、image、そして適切なビジネスのサブタイプです。

ステップ4：拠点ごとに専用ページを作成する

重要な拠点にはすべて、専用の拠点ページを用意しましょう。そのページは、住所、電話番号、営業時間、サービス、アクセス方法、地域に関する情報など、ユーザーと検索エンジンがその拠点の詳細を確認するための正式な場所であるべきです。

LocalBusinessスキーマを追加するのもこのページです。ほとんどの場合、全拠点のLocalBusinessスキーマをトップページに置くことはおすすめしません。

例： 渋谷店のスキーマは渋谷店の拠点ページに、新宿店のスキーマは新宿店の拠点ページに設置します。トップページは親ブランドの説明に集中させます。

充実した拠点ページには、次の要素を含めましょう。

• H1またはページタイトルに拠点名と地名
• GBPと一致するNAP情報（名称、住所、電話番号）
• 埋め込み地図または地図へのリンク
• 必要に応じて、車でのアクセスや駐車場の案内
• その拠点で提供しているサービス
• 拠点の写真
• 掲載が許可されていて関連性がある場合に限り、クチコミやお客様の声
• /locations/shibuya/のような、わかりやすいURLパス

スキーマにとどまらず、拠点ページをSEOの資産としてどう機能させるかまで考えたい場合は、地域単位のコンテンツを計画するためのローカルキーワードリサーチの記事もあわせてご覧ください。

ステップ5：各拠点ページにLocalBusinessスキーマを追加する

ページができたら、その拠点専用のJSON-LDを追加します。1拠点分のLocalBusinessスキーマの例は次のとおりです。

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/locations/shinjuku/#localbusiness",
  "name": "サンプル歯科 新宿院",
  "url": "https://example.com/locations/shinjuku/",
  "telephone": "+81-3-3456-7890",
  "image": "https://example.com/images/shinjuku-office.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "新宿3-1-1 サンプルビル2階",
    "addressLocality": "新宿区",
    "addressRegion": "東京都",
    "postalCode": "160-0022",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.6909,
    "longitude": 139.7044
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "parentOrganization": {
    "@id": "https://example.com/#organization"
  },
  "hasMap": "https://maps.google.com/?cid=1234567890"
}

ヒント： スキーマの語彙について調べるときは、Schema.orgの公式サイトが参考になります。

ステップ6：各拠点を親組織に関連付ける

複数拠点のスキーママークアップで、筆者が決して省略しないのが、拠点と親会社との関係づけです。

拠点は、固定の参照を使って親組織に関連付けられます。

{
  "parentOrganization": {
    "@id": "https://example.com/#organization"
  }
}

拠点数が少ない場合は、親のOrganizationスキーマ側から各拠点を記述することもできます。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "サンプル歯科グループ",
  "url": "https://example.com/",
  "subOrganization": [
    {
      "@type": "Dentist",
      "@id": "https://example.com/locations/shinjuku/#localbusiness",
      "name": "サンプル歯科 新宿院",
      "url": "https://example.com/locations/shinjuku/"
    },
    {
      "@type": "Dentist",
      "@id": "https://example.com/locations/ikebukuro/#localbusiness",
      "name": "サンプル歯科 池袋院",
      "url": "https://example.com/locations/ikebukuro/"
    }
  ]
}

規模の大きいブランドでは、各拠点ページに詳細なLocalBusinessスキーマを置き、トップページのOrganizationスキーマを親の参照先として使う構成をおすすめします。

ステップ7：サービス、部門、営業時間の補助スキーマを追加する

メインのLocalBusinessスキーマが正しく設定できたら、ページの内容がより明確になる場合にのみ補助的なスキーマを追加します。

拠点ページで具体的なサービスを紹介しているならServiceスキーマを、拠点内に独自の情報を持つ部門が実際にあるならDepartmentスキーマを使います。営業時間がページに表示され、更新が管理されているならOpeningHoursSpecificationを使います。WebSiteスキーマはサイトレベルで使い、拠点のスキーマの代わりにはしません。

ルールはシンプルです。構造化データは、常にページ上にすでにあり、ユーザーに役立つ情報を記述するものです。

ステップ8：LocalBusinessの構造化データを検証する

公開前に、GoogleのリッチリザルトテストとSchema.orgのバリデーターのどちらか、または両方を使って検証します。2つは答えてくれる問いが異なるため、筆者は両方を使っています。

Googleのテストでは、リッチリザルトの対象となる構造化データをGoogleが読み取れるかどうかがわかります。Schema.orgのバリデーターはより幅広くチェックでき、語彙や構文の問題を見つけるのに役立ちます。

検証時には、次の点を確認してください。

• JSON-LDの構文エラー
• 必須項目や推奨項目の漏れ
• 誤ったスキーマタイプ
• 古いNAP情報
• トップページのスキーマが誤って拠点ページにコピーされていないか
• 拠点ページが誤った親組織を参照していないか
• Googleのルールに沿っていないレビューのマークアップ

ステップ9：スキーマを定期的に監視・更新する

LocalBusinessスキーマは、一度設定すれば終わりという作業ではありません。多拠点ビジネスでは、営業時間、カテゴリ、電話番号、予約用URL、サービス、担当者、住所が変わっていきます。

Googleビジネスプロフィールの拠点情報を一括編集したときは、ウェブサイトとスキーマも更新しましょう。GBPでは18時閉店なのにウェブサイトのスキーマでは17時閉店になっている、といった食い違いは信頼を損なう原因になります。

定期的にGoogleビジネスプロフィールの監査を行えば、こうしたズレが積み重なる前に発見できます。さらにローカル順位トラッカーを組み合わせれば、修正によって各拠点の表示状況が実際に改善しているかどうかも確認できます。

複数拠点のスキーマ チェックリスト

公開前に、次のチェックリストで確認しましょう。

• 親ブランドに、固定の@idを持つOrganizationスキーマがある
• 重要な拠点にはすべて専用の拠点ページがある
• 各拠点ページに、その拠点専用のLocalBusinessスキーマが1つある
• スキーマタイプが実際のビジネスカテゴリと一致している
• NAP情報がページ、GBP、サイテーションと一致している
• 必要に応じて特別営業時間も含め、営業時間が最新である
• 拠点ごとのスキーマに固有の@idが使われている
• 各拠点が親組織を参照している
• ServiceスキーマとDepartmentスキーマは、ページの内容が裏付けている場合にのみ使われている
• レビュースキーマがGoogleの構造化データのルールに沿っている
• ページがJSON-LDの検証をパスしている
• スキーマの更新プロセスに担当者がいて、成り行き任せになっていない

避けるべきLocalBusinessスキーマのよくある間違い6つ

よく見かける間違いは、高度な技術的問題ではありません。たいていは、スキーマのコードの中に潜んでいる運用上の問題です。

• 同じLocalBusinessスキーマをすべての拠点ページにコピーしないでください。住所、電話番号、URLがどこでも同じなら、そのページを正しく記述しているとは言えません。
• 親ブランドを、地域の拠点であるかのようにマークアップしないでください。ブランドと拠点は関連していますが、同じエンティティではありません。
• レビュースキーマを安易に使わないでください。LocalBusinessのレビューのマークアップはGoogleのルールが重要になる分野であり、自己宣伝目的のレビューのマークアップは無視される可能性があります。
• ページに表示されている内容と矛盾するスキーマを追加しないでください。ページとJSON-LDの内容が食い違っている場合は、まず元のコンテンツを修正します。
• 検証を忘れないでください。カンマが1つ抜けただけでJSON-LDのブロック全体が壊れることがありますし、古い電話番号が1つ残っているだけで、それが何十ページにも使い回され続けることがあります。
• スキーマを拠点情報の更新フローから外さないでください。チームがGBPの営業時間を変更するなら、拠点ページとスキーマも同じ更新プロセスに含めるべきです。

拠点ごとにローカルスキーママークアップを使うべき理由

ローカルスキーママークアップは魔法ではありませんし、Googleマップの順位を直接上げる近道だと言うつもりもありません。その価値は「明確さ」にあります。 多拠点ビジネスにとっては、次のようなメリットがあります。

• 各拠点の情報を検索エンジンが理解しやすくなる
• 拠点と親ブランドの関係が明確になる
• 拠点ページを、正確なNAP情報を軸に構成できる
• 業種、営業時間、サービスに関して、より充実した検索結果につながる
• 同じ市区町村で複数の拠点を運営している場合も、情報の曖昧さが減る
• 多数の拠点ページで、技術的な土台を統一できる
• スキーマを作る過程で拠点データを点検することになるため、品質管理が向上する

最後の点は見落とされがちです。LocalBusinessスキーマを監査すると、ローカルSEOの他の場面でも悪影響を及ぼしている問題がよく見つかります。古い営業時間、一致しない電話番号、統一されていないカテゴリ、内容の薄い拠点ページ、そして信頼できる唯一の情報源がないことです。

スキーマは、より大きなGoogleマップSEOの仕組みを構成する要素の1つと考えてください。スキーマだけでページの順位が決まるわけではありませんが、その仕組み全体をGoogleが信頼しやすくなります。

Localithで複数拠点のスキーマを正確に保つ方法

Localithは、多数の拠点のGoogleクチコミ管理から、Googleの拠点情報の一括更新まで幅広く対応する、総合的なGBP管理プラットフォームです。

LocalBusinessスキーマの設定においてLocalithが本当に役立つのは、スキーマを作成する前に拠点データを整理し、正確に保てる点です。

Googleビジネスプロフィール、拠点ページ、スキーマがそれぞれ異なる情報を示していると、Googleには矛盾したシグナルが伝わり、お客様にとっても不便な体験になります。

これを防ぐには、Localithのアカウントを作成し、次の手順に沿って進めるだけです。

1. 左側のメニューにある「リスティング」タブで、Googleの拠点をすべて接続します。
2. 「一括編集」タブから、Googleの拠点情報を更新します。
3. 目的に応じて「単一情報の一括編集」または「複数情報の一括編集」を選択します。
4. 更新したい拠点を選びます。
5. 営業時間や住所など、更新したい情報の項目を選択します。
6. 新しい情報を入力します。
7. 変更内容を確定します。

注意： 複数情報の一括編集を選んだ場合は、あらかじめ用意された.CSVファイルをダウンロードし、手動で更新してから再アップロードするよう案内されます。

これで完了です。まもなくGoogle上の拠点データがすべて更新され、変更内容が反映されます。手順の詳細はGoogleビジネスプロフィールを一括編集する方法のガイドで紹介しています。運用面を引き締めるために、Googleビジネスプロフィール管理のベストプラクティスもあわせてご覧ください。

さらに、「SEO管理」タブにある「ローカルサイテーション」ツールを使えば、Google上に表示されている基本情報が、Yelp、Apple、Bing Placesなどの主要なリスティングディレクトリにも正しく反映されているかを確認できます。

Localithを活用すれば、次のことが可能になります。

• Googleビジネスプロフィールから拠点データを取得して一元管理する
• NAP、カテゴリ、URL、営業時間の不一致を見つける
• 拠点ページをGBPの項目と一致させる
• 信頼できる唯一の情報源から、スキーマを作成しやすくする
• 代理店が多数のクライアントと拠点のスキーマ用データを管理できるようにする

ワークフローの中でLocalithを活用すべきタイミングは、マークアップの前、運用・保守の期間中、そして拠点データが変わるたびです。

ビジネス名、住所、電話番号、カテゴリ、URL、営業時間が1か所で正しく整理されていれば、スキーマの作成は、拠点ごとに手作業で情報を整理し直すプロジェクトではなく、決まった手順で進められる公開作業になります。

代理店にとっては、これがさらに重要です。多くのクライアントのローカルSEOを管理するには、繰り返し使える入力データが欠かせません。LocalithならGBPと拠点データを整理しておけるので、ウェブサイト、スキーマ、レポートの内容がずれていくのを防げます。

まとめ：すべての拠点のスキーマを一致させ続ける

複数拠点のLocalBusinessスキーマは、整理された拠点構成をそのまま反映しているときに最も効果を発揮します。

まずは親組織から始めます。次に拠点ごとの専用ページを作り、各ページに正確なLocalBusinessスキーマを1つずつ追加します。

そのうえで、各拠点を親ブランドに関連付け、マークアップを検証します。そして、GBP、営業時間、サービス、拠点情報が変わるたびにデータを更新し続けましょう。

大切なのは、スキーマを追加することだけではありません。スキーマが信頼されるよう、拠点データ全体を一貫した状態に保ち続けることです。