خطای 404 در صفحه تسویه‌حساب یعنی درخواست به صفحه یا endpoint معتبر ووکامرس نرسیده است؛ این خطا با رد شدن پرداخت توسط درگاه فرق دارد. ممکن است خود صفحه Checkout حذف یا از تنظیمات ووکامرس جدا شده باشد، rewrite وردپرس درست کار نکند، نسخه ترجمه‌شده صفحه مسیر دیگری داشته باشد یا CDN همان پاسخ 404 قدیمی را نگه داشته باشد.
پاسخ سریع: ابتدا URL را از دکمه «ادامه جهت تسویه‌حساب» باز کنید و status و redirect chain را ثبت کنید. سپس در تنظیمات پیشرفته ووکامرس مطمئن شوید یک صفحه منتشرشده به Checkout اختصاص یافته است. اگر صفحه وجود دارد، slug، زبان و permalink را روی staging بررسی کنید؛ در Nginx نیز .htaccess هیچ اثری ندارد.
ابتدا نوع 404 را مشخص کنید
- خود آدرس Checkout از ابتدا 404 است.
- صفحه باز می‌شود، اما endpointی مانند پرداخت سفارش 404 می‌شود.
- فقط پس از ورود، تغییر زبان یا بازگشت از درگاه 404 رخ می‌دهد.
- فقط لینک منو خراب است و URL واقعی Checkout کار می‌کند.
- origin پاسخ درست می‌دهد ولی CDN پاسخ 404 نشان می‌دهد.
URL نهایی، status هر redirect، زمان رخداد و وضعیت ورود کاربر را ثبت کنید. اگر صفحه Checkout باز است اما دکمه ثبت سفارش روی spinner می‌ماند، راهنمای گیرکردن Checkout ووکامرس مسیر دقیق‌تری است.
انتساب صفحه Checkout در ووکامرس
در بخش تنظیمات پیشرفته ووکامرس، صفحه تسویه‌حساب باید به یک برگه معتبر متصل باشد. برگه را از نظر انتشار عمومی، قرار نگرفتن در Trash، زبان و دسترسی بررسی کنید. ساخت یک برگه هم‌نام کافی نیست؛ ووکامرس باید همان رکورد را به‌عنوان Checkout بشناسد. اگر چند برگه قدیمی دارید، قبل از حذف آن‌ها لینک منو، ترجمه‌ها و endpointهای سفارش را بررسی کنید.
Block یا Shortcode؛ نسخه موجود را بشناسید
صفحه Checkout بسته به نسخه و پیکربندی فروشگاه می‌تواند از Checkout Block یا ساختار کلاسیک استفاده کند. تعویض شتاب‌زده Block و shortcode ممکن است سازگاری درگاه، افزونه حمل‌ونقل یا سفارشی‌سازی قالب را تغییر دهد. ابتدا از محتوا و تنظیمات backup بگیرید و تغییر را در staging با پرداخت آزمایشی، کوپن، ارسال و حساب مهمان تست کنید.
Slug، Trash و تعارض مسیر
برگه‌ای در Trash، محصول یا route افزونه ممکن است slug موردنظر را اشغال کرده باشد. slug فعلی صفحه و URL تولیدشده توسط خود ووکامرس را مقایسه کنید. لینک قدیمی منو را دستی به یک حدس تازه تغییر ندهید؛ ابتدا canonical URL را مشخص و در صورت تغییر دائمی، فقط مسیر قدیمی را به مسیر معتبر redirect کنید.
خود صفحه 404 است یا Endpoint داخل آن؟
ووکامرس برای بعضی مراحل خرید از endpointهایی زیر یک صفحه پایه استفاده می‌کند. بنابراین سالم بودن صفحه اصلی Checkout ثابت نمی‌کند مسیر پرداخت سفارش یا دریافت سفارش نیز سالم است. path کامل خطادار را با URL پایه مقایسه کنید و ببینید بخش انتهایی توسط ووکامرس تولید شده یا لینک ثابت قالب است. حذف endpoint از تنظیمات یا ترجمه مستقیم آن می‌تواند لینک تولیدشده و route فعال را از هم جدا کند.
با DevTools گزینه Preserve log را روشن کنید و از Cart تا خطا پیش بروید. اگر document اولیه 200 ولی request بعدی 404 است، تمرکز باید روی همان endpoint و redirect قبل از آن باشد. اگر اولین document 404 است، mapping برگه و rewrite اولویت بالاتری دارند. query string و cookie را پیش از اشتراک‌گذاری پاک یا ناشناس کنید.
Permalink چه زمانی کمک می‌کند؟
ذخیره دوباره تنظیمات پیوند یکتا می‌تواند ruleهای وردپرس را بازسازی کند، اما درمان همه 404ها نیست. این کار صفحه حذف‌شده، mapping اشتباه یا config ناقص Nginx را اصلاح نمی‌کند. پیش از تغییر، از قواعد سفارشی وب‌سرور نسخه نگه دارید و بعد از آن صفحه محصول، سبد، Checkout، حساب کاربری و endpointهای سفارش را smoke test کنید.
تفاوت Apache و Nginx
| لایه | محل بررسی | خطای رایج |
|---|---|---|
| Apache | VirtualHost و در صورت فعال بودن .htaccess | rewrite module یا AllowOverride نامناسب |
| Nginx | بلوک‌های server و location | ارسال نشدن مسیر به front controller |
| Reverse proxy/CDN | route، cache و redirect در لبه | cache شدن 404 یا تغییر hostname |
پیکربندی آماده اینترنت را جایگزین config فعال نکنید. ابتدا syntax را با ابزار همان وب‌سرور بررسی و برای reload برنامه بازگشت داشته باشید. یک rule فراگیر می‌تواند فایل‌های استاتیک یا endpointهای امنیتی را نیز مختل کند.
سایت چندزبانه و Checkout فارسی
اگر Checkout انگلیسی سالم ولی نسخه فارسی 404 است، ارتباط ترجمه برگه، slug زبان، منوی همان زبان و تنظیم URL زبان را بررسی کنید. کپی مستقل صفحه بدون رابطه ترجمه ممکن است ووکامرس را به رکوردی وصل کند که در زبان فعال قابل دسترس نیست. redirect خودکار زبان نیز نباید مسیر Checkout یا endpoint پرداخت را قطع کند.
Cache و CDN را با شاهد بررسی کنید
404 می‌تواند در browser cache، افزونه، reverse proxy یا CDN باقی بماند. headerهای پاسخ و تفاوت درخواست مستقیم origin را بررسی کنید و فقط URL آسیب‌دیده را purge کنید. خود Checkout نباید به‌صورت عمومی page cache شود، زیرا session، nonce، روش ارسال و جمع سفارش برای هر کاربر متفاوت است.
بعد از مهاجرت یا تغییر دامنه
base URL قدیمی، search/replace ناقص، config متفاوت مقصد و cache مبدا از علت‌های رایج‌اند. داده serialized وردپرس را با جایگزینی ساده متنی خراب نکنید. DNS و hostname نهایی را نیز کنترل کنید؛ رفت‌وبرگشت کاربر میان دو سرور می‌تواند هم 404 و هم از دست رفتن session ایجاد کند.
تداخل افزونه و قالب را بدون توقف فروش پیدا کنید
افزونه چندزبانه، عضویت، امنیت، redirect و سفارشی‌سازی Checkout همگی می‌توانند پیش از router مسیر را تغییر دهند. آزمون تداخل را روی staging هم‌نسخه انجام دهید: ابتدا قالب سازگار و افزونه‌های ضروری ووکامرس/درگاه را نگه دارید و سپس گروه‌های کوچک را برگردانید. روی production درگاه یا افزونه موجودی را وسط خرید کاربران خاموش نکنید. اگر خطا به یک release وابسته است، diff تنظیمات و فایل‌های override از غیرفعال‌سازی تصادفی مفیدتر است.
URLهای سخت‌کدشده در قالب و پیام‌ها
دکمه header، mini-cart، ایمیل یا صفحه سفارشی ممکن است هنوز به slug قدیمی اشاره کند. لینک خروجی را در HTML بررسی و منبع تولید آن را پیدا کنید؛ redirect دائمی می‌تواند سازگاری کوتاه‌مدت بدهد، ولی منبع لینک نیز باید اصلاح شود. جست‌وجوی کور و جایگزینی کل دیتابیس، به‌خصوص روی داده serialized، راه امنی برای اصلاح این لینک‌ها نیست.
لاگ‌ها چگونه مسیر خطا را روشن می‌کنند؟
در access log، host، path، status، upstream status و زمان درخواست را با DevTools تطبیق دهید. نبودن درخواست در origin معمولاً مسئله را به DNS، CDN یا proxy نزدیک می‌کند. اگر وردپرس request را دریافت کرده، route و pluginها مهم‌ترند. کوکی، token، IP کامل مشتری و اطلاعات سفارش را در گزارش عمومی منتشر نکنید.
فرایند اصلاح کم‌ریسک
- backup و یک سفارش آزمایشی کنترل‌شده آماده کنید.
- URL واقعی تولیدشده توسط ووکامرس و redirectها را ثبت کنید.
- برگه منتشرشده و mapping Checkout را تأیید کنید.
- slug، Trash، ترجمه و تعارض route را بررسی کنید.
- روی staging permalink و config وب‌سرور را آزمایش کنید.
- cache همان مسیر را هدفمند پاک کنید.
- سبد تا بازگشت از پرداخت را end-to-end تست کنید.
اشتباه‌های رایج
- ساخت چند صفحه Checkout بدون اصلاح mapping
- redirect کردن همه 404ها به صفحه اصلی
- حذف
.htaccessیا جایگزینی config بدون backup - استفاده از راهکار Apache برای Nginx
- page cache کردن Checkout
- نادیده گرفتن زبان و hostname
- آزمون مستقیم با پرداخت واقعی و چند کلیک پیاپی
آزمون نهایی
با کاربر مهمان و واردشده، محصول ساده و متغیر را به سبد اضافه کنید؛ Cart، Checkout، تغییر آدرس، انتخاب ارسال و ورود به درگاه را بررسی کنید. در تست کنترل‌شده، callback و صفحه دریافت سفارش نیز باید بدون 404 باز شوند. اگر خود Cart هم خطا دارد، ابتدا خطای 404 سبد خرید را رفع کنید.
چه زمانی کمک تخصصی لازم است؟
اگر 404 فقط در یک زبان، پشت CDN یا در endpoint بازگشت پرداخت رخ می‌دهد، تغییر حدسی rewrite می‌تواند فروش را متوقف کند. پشتیبانی فروشگاه ووکامرس می‌تواند mapping، route، proxy و callback را با log و مسیر بازگشت مشخص بررسی کند.
پرسش‌های متداول
آیا ساخت دوباره صفحه Checkout سفارش‌ها را حذف می‌کند؟
خود برگه سفارش‌ها را حذف نمی‌کند، اما تغییر mapping و محتوا باید با افزونه‌های درگاه و Checkout آزموده شود.
چرا فقط لینک منوی تسویه‌حساب 404 است؟
احتمالاً منو هنوز URL یا برگه قدیمی را نگه داشته است؛ URL تولیدشده از سبد را معیار قرار دهید.
چرا پس از رفع مشکل هنوز بعضی کاربران 404 می‌بینند؟
لایه cache، DNS، service worker یا لینک ذخیره‌شده قدیمی را بررسی کنید؛ ابتدا مشخص کنید پاسخ از کدام لایه آمده است.