पढ़ने में 12 मिनट
URL रीडायरेक्ट कैसे चेक करें (और रीडायरेक्ट चेन कैसे पढ़ें)
TrueURL, curl और DevTools से URL रीडायरेक्ट चेक करने का तरीका: रीडायरेक्ट चेन का हर हॉप पढ़ें और लूप, लंबी चेन व मिले-जुले 301/302 ठीक करें।
लेख पढ़ेंमुफ़्त रीडायरेक्ट टूल
एक URL को दो बार जांचें, एक बार डेस्कटॉप Chrome बनकर और एक बार iPhone का Safari बनकर, और दोनों रीडायरेक्ट चेन की आमने-सामने तुलना करें। डिवाइस के हिसाब से होने वाले ऐसे रीडायरेक्ट पकड़ें जो मोबाइल विज़िटर को किसी अनचाही जगह भेज देते हैं।
Cloudflare का एज नेटवर्क सर्टिफ़िकेट हमेशा वैलिडेट करता है, इसलिए इस विकल्प से यह जांच छोड़ी नहीं जा सकती। सर्टिफ़िकेट की समस्याएं नतीजे में दिखाई जाती हैं।
पहली रिक्वेस्ट के साथ भेजी जाती है, ज़्यादा से ज़्यादा 16 KB। JSON बॉडी application/json के रूप में और बाकी बॉडी फ़ॉर्म के रूप में भेजी जाती है, जब तक आप Content-Type हेडर सेट न करें।
1 से 50 तक। ब्राउज़र 20 के बाद रुक जाते हैं।
साइटें फ़ोन, क्रॉलर और लिंक प्रीव्यू बॉट को अलग-अलग जगह रीडायरेक्ट कर सकती हैं।
चेन की हर रिक्वेस्ट के साथ भेजे जाते हैं।
कोई कस्टम हेडर नहीं।
यह हेडर भेजने के लिए वैल्यू डालें। हेडर की वैल्यू कभी सेव नहीं होती।
HTML पेजों में मिलने वाले <meta http-equiv="refresh"> टैग और Refresh हेडर फ़ॉलो करें।
पेज की स्क्रिप्ट में location.href = "…" जैसे सीधे, बिना शर्त वाले रीडायरेक्ट फ़ॉलो करें।
सेटिंग्स इसी ब्राउज़र में याद रखी जाती हैं। कुकीज़, हेडर की वैल्यू और POST बॉडी कभी सेव नहीं होतीं।
कुछ साइटें विज़िटर के डिवाइस के आधार पर तय करती हैं कि उसे कहां भेजना है, और डिवाइस का पता User-Agent हेडर से लगाती हैं। आम उदाहरण हैं अलग मोबाइल साइट (m.example.com), ऐप डाउनलोड पेज, स्टोर या रीजन चुनने वाले पेज और विज्ञापनों के लैंडिंग पेज। जब यह लॉजिक गलत होता है, तो मोबाइल विज़िटर होम पेज पर, किसी एरर पेज पर या ऐसे पेज पर पहुंच जाते हैं जिसका उस लिंक से कोई लेना-देना नहीं जिस पर उन्होंने क्लिक किया था।
Google मुख्य रूप से पेजों का मोबाइल वर्शन क्रॉल और इंडेक्स करता है, इसलिए खराब मोबाइल रीडायरेक्ट से यूज़र एक्सपीरियंस के साथ-साथ सर्च में दिखने पर भी बुरा असर पड़ता है।
TrueURL एक ही सेटिंग्स के साथ URL को दो बार जांचता है और सिर्फ़ यूज़र एजेंट (User-Agent) बदलता है: एक बार Windows पर हाल का डेस्कटॉप Chrome और एक बार iPhone पर Safari। दोनों रीडायरेक्ट चेन अपने अंतिम URL और स्टेटस कोड के साथ आमने-सामने दिखाई जाती हैं, ताकि कोई भी फ़र्क एक नज़र में दिख जाए।
सिर्फ़ User-Agent बदलता है। जो साइटें JavaScript में स्क्रीन साइज़ देखकर वर्शन चुनती हैं, वे दोनों कॉलम में एक जैसा बर्ताव कर सकती हैं, भले ही असली फ़ोन पर वे अलग दिखें। Android पर Chrome या Googlebot जैसे दूसरे एजेंट टेस्ट करने के लिए रीडायरेक्ट चेन चेकर की एडवांस सेटिंग्स में कोई प्रीसेट चुनें।
www.example.com/page पर ही रहता है और मोबाइल उसके बराबर वाले m.example.com/page पर जाता है, मोबाइल होम पेज पर नहीं। डेस्कटॉप पेज को <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page"> से अपने मोबाइल URL की ओर इशारा करना चाहिए, और मोबाइल पेज पर वापस डेस्कटॉप पेज की ओर इशारा करने वाला कैननिकल टैग होना चाहिए।Vary: User-Agent होना चाहिए, ताकि कैश दोनों वर्शन को आपस में न मिलाएं।m. लिंक खोलने वाले डेस्कटॉप यूज़र को वापस डेस्कटॉप पेज पर नहीं भेजा जाता।पढ़ने में 12 मिनट
TrueURL, curl और DevTools से URL रीडायरेक्ट चेक करने का तरीका: रीडायरेक्ट चेन का हर हॉप पढ़ें और लूप, लंबी चेन व मिले-जुले 301/302 ठीक करें।
लेख पढ़ेंWindows पर डेस्कटॉप Chrome और iPhone पर Safari, दोनों हाल के वर्शन नंबर के साथ। डिवाइस पहचानने वाला लगभग हर कोड पहले को डेस्कटॉप कंप्यूटर और दूसरे को फ़ोन के रूप में पहचानता है।
ज़्यादातर मोबाइल वाला। Google वेब को मुख्य रूप से Googlebot Smartphone से क्रॉल और इंडेक्स करता है, जिसका User-Agent किसी Android फ़ोन पर चल रहे Chrome जैसा दिखता है। अगर मोबाइल कॉलम गलत पेज पर खत्म होता है, तो Google भी उसी को इंडेक्स कर सकता है। कोई साइट Googlebot के User-Agent को क्या भेजती है, यह देखने के लिए रीडायरेक्ट चेन चेकर की एडवांस सेटिंग्स में Googlebot स्मार्टफ़ोन प्रीसेट इस्तेमाल करें। जो साइटें Googlebot को उसके IP एड्रेस से वेरिफ़ाई करती हैं, वे TrueURL को फिर भी अलग जवाब दे सकती हैं।
Google इन्हें सपोर्ट करता है, लेकिन इन्हें सही रखना ज़्यादा मुश्किल है: हर पेज के लिए मेल खाने वाला मोबाइल URL, सही एनोटेशन और दोनों दिशाओं में रीडायरेक्ट चाहिए। Google रिस्पॉन्सिव डिज़ाइन की सलाह देता है, जिसमें डिवाइस वाले रीडायरेक्ट की ज़रूरत ही नहीं पड़ती। अगर आप m-dot साइट चलाते हैं, तो हर रिलीज़ के बाद अपने मुख्य पेज यहां जांचें।
आपकी साइट शायद सर्वर-साइड रीडायरेक्ट के बजाय ब्राउज़र में ही, रिस्पॉन्सिव CSS या JavaScript से, खुद को ढालती है। यही सुझाया गया तरीका है, और इसका मतलब है कि तुलना करने के लिए कोई डिवाइस-आधारित रीडायरेक्ट है ही नहीं।
यह टूल डेस्कटॉप Chrome की तुलना iPhone के Safari से करता है। दूसरे डिवाइस के लिए रीडायरेक्ट चेन चेकर में एडवांस सेटिंग्स खोलें, Android पर Chrome जैसा कोई प्रीसेट चुनें या कोई भी User-Agent स्ट्रिंग पेस्ट करें, और जांच चलाएं।
हां। पेज लोड होना शुरू होने से पहले हर रीडायरेक्ट में एक पूरा राउंड ट्रिप लगता है, और मोबाइल नेटवर्क की लेटेंसी ब्रॉडबैंड से ज़्यादा होती है। सिर्फ़ www से m. पर एक रीडायरेक्ट ही साफ़ महसूस होने वाली देरी जोड़ सकता है; इसे आप रीडायरेक्ट लेटेंसी चेकर से माप सकते हैं।