ریدایرکت ۳۰۱ چیست؟ راهنمای مهاجرت URL بدون خطا

ریدایرکت ۳۰۱ فقط «فرستادن کاربر از آدرس قدیمی به جدید» نیست. یک پاسخ HTTP است که بر Method، Cache، Index، لینک‌ها، Analytics و حتی امنیت اثر می‌گذارد. اگر مقصد نامرتبط، Rule بیش‌ازحد گسترده یا زنجیره طولانی باشد، همان ابزاری که قرار بود مهاجرت را نجات دهد می‌تواند صدها URL را به Soft ۴۰۴، Loop یا مقصد اشتباه تبدیل کند.

در این راهنما می‌بینید ریدایرکت ۳۰۱ چیست، چه تفاوتی با ۳۰۲، ۳۰۳، ۳۰۷ و ۳۰۸ دارد، چه زمانی صفحه حذف‌شده باید ۴۰۴/۴۱۰ بماند، URL map چگونه ساخته می‌شود و Redirect در Apache، Nginx و WordPress چگونه با تست، مانیتورینگ و Rollback مدیریت می‌شود. هدف، وعده «حفظ قطعی رتبه» نیست؛ هدف، انتقال قابل دفاع کاربر و سیگنال‌ها با کمترین ابهام است.

ریدایرکت ۳۰۱ چیست؟

301 Moved Permanently یک کد وضعیت HTTP است. سرور در پاسخ به درخواست URL قدیمی، Status برابر ۳۰۱ و معمولاً Header به نام Location را برمی‌گرداند. User agent می‌تواند درخواست بعدی را به مقصد بفرستد.

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-path
Cache-Control: public, max-age=86400

«دائمی» یعنی مالک منبع انتظار ندارد این نگاشت برگردد. این کلمه به معنی انتقال فوری و تضمینی Rank، Traffic یا عدد ثابتی از «اعتبار» نیست. Google در راهنمای Redirectها می‌گوید Redirect دائمی سیگنالی است که مقصد باید canonical شود؛ پردازش نهایی همچنان به Crawl، محتوای مقصد و سازگاری سیگنال‌های دیگر وابسته است.

Redirect یک قرارداد سه‌جزئی است

برای تشخیص درستی یک Redirect، فقط Status را نبینید. سه جزء باید با هم سازگار باشند:

Headerهای Cache، Vary و Cookie، رفتار CDN، Query string و Body نیز می‌توانند نتیجه را تغییر دهند. برای درک خانواده کامل پاسخ‌ها، راهنمای کدهای وضعیت HTTP و سئو را ببینید.

تفاوت ۳۰۱، ۳۰۲، ۳۰۳، ۳۰۷ و ۳۰۸

طبق RFC 9110، رفتار Method در Redirectها یکسان نیست. در عمل، بسیاری از User agentها پس از ۳۰۱ یا ۳۰۲، درخواست POST را به GET تبدیل می‌کنند. ۳۰۷ و ۳۰۸ برای حفظ Method و Body تعریف شده‌اند.

۳۰۱ در برابر ۳۰۲ از نگاه Search

این گزاره که «۳۰۲ هیچ اعتباری منتقل نمی‌کند» دقیق نیست. Google Redirect موقت را دنبال می‌کند، اما آن را سیگنال canonical شدن مقصد نمی‌داند؛ ممکن است مقصد با سیگنال‌های دیگر Index شود. Redirect دائمی ۳۰۱/۳۰۸ برای جایگزینی پایدار URL روشن‌تر است. انتخاب Status باید واقعیت انتقال را بیان کند، نه ترفند رتبه‌گیری.

۳۰۱ در برابر ۳۰۸

برای صفحه‌های معمولی GET، هر دو انتقال دائمی‌اند. وقتی Method و Body اهمیت دارد، ۳۰۸ معنای دقیق‌تری دارد؛ با این حال Client، Proxy، CDN و Provider باید آن را پشتیبانی و در محیط واقعی تست کنند. برای Callback پرداخت یا Webhook، تغییر Endpoint در تنظیمات Provider از تکیه بر Redirect امن‌تر و قابل پیش‌بینی‌تر است.

هیچ درصد تضمینی برای انتقال «اعتبار» وجود ندارد

اعداد ۹۰ تا ۹۹ درصد یا «انتقال کامل PageRank» معیار قابل تضمینی برای یک URL مشخص نیستند. نتیجه به معادل‌بودن مقصد، Crawl، Internal link، canonical، محتوای مقصد، Availability و سیگنال‌های بیرونی وابسته است. Domain Authority و Page Authority نیز Metric ابزارهای شخص ثالث‌اند، نه عددی که Google برای صفحه شما منتشر کند.

سه Outcome را جدا اندازه بگیرید:

• Delivery: درخواست قدیمی مستقیم و بدون خطا به مقصد می‌رسد؟
• Index transition: مقصد برای Queryهای مرتبط جای منبع را می‌گیرد؟
• Business continuity: Session، Lead، Purchase یا Task حفظ شده است؟

۳۰۱ شرط مهم انتقال است، اما به‌تنهایی ضمانت Outcome نیست.

چه زمانی از ۳۰۱ استفاده کنیم؟

صفحه حذف‌شده را همیشه Redirect نکنید

۴۰۴ بن‌بست فنی یا شکست SEO نیست؛ Status درست برای منبعی است که وجود ندارد. اگر جایگزین مشابهی نیست، ۴۰۴ یا ۴۱۰ با صفحه خطای مفید بهتر از Redirect به Homepage، دسته عمومی یا محصول نامرتبط است. Google در راهنمای رفع خطاهای Crawl همین تصمیم را پیشنهاد می‌کند: محتوای منتقل‌شده ۳۰۱، محتوای بدون جایگزین ۴۰۴ یا ۴۱۰.

Redirect انبوه URLهای نامرتبط به صفحه اصلی می‌تواند به تجربه بد و Soft ۴۰۴ منجر شود. یک ۴۰۴ سفارشی باید Search/Navigation/Support مفید داشته باشد، اما Status آن همچنان ۴۰۴ بماند.

اگر حذف نتیجه Audit محتواست، تصمیم را فقط بر Traffic نگذارید. تقاضا، Outcome، بک‌لینک، هم‌پوشانی و هزینه نگهداری را بررسی کنید؛ چارچوب Create/Improve/Merge/Redirect/Archive در راهنمای سیستم محتوای وبلاگ این انتخاب را ساختاری می‌کند.

ریدایرکت ۳۰۱ با canonical چه تفاوتی دارد؟

۳۰۱ کاربران و Crawler را به مقصد می‌فرستد و منبع را بازنشسته می‌کند. rel="canonical" ترجیح میان نسخه‌های تکراری یا بسیار مشابه را اعلام می‌کند، در حالی که هر دو URL ممکن است برای کاربر در دسترس بمانند. Google در راهنمای canonical Redirect و canonical را سیگنال‌های قوی و Sitemap را سیگنال ضعیف‌تر توصیف می‌کند.

مهاجرت URL با Inventory شروع می‌شود

URL map را از Sitemap فعلی به‌تنهایی نسازید؛ Sitemap ممکن است URLهای قدیمی، Orphan، PDF، پارامتر، کمپین و صفحات دارای بک‌لینک را نداشته باشد.

منابع Inventory

• Crawl کامل سایت و Export URL/Status/canonical/internal inlinks؛
• XML Sitemap، RSS، hreflang، Image/Video Sitemap؛
• Search Console Page و Query، Indexing و لینک‌ها؛
• Analytics، CRM و Backend برای Landing/Outcome؛
• Server/CDN log برای URLهای درخواست‌شده واقعی؛
• فهرست بک‌لینک، PDF، اپ، QR، ایمیل و Partner؛
• CMS/database و Routeهای تولیدشده با JavaScript/API؛
• دامنه‌ها، Subdomainها، HTTP/HTTPS و www/non-www.

برای Baseline فنی و محتوایی گسترده‌تر، چک‌لیست ممیزی کامل سئو را اجرا کنید.

URL mapping یک Decision table است

هر Source URL باید یک مالک، تصمیم و دلیل داشته باشد. نگاشت خودکار بر اساس Path تنها وقتی امن است که ساختار واقعاً یک‌به‌یک و نمونه‌های استثنا بررسی شده باشند.

Similarity به معنی Equivalence نیست

دو صفحه ممکن است کلمه مشترک داشته باشند اما Job متفاوتی حل کنند. «راهنمای انتخاب لپ‌تاپ» جایگزین صفحه یک مدل حذف‌شده نیست؛ «صفحه دسته لپ‌تاپ» نیز فقط وقتی مقصد قابل قبول است که کاربر هنوز بتواند تصمیم متناظر بگیرد. نمونه‌های High-traffic/Revenue را دستی و نمونه‌های Long-tail را طبقه‌بندی‌شده بررسی کنید.

پیش از Redirect، مقصد را آماده کنید

Redirect درست به مقصد ناقص، مشکل را جابه‌جا می‌کند. هر Target باید:

• پاسخ نهایی ۲۰۰ و محتوای اصلی قابل Render داشته باشد؛
• Intent و اطلاعات مهم منبع را واقعاً پوشش دهد؛
• noindex یا Block ناخواسته نداشته باشد؛
• canonical خودارجاع و Metadata درست داشته باشد؛
• لینک داخلی، Navigation و Sitemap جدید دریافت کند؛
• دارایی‌ها، hreflang، Schema، Open Graph و Feed به‌روز باشند؛
• Task و Outcome در Mobile/RTL و شبکه واقعی تست شده باشند.

برای کنترل Title، H1، Meta، canonical و لینک‌های Target، چک‌لیست On-page SEO را پیش از Cutover اجرا کنید.

پیاده‌سازی Redirect را در نزدیک‌ترین لایه قابل اعتماد انجام دهید

Edge/CDN یا Web server معمولاً سریع‌تر و مستقل از Application است؛ CMS برای تیم غیر فنی قابل مدیریت‌تر است؛ Application وقتی Business rule یا Auth context لازم است مناسب‌تر است. یک Source نباید در چند لایه Ruleهای متناقض داشته باشد.

نمونه امن‌تر در Apache

برای نگاشت ساده، mod_alias از Regex پیچیده خواناتر است. مستند رسمی Apache mod_alias رفتار Redirect و تفاوت Statusها را شرح می‌دهد.

# نگاشت دقیق و دائمی
Redirect permanent "/old-guide" "https://www.example.com/new-guide"

# منبع بدون جایگزین
Redirect gone "/retired-campaign"

در Ruleهای Domain-wide، Host مقصد را صریح و Allowlisted بنویسید. بازتاب مستقیم Host درخواست در Header مقصد می‌تواند به Host header injection یا Open redirect کمک کند. پیش از Deploy، Syntax test، Config review و Rollback آماده باشد.

نمونه امن‌تر در Nginx

برای Path دقیق، location = و return معمولاً از Rewrite عمومی ساده‌تر است. مرجع Nginx rewrite module ترتیب اجرای Rule و Statusهای پشتیبانی‌شده را توضیح می‌دهد.

location = /old-guide {
    return 301 https://www.example.com/new-guide;
}

location = /old-api-endpoint {
    return 308 https://api.example.com/v2/resource;
}

اگر ساختار Path واقعاً یکسان است، نگاشت Domain-wide می‌تواند $request_uri را حفظ کند؛ اما ابتدا باید Query string، Pathهای استثنا، Admin، callback و فایل‌ها را Audit کنید. هرگز «همه چیز را منتقل کن» را بدون نمونه‌گیری و Allowlist منتشر نکنید.

ریدایرکت در WordPress

در WordPress می‌توانید Redirect را در Web server/CDN، Plugin معتبر یا کد کنترل‌شده اجرا کنید. انتخاب باید بر حجم Rule، دسترسی تیم، Cache، Staging و امکان Export/Version control استوار باشد.

کنترل‌های WordPress

• پیش از تغییر Permalink، Export کامل URLها و Map را بسازید.
• Ruleها را در Staging با نسخه مشابه Server و Pluginها تست کنید.
• Redirect خودکار Plugin را با Map دستی مقایسه کنید؛ Slug مشابه همیشه مقصد درست نیست.
• Cache صفحه، Object cache و CDN را پس از Deploy کنترل‌شده Purge کنید.
• Ruleها را Export، Version و صاحب‌دار کنید؛ تغییر مستقیم بدون Log نپذیرید.
• برای مقصدهای خارجی در کد، از Allowlist و API امن پلتفرم استفاده کنید؛ مستند wp_safe_redirect را مبنا قرار دهید.

Query string، Fragment و URL فارسی را صریح مدیریت کنید

در مهاجرت Slug فارسی به انگلیسی/Finglish، Map را از URL واقعی Percent-encoded و نسخه Decode‌شده اعتبارسنجی کنید. تفاوت «ی/ک»، نیم‌فاصله و Normalization می‌تواند URLهای ظاهراً مشابه اما فنی متفاوت بسازد.

امنیت Redirect: مقصد ورودی کاربر را اعتماد نکنید

پارامترهایی مانند ?next=، ?return_url= یا ?redirect= اگر بدون اعتبارسنجی به Location بروند، Open redirect می‌سازند. مهاجم می‌تواند لینک دامنه معتبر شما را به صفحه فیشینگ، OAuth chain یا مقصد داخلی هدایت کند.

کنترل‌های ضروری

• تا حد ممکن مقصد را با ID داخلی به یک جدول Allowlist نگاشت کنید.
• URL را با Parser استاندارد تحلیل و Scheme/Host/Port/Path را جدا اعتبارسنجی کنید.
• Protocol-relative، Userinfo، Backslash، Encoding دوبل و Subdomain confusion را تست کنید.
• Host مقصد را با Equality/Allowlist بسنجید؛ Contains یا suffix خام کافی نیست.
• Schemeهای غیر HTTP(S) و Credential در URL را رد کنید.
• در OAuth/SSO، redirect URI باید ثبت‌شده و Exact باشد.
• Redirectهای غیرمنتظره Clientهای Server-side را Follow نکنید؛ SSRF chain را در نظر بگیرید.

راهنمای Open Redirect در OWASP نشان می‌دهد چرا Blocklist و String matching کافی نیستند. برای Threat model وسیع‌تر، راهنمای امنیت API و OWASP را ببینید.

ریدایرکت API، پرداخت و Webhook را مانند صفحه GET نبینید

۳۰۱/۳۰۲ ممکن است POST را به GET تبدیل کنند و بعضی Clientها Redirect را اصلاً Follow نکنند. Signature ممکن است به Path، Host یا Body وابسته باشد. در پرداخت و Webhook، Redirect می‌تواند Retry، Duplicate و وضعیت نامعلوم ایجاد کند.

هیچ Redirectی جای Idempotency، Backend verification و Reconciliation را نمی‌گیرد.

زنجیره و حلقه Redirect چگونه شکل می‌گیرد؟

Chain وقتی است که A→B→C؛ Loop وقتی مقصد دوباره به منبع یا عضو قبلی برمی‌گردد. حتی دو Hop می‌تواند Latency، تعداد Request، Failure point و پیچیدگی Debug را بیشتر کند. هدف عملی برای URLهای تحت کنترل، یک Redirect مستقیم به مقصد ۲۰۰ است.

علت‌های رایج

• Rule قدیمی و جدید در CDN، Server و Plugin همزمان؛
• HTTP→HTTPS سپس non-www→www سپس slash normalization؛
• canonical Host متفاوت با Redirect Host؛
• Locale یا Geo redirect رفت‌وبرگشتی؛
• Cache قدیمی Browser/CDN پس از اصلاح Rule؛
• Regex greedy که مقصد را دوباره Match می‌کند.

Normalizationهای scheme/host/slash را در یک Hop ترکیب کنید و ترتیب Ruleها را از Exact و Exception به Broad ببرید.

تست Redirect باید ماشینی و نمونه‌محور باشد

کلیک مرورگر فقط می‌گوید «بالاخره صفحه‌ای باز شد». QA باید هر Hop، Header و محتوای مقصد را ببیند.

نمونه بررسی خط فرمان

# فقط پاسخ مستقیم و Location
curl -I --max-redirs 0 https://old.example.com/old-path

# دیدن تمام Hopها
curl -I -L --max-redirs 10 https://old.example.com/old-path

برای مجموعه بزرگ، CSV Map را ورودی Test runner کنید و Actual status/location/final/marker را با Expected مقایسه کنید. Failها باید Release را متوقف کنند، نه اینکه بعداً در Search Console پیدا شوند.

مهاجرت دامنه: Redirect فقط یک مرحله است

Google در راهنمای Site move بر آماده‌سازی مقصد، URL map، Redirect، تست، Sitemap و Monitoring تأکید دارد. نوسان Search در تغییر بزرگ ممکن است رخ دهد؛ زمان ثابت برای تکمیل Crawl وجود ندارد.

Preflight دامنه

• مالکیت، تاریخچه، Manual action و وضعیت Index دامنه مقصد بررسی شود.
• DNS، TLS، Email، CDN، WAF، Robots و Capacity مقصد آماده باشند.
• دامنه قدیمی، DNS و Certificate آن حفظ شوند؛ HTTPS قدیمی بدون TLS معتبر به Redirect نمی‌رسد.
• هر Subdomain و Host variant در Inventory و Certificate پوشش داده شود.
• URLهای جدید self-canonical، لینک داخلی و Sitemap جدید داشته باشند.
• همزمانی Migration با Redesign/Platform change تا حد ممکن کاهش یابد تا علت خطا جدا بماند.

Search Console Change of Address

برای جابه‌جایی Domain/Subdomain، پس از اجرای Redirect و Verify مالکیت‌ها از ابزار Change of Address استفاده کنید. این ابزار برای HTTP→HTTPS یا جابه‌جایی چند Path داخل همان سایت نیست. جزئیات و محدودیت‌ها در مستند Change of Address آمده است.

Update داخلی را پشت Redirect پنهان نکنید

پس از Cutover، تمام لینک‌های تحت کنترل را مستقیم به مقصد تغییر دهید:

• Navigation، Breadcrumb، Footer، Body link و CTA؛
• canonical، hreflang، Schema، Open Graph و Feed؛
• XML Sitemap و robots directive/reference؛
• Asset URL، manifest، Service worker و API config؛
• ایمیل Template، QR، PDF، اپ و Partner integration؛
• لینک‌های خارجی مهم با درخواست Update محترمانه.

Redirect برای سازگاری با لینک قدیمی است، نه جایگزین نگهداری لینک‌های داخلی. لینک مستقیم Crawl و UX را ساده‌تر می‌کند.

Cache و ۳۰۱: اصلاح Rule ممکن است فوراً دیده نشود

۳۰۱ می‌تواند در Browser، CDN یا Proxy Cache شود. TTL بلند پیش از اطمینان از Map، Rollback را دشوار می‌کند. ابتدا با TTL محافظه‌کارانه و نمونه کنترل‌شده منتشر کنید؛ پس از تثبیت، Policy را افزایش دهید.

• Cache key باید Host، Path و Query policy را درست پوشش دهد.
• Purge را برای Edge و Page cache برنامه‌ریزی و نتیجه را از چند POP بررسی کنید.
• از Browser تازه، Private mode و Client بدون Cache تست بگیرید.
• Location قدیمی در ۳۰۱ cached را با Versioned test و Header مشاهده کنید.

برای تفاوت Browser/CDN/Object cache و Headerها، راهنمای معماری Cache سایت را ببینید.

مانیتورینگ پس از Cutover

Migration با Deploy تمام نمی‌شود. Dashboard باید Source و Target را همزمان نشان دهد.

برای Metric، Log، Trace، SLO و Alert، راهنمای Observability سایت را به Runbook مهاجرت وصل کنید. اگر Redirect باعث افزایش Latency یا Failure شده، اثر آن را با RUM و Business outcome بررسی کنید؛ راهنمای سرعت سایت و سنجش اثر این مرزبندی را پوشش می‌دهد.

Runbook عیب‌یابی افت پس از Migration

1. دامنه را محدود کنید: همه سایت، یک Template، Device، Country/Network یا Query cluster؟
2. Delivery را بررسی کنید: DNS/TLS/WAF/CDN/redirect/final status و ظرفیت.
3. Map را Sample کنید: URLهای High-value و Long-tail به مقصد درست می‌رسند؟
4. Target را Audit کنید: ۲۰۰، Render، noindex، canonical، robots، hreflang و content parity.
5. سیگنال‌ها را تطبیق دهید: لینک داخلی، Sitemap و بک‌لینک به کجا اشاره می‌کنند؟
6. Search را Segment کنید: Brand/non-brand، Query/Page، Mobile/Desktop و بازه هم‌دوره.
7. Outcome را جدا کنید: افت Search است یا Landing/Checkout/Tracking نیز شکسته؟
8. Fix و Re-test: Rule کوچک، Test خودکار، Release و Monitor؛ از تغییرات همزمان زیاد پرهیز کنید.

A/B test و Geo/Language redirect

A/B test

برای انتقال موقت کاربر از Original به Variation، Google استفاده از ۳۰۲ به‌جای ۳۰۱ و canonical به Original را توصیه می‌کند؛ نمایش نسخه ویژه فقط به Googlebot Cloaking است. راهنمای A/B testing برای Search همچنین می‌گوید آزمایش را پس از رسیدن به نتیجه لازم متوقف و دارایی‌های موقت را جمع کنید.

زبان و موقعیت

Redirect اجباری بر اساس IP یا زبان Browser می‌تواند کاربر، Crawler، VPN و مسافر را به مقصد اشتباه ببرد. یک Default قابل Crawl، hreflang صحیح، Selector دستی و حفظ انتخاب کاربر بسازید. اگر انتقال موقت و وابسته به Context است، Status دائمی ندهید. صفحه اصلی هر Locale باید مستقل قابل دسترسی باشد.

ملاحظات کسب‌وکار ایرانی

• دامنه قدیمی .ir و دامنه بین‌المللی را تا زمانی که لینک/کاربر دارد تمدید و مانیتور کنید.
• Certificate و DNS هر Host قدیمی را حفظ کنید؛ Redirect HTTPS بدون TLS معتبر اجرا نمی‌شود.
• URLهای فارسی، نیم‌فاصله، «ی/ک»، Encoding و Slug Finglish را با نمونه واقعی تست کنید.
• از چند شبکه/ISP و Region در چارچوب مجاز Probe بگیرید؛ یک اتصال نتیجه کل بازار نیست.
• Callback درگاه، Webhook ارسال و اپ موبایل را با Provider هماهنگ کنید؛ Rule عمومی دامنه آن‌ها را ناخواسته نگیرد.
• پارامترهای کدملی، تلفن، ایمیل، Token پرداخت و Session نباید در Location یا Log مهاجرت نشت کنند.
• پیام خطا، Maintenance و Support فارسی با تاریخ/Timezone روشن و مسیر جایگزین مجاز فراهم کنید.
• تغییر دامنه/زیرساخت را بدون ارائه روش دورزدن محدودیت و با بررسی حقوقی/قراردادی اجرا کنید.

برنامه ۳۰ روزه مهاجرت URL

۳۰ روز نسخه ثابت همه پروژه‌ها نیست. دامنه بزرگ، چند Locale، Marketplace یا APIهای شخص ثالث به Discovery و Rollout طولانی‌تر نیاز دارد.

چک‌لیست ریدایرکت ۳۰۱

پیش از اجرا

• Inventory از Crawl، Log، Search، Analytics، CMS و بک‌لینک ساخته شده است.
• هر Source تصمیم، Target، دلیل معادل‌بودن، Method و Query policy دارد.
• Target نهایی ۲۰۰، self-canonical، قابل Index و از نظر Task کامل است.
• Ruleهای CDN/Server/App/CMS تداخل و ترتیب مشخص دارند.
• Security review، Capacity، Cache policy، Monitoring و Rollback آماده‌اند.

هنگام اجرا

• Source مستقیم Status و Location مورد انتظار می‌دهد.
• Target در یک Hop به ۲۰۰ و Marker درست می‌رسد.
• GET/HEAD/POST، Query، Encoding، Host و Slash تست شده‌اند.
• لینک داخلی، canonical، hreflang، Sitemap و Assetها به مقصد مستقیم تغییر کرده‌اند.
• Cache/CDN از چند مسیر و Client کنترل شده است.

پس از اجرا

• Log 3xx/4xx/5xx، Loop، Latency و Capacity مانیتور می‌شوند.
• Search Console Indexing/Query/Page و Sitemapهای قدیم/جدید بررسی می‌شوند.
• Outcomeهای CRM/Backend و Tracking continuity تأیید شده‌اند.
• بک‌لینک‌ها، PDF، QR، اپ و Partnerهای مهم Update می‌شوند.
• Redirect registry، Owner، Review date و دلیل نگهداری ثبت است.

پرسش‌های متداول

ریدایرکت ۳۰۱ و ۳۰۲ چه تفاوتی دارند؟

۳۰۱ انتقال دائمی و سیگنال جایگزینی URL است؛ ۳۰۲ انتقال موقت است و منبع معمولاً مالک Search می‌ماند. هر دو ممکن است برای POST به GET تبدیل شوند؛ برای حفظ Method از ۳۰۷ موقت یا ۳۰۸ دائم استفاده و Client را تست کنید.

ریدایرکت ۳۰۱ چند درصد اعتبار صفحه را منتقل می‌کند؟

درصد تضمینی و قابل اندازه‌گیری عمومی وجود ندارد. ۳۰۱ یک سیگنال قوی انتقال است، اما معادل‌بودن مقصد، Crawl، محتوا، لینک داخلی، canonical و Availability بر نتیجه اثر دارند. Delivery، Index transition و Business outcome را جدا بسنجید.

صفحه حذف‌شده را به Homepage ریدایرکت کنیم؟

فقط اگر Homepage واقعاً جایگزین همان Job باشد که معمولاً نیست. اگر مقصد معادل ندارید، ۴۰۴ یا ۴۱۰ با صفحه خطای مفید بدهید. Redirect انبوه URLهای نامرتبط به Homepage می‌تواند کاربر را سردرگم و به Soft ۴۰۴ منجر شود.

ریدایرکت ۳۰۱ را چه مدت نگه داریم؟

Google برای Site move نگهداری تا حد ممکن و عموماً دست‌کم یک سال را توصیه می‌کند. از دید کاربر، تا وقتی لینک خارجی، Bookmark، QR، اپ یا ترافیک به منبع می‌رسد بهتر است Redirect بماند. حذف را بر مبنای Log، هزینه نگهداری و ریسک تصمیم بگیرید، نه ادعای «انتقال کامل اعتبار».

آیا ریدایرکت ۳۰۱ سرعت سایت را کم می‌کند؟

هر Hop یک Round trip و Failure point اضافه می‌کند؛ اثر به شبکه، TLS، Server و Cache وابسته است. Chain و Redirect داخلی تکراری هزینه بیشتری دارند. URLهای تحت کنترل را مستقیم به مقصد نهایی لینک دهید و یک Hop، Latency و RUM را اندازه بگیرید.

جمع‌بندی

ریدایرکت ۳۰۱ زمانی درست است که انتقال دائمی و مقصد معادل باشد. Status باید با Method، مدت و Outcome هماهنگ شود؛ ۳۰۲/۳۰۷ برای موقت، ۳۰۳ برای See Other، ۳۰۸ برای انتقال دائمی با حفظ Method و ۴۰۴/۴۱۰ برای حذف بدون جایگزین، هرکدام جای خود را دارند.

در مقیاس سایت، کیفیت مهاجرت را URL map، Target readiness، Rule امن، تست ماشینی، لینک‌های مستقیم و Monitoring تعیین می‌کنند. اگر Inventory و دلیل نگاشت ندارید، هنوز آماده نوشتن Redirect عمومی نیستید. مهاجرت خوب نه رتبه را وعده می‌دهد و نه خطا را پنهان می‌کند؛ مسیر کاربر و سیگنال‌ها را با کمترین ابهام به مقصدی واقعی، سالم و قابل نگهداری می‌رساند.