بهینه‌سازی فایل htaccess | برای بهبود سئو: راهنمای جامع و عملی کدها

شاید اسم فایل .htaccess را شنیده باشید؛ فایلی کوچک، مخفی و کمی ترسناک در ریشه هاست شما که خیلی‌ها ترجیح می‌دهند به آن نزدیک نشوند. اما اگر بخواهم صادقانه بگویم، درک و استفاده صحیح از این فایل، یکی از ستون‌های اصلی سئو فنی پیشرفته است. این فایل مثل اتاق فرمان سرور شما عمل می‌کند و به شما قدرتی می‌دهد که بتوانید مستقیماً با سرور و مرورگر کاربر صحبت کنید. از مدیریت ریدایرکت‌های ۳۰۱ گرفته تا افزایش انفجاری سرعت سایت با تنظیمات کش، همه‌چیز از همین فایل متنی ساده می‌گذرد. در این راهنما، می‌خواهم به عنوان یک همراه، قدم به قدم به شما نشان دهم که چطور این فایل قدرتمند را بدون ترس و با اطمینان کامل، برای بهبود سئو، سرعت و امنیت سایت خود به کار بگیرید.

جدول کاربردی: خلاصه‌ی دستورات کلیدی htaccess. (برای دسترسی سریع)

کاربرد دستور	ماژول مورد نیاز	سطح خطر (از ۱ تا ۵)	خلاصه‌ی کد (نمونه)
ریدایرکت ۳۰۱ (تک صفحه)	mod_alias	۲ (کم)	Redirect 301 /old-page.html /new-page/
ریدایرکت HTTP به HTTPS	mod_rewrite	۴ (بالا)	RewriteCond %{HTTPS} off
ریدایرکت www به non-www	mod_rewrite	۴ (بالا)	RewriteCond %{HTTP_HOST} ^www\.
فعال‌سازی Gzip	mod_deflate	۳ (متوسط)	<IfModule mod_deflate.c>
تنظیم کش مرورگر	mod_expires	۳ (متوسط)	ExpiresActive On
جلوگیری از Hotlinking	mod_rewrite	۳ (متوسط)	RewriteCond %{HTTP_REFERER} !^$
محافظت از فایل wp-config	mod_authz_core	۲ (کم)	<FilesMatch “wp-config.php”>
مسدود کردن IP مخرب	mod_authz_core	۲ (کم)	Require not ip 123.45.67.89

فایل htaccess. چیست و چرا برای سئو حیاتی است؟

فایل .htaccess (که مخفف Hypertext Access است) در واقع یک فایل پیکربندی (Configuration File) ساده اما فوق‌العاده قدرتمند در سطح پوشه (Directory-level) است. این فایل به سرور وب شما، به طور خاص سرورهای آپاچی (Apache)، دستور می‌دهد که چطور با درخواست‌های ورودی به سایت شما رفتار کند.

اگر بخواهم ساده بگویم، .htaccess مثل یک «راهنمای نگهبانی» دمِ درِ سرور شما عمل می‌کند. این راهنما به نگهبان (سرور) می‌گوید:

• اگر کسی به این آدرس قدیمی آمد، او را به این آدرس جدید بفرست (ریدایرکت).
• این آدرس‌های طولانی و نازیبا را به آدرس‌های کوتاه و قشنگ تبدیل کن (بازنویسی URL).
• به این آدرس IP خاص اجازه ورود نده (مسائل امنیتی).
• اگر کسی فایلی را پیدا نکرد، این صفحه ۴۰۴ سفارشی را به او نشان بده.

اهمیت حیاتی آن برای سئو در همین دستورات نهفته است. تقریباً تمام کارهای فنی مهم سئو، از جمله مدیریت ریدایرکت‌های ۳۰۱، بهینه‌سازی ساختار URLها، مدیریت خطاهای ۴۰۴ و حتی برخی تنظیمات مربوط به سرعت (مثل کش)، مستقیماً از طریق همین فایل کنترل می‌شوند.

فایل htaccess. دقیقاً چه کاری انجام می‌دهد؟ (آشنایی با سرور آپاچی)

همان‌طور که اشاره کردم، این فایل مختص وب‌سرورهای آپاچی (Apache) است. آپاچی یکی از محبوب‌ترین وب‌سرورهای دنیاست و اکثر هاست‌های اشتراکی (مثل سی‌پنل) از آن استفاده می‌کنند. (در سرورهای دیگر مثل Nginx، فایل .htaccess کار نمی‌کند و تنظیمات باید در فایل‌های پیکربندی خود Nginx انجام شود).

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

مهم‌ترین کارهایی که .htaccess برای ما انجام می‌دهد عبارتند از:

• ریدایرکت‌ها (Redirects): مهم‌ترین کاربرد سئویی. وقتی صفحه‌ای را حذف می‌کنید یا آدرسش را تغییر می‌دهید، با یک ریدایرکت ۳۰۱ (دائمی) در این فایل، هم کاربر و هم گوگل را به آدرس جدید هدایت می‌کنید تا اعتبار صفحه از دست نرود.
• بازنویسی URL (URL Rewriting): این فایل می‌تواند URLهای داینامیک و پیچیده (مثل site.com/product.php?id=123) را به URLهای تمیز، کوتاه و قابل فهم (مثل site.com/products/my-product/) تبدیل کند که هم برای کاربر و هم برای سئو عالی است.
• مدیریت صفحات خطا (Error Handling): می‌توانید مشخص کنید وقتی خطای ۴۰۴ (صفحه پیدا نشد) یا ۴۰۳ (دسترسی ممنوع) رخ می‌دهد، کاربر به جای دیدن یک صفحه سفید زشت، به یک صفحه سفارشی‌سازی شده و زیبا هدایت شود.
• تنظیمات امنیتی (Security): کارهای مهمی مثل مسدود کردن دسترسی از IPهای خاص، جلوگیری از نمایش فایل‌های حساس، یا جلوگیری از «هات‌لینکینگ» (Hotlinking یا دزدی پهنای باند با استفاده مستقیم از تصاویر شما در سایت‌های دیگر) را انجام می‌دهد.
• تنظیمات کش (Caching): می‌توانید به مرورگر کاربر دستور بدهید که فایل‌های خاصی (مثل CSS یا تصاویر) را برای مدتی در حافظه خود نگه دارد تا در بازدیدهای بعدی، سایت سریع‌تر بارگذاری شود.

این فایل کجاست؟ (نحوه پیدا کردن و دسترسی به htaccess. در cPanel و وردپرس)

پیدا کردن این فایل معمولاً ساده است، اما یک ترفند کوچک دارد.

فایل .htaccess تقریباً همیشه در پوشه ریشه (Root Directory) وب‌سایت شما قرار دارد. در هاست‌های سی‌پنل، این پوشه معمولاً public_html نام دارد. اگر از وردپرس استفاده می‌کنید، این فایل دقیقاً در همان جایی است که فایل‌های اصلی وردپرس مثل wp-config.php و wp-content قرار دارند.

چرا فایل را نمی‌بینم؟ (مشکل فایل‌های مخفی)

مهم‌ترین نکته اینجاست: در سیستم‌عامل‌های مبتنی بر لینوکس (که اکثر سرورها از آن استفاده می‌کنند)، هر فایلی که نامش با نقطه (.) شروع شود، به عنوان «فایل مخفی» (Hidden File) در نظر گرفته می‌شود.

برای دیدن آن در سی‌پنل (cPanel):

1. وارد cPanel هاست خود شوید و به بخش File Manager (مدیریت فایل) بروید.
2. وارد پوشه public_html (یا هر پوشه‌ای که سایت اصلی شما در آن قرار دارد) شوید.
3. اگر فایل .htaccess را نمی‌بینید، در گوشه بالا سمت راست File Manager، روی دکمه Settings (تنظیمات) کلیک کنید.
4. در پنجره‌ای که باز می‌شود، تیک گزینه “Show Hidden Files (dotfiles)” یا «نمایش فایل‌های مخفی» را بزنید و Save کنید.
5. بلافاصله فایل .htaccess ظاهر خواهد شد.

مهم: چگونه قبل از هر تغییری از فایل htaccess. بکاپ کامل بگیریم؟

این بخش را چند بار بخوانید! فایل .htaccess به شدت حساس است. یک کاراکتر اشتباه، یک فاصله اضافی یا یک خطای تایپی کوچک می‌تواند کل سایت شما را از دسترس خارج کند و خطای معروف 500 Internal Server Error را نمایش دهد.

پس قبل از اینکه حتی یک کلمه به آن اضافه یا کم کنید، همیشه بکاپ بگیرید.

ساده‌ترین و امن‌ترین روش‌های بکاپ:

1. روش دانلود (پیشنهادی):
   • در File Manager، روی فایل .htaccess راست‌کلیک کنید.
   • گزینه Download (دانلود) را بزنید و فایل را روی کامپیوتر خود ذخیره کنید. به همین سادگی!
2. روش کپی درجا (سریع):
   • در File Manager، روی فایل .htaccess راست‌کلیک کنید.
   • گزینه Copy (کپی) یا Duplicate (تکثیر) را انتخاب کنید.
   • در پنجره باز شده، یک نام جدید برای فایل کپی وارد کنید. مثلاً: .htaccess_backup_2025_11_02 یا .htaccess.bak
   • حالا شما یک نسخه سالم از فایل دارید که سرور آن را نمی‌خواند (چون نامش .htaccess نیست) اما در صورت بروز مشکل، آماده استفاده است.

اگر سایت خراب شد چه کنیم؟ اگر بعد از ویرایش، سایت شما با خطای 500 مواجه شد، نگران نباشید:

1. فایل .htaccess معیوب را حذف کنید (یا نامش را به .htaccess_bad تغییر دهید).
2. فایل بکاپی که دانلود کرده بودید را دوباره آپلود کنید، یا اگر از روش کپی استفاده کردید، نام فایل کپی (.htaccess.bak) را به .htaccess تغییر نام دهید.
3. سایت شما بلافاصله به حالت قبل برمی‌گردد.

مدیریت URL و ریدایرکت‌ها: اولین ستون سئوی فنی با htaccess.

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

پیاده‌سازی ریدایرکت 301 (دائمی) برای صفحات حذف شده و تغییر آدرس‌ها

این مهم‌ترین دستوری است که هر سئوکار باید بلد باشد. وقتی آدرس صفحه‌ای را تغییر می‌دهید (مثلاً از site.com/old-page.html به site.com/new-better-page/) یا صفحه‌ای را حذف می‌کنید و می‌خواهید اعتبار آن را به صفحه مرتبط دیگری منتقل کنید، باید از ریدایرکت ۳۰۱ (Redirect 301) استفاده کنید.

این کد به گوگل می‌گوید: «آقای گوگل، من برای همیشه از این آدرس قدیمی به آدرس جدید نقل مکان کردم. لطفاً تمام اعتبار، رتبه و ارزشی که به آدرس قدیمی می‌دادی را به این آدرس جدید منتقل کن.»

کد ساده برای ریدایرکت یک صفحه به صفحه دیگر:

Apache

Redirect 301 /old-page.html https://www.yourdomain.com/new-page/

• توضیح کد:
  • Redirect 301: نوع ریدایرکت (دائمی) را مشخص می‌کند.
  • /old-page.html: آدرس قدیمی (فقط مسیر بعد از دامنه، با اسلش در ابتدا).
  • https://www.yourdomain.com/new-page/: آدرس کامل و جدید مقصد.

نکته تجربی: همیشه آدرس مقصد را به صورت کامل (Full URL) همراه با https:// بنویسید تا از هرگونه تفسیر اشتباه توسط سرور جلوگیری شود.

ریدایرکت کل سایت از HTTP به HTTPS (اجباری کردن SSL)

امروزه داشتن گواهی SSL (همان https که قفل سبز را نشان می‌دهد) دیگر یک گزینه نیست، بلکه یک اجبار است. گوگل رسماً اعلام کرده که HTTPS یک فاکتور رتبه‌بندی است و از نظر امنیتی هم برای اعتماد کاربران حیاتی است.

حتی اگر SSL را نصب کرده باشید، ممکن است سایت شما هم با http:// و هم با https:// باز شود. این فاجعه است! چون دو نسخه از سایت شما در دسترس است (محتوای تکراری). باید با کد زیر، تمام درخواست‌های http را به اجبار به https بفرستید.

کد ریدایرکت HTTP به HTTPS (روش استاندارد):

Apache

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

• توضیح کد:
  • RewriteEngine On: موتور بازنویسی URL را روشن می‌کند (برای تمام کدهای بعدی که با Rewrite شروع می‌شوند، این خط باید قبل از آن‌ها و یک بار نوشته شود).
  • RewriteCond %{HTTPS} off: یک شرط می‌گذارد. می‌گوید: «اگر (Cond) اتصال از نوع HTTPS نبود (off بود)…»
  • RewriteRule …: دستور اصلی را اجرا کن: «…هر آدرسی که درخواست شد (^(.*)$) را به نسخه https همان آدرس (https://%{HTTP_HOST}%{REQUEST_URI}) ریدایرکت ۳۰۱ کن.»
  • [L,R=301]: R=301 یعنی نوع ریدایرکت دائمی است. L (Last) یعنی این آخرین دستور است و دستورات بازنویسی بعدی را بررسی نکن (برای جلوگیری از تداخل).

حل مشکل محتوای تکراری: ریدایرکت WWW به non-WWW (یا برعکس)

مشکل دقیقاً مشابه قبلی است. از نظر گوگل، https://www.yourdomain.com و https://yourdomain.com دو دامنه متفاوت هستند. اگر سایت شما با هر دو آدرس باز شود، شما در حال ایجاد محتوای تکراری (Duplicate Content) از کل سایت خودتان هستید!

باید تصمیم بگیرید که کدام نسخه را به عنوان نسخه «کنونیکال» یا اصلی خود ترجیح می‌دهید. (تجربه نشان داده که تفاوت سئویی خاصی بین انتخاب www یا non-www وجود ندارد، فقط مهم است که یکی را انتخاب کنید و روی آن ثابت قدم بمانید).

کد ریدایرکت تمام درخواست‌های www به non-www (بدون www):

Apache

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]

RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

• توضیح کد:
  • RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]: شرط می‌گذارد: «اگر هاست (دامنه) درخواست شده با www. شروع می‌شد…» [NC] یعنی به حروف بزرگ و کوچک حساس نباش (No Case).
  • RewriteRule ^(.*)$ https://%1/$1 …: دستور می‌دهد: «کل آدرس ($1) را به نسخه بدون www (%1 که همان بخش داخل پرانتز در شرط بالایی است) ریدایرKت کن.»

(برای ریدایرکت برعکس، یعنی از non-WWW به WWW، کد کمی متفاوت است):

Apache

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www\. [NC]

RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]

بازنویسی URL ها (mod_rewrite) برای ساختار آدرس خوانا و بهینه (Pretty URLs)

این همان جادویی است که به آن mod_rewrite می‌گویند و در کدهای بالا هم از آن استفاده کردیم. کار اصلی آن «بازنویسی» یا «زیباسازی» URLها است.

فرض کنید سیستم شما یک URL داینامیک و زشت این‌ شکلی تولید می‌کند: https://yourdomain.com/profile.php?user_id=123

این URL نه برای کاربر خواناست و نه برای سئو بهینه است. با mod_rewrite می‌توانیم به سرور بگوییم هر وقت کسی آدرس خوانای زیر را درخواست کرد: https://yourdomain.com/user/123

تو در پشت صحنه (بدون اینکه کاربر بفهمد) همان فایل profile.php?user_id=123 را برایش اجرا کن.

کد نمونه ساده بازنویسی:

Apache

RewriteEngine On

RewriteRule ^user/([0-9]+)/?$ /profile.php?user_id=$1 [L]

• توضیح کد:
  • ^user/([0-9]+)/?$: یک الگو تعریف می‌کند: «هر آدرسی که با user/ شروع شد و بعد از آن یک یا چند عدد ([0-9]+) آمد…»
  • /profile.php?user_id=$1: «…آن را به این فایل بفرست و عددی که در پرانتز گرفته بودی ($1) را به عنوان user_id قرار بده.»
  • [L]: چون این یک بازنویسی داخلی است و ریدایرکت نیست (کاربر نباید متوجه شود)، از فلگ R=301 استفاده نمی‌کنیم.

نکته مهم: خوشبختانه، اگر از سیستم‌های مدیریت محتوا (CMS) مثل وردپرس استفاده می‌کنید، خود وردپرس به طور خودکار این فایل .htaccess را ایجاد و مدیریت می‌کند تا «پیوندهای یکتا» (Permalinks) شما به صورت زیبا نمایش داده شوند.

حذف اسلش (/) از انتهای URLها (یا افزودن آن)

باز هم بحث محتوای تکراری! از نظر گوگل، site.com/my-page و site.com/my-page/ (با اسلش در انتها) می‌توانند دو صفحه متفاوت باشند. این هم یک مشکل رایج است که باید حل شود.

شما باید تصمیم بگیرید که تمام URLهای شما یا با اسلش تمام شوند یا بدون اسلش. (وردپرس به طور پیش‌فرض همه را به نسخه با اسلش ریدایرکت می‌کند).

اگر به هر دلیلی (مثلاً ساختار سایت شما اینطور است) می‌خواهید اسلش انتهایی را حذف کنید، این کد به شما کمک می‌کند.

کد حذف اسلش (/) انتهایی:

Apache

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)/$ /$1 [L,R=301]

• توضیح کد:
  • RewriteCond %{REQUEST_FILENAME} !-d: یک شرط بسیار مهم. می‌گوید: «به شرطی این کار را بکن که آدرس درخواستی، یک پوشه (Directory) واقعی روی سرور نباشد (!-d).» (چون پوشه‌ها به طور طبیعی با اسلش تمام می‌شوند).
  • RewriteRule ^(.*)/$ /$1 …: دستور می‌دهد: «هر آدرسی که به اسلش (/) ختم می‌شد، آن اسلش را حذف کن (/$1) و ریدایرکت ۳۰۱ کن.»

افزایش سرعت سایت و بهبود Core Web Vitals با htaccess.

بهینه‌سازی سرعت فقط برای گوگل نیست، مستقیماً روی تجربه کاربری (UX) و نرخ تبدیل (CRO) هم تأثیر می‌گذارد. هیچ کاربری دوست ندارد منتظر لود شدن یک صفحه بماند. با .htaccess می‌توانیم دو کار اساسی انجام دهیم: کاهش حجم فایل‌ها و مدیریت هوشمندانه کش.

فعال‌سازی Gzip Compression برای فشرده‌سازی فایل‌ها و کاهش حجم صفحه

Gzip (یا برادر جدیدترش Brotli) یک روش فشرده‌سازی در سمت سرور است.

کارش چطور است؟ قبل از اینکه سرور شما فایل‌های متنی سایت (مثل HTML, CSS, JavaScript, XML) را برای مرورگر کاربر بفرستد، آن‌ها را مثل یک فایل Zip فشرده می‌کند. مرورگر کاربر این فایل فشرده و کم‌حجم را دریافت کرده و به سرعت آن را از حالت فشرده خارج (Unzip) می‌کند و نمایش می‌دهد.

نتیجه؟ حجم فایل‌های شما گاهی تا ۷۰ الی ۸۰ درصد کاهش پیدا می‌کند! این یعنی کاهش چشمگیر در زمان دانلود و بهبود مستقیم در معیارهایی مثل FCP (First Contentful Paint).

کد فعال‌سازی Gzip (با استفاده از mod_deflate): (این کد را در انتهای فایل .htaccess خود اضافه کنید)

Apache

<IfModule mod_deflate.c>

# فشرده‌سازی این نوع فایل‌های متنی

AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/html

AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE application/xml

AddOutputFilterByType DEFLATE application/xhtml+xml

AddOutputFilterByType DEFLATE application/rss+xml

AddOutputFilterByType DEFLATE application/javascript

AddOutputFilterByType DEFLATE application/x-javascript

 

# مدیریت برخی مرورگرهای قدیمی که مشکل دارند

BrowserMatch ^Mozilla/4 gzip-only-text/html

BrowserMatch ^Mozilla/4\.0[678] no-gzip

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

 

# فشرده‌سازی پروکسی‌ها (بسیار مهم)

<IfModule mod_headers.c>

Header append Vary User-Agent

</IfModule>

</IfModule>

• توضیح کد: این بلوک کد چک می‌کند که آیا ماژول mod_deflate فعال است (<IfModule>). اگر بود، به سرور می‌گوید فایل‌هایی با MIME Typeهای مشخص شده (مثل text/html, text/css) را قبل از ارسال، فشرده (DEFLATE) کند.

قدرت کش مرورگر (Leverage Browser Caching) برای بارگذاری مجدد سریع‌تر

این یکی از بهترین تکنیک‌ها برای افزایش سرعت سایت برای بازدیدکنندگان بازگشتی (Returning Visitors) است.

کارش چطور است؟ وقتی کاربری برای اولین بار وارد سایت شما می‌شود، مرورگرش باید تمام فایل‌ها (لوگو، تصاویر، فایل CSS، فایل JS) را دانلود کند. «کش مرورگر» به مرورگر کاربر دستور می‌دهد: «این فایل لوگو (logo.png) را دانلود کن و تا یک سال آینده در حافظه خودت نگه دار. هر بار که به این سایت برگشتی، دیگر آن را از سرور دانلود نکن، از همان نسخه‌ای که داری استفاده کن.»

این کار باعث می‌شود در بازدیدهای بعدی، صفحه به شکلی انفجاری و تقریباً آنی بارگذاری شود، چون مرورگر فقط محتوای متنی (HTML) جدید را دریافت می‌کند و بقیه فایل‌ها را از قبل در حافظه خود دارد.

تنظیم هدرهای Expires برای مدیریت دقیق حافظه پنهان (Cache-Control)

این بخش، در واقع پیاده‌سازی عملی همان «کش مرورگر» (بخش قبلی) است. ما با استفاده از ماژول mod_expires به سرور می‌گوییم که برای هر نوع فایل، یک «تاریخ انقضا» (Expires Header) و یک «دستورالعمل کنترل کش» (Cache-Control) مشخص کند.

Cache-Control به مرورگر می‌گوید که این فایل را تا چه مدتی (max-age) می‌تواند در حافظه پنهان خود نگه دارد.

کد تنظیم هدرهای Expires و Cache-Control:

Apache

<IfModule mod_expires.c>

# فعال‌سازی ماژول

ExpiresActive On

 

# پیش‌فرض: ۱ ماه

ExpiresDefault “access plus 1 month”

 

# فایل‌های CSS: ۱ ماه

ExpiresByType text/css “access plus 1 month”

 

# فایل‌های جاوا اسکریپت: ۱ ماه

ExpiresByType application/javascript “access plus 1 month”

ExpiresByType application/x-javascript “access plus 1 month”

 

# تصاویر: ۱ سال (چون به ندرت تغییر می‌کنند)

ExpiresByType image/gif “access plus 1 year”

ExpiresByType image/jpeg “access plus 1 year”

ExpiresByType image/png “access plus 1 year”

ExpiresByType image/webp “access plus 1 year”

ExpiresByType image/svg+xml “access plus 1 year”

ExpiresByType image/x-icon “access plus 1 year”

 

# فایل‌های دیگر (مثل فونت‌ها): ۱ سال

ExpiresByType application/font-woff “access plus 1 year”

ExpiresByType application/font-woff2 “access plus 1 year”

 

# فایل HTML (که داینامیک است) نباید کش شود یا زمان کمی داشته باشد

ExpiresByType text/html “access plus 0 seconds”

</IfModule>

• توضیح کد:
  • ExpiresActive On: ماژول را روشن می‌کند.
  • ExpiresByType … “access plus 1 year”: به مرورگر می‌گوید مثلاً فایل‌های image/jpeg را از زمان دسترسی (access) کاربر، تا یک سال آینده معتبر بدان و کش کن.
  • نکته تجربی مهم: می‌بینید که text/html را روی ۰ ثانیه تنظیم کردیم. این کار حیاتی است. چون اگر خود فایل HTML را کش کنیم، کاربر در بازدید بعدی تغییرات جدید سایت (مثلاً مقاله جدیدی که منتشر کردید) را نخواهد دید! ما می‌خواهیم فایل‌های استاتیک (تصاویر، CSS) کش شوند، نه محتوای اصلی.

ارتقای امنیت سایت و تاثیر آن بر اعتماد

امنیت فقط یک مسئله فنی نیست؛ مستقیماً به اعتماد (Trust) در E-E-A-T گره خورده است. گوگل (و کاربران) به سایت‌هایی که امن نیستند، اعتماد نمی‌کنند. اگر سایت شما هک شود، اسپم ارسال کند یا به دلیل حملات ربات‌ها کند باشد، هم کاربر و هم رتبه خود را از دست می‌دهHد.

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

جلوگیری از Hotlinking (دزدی پهنای باند) تصاویر و فایل‌ها

هات‌لینکینگ (Hotlinking) یا «دزدی پهنای باند» زمانی اتفاق می‌افتد که یک سایت دیگر، تصاویر یا فایل‌های شما را مستقیماً از روی سرور شما در سایت خودش نمایش می‌دهد.

مشکل چیست؟ آن‌ها محتوای خود را با استفاده از تصویر شما زیبا می‌کنند، اما این پهنای باند سرور شماست که مصرف می‌شود! این کار منابع سرور شما را می‌خورد و سایتتان را کند می‌کند.

با کد زیر، ما به سرور می‌گوییم: «اجازه نده هیچ دامنه‌ای غیر از دامنه خودم ([لینک مشکوک حذف شد])، فایل‌های تصویری من را نمایش دهد.»

کد جلوگیری از Hotlinking:

Apache

RewriteEngine On

# شرط اول: مطمئن شو درخواست‌کننده (Referer) خالی نیست

RewriteCond %{HTTP_REFERER} !^$

# شرط دوم: مطمئن شو درخواست‌کننده از دامنه ما نیست

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain\.com [NC]

# حالا برای این فایل‌ها، دسترسی را ممنوع کن (خطای 403)

RewriteRule \.(jpg|jpeg|png|gif|bmp|svg|webp)$ – [F,L]

• توضیح کد:
  • RewriteEngine On: موتور بازنویسی را روشن می‌کند (اگر قبلاً روشن کرده‌اید، نیازی به تکرار نیست).
  • RewriteCond %{HTTP_REFERER} !^$: شرط می‌گذارد که اگر درخواست‌کننده (Referer) خالی نبود…
  • RewriteCond %{HTTP_REFERER} !^…: …و آن درخواست‌کننده، دامنه yourdomain.com (با یا بدون www و http/https) نبود…
  • RewriteRule \.(jpg…)$ – [F,L]: … هر درخواستی برای فایل‌هایی با این پسوندها را با خطای 403 Forbidden ([F]) مسدود کن.

نکته تجربی: حتماً yourdomain.com را با آدرس دامنه واقعی خودتان جایگزین کنید.

محافظت از فایل‌های حیاتی (مانند wp-config.php و خود .htaccess)

برخی فایل‌ها در ریشه سایت شما (مثل public_html) وجود دارند که نباید هرگز از طریق مرورگر قابل دسترسی باشند. مهم‌ترین آن‌ها wp-config.php (که حاوی رمز عبور پایگاه داده شماست!) و خود فایل .htaccess است.

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

کد محافظت از فایل‌های حساس (برای آپاچی 2.4 به بالا):

Apache

<FilesMatch “^(\.htaccess|wp-config\.php|readme\.html|xmlrpc\.php)$”>

Require all denied

</FilesMatch>

• توضیح کد:
  • <FilesMatch “…”>: یک بلوک تعریف می‌کند که برای فایل‌هایی با نام‌های مشخص شده (.htaccess, wp-config.php و غیره) اعمال شود.
  • Require all denied: به سرور دستور می‌دهد که «هرگونه درخواستی» (all) برای این فایل‌ها را «رد کن» (denied).

نکته: اگر از هاست بسیار قدیمی با آپاچی 2.2 استفاده می‌کنید، به جای Require all denied باید از Order allow,deny و Deny from all استفاده کنید، اما کد بالا روی ۹۹٪ هاست‌های مدرن کار می‌کند.

افزودن هدرهای امنیتی (X-Content-Type-Options, HSTS)

هدرهای امنیتی، دستورالعمل‌هایی هستند که سرور شما به مرورگر کاربر می‌فرستد تا به او بگوید چطور با سایت شما رفتار کند. این کار جلوی حملات پیشرفته‌تری مثل Clickjacking و MIME-sniffing را می‌گیرد.

۱. HSTS (Strict-Transport-Security): این هدر به مرورگر می‌گوید: «تا یک سال آینده، فقط و فقط از طریق HTTPS به من وصل شو و هرگز سعی نکن با HTTP ارتباط بگیری.» این کار جلوی حملات “SSL Stripping” را می‌گیرد.

۲. X-Content-Type-Options: این هدر به مرورگر می‌گوید: «به محتوای فایل‌ها اعتماد نکن (Sniff نکن). اگر من گفتم این فایل text/css است، تو هم باید آن را text/css در نظر بگیری، نه اینکه حدس بزنی شاید یک اسکریپت مخرب باشد.»

کد افزودن هدرهای امنیتی (نیاز به mod_headers دارد):

Apache

<IfModule mod_headers.c>

# (HSTS) – سایت را مجبور به استفاده از SSL می‌کند

# هشدار: فقط زمانی فعال کنید که ۱۰۰٪ مطمئن هستید SSL شما همیشه فعال است

Header set Strict-Transport-Security “max-age=31536000; includeSubDomains” env=HTTPS

 

# (X-Content-Type-Options) – جلوگیری از MIME-sniffing

Header set X-Content-Type-Options “nosniff”

 

# (X-Frame-Options) – جلوگیری از Clickjacking (اجازه نمی‌دهد سایت شما در Iframe باز شود)

Header set X-Frame-Options “SAMEORIGIN”

</IfModule>

• هشدار جدی در مورد HSTS: فعال‌سازی HSTS (خط Strict-Transport-Security) یک تعهد بلندمدت است (max-age=31536000 یعنی یک سال). اگر SSL شما منقضی شود یا به مشکلی بخورد، سایت شما تا یک سال برای کاربرانی که قبلاً بازدید کرده‌اند، کاملاً از دسترس خارج می‌شود. فقط زمانی این خط را اضافه کنید که از SSL خود کاملاً مطمئن هستید.

مسدود کردن IPهای مخرب و ربات‌های اسپم برای حفظ منابع سرور

گاهی اوقات می‌بینید که یک IP خاص در حال تلاش برای ورود به مدیریت سایت شما (Brute Force Attack)، اسپم گذاشتن در کامنت‌ها، یا اسکرپ کردن (Scraping) بیش از حد محتوای شماست. این ربات‌ها منابع سرور شما را مصرف می‌کنند و سایت را کند می‌کنند.

ساده‌ترین راه، مسدود کردن (Block) مستقیم آن IP در همان سطح .htaccess است تا درخواستش اصلاً به وردپرس یا PHP نرسد.

کد مسدود کردن IP (برای آپاچی 2.4):

Apache

<RequireAll>

Require all granted

# مسدود کردن یک IP خاص

Require not ip 123.45.67.89

# مسدود کردن یک ربات اسپم دیگر

Require not ip 98.76.54.32

# مسدود کردن یک رنج IP

Require not ip 192.168.1.0/24

</RequireAll>

• توضیH کد:
  • Require all granted: اول به همه اجازه دسترسی می‌دهد.
  • Require not ip …: سپس IPهای مشخص شده را استثنا کرده و مسدود می‌کند.

(اگر از آپاچی 2.2 استفاده می‌کنید، از کد زیر استفاده کنید):

Apache

Order Allow,Deny

Allow from all

Deny from 123.45.67.89

Deny from 98.76.54.32

Deny from 192.168.1.0/24

تکنیک‌های پیشرفته htaccess. برای بهینه‌سازی بودجه خزش (Crawl Budget)

«بودجه خزش» (Crawl Budget) همان مقدار منابع و زمانی است که ربات گوگل برای بررسی و ایندکس کردن صفحات سایت شما اختصاص می‌دهد. این بودجه محدود است. اگر گوگل‌بات (Googlebot) وقتش را صرف چرخیدن در صفحات تکراری، پارامترهای بی‌نهایت یا صفحات خطا کند، به صفحات اصلی و محتوای جدید شما نمی‌رسد.

اینجاست که .htaccess به ما کمک می‌کند تا مثل یک راهنمای تور حرفه‌ای، گوگل‌بات را مستقیماً به سمت محتوای باارزش هدایت کنیم و از هدر رفتن بودجه خزش جلوگیری کنیم.

مدیریت پارامترهای URL (Query Strings) برای جلوگیری از محتوای تکراری

این یکی از بزرگ‌ترین قاتلان بودجه خزش است. پارامترهای URL (Query Strings) همان بخش‌هایی هستند که بعد از علامت سوال (?) در آدرس می‌آیند و معمولاً برای ردیابی (مثل UTMها)، فیلتر کردن محصولات یا شناسایی سِشِن (Session) کاربر استفاده می‌شوند.

مشکل کجاست؟ از نظر گوگل، این سه آدرس، سه صفحه کاملاً متفاوت هستند، در حالی که هر سه یک محتوا را نشان می‌دهند:

• https://yoursite.com/blog/my-post/
• https://yoursite.com/blog/my-post/?utm_source=google (محتوای تکراری)
• https://yoursite.com/blog/my-post/?fbclid=… (محتوای تکراری)

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

راه حل در .htaccess (با احتیاط فراوان): می‌توانیم به سرور دستور دهیم که تمام پارامترهای URL را نادیده بگیرد و کاربر (و گوگل) را به نسخه اصلی (بدون پارامتر) ریدایرکت کند.

کد حذف تمام Query Strings (نسخه اتمی!):

Apache

RewriteEngine On

# اگر آدرس درخواستی یک فایل یا پوشه واقعی روی سرور نبود…

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

# و اگر آدرس حاوی پارامتر (Query String) بود…

RewriteCond %{QUERY_STRING} .

# آنگاه، کاربر را به همان آدرس اما بدون پارامتر (علامت ؟ در انتها) ریدایرکت ۳۰۱ کن

RewriteRule ^(.*)$ /$1? [R=301,L]

• توضیح کد:
  • RewriteCond %{QUERY_STRING} .: شرط می‌گذارد که «اگر رشته پارامتر خالی نبود» (حداقل یک کاراکتر داشت).
  • RewriteRule ^(.*)$ /$1?: دستور اصلی ریدایرکت است. $1 همان آدرس قبل از علامت سوال است. گذاشتن علامت ? خالی در انتهای آدرس مقصد، یک ترفند آپاچی برای «حذف کردن» تمام پارامترهای قبلی است.

هشدار و بینش عملی: این کد بسیار قدرتمند و خطرناک است. اگر سایت شما برای کارکردهای اصلی (مثل جستجوی داخلی، فیلتر محصولات یا صفحه‌بندی) به پارامترهای URL وابسته است، این کد آن‌ها را هم می‌شکند! در ۹۹٪ مواقع، راه حل بهتر و ایمن‌تر، استفاده از تگ rel=”canonical” در صفحاتتان است تا به گوگل بگویید نسخه اصلی کدام است، نه اینکه پارامترها را به زور حذف کنید.

تنظیم صفحات خطای سفارشی (404, 503) برای تجربه کاربری بهتر

نحوه مدیریت خطاها هم بر تجربه کاربری (UX) و هم بر بودجه خزش تأثیر مستقیم دارد.

• صفحه ۴۰۴ (Not Found): وقتی کاربر (یا گوگل) به آدرسی می‌رود که وجود ندارد، دیدن یک صفحه خطای زشت و پیش‌فرض سرور، حس بسیار بدی می‌دهد. کاربر سایت را می‌بندد و گوگل هم متوجه می‌شود که این صفحه وجود ندارد (که این خوب است).
• صفحه ۵۰۳ (Service Unavailable): این کد برای سئو حیاتی است. اگر سایت شما برای «تعمیر و نگهداری» (Maintenance) موقتاً از دسترس خارج است، نباید خطای ۴۰۴ یا ۲۰۰ (صفحه سفید) برگردانید. باید کد ۵۰۳ برگردانید. این کد به گوگل می‌گوید: «من موقتاً در دسترس نیستم، لطفاً بعداً دوباره سر بزن». گوگل‌بات برمی‌گردد و سایت شما را از ایندکس حذف نمی‌کند.

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

کد تنظیم صفحات خطای سفارشی:

Apache

# صفحه پیدا نشد (404)

ErrorDocument 404 /errors/404.html

 

# دسترسی ممنوع (403)

ErrorDocument 403 /errors/403.html

 

# خطای داخلی سرور (500)

ErrorDocument 500 /errors/500.html

 

# در دست تعمیر (503)

ErrorDocument 503 /errors/503.html

• توضیح کد:
  • ErrorDocument: دستور اصلی است.
  • 404: کد خطا.
  • /errors/404.html: مسیر از ریشه (Root) سایت به فایل HTML که طراحی کرده‌اید. (شما باید این فایل‌ها را بسازید).

نکته تجربی: صفحه ۴۰۴ سفارشی شما باید به کاربر کمک کند. حتماً در آن یک نوار جستجو، لینک به صفحه اصلی و شاید لینک به چند مقاله محبوب قرار دهید تا کاربر را در سایت نگه دارید.

ریدایرکت کاربران موبایل به نسخه‌ی موبایل سایت (در صورت وجود)

یک مقدمه مهم: این تکنیک امروزه تقریباً منسوخ شده محسوب می‌شود. در دنیای «طراحی واکنش‌گرا» (Responsive Design) و «ایندکس‌گذاری موبایل-اول» (Mobile-First Indexing)، گوگل اکیداً توصیه می‌کند که یک نسخه واحد از سایت داشته باشید که در دسکتاپ و موبایل به خوبی نمایش داده شود.

اما اگر شما سایتی قدیمی دارید که هنوز از نسخه جداگانه موبایل (مثل m.yoursite.com) استفاده می‌کند، باید کاربران را به درستی هدایت کنید. اگر کاربر موبایل وارد سایت دسکتاپ (www) شود، تجربه بدی خواهد داشت.

راه حل در .htaccess: ما می‌توانیم «عامل کاربر» (User-Agent) مرورگر را بررسی کنیم. اگر نشانه‌های مرورگر موبایل (مثل android, iphone) را داشت، او را به زیردامنه m ریدایرکت کنیم.

کد ریدایرکت کاربران موبایل به سایت m.:

Apache

RewriteEngine On

 

# شرط ۱: چک کن که هاست (دامنه) فعلی، خود m. نباشد (برای جلوگیری از لوپ بی‌نهایت)

RewriteCond %{HTTP_HOST} !^m\. [NC]

 

# شرط ۲: چک کن که User-Agent یکی از مرورگرهای موبایلی رایج باشد

RewriteCond %{HTTP_USER_AGENT} (android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge\ |maemo|midp|mmp|mobile.+firefox|netfront|opera\ m(ob|in)i|palm(\ os)?|phone|p(ixi|rim)|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows\ ce|xda|xiino [NC]

 

# اگر دو شرط بالا برقرار بود: کاربر را به همان صفحه در دامنه m. ریدایرکت کن

RewriteRule ^(.*)$ https://m.yoursite.com/$1 [L,R=301]

• توضیح کد:
  • این کد ابتدا چک می‌کند که کاربر روی دامنه www یا دامنه اصلی باشد (نه m).
  • سپس با یک عبارت منظم (Regex) طولانی، چک می‌کند که آیا User-Agent کاربر، نشانه‌های موبایل را دارد یا خیر.
  • اگر هر دو شرط درست بود، او را با ریدایرکت ۳۰۱ به همان آدرس در زیردامنه m می‌فرستد.

تکرار می‌کنم: این فقط برای سایت‌های قدیمی با ساختار m. است. اگر سایت شما ریسپانسیو است، هرگز از این کد استفاده نکنید.

اشتباهات رایج در ویرایش htaccess. که سئوی شما را نابود می‌کند (بر اساس تجربه)

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

خطای مرگبار 500 (Internal Server Error) و نحوه رفع سریع آن

این ترسناک‌ترین خطایی است که بعد از زدن دکمه «Save» در فایل .htaccess می‌توانید ببینید.

این خطا چیست؟ خطای ۵۰۰ به این معنی است که سرور شما در خواندن و تفسیر دستورات فایل .htaccess دچار مشکل اساسی شده است. برخلاف خطای ۴۰۴ (که فقط می‌گوید یک صفحه پیدا نشد)، خطای ۵۰۰ می‌گوید کل سایت من در حال حاضر به دلیل یک مشکل فنی داخلی از کار افتاده است.

دلیل رایج آن (بر اساس تجربه): دلیل آن ۹۹.۹٪ مواقع یک خطای نگارشی (Syntax Error) ساده در کدی است که همین الان اضافه کرده‌اید:

• یک فاصله اضافی یا کم.
• یک کاراکتر اشتباه (( به جای { یا یک خطای تایپی ساده).
• نوشتن یک دستور در خط اشتباه.
• کپی کردن کدی که برای نسخه‌های متفاوت آپاچی (مثلاً ۲.۲ به جای ۲.۴) نوشته شده است.

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

نحوه رفع سریع (در ۳۰ ثانیه): نفس عمیق بکشید. خوشبختانه، چون شما قبل از ویرایش بکاپ گرفته‌اید (گرفته‌اید، نه؟)، رفع آن بسیار ساده است:

1. فوراً از طریق FTP یا File Manager هاست، به سراغ فایل .htaccess بروید.
2. ساده‌ترین کار: فایل .htaccess معیوب فعلی را حذف کنید (یا نامش را به .htaccess_broken تغییر دهید).
3. فایل بکاپی که دانلود کرده بودید را مجدداً آپلود کنید و نام آن را به .htaccess برگردانید.
4. سایت شما بلافاصله برمی‌گردد. حالا در کمال آرامش، فایل معیوب را روی کامپیوتر خود باز کنید و ببینید مشکل کجای آن کدی بود که اضافه کردید.

ایجاد حلقه‌های ریدایرکت (Redirect Loops) و شناسایی آن‌ها

این اشتباهی است که باعث می‌شود مرورگر کاربر (و گوگل‌بات) گیج شود و مدام دور خودش بچرخد.

این خطا چیست؟ حلقه ریدایرکت (که مرورگر آن را با خطای ERR_TOO_MANY_REDIRECTS نشان می‌دهد) زمانی رخ می‌دهد که شما دستورات متناقضی را در فایل .htaccess قرار می‌دهید.

• مثال کلاسیک:
  1. شما یک قانون می‌نویسید که صفحه A را به صفحه B ریدایرکت ۳۰۱ کند.
  2. همزمان (شاید فراموش کرده‌اید)، یک قانون دیگر هم دارید که صفحه B را به صفحه A ریدایرکت می‌کند!

یا یک مثال رایج‌تر:

1. یک قانون برای ریدایرکت HTTP به HTTPS می‌نویسید.
2. یک قانون دیگر (شاید در پلاگین) دارید که همزمان HTTPS را به HTTP ریدایرکت می‌کند!

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

شناسایی: بهترین راه، استفاده از ابزارهای آنلاین مثل Redirect-Checker.org است. آدرس URL خود را وارد کنید. این ابزارها به شما «زنجیره ریدایرکت» را نشان می‌دهند و به وضوح مشخص می‌کنند که حلقه دقیقاً بین کدام دو آدرس در حال رخ دادن است.

ترتیب اشتباه دستورات: چرا «ترتیب» در htaccess. اهمیت دارد؟

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

این اشتباه چیست؟ قرار دادن یک دستور خاص، بعد از یک دستور کلی.

• مثال: فرض کنید شما می‌خواهید آدرس /page-old.html را به /page-new/ ریدایرکت کنید. همزمان، شما بلوک کدهای وردپرس را هم در انتهای فایل خود دارید (همان # BEGIN WordPress …).
• اشتباه: اگر ریدایرکت ۳۰۱ خود را بعد از بلوک وردپرس قرار دهید، ممکن است هرگز اجرا نشود!
• چرا؟ چون سرور ابتدا به بلوک وردپرس می‌رسد. وردپرس آدرس /page-old.html را می‌گیرد، می‌بیند چنین صفحه‌ای وجود ندارد و آن را به صفحه ۴۰۴ خود ریدایرکت می‌کند. سرور هرگز به دستور ریدایرکت ۳۰۱ شما که در خطوط پایین‌تر بود، نمی‌رسد.

قانون کلی بر اساس تجربه:

1. بالاترین اولویت: دستورات بازنویسی (RewriteEngine On) و ریدایرکت‌های سراسری (مثل HTTP به HTTPS یا www به non-www) باید در بالاترین بخش فایل باشند.
2. اولویت دوم: ریدایرکت‌های ۳۰۱ تکی (صفحه به صفحه) باید بعد از آن‌ها و قبل از بلوک‌های CMS (مثل وردپرس) قرار گیرند.
3. پایین‌ترین اولویت: کدهای کش، هدرهای امنیتی و بلوک‌های پیش‌فرض CMS معمولاً در انتهای فایل قرار می‌گیرند.

استفاده از ریدایرکت 302 به جای 301 و آسیب آن به رتبه‌بندی

این یکی از ظریف‌ترین و در عین حال مخرب‌ترین اشتباهات سئویی است که مستقیماً در .htaccess رخ می‌دهد.

• ریدایرکت ۳۰۱ (Moved Permanently): به گوگل می‌گوید: «من برای همیشه به این آدرس جدید نقل مکان کردم. لطفاً تمام اعتبار، بک‌لینک‌ها و رتبه من را به آدرس جدید منتقل کن.» (این چیزی است که ما در ۹۹٪ مواقع می‌خواهیم).
• ریدایرکت ۳۰۲ (Found / Moved Temporarily): به گوگل می‌گوید: «من موقتاً در این آدرس جدید هستم (شاید برای تست A/B یا تعمیرات)، اما آدرس اصلی من همان آدرس قبلی است. لطفاً اعتبار را منتقل نکن و هفته بعد دوباره به همان آدرس قبلی سر بزن.»

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

آسیب سئویی: اگر شما یک صفحه قدیمی را (که کلی اعتبار و بک‌لینک دارد) با ریدایرکت ۳۰۲ به صفحه جدید منتقل کنید، شما عملاً به گوگل می‌گویید: «هیچ اعتباری را منتقل نکن». در نتیجه:

1. صفحه جدید شما بدون اعتبار، در رتبه‌بندی جایی نخواهد داشت.
2. صفحه قدیمی شما همچنان در ایندکس گوگل باقی می‌ماند (اما چون در دسترس نیست، به تدریج رتبه‌اش را از دست می‌دهد).
3. شما تمام ارزش سئویی صفحه قدیمی را دور ریخته‌اید.

راه حل: همیشه، همیشه، و همیشه مطمئن شوید که برای انتقال‌های دائمی، به صراحت از کد 301 یا فلگ [R=301] در دستورات خود استفاده می‌کنید.

جمع‌بندی (نتیجه‌گیری)

همان‌طور که با هم دیدیم، فایل .htaccess بسیار بیشتر از یک فایل پیکربندی ساده است؛ این ابزار، بخش مهمی از جعبه ابزار سئوی فنی ماست. از هدایت درست اعتبار صفحات با ریدایرکت‌های ۳۰۱ گرفته تا بهبود تجربه کاربری با افزایش سرعت لود (از طریق کش و Gzip) و ساختن دیوارهای امنیتی قوی، همه‌چیز به درک درست ما از این فایل بستگی دارد.

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