چگونه یک WordPress را به وردپرس دیگری منتقل کنیم؟

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

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

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

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

انتقال بین دو نصب همسان، ظاهراً ساده است؛ اما در واقع تمام دام‌های مهاجرت را در خود جمع کرده است.

سه سناریوی متفاوت این نوع انتقال

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

سناریو اول: لوکال یا استیجینگ به سایت اصلی

این سناریو زمانی رخ می‌دهد که سایتی را روی محیط توسعه ساخته‌اید و می‌خواهید به سایت زنده منتقل کنید. مهم‌ترین تصمیم: آیا سایت زنده داده دارد یا نه. اگر سایت زنده تازه نصب شده و خالی است، انتقال ساده‌تر است. اگر سایت زنده داده یا کاربرانی دارد، باید منطق Merge یا Override را مشخص کنید. در این سناریو، اغلب انتقال کامل جایگزین است، یعنی دیتابیس سایت زنده پاک و از نسخه لوکال جایگزین می‌شود. جزئیات این مسیر در انتقال سایت از لوکال به هاست کامل آمده است.

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

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

سناریو سوم: بازسازی از صفر روی نصب جدید

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

گام صفر: آماده‌سازی قبل از هر کاری

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

بکاپ کامل و تست‌شده

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

فهرست وابستگی‌ها

قبل از انتقال، فهرستی از وابستگی‌ها بسازید: افزونه‌های فعال، قالب فعال، نسخه PHP و MySQL، محل ذخیره آپلودها، و آدرس‌های ایمیل. این فهرست در سایت مقصد باید یک‌به‌یک بررسی شود. تجربه‌ام این است که در نود درصد موارد، اختلاف نسخه PHP بین مبدأ و مقصد، منبع اصلی دردسرهای بعدی است.

برنامه بازگشت

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

روش‌های انتقال: دستی، افزونه‌ای، WP-CLI

سه روش اصلی برای انتقال بین دو نصب وردپرس وجود دارد که هرکدام برای سناریوی خاصی مناسب است.

روش افزونه‌ای

افزونه‌های مهاجرت مثل All-in-One WP Migration یا Duplicator، فایل‌ها و دیتابیس را در یک بسته بسته‌بندی می‌کنند و در سایت مقصد باز می‌کنند. این روش، برای سایت‌های کوچک و متوسط (تا حدود ۱ گیگابایت) سریع‌ترین و کم‌دردسرترین است. اما در سایت‌های بزرگ، محدودیت‌های آپلود فایل و محدودیت‌های حافظه PHP می‌تواند مانع ایجاد کند. تجربه‌ام: این روش برای ۹۰ درصد پروژه‌ها کافی است.

روش دستی

روش دستی، فایل‌ها را با FTP و دیتابیس را با phpMyAdmin منتقل می‌کند. این روش برای سایت‌های بزرگ (بیش از ۵ گیگابایت) انتخاب بهتری است چون کنترل کامل روی هر مرحله دارید. مسیر گام‌به‌گام در همان راهنمای انتقال به هاست جدید که پیش‌تر لینکش را گذاشتم، آمده است.

روش WP-CLI

برای توسعه‌دهندگان و تیم‌های فنی، WP-CLI سریع‌ترین و دقیق‌ترین روش است. با دستوراتی مثل wp db export، wp db import و wp search-replace، انتقال در چند دقیقه انجام می‌شود و خطاهای انسانی به حداقل می‌رسد. اگر با ساختار فنی وردپرس آشنا هستید، این روش انتخاب اول من است. اگر به مفاهیم پایه علاقه‌مند هستید، توسعه وردپرس چیست و از کجا شروع کنیم مسیر یادگیری WP-CLI را نشان می‌دهد.

انتقال دیتابیس و تفاوت‌های آن

انتقال دیتابیس، قلب عملیات مهاجرت است. هر خطای کوچک در این مرحله می‌تواند به خرابی سایت منجر شود. سه نکته کلیدی در این بخش وجود دارد.

Export و Import با کاراکترست درست

دیتابیس را با فرمت SQL از مبدأ Export کنید و در مقصد Import کنید. مهم‌ترین نکته، کاراکترست است. اگر سایت شما فارسی است و دیتابیس با کاراکترست اشتباه Import شود، متن‌های فارسی به علامت‌های نامفهوم تبدیل می‌شوند. همیشه utf8mb4 را انتخاب کنید. اگر با مفهوم کاراکترست و کالیشن آشنا نیستید، در میان‌افزار پنل هاست معمولاً به‌صورت پیش‌فرض تنظیم شده است، اما در Import دستی باید دقت کنید.

جایگزینی پیشوند جدول

اگر پیشوند جدول‌های سایت مبدأ و مقصد متفاوت باشد، باید قبل از Import، پیشوند را در فایل SQL جایگزین کنید. مثلاً اگر مبدأ wp_ و مقصد site_ باشد، همه رکوردهای wp_posts به site_posts تغییر می‌کند. این کار با ابزارهایی مثل Notepad++ یا با دستور wp search-replace انجام می‌شود. نکته حساس: پیشوند در فایل wp-config.php سایت مقصد باید با پیشوند جدید یکسان باشد، وگرنه سایت به دیتابیس متصل نمی‌شود.

تعداد رکوردها و تست پس از Import

پس از Import، تعداد رکوردهای اصلی را در phpMyAdmin چک کنید. مثلاً تعداد پست‌ها، کاربران و سفارش‌ها باید با مبدأ برابر باشد. اگر تفاوت وجود دارد، احتمالاً Import نیمه‌کاره انجام شده یا با timeout سرور قطع شده است. برای بازبینی دقیق دیتابیس و حذف داده‌های اضافی، چگونه دیتابیس وردپرس را پاک‌سازی کنیم راهنمای مناسبی است. اگر به‌صورت جداگانه فقط دیتابیس را منتقل می‌کنید، مهاجرت دیتابیس وردپرس به سرور جدید این مسیر را با جزئیات بیشتری توضیح می‌دهد.

فایل‌ها، رسانه و کتابخانه تصاویر

پس از دیتابیس، نوبت به فایل‌های سرور می‌رسد. پوشه wp-content مهم‌ترین بخش است چون شامل افزونه‌ها، قالب‌ها و آپلودها می‌شود. هسته وردپرس را معمولاً به‌صورت تازه نصب می‌کنیم (نه کپی از مبدأ) تا از انتقال فایل‌های دست‌کاری‌شده جلوگیری شود.

انتقال wp-content

پوشه wp-content شامل سه زیرپوشه اصلی است: plugins، themes و uploads. پوشه uploads معمولاً بزرگ‌ترین بخش است و در سایت‌های چندساله می‌تواند چند گیگابایت حجم داشته باشد. برای انتقال سریع‌تر، فایل‌ها را به‌صورت zip فشرده کنید و در مقصد از حالت zip انتقال دهید.

حذف فایل‌های اضافی

قبل از انتقال، فرصت خوبی است که فایل‌های اضافی را حذف کنید. سه دسته اصلی: اول، فایل‌های بکاپ قدیمی که در هاست انباشته شده‌اند. دوم، افزونه‌ها و قالب‌های غیرفعال. سوم، فایل‌های یتیم در پوشه uploads که در هیچ محتوایی استفاده نمی‌شوند. همین پاکسازی، در مهاجرت‌ها معمولاً بین ۲۰ تا ۴۰ درصد حجم انتقال را کم می‌کند.

جایگزینی URL و اصلاح مسیرها

اگر آدرس سایت مقصد با مبدأ متفاوت باشد، حتماً باید تمام URLها در دیتابیس جایگزین شوند. این مرحله، فنی‌ترین بخش انتقال است و اگر اشتباه انجام شود، سایت با لینک‌های شکسته مواجه می‌شود.

روش جایگزینی درست

روش امن، استفاده از ابزارهایی است که Serialized Data را درست مدیریت می‌کنند. دستور wp search-replace در WP-CLI این کار را به‌شکل حرفه‌ای انجام می‌دهد. روش دستی با کوئری SQL ساده، در ساختار Serialized به مشکل می‌خورد چون طول رشته در داده ثبت شده و جایگزینی طولانی‌تر، ساختار را به هم می‌ریزد.

URL نسبی در برابر مطلق

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

در مهاجرت، جایگزینی URL یک عملیات حساس به Serialization است؛ ابزار دستی و کوئری خام، دو دشمن این مرحله‌اند.

کاربران، نقش‌ها و دسترسی‌ها

در انتقال دیتابیس، جدول کاربران هم منتقل می‌شود. اما رمزهای عبور به‌صورت Hash ذخیره شده‌اند و با انتقال، همان‌ها معتبر باقی می‌مانند. سه نکته کلیدی در این بخش: اول، مطمئن شوید نقش‌های سفارشی هم منتقل شده‌اند. دوم، بررسی کنید که ادمین اصلی به‌عنوان ادمین باقی مانده باشد. سوم، اگر رمز عبور کاربران بر پایه Salt تولید شده است، تغییر Salt در سایت مقصد باعث می‌شود همه کاربران مجبور به بازنشانی رمز شوند.

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

افزونه‌ها، قالب‌ها و تنظیمات وابسته

افزونه‌ها و قالب‌ها، تنها بخشی از وابستگی‌های مهاجرت هستند. وابستگی‌های پنهان، معمولاً مشکل‌سازترند: تنظیمات Customizer، ویجت‌ها، منوها، و API Keyهایی که در فایل‌های پیکربندی نگه‌داری می‌شوند.

Customizer و Widget

تنظیمات Customizer در جدول wp_options نگه‌داری می‌شود و با انتقال دیتابیس منتقل می‌شود. اما اگر قالب سایت مقصد با مبدأ متفاوت باشد، این تنظیمات بی‌معنا می‌شوند. ویجت‌ها هم در جدول wp_options و بخشی در جدول wp_posts نگه‌داری می‌شوند. پس از انتقال، حتماً ترتیب ویجت‌ها و موقعیت آن‌ها را در پیشخوان بررسی کنید.

API Keyها و SMTP

تنظیمات SMTP و API Keyها به‌صورت پیش‌فرض در دیتابیس ذخیره می‌شوند و منتقل خواهند شد. اما اگر درگاه پرداخت یا سرویس ایمیل شما به IP یا دامنه وابسته باشد، پس از انتقال باید مجدداً پیکربندی شود. تنظیم دقیق SMTP و درگاه پرداخت را در پیکربندی ایمیل‌های وردپرس آورده‌ام.

کرون، نشست‌ها و پاک‌سازی جانبی

پس از انتقال، چند بخش جانبی باید بازبینی شود: کرون، نشست‌های فعال و کش.

کرون وردپرس

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

نشست‌های فعال

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

پاک‌سازی کش

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

حفظ سئو در انتقال بین دو وردپرس

بزرگ‌ترین نگرانی صاحب سایت در مهاجرت، افت سئو است. تجربه‌ام این است که اگر چهار مرحله درست انجام شود، افت سئو صفر یا نزدیک به صفر خواهد بود.

یکسان نگه‌داشتن ساختار URL

اگر ساختار URL محصولات و نوشته‌ها یکسان نگه داشته شود، گوگل تفاوتی نمی‌بیند. مسئله زمانی پیش می‌آید که ساختار URL در سایت مقصد متفاوت باشد. در این حالت، حتماً ریدایرکت ۳۰۱ تعریف کنید. ابزارهای مدیریت ریدایرکت در بهترین افزونه‌های ریدایرکت برای وردپرس معرفی شده است.

sitemap و Search Console

پس از مهاجرت، sitemap جدید را در Search Console ثبت کنید. اگر دامنه تغییر کرده، حتماً از طریق Change of Address در Search Console اعلام کنید. اگر دامنه یکی است و فقط هاست تغییر کرده، نیازی به این مرحله نیست اما پایش هفتگی توصیه می‌شود. مفاهیم پایه سئو را در سئو چیست و چگونه به رشد سایت کمک می‌کند آورده‌ام و مکانیزم دقیق انتقال اعتبار بین دو سایت در وب به‌عنوان HTTP 301 مستند شده است.

پیوندهای ورودی

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

تست پس از انتقال و انتشار

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

تست ساختاری

سه چیز را در سایت مقصد تست کنید: اول، صفحه اصلی و صفحه محصول/نوشته. دوم، فرم تماس و سبد خرید. سوم، ورود به پیشخوان با کاربر ادمین. اگر همه این‌ها درست کار کرد، ۸۰ درصد مهاجرت موفق بوده است.

تست عملکرد

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

تست سئو

پس از مهاجرت، از Search Console سؤال بپرسید: آیا سایت به‌درستی کراول می‌شود؟ خطاهای Indexing چقدر است؟ اگر خطای جدیدی ظاهر شد، بلافاصله اصلاح کنید. پایش هفتگی برای دو ماه اول ضروری است.

خطاهای پرهزینه در انتقال

در بازبینی مهاجرت‌هایی که به مشکل خورده‌اند، پنج خطا بیشترین تکرار را داشته‌اند.

یک نکته اضافی از تجربه: در پروژه‌هایی که چند نصب وردپرس روی یک هاست وجود دارد، مهاجرت معمولاً با تداخل مجوز فایل مواجه می‌شود. فایل‌ها ممکن است با مالکیت کاربر اشتباه منتقل شوند و افزونه‌ها به آن‌ها دسترسی نداشته باشند. پیش از مهاجرت، این موضوع را با هاست‌تان هماهنگ کنید.

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

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

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

توصیه نمی‌کنم. انتقال روی سایت زنده، در ساعات پرباری می‌تواند منجر به قطع سرویس و از دست رفتن سفارش‌ها شود. مسیر درست: ابتدا سایت مبدأ را در حالت Maintenance قرار دهید، سپس انتقال را انجام دهید. اگر سایت خیلی فعال است، از حالت Read-Only استفاده کنید تا کاربران همچنان بتوانند محتوا را ببینند اما امکان تغییر نداشته باشند.

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

برای سایت‌های کوچک (زیر ۱ گیگابایت)، بین دو تا چهار ساعت. برای سایت‌های متوسط (۱ تا ۵ گیگابایت)، یک روز کاری. برای سایت‌های بزرگ (بیش از ۵ گیگابایت)، دو تا سه روز. در همه این اوقات، مهم‌ترین بخش، صبر در تست و بازبینی است، نه سرعت در اجرا.

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

برای سایت‌های کوچک و متوسط، بله. افزونه‌های مهاجرت مثل All-in-One WP Migration یا Duplicator، خطاهای انسانی را به حداقل می‌رسانند. اما در سایت‌های بزرگ یا شرایط خاص (پیشوند جدول غیرمعمول، دیتابیس پیچیده)، روش دستی یا WP-CLI انتخاب بهتری است.

آیا URLها به‌صورت خودکار جایگزین می‌شوند؟

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

آیا کاربران باید رمز خود را دوباره تنظیم کنند؟

اگر Salt دیتابیس (کلیدهای امنیتی وردپرس) تغییر کند، بله. اگر Salt یکسان منتقل شود، کاربران می‌توانند با رمز قبلی وارد شوند. تصمیم بین امنیت و راحتی: اگر مهاجرت از سایت لوکال به سایت زنده است، تغییر Salt توصیه می‌شود. اگر انتقال بین دو هاست با همان داده‌هاست، نگه‌داشتن Salt منطقی‌تر است.

آیا پس از مهاجرت باید افزونه‌های امنیتی را دوباره تنظیم کنم؟

اگر تنظیمات در دیتابیس ذخیره شده باشند، به‌صورت خودکار منتقل می‌شوند. اما تنظیمات وابسته به IP مثل Allowlist، پس از مهاجرت باید بازبینی شود. اگر IP سایت مقصد متفاوت است، حتماً این تنظیمات را بررسی کنید. اگر با افزونه‌های امنیتی آشنا نیستید، بهترین افزونه‌های امنیتی وردپرس راهنمای کاملی است.

اگر مهاجرت نیمه‌کاره ماند، چه باید کرد؟

سایت مقصد را در حالت Maintenance قرار دهید و از بکاپ مبدأ، سایت را در مقصد بازسازی کنید. هرگز تلاش نکنید نیمه‌کاره را تکمیل کنید؛ چون ریسک ترکیب داده ناسازگار بالاست. مسیر بازگشت در بازیابی سایت از بکاپ آمده است.

آیا انتقال، بر روی سئو اثر منفی دارد؟

اگر چهار مرحله رعایت شود، نه: یکسان نگه‌داشتن ساختار URL، ریدایرکت ۳۰۱ در صورت تغییر دامنه، اعلام Change of Address در Search Console، و پایش هفتگی. تجربه‌ام: مهاجرت‌های بدون افت سئو، همان‌هایی هستند که این چهار مرحله را با دقت اجرا کرده‌اند.

انتقال امن، شروع تازه‌ای مطمئن

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

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

اگر در انتقال سایت خود با موقعیت خاصی مواجه شده‌اید - مثلاً دیتابیس بسیار بزرگ، افزونه‌های ناسازگار یا محدودیت‌های هاست مقصد - تجربه‌تان را بنویسید. همین گزارش‌های واقعی، از هر مستند رسمی برای پروژه‌های فارسی مفیدتر است. 🔄