Which page are people actually cloaking these days — the lander or the thing after it

Caveat before anyone answers: I am asking about architecture, not about a specific service, and I would rather nobody named one.

When I started doing this the whole decision sat at the lander. Reviewer sees a compliant page, real traffic gets the other one, everything downstream is unprotected because nobody was looking downstream.

That has clearly stopped being true. 1) Two accounts of mine died in March where the lander was untouched and clean and the only thing that changed was the offer page the advertiser was hosting. 2) A third got a warning citing a page I do not own and cannot edit.

So the question is where people are drawing the line now. Is it still the lander, has it moved to the hop after it, or are people doing both and eating the latency? And if it has moved, what do you do about a page you do not control?

you don't control it so you don't run it. that's the answer and nobody likes it

IME the useful reframe is that you're not protecting a page, you're protecting a chain, and a chain is only as compliant as its worst hop.

What that means practically: the review can enter your funnel at any hop, not just the first. If the offer URL leaks into an ad platform's crawler — through a pixel, a redirect that got indexed, a competitor pasting it into a report form — it gets fetched directly with no referrer and none of your lander logic ever runs.

So the design question is what happens to a request that arrives at hop three with no history. If the answer is "it serves the offer", you have no protection at all no matter how good the lander filter is.

The boring fix that most people skip: signed, short-lived tokens between hops. A request to the offer page without a valid token from your lander gets a generic page. Costs you a few milliseconds and it means the entry point is the only thing you have to defend.

# nginx, roughly
if ($arg_t = "") { return 302 /info; }

Obviously useless when the offer page is on the advertiser's domain, which is Marta_K's actual problem and which I don't have a good answer to.

PipelineRat's chain framing is right and I want to extend it, because the advertiser-page problem has a shape that people keep rediscovering.

Three places the line can sit

1. At the lander. Classic. Cheap, well understood, and now insufficient on its own because reviewers increasingly arrive mid-chain.
2. Between lander and offer. Token-gated, as described. This is where most competent operations are now.
3. At the domain boundary. You stop sending traffic to anything you don't serve, and run your own version of the offer page with a server-side handoff at the point of conversion.

Most of the industry lives at 2 and thinks it lives at 3.

Why the advertiser page is the hard one

When the offer page is on the advertiser's domain you have handed control of your compliance posture to a company whose incentives are not yours. They will add a chat widget, a retargeting pixel, a new payment provider's script, or a claim in the copy that your ad platform's policy team objects to. They will do it without telling you, because in their model you are one of two hundred partners.

Marta_K's March losses are exactly this and the point worth internalising is that nothing she did caused them.

The options, honestly rated

• Mirror the offer page on your own domain. Legally and contractually fraught with most advertisers, technically straightforward, and it puts hop three back under your control. Some networks explicitly permit it, most are silent, a few forbid it.
• Monitor the advertiser page and pause on change. A diff every fifteen minutes against a known-good capture, alerting on any script tag change. This does not prevent anything but it turns a two-week bleed into a two-hour one. I would call this the minimum.
• Pick advertisers by page stability. Nobody does this and it is probably the highest-return item on the list. Some advertisers change their pages twice a year and some change them weekly. That is knowable in a fortnight of monitoring before you ever send traffic.

What I don't know

Whether mid-chain fetching is actually happening at scale or whether the March wave had a different cause and we're all constructing a mechanism from three anecdotes. I've seen the referrer-less hits in my own logs and I can't tell a platform crawler from a competitor's scraper with any confidence.

Summary: gate every hop you own, monitor the one you don't, and treat page volatility as an advertiser selection criterion.

The mirroring option carries a cost nobody has stated.

The moment you serve the offer page yourself, you are the party collecting whatever that page collects. Names, card details in some verticals, whatever the form takes. That is a completely different legal and operational exposure to sending someone to an advertiser's form, and it changes who is holding the data when something goes wrong.

People reach for it as a technical fix to a compliance problem and acquire a data-handling problem they have no process for.

Your threat model is not just the ad platform. It never was.

Advertiser page stability as selection criteria is good idea and i never think about it. Anyway is easy to check, just diff for two week before you send anything.

what is a hop

honestly i just don't cloak anymore, got tired of maintaining it. white hat funnel, worse numbers, accounts live for months instead of days

probably makes me a coward on this board but my stress level is completely different

The only person in the thread with a solution and he's apologising for it.

he's not a coward, he's the only one of you sleeping

Your whole section 2 rests on referrer-less mid-chain hits being reviewers. You said yourself you can't distinguish them from scrapers. Everything downstream of that is architecture built on a guess.