از هاست فعلی راضی نیستید؛ سایت کند است، پشتیبانی جواب نمیدهد یا با طراح قبلی به بنبست رسیدهاید. اما بیشتر دردسرهای انتقال سایت به هاست جدید از خود جابهجایی نیست؛ از اینجاست که صاحب سایت پیش از شروع، کلید همهٔ درها را در دست ندارد.
این راهنما سه بخش دارد: پس گرفتن کنترل، خود جابهجایی با کمترین قطعی، و حفظ سئو و پایش بعد از انتقال. چه کار را خودتان انجام دهید چه به شرکت پشتیبانی جدیدی بسپارید، باید بدانید چه چیزی را بخواهید و چه چیزی را چک کنید.
پیش از هر کار: چه چیزهایی باید مال خودتان باشد؟
سایت فقط چند فایل روی یک سرور نیست؛ مجموعهای از حسابهاست که اگر یکیشان دست کس دیگری بماند، انتقال نیمهکاره میماند یا چیزی بیصدا از کار میافتد. پیش از تغییر شرکت پشتیبانی سایت، این فهرست را کامل کنید:
- حساب ثبتکنندهٔ دامنه (برای .ir پنل ایرنیک) و ایمیلی که آن حساب به آن وصل است. اگر ایمیل بازیابی مال طراح قبلی باشد، عملاً دامنه هنوز دست اوست.
- پنل هاست (cPanel، DirectAdmin یا پنل شرکت میزبان) و حساب کاربری نزد خود شرکت هاستینگ.
- مدیریت DNS؛ گاهی DNS در سرویسی مثل Cloudflare یا ArvanCloud روی حساب شخص دیگری است.
- پایگاه داده و مشخصات دسترسی به آن.
- کد منبع یا مخزن کد برای سایت اختصاصی؛ برای وردپرس، لایسنس قالب و افزونههای پولی و حسابی که با آن خریداری شدهاند.
- حساب مدیر کل سایت با ایمیل خودتان.
- Google Search Console و Google Analytics با دسترسی مالک (Owner)، نه فقط کاربر.
- حسابهای ایمیل سازمانی و رمز آنها.
- حساب درگاه پرداخت و پنل اینماد؛ ببینید ایمیل و موبایل ثبتشده در آنها مال کیست.
- پنل پیامک و کلید API آن.
قاعدهٔ ساده: هر جا ورود با ایمیل یا موبایل طراح انجام میشود، آن دارایی هنوز کامل مال شما نیست.
تحویل گرفتن سایت از طراح قبلی؛ مؤدبانه و مکتوب
حتی اگر ناراضی هستید، با لحن آرام شروع کنید؛ دعوا فقط کار را کند میکند. درخواست را مکتوب بفرستید (ایمیل یا پیامرسانی که سابقهاش میماند) و در آن بیاورید:
- فهرست دقیق دسترسیها، مطابق بخش قبل.
- تغییر ایمیل بازیابی حسابها به ایمیل شما.
- یک بکاپ کامل فعلی (فایلها و پایگاه داده) با تاریخ.
- نکتههای فنی که فقط او میداند: کرانجابها، تنظیمات خاص سرور، سرویسهای بیرونی وصل به سایت.
- یک مهلت منطقی و تشکر بابت همکاری.
اگر بدهی باز دارید، اول آن را روشن کنید؛ طبیعی است که طراح پیش از تسویه، کد را تحویل ندهد. پس از تحویل، همهٔ رمزها را خودتان عوض کنید، کاربران اضافهٔ سایت و هاست را حذف کنید و کلیدهای API را از نو بسازید.
اگر دامنه به نام طراح قبلی ثبت شده باشد
این خطرناکترین حالت است. از نظر ثبتکننده، صاحب دامنه کسی است که دامنه به نامش ثبت شده، نه کسی که هزینهاش را داده. قدم اول، درخواست مکتوب انتقال مالکیت دامنه است؛ اگر همکاری نشد، مدارک پرداخت و قرارداد به کارتان میآید. جزئیات این موضوع و بندهایی که باید از اول در قرارداد باشد در مقالهٔ قرارداد طراحی سایت آمده است. تا مالکیت دامنه روشن نشده، سراغ انتقال نروید.
بکاپ کامل، بازگردانی آزمایشی و انتخاب هاست
بکاپی که هرگز بازگردانی نشده، فقط یک امید است. دو چیز لازم دارید: نسخهٔ کامل فایلها (شامل پوشهٔ آپلودها، فایل تنظیمات مثل wp-config.php یا .env و فایل .htaccess) و خروجی کامل پایگاه داده. بکاپ را بیرون از هاست فعلی نگه دارید و یکبار روی محیطی جدا بازگردانی کنید تا مطمئن شوید سالم است. روال بکاپ منظم را در چکلیست نگهداری وردپرس ببینید. اگر احتمال میدهید سایت آلوده است، پیش از انتقال پاکش کنید، وگرنه آلودگی را هم با خود میبرید (بازیابی سایت هکشده).
انتخاب میزبان را در راهنمای دامنه و هاست جدا توضیح دادهایم. سه نکتهٔ مخصوص انتقال:
- نسخهٔ PHP و پایگاه دادهٔ هاست جدید باید با سایت فعلی سازگار باشد؛ نسخههای فعلی را از هاست قدیم یادداشت کنید.
- اگر درگاه پرداخت داخلی دارید، پیش از انتخاب هاست خارج از ایران از شرکت پرداخت بپرسید درخواست از IP خارجی را میپذیرد یا نه.
- هاست قدیم را همزمان با خرید هاست جدید لغو نکنید؛ چند روز به هر دو نیاز دارید.
کپی فایلها و پایگاه داده، سپس تست پیش از تغییر DNS
فایلها را به هاست جدید منتقل کنید، پایگاه دادهٔ خالی بسازید، خروجی را در آن وارد کنید و مشخصات اتصال را در فایل تنظیمات بهروز کنید. دو نکته زیاد جا میافتد: پوشهٔ آپلود باید قابلنوشتن باشد، و کدگذاری پایگاه داده (utf8mb4) باید حفظ شود، وگرنه متن فارسی به علامت سؤال تبدیل میشود.
پیش از اینکه حتی یک بازدیدکننده به هاست جدید برسد، خودتان سایت را آنجا ببینید. بهترین راه فایل hosts است: روی کامپیوتر خودتان به سیستم میگویید دامنه را به IP هاست جدید ببرد. اینطور فقط شما سایت را از سرور جدید میبینید، با دامنهٔ واقعیاش. آدرس موقتی که برخی هاستها میدهند هم کار میکند، اما وردپرس معمولاً شما را به دامنهٔ اصلی برمیگرداند.
همهچیز را واقعاً امتحان کنید: صفحههای داخلی، جستوجو، فرم تماس، ورود، سبد خرید و پنل مدیریت. هر خطایی را همینجا رفع کنید، نه بعد از تغییر DNS.
TTL را از قبل پایین بیاورید، بعد DNS را عوض کنید
TTL میگوید سرورهای DNS دنیا پاسخ قبلی را تا چه مدت نگه دارند. اگر TTL شما چند ساعت باشد، پس از تغییر IP بخشی از کاربران تا همان مدت به سرور قدیم میروند. پس یکی دو روز پیش از انتقال، TTL رکوردهای A و www را به عددی کوتاه مثل ۳۰۰ ثانیه برسانید و پس از پایداری، دوباره بالا ببرید.
تغییر را در ساعت کمبازدید انجام دهید. اگر به جای رکورد A، سرورهای نام (Nameserver) را عوض میکنید، این تغییر معمولاً دیرتر پخش میشود؛ پیش از آن، همهٔ رکوردها را در DNS جدید بازسازی کنید.
هاست قدیم را چند روز زنده نگه دارید
پس از تغییر DNS، هاست قدیم را دستکم چند روز فعال نگه دارید: برخی کاربران و سرورهای ایمیل هنوز به آدرس قدیم میروند، و اگر مشکلی پیش آمد، برگشت فقط یک تغییر DNS است. اگر سایت سفارش میگیرد، ثبت سفارش روی نسخهٔ قدیم را ببندید، وگرنه بخشی از سفارشها در پایگاه دادهٔ قدیم ثبت میشود و گم میشود.
چیزهایی که معمولاً جا میمانند
سایت که روی هاست جدید بالا آمد، کار تمام نیست. این پنج مورد بیشترین گرفتاریها را میسازند.
گواهی SSL
گواهی SSL روی سرور نصب میشود و باید روی هاست جدید هم صادر یا نصب شود. گواهی رایگان خودکار معمولاً فقط پس از اشارهٔ DNS به سرور جدید صادر میشود، پس ممکن است مدتی کوتاه مرورگر هشدار نشان دهد. اگر گواهی پولی دارید، فایلهایش را از هاست قدیم بگیرید؛ وگرنه از هاست جدید بپرسید چطور میشود پیش از تغییر DNS گواهی گرفت.
ایمیل و رکوردهای MX؛ قطعهٔ کلاسیکِ فراموششده
اگر ایمیل سازمانی روی هاست قدیم است، با تغییر سرورهای نام ایمیلها بیصدا متوقف میشوند و گاهی چند روز بعد کسی متوجه میشود. پیش از انتقال روشن کنید ایمیل کجا میزبانی میشود؛ صندوقها را در مقصد بسازید و پیامهای قدیمی را با IMAP منتقل کنید. رکوردهای MX، SPF، DKIM و DMARC را در DNS جدید دقیقاً بازسازی کنید؛ SPF ناقص یعنی ایمیل شما در اسپم مشتری. بعد، دریافت و ارسال را هر دو تست کنید.
کرانجابها (Cron Jobs)
کارهای زمانبندیشده در تنظیمات سرورند و با کپی فایلها منتقل نمیشوند: خبرنامه، بکاپ خودکار، لغو سفارشهای پرداختنشده، همگامسازی موجودی. فهرستشان را از هاست قدیم یادداشت کنید و در هاست جدید بسازید.
درگاه پرداخت: آدرس بازگشت و IP سرور
برای سایتهای ایرانی حیاتی است. بسیاری از درگاههای داخلی، درخواست تأیید تراکنش را فقط از IP ثبتشدهٔ سرور شما میپذیرند. با عوض شدن هاست، IP عوض میشود و ممکن است مشتری پول بدهد اما سفارشش «ناموفق» ثبت شود.
پیش از انتقال، IP هاست جدید را به پشتیبانی درگاه بدهید تا به فهرست مجاز اضافه شود. اگر آدرس سایت عوض میشود، آدرس بازگشت (Callback URL) را هم در پنل درگاه بهروز کنید. بعد یک خرید واقعی با مبلغ کم انجام دهید. جزئیات درگاهها در راهنمای درگاه پرداخت آمده است. برخی پنلهای پیامک هم ارسال را به IP مشخص محدود میکنند.
ایمیلهای خود سایت (SMTP)
ایمیلهای تأیید سفارش، بازیابی رمز و فرم تماس اغلب از تابع ایمیل خود سرور ارسال میشوند که روی سرور جدید ممکن است غیرفعال باشد. بهتر است سایت از طریق SMTP یک صندوق واقعی ارسال کند؛ پس از انتقال، فرم تماس و بازیابی رمز را تست کنید.
سئو: اگر آدرسها عوض نشود، ریدایرکت لازم نیست
نگرانی اصلی بیشتر صاحبان سایت، از دست دادن رتبه است. تغییر هاست بهتنهایی چیزی را برای گوگل عوض نمیکند: همان دامنه، همان آدرسها، همان محتوا. انتقال سایت بدون افت سئو در این حالت بیشتر به این بستگی دارد که سایت در دورهٔ گذار سالم بماند:
- قطعی طولانی و خطاهای سری ۵۰۰ را به حداقل برسانید؛ خطای پیاپی خزش گوگل را کم میکند.
- مطمئن شوید
robots.txtهمان نسخهٔ قبلی است و در وردپرس گزینهٔ «از موتورهای جستوجو بخواهید محتوای این سایت را ایندکس نکنند» خاموش است. - سرعت سرور جدید را بسنجید و Core Web Vitals (مثلاً LCP تا ۲٫۵ ثانیه) را پیش و پس از انتقال مقایسه کنید.
اگر دامنه یا آدرس صفحهها تغییر کند
اگر همزمان دامنه یا ساختار آدرسها را عوض میکنید، برای هر آدرس قدیم یک ریدایرکت ۳۰۱ به معادل جدیدش لازم است؛ تهیهٔ این نقشه را در مقالهٔ بازطراحی سایت توضیح دادهایم. اگر دامنه عوض شده، پس از برقراری ریدایرکتها از ابزار Change of Address در Search Console استفاده کنید (راهنمای رسمی گوگل برای جابهجایی سایت) و ریدایرکتها را برای مدت طولانی نگه دارید. تغییر دامنه یعنی اینماد و ثبت درگاه هم باید برای دامنهٔ جدید پیگیری شود.
توصیهٔ ما: اگر میتوانید، تغییر هاست و تغییر دامنه را همزمان انجام ندهید؛ وگرنه اگر افتی پیش آمد، نمیدانید علتش کدام بوده است.
پایش بعد از انتقال
دو هفتهٔ اول، اینها را مرتب نگاه کنید:
- Search Console: گزارش صفحهها برای خطاهای سرور یا «یافت نشد»، و آمار خزش.
- Analytics: افت ناگهانی ترافیک یا سفارش و فرم؛ و اینکه کد آنالیتیکس هنوز بارگذاری میشود.
- سفارشها و پرداختها: تطبیق با گزارش درگاه؛ پرداخت موفقِ بیسفارش یعنی مشکل IP یا Callback.
- ایمیلها و بکاپ خودکار هاست جدید: آیا واقعاً کار میکنند؟
وقتی همهٔ اینها چند روز پشت سر هم سالم بود، یک بکاپ نهایی از هاست قدیم بگیرید و بعد لغوش کنید.
چکلیست انتقال سایت به هاست جدید
برای هر ردیف یک مسئول مشخص کنید و ستون آخر را فقط وقتی تیک بزنید که واقعاً تست شده باشد.
| مرحله | چه کسی | چک شد؟ |
|---|---|---|
| دسترسی مالک به پنل دامنه و ایمیل بازیابی آن | صاحب کسبوکار | ☐ |
| تحویل هاست، DNS، کد، لایسنسها، Search Console و Analytics | صاحب کسبوکار + طراح قبلی | ☐ |
| تعویض همهٔ رمزها و حذف کاربران اضافه | صاحب کسبوکار | ☐ |
| بکاپ کامل بیرون از هاست + بازگردانی آزمایشی | تیم فنی | ☐ |
| یادداشت نسخهٔ PHP، کرانجابها و رکوردهای DNS | تیم فنی | ☐ |
| ثبت IP جدید نزد درگاه پرداخت و پنل پیامک | صاحب کسبوکار + تیم فنی | ☐ |
| کاهش TTL یکی دو روز پیش از انتقال | تیم فنی | ☐ |
| تست کامل روی هاست جدید با فایل hosts | تیم فنی + صاحب کسبوکار | ☐ |
| آمادهسازی SSL و رکوردهای MX، SPF، DKIM و DMARC | تیم فنی | ☐ |
| تغییر DNS و بستن ثبت سفارش روی هاست قدیم | تیم فنی | ☐ |
| خرید آزمایشی، تست فرم تماس و ایمیلها، بررسی robots.txt | صاحب کسبوکار + تیم فنی | ☐ |
| پایش دو هفتهٔ اول، بکاپ نهایی و لغو هاست قدیم | هر دو | ☐ |
انتقال را خودتان انجام دهید یا بسپارید؟
برای یک سایت معرفی ساده بدون ایمیل سازمانی و درگاه، انتقال با همین راهنما و کمک پشتیبانی هاست جدید شدنی است. اما وقتی فروشگاه، درگاه، پنل پیامک و ایمیل سازمانی در کار باشد، هر قطعهای که جا بماند هزینهٔ واقعی دارد: سفارش گمشده یا ایمیل نرسیده.
اگر میخواهید این کار را بسپارید، دامنه و هزینهاش به اندازه و پیچیدگی سایت بستگی دارد و باید پیش از شروع مکتوب تعریف شود. بعد از انتقال هم سایت به نگهداری منظم نیاز دارد؛ پشتیبانی مای طرح با یک بررسی اولیهٔ فنی و امنیتی شروع میشود و جزئیاتش در خدمات پشتیبانی و نگهداری سایت آمده است. قول «صفر ثانیه قطعی» یا «حفظ قطعی رتبه» نمیدهیم، چون هیچکس صادقانه نمیتواند بدهد؛ آنچه میدهیم روالی منظم است که ریسک را پایین میآورد.
جمعبندی
انتقال سایت از پنل هاست شروع نمیشود؛ از پس گرفتن کنترل دامنه، حسابها و کد شروع میشود. بعد، بکاپ بازگردانیشده، تست با فایل hosts، TTL کوتاه، زنده نگه داشتن هاست قدیم و توجه به ایمیل، درگاه و کرانجابها بیشتر خطرها را میپوشاند. اگر آدرسها ثابت بمانند، سئو معمولاً آسیبی نمیبیند.
قدم بعدی: همین امروز فهرست بخش اول را پر کنید و ببینید کدام دسترسی هنوز دست شما نیست. اگر نمیدانید از کجا شروع کنید، یک گفتوگوی آشنایی رایگان ۳۰ دقیقهای رزرو کنید تا وضعیت سایتتان را با هم مرور کنیم.
سؤالات متداول
انتقال سایت به هاست جدید چقدر قطعی دارد؟
اگر سایت از قبل روی هاست جدید تست شده باشد، TTL پایین آمده باشد و هاست قدیم تا پخش کامل DNS روشن بماند، بیشتر کاربران قطعی محسوسی نمیبینند. ممکن است در چند ساعت اول، بخشی از بازدیدکنندگان هنوز نسخهٔ قدیم را ببینند. صفر بودن قطعی را کسی نمیتواند تضمین کند، اما با این روال آن را به حداقل میرسانید.
آیا تغییر هاست روی سئو و رتبهٔ گوگل اثر دارد؟
اگر دامنه و آدرس صفحهها همان بماند، تغییر هاست بهتنهایی معمولاً اثر منفی ندارد. چیزی که آسیب میزند قطعی طولانی، خطاهای سرور، کندتر شدن سایت یا جلوگیری ناخواسته از ایندکس در robots.txt است. پس از انتقال، گزارشهای Search Console را دو هفته پیگیری کنید تا هر خطایی را زود ببینید.
طراح قبلی دسترسیها را نمیدهد؛ چه کنم؟
اول بدهی احتمالی را روشن کنید و درخواست را مکتوب و مؤدبانه با فهرست دقیق دسترسیها بفرستید. اگر دامنه به نام خود شماست، از پنل دامنه میتوانید DNS را به هاست جدید ببرید و سایت را از بکاپ بازسازی کنید. اگر دامنه به نام اوست، مالکیت دامنه در اولویت است و مدارک پرداخت و قرارداد به کارتان میآید.
چرا بعد از انتقال، پرداخت انجام میشود اما سفارش ناموفق ثبت میشود؟
رایجترین علت این است که درگاه پرداخت درخواست تأیید تراکنش را فقط از IP قبلی سرور میپذیرد. IP هاست جدید را به پشتیبانی درگاه اعلام کنید تا به فهرست مجاز اضافه شود، و اگر آدرس سایت عوض شده، آدرس بازگشت را در پنل درگاه اصلاح کنید. بعد یک خرید آزمایشی با مبلغ کم انجام دهید.
هاست قدیم را چه زمانی لغو کنم؟
وقتی سایت چند روز پشت سر هم روی هاست جدید بدون خطا کار کرد، ایمیلها در هر دو جهت رسید، پرداخت آزمایشی موفق بود و بکاپ خودکار هاست جدید دستکم یکبار اجرا شد. پیش از لغو، یک بکاپ نهایی کامل از هاست قدیم بگیرید و جایی امن نگه دارید.