तीन साल पहले मुझे एक माइग्रेशन सौंपा गया जो पहले से ही लाइव था। कोई स्टेजिंग एनवायरनमेंट नहीं। कोई रीडायरेक्ट मैप नहीं। एक 22,000-पेज ई-कॉमर्स कैटलॉग जिसे किसी ने बस एक नए डोमेन की ओर पॉइंट कर दिया था और इसे "पूरा" कह दिया था। ऑर्गेनिक ट्रैफिक छः हफ्तों में 74% गिर गया। क्लाइंट ने मुझे हल्के पैनिक में कॉल किया, और मैंने करीब चार महीने इसे सुलझाने में लगाए।
मुख्य बात यह है: साइट माइग्रेशन में रैंकिंग खोने का कारण प्लेटफॉर्म बदलना नहीं, बल्कि रीडायरेक्ट ऑडिट को छोड़ना है; चेकलिस्ट में रीडायरेक्ट मैप, मेटाडेटा ट्रांसपोर्ट, स्कीमा कंटिन्यूटी और पोस्ट-लॉन्च वेरिफिकेशन शामिल है।Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.
वह अनुभव -- जितना दर्दनाक था -- मूलतः इसी कारण यह चेकलिस्ट मौजूद है। मैंने तब से 800-पेज वाली ब्रोशरवेयर से लेकर 31,000-पेज वाले पब्लिशर साइटों तक माइग्रेट किया है जिनमें रीजनल सबडोमेन हैं, और हर बार फंडामेंटल्स एक जैसे ही रहते हैं। अगर ऑर्डर गलत हो, एक स्टेप स्किप हो, तो Google आपको इसके बारे में Search Console में सबसे अप्रिय तरीके से बताएगा।
तो यह रही। वह असल चेकलिस्ट जो मैं Seahawk Media में इस्तेमाल करता हूँ, कोई सैद्धांतिक ढाँचा नहीं।Seahawk Media, not a theoretical framework.
---
1. किसी भी चीज़ को छूने से पहले पूरी साइट का क्रॉल करें
स्पष्ट? हाँ। छोड़ा जाता है? लगातार।
एक भी फाइल मूव होने से पहले, मैं पूरी लाइव साइट को Screaming Frog SEO Spider से क्रॉल करता हूँ। 20,000-पेज की साइट पर इसमें एक-दो घंटे लगते हैं -- मैं आमतौर पर इसे रात भर चलने देता हूँ, क्रॉल को डेटाबेस मोड में स्टोर करके ताकि मेमोरी समस्या न बने। जो कुछ मैं कैप्चर कर रहा हूँ:Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- हर 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, जाहिरी तौर पर) ताकि कुछ भी बदलने से पहले आपके ऑर्गेनिक ट्रैफिक बेंचमार्क लॉक हों। स्क्रीनशॉट यहाँ ठीक काम करते हैं; मैं रॉ CSVs भी एक्सपोर्ट करता हूँ।Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. Redirect Map बनाएँ। फिर इसे दोबारा चेक करें।
यह वह जगह है जहाँ माइग्रेशन सफल होते हैं या असफल। बड़ी साइटों पर, रीडायरेक्ट मैप एक असली स्प्रेडशीट होता है -- आमतौर पर Google Sheets में क्लाइंट, उनकी dev टीम, और किसी और के साथ शेयर किया जाता है जो शायद 11pm पर कोई फॉर्मूला ओवरराइट कर सकता है।
संरचना सरल है:
- 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 पेजों को मैप करें
- किसी भी URL को मैप करें जिसके पास मीनिंगफुल बैकलिंक्स हैं (इसके लिए Ahrefs का इस्तेमाल करें -- रेफरिंग डोमेन्स के हिसाब से फ़िल्टर करें, सिर्फ रॉ लिंक्स नहीं)Ahrefs for this -- filter by referring domains, not just raw links)
- बाकी सब कुछ के लिए pattern-based redirects को संभालें (उदाहरण के लिए, /product/old-slug/ → /shop/old-slug/)
/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 पेज थे। हमने इसे स्टेजिंग पर किया। एक प्लगइन कॉन्फ्लिक्ट मिला जो सभी प्रोडक्ट पेजों से कैनोनिकल टैग्स को स्ट्रिप कर रहा था। यह Google के री-क्रॉल तक अदृश्य रहता, जो कम-अथॉरिटी डोमेन पर हफ्तों ले सकता है।
Staging पर आप चेक कर रहे हैं:
- सभी redirects सही तरीके से काम करते हैं (मैं Screaming Frog को फिर से staging की ओर निर्देशित करके redirect map को bulk में verify करता हूँ)
- Robots.txt स्टेजिंग एनवायरनमेंट को इंडेक्स होने से ब्लॉक कर रहा है (महत्वपूर्ण -- Disallow: / का उपयोग करें लेकिन डबल सुरक्षा के लिए noindex हेडर भी जोड़ें)
Disallow: /but also add a noindex header for double protection) - नया sitemap सटीक है और इसमें staging URLs नहीं हैं
- Canonical tags सही production URLs की ओर pointing कर रहे हैं
- PageSpeed Insights के साथ पेज स्पीड बेसलाइन -- माइग्रेशन अक्सर रीडिज़ाइन के मौके के रूप में उपयोग किए जाते हैं, और रीडिज़ाइन अक्सर Core Web Vitals को नष्ट कर देते हैंPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy Core Web Vitals
---
4. Go-Live Sequence (क्रम आपके विचार से कहीं ज़्यादा महत्वपूर्ण है)
यह वह हिस्सा है जहाँ लोग freestyle करते हैं और अपने लिए समस्याएं create करते हैं। एक specific क्रम है। मैं इससे विचलित नहीं होता।
चरण 1: लॉन्च से पहले (48 घंटे पहले)
- सभी DNS रिकॉर्ड्स पर TTL को 300 सेकंड (5 मिनट) तक कम करें। इससे प्रोपेगेशन में काफी तेजी आती है।
- क्लाइंट को सूचित करें: माइग्रेशन विंडो के दौरान कोई कंटेंट बदलाव नहीं, नए पेज नहीं, प्लगइन अपडेट नहीं।
- किसी भी तीसरे पक्ष के इंटीग्रेशन (CDN, विज्ञापन प्लेटफॉर्म, मॉनिटरिंग टूल्स) को आने वाले बदलाव की सूचना दें।
चरण 2: लॉन्च विंडो
- DNS अपडेट करें
- नई कंटेंट पूरी तरह प्रोपेगेट होने से पहले रीडायरेक्ट्स डिप्लॉय करें -- रीडायरेक्ट्स सर्वर लेवल पर लाइव होने चाहिए, सिर्फ WordPress में नहीं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 दिया जा सके
एक चीज़ जो मैं हमेशा क्लाइंट्स को फ्लैग करता हूँ: Google सर्च रिजल्ट्स में नई URLs को तुरंत रिफ्लेक्ट नहीं करेगा। क्रॉल और रीप्रोसेसिंग में लैग होता है। बड़ी साइट पर, दो से छह हफ्तों का बजट रखें इससे पहले कि आपको स्पष्ट तस्वीर मिले। चौथे दिन घबराना क्योंकि रैंकिंग्स शिफ्ट हुई हैं -- यह नॉर्मल है। इसका मतलब यह नहीं है कि कुछ टूटा है।
---
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 करता हूँ।
यह स्टेप ही -- एक क्लाइंट पर जिसे हमने 2023 की शुरुआत में Magento से WooCommerce में माइग्रेट किया -- दो दिन लगे। उनके पास आठ साइलों में तीन माइग्रेशन हो चुके थे। कुछ URLs सही पेज पर पहुँचने से पहले पाँच रीडायरेक्ट्स से गुज़र रहे थे। सब को कोलैप्स किया, और उनके Search Console में क्रॉल बजट मेट्रिक्स एक महीने में नोटिसेबली इम्प्रूव हुई।
---
6. बड़े पैमाने पर कंटेंट सत्यापन
आप 20,000 पेजों की मैनुअल समीक्षा नहीं कर सकते। लेकिन आप उन चीजों को व्यवस्थित रूप से सत्यापित कर सकते हैं जो मायने रखती हैं।
यहाँ वह चीजें हैं जो मैं लॉन्च के बाद पहले दो हफ्तों में जांचता हूँ:
- Title tags और meta descriptions: एक यादृच्छिक 200-पेज के नमूने की तुलना माइग्रेशन पूर्व Screaming Frog export से करें। विसंगतियों को तुरंत फ़्लैग करें।: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- स्ट्रक्चर्ड डेटा: प्रोडक्ट पेजेस, आर्टिकल पेजेस, और होमपेज के एक सैंपल को Google के Rich Results Test से चलाओ। माइग्रेशन्स स्कीमा मार्कअप को अक्सर तोड़ते हैं, खासकर अगर नई थीम एक अलग प्लगइन का इस्तेमाल करती है।: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- Internal linking: Screaming Frog क्रॉल करें, inlinks के लिए फ़िल्टर करें। उच्च-मूल्य वाले पेजों में अभी भी मजबूत internal link गिनती होनी चाहिए। यदि एक कैटेगरी पेज जिसके पास पहले 400 internal links थे अब 12 हैं, तो template में कुछ गलत हुआ।: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
- Images और alt text: सख्ती से SEO-महत्वपूर्ण नहीं है, लेकिन टूटी हुई images यूजर experience signals को नुकसान पहुंचाती हैं और templated sites पर इन्हें मिस करना आसान है।: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
7. 90 दिनों के बाद निगरानी
माइग्रेशन go-live दिन पर खत्म नहीं होता। यह कम से कम 90 दिनों तक चलता है।
मैंने पहले महीने के लिए क्लाइंट के साथ साप्ताहिक रिपोर्टिंग कैडेंस सेट अप किया, फिर उसके बाद पखवाड़े दर पखवाड़े। यहाँ मैं जो देख रहा हूँ:
- GSC Index Coverage: क्या इंडेक्स किए गए पेजों की संख्या माइग्रेशन से पहले की गिनती की ओर बहाल हो रही है? तीन हफ्ते से आगे बनी रहने वाली महत्वपूर्ण गिरावट की जांच की जरूरत है।: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- ऑर्गेनिक ट्रैफिक बनाम बेसलाइन: लैंडिंग पेज टाइप के अनुसार सेगमेंटेड (प्रोडक्ट, कैटेगरी, ब्लॉग)। ट्रैफिक ड्रॉप्स अक्सर असमान होते हैं -- कभी-कभी कैटेगरी पेजेस टैंक होते हैं जबकि प्रोडक्ट पेजेस होल्ड करते हैं।: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
- Crawl budget: GSC की crawl stats report प्रति दिन crawl किए गए औसत पेज और server response times दिखाती है। अगर Googlebot को बहुत सारे 404s हिट कर रहे हैं, तो यह यहाँ दिखता है।: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- Ranking position tracking: मैं Ahrefs rank tracking और Google Search Console की performance report का संयोजन उपयोग करता हूँ। पहले दो से तीन हफ्तों में ranking volatility आम है और जरूरी नहीं कि समस्या हो। चौथे हफ्ते से आगे की sustained drops कार्रवाई की माँग करते हैं।: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
- Backlink profile: Ahrefs का उपयोग करके, सत्यापित करें कि पुराने URLs की ओर इशारा करने वाले high-value backlinks या तो पहले से ही सही तरीके से redirect हो चुके हैं या अपडेट करने के लिए outreach के लिए फ्लैग किए गए हैं।: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
ईमानदार सच? अधिकांश migration SEO समस्याएं 30 दिनों के भीतर पता लगाई जा सकती हैं अगर आप सही मेट्रिक्स देख रहे हैं। जो लोगों को काटते हैं वे हैं जहाँ किसी ने monitoring सेट अप नहीं किया और क्लाइंट को आठ महीने बाद नोटिस हुआ।
---
8. जिन चीजों में मैंने गलती की है (ताकि आपको न करनी पड़े)
2019 में वापस, मैंने एक क्लाइंट के लिए माइग्रेशन पर hreflang इम्प्लीमेंटेशन मिस किया जिसके पास UK, Australian, और Canadian सबफोल्डर्स थे। कैनोनिकल टैग्स सही थे। रीडायरेक्ट्स ठीक थे। लेकिन नई साइट पर hreflang एनोटेशन्स में गलत रीजन कोड्स थे -- en-au की जगह en-AU (कुछ इम्प्लीमेंटेशन्स में केस मायने रखता है)। Google Australian सर्चर्स को UK पेजेस सर्व करने लगा। Australian ऑर्गेनिक ट्रैफिक आधी क्यों हुई इसका पता लगाने में हमें छह हफ्ते लगे। हर इंटरनेशनल माइग्रेशन से पहले हमारे पास hreflang वैलिडेशन स्टेप है।en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
एक और बात: 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 से आपको सबसे बड़ी गलती कौन सी दिखती है?
रीडायरेक्ट मैप को dev टास्क के रूप में ट्रीट करना। रीडायरेक्ट्स एक SEO टास्क हैं जिसे एक डेवलपर इम्प्लीमेंट करता है। SEO टीम -- या जो भी सर्च स्ट्रैटेजी को ओन करता है -- को मैप को ओन करना चाहिए, रिव्यू करना चाहिए, और साइन-ऑफ करना चाहिए। मैंने डेवलपर्स को टेक्निकली करेक्ट रीडायरेक्ट रूल्स बिल्ड करते देखा है जो SEO-गलत थे क्योंकि किसी ने उन्हें नहीं बताया कि कौन सी URL वेरिएंट कैनोनिकल थी।
क्या साइट की गति माइग्रेशन SEO को प्रभावित करती है?
हाँ, ज्यादातर लोग जिनका एकाउंट ले सकते हैं। Core Web Vitals एक रैंकिंग फैक्टर हैं, और रीडिज़ाइन्स -- जो अक्सर माइग्रेशन के साथ आती हैं -- अक्सर हैवियर JavaScript या अनऑप्टिमाइज़्ड इमेजेस इंट्रोड्यूस करते हैं। लॉन्च से पहले हमेशा पुरानी और नई साइट के बीच PageSpeed Insights कम्पेरिजन चलाएँ। अगर नई साइट मोबाइल पर सार्थक रूप से स्लोअर है, तो स्विच फ्लिप करने से पहले इसे ठीक करें।
आप बहुत अधिक यूजर-जनरेटेड कंटेंट वाली साइटों के लिए माइग्रेशन को कैसे हैंडल करते हैं?
सावधानी के साथ। UGC पेज अक्सर अलग-अलग तो कम गुणवत्ता के होते हैं लेकिन सामूहिक रूप से लंबी-पूँछ वाली ट्रैफ़िक चलाते हैं। मैं आमतौर पर एक क्रॉल-एंड-एनालाइज़ स्टेप की सिफ़ारिश करता हूँ: पहचानें कि किन UGC URL के पास कोई भी ऑर्गेनिक ट्रैफ़िक है, उन्हें विशेष रूप से रीडायरेक्ट करें, और बाकी को 404 के रूप में छोड़ने के बजाय 410 से हटा दें। 410 Google को बताता है कि पेज जानबूझकर हट गया है; 404 अस्पष्ट है।
---
माइग्रेशन्स उन चीज़ों में से एक हैं जहाँ गुड और कैटास्ट्रॉफिक के बीच का अंतर लगभग पूरी तरह प्रीपेरेशन में है। टेक्निकल इम्प्लीमेंटेशन आमतौर पर आसान हिस्सा है। प्री-लॉन्च वर्क को सही पाना -- क्रॉल, रीडायरेक्ट मैप, स्टेजिंग वेरिफिकेशन -- यही वास्तविक काम है। और अगर आपको कभी एक माइग्रेशन सौंपा जाता है जो पहले से लाइव है और पहले से टूटा हुआ है, तो चेकलिस्ट अभी भी लागू होती है। आप बस इसे रिवर्स में कर रहे हैं।