वेबसाइट रीडायरेक्ट ऑडिट

अच्छी रीडायरेक्ट चेन कैसी होती है?

रीडायरेक्ट चेन 3xx रिस्पॉन्स का वह सिलसिला है जिसे क्लाइंट फ़ॉलो करता है — हर Location हेडर अगले URL की ओर इशारा करता है — जब तक कोई पेज जवाब न दे। अच्छी चेन छोटी होती है (आदर्श रूप से एक हॉप), स्थायी बदलाव के लिए स्थायी कोड (301 या 308) इस्तेमाल करती है, पुराने URL का पाथ और query बनाए रखती है, कभी HTTPS से HTTP पर नहीं गिरती और कभी लूप नहीं बनाती। हर फ़ालतू हॉप एक round trip लेता है, और Google के क्रॉलर 10 हॉप के बाद रुक जाते हैं।

वेबसाइट रीडायरेक्ट ऑडिट कैसे इस्तेमाल करें

1. वह URL डालें जिसके रीडायरेक्ट आप ऑडिट करना चाहते हैं — माइग्रेशन के बाद का कोई पुराना पता, कैंपेन लिंक, या आपके डोमेन का http:// रूप।
2. चुनें कि रिक्वेस्ट किस रूप में जाएँ: डिफ़ॉल्ट चेकर, मोबाइल ब्राउज़र या Googlebot।
3. "रीडायरेक्ट ऑडिट करें" दबाएँ। "नतीजे" टेबल पहले समस्याएँ दिखाती है, फिर चेतावनियाँ, नोट और जो पहले से सही है।
4. हर हॉप का स्टेटस, Location हेडर और समय देखने के लिए "हर रिस्पॉन्स" टेबल देखें, सर्वर पर रीडायरेक्ट के नियम ठीक करें और ऑडिट दोबारा चलाएँ।

वेबसाइट रीडायरेक्ट ऑडिट की खूबियाँ

• शुरुआती URL और हर रीडायरेक्ट टारगेट को Mutqan सर्वर से अलग-अलग माँगता है — छह रिस्पॉन्स तक — ताकि हर हॉप का अपना स्टेटस, Location हेडर, समय, Server और Cache-Control दिखे
• हर हॉप को वर्गीकृत करता है: स्थायी (301, 308) या अस्थायी (302, 303, 307) रीडायरेक्ट, असामान्य 3xx, अंतिम पेज या एरर
• रैंकिंग और स्पीड बिगाड़ने वाली दिक़्क़तें पकड़ता है: रीडायरेक्ट लूप, पाँच हॉप के बाद भी चलती चेन, HTTPS से HTTP पर गिरना, अस्थायी रीडायरेक्ट, एरर पर ख़त्म होती चेन, धीमे हॉप और बिना Location हेडर वाले रीडायरेक्ट
• ख़ुद माइग्रेशन को जाँचता है: पाथ और query string बचे या नहीं, पुराना पेज होम पेज पर तो नहीं भेजा गया (soft 404), और कोई हॉप सिर्फ़ आख़िरी स्लैश जोड़ता या अक्षरों का केस बदलता तो नहीं
• http:// से शुरू होने पर HTTPS अपग्रेड की जाँच: वह कहाँ होता है, पहला रीडायरेक्ट उसी होस्ट पर रहता है या नहीं जैसा HSTS preload माँगता है, और अंतिम पेज Strict-Transport-Security भेजता है या नहीं
• अंतिम HTML पेज में meta refresh — यानी client-side रीडायरेक्ट — ढूँढता है और उसकी देरी व मंज़िल बताता है, उसे फ़ॉलो किए बिना
• Mutqan चेकर, मोबाइल ब्राउज़र या Googlebot के User-Agent के रूप में फ़ेच करता है, ताकि क्लाइंट के हिसाब से बदलने वाले रीडायरेक्ट पकड़े जा सकें

इनपुट और आउटपुट

इनपुट

• शुरुआती URL — कोई भी सार्वजनिक http:// या https:// पता; सिर्फ़ होस्ट नाम देने पर http:// जोड़ा जाता है, ताकि HTTPS अपग्रेड भी ऑडिट में आए।
• इस रूप में फ़ेच करें — हर हॉप के लिए इस्तेमाल होने वाली रिक्वेस्ट प्रोफ़ाइल: Mutqan चेकर, मोबाइल ब्राउज़र User-Agent या Googlebot का User-Agent (ख़ुद घोषित)।

आउटपुट

• सारांश — रीडायरेक्ट की संख्या, आख़िरी स्टेटस, कुल समय, जिन होस्ट से चेन गुज़री, चेन HTTPS पर ख़त्म होती है या नहीं, और समस्याओं की गिनती।
• नतीजे — मिली हर समस्या, चेतावनी, नोट और सही प्रैक्टिस, सबसे गंभीर पहले; CSV में डाउनलोड हो सकती है।
• हर रिस्पॉन्स — हर हॉप का URL, स्टेटस, प्रकार, भेजा गया Location हेडर, समय, Server और Cache-Control; CSV में डाउनलोड हो सकता है।
• आख़िरी रिस्पॉन्स — वह URL जहाँ चेन रुकती है, उसका स्टेटस और Content-Type, उसका Strict-Transport-Security हेडर और कोई meta refresh।

वेबसाइट रीडायरेक्ट ऑडिट का उदाहरण

शुरुआती URL: http://shop.example.com/sale?ref=mail · इस रूप में फ़ेच करें: Mutqan चेकर (डिफ़ॉल्ट)

Redirects 2 · Last status 200 (Final page) · Total time 640 ms · Hosts 1 · Ends on HTTPS Yes · Problems 0
1 http://shop.example.com/sale?ref=mail → 301 Permanent redirect → https://shop.example.com/sale?ref=mail (140 ms)
2 https://shop.example.com/sale?ref=mail → 302 Temporary redirect → / (180 ms)
3 https://shop.example.com/ → 200 Final page (320 ms)
Warning: Hop 2 is a temporary redirect (302); if the move is permanent, use 301 or 308.
Warning: The path /sale is not kept: the chain ends on the home page https://shop.example.com/.
Note: The query string of the start URL is dropped along the way.
Good: The plain-HTTP address is upgraded to HTTPS at hop 1.

वेबसाइट रीडायरेक्ट ऑडिट के नतीजे कैसे पढ़ें

"समस्या" वाली पंक्तियाँ विज़िटर या क्रॉलर के लिए चेन तोड़ देती हैं: लूप, ख़त्म न होने वाली चेन, HTTPS से नीचे गिरना, बिना Location का रीडायरेक्ट या 4xx/5xx पर ख़त्म होती चेन। इन्हें सबसे पहले ठीक करें।

"चेतावनी" वाली पंक्तियाँ काम करती हैं पर कुछ क़ीमत लेती हैं: स्थायी बदलाव में अस्थायी रीडायरेक्ट, तीन या ज़्यादा रीडायरेक्ट, धीमा हॉप, होम पेज पर भेजा गया पुराना पेज, सादे HTTP पर ख़त्म होती चेन, या सर्वर का काम करता meta refresh।

"नोट" उन फ़ैसलों को बताते हैं जो जान-बूझकर भी हो सकते हैं — दो रीडायरेक्ट, सापेक्ष Location, होस्ट बदलना, आख़िरी स्लैश वाला हॉप, Strict-Transport-Security का न होना। "अच्छा" पंक्तियाँ पुष्टि करती हैं कि क्या पहले से सही है।

समय Mutqan सर्वर से मापा जाता है और इसमें होस्ट resolve करना शामिल है; एक सेकंड से ज़्यादा लेने वाले हॉप की रिपोर्ट होती है। साइट से दूर बैठा विज़िटर अलग समय देखेगा, पर हर हॉप हर विज़िटर से एक round trip लेता है।

"ऑडिट अधूरा रहा" नोट का मतलब है कि चेकर अगली रिक्वेस्ट नहीं भेज सका — रिक्वेस्ट-सीमा, अस्वीकार किए गए पते, टाइमआउट या नेटवर्क त्रुटि की वजह से। इसे समस्याओं में नहीं गिना जाता, उस हॉप के बाद की चेन अज्ञात रहती है, और सारांश में "आख़िरी स्टेटस" और "HTTPS पर ख़त्म" के लिए "—" दिखता है।

वेबसाइट रीडायरेक्ट ऑडिट कब इस्तेमाल करें

• साइट माइग्रेशन के बाद अपने रीडायरेक्ट मैप के पुराने URL चलाएँ और पक्का करें कि हर एक, पाथ बचाते हुए, एक ही स्थायी रीडायरेक्ट में अपने नए पेज तक पहुँचता है।
• HSTS preload लिस्ट में डोमेन भेजने से पहले उसका http:// रूप जाँचें: पहला रीडायरेक्ट उसी होस्ट पर रहकर सिर्फ़ HTTPS पर जाना चाहिए।
• पता करें कि Search Console पुराना URL क्यों रखे हुए है या रीडायरेक्ट एरर क्यों दिखाता है: अस्थायी कोड, लूप, लंबी चेन और meta refresh देखें।
• मार्केटिंग और QR कोड वाले लिंक ऑडिट करें: पक्का करें कि कैंपेन पैरामीटर रीडायरेक्ट के बाद भी बचे रहें और चेन किसी एरर पेज पर न रुके।

समस्या निवारण

• ऑडिट "ऑडिट अधूरा रहा" नोट पर ख़त्म होता है, जिसमें रिक्वेस्ट-सीमा का संदेश है: हर हॉप Mutqan सर्वर पर एक पेज फ़ेच है, और पेज फ़ेच साइन इन किए बिना एक मिनट में 10 तक सीमित हैं (साइन इन करने पर 30), जो पेज लाने वाले हर टूल के साथ साझा हैं; सभी इंटरनेट टूल मिलकर एक पते से एक मिनट में 120 रिक्वेस्ट की अनुमति भी देते हैं। छह हॉप वाला ऑडिट दस में से छह इस्तेमाल करता है, इसलिए एक मिनट रुककर फिर चलाएँ।
• www और बिना www वाले होस्ट के बीच, या http और https के बीच लूप: दो नियम (अक्सर एक ऐप्लिकेशन में और एक CDN पर) canonical पते पर असहमत हैं। दोनों को एक ही अंतिम रूप की ओर मोड़ें।
• चेन 403 या किसी चैलेंज पेज पर ख़त्म होती है: फ़ायरवॉल या बॉट-सुरक्षा ऑटोमेटेड क्लाइंट को अलग जवाब दे सकती है। मोबाइल प्रोफ़ाइल आज़माएँ; अगर विज़िटर को पेज दिखता है, तो वजह सुरक्षा है, रीडायरेक्ट नहीं।
• कोई हॉप "ऑडिट अधूरा रहा" नोट पर रुकता है क्योंकि उसका टारगेट अस्वीकार हुआ: Mutqan सर्वर प्राइवेट या रिज़र्व्ड पतों, आंतरिक नामों (एक हिस्से वाले होस्ट, .local, .internal, .corp जैसे), इसी साइट के अपने पते, workers.dev होस्ट, और 80, 443, 8080, 8443 तथा 3000–3999, 5000–5999 और 8000–8999 की ज़्यादातर रेंज के बाहर के पोर्ट से कनेक्ट नहीं करता। इनमें से कुछ तक आम विज़िटर पहुँच सकते हैं, इसलिए यह इनकार चेकर की सीमा है, इस बात का सबूत नहीं कि रीडायरेक्ट टूटा है; नोट में ठीक-ठीक वजह लिखी होती है।

वेबसाइट रीडायरेक्ट ऑडिट के बारे में अक्सर पूछे जाने वाले सवाल

तकनीकी नोट्स

हर हॉप POST /api/v1/internet/http/fetch की एक कॉल है जिसमें followRedirects false होता है: Mutqan सर्वर होस्ट को DNS over HTTPS से resolve करता है, निजी और आरक्षित पतों को ठुकराता है, चुना गया तय हेडर सेट भेजता है और सिर्फ़ वही एक रिस्पॉन्स लौटाता है, उसके असली Location हेडर समेत। ब्राउज़र Location को हॉप के URL के सापेक्ष resolve करता है (जैसा RFC 9110 §10.2.2 कहता है), कोई fragment हो तो हटाता है और अगला हॉप माँगता है — कुल मिलाकर छह रिस्पॉन्स तक।

RFC 9110 का §15.4 रीडायरेक्ट कोड परिभाषित करता है: 301 और 308 स्थायी हैं, 302, 303 और 307 अस्थायी, और 307 व 308 रिक्वेस्ट मेथड बदलने नहीं देते। Google अपने canonical चुनाव में 301, 308 और तुरंत होने वाले meta refresh को स्थायी संकेत मानता है और 302, 303, 307 व देर वाले meta refresh को अस्थायी; उसके क्रॉलर ज़्यादा से ज़्यादा 10 हॉप फ़ॉलो करते हैं।

जैसे ही कोई Location चेन में पहले माँगे गए URL की ओर इशारा करे, लूप की रिपोर्ट हो जाती है; जो Location सही URL नहीं है, या http और https के अलावा किसी स्कीम पर ले जाती है, वह नई रिक्वेस्ट के बजाय एक finding के साथ ऑडिट रोक देती है।

सीमाएँ और कार्यप्रणाली

रिक्वेस्ट Cloudflare नेटवर्क पर चलने वाले Mutqan सर्वर से जाती हैं। देश, भाषा, डिवाइस या कुकी के हिसाब से रीडायरेक्ट करने वाली साइटें असली विज़िटर को कहीं और भेज सकती हैं।

JavaScript रीडायरेक्ट नहीं दिखते: सिर्फ़ HTTP रीडायरेक्ट और अंतिम HTML पेज के meta refresh की रिपोर्ट होती है, और meta refresh फ़ॉलो नहीं होता।

एक ऑडिट में ज़्यादा से ज़्यादा छह रिस्पॉन्स माँगे जाते हैं, और meta refresh ढूँढने के लिए आख़िरी पेज के सिर्फ़ पहले 64 KiB पढ़े जाते हैं।

सुरक्षा और गोपनीयता

Mutqan सर्वर को शुरुआती URL और हर रीडायरेक्ट टारगेट मिलता है; वह हर एक को तय हेडर के साथ और आपकी किसी कुकी के बिना एक बार माँगता है और कुछ नहीं रखता। पेज की बॉडी आपके ब्राउज़र में टेक्स्ट की तरह पढ़ी जाती है और कभी रेंडर नहीं होती।

संदर्भ

• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• Redirections in HTTP — MDNMDN Web Docs (Mozilla)HTTP redirects: Location header के साथ 3xx status codes, स्थायी (301, 308) बनाम अस्थायी (302, 303, 307), और redirect loops कैसे बनते हैं।
• Redirects and Google SearchGoogle Search Centralकिसी पेज या साइट का canonical URL चुनते समय Google स्थायी (301, 308) और अस्थायी (302, 303, 307) सर्वर-साइड रीडायरेक्ट को कैसे लेता है।