WordPress .htaccess रीडायरेक्ट नियम: 301 सही तरीके से

कोई URL बदल रहे हैं और चाहते हैं कि पुराना अपनी रैंकिंग बनाए रखे? आपको .htaccess में 301 चाहिए — ऐसी जगह रखा हुआ जहाँ WordPress उसे मिटा न दे, सही डायरेक्टिव से लिखा हुआ, और ठीक उस URL की ओर इशारा करता हुआ जो WordPress असल में परोसता है। इन तीनों में से कुछ भी गलत हुआ तो आपको रीडायरेक्ट चेन मिलेगी, लूप मिलेगा, या ऐसा 500 मिलेगा जो आपको wp-admin से बाहर कर देगा।

फ़ैसला, जगह का नियम, और टेस्ट — इसी क्रम में।

कौन सा डायरेक्टिव: Redirect, RedirectMatch या RewriteRule

खेल में Apache के दो मॉड्यूल हैं और वे एक-दूसरे की जगह नहीं ले सकते।

Redirect (mod_alias) — एक ज्ञात पाथ से एक मंज़िल तक। जो सबसे सरल चीज़ काम कर जाती है, वही:

Redirect 301 /old-page/ https://example.com/new-page/

दो बातें जान लीजिए। यह पूरे स्ट्रिंग से नहीं, पाथ prefix से मेल खाता है, इसलिए /old-page/ /old-page/anything/ को भी पकड़ता है और मंज़िल में /anything/ जोड़ देता है। और यह query string अपने आप साथ ले जाता है।

RedirectMatch (mod_alias) — एक regex जो कई URL को कवर करे। पूरा सेक्शन ऐसे खिसकाया जाता है:

RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1

capture group (.*) मंज़िल में $1 बन जाता है, इसलिए /blog/hello-world/ /articles/hello-world/ पर उतरता है। शुरुआती स्लैश पर ध्यान दीजिए: mod_alias के पैटर्न पूरे URL पाथ से मेल खाते हैं।

RewriteRule (mod_rewrite) — तब ज़रूरी है जब रीडायरेक्ट किसी शर्त पर निर्भर हो: hostname, प्रोटोकॉल, query string, user agent। mod_alias में कुछ भी इन्हें जाँच नहीं सकता।

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

per-directory .htaccess में पैटर्न से शुरुआती स्लैश हटा दिया जाता है — इसीलिए यहाँ ^(.*)$ है और mod_alias वाले उदाहरण में ^/blog/। इसी को गड्ड-मड्ड करना वह अकेली सबसे आम वजह है जिससे कहीं से चिपकाया गया नियम चुपचाप कुछ नहीं करता।

डिफ़ॉल्ट रूप से mod_alias चुनिए। RewriteRule की ओर सिर्फ़ तब जाइए जब आपको कोई शर्त चाहिए। कम regex, गलत होने के कम रास्ते।

नियम कहाँ रखे जाने चाहिए

कस्टम रीडायरेक्ट # BEGIN WordPress लाइन के ऊपर आते हैं। उसके अंदर नहीं।

# --- custom redirects ---
Redirect 301 /old-page/ https://example.com/new-page/
RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

दो अलग-अलग वजहें:

1. WordPress अपना ब्लॉक खुद दोबारा लिखता है। Settings → Permalinks सेव करने पर flush_rewrite_rules() चलता है, जो मार्करों के बीच की हर चीज़ फेंककर उसे दोबारा बनाता है। अंदर रखा गया आपका नियम अगली बार गायब हो जाएगा जब कोई उस स्क्रीन को छुएगा — शायद महीनों बाद, और कोई इन दोनों घटनाओं को जोड़ भी नहीं पाएगा।
2. क्रम तय करता है कि कौन जीतेगा। WordPress ब्लॉक एक catch-all पर खत्म होता है जो हर ऐसा अनुरोध index.php को भेजता है जो न फ़ाइल है न डायरेक्टरी। उसके बाद रखा गया RewriteRule कभी चलता ही नहीं।

एक ईमानदार पेच: mod_alias और mod_rewrite असल में फ़ाइल के क्रम में नहीं चलते। Apache mod_alias को URL translation के दौरान चलाता है और per-directory mod_rewrite को बाद में, fixup के दौरान — इसलिए एक Redirect लाइन उस RewriteRule को हरा सकती है जो फ़ाइल में उससे ऊपर लिखी है। अगर आपको एक ही ओवरलैप करते पाथ पर दोनों की ज़रूरत पड़ रही है, तो उस पाथ के लिए एक मॉड्यूल चुनिए और उसी में रहिए। mod_alias बनाम mod_rewrite की लड़ाई डीबग करना एक घंटे के लायक नहीं है।

आख़िरी स्लैश

WordPress का अपना canonical रीडायरेक्ट ज़्यादातर permalinks में आख़िरी स्लैश जोड़ देता है। तो यह:

Redirect 301 /old-page/ https://example.com/new-page

दो hop बनाता है — आपका 301 बिना स्लैश वाले URL तक, फिर WordPress का अपना 301 जो स्लैश जोड़ता है। चेन रैंकिंग सिग्नल तो फिर भी पास करती हैं, पर वे crawl budget बर्बाद करती हैं और हर विज़िटर के लिए एक अतिरिक्त round trip जोड़ती हैं।

पहले मंज़िल को ब्राउज़र में लोड कीजिए, address bar में जमने के बाद URL को हूबहू कॉपी कीजिए, और वही इस्तेमाल कीजिए। अगर आपकी permalink संरचना .html पर खत्म होती है या उसमें आख़िरी स्लैश नहीं है, तो उसी से मिलाइए। यहाँ हर हाल में सही कोई एक जवाब नहीं है, सिर्फ़ “जो WordPress परोसता है, वही मिलाइए”।

खुद को बाहर किए बिना टेस्ट करना

.htaccess हर अनुरोध पर पढ़ी जाती है। एक syntax गलती wp-admin समेत पूरी साइट के लिए 500 लौटाती है, इसलिए रिकवरी का रास्ता ज़रूरत पड़ने से पहले मौजूद होना चाहिए।

पहले फ़ाइल का बैकअप लीजिए। SSH से:

cp /path/to/wordpress/.htaccess /path/to/wordpress/.htaccess.bak

अगर साइट 500 देने लगे, तो टूटी फ़ाइल के ऊपर बैकअप का नाम बदल दीजिए और साइट तुरंत लौट आती है। दूसरी विंडो में एक SFTP सेशन पहले से खुला रखिए — साइट डाउन रहते हुए शुरू से लॉगिन करना ही वह क्षण है जहाँ घबराहट शुरू होती है। ध्यान रखिए कि apachectl configtest .htaccess को parse नहीं करता, इसलिए आपकी साइट मरी होने पर भी वह कॉन्फ़िग को स्वस्थ बताएगा।

ब्राउज़र से नहीं, curl से टेस्ट कीजिए। ब्राउज़र 301 उत्तरों को बुरी तरह cache करते हैं और खुशी-खुशी आपको कल का नतीजा दिखा देंगे:

curl -sI https://example.com/old-page/ | head -n 5

दो चीज़ें पढ़िए: status लाइन में 301 होना चाहिए, और Location: हेडर ठीक वही अंतिम URL होना चाहिए। पूरी चेन देखने के लिए उसका पीछा कीजिए:

curl -sIL https://example.com/old-page/ | grep -E '^(HTTP|Location)'

एक से ज़्यादा HTTP/1.1 301 लाइन का मतलब है आपने चेन बना दी। करीब पाँच से ज़्यादा का मतलब है आपने लूप बना दिया, और curl रुककर आपको यह बता भी देगा।

जब तक पक्का न हो, 302 इस्तेमाल कीजिए। 302 उसी तरह cache नहीं होता, इसलिए गलती सेकंडों में पलटी जा सकती है। जब curl वही मंज़िल दिखाने लगे जो आप चाहते थे, तब 301 पर स्विच कीजिए। इसकी कोई कीमत नहीं है और इस लेख की किसी भी दूसरी आदत से ज़्यादा साइटें इसी ने बचाई हैं।

अगर कोई नियम बिल्कुल कुछ करता ही न दिखे, तो पहले पुष्टि कीजिए कि Apache फ़ाइल पढ़ भी रहा है या नहीं। डायरेक्टरी पर AllowOverride None लगा हो तो Apache .htaccess को पूरी तरह अनदेखा कर देता है, और nginx तो उसे बिल्कुल ही नहीं देखता — regex डीबग करने से पहले curl -I से Server: हेडर जाँच लीजिए। अपने Apache वर्शन और इंस्टॉल पाथ के लिए सही syntax वाला ब्लॉक तैयार करने के लिए WordPress .htaccess जनरेटर इस्तेमाल कीजिए।

.htaccess कब बिल्कुल इस्तेमाल नहीं करनी चाहिए

गिने-चुने ऐसे रीडायरेक्ट के लिए जिन्हें एडिटर खुद संभालना चाहते हैं, नियमों को डेटाबेस में रखने वाला रीडायरेक्ट प्लगइन बेहतर औज़ार है — वह होस्ट माइग्रेशन झेल जाता है और उसके लिए SSH नहीं चाहिए। समझौता असली है: रीडायरेक्ट परोसने के लिए php को बूट होना पड़ता है, जो Apache के सीधे जवाब देने से धीमा है।

.htaccess को संरचनात्मक, स्थायी बदलावों के लिए रखिए — डोमेन बदलना, सेक्शन का नाम बदलना, https या www लागू करना। इक्का-दुक्का संपादकीय रीडायरेक्ट के लिए प्लगइन इस्तेमाल कीजिए। दोनों करना ठीक है, बशर्ते आपको पता हो कि कौन सी परत किस URL की मालिक है, क्योंकि दो जगह परिभाषित रीडायरेक्ट एक ऐसा बग है जो किसी बुरी दोपहर का इंतज़ार कर रहा है।