عميل الامتياز الخاص بك يطلق الموقع الفرعي 247. ينشئ WordPress جداول wp_247_posts و wp_247_postmeta و wp_247_options — نفس الجداول الـ 12 التي أنشأتها للمواقع الفرعية 1 إلى 246. الآن لديك 2,964 جدول في قاعدة بيانات واحدة. تحديث المكون الإضافي يؤثر على جميعهم. استعلام على الموقع 118 ينافس الاستعلامات على المواقع 12 و 95 و 203. لوحة المراقبة الخاصة بك تظهر استنزاف مجموعة الاتصالات في الساعة 11:00 صباحاً كل يوم ثلاثاء. هذه ليست معمارية متعددة المواقع. هذا تثبيت WordPress واحد مع نسخ مرقمة من نفس المخطط، وله سبع عواقب توسع تنقطع عند حدود يمكن التنبؤ بها — الأول يصل حول الموقع 40.

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

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

WordPress Multisite Is Not Multi-Site: Architecture That Scales to 500 Locations

ما الذي يفعله 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              (main site)
wp_postmeta           (main site)
wp_options            (main site)
wp_users              (shared - all sites)
wp_usermeta           (shared - all sites)
wp_2_posts            (subsite 2)
wp_2_postmeta         (subsite 2)
wp_2_options          (subsite 2)
wp_3_posts            (subsite 3)
wp_3_postmeta         (subsite 3)
wp_3_options          (subsite 3)
...
wp_5_posts            (subsite 5)
wp_5_postmeta         (subsite 5)
wp_5_options          (subsite 5)

خمسة مواقع فرعية ولديك بالفعل حوالي 55 جدول. خمسون موقع فرعي؟ أنت تبحث عن أكثر من 500 جدول في قاعدة بيانات MySQL واحدة. 500 موقع؟ شمال من 5,000 جدول. في قاعدة بيانات واحدة. مشاركة مجموعة اتصال واحدة.

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

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

العواقب السبع لمعمارية Fake Multi-Site

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

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

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

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

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

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

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

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

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

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

50 موقع فرعي يشاركون مثيل 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. البحث والاستبدال لجميع العناوين الداخلية
  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 مواقع) حيث يتم إدارة جميع المواقع من قبل نفس الفريق
  • مواقع أقسام الجامعة حيث يكون التحكم المركزي مرغوباً فعلاً
  • مرايا Dev/staging/production للمشروع نفسه
  • شبكات المدونات حيث لا تكون عزلة المحتوى حرجة

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

WordPress Multisite Is Not Multi-Site: Architecture That Scales to 500 Locations - architecture

المعمارية التي تقاس بالفعل إلى 500 موقع

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

الفكرة الأساسية: بدلاً من نسخ الجداول لكل موقع، لديك مجموعة واحدة من الجداول بعمود location_id. تضمن سياسات أمان مستوى قاعدة البيانات أن الاستعلامات تُرجع فقط بيانات الموقع المصرح به. وبدلاً من 500 تثبيت WordPress منفصل متظاهر بأنها مستقلة، لديك انتشار تطبيق واحد حيث يقوم /locations/[slug] بتقديم صفحة كل موقع ديناميكياً من صف قاعدة البيانات.

كيف يعمل أمان مستوى الصف فعلاً

-- Create the locations table
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 the pages table with location isolation
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()
);

-- Enable RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Policy: location managers can only see their own location's pages
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- Policy: public can read published pages for any location
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

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

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

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

معمارية WordPress Multisite:

┌─────────────────────────────────────────────┐
│           قاعدة بيانات MySQL واحدة          │
│                                             │
│  wp_posts          (main site)              │
│  wp_options        (main site)              │
│  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 locations = 5,000+ tables       │
│                                             │
│  ⚠️  مجموعة بيانات اعتماد واحدة             │
│  ⚠️  عملية PHP واحدة تصل إلى جميع الجداول   │
│  ⚠️  صفر عزل مستوى قاعدة البيانات          │
└─────────────────────────────────────────────┘

معمارية Next.js + Supabase:

┌─────────────────────────────────────────────┐
│         قاعدة بيانات PostgreSQL واحدة       │
│                                             │
│  locations    (500 rows, one per location)  │
│  pages        (content per location)        │
│  media        (images per location)         │
│  staff        (team per location)           │
│  reviews      (reviews per location)        │
│                                             │
│  ✅  سياسات RLS تفرض العزلة                │
│  ✅  لا يمكن لمستخدم Denver الاستعلام عن Austin │
│  ✅  5 جداول فقط، وليس 5,000              │
│  ✅  فهارس قياسية، خطط استعلام مثالية     │
└─────────────────────────────────────────────┘

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

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

إزالة موقع؟ 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',
  // ... loaded from edge config in production
};

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 — فهو يجرد من مشكلة البادئة.

# Export all posts from subsite 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# Export all media
wp media list --url=example.com/location-23 --format=json > location-23-media.json

المرحلة 2: تصميم المخطط (1 أسبوع)

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

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

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

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

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

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

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

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

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

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

مقياس WordPress Multisite (قبل) Next.js + Supabase (بعد)
متوسط TTFB 1,240ms 89ms
رسم أكبر محتوى 3.8s 1.1s
تكلفة الاستضافة الشهرية $347/mo (WP Engine) $45/mo (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 موقع أنت تتعامل مع أكثر من 1,100 جدول قاعدة بيانات في مثيل MySQL واحد، وتدهور خطير في مخطط الاستعلام، وتعقيد التشغيل الذي يتطلب موظفي DevOps مكرسة. في 500 موقع، إنه غير قابل للبدء بالنسبة لمعظم بيئات الاستضافة.

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

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

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

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

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