بازطراحی یا مهاجرت سایت، اگر تکلیف نشانی‌ها، محتوا و تغییر مسیرها روشن نباشد، می‌تواند ترافیک گوگل را از بین ببرد. این مقاله علت‌های رایج افت رتبه، نقشه‌ی انتقال و چک‌لیست انتشار و پایش را برای مدیران کسب‌وکار توضیح می‌دهد.بازطراحی سایت معمولا با حرف از ظاهر شروع می‌شود: قالب تازه، مسیر کاربری بهتر، صفحه‌هایی که روی موبایل درست کار می‌کنند. اما اگر سایت شما همین حالا از گوگل بازدید و مشتری می‌گیرد، بازطراحی فقط یک پروژه‌ی طراحی نیست؛ یک مهاجرت در نتایج جست‌وجو هم هست.
موضع ما در گرین‌لبز صریح است: اگر پیش از عوض کردن ظاهر، تکلیف نشانی‌ها، محتوا، تغییر مسیرها و نمایه‌سازی روشن نباشد، بازطراحی زیبا می‌تواند گران‌ترین راه از دست دادن ترافیکی باشد که ماه‌ها و سال‌ها برایش هزینه کرده‌اید. گوگل صفحه‌ها را با نشانی‌شان می‌شناسد، نه با حسی که از طراحی تازه می‌گیرید.
چرا بازطراحی رتبه را از دست می‌دهد
رتبه معمولا به‌خاطر «الگوریتم تازه» یا بدشانسی ناپدید نمی‌شود. در بیشتر پروژه‌ها چند خطای مشخص، همزمان رخ می‌دهند.
عوض شدن نشانی صفحه‌ها. گوگل اعتبار، لینک‌ها و تاریخچه‌ی هر صفحه را به URL آن گره زده است. وقتی ساختار نشانی‌ها عوض می‌شود و مسیر تازه‌ای جای مسیر قبلی را می‌گیرد، بدون اتصال درست میان این دو، صفحه‌ی تازه برای گوگل تقریبا یک صفحه‌ی جدید است. لینک‌های خارجی و پیوندهای داخلی به نشانی‌ای می‌رسند که دیگر وجود ندارد.
حذف یا تهی شدن محتوایی که کار می‌کرد. در هیجان قالب تازه، صفحه‌هایی که «قدیمی» به نظر می‌رسند حذف می‌شوند یا به چند پاراگراف تزئینی تقلیل پیدا می‌کنند. اگر همان صفحه‌ها منبع ورود از جست‌وجو بوده‌اند، شما کانال جذب را برداشته‌اید.
شکستن لینک‌های داخلی. لینک داخلی فقط برای راحتی کاربر نیست؛ یکی از راه‌های اصلی گوگل برای فهمیدن ساختار سایت و انتقال اعتبار میان صفحه‌هاست. منوی تازه و دکمه‌هایی که به صفحه‌ی اصلی یا به نشانی‌های مرده می‌روند، این شبکه را پاره می‌کنند.
از دست رفتن فراداده. عنوان، توضیح متا، تیترها و نشانه‌گذاری ساخت‌یافته اغلب در سیستم قبلی زندگی می‌کردند. انتقال شلخته آنها را جا می‌گذارد و صفحه‌ها در نتایج با عنوانی ضعیف یا تکراری ظاهر می‌شوند، حتی اگر متن اصلی حفظ شده باشد.
تغییر ساختار و رندر جاوااسکریپت. سایت تازه گاهی بخش زیادی از محتوا را سمت مرورگر و با جاوااسکریپت می‌سازد. اگر محتوای اصلی فقط بعد از اجرای اسکریپت دیده شود و خزش و رندر آزمایش نشده باشد، گوگل ممکن است نسخه‌ای تقریبا خالی از صفحه را ببیند. سلسله‌مراتب تیترها و ساختار HTML هم اگر یکباره عوض شود، درک موتور جست‌وجو از صفحه عوض می‌شود. این را پیش از انتشار با صفحه‌ی خام و ابزار بازرسی نشانی بسنجید.
افت سرعت. قالب سنگین‌تر و انبوه اسکریپت تازه ممکن است روی گوشی معمولی و اینترنت همراه کند باشد. سرعت هم بر تجربه‌ی کاربر اثر می‌گذارد و هم بر دیده شدن در جست‌وجو. این موضوع را در مقاله‌ی سرعت سایت و اثر آن بر تبدیل بررسی کرده‌ایم.
پیش از هر تغییری: فهرست نشانی‌ها و خزش وضع موجود
هیچ نقشه‌ی انتقالی بدون تصویر دقیق از سایت فعلی معنا ندارد. این فهرست را از چند منبع جمع کنید:
- نقشه‌ی سایت فعلی و نشانی‌های ارسال‌شده در سرچ کنسول
- صفحه‌هایی که در گزارش عملکرد سرچ کنسول نمایش و کلیک می‌گیرند
- مسیرهای پربازدید و صفحه‌هایی که در ابزار تحلیل به تبدیل می‌رسند
- خروجی سیستم مدیریت محتوا
- لاگ سرور برای نشانی‌هایی که هنوز مراجعه دارند، از جمله فایل‌ها
- لینک‌های داخلی و لینک‌هایی که از سایت‌های دیگر به شما می‌رسند
تصاویر، پرونده‌های PDF، صفحه‌های فرود و نسخه‌های با www یا بدون آن و http در کنار https را هم ببینید. گوگل در راهنمای انتقال سایت با تغییر نشانی تأکید می‌کند که فایل‌های جاسازی‌شده مثل تصویر و ویدیو هم باید در برنامه‌ی انتقال دیده شوند.
خزش کامل سایت فعلی خط پایه‌ای است که بعدا بدون آن نمی‌توانید بگویید چه چیزی خراب شده است. این خزش باید کد پاسخ، عنوان، نشانی متعارف، دستور robots و زنجیره‌ی تغییر مسیرهای موجود را ثبت کند. صفحه‌هایی که ترافیک یا تبدیل می‌آورند خط قرمز پروژه‌اند: نه بی‌نقشه حذف می‌شوند، نه بی‌نقشه تغییر نشانی می‌دهند، و نه محتوای‌شان باید قربانی ظاهر تازه شود.
نقشه‌ی تغییر مسیر دائمی
وقتی نشانی‌ها عوض می‌شوند، اتصال میان قدیم و جدید باید از جنس تغییر مسیر دائمی سمت سرور باشد. گوگل در مستندات تغییر مسیرها توضیح می‌دهد که کدهای 301 و 308 به خزش‌گر می‌گویند مقصد تازه، نسخه‌ی اصلی و پایدار صفحه است. تغییر مسیر موقت، مثل 302، چنین پیامی نمی‌دهد و ممکن است نشانی قدیمی همچنان در نتایج بماند.
هر نشانی مهم باید به مرتبط‌ترین صفحه‌ی تازه وصل شود، نه به صفحه‌ی اصلی. فرستادن انبوه نشانی‌های قدیمی به صفحه‌ی نخست هم کاربر را گیج می‌کند و هم ممکن است از نظر گوگل نوعی خطای نرم به حساب بیاید. تغییر مسیر را مستقیم به مقصد نهایی بفرستید و از زنجیره‌ی چندپله‌ای بپرهیزید. تغییر مسیر سمت سرور را به جاوااسکریپت یا ترفندهای سمت مرورگر ترجیح دهید؛ اگر رندر شکست بخورد گوگل ممکن است هرگز آن انتقال را نبیند.
این نقشه را تا مدت طولانی نگه دارید. در همان راهنمای انتقال سایت، گوگل می‌گوید تغییر مسیرها را تا جای ممکن، معمولا دست‌کم حدود یک سال، حفظ کنید تا سیگنال‌ها و لینک‌های خارجی فرصت انتقال پیدا کنند. نقشه باید پیش از روز انتشار آماده و آزمایش‌شده باشد، نه فهرستی که شب راه‌اندازی با عجله نوشته شود.
محتوایی که ترافیک می‌آورد را نگه دارید و بهترش کنید
بازطراحی فرصت بهبود است، نه مجوز بازنویسی از صفر. اگر پاسخ صفحه‌های پربازدید در قالب تازه کوتاه یا تزئینی شود، رتبه‌شان دلیل محکمی برای ماندن ندارد.
محتوای صفحه‌های پربازدید را حفظ کنید و در صورت نیاز غنی‌تر کنید. اگر چند صفحه در یک صفحه‌ی جامع‌تر ادغام می‌شوند، همه‌ی نشانی‌های قدیمی به همان صفحه بروند و محتوای مفید هیچ‌کدام دور ریخته نشود. اگر خدمت یا محصولی واقعا حذف شده، به جای تغییر مسیر گمراه‌کننده به صفحه‌ای نامرتبط، پاسخ درست مثل 404 یا 410 بدهید و فقط وقتی جایگزین نزدیکی وجود دارد، کاربر را آگاهانه به آن هدایت کنید.
تیم طراحی و تیم بازاریابی باید پیش از انتشار تکلیف هر صفحه‌ی پربازدید را مکتوب کنند: می‌ماند، بهبود می‌یابد، ادغام می‌شود یا حذف می‌شود.
فراداده و داده‌ی ساخت‌یافته
عنوان، توضیح متا، تیتر اصلی و داده‌ی ساخت‌یافته بخشی از هویت صفحه در نتایج جست‌وجو هستند و باید با نشانی تازه هم‌خوان باشند.
هر صفحه‌ی مهم باید عنوان و توضیح منحصربه‌فرد داشته باشد؛ قالب نباید همه را با یک الگوی تکراری پر کند. نشانی متعارف (canonical) باید به خود صفحه‌ی جدید اشاره کند، نه به نشانی قدیمی، نه به محیط آزمایشی و نه به نسخه‌ای دیگر از همان صفحه. اگر داده‌ی ساخت‌یافته دارید، مثل نشانه‌گذاری سازمان، مقاله یا محصول، نشانی‌های داخل آن را به نسخه‌ی تازه به‌روز کنید. داده‌ای که به نشانی مرده اشاره می‌کند، سیگنال متناقض می‌فرستد. این کار را به «بعد از استقرار، سئو درست می‌کند» حواله نکنید.
محیط آزمایشی: نشت به گوگل یا مسدود ماندن در تولید
دو خطای متقارن در بازطراحی‌ها زیاد تکرار می‌شود و هر دو پرهزینه‌اند.
اول، محیط آزمایشی بدون محافظت وارد نتایج جست‌وجو می‌شود. اگر نسخه‌ی ناتمام بدون noindex بالا بیاید، گوگل ممکن است محتوای ناقص یا تکراری را نمایه کند. گاهی نشانی متعارف صفحه‌های اصلی هم به محیط آزمایشی اشاره می‌کند.
دوم، و شاید مخرب‌تر: قفل‌های محیط آزمایشی بعد از انتشار روی سایت اصلی جا می‌مانند. فایل robots.txt که خزش را می‌بندد یا متای noindex که روی قالب مانده، می‌تواند سایت تازه را از چشم گوگل پنهان کند. گوگل در راهنمای انتقال سایت همین مورد را از خطاهای رایج می‌داند: فراموش کردن برداشتن noindex یا مسدودسازی robots.txt بعد از مهاجرت.
محیط آزمایشی باید یا با احراز هویت از خزش خارج شود، یا با noindex در سطح صفحه محافظت شود. بستن کامل در robots.txt گاهی مانع از آن می‌شود که گوگل دستور noindex را اصلا ببیند. پیش از انتشار، فهرست قاعده‌هایی که باید برداشته شوند آماده باشد. بعد از انتشار، با ابزار بازرسی نشانی چند صفحه‌ی کلیدی را از دید گوگل بررسی کنید: آیا خزیده و نمایه می‌شوند و نشانی متعارف‌شان چیست.
نقشه‌ی سایت و سرچ کنسول
سرچ کنسول در مهاجرت ابزار تماشا نیست؛ بخشی از خود کار است. هر دو نسخه‌ی قدیم و جدید، و همه‌ی شکل‌های دامنه مثل با www و بدون آن و http و https، باید در حسابی که متعلق به خود کسب‌وکار است تأیید شده باشند. اگر دسترسی مالکیت سرچ کنسول به نام پیمانکار یا کارمند سابق است، پیش از مهاجرت آن را اصلاح کنید؛ موضوعی که در مقاله‌ی دامنه و هاست به نام شما نیست؟ شرح داده‌ایم.
نقشه‌ی سایت تازه باید فقط نشانی‌های نهایی و معتبر را داشته باشد و بعد از روشن شدن تغییر مسیرها در سرچ کنسول ارسال شود. نقشه‌ی قدیمی را وقتی می‌توان کنار گذاشت که گوگل مسیر جدید را بشناسد.
اگر دامنه یا زیردامنه عوض می‌شود، بعد از پیاده‌سازی تغییر مسیرها از ابزار تغییر نشانی در سرچ کنسول استفاده کنید. این ابزار به گوگل اعلام می‌کند که سایت منتقل شده و به انتقال سیگنال‌ها کمک می‌کند. برای رفتن از http به https، جابه‌جایی میان www و بدون www روی همان دامنه، یا تغییر مسیر صفحه‌ها داخل همان دامنه از این ابزار استفاده نکنید؛ در این حالت‌ها تغییر مسیر و نشانی متعارف کافی است. اگر دامنه عوض می‌شود، همه‌ی شکل‌های تأییدشده‌ی دامنه‌ی قدیم را جداگانه در نظر بگیرید.
ابزار تحلیل را هم بیازمایید. اگر کد ردگیری در قالب تازه جا مانده باشد، ممکن است تصور کنید ترافیک افت کرده، در حالی که فقط اندازه‌گیری قطع شده است.
چک‌لیست روز راه‌اندازی
روز انتشار، روز کشف کار جاافتاده نیست. اگر موارد زیر آماده نباشند، انتشار را عقب بیندازید.
- نقشه‌ی تغییر مسیر دائمی برای نشانی‌های مهم پیاده و روی نمونه‌های واقعی آزمایش شده است.
- هیچ تغییر مسیر مهمی به صفحه‌ای نامرتبط یا به صفحه‌ی اصلی ختم نمی‌شود، مگر آنکه همان مقصد درست باشد.
- لینک‌های داخلی سایت تازه به نشانی‌های جدید اشاره می‌کنند، نه به مسیرهای قدیمی.
- عنوان، توضیح متا، نشانی متعارف و داده‌ی ساخت‌یافته روی صفحه‌های کلیدی بررسی شده‌اند.
- noindex، مسدودسازی robots.txt و قفل‌های محیط آزمایشی از سایت اصلی برداشته شده است.
- محیط آزمایشی دیگر از بیرون نمایه‌شدنی نیست.
- نقشه‌ی سایت جدید ارسال شده و دسترسی سرچ کنسول و ابزار تحلیل کار می‌کند.
- اگر دامنه عوض شده، ابزار تغییر نشانی پس از فعال شدن تغییر مسیرها ثبت شده است.
- گواهی امنیتی، نسخه‌ی https و هدایت درست میان شکل‌های دامنه برقرار است.
- سرعت صفحه‌های اصلی روی دستگاه و اینترنت نزدیک به کاربر واقعی سنجیده شده و افت شدید دیده نمی‌شود.
- کدهای پاسخ صفحه‌های حذف‌شده درست است و فرم‌ها، پرداخت و مسیرهای حیاتی کار می‌کنند.
- کسی در ساعات اول انتشار مسئول پایش خطاهاست و روش برگشت به نسخه‌ی پایدار مشخص است.
بعد از انتشار چه چیزهایی را باید پایش کنید
مهاجرت وقتی تمام می‌شود که گوگل تقریبا همه‌ی نشانی‌های قدیم و جدید را دست‌کم یک بار دیده باشد. این زمان ثابت نیست و به اندازه‌ی سایت و سرعت سرور بستگی دارد.
در سرچ کنسول، گزارش پوشش یا نمایه‌سازی را برای جهش خطاها، صفحات یافت‌نشده و موارد مسدودشده ببینید. وضعیت نقشه‌ی سایت تازه و گزارش عملکرد را از نظر نمایش، کلیک و نشانی‌هایی که در نتایج ظاهر می‌شوند دنبال کنید.
در سایت و تحلیل، خطاهای 404 و تغییر مسیرهای ناقص را از لاگ سرور و خزش دوباره استخراج کنید. ترافیک ارگانیک و تبدیل را با دوره‌ی مشابه پیش از انتشار مقایسه کنید. خزش گوگل‌بات را هم در لاگ ببینید؛ گوگل هشدار می‌دهد که بعد از مهاجرت، خزش سایت جدید موقتا سنگین‌تر می‌شود.
پایش را به چند روز اول محدود نکنید. هفته‌های بعد همان جایی است که خطاهای آرام، مثل یک گروه نشانی جاافتاده یا noindex باقی‌مانده روی قالب، خودشان را نشان می‌دهند. نگهداری بعد از تحویل اصلا برای همین روزهاست؛ در مقاله‌ی هزینه‌ی واقعی سایت بعد از تحویل نوشته‌ایم که انتشار، پایان کار نیست.
افت موقت طبیعی است یا مسئله‌ی واقعی؟
گوگل صریح می‌گوید در هر تغییر بزرگ، نوسان موقت رتبه طبیعی است، چون سیستم باید نشانی‌های تازه را دوباره بخزد و ارزیابی کند. برای سایت‌های متوسط، این جایگزینی تدریجی ممکن است چند هفته یا بیشتر طول بکشد و برای سایت‌های بزرگ‌تر بیشتر. این را در همان راهنمای انتقال سایت نوشته است. پس افت کوتاه و محدود، به‌تنهایی دلیل بازگشت عجولانه نیست.
اما هر افتی را نباید به حساب «طبیعی بودن» گذاشت. وقتی بخش بزرگی از نشانی‌های پربازدید پاسخ 404 می‌دهند یا به صفحه‌ای نامرتبط می‌رسند، وقتی سایت با noindex یا robots.txt بسته مانده، وقتی پوشش نمایه‌سازی در هر دو سمت فرو می‌ریزد، وقتی صفحه‌های تازه در ابزار بازرسی محتوای اصلی را نشان نمی‌دهند، یا وقتی تغییر مسیرها فقط به صفحه‌ی نخست می‌روند، یا وقتی رتبه و ترافیک صفحه‌های پول‌ساز چند هفته پایین می‌ماند و خطاهای خزش برطرف نشده‌اند، با دوره‌ی گذار سالم روبه‌رو نیستید.
در حالت اول، صبر همراه پایش کافی است. در حالت دوم باید همان روز عیب را پیدا و رفع کرد. این تفاوت را فقط با خط پایه‌ی پیش از انتشار و گزارش‌های بعد از آن می‌توان دید.
این کار در قرارداد مال چه کسی است
بیشتر خسارت‌های مهاجرت از اینجا شروع می‌شود که همه گمان می‌کنند کار «کار سئو» است و سئو گمان می‌کند کار «تیم فنی در روز انتشار» است. تا وقتی نام، تحویل و زمان در قرارداد نباشد، این کار صاحب ندارد.
در قرارداد بازطراحی یا مهاجرت باید دست‌کم این موارد صریح باشد: تهیه‌ی فهرست نشانی‌های فعلی و علامت‌زدن صفحه‌های دارای ترافیک و تبدیل، پیش از شروع طراحی نهایی؛ تهیه‌ی نقشه‌ی تغییر مسیر و مسئولیت پیاده‌سازی و آزمایش آن؛ حفظ یا بهبود محتوای صفحه‌های پربازدید و فرایند تأیید حذف یا ادغام؛ انتقال فراداده، داده‌ی ساخت‌یافته و نقشه‌ی سایت؛ مدیریت noindex و robots در محیط آزمایشی و روز انتشار؛ دسترسی مالکیت سرچ کنسول و ابزار تحلیل به نام کارفرما؛ چک‌لیست انتشار و دوره‌ی پایش مشخص بعد از راه‌اندازی؛ و تعهد به نگهداری تغییر مسیرها برای مدتی معین، نه فقط تا پایان هفته‌ی تحویل.
اگر این بندها در پیشنهاد نیست، قیمت پایین‌تر یعنی کار کمتر روی پرریسک‌ترین بخش پروژه. بازطراحی‌ای که فقط ظاهر را تحویل می‌دهد، پروژه‌ای ناتمام است.
چک‌لیست عملی برای مدیر کسب‌وکار
لازم نیست جزئیات سرور را خودتان پیاده کنید. اما پیش از تأیید انتشار باید بتوانید به این پرسش‌ها پاسخ روشن بگیرید.
- فهرست نشانی‌های فعلی از کجا تهیه شده و صفحه‌های پربازدید کدام‌اند؟
- برای هر نشانی مهم، مقصد تازه مشخص است و تغییر مسیر دائمی سمت سرور آزمایش شده است؟
- محتوا و فراداده‌ی صفحه‌هایی که از گوگل مشتری می‌آورند حفظ یا بهتر شده است؟
- محیط آزمایشی در گوگل نمایه نمی‌شود و قفل‌های آزمایشی از سایت اصلی برداشته شده‌اند؟
- نقشه‌ی سایت جدید ارسال شده و سرچ کنسول به نام خود کسب‌وکار در دسترس است؟
- اگر دامنه عوض می‌شود، ابزار تغییر نشانی چه زمانی ثبت می‌شود؟
- در هفته‌های بعد از انتشار، چه کسی خطاهای 404، پوشش نمایه‌سازی، رتبه و تحلیل را می‌بیند و گزارش می‌دهد؟
- اگر مشکلی جدی دیده شد، مسیر برگشت چیست و چه کسی اجازه‌ی تصمیم دارد؟
اگر پاسخ بیشتر اینها «بعدا درست می‌شود» است، هنوز برای انتشار آماده نیستید.
جمع‌بندی
بازطراحی موفق آن نیست که فقط در جلسه‌ی رونمایی زیبا به نظر برسد. بازطراحی موفق آن است که کاربر همان صفحه را در جای درست و با همان ارزش، حتی بهتر، پیدا کند و گوگل بتواند این جابه‌جایی را دنبال کند. این کار با فهرست، نقشه، آزمایش و مالکیت حل می‌شود.
اگر در آستانه‌ی بازطراحی یا تغییر دامنه هستید و می‌خواهید تکلیف نشانی‌ها، تغییر مسیرها و پایش بعد از راه‌اندازی روشن باشد، تیم گرین‌لبز می‌تواند این مسیر را در کنار طراحی و توسعه با شما جلو ببرد. خدمات گرین‌لبز را ببینید.
