By platform
Test WooCommerce store before it goes live
The store looks finished from your dashboard. Simulated visitors browse it from the outside, add a product to the cart and show the first step where the walk fails.
How do I test a WooCommerce store before it goes live?
Walk the store the way a stranger would, from the public address and signed out: the shop page, one product, the cart, then checkout with a delivery address. Check that each product page shows a price and a working add-to-cart button, that the cart total matches the items, and that checkout offers a shipping choice for the address you use. Look for a maintenance or coming soon screen that is still switched on, because it hides the store from visitors. A simulated test repeats that walk with visitors who have no login, records each step and shows the page where the walk stopped.
What this looks like in a report
“The grid is empty and nothing says sheets anywhere. My friend sent me here, so I expected products. I will check her post again rather than wait around.”
The fix. Turn off the maintenance or coming soon setting for the public pages, then reload the shop page in a private window and confirm the products show. Add one product and reach checkout with a delivery address to confirm a shipping choice appears before you announce the store.
An illustration. Run a test to see your own.See a real sample report
A store you built is not a store a stranger has walked through
Most owners test with the account that built the site, on a laptop, at the address they keep open all day. That session has saved settings, test products and no maintenance screen. A stranger arrives on a phone, from a search or a launch email, with no account, and meets whatever the public site shows. A store can look finished in your own check and still hide its catalog behind a setting, a broken product page or a checkout that offers no shipping. Only a walk from the outside matches the visitor who will actually buy.
- Open the shop page signed out, in a private window, and count the products you expect to see.
- Open one product and check the price, the photo and the add-to-cart button on a phone.
- Add two different products, then check the cart total against the item prices.
- Go to checkout, enter a delivery address and confirm a shipping choice appears.
- Look for a maintenance or coming soon screen that still covers the store's pages.
A walk from the outside, in order
Start at the public address with no login, in a private window. The shop page should list the products you plan to sell, with photos and prices that match your records. Open one product and read it the way a shopper would, checking the photo, the price, any options and the add-to-cart button. A product that loads without a button, or a price that reads zero, is a finding even if it looks fine in the editor.
Then add two products of different kinds to the cart. Check that the count rises, that the cart lists both, and that the total is the sum of the items plus any shipping the cart shows. Continue to checkout and enter a delivery address in the country you sell to first. The walk ends at the payment step, where a stranger would expect to pay.
What the signed-in check hides
Your signed-in view carries saved settings, a session cookie and the products you added while you set up the store, so the shop can look complete when a stranger sees a thin list. A maintenance page that you bypass as the owner can still cover the store for everyone else. Check the public address the way a stranger opens it, compare it with your own view, and treat any gap between the two as something to fix before launch.
Where a pre-launch walk usually stops
A pre-launch walk stops at the first missing piece: an empty grid, a product without a button, a cart total that ignores a quantity change, or a checkout with no shipping choice for the address. The shop page is the cheapest place to find an empty grid, and checkout is the place where a missing shipping rule costs the most. Walk in that order, and fix each stop before you go on to the next one.
Mimiq is independent and not affiliated with the platforms it names. Names belong to their owners.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A new product or shipping rule can stall the walk again
Launch is not the end of the walk. A new product, a sale price or a shipping rule can break a page that passed last week. Run the same simulated visitors through the shop, one product and checkout after each change, and compare the step where each one stopped. Protected previews need a site password in the run, which is part of paid credits. Each staging copy then gets its own saved run to compare against.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Should I test with my real products or with samples?
Use the products you will sell, with the real prices, because a sample can hide a price or stock problem. Keep one low-cost item in the store for the walks. Hide any test product before launch, since a live store still shows test items to shoppers.
Can a simulated visitor create an account?
It can fill in a sign-up form that the store leaves open to visitors. The inbox it uses is real, so a confirmation email reaches it. It cannot sign in with Google or a single sign-on button, so test those with your own account and note that the walk did not.
Does a clean walk mean shoppers will buy?
No. A clean walk shows that a stranger can get from the shop page to payment. It does not predict how many visitors will buy, and it does not replace the first real orders, which tell you more about demand than any walk.
How far does the walk go into checkout?
Up to the payment step. It fills in a delivery address, reads the shipping choices and the totals, and stops where payment begins. It cannot pay with a real card, so run a test order with the payment provider's test mode to check the last step.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.