Headless WordPress को Next.js या Astro पर चलाएँ, wp-admin रखें, plugin के भार से बचें।

Headless WordPress तभी सही है जब तीन बातों में से एक सच हो। डिफ़ॉल्ट क्लासिक WordPress सेटअप अन्यथा गलत है, headless इंजीनियरिंग का ओवरहेड जोड़ता है और आपको इसके लिए असली कारण के बिना पैसे नहीं देने चाहिए।

पहला कारण परफॉर्मेंस है। एक वेनिला WordPress साइट जिसमें पाँच या छह प्लगइन हों, वह H1 रेंडर होने से पहले लगभग सात सौ किलोबाइट JavaScript भेजती है, और Elementor या Divi के साथ एक आम एडऑन स्टैक होने पर, असली दुनिया की साइटें पहले लोड पर दो से तीन मेगाबाइट भेजती हैं। Lighthouse और CrUX फील्ड डेटा पर एक कठोर सीमा है, चाहे सामने सबसे अच्छा कैशिंग प्लगइन हो। Headless एक स्टैटिक या ISR Next.js या Astro फ्रंट-एंड पर लगातार नब्बे-पाँच से ऊपर Lighthouse क्लियर करता है और फील्ड डेटा उसके अनुसार आता है।

दूसरा कारण संपादकीय टीम को खोए बिना इंजीनियरिंग अनुभव है। इंजीनियर जो रोज़ TypeScript लिखते हैं, WordPress फ्रंट-एंड स्टैक से निराश हो जाते हैं। PHP टेम्पलेट, jQuery, पेज बिल्डर शॉर्टकोड, भाषा गलत है, टूलिंग गलत है, डिप्लॉय की कहानी गलत है। Headless इंजीनियरिंग टीम को Next.js या Astro कोडबेस में काम करने देता है, version control के साथ, type checking के साथ, edge deployment के साथ, और component-driven design के साथ, जबकि संपादक wp-admin, Yoast, और ACF को वैसे ही रखते हैं।

तीसरा कारण मल्टी-डेस्टिनेशन है। एक मार्केटिंग साइट, एक मोबाइल ऐप, एक आंतरिक पोर्टल, और एक पार्टनर पोर्टल सभी एक ही कंटेंट स्रोत से डेटा ले रहे हों। क्लासिक WordPress एक CMS है, एक फ्रंट-एंड है। Headless WordPress संपादकीय बैक-एंड बन जाता है जो भी गंतव्य आप चाहें, प्रत्येक का अपना फ्रंट-एंड फ्रेमवर्क अपनी सतह के लिए अनुकूलित।

तीन फैसले engineering की ज़्यादातर story decide करते हैं।

फ्रंट-एंड फ्रेमवर्क आमतौर पर Next.js होता है जिसमें App Router marketing साइटों और auth या interactivity वाले ऐप्स के लिए। Astro content-heavy साइटों के लिए सबसे सरल रास्ता है जो static generation से लाभान्वित होती हैं और केवल विशिष्ट components पर partial hydration चाहती हैं। Nuxt सही विकल्प है जब टीम पहले से Vue चलाती है। हम Faust.js की जगह Next.js plus WPGraphQL plus छोटे custom scaffolding को default करते हैं, क्योंकि Faust ऐसी opinions भेजता है जिनसे हम कभी-कभी असहमत हैं, लेकिन Faust उत्कृष्ट है अगर आप फ्रेमवर्क को निर्णय लेने देना चाहते हैं।

API लेयर डिफॉल्ट रूप से WPGraphQL है। टाइप्ड क्वेरी-बाई-शेप API, ACF WPGraphQL फॉर ACF के ज़रिए समर्थन, Yoast समर्थन Yoast SEO फॉर WPGraphQL के ज़रिए, RankMath के बराबर। WP REST बिना प्लगइन के काम करता है और सरल साइटों के लिए ठीक है, लेकिन आप ज़्यादा डेटा फेच करते हैं जितने की ज़रूरत है और फ्रंट-एंड पर कोई स्कीमा इंट्रोस्पेक्शन नहीं है। REST तक सिर्फ तभी पहुँचें जब WPGraphQL होस्टिंग पॉलिसी से ब्लॉक हो या जब आपके पास बहुत छोटा डेटासेट हो।

होस्टिंग फ्रंट-एंड को बैक-एंड से अलग करती है। फ्रंट-एंड Vercel, Netlify, या Cloudflare Pages पर टीम की पसंद के अनुसार। बैक-एंड Cloudways, Kinsta, या WP Engine पर एक non-public subdomain पर, cms.yourdomain.com, Cloudflare Access या IP allowlist के पीछे लॉक किया हुआ। सार्वजनिक ट्रैफ़िक कभी सीधे WordPress से नहीं टकराता। WordPress सार्वजनिक वेब से अदृश्य हो जाता है; केवल आपके संपादक जानते हैं कि यह वहाँ है।

एक सफल headless WordPress बिल्ड WordPress की ओर से पाँच चीज़ें सार्वजनिक फ्रंट-एंड में पहुँचाता है बिना बीच में कोई नुकसान किए।

कंटेंट स्पष्ट है, हर post, page, custom post type, taxonomy, और ACF फील्ड, WPGraphQL के माध्यम से build या revalidation पर fetch किए जाते हैं। मीडिया अगला है: हर अपलोड की गई छवि, WordPress-साइड WebP optimization के साथ अगर उपलब्ध हो या अन्यथा फ्रंट-एंड-साइड image optimization के साथ। SEO metadata तीसरा है, Yoast या Rank Math फील्ड plugin-companion GraphQL schemas के माध्यम से bridged, canonical, title, description, OG, और Twitter card के रूप में typed response से rendered।

Schema चौथा है और ज्यादातर टीमें इसे गलत तरीके से संभालती हैं। हम plugin-emitted JSON-LD को hand-written templates से फ्रंट-एंड पर साफ़ output के लिए बदलते हैं। Article, BlogPosting, Service, Product, BreadcrumbList, सभी typed data से generated, build time पर validated। Redirects पाँचवाँ है: Yoast Redirect Manager या Redirection plugin में कुछ भी exported होता है और 301s के रूप में vercel.json में या Netlify पर _redirects में shipped होता है, कभी JavaScript redirects के रूप में नहीं जो transit में ranking signal खो देते हैं।

ट्रांसपोर्ट स्वचालित है। हम इनमें से किसी भी लेयर को प्रति साइट हाथ से बिल्ड नहीं करते। एक ही स्कैफोल्डिंग हर headless बिल्ड में भेजी जाती है जो हम करते हैं, इसीलिए प्रति-साइट लागत समय के साथ कम आई है भले ही इंजीनियरिंग सतह बढ़ गई है।

पेज बिल्डर पहले टूटते हैं। Elementor और Divi फ्रंट-एंड में heavy CSS और HTML inject करते हैं। उनमें से कोई भी headless फ्रंट-एंड पर नहीं चलता। ज्यादातर migrations project के हिस्से के रूप में content rewrite ship करते हैं, हम content निकालते हैं, इसे नए फ्रंट-एंड के component library से match करने के लिए reformat करते हैं, और visual builder layer को पूरी तरह से import करना छोड़ देते हैं। संपादक को Gutenberg blocks plus ACF flexible content पर आधारित एक नया, सरल editing UX मिलता है। कंटेंट बचता है, visual builder नहीं, और page weight एक side effect के रूप में significantly गिरता है।

कमेंट्स और फॉर्म्स को भी दोबारा सोचना पड़ता है। नेटिव WordPress कमेंट्स रेंडरिंग को प्रॉक्सी किए बिना headless पर रेंडर नहीं होते। ज्यादातर टीमें उन्हें Disqus, Giscus, या फ्रंट-एंड पर कस्टम कमेंट सिस्टम से बदल देती हैं। फॉर्म्स आमतौर पर ConvertKit, HubSpot Forms, या एक कस्टम Next.js एंडपॉइंट पर माइग्रेट होते हैं जो एक ईमेल-सेंडिंग सर्विस को hit करता है। Contact Form 7 और Gravity Forms के headless-फ्रेंडली वर्जन हैं लेकिन एक्सप्लिसिट GraphQL इंटीग्रेशन की जरूरत होती है जो काम बढ़ाता है।

फ्रंट-एंड plugins तीसरी चीज़ है जो टूटती है। कुछ भी जो WordPress फ्रंट-एंड में HTML या JavaScript inject करता है, काम करना बंद कर देता है, security plugins, caching plugins, schema plugins, social-share plugins। हर एक फ्रंट-एंड पर code से या managed service से replace होता है। plugin count आमतौर पर migration के बाद सत्तर से अस्सी प्रतिशत गिरता है। यह win का हिस्सा है, regression नहीं।