WordPress की डिफॉल्ट .htaccess फाइल: कोड और बहाली का तरीका

WordPress की डिफॉल्ट .htaccess फाइल वह छोटा RewriteEngine ब्लॉक है जिसे सॉफ्टवेयर आपकी साइट के रूट की .htaccess में लिखता है, ताकि /2026/10/post-name/ जैसे परमालिंक्स 404 देने के बजाय काम करें। यह ऐसा दिखता है:

# BEGIN WordPress
<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

ये रूल्स उस कोड से आते हैं जिससे WordPress यह ब्लॉक बनाता है, और ये WordPress की अपनी .htaccess गाइड से मेल खाते हैं। WordPress # BEGIN WordPress के ठीक बाद तीन कमेंट लाइनें भी लिखता है, जो चेतावनी देती हैं कि मार्करों के बीच किए गए बदलाव ओवरराइट हो जाएंगे। इनसे रूल्स के काम करने का तरीका नहीं बदलता।

सबफोल्डर इंस्टॉल में WordPress सबफोल्डर का पाथ RewriteBase और आखिरी रूल दोनों में रखता है, जैसे RewriteBase /blog/ और RewriteRule . /blog/index.php [L]। मल्टीसाइट नेटवर्क एक अलग ब्लॉक इस्तेमाल करते हैं, और WordPress उनके लिए यह फाइल अपने आप नहीं लिखता।

मुख्य बातें

• WordPress यह ब्लॉक Apache और LiteSpeed पर तब बनाता है जब उसके पास लिखने की अनुमति हो और प्रीटी परमालिंक्स चालू हों। Settings > Permalinks खोलना ही काफी है।
• अगर फाइल गायब या खराब है, तो परमालिंक्स 404 देते हैं जबकि होमपेज लोड होता रहता है, क्योंकि होमपेज को rewrite rules की ज़रूरत नहीं होती।
• आप या कोई प्लगइन जो भी जोड़े, उसे # BEGIN WordPress के ऊपर रखें, मार्करों के अंदर कभी नहीं। WordPress फाइल अपडेट करते समय इनके बीच की हर चीज़ बदल देता है।

हर लाइन असल में क्या करती है

RewriteEngine On इस डायरेक्टरी के लिए Apache का mod_rewrite मॉड्यूल चालू करता है; इसके बिना नीचे के rewrite rules कुछ नहीं करते।

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] URL को जैसा है वैसा छोड़ देता है (- का यही मतलब है) और रिक्वेस्ट के Authorization हेडर को एक सर्वर वेरिएबल में कॉपी करता है। WordPress उस वेरिएबल को पढ़ता है ताकि हेडर में भेजा गया यूज़रनेम और पासवर्ड ले सके, जैसे Application Password।

RewriteBase / वह पाथ प्रीफिक्स तय करता है जिसे Apache रीराइट किए गए URLs के लिए इस्तेमाल करता है। WordPress इसे साइट की लोकेशन के अनुसार सेट करता है, इसलिए सबफोल्डर इंस्टॉल को RewriteBase /blog/ मिलता है।

RewriteRule ^index\.php$ - [L] एक गार्ड है: अगर रिक्वेस्ट पहले से index.php के लिए है, तो रीराइटिंग रुक जाती है और रिक्वेस्ट बिना बदले आगे जाती है।

दोनों RewriteCond लाइनें असली लॉजिक हैं। %{REQUEST_FILENAME} !-f और !-d पूछते हैं “क्या यह रिक्वेस्ट किसी असली फाइल से मेल नहीं खाती, और किसी असली डायरेक्टरी से भी मेल नहीं खाती?” आखिरी रूल चलने के लिए दोनों का सच होना ज़रूरी है, इसलिए असली इमेज, CSS फाइल या अपलोड की गई PDF सीधे सर्व होती है और WordPress की रूटिंग तक नहीं पहुंचती।

RewriteRule . /index.php [L] ही परमालिंक्स को काम करवाता है। जो कुछ इन दोनों शर्तों से गुज़रता है वह index.php पर भेजा जाता है, और WordPress तय करता है कि URL का मतलब कौन सी पोस्ट, पेज या आर्काइव है।

WordPress यह फाइल कब फिर से बनाता है, और कब नहीं

हर बार जब Settings > Permalinks स्क्रीन लोड होती है, WordPress अपने rewrite rules फ्लश करता है, इसलिए इसे खोलना ही काफी है और Save Changes पर क्लिक करने की ज़रूरत नहीं। अगर .htaccess गायब है, तो WordPress इसे बना देता है, बशर्ते फोल्डर writable हो और प्रीटी परमालिंक्स चालू हों। अगर फाइल मौजूद और writable है, तो WordPress मार्करों के बीच का ब्लॉक बदल देता है।

इन स्थितियों में इससे समस्या हल नहीं होती:

• फाइल या उसका फोल्डर writable नहीं है उस यूज़र के लिए जिसके रूप में PHP चलता है। स्क्रीन एरर दिखाती है कि .htaccess फाइल writable नहीं है, साथ में पेस्ट करने के लिए रूल्स भी। कुछ होस्ट्स पर PHP उस सिस्टम यूज़र से अलग यूज़र के रूप में चलता है जिसके पास आपके FTP अपलोड का मालिकाना है, इसलिए FTP क्लाइंट में सही दिखने वाली परमिशन भी WordPress को रोक सकती हैं।
• आप nginx पर हैं। WordPress की nginx गाइड कहती है कि nginx में .htaccess जैसी डायरेक्टरी-लेवल कॉन्फिगरेशन फाइल नहीं होती, और WordPress सर्वर कॉन्फिगरेशन नहीं बदल सकता। इसके बराबर की रूटिंग सर्वर कॉन्फिगरेशन में एक try_files डायरेक्टिव है, जिसे एडमिनिस्ट्रेटर को एडिट करना पड़ता है।
• AllowOverride को None पर सेट किया गया है मुख्य Apache कॉन्फिगरेशन में आपकी साइट की डायरेक्टरी के लिए। Apache का डॉक्यूमेंटेशन कहता है: “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” यानी जब तक आप किसी डायरेक्टरी के लिए इन्हें साफ तौर पर चालू न करें, .htaccess फाइलें पूरी तरह नज़रअंदाज़ होती हैं। WordPress एकदम सही फाइल लिख सकता है और तब भी उसका कोई असर नहीं होगा। Rewrite rules के लिए ज़रूरी है AllowOverride FileInfo (या All), जिसे शायद आपके होस्ट को बदलना पड़े।
• आपके परमालिंक्स Plain पर सेट हैं। Plain URLs को rewrite rules की ज़रूरत नहीं होती, इसलिए WordPress उनके लिए फाइल नहीं बनाता।

इसे मैन्युअली कैसे बहाल करें

अगर पोस्ट्स और पेज 404 दे रहे हैं जबकि होमपेज चल रहा है, तो सबसे पहले गायब या खराब .htaccess की जांच करें। इसे दो चरणों में ठीक करें।

1. पहले एक क्लिक वाला उपाय आज़माएं। wp-admin में Settings > Permalinks खोलें, फिर कुछ बदले बिना Save Changes पर क्लिक करें। अगर WordPress फाइल लिख सकता है, तो इससे वह फिर से बन जाती है। अगर नहीं लिख सकता, तो स्क्रीन एरर और ज़रूरी रूल्स दिखाती है।

2. अगर इससे ठीक न हो, तो फाइल खुद बनाएं। FTP/SFTP या अपने होस्ट के फाइल मैनेजर से कनेक्ट करें और साइट के रूट फोल्डर में जाएं, जो आमतौर पर wp-admin वाला फोल्डर होता है। देखें कि .htaccess मौजूद है या नहीं। यह एक डॉटफाइल है, इसलिए कुछ फाइल मैनेजर इसे डिफॉल्ट रूप से छिपाते हैं; “show hidden files” चालू करें।

• अगर यह गायब है, तो ठीक .htaccess नाम की नई फाइल बनाएं (कोई .txt नहीं, डॉट से पहले कुछ नहीं)।
• WordPress के दिखाए रूल्स पेस्ट करें, या इस गाइड में सबसे ऊपर दिया गया डिफॉल्ट ब्लॉक। सबफोल्डर इंस्टॉल में RewriteBase और आखिरी रूल को उसके अनुसार बदलें।
• सेव करें, फिर किसी पोस्ट का परमालिंक दोबारा लोड करके पुष्टि करें कि वह काम करता है।

अगर फिर भी 404 आए, तो हो सकता है .htaccess नज़रअंदाज़ हो रही हो। अपने होस्ट से AllowOverride की जांच करवाएं, क्योंकि यह बंद होने पर Apache सही फाइल को भी नज़रअंदाज़ करता है।

आपके अपने रूल्स और WordPress का ब्लॉक

कोई प्लगइन या मैन्युअल एडिट अपने रूल्स जोड़ सकता है, जैसे रीडायरेक्ट, हॉटलिंक सुरक्षा या कैशिंग हेडर। इन्हें WordPress के ब्लॉक से बाहर और उसके ऊपर रखें, ताकि ये उसके कैच-ऑल रूल से पहले चलें:

# Rules you or a plugin added: ABOVE the WordPress markers
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # example: hotlink protection, caching rules, etc.
</FilesMatch>

# BEGIN WordPress
<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

# BEGIN WordPress और # END WordPress के बीच रखी कोई भी चीज़ अगली बार WordPress के फाइल अपडेट करने पर खो जाती है, और इसके लिए Permalinks स्क्रीन लोड करना ही काफी है। मार्करों से पहले और बाद की लाइनें बनी रहती हैं। रीडायरेक्ट के लिए, WordPress .htaccess रीडायरेक्ट रूल्स सही तरीके से देखें कि वे कहां होने चाहिए और लूप से कैसे बचें।

फाइल एडिट करने के ठीक बाद 500 Internal Server Error आपके अभी किए बदलाव की ओर इशारा करता है। Apache का डॉक्यूमेंटेशन कहता है कि एरर लॉग संभवतः ऐसे डायरेक्टिव का नाम बताएगा जिसकी अनुमति नहीं है, या सिंटैक्स एरर बताएगा। किसी पुराने ट्यूटोरियल से कॉपी किए रूल्स ऐसा कर सकते हैं: Order Apache 2.4 पर अमान्य कमांड है, जब तक mod_access_compat लोड न हो। साइट वापस लाने के लिए एडिट को पलटें, फिर एरर लॉग पढ़ें।

डिफॉल्ट ब्लॉक से आगे

डिफॉल्ट ब्लॉक सिर्फ परमालिंक रूटिंग और Authorization हेडर संभालता है। संवेदनशील फाइलों तक पहुंच सख्त करने के लिए, जैसे /uploads में PHP चलने से रोकना या wp-config.php की सीधी रिक्वेस्ट को नकारना, WordPress .htaccess सुरक्षा रूल्स जो वाकई मदद करते हैं देखें। अगर परमालिंक्स किसी और वजह से 404 दे रहे हैं, जैसे गलत परमालिंक स्ट्रक्चर, पुराने रूल्स देने वाली कैशिंग लेयर, या मल्टीसाइट सबडायरेक्टरी का टकराव, तो WordPress परमालिंक्स काम नहीं कर रहे बाकी कारण बताता है।

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

WordPress की डिफॉल्ट .htaccess फाइल क्या है? यह वह RewriteEngine ब्लॉक है जिसे WordPress आपकी साइट के रूट की .htaccess फाइल में # BEGIN WordPress और # END WordPress के बीच लिखता है। यह Authorization हेडर को PHP तक पहुंचाता है और हर उस रिक्वेस्ट को index.php पर भेजता है जो असली फाइल या फोल्डर नहीं है।

WordPress का सटीक डिफॉल्ट .htaccess कोड क्या है? RewriteEngine On, एक रूल जो Authorization हेडर को PHP तक पहुंचाता है, RewriteBase /, index.php के लिए एक पास-थ्रू रूल, दो शर्तें जो जांचती हैं कि रिक्वेस्ट असली फाइल या फोल्डर नहीं है, और एक अंतिम रूल जो बाकी सब कुछ index.php पर भेजता है। पूरा ब्लॉक इस गाइड में सबसे ऊपर है।

होमपेज को छोड़कर मेरी सभी पोस्ट्स 404 क्यों दिखा रही हैं? Apache पर गायब या खराब .htaccess फाइल से यही पैटर्न बनता है। सर्वर को होमपेज rewrite rules के बिना मिल जाता है। बाकी हर परमालिंक को index.php तक पहुंचने के लिए इन रूल्स की ज़रूरत होती है, इसलिए इनके बिना Apache ऐसी फाइल ढूंढता है जो मौजूद नहीं है और 404 लौटाता है।

क्या WordPress .htaccess को अपने आप फिर से बनाता है? हां, mod_rewrite वाले Apache या LiteSpeed पर, अगर प्रीटी परमालिंक्स चालू हों और WordPress वहां लिख सके। Settings > Permalinks खोलना ही काफी है। गायब फाइल के लिए फोल्डर writable होना चाहिए, और मौजूदा फाइल खुद writable होनी चाहिए। वरना स्क्रीन एक एरर दिखाती है, साथ में वे रूल्स भी जिन्हें आपको खुद पेस्ट करना होगा।

nginx में WordPress की .htaccess फाइल क्यों नहीं होती? nginx में Apache की .htaccess जैसी डायरेक्टरी-लेवल कॉन्फिगरेशन फाइल नहीं होती। वही रूटिंग nginx के सर्वर कॉन्फिगरेशन में try_files रूल के रूप में लिखी जाती है, जिसे एडमिनिस्ट्रेटर को एडिट करना पड़ता है क्योंकि WordPress इसे बदल नहीं सकता।

परमालिंक्स सेव करने के बाद मेरी .htaccess क्यों टूट गई? जांचें कि कोई कस्टम रूल # BEGIN WordPress और # END WordPress मार्करों के अंदर तो नहीं रखा गया था। WordPress फाइल अपडेट करते समय इनके बीच की हर चीज़ बदल देता है, इसलिए वह रूल खो जाता है। कस्टम रूल्स मार्करों के ऊपर रखें।

स्रोत

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• WordPress का सोर्स कोड: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

मुफ्त WordPress .htaccess जनरेटर से एक साफ और सही .htaccess फिर से बनाएं, जिसमें डिफॉल्ट परमालिंक ब्लॉक के साथ वे सुरक्षा या रीडायरेक्ट रूल्स हों जिनकी आपको सच में ज़रूरत है।