WooCommerce Troubleshooting: A Store Checklist
Useful WooCommerce troubleshooting starts with a repeatable symptom. Locate the failed part of the store journey, collect the smallest useful evidence and test one cause at a time.
Read the guide
Search Field Notes
A useful next read.
36 field notes
No matching guide yet. Try “checkout”, “shipping” or “catalog”.
All Field NotesTurn “the shop is broken” into a test case
Write what you expected, what happened and the steps that led there. Include the affected page, product or cart, buyer/account state, browser and approximate time. You do not need a theory of the cause to create a useful report.
Keep observations separate from explanations. “This started after Tuesday’s update” is evidence about timing; “the update caused it” still needs testing. Note whether the failure is consistent, limited to one device or tied to a specific cart. A short repeatable sequence usually helps more than several screenshots with no explanation of how they connect.
Find the first failed part of the journey
Choose the branch that matches the symptom before changing settings. Catalog availability, checkout, payment, emails, delivery and admin operations involve different evidence. Work forwards from the first step that fails, rather than applying a collection of generic fixes.
Use these distinctions to route the case:
- Product cannot be selected: check product/variation availability and the template interaction.
- No delivery option: compare cart data, address and the first matching shipping zone.
- Payment accepted but order still pending: reconcile the transaction and notification path.
- Order reaches its expected state but no email arrives: check notification, mail handoff and delivery.
- Page or staff action is slow: measure that request and its dependencies.
Start with the operation that fails
The symptom tells you which part of the store to investigate first.
Before an order
Locate the failed product, cart, delivery or checkout step.
Repeat the exact basket and contextAfter an order
Compare payment state, WooCommerce notes, email and fulfilment handoff.
Follow the missing resultProvider or connector
Trace the relevant gateway, carrier, email or system response.
Send evidence to its owner
Collect evidence the right owner can use
Capture the visible error and a safe example. The technical owner can then request the relevant order notes, system context, browser response or component log through a private channel. Share the minimum needed, with personal details and tokens redacted.
Identify who controls the part involved: host, theme/custom-code developer, gateway, carrier or mail provider. A WooCommerce symptom can depend on an external account decision. A focused request with versions and a repeatable case lets that owner investigate without a dump of unrelated customer records or a shared administrator password.
Test one explanation on a controlled copy
If diagnosis requires changing components, use staging with a current recovery route. Keep payment, email and fulfilment activity isolated before creating test records. Match the relevant configuration and input shape, and note production differences that might affect the result.
Compare one hypothesis at a time. Theme or plugin conflict testing should reintroduce components deliberately and repeat the original case. Do not delete business records, remove authentication checks or retry live payments just to see what happens. If a provider only supports a live check, agree a controlled test with the authorised owner and verify the earlier transaction state first.
Close the case against the original symptom
After a proposed fix, repeat the failing steps and check neighbouring behaviour it could affect. A checkout repair needs the correct order result; a product-data correction needs its catalog/cart behaviour intact. Keep the release small enough that the result is understandable.
Record the cause where established, the change, tested environment and remaining follow-ups. If the symptom disappears without an explained change, keep that as an observation and continue investigating an intermittent failure. The useful outcome is a resolved flow with evidence, or a narrower next task with a clear owner.
Common questions
What should I send with a WooCommerce support request?
Expected/actual behaviour, exact steps, relevant safe cart or product, approximate time and a redacted error. Include recent changes without treating them as a confirmed cause.
Do I need to send admin access straight away?
Start with context and safe evidence. Agree the task and required permissions, then grant access through a secure named-account process.
When is troubleshooting complete?
When the original case and relevant surrounding flow pass after the recorded fix, with any remaining provider or environment limits made explicit.