پارمیسافت

انتقال سایت و راهنمای انتقال سایت: راهبرد سئو، فرایند و چک لیست

  • ۱۳۹۷/آذر/۲۵
  • 14
  • 2188
انتقال سایت

 انتقال یک سایت چیست؟

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

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

مثال‌های انتقال سایت

بخش آتی در خصوص چگونگی انتقال‌های موفق و ناموفق خواهد بود و توضیح می‌دهد که خروج از انتقال سایت بدون متحمل شدن ضرر جدی چگونه به طور ۱۰۰ درصد امکان‌پذیر است.

اشتباه بودن افسانه «ترافیک از دست رفته مورد انتظار»

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

مثال‌هایی از انتقال‌های ناموفق

گرافی که در ادامه آمده یک انتقال سایت ناموفق را از یک خرده‌فروشی بریتانیایی نشان می‌دهد. این وبسایت دو هفته پس از انتقال از HTTP به HTTPS ، ۳۵ درصد مشاهدات خود را از دست داده است. حدود شش ماه زمان برد تا آن‌ها به طور کامل به حالت قبلی برگردند که احتمالا تاثیر معناداری بر درآمدشان از جست‌وجوی واقعی داشته است. این مثالی از انتقال ضعیف در سایت است که احتمالا نتیجه برنامه‌ریزی یا اجرای ضعیف بوده است.

انتقال سایت
اما ریکاوری همیشه امکان‌پذیر نیست. گراف مشاهدات زیر از یک خرده‌فروش بزرگ بریتانیایی دیگر است که در آن انتقال از HTTP به HTTPS منجر به کاهش دائمی ۲۰ درصدی مشاهده می‌شود.

 

انتقال سایت

در واقع کاملا امکان‌پذیر است که از HTTP به HTTPS منتقل شد و برای چنین مدت طولانی، این مقدار ترافیک از دست نداد. به جز چند هفته اول که به دلیل پیدا کردن آدرس سایت جدید توسط گوگل و به‌روز رسانی نتایج جست‌وجو، نوسانات بالایی وجود دارد.

مثال‌هایی از انتقال‌های موفق

یک انتقال سایت موفق چگونه است؟ این به طور عمده به نوع انتقال، اهداف و KPIها (در آینده بیشتر توضیح خواهیم داد) بستگی دارد. اما در غالب موارد، یک انتقال موفق در سایت، حداقل یکی از ویژگی‌های زیر را دارد:
۱-حداقل کاهش آمار مشاهده در هفته‌های اول (هدف کوتاه مدت).
۲- افزایش مشاهده پس از آن، که به نوع انتقال بستگی دارد (هدف بلندمدت).
گزارش مشاهده زیر در خصوص انتقال از یک HTTP به HTTPS است که همچنین با بهبود مشخص در سرعت بارگذاری صفحات سایت همراه بوده است.

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

رشد آمار مشاهده

مشاهدات ناشی از جست‌وجوی واقعی نه تنها کاهش نیافتند، بلکه از هفته اول شروع به رشد کردند.رشد آمار مشاهده یک ماه پس از انتقال به ۶۰ درصد رسید در حالی که رشد ترافیک جست‌وجوی واقعی دو ماه پس از راه‌اندازی ۸۰ درصد را پشت سر گذاشت.

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

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

انواع انتقال‌های سایت

انواع مختلفی از انتقال سایت وجود دارد. دسته‌ها به ذات تغییرات اعمال شده بستگی دارند.

انتقال سایت

دسته‌های بسیار مختلف انتقال سایت

 

تغییرات محل سایت: تغییر دامنه، برندسازی مجدد- جابه‌جایی یا ادغام بخش‌هایی از سایت- انتقال از HTTP به HTTPS یا HTTP2- جابه‌جایی سایت‌های بین‌المللی- تغییر تنظیمات موبایلی (AMP، PWA)

تغییرات پلت‌فرم: انتقال به یک پلت‌فرم جدید- به‌روز رسانی نسخه پلت‌فرم- معرفی ویژگی‌های جدید پلت‌فرم- ادغام پلت‌فرم‌های مختلف

تغییرات محتوا: اضافه یا حذف کردن صفحات- اضافه کردن، حذف کردن یا پنهان کردن محتواها- تثبیت محتوا یا صفحات- معرفی زبان‌های جدید

تغییرات ساختاری: تغییرات سلسله‌مراتبی در سایت- تغییرات مسیریابی- تغییرات لینک‌های داخلی- تغییرات نقشه سفر کاربر

تغییرات طراحی و تجربه کاربری: تغییرات تجربه کاربر محور در دستگاه‌های مختلف- تغییرات ظاهری و حسی- تغییرات رسانه‌ای- تغییرات عملکرد سایت

+ تمام ترکیب‌های ممکن

 

بخش مستندات گوگل اکثرا انتقال‌هایی با تغییرات محل سایت را پوشش می‌دهد که در دسته‌های زیر قرار می‌گیرند:

  • جابه‌جایی سایت با تغییر آدرس (URL)
  • جابه‌جایی سایت بدون تغییر آدرس (URL)

 

انتقال‌های جابه‌جایی سایت

انتقال سایت

این زمانی رخ می‌دهد که سایت به خاطر هر یک از دلایل زیر به آدرسی متفاوت منتقل می‌شود:

تغییرات پروتکلی:

یک مثال کلاسیک زمان انتقال از HTTP به HTTPS است.

تغییرات زیردامنه‌ای و زیرپوشه‌ای:

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

 

تغییر نام دامنه:

به طور متداول زمانی رخ می‌دهد که یک کسب‌وکار به دنبال برندسازی مجدد بوده و باید از یک دامنه به دامنه دیگری منتقل شود.

 

تغییر دامنه سطح بالا:

این زمانی متداول است که یک کسب‌وکار تصمیم به راه‌اندازی وبسایت‌های بین‌المللی گرفته و باید از یک دامنه سطح بالای کد کشوری به یک دامنه سطح بالای عمومی منتقل شود یا بالعکس، مثلا از .co.uk به .com منتقل شود یا از .com به .co.uk منتقل شود.

 

تغییرات ساختار سایت:

این تغییرات در معماری سایت بوده و معمولا بر لینک دهی داخلی سایت و ساختار آدرس سایت تاثیر دارند.

 

دسته‌های دیگر انتقال سایت :

دسته‌های دیگر انتقال از تغییراتی در محتوا، ساختار، طراحی یا پلت‌فرم سایت نشأت می‌گیرند.

 

پلت‌فرم سازی مجدد:

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

 

انتقال‌های محتوا:

تغییرات اساسی محتوا مانند بازنویسی محتوا، تثبیت محتوا یا هرس کردن محتوا می‌تواند بر مشاهده جست‌وجوی واقعی یک سایت تاثیر بزرگی داشته باشد که به مقیاس کار بستگی دارد. این تغییرات معمولا می‌توانند بر مسیریابی، دسته‌بندی و لینک دهی داخلی سایت تاثیر داشته باشند.

 

تغییرات تنظیمات موبایلی:

با توجه به گزینه‌های بسیاری که در خصوص جابه‌جایی تنظیمات موبایلی سایت وجود دارد، فعال‌سازی فهرست‌سازی برنامه، ساخت یک سایت AMP یا ساخت یک وبسایت PWA نیز می‌تواند به عنوان یک انتقال مقطعی سایت در نظر گرفته شود. به خصوص زمانی که سایت موبایلی موجود با یک برنامه، AMP یا PWA جایگزین می‌شود.

 

تغییرات ساختاری:

این موارد معمولا با تغییرات اساسی در دسته‌بندی سایت رخ می‌دهند که بر مسیریابی، لینک دهی داخلی و نقشه مسیر کاربر تاثیر می‌گذارند.

 

طراحی مجدد سایت:

این دسته، از تغییرات طراحی اساسی در ظاهر گرفته تا یک اصلاح کامل وبسایت را شامل می‌شود که همچنین ممکن است شامل تغییرات معناداری در کپی، کد و رسانه بشود.

 

انتقال‌های ترکیبی:

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

 

 

اشتباهات متداول در انتقال سایت ها

با وجود این که هر انتقالی متفاوت از دیگری است، پشت رایج‌ترین فجایع انتقال در سایت‌ها، موارد مشترکی وجود دارند. بزرگ‌ترین موارد قابل ذکر در ادامه آمده‌اند:

دلایل شکست انتقال در سایت‌ها

استراتژی ضعیف (مانند اهداف ناواضح)- برنامه‌ریزی ضعیف- کمبود هم‌فکری در سئو یا تجربه کاربری- کمبود منابع یا بودجه- مشارکت دیرهنگام- آزمون ضعیف- واکنش کند به رفع باگ- دست کم گرفتن مقیاس

انتقال سایت

استراتژی ضعیف

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

برنامه‌ریزی ضعیف

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

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

کمبود منابع

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

کمبود هم‌فکری برای سئو یا تجربه کاربری

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

مشارکت دیرهنگام

انتقال سایت ها ممکن است ماه‌ها به طول بینجامد و به برنامه‌ریزی عالی و زمان کافی برای آزمودن نیاز دارد.

جست‌وجوی دیرهنگام به دنبال پشتیبانی حرفه‌ای بسیار ریسکی است چرا که ممکن است گام‌های کلیدی فراموش شده باشند.

کمبود آزمون

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

واکنش کند به رفع باگ

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

دست‌ کم گرفتن مقیاس

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

فرآیند انتقال سایت

فرآیند انتقال سایت را می‌توان به شش گام ضروری تقسیم کرد.

تمام آن‌ها به مقدار برابری مهم بوده و از قلم انداختن آن‌ها به درجات مختلفی مانع از موفقیت انتقال می‌شود.

انتقال سایت

فرآیند انتقال سایت

مرحله ۱- ارزیابی و برنامه‌ریزی: اهداف، ریسک‌ها، موقعیت‌های رشد و پیش‌بینی سناریوها، راهبردها، برنامه پروژه

مرحله ۲- آماده‌سازی پیش از راه‌اندازی: مرور چارچوب، مشخص‌سازی فنی سئو، شناسایی صفحات در اولویت، برنامه وقایع احتمالی آینده

مرحله ۳- آزمون پیش از راه‌اندازی: مرور محتوا، مرور فنی، آزمون تغییر مسیر، ارزیابی ریسک راه‌اندازی سایت، ارزیابی استانداردها (بنچمارک)

مرحله ۴- پشتیبانی روز راه‌اندازی: عملیات‌های راه‌اندازی سایت، آزمون زنده سایت، پشتیبانی رسانه که هزینه آن پرداخت شده باشد

مرحله ۵- مرور پس از راه‌اندازی: ارزیابی‌ها و عملیات پس از راه‌اندازی، مرور رفع باگ‌ها، نظارت بر عملکرد

مرحله ۶- مرور عملکرد: اولویت‌سازی فعالیت‌های معمول کسب‌وکاری

مرحله اول: ارزیابی و برنامه‌ریزی

ارزیابی پروژه

فارغ از دلایل پشت یک پروژه انتقال، شما باید از ابتدا نسبت به اهداف مشخص باشید چرا که این امر به تنظیم و مدیریت انتظارات کمک می‌کند. جابه‌جایی از HTTP به HTTPS بسیار متفاوت از یک اصلاح کامل سایت است، بنابراین هر یک باید اهداف متفاوتی داشته باشند.در مثال اول، هدف باید بازیابی سطوح ترافیک سایت باشد، در حالی‌که در مثال دوم هدف باید احتمالا رشد باشد.

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

سهام‌داران

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

آماده‌سازی برنامه پروژه

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

نیازی به گفتن نیست برای سامان‌دهی و انجام فعالیت‌های لازم با توجه به برنامه، به مدیریت پروژه‌ای بی‌نقص لازم است.

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

مرحله دوم: آماده‌سازی پیش از راه‌اندازی

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

مرور چارچوب

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

آماده‌سازی مشخصات فنی سئو

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

اطمینان حاصل کنید که ملزومات خاصی شامل حوزه‌های زیر لحاظ شده‌اند:

  • ساختار آدرس سایت
  • فراداده (شامل ارزش‌های پیش‌فرضی که به طور پویا ایجاد شده‌اند)
  • داده‌های ساخت‌یافته
  • کنونیکال‌ها و دستورالعمل‌های فراروبات‌ها
  • کپی و تیترها
  • مسیریابی‌های اصلی و ثانویه
  • لینک‌دهی داخلی (به هر نحوی)
  • صفحه‌بندی
  • نقشه سایت (های) XML
  • نقشه سایت HTML
  • Hreflang(اگر سایت‌های بین‌المللی وجود دارند)
  • تنظیمات موبایل (شامل برنامه، سایت AMP یا PWA)
  • تغییر مسیرها
  • صفحه معمول ۴۰۴
  • جاوا اسکریپت، CSS و فایل‌های عکسی
  • زمان‌های بارگذاری صفحه (برای دسکتاپ و موبایل)

این مشخصات همچنین باید شامل حوزه‌هایی از کارکرد CMS باشند که به کاربر امکان این موارد را می‌دهد:

  • تشخیص آدرس‌های معمول و نادیده گرفتن آدرس‌های پیش‌فرض
  • به‌روز رسانی عناوین صفحات
  • به‌روز رسانی متا توضیحات
  • به‌روز رسانی هر یک از تیترهای h1 تا h6
  • اضافه کردن یا اصلاح تگ‌های کنونیکال
  • تنظیم ویژگی‌های متا روبات‌ها به index/noindex/follow/nofollow
  • اضافه کردن یا اصلاح متن جایگزین عنوان تصویر هر عکس
  • لحاظ کردن میدان‌های اوپن گراف برای توضیحات، آدرس، عکس، تایپ و اسم سایت
  • لحاظ کردن میدان‌های اوپن گراف توییتر برای کارت، آدرس، عنوان، توضیحات و عکس
  • به‌روز رسانی Bulk یا اصلاح تغییر مسیرها
  • به‌روز رسانی فایل txt

همچنین اطمینان حاصل کردن از این که هنگام به‌روز رسانی یک ویژگی خاص (مانند یک h1)، عناصر دیگر (مانند عنوان صفحه یا هر فهرستی از مسیریابی) تحت تاثیر قرار نمی‌گیرند، مهم است.

 

شناسایی صفحات در اولویت

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

برای این کار، شما باید:

  1. باید در سایت قدیمی عمل crawl را انجام دهید.
  2. تمام صفحات قابل فهرست‌بندی شدن را شناسایی کنید.
  3. صفحات با عملکرد بالا را شناسایی کنید.

نحوه crawl در سایت قدیمی

با عمل crawl شما یک کپی از تمام آدرس‌ها، عناوین صفحات، فرداده‌ها، تیترها، تغییر مسیرها، لینک‌های خراب و … خواهید داشت. فارغ از برنامه انتخابی جهت crawl (ضمیمه را ببینید) اطمینان حاصل کنید که crawl زیاد سفت و سخت نباشد. پیش از crawl در سایت قدیمی، خوب به تنظیمات برنامه مورد نظر توجه کنید و موارد زیر را در نظر بگیرید:

  • txt را نادیده بگیرید (در صورتی که هر یک از بخش‌های حیاتی بلاک شده‌اند)
  • لینک‌های داخلی «nofollow» را دنبال کنید (تا crawler به صفحات بیشتری دسترسی پیدا کند)
  • تمام زیردامنه‌ها را (با توجه به ارزیابی) crawl کنید
  • خارج از پوشه استارت، crawl کنید (با توجه به ارزیابی)
  • عامل کاربری را به Googlebot تغییر دهید (دسکتاپ)
  • عامل کاربری را به Googlebot تغییر دهید (تلفن هوشمند)

راهنمای حرفه‌ای: تا چند ماه پس از تکمیل انتقال از داده crawl سایت قدیمی یک کپی داشته باشید (روی ابر یا در یک فایل) تا وقتی سایت جدید روی کار آمد، در صورت نیاز داده‌های سایت قبلی را در اختیار داشته باشید.

نحوه شناسایی صفحات فهرست‌پذیر (indexable)

وقتی عمل crawl به پایان رسید، روی شناسایی صفحات فهرست شده سایت قدیمی کار کنید. این موارد شامل تمام صفحات HTML با ویژگی‌های زیر می‌شوند:

  • سرور پاسخ مثبت بدهد
  • یا تگ کنونیکال نداشته باشد یا یک آدرس کنونیکال خود ارجاع داشته باشد
  • Noindex متا روبات نداشته باشد
  • از فایل txt خارج نشده باشند
  • لینک‌های صفحات داخلی به آن‌ها منجر نشده باشد

صفحات فهرست‌پذیر تنها صفحاتی هستند که ممکن است بتوانند ترافیک را به سمت سایت هدایت کنند. از این رو باید در جهت هدف انتقال سایت شما اولویت‌بندی شوند. این‌ها صفحاتی هستند که ارزش بهینه‌سازی (اگر قرار است در سایت جدید حضور داشته باشند) یا تغییر مسیر (اگر قرار است در سایت جدید حضور نداشته باشند) را دارند.

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

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

پیشنهاد می‌شود که یک صفحه گسترده آماده کنید که شامل موارد زیر می‌شود:

  • آدرس سایت قدیمی (تنها موارد فهرست‌پذیر را از داده‌های crawl لحاظ کنید)
  • آمار مشاهده از جست‌وجوی واقعی طی ۱۲ ماه اخیر (گوگل Analytics)
  • درآمد، نرخ‌های تبدیل و تبدیل‌ها طی ۱۲ ماه اخیر (گوگل Analytics)
  • آمار مشاهده صفحات طی ۱۲ ماه اخیر (گوگل Analytics)
  • تعداد کلیک‌ها در ۹۰ روز اخیر (Search Console)
  • صفحات برتر از لحاظ لینک شدن (Majestic SEO/Ahrefs)

با داشتن هم‌زمان اطلاعات بالا، حال شناسایی مهم‌ترین صفحاتتان بسیار ساده‌تر است: صفحاتی که مشاهده‌های واقعی را رقم می‌زنند، نرخ تبدیل خوبی دارند، در درآمد تاثیر دارند، تعداد قابل توجهی از دامنه‌ها به آن‌ها لینک شده‌اند و … . این‌ها صفحاتی هستند که برای یک انتقال موفق، باید روی آن‌ها تمرکز کنید.به طور ایده‌آل، صفحات با عملکرد بالا باید در سایت جدید نیز وجود داشته باشند. اگر به هر دلیلی این طور نیست، باید به مربوط‌ترین صفحه تغییر مسیر داده شوند تا کاربری که درخواست آن‌ها را داده با صفحه ۴۰۴ مواجه نشود و ارزش لینکی که پیش از این وجود داشته، در سایت باقی بماند. اگر هر یک از این صفحات دیگر وجود نداشته باشند و تغییر مسیر به خوبی انجام نشود، ترافیک و رتبه سایت شما به طور منفی تحت تاثیر قرار می‌گیرد.

 

معیار سنجی (بنچمارک)

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

ردیابی رتبه کلیدواژه‌ها

اگر به طور مداوم رتبه سایت را دنبال نمی‌کنید، پیش از راه‌اندازی سایت جدید باید این کار را انجام دهید.

در غیر این‌صورت، برای این که در آینده بدانید که آیا انتقال سایت درست پیش رفته یا خیر، یا این که اشکال دقیقا از کجاست، به مشکل برخواهید خورد. این مورد را برای لحظه آخر نگذارید چرا که ممکن است موضوعی آمار را منحرف کند. یک هفته پیش از شروع، زمان ایده‌آلی خواهد بود.زمانی را صرف این که کنید که بدانید کدام کلیدواژه‌ها بیشتر از بقیه نماینده آمار مشاهده جست‌وجوی واقعی سایت است و آن‌ها را در موبایل و دسکتاپ ردیابی کنید. از آن‌جا که مشاهده هزاران ترکیب از کلیدواژه اصلی، طولانی و متوسط غیرواقع‌بینانه است، حداقل کلیدواژه‌های کافی که باید بر آن‌ها نظارت کنید آن‌هایی هستند که باعث ایجاد ترافیک در سایت می‌شوند (رتبه کلیدواژه‌ها در صفحه اول) و حجم جست‌وجوی خوبی دارند (تمرکز بر کلمات اصلی یا با اندازه متوسط).

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

عملکرد سایت

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

داده crawl سایت قدیمی

چند روز پیش از آن که سایت جدید جای سایت قدیمی را بگیرد، یک crawl نهایی از سایت قدیمی بگیرید. اگر در سایت جدید مشکلات بهینه‌سازی وجود داشته باشد، ارزش این کار در آینده قابل قیمت‌گذاری نیست. Crawl نهایی به شما این امکان را می‌دهد که اطلاعاتی حیاتی در خصوص عناوین صفحه سایت قدیمی، توضیحات متا، تگ‌های h1-h6، وضعیت سرور، تگ‌های کنونیکال، صفحات noindex/nofollow، inlinks/outlinks، سطح و … ذخیره داشته باشید. اگر برای مثال سایت جدید به خوبی بهینه‌سازی نمی‌شود یا از مسائل فنی پیکربندی اشتباه رنج می‌برد، داشتن تمام این اطلاعات می‌تواند از مشکلات بسیاری جلوگیری کند. همچنین سعی کنید از robots.txt و نقشه سایت XML سایت قدیمی یک کپی داشته باشید چرا که ممکن است در آینده به آن‌ها احتیاج داشته باشید.

 

داده‌های Search Console

استخراج داده‌های Search Console سایت قدیمی را نیز تا جای ممکن در نظر داشته باشید. این‌ها تنها برای ۹۰ روز در دسترس خواهند بود و احتمالاتی وجود دارند که وقتی سایت جدید اجرا شود، داده Search Console سایت قدیمی دیر یا زود ناپدید شود. داده‌هایی که ارزش استخراج دارند شامل موارد زیر می‌شوند:

  • صفحات و جستارهای تحلیل جست‌وجوها
  • خطاهای crawl
  • منابع بلوکه شده
  • مسائل قابلیت استفاده از موبایل
  • پارامترهای آدرس سایت
  • خطاهای داده‌های ساخت‌یافته
  • لینک‌های منتج به سایت شما
  • لینک‌های داخلی
  • وضعیت فهرست (index)

آماده‌سازی تغییر مسیرها

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

چرا تغییر مسیرها در انتقال سایت ها مهم هستند؟

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

وقتی تغییر مسیرها به طور درست اجرا نشوند چه اتفاقی می‌افتد؟

وقتی تغییر مسیرها به طور صحیح اجرا نمی‌شوند، عواقب فاجعه‌بار خواهند بود. کاربران یا به صفحات «Not Found» (۴۰۴) برمی‌خورند، یا به صفحات نامربوطی می‌رسند که به هدف کاربر ربطی ندارند. در هر دو حالت نرخ‌های تبدیل و دفع کاربر سایت به طور منفی تحت تاثیر قرار می‌گیرند. عواقب هر یک می‌تواند به طور برابر برای موتورهای جست‌وجو فاجعه‌آمیز باشد: اگر آدرس‌های سایت‌ یکسان نباشند، موتورهای جست‌وجو نمی‌توانند صفحات سایت قدیمی را با سایت جدید ارتباط دهند. سیگنال‌های رتبه‌دهی از سایت قدیمی به سایت جدید منتقل نخواهند شد و در نتیجه با کاهش رتبه و کاهش مشاهده ناشی از جست‌وجوی واقعی مواجه خواهیم شد. به علاوه، کشف و فهرست‌بندی صفحات سایت جدید برای موتورهای جست‌وجو بیشتر زمان خواهد برد.

تغییر مسیرهای جاوا اسکریپت، ۳۰۱، ۳۰۲، یا متا رفرش؟

وقتی آدرس‌های بین نسخه‌های قدیمی و جدید سایت متفاوت هستند، از تغییر مسیرهای ۳۰۱ (دائمی) استفاده کنید. این به موتورهای جست‌وجو می‌گوید که آدرس‌های جدید را فهرست‌بندی کرده و همچنین سیگنال‌های رتبه‌بندی را از آدرس‌های قدیمی به جدید منتقل کنند. از این رو اگر سایت شما از یک دامنه یا زیردامنه دیگر منتقل می‌شود، اگر از HTTP به HTTPS می‌روید یا اگر سایت یا بخش‌هایی از آن ساختاردهی مجدد شده‌اند، باید از تغییر مسیرهای ۳۰۱ استفاده کنید. با وجود بعضی ادعاهای گوگل مبنی بر این که تغییر مسیرهای ۳۰۲ رتبه‌دهی صفحه را منتقل می‌کنند، فهرست‌بندی آدرس‌های جدید کندتر خواهد بود و انتقال سیگنال‌های رتبه‌بندی از صفحه سایت قدیمی به جدید بیشتر زمان خواهد برد.

تغییر مسیرهای ۳۰۲ (مقطعی) تنها زمانی باید مورد استفاده قرار گیرند که قرار نباشد تغییر مسیر به طور دائم حضور داشته و از این رو فهرست‌بندی آدرس جدید اولویت محسوب نمی‌شود. با تغییر مسیرهای ۳۰۲، موتورهای جست‌وجو در ابتدا نسبت به فهرست‌بندی محتوای آدرس مقصد تغییر مسیر خنثی خواهند بود و هر سیگنال تغییر مسیری را به آن انتقال می‌دهند. اما اگر تغییر مسیر مقطعی برای مدتی طولانی حذف یا به‌روز رسانی نشود، در نهایت به مانند تغییر مسیرهای دائمی (۳۰۱) عمل خواهند کرد. زمانی از ۳۰۲ استفاده کنید که احتمال حذف یا به‌روز رسانی آن در آینده نزدیک وجود داشته باشد. این موضوع برای هر تغییر مسیری اعم از کشور، زبان یا مخصوص یک دستگاه صادق است.

از تغییر مسیرهای متا رفرش و جاوا اسکریپت باید اجتناب شود. با وجود این که گوگل مدام با crawling در جاوا اسکریپت سازگارتر می‌شود، تضمینی برای کشف آن‌ها و انتقال سیگنال‌های رتبه‌دهی به صفحات جدید وجود ندارد.

اگر تمایل دارید تا با نحوه کار گوگل با دسته‌های مختلف تغییر مسیر بیشتر بدانید، به پست جان مولر مراجعه کنید.

 

فرآیند نقشه‌‌برداری تغییر مسیر

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

نقشه‌برداری تغییر مسیر صفحه‌گسترده‌ای است که شامل دو ستون می‌شود:

  • آدرس سایت قدیمی: آدرس یک صفحه در سایت قدیمی
  • آدرس سایت جدید: آدرس یک صفحه در سایت جدید

هنگام نقشه‌برداری(تغییر مسیر)یک صفحه از سایت قدیمی به جدید، تلاش کنید آن را به مرتبط‌ترین صفحه تغییر مسیر دهید.

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

افزایش کارایی طی فرآیند نقشه‌برداری تغییر مسیر

نقشه‌برداری تغییر مسیر به توجه بالایی به جزئیات نیاز دارد و باید توسط افراد با تجربه سئو کار انجام شود. نقشه‌برداری آدرس سایت‌های کوچک در تئوری ممکن است به صورت دستی با نقشه‌برداری هر یک از آدرس‌های سایت قدیمی به آدرس سایت جدید انجام شود. اما در سایت‌های بزرگ که شامل هزاران یا حتی صدها هزار صفحه هستند، نقشه‌برداری دستی تک تک آدرس‌ها عملا غیرممکن است و باید از اتوماسیون استفاده شود. تکیه بر ویژگی‌های مشترک مشخصی بین سایت قدیمی و جدید می‌تواند به شدت در حفظ زمان موثر باشد. این ویژگی‌ها می‌تواند شامل عناوین صفحات، تیترهای h1 یا هر شناسه خاص صفحه دیگری مانند کدهای محصولات، واحد نگهداری موجودی و … باشد. اطمینان حاصل کنید که برای نقشه‌برداری تغییر مسیرها روی ویژگی‌هایی تکیه کنید که خاص هستند و در چندین صفحه تکرار نشده‌اند. در غیر این صورت به نقشه‌برداری ناصحیحی خواهید رسید.

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

تغییر مسیرهای قدیمی را فراموش نکنید!

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

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

مثال:

آدرس a به آدرس b تغییر مسیر داده می‌شود (تغییر مسیر قدیمی)

آدرس b به آدرس c تغییر مسیر داده می‌شود (تغییر مسیر جدید)

که منجر به زنجیره زیر می‌شود:

URL A –> URL B –> URL C

برای حذف این، تغییر مسیر قدیمی فعلی را اصلاح کرده و یک تغییر مسیر جدید ایجاد کنید تا:

آدرس a به آدرس c تغییر مسیر داده شود (تغییر مسیر قدیمی اصلاحی)

آدرس b به آدرس c تغییر مسیر داده شود (تغییر مسیر جدید)

راهنمای حرفه‌ای: صفحه گسترده نقشه‌برداری تغییر مسیر خود را جهت حلقه‌های تغییر مسیر چک کنید. این مورد زمانی رخ می‌دهد که آدرس قدیمی با آدرس جدید یکسان باشند. حلقه‌های تغییر مسیر باید حذف شوند چرا که منجر به بی‌نهایت صفحات در انتظار بارگذاری خواهند شد که برای کاربران و موتورهای جست‌وجو غیرقابل دسترس هستند. حلقه‌های تغییر مسیر باید حذف شوند چرا که قاتل فوری ترافیک، نرخ تبدیل و رتبه‌بندی‌ها هستند.

برای جلوگیری از محتوای تکراری، از قوانین تغییر مسیر پوششی استفاده کنید

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

در هر موردی، قوانین تغییر مسیر استانداردی وجود دارند که جهت جلوگیری از ایجاد محتوای تکراری باید اجرا شوند:

  • در مورد آدرس سایت‌ها: تمام آدرس‌هایی که حروف بزرگ دارند باید با ۳۰۱ به آدرس‌هایی با حروف کوچک تغییر مسیر داده شوند. برای مثال https://www.website.com/Page/ باید به طور خودکار به https://www.website.com/page/ تغییر مسیر داده شود.
  • میزبان: برای مثال، تمام آدرس‌های بدون www باید به نام مشابه با www تغییر مسیر داده شوند. مانند تغییر مسیر https://website.com/page/ به https://www.website.com/page/.
  • پروتکل: در یک وبسایت امن، درخواست‌ها برای HTTP باید به وبسایت مشابه با HTTPS تغییر مسیر داده شوند. برای مثال http://www.website.com/page/باید به طور خودکار به https://www.website.com/page/ تغییر مسیر داده شود.
  • اسلش انتهایی: برای مثال هر آدرسی که اسلش انتهایی ندارد باید به نسخه‌ای با اسلش انتهایی تغییر مسیر داده شود. مثلا http://www.website.com/page باید به http://www.website.com/page/ تغییر مسیر داده شود.

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

از تغییر مسیرهای داخلی اجتناب کنید

سعی کنید لینک‌های داخلی سایت را به‌روز رسانی کنید تا موجب تغییر مسیرهای داخلی نشوند. با وجود این که موتورهای جست‌وجو می‌توانند تغییر مسیرهای داخلی را دنبال کنند، این مورد پیشنهاد نمی‌شود. چرا که سبب تاخیر در زمان بارگذاری سایت شده و همچنین تاثیری منفی بر زمان crawl موتور جست‌وجو خواهند داشت.

فایل‌های عکسی خود را فراموش نکنید

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

مرحله سوم: آزمون پیش از راه‌اندازی

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

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

مطمئن شوید موتورهای جست‌وجو به سایت آزمایشی یا سایتی که در حال آماده شدن است دسترسی پیدا نمی‌کنند

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

امکان دسترسی به سایت از IPهایی خاص (راه پیشنهادی)

فراهم کردن سایت برای یک سری IPهای خاص (لیست سفید) راه بسیار موثری برای جلوگیری از خزیدن موتورهای جست‌وجو به آن است. کسی که به دنبال دسترسی به آدرس سایت باشد، به محتوایی دست پیدا نخواهد کرد مگر آن که در لیست سفید قرار گرفته باشد. مزیت اصلی این است که لیست سفیدها می‌توانند بدون مشکلی به سایت crawl کرده و به راحتی به آن دسترسی داشته باشند. تنها عیب آن این است که ابزار ثالث وب محور (مانند ابزار گوگل) به خاطر محدودیت‌های IP قابل استفاده نیستند.

محافظت با رمز عبور

رمز گذاشتن برای سایت آزمایشی یا در حال آماده‌سازی یکی دیگر از راه‌های دور نگه داشتن موتورهای جست‌وجوست، اما این راه دو عیب اساسی دارد. بسته به اجرا، ممکن است در صورت عدم توانایی برنامه crawler در عبور از صفحه لاگین، امکان آزمایش و crawl در سایتی که با رمز از آن محافظت می‌شود وجود نداشته باشد. عیب دیگر این که برنامه‌های ثالث crawl در سایت‌های رمزداری که برای دسترسی از فرم استفاده می‌کنند ممکن است، اما ریسک وقوع مسائلی حاد و غیرقابل پیش‌بینی وجود دارد. زیرا crawler روی هر لینکی در صفحه کلیک می‌کند (وقتی لاگین کردید) و ممکن است به سادگی روی لینکی کلیک کند که صفحه‌ای ایجاد یا حذف کند یا افزونه‌هایی نصب یا پاک کند و … .

بلاک با Robots.txt

اضافه کردن خطوط کد زیر به فایل Robots.txt از crawl موتورهای جست‌وجو به صفحات سایت جلوگیری می‌کند:

 

از معایب این روش این است که هر چند محتوای ظاهر شده در سرور آزمایشی فهرست‌بندی نخواهد شد، اما آدرس غیر مجاز (disallow) شده ممکن است در نتایج جست‌وجوی گوگل ظاهر شود. یکی از معایب دیگر این است که اگر فایل robots.txt بالا به سایت جدید منتقل شود، مسائل ضدفهرست‌بندی جدی ایجاد خواهد کرد. این چیزی است که من بارها با آت برخورد کرده‌ام و برای همین استفاده از این روش را برای بلاک کرده موتورهای‌ جست‌وجو پیشنهاد نمی‌کنم.

مرور نقشه راه کاربر

اگر سایت ساختاردهی یا طراحی مجدد شده است، احتمال این که نقشه راه کاربر تا حدی تحت تاثیر قرار بگیرد وجود دارد. مرور هر چه سریع‌تر و مناسب نقشه راه کاربر پیش از راه‌اندازی سایت جدید به دلیل نبود داده کاربر سخت است. اما یک فرد حرفه‌ای در تجربه کاربر می‌تواند هر موردی که ممکن است تاثیری منفی بر نرخ تبدیل سایت داشته باشد را شناسایی کند. از آن‌جا که آزمون A/B در این مرحله تقریبا غیرممکن است، اجرای آزمون‌های کاربر و تلاش برای دریافت بازخورد از کاربران واقعی ارزشمند خواهد بود. متاسفانه حل مسائل تجربه کاربری کمی سخت‌تر خواهد بود چرا که ممکن است نیاز به تغییراتی در سراسر سایت داشته باشد که تلاش و زمان بسیاری خواهد برد.

وقتی یک اصلاح سایت کامل صورت می‌گیرد، تمام تصمیمات تجربه کاربر قابل پشتیبانی با داده نیست و بسیاری تصمیمات باید بر پایه بهترین روش، تجربه قبلی و شهود اتخاذ شوند. از این رو مشارکت دادن متخصصان سئو و بهینه‌سازی نرخ تبدیل (CRO) هر چه زودتر باشد، در آینده جواب خود را خواهد داد.

مرور معماری سایت

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

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

فرا داده و مرور کپی

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

مرور لینک‌دهی داخلی

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

  • مسیریابی اصلی و ثانویه
  • لینک‌های سرتیتر و پانوشت
  • لینک‌های بدنه محتوا
  • لینک‌های صفحه‌بندی
  • لینک‌های افقی (مقالات مربوط، محصولات مشابه و …)
  • لینک‌های عمودی (مسیریابی بردکرامب)
  • لینک‌های بین سایتی (مانند لینک‌های بین سایت‌های بین‌المللی)

بررسی‌های فنی

برای اطمینان از صحت تنظیمات فنی سایت جدید یک سری بررسی‌های فنی باید صورت بگیرد و تا همچنین از مواجه ناگهانی با مسائل فنی پس از اجرای سایت، اجتناب شود.

مرور فایل Robots.txt

در محیط آماده‌سازی فایل Robots.txt سایت جدید را آماده کنید. از این طریق می‌توانید هنگام اجرای سایت جدید، آن را جهت خطاها و اشکالات بررسی کرده و از تجربه مسائل crawl موتور جست‌وجو جلوگیری کنید. یک خطای متداول در انتقال سایت زمانی است که فایل robots.txt با استفاده از دستورالعمل زیر از دسترسی موتور جست‌وجو جلوگیری می‌کند:

Disallow: /

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

اما اگر فایل robots.txt طی آماده‌سازی با دستورالعمل‌های robots.txt سایت جدید پر شده باشد، از این اشتباهات جلوگیری می‌شود.

وقتی فایل robots.txt سایت جدید را آماده می‌کنید، مطمئن شوید:

  • دسترسی موتورهای جست‌وجو به صفحاتی را که قرار بوده فهرست‌بندی شوند، بلاک نکرده باشد.
  • هیچ یک از موتورهای جست‌وجو منابع CSS و جاوا اسکریپت را که برای رندر کردن محتوای صفحات لازم هستند، بلاک نکرده باشد.
  • محتوای فایل txt سایت قدیمی مرور شده و در صورت لزوم منتقل شده باشند.
  • به‌جای نقشه‌سایت‌های XML سایت قدیمی که دیگر وجود ندارند، به نقشه‌سایت‌های جدید ارجاع دهد.

مرور تگ‌های کنونیکال

تگ‌های کنونیکال سایت را مرور کنید. به دنبال صفحاتی باشید که یا تگ کنونیکال ندارند یا تگ کنونیکالی دارند که به سمت یک آدرس دیگر می‌رود و ببینید که آیا این موضوع عمدی بوده یا خیر. Crawl کردن در تگ‌‌های کنونیکال را فراموش نکنید تا ببنیید آیا واکنشی مثبت خواهند داشت یا خیر. اگر این چنین نیست، باید آن‌ها را به‌روز رسانی کنید تا واکنش‌های سرور ۳xx، ۴xx و ۵xx را از بین ببرند. همچنین باید به دنبال صفحاتی باشید که تگ کنونیکال در آن‌ها با ترکیب با دستورالعملی غیرفهرست‌بندی شده، به سمت یک آدرس دیگر هدف رفته‌اند. زیرا این‌ها سیگنال‌هایی متعارض بوده و باید یکی از آن‌ها را حدف کنید.

مرور متاروبات‌ها

وقتی در سایت‌ در حال آماده‌سازی crawl کردید، به دنبال صفحاتی با ویژگی متا روبات باشید تا به دستورالعمل‌های  «noindex» یا «nofollow» تنظیمشان کنید. اگر این موضوع صادق است، هر یک از آن‌ها را مرور کنید تا مطمئن شوید این موضوع از عمد بوده و اگر دستورالعمل‌های «noindex» یا «nofollow» حذف نبودند، آن‌ها را حذف کنید.

مرور نقشه‌سایت XML

دو نوع نقشه‌سایت متفاوت را آماده کنید. یکی که شامل تمام صفحات فهرست‌بندی شده سایت جدید می‌شود و یکی که شامل تمام صفحات فهرست‌بندی شده سایت قدیمی می‌شود. مورد اول به گوگل کمک می‌کند تا از آدرس‌های قابل فهرست‌بندی سایت جدید آگاه شود. مورد دوم نیز به گوگل کمک می‌کند تا از تغییر مسیرهایی که وجود دارند آگاه شده و متوجه این حقیقت شود که بعضی از آدرس‌های فهرست‌بندی شده به محل جدیدی رفته‌اند تا بتواند آن‌ها را شناسایی کرده و نتایج جست‌وجو را سریع‌تر به‌روز رسانی کند.

شما باید تمام نقشه‌سایت‌های XML را بررسی کنید تا مطمئن شوید:
  • بدون مشکلی معتبر است.
  • به عنوان یک UTF-8 کدگذاری شده است.
  • شامل بیش از ۵۰۰۰۰ ردیف نمی‌شود.
  • در حالت غیرفشرده از ۵۰ مگابایت بیشتر نمی‌شود.

اگر تعداد ردیف‌ها بیشتر از ۵۰۰۰۰ است یا اندازه فایل فراتر از ۵۰ مگابایت می‌شود، باید نقشه‌سایت را به اجزای کوچک‌تری تقسیم کنید. این در صورتی که گوگل به طور مداوم نقشه‌سایت را درخواست کند، از بارگذاری بیش از حد در سرور جلوگیری می‌کند.همچنین باید در هر نقشه‌سایت XML crawl کنید تا مطمئن شوید تنها شامل آدرس‌های قابل فهرست‌بندی است. هر آدرس غیرقابل فهرست‌بندی باید از نقشه‌سایت XML خارج شود. مانند:

  • صفحات ۳xx، ۴xx و ۵xx (برای مثال صفحات تغییر مسیر داده شده، صفحاتی که پیدا نمی‌شوند، درخواست ضعیف و …)
  • خطاهای ۴۰۴ نرم. این‌ها صفحاتی هستند که محتوایی ندارند و به جای ۴۰۴، واکنش سرور ۲۰۰ دارند.
  • صفحات کنونیکال شده (فارغ از آدرس‌های کنونیکال خود ارجاع).
  • صفحاتی با دستورالعمل‌های noindex متاروبات

 

  • صفحاتی با تگ Xروبات noindex، در سرتیتر HTTP

 

  • صفحاتی که از فایل txt بلاک شده‌اند.

ساخت نقشه‌سایت شفاف XML می‌تواند در نظارت بر سطوح صحیح فهرست‌بندی سایت جدید هنگامی که اجرا می‌شود کمک کند. اگر مسائل فهرست‌بندی را پیدا نکنید، این کار بسیار سخت خواهد شد.

راهنمای حرفه‌ای: هر یک از نقشه‌سایت‌های XML را دانلود و در اکسل باز کنید تا نمایی جزئی از هر یک از ویژگی‌های اضافه مانند hreflang یا ویژگی‌های عکسی داشته باشید.

 

انتقال سایت

مرور نقشه‌سایت HTML

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

برای مثال نقشه‌سایت HTML سایت NYTimes.com از سه سطح تشکیل شده است که هر یک شامل بیش از ۱۰۰۰ آدرس در هر نقشه‌سایت می‌شوند. این نقشه‌سایت‌های تو در توی HTML به crawlerهای موتور جست‌وجو کمک می‌کنند مقاله‌های منتشر شده از سال ۱۸۵۱ را پیدا کند. در غیر این صورت کشف و فهرست‌بندی آن‌ها سخت می‌شد. چرا که تمام آن‌ها به صورت داخلی لینک‌دهی نشده‌اند.

انتقال سایت
انتقال سایت

مرور داده‌های ساخت‌یافته

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

انتقال سایت

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

 

مرور crawl در جاوا اسکریپت

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

انتقال سایت

همان‌طور که تست‌های بارتوش گورالویچ نشان دادند، حتی اگر گوگل بتواند در محتوای ایجاد شده توسط جاوا اسکریپت crawl کرده و فهرست‌بندی کند، به این معنا نیست که می‌تواند در تمام چارچوب‌های اصلی جاوا اسکریپت در محتواهای جاوا اسکریپت crawl کند. جدول زیر یافته‌های بارتوش را نشان می‌دهد و نشان می‌دهد که بعضی از چارچوب‌های جاوا مناسب سئو نیستند و در حال حاضر چارچوب AngularJS بیش از بقیه مسئله‌ساز است.

انتقال سایت

بارتوش همچنین دریافت که دیگر موتورهای جست‌وجو (مانند بینگ، یاندکس و بایدو) واقعا با فهرست‌بندی محتوای ایجاد شده توسط جاوا اسکریپت مشکل دارند. اگر ترافیک سایت شما به هر یک از موتورهای ذکر شده بستگی دارد، دانستن این نکته مهم است.

انتقال سایت

به طور خوش‌بینانه این موضوعی است که طی زمان بهبود پیدا می‌کند. اما با افزایش محبوبیت چارچوب‌های جاوا اسکریپت در توسعه وب، این موضوع باید در اولویت شما باشد.در نهایت باید چک کنید که آیا هیچ منبع خارجی بلاک شده است یا خیر. متاسفانه این چیزی نیست که بتوانید به طور ۱۰۰ درصد کنترل کنید چون منابع بسیاری (مانند فایل‌های CSS و جاوا اسکریپت) وبسایت میزبان ثالثی دارند که ممکن است آن‌ها را توسط فایل‌های robots.txt خودشان بلاک کنند.تکرار می‌کنم که ابزارهای فچ و رندر می‌توانند چنین مسائلی را شناسایی کنند. مسائلی که اگر حل نشده باقی بمانند، تاثیر منفی معناداری در پی خواهند داشت.

انتقال سایت

مرور سئو سایت موبایل

مرور بلاک دارایی‌ها

در ابتدا مطمئن شوید که فایل robots.txt به طور تصادفی هیچ فایل عکسی، جاوا اسکریپت یا CSS را که برای رندر کردن محتوای سایت ضروری هستند، بلاک نکرده باشد. این می‌تواند بر نحوه رندر کردن موتورهای جست‌وجو و فهرست‌بندی محتوای صفحه سایت موبایلی تاثیری منفی داشته باشد. این می‌تواند در نهایت تاثیری منفی بر عملکرد و مشاهده از طریق جست‌وجوی موبایل داشته باشد.

انتقال سایت

مرور فهرست‌بندیِ اولویت با موبایل

برای اجتناب از هر مسئله‌ای در فهرست‌بندی گوگل که اولویت آن با موبایل است وبسایت موبایل را به طور کامل مرور کرده و مطمئن شوید در حوزه‌های زیر هیچ ناسازگاری بین سایت‌های موبایلی و دسکتاپ وجود نداشته باشد:

  • عناوین صفحات
  • توضیحات متا
  • تیترها
  • کپی
  • تگ‌های کنونیکال
  • ویژگی‌های متا روبات‌ها (یعنی noindex و nofollow )
  • لینک‌های داخلی
  • داده‌های ساخت‌یافته

یک وبسایت واکنش‌گر باید همان محتوا، لینک‌ها و نشانه‌گذاری‌های بین دستگاه‌ها را ارائه دهد و ویژگی‌های سئوی فوق باید در وبسایت‌های دسکتاپ و موبایلی یکسان باشند.

به علاوه، وابسته به تنظیمات سایت موبایلی، باید چند بررسی فنی اضافه‌تر نیز انجام دهید.

مرور سایت واکنش‌گرا

یک وبسایت واکنش‌گرا باید در تمام دستگاه‌ها کدهای HTML یکسانی ارائه دهد که بسته به اندازه صفحه (طی استفاده از CSS) تنظیم می‌شود.

انتقال سایت

گوگل‌بات قادر است تا زمانی که اجازه crawl در صفحه و دارایی‌های آن را دارد، این تنظیمات موبایلی را شناسایی کند. از این رو اطمینان از این که گوگل‌بات می‌تواند به تمام دارایی‌های ضروری مانند عکس‌ها، فایل‌های CSS و جاوا اسکریپت دسترسی داشته باشد بسیار مهم است.برای سیگنال دادن به یک مرورگر که یک وبسایت واکنش‌گر است، یک تگ متای =”viewport” باید همراه با <head> هر صفحه HTML، قرار بگیرد.

 

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

انتقال سایت

مرور آدرس‌های جداگانه موبایل

اگر وبسایت موبایل از آدرس‌های جدایی نسبت به دسکتاپ استفاده می‌کند، مطمئن شوید:

  1. هر صفحه دسکتاپ تگی دارد که به صفحه موبایلی مربوط اشاره دارد.
  2. هر صفحه موبایل یک تگ rel=”canonical” دارد که به آدرس دسکتاپ مربوط اشاره دارد.
  3. وقتی آدرس‌ دسکتاپ‌ها در دستگاه‌های موبایل درخواست می‌شوند، به آدرس موبایل مربوطه تغییر مسیر پیدا می‌کنند.
  4. تغییر مسیرها در تمام دستگاه‌های موبایلی اعم از اندروید، آیفون و ویندوزفون‌ها کار می‌کنند.
  5. هیچ لینک‌های بینی نامربوطی بین صفحات موبایلی و دسکتاپ وجود ندارد. این یعنی لینک‌های داخلی موجود در یک صفحه دسکتاپ باید تنها به صفحات دسکتاپ و لینک‌هایی که در صفحات موبایلی هستند باید به دیگر صفحات موبایلی لینک شوند
  6. آدرس‌های موبایل واکنش سرور ۲۰۰ داشته باشند.

انتقال سایت

مرور خدمات‌دهنده پویا

وبسایت‌های سروینگ پویا به هر دستگاه کد متفاوتی ارائه می‌دهند، اما روی همان آدرس.

انتقال سایت

در وبسایت‌های سروینگ پویا، بررسی کنید که آیا تیتر متفاوت HTTP به طور درست برپا شده یا خیر. این موضوع ضروری است چرا که وبسایت‌های سروینگ پویا HTML عوامل کاربر موبایل را تغییر می‌دهند و تیتر متفاوت HTTP به گوگل‌بات کمک می‌کند تا محتوای موبایلی را پیدا کند.

مرور متناسب بودن با موبایل

فارغ از تنظیمات موبایل (واکنش‌گر، آدرس‌های جداگانه و سروینگ پویا)، صفحات را با استفاده از عامل کاربری موبایل مرور کرده و مطمئن شوید:

  1. تگ viewport درست تنظیم شده باشد. استفاده از یک viewport عرضی ثابت بین دستگاه‌ها سبب مشکلات کاربری در موبایل می‌شود.
  2. سایز فونت زیاد کوچک نباشد.
  3. عناصر لمسی (مانند دکمه‌ها، لینک‌ها) زیاد نزدیک نباشند.
  4. روزنه‌های ناخوانده ایجاد نشوند. مانند تبلیغات، فرم‌های قبت‌نام ایمیل، تبلیغات دانلود برنامه و … . برای اجتناب از هر مشکلی، باید یا از یک HTML کوچک یا از بنرهای تصویری استفاده کنید.
  5. بارگذاری صفحات موبایلی کند نباشد.

ابزار تست تناسب با موبایل گوگل می‌تواند در شناسایی اکثر مشکلات بالا مفید باشد.

انتقال سایتمرور سایت AMP

اگر وبسایت AMP وجود دارد و نسخه‌ دسکتاپی سایت در دسترس است، مطمئن شوید:

  • هر یک از صفحات غیر AMP (یعنی دسکتاپ و موبایل)، تگی دارد که به آدرس AMP مربوطه اشاره دارد.
  • هر صفحه AMP، یک تگ rel=”canonical” دارد که به صفحه مربوط دسکتاپ ارجاع می‌شود.
  • هر صفحه AMP که آدرس دسکتاپ مربوط ندارد، یک تگ کنونیکال خود ارجاع دارد.

همچنین باید مطمئن شوید که AMPها معتبر هستند. این می‌تواند با استفاده از ابزار تست AMP گوگل آزمایش شود.

 

خطاهای محتوای به‌هم ریخته

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

انتقال سایت

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

مرور دارایی‌های عکسی

گوگل کمتر از صفحات HTML در عکس‌ها crawl می‌کند. اگر عکس سایت را از یک محل به محلی دیگر منتقل می‌کنید (برای مثال از دامنه خود به CDN)، راه‌هایی برای کمک به گوگل جهت پیدا کردن سریع‌تر عکس وجود دارد. ساخت یک نقشه‌سایت XML عکسی کمک خواهد کرد، اما شما باید همچنین مطمئن شوید که گوگل‌بات می‌تواند هنگام crawl در سایت به عکس سایت دسترسی پیدا کند. بخش سخت فهرست‌بندی عکس این است که صفحه وبی که عکس در آن ظاهر می‌شود و خود فایل عکس باید فهرست‌بندی شوند.

مرور عملکرد سایت

در آخر چیزی که اهمیتش کمتر از بقیه نیست، اندازه‌گیری زمان بارگذاری صفحه سایت قدیمی و مقایسه آن با سایت جدید هنگام آماده‌سازی آن است. در این مرحله، بر جنبه‌های مستقل از شبکه عملکرد مانند استفاده از منابع خارجی (عکس‌ها، CSS و جاوا اسکریپت)، کد HTML و پیکربندی سرور سایت تمرکز کنید. در ادامه اطلاعات بیشتری در این خصوص آمده است.

مرور ردیابی تحلیل‌ها

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

تست تغییر مسیرها

تست تغییر مسیرها در انتقال سایت پیش از آن که سایت جدید اجرا شود ضروری است و می‌تواند از بروز مشکلات بسیاری در آینده جلوگیری کند. راه‌های بسیاری برای بررسی تغییر مسیرها در سرور در حال ساخت یا آزمایشی وجود دارند، اما حرف آخر این است که شما نباید پیش بدون آزمودن تغییر مسیرها، وبسایت جدید را راه‌اندازی کنید.

وقتی تغییر مسیرها در محیط آماده‌سازی یا تست جدید در دسترس قرار گرفتند، در تمام لیست تغییر مسیرها crawl کرده و به دنبال مشکلات زیر بگردید:

  • حلقه‌های تغییر مسیر (آدرسی که تا بی‌نهایت به خودش تغییر مسیر داده می‌شود)
  • تغییر مسیرهایی با واکنش‌های سرور ۴xx و ۵xx.
  • زنجیرهای تغییر مسیر (آدرسی که به یک آدرس دیگر تغییر مسیر می‌شود و سپس به آدرس سومی تغییر مسیر داده می‌شود و …)
  • آدرس‌های کنونیکالی که واکنش سرور ۴xx یا ۵xx دارند.
  • حلقه‌های کنونیکال (صفحه A کنونیکالی به سمت صفحه B دارد که آن نیز کنونیکالی به سمت A دارد)
  • زنجیره‌های کنونیکال (کنونیکالی که به یک صفحه دیگر اشاره دارد، آن صفحه کنونیکالی دارد که به یک صفحه دیگر اشاره دارد و …)
  • ناسازگاری‌های پروتکلی یا میزبانی (هاست) برای مثال آدرس‌ها هم به HTTP و هم به HTTPS تغییر مسیر داده می‌شوند یا هم به آدرس‌هایی با www و هم به آدرس‌هایی بدون www تغییر مسیر داده می‌شوند.
  • کاراکترهای فضا سفید پیشرو یا انتهایی. در اکسل از trim() استفاده کنید تا آن‌ها را حذف کنید.
  • کاراکترهای نامعتبر در آدرس‌ها.

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

مرحله چهارم: عملیات روز راه‌اندازی

وقتی سایت داون است…

در انتقال سایت وقتی سایت جدید جای سایت قدیمی را می‌گیرد، این احتمال وجود دارد که سایت در حال اجرا به طور موقت داون شود. زمان داون بودن سایت باید به حداقل رسانده شود. ، اما زمانی که این اتفاق رخ می‌دهد، سرور باید به هر درخواست آدرسی واکنش سرور ۵۰۳ را داشته باشد (در دسترس نبودن سرویس). این به crawlerهای موتورهای جست‌وجو خواهد گفت که سایت جهت نگهداری به طور موقت داون شده تا آن‌ها بعدا برای crawl در سایت بازگردند.

اگر سایت برای زمان زیادی داون شده و واکنش سرور ۵۰۳ را نشان نمی‌دهد و موتورهای جست‌وجو در سایت crawl می‌کنند، آمار مشاهده جست‌وجوی واقعی سایت تحت تاثیر منفی قرار گرفته و وقتی سایت برمی‌گردد ریکاوری فوری صورت نخواهد گرفت. همچنین زمانی که سایت به طور موقت داون شده، باید یک صفحه آگاهی‌رسانی نمایش دهد که به کاربران نشان دهد سایت جهت تعمیرات به طور موقت داون شده است.

بررسی‌های نقاط فنی

تا سایت جدید اجرا می‌شود، نگاه سریعی به موارد زیر داشته باشید:

  • فایل txt تا مطمئن شوید موتورهای جست‌وجو جهت crawl کردن بلاک نشده باشند.
  • تغییر مسیرهای صفحات برتر (برای مثال آیا درخواست‌ها برای صفحات برتر سایت قدیمی تغییر مسیر درستی دارند؟)
  • تگ‌های کنونیکال صفحات برتر
  • واکنش‌های سرور صفحات برتر
  • دستورالعمل‌های Noindex/nofollow، اگر سهوا ایجاد شده‌اند

بررسی این نقاط فنی باید هم در سایت موبایلی و هم سایت دسکتاپ انجام شود. مگر این که سایت به طور کامل واکنش‌گر باشد.

 

عمل‌های Search Console

فعالیت‌های زیر به محض آن که سایت جدید اجرا می‌شود باید انجام شوند:

  1. تست و آپلود نقشه‌سایت XML
  2. تعیین محل مورد ترجیح برای دامنه (www یا بدون www)
  3. تعیین هدف بین‌المللی (اگر قابل اجراست)
  4. پیکربندی پارامترهای آدرس برای از بین بردن هر مشکل محتوای تکراری
  5. آپلود کردن فایل Disavow (اگر قابل اجراست)
  6. استفاده از ابزار تغییر آدرس (در صورت تغییر دامنه‌ها)

راهنمای حرفه‌ای: برای هر نوع صفحه متفاوت، از «فچ به عنوان گوگل» استفاده کنید (برای مثال برای صفحه اصلی، یک دسته، یک زیردسته، یک صفحه محصول) تا مطمئن شوید گوگل‌بات می‌تواند بدون مشکل صفحات را رندر کند. گزارشی از هر منبع بلاک شده را مرور کنید و فراموش نکنید که فچ و رندر را برای دسکتاپ و موبایل استفاده کنید. به خصوص اگر سایت موبایل واکنش‌گرا نیست.

انتقال سایت

مرحله پنجم: مرور پس از راه‌اندازی

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

مضاف بر وظایف تستی که در مرحله سوم ذکر شدند، در حوزه‌هایی موارد باید کامل‌تر، دقیق‌تر و جزئی‌تر بررسی شوند.

حال می‌توانید به طور کامل از مزایای Search Console بهره ببرید.

آمار crawl و لاگ‌های سرور را چک کنید

نگاهی به آمار crawl در search console داشته باشید تا مطمئن شوید گوگل صفحات سایت جدید را crawl می‌کند. به طور کلی وقتی گوگل‌بات به صفحات جدید می‌آید، تمایل پیدا می‌کند تا میانگین صفحاتی را که روزانه crawl می‌کند افزایش دهد. اما اگر نتوانید در روز راه‌اندازی شیب رو به بالایی را ببنیید، احتمالا چیزی بر قابلیت گوگل‌بات جهت crawl در سایت تاثیر منفی گذاشته است.

انتقال سایت

مرور لاگ‌های سرور با اختلاف موثرترین راه برای کشف هر مسئله crawl یا هر ناسازگاری است. ابزاری مانند Botify و On Crawl می‌توانند به شدت مفید باشند زیرا آن‌ها crawlها را با داده‌های لاگ سرور ترکیب می‌کنند و می‌توانند صفحاتی را که موتورهای جست‌وجو crawl نمی‌کنند، مشخص کنند. صفحاتی که لینک به داخل نشده‌اند (صفحات یتیم)، صفحاتی که ارزش پایینی دارند و به شدت لینک به داخل شده‌اند و بسیاری صفحات دیگر.

 

خطاهای crawl را هر چند وقت یک بار مرور کنید

به طور ایده‌آل طی هفته‌های ابتدایی روزانه نگاهی به خطاهای گزارش شده crawl داشته باشید. دانلود روزانه این خطاها، crawl در آدرس‌های گزارش شده و انجام عملیات لازم (یعنی اجرای تغییر مسیرهای ۳۰۱ بیشتر، درست کردن خطاهای نرم ۴۰۴) به ریکاوری سریع کمک می‌کند. احتمال این که نیاز باشد هر خطای ۴۰۴ که گزارش می‌شود را تغییر مسیر دهید به شدت کم است، اما برای مهم‌ترین‌ها باید این کار را انجام دهید.

انتقال سایت

راهنمای حرفه‌ای: در گوگل Analytics می‌توانید به سادگی متداول‌ترین آدرس‌های درخواست شده ۴۰۴ را پیدا کرده و در ابتدا آن‌ها را درست کنید.

انتقال سایت

دیگر ویژگی‌های مفید Search Console

دیگر ویژگی‌های Search Console مانند منابع بلاک شده، خطای داده‌های ساخت‌یافته، خطای استفاده موبایلی، بهبودهای HTML و هدف‌گیری‌های بین‌المللی (برای بررسی خطاهای گزارش شده hreflang) نیز ارزش چک شدن را دارند.

 

راهنمای حرفه‌ای: در صورتی که پارامترهای آدرس مسائل محتوای تکراری را ایجاد کرده‌اند نگاه نزدیکی به آن‌ها داشته باشید. اگر این مورد صحت دارد، اجرای چند عمل فوری چاره‌ساز را در نظر داشته باشید.

انتقال سایت

اندازه‌گیری سرعت سایت

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

در غیر این صورت ترافیک و نرخ تبدیل سایت شما خیلی جدی افت خواهند کرد.

ارزیابی سرعت با استفاده از ابزار گوگل

در این مرحله از انتقال سایت دو ابزار گوگل که می‌توانند در این مورد مفید باشند Lighthouse و Pagespeed Insights هستند.

ابزار Pagespeed Insights عملکرد صفحه را هم در موبایل و هم در دسکتاپ می‌سنجد و داده سرعت صفحه واقعی را بر اساس داده کاربری که گوگل از کروم جمع‌آوری کرده نشان می‌دهد. همچنین به کارگیری بهترین شیوه‌های متداول عملکردی را چک کرده و یک نمره بهینه‌سازی ارائه می‌کند. این ابزار شامل دسته‌های اصلی ذیل می‌شود:

  • نمره سرعت: صفحه را تحت عنوان سریع، متوسط یا کند طبق دو معیار دسته‌بندی می‌کند: اولین نگاشت معنادار (First Contentful Paint (FCP و DOM Content Loaded. اگر نمره هر دو معیار در یک سوم برتر قرار بگیرد، صفحه «سریع» به شمار می‌آید.
  • نمره بهینه‌سازی: یک صفحه را تحت عناوین خوب، متوسط یا ضعیف بر اساس فضای خالی عملکرد دسته‌بندی می‌کند.
  • توزیع بار صفحه: یک صفحه را با مقایسه بین تمام رویدادهای FCP و DCL در روبات تجربه کاربری کروم تحت عنوان سریع (یک سوم اول)، متوسط (یک سوم میانی) و کند (یک سوم انتهایی) دسته‌بندی می‌کند.
  • آمار صفحه: می‌تواند نشان دهنده که آیا در صورت اصلاحات توسعه‌دهنده در ظاهر و کارکرد صفحه، آیا صفحه سریع‌تر خواهد شد یا خیر.
  • پیشنهادهای بهینه‌سازی: لیستی از بهترین کارهایی که می‌توان در صفحه به کار گرفت.

انتقال سایت

استفاده از لایت‌هاوس

لایت‌هاوس گوگل در عملکرد موبایل، دسترسی و بازرسی وب برنامه‌های پیش‌رونده بسیار مفید است. معیارهای متفاوت بسیار و مفیدی فراهم می‌کند که می‌توانند برای سنجش عملکرد صفحه در دستگاه‌های موبایل مورد استفاده قرار بگیرند. عملکردهایی چون:

  • اولین نگاشت معنادار که زمان قابل مشاهده بودن محتوای اصلی صفحه را اندازه‌گیری می‌کند.
  • زمان تعامل لحظه‌ای است که در آن صفحه آماده ارتباط با کاربر است.
  • معیارهای فهرست‌بندی سریع نشان می‌دهد که یک صفحه به طور قابل آشکار چه‌قدر سریع بازدید جمع می‌کند.

هر دو ابزار پیشنهاداتی ارائه می‌دهند که به بهبود مسائل عملکردی گزارش شده از سایت کمک می‌کنند.

انتقال سایت

 

همچنین می‌توانید برای دریافت تخمینی حدودی از درصد کاربرانی که ممکن است از صفحات سایت موبایل به دلیل زمان بارگذاری کند صفحات از این ابزار استفاده کنید.

 

انتقال سایت

 

همین ابزار مقایسه‌ای صنعتی فراهم می‌کند تا بتوانید ایده‌ای از این داشته باشید که در صنعت خود چه‌قدر از سایت‌هایی با برترین عملکرد فاصله دارید.

 

انتقال سایت

اندازه‌گیری سرعت از کاربران واقعی

وقتی سایت اجرا شود، می‌توانید بر اساس کاربرانی که سایت شما را مشاهده می‌کنند شروع به ارزیابی سرعت سایت کنید. اگر گوگل Analytics را داشته باشید، می‌توانید به سادگی زمان میانگین بارگذاری سایت جدید را با سایت قدیمی مقایسه کنید.انتقال سایت

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

انتقال سایت

مرحله ششم: اندازه‌گیری عملکرد انتقال سایت

زمان اندازه‌گیری

آیا انتقال سایت موفق بوده است؟ این یک سوال میلیون دلاری است که هر کس کار انتقال سایت انجام داده می‌خواهد جواب آن را به محض آن که سایت جدید اجرا شد بداند. در واقعیت، هر چه بیشتر صبر کنید جواب واضح‌تر خواهد بود.چرا که آمار مشاهده در چند هفته یا حتی چند ماه اول ممکن است بسته به اندازه و قدرت سایت شما بسیار نوسانی باشد. برای سایت‌های کوچک، ۴ الی ۶ هفته زمانی کافی خواهد بود پیش از آن که آمار سایت جدید را با سایت قدیمی مقایسه کنید. در وبسایت‌های بزرگ‌تر، باید حداقل ۲ تا ۳ ماه پیش از مقایسه صبر کنید.

همچنین اگر سایت جدید به طور مشخصی با سایت قبلی فرق دارد، کاربران به زمان نیاز خواهند داشت تا به ظاهر جدید عادت کنند و با دسته‌بندی جدید، نقشه راه کاربر و … خو بگیرند. چنین تغییراتی معمولا در ابتدا تاثیراتی منفی و مشخص بر نرخ تبدیل سایت خواهند داشت که باید پس از چند هفته که کاربران بیشتر و بیشتر به سایت عادت می‌کنند، بهبود پیدا می‌کند. به هر حال، نتیجه‌گیری‌های داده محور در خصوص تجربه کاربری سایت جدید می‌تواند بسیار ریسکی باشد.اما این‌ها تنها چند قانون سرانگشتی هستند و باید با عوامل دیگر لحاظ شوند. برای مثال اگر چند روز یا چند هفته پس از راه‌اندازی سایت جدید تغییرات معنادار و بیشتری انجام شوند (برای مثال جهت بررسی مسائلی فنی)، ارزیابی انتقال باید عقب‌تر بیفتد.

نحوه اندازه‌گیری

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

پس در کنار آمار ترافیک جست‌وجوی واقعی و درآمد، همچنین به موارد زیر توجه کنید:

  • آماره مشاهده موبایل و دسکتاپ (از SearchMetrics، SEMrush و Sistrix)
  • رتبه‌های موبایل و دسکتاپ (از هر برنامه قابل اعتمادی در ردیابی رتبه‌بندی)
  • مشارکت کاربر (نرخ دفع کاربر، میانگین زمان حضور در هر صفحه)
  • بخش‌های هر نوع صفحه (یعنی آیا صفحات دسته‌ای وجود دارند که بخش‌هایی به اندازه قبل ایجاد کنند؟)
  • نرخ تبدیل هر نوع صفحه (یعنی آیا صفحات محصولی وجود دارند که مانند گذشته تبدیل داشته باشند؟)
  • نرخ تبدیل هر دستگاه (آیا از زمان راه‌اندازی سایت جدید نرخ‌های تبدیل موبایل یا دسکتاپ افزایش یا کاهش داشته است؟)

مرور موارد زیر نیر می‌تواند بسیار مفید باشد. به خصوص از دیدگاه حل مسائل فنی:

  • تعداد صفحات فهرست‌بندی شده (Search Console)
  • صفحات فهرست‌‌بندی شده در برابر ثبت شده در نقشه‌سایت XML (Search Console)
  • صفحاتی که حداقل یک بازدید دریافت کرده‌اند (analytics)
  • سرعت سایت (PageSpeed Insights, Lighthouse, Google Analytics)

 

انتقال سایت و راهنمای انتقال سایت: راهبرد سئو، فرایند و چک لیست
5 (100%) 10 امتیاز

نظرات کاربران