ورڈپریس کی ڈیفالٹ htaccess. فائل: اس میں کیا ہے اور اسے کیسے بحال کریں

ورڈپریس کی ڈیفالٹ .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 کے بارے میں ورڈپریس کی سرکاری گائیڈ اور خوبصورت مستقل لنکس کے بارے میں HelpHub صفحے میں دستاویز شدہ rewrite منطق سے لیا گیا ہے۔ اگر آپ کا RewriteBase / نہیں ہے — مثلاً کیونکہ ورڈپریس کسی سب فولڈر میں انسٹال ہے — تو یہ اس کے بجائے اس راستے سے میچ کرے گا، اور یہ بھی اتنا ہی نارمل ہے اور خود ورڈپریس کا بنایا ہوا ہے۔

اہم نکات

• ورڈپریس یہ بلاک خودکار طور پر، صرف Apache اور LiteSpeed پر، ہر بار بناتا ہے جب فائل قابل تحریر ہو اور آپ سیٹنگز > مستقل لنکس محفوظ کریں۔
• اگر فائل غائب ہو یا خراب ہو، تو ہوم پیج کے سوا تمام مستقل لنکس 404 واپس کرتے ہیں، کیونکہ rewrite rules کے بغیر صرف ہوم پیج ہی تلاش کیا جا سکتا ہے۔
• آپ یا کوئی پلگ ان جو کچھ بھی شامل کریں وہ # BEGIN WordPress کے اوپر ہونا چاہیے، کبھی مارکرز کے اندر نہیں — ورڈپریس ہر مستقل لنک محفوظ کرنے پر ان کے درمیان موجود ہر چیز کو دوبارہ لکھتا ہے۔

فائل کو اپنے حقیقی راستے اور کچھ اضافی رولز کے ساتھ دوبارہ بنانے کی ضرورت ہے؟ ورڈپریس htaccess. جنریٹر براہ راست آپ کے براؤزر میں ایک درست فائل تیار کر دیتا ہے۔

ہر لائن کیا کرتی ہے

RewriteEngine On اس ڈائریکٹری کے لیے Apache کے mod_rewrite ماڈیول کو فعال کرتی ہے؛ اس لائن کے بغیر نیچے کی ہر چیز غیر فعال ہے۔

RewriteBase / Apache کو بتاتی ہے کہ دوبارہ لکھے گئے راستے سائٹ کے روٹ کے نسبت ہیں۔ ورڈپریس اسے اس کے مطابق سیٹ کرتا ہے کہ سائٹ حقیقت میں کہاں موجود ہے — سب فولڈر میں انسٹالیشن کو / کے بجائے RewriteBase /blog/ ملتا ہے۔

RewriteRule ^index\.php$ - [L] ایک بے اثر محافظ ہے: اگر درخواست پہلے سے ہی index.php ہے، تو rewrite رک جاتا ہے اور درخواست بغیر تبدیلی کے گزر جاتی ہے۔

دو RewriteCond لائنیں اصل منطق ہیں۔ %{REQUEST_FILENAME} !-f اور !-d پوچھتی ہیں کہ “کیا یہ درخواست کسی حقیقی فائل سے میچ نہیں کرتی، اور کسی حقیقی ڈائریکٹری سے میچ نہیں کرتی؟”۔ آخری رول کے فعال ہونے کے لیے دونوں کا سچ ہونا ضروری ہے — اس طرح ایک حقیقی تصویر، CSS فائل، یا اپ لوڈ کی گئی PDF براہ راست فراہم کی جاتی ہے اور کبھی ورڈپریس کی روٹنگ کو نہیں چھوتی۔

RewriteRule . /index.php [L] وہ چیز ہے جو مستقل لنکس کو کام کرنے دیتی ہے: پچھلی دو شرائط سے بچ جانے والی ہر چیز — یعنی جو حقیقی فائل یا فولڈر نہیں — index.php کی طرف بھیجی جاتی ہے، اور ورڈپریس کی اپنی روٹنگ (WP_Query، rewrite ٹیگز) فیصلہ کرتی ہے کہ یہ URL دراصل کون سی پوسٹ، صفحہ، یا آرکائیو ہے۔

ورڈپریس اس فائل کو کب دوبارہ بناتا ہے، اور کب نہیں بنا پاتا

ورڈپریس خود .htaccess لکھنے کی کوشش کرتا ہے ہر بار جب آپ سیٹنگز > مستقل لنکس کھولتے ہیں اور تبدیلیاں محفوظ کریں پر کلک کرتے ہیں، چاہے سکرین پر کچھ تبدیل نہ ہوا ہو۔ یہ سیو flush_rewrite_rules() کو متحرک کرتا ہے، جو .htaccess کو لکھنے کے لیے کھولنے اور موجودہ بلاک کو مارکرز کے درمیان داخل کرنے کی کوشش کرتا ہے۔

یہ کوشش خاموشی سے ناکام ہو جاتی ہے، فائل کو غائب یا پرانی چھوڑ کر، جب:

• فائل یا اس کا پیرنٹ فولڈر اس صارف کے لیے قابل تحریر نہ ہو جس کے ساتھ PHP چلتا ہے۔ بہت سے شیئرڈ ہوسٹنگز پر، PHP ایک مختلف سسٹم صارف کے طور پر چلتا ہے بمقابلہ وہ جس نے FTP کے ذریعے فائلیں اپ لوڈ کی تھیں، چنانچہ FTP کلائنٹ میں درست نظر آنے والی اجازتیں پھر بھی ورڈپریس کی تحریر کو روک سکتی ہیں۔
• آپ nginx استعمال کر رہے ہیں۔ .htaccess صرف Apache اور LiteSpeed کا میکانزم ہے (خود AllowOverride کے بارے میں Apache کی دستاویزات اس کی وجہ بتاتی ہیں: nginx کے پاس فی ڈائریکٹری کنفیگریشن فائل نہیں جو وہ ہر درخواست پر دوبارہ پڑھے)۔ nginx پر اس کا متبادل server بلاک کے اندر ایک try_files ہدایت ہے، جسے صرف سرور تک رسائی رکھنے والا شخص ترمیم کر سکتا ہے؛ ورڈپریس کبھی اسے آپ کے لیے نہیں لکھ سکتا۔
• آپ کی سائٹ کی ڈائریکٹری کے لیے مین Apache کنفیگریشن میں AllowOverride کو None پر سیٹ کیا گیا ہو۔ یہی وہ سیٹنگ ہے جو .htaccess کو کسی بھی چیز کو اوور رائیڈ کرنے کی اجازت دیتی ہے؛ Apache کی دستاویزات واضح ہیں: AllowOverride None کے ساتھ، “htaccess. فائلوں کو مکمل طور پر نظر انداز کیا جاتا ہے” — ورڈپریس ایک بے عیب فائل لکھ سکتا ہے، اور یہ اس وقت تک بے اثر رہے گی جب تک یہ سیٹنگ سرور کی سطح پر تبدیل نہ ہو۔
• فائل حذف کر دی گئی ہو یا کبھی موجود نہ رہی ہو، اور سیو کرنے کے دوران کچھ بھی دوبارہ بننے کو متحرک نہ کرے — سب سے عام وجہ یہ ہے کہ مستقل لنک کی ساخت پہلے سے ہی ایک جیسی تھی، چنانچہ ورڈپریس نے دوبارہ لکھنے کے لیے کوئی تبدیلی نہیں دیکھی۔

اسے دستی طور پر کیسے بحال کریں

اگر پوسٹس اور صفحات 404 دیتے ہیں جبکہ ہوم پیج اب بھی کام کر رہا ہے، تو یہ غائب یا خراب .htaccess کی مخصوص علامت ہے۔ اسے دو مراحل میں ٹھیک کریں۔

1. پہلے ایک کلک والا حل آزمائیں۔ ورڈپریس ڈیش بورڈ میں سیٹنگز > مستقل لنکس پر جائیں اور بغیر کچھ تبدیل کیے تبدیلیاں محفوظ کریں پر کلک کریں۔ اگر فائل قابل تحریر ہو، تو صرف یہی اسے دوبارہ بنا دیتا ہے اور کام ختم۔

2. اگر یہ کام نہ کرے، تو فائل کو دستی طور پر بنائیں۔ FTP/SFTP یا اپنے ہوسٹ کے فائل مینیجر کے ذریعے جڑیں، اس فولڈر میں جائیں جہاں ورڈپریس انسٹال ہے (وہی جس میں wp-config.php موجود ہے)، اور چیک کریں کہ .htaccess موجود ہے بھی یا نہیں — یہ ایک چھپی ہوئی فائل ہے، کچھ فائل مینیجرز اسے ڈیفالٹ طور پر چھپاتے ہیں؛ “چھپی ہوئی فائلیں دکھائیں” آن کریں۔

• اگر غائب ہو، تو بالکل .htaccess نام کی ایک نئی فائل بنائیں (نہ .txt، نقطے سے پہلے کچھ نہیں)۔
• اوپر دیا گیا ڈیفالٹ بلاک چپکائیں، اگر ورڈپریس سب فولڈر میں ہے تو RewriteBase کو ایڈجسٹ کریں۔
• محفوظ کریں اور کسی پوسٹ کے مستقل لنک کو دوبارہ لوڈ کریں تاکہ تصدیق ہو کہ یہ کام کر رہا ہے۔

اگر اس کے بعد بھی 404 آتا رہے، تو وجہ “.htaccess غائب ہے” سے بدل کر “.htaccess نظر انداز ہو رہی ہے” بن گئی ہے — اپنے ہوسٹ سے AllowOverride کے بارے میں پوچھیں، کیونکہ ایک درست فائل اس ڈائریکٹری میں جہاں Apache کو اسے نظر انداز کرنے کا حکم ہو، بالکل ویسا ہی رویہ اپناتی ہے جیسے فائل موجود ہی نہ ہو۔

آپ کے اپنے رولز بمقابلہ ورڈپریس کا بلاک

کوئی پلگ ان یا دستی ترمیم اپنے رولز شامل کر سکتی ہے — ری ڈائریکٹس، ہاٹ لنک پروٹیکشن، کیش ہیڈرز۔ یہ ورڈپریس کے بنائے گئے بلاک سے الگ اور مختلف بلاک ہے، اور ان دونوں کو کبھی اوورلیپ نہیں ہونا چاہیے:

# آپ یا کسی پلگ ان نے شامل کیے ہوئے رولز — ورڈپریس مارکرز کے اوپر
<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 کے درمیان رکھی گئی ہر چیز خاموشی سے حذف ہو جاتی ہے جب بھی کوئی اگلی بار مستقل لنکس اسکرین کو محفوظ کرے، کیونکہ ورڈپریس اس پورے حصے کو اپنا سمجھتا ہے اور اسے مکمل طور پر دوبارہ لکھتا ہے۔ یہ شکایت کی سب سے عام وجہ ہے کہ “میرا اپنا رول غائب ہو گیا” — یہ کبھی جانتے بوجھتے حذف نہیں کیا گیا، صرف ایک ایسے بلاک کے اندر تھا جسے ورڈپریس اپنا سمجھتا ہے۔ خاص طور پر ری ڈائریکٹس کے لیے، یہ جاننے کے لیے کہ وہ کہاں ہونے چاہییں اور loops سے کیسے بچیں، ورڈپریس htaccess. ری ڈائریکٹ رولز صحیح طریقے سے دیکھیں۔

یہ فائل میں ترمیم کرنے کے فوراً بعد اچانک 500 Internal Server Error آنے کی بھی سب سے عام وجہ ہے: کسی فورم پوسٹ سے کاپی کیا گیا رول جو کسی مختلف Apache ورژن کے لیے لکھا گیا تھا (2.2 کی Order/Deny سنٹیکس 2.4 کی Require سنٹیکس کے ساتھ مل جانا) پوری فائل کے parsing کو خراب کر دیتا ہے، بشمول نیچے موجود ورڈپریس بلاک کے، اور پوری سائٹ گر جاتی ہے — نہ کہ صرف وہ حصہ جسے آپ نے چھیڑا تھا۔

ڈیفالٹ بلاک سے آگے

ڈیفالٹ بلاک صرف مستقل لنک روٹنگ کو سنبھالتا ہے۔ اگر آپ حساس فائلوں تک رسائی کو سخت بھی کرنا چاہتے ہیں یا وہ چند .htaccess رولز شامل کرنا چاہتے ہیں جو واقعی حملے کی سطح کو کم کرتے ہیں — /uploads میں PHP ایگزیکیوشن بلاک کرنا، wp-config.php پر براہ راست درخواستیں مسترد کرنا — تو ورڈپریس htaccess. سیکیورٹی رولز جو واقعی مدد کرتے ہیں دیکھیں۔ اور اگر مستقل لنکس کسی دوسری وجہ سے 404 دیتے ہیں — غلط مستقل لنک ساخت، پرانے رولز فراہم کرنے والی کیشنگ لیئر، سب ڈائریکٹریز میں ملٹی سائٹ تنازعات — تو ورڈپریس مستقل لنکس جو کام نہیں کرتے دیگر وجوہات پر غور کرتا ہے۔

اکثر پوچھے جانے والے سوالات

ورڈپریس کی ڈیفالٹ htaccess. فائل کیا ہے؟ یہ وہ RewriteEngine بلاک ہے جو ورڈپریس # BEGIN WordPress اور # END WordPress کے درمیان لکھتا ہے تاکہ مستقل لنکس 404 دینے کے بجائے index.php کی طرف حل ہو جائیں۔

ورڈپریس کا درست ڈیفالٹ htaccess. کوڈ کیا ہے؟ RewriteEngine On، RewriteBase /، index.php کے لیے ایک پاس تھرو رول، دو شرائط جو چیک کرتی ہیں کہ درخواست حقیقی فائل یا ڈائریکٹری نہیں، اور ایک آخری رول جو باقی سب کچھ index.php کی طرف بھیجتا ہے۔ مکمل بلاک اس گائیڈ کے شروع میں دیا گیا ہے۔

ہوم پیج کے سوا میری تمام پوسٹس 404 کیوں دیتی ہیں؟ ہوم پیج کسی بھی rewrite rule کے بغیر تلاش کیا جا سکتا ہے؛ ہر دوسرے مستقل لنک کو ان کی ضرورت ہوتی ہے۔ Apache پر غائب یا خراب .htaccess بالکل یہی پیٹرن پیدا کرتا ہے۔

کیا ورڈپریس htaccess. کو خودکار طور پر دوبارہ بناتا ہے؟ صرف اس وقت جب فائل قابل تحریر ہو — سیٹنگز > مستقل لنکس کو دوبارہ محفوظ کرنا اسے متحرک کرتا ہے۔ اگر فائل قابل تحریر نہ ہو، کسی ایسے ہوسٹ پر غائب ہو جو اسے خودکار طور پر نہیں بناتا، یا AllowOverride بند ہو، تو ورڈپریس اسے آپ کے لیے ٹھیک نہیں کر سکتا اور آپ کو فائل کو دستی طور پر بنانا یا درست کرنا ہوگا۔

nginx میں ورڈپریس کی htaccess. فائل کیوں نہیں ہوتی؟ .htaccess صرف Apache اور LiteSpeed پر کام کرتی ہے۔ nginx کے پاس فی ڈائریکٹری کنفیگریشن فائل نہیں اور یہ .htaccess کو مکمل طور پر نظر انداز کرتا ہے؛ وہی روٹنگ nginx کے server بلاک میں try_files رول کے طور پر لکھی جاتی ہے۔

مستقل لنکس محفوظ کرنے کے بعد میری htaccess. کیوں خراب ہو گئی؟ ایک اپنا رول # BEGIN WordPress / # END WordPress مارکرز کے اوپر کے بجائے ان کے اندر رکھا گیا تھا، اور ورڈپریس نے اگلی بار مستقل لنکس محفوظ ہونے پر اس پورے حصے کو دوبارہ لکھ دیا۔

---

ایک صاف اور درست .htaccess بنائیں — ڈیفالٹ مستقل لنک بلاک کے ساتھ کوئی بھی سیکیورٹی یا ری ڈائریکٹ رولز جن کی آپ کو واقعی ضرورت ہے — مفت ورڈپریس htaccess. جنریٹر کے ساتھ۔