MerchantCure Free Quick Scan

What we find

The faults, grouped by the check that catches them.

48 classes of fault, drawn from real diagnoses and fully anonymised. The engine can name 66 distinct faults in total; these are the ones worth explaining.

MerchantCure was built against a live, suspended Merchant Center account in our own group of 30+ shops — not against a theory — and measured against a paid agency audit as an outside yardstick.

The order is a decision

The checks run in a fixed sequence, and it is not configurable.

Reachability first, because everything downstream is unmeasurable if Google cannot fetch the page. Claims last, deliberately, because it is the one place where a tool is most tempted to overreach. The feed check is last in the list and first in severity — the action plan is sorted by severity, so a critical feed finding lands at the top regardless.

01  /  Runs first

Reachability

Everything else is meaningless if Google cannot fetch the page. We crawl without cookies and without JavaScript — the way Googlebot meets a shop — and compare two passes with different identities against each other.

Severity Finding What it detects
Critical robots.txt blocks Googlebot robots.txt disallows Googlebot, AdsBot, Storebot or the inspection tool.
Critical Redirect loop A redirect loop: the address never resolves to a page.
High Empty without JavaScript The page is empty without JavaScript. Whatever it says, Google may not be reading it.
Medium Redirect ping-pong An address bounces A → B → A for clients without cookies. Common, and invisible in a normal browser. 53 addresses in one shop, reported as a single grouped finding.
High Dead internal link The shop links to its own pages that return 404.
High HTTPS downgrade A redirect chain drops from https to http partway through.
High Menu varies by visitor The page serves a different menu depending on who is asking.
Info Our own fetch was blocked Bot protection rejected our own fetch. A fact about our vantage point, not a fault in the shop — and it is reported as a limitation on what we could see.

02  /  Second

Policy pages

Every terms, returns, shipping, privacy and cookie page in the shop, found by slug pattern and by link text, across languages. Then compared against each other — the interesting faults are never in one page, they are between two.

Severity Finding What it detects
Critical No return policy No return policy is reachable at all.
Critical Contradicting return windows Two live policy pages state different return windows. Usually a leftover from a theme change, and invisible until someone lists them side by side.
High Duplicate policy pages Several parallel policy pages of the same kind are live simultaneously.
High Policy page in the wrong language A policy page is in a different language than the shop declares.
High No deadline stated The return policy states no deadline at all.
Medium Not linked from the footer The pages exist but are not reachable from the footer, which is where a reviewer looks first. 53 policy pages inventoried on a single shop.

03  /  Third

Business identity

Company name, registration and VAT number, address, email, phone — extracted per page and compared between pages. The finding is rarely 'this is missing'. It is almost always 'this exists in two versions'.

Severity Finding What it detects
Critical Two company names The shop states genuinely different company names on its own pages.
Critical Two registration numbers Two different registration or VAT numbers across the site.
High Structured data disagrees The company name in structured data does not match the one in the visible text.
High Two postal addresses Different postal addresses on different pages — typically an old one left in the terms.
Medium Postcode run into the city Postcode and city run together without a space, which breaks address parsing.
Medium Same value, several spellings The same value written several ways. Separated from real discrepancies on purpose — a spelling variant is not a contradiction.

04  /  Fourth

Locale, language and price format

Currency in structured data against the market's norm, decimal separators, cent values that reveal live currency conversion, meta text in the wrong language, machine-translation artefacts, and translated brand names.

Severity Finding What it detects
Critical Wrong currency in product data The currency in the product data is not the one the domain trades in.
Critical Page contradicts itself One product page states two different currencies about itself, in two different places.
High Live-converted prices The share of prices with odd cent values, which indicates live conversion rather than prices set for the market. 90 % of prices on one shop carried conversion artefacts.
High Wrong decimal separator Prices written with a point where the market uses a comma. 673 of 760 prices in one shop.
High Meta text in the wrong language Meta titles and descriptions in a different language than the page declares. Usually a template, which is why editing individual products changes nothing.
High Machine-translation artefact A machine-translation artefact: correct language, impossible in context. A car part appearing in a food supplement description.
High Translated brand name A brand name has been translated into a common noun by a translation plugin.

05  /  Last in the list, first in severity

The product feed

The only check that produces a machine-readable proof: exactly the comparison Google itself makes. Price, currency, availability and title, row by row, against the structured data on the matching page. Plus the feed's own quality.

Severity Finding What it detects
Critical Feed and page disagree on price The feed amount and the page amount differ. The check separates scattered differences from a single systematic factor, because they mean completely different things. One shop showed one constant ratio, 1.17925, on all 53 compared rows — the page charging 25 % VAT against a feed calculating with 6 %. Measured 17 August 2026.
Critical Feed and page disagree on currency The feed currency and the page currency disagree on matched rows.
Critical Channel names another domain The feed names a different domain as its channel than the one it lives on.
Critical Feed contradicts itself The feed describes two different shops: product links point at one host, other fields at another.
Critical Duplicated article ids The same article id appears more than once in one file. A regeneration once wrote most of a catalogue twice — the row count grew 61 % while the number of actual articles did not move.
Critical Rows pointing at missing pages Feed rows point at pages that do not exist.
Critical Price off by a factor of ten A price is off by an order of magnitude against the page.
Critical Translated brand in the feed Feed rows carry a translated brand name instead of the brand.
High Images on another host Product images are served from a host other than the shop's own.
High Thousands separator in prices Prices written with a thousands separator, which only hits the most expensive articles — so it is easy to miss. 0.55 % of rows in one file. All of them high-value products.
High Descriptions in the wrong language Product descriptions in the wrong language for the market. 27 % of descriptions in one feed — measured in a file that was served publicly but was not the connected one, which is a different fact from a fault in the live data.
High Sale price equal to the regular price A sale price identical to the regular price.
High Character corruption in product text Character corruption from an import or translation routine — a per cent sign replaced by a marker string, inside dosage text.
Medium Several feed files, one connected Several feed files are served publicly and only one is connected. Which one is connected is only visible inside the account — the check never guesses. 3 files on one server on 16 August 2026, 2 of them misconfigured. A run the following day found 2 — the count moves, which is the point.
Medium Empty image tags Empty additional image tags padding out every row. An average of 5 empty tags per article across a whole catalogue.
Info The funnel (a fact, not a fault) A fact row, not a fault: how many rows were submitted versus how many can actually be shown. Often the single most useful number in the whole report.

06  /  Only where the market requires it

Unit price

Grundpreis and equivalent rules. Runs only on markets that legally require a unit price, and checks three separate things — because 'it is there' is not the same as 'it is compliant'.

Severity Finding What it detects
High No unit price No unit price on products sold by weight or volume.
High Unit price hidden or too far away The unit price exists but is hidden in a tab or a collapsed panel, or sits too far from the price to count as being next to it.
High Unit price does not add up The unit price does not equal price divided by content. It is there, and it is wrong.

07  /  Deliberately last

Claims signals

Substances Google explicitly restricts are a lookup and carry weight. Risk words in category and product names are a flag, not a legal judgement — and the report says so in as many words. Neither can ever be raised to Critical.

Severity Finding What it detects
High Restricted substance in the catalogue A substance on Google's restricted list appears in the catalogue. A lookup against a named list, not an interpretation.
High Medical or therapeutic wording Medical or therapeutic language in category and product names. Flagged for you to judge. We do not rule on what is lawful — only on what Google says it requires and what the shop displays.

Underneath the list

Six mechanisms explain most of what the checks report.

The classes above are what the tool can name. These are what the findings turned out to mean once they were laid next to each other — and knowing which mechanism you are looking at changes what you fix, and in which order.

  1. 01

    Context inheritance

    Feed generation is not one program. Each subsystem decides its own context, and none of them checks the others.

    Product text comes from one place, links from another, currency and tax from a third, base URLs from whatever language or site context the export run happened to start in. Each part inherits a context independently. When one of them inherits the wrong one, that part is wrong everywhere and the rest is right everywhere.

    Why it survives normal debugging A partly-correct file reads as mostly fine. A merchant who sees correct product links assumes the file is broadly right and goes looking for a row-level mistake, when the fault is one subsystem that will keep inheriting the wrong context on every future run.

    Caught by Channel names another domain · Feed contradicts itself · Images on another host · Meta text in the wrong language

  2. 02

    The auto-update ghost

    The fix is applied, and something puts the fault back — usually a job nobody remembered was running.

    Old feed files left after a migration are ordinary. What is less obvious is that the export jobs that wrote them are often still active: delete the file and it returns tomorrow, with the same wrong channel and the same wrong image host. The same shape appears as a plugin setting overwritten at the next update, or a translation table that re-translates a brand name after someone has corrected it by hand.

    Why it survives normal debugging The fix is verified at the moment it is made, which is the one moment it is least likely to have been undone yet. Every recipe card we write therefore ends with a verification step carried out later, logged out and after a cache purge — the state most likely to reveal that something restored the fault.

    One server carried 3 feed files, 2 of them misconfigured and all 3 updated daily by active export jobs.

    Caught by Several feed files, one connected · Duplicate policy pages · Translated brand name

  3. 03

    The wrong file is connected

    The file being fixed is not the file Merchant Center fetches, and nothing on the outside says which one is.

    Several feeds are served publicly on the same server — a current one, one from a migration, one from a country domain that shares the generator. Only one is connected to the account. From outside, all of them look equally live, and they are: each is fetchable and each is being rewritten on a schedule.

    Why it survives normal debugging Every fix appears not to work, which sends the merchant looking for a bigger problem than the one they have. Nobody outside the account can resolve it, and a supplier who tells you which feed is connected without logging in is guessing. The check never guesses: the finding stays labelled unconfirmed until you have looked.

    3 product feeds served publicly on one server. 2 misconfigured. 1 connected.

    Caught by Several feed files, one connected · Feed contradicts itself

  4. 04

    The main-domain fault

    The feed describes a business at one address while the shop lives at another.

    A network of country domains generated from one platform inherits the group's or the primary domain's address in the fields that name the channel and host the images, while product links correctly point at the domain the feed was generated for. Three subsystems, two of which took their address from the wrong place.

    Why it survives normal debugging The shop works perfectly for shoppers, and the wrong values sit in fields no human reads. Merchant Center, on the other hand, reads the feed as a description of one store — so the account is describing a business other than the one under review.

    Caught by Channel names another domain · Images on another host · Feed contradicts itself

  5. 05

    The wrong tax or currency context

    One process applies one wrong rate at generation time, and every affected row is wrong by exactly the same factor.

    Feed generation runs under a tax class or a currency setting that belongs to a different market than the feed is for. The customer-facing price chain is usually untouched — shoppers see the right amount, pay it, and are never charged something else — while the exported metadata carries a systematically different number.

    Why it survives normal debugging It looks like a pricing problem, so people go and check their prices, which are correct. The constant ratio is the thing that names the cause — it is the quotient of the two rates, so 1.17925 reads as 25 % against 6 % — and a scattered difference would have meant data entry instead.

    One shop showed a ratio of 1.17925 on all 53 compared rows — (1 + 25 %) ÷ (1 + 6 %). One setting, not 53 wrong rows. Measured 17 August 2026.

    Caught by Feed and page disagree on price · Feed and page disagree on currency · Wrong currency in product data · Live-converted prices

  6. 06

    Number format against the market's norm

    The digits are right and the punctuation is not, which is enough for a parser to read a different number.

    A decimal point where the market writes a comma, or a thousands separator in a field that does not expect one. Both come from a locale setting somewhere in the export chain rather than from anything a merchant typed.

    Why it survives normal debugging The thousands separator only appears on the most expensive articles, so it affects a small share of rows and is invisible in an eyeball scan of a long file. The decimal separator is the opposite: so widespread that it stops looking like an error and starts looking like how the file is.

    673 of 760 prices in one shop used a point where the market uses a comma. In another file, a thousands separator appeared on 0.55 % of rows — all of them high-value products.

    Caught by Wrong decimal separator · Thousands separator in prices · Price off by a factor of ten

What a corrected fault looks like

The only measurement on this site that has both halves.

A before number is a complaint. The pair is what a reviewer can check without taking anyone at their word. This one is anonymised from a dated run on a real store, and it is the single fault in that dossier that was both carried out and verified by a re-scan.

Before 59 of 59 product pages declared one currency in structured data while the other price fields on the page, and the feed, declared another
After 0 of 59 of the same pages, after one setting in a currency plugin was changed

Measured 16 August 2026, and re-measured the same day after the change. The customer-facing price chain had been correct throughout: shoppers saw the local currency, paid in it, and were never charged an amount other than the one displayed. The fault lived entirely in machine-readable metadata that only Google was reading.

What a finding must carry

Four things, or it is not reported.

Evidence

Required by the data model, not by convention — a finding without it cannot be constructed. Six kinds: a verbatim quote, a redirect chain, an HTTP status, a conflict between two sources, a measured value, or a list of every affected address.

A rule, with a link

Google's own page, and the clause quoted word for word. A finding without a reference is an opinion, and an opinion cannot be attached to an appeal.

Why Google cares

One sentence, in plain language. If we cannot explain in one sentence why a reviewer would object, the finding is probably us being clever rather than useful.

An action class

We write it · You run the recipe card · Your decision. Stated up front so you know which findings we can correct for you, which ones you can hand to a developer, and which ones need your judgement.

The uncomfortable half

What the tool is built to admit.

Findings we cannot make

Merchant Center account state, account history, which feed file is connected, whether checkout completes. These go into a separate section as a checklist for you, each with why we cannot see it and what to check. One run produced 11 of them.

Faults with no class

The report ends with a self-audit: which of the 7 error classes were hit, which were not, and every finding no class covers — listed openly rather than quietly dropped.

Things we were told but could not reproduce

Faults the owner saw that our own fetch could not confirm are printed in their own section and are never ticked off as found. If we did not measure it, we did not find it.

Our own false alarms

The first run against a healthy shop produced 3 of 17 findings that were wrong. One of them claimed a tub of protein powder was a second, contradicting cookie policy. Each became a regression test.

See which of these apply to you.

Send your shop URL and the reason Google gave. Measurements on this page come from dated runs, the most recent on 17 August 2026.