انتقال سایت عبارتی است که به طور گسترده توسط متخصصان سئو استفاده می‌شود تا هر رویدادی را که در آن سایت تحت تغییرات اساسی قرار می‌گیرد را توصیف کند. تغییرات حوزه‌هایی که می‌توانند تاثیرات معناداری بر پدیدار شدن در موتور جست‌وجو داشته باشند. تغییراتی عمدتا در محل، پلتفرم، ساختار، محتوا، طراحی یا تجربه کاربری سایت.
بخش مستندات گوگل انتقال‌های سایت‌ها را به طور عمیق پوشش نداده و این حقیقت را که آن‌ها معمولا منجر به کاهش معنادار درآمد و ترافیک می‌شوند، کم اهمیت‌تر جلوه می‌دهد. کاهشی که می‌تواند از چند هفته تا چندین ماه دوام داشته باشد و به میزان تاثیرپذیری سیگنال‌های رتبه‌بندی موتور جست‌وجو و زمان لازم برای کسب‌وکار ضرر دیده جهت اجرای یک برنامه بهبودی موفق دارد.
چک لیست انتقال سایت
انواع انتقال سایت
اشتباهات متداول در انتقال سایت
فرایند انتقال سایت
بخش آتی در خصوص چگونگی انتقال‌های موفق و ناموفق خواهد بود و توضیح می‌دهد که خروج از انتقال سایت بدون متحمل شدن ضرر جدی چگونه به طور ۱۰۰ درصد امکان‌پذیر است.
هر کسی که با انتقال سایت مشغول بوده، نظریه شایعی که می‌گوید این امر در واقع منجر به از دست رفتن ترافیک و درآمد می‌شود را شنیده است. با وجود این که این ادعا در خصوص مواردی بسیار خاص صحت دارد (برای مثال جابه‌جایی از یک دامنه تثبیت شده به یک دامنه کاملا جدید)، نباید مقدس و بدون استثنا لحاظ شود. این امکان وجود دارد که انتقال را انجام داده و هیچ درآمد یا ترافیکی از دست ندهید. شما حتی می‌توانید بلافاصله پس از اجرای یک سایت اصلاح شده رشد مشخصی داشته باشید. اما این موضوع تنها زمانی صادق است که تمام گام‌ها به خوبی برنامه‌ریزی و اجرا شوند.
گرافی که در ادامه آمده یک انتقال سایت ناموفق را از یک خرده‌فروشی بریتانیایی نشان می‌دهد. این وبسایت دو هفته پس از انتقال از HTTP به HTTPS ، ۳۵ درصد مشاهدات خود را از دست داده است. حدود شش ماه زمان برد تا آن‌ها به طور کامل به حالت قبلی برگردند که احتمالا تاثیر معناداری بر درآمدشان از جست‌وجوی واقعی داشته است. این مثالی از انتقال ضعیف در سایت است که احتمالا نتیجه برنامه‌ریزی یا اجرای ضعیف بوده است.
اما ریکاوری همیشه امکان‌پذیر نیست. گراف مشاهدات زیر از یک خرده‌فروش بزرگ بریتانیایی دیگر است که در آن انتقال از HTTP به HTTPS منجر به کاهش دائمی ۲۰ درصدی مشاهده می‌شود.
در واقع کاملا امکان‌پذیر است که از HTTP به HTTPS منتقل شد و برای چنین مدت طولانی، این مقدار ترافیک از دست نداد. به جز چند هفته اول که به دلیل پیدا کردن آدرس سایت جدید توسط گوگل و به‌روز رسانی نتایج جست‌وجو، نوسانات بالایی وجود دارد.
یک انتقال سایت موفق چگونه است؟ این به طور عمده به نوع انتقال، اهداف و KPIها (در آینده بیشتر توضیح خواهیم داد) بستگی دارد. اما در غالب موارد، یک انتقال موفق در سایت، حداقل یکی از ویژگی‌های زیر را دارد:
۱-حداقل کاهش آمار مشاهده در هفته‌های اول (هدف کوتاه مدت).
۲- افزایش مشاهده پس از آن، که به نوع انتقال بستگی دارد (هدف بلندمدت).
گزارش مشاهده زیر در خصوص انتقال از یک HTTP به HTTPS است که همچنین با بهبود مشخص در سرعت بارگذاری صفحات سایت همراه بوده است.
زارش آمار مشاهدات زیر از یک تعمیرات اساسی در وبسایت است که من شانس حضور در آن چند ماه پیش از تعمیرات و مشارکت در حمایت از راهبرد، برنامه‌ریزی و مراحل آزمون را داشتم که همگی به یک میزان مهم بودند.به مانند آن چه در دیگر پروژه‌های انتقال متداول است، تاریخ راه‌اندازی به دلیل ریسک‌های پیش از موعد راه‌اندازی سایت و عدم رفع کامل موانع اساسی فنی، چند بار عقب افتاد. اما همان‌طور که گراف مشاهدات زیر می‌بینید، این صبر ارزشش را کاملا داشت.
مشاهدات ناشی از جست‌وجوی واقعی نه تنها کاهش نیافتند، بلکه از هفته اول شروع به رشد کردند.رشد آمار مشاهده یک ماه پس از انتقال به ۶۰ درصد رسید در حالی که رشد ترافیک جست‌وجوی واقعی دو ماه پس از راه‌اندازی ۸۰ درصد را پشت سر گذاشت.
از جایی که وبسایت جدید طراحی مجدد شده بود، از صفر روی یک پلتفرم جدید در یک طبقه‌بندی اصلاح شده که شامل صفحات فرود جدید می‌شد ساخته شده بود، ساختار آدرس آن به‌روز رسانی شده بود، بسیاری از تغییر مسیرها تعبیه شده تا ارزش لینک حفظ شود و همچنینتغییر از HTTP به HTTPS صورت گرفته بود، این انتقال سایت نسبتا پیچیده به شمار می‌آمد.
به طور کلی اعمال تغییرات بسیار در یک زمان می‌تواند سخت باشد چون اگر اشتباهی رخ دهد، زمان خواهد برد تا متوجه شوید اشکال از کجا بوده است. اما در عین حال به تعویق انداختن تغییرات عمده برای آینده نیز ایده‌آل نیست چرا که به منابع بیشتری نیاز خواهد داشت. اگر شما بدانید چه می‌کنید، اعمال چندین تغییر مثبت به طور هم‌زمان می‌تواند بسیار مقرون به صرفه باشد.قبل از پرداختن به اصل موضوع چگونگی موفق شدن در یک پروژه انتقال پیچیده، مهم است که انواع انتقال‌ها را بشناسیم و همچنین دلایل اصلی شکست غالب انتقال‌ها را بدانیم.
انواع مختلفی از انتقال سایت وجود دارد. دسته‌ها به ذات تغییرات اعمال شده بستگی دارند.
دسته‌های بسیار مختلف انتقال سایت
تغییرات محل سایت: تغییر دامنه، برندسازی مجدد- جابه‌جایی یا ادغام بخش‌هایی از سایت- انتقال از HTTP به HTTPS یا HTTP2- جابه‌جایی سایت‌های بین‌المللی- تغییر تنظیمات موبایلی (AMP، PWA)
تغییرات پلتفرم: انتقال به یک پلتفرم جدید- به‌روز رسانی نسخه پلتفرم- معرفی ویژگی‌های جدید پلتفرم- ادغام پلت‌فرم‌های مختلف
تغییرات محتوا: اضافه یا حذف کردن صفحات- اضافه کردن، حذف کردن یا پنهان کردن محتواها- تثبیت محتوا یا صفحات- معرفی زبان‌های جدید
تغییرات ساختاری: تغییرات سلسله‌مراتبی در سایت- تغییرات مسیریابی- تغییرات لینک‌های داخلی- تغییرات نقشه سفر کاربر
تغییرات طراحی و تجربه کاربری: تغییرات تجربه کاربر محور در دستگاه‌های مختلف- تغییرات ظاهری و حسی- تغییرات رسانه‌ای- تغییرات عملکرد سایت
+ تمام ترکیب‌های ممکن
بخش مستندات گوگل اکثرا انتقال‌هایی با تغییرات محل سایت را پوشش می‌دهد که در دسته‌های زیر قرار می‌گیرند:
این زمانی رخ می‌دهد که سایت به خاطر هر یک از دلایل زیر به آدرسی متفاوت منتقل می‌شود:
یک مثال کلاسیک زمان انتقال از HTTP به HTTPS است.
در سئوی بین‌المللی بسیار رایج است. جایی که کسب‌وکاری تصمیم می‌گیرد یک یا چند دامنه سطح بالای کد کشوری را به زیردامنه‌ها یا زیرپوشه‌ها منتقل کند. یک مثال رایج دیگر جایی است که یک وبسایت موبایلی که زیرپوشه یا زیردامنه‌ای متفاوت دارد، به حالت واکنش‌گر در آمده و آدرس‌های موبایل و دسکتاپ یکسان شوند.
به طور متداول زمانی رخ می‌دهد که یک کسب‌وکار به دنبال برندسازی مجدد بوده و باید از یک دامنه به دامنه دیگری منتقل شود.
این زمانی متداول است که یک کسب‌وکار تصمیم به راه‌اندازی وبسایت‌های بین‌المللی گرفته و باید از یک دامنه سطح بالای کد کشوری به یک دامنه سطح بالای عمومی منتقل شود یا بالعکس، مثلا از .co.uk به .com منتقل شود یا از .com به .co.uk منتقل شود.
این تغییرات در معماری سایت بوده و معمولا بر لینک دهی داخلی سایت و ساختار آدرس سایت تاثیر دارند.
دسته‌های دیگر انتقال از تغییراتی در محتوا، ساختار، طراحی یا پلتفرم سایت نشأت می‌گیرند.
این زمانی رخ می‌دهد که یک وبسایت از یک پلتفرم یا سیستم مدیریت محتوا به نوع دیگری منتقل می‌شود. برای مثال انتقال از WordPress به Magneto یا صرفا به‌روز رسانی نسخه قبلی همان پلتفرم. در بعضی موارد، پلتفرم سازی مجدد ممکن است به دلیل محدودیت‌های فنی حین تغییرات پلتفرم به تغییرات آدرس و طراحی سایت نیز منجر شود. به همین دلیل است که معمولا پلتفرم سازی مجدد به ندرت منجر به وبسایتی می‌شود که دقیقا ظاهر قبلی را دارد.
تغییرات اساسی محتوا مانند بازنویسی محتوا، تثبیت محتوا یا هرس کردن محتوا می‌تواند بر مشاهده جست‌وجوی واقعی یک سایت تاثیر بزرگی داشته باشد که به مقیاس کار بستگی دارد. این تغییرات معمولا می‌توانند بر مسیریابی، دسته‌بندی و لینک دهی داخلی سایت تاثیر داشته باشند.
با توجه به گزینه‌های بسیاری که در خصوص جابه‌جایی تنظیمات موبایلی سایت وجود دارد، فعال‌سازی فهرست‌سازی برنامه، ساخت یک سایت AMP یا ساخت یک وبسایت PWA نیز می‌تواند به عنوان یک انتقال مقطعی سایت در نظر گرفته شود. به خصوص زمانی که سایت موبایلی موجود با یک برنامه، AMP یا PWA جایگزین می‌شود.
این موارد معمولا با تغییرات اساسی در دسته‌بندی سایت رخ می‌دهند که بر مسیریابی، لینک دهی داخلی و نقشه مسیر کاربر تاثیر می‌گذارند.
این دسته، از تغییرات طراحی اساسی در ظاهر گرفته تا یک اصلاح کامل وبسایت را شامل می‌شود که همچنین ممکن است شامل تغییرات معناداری در کپی، کد و رسانه بشود.
به علاوه موارد بالا، دسته‌های ترکیبی انتقال نیز وجود دارند که در هر مسیر عملی ممکنی ترکیب می‌شوند. هر چه تغییرات بیشتری در یک زمان ایجاد شوند، ریسک و پیچیدگی بیشتری در پی خواهد داشت . حتی با این وجود که انجام هم‌زمانی تغییرات زیاد می‌تواند ریسک این که خطایی رخ دهد را افزایش دهد، اگر این امر به خوبی برنامه‌ریزی و اجرا شود، از دیدگاه منابع مقرون به صرفه خواهد بود.
با وجود این که هر انتقالی متفاوت از دیگری است، پشت رایج‌ترین فجایع انتقال در سایت‌ها، موارد مشترکی وجود دارند. بزرگ‌ترین موارد قابل ذکر در ادامه آمده‌اند:
استراتژی ضعیف (مانند اهداف ناواضح)- برنامه‌ریزی ضعیف- کمبود هم‌فکری در سئو یا تجربه کاربری- کمبود منابع یا بودجه- مشارکت دیرهنگام- آزمون ضعیف- واکنش کند به رفع باگ- دست کم گرفتن مقیاس
بعضی از انتقال‌ها خیلی قبل‌تر از این که سایت جدید راه‌اندازی شود، محکوم به شکست هستند. استراتژی که بر پایه اهداف غیرواقعی و نامشخص ساخته شده به احتمال بسیار کمتری موفق خواهد شد.برای ارزیابی اثر انتقال سایت پس از راه‌اندازی، برقراری اهداف قابل اندازه‌گیری ضروری است. در غالب انتقال‌ها، هدف اولیه باید حفظ سطوح موجود ترافیک و درآمد سایت باشد. در مواقع خاصی این موارد می‌توانند بالاتر درنظر گرفته شوند، اما در پیش‌بینی و انتظار عمومی، رشد باید هدف درجه دو باشد. این از ایجاد انتظارات غیرواقعی جلوگیری خواهد کرد.
ایجاد هرچه سریع‌تر یک برنامه پروژه جزئی از ایجاد تاخیرها در طول مسیر جلوگیری می‌کند. زمان و منابع اضافی را نیز برای دست‌وپنجه نرم کردن با هر موقعیت غیرقابل پیش‌بینی‌ای که ممکن است رخ دهد در نظر بگیرید. مهم نیست که برنامه شما چه‌قدر جرئی است و خوب پشت آن فکر شده است، احتمال این که همه چیز درست مانند انتظار پیش برود بسیار پایین است. نسبت به برنامه خود انعطاف‌پذیر باشید و این حقیقت که قطعا تاخیرهایی وجود خواهد داشت را بپذیرید. تمام وابستگی‌ها را مشخص کرده و کاری کنید تمام سهام‌داران از آن‌ها باخبر باشند.
از برنامه‌ریزی برای راه‌اندازی نزدیک نقاط اوج فروش فصلی خود اجتناب کنید. چون اگر مشکلی ایجاد شود، زمان کافی برای حل آن نخواهید داشت. برای مثال خرده‌فروشی‌ها باید از راه‌اندازی سایت نزدیک دی ماه یا بهمن خودداری کنند تا دوره شلوغ پیش از عید نوروز را به خطر نیندازند. در این مورد، راه‌اندازی سایت در زمان‌های خلوت ماه‌های تابستان هوشمندانه‌تر خواهد بود.
پیش از متعهد شدن به اجرای یک انتقال سایت ، زمان و تلاش لازم برای موفقیت آن را تخمین بزنید. اگر بودجه شما محدود است، ببینید که آیا اجرای انتقالی که احتمال شکست آن در رسیدن به اهداف اولیه و در نتیجه کاهش درآمد هست، ارزشش را دارد یا خیر. طی یک حساب سرانگشتی سعی کنید ۲۰ درصد بیشتر از منبعی که فکر می‌کردید برای پروژه لازم است، داشته باشید. این مقدار اضافه به شما اجازه می‌دهد در آینده وقتی مشکلی به وجود می‌آید، فورا و بدون به خطر انداختن موفقیت آن را رفع کنید. اگر منابع شما در مضیقه هستند یا شروع به صرفه‌جویی در مراحل اولیه کنید، احتمالا انتقال سایت شما به خطر خواهد افتاد.
وقتی تغییری در یک وبسایت رخ می‌دهد، هر تصمیم باید از نقطه‌نظر سئو و تجربه کاربر سنجیده شود. برای مثال حذف حجم زیادی از محتوا یا لینک‌ها برای بهبود تجربه کاربری ممکن است به توانایی سایت در هدف گرفتن کلیدواژه‌های ضروری کسب‌وکار صدمه بزند یا به مشکلاتی در فهرست‌سازی و خزیدن منجر شوند. در هر دو مورد چنین تغییراتی ممکن است به مشاهده جست‌وجوی واقعی سایت آسیب بزنند. از طرف دیگر، داشتن متن‌های بسیار و عکس‌های کم، ممکن است بر مشارکت کاربر تاثیر منفی داشته و به نرخ تبدیل‌های سایت ضرر برساند.برای اجتناب از ریسک، از مشاوران باتجربه سئو و تجربه کاربری استفاده کنید تا آن‌ها در خصوص عواقب احتمالی هر تغییر با سهام‌داران کلیدی کسب‌وکار بحث کنند. سهام‌دارانی که پیچیدگی‌های کسب‌وکار را بهتر از هر کسی می‌فهمند. پیش از هر تصمیم‌گیری، نکات مثبت و منفی هر دو گزینه باید سنجیده شود.
انتقال سایت ها ممکن است ماه‌ها به طول بینجامد و به برنامه‌ریزی عالی و زمان کافی برای آزمودن نیاز دارد.
جست‌وجوی دیرهنگام به دنبال پشتیبانی حرفه‌ای بسیار ریسکی است چرا که ممکن است گام‌های کلیدی فراموش شده باشند.
در کنار استراتژی عالی و برنامه‌ریزی فکر شده، زمان و تلاشی را به آزمون کامل سایت پیش از راه‌اندازی آن اختصاص دهید. خیلی بهتر است که اگر آزمون به مسائل مهمی برخورده، به جای عجله جهت اجرای ناقص محصول، زمان راه‌اندازی را به تاخیر بیندازید. نیاز به گفتن نیست که نباید یک وبسایت را بدون آزمایش شدن توسط تیم‌های متخصص سئو و تجربه کاربری راه‌اندازی کنید.توجه به جزئیات همچنین بسیار مهم است. اطمینان حاصل کنید که توسعه‌دهندگان کاملا از ریسک‌های مرتبط با اجرای ضعیف آگاه هستند. اطلاع‌رسانی به توسعه‌دهندگان در خصوص تاثیر مستقیم کارشان بر ترافیک سایت (و در نتیجه درآمد سایت) تفاوت بزرگی ایجاد می‌کند.
زمانی که سایت راه‌اندازی می‌شود، همیشه باگ‌هایی وجود دارند که باید برطرف شوند. با این حال بعضی باگ‌ها مهم‌تر از باگ‌های دیگر بوده و به توجه فوری نیاز دارند. برای مثال وقتی پس از راه‌اندازی سایت فورا متوجه این می‌شوید که عنکبوت‌های موتور جست‌وجو در خزیدن و فهرست‌سازی محتوای سایت به مشکل خورده‌اند، باید سریع مشکل را رفع کنید. واکنش کند به موانع فنی مهم بعضی اوقات می‌تواند فاجعه‌بار باشد و ریکاوری از آن زمان زیادی ببرد.
سهام‌داران کسب‌وکار گاهی انتظار ندارند که انتقال سایت زمان‌بر بوده و منابع بسیاری نیاز داشته باشد. غیرمعمول نیست که سهام‌داران عمده بخواهند سایت در روزی که دقیقا برنامه‌ریزی شده اجرا شود، خواه به طور ۱۰۰ درصد آماده باشد یا خیر. شعار «بیایید هرچه سریع‌تر کار را راه‌اندازی کنیم و بعدا مشکلات را رفع کنیم» یک اشتباه کلاسیک است. چیزی که اکثر سهام‌داران از آن آگاه نیستند این است که بازگشت به آمار مشاهده جست‌وجوی واقعی تنها چند روز طول می‌کشد، اما یک ریکاوری ممکن است چند ماه به طول بینجامد.آگاه‌سازی مشتریان، سپری کردن تمام سناریوها و مراحل مختلف با آن‌ها و شرح این که هر مرحله مستلزم چه چیزی است، مسئولیت مشاور و مدیر پروژه است. در آن صورت سهام‌داران کسب‌وکارها قادر هستند که تصمیم‌های آگاهانه‌تری گرفته و مدیریت انتظاراتشان ساده‌تر خواهد شد.
فرآیند انتقال سایت را می‌توان به شش گام ضروری تقسیم کرد.
تمام آن‌ها به مقدار برابری مهم بوده و از قلم انداختن آن‌ها به درجات مختلفی مانع از موفقیت انتقال می‌شود.
مرحله ۱- ارزیابی و برنامه‌ریزی: اهداف، ریسک‌ها، موقعیت‌های رشد و پیش‌بینی سناریوها، راهبردها، برنامه پروژه
مرحله ۲- آماده‌سازی پیش از راه‌اندازی: مرور چارچوب، مشخص‌سازی فنی سئو، شناسایی صفحات در اولویت، برنامه وقایع احتمالی آینده
مرحله ۳- آزمون پیش از راه‌اندازی: مرور محتوا، مرور فنی، آزمون تغییر مسیر، ارزیابی ریسک راه‌اندازی سایت، ارزیابی استانداردها (بنچمارک)
مرحله ۴- پشتیبانی روز راه‌اندازی: عملیات‌های راه‌اندازی سایت، آزمون زنده سایت، پشتیبانی رسانه که هزینه آن پرداخت شده باشد
مرحله ۵- مرور پس از راه‌اندازی: ارزیابی‌ها و عملیات پس از راه‌اندازی، مرور رفع باگ‌ها، نظارت بر عملکرد
مرحله ۶- مرور عملکرد: اولویت‌سازی فعالیت‌های معمول کسب‌وکاری
فارغ از دلایل پشت یک پروژه انتقال، شما باید از ابتدا نسبت به اهداف مشخص باشید چرا که این امر به تنظیم و مدیریت انتظارات کمک می‌کند. جابه‌جایی از HTTP به HTTPS بسیار متفاوت از یک اصلاح کامل سایت است، بنابراین هر یک باید اهداف متفاوتی داشته باشند.در مثال اول، هدف باید بازیابی سطوح ترافیک سایت باشد، در حالی‌که در مثال دوم هدف باید احتمالا رشد باشد.
انتقال در سایت فرصت بسیار خوبی برای حل مشکلات قدیمی است. قرار دادن هر چه بیشتر این مشکلات در یک ظرفیت انتقال تا جای ممکن باید بسیار مقرون به صرفه باشد چرا که حل این مشکلات پس از راه‌اندازی، منابع بسیار بیشتری نیاز خواهد داشت.در هر مورد، حیاتی‌ترین جنبه‌های پروژه را جهت موفق شدن شناسایی کنید. تمام ریسک‌هایی را که ممکن است تاثیری منفی بر مشاهده سایت داشته باشد را شناسایی کرده و اقدامات احتیاطی لازم را لحاظ کنید. حالت ایده‌آل این است که چند سناریوی مورد پیش‌بینی را بر اساس ریسک‌های مختلف و موقعیت‌های رشد آماده کنید. نیاز به گفتن نیست که سناریوهای موردانتظار باید توسط مشاوران باتجربه انتقال سایت آماده شوند.
لحاظ کردن سهام‌داران در این مرحله اولیه تا جایی که ممکن است، به شما کمک می‌کند درک عمیق‌تری از بزرگ‌ترین چالش‌ها و موقعیت‌های بین بخش‌ها پیدا کنید. از تیم‌های سئو، محتوا، تجربه کاربری و تحلیلی خود بازخورد بخواهید و فهرستی از بزرگ‌ترین مسائل و موقعیت‌ها را تهیه کنید. سپس باید بفهمید بازگشت سرمایه احتمالی رسیدگی به هر یک از این موارد چه خواهد بود. یکی از گزینه‌های در دسترس را که راهبرد انتقال سایت شما را شکل می‌دهد بر اساس اهداف و منابع در دسترس خود انتخاب کنید.حال فهرستی از فعالیت‌های اولویت‌بندی شده دارید که انتظار می‌رود در صورت اجرا، بازگشت سرمایه‌ای مثبت در پی داشته باشند. این موارد سپس باید با سهام‌داران به اشتراک گذاشته شده و در خصوص آن‌ها بحث شود. در این صورت اهدافی واقع‌گرایانه خواهید داشت، بر سر پروژه توافق خواهید کرد، ارزیابی خواهید داشت و از ابتدا انتظارات درستی خواهید داشت.
برنامه‌ریزی به همان اندازه اهمیت دارد. چرا که انتقال سایت ها می‌تواند غالبا پروژه‌هایی بسیار پیچیده باشد و به راحتی چند ماه به طول بینجامد. طی هر مرحله برنامه‌ریزی، هر وظیفه باید یک مالک (مانند مشاور سئو، مشاور تجربه کاربری، تدوین‌گر محتوا، توسعه‌دهنده وب) و یک تاریخ آماده‌سازی مورد انتظار داشته باشد. هر وابستگی باید شناسایی شده و در برنامه پروژه لحاظ شود تا همه از هر فعالیتی که به‌خاطر وابستگی به دیگران تکمیل نخواهد شد آگاه باشند. برای مثال تا زمانی که طرح نقشه تغییر مسیر کامل نشده و تغییر مسیرها در اجرای پیش از عمومی شدن تکمیل نشده‌اند، نمی‌توان تغییر مسیرها را آزمود.برنامه پروژه باید هر چه سریع‌تر با تمام افراد مشارکت کننده به اشتراک گذاشته شود تا زمان کافی برای بحث و شفاف‌سازی وجود داشته باشد. هر فعالیت باید به جزئی‌ترین حالت توصیف شود تا سهام‌داران بدانند هر مرحله شامل چه چیزهایی است.
نیازی به گفتن نیست برای سامان‌دهی و انجام فعالیت‌های لازم با توجه به برنامه، به مدیریت پروژه‌ای بی‌نقص لازم است.
یک بخش حیاتی در برنامه پروژه رسیدن به موقع به تاریخ راه‌اندازی است. به طور ایده‌آل، سایت جدید باید زمانی راه‌اندازی شود که ترافیک پایین است. تکرار می‌کنم که از راه‌اندازی سایت پیش از یا حین یک دوره اوج خودداری کنید. چون اگر شرایط آن طور که پیش‌بینی شده پیش نروند، عواقب می‌تواند قاجعه‌بار باشد. چیز دیگری که باید در ذهن داشته باشید این است که چون انتقال سایت ها هیچ وقت دقیقا مانند برنامه پیش نمی‌روند، باید درجه‌ای از انعطاف‌پذیری را داشته باشید.
این موارد شامل هر فعالیتی می‌شود که باید زمانی انجام شوند که سایت جدید همچنان در حال توسعه است. تا این نقطه، ملزومات سئوی سایت جدید باید به دست آمده باشند. شما باید با طراحان و معماران اطلاعاتی در ارتباط باشید و پیش از آن که سایت به محیط آماده برای راه‌اندازی برسد، به خوبی در خصوص نمونه‌های آزمایشی و چارچوب‌ها بازخورد دریافت کرده باشید.
پیش از آغاز توسعه، نمونه‌های آزمایشی یا چارچوب‌های سایت را مرور کنید. مرور الگوهای اصلی سایت جدید می‌تواند در شناسایی مسائل سئو و تجربه کاربر در مراحل اولیه مفید باشد. برای مثال ممکن است متوجه شوید که بخش بزرگی از محتوا از صفحات دسته‌بندی‌ها حذف شده است که باید فورا به آن توجه شود. یا ممکن است دریابید که برخی صفحات با ترافیک بالا دیگر در مسیریابی اصلی ظاهر نمی‌شوند. هر نوع تغییر رادیکال در طراحی یا کپی صفحات باید به طور کامل مرور شود تا هرگونه مشکل بالقوه در سئو یافت شود.
وقتی نمونه‌های آزمایشی و چارچوب‌ها مرور شدند، مشخصاتی جزئی از مسائل فنی سئو آماده کنید. هدف این مستندسازی حیاتی ثبت تمام ملزومات ضروری سئو است که توسعه‌دهندگان باید پیش از ارزیابی پروژه در خصوص کار و هزینه از آن آگاه باشند. بودجه‌ها طی این مرحله است که قطعی می‌شوند. اگر ملزومات سئو در آن لحاظ نشده باشند، در نظر گرفتن آن‌ها در آینده غیرممکن خواهد بود.مشخصات فنی سئو باید بسیار جزئی باشند و در عین حال به شکلی نوشته شده باشند که توسعه‌دهندگان به سادگی ملزومات را به عمل تبدیل کنند. این سندی برای شرح چرایی اجرا نیست، بلکه شرحی بر نحوه اجراست.
همچنین اطمینان حاصل کردن از این که هنگام به‌روز رسانی یک ویژگی خاص (مانند یک h1)، عناصر دیگر (مانند عنوان صفحه یا هر فهرستی از مسیریابی) تحت تاثیر قرار نمی‌گیرند، مهم است.
یکی از بزرگ‌ترین چالش‌های انتقال سایت این است که موفقیت به طور گسترده به کمیت و کیفیت صفحاتی که مورد انتقال قرار گرفته‌اند بستگی دارد. از این رو، اطمینان حاصل کردن از تمرکز بر روی صفحاتی که واقعا اهمیت دارند، مهم است. این‌ها صفحاتی هستند که در سایت قدیمی ترافیک به همراه داشته‌اند، لینک‌ها به این صفحات منتج شده است، نرخ تبدیل خوبی دارند و… .
برای این کار، شما باید:
با عمل crawl شما یک کپی از تمام آدرس‌ها، عناوین صفحات، فرداده‌ها، تیترها، تغییر مسیرها، لینک‌های خراب و … خواهید داشت. فارغ از برنامه انتخابی جهت crawl (ضمیمه را ببینید) اطمینان حاصل کنید که crawl زیاد سفت و سخت نباشد. پیش از crawl در سایت قدیمی، خوب به تنظیمات برنامه مورد نظر توجه کنید و موارد زیر را در نظر بگیرید:
راهنمای حرفه‌ای: تا چند ماه پس از تکمیل انتقال از داده crawl سایت قدیمی یک کپی داشته باشید (روی ابر یا در یک فایل) تا وقتی سایت جدید روی کار آمد، در صورت نیاز داده‌های سایت قبلی را در اختیار داشته باشید.
وقتی عمل crawl به پایان رسید، روی شناسایی صفحات فهرست شده سایت قدیمی کار کنید. این موارد شامل تمام صفحات HTML با ویژگی‌های زیر می‌شوند:
صفحات فهرست‌پذیر تنها صفحاتی هستند که ممکن است بتوانند ترافیک را به سمت سایت هدایت کنند. از این رو باید در جهت هدف انتقال سایت شما اولویت‌بندی شوند. این‌ها صفحاتی هستند که ارزش بهینه‌سازی (اگر قرار است در سایت جدید حضور داشته باشند) یا تغییر مسیر (اگر قرار است در سایت جدید حضور نداشته باشند) را دارند.
وقتی تمام صفحات فهرست‌پذیر را شناسایی کردید، باید یک کار دیگر نیز انجام دهید. به خصوص اگر سایت قدیمی از صفحات بسیار زیادی تشکیل شده و با توجه به زمان یا محدودیت‌های فنی، بهینه‌سازی یا تغییر مسیر تمام آن‌ها امکان‌ناپذیر است.اگر مسئله همین است، باید صفحات سایت قدیمی را که عملکرد بالایی داشته‌اند شناسایی کنید. این کمک می‌کند که در اولویت‌بندی صفحات در مراحل بعدی تمرکز داشته باشید.
پیشنهاد می‌شود که یک صفحه گسترده آماده کنید که شامل موارد زیر می‌شود:
با داشتن هم‌زمان اطلاعات بالا، حال شناسایی مهم‌ترین صفحاتتان بسیار ساده‌تر است: صفحاتی که مشاهده‌های واقعی را رقم می‌زنند، نرخ تبدیل خوبی دارند، در درآمد تاثیر دارند، تعداد قابل توجهی از دامنه‌ها به آن‌ها لینک شده‌اند و … . این‌ها صفحاتی هستند که برای یک انتقال موفق، باید روی آن‌ها تمرکز کنید.به طور ایده‌آل، صفحات با عملکرد بالا باید در سایت جدید نیز وجود داشته باشند. اگر به هر دلیلی این طور نیست، باید به مربوط‌ترین صفحه تغییر مسیر داده شوند تا کاربری که درخواست آن‌ها را داده با صفحه ۴۰۴ مواجه نشود و ارزش لینکی که پیش از این وجود داشته، در سایت باقی بماند. اگر هر یک از این صفحات دیگر وجود نداشته باشند و تغییر مسیر به خوبی انجام نشود، ترافیک و رتبه سایت شما به طور منفی تحت تاثیر قرار می‌گیرد.
وقتی زمان راه‌اندازی سایت جدید نزدیک می‌شود، شما باید عملکرد سایت قدیمی را مورد معیارسنجی قرار دهید. معیارسنجی ضروری است نه تنها برای مقایسه عملکرد سایت قبلی با سایت جدید، بلکه برای شناسایی حوزه‌هایی که سایت جدید در آن‌ها ضعیف عمل می‌کند تا آن‌ها را برطرف سازد.
اگر به طور مداوم رتبه سایت را دنبال نمی‌کنید، پیش از راه‌اندازی سایت جدید باید این کار را انجام دهید.
در غیر این‌صورت، برای این که در آینده بدانید که آیا انتقال سایت درست پیش رفته یا خیر، یا این که اشکال دقیقا از کجاست، به مشکل برخواهید خورد. این مورد را برای لحظه آخر نگذارید چرا که ممکن است موضوعی آمار را منحرف کند. یک هفته پیش از شروع، زمان ایده‌آلی خواهد بود.زمانی را صرف این که کنید که بدانید کدام کلیدواژه‌ها بیشتر از بقیه نماینده آمار مشاهده جست‌وجوی واقعی سایت است و آن‌ها را در موبایل و دسکتاپ ردیابی کنید. از آن‌جا که مشاهده هزاران ترکیب از کلیدواژه اصلی، طولانی و متوسط غیرواقع‌بینانه است، حداقل کلیدواژه‌های کافی که باید بر آن‌ها نظارت کنید آن‌هایی هستند که باعث ایجاد ترافیک در سایت می‌شوند (رتبه کلیدواژه‌ها در صفحه اول) و حجم جست‌وجوی خوبی دارند (تمرکز بر کلمات اصلی یا با اندازه متوسط).
اگر ترافیک را از کلماتی دریافت می‌کنید که هم برند هستند و هم نه، باید تصمیم بگیرید که از دیدگاه ردیابی باید بر کدام نوع کلیدواژه تمرکز کنید. کلیدواژه‌هایی که برند نیستند رقابتی‌تر و نوسانی‌تر هستند. در اکثر سایت‌ها تمرکز بر این دسته منطقی است.فراموش نکنید که رتبه‌بندی را در دسکتاپ و موبایل دنبال کنید. اگر پس از راه‌اندازی مشکلات عملکرد در یکی از دستگاه‌ها وجود داشته باشد، این کار پیدا کردن مسئله را راحت‌تر می‌سازد. اگر از بیش از یک کشور حجم زیادی از ترافیک را دریافت می‌کنید، ردیابی رتبه کلیدواژه‌ها را در بازارهای دیگر نیز در نظر داشته باشید زیرا آمار مشاهده و رتبه‌ها ممکن است از کشور تا کشور تفاوت معناداری داشته باشند.
زمان‌های بارگذاری صفحه سایت جدید می‌تواند تاثیر عمده‌ای بر ترافیک و فروش داشته باشد. مطالعات بسیاری نشان می‌دهند که هر چه زمان بارگذاری یک صفحه طولانی‌تر باشد، نرخ دفع کاربر(بانس ریت) نیز بالاتر خواهد بود. اگر زمان بارگذاری صفحه و نمرات عملکرد سایت قدیمی ثبت نشده باشند، پس از راه‌اندازی سایت جدید ربط دادن هر کاهش ترافیک یا درآمد به مشکل عملکردی سایت بسیار سخت خواهد بود.پیشنهاد می‌شود که با استفاده از ابزار سرعت سنج گوگل و Lighthouse انواع دسته‌های صفحات اصلی را مرور کنید. باید با استفاده از جدول خلاصه‌ای مانند زیر، بعضی از مهم‌ترین معیارهای عملکرد را معیارسنجی کنید. این مورد پس از آن که سایت جدید راه‌اندازی شد، برای مقایسه مفید خواهد بود.
چند روز پیش از آن که سایت جدید جای سایت قدیمی را بگیرد، یک crawl نهایی از سایت قدیمی بگیرید. اگر در سایت جدید مشکلات بهینه‌سازی وجود داشته باشد، ارزش این کار در آینده قابل قیمت‌گذاری نیست. Crawl نهایی به شما این امکان را می‌دهد که اطلاعاتی حیاتی در خصوص عناوین صفحه سایت قدیمی، توضیحات متا، تگهای h1-h6، وضعیت سرور، تگهای کنونیکال، صفحات noindex/nofollow، inlinks/outlinks، سطح و … ذخیره داشته باشید. اگر برای مثال سایت جدید به خوبی بهینه‌سازی نمی‌شود یا از مسائل فنی پیکربندی اشتباه رنج می‌برد، داشتن تمام این اطلاعات می‌تواند از مشکلات بسیاری جلوگیری کند. همچنین سعی کنید از robots.txt و نقشه سایت XML سایت قدیمی یک کپی داشته باشید چرا که ممکن است در آینده به آن‌ها احتیاج داشته باشید.
استخراج داده‌های Search Console سایت قدیمی را نیز تا جای ممکن در نظر داشته باشید. این‌ها تنها برای ۹۰ روز در دسترس خواهند بود و احتمالاتی وجود دارند که وقتی سایت جدید اجرا شود، داده Search Console سایت قدیمی دیر یا زود ناپدید شود. داده‌هایی که ارزش استخراج دارند شامل موارد زیر می‌شوند:
اجرای تغییر مسیرها یکی از حیاتی‌ترین فعالیت‌های یک انتقال در سایت است. اگر آدرس‌های سایت قدیمی دیگر وجود ندارند و در حال حاضر تغییر مسیر داده نشده‌اند، آمار مشاهده و رتبه سایت به سادگی افت خواهند کرد.
تغییر مسیرها به این دلیل بسیار مهم هستند که به موتورهای جست‌وجو و کاربران کمک می‌کنند صفحاتی را پیدا کنند که دیگر وجود ندارند، تغییر نام داده شده‌اند یا به محل دیگری منتقل شده‌اند. از نقطه‌نظر سئو، تغییر مسیرها به موتورهای جست‌وجو کمک می‌کنند تا آدرس جدید سایت را سریع‌تر کشف و فهرستبندی کرده و تا همچنین نحوه ارتباط صفحات سایت قدیمی با صفحات سایت جدید را درک کنند. این ارتباط به سیگنال‌های رتبه‌بندی این امکان را می‌دهد که از صفحات قدیمی به صفحات جدید بیایند و رتبه بدون آن که تحت تاثیر منفی قرار بگیرد، همان‌جا باقی می‌ماند.
وقتی تغییر مسیرها به طور صحیح اجرا نمی‌شوند، عواقب فاجعه‌بار خواهند بود. کاربران یا به صفحات «Not Found» (۴۰۴) برمی‌خورند، یا به صفحات نامربوطی می‌رسند که به هدف کاربر ربطی ندارند. در هر دو حالت نرخ‌های تبدیل و دفع کاربر سایت به طور منفی تحت تاثیر قرار می‌گیرند. عواقب هر یک می‌تواند به طور برابر برای موتورهای جست‌وجو فاجعه‌آمیز باشد: اگر آدرس‌های سایت یکسان نباشند، موتورهای جست‌وجو نمی‌توانند صفحات سایت قدیمی را با سایت جدید ارتباط دهند. سیگنال‌های رتبه‌دهی از سایت قدیمی به سایت جدید منتقل نخواهند شد و در نتیجه با کاهش رتبه و کاهش مشاهده ناشی از جست‌وجوی واقعی مواجه خواهیم شد. به علاوه، کشف و فهرستبندی صفحات سایت جدید برای موتورهای جست‌وجو بیشتر زمان خواهد برد.
وقتی آدرس‌های بین نسخه‌های قدیمی و جدید سایت متفاوت هستند، از تغییر مسیرهای ۳۰۱ (دائمی) استفاده کنید. این به موتورهای جست‌وجو می‌گوید که آدرس‌های جدید را فهرستبندی کرده و همچنین سیگنال‌های رتبه‌بندی را از آدرس‌های قدیمی به جدید منتقل کنند. از این رو اگر سایت شما از یک دامنه یا زیردامنه دیگر منتقل می‌شود، اگر از HTTP به HTTPS می‌روید یا اگر سایت یا بخش‌هایی از آن ساختاردهی مجدد شده‌اند، باید از تغییر مسیرهای ۳۰۱ استفاده کنید. با وجود بعضی ادعاهای گوگل مبنی بر این که تغییر مسیرهای ۳۰۲ رتبه‌دهی صفحه را منتقل می‌کنند، فهرستبندی آدرس‌های جدید کندتر خواهد بود و انتقال سیگنال‌های رتبه‌بندی از صفحه سایت قدیمی به جدید بیشتر زمان خواهد برد.
تغییر مسیرهای ۳۰۲ (مقطعی) تنها زمانی باید مورد استفاده قرار گیرند که قرار نباشد تغییر مسیر به طور دائم حضور داشته و از این رو فهرستبندی آدرس جدید اولویت محسوب نمی‌شود. با تغییر مسیرهای ۳۰۲، موتورهای جست‌وجو در ابتدا نسبت به فهرستبندی محتوای آدرس مقصد تغییر مسیر خنثی خواهند بود و هر سیگنال تغییر مسیری را به آن انتقال می‌دهند. اما اگر تغییر مسیر مقطعی برای مدتی طولانی حذف یا به‌روز رسانی نشود، در نهایت به مانند تغییر مسیرهای دائمی (۳۰۱) عمل خواهند کرد. زمانی از ۳۰۲ استفاده کنید که احتمال حذف یا به‌روز رسانی آن در آینده نزدیک وجود داشته باشد. این موضوع برای هر تغییر مسیری اعم از کشور، زبان یا مخصوص یک دستگاه صادق است.
از تغییر مسیرهای متا رفرش و جاوا اسکریپت باید اجتناب شود. با وجود این که گوگل مدام با crawling در جاوا اسکریپت سازگارتر می‌شود، تضمینی برای کشف آن‌ها و انتقال سیگنال‌های رتبه‌دهی به صفحات جدید وجود ندارد.
اگر تمایل دارید تا با نحوه کار گوگل با دسته‌های مختلف تغییر مسیر بیشتر بدانید، به پست جان مولر مراجعه کنید.
اگر آن‌قدر خوش شانس هستید که با انتقالی کار می‌کنید که شامل تغییرات آدرس سایت نمی‌شود، می‌توانید این بخش را پشت سر بگذارید. در غیر این صورت بخوانید تا بدانید چرا هر صفحه‌ای که پس از انتقال با آدرس یکسان از دسترس خارج می‌شود، باید تغییر مسیر داده شود.
نقشهبرداری تغییر مسیر صفحه‌گسترده‌ای است که شامل دو ستون می‌شود:
هنگام نقشهبرداری(تغییر مسیر)یک صفحه از سایت قدیمی به جدید، تلاش کنید آن را به مرتبط‌ترین صفحه تغییر مسیر دهید.
در مواردی که صفحه مربوطی وجود ندارد، از تغییر مسیر آن صفحه به صفحه اصلی سایت اجتناب کنید. در وهله اول و پیش از هر چیز، تغییر مسیر کاربران به یک صفحه نامربوط، منجر به تجربه کاربری بسیار ضعیفی می‌شود. گوگل اعلام کرده که با تغییر مسیر «تمام صفحات» به صفحات نامربوط مانند یک خطای ۴۰۴ نرم برخورد خواهد کرد و از این رو هیچ ارزش سئویی نخواهد داشت. اگر نمی‌توانید صفحه برابری در سایت جدید پیدا کنید، تلاش کنید آن را به صفحه دسته‌بندی منبع آن نقشهبرداری کنید.وقتی نقشهبرداری به پایان رسید، فایل باید به تیم توسعه فرستاده شود تا تغییر مسیر ایجاد شود تا بتوان این موارد را پیش از راه‌اندازی سایت جدید آزمود. اجرای تغییر مسیرها بخش دیگری از چرخه انتقال سایت است که ممکن است اشتباه پیش برود.
نقشهبرداری تغییر مسیر به توجه بالایی به جزئیات نیاز دارد و باید توسط افراد با تجربه سئو کار انجام شود. نقشهبرداری آدرس سایت‌های کوچک در تئوری ممکن است به صورت دستی با نقشهبرداری هر یک از آدرس‌های سایت قدیمی به آدرس سایت جدید انجام شود. اما در سایت‌های بزرگ که شامل هزاران یا حتی صدها هزار صفحه هستند، نقشهبرداری دستی تک تک آدرس‌ها عملا غیرممکن است و باید از اتوماسیون استفاده شود. تکیه بر ویژگی‌های مشترک مشخصی بین سایت قدیمی و جدید می‌تواند به شدت در حفظ زمان موثر باشد. این ویژگی‌ها می‌تواند شامل عناوین صفحات، تیترهای h1 یا هر شناسه خاص صفحه دیگری مانند کدهای محصولات، واحد نگهداری موجودی و … باشد. اطمینان حاصل کنید که برای نقشهبرداری تغییر مسیرها روی ویژگی‌هایی تکیه کنید که خاص هستند و در چندین صفحه تکرار نشده‌اند. در غیر این صورت به نقشهبرداری ناصحیحی خواهید رسید.
راهنمای حرفه‌ای: حتما پیش از شروع کار روی نقشهبرداری تغییر مسیر، ساختار آدرس سایت باید نهایی شده باشد. هیچ چیز ریسکی‌تر از آن نیست که نقشهبرداری آدرس‌ها پیش از اجرای سایت جدید به‌روز رسانی شوند. وقتی پس از تکمیل نقشهبرداری تغییر مسیر آدرس‌ها به‌روز رسانی شدند، باید با موقعیت‌های ناخواسته‌ای پیش از راه‌اندازی، مانند تغییر مسیرهای ناقص، زنجیره‌های تغییر مسیر و حلقه‌های تغییر مسیر دست‌وپنجه نرم کنید. پیش از تاریخ انتقال، یک دوره عدم تغییر محتوا باید در سایت قدیمی انجام شود تا یک نقطه پایان برای انتشار محتوای جدید روی سایت قدیمی وجود داشته باشد. این سبب می‌شود هیچ صفحه‌ای در نقشهبرداری تغییر مسیر از دست نرود و تغییر مسیر تمام صفحات را از سایت قبلی تضمین می‌کند.
باید تغییر مسیرهای فعلی سایت قدیمی را درک کنید تا اطمینان حاصل شود که هنگام آماده‌سازی نقشهبرداری تغییر مسیرهای سایت جدید آن‌ها لحاظ شده‌اند. اگر این کار را نکنید، احتمال دارد که در تاریخ راه‌اندازی، فایل تغییر مسیر فعلی توسط فایل تغییر مسیر جدید جایگزین شود. اگر این اتفاق رخ دهد، تمام تغییر مسیرهای سایت قدیمی از بین رفته و سایت احتمالا مقادیر قابل توجهی از ارزش لینک را از دست می‌دهد. این مقدار به طور عمده به حجم تغییر مسیرهای سایت قدیمی بستگی دارد. برای مثال سایتی که در گذشته چند بار تحت انتقال قرار گرفته، تغییر مسیرهای قدیمی خوبی دارد که نباید آن‌ها را از دست بدهد.
به طور ایده‌آل باید هر تعداد تغییر مسیرهای قدیمی ممکن را حفظ کنید و مطمئن شوید هنگام ترکیب با تغییر مسیرهای سایت جدید هیچ مشکلی پیش نخواهد آمد. به طور قوی پیشنهاد می‌شود که در این مرحله اولیه، هر زنجیره احتمالی تغییر مسیری حذف شود. این کار به سادگی با چک کردن این که آیا در صفحه‌گسترده نقشهبرداری تغییر مسیر آدرس یکسانی برای آدرس‌های سایت قدیمی و سایت جدید قرار می‌گیرند یا خیر، قابل انجام است. اگر این موضوع صحت دارد، باید با توجه به آن آدرس سایت جدید را به‌روز رسانی کنید.
آدرس a به آدرس b تغییر مسیر داده می‌شود (تغییر مسیر قدیمی)
آدرس b به آدرس c تغییر مسیر داده می‌شود (تغییر مسیر جدید)
که منجر به زنجیره زیر می‌شود:
URL A –> URL B –> URL C
برای حذف این، تغییر مسیر قدیمی فعلی را اصلاح کرده و یک تغییر مسیر جدید ایجاد کنید تا:
آدرس a به آدرس c تغییر مسیر داده شود (تغییر مسیر قدیمی اصلاحی)
آدرس b به آدرس c تغییر مسیر داده شود (تغییر مسیر جدید)
راهنمای حرفه‌ای: صفحه گسترده نقشهبرداری تغییر مسیر خود را جهت حلقه‌های تغییر مسیر چک کنید. این مورد زمانی رخ می‌دهد که آدرس قدیمی با آدرس جدید یکسان باشند. حلقه‌های تغییر مسیر باید حذف شوند چرا که منجر به بی‌نهایت صفحات در انتظار بارگذاری خواهند شد که برای کاربران و موتورهای جست‌وجو غیرقابل دسترس هستند. حلقه‌های تغییر مسیر باید حذف شوند چرا که قاتل فوری ترافیک، نرخ تبدیل و رتبه‌بندی‌ها هستند.
قویا پیشنهاد می‌شود که قوانین تغییر مسیری را امتحان کنید که تا جای ممکن درخواست‌های آدرس را پوشش دهند. اجرای قوانین تغییر مسیر در یک سرور وب بسیار کاراتر از تکیه بر چندین تغییر مسیر یک به یک است. اگر سند نقشهبرداری تغییر مسیر شما شامل تعداد بسیاری از تغییر مسیرها می‌شود که باید به عنوان قوانین یک به یک تغییر مسیر اجرا شوند، ممکن است عملکرد سایت به طور منفی تحت تاثیر قرار بگیرد. در هر شرایطی، حداکثر تعداد تغییر مسیرهایی که وب بدون مشکل می‌تواند مدیریت کند را با تیم توسعه چک کنید.
در هر موردی، قوانین تغییر مسیر استانداردی وجود دارند که جهت جلوگیری از ایجاد محتوای تکراری باید اجرا شوند:
حتی اگر تعدادی از این قوانین استاندارد تغییر مسیر در وبسایت قدیمی وجود داشته باشند، فرض نکنید که لزوما روی سایت جدید هم وجود خواهند داشت. مگر آن که به طور انحصاری درخواست شوند.
سعی کنید لینک‌های داخلی سایت را به‌روز رسانی کنید تا موجب تغییر مسیرهای داخلی نشوند. با وجود این که موتورهای جست‌وجو می‌توانند تغییر مسیرهای داخلی را دنبال کنند، این مورد پیشنهاد نمی‌شود. چرا که سبب تاخیر در زمان بارگذاری سایت شده و همچنین تاثیری منفی بر زمان crawl موتور جست‌وجو خواهند داشت.
اگر عکس‌های سایت به محل جدیدی رفته‌اند، گوگل پیشنهاد می‌کند که آدرس عکس‌های قدیمی را به آدرس عکس‌های جدید تغییر مسیر دهید تا به گوگل کمک کنید عکس‌های جدید را سریع‌تر پیدا و فهرستبندی کند. اگر تغییر مسیر تمام عکس‌ها ساده نیست، هدفتان حداقل باید تغییر مسیر آدرس عکس‌هایی باشد که از هایپرلینک سایت دیگری منتج شده‌اند.
در انتقال سایت هر چه تست را زودتر شروع کنید بهتر است. بعضی چیزها باید کامل آماده اجرا باشند تا آزمایش شوند، اما بعضی دیگر خیر. برای مثال مسائل نقشه راه کاربر را می‌توان در مراحل اولیه نمونه‌های آزمایشی یا طراحی چارچوب‌ها تشخیص داد. همچنین مسائل مربوط به محتوا بین سایت جدید و قدیمی یا عدم سازگاری محتواها را می‌توان در مراحل اولیه تشخیص داد (برای مثال بین سایت موبایلی و دسکتاپ). اما عناصر فنی‌تر باید زمانی که کاملا اجرا می‌شوند، آزمایش شوند. مواردی مانند تغییر مسیرها، تگ‌ها کنونیکال یا نقشه سایت‌های XML. هرچه مشکلات سریع‌تر شناسایی شوند احتمال آن که پیش از راه‌اندازی سایت برطرف شوند بیشتر است.
شناسایی بعضی مسائل در مراحل جلوتر اصلا مقرون به صرفه نیست، به منابع بیشتری نیاز خواهد داشت و تاخیرهای مهمی را رقم خواهد زد. آزمون ضعیف یا عدم تخصیص زمان مناسب برای تست کامل تمام بلوک‌های تشکیل دهنده که ممکن است بر عملکرد سئو یا تجربه کاربری تاثیر بگذارند، می‌تواند بلافاصله پس از اجرای سایت جدید، عواقب فاجعه‌باری داشته باشند.
پیش از آن که سایت را در محیط آماده‌سازی یا آزمایش مهیا کنید، اقداماتی احتیاطی انجام دهید تا موتورهای جست‌وجو آن را فهرستبندی نکنند. راه‌های مختلفی برای این کار وجود دارند که هر یک مزایا و معایب خود را دارند.
فراهم کردن سایت برای یک سری IPهای خاص (لیست سفید) راه بسیار موثری برای جلوگیری از خزیدن موتورهای جست‌وجو به آن است. کسی که به دنبال دسترسی به آدرس سایت باشد، به محتوایی دست پیدا نخواهد کرد مگر آن که در لیست سفید قرار گرفته باشد. مزیت اصلی این است که لیست سفیدها می‌توانند بدون مشکلی به سایت crawl کرده و به راحتی به آن دسترسی داشته باشند. تنها عیب آن این است که ابزار ثالث وب محور (مانند ابزار گوگل) به خاطر محدودیت‌های IP قابل استفاده نیستند.
رمز گذاشتن برای سایت آزمایشی یا در حال آماده‌سازی یکی دیگر از راه‌های دور نگه داشتن موتورهای جست‌وجوست، اما این راه دو عیب اساسی دارد. بسته به اجرا، ممکن است در صورت عدم توانایی برنامه crawler در عبور از صفحه لاگین، امکان آزمایش و crawl در سایتی که با رمز از آن محافظت می‌شود وجود نداشته باشد. عیب دیگر این که برنامه‌های ثالث crawl در سایت‌های رمزداری که برای دسترسی از فرم استفاده می‌کنند ممکن است، اما ریسک وقوع مسائلی حاد و غیرقابل پیش‌بینی وجود دارد. زیرا crawler روی هر لینکی در صفحه کلیک می‌کند (وقتی لاگین کردید) و ممکن است به سادگی روی لینکی کلیک کند که صفحه‌ای ایجاد یا حذف کند یا افزونه‌هایی نصب یا پاک کند و … .
اضافه کردن خطوط کد زیر به فایل Robots.txt از crawl موتورهای جست‌وجو به صفحات سایت جلوگیری می‌کند:
123User-agent: * Disallow: /
از معایب این روش این است که هر چند محتوای ظاهر شده در سرور آزمایشی فهرستبندی نخواهد شد، اما آدرس غیر مجاز (disallow) شده ممکن است در نتایج جست‌وجوی گوگل ظاهر شود. یکی از معایب دیگر این است که اگر فایل robots.txt بالا به سایت جدید منتقل شود، مسائل ضدفهرست‌بندی جدی ایجاد خواهد کرد. این چیزی است که من بارها با آت برخورد کرده‌ام و برای همین استفاده از این روش را برای بلاک کرده موتورهای جست‌وجو پیشنهاد نمی‌کنم.
اگر سایت ساختاردهی یا طراحی مجدد شده است، احتمال این که نقشه راه کاربر تا حدی تحت تاثیر قرار بگیرد وجود دارد. مرور هر چه سریع‌تر و مناسب نقشه راه کاربر پیش از راه‌اندازی سایت جدید به دلیل نبود داده کاربر سخت است. اما یک فرد حرفه‌ای در تجربه کاربر می‌تواند هر موردی که ممکن است تاثیری منفی بر نرخ تبدیل سایت داشته باشد را شناسایی کند. از آن‌جا که آزمون A/B در این مرحله تقریبا غیرممکن است، اجرای آزمون‌های کاربر و تلاش برای دریافت بازخورد از کاربران واقعی ارزشمند خواهد بود. متاسفانه حل مسائل تجربه کاربری کمی سخت‌تر خواهد بود چرا که ممکن است نیاز به تغییراتی در سراسر سایت داشته باشد که تلاش و زمان بسیاری خواهد برد.
وقتی یک اصلاح سایت کامل صورت می‌گیرد، تمام تصمیمات تجربه کاربر قابل پشتیبانی با داده نیست و بسیاری تصمیمات باید بر پایه بهترین روش، تجربه قبلی و شهود اتخاذ شوند. از این رو مشارکت دادن متخصصان سئو و بهینه‌سازی نرخ تبدیل (CRO) هر چه زودتر باشد، در آینده جواب خود را خواهد داد.
انتقال سایت معمولا فرصت خوبی برای بهبود معماری سایت است. به عبارت دیگر، شما فرصت این را دارید که محتوای هدفمند با کلیدواژه خود را سامان‌دهی مجدد کرده و پتانسیل ترافیک جست‌وجوی آن را به حداکثر برسانید. انجام تحقیقات گسترده کلیدواژه به شناسایی بهترین صفحات دسته و زیر دسته کمک خواهد کرد تا کاربران و موتورهای جست‌وجو می‌توانند با چند کلیک به هر صفحه‌ای از سایت دسترسی پیدا کنند. هر چه تعداد کلیک‌ها کمتر باشد و از این رو دسته‌بندی شما زیاد عمیق نباشد، بهتر است.
شناسایی کلیدواژه‌های جدید با پتانسیل ترافیک مناسب و نقشهبرداری آن‌ها به صفحات فرود جدید می‌تواند در سطوح ترافیک ناشی از جست‌وجوی واقعی سایت تفاوت بزرگی ایجاد کند. از طرف دیگر، بهبود معماری سایت باید بافکر صورت بگیرد. می‌توان گفت اگر صفحات مهم در معماری سایت جدید عمیق‌تر شده یا صفحات شبیه به هم بسیاری برای کلیدواژه‌های یکسان بهینه‌سازی شده باشند، مشکلاتی ایجاد خواهد شد. برخی از موفق‌ترین انتقال‌ها آن‌هایی هستند که منابع قابل توجهی را به بهبود معماری سایت اختصاص می‌دهند.
مطمئن شوید که عناوین صفحات، توضیحات متا، تیترها و کپی، بدون مشکل از سایت قدیمی به سایت جدید منتقل شده‌اند. اگر صفحه جدیدی ایجاد کرده‌اید، مطمئن شوید بهینه‌سازی شده‌اند و تا کلیدواژه‌هایی را که در صفحات دیگر مورد هدف قرار گرفته‌اند، هدف نگذارید. اگر پلتفرم سازی مجدد انجام می‌دهید، آگاه باشید که پلتفرم جدید ممکن است هنگام خلق صفحات جدید، ارزش‌های پیش‌فرض متفاوتی داشته باشد. راه‌اندازی سایت جدید در صورتی که عناوین صفحات به طور مناسبی بهینه‌سازی نشده‌اند یا هر گونه کپی از دست رفته باشد، تاثیرات فوری و منفی بر رتبه سایت و ترافیک آن خواهد گذاشت. فراموش نکنید که مرور کنید آیا محتوای ایجاد شده توسط کاربر (مانند نقدها یا کامنت‌های کاربر) هم آپلود شده است یا خیر.
لینک‌های داخلی ستون اصلی یک وبسایت هستند. مهم نیست که کپی سایت چه‌قدر خوب ساختاردهی یا بهینه‌سازی شده است، اگر توسط یک برنامه بی‌نقص لینک‌دهی داخلی پشتیبانی نشود، برای موفقیت چیزی کم خواهد داشت. لینک‌های داخلی باید در طول تمام سایت مرور شوند و لینک‌های پیدا شده در موارد زیر را شامل شوند:
برای اطمینان از صحت تنظیمات فنی سایت جدید یک سری بررسی‌های فنی باید صورت بگیرد و تا همچنین از مواجه ناگهانی با مسائل فنی پس از اجرای سایت، اجتناب شود.
در محیط آماده‌سازی فایل Robots.txt سایت جدید را آماده کنید. از این طریق می‌توانید هنگام اجرای سایت جدید، آن را جهت خطاها و اشکالات بررسی کرده و از تجربه مسائل crawl موتور جست‌وجو جلوگیری کنید. یک خطای متداول در انتقال سایت زمانی است که فایل robots.txt با استفاده از دستورالعمل زیر از دسترسی موتور جست‌وجو جلوگیری می‌کند:
Disallow: /
اگر این موضوع به طور اتفاقی در سایت در حال اجرا پیش آمد (که معمولا هم پیش خواهد آمد) از crawl موتورهای جست‌وجو در سایت جلوگیری می‌کند. و زمانی که موتورهای جست‌وجو نتوانند در یک صفحه فهرستبندی شده crawl کنند، کلیدواژه‌های مربوط به صفحه در نتایج جست‌وجو تنزل رتبه پیدا کرده و در نهایت فهرستبندی صفحه از بین می‌رود.
اما اگر فایل robots.txt طی آماده‌سازی با دستورالعمل‌های robots.txt سایت جدید پر شده باشد، از این اشتباهات جلوگیری می‌شود.
وقتی فایل robots.txt سایت جدید را آماده می‌کنید، مطمئن شوید:
تگهای کنونیکال سایت را مرور کنید. به دنبال صفحاتی باشید که یا تگ کنونیکال ندارند یا تگ کنونیکالی دارند که به سمت یک آدرس دیگر می‌رود و ببینید که آیا این موضوع عمدی بوده یا خیر. Crawl کردن در تگهای کنونیکال را فراموش نکنید تا ببنیید آیا واکنشی مثبت خواهند داشت یا خیر. اگر این چنین نیست، باید آن‌ها را به‌روز رسانی کنید تا واکنش‌های سرور ۳xx، ۴xx و ۵xx را از بین ببرند. همچنین باید به دنبال صفحاتی باشید که تگ کنونیکال در آن‌ها با ترکیب با دستورالعملی غیرفهرست‌بندی شده، به سمت یک آدرس دیگر هدف رفته‌اند. زیرا این‌ها سیگنال‌هایی متعارض بوده و باید یکی از آن‌ها را حدف کنید.
وقتی در سایت در حال آماده‌سازی crawl کردید، به دنبال صفحاتی با ویژگی متا روبات باشید تا به دستورالعمل‌های «noindex» یا «nofollow» تنظیمشان کنید. اگر این موضوع صادق است، هر یک از آن‌ها را مرور کنید تا مطمئن شوید این موضوع از عمد بوده و اگر دستورالعمل‌های «noindex» یا «nofollow» حذف نبودند، آن‌ها را حذف کنید.
دو نوع نقشه‌سایت متفاوت را آماده کنید. یکی که شامل تمام صفحات فهرستبندی شده سایت جدید می‌شود و یکی که شامل تمام صفحات فهرستبندی شده سایت قدیمی می‌شود. مورد اول به گوگل کمک می‌کند تا از آدرس‌های قابل فهرستبندی سایت جدید آگاه شود. مورد دوم نیز به گوگل کمک می‌کند تا از تغییر مسیرهایی که وجود دارند آگاه شده و متوجه این حقیقت شود که بعضی از آدرس‌های فهرستبندی شده به محل جدیدی رفته‌اند تا بتواند آن‌ها را شناسایی کرده و نتایج جست‌وجو را سریع‌تر به‌روز رسانی کند.
اگر تعداد ردیف‌ها بیشتر از ۵۰۰۰۰ است یا اندازه فایل فراتر از ۵۰ مگابایت می‌شود، باید نقشه‌سایت را به اجزای کوچک‌تری تقسیم کنید. این در صورتی که گوگل به طور مداوم نقشه‌سایت را درخواست کند، از بارگذاری بیش از حد در سرور جلوگیری می‌کند.همچنین باید در هر نقشه‌سایت XML crawl کنید تا مطمئن شوید تنها شامل آدرس‌های قابل فهرستبندی است. هر آدرس غیرقابل فهرستبندی باید از نقشه‌سایت XML خارج شود. مانند:
12345678910111213141516171819 <!DOCTYPE html>· <html>· <head>· <meta name="robots" content="noindex" />· (…)· </head>· <body> (…) </body>· </html>
12345· HTTP/1.1 200 OK· Date: Tue, 10 Nov 2017 17:12:43 GMT· (…)· X-Robots-Tag: noindex· (…)
ساخت نقشه‌سایت شفاف XML می‌تواند در نظارت بر سطوح صحیح فهرستبندی سایت جدید هنگامی که اجرا می‌شود کمک کند. اگر مسائل فهرستبندی را پیدا نکنید، این کار بسیار سخت خواهد شد.
راهنمای حرفه‌ای: هر یک از نقشه‌سایت‌های XML را دانلود و در اکسل باز کنید تا نمایی جزئی از هر یک از ویژگی‌های اضافه مانند hreflang یا ویژگی‌های عکسی داشته باشید.
داشتن یک نقشه‌سایت HTML بسته به اندازه و نوع سایتی که مورد انتقال قرار می‌گیرد، می‌تواند در موارد خاصی مفید باشد. یک نقشه‌سایت HTML که شامل آدرس‌هایی است که از مسیریابی اصلی سایت لینک نگرفته‌اند، می‌تواند به خوبی کشف و فهرستبندی صفحه را تقویت کند. با این حال از ایجاد نقشه‌سایت HTML که شامل چندین آدرس می‌شود اجتناب کنید. اگر نیاز است که هزاران آدرس را لحاظ کنید، ساخت یک نقشه‌سایت بخش‌بندی شده را در نظر بگیرید.تعداد نقشه‌سایت‌های تو در تو نیز مانند حداکثر تعداد آدرس‌هایی که باید در هر نقشه‌سایت لحاظ کنید به قدرت سایت بستگی دارد. هر چه یک سایت قدرت‌مندتر باشد، می‌تواند تعداد نقشه‌سایت‌های تو در تو و آدرس‌های بیشتری داشته باشد.
برای مثال نقشه‌سایت HTML سایت NYTimes.com از سه سطح تشکیل شده است که هر یک شامل بیش از ۱۰۰۰ آدرس در هر نقشه‌سایت می‌شوند. این نقشه‌سایت‌های تو در توی HTML به crawlerهای موتور جست‌وجو کمک می‌کنند مقاله‌های منتشر شده از سال ۱۸۵۱ را پیدا کند. در غیر این صورت کشف و فهرستبندی آن‌ها سخت می‌شد. چرا که تمام آن‌ها به صورت داخلی لینک‌دهی نشده‌اند.
خطاهای نشانه‌گذاری‌های داده‌های ساخت‌یافته باید سریع شناسایی شوند تا زمان کافی برای درست کردن آن‌ها پیش از اجرای سایت جدید وجود داشته باشد. به طور ایده‌آل، باید با استفاده از ابزار تست داده ساخت‌یافته گوگل، الگوی هر صفحه را تست کنید (به جای تست هر صفحه). مطمئن شوید که نشانه‌گذاری صفحات دسکتاپ و موبایل را چک کرده باشید. به خصوص اگر صفحات موبایل واکنش نشان نمی‌دهند.
این ابزار تمام خطاها را نشان می‌دهد اما اشتباهات را نه. برای مثال اگر الگوی صفحه محصول شما شامل برنامه داده ساخت‌یافته محصول نمی‌شود، ابزار هیچ خطایی گزارش نخواهد داد. پس در کنار بررسی خطاها، باید همچنین مطمئن شوید که هر الگوی صفحه شامل نشانه‌گذاری مناسب داده ساخت‌یافته برای نوع محتوای خود می‌شود.لطفا برای به‌روزترین جزئیات در خصوص اجرای داده ساخت‌یافته و انواع محتوای حمایتی به اسناد گوگل مراجعه کنید.
شما باید هر الگوی صفحه سایت جدید را تست کنید تا گوگل اطمینان حاصل شود گوگل خواهد توانست محتوایی را که به تجزیه جاوا اسکریپت نیاز دارند crawl کند. اگر می‌توانید از ابزار رندر و فچ گوگل حین آماده‌سازی سایت استفاده کنید، باید حتما این کار را بکنید. در غیر این صورت، با پیروی از پیشنهاد جاستین بریگ، تست‌هایی دستی انجام دهید.
همان‌طور که تست‌های بارتوش گورالویچ نشان دادند، حتی اگر گوگل بتواند در محتوای ایجاد شده توسط جاوا اسکریپت crawl کرده و فهرستبندی کند، به این معنا نیست که می‌تواند در تمام چارچوب‌های اصلی جاوا اسکریپت در محتواهای جاوا اسکریپت crawl کند. جدول زیر یافته‌های بارتوش را نشان می‌دهد و نشان می‌دهد که بعضی از چارچوب‌های جاوا مناسب سئو نیستند و در حال حاضر چارچوب AngularJS بیش از بقیه مسئله‌ساز است.
بارتوش همچنین دریافت که دیگر موتورهای جست‌وجو (مانند بینگ، یاندکس و بایدو) واقعا با فهرستبندی محتوای ایجاد شده توسط جاوا اسکریپت مشکل دارند. اگر ترافیک سایت شما به هر یک از موتورهای ذکر شده بستگی دارد، دانستن این نکته مهم است.
به طور خوش‌بینانه این موضوعی است که طی زمان بهبود پیدا می‌کند. اما با افزایش محبوبیت چارچوب‌های جاوا اسکریپت در توسعه وب، این موضوع باید در اولویت شما باشد.در نهایت باید چک کنید که آیا هیچ منبع خارجی بلاک شده است یا خیر. متاسفانه این چیزی نیست که بتوانید به طور ۱۰۰ درصد کنترل کنید چون منابع بسیاری (مانند فایل‌های CSS و جاوا اسکریپت) وبسایت میزبان ثالثی دارند که ممکن است آن‌ها را توسط فایل‌های robots.txt خودشان بلاک کنند.تکرار می‌کنم که ابزارهای فچ و رندر می‌توانند چنین مسائلی را شناسایی کنند. مسائلی که اگر حل نشده باقی بمانند، تاثیر منفی معناداری در پی خواهند داشت.
?
در ابتدا مطمئن شوید که فایل robots.txt به طور تصادفی هیچ فایل عکسی، جاوا اسکریپت یا CSS را که برای رندر کردن محتوای سایت ضروری هستند، بلاک نکرده باشد. این می‌تواند بر نحوه رندر کردن موتورهای جست‌وجو و فهرستبندی محتوای صفحه سایت موبایلی تاثیری منفی داشته باشد. این می‌تواند در نهایت تاثیری منفی بر عملکرد و مشاهده از طریق جست‌وجوی موبایل داشته باشد.
?
برای اجتناب از هر مسئله‌ای در فهرستبندی گوگل که اولویت آن با موبایل است وبسایت موبایل را به طور کامل مرور کرده و مطمئن شوید در حوزه‌های زیر هیچ ناسازگاری بین سایت‌های موبایلی و دسکتاپ وجود نداشته باشد:
یک وبسایت واکنش‌گر باید همان محتوا، لینک‌ها و نشانه‌گذاری‌های بین دستگاه‌ها را ارائه دهد و ویژگی‌های سئوی فوق باید در وبسایت‌های دسکتاپ و موبایلی یکسان باشند.
به علاوه، وابسته به تنظیمات سایت موبایلی، باید چند بررسی فنی اضافه‌تر نیز انجام دهید.
یک وبسایت واکنش‌گرا باید در تمام دستگاه‌ها کدهای HTML یکسانی ارائه دهد که بسته به اندازه صفحه (طی استفاده از CSS) تنظیم می‌شود.
?
گوگل‌بات قادر است تا زمانی که اجازه crawl در صفحه و دارایی‌های آن را دارد، این تنظیمات موبایلی را شناسایی کند. از این رو اطمینان از این که گوگل‌بات می‌تواند به تمام دارایی‌های ضروری مانند عکس‌ها، فایل‌های CSS و جاوا اسکریپت دسترسی داشته باشد بسیار مهم است.برای سیگنال دادن به یک مرورگر که یک وبسایت واکنش‌گر است، یک تگ متای =”viewport” باید همراه با <head> هر صفحه HTML، قرار بگیرد.
1<meta name="viewport" content="width=device-width, initial-scale=1.0">
اگر تگ متای viewport جا افتاده باشد، سایز فونت‌ها در اندازه‌های نامتناسب ظاهر خواهند شد. موضوعی که سبب می‌شود گوگل با آن مانند صفحه‌ای رفتار کند که مناسب موبایل نیست.
?
اگر وبسایت موبایل از آدرس‌های جدایی نسبت به دسکتاپ استفاده می‌کند، مطمئن شوید:
?
وبسایت‌های سروینگ پویا به هر دستگاه کد متفاوتی ارائه می‌دهند، اما روی همان آدرس.
?
در وبسایت‌های سروینگ پویا، بررسی کنید که آیا تیتر متفاوت HTTP به طور درست برپا شده یا خیر. این موضوع ضروری است چرا که وبسایت‌های سروینگ پویا HTML عوامل کاربر موبایل را تغییر می‌دهند و تیتر متفاوت HTTP به گوگل‌بات کمک می‌کند تا محتوای موبایلی را پیدا کند.
فارغ از تنظیمات موبایل (واکنش‌گر، آدرس‌های جداگانه و سروینگ پویا)، صفحات را با استفاده از عامل کاربری موبایل مرور کرده و مطمئن شوید:
ابزار تست تناسب با موبایل گوگل می‌تواند در شناسایی اکثر مشکلات بالا مفید باشد.
اگر وبسایت AMP وجود دارد و نسخه دسکتاپی سایت در دسترس است، مطمئن شوید:
همچنین باید مطمئن شوید که AMPها معتبر هستند. این می‌تواند با استفاده از ابزار تست AMP گوگل آزمایش شود.
با توجه به این که گوگل به شدت به سایت‌ها فشار می‌آورد که ایمن باشند و کروم اولین مرورگری است که به صفحات HTTP نشان غیرایمن می‌زند، هدفتان این باشد که سایت جدید را در HTTPS راه‌اندازی کنید و مطمئن شوید که تمام منابع مانند عکس‌ها، فایل‌های CSS و جاوا اسکریپت از طریق ارتباطات امن HTTPS خواسته می‌شوند. این برای اجتناب از مشکل محتوای به‌هم ریخته ضروری است.محتوای به‌هم ریخته زمانی رخ می‌دهد که صفحه‌ای که در یک ارتباط امن HTTPS بارگذاری شده از طریق ارتباطات ناامن HTTP درخواست دارایی کند. اکثر مرورگرها یا درخواست‌های خطرناک HTTP را بلاک کرده یا تنها هشداری نشان می‌دهند که مانع تجربه کاربری می‌شوند.
?
راه‌های بسیاری برای شناسایی خطاهای محتوای به‌هم ریخته وجود دارند که شامل استفاده از برنامه‌های crawler، لایت‌هاوس گوگل و … می‌شوند.
گوگل کمتر از صفحات HTML در عکس‌ها crawl می‌کند. اگر عکس سایت را از یک محل به محلی دیگر منتقل می‌کنید (برای مثال از دامنه خود به CDN)، راه‌هایی برای کمک به گوگل جهت پیدا کردن سریع‌تر عکس وجود دارد. ساخت یک نقشه‌سایت XML عکسی کمک خواهد کرد، اما شما باید همچنین مطمئن شوید که گوگل‌بات می‌تواند هنگام crawl در سایت به عکس سایت دسترسی پیدا کند. بخش سخت فهرستبندی عکس این است که صفحه وبی که عکس در آن ظاهر می‌شود و خود فایل عکس باید فهرستبندی شوند.
در آخر چیزی که اهمیتش کمتر از بقیه نیست، اندازه‌گیری زمان بارگذاری صفحه سایت قدیمی و مقایسه آن با سایت جدید هنگام آماده‌سازی آن است. در این مرحله، بر جنبه‌های مستقل از شبکه عملکرد مانند استفاده از منابع خارجی (عکس‌ها، CSS و جاوا اسکریپت)، کد HTML و پیکربندی سرور سایت تمرکز کنید. در ادامه اطلاعات بیشتری در این خصوص آمده است.
مطمئن شوید که ردیابی تحلیل‌ها به خوبی تنظیم شده باشد. این بررسی به طور ایده‌آل باید توسط مشاوران تحلیلی صورت بگیرد که فراتر از اجرای کد ردیابی عمل می‌کنند. مطمئن شوید اهداف و رویدادها به خوبی تنظیم شده‌اند، ردیابی تجارت الکترونیک اجرا می‌شود و ردیابی تجارت الکترونیک پیشرفته فعال شده است و … . هیچ چیز ناامیدکننده‌تر از این نیست که پس از اجرای سایت جدید، هیچ داده تحلیلی نداشته باشید.
تست تغییر مسیرها در انتقال سایت پیش از آن که سایت جدید اجرا شود ضروری است و می‌تواند از بروز مشکلات بسیاری در آینده جلوگیری کند. راه‌های بسیاری برای بررسی تغییر مسیرها در سرور در حال ساخت یا آزمایشی وجود دارند، اما حرف آخر این است که شما نباید پیش بدون آزمودن تغییر مسیرها، وبسایت جدید را راه‌اندازی کنید.
وقتی تغییر مسیرها در محیط آماده‌سازی یا تست جدید در دسترس قرار گرفتند، در تمام لیست تغییر مسیرها crawl کرده و به دنبال مشکلات زیر بگردید:
راهنمای حرفه‌ای: مطمئن شوید یکی از آدرس‌های سایت قدیمی به سایت جدید تغییر مسیر می‌شود. در این مرحله، چون سایت جدید هنوز وجود ندارد، تنها می‌توانید تست کنید که آیا آدرس مقصد تغییر مسیر همان آدرس مدنظر است یا خیر اما قطعا ارزشمند است. این که یک آدرس تغییر مسیر می‌شود، دلیلی بر آن نیست که به صفحه درست تغییر مسیر می‌شود.
در انتقال سایت وقتی سایت جدید جای سایت قدیمی را می‌گیرد، این احتمال وجود دارد که سایت در حال اجرا به طور موقت داون شود. زمان داون بودن سایت باید به حداقل رسانده شود. ، اما زمانی که این اتفاق رخ می‌دهد، سرور باید به هر درخواست آدرسی واکنش سرور ۵۰۳ را داشته باشد (در دسترس نبودن سرویس). این به crawlerهای موتورهای جست‌وجو خواهد گفت که سایت جهت نگهداری به طور موقت داون شده تا آن‌ها بعدا برای crawl در سایت بازگردند.
اگر سایت برای زمان زیادی داون شده و واکنش سرور ۵۰۳ را نشان نمی‌دهد و موتورهای جست‌وجو در سایت crawl می‌کنند، آمار مشاهده جست‌وجوی واقعی سایت تحت تاثیر منفی قرار گرفته و وقتی سایت برمی‌گردد ریکاوری فوری صورت نخواهد گرفت. همچنین زمانی که سایت به طور موقت داون شده، باید یک صفحه آگاهی‌رسانی نمایش دهد که به کاربران نشان دهد سایت جهت تعمیرات به طور موقت داون شده است.
تا سایت جدید اجرا می‌شود، نگاه سریعی به موارد زیر داشته باشید:
بررسی این نقاط فنی باید هم در سایت موبایلی و هم سایت دسکتاپ انجام شود. مگر این که سایت به طور کامل واکنش‌گر باشد.
فعالیت‌های زیر به محض آن که سایت جدید اجرا می‌شود باید انجام شوند:
راهنمای حرفه‌ای: برای هر نوع صفحه متفاوت، از «فچ به عنوان گوگل» استفاده کنید (برای مثال برای صفحه اصلی، یک دسته، یک زیردسته، یک صفحه محصول) تا مطمئن شوید گوگل‌بات می‌تواند بدون مشکل صفحات را رندر کند. گزارشی از هر منبع بلاک شده را مرور کنید و فراموش نکنید که فچ و رندر را برای دسکتاپ و موبایل استفاده کنید. به خصوص اگر سایت موبایل واکنش‌گرا نیست.
?
وقتی سایت جدید اجرا شد، دور جدیدی از بررسی‌های عمیق باید صورت گیرد. این‌ها به طور عمده مشابه مواردی هستند که در بخش مرحله سوم انتقال سایت؛ یعنی، «تست پیش از راه‌اندازی» ذکر شدند.اما تفاوت اصلی در این مرحله این است که حال به ابزار و داده‌های بسیار بیشتری دسترسی دارید. تلاشی را که باید در این مرحله به کار ببندید دست کم نگیرید. زیرا هر مشکلی که حالا با آن روبه‌رو می‌شوید مستقیم بر عملکرد سایت در صفحه نتایج موتورهای جست‌وجو تاثیر دارد. از طرف دیگر، هرچه مشکل سریع‌تر شناسایی شود، سریع‌تر حل خواهد شد.
مضاف بر وظایف تستی که در مرحله سوم ذکر شدند، در حوزه‌هایی موارد باید کامل‌تر، دقیق‌تر و جزئی‌تر بررسی شوند.
حال می‌توانید به طور کامل از مزایای Search Console بهره ببرید.
نگاهی به آمار crawl در search console داشته باشید تا مطمئن شوید گوگل صفحات سایت جدید را crawl می‌کند. به طور کلی وقتی گوگل‌بات به صفحات جدید می‌آید، تمایل پیدا می‌کند تا میانگین صفحاتی را که روزانه crawl می‌کند افزایش دهد. اما اگر نتوانید در روز راه‌اندازی شیب رو به بالایی را ببنیید، احتمالا چیزی بر قابلیت گوگل‌بات جهت crawl در سایت تاثیر منفی گذاشته است.
?
مرور لاگ‌های سرور با اختلاف موثرترین راه برای کشف هر مسئله crawl یا هر ناسازگاری است. ابزاری مانند Botify و On Crawl می‌توانند به شدت مفید باشند زیرا آن‌ها crawlها را با داده‌های لاگ سرور ترکیب می‌کنند و می‌توانند صفحاتی را که موتورهای جست‌وجو crawl نمی‌کنند، مشخص کنند. صفحاتی که لینک به داخل نشده‌اند (صفحات یتیم)، صفحاتی که ارزش پایینی دارند و به شدت لینک به داخل شده‌اند و بسیاری صفحات دیگر.
به طور ایده‌آل طی هفته‌های ابتدایی روزانه نگاهی به خطاهای گزارش شده crawl داشته باشید. دانلود روزانه این خطاها، crawl در آدرس‌های گزارش شده و انجام عملیات لازم (یعنی اجرای تغییر مسیرهای ۳۰۱ بیشتر، درست کردن خطاهای نرم ۴۰۴) به ریکاوری سریع کمک می‌کند. احتمال این که نیاز باشد هر خطای ۴۰۴ که گزارش می‌شود را تغییر مسیر دهید به شدت کم است، اما برای مهم‌ترین‌ها باید این کار را انجام دهید.
?
راهنمای حرفه‌ای: در گوگل Analytics می‌توانید به سادگی متداول‌ترین آدرس‌های درخواست شده ۴۰۴ را پیدا کرده و در ابتدا آن‌ها را درست کنید.
?
دیگر ویژگی‌های Search Console مانند منابع بلاک شده، خطای داده‌های ساخت‌یافته، خطای استفاده موبایلی، بهبودهای HTML و هدف‌گیری‌های بین‌المللی (برای بررسی خطاهای گزارش شده hreflang) نیز ارزش چک شدن را دارند.
راهنمای حرفه‌ای: در صورتی که پارامترهای آدرس مسائل محتوای تکراری را ایجاد کرده‌اند نگاه نزدیکی به آن‌ها داشته باشید. اگر این مورد صحت دارد، اجرای چند عمل فوری چاره‌ساز را در نظر داشته باشید.
?
وقتی سایت جدید اجرا می‌شود، سرعت سایت را اندازه‌گیری کنید تا مطمئن شوید صفحات سایت هم روی دسکتاپ و هم روی موبایل سریع بارگذاری می‌شوند. از آن‌جا که سرعت سایت یکی از عوامل رتبه‌بندی بین دستگاه‌هاست و صفحات کم سرعت کاربر و مشتری از دست می‌دهند، مقایسه سرعت سایت جدید با سرعت سایت قدیمی بسیار مهم است.اگر زمان بارگذاری صفحه سایت جدید طولانی‌تر است، باید فورا عمل‌هایی صورت دهید.
در غیر این صورت ترافیک و نرخ تبدیل سایت شما خیلی جدی افت خواهند کرد.
در این مرحله از انتقال سایت دو ابزار گوگل که می‌توانند در این مورد مفید باشند Lighthouse و Pagespeed Insights هستند.
ابزار Pagespeed Insights عملکرد صفحه را هم در موبایل و هم در دسکتاپ می‌سنجد و داده سرعت صفحه واقعی را بر اساس داده کاربری که گوگل از کروم جمع‌آوری کرده نشان می‌دهد. همچنین به کارگیری بهترین شیوه‌های متداول عملکردی را چک کرده و یک نمره بهینه‌سازی ارائه می‌کند. این ابزار شامل دسته‌های اصلی ذیل می‌شود:
?
لایت‌هاوس گوگل در عملکرد موبایل، دسترسی و بازرسی وب برنامه‌های پیش‌رونده بسیار مفید است. معیارهای متفاوت بسیار و مفیدی فراهم می‌کند که می‌توانند برای سنجش عملکرد صفحه در دستگاه‌های موبایل مورد استفاده قرار بگیرند. عملکردهایی چون:
هر دو ابزار پیشنهاداتی ارائه می‌دهند که به بهبود مسائل عملکردی گزارش شده از سایت کمک می‌کنند.
?
همچنین می‌توانید برای دریافت تخمینی حدودی از درصد کاربرانی که ممکن است از صفحات سایت موبایل به دلیل زمان بارگذاری کند صفحات از این ابزار استفاده کنید.
?
همین ابزار مقایسه‌ای صنعتی فراهم می‌کند تا بتوانید ایده‌ای از این داشته باشید که در صنعت خود چه‌قدر از سایت‌هایی با برترین عملکرد فاصله دارید.
?
وقتی سایت اجرا شود، می‌توانید بر اساس کاربرانی که سایت شما را مشاهده می‌کنند شروع به ارزیابی سرعت سایت کنید. اگر گوگل Analytics را داشته باشید، می‌توانید به سادگی زمان میانگین بارگذاری سایت جدید را با سایت قدیمی مقایسه کنید.?
همچنین اگر به یک ابزار نظارتی کاربر واقعی مانند Pingdom دسترسی داشته باشید می‌توانید بر اساس کاربرانی که سایت شما را مشاهده می‌کنند سرعت سایت را ارزیابی کنید. نقشه پایینی نشان می‌دهند چگونه کاربران مختلف زمان‌های بارگذاری بسیار مختلفی را بر اساس محل‌های جغرافیایی خود تجربه می‌کنند. در مثال زیر، زمان‌های بارگذاری صفحه ظاهرا برای کاربرانی از بریتانیا، آمریکا و آلمان رضایت‌بخش بوده است. اما برای کاربرانی که در کشورهای دیگر ساکن هستند، این زمان بسیار بیشتر است.
?
آیا انتقال سایت موفق بوده است؟ این یک سوال میلیون دلاری است که هر کس کار انتقال سایت انجام داده می‌خواهد جواب آن را به محض آن که سایت جدید اجرا شد بداند. در واقعیت، هر چه بیشتر صبر کنید جواب واضح‌تر خواهد بود.چرا که آمار مشاهده در چند هفته یا حتی چند ماه اول ممکن است بسته به اندازه و قدرت سایت شما بسیار نوسانی باشد. برای سایت‌های کوچک، ۴ الی ۶ هفته زمانی کافی خواهد بود پیش از آن که آمار سایت جدید را با سایت قدیمی مقایسه کنید. در وبسایت‌های بزرگ‌تر، باید حداقل ۲ تا ۳ ماه پیش از مقایسه صبر کنید.
همچنین اگر سایت جدید به طور مشخصی با سایت قبلی فرق دارد، کاربران به زمان نیاز خواهند داشت تا به ظاهر جدید عادت کنند و با دسته‌بندی جدید، نقشه راه کاربر و … خو بگیرند. چنین تغییراتی معمولا در ابتدا تاثیراتی منفی و مشخص بر نرخ تبدیل سایت خواهند داشت که باید پس از چند هفته که کاربران بیشتر و بیشتر به سایت عادت می‌کنند، بهبود پیدا می‌کند. به هر حال، نتیجه‌گیری‌های داده محور در خصوص تجربه کاربری سایت جدید می‌تواند بسیار ریسکی باشد.اما این‌ها تنها چند قانون سرانگشتی هستند و باید با عوامل دیگر لحاظ شوند. برای مثال اگر چند روز یا چند هفته پس از راه‌اندازی سایت جدید تغییرات معنادار و بیشتری انجام شوند (برای مثال جهت بررسی مسائلی فنی)، ارزیابی انتقال باید عقب‌تر بیفتد.
ارزیابی عملکرد بسیار مهم است و حتی با وجود این که ذی‌نفعان تنها به شنیدن تاثیر ترافیک و درآمد علاقه دارند، معیارهای بسیار دیگری وجود دارند که شما باید به آن‌ها توجه کنید. برای مثال دلایل بسیاری وجود خواهند داشت که درآمد پس از انتقال سایت افت کند، شامل روندهای فصلی، علاقه کمتر به برند، مسائل تجربه کاربری که به طور معناداری نرخ تبدیل سایت را پایین‌تر می‌آورند، عملکرد ضعیف موبایلی، زمان‌های طولانی بارگذاری صفحات و … .
پس در کنار آمار ترافیک جست‌وجوی واقعی و درآمد، همچنین به موارد زیر توجه کنید:
مرور موارد زیر نیر می‌تواند بسیار مفید باشد. به خصوص از دیدگاه حل مسائل فنی:
