Cloaking detection works by visiting your URL multiple times with different identities — crawler, reviewer, real user, different countries — and comparing what each visit gets. To audit your own page, fetch it from different IPs, devices, and referrers, and confirm every version shows the same core content and offer.
A note on intent before the mechanics: this is a self-audit guide for compliance. It explains how detection works so you can make sure a legitimate page doesn't get read as cloaking. It is not a guide to cloaking. The fix for every problem below is "make the page consistent," never "hide the difference better."
How cloaking detection actually works
Detection systems don't guess intent. They compare visits.
The core mechanism: fetch the same URL multiple times under different identities and diff what comes back. Typically that means some combination of:
- Different IP types. Datacenter IPs, where crawlers live. Known reviewer and security-vendor ranges. Residential IPs, where users live.
- Different user agents. A bot identifies as a bot. A desktop browser as desktop. A phone as a phone.
- Different geographies. The reviewer's crawler may not be in your target country. A residential user in the target geo is the reference visit.
- With and without a referrer. Arriving with an ad-network referrer versus arriving direct.
- JavaScript on and off. Some detection renders the page fully; some reads the raw HTML.
If the HTML, redirects, links, or rendered content differ in ways that track visitor identity, that's the signal. The verdict doesn't care whether a cloaking script or a misconfigured plugin caused it.
The second mechanism is behavioral: scripts that profile the visitor before deciding what to show. Fingerprinting libraries, timing checks, "real users scroll, bots don't" logic. Detection tooling looks for these scripts specifically, and their presence on a page is a flag even when they're doing something innocent.
What detectors compare between visits
Concretely, the diff runs over:
- HTTP status and redirect chain. Does one identity get a 200 where another gets a 302 to a different domain?
- Final URL. Same destination for everyone, or does the path fork?
- Page content. Text, offers, prices, claims.
- Outbound links. Do the buttons go to the same place?
- Loaded scripts. Does one identity get extra JavaScript the other doesn't?
- Rendered behavior. Popups, forced redirects, interstitials that appear for some visitors only.
A mismatch on items 1–2 is the loudest signal — infrastructure-level forking. Content and link mismatches (3–4) come next. Script and behavior differences (5–6) are softer, but they stack.
Why clean pages trip detectors
This is the section that matters if you're running legitimate campaigns, because false positives are common and the patterns are boring.
Geo and language redirects. You route French visitors to /fr/ and German visitors to /de/ via silent 302s. A reviewer's crawler arrives from a US datacenter IP and gets the English default. User in Paris gets French content, crawler gets English — a content difference that tracks visitor identity. Localization is normal practice. Silent identity-based forking is what it looks like to a detector.
Bot-protection challenges. Your CDN or WAF shows a challenge page to suspicious visitors. Crawlers are suspicious by definition. So the reviewer's tool gets a challenge screen while a user gets your page — different content by visitor type, exactly the pattern detection exists to catch.
A/B testing tools. Variant A for half of visitors, variant B for the rest. If the variants carry different offers, different claims, or different outbound links, two detector visits can pull two materially different pages. In most networks' policies, testing itself isn't cloaking — but variants that are substantively different pages can read like it.
Mobile/desktop swaps done in JavaScript. "If screen width is under 768px, replace this section." Fine for layout. A problem when the swap changes the offer, the claims, or the links — the mobile render and desktop render become two different pages.
Third-party scripts you didn't audit. Page builders, widgets, and "free" scripts sometimes ship their own redirect or fingerprinting logic. If you didn't put it there, find out who did — the flag lands on your domain, not theirs.
The self-audit, step by step
Run this before every launch, and again after any template or script change:
- Fetch the page as different identities. At minimum: your normal browser, a mobile device or mobile emulation, a VPN exit in your target geo, and a datacenter IP if you can manage one. Note what each gets — content, redirects, destination links.
- Compare the renders side by side. Core content, offer, and outbound links should be identical across every identity. Layout differences are fine. Meaning differences are not.
- Test what a bot gets. Many bot-protection setups let you preview challenge behavior. If crawlers see a blank challenge instead of your page, decide that deliberately — typically you want protection tuned so legitimate verification traffic reaches the real page.
- Inventory every script. View source, list every external script and iframe, and account for each one. Anything you can't explain gets removed or replaced.
- Reload-test your urgency elements. Countdown timers that reset on every reload are a deceptive-practices flag in most networks. Separate problem from cloaking, same audit pass.
- Screenshot both viewports. Desktop and mobile, full page, top to bottom. What you want is the boring outcome: same page, same offer, both sizes.
Step 6 is where I stopped doing this by hand. AdInfraCheck runs a cloaking-signals module as part of its 17 checks, and its captures open the page in a real browser at desktop (1440×900) and mobile (375×812) — full-page screenshots plus a scroll video of how the page behaves while scrolling. Scroll behavior is exactly where forced redirects and popup traps hide; a static screenshot of the first frame doesn't show them.
What to fix if you find a mismatch
The fix is always the same direction: make the page consistent, and make the remaining differences defensible.
- Geo routing. Prefer explicit locale URLs with a visible language switcher over silent 302 forks. Serve the same offer and claims in every locale — translate, don't swap.
- Bot protection. Tune the rules so verification challenges don't blanket-block review infrastructure. Every major vendor documents how. The goal is a crawler reaching your real page, not a wall.
- A/B variants. Keep variants substantively equivalent: same offer, same claims, same links, different presentation. A variant you wouldn't want a reviewer to see is a variant you shouldn't be running.
- Script hygiene. Remove what you can't account for. Every script on the page is either doing something you chose or something you didn't.
- Document legitimate differences. If your page genuinely varies — localization, device-appropriate layout — the safe version is that every variant is complete, policy-compliant, and independently presentable.
Two closing pointers. The behavior layer feeds into how reviewers score trust overall — the weighting is in trust signals for white pages. And cloaking is one layer of the audit, not the whole audit: reputation and history sit underneath it, covered in domain reputation for media buyers.
FAQ
Is A/B testing considered cloaking?
No — in most networks' policies, split testing is legitimate practice. The line is what varies. Presentation-level differences are fine; serving substantively different offers or content by visitor identity is the pattern detectors flag. Keep variants equivalent in meaning and you're on the right side of it.
Does geo-targeting or language routing count as cloaking?
Localization is normal and expected. What trips detectors is forking that separates reviewers from users — a crawler getting one page, a target-geo user getting a materially different one. Same offer, same claims, translated and localized: defensible. Different content by visitor type: not.
My bot-protection shows challenges to crawlers. Is that a problem?
It can be. A challenge page shown to a security crawler while users get full content is literally different content by visitor identity. Most vendors let you tune sensitivity and allowlist verification traffic — typically worth the configuration time before a campaign, not after a rejection.
If my page passes a cloaking audit, will it pass moderation?
Not necessarily — cloaking is one layer. Content policy, claims, reputation, and account history are separate layers with separate failure modes. A clean self-audit removes one specific risk: a legitimate page being misread as an evasive one.
How often should I re-audit?
After every change that touches templates, scripts, routing, or testing tools — those are the moving parts that create mismatches. And after any rejection wave, because something changed whether you changed it or not.
Run the audit before the reviewer's tools do
AdInfraCheck automates most of this pass: a cloaking-signals module alongside 16 other checks — WHOIS, DNS, SSL, reputation across 30+ blacklists, Safe Browsing, VirusTotal, security headers, Core Web Vitals — each reported separately, so a flag tells you which layer tripped it. The captures show you the reviewer's view directly: full-page screenshots at desktop and mobile, plus a scroll video, all packed into a downloadable ZIP.
Free with an account. Audit your own page first — it's the one visit you get a second chance at.