۴. قرارداد محصول و سبد خرید را جدا آزمایش کنید
Store API ووکامرس مسیرهای روبهمشتری را ارائه میدهد. برای یک بررسی فقطخواندنی میتوان فهرست محصولات عمومی را درخواست کرد. دامنه زیر نمونه است و باید با دامنه فروشگاه آزمایشی جایگزین شود:
curl --fail --show-error "https://shop.example.com/wp-json/wc/store/v1/products?per_page=1"
پاسخ موفق یعنی این مسیر قابل دسترسی است؛ به معنی آمادهبودن سبد، حساب یا درگاه نیست. در نمایش مبلغ نیز واحد و تعداد رقم اعشار پاسخ API را بررسی کنید. مبلغ نمایشی را بدون توجه به تنظیم ارز، مستقیماً به تومان تبدیل نکنید. قیمت، مالیات و جمع نهایی سفارش باید از منطق معتبر ووکامرس بیاید، نه محاسبه قابل دستکاری مرورگر.
طبق مستندات Cart Token، توکن سبد میتواند سبد مربوط به درخواستهای Headless را شناسایی کند. این توکن را مانند شناسه حساس نشست نگه دارید؛ آن را میان کاربران به اشتراک نگذارید، داخل HTML عمومی قرار ندهید و در کش عمومی یا لاگ ذخیره نکنید. سیاست انتقال و نگهداری نشست باید برای دامنهها و مرورگرهای هدف آزمایش شود.
سبد را در دو نشست مستقل باز کنید و مطمئن شوید محصول کاربر اول برای کاربر دوم دیده نمیشود. تغییر تعداد، حذف محصول، انتخاب تنوع، تمامشدن موجودی و اعمال کد تخفیف را بررسی کنید. مقدار «افزوده شد» در رابط فقط وقتی نمایش داده شود که سرور نتیجه را تأیید کرده است؛ در خطای شبکه، کاربر باید بداند عملیات چه وضعیتی دارد.
۵. پرداخت را یک پروژه یکپارچه‌سازی مستقل بدانید
کارکردن افزونه در قالب فعلی، سازگاری خودکار با فرانتاند مستقل را ثابت نمی‌کند. بعضی درگاهها یا افزونه‌ها به فرمها، اسکریپتها یا مسیرهای بازگشت خاص وابستهاند. بررسی کنید افزونه مسیر موردنیاز معماری جدید را پشتیبانی میکند یا باید بخشی از تسویهحساب در مسیر فعلی باقی بماند. تصمیم را قبل از طراحی نهایی صفحه پرداخت بگیرید.
در محیط آزمایشی، سفارش موفق، پرداخت ناموفق، انصراف، بازگشت دیرهنگام، تکرار کلیک و قطع ارتباط را بسنجید. callback درگاه باید به مقصد درست برسد و تکرار پیام نباید سفارش یا اثر مالی تکراری بسازد. وضعیت پرداخت را از تأیید معتبر سرور بگیرید، نه صرف وجود یک پارامتر موفقیت در URL مرورگر. آزمون پرداخت واقعی فقط با مجوز و مبلغ کنترلشده انجام شود.
پس از سفارش، موجودی، وضعیت سفارش، ایمیل و حساب مشتری را هم کنترل کنید. فروشگاه وقتی آماده است که چرخه بعد از پرداخت نیز درست کار کند. اگر برای یک روش ارسال یا افزونه خاص هنوز پاسخ روشن ندارید، آن قابلیت را آماده اعلام نکنید و دامنه انتشار را محدود نگه دارید.
۶. URL و سئوی صفحات را حفظ کنید
اگر امکان دارد مسیرهای شناختهشده محصول و دسته‌بندی را حفظ کنید. در صورت تغییر URL، برای هر صفحه مهم مقصد متناظر و ریدایرکت دائمی تعریف کنید؛ همه آدرسها را به صفحه اصلی نفرستید. راهنمای مهاجرت URL گوگل بر آماده‌سازی نگاشت و بررسی انتقال تأکید دارد. حتی با اجرای درست نیز نوسان موقت قابل انتظار است؛ حفظ قطعی رتبه را وعده ندهید.
HTML خروجی یک صفحه محصول باید عنوان، توضیحات لازم و محتوای قابل فهم داشته باشد. canonical را به دامنه عمومی درست بدهید و نگذارید نشانی بکاند جای صفحه فروشگاه بنشیند. سایتمپ باید URLهای عمومی معتبر را معرفی کند. صفحه حذف‌شده یا نامعتبر نیز نباید با پاسخ ۲۰۰ و محتوای مبهم شبیه یک محصول سالم نمایش داده شود.
داده ساختاریافته محصول باید با اطلاعات قابل مشاهده صفحه هماهنگ باشد؛ قیمت و موجودی ساختگی یا نسخه‌ای متفاوت از خروجی واقعی منتشر نکنید. اگر افزونه SEO داده را در وردپرس نگه میدارد، مسیر انتقال آن به فرانتاند را پیاده و خروجی رندرشده را بررسی کنید. نصب افزونه در بکاند، به‌تنهایی متادیتای برنامه مستقل را درست نمی‌کند.
۷. کش، پیش‌نمایش و انتشار محتوا را کنترل کنید
پس از ویرایش محصول، زمان رسیدن تغییر به فهرست و صفحه محصول را اندازه بگیرید. ناموجودشدن، تغییر تصویر و تغییر قیمت را جدا امتحان کنید. برای پاسخهای خصوصی سیاست بدون کش عمومی داشته باشید و از راهنمای کش ووکامرس برای شناخت مسیرهای حساس کمک بگیرید. کش سریع ولی اشتباه میتواند از پاسخ کند خطرناکتر باشد.
نویسنده باید پیشنویس را در ظاهر نهایی ببیند، بدون آنکه محتوا عمومی شود. سپس انتشار و لغو انتشار را آزمایش کنید. اگر webhook شکست خورد، باید راهی برای تازهسازی دوباره وجود داشته باشد. یک روال عملی برای این خطا بنویسید تا تیم محتوا برای هر تأخیر مجبور به تماس با توسعهدهنده نباشد.
۸. مسیر پاستا را با مرز واقعی قابلیت‌ها اجرا کنید
از صفحه Headless WordPress پاستا میتوانید نمونه و مسیر شروع را بررسی کنید. در کنسول، سایت فعال و آماده اکو یا توربو انتخاب می‌شود و دسترسی به فهرست محصولات آزموده می‌شود. پس از آن فرم استقرار نمونه آماده می‌شود. این مرحله تنظیم افزونه پرداخت یا مهاجرت سفارشهای فروشگاه قبلی را انجامشده فرض نمی‌کند.
برای رابط مبتنی بر Next.js، هاست Next.js پاستا را متناسب با نوع اجرا انتخاب کنید. دامنه و HTTPS فرانتاند را جدا بررسی کنید و آدرس بکاند را در تنظیمات محیط نگه دارید. Secretها نباید در متغیرهای عمومی مرورگر قرار بگیرند. هزینه وردپرس، پروژه فرانتاند و هر سرویس اضافه را پیش از تأیید بررسی کنید؛ اینها یک هزینه مشترک فرض نمیشوند.
مخزن نمونه متنباز را با نسخه مشخص مبنا بگیرید و تغییرهای خود را در مخزن نگه دارید. پیش از تغییر نسخه، یادداشتهای پروژه و قرارداد اتصال را مرور کنید. نمونه، جای تست سفارش و مستندات مخصوص درگاه فروشگاه شما را نمی‌گیرد.
۹. انتشار را با معیار توقف و بازگشت انجام دهید
قبل از تغییر ترافیک، نسخه قابل بازگشت فرانتاند، بکاپ معتبر و مسئول تصمیم را مشخص کنید. معیار توقف میتواند شکست ثبت سفارش، نمایش قیمت اشتباه یا نشتی نشست باشد؛ منتظر شکایت گسترده مشتری نمانید. برای بازگشت، فقط تغییر DNS را تصور نکنید: باید بدانید نشستها، کش و سفارشهای ایجادشده چه وضعیتی خواهند داشت.
اگر هنگام اجرای نسخه جدید سفارش واقعی ثبت شده باشد، بازگرداندن بیفکر دیتابیس قدیمی میتواند آن سفارش‌ها را حذف کند. در مهاجرتی که بکاند مشترک باقی مانده، ترجیحاً رابط را به نسخه سالم برگردانید و داده سفارش را حفظ کنید. هر بازیابی داده باید با برنامه سازگاری و بررسی سفارشهای جدید انجام شود، نه بهعنوان اولین واکنش به خطای ظاهر.
معیار تحویل نهایی فروشگاه
- صفحه عمومی و HTML آن در موبایل و دسکتاپ درست است.
- نشست دو مشتری مستقل است و کش، داده شخصی را منتشر نمی‌کند.
- محصول متغیر، تخفیف، ارسال و پرداخت آزمون مشخص دارند.
- URLهای مهم، ریدایرکتها، canonical و سایتمپ بررسی شدهاند.
- انتشار محتوا و تغییر موجودی به فرانتاند می‌رسد.
- گزارش خطا و مسیر بازگشت، مالک و دستور روشن دارند.
پس از انتشار، خطاهای خرید، صفحات ۴۰۴، داده سرچ کنسول و تجربه کاربران را جدا دنبال کنید. هدف مهاجرت، رابطی سریعتر و قابل توسعهتر با همان صحت عملیاتی فروشگاه است. اگر فقط ظاهر بهتر شده ولی سفارش قابل اعتماد نیست، کار هنوز تمام نشده است.
