آموزش گام‌به‌گام کاهش ریدایرکت‌ها

ریدایرکت، خودش خطا نیست؛ ریدایرکت، ابزار انتقال ترافیک است و انتقالِ درست به تغییر آدرس‌ها معنا می‌دهد. مشکل از جایی شروع می‌شود که انتقال‌ها روی هم انباشته شوند: آدرسِ قدیمی به میانه اشاره می‌کند و میانه به مقصد؛ کاربر دو پرش تحمل می‌کند و هر پرش، تأخیر همان فایل HTML اضافه می‌کند. در هاب سرعت و کارایی وردپرس بحث سرعت را از قالب و افزونه شروع کردیم؛ زنجیرهٔ ریدایرکت همان لایهٔ پنهان است که نه در صفحهٔ افزونه‌ها دیده می‌شود و نه در ظاهر سایت.

هزینهٔ این لایه دو سر دارد: سر کاربر، تأخیر در اولین بایت و بلاتکلیفی در مرورگر؛ و سر خزنده، بودجهٔ خزشی که در پرش‌های اضافه می‌سوزد و در سایت‌های بزرگ، صفحات مهم را دیرتر می‌بیند. به تجربهٔ ما بعد از هر مهاجرت یا بازطراحی، انباشتِ تازه رخ می‌دهد؛ برای همین کاهش ریدایرکت‌ها را یک پروژهٔ یک‌باره نمی‌دانیم و روتین فصلی برایش تعریف می‌کنیم.

کاهش ریدایرکت‌ها از کجا شروع می‌شود؟

شروع کار، تغییر ذهنیت است: به‌جای «چند ریدایرکت داریم؟» بپرسید «طولانی‌ترین مسیر چند پرش است؟». ده ریدایرکتِ تک‌پله بی‌خطر است؛ دو زنجیرهٔ چهارپله مسئله‌ساز. معیار عملی ما این است: هر آدرسِ عمومی سایت — خانه، دسته، صفحات اصلی محصول و خدمات — باید در حداکثر یک پرش به مقصد نهایی برسد و هیچ زنجیره‌ای نباید از دو پرش عبور کند.

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

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

گام اول؛ ممیزی زنجیره‌ها با سه گزارش

سه منبع ممیزی را کنار هم بگذارید، چون هر کدام لایهٔ متفاوتی را می‌بیند. منبع اول، گزارش «صفحات» سرچ‌کنسول است که وضعیت «صفحه با ریدایرکت» و «خطای ریدایرکت» را برای آدرس‌هایی که گوگل دیده فهرست می‌کند؛ نحوهٔ خواندن این گزارش را در بررسی ایندکس صفحه در سرچ‌کنسول باز کرده‌ایم. منبع دوم، ابزارهای تحلیل سرعت مثل GTmetrix است که در گزارش صفحات، پرش‌های مسیر را نشان می‌دهد و برای زنجیره‌های صفحهٔ خانه و صفحات پربازدید کارآمد است. منبع سوم، خزندهٔ سایت است که کل نقشهٔ پیوندهای داخلی را می‌پیماید و زنجیره‌هایی را می‌یابد که از گزارش‌های بالا جا مانده‌اند.

سه منبع را در یک فهرست واحد بریزید و برای هر ردیف سه ستون بنویسید: مبدأ، میانه‌ها، مقصد نهایی. اولویت‌بندی هم با همان قاعدهٔ معیار بخش قبل انجام می‌شود: صفحه‌های پربازدید و مسیرهای وارده از لینک‌سازی بیرونی، اول؛ آدرس‌های فرعی و کم‌بازدید، بعد. به تجربهٔ ما هشتاد درصد تأثیر، از بیست درصد بالای همین فهرست می‌آید و ترتیبِ درست، پروژه را از یک هفته قفل‌شدن تیم نجات می‌دهد.

گام دوم؛ نگاشت آدرس‌ها و انتخاب نوع ریدایرکت

نگاشت یعنی تصمیم مکتوب: هر آدرس قدیمی به کدام مقصد نهایی می‌رود و با چه نوعی؟ نوع اول، ریدایرکت دائمی ۳۰۱ است برای انتقال واقعی — تغییر آدرس محتوا، حذف صفحه، مهاجرت دامنه — و سیگنال جابه‌جایی را به موتور جستجو می‌دهد. نوع دوم، موقت ۳۰۲ و واریان‌هایش است برای وضعیت‌هایی که برمی‌گردند: صفحهٔ محصول ناموجود که فصل بعد برمی‌گردد یا کانپین موقت. قاطی‌کردن این دو، رایج‌ترین خطای نگاشت است؛ ۳۰۲ ماندگار، سیگنال انتقال را ضعیف می‌کند و ۳۰۱ِ موقت، برگشت را سخت می‌سازد.

مقصد را هم با انرژی انتخاب کنید، نه با راحتی: بهترین مقصد، نزدیک‌ترین صفحهٔ هم‌قصد است؛ اگر صفحهٔ اصلی وجود ندارد، دستهٔ پدر، و اگر آن هم نبود، صفحه‌ای که همان نیاز کاربر را جواب می‌دهد. هدایت همهٔ آدرس‌های حذف‌شده به صفحهٔ خانه، راه‌آسانِ نادرست است؛ کاربر از پرش می‌گذرد و بعد با صفحه‌ای بی‌ربط روبه‌رو می‌شود که آن‌جا خداحافظی می‌کند.

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

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

گام سوم؛ شکستن حلقه‌ها و زنجیره‌های بلند

حالا زنجیره‌ها را می‌شکنید. قاعدهٔ فنی ساده است: مبدأ هر زنجیره را مستقیم به مقصد نهایی ببندید و آدرس‌های میانی را از مسیر حذف کنید. در وردپرس این کار معمولاً در افزونهٔ مدیریت ریدایرکت یا تنظیمات سرور انجام می‌شود؛ مهم آن است که قاعده در فایل نگاشت باقی بماند، چون افزونه‌ها عوض می‌شوند و فایل نگاشت می‌ماند. حین کار، ردیف‌های «میانه» را حذف نکنید — فقط دیگر در مسیر نیستند؛ ممکن است بیرون از سایت، به آن آدرس‌ها لینک شده باشد.

حلقه‌ها را جدا و فوری ببندید؛ معمولاً از قاعده‌های متناقض می‌آیند: یک قاعده https را به www می‌برد و قاعدهٔ دیگر www را به بدون www، و نتیجه یک چرخهٔ بی‌پایان است. باقی‌مانده‌های مهاجرت‌های قدیمی هم منبع رایج حلقه‌اند: قاعده‌ای که در دوره‌ای درست بوده و حالا با ساختار تازه می‌جنگد. در این گام، ترتیب اجرا اهمیت دارد: اول حلقه و خراب، بعد زنجیره‌های صفحات پربازدید، بعد بقیه.

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

گام چهارم؛ یکدست‌سازی http و https و www

یکدست‌سازی، پاک‌سازیِ ریشه است: نسخه‌های چهارگانهٔ هر آدرس — http و https، با www و بدون www — باید با یک پرش به نسخهٔ کانونی برسند. تصمیم کانونی مال شماست؛ مهم آن است که فقط یک نسخه انتخاب شود و همهٔ قاعده‌ها به آن اشاره کنند. اگر قاعده‌ها پراکنده‌اند — یکی در تنظیمات وردپرس، یکی در فایل پیکربندی سرور، یکی در افزونهٔ امنیتی — همین پراکندگی، منبع زنجیره‌های دوپله و گاهی حلقه است.

ترتیب پیشنهادی ما در پیکربندی سالم این است: اول پروتکل به https برسد، در همان پاسخ نسخهٔ www هم کانونی شود، و پاسخ نهایی مستقیم از مبدأ تولید شود نه از زنجیرهٔ دوپله. آدرس کانونی را در نقشهٔ سایت هم یکدست کنید؛ اگر نقشهٔ سایت نسخهٔ دیگری را اعلام کند، خزنده دو سیگنال متناقض می‌گیرد و نتیجه، کندی ایندکس است. لینک‌های داخلی سایت را هم به نسخهٔ کانونی ببندید؛ لینک داخلی به نسخهٔ غیرکانونی، هر بازدید را تبدیل به یک پرش اضافه می‌کند که رفع آن یک‌خط کد است.

این گام را یک‌بار درست ببندید و سال‌ها آرام بمانید؛ برخلاف نگاشت محتوا که با هر انتشار به‌روز می‌شود، یکدست‌سازی زیرساخت است و دست‌نخوردن به آن، خودش ارزش است.

گام پنجم؛ پیشگیری از بازگشت مشکل

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

نقشهٔ سایت را هم از دل زنجیره‌ها تمیز نگه دارید: فقط آدرس‌های کانونی با پاسخ ۲۰۰ در نقشه باشند. و بعد از هر بازطراحی، همان ممیزی سه‌منبعی بخش دوم را دوباره اجرا کنید؛ مهاجرت، انباشتِ تازه می‌آورد و شروعِ سریع، ارزان‌ترین زمان اصلاح است. به تجربهٔ ما پروژه‌هایی که این روتین را دارند، سرعت واقعی‌شان بعد از هر بازطراحی بهتر می‌شود و بقیه، هر بار پله‌ای عقب می‌روند.

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

جمع‌بندی؛ روتین فصلی پاک‌سازی

جمع‌بندی: کاهش ریدایرکت‌ها پنج گام دارد — ممیزی با سه منبع، نگاشت مکتوب با تفکیک ۳۰۱ و ۳۰۲، شکستن حلقه‌ها و زنجیره‌ها، یکدست‌سازی نسخه‌های http و https و www، و پیشگیری با قواعد تیمی — و معیار پیروزی روشن است: هر آدرس عمومی در یک پرش به مقصد نهایی. این پروژه را فصلی تکرار کنید، نه سالی یک‌بار؛ انباشت، طبیعتِ هر سایت زنده است.

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

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

رصد ما، رشد شما.