2021 में, एक बड़े UK retailer ने Seahawk को 22,000 से ज़रा ज्यादा indexed URLs वाली एक साइट के लिए migration का काम दिया। dev team चार महीने से नए platform पर काम कर रहा था। उनके पास launch date था। उनके पास staging site था। जो उनके पास नहीं था, और सच में सोचा ही नहीं था, वह था redirect map। न ही कोई rough version। न ही कुछ भी। SEO lead की plan यह था कि "launch के बाद handle कर देंगे।" मैं अभी भी उस meeting के बारे में सोचता हूँ कभी-कभी।
मुख्य बात: 20,000 URL माइग्रेशन रीडायरेक्ट मैप पर निर्भर करता है — इसे नई साइट बनने से पहले Search Console और क्रॉल डेटा से तैयार करें, और यह सुनिश्चित करें कि हर हॉप सिंगल है।
हमने लॉन्च को तीन हफ्ते आगे बढ़ा दिया। पूरी तरह से रीडायरेक्ट स्ट्रेटेजी फिर से बनाई। साइट सफाई के साथ लॉन्च हुई, ट्रांजिशन के दौरान 94% ऑर्गेनिक ट्रैफिक रखी, और क्लाइंट ने हमें Scotch की एक बोतल भेजी। तीन हफ्े की देरी ने उन्हें उस चीज से बचा दिया जो लगभग निश्चित रूप से छह महीने की रिकवरी की एक लंबी यात्रा होती।
तो। यहाँ है कि आप इस स्केल पर एक साइट के लिए redirect map कैसे बनाते हो — प्रक्रिया, tools, prioritisation logic, और वह हिस्से जो ज्यादातर migration guides चुपचाप छोड़ देती हैं।
---
एक संपूर्ण URL इन्वेंटरी के साथ शुरू करें
आप जिसकी गिनती नहीं किए हो उसे map नहीं कर सकते। किसी भी चीज़ से पहले, आपको origin site के हर live, indexed URL का पूरा export चाहिए। सिर्फ sitemap नहीं। Sitemaps झूठ बोलते हैं, वे अक्सर outdated होते हैं, वे paginated URLs को exclude करते हैं, और वे उन product या archive pages को छोड़ देते हैं जिन्होंने साल भर में links जमा किए हैं।
मैं Screaming Frog SEO Spider को list mode में एक combined source के विरुद्ध चलाता हूँ: XML sitemap साथ में Google Search Console का export सभी indexed URLs का। ये दोनों sources मिलकर लगभग हमेशा URLs surface करते हैं जो दूसरा miss करता है। 20,000-URL वाली साइट के लिए, actual crawl count कहीं भी 18,000 और 35,000 के बीच आएगा — pagination, filters, faceted nav, सब कुछ।
crawl को एक spreadsheet में export करें। आपको कम से कम चाहिए: URL, HTTP status, title tag, H1, inbound internal links count, और चाहे यह GSC में impressions के साथ दिखाई दे। यह आखिरी column लोगों द्वारा स्वीकार किए जाने से कहीं ज्यादा महत्वपूर्ण है।
उन 404s को भूल मत जाइए जो अभी भी traffic पाते हैं।
जब आप GSC में हों, तो Coverage report निकालिए और हर वह URL लीजिए जिसे Google ने पिछले छह महीनों में crawl करने की कोशिश की है, existing 404s सहित। कुछ broken pages के पास अभी भी उन्हें point करने वाली external backlinks हैं। मैंने एक 404 देखा है जिसके पास 40 referring domains थे एक साइट पर जिसे दो साल से maintain नहीं किया गया था। उन्हें भी destination चाहिए।
---
Mapping से पहले Categorise करें
20,000 URLs की एक flat list unusable है। Crawl export के बाद पहली चीज़ जो मैं करता हूँ वह है हर URL को type के आधार पर categorise करना, क्योंकि mapping logic completely different होती है इस बात के आधार पर कि URL क्या है।
यहाँ वह rough taxonomy है जो मैं use करता हूँ:
- Product pages, नए product URL से 1:1 map करें जहाँ संभव हो
- Category / collection pages, equivalent नए category को map करें, या nearest parent को
- Blog posts / articles, slug से match करें, title similarity से, या topic cluster से
- टैग और आर्काइव पेज, आमतौर पर कैटेगरी या होमपेज में समेकित करें
- पेजिनेटेड URLs (जैसे
/category/shoes/page/3), लगभग हमेशा → पैरेंट कैटेगरी - यूजर-जेनरेटेड या अकाउंट URLs, आमतौर पर छोड़ें या लॉगिन पर रीडायरेक्ट करें
- पुराने कैंपेन लैंडिंग पेज, रीडायरेक्ट का फैसला करने से पहले लिंक इक्विटी का मूल्यांकन करें
- डुप्लिकेट/कैनोनिकल वेरिएंट, कैनोनिकल पर रीडायरेक्ट करें, बस इतना ही
Google Sheets में dropdown column के साथ यह categorisation स्टेप करना कुछ घंटे लेता है। यह दिन बचाता है। एक बार जब सब कुछ type हो जाए, तो आप 20,000 अलग-अलग फैसलों के बजाय प्रत्येक श्रेणी पर अलग rule set लागू कर सकते हैं।
---
मिलान चरण: स्वचालित पहले, मैनुअल दूसरा
यहीं पर ज्यादातर टीमें गलती करती हैं। वे हर URL को मैन्युअली मैच करने की कोशिश करते हैं। 20,000 rows के साथ यह बस एक नर्वस ब्रेकडाउन की प्रतीक्षा है, थोरोनेस नहीं।
मेरी प्रक्रिया पहले ऑटोमेटेड मैचिंग है, दूसरे मैनुअल रिव्यू, सिर्फ उन URLs के लिए जो वाकई मायने रखते हैं।
VLOOKUP और Python के साथ ऑटोमेटेड मैचिंग
उन साइट्स के लिए जहाँ पुरानी और नई URL स्ट्रक्चर समान हों (जैसे /products/red-shoes/ से /shop/red-shoes/ बदलना), Sheets में slug के हिस्से पर एक सिंपल VLOOKUP दस मिनट में लिस्ट का 60-70% सॉर्ट कर देता है। Regex-based find/replace स्ट्रक्चरल पैटर्न चेंज को हैंडल करता है।
ज्यादा जटिल माइग्रेशन, प्लेटफॉर्म बदलाव, पूरे IA रीडिज़ाइन के लिए मैं एक छोटी सी Python स्क्रिप्ट यूज करता हूँ जो पुरानी क्रॉल एक्सपोर्ट और नई साइट की क्रॉल के बीच पेज टाइटल पर fuzzy string मैचिंग करती है। thefuzz लाइब्रेरी (पहले FuzzyWuzzy) इसे अच्छी तरह करती है। 85% के ऊपर कोई भी मैच स्कोर ऑटो-असाइन हो जाता है। नीचे का सब कुछ मैनुअल रिव्यू क्यू में जाता है।
मैनुअल क्यू आमतौर पर लिस्ट का 20-30% होता है। इसे पूरी तरह सीनियर अटेंशन की जरूरत नहीं होती।
मैन्युअल क्यू को प्रायोरिटाइज करना
सभी 20,000 URLs को बराबर टाइम नहीं मिलना चाहिए। मैं हर URL को स्कोर करता हूं:
- पिछले 90 दिनों में GSC impressions, अगर यह सर्च ट्रैफिक ला रहा है, तो यह हाई प्रायोरिटी है
- रेफरिंग डोमेन की संख्या (Ahrefs से ली गई), लिंक इक्विटी जिसे आप खोना नहीं सकते
- क्रॉल से इंटरनल लिंक काउंट, संरचनात्मक महत्व का संकेत
- राजस्व attribution, अगर क्लाइंट GA4 ecommerce डेटा प्रदान कर सकता है, तो conversions चलाने वाले पेज शीर्ष पर चले जाते हैं
impressions, backlinks या revenue वाली किसी भी चीज़ को एक ह्यूमन मैपिंग डिसीजन मिलता है। बाकी सब कुछ एक rule-based fallback को फॉलो कर सकता है (आमतौर पर → parent category या homepage)। ईमानदारी से कहूँ, एक 20,000-URL साइट के लिए, शायद 800-1,200 URLs को वाकई में इंडिविजुअल अटेंशन चाहिए। बाकी सब long-tail cruft है।
---
Redirect Map Document को संरचित करना
अंतिम map एक spreadsheet में रहता है। सरल। इस स्तर पर कोई clever tooling की ज़रूरत नहीं है, फ़ाइल सिर्फ़ स्पष्ट और importable होनी चाहिए।
मैं जिन columns का उपयोग करता हूँ:
- Source URL (पूरा, old page का absolute URL)
- Destination URL (पूरा, new page का absolute URL)
- Redirect type (लगभग हर मामले में 301, 302 केवल genuinely temporary के लिए, जो दुर्लभ है)
- मिलान प्रकार (exact / pattern / regex)
- श्रेणी (वर्गीकरण चरण से)
- Priority tier (High / Medium / Low, ऊपर दिए गए scoring के आधार पर)
- स्थिति (Pending / Confirmed / Implemented / Tested)
- नोट्स
वह "Notes" column कम आंका हुआ है। यह वह जगह है जहाँ आप "client confirmed this product is discontinued, redirect to category" या "backlink from Forbes pointing here, map to closest equivalent not homepage" जैसी चीज़ें डालते हैं। भविष्य का आप वर्तमान आप को धन्यवाद देगा।
source URLs को बिल्कुल वैसे रखें जैसे वे दिखाई देते हैं, trailing slash के साथ या बिना, query strings के साथ यदि लागू हो। यहाँ inconsistency partial matches और missed redirects का कारण बनती है जो launch के बाद diagnose करने में nightmare है।
---
पैटर्न-आधारित बनाम Exact रीडायरेक्ट्स
इस scale पर आपको absolutely pattern-based redirects चाहिए, सिर्फ़ exact-match वाले नहीं। एक .htaccess फ़ाइल में 20,000 individual Redirect 301 lines लिखना, ठीक है, यह काम करता है, लेकिन यह fragile है, parse करने में slow है, और एक maintenance disaster है।
Apache/WordPress सेटअप के लिए, मैं structural patterns के लिए regex-आधारित RewriteRules का उपयोग करता हूँ। उदाहरण के लिए, अगर /old-blog/[post-slug]/ के तहत हर पुराना URL /insights/[post-slug]/ पर map करता है, तो वह एक rule है, 4,000 नहीं।
Nginx पर, same principle rewrite directives के साथ लागू होता है। Cloudflare पर, आप Bulk Redirects का उपयोग कर सकते हैं (उनका free tier 20 exact-match rules तक handle करता है; Workers या paid Redirect Rules product scale पर pattern logic को handle करता है)।
Map document को flag करना चाहिए कि कौन से redirects pattern-eligible हैं बनाम कौन से exact matching की जरूरत है। आमतौर पर: blog posts, products, और category pages patterns का पालन करते हैं। पुराने campaign pages, legacy subdomains, और weird historical URLs को exact matching की जरूरत है।
Pattern को live होने से पहले test करें।
मैं पूरे pattern rule set को staging environment में URL list के विरुद्ध चलाता हूँ और Redirect Checker (bulk) या bash में एक curl loop जैसे tool से हर redirect response को log करता हूँ। हर chain redirect (old → interim → new) एक समस्या है, Google chains को follow करेगा लेकिन हर hop पर कुछ link equity खो देता है। Launch से पहले उन्हें flatten करें।
---
लंबी पूँछ को संभालना: Fallback Strategy
20,000-URL site के बारे में यह बात है, उनमें से कुछ हज़ार URLs को शायद zero traffic है, zero backlinks हैं, और कोई भी उन्हें दोबारा visit करने का कोई कारण नहीं है। उन सभी को homepage पर redirect करना एक अलग समस्या बनाता है: यह Google को manipulative दिखता है, और यह users को confuse करता है जिन्होंने एक specific link को follow किया।
मेरी fallback hierarchy:
- अगर URL एक subcategory page है जिसमें no traffic और कोई links नहीं हैं → parent category को redirect करें।
- अगर यह टैग या लेखक आर्काइव है → ब्लॉग इंडेक्स पर रीडायरेक्ट करें
- अगर यह वाकई एक अनाथ पृष्ठ है जिसका कोई तार्किक समकक्ष नहीं है → इसे 404 होने दें, या किसी अच्छे डिज़ाइन किए गए 404 पृष्ठ पर सॉफ्ट-रीडायरेक्ट करें जिसमें नेविगेशन हो
एक अच्छा custom 404 page contextual search और popular category links के साथ इन visits में से अधिक को recover करता है एक blanket homepage redirect की तुलना में। मैंने एक Seahawk client के लिए पिछले साल एक बनाया था, इसमें 28% "recovered" rate था (users 404 से दूसरे page पर navigate कर रहे थे) versus पहले लगभग 9%।
---
लॉन्च के बाद का सत्यापन
रीडायरेक्ट मैप लॉन्च पर खत्म नहीं होता। पहले 72 घंटे महत्वपूर्ण हैं।
मैंने लॉन्च से एक दिन पहले GSC प्रॉपर्टी वेरिफिकेशन सेट अप किया, फिर पहले दो हफ्तों तक रोज़ Coverage रिपोर्ट को मॉनिटर करता हूँ। लॉन्च के बाद नए 404s आना आमतौर पर उन URLs को दर्शाता है जो इन्वेंटरी से छूट गए, rogue पैरामीटर variants, hreflang alternates, या बाहरी ईमेल कैम्पेन में पुराने URLs।
हर नए 404 के लिए जो मुझे मिलता है, मैं एक रीडायरेक्ट जोड़ता हूं और इसे पुश करता हूं। छोटी आग। आप उन्हें तब तक पकड़ना चाहते हैं जब तक कि Googlebot उन URL पर पूरी तरह से हार न मान दे।
साथ ही, अपने सर्वर लॉग्स को चेक करो। सिर्फ GSC नहीं। Googlebot उन URLs को विज़िट करता है जो कहीं लिंक नहीं हैं, अपने खुद के historical crawl data के आधार पर। लॉग analysis (मैं छोटे सर्वर सेटअप पर quick reads के लिए GoAccess use करता हूँ) 404s को surface करता है जो GSC sometimes एक हफ्ता या उससे ज़्यादा टाइम में रिपोर्ट करता है।
---
FAQ
20,000 URLs के लिए redirect map बनाने में वास्तव में कितना समय लगता है?
रिअलिस्टिकली, पार्ट-टाइम एफर्ट के दो से तीन हफ़्ते बजट करें, सायद पूरी तरह 40-60 घंटे — इस पर निर्भर करता है कि पुरानी साइट की URL स्ट्रक्चर कितनी मेस है। ऑटोमेटेड मैचिंग फेज़ तेज़ है। high-priority URLs की मैनुअल रिव्यू और वैलिडेशन फेज़ सबसे ज़्यादा टाइम खाते हैं। कभी किसी क्लायंट या PM को यह न बताने दें कि यह "एक सप्ताहांत में" हो सकता है।
क्या मुझे हर एक URL को रीडायरेक्ट करना चाहिए, या कुछ 404 होने देना ठीक है?
यह ठीक है कि सत्यिक रूप से मृत, कोई ट्रैफिक न होने वाले, कोई backlink न होने वाले URLs को 404 प्राकृतिक रूप से होने दें। एक अप्रासंगिक पृष्ठ पर एक रीडायरेक्ट को मजबूर करना एक soft-404 सिग्नल बनाता है जो संभवतः बदतर है। निर्दयता से छँटाई करें। जो मायने रखता है उसे रीडायरेक्ट करें, और बाकी के लिए एक ठोस कस्टम 404 अनुभव में निवेश करें।
मुझे कौन सा redirect type use करना चाहिए, 301 या 302?
माइग्रेशन में लगभग सभी चीजों के लिए 301 (स्थायी)। एक 302 Google को बताता है कि स्थानांतर अस्थायी है और यह पुराने URL को इंडेक्स में संरक्षित रखेगा। मैंने एजेंसियों को 302 का उपयोग करते हुए देखा है "सुरक्षित रहने के लिए" और फिर पुराने डोमेन को रैंकिंग करते हुए देखा है जबकि नया महीनों तक stagnate होता है। 301 का उपयोग करें।
क्या मैं WordPress पर 20,000 रीडायरेक्ट को प्रबंधित करने के लिए एक प्लगइन का उपयोग कर सकता हूँ?
हाँ, लेकिन सावधानी से चुनें। Redirection by John Godley बड़े वॉल्यूम को अच्छी तरह संभालता है और नियमों को डेटाबेस में store करता है बजाय .htaccess के, जो स्केल पर performance के लिए बेहतर है। ~10,000 से ज़्यादा exact-match redirects के लिए, मैं फिर भी pattern-based नियमों को server config में माइग्रेट करने की सिफारिश करूँगा बजाय पूरी तरह एक प्लगइन पर निर्भर रहने के।
बड़े माइग्रेशन पर टीमें सबसे आम गलती क्या करती हैं?
Redirect map को बहुत देरी से शुरू करना। मैं यह लगातार देखता हूँ, dev work 90% done है, लॉन्च दो हफ्तों दूर है, और कोई पूछता है "तो redirects के बारे में क्या?" उस समय तुम scramble कर रहे हो और inevitably चीजें miss कर रहे हो। Redirect map को नई साइट की URL structure confirm होते ही build किया जाना चाहिए। Parallel workstream, कोई afterthought नहीं।
---
तीन हफ्ते की देरी, एक बोतल स्कॉच, 94% ट्रैफिक रिटेंशन। इसे सही तरीके से करने की गणित काफी सीधी है।
Redirect map migration का glamorous part नहीं है। कोई इसे case study hero banner में नहीं डालता। लेकिन यह एक migration और एक recovery के बीच का अंतर है, और मुझे पता है कि मैं किसके लिए बिल करना पसंद करूँ।