DSO、獣医チェーン、ジム、フランチャイズ向けマルチサイトアーキテクチャ

歯科DSO50社も、200店舗のジムチェーンも、30物件のホテルグループも、15キャンパスの教会ネットワークも、同じウェブサイトアーキテクチャの問題を抱えています。必要なのは：集中的なブランド管理、ロケーションごとのローカライズコンテンツ、1つの管理ダッシュボード、ロケーションごとのSEOページ、すべてを同時に更新しながら何も壊さない展開です。アーキテクチャは同じです。コンテンツが異なるだけです。

このパターンを歯科グループ、フィットネスフランチャイズ、獣医ネットワーク、レストランチェーンに構築してきました。毎回、同じデータベーススキーマ、同じNext.jsルート構造、同じロールベースのアクセス制御から始めます。変わるのはシードデータとコンポーネントラベルだけです。「Services」がジムでは「Classes」に、レストランでは「Menu Items」になります。「Staff」は「Dentists」「Trainers」「Veterinarians」になります。内側の配管？同じです。

このポストでは、ユニバーサルなマルチロケーションアーキテクチャパターンを一度説明した上で、まったく異なる5つの業界にどのように適応するかを示します。マルチロケーションビジネスを経営していても、開発者としてそのために構築していても、このブループリントがあります。

目次

• すべてのマルチロケーションビジネスが直面するコア問題
• ユニバーサルデータベーススキーマ
• Next.jsルートアーキテクチャ
• 行レベルセキュリティと管理ダッシュボード
• 業界バリエーション1: 歯科DSO
• 業界バリエーション2: ジムとフィットネスチェーン
• 業界バリエーション3: ホテルグループ
• 業界バリエーション4: 獣医クリニックチェーン
• 業界バリエーション5: レストランチェーン
• アーキテクチャ比較表
• スケール時の展開とパフォーマンス
• コスト内訳: 2025年の実際のコスト
• FAQ

すべてのマルチロケーションビジネスが直面するコア問題

通常何が起こるかについて、率直に言いましょう。フランチャイズまたはマルチロケーションビジネスは単一のウェブサイトから始まります。次に2番目の場所が開きます。誰かが2番目のWordPressインストールをスピンアップします。15の場所がある頃には、15の独立したWordPressサイト、15の異なるテーマ（一部は3バージョン遅れている）、15の異なるプラグインセット、集中管理ゼロがあります。

マーケティング担当者は、すべての場所のブランドのプライマリCTAを更新したいと考えています。それは15回のログイン、15の編集、そして誰もテンプレートを壊していないという祈りです。SEOチームは、どの場所がブログコンテンツを公開しており、どの場所が6ヶ月間暗黒に陥っているかを見たいと考えています。そのためのダッシュボードはありません。3月に誰かが更新するのを忘れたスプレッドシートだけです。

これは50の診療所を管理している歯科支援組織（DSO）でも、200の場所を持つレストラングループでも同じ問題です。症状は同じです：

• ブランドドリフト。 一貫性を強制する人がいないため、ロケーションはブランドを外れます。
• SEO断片化。 構造化されたローカルSEOページがなく、スキーママークアップの一貫性がなく、集中管理されたサイトマップがありません。
• 管理の混乱。 各ロケーションが自分のサイト（不十分に）を管理するか、企業がすべてを処理します（ゆっくり）。
• 展開リスク。 1つのロケーションのサイトを更新すると、別のロケーションが停止する可能性があります。

修正は、より良いCMSテーマではありません。それは完全に異なるアーキテクチャです。

ユニバーサルデータベーススキーマ

すべてはlocationsテーブルで始まります。これはシステム全体のアンカーです。データベースと認証レイヤーとしてSupabaseを使用します。Postgres、行レベルセキュリティ、リアルタイムサブスクリプション、寛大な無料ティアを提供するためです。ただし、スキーマはリレーショナルデータベースで機能します。

コアスキーマは以下の通りです：

-- アンカーテーブル。すべてのロケーション固有コンテンツが
-- location_idを介してこれを参照します。
CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  name TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  address TEXT NOT NULL,
  city TEXT NOT NULL,
  state TEXT NOT NULL,
  zip TEXT NOT NULL,
  lat DECIMAL(10, 8),
  lng DECIMAL(11, 8),
  phone TEXT,
  email TEXT,
  hours JSONB DEFAULT '{}',
  photos TEXT[] DEFAULT '{}',
  description TEXT,
  metadata JSONB DEFAULT '{}',
  is_active BOOLEAN DEFAULT true,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

-- コンテンツテーブルは同じパターンに従います：
-- location_idはNULLABLEです。
-- NULL = すべてのロケーション間で共有
-- 値 = その特定のロケーションに限定

CREATE TABLE services (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  location_id UUID REFERENCES locations(id) ON DELETE CASCADE,
  name TEXT NOT NULL,
  slug TEXT NOT NULL,
  description TEXT,
  price_range TEXT,
  duration TEXT,
  category TEXT,
  sort_order INT DEFAULT 0,
  is_active BOOLEAN DEFAULT true,
  metadata JSONB DEFAULT '{}'
);

CREATE TABLE staff (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  location_id UUID REFERENCES locations(id) ON DELETE CASCADE,
  name TEXT NOT NULL,
  slug TEXT NOT NULL,
  title TEXT,
  photo TEXT,
  bio TEXT,
  credentials TEXT[],
  specialties TEXT[],
  sort_order INT DEFAULT 0,
  is_active BOOLEAN DEFAULT true
);

CREATE TABLE blog_posts (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  location_id UUID REFERENCES locations(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  excerpt TEXT,
  author_id UUID REFERENCES staff(id),
  published_at TIMESTAMPTZ,
  is_published BOOLEAN DEFAULT false,
  tags TEXT[] DEFAULT '{}',
  metadata JSONB DEFAULT '{}'
);

CREATE TABLE testimonials (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  location_id UUID REFERENCES locations(id) ON DELETE CASCADE,
  author_name TEXT NOT NULL,
  rating INT CHECK (rating >= 1 AND rating <= 5),
  content TEXT,
  is_approved BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE events (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  location_id UUID REFERENCES locations(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  description TEXT,
  event_date TIMESTAMPTZ,
  end_date TIMESTAMPTZ,
  is_active BOOLEAN DEFAULT true
);

nullable location_idパターンは重要な洞察です。ブログポストがlocation_id = NULLの場合、それはネットワーク全体の記事です（すべての50の歯科診療所で共有される「健康な歯のための5つのヒント」）。location_idに値がある場合、それはそのロケーションに固有です（「スミス医師がオースティン診療所に参加」）。同じテーブル、同じクエリパターンですが、コンテンツは単一の列で共有またはローカライズできます。

metadata JSONBカラムは業界固有フィールドが存在する場所です。歯科ロケーションは{"insurance_accepted": ["Delta Dental", "Cigna"], "parking_info": "Free lot behind building"}を保存できます。ジムは{"equipment": ["squat racks", "rowing machines"], "peak_hours": "5-7 PM weekdays"}を保存します。スキーママイグレーションは不要です。異なるJSON形状だけです。

Next.jsルートアーキテクチャ

Next.js App Routerはこのデータモデルに整然とマップされます。すべての業界に機能するルート構造は以下の通りです：

app/
├── page.tsx                          # ホームページ
├── locations/
│   ├── page.tsx                      # ロケーション検索（マップ+地理検索）
│   └── [slug]/
│       ├── page.tsx                  # ロケーション詳細ページ
│       ├── staff/page.tsx            # ロケーション用スタッフリスト
│       └── services/page.tsx         # ロケーション用サービス
├── services/
│   └── [service]/page.tsx            # 共有サービスの説明
├── blog/
│   ├── page.tsx                      # すべてのブログ記事
│   └── [post]/page.tsx               # 個別ブログ記事
├── about/page.tsx
└── contact/page.tsx

ロケーション詳細ページ（/locations/[slug]）は魔法が起こる場所です。単一のgenerateStaticParams呼び出しがすべてのアクティブなロケーションをクエリし、ビルド時にそのすべてを事前レンダリングします：

// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'

export async function generateStaticParams() {
  const supabase = createClient()
  const { data: locations } = await supabase
    .from('locations')
    .select('slug')
    .eq('is_active', true)

  return locations?.map((loc) => ({ slug: loc.slug })) ?? []
}

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  const { data: location } = await supabase
    .from('locations')
    .select('*')
    .eq('slug', params.slug)
    .single()

  if (!location) return {}

  return {
    title: `${location.name} | ${location.city}, ${location.state}`,
    description: location.description,
    openGraph: {
      title: `${location.name} - ${location.city}`,
      images: location.photos?.[0] ? [location.photos[0]] : [],
    },
  }
}

export default async function LocationPage({ params }: { params: { slug: string } }) {
  const supabase = createClient()
  
  const [{ data: location }, { data: staff }, { data: services }, { data: testimonials }] = 
    await Promise.all([
      supabase.from('locations').select('*').eq('slug', params.slug).single(),
      supabase.from('staff').select('*').eq('location_id', params.slug), // 簡略化
      supabase.from('services').select('*').or(`location_id.is.null,location_id.eq.${locationId}`),
      supabase.from('testimonials').select('*').eq('is_approved', true),
    ])

  // すべてのデータを持つロケーションページをレンダリング
  // これは業界に関係なく同じコンポーネント構造です
}

サービスクエリはそのorフィルターを使用します。location_idがnull（共有サービス）またはcurrentロケーションと一致するサービスを取得します。これは、歯科DSOが「歯のクリーニング」をすべてのロケーションに一度定義してから、「インビザライン」をそれを提供するロケーションにのみ追加できることを意味します。重複なし。

ロケーション検索ページでは、緯度経度座標を保存し、Supabaseの PostGIS拡張機能を地理クエリに使用します：

-- ユーザーの座標から25マイル以内のロケーションを検索
SELECT *, 
  (point(lng, lat) <@> point($1, $2)) * 1.60934 AS distance_miles
FROM locations
WHERE is_active = true
ORDER BY point(lng, lat) <@> point($1, $2)
LIMIT 20;

行レベルセキュリティと管理ダッシュボード

ここはアーキテクチャが本当に報酬を与える場所です。Supabase RLSポリシーは、アプリケーションコードではなく、データベースレベルでデータアクセスを定義できます。

-- ロケーションマネージャーは自分のロケーションのデータのみを見ることができます
CREATE POLICY "Location managers see own data" ON services
  FOR ALL
  USING (
    location_id IN (
      SELECT location_id FROM user_locations
      WHERE user_id = auth.uid()
    )
    OR
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE user_id = auth.uid() AND role = 'network_admin'
    )
  );

ネットワーク管理者はすべてを見ることができます。ロケーションマネージャーはそのロケーションのみを見ることができます。これはすべてのテーブルに適用されます。サービス、スタッフ、ブログ記事、証言、イベント。1つのポリシーパターン、一貫して適用。

管理ダッシュボードはネットワークレベルのメトリクスを表示します：

• コンテンツの鮮度： どのロケーションが30日以上ブログを更新していないか？
• ロケーションあたりのトラフィック： ロケーションのスラッグ別に集計されたGoogle Search Consoleデータ
• ロケーションあたりのリード： ロケーション別のフォーム送信と予約リクエスト
• ブランド準拠： すべてのロケーションが承認されたロゴ、色、CTA テキストを使用していますか？

業界バリエーション1: 歯科DSO

DSO ウェブサイトは、統一された歯科ブランドのように感じながら、各診療所が独自のプロバイダーと特性を強調できる必要があります。

Servicesは歯科手順にマップされます：クリーニング、充填、クラウン、インプラント、インビザライン、緊急歯科治療。いくつかは普遍的です（すべてのロケーションがクリーニングを行う）、他は場所固有です（3つのロケーションのみが鎮静歯科を提供します）。

Staffは歯科医、歯科衛生士、オフィスマネージャーです。それぞれは認定資格（DDS、DMD）、特性、教育、プロフィール写真を含むプロファイルを取得します。小児歯科医を選ぶ親は、誰が子どもを治療するのかを見たいと考えています。

CTAは「予約を予約する」です。これは Calendly、NexHealth、またはカスタム予約システムに接続します。予約ウィジェットは、ユーザーがどのロケーションページから来たかに基づいてロケーションを事前に選択します。

ローカルSEOターゲット： 「[市区町村]の歯科医」、「[市区町村]の[手順]」、「[市区町村][州]の緊急歯科医」。各ロケーションページは、DentistとLocalBusinessスキーマの構造化データマークアップを取得します。

Metadata JSONBは以下を保存します：受け入れられた保険プラン、駐車情報、アクセシビリティ機能、話される言語、新しい患者を受け入れるかどうか。

業界バリエーション2: ジムとフィットネスチェーン

ジムチェーンは「サービス」を「クラス」と交換します。ただし、データモデルは同じです。ロケーション Aのヨガクラスとロケーション Bの HIIT クラスは、異なるlocation_id値を持つサービステーブルの行です。

Servicesは、スケジュールデータ付きのクラスタイプです。メタデータは、週次スケジュールをJSONとして保存し、インストラクター割り当て、容量制限、ドロップインが許可されているかどうかを保存します。

Staffは、認定資格（NASM、ACE、CrossFit L2）、特性、パーソナルトレーニング予約の利用可能性を持つトレーナーとインストラクターです。

CTAは「今すぐ参加」です。メンバーシップティアを処理し、複数のロケーションへのアクセスを処理する Stripe サブスクリプション チェックアウト。ダウンタウンロケーションにサインアップするメンバーは、郊外のロケーションでもチェックインできるはずです。

ローカルSEOターゲット： 「近くのジム」、「[市区町村]のフィットネスクラス」、「[市区町村]の[クラスタイプ]クラス」、「[市区町村]のパーソナルトレーナー」。

Metadata JSONBは以下を保存します：機器のリスト、クラススケジュール、ピークタイム、アメニティ（サウナ、プール、保育施設）、無料駐車の利用可能性。

業界バリエーション3: ホテルグループ

ブティックホテルグループと独立したホテルチェーンは、このパターンから膨大に恩恵を受けます。特に、OTA委託料を回避する直接予約を可能にするため（Booking.comまたはExpediaの予約あたり通常15～25%）。

Servicesは、ルームタイプになります：標準ルーム、キングスイート、ペントハウス。それぞれは写真、アメニティリスト、面積、ベース料金を取得します。ロケーション固有の価格はメタデータまたは日付範囲の個別の料金テーブルにあります。

Staffは軽めです。ブランドのストーリーテリングのための、おそらく紹介されたゼネラルマネージャーまたはコンシェルジュ。

CTAは「直接予約」です。ゲストにホテル独自のサイトで OTA ではなく予約する理由を与える FME（検索、マッチング、エンゲージ）パターン。通常、「最高料金保証」または無料アップグレード。

ローカルSEOターゲット： 「[市区町村]のホテル」、「[ホテル名]レビュー」、「ブティックホテル[近所][市区町村]」、「[ランドマーク]近くのホテル」。

Metadata JSONBは以下を保存します：アメニティ（プール、スパ、レストラン、ジム、EV充電）、近隣の観光スポット、ローカルイベントカレンダー、チェックイン/チェックアウト時間、ペットポリシー。

業界バリエーション4: 獣医クリニックチェーン

獣医チェーンは 2025 年に急速に成長しています。獣医学での統合は、10年前に起こった歯科DSO の状況を反映しています。同じマルチロケーションアーキテクチャは完全に適用されます。

Servicesはペットケアサービスです：健康診断、予防接種、歯のクリーニング、手術、緊急治療、ペット預かり、グルーミング。一部のロケーションはエキゾチックペットケアを提供します。ほとんどは提供しません。

Staffは種固有の専門知識（小動物、馬、エキゾチック）、専門認定資格、教育を持つ獣医です。

CTAは「予約を予約する」です。ただし、アップテイクフォームが、ペット情報（種、品種、年齢、来院理由）を取得して、予約を正しくルーティングする必要があります。

ローカルSEOターゲット： 「[市区町村]の獣医」、「[市区町村]の緊急獣医」、「[市区町村]の[種]の獣医」、「[市区町村]のペット歯クリーニング」。

Metadata JSONBは以下を保存します：受け入れられた種、緊急時間（通常営業時間と異なる場合）、ペット預かり容量、オンサイトラボとイメージングの有無。

業界バリエーション5: レストランチェーン

Servicesはメニューセクションになります：前菜、メインコース、デザート、ドリンク。ここで重要なのは、価格がロケーションによって異なる可能性があることです。バーガーはオースティンでは14ドル、マンハッタンでは19ドルです。metadataカラムはロケーション固有の価格上書きで処理します。

Staffは、認知されたシェフまたはピットマスターです。これは、食べ物の背後にいる人がストーリーの一部である企業に最適に機能します。

CTAは「オンラインで注文」です。ロケーション認識リンクで、ユーザーの最寄りのロケーション用の正しいオンライン注文システム（Toast、Square、ChowNow、またはカスタム）にルーティングされます。

ローカルSEOターゲット： 「[レストラン名][市区町村]メニュー」、「近くのレストラン」、「[市区町村]の[料理タイプ]レストラン」、「[レストラン名]時間」。

Metadata JSONBは以下を保存します：配信範囲、予約の利用可能性（OpenTableまたはResyリンク付き）、駐車詳細、プライベートダイニング容量、ハッピーアワー時間。

アーキテクチャ比較表

コンポーネント	歯科DSO	ジムチェーン	ホテルグループ	獣医チェーン	レストラン
「Services」ラベル	手術	クラス	ルームタイプ	ペットサービス	メニュー項目
「Staff」ラベル	歯科医	トレーナー	マネジメント	獣医	シェフ
プライマリCTA	予約を予約	メンバーシップに参加	ルームを予約	予約を予約	オンラインで注文
予約統合	NexHealth、Calendly	Stripeサブスクリプション	カスタム / Cloudbeds	カスタム + ペット入場	Toast、Square
キーローカルデータ	保険、駐車	スケジュール、機器	アメニティ、観光	種、緊急時間	メニュー価格、配信
プライマリSEOキーワード	「[市区町村]の歯科医」	「近くのジム」	「[市区町村]のホテル」	「[市区町村]の獣医」	「[ブランド][市区町村]メニュー」
スキーママークアップ	歯科医、LocalBusiness	SportsActivityLocation	Hotel、LodgingBusiness	VeterinaryCare	Restaurant、Menu
変更されたDBテーブル	0	0	0	0	0

その最後の行が重要なのです。業界間でゼロのデータベーステーブルが変更されます。同じlocations、services、staff、blog_posts、testimonials、eventsテーブルを使用しています。UIのラベルが変わります。メタデータの形状が変わります。アーキテクチャは変わりません。

スケール時の展開とパフォーマンス

Vercel に ISR（増分静的再生成）で展開します。各ロケーションページはビルド時に静的に生成され、60秒ごとに再検証されます。200ロケーションのチェーンの場合、それは任意のデバイスで1秒未満で読み込まれる200の静的HTMLページです。

数字が重要です。通常、次のようなものが表示されます：

• 200ロケーション用のビルド時間： Vercel Proで約45秒
• ロケーションページあたりのTTFB： < 50ms（エッジCDNから提供）
• Lighthouseスコア： 全体で95以上
• ISR再検証： 60秒のStale-While-Revalidateは、完全な再構築なしで1分以内にコンテンツ更新を表示することを意味します

新しいロケーションを追加するのは、データベース挿入およびオプションのオンデマンド再検証呼び出しです。新しい展開は不要です。generateStaticParams関数は、次のビルドまたはISRサイクルで新しいロケーションを取得します。

// ロケーションが追加/更新されたときに再検証をトリガーするAPIルート
import { revalidatePath } from 'next/cache'

export async function POST(request: Request) {
  const { slug } = await request.json()
  
  revalidatePath('/locations')
  revalidatePath(`/locations/${slug}`)
  
  return Response.json({ revalidated: true })
}

コスト内訳: 2025年の実際のコスト

実際の数字について話しましょう。これは価格設定会話中に受け取る一般的な質問です。

コンポーネント	月額コスト（50ロケーション）	月額コスト（200ロケーション）
Supabase Pro	$25	$25（同じティアが両方を処理）
Vercel Pro	$20	$20
Vercel帯域幅（超過）	~$0	~$40
ドメイン + DNS（Cloudflare）	$0	$0
画像CDN（Cloudflare R2）	~$5	~$15
監視（Sentry）	$26	$26
合計インフラストラクチャ	~$76/月	~$126/月

各 WordPress サイトで 50 個の個別サイトと約 30 ドル/月の管理ホスティング を比較してください。これは月額 1,500 ドルです。メンテナンス、プラグインライセンス、またはそれらをすべて更新し続ける必要がある人を考える前に。

開発投資は最初は高いです。通常、マルチロケーションビルドを複雑さに応じて 30,000～80,000 ドルで見積もります。ただし、継続的な運用コストは WordPress マルチサイト代替と比較して数分の一です。また、ロケーションあたり月額 500 ドルを、プラットフォームに閉じ込められるようなフランチャイズウェブサイトベンダーに支払っていません。

ヘッドレスCMS統合の探索やNext.jsの代わりにAstroを検討することに関心のあるチームの場合、さらに高速な静的ビルド用に、同じデータベースアーキテクチャが適用されます。フロントエンドフレームワークはスワップ可能です。データモデルはそうではありません。

FAQ

このアーキテクチャは異なるタイムゾーンのロケーションを処理できますか？

完全にできます。hours JSONBカラムは、各ロケーションの営業時間をそのローカルタイムゾーンに保存します。ロケーション メタデータにtimezoneフィールド（例：「America/Chicago」）を含めます。「Open Now」バッジなどの時間に敏感なディスプレイにはそれを使用します。データベース内のすべてのタイムスタンプはUTCで保存され、フロントエンドで変換されます。

異なるサービスを提供するロケーションをどのように処理しますか？

それは NULLlocation_idパターンの動作です。location_id = NULLのサービスはすべてのロケーション間で共有されます。すべてのロケーションのページに表示されます。特定のlocation_idを持つサービスはそのロケーションにのみ表示されます。共有サービスがロケーションごとのカスタム価格や可用性などのロケーションごとのオーバーライドが必要な場合、多対多の関係には結合テーブル（location_services）を使用することもできます。

新しいロケーションが開くとどうなりますか？

ネットワーク管理者がダッシュボードを介してロケーションを追加します。これにより、locationsテーブルに行が作成され、ISR再検証をトリガーするウェブフックが実行され、新しいロケーションページは60秒以内にライブになります。開発者は不要です、展開はありません、DNS変更はありません。ロケーションは、すべての共有サービスとコンテンツをすぐに継承します。

これは、フランチャイズ向けの WordPress Multisite より優れていますか？

ほとんどのマルチロケーション企業の場合、はい。WordPress Multisite は10年間の標準的な回答でしたが、実際の問題があります：単一のプラグインの脆弱性はネットワーク全体を奪う可能性があり、パフォーマンスはサイトを追加すると低下し、専用のシステム管理者が必要になります。このヘッドレスアーキテクチャは、静的サイトのパフォーマンス、データベースレベルのセキュリティ、ロケーション間の共有ランタイムリスクゼロを提供します。

ロケーションマネージャーが他のロケーションを壊さずに自分のコンテンツを編集するにはどうしたらいいですか？

行レベルセキュリティは、データベースレベルでこれを保証します。オースティンのロケーションマネージャーは、デンバーロケーションに属するデータを見たり変更したりすることはできません。アプリケーション コードのバグがある可能性があるコードではなく、Postgres 自体によって強制されます。管理UIが他のロケーションのデータをクエリしようとするバグがあったとしても、データベースは空の結果を返します。

SEOについて。各ロケーションは独自のサイトマップを取得しますか？

各ロケーションページは、ビルド時に生成された単一の動的サイトマップのエントリを取得します。また、LocalBusinessスキーマ、地理座標、営業時間、業界固有の種類を使用したロケーションごとの構造化データ（JSON-LD）を生成します。Googleは各/locations/[slug]ページを個別のローカルビジネスリストとして扱います。これは、ローカルパックランキングにまさに必要なものです。

ロケーションが共有ネットワークコンテンツを共有しながら独自のブログ記事を持つことができますか？

はい。もう一度、nullablelocation_idパターン。location_id = NULLのブログ記事はすべてのロケーションのブログフィードに表示されます。特定のlocation_idを持つ投稿はそのロケーションのフィードにのみ表示されます。マイアミのロケーションはローカルコミュニティイベントに関する投稿を公開でき、企業チームはネットワーク全体の思考的リーダーシップを公開します。両方がマイアミのブログフィードに表示されます。コーポレート投稿のみが他の場所に表示されます。

50の個別のウェブサイトを管理するのと比べて、継続的なメンテナンスコストはいくらですか？

このアーキテクチャでは、1つのコードベース、1つの展開、1つの依存セットがあります。月次インフラストラクチャは規模に応じて75～125ドルで実行されます。50のWordPressインストールと比較してください：ホスティングだけで月額1,500ドル、プラス月額10～20時間のプラグイン更新、セキュリティパッチ、自動更新の後に壊れたロケーション1つのトラブルシューティング。マルチロケーション企業がこのパターンへの移行後、年間ウェブ操作予算を60～70%削減したのを見てきました。