انتقال هاست بدون قطعی؛ تکلیف سفارش و ایمیل چیست؟
هنگام جابه‌جایی سایت، ممکن است ظاهر همه‌چیز درست باشد اما سفارشها و ایمیلهای تازه در سرویس قبلی باقی بمانند. این راهنما مراحل انتقال، آزمون‌های ضروری و زمان مناسب لغو هاست قبلی را توضیح می‌دهد.
انتقال هاست برای خیلی از صاحبان سایت با یک نگرانی شروع می‌شود: اگر موقع جابه‌جایی، مشتری سفارش بدهد یا ایمیل مهمی برسد، چه اتفاقی می‌افتد؟ این نگرانی بی‌دلیل نیست؛ ممکن است سایت روی سرویس جدید کاملاً سالم دیده شود، اما بخشی از اطلاعات تازه هنوز در سرویس قبلی مانده باشد.
جابه‌جایی موفق فقط به معنی باز شدن صفحه اصلی نیست. باید مطمئن شوید اطلاعات کامل منتقل شده، خرید و فرم‌ها کار می‌کنند، ایمیلها به مقصد درست می‌رسند و سایت قدیمی دیگر اطلاعات تازه و جداگانه‌ای دریافت نمی‌کند. در این راهنما فرض می‌کنیم نام دامنه و نشانی صفحات ثابت می‌مانند و فقط محل میزبانی عوض می‌شود.
آیا انتقال هاست بدون حتی یک لحظه قطعی ممکن است؟
از نظر فنی، در بعضی زیرساخت‌ها می‌توان جابه‌جایی را بدون وقفه محسوس انجام داد؛ اما این نتیجه با کپی ساده فایلها تضمین نمی‌شود. سایت معرفی خدماتی که به‌ندرت تغییر میکند، با فروشگاهی که پیوسته سفارش و پرداخت دارد، شرایط یکسانی ندارد.
برای یک فروشگاه کوچک، راه عملی می‌تواند توقف کوتاه و برنامه‌ریزی‌شده ثبت اطلاعات تازه باشد. برای سامانه‌ای که نباید متوقف شود، مسئول فنی باید روش همگام‌سازی داده‌ها و هدایت درخواست‌ها را طراحی کند. وعده «بدون قطعی» زمانی معنا دارد که معلوم باشد منظور فقط نمایش صفحات است یا ثبت سفارش و پرداخت هم پیوسته ادامه پیدا میکند.
پیش از شروع، از مجری بپرسید: «در فاصله آخرین کپی تا تکمیل جابه‌جایی، اطلاعات جدید کجا ثبت می‌شود؟» پاسخ همین سؤال، بسیاری از ابهام‌ها را روشن میکند.
تغییر هاست با انتقال دامنه چه تفاوتی دارد؟
دامنه، نامی است که مشتری وارد میکند؛ هاست، محیطی است که سایت روی آن اجرا می‌شود. برای عوض کردن میزبان، معمولاً نیازی نیست شرکت ثبتکننده دامنه یا مالکیت آن را تغییر دهید. کافی است تنظیمات مربوط به مقصد سایت به‌درستی بهروز شوند.
DNS سامانه‌ای است که نام‌ها را به اطلاعاتی مانند نشانی سرور مرتبط میکند. نیم‌سرورها نیز مشخص می‌کنند پاسخهای اصلی DNS دامنه از کجا دریافت شوند. ممکن است با تغییر یک رکورد، سایت به مقصد تازه برود؛ بدون اینکه لازم باشد نیم‌سرورها عوض شوند.
| کاری که انجام می‌دهید | چه چیزی تغییر میکند؟ | آیا به‌تنهایی فایل و اطلاعات را منتقل میکند؟ |
|---|---|---|
| کپی سایت به هاست جدید | محل یک نسخه از فایلها و پایگاه داده | بله، در محدوده اطلاعاتی که کپی شدهاند |
| تغییر رکورد مقصد سایت | مسیر مراجعه به وب‌سایت | خیر |
| تغییر نیم‌سرورها | سرویس پاسخ‌گوی اصلی DNS | خیر |
| انتقال دامنه به ثبتکننده دیگر | شرکت مدیریت ثبت و تمدید دامنه | خیر |
| تغییر رکورد ایمیل | مقصد دریافت پیامهای جدید | خیر؛ پیامهای قبلی جدا منتقل میشوند |
اگر DNS فعلی مستقل از هاست قبلی است، ممکن است بتوانید آن را نگه دارید. اگر همراه همان هاست ارائه می‌شود، پیش از لغو سرویس بپرسید آیا همچنان فعال می‌ماند. باقی ماندن سایت روی سرور جدید، از خاموش شدن ناخواسته DNS جلوگیری نمی‌کند.
پیش از شروع، دقیقاً چه چیزهایی را فهرست کنیم؟
بزرگ‌ترین اشتباه این است که «سایت» را فقط چند پوشه بدانیم. پیش از جابه‌جایی، فهرستی از سرویس‌های متصل تهیه کنید و برای هرکدام مشخص کنید چه کسی انتقال و آزمایش آن را انجام می‌دهد.
- فایلها، تصاویر و پایگاه داده؛ یعنی محل نگهداری اطلاعاتی مانند سفارشها، کاربران و تنظیمات.
- زیردامنه‌ها و بخش‌های جداگانه، مثل فروشگاه، پنل مشتریان یا سامانه پشتیبانی.
- صندوقهای ایمیل، پیامهای قبلی، نام‌های مستعار و ارسال خودکار به نشانی دیگر.
- گواهی امنیتی برای باز شدن دامنه با HTTPS.
- کارهای زمان‌بندی‌شده، مانند ساخت گزارش یا همگام‌سازی موجودی.
- اتصال به درگاه پرداخت، پیامک، انبارداری و نرم‌افزارهای دیگر.
- رکوردهای DNS و اطلاعات تأیید مالکیت سرویس‌هایی مانند سرچ کنسول.
همچنین روشن کنید آیا سرویس بیرونی به نشانی IP قبلی اجازه دسترسی داده است. ممکن است سایت جدید سالم باشد، اما اتصال آن به یک سامانه دیگر به‌دلیل تغییر IP رد شود. این مورد را باید با ارائه‌دهنده همان اتصال بررسی کرد.
خطر پنهان: دو نسخه سالم با اطلاعات متفاوت
فرض کنید صبح از فروشگاه نسخه کپی می‌گیرید و عصر تنظیمات مقصد را عوض میکنید. در این فاصله، چند مشتری در سایت قبلی خرید کرده‌اند. نسخه صبح طبیعتاً این سفارشها را ندارد؛ مگر اینکه تغییرات بعدی هم منتقل شوند.
حالا اگر بخشی از کاربران به نسخه قدیمی و بخشی به نسخه جدید برسند، احتمال ثبت اطلاعات در دو محل وجود دارد. ظاهر هر دو سایت درست است، ولی سفارشها، موجودی یا حساب‌های کاربری آن‌ها یکسان نیستند. این اختلاف با یک بار دیگر کپی کردن تصادفی پایگاه داده حل نمی‌شود؛ ممکن است اطلاعات تازه مقصد را از بین ببرید.
راه‌حل، مشخص کردن یک محل معتبر برای ثبت اطلاعات تازه است. مجری باید بداند از چه لحظه‌ای نسخه قدیمی دیگر سفارش مستقل نمی‌گیرد و درخواست‌هایی که هنوز به آن می‌رسند چگونه مدیریت میشوند. صرفاً روشن گذاشتن هر دو نسخه، تضمین حفظ اطلاعات نیست.
نکته: تغییر DNS اطلاعات دو سرور را با هم یکی نمی‌کند. اگر در هر دو نسخه سفارش ثبت شده باشد، ابتدا باید اختلاف داده‌ها بررسی و رفع شود.
مراحل انتقال هاست با کمترین اختلال
۱. مقصد را از نظر سازگاری بررسی کنید
پیش از انتقال، نیازهای سایت را با امکانات سرویس جدید تطبیق دهید. برای وردپرس، نسخه PHP، افزونه‌های مورد نیاز سرور و تنظیمات پایگاه داده اهمیت دارند؛ PHP زبان اصلی اجرای وردپرس است. مسئول فنی باید مشخص کند نسخه موجود سایت در مقصد قابل اجراست.
بهتر است هم‌زمان با جابه‌جایی، تغییر قالب، بازطراحی و چند ارتقای بزرگ را انجام ندهید. اگر مشکلی پیش بیاید، تشخیص علت دشوار می‌شود. ابتدا همان سایت را سالم منتقل کنید و تغییرهای دیگر را جداگانه پیش ببرید.
۲. نسخه پشتیبان مستقل بگیرید
از فایلها و پایگاه داده نسخه پشتیبان داشته باشید و آن را فقط روی هاستی که قصد لغوش را دارید نگه ندارید. اگر ایمیل هم جابه‌جا می‌شود، مطمئن شوید پیامها در برنامه پشتیبان‌گیری پوشش داده شدهاند؛ خروجی یک افزونه وردپرس الزاماً نسخه پشتیبان ایمیل نیست.
فایل پشتیبان باید قابل بازیابی باشد. از مجری بخواهید تأیید کند آن را باز کرده یا در محیط آزمایشی بازیابی کرده است. دیدن نام یک فایل فشرده، سالم بودن محتویاتش را ثابت نمی‌کند.
۳. نسخه مقصد را قبل از تغییر مسیر آزمایش کنید
یک نسخه از سایت را در هاست جدید راه‌اندازی کنید و دسترسی آزمایشی بگیرید. مسئول فنی می‌تواند کاری کند که فقط رایانه آزمایش‌کننده، دامنه اصلی را از سرور جدید باز کند؛ کاربران دیگر همچنان سایت فعلی را می‌بینند.
صفحه اصلی، چند محصول یا مقاله، جست‌وجو، ورود کاربر، فرم تماس و تصاویر را بررسی کنید. محیط آزمایشی نباید ناخواسته پیامک، ایمیل یا درخواست واقعی به سامانه انبار بفرستد. آزمون پرداخت را نیز با روش آزمایشی مورد تأیید درگاه انجام دهید.
۴. تکلیف تغییرات لحظه آخر را مشخص کنید
برای سایتی که اطلاعات تازه می‌گیرد، زمان آخرین همگام‌سازی را تعیین کنید. در روش ساده‌تر، ثبت سفارش و سایر تغییرات برای مدت کوتاهی متوقف می‌شود، دادههای نهایی منتقل میشوند و پس از تأیید مقصد، فعالیت از سر گرفته می‌شود.
این توقف فقط بستن دکمه خرید نیست. پرداخت‌های در جریان، پیام تأیید درگاه، عضویت کاربران و تغییرات مدیر سایت هم باید در برنامه باشند. برای پرداخت‌های ناتمام، مسئول مشخصی تعیین کنید تا نتیجه درگاه با وضعیت سفارش تطبیق داده شود.
۵. مسیر سایت را تغییر دهید و نسخه قدیمی را کنترل کنید
پس از تأیید نسخه نهایی، رکوردهای لازم تغییر می‌کنند. نسخه قدیمی نباید دوباره به فروشگاهی مستقل تبدیل شود. بسته به زیرساخت، ممکن است درخواست‌ها به مقصد جدید هدایت شوند یا امکان ثبت اطلاعات در مبدأ بسته بماند؛ انتخاب روش با مسئول فنی است.
از مجری بخواهید روش برخورد با کاربری را که هنوز به سرور قبلی می‌رسد توضیح دهد. این بخش باید پیش از تغییر تنظیمات آماده باشد، نه زمانی که اولین سفارش گم‌شده گزارش می‌شود.
۶. نتیجه را با اطلاعات واقعی تطبیق دهید
چند سفارش آخر، وضعیت پرداخت، موجودی کالا و حساب‌های تازه را با سوابق پیش از انتقال مقایسه کنید. پیام موفقیت ابزار انتقال کافی نیست. برای سایت خدماتی نیز فرم‌ها را امتحان کنید و مطمئن شوید درخواست واقعاً به دست مسئول مربوط می‌رسد.
چرا بعد از تغییر DNS همه یک نسخه را نمی‌بینند؟
پاسخهای DNS برای مدتی در حافظه موقت نگهداری میشوند. TTL مدت اعتبار این پاسخ ذخیره‌شده را مشخص میکند. در نتیجه ممکن است دستگاه یا شبکه‌ای هنوز مقصد قبلی را بشناسد و شبکه دیگری اطلاعات تازه را گرفته باشد.
پایین آوردن TTL باید پیشاپیش انجام شود؛ تغییر آن در لحظه جابه‌جایی، پاسخ‌هایی را که قبلاً با زمان اعتبار طولانی ذخیره شدهاند فوراً پاک نمی‌کند. توضیح این سازوکار در مستندات رسمی TTL در Cloudflare آمده است.
تغییر رکورد یک سایت با تغییر نیم‌سرور یکسان نیست و زمان ذخیره شدن اطلاعات مربوط به آن‌ها می‌تواند متفاوت باشد. بنابراین عبارت «کمی صبر کنید» جای بررسی را نمی‌گیرد. ابتدا باید معلوم شود رکورد درست است و مشکل فقط از اطلاعات ذخیره‌شده قبلی است.
اگر پس از تغییر، سایت برای بعضی کاربران باز نمی‌شود، از مسئول فنی بخواهید رکوردهای IPv4 و IPv6، با نام‌های A و AAAA، را هم بررسی کند. اگر نیم‌سرورها عوض شدهاند و DNSSEC فعال بوده، تنظیمات اعتبارسنجی آن نیز باید با مقصد هماهنگ باشد؛ باقی ماندن اطلاعات ناسازگار می‌تواند پاسخ DNS را نامعتبر کند.
هنگام جابه‌جایی سایت، چه بلایی سر ایمیلها می‌آید؟
پاسخ به این بستگی دارد که ایمیل کجا میزبانی می‌شود. اگر سرویس ایمیل مستقل دارید و فقط مقصد وب‌سایت تغییر میکند، ممکن است اصلاً نیازی به انتقال صندوق‌ها نباشد. بااین‌حال، هنگام تغییر نیم‌سرورها باید رکوردهای ایمیل را هم در DNS جدید حفظ کنید.
اگر ایمیل روی هاست قبلی است و قرار است آن سرویس لغو شود، جابه‌جایی صندوق‌ها یک کار جداگانه است. MX رکوردی است که مقصد دریافت ایمیل را معرفی میکند؛ تغییر آن، پیامهای قدیمی را از یک صندوق به صندوق دیگر کپی نمی‌کند.
پیش از تغییر مسیر دریافت، صندوقهای مقصد را بسازید و روش انتقال پیامها را تعیین کنید. یکی از روش‌ها همگام‌سازی با IMAP است؛ پروتکلی که برنامه‌های ایمیل از طریق آن به پیامهای ذخیره‌شده روی سرور دسترسی دارند. ابزار و روش انتخابی باید با هر دو سرویس سازگار باشد.
در دوره گذار، ممکن است پیامهایی هنوز به سرویس قدیمی برسند. بنابراین انتقال اولیه را پایان کار ندانید؛ بررسی و همگام‌سازی نهایی پیامهای تازه هم لازم است. پوشه‌های ارسال‌شده و پوشه‌های شخصی کاربران را نیز فراموش نکنید.
پس از انتقال، از یک نشانی خارج از دامنه به صندوق خودتان پیام بفرستید و پاسخ بدهید. ارسال از فرم سایت را جداگانه آزمایش کنید؛ ممکن است صندوق کار کند، اما تنظیمات ارسال برنامه هنوز به سرور قبلی وابسته باشد. در cPanel نیز مسیریابی محلی یا خارجی ایمیل باید متناسب با محل واقعی سرویس تنظیم شود.
از مجری بخواهید تنظیمات احراز اصالت ایمیل، شامل SPF، DKIM و DMARC را با سرویس نهایی تطبیق دهد. این تنظیمات به گیرنده کمک می‌کنند اعتبار فرستنده را بررسی کند؛ نباید صرفاً برای راه افتادن ارسال حذف شوند.
آیا عوض کردن میزبان به سئو آسیب می‌زند؟
اگر دامنه و نشانی صفحات ثابت‌اند، موضوع با تغییر آدرس سایت فرق دارد. فقط به‌دلیل عوض شدن سرور، نباید برای تمام صفحات آدرس تازه یا انتقال ۳۰۱ تعریف کنید. هدف این است که همان صفحه‌ها از زیرساخت جدید درست در دسترس بمانند.
در راهنمای رسمی گوگل برای تغییر میزبانی، آماده‌سازی و آزمایش مقصد، بررسی دسترسی خزنده و پایش سرویس قدیمی و جدید توصیه شده است. گوگل همچنین تغییر موقت در نرخ خزش را پس از جابه‌جایی طبیعی می‌داند؛ این موضوع به‌تنهایی به معنی افت رتبه نیست.
اگر برای نسخه آزمایشی محدودیت دسترسی یا دستور noindex گذاشته‌اید، پیش از عمومی شدن نسخه نهایی آن را بازبینی کنید. noindex دستوری برای جلوگیری از نمایش صفحه در نتایج جست‌وجو است. باقی ماندن ناخواسته آن، مشکلی جدا از کیفیت هاست ایجاد میکند.
چه زمانی می‌توانیم هاست قبلی را لغو کنیم؟
وقتی سایت روی گوشی شما باز شد، هنوز برای تصمیم قطعی زود است. لغو سرویس باید بعد از بررسی وابستگی‌ها و داده‌ها انجام شود، نه صرفاً پس از گذشت یک زمان ثابت.
| مورد بررسی | نشانه آمادگی برای لغو سرویس قبلی |
|---|---|
| وب‌سایت | مراجعه واقعی دیگر به نسخه قدیمی وابسته نیست |
| سفارش و فرم | دادههای آخر تطبیق داده شده و ثبت تازه در مقصد انجام می‌شود |
| ایمیل | پیامهای لازم منتقل شده و دریافت و ارسال مقصد تأیید شده است |
| DNS | لغو حساب قدیمی، سرویس پاسخ‌گوی دامنه را خاموش نمی‌کند |
| فایل و پشتیبان | نسخه مستقل و قابل بازیابی در دسترس است |
| کارهای خودکار | وظایف ضروری در مقصد فعال‌اند و دوبار اجرا نمی‌شوند |
برنامه بازگشت را هم مشخص کنید. اگر بعد از شروع فعالیت در مقصد مشکلی پیدا شد، برگرداندن DNS به مبدأ لزوماً بازگشت امنی نیست؛ چون سفارشها و تغییرات جدید ممکن است فقط در مقصد باشند. ابتدا باید معلوم شود این اطلاعات چگونه حفظ میشوند.
برای آشنایی بیشتر با تنظیمات سرویس، بخش راهنمای هاست سی‌پنل را ببینید. مطالب مربوط به مدیریت نام و تنظیمات دامنه نیز در راهنمای دامنه قرار دارند.
برای هماهنگی با مجری، چهار پاسخ را کتبی بگیرید: چه چیزهایی منتقل میشوند، ثبت اطلاعات تازه چگونه کنترل می‌شود، چه آزمون‌هایی انجام میشوند و چه کسی پایان کار را تأیید میکند. این توافق ساده، معیار تحویل را از «سایت باز می‌شود» به «سایت و خدمات وابسته درست کار می‌کنند» تبدیل میکند.
سوالات متداول
انتقال هاست چقدر طول میکشد؟
زمان آن به حجم فایلها، پایگاه داده، تعداد صندوقهای ایمیل و روش کنترل تغییرات تازه بستگی دارد. زمان کپی اطلاعات و زمان بهروز شدن پاسخهای DNS را باید جدا در نظر گرفت.
آیا لازم است دامنه را هم به شرکت جدید منتقل کنم؟
معمولاً خیر؛ میتوانید دامنه را نزد ثبتکننده فعلی نگه دارید و مقصد سایت را تغییر دهید. فقط مطمئن شوید مدیریت DNS به سرویسی که لغو میکنید وابسته نمیماند.
آیا سفارش‌های جدید خودکار به هاست تازه منتقل میشوند؟
خیر؛ نسخه کپی فقط اطلاعاتی را دارد که هنگام تهیه آن منتقل شدهاند. سفارش‌های بعدی به همگام‌سازی یا برنامه مشخص برای توقف و ازسرگیری ثبت اطلاعات نیاز دارند.
آیا با تغییر MX، ایمیلهای قبلی هم منتقل میشوند؟
خیر؛ MX مسیر دریافت پیامها را مشخص میکند. پیامهای قبلی و پیامهایی که در دوره گذار به سرور قدیمی رسیدهاند، باید جداگانه منتقل یا همگام شوند.
چرا من سایت جدید را می‌بینم ولی همکارم نسخه قبلی را می‌بیند؟
ممکن است پاسخ قدیمی DNS یا محتوای قبلی در حافظه موقت مانده باشد. ابتدا باید مقصد واقعی درخواست و درستی تنظیمات بررسی شود؛ پاک کردن کش مرورگر همه انواع این مشکل را حل نمی‌کند.
آیا پس از انتقال میتوانم فوراً هاست قبلی را حذف کنم؟
خیر؛ ابتدا سفارشها، ایمیلها، وابستگیهای DNS و نسخه پشتیبان را بررسی کنید. وقتی سرویس قبلی دیگر نقش ضروری ندارد و دادههای تازه آن هم تطبیق داده شدهاند، لغو آن منطقی است.
