- A checker compares responses to the same URL across user agents, IP types and sometimes JavaScript execution. It detects differences, not intent.
- Legitimate personalization such as language, currency, consent banners, same-URL A/B tests and regional pricing also produces differences. A “difference found” result is the start of a review, not a verdict.
- A checker cannot reproduce what an ad platform’s own systems observe from their own infrastructure, so a clean result does not guarantee a clean policy outcome.
- Use checkers for recurring self-audits of your own and partner landing pages, keep dated reports, and pair them with server-log review.
What a cloaking checker actually does
At its core, a checker is a fetcher with several identities. It requests the same URL as a desktop browser, as a mobile browser, with a search-engine crawler user agent, and sometimes from a datacenter IP and a residential IP. It then compares the responses: status codes, redirect chains, final URL, page title, main text and, in better tools, a rendered screenshot taken after JavaScript has run.
The output is a diff. Some tools summarize it as a score or a pass/fail label, but underneath there is always a comparison between two or more fetches. Understanding that is the key to reading the report correctly: the tool knows that responses differed, it does not know why. Our guide on how to check if a page is cloaking covers the manual version of the same comparison.
The signals a checker compares
| Signal | What the checker fetches | What it cannot see |
|---|---|---|
| User agent | Same URL with browser and crawler UA strings | Whether a server treats a self-declared crawler UA differently from a verified crawler IP |
| IP type | Datacenter, residential and sometimes mobile-carrier exits | The exact IP ranges a specific ad platform uses for its own checks |
| Redirect chain | Each hop, its status code and the final destination | Hops that trigger only after a client-side event, timer or interaction |
| Rendered content | DOM or screenshot after JavaScript, if supported | Content that loads only after scroll, consent, or a cookie set on a prior visit |
| Geography | Fetches from a handful of countries | The full set of regions your ads actually serve in |
The redirect-chain row deserves attention. Many flagged differences come from tracking links and affiliate redirects rather than from the landing page itself. Our redirect chain analysis article shows how to separate hop-level behavior from page-level behavior before drawing any conclusion.
What a checker cannot verify
- Platform-side observations. Ad platforms compare what their systems fetched with what users experienced, using their own infrastructure and historical data. A third-party checker cannot reproduce that view. See how ad platforms detect cloaking and what Google Ads compares for the platform perspective.
- Time. A single fetch is a snapshot. A page that behaves differently during a campaign’s launch hours, or that changes after a partner updates it, will pass a check run at the wrong moment.
- Session state. Cookies, consent choices, logged-in state and prior visits change what a page shows. Most checkers start from a clean session every time.
- Intent. Serving a translated page to a browser with a German Accept-Language header and serving an unrelated page to a crawler are both “differences”. Only a human reading both versions side by side can tell them apart.
- Policy outcome. Passing a checker is not approval. Platforms publish destination requirements and evaluate against them. The checker is a tool for your own diligence, not a substitute for reading the policy text.
Reading false positives and false negatives
False positives are the common case. Language and currency switching, cookie-consent banners that render differently by region, same-URL A/B tests, dynamic inventory and pricing, and bot-mitigation challenge pages shown to datacenter IPs all produce differences that a checker flags. None of these is a policy problem on its own, provided the substantive content and the offer are the same for every visitor. The de-cloaking false positives article walks through the most frequent cases.
False negatives are quieter and more dangerous. A page that keys off signals the checker does not vary, such as a specific referrer, a click-ID parameter, a device fingerprint or a timing window, will look consistent to the tool. If you are auditing a partner, a clean result should raise the question “what did this tool not vary?” rather than close the file.
A practical reading rule: treat “difference found” as “open a manual review”, and treat “no difference” as “no difference across the dimensions this tool tested”. Neither label is a verdict.
A self-audit workflow for your own and partner pages
- Define the baseline. Record the intended behavior of the page: which language and currency variants exist, which A/B variants are live, which regions are served, which consent flows apply. Differences inside that baseline are expected.
- Run from more than one vantage point, at more than one time. At minimum: launch day, mid-campaign, and after any partner or CMS change.
- Export and date every report. If a platform later asks about the destination, a dated trail of your own checks is useful context.
- Reconcile flagged differences against the baseline. Anything outside it goes to a human review of both versions side by side.
- Cross-check with server logs. Log the user agent, IP class and response served for crawler-identified requests, and compare against what the checker observed. Our guide to testing routing-tool accuracy describes several of these tests.
- For partner pages, agree the baseline in writing and re-run on a schedule. See partner page compliance monitoring for a monitoring cadence.
Choosing a checker: the questions that matter
- Does it render JavaScript, or only compare raw HTML? Raw-only tools miss client-side behavior entirely.
- Which IP classes and countries can it fetch from, and does the report show the exit IP used?
- Does it show the full redirect chain with status codes, or only the final URL?
- Can it store history and show change over time for the same URL?
- Does it explain what differed, or only output a score? A score without a diff cannot be reviewed.
- Can it run on a schedule and alert on change?
Our cloaking tools comparison evaluates routing and verification tools on related criteria. Whatever you pick, prefer a tool that shows its evidence over one that only gives a label.
Frequently asked questions
What is a cloaking checker tool?
A service that requests the same URL under different identities, such as browser and crawler user agents, datacenter and residential IPs and sometimes several countries, and reports whether the responses differ in status, redirects, content or rendering.
If a checker says my page is clean, is my ad destination compliant?
No. A clean result means no difference was found across the dimensions that tool varied. Ad platforms evaluate with their own infrastructure and against their published destination requirements. Treat the checker as one input in your own diligence, not as approval.
Why does a checker flag my page when I only use language and currency switching?
Because the tool detects differences, not intent. Localization, consent banners and same-URL A/B tests all produce differences. Document them as your expected baseline and review anything that falls outside it.
How often should I check partner landing pages?
At launch, after any change the partner reports, and on a fixed schedule during the campaign. Keep dated exports so you can show what you observed and when.
Can a checker replace server-log review?
No. The checker shows the outside view; your logs show what your server actually served to each request class. You need both to explain a difference.
One URL, the same page for every visitor
Same landing-page URL for every visitor — language and region adaptation in-page, in-page A/B testing, and identification and filtering of invalid traffic. No hidden content, no misleading redirects.