वेबसाइट माइग्रेशन में 301 रीडायरेक्ट कैसे सेट करें

वेबसाइट माइग्रेशन के लिए 301 रीडायरेक्ट चरण-दर-चरण कैसे सेट करें

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

यह गाइड बताता है कि वेबसाइट माइग्रेशन के लिए 301 रीडायरेक्ट्स चरण-दर-चरण कैसे सेट करें, और ऐसा कैसे करें कि सारा काम सिर्फ रीडायरेक्ट लेयर पर ही न छोड़ना पड़े। आप पुरानी साइट का नक्शा बनाएँगे, तय करेंगे कि किन पेजों को रीडायरेक्ट मिलना चाहिए, और खोज इंजन तथा उपयोगकर्ताओं के सामने गैप आने से पहले नतीजे जाँचेंगे। अगर आप व्यावहारिक शुरुआत चाहते हैं, तो पहले समझें कि "वेबसाइट माइग्रेशन 301 रीडायरेक्ट कैसे सेट करें" और फिर "साइट माइग्रेशन रीडायरेक्ट मैप कैसे बनाएं" को एक ही वर्कफ़्लो का हिस्सा मानें।

1. माइग्रेशन का प्रकार और रीडायरेक्ट के लक्ष्य तय करें

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

उदाहरण के लिए, oldsite.com से newsite.com तक ब्रांड बदलाव में लगभग हर लाइव पेज को रीडायरेक्ट करना पड़ सकता है, जबकि एक CMS से दूसरे टेम्पलेट सिस्टम में बदलाव में URL वही रह सकते हैं और सिर्फ पेजों के रेंडर होने का तरीका बदलता है। ये दोनों एक जैसा काम नहीं हैं। अगर आप इन्हें एक जैसा मानेंगे, तो रीडायरेक्ट प्लान जल्दी गड़बड़ा जाएगा।

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

माइग्रेशन के नियम साधारण भाषा में लिखें। उन्हें छोटा रखें। “पुराने कैटेगरी पेज नए कैटेगरी में जाएँगे।” “बंद किए गए प्रोमो पेजों को रीडायरेक्ट की ज़रूरत नहीं।” “पतले आर्काइव पेज हटाए जा सकते हैं।” ऐसे फैसले आगे चलकर घंटों बचाते हैं, क्योंकि 301 रीडायरेक्ट्स को साइट की असली संरचना का पालन करना चाहिए, लॉन्च हफ़्ते में लगाए गए अंदाज़ों का नहीं।

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

2. सिर्फ उन्हीं URLs की सूची बनाएँ जिन्हें रीडायरेक्ट कवरेज चाहिए

हर ऐतिहासिक URL की सूची न बनाएँ, जब तक कि वाकई उसकी ज़रूरत न हो। कागज़ पर यह व्यवस्थित लगता है, लेकिन इससे समय बर्बाद होता है और शोर बढ़ता है। उन पेजों, फ़ोल्डरों और फ़ाइलों से शुरू करें जिनकी अभी भी वैल्यू है: लैंडिंग पेज, सर्विस पेज, ब्लॉग पोस्ट, कैटेगरी पेज, अगर इमेज सार्वजनिक रूप से लिंक हैं तो वे, और वे PDFs जिन पर अभी भी विज़िट आती हैं।

URLs कई जगहों से निकालें। अपना मौजूदा sitemap, analytics, server logs, और जो पुराने crawl exports आपके पास हैं, उन्हें इस्तेमाल करें। बिना विज़िट और बिना लिंक वाला URL शायद ध्यान देने लायक न हो। लेकिन बाहर से लिंक वाला URL ज़रूरी हो सकता है। वह माइग्रेशन के छह महीने बाद भी काम आ सकता है।

जिन पेजों को जानबूझकर रिटायर करना है, उन्हें बाहर रखें। 2021 का कोई seasonal campaign सिर्फ इसलिए नए घर का हकदार नहीं हो जाता कि वह मौजूद है। न ही कोई पुराना internal test page। यहीं अनुशासन काम आता है। ज़रूरत से ज़्यादा की बजाय कम रीडायरेक्ट्स बेहतर हो सकते हैं, बशर्ते महत्वपूर्ण वाले कवर हों।

इन्वेंटरी को सरल समूहों में बाँटें: पेज, फ़ोल्डर, फ़ाइलें, और विशेष केस। यहाँ संख्या मदद करती है। 12 URLs की सूची एक तरह से संभाली जा सकती है। 1,200 URLs की सूची के लिए पैटर्न नियम चाहिए, हर लाइन के लिए हाथ से बनाए गए नियम नहीं। यह चरण छोड़ देंगे, तो रीडायरेक्ट मैप का ऑडिट मुश्किल हो जाएगा।

इन्वेंटरी को पुराने साइट पर केंद्रित रखें, नए साइट पर नहीं। आज क्या मौजूद है, इसका स्रोत-ऑफ-ट्रुथ पुरानी साइट है। नई साइट लक्ष्य है। दोनों को बहुत जल्दी मिला देने से missing pages और accidental duplicates पकड़ना कठिन हो जाता है।

3. पुराने URLs को सही नए समकक्षों से मिलाएँ

अब मैपिंग बनाएँ। एक साफ one-to-one रीडायरेक्ट मैप सबसे आसान केस है: एक पुराना URL एक नए URL पर जाता है, और संबंध साफ़ होता है। प्राइसिंग पर ब्लॉग पोस्ट नई प्राइसिंग आर्टिकल पर जाती है। ऑडिट्स वाली सर्विस पेज नए ऑडिट पेज पर पहुँचती है। सीधा मामला।

असल माइग्रेशन शायद ही इतने साफ़ होते हैं। कभी एक पुराना पेज दो नए पेज बन जाता है, या तीन पुराने पेज एक मज़बूत नए पेज में समा जाते हैं। ऐसे मामलों में तय करें कि यूज़र शायद किस चीज़ के लिए आया था। अगर पुराने पेज में “setup” और “support” दोनों थे, लेकिन नई साइट उन्हें अलग-अलग पेजों में बाँटती है, तो मुख्य इरादे के हिसाब से सबसे अच्छा विकल्प चुनें और बाकी को बाद में internal links से जोड़ दें।

सब कुछ होमपेज पर रीडायरेक्ट न करें। एक दोपहर के लिए यह आसान लगता है, लेकिन महीनों तक महँगा पड़ता है। सर्च इंजन कम relevancy को पसंद नहीं करते, और यूज़र उससे भी जल्दी समझ जाते हैं। कोई pricing page ढूँढ रहा व्यक्ति generic landing page नहीं चाहता। उसे pricing page चाहिए, या उसका सबसे नज़दीकी कामचलाऊ विकल्प।

हटाए गए कंटेंट के लिए फैसला लें। अगर कोई replacement नहीं है और कोई सार्थक समकक्ष भी नहीं, तो उसे रीडायरेक्ट मैप से बाहर छोड़ दें। खराब मैच थोपने से यह ज़्यादा साफ़ है। 2019 के किसी event वाले पेज को सिर्फ एक spreadsheet row भरने के लिए नकली destination की ज़रूरत नहीं।

मुश्किल URLs के साथ नोट लिखें। merged pages, split pages, और retired content के लिए छोटी-सी वजह दें। जब कोई लॉन्च से दो दिन पहले प्लान देखता है और पूछता है कि page A page B पर क्यों जा रहा है, तो यह नोट काम आता है। जवाब मैप में दिखना चाहिए, चैट में छिपा नहीं।

4. सही 301 रीडायरेक्ट implementation method चुनें

301 रीडायरेक्ट्स कहाँ लगाए जाएँ, यह इस पर निर्भर करता है कि migrated site कैसे host हुई है। कुछ stacks में server config सबसे साफ़ रास्ता होता है। दूसरों में CMS, CDN, या app routing layer बेहतर विकल्प होती है। वही जगह चुनें जो बिना अतिरिक्त जटिलता के भरोसेमंद तरीके से रीडायरेक्ट दे सके।

अगर साइट traditional web server पर चलती है, तो server-level rules सबसे सीधे विकल्प हो सकते हैं। अगर साइट CMS के भीतर built-in redirect tools से चलती है, तो छोटे moves के लिए वही काफी हो सकता है। अगर ट्रैफिक CDN से होकर जाता है, तो edge rules मदद कर सकते हैं, खासकर जब बहुत सारे URLs पर तेज़ अपडेट चाहिए हों।

हर विकल्प की अपनी tradeoff है। Server rules ताकतवर होते हैं, लेकिन सावधानी से संभालने पड़ते हैं। CMS plugins सुविधाजनक होते हैं, लेकिन भरे-भरे और अव्यवस्थित हो सकते हैं। CDN rules तेज़ होते हैं, लेकिन caching और path matching के साथ उनका व्यवहार ठीक से समझना पड़ता है। आदत के बजाय migrated site के हिसाब से चुनें।

अगर आपका माइग्रेशन security settings, hosting, या tracking भी बदल रहा है, तो उस काम को उसी विंडो में समन्वित करें। गलत host name या अधूरी certificate setup पर निर्भर रीडायरेक्ट लेयर अजीब तरीकों से fail कर सकती है। साइट सुरक्षा से जुड़ी योजना के लिए देखें वेबसाइट सुरक्षा।

बड़ी टीमों के लिए, method को एक जगह दर्ज करें। redirect map के साथ owner, platform, और deployment path लिखें। इससे जो व्यक्ति नियम बदल रहा है, उसे पता रहेगा कि वे Nginx, Apache, किसी CMS table, CDN panel, या app code में जाने चाहिए।

5. 301 नियम लिखें और व्यवस्थित करें

अब map को असली 301 redirects में बदलें। नियमों को साफ़ रखें। एक pattern एक ही काम करे। अगर कोई rule बहुत ज़्यादा URL shapes पकड़ने की कोशिश करता है, तो वह गलत पेज उठा सकता है और यूज़र को अजीब जगह भेज सकता है।

loops पर नज़र रखें। loop तब होता है जब page A page B पर redirect होता है और page B वापस page A पर जाता है, या दो पेज एक-दूसरे को चक्कर लगाते रहते हैं। यह crawlers और users, दोनों के लिए dead end है। इससे crawl budget भी बर्बाद होता है, जो उन उबाऊ शब्दों में से एक है जो तब बहुत अहम हो जाते हैं जब कुछ भी ठीक से index नहीं होता।

chains से भी बचें। chain का मतलब है एक redirect, दूसरे redirect पर जाता है, फिर तीसरे पर। Page A B पर, फिर B C पर। यह खराब तरीके से काम करता है और हर चीज़ को धीमा करता है। अगर A को सीधे C पर भेजा जा सकता है, तो वही करें।

फ़ाइल या interface के अंदर consistent naming और grouping इस्तेमाल करें। नियमों को सेक्शन के हिसाब से बाँटें: पुराने blog paths, पुराने service paths, पुराने product paths, retired assets। एक व्यवस्थित सूची टेस्ट करने में आसान होती है। और लॉन्च वाले दिन शाम 6 बजे बिना लंबी व्याख्या के किसी दूसरे developer को देने में भी आसान होती है।

exceptions पर भी नज़र रखें। “/blog/ के सब कुछ को /insights/ पर redirect करें” जैसा बड़ा rule देखने में कुशल लगता है, लेकिन यह tags, author pages, या पुराने media links तोड़ सकता है। अगर pattern में exceptions हैं, तो रिलीज़ से पहले उन्हें अलग कर दें। इससे बाद की सफ़ाई बचती है।

6. लॉन्च से पहले और बाद में रीडायरेक्ट व्यवहार सत्यापित करें

Testing लॉन्च से पहले होना चाहिए, पहले broken page की user report आने के बाद नहीं। मैप से कुछ individual URLs जाँचें, फिर grouped patterns, फिर trailing slashes, uppercase paths, query strings, और extension वाली फ़ाइलों जैसे odd cases टेस्ट करें। जो redirect एक URL पर काम करता है, वह उसके नज़दीकी cousin पर fail कर सकता है।

जाँचें कि response code असली 301 हो, 302 न हो, और न ही कोई ऐसा soft rewrite जो ब्राउज़र में सिर्फ redirect जैसा दिखता हो। यह फर्क मायने रखता है। Search engines permanent move को temporary move से अलग तरह से संभालते हैं, और यूज़र को अंदाज़ा नहीं लगाना चाहिए कि क्या हुआ। ऐसा tool इस्तेमाल करें जो वास्तविक response दिखाए।

सिर्फ obvious paths टेस्ट न करें। पुराने PDFs, image URLs, और nested folder URLs अक्सर छूट जाते हैं। एक missing file path 404s की ऐसी श्रृंखला बना सकता है जो लॉन्च के बाद भी बढ़ती रहती है, खासकर अगर वे assets पेजों में embedded थे या सालों पहले सोशल मीडिया पर साझा किए गए थे।

जाँचें दो चरणों में करें: एक staging environment में लॉन्च से पहले, और एक live site पर लॉन्च के तुरंत बाद। दूसरा राउंड deployment issues, caching surprises, और उन rules को पकड़ता है जो असली host पर अलग व्यवहार करते हैं। यही वह चरण है जहाँ कई टीमें वह एक URL पकड़ती हैं जिसे वे भूल गई थीं।

अगर माइग्रेशन में नई analytics या monitoring भी शामिल है, तो पुष्टि करें कि रीडायरेक्ट्स उन systems को तोड़ नहीं रहे। जब आप traffic, response codes, और crawl behavior को साथ देख सकते हैं, तो move पर भरोसा करना आसान होता है। इस तरह के प्रोजेक्ट में measurement tools की तुलना करने वाली टीमों के लिए वेबसाइट analytics की लागत कितनी होती है एक उपयोगी संदर्भ है।

7. माइग्रेशन के बाद सहायक संकेत अपडेट करें

301 रीडायरेक्ट्स को पूरा माइग्रेशन अकेले नहीं ढोना चाहिए। internal links अपडेट करें ताकि नई साइट खुद को ही point करे। अगर आपकी navigation अभी भी पुराने addresses पर जाती है, तो हर click एक और अनावश्यक hop बनाता है। इससे यूज़र को अतिरिक्त देरी होती है और crawlers पर अतिरिक्त काम पड़ता है।

XML sitemaps को नए URLs से refresh करें। जहाँ ज़रूरी हो, उन्हें submit करें। पुराने URLs को live sitemap से हटाएँ अगर वे अब redirect हो रहे हैं, और वहाँ सिर्फ destination URLs रखें। पुराने addresses से भरा sitemap mixed signals भेजता है, भले ही redirects पूरी तरह काम कर रहे हों।

Canonical tags जाँचें। उन्हें पुराने पेज की बजाय नए पेज की ओर इशारा करना चाहिए। यह कोड की एक छोटी-सी line है, लेकिन महत्व रखती है। अगर canonical tag अभी भी पुराने URL की ओर इशारा करता है, तो यह search engines को दिया गया संदेश धुंधला कर सकता है, खासकर लॉन्च के बाद पहले crawl cycle के दौरान।

जहाँ संभव हो, बाहरी references अपडेट करें। इसमें partner sites, social profiles, email templates, या आपका नियंत्रित directory listing शामिल हो सकता है। आप सब कुछ नहीं पकड़ पाएँगे, और यह ठीक है। लक्ष्य redirect layer से बचने योग्य ट्रैफिक कम करना है, पूरे इंटरनेट को ठीक करना नहीं।

अगर आपका माइग्रेशन बड़े redesign का हिस्सा है, तो redirect काम की तुलना व्यापक content और budget decisions से करना मददगार होता है। वेबसाइट redesign बजट बनाम maintenance बजट नाम का पेज बदलाव के काम और रखरखाव के बीच अंतर समझने में मदद कर सकता है।

8. लॉन्च के बाद के पहले चरण में crawl और traffic issues पर नज़र रखें

लॉन्च के बाद का पहला चरण वही होता है जहाँ समस्याएँ सामने आती हैं। छूटे हुए URLs, unexpected 404s, redirect anomalies, और पुराने paths पर request spikes देखें। अगर साइट बड़ी है, तो शुरुआत में यह काम रोज़ करें। माइग्रेशन ताज़ा हो तो दिन में दो बार जाँच करना भी ज़्यादा प्रतिक्रिया नहीं है।

server logs, analytics, और search console data को साथ देखें। एक source वह चीज़ नहीं पकड़ेगा जो दूसरे देखते हैं। Logs में 404 किसी टूटे हुए internal link का संकेत हो सकता है। Crawl error किसी typo वाले redirected URL का। किसी मुख्य page पर traffic गिरना यह दिखा सकता है कि कोई पुराना path अभी भी कहीं महत्वपूर्ण जगह साझा कर रहा है।

गैप जल्दी ठीक करें। अगर कोई URL छूट गया, तो उसे जोड़ें। अगर कोई pattern बहुत चौड़ा है, तो उसे संकुचित करें। अगर chain बन गई है, तो उसे छोटा करें। लॉन्च पर redirect map खत्म नहीं होता; मूव के शुरुआती दिनों में यह एक live document रहता है।

पहले 7 दिनों में सबसे महत्वपूर्ण पेजों को ट्रैक करें, फिर अगर माइग्रेशन बड़ा है तो 30 दिनों बाद फिर देखें। इससे आपको दो checkpoints मिलते हैं: एक तुरंत होने वाली टूट-फूट के लिए, और एक धीमे crawl तथा indexing प्रभावों के लिए। अगर संख्याएँ गलत दिखें, तो उनके अपने-आप ठीक होने का इंतज़ार न करें।

टीम को ठोस उदाहरणों के साथ अपडेट रखें, धुंधले status notes के साथ नहीं। “चार product URLs अभी भी 404 दे रहे हैं” उपयोगी है। “कुछ समस्याएँ अभी बाकी हैं” नहीं। अगर कोई marketing campaign, press mention, या top-linked page अभी भी पुराने address पर जा रहा है, तो पहले उसी path को ठीक करें। एक छूटा हुआ URL दर्जनों कम-मूल्य वाले पेजों से बड़ा असर डाल सकता है।

पहली लहर स्थिर हो जाने के बाद, redirect layer की फिर से असली traffic के आधार पर समीक्षा करें। कुछ पुराने URLs इन्वेंटरी के अनुमान से ज़्यादा महत्वपूर्ण साबित होंगे। कुछ दूसरे कभी हिट नहीं होंगे। यह सबूत redirect plan को और सटीक बनाने और माइग्रेशन के स्थिर होने पर साइट को साफ़ रखने में मदद करता है।