آموزش گام‌به‌گام مهاجرت سایت وردپرسی

یک بار در حال مهاجرت یک فروشگاه اینترنتی به یک هاست جدید بودم که در وسط کار متوجه شدم بیش از چهارصد تصویر در مسیرهای اشتباه ذخیره شده‌اند و دیتابیس هم چند افزونهٔ حذف‌شده را در خود نگه داشته بود. انتقال فایل‌ها و دیتابیس، بخش سادهٔ ماجرا بود؛ چیزی که ساعت‌ها وقت برد، پاک‌سازی همان بدهی فنیِ پنهان بود. مهاجرت وردپرس را می‌توان در دو ساعت انجام داد، ولی اگر آماده نباشید، می‌تواند چند روز طول بکشد — و بدتر از آن، بخشی از ترافیک ارگانیک شما را هم با خودش ببرد. این آموزش گام‌به‌گام، همان چک‌لیستی است که امروز روی همهٔ پروژه‌های مهاجرت اجرا می‌کنم. اگر تازه با مهاجرت روبه‌رو شده‌اید، پیش از هر اقدام، مقالهٔ چگونه قالب وردپرس را بدون آسیب به سایت تغییر دهیم را بخوانید؛ چون منطق «محیط تست قبل از اقدام روی زنده» در مهاجرت هم دقیقاً همان است.

مهاجرت در چه شرایطی لازم می‌شود؟

در تجربهٔ کاری من، پنج سناریو بیشترین دلیل مهاجرت هستند:

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

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

مهاجرت، آزمایش توانایی شما در مدیریت ریسک است؛ نه سرعت.

انواع مهاجرت: هاست، دامنه، هر دو

سه سناریوی اصلی مهاجرت، سه سطح پیچیدگی دارند:

مهاجرت فقط هاست: دامنه ثابت می‌ماند، فایل‌ها و دیتابیس به سرور جدید می‌روند. ساده‌ترین سناریو.
مهاجرت فقط دامنه: فایل‌ها و دیتابیس ثابت می‌مانند، ولی آدرس عوض می‌شود. نیاز به جایگزینی URLها در دیتابیس و ریدایرکت ۳۰۱ دارد.
مهاجرت هم هاست و هم دامنه: ترکیب دو حالت بالا. پیچیده‌ترین سناریو، ولی با چک‌لیست درست، مدیریت‌پذیر.

در هر سه سناریو، اصل طلایی یکی است: هرگز روی سایت زنده کار نکنید. همیشه یک محیط آزمایشی (staging) بسازید و کل فرآیند را قبل از اقدام نهایی روی همان محیط تمرین کنید. اگر هاست فعلی شما قابلیت staging دارد، عالی است؛ اگر نه، یک زیردامنه روی هاست جدید بسازید و همانجا تمرین کنید.

مرحلهٔ صفر: پیش از هر کاری

قبل از شروع، این پنج کار انجام می‌شود:

بکاپ کامل: هم فایل‌ها و هم دیتابیس. همیشه قبل از هر تغییر بزرگ. اگر مطمئن نیستید چطور، راهنمای چگونه از سایت وردپرسی بکاپ بگیریم گام‌به‌گام توضیح می‌دهد.
ثبت وضعیت فعلی: یک اسکرین‌شات از پیشخوان، فهرست افزونه‌های فعال، لیست کاربران و صفحهٔ اصلی سایت بگیرید. بعد از مهاجرت، همین‌ها مرجع مقایسه هستند.
بررسی فضای هاست جدید: مطمئن شوید هاست جدید نسخهٔ PHP، فضای دیسک و پیکربندی لازم برای وردپرس را دارد. معیارهای هاست وردپرس را در بهترین هاست برای وردپرس آورده‌ام.
بررسی پروندهٔ امنیتی: مطمئن شوید سایت مهاجرت‌شده از بدافزار پاک است. مهاجرت با بدافزار، یعنی انتقال بدافزار به سرور جدید.
اطلاع‌رسانی به تیم: اگر سایت بخش تجاری دارد، قبل از مهاجرت به مشتریان و تیم پشتیبانی اطلاع دهید که ممکن است یک بازهٔ کوتاه اختلال وجود داشته باشد.

انتقال فایل‌ها

دو مسیر اصلی برای انتقال فایل‌ها وجود دارد. مسیر اول، انتقال با ابزار File Manager پنل هاست (که در cPanel چیست و چه کاربردی دارد توضیح داده‌شده): کل پوشهٔ public_html را دانلود می‌کنید و در هاست جدید آپلود می‌کنید. برای سایت‌های کوچک و متوسط، این روش کاملاً کافی است. مسیر دوم، انتقال با FTP (File Transfer Protocol — پروتکل انتقال فایل) یا با ابزار rsync روی سرور. مسیر دوم برای سایت‌های بزرگ با هزاران فایل تصویر، بسیار سریع‌تر و پایدارتر است.

یک نکتهٔ حیاتی که در پروژه‌های واقعی بارها با آن مواجه شدم: قبل از انتقال، فایل‌های موقت هاست قبلی (مثل فایل‌های .log، پوشه‌های کش و نسخه‌های قدیمی افزونه‌ها) را حذف کنید. این کار حجم انتقال را گاهی بیش از نصف کاهش می‌دهد و از انتقال آشغال‌های فنی جلوگیری می‌کند.

انتقال دیتابیس

دیتابیس، قلب مهاجرت است. اگر دیتابیس ناقص منتقل شود، حتی سایت بالا می‌آید ولی نیمی از محتوا نیست. سه روش رایج:

phpMyAdmin: هم در پنل هاست فعلی و هم در هاست جدید موجود است. دیتابیس را Export می‌کنید (با پسوند .sql) و در هاست جدید Import می‌کنید. مناسب برای دیتابیس‌های تا حدود ۵۰۰ مگابایت.
خط فرمان با mysqldump: برای دیتابیس‌های بزرگ، پایدارترین روش. با یک دستور روی سرور، دیتابیس dump می‌شود و در هاست جدید import می‌شود.
افزونه‌های مهاجرت: ابزارهایی مثل All-in-One WP Migration یا Duplicator که هم فایل‌ها و هم دیتابیس را در یک بسته منتقل می‌کنند. برای کاربران غیرفنی، ساده‌ترین گزینه است.

# نمونهٔ استفاده از mysqldump
mysqldump -u user -p dbname > backup.sql

# import در سرور جدید
mysql -u newuser -p newdbname < backup.sql

نکتهٔ فنی: اگر روی هاست فعلی چند سایت روی یک دیتابیس دارید، حتماً پیشوند جدول‌های خودتان (wp_ یا هر پیشوند دیگری) را دقیقاً مطابق قبل نگه دارید. تغییر پیشوند در زمان مهاجرت، بی‌دلیل پیچیدگی اضافه می‌کند.

جایگزینی URLها در دیتابیس

اگر فقط هاست عوض شده و دامنه ثابت است، این مرحله لازم نیست. ولی اگر دامنه تغییر کرده، در دیتابیس وردپرس هزاران رکورد وجود دارد که آدرس سایت در آن‌ها ذخیره شده. این رکوردها در جدول wp_options، در متادیتا، در تنظیمات افزونه‌ها و در محتوای نوشته‌ها پراکنده‌اند. هیچ‌وقت این جایگزینی را با کوئری سادهٔ UPDATE انجام ندهید؛ چون برخی از این داده‌ها به‌صورت serialize ذخیره شده‌اند و جایگزینی ساده، ساختار آن‌ها را می‌شکند. ابزار درست، افزونهٔ Better Search Replace است که serialize data را هم می‌فهمد:

// جست‌وجوی امن URL قدیمی و جایگزینی با جدید
// Search: https://old-domain.com
// Replace: https://new-domain.com
// Tables: wp_posts, wp_postmeta, wp_options, wp_usermeta

قبل از این مرحله، یک بکاپ از دیتابیس بگیرید. اگر سرچ-اند-ریپلیس اشتباه انجام شود، بازگشت به عقب بدون بکاپ غیرممکن است.

تنظیم DNS و انتقال دامنه

DNS (Domain Name System — سیستم نام دامنه) نقشهٔ آدرس‌ها است که مرورگر با آن می‌فهمد سایت شما کجا میزبانی می‌شود. اگر فقط هاست عوض شده، کافی است در پنل دامنه، رکورد A را به IP هاست جدید تغییر دهید. اگر دامنه را هم منتقل می‌کنید، ابتدا باید در هاست قبلی، رکوردهای DNS را یادداشت کنید و بعد از انتقال، همان‌ها را در هاست جدید بازسازی کنید. تغییرات DNS معمولاً بین ۳۰ دقیقه تا ۴۸ ساعت طول می‌کشد که به آن پروپاگیشن (Propagation — انتشار) می‌گویند. توضیح کامل رکوردها در رکوردهای DNS کدامند؟ آمده است. توصیهٔ عملی من: قبل از تغییر DNS، TTL رکوردها را روی یک مقدار کوتاه (مثلاً ۳۰۰ ثانیه) بگذارید تا تغییر سریع‌تر منتشر شود؛ بعد از تثبیت، می‌توانید مقدار را به حالت عادی برگردانید.

جدول انواع مهاجرت و پیچیدگی‌شان

نوع مهاجرت	پیچیدگی	مدت تقریبی	ریسک اصلی
فقط هاست، دامنه ثابت	پایین	۲ تا ۴ ساعت	فراموش کردن فایل‌های پنهان
فقط دامنه، هاست ثابت	متوسط	۴ تا ۸ ساعت	ریدایرکت ناقص و از دست رفتن سئو
هاست + دامنه	بالا	۱ تا ۲ روز	ترکیب دو ریسک بالا
از سیستم دیگر به وردپرس	بالا	۱ تا ۳ روز	نقشه‌برداری محتوا و ساختار
فقط انتقال ایمیل	پایین	۲ تا ۴ ساعت	تنظیم رکورد MX و SPF

بعد از مهاجرت: ۱۰ بررسی ضروری

صفحهٔ اصلی باز می‌شود و محتوا نمایش داده می‌شود؟
پیشخوان وردپرس با یوزر و پسورد قبلی باز می‌شود؟
تصاویر منتقل‌شده در کتابخانه رسانه دیده می‌شوند؟
فرم تماس کار می‌کند؟ (با ارسال یک پیام واقعی)
لینک‌های داخلی هیچ‌کدام ۴۰۴ نمی‌دهند؟ (روشش در خطای ۴۰۴ در وردپرس)
دیتابیس اتصال دارد و افزونه‌های حیاتی کار می‌کنند؟
فایل wp-config.php اطلاعات دیتابیس جدید را دارد؟
گواهی SSL فعال است و مرورگر هیچ هشدار امنیتی نمی‌دهد؟
سرعت سایت با همان معیارهای قبل قابل مقایسه است؟ (روش تست در ابزارهای تست سرعت سایت کدامند؟)
ایمیل‌های تراکنشی (مثل ایمیل فرم تماس) درست ارسال می‌شوند؟

توصیهٔ من این است که این ده مورد را در یک فایل چک‌لیست بگذارید و دقیقاً به ترتیب انجام دهید. یکی از اشتباهات رایج، پرش از روی برخی موارد به‌دلیل «مطمئن بودن» است؛ ولی تجربه نشان داده که حتی در پروژه‌های باتجربه هم گاهی یک رکورد فراموش می‌شود.

مهاجرت و سئو: نکات حیاتی

اگر مهاجرت شامل تغییر دامنه است، سه اقدام سئویی الزامی است:

ریدایرکت ۳۰۱ از دامنهٔ قدیم به جدید: هر URL قدیمی باید به معادل دقیق خودش در دامنهٔ جدید برود، نه به صفحهٔ اصلی. این نکته را در پروژه‌های واقعی بارها دیده‌ام که نادیده گرفته می‌شود و ترافیک دامنهٔ قدیمی از بین می‌رود.
به‌روزرسانی Search Console: دامنهٔ جدید را به‌عنوان Property اضافه کنید و آدرس تغییر را ثبت کنید. این ابزار به گوگل می‌گوید که تغییر دامنه اتفاق افتاده و باید اعتبار منتقل شود.
به‌روزرسانی sitemap و robots: بعد از مهاجرت، sitemap جدید را در Search Console ثبت کنید و در فایل robots.txt، آدرس دامنهٔ جدید را قرار دهید.

یک نکتهٔ عملی که در پروژه‌های خودم زیاد استفاده می‌کنم: در دو هفتهٔ اول بعد از مهاجرت، هر روز گزارش Coverage را در Search Console نگاه کنید. اگر تعداد خطاها به‌سرعت بالا رفت، یعنی جایی از ریدایرکت ناقص مانده. عکس این هم صادق است: اگر بعد از دو هفته هیچ نوسانی ندید، احتمالاً مهاجرت تمیز انجام شده. در یکی از پروژه‌های مشابه، همین دو هفته پایش روزانه، اجازه داد یک ریدایرکت ناقص که فقط دو درصد URLها را می‌گرفت، در همان روزهای اول پیدا شود — در حالی‌که اگر یک ماه بعد متوجه می‌شدیم، بازگرداندن اعتبار آن URLها ماه‌ها زمان می‌برد.

اشتباهات پرهزینه در مهاجرت

مهاجرت بدون بکاپ: بدترین اشتباه. حتی با تجربه، همیشه امکان دارد چیزی خراب شود.
نادیده گرفتن فایل‌های پنهان: فایل‌هایی مثل .htaccess، wp-config.php و فایل‌های مخفی دیگر، گاهی در انتقال دستی فراموش می‌شوند.
تغییر DNS قبل از آماده بودن هاست جدید: اگر هاست جدید هنوز آماده نیست و DNS را عوض کنید، سایت برای ساعاتی از دسترس خارج می‌شود.
جایگزینی URL با کوئری خام: ساختار serialize داده‌ها را می‌شکند.
فراموش کردن ایمیل‌ها: انتقال هاست فقط یعنی انتقال سایت، نه ایمیل. اگر از ایمیل هاست استفاده می‌کنید، باید رکوردهای MX، SPF و DKIM را هم منتقل کنید — توضیح رکوردها در رکوردهای DNS.
حذف هاست قدیم بلافاصله: حداقل دو هفته هاست قدیم را فعال نگه دارید تا در صورت بروز مشکل، بازگشت امکان‌پذیر باشد.

نگاه از لایهٔ عمیق‌تر: مهاجرت به‌عنوان پروژهٔ معماری

در نگاه یک توسعه‌دهندهٔ ارشد، مهاجرت وردپرس فقط انتقال فایل و دیتابیس نیست؛ یک «پروژهٔ کوچک معماری» است که سه لایه را هم‌زمان تحت تأثیر قرار می‌دهد: لایهٔ زیرساخت (سرور، DNS، SSL)، لایهٔ داده (دیتابیس، فایل‌ها، تنظیمات) و لایهٔ نمایش (URLها، ریدایرکت‌ها، سئو). موفقیت در هر لایه، پیش‌نیاز لایهٔ بعدی است. اگر زیرساخت درست آماده نباشد، انتقال داده با شکست مواجه می‌شود؛ اگر داده کامل منتقل نشود، لایهٔ نمایش هم ناقص ظاهر می‌شود.

در پروژه‌های حرفه‌ای، توصیه می‌کنم مهاجرت را در یک محیط staging اجرا کنید و آن را به‌عنوان یک «تغییر نسخه» ثبت کنید: با تاریخ، با مسئول، با چک‌لیست و با برنامهٔ rollback. اگر تیم شما از ابزارهای مدیریت پروژه استفاده می‌کند، مهاجرت باید یک تسک مشخص باشد، نه چند کار پراکنده. یک الگوی کوچک که در پروژه‌های خودم استفاده می‌کنم: قبل از اجرای نهایی، یک نسخه از همه‌چیز روی staging تمرین می‌شود و بعد از موفقیت، تنها تفاوت کوچک، تغییر DNS نهایی است. این روش، ریسک را از چند ساعت پرتنش به چند دقیقهٔ قابل کنترل تبدیل می‌کند. در یکی از پروژه‌های بزرگ انتقال، همین تمرین روی staging باعث شد یک تداخل بین دو افزونه که فقط روی سرور جدید خودش را نشان می‌داد، در همان مرحلهٔ آزمایش کشف شود؛ چیزی که اگر روی سایت زنده می‌رفت، می‌توانست یک روز فروش را از دست بدهد.

نکتهٔ سوم در این لایه، برنامه‌ریزی برای آینده است. مهاجرت را فرصتی برای پاک‌سازی بدهی فنی در نظر بگیرید: افزونه‌های غیرضروری را حذف کنید، دیتابیس را از داده‌های اضافی پاک کنید، و ساختار فایل‌ها را مرتب کنید. این کار در چند ساعت انجام می‌شود ولی ماه‌ها صرفه‌جویی در زمان نگهداری و بهبود در سرعت سایت به‌همراه دارد. برای دیتابیس، راهنمای کامل پاک‌سازی در چگونه دیتابیس وردپرس را پاک‌سازی کنیم؟ و برای بهینه‌سازی سرعت بعد از مهاجرت، چگونه سرعت سایت وردپرسی را افزایش دهیم؟ مسیر طبیعی بعدی هستند. در نهایت، قاعده‌ای که در همهٔ پروژه‌ها روی آن تأکید می‌کنم: مهاجرت خوب، مهاجرتی است که بعد از آن، کسی از کاربران نفهمد تغییری رخ داده است.

اگر روی یک مهاجرت خاص به چالشی خورده‌اید — مثلاً انتقال فروشگاهی با هزاران تصویر، یا ادغام دو سایت وردپرسی — سناریوی دقیقش را در دیدگاه بنویسید. تجربه‌های واقعی در این حوزه، همان‌قدر که به من در پروژه‌های بعدی کمک کرد، می‌تواند برای خوانندهٔ بعدی هم ارزشمند باشد. 🚚