مهاجرت یک وب‌سایت محتوایی و فروشگاهی از WordPress به Next.js؛ تصمیم‌ها، ریسک‌ها و چک‌لیست اجرا

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

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

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

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

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

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

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

موجودی را بر اساس نوع داده بسازید، نه بر اساس صفحهٔ خانه

قبل از انتخاب لایهٔ داده یا طراحی جزء رابط، موجودی بگیرید. موجودی مهاجرت چهار لایه دارد و هر لایه منبع حقیقت جدا دارد.

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

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

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

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

خروجی این مرحله یک جدول تصمیم است نه یک اسلاید: برای هر نوع داده، منبع استخراج، تبدیل، مقصد، و رفتار خطا. اگر ردیفی «بعداً» دارد، آن ردیف در دورهٔ اول نیست. کد کوتاه ویرایشگر را هم موجودی کنید؛ گالری و جدول قیمت در HTML خام به جزء رابط تبدیل نمی‌شوند مگر نگاشت داشته باشید.

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

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

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

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

جزئیات سئوی جابه‌جایی دامنه و ایندکس را اینجا تکرار نمی‌کنیم. قرارداد ریدایرکت، نشانی مرجع و نقشهٔ سایت را از چک‌لیست مهاجرت سایت بدون از دست رفتن ایندکس دنبال کنید و در این پروژه به‌عنوان دروازهٔ پذیرش بگذارید، نه کار هفتهٔ بعد از رونمایی.

یکپارچگی داده یعنی شناسه، رابطه و رسانه با هم می‌رسند

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

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

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

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

ریدایرکت را در لبه پیاده کنید و با مبدأ واقعی بیازمایید

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

در مقصد Next.js جدول بزرگ اسلاگ را داخل جزء صفحه نگذارید. پیکربندی ریدایرکت فریم‌ورک، قواعد شبکهٔ توزیع یا کارساز جلوی برنامه، برای حجم بالا مناسب‌تر است. منطق برنامه را برای موردهایی نگه دارید که مقصد به داده وابسته است؛ مثلاً محصول حذف‌شده به دستهٔ والد.

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

ریدایرکت را بعد از یک ماه برندارید. نشانک، کارزار و پیوند ورودی به مبدأ هنوز می‌رسند. برداشتن زودهنگام یعنی بازگرداندن خطای پیدا نشدن به نشانی‌ای که هنوز در ایندکس است.

فراداده و HTML را در مقصد مثل قرارداد ایندکس بسازید

وردپرس عنوان و توضیحات را از افزونه می‌گیرد. در Next.js این قرارداد باید در کد باشد وگرنه صفحه بدون عنوان اختصاصی یا با عنوان تکراری قالب ایندکس می‌شود. مستندات فراداده و تصویر Open Graph در Next.js دو مسیر رسمی می‌گذارند: شیء ایستا برای مسیرهای ثابت، و تابع تولید فراداده برای صفحه‌ای که عنوان و توضیح از داده می‌آید. برای مقاله و محصول، مسیر دوم طبیعی است؛ داده را یک‌بار بخوانید و هم در صفحه هم در فراداده استفاده کنید تا عنوان بدنه با عنوان زبانه فرق نکند.

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

جزئیات رندر، نقشهٔ سایت و دادهٔ ساختاریافته را در سئوی فنی مسیرها و فراداده در Next.js دنبال کنید. در مهاجرت، دروازه این است که هر قالب صفحهٔ پول‌ساز HTML کامل با عنوان، توضیح، نشانی مرجع و پاسخ موفق داشته باشد؛ نه اینکه بعداً فراداده را پر می‌کنیم.

عملکرد را بعد از صحت اندازه بگیرید، نه به‌جای آن

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

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

کش وردپرس را با فرض‌های Next.js عوض نکنید بدون شناخت لایهٔ کش جدید. محصول با قیمت متغیر و مقالهٔ ایستا سیاست جدا می‌خواهند.

برگشت یعنی دکمه، نه امید

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

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

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

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

مقصد نمونه: فروشگاه و محتوا روی یک پایگاه کد Next.js

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

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

چک‌لیست اجرا از محیط میانی تا سی روز بعد

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

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

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

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

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

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

آیا همهٔ سایت‌های وردپرسی باید به Next.js بروند؟

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

محتوا را با رابط برنامه‌نویسی می‌بریم یا با خروجی پایگاه‌داده؟

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

ریدایرکت را در Next.js بگذاریم یا روی کارساز؟

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

اگر بعد از تعویض سفارش در مقصد ثبت نشود چه؟

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

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