انتقال وردپرس به هاست جدید
بدون فراموش‌کردن دیتابیس، DNS و راه بازگشت

دامنه مهاجرت را پیش از شروع مشخص کنید

ابتدا تعیین کنید فقط هاست عوض می‌شود یا دامنه/پروتکل/مسیر نیز تغییر می‌کند. در انتقال با همان دامنه، معمولاً URLهای ذخیره‌شده ثابت می‌مانند؛ در تغییر دامنه یا HTTP به HTTPS، داده‌های دیتابیس نیز نیازمند بازبینی‌اند. نسخه PHP، extensionهای لازم، محدودیت upload، نوع دیتابیس، cron، SMTP و فضای موردنیاز را بین مبدأ و مقصد مقایسه کنید.

یک زمان برش انتخاب کنید و مسئول تصمیم rollback را مشخص کنید. برای فروشگاه، عضویت یا فرم فعال، داده‌های جدید ممکن است بین backup و برش روی مبدأ نوشته شوند. راه‌حل می‌تواند پنجره نگهداری کوتاه، همگام‌سازی نهایی یا فرایند مهاجرت تخصصی باشد؛ دو سایت نویسنده هم‌زمان معمولاً باعث واگرایی سفارش و حساب کاربری می‌شوند.

نسخه کامل و قابل‌بازیابی تهیه کنید

فایل‌های هسته، wp-content، فایل‌های مخفی مانند .htaccess و wp-config.php را در inventory بگنجانید؛ در کنار آن، از همه جدول‌های دیتابیس WordPress خروجی بگیرید. فقط Media Library یا ابزار Export محتوای داخل پیشخوان جای backup کامل سایت را نمی‌گیرد.

نسخه را خارج از حساب مبدأ نگه دارید، checksum یا اندازه آن را ثبت و امکان بازکردن archive و خواندن dump را بررسی کنید. رمزها و کلیدهای موجود در wp-config.php حساس‌اند. نسخه مبدأ را تا پایان تأیید مهاجرت حفظ کنید و از پاک‌سازی زودهنگام سرویس قبلی بپرهیزید.

فایل، دیتابیس و wp-config.php را در مقصد هماهنگ کنید

در مقصد، دامنه یا محیط آزمایشی را بسازید و فایل‌ها را در document root درست بارگذاری کنید. دیتابیس و کاربر جدید را با حداقل دسترسی لازم بسازید و dump را restore کنید. سپس DB_NAME، DB_USER، DB_PASSWORD و در صورت تفاوت DB_HOST را در wp-config.php با مقادیر واقعی مقصد تطبیق دهید.

مالکیت و permission فایل‌ها باید با مدل میزبان مقصد سازگار باشد؛ نسخه‌برداری از permission یک سرور دیگر همیشه درست نیست. اگر prefix جدول یا multisite دارید، مهاجرت پیچیده‌تر است و باید ساختار شبکه، فایل‌های پیکربندی و جدول‌های مرتبط را طبق مستندات WordPress جدا بررسی کنید.

تغییر URL را با ابزار آگاه از serialization انجام دهید

قالب‌ها و افزونه‌ها ممکن است URL را در داده PHP serialized ذخیره کنند؛ جایگزینی خام SQL می‌تواند طول رشته را ناسازگار و تنظیمات را خراب کند. WP-CLI دستور search-replace را با پشتیبانی از serialized data ارائه می‌دهد. ابتدا دامنه هدف، جدول‌ها و نتیجه را با حالت بدون نوشتن بررسی کنید:

wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-run

خروجی dry-run را بازبینی کنید و تنها با backup و دامنه دقیق، اجرای واقعی را برنامه‌ریزی کنید. اگر دامنه ثابت مانده، search-replace عمومی لازم نیست. مقدار home و siteurl، لینک رسانه‌ها، canonical، sitemap و تنظیمات cache/CDN را پس از هر تغییر URL کنترل کنید.

پیش از تغییر DNS، مقصد را واقعاً آزمایش کنید

با نگاشت موقت فایل hosts روی رایانه خود، دامنه اصلی را به IP مقصد ببرید تا WordPress همان Host واقعی را ببیند، بدون آنکه کاربران عمومی منتقل شوند. صفحه اصلی کافی نیست: ورود و خروج، صفحه نوشته، تصویر، فرم، ارسال ایمیل تراکنشی، جست‌وجو، checkout آزمایشی، REST API، پیوند یکتا و log خطای PHP/وب‌سرور را بررسی کنید.

cache مرورگر، افزونه cache، object cache و CDN می‌توانند نتیجه قدیمی نشان دهند. برای آزمون، هر لایه را آگاهانه پاک یا bypass کنید و بعد تنظیم نهایی cache را بازگردانید. SSL مقصد باید برای نام واقعی آماده باشد؛ هشدار گواهی را به‌عنوان «طبیعی در مهاجرت» نپذیرید.

برش DNS و دوره هم‌زیستی را کنترل کنید

پس از آزمون، در صورت نیاز نوشتن روی مبدأ را متوقف کنید، آخرین داده را همگام کنید و رکورد DNS را به مقصد تغییر دهید. پاسخ authoritative و چند resolver را بررسی کنید. TTL کوتاه‌تر می‌تواند مدت cache را کاهش دهد، اما انتشار هم‌زمان را تضمین نمی‌کند؛ به همین دلیل مبدأ باید در دوره گذار پاسخ سالم و سازگار بدهد.

سرویس ایمیل را با وب اشتباه نگیرید: تغییر A وب لزوماً MX را عوض نمی‌کند، اما جابه‌جایی nameserver بدون انتقال رکوردهای ایمیل خطرناک است. تا زمانی که logها نشان دهند ترافیک به مقصد رسیده و داده جدید فقط آنجا ثبت می‌شود، مبدأ را نگه دارید.

تأیید نهایی و معیار rollback

پس از برش، statusهای HTTP، redirectهای زنجیره‌ای، mixed content، robots، canonical، sitemap، jobهای زمان‌بندی‌شده، backup مقصد و مانیتورینگ را بررسی کنید. خطاهای 404 پیوند یکتا ممکن است به rewrite؛ خطای database به credential/host؛ و صفحه سفید به PHP، memory یا افزونه ناسازگار مربوط باشد.

پیشاپیش معیار بازگشت تعریف کنید؛ مثلاً ازکارافتادن پرداخت یا ورود که در زمان مشخص حل نمی‌شود. rollback فقط برگرداندن DNS نیست: باید بدانید داده‌های نوشته‌شده روی مقصد در فاصله برش چه می‌شوند. پس از دوره پایش و یک backup موفق از مقصد، بازنشسته‌کردن مبدأ را طبق برنامه انجام دهید.