Cloaking is often perceived as a magic button: turn it on and moderators see nothing. But that's an incomplete picture. Cloaking is only a filter that decides who sees what. What to actually show — that's a question your white page has to answer. And this is where things get interesting.
How traffic filtering works
When a user follows an ad link, the cloaking server analyzes the request in milliseconds and decides: serve the white page or the actual offer. Several methods are used:
- IP filtering — the bluntest method. Databases of ad network IPs, datacenters, and VPNs are updated but never complete. Works as the first line, not the main one.
- User-agent analysis — a moderator's browser often sends headless signatures, non-standard versions, or automation patterns. Selenium, Puppeteer, Chrome headless all have characteristic fingerprints.
- Behavioral patterns — bots don't move the mouse, don't scroll, visit pages on exact schedules. Advanced cloaks analyze click timings and action sequences.
- Referrer and UTM — a direct visit with no referrer at 3 AM from a datacenter IP is an obvious review pattern.
- Geolocation and ASN — the provider's autonomous system (ASN) says more than just the country. ASNs of major cloud providers (AWS, Google Cloud, Azure) are almost never used by regular users.
A good cloaking system operates on a presumption of guilt: any suspicious request gets the white page. Better to lose 5% of real traffic than show the offer to one moderator.
Why a poor white page kills even a perfect cloak
This is where most buyers make their mistake. They invest in expensive cloaking, configure filters properly — and then cut corners on the white page itself. They use one template across 50 accounts, don't change the texts, grab stock photos from the same source.
The problem is that ad networks — especially Facebook and Google — conduct not just automated but also manual review. A live employee opens your white page not as a bot, but as a regular person. Or disguises themselves well enough that cloaking lets them through.
In these moments, several scenarios play out:
- The page is technically clean, but the content is obviously generated — meaningless sentences, no structure, no real value for the reader
- The same domain and page are used on dozens of accounts — visible through domain history
- Images found via reverse image search appear on hundreds of other "white" pages with the same structure
- Page metadata (title, description, og tags) doesn't match the content — an obvious template signature
Result: the cloak worked, the bot didn't reach the offer — but the human reviewer still banned the account for a suspicious white page. This is precisely why the quality and uniqueness of your white page isn't optional — it's the foundation of the entire setup.
Technical methods for content substitution
Once cloaking decides who sees what, it uses one of several technical mechanisms for substitution:
JS redirect
The simplest option: the user loads the white page, a script checks parameters and instantly redirects to the offer via window.location. Pros — easy to implement. Cons — the redirect shows up in browser logs and history; Google tracks this.
Server-side redirect (302/307)
The cloaking server returns an HTTP-level redirect to the target URL. Fast, clean, leaves no DOM traces. Works better than JS, but puts load on the server under heavy traffic.
iframe substitution
The white page stays on the domain while the actual offer loads inside an iframe. Technically the domain stays "clean," the moderator sees the white page. But iframes have limitations: many offer landing pages have X-Frame-Options set to DENY, and the method simply won't work.
curl/PHP proxy
The server fetches the offer content via curl and serves it under the white domain. The user sees the offer, the URL stays white. Resource-intensive and slower, but perfect from a URL perspective.
Dynamic content substitution (DOM-swap)
The page loads as white, then JS completely replaces the DOM with the target content. A moderator who screenshots before the script executes sees the white page. More sophisticated checks can wait, or disable JS — in which case the white page must be fully functional on its own.
Regardless of the substitution method — if your white page is empty, templated, or obviously non-functional, that's a signal. Even if the moderator landed on it by accident and the cloak failed — the page must look like a real site.
What makes a white page "bulletproof"
A checklist for a white page that will pass not just automated but manual review:
- Unique content — not a template, not spun text. Real material on the topic that's worth reading
- Proper structure — H1, H2, paragraphs, numbered lists. The page should look like an article or blog post
- Unique images — or none at all. Better no images than the same stock photos appearing on thousands of other white pages
- Working policy pages — privacy policy and terms of service must not be placeholders
- Correct meta tags — title, description, og tags match the page topic
- Different content across accounts — one page on 50 campaigns is a pattern visible at the domain level
A generator like Gen White Page solves exactly this problem: every page is created with unique content tailored to a specific category and GEO. No repeating structures, no identical text. This is critically important when working with multiple accounts simultaneously.
Summary
Cloaking and white page aren't interchangeable — they're two links in the same chain. Cloaking decides: who sees what. The white page decides: what to show those who can't see the offer. Break one link — the whole chain fails.
That's why buyers who take this seriously never cut corners on white page quality — and rotate it just as regularly as they test new creatives.
