اصلاح فایل htaccess در وردپرس زمانی مفید است که مشکل به قواعد وب‌سرور مربوط باشد؛ هر خطای 404، صفحهٔ سفید یا اختلال ورود از این فایل ناشی نمی‌شود. ابتدا نشانهٔ خطا، آخرین تغییر و نوع وب‌سرور را مشخص کنید. جایگزینی کل فایل با یک نمونهٔ عمومی ممکن است ریدایرکت‌های مهم یا تنظیمات امنیتی را حذف کند.
آیا سایت شما از htaccess استفاده می‌کند؟
این فایل برای تنظیمات پوشه‌ای Apache و بعضی محیط‌های سازگار کاربرد دارد. در Nginx مستقل، ساختن .htaccess قواعد مسیریابی را فعال نمی‌کند. اگر Nginx جلوی Apache قرار دارد، نقش هر لایه را از پشتیبانی سرویس بپرسید.
طبق مستند Apache، مجازبودن دستورها به AllowOverride و AllowOverrideList وابسته است. دستور نامعتبر یا غیرمجاز می‌تواند خطای 500 بدهد؛ نادیده‌گرفته‌شدن فایل نیز ممکن است ناشی از تنظیم سرور باشد. برای جبران، دستورهای بیشتری را تصادفی اضافه نکنید.
پیداکردن فایل صحیح در هاست
- ریشهٔ واقعی دامنه یا نصب وردپرس را در پنل هاست مشخص کنید؛ همیشه public_html نیست.
- File Manager را باز و نمایش فایل‌های مخفی را فعال کنید.
- فایل دقیقاً با نام .htaccess را پیدا کنید؛ htaccess.txt همان فایل نیست.
- پیش از ویرایش، نسخهٔ قبلی را در محل غیرعمومی نگه دارید.
- بلوک WordPress، قواعد افزونه‌ها و ریدایرکت‌های دستی را از هم تشخیص دهید.
اصلاح فایل htaccess در وردپرس از پیوندهای یکتا
اگر صفحهٔ اصلی باز می‌شود ولی نوشته‌های موجود 404 می‌شوند، تنظیمات ← پیوندهای یکتا را باز کنید و بدون تغییر ساختار نشانی، ذخیرهٔ تغییرات را بزنید. این کار قواعد بازنویسی وردپرس را بازسازی می‌کند. در محیط قابل‌نوشتن و سازگار، وردپرس می‌تواند بخش مربوط به خودش را در فایل به‌روز کند.
اگر پیام عدم امکان نوشتن دیده می‌شود، قواعد پیشنهادی همان نصب را بررسی کنید. راهنمای پیوندهای یکتا مبنای این تنظیم است. تغییر از نام نوشته به ساختار تاریخ‌دار، راه رفع خطا نیست و نشانی‌های قبلی را عوض می‌کند.
نمونهٔ قواعد پایه؛ فقط نصب تکی در ریشه
نمونهٔ زیر برای وردپرس تک‌سایته در ریشهٔ دامنه و با فعال‌بودن mod_rewrite است. آن را برای شبکهٔ چندسایته، نصب در زیرپوشه یا ساختار اختصاصی کپی نکنید؛ قواعد همان نصب مقدم‌اند. مرجع رسمی Apache و وردپرس نمونه‌های جداگانه دارد.
# BEGIN WordPress
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]
# END WordPressفقط بخش مربوط به وردپرس را با قواعد مناسب مقایسه کنید. دستورهای سفارشی را داخل بلوک تولیدشدهٔ WordPress نگذارید، چون ممکن است در بازسازی بعدی جایگزین شوند. ترتیب ریدایرکت‌ها نیز مهم است؛ یک قاعدهٔ عمومی می‌تواند مسیرهای اختصاصی بعدی را بی‌اثر کند.
رفع خطای 500 پس از ویرایش
اگر خطا بلافاصله پس از تغییر شروع شد، همان تغییر اخیر را برگردانید و لاگ وب‌سرور را در زمان خطا بخوانید. پیام‌هایی دربارهٔ دستور ناشناخته، مجازنبودن دستور یا حلقهٔ بازنویسی سرنخ متفاوتی دارند. حذف کل فایل، تشخیص دقیق محسوب نمی‌شود.
دستورهای PHP مانند php_value در همهٔ روش‌های اجرای PHP معتبر نیستند. تنظیم نسخه یا حافظه را از ابزار مناسب سرویس انجام دهید. خاموش‌کردن حفاظت یا حذف محدودیت دسترسی برای رسیدن به صفحهٔ بدون خطا، اصلاح کامل نیست.
سطح دسترسی و بررسی نتیجه
برای قابل‌نوشتن‌کردن فایل سراغ 666 یا 777 نروید. مالکیت و روش اجرای سرویس تعیین می‌کنند چه دسترسی‌ای لازم است؛ 644 در بسیاری از محیط‌ها رایج است، اما نسخهٔ عمومی برای همه نیست. راهنمای امن‌سازی وردپرس بر دسترسی متناسب با مالکیت تأکید می‌کند.
- یک نوشتهٔ قدیمی، صفحهٔ اصلی و ورود مدیریت را باز کنید.
- ریدایرکت‌های مهم را از نظر مقصد و حلقه بررسی کنید.
- مطمئن شوید فایل‌های خصوصی همچنان عمومی نشده‌اند.
- اگر کش خطای قبلی را نگه داشته، همان لایهٔ مربوط را پاک کنید.
بازشدن یک صفحه کافی نیست؛ اصلاح باید مسیرهای قبلی و قواعد ضروری سایت را حفظ کند.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
