वेबसाइट जाँचकर्ता कार्यप्रणाली

अंतिम अद्यतन: 21 अप्रैल, 2026

यह पृष्ठ बताता है कि वेबसाइट जाँचकर्ता किसी URL का मूल्यांकन कैसे करता है, हम क्या माप सकते हैं और क्या नहीं, और आपके ब्राउज़र का अनुभव हमारे परिणाम से क्यों भिन्न हो सकता है।

1. इनपुट सत्यापन और सुरक्षा फ़िल्टर

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

2. DNS जाँच

हम DNS रिकॉर्ड क्वेरी करते हैं और डोमेन-से-IP मैपिंग हल करते हैं। यदि कोई डोमेन सार्वजनिक रूप से हल नहीं होता, तो हम इसे स्पष्ट रूप से चिह्नित करते हैं ताकि उपयोगकर्ता DNS समस्याओं को वेब सर्वर समस्याओं से अलग कर सकें।

3. HTTP(S) अनुरोध व्यवहार

हम रीडायरेक्ट अनुसरण और समय माप के साथ HTTP(S) अनुरोध करते हैं। प्रतिक्रिया में स्थिति कोड, रीडायरेक्ट संख्या, अंतिम URL, सामग्री प्रकार और जब उपलब्ध हो तो बुनियादी पृष्ठ मेटाडेटा शामिल होता है।

4. SSL/TLS प्रबंधन

हम पहले सख्त SSL सत्यापन का प्रयास करते हैं। यदि सख्त SSL हैंडशेक विफल हो, तो हम यह जानने के लिए शिथिल अनुवर्ती जाँच चला सकते हैं कि होस्ट पहुँच योग्य है पर गलत कॉन्फ़िगर है। ऐसे मामलों में हम SSL चिंताओं को अलग से चिह्नित करते हैं, न कि साइट को चुपचाप स्वस्थ मानते हैं।

5. दर सीमा और एंटी-बॉट पृष्ठ

कुछ वेबसाइटें स्वचालित अनुरोधों को अवरुद्ध करती हैं (उदाहरण: WAF चुनौती या Cloudflare सुरक्षा)। जब हम इन पैटर्न का पता लगाते हैं, तो परिणाम को सीमित के रूप में लेबल करते हैं ताकि उपयोगकर्ता बॉट अवरोधन को पूर्ण आउटेज से न भ्रमित हों।

ज्ञात सीमाएँ

  • परिणाम हमारे सर्वर स्थान से हैं, हर वैश्विक क्षेत्र से नहीं।
  • जाँच ऑन-डिमांड स्नैपशॉट हैं, निरंतर निगरानी नहीं।
  • 200 प्रतिक्रिया हर पृष्ठ पथ के स्वस्थ होने की गारंटी नहीं देती।
  • उपयोगकर्ता-पक्ष समस्याएँ (ISP अवरोध, ब्राउज़र कैश, एक्सटेंशन) सर्वर-पक्ष जाँच से भिन्न हो सकती हैं।

परिणामों का जिम्मेदारी से उपयोग

जाँचकर्ता परिणाम को एक तकनीकी डेटा बिंदु मानें। गंभीर घटनाओं के लिए इसे सर्वर लॉग, कई क्षेत्रों से सिंथेटिक निगरानी और अपने होस्टिंग प्रदाता के निदान के साथ मिलाएँ।