فایل htaccess وردپرس چیست و با آن چه کار میتوان کرد

فایل .htaccess یکی از فایل‌های پیکربندی مهم در بسیاری از سایت‌های وردپرس است. با استفاده از این فایل می‌توان رفتار وب‌سرور را در زمینه‌هایی مانند پیوندهای یکتا، ریدایرکت، کش مرورگر و بعضی محدودیت‌های دسترسی تنظیم کرد. با این حال، یک دستور اشتباه ممکن است باعث خطای 500، ریدایرکت ناخواسته یا از دسترس خارج شدن بخشی از سایت شود.

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

فایل htaccess. چیست و چه کاری انجام می‌دهد؟

فایل .htaccess یک فایل پیکربندی در وب‌سرور Apache است که می‌تواند برای تعیین بعضی از قوانین دسترسی، بازنویسی URLها، ریدایرکت و تنظیمات دیگر استفاده شود. وب‌سرور LiteSpeed هم بسیاری از دستورهای رایج Apache را پشتیبانی می‌کند، اما پشتیبانی از هر دستور به نسخه و تنظیمات سرور بستگی دارد.

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

قبل از ویرایش فایل، این سه کار را انجام بده

تغییرات این فایل می‌تواند روی کل سایت اثر بگذارد. پیش از شروع، سه اقدام احتیاطی زیر را انجام بده:

1. از فایل فعلی بکاپ بگیر. یک کپی از .htaccess تهیه کن و آن را خارج از مسیر عمومی سایت نگه دار. اگر امکان دارد، از فایل‌ها و دیتابیس سایت هم بکاپ داشته باش.
2. روش بازگشت را آماده کن. مطمئن شو در صورت بروز خطا می‌توانی از طریق کنترل‌پنل، FTP یا SSH فایل قبلی را برگردانی.
3. قوانین را یکی‌یکی آزمایش کن. بعد از هر تغییر، صفحه اصلی، نوشته‌ها، ورود به پیشخوان و بخش‌های مهم سایت را بررسی کن. همه کدهای این مقاله را هم‌زمان اضافه نکن.

فایل htaccess. وردپرس کجاست؟

در بسیاری از نصب‌های وردپرس، این فایل در پوشه اصلی سایت قرار دارد، یعنی همان مسیری که پوشه‌های wp-admin، wp-content و wp-includes را می‌بینی. در هاست‌های رایج، این مسیر ممکن است public_html باشد، اما مسیر دقیق به ساختار میزبانی بستگی دارد.

نام فایل با نقطه شروع می‌شود، بنابراین ممکن است در نرم‌افزار مدیریت فایل یا FTP به‌صورت پیشفرض نمایش داده نشود.

نمایش فایل مخفی در FileZilla

1. با FileZilla به حساب FTP یا SFTP سایت متصل شو.
2. به پوشه‌ای برو که وردپرس در آن نصب شده است.
3. از منوی Server گزینه Force showing hidden files را فعال کن.
4. فهرست فایل‌ها را تازه‌سازی کن و دنبال فایل .htaccess بگرد.

اگر فایل را پیدا نکردی، ابتدا مطمئن شو در پوشه درست قرار داری و فایل‌های مخفی نمایش داده می‌شوند. نبودن این فایل لزوماً به معنی خرابی وردپرس نیست. ممکن است سایت از تنظیمات دیگری در وب‌سرور استفاده کند یا فایل هنوز ایجاد نشده باشد.

ساخت مجدد قوانین پیش‌فرض وردپرس

اگر از Apache یا LiteSpeed استفاده می‌کنی و مجوزهای لازم وجود دارد، وارد پیشخوان وردپرس شو و به مسیر تنظیمات ← پیوندهای یکتا برو. پس از بررسی ساختار پیوندهای یکتا، روی «ذخیره تغییرات» کلیک کن. وردپرس در شرایط مناسب می‌تواند قوانین بازنویسی را ایجاد یا به‌روزرسانی کند، اما این کار در همه محیط‌ها تضمین‌شده نیست.

قوانین متداول وردپرس در ریشه سایت با ساختاری مشابه نمونه زیر قرار می‌گیرند. اگر وردپرس در زیرپوشه نصب شده باشد، ممکن است مسیرها متفاوت باشند. این بخش را بدون بررسی ساختار نصب، جایگزین کل فایل فعلی نکن.

# 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 ممکن است با ذخیره مجدد پیوندهای یکتا بازنویسی شوند. قوانین سفارشی را با توجه به ساختار فعلی فایل و دستورالعمل‌های همان سرور مدیریت کن.

کاربرد اول، مدیریت ریدایرکت‌ها

ریدایرکت زمانی کاربرد دارد که نشانی صفحه‌ای تغییر کرده، دامنه سایت عوض شده یا لازم است کاربران و موتورهای جست‌وجو به نسخه اصلی URL هدایت شوند. پیش از افزودن قانون، مطمئن شو افزونه سئو، افزونه ریدایرکت، کنترل‌پنل یا تنظیمات وب‌سرور قانون مشابهی ایجاد نکرده باشند.

ریدایرکت دائمی یک صفحه با کد 301

از ریدایرکت 301 برای انتقال دائمی یک URL به URL جدید استفاده می‌شود. نمونه زیر صفحه قدیمی را به صفحه جدید در همان دامنه منتقل می‌کند. مسیرها را با نشانی واقعی سایت جایگزین کن.

Redirect 301 /oldpage.html https://example.com/newpage/

برای انتقال دائمی، مقصد باید نسخه نهایی و درست صفحه باشد. از زنجیره‌های چندمرحله‌ای و ریدایرکت به صفحه نامرتبط خودداری کن.

ریدایرکت موقت با کد 302

اگر انتقال فقط برای مدتی انجام می‌شود و قرار است URL اصلی بعدا دوباره استفاده شود، می‌توان از 302 استفاده کرد:

Redirect 302 /oldpage.html https://example.com/temporary-page/

یکسان‌سازی نسخه www و بدون www

برای سئو و جلوگیری از پراکندگی نشانی‌ها، بهتر است نسخه اصلی دامنه مشخص باشد. برای مثال، اگر نسخه اصلی سایت https://www.example.com است، قانون زیر می‌تواند درخواست‌های دامنه بدون www را به آن منتقل کند:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

اگر نسخه اصلی بدون www است، قانون بالا را استفاده نکن. در آن حالت، باید دامنه مقصد را به نسخه بدون www تغییر دهی. همچنین مطمئن شو گواهی SSL برای دامنه مورد استفاده معتبر است و قانون دیگری در سطح سرور یا افزونه این انتقال را انجام نمی‌دهد.

هدایت درخواست‌های HTTP به HTTPS

اگر گواهی SSL نصب شده و HTTPS به‌درستی کار می‌کند، می‌توان درخواست‌های HTTP را به نسخه امن منتقل کرد. نمونه زیر برای سایت‌هایی است که اتصال مستقیم کاربر به Apache یا LiteSpeed انجام می‌شود و HTTPS در همان لایه قابل تشخیص است:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

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

انتقال دامنه قدیمی به دامنه جدید

اگر تمام صفحات دامنه قدیمی باید به مسیر مشابه در دامنه جدید منتقل شوند، می‌توان از قانونی مانند نمونه زیر استفاده کرد. این قانون باید در پیکربندی دامنه قدیمی قرار بگیرد و نباید روی دامنه مقصد اعمال شود:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-example\.com$ [NC]
RewriteRule ^ https://new-example.com%{REQUEST_URI} [R=301,L]

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

کاربرد دوم، بهبود کش و سرعت سایت

فایل .htaccess می‌تواند در بعضی سرورها برای تعیین مدت نگهداری منابع در کش مرورگر یا فعال‌سازی فشرده‌سازی استفاده شود. اما این تنظیمات به‌تنهایی جایگزین کش صفحه، بهینه‌سازی تصاویر یا بررسی زمان پاسخ سرور نیستند. اگر از LiteSpeed Cache یا افزونه بهینه‌سازی دیگری استفاده می‌کنی، ابتدا تنظیمات همان ابزار را بررسی کن تا قوانین تکراری یا متناقض ایجاد نشوند.

تنظیم زمان انقضای کش مرورگر

برای فایل‌هایی که به‌ندرت تغییر می‌کنند، مانند تصاویر و فایل‌های فونت، می‌توان زمان کش طولانی‌تری در نظر گرفت. برای HTML یا داده‌هایی که مرتب تغییر می‌کنند، سیاست کش باید محتاطانه‌تر باشد.

<IfModule mod_expires.c>
    ExpiresActive On

    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 month"
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/webp "access plus 1 month"
    ExpiresByType image/svg+xml "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 month"

    ExpiresByType text/html "access plus 0 seconds"
</IfModule>

این یک نمونه عمومی است، نه نسخه‌ای مناسب برای همه سایت‌ها. اگر نام فایل‌های CSS و JavaScript هنگام هر انتشار تغییر می‌کند، کش طولانی معمولاً قابل استفاده است. اگر فایل‌ها با همان نام به‌روزرسانی می‌شوند، ممکن است کاربر نسخه قدیمی را ببیند. همچنین وجود یا نبود ماژول mod_expires باید در سرور بررسی شود.

فعال کردن فشرده‌سازی GZIP

فشرده‌سازی پاسخ‌های متنی می‌تواند حجم انتقال HTML، CSS، JavaScript و برخی قالب‌های متنی را کاهش دهد. در Apache، اگر ماژول mod_deflate فعال باشد، نمونه زیر قابل بررسی است:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

پیش از فعال‌سازی دستی، بررسی کن که وب‌سرور، CDN یا افزونه کش از قبل فشرده‌سازی را انجام ندهد. فشرده‌سازی دوباره یک پاسخ معمولاً سودی ندارد و تنظیمات تکراری فقط نگهداری را دشوارتر می‌کنند. قالب‌های تصویری مانند JPEG و WebP عموماً از قبل فشرده هستند و نیازی به GZIP ندارند.

کاربرد سوم، محدود کردن دسترسی به فایل‌های حساس

بعضی فایل‌ها مانند wp-config.php حاوی اطلاعات مهمی هستند. در نصب استاندارد وردپرس، وب‌سرور معمولا مانع دسترسی مستقیم به این فایل می‌شود، اما می‌توان یک قانون دفاعی اضافه کرد. نمونه زیر از نحو جدید Apache استفاده می‌کند:

<Files "wp-config.php">
    Require all denied
</Files>

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

محدود کردن دسترسی مستقیم به فایل‌های پیکربندی

برای مسدود کردن دسترسی وب به چند نوع فایل حساس می‌توان از FilesMatch استفاده کرد. نمونه زیر برای فایل‌های نام‌برده‌شده است و باید با ساختار سایت تطبیق داده شود:

<FilesMatch "^(wp-config\.php|php\.ini|\.htaccess)$">
    Require all denied
</FilesMatch>

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

آیا باید دسترسی به پوشه wp-content را ببندیم؟

خیر، مسدود کردن کامل پوشه wp-content معمولا کار درستی نیست. وردپرس برای نمایش تصاویر، فایل‌های CSS و JavaScript و منابع قالب و افزونه‌ها به دسترسی عمومی به بسیاری از فایل‌های این پوشه نیاز دارد. بستن کل پوشه می‌تواند ظاهر و عملکرد سایت را خراب کند.

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

محدود کردن دسترسی به پیشخوان وردپرس

محدودسازی دسترسی به wp-admin با IP ثابت می‌تواند در بعضی محیط‌های سازمانی مفید باشد، اما برای سایت‌هایی که مدیران از اینترنت یا IPهای متغیر استفاده می‌کنند، ممکن است باعث قفل شدن دسترسی شود. همچنین فایل wp-admin شامل منابعی است که گاهی برای عملکرد صحیح سایت به دسترسی نیاز دارند.

اگر قصد محدودسازی بر اساس IP را داری، بهتر است ابتدا آن را در سطح وب‌سرور یا فایروال و با در نظر گرفتن مسیرهای مورد نیاز وردپرس طراحی و آزمایش کنی. نمونه‌های قدیمی مبتنی بر Order، Allow و Deny در همه نسخه‌های Apache به یک شکل عمل نمی‌کنند و نباید بدون بررسی نسخه سرور کپی شوند.

افزایش حجم آپلود با htaccess.، همیشه ممکن نیست

حداکثر حجم آپلود وردپرس به تنظیمات PHP، وب‌سرور و محدودیت‌های میزبانی وابسته است. دستورهایی مانند php_value upload_max_filesize ممکن است در بعضی محیط‌های Apache با PHP به‌صورت ماژول کار کنند، اما در بسیاری از تنظیمات PHP-FPM یا بعضی محیط‌های LiteSpeed می‌توانند باعث خطای 500 شوند.

به‌جای افزودن مستقیم این کدها به .htaccess، ابتدا مقدارهای upload_max_filesize، post_max_size، max_execution_time و محدودیت‌های پنل میزبانی را بررسی کن. سپس از روش پیشنهادی شرکت هاستینگ برای تغییر تنظیمات PHP استفاده کن. مقدار post_max_size باید با حجم فایل مورد نظر و داده‌های ارسالی فرم سازگار باشد.

چرا بعضی کدهای رایج htaccess. خطرناک یا بی‌اثر هستند؟

نمونه کدهای موجود در اینترنت ممکن است برای نسخه قدیمی سرور، معماری متفاوت یا شرایط خاصی نوشته شده باشند. پیش از استفاده از هر کد، این نکات را در نظر بگیر:

• بستن تمام دسترسی‌ها به فایل‌ها: ممکن است فایل‌های لازم برای نمایش سایت را مسدود کند.
• ریدایرکت عمومی همه URLها: ممکن است حلقه ریدایرکت یا زنجیره انتقال ایجاد کند.
• قوانین قدیمی کنترل دسترسی: ممکن است در نسخه جدید Apache نیاز به نحو متفاوت داشته باشند.
• قوانین کش طولانی: ممکن است باعث نمایش نسخه قدیمی منابعی شود که نام فایلشان تغییر نمی‌کند.
• دستورهای PHP در htaccess.: بسته به شیوه اجرای PHP ممکن است پشتیبانی نشوند و خطای سرور ایجاد کنند.
• قوانین مربوط به Nginx: تنظیمات Nginx معمولا در فایل‌های پیکربندی خود وب‌سرور تعریف می‌شوند و نمی‌توان قوانین Apache را مستقیم در آن قرار داد.

اگر پس از ویرایش htaccess. سایت خطای 500 داد چه کنیم؟

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

اگر دسترسی به پیشخوان قطع شده، از کنترل‌پنل، File Manager یا SFTP برای اصلاح فایل استفاده کن. از حذف کل فایل بدون داشتن نسخه پشتیبان خودداری کن، چون ممکن است قوانین لازم برای پیوندهای یکتا یا تنظیمات دیگر هم در آن قرار داشته باشند.

اگر برای تشخیص مشکل به راهنمای بیشتری نیاز داری، مقاله رفع خطای 500 وردپرس را هم ببین.

جمع‌بندی

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

برای مدیریت پیوندهای یکتا و ریدایرکت‌ها، ابتدا تنظیمات فعلی وردپرس و وب‌سرور را بررسی کن. برای کش و فشرده‌سازی، تنظیمات موجود در LiteSpeed، CDN یا افزونه کش را در اولویت قرار بده. برای امنیت هم به محدودسازی دسترسی‌ها، به‌روزرسانی نرم‌افزارها، بکاپ سالم و تنظیمات صحیح سرور توجه کن، نه فقط چند قانون در یک فایل.

اگر به دنبال بهبود عملکرد سایت هستی، می‌توانی راهنمای بهینه‌سازی سرعت سایت را هم مطالعه کنی.