यूआरएल रीडायरेक्ट चेकर

यूआरएल रीडायरेक्ट चेकर एक मुफ़्त टूल है, जो किसी खास URL के लिए 301 और 302 रीडायरेक्ट पहचानता है और रीडायरेक्ट चेन को अधिकतम 10 चरणों तक फ़ॉलो करता है।

URL रीडायरेक्ट क्या होता है?

URL रीडायरेक्ट एक HTTP रिस्पॉन्स है, जो ब्राउज़र, सर्च इंजन क्रॉलर या किसी अन्य क्लाइंट को किसी दूसरे पते के लिए अनुरोध भेजने को कहता है। आम तौर पर इस रिस्पॉन्स में 3xx स्टेटस कोड और एक Location फ़ील्ड होता है। इस फ़ील्ड की वैल्यू URI रेफ़रेंस होती है, जो रिलेटिव भी हो सकती है।

301 स्टेटस कोड का अर्थ है कि रिसोर्स स्थायी रूप से दूसरी जगह चला गया है। इसका इस्तेमाल अक्सर किसी पेज का पता बदलने, HTTP से HTTPS पर जाने या डुप्लिकेट URL को एक करने के बाद किया जाता है। 302 स्टेटस कोड बताता है कि रिसोर्स किसी दूसरी जगह मिला है, लेकिन आम तौर पर इस बदलाव को अस्थायी माना जाता है।

HTTP में 303, 307 और 308 सहित दूसरे रीडायरेक्ट कोड भी तय किए गए हैं। इनके बीच का अंतर इस बात को प्रभावित कर सकता है कि क्लाइंट अनुरोध दोबारा कैसे भेजते हैं, खास तौर पर POST जैसी विधियों के मामले में। सामान्य वेब पेज रीडायरेक्ट में 301 और 302 अब भी आम हैं और यह चेकर इन्हीं को पहचानने के लिए बनाया गया है।

किसी URL का रीडायरेक्ट कैसे जांचें?

स्टेटस कोड फ़ील्ड में 301 या 302 जैसा HTTP स्टेटस कोड दर्ज किया जाता है। चेकर सर्वर पर काम करता है और अधिकतम 10 रीडायरेक्ट चरणों की जांच करता है।

इनपुट HTTPS के ज़रिए सर्वर तक जाता है और उसे स्टोर नहीं किया जाता।

यह चेकर कौन-से रीडायरेक्ट पहचानता है?

यह चेकर 301 और 302 रीडायरेक्ट पहचानता है। 301 स्थायी रीडायरेक्ट और 302 अस्थायी रीडायरेक्ट को दर्शाता है।

दो पतों के बीच बार-बार बदलने वाला क्रम रीडायरेक्ट लूप कहलाता है। HTTP, HTTPS, www, बिना www और आखिर में स्लैश वाले या बिना स्लैश वाले URL के बीच बदलावों का लंबा क्रम रीडायरेक्ट चेन कहलाता है। यह टूल अधिकतम 10 चरणों के बाद रुक जाता है, इसलिए इससे किसी लंबी चेन का अंतिम गंतव्य तय नहीं किया जा सकता।

रीडायरेक्ट की आम समस्याएं कैसे सुलझाएं

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

• माइग्रेट किया गया पेज अब भी पुराने पते पर खुल रहा है। पुराने URL की सीधे जांच करें। 301 को किसी सामान्य होम पेज या दूसरे पुराने पते के बजाय सही नए पेज की ओर ले जाना चाहिए।
• HTTP और HTTPS बार-बार एक-दूसरे पर जा रहे हैं। दोनों वर्ज़न जांचें। वेब सर्वर, कॉन्टेंट डिलीवरी नेटवर्क या ऐप्लिकेशन में मौजूद परस्पर विरोधी नियम HTTPS को वापस HTTP पर भेज सकते हैं, जबकि कोई दूसरी लेयर उसे तुरंत फिर से HTTPS पर लौटा सकती है।
• ईमेल का लिंक अपेक्षित लैंडिंग पेज तक नहीं पहुंच रहा है। संदेश से कॉपी किए गए पूरे URL की जांच करें, जिसमें उसकी क्वेरी स्ट्रिंग भी शामिल हो। ट्रैकिंग सेवाएं अक्सर अंतिम पेज से पहले एक या अधिक रीडायरेक्ट जोड़ती हैं। बीच का कोई गंतव्य काम न करे, तो चेन वहीं रुक सकती है।

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

विराम चिह्न और स्पेस भी मायने रखते हैं। URL में सीधे स्पेस मान्य नहीं होते और आम तौर पर उन्हें %20 जैसे प्रतिशत-एन्कोडिंग में बदलना पड़ता है। # से शुरू होने वाले फ़्रैगमेंट को ब्राउज़र संभालता है और वह HTTP अनुरोध में नहीं भेजा जाता। इसलिए केवल फ़्रैगमेंट बदलने से सर्वर-साइड का कोई अलग रीडायरेक्ट नहीं चुना जाता। अंतरराष्ट्रीयकृत डोमेन नाम अपने ASCII Punycode रूप में दिखाए जा सकते हैं। वहीं, पाथ में मौजूद गैर-ASCII वर्णों को आम तौर पर UTF-8 का इस्तेमाल करके बाइट्स में एन्कोड किया जाता है और ट्रांसमिशन के दौरान संबंधित बाइट्स को प्रतिशत-एन्कोड किया जाता है।

सही रीडायरेक्ट भी गलत क्यों दिख सकता है?

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

सर्वर-साइड चेकर आपके ब्राउज़र की स्थानीय रीडायरेक्ट हिस्ट्री इस्तेमाल नहीं करता। हालांकि, लक्षित वेबसाइट या उसका CDN फिर भी कैश किया हुआ रिस्पॉन्स लौटा सकता है।

DNS में बदलाव से अलग तरह की देरी होती है। रिकर्सिव रिज़ॉल्वर पिछले IP पते को रिकॉर्ड की टाइम टू लिव अवधि खत्म होने तक रख सकते हैं। इस दौरान अलग-अलग नेटवर्क अलग सर्वरों तक पहुंच सकते हैं और उन्हें अलग रीडायरेक्ट नियम मिल सकते हैं। "DNS propagation" का अर्थ दुनिया भर में एक साथ होने वाला कोई अपडेट नहीं, बल्कि कैश की अवधि का असमान रूप से खत्म होना है।

अगर डोमेन हाल ही में माइग्रेट हुआ है, तो DNS रिकॉर्ड, CDN कॉन्फ़िगरेशन और ओरिजिन सर्वर के नियमों की तुलना करें। गूगल कैश चेकर पुराने इंडेक्स किए गए या कैश किए गए पेज का संदर्भ दे सकता है। वहीं, वेबसाइट होस्टिंग चेकर यह पहचानने में मदद कर सकता है कि डोमेन फिलहाल कहां होस्ट होता दिख रहा है। इनमें से कोई भी HTTP रीडायरेक्ट जांच की जगह नहीं लेता।

अक्सर पूछे जाने वाले सवाल

क्या 301 रीडायरेक्ट को बाद में बदला जा सकता है?

हां, सर्वर कॉन्फ़िगरेशन बदला जा सकता है, लेकिन क्लाइंट कुछ समय तक कैश किया हुआ 301 रिस्पॉन्स इस्तेमाल करते रह सकते हैं। नए ब्राउज़र प्रोफ़ाइल में जांच करें और जिन CDN कैश पर आपका नियंत्रण है, उनसे संबंधित कैश साफ़ करें। अगर गंतव्य के बदलने की संभावना अब भी है, तो शुरुआती परीक्षण के दौरान 301 का इस्तेमाल न करें।

क्या रीडायरेक्ट URL की क्वेरी स्ट्रिंग भी नए पते पर भेजता है?

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

मेरे इनपुट का क्या किया जाता है?

सारी प्रक्रिया सर्वर पर होती है। इनपुट HTTPS के ज़रिए सर्वर तक जाता है और उसे स्टोर नहीं किया जाता।

क्या यह JavaScript या meta refresh रीडायरेक्ट भी जांचता है?

यह चेकर 301 और 302 HTTP रीडायरेक्ट पहचानता है और अधिकतम 10 रीडायरेक्ट की जांच करता है।

क्या कमांड लाइन से रीडायरेक्ट जांचे जा सकते हैं?

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