Facebook ads cloaking: what Meta's ad review checks and how to set up a cloaker

Facebook ads cloaking is a traffic filter that sits between a Meta campaign and your landing page. It decides who sees the white page and who sees the offer: Meta's crawlers and reviewers get an ordinary, policy-compliant site, a real person who clicked the ad gets the pre-lander or the offer. This guide has no generic advice about "bypassing moderation". We took Meta's documentation on ad review and on its crawlers, compared it with what we see in KLO logs, and collected the rules that actually separate a review from a buyer.

If you are new to the topic, our Russian guide on how cloaking works covers the basics. Here we stick to Meta specifics.

How Meta reviews ads and landing pages

Meta's Business Help Center describes the process plainly: review starts automatically after an ad is created or edited and, with some exceptions, takes up to 24 hours. Most of it is automated, some ads go to a human reviewer. An ad can be reviewed again at any moment, including ads that are already running.

Three points in that description matter for a cloaker.

• The destination is part of the review. Meta's Advertising Standards state that the system evaluates images, video, text and targeting, and also the ad's destination or landing page. A landing page that does not match the ad, or that is broken, is grounds for rejection on its own.
• Edits trigger a new review. Scheduled or active ads go back into review when targeting, creative (images, text, links, video), optimization or the billing event changes. Changing budget, bid or schedule does not trigger it.
• Review can be manual. A reviewer on a regular phone with home internet looks like any other visitor. Against that kind of check only the quality of the white page works, not the filter.

Which Meta crawlers hit your landing page

Meta publishes its crawler list and the exact User-Agent strings you will see in server logs. Four of them matter for Facebook ads.

The line about robots.txt deserves attention. You cannot keep the crawler out with robots.txt: Meta states directly that FacebookExternalHit may ignore it during security checks. So the decision has to be made by a filter on the server, not by robots.txt.

All of these crawlers come from Meta's own networks. Meta's autonomous system is AS32934, and any serious filter keeps its prefixes in the database. In KLO logs the visits with facebookexternalhit, meta-externalagent, meta-externalads and meta-webindexer user agents over the summer of 2026 came almost exclusively from Meta prefixes, and the same prefixes also produced visits with ordinary browser user agents. That second group is the interesting one.

Signals that separate a review from a buyer

A crawler with a declared user agent is the easy case: the string is in the list, the IP is in Meta's ranges, the answer is white. The hard case is a check that looks like a browser. These are the signals that work in practice, roughly in order of reliability.

1. Network. The IP belongs to Meta (AS32934), to a hosting provider or to a data center. A buyer comes from a mobile carrier or a home ISP. This is the cheapest and the most accurate signal.
2. No click ID. A real click from an ad carries fbclid in the URL. A visit to the entry URL without it is a crawler, a manual open or someone who copied the link.
3. Geo and device mismatch. The campaign targets Germany on Android, the visitor is on a desktop in the US. Reviewers work from where they work, buyers come from the targeting.
4. Browser language. A German campaign with a visitor whose Accept-Language is en-US only. Not a hard rule, but a strong one in combination.
5. Headless and automation fingerprints. navigator.webdriver, software WebGL renderers, no mouse movement, zero plugins on a desktop user agent. These come from a JS layer and catch tools that spoof everything else.
6. Behaviour. Repeated visits from one subnet within minutes, bursts of clicks in 60 seconds, visits that walk through the site's links instead of landing and converting.

KLO combines these into a decision on the first request, before any HTML is sent. There is no redirect the visitor could notice, and there is no way to "click through" to the offer by hand.

Setting up KLO for Facebook ads step by step

Below is the sequence for KLO. Other services have similar steps, with different field names.

Step 1. White page and offer

Build the white page before you connect the filter: the topic matches the creative, there is a contact page and a privacy policy, the page is fast, the pixel is installed. Our white page checklist lists every item. The offer or the pre-lander is prepared separately and never links back to the entry domain.

Step 2. Campaign in the KLO cabinet

Create a campaign and pick Facebook / Meta as the source. Set the countries and devices from the campaign's targeting, enable the click ID requirement (fbclid), and enter the white and offer addresses. For a new campaign turn on warm-up: the first N clicks go to white, so that the review after launch sees a normal site.

Step 3. Connection

For a regular landing page download the PHP loader from the cabinet: the secret key is already embedded, the file goes next to the landing page. WordPress has a plugin, Keitaro a filter module, React, Vue, Next.js and Node.js the @boostclicks/klo package. On the DOMINATION plan the decision is made by a Cloudflare Worker and there are no cloaking files on your hosting at all.

Step 4. Test before launch

Open the entry URL from a phone on mobile data: you should see the offer. Open it through a VPN, from office Wi-Fi and from a headless browser: you should see white. Then paste the URL into Meta's Sharing Debugger: it fetches the page with facebookexternalhit and shows what the crawler received. The correct result is the title and description of the white page.

Step 5. Launch and statistics

After launch watch the white share, the decision reasons and the visits without a click ID in the KLO cabinet. Meta re-reviews after every change to creative or targeting, so do not edit running ads without a reason: each edit is a new review and a new chance to be looked at from an unexpected network.

Mistakes that get accounts flagged

• White page on a different topic. An ad about skincare that leads to a page about car rental fails the destination check regardless of the filter.
• A redirect on the white side. The white page must be served on the entry domain. A 302 to another domain for reviewers is a signal on its own.
• Pixel only on the offer. The reviewer sees a page without the pixel that the ad account uses. Put the pixel on both pages.
• Same white page across dozens of campaigns. Meta sees the same destination behind unrelated ads. Build the white page per campaign topic.
• Constant edits of live ads. Every edit is a re-review. Batch the changes.
• Your own team on the offer. Testers on office IPs end up in the same statistics as reviewers. Add their IPs to the allowed list instead of loosening the rules.

What a cloaker does not solve

A manual review from an ordinary phone on a carrier network with a real click from the ad is indistinguishable from a buyer. In that case the reviewer sees the offer, and only the offer itself decides what happens next. A filter also does not fix a banned vertical, a payment processor that rejects the product, or an account with a history of violations. It removes the automated and the semi-automated part of the review, which is most of it, and leaves the rest to the quality of your pages.

Cloaking is against Meta's Advertising Standards, and an account can be restricted if it is detected. The techniques above reduce how often that happens; they do not make it impossible. Treat the filter as a risk reduction tool, not as a guarantee.