على أي نظام تُشغّلون موقعكم في 2026

ظل اختيار نظام إدارة المحتوى سنوات طويلة سؤالًا عن الناس: من في الشركة سيحرّر الموقع، وإلى أي حد قد يُفسده. وفي 2026 صار لهذا السؤال قارئ ثانٍ. فالمساعدون ووكلاء البرمجة باتوا يكتبون الصفحات ويترجمونها ويعدّلونها، وكل أنواع الأنظمة يُعاد بناؤها، أو تُسوَّق، على أساس مدى انسجامها معهم. في ما يلي أين تقف السوق، وما الذي غيّره الذكاء الاصطناعي في كل ركن منها، وكيف كنا سنختار.

WordPress، ولا يزال الخيار الافتراضي

يشغّل WordPress نسبة 40.1 بالمئة من جميع المواقع، بحسب W3Techs في 13 أكتوبر 2026، و58.6 بالمئة من المواقع التي تستطيع W3Techs تحديد نظامها. ويليه Shopify بنسبة 5.4 بالمئة، ثم Wix بنسبة 4.2، وSquarespace بنسبة 2.4. وقرابة ثلث المواقع كلها، أي 31.6 بالمئة، لا يظهر فيها نظام لإدارة المحتوى تستطيع W3Techs رصده.

وقد أدخل WordPress الذكاء الاصطناعي إلى نواته. فالإصدار 7.0، الذي صدر في 20 مايو، أضاف عميلًا للذكاء الاصطناعي (AI Client) يتيح للموقع التخاطب مع النماذج التوليدية، مع إدارة الاتصالات من شاشة واحدة، وقرنه بواجهة Abilities API التي تصف الإضافات من خلالها ما تستطيع فعله. وتتولى إضافة اختيارية للذكاء الاصطناعي كتابة العناوين والمقتطفات، وتوليد الصور وتعديلها، واقتراح النص البديل.

لكن العبء القديم باقٍ. فقد أحصت Patchstack في 2025 عدد 11,334 ثغرة جديدة في منظومة WordPress، بزيادة 42 بالمئة عن 2024. وكان 91 بالمئة منها في الإضافات وست فقط في النواة، ولم يكن لـ 46 بالمئة منها إصلاح جاهز حين أُعلن عنها.

ولم يُحسم الصراع في القمة أيضًا. فقد بدأ في سبتمبر 2024، حين انتقد مات مولنويغ (Matt Mullenweg)، الذي يقود المشروع وشركة Automattic، علنًا شركة الاستضافة WP Engine لأنها تساهم بأقل مما ينبغي، وقطع وصولها إلى WordPress.org. ورفعت WP Engine دعوى في أكتوبر، وفي ديسمبر أمرت محكمة بإعادة وصولها. وفي 28 سبتمبر 2026 أفادت Search Engine Journal بأن القاضية سمحت بالمضي في دعاوى مكافحة الاحتكار الأربع كلها التي رفعتها WP Engine، فيما بقيت الدعاوى المضادة لـ Automattic قائمة هي الأخرى، جزئيًا على الأقل. وبعد عامين لا نتيجة بعد، بل قضية تطول فحسب.

أنظمة منفصلة عن الواجهة، مكتوبة للوكلاء

يُبقي نظام إدارة المحتوى المنفصل عن الواجهة (headless CMS) المحتوى بمعزل عن الموقع: مُدخلات منظّمة في مخزن واحد، تُسلَّم عبر واجهة برمجة (API) إلى موقع أو تطبيق أو أي جهة أخرى تطلبها. وأشهر الأسماء Sanity وContentful وStoryblok وPayload. وتضع W3Techs كلًّا من Sanity وStoryblok وPayload دون 0.1 بالمئة من المواقع، لكن هذه الإحصاءات تعجز عن رصدها جيدًا، لأن النظام المنفصل عن الواجهة يترك آثارًا قليلة على الصفحة النهائية.

ومنح الذكاء الاصطناعي هذه الأنظمة حجة جديدة. ففي مارس كتب ماغنوس هيليستاد (Magnus Hillestad)، الرئيس التنفيذي لـ Sanity: «صار المحتوى سياقًا. وصار السياق بنية تحتية.» ويرى أن الوكلاء الذين يجيبون العملاء أو يقدّمون عروض الأسعار يحتاجون إلى حقائق دقيقة، لا إلى صفحات يفسّرونها، وأن المحتوى ينبغي أن يصل إليهم عبر واجهات البرمجة وخوادم MCP، إلى جانب المواقع. إنه مقال من مورّد، لكن الفكرة تصمد في تجربتنا: فالوكيل يعمل مع حقول نظيفة أفضل بكثير مما يعمل مع صفحة من النص المنسّق.

والقطاع يتجه أيضًا نحو الاندماج. ففي يونيو 2025 انضمت Payload، وهي نظام مفتوح المصدر لإدارة المحتوى بُني لـ Next.js، إلى Figma. وتقول Payload إنها تبقى مفتوحة المصدر ويمكن مواصلة استضافتها ذاتيًا.

أدوات بناء تبدأ بجملة

وتستحوذ أدوات بناء المواقع على كثير مما تبقى: Wix وSquarespace للشركات الصغيرة، وWebflow بنسبة 0.8 بالمئة وFramer بنسبة 0.2 بالمئة للفرق التي يقودها التصميم، ومعظمها بات مزوّدًا بذكاء اصطناعي يصوغ مسودات التخطيطات والنصوص. وثمة مجموعة أحدث تبدأ من وصف بدلًا من قالب، وتملك Wix الآن إحداها، وهي Base44.

في أغسطس أعلنت Wix أن Base44 قادت نمو إيراداتها، لكنها أعلنت أيضًا أن Base44 دخلت العام بهامش ربح إجمالي معدَّل يقارب الصفر. ويهدف نموذجها الخاص، Base 1، إلى خفض تكلفة تشغيل الذكاء الاصطناعي، وتتوقع Wix هامشًا يقارب 60 بالمئة في النصف الثاني. وهذه إشارة مفيدة للمشتري. ففي رأينا، هذه الأدوات أسرع طريق إلى موقع أول، وأسعارها ستتبع قدرة الحوسبة التي تقف وراءها. وقبل أن يكبر الموقع، تحققوا مما يمكنكم أخذه معكم.

من دون نظام لإدارة المحتوى إطلاقًا

وعلى الطرف الآخر، تخلّت بعض الفرق عن نظام إدارة المحتوى. ففي ديسمبر 2025 نقل لي روبنسون (Lee Robinson)، الذي يعمل لدى Cursor، موقع cursor.com من نظام إدارة محتوى منفصل عن الواجهة إلى شيفرة بسيطة وملفات Markdown. كان يتوقع أن يستغرق ذلك من أسبوع إلى أسبوعين. ومع الوكلاء استغرق ثلاثة أيام، و344 طلبًا للوكلاء، و260.32 دولارًا من الرموز (tokens).

وسببه: «مع الذكاء الاصطناعي ووكلاء البرمجة، لم تكن كلفة التجريد يومًا أعلى مما هي الآن.» ففي المستودع يستطيع الوكيل تغيير أي ملف. أما خلف نظام إدارة المحتوى فعليه أن يمر عبر واجهة يملكها غيره.

وردّت Sanity، النظام الذي تركه، بأنه أعاد بناء نظام من هذا النوع: شاشة لإدارة الصور والملفات، وإدارة للمستخدمين عبر صلاحيات GitHub، وتحكم في الإصدارات عبر git، وأدوات للتوطين، ونموذج محتوى في الترويسة الأمامية (front matter) لملفات Markdown. وكتب كنوت ملفار (Knut Melvær) من Sanity: «المفارقة الغريبة هنا أننا نتفق نوعًا ما مع رأي لي.»

وكلاهما محق. فلموقع يديره مطورون، بمحررين قليلين وقائمة قصيرة من الصفحات، يكفي غالبًا مستودع ووكيل. أما لعشرين محررًا بخمس لغات، فالميزات التي عدّدتها Sanity هي صلب العمل.

ماذا كنا سنختار

ابدؤوا بثلاثة أسئلة. من يحرّر الموقع، وكم مرة. وكيف يُفحص التغيير قبل أن يُنشر، سواء أجراه شخص أو وكيل. ومن يملك المحتوى يوم تغادرون.

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

بنينا Studio للحالة الواقعة بينهما: فريق تسويق يحرّر كل يوم، ومعه وكلاء يساعدون. إنه نظام لإدارة المحتوى فوق مواقع مبنية بـ Next.js أو Vite أو TanStack، دون إضافات ودون PHP على الموقع العلني. ينقر المحررون على كلمة ليغيّروها، ويصوغ المساعد المسودة، ويقرر شخص. وكل نشر يُفحص، ويُبنى مرة واحدة، ويُختبر، ويُطلق، ويُتحقق منه، ويتراجع من تلقاء نفسه إذا أخفق أي شيء، ويودع المحتوى في مستودع الشركة نفسها. Studio في مرحلة الوصول المبكر.