आप जिस लिंक पर क्लिक करते हैं, अक्सर वही पेज आपको नहीं मिलता। बीच में HTTPS अपग्रेड, होस्ट का बदलना, कोई ट्रैकिंग सर्विस, URL शॉर्टनर और ट्रेलिंग स्लैश (URL के आखिर का /) जोड़ने वाला कोई CMS नियम हो सकता है। इनमें से हर एक अलग रिक्वेस्ट है, जिसे आपका ब्राउज़र आपको बताए बिना भेजता है।

इस गाइड में बताया गया है कि TrueURL, curl और ब्राउज़र DevTools से इन कदमों को कैसे देखें, रीडायरेक्ट चेन के हर हिस्से का क्या मतलब है, और सबसे आम समस्याओं को कैसे ठीक करें।

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

रीडायरेक्ट तब होता है जब सर्वर 3xx HTTP स्टेटस कोड और किसी दूसरे URL वाले Location हेडर के साथ जवाब देता है। तब क्लाइंट, यानी ब्राउज़र या क्रॉलर, उस URL को रिक्वेस्ट करता है, और यही प्रक्रिया तब तक दोहराता है जब तक ऐसा रिस्पॉन्स न आ जाए जो रीडायरेक्ट न हो।

हर रिक्वेस्ट और उसका रिस्पॉन्स मिलकर एक हॉप बनाते हैं, यानी रीडायरेक्ट चेन का एक कदम। पहले URL से अंतिम रिस्पॉन्स तक का पूरा सिलसिला रीडायरेक्ट चेन कहलाता है:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

यानी एक पेज तक पहुंचने के लिए तीन रीडायरेक्ट और चार रिक्वेस्ट। हॉप 3 का Location रिलेटिव है: RFC 9110 के मुताबिक क्लाइंट उसे उस URL के आधार पर पूरा करते हैं जिसे उन्होंने अभी-अभी रिक्वेस्ट किया था, इसलिए उसका मतलब है https://www.example.com/shoes/। आदर्श स्थिति में इनमें से हर पता एक ही हॉप में अंतिम URL तक पहुंचना चाहिए।

कोई पेज 200 OK के साथ जवाब देने के बाद भी रीडायरेक्ट कर सकता है, <meta http-equiv="refresh"> टैग या JavaScript के ज़रिए। ये क्लाइंट-साइड रीडायरेक्ट भी चेन का हिस्सा हैं, लेकिन जो टूल सिर्फ़ HTTP हेडर पढ़ते हैं, जैसे curl, वे उसी पेज पर रुक जाते हैं।

रीडायरेक्ट की जांच क्यों ज़रूरी है

SEO: कैननिकल सिग्नल और क्रॉल बजट

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

चेन की लंबाई भी मायने रखती है। Googlebot ज़्यादा से ज़्यादा 10 रीडायरेक्ट हॉप फ़ॉलो करता है; अगर तब तक उसे कॉन्टेंट नहीं मिलता, तो Search Console रीडायरेक्ट एरर रिपोर्ट करता है। Google की क्रॉल बजट (crawl budget) गाइड में भी लंबी रीडायरेक्ट चेन से बचने की सलाह दी गई है, क्योंकि उसके मुताबिक इनका क्रॉलिंग पर बुरा असर पड़ता है।

पेज की स्पीड

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

शॉर्ट और अनजान लिंक की सुरक्षा

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

एफ़िलिएट और ट्रैकिंग लिंक

मार्केटिंग लिंक लैंडिंग पेज तक पहुंचने से पहले अक्सर कई सर्विस से होकर गुज़रते हैं, और हर सर्विस को क्वेरी स्ट्रिंग आगे भेजनी होती है, वरना UTM पैरामीटर, क्लिक ID और एफ़िलिएट टैग चुपचाप गायब हो जाते हैं। अंतिम URL से पता चलता है कि ये बचे रहे या नहीं, और लिंक अब भी सही पेज तक पहुंचता है या नहीं।

माइग्रेशन, HTTPS और कैननिकल होस्ट

रीडिज़ाइन, डोमेन बदलने या HTTPS पर जाने के बाद हर पुराना URL एक ही स्थायी रीडायरेक्ट में सीधे अपने नए पेज तक पहुंचना चाहिए। साइट के चारों बुनियादी रूप (http:// और https://, www के साथ और उसके बिना) एक ही कैननिकल पते पर पहुंचने चाहिए। ये नियम चुपचाप टूटते हैं: कोई नया CDN नियम, प्लगइन अपडेट या सर्वर बदलना, किसी को पता चले बिना एक हॉप या लूप जोड़ सकता है।

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

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

स्टेप 1: URL डालें

URL पेस्ट करें और जांच चलाएं। अगर स्कीम नहीं लिखी है, तो https:// मान लिया जाता है; सादा HTTP टेस्ट करने के लिए http:// टाइप करें।

स्टेप 2: ज़रूरत हो तो एडवांस सेटिंग्स बदलें

डिफ़ॉल्ट रूप से चेकर डेस्कटॉप Chrome के मौजूदा वर्शन वाले यूज़र एजेंट (User-Agent) के साथ GET रिक्वेस्ट भेजता है, बिना किसी कुकी के और 20 रीडायरेक्ट की सीमा के साथ। एडवांस सेटिंग्स में आप इसे बदल सकते हैं:

  • HTTP मेथड: GET, HEAD या POST। HEAD हल्का होता है, लेकिन कुछ सर्वर उसका जवाब अलग तरह से देते हैं, और बॉडी के बिना क्लाइंट-साइड रीडायरेक्ट पकड़े नहीं जा सकते। POST आपकी डाली गई रिक्वेस्ट बॉडी भेजता है, जो फ़ॉर्म हैंडलर और API के लिए काम आता है। आगे के हॉप ब्राउज़र के नियमों पर चलते हैं: POST के बाद 301 या 302 मिलने पर अगली रिक्वेस्ट GET से होती है, 303 के बाद हमेशा GET से होती है, और 307 व 308 मेथड और बॉडी दोनों बनाए रखते हैं।
  • अधिकतम हॉप: कितने रीडायरेक्ट फ़ॉलो किए जाएं, 1 से 50 तक। डिफ़ॉल्ट 20 है, जो Fetch Standard और Chrome व Firefox की सीमा है। चेन Googlebot की सीमा में आती है या नहीं, यह देखने के लिए इसे 10 पर सेट करें।
  • कस्टम User-Agent: खाली छोड़ने पर डेस्कटॉप Chrome इस्तेमाल होता है। प्रीसेट में iPhone पर Safari, Android पर Chrome, Googlebot (स्मार्टफ़ोन और डेस्कटॉप), Bingbot, Facebook और X के लिंक प्रीव्यू बॉट, और curl शामिल हैं।
  • कस्टम रिक्वेस्ट हेडर: अतिरिक्त हेडर जो हर हॉप पर भेजे जाते हैं, जैसे भाषा के हिसाब से होने वाला रीडायरेक्ट ट्रिगर करने के लिए Accept-Language: fr-FR।
  • कुकी: लॉग-इन, कुकी सहमति (consent) या क्षेत्र वाली स्थिति दोहराने के लिए name=value; other=value डालें। चेन के दौरान सेट हुई कुकीज़ आगे के हॉप के लिए रखी जाती हैं, बिल्कुल ब्राउज़र की तरह।
  • क्लाइंट-साइड रीडायरेक्ट: मेटा रिफ़्रेश टैग और सामान्य JavaScript रीडायरेक्ट को फ़ॉलो करें, या उन्हें सिर्फ़ रिपोर्ट करें।
  • SSL एरर को अनदेखा करें: Cloudflare का एज हमेशा सर्टिफ़िकेट वैलिडेट करता है, इसलिए इस विकल्प से खराब सर्टिफ़िकेट को छोड़ा नहीं जा सकता। TLS एरर उसी हॉप पर रिपोर्ट होता है जहां वह हुआ।

स्टेप 3: नतीजा पढ़ें

नतीजे में सबसे ऊपर अंतिम URL और उसका स्टेटस कोड होता है। उसके नीचे की चेन में हर हॉप की एक पंक्ति होती है, जिसमें ये जानकारियां होती हैं:

  • रिक्वेस्ट किया गया URL और इस्तेमाल हुआ HTTP मेथड;
  • स्टेटस कोड और रीज़न फ़्रेज़ (स्टेटस कोड रेफ़रेंस में हर कोड समझाया गया है);
  • रिस्पॉन्स टाइम, यानी रिक्वेस्ट भेजने से लेकर हेडर आने तक का समय, जिसमें DNS लुकअप और कनेक्शन बनने का समय भी शामिल है;
  • वह Location जिस पर हॉप आगे भेजता है;
  • रिस्पॉन्स हेडर और उस हॉप में सेट हुई कुकीज़ के नाम।

हर रीडायरेक्ट पर लेबल लगा होता है कि वह किस तरीके से हुआ: HTTP स्टेटस कोड, मेटा रिफ़्रेश (सेकंड में उसकी देरी के साथ) या JavaScript। जो क्लाइंट-साइड रीडायरेक्ट मिले, लेकिन फ़ॉलो नहीं किए गए, वे भी रिपोर्ट होते हैं। उतना ही अहम यह है कि जांच किस तरह खत्म हुई:

नतीजा इसका मतलब
अंतिम रिस्पॉन्स चेन ऐसे रिस्पॉन्स तक पहुंच गई जो रीडायरेक्ट नहीं है, जैसे 200 OK या 404 Not Found।
रीडायरेक्ट लूप अगली रिक्वेस्ट किसी पिछली रिक्वेस्ट को ही दोहराती: वही URL, वही मेथड और वही कुकीज़। नतीजे में दिखता है कि कौन-सा हॉप लूप को पूरा करता है।
अधिकतम हॉप की सीमा पूरी हुई सीमा पर पहुंचने के बाद भी चेन रीडायरेक्ट कर रही थी। अगला टारगेट दिखाया जाता है, लेकिन उसे रिक्वेस्ट नहीं किया जाता।
एरर कोई हॉप फ़ेल हो गया: DNS, कनेक्शन, TLS या टाइमआउट की वजह से, या रीडायरेक्ट का टारगेट कोई मान्य या अनुमति वाला URL नहीं था।

चेतावनियां इन बातों पर फ़्लैग लगाती हैं: चेन में कोई अस्थायी रीडायरेक्ट, HTTPS से HTTP पर डाउनग्रेड, तीन से ज़्यादा रीडायरेक्ट, किसी दूसरे डोमेन पर अंतिम URL, क्लाइंट-साइड रीडायरेक्ट, और ऐसी HEAD रिक्वेस्ट जो पेज की बॉडी नहीं पढ़ पाईं।

एक चेतावनी पर खास ध्यान दें। कुछ साइटें ऑटोमेटेड या डेटा सेंटर से आने वाले ट्रैफ़िक को बॉट चैलेंज पेज (बॉट जांचने वाला पेज) दिखाती हैं, जैसे Cloudflare का “Just a moment...” पेज। TrueURL ऐसे दिखने वाले रिस्पॉन्स को मार्क करता है, क्योंकि जांच साइट की सुरक्षा परत तक पहुंची, डेस्टिनेशन तक नहीं। असली विज़िटर किसी और जगह पहुंच सकता है।

कमांड लाइन से रीडायरेक्ट कैसे चेक करें

macOS, Windows 10 और 11 और ज़्यादातर Linux डिस्ट्रीब्यूशन में curl पहले से इंस्टॉल रहता है, और यह ठीक वही दिखाता है जो सर्वर भेजता है, बीच में कोई ब्राउज़र कैश नहीं होता। उदाहरण Unix शेल के हैं; Windows PowerShell 5.1 में curl.exe टाइप करें, क्योंकि वहां curl असल में Invoke-WebRequest का उपनाम (alias) है, और /dev/null की जगह NUL लिखें।

एक हॉप देखें

Bash
curl -I https://example.com/old-page

-I एक HEAD रिक्वेस्ट भेजता है और रिस्पॉन्स हेडर प्रिंट करता है, जिनमें स्टेटस लाइन और Location (अगर हो) भी शामिल हैं। जब तक कहा न जाए, curl रीडायरेक्ट फ़ॉलो नहीं करता। कुछ सर्वर HEAD के साथ अलग बर्ताव करते हैं, इसलिए नतीजा अजीब लगे तो यही जांच GET से दोहराएं; -o /dev/null बॉडी को हटा देता है और -D - हेडर प्रिंट करता है:

Bash
curl -sS -o /dev/null -D - https://example.com/old-page

पूरी चेन फ़ॉलो करें

-L रीडायरेक्ट फ़ॉलो करता है, और -I या -D - के साथ curl हर हॉप के हेडर प्रिंट करता है। grep फ़िल्टर लगाने से छोटा और साफ़ नतीजा मिलता है:

Bash
curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

curl डिफ़ॉल्ट रूप से 50 तक रीडायरेक्ट फ़ॉलो करता है; --max-redirs 10 से Googlebot वाली सीमा लागू होती है।

सिर्फ़ अंतिम URL प्रिंट करें

-w (write-out) विकल्प ट्रांसफ़र के बाद जानकारी प्रिंट करता है, जिससे curl एक छोटा-सा URL एक्सपैंडर बन जाता है:

Bash
curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} आखिरी बार फ़ेच किया गया URL है, %{num_redirects} फ़ॉलो किए गए रीडायरेक्ट की संख्या और %{http_code} अंतिम स्टेटस। %{time_redirect} बताता है कि अंतिम रिक्वेस्ट से पहले रीडायरेक्ट में कितने सेकंड लगे। -L के बिना %{redirect_url} दिखाता है कि पहला रीडायरेक्ट कहां ले जाता।

POST रिक्वेस्ट टेस्ट करें

-d बॉडी भेजता है और रिक्वेस्ट को POST बना देता है। रीडायरेक्ट फ़ॉलो करते समय curl फिर ब्राउज़र की तरह बर्ताव करता है: 301, 302 या 303 के बाद वह GET पर आ जाता है, और 307 या 308 के बाद POST को उसकी बॉडी के साथ दोबारा भेजता है।

Bash
curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

-X POST को -L के साथ इस्तेमाल न करें। -X हर रिक्वेस्ट पर मेथड थोप देता है, इसलिए 301, 302 या 303 के बाद भी curl POST ही भेजता रहता है, जबकि ब्राउज़र GET पर आ जाता। इस तरह आप ऐसी चेन टेस्ट करते हैं जो कोई असली क्लाइंट कभी नहीं बनाता।

User-Agent, हेडर और कुकीज़ बदलें

Bash
# Smartphone User-Agent
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Extra request header
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Send a cookie and keep the cookies set along the chain
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A User-Agent सेट करता है, -H हेडर जोड़ता है और -b कुकीज़ भेजता है। -c मिली हुई कुकीज़ को फ़ाइल में सेव करता है और curl का कुकी इंजन चालू कर देता है, ताकि एक हॉप पर सेट हुई कुकी अगले हॉप पर भेजी जाए।

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

ब्राउज़र DevTools में रीडायरेक्ट कैसे चेक करें

DevTools चेन को वैसे ही दिखाता है जैसे आपका अपना ब्राउज़र उसे देखता है, यानी आपकी कुकीज़, एक्सटेंशन और लोकेशन के साथ:

  1. DevTools खोलें (F12, या Mac पर Cmd+Option+I) और Network टैब चुनें।
  2. Chrome और Edge में Preserve log चालू करें, या Firefox में नेटवर्क सेटिंग्स मेन्यू से Persist Logs। ऐसा न करने पर हर पेज लोड के साथ लिस्ट साफ़ हो जाती है और क्लाइंट-साइड रीडायरेक्ट नज़र से गायब हो जाते हैं।
  3. Disable cache चालू करें, ताकि कैश में रखा कोई रीडायरेक्ट यह न छिपा दे कि सर्वर आज क्या भेज रहा है।
  4. एड्रेस बार में URL डालें।

हर हॉप अपने 3xx स्टेटस के साथ एक अलग पंक्ति में दिखता है; उसे चुनें और location रिस्पॉन्स हेडर देखने के लिए Headers खोलें। Chrome में Size कॉलम में “(disk cache)” या “(memory cache)” लिखा हो, तो इसका मतलब है कि रीडायरेक्ट सर्वर से नहीं, कैश से आया।

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

रीडायरेक्ट की आम समस्याएं और उनका समाधान

एक से ज़्यादा हॉप वाली चेन

चेन परत-दर-परत बढ़ती हैं: किसी पुराने माइग्रेशन का नियम ऐसे URL पर भेजता है जिसे बाद के किसी माइग्रेशन ने फिर से रीडायरेक्ट कर दिया। हर नियम को सीधे अंतिम URL पर भेजें, और इंटरनल लिंक, कैननिकल टैग, hreflang एनोटेशन और साइटमैप अपडेट करें, ताकि आपकी अपनी साइट कभी कोई रीडायरेक्ट ट्रिगर न करे। बल्क रीडायरेक्ट चेकर दिखाता है कि किन पुराने URL को अब भी एक से ज़्यादा हॉप लगते हैं।

रीडायरेक्ट लूप

Chrome लूप को “redirected you too many times” (ERR_TOO_MANY_REDIRECTS) के रूप में रिपोर्ट करता है; Firefox कहता है “The page isn't redirecting properly”। आम वजहें:

  • प्रॉक्सी या CDN के पीछे HTTPS। ओरिजिन सर्वर HTTP को HTTPS पर रीडायरेक्ट करता है, लेकिन प्रॉक्सी ओरिजिन तक सादे HTTP से पहुंचता है, इसलिए ओरिजिन को कभी HTTPS दिखता ही नहीं और वह लगातार रीडायरेक्ट करता रहता है। Cloudflare पर यह Flexible SSL/TLS मोड का जाना-पहचाना नतीजा है; Full (strict) इस्तेमाल करें, या ओरिजिन से X-Forwarded-Proto चेक करवाएं।
  • आपस में टकराने वाली दो परतें, जैसे CDN का कोई नियम www हटाता है जबकि सर्वर उसे जोड़ता है, या कोई फ़्रेमवर्क ट्रेलिंग स्लैश जोड़ता है जिसे CDN हटा देता है।
  • कुकी पर निर्भर रीडायरेक्ट। लॉगिन या कुकी सहमति वाला पेज विज़िटर को वापस मूल URL पर भेजता है, जो उन्हें फिर से लॉगिन पेज पर रीडायरेक्ट कर देता है, क्योंकि कुकी सेव नहीं हुई थी।

रीडायरेक्ट लूप चेकर दिखाता है कि कौन-सा हॉप लूप को पूरा करता है। फिर हर नियम की ज़िम्मेदारी किसी एक ही परत को सौंपें।

एक ही चेन में 301 और 302 का मेल

301, फिर 302, फिर 200 वाली चेन असल में एक स्थायी बदलाव है, जिसके बीच में एक अस्थायी कदम आ गया है। ऐसा अक्सर किसी डिफ़ॉल्ट सेटिंग की वजह से होता है: Express का res.redirect() और PHP का header('Location: ...'), दोनों अलग से न बताने पर 302 भेजते हैं। हर हॉप पर स्थायी कोड इस्तेमाल करें और 301 रीडायरेक्ट चेकर से इसकी पुष्टि करें। HTTP रीडायरेक्ट स्टेटस कोड पर हमारी गाइड बताती है कि कौन-सा कोड कब सही है।

HTTP से HTTPS और फिर www: दोहरा हॉप

एक बहुत आम चेन है http://example.com → https://example.com → https://www.example.com: जहां एक हॉप काफ़ी था, वहां दो। हर नॉन-कैननिकल रूप को सीधे अंतिम HTTPS URL पर रीडायरेक्ट करें, फिर HTTPS रीडायरेक्ट चेकर से चारों रूप टेस्ट करें।

एक अपवाद जान-बूझकर रखा जाता है। अगर आपका कैननिकल होस्ट www है और आप डोमेन को HSTS प्रीलोड लिस्ट में जोड़ते हैं, तो hstspreload.org की शर्त है कि http://example.com पहले https://example.com पर रीडायरेक्ट हो, ताकि ब्राउज़र बिना www वाले मूल डोमेन के लिए HSTS पॉलिसी दर्ज कर लें।

ट्रेलिंग स्लैश का अलग-अलग इस्तेमाल

/pricing और /pricing/ दो अलग URL हैं। अगर दोनों 200 OK लौटाते हैं, तो आपके पास डुप्लीकेट कॉन्टेंट है; अगर दो परतें इन्हें एक-दूसरे पर रीडायरेक्ट करती हैं, तो लूप बन जाता है। एक रूप चुनें, दूसरे को एक ही 301 से उस पर रीडायरेक्ट करें और हर जगह उसी रूप से लिंक करें। ट्रेलिंग स्लैश चेकर दोनों रूप एक साथ टेस्ट करता है।

सिर्फ़ मोबाइल पर होने वाले रीडायरेक्ट

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

साइटमैप में रीडायरेक्ट

साइटमैप में वे कैननिकल URL होने चाहिए जिन्हें आप सर्च नतीजों में देखना चाहते हैं, और वे 200 OK लौटाते हैं। रीडायरेक्ट होने वाली एंट्री क्रॉल रिक्वेस्ट बर्बाद करती हैं और कैननिकल को लेकर आपस में टकराते सिग्नल भेजती हैं। हर माइग्रेशन के बाद साइटमैप रीडायरेक्ट चेकर चलाएं और रीडायरेक्ट होने वाली हर एंट्री को उसके अंतिम URL से बदल दें।

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

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

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

माइग्रेशन या CDN में बदलाव के बाद, या किसी कैंपेन को लॉन्च करने से पहले, यह लिस्ट एक बार ज़रूर देखें:

  1. हर पुराना URL एक ही हॉप में अपने अंतिम URL तक पहुंचता है।
  2. स्थायी बदलाव में हर हॉप पर 301 या 308 इस्तेमाल होता है।
  3. प्रोटोकॉल और होस्ट के चारों रूप कैननिकल HTTPS URL पर खत्म होते हैं।
  4. कोई भी हॉप HTTPS से HTTP पर नहीं जाता।
  5. क्वेरी स्ट्रिंग, जिनमें UTM पैरामीटर और एफ़िलिएट ID भी शामिल हैं, पूरी चेन में बची रहती हैं।
  6. ट्रेलिंग स्लैश के मामले में हर URL का एक ही रूप है (स्लैश के साथ या उसके बिना), और दूसरा रूप उस पर रीडायरेक्ट होता है।
  7. डेस्कटॉप, स्मार्टफ़ोन और Googlebot की रिक्वेस्ट एक जैसे पेजों पर खत्म होती हैं।
  8. जहां भी मुमकिन हो, मेटा रिफ़्रेश और JavaScript की जगह सर्वर-साइड रीडायरेक्ट इस्तेमाल होते हैं।
  9. इंटरनल लिंक, कैननिकल टैग, hreflang और साइटमैप अंतिम URL की ओर इशारा करते हैं।
  10. हटाए गए जिन पेजों का कोई विकल्प नहीं है, वे होम पेज पर रीडायरेक्ट करने के बजाय 404 या 410 लौटाते हैं।
  11. साइट बदलने के बाद के रीडायरेक्ट लगे रहते हैं; Google इन्हें कम से कम एक साल तक रखने की सलाह देता है।