Before you launch or pay for traffic
Website product page best practices: price first
A shopper on a product page is weighing three things: the price after shipping, whether their size exists, and whether the button works. Those three have to be visible without a long scroll.
What makes a website product page work?
A product page works when a shopper can see the price and any shipping note, choose the variant they need, and press add to cart without reading the whole description. Put those controls above the long text, and show stock and delivery next to the button. A simulated visitor opens the page on a phone, makes the choice and reports where it stopped, with a screenshot of what it saw at that step.
What this looks like in a report
“I need the price with delivery before I pick a color. The text is about the zip, the lining and the brand's story. I scrolled and still saw no total and no size, so I am closing the tab.”
The fix. Move the price, the shipping note and the size selector above the description, and put the add to cart button directly under the selector. Then open the product from a phone search result, choose a size and color, and confirm the button stays visible after each choice.
An illustration. Run a test to see your own.See a real sample report
The shopper has to hunt for the price and the size
Shoppers on a product page ask a short list of questions before they touch anything: what it costs with delivery, whether the size or color they want exists, and whether the button will take them to checkout. If the price shows without a shipping note, the size selector sits under four paragraphs of description, or the add to cart button stays hidden until a variant is chosen in a selector that is hard to tap on a phone, the shopper leaves with a question open. The owner already knows which size is in stock and where the button is, so the page looks clear from their seat.
- Price: is the price, with any shipping or tax note, visible before the description?
- Variant selector: can a phone shopper choose size and color without the menu closing?
- Stock and delivery: are they shown next to the add to cart button, not in the footer?
- Add to cart: does the button stay usable, and say what happens when a size is out?
- Images: does the gallery load on a phone, with the product in the first image?
The buying controls come before the story
Wrong: five paragraphs on the fabric's history, then the size selector. Right: the price, the size, the add to cart button, and then a short line about the material. The longer story and the sizing chart can sit below, where the shopper who wants them will scroll. The owner usually wrote the description first and placed the controls where the template put them, so the order reflects how the page was built, not how a shopper decides. Check the order on a phone, since the first screen is all a shopper sees before they decide whether to scroll.
An out of stock size should show, not vanish
A variant that is out of stock is often handled by hiding the add to cart button until a size is picked, or by graying a size without saying why. A shopper who picks a color, then a size, and then sees the button disappear thinks the site is broken. Show the size with its availability, label the button with the state, such as Out of stock in medium, and keep the chosen color when the size changes. The tell is a reset: pick a color, choose a size, change the color, and see whether the size clears. A reset is a fault the owner cannot see, because they already know the size they want.
The shipping cost has to appear before the cart
A shopper who sees a price without a shipping note will assume delivery is included, then meet a new total at checkout. Put a short line under the price, such as shipping calculated at checkout, and show the free shipping threshold if you have one. Then compare the product page price with the cart total for the same item and the same destination. A gap between the two is the mismatch that makes a shopper leave at the cart.
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 color or a review app can move the add to cart button below the fold
Product pages change when a new color is added, a review app is installed or the theme updates. Any of those can push the add to cart button below the first screen, or reset the variant a shopper just chose. Rerun the same phone path on your best-selling product after each change, and again before you send new traffic to it.
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
How long should a product description be?
As long as the shopper needs to decide, and no longer. A short paragraph on material, fit and care is usually enough above the controls. Put the longer story and the sizing chart below the buying controls, where a shopper who wants them will find them.
Should the page show reviews above the button?
Show at least a rating near the title if you have reviews. A review block that loads late on a phone can push the button down while the shopper is tapping it. Test the page after the reviews load, not only before.
Does a simulated visitor judge whether the product is good?
No. It does not predict whether a shopper will buy the product or what they think of its quality. It shows whether a visitor can find the price, choose the variant, see the availability and reach the add to cart button, and where they stopped.
Does the test judge my product photos?
It sees the page as the visitor's browser shows it, including whether the gallery loads and whether the first image appears on a phone. It cannot judge whether a photo is attractive or whether the color matches the item in daylight.
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.