WordPress Multisite ليست متعددة المواقع: البنية المعمارية التي تتسع لـ 500 موقع

WordPress Multisite يبدو أنك تحصل على مواقع متعددة. ما تحصل عليه فعلاً هو تثبيت WordPress واحد يتظاهر بأنه مواقع متعددة بإضافة رقم في مقدمة أسماء جداول قاعدة البيانات. الموقع الرئيسي يستخدم wp_posts. الموقع الفرعي 2 يستخدم wp_2_posts. الموقع الفرعي 3 يستخدم wp_3_posts. هذا ليس معمار متعدد المواقع. هذا قاعدة بيانات واحدة تحتوي على نسخ مرقمة من نفس الجداول. وله عواقب.

لقد قمت بترحيل شبكات بها 15 و 40 وحتى 87 موقع فرعي من WordPress Multisite. في كل مرة، اعتقد العميل أنه يحصل على مواقع مستقلة. وفي كل مرة، اكتشفوا بالطريقة الصعبة أنهم لم يكونوا كذلك. إذا كنت تقوم بتشغيل امتياز أو عمل متعدد المواقع أو شبكة قسم جامعي على WordPress Multisite، فهذه المقالة ستؤلمك قليلاً. لكن من الأفضل أن تعرف الآن بدلاً من بعد أن يوقف الموقع الفرعي #47 جميع الـ 46 الآخرين.

جدول المحتويات

• ما يفعله WordPress Multisite بالفعل تحت الغطاء
• العواقب السبع لمعمار متعدد المواقع المزيف
• متى يعمل WordPress Multisite (بصراحة)
• البنية المعمارية التي تتسع فعلاً لـ 500 موقع
• مقارنة البنية المعمارية: الجداول ذات البادئات مقابل أمان مستوى الصف
• التنفيذ: Next.js + Supabase للمواقع متعددة المواقع
• مسار الترحيل: الخروج من WordPress Multisite
• أرقام حقيقية: مقارنة الأداء والتكلفة
• الأسئلة الشائعة

ما يفعله WordPress Multisite بالفعل تحت الغطاء

دعنا ننظر إلى ما يحدث عندما تقوم بتفعيل Multisite في WordPress. تضيف بعض الأسطر إلى 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)

خمسة مواقع فرعية ولديك بالفعل حوالي 55 جدول. خمسين موقع فرعي؟ أنت تنظر إلى أكثر من 500 جدول في قاعدة بيانات MySQL واحدة. خمسمائة موقع؟ أكثر من 5000 جدول. في قاعدة بيانات واحدة. تشترك في مجموعة اتصال واحدة.

لكل جدول فهارسه الخاصة. كل استعلام يستهدف جدول ذو بادئة محددة. منسق الاستعلام يجب أن يتعامل مع كل هذا. وكل واحد من هذه الجداول يمكن الوصول إليه من قبل أي عملية PHP تعمل على هذا الخادم، لأنها جميعها في نفس قاعدة البيانات بنفس بيانات الاعتماد.

هذا ليس معمار متعدد المواقع. هذا اتفاقية تسمية تتظاهر بأنها عزلة.

العواقب السبع لمعمار متعدد المواقع المزيف

1. سطح الضعف المشترك

كل موقع فرعي في شبكة WordPress Multisite يشغل نفس نواة WordPress وننفس المكونات الإضافية والمواضيع نفسها. استغلال مكون إضافي واحد يضر جميع المواقع الفرعية لأنها تشارك نفس أساس الكود.

هذا ليس نظري. في فبراير 2026، كان لدى WPVivid — مكون إضافي للنسخ الاحتياطي بأكثر من 900000 تثبيت نشط — اكتشاف ثغرة RCE (تنفيذ الكود من بعيد) بشدة 9.8. الشدة 9.8 من 10. هذا عبارة عن "يمكن للمهاجم غير المصرح به تنفيذ كود عشوائي على خادمك".

على موقع WordPress مستقل، هذا موقع واحد مخترق. على شبكة Multisite بها 30 موقع فرعي؟ هذا 30 موقع فرعي مخترق. نفس الخادم. نفس قاعدة البيانات. نفس نظام الملفات. استغلال واحد، تسوية الشبكة الكاملة.

لا يمكنك تثبيت نسخة مختلفة من مكون إضافي على الموقع الفرعي #12 من الموقع الفرعي #13. لا يمكنك وضع مكونات إضافية لموقع واحد في صندوق رمل بعيداً عن موقع آخر. كل موقع يحصل على نفس سطح الهجوم.

2. تضاعف تضارب المكونات الإضافية

على موقع WordPress واحد، يؤدي تضارب المكون الإضافي إلى كسر موقع واحد. تقوم بإلغاء تفعيل المكون الإضافي وتشخيص والمضي قدماً. مزعج لكنه قابل للإدارة.

على Multisite، يؤدي تضارب مكون إضافي مفعّل على مستوى الشبكة إلى كسر كل موقع في نفس الوقت. لقد رأيت تحديث WooCommerce على شبكة Multisite يوقف 23 صفحة موقع في نفس الوقت لأن مكون إضافي للتخزين المؤقت مفعّل على مستوى الشبكة لم يتم تحديثه لخطافات WooCommerce الجديدة. ثلاثة وعشرون موقع بصفحات مكسورة. سبب جذري واحد، ثلاثة وعشرون مدير موقع غاضب يتصلون بنفس الشخص.

وإليك الحقيقة المرة — لا يستطيع مسؤولو الموقع الفردي عادةً إلغاء تفعيل المكونات الإضافية المفعّلة على مستوى الشبكة. يجب عليهم الانتظار حتى يقوم Super Admin بإصلاح الأمر.

3. تدهور الأداء

خمسين موقع فرعي يتشاركون مثيل 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 موقع فرعي ليس ضعف الحمل — يمكن أن يكون ثلاث أو أربع مرات الحمل اعتماداً على أنماط حركة المرور، بسبب تنازع القفل وإهدار مجموعة المخزن المؤقت.

قمت بقياس شبكة بها 40 موقع فرعي مرة واحدة. متوسط وقت الاستعلام على الموقع الفرعي #1 كان 45 مللي ثانية. بحلول الوقت الذي اختبرنا فيه الموقع الفرعي #38، كان متوسط وقت الاستعلام قد ارتفع إلى 380 مللي ثانية. نفس هيكل الاستعلام. نفس حجم البيانات لكل موقع. كانت قاعدة البيانات تختنق فقط في الجداول.

4. الترحيل كابوس

جرب استخراج الموقع الفرعي #23 من شبكة بها 50 موقع إلى تثبيت WordPress مستقل. إليك ما تحتاج إلى القيام به:

1. تصدير جميع جداول البادئة wp_23_
2. إعادة تعيين كل جدول من بادئة wp_23_ إلى بادئة wp_
3. إعادة تسلسل جميع خيارات وبيانات الأداة (يخزن WordPress PHP المسلسل في قاعدة البيانات، وتتغير أطوال السلاسل عندما تقوم بتغيير البادئات)
4. إعادة تعيين مسارات الوسائط من /uploads/sites/23/ إلى /uploads/
5. البحث والاستبدال لجميع عناوين URL الداخلية
6. إعادة تعيين قدرات المستخدم من wp_23_capabilities إلى wp_capabilities في wp_usermeta
7. استخراج المستخدمين من جدول wp_users المشترك (فقط الذين ينتمون إلى الموقع الفرعي #23)
8. إعادة إنشاء علاقات المستخدم بالموقع

خطأ واحد في التسلسل والحصول على بيانات تالفة. تختفي إعدادات الأداة. تنكسر خيارات مخصص المظهر. تختفي هياكل القائمة. لقد قمت بعملية الاستخراج هذه عشرات المرات، وتستغرق 4-8 ساعات لكل موقع فرعي حتى مع أدوات مثل WP Migrate DB Pro. اضرب هذا في 50 موقع فرعي إذا كنت تقوم بإيقاف شبكة.

يمتلك النظام البيئي WordPress أدوات لهذا بالتأكيد. لكن حقيقة أن هذه الأدوات تحتاج إلى الوجود تخبرك شيئاً عن المعمار.

5. لا عزلة بيانات حقيقية

هذا هو الذي يجب أن يرعبك إذا كنت تهتم بالأمان أو الامتثال.

ثغرة حقن SQL على الموقع الفرعي #2 لا تعرض فقط wp_2_posts. مستخدم قاعدة البيانات الذي يتصل بـ MySQL لديه وصول إلى كل جدول في قاعدة البيانات. هذا يعني wp_posts (الموقع الرئيسي)، wp_3_posts (الموقع الفرعي 3)، wp_users (جميع المستخدمين عبر جميع المواقع)، وكل جدول آخر.

لا توجد عزلة على مستوى قاعدة البيانات. لا أمان على مستوى الصف. لا فصل البيانات. WordPress Multisite هي قاعدة بيانات واحدة وبيانات اعتماد واحدة واتفاقية تسمية. هذا كل شيء.

بالنسبة للشركات التي تتعامل مع بيانات العملاء عبر المواقع — العيادات الطبية والمكاتب القانونية والخدمات المالية — هذه مشكلة الامتثال. HIPAA و SOC 2 و PCI DSS كل منها لديه متطلبات حول عزل البيانات. "استخدمنا بادئات جداول مختلفة" لن تقنع المدقق.

6. اختناق Super Admin

يحتوي WordPress Multisite على دور يسمى Super Admin. يمكن فقط لـ Super Admin:

• تثبيت أو حذف المكونات الإضافية
• تثبيت أو حذف المواضيع
• تفعيل المكونات الإضافية على مستوى الشبكة
• إضافة مواقع جديدة إلى الشبكة
• إدارة إعدادات الشبكة

مسؤولو الموقع الفردي لديهم قدرات مقيدة. لا يمكنهم تثبيت مكوناتهم الخاصة. لا يمكنهم إضافة مواضيعهم الخاصة. كل تغيير يمس البنية التحتية المشتركة يسير من خلال شخص واحد (أو فريق صغير).

بالنسبة لشبكة مكونة من 3 مواقع، هذا على ما يرام. بالنسبة لامتياز بـ 50 موقع حيث يريد كل مدير موقع إضافة أداة حجز خاصة به أو مكون إضافي لقائمة PDF؟ إنه اختناق يولد الاستياء و IT الظلية.

7. فراغية رسم خريطة المجال

هل تريد لكل موقع أن يكون له مجاله الخاص؟ denver.yourbrand.com أو yourbrand-denver.com؟ WordPress Multisite لا يتعامل مع هذا بشكل أصلي بطريقة موثوقة. تحتاج إلى حل رسم خريطة المجال، ونهج sunrise.php dropin المدمج سيء بشكل مشهور.

شهادات SSL للمجالات المعاد تعيينها تضيف طبقة أخرى. تكوين DNS يضيف آخر. كل مجال معاد تعيين هو نقطة فشل محتملة أخرى يجب أن يدير Super Admin. تغيير DNS واحد أو شهادة منتهية الصلاحية أو إدخال رسم خريطة خاطئ، وموقع الموقع ينخفض.

متى يعمل WordPress Multisite (بصراحة)

لن أتظاهر أنه عديم الفائدة. WordPress Multisite يعمل بشكل جيد في سيناريوهات محددة:

• الشبكات الصغيرة (أقل من 10 مواقع) حيث يتم إدارة جميع المواقع من قبل نفس الفريق
• مواقع قسم الجامعة حيث يكون التحكم المركزي مرغوباً فيه فعلاً
• مرايا التطوير/التدريج/الإنتاج لنفس المشروع
• شبكات المدونات حيث لا يكون عزل المحتوى حرجاً

إذا كان لديك 5-8 مواقع وسيسادمن كفء ولا تحتاج إلى عزل البيانات بين المواقع — Multisite على ما يرام. تبدأ المشاكل عندما تحاول توسيع نطاقها إلى عشرات أو مئات المواقع.

البنية المعمارية التي تتسع فعلاً لـ 500 موقع

إليك نهج بديل نستخدمه في Social Animal للشركات متعددة المواقع: معمار بدون رأس مع Next.js في الواجهة الأمامية و Supabase (PostgreSQL) في الخلفية، باستخدام Row-Level Security (RLS) لعزل البيانات الحقيقي.

الفكرة الأساسية: بدلاً من تكرار الجداول لكل موقع، لديك مجموعة جداول واحدة بعمود location_id. تضمن سياسات أمان على مستوى قاعدة البيانات أن الاستعلامات تعيد البيانات فقط للموقع المصرح به. وبدلاً من 500 تثبيت WordPress منفصل يتظاهر بأنه مستقل، لديك نشر تطبيق واحد حيث يعيد /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);

بهذا الإعداد، مدير موقع في Denver الذي يصيغ بطريقة ما استعلاماً خبيثاً لا يمكنه فعلاً الوصول إلى بيانات Austin. قاعدة البيانات تفرضه. ليس طبقة التطبيق. ليس اتفاقية تسمية. قاعدة البيانات نفسها.

مقارنة البنية المعمارية: الجداول ذات البادئات مقابل أمان مستوى الصف

إليك تمثيل مرئي للمعمارتين:

معمار WordPress Multisite:

┌─────────────────────────────────────────────┐
│      قاعدة بيانات MySQL واحدة              │
│                                             │
│  wp_posts          (الموقع الرئيسي)         │
│  wp_options        (الموقع الرئيسي)         │
│  wp_2_posts        (Denver)                 │
│  wp_2_options      (Denver)                 │
│  wp_3_posts        (Austin)                 │
│  wp_3_options      (Austin)                 │
│  wp_4_posts        (Seattle)                │
│  wp_4_options      (Seattle)                │
│  ... x 500 موقع = 5000+ جدول              │
│                                             │
│  ⚠️  بيانات اعتماد قاعدة بيانات واحدة       │
│  ⚠️  عملية PHP واحدة تصل إلى جميع الجداول   │
│  ⚠️  عزلة على مستوى قاعدة البيانات = صفر    │
└─────────────────────────────────────────────┘

معمار Next.js + Supabase:

┌─────────────────────────────────────────────┐
│    قاعدة بيانات PostgreSQL واحدة            │
│                                             │
│  locations    (500 صف، واحد لكل موقع)       │
│  pages        (محتوى لكل موقع)              │
│  media        (صور لكل موقع)                │
│  staff        (فريق لكل موقع)               │
│  reviews      (تقييمات لكل موقع)            │
│                                             │
│  ✅  سياسات RLS تفرض العزلة                 │
│  ✅  مستخدم Denver لا يمكنه الاستعلام عن    │
│      بيانات Austin                         │
│  ✅  5 جداول إجمالاً، وليس 5000             │
│  ✅  فهارس قياسية، خطط استعلام مثلى          │
└─────────────────────────────────────────────┘

قاعدة بيانات واحدة في كلتا الحالتين. لكن نموذج العزلة مختلف بشكل أساسي. يتم فرض RLS على مستوى محرك PostgreSQL — إنه ليس شيئاً يمكن للتطبيق تجاوزه.

العامل	WordPress Multisite	Next.js + Supabase
الجداول عند 500 موقع	~5500+	~5-15
عزل البيانات	لا (اتفاقية تسمية فقط)	RLS مفروض من قاعدة البيانات
سطح الضعف	استغلال واحد = جميع المواقع	عزل المصادقة لكل موقع
تضارب المكونات الإضافية	انقطاع على مستوى الشبكة	غير قابل للتطبيق (لا بنية مكونات إضافية)
إضافة موقع	إنشاء موقع فرعي + إعداد	إدراج صف قاعدة بيانات
إزالة موقع	عملية استخراج معقدة	حذف الصفوف مع CASCADE
رسم خريطة المجال	مكون إضافي مطلوب، هش	إعادة كتابة البرنامج الوسيط، أصلي
وقت البناء/النشر	غير قابل للتطبيق (PHP في وقت التشغيل)	~30 ثانية بناء متزايد
TTFB (متوسط، بدون تخزين مؤقت)	800ms-2s+	50-150ms (edge)
الاستضافة الشهرية (500 موقع)	$200-800/شهر (WordPress مُدار)	$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 dropin. لا قواعد رسم خريطة هشة. فقط قاعدة إعادة كتابة على الحافة.

مسار الترحيل: الخروج من WordPress Multisite

إذا كنت حالياً على WordPress Multisite مع 20+ موقع، إليك مسار الترحيل الواقعي:

المرحلة 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: تصميم البيانات (أسبوع واحد)

صمم مخطط Supabase حول نموذج المحتوى الفعلي الخاص بك، وليس نموذج post/postmeta في WordPress. هذه هي اللحظة المناسبة لإصلاح سنوات من التراكم في نموذج البيانات.

المرحلة 3: ترحيل المحتوى (1-2 أسبوع)

اكتب نصوص الترحيل التي تحول محتوى WordPress إلى مخطط جديد. تعامل مع البيانات المسلسلة والعلامات القصيرة وكتل Gutenberg.

المرحلة 4: بناء الواجهة الأمامية (3-4 أسابيع)

بناء الواجهة الأمامية في Next.js. هذا حيث ترى المكاسب الفعلية في الأداء. الصفحات التي استغرقت 1.5 ثانية على WordPress الآن تحمل في أقل من 200 ميلي ثانية.

المرحلة 5: قطع DNS (يوم واحد)

أشر بمجالاتك نحو البنية التحتية الجديدة. احتفظ بالشبكة القديمة تعمل للقراءة فقط لمدة 30 يوماً.

بالنسبة للشركات التي تحتاج إلى مساعدة في عملية الترحيل هذه، قمنا بتوثيق نهجنا على صفحة تطوير CMS بدون رأس. لقد قمنا بعدد كافٍ من ترحيل لمعرفة أين تم دفن الأجساد.

أرقام حقيقية: مقارنة الأداء والتكلفة

إليك البيانات من ترحيل فعلي أكملناه في Q1 2025 — شبكة عيادات أسنان مع 34 موقع:

المقياس	WordPress Multisite (قبل)	Next.js + Supabase (بعد)
متوسط TTFB	1240 ميلي ثانية	89 ميلي ثانية
أكبر رسم محتوى	3.8 ثانية	1.1 ثانية
تكلفة الاستضافة الشهرية	$347/شهر (WP Engine)	$45/شهر (Vercel Pro + Supabase Pro)
الوقت المستغرق لإضافة موقع جديد	2-3 ساعة (إعداد يدوي)	15 دقيقة (إدراج صف + محتوى)
الوقت المستغرق لتحديث جميع المواقع	تحديث المكون الإضافي + الصلاة	git push
معدل اجتياز Core Web Vitals	12 من 34 موقع	34 من 34 موقع
حوادث الأمان (12 شهر)	3	0

وحده انخفاض تكاليف الاستضافة أموال الترحيل في غضون 8 أشهر. أدت تحسينات الأداء إلى زيادات ملحوظة في ترتيب البحث المحلي لـ 28 من 34 موقع في غضون 90 يوماً.

إذا كنت تقيم التكاليف لشبكتك الخاصة، فإن صفحة التسعير لدينا تحتوي على تفاصيل شفافة لمشاريع متعددة المواقع.

الأسئلة الشائعة

هل WordPress Multisite جيد لإدارة مواقع متعددة؟ بالنسبة لعدد صغير من المواقع (أقل من 10) مع إدارة مركزية، يمكن أن يعمل WordPress Multisite. لكنه لم يكن مصمماً للشركات متعددة المواقع التي تحتاج إلى تشغيل مستقل أو عزل البيانات أو أداء عالي في الحجم. معمار قاعدة البيانات المشترك ينشئ مشاكل أمان وأداء وتشغيلية تتفاقم مع كل موقع تضيفه.

ما أكبر المشاكل مع WordPress Multisite؟ المشاكل السبع الرئيسية هي: سطح الضعف المشترك (استغلال واحد يضر جميع المواقع)، تضاعف تضارب المكونات الإضافية (تضارب واحد يوقف كل موقع)، تدهور الأداء غير الخطي، عمليات ترحيل/استخراج كابوس، عدم وجود عزلة بيانات على مستوى قاعدة البيانات، اختناق Super Admin لجميع التغييرات الإدارية، ورسم خريطة مجال هش. هذه المشاكل معمارية — لا يمكن إصلاحها بمكونات إضافية أو استضافة أفضل.

هل يمكن لـ WordPress Multisite التعامل مع 100+ موقع؟ تقنياً، نعم. عملياً، يصبح مؤلماً جداً بعد 30-50 موقع. في 100 موقع، أنت تتعامل مع 1100+ جدول قاعدة بيانات في مثيل MySQL واحد، وتدهور خطير لمخطط الاستعلام، وتعقيد تشغيلي يتطلب موظفي DevOps مخصصين. عند 500 موقع، إنه غير قابل للبدء بالنسبة لمعظم بيئات الاستضافة.

ما البديل الأفضل لـ WordPress Multisite للمواقع المتعددة؟ معمار بدون رأس باستخدام Next.js أو Astro للواجهة الأمامية مع قاعدة بيانات PostgreSQL (مثل Supabase) باستخدام Row-Level Security يوفر عزل بيانات حقيقي وأداء أفضل بكثير وتكاليف استضافة أقل وإدارة موقع تافهة. كل موقع هو صف قاعدة بيانات، وليس تثبيت WordPress كامل.

كيف تترحل من WordPress Multisite إلى معمار بدون رأس؟ الطريقة الأكثر أماناً هي استخراج المحتوى عبر WordPress REST API أو WP-CLI بدلاً من محاولة إعادة تعيين جداول البادئة يدوياً. تصدير المحتوى لكل موقع فرعي، وتصميم مخطط نظيف في قاعدة البيانات الهدف، وكتابة نصوص تحويل، وبناء الواجهة الأمامية الجديدة، وقطع DNS. خطط 6-10 أسابيع إجمالاً لشبكة بها 20+ موقع.

هل WordPress Multisite تؤثر على SEO؟ بشكل غير مباشر، نعم. يؤدي تدهور الأداء في WordPress Multisite إلى تحميل صفحات أبطأ، مما يؤثر على درجات Core Web Vitals. أكد Google أن إشارات تجربة الصفحة تؤثر على الترتيب. في بيانات الترحيل لدينا، شهدت 82% من المواقع تحسينات في ترتيب البحث المحلي في غضون 90 يوماً من الانتقال إلى معمار بدون رأس مع TTFB أقل من 200 ميلي ثانية.

هل WordPress Multisite آمن لبيانات الأعمال؟ لا، إذا حددت الأمان على أنه يشمل عزل البيانات بين المواقع. WordPress Multisite تستخدم قاعدة بيانات واحدة بمجموعة بيانات اعتماد واحدة. حقن SQL على أي موقع فرعي يمكنه الوصول إلى بيانات كل موقع فرعي آخر. بالنسبة للشركات الخاضعة لمتطلبات HIPAA أو SOC 2 أو PCI DSS أو ما شابه، فإن نقص عزل البيانات على مستوى قاعدة البيانات هو مسؤولية كبيرة.

كم يكلف تشغيل WordPress Multisite مقابل بديل بدون رأس؟ الاستضافة المدارة لـ WordPress Multisite عادةً ما تتراوح بين $200-800/شهر حسب عدد المواقع ومستويات حركة المرور (خطط Multisite في WP Engine تبدأ من $240/شهر لـ Growth tier في 2025). إعداد بدون رأس قابل للمقارنة على Vercel Pro ($20/شهر) بالإضافة إلى Supabase Pro ($25/شهر) يتعامل مع نفس حركة المرور بجزء صغير من التكلفة. استثمار البناء الأولي أعلى للنهج بدون رأس، لكن تكاليف التشغيل الشهرية أقل بشكل كبير. لا تتردد في التواصل إذا كنت تريد مقارنة تكاليف محددة لحجم الشبكة الخاصة بك.