When a WooCommerce shipping amount stays unchanged after editing the method, do not start by purging every cache. Hold the basket and address constant, verify the exact method instance, and compare the result with shipping debug mode on staging. WooCommerce documents that this mode bypasses the shipping rate cache.
The official troubleshooting guide also explains a useful limitation: the matched-zone notice is available on the classic Cart page, not reliably on Cart or Checkout blocks. An absent notice on a block checkout does not prove the setting failed.
Create one repeatable basket
Record product and variation IDs, quantities, shipping classes, destination country, state, and postcode. Use staff-controlled test details. Record the method label and instance you edited, the intended amount, and whether taxes or discounts change the displayed total.
If the wrong zone is matched, resolve that first with the missing shipping options guide. A cache experiment cannot validate the wrong method. Multiple methods can share the same customer-facing label, so compare configuration identities rather than labels alone.
Run an A/B/A check
Use an isolated staging store with outbound customer notifications and real payments safely disabled through its normal test setup. Record the current debug setting before changing it.
- With debug off, load the fixed basket and address. Record the method and amount.
- Under WooCommerce shipping settings, enable shipping debug mode and save. Reload and record the same evidence.
- Disable debug again. Repeat in a fresh session and in the original session.
Keep all other settings unchanged during this comparison. If the amount changes only while cache bypass is active, you have evidence to investigate invalidation or session reuse. You have not proved that a CDN is responsible.
Basket: Products and address unchanged. Method: Exact instance confirmed. Response: Server amount compared with UI. Finish: Debug OFF and order verified. Explanatory checklist, not a customer test result.
Read the outcome before choosing a repair
| Result |
What it narrows down |
| Wrong amount with debug both on and off |
Settings, method selection, custom logic, or carrier response |
| Correct only with debug on |
Rate-cache or session invalidation investigation |
| Server returns correct amount, screen stays old |
Frontend update or cached response path |
| New session works, returning session fails |
Reused cart/session state merits inspection |
A live-rate extension may maintain its own cache or receive an unexpected amount from a carrier. Core debug mode is not a universal bypass for every extension. Ask the extension owner which layer cached the response and what supported invalidation operation it provides.
Verify without destroying active carts
Avoid clearing every customer's sessions to repair one stale quote. Preserve a redacted failing request and use the smallest supported repair. Afterward, test a quantity change, address change, shipping-class change, and a return to the original basket.
Finish with debug mode off. Its frontend notices are not intended as a permanent customer experience. Verify the chosen method and final shipping line on a test order, not only the cart preview. HandL WP can trace rate calculation and cache ownership using the controlled comparison rather than a broad purge that hides the evidence.
References reviewed October 9, 2026. Examples are explanatory, not customer test results.