WordPress پوسٹس 404 دیتی ہیں مگر ہوم پیج ٹھیک چلتا ہے
اگر آپ کا ہوم پیج تو بالکل ٹھیک کھلتا ہے مگر ہر انفرادی پوسٹ اور پیج 404 دیتا ہے، تو اس کا مطلب ہے کہ WordPress جن URL rewrite rules پر انحصار کرتا ہے وہ آپ کی فائل میں موجود نہیں یا خراب ہیں
شائع شدہ
اگر آپ کا ہوم پیج تو ٹھیک لوڈ ہوتا ہے مگر ہر انفرادی پوسٹ اور پیج 404 دیتا ہے، تو WordPress جن URL rewrite rules پر انحصار کرتا ہے وہ آپ کی .htaccess فائل میں یا تو موجود نہیں یا خراب ہو چکی ہیں۔ سب سے تیز حل: wp-admin میں Settings → Permalinks پر جائیں اور کچھ بھی تبدیل کیے بغیر Save Changes پر کلک کریں۔ یہ WordPress کو مجبور کر دیتا ہے کہ وہ rewrite block دوبارہ بنائے۔ اگر پھر بھی 404 برقرار رہے، تو اس کا مطلب ہے کہ آپ کی .htaccess ویب سرور کے لیے writable نہیں، یا Apache اسے نظر انداز کرنے کے لیے configure ہے، یا آپ Nginx پر ہیں (جو .htaccess استعمال ہی نہیں کرتا)۔
ہوم پیج کیوں چلتا ہے مگر پوسٹس کیوں نہیں
آپ کا ہوم پیج اس لیے چلتا ہے کیونکہ / کی درخواست سیدھی document root پر موجود index.php سے پوری کر دی جاتی ہے۔ کسی rewriting کی ضرورت نہیں پڑتی۔
/2026/my-post/ کی درخواست اس سے مختلف ہے۔ یہ path ڈسک پر کوئی حقیقی فولڈر نہیں ہے۔ WordPress کے لیے اس کا جواب دینے کی خاطر Apache کو درخواست کو اندرونی طور پر index.php کی طرف route کرنا پڑتا ہے، پھر WordPress REQUEST_URI پڑھتا ہے، اسے ڈیٹابیس میں موجود rewrite_rules آپشن کے rewrite rules سے match کرتا ہے، query vars حل کرتا ہے (WP::parse_request())، اور درست پوسٹ لوڈ کرتا ہے۔
Apache سے index.php تک یہ منتقلی ہی وہ حصہ ہے جو ٹوٹتا ہے۔ یہ مکمل طور پر .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 تک درخواست پہنچنے سے بھی پہلے۔
جب آپ permalinks محفوظ کرتے ہیں تو WordPress .htaccess کو کیوں دوبارہ لکھ دیتا ہے
یہ وہ حصہ ہے جسے اکثر گائیڈز چھوڑ دیتی ہیں۔ جب آپ Permalinks اسکرین پر Save پر کلک کرتے ہیں، تو WordPress flush_rewrite_rules() کو کال کرتا ہے۔ writable .htaccess والے Apache پر یہ save_mod_rewrite_rules() کو چلاتا ہے، جو WP_Rewrite::mod_rewrite_rules() کے ذریعے اوپر والا block دوبارہ بناتا ہے اور insert_with_markers() کے ذریعے واپس لکھ دیتا ہے۔
insert_with_markers() صرف # BEGIN WordPress اور # END WordPress کے درمیان والی لائنوں کو چھوتا ہے۔ ان markers سے باہر کی ہر چیز جوں کی توں رہتی ہے۔ اندر کی ہر چیز مٹا کر نئے سرے سے لکھ دی جاتی ہے۔ نئے WordPress ورژنز تو یہ تنبیہ سیدھی فائل کے اندر ہی لکھ دیتے ہیں:
Any changes to the directives between these markers will be overwritten.
تو یہ کہنا کہ “WordPress میری .htaccess کو دوبارہ لکھ دیتا ہے” درست تو ہے مگر محدود معنوں میں: یہ صرف اپنے marked block کو دوبارہ لکھتا ہے، اور صرف تب جب فائل writable ہو۔ اگر فائل writable نہ ہو، تو save خاموشی سے ڈسک پر کچھ نہیں کرتا۔ WordPress، Permalinks اسکرین پر ایک زرد نوٹس دکھاتا ہے جو آپ کو rules خود دستی طور پر paste کرنے کا کہتا ہے، اور اگر آپ سے وہ نوٹس نظرانداز ہو جائے، تو آپ کا rewrite block غائب رہتا ہے اور ہر پوسٹ 404 دیتی رہتی ہے۔
اسے کیسے ٹھیک کریں، ترتیب سے
1. اپنے permalinks دوبارہ محفوظ کریں۔ Settings → Permalinks → Save Changes۔ کسی ترمیم کی ضرورت نہیں۔ یہ flush دوبارہ چلاتا ہے اور block کو دوبارہ لکھ دیتا ہے۔ یہ زیادہ تر معاملات حل کر دیتا ہے، بشمول migration کے بعد پرانے پڑ چکے rules۔
2. تصدیق کریں کہ .htaccess موجود ہے اور writable ہے۔ یہ اُسی فولڈر میں رہتی ہے جہاں wp-config.php ہوتی ہے۔ یہ ایک dotfile ہے، تو اپنے FTP کلائنٹ میں “show hidden files” آن کریں یا یہ استعمال کریں:
ls -la /path/to/wordpress/.htaccess
اگر یہ غائب ہو، تو اسے بنائیں اور درست block paste کریں۔ اگر آپ کی install کسی subdirectory میں ہو، تو RewriteBase اور آخری rewrite target کو اُس path سے میل کھانا چاہیے — اسے غلط کرنا سب سے عام وجہ ہے کہ خود paste کیا گیا block پھر بھی 404 دیتا ہے۔ ہمارا .htaccess generator آپ کے install path کے لیے بالکل درست block بنا دیتا ہے تاکہ آپ کو اندازے نہ لگانے پڑیں۔
3. تصدیق کریں کہ Apache کو .htaccess پڑھنے کی اجازت ہے۔ اگر virtual host میں AllowOverride None ہو، تو Apache فائل کے مواد سے قطع نظر اسے مکمل طور پر نظر انداز کر دیتا ہے۔ آپ کو WordPress directory پر AllowOverride All (یا کم از کم FileInfo) چاہیے۔ یہ سرور config میں ہوتا ہے، .htaccess میں نہیں، اس لیے اس کے لیے سرور تک رسائی درکار ہے:
<Directory /var/www/html>
AllowOverride All
</Directory>
4. تصدیق کریں کہ mod_rewrite فعال ہے۔ Debian/Ubuntu پر:
sudo a2enmod rewrite
sudo systemctl restart apache2
5. Nginx پر کوئی .htaccess نہیں ہوتی۔ Rewrites اس کے بجائے server block میں جاتے ہیں:
location / {
try_files $uri $uri/ /index.php?$args;
}
فوری تشخیص: یہ 404 کس کا ہے؟
404 پیج کو دیکھیں۔ اگر یہ کوئی بغیر اسٹائل والا Apache یا ہوسٹ ایرر پیج ہو، تو Apache WordPress تک پہنچا ہی نہیں — یہ .htaccess یا سرور config کا مسئلہ ہے (مراحل 2–4)۔ اگر یہ آپ کی تھیم کا اسٹائل شدہ 404 ہو، تو WordPress درخواست تو وصول کر رہا ہے مگر اسے match نہیں کر پا رہا — ڈیٹابیس کے rules پرانے پڑ چکے ہیں، اور permalinks دوبارہ محفوظ کرنا (مرحلہ 1) ہی حل ہے۔ یہ ایک فرق ہی زیادہ تر لوگوں کا ایک گھنٹہ اندازے لگانے سے بچا لیتا ہے۔
کیا نہ کریں
سب سے پہلے اپنے سارے plugin غیر فعال نہ کریں۔ خالص “پوسٹس 404، ہوم پیج ٹھیک” والی علامت ایک rewrite مسئلہ ہے، plugin کا ٹکراؤ نہیں۔ plugin بند کرنا فورمز پر پہلا reflex جواب ہوتا ہے مگر یہ تقریباً کبھی اس مسئلے کو نہیں چھوتا۔
اپنی .htaccess پر chmod 777 نہ کریں۔ WordPress کو فائل کا ویب سرور یوزر کے لیے writable ہونا درکار ہے، جو world-writable ہونے سے مختلف بات ہے۔ درست owner کے ساتھ 644 بالکل ٹھیک اور محفوظ ہے؛ 777 ایک سیکیورٹی سوراخ ہے جو routing کو ویسے بھی ٹھیک نہیں کرے گا۔
اپنے custom rewrite rules کو # BEGIN WordPress / # END WordPress markers کے اندر paste نہ کریں۔ اگلی بار جب بھی کوئی permalinks محفوظ کرے گا وہ مٹ جائیں گے۔ اپنے custom directives کو # BEGIN WordPress لائن سے اوپر رکھیں۔
WordPress دوبارہ install نہ کریں۔ core فائلیں ٹھیک ہیں۔ یہ متن کا ایک غائب block ہے، کوئی خراب install نہیں۔
اپنی تھیم کو الزام نہ دیں۔ Permalink routing، WordPress core کا حصہ ہے۔ کوئی تھیم نہ اسے پیدا کر سکتی ہے نہ ٹھیک کر سکتی ہے۔
اب بھی پھنسے ہوئے ہیں؟
اگر آپ permalinks دوبارہ محفوظ کر چکے ہیں، تصدیق کر چکے ہیں کہ block موجود اور writable ہے، اور AllowOverride All سیٹ کر چکے ہیں، تو باقی مشتبہ چیز یا تو کوئی سیکیورٹی plugin ہے یا کوئی ہوسٹ لیول rule جو آپ کی جانکاری کے بغیر .htaccess کو دوبارہ بنا یا lock کر رہا ہے۔ permalink save کے فوراً بعد فائل کا modification timestamp چیک کریں — اگر وہ تبدیل نہیں ہوا، تو کوئی چیز write کو روک رہی ہے۔ .htaccess generator سے ایک صاف block دوبارہ بنائیں، اسے paste کریں، اور hard refresh کے ساتھ دوبارہ ٹیسٹ کریں۔