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

انتقال سایت به هاست جدید چه تأثیری بر سئو دارد؟
خلاصه پاسخ: اگر در فرایند انتقال سایت به هاست جدید فقط زیرساخت میزبانی تغییر کند و آدرس صفحات، محتوای سایت، ساختار لینکها و دسترسی موتورهای جستجو حفظ شوند، معمولاً نیازی به تغییر URL یا اجرای ریدایرکت نیست. بااینحال، اختلال در دسترسی Googlebot، خطاهای سرور و تغییر ناخواسته تنظیمات فنی میتوانند عملکرد سئوی سایت را تحت تأثیر قرار دهند.
از دید موتورهای جستجو، یک صفحه وب فقط مجموعهای از فایلهای موجود روی سرور نیست. گوگل برای شناسایی، خزش و ارزیابی صفحات از اطلاعات مختلفی مانند آدرس URL، محتوای HTML، لینکهای داخلی، تگ Canonical، کدهای پاسخ HTTP و سیگنالهای فنی استفاده میکند.
بنابراین، زمانی که یک سایت از سرور A به سرور B منتقل میشود، مهم است که سرور جدید همان محتوای مورد انتظار را از همان آدرسهای قبلی ارائه کند.
برای مثال، فرض کنید آدرس یک فروشگاه اینترنتی به شکل زیر است:
پس از انتقال هاست نیز باید همین آدرس در دسترس باشد و همان صفحه محصول را نمایش دهد.
اگر URL ثابت بماند، انتقال صرفاً یک تغییر زیرساختی محسوب میشود، نه مهاجرت دامنه.
البته چند عامل میتوانند باعث ایجاد مشکل شوند:
- پاسخگویی نامناسب سرور جدید و افزایش خطاهای 5xx
- مسدود شدن دسترسی خزندههای موتور جستجو
- تغییر ناخواسته فایل robots.txt
- ایجاد تگ Noindex روی صفحات
- حذف یا تغییر آدرس تصاویر و فایلهای مهم
- تغییر تنظیمات Canonical
- از دست رفتن اطلاعات پایگاه داده
- تغییر نسخه PHP و ایجاد ناسازگاری در کدهای سایت
نکته مهم این است که تغییر هاست بهتنهایی جریمه سئویی محسوب نمیشود؛ اما کیفیت اجرای مهاجرت میتواند بر دسترسیپذیری و عملکرد سایت اثر بگذارد.
تفاوت انتقال هاست با انتقال دامنه چیست؟
خلاصه پاسخ: انتقال هاست به معنای جابهجایی فایلها، پایگاه داده و سرویسهای سایت به یک سرور یا شرکت میزبانی جدید است؛ درحالیکه انتقال دامنه معمولاً به تغییر نام دامنه یا آدرس اصلی وبسایت اشاره دارد. این دو فرایند از نظر فنی و سئویی متفاوت هستند و نباید اقدامات مربوط به آنها را با یکدیگر اشتباه گرفت.
برای درک بهتر، سه سناریوی متداول را در نظر بگیرید:
سناریوی اول: تغییر هاست بدون تغییر دامنه
در این حالت، دامنه و URL صفحات ثابت هستند و فقط آدرس IP یا زیرساخت پاسخگوی سایت تغییر میکند.
مثال:
- هاست قبلی: سرور A با IP مشخص
- هاست جدید: سرور B با IP متفاوت
- دامنه:
example.com
در این سناریو معمولاً نیازی به ریدایرکت ۳۰۱ یا ابزار Change of Address سرچ کنسول نیست.
سناریوی دوم: تغییر دامنه
فرض کنید سایت از example.com به newexample.com منتقل میشود.
در این شرایط باید URLهای قدیمی به آدرسهای متناظر جدید با ریدایرکت دائمی ۳۰۱ منتقل شوند و اقدامات مربوط به تغییر آدرس در Google Search Console انجام شوند.
سناریوی سوم: تغییر همزمان هاست و ساختار URL
این حالت حساستر است؛ زیرا علاوه بر تغییر زیرساخت، ممکن است آدرس صفحات، دستهبندیها یا مسیرهای محتوایی نیز تغییر کنند.
بهتر است این تغییرات تا حد امکان همزمان با سایر بازطراحیها و تغییرات گسترده انجام نشوند. تفکیک مراحل به شما کمک میکند در صورت بروز مشکل، علت آن را دقیقتر شناسایی کنید.
قبل از انتقال سایت به هاست جدید چه اقداماتی ضروری است؟
خلاصه پاسخ: پیش از شروع مهاجرت باید از تمام فایلها و پایگاه داده نسخه پشتیبان تهیه کنید، وضعیت سئوی فعلی را ثبت کنید، تنظیمات دامنه و DNS را بررسی کنید و از سازگاری زیرساخت جدید با فناوریهای سایت مطمئن شوید. این اقدامات احتمال از دست رفتن اطلاعات و بروز اختلال هنگام جابهجایی را کاهش میدهند.
یکی از اشتباهات رایج مدیران سایت این است که بلافاصله پس از خرید هاست جدید، عملیات انتقال را شروع میکنند؛ بدون اینکه وضعیت سایت فعلی را مستندسازی کرده باشند.
برای جلوگیری از این مشکل، بهتر است پیش از مهاجرت موارد زیر بررسی شوند.
۱. تهیه نسخه پشتیبان کامل از سایت
اولین اقدام، تهیه بکاپ از تمام اطلاعات سایت است.
نسخه پشتیبان باید شامل موارد زیر باشد:
- تمام فایلهای موجود در مسیر اصلی سایت
- پوشههای آپلود و تصاویر
- فایلهای تنظیمات مانند wp-config.php
- پایگاه داده MySQL یا MariaDB
- فایلهای مخفی مانند .htaccess
- فایلهای مربوط به ایمیلها، در صورت نیاز
- تنظیمات Cron Job و سایر وظایف زمانبندیشده
بهتر است بکاپ در محلی خارج از هاست فعلی نگهداری شود.
همچنین صرفاً تهیه بکاپ کافی نیست. باید امکان بازیابی اطلاعات نیز بررسی شود؛ زیرا نسخه پشتیبانی که قابل بازیابی نباشد، در زمان بروز مشکل ارزش عملیاتی چندانی ندارد.
۲. ثبت وضعیت سئوی سایت قبل از مهاجرت
یکی از مهمترین اقداماتی که معمولاً نادیده گرفته میشود، ثبت وضعیت سئوی سایت پیش از انتقال است.
پیشنهاد میشود اطلاعات زیر را در Google Search Console و ابزارهای تحلیل وب ثبت کنید:
- صفحات دارای بیشترین کلیک ارگانیک
- تعداد Impression و Click
- میانگین جایگاه کلمات کلیدی مهم
- وضعیت ایندکس صفحات
- خطاهای خزش
- وضعیت Sitemap
- صفحات دارای ترافیک ورودی بالا
- وضعیت Core Web Vitals
این اطلاعات به شما کمک میکنند پس از انتقال، تغییرات احتمالی را با وضعیت قبلی مقایسه کنید.
بدون داشتن اطلاعات اولیه، تشخیص اینکه کاهش بازدید ناشی از مهاجرت بوده یا تغییرات طبیعی جستجو، دشوار خواهد بود.
۳. بررسی سازگاری هاست جدید
هاست جدید باید با نیازهای واقعی وبسایت سازگار باشد.
برای مثال، در سایتهای وردپرسی باید موارد زیر بررسی شوند:
- نسخه PHP
- نسخه و نوع پایگاه داده
- میزان RAM و منابع پردازشی
- محدودیت اجرای پردازشها
- فضای ذخیرهسازی
- محدودیت حجم آپلود
- پشتیبانی از افزونهها و توابع موردنیاز
- تنظیمات وبسرور
- امکان استفاده از SSL
در پروژههای برنامهنویسیشده با Node.js یا Python نیز باید نسخه Runtime، وابستگیها، متغیرهای محیطی و سرویسهای موردنیاز بررسی شوند.
صرفاً داشتن فضای ذخیرهسازی بیشتر به معنای مناسب بودن یک سرویس میزبانی نیست.
چگونه سایت را بدون قطعی به هاست جدید منتقل کنیم؟
خلاصه پاسخ: برای انتقال سایت با حداقل قطعی، ابتدا باید نسخه کامل سایت روی سرور جدید آماده و آزمایش شود. سپس با کاهش زمان TTL رکوردهای DNS، انتقال نهایی اطلاعات و هماهنگی تغییر DNS انجام شود. برای سایتهای پویا نیز باید از همگامسازی نهایی پایگاه داده و کنترل همزمانی اطلاعات استفاده کرد.
در یک مهاجرت اصولی، سرور جدید باید پیش از دریافت ترافیک اصلی، آماده ارائه خدمات باشد.
فرایند پیشنهادی شامل مراحل زیر است.
مرحله اول: آمادهسازی محیط میزبانی جدید
پس از خرید هاست یا سرور جدید، ابتدا محیط اجرایی آن را مطابق نیاز سایت تنظیم کنید.
برای مثال، اگر سایت وردپرسی است، باید نسخه PHP و پایگاه داده سازگار انتخاب شود.
اگر پروژه با فریمورک Laravel توسعه داده شده، مواردی مانند Composer، نسخه PHP، افزونههای موردنیاز، مسیر اجرای پروژه و تنظیمات فایل .env اهمیت دارند.
در پروژههای Node.js نیز باید نسخه Node، پکیجها، Process Manager و تنظیمات اجرای برنامه مشخص شوند.
در این مرحله هنوز نباید هاست قدیمی را غیرفعال کنید.
مرحله دوم: انتقال فایلها و پایگاه داده
در این مرحله اطلاعات سایت از سرور قبلی به سرور جدید منتقل میشوند.
روش انتقال به نوع سرویس میزبانی بستگی دارد.
در هاستهای دارای کنترل پنل cPanel، امکان استفاده از Full Account Backup یا ابزارهای انتقال حساب وجود دارد.
در سرورهای لینوکسی نیز ابزارهایی مانند rsync میتوانند برای انتقال فایلها استفاده شوند.
برای مثال:
rsync -avz /source/ user@NEW_SERVER:/destination/
این دستور نمونهای برای همگامسازی فایلها بین دو مسیر است و باید متناسب با دسترسی و ساختار سرورها تنظیم شود.
پایگاه داده نیز باید Export و سپس روی سرور جدید Import شود.
پس از انتقال، اطلاعات اتصال به پایگاه داده، دسترسی فایلها و مسیرهای اجرایی را بررسی کنید.
نکته مهم: در سایتهای فروشگاهی و پرتراکنش، پایگاه داده ممکن است هنگام انتقال اولیه همچنان تغییر کند. بنابراین یک کپی اولیه بهتنهایی کافی نیست و باید برای همگامسازی نهایی دادهها برنامه داشته باشید.
مرحله سوم: آزمایش سایت روی سرور جدید بدون تغییر DNS
یکی از مهمترین مراحل مهاجرت، آزمایش سایت قبل از تغییر DNS است.
در این مرحله باید مطمئن شوید که سایت روی سرور جدید بهدرستی اجرا میشود، بدون اینکه کاربران عادی هنوز به آن هدایت شده باشند.
برای انجام این کار میتوان از فایل Hosts سیستم یا روشهای تست مستقیم IP با تنظیم Host Header استفاده کرد.
در این مرحله موارد زیر را بررسی کنید:
- صفحه اصلی سایت
- صفحات داخلی و مقالات
- تصاویر و فایلهای دانلودی
- فرمهای ثبتنام و تماس
- ورود و خروج کاربران
- سبد خرید و فرایند پرداخت
- پنل مدیریت
- اتصال به پایگاه داده
- ارسال ایمیل
- گواهی SSL
- لینکهای داخلی
همچنین بررسی کنید که سایت در محیط آزمایشی دارای تنظیمات ناخواسته Noindex یا محدودیت robots.txt نباشد.
اگر در این مرحله خطایی مشاهده شد، بهتر است قبل از تغییر DNS آن را برطرف کنید.
برای آشنایی بیشتر با روشهای افزایش سرعت و بهبود عملکرد وبسایت، پیشنهاد میکنیم مقاله CDN چیست و چه تأثیری بر سرعت سایت دارد؟ را مطالعه کنید.
مرحله چهارم: کاهش TTL رکوردهای DNS
TTL مخفف Time To Live است و مشخص میکند اطلاعات یک رکورد DNS چه مدت در حافظه کش Resolverها نگهداری شود.
برای مثال، اگر TTL یک رکورد ۱۴۴۰۰ ثانیه باشد، این مقدار معادل ۴ ساعت است.
هنگام مهاجرت، میتوان ۲۴ تا ۴۸ ساعت پیش از تغییر DNS، در صورت امکان TTL رکوردهای مرتبط را کاهش داد.
برای نمونه:
| مقدار TTL | مدت زمان |
|---|---|
| ۱۴۴۰۰ | ۴ ساعت |
| ۳۶۰۰ | ۱ ساعت |
| ۱۸۰۰ | ۳۰ دقیقه |
| ۳۰۰ | ۵ دقیقه |
کاهش TTL میتواند به سریعتر شدن بهروزرسانی DNS در بسیاری از Resolverها کمک کند؛ اما تضمین نمیکند که تمام کاربران بلافاصله IP جدید را دریافت کنند.
برخی Resolverها ممکن است اطلاعات قبلی را تا پایان زمان کش خود نگه دارند.
مرحله پنجم: انتقال نهایی و تغییر DNS
پس از اطمینان از صحت عملکرد سرور جدید، نوبت تغییر رکوردهای DNS میرسد.
معمولاً باید رکوردهای زیر بررسی شوند:
- A Record برای اتصال دامنه به IP جدید
- AAAA Record در صورت استفاده از IPv6
- CNAME برای زیردامنهها
- MX برای سرویس ایمیل
- TXT برای تنظیمات SPF، DKIM و سایر اعتبارسنجیها
تمام رکوردها را بدون بررسی تغییر ندهید. برای مثال، رکورد MX ممکن است همچنان به سرویس ایمیل قبلی وابسته باشد و تغییر اشتباه آن باعث اختلال در دریافت ایمیلها شود.
پس از تغییر DNS، باید سایت از چند شبکه و موقعیت مختلف بررسی شود.
مرحله ششم: همگامسازی نهایی اطلاعات سایت
در سایتهای پویا، مانند فروشگاههای اینترنتی، اطلاعات در طول زمان تغییر میکنند.
فرض کنید در فاصله انتقال سایت، یک کاربر سفارش جدیدی ثبت کند یا اطلاعات حساب خود را تغییر دهد.
اگر پایگاه داده سرور قدیمی و جدید بهصورت مستقل فعال باشند، ممکن است بخشی از اطلاعات در یکی از آنها ثبت شود و در دیگری وجود نداشته باشد.
برای جلوگیری از این مشکل، یکی از روشهای زیر باید انتخاب شود:
- تعیین بازه کوتاه برای توقف ثبت اطلاعات جدید و انجام همگامسازی نهایی
- استفاده از Database Replication در زیرساختهای پشتیبانیشده
- استفاده از معماری مهاجرتی که امکان انتقال تغییرات نهایی را فراهم کند
در سایتهای پرتراکنش، این مرحله باید با دقت بیشتری انجام شود.
هدف این است که هنگام تغییر مسیر ترافیک، هیچ سفارش، پرداخت یا اطلاعات کاربری از دست نرود.
پس از انتقال هاست چه تنظیمات سئویی باید بررسی شوند؟
خلاصه پاسخ: پس از انتقال سایت، باید پاسخ HTTP صفحات، فایل robots.txt، تگ Canonical، نقشه سایت، دسترسی Googlebot و عملکرد صفحات مهم بررسی شوند. همچنین باید مطمئن شوید که نسخه جدید دقیقاً همان URLهای قبلی را با محتوای صحیح ارائه میکند و هیچ محدودیت ناخواستهای برای خزش یا ایندکس ایجاد نشده است.
پس از تغییر DNS، کار تمام نشده است. در واقع بخش مهمی از اطمینان از موفقیت مهاجرت در همین مرحله انجام میشود.
بررسی کدهای پاسخ HTTP
صفحات مهم سایت باید پاسخ مناسب دریافت کنند.
| کد HTTP | مفهوم | وضعیت مورد انتظار |
|---|---|---|
| 200 | درخواست موفق | مناسب برای صفحات فعال |
| 301 | انتقال دائمی | فقط برای URLهایی که واقعاً تغییر کردهاند |
| 302 | انتقال موقت | در موارد مشخص و موقت |
| 404 | صفحه پیدا نشد | برای URLهای ناموجود واقعی |
| 403 | دسترسی ممنوع | نیازمند بررسی |
| 500 | خطای داخلی سرور | نیازمند رفع فوری |
| 502 | پاسخ نامعتبر از سرور بالادستی | نیازمند بررسی |
| 503 | سرویس موقتاً در دسترس نیست | فقط در شرایط کنترلشده |
یکی از اشتباهات رایج، استفاده از ریدایرکت ۳۰۱ برای تمام صفحات هنگام تغییر هاست است.
اگر URL تغییر نکرده، نیازی به ریدایرکت نیست و صفحه باید مستقیماً با کد ۲۰۰ پاسخ دهد.
بررسی فایل robots.txt
محتوای فایل robots.txt در هاست جدید باید بررسی شود.
گاهی نسخه آزمایشی سایت با محدودیت خزش منتشر میشود و مدیر سایت فراموش میکند این محدودیت را پس از مهاجرت حذف کند.
برای نمونه:
User-agent: *
Disallow: /
چنین تنظیمی میتواند دسترسی خزندهها به کل سایت را محدود کند.
بنابراین باید مطمئن شوید که فایل robots.txt مطابق سیاست واقعی خزش سایت تنظیم شده است.
بررسی تگ Canonical
تگ Canonical به موتورهای جستجو کمک میکند نسخه اصلی یک صفحه را شناسایی کنند.
اگر هنگام انتقال سایت، تنظیمات Canonical بهاشتباه تغییر کند، ممکن است صفحات به آدرسهای نامرتبط اشاره کنند.
برای مثال، صفحه زیر باید Canonical صحیح خودش را داشته باشد:
اگر سایت پس از انتقال همچنان از همین دامنه و ساختار URL استفاده میکند، بهتر است Canonicalها نیز بدون تغییر غیرضروری حفظ شوند.
بررسی Sitemap و Google Search Console
پس از مهاجرت باید مطمئن شوید نقشه سایت XML همچنان در دسترس است و URLهای معتبر را معرفی میکند.
سپس در Google Search Console موارد زیر را بررسی کنید:
- وضعیت Indexing
- گزارش Page Indexing
- گزارش Crawl Stats
- خطاهای Server Response
- وضعیت Sitemap
- گزارش HTTPS
- عملکرد صفحات مهم
همچنین میتوانید با ابزار URL Inspection چند صفحه مهم را بررسی کنید تا از دسترسی Googlebot و وضعیت ایندکس آنها مطمئن شوید.
نکته مهم این است که پس از تغییر زیرساخت، ممکن است نرخ خزش Googlebot بهصورت موقت تغییر کند. این موضوع لزوماً نشانه افت سئو نیست؛ مهم این است که سرور جدید بدون خطا و با سرعت مناسب پاسخگو باشد.
چرا انتقال سایت ممکن است باعث قطعی یا کاهش رتبه شود؟
خلاصه پاسخ: قطعی سایت معمولاً زمانی رخ میدهد که DNS پیش از آماده شدن سرور جدید تغییر کند، فایلها و پایگاه داده ناقص منتقل شوند یا تنظیمات وبسرور و SSL بهدرستی انجام نشده باشند. کاهش رتبه نیز میتواند در نتیجه مشکلات دسترسی خزندهها، خطاهای مداوم سرور یا تغییر ناخواسته ساختار URL ایجاد شود.
مهمترین خطاهای مهاجرت عبارتاند از:
۱. حذف زودهنگام هاست قبلی
تا زمانی که مطمئن نشدهاید تمام کاربران و خزندهها به سرور جدید هدایت شدهاند، هاست قبلی را حذف نکنید.
۲. انتقال ناقص فایلها
گاهی فایلهای مخفی، پوشه Uploads یا تنظیمات موردنیاز برنامه منتقل نمیشوند و سایت پس از مهاجرت با خطا مواجه میشود.
۳. ناسازگاری نسخه PHP
ممکن است سایت روی PHP ۷.۴ بهدرستی کار کند، اما پس از انتقال به محیطی با PHP ۸.۲ برخی افزونهها یا کدهای قدیمی دچار خطا شوند.
۴. فراموش کردن سرویس ایمیل
انتقال فایلهای سایت الزاماً به معنای انتقال سرویس ایمیل نیست. تنظیمات MX، SPF و DKIM باید جداگانه بررسی شوند.
۵. تغییر ناخواسته آدرسها
اگر هنگام انتقال، آدرس تصاویر، صفحات یا لینکهای داخلی تغییر کنند، ممکن است خطاهای ۴۰۴ و مشکلات Canonical ایجاد شوند.
۶. ظرفیت ناکافی سرور جدید
پس از مهاجرت، ممکن است Googlebot و کاربران همزمان درخواستهای بیشتری به سرور جدید ارسال کنند. بنابراین منابع CPU، RAM و محدودیت پردازشها باید متناسب با بار سایت انتخاب شوند.
چه زمانی میتوان هاست قدیمی را غیرفعال کرد؟
خلاصه پاسخ: زمانی میتوان هاست قبلی را غیرفعال کرد که سرور جدید بهدرستی پاسخ دهد، اطلاعات نهایی سایت منتقل شده باشند، ترافیک کاربران و خزندهها به زیرساخت جدید رسیده باشد و وابستگی باقیماندهای به سرویس قبلی وجود نداشته باشد. صرف تغییر DNS برای حذف فوری هاست قدیمی کافی نیست.
یکی از توصیههای مهم Google در راهنمای تغییر زیرساخت میزبانی این است که تا زمانی که مطمئن نشدهاید کاربران و Googlebot محتوای صحیح را از سرور جدید دریافت میکنند، زیرساخت قبلی را خاموش نکنید.
برای تصمیمگیری، این موارد را بررسی کنید:
- میزان ترافیک ورودی به سرور قدیمی کاهش یافته باشد.
- لاگهای سرور جدید درخواستهای کاربران را ثبت کنند.
- درخواستهای Googlebot به سرور جدید برسند.
- خطاهای 5xx افزایش غیرعادی نداشته باشند.
- فایلها و پایگاه داده بهدرستی منتقل شده باشند.
- سرویس ایمیل و وظایف زمانبندیشده عملکرد صحیح داشته باشند.
- نسخه پشتیبان نهایی و قابل بازیابی در اختیار شما باشد.
در بسیاری از پروژهها، نگهداری هاست قبلی برای چند روز تا یک یا دو هفته پس از مهاجرت، تصمیم محتاطانهای است؛ اما زمان دقیق باید بر اساس میزان ترافیک، وضعیت DNS و لاگهای سرورها تعیین شود.
چکلیست نهایی انتقال سایت به هاست جدید بدون افت سئو
خلاصه پاسخ: برای اطمینان از انتقال موفق، باید پیش از مهاجرت، حین جابهجایی و پس از تغییر DNS، مجموعهای از کنترلهای فنی و سئویی انجام شوند. استفاده از چکلیست باعث میشود هیچ مرحله مهمی مانند بکاپ، تست سرور جدید، بررسی DNS، کنترل پایگاه داده یا ارزیابی دسترسی موتورهای جستجو فراموش نشود.
قبل از انتقال
- تهیه بکاپ کامل از فایلها و پایگاه داده
- ذخیره نسخه بکاپ در محلی خارج از سرور
- ثبت وضعیت سئوی سایت در Search Console
- تهیه فهرست صفحات مهم و پرترافیک
- بررسی منابع و محدودیتهای هاست جدید
- بررسی نسخه PHP و پایگاه داده
- ثبت رکوردهای DNS فعلی
- کاهش TTL در صورت امکان و نیاز
- بررسی وضعیت سرویس ایمیل
هنگام انتقال
- انتقال کامل فایلها
- انتقال پایگاه داده
- بررسی دسترسی فایلها و پوشهها
- تنظیم اطلاعات اتصال پایگاه داده
- بررسی SSL و وبسرور
- آزمایش سایت بدون تغییر DNS
- بررسی فرمها، پرداخت و ورود کاربران
- برنامهریزی برای همگامسازی نهایی اطلاعات
- تغییر کنترلشده رکوردهای DNS
پس از انتقال
- بررسی باز شدن سایت از شبکههای مختلف
- بررسی پاسخ HTTP صفحات مهم
- کنترل Canonical
- بررسی robots.txt
- بررسی Sitemap
- بررسی گزارشهای Google Search Console
- بررسی خطاهای سرور
- بررسی عملکرد ایمیل و Cron Job
- کنترل منابع مصرفی سرور جدید
- نگهداری هاست قبلی تا اطمینان از تکمیل مهاجرت
چگونه بدون آسیب به سئو، زیرساخت سایت را تغییر دهیم؟
انتقال سایت به هاست جدید نباید به معنای شروع دوباره فعالیت سئویی یک وبسایت باشد. اگر URLها، محتوای صفحات، ساختار لینکسازی و تنظیمات فنی بهدرستی حفظ شوند، تغییر زیرساخت میتواند بدون نیاز به بازسازی اعتبار صفحات انجام شود.
مهمترین اصل این است که سرور جدید قبل از دریافت ترافیک اصلی آماده باشد و انتقال اطلاعات با برنامه مشخص انجام شود. همچنین نباید هاست قبلی را صرفاً به دلیل تغییر DNS غیرفعال کرد؛ بلکه باید عملکرد واقعی زیرساخت جدید و دسترسی کاربران و موتورهای جستجو بررسی شود.
در نهایت، انتخاب یک سرویس میزبانی متناسب با منابع موردنیاز سایت، نقش مهمی در پایداری بلندمدت آن دارد. زیرساخت مناسب باید بتواند علاوه بر پاسخگویی به ترافیک فعلی، ظرفیت لازم برای رشد آینده وبسایت را نیز فراهم کند.
اگر قصد دارید وبسایت خود را به یک زیرساخت پایدارتر منتقل کنید، پیش از هر اقدامی منابع موردنیاز، نوع پروژه و امکانات سرویس میزبانی را بررسی کنید. برای آشنایی با سرویسهای میزبانی تاباهاست میتوانید از وبسایت تاباهاست بازدید کنید.
سوالات متداول
آیا تغییر هاست باعث افت رتبه سایت در گوگل میشود؟
خیر، تغییر هاست بهخودیخود عامل جریمه یا افت رتبه نیست. اگر URLها، محتوا و دسترسی موتورهای جستجو حفظ شوند، معمولاً انتقال زیرساخت بدون تغییر اساسی در ساختار سئو انجام میشود. البته اختلال طولانی در دسترسی سایت میتواند بر عملکرد ارگانیک تأثیر منفی بگذارد.
آیا هنگام انتقال سایت به هاست جدید باید ریدایرکت ۳۰۱ انجام دهیم؟
خیر. اگر فقط سرور یا شرکت میزبانی تغییر میکند و آدرس صفحات ثابت است، نیازی به ریدایرکت ۳۰۱ وجود ندارد. این نوع ریدایرکت برای انتقال دائمی یک URL به URL دیگر استفاده میشود.
انتقال سایت به هاست جدید چقدر زمان میبرد؟
مدت زمان انتقال به حجم فایلها، اندازه پایگاه داده، سرعت ارتباط بین سرورها، نوع پروژه و پیچیدگی تنظیمات بستگی دارد. یک سایت ساده ممکن است در مدت کوتاهی منتقل شود، اما فروشگاههای بزرگ و سامانههای پرتراکنش به برنامهریزی و آزمایش بیشتری نیاز دارند.
آیا هنگام انتقال هاست سایت از دسترس خارج میشود؟
الزاماً خیر. با آمادهسازی کامل سرور جدید، آزمایش پیش از تغییر DNS و مدیریت صحیح اطلاعات پویا میتوان قطعی را به حداقل رساند. بااینحال، به دلیل تفاوت رفتار Resolverهای DNS و شرایط زیرساخت، تضمین قطعی صفر در تمام شبکهها ممکن نیست.
آیا پس از انتقال هاست باید Sitemap جدید ثبت کنیم؟
اگر آدرسهای صفحات و دامنه تغییر نکردهاند و نقشه سایت همچنان معتبر است، الزاماً نیازی به ساخت Sitemap جدید نیست. بااینحال، باید دسترسی به نقشه سایت و صحت URLهای آن بررسی شود. در صورت تغییر URLها، نقشه سایت باید مطابق ساختار جدید بهروزرسانی شود.
آیا پس از انتقال هاست باید دامنه را در Google Search Console دوباره ثبت کنیم؟
خیر. اگر دامنه و URLها تغییر نکرده باشند، معمولاً نیازی به ایجاد Property جدید نیست. کافی است دسترسی به Property فعلی، وضعیت خزش و عملکرد صفحات را بررسی کنید.
آیا انتقال هاست میتواند سرعت سایت را افزایش دهد؟
بله، اگر زیرساخت جدید از نظر منابع پردازشی، نوع وبسرور، تنظیمات کش، کیفیت شبکه و زمان پاسخگویی شرایط بهتری داشته باشد، احتمال بهبود عملکرد سایت وجود دارد. البته افزایش سرعت قطعی نیست و به کدنویسی و نحوه پیکربندی سایت نیز بستگی دارد.
بعد از انتقال هاست تا چه زمانی باید هاست قبلی را نگه داریم؟
تا زمانی که اطمینان حاصل شود ترافیک کاربران و خزندهها به سرور جدید منتقل شده، اطلاعات بهدرستی همگامسازی شده و وابستگی مهمی به زیرساخت قبلی باقی نمانده است. در پروژههای حساس، نگهداری موقت هاست قبلی ریسک مهاجرت را کاهش میدهد.
