空間AIは、複数の拠点を持つ企業向けに、正規の支店記録、在庫状況、営業時間、サービスエリア、および移動状況を連携させ、最寄りのピンではなく、適切な場所を1つだけ推奨できるようにします。言語モデルは、「帰宅途中に在庫のある商品を探す」といった複合的な意図を解釈します。位置情報システム、在庫システム、経路計算システムが、支店の識別、在庫、営業時間、移動に関する信頼できる情報源であり続けます。空間AIは、利用可能な支店をランク付けし、地図上でその結果を説明します。
以下のセクションでは、組織の識別情報と支店記録を分離し、資格要件、移動ランキング、Kaleidrマッピング、測定、および小規模パイロットについて説明します。関連資料として、AI Store Locator With Map Chat、Store-Aware Shopping AI、Location Intelligence Customer Experienceを参照してください。既存の支店マップに会話を関連付けているチームは、Kaleidrマッピングのセクションに進んでください。カタログ境界をまだ定義していないチームは、正規のロケーションレコードから始める必要があります。
複数ロケーション空間AIの基本
- 場所ごとに1つのID: 各支店、施設、クリニック、またはサービスポイントには、安定したロケーションIDが必要です。
- 事実は所有者に保持される: 営業時間、在庫、収容人数、および価格は、モデルから生成されるものではありません。
- 最寄りは検索対象: 最も近いピンによる並べ替えは推奨ではありません。
- ランクより先に資格: 閉鎖、在庫切れ、エリア外、または許可されていない場所が最初にセットから削除されます。
- 場所の測定: 選択、経路案内、受け取り、そして検索結果なしの地理的位置情報は、チャット時間だけよりも効果的です。
複数拠点空間AIは、顧客のニーズに最も適した支店を特定し、単に最も近いピンを示すだけではありません。
複数拠点企業における空間AIは、なぜ独自のアーキテクチャ上の課題となるのでしょうか？
単一の店舗では、ピンを1つ、営業時間の記録を1つ、アクションを1つ公開できる場合が多い。数十、数千もの支店を持つ企業では、製品の役割は異なる。顧客は既にブランドの存在を知っており、どの店舗が今すぐ対応してくれるのかを尋ねている。その答えは、マーカーの表示だけではなく、支店の機能、実際の営業状況、営業時間、サービスエリア、移動手段、ビジネスルールによって決まる。
Kaleidrは現在、ビジネスデータ、位置情報、既存システムを連携させるカスタマージャーニーを中心にプラットフォームを位置付けており、AI応答のための位置情報に基づくビジネス知識基盤について説明しています（AI-Powered Map Experiences for Business）。AI Map Chat for Customer Discoveryページでは、検索機能とレコメンデーション機能をホストが既に運用しているマップに連携させる方法について説明しており、小売業もその業種の一つとして挙げられています。これらのページは、Kaleidr自身のポジショニングに関する権威ある情報源です。しかし、これらのページは、Kaleidrがネイティブの在庫台帳、CRM、営業時間フィード、フランチャイズディレクトリを運用していることを示す証拠にはなりません。
上記の店舗検索に関する記事では、顧客向けの検索機能（リスト、地図、フィルター、ディレクトリを介したチャット）について説明しています。ショッピングに関する記事では、特定の店舗におけるSKUと在庫状況について説明しています。本ガイドは、これらの顧客体験を支えるエンタープライズアーキテクチャ、すなわち、正規ID、資格要件、ランキング、そしてネットワーク全体における場所中心の分析について解説しています。たとえ同じ店舗が1つの地図上に表示されていても、製品内ではこれら3つの課題を明確に区別してください。
各店舗はどのような正規ロケーションレコードを保持すべきか？
ブランドは1つの組織である可能性があります。その拠点は1つのレコードではありません。各支店は、座標、住所、営業時間、サービス、在庫、スタッフの能力、アクセス、サービスエリア、営業状況、次のビジネスアクションが異なる場合があります。公開リスティングシステムでは、すでにこの分割を運用上の問題として扱っています。Googleは現在、企業に対し、各拠点ごとに複数のプロファイルページを作成しないこと、拠点間で名前とカテゴリを統一すること、店舗とサービスエリアのビジネスを区別することを推奨しています（Guidelines for representing your business on Google, 2026）。プロファイルを一括管理できる規模のチェーン向けに、Googleは現在、10以上の拠点を持つ企業向けの一括追加、検証、管理ワークフローを文書化しています（Bulk location management overview, 2026）。これらのヘルプページは、Googleの公開リスティング契約について説明しています。これらのページは、Kaleidrのロケーションスキーマではありません。
Schema.org では現在、LocalBusiness を組織の特定の物理的な事業所または支店 (LocalBusiness, 2026) と定義しています。branchCode は事業所を一意に識別する短い店舗コードで、通常は親組織がそのコードを割り当てます (branchCode, 2026)。parentOrganization は支店が属するより大きな組織の名前です (parentOrganization, 2026)。Google Search Central では現在、各ローカル事業所を LocalBusiness タイプとして定義し、可能な限り最も具体的なサブタイプを使用し、name と address を必須プロパティとして提供するようにパブリッシャーに指示しています (Google Search Central, 2026)。これらのタイプは、構造化データとしてのアイデンティティを示しており、Schema.org バージョン 30.0 でも現行です（Schema.org Releases, 2026）。同じ語彙は Kaleidr カタログ スキーマではなく、公開検索用の構造化データは、ピックアップ、予約、またはアカウント固有のアクセスに対するファーストパーティの適格性に取って代わるものではありません。
安定したロケーションIDは、空間AIワークフローにおいて、マップ、AI、運用状況、および分析が同じブランチについて通信することを可能にします。
正確なフィールドリストは製品固有です。負荷を支える契約は、ウェブサイト、マップ、空間AI、在庫、分析、CRM、予約、サポート全体にわたる安定したlocationIdであり、親組織IDが代替としてではなく、その横に付随します。アドレス文字列をIDとして使用しないでください。ロゴが共有されているからといって、すべての支店を1つのブランドピンに統合しないでください。ブランド名や決済ブランドなどの組織データは継承できます。座標、営業時間、ローカル電話番号などの位置情報データは支店に保持する必要があります。第3層である運用状態には、在庫、キャパシティ、一時休業が明示的なupdatedAtとともに保持されます。これは、昨日の在庫がランキング機能ではないためです。
最寄りの支店だけでは不十分なのはなぜですか？
近隣の店舗マップは、ピンの周囲にどの店舗があるかを示します。複数店舗対応の商品では、残りの時間内に顧客の要望を満たすことができる店舗がどれかを示します。この違いは重要です。なぜなら、最寄りの店舗が閉店していたり、在庫切れだったり、サービスエリア外だったり、必要なサービスを提供していなかったり、通勤途中の立ち寄り予定に合わなかったりする可能性があるからです。遠くの店舗が、次の予定までに営業していて、認可されていて、アクセス可能な唯一の店舗である場合もあります。
近接性は検索機能です。候補となる場所が特定された後、レコメンデーションが開始されます。製品は、顧客が支店に到達し、タスクを完了し、次の目的地にも立ち寄れるかどうかを判断する必要があります。上記の顧客体験に関する記事では、同じ「発見 → 比較 → 実行」のプロセスについて説明しています。「発見」では、対象となる場所が検索されます。「比較」では、営業時間、在庫状況、移動時間などを確認できます。「実行」では、経路案内、受け取り、予約、または予約の引き継ぎが行われます。閉店中または空きピンが数百メートル近いという理由でランク付けされると、この順序が逆転します。
まず使用できない場所をフィルタリングし、次に空間AIが実際にリクエストを満たすことができる支店をランク付けします。
ランキング前に、適格性フィルターで場所をどのように絞り込むべきか？
厳密な制約は二値であり、ランキング前に場所、在庫、および経路計算の所有者と連携する必要があります。現在閉店している、営業時間が不明（ただし、製品によっては営業時間が既知である必要がある）、希望するバリエーションが在庫切れ、サービスエリア外、必要なサービスが提供されていない、または承認が不足している場合は、候補から除外する必要があります。近隣地域、ロイヤルティレベル、またはわずかに短い移動距離などのソフトな優先順位に基づいて、残りの有効なセットをランク付けします。閉店している旗艦店が、より有名であるという理由だけで上位にランク付けされるべきではありません。
言語モデルは、「帰宅途中の店舗でこの商品の在庫状況を確認してください」といったリクエストを、出発地、目的地、商品、開店条件、受け取りまたは訪問方法、移動制限といった検証可能なフィールドに変換できます。これらのフィールドは、既存の情報を持つシステムに対するクエリであり、架空の値ではありません。どの例も構造は例示です。重要な点は、曖昧な表現が、顧客が会話を再開することなく修正できる状態として扱われることです。
以下の比較は例示であり、Kaleidrや小売店の測定結果ではありません。オプションに同じ列が必要な理由を示すためにのみ使用してください。実際の商品では、現在の営業時間、在庫状況、経路計算の応答に基づいてこれらの列が埋められるはずです。リクエストは、特定の在庫商品、本日受け取り、職場からの移動時間20分以内というものです。
| 候補 | 営業中 | 在庫 | 職場からの移動 | 受け取り |
|---|---|---|---|---|
| 支店A | いいえ | 在庫あり | 6分 | いいえ |
| 支店B | はい | 在庫切れ | 9分 | はい |
| 支店C | はい | 在庫あり | 12分 | はい |
| 支店D | はい | 在庫あり | 24分 | はい |
支店Aは最も近いですが、閉店しているため利用できません。支店Bは営業しており、近くにありますが、商品を提供できません。支店Cはやや遠く、在庫があり、営業中で、移動時間の上限内に収まるため、推奨支店となります。支店Dも候補には残りますが、所要時間は長くなります。適格性は絞り込みのためのフィルターです。ランキングは残った候補の順位付けです。説明は、候補リストが存在する理由を具体的に示すものです。
移動時間と経路の状況は、支店の順位付けにどのように影響するか？
推奨は、顧客が支店にたどり着き、かつ目的を達成できる場合にのみ有効です。直線距離だけでは判断できません。2つの店舗が職場からほぼ同じ距離にある場合でも、片方は通勤で12分、もう片方は市内を迂回して24分かかる可能性があります。ランキングでは、出発地から支店までの距離、残りの営業時間、そして顧客が次の目的地を指定した場合、その目的地への支店を一つの実現可能性として評価する必要があります。
沿線探索と複数アンカー探索は、起点が異なるだけで同じ作業です。帰宅途中のどの店に行くかを知るには、職場周辺の半径だけでなく、ルートが必要です。オフィスとピックアップの間でどのクリニックに行けるかを知るには、両方のアンカーが必要です。顧客が制約をすでに指定した後に、言語モデルにその所要時間を推測させないでください。Place Ranking API は、適格性フィルターを通過した候補を検証可能な形で順位付けする方法を扱っており、次の目的地がすでに行程上にある場合も含まれます。
出張型（サービスエリア型）の事業者には、最寄り店舗の並べ替えではなく、対象エリアに含まれるかどうかの判定が必要です。同じ Google ビジネスプロフィールのガイドラインでは、顧客が来店する事業者と顧客のもとへ出向く事業者を区別し、サービスエリアとスタッフが別々の場合は、スタッフを配置している拠点ごとに1つのプロフィールを作成できるようにしています（Guidelines for representing your business on Google, 2026）。ファーストパーティの空間AIは、顧客の出発地または目的地が承認されたサービスエリア内にあるか、そして作業員が約束された時間枠内に到着できるかを依然として確認する必要があります。隣の都市にあるピンは地理的に近いように見えても、サービスエリア外である可能性があります。
Kaleidr はマルチロケーション基盤にどう対応しますか？
Kaleidr の実装では、ホストが既に運用しているマップと位置情報スタックに会話型の空間レイヤーをアタッチできます。Kaleidr は現在、Chat を、ホストが既にレンダリングしているマップ上にマウントされ、解決済みの場所をプロットし、会話によって場所が解決されるにつれてカメラをフレーム化する製品として文書化しており、Mapbox、MapLibre、Google Maps、Leaflet (Chat attach) の自動検出機能を備えています。アタッチ契約では、現在の公開開発者向けインターフェースにマップ対応の会話機能が存在することが確認されています。ただし、同じ文書では、ネイティブの在庫カタログ、予約エンジン、または営業時間フィードの提供は保証されていません。
これらのシステムは、明示的なデプロイメント依存関係として維持する必要があります。Kaleidr は対話型の空間レイヤーとマップ認識型の調整機能を提供できますが、デプロイメントでは適切な権威ある位置情報、在庫情報、ルーティング情報源を使用します。デプロイメントの特定の統合が文書化されていない限り、Kaleidr 自体がストア オペレーターまたは在庫台帳であると示唆しないでください。How to Add AI Chat to Mapbox, Google Maps, and MapLibre では、レンダラー固有のアタッチ手順について説明します。Location Intelligence APIs and Map SDK ページでは、空間製品の SDK、ランキング、および分析について説明しています。現在の開発者向けドキュメントを統合契約として扱い、マーケティング ページでは在庫フィード リストではなくユース ケースについて説明します。
公開可能なキーはブラウザー SDK で使用されます。サーバー認証情報はアプリケーション層に属します。Kaleidr は現在この分離を文書化しており、ベアラーとして提示された公開可能なキーは拒否されると述べています (Auth & scopes)。プライベート インベントリ、アカウント固有の資格、非公開の場所、および顧客レコードは、そのサーバー境界の内側に属します。Private Location Data for AI Map Workflows は、ホストが公開しない移動とビジネス データに対する認証について説明しています。デバイスの位置情報は別の権限であり、職場、自宅、予約済みの予定、または選択したマップ ポイントが既に適切な出発地として指定されている場合は、必要ありません。
共有マップ状態は、会話、カード、および支店を単一の正規ロケーションIDに紐付けます。支店を選択すると、その場所がハイライト表示され、移動経路が表示され、制約条件が維持されます。より近い場所を尋ねると、同じ商品、営業時間、および受け取りルールが維持されます。返品を受け付けている場所について尋ねると、新しいネットワークを作成するのではなく、資格審査が再実行されます。アシスタント専用の、目に見えない2つ目のリストは、この契約を破ります。
オペレーション部門は、場所検索とカバレッジをどのように測定すべきでしょうか？
マップのパンとチャットのオープンは診断です。結果の指標には、クエリの開始、返された有効な結果、場所の選択、開かれた経路、ピックアップまたは予約、および予約の引き渡しが含まれます。品質の指標には、結果なし率、古い営業時間率、不明な在庫率、および旅行計算の失敗が含まれます。ビジネス指標はホストに依存します。完了したピックアップ、予約された訪問、誤った経路への移動の減少、またはどの店舗に在庫があるかから始まるサポートコールの減少などです。単なる失敗フラグではなく、現在閉店、在庫切れ、エリア外、遠すぎる、営業時間不明、または承認されていないなど、構造化された結果なしの理由を保持します。
検索の地理情報は、デバイスの地理情報とは別に管理する必要があります。ある都市にいる顧客が、別の都市の支店を検索できます。需要は、デフォルトではデバイスの位置情報ではなく、検索された場所に紐付けられます。Map Engagement and Location Analytics は現在、製品、在庫、成長チームが活用できる地図と場所のエンゲージメント、場所の比較、空間パターン、アクティビティについて文書化しています。ホストシステムは、在庫と予約を引き続き管理します。複数の拠点を持つ企業は、このモデルを使用して、どの郵便番号で在庫検索が発生し、対象となる支店がないか、どの移動時間帯で顧客が離脱するか、どの市場で需要があるにもかかわらずサービスが提供されていないかなどを調べることができます。これらの質問は、ページビューに関する質問ではなく、地理に関する質問です。Spatial Analytics vs. Web Analytics では、ページビューだけではこれらの質問に答えられない理由について説明しています。
顧客検索によって位置情報のカバレッジ、在庫、および支店データの改善が必要な場所が明らかになると、複数拠点空間AIの価値が高まります。
この記事で提案されているホストイベント名は編集上の推奨事項であり、Kaleidr Analyticsの自動イベント名として文書化されているものではありません。インテント、適格性の結果、選択されたロケーションID、およびそれに続くホストアクションをログに記録してください。チャットの長さを複数拠点検索の成功指標として扱わないでください。ロケーションのパフォーマンスにはコンテキストも必要です。需要の低いセルにある静かな支店と、需要の高いセルにある現在適格な検索結果が返されない静かな支店は、同じ問題ではありません。
複数拠点パイロットプロジェクトはどのように開始すべきか？
まず、単一の都市圏内で、職場から自宅までの経路にある在庫のある受け取り場所を1つ推奨するなど、価値の高いタスクを1つ実行します。場所のディレクトリ、営業時間、在庫状況は、既にそれらを管理しているシステムに保持します。既存の地図に会話型の地図操作を追加します。候補を承認済みの支店に限定し、要求された商品の開店州と在庫状況を必須とし、指定された出発地からの移動距離を計算し、選択とそれに続くホストのアクションを測定します。最初のウィンドウがうまく機能する場合にのみ、カテゴリ、都市、フランチャイズテナントを拡張します。
会話型検索は、カタログの品質、鮮度、またはフルフィルメントの規律に取って代わるものではありません。移動時間はあくまでも目安です。在庫状況は、その背後にある在庫ソースの信頼性に左右されます。既存のマップにアシスタントを追加する方が、レンダリングエンジンを交換するよりも通常は安価ですが、ホストは依然として承認、サプライヤー契約、および次のビジネスアクションを管理する必要があります。すべてのブランド拠点を一度に展開するのではなく、市場ごとに展開し、欠落データはパスではなく不明として扱います。
Explore Kaleidr Spatial AI 既存の地図に会話型位置情報検索機能を追加します。 Explore Kaleidr Enterprise 既に運用しているスタックにSDKとランキングをアタッチします。 Explore Kaleidr Analytics その旅程周辺の場所のエンゲージメントと地理的な需要を測定します。この記事の例を本番環境の機能仕様として扱う前に、現在の公開ページを確認してください。
よくある質問
複数拠点を持つ企業にとっての空間AIとは何ですか？
複数拠点を持つ企業にとっての空間AIは、顧客の意図、正規の支店記録、営業時間、在庫状況、サービスエリア、移動時間、およびビジネスルールを組み合わせることで、実際にリクエストに対応できる場所を製品が推奨できるようにします。空間AIはリクエストを解釈して説明しますが、位置情報システムとコマースシステムは事実に関する権威を維持します。
これは店舗検索とどう違うのですか？
店舗検索は、顧客がディレクトリで店舗を検索して確認するのに役立ちます。複数拠点空間AIは、営業状況全体にわたって適格性とランキングを追加することで、ピンの位置だけでなく、どの支店が今すぐ対応できるかを製品が回答できるようにします。
すべての事業所に固有のIDが必要ですか？
はい。公開リストガイドラインとSchema.orgはどちらも、支店を独立した場所として扱います。ファーストパーティ検索、マップ、AI、および分析には、異なるレコードに迷い込まないように、同じ安定したIDが必要です。
在庫情報はロケーションレコード内に保持すべきでしょうか？
ロケーションレコードには、IDと地理情報を保持します。在庫状況、キャパシティ、および一時休業情報は、同じロケーションIDをキーとする運用レイヤーに保持し、鮮度タイムスタンプを明示的に付与します。
ランキング前にフィルタリングする必要があるのはなぜですか？
顧客が利用できない場所をランキングすると、候補リストが無駄になります。閉店、在庫切れ、エリア外、および承認されていない支店は、移動時間や選好スコアを計算する前に除外する必要があります。
最も近い支店が常に最適な支店でしょうか？
いいえ。最も近い支店が閉店していたり、空いていたり、ルートから外れている可能性があります。利用可能な支店を、確認可能な移動状況とビジネスコンテキストに基づいてランキングします。
Kaleidrは既存の店舗検索や支店マップと連携できますか？
はい。現在公開されているチャット添付ドキュメントでは、Mapbox、MapLibre、Google Maps、Leafletなど、ホストが既にレンダリングしているマップ上で会話を進める方法について説明しています。ロケーションカタログと次のビジネスアクションはホストが引き続き管理します。
Kaleidrは在庫管理システム、予約システム、またはCRMシステムを置き換えるものですか？
いいえ。現在公開されているKaleidrのページでは、会話型マップ検索、SDK、ランキング、および分析について説明しています。在庫、価格、予約、CRMは、特定の統合が文書化されていない限り、ホストまたはサプライヤーのシステムに残ります。
複数拠点を持つ企業は、空間AIをどのように評価すべきですか？
ロケーション選択、経路案内、ピックアップ、ホストへの引き継ぎ、検索結果が表示されない理由、需要とカバレッジの地理的分布などを評価する必要があります。チャット量だけでは、成功の指標としては不十分です。
参考資料
- Kaleidr. AI-Powered Map Experiences for Business. Accessed 11 September 2026. https://kaleidr.com/
- Kaleidr. AI Map Chat for Customer Discovery. Accessed 11 September 2026. https://kaleidr.com/ai
- Kaleidr. Map Engagement and Location Analytics. Accessed 11 September 2026. https://kaleidr.com/analytics
- Kaleidr. Location Intelligence APIs and Map SDK. Accessed 11 September 2026. https://kaleidr.com/enterprise
- Kaleidr. Chat attach. Developer documentation. Accessed 11 September 2026. https://docs.kaleidr.com/sdk/chat-attach
- Kaleidr. Auth & scopes. Developer documentation. Accessed 11 September 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
- Google Business Profile Help. Guidelines for representing your business on Google. Accessed 11 September 2026. https://support.google.com/business/answer/3038177
- Google Business Profile Help. Bulk location management overview. Accessed 11 September 2026. https://support.google.com/business/answer/3217744?hl=en
- Schema.org. LocalBusiness. Version 30.0. Accessed 11 September 2026. https://schema.org/LocalBusiness
- Schema.org. branchCode. Version 30.0. Accessed 11 September 2026. https://schema.org/branchCode
- Schema.org. parentOrganization. Version 30.0. Accessed 11 September 2026. https://schema.org/parentOrganization
- Google Search Central. Local business (LocalBusiness) structured data. Last updated 8 September 2026. Accessed 11 September 2026. https://developers.google.com/search/docs/appearance/structured-data/local-business
- Schema.org. Releases. Version 30.0, 19 March 2026. Accessed 11 September 2026. https://schema.org/docs/releases.html
@misc{kaleidr_home_multiloc_2026_09_11,
title = {AI-Powered Map Experiences for Business},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/}
}
@misc{kaleidr_ai_multiloc_2026_09_11,
title = {AI Map Chat for Customer Discovery},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/ai}
}
@misc{kaleidr_analytics_multiloc_2026_09_11,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/analytics}
}
@misc{kaleidr_enterprise_multiloc_2026_09_11,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/enterprise}
}
@misc{kaleidr_chat_attach_multiloc_2026_09_11,
title = {Chat attach},
author = {{Kaleidr}},
note = {Developer documentation; accessed 11 September 2026},
url = {https://docs.kaleidr.com/sdk/chat-attach}
}
@misc{kaleidr_auth_scopes_multiloc_2026_09_11,
title = {Auth \& scopes},
author = {{Kaleidr}},
note = {Developer documentation; accessed 11 September 2026},
url = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}
@misc{gbp_representation_multiloc_2026_09_11,
title = {Guidelines for representing your business on Google},
author = {{Google Business Profile Help}},
note = {Accessed 11 September 2026},
url = {https://support.google.com/business/answer/3038177}
}
@misc{gbp_bulk_locations_multiloc_2026_09_11,
title = {Bulk location management overview},
author = {{Google Business Profile Help}},
note = {Accessed 11 September 2026},
url = {https://support.google.com/business/answer/3217744?hl=en}
}
@misc{schema_localbusiness_multiloc_2026_09_11,
title = {LocalBusiness},
author = {{Schema.org}},
note = {Version 30.0; accessed 11 September 2026},
url = {https://schema.org/LocalBusiness}
}
@misc{schema_branchcode_multiloc_2026_09_11,
title = {branchCode},
author = {{Schema.org}},
note = {Version 30.0; accessed 11 September 2026},
url = {https://schema.org/branchCode}
}
@misc{schema_parentorg_multiloc_2026_09_11,
title = {parentOrganization},
author = {{Schema.org}},
note = {Version 30.0; accessed 11 September 2026},
url = {https://schema.org/parentOrganization}
}
@misc{google_localbusiness_sd_multiloc_2026_09_11,
title = {Local business (LocalBusiness) structured data},
author = {{Google Search Central}},
note = {Last updated 8 September 2026; accessed 11 September 2026},
url = {https://developers.google.com/search/docs/appearance/structured-data/local-business}
}
@misc{schema_releases_multiloc_2026_09_11,
title = {Releases},
author = {{Schema.org}},
note = {Version 30.0, 19 March 2026; accessed 11 September 2026},
url = {https://schema.org/docs/releases.html}
}