في موقع WordPress التقليدي، يخزّن نظام واحد المحتوى ويعرض الصفحات أيضًا عبر قالب مكتوب بلغة PHP. أما في إعداد Headless فينفصل الدوران: يصبح WordPress واجهة خلفية للمحتوى فقط، وتجلب واجهة أمامية منفصلة، تُبنى غالبًا باستخدام Next.js أو Astro أو Nuxt، المحتوى عبر WordPress REST API أو WPGraphQL ثم تعرض الصفحات. يحتفظ المحررون بلوحة تحكم WordPress المألوفة، ولا يصل الزوار إلى WordPress مباشرة.
متى يكون منطقيًا
- يجب أن يصل المحتوى نفسه إلى قنوات عدة، مثل الموقع وتطبيق الجوال وشاشات المتاجر.
- تحتاج الواجهة الأمامية إلى تفاعلات تشبه التطبيقات أو أهداف أداء يصعب تحقيقها مع قالب ثقيل وإضافات كثيرة.
- مطوروك يعملون أصلًا باستخدام React أو إطار JavaScript آخر ويريدون تقنية واحدة للموقع والتطبيق.
- يجب أن يصمد الموقع أمام زيارات كثيفة. فالواجهة الأمامية المولّدة بشكل ثابت على CDN تستمر في تقديم الصفحات حتى لو تباطأ WordPress، ويمكن إبعاد لوحة إدارة WordPress عن النطاق العام.
ما الذي تتنازل عنه
كثير من إضافات WordPress تفترض أنها تتحكم في الواجهة الأمامية: منشئات الصفحات مثل Elementor، وإضافات النماذج، وشرائح العرض، وأدوات العضوية. وفي بناء Headless لا يظهر ناتجها على الموقع، فيجب إعادة بناء كل ميزة في الواجهة الأمامية أو استبدالها بشيء يتيح بياناته عبر الـ API. ويمكن لإضافات SEO مثل Yoast SEO إتاحة بياناتها الوصفية عبر REST API، لكن الواجهة الأمامية تظل مسؤولة عن إخراجها. كما تحتاج معاينة المسودات إلى إعداد إضافي، وتصبح لديك منظومتان بعمليتي نشر وفاتورتي استضافة.
متى تبقى مع WordPress التقليدي
لموقع شركة أو مدونة أو متجر WooCommerce يديره فريق تسويق يعتمد على منشئات الصفحات والإضافات، يكون القالب التقليدي المبني جيدًا مع استضافة وتخزين مؤقت مناسبين عادةً أسرع في البناء وأرخص في التشغيل وأسهل في التسليم. وكثير من مواقع WordPress البطيئة بطيئة بسبب قوالب متضخمة وإضافات كثيرة، لا بسبب WordPress نفسه، ويمكن إصلاح ذلك دون تغيير البنية.
اختر Headless عندما تكون للواجهة الأمامية احتياجات لا يلبيها قالب WordPress، لا لأن البنية تبدو حديثة.