از WordPress به هدلس؛ چه چیزی را واقعاً جدا می‌کنی

WordPress هنوز برای خیلی سایت‌ها ابزار درست است. این را به‌عنوان کسی می‌گویم که با React و Next.js کار می‌کند، نه علیه یک جامعه. مهاجرت به هدلس وقتی معنی دارد که شکل ارائه واقعاً با مدل «قالب PHP و افزونه» نمی‌خواند، یا هزینه نگهداری افزونه‌ها از هزینه مالکیت یک فرانت جدا بیشتر شده.

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

چه چیزی آدم را از مونولیت خسته می‌کند

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

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

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

هدلس دقیقاً چه مرزی است

CMS سربه‌سر یعنی محتوا و ارائه در یک فرآیند زندگی می‌کنند. هدلس یعنی محتوا از API یا خروجی ساخت می‌آید و ارائه جای دیگری رندر می‌شود. «سر» همان لایه نمایش است که جدا شده.

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

آزادی، کار تازه هم می‌آورد. پیش‌نمایش پیش‌نویس، نقش ویراستار، رسانه، فرم، ریدایرکت، و جستجو دیگر «همراه خود WordPress» نیستند. هر کدام را یا از CMS جدید می‌گیری یا خودت می‌سازی. تیم‌هایی که این فهرست را نمی‌نویسند، وسط مهاجرت غافلگیر می‌شوند.

انتخاب CMS را با جریان تحریریه بگیر، نه با لوگوی API

Contentful، Sanity، Strapi، Ghost، و Payload هر کدام مصالحه متفاوتی دارند. یکی میزبانی‌شده و خوش‌دست، یکی متن‌باز و روی زیرساخت خودت. قیمت برخی با حجم محتوا یا صندلی بالا می‌رود. برخی مدل داده انعطاف‌پذیرتری دارند و در عوض تیم باید نظم schema را خودش نگه دارد.

سؤال درست: ویراستار غیربرنامه‌نویس فردا چطور پیش‌نویس را می‌بیند و منتشر می‌کند؟ اگر جوابت «JSON را در گیت ادیت می‌کند» باشد، CMS نخریده‌ای؛ درد را به آدم منتقل کرده‌ای. اگر جوابت «همان حس WordPress بدون هیچ آموزش» باشد، احتمالاً هزینه واقعیت را دست‌کم گرفته‌ای.

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

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

مهاجرت را مثل برش ترافیک انجام بده، نه مثل پرش

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

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

HTML بدنه را کورکورانه به کامپوننت ری‌اکت تبدیل نکن. shortcode و صفحه‌ساز پر از حالت خاص‌اند. یا رندر HTML تمیز باSanitize جدی، یا تبدیل صریح بلوک‌ها. حالت وسط، یعنی dangerouslySetInnerHTML روی محتوای قدیمی بدون سیاست، هم XSS است هم بدهی.

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

چه چیزی را از دست می‌دهی

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

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

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

پرسش‌های کوتاه

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

همه چیز باید ایستا باشد؟ نه. محتوای عمومی پایدار را ایستا یا کش‌شده نگه دار. هر چه به کاربر واردشده وابسته است باید مسیر دینامیک خودش را داشته باشد.

کی مهاجرت نکنم؟ وقتی درد اصلی محتوا و فرآیند است نه فناوری، یا وقتی کسی در تیم مالک فرانت جدید بعد از تحویل نیست.