301 vs 302 redirect: कौन-सा चुनें और Google कितने कदम तक जाता है
संक्षिप्त उत्तर: 301 vs 302 redirect के चुनाव में 301 (या उसका जोड़ीदार 308) वहाँ लगाइए जहाँ पुराना पता हमेशा के लिए चला गया है, और 302 (या 307) सिर्फ़ तब जब बदलाव अस्थायी हो और पुराना पता खोज में बना रहना चाहिए। Google स्थायी रीडायरेक्ट को लक्ष्य पेज प्रोसेस करने का मज़बूत संकेत मानता है और अस्थायी को कमज़ोर। वह डिफ़ॉल्ट रूप से 10 कदम (hop) तक पीछा करता है, फिर भी हर पुराने पते को एक ही कदम में अंतिम पते पर भेजिए।
301 vs 302 redirect: फ़र्क़ क्या है?
रीडायरेक्ट आपके सर्वर का वह जवाब है जो कहता है “यहाँ नहीं, वहाँ जाइए” और नया पता Location हेडर में बताता है। वजह स्टेटस कोड बताता है। HTTP मानक (RFC 9110) में 301 का मतलब है कि पेज को नया, स्थायी पता मिल गया है, और 302 का मतलब है कि वह सिर्फ़ कुछ समय के लिए कहीं और है, इसलिए क्लाइंट को मूल पता इस्तेमाल करते रहना चाहिए। Google यही फ़र्क़ पढ़ता है और उसी के हिसाब से काम करता है:
| कोड | मतलब | Google क्या करता है |
|---|---|---|
| 301 | हमेशा के लिए हटा (Moved permanently) | पीछा करता है; मज़बूत संकेत कि लक्ष्य को प्रोसेस किया जाए |
| 308 | स्थायी रीडायरेक्ट (Permanent redirect) | 301 जैसा |
| 302 | Found (अस्थायी) | पीछा करता है; कमज़ोर संकेत कि लक्ष्य को प्रोसेस किया जाए |
| 307 | अस्थायी रीडायरेक्ट (Temporary redirect) | 302 जैसा |
यह तालिका Google के HTTP स्टेटस कोड वाले पेज से है (आख़िरी अपडेट 2026-02-04)। खोज में इसका क्या मतलब है, यह Google के रीडायरेक्ट वाले पेज पर है (आख़िरी अपडेट 2026-04-14): स्थायी रीडायरेक्ट खोज नतीजों में नया लक्ष्य दिखाते हैं, अस्थायी रीडायरेक्ट स्रोत पेज दिखाते हैं। यहाँ लिंक किए Google के पेज हमने 4 नवंबर 2026 को पढ़े।
307 और 308 आख़िर हैं ही क्यों? Google उन्हें 302 और 301 की तरह बरतता है, पर नोट करता है कि वे अर्थ में अलग हैं, इसलिए वह कोड चुनिए जो मामले से मेल खाए। फ़र्क़ अनुरोध की विधि (method) का है: 301 या 302 के बाद क्लाइंट POST को GET में बदल सकता है, 307 या 308 के बाद उसे विधि वैसी ही रखनी होती है (RFC 9110, खंड 15.4)। पेज को सामान्य तरीक़े से खोलने में आपको यह फ़र्क़ नहीं दिखेगा; जिन फ़ॉर्म और API को POST अनुरोध मिलते हैं, उनके लिए 308 या 307 लीजिए।
कौन-सा रीडायरेक्ट कब चुनें?
एक सवाल ज़्यादातर मामले तय कर देता है। Google का रीडायरेक्ट वाला पेज कहता है: “Use permanent redirects when you're sure that the redirect won't be reverted.” यानी स्थायी रीडायरेक्ट तब लगाइए जब आपको पक्का हो कि उसे पलटा नहीं जाएगा। अगर पुराना पता कभी वापस नहीं आएगा, तो 301। अगर वापस आएगा, तो 302।
| स्थिति | क्या लगाएँ | टिप्पणी |
|---|---|---|
| पेज को नया पता मिला (नया slug, नया फ़ोल्डर) | 301 या 308 | नया लक्ष्य खोज में दिखता है |
| दो पेज मिलाकर एक कर दिए गए | हर पुराने पते से मिलाए हुए पेज पर 301 | Google की साइट-माइग्रेशन गाइड मिलाई गई सामग्री के लिए इसकी इजाज़त देती है |
| http से https, या www से बिना www (या उल्टा) | 301 या 308 | Google: एक पसंदीदा पता चुनिए और बाक़ी को उस पर रीडायरेक्ट कीजिए |
| कोई सेवा कुछ समय के लिए बंद है और आगंतुकों को समझाने वाला पेज दिखता है | 302 या 307 | पुराना पता खोज में बना रहता है |
| पेज चला गया और उसकी जगह कुछ नहीं | रीडायरेक्ट नहीं: 404 या 410 | कोई बराबर का पेज नहीं है तो होम पेज पर न भेजिए |
| बहुत-से पुराने पते होम पेज पर | मत कीजिए | Google कहता है कि इसे soft 404 माना जा सकता है |
आख़िरी पंक्ति Google की साइट-माइग्रेशन गाइड से है (आख़िरी अपडेट 2026-08-20), और ऐसे मामले कैसे पकड़ें, यह हमारा soft 404 error वाला लेख दिखाता है। गाइड पूरी साइट को नए डोमेन पर ले जाने के बारे में है, जो इस लेख से बड़ा काम है।
ग़लत चुनाव की क़ीमत क्या है? जो पेज हमेशा के लिए चला गया, उस पर 302 लगाना Google को कुछ ग़लत बताना है। अस्थायी रीडायरेक्ट स्रोत पेज को नतीजों में रखता है, और “the target page might still be indexed if other canonicalization signals are present”, यानी लक्ष्य पेज भी इंडेक्स हो सकता है अगर canonicalization के दूसरे संकेत मौजूद हों। यह “शायद” है, और हमें ऐसा कोई Google पेज नहीं मिला जो वादा करे कि बहुत दिन चला 302 बाद में 301 बन जाएगा। इसलिए इसका इंतज़ार मत कीजिए।
Google कितने रीडायरेक्ट तक जाता है?
Google का स्टेटस कोड वाला पेज कहता है: “By default, Google's crawlers follow up to 10 redirect hops.” Googlebot वेब सामग्री के लिए आम तौर पर 10 कदम तक पीछा करता है, Google के दूसरे उत्पादों की सीमाएँ अलग हो सकती हैं, और रीडायरेक्ट करने वाले पते ने जो भी लौटाया उसे अनदेखा किया जाता है; इसके बजाय अंतिम लक्ष्य की सामग्री प्रोसेस होती है।
दस ऊपरी सीमा है, लक्ष्य नहीं। साइट-माइग्रेशन गाइड सलाह देती है कि सीधे अंतिम मंज़िल पर रीडायरेक्ट कीजिए, और अगर यह न हो सके तो chain छोटी रखिए, बेहतर है कि 3 कदम से ज़्यादा नहीं और हर हाल में 5 से कम। उसकी वजह: “Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.” यानी chain वाले रीडायरेक्ट उपयोगकर्ताओं के लिए देरी बढ़ाते हैं, और सारे user agent और ब्राउज़र लंबी chain सँभालते भी नहीं। Google का क्रॉल त्रुटियों वाला पेज (आख़िरी अपडेट 2025-12-18) जोड़ता है कि लंबी chain का क्रॉलिंग पर बुरा असर पड़ता है।
Chain परत-दर-परत बढ़ती हैं, इरादे से नहीं। एक आम chain में पेज दिखने से पहले तीन कदम होते हैं:
http://example.com/old-guide 301 -> https://example.com/old-guide
https://example.com/old-guide 301 -> https://www.example.com/old-guide
https://www.example.com/old-guide 301 -> https://www.example.com/new-guide
https://www.example.com/new-guide 200
हल है हर पुराने पते के लिए एक कदम: पुराने पते की हर लिखावट एक ही 301 से जवाब दे जो सीधे अंतिम पता बताए। अपने लिंक पर भी यही लागू होता है: आंतरिक लिंक, canonical tag और साइटमैप की प्रविष्टियाँ अंतिम पते पर रखिए। रीडायरेक्ट बाहर से आने वाले आगंतुकों और पुराने बुकमार्क के लिए है, आपके अपने नेविगेशन के लिए नहीं।
301 रीडायरेक्ट कैसे लगाएँ
सर्वर-साइड रीडायरेक्ट इस्तेमाल कीजिए। Google का रीडायरेक्ट वाला पेज इसे उस प्रकार के रूप में गिनाता है जिसकी सही व्याख्या होने की सबसे ज़्यादा संभावना है। नीचे के nginx और Node के उदाहरण हमने 4 नवंबर 2026 को चलाए (nginx 1.24.0, Node 25.9.0) और जवाब curl से पढ़े। Apache की पंक्तियाँ Google का अपना उदाहरण हैं, जिन्हें हमने नहीं चलाया।
पहले nginx। location नियम https://example.com के server ब्लॉक में जाता है। दोनों server ब्लॉक बाक़ी हर लिखावट को एक ही कदम में वहीं भेजते हैं, और $request_uri पाथ और query string को बनाए रखता है:
# एक पेज हमेशा के लिए गया (अस्थायी बदलाव के लिए 302 लीजिए)
location = /old-guide {
return 301 https://example.com/new-guide;
}
# http:// और https://www. दोनों https://example.com पर जाते हैं
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/ssl/example.com.pem;
ssl_certificate_key /etc/ssl/example.com.key;
return 301 https://example.com$request_uri;
}
बिना किसी पैकेज के Node। अगर POST अनुरोध POST ही रहने चाहिए, तो 301 की जगह 308 लिखिए:
import http from 'node:http';
const moved = new Map([['/old-guide', '/new-guide']]); // पुराना पाथ -> नया पाथ
http.createServer((req, res) => {
const { pathname, search } = new URL(req.url, 'http://localhost');
const target = moved.get(pathname);
if (target) {
res.writeHead(301, { location: `https://example.com${target}${search}` });
return res.end();
}
res.writeHead(200, { 'content-type': 'text/plain' });
res.end('ok');
}).listen(3000);
Apache, Google के पेज से (सर्वर कॉन्फ़िगरेशन या .htaccess फ़ाइल में):
Redirect permanent "/old" "https://example.com/new"
Redirect temp "/two-old" "https://example.com/two-new"
अगर आप सर्वर को छू नहीं सकते, तो पहले अपना प्लेटफ़ॉर्म देखिए: Google Blogger और Shopify को ऐसे उदाहरण बताता है जिनमें रीडायरेक्ट के औज़ार पहले से हो सकते हैं। Google meta refresh (0 सेकंड स्थायी गिना जाता है, देरी अस्थायी) और JavaScript रीडायरेक्ट भी पढ़ता है, पर सिर्फ़ अंतिम उपाय के रूप में। JavaScript के साथ रेंडरिंग विफल हो तो Google उसे “might never see it”, यानी शायद कभी देखे ही नहीं।
अपने रीडायरेक्ट कैसे जाँचें, और SEOgrinder क्या पकड़ता है
दो curl कमांड काफ़ी हैं। पहला हर कदम को स्टेटस और लक्ष्य के साथ छापता है, दूसरा कदमों की गिनती और अंतिम पता देता है। वे HEAD की जगह GET इस्तेमाल करते हैं, क्योंकि कुछ सर्वर HEAD का जवाब अलग देते हैं:
curl -s -L -o /dev/null -D - http://example.com/old-guide | grep -i -E "^(HTTP|location)"
curl -s -L -o /dev/null -w "%{num_redirects} redirects, final: %{url_effective}\n" http://example.com/old-guide
उन सभी लिखावटों के लिए चलाइए जिनसे लोग और लिंक आप तक पहुँचते हैं: http और https, www के साथ और बिना। जो नतीजा चाहिए वह है एक 301 और फिर 200।
SEOgrinder हमारा टूल है; हम इसे बनाते हैं। SEOgrinder का मुफ़्त स्कैन रीडायरेक्ट को तीन जगह देखता है (नाम हिंदी इंटरफ़ेस के अनुसार):
- “तकनीक और सुरक्षा” टैब, “रीडायरेक्ट” कार्ड। यह उस पते के कदम गिनाता है जिसे आपने स्कैन किया। अगर वह पता एक से ज़्यादा बार रीडायरेक्ट करता है, तो कार्य “लगातार N रीडायरेक्ट” कदम दिखाता है और सलाह देता है कि पहले URL को सीधे अंतिम मंज़िल पर भेजिए।
- उसी टैब में “डोमेन की एकरूपता” कार्ड। वह उम्मीद करता है कि http और https, www के साथ और बिना, एक ही पते पर ख़त्म हों। अगर नहीं, तो कार्य “साइट के N आपस में प्रतिस्पर्धा करते रूप” आता है। “डोमेन का रीडायरेक्ट सिर्फ़ अस्थायी है” तब आता है जब कोई लिखावट 302, 303 या 307 से रीडायरेक्ट करती है।
- “Google पर पेज” टैब। कार्य “N आंतरिक लिंक घुमावदार रास्ते से होकर जाते हैं” उन आंतरिक लिंक को गिनाता है जिनका लक्ष्य रीडायरेक्ट करता है या canonical में किसी और पेज का नाम लेता है (स्कैन किए पेज के ज़्यादा से ज़्यादा 60 आंतरिक लिंक)।
दो सीमाएँ। chain की जाँच स्कैन किए गए पते और आपके डोमेन की लिखावटों को देखती है, आपकी साइट के हर पुराने पते को नहीं, इसलिए पुराने पते curl से जाँचिए। और SEOgrinder यह नहीं आँक सकता कि कोई लक्ष्य उपयुक्त उत्तराधिकारी है या नहीं, या Google ने किसी रीडायरेक्ट को कैसे बरता। “AI को सौंपें” किसी कार्य को coding agent के लिए ब्रीफ़िंग बना देता है, और “दोबारा जाँचें” आपके बदलाव के बाद नया स्कैन चलाता है।
आम ग़लतियाँ
- स्थायी बदलाव के लिए 302। पुराना पता नतीजों में रह सकता है। 301 या 308 लगाइए।
- अस्थायी चीज़ के लिए 301। जो दुकान एक हफ़्ते बंद है, उसे 302 चाहिए।
- एक-के-ऊपर-एक नियम जो chain बनाते हैं। पहले http, फिर https, फिर www, फिर नया पेज: तीन कदम। हर नियम में सीधे अंतिम पता लिखिए।
- सब कुछ होम पेज पर भेज देना। बराबर के पेज पर रीडायरेक्ट कीजिए, या 404 या 410 लौटाइए।
- आपके अपने लिंक जो अब भी पुराना पता इस्तेमाल करते हैं। आंतरिक लिंक, canonical और साइटमैप बदलिए।
- पुराने पते को robots.txt में रोक देना। तब Google उसे ला ही नहीं पाता और रीडायरेक्ट कभी नहीं देखता। Google की 2011 की पोस्ट Do 404s hurt my site? में जवाब देखने के लिए क्रॉलर को उस URL को क्रॉल कर पाना चाहिए (“has to be able to crawl that URL”)।
- रीडायरेक्ट बहुत जल्दी हटा देना। साइट माइग्रेशन के लिए Google कहता है: “Keep the redirects for as long as possible, generally at least 1 year.” इसे एक अकेले पेज पर लागू करना हमारी अपनी समझ है।
अक्सर पूछे जाने वाले सवाल
क्या 301 रीडायरेक्ट SEO को नुक़सान पहुँचाता है?
Google की साइट-माइग्रेशन गाइड कहती है: “301 and other permanent redirects don't cause a loss in PageRank.” यह वाक्य गाइड में साइट माइग्रेशन के लिए है, इसलिए इसे एक अकेले पेज पर लागू करना हमारी अपनी समझ है। Google जिन चीज़ों से चेताता है वे हैं लंबी chain, असंबंधित पेजों पर रीडायरेक्ट (soft 404) और माइग्रेशन के दौरान, जब तक वह दोबारा क्रॉल करता है, रैंकिंग में उतार-चढ़ाव।
क्या 308, 301 से बेहतर है?
Google के लिए दोनों बराबर हैं। 308 अनुरोध की विधि भी बनाए रखता है, जो फ़ॉर्म और API के लिए मायने रखता है। सामान्य पेजों के लिए 301 ठीक है।
Google को नया पता दिखाने में कितना समय लगता है?
एक अकेले पेज के लिए Google को कोई समय बताते हमने नहीं पाया। साइट माइग्रेशन के लिए वह कहता है कि मध्यम आकार की वेबसाइटों में “it can take a few weeks or more” लग सकते हैं, यानी नए URL धीरे-धीरे नतीजों में पुराने की जगह लेने में कुछ हफ़्ते या ज़्यादा लगा सकते हैं। कोई तारीख़ का वादा मत कीजिए।
आपका अगला कदम
पहला curl कमांड अपने पुराने पतों पर और अपने डोमेन की हर लिखावट पर चलाइए। अगर किसी अनुरोध में एक से ज़्यादा कदम लगें, तो पहले पते को सीधे अंतिम पते पर भेजिए। फिर अपनी साइट को SEOgrinder से स्कैन कीजिए, “तकनीक और सुरक्षा” टैब खोलिए, “रीडायरेक्ट” और “डोमेन की एकरूपता” देखिए, और बदलाव के बाद “दोबारा जाँचें” दबाइए। तकनीकी बुनियादी बातों के लिए हमारी SEO audit checklist भी देखिए।