سلام، من میثم سلیمی هستم؛ از اردیبهشت 97 کارم رو توی دنیای SEO شروع کردم و در حال حاضر در شرکت تخفیفان مشغول به کارم.
چند روز پیش بود که من درباره مایگریشن (site migration) تخفیفان پستی توی لیندکین منتشر کردم و بعد از اون تصمیم گرفتم یکم بیشتر راجع بهش صحبت کنم و این تجربه رو با دوستان به اشتراک بذارم به امید اینکه برای چند نفر مفید باشه، نتیجه این تصمیم شد این مقاله :)
دوتا نکته رو بگم، اول اینکه که من اسم این مقاله رو مقاله آموزشی نمیذارم و بهش میگم مقاله انتقال تجربه و قراره از تجربه خودم صحبت کنم؛ پس ممکنه همه ابعاد مایگریشن اینجا گفته نشه، از طرفی هم برای اینکه بعضی جاها بتونم منظورم رو بهتر برسونم احتمالا نکاتی که به صورت کلی باید برای مایگریشن در نظر بگیریم رو هم بگم.
نکته دوم اینکه سعی میکنم تا جایی که بشه ساده بنویسم و امیدوارم بتونم کمک کوچکی به دوستان بکنم که اگه توی مسیر کاری SEO نیاز به مایگریشن بود بتونن تجربه خوبی داشته باشن.
خب، به صورت کلی مایگریشن انواع مختلفی داره، تغییر سرور، تغییر ساختار سایت، ریدیزاین، تغییرات محتوایی و ...که توی این ویدیو میتونید درباره‌اش بیشتر بدونید.
توی مایگریشنی که برای تخفیفان انجام شد تغییر ساختار سایت، ریدیزاین و انتقال سرور وجود داشت اما موضوع خیلی مهمی که باعث این موارد شده بود "تغییر نوع همکاری تخفیفان با شرکای تجاری و نحوه ارائه سرویس به کاربران" بود که لازم بود ساختار سایت به میزان قابل توجهی تغییر پیدا کنه.
خب تخفیفان تا چند ماه پیش یه سایت deal base بود و تخفیف‌های مختلفی روی اون قرار می‌گرفت و مردم استفاده می‌کردن، توی این مایگریشن تخفیفان به یه مارکت‌پلیس تبدیل شد و ساختار سایت به vendor base تغییر پیدا کرد.به این صورت که پیشنهادها و تخفیف‌هایی که توی سایت قرار میگیره توسط مالکین اون کسب و کار تعریف میشه که قبلا اینطوری نبود.
این مایگریشن از زمان اولین ریلیز تا زمان تکمیل شدن حدود 4 ماه طول کشید اما تا جایی که من میدونم سمت بیزینس حدود 1 سال درگیر این تغییر و تحولات بودن.
بریم سر اصل مطلب؛
ما توی تیم SEO برای اینکه بتونیم وظایف خودمون رو به درستی انجام بدیم اومدیم یه road map برای خودمون ایجاد کردیم که شامل بخش های زیر بود :
این road map رو با سایر تیم ها به اشتراک گذاشتیم و بابت زمانبندی‌ها با هم صحبت کردیم و هماهنگ شدیم.
بریم که یکم جزئی‌تر شیم و این مراحل رو با هم مرور کنیم.
قبل از این که مایگریشن رو شروع کنیم باید اول صفحات و مشخصات کامل اونها رو استخراج و دسته‌بندی می‌کردیم. ما شروع کردیم به کراول تمام بخش های سایت و دسته بندی کردن اطلاعات.این کار رو بسته به شرایط و ابعاد سایت به روش‌های مختلف میتونید انجام بدید، screaming frog, python , google sheet.
برای سایت‌هایی که صفحات کمی دارن گوگل شیت گزینه خوبیه. میتونید توی این پست درباره اسکریپینگ با گوگل شیت بخونید.
برای سایت‌های بزرگ‌تر باید از python یا screaming frog استفاده کنید. توی این پست از لینکدینِ علیرضا اسمی‌خانی میتونید روش کراول سایت با python رو ببینید و برای screaming frog هم که آموزش‌های مقدماتی و پیشرفته زیادی وجود داره.این رو هم اگه می‌خواهید از پایه کار باهاش رو یاد بگیرید از طریق این لینک اقدام کنید.
ما بخش زیادی از این مرحله رو با screaming frog پیش بردیم.
حقیقتش اینه اگه سایتتون صفحات زیادی داشته باشه همین مرحله اول تایم نسبتا زیادی رو ازتون میگیره.برای اینکه مراحل بعدی رو به خوبی پیش ببرید نیاز دارید که این مرحله رو با دقت بالایی انجام بدید.ما توی این مرحله دیتای صفحات‌مون رو استخراج کردیم که شامل URL, page title, meta title, meta description, canonical, content و یه سری دیتای دیگه از کتگوری‌ها و صفحات deal میشد.
نکته: بعضی از ستون‌هایی که توی عکس زیر می‌بینید (مثلا parent - slug - category ids) توسط بچه‌های فنی پر شده بودند و اونها علاوه بر دیتای ما به یه سری دیتای دیگه برای پیشبرد کار نیاز داشتن.
در نتیجه یه همچین داکیومنتی آماده کردیم:
خب میشه گفت مهم‌ترین بخش مایگریشن یه سایت همین قسمته، اگه اشتباه بزرگی توی انتقال دیتا اتفاق بیوفته ممکنه کار به اخراج شما از اون سازمان کشیده بشه :)) باید یه نقشه خیلی کامل و تمیز داشته باشید از اتفاقی که قراره رقم بزنید.احتمالا برای بخش زیادی از اون چیزهایی که توی عکس بالا دیدید باید جایگزین مناسب داشته باشید.
چالش برانگیزترین جای کار برای ما ساخت صفحات وندور و انتقال صفحات deal به وندورهای مرتبطشون بود.فکر کنم نیازه که اینجارو یکم بیشتر توضیح بدم:
توی سایت تخفیفان چیزی حدود 100.000 صفحه deal وجود داشت. منظور از صفحه deal همون تخفیف هایی بود که ارائه میشد.مثلا یه صفحه برای "تخفیف صبحانه رستوران گردان برج میلاد ویژه آخر هفته" وجود داشت و یه صفحه هم برای "تخفیف صبحانه رستوران گردان برج میلاد ویژه وسط هفته" وجود داشت.
یا مثلا اگه یه خواننده در سال 5 بار کنسرت اجرا می‌کرد هربار توی تخفیفان براش یه صفحه deal ایجاد میشد.اما وقتی داشتیم به سمت vendor base شدن می‌رفتیم باید اینطوری میشد که فقط یک صفحه برای اون خواننده ایجاد بشه و هروقت هر کنسرتی داره توی همون صفحه پیشنهادش نمایش داده بشه.
اینارو گفتم که بگم گاهی اوقات دیده میشد که برای یک وندور بیشتر از 10 تا صفحه deal وجود داره و ما باید اول همه اون هارو پیدا می‌کردیم و براشون 1 صفحه وندور ایجاد می‌کردیم و بعد ریدایرکتشون می‌کردیم به صفحه وندور.
یه اتفاق خوبی که توی این مرحله افتاد و باعث شد یه جون به جون‌های من اضافه بشه این بود که از چند سال پیش صفحات vendor توی پنل ساخته شده بودن و مشخص بود که کدوم deal مربوط به کدوم vendor میشه.یعنی از چند سال پیش مشخص بود که تخفیفان قراره یه روزی vendor base بشه و بعضی بستر هاش از همون چند سال پیش کم کم ایجاد شده بود.
اما بیاید فرض کنیم که این اتفاق نیوفتاده بود، حالا بر چه اساسی باید صفحات وندور رو می‌ساختیم؟
چیزی که به ذهن من می‌رسه استفاده از ریجکس (Regex) توی گوگل شیتِ ؛ مثلا اگه ما 10 تا صفحه deal داشتیم که توی عنوانشون از کلمه رستوران گردان برج میلاد استفاده شده بود، میشد با استفاده از ریجکس پیداشون کرد و براشون یک صفحه وندور به اسم رستوران گردان برج میلاد ساخت.
خب، در نهایت ما اومدیم یه داکیومنت درست کردیم و توی اون مشخص کردیم که چه صفحاتی باید به چه صفحاتی ریدایرکت بشن.
نتیجه:
این وسط ما یه سری صفحات رو هم مشخص کردیم که باید حذف می‌شدن. بیشتر این‌ها صفحاتی بودن که مربوط به هیچ وندوری نمی‌شدن و بودنشون توی سایت هیچ منفعتی نداشت و ضرر هم داشت.
پس ما:
جالبه بدونید در نهایت حدود 35.000 صفحه رو از نتایج گوگل حذف کردیم و سعی کردیم crawl رو به سمت صفحات مهم تر ببریم.
خب مهم ترین قسمت از مرحله 2 رو گذروندیم، می‌رسیم به موارد دیگه.
طبیعتا ما توی این مرحله دیتاهای دیگه مثل تایتل، دیسکریپشن و ... رو هم جایگذاری کردیم.
ما دوست داشتیم حالا که داریم وارد یه دوره‌ی پر ریسک میشیم، یه سری تست‌ها رو هم روی سایت انجام بدیم.چون همزمان با مایگریشن ما یه سری تارگت دیگه هم داشتیم که باید بهشون می‌رسیدیم :))
(البته توی مایگریشنی که ساختار سایت تغییرات اساسی داره نمیشه از یه تست خاص برداشت دقیقی کرد)
صفحات وندور که قاعدتا باید تایتل و دیسکریپشن جدید براشون نوشته میشد چون کانسپت صفحه تغییر کرده بود و از deal شده بود vendor.یه کار اجتناب ناپذیر بود و باید انجام میشد.
پس ما اومدیم سراغ کتگوری ها و خواستیم روی تقریبا نصف کتگوری ها با تغییر تایتل و دیسکریپشن تست انجام بدیم و توی مرحله جایگذاری دیتا، تایتل و دیسکریپشن نصف کتگوری هارو هم تغییر دادیم.(تقریبا 2000 کتگوری توی تخفیفان وجود داره که در حال حاضر فقط حدود 100 تا از اون ها از طریق منو قابل مشاهده هستن)
خب همیشه همه تیم‌ها روی استیج در حال تست‌های خودشونن و تیم سئو هم قبل از ریلیز باید موارد مربوط به خودش رو چک کنه.
من یه نکته خیلی مهم رو اینجا بگم، ما توی تخفیفان مایگریشن رو به صورت مرحله به مرحله انجام دادیم و توی هر ریلیز یکی از کتگوری های اصلی سایت رو پیش می‌بردیم.مثلا توی مرحله اول فقط کتگوری رستوران رو vendor base کردیم.توی این ابعاد اگه مایگریشن مرحله به مرحله انجام نشه ممکنه پشیمونی به بار بیاره پس بهتر بود خیلی محتاط پیش بریم و سعی کنیم توی هر مرحله مشکلات احتمالی رو بررسی کنیم تا توی مراحل بعدی اون اشتباهات تکرار نشن.
توی استیج با توجه به اینکه دسترسی ها محدوده (هر سازمانی از روش خاصی استفاده می‌کنه) و اکشن‌ها فیدبک دقیقی نداره، شما نمی‌تونید مطمئن بشید که همه چیز داره به خوبی پیش میره، مثلا ریدایرکت‌ها تا وقتی انجام نشن شما متوجه نمی‌شید درست انجام شدن یا نه ( ریدایرکت هارو هم میشه روی استیج انجام داد اما معمولا تیم فنی زیر بارش نمیره)، اما یه سری چیزهارو حتما باید چک کنید.
چیزهایی که باید روی استیج چک کنید معمولا تایتل، دیسکریپشن، کنونیکال، کانتنت صفحه، لینک های داخلی، داده‌های ساختار یافته، پرفورمنس صفحات و ... هستند.
ما توی مرحله اول ریلیز، کتگوری رستوران رو vendor base کردیم و علاوه بر اون تایتل و دیسکریپشن نصف کتگوری های سایت رو تغییر دادیم (همون تستی که گفتم).
چند روز بعد از ریلیز هم ما sitemap رو آپدیت کردیم و اولین گروه از وندورها وارد sitemap شدن.
فاصله بین ریلیز اول و ریلیز دوم حدود یک ماه بود چون این اولین کتگوری بود که vendor base میشد و هم تیم SEO و هم تیم های دیگه شدیدا درگیر رصد تاثیرات این جابجایی روی بیزینس بودیم.
مراحل بعدی هم بعد از بررسی ریلیز قبلی و رفع ایرادات انجام می‌شدن و توی مراحل بعدی سرعت کار بالا می‌رفت، دیگه اومده بود دستمون :))
بعد از اینکه تغییرات مورد نظر روی سایت اعمال شد ما شروع کردیم به بررسی اتفاقاتی که داره میوفته و حقیقتش شخصا استرس زیادی هم داشتم.
چه چیزهایی رو باید بررسی می‌کردیم؟
اولین و در دسترس‌ترین چیزی که باید بررسی می‌کردیم، این بود که مطمئن بشیم ریدایرکت‌ها به درستی و بدون هیچ ایرادی انجام شدن.بعدش هم همون مواردی که چند خط بالاتر گفتم روی استیج باید چک بشن.
پس ما دوباره رفتیم سراغ رفیق خوبمون screaming frog و شروع کردیم به بررسی این موارد، این بار کارمون راحت تر بود چون بررسی فقط شامل بخشی از سایت میشد.
پس توی این مرحله باید مطمئن بشید که هرچی که توی استیج چک کردید درست منتشر شده و اگه مورد مهمی هست که درست انجام نشده سریعا به تیم فنی انتقال بدین.
علاوه بر این موارد ما حدود 2 هفته منتظر موندیم تا اون کتگوری کاملا کراول شه و 2 مورد رو بررسی کنیم:
1: خطاهای احتمالی در کراول، ایندکس و ...
2: تغییر جایگاه ها و بررسی دراپ احتمالی کیوردها در SERP
در آخر دوست دارم یه سری نکاتی که به نظرم مهم هستن رو اینجا بگم:
به هر حال، بهتره که تغییر سرور وسط تغییرات ساختاری سایت اتفاق نیوفته اما اگه مجبور به این کار شدید و سایت برای چند ساعت down بود برای اینکه مشکلی توی سئو پیش نیاد از تیم فنی بخواهید که status code 503 رو به مرورگر برگردونن.
پ.ن: میشد توی خیلی از بخش‌های این مقاله بیشتر وارد جزئیات شد اما من دوست داشتم مقاله توی چارچوب مایگریشن و تجربه ای که ازش داشتم باقی بمونه و تبدیل به چیز دیگه ای نشه چون هر کدوم از مراحل جزئیات و پیچیدگی‌های خودشون رو دارن.یه سری بخش‌ها رو خودم معرفی کردم از کجا مطالعه کنید یا ببینید و بخش‌های دیگه رو هم اگه آشنایی کافی ندارید پیشنهاد میکنم سرچ کنید و در موردشون بخونید.
امیدوارم با این مقاله تونسته باشم نکات به درد بخوری رو منتقل کنم :) شما هم اگه تجربه ای توی مایگریشن دارید لطفا توی کامنت ها باهامون به اشتراک بگذارید تا استفاده کنیم.
