آماده سازی آنلاین شاپ وردپرسی برای بلک فرایدی ۱۴۰۵: چک‌لیست فنی وردپرس با تاریخ‌های روزشمار تا بلک فرایدی
آماده سازی فروشگاه های آنلاین برای بلک فرایدی ۱۴۰۵ پنج کار فنی دارد که تا ۳ آذر باید تمام شود: پرداخت واقعی، سرعت و کش، موجودی، کد تخفیف و پشتیبان. بلک فرایدی امسال جمعه ۶ آذر ۱۴۰۵ (۲۷ نوامبر ۲۰۲۶) است و یلدا دوشنبه ۳۰ آذر (۲۱ دسامبر). از ۴ آبان ۱۴۰۵ تا بلک فرایدی ۳۲ روز مانده است.
تغییر کد و افزونه را سه روز مانده به شروع متوقف کنید، چون هر تغییر تازه همه آزمون‌های قبلی را از اعتبار می‌اندازد. بیشترین ریسک روز فروش درگاهی است که در حالت آزمایشی جواب داده ولی در پرداخت واقعی خطا می‌دهد. اگر تیم فنی وردپرس یا توسعه وردپرس ندارید، پشتیبانی سایت فروشگاهی را توسط ما، متخصصین پشتیبانی فنی وردپرس از وردپرس نیاز، از ماه قبل شروع کنید تا چک‌لیست پیش از فروش بخشی از کار ماهانه باشد، نه کار شب قبل.
| روز | تاریخ | کار |
|---|---|---|
| ۳۰ روز مانده | ۶ آبان (۲۸ اکتبر) | بک‌آپ کامل و بازیابی آزمایشی، ثبت IP سرور در پنل درگاه |
| ۲۱ روز مانده | ۱۵ آبان (۶ نوامبر) | سفارش واقعی با کارت و هر روش ارسال، اندازه‌گیری سرعت پایه |
| ۱۴ روز مانده | ۲۲ آبان (۱۳ نوامبر) | کش، موجودی و کد تخفیف روی نسخه آزمایشی |
| ۷ روز مانده | ۲۹ آبان (۲۰ نوامبر) | ورود تخفیف‌ها با زمان‌بندی و آزمون نهایی |
| ۳ روز مانده | ۳ آذر (۲۴ نوامبر) | توقف هر تغییر در افزونه، قالب و کد |
| آخرین روز کاری ما | پنجشنبه ۵ آذر (۲۶ نوامبر) | بررسی نهایی تا ساعت ۱۳؛ جمعه تعطیل است |
| شروع فروش | جمعه ۶ آذر (۲۷ نوامبر) | پایش سفارش‌ها، بدون تغییر در سایت |
زمان‌بندی روزشمار؛ تاریخ‌ها برای بلک فرایدی ۶ آذر ۱۴۰۵ حساب شده است.
این چک‌لیست برای فروشگاهی است که ووکامرس، یک درگاه ایرانی و یک افزونه کش دارد. اگر سایت شما فقط ویترین است و سفارش آنلاین نمی‌گیرد، فقط بخش سرعت و بک‌آپ به کارتان می‌آید.
مرور ماهانه این چک‌لیست را در برنامه نگهداری ماهانه ببینید؛ فروش مناسبتی بخشی از همان کار ماهانه است.
درگاه پرداخت آنلاین شاپ و مسیر خرید را ۳۰ روز مانده تست کنید
سفارشی که پرداخت نشود فروش نیست، و درگاه تنها بخشی است که فروشگاه روی آن کنترل کامل ندارد. اول این‌ها را بسنجید و بعد سراغ بقیه بروید. برای مقایسه افزونه‌ها، افزونه‌های درگاه پرداخت وردپرس را ببینید و تاریخ آخرین به‌روزرسانی هر افزونه را در مخزن وردپرس بخوانید؛ افزونه‌ای که برای تسویه حساب بلوکی ساخته نشده باشد، با اینکه فعال است در صفحه پرداخت نمی‌آید.
آنچه ما در آزمایش زرین پال دیدیم (۱۱ مهر ۱۴۰۵، وردپرس ۷٫۱٫۲، ووکامرس ۱۱٫۱٫۲، زرین‌پال ۵٫۱٫۱):
• حالت آزمایشی (Sandbox) زرین‌پال سفارش ۱۵۰ هزار تومانی را با مرچنت کد ساختگی و آی پی ثبت‌نشده پذیرفت و سفارش «در حال انجام» شد. پس موفق بودن حالت آزمایشی هیچ چیز درباره IP نمی‌گوید.
• زرین‌پال می‌نویسد از میانه شهریور ۱۴۰۵ ایجاد تراکنش فقط از IPهای ثبت‌شده در پنل پذیرفته می‌شود. تا ۵ نشانی را می‌شود ثبت کرد و با تغییر IP هاست باید دوباره ثبت شود.
• قاعده‌ای در فایروال یا کلودفلر که نشانی بازگشت (wc-api) را ببندد، پرداخت موفق را «در انتظار پرداخت» نگه می‌دارد. در آزمایش ما با ۴۰۳ این اتفاق افتاد و دکمه «اعتبارسنجی مجدد تراکنش» در صفحه سفارش آن را درست کرد.
ترتیب کار در ۳۰ تا ۲۱ روز مانده:
1. IP خروجی همان سروری را که درخواست پرداخت را می‌فرستد از پشتیبانی هاست بگیرید و در پنل درگاه ثبت کنید.
2. دامنه نهایی فروشگاه را قطعی کنید؛ درگاه برای یک دامنه ثبت می‌شود.
3. واحد پول فروشگاه را با واحد قیمت‌ها یکی کنید (تومان یا ریال)، وگرنه مبلغ ده برابر کمتر یا بیشتر به درگاه می‌رسد.
4. حالت آزمایشی را خاموش کنید و مبلغ کوچکی را با کارت خودتان واقعاً بپردازید.
5. بعد از پرداخت، وضعیت سفارش، ایمیل مشتری و ایمیل مدیر را بررسی کنید و سفارش را برگردانید یا لغو کنید.
6. همین مسیر را برای هر روش ارسال و هر روش پرداخت دیگر (مثل پرداخت در محل) تکرار کنید.
شش گام تست پرداخت پیش از فروش.
سرعت و کش ووکامرس را برای صفحه‌هایی بسنجید که خریدار از آن‌ها بازدید میکند
در فروش آنلاین، بیشترین فشار روی صفحه محصول، سبد و تسویه حساب می‌آید؛ همان صفحه‌هایی که کش نمی‌شوند. بنابراین سرعت را روی همین پنج صفحه بسنجید: خانه، یک دسته، یک محصول، سبد و تسویه حساب. نتیجه PageSpeed Insights را ۲۱ روز مانده ذخیره کنید تا بعد از هر تغییر با آن مقایسه شود. اگر عدد بد است، سراغ افزایش سرعت سایت وردپرس بروید و هر بار فقط یک چیز را عوض کنید.
برای کش صفحه، افزونهٔ WP Rocket را قبل از تخفیف فعال کنید و این سه نکته را که از مستندات و آزمایش خودمان آمده بررسی کنید:
• WP Rocket خودش صفحه‌های سبد، تسویه حساب و حساب کاربری را از کش بیرون می‌گذارد. همین مستندات می‌نویسد اگر مدیریت موجودی در سطح محصول روشن باشد، با هر سفارش کش آن محصول پاک می‌شود. در فروش پرتعداد یعنی کش محصول‌های پرفروش مدام خالی می‌شود و پیش‌بارگذاری باید دوباره آن‌ها را بسازد.
• نمره Lighthouse بالاتر همیشه یعنی خرید روان‌تر نیست. بعد از هر تغییر کش، یک خرید کامل با سبد پر انجام دهید.
برای فروشگاه شلوغ، افزونهٔ Redis Object Cache فشار پایگاه‌داده را کم میکند، ولی فقط وقتی هاست Redis را پشتیبانی کند. این را از هاست بپرسید و همان‌جا ظرفیت CPU و تعداد پردازش هم‌زمان را بخواهید؛ ما تست بار روی هاست شما را بدون هماهنگی با خودش توصیه نمی‌کنیم.
موجودی محصول، کد تخفیف و زمان‌بندی قیمت را روی نسخه آزمایشی آنلاین شاپ امتحان کنید
اینجا اشتباه کوچک سریع به ضرر تبدیل می‌شود: تخفیفی که زود تمام می‌شود، کدی که روز اول کار نمی‌کند یا کالایی که فروخته شده ولی هنوز موجود نشان داده می‌شود. زمان‌بندی را با تقویم فروش فصلی ووکامرس هماهنگ کنید و بعد این موارد را یکی‌یکی بزنید:
• نگهداری موجودی (دقیقه): در «ووکامرس > پیکربندی > محصولات» این عدد موجودی سفارش‌های «در انتظار پرداخت» را نگه می‌دارد و بعد از پایان آن سفارش لغو و کالا آزاد می‌شود. خالی بگذارید تا غیرفعال شود. برای کالای کم‌موجود، عدد را کوتاه نگه دارید تا سفارش‌های رهاشده موجودی را قفل نکنند.
• آستانه کم‌موجودی و ناموجودی: هشدار ایمیلی را برای کالاهای پرفروش روی عددی بگذارید که هنوز فرصت تأمین داشته باشید.
• کد تخفیف: سقف استفاده برای کل کد و برای هر کاربر، حداقل خرید، «فقط استفاده فردی» و «حذف کالاهای تخفیف‌دار» را تعیین کنید. تاریخ انقضا را یک روز بعد از آخرین روز کمپین بگذارید، چون به نوشته مستندات ووکامرس کد در همان تاریخ انقضا قابل استفاده نیست.
• قیمت زمان‌بندی‌شده: ساعت و منطقه زمانی سایت را در تنظیمات همگانی وردپرس بررسی کنید و یک تخفیف آزمایشی را برای ۱۰ دقیقه بعد زمان‌بندی کنید تا ببینید واقعاً شروع و تمام می‌شود.
• وظایف زمان‌بندی‌شده: در «ووکامرس > وضعیت > اقدامات زمان‌بندی‌شده» وضعیت‌های شکست‌خورده (failed) را نگاه کنید؛ ایمیل‌ها و کارهای پس‌زمینه از این صف رد می‌شوند.
مسیر ووکامرس > وضعیت > اقدامات زمان‌بندی‌شده؛ وضعیت شکست‌خورده را بررسی کنید.
ایمیل‌ها، بک‌آپ و بازیابی را بسنجید، نه فقط وجودشان را
بک‌آپی که یک بار بازیابی نشده باشد، فقط یک فایل است. ۳۰ روز مانده بک‌آپ کامل بگیرید، آن را روی نسخه آزمایشی بازیابی کنید و مدت بازیابی را یادداشت کنید؛ این عدد در شب فروش تعیین میکند چقدر می‌شود ریسک برگشت را پذیرفت. در پلن فروشگاهی ما بک‌آپ هفتگی است، ولی قبل از توقف تغییرات یک بک‌آپ دستی جدا بگیرید.
ایمیل سفارش را برای مشتری و برای مدیر با یک سفارش واقعی ببینید. اگر ایمیل‌ها به هرزنامه می‌روند یا نمی‌رسند، پیش از فروش سرویس ارسال ایمیل را عوض کنید، نه در روز فروش.
روز فروش بلک فرایدی در آنلاین شاپ: چه کسی در دسترس است و چه چیزی را تغییر نمی‌دهید
بلک فرایدی ۱۴۰۵ جمعه است. ساعت کاری ما در وردپرس نیاز بعنوان متخصص پشتیبانی فنی وردپرس شنبه تا چهارشنبه ۸ تا ۱۸ و پنجشنبه ۸ تا ۱۳ است و جمعه و تعطیلات رسمی بسته‌ایم. در پلن‌های ماهانه، اولین پاسخ کارشناس در ساعت کاری زیر ۲ ساعت است. پس هر چیزی که باید پیش از فروش درست شود، تا پنجشنبه ۵ آذر ساعت ۱۳ درست شود.
برای خودتان هم قاعده بگذارید:
• از ۳ آذر هیچ افزونه، قالب یا کدی به‌روزرسانی نمی‌شود، مگر برای رفع یک خطای فعال.
• یک نفر مسئول پایش سفارش‌هاست و می‌داند در خطا با چه کسی تماس بگیرد.
• اگر خطایی آمد، ابتدا بک‌آپ و فهرست تغییرات اخیر را ببینید، بعد افزونه مشکوک را غیرفعال کنید.
فروش یلدا در آنلاین شاپ و مناسبت‌های بعدی: همان فهرست، با تاریخ تازه
یلدا دوشنبه ۳۰ آذر ۱۴۰۵ (۲۱ دسامبر ۲۰۲۶) است، یعنی ۲۴ روز بعد از بلک فرایدی. اگر بلک فرایدی را با این فهرست پشت سر بگذارید، برای یلدا فقط این‌ها را تکرار کنید: تست یک سفارش واقعی، نگاه به صف اقدامات زمان‌بندی‌شده، کد تخفیف تازه و توقف تغییر ۳ روز قبل. زمان تحویل و تعطیلی پست را هم به مشتری اعلام کنید. همین فهرست برای نوروز ۱۴۰۶ (۱ فروردین برابر ۲۱ مارس ۲۰۲۷) هم قابل استفاده است.
