انتقال سایت به هاست جدید یکی از آن کارهایی است که بیشتر مدیران سایت تا آخرین لحظه عقبش میاندازند — نه چون سخت است، بلکه چون سه ترس بزرگ پشت آن خوابیده: قطعی سایت وسط روز کاری، گمشدن ایمیلها و سقوط رتبه در گوگل. واقعیت این است که هر سه ریسک با یک توالی درست از بین میروند. در این راهنما همان توالی حرفهای را قدمبهقدم میچینیم: پشتیبانگیری کامل، کاهش TTL پیش از هر کاری، انتقال فایل و دیتابیس، تست هاست جدید با ترفند فایل hosts، صدور SSL قبل از تغییر DNS، مدیریت پنجرهی انتشار و چکلیست پس از انتقال — طوری که بازدیدکنندهها اصلاً متوجه جابهجایی نشوند.
چرا تغییر هاست بدون برنامه به قطعی میرسد؟
تقریباً همهی داستانهای تلخ تغییر هاست یک الگوی مشترک دارند: کسی اول DNS را عوض کرده و بعد به فکر بقیهی کارها افتاده است. از لحظهای که رکورد دامنه به آیپی جدید اشاره میکند، بخشی از کاربران به سروری میرسند که هنوز فایل ندارد، دیتابیس ندارد یا گواهی SSL معتبری رویش نصب نیست — و همین یعنی چند ساعت صفحهی خطا، خطای گواهی امنیتی در مرورگر و سفارشهایی که نیمهکاره رها شدهاند.
توالی حرفهای دقیقاً برعکس است: اول همهچیز روی هاست جدید ساخته، تست و امضا میشود؛ تغییر DNS آخرین قدم است، نه اولین قدم. با این ترتیب، در کل فرایند همیشه دستکم یک سرور کاملاً سالم پاسخگوی دامنهی شماست و «قطعی» عملاً از معادله حذف میشود.
یک نکته را هم پیش از شروع روشن کنیم: این راهنما دربارهی «چگونه» است، نه «به کجا». اگر هنوز مقصد را انتخاب نکردهاید، اول تکلیف دو تصمیم بزرگتر را روشن کنید — هاست ایران یا هاست خارج بر اساس محل مخاطبانتان، و هاست اشتراکی یا سرور مجازی بر اساس نیاز فنی پروژه. انتقال به مقصد اشتباه، هر چقدر هم تمیز انجام شود، باز هم انتقال به مقصد اشتباه است.
قدم اول انتقال سایت به هاست جدید: پشتیبانگیری کامل
پشتیبانگیری در این فرایند بیمهنامهی شماست: اگر هر قدمی خراب شد، باید بتوانید بدون بحث و بدون استرس به نقطهی قبل برگردید. «کامل» هم یعنی هر سه جزء سایت، نه فقط فایلها:
- فایلها. کل شاخهی سایت شامل هسته، قالب، افزونهها و مهمتر از همه پوشهی آپلودها. در cPanel ابزار پشتیبانگیری یک آرشیو کامل میسازد؛ در DirectAdmin هم گزینهی مشابهی زیر بخش پشتیبانگیری هست. اگر به SSH دسترسی دارید، یک آرشیو فشرده از کل شاخه سریعتر و قابلاتکاتر است.
- دیتابیس. خروجی کامل با phpMyAdmin یا خط فرمان. برای سایت وردپرسی، دیتابیس یعنی همهی نوشتهها، کاربران، سفارشها و تنظیمات — فایلها بدون آن فقط یک پوستهی خالیاند.
- ایمیل. اگر صندوقهای ایمیل روی همان هاستاند، محتوای آنها جزئی از دارایی شماست. فهرست آدرسها، رمزها و حجم هر صندوق را ثبت کنید و از پیامهای مهم خروجی بگیرید؛ در ادامهی مقاله روش انتقالشان را میگوییم.
دو قاعدهی طلایی را هم رعایت کنید. اول، نسخهی پشتیبان را بیرون از هاست فعلی نگه دارید — روی سیستم خودتان یا یک فضای ابری جدا؛ پشتیبانی که کنار خود سایت خوابیده، در روز مبادا همراه سایت از دسترس خارج میشود. دوم، پشتیبان را باز کنید و امتحان کنید: آرشیوی که سالم استخراج نشود یا فایل SQLای که وسطش بریده باشد، فقط حس امنیت کاذب میدهد. جزئیات ابزارها و راهبرد نگهداری نسخهها را در راهنمای پشتیبانگیری لینوکس کامل نوشتهایم و مستندات رسمی وردپرس هم صفحهی جداگانهای دربارهی پشتیبانگیری دارد.
کاهش TTL؛ کاری که باید ۲۴ تا ۴۸ ساعت قبل از انتقال انجام دهید
هر رکورد DNS یک عدد TTL دارد: مدتی که سرویسهای DNS در سراسر اینترنت اجازه دارند پاسخ را نزد خودشان نگه دارند و دوباره از مبدأ نپرسند. اگر TTL رکورد اصلی سایت شما ۲۴ ساعت باشد، یعنی بعد از تغییر آیپی، بخشی از کاربران تا یک شبانهروز همچنان به آدرس قدیمی فرستاده میشوند — چون پاسخ کهنه هنوز در حافظهی DNS مسیرشان معتبر است.
راهحل ساده اما زمانبر است: پیش از انتقال، TTL رکوردهای A و CNAME دامنه را به عددی کوچک — مثلاً ۳۰۰ ثانیه — کاهش دهید و بعد به اندازهی TTL قبلی صبر کنید تا پاسخهای کهنه در سراسر شبکه منقضی شوند. به همین دلیل این قدم باید ۲۴ تا ۴۸ ساعت قبل از روز انتقال انجام شود؛ اگر همان لحظهی جابهجایی TTL را کم کنید، عملاً هیچ اثری روی همان جابهجایی ندارد. اگر با مفهوم رکوردها و TTL راحت نیستید، راهنمای رکوردهای DNS را قبل از این قدم بخوانید.
انتقال فایلها و دیتابیس به هاست جدید
فایلها
روی هاست جدید، دامنه را اضافه کنید — بیآنکه DNS آن را تغییر داده باشید؛ پنلهای میزبانی برای ساخت اکانت نیازی به اشارهکردن دامنه به خودشان ندارند. سپس آرشیو فایلها را آپلود و همانجا استخراج کنید. انتقال آرشیو فشرده همیشه بر آپلود تکتک فایلها با FTP ترجیح دارد: هم چند برابر سریعتر است و هم ریسک جاافتادن فایلهای مخفی مثل .htaccess — که قواعد ریدایرکت و پیوندهای یکتای سایت به آن وابسته است — عملاً صفر میشود.
دیتابیس
در هاست جدید یک دیتابیس و یک کاربر تازه بسازید و خروجی SQL را وارد کنید. تقریباً همیشه نام دیتابیس و نام کاربر در هاست جدید متفاوت خواهد بود؛ فراموشکردن بهروزرسانی همین چهار مقدار — نام دیتابیس، کاربر، رمز و میزبان دیتابیس — در فایل تنظیمات سایت (برای وردپرس wp-config.php) رایجترین دلیل صفحهی «خطا در اتصال به پایگاه داده» بعد از انتقال است. اگر دامنهی سایت تغییری نمیکند — که در تغییر هاست معمولاً همینطور است — به هیچ جستوجو و جایگزینی درون دیتابیس نیاز ندارید؛ این عملیات مخصوص تغییر آدرس است و اجرای ناشیانهاش روی دادههای سریالایزشده خودش منبع خرابی است.
ایمیل
روی هاست جدید همان صندوقهای ایمیل را با همان آدرسها بسازید. برای محتوای قدیمی دو راه دارید: اتصال همزمان هر دو سرور در یک نرمافزار ایمیل از طریق IMAP و کشیدن پوشهها از حساب قدیمی به جدید، یا استفاده از ابزار انتقال خود پنل اگر مبدأ و مقصد همخانواده باشند. نکتهی مهم، رکوردهای اعتبارسنجی است: هاست جدید کلید DKIM مخصوص خودش را تولید میکند و مقدار SPF متفاوتی میخواهد؛ این رکوردها را باید هنگام تغییر DNS با مقادیر جدید جایگزین کنید، وگرنه ایمیلهای سایت از فردای انتقال راهی پوشهی هرزنامه میشوند.
اگر مبدأ و مقصد هر دو cPanel یا هر دو DirectAdmin باشند، کار از این هم سادهتر است: پشتیبان کامل اکانت — فایل، دیتابیس، ایمیل و تنظیمات DNS با هم — در مقصد بازیابی میشود و بیشتر قدمهای دستی بالا حذف میشوند. جزئیات این قابلیت در مستندات cPanel و مستندات DirectAdmin آمده است. در مهران هاست هم مقصد انتقال معمولاً همین دو پنل است؛ میزبانی اشتراکی با فاکتور ریالی سفارش داده میشود و فهرست بهروز پلنها در صفحهی میزبانی وب در دسترس است.
تست هاست جدید قبل از تغییر DNS — ترفند فایل hosts
اینجا همان قدمی است که حرفهایها را از بقیه جدا میکند: سایت را روی هاست جدید با آدرس واقعی خودش تست کنید، در حالی که دنیا هنوز نسخهی قدیمی را میبیند. ابزار کار، فایل hosts سیستمعامل شماست — فهرستی محلی که قبل از هر پرسوجوی DNS خوانده میشود. کافی است دامنهتان را در این فایل به آیپی هاست جدید گره بزنید تا فقط مرورگر شما به سرور تازه برود:
# Linux / macOS: /etc/hosts (edit with sudo)
# Windows: C:\Windows\System32\drivers\etc\hosts (open the editor as administrator)
203.0.113.10 example.com
203.0.113.10 www.example.comبهجای 203.0.113.10 آیپی هاست جدید و بهجای example.com دامنهی خودتان را بگذارید، مرورگر را کامل ببندید و دوباره باز کنید تا حافظهی DNS آن خالی شود. حالا سایت را مثل یک بازدیدکنندهی سختگیر بگردید: صفحهی اصلی، چند نوشته، جستوجو، فرم تماس، ورود به بخش مدیریت و — اگر فروشگاه دارید — یک خرید آزمایشی کامل. هر خطایی که اینجا پیدا کنید، خطایی است که هیچ کاربری هرگز نخواهد دید. بعد از پایان تست، همان خطها را از فایل hosts پاک کنید. ساختار دقیق این فایل و قواعد نوشتنش در مستندات فایل hosts در man7.org آمده است.
SSL را قبل از جابهجایی صادر کنید، نه بعد از آن
خطای گواهی امنیتی بدترین چهرهی یک انتقال شلخته است، چون مرورگر آن را با هشدار تمامصفحه به کاربر نشان میدهد. مشکل اینجاست که صدور خودکار گواهی در بیشتر پنلها به این وابسته است که دامنه از قبل به همان سرور اشاره کند — چیزی که هنگام تست هنوز اتفاق نیفتاده. دو راهحل تمیز دارید: یا گواهی فعلی و کلید خصوصیاش را از هاست قدیم خارج و در پنل جدید نصب کنید تا لحظهی جابهجایی همان گواهی معتبر پاسخ دهد و بعداً صدور خودکار جایش را بگیرد؛ یا اگر به سرور و خط فرمان دسترسی دارید، گواهی تازه را با اعتبارسنجی DNS — که به محل اشارهی دامنه کاری ندارد — از قبل صادر کنید. روش دوم را با جزئیات در راهنمای نصب SSL رایگان با Certbot نوشتهایم. هر راهی که انتخاب میکنید، معیار یکی است: در لحظهی تغییر DNS، سرور جدید باید با گواهی معتبر پاسخ بدهد.
تغییر DNS بدون داونتایم: مدیریت پنجرهی انتشار
حالا که هاست جدید تستشده و گواهیدار آماده است، رکوردهای A دامنه — و در صورت وجود، رکوردهای www و سابدامینها — را به آیپی جدید تغییر دهید و رکوردهای MX و SPF و DKIM را با مقادیر هاست جدید جایگزین کنید. چون TTL را از قبل کم کردهاید، بیشترِ کاربران ظرف چند دقیقه به سرور تازه میرسند؛ اما «بیشتر» با «همه» فرق دارد. برخی سرویسهای DNS پاسخها را کمی بیش از مجاز نگه میدارند و برخی کاربران پشت شبکههایی با حافظهی سمجترند. بازهی واقعبینانه برای پایان کامل انتشار، چند ساعت تا حداکثر یک شبانهروز است.
در این پنجره، هر دو سرور همزمان بازدیدکننده دارند — و این نکتهای است که برنامهریزی محتوایی میخواهد. کاربری که هنوز به سرور قدیم میرسد اگر نظری ثبت کند یا سفارشی بدهد، آن داده روی دیتابیس قدیمی مینشیند و در نسخهی جدید وجود نخواهد داشت. راهحل حرفهای «فریز» است: از لحظهی گرفتن خروجی نهایی دیتابیس تا پایان انتشار، محتوای تازه منتشر نکنید و اگر فروشگاه دارید، انتقال را به کمترافیکترین ساعت هفته ببرید یا ثبت سفارش را موقتاً با یک پیام محترمانه متوقف کنید. برای ایمیل هم حساب قدیمی را چند روز باز نگه دارید و یکبار دیگر با IMAP سر بزنید؛ پیامهایی که در ساعتهای انتشار به سرور قدیم رسیدهاند باید دستی به صندوق جدید منتقل شوند.
چکلیست بعد از انتقال سایت: سئو، ایمیل و فرمها
روز بعد از جابهجایی، بهجای خیال راحت، این فهرست را یکبار کامل جلو بروید:
- گواهی SSL را از چند دستگاه و شبکهی متفاوت — رایانه، موبایل با اینترنت همراه — بررسی کنید؛ نسخهی www و بدون www هر دو باید بدون هشدار باز شوند.
- فرمها و ایمیلهای تراکنشی را عملاً امتحان کنید: فرم تماس، بازیابی رمز عبور، تأیید سفارش. تحویلشدن ایمیل به صندوق اصلی — نه پوشهی هرزنامه — یعنی رکوردهای SPF و DKIM جدید درست نشستهاند.
- بخشهای پویا — جستوجو، سبد خرید، ورود کاربران، آپلود فایل — را جدا تست کنید؛ خطاهای وابسته به تنظیمات PHP یا ماژولهای سرور معمولاً همینجا خودشان را نشان میدهند.
- سرچ کنسول را چند روز زیر نظر بگیرید: گزارش پوشش ایندکس و خطاهای خزش، اولین جایی است که مشکلات نامرئی — صفحههایی که فقط برای ربات خطا میدهند — آشکار میشود.
- زمان بارگذاری را با محل قبلی مقایسه کنید؛ اگر انتقال به هاست بهتری بوده، همینجا باید خودش را نشان دهد.
و اما نگرانی سئو. خبر خوب این است که گوگل برای جابهجایی سایت بین سرورها، وقتی آدرس صفحهها تغییر نمیکند، راهنمای رسمی مشخصی دارد و تنها اثری که در آن عادی توصیف شده موقت است: افت کوتاهمدت نرخ خزش که طی چند روز برمیگردد. قاعدهی طلایی همین است — ساختار آدرسها را دست نزنید. آدرس هر نوشته، هر دسته و هر تصویر باید بعد از انتقال دقیقاً همان باشد که قبل بود. اگر به هر دلیل مجبور به تغییر ساختار هستید — مثلاً حذف یک پیشوند قدیمی از مسیرها — این کار را با انتقال همزمان نکنید: اول جابهجایی سرور را تمام و تثبیت کنید، بعد در قدمی جدا، نقشهی کامل آدرسهای قدیم به جدید را با ریدایرکت ۳۰۱ پیاده کنید تا اعتبار هر صفحه به آدرس تازهاش منتقل شود. دو تغییر بزرگ همزمان یعنی وقتی چیزی خراب شد، ندانید مقصر کدام است.
اشتباههای رایج در تغییر هاست — و راه درست هرکدام
جمعبندی تجربهی انتقالهای خرابشده در یک جدول:
| اشتباه رایج | پیامد | راه درست |
|---|---|---|
| تغییر DNS قبل از آمادهشدن هاست جدید | قطعی واقعی و خطای SSL برای کاربران | تغییر DNS همیشه آخرین قدم است |
| پشتیبانگیری فقط از فایلها | سایتی بدون محتوا، کاربر و سفارش | فایل + دیتابیس + ایمیل، با تست بازگردانی |
| کمنکردن TTL از ۲۴ تا ۴۸ ساعت قبل | پنجرهی انتشار طولانی و دوسروری کشدار | کاهش TTL به ۳۰۰ ثانیه، دو روز قبل از انتقال |
| تستنکردن با فایل hosts پیش از جابهجایی | کشف خطاها بعد از دیدهشدن توسط کاربران | تست کامل سایت روی آیپی جدید از سیستم خودتان |
| انتشار محتوا یا پذیرش سفارش در پنجرهی انتشار | دادههای گمشده روی دیتابیس قدیمی | فریز محتوا از خروجی نهایی تا پایان انتشار |
| فراموشکردن رکوردهای MX و SPF و DKIM | ایمیلهای ارسالی در هرزنامه، دریافتیها سرگردان | جایگزینی رکوردهای ایمیل با مقادیر هاست جدید |
| تغییر ساختار آدرسها همزمان با انتقال | افت سئو و سردرگمی در ریشهیابی | اول انتقال و تثبیت؛ تغییر آدرسها جدا و با نقشهی ۳۰۱ |
| لغو فوری هاست قدیمی | ازدسترفتن راه بازگشت و ایمیلهای در راه | نگهداشتن مبدأ تا یک تا دو هفته پس از انتقال |
اگر این جدول را به یک جمله خلاصه کنیم: عجله نکنید و ترتیب را به هم نزنید. کل فرایند برای یک سایت معمولی چند ساعت کار مؤثر است که روی دو سه روز پخش میشود — و همان پخششدن روی چند روز است که «بدون قطعی» را ممکن میکند. اگر مقصد انتقال شما میزبانی اشتراکی cPanel یا DirectAdmin با فاکتور ریالی است، فهرست بهروز پلنها در صفحهی میزبانی وب مهران هاست را ببینید؛ تحویل سرویس پس از پرداخت فاکتور خودکار است و میتوانید اکانت مقصد را همین امروز، بیآنکه به سایت فعلیتان دست بزنید، آماده کنید.
سؤالات پرتکرار
انتقال سایت به هاست جدید چقدر طول میکشد؟
کار مؤثر برای یک سایت معمولی چند ساعت بیشتر نیست: آمادهسازی اکانت، انتقال فایل و دیتابیس و تست. اما فرایند درست روی دو تا سه روز پخش میشود، چون کاهش TTL باید ۲۴ تا ۴۸ ساعت قبل از جابهجایی انجام شده باشد و بعد از تغییر DNS هم چند ساعت تا یک شبانهروز برای انتشار کامل لازم است. این کشآمدن زمان، هزینهی واقعی «بدون قطعی» بودن است.
آیا هنگام تغییر هاست، سایت از دسترس خارج میشود؟
اگر ترتیب درست را رعایت کنید، نه. رمز کار این است که تغییر DNS آخرین قدم باشد: تا پیش از آن همهی کاربران نسخهی سالم قدیمی را میبینند و پس از آن به نسخهی از قبل تستشده و گواهیدار جدید میرسند. در پنجرهی انتشار هر دو سرور همزمان پاسخ میدهند، پس هیچ لحظهای بدون سرورِ آماده نمیماند؛ فقط باید در همین بازه محتوای تازه و سفارش جدید را متوقف کرده باشید.
برای انتقال وردپرس به هاست جدید چه چیزهایی باید منتقل شود؟
سه جزء: همهی فایلها شامل هسته، قالب، افزونهها و پوشهی آپلودها؛ خروجی کامل دیتابیس که نوشتهها، کاربران و تنظیمات در آن است؛ و صندوقهای ایمیل اگر روی همان هاستاند. بعد از وارد کردن دیتابیس در مقصد، مشخصات اتصال را در فایل تنظیمات وردپرس بهروز کنید. تا وقتی دامنهی سایت عوض نمیشود، به جستوجو و جایگزینی درون دیتابیس نیازی نیست.
آیا تغییر هاست به سئوی سایت آسیب میزند؟
بهخودیخود نه. راهنمای رسمی گوگل برای جابهجایی سایت بدون تغییر آدرس صفحهها تنها یک اثر موقت را عادی میداند: افت کوتاهمدت نرخ خزش که طی چند روز برمیگردد. آسیب از جای دیگری میآید: قطعی طولانی هنگام جابهجایی، تغییر همزمان ساختار آدرسها بدون ریدایرکت ۳۰۱، یا کندتر بودن هاست جدید. اگر آدرسها ثابت بمانند و انتقال بدون قطعی انجام شود، از نظر گوگل فقط آیپی سایت عوض شده است.
ایمیلهای هاست قبلی در انتقال چه میشوند؟
خودشان منتقل نمیشوند؛ باید صندوقها را با همان آدرسها روی هاست جدید بسازید و محتوای قدیمی را با اتصال همزمان دو سرور از طریق IMAP جابهجا کنید. رکوردهای MX و SPF و DKIM را هم هنگام تغییر DNS با مقادیر هاست جدید جایگزین کنید. حساب قدیمی را چند روز باز نگه دارید، چون پیامهایی که در ساعتهای انتشار به سرور قدیم میرسند باید دستی به صندوق جدید بیایند.