مهاجرت سایت به هاست جدید چه تأثیری بر SEO دارد؟

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

چرا مهاجرت هاست، یک تصمیم استراتژیک است؟

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

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

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

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

معرفی پروژه و وضعیت اولیه

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

وضعیت اولیه هاست

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

اهداف اولیه پروژه

سه هدف مشخص روی کاغذ آوردیم و هرکدام را به یک عدد متصل کردیم. هدف اول، کاهش TTFB از حدود ۸۹۰ میلی‌ثانیه به زیر ۲۵۰ میلی‌ثانیه. هدف دوم، بازگشت ترافیک ارگانیک به سطح قبلی یا بالاتر در بازه سه‌ماهه. هدف سوم، افزایش پایداری سایت به‌گونه‌ای که در ساعات اوج هیچ خطای ۵xx ثبت نشود. هدف چهارمی که در ماه دوم اضافه شد، بهبود Core Web Vitals به محدوده سبز بود که در پلن قدیمی عملاً غیرممکن بود.

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

خط پایه در هشت شاخص کلیدی

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

سه عدد در این جدول، بحران را به‌وضوح نشان می‌داد. اول، TTFB نزدیک یک ثانیه؛ در سایت‌های حرفه‌ای این عدد معمولاً زیر دویست میلی‌ثانیه است. دوم، بیش از دو هزار رخداد خطای ۵xx در یک ماه که مستقیماً روی نرخ تبدیل و اعتماد کاربر اثر می‌گذاشت. سوم، مصرف CPU در ساعات اوج که به نودو‌چهار درصد می‌رسید؛ این یعنی سایت در آستانه ریزش کامل بود و هر افزایش ترافیکی می‌توانست آن را به‌طور کامل از دسترس خارج کند.

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

فاز تشخیص: چرا هاست قدیمی به دیوار خورده بود؟

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

سه گلوگاه اصلی که شناسایی شد

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

گلوگاه دوم، نوع دیسک. هاست قدیمی از دیسک HDD استفاده می‌کرد، در حالی که هاست‌های مدرن از SSD یا NVMe استفاده می‌کنند. تفاوت سرعت I/O بین این دو نوع دیسک، در پروژه‌های متعدد دیده‌ام که به تنهایی می‌تواند TTFB را دو تا سه برابر کند. نکته تکمیلی این تفاوت در چرا SSD برای وردپرس ضروری است آمده است.

گلوگاه سوم، نسخه قدیمی PHP و نبود OPcache. سایت روی PHP نسخه ۷.۲ اجرا می‌شد، در حالی که نسخه‌های جدید PHP سرعت اجرای کد وردپرسی را تا دو برابر بالا می‌برند. علاوه بر این، OPcache فعال نبود که باعث می‌شد PHP در هر ریکوئست، کد را از نو کامپایل کند.

روش تشخیص سه‌لایه‌ای

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

یک یافته مهم این فاز این بود که مسئله صرفاً منابع نبود؛ ترکیب منابع کم، دیسک کند و نسخه قدیمی PHP، مجموعاً به وضعیت بحرانی رسیده بود. اگر فقط یکی از این‌ها اصلاح می‌شد، نتیجه کمتر از نصف انتظار بود.

انتخاب هاست جدید و معیارهای تصمیم

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

سه معیار اصلی انتخاب

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

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

مشخصات پلن انتخابی

پلن نهایی شامل CPU اختصاصی چهار هسته‌ای، هشت گیگابایت رم، دیسک NVMe ۲۰۰ گیگابایت، سرور LiteSpeed و PHP نسخه ۸.۲ بود. علاوه بر این، پلن شامل بکاپ خودکار روزانه، SSL رایگان و پشتیبانی فنی با زمان پاسخ کمتر از یک ساعت بود. این ترکیب، در بازه پروژه به‌خوبی جواب داد و در سه ماه پس از مهاجرت، نیاز به ارتقای دوباره پیش نیامد.

گام اول: بکاپ کامل و تست‌شده

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

سه لایه بکاپ که تهیه شد

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

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

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

تست بازیابی پیش از شروع

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

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

گام دوم: بازیابی روی محیط مقصد

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

مراحل بازیابی

اول، فایل‌های سایت از بکاپ استخراج و در پوشه هاست جدید قرار گرفتند. دوم، دیتابیس از بکاپ در phpMyAdmin محیط جدید ایمپورت شد. سوم، فایل wp-config.php با اطلاعات اتصال دیتابیس جدید بازنویسی شد. چهارم، سایت روی زیردامنه موقت با تنظیمات SSL تست شد تا از اجرای صحیح اطمینان حاصل شود.

چالش‌های بازیابی و راه‌حل‌ها

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

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

گام سوم: تست پیش از سوییچ DNS

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

چه مواردی تست شد

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

چالش‌های تست

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

تنظیم کش و بهینه‌سازی‌های اولیه

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

گام چهارم: سوییچ DNS و مدیریت پروپاگیشن

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

آماده‌سازی پیش از سوییچ

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

سوییچ در ساعت کم‌ترافیک

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

مدیریت پروپاگیشن

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

عیب‌یابی احتمالی

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

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

گام پنجم: پایش ۹۰ روزه پس از مهاجرت

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

پایش در هفته اول

در هفته اول، پایش روزانه انجام شد. سه عدد اصلی سنجیده شد: TTFB، LCP و خطاهای ۵xx. علاوه بر این، Search Console روزانه بازبینی شد تا اگر خطای ایندکس مشاهده شد، سریع حل شود. اولین سه روز، TTFB حدود صد میلی‌ثانیه بالاتر از محیط staging بود که در بازه یک هفته به حالت پایدار رسید.

پایش در ماه اول

در ماه اول، پایش هفتگی انجام شد. پنج شاخص اصلی سنجیده شد: TTFB، LCP، CLS، خطاهای ۵xx و رتبه کلمات کلیدی اصلی. یافته مهم این ماه، تثبیت سریع شاخص‌های فنی و شروع روند مثبت در شاخص‌های سئویی بود. علاوه بر این، در همان ماه اول، تعداد خطاهای ۵xx از بیش از دو هزار به کمتر از پنجاه کاهش یافت.

پایش در ماه دوم و سوم

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

تنظیمات کش و بهینه‌سازی نهایی

در بازه ماه دوم، تنظیمات کش و بهینه‌سازی‌های تکمیلی انجام شد. کارهایی مثل تنظیم دقیق cache control، فعال‌سازی CDN و بهینه‌سازی تصاویر با فرمت‌های مدرن. این اقدامات مجموعاً حدود پانزده درصد بهبود اضافه در LCP ایجاد کرد. چارچوب کامل این نوع بهینه‌سازی در بهینه‌سازی سرعت سایت آمده است.

نتایج بعد از سه ماه

سه ماه پس از مهاجرت، شاخص‌ها را مجدداً سنجیدیم. نتایج در جدول زیر آمده است.

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

یافته اول: اثر مستقیم زیرساخت بر سرعت

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

یافته دوم: رشد ترافیک ارگانیک

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

یافته سوم: کاهش چشمگیر خطاهای سرور

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

یافته چهارم: رشد نرخ تبدیل موبایل

نرخ تبدیل موبایل از ۰.۸ به ۱.۳ درصد رسید که حدود شصت‌و‌سه درصد رشد است. این عدد، دو منبع داشت: اول، تجربه کاربری سریع‌تر که نرخ پرش را کاهش داد. دوم، پایداری سایت که اعتماد کاربر را در لحظه تصمیم‌گیری بالا برد. یک نکته ظریف این است که بخش بزرگی از بهبود نرخ تبدیل، به‌خاطر حذف خطاهای ۵xx بود که پیش از این در لحظات حساس خرید، کاربران را از دست می‌داد.

تفکیک اثر هر گام

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

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

نکته دوم این است که اثر هر گام در زمان متفاوتی ظاهر شد. بهبود TTFB بلافاصله پس از سوییچ DNS رخ داد. کاهش خطاها در بازه یک هفته. رشد ترافیک ارگانیک در بازه چهار تا هشت هفته. این تفاوت بازه‌ها نشان می‌دهد که باید صبر کرد و بر اساس داده‌های بلندمدت تصمیم گرفت.

اقداماتی که اثر مطلوب نداشتند

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

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

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

اقدام دوم: تغییر قالب همزمان با مهاجرت

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

اقدام سوم: به‌روزرسانی همزمان همه افزونه‌ها

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

درباره اشتباهات رایج در انتخاب هاست و مهاجرت، مقاله اشتباهات رایج در انتخاب هاست تحلیل جامعی ارائه می‌دهد.

اثر جانبی روی سئو و رتبه گوگل

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

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

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

پرسش‌های پرتکرار درباره مهاجرت سایت به هاست جدید

مهاجرت سایت به هاست جدید چقدر طول می‌کشد؟

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

آیا مهاجرت روی رتبه گوگل اثر منفی دارد؟

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

چه مدت زمان لازم است تا سایت به حالت پایدار بعد از مهاجرت برسد؟

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

آیا باید همزمان با مهاجرت، قالب را هم تغییر داد؟

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

آیا مهاجرت به VPS برای همه سایت‌ها توصیه می‌شود؟

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

چطور بفهمم هاست فعلی دیگر پاسخگو نیست؟

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

آیا مهاجرت روی درآمد فروشگاه اثر می‌گذارد؟

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

چه اقداماتی قبل از مهاجرت باید انجام شود؟

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

آیا مهاجرت روی Core Web Vitals اثر دارد؟

بله، و این یکی از مهم‌ترین اثرات مهاجرت در پروژه‌های مدرن است. در این پروژه، LCP موبایل پنجاه‌و‌پنج درصد بهبود یافت و CLS هفتادو‌سه درصد کاهش یافت. این بهبود، ترکیبی از منابع بهتر سرور، دیسک سریع‌تر، OPcache فعال و کش بهینه بود. برای درک عمیق‌تر این شاخص‌ها، Core Web Vitals چیست را ببینید.

آیا استفاده از CDN همزمان با مهاجرت توصیه می‌شود؟

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

آیا پس از مهاجرت نیاز به بهینه‌سازی سرعت هست؟

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

آیا سایت‌های وردپرسی روی هاست‌های ارزان هم می‌توانند سریع باشند؟

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

پنج درس کلیدی این پروژه

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

1. مهاجرت بدون بکاپ تست‌شده، قمار با دارایی کسب‌وکار است. حداقل سه لایه بکاپ و یک تست بازیابی ضروری است.
2. انتخاب هاست با معیارهای دقیق، نیمی از موفقیت پروژه است. قیمت پایین، معیار نیست؛ ترکیب سرعت، پایداری و پشتیبانی معیار است.
3. پایش نود روزه پس از مهاجرت، بخشی از خود پروژه است نه کار اضافه. تصمیم بر اساس داده‌های دو هفته اول، معمولاً اشتباه است.
4. هرگز دو تغییر بزرگ (مهاجرت و تغییر قالب یا افزونه) را در یک بازه انجام ندهید. تفکیک، تشخیص مقصر را ممکن می‌کند.
5. پایداری در ساعات اوج، ارزشمندتر از سرعت در ساعات خلوت است. هاستی که در اوج می‌ریزد، حتی اگر در خلوت سریع باشد، انتخاب اشتباهی است.

این پنج درس، خروجی مستقیم تجربه این پروژه است. اگر تیم شما در آستانه مهاجرت هاست است، این پنج مورد را روی دیوار یادداشت کنید.

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

مهاجرت موفق چه رازهایی دارد؟

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

در پروژه‌های امروز من، اولین اقدام در هر پروژه مهاجرت، همیشه ممیزی کامل است. چهار عدد اول که در همه پروژه‌ها سنجیده می‌شود: TTFB در ساعات اوج، خطاهای ۵xx ماهانه، مصرف CPU هاست و نرخ تبدیل فعلی. این چهار عدد، تصویر سریعی از وضعیت زیرساخت می‌دهند و مسیر تصمیم اول را روشن می‌کنند.

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

برای درک عمیق‌تر تأثیر هاست روی عملکرد سایت، تأثیر هاست بر سرعت سایت را بخوانید. برای مقایسه دقیق پلن‌های مختلف، بهترین هاست وردپرس و مقایسه هاست از نظر سرعت راهنمای عملی خوبی هستند.

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

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