امنیت و نگهداری وردپرس

آموزش انتقال وردپرس به هاست جدید؛ مهاجرت بدون قطعی و حفظ سفارش‌های ووکامرس

ارسال توسط
0
آموزش انتقال وردپرس به هاست جدید

🗓 آخرین به‌روزرسانی:

📚 این آموزش بخشی از آموزش جامع وردپرس از صفر تا حرفه‌ای است؛ مسیر کامل یادگیری را آنجا ببینید.
نقشه راه وردپرس ←همه آموزش‌ها

انتقال وردپرس به هاست جدید فقط کپی‌کردن پوشه public_html و Import یک فایل SQL نیست. در یک سایت زنده، مخصوصاً فروشگاه WooCommerce، هم‌زمان با مهاجرت ممکن است مشتری سفارش ثبت کند، درگاه Callback بفرستد، موجودی کاهش یابد، ایمیل تراکنشی ارسال شود، فایل دانلودی تحویل داده شود و Jobهای زمان‌بندی‌شده اجرا شوند. اگر برنامه مهاجرت این جریان‌ها را کنترل نکند، نتیجه می‌تواند دو نسخه متفاوت از دیتابیس، سفارش‌های گمشده، پرداخت‌های تأییدنشده یا قطعی طولانی باشد.

مهاجرت حرفه‌ای یک فرایند مرحله‌ای است: ارزیابی هاست مقصد، تهیه Backup قابل بازیابی، ساخت کپی اولیه، آزمایش قبل از تغییر DNS، آماده‌سازی Cutover، توقف کوتاه نوشتن داده، انتقال Delta نهایی، تغییر DNS، اعتبارسنجی سرویس‌ها و مانیتورینگ پس از انتقال. هدف فقط بازشدن صفحه اصلی روی سرور جدید نیست؛ تمام مسیرهای WordPress، WooCommerce، ایمیل، درگاه، Cron، API و فایل دانلودی باید سالم بمانند.

در این راهنما، انتقال دستی با cPanel، SFTP و WP‑CLI، مهاجرت با افزونه یا سرویس هاست، مدیریت DNS و TTL، تست با Hosts File، Search‑Replace امن، SSL، ایمیل، HPOS، سفارش‌ها، درگاه پرداخت، LiteSpeed، Rank Math، افزونه‌های سفارشی و Rollback را مرحله‌به‌مرحله بررسی می‌کنیم.

وضعیت سایت فعلی: dev-source.ir روی WordPress 7.0.2 و WooCommerce 10.9.4 اجرا می‌شود. HPOS، WooCommerce Analytics، محصولات دانلودی، LiteSpeed Cache، Rank Math و چند افزونه سفارشی فعال‌اند و یک درگاه آنلاین نیز در فروشگاه فعال است. بنابراین مهاجرت واقعی این سایت باید سفارش، Callback درگاه، فایل دانلودی، Action Scheduler، ایمیل و داده‌های افزونه‌های سفارشی را جداگانه کنترل کند. در این مقاله هیچ فایل، دیتابیس، DNS، SSL یا تنظیم درگاه سایت زنده تغییر داده نمی‌شود.

مهاجرت هاست با تغییر دامنه چه تفاوتی دارد؟

تغییر هاست با دامنه ثابت

دامنه و URLها ثابت می‌مانند و فقط سرور مقصد عوض می‌شود. معمولاً Search‑Replace دامنه لازم نیست، اما مسیر فایل، IP، نسخه PHP، Cache، SSL و تنظیمات سرور تغییر می‌کنند.

تغییر هاست و دامنه

علاوه بر انتقال فایل و دیتابیس، تمام URLهای قدیمی باید با روش سازگار با داده‌های Serialized جایگزین شوند. Redirectهای 301، Search Console، Sitemap، Canonical، درگاه و ایمیل نیز نیازمند بازتنظیم‌اند.

انتقال از Subdomain یا پوشه

برای مثال انتقال از old.example.com یا example.com/store به دامنه اصلی نیازمند اصلاح home، siteurl، لینک‌های داخلی، Assetها و Ruleهای Rewrite است.

آیا مهاجرت بدون قطعی واقعاً ممکن است؟

برای بیشتر سایت‌ها می‌توان Downtime را به چند دقیقه کاهش داد، اما «صفر مطلق» به معماری پیچیده‌تر مانند Database Replication، Shared Storage، Load Balancer یا Blue‑Green Deployment نیاز دارد.

برای فروشگاه معمولی، راهکار عملی این است:

  1. بخش عمده فایل و دیتابیس پیش از Cutover منتقل شود.
  2. سرور جدید با Hosts File تست گردد.
  3. TTL پیش از مهاجرت کاهش یابد.
  4. در زمان نهایی Checkout و تغییر داده برای مدت کوتاه متوقف شود.
  5. دیتابیس و فایل‌های جدید به‌صورت Delta منتقل شوند.
  6. DNS تغییر کند و سرویس سریعاً تست شود.

این مدل قطعی را کوتاه می‌کند و مانع ثبت سفارش هم‌زمان در دو دیتابیس می‌شود.

چرا فروشگاه را نمی‌توان مانند وبلاگ ساده منتقل کرد؟

وبلاگ کم‌تغییر ممکن است در زمان مهاجرت داده جدید کمی تولید کند. فروشگاه دائماً اطلاعات پویا می‌سازد:

  • سفارش و Order Note
  • پرداخت و Transaction ID
  • موجودی و رزرو Stock
  • حساب مشتری و Session
  • کوپن و Usage Count
  • مجوز دانلود
  • Webhook و Callback
  • Action Scheduler و Analytics
  • ایمیل تراکنشی

کپی اولیه دیتابیس چند ساعت قبل از DNS Switch، این تغییرهای جدید را شامل نمی‌شود. به همین دلیل مرحله Delta یا Freeze کوتاه ضروری است.

مرحله اول: ارزیابی هاست مقصد

پیش از خرید یا انتقال، فقط حجم و قیمت هاست را مقایسه نکنید. این موارد را بررسی کنید:

  • نسخه‌های پشتیبانی‌شده PHP و MariaDB/MySQL
  • Memory Limit، Max Execution Time و Upload Limit
  • نوع وب‌سرور: LiteSpeed، Apache یا Nginx
  • پشتیبانی از Cron و WP‑CLI
  • تعداد PHP Worker و محدودیت CPU
  • فضای دیسک و Inode
  • Backup خارج از سرور و Restore
  • SSL و امکان نصب گواهی قبل از DNS Switch
  • Redis یا Object Cache
  • امنیت، WAF و دسترسی SFTP/SSH
  • موقعیت دیتاسنتر و کیفیت دسترسی مخاطبان

سرور مقصد باید از نظر نسخه PHP و Extensionها با افزونه‌های فعلی سازگار باشد. تغییر هاست و ارتقای بزرگ PHP را هم‌زمان انجام ندهید مگر روی Staging کامل آزمایش شده باشد.

مرحله دوم: فهرست کامل وابستگی‌ها

یک Migration Inventory بسازید:

  • دامنه و DNS Provider
  • رکوردهای A، AAAA، CNAME، MX، TXT و SRV
  • SSL و DNSSEC
  • ایمیل دامنه و SMTP
  • CDN و Cloudflare
  • درگاه‌های پرداخت
  • Webhook و REST API
  • Jobهای Cron
  • License قالب و افزونه
  • فضای ذخیره‌سازی خارجی
  • Analytics، Pixel و Search Console
  • Feed مارکت‌پلیس و اتصال‌های سفارشی

اگر رکورد MX یا SPF هنگام تغییر DNS فراموش شود، سایت باز می‌شود اما ایمیل قطع خواهد شد.

مرحله سوم: اندازه واقعی سایت را اندازه بگیرید

برای انتخاب روش انتقال این موارد را ثبت کنید:

  • حجم کل فایل‌ها
  • حجم wp-content/uploads
  • حجم فایل‌های دانلودی
  • اندازه دیتابیس
  • تعداد فایل و Inode
  • بزرگ‌ترین جدول‌ها
  • سرعت Upload و Download دو سرور

سایت ۱۰ گیگابایتی با صدها هزار فایل ریز ممکن است از سایت ۳۰ گیگابایتی با چند فایل بزرگ سخت‌تر منتقل شود.

مرحله چهارم: Backup کامل و قابل بازیابی

قبل از هر کار:

  • از دیتابیس Export کامل بگیرید.
  • تمام wp-content و فایل‌های Root را ذخیره کنید.
  • فایل wp-config.php و Ruleهای وب‌سرور را نگه دارید.
  • نسخه Backup را خارج از هر دو هاست ذخیره کنید.
  • Restore آن را روی محیط جدا آزمایش نمایید.

فروشگاه اطلاعات را هم در دیتابیس و هم در فایل‌ها نگه می‌دارد؛ محصولات، سفارش‌ها، نوشته‌ها و تنظیمات عمدتاً در دیتابیس‌اند و قالب، افزونه، Upload و فایل دانلودی در فایل‌سیستم قرار دارند.

راهنمای کامل در مقاله آموزش بکاپ و بازیابی وردپرس قرار دارد.

مرحله پنجم: TTL را پیش از Cutover کاهش دهید

TTL تعیین می‌کند Resolverها یک رکورد DNS را چه مدت Cache کنند. اگر TTL بلند باشد، بعضی کاربران پس از تغییر DNS همچنان به سرور قدیمی می‌روند.

روند عملی:

  1. حداقل یک دوره TTL پیش از مهاجرت، مقدار رکورد وب را کاهش دهید.
  2. رکوردهای ایمیل و سرویس‌های دیگر را بی‌دلیل تغییر ندهید.
  3. پس از پایدارشدن مهاجرت، TTL را به مقدار معمول برگردانید.

در Cloudflare، رکوردهای Proxied به‌طور پیش‌فرض TTL خودکار کوتاه دارند؛ اما Cache محلی کاربران و Resolverها ممکن است تغییر را دیرتر نشان دهند.

مرحله ششم: آماده‌سازی سرور جدید

  • دامنه یا Temporary URL را در پنل مقصد اضافه کنید.
  • نسخه PHP و Extensionها را تنظیم نمایید.
  • Database و User جدا بسازید.
  • SSL را در صورت امکان آماده کنید.
  • Permissionهای فایل را استاندارد نگه دارید.
  • Logهای PHP و وب‌سرور را فعال و قابل دسترسی کنید.
  • Backup خودکار مقصد را تنظیم نمایید.

از Permission عمومی 777 برای رفع خطای انتقال استفاده نکنید. فایل‌ها معمولاً با 644 و پوشه‌ها با 755 شروع می‌شوند، اما تنظیم نهایی به معماری هاست بستگی دارد.

روش اول: انتقال با ابزار شرکت هاست

بعضی شرکت‌ها مهاجرت را رایگان یا با ابزار خودکار انجام می‌دهند. قبل از واگذاری بپرسید:

  • آیا دیتابیس Delta در لحظه نهایی منتقل می‌شود؟
  • آیا فروشگاه در زمان Cutover Freeze خواهد شد؟
  • SSL و DNS را چه کسی مدیریت می‌کند؟
  • فایل‌های دانلودی و Cron بررسی می‌شوند؟
  • Rollback چگونه انجام می‌شود؟
  • مهاجرت شامل ایمیل‌های هاست قبلی نیز هست؟

پاسخ «سایت را کامل کپی می‌کنیم» برای فروشگاه کافی نیست؛ ترتیب عملیات و کنترل سفارش باید روشن باشد.

روش دوم: مهاجرت با افزونه

افزونه Migration می‌تواند فایل و دیتابیس را در یک Package منتقل کند. برای سایت کوچک مناسب است، اما محدودیت‌های زیر محتمل‌اند:

  • Timeout و Memory Limit
  • محدودیت حجم Upload
  • قطع‌شدن فرایند در فایل‌های بزرگ
  • عدم انتقال فایل خارج از WordPress
  • مشکل با Serialized Data یا Multisite
  • Push دیتابیس قدیمی روی فروشگاه فعال

معیار انتخاب افزونه:

  • پشتیبانی از WooCommerce و HPOS
  • توانایی Exclude Cache و Backup
  • انتقال Incremental یا Delta
  • Search‑Replace امن
  • Log و Resume
  • سازگاری با فایل‌های دانلودی بزرگ

روش سوم: انتقال دستی با cPanel و phpMyAdmin

کپی فایل‌ها

  1. فایل‌های سایت را Compress کنید.
  2. آرشیو را با SFTP یا Remote Transfer به مقصد ببرید.
  3. در Document Root صحیح Extract کنید.
  4. تعداد و حجم فایل‌ها را مقایسه نمایید.

آرشیو Backup را پس از تأیید از Web Root حذف کنید؛ فایل ZIP عمومی می‌تواند اطلاعات کامل سایت را افشا کند.

Export دیتابیس

در phpMyAdmin، Database صحیح را انتخاب و Export کامل SQL بگیرید. برای دیتابیس بزرگ از Compression و روش Custom استفاده کنید.

Import دیتابیس

Database مقصد را انتخاب و SQL را Import کنید. اگر محدودیت Upload دارید، از SSH، WP‑CLI یا ابزار Import مرحله‌ای هاست استفاده نمایید.

تنظیم wp-config.php

این مقادیر باید متعلق به دیتابیس مقصد باشند:

define( 'DB_NAME', 'new_database' );
define( 'DB_USER', 'new_user' );
define( 'DB_PASSWORD', 'strong-password' );
define( 'DB_HOST', 'localhost' );

مقدار واقعی را در مقاله، تیکت عمومی یا Git ثبت نکنید.

روش چهارم: مهاجرت با WP‑CLI و SSH

Export دیتابیس

wp db export before-migration.sql --add-drop-table

دستور از Credentialهای wp-config.php استفاده می‌کند. فایل SQL را خارج از Web Root نگه دارید.

انتقال فایل با rsync

rsync -avz --progress /path/to/site/ user@new-server:/path/to/site/

برای اجرای واقعی، مسیر، SSH Key، مالکیت فایل و Excludeها باید با مدیر سرور تنظیم شوند. Command نمونه را کورکورانه اجرا نکنید.

Import دیتابیس در مقصد

wp db import before-migration.sql

wp db import دیتابیس را ایجاد نمی‌کند؛ SQL را روی Database تعریف‌شده در wp-config.php اجرا می‌کند.

آیا هنگام تغییر هاست Search‑Replace لازم است؟

اگر دامنه و Protocol ثابت بمانند، معمولاً جایگزینی دامنه لازم نیست. بااین‌حال مسیر مطلق سرور، CDN یا Temporary URL ممکن است داخل تنظیمات ذخیره شده باشد.

اگر دامنه تغییر می‌کند، ابتدا Dry Run:

wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

پس از بررسی گزارش:

wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables-with-prefix --skip-columns=guid

این ابزار داده‌های PHP Serialized را مدیریت می‌کند و Primary Keyها را تغییر نمی‌دهد.

چرا Replace مستقیم داخل SQL خطرناک است؟

WordPress و افزونه‌ها آرایه‌ها و Objectها را به‌صورت Serialized ذخیره می‌کنند. طول رشته بخشی از ساختار داده است. Replace ساده می‌تواند طول را ناسازگار و Option، Widget یا تنظیم قالب را خراب کند.

مرحله هفتم: تست سرور جدید بدون تغییر DNS

بهترین روش، ویرایش موقت Hosts File روی کامپیوتر تست است تا فقط دستگاه شما دامنه را به IP سرور جدید Resolve کند.

نمونه ساختار:

203.0.113.10 example.com
203.0.113.10 www.example.com

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

چرا Temporary URL همیشه مناسب نیست؟

WordPress، Cookie، HTTPS، درگاه و CORS بر اساس دامنه واقعی رفتار می‌کنند. Temporary URL ممکن است Redirect، Mixed Content یا خطای Login ایجاد کند. Hosts File اجازه می‌دهد دامنه واقعی را روی سرور مقصد آزمایش کنید.

چک‌لیست تست پیش از Cutover

WordPress

  • صفحه اصلی، نوشته، دسته و جست‌وجو
  • ورود و خروج مدیر
  • آپلود رسانه
  • REST API و Cron
  • Permalink و 404
  • Header، Footer و WoodMart

WooCommerce

  • محصول ساده و دانلودی
  • Variation و موجودی
  • Cart و Checkout
  • حساب مشتری
  • کوپن و قیمت
  • Order آزمایشی
  • ایمیل تراکنشی
  • لینک دانلود
  • Action Scheduler

فنی

  • SSL و Mixed Content
  • PHP Error Log
  • LiteSpeed و Object Cache
  • فایل‌های قابل نوشتن
  • حجم Upload
  • Scheduled Taskها

تست درگاه پیش از تغییر DNS

Callback درگاه ممکن است فقط به دامنه عمومی دسترسی داشته باشد و Hosts File کامپیوتر شما روی سرور درگاه اثری ندارد. راهکارها:

  • استفاده از Sandbox یا Test Mode
  • ساخت Callback آزمایشی جدا
  • هماهنگی با ارائه‌دهنده درگاه
  • اجرای تراکنش کنترل‌شده پس از Cutover

درگاه Production را روی یک دامنه موقت عمومی بدون کنترل امنیتی آزمایش نکنید.

مرحله هشتم: Freeze و انتقال Delta نهایی

در لحظه نهایی باید از تولید داده جدید روی سرور قدیمی جلوگیری شود.

روش محافظه‌کارانه

  1. زمان مهاجرت را در ساعت کم‌ترافیک انتخاب کنید.
  2. Coming Soon یا Maintenance کنترل‌شده فعال نمایید.
  3. Checkout و Login مشتری را موقتاً متوقف کنید.
  4. آخرین Backup دیتابیس بگیرید.
  5. دیتابیس نهایی را روی مقصد Import کنید.
  6. فایل‌های جدید Upload و دانلود را Sync نمایید.
  7. تست سریع انجام دهید.
  8. DNS را تغییر دهید.

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

Delta فایل‌ها چیست؟

بین کپی اولیه و Cutover ممکن است تصویر، PDF، Log یا فایل جدید ساخته شود. با rsync می‌توان فقط فایل‌های تغییرکرده را منتقل کرد. اگر از File Manager استفاده می‌کنید، زمان آخرین تغییر Uploads و فایل‌های دانلودی را بررسی نمایید.

Delta دیتابیس برای فروشگاه

انتقال انتخابی سفارش‌ها پیچیده است؛ HPOS شامل چند جدول مرتبط، Order Item، مجوز دانلود، Analytics و Action Scheduler است. کپی دستی چند ردیف از جدول سفارش راهکار امنی نیست.

برای فروشگاه معمولی، Freeze کوتاه و Export نهایی کل دیتابیس امن‌تر است. برای فروشگاه پرترافیک باید از ابزار Migration تخصصی، Replication یا برنامه همگام‌سازی توسعه‌یافته استفاده شود.

HPOS در مهاجرت WooCommerce

در سایت فعلی HPOS فعال است و سفارش‌ها در جدول‌های اختصاصی WooCommerce ذخیره می‌شوند. هنگام مهاجرت:

  • تمام جدول‌های دارای Prefix منتقل شوند.
  • Database Version و Schema تطبیق داده شوند.
  • Compatibility Mode در صورت وجود بررسی شود.
  • سفارش با CRUD رسمی WooCommerce کنترل گردد.
  • Order Count و آخرین Order ID مقایسه شود.

Export فقط جدول posts و postmeta برای سفارش‌های HPOS کافی نیست.

فایل‌های دانلودی فروشگاه

برای فروش PDF یا فایل دیجیتال:

  • تمام فایل‌های Product Download منتقل شوند.
  • مسیر فایل و Permission بررسی شود.
  • روش Force Download یا X‑Accel/X‑Sendfile با سرور جدید سازگار باشد.
  • لینک دانلود یک سفارش قدیمی و جدید تست شود.
  • Hash و حجم فایل با منبع مقایسه گردد.

بازشدن محصول به معنی سالم‌بودن Download نیست.

مرحله نهم: تغییر DNS

اگر DNS Provider ثابت است، معمولاً رکورد A یا CNAME وب را به IP مقصد تغییر می‌دهید. اگر Nameserver نیز عوض می‌شود، باید تمام Zone قبلی را منتقل کنید.

قبل از Save

  • A و AAAA صحیح باشند.
  • www و دامنه اصلی هماهنگ باشند.
  • MX، SPF، DKIM و DMARC حفظ شوند.
  • رکوردهای Verification و API حذف نشده باشند.
  • DNSSEC با برنامه مدیریت شود.

تغییر Nameserver می‌تواند از چند دقیقه تا مدت بیشتری در Resolverهای مختلف دیده شود. در این دوره هر دو سرور باید آماده باشند.

سرور قدیمی را فوراً خاموش نکنید

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

روش‌ها:

  • نمایش Maintenance در Origin قدیمی
  • Redirect به دامنه اصلی در صورت امکان بدون Loop
  • محدودکردن Checkout
  • نگهداری Log برای مقایسه ترافیک باقی‌مانده

اگر هر دو سرور سفارش بپذیرند، دیتابیس‌ها Split‑Brain می‌شوند.

مرحله دهم: SSL در سرور جدید

پس از Resolveشدن دامنه:

  • گواهی دامنه اصلی و www را بررسی کنید.
  • زنجیره Certificate و تاریخ انقضا را کنترل نمایید.
  • HTTP را به HTTPS Redirect کنید.
  • HTTPS میان CDN و Origin نیز برقرار باشد.
  • Mixed Content را در Console بررسی کنید.

اگر Cloudflare استفاده می‌شود، حالت SSL باید با گواهی معتبر Origin هماهنگ باشد.

مرحله یازدهم: Cache و CDN

بعد از انتقال:

  • LiteSpeed Page Cache را Purge کنید.
  • Object Cache مقصد را پاک کنید.
  • CDN Cache را هدفمند Purge نمایید.
  • OPcache را Refresh کنید.
  • Cart، Checkout و My Account را از Cache عمومی خارج نگه دارید.

Cache قدیمی ممکن است Asset سرور قبلی یا صفحه Checkout نامعتبر نمایش دهد.

مرحله دوازدهم: ایمیل و SMTP

تغییر IP سرور می‌تواند تحویل ایمیل را تحت تأثیر قرار دهد. بررسی کنید:

  • SMTP خارجی همچنان متصل است.
  • Firewall خروجی Port موردنیاز را مسدود نمی‌کند.
  • SPF شامل سرویس صحیح است.
  • DKIM و DMARC تغییر نکرده‌اند.
  • Reverse DNS در ارسال مستقیم تنظیم است.
  • ایمیل New Order، Reset Password و Contact Form تحویل می‌شوند.

وضعیت Sent در WordPress به معنی رسیدن قطعی به Inbox نیست؛ Log SMTP و مقصد را نیز بررسی کنید.

راهنمای بیشتر در مقاله تنظیم ایمیل‌های ووکامرس و SMTP قرار دارد.

مرحله سیزدهم: Callback و Webhook

پس از Cutover یک تراکنش کنترل‌شده انجام دهید و این زنجیره را بررسی کنید:

  1. ایجاد سفارش
  2. ارسال به درگاه
  3. بازگشت به Callback
  4. تأیید Transaction
  5. تغییر Status سفارش
  6. کاهش موجودی
  7. ارسال ایمیل
  8. اعطای دسترسی دانلود

همچنین WooCommerce Webhook، Feed مارکت‌پلیس، Mailchimp و اتصال‌های سفارشی را بررسی نمایید.

مرحله چهاردهم: Cron و Action Scheduler

در هاست جدید ممکن است Loopback، Cron یا Permission متفاوت باشد.

  • Site Health را بررسی کنید.
  • wp cron test اجرا نمایید.
  • Scheduled Actions Pending و Failed را کنترل کنید.
  • System Cron را در cPanel مقصد بازسازی کنید.
  • Jobهای Import و Analytics را بررسی نمایید.

اگر DISABLE_WP_CRON فعال است ولی Cron سیستم مقصد ساخته نشده باشد، وظایف زمان‌بندی‌شده متوقف می‌شوند.

مرحله پانزدهم: SEO پس از مهاجرت

دامنه ثابت

  • Status Code و Canonical ثابت بماند.
  • Sitemap قابل دسترسی باشد.
  • Robots.txt ناخواسته Disallow نکرده باشد.
  • سرعت و خطاهای Crawl مانیتور شوند.

دامنه جدید

  • Redirect 301 یک‌به‌یک ساخته شود.
  • Canonical، Sitemap و Internal Link اصلاح گردند.
  • Search Console دامنه جدید تأیید شود.
  • Change of Address در صورت شرایط مناسب بررسی شود.
  • Redirect Chain و 404 رفع شوند.

Rank Math روی سایت فعلی فعال است؛ بعد از Migration باید Sitemap Cache، Redirectها و تنظیمات Local SEO کنترل شوند.

بررسی Rank Math Instant Indexing

در مهاجرت، ارسال انبوه URLهای قدیمی و جدید می‌تواند Rate Limit سرویس Indexing ایجاد کند. مهاجرت فنی را به ارسال مکرر دستی وابسته نکنید. ابتدا URLها، Sitemap و Status Code صحیح باشند؛ سپس موتور جست‌وجو Crawl را انجام می‌دهد.

مرحله شانزدهم: افزونه‌های سفارشی

در dev-source.ir چند افزونه سفارشی برای Import، پردازش PDF، مشخصات محصول و Checkout وجود دارد. برای هرکدام بررسی شود:

  • مسیر مطلق سرور داخل کد Hardcode نشده باشد.
  • Cron یا Queue در مقصد اجرا شود.
  • Permission پوشه موقت صحیح باشد.
  • Libraryهای PHP لازم نصب باشند.
  • Webhook و Tokenها معتبر باشند.
  • Log مستقل خطا داشته باشند.

کد سفارشی که روی هاست قبلی با Extension خاص کار می‌کرد، ممکن است در مقصد خطا دهد.

مقایسه داده قبل و بعد از مهاجرت

  • تعداد Post و Page
  • تعداد Product و Variation
  • تعداد User و Customer
  • تعداد Order براساس Status
  • آخرین Order ID و تاریخ
  • موجودی محصولات حساس
  • تعداد Media و حجم Uploads
  • تعداد Scheduled Action Failed
  • حجم جدول‌های اصلی

فقط مقایسه اندازه کل دیتابیس کافی نیست؛ تفاوت Engine و Overhead ممکن است اندازه را تغییر دهد.

Smoke Test بعد از DNS Switch

  • صفحه اصلی و محصول از اینترنت عمومی باز می‌شوند.
  • DNS به IP مورد انتظار Resolve می‌شود.
  • SSL معتبر است.
  • ورود مدیر انجام می‌شود.
  • Cart و Checkout سالم‌اند.
  • درگاه و Callback کار می‌کنند.
  • ایمیل سفارش تحویل می‌شود.
  • فایل دانلودی قابل دریافت است.
  • PHP و WooCommerce Log خطای جدید ندارند.
  • Uptime Monitor سرور جدید را می‌بیند.

مانیتورینگ ۷۲ ساعت پس از مهاجرت

در سه روز اول این موارد را با دقت بیشتری بررسی کنید:

  • خطاهای ۵۰۰، ۵۰۲، ۵۰۳ و ۵۰۴
  • Failed Payment و Pending Payment
  • Callbackهای ناموفق
  • Actionهای Failed
  • مصرف CPU، RAM، I/O و Disk
  • SMTP Error و Bounce
  • 404 فایل و تصویر
  • Core Web Vitals و TTFB
  • ترافیک باقی‌مانده روی سرور قدیمی

مقاله مانیتورینگ وردپرس و بررسی لاگ‌ها برای این مرحله مفید است.

چه زمانی هاست قدیمی را لغو کنیم؟

پس از این تأییدها:

  • DNS در Resolverهای اصلی به مقصد اشاره می‌کند.
  • هیچ سفارش جدیدی روی سرور قدیمی ثبت نشده است.
  • Backup مستقل از سایت قدیمی دارید.
  • ایمیل‌ها و DNS Zone کامل منتقل شده‌اند.
  • حداقل چند روز سرویس جدید پایدار بوده است.
  • تمام فایل‌های دانلودی و Logهای لازم منتقل شده‌اند.

لغو عجولانه هاست قبلی Rollback و بازیابی فایل جاافتاده را دشوار می‌کند.

Rollback مهاجرت

پیش از Cutover، معیار بازگشت را مشخص کنید؛ برای مثال:

  • Checkout بیش از چند دقیقه از کار افتاده است.
  • دیتابیس خطای جدی دارد.
  • فایل‌های دانلودی قابل بازیابی نیستند.
  • درگاه Callback را تأیید نمی‌کند.

Rollback DNS

رکورد را به IP قبلی برگردانید. به‌دلیل Cache، اثر آن فوری برای همه کاربران نیست.

Rollback داده

اگر سرور جدید سفارش گرفته باشد، بازگشت ساده به دیتابیس قبلی آن سفارش‌ها را حذف می‌کند. بنابراین Rollback پس از بازکردن Checkout نیازمند همگام‌سازی داده یا Maintenance مجدد است.

اشتباهات رایج مهاجرت

  • تغییر DNS قبل از تست سرور مقصد
  • کپی دیتابیس قدیمی و فراموش‌کردن سفارش‌های جدید
  • بازگذاشتن Checkout روی هر دو سرور
  • حذف هاست قبلی در همان روز
  • فراموش‌کردن MX، SPF و DKIM
  • Replace مستقیم Serialized Data
  • انتقال ناقص فایل‌های دانلودی
  • فعال‌نکردن SSL Origin
  • فراموش‌کردن Cron سیستم
  • تغییر هم‌زمان هاست، دامنه، PHP و قالب
  • Purge نکردن Cache و CDN
  • اعتماد به صفحه اصلی به‌عنوان تنها تست

خطا: Error Establishing a Database Connection

نام دیتابیس، User، Password، Host، Permission User و فعال‌بودن Database Server را بررسی کنید. Credentialها باید مربوط به مقصد باشند.

خطا: سایت به Temporary URL یا دامنه قدیمی Redirect می‌شود

home، siteurl، Search‑Replace، Cache، Rule وب‌سرور و تنظیم قالب را بررسی کنید.

خطا: صفحه سفید یا Critical Error

نسخه PHP، Extension، Memory، Plugin و Error Log را بررسی کنید. تفاوت نسخه PHP یکی از علت‌های رایج پس از مهاجرت است.

خطا: تصاویر 404 می‌شوند

پوشه Uploads ناقص، Permission اشتباه، مسیر Hardcode یا CDN قدیمی محتمل است. تعداد فایل و آدرس Attachment را بررسی نمایید.

خطا: Checkout کار می‌کند اما پرداخت تأیید نمی‌شود

Callback، WAF، SSL، IP مقصد، Clock سرور و Log درگاه را بررسی کنید. ممکن است درگاه هنوز Origin قدیمی یا Rule امنیتی ناسازگار ببیند.

خطا: ایمیل بعد از مهاجرت ارسال نمی‌شود

SMTP، Port خروجی، DNS ایمیل، From Address و Log را کنترل کنید. تغییر IP می‌تواند Reputation ارسال مستقیم را تغییر دهد.

خطا: Cron و Action Scheduler متوقف شده‌اند

System Cron، Loopback، Constantهای wp-config، Timezone و PHP CLI مقصد را بررسی کنید.

خطا: بعضی کاربران هنوز سرور قدیمی را می‌بینند

DNS Cache، TTL، ISP Resolver، Browser Cache یا Proxy علت است. سرور قدیمی را در حالت امن نگه دارید و انتظار Propagation را در برنامه لحاظ کنید.

خطا: سرعت سایت در هاست جدید بدتر شده است

  • Cache گرم نشده است.
  • Object Cache فعال نیست.
  • PHP Worker کمتر است.
  • Database تنظیم مناسبی ندارد.
  • CDN یا DNS اشتباه است.
  • Image Optimization Queue دوباره اجرا می‌شود.

Baseline قبل از مهاجرت را با همان صفحات و شرایط مقایسه کنید.

برنامه پیشنهادی مهاجرت dev-source.ir

  1. سرور مقصد با PHP و LiteSpeed سازگار آماده شود.
  2. Backup کامل فایل، دیتابیس و فایل‌های PDF خارج از هاست ذخیره گردد.
  3. DNS Zone، ایمیل، درگاه و اتصال‌های خارجی مستند شوند.
  4. کپی اولیه با SFTP/rsync و WP‑CLI انجام شود.
  5. مقصد با Hosts File و دامنه واقعی تست گردد.
  6. HPOS، سفارش، دانلود و افزونه‌های سفارشی بررسی شوند.
  7. TTL پیش از Cutover کاهش یابد.
  8. در ساعت کم‌ترافیک Checkout موقتاً متوقف شود.
  9. دیتابیس و فایل‌های Delta نهایی منتقل شوند.
  10. DNS تغییر کند و تراکنش کنترل‌شده انجام شود.
  11. ایمیل، Torob، Mailchimp، Royal MCP و Cron بررسی شوند.
  12. سرور قدیمی چند روز در حالت بدون ثبت سفارش نگه داشته شود.
  13. پس از پایداری، TTL به مقدار عادی برگردد و هاست قدیمی آرشیو شود.

چک‌لیست نهایی انتقال وردپرس

  • مقصد از نظر PHP و Database سازگار است.
  • Backup فایل و دیتابیس Restore شده و معتبر است.
  • TTL پیش از مهاجرت کاهش یافته است.
  • فایل و دیتابیس اولیه منتقل شده‌اند.
  • سرور جدید با Hosts File تست شده است.
  • SSL، Permalink و Cache سالم‌اند.
  • Checkout هنگام Delta Freeze می‌شود.
  • HPOS و همه جدول‌های افزونه منتقل شده‌اند.
  • فایل‌های دانلودی کامل‌اند.
  • Callback و Webhook تست شده‌اند.
  • SMTP و DNS ایمیل سالم‌اند.
  • Cron و Action Scheduler اجرا می‌شوند.
  • Order Count و آخرین سفارش مقایسه شده‌اند.
  • سرور قدیمی فوراً حذف نشده است.
  • Rollback مستند و قابل اجراست.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و بهینه‌سازی دیتابیس وردپرس

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

انتقال وردپرس چقدر طول می‌کشد؟

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

آیا با تغییر هاست رتبه گوگل افت می‌کند؟

اگر دامنه، URL، Status Code و محتوا ثابت بمانند و قطعی طولانی رخ ندهد، تغییر هاست به‌تنهایی نباید ساختار سئو را عوض کند. سرعت و دسترسی جدید باید مانیتور شوند.

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

برای سایت کم‌ترافیک ممکن است کافی باشد، اما باید HPOS، سفارش‌های جدید، فایل دانلودی، درگاه و Delta نهایی را پشتیبانی کند.

آیا باید دامنه را به شرکت هاست جدید منتقل کنیم؟

خیر. Registrar دامنه می‌تواند مستقل بماند و فقط DNS یا رکورد وب تغییر کند.

چرا Checkout باید موقتاً بسته شود؟

برای جلوگیری از ثبت سفارش روی دیتابیس قدیمی در فاصله Export نهایی تا Cutover.

آیا Search‑Replace برای تغییر IP لازم است؟

معمولاً خیر، چون URL دامنه ثابت است. فقط مسیرها یا URLهای Hardcodeشده باید بررسی شوند.

چه زمانی هاست قبلی را حذف کنیم؟

بعد از پایداری سرور جدید، تکمیل Propagation، تأیید سفارش و ایمیل و داشتن Backup مستقل.

جمع‌بندی

انتقال وردپرس به هاست جدید زمانی موفق است که نه‌تنها صفحه اصلی، بلکه سفارش، پرداخت، ایمیل، دانلود، Cron، SEO و افزونه‌های سفارشی روی سرور مقصد بدون خطا کار کنند. مهم‌ترین ریسک فروشگاه، ثبت داده هم‌زمان در دو سرور است؛ بنابراین Freeze کوتاه Checkout و انتقال Delta نهایی بخش اصلی Cutover هستند.

ابتدا مقصد را آماده و با Hosts File تست کنید، سپس TTL را کاهش دهید، Backup قابل بازیابی داشته باشید، فایل و دیتابیس نهایی را در بازه کنترل‌شده منتقل کنید و بعد DNS را تغییر دهید. سرور قدیمی را تا پایان مانیتورینگ حفظ کنید تا امکان Rollback و بازیابی فایل وجود داشته باشد.

برای سایت فعلی، HPOS، درگاه آنلاین، فایل‌های دانلودی، LiteSpeed و افزونه‌های سفارشی باعث می‌شوند مهاجرت باید با چک‌لیست اختصاصی و تست تراکنش واقعی کنترل‌شده انجام شود؛ کپی ساده cPanel بدون برنامه حفظ سفارش کافی نیست.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.
✈️ کانال تلگرام🟣 کانال روبیکا
جدیدتر
آموزش رفع خطای Critical Error و 500 در وردپرس؛ عیب‌یابی افزونه، قالب، PHP و ووکامرس
بازگشت به لیست
قدیمی تر آموزش ساخت Staging وردپرس؛ کلون سایت، تست تغییرات و انتقال امن به سایت اصلی

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *