[wd_asp id=1]
فرض کنید محل زندگی یا دفتر شرکت خود را برای همیشه تغییر دادهاید، اما مشتریان، نامهها و مرسولهها همچنان به نشانی قبلی شما فرستاده میشوند. بستن محل قدیمی مشکل را حل نمیکند؛ چون فرستنده از نشانی جدید شما خبر ندارد و بستهها نیز به مقصد نمیرسند و برگشت میخورند. برای جلوگیری از این اتفاق یک راح حل این است که شما از پست درخواست میکنید هر مرسولهای که به نشانی قبلی میآید، مستقیماً به محل جدید شما تحویل داده شود.
همین جابهجایی در دنیای آنلاین نیز اتفاق میافتد. کاربران ممکن است از طریق نتایج جستجو، بکلینکها، بوکمارکها یا تبلیغات وارد URL قدیمی شوند. رباتهای گوگل نیز این آدرس را از لینکهای داخلی و خارجی میشناسند. اگر صفحه را بدون تعیین مسیر جدید حذف کنید، بخشی از این ورودیها با خطای ۴۰۴ روبهرو میشوند؛ اما اگر مقصدی مرتبط وجود داشته باشد، ریدایرکت ۳۰۱ کاربر و رباتهای گوگل را به آن هدایت میکند.
گوگل برای تغییر دائمی نشانی صفحات، استفاده از ریدایرکت دائمی سمت سرور را پیشنهاد میکند.[۱]
«اگر لازم است URL نمایشدادهشده در نتایج جستجو تغییر کند، تا حد امکان از ریدایرکت دائمی سمت سرور استفاده کنید.»
ریدایرکت ۳۰۱ زمانی انتخاب درستی است که انتقال دائمی باشد و URL قدیمی یک جایگزین واقعی و مرتبط داشته باشد. اجرای این انتقال فقط فقط اعمال یک ریدایرکت نیست؛ تصمیم اشتباه میتواند مسیر ورود کاربر، اعتبار بکلینکها و فرصت تبدیل بازدیدکننده به لید یا مشتری را از بین ببرد.
ریدایرکت 301 ، Moved Permanently یک کد وضعیت HTTP است. سرور با ارسال این پاسخ اعلام میکند که آدرس درخواستشده برای همیشه به URL دیگری منتقل شده است.
در پاسخ سرور، Header با نام Location نشانی مقصد را مشخص میکند. مرورگر یا رباتهای گوگل پس از دریافت این پاسخ، URL جدید را درخواست میکنند و به آن مراجعه میکنند.[۲]
مسیر درست معمولاً چنین است:
Old URL → 301 → New URL → 200 OKدر این مسیر، URL قدیمی پاسخ ۳۰۱ میدهد و مقصد نهایی با پاسخ ۲۰۰ در دسترس است. اگر مقصد نیز ریدایرکت شود، زنجیرهای از ریدایرکتها ایجاد خواهد شد. اگر مقصد پاسخ ۴۰۴ یا 5XX بدهد، انتقال به یک صفحه خراب ختم شده است.
وقتی کاربر URL قدیمی را باز میکند، سرور بهجای نمایش محتوای آن، پاسخ ۳۰۱ و نشانی مقصد را ارسال میکند. مرورگر معمولاً این فرایند را در مدت کوتاه انجام میدهد؛ به همین دلیل ممکن است کاربر فقط URL نهایی را ببیند.
رباتهای گوگل نیز پاسخ را بررسی میکنند. گوگل ریدایرکت دائمی را سیگنالی قوی برای انتخاب URL مقصد بهعنوان نسخه کانونیکال صفحه در نظر میگیرد؛ بااینحال، انتخاب نهایی گوگل برای نمایش صفحه مقصد در نتایج، فقط به وجود یک قانون ۳۰۱ وابسته نیست. لینکهای داخلی، Sitemap، تگ Canonical و ارتباط محتوایی صفحات نیز باید با مقصد جدید هماهنگ باشند.[۳]
تغییر لینک داخلی و ایجاد ریدایرکت، دو اقدام متفاوت هستند. ریدایرکت، درخواست URL قدیمی را به مقصد جدید میفرستد؛ اما اصلاح لینک باعث میشود کاربر و رباتهای گوگل از ابتدا URL نهایی را درخواست کنند.
برای نمونه، اگر نشانی یک مقاله تغییر کرده باشد، باید دو کار انجام شود:
درنتیجه ریدایرکت یک صفحه به صفحه جدید، دو اقدام صحیح و خطای زیر از وبمستران و سئوکاران دیده میشود:
❌ نگهداری تمام لینکهای داخلی قدیمی و اتکا به ریدایرکت انجام شده
✅ اصلاح لینکها و نگهداری ۳۰۱ برای ورودیهای خارجی و آدرسهای قدیمی
این هماهنگی یکی از بخشهای مهم سئو تکنیکال است؛ زیرا ساختار URL، پاسخ سرور، Canonical و لینکهای داخلی باید یک مقصد واحد را معرفی کنند.
ریدایرکت دائمی به گوگل کمک میکند ارتباط میان URL قدیمی و جدید را تشخیص دهد. این انتقال میتواند سیگنالهای صفحه قبلی را با مقصد جدید هماهنگ کند؛ اما نباید آن را تضمینی برای انتقال کامل رتبه، ترافیک یا اعتبار تمام بکلینکها دانست.
نتیجه به کیفیت اجرای انتقال، شباهت مبدأ و مقصد، امکان خزش، وضعیت ایندکس و هماهنگی سایر سیگنالهای سئو وابسته است. انتقال یک مقاله به نسخه جدید همان مقاله با انتقال آن به صفحه اصلی یکسان نیست.( این اشتباهی است که از بسیاری از وبمستران دیده میشود)
اگر URL قدیمی بکلینک معتبری داشته باشد، ریدایرکت مستقیم به یک مقصد معادل میتواند سیگنالهای آن را به URL جدید متصل کند. بااینحال، وجود بکلینک بهتنهایی مجوز انتقال صفحه به هر مقصدی نیست.
فرض کنید یک مقاله قدیمی درباره تحقیق کلمات کلیدی در سایت خود داشته اید که حذف شده است:
این دو اقدام ممکن است از سمت شما انجام شود:
✅ انتقال آن به نسخه جدید و کاملتر همان راهنما
❌ انتقال آن به صفحه اصلی، صفحه خدمات طراحی سایت یا مقالهای نامرتبط
گوگل انتقال گروه بزرگی از URLهای قدیمی به مقصدی نامرتبط، مانند صفحه اصلی، را اقدامی گمراهکننده میداند و ممکن است چنین انتقالی را Soft ۴۰۴ تشخیص دهد.[۴]
پس از اجرای ۳۰۱، ممکن است URL قدیمی برای مدتی در نتایج یا گزارشهای سرچ کنسول دیده شود. گوگل باید مبدأ، پاسخ ریدایرکت و مقصد را دوباره بررسی کند و سیگنالهای مربوط به صفحات را پردازش کند. بنابراین جایگزینی URLها همیشه فوری نیست.
در ریدایرکتها دستهجمعی نیز نوسان موقت رتبه یا ترافیک ممکن است رخ دهد. اگر URL Mapping اشتباه باشد، صفحات جدید پاسخ درستی ندهند یا منابع لازم برای رباتهای گوگل مسدود شوند، این نوسان میتواند به یک مشکل بسیار بزرگ تبدیل شود.
ارزش ریدایرکت فقط به ایندکس شدن آدرس جدید محدود نمیشود. URL قدیمی ممکن است در تبلیغات، شبکههای اجتماعی، پیامک، ایمیل، فایل PDF یا سایتهای دیگر قرار گرفته باشد. حذف آن بدون انتقال درست میتواند مسیر ورود مشتری بالقوه را قطع کند.
برای سنجش نتیجه ریدایرکت، باید علاوهبر کلیک و Impression، رفتار کاربر در مقصد نیز بررسی شود. Google Analytics مسیر و تبدیل را نشان میدهد و Microsoft Clarity میتواند برای مشاهده رفتار کاربران، نقاط کلیک و نقاط ریزش کاربران استفاده شود. ابزار یک شاخص ارائه میکند؛ تصمیم نهایی باید براساس دادههای معتبر فنی و تخصصی گرفته شود. ( انجام ریدایرکت مانند انجام عمل bypass در جراحی قبل باز است، با حذف شاخه معیوب، باید بدانید از کجا به کجا ارتباطی برقرار میکنید. به همین دلیل است که انجام ریدایرکت یک تصمیم استراتژیک در نظر گرفته میشود.)
دو شرط اصلی برای استفاده از ریدایرکت ۳۰۱ وجود دارد:
اگر یکی از این شرایط برقرار نباشد، ممکن است ۳۰۲، ۳۰۷، ۴۰۴، ۴۱۰ یا نگهداری پاسخ ۲۰۰ انتخاب مناسبتری باشد.
اگر اسلاگ مقاله، محصول یا لندینگپیج تغییر کرده است، URL قبلی باید مستقیماً به نشانی جدید منتقل شود. سپس تمام لینکهای داخلی، Canonical و Sitemap نیز باید به نسخه جدید اشاره کنند.
برای نمونه:
/old-seo-course/ → 301 → /seo-course/پیش از تغییر URL یک صفحه دارای رتبه، باید دلیل سئویی و فنی مشخصی وجود داشته باشد. کوتاهتر یا زیباترشدن آدرس، همیشه ارزش ریسک جابهجایی را ندارد.
اگر چند صفحه یک نیاز جستجوی مشابه را پاسخ میدهند، ممکن است میان آنها کنیبالیزیشن ایجاد شده باشد. در این وضعیت ابتدا باید محتوای ارزشمند صفحات در یک مقصد کامل ادغام شود؛ سپس URLهای قدیمی به آن منتقل شوند.
ریدایرکت نباید قبل از انتقال بخشهای مفید محتوا اجرا شود. در غیر این صورت، کاربری که انتظار اطلاعات قبلی را دارد به صفحهای ناقص میرسد.
در انتقال سایت به دامنه جدید، باید برای هر URL قدیمی نزدیکترین معادل آن در دامنه جدید مشخص شود. انتقال تمام صفحات به صفحه اصلی دامنه جدید، جایگزین URL Mapping نیست.
در یک انتقال گروهی صحیح، موارد زیر هماهنگ میشوند:
گوگل توصیه میکند در اینگونه مهاجرت url ، ریدایرکتهای دائمی سمت سرور به مقصد نهایی ایجاد و از ترکیب چند انتقال متوالی جلوگیری شود.[۵]
نسخههای HTTP باید به معادل HTTPS خود منتقل شوند. همین اصل برای یکپارچهکردن نسخههای www و بدون www نیز کاربرد دارد.
http → https://www → https://non-www ❌ حذف یک URL همیشه به معنای نیاز به ۳۰۱ نیست. تصمیم درست به وضعیت جایگزین بستگی دارد:
انتقال دائمی در سناریوهای موقت یا بدون مقصد مرتبط میتواند سیگنال اشتباهی به کاربر و موتور جستجو ارسال کند. در ادامه درباره هرکدام از این موارد توضیحاتی ارائه شده است.
اگر صفحه پس از مدت مشخصی بازمیگردد، نباید دائمیبودن انتقال را اعلام کرد. در این وضعیت، ریدایرکت ۳۰۲ یا ۳۰۷ براساس نوع درخواست انتخاب میشود.
برای نمونه، انتقال موقت کاربران در زمان تعمیر یا بازطراحی یک لندینگپیج، دلیل کافی برای ایجاد ۳۰۱ نیست.
اگر صفحه حذف شده و جایگزین معادل ندارد، ۴۰۴ یا ۴۱۰ پاسخ بهتری است. صفرکردن تعداد خطاهای ۴۰۴ در سرچ کنسول هیچ وقت یک KPI سئو نیست، باید مشخص شود کدام URL ناخواسته حذف شده و کدام صفحه واقعاً دیگر وجود ندارد.
انتقال همه محصولات، مقالات یا دستههای حذفشده به صفحه اصلی میتواند کاربر را سردرگم کند. صفحه اصلی معمولاً پاسخ همان نیازی را نمیدهد که URL قبلی برای آن ساخته شده بود.
اگر ۵۰ محصول قدیمی در یک دسته حذف شدهاند، فقط زمانی میتوان آنها را به یک مقصد مشترک منتقل کرد که محتوای آنها واقعاً در صفحهای مرتبط ادغام شده باشد.
گوگل برای تستهایی که کاربر را از URL اصلی به نسخه آزمایشی میفرستند، استفاده از ۳۰۲ را توصیه میکند. این کد نشان میدهد انتقال فقط در مدت آزمایش برقرار است و URL اصلی باید در ایندکس حفظ شود.[۶]
انتخاب کد به دائمی یا موقتیبودن انتقال و رفتار موردنیاز برای Method و شکل اجرای درخواست بستگی دارد. این تفاوت در صفحات عادی مبتنی بر GET ممکن است محسوس نباشد، اما برای فرمها، APIها و درخواستهای POST اهمیت دارد.
۳۰۱ انتقال دائمی را اعلام میکند؛ درحالیکه ۳۰۲ برای انتقال موقت استفاده میشود. گوگل در هر دو ریدایرکت، مقصد اعلام شده را دنبال میکند، اما در حالت دائمی انتظار میرود که URL مقصد بهعنوان نسخه اصلی جایگزین شود.
301: جابهجایی دائمی302: جابهجایی موقتانتخاب این دو نباید فقط براساس مدت اجرای ریدایرکت در افزونهها انجام شود. سؤال اصلی این است که آیا تصمیم انتقال برگشتپذیر است یا خیر.
هر دو کد انتقال دائمی را اعلام میکنند، اما ۳۰۸ اجازه تغییر Method و Body درخواست را نمیدهد. برخی User Agentها ممکن است پس از دریافت ۳۰۱ برای یک درخواست POST، درخواست بعدی را با GET ارسال کنند. کد ۳۰۸ برای حذف این ابهام ایجاد شده است.[۷]
برای صفحات محتوایی که با GET باز میشوند، ریدایرکت ۳۰۱ انتخاب رایجی است. در APIها یا مسیرهایی که حفظ POST و دادههای درخواست ضروری است، ۳۰۸ باید بررسی شود.
ریدایرکت ۳۰۱ کاربر و رباتهای گوگل را عملاً از URL قدیمی به مقصد میفرستد. تگ Canonical انتقال ایجاد نمیکند؛ بلکه نسخه ترجیحی را از میان صفحات تکراری یا بسیار مشابه پیشنهاد میدهد.
اگر هر دو صفحه باید برای کاربران در دسترس باشند، Canonical ممکن است مناسب باشد. اگر نشانی قدیمی دیگر نباید استفاده شود، ریدایرکت دائمی انتخاب بهتری است.
پیش از ساخت ریدایرکت ، وضعیت URL فعلی و مقصد آن را مشخص کنید. جدول زیر یک نقطه شروع برای تصمیمگیری در خصوص ریدایرکت صحیح است؛ هر URL مهم سایت باید براساس محتوا، بکلینک، ورودی و ارزش تجاری جداگانه بررسی شود.
| وضعیت URL | پاسخ مناسب | دلیل تصمیم | اقدام بعدی |
|---|---|---|---|
| انتقال دائمی با مقصد معادل | 301 | منبع برای همیشه منتقل شده است | اصلاح لینک داخلی، Canonical و Sitemap |
| انتقال موقت | 302 | URL اصلی باید حفظ شود | تعیین زمان بازگشت و کنترل نتیجه |
| انتقال موقت با حفظ Method | 307 | Method و Body نباید تغییر کند | آزمایش درخواست نهایی |
| انتقال دائمی با حفظ Method | 308 | انتقال دائمی برای درخواست غیر GET | کنترل سازگاری فنی |
| حذف بدون جایگزین | ۴۰۴ یا ۴۱۰ | مقصد مرتبطی وجود ندارد | حذف URL از Sitemap و اصلاح لینکها |
| صفحه معتبر و فعال | 200 | محتوا همچنان در همان نشانی قرار دارد | حفظ و بهبود صفحه |
| صفحات مشابه و قابلدسترسی | ۲۰۰ همراه Canonical مناسب | هر دو URL برای کاربر لازم هستند | هماهنگی سیگنالهای کانونیکال |
در وردپرس میتوان ریدایرکت را با افزونه، قابلیتهای خود CMS یا تنظیمات سرور اجرا کرد. در هرکدام از این موارد، ابزارها، فقط ریدایرکتهای تعیینشده را اجرا میکند و نمیتواند مرتبطبودن مقصد یا ارزش تجاری URL را تشخیص دهد.
پیش از ایجاد ریدایرکت، یک فهرست شامل URL مبدأ، مقصد، دلیل انتقال و تاریخ اجرا تهیه کنید. پس از اجرا نیز پاسخ واقعی سرور را آزمایش کنید.
در افزونه Redirection معمولاً این مراحل طی میشود:
Tools → Redirection شوید.در قوانین مبتنی بر Regex باید دامنه دقیقا متناظر باشد. یک الگوی اشتباه ممکن است گروه بزرگی از URLهای سالم را نیز منتقل کند.
در Rank Math، ماژول Redirections باید فعال باشد. سپس از بخش Rank Math SEO → Redirections میتوان قانون جدید ساخت و URL مبدأ، مقصد و نوع انتقال را مشخص کرد.
چراغ یا پیام موفق افزونه فقط ثبت قانون را نشان میدهد. برای اطمینان باید URL را خارج از پنل وردپرس باز و Header آن را بررسی کنید.
وردپرس در برخی شرایط اسلاگ قدیمی نوشته را در متادیتای _wp_old_slug نگهداری میکند. تابع wp_old_slug_redirect() تلاش میکند درخواست نامک قبلی را به پیوند فعلی نوشته منتقل کند.[۸]
این قابلیت مفید است، اما نباید بدون آزمایش به آن اتکا کرد. شباهت نامکها، تغییر نوع محتوا یا وجود قوانین دیگر میتواند نتیجه متفاوتی ایجاد کند.
اگر به تنظیمات سرور دسترسی دارید، میتوانید ریدایرکت را در Apache یا Nginx اجرا کنید. قبل از ویرایش فایل پیکربندی، نسخه پشتیبان بگیرید و امکان بازگرداندن تغییر را حفظ کنید. یک خطای کوچک هم میتواند دسترسی کل سایت را مختل کند.
در سرور Apache میتوان از دستور RedirectPermanent در فایل .htaccess استفاده کرد. مستندات Apache این دستور را معادل Redirect permanent و دارای پاسخ ۳۰۱ معرفی میکند.[۹]
RedirectPermanent /old-page/ https://example.com/new-page/برای انتقال دامنه و حفظ مسیرها ممکن است به قوانین mod_rewrite نیاز باشد که نمونه آنها در زیر درج شده است:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-example\.com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]در این نمونه باید با ساختار واقعی دامنه، HTTPS، مسیرها و تنظیمات سرور تطبیق داده شود. فایل htaccess محل اجرای قوانین مهمی است و تغییر آزمایشی آن روی سایت اصلی توصیه نمیشود.
در PHP میتوان Header مقصد و کد وضعیت را ارسال کرد:
<?php
header('Location: https://example.com/new-page/', true, 301);
exit;ارسال Header باید پیش از خروجی HTML انجام شود. استفاده از exit نیز ادامه اجرای کد را متوقف میکند. مستندات وردپرس توضیح میدهد که wp_redirect() بهصورت خودکار اجرای برنامه را متوقف نمیکند و معمولاً باید پس از آن exit قرار گیرد.[۱۰]
اعمال ریدایرکتها از php متداول و مرسوم نیست.
در Nginx میتوان برای انتقال یک مسیر مشخص از return 301 استفاده کرد:
location = /old-page/ {
return 301 https://example.com/new-page/;
}پس از تغییر تنظیمات، ابتدا صحت پیکربندی را آزمایش و سپس سرویس را Reload کنید. روش دقیق اجرا به سطح دسترسی و معماری سرور وابسته است.
بازشدن صفحه مقصد برای تأیید صحت ریدایرکت کافی نیست. ممکن است مسیر شامل چند انتقال باشد، از ۳۰۲ بهجای ۳۰۱ استفاده شده باشد یا مقصد نهایی پاسخ ۴۰۴ بدهد.
برای مشاهده Header میتوان از دستور زیر استفاده کرد:
curl -I https://example.com/old-page/نتیجه مورد انتظار پس از ریدایرکت:
HTTP/2 301
location: https://example.com/new-page/برای دنبالکردن کل مسیر از دستور زیر استفاده کنید:
curl -IL https://example.com/old-page/ساختار مطلوب معمولاً چنین است:
301 → 200اگر چنین پاسخهایی را داشتید، باید ریدایرکتهای خود و لینکسازیهای داخلی انجام شده به صفحاتتان را مجدد چک کنید:
301 → 301 → 200
301 → 404
301 → 302 → 200در URL Inspection، نشانی قدیمی و جدید را جداگانه بررسی کنید. Test Live URL پاسخ فعلی را نشان میدهد؛ درحالیکه اطلاعات ایندکس ممکن است مربوط به آخرین بررسی گوگل باشد.
Search Console برای استخراج کامل تمام قوانین ریدایرکت سایت طراحی نشده است، اما برای بررسی برداشت گوگل از URLهای مهم کاربرد دارد. پس از انتقال، روند ایندکس صفحات سایت را بررسی کنید؛ درخواست ایندکس نیز تضمینی برای نمایش فوری URL جدید نیست.
برای بررسی تمام URLهای سایت، آن را Crawl کنید و URLهای 3XX، مقصدهای آنها و Inlinkهای منتهی به صفحات قدیمی را استخراج کنید. در گزارش باید این موارد بررسی شوند:
وجود تعداد زیادی لینک داخلی به URLهای ریدایرکتشده میتواند درخواستهای غیرضروری ایجاد کند. این موضوع بهویژه در سایتهای بزرگ و مدیریت بودجه خزش اهمیت بیشتری دارد.
بخش بزرگی از مشکلات، نه از خود کد ۳۰۱، بلکه از انتخاب مقصد یا نگهداری نادرست قوانین ایجاد میشود. تعدادی از این خطاها و روشهای اصلاح یا جایگزین آنها در ادامه درج شده است:
❌ انتقال تمام URLهای حذفشده به صفحه اصلی
✅ انتخاب مقصد معادل یا استفاده از ۴۰۴ و ۴۱۰
❌ باقیگذاشتن URL قدیمی در لینکهای داخلی
✅ اتصال مستقیم لینکها به URL جدید
❌ ایجاد مسیر A → B → C
✅ انتقال مستقیم A → C
❌ ریدایرکت به صفحه Noindex یا دارای خطای 5XX
✅ انتخاب مقصد فعال، قابلدسترسی و دارای پاسخ ۲۰۰
❌ درج URL قدیمی در Sitemap
✅ ثبت فقط URL نهایی و کانونیکال
❌ مسدودکردن URL قدیمی در robots.txt پیش از پردازش ریدایرکت
✅ فراهمکردن امکان درخواست URL و مشاهده پاسخ ۳۰۱ توسط رباتهای گوگل
❌ اجرای چند افزونه ریدایرکت با قوانین متناقض
✅ نگهداری قوانین قابلکنترل در یک محل مشخص
❌ ارزیابی موفقیت فقط با بازشدن مقصد
✅ کنترل Header، مسیر کامل، ایندکس، ترافیک و تبدیل
در مهاجرت سایت، گوگل توصیه میکند ریدایرکتها عموماً حداقل یک سال نگهداری شوند. این بازه به گوگل فرصت میدهد سیگنالهای URL قدیمی را به مقصد جدید منتقل کند.[۵]
یک سال به معنای ضرورت حذف قانون در روز بعد نیست. کاربران، سایتهای دیگر، فایلهای دانلودی و بوکمارکها ممکن است مدت بیشتری از URL قدیمی استفاده کنند. اگر نگهداری قانون ریدایرکت هزینه یا تعارض خاصی ایجاد نمیکند، حفظ طولانیتر آن میتواند از قطع این مسیرها جلوگیری کند.
پیش از حذف ریدایرکت باید بررسی شود:
موفقیت ریدایرکت با مشاهده کد ۳۰۱ آغاز میشود، اما به آن محدود نیست. انتقال باید از نظر فنی درست باشد و مسیر جذب ترافیک و درآمدزایی صفحه را نیز حفظ کند.
شاخصهای فنی عبارتاند از:
شاخصهای تجاری عبارتاند از:
کاهش کلیک پس از انتقال همیشه فقط از ریدایرکت ناشی نمیشود. تغییر محتوا، عنوان، تقاضای جستجو، رقبا و آپدیتهای گوگل نیز باید بررسی شوند. نتیجه قابلاعتماد از مقایسه دادههای قبل و بعد به دست میآید.
در یکی از پروژههای سئو مدیروب، یک سایت فعال در زمینه خرید و فروش کانکس، پروژه خود را برای سئو به ما واگذار کرد، در زمان قبول پروژه تقریبا سایت پنالتی بود و صفحات مهم سایت هیچکدام رتبهای در نتیجه اول سرپ نداشتند.
با بررسیهای انجام شده، مشخص شده که Topical Authority سایت بدون با هدف افزایش تعداد محتواهای سایت، بین صفحاتی که همپوشانی زیادی از نظر سئو معنایی داشتند، پخش شده بود. تیم مدیروب با بررسیهای تخصصی یکی از صفحات را به عنوان صفحه مادر یا Pillar در نظر گرفت و تصمیم بر ادغام و مرج محتواهای ضعیف سایت در این pillar گرفته شد.
پس از اضافه کردن محتواهای ضعیف در pillar، ریدایرکت ۳۰۱ از طریق اضافه کردن کد در فایل htaccess اجرا شد و تمام این صفحات در ۱ صفحه ادغام شدند.
برای اعمال ریدایکرت ما به ۳ شرط زیر نگاه کردیم:
در نهایت تعداد زیادی از صفحات به آدرس pillar ریدایرکت شدند، نکته جالب اینجاست، از اعمال ریدایرکت تا حصول نتایج و خروج سایت از پنالتی بیش از یک سال و ۳ آپدیت هسته، طول کشید.
پیش از ثبت هر ریدایرکت ۳۰۱، URL قدیمی، مقصد، دلیل انتقال و تاریخ اجرا را مشخص کنید. مقصد باید نیاز قبلی کاربر را پاسخ دهد و در حالت عادی دارای پاسخ ۲۰۰ باشد.
اگر انتقال موقت است، کد موقت انتخاب کنید. اگر جایگزین مرتبطی وجود ندارد، از ایجاد ریدایرکت ۴۰۴ یا ۴۱۰ نترسید. اگر انتقال دائمی است، ایجاد ریدایرکت با اضافه کردن یک قانون تمام نمیشود؛ لینکهای داخلی، Canonical، Sitemap، بکلینکهای مهم و مسیر تبدیل کاربر را نیز اصلاح کنید.
در مدیروب ما به این اصل باور داریم:
ریدایرکت خوب، کوتاهترین مسیر فنی میان دو URL و مرتبطترین مسیر محتوایی برای کاربر است.
ریدایرکت ۳۰۱ سیگنال قدرتمندی برای انتقال دائمی و انتخاب URL مقصد بهعنوان نسخه جایگزین است، اما انتقال کامل رتبه یا ترافیک تضمین نمیشود. ارتباط مقصد، لینکهای داخلی، Canonical، قابلیت خزش و کیفیت اجرای مهاجرت بر نتیجه اثر دارند.
در مدت کوتاه ممکن است نوسان ایجاد شود؛ زیرا گوگل باید URLها را دوباره بررسی و سیگنالها را پردازش کند. افت پایدار میتواند نتیجه مقصد نامرتبط، محتوای ناقص، زنجیره، خطای فنی یا ناهماهنگی سیگنالها باشد.
خیر. فقط URLهایی که منتقل شدهاند یا جایگزین مرتبط دارند باید ۳۰۱ شوند. برای صفحه حذفشده بدون جایگزین، ۴۰۴ یا ۴۱۰ پاسخ درستی است.
بله؛ به شرط آنکه محتوای صفحات واقعاً در یک مقصد مرتبط ادغام شده باشد. انتقال گروهی صفحات نامرتبط به صفحه اصلی یا یک دسته عمومی تصمیم مناسبی نیست.
بله. لینکها باید مستقیماً به URL جدید اشاره کنند. ریدایرکت برای حفظ مسیرهای قدیمی است و جایگزین اصلاح معماری داخلی سایت نیست.
خیر. ۳۰۱ کاربر و ربات را به مقصد میفرستد؛ اما Canonical فقط نسخه ترجیحی را پیشنهاد میکند و صفحه مبدأ همچنان قابلدسترسی باقی میماند.
در مهاجرت سایت، گوگل نگهداری حداقل یکساله را توصیه میکند. اگر URL قدیمی همچنان بکلینک یا ورودی دارد، حفظ طولانیتر قانون میتواند مفید باشد.
هر دو دائمی هستند، اما ۳۰۸ Method و Body درخواست را حفظ میکند. این تفاوت برای درخواستهای POST و APIها اهمیت دارد.
پاسخ URL مبدأ، Header مقصد، تعداد انتقالها و پاسخ نهایی را با curl یا ابزار بررسی Header کنترل کنید. نتیجه مطلوب معمولاً 301 → 200 است.
اثر آن به تعداد قوانین، روش ذخیرهسازی، کیفیت افزونه، منابع سرور و تعارض با سایر افزونهها وابسته است. صرف نصب افزونه برای تشخیص کندی کافی نیست؛ عملکرد سایت باید اندازهگیری شود.
این مقاله با گردآوری، تطبیق و بازنویسی مستندات رسمی Google Search Central، MDN، Apache و WordPress تدوین شده است. نمونههای اجرایی باید پیش از استفاده با محیط سرور و ساختار واقعی سایت تطبیق داده شوند.