HTTP स्टेटस कोड: हर रिस्पॉन्स कोड की पूरी गाइड

हर HTTP रिस्पॉन्स की शुरुआत तीन अंकों की एक संख्या से होती है, और यह संख्या सर्वर का सबसे संक्षिप्त जवाब है कि आपके अनुरोध का क्या हुआ। अधिकतर समय आप इसे देखते ही नहीं: पेज लोड हो जाता है और ब्राउज़र आगे बढ़ जाता है। यह संख्या तभी दिखती है जब कुछ गड़बड़ हो, और ठीक उसी समय आपको इसका अर्थ जानना होता है।

लेकिन स्टेटस कोड केवल निदान नहीं हैं, वे निर्देश हैं। एक 301 सर्च इंजन से कहता है कि वह अपनी इंडेक्स प्रविष्टि स्थायी रूप से बदल ले; एक 429 क्लाइंट को ठीक-ठीक बताता है कि कैसे धीमा होना है; एक 503 क्रॉलर से कहता है कि आपका पेज हटाने के बजाय बाद में लौटे। गलत कोड लौटाना ट्रैफ़िक गँवाने के सबसे चुपचाप तरीकों में से एक है, क्योंकि दिखने में कुछ टूटता नहीं। यह गाइड हर श्रेणी, असल में मिलने वाले कोड, और किसी URL का सच में लौटाया जाने वाला कोड जाँचने का तरीका बताती है।

स्टेटस कोड क्यों मायने रखते हैं

आपके स्टेटस कोड चार पक्ष पढ़ते हैं, और हर एक उन पर अलग तरह से काम करता है:

• ब्राउज़र। वे तय करते हैं कि रीडायरेक्ट का पालन करें या नहीं, कैश की प्रति दोबारा इस्तेमाल करें या नहीं, और फ़ॉर्म का डेटा फिर भेजें या नहीं।
• सर्च इंजन। कोड तय करता है कि URL इंडेक्स होगी, किसी दूसरी में मिला दी जाएगी, बाद में फिर आज़माई जाएगी, या छोड़ दी जाएगी। एक सुंदर «नहीं मिला» पेज को 200 के साथ देना सबसे पुरानी गलती है: क्रॉलर को बताया जाता है कि पेज मौजूद है और वह उसे इंडेक्स में रखे रहता है।
• API क्लाइंट। अच्छे क्लाइंट कोड के आधार पर रास्ता चुनते हैं। 429 या 503 पर दोबारा कोशिश करना सही है; 400 पर कभी नहीं, क्योंकि गलत बने अनुरोध को दोहराने से वही त्रुटि मिलेगी।
• आपकी अपनी निगरानी। त्रुटि-दर और अलर्ट लगभग हमेशा स्टेटस कोड पर बनते हैं, इसलिए जो सेवा त्रुटि को बॉडी में रखकर 200 लौटाती है वह अपने ही डैशबोर्ड के लिए अदृश्य रहती है।

पाँच श्रेणियाँ

पहला अंक बताता है कि ज़िम्मेदारी किसकी है और आगे क्या करना है। और कुछ याद न रहे तो यह तालिका याद रखें।

4xx और 5xx का बँटवारा व्यवहार में सबसे महत्वपूर्ण है, क्योंकि किसी घटना के दौरान वही एक सवाल हल करता है जो मायने रखता है: यह मुझे ठीक करना है या उन्हें?

वे कोड जो आपको असल में मिलेंगे

दर्जनों पंजीकृत कोड हैं, पर एक कार्यदिवस में शायद पंद्रह ही सामने आते हैं। सफलता के कोड सबसे सरल हैं। 200 OK सामान्य उत्तर है। 201 Created उस POST का सही उत्तर है जिसने कुछ बनाया, और उसमें नए संसाधन की ओर इशारा करता Location हेडर होना चाहिए। 204 No Content कहता है कि अनुरोध सफल रहा और जान-बूझकर कुछ लौटाना नहीं है, जो DELETE का सही उत्तर है। 206 Partial Content वही है जिससे वीडियो में आगे-पीछे जाना और रुके डाउनलोड फिर शुरू होना संभव होता है।

रीडायरेक्ट: 301, 302, 307 और 308

रीडायरेक्ट किसी भी अन्य श्रेणी से अधिक SEO नुकसान करते हैं, और लगभग हमेशा इसलिए कि स्थायी और अस्थायी रूप आपस में बदल जाते हैं।

• 301 Moved Permanently — URL हमेशा के लिए बदल गई। सर्च इंजन रैंकिंग संकेत नए पते पर ले जाते हैं और अंत में पुराने को इंडेक्स में बदल देते हैं। डोमेन माइग्रेशन, HTTP से HTTPS, और www जोड़ने या हटाने में इसका उपयोग करें।
• 302 Found — अस्थायी। पुरानी URL इंडेक्स में बनी रहती है क्योंकि आपने कहा है कि वह लौटेगी। A/B परीक्षण, छोटी मेंटेनेंस अवधि और जिस भौगोलिक रूटिंग को आप पलटना चाहते हैं, उसमें इसका उपयोग करें।
• 307 Temporary Redirect — 302 जैसा, पर मेथड और बॉडी के सुरक्षित रहने की गारंटी के साथ। 307 से रीडायरेक्ट किया POST, POST ही पहुँचता है; पहले कुछ क्लाइंट रीडायरेक्ट किए POST को GET बना देते थे।
• 308 Permanent Redirect — 307 का स्थायी रूप: 301 जैसा ही कैशिंग व्यवहार, मेथड सुरक्षित रखते हुए।
• 304 Not Modified — असल में रीडायरेक्ट नहीं है। यह एक शर्तीय अनुरोध का उत्तर है और इसका अर्थ है «आपकी कैश प्रति अब भी ठीक है», इसीलिए ठीक से कॉन्फ़िगर साइट अपने पेज वज़न से बहुत कम डेटा भेजती है।

दो नियम: जहाँ एक छलाँग काफ़ी हो वहाँ रीडायरेक्ट की कड़ी न बनाएँ, क्योंकि हर छलाँग विलंब और क्रॉल बजट लेती है; और हर गुम पेज को होमपेज पर कभी न भेजें। दूसरी बात सुव्यवस्थित लगती है पर उपयोगकर्ताओं और क्रॉलरों दोनों को झूठ बताती है।

क्लाइंट त्रुटियाँ: 400, 401, 403, 404 और 429

4xx परिवार कहता है कि समस्या अनुरोध में ही थी। इन भेदों को ठीक रखना ज़रूरी है, क्योंकि क्लाइंट हर एक पर अलग व्यवहार करते हैं।

• 400 Bad Request — गलत बनावट: टूटा JSON, कोई अनिवार्य फ़ील्ड गायब, या न पढ़ा जा सकने वाला पैरामीटर। जैसा भेजा गया है, वैसा दोहराने योग्य कभी नहीं।
• 401 Unauthorized — नाम भ्रामक है; इसका अर्थ अप्रमाणित है। कोई प्रमाण नहीं, या ऐसे प्रमाण जिन्हें सर्वर जाँच नहीं सका। इसमें WWW-Authenticate हेडर होना चाहिए।
• 403 Forbidden — सर्वर जानता है आप कौन हैं और फिर भी आपको अनुमति नहीं है। दोबारा लॉगिन करने से कुछ नहीं होगा।
• 404 Not Found — इस URL पर कुछ मौजूद नहीं है। सर्वर यह नहीं बताता कि कभी था या नहीं।
• 405 Method Not Allowed — URL मौजूद है, पर इस क्रिया के लिए नहीं। जो क्रियाएँ चलती हैं उनकी सूची वाला Allow हेडर जोड़ें।
• 409 Conflict — अनुरोध वर्तमान स्थिति से टकराता है, जैसे दोहरी कुंजी या पुराना संस्करण।
• 410 Gone — संसाधन था और जान-बूझकर हटाया गया। सर्च इंजन 410 को 404 से तेज़ी से छोड़ते हैं, इसलिए जब आपने सामग्री जान-बूझकर हटाई हो तो यही बेहतर विकल्प है।
• 422 Unprocessable Content — बनावट पढ़ी जा सकी पर मान मान्यता जाँच में विफल रहे। «मैं इसे पढ़ नहीं सकता» और «मैंने पढ़ा और यह गलत है» को अलग करने में उपयोगी।
• 429 Too Many Requests — आपने दर सीमा पार कर दी। इसे हमेशा Retry-After हेडर के साथ भेजें; उसके बिना क्लाइंट तुरंत दोबारा कोशिश करते हैं और अधिभार बढ़ा देते हैं।

सर्वर त्रुटियाँ: 500, 502, 503 और 504

5xx का अर्थ है कि आपका अनुरोध उचित था और सर्वर फिर भी विफल हुआ। चार आम कोड अलग-अलग परतों की ओर इशारा करते हैं, जिससे घटना के समय वे सचमुच उपयोगी बनते हैं।

• 500 Internal Server Error — एप्लिकेशन में अनहैंडल्ड अपवाद। सामान्य सर्वव्यापी कोड, और लॉग में सबसे पहले ढूँढने वाली चीज़।
• 502 Bad Gateway — प्रॉक्सी या लोड बैलेंसर को अपस्ट्रीम से अमान्य या खाली उत्तर मिला। आमतौर पर प्रॉक्सी के पीछे का एप्लिकेशन क्रैश हो गया या सुन नहीं रहा था।
• 503 Service Unavailable — सर्वर पर अधिभार है या वह मेंटेनेंस में है। इस परिवार का यही एक कोड है जिसे आपको नियोजित डाउनटाइम में Retry-After हेडर के साथ जान-बूझकर लौटाना चाहिए: क्रॉलर पेज रखे रहते हैं और लौट आते हैं।
• 504 Gateway Timeout — प्रॉक्सी ने अपस्ट्रीम का इंतज़ार किया और हार मान ली। यह क्रैश के बजाय किसी धीमी निर्भरता की ओर इशारा करता है।

किसी व्यवधान के दौरान 502 और 504 का अंतर बताता है कि आपका एप्लिकेशन बंद हो गया या बस धीमा हो गया, और यह अक्सर सबसे तेज़ उपलब्ध संकेत होता है।

स्टेटस कोड और SEO

सर्च इंजन स्टेटस कोड को किसी URL के बारे में अंतिम कथन मानते हैं और पेज की सामग्री से अधिक उसी पर भरोसा करते हैं। इससे चार नतीजे निकलते हैं:

1. «सॉफ़्ट 404» क्रॉल बजट बरबाद करते हैं। 200 के साथ दिया गया «पेज नहीं मिला» संदेश एक मरी हुई URL को इंडेक्स में रखता है, जहाँ वह आपके असली पेजों से होड़ करती है। असली 404 या 410 लौटाएँ।
2. स्थायी बदलाव के लिए 301 का उपयोग करें। असली बदलाव पर 302 पुरानी URL को इंडेक्स में छोड़ देता है और संकेतों को दो पतों में बाँट देता है।
3. रीडायरेक्ट की कड़ियाँ छोटी रखें। हर छलाँग विलंब जोड़ती है और क्रॉलर सीमित संख्या तक ही पीछा करते हैं। पुरानी URL को सीधे अंतिम गंतव्य पर भेजें।
4. मेंटेनेंस के दौरान 503 लौटाएँ। Retry-After वाला 503 क्रॉलर से लौटने को कहता है। टाइमआउट या 500 टूटी हुई साइट जैसा लगता है।

रीडायरेक्ट HTTPS से भी जुड़े हैं। यदि http:// से https:// का आपका रीडायरेक्ट लगा है पर प्रमाणपत्र अमान्य है या समाप्त हो चुका है, तो रीडायरेक्ट के मायने रखने से पहले ही आने वालों को ब्राउज़र की चेतावनी दिखती है, इसलिए साथ ही SSL प्रमाणपत्र जाँचकर्ता से प्रमाणपत्र की पुष्टि कर लेना ठीक रहता है।

स्टेटस कोड कैसे जाँचें

सफल लोड पर आपका ब्राउज़र कोड छिपा देता है, इसलिए उसे स्पष्ट रूप से माँगना पड़ता है। तीन भरोसेमंद तरीके:

1. ब्राउज़र का नेटवर्क पैनल। डेवलपर टूल खोलें, पेज फिर लोड करें और स्टेटस कॉलम पढ़ें। यह पूरी रीडायरेक्ट कड़ी दिखाता है, जो अकेली संख्या नहीं दिखा सकती।
2. curl -I https://example.com। HEAD अनुरोध बॉडी डाउनलोड किए बिना स्टेटस पंक्ति और हेडर छापता है। रीडायरेक्ट का पीछा करने और हर छलाँग देखने के लिए -L जोड़ें।
3. खोजने योग्य संदर्भ। जब संख्या आपके पास हो और अर्थ, दायित्व तथा सामान्य कारण चाहिए हों, तो हमारा HTTP स्टेटस कोड संदर्भ हर कोड के साथ बताता है कि क्या करना है।

संख्या के अलावा दो बातें जाँचें। पहली, वही URL आज़माएँ जिस पर उपयोगकर्ता पहुँचेगा, अंत में स्लैश सहित या रहित, क्योंकि दोनों अक्सर अलग तरह से हल होती हैं। दूसरी, यदि उत्तर 429 है तो Retry-After का मान पढ़ें और देखें कि आपके क्लाइंट की प्रतीक्षा उसका सच में पालन करती है या नहीं; दर सीमा कैलकुलेटर किसी सीमा को ठोस अंतराल में बदल देता है।

बचने योग्य आम गलतियाँ

• बॉडी में त्रुटि रखकर 200 लौटाना। निगरानी, कैश, क्रॉलर और क्लाइंट सब कोड पढ़ते हैं, आपका JSON नहीं। सूची की सबसे भारी गलती यही है।
• स्थायी बदलाव के लिए 302 का उपयोग। रैंकिंग संकेत पुरानी URL पर ही रह जाते हैं, कभी-कभी महीनों तक।
• सभी 404 को होमपेज पर भेजना। यह टूटे लिंक आपसे छिपा देता है और क्रॉलरों के लिए «सॉफ़्ट 404» बनाता है।
• जहाँ 401 चाहिए वहाँ 403। 403 पाने वाला क्लाइंट प्रमाणीकरण की कोशिश नहीं करेगा, क्योंकि 403 कहता है कि समस्या प्रमाणीकरण नहीं है।
• Retry-After के बिना 429। तब क्लाइंट अनुमान लगाते हैं, आमतौर पर «अभी» का, जो ठीक वही व्यवहार है जिसे रोकने के लिए सीमा है।
• मेंटेनेंस में टाइमआउट देना। इंडेक्स प्रविष्टियाँ बचाने के लिए Retry-After वाला 503 लौटाएँ।
• माइग्रेशन के बाद लंबी रीडायरेक्ट कड़ियाँ। हर माइग्रेशन एक छलाँग जोड़ता है; अगली बार नियम छूते समय उन्हें एक में समेट दें।

अपने स्टेटस कोड जाँचें

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

संबंधित टूल और गाइड:

• HTTP स्टेटस कोड — हर रिस्पॉन्स कोड के लिए खोजने योग्य संदर्भ।
• दर सीमा कैलकुलेटर — सीमा को सुरक्षित अंतराल और Retry-After में बदलें।
• DNS लुकअप — उत्तरों की डीबगिंग से पहले पुष्टि करें कि डोमेन हल होता है।
• SSL प्रमाणपत्र जाँचकर्ता — अपने HTTPS रीडायरेक्ट के पीछे का प्रमाणपत्र जाँचें।
• 301 और 302 रीडायरेक्ट: कौन सा चुनें और SEO क्या देखता है - कौन-सा रीडायरेक्ट इस्तेमाल करें और हर एक रैंकिंग पर क्या असर डालता है।
• 404 या 410: हटाई गई पेज के बारे में Google को क्या बताता है - हर कोड Google को हटाए गए पेज के बारे में क्या बताता है।

अक्सर पूछे जाने वाले प्रश्न