WooCommerce recalculates shipping when country, state or postcode changes. If every method vanishes, the final address may match no zone, the package may be ineligible, a live-rate API may have failed or the checkout update may not have completed.
Do not create a catch-all free shipping method as an emergency shortcut. That can accept orders the store cannot fulfil economically.
Capture the last working and first failing address
Use controlled addresses and record country, state, postcode format, cart contents and customer state. Change one address field at a time and watch when the rates disappear.
Inspect the checkout Network panel for update_order_review or Store API requests. Record status, duration and customer-safe error text.
Never retain real customer addresses in shared debugging material.
Confirm zone matching order
WooCommerce evaluates shipping zones from the most specific towards the fallback location. Check whether the address should match a postcode, state, country or “locations not covered” zone.
Review each relevant zone:
- included countries/regions
- postcode patterns
- enabled method instances
- method cost and conditions
- order relative to broader zones
Test postcode spacing and case. Keep patterns explicit; a broad wildcard may accidentally capture areas intended for another zone.
Also test leading zeros, which spreadsheets and external address tools sometimes remove.
Inspect the shipping package
Rates are calculated for packages, not merely the whole cart. Product shipping classes, virtual status, dimensions, weight and multi-vendor splits affect eligibility.
Compare a simple physical product with the failing cart. If only one product combination fails, inspect its class and package-building custom code.
A cart containing only virtual products normally requires no shipping. That is different from a physical cart with no available rate.
Check method-specific conditions
Free shipping can depend on coupons or minimum spend. Flat-rate instances may be disabled, while collection methods can be limited to zones.
For carrier APIs, match the failure time with the extension log. Authentication, account services, origin postcode, product dimensions or a provider timeout can return no rates.
Do not log carrier credentials or customer addresses. Use provider request IDs and controlled test data.
Trace checkout recalculation
Address fields trigger JavaScript events that request new totals. A custom theme, address autocomplete or field plugin may update the visible input without sending the value WooCommerce reads.
Inspect the posted country, state and postcode using safe test data. Read the first console error. If the server response contains valid rates but the page shows none, the fault is in rendering or JavaScript.
Avoid forcing repeated update_checkout events in a loop; that can overload the server and create flicker.
Rule out cache and stale sessions
Checkout and rate responses must not be shared between customers. Verify page, server and Cloudflare cache exclusions.
If the browser session retains an old package after address changes, compare with a fresh private session. Clear only the controlled session while diagnosing. Deleting all WooCommerce sessions disrupts active carts.
Currency and language changes can also cause checkout to rebuild packages; test the store’s supported combinations.
Repair the exact rate boundary
Correct the zone, postcode rule, product data, method condition, carrier credentials or checkout field event. Provide a customer-safe “shipping unavailable” message when no legitimate method exists.
Do not expose raw carrier errors at checkout. Log technical detail privately with a correlation reference.
Complete orders for the repaired address and a deliberately unsupported address. Confirm rate, tax, total, payment amount and stored shipping method all agree.
Recurring care should test representative destination zones after carrier, product, checkout and WooCommerce updates. A rate that appears once is insufficient; address recalculation must remain deterministic.