مهاجرت سایت کلینیک: چطور جلوی افت رتبه را بگیریم
راهنمای مهاجرت سایت کلینیک برای جلوگیری از افت ارگانیک: فهرستبرداری و نگاشت پیش از انتشار، قواعد ریدایرکت، چکلیست روز انتشار و هشت هفته پایش.
نوشته Roozbeh Nazari · CEO
بیشتر سایتهای کلینیکی که با آنها کار میکنیم هر چند سال یک بار از نو ساخته میشوند: طراحی جدید، CMS جدید، گاهی دامنه جدید و در بیشتر موارد ساختار زبانی جدید. مشاهده ما این است که سهم قابل توجهی از این بازسازیها با افت ترافیک ارگانیک در هفتههای پس از انتشار تمام میشود؛ گاهی برمیگردد، گاهی نه. این مقاله کارهایی را که مهاجرت سایت کلینیک پیش از انتشار، در روز انتشار و در هفتههای بعد از آن لازم دارد، به همان ترتیبی که ما بهعنوان آژانس اجرا میکنیم شرح میدهد تا افت رتبه هیچوقت دائمی نشود.
اول یک چارچوب. مستندات انتقال سایت گوگل میگوید در مهاجرتی که URLها تغییر میکنند، برای یک سایت متوسط ممکن است چند هفته یا بیشتر طول بکشد تا URLهای جدید بهتدریج جای قدیمیها را بگیرند. پس مقداری نوسان در دوره گذار طبیعی است؛ آنچه قابل پیشگیری است، افتی است که به خاطر ریدایرکتهای اشتباه، صفحههای گمشده و سیگنالهای زبانی خراب دائمی میشود. برای کلینیکها این تمایز مهمتر هم هست، چون بیشتر صفحههای درمان بعد از مدت طولانی به رتبه رسیدهاند و پس گرفتن آنها گران است.
پیش از انتشار: فهرستبرداری و نگاشت
سرنوشت مهاجرت تا حد زیادی پیش از انتشار تعیین میشود. کار اول، فهرست کامل URLهای سایت فعلی است: صفحههای داخل sitemap، صفحههایی که در دوازده ماه گذشته در Search Console کلیک گرفتهاند، URLهایی که طبق فایل لاگ Googlebot بازدید کرده و URLهایی که لینک خارجی دارند. این چهار فهرست هیچوقت یکسان نیستند؛ صفحه کمپین قدیمیای که در sitemap نیست اما هنوز ترافیک دارد، یا PDFای که فقط از یک لینک خارجی پیدا میشود، اگر در فهرست نباشد در جدول ریدایرکت هم نخواهد بود.
کار دوم، تعیین مقصد برای هر URL قدیمی است. قاعده ساده است اما در عمل زیاد نقض میشود: مقصد باید از نظر محتوا نزدیکترین صفحه باشد، نه صفحه اصلی. ریدایرکت کردن یک صفحه درمان حذفشده به صفحه اصلی، در نگاه گوگل سیگنالی نزدیک به soft 404 است و برای کاربر صفحهای است که چیزی را که دنبالش آمده پیدا نمیکند. برای صفحههایی که واقعاً معادلی ندارند، یک 404 یا 410 صادقانه بهتر از 301 به مقصد اشتباه است.
کار سوم، ساختار چندزبانه است. در سایت کلینیکی که صفحههای ترکی، انگلیسی، عربی و فارسی دارد، هر نسخه زبانی قدیمی باید به نسخه جدید همان زبان ریدایرکت شود؛ رسیدن یک صفحه عربی به مقصد ترکی هم مسیر کاربر را خراب میکند هم خوشه hreflang را. پیش از انتشار در محیط staging بررسی کنید که تگهای hreflang سایت جدید متقابل باشند؛ مستندات گوگل صریحاً میگوید تگهایی که به هم اشاره نکنند نادیده گرفته میشوند. رایجترین خطاها را در مقاله خطاهای hreflang جمع کردهایم.
کار چهارم، خزیدن staging مثل سایت زنده است. پیش از انتشار، سایت جدید را از ابتدا تا انتها با یک خزنده بگردید و سه فهرست را مقایسه کنید: صفحههایی که در سایت قدیمی هستند و در سایت جدید معادلی ندارند، صفحههایی در سایت جدید که لینک داخلیشان هنوز به URL قدیمی میرود، و صفحههایی که عنوان یا توضیح متا خالی ماندهاند. لینکهای داخلی که به URL قدیمی اشاره میکنند، بعد از مهاجرت هر کلیک را از یک ریدایرکت عبور میدهند؛ گوگل این را تحمل میکند، اما اینکه لینکهای خود سایت مستقیم به مقصد جدید بروند هم برای خزش هم برای کاربر تمیزتر است.
قواعد ریدایرکت: یک پرش، دائمی، سمت سرور
مستندات ریدایرکت گوگل ترتیب اولویت را روشن میکند: ریدایرکت دائمی سمت سرور (301 یا 308) قابلاعتمادترین روش است؛ meta refresh و ریدایرکت با JavaScript فقط وقتی که سمت سرور ممکن نباشد. در سایتهای کلینیک هنوز به ریدایرکت JavaScript برمیخوریم؛ معمولاً چون سایت قدیمی با یک صفحهساز ساخته شده و کسی دسترسی به سرور ندارد. در این حالت درستتر این است که برنامه مهاجرت را طوری بچینید که انتقال به زیرساختی را که ریدایرکت سمت سرور در آن ممکن است هم شامل شود.
قاعده دوم، نساختن زنجیره است. اگر سایت قدیمی از مهاجرت قبلی ریدایرکتهایی به ارث برده، قواعد جدید باید جای آنها را بگیرند نه اینکه روی آنها انباشته شوند؛ زنجیرههای A به B و B به C هم بودجه خزش را میخورند هم در هر پرش خطر از دست رفتن سیگنال دارند. مستندات گوگل توصیه میکند زنجیره تا حد ممکن کوتاه بماند. قاعده سوم، برنداشتن ریدایرکتهاست: همان سند توصیه میکند ریدایرکتها دستکم یک سال حفظ شوند. حتی بعد از یک سال هم ریدایرکت URLهایی که لینک خارجی دارند باید بماند.
اگر دامنه عوض میشود، از ابزار تغییر آدرس در Search Console استفاده کنید؛ صفحه راهنمای این ابزار میگوید فقط برای انتقال دامنه یا زیردامنه است و برای تغییر مسیر داخل همان دامنه کار نمیکند. برای گذار از HTTP به HTTPS یا تغییر www هم از این ابزار استفاده نمیشود.
روز انتشار: چکلیست
- بررسی کنید که noindex و مسدودسازی robots.txt محیط staging به سایت زنده منتقل نشده باشد؛ این هنوز دردناکترین علت افتهای مهاجرت است.
- هر URL داخل sitemap قدیمی را واکشی کنید و کد پاسخ و مقصدش را ثبت کنید؛ اگر توزیع 200، 301 و 404 با انتظار نمیخواند، انتشار را برگردانید.
- sitemap جدید را ارسال کنید و sitemap قدیمی را مدتی در دسترس نگه دارید؛ گوگل URLهای قدیمی را از آنجا دوباره میخزد و ریدایرکتها را میبیند.
- در چهار زبان بهصورت دستی تست کنید که تگهای canonical به URLهای جدید اشاره میکنند، خوشههای hreflang کاملاند و تغییردهنده زبان به صفحه درست میرود.
- بررسی کنید که GA4 و تگمنیجر در سایت جدید کار میکنند و رویدادهای تبدیل فرم و WhatsApp ثبت میشوند؛ اگر اندازهگیری قطع باشد، افت را اصلاً نمیبینید.
پس از انتشار: چه چیزی را چقدر زیر نظر بگیرید
ما یک نظم پایش میچینیم که دو هفته اول روزانه و شش هفته بعد هفتگی است. سه چیز پایش میشود: تعداد «صفحه با ریدایرکت» و «پیدا نشد» در گزارش ایندکس صفحههای Search Console؛ کلیک و نمایش به تفکیک صفحه در گزارش عملکرد؛ و تعداد درخواستهای Googlebot به URLهای قدیمی در لاگ. اگر درخواست به URLهای قدیمی کم میشود و نمایش URLهای جدید زیاد، یعنی گذار پیش میرود. اگر نمایش افت میکند و برنمیگردد، تشخیص مشکل را باید به ترتیب مقاله مشکلات ایندکس پیش ببرید.
دو چیز هم زیاد با هم اشتباه گرفته میشوند. اول، تغییر محتوا همزمان با مهاجرت: اگر عنوانها، متنها و لینکهای داخلی در همان روز تغییر کنند، نمیتوانید تشخیص دهید افت از تغییر URL بوده یا از تغییر محتوا. اگر ممکن است اول URLها را منتقل کنید و بازبینی محتوا را به چند هفته بعد بگذارید. دوم، اثر تغییر طراحی بر عملکرد: اگر قالب جدید وزن تصویر و بار اسکریپت را بالا برده باشد، افت دادههای Core Web Vitals با چند هفته تأخیر ظاهر میشود و با اثر مهاجرت اشتباه گرفته میشود.
همه این کارها بخش استاندارد یک پروژه سئوی فنی است؛ در پروژههایی که مهاجرت را فقط آژانس طراحی پیش میبرد، بیشتر بندهای این فهرست جا میافتد، چون کار طراح چیزی است که دیده میشود، نه جدول ریدایرکت.
نتیجه
افت در مهاجرت سایت کلینیک اجتنابناپذیر نیست؛ تقریباً همه مواردی که دائمی شده، از خطاهای قابل پیشگیری مثل فهرست ناقص، ریدایرکت با مقصد اشتباه، hreflang خراب و noindexای که به سایت زنده رفته، آمده است. تمام کردن جدول نگاشت پیش از انتشار، اندازهگیری کدهای پاسخ در روز انتشار و پایش منظم هشتهفتهای پس از آن، راه شناختهشده موقت نگه داشتن نوسان گذار است.