Skip to main content

साइट माइग्रेशन के औज़ार: वे नौ जिन्हें हम उठाते हैं।

एक माइग्रेशन चार जगह टूटता है: रीडायरेक्ट मैप, डेटा इम्पोर्ट, वह स्क्रिप्टिंग जिसका बजट किसी ने नहीं रखा, और लॉन्च के बाद वाला हफ़्ता जब कोई साबित नहीं कर पाता कि क्या बदला। ये वे नौ औज़ार हैं जिन्हें हम उठाते हैं, हर एक क्या संभालता है, और वह टाइमलाइन में कहाँ बैठता है।

क्रीम रंग के कागज़ पर एक कतार में रखे सात छोटे मिट्टी के औज़ार, और उनके पास मिट्टी का एक तीर जो एक रास्ते को दो में बाँटता है
संक्षेप में
  1. एक माइग्रेशन चार अलग-अलग जगहों पर विफल होता है। रीडायरेक्ट मैप, डेटा इम्पोर्ट, वह स्क्रिप्टिंग जिसका बजट किसी ने नहीं रखा, और लॉन्च के बाद वाला हफ़्ता जब कोई साबित नहीं कर पाता कि क्या बदला। इनमें से तीन को संभालने वाला औज़ारों का सेट भी चौथे पर बहस हार जाता है।
  2. रीडायरेक्ट मैपिंग हाथ से सबसे बुरी तरह स्केल होती है। दस हज़ार URL हाथ से मिलाना हफ़्तों का काम है और गलती की दर तय है। पैसा खर्च करने की यह पहली जगह है, और वही इकलौती जगह जहाँ हर मिलान का भरोसा-स्कोर मिलान से भी ज़्यादा कीमती है।
  3. आधार-रेखा बाद में नहीं बनाई जा सकती। Search Console सोलह महीने का इतिहास रखता है और फिर वह चला जाता है। पेज-स्तर का एक्सपोर्ट कटओवर से पहले निकाल लीजिए, क्योंकि लॉन्च के बाद की पूरी बातचीत इसी पर होती है कि पहले आँकड़े क्या थे। वह एक ही चैनल संभालता है: AI क्रॉलर अपने ही समय पर चलते हैं और किसी इंटरफ़ेस में दिखते नहीं, इसलिए वह आधार-रेखा अलग से दर्ज करनी पड़ती है।
  4. कोई औज़ार यह तय नहीं करता कि कौन से रीडायरेक्ट मायने रखते हैं। यहाँ का हर औज़ार वह काम छोटा करता है जो कोई इंसान हाथ से करता। कोई भी यह तय नहीं करता कि कौन से रीडायरेक्ट मायने रखते हैं, कौन से पेज कमाई उठाते हैं, या ट्रैफ़िक की गिरावट माइग्रेशन है या मौसम।

इन चारों में से हर विफलता टाली जा सकती है

चारों पहले भी सुलझाए जा चुके हैं। फिर भी लॉन्च के दिन आ खड़े होते हैं, जब काम कार्यक्रम से आगे निकल जाता है और योजना में उन हिस्सों के लिए जगह नहीं बचती जो बुरी तरह स्केल होते हैं। नीचे के औज़ार वही हैं जो हर एक को क्रिटिकल पाथ से बाहर रखते हैं।

पहले रीडायरेक्ट मैप। फिर डेटा इम्पोर्ट, जो आम तौर पर तब पकड़ में आता है जब कोई श्रेणी पेज आधे उत्पादों के साथ खुलता है। तीसरे नंबर पर वह स्क्रिप्टिंग जिसे किसी ने अनुमान में नहीं रखा: URL का सामान्यीकरण, तीन सर्वर फ़ॉर्मैट में रीडायरेक्ट फ़ाइलें, कुछ सौ टेम्पलेट पर schema मार्कअप। चौथा लॉन्च के दो हफ़्ते बाद आता है, जब ट्रैफ़िक नीचे है और कोई साबित नहीं कर पाता कि वजह माइग्रेशन थी या नहीं।

01रीडायरेक्ट मैपहज़ारों पुराने URL, और सामने एक संरचना जो पुरानी से मेल नहीं खाती।
02डेटा इम्पोर्टउत्पाद, मीडिया और मेटाडेटा अधूरे आते हैं, गलत फ़ील्ड में आते हैं, या आते ही नहीं।
03बजट से बाहर की स्क्रिप्टिंगथोक रूपांतरण और वैलिडेटर, जिन्हें आँका नहीं गया बल्कि मान लिया गया।
04लॉन्च के बाद वाला हफ़्ताट्रैफ़िक हिलता है और उसे नापने के लिए कोई आधार-रेखा नहीं है।

नीचे के नौ औज़ार उन चारों को ढँकते हैं। ये हमारी अपनी मशीनों पर मौजूद औज़ार हैं, उसी क्रम में जिसमें एक माइग्रेशन इन्हें उठाता है।

वे नौ

01

Redirects.net

रीडायरेक्ट मैप
Redirects.net का डैशबोर्ड, जिसमें मिलाए गए URL जोड़े और उनके भरोसा-स्कोर दिख रहे हैं

पुराने URL को नए से मिलाना वह काम है जो हाथ से सबसे बुरी तरह स्केल होता है। Redirects.net दोनों सेट पढ़ता है और एक भाषा मॉडल से मिलान सुझाता है, जो उन संरचनाओं पर भी टिकता है जहाँ पैटर्न नियम हार जाते हैं: SKU धँसे हुए प्रोडक्ट स्लग, दोबारा जमाए गए श्रेणी पथ, पुराने URL जिन्हें कोई समझा नहीं सकता।

यह क्या करता है
हर स्रोत URL के लिए एक लक्ष्य सुझाता है और हर मिलान पर अपना भरोसा आँकता है। दसियों हज़ार URL मिनटों में निकल जाते हैं।
हम इसे क्यों लेते हैं
मिलान से ज़्यादा भरोसा-स्कोर। वह दस हज़ार पंक्तियों को उन कुछ सौ में बाँटता है जिन्हें इंसान चाहिए और बाकी में जिन्हें नहीं, और यही फ़र्क है मैप की समीक्षा करने और उसे बिना देखे मंज़ूर कर देने में।
यह कहाँ बैठता है
कटओवर से पहले, जैसे ही नई URL संरचना निर्यात करने लायक स्थिर हो जाए।
02

Claude Code

स्क्रिप्टिंग

हर माइग्रेशन दोहराने लायक इंजीनियरिंग का एक ढेर साथ लाता है जिसका अनुमान किसी ने नहीं लगाया। Claude Code, Anthropic का एजेंटिक कमांड-लाइन औज़ार है। यह रिपॉज़िटरी पढ़ता है, बदलाव की योजना बनाता है, कमांड चलाता है और पीछे एक ऐसा सत्र छोड़ता है जिसकी समीक्षा हो सके।

यह क्या करता है
थोक में URL सामान्यीकरण, एक ही स्रोत से Apache, Nginx और Cloudflare के लिए बनी रीडायरेक्ट फ़ाइलें, टेम्पलेट भर में schema मार्कअप, स्टेजिंग और प्रोडक्शन के बीच अंतर की जाँच।
हम इसे क्यों लेते हैं
यह अड़चन को खिसका देता है। जो काम पहले इंजीनियरिंग के एक हफ़्ते का इंतज़ार करता था, वह किसी अनुभवी की निगरानी में एक दोपहर बन जाता है, और नतीजा एक ब्लैक बॉक्स नहीं बल्कि एक diff होता है।
यह कहाँ बैठता है
शुरू से आख़िर तक। सबसे भारी कटओवर से पहले के दो हफ़्ते और उसके बाद का पहला हफ़्ता।
03

SEOGets

आधार-रेखा
SEOGets, समय के साथ पेज-स्तर पर Search Console का इतिहास दिखाते हुए

Search Console सोलह महीने रखता है, और उसका अपना इंटरफ़ेस पेज-स्तर का इतिहास काम लायक मात्रा में निकालना मुश्किल बनाता है। SEOGets उसे निकालता है और उस खिड़की के आगे तक ले जाता है।

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

WISLR.ai

AI आधार-रेखा
WISLR.ai का डैशबोर्ड: रोज़ का क्रॉल वॉल्यूम, OpenAI, Anthropic और Perplexity के बीच बँटवारा, और वे पेज जो उद्धरण के उम्मीदवार के तौर पर खींचे जा रहे हैं

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

यह क्या करता है
आपके ही डोमेन पर एज पर ट्रेनिंग क्रॉल, बातचीत के बीच होने वाले फ़ेच और AI रेफ़रल दर्ज करता है, पेज और इंजन के हिसाब से कवरेज बताता है, और सत्रों को ऑर्डर से जोड़ता है।
हम इसे क्यों लेते हैं
हर URL बदलने से मॉडल को साइट दोबारा सीखनी पड़ती है, और उसमें हफ़्ते लगते हैं। कटओवर से पहले की एक रीडिंग के बिना यह कहने का कोई रास्ता नहीं कि AI चैनल संभला या बस चुप हो गया।
यह कहाँ बैठता है
कटओवर से पहले लगाया जाता है, उसके बाद के हफ़्तों में ध्यान से देखा जाता है। मुफ़्त प्लान तीस लगातार दिन रखता है, जो आधार-रेखा बिठाने के लिए काफ़ी है।
05

Cloudflare

एज

प्लेटफ़ॉर्म की रीडायरेक्ट सीमाएँ बड़े माइग्रेशन में असली अड़चन हैं। Shopify और ज़्यादातर होस्टेड कार्ट सूची को वहाँ काट देते हैं जो पूरे कैटलॉग के खिसकने से बनी संख्या से बहुत नीचे है, और ऐप्लिकेशन में रखे नियम हर अनुरोध पर एक लुकअप का खर्च लाते हैं। Cloudflare मैप को एज पर, प्लेटफ़ॉर्म के आगे ले जाता है।

यह क्या करता है
प्लेटफ़ॉर्म जितना स्वीकारे उससे कहीं बड़े मैप के लिए Bulk Redirects, पैटर्न से दोबारा लिखने के लिए Transform Rules, और एज पर अनुरोध के लॉग, जहाँ क्रॉलर का व्यवहार सचमुच दिखता है।
हम इसे क्यों लेते हैं
रीडायरेक्ट मैप प्लेटफ़ॉर्म की समस्या नहीं रहता, इसलिए उसे बिना डिप्लॉय के पूरा बदला जा सकता है। लॉग भी उतने ही ज़रूरी हैं: वही इकलौता पूरा रिकॉर्ड हैं कि किसने क्या माँगा, और वे कटओवर के बाद भी बचे रहते हैं।
यह कहाँ बैठता है
निर्माण और कटओवर, और उसके बाद डिलीवरी परत के तौर पर टिका रहता है।
06

DigitalOcean

इंफ़्रास्ट्रक्चर

माइग्रेशन को चलने के लिए ऐसी जगह चाहिए जो प्रोडक्शन न हो: एक स्टेजिंग कॉपी जिस पर रीडायरेक्ट परखे जाएँ, एक मशीन जिस पर रूपांतरण चलें, और लॉन्च के बाद ट्रैफ़िक खिसकने पर बढ़ाने की गुंजाइश।

यह क्या करता है
स्टेजिंग वातावरण, माइग्रेशन स्क्रिप्ट और खुद प्रोडक्शन साइट के लिए Droplets, प्रबंधित डेटाबेस और App Platform।
हम इसे क्यों लेते हैं
अनुमान लगाने लायक कीमत और फ़ैसले से चलते वातावरण तक छोटा रास्ता। जिस स्टेजिंग मशीन की मंज़ूरी में एक खरीद-चक्र लगे, वह इस्तेमाल ही नहीं होती।
यह कहाँ बैठता है
पहले परीक्षण इम्पोर्ट से लेकर लॉन्च के बाद के हफ़्तों तक।
07

Row Zero

डेटा
Row Zero ब्राउज़र में एक बड़े URL डेटासेट को संभालते हुए

URL की सूचियाँ आम स्प्रेडशीट तोड़ देती हैं। मध्यम आकार के ईकॉमर्स कैटलॉग का पूरा क्रॉल लाखों पंक्तियों तक पहुँचता है, और जो औज़ार उसे खोले उसे फ़िल्टर और पिवट करते वक़्त भी चलता रहना होगा।

यह क्या करता है
डेस्कटॉप स्प्रेडशीट जहाँ अटक जाती है उससे कहीं आगे तक डेटासेट खोलता और संभालता है, उन्हीं सफ़ाई और रूपांतरण चरणों के साथ जो रीडायरेक्ट मैपिंग माँगती है।
हम इसे क्यों लेते हैं
माइग्रेशन का डेटा असंगत आता है, कई सिस्टम से और कई रूपों में। रीडायरेक्ट मैपिंग का ज़्यादातर हिस्सा कुछ भी मिलाने से पहले उसे एक जैसा बनाना ही है।
यह कहाँ बैठता है
रीडायरेक्ट मैप के साथ-साथ, और इम्पोर्ट की जाँच के दौरान दोबारा।
08

Plausible

लॉन्च के बाद
Plausible Analytics का डैशबोर्ड

कटओवर के बाद के पहले अड़तालीस घंटे वह खिड़की हैं जिसमें टूटा रीडायरेक्ट सस्ते में ठीक होता है। रिपोर्टिंग तुरंत होनी चाहिए और इतनी सरल कि दबाव में पढ़ी जा सके।

यह क्या करता है
हल्का, निजता का ध्यान रखने वाला एनालिटिक्स, जिसमें पेज, रेफ़रर और लक्ष्य के हिसाब से लाइव ट्रैफ़िक दिखता है और कोई कुकी बैनर सेट नहीं करना पड़ता।
हम इसे क्यों लेते हैं
पढ़ने की रफ़्तार। लॉन्च की रात का जो डैशबोर्ड तीन क्लिक और एक कस्टम रिपोर्ट माँगे, वह डैशबोर्ड रात दो बजे कोई नहीं देखता।
यह कहाँ बैठता है
कटओवर से पहले लगाया जाता है, बाद के पहले हफ़्ते ध्यान से देखा जाता है।
09

The SEO Community Slack

लोग
The SEO Community का Slack वर्कस्पेस

माइग्रेशन की कुछ दिक्कतें किसी दस्तावेज़ में नहीं होतीं, क्योंकि वे किसी प्लेटफ़ॉर्म संस्करण, किसी प्लगइन या ऐसे मेल से जुड़ी होती हैं जिसे किसी ने लिखा ही नहीं। उन जवाबों तक सबसे तेज़ रास्ता वह व्यक्ति है जो पिछली तिमाही इसी से टकराया था।

यह क्या करता है
एक Slack वर्कस्पेस, जिसमें तकनीकी SEO, Search Console और ईकॉमर्स के चैनल हैं। अकेले तकनीकी SEO चैनल में साढ़े तीन हज़ार से ज़्यादा सदस्य हैं।
हम इसे क्यों लेते हैं
कटओवर से पहले समझदारी की जाँच, और उसके दौरान दूसरी राय। तारीख़ जितनी पास आती है, दोनों की कीमत उतनी बढ़ती है।
यह कहाँ बैठता है
योजना बनाते वक़्त, और लॉन्च की रात ग्यारह बजे एक बार फिर।

हर एक कहाँ बैठता है

क्रम सूची से ज़्यादा मायने रखता है। इनमें से दो की समय-सीमा है: Search Console की आधार-रेखा और स्टेजिंग वातावरण, दोनों DNS हटते ही उपलब्ध नहीं रहते।

चरणऔज़ारकिसलिए
योजनाSEOGets, WISLR.ai, Row Zero, Slackदोनों आधार-रेखाएँ जब तक मौजूद हैं तब तक दर्ज करना, URL की सूची बनाना, योजना को कसकर परखना।
निर्माणRedirects.net, Claude Code, Cloudflare, DigitalOceanरीडायरेक्ट मिलाना, रूपांतरण की स्क्रिप्ट लिखना, एज के नियम तैयार करना, सब पहले एक कॉपी पर चलाना।
कटओवरCloudflare, Plausible, Claude Codeमैप एज पर चढ़ाना, लाइव ट्रैफ़िक देखना, टूटे नियम तब ठीक करना जब यह सस्ता है।
उसके बादSEOGets, WISLR.ai, Plausibleदोनों चैनलों को उनकी आधार-रेखाओं से मिलाकर तय करना कि माइग्रेशन ने क्या किया।
कटओवर से पहले

माइग्रेशन की गहराई से जाँच हमसे कराइए।

हम रीडायरेक्ट मैप को लाइव होने से पहले देखते हैं, स्टेजिंग पर क्रॉल और रेंडरिंग का रास्ता जाँचते हैं, आधार-रेखा तब दर्ज करते हैं जब Search Console उसे अब भी रखे हुए है, और पहले हफ़्तों को उस टैग से नहीं बल्कि सर्वर लॉग से पढ़ते हैं जो शायद कभी चले ही नहीं। आपको निष्कर्ष मिलते हैं, उनकी गंभीरता, और उन्हें ठीक करने का क्रम।

जाँच में क्या शामिल है →

यह सूची क्या नहीं करती

यहाँ का हर औज़ार वह काम छोटा करता है जो कोई इंसान हाथ से करता। कोई भी यह तय नहीं करता कि कौन से रीडायरेक्ट मायने रखते हैं। एक औज़ार किसी मिलान को साठ प्रतिशत भरोसे पर आँकता है और वहीं रुक जाता है। वह URL बंद हो चुका उत्पाद है जिसे कोई नहीं खोजता, या वह पेज है जो अपनी श्रेणी की कमाई का पाँचवाँ हिस्सा उठाता है, यह विवेक का सवाल है, और किसी भी दिशा में गलती महँगी पड़ती है।

लॉन्च के बाद वाले हफ़्ते के लिए भी यही सच है। एनालिटिक्स गिरावट बता देता है। यह तय करना कि वजह माइग्रेशन है, मौसम है, या उसी हफ़्ते आया कोई एल्गोरिद्म अपडेट, उस व्यक्ति का काम है जिसने यह पैटर्न पहले देखा हो।

कुछ सौ URL से नीचे इसमें से ज़्यादातर की ज़रूरत ही नहीं। एक क्रॉल, एक स्प्रेडशीट और एक ध्यान से बिताई दोपहर काम कर देगी। यह सूची पैमाने पर और सबूत पर अपनी कीमत निकालती है, और Search Console का एक्सपोर्ट हर आकार पर निकालने लायक है, क्योंकि वह इतिहास तो चला ही जाता है, चाहे आपने किसी चीज़ के पैसे दिए हों या नहीं।

WISLR के साथ काम कीजिए

हमारी माइग्रेशन टीम अपनी टीम में जोड़िए।

हमने सौ से ज़्यादा साइट माइग्रेशन किए हैं, और हम उसी टीम के साथ काम करते हैं जो आपके पास पहले से है। रीडायरेक्ट रणनीति और मैपिंग, schema और रेंडरिंग, और सर्वर लॉग से यह सबूत कि कटओवर से पहले और बाद में क्रॉलर और खरीदारों ने क्या किया।

हम कैसे काम करते हैं →