سلام، میثم سلیمی هستم. فعالیتم در حوزه سئو را از اردیبهشت ۹۷ آغاز کردم و اکنون در شرکت تخفیفان مشغول به کار هستم.
چندی پیش پستی درباره مایگریشن (انتقال سایت) تخفیفان در لینکدین منتشر کردم. پس از آن، تصمیم گرفتم جزئیات بیشتری را در این خصوص با شما به اشتراک بگذارم، به این امید که تجربه من برای برخی از شما مفید واقع شود. نتیجه این تصمیم، همین مقاله است. 🙂
دو نکته را لازم میدانم یادآوری کنم: اول اینکه این مقاله جنبه آموزشی صرف ندارد، بلکه بیشتر به انتقال تجربه شخصی من میپردازد. بنابراین، ممکن است تمام ابعاد مایگریشن در آن پوشش داده نشود. با این حال، برای روشنتر شدن مطالب، سعی میکنم نکات کلی مربوط به مایگریشن را نیز بیان کنم.
نکته دوم اینکه تلاش میکنم مطالب را به زبانی ساده بنویسم و امیدوارم بتوانم کمکی هرچند کوچک به همکاران عزیز در مسیر شغلی سئو باشم تا در صورت نیاز به مایگریشن، تجربهای موفق داشته باشند.
به طور کلی، مایگریشن انواع مختلفی دارد، از جمله تغییر سرور، تغییر ساختار سایت، ریدیزاین، تغییرات محتوایی و غیره. در مایگریشن تخفیفان، هم تغییر ساختار سایت، هم ریدیزاین و هم انتقال سرور اتفاق افتاد. اما عامل اصلی و مهمی که منجر به این تغییرات شد، «تغییر نوع همکاری تخفیفان با شرکای تجاری و نحوه ارائه سرویس به کاربران» بود که لزوم تغییرات اساسی در ساختار سایت را ایجاب میکرد.
تا چند ماه پیش، تخفیفان یک سایت «deal base» بود که تخفیفهای مختلفی را ارائه میکرد. اما با این مایگریشن، تخفیفان به یک «مارکتپلیس» تبدیل شد و ساختار سایت به «vendor base» تغییر یافت. به این معنی که پیشنهادها و تخفیفها توسط خود کسبوکارها تعریف میشوند، که قبلاً اینگونه نبود.
این فرآیند مایگریشن، از اولین انتشار تا تکمیل نهایی، حدود ۴ ماه به طول انجامید. اما تا جایی که اطلاع دارم، بخش بیزینس حدود یک سال درگیر این تغییر و تحولات بود.
حال به اصل مطلب بپردازیم:
ما در تیم سئو، برای انجام صحیح وظایفمان، یک نقشه راه (road map) تدوین کردیم که شامل بخشهای زیر بود:
- استخراج کامل دادههای سایت قبل از مایگریشن
- جایگذاری دادههای جدید برای انتقال
- بررسی وظایف انجام شده در محیط استیج قبل از انتشار
- انتشار (release)
- مانیتورینگ و بررسی خطاها و تاثیرات احتمالی
این نقشه راه را با سایر تیمها به اشتراک گذاشتیم و برای زمانبندیها هماهنگیهای لازم را انجام دادیم.
بیایید این مراحل را با جزئیات بیشتری مرور کنیم.
۱: استخراج کامل دادههای سایت قبل از مایگریشن
پیش از شروع مایگریشن، باید صفحات و مشخصات کامل آنها را استخراج و دستهبندی میکردیم. ما شروع به کراول کردن تمام بخشهای سایت و دستهبندی اطلاعات کردیم. این کار را بسته به شرایط و ابعاد سایت میتوان به روشهای مختلفی انجام داد، از جمله با استفاده از ابزارهایی مانند Screaming Frog، پایتون یا Google Sheet.
برای سایتهای کوچکتر، Google Sheet گزینه مناسبی است.
برای سایتهای بزرگتر، باید از پایتون یا Screaming Frog استفاده کنید. آموزشهای مقدماتی و پیشرفته زیادی برای Screaming Frog وجود دارد.
ما بخش عمدهای از این مرحله را با Screaming Frog پیش بردیم.
واقعیت این است که اگر سایت شما صفحات زیادی داشته باشد، همین مرحله اول زمان نسبتاً زیادی از شما میگیرد. برای اینکه مراحل بعدی را به خوبی پیش ببرید، نیاز دارید که این مرحله را با دقت بالایی انجام دهید. ما در این مرحله، دادههای صفحاتمان را استخراج کردیم که شامل URL، عنوان صفحه، متادیسکریپشن، کنونیکال، محتوا و تعدادی داده دیگر از دستهبندیها و صفحات تخفیف میشد.
نکته: برخی از ستونهایی که در تصویر زیر مشاهده میکنید (مثلاً parent – slug – category ids) توسط تیم فنی پر شده بودند و آنها علاوه بر دادههای ما، به تعدادی داده دیگر برای پیشبرد کار نیاز داشتند.
در نتیجه، سندی به این شکل آماده کردیم:
۲: جایگذاری دادههای جدید برای انتقال
میتوان گفت مهمترین بخش مایگریشن سایت همین قسمت است. اگر اشتباه بزرگی در انتقال دادهها رخ دهد، ممکن است عواقب جدی داشته باشد. باید یک نقشه بسیار کامل و دقیق از آنچه قرار است انجام دهید، داشته باشید. احتمالاً برای بخش زیادی از اطلاعاتی که در تصویر بالا دیدید، باید جایگزین مناسبی داشته باشید.
چالشبرانگیزترین بخش کار برای ما، ساخت صفحات وندور و انتقال صفحات تخفیف به وندورهای مرتبطشان بود. فکر میکنم لازم است این قسمت را کمی بیشتر توضیح دهم:
در سایت تخفیفان، حدود ۱۰۰,۰۰۰ صفحه تخفیف وجود داشت. منظور از صفحه تخفیف، همان پیشنهادهایی بود که ارائه میشد. مثلاً یک صفحه برای «تخفیف صبحانه رستوران گردان برج میلاد ویژه آخر هفته» و یک صفحه دیگر برای «تخفیف صبحانه رستوران گردان برج میلاد ویژه وسط هفته» وجود داشت.
یا مثلاً اگر یک خواننده در سال ۵ بار کنسرت اجرا میکرد، هر بار در تخفیفان برایش یک صفحه تخفیف ایجاد میشد. اما وقتی به سمت «vendor base» شدن حرکت میکردیم، باید به گونهای میشد که فقط یک صفحه برای آن خواننده ایجاد شود و هر زمان کنسرتی داشت، پیشنهادش در همان صفحه نمایش داده شود.
اینها را گفتم تا بگویم گاهی اوقات مشاهده میشد که برای یک وندور، بیش از ۱۰ صفحه تخفیف وجود دارد و ما باید ابتدا همه آنها را پیدا میکردیم و برایشان یک صفحه وندور ایجاد میکردیم و سپس آنها را به صفحه وندور ریدایرکت میکردیم.
یک اتفاق خوبی که در این مرحله افتاد و باعث شد کمی آسودهخاطر شوم، این بود که از چند سال پیش صفحات وندور در پنل ساخته شده بودند و مشخص بود که کدام تخفیف مربوط به کدام وندور میشود. یعنی از چند سال پیش مشخص بود که تخفیفان قرار است روزی «vendor base» شود و برخی زیرساختهای آن از همان زمان کمکم ایجاد شده بود.
اما فرض کنید این اتفاق نیفتاده بود، در آن صورت بر چه اساسی باید صفحات وندور را میساختیم؟
چیزی که به ذهن من میرسد، استفاده از ریجکس (Regex) در Google Sheet است. مثلاً اگر ما ۱۰ صفحه تخفیف داشتیم که در عنوانشان از کلمه «رستوران گردان برج میلاد» استفاده شده بود، میشد با استفاده از ریجکس آنها را پیدا کرد و برایشان یک صفحه وندور به نام «رستوران گردان برج میلاد» ساخت.
خب، در نهایت ما یک سند رز سانگ تهیه کردیم و در آن مشخص کردیم که چه صفحاتی باید به چه صفحاتی ریدایرکت شوند.
نتیجه:
در این میان، ما تعدادی صفحه را نیز مشخص کردیم که باید حذف میشدند. بیشتر اینها صفحاتی بودند که مربوط به هیچ وندوری نمیشدند و وجودشان در سایت نه تنها منفعتی نداشت، بلکه مضر نیز بود.
پس ما:
- تعدادی صفحه را به وندور مربوطه ریدایرکت کردیم.
- تعدادی از صفحات را کلاً ۴۱۰ کردیم.
- و تعدادی صفحه را که به نظرمان نباید از ابتدا در گوگل ایندکس میشدند، noindex کردیم.
جالب است بدانید در نهایت حدود ۳۵,۰۰۰ صفحه را از نتایج گوگل حذف کردیم و سعی کردیم کراول را به سمت صفحات مهمتر هدایت کنیم.
خب، مهمترین قسمت از مرحله ۲ را پشت سر گذاشتیم، میرسیم به موارد دیگر.
طبیعتاً ما در این مرحله، دادههای دیگر مانند عنوان، توضیحات و غیره را نیز جایگذاری کردیم.
ما میخواستیم حالا که وارد یک دوره پر ریسک میشویم، یک سری تستها را هم روی سایت انجام دهیم. چون همزمان با مایگریشن، تعدادی هدف دیگر هم داشتیم که باید به آنها میرسیدیم. :))
(البته در مایگریشنهایی که ساختار سایت تغییرات اساسی دارد، نمیتوان از یک تست خاص برداشت دقیقی کرد.)
صفحات وندور قاعدتاً باید عنوان و توضیحات جدیدی برایشان نوشته میشد، زیرا مفهوم صفحه تغییر کرده بود و از تخفیف به وندور تبدیل شده بود. این یک کار اجتنابناپذیر بود و باید انجام میشد.
پس ما به سراغ دستهبندیها رفتیم و خواستیم روی تقریباً نیمی از دستهبندیها با تغییر عنوان و توضیحات تست انجام دهیم و در مرحله جایگذاری دادهها، عنوان و توضیحات نیمی از دستهبندیها را نیز تغییر دادیم. (تقریباً ۲۰۰۰ دستهبندی در تخفیفان وجود دارد که در حال حاضر فقط حدود ۱۰۰ مورد از آنها از طریق منو قابل مشاهده هستند.)
۳: بررسی وظایف انجام شده در محیط استیج قبل از انتشار
همیشه همه تیمها روی محیط استیج در حال تستهای خود هستند و تیم سئو نیز قبل از انتشار باید موارد مربوط به خود را بررسی کند.
یک نکته خیلی مهم را اینجا بگویم: ما در تخفیفان، مایگریشن را به صورت مرحله به مرحله انجام دادیم و در هر انتشار، یکی از دستهبندیهای اصلی سایت را پیش میبردیم. مثلاً در مرحله اول فقط دستهبندی رستوران را «vendor base» کردیم. در این ابعاد، اگر مایگریشن مرحله به مرحله انجام نشود، ممکن است پشیمانی به بار آورد، پس بهتر بود خیلی محتاطانه پیش برویم و سعی کنیم در هر مرحله مشکلات احتمالی را بررسی کنیم تا در مراحل بعدی آن اشتباهات تکرار نشوند.
در محیط استیج، با توجه به اینکه دسترسیها محدود است (هر سازمانی از روش خاصی استفاده میکند) و اکشنها بازخورد دقیقی ندارند، شما نمیتوانید مطمئن شوید که همه چیز به خوبی پیش میرود. مثلاً ریدایرکتها تا زمانی که انجام نشوند، شما متوجه نمیشوید درست انجام شدهاند یا نه (ریدایرکتها را هم میشود روی استیج انجام داد اما معمولاً تیم فنی زیر بارش نمیرود)، اما یک سری چیزها را حتماً باید چک کنید.
چیزهایی که باید روی استیج چک کنید معمولاً عنوان، توضیحات، کنونیکال، محتوای صفحه، لینکهای داخلی، دادههای ساختاریافته، پرفورمنس صفحات و غیره هستند.
۴: انتشار (Release)
ما در مرحله اول انتشار، دستهبندی رستوران را به صورت «vendor base» درآوردیم و علاوه بر آن، عنوان و توضیحات نیمی از دستهبندیهای سایت را تغییر دادیم (همان تستی که گفتم).
چند روز پس از انتشار نیز، ما نقشه سایت (sitemap) را بهروزرسانی کردیم و اولین گروه از وندورها وارد نقشه سایت شدند.
فاصله بین انتشار اول و انتشار دوم حدود یک ماه بود، زیرا این اولین دستهبندی بود که «vendor base» میشد و هم تیم سئو و هم تیمهای دیگر به شدت درگیر رصد تأثیرات این جابجایی بر کسبوکار بودیم.
مراحل بعدی نیز پس از بررسی انتشار قبلی و رفع ایرادات انجام میشدند و در مراحل بعدی سرعت کار بالا میرفت، دیگر دستمان آمده بود. :))
۵: مانیتورینگ و بررسی خطاها و تاثیرات احتمالی
پس از اعمال تغییرات مورد نظر روی سایت، ما شروع به بررسی اتفاقاتی که در حال رخ دادن بود کردیم و حقیقتش شخصاً استرس زیادی هم داشتم.
چه چیزهایی را باید بررسی میکردیم؟
اولین و در دسترسترین چیزی که باید بررسی میکردیم، این بود که مطمئن شویم ریدایرکتها به درستی و بدون هیچ ایرادی انجام شدهاند. بعد از آن، همان مواردی که چند خط بالاتر گفتم روی استیج باید چک میشدند.
پس ما دوباره به سراغ دوست خوبمان Screaming Frog رفتیم و شروع به بررسی این موارد کردیم. این بار کارمان راحتتر بود، زیرا بررسی فقط شامل بخشی از سایت میشد.
پس در این مرحله باید مطمئن شوید که هرچه در استیج چک کردهاید، درست منتشر شده و اگر مورد مهمی هست که درست انجام نشده، سریعاً به تیم فنی انتقال دهید.
علاوه بر این موارد، ما حدود ۲ هفته منتظر ماندیم تا آن دستهبندی کاملاً کراول شود و ۲ مورد را بررسی کنیم:
- خطاهای احتمالی در کراول، ایندکس و غیره
- تغییر جایگاهها و بررسی افت احتمالی کلمات کلیدی در نتایج جستجو (SERP)
در آخر، دوست دارم یک سری نکات که به نظرم مهم هستند را اینجا بگویم:
- ارتباط با تیمهای دیگر همیشه در سئو مهم بوده و زمان مایگریشن نیز یکی از مهمترین مسائلی است که باید به خوبی از عهده آن برآیید. موضوع ارتباط با تیمهای دیگر بسیار گسترده است.
- همانطور که گفتم، ما مایگریشن را مرحله به مرحله انجام دادیم و به نظرم این موضوع مخصوصاً در سایتهای متوسط و بزرگ بسیار مهم است و میتوان کار را بهتر پیش برد.
- یک اتفاق مهمی که برای ما در این مایگریشن افتاد، تغییر سرور درست در میانه تغییرات ساختاری سایت بود. تغییر سرور در حالت عادی هم ممکن است تأثیراتی روی سئو داشته باشد. ما سعی کردیم جلوی این اتفاق را بگیریم، اما این چیزی نبود که بتوانیم از آن جلوگیری کنیم و باید انجام میشد.
- به هر حال، بهتر است که تغییر سرور در میانه تغییرات ساختاری سایت اتفاق نیفتد، اما اگر مجبور به این کار شدید و سایت برای چند ساعت از دسترس خارج شد، برای اینکه مشکلی در سئو پیش نیاید، از تیم فنی بخواهید که کد وضعیت ۵۰۳ را به مرورگر برگردانند.
- هرچه ابعاد تغییراتی که در حال انجام است بزرگتر باشد، اگر افتی برای سایت اتفاق بیفتد، تشخیص اینکه دلیلش چه بوده نیز سختتر میشود، پس باز هم اینجا یکی از راهکارها مایگریشن مرحله به مرحله است.
- اگر مایگریشن را به صورت مرحله به مرحله انجام دادید، بهتر است نقشه سایت (sitemap) را هم به صورت مرحلهای بهروزرسانی کنید.
پ.ن: میشد در بسیاری از بخشهای این مقاله بیشتر وارد جزئیات شد، اما من دوست داشتم مقاله در چارچوب مایگریشن و تجربهای که از آن داشتم باقی بماند و تبدیل به چیز دیگری نشود، زیرا هر کدام از مراحل جزئیات و پیچیدگیهای خود را دارند. برخی بخشها را خودم معرفی کردم که از کجا مطالعه کنید یا ببینید و بخشهای دیگر را هم اگر آشنایی کافی ندارید، پیشنهاد میکنم جستجو کنید و در موردشان بخوانید.
امیدوارم با این مقاله توانسته باشم نکات به دردبخوری را منتقل کنم. 🙂 شما هم اگر تجربهای در مایگریشن دارید، لطفاً در نظرات با ما به اشتراک بگذارید تا استفاده کنیم.
