WordPress Multisiteは本当のマルチサイトではない：500の場所にスケールするアーキテクチャ

WordPress Multisiteは複数のサイトが得られるように聞こえます。実際に得られるのは、データベーステーブル名の前に番号を付けることで複数のサイトであるふりをする1つのWordPress インストールです。メインサイトはwp_postsを使用します。サブサイト2はwp_2_postsを使用します。サブサイト3はwp_3_postsを使用します。これはマルチサイトアーキテクチャではありません。これは同じテーブルの番号付きコピーを持つ1つのデータベースです。そして、それは結果をもたらします。

私は15、40、そして一度87のサブサイトを持つネットワークをWordPress Multisiteから移行しました。毎回、クライアントは独立したサイトが得られると思っていました。毎回、彼らはそうではないことを苦い経験で発見しました。フランチャイズ、複数拠点のビジネス、またはWordPress Multisiteで大学の部門ネットワークを実行している場合、この記事は少し痛いでしょう。しかし、サブサイト#47が他の46個すべてを取り down する前に知っておく方が良いです。

目次

• WordPress Multisiteが実際に内部で行うこと
• 偽のマルチサイトアーキテクチャの7つの結果
• WordPress Multisiteが実際に機能する場合
• 実際に500の場所にスケールするアーキテクチャ
• アーキテクチャ比較：接頭辞付きテーブル対行レベルセキュリティ
• 実装：マルチロケーションサイト向けNext.js + Supabase
• 移行パス：WordPress Multisiteから脱出
• 実数：パフォーマンスとコスト比較
• FAQ

WordPress Multisiteが実際に内部で行うこと

WordPressでMultisiteを有効にするときに何が起こるかを見てみましょう。wp-config.phpに数行追加します：

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

WordPressはいくつかのネットワークレベルのテーブル（wp_blogs、wp_site、wp_sitemeta、wp_registration_log、wp_signups）を作成し、すべての新しいサブサイトのコアテーブル構造の複製を開始します。

わずか5つのサブサイト後のデータベースの様子は以下の通りです：

wp_posts              (メインサイト)
wp_postmeta           (メインサイト)
wp_options            (メインサイト)
wp_users              (共有 - 全サイト)
wp_usermeta           (共有 - 全サイト)
wp_2_posts            (サブサイト2)
wp_2_postmeta         (サブサイト2)
wp_2_options          (サブサイト2)
wp_3_posts            (サブサイト3)
wp_3_postmeta         (サブサイト3)
wp_3_options          (サブサイト3)
...
wp_5_posts            (サブサイト5)
wp_5_postmeta         (サブサイト5)
wp_5_options          (サブサイト5)

5つのサブサイトと既に~55個のテーブルがあります。50個のサブサイト？500以上のテーブルが1つのMySQLデータベースにあります。500の場所？5,000を超えるテーブルが1つのデータベースにあります。1つの接続プールを共有しています。

すべてのテーブルに独自のインデックスがあります。すべてのクエリは特定の接頭辞付きテーブルをターゲットとします。クエリプランナーはこれすべてに対処する必要があります。そして、これらのテーブルのすべてが、同じデータベースと同じ認証情報を使用してそのサーバーで実行されているPHPプロセスからアクセス可能です。

これはマルチサイトアーキテクチャではありません。これは分離として機能する命名規則です。

偽のマルチサイトアーキテクチャの7つの結果

1. 共有脆弱性表面

WordPress Multisiteネットワーク内のすべてのサブサイトは、同じWordPressコア、同じプラグイン、同じテーマを実行します。1つのプラグインエクスプロイトがすべてのサブサイトを危険にさらします。なぜなら、彼らは同じコードベースを共有するからです。

これは理論的ではありません。2026年2月、900,000以上のアクティブインストールを持つバックアッププラグインWPVividは、重大度9.8のRCE（リモートコード実行）脆弱性が開示されました。10点満点中9.8。これは「認証されていない攻撃者がサーバー上で任意のコードを実行できる」領域です。

スタンドアロンのWordPressサイトでは、これは1つの危険にさらされたサイトです。30のサブサイトを持つMultisiteネットワークでは？それは30の危険にさらされたサイトです。同じサーバー。同じデータベース。同じファイルシステム。1つのエクスプロイト、完全なネットワーク侵害。

サブサイト#12にはサブサイト#13とは異なるバージョンのプラグインをインストールすることはできません。あるロケーションのプラグインを別のロケーションから分離することはできません。すべてのサイトが同じ攻撃表面を取得します。

2. プラグイン競合の増加

単一のWordPressサイトでは、プラグイン競合が1つのサイトを破壊します。プラグインを無効にしたり、診断したり、先に進んだりします。面倒ですが、管理できます。

Multisiteでは、ネットワークで有効化されたプラグインの競合がすべてのサイトを同時に破壊します。Multisiteネットワークで古いWooCommerceアップデートが23のロケーションページを破壊した場合を見ました。なぜなら、ネットワークで有効化されたキャッシュプラグインが新しいWooCommerceフックで更新されていなかったからです。破壊されたページを持つ23の場所。1つの根本的な原因、23人の怒ったロケーションマネージャーが同じ人に電話しています。

そしてここに落とし穴があります — 個々のサイト管理者は通常ネットワークで有効化されたプラグインを無効にすることはできません。彼らはスーパー管理者がそれを修正するまで待つ必要があります。

3. パフォーマンス低下

50個のサブサイトが1つのMySQLインスタンスを共有しています。サブサイト#47でのすべてのページロードは次のようなクエリを実行します：

SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);

一方、サブサイト#12はwp_12_posts、wp_12_options、wp_12_postmetaに対して独自のクエリセットを実行しています。そして、他のすべてのサブサイトと同じように、すべて同じMySQLインスタンスを攻撃しています。

MySQLのクエリプランナーは混乱します。テーブルキャッシュは満杯になります。各接頭辞付きテーブルは独自のインデックスを保持しますが、バッファプールは共有されています。パフォーマンスはサブサイトを追加するにつれて非線形に低下します。10から20のサブサイトに進むことは負荷が2倍ではありません — ロック競合とバッファプールスラッシングのため、トラフィックパターンに応じて3倍または4倍の負荷になる可能性があります。

40サブサイトのネットワークを一度ベンチマークしました。サブサイト#1の平均クエリ時間は45msでした。サブサイト#38をテストするまでに、平均クエリ時間は380msまで上昇していました。同じクエリ構造。サイトあたりのデータ量は同じです。データベースはテーブルに溺れていただけです。

4. 移行は悪夢

50サイトのネットワークからサブサイト#23を独立したスタンドアロンWordPressインストールに抽出してみてください。ここであなたがする必要があることは：

1. すべてのwp_23_接頭辞付きテーブルをエクスポートする
2. すべてのテーブルをwp_23_接頭辞からwp_接頭辞に再マップする
3. すべてのオプションとウィジェットデータを再シリアル化する（WordPressはデータベースに シリアル化されたPHPを保存し、接頭辞を変更するときに文字列の長さが変わります）
4. メディアパスを/uploads/sites/23/から/uploads/に再マップする
5. すべての内部URLの検索と置換
6. ユーザー機能をwp_23_capabilitiesからwp_usermetaのwp_capabilitiesに再マップする
7. 共有wp_usersテーブルからユーザーを抽出する（サブサイト#23に属するユーザーのみ）
8. ユーザーとサイトの関係を再作成する

シリアル化でエラーが発生し、破損したデータが得られます。ウィジェット設定が消えます。テーマカスタマイザーオプションが破壊されます。メニュー構造が消えます。このエクスプロイトプロセスを数十回実行していますが、WP Migrate DB Proなどのツールを使用してもサブサイトごとに4～8時間かかります。50個のサブサイトをネットワークから廃止しようとしている場合、それを50倍にしてください。

WordPressエコシステムにはこれ用のツールがあります、確かに。しかし、これらのツールが存在する必要があるという事実は、アーキテクチャについて何かを教えてくれます。

5. 真のデータ分離がない

セキュリティまたはコンプライアンスについて気にする場合、これはあなたを恐れさせるべき1つです。

サブサイト#2でのSQL インジェクション脆弱性は、wp_2_postsだけを公開しません。MySQLに接続しているデータベースユーザーは、データベース内のすべてのテーブルにアクセスできます。これはwp_posts（メインサイト）、wp_3_posts（サブサイト3）、wp_users（すべてのサイト全体の全ユーザー）、および他のすべてのテーブルを意味します。

データベースレベルの分離はありません。行レベルのセキュリティがありません。スキーマの分離がありません。WordPress Multisiteは1つのデータベース、1つの認証情報セット、および命名規則です。それだけです。

場所を越えてカスタマーデータを処理しているビジネスの場合 — 医療オフィス、法律事務所、金融サービス — これはコンプライアンスの問題です。HIPAA、SOC 2、PCI DSSはすべてデータ分離に関する要件があります。「異なるテーブル接頭辞を使用しました」は監査人を満足させるつもりはありません。

6. スーパー管理者ボトルネック

WordPress Multisiteには「スーパー管理者」という役割があります。スーパー管理者のみが以下を実行できます：

• プラグインをインストールまたは削除する
• テーマをインストールまたは削除する
• ネットワーク全体でプラグインをアクティブ化する
• ネットワークに新しいサイトを追加する
• ネットワーク設定を管理する

個々のサイト管理者には制限されたカパビリティがあります。彼らは独自のプラグインをインストールすることはできません。彼らは独自のテーマを追加することはできません。共有インフラストラクチャに触れるすべての変更は、1人（または小さなチーム）を通じてルーティングされます。

3サイトのネットワークでは、これは問題ありません。各ロケーションマネージャーが独自の予約ウィジェットまたはメニューPDFプラグインを追加したい50ロケーションのフランチャイズの場合？それは不満と影のITを生み出すボトルネックです。

7. ドメインマッピングの脆弱性

各場所が独自のドメインを持ちたいですか？denver.yourbrand.comまたはyourbrand-denver.com？WordPress Multisiteは、これを信頼できる方法でネイティブに処理しません。ドメインマッピングソリューションが必要です。組み込みのsunrise.php droppingアプローチは悪名高く不安定です。

マップされたドメインのSSL証明書は別のレイヤーを追加します。DNS構成が別のレイヤーを追加します。マップされたドメインはすべて、スーパー管理者が管理する別の失敗のポイントです。1つのDNS変更、1つの期限切れの証明書、1つの誤って構成されたマッピングエントリ、およびロケーションのサイトがダウンします。

WordPress Multisiteが実際に機能する場合

それが役に立たないふりはするつもりはありません。WordPress Multisiteは特定のシナリオで正常に機能します：

• **小さなネットワーク（10未満のサイト）**同じチームで管理されている場合
• 大学の部門サイト中央管理が実際に望まれる場合
• 開発/ステージング/本番ミラー同じプロジェクト用
• ブログネットワークコンテンツの分離が重要ではない場所

5～8個のサイトがあり、能力のあるシステム管理者がいて、サイト間のデータ分離が必要ない場合 — Multisiteは問題ありません。問題は、数十または数百の場所にスケーリングしようとするときに始まります。

実際に500の場所にスケールするアーキテクチャ

Social Animalで複数ロケーションのビジネスに使用する代替アプローチは、次のとおりです。Next.jsをフロントエンドに、Supabase（PostgreSQL）をバックエンドに使用したヘッドレスアーキテクチャ。行レベルセキュリティ（RLS）を使用した真のデータ分離。

コアアイデア：各ロケーションのテーブルを複製する代わりに、location_id列を持つ1つのテーブルセットがあります。データベースレベルのセキュリティポリシーにより、クエリが認可されたロケーションのデータのみを返すことが保証されます。500個の独立したふりをしている別のWordPressインストール、1つのアプリケーションデプロイメント、/locations/[slug]で各ロケーションのページをデータベース行から動的にレンダリングします。

行レベルセキュリティの実際の動作方法

-- ロケーションテーブルを作成する
CREATE TABLE locations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  slug TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  address TEXT,
  phone TEXT,
  hours JSONB,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- ロケーション分離を持つページテーブルを作成する
CREATE TABLE pages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  location_id UUID REFERENCES locations(id),
  title TEXT NOT NULL,
  content JSONB,
  slug TEXT NOT NULL,
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- RLSを有効にする
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- ポリシー：ロケーションマネージャーは独自のロケーションのページのみを表示できます
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- ポリシー：公的には任意のロケーションに対して公開されたページを読むことができます
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

このセットアップにより、デンバーのロケーションマネージャーが悪意のあるクエリを何らかの方法で作成したとしても、物理的にオースティンのデータにアクセスすることはできません。データベースが強制します。アプリケーションレイヤーではありません。命名規則ではありません。データベース自体。

アーキテクチャ比較：接頭辞付きテーブル対行レベルセキュリティ

2つのアーキテクチャを視覚的に表したものは以下の通りです：

WordPress Multisiteアーキテクチャ：

┌─────────────────────────────────────────────┐
│           単一MySQLデータベース              │
│                                             │
│  wp_posts          (メインサイト)            │
│  wp_options        (メインサイト)            │
│  wp_2_posts        (デンバー)                │
│  wp_2_options      (デンバー)                │
│  wp_3_posts        (オースティン)            │
│  wp_3_options      (オースティン)            │
│  wp_4_posts        (シアトル)                │
│  wp_4_options      (シアトル)                │
│  ... x 500 locations = 5,000+ tables       │
│                                             │
│  ⚠️  1つのDB認証情報セット                   │
│  ⚠️  1つのPHPプロセスがすべてのテーブルにアクセス │
│  ⚠️  ゼロのデータベースレベルの分離          │
└─────────────────────────────────────────────┘

Next.js + Supabaseアーキテクチャ：

┌─────────────────────────────────────────────┐
│         単一PostgreSQLデータベース           │
│                                             │
│  locations    (500行、ロケーションごとに1行)  │
│  pages        (ロケーションあたりのコンテンツ) │
│  media        (ロケーションあたりの画像)     │
│  staff        (ロケーションあたりのチーム)   │
│  reviews      (ロケーションあたりのレビュー) │
│                                             │
│  ✅  RLSポリシーが分離を強制します           │
│  ✅  デンバーユーザーはオースティンデータを照会できません │
│  ✅  5つのテーブル、5,000ではなく           │
│  ✅  標準インデックス、最適なクエリプラン   │
└─────────────────────────────────────────────┘

どちらの場合も1つのデータベース。しかし、分離モデルは根本的に異なります。RLSはPostgreSQLエンジンレベルで強制されます — これはアプリケーションがバイパスできるものではありません。

要因	WordPress Multisite	Next.js + Supabase
500ロケーションのテーブル	~5,500+	~5-15
データ分離	なし（命名規則のみ）	データベース適用RLS
脆弱性表面	1つのエクスプロイト = 全サイト	ロケーション単位の認証分離
プラグイン競合	ネットワーク全体の停止	N/A（プラグインアーキテクチャなし）
ロケーションの追加	サブサイト+構成を作成	データベース行を挿入
ロケーションの削除	複雑な抽出プロセス	カスケードで行を削除
ドメインマッピング	プラグイン必須、不安定	ミドルウェア書き直し、ネイティブ
ビルド/デプロイ時間	N/A（ランタイムPHP）	~30s増分ビルド
TTFB（平均、キャッシュなし）	800ms-2s+	50-150ms（エッジ）
月間ホスティング（500サイト）	$200-800/月（管理WP）	$25-75/月（Supabase + Vercel）
侵害からの回復	ネットワーク全体の修復	キーを回転、再デプロイ

実装：マルチロケーションサイト向けNext.js + Supabase

Next.jsでのルーティングの実際の動作方法を以下に示します：

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

export async function generateStaticParams() {
  const supabase = createClient();
  const { data: locations } = await supabase
    .from('locations')
    .select('slug');
  
  return locations?.map(({ slug }) => ({ slug })) ?? [];
}

export default async function LocationPage({ 
  params 
}: { 
  params: { slug: string } 
}) {
  const supabase = createClient();
  
  const { data: location } = await supabase
    .from('locations')
    .select(`
      *,
      pages(*),
      staff(*),
      reviews(*, rating)
    `)
    .eq('slug', params.slug)
    .single();
  
  if (!location) notFound();
  
  return (
    <div>
      <h1>{location.name}</h1>
      <LocationHero location={location} />
      <LocationServices pages={location.pages} />
      <LocationTeam staff={location.staff} />
      <LocationReviews reviews={location.reviews} />
    </div>
  );
}

新しいロケーションを追加しますか？行を挿入します：

INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
  'portland-or',
  'Portland, OR',
  '123 Burnside St, Portland, OR 97209',
  '(503) 555-0142',
  '{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);

それだけです。次のビルドがそれを拾います。または、ISR（増分静的再生成）を使用している場合、ビルドなしで再検証ウィンドウ内に表示されます。

ロケーションを削除しますか？DELETE FROM locations WHERE slug = 'portland-or'; カスケード削除は残りを処理します。4～8時間の抽出プロセスはありません。

ロケーションあたりのカスタムドメインの場合、Next.jsミドルウェアがそれをきれいに処理します：

// middleware.ts
import { NextResponse } from 'next/server';

const DOMAIN_MAP: Record<string, string> = {
  'yourbrand-denver.com': '/locations/denver-co',
  'yourbrand-austin.com': '/locations/austin-tx',
  // ... 本番環境でエッジ構成から読み込まれます
};

export function middleware(request: Request) {
  const hostname = new URL(request.url).hostname;
  const rewritePath = DOMAIN_MAP[hostname];
  
  if (rewritePath) {
    return NextResponse.rewrite(new URL(rewritePath, request.url));
  }
  
  return NextResponse.next();
}

プラグインなし。sunrise.phpドロップインなし。脆いマッピングテーブルなし。エッジでの書き直しルールだけです。

移行パス：WordPress Multisiteから脱出

現在20以上のロケーションでWordPress Multisiteを実行している場合、現実的な移行パスは次のとおりです：

フェーズ1：データエクスポート（1～2週間）

WordPress REST APIまたはWP-CLIを使用して、各サブサイトからコンテンツを抽出します。接頭辞付きテーブルを手動で再マップしようとしないでください。APIを使用します — それは接頭辞の悪夢を抽象化します。

# サブサイト23からすべてのポストをエクスポート
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# すべてのメディアをエクスポート
wp media list --url=example.com/location-23 --format=json > location-23-media.json

フェーズ2：スキーマ設計（1週間）

WordPress post/postmetaモデルではなく、実際のコンテンツモデルの周りにSupabaseスキーマを設計します。これは、数年間に蓄積されたデータモデルの技術的負債を修正する時点です。

フェーズ3：コンテンツ移行（1～2週間）

WordPress コンテンツを新しいスキーマに変換する移行スクリプトを作成します。シリアル化されたデータ、ショートコード、Gutenbergブロックを処理します。

フェーズ4：フロントエンドビルド（3～4週間）

Next.jsフロントエンドを構築します。これは実際のパフォーマンスゲインを見る場所です。WordPressで1.5秒かかったページが200ms未満で読み込まれるようになります。

フェーズ5：DNSカットオーバー（1日）

ドメインを新しいインフラストラクチャにポイントします。30日間、古いネットワークを読み取り専用バックアップとして実行状態に保ちます。

このプロセスの移行で支援が必要なビジネスの場合、ヘッドレスCMS開発ページで方法を文書化しました。20以上のサイトを持つネットワークで十分な移行を完了しているため、死体がどこに埋もれているかを知っています。

実数：パフォーマンスとコスト比較

Q1 2025で完了した実際の移行からのデータ — 34の場所を持つ歯科診療ネットワーク：

メトリック	WordPress Multisite（前）	Next.js + Supabase（後）
平均TTFB	1,240ms	89ms
最大コンテンツペイント	3.8s	1.1s
月間ホスティングコスト	$347/月（WP Engine）	$45/月（Vercel Pro + Supabase Pro）
新しいロケーションを追加する時間	2～3時間（手動セットアップ）	15分（行を挿入+コンテンツ）
すべてのロケーションを更新する時間	プラグインアップデート+祈り	git push
Core Web Vitals合格率	12の34ロケーション	34の34ロケーション
セキュリティインシデント（12ヶ月）	3	0

ホスティングコストの削減だけで8ヶ月以内に移行代金を回収しました。パフォーマンスの改善により、90日以内に34の場所中28のロケーション検索ランキングの測定可能な増加が促進されました。

独自のネットワークのコスト評価を行う場合、価格ページにはマルチロケーションプロジェクト用の透明な内訳があります。

FAQ

WordPress Multisiteは複数のロケーションを管理するのに適していますか？ 少数のロケーション（10未満）で中央管理されている場合、WordPress Multisiteは機能できます。ただし、独立した運営、データ分離、またはスケール時のハイパフォーマンスが必要なマルチロケーションビジネス用に設計されていません。共有データベースアーキテクチャは、追加するすべてのロケーションで複合する セキュリティ、パフォーマンス、および運用上の問題を作成します。

WordPress Multisiteの最大の問題は何ですか？ 7つの主な問題は、共有脆弱性表面（1つのエクスプロイトがすべてのサイトに当たります）、プラグイン競合の増加（1つの競合がすべてのサイトを取り down します）、非線形パフォーマンス低下、悪夢の移行/抽出プロセス、ゼロのデータベースレベルのデータ分離、すべての管理上の変更のためのスーパー管理者ボトルネック、および脆いドメインマッピングです。これらの問題はアーキテクチャ的なものです — プラグインやより良いホスティングで修正することはできません。

WordPress Multisiteは100以上のサイトを処理できますか？ 技術的には、はい。実際には、30～50のサイトを超えると非常に痛いです。100サイトでは、単一のMySQLインスタンスで1,100以上のデータベーステーブルを処理しており、深刻なクエリプランナー低下と、専用のDevOpsスタッフが必要な運用上の複雑さに対処しています。500サイトでは、ほとんどのホスティング環境では実行できません。

WordPress Multisiteの最良の代替案は何ですか複数のロケーション？ Next.jsまたはAstroをフロントエンドに使用し、PostgreSQLデータベース（Supabaseなど）を行レベルセキュリティで使用するヘッドレスアーキテクチャにより、真のデータ分離、劇的に優れたパフォーマンス、より低いホスティングコスト、および些細なロケーション管理が提供されます。各ロケーションはWordPressインストール全体ではなく、データベース行です。

WordPress Multisiteからヘッドレスアーキテクチャに移行するにはどうすればよいですか？ 最も安全なアプローチは、接頭辞付きデータベーステーブルを手動で再マップしようとするのではなく、WordPress REST APIまたはWP-CLIを使用してコンテンツを抽出することです。サブサイト単位でコンテンツをエクスポートし、対象データベースでクリーンなスキーマを設計し、変換スクリプトを作成し、新しいフロントエンドを構築し、DNSを削除します。20以上のサイトを持つネットワークの場合、合計6～10週間を計画します。

WordPress MultiSiteはSEOに影響しますか？ 間接的には、はい。WordPress Multisiteのパフォーマンス低下により、ページロードが遅くなり、Core Web Vitalsスコアが低下します。Googleはページエクスペリエンス信号がランキングに影響することを確認しています。移行データでは、ロケーションの82％がヘッドレスアーキテクチャに移行してから90日以内に改善されたローカル検索ランキングを見ました。

ビジネスデータの場合、WordPress Multisiteは安全ですか？ いいえ、セキュリティをロケーション間のデータ分離を含めて定義する場合。WordPress Multisiteは1つのデータベースを使用し、1つの認証情報セットを使用します。任意のサブサイトでのSQL インジェクション他のすべてのサブサイトのデータにアクセスできます。HIPAA、SOC 2、PCI DSSなどのコンプライアンス要件の対象となるビジネスの場合、データベースレベルの分離の欠如は重大な責任です。

WordPress Multisiteの実行とヘッドレス代替案のコストはどのくらいですか？ Multisiteの管理Wordpressホスティングは通常、サイト数とトラフィックレベルに応じて月額$200～$800かかります（WP Engineのマルチサイトプランは2025年に$240/月から始まります）。同等のヘッドレスセットアップは、Vercel Pro（$20/月）+Supabase Pro（$25/月）で同じトラフィックを分数で処理します。ヘッドレスアプローチの初期ビルド投資は高いですが、月間運営コストは大幅に低くなります。ネットワークサイズの特定のコスト比較については、お気軽にお問い合わせください。