WordPress Posts पर 404 आ रहा है लेकिन Homepage चल रहा है
अगर आपका homepage तो ठीक से खुल रहा है लेकिन हर अलग post और page पर 404 आ रहा है, तो इसका मतलब है कि WordPress जिन URL rewrite rules पर निर्भर करता है वे आपके सर्वर में या तो गायब हैं या टूट गए हैं।
Published
अगर आपका homepage तो ठीक से खुल रहा है लेकिन हर अलग post और page पर 404 आ रहा है, तो WordPress जिन URL rewrite rules पर निर्भर करता है वे आपकी .htaccess फाइल में या तो गायब हैं या टूट गए हैं। सबसे तेज़ हल: wp-admin में Settings → Permalinks पर जाएं और बिना कुछ बदले सीधे Save Changes पर क्लिक कर दें। इससे WordPress rewrite block को दोबारा बना देता है। अगर फिर भी 404 आते रहें, तो या तो आपकी .htaccess वेब सर्वर के लिए writable नहीं है, या Apache इसे नज़रअंदाज़ करने के लिए configure किया गया है, या फिर आप Nginx पर हैं (जो .htaccess इस्तेमाल ही नहीं करता)।
Homepage क्यों चलता है लेकिन posts नहीं
आपका homepage इसलिए चलता है क्योंकि / पर आने वाली request सीधे document root की index.php से serve हो जाती है। किसी rewriting की ज़रूरत नहीं पड़ती।
/2026/my-post/ की request अलग मामला है। यह path डिस्क पर कोई असली फोल्डर नहीं है। WordPress इसका जवाब दे सके, इसके लिए Apache को request को internally index.php की तरफ भेजना पड़ता है, और फिर WordPress REQUEST_URI को पढ़ता है, उसे database में rewrite_rules option में स्टोर किए गए rewrite rules से match करता है, query vars को resolve करता है (WP::parse_request()), और सही post को लोड करता है।
Apache से index.php तक का यह handoff ही वह हिस्सा है जो टूटता है। यह पूरी तरह .htaccess के इस block पर निर्भर करता है:
# 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
ये दो RewriteCond लाइनें कहती हैं: अगर मांगा गया path कोई असली फाइल नहीं है (!-f) और कोई असली directory नहीं है (!-d), तो उसे index.php पर भेज दो। इस block को हटा दें और Apache एक असली /2026/my-post/ directory ढूंढने लगता है, नहीं मिलती, और अपना खुद का 404 लौटा देता है — WordPress तक request पहुंचने से पहले ही।
Permalinks सेव करने पर WordPress .htaccess को क्यों overwrite करता है
यह वह हिस्सा है जिसे ज़्यादातर guides छोड़ देती हैं। जब आप Permalinks स्क्रीन पर Save क्लिक करते हैं, तो WordPress flush_rewrite_rules() को कॉल करता है। writable .htaccess वाले Apache पर यह save_mod_rewrite_rules() को ट्रिगर करता है, जो ऊपर वाले block को WP_Rewrite::mod_rewrite_rules() के ज़रिए दोबारा बनाता है और insert_with_markers() से उसे वापस फाइल में लिख देता है।
insert_with_markers() सिर्फ # BEGIN WordPress और # END WordPress के बीच की लाइनों को ही छूता है। इन markers के बाहर की हर चीज़ जस की तस रहती है। अंदर की हर चीज़ हटाकर दोबारा लिखी जाती है। नए WordPress versions तो यह चेतावनी सीधे फाइल में भी छाप देते हैं:
Any changes to the directives between these markers will be overwritten.
तो “WordPress मेरी .htaccess overwrite कर देता है” यह सच है लेकिन सीमित अर्थ में: यह सिर्फ अपने खुद के marked block को ही दोबारा लिखता है, और सिर्फ तब जब फाइल writable हो। अगर फाइल writable नहीं है, तो सेव करने पर डिस्क पर चुपचाप कुछ नहीं होता। WordPress Permalinks स्क्रीन पर एक पीला notice दिखाता है जिसमें rules को manually paste करने को कहता है, और अगर आप वह notice चूक गए, तो आपका rewrite block गायब ही रहता है और हर post पर 404 आता रहता है।
इसे कैसे ठीक करें, क्रम से
1. अपने permalinks दोबारा सेव करें। Settings → Permalinks → Save Changes। किसी बदलाव की ज़रूरत नहीं। इससे flush दोबारा चलता है और block फिर से लिखा जाता है। यह ज़्यादातर मामलों को हल कर देता है, migration के बाद रह गए stale rules समेत।
2. जांचें कि .htaccess मौजूद है और writable है। यह उसी फोल्डर में रहती है जिसमें wp-config.php है। यह एक dotfile है, इसलिए अपने FTP client में “show hidden files” चालू करें या यह इस्तेमाल करें:
ls -la /path/to/wordpress/.htaccess
अगर यह गायब है, तो इसे बनाएं और सही block paste करें। अगर आपका install किसी subdirectory में है, तो RewriteBase और आखिरी rewrite target दोनों को उस path से match करना चाहिए — इसे गलत रखना ही सबसे आम वजह है जिससे हाथ से paste किया block फिर भी 404 देता है। हमारा .htaccess generator आपके install path के लिए बिल्कुल सही block बना देता है, ताकि आपको अंदाज़ा न लगाना पड़े।
3. पक्का करें कि Apache को .htaccess पढ़ने की अनुमति है। अगर virtual host में AllowOverride None है, तो Apache फाइल के अंदर चाहे कुछ भी हो, उसे पूरी तरह नज़रअंदाज़ कर देता है। आपको WordPress directory पर AllowOverride All (या कम से कम FileInfo) चाहिए। यह server config में होता है, .htaccess में नहीं, इसलिए इसके लिए server access चाहिए:
<Directory /var/www/html>
AllowOverride All
</Directory>
4. पक्का करें कि mod_rewrite enabled है। Debian/Ubuntu पर:
sudo a2enmod rewrite
sudo systemctl restart apache2
5. Nginx पर कोई .htaccess नहीं होती। rewrites इसके बजाय server block में जाते हैं:
location / {
try_files $uri $uri/ /index.php?$args;
}
झटपट diagnostic: 404 किसका है?
404 page को देखें। अगर यह बिना styling वाला Apache या host का error page है, तो Apache WordPress तक पहुंचा ही नहीं — यह .htaccess या server-config की समस्या है (steps 2–4)। अगर यह आपकी theme का styled 404 है, तो WordPress request तो पा रहा है लेकिन उसे match नहीं कर पा रहा — database के rules stale हैं, और permalinks दोबारा सेव करना (step 1) ही हल है। यह एक फर्क ही ज़्यादातर लोगों का एक घंटा अंदाज़ेबाज़ी में जाने से बचा लेता है।
क्या न करें
सबसे पहले अपने सारे plugins deactivate न करें। शुद्ध “posts पर 404, homepage चल रहा है” वाला लक्षण एक rewrite की समस्या है, plugin conflict नहीं। plugins बंद करना forums का reflex जवाब है और यह लगभग कभी इस समस्या को नहीं छूता।
अपनी .htaccess को chmod 777 न करें। WordPress को फाइल का web server user के लिए writable होना चाहिए, जो world-writable होने से अलग बात है। सही owner के साथ 644 ठीक और सुरक्षित है; 777 एक security छेद है जो वैसे भी routing को ठीक नहीं करेगा।
अपने custom rewrite rules को # BEGIN WordPress / # END WordPress markers के अंदर paste न करें। अगली बार जब कोई permalinks सेव करेगा, वे मिट जाएंगे। custom directives को # BEGIN WordPress लाइन के ऊपर रखें।
WordPress दोबारा install न करें। core files ठीक हैं। यह एक गायब text block की बात है, corrupt install की नहीं।
अपनी theme को दोष न दें। Permalink routing WordPress core का हिस्सा है। कोई theme न तो इसे पैदा कर सकती है और न ही ठीक कर सकती है।
अब भी अटके हुए हैं?
अगर आपने permalinks दोबारा सेव कर लिए, पक्का कर लिया कि block मौजूद और writable है, और AllowOverride All सेट कर दिया, तो बचा हुआ शक किसी security plugin या host-level rule पर जाता है जो आपके पीछे .htaccess को दोबारा बना रहा या lock कर रहा है। permalink सेव करने के तुरंत बाद फाइल का modification timestamp जांचें — अगर वह नहीं बदला, तो कुछ write को रोक रहा है। .htaccess generator से एक साफ block बनाएं, उसे paste करें, और hard refresh के साथ दोबारा test करें।