सारांश: HTTP हेडर चेकर किसी भी URL का अनुरोध करता है, उसके रीडायरेक्ट का पालन करता है, और अंतिम स्टेटस code, हर रिस्पॉन्स हेडर, सात सिक्योरिटी हेडर पर आधारित एक सिक्योरिटी score, और कैशिंग व compression हेडर दिखाता है। पहले स्टेटस code और किसी भी X-Robots-Tag को देखें, क्योंकि एक हेडर ऐसे पेज को index से हटा सकता है जिसका HTML बिल्कुल ठीक दिखता है। फिर कैशिंग और compression, और अंत में सिक्योरिटी।
एक HTTP हेडर चेकर दिखाता है कि आपका सर्वर पेज शुरू होने से पहले क्या कहता है: स्टेटस code, कैशिंग के नियम, सिक्योरिटी नीतियाँ और कभी-कभी इंडेक्सिंग के निर्देश। ये हेडर पेज के source में नहीं दिखते, फिर भी Google इन्हें पढ़ता है। जो भी नियम आप robots meta tag में लगा सकते हैं, जैसे noindex, उसे X-Robots-Tag हेडर के रूप में भी भेजा जा सकता है, और यही तरीका उन फ़ाइलों को नियंत्रित करने का है जिनमें HTML नहीं होता, जैसे PDF या इमेज (Google Search Central, robots meta tag और X-Robots-Tag)। जब कोई पेज Google से बाहर हो जाए और उसका HTML कुछ गलत न दिखाए, तो अगली जगह हेडर ही हैं।
HTTP हेडर चेकर क्या दिखाता है?
एक URL डालें। टूल उसका अनुरोध करता है, रीडायरेक्ट को अंतिम पते तक फ़ॉलो करता है, और चार हिस्सों की रिपोर्ट लौटाता है।
| रिपोर्ट का हिस्सा | इसमें क्या है |
|---|---|
| मुख्य आँकड़े | अंतिम HTTP स्टेटस code, 7 में से कितने सिक्योरिटी हेडर मौजूद हैं, कुल हेडर की संख्या, सर्वर का नाम |
| Security हेडर | मौजूद या गायब, हर एक की वैल्यू और गंभीरता के साथ |
| Cache और performance | Cache-Control, Expires, ETag, Last-Modified, Age, Vary, Content-Encoding और Content-Type |
| सभी हेडर | लौटाए गए हर हेडर, वर्णमाला के क्रम में, माँग पर दिखाए गए |
एक त्वरित anti-bot सत्यापन के बाद प्रतिदिन तीन जाँचें मुफ़्त हैं। रिपोर्ट अंतिम URL का रिस्पॉन्स दिखाती है; रीडायरेक्ट श्रृंखला का हर चरण देखने के लिए रीडायरेक्ट चेकर इस्तेमाल करें।
कौन से हेडर SEO को प्रभावित करते हैं?
चार तरह के हेडर बदलते हैं कि सर्च इंजन किसी URL को कैसे crawl और index करते हैं। इन्हें हेडर की पूरी सूची में खोजें।
| Header | उदाहरण | Google पर असर |
|---|---|---|
| Status code | 200, 301, 404, 503 | 2xx रिस्पॉन्स index हो सकता है; Google 10 रीडायरेक्ट चरणों तक फ़ॉलो करता है (Google, HTTP स्टेटस codes) |
| X-Robots-Tag | X-Robots-Tag: noindex | robots meta tag वाले ही नियम, किसी भी फ़ाइल प्रकार पर लागू |
| Link, rel="canonical" | Link: <https://example.com/page>; rel="canonical" | पसंदीदा URL घोषित करता है, PDF के लिए उपयोगी |
| Link, rel="alternate" hreflang | Link: <https://example.com/de/>; rel="alternate"; hreflang="de" | भाषा के संस्करण घोषित करता है, तीन बराबर तरीकों में से एक |
Google के दस्तावेज़ों की दो चेतावनियाँ। canonical के लिए HTML link element या HTTP हेडर, दोनों में से एक चुनें: दोनों इस्तेमाल करना “ज़्यादा गलती की संभावना” वाला है, जैसे जब वे अलग-अलग URL की ओर इशारा करें (Google, डुप्लिकेट URL समेकित करें)। hreflang के लिए HTML, HTTP हेडर और sitemaps बराबर हैं, और हेडर गैर-HTML फ़ाइलों के लिए उपयोगी हैं (Google, स्थानीय संस्करण)। HTML वाले हिस्से की जाँच canonical चेकर और hreflang generator से करें।
Security score कैसे निकलता है?
Security score = मौजूद सिक्योरिटी हेडर ÷ 7 × 100। हर हेडर एक समान गिना जाता है, उसकी गंभीरता चाहे जो हो। रिंग 70% से हरी, 40% से नारंगी, और उससे नीचे लाल होती है।
| Header | गंभीरता | यह क्या करता है |
|---|---|---|
| Strict-Transport-Security (HSTS) | उच्च | ब्राउज़रों को बताता है कि इस होस्ट के लिए केवल HTTPS इस्तेमाल करें |
| Content-Security-Policy | उच्च | सीमित करता है कि पेज कौन सी scripts, styles और संसाधन लोड कर सकता है |
| X-Content-Type-Options | मध्यम | ब्राउज़रों को फ़ाइल प्रकार का अंदाज़ा लगाने से रोकता है (“nosniff”) |
| X-Frame-Options | मध्यम | दूसरी साइटों को आपके पेज फ़्रेम में डालने से रोकता है |
| Referrer-Policy | मध्यम | नियंत्रित करता है कि आपके URL उन साइटों को क्या बताते हैं जिनसे आप लिंक करते हैं |
| Permissions-Policy | मध्यम | ऐसे ब्राउज़र फ़ीचर बंद करता है जो आप इस्तेमाल नहीं करते, जैसे कैमरा |
| X-XSS-Protection | कम | पुराना फ़िल्टर, अब deprecated |
score मौजूदगी जाँचता है, गुणवत्ता नहीं: हर चीज़ को अनुमति देने वाली Content-Security-Policy भी “मौजूद” गिनी जाती है। और आखिरी अंक के पीछे न भागें: MDN X-XSS-Protection को deprecated बताता है और नए प्रोजेक्ट में इसके इस्तेमाल के खिलाफ़ सलाह देता है (MDN, X-XSS-Protection)। एक अच्छी तरह सुरक्षित आधुनिक साइट जानबूझकर 86% (7 में से 6) पर रह सकती है। OWASP Secure Headers Project हर हेडर के सुझाए गए मान दस्तावेज़ में देता है (OWASP Secure Headers Project)।
Caching और compression हेडर speed पर कैसे असर डालते हैं?
ये तय करते हैं कि लौटने वाला विज़िटर कितना दोबारा डाउनलोड करता है, और हर रिस्पॉन्स कितना भारी है।
- Cache-Control नियम तय करता है। “max-age=N” रिस्पॉन्स को N सेकंड तक ताज़ा रखता है; “no-कैश” स्टोरेज की अनुमति देता है पर हर दोबारा इस्तेमाल से पहले सर्वर से जाँच माँगता है; “no-store” स्टोरेज को मना करता है (MDN, Cache-Control)।
- ETag और Last-Modified ब्राउज़र को पूछने देते हैं कि फ़ाइल बदली है या नहीं, और अगर नहीं बदली तो पूरी फ़ाइल के बजाय एक छोटा जवाब मिलता है।
- Age दिखाता है कि CDN ने रिस्पॉन्स कितनी देर से रखा है: एक मान का मतलब है कि वह कैश से आया।
- Vary उन request हेडर की सूची देता है जो रिस्पॉन्स बदलते हैं, जैसे Accept-Encoding।
- Content-Encoding compression दिखाता है: gzip, br (Brotli) या zstd। बिना compression वाला HTML पेज ज़रूरत से कई गुना भारी डाउनलोड होता है।
एक आम पैटर्न: versioned नाम वाली स्थिर फ़ाइलों को लंबा max-age मिलता है, अक्सर “immutable” के साथ; HTML को छोटा max-age या “no-कैश” मिलता है, ताकि अपडेट तुरंत दिखें। पूरे पेज पर असर मापने के लिए page size चेकर इस्तेमाल करें।
एक स्वस्थ रिस्पॉन्स कैसा दिखता है?
यह एक ऐसे HTML पेज के हेडर का आम सेट है जो indexable है, समझदारी से कैश होता है, compressed है और सुरक्षित है, साथ में हर पंक्ति क्या बताती है।
| लौटाया गया हेडर | अर्थ |
|---|---|
| HTTP स्टेटस 200 | पेज सामान्य रूप से जवाब देता है और index हो सकता है |
| Content-Type: text/html; charset=utf-8 | घोषित character set वाला HTML पेज |
| Content-Encoding: br | Brotli से compressed |
| Cache-Control: max-age=300 | पाँच मिनट के लिए कैश, ताकि अपडेट जल्दी दिखें |
| Vary: Accept-Encoding | कैश compressed और uncompressed संस्करण अलग रखते हैं |
| Strict-Transport-Security: max-age=31536000 | एक साल तक केवल HTTPS |
| कोई X-Robots-Tag नहीं | कोई छिपी इंडेक्सिंग पाबंदी नहीं |
अगर Google में आने वाले पेज पर “X-Robots-Tag: noindex” दिखे, या जहाँ 301 की उम्मीद थी वहाँ 302, तो पहले उसे ठीक करें।
हेडर कब जाँचें?
- कोई पेज Google से गायब हो जाए और उसका HTML ठीक दिखे: X-Robots-Tag खोजें, फिर indexability चेकर से पुष्टि करें।
- माइग्रेशन, CDN बदलने या नए होस्टिंग प्लान के बाद, जब रीडायरेक्ट, कैश और सिक्योरिटी नियम थोक में फिर से लिखे जाते हैं।
- स्टेजिंग साइट लाइव होने के बाद, क्योंकि टेस्ट सर्वर पर लगाया गया सामान्य “noindex” हेडर अक्सर स्थानांतरण के बाद भी बना रहता है।
- किसी performance अभियान से पहले, ताकि देखा जा सके कि क्या कैश होता है, क्या compressed होता है, और क्या दोनों नहीं।
- PDF और इमेज के लिए जिन्हें index कराना या बाहर रखना है, क्योंकि हेडर ही उन्हें निर्देश देने का एकमात्र तरीका हैं।
जाँच की सीमाएँ क्या हैं?
टूल वही देखता है जो उसका अपना अनुरोध पाता है। कुछ सर्वर विज़िटर के आधार पर अलग जवाब देते हैं: firewall अज्ञात bots को रोक सकता है, CDN देश के अनुसार बदल सकता है, और कुछ साइटें सर्च इंजन क्रॉलर को अलग रिस्पॉन्स देती हैं। अगर नतीजा चौंकाए, तो उसे Google Search Console के URL Inspection टूल से मिलाएँ, जो दिखाता है कि Googlebot ने क्या पाया। रिपोर्ट अंतिम URL का ही रिस्पॉन्स दिखाती है; बीच के रीडायरेक्ट रीडायरेक्ट चेकर के दायरे में आते हैं।
पूरी साइट पर हेडर सही कैसे रखें?
पेजों के बजाय टेम्प्लेट जाँचें। हेडर आम तौर पर सर्वर, CDN या framework कॉन्फ़िगरेशन में एक बार सेट होते हैं, इसलिए एक गलत नियम हज़ारों URL को प्रभावित कर सकता है। हर infrastructure बदलाव के बाद हर प्रकार का एक URL जाँचें: होम पेज, आर्टिकल, प्रोडक्ट, PDF, इमेज।
एक व्यापक तकनीकी समीक्षा के लिए on-page SEO audit चलाएँ, और technical SEO audit पर हमारी ग्लॉसरी प्रविष्टि देखें। अपने सुधारों का असर traffic और AI जवाबों पर देखने के लिए Sorank GEO और SEO डैशबोर्ड इस्तेमाल करें, या Sorank SEO chat से पूछें कि कोई हेडर आपकी साइट के लिए क्या मायने रखता है।
Status code, X-Robots-Tag, canonical, फिर कैश और सिक्योरिटी: यही वह क्रम है जो पहले आपकी रैंकिंग बचाता है। ऊपर के टूल से अपने मुख्य URL जाँचें, फिर अपनी साइट को autopilot पर मॉनिटर करने के लिए Sorank plans देखें।
