301 در برابر 302: ریدایرکت‌ها، سئو و اشتباهاتی که می‌چسبند

در یک ریدایرکت واقعاً چه اتفاقی می‌افتد

وقتی مرورگر یک URL را درخواست می‌کند و سرور با یک کد وضعیت 3xx و هدر Location پاسخ می‌دهد، مرورگر بی‌صدا درخواست دومی به آن آدرس جدید می‌فرستد. بازدیدکننده فقط مقصد را می‌بیند؛ هزینه — یک رفت‌وبرگشت اضافی — و معنا، روی کد وضعیت سوارند.

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

موتورهای جستجو با هر کدام چه می‌کنند

برای یک 301، موتورهای جستجو جابه‌جایی را یک واقعیت قطعی تلقی می‌کنند: سیگنال‌های انباشته‌ی URL قدیمی — لینک‌ها، سابقه، رتبه — به URL جدید منتقل می‌شوند و طی هفته‌های بعد، URL جدید در نتایج جای قدیمی را می‌گیرد. به همین دلیل مهاجرت سایت، سوئیچ به HTTPS و تغییر نام slugها با 301 انجام می‌شوند: اعتبار به دنبال محتوا می‌رود.

برای یک 302، موتورها همان کار تحت‌اللفظی را می‌کنند: URL قدیمی را در ایندکس نگه می‌دارند، چون به آن‌ها گفته‌اید محتوا برمی‌گردد. یک 302 که برای جابه‌جایی دائمی باقی مانده، یکی از اشتباهات کلاسیک و بی‌سروصدای سئو است — برای بازدیدکنندگان همه‌چیز کار می‌کند، اما URL جدید هیچ سابقه‌ای نمی‌سازد و URL قدیمی آرام‌آرام کهنه می‌شود. اگر چنین موردی پیدا کردید، صرفِ تغییر آن به 301 انتقال را آغاز می‌کند؛ موتورها این اصلاح را به‌خوبی هضم می‌کنند.

اشتباه معکوس هم وجود دارد: یک 301 برای چیزی که واقعاً موقتی است (صفحه‌ی کمپین، تست A/B) به موتورها می‌گوید صفحه‌ی اصلی را از ایندکس خارج کنند — یعنی دقیقاً همان چیزی که نمی‌خواستید.

بخشی که مردم به روش سخت یاد می‌گیرند: 301 می‌چسبد

مرورگرها مجازند یک 301 را بدون تاریخ انقضا کش کنند — و چند مرورگر دقیقاً همین کار را می‌کنند. اولین باری که مرورگرِ یک بازدیدکننده ریدایرکت را ببیند، ممکن است آن را برای مدت نامحدود به خاطر بسپارد و دیگر هرگز از URL قدیمی نپرسد. سرور را فردا اصلاح کنید و آن بازدیدکننده همچنان به صفحه‌ی اشتباه می‌رسد، چون ریدایرکت حالا در مرورگرِ او زندگی می‌کند، خارج از دسترس شما. برای مرورگر دیگران دکمه‌ی purge وجود ندارد.

دو نتیجه‌ی عملی. اول، جابه‌جایی را با 302 آزمایش کنید و فقط وقتی مطمئن شدید آن را به 301 ارتقا دهید — کد موقت همان کدِ قابل‌بازگشت است. دوم، روی ریدایرکت‌ها یک Cache-Control صریح بگذارید، چون یک عمرِ محدود، «برای همیشه گیرکرده» را به «حداکثر یک روز گیرکرده» تبدیل می‌کند. ما در همین سایت این قاعده را رعایت می‌کنیم: ریدایرکت‌های canonical ما Cache-Control: public, max-age=86400 دارند، پس حتی ریدایرکتی که بعداً تغییرش دهیم، برای هر بازدیدکننده و هر کشِ میانی ظرف یک روز خودش را اصلاح می‌کند.

یک ریدایرکت با عمر محدود و قابل کش

$ curl -sI https://cdn.com.tr/en/features/almacenamiento-objetos-s3 | grep -iE 'http|location|cache-control'
HTTP/2 301
location: https://cdn.com.tr/en/features/object-storage
cache-control: max-age=86400, public

زنجیره‌های ریدایرکت: مالیاتی که بر هر کلیک می‌پردازید

ریدایرکت‌ها روی هم انباشته می‌شوند. قانون http به https یک پرش اضافه می‌کند، قانون www یکی دیگر، و slug تغییرنام‌یافته سومی — و حالا هر بازدیدکننده پیش از رسیدن هر محتوایی سه رفت‌وبرگشت می‌پردازد، در حالی که موتورهای جستجو در هر گام میانی کمی سیگنال هدر می‌دهند و زنجیره‌های خیلی بلند را اصلاً دنبال نمی‌کنند.

راه‌حل، پرهیز از ریدایرکت نیست؛ این است که هر URL قدیمی مستقیماً به مقصد نهایی اشاره کند. وقتی صفحه‌ای را تغییر نام می‌دهید که از قبل ریدایرکتی به آن اشاره می‌کرد، قانونِ قدیمی را هم به‌روز کنید تا هر دو نسل URL در یک پرش به آدرس جدید برسند. یک بازرسی گاه‌به‌گاه، یک دستور به‌ازای هر URL است، و شکلی که می‌خواهید ببینید، یک 301 و بلافاصله یک 200 است.

کل زنجیره را دنبال کنید و پرش‌ها را بشمارید

# -L follows redirects; print each hop's code and target
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com/old-page

# see every hop explicitly (one line per response)
curl -sIL http://example.com/old-page | grep -iE '^HTTP|^location'

# healthy: HTTP/1.1 301 -> HTTP/2 200. unhealthy: 301 -> 301 -> 302 -> 200

ریدایرکت روی CDN: کجا باید زندگی کنند و کش‌کردن‌شان

ریدایرکتی که اپلیکیشن شما سرو می‌کند کار می‌کند، اما برای تولید یک هدرِ همیشه‌ثابت، یک سفر کامل تا origin هزینه دارد. انتقال ریدایرکت‌های شناخته‌شده به لبه — یا اجازه‌دادن به لبه برای کش‌کردن ریدایرکت‌هایی که اپ شما تولید می‌کند — به آن‌ها نزدیک بازدیدکننده پاسخ می‌دهد.

هر دو نیمه اینجا در دسترس‌اند. قوانین تحویل می‌توانند مستقیماً در لبه ریدایرکت کنند (ریدایرکت سایت موبایل یک تنظیم تک‌فیلدی در پنل است)، و از یک بهبود اخیر به بعد، لبه پاسخ‌های 301 و 302 برآمده از origin شما را هم با عمر محدود کش می‌کند، تا خزش‌های مکرر یک URL جابه‌جاشده اصلاً به اپلیکیشن شما نرسند. توصیه‌ی عملی: به ریدایرکت‌هایتان مثل هر پاسخ دیگری یک Cache-Control صریح بدهید — برای 302 کوتاه، برای 301 تا یک روز — آن‌قدر بلند که ترافیک را جذب کند، آن‌قدر کوتاه که از اشتباهات خودتان جان سالم به در ببرد.

انتخاب در پنج ثانیه

صفحه‌ای را تغییر نام داده‌اید، دامنه عوض کرده‌اید، به HTTPS رفته‌اید، صفحات تکراری را ادغام کرده‌اید: 301، و زنجیره‌های قدیمی را طوری به‌روز کنید که مستقیم به URL نهایی اشاره کنند. صفحه‌ی کمپین، مسیر موقت تعمیرات، تست A/B، تفکیک جغرافیایی، هر چیزی که قصد دارید برگردانید: 302. هنوز مطمئن نیستید: اول 302 — همان کدِ قابل‌بازگشت است — و وقتی جابه‌جایی قطعی شد به 301 ارتقا دهید.

و فراقاعده‌ای که بقیه‌ی موارد را می‌گیرد: ریدایرکت یک قول درباره‌ی آینده‌ی یک URL است. کدی را انتخاب کنید که با قولی که واقعاً می‌توانید نگه دارید، بخواند.