Methodology

How a scan actually works

Cloaker Checker’s whole premise is “evidence over assumptions” — every number in a report traces back to a specific, documented rule, not a model we can’t explain. This page is that documentation.

The dual-agent fetch

A scan requests the same URL twice: once with a standard browser’s User-Agent header, once with Googlebot’s. Both requests go through the same hardened fetcher (see Limitations for what that does and doesn’t protect against), following redirects and recording the full chain, response headers, timing, and raw HTML for each.

Important: the Googlebot request uses Googlebot’s User-Agent string only — it does not originate from a verified Google IP range. A site that cloaks based on reverse-DNS or IP verification rather than the User-Agent header alone may not reveal cloaking to this check. We call this a “Simulated Googlebot” throughout the app rather than implying verified crawler access.

Three separate measurements, not one score

Earlier versions of this tool produced a single blended “risk score.” That conflated two different questions: how much a page differs, and whether that difference looks deliberately deceptive. A full site redesign and an actual cloaking attack can both produce a lot of raw difference — only one of them should read as suspicious. So a report now shows three independent numbers:

Content Divergence

Pure magnitude — how different the two responses are, based on structural HTML similarity, visible-text similarity, and whether fields like title, meta description, and headings differ. Says nothing about intent. A cookie banner, an A/B test, or a genuine redesign all show up here without triggering the other two measurements.

Cloaking Suspicion

Only fires on specific, named patterns associated with actual cloaking: crawler-only spam keywords, hidden links shown only to the crawler, a canonical URL pointing to an unrelated domain, the crawler and browser landing on different final destinations, an indexable page served to the crawler paired with a blocked/redirected human visitor, and a few others. Each signal has a documented, fixed weight. Three signals — the ones with essentially no innocent explanation — are weighted high enough to independently cross the “Cloaking Suspected” threshold on their own; everything else needs roughly two signals together.

Evidence Confidence

How much a single-shot read like this can be trusted — did both fetches succeed, was the content actually HTML, was there enough text to compare meaningfully. Framed as deductions from a 100-point baseline. This is deliberately separate from reproducibility across repeated requests, which is what Verification Scan adds.

Verification Scan

An optional, separate action (never run automatically) that requests each profile a second time and checks two things: whether each agent’s own response is internally stable across the two requests, and whether the same browser-vs-Googlebot differences show up on both independent comparisons. A finding that reproduces identically is a real, consistent pattern; a finding that only shows up once is treated as a possible false positive, and Evidence Confidence is adjusted accordingly — down if something didn’t reproduce, up if it did.

Before comparing two repeats of the same agent, we normalize away known-dynamic noise — timestamps, cache-busting query parameters, CSP nonces, auto-generated-looking element IDs, attribute ordering, and whitespace — so a cookie-consent banner or a rotating ad doesn’t register as “unstable.” We never normalize away text content, links, metadata, canonicals, robots directives, or structured data; a report’s “Normalization Details” section lists exactly what was excluded, with real examples, for every verification run.

What this doesn’t do (yet)

Both fetches request the raw server response — no JavaScript execution, no rendering. A site that only cloaks after client-side JavaScript runs won’t be caught by the current version. This is a deliberate, documented gap while we figure out whether rendered scanning is viable within this project’s hosting constraints, not an oversight.