HTTP रीडायरेक्ट कोड: 301, 302, 307, 308 में अंतर

रीडायरेक्ट देखने में आसान लगता है: सर्वर एक HTTP स्टेटस कोड और Location हेडर के साथ जवाब देता है, और क्लाइंट वहां चला जाता है। लेकिन यही तीन अंक तय करते हैं कि ब्राउज़र रीडायरेक्ट को कैश कर सकते हैं या नहीं, POST रिक्वेस्ट POST ही रहती है या नहीं, और सर्च इंजन संभवतः किस URL को इंडेक्स करेंगे।

इस गाइड में RFC 9110 में परिभाषित 3xx कैटेगरी, इसके कोड के आपस में मिलते-जुलते होने के पीछे का इतिहास, बिना स्टेटस कोड वाले रीडायरेक्ट, और आम सर्वरों पर सही कोड कॉन्फ़िगर करने का तरीका शामिल है।

3xx कैटेगरी का मतलब

HTTP सिमेंटिक्स के मौजूदा स्पेसिफ़िकेशन RFC 9110 के मुताबिक 3xx स्टेटस कोड बताता है कि “रिक्वेस्ट पूरी करने के लिए यूज़र एजेंट को आगे कोई कदम उठाना होगा”। सेक्शन 15.4 इन कोड को चार तरह के रीडायरेक्ट में बांटता है:

रिसोर्स किसी दूसरे URI पर उपलब्ध है, जो Location में दिया गया है: 301, 302, 307 और 308।
क्लाइंट रिसोर्स के कई रूपों (representations) में से चुन सकता है: 300।
कोई दूसरा रिसोर्स रिक्वेस्ट का अप्रत्यक्ष जवाब देता है: 303।
क्लाइंट अपने कैश में पहले से मौजूद कॉपी दोबारा इस्तेमाल कर सकता है: 304।

असल में सिर्फ़ 301, 302, 303, 307 और 308 ही ऑटोमैटिक रीडायरेक्ट की तरह काम करते हैं। ब्राउज़र जिस Fetch Standard को लागू करते हैं, वह ठीक इन्हीं पांच कोड को “redirect statuses” कहता है। 300 को आम तौर पर एक सामान्य पेज की तरह दिखाया जाता है, और 304 क्लाइंट से अपने कैश की कॉपी इस्तेमाल करने को कहता है।

Location की वैल्यू /new-page या ../shop/ जैसा रिलेटिव रेफ़रेंस भी हो सकती है। क्लाइंट उसे उस URL के आधार पर पूरा करता है जिसे उसने अभी-अभी रिक्वेस्ट किया था (RFC 9110, सेक्शन 10.2.2)। अगर Location में कोई फ़्रैगमेंट (# वाला हिस्सा) नहीं है, तो मूल फ़्रैगमेंट बना रहता है: /guide#install का लिंक, जो /docs/guide पर रीडायरेक्ट होता है, /docs/guide#install पर पहुंचता है।

पांच असली रीडायरेक्ट में से कौन-सा कोड सही है, यह दो सवालों से तय होता है:

बदलाव स्थायी है या अस्थायी? स्थायी रीडायरेक्ट कैश किए जा सकते हैं, और ये सर्च इंजन को संकेत देते हैं कि पुराने की जगह नया URL इंडेक्स करें।
क्या रिक्वेस्ट मेथड बनाए रखना ज़रूरी है? यह तब मायने रखता है जब मूल रिक्वेस्ट सादा GET न होकर POST, PUT या DELETE हो।

रीडायरेक्ट स्टेटस कोड एक नज़र में

कोड	नाम	स्थायी	मेथड बना रहता है	डिफ़ॉल्ट रूप से कैश करने योग्य	आम इस्तेमाल	Google Search
300	Multiple Choices	–	–	हां	वैकल्पिक रूप पेश करना (बहुत कम)	–
301	Moved Permanently	हां	नहीं: POST बदलकर GET बन सकता है	हां	नई जगह गए पेज और साइटें, HTTPS और होस्ट का कैननिकलाइज़ेशन	स्थायी (मज़बूत सिग्नल)
302	Found	नहीं	नहीं: POST बदलकर GET बन सकता है	नहीं	कम समय के रीडायरेक्ट, लॉगिन वॉल, A/B टेस्ट	अस्थायी (कमज़ोर सिग्नल)
303	See Other	नहीं	नहीं: GET बन जाता है	नहीं	फ़ॉर्म सबमिट होने के बाद नतीजे वाला पेज	अस्थायी
304	Not Modified	रीडायरेक्ट नहीं	–	–	कंडीशनल रिक्वेस्ट का जवाब	कॉन्टेंट नहीं बदला
305	Use Proxy	डेप्रिकेटेड	–	–	इस्तेमाल न करें	–
306	(Unused)	रिज़र्व	–	–	इस्तेमाल न करें	–
307	Temporary Redirect	नहीं	हां	नहीं	किसी भी मेथड के अस्थायी रीडायरेक्ट	अस्थायी
308	Permanent Redirect	हां	हां	हां	API, फ़ॉर्म या किसी भी URL का स्थायी बदलाव	स्थायी (मज़बूत सिग्नल)

“डिफ़ॉल्ट रूप से कैश करने योग्य” का मतलब है कि RFC 9110, सेक्शन 15.1 के तहत यह कोड ह्यूरिस्टिक तौर पर, यानी अनुमान के आधार पर, कैश करने योग्य (heuristically cacheable) है: कैश, सर्वर से पूछे बिना रिस्पॉन्स को दोबारा इस्तेमाल कर सकता है, भले ही उसमें फ़्रेशनेस की कोई साफ़ जानकारी न हो। फिर भी Cache-Control से किसी भी रिस्पॉन्स को कैश करने योग्य या कैश न करने योग्य बनाया जा सकता है। Google वाला कॉलम रीडायरेक्ट और HTTP स्टेटस कोड पर Google के डॉक्यूमेंटेशन का सार है।

हर कोड विस्तार से

300 Multiple Choices

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

301 Moved Permanently

टारगेट रिसोर्स को “एक नया स्थायी URI दे दिया गया है, और आगे इस रिसोर्स के हर रेफ़रेंस में दिए गए URI में से किसी एक का इस्तेमाल होना चाहिए”। नई जगह गए पेज, बदले हुए डोमेन, HTTP से HTTPS पर अपग्रेड और कैननिकल होस्ट पर रीडायरेक्ट के लिए यही स्टैंडर्ड कोड है।

दो बातें अहम हैं। 301 ह्यूरिस्टिक तौर पर कैश करने योग्य है, इसलिए ब्राउज़र इसे याद रख सकते हैं और सर्वर से पूछना बंद कर सकते हैं (नीचे कैशिंग वाला सेक्शन देखें)। और ऐतिहासिक कारणों से, 301 को फ़ॉलो करते समय क्लाइंट POST को GET में बदल सकता है, और ब्राउज़र ऐसा करते भी हैं। GET से लोड होने वाले पेजों के लिए इससे कोई फ़र्क नहीं पड़ता; फ़ॉर्म एंडपॉइंट या API के लिए 308 इस्तेमाल करें।

302 Found

टारगेट रिसोर्स “कुछ समय के लिए किसी दूसरे URI पर है”, इसलिए क्लाइंट को आगे की रिक्वेस्ट के लिए मूल URL ही इस्तेमाल करते रहना चाहिए। 302 डिफ़ॉल्ट रूप से कैश करने योग्य नहीं है। इसे कम समय वाली स्थितियों में इस्तेमाल करें: कोई सेल पेज (जैसे दिवाली सेल) जो एक हफ़्ते के लिए किसी कैटेगरी की जगह ले, लॉगिन वॉल, जगह के हिसाब से रूटिंग या A/B टेस्ट।

301 की तरह 302 भी POST को GET में बदलने की इजाज़त देता है। कोड न बताने पर कई फ़्रेमवर्क 302 भेजते हैं, और इसी वजह से स्थायी बदलाव अक्सर गलती से 302 बन जाते हैं।

303 See Other

303 क्लाइंट को एक दूसरे रिसोर्स पर भेजता है, जो मूल रिक्वेस्ट का अप्रत्यक्ष जवाब होता है, और क्लाइंट उसे GET (या HEAD) से लाता है। इसे Post/Redirect/Get पैटर्न के लिए बनाया गया है: फ़ॉर्म सबमिशन प्रोसेस करने के बाद सर्वर, कन्फ़र्मेशन या नतीजे वाले पेज के URL के साथ 303 भेजता है। फिर उस पेज को रीलोड करने पर फ़ॉर्म दोबारा सबमिट नहीं होता, बस एक बेनुकसान GET दोहराया जाता है।

303 डिफ़ॉल्ट रूप से कैश करने योग्य नहीं है, और यह दावा नहीं करता कि मूल URL कहीं और चला गया है। Google इसे 302 की तरह ही मानता है।

304 Not Modified (रीडायरेक्ट नहीं)

3xx नंबर होने के बावजूद 304 क्लाइंट को कहीं नहीं भेजता। यह कंडीशनल GET या HEAD रिक्वेस्ट का जवाब है: ऐसी रिक्वेस्ट जिसमें ETag वैल्यू के साथ If-None-Match हो, या किसी तारीख के साथ If-Modified-Since। अगर रिसोर्स नहीं बदला है, तो सर्वर बिना बॉडी के 304 लौटाता है, और क्लाइंट अपने कैश की कॉपी इस्तेमाल करता है।

HTTP

GET /styles.css HTTP/1.1
Host: example.com
If-None-Match: "5f1c-3a2b"

HTTP/1.1 304 Not Modified
ETag: "5f1c-3a2b"
Cache-Control: max-age=3600

रीडायरेक्ट चेकर बिना शर्त वाली (unconditional) रिक्वेस्ट भेजते हैं, इसलिए उन्हें आम तौर पर 304 कभी नहीं दिखता। TrueURL में इसे टेस्ट करने के लिए एक सामान्य जांच चलाएं, उसके रिस्पॉन्स हेडर से ETag की वैल्यू कॉपी करें, और उसे कस्टम रिक्वेस्ट हेडर में If-None-Match हेडर के रूप में भेजें। Googlebot के लिए 304 का मतलब है कि पिछले क्रॉल के बाद से कॉन्टेंट नहीं बदला।

305 Use Proxy और 306 (Unused)

305 क्लाइंट से कहता था कि वह Location में बताए गए प्रॉक्सी के ज़रिए रिक्वेस्ट दोहराए। किसी रिस्पॉन्स को क्लाइंट का प्रॉक्सी बदलने देना सुरक्षा के लिए खतरा है, इसलिए RFC 7231 ने इस कोड को डेप्रिकेट कर दिया, और आज के ब्राउज़र इस पर अमल नहीं करते।

306 स्पेसिफ़िकेशन के एक पुराने वर्शन में परिभाषित था (इसे अक्सर Switch Proxy के नाम से लिखा जाता है) और अब रिज़र्व है। किसी आधुनिक ऐप्लिकेशन में इन दोनों में से किसी भी कोड की जगह नहीं है; अगर आपको इनमें से कोई दिखे, तो कहीं कुछ गलत कॉन्फ़िगर है।

307 Temporary Redirect

307 का मतलब वही है जो 302 का, बस एक बात और: क्लाइंट रिक्वेस्ट मेथड नहीं बदल सकता। POST को उसी बॉडी के साथ नए URL पर POST के रूप में ही दोबारा भेजा जाता है। इसीलिए API और फ़ॉर्म एंडपॉइंट के लिए 307 सही अस्थायी रीडायरेक्ट है।

Chrome DevTools में भी आपको http:// से https:// पर 307 Internal Redirect के रूप में 307 दिख सकता है। यह सर्वर ने कभी भेजा ही नहीं। ब्राउज़र ने खुद रिक्वेस्ट को अपग्रेड किया, आम तौर पर उस HSTS (Strict-Transport-Security) पॉलिसी की वजह से जो उसने साइट के लिए सेव कर रखी है।

308 Permanent Redirect

308, 301 का वह रूप है जो मेथड बनाए रखता है: स्थायी, ह्यूरिस्टिक तौर पर कैश करने योग्य, और क्लाइंट मेथड नहीं बदल सकता। इसे पहली बार 2014 में प्रायोगिक (experimental) RFC 7238 में प्रकाशित किया गया, 2015 में RFC 7538 के साथ यह स्टैंडर्ड बना, और अब यह RFC 9110 का हिस्सा है।

जिन एंडपॉइंट पर POST, PUT या DELETE रिक्वेस्ट आती हैं, उनके स्थायी बदलाव के लिए 308 इस्तेमाल करें। सामान्य पेजों के लिए 301 और 308 में से कोई भी चलेगा, और Google दोनों को स्थायी रीडायरेक्ट मानता है।

303, 307 और 308 क्यों बने

301/302 और 303/307/308 का आपस में मिलता-जुलता होना किसी सोची-समझी योजना का नहीं, बल्कि इतिहास का नतीजा है।

HTTP/1.0 (RFC 1945, 1996) ने 301 Moved Permanently और 302 Moved Temporarily परिभाषित किए। इसमें कहा गया था कि यूज़र एजेंट को यूज़र की पुष्टि के बिना किसी POST को अपने-आप रीडायरेक्ट नहीं करना चाहिए, और यह भी दर्ज था कि कुछ यूज़र एजेंट गलती से POST को GET में बदल देते हैं। ब्राउज़र ऐसा करते रहे।

HTTP/1.1 ने दो ऐसे कोड जोड़े जिनके मतलब को लेकर भ्रम की कोई गुंजाइश नहीं थी। RFC 2068 (1997) ने 303 See Other पेश किया, जो हमेशा GET पर आ जाता है। RFC 2616 (1999) ने 307 Temporary Redirect जोड़ा, जो हमेशा मेथड बनाए रखता है, 302 का नाम बदलकर Found किया, और खुलकर माना कि ज़्यादातर यूज़र एजेंट 302 के साथ 303 जैसा बर्ताव करते थे।

फिर भी मेथड बनाए रखने वाला कोई स्थायी रीडायरेक्ट नहीं था। यह कमी पंद्रह साल बाद 308 ने पूरी की। इस बीच स्पेसिफ़िकेशन ने हकीकत को स्वीकार कर लिया: RFC 7231 (2014) के बाद से यूज़र एजेंट 301 या 302 के बाद POST को GET में बदल सकता है।

आज ब्राउज़र Fetch Standard के ये नियम लागू करते हैं:

स्टेटस	मूल मेथड	ब्राउज़र नए URL को किस मेथड से रिक्वेस्ट करते हैं
301, 302	POST	GET, बॉडी के बिना
301, 302	कोई और मेथड	वही मेथड
303	GET और HEAD को छोड़कर कोई भी मेथड	GET, बॉडी के बिना
303	GET या HEAD	वही मेथड
307, 308	कोई भी मेथड	वही मेथड और वही बॉडी

301 या 302 के बाद सिर्फ़ POST बदला जाता है; PUT या DELETE का मेथड वही रहता है। लेकिन इस पर भरोसा करना जोखिम भरा है, क्योंकि HTTP लाइब्रेरी अलग-अलग तरह से बर्ताव करती हैं, इसलिए जब भी मेथड मायने रखता हो, 307 या 308 इस्तेमाल करें।

बिना 3xx स्टेटस कोड वाले रीडायरेक्ट

मेटा रिफ़्रेश

HTML

<meta http-equiv="refresh" content="0; url=https://example.com/new-page">

पेज खुद 200 OK के साथ आता है, और ब्राउज़र उसे लोड करने के बाद टैग को फ़ॉलो करता है। नंबर सेकंड में देरी बताता है। Google तुरंत होने वाले मेटा रिफ़्रेश को स्थायी रीडायरेक्ट और देरी वाले को अस्थायी रीडायरेक्ट मानता है।

तय समय के बाद होने वाले रिफ़्रेश ऐक्सेसिबिलिटी को भी नुकसान पहुंचाते हैं। WCAG तुरंत होने वाले मेटा रिफ़्रेश को क्लाइंट-साइड रीडायरेक्ट के रूप में स्वीकार करता है (तकनीक H76), लेकिन टाइमर वाले रिफ़्रेश को विफलता (F40) मानता है, क्योंकि पेज ऐसे टाइमर पर बदलता है जिसे यूज़र कंट्रोल नहीं कर सकते।

JavaScript रीडायरेक्ट

HTML

<script>
  window.location.replace('https://example.com/new-page');
</script>

location.replace() रीडायरेक्ट करने वाले पेज को सेशन हिस्ट्री में नहीं छोड़ता, इसलिए Back बटन दबाने पर यूज़र दोबारा उसी रीडायरेक्ट में नहीं फंसते। location.href असाइन करने पर वह पेज हिस्ट्री में बना रहता है।

Google JavaScript सिर्फ़ तब चलाता है जब वह पेज को क्रॉल करने के बाद रेंडर करता है, और रेंडरिंग फ़ेल भी हो सकती है। उसका डॉक्यूमेंटेशन JavaScript रीडायरेक्ट की सलाह सिर्फ़ तब देता है जब सर्वर-साइड और मेटा रिफ़्रेश रीडायरेक्ट मुमकिन न हों। कई दूसरे बॉट और टूल JavaScript कभी चलाते ही नहीं।

Refresh हेडर

HTTP

HTTP/1.1 200 OK
Content-Type: text/html
Refresh: 0; url=https://example.com/new-page

Refresh हेडर किसी भी HTTP RFC में परिभाषित नहीं है। ब्राउज़र दशकों से इसे सपोर्ट करते आए हैं, और HTML Standard इसे मेटा रिफ़्रेश टैग के बराबर मानता है। curl समेत कई HTTP क्लाइंट और टूल इसे अनदेखा कर देते हैं, इसलिए असली 3xx रीडायरेक्ट को ही प्राथमिकता दें।

रीडायरेक्ट सही तरीके से कैसे लागू करें

nginx

# Every http:// request, on either host, goes to the canonical HTTPS URL in one hop
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# https://www.example.com -> https://example.com
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and ssl_certificate_key as above

    # One moved page
    location = /old-page {
        return 301 /new-page;
    }

    # A whole section, keeping the rest of the path
    location /blog/ {
        rewrite ^/blog/(.*)$ /articles/$1 permanent;
    }
}

$request_uri में मूल पाथ और क्वेरी स्ट्रिंग होती है, इसलिए कुछ भी छूटता नहीं। rewrite ... permanent एक 301 भेजता है और rewrite ... redirect एक 302; 307 या 308 के लिए उसी कोड के साथ return इस्तेमाल करें।

Apache (.htaccess)

Apache

# mod_alias: one page, and a whole folder (the rest of the path is appended)
Redirect 301 /old-page https://example.com/new-page
Redirect 301 /blog/ https://example.com/articles/

# mod_alias with a regular expression
RedirectMatch 301 ^/products/([0-9]+)\.html$ https://example.com/p/$1

# mod_rewrite: send every http:// and www request to https://example.com in one hop
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

स्टेटस कोड के बिना Redirect एक 302 भेजता है, इसलिए कोड हमेशा लिखें। अगर Apache के आगे कोई लोड बैलेंसर या CDN है जो उससे सादे HTTP पर जुड़ता है, तो %{HTTPS} हमेशा off रहता है और आखिरी नियम लूप बना देता है; इसकी जगह %{HTTP:X-Forwarded-Proto} जांचें। mod_alias और mod_rewrite एक-दूसरे से स्वतंत्र काम करते हैं, और फ़ाइल में लाइनों का क्रम यह तय नहीं करता कि कौन-सा मॉड्यूल पहले चलेगा। जो URL दोनों के नियमों से मेल खाता है, जैसे यहां http://www.example.com/old-page, उसमें दो हॉप (रीडायरेक्ट चेन के कदम) लग सकते हैं; जिन URL को एक ही हॉप में रीडायरेक्ट होना है, उनके सारे नियम एक ही मॉड्यूल में रखें।

Cloudflare

Cloudflare रिक्वेस्ट के आपके सर्वर तक पहुंचने से पहले ही एज पर रीडायरेक्ट कर सकता है:

Single Redirects (डैशबोर्ड का Redirect Rules सेक्शन) फ़िल्टर एक्सप्रेशन से रिक्वेस्ट को मैच करते हैं और उन्हें 301, 302, 303, 307 या 308 के साथ किसी स्टैटिक या डायनैमिक टारगेट पर भेजते हैं। www से बिना www वाले मूल डोमेन (apex) पर भेजने वाले एक आम नियम की सेटिंग्स ये होती हैं:
```
When incoming requests match:  (http.host eq "www.example.com")
URL redirect type:             Dynamic
Expression:                    concat("https://example.com", http.request.uri.path)
Status code:                   301
Preserve query string:         On
```
Bulk Redirects सोर्स और टारगेट URL की लंबी लिस्ट संभालते हैं, जैसे CSV के रूप में अपलोड किया गया माइग्रेशन मैप। हर एंट्री का अपना स्टेटस कोड और क्वेरी स्ट्रिंग बनाए रखने जैसे विकल्प होते हैं, और एक Bulk Redirect Rule उस लिस्ट को चालू करता है।
Workers कोड में Response.redirect() से रीडायरेक्ट बना सकते हैं:

JavaScript

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === '/old-page') {
      url.pathname = '/new-page'; // the query string is kept
      return Response.redirect(url.toString(), 301);
    }
    return fetch(request);
  },
};

Response.redirect() डिफ़ॉल्ट रूप से 302 भेजता है और सिर्फ़ 301, 302, 303, 307 और 308 स्वीकार करता है। कोई और कोड देने पर RangeError आता है।

Node.js और Express

JavaScript

import express from 'express';

const app = express();
app.set('trust proxy', 1); // when running behind a load balancer or CDN

// HTTPS and the canonical host in one hop
app.use((req, res, next) => {
  if (req.secure && req.hostname === 'example.com') return next();
  res.redirect(301, `https://example.com${req.originalUrl}`);
});

// One moved page
app.get('/old-page', (req, res) => {
  res.redirect(301, '/new-page');
});

स्टेटस के बिना res.redirect(url) एक 302 भेजता है। Express 5 सिर्फ़ res.redirect(status, url) वाला क्रम सपोर्ट करता है। सादे Node.js में स्टेटस और हेडर खुद सेट करें:

JavaScript

res.writeHead(301, { Location: 'https://example.com/new-page' });
res.end();

PHP

<?php
// Must run before any output is sent.
header('Location: https://example.com/new-page', true, 301);
exit;

अकेला Location हेडर होने पर PHP 302 भेजता है (जब तक पहले से 201 या कोई 3xx स्टेटस सेट न हो), इसलिए कोड को तीसरे आर्ग्युमेंट के रूप में दें, और exit करें ताकि आगे कुछ और न चले। WordPress में wp_redirect() और wp_safe_redirect() भी डिफ़ॉल्ट रूप से 302 भेजते हैं; दूसरे आर्ग्युमेंट के रूप में 301 दें।

सही रीडायरेक्ट कोड कैसे चुनें

पेज हमेशा के लिए नई जगह चला गया है और यह GET से लोड होने वाला सामान्य पेज है: 301 इस्तेमाल करें। 308 भी उतना ही अच्छा काम करता है।
बदलाव स्थायी है और क्लाइंट POST, PUT या DELETE भेज सकते हैं, जैसे API, फ़ॉर्म ऐक्शन और वेबहुक में: 308 इस्तेमाल करें।
रीडायरेक्ट अस्थायी है और सिर्फ़ GET मायने रखता है: 302 इस्तेमाल करें।
रीडायरेक्ट अस्थायी है और मेथड बनाए रखना ज़रूरी है: 307 इस्तेमाल करें।
कोई फ़ॉर्म या दूसरा POST प्रोसेस हो चुका है और यूज़र को नतीजे वाला पेज दिखना चाहिए: 303 इस्तेमाल करें।
HTTP से HTTPS: 301 या 308 इस्तेमाल करें, और HTTPS साइट से Strict-Transport-Security हेडर भेजें, ताकि अगली बार ब्राउज़र असुरक्षित रिक्वेस्ट भेजे ही नहीं।
कॉन्टेंट हट चुका है और उसका कोई विकल्प नहीं है: रीडायरेक्ट न करें। 404 या 410 लौटाएं। किसी असंबंधित पेज, जैसे होम पेज, पर किए गए रीडायरेक्ट को Google सॉफ़्ट 404 (soft 404) मान सकता है।
300, 305 और 306: इन्हें इस्तेमाल न करें। 304 कंडीशनल रिक्वेस्ट के जवाब में आपका सर्वर या कैश खुद बनाता है, और रीडायरेक्ट के लिए इसे कभी नहीं चुना जाता।

301 और 308 में कैशिंग का जाल

301 और 308 ह्यूरिस्टिक तौर पर कैश करने योग्य हैं, इसलिए ब्राउज़र इन्हें स्टोर करके सर्वर से पूछना बंद कर सकते हैं। Chromium पर आधारित ब्राउज़र, बिना कैशिंग हेडर वाले 301 या 308 को तब तक रखे रहते हैं जब तक वह एंट्री कैश से हट न जाए या यूज़र कैश साफ़ न कर दे। कोई गलत स्थायी रीडायरेक्ट, सर्वर ठीक करने के काफ़ी समय बाद तक पुराने विज़िटर को गलत जगह भेजता रह सकता है, और आप उसे उनके ब्राउज़र से भरोसेमंद तरीके से वापस नहीं ले सकते।

सुरक्षित रहने के लिए:

नए नियमों को पहले 302 या 307 से टेस्ट करें, और डेस्टिनेशन पक्का होने के बाद 301 या 308 पर जाएं।
या फिर, रोलआउट के दौरान यह सीमित कर दें कि स्थायी रीडायरेक्ट कितनी देर तक कैश किया जा सकता है:

nginx

location = /old-page {
    add_header Cache-Control "max-age=3600";
    return 301 https://example.com/new-page;
}

टेस्ट करते समय प्राइवेट विंडो, Disable cache चालू करके DevTools, या कोई सर्वर-साइड चेकर इस्तेमाल करें, जो कभी ब्राउज़र कैश का इस्तेमाल नहीं करता।
रीडायरेक्ट बदलने के बाद CDN और प्रॉक्सी कैश पर्ज करें, क्योंकि वे भी रीडायरेक्ट स्टोर कर सकते हैं।
कैश हो चुके A → B रीडायरेक्ट को, B से वापस A पर रीडायरेक्ट करके पलटने की कोशिश न करें। जिन विज़िटर के ब्राउज़र ने पहला रीडायरेक्ट कैश कर लिया है, वे लूप में फंस सकते हैं।

अपने रीडायरेक्ट टेस्ट करें

आपका प्लेटफ़ॉर्म जो भी हो, नतीजे को बाहर से जांचें। 301 रीडायरेक्ट चेकर पुष्टि करता है कि स्थायी बदलाव का हर हॉप 301 या 308 है, रीडायरेक्ट चेन चेकर हर हॉप को उसके Location और हेडर के साथ दिखाता है, और HTTPS रीडायरेक्ट चेकर प्रोटोकॉल और होस्ट के चारों रूप एक साथ टेस्ट करता है। मेटा रिफ़्रेश चेकर ऐसे क्लाइंट-साइड रीडायरेक्ट ढूंढता है जो सिर्फ़ हेडर पढ़ने वाले टूल से छूट जाते हैं, और रीडायरेक्ट लेटेंसी चेकर मापता है कि हर हॉप में कितना समय लगता है।

टर्मिनल में curl -sIL https://example.com/old-page हर हॉप के हेडर प्रिंट करता है। URL रीडायरेक्ट कैसे चेक करें पर हमारी गाइड में कमांड लाइन, DevTools और रीडायरेक्ट की आम समस्याओं के बारे में विस्तार से बताया गया है।

3xx कैटेगरी का मतलब

रीडायरेक्ट स्टेटस कोड एक नज़र में

हर कोड विस्तार से

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

304 Not Modified (रीडायरेक्ट नहीं)

305 Use Proxy और 306 (Unused)

307 Temporary Redirect

308 Permanent Redirect

303, 307 और 308 क्यों बने

बिना 3xx स्टेटस कोड वाले रीडायरेक्ट

मेटा रिफ़्रेश

JavaScript रीडायरेक्ट

Refresh हेडर

रीडायरेक्ट सही तरीके से कैसे लागू करें

nginx

Apache (.htaccess)

Cloudflare

Node.js और Express

PHP

सही रीडायरेक्ट कोड कैसे चुनें

301 और 308 में कैशिंग का जाल

अपने रीडायरेक्ट टेस्ट करें

संबंधित टूल

301 रीडायरेक्ट चेकर

रीडायरेक्ट चेन चेकर

HTTPS रीडायरेक्ट चेकर

मेटा रिफ़्रेश चेकर

रीडायरेक्ट लेटेंसी चेकर