सामग्री पर जाएँ
🚀 10 टूल लाइव, हमेशा के लिए मुफ़्त — टूलबॉक्स बढ़ता जा रहा है
होम›ब्लॉग›301 और 302 रीडायरेक्ट: कौन सा चुनें और SEO क्या देखता है
गाइड

301 और 302 रीडायरेक्ट: कौन सा चुनें और SEO क्या देखता है

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

✍ संस्थापक और CEO द्वारा, टीम BuildToolForge🗓 2026-10-16⏱ 10 मिनट
httpredirectsstatus-codesseoredirect chains
HTTP संदर्भ2026

301 vs 302
सरल भाषा में

301 कब और 302 कब इस्तेमाल करें

स्टेटस लाइन · Location हेडर · Cache-Control

curl · example.com
$ curl -I https://example.com/old
HTTP/2301 Moved Permanently
locationhttps://example.com/new
cachemax-age=3600
✓ स्थायी · रैंकिंग सिग्नल नए URL को मिलते हैं
रीडायरेक्ट कोड
301
स्थायी
302
Found
303
See Other
307
अस्थायी
308
स्थायी
300
एकाधिक
लिंक इक्विटी बनाए रखेंचेन से बचेंसही कैशिंगकोई रीडायरेक्ट लूप नहीं

रीडायरेक्ट असल में क्या है

रीडायरेक्ट कोई पेज नहीं है। वह बिना काम के बॉडी वाला एक जवाब है: 3xx श्रेणी का एक स्टेटस कोड और एक Location हेडर जो बताता है कि उसकी जगह कहाँ जाना है। क्लाइंट वह हेडर पढ़ता है और नए URL को दूसरी रिक्वेस्ट भेजता है।

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

व्यवहार में रीडायरेक्ट के पाँच कोड हैं, लेकिन पूरा फ़ैसला एक सवाल पर आता है: यह बदलाव स्थायी है या नहीं?

301 और 302: असली फ़र्क

301 Moved Permanently कहता है: यह URL हमेशा के लिए गया, अब से नया इस्तेमाल करो और जो सहेजा है उसे अपडेट कर लो। 302 Found कहता है: फ़िलहाल यह दूसरा URL दो, मगर मूल URL माँगते रहो, क्योंकि वह वापस आ रहा है।

इससे तीन नतीजे निकलते हैं, और पूरा व्यावहारिक फ़र्क उन्हीं में है:

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

तो नियम यह नहीं है कि «SEO के लिए 301 बेहतर है», चाहे यह हर जगह लिखा मिले। नियम यह है: 301 तब बेहतर है जब बदलाव सचमुच स्थायी हो, और तब सचमुच बुरा है जब न हो।

SEO असल में क्या देखता है

आज के सर्च इंजन लोककथाओं से ज़्यादा उदार हैं, और इसी से कुछ ज़िद्दी मिथक बने हैं जिन्हें साफ़ करना चाहिए।

  • «301 में लिंक इक्विटी का 15% चला जाता है।» यह सालों पहले लागू रहे एक क्षय गुणक से आया था। Google ने कहा है कि वह रीडायरेक्ट पर PageRank का पतला होना लागू नहीं करता। ठीक से लगाया गया 301 संकेत आगे पहुँचाता है।
  • «302 कुछ आगे नहीं पहुँचाता।» पूरी तरह नहीं। लंबे समय से लगे 302 को Google आख़िरकार स्थायी जैसा मानने लगता है, क्योंकि व्यवहार घोषणा का खंडन करता है। लेकिन उस «आख़िरकार» का बोझ भारी है: आप हफ़्तों या महीनों तक गलत URL को इंडेक्स में रखते हैं, और समय आपके हाथ में नहीं होता।
  • «रीडायरेक्ट से रैंकिंग को हमेशा नुकसान होता है।» किसी नज़दीकी से जुड़े पेज पर एक साफ़ रीडायरेक्ट आम बात है और आम तौर पर कुछ नापने लायक खर्च नहीं करता। नुकसान तब होता है जब आप असंबंधित जगह मोड़ते हैं: सौ बंद उत्पाद पेजों को होमपेज पर भेजना सॉफ़्ट 404 की तरह पढ़ा जाता है, और उन पेजों के संकेत कहीं नहीं जाते।

असली जोखिम मिथकों से ज़्यादा फीके हैं: चेन, लूप, आपस में टकराते संकेत, और साइटमैप में पड़े रीडायरेक्ट होने वाले URL। ये नीचे हैं।

कौन सा, किस स्थिति में

लगभग हर मामला इनमें से किसी एक में आता है।

301 लें

आपने कोई slug बदला या पाथ का ढाँचा फिर से बनाया। नए डोमेन पर चले गए। एक कैनोनिकल होस्टनाम चुना और दूसरे को उसका पीछा करना है — www से एपेक्स या उलटा। HTTPS लागू कर रहे हैं। दो पेज मिलाकर एक कर दिए। किसी उत्पाद पेज को बंद कर उसकी जगह लेने वाली कैटेगरी पर भेजा। इन सब में पुराना URL कभी वापस नहीं आएगा, और 301 ठीक यही घोषित करता है।

302 लें

असली पेज बंद होने तक मेंटेनेंस या कोई अस्थायी पेज। किसी पेज के दो रूपों का A/B टेस्ट। भौगोलिक या भाषा के हिसाब से रूटिंग, जहाँ मूल URL को कैनोनिकल बना रहना है। आम पेज की जगह कोई अस्थायी प्रचार पेज। साइन-इन वाला रीडायरेक्ट जो बाद में उपयोगकर्ता को वापस भेज देता है। यहाँ आप चाहते हैं कि मूल URL इंडेक्स में बना रहे, और 301 उसे हटा देगा।

307 और 308 कब मायने रखते हैं

307 Temporary Redirect और 308 Permanent Redirect 302 और 301 के सख़्त रूप हैं। फ़र्क HTTP मेथड का है: 301 और 302 के साथ क्लाइंट ऐतिहासिक रूप से रीडायरेक्ट का पीछा करते समय POST को GET बना देते थे, और वह व्यवहार अब पक्का हो चुका है। 307 और 308 को मेथड और बॉडी बनाए रखना ही होता है।

पेज के आम बदलावों के लिए 301 और 302 ही वह हैं जिनकी सर्च इंजन अपेक्षा करते हैं और जिन्हें आपको लेना चाहिए। API और फ़ॉर्म सबमिशन के लिए 307 या 308 लें: रीडायरेक्ट हुआ POST जो चुपचाप GET बन जाता है, रिक्वेस्ट बॉडी खो देता है, और उससे बनी गड़बड़ी ढूँढना सिर दर्द है।

303 और वह एक काम जिसके लिए वह है

303 See Other जान-बूझकर अगली रिक्वेस्ट को GET बना देता है। उसका सही उपयोग पोस्ट-और-रीडायरेक्ट का तरीक़ा है: फ़ॉर्म का POST स्वीकार करें, फिर 303 से परिणाम पेज पर भेजें, ताकि ब्राउज़र रीफ़्रेश करने पर फ़ॉर्म दोबारा न जाए। यह सामान्य इस्तेमाल का रीडायरेक्ट नहीं है और पेज बदलने में उसकी कोई जगह नहीं।

मेटा रीफ़्रेश और JavaScript रीडायरेक्ट

विज़िटर को हटाने के दो गैर-HTTP तरीक़े हैं, और दोनों दिखने से ज़्यादा बुरे हैं।

मेटा रीफ़्रेश (<meta http-equiv="refresh">) को ब्राउज़र पेज डाउनलोड करने के बाद संभालता है। सर्च इंजन उसका पीछा करते हैं और बिना देरी वाले रीफ़्रेश को आम तौर पर स्थायी रीडायरेक्ट मानते हैं, लेकिन वह धीमा है, HTML रेंडर न करने वाली हर चीज़ के लिए अदृश्य है, बैक बटन तोड़ता है, और देरी के साथ असली सुगम्यता समस्या है। इसे सिर्फ़ तब इस्तेमाल करें जब सर्वर कॉन्फ़िगरेशन तक आपकी पहुँच बिल्कुल न हो।

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

चेन और लूप: ट्रैफ़िक असल में कहाँ रिसता है

यही हिस्सा असली पैसे का नुकसान करता है, और लगभग हमेशा अनजाने में बनता है।

चेन का मतलब है रीडायरेक्ट पर रीडायरेक्ट। यह सालों में, एक-एक नियम से बनती है: http://example.com → https://example.com → https://www.example.com → https://www.example.com/naya-page। हर छलांग पूरा चक्कर है, इसलिए मोबाइल कनेक्शन पर चार छलाँगों की चेन साफ़ धीमी लगती है, और क्रॉलर लंबी चेन पर हार मान लेते हैं — Google सीमित छलाँगों तक पीछा करता है और फिर रुक जाता है। पहली URL को सीधे अंतिम लक्ष्य पर भेजकर चेन खत्म करें।

लूप क्लाइंट को वहीं लौटा देता है जहाँ से उसने शुरू किया था, और पेज कभी लोड नहीं होता। क्लासिक वजह है दो नियमों की असहमति: एक www लागू करता है, दूसरा एपेक्स, और हर एक दूसरे को पलट देता है। करीब बीस छलाँगों के बाद ब्राउज़र ERR_TOO_MANY_REDIRECTS दिखाते हैं। यह दिखे तो समझिए दो नियम लड़ रहे हैं, एक नियम टूटा नहीं है।

दो और रिसाव जाँचने लायक हैं:

  • साइटमैप में छूटे रीडायरेक्ट होने वाले URL। साइटमैप में सिर्फ़ अंतिम ठिकाने होने चाहिए। रीडायरेक्ट करने वाला URL डालना क्रॉलर से कहना है कि अपना बजट एक छलाँग पर खर्च करे।
  • रीडायरेक्ट से टकराता कैनोनिकल टैग। जिस पेज पर आप पहुँचते हैं, अगर वह कैनोनिकल में पुराने URL की ओर इशारा करता है, तो आपने दो उलटे निर्देश दे दिए और इंजन आपकी जगह चुन लेगा।

कैसे जाँचें कि URL असल में क्या देता है

पता बार देखकर 301 और 302 में फ़र्क नहीं किया जा सकता — दोनों एक ही जगह पहुँचते हैं। जवाब पढ़ना पड़ता है।

ये तीन चीज़ें जाँचें:

  • पहले जवाब का स्टेटस कोड, आख़िरी का नहीं। ब्राउज़र का नेटवर्क पैनल पूरा क्रम दिखाता है; स्थायित्व की घोषणा पहली पंक्ति करती है।
  • छलाँगों का पूरा क्रम। आपने जो URL डाला और जो पेज रेंडर हुआ, उनके बीच के रीडायरेक्ट गिनें। एक से ज़्यादा देखने लायक है; दो से ज़्यादा वह चेन है जिसे खत्म करना चाहिए।
  • चेन कोड मिलाती है या नहीं। 301 के बाद 302 एक आम और भ्रमित करने वाला पैटर्न है जो कहता है «स्थायी रूप से किसी अस्थायी जगह चला गया»।

कोई HTTP स्टेटस कोड चेकर हर छलाँग का स्टेटस और हर चरण का Location हेडर दिखाता है, और यही वह नज़ारा है जिसकी आपको ज़रूरत है। खास तौर पर HTTPS और होस्टनाम के नियमों के लिए SSL सर्टिफ़िकेट चेकर से पक्का करें कि सर्टिफ़िकेट उस होस्ट को कवर करता है जिस पर आप भेज रहे हैं: जिस होस्ट को सर्टिफ़िकेट कवर नहीं करता, उस पर रीडायरेक्ट चलती साइट की जगह चेतावनी का पन्ना देता है।

आम गलतियाँ

  • किसी अस्थायी चीज़ के लिए 301 लेना। ब्राउज़र उसे कैश करते हैं, इसलिए नियम हटाने के बाद भी लौटने वाले विज़िटर मुड़ते रहते हैं। उसे साफ़ करना आपके हाथ में नहीं।
  • स्थायी बदलाव के लिए 302 लेना और सोचना कि पुराना URL अब भी क्यों रैंक कर रहा है। आपने इंजन से कहा था कि कैनोनिकल पुराना है।
  • बंद की गई हर चीज़ को होमपेज पर मोड़ना। Google असंबंधित ठिकाने को सॉफ़्ट 404 मानता है। सबसे नज़दीकी समतुल्य पेज पर भेजें, या समतुल्य न हो तो साफ़ 410 दें।
  • चेन को जमा होने देना। हर नया नियम पिछले को बदलने के बजाय उस पर चढ़ जाता है।
  • होस्टनाम के दो नियम लड़ना, जिससे लूप बनता है। एक कैनोनिकल होस्टनाम तय करें और उसके लिए ठीक एक नियम लिखें।
  • POST को 301 या 302 से मोड़ना। मेथड GET बन जाता है और बॉडी चली जाती है। जो सिर्फ़ पेज देखना नहीं है, उसके लिए 307 या 308 लें।
  • साइटमैप में रीडायरेक्ट वाले URL छोड़ना, या आंतरिक लिंक पुराने URL पर रखना। अपने लिंक अपडेट करें; रीडायरेक्ट दूसरों के लिंक के लिए है।

संक्षेप में

301 का मतलब स्थायी है: सर्च इंजन रैंकिंग संकेत नए URL पर ले जाते हैं और ब्राउज़र उसे सख़्ती से कैश करते हैं, इसलिए उसे slug बदलने, डोमेन बदलने, HTTPS और होस्टनाम की कैनोनिकलाइज़ेशन के लिए लें — और उस चीज़ के लिए कभी नहीं जिसे आप पलट सकते हैं। 302 का मतलब अस्थायी है: मूल URL इंडेक्स में बना रहता है, जो मेंटेनेंस पेज, A/B टेस्ट और साइन-इन रीडायरेक्ट के लिए ठीक वही है जो चाहिए। जहाँ POST को रीडायरेक्ट के बाद भी बचना है वहाँ 307 या 308 लें, चेन को एक छलाँग तक रखें, और पक्का करें कि कोई नियम अपने ही शुरुआती बिंदु पर न लौटाए। कोई URL असल में क्या देता है, छलाँग दर छलाँग, मुफ़्त HTTP स्टेटस कोड चेकर से जाँचें, और नए होस्ट पर भेज रहे हों तो पहले उसका सर्टिफ़िकेट SSL सर्टिफ़िकेट चेकर से पक्का करें। हर जवाब श्रेणी का मतलब जानने के लिए HTTP स्टेटस कोड की पूरी गाइड बाकी हिस्सा कवर करती है।

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

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

मुझे 301 या 302 रीडायरेक्ट इस्तेमाल करना चाहिए?⌄

301 तब लें जब पुराना URL कभी वापस नहीं आएगा — बदला हुआ slug, नया डोमेन, HTTPS लागू करना, या www और एपेक्स में से एक चुनना। 302 तब लें जब मूल URL को ही कैनोनिकल बना रहना है, जैसे मेंटेनेंस पेज, A/B टेस्ट, या साइन-इन रीडायरेक्ट जो बाद में विज़िटर को वापस भेज देता है।

क्या 301 रीडायरेक्ट से SEO को नुकसान होता है?⌄

नहीं, जब उसे ठीक से इस्तेमाल किया जाए। Google अब रीडायरेक्ट पर क्षय गुणक लागू नहीं करता, इसलिए नज़दीकी से जुड़े पेज पर किया गया 301 पुराने URL के रैंकिंग संकेत आगे पहुँचाता है। नुकसान असंबंधित पेज पर मोड़ने से होता है, जिसे सॉफ़्ट 404 माना जाता है, और लंबी चेन से, जिनका पीछा क्रॉलर छोड़ देते हैं।

क्या 301 रीडायरेक्ट वापस लिया जा सकता है?⌄

सर्वर पर हाँ, लेकिन ब्राउज़र 301 को सख़्ती से कैश करते हैं और नियम हटाने के बहुत बाद तक लौटने वाले विज़िटर को मोड़ते रह सकते हैं, और उनका कैश आप साफ़ नहीं कर सकते। इसलिए 301 सिर्फ़ उस बदलाव के लिए इस्तेमाल करें जिसके बारे में आप निश्चित हैं; पलटने की कोई भी संभावना हो तो 302 लें।

302 और 307 में क्या अंतर है?⌄

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

कैसे जाँचें कि कोई URL 301 देता है या 302?⌄

पता बार से यह पता नहीं चलता, क्योंकि दोनों एक ही जगह पहुँचते हैं। पहले जवाब का स्टेटस कोड पढ़ें और हर छलाँग का पीछा करें। स्टेटस कोड चेकर हर चरण पर कोड और Location हेडर दिखाता है, जिससे चेन और स्थायी-अस्थायी कोड मिलाने वाली कोई भी छलाँग भी सामने आ जाती है।

लेखक के बारे में
संस्थापक और CEO, BuildToolForge
X पर फ़ॉलो करें: @Buildtoolforge

वेब डेवलपमेंट और सुरक्षा में 15+ वर्षों का व्यावहारिक अनुभव। व्यावहारिक वेब सुरक्षा पर ध्यान: वेबसाइटों को सुरक्षित, भरोसेमंद और समस्या-निवारण में आसान रखना। BuildToolForge इन जाँचों को मुफ़्त, निजी और समझने योग्य बनाने के लिए है। जहाँ संभव हो, टूल आपके ब्राउज़र में चलते हैं, और आप किसी टूल में जो कुछ भी दर्ज करते हैं वह संग्रहीत नहीं होता।

हम अपनी गाइड कैसे लिखते हैं: हर गाइड व्यावहारिक अनुभव से लिखी जाती है, आधिकारिक मानकों से जाँची जाती है और असली डोमेन पर हमारे अपने टूल से परखी जाती है। मानक या टूल बदलने पर हम गाइड अपडेट करते हैं। कोई गलती मिली? हमें contact@buildtoolforge.com पर ईमेल करें।

अंतिम अपडेट: 2 नवंबर 2026