तीन साल पहले एक क्लायंट ने मुझे गुरुवार की दोपहर को फोन किया, बिल्कुल घबराया हुआ। उन्होंने एक Drupal-से-WordPress माइग्रेशन को एक सस्ते डेवलपर की दुकान को सौंप दिया था, साइट शुक्रवार को लाइव हुई, और सोमवार तक उना ऑर्गेनिक ट्रैफिक 67% गिर गया। खत्म। छह साल का SEO इक्विटी, बस... उड़ गया। कोई रीडायरेक्ट नहीं। हजारों broken URLs। Google का crawl budget तबाह।
मुख्य बात: Drupal से WordPress माइग्रेशन CMS स्वैप से नहीं, बल्कि URL मैपिंग और टैक्सोनॉमी ट्रांसलेशन में विफल होते हैं; रैंकिंग बनाए रखने के लिए एक संपूर्ण रीडायरेक्ट मैप और मेटाडेटा को ट्रांसपोर्ट करके भेजें।
मैंने इस तरह की खस्ताहाली को गिनती से ज्यादा बार दोबारा बनाया है। Seahawk Media में 12,000+ माइग्रेशन के बाद, मैं आपको पूरे आत्मविश्वास के साथ बता सकता हूँ: Drupal से WordPress तक की तकनीकी चाल असल में आसान हिस्सा है। SEO संरक्षण वह जगह है जहाँ सब कुछ गलत हो जाता है, और जहाँ इसे बिल्कुल गलत होने की जरूरत नहीं है।
यह वह प्लेबुक है जो मैं फॉलो करता हूँ। हर बार।
---
Drupal-से-WordPress माइग्रेशन एक SEO खदान क्यों हैं
Drupal और WordPress URLs अलग तरीके से जेनरेट करते हैं। Drupal की डिफ़ॉल्ट पाथ सिस्टम, Pathauto जैसे मॉड्यूल के साथ, अक्सर ऐसी URL संरचनाएँ बनाती है जिनका WordPress के साथ कोई ओवरलैप नहीं होता। Drupal पर /content/our-services/web-design पर एक नोड WordPress पर /our-services/web-design या यहाँ तक कि /web-design बन सकता है, यह इस बात पर निर्भर करता है कि आप परमालिंक कैसे सेट करते हैं। ये अलग URLs हैं। Google उन्हें अलग पेज मानता है। रिडायरेक्ट के बिना, पुराना वाला मर जाता है।
और यह सिर्फ URLs के बारे में नहीं है। Drupal की टैक्सोनमी सिस्टम WordPress की categories और tags से मैप करती है, लेकिन बिल्कुल नहीं। Drupal में कस्टम कंटेंट टाइप WordPress में Custom Post Types बन जाते हैं, और अगर आप माइग्रेशन से पहले उन CPTs को नहीं बनाते हैं, तो आपकी कंटेंट बिल्कुल गलत जगह पर आ जाती है। मैंने एक Drupal-संचालित समाचार साइट देखी है जहाँ 800 "article" नोड्स सब कुछ मानक WordPress Posts के रूप में आयात किए गए, जिससे कस्टम आर्काइव संरचना को ओवरराइट कर दिया गया जिस पर उनकी आंतरिक लिंकिंग निर्भर थी।
यहाँ वह चीज़ है जो ज़्यादातर devs miss करते हैं: migration से पहले WordPress में जो भी structural decision आप लेते हैं, वह directly उन redirects को प्रभावित करता है जिनकी आपको बाद में ज़रूरत होगी। पहले architecture को सही करें। Redirects एक patch हैं, एक plan नहीं।
---
चरण 1: माइग्रेशन पूर्व ऑडिट, जानें कि आप क्या ले जा रहे हैं इससे पहले कि आप इसे ले जाएँ
Drupal इंस्टॉलेशन को तब तक न छुएँ जब तक आपके पास लाइव साइट का संपूर्ण क्रॉल न हो। मैं Screaming Frog का उपयोग करता हूँ जो 500,000 URLs तक क्रॉल करने के लिए सेट है (पेइड वर्जन)। सब कुछ एक्सपोर्ट करें: URLs, स्टेटस कोड, टाइटल टैग, मेटा विवरण, H1s, कैनोनिकल टैग, इनबाउंड इंटरनल लिंक, शब्द गिनती।
अपने Google Search Console डेटा भी खींचें। पिछले 16 महीनों में क्लिक्स के आधार पर फिल्टर करें (3 नहीं, न ही 6-16, क्योंकि आप सीज़नल कंटेंट को कैच करना चाहते हैं)। हर वह URL एक्सपोर्ट करें जिसे कम से कम एक क्लिक मिला हो। ये आपके प्रोटेक्टेड URLs हैं। इनमें से किसी पर भी रैंकिंग खोएँ तो क्लाइंट को नोटिस हो जाएगा।
मैं specifically क्या देख रहा हूँ:
- Drupal साइट पर पहले से मौजूद डुप्लिकेट कंटेंट (माइग्रेशन के बाद नहीं, पहले ठीक करें)
- 200 शब्दों से कम पतली कंटेंट पेजें जो कुछ भी रैंक नहीं करती हैं, इन्हें माइग्रेट करने के बजाय समेकित या हटाया जा सकता है
- गैर-मानक URL पैटर्न जैसे /node/1234 URLs जो Drupal कभी-कभी उजागर करते हैं भले ही Pathauto सक्रिय हो
- टैक्सोनमी आर्काइव पेज जो रैंक करते हैं, /tags/, /category/, /topic/ पाथ जिनके पास असल में Search Console impressions हैं
वह आखिरी वाला लोगों को लगातार पकड़ता है। Drupal टैक्सोनॉमी टर्म पेज अक्सर लॉन्ग-टेल क्वेरी के लिए रैंक करते हैं। अगर आप समकक्ष WordPress टैक्सोनॉमी आर्काइव को फिर से नहीं बनाते और पुराने पाथ को रिडायरेक्ट नहीं करते, तो आपने अभी-अभी निष्क्रिय ट्रैफिक फेंक दिया है।
---
चरण 2: URL मैपिंग, वह स्प्रेडशीट जिसे कोई नहीं बनाना चाहता है
उबाऊ? हाँ। गैर-परक्राम्य? यह भी हाँ।
Google Sheets (या Airtable अगर आप पसंद करते हैं, मैंने दोनों का उपयोग किया है) में एक URL मैप बनाएँ। कॉलम A हर Drupal URL है। कॉलम B वह संबंधित WordPress URL है जिसमें यह रिजॉल्व होगा। कॉलम C एक स्टेटस है: exact match, redirect needed, consolidate, या delete।
300-पेज वाली साइट के लिए, इसमें आधा दिन लगता है। 8,000-पेज वाली साइट के लिए, जिसे Seahawk ने 2021 में एक उच्च-शिक्षा क्लायंट के लिए संभाला था, इसमें तीन लोगों की टीम को लगभग चार कार्यदिस और एक बहुत ही थकाऊ शुक्रवार की शाम लगती है। हर बार इसके लायक।
कुछ नियम जिन्हें मैं अनुसरण करता हूँ:
- जहां संभव हो slugs को संरक्षित करें। यदि Drupal के पास /blog/how-to-fix-crawl-errors है, तो WordPress को भी यही slug उपयोग करने दें। अधिकांश समय आप कर सकते हैं। WordPress में Permalink सेटिंग्स WordPress Settings → Permalinks आपको किसी भी पैटर्न से मेल खाने देती है जो Drupal उपयोग कर रहा था।
- कभी होमपेज पर रीडायरेक्ट मत करो। आलसी डेवलपर्स यही करते हैं। इससे लिंक इक्विटी खत्म हो जाती है और यूजर्स को भ्रम होता है। हर पुराने URL का एक खास डेस्टिनेशन होना चाहिए।
- पेजिनेटेड URLs से सावधान रहें। Drupal पेजिनेशन ?page=1 जैसा दिखता है। WordPress /page/2/ का उपयोग करता है। इन्हें मैप करें या उन्हें 404s के रूप में छोड़ दें (जो आमतौर पर ठीक है, पेजिनेटेड पेज शायद ही कभी अर्थपूर्ण लिंक इक्विटी रखते हैं, लेकिन पहले GSC में पुष्टि करें)।
- क्वेरी स्ट्रिंग्स को अलग से दस्तावेज़ करें। /search?keys=wordpress जैसी चीजों को रीडायरेक्ट की जरूरत नहीं है। /events?date=2023-06 को शायद जरूरत हो, इस बात पर निर्भर करता है कि वे पेज रैंक करते हैं या नहीं।
---
चरण 3: कंटेंट माइग्रेशन, FG Drupal to WordPress और क्या वास्तव में होता है
FG Drupal to WordPress प्लगइन ज्यादातर माइग्रेशन में भारी सामान उठाता है। यह सीधे आपके Drupal डेटाबेस से कनेक्ट होता है, नोड्स, यूजर्स, टैक्सोनमी टर्म्स और मीडिया खींचता है। Drupal 7 के लिए, यह शानदार काम करता है। Drupal 9/10 के लिए, आपको प्रीमियम संस्करण की जरूरत है, जो आखिरी बार जब मैंने चेक किया तो लगभग €99 का था। मैनुअल माइग्रेशन की तुलना में हर पैसा खर्च करने लायक है।
प्लगइन जो चीजें अच्छे से हैंडल करता है:
- नोड बॉडी कंटेंट (मीडिया पाथ सही तरीके से कॉन्फ़िगर करो तो एम्बेडेड इमेजेस सहित)
- टैक्सोनॉमी टर्म्स को WordPress कैटेगरीज/टैग्स में मैप किए हुए
- बेसिक कस्टम फील्ड्स अगर तुम प्रीमियम टियर पर हो
जो चीजें यह हैंडल नहीं करेगा और आपको मैनुअली ठीक करनी होंगी:
- Drupal Views, ये कस्टम पेज लेआउट/क्वेरीज हैं। आप इन्हें WordPress में WPGridBuilder जैसी प्लगइन का उपयोग करके या सिर्फ कस्टम WP_Query लूप का उपयोग करके पुनः बनाएंगे
- वेबफॉर्म्स, इन्हें Gravity Forms या WPForms से मैन्युअली मैप करें; लॉजिक ट्रांसफर नहीं होती
- जटिल फील्ड ग्रुप्स, Drupal का Field API कुछ वास्तव में अजीब डेटा स्ट्रक्चर सपोर्ट करता है। आपको इन्हें CSV में एक्सपोर्ट करना होगा और WP All Import के जरिए इम्पोर्ट करना होगा
- ब्लॉक कंटेंट रीजन्स, Drupal की ब्लॉक सिस्टम WordPress विजेट्स/FSE ब्लॉक्स जैसी बिल्कुल नहीं है। यह डिज़ाइन निर्णय है, माइग्रेशन टास्क नहीं
FG Drupal to WordPress खत्म होने के बाद मैं हमेशा एक काम करता हूं: row count चलाना। Drupal में कितने nodes थे? WordPress में अब कितनी posts/CPT एंट्रीज हैं? ये मैच करनी चाहिए (सिवाय जो आपने जानबूझकर एक्सक्लूड किए हों)। 5,000-नोड साइट पर 3% डिस्क्रेपेंसी का मतलब 150 पेज मिसिंग हैं। उन्हें खोजें।
---
स्टेप 4: रीडायरेक्ट्स को इंप्लीमेंट करना बिना अपने सर्वर को तोड़े
एक बार URL मैप बन जाए और कंटेंट WordPress स्टेजिंग वातावरण पर लाइव हो जाए, तो रीडायरेक्ट्स का समय आ गया है। दो टूल्स: छोटी साइट्स के लिए Redirection प्लगइन (~1,000 रीडायरेक्ट्स से कम), और Apache पर बड़ी साइट्स के लिए .htaccess नियम, या Nginx पर nginx.conf ब्लॉक्स।
यह स्प्लिट क्यों? Redirection प्लगइन रीडायरेक्ट्स को PHP के जरिए प्रोसेस करता है, जिसका मतलब है हर रीडायरेक्ट चेक के लिए एक सर्वर हिट। 5,000 रीडायरेक्ट्स के साथ 50,000 दैनिक पेजव्यूज़ पर, यह असली ओवरहेड है। सर्वर-लेवल रीडायरेक्ट्स एक ऑर्डर ऑफ मैग्नीट्यूड से तेज़ हैं।
बड़े माइग्रेशन के लिए, मैं Google Sheets से URL मैप एक्सपोर्ट करता हूँ, RewriteRule ब्लॉक्स जेनरेट करने के लिए एक त्वरित स्क्रिप्ट लिखता हूँ, और उन्हें गो-लाइव से पहले .htaccess में डालता हूँ। 20 मिनट लगते हैं। लॉन्च के बाद एक सुस्त साइट की डीबगिंग में घंटों की बचत करता है।
एक चीज जो लोग नहीं सोचते: रीडायरेक्ट चेन्स। अगर Drupal के पास पहले से ही रीडायरेक्ट्स थे (कई परिपक्व Drupal साइट्स के पास हैं, Redirect मॉड्यूल के माध्यम से), तो आपको उन्हें खोजना होगा और चेन को कोलैप्स करना होगा। A → B → C को A → C बन जाना चाहिए। Google का अपना दस्तावेज़ काफी स्पष्ट है कि चेन्स PageRank ट्रांसफर को धीमा करते हैं, भले ही वे इसे खत्म न करें।
---
स्टेप 5: पोस्ट-लॉन्च, 72-घंटे की विंडो
मंगलवार या बुधवार को लाइव जाएं। कभी शुक्रवार नहीं। मैंने यह 2018 में एक क्लाइंट के साथ कठिन तरीके से सीखा, हमने एक 1,200-पेज माइग्रेशन शुक्रवार दोपहर को लॉन्च किया और शाम 6 बजे एक गलत कॉन्फ़िगर की गई परमालिंक स्ट्रक्चर की खोज की। सोमवार तक, Google ने पहले से ही टूटी हुई URLs की एक बड़ी लहर को क्रॉल और इंडेक्स कर दिया था।
पहले 72 घंटों में मैं जो मॉनिटर करता हूँ:
- GSC कवरेज रिपोर्ट, 404s में स्पाइक के लिए देखें। कुछ उम्मीद के अनुसार हैं (पुराने Drupal सिस्टम पाथ)। आपके मनी पेजेस के पार एक स्पाइक नहीं है।
- Screaming Frog फिर से क्रॉल करें, लॉन्च के अगली सुबह लाइव WordPress साइट को क्रॉल करें। URL काउंट को अपनी प्री-माइग्रेशन बेसलाइन से तुलना करें।
- रीडायरेक्ट स्पॉट-चेक्स, GSC से अपने 20 सबसे अधिक ट्रैफिक वाले Drupal URLs को मैन्युअली टेस्ट करें। उन्हें ब्राउज़र में पेस्ट करें। क्या वे सही जगह पर लैंड करते हैं?
- कैनोनिकल टैग्स, कन्फर्म करें कि WordPress हर पेज पर सही कैनोनिकल आउटपुट कर रहा है। Yoast और Rank Math दोनों यह स्वचालित रूप से करते हैं, लेकिन फिर भी चेक करें।
- XML साइटमैप सबमिशन, नया साइटमैप तुरंत GSC में सबमिट करें। Google को इसे खोजने के लिए प्रतीक्षा न करें।
एक चीज़ जो मैं करता हूँ और ज्यादातर लोग छोड़ देते हैं: migration के बाद, पुरानी Drupal XML sitemap को भी GSC में जमा करें, अगर आपने पुराने domain या subdomain को잠시के लिए बनाए रखा है तो उसे point करते हुए। यह Google को बताता है कि कौन से पुराने URLs को crawl करना है, redirects को follow करना है, और अपने index को तेजी से update करना है।
---
चरण 6: 30-दिन की SEO स्वास्थ्य जांच
एक migration go-live पर पूरी नहीं होती। Index को update होने में समय लगता है। 30-दिन के निशान पर मैं यह देखता हूँ:
- रैंकिंग पोजीशन में बदलाव देखने के लिए Ahrefs या Semrush का इस्तेमाल करके माइग्रेशन से 30 दिन पहले और 30 दिन बाद की कीवर्ड पोजीशन की तुलना करें। कुछ शब्दों पर मामूली उतार-चढ़ाव (5-10 पोजीशन) की उम्मीद रखें। किसी प्राथमिक कीवर्ड पर 30+ पोजीशन की गिरावट जांच की मांग करती है।
- बैकलिंक टार्गेट्स को देखें—अगर आपके पास बाहरी बैकलिंक्स किसी विशेष Drupal URL की ओर इशारा कर रहे थे, तो जांचें कि वह URL सही तरीके से रीडायरेक्ट हो रहा है या नहीं। Ahrefs की Lost Backlinks रिपोर्ट यह सामने लाती है। टूटे हुए बैकलिंक टार्गेट्स वह लिंक इक्विटी हैं जिसे आप सक्रिय रूप से खो रहे हैं।
- पेज स्पीड में गिरावट—WordPress साइट्स कभी-कभी अच्छी तरह ट्यून की गई Drupal साइट्स से धीमी होती हैं। अपने 5 सबसे महत्वपूर्ण पेजों पर Lighthouse ऑडिट चलाएं और अपने माइग्रेशन-पूर्व बेसलाइन से तुलना करें।
- इंडेक्सेशन दर—आपके जमा किए गए कितने URLs इंडेक्स हैं? 30 दिन पर आप अपने मुख्य कंटेंट पेजों का कम से कम 80% इंडेक्स होना चाहते हैं। 60% से कम कुछ भी क्रॉलेबिलिटी समस्या का संकेत है (robots.txt की जांच करें और यह सुनिश्चित करें कि आपने WordPress Settings → Reading में accidentally Googlebot को ब्लॉक नहीं किया)।
Seahawk का पिछले साल एक फिनटेक क्लाइंट था जहाँ 30 दिन की जांच से पता चला कि 340 प्रोडक्ट पेजों को गलती से माइग्रेशन के दौरान एक गलत कॉन्फ़िगर किए गए Yoast बल्क एक्शन द्वारा noindex पर सेट कर दिया गया था। 30 दिन में पकड़े गए: दोपहर में ठीक किए जा सकते हैं। 6 महीने में पकड़े गए: संभवतः एक रैंकिंग छेद है जिसे आप भरने की कोशिश कर रहे हैं।
---
FAQ
Drupal से WordPress माइग्रेशन वास्तव में कितना समय लेता है?
यह पूरी तरह साइट के आकार और कंटेंट की जटिलता पर निर्भर करता है। 50-पेज की ब्रोशर साइट: QA सहित 2-3 दिन। 5,000-पेज का न्यूज़ आर्काइव कस्टम कंटेंट टाइप्स के साथ: 6-10 सप्ताह। SEO का काम, ऑडिट, URL मैपिंग, रीडायरेक्ट इंप्लीमेंटेशन, पोस्ट-लॉन्च मॉनिटरिंग आमतौर पर कोर डेवलपमेंट एस्टिमेट के अनुमान में 30-40% जोड़ते हैं। किसी को यह न कहने दें कि अन्यथा है।
क्या Drupal से WordPress में माइग्रेट करने के बाद मैं रैंकिंग खो दूंगा?
Short-term fluctuation सामान्य है और लगभग अपरिहार्य है। अगर आपने URL mapping, redirects, और canonical tags सही तरीके से किए हैं, तो ज्यादातर rankings 6-12 सप्ताह में स्थिर हो जाते हैं। जिन sites को मैंने permanent losses suffer करते देखा है, उन सभी की एक ही समस्या थी: या तो कोई redirects नहीं, या mass redirects जो homepage की ओर pointing हैं। काम करो। Rankings वापस आते हैं।
क्या मुझे सभी Drupal कंटेंट माइग्रेट करना चाहिए या नए सिरे से शुरू करना चाहिए?
इस बात पर निर्भर करता है कि आपके लिए कंटेंट क्या कर रहा है। अपना GSC डेटा खींचें। 16 महीने में शून्य क्लिक और कोई बैकलिंक्स न होने वाला कोई भी कंटेंट माइग्रेट करने के बजाय डिलीट करने का कैंडिडेट है। पतले, कम-वैल्यू कंटेंट को माइग्रेट करने से आपकी WordPress साइट ब्लोटेड होती है और क्रॉल बजट को कमजोर किया जा सकता है। निर्मम बनें। बस कहा, ऐसे किसी भी URL को कभी डिलीट न करें जिसके पास बाहरी बैकलिंक्स हों, भले ही पेज खुद ही खराब हो, इसे कुछ प्रासंगिक की ओर रीडायरेक्ट करें।
Drupal माइग्रेशन के बाद WordPress के लिए सबसे अच्छा थीम कौन सा है?
ईमानदारी से, अगर आप अच्छी तरह से संरचित HTML का उपयोग कर रहे हैं और पेज स्पीड में ध्यान रख रहे हैं, तो थीम चुनाव के लगभग कोई SEO प्रभाव नहीं है। मैं GeneratePress को इसके क्लीन मार्कअप और न्यूनतम ओवरहेड के लिए, या Kadence को डिफॉल्ट करता हूँ अगर क्लाइंट को अधिक डिजाइन लचीलापन चाहिए। पेज-बिल्डर-हेवी थीम्स से बचें जो हर पेज लोड पर 400KB अप्रयुक्त CSS को आउटपुट करते हैं।
क्या मुझे डेवलपर की जरूरत है या मैं यह खुद कर सकता हूँ?
50 पेज से कम, सरल कंटेंट और कस्टम पोस्ट टाइप्स न होने वाली छोटी साइट के लिए? आप शायद FG Drupal to WordPress और Redirection प्लगइन के साथ ऊपर दिए गए चरणों का पालन करते हुए प्रबंधित कर सकते हैं। बड़ी किसी चीज के लिए, या CPTs, जटिल टैक्सोनॉमीज़, या मौजूदा SEO फ़ुटप्रिंट के साथ कुछ के लिए, एक डेवलपर प्राप्त करें। बोचे गए माइग्रेशन को ठीक करने की लागत हमेशा पहली बार ठीक से करने की लागत से अधिक होती है।
---
माइग्रेशन ही शायद काम का 40% है। बाकी 60% उस SEO इंफ्रास्ट्रक्चर है जो आप इसके चारों ओर बनाते हैं, मैपिंग, रीडायरेक्ट्स, मॉनिटरिंग, विजय की घोषणा करने से पहले 30 दिन के लिए डेटा को देखने का धैर्य। मैंने सुंदर तरीके से निर्मित WordPress साइट्स को सर्च में टैंक करते देखा है क्योंकि रीडायरेक्ट वर्क स्लॉपी था, और मैंने स्क्रैपी, मुश्किल से थीमित WordPress इंस्टॉल्स को हर रैंकिंग को होल्ड करते देखा है क्योंकि URL मैप मेटिकुलस था।
बोरिंग स्टफ को सही तरीके से करो। बाकी सब कुछ आम तौर पर फॉलो कर जाता है।