Free Geo-Grid Audit — see exactly where you rank on Google Maps, block-by-block. Claim yours →

301 या 302 रीडायरेक्ट? 30 सेकंड में सही जवाब

इस गाइड का वो वर्शन चुनें जो आप पर फिट बैठे

आप बस स्क्रॉल भी कर सकते हैं। नीचे पूरी गाइड है। पिकर सिर्फ़ क्रम बदल देता है। हम आपकी पसंद ट्रैक नहीं करते।

🌍250+ व्यवसाय · 17 देश 4.9★ · 140+ सत्यापित समीक्षाएँ 🏆WASME 2023 विजेता · New Delhi

8 मिनट का पठन · अंतिम अपडेट 2 मई 2026

पढ़ने के बजाय सुनें
पढ़ने के बजाय सुनें
"90 सेकंड का जवाब"
0:00
0:00

Kunal Singh Dabi दो कार्ड दिखाते हुए। बाएँ हाथ में चमकता सुनहरा कार्ड जिस पर 301 लिखा है, दाएँ हाथ में लाल कार्ड जिस पर 302 लिखा है। हल्की समझदार मुस्कान। ब्रांड-रंग की नेवी पृष्ठभूमि, सुनहरी और लाल परिवेशीय चमक के साथ।

संक्षेप में

किसी पेज को हमेशा के लिए मूव कर रहे हैं? 301 का उपयोग करें। केवल अस्थायी रूप से? 302 का उपयोग करें। यही एक नियम आपके दस में से नौ रीडायरेक्ट निर्णयों को कवर कर लेता है। (दसवाँ, API एंडपॉइंट्स के लिए जहाँ रिक्वेस्ट टाइप मूव के बीच में नहीं बदल सकता, वहाँ 307 या 308 इस्तेमाल होता है। ज़्यादातर लोग इन्हें कभी नहीं छूते।)

जानना चाहते हैं कि आपकी साइट पर असल में क्या लाइव है? एक लाइन का चेक है जो बताता है कि आपका सर्वर कौन सा कोड भेज रहा है। अगर वह 302 कह रहा है और मूव स्थायी होना चाहिए था, तो आपकी रैंकिंग रियल-टाइम में फिसल रही है। हम नीचे आपको यह चेक करवाएँगे, बिना किसी कमांड-लाइन जानकारी के।

रिकवरी में 2 से 6 सप्ताह लगते हैं, एक बार जब आप गलत कोड ठीक कर देते हैं और Google से पेज को दोबारा क्रॉल करने को कहते हैं। उस इंतज़ार का ज़्यादातर हिस्सा सिर्फ़ Google के बॉट्स के अपने शेड्यूल पर लौटने का है।


रात के ग्यारह बज रहे हैं। आप माइग्रेशन के तीसरे हफ़्ते में हैं, और ऑर्गेनिक ट्रैफ़िक 40% नीचे है। डेव टीम कसम खाती है कि रीडायरेक्ट सही हैं। Search Console सामान्य लगता है। लेकिन आपके एनालिटिक्स चार्ट की लाइन गिरती ही जा रही है, और आप उसे बार-बार रिफ्रेश कर रहे हैं जैसे नंबर कुछ अलग कहानी बताने वाले हों।

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

फ़िक्स आमतौर पर कोड की एक पंक्ति होती है। असली मुश्किल समस्या को पहचानना होता है।

यह गाइड आपको पूरी प्रक्रिया से गुज़ारती है। सही रीडायरेक्ट चुनने का सरल नियम (सच में यह सिर्फ़ दो सवाल हैं)। आपकी साइट जो भी चलाती हो (WordPress, Shopify, Next.js, Apache, Nginx, सब कुछ) उसके लिए तैयार पेस्ट-करने-योग्य कोड। Google Search Console में बाद में वही एक चीज़ जाँचनी है जो साबित करेगी कि फ़िक्स काम कर गया। और अगर किसी और की गलती आपके सिर पड़ी है, तो अंत में चार-कदम की रिकवरी प्लेबुक का इंतज़ार है।

एक बात पहले। अपने SEO डैशबोर्ड पर रीडायरेक्ट के बारे में जो लिखा है, उस पर मत जाइए। डेवलपर जो कहता है, उस पर भी मत जाइए। अपनी आँखों से देखिए कि आपका सर्वर असल में क्या भेज रहा है। विश्वास मत करो। साबित करो। हम आपको आसान तरीका दिखाएँगे।

30 सेकंड का जवाब

पेज हमेशा के लिए हटा रहे हैं? 301 इस्तेमाल करें। थोड़ी देर के लिए हटा रहे हैं? 302 इस्तेमाल करें। बस एक और मामला जानने लायक है, API endpoints, जिनके लिए 307 (temporary) या 308 (permanent) चाहिए। जब तक आप APIs के साथ काम करने वाले डेवलपर नहीं हैं, आपको शायद ही कभी इनका सामना पड़े।

वह एक नियम 90% फैसले कवर कर देता है। यह चुनाव इतना मायने क्यों रखता है? क्योंकि redirect code एक साथ दो काम कर रहा है। यह search engines को बता रहा है कि यह बदलाव permanent है या temporary। और चुपके से browsers को बता रहा है कि request type (GET, POST, वगैरह) रास्ते में बिल्कुल वैसा ही रहना चाहिए या नहीं। हममें से ज़्यादातर को सिर्फ पहले काम के बारे में सोचना होता है।

अंदर से, हर redirect एक ही तरह काम करता है। कोई visitor पुराने URL की मांग करता है। आपका server एक छोटा सा message वापस भेजता है: यह पेज हट गया है, नया पता यह है। उस message पर लिखा नंबर (301, 302, 307, 308) ही search engines को बताता है कि इस बदलाव को कैसे handle करें।

एक पेच जानने लायक है। Google ने 2016 में चुपचाप बदला कि वह 302s को कैसे handle करता है। वे इन्हें proper signals की तरह treat करने में ज़्यादा lचीले हो गए, पर सिर्फ तब जब redirect काफी देर तक टिका रहे और नया पेज वास्तव में पुराने से मेल खाता हो। तो SEO नतीजा (किस URL की rankings बनती है, आपकी link equity कहाँ बहती है) सिर्फ इस बात पर निर्भर नहीं करता कि आपने कौन सा नंबर चुना। redirect कितने समय तक जीता है। content कितना मिलता-जुलता है। Google कितनी बार crawl करता है। ये सब काम करते हैं। हम एक मिनट में सबूतों पर आएंगे।

Status अर्थ Cacheable? Method-safe? Link equity कब इस्तेमाल करें
301 Moved Permanently हाँ (long TTL) नहीं (POST→GET की इजाज़त) पूरी destination पर स्थायी बदलाव
302 Found (मूलतः Moved Temporarily) नहीं (default) नहीं source URL के साथ रहती है अस्थायी substitutions
303 See Other नहीं GET पर मजबूर करता है source URL के साथ रहती है फॉर्म-submission के बाद
307 Temporary Redirect नहीं हाँ (सख्त) source URL के साथ रहती है अस्थायी, method-safe (API)
308 Permanent Redirect हाँ हाँ (सख्त) पूरी destination पर स्थायी, method-safe (API)
निर्णय वृक्ष। ऊपर का हीरा पूछता है 'क्या यह permanent move है?'। Yes 301 पर जाता है, नीचे 308 method-safe के रूप में लिखा है। No 302 पर जाता है, नीचे 307 method-safe के रूप में लिखा है।
निर्णय नियम, चित्र रूप में। Permanent बनाम temporary, फिर method-safe बनाम नहीं।

वह table ही छोटा जवाब है। बाकी गाइड यह खोलता है कि जब आप एक को दूसरे पर चुनते हैं तो असल में आपकी rankings, आपके crawl budget, और आपके indexed URLs के साथ क्या होता है। आप हर बड़े platform के लिए copy-paste करने लायक code देखेंगे, और सबूत, असली crawl data और Google के अपने documentation से निकाले हुए।

परिभाषाएँ: 301, 302, 307, 308, और Location हेडर

ये वो परिभाषाएँ हैं जिनसे आप इस गाइड के बाकी हिस्से में टकराएँगे। बुकमार्क करने लायक। आप वापस आएँगे।

301 Moved Permanently: एक रिस्पॉन्स स्टेटस कोड जो ब्राउज़र को बताता है कि रिसोर्स को Location हेडर में दिए गए URL पर स्थायी रूप से स्थानांतरित कर दिया गया है। सर्च इंजन रैंकिंग सिग्नल्स को नए URL पर पास कर देते हैं; ब्राउज़र इस रीडायरेक्ट को आक्रामक रूप से कैश करते हैं।

302 Found: एक रिस्पॉन्स स्टेटस कोड जो ब्राउज़र को बताता है कि रिसोर्स अस्थायी रूप से Location हेडर में दिए गए किसी अलग URL पर है। सर्च इंजन ओरिजिनल URL को इंडेक्स में रखते हैं; ब्राउज़र डिफ़ॉल्ट रूप से कैश नहीं करते।

307 Temporary Redirect: 302 जैसा ही, पर सख्त method preservation के साथ। क्लाइंट को उसी method के साथ रिक्वेस्ट दोहरानी होती है (POST, POST ही रहता है)। इसका इस्तेमाल तब करें जब कोई API contract verbs नहीं बदल सकता।

308 Permanent Redirect: 301 जैसा ही, पर सख्त method preservation के साथ। स्थायी और method-safe।

Location header: वह HTTP रिस्पॉन्स हेडर जो किसी भी 3xx रीडायरेक्ट का गंतव्य URL लेकर चलता है।

HTTP 3xx रीडायरेक्ट फ़ैमिली मैप। 300 Multiple Choices (ऊपर, सफ़ेद)। 301 Moved Permanently और 308 Permanent Redirect एक सुनहरी रेखा से जुड़े हैं, स्थायी जोड़ी के रूप में। 302 Found और 307 Temporary Redirect एक लाल रेखा से जुड़े हैं, अस्थायी जोड़ी के रूप में। 303 See Other सबसे बायीं ओर है, जो डैश्ड-लिंक से 302 से जुड़ा है।
3xx फ़ैमिली। स्थायी जोड़ी 301↔308 (सुनहरी)। अस्थायी जोड़ी 302↔307 (लाल)। 303 अलग बैठा है, post-form-submission रीडायरेक्ट्स के लिए।

इनका व्यावहारिक मतलब क्या है। 301 को ऐसा समझिए जैसे घर बदलना और हमेशा के लिए अपनी सारी डाक को नए पते पर फॉरवर्ड करवा देना। 302 ऐसा है जैसे छुट्टियों पर जाना और डाकघर से दो हफ़्तों के लिए डाक रीडायरेक्ट करवाना, फिर बंद। “method-safe” 307 और 308 ठीक-ठीक बताते हैं कि डाक को कैसे संभाला जाए। खोलना मत। मेरी तरफ़ से जवाब मत देना। यही वो नियम है जिसकी ज़रूरत applications को होती है ताकि जब आप उनके endpoints को रीडायरेक्ट करें तो वे काम करते रहें।

स्पेक वंशावली। 301 स्टेटस कोड की जड़ें HTTP/1.1 में हैं, और RFC 9110 — HTTP Semantics अब आधिकारिक संदर्भ है (§15.4.2)। 302 कोड की कहानी ज़्यादा उलझी हुई है। HTTP/1.0 (1996) ने इसे “Moved Temporarily” के रूप में परिभाषित किया था, पर ब्राउज़रों ने तुरंत रीडायरेक्ट पर POST रिक्वेस्ट को GET में बदलना शुरू कर दिया, यह व्यवहार जिसे स्पेक ने कभी मंज़ूरी नहीं दी। RFC 2616 (1999) ने 302 का नाम बदलकर “Found” कर दिया और मान लिया कि नुकसान पहले ही हो चुका था।

1999 का वह स्पेक बदलाव जिसने 302 को तोड़ा: RFC 2616 ने स्वीकार किया कि पूरे वेब में 302 को ग़लत तरीक़े से लागू किया गया था। अरबों क्लाइंट्स को ठीक करने की कोशिश करने के बजाय, स्पेक ने लोगों को साफ़-सुथरा रास्ता देने के लिए 303 और 307 पेश किए।

307 और 308 कोड ठीक इसलिए मौजूद हैं क्योंकि 302 का method बदलने वाला व्यवहार हमेशा के लिए जड़ जमा चुका था। जब आपका API contract verb बदलाव बर्दाश्त नहीं कर सकता (एक POST जिसे POST ही रहना चाहिए), तो 307 (अस्थायी) और 308 (स्थायी) method को लॉक कर देते हैं। ब्राउज़र-सामना करने वाले रीडायरेक्ट्स के लिए जहाँ गंतव्य वैसे भी GET की अपेक्षा करता है, वहाँ 301 और 302 अब भी मानक हैं।

<link rel=canonical> के संबंधित पर अलग mechanism के लिए canonical URL गाइड भी देखें। गहरे implementation विवरण के लिए, HTTP रीडायरेक्शन पर MDN Web Docs में ब्राउज़र-विशिष्ट व्यवहार के अच्छे नोट्स हैं।

301 बनाम 302 कब इस्तेमाल करें: निर्णय का नियम

बात एक सवाल पर आती है: यह बदलाव स्थायी है, या सिर्फ अस्थायी? नीचे दिए गए मामले बताते हैं कि आप किस तरफ हैं।

301 तब इस्तेमाल करें जब…

आप हमेशा के लिए नए डोमेन पर जा रहे हैं। जब oldbrand.com बन जाता है newbrand.com और वापसी का कोई रास्ता नहीं है, तब 301 का उपयोग करें। यह सर्च इंजन को बताता है: पुराने डोमेन के बारे में जो कुछ भी आप जानते हैं वह नए पर पास करें, और पुराने को अपने इंडेक्स से हटा दें।

आप HTTP से HTTPS पर जा रहे हैं। आपकी साइट का हर पेज असुरक्षित वर्जन (जिसमें ब्राउज़र में ताले का निशान नहीं होता) से सुरक्षित वर्जन पर जा रहा है। यह स्थायी है। 301 सुनिश्चित करता है कि अब से ब्राउज़र और सर्च इंजन HTTPS को आधिकारिक वर्जन मानें।

आप अपने URLs की संरचना बदल रहे हैं। जब पूरी साइट के पुनर्गठन के हिस्से के रूप में /blog/post-1 बन जाता है /posts/post-1, तब आप नहीं चाहते कि पुराना पथ कभी वापस आए। 301 सारी रैंक पावर नई संरचना को सौंप देता है।

आप पेजों को मर्ज या ट्रिम कर रहे हैं। जब आप दो छोटे पेजों को एक मजबूत पेज में जोड़ते हैं, तब पुराने URL को स्थायी रूप से रीडायरेक्ट करें। मर्ज किया गया पेज दोनों की रैंक पावर उठा लेता है।

आप हटाए गए पेज को उसकी पैरेंट कैटेगरी पर भेज रहे हैं। बंद हो चुके प्रोडक्ट के लिए “पेज नहीं मिला” दिखाने की बजाय, पैरेंट कैटेगरी पेज पर रीडायरेक्ट करें। यूज़र कहीं उपयोगी जगह पहुंचते हैं, और रैंक पावर गायब होने के बजाय किसी प्रासंगिक पेज की ओर बहती है।

आप स्लैश और बिना-स्लैश के बीच विजेता चुन रहे हैं। या तो /page चुनें या /page/, और दूसरे को स्थायी रूप से रीडायरेक्ट करें। सुसंगतता Google को इन्हें दो अलग पेज मानने से रोकती है।

आप www और non-www के बीच विजेता चुन रहे हैं। www.domain.com या domain.com में से एक को अपना मुख्य वर्जन चुनें। दूसरे को 301 के साथ रीडायरेक्ट करें ताकि सर्च इंजन अपने सारे संकेत एक ही पर जमा करें।

एक ईकॉमर्स माइग्रेशन (Shopify से WooCommerce, कस्टम स्टोरफ्रंट से Shopify Plus) ऐसा सबसे बड़ा 301-रीडायरेक्ट काम है जो कोई ब्रांड कभी करेगा। पूरी माइग्रेशन प्लेबुक, जिसमें वह रीडायरेक्ट मैप शामिल है जिसे आप कोई भी URL बदलाव लाइव होने से पहले बनाते हैं, Revenue Funnel SEO पद्धति के अंदर मौजूद है।

302 तब इस्तेमाल करें जब…

आप A/B टेस्ट चला रहे हैं। अगर आपका आधा ट्रैफ़िक किसी वेरिएंट पेज पर जा रहा है, तो प्रयोग के दौरान कोई भी वर्जन मुख्य URL के रूप में हावी नहीं होना चाहिए। 302 सर्च इंजन को बताता है: जब तक हम डेटा इकट्ठा कर रहे हैं, मूल URL ही प्रभारी है।

आप मेंटेनेंस विंडो में हैं। अगर आप निर्धारित डाउनटाइम के दौरान विज़िटर्स को स्टेटस पेज पर भेज रहे हैं, तो यह परिभाषा से अस्थायी है। 302 Google में मूल URL की स्थिति को बरकरार रखता है ताकि जब आप चीज़ें ठीक कर रहे हों, तब रैंकिंग न बदले।

आपने अभी तक कंट्री टैग सेट अप नहीं किए हैं। भारतीय विज़िटर्स को /in/ पर और अमेरिकी विज़िटर्स को /us/ पर भेज रहे हैं? अगर आपने अभी तक hreflang नहीं जोड़ा है, तो 302 इस्तेमाल करें। (Hreflang वह टैग है जो Google को बताता है कि किस देश में कौन सा वर्जन दिखाना है।) यह Google को गलत क्षेत्रीय वर्जन को मुख्य URL के रूप में चुनने से रोकता है।

आप एक प्रोमो पेज चला रहे हैं जो गायब हो जाएगा। Black Friday का पेज जो 1 दिसंबर के बाद गायब हो जाता है, उसे आपके मुख्य पेज की रैंकिंग पावर नहीं सोखनी चाहिए। 302 मूल URL को मुख्य बनाए रखता है, और प्रोमो पेज सिर्फ कैंपेन के लिए मौजूद रहता है।

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

एज केस जिन्हें नियम पूरी तरह से तय नहीं करते

शॉपिंग कार्ट चेकआउट के बाद के रीडायरेक्ट को तकनीकी रूप से 303 इस्तेमाल करना चाहिए (यह ब्राउज़र को बताता है: फ़ॉर्म डेटा भूल जाओ, बस यह पेज फ़ेच करो)। ज़्यादातर प्लेटफ़ॉर्म इसकी जगह 302 भेजते हैं, और ब्राउज़र इसे एक ही तरह से ट्रीट करते हैं। API मूव जहां क्लाइंट POST डेटा भेजते हैं, वहां वास्तव में रिक्वेस्ट टाइप लॉक करने के लिए 308 का उपयोग होना चाहिए। ज़्यादातर टीमें इसकी जगह 301 उठा लेती हैं। यह एक दशक से काम कर रहा है और अब तक कुछ नहीं टूटा। लॉगिन रीडायरेक्ट आमतौर पर 302 इस्तेमाल करते हैं। विज़िटर लॉगिन पेज पर उछलता है, फिर साइन इन करने के बाद वापस आ जाता है।

चुनाव के बाद आपके SEO का क्या होता है (2026 की हकीकत)

सही कोड चुनना सिर्फ एक तकनीकी खानापूर्ति नहीं है। यह चुपचाप एक साथ तीन चीजें तय करता है। क्या Google आपके नए URL तक रैंक-पावर पहुंचाएगा। क्या आपका नया URL सर्च रिजल्ट में पुराने की जगह ले लेगा। और क्या ChatGPT जैसे AI सर्च इंजन आपको बिलकुल साइट करेंगे भी या नहीं। हर एक चीज अगली को प्रभावित करती है, और बाद में नुकसान ठीक करने में पहली बार सही करने से ज्यादा मेहनत लगती है।

लिंक-इक्विटी ट्रांसफर

लिंक इक्विटी आपके URLs की SEO “प्रतिष्ठा” है जो समय के साथ बनती है। दूसरी साइट्स का आपको लिंक करना, आपका पब्लिश किया कंटेंट, असली यूजर्स का पेज पर व्यवहार। ये सब मिलकर एक स्कोर बनाते हैं जो URL को रैंक करने में मदद करता है।

जब आप 301 (स्थायी) से रीडायरेक्ट करते हैं, Google प्रतिष्ठा को नए URL पर शिफ्ट कर देता है। नया URL रैंक-पावर विरासत में पा लेता है।

जब आप 302 (अस्थायी) से रीडायरेक्ट करते हैं, Google प्रतिष्ठा पुराने URL पर ही रखता है। नए URL को एक साइड एड्रेस की तरह माना जाता है जो कभी अपनी ऑथोरिटी नहीं बना पाता। तो अगर आप गलती से स्थायी बदलाव के लिए 302 लगा देते हैं, तो Google की नजर में आपके पास दो URLs हो जाते हैं। कोई भी अकेले रैंक करने लायक मजबूत नहीं। आपकी रैंक-पावर हमेशा के लिए बंट जाती है, जब तक आप कोड ठीक नहीं करते।

यह तकनीकी SEO की सबसे महंगी अकेली गलती है।

सालों तक SEOs मानते रहे कि 302 लिंक इक्विटी खत्म कर देते हैं। वे अस्थायी रीडायरेक्ट को इक्विटी ब्लैक होल की तरह मानते थे। PageRank सोर्स URL पर रुक जाता और डेस्टिनेशन तक कभी नहीं पहुंचता।

Google के John Mueller ने 2016 में यह बात साफ कर दी थी, और Search Central Office Hours में कई बार दोहराई है। 301 और 302 दोनों रीडायरेक्ट लिंक इक्विटी पास करते हैं। URL रीडायरेक्ट पर Google Search Central का डॉक्युमेंटेशन इसकी पुष्टि करता है। Mueller का बार-बार दोहराया गया वाक्य: “It’s been like this for years now.”

इक्विटी दोनों तरह से पास होती है। बदलता सिर्फ यह है कि वह कहां जाकर टिकती है।

एक 302 पुराने URL को ही कैनोनिकल रखता है। Google पुराने URL को ही बॉस मानता रहता है, इसलिए नया URL कभी अपने रैंकिंग सिग्नल नहीं बना पाता। भले ही तकनीकी रूप से इक्विटी रीडायरेक्ट के जरिए बह रही हो। व्यवहारिक नतीजा: 301 के साथ, नया URL पेज-लेवल मेट्रिक्स विरासत में पाता है और रैंकिंग एंटिटी बन जाता है। 302 के साथ, इक्विटी दो URLs में बंट जाती है जिसमें कोई स्पष्ट विजेता नहीं। कोई भी वह केंद्रित ऑथोरिटी नहीं बना पाता जो कठिन क्वेरीज के लिए प्रतिस्पर्धा में जरूरी है।

लिंक इक्विटी रीडायरेक्ट लिटरेसी और ऑफ-पेज SEO के बीच का टॉपिकल जोड़ है। The Earned Authority Method वह फ्रेमवर्क है जो इसे पहली जगह पर बनाता है। और यही वजह है कि सही 301 के जरिए इसे बचाना ज्यादातर ऑपरेटर्स की समझ से कहीं ज्यादा मायने रखता है।

यह बंटवारा माइग्रेशन के दौरान सबसे ज्यादा मायने रखता है। एक साइट जो HTTP से HTTPS पर 302s के साथ जाती है, इक्विटी नहीं खोती। वह बस उसे प्रोटोकॉल वेरिएंट्स में हमेशा के लिए बिखेर देती है।

Google का इंडेक्स हर एक के साथ क्या करता है

Googlebot, Google का क्रॉलर है। यह अपने इंडेक्स में पेज स्टोर करते समय 301s और 302s के साथ बहुत अलग व्यवहार करता है। (इंडेक्स हर उस पेज का विशाल डेटाबेस है जिसे Google जानता है।)

एक 301 Google को बताता है: पुराने URL को नए से बदल दो। अगले कुछ विज़िट्स में Google ठीक यही करता है। आमतौर पर एक सामान्य साइट के लिए 2 से 6 हफ्तों में, बड़ी साइट्स के लिए जल्दी जिन्हें Google ज्यादा बार चेक करता है। नया URL वही बनता है जो Google सर्च रिजल्ट्स में दिखाता है। पुराना चुपचाप बाहर हो जाता है।

एक 302 Google को बताता है: पुराना URL रखो। Google सर्च रिजल्ट्स में पुराने URL को मुख्य URL के रूप में दिखाता रहता है। नया URL विज़िट हो सकता है, लेकिन कभी उसकी जगह नहीं लेता। Google रीडायरेक्ट को एक शॉर्ट-टर्म डिटूर समझता है, पते के स्थायी बदलाव के रूप में नहीं।

Google Search Console (साइट मालिकों के लिए Google का फ्री टूल) में URL Inspection नाम का एक फीचर है जो यह खुद देखना आसान बनाता है। 301 वाला URL आखिरकार “URL is not on Google” दिखाता है, कारण “Page with redirect” के साथ, और नया URL इंडेक्स्ड दिखता है। 302 वाला URL ओरिजिनल को ही मुख्य URL के रूप में पकड़े रहता है, “Page with redirect” टैग के साथ। और नया URL वहीं पड़ा रहता है, कभी नहीं उठाया जाता।

माइग्रेशन के लिए, इसका मतलब है कि 302s दो URLs के बीच स्थायी बंटवारा बना देते हैं, जब तक आप वापस जाकर कोड ठीक न करें।

AI सर्च और रीडायरेक्ट: 2025 ChatGPT डेटा

SE Ranking की दिसंबर 2025 की एक स्टडी में कुछ चौंकाने वाली बात निकली। AI सर्च इंजन (ChatGPT, Perplexity, Google के AI Overviews) रीडायरेक्ट किए गए URLs को नियमित Google के मुकाबले कहीं कम बार साइट करते हैं।

आंकड़े कहानी बताते हैं। ChatGPT के केवल 0.79% साइटेशन रीडायरेक्ट से गुजरने वाले URLs की तरफ इशारा करते हैं, नियमित Google रिजल्ट्स में 5.75% के मुकाबले। इसका मतलब है ChatGPT रीडायरेक्ट किए गए URLs को Google के मुकाबले 3 से 7 गुना कम साइट करता है।

यहां चौंकाने वाली बात है। जब ChatGPT रीडायरेक्ट फॉलो करता ही है, तो वह बहुत ज्यादा स्थायी वाले को पसंद करता है। उसी स्टडी में पाया गया कि ChatGPT 301s को 302s के मुकाबले 1.6 गुना ज्यादा बार फॉलो करता है। Perplexity और Bing के AI फीचर्स वही पैटर्न दिखाते हैं। AI सर्च सिस्टम्स स्थायी रीडायरेक्ट को अस्थायी के मुकाबले ज्यादा भरोसेमंद मानते हैं।

आपके माइग्रेशन के लिए इसका मतलब: आपके रीडायरेक्ट्स में कहीं भी छिपा हुआ 302 चुपचाप AI सर्च द्वारा साइट किए जाने की आपकी संभावनाएं कम कर देता है। आप एक साथ दो मोर्चों पर हारते हैं। Google की नियमित सर्च आपके URLs को बिखरा हुआ मानती है, और AI सर्च इंजन्स की नई लहर अपने जवाबों में आपका जिक्र करना बंद कर देती है।

अगर आपका गलत कोड ChatGPT को आपका कंटेंट साइट करने से रोक देता है, तो आपके पेड सर्च को कमी पूरी करनी पड़ती है। The Pincer Method ठीक यही वजह है कि हम पेड और ऑर्गेनिक को एक ही प्लेबुक से चलाते हैं। जब AI सर्च एक चैनल छोड़ती है, तो दूसरे को मांग पकड़नी पड़ती है।

7 प्लेटफ़ॉर्म्स के लिए कॉपी-पेस्ट कोड

Google पर “301 vs 302 redirect” सर्च करें तो टॉप रिज़ल्ट्स सात प्लेटफ़ॉर्म्स का नाम तो लेते हैं, लेकिन असली कोड कभी नहीं दिखाते जिसे आप इस्तेमाल कर सकें। तो लीजिए, यहाँ वो है। नीचे दिया हर स्निपेट कॉपी-पेस्ट के लिए तैयार है, मौजूदा प्लेटफ़ॉर्म डॉक्यूमेंटेशन से जाँचा गया है, और सबसे आम गलतियों पर टेस्ट किया गया है।

Apache (.htaccess)

Apache पर यह आपके डॉक्यूमेंट रूट में मौजूद .htaccess फ़ाइल में जाता है।

Show Apache .htaccess code
# Single URL 301
Redirect 301 /old-url /new-url

# Pattern-based 301 (regex)
RedirectMatch 301 ^/old/(.*)$ /new/$1

# Domain change with HTTPS
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldbrand\.com$ [NC]
RewriteRule ^(.*)$ https://newbrand.com/$1 [R=301,L]

गोटचा: RewriteRule इस्तेमाल करने से पहले RewriteEngine On लिखना भूल जाना। यह डायरेक्टिव बिना इसके चुपचाप फ़ेल हो जाता है, और आप बीस मिनट तक यह सोचते रहेंगे कि कुछ काम क्यों नहीं कर रहा। इस तुलना को हमने htaccess vs Nginx for redirect rules में विस्तार से कवर किया है।

Nginx

Nginx पर यह आपके सर्वर ब्लॉक कॉन्फ़िगरेशन फ़ाइल में जाता है (आमतौर पर /etc/nginx/sites-available/yourdomain)।

Show Nginx config code
# Single URL 301
location = /old-url {
    return 301 /new-url;
}

# Domain change
server {
    listen 443 ssl;
    server_name oldbrand.com;
    return 301 https://newbrand.com$request_uri;
}

गोटचा: जहाँ return तेज़ होगा वहाँ rewrite का इस्तेमाल करना। return 301 regex इवैल्यूएशन से पहले चलता है और सर्वर का काम बचाता है। पूरा ब्रेकडाउन htaccess vs Nginx for redirect rules में है।

Cloudflare Workers + Page Rules

Page Rules (UI, कोई कोड नहीं): Cloudflare dashboard → Rules → Page Rules → “Forwarding URL” → ड्रॉपडाउन से 301 या 302 चुनें। Free plans में सिर्फ़ 3 एक्टिव Page Rules मिलते हैं, जो कई रीडायरेक्ट ज़रूरतों वाली साइट्स पर जल्दी भर जाते हैं।

Workers (कोड, ज़्यादा लचीले):

Show Cloudflare Workers code
export default {
  fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === '/old-url') {
      return Response.redirect('https://example.com/new-url', 301);
    }
    return fetch(request);
  }
}

गोटचा: Workers की कीमत $5/month है 10M रिक्वेस्ट्स के लिए, लेकिन यह पैटर्न-मैचिंग की ताक़त देते हैं जो Page Rules कभी मैच नहीं कर सकते। एडवांस्ड यूज़ केसेस हम Cloudflare Workers redirect patterns में कवर करेंगे।

WordPress: RankMath PRO + Redirection plugin + manual .htaccess

RankMath PRO: WordPress Admin → Rank Math → Redirections → Add New। ड्रॉपडाउन से 301 या 302 चुनें, सोर्स और डेस्टिनेशन URLs डालें। बदलाव तुरंत लाइव हो जाते हैं, कोई सर्वर रीस्टार्ट नहीं।

Redirection plugin (free, John Godley): Tools → Redirection। हाई-वॉल्यूम माइग्रेशन्स के लिए सबसे अच्छा। CSV import/export, regex patterns, और 404 tracking सपोर्ट करता है। प्लगइन redirect hits लॉग करता है, जिससे आप chains या loops को बिगड़ने से पहले पकड़ सकते हैं।

Manual .htaccess: काम करता है, लेकिन उन प्लगइन या थीम अपडेट्स के बाद नहीं बचता जो .htaccess को छूते हैं। इसे सिर्फ़ स्थायी सिस्टम-स्तर के नियमों के लिए इस्तेमाल करें जिन्हें WordPress state से बेपरवाह रहना है।

अगर आप WordPress-native हैं और हर redirect बदलाव को बड़े कंटेंट इंजन का हिस्सा मान रहे हैं, तो redirect स्टेप व्यापक मेथडोलॉजी के अंदर बस एक चाल है। The Content Compounder methodology ही वह इंजन चलाती है। छह-स्तंभों वाला फ़ीडबैक लूप जो redirect literacy को Pillar 2 की प्लंबिंग के रूप में खाता है। प्लगइन-विशिष्ट तुलनाओं के लिए, WordPress redirect plugin guide सेलेक्शन क्राइटेरिया में गहराई से जाती है।

WooCommerce + Shopify

WooCommerce: ऊपर दिए गए WordPress redirect tools का इस्तेमाल करता है। हालाँकि, बल्क प्रोडक्ट-URL माइग्रेशन के लिए deduplication logic ज़रूरी है। एक 500-SKU स्टोर 500 redirect rules जनरेट कर सकता है जो .htaccess parsing को धीमा कर देते हैं। deduplication वर्कफ़्लो हम नीचे common-mistakes सेक्शन में कवर करते हैं।

Shopify: Online Store → Navigation → URL Redirects। Shopify स्टैंडर्ड admin से सिर्फ़ 301 सपोर्ट करता है। आप बिना कस्टम Shopify Function या Easy Redirects जैसी third-party app के 302 कॉन्फ़िगर नहीं कर सकते।

गोटचा: Shopify URL Redirects theme बदलावों के बाद बचते हैं, लेकिन जैसे ही आप सोर्स प्रोडक्ट या पेज डिलीट करते हैं, टूट जाते हैं। किसी भी स्ट्रक्चरल बदलाव से पहले हमेशा अपनी redirect लिस्ट एक्सपोर्ट करें। Settings → Files आपको यहाँ नहीं बचाएगा।

Next.js (next.config.js)

Next.js पर यह प्रोजेक्ट रूट में आपकी next.config.js फ़ाइल में जाता है।

Show Next.js redirects config
// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-url',
        destination: '/new-url',
        permanent: true, // permanent: true = 308; permanent: false = 307
      },
    ];
  },
};

गोटचा: Next.js डिफ़ॉल्ट रूप से 307/308 (strict-method वेरिएंट्स) का इस्तेमाल करता है, 301/302 का नहीं। अगर आपको खासतौर पर 301/302 चाहिए क्योंकि कोई legacy SEO tool 308 को अभी तक नहीं पहचानता, तो permanent: true की जगह statusCode: 301 सेट करें।

Express middleware

Express पर यह आपकी मुख्य server फ़ाइल में जाता है (आमतौर पर app.js या server.js)।

Show Express middleware code
// Express
app.get('/old-url', (req, res) => {
  res.redirect(301, '/new-url');
});

// Pattern-based redirect
app.use('/old-section/*', (req, res) => {
  const newPath = req.originalUrl.replace('/old-section', '/new-section');
  res.redirect(301, newPath);
});

गोटचा: अगर आप status code पास नहीं करते तो res.redirect() डिफ़ॉल्ट रूप से 302 हो जाता है। हमेशा स्पष्ट रहें। Implicit 302s “मैंने redirects सेट किए पर मेरी रैंकिंग्स गिर गईं” जैसे सपोर्ट टिकट्स की सबसे बड़ी वजह हैं जो हम देखते हैं।

Vercel (vercel.json or next.config.js)

Vercel पर redirects प्रोजेक्ट रूट में vercel.json में रहते हैं, या अगर आप Next.js इस्तेमाल कर रहे हैं तो next.config.js के अंदर (ऊपर कवर किया गया)।

Show Vercel vercel.json code
{
  "redirects": [
    {
      "source": "/old-url",
      "destination": "/new-url",
      "permanent": true
    },
    {
      "source": "/old/:path*",
      "destination": "/new/:path*",
      "permanent": true
    }
  ]
}

गोटचा: Next.js जैसा ही। permanent: true का मतलब 308, permanent: false का मतलब 307। अगर आपको खासतौर पर 301/302 status codes चाहिए, तो "permanent" की जगह "statusCode": 301 इस्तेमाल करें।

Netlify (_redirects file)

Netlify पर redirects आपकी publish directory (या public/) में _redirects फ़ाइल में जाते हैं।

Show Netlify _redirects code
# Single URL 301
/old-url    /new-url    301

# Wildcard
/old/*    /new/:splat    301

# Domain change (full URL on the right)
https://oldbrand.com/*    https://newbrand.com/:splat    301!

गोटचा: ट्रेलिंग ! (force flag) redirect को destination पर मौजूद फ़ाइलों को ओवरराइड करने देता है। इसके बिना, Netlify सिर्फ़ तभी redirect करता है जब source किसी असली फ़ाइल से मैच न हो। उपयोगी है, पर भूलना आसान है।

AWS CloudFront (Functions or Lambda@Edge)

CloudFront पर redirects CloudFront Function (सस्ता, सरल) या Lambda@Edge (ज़्यादा ताक़तवर, ज़्यादा महँगा) के रूप में चल सकते हैं। ज़्यादातर redirect काम के लिए Functions सही चुनाव है।

Show CloudFront Function code
function handler(event) {
  var request = event.request;
  if (request.uri === '/old-url') {
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: {
        location: { value: 'https://example.com/new-url' }
      }
    };
  }
  return request;
}

फ़ंक्शन को viewer-request event type के साथ CloudFront distribution behaviour से attach करें। CloudFront Functions 10ms execution तक सीमित हैं और इनका network access नहीं है, लेकिन हर महीने पहले 10M invocations के लिए ये मुफ़्त हैं।

Caddy

Caddy पर redirects आपकी Caddyfile में जाते हैं और बेहद आसान हैं।

Show Caddyfile code
# Single URL 301
oldbrand.com {
    redir /old-url /new-url permanent
}

# Domain change with HTTPS preserved
oldbrand.com {
    redir https://newbrand.com{uri} 301
}

गोटचा: Caddy में permanent का मतलब 301 है। 302 के लिए temporary इस्तेमाल करें। Caddy Let’s Encrypt के ज़रिए HTTPS अपने आप संभालता है, इसलिए domain redirects आमतौर पर एक-लाइन का मामला हैं।

IIS (Windows Server, web.config)

IIS पर redirects आपकी साइट की web.config फ़ाइल में <system.webServer> सेक्शन के तहत रहते हैं। URL Rewrite module की ज़रूरत होती है (Microsoft से मुफ़्त डाउनलोड)।

Show IIS web.config code
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Old URL 301" stopProcessing="true">
          <match url="^old-url$" />
          <action type="Redirect" url="/new-url" redirectType="Permanent" />
        </rule>
        <rule name="Domain change" stopProcessing="true">
          <match url=".*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^oldbrand\.com$" />
          </conditions>
          <action type="Redirect" url="https://newbrand.com/{R:0}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

गोटचा: IIS में redirectType="Permanent" का मतलब 301 है। 302 के लिए Found, 303 के लिए SeeOther, 307 के लिए Temporary इस्तेमाल करें। नामकरण स्पष्ट नहीं है। कई डेवलपर्स मान लेते हैं कि Temporary 302 है और ग़लत कोड शिप कर देते हैं।


माइग्रेशन के बीच हैं और दूसरी नज़र चाहिए? हमें अपना sitemap और अपनी .htaccess भेजिए। हम कॉल पर 30-मिनट का मुफ़्त ऑडिट करेंगे। आपकी स्क्रीन, हमारी आवाज़, असली curl आउटपुट। कोई डेक नहीं। कोई प्रपोज़ल नहीं। जब आप चाहें कि हम काम अपने हाथ में लें, तो रीटेनर्स ₹40,000 / $499 महीने से शुरू।

Book a 30-min strategy call → · WhatsApp +91 96366 50036


कैसे सत्यापित करें: विश्वास मत करो। साबित करो।

रीडायरेक्ट असल में क्या कर रहा है, यह जाँचने के तीन तरीके हैं। पहले के लिए किसी विशेष टूल की ज़रूरत नहीं। दूसरा Chrome में पहले से मौजूद एक मुफ्त फीचर का उपयोग करता है। तीसरा Google के अपने मुफ्त डैशबोर्ड का उपयोग करता है। जो आपको सबसे आरामदायक लगे, वह चुनें। वे सभी आपको सच बताते हैं।

curl -I, एक-लाइन चेक (डेवलपर्स के लिए)

अगर आप डेवलपर नहीं हैं, तो नीचे दिए गए Browser DevTools या Google Search Console तरीके पर जाएँ। वे आपको कमांड लाइन के बिना वही जानकारी दिखाते हैं।

किसी भी कंप्यूटर पर टर्मिनल (काले-सफेद टेक्स्ट वाली विंडो जो डेवलपर्स इस्तेमाल करते हैं) खोलकर चलाएँ:

curl -I https://example.com/old-url

नमूना आउटपुट:

HTTP/2 301
date: Tue, 1 May 2026 09:00:00 GMT
location: https://example.com/new-url
cache-control: max-age=31536000
स्टाइलाइज़्ड टर्मिनल विंडो जिसमें curl -I कमांड और उसका आउटपुट दिखाया गया है। <abbr class=HTTP/2 301 लाइन सुनहरे रंग में चमक रही है, location हेडर नए URL की ओर इशारा कर रहा है, cache-control max-age वैल्यू हाइलाइट है। ब्रांड पैलेट नेवी और गोल्ड।" loading="lazy" width="1600" height="900">
यह स्क्रीनशॉट आप अपने क्लाइंट को भेजते हैं। रिस्पॉन्स पढ़ें। डैशबोर्ड पर भरोसा मत करें।

पहली लाइन आपको स्टेटस बताती है। यहाँ 301। location: हेडर आपको बताता है कि रीडायरेक्ट कहाँ इशारा कर रहा है: आपका नया URL, बिल्कुल वैसा ही जैसा आपने निर्दिष्ट किया था। cache-control: max-age=31536000 (सेकंड में एक साल) आपको बताता है कि रीडायरेक्ट को आक्रामक ढंग से कैश किया जा रहा है, जो एक स्थायी रीडायरेक्ट के अनुरूप है। ब्राउज़र और CDN इस निर्देश का सम्मान करेंगे और दोबारा विज़िट पर लुकअप छोड़ देंगे।

एक पेच: कुछ सर्वर HTTP/2 के बजाय HTTP/1.1 लौटाते हैं। स्टेटस लाइन संक्षिप्त HTTP/2 301 के बजाय HTTP/1.1 301 Moved Permanently पढ़ती है। व्यवहार एक जैसा है। वर्ज़न नंबर केवल यह दर्शाता है कि आपका सर्वर क्या सपोर्ट करता है, न कि रीडायरेक्ट वैध है या नहीं।

Browser DevTools Network टैब

Chrome DevTools → Network टैब खोलें → “Preserve log” पर टिक करें → एड्रेस बार में सीधे पुराना URL लोड करें।

पहला रिक्वेस्ट Status कॉलम में 301 या 302 स्टेटस दिखाता है। उस पंक्ति पर क्लिक करके दाएँ पैनल में Location हेडर और पूरे रिस्पॉन्स हेडर का निरीक्षण करें।

रीडायरेक्ट चेन को देखकर पहचानने के लिए यह तरीका बढ़िया है। हर हॉप एक अलग पंक्ति के रूप में दिखाई देता है। अगर आपको अंतिम 200 से पहले तीन पंक्तियाँ दिखती हैं, तो समेटने लायक एक चेन है।

GSC URL Inspection, डिप्लॉय के बाद का चेक

Google Search Console → URL Inspection → पुराना URL पेस्ट करें।

एक सफल 301 के लिए, आपको “URL is not on Google” दिखेगा और कारण “Page with redirect” होगा। यह पुष्टि करता है कि Google ने रीडायरेक्ट को क्रॉल किया, रजिस्टर किया, और गंतव्य तक अथॉरिटी पास करना शुरू कर दिया है।

दो से छह सप्ताह बाद, नया URL पेस्ट करें। आप यह देखना चाहते हैं: “URL is on Google” के साथ “Page is indexed” और “User-declared canonical”। यह पुष्टि करता है कि समेकन पूरा हो गया है। नया URL अब उस अथॉरिटी को धारण कर रहा है जो पुराने URL ने बनाई थी।

URL Inspection फीचर के पूर्ण संदर्भ के लिए, देखें Google का URL Inspection डॉक्यूमेंटेशन

यह वह स्क्रीनशॉट है जो आप अपने क्लाइंट को यह साबित करने के लिए भेजते हैं कि माइग्रेशन काम कर गया। Semrush एक्सपोर्ट नहीं। किसी पेड टूल की रिपोर्ट नहीं। Google का अपना कंसोल कह रहा है कि URL Google पर है। डैशबोर्ड पर विश्वास मत करो। रिस्पॉन्स पढ़ो।

अगर आपने पहले से गलत कोड इस्तेमाल कर लिया है: रिकवरी प्लेबुक

रिकवरी चार छोटे कदमों में होती है। टूटे हुए URL ढूंढें। कोड ठीक करें। Google से वापस आने को कहें। इंतज़ार करें। ज़्यादातर समय तो बस इंतज़ार में ही जाता है। असली फिक्स तेज़ है। पूरा काम आमतौर पर 2 से 6 हफ्ते लेता है, और किसी भी एक कदम में जल्दबाज़ी करने से इंतज़ार और लंबा हो जाता है।

असल ज़िंदगी में ये कैसा दिखता है। पिछले क्वार्टर हमने एक स्किनकेयर ब्रांड की मदद की जिसने अपनी दुकान Shopify से WooCommerce पर शिफ्ट की थी। उनके डेवलपर्स ने हर URL पर 302 इस्तेमाल कर दिए थे क्योंकि माइग्रेशन प्लगइन डिफॉल्ट में “temporary” पर सेट था और किसी को चेतावनी नहीं दी। हफ्ते 4 तक ऑर्गेनिक ट्रैफिक 38% गिर चुका था। हमने 60 प्रोडक्ट पेज चेक किए, पुष्टि की कि हर रीडायरेक्ट गलत टाइप का था, और सब को 301 में बदल दिया। फिर हमने उनका साइटमैप दोबारा सबमिट किया और Google से 12 सबसे ज़्यादा रेवेन्यू वाले पेज फिर से क्रॉल करने को कहा। अठारह दिन बाद, नए URL मुख्य वर्ज़न के रूप में दिखने लगे, और ट्रैफिक माइग्रेशन-पूर्व बेसलाइन के 4% के भीतर वापस आ गया।

लक्षण

रैंकिंग आपके माइग्रेशन के 2 से 6 हफ्ते बाद गिरी, और टाइमिंग इतनी सटीक मेल खाती है कि संयोग नहीं हो सकता। Google Search Console उन URL के लिए “Page with redirect” फ्लैग कर रहा है जो अब तक नए मुख्य वर्ज़न बन चुके होने चाहिए थे। Google अभी भी पुराने URL को ही प्राइमरी मान रहा है। AI सर्च इसे और बिगाड़ता है: ChatGPT, Claude, और Gemini लोगों को पुराने URL पर ही भेजते रहते हैं क्योंकि उनके ट्रेनिंग डेटा ने temporary redirect वाला सिग्नल पकड़ लिया था। आपके नए URL Google में कम या ना के बराबर मौजूदगी के साथ दिखते हैं, भले ही Google ने आपका साइटमैप बिना किसी शिकायत के स्वीकार कर लिया था। पुराने URL पर डायरेक्ट ट्रैफिक अप्रत्याशित रूप से उछलता है क्योंकि ब्राउज़र और बुकमार्क पुराना पता याद रखते हैं, विज़िटर्स को redirect loops या पुराने पेजों पर भेज देते हैं।

जांच करें

अपने 20 से 50 पुराने URL चुनें और देखें कि सर्वर असल में क्या भेज रहा है। (अगर आप डेवलपर हैं, तो curl -I इस्तेमाल करें। वरना, Chrome में URL खोलें और DevTools के Network टैब को चालू करें।) असली status code लिखें, वो नहीं जो आपका CMS कहता है कि वो भेज रहा है। फिर उन्हीं URL को Google Search Console के URL Inspection टूल में डालें। जहां मेल नहीं खाता, वहीं लीक है। जड़ तक पहुंचने के लिए अपनी प्लेटफॉर्म सेटिंग्स या सर्वर कॉन्फ़िग देखें। तीन आम गुनहगार: डिफॉल्ट से “temporary” पर सेट रीडायरेक्ट प्लगइन, बिना स्पष्ट status code वाली Express कॉल, या permanent: false के साथ Next.js redirect। किसी भी चेन को अलग से नोट करें। A→B→C→D जैसी चेन गलत-कोड वाली समस्या के ऊपर एक और समस्या जोड़ देती है।

ठीक करें

हर ज़रूरी सेटिंग को 301 में बदलें (या अगर आपको किसी API के लिए रिक्वेस्ट टाइप लॉक करना है तो 308) और बदलाव लाइव कर दें। जिस तरह से आपने समस्या ढूंढी थी, उसी तरह हर फिक्स को दोबारा चेक करें और पुष्टि करें कि 301 दिख रहा है। अपना साइटमैप Google Search Console में दोबारा सबमिट करें ताकि Google को पता चले कि कुछ बदला है। GSC के URL Inspection टूल का इस्तेमाल करें और अपने सबसे ज़रूरी डेस्टिनेशन URL पर “Request Indexing” पर क्लिक करें। उन पेजों को प्राथमिकता दें जो रेवेन्यू या बैकलिंक ला रहे हैं। बहुत ज़्यादा ट्रैफिक वाले रीडायरेक्ट के लिए, आप अस्थायी रूप से अपने होम पेज से नए URL पर लिंक करके Google को तेज़ कर सकते हैं। वो इंटरनल लिंक Google को जल्दी वापस आकर चेक करने के लिए नज्ज करता है।

दोबारा इंडेक्स करें

नए URL के मुख्य वर्ज़न बनने का सामान्य इंतज़ार 2 से 6 हफ्ते है। बड़ी साइट्स पर तेज़ जिन्हें Google बार-बार विज़िट करता है। AI सर्च रिकवरी अलग-अलग होती है। ChatGPT और Gemini सही URL का हवाला तब देने लगते हैं जब उनके ट्रेनिंग साइकिल रिफ्रेश होते हैं। Perplexity और Bing का चैट आमतौर पर नए URL के स्थिर होने के 1 से 2 हफ्ते में पकड़ लेते हैं। 301 redirect को Google को प्रोसेस करने में कितना समय लगता है, इस पर विस्तृत बेंचमार्क के लिए, हम भविष्य की पोस्ट में विस्तृत क्रॉल-टाइमिंग डेटा प्रकाशित करेंगे।


विरासत में रीडायरेक्ट का घालमेल मिला है और पता नहीं कहां से लीक हो रहा है? अपना साइटमैप एक मुफ्त 5-मिनट ऑडिट में पेस्ट करें और हम आपको आपके रीडायरेक्ट ग्राफ में हर 301, 302, और चेन की लिस्ट वापस भेजेंगे, साथ ही वो भी जो अभी आपकी इंडेक्सेशन खो रहे हैं। ज़्यादातर क्लाइंट अस्पष्टीकृत ट्रैफिक गिरावट के हफ्ते 3 में हमें कॉल करते हैं। 2 हफ्ते बचाएं।

WhatsApp पर अपना साइटमैप भेजें →


7 गलतियां जो चुपचाप रैंकिंग छीन लेती हैं

ये वो सात गलतियां हैं जो हमें लगभग हर ऑडिट में दिखती हैं। हर एक के साथ उसे पहचानने का एक तरीका और ठीक करने का एक तरीका है।

असल ज़िंदगी में ये कैसा दिखता है। पिछले साल हमने एक सॉफ्टवेयर कंपनी का ऑडिट किया जो अपने पहले बड़े इन्वेस्टमेंट राउंड की तैयारी कर रही थी। छह साल के प्रोडक्ट बदलावों के दौरान, उनके सर्वर कॉन्फ़िग में 4,200 रीडायरेक्ट नियम जमा हो गए थे। इकतालीस चार-या-उससे-ज़्यादा hop लंबी चेन बनाते थे। छह लाइव loops थे, सर्वर को गोल-गोल घुमाते हुए। हमने हर चेन को single-hop रीडायरेक्ट में बदल दिया, loops ख़त्म किए, और कुल संख्या को 1,180 तक ले आए। पेज 340ms तेज़ लोड होने लगे। दो हफ्ते बाद, Google उनकी साइट का ज़्यादा हिस्सा फिर से क्रॉल कर रहा था।

  1. रीडायरेक्ट चेन (A जाता है B को, B जाता है C को, C जाता है D को)। हर कदम के साथ पूरी चेन का पीछा करके आप इसे पहचान सकते हैं। हर hop थोड़ी रैंक पावर खोता है और देरी जोड़ता है। A को सीधे D पर भेज कर ठीक करें। रीडायरेक्ट चेन डीबगिंग गाइड पूरी स्टेप-बाय-स्टेप प्रक्रिया बताता है।

  2. रीडायरेक्ट loops। सर्वर errors लौटाता है या रीडायरेक्ट के गोल-गोल घूमने के बाद आपका ब्राउज़र timeout हो जाता है। उस नियम को हटाकर ठीक करें जो चेन में पहले वाले URL की तरफ इशारा कर रहा है।

  3. एक ही माइग्रेशन में मिले-जुले 301 और 302। कुछ पेजों को permanent कोड मिला, कुछ को temporary, और Google को असंगत तस्वीर दिखती है। अपने साइटमैप पर हर URL चेक करके और हर नियम को 301 में बदल कर ठीक करें।

  4. ये भूल जाना कि /page और /page/ अलग URL हैं। trailing slash के साथ या बिना, Google इन्हें दो अलग पेज मानता है। दोनों को एक ही पर रीडायरेक्ट करना पड़ेगा, वरना आप अपनी रैंक पावर दो वर्ज़न में बांट देते हैं।

  5. http:// और www. वेरिएंट भूल जाना। हर URL के चार वर्ज़न होते हैं: https के साथ और बिना, www के साथ और बिना। तीन को एक मुख्य वर्ज़न पर 301 करना होगा। इनमें से किसी को छोड़ देने से आपकी authority कई पतों में बंट जाती है।

Variation-URL विस्फोट इसी से जुड़ा WC-विशिष्ट failure मोड है। पांच attributes जिनमें आठ-आठ values हों, एक ही प्रोडक्ट से 40,000 indexable URL बना सकते हैं। WooCommerce-विशिष्ट टेक्निकल SEO उस variation-URL deduplication पैटर्न को कवर करता है जो WC Tower की Floor 3 पर बैठता है।

  1. रीडायरेक्ट के बाद खाली पेज। डेस्टिनेशन URL काम करता है, लेकिन पेज छोटा है या लगभग खाली है। Google इसे “soft 404” (पेज जो तकनीकी रूप से लोड होता है लेकिन गायब जैसा व्यवहार करता है) मानता है और चुपचाप हटा देता है। डेस्टिनेशन पर असली, काम की कंटेंट डालकर ठीक करें। soft 404 रिकवरी प्लेबुक ठीक बताती है कि कितनी कंटेंट काफी है।

  2. लोगों को उनके देश के आधार पर अपने आप रीडायरेक्ट करना। विज़िटर्स कहां से ब्राउज़ कर रहे हैं, इसके आधार पर उन्हें अलग पेज पर भेजना, और उन्हें opt out का कोई तरीका न देना, Google के नियम तोड़ता है। Multi-Region Authority Stack Layer 1 के अनुसार ठीक करें, जो लोगों को क्षेत्र के हिसाब से रूट करने का सही तरीका बताता है।

बिना मैनुअल override के Geo-IP ऑटो-रीडायरेक्ट एक cloaking-जोखिम पैटर्न है जिसे Google की spam टीम फ्लैग करती है। सही तरीके से किए गए multi-region routing के लिए (hreflang, ccTLD architecture, और Layer 1 Geo-IP नियम जो चुपके से 302 नहीं करते), देखें Multi-Region Authority Stack

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

301 और 302 रीडायरेक्ट में क्या अंतर है?

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

क्या 302 रीडायरेक्ट SEO को नुकसान पहुंचाता है?

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

क्या 302 रीडायरेक्ट लिंक इक्विटी पास करता है?

हां। Google के John Mueller ने पुष्टि की है कि 301 और 302 दोनों रीडायरेक्ट लिंक इक्विटी पास करते हैं। पेच यह है: 302 के साथ, गंतव्य URL कैनोनिकल नहीं बनता, इसलिए इक्विटी एक URL पर समेकित होने के बजाय दोनों URL पर बंटी रहती है। जब तक आप 301 पर स्विच नहीं करते या रीडायरेक्ट पूरी तरह हटा नहीं देते, आपके लिंक संकेत बंटे रहते हैं।

301 के बजाय 302 रीडायरेक्ट का उपयोग कब करूं?

स्पष्ट रूप से अस्थायी परिदृश्यों के लिए 302 का उपयोग करें। A/B टेस्ट जहां आप वापस लौटेंगे। घंटों या दिनों की रखरखाव विंडो। कैम्पेन के बाद समाप्त होने वाले प्रोमो पेज। जियो-टेस्टिंग के दौरान लोकेल-विशिष्ट अस्थायी सर्विंग। मानदंड: आपका वास्तव में एक उचित समय-सीमा के भीतर मूल URL को पुनर्स्थापित करने का इरादा है।

Google को 301 रीडायरेक्ट का सम्मान करने में कितना समय लगता है?

आमतौर पर Google के इंडेक्स में पुराने को नए कैनोनिकल से पूरी तरह बदलने में 2 से 6 सप्ताह लगते हैं। सक्रिय क्रॉल बजट वाली हाई-अथॉरिटी साइट्स में प्रोसेसिंग तेज़ होती है। लो-अथॉरिटी साइट्स में समेकन पूरा होने में 8 से 12 सप्ताह लग सकते हैं। GSC के URL Inspection टूल से प्रगति ट्रैक करें। “301 रीडायरेक्ट को Google में कितना समय लगता है” यह प्रश्न मुख्यतः इस पर निर्भर करता है कि Google आपकी साइट को कितनी बार क्रॉल करता है।

क्या मैं बाद में 302 को 301 में बदल सकता हूं? क्या मेरी रैंकिंग वापस आ जाएगी?

हां। अपनी सर्वर कॉन्फ़िग को 302 से 301 में अपडेट करें, Google Search Console में अपना साइटमैप फिर से सबमिट करें, और प्रभावित URL के लिए इंडेक्सिंग का अनुरोध करें। आमतौर पर 2 से 6 सप्ताह में रैंकिंग वापस आ जाती है जब Google रीडायरेक्ट को फिर से प्रोसेस करता है और गंतव्य URL पर संकेत समेकित करता है। जितनी जल्दी आप गलती ठीक करेंगे, उतनी ही जल्दी रिकवरी होगी।

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

308 सख्त स्थायी (method-safe) है। यह क्लाइंट को रीडायरेक्ट के दौरान HTTP मेथड बदलने से मना करता है। 307 सख्त अस्थायी (method-safe) है, उसी मेथड संरक्षण के साथ। 301 और 302 ऐतिहासिक रूप से क्लाइंट को POST अनुरोधों को GET अनुरोधों में बदलने की अनुमति देते थे। API एंडपॉइंट के लिए 307 और 308 का उपयोग करें जहां मूल अनुरोध मेथड को संरक्षित करना महत्वपूर्ण हो।

WordPress में URL कैसे रीडायरेक्ट करूं?

तीन विकल्प। RankMath PRO के रीडायरेक्ट मैनेजर में सबसे स्वच्छ इंटरफ़ेस और स्वचालित 404 डिटेक्शन है। मुफ्त Redirection प्लगइन प्रीमियम लागत के बिना समान कार्यक्षमता प्रदान करता है। मैन्युअल .htaccess एडिटिंग आपको अधिकतम नियंत्रण देती है लेकिन सर्वर एक्सेस की ज़रूरत होती है। व्यापक WordPress तकनीकी-SEO पद्धति के लिए, देखें हमारा WordPress SEO प्लेबुक

मैं कैसे जांचूं कि रीडायरेक्ट सही तरीके से काम कर रहा है?

अपने टर्मिनल में curl -I [old-url] चलाएं ताकि आप देख सकें कि आपका सर्वर वास्तव में कौन सा स्टेटस कोड और Location हेडर रिटर्न कर रहा है। ब्राउज़र DevTools का Network टैब वही जानकारी विज़ुअल चेन रेंडरिंग के साथ दिखाता है। Google Search Console का URL Inspection टूल आपको बताता है कि खुद Google रीडायरेक्ट को कैसे पढ़ता है।

क्या 301 रीडायरेक्ट चेन मेरे SEO को नुकसान पहुंचाएगी?

हां। प्रत्येक हॉप लिंक इक्विटी का एक छोटा हिस्सा खो देता है और लेटेंसी जोड़ देता है। Google लगभग 5 हॉप के बाद चेन का पालन करना बंद कर सकता है, जिससे इक्विटी रास्ते में ही अटक जाती है। अपने रीडायरेक्ट का हर तिमाही ऑडिट करें और चेन को सिंगल-हॉप में समेटें। Screaming Frog चेन को स्वचालित रूप से पहचानता है।

क्या AI सर्च इंजन (ChatGPT, Claude, Gemini) रीडायरेक्ट को Google से अलग तरीके से मानते हैं?

हां। SE Ranking के दिसंबर 2025 के अध्ययन के अनुसार, ChatGPT रीडायरेक्ट किए गए URL को Google की तुलना में 3 से 7 गुना कम उद्धृत करता है। AI सिस्टम स्रोत चुनते समय स्थिर, गैर-रीडायरेक्टेड URL को प्राथमिकता देते हैं। यदि आपकी रणनीति के लिए AI ट्रैफ़िक महत्वपूर्ण है, तो 302 के बजाय 301 को प्राथमिकता दें और अपने उच्च-मूल्य वाले कंटेंट में रीडायरेक्ट चेन समाप्त करें।

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

कम से कम 12 महीने, आदर्श रूप से स्थायी रूप से। एक बार जब Google ने नए URL पर संकेत समेकित कर दिए हों, तो आपको लग सकता है कि रीडायरेक्ट की अब ज़रूरत नहीं है। है। इसे रखें। पुराने URL से लिंक करने वाली अन्य साइट्स वर्षों तक उपयोगकर्ताओं (और बॉट्स) को रीडायरेक्ट के माध्यम से भेजती रहती हैं। इसे हटा दें और वे लिंक 404 हो जाएंगे। उचित नियम: 301 को हमेशा के लिए रखें जब तक कि गंतव्य URL खुद समाप्त नहीं किया जा रहा हो।

?utm_source=X जैसे क्वेरी-स्ट्रिंग पैरामीटर को कैसे रीडायरेक्ट करूं?

दो विकल्प। उन्हें संरक्षित करें: अधिकांश प्लेटफ़ॉर्म क्वेरी स्ट्रिंग्स को स्वचालित रूप से पास करते हैं (Apache RewriteRule, Nginx $request_uri, Cloudflare Workers request.url)। उन्हें हटाएं: क्वेरी के बिना स्पष्ट रूप से गंतव्य पर रीडायरेक्ट करें (जैसे Apache RewriteRule ^old$ /new? [R=301,L], जहां अंत का ? क्वेरी को साफ़ कर देता है)। डिफ़ॉल्ट रूप से संरक्षित करें, जब तक कि आपके पास उन्हें हटाने का कोई विशिष्ट कारण (एनालिटिक्स हाइजीन, कैनोनिकल क्लीनअप) न हो।

क्या रीडायरेक्ट Core Web Vitals या पेज स्पीड को प्रभावित करते हैं?

हां। प्रत्येक रीडायरेक्ट हॉप DNS, TLS हैंडशेक और सर्वर प्रतिक्रिया समय के आधार पर 100-400ms की लेटेंसी जोड़ता है। एक अकेला रीडायरेक्ट शायद ही कभी CWV की चिंता का विषय होता है। किसी क्रिटिकल-पाथ रिसोर्स पर 3+ रीडायरेक्ट की चेन LCP को 2.5 सेकंड से आगे धकेल सकती है और आपके CWV को गिरा सकती है। हमेशा चेन को समेटें और सबसे तेज़ प्रतिक्रिया के लिए रीडायरेक्ट को एज (Cloudflare Workers, CloudFront Functions) पर होस्ट करें।

हार्ड 301 और सॉफ्ट 301 में क्या अंतर है?

HTTP स्पेक में “सॉफ्ट 301” जैसा कुछ नहीं होता। यह शब्द कभी-कभी SEO लेखन में JavaScript-आधारित या मेटा-रिफ्रेश रीडायरेक्ट का वर्णन करने के लिए दिखता है। वे असली 301 नहीं हैं। वे क्लाइंट-साइड हैक्स हैं। एक हार्ड (असली) 301 सर्वर द्वारा स्टेटस कोड 301 के साथ लौटाई गई HTTP-स्तर की प्रतिक्रिया है। एक “सॉफ्ट 301” (JS या मेटा-रिफ्रेश) विश्वसनीय रूप से इक्विटी पास नहीं करता, सभी क्रॉलर्स द्वारा सम्मानित नहीं होता, और लेटेंसी जोड़ता है। हमेशा असली HTTP-स्तर 301 का उपयोग करें।

क्या मैं किसी बाहरी डोमेन पर रीडायरेक्ट कर सकता हूं?

हां। रीडायरेक्ट मैकेनिज़्म एक समान है। Location हेडर बाहरी URL की ओर इंगित करता है, स्टेटस कोड जो भी आप चुनें। SEO परिणाम भी वही हैं: एक बाहरी डोमेन पर 301 रैंकिंग संकेत उस डोमेन पर ट्रांसफ़र करता है, 302 संकेतों को आपकी साइट पर रखता है। बाहरी 301 रीडायरेक्ट का उपयोग कम से कम करें। आप किसी और की साइट को इक्विटी सौंप रहे हैं। सामान्य वैध उपयोग: अधिग्रहण के बाद रीडायरेक्ट करना, पार्टनर-साइट रेफ़रल, या किसी ब्रांड को बंद करना।

रीडायरेक्ट लूप कैसे ठीक करूं?

curl -L -I [url] चलाएं। -L फ़्लैग रीडायरेक्ट का अनुसरण करता है, -I हेडर दिखाता है। यदि ट्रेस दो या अधिक URL के बीच उछलता है, तो आपके पास लूप है। सामान्य कारण: A→B रीडायरेक्ट के साथ B→A कैनोनिकल टैग, परस्पर विरोधी .htaccess नियम, या एक CDN-स्तर का रीडायरेक्ट जो ओरिजिन-सर्वर रीडायरेक्ट से लड़ रहा हो। आपत्तिजनक नियम की पहचान करके (आमतौर पर सबसे हाल में जोड़ा गया) और उसे हटाकर ठीक करें। फ़िक्स के बाद, curl -L -I से फिर से सत्यापित करें। सफल समाधान ट्रेस के अंत में एक एकल 200 दिखाता है।


माइग्रेशन के बीच में हैं? यह रहा ऑफर।

हमें अपना साइटमैप और अपना .htaccess भेजें। हम एक कॉल पर 30 मिनट बिताएंगे। आपकी स्क्रीन और हमारी। हम आपके पांच URL पर लाइव curl चलाएंगे, GSC में आपका रीडायरेक्ट ग्राफ़ देखेंगे, और आपको बताएंगे कि कौन सा फ़िक्स सबसे अधिक रैंकिंग इक्विटी बचाता है। कोई डेक नहीं, कोई प्रस्ताव नहीं, कोई फ़ॉलो-अप सेल्स सीक्वेंस नहीं।

30 मिनट की रणनीति कॉल बुक करें → · WhatsApp +91 96366 50036

पहले कीमत देखना चाहते हैं? प्रकाशित प्राइसिंग इंडेक्स INR, USD, GBP, EUR, AUD में हर रिटेनर टियर दिखाता है। कोई डिस्कवरी-कॉल मल्टीप्लायर नहीं।

मास्टर पद्धति चाहिए? देखें the Prove-It Protocol। Ship → Measure → Prove → Iterate।


लेखक के बारे में

Kunal Singh Dabi, KD Digital के संस्थापक हैं। New Delhi में WASME World MSME Business Summit 2023 में MSMEs के लिए भारत के सर्वश्रेष्ठ SEO विशेषज्ञ के रूप में मान्यता प्राप्त। मई 2021 से 17+ देशों में 250+ व्यवसायों को स्केल किया। 140+ सत्यापित समीक्षाओं में 4.9★। मूल SEO कंसल्टिंग प्रैक्टिस के निर्माता जो हर बदलाव को Monday Report के साथ शिप करती है।