रीडायरेक्ट जाँच

रीडायरेक्ट जाँच से एक सार्वजनिक URL के HTTP रीडायरेक्ट का क्रम पता करें और अंत में मिली प्रतिक्रिया देखें। रिपोर्ट में देखे गए पते, स्थिति कोड और रीडायरेक्ट के गंतव्य मिलते हैं। इन तथ्यों की तुलना उस पते से करें जहाँ लिंक को जाना चाहिए: पूरी हुई शृंखला भी गलत पेज पर पहुँच सकती है, जबकि अधूरी जाँच अंतिम गंतव्य की पुष्टि नहीं करती।

वह URL दें जिसकी जाँच करनी है

उस पते से शुरू करें जिसे लोग वास्तव में इस्तेमाल करते हैं। उसका पाथ और ज़रूरी क्वेरी पैरामीटर भी रखें। सिर्फ़ होमपेज की जाँच से पुराने उत्पाद लिंक का व्यवहार पता नहीं चलता। उदाहरण के लिए, http://example.com/products/old-mug/ एक शुरुआती पते का नमूना है; इसकी जगह वह सार्वजनिक URL दें जिसे आप जाँचना चाहते हैं।

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

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

रीडायरेक्ट शृंखला और अंतिम प्रतिक्रिया पढ़ें

प्रतिक्रियाओं की पंक्तियाँ क्रम से पढ़ें। हर पंक्ति में अनुरोध किया गया URL, HTTP स्थिति और समर्थित रीडायरेक्ट में दिया गया Location गंतव्य होता है। Location के मान पूर्ण पतों के रूप में दिखाए जाते हैं। अगर कोई प्रतिक्रिया /products/new-mug/ की ओर भेजती है, तो रिपोर्ट उस प्रतिक्रिया के URL के आधार पर पूरा पता निकालती है। इसलिए दिखाई देने वाला पता मूल हेडर के शब्दशः पाठ से अलग हो सकता है।

इस उदाहरण की शृंखला में तीन प्रतिक्रियाएँ और दो रीडायरेक्ट हैं। यह समझाने के लिए दिया गया नमूना है, किसी वास्तविक वेबसाइट की जाँच नहीं:

http://example.com/products/old-mug/       301 → https://example.com/products/old-mug/
https://example.com/products/old-mug/      301 → https://example.com/products/new-mug/
https://example.com/products/new-mug/      200

यहाँ पहली स्थिति 301, अंतिम स्थिति 200 और अंतिम URL उत्पाद का नया पता है। अंतिम 200 वाली पंक्ति प्रतिक्रिया है, अतिरिक्त रीडायरेक्ट नहीं। पूरी हुई जाँच में रीडायरेक्ट की गिनती देखी गई प्रतिक्रियाओं के बीच हुए बदलाव दर्शाती है। अगर जाँच पहले रुक जाए, तो उस संख्या को सहेजी गई पंक्तियों के साथ पढ़ें; उसे पूरी शृंखला की लंबाई न मानें।

परिणाम के रंग को इन विवरणों के साथ देखें:

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

रंग प्रतिक्रियाओं की श्रेणियाँ बताते हैं। वे पेज की सामग्री को अंक नहीं देते, इंडेक्सिंग साबित नहीं करते और यह नहीं तय करते कि रीडायरेक्ट आपके उद्देश्य के अनुरूप है या नहीं।

301, 302, 303, 307 और 308 समझें

पहले अपेक्षित व्यवहार तय करें, फिर स्थिति कोड चुनें। यह जाँचकर्ता इन पाँच रीडायरेक्ट कोड का अनुसरण करता है:

ये अंतर RFC 9110 में HTTP रीडायरेक्ट के अर्थ पर आधारित हैं। सिर्फ़ GET वाली जाँच यह नहीं बता सकती कि भेजे गए POST अनुरोध या उसकी बॉडी का क्या होगा। यहाँ 307 या 308 दिखना फ़ॉर्म भेजने की प्रक्रिया का परीक्षण नहीं है।

रीडायरेक्ट पर Google का मार्गदर्शन स्थायी URL बदलावों के लिए सर्वर से स्थायी रीडायरेक्ट की सलाह देता है। Google इन्हें गंतव्य को कैनोनिकल URL चुनने के पक्ष में संकेत मानता है; अस्थायी रीडायरेक्ट का उद्देश्य अलग है। इसका अर्थ यह नहीं कि हर 302 SEO त्रुटि है या 301 से खोज परिणाम तुरंत बदल जाएँगे।

अगर स्थायी स्थानांतरण अनपेक्षित रूप से अस्थायी कोड लौटाता है, तो उसे बनाने वाला नियम देखें। जानबूझकर बनाए गए अस्थायी रास्ते का कोड केवल बेहतर दिखने वाला परिणाम पाने के लिए न बदलें।

देखें कि गंतव्य सही पेज है या नहीं

पूरी हुई शृंखला बताती है कि यह अनुरोध कहाँ समाप्त हुआ। इससे यह स्थापित नहीं होता कि पेज उपयुक्त विकल्प है। जाँचकर्ता प्रतिक्रिया की स्थिति और रीडायरेक्ट के गंतव्य पढ़ता है; अंतिम पेज की सामग्री नहीं जाँचता।

अंतिम URL की तुलना उस गंतव्य से करें जिसे जाँच से पहले तय किया था। होस्टनाम, पाथ और ज़रूरी क्वेरी पैरामीटर देखें। पुराना उत्पाद लिंक 200 के साथ होमपेज पर पहुँचे, तो भी आगंतुक का काम अधूरा रह सकता है। गंतव्य खोलकर तय करें कि वहाँ अपेक्षित उत्पाद, लेख या कोई उपयुक्त विकल्प है या नहीं। अगर उपयुक्त विकल्प नहीं है, तो केवल रिपोर्ट से त्रुटि हटाने के लिए कोई गंतव्य न गढ़ें।

HTTPS से HTTP पर जाने की चेतावनी भी देखें। तय करें कि रीडायरेक्ट नियम अपेक्षित सुरक्षित पते की ओर जाता है या नहीं और अनचाहा बदलाव सुधारें। यह चेतावनी उस बदलाव को दर्शाती है; यह गंतव्य का सुरक्षा ऑडिट नहीं है।

जिस पेज को खोज में दिखना चाहिए, उसके घोषित पसंदीदा URL को अलग से देखने के लिए कैनोनिकल टैग जाँच इस्तेमाल करें। सफल रीडायरेक्ट कैनोनिकल घोषणा, noindex की अनुपस्थिति या Google के इंडेक्सिंग निर्णय की पुष्टि नहीं करता। सही HTTP शृंखला और पेज पर सही घोषणा अलग-अलग अवलोकन हैं।

अधूरी शृंखला का कारण पता करें

अंतिम URL या स्थिति उपलब्ध न हो, तो वास्तव में दर्ज अंतिम प्रतिक्रिया से शुरुआत करें। Location बताता है कि वह प्रतिक्रिया अनुरोध को कहाँ भेजना चाहती थी। इससे अगला पता पहुँचने या उससे सफल प्रतिक्रिया मिलने की पुष्टि नहीं होती। अनुपलब्ध परिणाम और देखी गई HTTP त्रुटि भी अलग हैं: समय समाप्त होने पर कोई पुष्ट अंतिम कोड नहीं होता, जबकि मिली प्रतिक्रिया स्पष्ट रूप से 404 या 403 लौटा सकती है।

सहेजी गई पंक्तियों से जाँच का दायरा सीमित करें:

• दोहराए गए पते: उदाहरण की A → B → A शृंखला एक लूप है। अनुरोध को पहले देखे गए URL पर लौटाने वाले नियम जाँचें, जैसे होस्टनाम या पाथ के विरोधी नियम।
• बिना दोहराव का लंबा क्रम: जाँचकर्ता अधिकतम पाँच रीडायरेक्ट का अनुसरण करता है। इस सीमा तक पहुँचने से लूप साबित नहीं होता और बाकी शृंखला भी नहीं दिखती। अंतिम दर्ज गंतव्य अलग से जाँचें।
• उपयोगी गंतव्य के बिना रीडायरेक्ट स्थिति: देखें कि संबंधित प्रतिक्रिया वैध Location देती है या नहीं। अनुपस्थित या अमान्य गंतव्य को पूरा स्थानांतरण नहीं माना जा सकता।
• अगली प्रतिक्रिया नहीं: सार्वजनिक पहुँच, डोमेन नाम से पता निकालने, कनेक्शन या सुरक्षित कनेक्शन की समस्याएँ जाँच रोक सकती हैं। पूरी URL शृंखला को आठ सेकंड मिलते हैं, हर चरण को आठ सेकंड नहीं। प्रतिक्रिया हेडर की सीमाएँ और निजी या असमर्थित गंतव्य भी इसे रोक सकते हैं।

अगर गंतव्य पहुँच या अनुरोधों की संख्या पर प्रतिबंध लौटाता है, तो सामग्री मिट गई मानने से पहले उस स्थिति का कारण देखें। इस अनुरोध को आपके लॉग इन किए हुए ब्राउज़र से अलग प्रतिक्रिया मिल सकती है। JavaScript रीडायरेक्ट, meta refresh और ब्राउज़र व्यवहार जाँच के बाहर हैं; इसलिए HTTP परिणाम स्क्रीन पर दिखने वाली हर नेविगेशन नहीं समझा सकता।

कारण सुधारकर वही URL दोबारा जाँचें

नियम बदलने से पहले JSON रिपोर्ट डाउनलोड करें। भेजा गया URL और अपेक्षित गंतव्य भी उसके साथ रखें, ताकि सुधार करने वाला व्यक्ति वास्तविक और अपेक्षित व्यवहार अलग कर सके। यह टूल JSON रिपोर्ट निर्यात करता है; फ़िल्टर किया हुआ CSV नहीं देता और आपके लिए रीडायरेक्ट नहीं बदलता।

1. वह प्रतिक्रिया खोजें जहाँ पता या स्थिति पहली बार आपके उद्देश्य से अलग हुई। असंबंधित पेज मेटाडेटा बदलने के बजाय उस प्रतिक्रिया को बनाने वाली सेटिंग ढूँढें।
2. अनचाहा गंतव्य, स्थिति, लूप या HTTP पर जाने का बदलाव सुधारें। जहाँ नियम आपके नियंत्रण में हों, वहाँ अनावश्यक बीच के चरण हटाएँ, लेकिन उद्देश्यपूर्ण रूटिंग या ट्रैकिंग बनाए रखें। जब आगंतुक के काम के अनुकूल हो, आंतरिक लिंक सीधे अपेक्षित गंतव्य की ओर करें।
3. सुधरी हुई सार्वजनिक प्रतिक्रिया उपलब्ध होने पर बिल्कुल वही शुरुआती URL दोबारा चलाएँ। सहेजी रिपोर्ट से क्रम, पहला और अंतिम कोड, अंतिम पता और अब भी अनुपलब्ध प्रमाण की तुलना करें।
4. पुराने पाथ या अलग होस्टनाम जैसे प्रासंगिक शुरुआती विकल्प अलग से जाँचें। एक पता सुधारने से माइग्रेशन की हर URL मैपिंग सही होने की पुष्टि नहीं होती।

सूची जाँचने के लिए एक साथ HTTP स्थिति जाँच इस्तेमाल करें। यह अधिकतम 50 URL स्वीकार करता है और फ़िल्टर किए हुए CSV निर्यात का समर्थन करता है। एक शृंखला को ध्यान से पढ़ने के लिए इस एक-URL जाँचकर्ता का इस्तेमाल करें। सफल पुनःजाँच अभी देखी गई प्रतिक्रिया की पुष्टि करती है; यह साबित नहीं करती कि भविष्य का आगंतुक, ब्राउज़र या खोज क्रॉलर भी समान व्यवहार पाएगा।