ریدایرکت 301 و 302 چه تفاوتی برای سئو دارند؟

کدهای 301 و 308 تغییر دائمی را نشان می دهند. کدهای 302 و 307 برای هدایت موقت به کار می روند. تفاوت 307 و 308 با دو کد دیگر در حفظ روش درخواست نیز اهمیت دارد. در صفحه عمومی که با GET دریافت می شود، این تفاوت کمتر دیده می شود. برای فرم و API باید رفتار درخواست های POST با دقت آزمایش شود تا داده ناخواسته دوباره ارسال نشود.

برای تغییر دائمی اسلاگ مقاله، مقصد باید نسخه جایگزین همان محتوا باشد. اگر مقاله حذف شده و هیچ جایگزین مرتبطی ندارد، فرستادن آن به صفحه نخست اغلب پاسخ مناسبی نیست. کاربر هنوز دنبال همان موضوع است و مقصد عمومی نیاز او را برطرف نمی کند. در چنین حالتی پاسخ واقعی 404 یا 410 می تواند از انتقال گسترده به یک مقصد نامرتبط بهتر باشد.

برای ادامه بررسی: خدمات تخصصی ریدایرکت 301 و 302

نقشه انتقال را از چند منبع بسازید. خروجی خزش، نقشه سایت، صفحه های دارای کلیک و آدرس های دارای پیوند خارجی را کنار هم قرار دهید. فقط فهرست نشانی های فعلی CMS کافی نیست، چون ممکن است آدرس های قدیمی هنوز ورودی داشته باشند. برای هر مبدا، مقصد، دلیل انتخاب و وضعیت تایید ثبت شود. آدرس های بدون مقصد باید پیش از راه اندازی بررسی شوند.

برای تبدیل بحث به تصمیم عملی، این مثال فرضی را در نظر بگیرید: مقاله ای از /old-guide/ به /new-guide/ رفته و قانون فعلی ابتدا آن را به نسخه بدون اسلش و سپس به نسخه HTTPS می فرستد. این وضعیت به معنی وجود یک علت قطعی نیست. باید بین چیزی که در خروجی سایت مشاهده شده و برداشتی که از علت آن داریم فرق گذاشت. شرح مسئله را با نشانی صفحه، تاریخ مشاهده، دستگاه آزمایش و رفتار مورد انتظار ثبت کنید. این چهار مورد باعث می شوند نفر بعدی بتواند همان وضعیت را دوباره بررسی کند و گزارش به برداشت شخصی وابسته نماند.

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

برای ادامه بررسی: ممیزی سئو و اولویت بندی اصلاحات

زنجیره زمانی ساخته می شود که نشانی اول به دوم و دوم به سوم برود. هرجا امکان دارد، مبدا را مستقیم به مقصد نهایی وصل کنید. حلقه تغییر مسیر که دوباره به مبدا برمی گردد، دسترسی را قطع می کند. قوانین مربوط به HTTPS، www، اسلش پایانی و اسلاگ را با هم آزمایش کنید، چون ترکیب چند قانون درست می تواند یک مسیر اشتباه یا پرش اضافه ایجاد کند.

ریدایرکت جای اصلاح لینک داخلی را نمی گیرد. منو، لینک داخل متن، نقشه سایت و کنونیکال باید به مقصد نهایی اشاره کنند. این هماهنگی باعث می شود کاربر و خزنده مسیر کوتاه تری داشته باشند و سیگنال های متناقض کمتر شوند. تغییر یکباره همه URLها فقط برای کوتاه شدن ظاهر آدرس، بدون منفعت روشن، هزینه انتقال و ریسک خطا را بالا می برد.

برای ادامه بررسی: تحلیل عملکرد صفحات در سرچ کنسول

در آزمایش ریدایرکت از درخواست GET هم استفاده کنید، چون بعضی سرورها برای HEAD رفتار متفاوت دارند. پارامتر لازم مثل شناسه کمپین یا انتخاب محصول نباید بی دلیل حذف شود. در عین حال، انتقال بی قاعده تمام پارامترها ممکن است نشانی های بی مصرف بسازد. برای دامنه قدیمی، تمدید دامنه و اعتبار گواهی HTTPS هم بخشی از حفظ مسیر انتقال هستند.

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

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

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

برای ادامه بررسی: راهنماهای تکمیلی در این موضوع

برای سنجش، «تعداد پرش تا مقصد» را از «کلیک منتقل شده به مقصد» جدا ثبت کنید. اولی و دومی لزوما هم زمان تغییر نمی کنند و از روی یکی نباید درباره دیگری حکم داد. بازه مقایسه باید دوره مشابه و گروه صفحه مشابه داشته باشد. روزهای ناقص، تغییر فصل، کمپین و تغییر موجودی را در یادداشت گزارش بیاورید. هرجا داده کم است، نتیجه را نشانه اولیه بنامید و از تبدیل آن به ادعای قطعی درباره رشد پرهیز کنید.