SuiteCommerceChecker

How much we read

An audit has a page budget fixed before it starts, and the crawler stops at it. We keep at most 2 page 2 requests and 4 API 4 requests in flight to one storefront at a time, and space them by at least 750 ms and 250 ms respectively. A Crawl-delay in your robots.txt raises that spacing, and we honour yours over ours whenever yours is longer.

The anonymous pre-check is one request for your home page and nothing else. It never sends seodebug, preview or seonojscache, so it cannot make your account regenerate anything.

Letting us through a firewall

Allowlist on the user-agent substring SuiteCommerceChecker/. We do not publish a fixed IP range: the crawler runs on shared infrastructure and the addresses change, so an address allowlist would break without warning. If your WAF needs one, ask and we will tell you what the current egress looks like at that moment, with the caveat attached.

What robots.txt does, and the one case where it does not stop us

A Disallow matching our user agent stops a partner audit and the anonymous pre-check outright, with no exception. Nobody consented on your behalf, so your file is the whole answer, and the report says the audit was refused rather than reporting a clean site.

On an audit requested by a verified owner of that domain it does not stop us, and you should know that before you rely on the file. We fetch page paths anyway, and four public read-only endpoints under an /api/ disallow — /api/cacheable/items, /api/items, /api/navigation/v1/ and /api/cms/v2/. The reasoning is that the person asking is the person the file belongs to, and a file written to keep search engines out of a faceted catalog is rarely an instruction to the owner about their own audit. Every override is recorded, and the Disallow comes back in the report as a finding, because it is more often a mistake than an intention. The allowlist is closed: any other /api/ path is refused even for an owner.

One path is honoured absolutely, for every kind including an owner: the SSP application path we read from your live site. Crawling it renders the application as a bot and forces a regeneration for no informational gain.

So if you want one control that stops us in every case — including an audit somebody on your own team requested — block the user agent at your WAF, or ask us to blocklist the host.

Turning us off

• Block the user agent at your WAF. That stops every request of every kind immediately and needs nothing from us. A Disallow in robots.txt also works immediately against partner audits and the pre-check, but not against an audit requested by a verified owner of the domain — the section above says why, and what to use instead if that is the case you care about.
• Verify the domain yourself and switch off partner audits. A verified owner’s opt-out blocks every agency account from requesting your storefront — refused before any credit is spent, with no appeal path through our support and no plan that overrides it. We notify you of each attempt, because “somebody tried” is something you are entitled to know; the notice names no agency, and you can decline those notices without declining anything else.
• Write to us at [email protected]. A hostname on our blocklist is refused before a request is made, for every account and every kind of crawl, and it is matched on the hostname rather than on an account we have — so a storefront we have never audited is refused just as a customer’s is. An audit already running for that host stops at the next stage boundary; its credits come back only if it had not yet fetched a page, which by then it usually has.

What we keep and for how long is in the privacy notice. What a report looks like — of a storefront we invented, never of somebody else’s shop — is at /sample-report.