There Are No Shipping Methods Available? Causes & Fix
This one stops the sale dead — the customer can't check out, and most won't email you about it. Depending on your version WooCommerce phrases it as "There are no shipping methods available" or "No shipping options were found for…", but the cause is the same: the store has no rate to offer this address.
Last updated: 16 Jul 2026 · ~7 min read
The usual cause is that the customer's address matches no shipping zone with an enabled method in it — classically, they fall through to Rest of the World, which is empty. Open WooCommerce → Settings → Shipping, find the zone their address matches, and give it at least one enabled method. Fastest safe fix: put a Flat rate in Rest of the World.
What this message actually means
WooCommerce takes the customer's address, walks your shipping zones from the top down, and stops at the first one that matches. Then it asks that zone — and only that zone — for rates. If the zone has no enabled methods, or if the only zone that matched is the empty Rest of the World fallback, there are no rates to return, and the customer sees this message instead of a shipping option.
From your side the store looks perfectly healthy. Your own address matches a zone you built carefully, so your test orders sail through. From the customer's side, checkout is a wall — they cannot place the order at all. That asymmetry is why this bug can run for weeks: it only breaks for the people who never get to tell you.
The most common causes (most likely first)
- The address falls through to an empty "Rest of the World" zoneIt works for your own country and fails for everywhere you didn't explicitly build a zone for. Rest of the World catches every address your other zones don't, and it starts out with no methods in it. If you sell internationally and never filled it in, this is your cause.
- The matched zone has methods, but none are enabledThe zone looks right at a glance — the method rows are all there — but the enabled toggles are grey. Common after someone disabled a carrier "just to test" and never switched it back.
- The zone's region is narrower than you thinkIt fails for one region or a handful of postcodes inside a country you thought was covered. Check whether the zone uses Limit to specific ZIP/postcodes, and whether it lists states individually rather than the whole country — a customer one state over matches nothing.
- A live-rate carrier API returned zero rates and there's no fallbackIt fails only for particular carts — heavy, oversized, or bound for a lane the carrier doesn't serve — or it started failing the day the API credentials expired. Other carts get rates normally. Live-rate methods return nothing rather than erroring, so with no static method in the zone you get a dead checkout.
- A table-rate or conditional-logic plugin matched no ruleYour rates come from a rules plugin rather than plain WooCommerce methods, and this cart satisfies none of the rules. Temporarily disabling the plugin brings the underlying rates back — that's your confirmation.
- You're seeing a stale, empty rate package in your sessionYou just fixed the zone and it still says no methods — but a private window works. Rates are cached against the customer session. Clear customer sessions and transients under
WooCommerce → Status → Tools.
Where to look first
- Get one failing address. From a support email, an abandoned cart, anything real. Debugging this against your own address will tell you the store is fine, because for your address it is.
- Open
WooCommerce → Settings → Shippingand find which zone that address matches — top down, first match wins. If the answer is Rest of the World, you've found it (cause 1). - Open the matched zone. Does it have at least one method, and is that method's toggle actually on (cause 2)? Does its region genuinely include the customer's state and postcode (cause 3)?
- Rates come from a carrier API or a table-rate plugin? Add a plain Flat rate to the same zone as a fallback and retest — if a rate appears, the carrier or the rules plugin returned nothing (causes 4 and 5).
- Fixed it but still seeing the error? Retest in a private window before touching anything else — you're probably looking at a cached package (cause 6).
How many customers hit this before you noticed?
That's the real cost here — this error only fires for addresses you don't have, so your test orders pass while a whole country silently can't check out. DiagnosticIQ's free dashboard checks your zones for the gap: regions with no enabled method behind them, an empty Rest of the World fallback, live-rate methods with nothing static to fall back on. And because it keeps watching, the next time someone toggles a method off you hear it from DiagnosticIQ rather than from your quarterly numbers.
Get the free plugin →Made by Prima Digital — the team behind this guide. Free forever; no card to install.
How to know you fixed it
Use the address that was failing — in a fresh private window, the cart should now show at least one shipping option and let you reach the payment step. Then repeat with a deliberately obscure international address to confirm your fallback zone catches it.
Frequently asked
Am I losing orders right now?
Yes — for every address this affects, checkout cannot be completed. Add a method to Rest of the World now as a stopgap, then tune your zones properly.
Why does it work for me but not my customers?
Because your address matches a zone you built. The error only appears for addresses that fall outside every zone with an enabled method — which is never your own.
What's the fastest safe fix?
Put a Flat rate method in the Rest of the World zone. It guarantees nobody ever hits a dead end, and you can refine the rates afterwards.
Could this be caused by the products in the cart?
Possibly. A cart of only virtual or downloadable products needs no shipping at all, so no options is correct there. If it's a heavy or oversized physical cart, suspect a carrier returning zero rates instead.