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

در محیط آزمون، مسیرهای اصلی و الگوهای حساس بررسی شوند. صفحه اصلی، خدمت، دسته، محصول، مقاله، صفحهبندی، تصویر و فرم تماس نمونههای مناسبی هستند. تنها باز شدن صفحه کافی نیست. وضعیت HTTP، محتوای اصلی، تیتر، متادیتا و مقصد لینکها هم دیده شوند. یک قالب سالم نمیتواند نبود آزمون برای قالبهای دیگر را جبران کند.
دستورهای محیط توسعه باید فهرست جدا داشته باشند. محدودیت خزش، noindex، رمز ورود یا URL موقت ممکن است برای مرحله ساخت مناسب باشند، اما نباید ناخواسته وارد انتشار عمومی شوند. مسئول حذف یا تغییر هر مورد مشخص شود. در کنار آن، داده یا صفحهای که باید خصوصی بماند نباید صرفا به خاطر شروع انتشار برای عموم باز شود.
قواعد canonical از روی URL نهایی ساخته و آزمون شوند. باقی ماندن دامنه آزمون یا آدرس قدیمی در قالب، میتواند سیگنال ناسازگار ایجاد کند. همین کنترل برای sitemap، داده ساختاریافته و تصاویر اجتماعی هم لازم است. بهتر است چند خروجی واقعی با ابزار مستقل بررسی شوند تا تیم فقط به پیشنمایش تنظیمات CMS تکیه نکند.
در تغییر دامنه، مالکیت و دسترسی لازم باید پیشاپیش آماده باشد. تنظیمات HTTPS، DNS و ابزارهای مدیریت جستجو بخشی از هماهنگی هستند. همه مهاجرتها از ابزار تغییر نشانی به شکل یکسان استفاده نمیکنند. روش مناسب باید با نوع انتقال و راهنمای رسمی همان ابزار بررسی شود. اقدامات حساب را فرد مجاز و با دسترسی محدود انجام دهد.
نسخه پشتیبان بدون روش برگشت، برنامه کامل نیست. مشخص شود چه کسی بازگشت را تایید میکند، کدام نسخه کد و داده استفاده میشود و دادههای ثبتشده پس از انتشار چه وضعی خواهند داشت. بازگردانی پایگاه داده ممکن است سفارش یا درخواست تازه را تحت تاثیر قرار دهد. این خطر باید پیش از رویداد بررسی شود، نه هنگام بحران.
دروازه انتشار مجموعهای از معیارهای قابل آزمون باشد. برای نمونه، سالم بودن مسیرهای مهم، مقصد درست ریدایرکتها، نبود دستور مسدودکننده ناخواسته و کار کردن فرمها. عدد کلی سلامت جای این شروط را نمیگیرد. اگر یک مسیر تجاری مهم خراب است، ظاهر سالم صفحه اصلی نباید بهتنهایی مجوز ادامه انتشار تلقی شود.
برای بررسی جزئیات در مستندات اصلی، مهاجرت سایت همراه با تغییر URL را ببینید.
برای بررسی جزئیات در مستندات اصلی، تغییر مسیر و جستجوی گوگل را ببینید.
پس از انتشار چگونه ریدایرکت و اثر مهاجرت را کنترل کنیم؟
پس از انتشار، ابتدا آزمونهای فوری فنی انجام شوند. آدرسهای قدیمی باید رفتار مورد توافق را داشته باشند و مقصد تازه با محتوای مناسب پاسخ بدهد. برای جابهجایی دائمی، نوع تغییر مسیر مناسب انتخاب شود. صرف دیدن انتقال در مرورگر کافی نیست. وضعیت پاسخ، تعداد مرحلهها و مقصد نهایی نیز باید از روی درخواست واقعی بررسی شوند.
زنجیره و حلقه تغییر مسیر بهصورت جدا کنترل شوند. اگر URL قدیمی ابتدا به آدرس میانی و سپس به مقصد تازه میرود، ساده کردن مسیر میتواند عیبیابی و نگهداری را آسانتر کند. در انتقالهای چندمرحلهای، قواعد قدیمی ممکن است با قواعد تازه تداخل داشته باشند. نمونهگیری از چند گروه URL به پیدا کردن همین تداخلها کمک میکند.
لینک داخلی باید به مقصد نهایی اشاره کند. تکیه دائمی بر ریدایرکت برای پیوندهای داخل سایت، نگهداری را دشوار میکند. منو، مسیر راهنما، لینک مقاله، تصویر و فایل نیز در این کنترل دیده شوند. بهتر است فهرست اصلاحات بر اساس قالب یا منبع تولید لینک دستهبندی شود تا تیم مجبور به ویرایش دستی پراکنده هزاران مورد نشود.
سایتمپ تازه باید URLهای مناسب نسخه عمومی را معرفی کند. آدرس آزمون، مقصد حذفشده یا نسخه نامناسب نباید بدون بررسی در آن باقی بماند. نقشه سایت، جای لینک داخلی و بررسی دسترسی را نمیگیرد. پس از تغییر، نمونه URLهای داخل فایل با پاسخ واقعی سرور تطبیق داده شوند و نتیجه ارسال یا پردازش نیز در ابزار مرتبط پیگیری شود.

تصاویر و فایلها فراموش نشوند. اگر نشانی آنها تغییر کرده است، مسیر دسترسی، لینک در محتوا و نیاز به انتقال مناسب بررسی شود. خراب شدن تصویر شاخص ممکن است در نگاه نخست خطای بزرگ سئو به نظر نرسد، اما تجربه خواندن و اشتراکگذاری را تحت تاثیر میگذارد. آزمون مقاله باید دریافت خود فایل تصویر را هم شامل شود، نه فقط وجود تگ آن در HTML.
پایش داده جستجو با نقطه شروع قابل مقایسه انجام شود. صفحههای ورودی مهم و گروه پرسشهای مرتبط جدا دیده شوند. ممکن است جابهجایی در سطح URL بهتدریج پردازش شود و نوسان رخ دهد. زمان قطعی برای پایان همه انتقالها تعیین نکنید. در گزارش مشخص باشد کدام نشانه طبیعیِ در حال بررسی است و کدام خطا به اقدام فوری نیاز دارد.
خطای فنی را از نوسان عملکرد جدا کنید. ریدایرکت اشتباه یک صفحه مهم قابل مشاهده و قابل اصلاح است. کاهش کلیک بدون شاهد دیگر هنوز علت مشخصی ندارد. اگر هر تغییر نمودار به بازگشت فوری منجر شود، خودِ رفتوبرگشت میتواند مسئله را پیچیده کند. معیار توقف یا بازگشت باید پیش از انتشار تعیین شده و توسط فرد مسئول ارزیابی شود.
کنترل تجاری همزمان لازم است. ثبت سفارش، ورود، پرداخت، ارسال فرم و ایمیل تایید در محدوده مجاز آزمون شوند. سئوی سالم برای صفحهای که کار اصلی کسبوکار را انجام نمیدهد کافی نیست. نتیجه آزمونهای فنی و تجاری در یک دفتر مشترک ثبت شود تا تیمها تصویر یکسانی از وضعیت داشته باشند و کارهای ضروری میان آنها گم نشوند.
دامنه و قواعد قدیمی زود کنار گذاشته نشوند. نگهداری ریدایرکتها باید با راهنمای رسمی و وضعیت انتقال هماهنگ باشد، نه با پایان ظاهری کار طراحی. هزینه تمدید دامنه، کنترل HTTPS و پایش مقصدها در برنامه دیده شوند. مهاجرت بدون مالک مشخص برای این بخش، ممکن است چند ماه بعد با خطایی تازه و قابل پیشگیری روبهرو شود.
پس از تثبیت، گزارش پایان مرحله نوشته شود. URLهای بررسیشده، خطاهای رفعشده، موارد باز، محدودیت داده و مسئول نگهداری مشخص باشند. این گزارش تضمین حفظ رتبه نیست. ارزش آن در قابل پیگیری کردن تصمیمهاست. مهاجرت حرفهای زمانی شکل میگیرد که علاوه بر نسخه تازه سایت، مسیر نگهداری و واکنش به مسئله بعدی نیز آماده باشد.
| کنترل | پیش از انتشار | پس از انتشار |
|---|---|---|
| نگاشت URL | تعیین مقصد و دلیل تغییر | آزمون پاسخ و مقصد نهایی |
| دستورهای صفحه | ثبت تفاوت محیط آزمون و عمومی | کنترل خروجی واقعی robots و noindex |
| لینک و canonical | تولید بر پایه آدرس نهایی | بررسی منو، متن و نسخه اصلی |
| فرایند تجاری | تعیین سناریو و مسئول آزمون | بررسی فرم و مسیرهای مهم مجاز |
برای بررسی جزئیات در مستندات اصلی، انتقال میزبانی بدون تغییر آدرس را ببینید.
برای بررسی جزئیات در مستندات اصلی، کنونیکال و سیگنالهای نسخه اصلی را ببینید.
پرسش های رایج
آیا هر تغییر هاست به تغییر همه URLها نیاز دارد؟
خیر. انتقال میزبانی با آدرس ثابت، با مهاجرت دارای URL تازه متفاوت است. آزمون و اقدام باید بر اساس نوع واقعی انتقال طراحی شوند.
آیا همه صفحه های قدیمی را به صفحه اصلی منتقل کنیم؟
این کار جای نگاشت مقصد مرتبط را نمیگیرد. برای هر گروه، حفظ، مقصد متناظر یا حذف واقعی باید با نقش محتوا بررسی شود.
آیا می توان نبود افت را تضمین کرد؟
خیر. پردازش جستجو و عوامل بیرونی کاملا در اختیار تیم نیستند. برنامه دقیق میتواند خطاهای قابل پیشگیری را کاهش دهد و واکنش به مسئله را روشن کند.