Skip to main content

What’s better in the scanner

Each update below makes the evidence tighter, the calls clearer, or the report easier to act on. Plain English, dated, and written for the merchant who has to use it.

These are customer-facing release labels, not internal benchmark runs. A whole-number update marks a material change to how StoreVerifier collects or explains evidence; a decimal update marks a smaller, verified improvement.

Update 16.54Latest

Seven more checks read the page instead of matching words

Checks that used to depend on lists of words in a few languages now read what your pages say, in any language, and quote it. No check is limited to a set of languages by a word list any more.

ChangedTax at checkout
The scan reads your basket and checkout for the line that shows tax, and quotes it. It used to look for a tax word, which could take a VAT number or a “spend £100+VAT” offer for a tax line.
ChangedTerms page
A page linked as your terms is read to tell terms and conditions from a legal notice. It used to go by the page’s name.
ChangedP.O. box
The scan reads every address your store shows, on every page it read. A P.O. box is a finding only when it is the only business address anywhere. A box beside a street address, or one that returns are sent to, is not.
FixedPhone in structured data
The phone number in your structured data is compared with the one on your pages as a whole number. It used to compare only the last seven digits.
ChangedPhone number
A number written without spaces or a country code is read in its sentence, to tell a phone number from a registration number, in any language.
ChangedTax number
A tax or company number is found under any label, in any language. The scan no longer reports that it cannot check a page because of the language it is written in.
FixedBusiness name in the footer
A footer that names the shop by a trading name is read as naming the business. A “powered by” line or an agency credit is not taken for it.
Update 16.53

Prices with no label are read; fake urgency is critical; where orders ship from is checked

The scan reads a product price however the page is built, treats urgency it can prove is fake as a critical finding, and checks whether your pages say where orders ship from. A footer with no address in it is now reported as that.

FixedPhone on the contact page
When the scan only works out which country your store is in late in the scan, the contact page’s phone row is now read again with it. It could say "could not check" while another row of the same report quoted the number from that page.
FixedAddress in the footer
A footer with no business address in it is now reported as that, even when the scan cannot tell which country your store is in. It used to say it could not check. When an address is quoted from another page, the report now says which page.
ChangedFake urgency
A countdown that restarts for each visitor, a stock number that moves when nothing was bought and a purchase feed that replays the same script are now critical findings. Viewer counters, sales counters and “someone just bought” notices are judged by watching the page twice, in any language. Five rows that only spotted English phrases are merged into that check.
AddedWhere orders ship from
The scan now reads your shipping page and product page for a sentence that says where orders ship from, in any language, and quotes it. A store that loads a supplier marketplace’s app and never says where orders come from gets a warning. The old warning for a page that merely mentioned a dropshipping platform is gone: Google does not prohibit dropshipping, it prohibits hiding where products are shipped from.
FixedProduct price
A product page whose price is not labelled as a price in the page code is now read. The scan finds the price by how it is written and drawn, so the structured-data price check and the phone-screen price check now run on those pages. They used to say the price could not be read.
FixedStructured data
When a product page declares offers for more than one page, the scan now reads the offers that point to the page it is on. It used to pick up the price of a neighbouring product and report that as the page's declared price.
FixedPhone and address
When the scan cannot tell which country your store is in, the phone and address rows now say so. They used to say "the homepage footer could not be read" although the footer had been read.
Update 16.52

Product pages built by script are found; promotions, reviews and pop-ups read by what is there

Stores whose pages are built in the browser now get their product and checkout checks. Promotion dates, review totals and homepage pop-ups are read by their shape and behaviour instead of English phrases.

FixedProduct pages
A product page that a script builds in the browser is now judged on what the browser shows. Such a store used to get no product checks and no checkout check at all. A product page that links many other products is still one product.
ChangedPromotions
An expired promotion is reported when your product data declares an end date that has passed and the reduced price is still charged. A date printed near a discount is read in any language; if it has passed, the row says it could not tell what the date ends, instead of failing.
ChangedReview totals
A claim such as "10,000+ reviews" is compared with the review total your own page data shows, in any language. It is a warning only when the claim is far above that total, not just for being there.
ChangedRepeated reviews
The same review text is counted as repeated only when it sits on two different review cards. Copies made by a sliding carousel, product tiles and "write a review" forms are no longer taken for repeats.
ChangedHomepage pop-up
A pop-up on your homepage is tested on a fresh visit: the scan waits for it and tries to close it. One that cannot be closed and asks for your details is the warning; one that closes, or only asks you to choose a country, passes. The row quotes what the pop-up says.
FixedPop-ups on policy and product pages
A pop-up that only asks the shopper to choose, such as a country picker, is no longer reported as "could not be closed" on policy and product pages. The homepage row already passed it; all three rows now give the same answer. When two pop-ups are up at once and one key press closes one of them, that pop-up is now counted as one a shopper can close, instead of "could not test".
FixedOut of stock
The buy button is found by the form it belongs to, in the product's own part of the page, so a button on a related product no longer counts as this product being on sale.
FixedVAT in prices
A checkout total that is higher than the product price is no longer reported as VAT added on top when the scan could not read the delivery charge. The row says it could not tell delivery from tax.
AddedIndexing
When a product page names another address as its main version, that address is also checked for a "do not index" instruction.
Update 16.51

AI findings must stand on what your pages say, checked by code

A finding from the AI reader is now kept only when it names what it found from a fixed list and its quote is on your page. Lists of English words no longer decide which AI findings you see.

ChangedPolicy findings
A policy finding from the AI reader is shown only when it quotes your policy page. A finding about your homepage is no longer filed as a policy problem, and "the page does not say X" is left to the checks that read every policy page.
ChangedUrgency
Words such as "limited time only" are no longer reported on their own. An urgency finding needs a countdown, a stock count, shopper activity, or an offer whose printed end date has passed.
ChangedReviews
The AI reader no longer judges how reviews sound. It reports one thing: the same review printed twice under different names or products, with both copies quoted.
ChangedRestricted products
What you sell is read on each sampled product page, in any language, instead of from your homepage. A restricted category is a finding only when your own product data files the product under it; otherwise the row says it could not confirm.
FixedPricing
A pricing finding from the AI reader needs one item shown at two prices, both quoted from your pages. A figure your pages do not show is no longer reported.
FixedPromotions
A date written year first, such as 2026-12-05, is read as 5 December. It was read as 12 May and could be reported as an expired promotion.
ChangedFinding text
The line "Our reading" under each finding is gone unless the finding has its own. It used to repeat one of seven general sentences.
Update 16.50

A policy page shoppers cannot reach from your storefront is a failure

Your returns, shipping, privacy and terms pages have to be reachable from your storefront at all times. A page that exists but is not linked, or is shown only at checkout, now fails.

ChangedPolicy pages
A policy page that exists at its standard address but that nothing on your storefront links to now fails, with the address the scan found it at. When the scan could not read every link on your store, the row still says it could not check.
ChangedPolicy pages
A policy that only your checkout links, or opens in a pop-up, now fails. The row says it was found only at your checkout and quotes the link or the pop-up; it is not reported as missing.
Update 16.49

Delivery, return and refund times, and your contact details, read where you state them

Policy times are now read sentence by sentence wherever your shop states them, and your address, phone, email and contact page are found on every page the scan holds, in any language.

ChangedPolicy times
Handling time, delivery time, return window and refund time are each read from the sentence that states them, and the row quotes that sentence. When a page gives several periods, the reading says which is which instead of leaving the row undecided.
AddedPolicy times
A time stated outside your policy pages now counts: on the product page, in a policy pop-up at checkout, beside a delivery option, or in a strip shown on every page.
ChangedDelivery claims
The two delivery-consistency rows now compare the dispatch and delivery times your pages actually state. A difference is reported only with both sentences quoted. A shop is no longer passed because it used none of a list of English phrases.
FixedBusiness address
An address written without a postcode, or with the town first, is now read. Where the footer shows part of an address the scan cannot complete, it is read for its meaning, and "no address in the footer" is reported only when that reading agrees there is none.
FixedContact page
A contact page linked under another name is found by what it holds: a contact form, or your address, phone and email together. When the scan could not read every link, a contact or About page it did not find is marked as not checked instead of missing.
FixedContact email
The contact email row reads every page the scan holds and says where it found the address. It used to read the homepage only.
FixedTax number
A tax or company number under a label the scan had no word for is now read and checked, so it is no longer reported as missing.
Update 16.48

Checkout checks read the basket and the form, not English phrases

Guest checkout, tax lines, pre-ticked extras, minimum orders, delivery charges and checkout policy links are now read from what your checkout does, in any language.

ChangedGuest checkout
Guest checkout is read from the checkout step itself: a step that asks for your details and no password passes; a required password is the warning. The word "guest" on a page no longer decides it.
FixedTax at checkout
A tax line is recognised by its numbers before its name: the tax amount your platform prints, or your total restated without tax. A checkout that shows tax in a language the scan had no phrase for now passes.
ChangedPre-ticked extras
A ticked box with a price beside it is tested by unticking it and reading the total again. If the total drops by that price, it is reported. An add-on app whose option the scan could not find is no longer counted as a warning; the row says it was not checked.
ChangedOut of stock at checkout
A product that cannot be added is read from your own basket, before and after the click, instead of from a list of sold-out phrases. The row names the product the scan tried to buy.
ChangedMinimum order
A minimum order is reported when the basket holds the item, the checkout will not go on, and the page shows an amount above the basket total. A line such as "minimum order quantity: 1" is no longer a finding.
ChangedDelivery charges
A promise of free delivery on your policy page is held against the charge your own basket or checkout shows. When the scan could not test the promise, the row now says so.
FixedCheckout policy links
A checkout link counts as a policy link when it leads to one of your policy pages, whatever its label says. A link labelled only "here" that opens your privacy policy is now counted.
FixedCompany details at checkout
A required company or tax-number field is recognised from how the field is built, in any language. A required email field with "company email" as its hint is no longer reported.
Update 16.47

Broken links, blocked scans and page layout judged by what the browser meets

Dead links, error pages, blocked scans, hidden text, mixed content and phone layout are now read from how your pages answer and how a browser draws them, in any language.

FixedBroken links
A policy link is reported as broken when the server says the page is gone, or when it answers with the same page a made-up address on your shop gets. A real page whose title happens to contain "not found" is no longer called broken, and your shop's "page not found" page is recognised in any language.
FixedBlocked scans
A shop whose title or opening words contain a phrase such as "forbidden" or "access denied" no longer loses its scan. The scan stops only when the page is bare and something shows the shop turned the scanner away. When a plain request reaches your store and only our browser is shown an empty page, the scan carries on with the store it has.
FixedComing-soon pages
A holding page is recognised by what is missing from it: no store links, no price, no product, and no product page anywhere. A shop with a heading such as "New collection coming soon" is no longer reported as not open.
ChangedHidden text
Hidden text is now measured in the browser: text drawn in the colour of what is behind it, at size zero, or far off the page. Rules in your stylesheet are seen too, and text kept for screen readers is not reported.
ChangedMixed content
Insecure files are reported from what the browser actually did with them. A file the browser refused to load is reported with its address; a plain link nobody loads is not.
ChangedPhone layout
The phone check measures your homepage on a phone-sized screen: whether it is laid out at the phone's width and whether it scrolls sideways. It used to look only for one tag in the page source.
ChangedRedirects
The HTTPS check fails only when a page is really served over plain HTTP, not when a request was turned away. Redirect hops are counted on product addresses, the pages your ads lead to.
Update 16.46

Product data and unfinished pages read by what is there, in any language

Product data rows now read every copy of your product markup, and unfinished template text, sign-in walls and image sizes are judged by the page itself, not by a list of English phrases.

FixedProduct data
A field such as brand, price or identifier is reported missing only when no copy of your product data carries it. Data a script adds after the page loads now counts, in either format.
AddedProduct data
A declared value is checked against what the field allows: a currency must be a real three-letter code, and availability and condition must be values the standard defines. A value that is not is quoted on the same row.
FixedProduct data
A product page the scan could not open in a browser is no longer reported as having no structured data. The row says it could not be checked and stays out of your score.
ChangedUnfinished pages
Filler text, a platform's default starter text and unfilled template tags are found by their shape on the homepage, product pages and policy pages, in any language. A short returns policy is no longer a warning on its length alone.
ChangedSign-in walls
A product address that answers with a sign-in page, or a product page with a sign-in standing where the price would be, is read from the page itself. English phrases such as "log in to see price" no longer decide it.
FixedProduct images
The main image of every sampled product is measured, not only the first. When an image cannot be measured the row says so instead of staying silent.
ChangedProduct images
An image hosted by a stock photo provider is no longer counted as a watermark warning. The scan has not looked at the picture, so the row says it was not checked.
Update 16.45

Prices and stock checked on every sampled product, and across your catalogue

Sale prices, stock and basket prices are now each read one way, on every product page the scan opens, and reduced prices are also read from your own product listing.

AddedSale prices
Reduced prices are now also read from your shop's own product listing and its sale section, not only from the product pages the scan opened. A product listed at half price or less beside a higher reference price is reported with its address, wherever it sits in your catalogue.
FixedStock
What a product page says about stock is read in any language, from the buy button and the words beside it. A page marked in stock in its structured data while its buy box says pre-order is now reported on every sampled product, not only the first.
FixedPrices
The price a product page shows is read one way for both the structured-data check and the basket check, so one page can no longer agree in one row and differ in the other. The basket price is your shop's own basket line for the item, per unit, in the currency it charges.
FixedReturn policy data
When your structured data declares a return window that differs from your returns page, the row now quotes both: the declared window with the countries it applies to, and the sentence on your page. A shop that declares one window per market is no longer told its page contradicts the first one.
FixedProduct type
A product that Shopping ads do not support, such as a service or a download, is reported only when the product page itself says so and your shop's own product data agrees.
Update 16.44

A policy page we could not look for is no longer called missing

The returns, shipping, privacy and terms page rows now say what the scan actually found: a page, a page nothing links to, a policy shown only at checkout, or a page it could not look for.

FixedPolicy pages
When the scan could not read every link on your store, because a link turned it away or a reading step did not run, a policy page it did not find is reported as not checked and left out of your score. It used to be reported as missing.
ChangedPolicy pages
A policy page that exists but that nothing on your storefront links to is no longer a clean pass. The row says the page was reached only at its standard address and asks you to link it from your footer.
FixedPolicy pages
A policy your checkout links, or opens in a pop-up, is no longer reported as missing. The row says shoppers meet it only at checkout and quotes the link or the pop-up.
FixedPolicy pages
When a store turns away our plain request but lets a browser in, its standard policy addresses are now asked through the browser, so its policy rows are read instead of left unverified.
FixedPrivacy policy
A privacy policy kept inside another page is found by its own heading and the text under it. A terms page that only mentions personal information is no longer taken for your privacy policy.
AddedShipping policy
When no shipping page is found but your structured data declares shipping terms, the row names what is declared. The terms still need a page shoppers can read.
ChangedReturn address
The return address is read as the address your returns page prints, in any language, instead of from a list of phrases such as "send returns to". An address with no postcode is read by the policy reader.
Update 16.43

A boast is no longer reported as a false claim

Words such as "#1", "best" or "biggest selection" are no longer findings. Claims of fact your pages do not back up, such as health effects, tests and awards, still are.

ChangedMarketing claims
A superlative or praise of your shop, such as "#1 choice", "biggest marketplace" or "high quality", is no longer reported. A health or medical effect, a test, certification or award, an environmental claim or a claim about where a product is made is still reported when your pages do not back it up, whatever language it is written in.
Update 16.42

Checkout checks read the page, not a list of English words

Whether your checkout works, where it leads and how shoppers can pay are now judged by what the checkout page is, in any language.

FixedCheckout
A checkout showing a phrase such as "currently unavailable" for one option is no longer reported as a disabled checkout. The scan now decides from the page itself: whether there is anything to fill in and a way to pay.
FixedCheckout
A checkout on another web address is now judged by what that page is. A checkout that carries your basket at your product's price is treated as your checkout, whichever service runs it.
FixedPayment methods
A sentence that mentions crypto or bank transfer no longer fails the payment check by itself. The check fails only when the full list of methods your checkout offers has no normal way to pay.
FixedMarketplace links
Buy buttons that lead to a marketplace are now recognised across many more marketplaces and countries. Paying with a marketplace's own wallet is no longer read as sending the shopper away.
Update 16.41

Countdowns, pop-ups and reviews judged on what was actually seen

Countdown, pop-up and review checks now report only what the scan saw happen, and say so when it could not look.

FixedCountdowns
A countdown is reported as restarting only when two fresh visits see it start over. When the scan could not watch your pages, the row says so and is left out of your score, instead of reporting a countdown from its wording.
FixedPop-ups
A pop-up on a policy or product page is now reported only when it covers the page and a shopper cannot simply close it and read on. Pop-ups on product pages are now reported even when a policy page has one too.
FixedReviews
Review markup is reported as hidden from shoppers only after the scan has scrolled the page and read every place reviews can appear. A review app alone is no longer reported as importing reviews from another website.
FixedReviews
Reviews repeated across products are now found in the review cards shoppers see, not only in your markup. A star rating summary on a product tile is not counted as a review.
FixedReviews
Review dates are now compared with the registration date of your own domain name. A shop on an address its platform hands out is told the check could not run, instead of being compared with the platform's age.
Update 16.40

Links, crawling and certificates checked the way Google meets them

Navigation links, robots rules, cloaking and certificates are now each read one way, and a page that turned our scanner away is no longer reported as broken.

FixedNavigation
A menu link that turned our scanner away is no longer reported as working. A link that answers with your shop's "page not found" page, in any language, is now reported as broken.
FixedCrawlability
Your robots.txt is now checked for Google's shopping crawler as well as its main one, on every product and policy page found. When your robots.txt turns plain requests away, it is read through a browser instead. Your own blocking rule is no longer excused as a platform default.
FixedIndexing
One reader now finds a "do not index" instruction on your homepage, product and policy pages, whether it sits in the page, in the server's headers or is added by a script.
FixedStore access
A homepage that turned our plain request away but opens normally in a browser is no longer reported as unreachable. A closed or password-protected store is now recognised by the shape of its page, in any language, and confirmed on its other pages.
FixedCloaking
The cloaking check now runs on a product page and compares the offer shown to Google with the one shown to a shopper: name, price, currency and stock.
FixedSecurity
Every certificate check now uses one reader, checks each web address your homepage passes through, and quotes the error your site gave.
Update 16.39

Your contact details found where shoppers find them

Your address, email, phone and tax number are now also read from your product pages and from pages that only open in a browser.

FixedContact details
Your address, email, phone and tax number are now read from your product pages too, and from linked pages that turned our plain request away but open in a browser. A page the scan found but could not read no longer counts as missing your details.
FixedContact details
The phone number on your contact page is read as a shopper's browser shows it, and your platform's built-in contact page is now found.
FixedFooter
One reader now decides whether your footer shows an address, and the phone-screen footer check compares against the same desktop footer.
Update 16.38

Stock, currency and return windows read from what your shop declares

Stock is read from your platform's own catalogue and your buy box, currencies in any written form, and return windows from the sentence that grants them.

FixedCatalogue availability
The out-of-stock checks now read your platform's own product catalogue where your shop publishes one. Opening product pages one by one is now only the fallback.
FixedProduct pages
Whether a product shows as in stock is now read from its buy box in any language, not from a list of English words.
FixedPrices
The currency your page writes, such as "kr", "zł" or "lei", is now recognised for every currency. The currency check passes only when your structured data and your page really match; when the scan cannot tell, it says so instead of passing.
FixedPolicy evidence
Handling, delivery, refund and return times now pass only when the sentence that grants them has been read. A matching number on its own is no longer enough.
FixedReturns
A return window you declare in structured data is now read wherever you declare it, including your business's own record.
Update 16.37

Pop-ups shown as they are, and a store that blocks us is told so

You now see what each pop-up says, a store that blocks our scanner is told so plainly, and two different tax numbers on one store are reported.

ChangedPop-ups
Every pop-up, countdown and activity row now shows what the pop-up says, so you can judge whether it is an ordinary promotion or something a reviewer could question.
ChangedStore access
When your store blocks our scanner, the report now says so plainly and leaves those checks out of your score. A store that blocks automated visitors can block Google's crawlers too. A page that answers with an error, such as a missing page, is still reported.
AddedBusiness identity
Two different tax or company numbers of the same kind on your store are now reported as a critical problem. A reviewer cannot tell which business is selling.
ChangedLanguage
The two language checks are now one, "Language consistency across pages".
ChangedContact details
The separate "Public phone number" row is gone. The footer phone check now covers it, including when the page could only be read as your server sent it.
Update 16.36

Your product pages, found and told apart from your categories

A category page is no longer graded as a product page, and products listed in your sitemap inside category folders are now found.

FixedProduct pages
A category page whose product tiles each carry their own buy button is no longer graded as a product page. Your product checks are now written about a real product page, not about a category.
FixedCatalogue availability
Products your sitemap lists inside category folders, such as /category/sub/product.html, are now found and included in the stock sample. The scan used to stop at the first product with a simpler address.
Update 16.35

The stock check samples your whole catalogue

The out-of-stock check now looks at products from across your catalogue, and calls the catalogue "mostly out of stock" only when the sample can carry that.

FixedCatalogue availability
The products sampled for the stock check are now spread across your whole catalogue. They used to come from the start of your product list, which on many shops holds the oldest listings, where sold-out items collect.
ChangedCatalogue availability
"Catalogue mostly out of stock" is now reported only when the sample is large and one-sided enough to say it of the whole catalogue. A smaller share, such as 8 of 10 sampled pages, is reported as a warning that says what was seen.
Update 16.34

Buy buttons in any language, and no subscription finding without the page that sells it

The scan now finds your buy button by the form it submits, whatever its label says, and no longer reports missing cancellation terms when it could not find the page that sells your subscription.

FixedProduct pages
A buy button the scan did not know by its label, such as "Köp nu", is now found by the shape of the form it submits: one button, a quantity and the product it adds. Stock, availability and the phone-screen checks now read it, the same way the checkout test already did.
FixedSubscriptions
When your homepage or terms describe a subscription but the scan cannot find the page that sells it, missing cancellation terms are no longer reported as a finding. The row says what was read and is left out of your score.
Update 16.33

Your returns policy is read, not your returns form

The scan now finds the page that states your returns policy, rather than a form for starting a return or a page your basket link happens to lead to.

FixedReturns policy
A form for starting a return or withdrawing from a purchase is no longer read as your returns policy when your returns terms are written elsewhere: on a separate notice page, or as a section of your terms. The scan reads the policy, and says where it found it.
FixedReturns policy
Site-wide panels, such as accessibility or cookie settings, no longer make a short form look like a written policy page.
FixedReturns policy
A link your site redirects, such as a basket link that lands on an address containing the word "return", no longer makes that page your returns policy.
FixedPolicy pages
Numbered headings in your terms, such as "§ 6. Right of withdrawal", are now recognised, so a returns policy kept inside your terms is found and read.
Update 16.32

Policy pages, delivery times and basket prices read more carefully

Four fixes to what the scan finds on your policy pages and at checkout. Each one removed a finding your store did not deserve, or a pass it had not earned.

FixedPolicy pages
Some shop platforms label every text page as an "article". The scan used to treat your terms, delivery and privacy pages as blog posts because of that label alone, and reported them missing. They are now read as your policies. A real blog post, with its own date or author, is still left out.
FixedDelivery times
A delivery or dispatch time found on your terms page now counts only when the sentence is about delivery. A payment deadline ("if payment is not received within 7 days") was being accepted as your delivery time.
FixedDelivery and refund times
When the scan finds a sentence that may state your dispatch or refund time but cannot settle what it means, the row now says so, quotes the sentence and is left out of your score. It used to report the time as not stated anywhere.
FixedCheckout prices
The basket price is now compared with the listed price of the product the scan actually added. It could be compared with a different product the scan had looked at first, and show a mismatch that was not there.
Update 16.31

Reviews from another .co.uk website are told apart from yours

The review check now tells two websites apart the same way the rest of the scan does.

FixedReviews
A review your product markup says lives on another website is reported as imported. On addresses with a two-part ending such as .co.uk or .com.au, every website read as the same one ("co.uk"), so such a review read as your own.
Update 16.30

An answer the scan could not settle no longer counts against you

Two checkout checks that said the scan was withholding its answer were still scored as findings. They are now marked as not checked.

FixedCheckout
When the scan sees payment logos at checkout but cannot find a payment option a shopper could use, it says it cannot settle the question. That row used to count against your score as a serious finding; it is now marked as not checked and costs nothing.
FixedCheckout
The same applies when your checkout is served over HTTPS but the scan could not finish validating its certificate.
Update 16.29

The pages your store links come first

On WordPress stores, the scan now reads and chooses the policy and contact pages your store links before any page WordPress merely publishes.

FixedPolicy pages
WordPress publishes every page a store has ever made, linked or not. The scan used to read those alongside your own links and could pick an old, unlinked page, such as an English contact page on a French store, and then report that your pages switch language. The pages your store links are now read and chosen first; an unlinked page is used only when nothing you link answers.
Update 16.28

Business identity findings are settled by your own pages

An AI review concern about your business identity now names exactly what it is about, and the scan settles it from what it read on your store.

ChangedBusiness identity
A concern that your store shows no phone number, email, address or registration number is now left to the check that reads that detail across your store: when that check found it, or already reports it missing, the AI review no longer adds a second finding.
ChangedBusiness identity
Two different names, addresses or registration numbers for your business are reported only when both are quoted and found on your pages. Concerns about how your business is set up that no Google requirement covers, such as the country you trade from or a free email provider, are no longer shown.
Update 16.27

A contradiction quotes both sides

When the AI review says two statements on your site disagree, it now quotes both, and both are checked on your pages before the finding reaches your report.

ChangedAI review
A contradiction finding now quotes both statements, and each is checked on your pages. One whose second statement could not be found is no longer shown: a single quote cannot show that two things disagree.
Update 16.26

AI review findings quote your page word for word

Every AI review finding in your report now stands on words found on your own pages. A finding whose quote cannot be found there is no longer shown.

FixedAI review
When the AI review finds two parts of your site that contradict each other, it quotes both. Each quote is now checked on your pages on its own; such findings used to be marked unverified because the two quotes were checked as one.
ChangedAI review
An AI review finding whose quote cannot be found on your pages is no longer shown. It used to appear in your report marked as unverified.
FixedAI review
A contradiction the AI review finds on one page, such as two different free-delivery thresholds in your banners, is no longer dropped because the check that compares your pages had only one page to compare.
Update 16.25

A product is judged by what it is, not by one word

The prohibited and restricted product checks no longer react to a single word. A candle scent, a colour or a sticker design is not the product.

FixedProduct categories
The checks for prohibited and restricted products used to react to words such as "tobacco", "gun" or "nitrous oxide" anywhere on a product page: a candle scent, a colour, a footprint note. A product whose page uses such a word is now read as a whole, in any language, and a finding quotes the words that show what the product is.
FixedProduct categories
Products shown in a "you might also like" strip are no longer read as the product on the page.
Update 16.24

The catalogue stock check says when it could not look

The check that samples your catalogue for sold-out products now always reports, and reads each sampled product from its own data.

FixedStock
When too few of your product pages could be sampled, the scan used to say nothing about your catalogue's stock. It now says it could not check, with how many pages answered, and that row does not count against your score.
FixedStock
Each sampled page's stock is now read from that product's own data. A sold-out product shown beside an in-stock recommendation used to be read as in stock.
ChangedStock
A product your data marks out of stock is reported as a data error only when its buy button can actually be pressed and the page does not say it is sold out.
Update 16.23

No stock warning without a look at your buy button

A product page the scan could only read as code is no longer told it shows no stock information. A buy button your theme draws with a script is only there once a browser opens the page.

FixedStock
When a product page was read without a browser and no stock wording or buy button was found in its code, the scan used to warn that the page shows no stock information. It now says it could not check, and that row no longer counts against your score. A page a browser opened is still read as before.
Update 16.22

Sale prices are read from what your page shows

A crossed-out price is now found by how your page draws it, in any language, or from the sale price your product markup declares. A label such as "Regular price" no longer raises a finding on its own.

ChangedPricing
A reference price is now found when your page draws it crossed out beside the price you charge, whatever your theme calls it and in any language, or when your product markup declares it as a strikethrough or list price. The size of the saving is worked out from the two numbers.
ChangedPricing
Words such as "Regular price", "was ... now" or "90% off" no longer raise a finding on their own: many themes print them on every product, on sale or not. The separate "was/now" finding is now part of the reference-price finding, so one sale is one finding.
FixedPricing
A price written as "$1,299" on a page in another language is no longer read as 1.299 when the price on your page is compared with your product data and your basket.
Update 16.21

Your product markup is read one way

The scan read your product's structured data in two places, and the two could disagree. It is now read once, the same way for JSON-LD and Microdata, and every check uses that reading.

FixedProduct data
If your theme lists a product's offers inside a nested list, every part of the scan now reads the price. One part used to see it and another did not.
FixedProduct data
A brand your markup names by pointing to another part of the same page is now read as the brand's name. The report used to quote the pointer's address as your brand.
FixedProduct data
Microdata product markup placed inside your site's own markup is now read. It used to be missed, and the page read as having no product markup.
ChangedProduct data
Microdata product pages now get the same checks as JSON-LD ones: barcode or part number, condition and currency. Price, stock and brand come from the product the page is about, not from the first price found anywhere on the page, which could belong to a related product.
Update 16.20

Price findings from the AI review are back

Since 30 September every AI pricing finding that named an amount was being dropped before it reached your report. It is checked against what the review read again.

FixedPricing
A pricing finding that quotes an amount, such as a "was" price or a delivery charge, is now kept when that amount is on the pages the review read, and dropped when it is not. A change on 30 September left the check with no page text to look in, so every such finding was dropped, true or not.
Update 16.19

More of your product pages are found

Some shops first send a product's address as its category page and let a script turn it into the product. The scan now waits for the product, so your checkout and phone checks run.

FixedProduct pages
A product page that first arrives as its category page, naming the category as itself and listing many products, is now waited on until it names itself, and is then read as your product. The scan used to call every such page a listing and say it found no product page, which left the checkout and the phone checks unchecked.
FixedProduct pages
A product page whose buy box also sells the rest of a set, with a buy button for each item, is now read as that product's page: the product your page heading names is the page's own. It used to be refused as a page of many products.
Update 16.18

The AI review is held to what the page shows

Three findings the AI review could raise wrongly are now checked against the scan's own reading of your page before they reach your report.

FixedReviews
A reviews carousel that loops repeats its own slides in the page code. The AI review used to call those copies "duplicated testimonials". When the scan's own check finds no real repeat, that finding is no longer published.
FixedPolicy evidence
An ordinary bracket in a policy, such as "[Re: Privacy Compliance Officer]", is no longer reported as left-over template text. A real template leftover, such as "[INSERT RETURN ADDRESS]", still is.
FixedScore
A missing terms or shipping page is now one finding. The AI review saying the same page is missing no longer adds a second finding and a second charge to your score.
Update 16.17

A pre-order is not an item in stock

When your buy button says pre-order or backorder while your product data says in stock, the report now says the two disagree, quoting your button.

AddedProduct pages
Your product page's buy button and the text around it are now read, in any language, for whether the item is in stock, on pre-order or on backorder. A pre-order or backorder shown to shoppers while your structured data says InStock is reported as a mismatch, with the words your page uses.
ChangedCheckout
Which of your checkout's choices is the payment choice is now read in any language, and only the methods it lists count: a card, PayPal, cash on delivery or an invoice. A bank transfer on its own is not counted as a card or PayPal.
Update 16.16

Product markup a script adds, and company numbers, read as they are

A product page the scan did not open in a browser is no longer reported as missing the structured data your shop adds by script, and a company registration number is no longer called a tax number.

FixedProduct pages
When your shop adds its product structured data with a script, and the scan saw that on one of your product pages, a second product page it read only from the page code now says it could not check, instead of "No supported Product structured data was detected".
FixedBusiness identity
A company registration number, such as a Companies House number, is now named as one. The report used to call it a VAT or tax number.
FixedProduct pages
A product whose only identifier is a template placeholder, such as the part number "123456789" or "0000000", is no longer passed as identified. The report says the number is a placeholder and what to put there instead.
FixedCurrency
A country picker where every country pays in the same currency is no longer reported as a currency switcher. It is counted by the currencies it offers, not by the countries it lists.
FixedCurrency
A currency picker that your theme shows only in the phone menu is now found, and the report says it is on the phone version of your page. It used to say no currency switcher was there.
ChangedCheckout
The currency your checkout charges is now read from the amounts themselves, in any language: all of them in one currency, or the currency whose items and delivery add up to the total. It no longer depends on the word beside the total.
Update 16.15

Your phone and email links count as contact information

A phone number or email address your homepage links is now counted as contact information, and a contact page that was too busy to answer the scan is no longer reported missing.

FixedContact details
A homepage with no link to a contact page, but with a phone number or email address shoppers can press, no longer gets "No contact page/link was detected". The report names the number or address it found.
FixedContact details
When your contact page could not be reached because your server was busy or refused the scan, the report now says it could not check, and it costs you nothing. It used to say no contact page was found. A contact page that is not there is still reported.
FixedContact details
A contact page that your theme labels as an article is now accepted as your contact page. It used to be refused, and the report said no contact page was found.
Update 16.14

Your address is quoted the way your footer shows it

The address the report quotes now ends where your footer's address ends, instead of running on into the heading below it or starting inside a company number.

FixedBusiness identity
When your footer is read from your page's code instead of the browser, each block of it is now kept on its own line, the way a shopper sees it. A town is no longer joined to the heading after it, such as "Gréoux-les-Bains Horaires".
FixedBusiness identity
A company registration number printed just before your address is no longer read as part of it. A label such as "Address:" is no longer taken for the name of your town, and the report quotes the address that follows it.
Update 16.13

A legal notice we could not open is not a missing tax number

When your legal notice page could not be opened during the scan, the tax number check now says it could not check, instead of reporting your tax number as missing.

FixedBusiness identity
Every legal notice or Impressum link in your footer is now tried, not only the first, and a page that is busy is asked again after a short wait. A shop that links two, where the first was busy and refused the scan, is now read on the second.
FixedBusiness identity
When no legal notice page could be read, because your server was busy or refused the scan, the tax number check says it could not check and costs you nothing. A legal notice link that leads nowhere is still read as no page.
Update 16.12

More of your checkout is read

Policy pop-ups, a choice of payment methods, and a first step where shoppers pick delivery and payment are now read at your checkout. Your currency is checked against what the checkout charges.

FixedCheckout
Refund, shipping, privacy and terms buttons in your checkout that open your policy in a pop-up are now opened. When the pop-up shows your policy, the report passes the check and quotes it, instead of saying it could not confirm your policies are reachable.
FixedCheckout
A checkout that offers a choice of payment methods, such as iDEAL, Klarna, a card or a bank transfer, is now seen as offering them, even when the card form stays folded until one is picked or the choice sits on the same page as the delivery choice. The report names the methods instead of withholding the result. A method that cannot be picked with your chosen delivery is left out.
FixedCheckout
A checkout whose first step is a choice of delivery and payment, with prices, instead of a form asking for your details, is now recognised as your checkout. The checkout checks run on that page, where before the scan stopped at your basket and could not check them.
FixedCurrency
The currency in your product data is now checked against the currency your checkout charges, read from the checkout's own total. A basket or product page that converts prices for a visitor in another country is no longer taken for what you charge, and the report no longer tells you to change your currency to the one the scan was shown.
Update 16.11

Your phone number and email belong in your footer

Your business name, address, phone number and email are now each checked in your site footer, the one place a shopper and a reviewer find them on every page.

ChangedBusiness identity
The phone number check now reads your footer only. A number shown elsewhere on your homepage, such as in the header or a contact section, is named in the report, but it no longer counts as being in your footer.
AddedBusiness identity
A new check, graded critical like your address, for an email address in your footer, read the same way. An email shown only on your contact page or elsewhere on the homepage is named, and reported as missing from the footer. Each of these findings now says plainly that the detail must be shown in your footer, on every page.
FixedBusiness identity
A business address is no longer pieced together from bits of a page that stand far apart, such as a menu count and a year. Where no real address is shown, the report now says so.
FixedBusiness identity
When your homepage does not show which country you sell from, your contact and terms pages are now read for it, such as a phone number written with its country code. Your footer details are then checked instead of left as "could not check", and a detail your footer does show is no longer reported missing when the scan reads the footer a second time.
ChangedBusiness identity
An address, phone number or email missing from your footer and from every page the scan read is now one finding: missing from your footer, which is where it has to be. It used to be reported as missing from your whole store, which was wrong when a page the scan did not read showed it.
Update 16.10

One free scan a day, and three more scans with the report

The free scan still shows you what is wrong with your store. The full report now comes with three more scans of your store, in full, to check your fixes within 30 days of paying.

ChangedFree scans
Free scans are now one a day for each visitor, and still one a day for any one store, whoever runs it.
ChangedFull report
A full report now comes with three more scans of its store, each in full, to use any time within 30 days of paying. It used to open up to 10 scans a day for 30 days.
Update 16.9

Subscriptions are checked where you sell them

If you sell a subscription, the report now reads the page that sells it and your policies, in any language, for how it renews and how to cancel it. A word on your homepage alone no longer fails you.

ChangedSubscriptions
A subscription is found where it is sold: the product page's buy form offering a plan, or the plan in your product data. That page, your terms, homepage and footer are read for how the subscription renews and how to cancel it, and the report quotes what it found.
FixedSubscriptions
A shop whose product page says "Billed monthly" and "Cancel anytime" is no longer failed because its terms page did not repeat it. And a menu link or a sentence about cancelling an order is no longer taken for subscription terms.
FixedSubscriptions
A homepage that only mentions a subscription is no longer failed on that word alone. When no page the scan read sells one, the row says it could not check, and costs you nothing.
Update 16.8

A policy kept in your footer or your terms still counts

If your returns or delivery policy has no page of its own but is written in your site footer or inside your terms, the report now reads it there and says so, instead of calling it missing.

FixedReturns policy
A returns policy written in the footer of every page, or as a section of your terms, is now read where it is, in any language. The report names the page that states it and quotes it, and "Returns policy page exists" becomes a warning that the policy has no page of its own, not a critical "missing".
FixedPolicy evidence
Your site footer is now read like a policy page for every return and delivery fact: who pays return postage, how refunds are paid, the return window, and dispatch and delivery times.
ChangedPolicy evidence
When your policy lives on another page, a fact it leaves out is reported as not stated only when every page was read. A page the scan could not read leaves that fact unchecked, never missing.
Update 16.7

Template leftovers and blank policy pages

A policy page that still carries its template's unmade choices, or that your site links but shows nothing on, is now reported.

FixedPolicy pages
Template text left in a policy is now found on every policy page, the shipping page included, in any language. That covers a template's choice left unmade, such as two versions of one clause side by side, or a word offered in two forms like "nejmenoval / jmenoval".
FixedPolicy pages
A policy page your site links that is blank, in the page as served and as a browser shows it, is now reported as a missing policy. It used to be marked as something the scan could not check.
ChangedPolicy pages
When a policy page cannot be read, every row that depends on it now says why, for example that the page returned an error or is blank, instead of one general sentence.
Update 16.6

Two pages that say two different things

When two of your own pages give a shopper two different delivery prices, or two different return windows, the report now says so and quotes both.

AddedShipping policy
A delivery price or free-delivery threshold stated differently on two of your pages, such as your terms and a banner on your homepage, is now reported with both sentences quoted. Prices for different countries, for express and standard delivery, or for wholesale and retail customers are not counted as a clash.
AddedReturns policy
A return window stated differently on two of your pages is now reported with both sentences quoted. Google asks that your return policy is consistent throughout your website, including banners and the footer. A legal right of withdrawal you describe separately from your own return offer is not counted as a clash.
FixedReturns policy
A return window or refund time your policy states is no longer reported as "could not be verified" after the scan had read it. A second, older check used to overrule the reading; the reading now decides, and a sentence that refuses returns is still never counted as a window.
FixedPolicy evidence
A long policy page is now read to its end. A return window or delivery time near the bottom of a long terms page used to be missed, and a page the scan could only read in part is never reported as not stating something.
ChangedPolicy evidence
Each policy fact is now reported once, by the check that reads it on every page. A separate AI note about the same fact, which could repeat that check or contradict it, is no longer added beside it.
Update 16.5

Where returns go, and delivery times written with a tilde

Where to send a return is now read in your own language on every policy page, and a delivery time like "1~5 days" is read as the whole range.

FixedReturns policy
Where returns are sent is now read in any language, from your returns page, terms, shipping page and contact page. A policy that says the address or a prepaid label comes with the return instructions counts, and so does the postal address your terms point to, such as "the address given in these terms". Before, a return address could be reported as missing when it was there.
FixedShipping policy
A delivery or dispatch time written with a tilde, such as "1~5 days" or "3〜5日", is read as the whole range. It used to be read as the last number only.
ChangedShipping policy
Dispatch and delivery times are now also read from your site footer. A missing time is decided once, after every policy page and the footer were read, and a single second look no longer turns that into a failure.
Update 16.4

Delivery costs and policy time limits, read on every policy page

What delivery costs, and how long returns, refunds, dispatch and delivery take, are now read the way a shopper reads them: in your own language, on every policy page you publish.

FixedShipping policy
What delivery costs is now read in any language, from your shipping page, returns page, terms, contact page and any policy you link as a PDF, and the report quotes the sentence it read. Before, a cost written in many languages, or kept in a linked PDF, could be reported as missing.
FixedShipping policy
A shipping page that gives no price at all, not even free delivery or "calculated at checkout", is now reported. Before, a delivery time on the same page could stop the scan from saying so.
ChangedReturns and shipping policy
A missing return window, refund time, dispatch time or delivery time is now reported only after every policy page was read and none of them states it. A period stated on another policy page counts.
Update 16.3

Return fees, refunds and no-returns clauses, read in your own language

Three more parts of your returns policy are now read the way a shopper reads them, in whatever language they are written, with the sentence quoted back to you.

FixedReturns policy
A return fee your policy states with its amount is now reported as disclosed, which is what Google asks for. It used to be flagged as a problem. A fee named without its amount is still reported.
ChangedReturns policy
How refunds are paid is read in any language, and any method you state counts: money back, store credit or an exchange. Google asks that your policy says how refunds work; it does not require money back. A policy that never says is reported.
FixedReturns policy
A sentence that refuses returns on named items, such as sale items or opened goods, is no longer reported as refusing every return.
Update 16.2

Who pays for a return is read in your own language

The scan now reads your returns policy the way a shopper does, in whatever language it is written, and quotes the sentence that says who pays to send an item back.

FixedReturns policy
Who pays for return postage is now read from your returns page, your terms and your shipping page in any language, and the report quotes the sentence it read. Before, plain statements in Czech, Japanese, German and other languages could be reported as missing.
ChangedReturns policy
If the scan could not read the page this time, the row says so and costs you nothing. It is reported as missing only when every policy page was read and none of them says it.
Update 16.1

Free scans: two a day, and one a day for each store

The free scan shows you what is wrong with your store. Once you know, the full report is the list of fixes, and every scan of your store for the next 30 days opens in full.

ChangedFree scans
Free scans are now two a day for each visitor, and one a day for any one store, whoever runs it. A store you have bought the report for still gets up to 10 scans a day for 30 days.
Update 16.0

The report now shows only what Google Merchant Center asks for

We went through every check the scan runs and asked one question: does a Google Merchant Center rule stand behind it? The ones that did not, and the ones that repeated another check, are gone from the report and the score. What is left is the list of things Google can hold against your store.

ChangedWhat the scan checks
The scan no longer reports search and site-housekeeping items that Merchant Center does not require: page title, meta description, social sharing tags, favicon, canonical tag, whether a sitemap or robots file exists, security headers, copyright year, custom domain, social media links and tracking code. They no longer affect your score.
ChangedWhat the scan checks
It also no longer reports cookie banners, customer service hours, import duty wording, data-protection wording, where you ship to as a sentence, all-capital product titles or payment logos on the homepage. Google does not ask for any of these.
ChangedFindings
Checks that reported the same problem twice are now one: product image size is one row, a missing contact link no longer repeats a missing contact page, and a free e-mail address is reported once, not again for the contact page. Small product images are still reported against Google’s published size rules.
Update 15.3

The scan gets through to your checkout on more stores, and stops reporting things that were not problems

On about half of the scans run this month, the scan stopped before the checkout and the checkout checks were marked "not checked". It now gets past what stopped it: a cookie banner, a size or scent that has to be picked first, a basket with an unusual name, a sign-in page, a checkout built into the basket page. We also checked a fresh set of stores by hand, row by row, and fixed what the scan got wrong.

FixedCheckout checks
The scan picks a required option before adding a product to the basket, including options chosen from a drop-down list, and never presses a “Buy now”, wishlist or quantity button while doing it. It answers a cookie banner that locks the page, finds the basket by the counter that goes up when something is added, takes a sign-in page’s guest checkout, and reads a checkout built into the basket page as the checkout.
AddedCheckout checks
A checkout that opens but offers no way to order, in any language, is now reported as a disabled checkout, with the words your checkout shows. Before, it was only marked “not checked”.
FixedCheckout checks
The scan no longer adds a product twice when your header basket count does not update, which could report the basket price as twice the product price. A PayPal or pay-later box on a basket or product page is no longer read as the checkout.
FixedPolicy evidence
Policy pages that your shop system labels as articles in its page code are read as policy pages again. Some shop systems label every page that way, and the scan reported those stores as having no returns, shipping, privacy or terms page.
FixedPolicy evidence
Unfinished template text such as “[ LINK ]” in a policy is now reported, once. A returns page that asks shoppers to write “[Your order number]” is not. “Shipping costs will be borne by the customer on return” now counts as saying who pays for returns.
FixedTax and prices
“Including $1.18 in taxes” and “tax incl.” now count as a tax line. In the US and Canada, where tax is added once the address is known, a checkout that shows no tax yet is no longer reported as missing tax. A price written as “€32,95” is read as 32.95 on an English page, and prices are shown in your store’s currency, not guessed from a “$” sign.
FixedScore
One problem reported under two checks, such as a missing contact page and no contact link on the homepage, now costs the score once, as it is shown once.
FixedPop-ups
A discount pop-up (“10% off”) is no longer read as a count of other shoppers, and a newsletter sign-up is no longer reported as a cookie banner.
Update 15.2

The full report now covers your store for 30 days, and your score moves as you fix

The full report used to open the one scan you bought it from, so a re-scan after a fix came back locked. It now opens every scan of that store for 30 days after you pay. And a store with many critical problems no longer reads 0 however much is fixed: the number now shows the work.

AddedFull report
Every scan of your store run in the 30 days after you pay opens in full, up to 10 a day, in the browser you paid from or once you sign in. Fix something, scan again, and see exactly what is left and whether the change broke anything else.
ChangedScore
Each critical problem used to take a flat 15 points off, so a store with six or more read 0 whatever was fixed. Each critical problem now takes a quarter of what is left, and each major problem a twentieth. A store with any critical problem still scores 49 or below; under that line, each critical problem you fix now raises the score.
ChangedFree scans
Free scans are limited to 3 a day. The three findings a free scan shows in full are now picked once for your store, not again on every scan: a re-scan shows the same three, and one you have fixed drops off without being replaced.
Update 15.1

Phone checks are read from the page itself; screenshots no longer go to an AI

The scan still opens your pages as a phone would, but no screenshot of them is sent to any AI provider any more. The findings that reader produced had not reached a report since 11 September; the questions it tried to answer on a phone are now answered from the page itself, with the measurement quoted.

AddedPhone checks
On a phone-sized screen the scan now measures where your product’s own price and buy button sit, and checks that the phone version of your footer still carries the contact details and policy links the desktop footer shows. A folded footer section counts as present. Google asks for a price that is easy to view and a way to buy, and names no fold, so a price below the first screen is recorded, not charged.
ChangedWhat the scan checks
The checks only the screenshot reader performed, such as watermarks and supplier logos inside images, trust badges in pictures and broken phone layouts, are no longer listed as checks we run. Their findings had been held back from reports since 11 September. Guides that described them now say plainly what the scan does not look at.
Update 15.0

We re-checked every claim our reports had made, and fixed what was wrong

We went back through the reports this scanner has written, one claim at a time, and checked each against the page it was about. Where a claim was wrong, we fixed the reason for it, for every store, not only the one that showed it. The biggest changes: the page we grade as your policy must now be that policy, and a page in a language we cannot read is reported as unchecked rather than as silent.

ChangedPolicy pages
The page we grade as your returns, shipping, terms or privacy policy must now read as that policy. A shipping page linked as “Shipping + Returns”, an order-tracking form, a company-registration notice or a product catalogue is no longer graded as your returns policy or your terms. A policy kept as a section of your terms page, or one link away behind a customer-service page, is now found, and a page that answered us with a bot check is reported as one we could not read rather than graded as yours.
ChangedLanguage coverage
When a policy page is written in a language our readers do not cover, the checks that depend on reading it now say we could not check, and cost you nothing, instead of reporting the page as silent. We also read more wording in more languages: who pays return postage, refund and delivery times, shipping costs, duties and customer-service hours. And a payment or login widget’s code on a page is no longer read as that page’s words, which had made one French contact page read as English.
FixedBusiness identity
A footer that names your business was reported as showing no clear business identity unless it carried a company-form word such as “Ltd”. It now passes on your business name or a registration number; your address, phone and email keep their own checks. Tax numbers keep their final check letter, an email at a free provider we had not listed is no longer called a business address, and the demo contact details a theme ships with are not taken for yours.
FixedCurrency and payment logos
A hidden currency tag that payment add-ons place in the page was reported as a currency switcher. A switcher is now a control a shopper can use that offers more than one currency. A product photo whose file name contains a card brand no longer counts as a payment logo, and a card-logo image we cannot read is reported as unchecked, not as missing.
FixedPop-ups and urgency
A customer review saying “I just bought…” was reported as a “someone just bought” pop-up, a model-kit scale or opening hours as a countdown, “need it in a hurry?” as a low-stock claim, and a country selector as a marketing pop-up. None of these is reported now.
FixedDelivery, return and refund times
Dispatch and delivery times are now told apart by what their own sentence says. A payment term, a tracking-number note, an order-cancellation window or a deadline to report a fault is no longer given as your delivery, return or refund time.
FixedReturns policy
“We cannot ship to a PO box” was reported as a PO-box return address, a customs handling charge as a restocking fee, a store-credit or exchange-only policy passed as giving money refunds, and “no returns on coffee and snacks” was called a blanket no-returns policy. Each is now read for what the page says, and a page that does not say how refunds are paid is no longer passed.
ChangedAI findings
An AI finding that says a fact is missing is no longer shown when the scan quoted that fact from the same page, or when the AI says it could not read the page. Fake-urgency, fake-review and marketing-claim findings are shown only when the quoted words show the problem.
FixedCheckout
Policy links that belong to your payment provider or to a security check no longer count as your checkout policy links, and a cart price that differs from the product price is no longer reported as matching.
FixedProduct pages
Stock, scarcity and discount claims are read from the product’s own offer, not from related products, customer reviews or hidden text. Pages from shops whose SEO plugin marks every page as an article are no longer skipped.
FixedDouble counting
One free-email address, one urgency slogan and one AI finding that repeats a check were each reported more than once. Each now appears once.
Update 14.0

Every check is graded again, and one problem is reported once

Every check now carries a grade set by what it takes to pass a Merchant Center review. A detail your policy page should state and does not is graded like the problem it is, not as advice. And a problem that several checks used to report separately now appears once.

ChangedHow serious each finding is
All checks were graded again, one by one. When we read a page and a fact Google asks for is not on it (a return address, a refund time, handling and delivery times, your business name, address, phone or email where shoppers look) it is reported at that check’s grade rather than as a minor note. A store that turns our scanner away with an error or a bot check is now reported as critical, because Google’s own crawler can hit the same wall. A page we simply could not fetch still costs you nothing.
FixedDouble counting
A missing policy page used to be reported again as a missing link to it, and a missing contact page as a missing contact link; the same pop-up was reported for desktop and again for mobile. Each problem now appears once.
FixedReturns policy
A returns page that says “we do not charge any restocking fees” was reported as stating a fee. A fee the policy says it does not charge is no longer taken for one. And a returns page that does not say who pays for return shipping is now reported, where it used to be left out as something we could not check.
Update 13.7

A store in several languages is checked in the language you scanned

A shop with more than one storefront can point its structured data at a policy page from another storefront. The scan followed that link and read, say, the Turkish returns page for the English store, then warned that the pages were in different languages.

FixedPolicy evidence
When the policy page your structured data names lists its own language versions, the scan now reads the version for the storefront you scanned. If the named page is in another language and lists no versions, a page your storefront links in its own language is read instead. The report still tells you that your structured data names the other page, so you can correct it.
Update 13.6

Your product photo is measured, not its thumbnail

Many shops name their resized images after the original with a size tag added, such as “_xs”, “_300x300” or “-1024x1024”. When the page’s product image was one of those thumbnails, the scan measured the thumbnail and could fail a photo that is much larger.

FixedProduct images
A picture file with the same name as your product image, give or take one size tag, is now recognised as the same photo, and the largest copy the page points to is the one measured. It only counts if it really is bigger when we fetch it. On one shop we checked, a 43×33 thumbnail had failed the image check; the photo itself is 394×300.
Update 13.5

Links are followed where your browser follows them

Some shops tell the browser, in one line of their page code, where every relative link starts from. The scanner ignored that line, so on those shops it opened the wrong pages, often your homepage, when it went looking for your policies.

FixedFinding your pages
Pages that set a base address for their links (common on ePages shops and some app-style storefronts) now have every link resolved the way a browser resolves it. On one shop we checked, only 7 of 264 links used to reach the page a shopper reaches; now all 264 do, and its shipping cost and delivery area, which it states plainly, are no longer reported as missing.
Update 13.4

Every finding is named for the problem it found

Some findings were named after the check that ran, worded as if it had passed: “Phone number plausibility”, “Schema price matches visible price”. Each one now says what is wrong.

ChangedFinding names
Every check now has a name that states the problem, used whenever the finding’s own first line is too long or only describes what the scan saw. “Phone number plausibility” is now “Phone number looks invalid or from the wrong country”; “Policy page issue” is now “Store policy is unclear, incomplete or contradicted”. Findings that already named the exact fact, such as “Return window is only 7 days”, keep that name.
Update 13.3

A return address is recognised however your returns page introduces it

The returns check used to look for set phrases such as “send returns to”. A returns page that says “send it to this address:” and prints the address was told it had no return address. It now reads the address itself.

FixedReturns policy
If your returns page prints a full postal address — street, postcode and town for your country — it now counts as a return address, whatever words lead into it. A line that says the address is old or not to be used still rules it out, and an address from your contact page is still never taken as your returns address.
Update 13.2

An address only your structured data holds no longer counts as shown

Your business address has to be on the page, where shoppers and Google’s reviewers can read it. An address that sits only in your site’s hidden structured data is now reported as not shown, and a price can no longer be mistaken for an address.

FixedContact details
If your address appeared only in your site’s structured data (the code search engines read, which no shopper sees), the report said a business address was shown. It now says the address is declared but not shown on any page we read, and quotes it, so the fix is to print the address you already have. Where the same address is printed on your contact or policy pages, it still counts, and the report quotes it from that page.
FixedContact details
A fee written as a number and a currency, such as “65000 KRW”, could be read as a postcode and quoted as your address. A number with a currency code or symbol beside it is now never taken for a postcode.
Update 13.1

Your address is quoted on its own, and a real problem can no longer hide as a gap

The business address line now shows just your address, not the text around it. And a finding whose wording happened to sound like “we could not check” is now always reported as the finding it is.

FixedContact details
When your address sits in a block of contact text, the report used to quote the whole block — shop name, contact person and all. It now quotes the street, number, postcode and town it actually read, so you can see at a glance which address we found.
FixedWhat we could not check
A few findings were worded in a way that looked like our own “could not check” note, and could drop out of your report and your score. Every check now says outright whether it is a finding or a gap, and every gap says why we could not look: blocked, page not found, language not covered, and so on.
Update 13.0

Every finding is graded by what it costs you with Google

Critical, major and minor now come from one list that ties each check to Google’s own wording and to what reviewers ask for in practice. A missing returns, shipping or terms page is critical again, and any critical problem now shows as a failing score.

ChangedHow serious each finding is
Each check now carries its grade in one place, next to the Google sentence it rests on and how often merchants and Google’s community experts name it as a reason for suspension. Critical means the kind of problem that gets an account suspended; major means one that gets products turned down or holds up a review; minor means advice worth taking. Checks with no Google or reviewer backing no longer appear in your report.
FixedMissing policy pages
Since 16 September a returns, shipping, privacy or terms page we looked for and could not find was reported as something we could not check, so it cost nothing. It is a real gap and is now reported as one: a missing returns, shipping or terms page is critical, and a missing privacy page is major. A page we were blocked from reading still counts as not checked, never as missing.
ChangedYour score
A shop with at least one critical problem now scores 49 or below, so the number and the “fix first” label always agree.
AddedContact details
A new line says whether shoppers can reach you at all — phone, email, address, contact form or social profile — and it is critical when there is none. Your phone number, email address and business address are now looked for across your whole store, not only the footer, and each is major when it appears nowhere a shopper can see it.
Update 12.54

Fewer things reported missing that your shop actually shows

A round of fixes to lines that told merchants something was absent or wrong when it was not: your own contact details, your product pages, pop-ups, currency pickers and language versions, and policy findings with no Merchant Center rule behind them.

FixedYour business details
A tax number was missed when a letter such as ß sat earlier on the page, when your structured data spelled the field in a different letter case, or when it only appeared on your legal-notice page, which we now read when nothing else carries it. An email you declare in your own structured data, or that the browser shows as a link, now counts. Opening hours on your contact page are read from the page a browser shows, not only the cut-down copy some shops send to automated visitors. A copyright year or a “10% off” line is no longer read as a street address, and the ownership line many shops print just below their footer now counts as part of it.
FixedProduct pages
A check that tells a product page from a grid of products had stopped running without saying so; it runs again. Real product pages that were refused are now accepted: pages whose buy button sits inside a component, pages whose structured data names the address the shop redirected to, and pages whose product data is added by a script. A brand in Microdata is read from its value, the largest copy of the product photo is the one measured, a crossed-out price next to another product is not your price claim, and facts about checkout count only when we actually reached the basket or the checkout.
FixedPop-ups and switchers
A closed menu or drawer that sits over the page but lets clicks pass through is no longer reported as a pop-up. A newsletter game is not a “recent purchase” pop-up; that needs a count, or names that change while we watch. Your own image server is not somebody else’s. A footer picker that lists each country with its currency now counts as a currency switcher. A link with stray spaces is read the way a browser reads it, so a working social profile is not called dead. A dated line in your terms is a rule, not an urgency claim. And a shop that serves one language to browsers and another to automated visitors is no longer told its pages are inconsistent.
ChangedPolicy findings
The part of the scan that reads your policies was asked to flag “unreasonable” clauses, and it flagged plainly stated terms because they seemed strict or unusual. Google does not require a policy to be generous; it requires it to be there, to say how returns and costs work, to agree with itself, and not to be used to refuse what it promises. Every policy finding must now name the Merchant Center requirement it rests on, from a fixed list tied to Google’s own wording; a finding that rests only on fairness or on the law is no longer published. Across our stored scans, one in four published policy findings was of that kind.
Update 12.53

The word “Discover” is no longer a payment card, and an unchanged shop gets the same report

Four fixes: payment brands read from ordinary words, a terms page swapped for a platform default, a product-page gap counted against the shop, and a report that could change when the shop had not.

FixedPayment methods you show
When we found no payment logos, we searched your page’s text for brand names and took the first ordinary word that spelled one. “Discover our newest arrivals” became the Discover card; “ideal for your home”, the Swedish “visa” (show) and the German “sofort” (immediately) did the same on other shops. Across 332 stored homepages whose payment brands came only from text, 84 of 90 rested on one such word. A brand name that is also an everyday word now counts only beside a payment logo or another brand; on its own the line says we could not tell, and stays out of your score. Names that are nobody’s everyday word — “Betala med Klarna”, “per PayPal” — still count on their own.
FixedFinding your terms page
On some shops the scan found the terms page you link in your footer and then replaced it with the platform’s default terms address, so your terms facts were read from a document you do not link. Six of twenty-one recently checked shops ended up there this way. The page you link now stays the one we read; the default address is only tried when we found none.
FixedProduct pages
When the pages we opened did not prove to be single product pages, the line said so as a warning that counted against your score. That outcome is about how far our scan got, not about your shop, and on three of four shops where it happened the pages were real product pages our check refused. It is now marked as not checked and does not affect your score.
ChangedConsistent results
The part of the scan that reads your policies and marketing copy gives slightly different answers each time it reads the same words. If your pages have not changed since your last scan in the past week, we now reuse that reading instead of asking again, so an unchanged shop gets the same judgement twice and a daily scan does not report a change you did not make. Any change to the text we read means a fresh reading.
Update 12.52

Your front page is never read as your returns policy

When a returns or shipping link led back to a shop’s own front page, we read the front page as the policy. And returns rules printed inside a shop’s terms were read by a narrower rule than a returns page gets.

FixedFinding your policy pages
A shop whose site opens on a language address, such as /es/, could have its returns and shipping links lead straight back to that same front page. We then read the front page — product tiles and banners — as both policies, and told the merchant it stated no return window, no return address and no shipping area. The page your shop opens on is now never taken as one of your policies, whichever route led there. The scan keeps looking, and if it finds nothing it says it could not check rather than reading the wrong page.
FixedReturns rules inside your terms
When a shop has no separate returns page and prints its returns rules in its terms and conditions, the return window and the refund time were read there by a narrower rule than a returns page gets, and a sentence it missed became “no return window is stated”. A terms page saying returns may be requested “dentro de los treinta (30) días naturales” was reported as stating no window. Those two lines are now read by the same reader as a returns page. Where the terms state more than one period and we cannot tell which one is the window, the line says so and stays out of your score.
Update 12.51

Your returns lines are judged by Google’s rules, not by ours about the law

Three lines about returns and prices were grading shops against the European fourteen-day withdrawal right. That is law, not a Merchant Center rule, and it is gone from your report.

FixedThe “all sales final” line
A shop with no returns page and a blanket “no returns” statement elsewhere was failed outright if its site looked European, with the sentence “UK/EU distance-selling law gives consumers a mandatory 14-day withdrawal right”, and warned everywhere else. When the refusal was explained by made-to-order production, the line went the other way and told the merchant their clause was a lawful exception under a named article of an EU directive. We report against Google Merchant Center, whose requirements can be stricter than the law, and telling you a clause is lawful reassures you about the wrong standard. The line now reads the same for every shop and quotes what Google asks for: clear and conspicuous refund and return information on your website, reachable without logging in, stating how returns and refunds are handled. It is a warning, not a failure, because Google’s own misrepresentation policy is about refusing a return you promised — not about publishing a policy that offers none.
FixedThe return-window line
A window shorter than fourteen days got different words depending on whether your site looked European, and a window found by the AI reader was turned into a serious warning below the same fourteen days. Fourteen is the European and British withdrawal period. Google names no number for your website at all: it asks that the time frame be stated clearly, and its return-window page says a policy must meet the minimum for the country a product targets. Every stated window is now read back to you the same way, with one sentence: Google sets no single minimum, it depends on the countries you sell to and on the return settings in your Merchant Center account. Over one hundred and ninety-three stored returns pages, sixteen lines lose the old wording and none changes from a pass to a warning or back.
FixedThe VAT-in-the-price line
This line stays, and it still depends on the markets you sell to, because Google’s rule itself does: “Include value-added tax (VAT) where required. Many countries require a value-added tax (VAT), which must be included in your price.” What changed is what it says to you. It now quotes that rule and the one beside it — “the price of your product must be consistent throughout the checkout process” — and states plainly that we read your page and your cart, not your product data, so it is a signal to check rather than a confirmed mismatch.
Update 12.50

A euro sign on your page is not a European shop

Whether your returns policy is judged against UK and EU rules now rests on where you say you sell, not on which currency symbols appear somewhere on the page.

FixedWhich markets we judge your returns policy against
Two lines in your report are stricter for shops selling to UK and EU customers: a blanket “all sales final” clause, and a return window shorter than fourteen days. Whether that applied to you was decided by a list of twenty-nine European domain endings, a pound or euro sign anywhere on the page, an English sentence about data protection, a British postcode, or an English sentence about shipping to Europe. Over two hundred and forty-four stored shop captures that called one hundred and forty-two shops European sellers — seventy-six of them on a single signal, and forty-three of those seventy-six on a currency symbol alone, which is what a currency switcher puts on an American shop’s homepage. Four shops whose own market is the United States, two Australian and one each in New Zealand, Canada, Sri Lanka and Turkey were being judged against European rules on that basis. We now read what your site declares: a storefront you publish for a region, the shipping destinations in your structured data, the market your own address and contact details put you in, a shipping rate listed beside a country in your rates table, and — only ever as supporting evidence, never on its own — your currency and your domain ending. If you state where you ship and these markets are not in that list, the answer is that you do not sell there. If none of it is on your site, the answer is that we do not know, and not knowing never makes a finding harsher: that gap is ours, not yours.
Update 12.49

A return window written in hours is no longer a window you never wrote

When a check will not use a period of time you did state, it says so instead of reporting that you stated none.

FixedReturn window and refund processing time
These two lines read hours as a dispatch or delivery time, never as how long a shopper has. So a returns page whose only period is “claims must be made within 48 hours of receipt” was told it states no return window at all — about the very sentence that states it. Across three hundred and thirty-four stored shipping and returns pages, six lines on three shops said that. They now say plainly that the page states a period, that it is in hours, and that this check does not read hours for that line. Like every other line of that kind, it counts neither for nor against your score.
ChangedDelivery, dispatch and return times
The scan now records, for every period of time it finds on a page, why it would not use that period for each line: the wrong unit for that line, already used for a different line, or not a period at all. That last one matters more than it sounds — a shop’s Christmas cut-off, “Friday 19 December – 1pm”, was being read as thirteen hours. The weekday and month names come from the standard Unicode data, so it reads a French cut-off and a Czech one the same way. A line only withholds its “you state none” when the sole reason was our own unit rule; a dispatch time printed on a returns page, or a clock time, leaves the finding standing.
Update 12.48

The country in your footer address is the country we check you against

A shop that writes “Italia” under a street and a postcode is an Italian shop, in whatever language it writes it — and the phone line now tells you what we decided instead of going quiet.

FixedWorking out which country you sell from
Several checks — your phone number, your postal address, your tax or company number — can only be read against a country, because a number that is a real phone number in one country is a tax number in another. We work that country out from what your site declares: a regional web address, a country in your structured data, a tax number with its country prefix, a phone number written with its international code, a currency only one country uses, a country domain. A shop on a .com that declares none of those had no country at all, and those lines said so: “we could not tell which country you trade from”. Your footer address was sitting there the whole time. We now read it: a country name in any of the languages the international standard knows, printed inside an address with a postcode of that country’s own format beside a street and a town. Over two hundred and forty-four stored shop captures, six shops that had no country now have one, four more are now settled by their own address instead of their web address, and none disagrees with what we already knew. A country name on its own does not count — a shipping list or a country picker names a dozen countries and none of them is your address — and if your footer carries addresses in two countries, the line now names both and says the answer is uncertain rather than pretending we know.
FixedThe phone number line in your footer
This line had three answers and only two ways of saying them. It told you when it found a number, and it told you when it could not look. When it did look, knew your country, read the runs of digits in your footer and decided that none of them was a phone number, it said nothing at all — which on a report looks exactly like a check that never ran. It now says so plainly: your footer’s numbers were read against your country’s numbering plan and none of them is a phone number. That is not a fault. Google asks for one way to reach you, and a contact form, an email address or a social profile is as good as a number. On the same stored captures three lines that said “could not be checked” are now decided, one of them because a real phone number could finally be validated once the country was known, and no shop lost a number it already had.
Update 12.47

Your shipping rates are read off the page even when they are in a table, or in Czech

A rate table no longer talks the scan out of reading itself, and your own name for your shipping page is the word we look for.

FixedShipping cost
A shipping page that lists its rates in a TABLE has no full stops in it. The scan reads a sentence at a time to tell a delivery charge from return postage, and with no full stops that “sentence” was the whole page — so the word “returns” in the service links at the bottom cancelled every rate in the table above. One shop listed a price for fifty-eight countries and was told it stated none. The scan now stops at a sentence’s length and reads what sits beside the number instead. Nothing that was ruled out for a reason next to the number stops being ruled out.
FixedShipping cost
The words for “delivery” came from a list, and the list is English, German, French, Spanish, Italian, Dutch, Polish and the Nordic languages. A Czech shop whose page says “Doprava nad 2 500 Kč zdarma!” — free delivery over 2,500 crowns — was told it published no rates at all. We no longer need the word to be on a list, because you already wrote it: the address of your shipping page is your own name for it, in your own language. When we know a page is your shipping policy, a price next to your word for that page is a shipping price. On a page we are not sure about — your terms standing in, a homepage with nothing else to read — the old rule still applies, because there a price really can be about something else.
FixedShipping cost
Three capital letters beside a number were treated as a currency. The tail of a phone number written “… 94711222002 USA” and a Dutch VAT line reading “BTW 72947780” both looked like money. Only the three hundred real currency codes count now.
Update 12.46

Every check we could not finish now tells you why

A line in your report that says “could not be checked” says which of the dozen reasons it was, and a delivery time written in a language we cannot read is no longer reported as one you never published.

FixedWhat “could not be checked” means
Your report separates the checks we decided from the ones we could not, and the ones we could not have always been meant to say why: the page was refused, the page never answered, nothing on your site linked to it, we read it and it does not say, we do not read that language yet. Over seven hundred and eighty-nine stored reports, forty-six of those lines — about one in five — fell back to the bare sentence “this scan could not look”, because the check that produced the line never recorded what it knew. Eleven kinds of line were affected, among them the restocking-fee line, the cart-price comparison, the guest-checkout line and the malware lookup. Each of those checks now records the reason where the line is made, so the report shows it and the coverage summary counts it. None of these lines counts for or against your score, before or after.
FixedDelivery, dispatch and return times
Four lines — your return window, your refund processing time, your dispatch time and your delivery estimate — find a period of time by matching a number against a word for “days”. When they found nothing they said your page states none, whatever language the page was written in, and a missing delivery estimate is reported as a serious problem. Across three hundred and seventy-three stored shipping and returns pages, three of those lines sat on pages that do state the period, written in a language the word list has no word for. That claim is now only made where we could have read a period — either your page already showed us one, or its language is one we have the words for. Everywhere else the line says plainly that the gap is ours. The languages each check can read are listed on our languages page, worked out from the scanner itself.
Update 12.45

Your product pages and your shipping rates are found the way a shopper finds them

A web address no longer decides what is a product page, a delivery estimate is read in your own language, and a rate written “30 $” is a rate.

FixedFinding your product pages
The scan used to recognise a product page by the shape of its web address, from a list of the shapes twenty-odd shop systems happen to use. Across eighty-one stored sitemaps that list matched nothing at all on twenty shops — a quarter of them — and on those the scan never opened a single one of the twenty-two thousand pages they listed. Now the address only decides what order pages are opened in: what your page shows leads instead, and it is the same signal in every language — a link wrapping a picture, a price beside it, a row of tiles that all look alike. Every candidate is still opened and checked before anything is graded from it. On one shop whose front end is built by a script this went from no product page at all to three, in about a second more.
FixedDelivery and return times
The words for a day, a week and an hour used to come from a list grown one shop at a time, and the word for a week was English only — “semaines”, “weken”, “Wochen”, “týdnů” did not exist for it, nor did Vietnamese, Arabic, Croatian, Greek or Norwegian days and hours. Those words are now generated for every language from the standard Unicode data, and a heading shouted in capitals (“FREE 30 DAYS RETURNS”) is read like any other. A range also keeps both ends: “6-8 weeks” used to be published as roughly fifty-six days, with the shorter end and the word “weeks” thrown away. Over two hundred and thirty-nine stored scans, twenty claims came back that had been missed and none was lost.
FixedShipping cost
A rate table reading “Argentina 7 30 $” was reported as “no shipping cost information found” while another line of the same report quoted that very table. Every way the scan knew to spot money wanted the symbol in front of the number. It now reads an amount however you write it — “30 $”, “1.000,00 EUR”, “9.995,00 kr.”, “£12.50”, “USD 30” — and checks it really is money before saying so.
ChangedWhat language your pages are in
Four parts of the scan each decided this their own way and they disagreed. There is one answer now: what your page declares, then what your shop declares, and the words themselves overrule a declaration only when two independent readers agree it is wrong — so a theme left on English over Dutch copy is read as Dutch, while an Italian contact page with English form labels stays Italian. Across one thousand two hundred and forty-two stored pages, six changed and every one was an improvement.
FixedFinding your policy pages
The footer we followed was the one in the file your server sends. On shops whose footer is put together by a script there is nothing there to follow, and real, linked policy pages were reported as not linked from your storefront. We now read the footer the browser builds as well. On one such shop that is fourteen links before and forty after, and it costs nothing — the page was already open.
Update 12.44

The basket check now watches what your shop does, instead of reading your buttons

We find the buy button by what the form is for, we check the add really happened, and we compare three prices in one currency — or say plainly that we could not.

ChangedFinding the buy button
The scan used to look for thirty-eight things a buy button might be called — class names, ids, and eight English phrases, each one added after a shop broke on it. It now asks what the form is FOR: does it carry how many you want, does it carry which product, is there one thing to press, does it sit beside the price. That reads the same on a Hungarian, Greek or Czech storefront, and on eight live shops it found a buy button on one that every name in the old list missed. The old list still runs behind it.
AddedProving the item went in
Pressing a button is not adding to a basket. The scan now watches for what a shop actually does: a request to its own basket route, a basket cookie it did not have before, a basket count going up, its own basket answering with something in it, or its own analytics reporting the add. If none of that happens we say the press was not seen to do anything — which is a different sentence from "your button is broken", and we no longer grade the rest of the journey against a basket that stayed empty.
ChangedReaching the checkout
This used to be satisfied by the word "cart" or "checkout" in a web address, or by the word "total" anywhere on a page. A product page with a basket icon in its header qualified. So did a page-not-found with a footer. A checkout is now the one page that asks you for something no other page does — a payment window, a card field, a delivery address, a country list, or a form wanting four or more of your details. On eight live shops three that used to count as "checkout reached" were reached on a web address alone, and the report now says so instead.
AddedThree prices, one currency
The price check used to read two numbers and compare two currency SYMBOLS. A dollar sign is eleven currencies and "kr" is four, so shops with matching prices were told we could not be sure. It now reads three: the price in your product data, the price a shopper sees (read by your own language’s number rules, so a comma is a decimal point where it should be), and what your own basket says it holds. The currency comes from your product data, then your basket, then your market — never from a guess at a symbol. We only call a difference a difference when all three were read in one currency, and the basket figure is what the items cost, not the order total with delivery on it.
FixedWhen we could not look
If the journey stopped at the basket, the report still said "no returns, privacy or terms links found in the checkout" and "no tax shown before payment" — about a page we had never opened. And a shop whose bot protection answered instead of the product page was told to fix a button nobody had laid eyes on. Both now say what happened, and neither counts against your score.
Update 12.43

A colour called Rum is no longer a bottle of rum

A restricted or prohibited category is only reported when something outside the product name and its options says the shop sells it.

FixedRestricted and prohibited products
The check used to fire on a word. A sandal offered in the leather colourway “Rum” was told it sells alcohol; so was a Danish lamp, because “rum” is Danish for room; a cashmere jumper was told it sells tobacco because another jumper on the page comes in “Dark Tobacco”. The word is now only where we start looking. Before anything is reported, the category has to be named somewhere the product name cannot reach: the page’s own declared category, the breadcrumb trail above the product, the shop’s menus and category links, the catalogue the shop’s platform publishes, or an age check at the door. Across two hundred and thirty-nine stored scans, thirty-one of forty flagged pages were words in a name or a colour swatch.
ChangedRestricted and prohibited products
When the word is there and nothing backs it up, the row does not disappear — it says we saw the word, checked your categories, menus and catalogue, and found nothing that says you sell it. That row counts neither for nor against your score. If we had nothing to check the word against at all, the row says that instead, because “we could not look” is not the same answer as “we looked and found nothing”. Shops that do sell alcohol, tobacco or supplements keep the warning, off their own categories.
Update 12.42

The report now says what it could not check, and why

Every check that could not be decided is named, with the reason, and none of them count for or against your score.

AddedWhat we could not check
A scan used to fold every undecided check into one quiet number. It now says, check by check, which of fourteen things happened: the page was not found, the page was found but does not state the fact, the wording was unclear, the store blocked us, the checkout could not be reached, your site does not say which country it serves, we do not read that language yet, and so on. The summary line counts them by reason. None of it counts for or against you — a check we could not run is not a check you failed.
AddedCoverage by area
The result now carries, for each area of the check list, how many checks were decided and how many were not, and why. Over nineteen recent scans that showed one thing the old headline hid: restocking-fee disclosure was decided on one shop in seventeen, and a single failed checkout journey takes twenty-four checks with it.
Update 12.41

Countdowns, stock counts and “someone just bought this” are judged by watching, not by reading

The scan now visits your page twice — the second time as a brand-new visitor — and compares. That works in every language, and it stops accusing shops of things a word list only guessed at.

ChangedPressure tactics
A real deadline is the same moment for every visitor. A stock count does not move when nothing is bought. A pop-up that plays the same names in the same order to two fresh browsers is a recording. Those are the tests now. A countdown, stock claim or activity pop-up is only marked as false when the second visit proves it; otherwise the report says it is there and could not be disproved. Three shops that had been accused of a fake countdown were not: one was a video player’s clock, two were the dates of a promotion.
ChangedLanguages
Because these checks no longer read words, they no longer depend on your language. The languages page now lists two word-list checks instead of eight, and a Czech, Italian or Dutch shop gets the same countdown and stock checks as an English one.
FixedWhich page is a product page
A page was treated as a product page if it showed a price. Terms pages, returns pages and home pages all show prices, and forty-two such pages on twenty-one shops had been graded as products. A page is now a product page only if it says so — in its structured data, its social-sharing tags, or its platform’s own markup — or if it carries a real buy control beside a price. A category listing is never one.
Update 12.40

Phone numbers, addresses and tax numbers are read the way a phone company reads them

We stopped guessing that a run of digits near the right word is a phone number. Every number is now checked against the real numbering plan for your country, and a VAT number can no longer be published as your phone.

FixedYour phone number
Two shops were told their tax number was their phone number. A number is now only published as a phone if it is a valid, dialable number for the country your site is for — checked against the same numbering data phone networks use — and if it was found where phone numbers live: a call link, your business markup, or the footer and contact text. Digits inside a web address, a script, or a date are never read at all. If your site does not say which country it serves, the report says it could not check rather than guessing.
ChangedAddress and tax number
A postal address is read from your business markup first, then by finding a real postcode for your country beside a street and a town. A VAT or company number is recognised by its own check digits, so it is reported as what it is. None of this depends on the language of the labels around it.
Update 12.39

A number is not a fact until its sentence has been read

Delivery and handling times are no longer taken from any sentence that happens to contain a number of days. The sentence is read, in your language, and has to be about delivery.

FixedDelivery and handling times
One shop was told its delivery time was thirty days. The sentence said customers may pause deliveries for up to thirty days while on holiday. Another had its dispatch time read from a line about how long delivery takes. When a policy page states several periods, we now read every one, with what it is about — delivery, dispatch, a return window, a refund, a holiday hold, a reference price — three times independently, and keep only what agrees and quotes the page word for word. A number whose sentence is not about the check in question is not published as that check’s answer.
ChangedWhen we could not tell
The report now says which of three things happened: we could not find the page; we found it and it does not state the fact; or we found it and the wording was unclear. Only the middle one counts against a shop. Each is counted separately, so a scan cannot look better by looking at less.
Update 12.38

A recommendation from Google can no longer fail your shop

Every check now records which kind of Google page it rests on. Where Google only recommends something, the report says so and does not mark you down for it.

ChangedHow findings are graded
Google publishes three kinds of page: policies it enforces, requirements it states as “must”, and a checklist of things it recommends to pass review. We used to grade some recommendations as failures — a missing favicon or meta description, a page title, no social links. Those are now shown as advice, marked as such, and never count against your score. Checks that rest on a policy or a stated requirement are unchanged.
FixedPolicy links and placeholder text
Six checks — policy links missing from the footer, a policy link that leads to a dead page, and placeholder text left on a page — had been recorded against the checklist only. Google’s requirement pages cover each of them: the returns policy must be reachable from a footer button on every page, links must not lead to errors, and pages must carry no template text. They keep their weight.
Update 12.37

The languages page now says what each check can read

Our languages page claimed 36 of 37 languages were fully covered. That number came from one check. It is corrected.

ChangedLanguage coverage
The old figure counted one thing: whether we could find and read a privacy policy in that language. Several of our word-list checks — the ones that look for pressure tactics like live viewer counts, sales counters and “only a few left” wording — read far fewer languages, and some read English alone. The page now shows every word-list check with the languages it reads, and a language is called fully covered only when all of them read it. By that honest rule it is one language today. Where a check cannot read your language the report says it could not look, and your store is neither passed nor failed on it. The policy checks that read the page with the model are not word-list checks and work in any language; they are listed separately.
Update 12.36

Reading the page your customer reads

Six ways a scan could look at the wrong thing on your site and report what it found there as a fact about your shop.

FixedShipping and returns pages
Some shops build their policy pages in the browser, so what arrives first is a shell — the headings, none of the content. We judged the shell. One shop with a table of delivery times and prices covering dozens of countries was told it stated no shipping cost anywhere, not even “calculated at checkout”, and that a second reading of the full page had confirmed it. The second reading had been given the same shell. We now compare the two and read whichever page actually carries your policy.
FixedFinding your policy pages
We used to take the first link on your homepage that mentioned a policy. On a shop whose product tiles each carry a “free shipping” badge, that made a hoodie listing the shipping policy, and every delivery fact came off it. Links are now scored rather than taken in order, and a link whose address names the policy beats one that only mentions it — which also stopped a “your benefits” page standing in for a returns policy, and a data-protection contact page standing in for a privacy policy.
FixedNews stories mistaken for policies
One shop’s only returns-related link on its homepage was a news story about a sailing race, because the headline happened to contain the word “returns”. We read that story as their returns policy and every returns fact came from it. Their real refund policy was sitting at the usual address and we never looked, because the slot was taken. A page that tells search engines it is an article is no longer treated as a policy page, and we go and find the real one.
FixedYour phone number
Two shops were told their company registration number was their phone number, and both passed our plausibility check as valid. A number published for shoppers is written to be dialled — it has a country code, or spaces, dashes or slashes between the groups. An unbroken run of digits is an identifier, not a number anyone can ring. If something on the page calls it a phone, we still take it however it is written.
FixedDates mistaken for phone numbers
A shop that stamps its customer reviews with the date the way much of central and northern Europe writes it — with a space after each dot — had one of those dates read as its phone number. The same date written with slashes was already ignored correctly. It is ignored now in either form.
FixedWeb addresses mistaken for phone numbers
Where a shop’s styling leaves an image address in the page text, the digits in that address could be read as a phone number. Addresses are now set aside before we look for a number. Click-to-call links still work as before.
Update 12.35

The number of days you actually give people

Six shops were told the wrong return window. Every one was a real period from their own page — just not the right one.

FixedReturn window
A returns page states several periods: how long you have to change your mind, how long you then have to post the parcel back, how long a refund takes, and the separate remedy if goods arrive faulty. We read whichever one we found first. One shop that gives 14 days was told 30 — taken from their faulty-goods clause; another that gives 30 was told 5, which was their refund processing time. We now report no window at all rather than the wrong one when a page states several, and a remedy for faulty goods is never read as your ordinary return window.
FixedReturn windows written in Nordic languages
A shop saying “öppet köp i en månad” gives customers a month to change their mind. We reported that it stated no return window at all, because the words for days, weeks and months in Swedish, Danish, Norwegian and Finnish were missing from what we could read. They are in now, including the possessive forms Danish uses.
FixedPrices written with a currency word
Much of Europe writes its prices as “9.995,00 kr.” rather than with a symbol. We could not read those as prices at all, so we fell back on a reading that turned nine thousand into nine — and told one shop its own page contradicted its own product data. Those prices are read properly now, and where a currency is one we have never seen, the page’s own way of writing the number is still considered before any mismatch is reported.
Update 12.34

Four things we were telling shops that were not true

An independent review of a fresh test run read every claim back against the evidence. It found four ways a scan could tell a shop something untrue about itself. All four are fixed.

FixedProduct prices
A product page usually shows more than one price — the product’s own, and whatever sits in a “pairs well with” strip beside it. We sometimes read the neighbour’s price, compared it against your structured data and reported a mismatch that did not exist. One shop was told its page showed $42 against structured data of $114 when the page said $114 twice. Every price on the page now counts, and a price that agrees with your data is no longer a contradiction.
FixedStock availability
We sample product pages to judge how much of a catalogue is buyable. The sample was taken from one place in the list, so on a shop with a large sale section every sampled page came from clearance — where items are routinely sold out. A working retailer was told its catalogue was overwhelmingly unavailable while the products we actually opened were in stock. The sample now spreads across the catalogue, and when the sold-out pages all sit in one section we name the section instead of judging the whole shop.
FixedContact details
A contact page reading “Phone (Closed 12.00 - 13.30)” had its lunch closure published as the shop’s phone number, with the real number nine lines below. Opening hours are never read as a phone number now, in any language.
FixedDelivery terms
Shops with no separate delivery page — common in Europe, where delivery terms sit inside the terms and conditions — were told they state no delivery countries, no costs and no delivery times, even where their terms stated all three. Those documents are now read for delivery facts as well, in whatever language they are written in, and the report says which page the answer came from.
Update 12.33

Scan the same shop twice, read the same report

The part of the scan that judges your policies asked the model once. Models answer a little differently each time, so two scans of a shop that had not changed could name the same problem in different words, or list one the other missed.

ChangedPolicy judgment
Your pages are now read several times over, at the same time, and only what more than one reading found is reported. A problem that appears in one reading and never again was the model’s wording, not your shop; a problem two readings arrived at separately is worth your time. Scans take no longer, because the readings run together.
FixedRepeated rows
When a reading described the same clause twice, it appeared twice under the same heading. Those are now one row, and rows come out in the same order every scan.
Update 12.32

A price written the way your country writes it

We read a price of 34.800 as thirty-four point eight, then told the shop its own page disagreed with its own structured data.

FixedPrices grouped with a dot
Much of the world writes thirty-four thousand eight hundred as "34.800". We read that as 34.8, compared it to the 34800 in the page’s structured data, and reported a mismatch that did not exist. One shop was told its schema contradicted its own page when the two agreed perfectly — and the same thing would have happened to any store in Chile, Brazil, Germany, Spain, Italy, the Netherlands, Indonesia, Turkey, Argentina or Colombia with a price above 999. Prices are now read without assuming a country. Where a number could honestly be read two ways, we take the reading that agrees with the shop’s own data instead of accusing it; a price that disagrees under every reading is still reported.
FixedA cart comparison that explained a difference that was not there
The same misreading reached the cart check, which found 34800 in the basket and 34.8 on the page and explained the gap as a variant selection. There was no gap and no variant. The cart and the page are now read the same way, so that line says what actually happened.
Update 12.31

Judging a product page that was not one

When we could not find a real product page, we graded six product checks against whatever page we had reached anyway.

FixedProduct checks now say when they had nothing to judge
Our scanner already asks whether the page it found is really a product page — it has to, before deciding whether to look harder. When the answer was no and a deeper crawl turned up nothing better, it kept that page and graded it anyway. One store’s brand listing, a page reading "871 results sorted by Popularity", was marked as having no product structured data, as showing scarcity wording, and as having an undersized product image — that image being the page’s hero banner. Two other checks passed it. Those six checks are now published as not checked, with a line saying no product page could be identified, and they no longer count for or against your score.
FixedEuropean companies
A copyright line ending in GmbH or Ltd counted as showing who runs the shop. The same footer ending in SE — Societas Europaea, the EU-wide company form used by plenty of large retailers — did not, and those shops were told they showed no clear business identity. Now it counts, like every other legal form we already knew.
Update 12.30

A report that argued with itself

One row said your shipping page was found. Another row, in the same report, said it was missing.

FixedWhere we say a fact came from
When a delivery or dispatch time is not on your shipping page, we look on your terms page and say so. The sentence explaining why always read "the dedicated shipping page is missing" — even when we had found your shipping page and listed its address higher up the same report. It fires for two different reasons: there is no shipping page, or there is one and it does not mention that fact. Now it says which. If you have no shipping page the wording is unchanged.
Update 12.29

Two clocks read as the wrong clock

One turned how fast a shop pays you into how long you have to send goods back. The other built a delivery promise out of a number the shop said was not part of it.

FixedYour refund speed is not your return window
"Refunds are processed within 10 business days of receipt" was read correctly. "Returns are processed within 10 business days of receipt" — the same sentence, one word different — was read as your return window, so a shop that gives customers 30 days to send things back could be recorded as giving 10. We now read the verb rather than the noun. Three shops on file had a refund promise filed under the wrong heading; none lost a return window in the correction.
FixedA "contact us if it has not arrived" clock is not a delivery time
One shop writes "if you did not receive a shipping confirmation after 2 working days, reach out via live chat". We reported that as a 2-day delivery time — the same 2 days it had already, correctly, reported as the shop’s dispatch time, so one number was doing duty as both. We already ignored "if you have not received it after N days"; we just did not recognise the wording shops actually use. Fixed in English and in French, Spanish, Italian and Portuguese, which split the same way. "You will receive your order within 3-5 working days" is untouched — that is a promise, not a fallback.
FixedA number you rule out is not a promise
One shop writes that its delivery times "don’t include the 1-2 days it takes to pick and ship the order". We took the only number in that sentence and reported it as the delivery time — the very thing the sentence says it is not. A duration a sentence rules out no longer counts as what it was ruled out of. "Delivery takes 3-5 days, not including weekends" is untouched: that rules out Saturdays, not the three to five days.
Update 12.28

Four checks that read the page wrong

Two told you a fact was missing while it sat on the page we had just read. Two passed you on something that was never there.

FixedYour dispatch time, not your opening days
If your shipping page said "we ship Monday to Friday" before it said how fast you dispatch, we quoted the opening days and stopped reading. One shop was told its handling time was "ship from sunny Chico, CA on Monday" — with "process and ship within 72 hours" in the very next sentence. We now quote the sentence that actually names a time. If your page only gives the days you ship, that still counts, as it did before.
FixedThe refund clock, when you call it a return
"Refund" and "return" are the same thing to a shopper, and shops use either word. We only understood the first. A page saying "returns take approximately 7-10 business days to process" was told it stated no refund timeline at all. We now follow the verb rather than the noun — so a clock for processing counts however you word it, while your deadline for sending goods back stays what it is, a deadline.
FixedThe payment icons you actually show
Most shops name each payment logo inside the image itself rather than in a label beside it, and we were only reading the label. So a footer showing Visa, Mastercard, PayPal, Apple Pay, Klarna and six more could be told it showed no payment brands at all. Of the shops we hold on file that display these icons, roughly four in five were invisible to us this way. They are not any more.
FixedA word is not a logo
The opposite mistake, and the one that flattered you. We searched your page for brand names without checking they were whole words, so "keepsake" counted as an EPS logo, "promo code" as cash on delivery, and a French shop selling face cream passed on the word "visage". About a quarter of the shops we hold on file contain a brand name buried inside an ordinary word. Those passes were not real, and some shops will now see this check as a warning instead — correctly, because the icons were never on the page.
Update 12.27

Told you had no sitemap, when you had one

A shop whose sitemap sits at the address WordPress and Yoast generate could be told it had none at all.

FixedWhere we look for your sitemap
We looked at whatever your robots.txt named, then at /sitemap.xml, then at the WordPress path. Plenty of shops keep theirs at /sitemap_index.xml and never mention it in robots.txt — and those shops were told "No valid XML sitemap found" about a file listing three thousand pages. We now look there too. If your sitemap was already being found, nothing changes for you.
Update 12.26

Social profiles: naming them, instead of assuming them

Two ways this check was wrong in opposite directions — shops with no profile at all were told they had them, and shops with real profiles were told they had none.

FixedA tracking script is not a profile
The check passed if the page mentioned a social network anywhere in its code. A Facebook pixel or a TikTok analytics tag is exactly that, so shops linking no profile at all were told “links to social profiles found” — with nothing listed underneath, because there was nothing to list. The check now has to name the profile it found, or it does not pass.
FixedProfiles a script builds into the footer
The opposite failure, and the more expensive one: if your footer is built by script, your profile links were invisible to us and you were marked down for links you publish. The check now reads the page as a browser renders it, so those count.
FixedA post is not a profile
Where a shop links recent Instagram posts above its own profiles, the posts were being listed as the evidence. The report now lists the profiles.
Update 12.25

The report belongs to whoever paid for it

The second half of the security review. One change to who a bought report belongs to; the rest of it you would never see.

FixedWho owns a report after it is bought
A results link opens for anyone you send it to, and anyone who opens it can ask us to keep that report — which is how you get your own results back after closing the tab. If someone did that in the gap between you starting your payment and it going through, the report stayed theirs afterwards, and your own browser was told the report was not yours. With a card that gap is seconds; with a bank transfer it can be days. Paying now takes ownership, every time, whoever held the link first.
Update 12.24

A report is unlocked when the money arrives, not before

A full security review of the whole application. Most of what it found is invisible to you and has been fixed; two things change what you would actually experience.

FixedPaying by a method that settles later
Card payments clear immediately, but direct debit, bank transfer and several local methods tell us “checkout finished” days before the money moves — and sometimes it never does. We were handing over the report at that first message. Now we wait until the payment has actually settled, and the report unlocks by itself the moment it does. If you paid by card, nothing about this changes for you.
FixedWhat the scanner is allowed to open
A shop being scanned controls where its own links and redirects point. A shop could send the scanner to an address on our own machines instead of its storefront, and what came back was read as if it were part of the shop. Every fetch and every browser page now re-checks the destination at each redirect, so the only thing a scan can read is the shop.
ChangedHousekeeping you would not see
Stricter limits on password-reset, sign-in-link and session-refresh requests; internal error text no longer appears in a scan result; a shop name can no longer put markup into an email we send; and the image and PDF readers that handle a shop’s own files were moved to newer versions.
Update 12.23

The report you paid for is yours to keep

A paid report opened at one address and nowhere else. There was no way to save it, so closing the tab lost it — and the offer to keep a report only ever appeared on the free result screens.

FixedKeeping a paid report
The paid report now carries the same offer the free screens have always had, worded for someone who has paid. Before this, a buyer without an account had the report in one tab and no way back to it at all.
AddedAn account, not just an emailed link
Saving a report used to mean giving an email address and waiting for a link. You can now set a password instead: the account is created, you are signed in, and the report is on your dashboard in the same step. The emailed link is still there for anyone who prefers it.
FixedA link that went nowhere
The paid report offered “Dashboard” as the way back even to a buyer who had no account, which led to a sign-in screen they could not pass. It is no longer shown to someone who has not got one.
Update 12.22

The refund clock, when the shop writes the day as a single letter

A Lithuanian shop promises the money back “per 14 d.” — within 14 days. The scan reported no refund timeline at all, because “d.” was not a day to it and the sentence about returning money read as a sentence about returning goods.

FixedA day written as an abbreviation
Plenty of shops shorten the word for day to a letter and a dot — “14 d.”, “2 d. d.” for working days. Every length of time written that way was invisible, so the page could state a clear promise and the report would still say nothing was found. Company names that end in the same letters, the Croatian and Slovenian d.o.o. and d.d., are still read as company names and not as times.
FixedMoney back versus goods back
In several languages one verb covers both returning an item and returning the money, so a single clock on a returns page has to be assigned to one of them. Where the sentence says money, the clock is now read as the refund clock — not as the window you have to send the item back. A shop that states both now gets both rows right instead of one right and one missing.
Update 12.21

Working days, in the languages that write them differently

A Lithuanian shop states dispatch in “1-2 darbo dienas” and delivery in “2-5 darbo dienas”. Neither was a length of time to this scan, because the word for “working” sits between the number and the day.

FixedHow long things take, in six more languages
English and German write the working part inside one word — business days, Werktagen. Lithuanian, Latvian, Czech, Slovak, Croatian and Slovenian put it between the number and the day, and every such time was invisible: not a wrong reading, no reading at all. Two day forms were missing as well, the Slovak plural and the Slovenian one. Across every shipping and returns page we hold, three shops gain a delivery time they had always stated and none loses one.
FixedLithuanian dispatch, delivery and returns
With the numbers visible, the words around them now decide what each one means. That shop’s page reads dispatch as one to two working days, delivery as two to five, and the fourteen days in its banner as the return guarantee it is rather than a delivery promise.
Update 12.20

A heading is not a policy page

One shop was told its shipping page states no cost, no dispatch time, no delivery time and no delivery area. The page we read is fourteen characters long: “SHIPPING POLICY”. Four claims about a shop, all from a heading.

FixedPages that answer but hold nothing
A page that loads and carries no readable content is now reported as something this scan could not check, not as a shop that states nothing. Across every policy page we hold, forty captures are below the line, and each one is impossible as a document: an empty page, a bare heading, the same heading twice, a cart subtotal, the field labels of a contact form. The line sits below the shortest thing a policy could be — “All sales are final. No returns are accepted.” is a complete policy — so a one-sentence policy is never thrown away, and a policy that lives inside an embedded viewer is still read in full.
FixedTwo checks that used to go silent
When a shipping page could not be read, the report said so for the dispatch time, the delivery time and the delivery area, and said nothing at all about the cost or duties. A missing line reads like a clean one. All five now say plainly that they could not be checked, and none of them costs you points.
Update 12.19

Your address and your company number, written the way your country writes them

A Romanian shop publishing "Str. Republici nr. 4" and "CUI: 16924224" in its footer was told it showed neither an address nor a tax number. Both are read now, and so are the Danish and Croatian company numbers.

FixedAddresses that start with the street word
Two address shapes were understood: the English one, number first, and the German or Dutch one, where the street type is fused to the name and the number follows. The third — street word, name, number — is how Romanian, Polish, Spanish, Italian, Portuguese, Hungarian, Turkish and Malay write an address, and it was read as no address at all. Checked against every stored page: one more shop gains its address and none loses one. A street named without a house number is still a place, not an address.
FixedCompany and tax numbers
Romania’s CUI, Denmark’s CVR and Croatia’s OIB are now recognised alongside VAT, KvK, adószám and the rest. Four shops in our own test set were publishing a company number and being told they published none. A percentage after those letters is still not a company number.
Update 12.18

Keep a report without buying one, and Romanian read properly

A scan you run without an account lived at one address and nowhere else — close the tab and it was gone. You can now save it with an email address, and we send you a link that opens it.

AddedKeeping a report
Every result page now offers to keep the report. Give an email address and we save it to an account for you and email a link that opens it and signs you in. The page you are on keeps working straight away. Nothing is sent to an address that already has an account beyond that same link, so this cannot be used to reach someone else’s reports.
FixedRomanian delivery and dispatch times
A Romanian shop stating "Expedierea comenzii ... in termen de 24 ore" and "Comanda ar trebui sa ajunga la dumneavoastra in termen de maxim 2 zile lucratoare" was told it stated values the scanner could not identify. Both are read now. Romanian also writes "de" between a number and its unit above nineteen — "30 de zile", "24 de ore" — which no reading of a duration allowed, so every Romanian shop’s thirty-day return window was invisible.
FixedRomanian shipping and return costs
A shop can say what shipping costs without putting a number beside the word: "Taxa de transport este variabila in functie de volum", "Valoarea totala a transportului va fi afisata in cos". Those now count, and so does who pays to send something back — "costul transportului TUR-RETUR va fi suportat de catre client", or the opposite, "suportat de vanzator".
Update 12.17

Paying opens the report, and the wait looks like work

After paying, the page could not open the report it had just sold you: the purchase moved the report into an account and the tab you paid in was refused. It opens immediately now, and the email opens it too.

FixedOpening the report you paid for
Paying saves the report to an account for the email address you paid with, and that had the side effect of locking the browser you paid in out of it. The payment confirmation now hands that tab a pass for that one report, so it opens straight away. The pass is read-only, covers nothing else, and lasts a day; the account and the emailed sign-in link are the way back after that.
ChangedWhere your report is kept
The screen after payment now says which inbox has the receipt and the sign-in link, and that the report is saved to an account for that address. That was already true and never said. The emailed link now opens the report itself rather than the dashboard.
FixedA box drawn around your store name
Moving to a new page puts the cursor on that page’s heading, so a keyboard or screen reader starts at the top of the new content. The browser was drawing its keyboard outline around that heading as well, which on the scanning screen looked like an input field around your store’s address. The outline now appears only when you actually moved there with the keyboard.
ChangedWhile a scan runs
A single pass can run for minutes with nothing new to report, and the screen looked frozen. A light now travels across the work already done, the pass being read is marked with a band that moves down the list as the work does, and everything stops when the worker stops. Nothing on the screen claims progress that has not happened.
Update 12.16

A shop whose own code broke the scan, and a terms page read as missing

One shop produced no report at all: score zero, no rows, and a message saying we could not fetch a site we had already fetched. Another was failed for having no Terms of Service page while linking one in its footer.

FixedA scan that stops early
A scan that ends unexpectedly now publishes every check that had already run, with a line saying it stopped early. That line is marked as something we could not check, so it costs no points. Before this, one unexpected value discarded a full page of completed checks and reported that we could not reach the store.
FixedWhen a shop’s own scripts change how the page behaves
Some older shops load libraries that redefine parts of JavaScript the scanner uses to read a page. On one shop this returned the payment brands, the contact email and the contact phone as empty values, and then stopped the scan outright. The reading no longer depends on anything a page can redefine, and the report no longer assumes it got back what it asked for.
FixedPolicy pages named in your own language
A Greek shop linking “Όροι Χρήσης” was told it had no Terms of Service page at all. The word lists behind returns, shipping and terms were checked against a real link label in seventeen languages: terms was missing in twelve of them, returns in nine, shipping in six. All three now cover them. Delivery-terms links stay with shipping rather than being read as Terms of Service.
FixedA phone number on one line, an address on the next
A Hungarian shop printing its phone number above its address had the two read as one number. It was told its own valid number looks invalid, told its markup and its footer name different numbers when they name the same one, and told it publishes no address at all. A phone number now ends where its line ends.
Update 12.15

Paying for a report now opens the report

After paying, the page sent you back to the homepage while it waited for the payment to register — the page that asks you to run a scan, with nothing on it saying your payment had gone through. Coming back from payment is now a page of its own.

FixedAfter you pay
The return from checkout lands on a page that says the payment arrived and names the store it is for, and it opens the full report as soon as the payment confirms. If the confirmation is slow, the page says so, points at the receipt already in your email, and offers to open the report again rather than leaving you on the homepage or on a locked result.
FixedA refused request to Google’s crawler
A shop whose firewall answered a Googlebot request with a bot-verification page was failed for blocking Google. This scan sends Google’s name from an address that is not Google’s, and Google’s own crawler is recognised by its address, so a firewall showing that page may be waving the real crawler straight through. The report now records it as something this scan could not settle, and it costs no points. To see what Google actually receives, use the URL Inspection tool in Search Console.
FixedYour tax number is not your phone number
A VAT line written as one block — NL001819080B13 — was published as a shop’s phone number, and the number check then called it valid. Digits with a letter stuck to them on either side are part of a code, not a number anyone can dial, and that now holds wherever a number is read: beside a label, under an address, or alone on a line. An order code sitting below your address is no longer a phone number either.
FixedDispatch and delivery in Dutch and Portuguese
A Brazilian shop saying the posting deadline is up to seven days after payment had that published as a delivery estimate, while its own page says delivery depends on the method chosen. Posting, dispatch and expedition are now read as dispatch times in Portuguese, and a Dutch order being “onderweg” is read the same way, with “levertijd” read as a delivery time.
FixedA long answer that stops mid-sentence
When the policy reading is cut off at its length limit, the findings it had already finished are kept instead of the whole reading being discarded. One shop produced eight thousand words of analysis and the report showed none of it.
Update 12.14

A footer named in your language, and a keyword that is a word

A Brazilian shop with no footer element and a footer block named “rodape” had its returns policy graded on a product page, a breeding box, because the Turkish word for return sat inside the product’s name.

FixedFinding your policy links
When a page has no footer element, the scanner looks for a block whose class or id says “footer”. Many platforms name it in their own language — rodapé, pie de página, Fußzeile, voettekst, stopka, sidfot, bunntekst — and with nothing recognised every link on the page competed for the policy slots. Those words are now known to both readers, the one that reads the page as served and the one that reads it rendered.
FixedReturn policy keyword
The Turkish returns keyword “iade” matched inside the Portuguese “criadeira” by substring, so a product became the returns page. It is now a word with a boundary before it; Turkish suffixes still count. “Política de trocas”, where a Brazilian shop keeps its returns terms, is a returns link too. The shop’s “os valores de frete podem variar” and “o frete é calculado por pedido” now count as shipping-cost statements.
Update 12.13

One wait for the policy analysis, not two

Two scans today took 406 and 564 seconds. A timed run put 417 of one scan’s 545 seconds in a single step: the model’s read of the policy pages, which was asked once with too small an answer budget, then asked again with a bigger one, with a timed-out attempt repeated on top — and still returned nothing.

FixedScan time
The model that reads your policies thinks before it answers, and its thinking counts against the answer budget. At the old budget the first call routinely ran out before the answer, and a second, longer call followed. The read is now one call with the budget it can actually use; the answer is the same, and one wait is shorter than two. A call the scan had already agreed to wait ninety seconds or more for is not repeated from scratch when it times out — that repeat had been doubling the wait with little chance of a different outcome. The same store scanned again in 259 seconds with the model’s findings present, against 491 and 545 seconds with none.
NoteWhat remains
The model’s read still takes two to three minutes on stores with long policies, because the model reasons at length; every other step is done by then. A shallower reasoning setting would make the read far faster at some cost in what it notices. That trade-off is a decision, not a bug, and it is listed for the owner.
Update 12.12

The places a shop names, and who pays in more of its words

Re-reading every report row that only the model layer had found, the delivery-area rows named places the scanner’s country list did not know, and the return-shipping rows said who pays in words its shape lacked.

FixedDelivery area
“Exclusively within India”, “anywhere in Texas … within the 50 United States”, “within Pakistan”, “free within Australia”, “Delivery in Sri Lanka”, “na području cijele Hrvatske”, “po celé České republice” were misses: the list held eighteen countries. Sized on the stored shipping pages (which capitalised names follow “to”, “within”, “nach” or “en” beside a shipping word), it now carries the world’s shipping destinations in English and native forms, the regions, and the states and provinces of the United States, Canada and Australia; “mailed” and the Croatian, Czech and Slovak shipping words count as shipping words. Six stored shops gain their delivery area, none loses one.
FixedReturn shipping responsibility
“Les frais de livraison pour les retours sont à la charge du client”, “op eigen kosten retourneren”, “U betaalt de kosten voor retour”, “os custos de envio de troca são por conta do cliente”, “puedes devolverlos gratuitamente” and the Hungarian “költsége a vásárlót terheli” now count. Six stored shops gain the row.
Update 12.11

Refund timelines and compound delivery words

Every report row that had passed only because the model layer read it was re-read by the rules on its stored page. The refund and delivery-time rows shared a few mechanisms, fixed by sentence.

FixedRefund processing timeline
“We will process your refund or exchange within 7 business days”, “please allow 5–10 business days for your return to be processed”, “procesaremos el reembolso en un plazo máximo de 5 días hábiles” and “storten wij het bedrag binnen 1–2 werkdagen terug” were dropped because the sentence also mentions a return, and the refund shapes knew one English word order. The refund now owns the duration in either order, in English, Spanish, Dutch, German, French, Italian and Portuguese. Six stored returns pages gain their refund timeline; one return window that had read as doubt reads clearly.
FixedDelivery time
“Die Standardlieferzeit beträgt 1–4 Werktage” had no delivery word for the scanner: German compounds hid the stem behind a word boundary. “Bei Dir eintreffen” (arrive) and the Polish inflection “czas dostawy” were missing too. A range written with the shop’s own connector — “1 a 15 días”, “2 bis 3 Tage” — is now quoted whole rather than by its upper bound.
Update 12.10

When you can be reached, read in your language

The customer-service-hours check knew English phrases, a weekday range in three languages, and a clock range only when “Uhr” followed it. “Lunes a Viernes: 10:00 - 13:30”, “Mo - Fr : 9h - 12h30”, “maandag tot en met vrijdag tussen 9u en 17u” and “Sun-Thu: 10:00-18:00” were misses.

FixedCustomer service hours
Across the stored contact pages the check missed 122 of 163; 45 of those state hours, and 20 were reported as stating none. It now reads three shapes in the shop’s language: a weekday range (full names in thirteen languages, or the capitalised short pair such as Mo - Fr, Lun - Vie, Sun-Thu), a clock-time range with a clock signal on at least one side (minutes, am/pm, h, Uhr, uur — a bare “1 - 3” is a count of days, not a schedule), and an hours label (Öffnungszeiten, horario de atención, openingstijden, radno vrijeme, godziny otwarcia). The row quotes the schedule it found. Twenty-four stored contact pages gain their hours, none loses any.
Update 12.9

Where to send the return, read in your language and on the lines that follow

The return-address check found an address on 1 of 151 stored returns pages by itself; the rest had been rescued by the model layer. Its instruction set was English only, and it expected the street and postcode on the same line as “send returns to”.

FixedReturn address
Real returns pages write the address on the lines after the instruction, behind a company name, an “Attn: Returns” line or the company’s legal form, and say it in their own words: “An [the shop], Salzdahlumer Str. 196, 38126 Braunschweig” (the withdrawal form), “Retouradres Biesland 13 1948 RJ Beverwijk”, “à l’adresse suivante : 15-6377 Rue Saint-André, QC, H2S 2K6”, “Adres do zwrotu: Okólna 40A 05-270 Marki”. The check now reads the instruction in a dozen languages, lets the address follow across line breaks and company lines, and knows Canadian and Australian address forms. Across the stored returns pages it now finds 17 more addresses and loses none. A stale or negated destination (“old return address”, “do not send returns to”, “ehemalige Rücksendeadresse”) still does not count.
Update 12.8

Who pays for the return, read as a shape

The check for who pays return shipping was a list of phrasings. “You ship the item back and cover return shipping”, “return shipping fees are to be handled by the customer”, “the cost of return shipping is paid by the buyer” and every French page (“les frais de retour sont à votre charge”) were misses.

FixedReturn shipping responsibility
Across the stored returns pages, 32 stated who pays and were missed by the phrase list; 25 of them were reported correctly only because the model layer read them, and 5 were reported as not stating it. The check now reads one shape in a dozen languages: a return-cost term (return shipping, return postage, the cost of returning, frais de retour, gastos de devolución, spese di reso, retourkosten, koszty zwrotu, returfrakt, Palautuskulut, Rücksendekosten) beside a bearer term (customer, buyer, borne by, responsibility of, we cover, refunded, à votre charge, a cargo del cliente, ponosi kupujący, betalas av kunden) in the same sentence, either order. A free-return phrase counts on its own. “We are responsible for return shipping costs” now counts too; an earlier version had refused it on purpose.
Update 12.7

Shipping cost, delivery area and duties, read in your language

A German shipping page with a full cost table (“Versandkosten pauschal 5,99 €”, “versandkostenfrei ab 150 €”) and “Die Lieferung erfolgt weltweit” was reported as stating neither a shipping cost nor a delivery area.

FixedShipping cost
The shipping-cost check knew English phrasings only. Across the stored shipping pages it missed 36 cost statements written in German, French, Spanish, Dutch, Italian, Portuguese, Polish or a Nordic language; ten of those reports said no cost was stated, and the rest were rescued only by the model layer. The same three shapes are now read in each of those languages: a free-shipping statement, a shipping-cost word, and a shipping word beside an amount in the local currency.
FixedDelivery area
The delivery-area check was an English phrase list, and its row never quoted anything. “Wir liefern innerhalb Deutschlands und nach Österreich”, “Nous livrons partout au Canada”, “Entregas a todo el país” and even the English “Shipping Information for Europe” were misses — 60 pages, 15 of them reported as stating no area. A geographic word now counts only in the same sentence as a shipping word, a region or country only behind a word like “to”, “within”, “nach” or “en”, and a sentence naming two countries beside a shipping word counts too. The row quotes the sentence it rests on. A page platform’s “millions of stores worldwide”, a company name with “Europe” in it, “livraison en temps réel” and “returned to us” do not count.
FixedDuties and customs
A customs word now counts as a duty disclosure only beside a money or obligation word: “inkl. Zollabwicklung”, “frais de douanes”, “derechos aduaneros incluidos”, “paid to release the parcel from customs”. A note that customs may delay the parcel is not a disclosure of who pays.
FixedPhone number
A contact page reading “Märkische Straße 51-53 44141 Dortmund Tel: +49 (0)231 522540” had its street number and postcode published as the phone. The number a label names, or one that starts with a country code, now wins over a number that merely sits nearby.
Update 12.6

A promise that says “delivered” is still a delivery time

Sentences like “your order will be delivered within 3–5 days”, “orders are shipped within 2 business days” and “votre commande est livrée en 5 jours ouvrés” were thrown out by the rule that guards against clocks starting at delivery, because the word itself was in the sentence.

FixedDelivery and dispatch times
The scanner keeps a return or claim window (“14 days after delivery”) apart from a delivery time. It did so by refusing any sentence that contained a word like delivered, received, shipped or sent — which also refused the plainest promises a shop makes. It now reads the word order instead: a duration followed by “of, after, from delivery”, or “once delivered” followed by a duration, starts at the parcel’s arrival and is never a delivery time; “delivered within 3–5 days” is. Read across every stored shipping and returns page, this recovers delivery times, dispatch times and refund timelines on dozens of shops, in nine languages, and takes nothing correct away.
FixedWhat the old rule had been hiding
With the blanket gone, some sentences needed reading for what they are. “3–7 business days for delivery from the date your order is shipped” is a delivery time, not a dispatch time. “2-day air” is a carrier service, not a promise to leave the warehouse in two days. “Adjustments must be received 72 hours before the ship date” is a deadline, not a delivery time; “processed within 1–3 days before shipment” still counts as dispatch. “Tracking information is provided within 2 days of shipping” is a notice, not a shipment. “If you haven’t received your order within 10 business days, contact us” is a recovery clock, now recognised with the curly apostrophe most shops actually use.
FixedRefund timelines
A returns page that states a legal maximum (“at the latest within fourteen days”) beside its own timeline (“within 10 working days”) used to read as doubt. Two statements are two statements: the row now quotes both.
Update 12.5

A language switch on your policy page is not another policy page

A returns page with a language selector (the same address plus ?switchlang=en, fr, it) was read as three more returns pages. The shop remembers the switch, so the scan then read the shipping and terms pages in Italian.

FixedFollowing links off a policy page
When a policy page is thin or misses a fact, the scanner follows one link off it to the page that may carry the rest. A link to the page’s own address with a parameter added — a language switch, a currency, a print view — is that page in another state, not another page, and is no longer followed. On a shop that keeps such a switch in the session, following it had changed the language of every page read afterwards, so the report quoted your terms in a language you never chose. A page routed by its address parameters keeps its own parameters, so a link with different values is still followed.
Update 12.4

Your footer is every footer on the page

A shop whose footer is built from four footer blocks keeps its AGB, privacy and withdrawal links in the fourth. The scan read the first block, missed all three, and fell back to guessed addresses that served a catalogue menu.

FixedFooter links and footer text
The scanner read one footer element per page: the first one. Many shops build the footer from several — a payment strip, a newsletter block, the address, the legal links — and the first is rarely the one with the policy links. Every footer element on the page is now read as one footer, for the links it carries and for the business-identity check that looks for your name, address and phone there. A footer inside a pop-up or a slide-out drawer is still left out. A page-state class such as modal-open on the body no longer makes the whole page look like a pop-up, which had been blanking the footer text on some shops.
FixedDelivery time ranges
A delivery time written as a range — 1 - 3 Tagen, 3 to 5 working days — was quoted by its upper bound only. The row now quotes the range as your page writes it. The day count still uses the upper bound, so no grade moves.
Update 12.3

A page that answers for any address is not your returns policy

One shop answers /pages/returns, /pages/privacy-policy and /pages/terms — and /pages/anything-at-all — with the same catalogue menu. The scan said all three policy pages exist, then graded the menu.

FixedGuessed addresses
When a policy page is not linked anywhere, the scanner tries the usual addresses for it. A shop that serves one generic page for any unknown address passed every check that guarded that guess: a real title, no “not found” wording, plenty of words. The report then said the returns, privacy and terms pages exist and graded the catalogue menu as each of them — no return address, no data-protection language. Now, once a guessed address has passed every check — whichever part of the scanner guessed it — the scanner asks one more question: does a nonsense address in the same folder answer with the same page? If it does, the guess found nothing, and the report says the page was not found rather than describing a menu.
NoteCost and precision
One extra request per folder per scan, only when a guess is about to be accepted. Two pages count as the same when their text matches, allowing for a date or a visitor counter that differs. A shop whose unknown addresses answer a different generic page keeps its policy.
Update 12.2

Two delivery times are a delivery time, not a doubt

A shipping page that says “1–3 days in Germany, 2–5 days abroad” was told the scanner could not work out which one was the delivery time. Thirty-five stored shipping pages carried that row; read by hand, nearly all state one time per destination or service.

FixedOne time per destination
When the scanner’s own delivery-time patterns miss and it falls back to the durations a page states, two different ones used to end in a warning: “duration-like values, but the scanner could not determine which one is the delivery time”. Each of those values already sits in its own delivery sentence — that is how it was picked up — so two of them are two statements. The row now reads “Delivery/transit times stated: 1 - 3 Tagen, 2 - 5 Tagen” and passes. Handling times get the same treatment. A returns window with two values keeps its doubt: a shopper has one window, not one per country.
FixedA clock that starts at delivery is not a delivery time
Removing the doubt showed what it had been hiding: “claims must be reported within 7 days of delivery”, “within 60 days of the order’s delivery date”, “damages reported within 14 days of receipt” had all been counted as delivery times. A duration followed by of, after or from + delivery, receipt or arrival counts from the parcel’s arrival — a claim, return or notice window — and is never the transit now, in nine languages. “Within 1–3 working days of receiving your order”, counted from the purchase, is still a dispatch time. How long a shop will hold an uncollected parcel is not a delivery time either.
NoteOn another page
When the shipping page is missing and a delivery time is read from the returns or terms page instead, two figures there still count as a doubt: a returns page that mentions two is more often talking about something else.
Update 12.1

A returns policy on your shipping page is still a returns policy

Three shops keep their returns terms on a page the scanner had filed as shipping — a delivery-information page, a “Shipping & Returns” page, a Japanese legal notice — and were told they have no returns policy at all.

FixedWhere the scanner looked
When no dedicated returns page is found, the scanner reads the Terms page for a combined policy and, if the returns terms are there, reports that instead of “no returns policy”. It read the Terms page only. “Items can be returned within 14 days” on a delivery-information page, “we cannot accept returns for refund” on a shipping-and-returns page, and the returns clause of a Japanese 特定商取引法 notice were all invisible to it. Every other captured page is read now, Terms first, and the first page that carries the policy is the policy: the report names that page and links to it.
NoteWhat it costs and what it does not
Only a page that speaks of returns at all is asked — a cookie policy costs nothing. Terms is always asked, because the return vocabulary does not speak every language and Terms is where a combined policy most often lives. A page that turns out to say nothing about returns changes nothing.
Update 12.0

An error page at your root address is not your shop

One shop’s root address answers “HTTP 404: Nicht gefunden” with a 200 status; the shop lives on www. The scan graded the error page as the shop and told the owner fifteen things that were not true.

FixedReading the error page as the shop
A server can answer “OK” and still send an error page. The scan took the status at its word and reported the error page’s own do-not-index tag as “your store is unavailable for indexing”, then no viewport, no favicon, no products, no navigation, no contact details, no address — while its policy reading, which had followed the browser, was quoting the real shop. A page whose title or opening says it is an error page is not the shop now, whatever the status code, the same rule the policy pages have long used.
FixedThe other address
A shop is one site on two host names. When the root address errors, the scan tries the address with (or without) www once; if that serves the shop, the report is read from there and carries one new finding: your root address serves an error page. Google reaches a shop through the address given in Merchant Center, and a root that errors is a claimed address that does not resolve to the store. When neither address serves a shop, the scan says so and stops rather than grading an error page.
NotePrecision
A shop that sells a “Page Not Found” poster is still a shop: the opening-lines rule also needs a page thin enough to be an error page. Error-page phrasing is recognised in eight languages.
Update 11.9

The model does not fail a shop on its own

Scanning the same shop twice could give a finding a “fail” one day and a “warn” the next — same page, same words. The language model was choosing, and it does not choose the same way twice.

FixedA model reading is a warning
Part of every report comes from a language model reading your pages: fabricated urgency, unsubstantiated claims, templated reviews, policy pages that say nothing. It used to decide whether each one was a fail or a warning, and on 10 of 102 findings we could compare across two scans of the same shop it decided differently the second time. Forty-one shops’ scores moved with it, by up to two points. Every model finding is now a warning to review — same words, same evidence, same place in the report — and only the checks that work from a rule you can read can fail a shop.
NoteWhat the model still does
It still reads every page and still flags everything it flagged before, with the quote it found it in and a note when the quote could not be verified against the page. Restricted product content keeps its higher standing among the warnings. What changed is who gets to take points off: a rule, never a mood.
Update 11.8

Hours count now

A third of shipping pages say how fast they ship in hours. The scanner only read days, so “dispatched within 24–48 hours” was no handling time at all.

FixedHours as a unit
Of 139 stored shipping pages, 32 state a time in hours — “dispatched within 24-48 hours”, “binnen 24 uur verzonden”, “dans un délai de 48 heures”, “Wysyłka w 24h”, “plazo de 24/48 horas” — and four of them were told they had not stated a handling time. Hours are read now, for handling and delivery times, as the days they amount to; a slash between two numbers is a range like any other.
FixedWhat an hour count is not
The same pages showed what else is counted in hours: “cancel your delivery within 48 hours”, “contact our support team within 5 hours”, “we pack our shipments to last 48 hours”, a “1 hour delivery time slot”, and the minutes of a clock time (“18:00 uur”). None of those is a shipping time, and none is read as one. A returns page’s “notify us within 48 hours” stays what it is: a deadline for you to act, not a returns window.
FixedDutch, on the way
The handling reading knew the Dutch noun for shipping but not the verb — “verzonden”, “verzenden”, “verstuurd” — so a Dutch shop’s “bestellingen worden binnen 24 uur verzonden” had two things against it. Adding the verb showed a second gap: “if you have not received your order two days after dispatch, contact us” read as a two-day handling time in Dutch and French, though not in English or German. That recovery clock is set aside in every language now.
NoteHow it was checked
Old against new over the same 139 shipping pages and 290 returns pages in one process, every changed row read: seven handling times gained across five languages, three wrong values that had passed now marked as unclear, nothing that was right before is wrong now.
Update 11.7

A return window is not a delivery time, and a dispatch schedule is a handling time

Three reading errors on shipping pages, found by checking the last run’s “not stated” rows against the live pages. Six shops were told their delivery time was their returns deadline; sixteen were told they had not said when orders leave, when they had.

FixedThe only number on the page
When a shipping page states no delivery time in a shape the scanner knows, it falls back to the one duration the page does state. On a combined shipping-and-returns page that one duration is the returns deadline — “puedes devolverlos dentro de los 30 días”, “de herroepingstermijn verstrijkt 30 dagen” — and six shops were told their delivery time was ~30 days. The fallback now asks the same question the main reading asks: what is this number about? A number that belongs to returns is no evidence of a delivery time.
Fixed“Cooling-off period”
One English shop stated its returns right as a “14 day cooling-off period starting from the day after you receive the goods”. The scanner knew “withdraw” but not the statutory name, and “receive” made it a delivery time. It is a returns window now.
FixedWhen orders leave
Handling time was only read as a count of days. “Orders are dispatched on Monday, Wednesday and Friday mornings”, “we pack and ship orders each day we are open”, “am nächsten Werktag versendet”, “op werkdagen” — all reported as no handling time stated. A schedule says when orders leave, and is read as one now, in five languages. A schedule said in the negative (“we do not ship on Sundays”) or a price sentence (“shipping rates are updated daily”) is not.
NoteHow it was checked
Every change was run old-against-new over the same 139 stored shipping pages and 290 returns pages in one process, and every row that changed was read by hand: the delivery-time rows that flipped were all returns deadlines; the sixteen handling rows that flipped were all real schedules; nothing that was right before is wrong now.
Update 11.6

The one shop that ran out of time now finishes in under four minutes

Of twenty shops in our last run, one hit the eleven-minute limit and got no report. Its checkout walk alone took five and a half minutes, spent asking one question at a time of a page that answers slowly.

FixedAsking a slow page one thing at a time
To find your add-to-cart button the scanner tries thirty-eight ways of describing one, and for each it asked the page twice whether anything matched. On most pages an answer takes a few thousandths of a second. On a page whose scripts keep the browser busy, every answer waits behind them — on this shop a second and a half each, two hundred and twenty-eight times. The scanner now asks about all thirty-eight in one question, and only looks closer at the ones that matched. Same descriptions, same answers, same button.
FixedThe policy step
While reading your policy pages the scanner asks a language model four one-fact questions — a blanket no-returns clause, a box number as the returns address, the same on the contact page, a subscription clause — only when its own patterns found nothing. It used to stop and wait for each answer in turn. It now asks the moment it has the page and carries on with the rest of the reading; the answers land in the report exactly where they always did. The full policy analysis starts at the same moment, rather than after the whole step is done.
NoteWhere the time goes now
On the two shops we timed, a scan went from six and a half minutes to just over three, and from over eleven to under four. What is left is the browser reading your pages, which waits a fixed few seconds on each one so late-loading popups and prices show up, and one long read of your policies by the model. Neither is being trimmed: both are where findings come from.
Update 11.5

Scans finish sooner. Nothing was cut to do it.

On the slowest shop in our last twenty-store run a scan took six and a half minutes. Most of that was the scanner waiting on one thing while it could have been doing another.

FixedWaiting in line
The scanner reads your policies with a language model twice over: once to judge them as a whole, once to find the facts the plain-text patterns missed. Those two reads took three minutes between them and ran one after the other — after the browser had finished with your pages and before it walked your checkout, so each half of the scanner sat idle while the other worked. They now start the moment your policy pages are in, and the product and checkout checks run while they are out. They are the same reads of the same text; they just no longer queue.
FixedThe screenshot pass
The look at your screenshots waited for the policy judgment to come back before it began, and that judgment is the longest single wait of the scan. It has everything it needs once the checkout has been captured, so it starts then.
FixedOne page at a time
When a fact was not found on the first pass, the scanner re-read each policy page in turn with a bigger window. On one shop three pages of the same size took three seconds, forty-nine and eight, one after another. They are now re-read together, so the wait is the slowest page rather than the sum of all three.
NoteWhat did not change
Every check runs as before, against the same pages, asking the same questions. The browser still waits its full settle on every page, because that is where late-loading popups and prices show up, and trimming it would be trading findings for seconds. A scan that finishes faster and finds less would be a bug, not a speed-up.
Update 11.4

A shipping charge being non-refundable is not a no-returns policy

A shop was reported as refusing all returns. The sentence quoted said its postage cost was non-refundable — and the sentence after it said refunds are issued.

FixedOne word order
The scan already knew that “shipping cost is non-refundable” is ordinary boilerplate and not a refusal to accept returns. But it only recognised that phrase in one order. This shop writes “The cost of shipping is non-refundable” — cost first — and was reported as having a blanket no-returns policy because of it. Both orders are now understood.
NoteWhy it only applies to the sentence itself
The obvious fix was to accept both orders everywhere the old check looked, which is a window of text around the phrase. That was tried and measured first: it made “We do not accept returns. The cost of shipping is non-refundable.” stop being reported — a real refusal silenced by the sentence after it. So the wider wording is only asked of the sentence the clause is in. That is a question about what the clause says, not about what happens to sit near it.
NoteWhat it still will not catch
The rule is about shipping COSTS. “Return postage is non-refundable”, with no cost word in it, is still read as a refusal. Widening it that far would let “We ship worldwide. No refunds.” suppress a genuine one, and we have no example of a shop written the first way. Recorded as a known limit rather than guessed at.
Update 11.2

A neighbour’s price is not your product’s claim

A shop selling a £55 planner was told it had an unproven discount claim — the figure came from a diary listed further down the same page.

FixedThe wrong two numbers were being compared
A leather goods shop sells a £55 table planner. The same page lists other diaries, one of which shows “Regular price £98.00 Sale price £98.00” — the same figure twice, so that diary is not on sale either. The check compared the £98 against what THIS page charges, £55, decided they differed, and reported a claim nobody had made.
ChangedCompare it with the price beside it
A reference price is always printed next to the price it is being measured against. That is now the comparison, and it works whichever product the block belongs to. Where there is no price beside it, the check falls back to comparing against what the page charges, as before.
NoteWhat we tried first, and why it was wrong
The obvious fix was to ignore the “related products” part of the page. Measured before building it: on four of five real product pages that removed none of the text at all, and on the fifth 5%, and it changed no finding — those strips are drawn by JavaScript and are not in the page we read. The text was never the place to fix this.
Update 11.1

A delivery cut-off is not a reference price

A shop that promises same-day dispatch if you order before 15:00 was told it had an unproven price claim — quoting its own delivery cut-off back at it.

FixedA time read as a price
The rule that spots reference prices (“RRP”, “was”, “regular price”) also accepted the word “before” followed by a number. A tattoo supplier writes “orders will be dispatched the same working day if ordered before 15:00”, and the scan read that as a reference price of 15. “Before” is the only word in that list that is an ordinary preposition rather than a price label, so it now has to be followed by actual money.
FixedA clock is never a price
Separately, and under every label: a number that is part of a time — 15:00, 14:15, 09:30 — is no longer read as an amount.
NoteNothing real was lost
Checked old against new across 28,761 pieces of stored evidence: 159 genuine reference prices match both ways, 19 stop matching, and every one of those 19 is a time or a date — “before 12 PM”, “before 1.30pm”, “before 14 days after receipt”. Nothing new was let in.
NotePrices without a currency symbol still count
The money requirement applies to “before” alone. Shops that write “Regular price 44,90” or “Original Price 139,90” with no symbol are still read correctly — 13 of these findings had no symbol anywhere, and the genuine ones were all European prices written plainly.
Update 11.0

A price equal to itself is not a discount claim

Shops were told to justify a saving they were never advertising, because their shop software prints the words “Regular price” on every product.

FixedA warning about a discount that was not there
Shopify’s standard price block prints “Regular price $8.82 … Sale price $8.82” on every product page, on sale or not. The check spotted the words “Regular price” and warned that a reference price had been found and could not be proven. Both numbers are the same. Nothing was being claimed, and there was nothing to prove.
ChangedThe rule now compares the numbers
A reference price is only reported when it differs from what you are actually charging. If we cannot read the number, or cannot see what the page charges, the finding stays — the point is to stop inventing claims, not to start excusing them.
FixedIt was also inflating a second finding
The same match fed the rule that turns a “50% off” line into a discount finding. So a shop’s default price markup could promote an unrelated sale line into a formal finding, on the strength of a reference price nobody had claimed. Both now read the same answer, from one check instead of two.
NoteHow many
Of 152 of these warnings in our records, 79 quote a fragment containing a single price — one number, with nothing to compare it to. The shop that showed it: a candle maker whose page reads “Regular price $8.82 … Sale price $8.82”, the same figure twice.
Update 10.9

A claim we could not check is not a claim we withdrew

When a shipping page claimed local fulfilment, the scan raised the question and then quietly dropped the whole row — whether it had checked or not.

FixedA row that vanished two different ways
If your shipping page says something like “UK warehouse”, the scan notes it and then looks at a product page to see whether the two agree. That is the right rule — a warehouse claim on its own accuses nobody. But it was enforced by deleting the row. So the row disappeared both when the product page had been read and agreed, and when no product page had been read at all. Either way you saw nothing.
ChangedNow it says which
The row stays and tells you what happened: either the product page was read and carries nothing that contradicts your claim, or there was no product page reading to compare against — in which case the row scores nothing at all, because that is our gap and not yours. Neither outcome accuses you of anything.
NoteThe rule itself has not moved
One claim is still never enough. A fulfilment problem is only reported when the shipping page and the product page actually contradict each other — for example a local warehouse promise beside a product that states it ships from overseas. That stays a serious finding.
NoteHow many
Across 549 shops whose shipping page was genuinely read, 45 — 8.2% — had this row deleted and never knew the question had been asked. The product page could be read on roughly half of scans, so both causes were real and the empty space could not tell them apart.
Update 10.8

A navigation we could not sample is not a navigation that works

The link check read the page before JavaScript built the menu. When it found no menu, it said nothing at all.

FixedMenus built by JavaScript
The check that samples your header and footer links and reports dead ones was reading the page as it arrives from the server. A menu built by JavaScript is not in that. One shop has fifteen navigation links on screen and none in the fetched page — so the check found nothing to sample. It now falls back to the rendered page and actually runs.
FixedSaying nothing is not an answer
When it could not sample a menu, or when the links did not answer in time, the check returned nothing — no row, no note. A reader could not tell a navigation that had been checked and passed from one that was never looked at. It now says which of the two happened, and that row scores nothing either way, so our reach is not charged to you.
NoteHow many
Across 669 stored scans, 102 — 15.2% — carried neither this check’s pass row nor its warning. Those reports were silent about navigation and gave no sign of it.
NoteWhat did not change
Two or more dead links still raise a warning; a single dead one is still named but not flagged, because one 404 is usually a stale cache rather than a broken site. The number of links needed before a menu is judged at all was written twice in the code as a bare number and is now written once.
Update 10.7

We were surer about your returns page when we could not read it

One row told shops their returns policy had no no-returns clause, on a page the same scan had just said it could not open.

FixedA pass on a page that was never read
When a returns page cannot be reached, the report publishes nine rows about it. Eight say so plainly: “Could not verify — not evidence that this information is missing.” The ninth said “no ‘all sales final’ wording found” and scored it as a full pass. It was reading the homepage instead. A no-returns clause lives on the returns page, not the front page.
FixedMore confident with less read
When the returns page CAN be opened and carries no such clause, the scan deliberately says nothing — the absence of one phrase is not proof a returns policy is sound. So the report claimed more about shops whose page it had failed to open than about shops whose page it had read in full. That row now says what its eight neighbours say, and scores nothing either way.
FixedA second check that was quietly skipped
When the returns page is unreachable, the scan searches every other policy document — terms, shipping, privacy — for the clause it could not check for, and asks a model to read them in any language. That search found its starting point by matching one exact sentence. Two different situations produce this row and they word it differently, so shops whose returns page was found but would not load never got the second search at all. It is now found by what it is rather than by how it is worded.
NoteHow many
99 stored scans carry the old claim, spread evenly across July, August and September — so this was current behaviour, not old history. Where the second search does find a clause in another document, that finding counts in the score exactly as before; only the empty-handed case changed.
Update 10.6

A finding quotes your shop, not an example

Three rows reported what they found and then printed example wording that was never on the page.

FixedRows that showed you someone else’s words
A Spanish shop showing “¡Solo quedan 3 en stock!” on four products was told: “4 scarcity indicator(s) found on the homepage (e.g. ‘Low stock’, ‘Hurry — limited stock left’, ‘Only 3 left’).” The quote underneath was right; the three examples in the sentence appear nowhere on that site. A merchant cannot tell which of those they are supposed to have written. Those rows now say how many were found and let the quotes speak.
ChangedQuote marks mean one thing now
The viewer-count row said “4 ‘live viewer’ counter(s) detected”, using quote marks to name a category rather than to quote a page. Read quickly that is indistinguishable from a quotation. Inside a finding, quote marks now mean one thing: this is text from your shop.
NoteAdvice still gives examples
Nothing changed where we tell you what to write — “state your return window (e.g. ‘30 days’)” invents nothing about your page and stays as it is. The rule applies to rows reporting what was found.
NoteWhy it surfaced now
It went unnoticed while the check only read English, where an invented English example is at least plausible. Widening it to four more languages made it visible. That is the ordinary way this kind of wording fails: written once beside one language, and nothing rechecks it when the reach changes. There is now a test that reads every one of these rows and fails if the sentence quotes anything the evidence does not.
Update 10.5

The scarcity check now reads Spanish, Portuguese, Japanese and Norwegian

Four more languages, each added because a real shop was found using the wording — and each declared, so the report still says when it cannot read a page.

AddedScarcity and urgency wording
The check that looks for “only 3 left”, “low stock” and “almost sold out” now also reads Spanish, Portuguese, Japanese and Norwegian. Each list covers the same ideas the English one does — only N left, low stock, limited stock, almost sold out, few left — not just the one phrase that happened to turn up.
AddedWhy those four and not others
Each was added because a real shop was found using the wording: “Solo quedan 3”, “Restam 74 Unid.”, “残り３点”, “Få igjen”. German, Dutch, French and Italian were deliberately left out, and that is a measurement rather than an oversight: across 566 shop homepages those shops carry “Op voorraad”, “en stock” and “Über 10.000 Artikel auf Lager” — stock facts, mostly the opposite of scarcity. No shop found using it, no claim that we read it.
ChangedOne shop, three answers
A Spanish shop selling ceramics shows “¡Solo quedan 3 en stock!” on four products on its homepage. Yesterday the report said no scarcity wording was found. This morning it said the check could not read the page. It now reports the four, and quotes them.
NoteWhat was deliberately not added
“While stocks last” is a normal retail disclaimer, not an urgency widget, and it has never been flagged in English. So the German “solange der Vorrat reicht” and the Dutch “OP=OP” are not flagged either. Matching a phrase in one language while ignoring it in another would be the same fault in a new coat.
NoteChecked against every homepage we hold
Widening a rule like this can start seeing urgency in ordinary shop copy, so every hit was read before it shipped. Across 566 stored homepages the new wording matches five shops that the old rule missed, every one of them a genuine “only N left” claim, and it matches nothing on a page in any other language. “Restam 3 dias” is three days, not three units, and is still refused.
NoteThe other three widget checks
Viewer counts, sold counters and recent-purchase pop-ups still read English only, and still say so on a page they cannot read. Nothing in 566 homepages showed how those widgets are worded in another language, and a list covers what it covers.
Update 10.4

A check that cannot read your language no longer calls your shop clean

Six homepage checks find what they are looking for by matching words. Four of those word lists are English only, and they were passing shops they could not read.

FixedSix checks that match words
Some checks look for a thing by its wording: “only 3 left”, “12 people are viewing this”, “48 sold today”, “someone just bought this”, “2,400 happy customers”, “P.O. Box”. Four of those word lists are written in English and nothing else. On a shop written in any other language they found nothing — and the report published that as a clean pass, worth a full point, as though the shop had been checked and cleared.
FixedShops that were told the opposite of what their own page said
Twenty-one shops in our records were told no scarcity or urgency wording was found while their own homepage said “OP=OP”, “Últimas Unidades”, “残り３点” or “Få igjen”. Every one of those is the same phrase we do flag when it is written in English. The shop had not been checked and cleared; it had not been checked at all.
ChangedEach word list now states what it reads
Every one of these word lists now declares the languages it actually covers, and a clean pass is published only for a page in one of them. Otherwise the report says plainly that the check could not run, and that row scores nothing at all — not a pass, not a warning, not a penalty. Our gap costs you no points. It just stops paying you for one.
NoteWhat did not change
The P.O. box list was written multilingual from the start and already covers German, Dutch, French and Spanish, so shops in those languages are still genuinely checked for it. The repeated-testimonial check reads no word list at all — it compares the page with itself — and is unchanged. And a shop that does show one of these widgets is still reported, in any language: only the clean pass was ever in question.
NoteThe measurement
Across 631 stored scans, 2,058 of 3,693 clean passes on these six checks came from a check that could not read the page. The scarcity check fires on 3.46% of English homepages and on 0.35% of homepages it cannot read, and that single hit turned out to be an English fragment on an otherwise Hebrew page. The repeated-testimonial check, which uses no word list, shows no such gap — which is how we know the cause was the wording and not the shops.
Update 10.3

A street name with a hyphen in it is still a street

One shop publishes its full address in its footer and was told it had none — because the street name contains a hyphen.

FixedOne character
A shop in Bangkok prints its whole address at the bottom of every page — building number, road, district, city, country. The scan reported “no physical address found” and advised adding the address the shop had already published. The reason was a single character: the rule that recognises an English-style street would accept letters, numbers and spaces in the street name, but not a hyphen. “311 Main Road” was an address; “311 Ladprao-Wanghin Rd.” was not.
FixedIt was never only about one shop
Hyphens are ordinary in street names everywhere. “Stratford-upon-Avon Road”, “Winston-Salem Avenue” and “O’Connell Street” were all being missed in exactly the same way. All of them read correctly now.
NoteChecked against every footer we hold
Loosening a rule like this can start seeing addresses in ordinary footer wording, so it was measured first. Across 203 real shop footers the change finds exactly one thing it did not find before — the Bangkok address — and stops finding nothing. Four pieces of marketing copy that had fooled an earlier, looser version of this rule are kept as permanent tests, and they are still refused. A postcode and a town with no street is still not a full address, as before.
Update 10.2

When the stock check cannot read your page, it says so

Half the product pages with stock information in their data got no stock row at all — not a pass, not a warning, nothing.

FixedThe other half of last night’s fix
The same check that compares your listed price against your page also compares your listed stock status against it. It was right not to call it a match when it could not read the page — an unreadable page is not agreement. But then it printed nothing, so a comparison that could not be made looked exactly like one that was never needed. Checked on sixteen product pages the scan had never visited: of the six with stock information in their data, three produced no row.
FixedAnd it says which reading failed
There are ordinary reasons a page cannot be read this way. A page showing several variants at once has no single stock state. A buy button that stays greyed out until you pick a size is a normal shop design, not a sold-out sign. The report now names which of those it ran into, says plainly that it is not evidence anything disagrees, and does not count it against your score — it is a limit of the scan, not a fault in your shop.
NoteNothing that worked stopped working
A page that can be read still gets a plain pass. A shop whose data says sold out while the page sells the item, or says in stock while the page says sold out, still gets the same firm failure it always did — that one is among the most serious things this scan looks for.
Update 10.1

The price check is back, and it says so when it cannot run

Checking your listed price against the price on your page had quietly stopped happening. It now reads the page directly.

FixedA check that went quiet without saying so
One of the things this scan does is compare the price in your product’s machine-readable data against the price a shopper actually sees, because a mismatch between those two is one of the things Google acts on hardest. That comparison was getting the shopper’s price from the part of the scan that looks at screenshots — and that part has been holding everything back since the eleventh. So the price comparison simply stopped, with no row to say it had. It ran nine times in the weeks before and not once after.
FixedReading the page instead
The scan already reads your page’s own price while it is checking whether the item is in stock — the same pass, the same visit, sitting in the same place. The price comparison now uses that. Checked on twelve real product pages: nine give a clean price, correct in pounds, euros, dollars, ringgit and pesos, including one written “€ 21,95* Excl.”. Where the screenshot reader does have something to say, it still leads.
NoteAnd when no price can be read at all
Some pages draw their price with a script after loading, and nothing readable is there. Rather than saying nothing — which is what went wrong here — the report now carries a line saying the two could not be compared, and that this is not evidence they disagree. That line does not count against your score, because it is a limit of the scan and not a fault in your shop.
Update 10.0

The price on the tile is not the price of the page

A shop’s product listing was read as a single product, and the first tile’s price and stock were reported as if they belonged to the whole page.

FixedA tile belongs to its own page
Shop software often puts a little machine-readable card behind every tile in a listing, one per product. On one shop’s listing of seventeen items, the scan picked up the first card — a sensory table — and reported its price and availability as though they described the page it was looking at. Those cards say which page they belong to, and the scan now reads that: a card pointing at a different page on the same shop is that page’s card, not this one’s. A listing then correctly comes out as having no product details of its own, which is the truth about a listing.
FixedAnd it happens on real product pages too
This is not only a listing problem. One shop’s sugar-bowl page carries the card for a different sugar bowl entirely. Before, the report would have quoted that other item’s price. Now it does not, and the page is judged on what it actually shows.
NoteA shop’s other address is still the same shop
Some shops sell from two addresses — a platform address and their own domain — and the card names one while you are on the other. That is the same shop and the same product, so nothing is thrown away there. Only a different page on the same address counts. Checked across ninety real product pages before shipping: the change touches exactly two, and both were reading the wrong item.
Update 9.9

Your basket is not one of your products

On one shop the page picked to represent its products was the add-to-basket link. The page then graded was the basket.

FixedA shop’s own utility pages, with anything after them
The scan has always known to skip a shop’s working pages — basket, checkout, search, sign-in, wishlist — when it goes looking for a product to examine. It was only checking the very end of the address. So “/cart” was skipped, but “/cart/add/26748776” was not, because the end of that address is an item number and the word “cart” never got looked at. One coffee shop’s product page was exactly that link: opening it drops an item in a basket, and the basket is what got examined. The same hole let a checkout page through on the same shop, and a password-reset page on another. Every part of the address is now checked.
NoteChecked against 559 real product pages first
Widening a rule like this risks throwing away real products, so it was measured before it shipped. Against 559 product pages the scan has genuinely found on real shops, the change rejects exactly four more — the two basket links, the checkout page and the password-reset page. Nothing else moved. Products with names like “cart-bag-leather” or “search-and-rescue-tshirt” are untouched, because whole words are matched, never the start of one.
NoteOne rule, not three
This rule existed in three places: a shared version nothing used, and two private copies that did the work. All three had the same blind spot. They are now one rule, and a test fails if either copy comes back.
Update 9.8

Three policies on one page are three policies

A shop keeps its returns, privacy and terms as three sections of one legal page. All three were being read as the whole 6,499-word document.

FixedWhere a section starts and stops
Last week the scan learned to read the part of a page that a link points at. It only worked when the shop had wrapped that part in a box of its own. Far more often the link points at the heading, and the section is simply everything that follows until the next heading. One shop’s legal page holds its return policy, its privacy policy and its terms one after another; all three links resolved to the same 6,499 words, so the returns check was reading the entire privacy policy and all of the terms, and the same text was reported for three different things. Now each one reads its own: 317 words of returns, 1,599 of privacy, 2,578 of terms, each starting at its own title.
FixedA sign-in form is not a returns policy
A French shop’s returns link goes to a page that asks you to log in first. The scan already knew to spot that and stop — but only in English. This shop’s sign-in page is at “authentification”, and the check was looking for “authentication”. So 490 words of login-page furniture were graded as the returns policy. The scan now notices the password box in the page’s own content, which needs no particular language and covers the same gap for German, Dutch and Spanish shops too.
NoteWhy the password box has to be in the content
Plenty of shops put a small sign-in box in the header of every page, including their real policy pages. Four were checked — policies of 8,172, 7,090, 4,502 and 3,683 words, all with a sign-in box in the header. None of them is affected: what counts is a password box sitting in the page’s own content, which is what makes the page a sign-in page rather than a page with a sign-in corner.
Update 9.7

If your policy is a section of a page, we read the section

A shop’s shipping terms sit in a named part of its homepage. The scan was reading the whole homepage instead — marketing copy and all.

FixedThe part the link points at
Plenty of smaller shops keep their terms, delivery or returns details in a named section of one page rather than on a page of their own, and link straight to that section. That is a perfectly good arrangement and the scan has always accepted it. What it did next was read the entire page. On one shop the shipping section holds 418 words of real delivery terms; the scan graded 1,687 words that begin “welcome to our angling shop”. Another was told its terms document was 174 words — its homepage. The scan now reads the section the link names.
FixedWhy that was wrong in both directions
Reading the whole page meant two kinds of mistake. Marketing copy could be quoted back as evidence from your policy. And a number sitting anywhere else on the page — a banner advertising thirty-day returns, say — could satisfy a check about a policy that never actually says it. Narrowing to the named section removes both.
NoteWhen we still read the whole page
If the link names nothing, or names something that is not on the page, or points at a heading with no real text under it, nothing changes and the whole page is read as before. Shops that keep a policy on its own page are untouched.
Update 9.6

Your policy still counts when it lives in an embed

A shop was told its privacy policy was a two-word stub. The policy is there, all 3,314 words of it, inside an embedded box on the page.

FixedReading a policy that arrives in a box
Plenty of shops publish their legal documents through a service that drops them into the page inside an embedded frame. The scan already knew how to follow one of those and read the document behind it — by asking the service directly for the page. That works when the service hands over plain text. It does not work when the service builds its page with scripts, and it cannot work at all when the frame is added to the page by a script, because then there is no frame to follow until the page is actually opened. One Hungarian shop was both: nothing to follow, and asking the service directly returned eight words of menu. The scan now simply reads what the browser already had open on the page. Privacy went from a two-word stub to 2,493 words, terms from a fifty-word stub to 2,295.
FixedThe rescue now works when the plain fetch is refused
There are two ways the scan can pick up a page: a plain request, or the browser. Every rescue for an awkward page — documents in an embed, documents in a PDF, a page that is only an index of links — was wired to the plain request. If a shop refuses plain requests, which this one does, the scan fell back to the browser and then had no rescues at all, so an awkward page came out looking empty. The embed rescue now works on both routes.
NoteOnly when the page has nothing of its own
An embed is read only when the page itself carries no real document, and what it finds is added to the page rather than replacing it. A shop with a proper policy of its own and a map or a video embedded next to it is untouched — checked against the same shop’s own six-hundred-word returns policy, which reads exactly as before and did not go near this.
Update 9.5

A cookie banner is not your privacy policy

One shop was told its privacy policy was five hundred words long and mentioned data protection. What had been read was the cookie consent box.

FixedReading the wall instead of the room
A Hungarian shop keeps its privacy policy in an embedded document that had not loaded, so the page itself held four words. The scan looked past that and took the next-largest block of text on the page — the cookie consent panel. It then reported the privacy policy as found, five hundred words, and substantive because it mentioned data protection. A consent panel talks about data protection; that is its entire job. The same thing happened on the terms page, and the two came out as the same document word for word. The shop’s real privacy policy was never read and the report signed it off anyway.
FixedWhat counts as the page now
A box you have to dismiss before you can read a page is not the page. Anything marked up as a dialog is now left out of the text a policy is judged on. That is the standard browser markup for “this sits on top of the page”, not a list of cookie-tool names, so it works the same for a consent wall, an age gate or a newsletter pop-up, whoever built it. Ordinary page sections are untouched — checked against the same shop’s genuine six-hundred-word returns policy, which reads exactly as before.
FixedAnd a policy in your own language
A related check confirms a policy page before the report says anything about it. It was leaning on a keyword list, and keyword lists always have a language missing — this one did not recognise a Dutch returns page, a Hungarian one, or a Lithuanian returns and delivery page, all of them real and hundreds of words long. A page that is plainly a written document now counts as confirmed whatever language it is in.
Update 9.4

A customer’s review is not your returns policy

One shop’s returns policy was a Trustpilot review a customer had titled “Return Customer!!”. Six rows were written about it.

FixedWhere the report thought the policy was
A dog-treat shop had six review links in its footer. One of them was a happy customer’s review headed “Return Customer!!”. The word “Return” was enough: that review became the shop’s returns policy. The report then said the returns page existed, that it stated no return window, that it did not say who pays return postage, that it carried no return address, and that at eleven words it was “too short to be genuine”. Every one of those was about a review of the shop rather than a policy of the shop. A link that is not on your own site is no longer taken as your policy.
FixedAnd when your policy really does live somewhere else
Some shops genuinely host their policies on another domain — after a rebrand, for instance — and telling them the pages are missing would be wrong. So the report has a gentler line for that case. The trouble was that it trusted the link without ever opening it, so a shop with no returns policy at all could be told theirs was “linked to a different website” and sent off to move a page that never existed. Now the page is opened and has to actually read like that policy before we say so. If we cannot reach it, we say nothing new and leave the plain finding standing.
NoteWhy link text is not enough on its own
Footer link text is written by whoever wrote it, and on a review widget that is a customer. A word appearing in a link is a hint about where to look, never proof of what is there. The same discipline already applies elsewhere in the scan: before a page is graded as your policy, something on it has to read like that policy.
Update 9.3

A page you never wrote and a page we could not read are not the same sentence

Four rows ended with “or page returned an error”, which made a clear result sound like it might be our fault.

FixedA result you can act on
When no returns, shipping, privacy or terms page could be found, the report said “No privacy policy page found or page returned an error.” Two different things in one sentence, and you could not tell which one you were reading. If the page was there but our scan could not fetch it, that is our limit and you should not be changing anything. If it genuinely is not there, you should. Those rows now say plainly that the page was not found, and add that a page which exists but could not be fetched is reported separately — so the row you are reading means what it says.
NoteWhy the old wording was already out of date
A while ago these checks learned to tell a missing page from an unreachable one, and an unreachable page already gets its own row that says, in as many words, that it is not evidence the page is missing. The old ending was left over from before that and had been hedging about something that could no longer happen.
NoteChecked against a real shop
A Lithuanian shop was told it had no privacy policy. We opened it in a browser to be sure: the shop loads fine, its returns, delivery and terms pages are all found and read, there is no privacy link anywhere on the page, and the usual address gives a genuine “page not found”. The verdict was right. Only the sentence was making it sound uncertain.
Update 9.2

We check Google’s rules, not your country’s laws

A handful of reports told shops their returns policy might break consumer law. That was never ours to say, and it is gone.

FixedA verdict we are not qualified to give
This scan measures one thing: whether what your shop publishes matches what Google Merchant Center asks of a store. That is a different question from whether a clause is legal where you trade, and it is a question we have no business answering. A few reports answered it anyway — “this clause may violate consumer protection laws”, “revise the policy to comply with legal requirements”. Those sentences are now blocked before they reach a report. If you want a view on the law, that comes from a lawyer who knows your country, not from a scanner.
FixedThe finding stays even when the closing line goes
Two of the findings were sound and only ended badly. One said a product page claimed health benefits it did not support — a real problem — then closed by telling the shop to be “compliant with local regulations”. Another said a returns policy put an unreasonable burden on the buyer, then closed the same way. Those findings still appear, with the legal tail cut off and the advice intact. Dropping a genuine problem because of its last few words would have been the easy answer and the wrong one.
NoteYour own words are still your own
Plenty of shops quote a statute in their own returns policy, and that is perfectly normal. Nothing here stops the scan reading such a page or reporting what it does and does not say — one report points out that a policy cites a legal provision without listing which products it covers, and that is still a fair thing to tell you. What changed is what the scan is willing to claim in its own voice.
NoteWhy a written rule was not enough
The instruction to judge against Google’s rules and never against the law had already been written down, in plain terms, and it still slipped through. An instruction is not a check. It is now enforced in code, and the reports that were affected are counted rather than quietly discarded, so we can see if it ever happens again.
Update 9.1

Your return address, written the way Europe writes it

Six shops in a row were told no return address could be found on their returns page. Four of them print it right there.

FixedA house number goes after the street here, not before it
The address the scan knew how to read was the American one: number, street, one of a handful of English street words, then a state and a zip. Germany and the Netherlands put the street first and the number after, often with no street word at all. France puts “Rue” at the front. The postcode comes before the town, not after it. Ireland’s code is a format of its own. What the scan looks for now is the thing all of them share — a house number beside a street, then a postcode followed by a town — rather than a list of street words in every language, which is a list that is never finished.
FixedAnd the sentence in front of it
Two shops wrote it plainly in English and were still missed: “returned directly to our store: …” and “The return address is : …”. The first has a word between “returned” and “to”; the second says the field in a sentence rather than on a line of its own. Both read now.
NoteWhat still is not read, and why we are saying so
A German shop’s address is now recognised but its sentence is not — it says “An …” rather than anything English, and no wording has been invented for it here. The same goes for “items must be sent back to …”, which no shop in the group measured actually writes. Adding wording without a real shop to check it against is how a scan starts claiming you said something you did not, so those stay unread until a shop shows us the sentence.
Update 9.0

Your return window is your return window, not your refund clock

One shop was told its return window was thirty days. It is fourteen, and the shop says so twice on the same page. The thirty came from a sentence about when the money arrives.

FixedA wrong number, not a missing one
The shop writes “contact us within fourteen days to arrange a return” and “must be returned within fourteen days”. The report reached past both and quoted “refunds will be issued within thirty days of receipt” instead, then printed thirty as the return window — while the refund row, one line below, quoted the very same sentence. A merchant reading that would have had the wrong deadline for their own policy.
FixedWhen the money moves is a different fact from when the goods go back
These have always been two separate rows and they stay separate. A sentence about a refund being issued, processed, credited or paid is the money; so is “we will refund you within fourteen days”. None of them can be read as a return window now. What still counts is the shopper asking — “you may request a refund within thirty days of purchase” really is a deadline for you, and it still reads.
NoteThe risky direction was the other way
A rule that throws sentences out can delete a real finding as easily as it removes a wrong one. So a test puts both sentences on one page and insists the shopper’s own deadline survives; widening the rule until it swallowed that test is exactly what we checked for before shipping.
Update 8.9

Who pays return postage, read in German

A German shop states who pays to send something back, in the exact sentence German law gives shops to use — and the report said it could not tell.

FixedThe sentence almost every German shop uses
“Du trägst die unmittelbaren Kosten der Rücksendung” — you bear the direct costs of sending it back. That wording comes almost word for word from the model withdrawal notice German law provides, so it sits on a very large share of German shops, and every one of them was being told we could not determine who pays. Both answers are read now: the shopper bearing the cost, and the shop covering it or offering free returns.
FixedA second Dutch way of saying it
One shop answers its own heading — “are the return costs mine?” — with “the direct costs of returning a product are for your account”. The wording added earlier this year expected the phrase “retourkosten” and a short gap; this one puts a whole phrase in between. Both read now.
NotePostage out is not postage back
The cost has to be named as a RETURN cost. A shop stating its ordinary delivery charge, or offering free delivery over fifty euros, is not stating who pays to send something back — and one shop in the group measured for this does exactly that on its returns page. It still gets told the fact is missing, because it is.
Update 8.8

A free scan now opens three of your findings in full

A free scan used to show you a verdict, a score and a locked door. It now opens three real findings — the page we looked at, your own words quoted off it, and what to do — so you can check our working before deciding whether to pay for the rest.

NewThree findings, opened, with the evidence
Each one names the page it came from, quotes the wording found there, says how we read it, and gives the fix. Nothing blurred, nothing teased. The three are picked by us, not by your browser, and they stay the same three however many times you reload — so if you are working through them, your place holds.
NoteOnly ever the smallest ones
They are drawn from the least serious tier a scan grades, and never from anything major or critical — those are what the paid report is for. Findings that quote your own pages are preferred over ones with nothing to show, because proving the scan is real is the whole point. If a shop has nothing at that tier, the page says so plainly rather than pretending.
ImprovedAnd it says what it is holding back
Under the three, the count of what was withheld, taken from your own result: how many critical or major findings there are, and how many more small ones. The page never implies the three are everything.
Update 8.7

Your report remembers where you left off

Working through a list of findings and reloading the page used to lose your place.

FixedThe findings you opened stay open
Ticking a finding as resolved was already remembered. Which ones you had OPENED to read was not — that snapped back to “criticals only” on every reload, so anyone part-way through a long list lost their place. It is kept per report now, along with whether you had unfolded the minor run, and it comes back exactly as you left it. Collapsing everything is remembered too, rather than being read as “nothing saved”.
NoteWhat is kept, and where
Only the identifiers of the findings, in your own browser, tied to that one report. Not their wording, and nothing leaves your machine. A re-scan that finds different things quietly drops anything stale. If your browser refuses to store it — private mode, or a full disk — the report opens normally with no memory rather than breaking.
Update 8.6

Your return window, read in your own language

Three shops state how long a shopper has to send something back, in plain words on their own returns page, and the report said it could not find one.

FixedGerman, French, Polish and Dutch
The wording it knew was English. So “30 Tage Widerrufsrecht”, “retour sous 30 jours”, “masz 15 dni na odstąpienie od umowy” and “retourtermijn bedraagt 90 dagen” were all read as silence, and each shop was warned for not stating something it states clearly. One of them offers ninety days — a generous policy the report had nothing to say about.
NoteSending it back is not the same as getting paid back
These are two separate rows and they stay separate. The German for “refund” looks a lot like the German for “return”, so every new pattern here insists on a sending-back word: a promise to repay you within fourteen days will never be counted as a fourteen-day return window, and neither will a delivery estimate.
NoteA return label is not a return window
Caught before this shipped: “the return label is valid for ten days” is the lifetime of a piece of paper, not the time you have to change your mind. The rule now refuses labels, slips and forms while still reading the words for the right itself.
Update 8.5

A tick in the box is still a choice

One shop offers guest checkout in plain sight — an ordinary “create an account” tickbox beside the name and address fields — and the report said it could not tell.

FixedWhether you can turn it off, not how it starts
A tickbox offering to make an account, sitting beside the rest of the order form, is the clearest sign there is that an account is not required. The scan only accepted it if it started UNTICKED, because the first shop that taught it this pattern happened to ship one that way. Plenty of shops tick it for you, and a shopper who unticks it still orders. What matters is whether it can be turned off — a box nobody can change is a gate, and that is still refused.
FixedA compound word is still the word
The German wording it knew was “Konto erstellen”. The shop writes “Kundenkonto anlegen” — a joined-up noun and a different verb — and neither half matched, so a checkout that offers guest ordering had nothing said about it either way. The rule now reads the joined form, in the three verbs a shop actually uses, and still ignores a box about your privacy policy, your newsletter, or a different delivery address.
NoteWhat was NOT flagged, on purpose
That box is ticked for you by default, which is worth knowing but is not a Google Merchant Center matter — making an account adds nothing to what you pay. These reports cover Google’s policies and nothing else, in both directions: a finding grounded somewhere else is never published, however tempting it looks.
Update 8.4

Two shops were being judged on their basket and told it was their checkout

If your shop keeps its basket at an address containing the word “checkout” — which two of the biggest shop platforms do — the scan pressed the wrong thing and never left the basket. It then reported on that basket as though it were your checkout page.

FixedA link back to the page you are standing on is not a way forward
Looking for the way to your checkout, the scan took the first link whose address contained the word “checkout”. On a basket that already lives at that address, the first such link is the basket itself. Clicking it moved from the basket to the same basket with a marker on the end, which counted as arriving. Five things then got reported about your checkout — tax shown before payment, nothing pre-ticked, policy links present, the journey completed — from a page that was not it.
FixedAnd the skip link is not your checkout button
When that failed, the next attempt matched on the words in a control. In a browser the address of a link like “Skip to content” is the whole page address, so on that same basket every in-page link matched the word “checkout” too. One shop had six of them, and the one chosen was a skip link one pixel across, while the real button sat further down the page. The scan now ignores anything that points back at the page it is on, and prefers a control a shopper could actually press.
ImprovedWhat the two shops get now
Both reach their real checkout. One went from “could not determine whether guest checkout is available” to a plain pass. The other’s checkout turned out to demand a company name as a required field, which Google’s checkout rules say must be optional for ordinary shoppers — a real finding that was invisible while the journey stopped at the basket. Three shops that were already reaching their checkout are unchanged.
NoteOne of these fixes only worked because of the other
Refusing the basket’s own “edit this item” link was tried first on its own and measured: it made things worse, sending the scan to a news page, because the step it fell back to was still choosing skip links. It was reverted, unshipped, and tried again only once the second fix was in. Both are in now, and both were checked against five live shops before shipping.
Update 8.3

The waiting screen tells the truth about the wait

Two numbers on that screen were typed in by hand rather than measured, and one of them could have told you your scan had died while it was still running.

FixedA scan that is still working is no longer called interrupted
A background job looks for scans that have stopped and marks them so you are not left staring at a frozen bar. It called a scan abandoned after ten minutes — while the scan itself was allowed eleven. A slow store could therefore be told “Scan was interrupted. Please try again”, have its charges refunded and its totals cleared, and then finish half a minute later and deliver a real report anyway. The cut-off now comes from the scan’s own limit rather than a second number typed beside it, so a scan is only called abandoned once nothing could still be working on it.
ImprovedAnd a stopped scan clears faster
That job used to look every five minutes; it now looks every minute. Moving the cut-off later without that would have made you wait longer, not less. Worst case for a frozen bar is thirteen minutes instead of fifteen — and no scan that was still working gets killed on the way.
ImprovedThe time estimate is measured, and says so
Before the first pass lands the screen has nothing to project from, so it starts from a typical scan length. That figure was typed in as a hundred and sixty-five seconds, next to a note about ten scans nobody could look up. Measured again this morning across a dozen real scans: the middle is a hundred and thirty-six seconds, the range a hundred and fifteen to two hundred and one. The screen now reads that measurement from a file that records what was counted, when, and how to count it again — and the build fails if the two ever drift apart.
Update 8.2

When your own bot protection answers, the report stops describing your cart

One shop in this round answers its cart with a single sentence from its security layer: “Your connection needs to be verified before you can proceed.” The report read that sentence as the cart and published four findings about it, two of them stated as facts about the shop.

FixedA verification page is not an empty cart
The homepage has been protected from this since last year — if the storefront serves our browser a queue page or a security check, the scan says so and stops, because unreadable is not the same as absent. The cart never asked the same question. So a shop whose security layer challenged us got “Successfully navigated add-to-cart to checkout flow”, “No returns, privacy or terms links found in the checkout flow” and “No tax or VAT mention found in the checkout flow” — the last two written as findings about the shop, from a page with one sentence on it.
FixedThose rows now name the cause, and cost you nothing
They read: the store’s own bot protection answered instead of the cart, so this could not be observed — a limit of the scan, not a fault found in your store — and they are marked not-checked, which keeps them out of your score entirely. Nothing there needs fixing; a shop with a security layer in front of its cart is doing something sensible.
NoteWhat was NOT quieted
If something really was seen, it is still reported. A pre-selected paid add-on found before the challenge is still named, a payment control that was observed still passes, and a shop that genuinely reached its checkout still gets its plain pass. This change removes claims about pages nobody read; it removes nothing that was actually looked at.
Update 8.1

If your shop asks for a password, the report stops saying it saw a checkout

One shop in this round sends the shopper to a sign-in page when they press Checkout. The scan read that sign-in page as the checkout and published five passes about it — then said it could not tell whether guest checkout was available, on a page that answers the question outright.

FixedA sign-in page is not a checkout
A sign-in page carries your site header, and your site header carries the basket total. That was enough for the scan: an amount on the page and an email box in the login form, and it believed it was standing in your checkout. So “tax shown before payment”, “no pre-selected paid add-ons”, “policy links present in checkout” and “checkout reached” were all published as passes about a page nobody had opened.
FixedThose four rows now say they could not look
They read: the store asked for an account password before showing a checkout, so this could not be observed — a limit of the scan, not a fault found in your store — and they are marked not-checked, so they cost you nothing in the score. A gap of ours has never been allowed to read as a finding about you, and it must not quietly read as a clean result either.
ImprovedAnd the question that page does answer, gets answered
“Guest checkout available” used to read “could not determine”. It now says the checkout appears to require an account, with the rule Google actually applies: a required sign-up is permitted when it is straightforward, free, and needs no app download, and a heavy one at the checkout is treated as an unnecessary barrier. Read from the page’s structure rather than its wording, so a shop that says “Anmelden” or “Se connecter” is read the same as one that says “Sign in”.
NoteThe obvious version of this rule was wrong
Plenty of real checkouts offer a password box on their first step, beside the guest flow — two in the group measured for this change do exactly that. A rule of “password field, therefore sign-in wall” would have taken their checkout rows away. What marks the real wall is that the shopper was SENT there: the address they were heading to is left behind in the link, which is a habit of the software rather than a phrase in any language.
Update 8.0

Your sitemap writes “www”, your shop answers without it

Two shops in this round listed their whole catalogue in a sitemap and got a report with no product page in it at all — no price, no availability, no basket, no checkout. The scan had thrown every one of those addresses away before opening a single one.

FixedOne shop, written two ways, is still one shop
A sitemap usually writes the canonical address, and plenty of shops answer at the other form — one with “www”, one without. The scan compared the two spellings letter by letter, decided the sitemap belonged to somebody else, and dropped every address in it. One shop lost all of its listed addresses that way; another lost all eleven hundred and fifty-eight. Both now reach a real product page, in a real browser, and everything downstream of it comes back.
FixedA checkout on your own subdomain is your checkout
Plenty of shops send the shopper to checkout, secure or pay at their own address for the final step. The same letter-by-letter comparison called that a different merchant and withheld the whole “we walked your checkout” proof, even though the walk had happened. The test is now the one the rest of the scan already used for deciding what belongs to you — so your own subdomains count, and a checkout hosted on somebody else’s domain still does not.
NoteThe same question, asked eight different ways
“Is this address part of the shop being scanned?” was written out by hand in eight places, and they had drifted. It is one answer now, in one place, and a test fails the build if a ninth copy appears. A sitemap is still not a trusted document: an address on a genuinely different domain, or a neighbouring shop on a shared platform, is refused exactly as before.
Update 7.9

Your returns policy is read in your own language

A Dutch shop states who pays return postage and how long a refund takes, in two plain sentences on its returns page. The report said it could determine neither, and warned the shop twice.

FixedWho pays return postage, in Dutch
The page says “Retourkosten zijn voor eigen rekening” — return costs are yours — and says it twice. The word list that answers this question was English only, while the list that reads your return WINDOW had already learned other languages and read the same page perfectly. One question, several word lists, and only some of them were ever taught a second language.
FixedHow long a refund takes, in Dutch — and in ordinary English
The same page says “Binnen 14 dagen na aanmelding ontvang je je aankoopbedrag terug”. Three separate rules had to agree before that could be published: the words that find the sentence, the rule that asks whether a refund really owns the number, and the one that decides between a refund clock and a return deadline in a sentence containing both. Found on the way: “Refunds are issued within 5 business days” and “We will refund you within 14 days” were missed in English too.
NoteOnly where there is a real shop to check it against
Dutch was added because a real shop proved it. Other languages are left alone until one does: the opposite mistake — telling you that you state something you do not — is the one worth avoiding, and guessing at foreign legal wording is how that happens. A cancellation window, a delivery promise and store credit are all still refused as refund clocks.
Update 7.8

Your checkout was being read with one eye shut

The scan opens your checkout and looks at it: pre-ticked paid extras, what it demands from you, how you can pay. That reading had been failing silently, and one line of your report was passing shops on the strength of it.

FixedA whole reading of your checkout had been failing in silence
One pattern in that code was written in a way the browser refuses, and the error was being caught and ignored. So the reading returned nothing — and “No pre-selected paid add-ons detected” was published as a pass built on it, because an empty list looks exactly like a clean shop. It is fixed, and a test now calls that reading directly, since a swallowed error can never show up anywhere else.
FixedCard fields live in the payment company’s frame now, not in your page
Modern checkouts keep the card number, expiry and security code inside frames hosted by the payment processor, and the wallet buttons too. The scan only looked at one attribute of those frames, against a list of company names. It now reads what a payment frame says about itself — so a processor nobody has listed still counts. Both shops in the test group went from “could not verify a payment method” to a pass naming the frame.
FixedA Dutch checkout showing its VAT
One shop’s checkout prints “Inclusief € 2,95 btw” — the tax, itemised, exactly as a shopper should see it before paying. The report said no tax was mentioned, because the phrase it knew could not survive an amount standing between the two words. A tax word beside an amount now counts, in every language the rest of the scan reads.
Update 7.7

The price check could never say yes

The check that compares your product page price against what your basket charges is the one this scanner is built around. It could confirm a match — and then withhold the answer anyway, because of a test that was asking the wrong question.

FixedA checkout that has not asked where to ship is still a checkout
Before publishing that your prices agree, the scan requires proof that it really walked the journey — product, basket, checkout, same shop. One part of that proof was borrowed from a test written for a different purpose: how long to wait for a slow checkout to finish drawing itself. That test looks for a tax or delivery line with an amount on it, which a first-step checkout cannot have, because nobody has said where to ship yet. Measured on two real checkouts on the shops’ own domains, each with an email field, a payment field and a checkout form: both failed it. So the answer was withheld with wording that reads like our own doubt, about shops where everything worked.
FixedA basket total in your own language
The same test looked for the words “order summary”, “subtotal” or “total”. A Dutch checkout says “Totaal”, which is not the word “total” to a computer. It now reads the bottom line in every language the rest of the scan reads — one list, shared, so the two halves cannot drift apart again.
NoteWhat it does not do
A checkout step with no money on it anywhere is still not proof we reached a checkout — one shop in the test group puts its basket total on a later step, and the scan says so rather than guessing. Three shops that match exactly can now be told they match, which none of them could before.
Update 7.6

The scan was emptying the basket it had just filled

After pressing Add to cart the scan opens your basket to see what is in it. On one shop it opened the wrong link — the remove control — and then reported an empty basket. On another it compared your product price against a total with postage in it and called that a price mismatch.

FixedA link that changes your basket is not a link to your basket
Your basket and the controls that empty it live at addresses that look alike — the remove control in a cart drawer is usually the basket address with a quantity of zero on the end. The scan was following the first one it found, which threw away the item it had just added, and then reported that nothing was in the basket. Every platform does this the same way, so the rule covers all of them: an address that tells the basket to change is not the basket.
FixedA total with postage in it is not the price of your product
One shop’s basket reads: one item 13,95, delivery 5,00, total 18,95. The only figure labelled as payable is the total, so the scan compared 18,95 against the 13,95 on the product page and reported a price mismatch — against a shop charging exactly what it advertises, with the postage printed on its own line. Where the arithmetic agrees, the postage is subtracted and the comparison is made against what your product actually costs.
NoteWhy this only turned up now
Both were hidden behind an earlier fault: the basket check was failing for other reasons, and a check that never runs cannot be wrong. Six shops in the test group now go all the way from the product page to the checkout, and all six agree on the price.
Update 7.5

Your basket was read as empty when it was not

After the scan presses Add to cart it opens your basket and checks what is in it. That check is what unlocks the comparison between your page price and your cart price — and it was failing in three ways, each of which quietly withheld the answer.

FixedA basket priced in złoty, kroner or forint counted as empty
The check carried its own short list of currencies — five symbols and seven codes. A basket priced in anything else contained no money as far as it was concerned, so the line did not count and the basket read as empty. It now reads the same currency list as the rest of the scan.
FixedA basket line is whatever holds the quantity box
The check looked for your basket line by name, and a theme that calls its line something else was invisible to it — on one shop the line was on screen with the product title and the price beside it. Every basket on every platform has one thing in common: a box for how many you want. The line is now found from there, whatever it is called.
FixedThe basket is waited for, not asked once
A basket drawn by the shop’s own scripts is usually still empty a second after the page loads, and the check was taken at that moment. It now waits for the basket to answer, and gives up after a few seconds rather than sleeping longer on every shop.
Update 7.4

The scan was hiding your buy button before it looked for it

Before photographing your product page, the scan hides cookie walls and pop-ups so the picture shows your shop rather than a dialog. The rule for what counts as a wall was far too broad — and it ran before the scan looked at the page, not after.

FixedA pinned column is part of your page, not a wall over it
Anything pinned in place and covering a fifth of the screen was hidden, and modern product pages pin the column holding the title, the price and Add to cart while the photos scroll. Measured across twenty-three shops, four lost part or all of their product reading this way — and on two of them the scan went on to record that there was no way to buy the item at all. That is not silence, it is a claim, and it was about a page the scan had blanked itself.
FixedA box holding your heading or your buy button is never hidden
A wall covers your content; it does not contain it. Whatever a box is pinned or floated with, if your page heading or something that says it adds to a basket is inside it, it stays.
NoteReal walls are still removed
Checked in both directions on the same shops: the cookie dialog and the consent backdrop that prompted this feature are still hidden before the photograph, and every one of the twenty-three shops now reads the same after the sweep as before it. One thing did stop being reported: a pinned announcement bar that scrolls with the page was the only “pop-up” found across the whole group, and it never was one.
Update 7.3

Seven thousand products in the sitemap, and none the scan could see

One shop in the test group lists 7,566 pages in its sitemap and links only to category pages from its homepage. Its product addresses are plain words — nothing in them says “product” — so every way the scan had of finding a product page came back empty and the shop got no product checks at all.

FixedWhen nothing else is left, the sitemap is worth a guess
If no page on your site announces itself as a product, the scan now takes a plausible address from your sitemap, opens it, and keeps it only if that page really does show a product or a way to buy. If it does not, the scan keeps what it had. This only runs when there is no other candidate of any kind — not even a category page — and only the part of the scan that can open the page and check gets to use it.
FixedYour homepage under another name is not a product page
The scan already refused to treat your root address as a product. Addresses like /home or /index.html walked straight past that, and grading a homepage as a product page produces a cascade of findings about a missing price and missing product data that were never true of it.
NoteMeasured on six shops that had no product page
One now has a verified product page it never had. The rest are unchanged: two answer the sitemap request with a bot challenge, one lists only blog posts, and one is a single-page shop whose products are not separate addresses at all.
Update 7.2

Which block is the product, and which number is the price

Two more shops in the test group were getting no product answers at all. One has no page heading for the scan to work from; the other prints its old price beside the one it charges, with nothing in the markup to say which is which.

FixedA block whose only buttons lead to other products is not your product
When a page has no heading, the scan picks the product area from the page structure alone, and it needed exactly one candidate or it gave up. One shop has two: the block with its buy button, and a block of four “more info” tiles leading to other products. The same test that stops a recommendation strip supplying your price now tells those apart, so that shop went from no answers to a working buy button and 79,20 €.
FixedA price the shop has crossed off is not the price
Old prices are not always struck through in the markup — sometimes the only clue is the name of the box. Those names are now read, and the number you actually charge is the one the scan compares against your checkout. This matters because reading the wrong one produces a price-mismatch finding that is not true.
NoteMatched as words, not as letters
The first attempt matched “old-price” anywhere in a name, and one shop’s price box is called “hold-price” — it lost its price entirely. Caught by re-reading all twenty-three shops in the test group before shipping; after the fix every one of them reads exactly what it did before.
Update 7.1

A link that says “product” beats one that merely looks like it

To check a product page, the scan first has to find one. It picked the first three product-shaped links on your homepage in the order they appear — and your navigation is at the top of every page, above your products.

FixedCategory links stop outranking product links
Some link rules name a product route outright; others recognise a shape, like an address ending in a numbered file. The shape rules are needed, and on some platforms a category address has the same shape as a product one — the difference is a single letter. The scan now looks further down the page and prefers a link that names itself a product. Nothing is excluded: a shaped link is still a candidate, it just no longer wins by being higher up.
NoteMeasured on eighteen shops, one version per run
Seventeen picked the same page as before. One improved: the scan had been examining a club information page and now examines a real product with a working buy button. None got worse.
NoteWhat is still not solved
Two shops in the group link to no product at all from their homepage — only to categories, which link to further categories. That is a different problem and their reports already withhold every product answer rather than guessing.
Update 7.0

A rule about products has to name something smaller than the page

The scan keeps two lists of names: the ones themes use for “this is the product” and the ones they use for “these are other products”. Both are meant to describe a block inside your page. On two shops they matched the page itself, and both shops lost their whole product check.

FixedA theme setting on your page does not make every heading a recommendation
One shop’s builder writes its theme settings onto the page itself, and one of those settings is named after the related-products feature. Every heading on the page then looked like it sat inside a recommendation block, so the scan found no product title, chose no product area, and reported no price and no way to buy on a page with a working Add to Cart. It now reads $10.00 and marks that button.
FixedThe page itself is never the product
Another shop marks the whole document as a product-details page, which is a perfectly ordinary thing for a theme to do. The scan took that literally: the entire page became the product, and every real product block inside it was therefore a different product — including the one holding the buy button. That page had been reporting no way to buy at all, which is worse than reporting nothing, because “no way to buy” is a claim.
NoteThird time in two days
The same mistake produced the sidebar bug in 6.6 and a fix earlier the same day where a product title could be treated as the product itself. The lists now refuse anything document-sized, in one place, and a test fails if any future rule skips it.
Update 6.9

A shelf of products is not a product

The scan checks the page it picked really is a product page before it judges anything on it. One of the two ways it checks — does the page’s own structured data say “product” — is true of a category page too, because every tile in the grid carries its own product markup.

FixedA page that declares many products and is named after none of them is a listing
Two shops in the test group were being examined on a category page: one declared seventeen different products under the heading “Winter Dog Boots”, the other twenty under “Model Railroading”. A product page declares the thing it is about — across twenty-one real ones, every product declared was named by the page’s own heading or title, including a page declaring twenty-one colourways of the same yarn.
NoteOne declaration is never enough to judge
Plenty of shops name a product one way in the page heading and another in the markup. That says nothing either way, so the rule needs at least two declarations before it will call a page a listing — and a page with a working Add to cart is still accepted on that alone.
NoteWhat this does and does not change today
Rejecting a page only sends the scan looking for a better one; if it cannot find one, the same page is still captured, so no shop loses anything it had. On the two shops above the deeper crawl finds nothing better — their homepages link only to more categories — and their reports already withhold every product-page answer rather than guessing at one.
Update 6.8

Two ways a price could be read ten times too high

Both were found by a new check that compares the price the scan reads against the price your page declares in its own structured data. Both fed the comparison between your page price and your checkout price — the one place a misreading becomes a public accusation.

FixedCents in their own element belong to the pounds in front of them
One shop prints the whole number and the cents as two separate pieces, which is how a great many themes style a price when the cents are smaller or raised. Read as text that comes out as “8, 95 €”, and the scan took the first amount it could see: 95. The shop charges 8,95.
FixedThe number stops where the price stops
Another shop prints “$39.95 10+ Available Online” in a single line, and the stock count was swallowed into the number, giving 39.951. A price has a grammar — thousands come in threes, the pence come last, and nothing follows them — and the scan now holds to it. Prices written 1 299,00 or 1.455,00 or 395,000 read exactly as before.
NoteWhat the new check can and cannot see
Of fourteen shops it was run against, only two declared a price in their structured data that could be compared at all. It is a useful cross-check where it applies and it is not a measure of anything on its own — most shops simply do not publish that number.
Update 6.7

Your price is read however your shop writes it

The scan looked for a short list of exact names for the price box. Shops that name it anything else — or print the number with no currency sign — came back with no price at all, and the check that compares your page price against your checkout price was recorded as not checked.

FixedThe price box is found by what it is called, not by an exact match
Two shops in the test group had a price on screen the scan could not see. One names the box with a longer compound name; the other hangs the price off a data attribute and leaves the class empty, so no name rule could ever have matched it. The scan now treats “price” as a word inside the name, however the name is joined up — while a name that merely contains those letters, like “priceless” or “pricing”, is still not a price.
FixedA price with no currency sign is still a price
One shop prints 129,95 with the euro sign nowhere in the text of the page — not in the box, not beside it, not even drawn in by the stylesheet. A bare number is now accepted, but only from a box named as a price, only when the text is nothing but the number, and only when nothing else in the product area carries a sign. Wherever your shop does print its symbol, a signed price always wins.
FixedThe per-kilogram figure is never your price
Shops selling by weight print both, and the per-unit one is the larger number. Reading it would have compared your checkout against a price you do not charge and reported a mismatch that is not there. Measurement units only — if you price something “per item” or “each”, that is still your price.
NoteMeasured on thirteen shops
Three shops gain a price they never had. One had been reading a neighbouring product’s price and now reads its own. Nine are unchanged.
Update 6.6

The scan reads your product, not the ones advertised beside it

One shop in the test group shows a strip of five other products inside its own product block. The scan took one of their buy buttons and one of their prices — it reported a price four times the real one, and the button it marked belonged to a different product entirely.

FixedA strip of other products cannot supply your price or your button
The strip carried no name the scan could recognise — nothing saying related, recommended or upsell — so every rule it had left the strip alone. It is now recognised by its shape instead: several identical blocks side by side, each holding something to buy, each linking to its own product page. A list of your own variants repeats in the same way and is kept, because a variant is not a separate page and carries no link to one.
FixedA sidebar is not somebody else’s product
Any block your theme marks as a sidebar was treated as a run of other products. That is how themes describe a purchase column, and on the same shop it held the price, the quantity buttons, Add to cart and the wishlist link — all four thrown away. The page ended up reporting five ways to buy, not one of which was that shop’s own.
NoteWhy this one matters more than a wrong number
The scan presses the button it marked to see what the basket does. Pressing a neighbouring product’s button puts a different item in the basket, and the price comparison then reports a mismatch that was never on your page. That shop now shows its own price and its own four controls.
Update 6.5

The product area now stretches far enough to include your price

The scan decides which part of your page is the product, then reads the price from inside it. It stopped as soon as it found the buy button — so on shops that put the price in a neighbouring block, it found the button and no price.

FixedThe product area grows until it holds the price as well as the button
One shop in the test group had twelve prices on the page and none of them inside the area the scan had settled on. Without a readable price, the check that compares your page price against your checkout price cannot run at all and is recorded as not checked — so a shop could be paying for a scan and getting no answer on the thing that matters most.
NoteIt stops as soon as both are present
A wider area than necessary is how a neighbouring product’s price gets picked up by mistake, so the area stops growing the moment it contains both your buy button and a price. A shop whose product block already holds both is untouched.
NoteMeasured on seven shops
One shop gains a price, and the button it identifies is unchanged. Six are unchanged, including four that already read prices correctly. Two shops in the group still show no price for reasons we have measured and not yet fixed.
Update 6.4

Prices in złoty, kroner, koruna and forint are readable now

To check that the price you advertise matches the price you charge, the scan has to read the price on your product page. It knew the three-letter codes — PLN, SEK, DKK — which shops almost never display, and not the symbols they actually print.

FixedThe price reader now knows the symbols, not just the codes
A shop pricing in “9,80 zł” had no readable price at all, so the comparison between your page price and your checkout price could not run and was recorded as not checked. The rest of the scan already carried a full currency list — every symbol, every code, and the unit words that are not symbols. The price reader simply never used it. It does now.
NoteCareful about what counts as a price
Currency words like “kr” and “lei” also appear in ordinary sentences, so they only count when a number sits directly against them. A bare number is never treated as a price — otherwise a quantity, a star rating or a product code could be compared against your checkout total and reported as a mismatch.
NoteMeasured on thirteen shops
One shop gains a readable price. Twelve are unchanged. Three shops in the group still show no price for a different reason we have measured and not yet fixed: their price sits outside the part of the page the scan treats as the product.
Update 6.3

A buy button thrown away for belonging to the wrong part of the page

To judge whether an item can be bought, the scan works out which part of the page is the product. On some shops it drew that boundary around the whole page, then discarded the shop’s own buy button for sitting in a section it had decided belonged to something else.

FixedThe product area can now shrink, not only grow
A recent change taught the scan to widen the product area when the buy button sat just outside it. Nothing taught it to narrow. Where a shop’s heading sits outside its product block — common on site builders — the scan settled on the whole page and then treated the real product block as if it were a different product. It now narrows to that block, and only when nothing would be left behind.
FixedA rule that would discard every buy button now stands aside
The scan ignores buy buttons inside “you may also like” cards, so a recommendation cannot be mistaken for the item you are selling. One shop wraps its own buy area in the same kind of card, so that rule discarded the only buy button on a page with no other product on it. The rule now yields when applying it would leave nothing at all — a real recommendation grid always leaves the main button outside the cards, so it still works there.
NoteNarrowing alone fixed nothing
Correcting the product area changed the boundary and changed no verdict: the shop was still reported as having no way to buy, because the second rule then discarded the button. Both were needed. We mention it because a change that visibly does something is easy to mistake for a change that helps.
NoteMeasured on twelve shops
One shop moves from “no purchase control” to a recognised buy button. The other eleven are unchanged, including one whose product area contains seven nested product blocks and is deliberately left alone.
Update 6.2

Two languages the stock check could not read

The scan works out whether an item can be bought by finding the buy button. One part of the scan had its own private list of what a buy button says — and that list was missing Polish and Danish.

FixedOne list of what a buy button says, shared by the whole scan
The rest of the scan already recognised “Dodaj do koszyka” and “Tilføj til Kurv”. The stock check did not, because it carried an older copy of the list. A Polish shop with a working buy button was reported as having none. Both halves now read the same list, so a language added once is understood everywhere.
FixedThe word “basket” on its own is not a buy button
The old copy also treated a bare “Winkelwagen” as a buy button. That is the link to your basket, not a way to add to it — pressing it arrives at an empty basket, which the scan would then judge. The shared list requires a word beside the noun, so “In Winkelwagen” counts and “Winkelwagen” alone does not.
NoteChecked against real buttons, not invented ones
Compared across 1,525 real button labels collected from 23 shops. The shared list gains exactly those two buy buttons and gives up exactly one match, the bare basket link. Six shops in six languages that already worked are unchanged.
Update 6.1

We now open the page before deciding it is a product

The scan picks one product page to photograph and to test adding to the basket. It chose that page by its web address. On shops where the address gives nothing away — often simply because it is not in English — it picked a returns page or a terms page and spent the whole visual half of the scan there.

FixedThe page is opened and checked, not guessed from its address
A page now counts as a product page if its own markup says so, or if it shows a real price beside a working buy button. Either is enough, and that matters both ways: shops with no markup at all still count because they visibly sell, and a product whose buy button we cannot see still counts because its markup says what it is.
FixedWhen the first choice is wrong, the deeper search is asked
A deeper search for product pages already ran in another part of the scan, but only when nothing at all had been found — never when something wrong had been found. It is now asked in both cases. Two shops in the test group moved from a policy page to a genuine product page, one Dutch and one with a Dutch address we had no way to read.
NoteIt can only improve, never worsen
The deeper search’s answer is checked the same way before it is used. On one shop that search returned job vacancy pages; they failed the check and the scan kept what it had. Shops whose front page already leads to a product are untouched and pay nothing for any of this — confirmed on three of them.
Update 6.0

Some shops were scanned without a product page at all

The scan opens one of your product pages to photograph it, read it, and test adding it to the basket. On some shops it never found one — even though another part of the same scan had already found one.

FixedThe two halves of the scan now share what they find
Finding a product page is done two ways: one reads the links on your home page, the other crawls deeper. Only the deeper one runs for the written checks. The part that takes the photographs and tests your basket used the shallower one, and when that came back empty it simply went without — no product photograph, no visual check, no basket test. It now asks the deeper search when its own comes back empty.
NoteWhat it costs you
Nothing, unless it is needed. The deeper search only runs for shops whose home page did not lead us to a product, so a shop that links products from its front page is scanned exactly as before — verified unchanged on shops that already worked.
NoteMeasured on eight shops that had no product page
Six now get one, and five of those six are confirmed product pages by the shop’s own markup. The sixth is a category page, which the written checks already refuse to grade as a product. Two shops still get nothing: one refuses automated visits, and one appears to be a blog rather than a shop. We would rather report five than round it to six.
Update 5.9

We were pressing the wrong button

To test your checkout, the scan puts one item in the basket. It had been pressing whichever control came first in the page — which on many shops is the quantity minus button sitting next to the real one.

FixedThe scan now presses the button that adds to the basket
The control to press was chosen by position in the page rather than by what it does. A quantity stepper sits inside the same form as the buy button and comes first, so on several shops the scan pressed “minus”, or an unlabelled button, or the link to the basket, or a form wrapper that cannot be pressed at all. It then reported that it reached checkout with an empty basket — which was true, and was our fault, not yours.
FixedWhat the control does now matters more than what it says
The strongest evidence that a control adds to the basket is that it submits a form pointing at your cart. That now counts for more than the wording, so a button saying “Pre-order”, “Vorbestellen” or anything else we have never seen is still found. Weighting the wording first picked a “buy the whole bundle” widget on one shop, which would have filled the basket with extra items and then accused the shop of changing its prices at checkout.
NoteMeasured on twelve shops
Five of the twelve were pressing the wrong control. All five now reach checkout with a real item in the basket and a readable total. The seven that were already correct are unchanged. Before this the whole test group had one shop with a confirmed non-empty basket.
Update 5.8

When the buy button sits outside the product block

To judge whether an item can be bought, the scan first works out which part of the page is the product. Some shops put the buy button just outside that part — and the scan then reported a working shop as having no way to buy.

FixedThe product area now stretches to include the buy button
When a shop marks up a product block, the scan uses it. If the buy form sits beside that block rather than inside it, the scan used to look inside the block, find nothing, and record the item as having no purchase control — on a page where the button works perfectly. The product area now grows outwards until it contains the buy button.
FixedGrowing outwards no longer loses your price
The first attempt at this found the button by looking somewhere else on the page entirely, and lost the price in the process — which would have broken the check that compares your product price against the price at checkout. One repair should not cost another. The product area now keeps everything it already had: your title, your price, and now the button.
NoteA recommended product still cannot supply your price
A wider product area could pick up a “you may also like” card sitting next to it. It does not. Anything belonging to another product on the page is still excluded, so a recommendation cannot lend its price or its buy button to the item being judged.
NoteMeasured, and not finished
Checked against twelve shops before and after, each on a fresh page load. One shop that was wrongly reported as having no purchase control now reads correctly, with its price intact, and the eight already-correct shops are unchanged. Three shops in the group are still wrong for reasons this does not cover, and we would rather say so than round it up.
Update 5.7

The malware check runs now, and says which of three things happened

This scan asks Google whether your site is flagged for malware, phishing or unwanted software. Until today it could not run at all — the key it needs was never configured — and the moment it ran it showed a second problem underneath.

FixedThe check can actually run
The malware and phishing lookup had never once run in this product’s life. Reports said so rather than implying a clean result, which was the right thing to do, but it meant nobody was getting the check. It runs now.
FixedA clean result no longer counts against you
Every outcome came back as the same kind of unresolved warning. A shop Google had nothing against was given a minor issue — with no fix attached, because there was nothing to fix — and it cost score. A clean lookup is now recorded as a pass, and costs nothing.
FixedA flagged shop is treated as serious
A shop Google had actually flagged for malware produced that same minor warning: the worst thing this scan can find, ranked level with a clean result and with a lookup that timed out. Merchant Center requires a shop to be free of malware, phishing and unwanted software, so a flagged shop is now a critical failure. A lookup that could not complete is still recorded as not checked and still costs nothing.
NoteWhat the result does and does not mean
It is one lookup against the address we scanned, not every page of your shop, and not a decision by Merchant Center. A clean answer means Google’s Safe Browsing list has nothing against that address today.
Update 5.6

We were checking your search page instead of a product

The scan picks one product page to examine in detail. On some shops it picked a page that was not a product at all — a search page, a category, a policy page — and then ran every product check against it.

FixedA store’s own utility pages are no longer mistaken for products
Addresses like /products/search or /products/cart look exactly like a product address, so the scan accepted one as the product to examine. It now recognises a shop’s own search, basket, account and checkout routes and passes over them. A real product whose name merely begins with one of those words — /products/search-and-rescue-tshirt — is unaffected, which is why this had to be done carefully rather than by keyword.
FixedThe two halves of the scan now share one list
This was already fixed in July, in the part of the scan that crawls for product pages. The part that chooses the page to open and photograph had its own separate copy of the rule and never received it, so the problem stayed live on the pages a merchant actually sees in the report. Both halves now read the same list, so a fix to one cannot miss the other.
NoteMeasured, and not finished
Across 26 shops, 18 produced a page to examine and 4 of those were not product pages. One of the four is fixed by this change. The other three were picked because their address gives nothing away in the shop’s own language — a Dutch returns page, a Dutch terms page, a category. Naming the page correctly needs us to look at the page rather than read its address, and that is the next piece of work.
Update 5.5

Two reasons the pop-up was still there after we closed it

The change in 5.4 was right about what to do and wrong about how to check it. Both mistakes had the same effect: the scan decided the way was clear, clicked, and got nothing.

FixedWe were sizing up the wrong thing
To decide whether something was really in the way, the scan measured the box the pop-up sits inside rather than the pop-up itself. Plenty of shops wrap a pop-up in a container with no height of its own, and the scan then concluded that nothing was covering the button — while the shopper was looking straight at it. It now measures whatever is actually over the button.
FixedWe did not wait for it to go
The scan pressed the pop-up’s close button and asked in the same instant whether it had gone. Pop-ups fade out over a moment, so the answer was always no, and the scan spent every attempt pressing the same button instead of trying another way. It now presses once, waits for the pop-up to leave, and only then decides what to do next.
NoteWhat this is worth, measured
Checked against the same shops before and after, each on a fresh page load: two shops that could not get past a pop-up now add to the basket, and the shops that already worked are unaffected. That is a small number honestly counted rather than a large one we cannot stand behind.
Update 5.4

Getting past the pop-up that covers your buy button

The scan adds an item to your basket to test checkout. On some shops a pop-up sits over the buy button, the click never lands, and the report then said we could not find the button — when we had found it perfectly.

FixedA pop-up standing in the way
The scan now closes whatever is covering the button before it clicks, the way a shopper would — using the pop-up’s own close or dismiss control. Cookie notices, country-redirect pop-ups and newsletter sign-ups all cause the same failure, so it works on the shape of the thing rather than on any one kind.
NoteWe look for the way out, not the “yes”
Where a pop-up offers a choice, the scan takes the close or decline option first — “continue without”, “only necessary”, “no thanks”. Accepting is a last resort, because agreeing to something on your site is not a choice we should make for you. Your basket or checkout panel is never treated as an obstacle.
NoteIt does not fix every case yet
We tested 26 shops that had failed this step. Corrected in 5.5: we first counted five of them as blocked by a pop-up, but two of those were our own mistake — we had checked them against product addresses that no longer exist, so those pages genuinely had no buy button to find. Three were blocked by a pop-up.
Update 5.3

Our own note is no longer shown as a captured quote

A footer finding carried a line describing what our scan did, sitting under “Evidence captured” where you would expect wording taken from your page.

FixedA note about the scan, filed as evidence
The line read “Static-text cross-check: contact details present in the rendered footer text”. It appeared on 121 stored reports and there is nothing in it you could go and look at. It has been removed from the evidence box.
NoteThe useful part is unchanged
The finding itself still tells you the same thing, and in plainer words: your footer does contain the contact details, and on mobile they are probably folded behind a toggle rather than missing. That note was always there — it was simply being repeated in the wrong place.
Update 5.2

Pointing you at the page a quote actually came from

Some findings quoted wording from one of your policy pages, then listed a different page as the one affected. Open the page named and the quoted wording is not there.

FixedThe wrong page listed beside a quote
We saw a finding quote a shop’s refund policy while naming the shipping page, another quote the terms page while naming an unrelated page, and a third quote the about page while naming the homepage. The quotes were genuine — they were just filed against the wrong address.
ChangedWhy it happened to more than three shops
Thirty of these checks never recorded which page they had read, so the report fell back to whichever page the scan happened to be on at that moment. When those matched, the result looked right by luck. All thirty now record the page the wording came from.
Update 5.1

Not offering “not found” as evidence

Some findings listed their own conclusion in the evidence box — lines like “Address: not found” or “Cookie usage not mentioned”, shown under “Evidence captured” as though we had quoted them from your page.

FixedA conclusion presented as a quote
The finding already says what is missing in its own sentence. Repeating that underneath as “evidence” proved nothing — the proof of the claim was the claim. Those lines are gone.
NoteWhat we actually found is still there
These lists often mix the two. A finding about your footer might list “Address: not found” beside “Phone: +91 6359 021 222”. The phone number is a real capture and stays; only the “not found” line goes.
NoteYour own wording is never removed
If your policy genuinely says something like “delivery times are not stated for remote areas”, that is your text and it is kept exactly as captured. Only our own fixed conclusion lines are dropped, and each one was checked by hand first.
Update 5.0

Saying whether a quote came from your page or was written about it

Findings from the analysis model show a supporting quote. Some of those quotes are text we located on your page. Some are the model describing what it read. The report showed both the same way.

FixedA description shown as though it were a quote
Every quote is already checked against the text we scraped from your page. Across stored reports, 979 passed that check and 133 did not — and all 133 were still shown under “Evidence captured”. If you went looking for that wording on your page, you would not have found it.
ChangedTwo different labels now
Text we located on your page still reads “Evidence captured”. Text the model wrote about your page now reads “Summary — not a verbatim quote”, and says plainly that you should check the page itself before acting on it.
NoteNothing was removed
The wording is still shown either way — a summary is useful, it just should not pose as a quote. Findings from the other checks are unaffected; those have always been real captures.
Update 4.9

An empty bracket where a quote should have been

One finding printed a gap in its own sentence. If your shop has a currency switcher, the report may have told you “A currency-switching widget is present ()” — brackets with nothing inside them.

FixedA sentence with a hole in it
The line quotes the wording it found on your switcher. Where that wording could not be read — which is the normal case for an ordinary dropdown, since a closed dropdown has no visible text — it printed the brackets empty anyway. 128 stored reports read like that. The quote is now optional: if there is nothing to quote, the sentence simply does not quote anything.
ChangedReading the switcher properly
The scan now asks the switcher what it says in the order a person would look: its visible text, then whichever currency is currently selected, then its label. So in most cases there is now a real quote where there used to be a gap.
NoteEmpty evidence is not evidence
The same finding also attached an empty quote as its supporting evidence. It no longer attaches anything when there is nothing to attach.
Update 4.8

Advice for things we could not check now reads as a suggestion

When the scan cannot reach one of your pages, it says so and it does not count against your score. But the advice beneath it was still written as though we had looked and found something missing.

FixedBeing told to add something we never managed to read
If your returns page did not load for us, the report still said “State your return window in days” — which reads as though we checked and it was absent. Across stored reports this affected 1,687 lines on fifteen different checks. Those lines now begin by saying the scan could not confirm the current state, and present the advice as something to check rather than a fault to fix.
NoteAdvice we deliberately left alone
Two kinds are unchanged. If something blocked our visit, “make the page reachable to automated crawlers” stays as it is — being blocked is something we genuinely observed. And anything that simply asks you to check for yourself was already honest.
NoteReal findings still say what to do
Where the scan did read your page and found something missing, the advice is unchanged and direct. Only the lines where we could not look were reworded.
Update 4.7

Not blaming your button for a page we were never shown

When the scan could not complete a test purchase, it told you to make sure your Add to Cart button works — even on shops where our browser was blocked at the door and never saw the page at all.

FixedAdvice that assumed your button was broken
That line appeared on 227 stored reports and was the only thing it said. On some of those shops our browser received a completely blank page — no text, no buttons — so there was nothing to judge, and you were being sent to fix something nobody had seen.
ChangedThe report now says which of two things happened
Either the page did not load for our browser — usually bot protection in front of an automated visit, stated plainly as a limit of the scan and not a finding about your shop — or the page loaded and we did not recognise a control on it, in which case the item may simply be unavailable, or the button may be a style we do not read yet. Neither claims your button is broken.
NoteIt never counted against your score
This line was already outside your score, and still is. What changed is that it no longer asks you to fix something we did not observe.
Update 4.6

Reading buy buttons in more languages, and not clicking the wrong one

The scan understood cart wording in some languages when checking a web address, but only a shorter list when reading the button itself. Whether your shop was understood depended on which of the two happened to be looking.

FixedBuy buttons in Danish, Polish, Czech, Swedish, Norwegian, Turkish and Portuguese
A Danish shop with a button reading “Tilføj til Kurv” was missed, while the very same shop writing “Læg i kurv” would have been found — because only that exact phrase was on file. Both parts of the scan now read the same set of cart words.
FixedClicking the basket link instead of adding to it
A button reading just “Warenkorb” or “Koszyk” is the link to your basket, not a way to put something in it. The scan could click that, find an empty basket, and then report the empty basket as a problem with your shop. It now expects a word alongside — “In den Warenkorb”, “Dodaj do koszyka” — before treating something as a buy button.
NoteWhat we checked it against
We collected every visible button from 26 live shops — 1,525 of them — and checked the result. The scan now recognises 12 of those as buy buttons, and all 12 genuinely are.
Update 4.5

Seeing a buy button built the older way

Some shops build their buy button out of a form input rather than a modern button. The scan was not looking at that kind of element at all, so on those shops it reported it could not find a way to buy.

FixedBuy buttons the scan could not see
The scan gathers up everything on the page a shopper could press, then looks for the buy control among them. One older style of element was missing from that list, so a perfectly normal, clearly visible “Add to Cart” button was never even considered. Checked against a live shop using that style: before, the scan found nothing; after, it finds the button.
NoteStill not found on some shops
This does not explain every case. On one shop we looked at there is genuinely no buy control on the page; on another the button says “ORDER HERE”, which we do not yet recognise. We are not adding single words on the strength of one shop — “order” also appears in “order status” and “my orders”, and a careless match there would make things worse.
Update 4.4

Checking a product page, not a list of products

The scan picks one product page to inspect. On some shops it picked a page that lists products instead, then reported that it could not find a buy button — on a page that was never meant to have one.

FixedList pages mistaken for product pages
Addresses ending in things like “list”, “archive”, “filter” or “sort” are pages that show many products, not one. The scan now recognises them and keeps looking for a real product page.
NoteWords we deliberately left alone
Plenty of shops keep their real products under addresses containing “collections”, “catalog” or “category”. Treating those as list pages would make the scan skip real products on a lot of shops, so it does not. We checked this against every product address we hold before deciding.
Update 4.3

Proof for every page a finding names

When the same problem appeared on two pages, the report combined them into one line — listed both page addresses, and then showed the captured wording from only one of them.

FixedA combined finding proved only one of its pages
If the scan found the same issue on two product pages, it showed you one line with both addresses attached. The captured wording underneath came from the first page only. So you could open the second address, see completely different figures, and have nothing in the report that matched. The capture from every page is now included, and each one says which page it came from.
NoteFindings still combine
The same issue on several pages is still one line rather than several — that part was right. What was missing was the evidence for the pages after the first.
Update 4.2

Naming the pages we never looked at

The scan takes pictures of up to eleven page views and reviews them. When a picture was never taken, the report said nothing at all — which reads exactly like “we looked and it was fine”.

FixedPages that were never photographed
If the scan never managed to photograph a page — your checkout, say, or a policy page it could not reach — that page vanished from the report entirely. It was not listed as reviewed and it was not listed as skipped. Your report now names those page views plainly and says nothing about them was examined. It does not count against your score, because the gap is in our scan and not in your shop.
ChangedTwo different gaps, told apart
A page we photographed but could not get an answer about is a different problem from a page we never photographed. The report now distinguishes them instead of reporting one number.
Update 4.1

Saying when we could not check something

A check that could not run used to leave no trace at all — the row simply vanished, and a missing answer looked exactly like a clean one. Two checks were doing that, and one of them had never run in this product’s life.

FixedThe malware and phishing check had never run
This check needs a key from Google to work, and that key was never set up on our side. Instead of saying so, the check returned nothing — and nothing looks identical to “we looked and your shop is clean”. Every report we have ever produced was missing that line, and none of them mentioned it. Your report now states plainly that the check did not run. It does not count against your score, because the gap is ours and not yours.
FixedThe cloaking check could disappear quietly
If that check hit a connection problem it also returned nothing rather than saying it had failed. It now says so. To be straight about the size of this one: it affected 2 scans in 717.
ChangedA “noindex” tag is no longer treated as serious
We were marking a “noindex” tag as a critical problem. On review, that was wrong. Google has to visit a page to read that tag, so it is not blocking Google from reaching your shop — it is a search-listing setting. A robots.txt block is a different thing and is still treated as serious. We still show the observation, because it is worth knowing; it is no longer presented as an emergency.
ChangedOlder reports re-graded
Reports produced before our recent grading change kept their old, harsher labels. We have re-graded every stored report using the current rules. Nothing became more severe; a number of findings became less so.
Update 4.0

Checkout checks that work on more shops

The part of the scan that adds an item to your basket and walks to checkout was failing on a lot of shops — not because those shops had a problem, but because it did not recognise their buttons.

Fixed“Add to shopping cart” was not recognised
The scan looked for the words “add to cart” sitting together. Plain English phrasings like “Add to shopping cart” did not match, and neither did several German, Czech, Dutch, French and Turkish phrasings that were known in some parts of the scan but missing from others. There were four separate lists of what an add-to-cart button looks like and they had drifted apart. There is one now.
FixedThe scan could press the wrong button
While fixing the above we found the scan could match an address form and press its save button, then record that as adding an item to the basket. Any shop with an address, review or add-on form on its product page could have been affected. It now matches the shape of a real basket address rather than looking for letters inside a word.
FixedThe wrong page could be photographed
Part of the scan takes a picture of a product page to review it. On Czech shops it could pick the basket or the login page instead, because that part of the scan was missing the Czech words for them while other parts had them.
FixedBusiness details found, then not used
One check said a shop had business identity markup while a second check, looking at the same page, did not recognise it and quietly did nothing. The two disagreed on 50 of 717 shops. They now read the same definition.
Update 3.9

Not judging a shop on its blog posts

A store with no product pages could have its product checks run against a blog post instead — and be scored on the result. A wrong answer is worse than no answer.

FixedBlog posts treated as product pages
The scan looks for a product page to inspect. It already knew to ignore editorial pages, but it only checked the last part of the address. One store had two blog posts sitting side by side and only one was recognised — the other escaped because it spelled its title with spaces instead of dashes. That store has no product pages at all, so every product check ran against a blog post, and the report said “product pages reachable” and gave a score. Editorial pages are now recognised anywhere in the address.
ChangedWhat happens when there are no product pages
If your store genuinely has no product detail pages, the report now says so plainly instead of inspecting whatever page it could find. That message already existed — the scan simply never got that far.
NoteShop addresses were left alone on purpose
Many stores put products at addresses containing the word “collections”. Treating that word the same way would have made the scan ignore product pages on a very large number of shops, so it is still only recognised when it is the whole address. Every product address we tested behaves exactly as it did before this change.
Update 3.8

Measuring your product photo, not your logo

The scan picks one product image and measures it against Google’s published size rules. On some stores it was picking the shop logo instead — and a logo it cannot measure means no answer at all.

FixedThe wrong image was being measured
There are two places a page can declare its main image, and the scan already knew to skip anything with “logo” in the filename — but only in the second place it looked. If your page declared its image in the first place and that happened to be the logo, the logo won, even when a perfectly good product photo was sitting right there in the second. Logos are often a format with no fixed pixel size, so the measurement failed and the report said nothing at all. Both places now apply the same rule.
FixedReports with no image verdict
Across our stored scans, 46 reports had analysed a product page and still carried no verdict on product image size; 41 of those said nothing whatsoever about product images. On the store that exposed this, the scan now measures the real photo at 800×800 and tells the merchant it is below the recommended size — a real finding they were never given.
NoteWhy image size is worth the trouble
Google publishes a minimum image size and a recommended one, and the minimum rises to 500×500 in January 2027. An image that is too small is a fixable problem, but only if somebody tells you about it.
Update 3.7

When the scan cannot reach your checkout

Some checks can only be made on the checkout page itself. When the scan got as far as the cart but no further, those checks quietly did not happen — and the report never said so.

FixedChecks that need the checkout page
Three things can only be seen once the checkout page actually loads: whether it is served over HTTPS, whether a paid extra is pre-ticked for the customer, and whether a normal payment method is offered. If the scan reached your cart but could not get into checkout, all three were skipped and left no trace. The report did say the checkout could not be entered — it just never said what that cost you. It now names all three, so you know they are unanswered rather than fine.
NoteWhy HTTPS at checkout is the one to care about
A payment page served over plain HTTP is disqualifying on its own, no matter how good the rest of the store is. If the scan could not reach that page, it could not rule that out, and you should know that rather than assume the silence was good news.
Update 3.6

The crawlability answer you were owed

The check that asks whether Google can reach your product and policy pages either said "yes" or said nothing at all. Saying nothing looked the same as saying yes.

FixedA crawlability answer that went missing
This check tells you whether your robots.txt lets Google reach the pages that matter. When it worked it wrote a line saying so. When it could not run — because robots.txt was unreachable, or because the scan had not resolved any product or policy page to test — it wrote nothing, and a report with no line looks exactly like a report with a passing line. Across our stored scans, 84 reports had no crawlability answer at all. It now says which of those happened, and why.
FixedStores with no robots.txt were given no credit
If your store publishes no robots.txt, or an empty one, you are placing no restriction on Google whatsoever — the most permissive setting there is. The scan was throwing that answer away instead of recording it as a pass. Twelve stored reports lost a verdict they had earned. They now get it.
ChangedWhy a missing answer is worth reading
When this check does run it is not a formality: it returns a real problem on roughly one store in fifteen. A blocked product page is invisible to Google no matter how good the rest of the store is, so an unanswered crawlability question is worth knowing about.
Update 3.5

A check that could not finish now says so

Three checks used to disappear from the report when they could not complete. A missing row looks exactly like a passing one, so a scan that never ran a check could still read as clean.

FixedChecks that vanished instead of reporting
The cloaking, malware and certificate checks each run alongside the main scan. If one of them did not come back in time — on a slow connection, or a site that answers twice over — its result was dropped and the report simply had one fewer line. Nothing said so. Across our own stored scans, thirteen full reports had gone out with no cloaking verdict at all, and one of those scored 100 out of 100. Each of the three now writes a line saying it did not finish and why.
ChangedWhat a missing answer does to your score
A check that could not run used to cost nothing, because it left no trace to count. It now counts as unanswered rather than passed, which lowers the score slightly. A scan that could not look at something should not score the same as one that looked and found it clean.
NoteCloaking is the check this matters most for
Cloaking means showing Google something different from what a shopper sees. It is the single thing this scanner exists to catch, and when the check does run it finds a real problem on roughly one store in twenty. That is not a check worth losing quietly.
Update 3.4

Saying only what we can see

Five findings that read as accusations have been withdrawn or reworded, because in each case the scan was claiming more than it had actually checked.

ChangedWhat a policy finding may say
This is a Google Merchant Center scanner. Some policy findings had started commenting on wider retail law instead — "may not comply in some jurisdictions", with no jurisdiction and no law named. You cannot act on that, and it is not the standard your account is judged by. Those are gone. Findings now stay with what is on your page.
FixedLong policy pages called empty
A terms page of nearly nine thousand words was reported as having no terms on it, because it opens with a list of section headings. The scan had already read the whole document. It now checks its own reading before making that claim, so the wording the report happens to use can no longer change the answer.
FixedStores that ship nothing
A store selling only downloads was marked down twice for not stating a delivery time and a shipping cost. Its shipping page said plainly that it ships no physical products. That page had answered the question, and the scan had marked it unanswered.
FixedBlocked crawler checks
When a store's firewall refused our request, the report sometimes called it cloaking — serving different pages to Google than to shoppers. That is a suspension-level accusation, and we were making it from a request that had been turned away. It now says plainly that the comparison could not be made, and points you at Search Console, which asks Google directly.
FixedCrawl-blocking evidence
When robots.txt blocks a page from Google, the report names an example page and the rule blocking it. Those two did not always match, so the rule quoted belonged to a different page. Now the rule shown is the one blocking the page named.
ChangedMissing versus unchecked
A report that said "cannot verify" sometimes meant the opposite — every document had been read and the fact simply was not in any of them. Those now say "not stated", and say the documents were read. Where a page genuinely could not be fetched, the report still says so and does not treat it as missing.
Update 3.3

Your policies, in your language

The scanner can now find and read policy pages in the languages of every market it serves, and it no longer comments on anything outside Google Merchant Center policy.

FixedFinding your policy pages
Eight more languages can now be found, not just read: Arabic, Hebrew, Russian, Ukrainian, Chinese, Indonesian, Malay and Vietnamese. Stores in those markets had policy pages the scanner could understand perfectly well but could never locate, so it reported them as missing. Catalan, Croatian and Slovenian were added at the same time.
AddedLanguage and market coverage
A new page lists every language the scanner reads and every market that covers. It shows two separate things for each language — whether we can find your policy page, and whether we can read it once found — because those can fail independently. The one language we do not yet handle is listed as a gap rather than left out.
ChangedWhat a policy finding may say
This is a Google Merchant Center scanner. Some policy findings had started commenting on wider retail law instead, which is not what we check and not something you can act on. Those are gone. Findings now stick to what is actually on your page: a returns page that will not load, a free-shipping offer contradicted by the costs listed beside it, a refund promised as credit rather than money back.
FixedLong policy pages
A terms page of nearly nine thousand words was reported as having no terms on it, because it opens with a list of section headings. The scanner had already read the whole page. It now trusts what it read.
Update 3.2

Reading the page you actually wrote

The scanner stops contradicting itself: policies it had already found are now read, wording it already understood in one place is understood everywhere, and several accusations it could not support have been withdrawn.

FixedPolicies in your own language
A privacy policy written in Danish, Swedish, Greek, Bulgarian, Turkish, Arabic, Hebrew, Vietnamese, Japanese, Korean, Chinese or a dozen other languages is now read as a real policy. Stores with a complete, compliant privacy page were being told they had none, because the check only recognised English wording. It now reads the words themselves rather than a list of phrases someone remembered to add.
FixedReturn windows
A return window written as "return it within 30 days" is now found. So is one counted from when you bought rather than from when it arrived — the two are different promises and the report no longer mixes them up.
FixedCombined policy documents
If your terms page also contains your returns or privacy terms, that now counts. A small store putting everything in one document was being told the missing policies did not exist, when a shopper could read them perfectly well.
FixedOut-of-stock contradictions
When your structured data says a product is out of stock while the page itself is still selling it, the report now names that contradiction. It used to report an empty catalogue instead, which told you nothing about the actual problem.
FixedProduct pages
A product page is no longer dismissed as a category listing because it happens to show related products underneath. On some stores this silenced an entire layer of checks.
ChangedAccusations we could not support
Three findings have been withdrawn where the evidence never justified them. Cloaking is no longer alleged when our check was simply refused entry. A policy page is no longer called empty when the scanner had already read it. And the word "hurry" in a product name is no longer treated as a countdown-style urgency claim.
FixedProhibited categories
A product is no longer flagged for the very thing it removes. Stain remover, odour eliminator and similar wording were being read as the product containing what they take away.
ChangedRepeatability
One step that identifies your footer links could return a different answer on identical runs, so the same store could pass one scan and fail the next. It is now retried when it leaves something unresolved.
Update 3.1

The right page, and a straight answer

Checks now run against the page they claim to be reading, contact details have to be usable before we publish them, and findings that were being withheld are published again.

FixedContact details
A product code or an example order number can no longer be reported as your support phone. A number has to be labelled as a phone and formatted like one before the report will publish it.
FixedPolicy pages
A product page, a category grid or your homepage is no longer accepted as your privacy policy, contact or shipping page. When the real page cannot be found the report says so, instead of grading the wrong document and reporting whatever it finds there.
FixedProduct identifiers
A GTIN or MPN published on the offer rather than the product is now found. Stores were being told to add an identifier they had already supplied.
ChangedHeld-back findings
Update 3.0 described holding conclusions back unless they came from a narrow set of sources. That behaviour is removed. The scanner publishes every verdict its evidence supports, and says plainly when it could not check something rather than staying silent.
FixedPublished totals
The scan total on our accuracy page was missing every store whose review finished with warnings and no failures. It now counts every completed review.
Update 3.0

Every finding now shows its working

Every active rule now carries a policy class, an official Google source, and a clear evidence boundary. The report can show where a call came from and what would be needed to make it.

ChangedSource gate
Every active check is now tied to an official source. Unsupported heuristics such as WHOIS age and PageSpeed stay out of Merchant Center conclusions.
ChangedRisk versus violation
Clues that still need feed, account, market, or submitted-product context are clearly held for merchant review. They cannot quietly lower the score.
AddedPolicy sources
Report findings carry the official Google source and the evidence required for the adverse conclusion, alongside the captured store evidence.
AddedMerchant checklist
Purchased reports now include a short account-side checklist for the facts only the merchant can confirm, with saved statuses and an exportable record.
Update 2.1

Stronger evidence, fewer wrong calls

Repeat failure patterns became regression tests, and every evidence path got a tighter boundary. The practical result is a report that is harder to fool and easier to challenge.

ChangedVisual evidence
A visual finding now has to match the exact page capture, URL, viewport, visible text or accessibility snapshot. If the visual model cannot point back to that evidence, the report holds the claim back.
ChangedFact decisions
Product rules, category exceptions and store-wide promises now stay in their proper scope. When two trustworthy sources disagree, the report says it could not verify the answer instead of picking a winner.
ChangedReplay coverage
Historical evidence now replays through the repaired scanner before a fresh benchmark begins, so old failure patterns have to stay fixed.
FixedTruth boundary
Domain age, footer phone placement and optional structured data are no longer dressed up as universal Google violations. Sales and visitor counters now ask for proof instead of declaring fraud from pixels alone.
ChangedRelease gate
Every candidate release now has to clear whole-store accuracy, hidden-miss, uncertainty, and independent-audit gates twice on fresh stores.
FixedBusiness identity
Registration labels, Irish Eircodes, and third-party developer credits are now kept separate, so the scanner is less likely to miss a real merchant or credit the wrong company.
FixedReturns and refunds
Swedish, Hungarian, and Norwegian timing language now stays attached to the right fact instead of being confused with delivery timing.
FixedContact details
Danish contact links, JavaScript-rendered contact pages, Serbian contact wording, and adjacent Spanish phone numbers now survive discovery and parsing.
FixedReturn exceptions
A narrow exception for a product or use condition no longer turns into a false claim that the whole store refuses returns.
Update 2.0

Broader policy and storefront coverage

Policy discovery now handles more real storefront patterns while keeping every conclusion inside the evidence the scanner actually captured.

FixedPolicy evidence
The scanner now prefers substantive policy pages, records broken-policy-link provenance, and keeps in-store returns and credit-note final sales in their proper scope.
FixedRendered evidence
Rendered footer details can now support tax-identifier checks, while persisted AI findings keep distinct evidence instead of collapsing together.
FixedLanguage coverage
Estonian return windows and German free-return wording gained focused regression coverage.