WordPress की डिफॉल्ट .htaccess फाइल: इसमें क्या है और इसे कैसे बहाल करें

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

यह वही सटीक ब्लॉक है, जो Apache HTTP Server पर WordPress की आधिकारिक गाइड और सुंदर परमालिंक्स पर HelpHub पेज में दर्ज rewrite लॉजिक से लिया गया है। यदि आपका RewriteBase / नहीं है — उदाहरण के लिए क्योंकि WordPress किसी सबफोल्डर में इंस्टॉल है — तो यह उस पाथ से मैच करेगा, और यह भी सामान्य है, जिसे WordPress खुद बनाता है।

मुख्य बातें

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

फाइल को अपने असली पाथ और कुछ अतिरिक्त नियमों के साथ फिर से बनाने की ज़रूरत है? WordPress .htaccess जेनरेटर सीधे आपके ब्राउज़र में एक सही फाइल तैयार कर देता है।

हर लाइन क्या करती है

RewriteEngine On इस डायरेक्टरी के लिए Apache के mod_rewrite मॉड्यूल को ऑन करता है; इस लाइन के बिना आगे की हर चीज़ निष्क्रिय है।

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

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

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

RewriteRule . /index.php [L] वह है जो परमालिंक्स को काम करने लायक बनाता है: पिछली दोनों शर्तों से बचा हुआ कुछ भी — यानी जो असली फाइल या फोल्डर नहीं है — index.php पर भेजा जाता है, और WordPress की अपनी रूटिंग (WP_Query, rewrite टैग्स) फैसला करती है कि वह URL वास्तव में कौन सी पोस्ट, पेज या आर्काइव है।

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

WordPress हर बार जब आप Settings > Permalinks खोलते हैं और Save Changes पर क्लिक करते हैं, तो वह खुद .htaccess लिखने की कोशिश करता है, चाहे स्क्रीन पर कुछ न बदला हो। यह सेव flush_rewrite_rules() को चलाता है, जो .htaccess को लिखने के लिए खोलने और मार्करों के बीच मौजूदा ब्लॉक डालने की कोशिश करता है।

यह कोशिश चुपचाप विफल हो जाती है, फाइल को गायब या पुरानी छोड़ देती है, जब:

• फाइल या उसका पेरेंट फोल्डर उस यूज़र के लिए writable नहीं है जिस पर PHP चलता है। कई शेयर्ड होस्टिंग पर, PHP एक अलग सिस्टम यूज़र के रूप में चलता है जो FTP से फाइलें अपलोड करने वाले यूज़र से भिन्न होता है, इसलिए FTP क्लाइंट में सही दिखने वाली परमिशन भी WordPress की लिखाई को रोक सकती हैं।
• आप nginx पर हैं। .htaccess केवल Apache और LiteSpeed का मैकेनिज्म है (खुद AllowOverride पर Apache का दस्तावेज़ीकरण बताता है क्यों: nginx के पास हर डायरेक्टरी के लिए कोई कॉन्फ़िगरेशन फाइल नहीं होती जिसे वह हर रिक्वेस्ट पर फिर से पढ़े)। nginx पर इसका समकक्ष server ब्लॉक के भीतर एक try_files डायरेक्टिव है, जिसे केवल सर्वर एक्सेस रखने वाला व्यक्ति ही एडिट कर सकता है; WordPress इसे आपके लिए कभी नहीं लिख सकता।
• मुख्य Apache कॉन्फ़िगरेशन में आपकी साइट की डायरेक्टरी के लिए AllowOverride को None पर सेट किया गया है। यह वह सेटिंग है जो .htaccess को कुछ भी ओवरराइड करने की अनुमति देती है; Apache का दस्तावेज़ीकरण स्पष्ट है: AllowOverride None के साथ, “.htaccess फाइलों को पूरी तरह नज़रअंदाज़ किया जाता है” — WordPress एक परफेक्ट फाइल लिख सकता है, और यह तब तक बेअसर रहेगी जब तक यह सेटिंग सर्वर स्तर पर न बदली जाए।
• फाइल डिलीट हो गई या कभी मौजूद ही नहीं थी, और सेव में कुछ ऐसा हुआ जिसने पुनर्निर्माण को ट्रिगर नहीं किया — सबसे सामान्य कारण यह है कि परमालिंक संरचना पहले से ही वैसी ही थी, इसलिए WordPress को फिर से लिखने के लिए कोई बदलाव नहीं दिखा।

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

यदि पोस्ट्स और पेज 404 दे रहे हैं जबकि होमपेज अभी भी काम कर रहा है, तो यह गायब या टूटी हुई .htaccess का विशिष्ट संकेत है। इसे दो चरणों में ठीक करें।

1. पहले एक-क्लिक समाधान आज़माएं। WordPress डैशबोर्ड में Settings > Permalinks पर जाएं और कुछ भी बदले बिना Save Changes पर क्लिक करें। यदि फाइल writable है, तो यह अकेला ही इसे फिर से बना देता है और काम हो जाता है।

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

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

यदि इसके बाद भी 404 आ रहा है, तो कारण “.htaccess गायब है” से बदल कर “.htaccess को नज़रअंदाज़ किया जा रहा है” हो गया है — अपने होस्ट से AllowOverride के बारे में पूछें, क्योंकि एक सही फाइल भी ऐसी डायरेक्टरी में, जहां Apache को इसे नज़रअंदाज़ करने का आदेश है, बिल्कुल वैसा ही व्यवहार करती है जैसे फाइल ही न हो।

आपके अपने नियम बनाम WordPress का ब्लॉक

कोई प्लगइन या मैन्युअल एडिट अपने नियम जोड़ सकता है — रीडायरेक्ट, हॉटलिंक प्रोटेक्शन, कैश हेडर। यह WordPress द्वारा बनाए गए ब्लॉक से अलग, एक स्वतंत्र ब्लॉक है, और इन दोनों को कभी ओवरलैप नहीं होना चाहिए:

# आपके या किसी प्लगइन द्वारा जोड़े गए नियम — WordPress मार्करों के ऊपर
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # उदाहरण: हॉटलिंक प्रोटेक्शन, कैश नियम, आदि।
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

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

यह फाइल को एडिट करने के ठीक बाद अचानक आने वाले 500 Internal Server Error का भी सबसे सामान्य कारण है: किसी फोरम पोस्ट से कॉपी किया गया नियम जो Apache के किसी अलग वर्ज़न के लिए लिखा गया था (2.2 का Order/Deny सिंटैक्स 2.4 के Require सिंटैक्स के साथ मिल जाना) पूरी फाइल के पार्सिंग को तोड़ देता है, जिसमें नीचे का WordPress ब्लॉक भी शामिल है, और पूरी साइट डाउन हो जाती है — न कि सिर्फ वह हिस्सा जिसे आपने छेड़ा था।

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

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

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

WordPress की डिफॉल्ट .htaccess फाइल क्या है? यह वह RewriteEngine ब्लॉक है जिसे WordPress # BEGIN WordPress और # END WordPress के बीच लिखता है ताकि परमालिंक्स 404 देने के बजाय index.php पर रिज़ॉल्व हो जाएं।

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

होमपेज को छोड़कर मेरी सभी पोस्ट्स 404 क्यों दिखा रही हैं? होमपेज को किसी भी rewrite rule के बिना ढूंढा जा सकता है; किसी भी अन्य परमालिंक को इनकी ज़रूरत होती है। Apache पर गायब या खराब .htaccess ठीक यही पैटर्न बनाता है।

क्या WordPress .htaccess को अपने आप फिर से बनाता है? केवल तभी जब फाइल writable हो — Settings > Permalinks को फिर से सेव करना इसे ट्रिगर करता है। यदि फाइल writable नहीं है, किसी ऐसे होस्ट पर गायब है जो इसे अपने आप नहीं बनाता, या AllowOverride बंद है, तो WordPress इसे आपके लिए ठीक नहीं कर सकता और आपको फाइल को मैन्युअली बनाना या सही करना होगा।

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

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

---

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