انتقال وردپرس به هاست جدید؛ چک‌لیست امن از بکاپ تا تغییر DNS

برای انتقال وردپرس به هاست جدید باید فایل‌ها، دیتابیس و تنظیمات محیط را منتقل کنید، نسخه مقصد را پیش از تغییر DNS آزمایش کنید و برای داده‌هایی که هنگام انتقال تولید می‌شوند برنامه داشته باشید. کپی‌کردن فایل‌ها به‌تنهایی کافی نیست؛ سفارش، فرم، ایمیل، Cron، SSL و Cache ممکن است پس از جابه‌جایی ظاهراً سالم باشند اما درست کار نکنند.

پاسخ سریع: از فایل‌ها و دیتابیس یک بکاپ قابل‌بازیابی بگیرید، سازگاری PHP و افزونه‌های سرور مقصد را بررسی کنید، یک کپی اولیه بسازید و آن را با hostname واقعی و بدون تغییر عمومی DNS تست کنید. سپس در یک بازه کنترل‌شده نوشتن روی سایت قدیمی را متوقف کنید، دیتابیس و فایل‌های متغیر را دوباره همگام کنید، DNS را تغییر دهید و هر دو سرور را تا پایان دوره TTL زیر نظر نگه دارید. اگر دامنه عوض نمی‌شود، search-replace عمومی روی دیتابیس لازم نیست.

پیش از شروع، نوع انتقال را مشخص کنید

سه سناریو رفتار یکسانی ندارند: انتقال به هاست جدید با همان دامنه، انتقال هم‌زمان به دامنه جدید و انتقال یک فروشگاه فعال. در حالت اول معمولاً URLهای وردپرس ثابت می‌مانند. در حالت دوم باید URLهای ذخیره‌شده را با ابزار سازگار با داده serialized تغییر دهید. در فروشگاه فعال نیز فاصله میان کپی اولیه و تغییر نهایی می‌تواند سفارش، موجودی یا حساب کاربر را بین دو دیتابیس تقسیم کند.

راهنمای رسمی مهاجرت WordPress نیز انتقال فایل‌ها و دیتابیس را مبنا می‌داند و درباره جایگزینی ساده متن در داده‌های serialized هشدار می‌دهد.

اطلاعاتی که باید از هر دو هاست ثبت کنید

• نسخه PHP، محدودیت حافظه و افزونه‌های لازم مانند mysqli، curl، mbstring و imagick
• نوع وب‌سرور، قوانین Rewrite، نسخه MySQL یا MariaDB و collation دیتابیس
• مسیر Document Root، مالک فایل‌ها و روش اجرای PHP
• وظایف Cron واقعی، Queueها و سرویس‌های پس‌زمینه
• تنظیمات SMTP، DNS، CDN، WAF، Object Cache و Page Cache
• فضای Disk و inode، اندازه دیتابیس و پوشه wp-content/uploads
• TTL رکوردهای A، AAAA و هر رکوردی که به مبدأ وب اشاره می‌کند

اگر هدف مهاجرت رفع کندی است، ابتدا شواهد را با معیارهای تشخیص کندی ناشی از هاست تطبیق دهید. انتقال یک Query کند یا افزونه ناسازگار به سرور قوی‌تر ممکن است فقط زمان بروز دوباره مشکل را عقب بیندازد.

بکاپ مهاجرت باید چه چیزی را پوشش دهد؟

حداقل به یک export کامل دیتابیس و یک کپی از فایل‌های وردپرس نیاز دارید. پوشه wp-content معمولاً قالب، افزونه، رسانه و فایل‌های وابسته به برنامه را نگه می‌دارد، اما فایل‌های پیکربندی وب‌سرور، Cron، گواهی، تنظیمات PHP و سرویس‌های بیرون از Document Root ممکن است جای دیگری باشند. فهرست این وابستگی‌ها را جدا ثبت کنید.

صرف وجود فایل backup اثبات نمی‌کند که قابل‌بازیابی است. اندازه، checksum و امکان خواندن archive را بررسی کنید و restore را روی مقصد یا محیط جدا آزمایش کنید. نسخه سالم پیش از مهاجرت را با کپی تازه‌ای که ممکن است ناقص باشد جایگزین نکنید.

TTL را پیش از روز انتقال کاهش دهید

کاهش TTL فقط زمانی اثر کامل دارد که حداقل به‌اندازه TTL قبلی پیش از تغییر نهایی اعمال شده باشد. برای انتقال وب‌سایت معمولاً تغییر رکوردهای مبدأ وب از جابه‌جایی هم‌زمان nameserver کم‌ریسک‌تر است؛ انتقال DNS و انتقال سایت را تا جای ممکن به دو تغییر مستقل تقسیم کنید.

TTL پایین تضمین نمی‌کند همه resolverها فوراً IP تازه را ببینند. سرور قدیمی را بلافاصله خاموش نکنید؛ لاگ و ترافیک هر دو مبدأ را تا پایان بازه مشاهده کنید. پس از تثبیت، TTL را به مقدار عملیاتی معمول برگردانید.

محیط مقصد را پیش از کپی آماده کنید

1. نسخه‌های سازگار PHP و دیتابیس را نصب یا در کنترل‌پنل انتخاب کنید.
2. دیتابیس و کاربر مجزا با دسترسی فقط به همان دیتابیس بسازید.
3. Document Root، مالکیت فایل و تنظیمات PHP را مشخص کنید.
4. Virtual Host را برای دامنه واقعی آماده کنید، اما هنوز DNS عمومی را تغییر ندهید.
5. TLS، Cron، SMTP و Cache را برای مرحله آزمون طراحی کنید.

نسخه جدید PHP یا تغییر وب‌سرور را بی‌دلیل با لحظه انتقال ترکیب نکنید. هر تغییر اضافی دامنه تشخیص خطا و مسیر بازگشت را بزرگ می‌کند. اگر وب‌سرور مقصد Nginx است، ساختار امن Nginx برای وردپرس را جداگانه بررسی کنید.

کپی اولیه فایل‌ها و دیتابیس

روش انتقال به دسترسی شما بستگی دارد: ابزار migration معتبر، پنل هاست، SFTP یا SSH. برای سایت بزرگ، ابزارهای incremental مانند rsync می‌توانند فاصله همگام‌سازی نهایی را کم کنند، اما حذف فایل در مقصد و گزینه‌های مخرب نباید بدون dry run و backup اجرا شود.

دیتابیس را با ابزاری export کنید که با نسخه و دسترسی محیط سازگار است. هنگام import، charset، collation، خطاهای SQL و تعداد جدول‌ها را کنترل کنید. موفقیت exit code یا نمایش پیام «Import complete» به‌تنهایی صحت داده و عملیات برنامه را ثابت نمی‌کند.

تنظیم wp-config.php در مقصد

مقادیر DB_NAME، DB_USER، DB_PASSWORD و DB_HOST باید به دیتابیس مقصد اشاره کنند. prefix جدول‌ها، کلیدهای امنیتی، تنظیمات Cache و ثابت‌های محیطی را نیز مرور کنید. رمز یا محتوای wp-config.php را در تیکت، خروجی فرمان یا مخزن عمومی قرار ندهید.

اگر با خطای اتصال دیتابیس وردپرس روبه‌رو شدید، نام میزبان، دسترسی کاربر، listener دیتابیس و prefix را جدا بررسی کنید؛ خطای اتصال الزاماً به معنی خرابی دیتابیس نیست.

سایت مقصد را بدون تغییر DNS عمومی آزمایش کنید

بهترین آزمون با همان hostname نهایی انجام می‌شود، زیرا Cookie، Redirect، CORS، TLS و کدهای وابسته به دامنه را آشکار می‌کند. می‌توانید روی سیستم آزمایش، نگاشت موقت hosts بسازید یا از preview امن ارائه‌دهنده استفاده کنید. تست با IP خام نماینده کاملی از رفتار Virtual Host و HTTPS نیست.

مقصد آزمایشی را از موتور جست‌وجو و کاربر عمومی دور نگه دارید، اما از noindex به‌تنهایی به‌عنوان کنترل دسترسی استفاده نکنید. همچنین ارسال ایمیل، webhook، پرداخت و Cron را محدود کنید تا نسخه آزمایشی پیام یا تراکنش واقعی تکراری نسازد.

چه چیزهایی را پیش از Cutover تست کنیم؟

• صفحه اصلی، نوشته، جست‌وجو، صفحه 404 و Permalinkها
• ورود و خروج مدیریت با حساب آزمایشی کم‌دسترسی
• بارگذاری و نمایش تصویر و تولید thumbnail
• فرم تماس، ارسال ایمیل و تحویل آن بدون افشای داده واقعی
• REST API، loopback، Site Health و WP-Cron
• Cache، purge و مسیرهای مستثنا مانند login و checkout
• HTTPS، chain گواهی، Mixed Content و Redirectهای HTTP
• برای ووکامرس: سبد، موجودی، مالیات، ارسال و پرداخت sandbox

لاگ PHP، وب‌سرور و دیتابیس را هنگام آزمون بخوانید. صفحه‌ای که HTTP 200 می‌دهد ممکن است هشدار PHP، خطای Ajax یا شکست job پس‌زمینه داشته باشد.

آیا هنگام انتقال به هاست جدید Search-Replace لازم است؟

اگر دامنه، scheme و مسیر عمومی سایت ثابت مانده‌اند، معمولاً جایگزینی URL لازم نیست. اجرای search-replace بی‌هدف می‌تواند ایمیل، شناسه بیرونی یا داده افزونه را ناخواسته تغییر دهد. تغییر IP سرور دلیل تغییر URLهای ذخیره‌شده در WordPress نیست.

اگر دامنه یا مسیر عوض می‌شود، از ابزار آگاه از داده serialized استفاده کنید. فرمان رسمی wp search-replace از --dry-run پشتیبانی می‌کند و داده serialized را مدیریت می‌کند:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix

دامنه‌های نمونه را با مقادیر واقعی جایگزین کنید. ابتدا خروجی dry run، جدول‌ها و تعداد تغییرات را بررسی کنید و backup داشته باشید. در Multisite، جدول‌های افزونه و داده‌های objectشده، scope فرمان باید بر اساس ساختار واقعی انتخاب شود؛ گزینه گسترده را کورکورانه کپی نکنید.

همگام‌سازی نهایی و جلوگیری از گم‌شدن داده

پس از کپی اولیه، سایت قدیمی همچنان comment، سفارش، فرم، upload و تغییر تنظیمات دریافت می‌کند. برای سایت محتوایی کم‌تغییر می‌توان یک maintenance window کوتاه تعیین کرد. نوشتن را متوقف کنید، آخرین دیتابیس و فایل‌های متغیر را همگام کنید، مقصد را دوباره بسنجید و سپس DNS را تغییر دهید.

در فروشگاه یا سایت عضویتی، نمایش یک صفحه نگهداری ساده‌تر از ادغام نامطمئن دو دیتابیس است. اگر downtime نزدیک به صفر الزام واقعی است، replication، shared storage، سازگاری session و فرایند cutover تخصصی لازم می‌شود. «بدون قطعی» نباید فقط به پایین بودن TTL تقلیل داده شود.

تغییر DNS و مراقبت از IPv6 و CDN

رکوردهای A و AAAA را با مقصد واقعی تطبیق دهید. باقی‌ماندن AAAA قدیمی می‌تواند بخشی از کاربران را به سرور قبلی ببرد. اگر CDN یا Proxy دارید، مبدأ آن را جدا تغییر دهید و پاسخ origin را پیش از purge گسترده بسنجید.

DNS را از چند resolver بررسی کنید، اما نتیجه resolver شخصی را معادل انتشار جهانی ندانید. هم‌زمان access log دو سرور را ببینید تا مشخص شود درخواست‌ها به کدام مقصد می‌رسند.

SSL را فقط از روی وجود فایل گواهی تأیید نکنید

گواهی باید برای hostname نهایی صادر و از اینترنت با chain کامل ارائه شود. Redirect از HTTP به HTTPS، URLهای WordPress و Headerهای Proxy را کنترل کنید. اگر CDN در جلوی سایت است، TLS مرورگر تا CDN و TLS میان CDN تا origin دو اتصال مستقل‌اند.

تمدید خودکار را نیز آزمایش یا حداقل پیکربندی آن را بررسی کنید؛ انتقال فایل گواهی قدیمی بدون مسیر renewal، خطایی است که چند هفته بعد ظاهر می‌شود.

کنترل‌های پس از انتقال

1. DNS، TLS، status code و canonical چند صفحه اصلی را از بیرون بررسی کنید.
2. ورود، فرم، ایمیل، Cron و عملیات اصلی کسب‌وکار را دوباره تست کنید.
3. PHP، وب‌سرور، دیتابیس و Queue را برای خطای تازه زیر نظر بگیرید.
4. Cache و CDN را هدفمند purge کنید؛ حذف همه Cacheها را با تغییرات دیگر هم‌زمان نکنید.
5. Analytics، Search Console، webhook و IP allowlist سرویس‌های بیرونی را بررسی کنید.
6. Backup زمان‌بندی‌شده مقصد و یک Restore Test آینده را ثبت کنید.

سایت قدیمی را تا زمانی که TTL و ترافیک واقعی اجازه نداده‌اند حذف نکنید. آن را read-only یا محدود نگه دارید تا نوشتن تازه ایجاد نشود، ولی برای rollback سریع در دسترس باشد.

Rollback را پیش از تغییر DNS بنویسید

Rollback فقط برگرداندن IP نیست. باید بدانید داده‌ای که پس از cutover روی مقصد نوشته شده چه می‌شود. اگر سایت مقصد سفارش تازه گرفته باشد، بازگرداندن DNS به دیتابیس قدیمی آن سفارش‌ها را پنهان می‌کند. معیار بازگشت، مسئول تصمیم، آخرین نقطه همگام‌سازی و روش reconciliation را پیشاپیش مشخص کنید.

اشتباه‌های رایج در انتقال وردپرس

• تغییر DNS پیش از آزمون مقصد
• کپی فایل‌ها بدون دیتابیس یا برعکس
• ویرایش خام SQL و خراب‌کردن داده serialized
• خاموش‌کردن فوری سرور قدیمی
• نادیده‌گرفتن رکورد AAAA یا مبدأ CDN
• اجرای هم‌زمان ارتقای PHP، تغییر دامنه و تغییر وب‌سرور
• فعال ماندن Cron، ایمیل یا پرداخت روی هر دو نسخه
• نداشتن برنامه برای سفارش و upload پس از کپی اولیه
• اعتماد به ظاهر صفحه اصلی بدون بررسی log و عملیات پویا

چه زمانی انتقال را به متخصص بسپاریم؟

اگر سایت فروش فعال، دیتابیس بزرگ، Multisite، ترافیک پیوسته، افزونه‌های سفارشی یا الزام downtime بسیار کم دارد، هماهنگی داده و rollback مهم‌تر از خود کپی است. سرویس انتقال سایت وردپرس برای برنامه‌ریزی انتقال، کنترل مقصد و آزمون‌های پس از جابه‌جایی در همین سناریوها تعریف شده است.

پرسش‌های متداول

انتقال وردپرس به هاست جدید چقدر زمان می‌برد؟

به حجم فایل و دیتابیس، سرعت دو میزبان، زمان آزمون و TTL بستگی دارد. زمان کپی فقط بخشی از کار است؛ همگام‌سازی نهایی و مشاهده پس از DNS را نیز در برنامه حساب کنید.

آیا با تغییر هاست، آدرس سایت عوض می‌شود؟

خیر. اگر همان دامنه و مسیر حفظ شود، URL عمومی ثابت می‌ماند و فقط مقصد DNS یا CDN تغییر می‌کند.

آیا انتقال وردپرس باعث افت سئو می‌شود؟

تغییر هاست به‌تنهایی نباید URLها را عوض کند. قطعی طولانی، پاسخ 5xx، Redirect اشتباه، Robots نامناسب یا تفاوت محتوای مقصد می‌تواند خزیدن و تجربه کاربر را مختل کند؛ بنابراین URL، canonical و status code را پس از انتقال بررسی کنید.

آیا افزونه مهاجرت کافی است؟

برای سایت ساده ممکن است بخش کپی را آسان کند، اما DNS، SSL، ایمیل، Cron، Cache، ظرفیت مقصد و داده‌های ایجادشده هنگام cutover همچنان نیازمند بررسی‌اند.