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

فایل .htaccess پیش‌فرض وردپرس همان بلوک کوتاه RewriteEngine است که این نرم‌افزار در فایل .htaccess ریشه سایت شما می‌نویسد تا لینک‌های یکتایی مانند /2026/10/post-name/ به‌جای خطای 404 کار کنند. ظاهر آن این است:

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

این قوانین از کدی می‌آیند که وردپرس برای ساختن این بلوک به کار می‌برد و با راهنمای .htaccess خود وردپرس مطابقت دارند. وردپرس همچنین درست بعد از # BEGIN WordPress سه خط توضیح می‌نویسد که هشدار می‌دهند ویرایش‌های بین نشانگرها بازنویسی خواهند شد. این خطوط در کار قوانین تغییری نمی‌دهند.

در نصب داخل زیرپوشه، وردپرس مسیر زیرپوشه را هم در RewriteBase و هم در قانون آخر می‌گذارد، مثلاً RewriteBase /blog/ و RewriteRule . /blog/index.php [L]. شبکه‌های چندسایته از بلوک متفاوتی استفاده می‌کنند و وردپرس این فایل را برای آن‌ها خودکار نمی‌نویسد.

نکات کلیدی

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

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

RewriteEngine On ماژول mod_rewrite آپاچی را برای این پوشه روشن می‌کند؛ بدون آن، قوانین بازنویسی پایین هیچ کاری نمی‌کنند.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] آدرس را دست‌نخورده می‌گذارد (معنی - همین است) و هدر Authorization درخواست را در یک متغیر سرور کپی می‌کند. وردپرس این متغیر را می‌خواند تا نام کاربری و رمز عبور ارسال‌شده در هدر را بگیرد، مانند یک رمز عبور برنامه.

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

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

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

RewriteRule . /index.php [L] همان چیزی است که لینک‌های یکتا را به کار می‌اندازد. هر چیزی که از این دو شرط بگذرد به index.php فرستاده می‌شود و وردپرس تصمیم می‌گیرد آدرس به کدام نوشته، برگه یا بایگانی اشاره دارد.

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

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

این کار در موارد زیر مشکل را حل نمی‌کند:

• فایل یا پوشه آن قابل نوشتن نیست برای کاربری که PHP با آن اجرا می‌شود. صفحه خطایی نشان می‌دهد که می‌گوید فایل .htaccess قابل نوشتن نیست و قوانینی را که باید بچسبانید هم نمایش می‌دهد. در برخی میزبانی‌ها PHP با کاربر سیستمی متفاوتی از مالک فایل‌های آپلودشده با FTP اجرا می‌شود، پس مجوزهایی که در برنامه FTP درست به نظر می‌رسند باز هم ممکن است جلوی وردپرس را بگیرند.
• از nginx استفاده می‌کنید. راهنمای nginx وردپرس می‌گوید nginx فایل پیکربندی در سطح پوشه مانند .htaccess ندارد و وردپرس نمی‌تواند پیکربندی سرور را تغییر دهد. معادل این مسیریابی یک دستور try_files در پیکربندی سرور است که مدیر سرور باید آن را ویرایش کند.
• AllowOverride روی None است برای پوشه سایت شما در پیکربندی اصلی آپاچی. مستندات آپاچی می‌گوید: “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” یعنی فایل‌های .htaccess کاملاً نادیده گرفته می‌شوند، مگر اینکه آن‌ها را صریحاً برای یک پوشه فعال کنید. وردپرس می‌تواند فایلی بی‌نقص بنویسد و باز هم آن فایل کاری نمی‌کند. قوانین بازنویسی به AllowOverride FileInfo (یا All) نیاز دارند و شاید میزبان شما باید این را تغییر دهد.
• لینک‌های یکتای شما روی حالت ساده (Plain) هستند. آدرس‌های ساده به قوانین بازنویسی نیاز ندارند، پس وردپرس فایل را برای آن‌ها نمی‌سازد.

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

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

1. اول راه‌حل یک‌کلیکی را امتحان کنید. در wp-admin صفحه تنظیمات > پیوندهای یکتا را باز کنید و بدون هیچ تغییری روی ذخیره تغییرات کلیک کنید. اگر وردپرس بتواند فایل را بنویسد، این کار آن را دوباره می‌سازد. اگر نتواند، صفحه خطا و قوانین لازم را نشان می‌دهد.

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

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

اگر هنوز خطای 404 می‌دهد، شاید .htaccess نادیده گرفته می‌شود. موضوع AllowOverride را از میزبان خود بپرسید، چون وقتی خاموش باشد آپاچی فایل درست را هم نادیده می‌گیرد.

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

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

# قوانینی که شما یا یک افزونه اضافه کرده‌اید: بالای نشانگرهای وردپرس
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # مثال: محافظت در برابر هات‌لینک، قوانین کش و غیره
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

هر چیزی که بین # BEGIN WordPress و # END WordPress قرار بگیرد، دفعه بعد که وردپرس فایل را به‌روز کند از بین می‌رود و بار شدن صفحه پیوندهای یکتا برای این کار کافی است. خطوط قبل و بعد از نشانگرها حفظ می‌شوند. برای تغییر مسیرها به‌طور خاص، قوانین درست تغییر مسیر در .htaccess وردپرس را ببینید تا بدانید کجا باید قرار بگیرند و چگونه از حلقه جلوگیری کنید.

خطای 500 Internal Server Error درست بعد از ویرایش فایل به چیزی اشاره دارد که همین الان تغییر داده‌اید. مستندات آپاچی می‌گوید گزارش خطا احتمالاً نام یک دستور غیرمجاز یا خطای نحوی را ذکر می‌کند. قوانین کپی‌شده از یک آموزش قدیمی می‌توانند باعث این خطا شوند: Order در آپاچی 2.4 دستوری نامعتبر است، مگر اینکه mod_access_compat بارگذاری شده باشد. ویرایش را برگردانید تا سایت بالا بیاید و سپس گزارش خطا را بخوانید.

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

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

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

فایل .htaccess پیش‌فرض وردپرس چیست؟ این همان بلوک RewriteEngine است که وردپرس بین # BEGIN WordPress و # END WordPress در فایل .htaccess ریشه سایت شما می‌نویسد. این بلوک هدر Authorization را به PHP می‌دهد و هر درخواستی را که فایل یا پوشه واقعی نباشد به index.php می‌فرستد.

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

چرا همه نوشته‌های من به جز صفحه اصلی خطای 404 می‌دهند؟ فایل .htaccess گمشده یا خراب روی آپاچی همین الگو را ایجاد می‌کند. سرور می‌تواند صفحه اصلی را بدون قوانین بازنویسی پیدا کند. هر لینک یکتای دیگر برای رسیدن به index.php به این قوانین نیاز دارد، پس بدون آن‌ها آپاچی دنبال فایلی می‌گردد که وجود ندارد و خطای 404 برمی‌گرداند.

آیا وردپرس .htaccess را به‌طور خودکار دوباره می‌سازد؟ بله، روی آپاچی یا LiteSpeed با mod_rewrite، اگر لینک‌های یکتای زیبا فعال باشند و وردپرس بتواند آنجا بنویسد. باز کردن تنظیمات > پیوندهای یکتا برای این کار کافی است. برای فایل گمشده پوشه باید قابل نوشتن باشد، و فایل موجود هم باید خودش قابل نوشتن باشد. در غیر این صورت، صفحه خطا را همراه با قوانینی که باید دستی بچسبانید نشان می‌دهد.

چرا nginx فایل .htaccess وردپرس را ندارد؟ nginx فایل پیکربندی در سطح پوشه مانند .htaccess آپاچی ندارد. همین مسیریابی به‌صورت قانون try_files در پیکربندی سرور nginx نوشته می‌شود و مدیر سرور باید آن را ویرایش کند، چون وردپرس نمی‌تواند آن را تغییر دهد.

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

منابع

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• کد منبع وردپرس: class-wp-rewrite.php، options-permalink.php، misc.php، load.php، user.php، vars.php
• Apache HTTP Server 2.4: .htaccess files، mod_rewrite، Upgrading to 2.4

---

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