انتقال وردپرس به هاست جدید بدون قطعی؛ راهنمای مرحلهبهمرحله
انتقال بدون قطعی با آمادهسازی مقصد، تست قبل از DNS، همگامسازی تغییرات نهایی، نگهداشتن سرور قدیمی و پایش دقیق امکانپذیر است؛ اما سایتهای تراکنشی به برنامه کنترل نوشتن داده نیاز دارند.
پاسخ کوتاه: چطور وردپرس را بدون قطعی منتقل کنیم؟
ابتدا هاست مقصد را کامل آماده کنید، فایل و دیتابیس را منتقل کنید، سایت را با Hosts File یا URL آزمایشی تست کنید، SSL و PHP را هماهنگ کنید و سپس یک همگامسازی نهایی انجام دهید. بعد DNS را تغییر دهید، سرور قدیمی را فعال نگه دارید و ترافیک، سفارش، ایمیل و خطاها را پایش کنید.
«بدون قطعی» در عمل یعنی کاربر پاسخ معتبر بگیرد و داده از بین نرود. برای سایت پویا، فقط کپی فایل کافی نیست؛ باید نوشتنهای جدید میان دو سرور کنترل یا همگام شوند.
مهاجرت یک وبلاگ Cacheپذیر سادهتر از فروشگاه فعال است. پیش از شروع، سطح ریسک، نرخ تغییر داده، زمان قابل قبول Freeze و برنامه بازگشت را مشخص کنید.
قطعی صفر در مهاجرت وردپرس دقیقاً یعنی چه؟
DNS یکباره برای همه کاربران تغییر نمیکند. در دوره انتشار DNS، بخشی از درخواستها ممکن است به سرور قدیمی و بخشی به مقصد جدید برسند. اگر هر دو نسخه پاسخ دهند، سایت ظاهراً در دسترس است؛ اما در سایت تراکنشی ممکن است سفارش یا فرم بین دو دیتابیس تقسیم شود.
بنابراین سه هدف جدا وجود دارد: دسترسی، یکپارچگی داده و امکان بازگشت. انتقال حرفهای باید هر سه را پوشش دهد.
فهرست پیش از مهاجرت را تهیه کنید
- دامنهها، Subdomainها و مسیر نصب WordPress
- نسخه PHP، Extensionها، MariaDB/MySQL و Web Server
- حجم فایل، دیتابیس، تعداد Inode و فضای موقت لازم
- Cron Job، Queue، Webhook و Taskهای زمانبندیشده
- حسابهای ایمیل، Forwarder، SPF، DKIM و DMARC
- SSL، CDN، DNS Provider و TTL رکوردها
- Redis، Object Cache، OPcache و افزونههای کش
- Integrationهای پرداخت، پیامک، CRM و API
- مسئول تصمیم Rollback و کانال ارتباط اضطراری
این فهرست مانع میشود سایت باز شود اما ایمیل، Cron یا Webhook از کار بیفتد. مهاجرت را فقط به «فایل و دیتابیس» محدود نکنید.
قبل از هر کاری بکاپ و نقطه بازگشت بسازید
از فایلها و دیتابیس نسخه کامل بگیرید و سلامت آرشیو را بررسی کنید. اگر سایت بزرگ است، Snapshot اولیه و Dump مستقل دیتابیس داشته باشید. نسخه را خارج از هر دو سرور نگهداری کنید تا خرابی یا حذف اشتباه روی منبع بکاپ اثر نگذارد.
- زمان ایجاد نسخه و Hash یا اندازه فایل را ثبت کنید.
- فایل
wp-config.phpو تنظیمات وبسرور را جدا نگه دارید. - نسخه قدیمی Cache و Log را در صورت نیاز حذف کنید.
- روش Restore را قبل از Cutover بدانید.
راهنمای رسمی WordPress نیز مهاجرت بین سرورها را با بکاپ فایلها، رسانه، افزونه، قالب و دیتابیس آغاز میکند.
هاست مقصد را پیش از انتقال آماده کنید
دامنه یا vHost، دیتابیس، کاربر دیتابیس، نسخه PHP، Extensionها، محدودیت Upload و Cron را از قبل تنظیم کنید. اگر مقصد LiteSpeed، Redis یا تنظیمات متفاوتی دارد، ابتدا محیط پایه را بسازید و بهینهسازی را بعد از صحت عملکرد انجام دهید.
- فضای آزاد باید برای فایل، آرشیو و استخراج کافی باشد.
- Timezone، Collation و Character Set را بررسی کنید.
- مجوز فایل و مالکیت User را صحیح تنظیم کنید.
- ارسال ایمیل و اتصال بیرونی را در مقصد آزمایش کنید.
- Access Log و Error Log در دسترس باشند.
فایل و دیتابیس را چگونه منتقل کنیم؟
برای سایت کوچک میتوان از آرشیو و Import استفاده کرد. برای سایت بزرگ، کپی اولیه با ابزارهای همگامسازی و سپس Delta Sync زمان توقف را کم میکند. دیتابیس را با ابزار سازگار Export کنید و پس از Import، تعداد جدول و اندازه را مقایسه کنید.
پوشههای Cache، Backup قدیمی و Logهای حجیم معمولاً لازم نیستند. اما wp-content/uploads، قالب، افزونه، MU Plugin و فایلهای اختصاصی باید منتقل شوند. قبل از حذف هر مسیر، وابستگی برنامه را بررسی کنید.
دامنه ثابت است یا URL تغییر میکند؟
اگر دامنه و مسیر URL ثابت میماند، Search & Replace عمومی لازم نیست و انجام بیدلیل آن میتواند داده Serialized را خراب کند. فقط تنظیمات اتصال دیتابیس، مسیرهای مطلق خاص و فایل پیکربندی را کنترل کنید.
اگر دامنه یا پروتکل تغییر میکند، از ابزار آگاه از Serialization مانند WP-CLI Search Replace یا ابزار مهاجرت معتبر استفاده کنید. سپس canonical، Redirect، Sitemap، لینک داخلی و داده Structured را بررسی کنید. تغییر هاست با URL ثابت از نظر سئو سادهتر است.
قبل از تغییر DNS با Hosts File تست کنید
Hosts File اجازه میدهد دامنه فقط روی دستگاه شما به IP مقصد اشاره کند. در این حالت کاربر عمومی همچنان سرور قدیمی را میبیند و شما نسخه مقصد را با URL واقعی آزمایش میکنید. تست باید شامل Frontend، مدیریت، Login، فرم، آپلود، Cron و API باشد.
- کش مرورگر و DNS محلی را پاک کنید.
- IP پاسخدهنده را با Header یا فایل تشخیصی تأیید کنید.
- نسخه موبایل و چند مرورگر را بررسی کنید.
- درگاه پرداخت را در Sandbox یا سناریوی کنترلشده تست کنید.
- پس از پایان، ورودی Hosts را حذف کنید.
تغییرات نهایی را چگونه همگام کنیم؟
از زمان کپی اولیه تا Cutover ممکن است نوشته، دیدگاه، سفارش یا فایل جدید ایجاد شود. برای سایت کمتغییر، یک Maintenance کوتاه یا توقف انتشار و Dump نهایی کافی است. برای فروشگاه فعال، روش باید دقیقتر باشد.
- فایلهای جدید را با Delta Sync منتقل کنید.
- در بازه نهایی، Cronهای نوشتنی را موقتاً متوقف کنید.
- برای دیتابیس، Window کوتاه Freeze یا Replication برنامهریزی کنید.
- زمان آخرین سفارش و آخرین ID را ثبت و مقایسه کنید.
- پس از Import نهایی، Cache و OPcache مقصد را پاک کنید.
اجرای همزمان دو سایت مستقل با دیتابیس جدا و پذیرش سفارش روی هر دو، بدون مکانیزم Merge، ریسک از دست رفتن داده دارد.
DNS و TTL را چه زمانی تغییر دهیم؟
چند روز پیش از مهاجرت، TTL رکورد اصلی را در صورت امکان کاهش دهید تا Cacheهای DNS زودتر تازه شوند. کاهش TTL درست در لحظه مهاجرت روی Resolverهایی که مقدار قبلی را Cache کردهاند اثر فوری ندارد.
در Cutover فقط رکوردهای لازم را تغییر دهید و Zone را بیدلیل بازنویسی نکنید. A/AAAA، CNAME، MX و رکوردهای سرویس را جدا بررسی کنید. پس از پایدار شدن، TTL را به مقدار عادی برگردانید.
SSL و HTTPS را قبل از Cutover آماده کنید
مقصد باید برای دامنه اصلی و نسخه www گواهی معتبر ارائه کند. در برخی روشها صدور عمومی قبل از DNS دشوار است؛ میتوان از DNS Challenge، گواهی موقت معتبر یا صدور سریع بلافاصله پس از تغییر استفاده کرد. از نمایش گواهی اشتباه یا Redirect Loop جلوگیری کنید.
- Chain گواهی و تاریخ اعتبار را بررسی کنید.
- HTTP به HTTPS و www/non-www را یکدست کنید.
- Mixed Content و URLهای ثابت را پیدا کنید.
- HSTS را بدون برنامه Rollback سختگیرانهتر نکنید.
ایمیل و رکوردهای جانبی را فراموش نکنید
اگر ایمیل روی هاست قبلی است، تغییر Nameserver یا Zone میتواند MX، SPF، DKIM و Autodiscover را حذف کند. پیش از تغییر، رکوردهای فعلی را Export کنید و تصمیم بگیرید ایمیل منتقل میشود یا روی سرویس قبلی باقی میماند.
حسابها، Forwarder، Catch-all، محدودیت ارسال و تاریخچه Mailbox را جداگانه منتقل و تست کنید. ارسال فرم WordPress نیز ممکن است به SMTP یا IP Allowlist وابسته باشد.
ترتیب پیشنهادی Cutover
- تأیید تست کامل مقصد و سلامت Backup
- اعلام Freeze کوتاه برای محتوای نوشتنی در صورت نیاز
- توقف Cron و Queueهای حساس روی مبدا
- Delta Sync فایل و Export/Import نهایی دیتابیس
- پاکسازی Cache و تست سریع مقصد
- تغییر A/AAAA یا رکورد مربوط به Origin
- فعالسازی Cron و Queue فقط روی مقصد
- پایش Log، سفارش، ایمیل و ترافیک هر دو سرور
- حفظ مبدا تا پایان دوره اطمینان
زمان هر مرحله و مسئول آن را قبل از اجرا ثبت کنید. مهاجرت شبانه همیشه بهترین زمان نیست؛ زمانی را انتخاب کنید که تیم فنی و ذینفعان در دسترس باشند.
پس از تغییر DNS چه تستهایی لازم است؟
- صفحه اصلی، نوشته، محصول، جستوجو و 404
- Login، خروج، نقشهای کاربری و پنل مدیریت
- آپلود تصویر، ساخت Thumbnail و ویرایش محتوا
- فرم تماس، ایمیل و SMTP
- Cart، Checkout، Coupon و Payment Callback
- REST API، Webhook، Cron و Queue
- SSL، Redirect، canonical، robots و Sitemap
- Cache HIT/MISS، Redis و پاکسازی Cache
- خطاهای 4xx/5xx و زمان پاسخ
فقط از شبکه خود تست نکنید. چند Resolver و موقعیت شبکه میتوانند هنوز IP قدیمی را ببینند.
تغییر هاست چه اثری روی سئو دارد؟
اگر URL، محتوا و canonical ثابت بمانند و هر دو زیرساخت در زمان انتقال پاسخ صحیح بدهند، تغییر هاست نباید به تغییر ساختار سئو تبدیل شود. گوگل برای جابهجایی میزبانی بدون تغییر URL توصیه میکند مقصد را آماده و تست کنید، DNS را تغییر دهید و ترافیک قدیم و جدید را پایش کنید.
- از noindex یا robots اشتباه در مقصد جلوگیری کنید.
- نسخه Staging را با Production اشتباه Publish نکنید.
- Status Code، canonical و Sitemap را ثابت نگه دارید.
- سرعت و دسترسی Googlebot را پس از انتقال بررسی کنید.
- اگر URL تغییر نکرده، Change of Address لازم نیست.
برای ووکامرس چگونه از از دست رفتن سفارش جلوگیری کنیم؟
فروشگاه فعال حساسترین سناریو است. Freeze کوتاه Checkout در مرحله نهایی، Replication دیتابیس یا مهاجرت مدیریتشده میتواند از Split Brain جلوگیری کند. اگر امکان توقف سفارش ندارید، باید دقیقاً بدانید نوشتنها چگونه به دیتابیس واحد یا مقصد نهایی هدایت میشوند.
- آخرین Order ID و تعداد سفارش را پیش و پس از Cutover مقایسه کنید.
- Webhookهای پرداخت و حملونقل را بررسی کنید.
- Stock، Session و Action Scheduler را تست کنید.
- Cron روی دو سرور همزمان اجرا نشود.
- ایمیل سفارش و Invoice را کنترل کنید.
سایتهای بزرگ و Media Library حجیم
انتقال آرشیوهای بسیار بزرگ زمان و فضای موقت زیادی میخواهد. کپی مرحلهای و Delta Sync بهتر از ساخت چندباره Archive کامل است. برای فایلهای رسانهای میتوان ابتدا داده تاریخی را منتقل و در Cutover فقط فایلهای جدید را همگام کرد.
تعداد Inode، Symlink، Permission و فایلهای مخفی را بررسی کنید. اگر Object Storage یا CDN دارید، Origin و Credentialها باید در مقصد معتبر باشند.
برنامه Rollback باید چه داشته باشد؟
- شرط روشن بازگشت: خطای پرداخت، از دست رفتن داده یا 5xx پایدار
- مسئول تصمیم و حداکثر زمان انتظار
- روش بازگرداندن DNS و TTL
- وضعیت دیتابیس و نوشتنهای پس از Cutover
- نسخه Backup و روش Restore
- خاموشکردن Cron مقصد و فعالکردن مبدا
- اطلاعرسانی داخلی و ثبت Timeline
Rollback فقط تغییر IP نیست. اگر پس از Cutover داده جدید ثبت شده، بازگشت بدون Merge میتواند همان داده را حذف کند.
چکلیست نهایی مهاجرت
- Backup فایل و دیتابیس تأیید شده است.
- مقصد با Hosts File تست کامل شده است.
- PHP، Extension، Cron و ایمیل هماهنگاند.
- SSL و Redirectها آمادهاند.
- TTL از قبل کاهش یافته است.
- روش Sync نهایی و کنترل نوشتن مشخص است.
- Monitoring و Log آمادهاند.
- برنامه Rollback نوشته شده است.
- مبدا تا پایان دوره اطمینان حذف نمیشود.
- پس از تثبیت، TTL و Backup عادی بازتنظیم میشوند.
اشتباههای رایج
- تغییر DNS قبل از تست: خطا مستقیماً به کاربر میرسد.
- کپی یکباره فروشگاه: سفارشهای جدید جا میمانند.
- حذف زودهنگام مبدا: امکان Rollback از بین میرود.
- فراموشی ایمیل: MX و DKIM با Zone جدید حذف میشوند.
- اجرای Cron روی هر دو سرور: Job و ایمیل تکراری ایجاد میشود.
- Search Replace غیرضروری: داده Serialized یا URL خراب میشود.
- فعالکردن همه بهینهسازیها همزمان: عیبیابی دشوار میشود.
جمعبندی: مهاجرت را یک فرایند کنترل داده ببینید
انتقال وردپرس بدون قطعی با آمادهسازی و تست مقصد، Sync مرحلهای، کنترل نوشتنهای نهایی، تغییر حسابشده DNS و نگهداشتن مبدا امکانپذیر است. در فروشگاه، یکپارچگی سفارش و دیتابیس مهمتر از نمایش ظاهری صفحه اصلی است.
FluxCDN انتقال سایت را برای پلنهای هاست وردپرس بهصورت رایگان ارائه میکند. برای بررسی شرایط و آمادهسازی مهاجرت، پلنهای هاست وردپرس و فرایند انتقال را مشاهده کنید.