तीन साल पहले मुझे एक माइग्रेशन सौंपा गया जो पहले से ही लाइव था। कोई स्टेजिंग एनवायरनमेंट नहीं। कोई रीडायरेक्ट मैप नहीं। एक 22,000-पेज ई-कॉमर्स कैटलॉग जिसे किसी ने बस एक नए डोमेन की ओर पॉइंट कर दिया था और इसे "पूरा" कह दिया था। ऑर्गेनिक ट्रैफिक छः हफ्तों में 74% गिर गया। क्लाइंट ने मुझे हल्के पैनिक में कॉल किया, और मैंने करीब चार महीने इसे सुलझाने में लगाए।
मुख्य बात यह है: साइट माइग्रेशन में रैंकिंग खोने का कारण प्लेटफॉर्म बदलना नहीं, बल्कि रीडायरेक्ट ऑडिट को छोड़ना है; चेकलिस्ट में रीडायरेक्ट मैप, मेटाडेटा ट्रांसपोर्ट, स्कीमा कंटिन्यूटी और पोस्ट-लॉन्च वेरिफिकेशन शामिल है।
यह अनुभव, जितना दर्दनाक था, मूलतः इसी वजह से यह चेकलिस्ट मौजूद है। तब से मैंने 800-पेज की ब्रोशरवेयर साइट्स से लेकर 31,000-पेज के पब्लिशर तक माइग्रेट किए हैं जिसके रीजनल सबडोमेन थे, और हर बार बुनियादी बातें एक जैसी होती हैं। क्रम गलत करो, एक स्टेप स्किप करो, और Google तुम्हें Search Console में सबसे अप्रिय तरीके से बताएगा।
तो यह रही। वह असल चेकलिस्ट जो मैं Seahawk Media में इस्तेमाल करता हूँ, कोई सैद्धांतिक ढाँचा नहीं।
---
1. किसी भी चीज़ को छूने से पहले पूरी साइट का क्रॉल करें
स्पष्ट? हाँ। छोड़ा जाता है? लगातार।
एक भी फ़ाइल मूव होने से पहले, मैं Screaming Frog SEO Spider से पूरी लाइव साइट को क्रॉल करता हूँ। 20,000-पेज की साइट पर इसमें कुछ घंटे लगते हैं, मैं आमतौर पर इसे रात में किक करता हूँ और क्रॉल को डेटाबेस मोड में स्टोर करता हूँ ताकि मेमोरी समस्या न बने। मैं जो कैप्चर कर रहा हूँ:
- हर indexable URL (canonical version, pagination noise नहीं)
- पूरे बोर्ड में रिस्पांस कोड्स, 200s, 301s, 302s, 404s, सब कुछ
- मौजूदा internal link structure
- Canonical tags, hreflang attributes अगर लागू हों
- Page titles और meta descriptions (ताकि मैं verify कर सकूँ कि ये migration के दौरान survive करते हैं)
मैं पूरे crawl को CSV में export करता हूँ और इसे रखता हूँ। ये मेरा baseline है। ये वह document है जिसकी मैं तीन हफ्ते बाद नई साइट के live होने के बाद तुलना करूँगा।
बहुत सारे लोग इस स्टेप को स्किप करते हैं क्योंकि "हम साइट को पहले से जानते हैं।" तुम नहीं जानते। मुझे लगता था कि मैं 2021 में एक ट्रैवल क्लायंट की साइट को जानता हूँ, पता चला कि उनके पास 4,000 URLs थे जो एक लीगेसी CMS सबडायरेक्टरी से सर्व किए जा रहे थे जिसका किसी ने ब्रीफ में जिक्र नहीं किया था। इसे क्रॉल में मिला। यह एक आपदा होता।
Google के अपने डेटा को मत भूलिए
Google Search Console से सब कुछ खींचो, कम से कम पिछले 16 महीने का परफॉर्मेंस डेटा, इंडेक्स कवरेज रिपोर्ट, कोई भी मैनुअल एक्शन, सभी साइटमैप्स। और Google Analytics (अब GA4, जाहिर है) से खींचो ताकि कुछ भी बदलने से पहले तुम्हारे ऑर्गेनिक ट्रैफिक के बेंचमार्क्स लॉक हो जाएँ। स्क्रीनशॉट्स यहाँ ठीक काम करते हैं; मैं raw CSVs भी एक्सपोर्ट करता हूँ।
---
2. Redirect Map बनाएँ। फिर इसे दोबारा चेक करें।
यह वह जगह है जहाँ माइग्रेशन सफल या असफल होते हैं। बड़ी साइट्स पर, रीडायरेक्ट मैप एक असल स्प्रेडशीट होता है, आमतौर पर Google Sheets में क्लायंट, उनकी डेव टीम, और किसी भी और को शेयर किया जाता है जो 11pm पर accidentallyकोई formula ओवरराइट कर सकता है।
संरचना सरल है:
- Column A: Old URL (सटीक, trailing slash सहित या बिना)
- Column B: New URL (सटीक)
- Column C: Redirect type (लगभग हर मामले में 301)
- Column D: Status (mapped, verified, live)
- Column E: Notes (catch-all redirects, category consolidations, intentional drops)
20,000 पेज वाली साइट पर आप जाहिर है कि हर URL को अलग से मैप नहीं कर सकते। यह वह क्रम है जिससे मैं काम करता हूँ:
- सभी टॉप-परफॉर्मिंग URLs को पहले मैप करो (GSC से ऑर्गेनिक ट्रैफिक से, टॉप 500 आमतौर पर 80%+ ट्रैफिक ड्राइव करता है)
- Category और taxonomy पेजों को मैप करें
- उन किसी भी URLs को मैप करो जिनके पास मीनिंगफुल बैकलिंक्स हैं (इसके लिए Ahrefs यूज करो, रेफरिंग डोमेन्स फिल्टर करो, सिर्फ raw links नहीं)
- बाकी सब कुछ के लिए pattern-based redirects को संभालें (उदाहरण के लिए, /product/old-slug/ → /shop/old-slug/)
- आप जो पेज retire कर रहे हैं उनके लिए intentional 410s को document करें
Pattern-based redirects वह चीज है जिसे ज्यादातर junior developers गलत करते हैं। वे एक wildcard rule लिखते हैं जो बहुत ज्यादा broad होता है और accidentally वे URLs को redirect कर देते हैं जिन्हें वे redirect नहीं करना चाहते थे। Production में जाने से पहले हर pattern rule को staging पर test करें।
---
3. Staging Optional नहीं है
मैं इसे संक्षिप्त रखूंगा क्योंकि इसे ज्यादा explanation की जरूरत नहीं होनी चाहिए। हर migration को एक staging environment मिलता है। बस इतना ही।
Seahawk के पास 2022 में एक फिनटेक क्लायंट था जिसने इसके खिलाफ पुश बैक किया, चाहता था "बस इसे लाइव पर करो क्योंकि साइट छोटी है।" साइट के 6,000 पेज थे। हमने इसे स्टेजिंग पर किया। एक प्लगइन कॉन्फ्लिक्ट मिला जो सभी प्रोडक्ट पेजों से canonical tags स्ट्रिप कर रहा था। यह तब तक अदृश्य होता जब तक Google सब कुछ री-क्रॉल न करता, जो एक low-authority डोमेन पर हफ्तों लग सकते हैं।
Staging पर आप चेक कर रहे हैं:
- सभी redirects सही तरीके से काम करते हैं (मैं Screaming Frog को फिर से staging की ओर निर्देशित करके redirect map को bulk में verify करता हूँ)
- Robots.txt staging environment को index करने से block कर रहा है (महत्वपूर्ण, Disallow: / का उपयोग करें लेकिन double protection के लिए noindex header भी जोड़ें)
- नया sitemap सटीक है और इसमें staging URLs नहीं हैं
- Canonical tags सही production URLs की ओर pointing कर रहे हैं
- PageSpeed Insights के साथ page speed baselines, migrations को अक्सर redesign opportunities के रूप में उपयोग किया जाता है, और redesigns अक्सर Core Web Vitals को नष्ट कर देते हैं
---
4. Go-Live Sequence (क्रम आपके विचार से कहीं ज़्यादा महत्वपूर्ण है)
यह वह हिस्सा है जहाँ लोग freestyle करते हैं और अपने लिए समस्याएं create करते हैं। एक specific क्रम है। मैं इससे विचलित नहीं होता।
चरण 1: लॉन्च से पहले (48 घंटे पहले)
- सभी DNS रिकॉर्ड्स पर TTL को 300 सेकंड (5 मिनट) तक कम करें। इससे प्रोपेगेशन में काफी तेजी आती है।
- क्लाइंट को सूचित करें: माइग्रेशन विंडो के दौरान कोई कंटेंट बदलाव नहीं, नए पेज नहीं, प्लगइन अपडेट नहीं।
- किसी भी तीसरे पक्ष के इंटीग्रेशन (CDN, विज्ञापन प्लेटफॉर्म, मॉनिटरिंग टूल्स) को आने वाले बदलाव की सूचना दें।
चरण 2: लॉन्च विंडो
- DNS अपडेट करें
- नई content पूरी तरह propagate होने से पहले redirects deploy करें, redirects server level पर live होने चाहिए, सिर्फ WordPress में नहीं
- नया sitemap सक्षम करें, पुराना वाला बंद करें
- robots.txt सही है यह सत्यापित करें (प्रोडक्शन फाइल, स्टेजिंग वाली नहीं)
चरण 3: लॉन्च के तुरंत बाद
- नई साइट को दो घंटों के अंदर क्रॉल करें। Screaming Frog, production पर पॉइंटेड, redirects को रेस्पेक्ट करते हुए। मैं unexpected 404s, दो से ज्यादा hops वाली redirect chains, और कोई भी ऐसा पेज जो indexable होना चाहिए लेकिन noindex tag दिखा रहा है — ये सब ढूंढ रहा हूँ।
- नया sitemap Search Console में submit करें
- GSC के URL Inspection टूल के माध्यम से homepage को fetch करें ताकि Googlebot को विजिट करने के लिए prompt दिया जा सके
एक चीज़ जो मैं हमेशा clients को flag करता हूँ: Google तुरंत नए URLs को search results में reflect नहीं करेगा। Crawl और reprocessing में lag होता है। एक बड़ी site पर, इससे पहले कि आपको एक स्पष्ट picture मिले, दो से छह हफ्तों का budget रखें। चौथे दिन panic करना क्योंकि rankings shift हुई हैं—यह normal है, इसका मतलब यह नहीं है कि कुछ टूटा है।
---
5. Redirect Chain Auditing (वह Step जो ज्यादातर Agencies अलग से Bill करते हैं)
Redirect chains एक slow bleed हैं। एक URL जो A → B → C → D जाता है, वह Googlebot को extra work करने के लिए मजबूर कर रहा है, और यह multiple hops के across link equity को भी dilute कर रहा है। किसी ऐसी साइट पर जिसके कई पिछले migrations या platform switches हुए हैं, chains surprisingly गहरी हो सकती हैं।
Post-launch में, मैं full Screaming Frog crawl export करता हूँ और redirect chains के लिए filter करता हूँ। दो hops से कुछ भी beyond collapse हो जाता है। अगर original URL redirect map पर था, तो मैं इसे update करता हूँ ताकि यह सीधे final destination को point करे। अगर यह किसी migration से legacy chain था जिसे कोई documented नहीं करता था, तो मैं इसे add करता हूँ।
यह step अकेले, एक client पर जिसे हमने 2023 की शुरुआत में Magento से WooCommerce में migrate किया, को दो दिन लगे। उन्हें आठ सालों में तीन migrations हो चुके थे। कुछ URLs पांच redirects से गुज़र रहे थे सही page तक पहुँचने से पहले। सब कुछ collapse कर दिया, और उनके Search Console में crawl budget metrics एक महीने में काफ़ी बेहतर हुए।
---
6. बड़े पैमाने पर कंटेंट सत्यापन
आप 20,000 पेजों की मैनुअल समीक्षा नहीं कर सकते। लेकिन आप उन चीजों को व्यवस्थित रूप से सत्यापित कर सकते हैं जो मायने रखती हैं।
यहाँ वह चीजें हैं जो मैं लॉन्च के बाद पहले दो हफ्तों में जांचता हूँ:
- Title tags और meta descriptions: एक यादृच्छिक 200-पेज के नमूने की तुलना माइग्रेशन पूर्व Screaming Frog export से करें। विसंगतियों को तुरंत फ़्लैग करें।
- स्ट्रक्चर्ड डेटा: प्रोडक्ट पेजेस, आर्टिकल पेजेस, और होमपेज के एक सैंपल को Google के Rich Results Test से चलाओ। माइग्रेशन्स स्कीमा मार्कअप को अक्सर तोड़ते हैं, खासकर अगर नई थीम एक अलग प्लगइन का इस्तेमाल करती है।
- Internal linking: Screaming Frog क्रॉल करें, inlinks के लिए फ़िल्टर करें। उच्च-मूल्य वाले पेजों में अभी भी मजबूत internal link गिनती होनी चाहिए। यदि एक कैटेगरी पेज जिसके पास पहले 400 internal links थे अब 12 हैं, तो template में कुछ गलत हुआ।
- Images और alt text: सख्ती से SEO-महत्वपूर्ण नहीं है, लेकिन टूटी हुई images यूजर experience signals को नुकसान पहुंचाती हैं और templated sites पर इन्हें मिस करना आसान है।
---
7. 90 दिनों के बाद निगरानी
माइग्रेशन go-live दिन पर खत्म नहीं होता। यह कम से कम 90 दिनों तक चलता है।
मैंने पहले महीने के लिए क्लाइंट के साथ साप्ताहिक रिपोर्टिंग कैडेंस सेट अप किया, फिर उसके बाद पखवाड़े दर पखवाड़े। यहाँ मैं जो देख रहा हूँ:
- GSC Index Coverage: क्या इंडेक्स किए गए पेजों की संख्या माइग्रेशन से पहले की गिनती की ओर बहाल हो रही है? तीन हफ्ते से आगे बनी रहने वाली महत्वपूर्ण गिरावट की जांच की जरूरत है।
- Organic traffic vs. baseline: Landing page type के आधार पर segmented (product, category, blog)। Traffic drops अक्सर uneven होते हैं, कभी-कभी category pages tank हो जाते हैं जबकि product pages steady रहते हैं।
- Crawl budget: GSC की crawl stats report प्रति दिन crawl किए गए औसत पेज और server response times दिखाती है। अगर Googlebot को बहुत सारे 404s हिट कर रहे हैं, तो यह यहाँ दिखता है।
- Ranking position tracking: मैं Ahrefs rank tracking और Google Search Console की performance report का संयोजन उपयोग करता हूँ। पहले दो से तीन हफ्तों में ranking volatility आम है और जरूरी नहीं कि समस्या हो। चौथे हफ्ते से आगे की sustained drops कार्रवाई की माँग करते हैं।
- Backlink profile: Ahrefs का उपयोग करके, सत्यापित करें कि पुराने URLs की ओर इशारा करने वाले high-value backlinks या तो पहले से ही सही तरीके से redirect हो चुके हैं या अपडेट करने के लिए outreach के लिए फ्लैग किए गए हैं।
ईमानदार सच? अधिकांश migration SEO समस्याएं 30 दिनों के भीतर पता लगाई जा सकती हैं अगर आप सही मेट्रिक्स देख रहे हैं। जो लोगों को काटते हैं वे हैं जहाँ किसी ने monitoring सेट अप नहीं किया और क्लाइंट को आठ महीने बाद नोटिस हुआ।
---
8. जिन चीजों में मैंने गलती की है (ताकि आपको न करनी पड़े)
2019 में, मैंने एक client के लिए migration पर hreflang implementation को miss किया जिसके पास UK, Australian, और Canadian subfolders थे। Canonical tags सही थे। Redirects ठीक थे। लेकिन नई site पर hreflang annotations के पास गलत region codes थे, en-au की जगह en-AU (case apparently, कुछ implementations में, मायने रखता है)। Google UK pages को Australian searchers को serve करने लगा। हमें यह पता चलने में छह हफ्ते लगे कि Australian organic traffic आधा क्यों हो गया। तब से हमने हर international migration में एक hreflang validation step रखा है।
एक और बात: XML sitemaps जिनमें noindexed URLs हों। यह मामूली inconsistency लगती है पर conflicting signals भेजती है और सफाई के लायक है। Screaming Frog आपके sitemap का audit कर सकता है और sitemap में किसी भी ऐसे URL को flag कर सकता है जो noindex tag return करता हो।
और शायद सबसे महंगा सबक: rollback plan न होना। Migration जब गलत दिशा में जा रही हो, तो DNS को पुराने server पर एक घंटे के अंदर flip कर देने की क्षमता कीमती होती है। मैं हमेशा настаivah करता हूँ कि पुराना environment migration के बाद कम से कम 30 दिन तक live और intact रहे। Clients कभी-कभी hosting cost को लेकर अड़ते हैं। मैं समझाता हूँ कि 70% traffic drop revenue में क्या cost करता है और फिर वे अड़ना बंद कर देते हैं।
---
FAQ
20,000-page site migration को plan करने में actually कितना समय लगता है?
Realistically? Go-live date से पहले छह से दस हफ्ते की तैयारी। इतने बड़े site पर redirect map अकेले दो से तीन हफ्ते ले सकता है properly बनाने में, खासकर अगर हर URL के लिए backlinks का audit कर रहे हों। Preparation को rush करना इसी वजह से है कि आप महीनों recovery में फँस जाते हैं।
Migration के बाद क्या मुझे disavow file submit करनी होगी?
आमतौर पर नहीं, जब तक पुराने domain के पास toxic links न हों और आप specifically उन्हें escape करने के लिए migrate न कर रहे हों। अगर आप नए domain पर migrate कर रहे हैं और clean link profile चाहते हैं, तो disavow को GSC में नई property पर handle करें। लेकिन same domain पर ज्यादातर platform या redesign migrations के लिए, disavow irrelevant है।
बड़ी migrations पर agencies से आपको सबसे बड़ी गलती कौन सी दिखती है?
Redirect map को dev task की तरह treat करना। Redirects एक SEO task हैं जिसे एक developer implement करता है। SEO team, या जो कोई search strategy को own करता है, को map को own करना चाहिए, उसे review करना चाहिए, और sign off करना चाहिए। मैंने developers को technically correct redirect rules बनाते देखा है जो SEO-wrong थे क्योंकि किसी ने उन्हें नहीं बताया कि कौन सा URL variant canonical था।
क्या साइट की गति माइग्रेशन SEO को प्रभावित करती है?
हाँ, ज़्यादातर लोग account करते हैं उससे ज़्यादा। Core Web Vitals एक ranking factor हैं, और redesigns, जो अक्सर migrations के साथ आते हैं, अक्सर heavier JavaScript या unoptimised images introduce करते हैं। Launch से पहले हमेशा old और new site के बीच PageSpeed Insights comparison चलाएँ। अगर नई site mobile पर meaningfully slower है, तो इसे switch flip करने से पहले fix करें।
आप बहुत अधिक यूजर-जनरेटेड कंटेंट वाली साइटों के लिए माइग्रेशन को कैसे हैंडल करते हैं?
सावधानी के साथ। UGC पेज अक्सर अलग-अलग तो कम गुणवत्ता के होते हैं लेकिन सामूहिक रूप से लंबी-पूँछ वाली ट्रैफ़िक चलाते हैं। मैं आमतौर पर एक क्रॉल-एंड-एनालाइज़ स्टेप की सिफ़ारिश करता हूँ: पहचानें कि किन UGC URL के पास कोई भी ऑर्गेनिक ट्रैफ़िक है, उन्हें विशेष रूप से रीडायरेक्ट करें, और बाकी को 404 के रूप में छोड़ने के बजाय 410 से हटा दें। 410 Google को बताता है कि पेज जानबूझकर हट गया है; 404 अस्पष्ट है।
---
Migrations उन चीज़ों में से एक हैं जहाँ अच्छे और catastrophic के बीच का फ़र्क लगभग पूरी तरह preparation में है। Technical implementation आमतौर पर आसान हिस्सा है। Pre-launch work को सही करना, crawl, redirect map, staging verification—यहीं पर असली काम होता है। और अगर आपको कभी एक migration दिया जाता है जो पहले से ही live है और पहले से ही broken है, तो checklist अब भी लागू होती है। आप बस इसे reverse में कर रहे हैं।