Ad cloaking refers to a system where the display of different content or landing pages for each visitor is done depending on variables such as IP address, browser, and device.
Quick answer – Cloaked advertisements show different content to the auditor and regular users; they both see completely different landing pages. The content shown is usually determined by factors such as IP address, device, browser, location, and user activity or behavior.
Cloaked advertisements can make an advertisement that will appear totally different depending on the person accessing the ad. The auditor may see a legitimate landing page that is compliant with all regulations, but the regular website visitor might be sent to a completely different page.
This is due to the fact that cloaking software will evaluate signals such as the IP address, browser, device, connection, and even user actions to determine which version of the page should be shown to the viewer.
With time and development, the above techniques will get even more complex, and a regular ad check might not tell the whole story. It will be necessary to keep on testing the ad from different environments, including a proxy for AD veification and monitoring to identify hidden redirects, inconsistent destinations, and other differences that could otherwise remain unnoticed.
Cloaking scripts do not make random assumptions; they score a visitor against a checklist built from years of watching who reports bad ads. A data-center IP address, a stale user-agent string tied to a known crawler, or a referrer that matches an ad-network’s own domain is worth points toward “this is a reviewer, show the safe version.” Clear the mark and the script changes the destination URL before the first pixel appears.
| Signal checked | What triggers suspicion | Why cloakers track it |
| IP origin | Data center or VPN range | Auditors rarely browse from residential ISPs |
| User agent | Headless browser, outdated string | Scrapers skip real device updates |
| Click history | Zero prior page views on the domain | Real users arrive with a browsing trail |
| Time on page | Under two seconds before redirect | Bots often fetch and move on instantly |
| Referrer path | Direct ad-network click-through | Marks a formal review session |
Filtering is applied most heavily at the stage when nothing gets rendered yet. A request hits the ad server, the server checks IP reputation against commercial blocklists that flag known scanning ranges, and it decides which HTML to return – no JavaScript required, no trace left in the page source an auditor later inspects. That’s why the post-render snapshot cannot prove that cloaking was applied in practice; the switch was made at the networking level.
Some advertisers add another layer by rotating the so-called “safe” page every few hours, so a reviewer who requests the same URL twice in one afternoon sees two different clean pages and assumes the campaign is consistent. Catching that rotation requires repeat checks from IPs that were not flagged on the first pass, spaced out like a genuine user’s return visits. Teams running that cadence at scale credit a provider like Floppydata with keeping the IP rotation side manageable rather than a manual, one-off task that eats an analyst’s afternoon.
After passing the server-side check, there is usually a second filter running in the browser. A short script waits for mouse movement or a scroll event – signals a real person generates without thinking – before firing the redirect to the actual offer. An automated checker that loads a page headlessly and grabs the DOM instantly, without simulating that behavior, gets served the compliant page every time and never notices the swap happened at all.
Independent verification teams now build browsing sessions that mimic idle scrolling on purpose, then route each check through a residential exit so the request itself never carries the fingerprint of a lab environment. What is more important here is not the scripting but rather the multi-layered protection. This might be true because a checker sitting on one static IP is blocklisted by the cloaking script within the first two or three attempts and cannot even prove anything regarding the campaign in question.
An initial inspection reveals very little information to the reviewer, because cloaking rules get tuned against whichever detection method just caught them. The pages that hold up track a creative across weeks, from different regions, device types, and connection profiles, and log every redirect chain rather than just the final landing page.
If there is any change in the destination without any clear explanation in the source code, that log is the evidence a network needs to pull the ad. Far more convincing than a single screenshot that the advertiser can dismiss as a rendering glitch on the auditor’s end.
Ad cloaking refers to a system where the display of different content or landing pages for each visitor is done depending on variables such as IP address, browser, and device.
Auditing teams can compare test results from multiple locations, devices, internet connections, and sessions while tracking redirects and changes of destination.
In server-side cloaking, the ad server identifies a visitor prior to loading the page and then serves up different content depending on the visitor’s characteristics.
Client-side cloaking relies on browser scripts or user action to effect redirects after loading the original page.
