Meta says "Some website data blocked": what it means and what to do next

You open Events Manager and see a banner: some website data blocked. Conversions that used to arrive look thin or vanish, custom conversions stop matching, and campaigns that optimised well start drifting.

This usually isn't a bug. It's Meta applying its data-sharing restrictions to your website.

Why Meta restricts some websites

Meta classifies websites by what they're about. When a site falls into a sensitive category, such as health and wellness, personal hardship (legal problems, debt, family issues) or certain financial topics, Meta limits what information it accepts from that site. The aim is to stop sensitive details about people from flowing into ad systems.

The classification is about the site, not about something you did wrong. A pain clinic, a family law firm and a debt advice service can all be flagged even with a perfectly normal setup.

What typically stops working

The exact limits depend on how your dataset is classified, but these are the usual effects:

• URL data after the domain is removed. Meta no longer sees /treatment/back-pain or query strings like ?utm_term=....
• Custom parameters are dropped. Anything like content_name: "knee surgery" never arrives.
• URL-based custom conversions break. If a conversion was defined as "URL contains /thank-you", Meta can't see the URL, so it never fires.
• Some customer information fields can be limited, depending on the restriction.
• In some cases Meta also limits which events you can optimise for.

The dangerous part: none of this throws an error on your website. Tags keep firing, the browser shows no problem, and the campaign quietly optimises on less and less.

What still works

A restricted dataset isn't a dead dataset. With a clean setup you can usually still rely on:

1. Standard events with neutral names. A Lead or Schedule event, fired at the right moment, still carries the signal that matters: a qualified action happened.
2. Server events through the Conversions API, sent alongside the browser event with the same event_id, so Meta deduplicates them instead of counting twice.
3. Lead-form outcomes matched by lead ID. If you use Meta lead forms, your CRM can report back which leads became qualified or booked, using the lead ID instead of personal data.
4. Your own reporting. UTM parameters and a CRM still tell you which campaign produced which customer, even when Meta can't.

What not to do

You'll find advice online to "get around" the restriction. Avoid it:

• Don't send events under another domain or through a masked setup.
• Don't rename events to hide what they are.
• Don't open new pixels, ad accounts or Business Managers to escape the classification.

These approaches risk the ad account itself, and they don't fix the underlying problem: the campaign still needs a trustworthy signal.

A practical order of work

1. Audit before changing anything. Check in Events Manager what the restriction says, which events still arrive, and which parameters are dropped.
2. Map your funnel to standard events. Decide which real step means "qualified" (an eligibility step, a confirmed booking) and fire a standard event there.
3. Add server events with deduplication so signal survives ad blockers and browser limits.
4. Send outcomes from your CRM where it's allowed, so Meta learns which leads were good.
5. Report from your own data and compare it with what Meta shows, every week.

If you're looking at this banner in your own account and aren't sure what applies to you, that's exactly what an audit answers: what's blocked, what's allowed, and the cleanest setup inside the rules.