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

چه زمانی مهاجرت از وردپرس توجیه فنی دارد؟

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

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

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

چرا کسب‌وکارها از وردپرس خارج می‌شوند؟

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

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

سوم، الزامات حاکمیتی و انطباق: برخی سازمان‌ها به‌دلیل ماهیت داده‌هایشان نمی‌توانند روی زیرساخت مشترک یا با افزونه‌های ثالث کار کنند. اینجا مهاجرت به یک CMS اختصاصی یا یک پلتفرم SaaS که قرارداد سطح سرویس (Service Level Agreement یا SLA) مشخص دارد، الزام می‌شود، نه انتخاب. در این دسته، تصمیم فنی از قبل گرفته شده و آنچه می‌ماند، طراحی صحیح پروژه‌ی مهاجرت است.

چارچوب تصمیم‌گیری: بمانیم یا کوچ کنیم؟

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

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

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

گزینه‌های جایگزین وردپرس و مقایسه فنی

بعد از تصمیم به کوچ، اولین سؤال این است: به کدام سیستم؟ پاسخ صادقانه این است که گزینه‌ها را باید با توجه به نیازهای خاص پروژه انتخاب کرد، نه با توجه به محبوبیت عمومی. چهار مسیر اصلی روی میز است.

سیستم‌های مدیریت محتوای اختصاصی (Custom CMS)

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

پلتفرم‌های SaaS مدیریت محتوا

سرویس‌هایی مانند Contentful، Sanity یا Strapi Cloud، مدل داده‌ی محتوا را از لایه‌ی ارائه جدا می‌کنند و از طریق API محتوا تحویل می‌دهند. برای پروژه‌هایی که می‌خواهند روی چند بستر (وب، اپ موبایل، سرویس‌های صوتی) محتوا پخش کنند، این معماری بسیار مناسب است. محدودیت اصلی، هزینه‌ی اشتراکی است که با رشد محتوا بالاتر می‌رود.

ژنراتورهای سایت استاتیک (Static Site Generator)

ژنراتورهایی مانند Next.js، Astro یا Hugo، محتوا را در زمان بیلد به فایل‌های HTML استاتیک تبدیل می‌کنند و در نتیجه سرعت و امنیت بسیار بالایی می‌دهند. برای سایت‌های محتوایی، وبلاگ‌ها و مستندات فنی، این معماری امروز پرکاربردترین است. برای فروشگاه‌های پویا و سایت‌های عضویت‌محور، نیاز به لایه‌ی API جداگانه‌ای دارند که معماری را پیچیده‌تر می‌کند.

پلتفرم‌های تجارت الکترونیک تخصصی

سرویس‌هایی مثل Shopify یا BigCommerce، برای فروشگاه‌هایی که منطق کسب‌وکارشان پیچیده نیست و می‌خواهند از دردسر نگهداری زیرساخت فرار کنند، انتخاب منطقی‌اند. خودم در پروژه‌های زیادی از سمت مقابل این جریان (مهاجرت از Shopify به ووکامرس) کار کرده‌ام که تجربه‌اش در مهاجرت از Shopify به ووکامرس آمده؛ این مقاله عمدتاً همان منطق را در جهت معکوس اجرا می‌کند.

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

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

فهرست‌برداری از داده‌ها: آنچه باید منتقل شود

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

یک، جداول اصلی: wp_posts، wp_postmeta، wp_terms، wp_term_taxonomy، wp_term_relationships، wp_users، wp_usermeta. این هفت جدول، اسکلت محتوا و کاربران شما را می‌سازند و مهاجرت به هر سیستمی که باشد، از این‌ها شروع می‌شود. جزئیات فنی انتقال این جداول را در مهاجرت دیتابیس وردپرس به سرور جدید توضیح داده‌ام و همان منطق، با تغییر مقصد، اینجا هم کاربرد دارد.

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

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

شش، داده‌های مرتبط با فروشگاه: اگر ووکامرس یا هر پلاگین تجارت الکترونیکی روی سایت دارید، جداول جداگانه‌ای برای محصولات، سفارش‌ها، مشتریان و کوپن‌ها وجود دارد که انتقال‌شان بسیار حساس‌تر از محتوای عمومی است. هفت، داده‌های تحلیلی و ردیابی: تنظیمات Google Analytics، Google Search Console، رکوردهای تأیید دامنه و ابزارهای ردیابی سرور، که در جریان مهاجرت معمولاً از قلم می‌افتند و بازسازی‌شان هزینه دارد.

چهار استراتژی انتقال محتوا

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

استراتژی اول: خروجی XML استاندارد وردپرس

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

استراتژی دوم: واکشی مستقیم از دیتابیس

اگر سیستم مقصد استاندارد وردپرس را نمی‌پذیرد، واکشی مستقیم از جداول با کوئری‌های SQL و تبدیل داده‌ها به فرمت مقصد، رایج‌ترین مسیر است. در این روش، باید ساختار روابط (post_parent، menu_order، term_relationships) را دقیق درک کنید تا سلسله‌مراتب دسته‌بندی و برگه‌ها در سیستم جدید حفظ شود.

استراتژی سوم: استفاده از REST API

وردپرس از نسخه ۴.۷ یک REST API داخلی دارد که تمام منابع اصلی (نوشته‌ها، برگه‌ها، رسانه، کاربران) را از طریق HTTP در اختیار قرار می‌دهد. مسیر کاربردی این API را در راهنمای REST API وردپرس باز کرده‌ام. این استراتژی برای سایت‌های بزرگ و زمانی که می‌خواهید انتقال را تدریجی و بدون قطعی انجام دهید، بسیار مناسب است.

استراتژی چهارم: بازسازی دستی محتوا

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

حفظ ساختار URL و مدیریت ریدایرکت‌ها

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

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

در سطح فنی، ریدایرکت ۳۰۱ باید در لایه‌ی وب‌سرور (Apache با .htaccess، Nginx با کانفیگ سرور) پیاده‌سازی شود، نه در لایه‌ی اپلیکیشن. یک زنجیره‌ی ریدایرکت بلندتر از سه گام، هم سرعت را کاهش می‌دهد و هم اعتبار را می‌سوزاند. قاعده‌ی من در پروژه‌ها این است که حداکثر یک ریدایرکت مستقیم بین نسخه‌ی قدیم و جدید URL قرار بگیرد، بدون گام میانی.

استراتژی حفظ سئو در جریان مهاجرت

سئو در مهاجرت، یک لایه‌ی مستقل است که باید با دقت کنترل شود. در تجربه‌ی من، سئو در سه دسته‌ی آسیب رخ می‌دهد: از دست رفتن ساختار لینک داخلی، از دست رفتن داده‌ی ساختاریافته، و از دست رفتن اعتبار دامنه در نتایج SERP (Search Engine Results Page). سرنام SERP همان صفحه‌ی نتایج موتور جستجو است که رتبه و ریدایرکت‌ها در آن با هم ارزیابی می‌شوند.

برای لینک داخلی، باید یک شبکه‌ی نگاشت بین صفحات قدیم و جدید بسازید و اطمینان حاصل کنید که روابط درونی (نوشته به دسته، برگه به والد، محصول به دسته‌بندی) در سیستم جدید بازتولید شده‌اند. برای داده‌ی ساختاریافته، سه نوع schema را در اولویت نگه دارید: Article برای محتوای تحریریه، Product برای فروشگاه، و Organization برای سایت. برای اعتبار دامنه، در هفته‌های اول پس از مهاجرت، دو ابزار را پایش کنید: Search Console برای روند کلیک و ایندکس، و Bing Webmaster Tools برای تنوع داده.

در پروژه‌های مهاجرت، ساختار داده‌ی ساختاریافته را روز اول بسازید، نه روز دهم. اگر schema را از دست بدهید، بازگرداندنش به نتایج غنی، چندین ماه طول می‌کشد.

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

رسانه، کاربران و احراز هویت

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

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

آزمون‌های پیش از انتشار

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

آزمون‌های حداقلی که در پروتکل خودم گنجانده‌ام: صفحه‌ی اصلی، یک صفحه‌ی محتوایی با پیوست رسانه‌ای، یک محصول فروشگاهی با تمام مسیر خرید، فرم تماس با ارسال واقعی، جستجوی داخلی، صفحه‌ی ۴۰۴، فید RSS، و نقشه‌ی سایت XML. پس از این‌ها، سه آزمون فنی جدا: PageSpeed روی سه صفحه‌ی نمونه، تست موبایل واقعی، و بررسی هدرهای HTTP برای canonical و hreflang. یک نکته‌ی مهم در مورد آزمون‌ها، اجرای همان پروتکل چندباره روی سناریوی مهاجرت خودِ وردپرس است که در مهاجرت از وردپرس به وردپرس دیگر به‌عنوان مبنای مقایسه‌ی نتایج آمده؛ همان چک‌لیست، با افزایش لایه‌های تحول، در مهاجرت به سیستم دیگر هم معتبر است.

خطاهای پرهزینه‌ای که دیده‌ام

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

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

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

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

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

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

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

آیا رتبه‌های سئو در جریان مهاجرت حفظ می‌شوند؟

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

در جریان مهاجرت، سایت باید مدتی آفلاین باشد؟

در معماری درست، خیر. با استفاده از محیط staging و استراتژی مهاجرت تدریجی (مثلاً واکشی داده در ساعات کم‌ترافیک و سوئیچ نهایی در چند دقیقه)، می‌توان زمان قطعی را به حداقل رساند. اگر قطعی طولانی لازم شد، روی دامنه‌ی قدیم یک صفحه‌ی موقت نگه دارید و در آن اطلاع‌رسانی کنید تا گوگل و کاربران بدانند که این وضعیت گذراست.

آیا باید همه‌ی محتوا را منتقل کنیم یا می‌توان بخشی را حذف کرد؟

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

برای انتقال لینک‌های داخلی و خارجی چه کار کنیم؟

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

خط پایان: چه چیزهایی را نباید فراموش کنید

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

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

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