तीन साल पहले मैंने एक क्लाइंट का ब्लॉग लिया, 400 पोस्ट्स, 60 हजार मासिक ऑर्गैनिक विजिट्स, आठ साल की जमा हुई PageRank, और इसे एक चमकदार Next.js फ्रंट-एंड में माइग्रेट किया। छह हफ्ते में हमने उस ट्रैफिक का 34% खो दिया। इसलिए नहीं कि नई साइट धीमी थी। इसलिए नहीं कि कंटेंट गायब हो गया। क्योंकि मैं चार विशिष्ट चीजों के साथ लापरवाह था जिन्हें मैं इस पोस्ट में आपको समझाऊँगा ताकि आप मेरी गलती दोहराएँ नहीं।
Headless WordPress with Next.js सचमुच performance और developer experience के लिए शानदार है। लेकिन Google को आपके Lighthouse score से कोई मतलब नहीं है अगर आपके canonical tags गलत हैं, आपका XML sitemap पुराने domain की ओर इशारा कर रहा है, और आपका structured data WPGraphQL और getStaticProps के बीच कहीं गायब हो गया है। Migration का खतरनाक हिस्सा खुद migration ही है। इसे सही तरीके से करना ज्यादातर discipline के बारे में है, magic नहीं।
---
यह माइग्रेशन पहली जगह में SEO को क्यों तोड़ता है
यहाँ वह बात है जिसे ज्यादातर tutorials नज़रअंदाज़ कर देते हैं: WordPress आपके लिए बिना आपको पता चले ही एक बहुत बड़ी SEO heavy lifting करता है। Yoast या Rank Math आपके meta tags generate कर रहा है। WordPress core आपकी permalink structure को handle कर रहा है। आपका theme शायद किसी न किसी तरह का schema markup output कर रहा है। आपका XML sitemap हर बार जब आप publish करते हैं तो ख़ुद-ब-ख़ुद regenerate होता है।
जब आप content layer को WPGraphQL API के ज़रिये Next.js में pull करते हैं और इसे एक नए front-end से serve करते हैं, तो वह सारी infrastructure आपकी समस्या बन जाती है replicate करने के लिए। हर। एक। चीज़।
दूसरी समस्या URL structure है। ज्यादातर WordPress साइटों में /category/post-slug/ या /year/month/post-slug/ या सिर्फ /post-slug/ होता है। Next.js आपको routing के लिए एक खाली कैनवस देता है। अगर आप इसे सावधानी से plan नहीं करते, तो वह खाली कैनवस ranking का कब्रिस्तान बन जाता है।
दो Failure Modes जो मुझे लगातार दिखते हैं
पहली चीज़ वह टीमें हैं जो URLs को भी माइग्रेट करती हैं और फिर भी चीजें तोड़ती हैं, आमतौर पर क्योंकि रीडायरेक्ट्स असंगत रूप से लागू होते हैं या नया sitemap रीडायरेक्ट्स के पहले लाइव हो जाता है। दूसरी चीज़ वह टीमें हैं जो जानबूझकर URL स्ट्रक्चर को बदलती हैं (अक्सर इसे साफ करने के लिए) और रीडायरेक्ट मैपिंग को एक बाद की चीज़ मानती हैं। दोनों ही ठीक किए जा सकते हैं। न ही स्वीकार्य है।
---
कुछ भी छुए से पहले Audit करें
Next.js का एक भी लाइन कोड न लिखें जब तक आपके पास एक पूर्ण URL इन्वेंटरी न हो। मैं Screaming Frog का उपयोग करता हूँ, लाइव WordPress साइट को क्रॉल करता हूँ, हर indexable URL को एक्सपोर्ट करता हूँ, और इसे एक स्प्रेडशीट में डंप करता हूँ। एक 400-पेज साइट के लिए वह शायद एक घंटे का काम है। एक 4,000-पेज साइट के लिए यह अभी भी सिर्फ एक घंटा है, क्योंकि टूल इसे अपने आप करता है।
आप जो capture कर रहे हैं:
- हर canonical URL जो currently indexed है
- हर एक का HTTP status (पहचानें 404s और 301s जो पहले से exist करते हैं)
- हर पेज के लिए मेटा टाइटल और विवरण
- कौन से पेजों के पास स्ट्रक्चर्ड डेटा है (Rich Results Test का उपयोग करें या बस सोर्स इंस्पेक्ट करें)
- इनबाउंड इंटरनल लिंक्स, ताकि आप जानें कि कौन से पेज किन पेजों को लिंक करते हैं
Google Search Console से अपने शीर्ष 50 पेज भी खींचें, क्लिक्स के आधार पर सॉर्ट किए गए। ये वो हैं जिन्हें आप गलत नहीं कर सकते। स्प्रेडशीट में उन्हें फ्लैग करें। उन्हें प्रोडक्शन डिपेंडेंसीज़ की तरह ट्रीट करें।
Seahawk के पास 2022 के अंत में एक ई-कॉमर्स क्लाइंट था -- 1,200-प्रोडक्ट WooCommerce स्टोर जो हेडलेस सेटअप में जा रहा था। कोड लिखने से पहले हमने दो पूरे दिन ऑडिट पर बिताए। क्लाइंट को लगा हम समय बर्बाद कर रहे हैं। हमने उनके 90k मासिक ऑर्गेनिक सेशन्स बचाए।
---
WordPress को True Headless CMS के रूप में सेट अप करना
यह हिस्सा ज्यादातर सीधा है। WPGraphQL इंस्टॉल करें और GraphQL API के माध्यम से अपनी कंटेंट को एक्सपोज़ करें। लेकिन कुछ चीजें हैं जिनके बारे में जानबूझकर सोचना लायक है।
WordPress साइड पर Yoast (या Rank Math) को चलता रखें
भले ही आप अब WordPress को सार्वजनिक फ्रंट-एंड के रूप में सर्व नहीं कर रहे हैं, अपने SEO प्लगइन को सक्रिय रखें। WPGraphQL for Yoast SEO (या समकक्ष Rank Math एक्सटेंशन) सभी SEO मेटा, टाइटल्स, डिस्क्रिप्शन्स, कैनोनिकल URLs, OG डेटा, robots डायरेक्टिव्स को सीधे GraphQL API के माध्यम से प्रदर्शित करता है। इसका मतलब है कि आप इसे Next.js से क्वेरी कर सकते हैं और इसे ठीक वैसे ही रेंडर कर सकते हैं जैसे Yoast का इरादा था।
यह उस 2019 ट्रैफिक ड्रॉप का सबक था जिसका मैंने जिक्र किया था। मैंने मान लिया था कि हम Next.js में post title + site name से titles फिर से generate कर सकते हैं। हम कर सकते थे। लेकिन Yoast ने लगभग 80 top-performing posts के लिए meta titles को manually customize किया था, और हमने सब कुछ खत्म कर दिया। रिकवर होने में आठ हफ्ते लगे।
WordPress Front-End को सावधानी से Disable करें
एक बार जब आप Next.js की ओर traffic point करने के लिए तैयार हों, तो आप WordPress को अपना ख़ुद का front-end simultaneously serve नहीं करना चाहते। बड़े पैमाने पर duplicate content। सबसे साफ़ तरीका है अपने WordPress install पर robots.txt set करना Disallow: / के साथ जब आपकी Next.js site live हो जाती है, और फिर eventually WordPress URL को पूरी तरह firewall कर दो ताकि यह सिर्फ internally या VPN के ज़रिये accessible हो।
robots.txt स्टेप को स्किप न करें। मैंने teams को WordPress को CDN level पर block करते हुए देखा है और फिर उन्हें पता चला कि Googlebot के पास एक cached route था। Cleanup होने में महीनों लगते हैं।
---
URL Structure को बिल्कुल Replicate करना
मेरी strong default recommendation: अपने URLs को identical रखें। Same slug, same permalink structure, same trailing slash behaviour। जितना अधिक Next.js routes WordPress routes को mirror करते हैं, उतने कम redirects की जरूरत है, और कम risk आप carry करते हैं।
Next.js dynamic routes यह आसान बनाता है। अगर आपकी WordPress posts /blog/[slug] पर रहती हैं, तो pages/blog/[slug].js बनाओ। हो गया।
यह जहां messy हो जाता है वह है category archives, author pages, tag pages, और paginated archives (/blog/page/2/)। WordPress ये सब automatically generate करता है। Next.js में आप इन्हें खुद build कर रहे हैं। बहुत सारी teams इन्हें deprioritise करती हैं और फिर सोचती हैं कि crawl coverage क्यों drop हुई।
यहाँ URL parity के लिए मेरी numbered checklist है:
- सिंगल पोस्ट्स/पेजेस, slug को बिल्कुल मिलाएँ, किसी भी सबफोल्डर सहित
- कैटेगरी आर्काइव्स, /category/[slug]/ को रीक्रिएट करें WPGraphQL से getStaticPaths के साथ सभी कैटेगरीज को खींचते हुए
- टैग आर्काइव्स, ऊपर जैसा ही, इन्हें स्किप न करें अगर उन्हें ऑर्गैनिक ट्रैफिक मिलता है
- लेखक आर्काइव्स के लिए पहले Search Console चेक करें; अगर उन्हें जीरो क्लिक मिल रहे हैं, तो आप उन्हें 301 के माध्यम से होमपेज पर रीडायरेक्ट कर सकते हैं
- पेजिनेटेड आर्काइव्स, /blog/page/[num]/ को संरक्षित रखने लायक है अगर आपके पास बहुत सारी पोस्ट हैं
- अटैचमेंट पेजेस, लगभग हमेशा इन्हें 301 के माध्यम से पैरेंट पोस्ट पर रीडायरेक्ट करें; ये WordPress में भी SEO की दृष्टि से बेकार हैं
- फीड URLs, /feed/ को आपके नए RSS फीड पर 301 करें अगर आपके पास एक है, या अगर नहीं है तो 410 रिटर्न करें
---
रीडायरेक्ट: वह हिस्सा जिसे हर कोई कम आंकता है
अगर आप किसी भी URL को बदल रहे हैं, जिसके बारे में मैं असहमत हूँ, लेकिन कभी-कभी ये जरूरी हो जाता है, तो आपका रीडायरेक्ट मैप लॉन्च से पहले बनाना होगा और स्टेजिंग एनवायरनमेंट में टेस्ट करना होगा।
Next.js में, रीडायरेक्ट्स next.config.js में रहते हैं। छोटी साइटों के लिए (200 रीडायरेक्ट्स से कम) ये ठीक है। बड़ी साइटों के लिए, इन्हें JSON फाइल में रखें और इम्पोर्ट करें, या मिडलवेयर का इस्तेमाल करके उन्हें डायनामिकली हैंडल करें। Vercel का edge middleware बड़े रीडायरेक्ट टेबल्स के लिए शानदार है क्योंकि ये पेज रेंडर होने से पहले चलता है, कोई लेटेंसी पेनल्टी नहीं।
next.config.js में format यह है:
``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``
permanent: true एक 301 भेजता है। सभी जेनुइन URL चेंजेस के लिए इसका इस्तेमाल करें। 302 (टेम्पररी) का इस्तेमाल न करें जब तक आप वाकई इसे वापस नहीं लाना चाहते, Google इन दोनों को बिल्कुल अलग तरीके से ट्रीट करता है।
launch से पहले हर redirect को test करें। मैं एक सरल bash script का उपयोग करता हूँ जो spreadsheet के through loop करता है और हर पुरानी URL को curl करके 301 response की जांच करता है सही destination के लिए। लिखने में दस मिनट लगते हैं, launch के बाद की घबराहट में घंटों बचाता है।
---
Next.js में Meta Tags, Canonical URLs, और Structured Data
यह वह जगह है जहाँ अधिकांश migrations चुपचाप points खो देते हैं। content वहाँ है, URLs काम करते हैं, लेकिन SEO signals गलत हैं।
Meta Tags
next-seo का इस्तेमाल करें। ये स्टैंडर्ड है। इसे WPGraphQL Yoast से क्वेरी किए गए डेटा पास करें। आपका _app.js DefaultSeo कॉन्फ़िग पाता है, और हर पेज को NextSeo कम्पोनेंट मिलता है पेज-स्पेसिफिक ओवरराइड्स के साथ। टाइटल, डिस्क्रिप्शन, OG टाइटल, OG इमेज, कैनोनिकल URL, और robots डायरेक्टिव्स को सीधे Yoast GraphQL रिस्पांस से ले लें, कुछ नया न बनाएँ।
एक चीज़ जो लोगों को परेशान करती है: canonical URLs। WordPress में, Yoast automatically canonical सेट करता है। Next.js में आपको canonical को explicitly पास करना होता है। अगर आप भूल जाते हैं, तो Next.js बिना canonical tag के pages render करेगा, और अगर आपके पास कहीं भी query strings हैं (pagination, filters), तो आप expected से ज़्यादा तेज़ी से duplicate content issues का सामना करेंगे।
Structured Data
WordPress थीम और प्लगइन अक्सर JSON-LD को स्वचालित रूप से आउटपुट करते हैं। यह headless में गायब हो जाता है। आपको इसे फिर से बनाना होगा। लेख के लिए, Article स्कीमा का उपयोग करें। प्रोडक्ट के लिए, Product। स्थानीय व्यवसायों के लिए, LocalBusiness। मैं इन्हें React कॉम्पोनेंट्स के रूप में लिखता हूँ जो props स्वीकार करते हैं और <script type="application/ld+json"> टैग रिटर्न करते हैं। प्रत्येक स्कीमा प्रकार के लिए एक कॉम्पोनेंट, पूरे ऐप में दोबारा इस्तेमाल किया जाता है।
माइग्रेशन से पहले Rich Results Test में आपके पास पहले से मौजूद हर स्कीमा प्रकार को चेक करें। उन्हें डॉक्यूमेंट करें। उन्हें फिर से बनाएँ। लॉन्च के बाद नए स्कीमा को उसी टूल से टेस्ट करें।
The XML Sitemap
स्टेटिक सीटमैप का इस्तेमाल न करें। इसे डायनामिकली जेनरेट करें। छोटी साइटों के लिए, /sitemap.xml रूट पर getServerSideProps काम करता है। हजारों पोस्ट्स वाली बड़ी साइटों के लिए, बिल्ड टाइम पर एक कस्टम स्क्रिप्ट के जरिए सीटमैप जेनरेट करें और इसे public/ फोल्डर में आउटपुट करें। Vercel हर डिप्लॉयमेंट पर यह चलाता है, आपका सीटमैप हमेशा करेंट रहता है।
नए sitemap URL को Google Search Console में submit करें — नई site के live होने के पहले दिन। तीसरे दिन नहीं। पहले दिन।
---
Post-Launch Monitoring (The 90-Day Window)
माइग्रेशन लॉन्च पर खत्म नहीं होती। यह तब खत्म होती है जब आपकी रैंकिंग्स स्थिर हो जाती हैं, जिसे Google का डॉक्यूमेंटेशन कुछ हफ्तों से लेकर कुछ महीनों तक कहीं भी हो सकता है क्रॉल बजट और साइट अथॉरिटी के आधार पर।
मैं हर कार्य दिवस पहले महीने में जो देखता हूँ:
- Google Search Console → Coverage रिपोर्ट नए 404s या 'Excluded' URLs के लिए जो बाहर न किए जाने चाहिए
- Search Console → Performance में जाएँ, अपने शीर्ष 50 पेजों के लिए क्लिक और impressions की तुलना सप्ताह-दर-सप्ताह करें
- नई साइट के लिए Screaming Frog को फिर से क्रॉल करें ताकि किसी आंतरिक 404 या गलत तरीके से कॉन्फ़िगर की गई canonical टैग को पकड़ा जा सके
- Core Web Vitals, हाँ, Next.js साइट तेज़ होनी चाहिए, लेकिन इसे फील्ड डेटा (CrUX) में verify करें, सिर्फ Lighthouse में नहीं
अगर आप पहले दो या तीन हफ्तों में एक महत्वपूर्ण drop देखते हैं, तो तुरंत घबराएँ नहीं। Google के re-crawl और re-index करते समय लगभग हमेशा एक अल्पकालिक उतार-चढ़ाव होता है। आप जो ढूंढ रहे हैं वह सप्ताह चार के बाद sustained drops हैं। यही संकेत है कि कुछ संरचनात्मक रूप से गलत है।
2022 के अंत में, e-commerce वाले प्रोजेक्ट से अलग एक प्रोजेक्ट था, हमने एक SaaS ब्लॉग के लिए Next.js migration चलाया और दूसरे सप्ताह 20% impressions में गिरावट देखी। निकला कि हमारा dynamically generated sitemap noindex पेजों को शामिल कर रहा था क्योंकि हमने WPGraphQL query को सही तरीके से filter नहीं किया था। चार घंटे में ठीक किया। तीन हफ्ते में rankings recover हो गई। monitoring ने इसे पकड़ा इससे पहले कि यह और खराब हो जाता
---
FAQ
WordPress से Next.js migration में कितना समय लगता है?
ईमानदारी से कहूँ तो यह पोस्ट की संख्या से ज्यादा साइट की जटिलता पर निर्भर करता है। एक 100-पेज ब्रोशर साइट जिसके पास क्लीन URLs हों, उसे सही तरीके से दो से तीन हफ़्तों में बना सकते हैं। एक 2,000-पोस्ट वाला ब्लॉग जिसमें कस्टम पोस्ट टाइप्स, ACF फील्ड्स और WooCommerce इंटीग्रेशन हो, अगर आप SEO का काम सही तरीके से डेवलपमेंट के साथ कर रहे हैं तो कम से कम छह से आठ हफ़्तों का प्रोजेक्ट है। किसी को भी यह न कहने दें कि यह वीकेंड का काम है।
क्या मुझे Next.js में Pages Router या App Router का इस्तेमाल करना चाहिए?
2024 के मध्य तक मैं नए प्रोजेक्ट्स के लिए App Router को default कर रहा हूँ। लेकिन अगर आपकी टीम Pages Router से ज्यादा comfortable है और यह एक time-sensitive migration है, तो जो आप जानते हैं उसका इस्तेमाल करें। SEO implications minimal हैं, दोनों static generation, server-side rendering, और dynamic routes को support करते हैं। next-seo package के पास अब App Router support है
क्या मुझे WordPress होस्टिंग से पूरी तरह दूर हटना चाहिए?
नहीं। WordPress अपने existing host पर रह सकता है, WP Engine, Kinsta, Cloudways, जो भी आप use कर रहे हों, और purely content API की तरह काम कर सकता है। Next.js front-end Vercel या Netlify पर deploy होता है। दोनों HTTP के माध्यम से communicate करते हैं। कुछ clients को यह approach पसंद है क्योंकि editorial team को वह WordPress admin मिल जाता है जिससे वह पहले से परिचित है
WordPress plugins के बारे में क्या जो SEO को प्रभावित करते हैं, जैसे Redirection में manage किए गए redirects?
Migration से पहले उन्हें export कर दें। Redirection plugin के पास CSV export है। सभी existing redirects लें और उन्हें अपने next.config.js या edge middleware में जोड़ दें। यह न मानें कि वे automatically carry over हो जाएँगे, नहीं होंगे, क्योंकि वे WordPress database में live हैं और Next.js को उनका कोई अंदाज़ा नहीं है
क्या मेरी Google रैंकिंग चाहे कुछ भी हो ड्रॉप हो जाएगी?
लगभग हमेशा कुछ short-term volatility होती है। एक well-executed migration जिसमें zero URL changes हों, proper redirects (जहाँ ज़रूरत हो), replicated meta और structured data, और re-submitted sitemap चार से छः हफ्ते में stabilise हो जाना चाहिए। जिन drops को मैंने महीनों तक चलते देखा है वे सभी specific technical errors की वजह से थे, migration की वजह से नहीं
---
Migration मुश्किल हिस्सा नहीं है। मुश्किल हिस्सा यह discipline है कि हर boring, unglamorous step को करें, audit, redirect mapping, schema recreation, कोई भी clever Next.js code लिखने से पहले। इस order को सही रखें और आप दूसरी तरफ एक faster front-end के साथ निकलेंगे और वही rankings के साथ जिनके साथ आप शुरू हुए थे। संभवतः बेहतर ones, जब Core Web Vitals improvements feed through हों