فایل htaccess. پیش‌فرض وردپرس: محتوا و روش بازیابی آن

فایل .htaccess پیش‌فرض وردپرس همان بلوک کوتاه RewriteEngine است که نرم‌افزار در فایل .htaccess ریشه سایت شما می‌نویسد، تا لینک‌های ثابتی مثل /2026/10/نام-نوشته/ به‌جای خطای 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 و منطق rewrite که در صفحه HelpHub درباره لینک‌های ثابت زیبا توضیح داده شده، گرفته شده است. اگر RewriteBase شما / نباشد — مثلاً چون وردپرس در یک زیرپوشه نصب شده — این بلوک به‌جای آن با همان مسیر مطابقت می‌کند، و این هم کاملاً عادی است و خود وردپرس آن را می‌سازد.

نکات کلیدی

• وردپرس این بلوک را به‌طور خودکار، تنها روی آپاچی و LiteSpeed، هر بار که فایل قابل نوشتن باشد و تنظیمات > لینک‌های ثابت را ذخیره کنید، می‌سازد.
• اگر فایل گم شده یا خراب باشد، همه لینک‌های ثابت به‌جز صفحه اصلی خطای 404 برمی‌گردانند، چون فقط صفحه اصلی بدون قوانین rewrite پیدا می‌شود.
• هر چیزی که شما یا یک افزونه اضافه می‌کنید باید بالای # BEGIN WordPress باشد، هرگز داخل نشانگرها — وردپرس هر بار که لینک‌های ثابت ذخیره می‌شوند، همه چیز بین آن‌ها را بازنویسی می‌کند.

نیاز دارید فایل را با مسیر واقعی خود و چند قانون اضافه بازسازی کنید؟ سازنده .htaccess وردپرس یک فایل درست مستقیماً در مرورگر شما می‌سازد.

هر خط چه می‌کند

RewriteEngine On ماژول mod_rewrite آپاچی را برای این دایرکتوری فعال می‌کند؛ بدون این خط، هر چیزی که بعد از آن می‌آید بی‌اثر است.

RewriteBase / به آپاچی می‌گوید که مسیرهای بازنویسی‌شده نسبت به ریشه سایت هستند. وردپرس این مقدار را متناسب با محل واقعی سایت تنظیم می‌کند — نصب در یک زیرپوشه مقدار RewriteBase /blog/ می‌گیرد، نه /.

RewriteRule ^index\.php$ - [L] یک محافظ بی‌اثر است: اگر درخواست از قبل index.php باشد، بازنویسی متوقف می‌شود و درخواست بدون تغییر عبور می‌کند.

دو خط RewriteCond منطق واقعی هستند. %{REQUEST_FILENAME} !-f و !-d می‌پرسند “آیا این درخواست با یک فایل واقعی مطابقت ندارد، و با یک دایرکتوری واقعی مطابقت ندارد؟”. هر دو باید درست باشند تا قانون نهایی فعال شود — به این ترتیب یک تصویر واقعی، فایل CSS، یا PDF آپلودشده مستقیماً تحویل داده می‌شود و هرگز با مسیریابی وردپرس برخورد نمی‌کند.

RewriteRule . /index.php [L] چیزی است که لینک‌های ثابت را کارآمد می‌کند: هر چیزی که از دو شرط قبلی جان سالم به در برده — یعنی فایل یا پوشه واقعی نیست — به index.php فرستاده می‌شود، و مسیریابی خود وردپرس (WP_Query، تگ‌های rewrite) تصمیم می‌گیرد که آن آدرس واقعاً کدام نوشته، صفحه یا آرشیو است.

چه زمانی وردپرس این فایل را دوباره می‌سازد، و چه زمانی نمی‌تواند

وردپرس هر بار که تنظیمات > لینک‌های ثابت را باز می‌کنید و روی ذخیره تغییرات کلیک می‌کنید، حتی اگر چیزی در صفحه تغییر نکرده باشد، خودش سعی می‌کند .htaccess را بنویسد. این ذخیره‌سازی تابع flush_rewrite_rules() را فعال می‌کند، که سعی می‌کند .htaccess را برای نوشتن باز کند و بلوک فعلی را بین نشانگرها قرار دهد.

این تلاش بی‌صدا شکست می‌خورد و فایل را گمشده یا قدیمی باقی می‌گذارد، وقتی که:

• فایل یا پوشه والد آن برای کاربری که PHP با آن اجرا می‌شود قابل نوشتن نباشد. در بسیاری از هاست‌های اشتراکی، PHP با کاربر سیستمی متفاوتی از کاربری که فایل‌ها را از طریق FTP آپلود کرده اجرا می‌شود، پس مجوزهایی که در یک کلاینت FTP درست به نظر می‌رسند، همچنان می‌توانند نوشتن وردپرس را مسدود کنند.
• شما روی nginx هستید. .htaccess فقط مکانیزمی مخصوص آپاچی و LiteSpeed است (خود مستندات آپاچی درباره AllowOverride دلیل آن را توضیح می‌دهد: nginx فایل پیکربندی به‌ازای هر دایرکتوری ندارد که با هر درخواست دوباره بخواند). معادل آن در nginx یک دستور try_files درون بلوک server است، که فقط کسی با دسترسی به سرور می‌تواند آن را ویرایش کند؛ وردپرس هرگز نمی‌تواند آن را برای شما بنویسد.
• AllowOverride روی None برای دایرکتوری سایت شما در پیکربندی اصلی آپاچی تنظیم شده باشد. این همان تنظیمی است که اصلاً به .htaccess اجازه می‌دهد چیزی را بازنویسی کند؛ مستندات آپاچی صریح است: با AllowOverride None، “فایل‌های htaccess. کاملاً نادیده گرفته می‌شوند” — وردپرس می‌تواند یک فایل بی‌نقص بنویسد، و همچنان بی‌اثر خواهد ماند تا این تنظیم در سطح سرور تغییر کند.
• فایل حذف شده یا هرگز وجود نداشته و چیزی در ذخیره‌سازی باعث بازسازی نشده — شایع‌ترین دلیل این است که ساختار لینک ثابت از قبل همان بوده، پس وردپرس هیچ تغییری برای بازنویسی ندیده است.

چگونه آن را دستی بازیابی کنیم

اگر نوشته‌ها و صفحات خطای 404 می‌دهند در حالی که صفحه اصلی همچنان کار می‌کند، این نشانه معمول یک .htaccess گمشده یا خراب است. آن را در دو مرحله برطرف کنید.

۱. ابتدا راه‌حل یک‌کلیکی را امتحان کنید. به تنظیمات > لینک‌های ثابت در پیشخوان وردپرس بروید و بدون تغییر هیچ چیزی، روی ذخیره تغییرات کلیک کنید. اگر فایل قابل نوشتن باشد، همین کافی است تا دوباره ساخته شود و کار تمام است.

۲. اگر این کار نکرد، فایل را دستی بسازید. از طریق FTP/SFTP یا مدیر فایل هاست خود وصل شوید، به پوشه‌ای که وردپرس در آن نصب شده (همانی که wp-config.php را دارد) بروید، و بررسی کنید که .htaccess اصلاً وجود دارد یا نه — این یک فایل مخفی است، برخی مدیرهای فایل آن را به‌طور پیش‌فرض پنهان می‌کنند؛ گزینه “نمایش فایل‌های مخفی” را فعال کنید.

• اگر وجود ندارد، یک فایل جدید دقیقاً با نام .htaccess بسازید (نه .txt، و هیچ چیز قبل از نقطه).
• بلوک پیش‌فرض بالا را بچسبانید، و اگر وردپرس در یک زیرپوشه است، RewriteBase را متناسب تنظیم کنید.
• ذخیره کنید و لینک ثابت یک نوشته را دوباره بار کنید تا مطمئن شوید کار می‌کند.

اگر بعد از این هم‌چنان خطای 404 بگیرید، دلیل از “.htaccess گمشده است” به “.htaccess نادیده گرفته می‌شود” تغییر کرده است — از هاست خود درباره AllowOverride بپرسید، چون یک فایل درست در دایرکتوری‌ای که آپاچی دستور دارد آن را نادیده بگیرد، دقیقاً مثل نبود فایل عمل می‌کند.

قوانین خودتان در برابر بلوک وردپرس

یک افزونه یا ویرایش دستی می‌تواند قوانین خودش را اضافه کند — ریدایرکت‌ها، محافظت از hotlink، هدرهای کش. این یک بلوک متفاوت و جداگانه از آن چیزی است که وردپرس می‌سازد، و این دو هرگز نباید با هم همپوشانی داشته باشند:

# قوانینی که شما یا یک افزونه اضافه کرده‌اید — بالای نشانگرهای وردپرس
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # نمونه: محافظت از hotlink، قوانین کش و غیره.
</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 قرار بگیرد، بار بعدی که کسی صفحه لینک‌های ثابت را ذخیره کند، بی‌صدا حذف می‌شود، چون وردپرس تمام آن بخش را مال خود می‌داند و کاملاً بازنویسی می‌کند. این شایع‌ترین دلیل شکایت “قانون خودم من ناپدید شد” است — هرگز عمداً حذف نشده، فقط داخل بلوکی بوده که وردپرس آن را مال خود می‌داند. برای ریدایرکت‌ها به‌طور خاص، قوانین ریدایرکت htaccess. وردپرس به روش درست را ببینید تا بدانید آن‌ها کجا باید باشند و چطور از حلقه‌ها جلوگیری کنید.

این همچنین شایع‌ترین دلیل یک خطای ناگهانی 500 Internal Server Error بلافاصله بعد از ویرایش فایل است: قانونی که از یک پست انجمن کپی شده که برای نسخه دیگری از آپاچی نوشته شده (نحو Order/Deny نسخه ۲.۲ که با نحو Require نسخه ۲.۴ مخلوط شده) تجزیه کل فایل را، از جمله بلوک وردپرس زیر آن، خراب می‌کند و کل سایت سقوط می‌کند — نه فقط بخشی که لمس کردید.

فراتر از بلوک پیش‌فرض

بلوک پیش‌فرض فقط مسیریابی لینک ثابت را مدیریت می‌کند. اگر همچنین می‌خواهید دسترسی به فایل‌های حساس را سخت‌تر کنید یا آن تعداد کم قوانین .htaccess که واقعاً سطح حمله را کاهش می‌دهند را اضافه کنید — مسدود کردن اجرای PHP در /uploads، رد کردن درخواست‌های مستقیم به wp-config.php — به قوانین امنیتی htaccess. وردپرس که واقعاً کمک می‌کنند نگاه کنید. و اگر لینک‌های ثابت به دلیل دیگری خطای 404 می‌دهند — ساختار لینک ثابت اشتباه، لایه کشی که قوانین قدیمی را تحویل می‌دهد، تعارض‌های چندسایتی در زیردایرکتوری‌ها — لینک‌های ثابت وردپرس که کار نمی‌کنند دلایل دیگر را بررسی می‌کند.

پرسش‌های پرتکرار

فایل htaccess. پیش‌فرض وردپرس چیست؟ این همان بلوک RewriteEngine است که وردپرس بین # BEGIN WordPress و # END WordPress می‌نویسد تا لینک‌های ثابت به‌جای خطای 404 به index.php حل شوند.

کد دقیق htaccess. پیش‌فرض وردپرس چیست؟ RewriteEngine On، RewriteBase /، یک قانون عبوری برای index.php، دو شرط که بررسی می‌کنند درخواست فایل یا دایرکتوری واقعی نیست، و یک قانون نهایی که بقیه موارد را به index.php می‌فرستد. بلوک کامل در ابتدای این راهنما آمده است.

چرا همه نوشته‌های من به جز صفحه اصلی خطای 404 می‌دهند؟ صفحه اصلی بدون هیچ قانون rewrite پیدا می‌شود؛ هر لینک ثابت دیگری به آن‌ها نیاز دارد. یک .htaccess گمشده یا خراب روی آپاچی دقیقاً همین الگو را تولید می‌کند.

آیا وردپرس htaccess. را به‌طور خودکار دوباره می‌سازد؟ فقط اگر فایل قابل نوشتن باشد — ذخیره دوباره تنظیمات > لینک‌های ثابت این را فعال می‌کند. اگر فایل قابل نوشتن نباشد، در هاستی که آن را به‌طور خودکار نمی‌سازد گم شده باشد، یا AllowOverride خاموش باشد، وردپرس نمی‌تواند این را برای شما درست کند و باید فایل را دستی بسازید یا اصلاح کنید.

چرا nginx فایل htaccess. وردپرس را ندارد؟ .htaccess فقط روی آپاچی و LiteSpeed کار می‌کند. nginx فایل پیکربندی به‌ازای هر دایرکتوری ندارد و .htaccess را کاملاً نادیده می‌گیرد؛ همان مسیریابی به‌صورت یک قانون try_files در بلوک server در nginx نوشته می‌شود.

چرا htaccess. من بعد از ذخیره لینک‌های ثابت خراب شد؟ یک قانون خاص داخل نشانگرهای # BEGIN WordPress / # END WordPress به‌جای بالای آن‌ها قرار گرفته بود، و وردپرس در ذخیره بعدی لینک‌های ثابت کل آن بخش را بازنویسی کرد.

---

یک .htaccess تمیز و درست بسازید — بلوک پیش‌فرض لینک ثابت به‌همراه هر قانون امنیتی یا ریدایرکتی که واقعاً نیاز دارید — با سازنده رایگان .htaccess وردپرس.