Limitations

What this tool can’t promise

Every report is stamped “unverified — evidence-based” on purpose. This page collects, in one place, the specific things that stamp is referring to.

Simulated Googlebot, not verified Googlebot

The crawler-side fetch uses Googlebot’s User-Agent string only — it does not originate from a verified Google IP range, and we don’t check reverse DNS. A site that cloaks based on IP verification rather than the User-Agent header alone can pass this check while still cloaking against the real Googlebot. See Methodology for how this is used.

No JavaScript rendering

Both fetches read the raw server response. A site that only cloaks after client-side JavaScript executes — injecting content dynamically rather than serving it in the initial HTML — won’t be revealed by the current version.

Single-shot by default

A normal scan fetches each profile once. Any result can, in principle, reflect a one-off fluke rather than a stable pattern. Verification Scan (an optional, separate action) requests each profile a second time and checks reproducibility — but even that is two data points, not a statistically rigorous sample. A finding that reproduces twice is meaningfully more trustworthy than one that doesn’t, but “reproduced twice” is not the same claim as “always happens.”

Secret redaction is heuristic

Response content and headers are scanned for patterns that look like exposed API keys or tokens (AWS keys, GitHub tokens, JWTs, generic key=value assignments, and similar) and redacted before appearing in a report. This is pattern-matching against known formats, not a guarantee — a credential in an unrecognized format won’t be caught, and there’s a small chance an ordinary string that happens to match a pattern gets redacted when it wasn’t actually sensitive.

Rate limiting is per-instance, not global

Request limiting runs as an in-memory counter inside each server instance, not a shared external store — there’s no database or Redis behind it. That means it measurably slows casual abuse on a single warm instance, but doesn’t coordinate across multiple concurrent instances, and resets on a cold start. It’s real protection, not a hard, globally-enforced ceiling.

Sitemap discovery has hard caps

Sitemap-based batch scanning reads at most 10 sitemap files (including any referenced by a sitemap index) and collects at most 500 page URLs, within a fixed time budget. A very large site’s sitemap may be only partially represented in the URLs offered for batch scanning — this is a deliberate cap to keep discovery fast and bounded, not a bug.

Evidence, not a verdict

Every score, finding, and recommendation in a report is exactly that — evidence and an interpretation of it, produced by a fixed set of documented rules. It is not a legal or forensic determination that a site is compromised or engaging in cloaking, and a “Cloaking Suspected” result always warrants a manual look before you act on it.