Four Scans You Can Run on Your Own Store Right Now, and the Question Each One Cannot Answer

Three of our tools have a public front door. You paste a store URL, you wait a few seconds, and you get a result — no install, no account, no Shopify permissions granted to anybody. They are lead magnets, and we are not going to pretend otherwise. But a lead magnet that lies about its own reach is worth less than nothing, so this guide is organised around the part the marketing page does not lead with: the question each one cannot answer.

If you read only the limits and never install a thing, the guide has done its job. Every number below was read out of the running code the morning this published.

Scan One: Accessibility

The accessibility checker loads your storefront in a real headless browser and runs a real axe-core audit against it. It is not a heuristic and it is not a guess — the issues it lists are the issues that engine found on the page it loaded.

What it cannot answer: anything about the rest of your store. One line of code sets the whole boundary:

# One page only. The paid audit scans six; this is the lead magnet, not the product.
MAX_PAGES = 1

A full AccessGuard audit combines findings across six representative page types — home, collection, product, cart, search and policy — because the accessibility of a Shopify store is mostly not decided on its home page. Your cart is where a broken label costs you an order. Your product template is where the same missing alt attribute repeats across a thousand URLs. The free check reads the front door and is honest in the response itself about doing so: it returns the scope it used, a flag saying the result is partial, and a note telling you the full audit may land on a different score.

The deeper comparison — what a real audit does that a script bolted onto your theme cannot — is AccessGuard versus accessibility overlays.

Scan Two: Merchant Center Readiness

The Merchant Center checker reads your public storefront for the things Google's policies care about before it cares about your feed: whether a refund or return policy is reachable, whether privacy, shipping and terms exist, whether there is a contact route, and whether the visible copy trips prohibited-content signals.

What it cannot answer: what Google actually decided about your account. It is a readiness check against published policy, not a window into a review queue. Nothing that runs from outside your admin can tell you why a specific account was suspended, and any tool claiming otherwise is guessing at you.

Its score is also coarse on purpose, and the comment in the scoring function says why:

if prohibited_hits:
    score -= 50  # any prohibited hit is a big deal; flat penalty (don't stack to absurd)

A flat penalty rather than a stacking one. Three prohibited hits and one prohibited hit both land you in the same place, because the difference between them is not the thing you need to act on — the existence of any is. A scanner that let a bad score run away from itself would produce numbers that sound precise and mean nothing. Set against Google's own tooling, the split is covered in Merchant Guard versus Merchant Center diagnostics.

Scan Three: Made-in-USA Claims

The Made in USA checker reads the visible copy on your home page and your about page, finds US-origin claims in it, and explains the FTC risk attached to the kind of claim you are making.

What it cannot answer: whether the claim is true. This is the sharpest limit of the four and the one worth understanding properly. Origin claims are a copy problem and a data problem. The copy lives on your storefront, where anybody can read it. The data lives in your admin, on each variant's inventory item, as a declared country of origin — and no public checker can see it, ours included. So the free check can tell you what your store says. It cannot cross-check that against what your catalog declares, which is the comparison the FTC standard actually turns on.

That gap is not a shortcoming we are working around; it is a wall. The installed app reads the declared origin through the Admin API because you granted it access. A URL in a text box grants nobody anything. If you want the standard itself rather than the tooling, Old Glory versus the FTC's Made in USA standard is the long version.

Scan Four: Legacy Checkout Scripts

The checkout script checker reads your storefront home page and looks for known tracking scripts loading the old way — as raw storefront scripts rather than through a Web Pixel. For each one it finds, it names the platform-approved replacement.

The context matters more than the scan does. On August 26, 2026 Shopify shut off the legacy Thank-you and Order-status pages, checkout ScriptTags, and the order-status “Additional scripts” box for every non-Plus store. Anything wired to those surfaces stopped that day, and nothing errored to say so. Conversion tags simply went quiet.

What it cannot answer: what actually stopped. This limit is stranger than the others, so it is worth stating plainly. The scripts this check can see are the ones on your storefront, and those still run — the shutoff did not touch them. What went silent lives on your checkout and order-status pages, which are not publicly readable at all. So a green result here is not reassurance; it means the pattern is absent from the one page a stranger can load.

Reading the other side needs your admin: the checkout profile's upgrade status, ScriptTags classified by display scope, and the surfaces no API exposes at all. That is the wall, and it is a real one rather than a withheld feature.

The Question None of the Four Can Answer

When the Scan Fails, Read the Failure

Run any of the four against a store sitting behind bot protection and you will get this back instead of a score:

"error": "Your store returned a security challenge instead of the page,
          so we couldn't read it from outside."

That is not the tool breaking. That is the tool telling you something true and slightly uncomfortable: a public checker sees your storefront the way a stranger sees it, and if a challenge page stands between the two, everything else that reads you from outside hits the same wall. Search crawlers. Feed fetchers. Preview cards on social. Price comparison bots. The scan failing is a small, free, early instance of a problem that shows up later in places you care about more.

It is also, incidentally, why the installed versions exist. A scan that runs from inside your admin does not have to negotiate with your own front door.

What They Refuse to Do

Every one of these endpoints takes a URL from an anonymous stranger and then makes an outbound request. That is a shape worth being paranoid about, and each engine is guarded the same way: HTTPS only, public addresses only (private, loopback, link-local and reserved ranges are all refused), standard ports only, no redirect following, a tight timeout, a hard cap on how many bytes will be read, and a transport pinned to the address that was resolved — so the name cannot be re-pointed between the check and the fetch.

The practical upshot for you is short: you cannot use our checkers to probe something that is not reachable from the open internet, and neither can anybody else.

Run Them in the Right Order

1. Merchant Center readiness first. It is the fastest, and missing policy pages are the cheapest thing on this list to fix.
2. Made in USA next, if you make origin claims at all. Copy risk is the half you can see and edit today.
3. Accessibility next, and read the scope note before you read the score.
4. Legacy checkout scripts last — not because it matters least, but because a finding there sends you into your admin rather than into your copy, and that is a longer errand than the other three.

Then treat all four results the same way: as a list of questions, not a verdict. The whole reason this guide is built around limits is that a scan result read as a verdict is worse than no scan at all — it converts a real uncertainty into false confidence, and false confidence is the expensive kind.