Know what to fix, and why it needs fixing.
A useful misrepresentation fix list starts with evidence from your public store: the page, the wording and the problem to address. StoreVerifier gathers that evidence so you can see why a change is needed. The quick scans our owner tried took 30 to 60 seconds. They found policy links but did not open the policy pages. The comparison below shows those homepage-only checks beside the steps used for your report. Time alone does not prove coverage.
Observed quick scans, in 30 to 60 secondsthe store as text, as far as the homepage
StoreVerifier, in a few minutesthe store in a real browser, as far as the checkout
A fix should start with something we actually found.
Before changing your store, you need the page and the evidence behind a finding. These worked examples show the difference between an assumption and a captured problem.
Critical: your checkout forces shoppers to make an account.
- Product
- Not opened.
- Basket
- Not opened.
- Checkout
- Not opened.
- What it rests on
- Nothing.
An assumption with a severity label.
The checkout requires an account before it will take payment.
- Product
- Opened, and a size chosen.
- Basket
- Opened, and its price read.
- Checkout
- Entered, and read.
- What it rests on
the form that takes your details requires a password
, read from the checkout form itself.
A finding, with what it rests on.
The captured line tells you what to inspect: whether shoppers can buy without creating an account. Check the setting, make the change if needed, then try the guest checkout again.
The fix list needs evidence from the buying journey.
The first column describes the homepage-only quick scans our owner tried. The second is this scan. The rows show the steps a shopper takes, in order; they do not describe every tool or promise that every page will be reachable.
| Step | Observed quick scans, in 30 to 60 seconds | StoreVerifier, in a few minutes |
|---|---|---|
| Fetch the homepage as text | Yes | Yes |
| Check the certificate and the redirects | Yes | Yes |
| Run the page’s scripts and see what a shopper sees | No | Yes, in a real browser |
| Wait for the popups and banners that load late | No | Yes, on every page |
| Read the returns, shipping and terms pages | No, only finds the links | Yes, opens and reads them |
| Open a real product and choose a size | No | Yes |
| Press Add to cart and open the basket | No | Yes |
| Reach the checkout and read what it shows | No | Yes |
| Compare the product page’s price with the cart’s | No | Yes |
A claim about a page that was never opened has no captured evidence from that page. This scan marks blocked or unclear evidence instead of guessing.
How we gather the evidence for your fix list
Six steps connect a finding to the pages and wording behind it. The report records what the scan can verify and marks any gaps, so you know what needs another look.
We open the store in a real browser
- What happens
- The page is fetched, its scripts are run, and it is given time to settle before anything is read. Popups, timers and banners that arrive late are seen the way a shopper sees them.
- What it catches
- A countdown that resets on every visit, or a popup nobody can close. Neither is in the HTML.
We follow your own footer to the policy pages
- What happens
- Returns, shipping, privacy and terms are opened from the links a shopper would use, and the wording is read: how long the return window is, who pays return postage, whether a restocking fee is disclosed.
- What it catches
- A return window on the product page that does not match the one on the returns page. It takes two pages to see it.
We open a real product and choose a size
- What happens
- A product is taken off your store, not a demo. If it has options, one is chosen, so the buy button is live and the price on the page is the price of something.
- What it catches
- Product markup with no price, brand or availability in it, or a compare-at price that is being compared to nothing.
We press Add to cart, then open the basket
- What happens
- If something is standing over the button — a cookie banner, an age check, a country popup, a newsletter form — it is closed with its own close or decline button, the way a shopper would. Then the basket is opened and its price read.
- What it catches
- A product page that says one price and a cart that says another. The report shows both.
We go on to the checkout
- What happens
- The checkout is entered and read: whether a guest can check out, whether tax is shown before payment, whether the policy links are still there, and whether anything was added to the basket with the box already ticked.
- What it catches
- Tax that appears only at the last step, or an extra added with the box already ticked. Nothing on a homepage says what a checkout does.
We read the wording against policy
- What happens
- The wording that was captured is read against Google’s policies, in the languages the scan can read, and only the checks that can be verified from public pages count.
- What it catches
- A health claim, or wording that sells rather than describes. If the wording could not be verified, the report marks the gap instead of guessing.
Find problems across your public store.
Seven areas go into every report, and the route above is only where the difference is easiest to see. Each area below says what it checks, one thing it catches, and the step it needs first: the mark is filled where the observed quick scans covered that step, and hollow where they did not.
Static checks
Checks the certificate, whether crawlers are let in, the redirects, the schema markup and Google’s Safe Browsing list, when available.
- What it catches
- A certificate that has run out, or a robots file that shuts Google’s crawler out.
- The step it needs first
- Fetch the homepage as textCovered by these quick scans
Rendered checks
Checks popups, countdown timers, the contact details in the footer and currency switchers.
- What it catches
- A footer whose only phone-shaped digits are a tax number, not a number anyone can dial, or no address at all.
- The step it needs first
- Run the page’s scripts and see what a shopper seesBeyond these quick scans
AI policy analysis
Checks health claims, wording that sells rather than describes, whether a real business is behind the page and reviews that look written to order.
- What it catches
- A product that says it cures something, or two reviews that are the same text under different names.
- The step it needs first
- Run the page’s scripts and see what a shopper seesBeyond these quick scans
Policy pages
Checks returns, shipping, privacy, terms and what the contact page says.
- What it catches
- A returns policy that never says who pays to send an item back, or a contact page with no phone number on it.
- The step it needs first
- Read the returns, shipping and terms pagesBeyond these quick scans
Product pages
Checks the product markup, stock status, images and scarcity widgets.
- What it catches
- Markup that says out of stock while the page is selling the product, or a viewer count nobody can check.
- The step it needs first
- Open a real product and choose a sizeBeyond these quick scans
Checkout flow
Checks guest checkout, the policy links, the cart price against the page’s and tax before payment.
- What it catches
- A checkout that will not take payment without an account, or policy links that are gone by the payment step.
- The step it needs first
- Reach the checkout and read what it showsBeyond these quick scans
External signals
Checks whether the domain stays the one you typed and whether a crawler is shown a different page.
- What it catches
- A page that shows Google’s crawler one thing and a shopper another, or a shop that answers from a different domain than the one you typed.
- The step it needs first
- Fetch the homepage as textCovered by these quick scans
Know why a change belongs on your fix list.
How the scanner is tested, and what it currently stands behind, is on the accuracy page.
- It reads what shoppers and reviewers see
- Your live pages, from the outside, the way Google’s reviewers meet them. Anything the scan could not reach is marked as unreached, not passed.
- It tells you when it is blocked
- If your store will not let the browser in, the scan stops and tells you, instead of reporting a clean result.
Start with the findings, then work through the fixes.
This scan is free and shows the findings. The paid report adds affected pages, captured evidence and practical steps to fix supported problems. No account to scan, and no card to start. If it comes back clean there is nothing to pay.