WordPress से Next.js माइग्रेशन — बिना किसी रैंकिंग को खोए।

सच कहूँ तो? ज़्यादातर इसलिए कि Lighthouse कभी वाक़ई वहाँ तक नहीं पहुँचता।

मैंने बहुत सुबहें संस्थापकों को यह समझाने में बिताई हैं कि उनकी मेहनत से बनाई गई Elementor साइट PageSpeed Insights में 62 पर ही अटक जाती है, भले ही तीन caching प्लगइन, एक CDN, और एक ताज़ी hosting मूव के बाद भी। एक छत होती है। अगर आप सच में परवाह करें तो classic WordPress front-end को 80 के कम तक ले जा सकते हैं, लेकिन हर plugin अपडेट एक regression का जोखिम है और हर page builder release एक और आधा megabyte लेकर आता है जिसकी आपने माँग नहीं की थी।

जो teams मुझे migrate करते देखता हूँ वे तीन मोटे-मोटे buckets में बँटती हैं, और वे लगभग कभी overlap नहीं करतीं।

The performance bucket

एक Series-A SaaS marketing site, फिलहाल WP Engine पर, Elementor Pro और तीन add-on पैक के लिए paying। Lighthouse 64 mobile पर। INP 380 ms पर। उनके पास एक content team है जो हर हफ़्ते दो posts ship करती है और एक engineering team है जो onboarding flows ship करना चाहती है, WordPress patches नहीं। Next.js rebuild उन्हें 96 तक ले जाता है, और engineers wp-admin को छूना बंद कर देते हैं।

The engineering bucket

तीन TypeScript engineers। इनमें से एक marketing site के लिए on call है। वे wp-admin को हर दूसरे हफ़्ते खोलते हैं और गाली देते हैं। पूरा "यह PHP 7.4 है या 8.1, agency ने हमारे लिए WooCommerce का कौन सा version छोड़ा है" नियम उन लोगों पर एक tax है जो खुशी से Astro में ship करते जो आधी परेशानी में होती। Migrate करो, उन्हें एक Next.js या Astro repo दो proper CI के साथ, और on-call rotation छोटा हो जाता है।

The security bucket

कम आम, ज़्यादा decisive। एक board-level mandate कि public-facing surfaces PHP चला नहीं सकतीं। या एक security incident जो एक patched plugin को तीन हफ़्ते late ship करता है। Headless WordPress एक non-public origin पर policy को satisfy करता है बिना editorial team को एक नया CMS सीखने के लिए मजबूर किए। wp.example.com private चला जाता है; front-end सिर्फ एक static site है Vercel पर। ज़्यादातर pen tests interesting होना बंद कर देते हैं।

तीन। सच में तीन, marketing-page की किस्म नहीं जो सब एक ही scope में collapse हो जाएँ। हर एक एक अलग team के लिए अच्छा है।

पथ 1 — WordPress रखें, फ्रंट-एंड बदलें

हेडलेस। WP संपादक सतह के रूप में रहता है। Yoast एडमिन में अपना काम करता रहता है। ACF एडमिन में अपना काम करता रहता है। सार्वजनिक साइट Next.js या Astro में फिर से बनाई जाती है और WPGraphQL पर content खींचता है। संपादकों को माइग्रेशन के दिन शायद ही कुछ अंतर दिखता है, सिवाय URL बार में नए फ्रंट-एंड डोमेन के। यह सबसे सामान्य पथ है जो मैं देखता हूँ; हाल के माइग्रेशन का लगभग दो-तिहाई इसी तरह गए हैं।

जब यह सही हो: संपादकीय टीम WordPress में खुश है, इंजीनियरिंग समस्या पूरी तरह फ्रंट-एंड की है, और आप बारह हज़ार पृष्ठों के Yoast metadata को माइग्रेट नहीं करना चाहते।

पथ 2 — WordPress को पूरी तरह छोड़ दें

सब कुछ Sanity, Payload, Storyblok या Contentful में माइग्रेट करें। लॉन्च पर WordPress बंद करें। नया codebase, साफ content model, कहीं भी PHP नहीं। माइग्रेशन की लागत अधिक है क्योंकि आप content को स्थानांतरित कर रहे हैं, सिर्फ फ्रंट-एंड को फिर से नहीं बना रहे। यह तब काम में आता है जब संपादकीय टीम विशेष रूप से WordPress से बाहर निकलना चाहती है, या जब content model को ACF flexible content से अधिक कठोरता की जरूरत होती है।

जब यह सही हो: आप वास्तव में एक अलग CMS चाहते हैं, सिर्फ एक अलग फ्रंट-एंड नहीं।

पथ 3 — संकर

कुछ content WordPress में रहता है, कुछ कहीं और चला जाता है। वास्तविक उदाहरण पैटर्न: ब्लॉग WP में रहता है क्योंकि संपादकीय टीम परिपक्व है और Yoast असली काम कर रहा है; product pages Payload में चले जाते हैं क्योंकि schema को सही relations और validation की जरूरत है। फ्रंट-एंड एक Next.js ऐप है जो दोनों backends से पढ़ता है। अधिक architecture है लेकिन कभी-कभी यह सही जवाब होता है।

जब यह सही हो: एक ही साइट पर दो genuinely अलग content shapes हैं, और उन्हें एक CMS में डालने से किसी का जीवन कठिन हो रहा है।

यह वह जगह है जहाँ माइग्रेशन आगे बढ़ते हैं या असफल होते हैं, और यह भी वह बिट है जहाँ टीमें आमतौर पर कटौती करती हैं। एक संपूर्ण map के बिना आप launch के दिन ही rankings खो देते हैं। आधे map के साथ आप उन्हें छह हफ्तों में धीरे-धीरे खो देते हैं जबकि आप खुद को बताते हैं कि यह गिरावट सिर्फ seasonality है।

यह map तीन स्वतंत्र स्रोतों से बनता है कोई भी कोड भेजने से पहले।

1. Search Console export — हर एक URL जिसे Google ने crawl किया है और पिछले 16 महीनों में indexable माना है। यह आपके domain पर Google को जो कुछ मिलने की उम्मीद है उसकी canonical list है।
2. Ahrefs या Semrush export — हर एक URL जिसके पास कम से कम एक referring domain है, referring-domain count के अनुसार sorted। ये वह URLs हैं जहां 301 preservation सबसे ज़्यादा मायने रखता है। अगर आप 200 backlinks वाले page को 404 करते हो, तो आपने 200 backlinks बर्बाद कर दिए हैं।
3. WordPress sitemap — आपका current XML sitemap export। ऐसे pages को पकड़ता है जिनके पास backlinks या organic traffic नहीं हो सकते लेकिन फिर भी structure में हैं। पहले दोनों से कुछ छूट गया हो तो उसे खोजने के लिए useful है।

तीन lists, deduped, नए URLs पर mapped, vercel.json या netlify.toml में edge पर 301s के रूप में shipped। 302s नहीं। JavaScript-driven redirects नहीं। Meta refresh नहीं। URLs जो genuinely retired हैं वो 410 पाते हैं। URLs जिनके slug बदल गए हैं वो 301 पाते हैं। Build linter deploy को fail कर देता है अगर migration से पहले कोई URL map से missing है।

मैंने एक 5,000-page migration को आठ हफ्तों में 60% organic खो देते देखा है क्योंकि redirect map 87% complete था और "बाकी चीज़ों की चिंता करने की कोई बात नहीं है"। वह 13% चिंता करने के लायक थे। हमेशा ही होते हैं।

Plugin audit दिन एक पर। हर एक active plugin चार buckets में से एक में जाता है, और bucket काम decide करता है।

जैसे है वैसे रहता है

Plugins जो server-side चलते हैं और कभी public front-end को touch नहीं करते। WP Migrate DB, BackWPup, server-side analytics, role-management। ये काम करते रहते हैं क्योंकि उनके काम में HTML को visitor को render करना शामिल नहीं है। आम तौर पर plugin count का लगभग 20-25% यहां आता है।

Replaced by code

Plugins जो front-end में HTML या JavaScript inject करते हैं। ज़्यादातर SEO plugins (metadata transports, front-end output custom है)। ज़्यादातर form plugins (Next.js endpoints या ConvertKit / HubSpot / Mailchimp से replace किए गए)। ज़्यादातर schema plugins (hand-written templates से replace किए गए जो cleaner JSON-LD emit करते हैं)। Cookie banners को TypeScript में rewrite किया जाता है। लगभग 30-40% plugin count।

सेवा द्वारा बदला गया

Plugins जो एक third-party को wrap करते हैं। HubSpot embed plugin HubSpot Forms API call बन जाता है। Stripe payment plugin Stripe Elements बन जाता है। Zapier और Make वहीं रहते हैं क्योंकि वो WordPress के बाहर रहते हैं। Count का लगभग 10-15%।

पूरी तरह हटा दिया गया

वे प्लगइन जो केवल इसलिए मौजूद हैं क्योंकि WordPress फ्रंट-एंड को उनकी जरूरत थी। कैशिंग प्लगइन (Vercel इसे संभालता है)। अधिकांश सिक्योरिटी प्लगइन (सार्वजनिक अटैक सर्फेस खत्म हो गया है)। परफॉर्मेंस ऑप्टिमाइजेशन प्लगइन (अब बिल्ड-टाइम की चिंता है)। और हमेशा-मजेदार "मुझे कोई अंदाजा नहीं है कि यह यहाँ क्यों है, यह दो साल से डीएक्टिवेट है लेकिन हमने कभी इसे डिलीट नहीं किया" ग्रुप। माइग्रेशन के बाद WordPress साइड पर प्लगइन काउंट आमतौर पर 70-80% गिर जाता है। यह जीत का हिस्सा है।

preview और drafts

एडिटर wp-admin में Preview को दबाते हैं। WordPress एक JWT प्रिव्यू टोकन बनाता है। Next.js फ्रंट-एंड टोकन को पढ़ता है, स्टैटिक कैश को बायपास करते हुए WPGraphQL के माध्यम से ड्राफ्ट को फेच करता है, और रेंडर करता है। ड्राफ्ट URLs साइन किए हुए होते हैं, कभी इंडेक्सेबल नहीं, कभी सार्वजनिक रूप से कैश नहीं होते। वन-क्लिक प्रिव्यू UX बिल्कुल वैसे ही रहता है जैसे पहले था। अधिकांश एडिटर को माइग्रेशन दिन पर एडिटोरियल साइड से कोई फर्क नहीं पड़ता।

कमेंट, रिविजन, रोल

बैक-एंड पर अछूते। पोस्ट पर कमेंट WordPress-नेटिव रह सकते हैं और WPGraphQL के माध्यम से हेडलेस रेंडर हो सकते हैं, या Disqus / Giscus / एक कस्टम सिस्टम से बदले जा सकते हैं अगर आपकी टीम चाहती थी। रिविजन अपरिवर्तित हैं — हर पोस्ट का पूरा इतिहास अभी भी WordPress एडिटर से एक्सेस योग्य है। यूजर रोल, परमिशन, मल्टी-ऑथर सेटअप, सब सुरक्षित।

Yoast और Rank Math

दोनों ट्रांसपोर्ट करते हैं। Yoast SEO for WPGraphQL हर फील्ड को एक्सपोज करता है — फोकस कीवर्ड, मेटा टाइटल, मेटा डिस्क्रिप्शन, कैनोनिकल, OG, Twitter कार्ड, स्कीमा ब्रेडक्रंब — क्वेरीएबल GraphQL के रूप में। Rank Math के पास समतुल्य है। Next.js लेआउट टाइप किए गए रिस्पांस को पढ़ता है और मेटा टैग्स को उसी तरह रेंडर करता है जैसे Yoast या Rank Math क्लासिक WordPress पर आउटपुट करते। एडिटर एक ही प्लगइन UI में एडिट करते रहते हैं; माइग्रेशन उनकी साइड से अदृश्य है।

सप्ताह 1: discovery और scoping

प्लगइन ऑडिट। कंटेंट ऑडिट। Search Console + Ahrefs एक्सपोर्ट रिडायरेक्ट मैप सोर्स के लिए। वर्तमान परफॉर्मेंस बेसलाइन। पाथ वन बनाम दो बनाम हाइब्रिड पर निर्णय। आउटपुट: एक निश्चित मूल्य और माइलस्टोन पेमेंट शेड्यूल के साथ लिखित SOW। पहले सप्ताह के अंत तक आप बिल्कुल जानते हैं कि आप किस चीज के लिए भुगतान कर रहे हैं।

सप्ताह 2-4: foundation

Repos आपके GitHub में, हमारे में नहीं। होस्टिंग आपके अकाउंट में। WPGraphQL (या नया CMS) कॉन्फ़िगर किया गया। Next.js या Astro स्कैफोल्डिंग शिप किया गया। SEO लिंटर और रिडायरेक्ट-मैप इनजेशन प्लम्बड। डिजाइन टोकन माइग्रेट किए गए। चौथे सप्ताह के अंत तक फाउंडेशन वास्तविक है और टीम पेज शिप कर रही है।

सप्ताह 5-10: build

टेम्पलेट पोर्ट किए गए, पेज-दर-पेज। आपके Slack में लीड इंजीनियर से दैनिक Loom। साप्ताहिक मध्य-निर्माण रिव्यु कॉल। Linear या Jira या जो भी आप पहले से इस्तेमाल करते हैं में टिकट। एज केस जब वे सामने आते हैं। यह प्रोजेक्ट का उबाऊ मिडल है जहाँ अधिकांश वास्तविक कोड लिखा जाता है।

सप्ताह 10-12: प्री-लॉन्च QA

मैनुअल क्रॉस-ब्राउजर। मोबाइल ऑडिट। WCAG AA पर एक्सेसिबिलिटी ऑडिट। रीयल-डिवाइस Core Web Vitals (लैब Lighthouse नहीं)। SEO लिंटर ग्रीन। स्कीमा वेलिडेटर ग्रीन। रिडायरेक्ट मैप Search Console एक्सपोर्ट के विरुद्ध URL-दर-URL वेरिफाइड। कटओवर प्लान लिखा और रिहर्सल किया गया।

सप्ताह 12: लॉन्च

आपके द्वारा चुनी गई विंडो पर DNS कटओवर। अधिकांश मंगलवार या बुधवार की सुबह जाते हैं, कम ट्रैफिक। फ्रंट-एंड पहले से ही एक स्टेजिंग डोमेन पर चल रहा है; कटओवर एक DNS फ्लिप है। इंजीनियरिंग 24 घंटे के लिए स्टैंडबाई पर है। नया साइटमैप के साथ Search Console सबमिट किया गया। Ahrefs और GA एनोटेट किए गए।

सप्ताह 12-16: हाइपर-केयर

इंडेक्स संबंधी असामान्यताओं, रीडायरेक्ट चेन चेतावनियों और स्कीमा त्रुटियों के लिए रोज़ Search Console की निगरानी करें। आधारभूत स्तर के विरुद्ध साप्ताहिक ट्रैफ़िक की तुलना करें। बग फ़िक्स को फ़ीचर्स से अधिक प्राथमिकता दें। सप्ताह 16 तक साइट स्थिर हो जाती है और हम या तो साफ़-सुथरे तरीके से हैंडओफ़ कर देते हैं या किसी चल रही देखभाल योजना में चले जाते हैं।