HTTP हेडर चेकर किसी URL के लिए वेब सर्वर से मिले मेटाडेटा दिखाता है। Screpy एक सार्वजनिक GET अनुरोध करता है, समर्थित रीडायरेक्ट का अनुसरण करता है और पेज की बॉडी डाउनलोड किए बिना अंतिम रिस्पॉन्स के हेडर नाम व मान दिखाता है। रीडायरेक्ट की समस्या, प्रकाशन के बाद हेडर में बदलाव या अनपेक्षित इंडेक्सिंग निर्देश देखने के लिए रिपोर्ट इस्तेमाल करें।
पहले मिले रिस्पॉन्स को पढ़ें, फिर उस संसाधन के अपेक्षित व्यवहार से तुलना करें। सफलतापूर्वक पूरा हुआ चेक भी सर्वर की त्रुटि या अनुपयुक्त नीति दिखा सकता है। हरा परिणाम सुरक्षा, कैश प्रदर्शन या खोज इंजन में इंडेक्सिंग का प्रमाणपत्र नहीं है।
सटीक URL और रिस्पॉन्स के चरण जांचें
संबंधित पाथ और क्वेरी सहित पूरा सार्वजनिक HTTP या HTTPS पता लिखें। एक ही डोमेन का होमपेज, PDF और उत्पाद पेज अलग हेडर दे सकते हैं। काल्पनिक उत्पाद पेज के लिए, अगर उसी का रिस्पॉन्स देखना हो तो साइट के मूल पते से https://example.com/products/blue-mug/ ज्यादा उपयोगी है।
हेडर की तालिका से पहले रिस्पॉन्स के चरण पढ़ें। रीडायरेक्ट प्रोटोकॉल, होस्ट या पाथ बदल सकता है। तालिका में हर चरण के सारे हेडर नहीं, अंतिम रिस्पॉन्स के हेडर होते हैं। चरणों में अंतिम रिस्पॉन्स भी गिना जाता है, इसलिए उनकी संख्या रीडायरेक्ट की संख्या के बराबर होना जरूरी नहीं है।
पुष्टि करें कि अंतिम URL उसी संसाधन का है जिसे देखना चाहते थे। लॉगिन पेज, त्रुटि पेज या अलग होस्ट अनपेक्षित मान समझा सकते हैं। अंतिम हेडर सूची के बजाय रीडायरेक्ट का रास्ता विस्तार से देखना हो तो Redirect Checker इस्तेमाल करें।
HTTP रिस्पॉन्स हेडर का उदाहरण पढ़ें
यह काल्पनिक रिस्पॉन्स दिखाता है कि अलग फ़ील्ड अलग सवालों का उत्तर देते हैं। यह लिया हुआ वास्तविक स्कैन या हर पेज पर कॉपी करने की कॉन्फ़िगरेशन नहीं है।
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
200 सफल रिस्पॉन्स बताता है। Content-Type UTF-8 एन्कोडिंग वाला HTML घोषित करता है। Cache-Control कैश निर्देश और X-Robots-Tag इंडेक्सिंग निर्देश देता है। इसलिए काम कर रहे रिस्पॉन्स में भी noindex हो सकता है। HTTP सफलता का अर्थ नहीं कि पेज खोज परिणामों में दिखने के लिए बनाया गया है।
तालिका हेडर के नाम छोटे अक्षरों में सामान्यीकृत करके दिखाती है। बड़े अक्षर लिखने से वह अलग फ़ील्ड नहीं बन जाता। MDN का हेडर संदर्भ अनुरोध और रिस्पॉन्स फ़ील्ड अलग करता है। यह चेकर रिस्पॉन्स दिखाता है, आपके ब्राउज़र सत्र की कुकी, प्राथमिकताएं या प्रमाणीकरण जानकारी की सूची नहीं।
कैश और इंडेक्सिंग को अलग फैसले मानें
खास समस्या देखते समय हेडर के नाम से तालिका फ़िल्टर करें। पहले संसाधन की जरूरत तय करें। बार-बार बदलने वाले HTML, संस्करण वाली फ़ाइल और जानबूझकर खोज से हटाए दस्तावेज़ की नीति एक जैसी होना जरूरी नहीं है।
| हेडर | समीक्षा का उपयोगी सवाल |
|---|---|
content-type |
घोषित फ़ॉर्मैट अपेक्षित संसाधन से मिलता है या रीडायरेक्ट किसी और रिस्पॉन्स तक पहुंचा? |
cache-control |
कैश नीति संसाधन की अपडेट और निजता संबंधी जरूरतों के अनुकूल है? |
etag या last-modified |
शर्त वाले अनुरोधों के लिए वैलिडेटर है? मौजूद होना पुनः सत्यापन का परीक्षण नहीं है। |
vary |
कैश चुनने के लिए रिस्पॉन्स अनुरोध के किन हेडर के अंतर बताता है? |
x-robots-tag |
इस URL पर मिला noindex जानबूझकर है? |
no-cache का अर्थ “कभी संग्रह न करें” नहीं है। यह संग्रह की अनुमति देता है, लेकिन दोबारा इस्तेमाल से पहले सत्यापन मांगता है। no-store कैश को रिस्पॉन्स संग्रह न करने का निर्देश देता है। MDN का Cache-Control संदर्भ अंतर समझाता है। यह जांच कैश से मिले उत्तरों की संख्या नहीं मापती और पहले से संग्रहित कॉपी नहीं हटाती।
इंडेक्सिंग निर्देश सामग्री की ताज़गी से अलग फैसला है। इंडेक्स होने के लिए बनाई गई पेज अनपेक्षित noindex दे तो बदलाव से पहले जिम्मेदार ऐप्लिकेशन, सर्वर सेटिंग या रिस्पॉन्स नियम खोजें। HTML निर्देश भी देखने के लिए Noindex Checker इस्तेमाल करें। Google का noindex दस्तावेज़ निर्देश समझाता है; उसे देखना Google के वर्तमान इंडेक्स की स्थिति साबित नहीं करता।
सुरक्षा हेडर से जुड़ी टिप्पणियां समझें
Screpy कुछ खास घोषणाएं समीक्षा के लिए दिखाता है। निष्कर्ष को कॉन्फ़िगरेशन के सवाल की तरह लें, कमजोरी की रिपोर्ट या अनजान नीति को लाइव साइट पर कॉपी करने की सलाह की तरह नहीं।
| टिप्पणी | जांच क्या बताती है और क्या नहीं |
|---|---|
| HSTS समीक्षा | HTTPS रिस्पॉन्स में सकारात्मक max-age खोजती है। पूरा HTTPS सेटअप या प्रमाणपत्र सत्यापित नहीं करती। |
| CSP नहीं मिली | HTML घोषित रिस्पॉन्स में Content-Security-Policy खोजती है। हेडर मौजूद होना यह सुनिश्चित नहीं करता कि निर्देश ऐप्लिकेशन की रक्षा करते हैं। |
| फ़्रेम में जोड़ने की समीक्षा | CSP में frame-ancestors या मान्य X-Frame-Options मान खोजती है। पेज को दूसरे स्थान पर जोड़ने की अनुमति उसके काम पर निर्भर है। |
| MIME पहचान की समीक्षा | देखती है कि X-Content-Type-Options में nosniff घोषित है या नहीं। वास्तविक फ़ाइल सामग्री या हर ब्राउज़र का व्यवहार नहीं जांचती। |
सूचनात्मक टिप्पणी या नीति का न होना सुरक्षा की कमजोरी का प्रमाण नहीं है। उसी तरह हेडर मौजूद होने से नीति प्रभावी नहीं हो जाती। MDN का CSP दस्तावेज़ लागू होने वाली नीतियों और Content-Security-Policy-Report-Only में फर्क करता है। दूसरा उल्लंघन बताता है, लेकिन वे पाबंदियां लागू नहीं करता। उसे देखना किसी लागू नीति की मौजूदगी साबित नहीं करता।
नीति में बदलाव ऐप्लिकेशन के वास्तविक संसाधन और एम्बेडिंग की जरूरतों के अनुसार देखें। चेकर सुरक्षा अंक नहीं देता, प्रमाणपत्र नहीं जांचता और हर निर्देश सत्यापित नहीं करता। HTML के अंदर असुरक्षित संसाधन संदर्भ अलग से देखने के लिए Mixed Content Checker इस्तेमाल करें।
दोहराए गए और छिपे मानों का अर्थ समझें
हेडर की संख्या अलग सामान्यीकृत नामों की गिनती है। आवृत्ति वाला कॉलम बताता है कि एक नाम कितनी बार आया, और सामान्य दोहराए गए मान दिखाई देते हैं। एक से ज्यादा बार होना अपने आप त्रुटि नहीं है। देखें कि संबंधित फ़ील्ड उस संरचना की अनुमति देता है या नहीं और संयुक्त नीति इच्छित है या नहीं।
संवेदनशील कुकी, प्रमाणीकरण और पहचाने गए गोपनीय मान छिपाए या साफ़ किए जाते हैं। छिपा मान गायब हेडर नहीं है और उसकी मौजूदगी कुकी सुरक्षा का आकलन नहीं है। साझा रिपोर्ट में छिपाए गए मान वापस न भरें। गोपनीय विवरण केवल उचित निजी डिबगिंग वातावरण में देखें।
खोज बॉक्स हर मान में खोजेगा, यह मानने के बजाय cache-control जैसे नाम से फ़िल्टर करें। तुलना के लिए जांचे गए URL और समय के साथ रिपोर्ट रखें। एक फ़ील्ड की मौजूदगी या अनुपस्थिति अंतिम स्टेटस, संसाधन के प्रकार और कवरेज संदेश के साथ समझें।
अधूरी जांच और HTTP त्रुटियों में फर्क करें
सर्वर का त्रुटि देना और चेकर का सर्वर तक न पहुंच पाना अलग परिणाम हैं। गायब पंक्तियों का अर्थ निकालने से पहले कवरेज संदेश पढ़ें।
| परिणाम | अर्थ और अगला कदम |
|---|---|
हेडर के साथ अंतिम 404 या 500 |
रिस्पॉन्स मिला है। URL की पुष्टि करके संसाधन या सर्वर त्रुटि देखें; सफल कनेक्शन को सफल पेज न समझें। |
| आंशिक रिस्पॉन्स क्रम | कुछ चरण देखे गए, लेकिन अंतिम रिस्पॉन्स जांचा नहीं जा सका। अंतिम हेडर अज्ञात हैं, उनका गायब होना तय नहीं है। |
| टाइमआउट या अनुपलब्ध स्रोत | मांगा गया रिस्पॉन्स नहीं मिला। दोबारा प्रयास से पहले सार्वजनिक पहुंच, पता और रीडायरेक्ट जांचें। |
चेकर सीमित संख्या में रीडायरेक्ट का अनुसरण करता है और सीमित समय प्रतीक्षा करता है। लूप, पहुंच से बाहर लक्ष्य या समर्थित सीमा से बड़े रिस्पॉन्स जांच अधूरी छोड़ सकते हैं। उस स्थिति में खाली अंतिम सूची को गायब सुरक्षा हेडर की सूची न समझें।
निजी नेटवर्क पते, लॉगिन वाले पेज और आपकी ब्राउज़र कुकी मांगने वाले अनुरोध इस फ़ॉर्म के दायरे में नहीं हैं। पहुंच पर रोक यह भी साबित नहीं करती कि Googlebot या किसी दूसरे वास्तविक विज़िटर को क्या मिलता है।
प्रकाशन के बाद हेडर की तुलना करें
बदलाव से पहले सटीक URL, अंतिम रिस्पॉन्स, जांच का समय और बदलने वाला फ़ील्ड दर्ज करें। शुरुआती स्थिति रखने के लिए रिपोर्ट एक्सपोर्ट करें। इच्छित कॉन्फ़िगरेशन प्रकाशित करने के बाद वही URL जांचें और संबंधित मानों की तुलना करें, केवल हेडर या चेतावनियों की संख्या की नहीं। नियम दूसरे प्रकार के संसाधन पर भी लागू होना हो तो उसे भी जांचें।
ब्राउज़र कुछ और दिखाए तो उसका Network पैनल खोलें, पेज फिर लोड करें और संबंधित अनुरोध देखें। रीडायरेक्ट के बाद URL, तरीका और लॉगिन स्थिति की तुलना करें। कैश किया या व्यक्तिगत रिस्पॉन्स दूसरी जगह से किए सार्वजनिक अनुरोध जैसा होना जरूरी नहीं। यह फ़ॉर्म आपकी कुकी नहीं भेजता और अपना प्रमाणीकरण हेडर जोड़ने नहीं देता।
यह भी देखें कि दूसरे टूल ने GET की जगह HEAD इस्तेमाल किया था या नहीं। RFC 9110 बताता है कि HEAD में रिस्पॉन्स बॉडी नहीं होती और सामग्री बनाते समय तय होने वाले कुछ फ़ील्ड छोड़े जा सकते हैं। Screpy GET इस्तेमाल करता है, लेकिन बॉडी डाउनलोड से पहले रुकता है। तरीका और अनुरोध की शर्तें मिलाना अंतर की जांच में मदद करता है; हर सर्वर रिस्पॉन्स एक जैसा नहीं हो जाता।