How To Run Meta Health & Wellness Ads Without Getting Restricted
Summary / TL;DR
Meta health and wellness data restrictions are driven by legal risk around Protected Health Information and domain-level classification, not just ad policy. Once Meta classifies your domain under a restricted category, it limits or blocks the event data it accepts from that domain through the pixel and Conversions API. This happens independently of your ad creative; your ads can be approved and running while your conversion data is already being filtered or blocked.
Key Takeaways
Meta classifies your domain based on your landing page content, product descriptions, and event payloads, not just your ad creative. Ad approval does not mean your domain is unrestricted.
Restrictions apply at three levels: Core Setup (metadata and URL filtering), Standard Event Restrictions (lower-funnel events blocked), and Full Restrictions (all event sharing blocked).
Renaming events or switching to CAPI-only does not resolve domain-level restrictions. The Conversions API is subject to the same data sharing rules as the browser pixel.
The durable fix is a server-side architecture with a compliant intermediary domain that changes where your data enters Meta's systems, restoring clean conversion signals without changing the customer journey.
Why Meta Restricts Health & Wellness Ads
Meta evaluates your brand across two separate systems.
The first is your ad creative: the copy, images, and video a user sees before they click. Meta reviews these against its advertising policies and Community Standards. If your creative implies a medical condition, uses shame-based messaging, shows before and after transformations, or promotes a regulated product, your ad gets rejected before it delivers. If this is your problem, read: Why Meta Does Not Allow Before and After Images in Health Ads →
The second is your landing page, domain, and event data - Everything that happens after the click. Meta scans your destination URL, the copy and images on your landing page, your product descriptions, and the event payloads your pixel or CAPI sends back. If these signal a restricted category, Meta classifies your domain and applies data sharing restrictions in Events Manager - independently of whether your ads are approved.
These two systems operate separately. Your ads can be approved and delivered while your domain is simultaneously restricted at the data layer. This is why many brands see ROAS drop and Events Manager restrictions with no ad rejections in sight.
If your ads are running fine, but you see restrictions in Events Manager, your domain has been classified under a restricted category. That is a data infrastructure problem, and the rest of this blog covers exactly that.
So again, why does Meta restrict Health & Wellness Ads?
Meta restricts health and wellness ads for two reasons: user safety and legal liability. If your creative, landing page, or event data implies shame, harm, fear, a medical condition, or sexual enhancement, Meta’s systems classify it as a policy violation, even if your product is legitimate. Why? Because of Protected Health Information
Why is Protected Health Information (PHI) so important?
When you send a purchase event to Meta that says, "User X bought a Weight Loss Supplement," you are inadvertently revealing who they are and what health condition they likely have (e.g., obesity, diabetes).
In the eyes of the law, that transaction data is now Protected Health Information (PHI).
And every Health & Wellness product implies a condition
Weight loss = obesity
Menstrual health = PCOS
ED supplements = erectile dysfunction
Supplements for Diabetes = diabetic
This turns your transaction data into PHI, which is a liability for Meta Ads.
Here’s verbatim language from Meta’s official help section :
“We do not want or permit advertisers to send health information… including medical conditions, treatments, or sensitive health data.”
and:
“Sharing prohibited information may result in data restrictions, performance issues, or suspension.”
and most importantly:
“Advertisers are responsible for ensuring their integrations do not share prohibited information… Meta’s systems are not a substitute for your own compliance.”
Meta’s systems are not a substitute for your own compliance...” Translation:
If Meta detects health signals in your events or URLs, it will block or put restrictions on your domain and/or Ad account to avoid legal liability.
That’s why health brands get restricted even when everything feels “compliant.”
How to diagnose your Meta health & wellness policy restriction level
Not all health and wellness policy restrictions are the same. After reviewing over 75+ Health & Wellness accounts, we consistently observe three levels of restriction, each of which affects your tracking, optimization, and revenue.
Level 1: Metadata Filtering (The Warning Stage)
What you’ll see:
A yellow warning icon in Events Manager → Data Source Categories.
What’s happening:
Meta still accepts your events, but it strips sensitive parameters (product names, content categories, item metadata).
What this means for performance:
Your audience weakens because Meta isn’t receiving a full signal. Limited Retargeting pools and weak attribution, but ads still run.
What to do:
Prepare backup custom events before this escalates to Level 2.
Level 2: Lower-Funnel Event Blocking (The Revenue Breaker)
What you’ll see:
A red restricted icon next to your domain.
What’s happening:
Your Shopify sales no longer match Meta-reported Purchases. Meta starts blocking lower-funnel events like InitiateCheckout and Purchase.
If your payload contains medical signals (weight loss, PCOS, ED, diabetes), Meta rejects the entire packet.
What this means for performance:
Optimization collapses, ROAS drops, Lookalike audiences stop refreshing, and costs spike.
What to do:
This is where server-side cleansing becomes essential. Before you do anything else, find out exactly what data is leaking and why. Drop the widget here before moving into the fix.
Level 3: Full Domain Restriction (The Blackout)
What you’ll see:
Almost no events in Events Manager. Even PageView stops firing.
What’s happening:
Your domain is flagged as a source of PHI. Meta blocks all pixel activity from this URL, regardless of event names or renaming tactics.
What this means for performance:
All lower-funnel optimization disappears, and Top-of-funnel performance tanks because the algorithm has no feedback loop.
What to do:
You typically need to operate under a new, clean domain (or fully isolated domain setup) that doesn’t carry the flagged history. Masking via sub-domains is a temporary workaround and often insufficient once Level 3 restrictions are applied.
How to run Meta health & wellness ads without getting flagged?
Many brands attempt to trick Meta by simply renaming events in the browser (e.g., changing "Purchase" to "Donate"). This used to work, but not anymore.
Meta’s crawler now checks all three surfaces:
Your ads (creative signals)
Your landing page and domain
Your event payload (product names, categories, metadata)
To fix this permanently, you must make all three user touch-points compliant:
Compliant Ads
Compliant Domain
Compliant Data Signals.
How to Make Meta Health & Wellness-Compliant Ads that Don't Flag Policy Violations?
With the Andromeda update, your creative is a strong targeting signal, and there's a way to reach out to your target audience without violating Meta's health & wellness policy.
Suppose your product is a weight-loss product.
Bad Creative: "Buy this for weight loss." (Flags policy).
Good Creative: A person struggling to button their jeans, with the text "Ready for a change?" (Calls out the core desire without using restricted words).
But ads are only one-third of the solution.
But first, do you know how Meta sees your brand?
Before fixing your ads or implementing server-side tagging, you need to know where you stand. Meta's automated review scans your landing page, product descriptions, and health claims to classify your brand.
If you're already flagged under Health & Wellness, fixing your creative alone won't help.
Use the below Audit to see exactly how Meta classifies your domain, and what's triggering your restriction.
The other two parts require server-side setup, which decouples what the Meta bot sees from what the user sees.
How does Server-side help you run Meta Health & Wellness Compliant Ads without policy Restrictions?
When a user clicks your ad, Meta automatically installs first-party cookies on the landing URL (like _fbp and _fbc).
If this domain is flagged, those cookies, along with your UTMs, inherit the restriction.
A compliant server-side setup fixes this by changing the entry point, not the user journey.
Here’s how it works:
Step 1: Send users to a clean landing domain
You run all ads to a clean, compliant domain (e.g., wellness-daily.com).
This domain contains no PHI keywords and carries no restriction history.
Meta scans this domain → sees neutral content → no restrictions.
Step 2: Preserve cookies and UTMs using server-side
When the user lands here:
_fbp, _fbc, and all UTMs fire on the clean domain
Your server captures them.
Then passes the user to your real site (your actual store)
Nothing breaks in the user journey.
Step 3: Unify activity from both domains
Even though the purchase happens on your main site, your server:
links the session data from the clean domain
associates clicks, views, ATC, purchase
and then sends 100% compliant, cleansed, PHI-free events to Meta
Step 4: Scrub any sensitive data before Meta sees it
Input (user buys): 50mg THC Mixed Fruit Gummies
Server-Side Scrub: Detects “THC” → replaces with a neutral label
Output (Meta sees): Mixed Fruit
The sensitive term never enters Meta’s systems.
No PHI. No restriction :)
This is the difference between a browser pixel and a native server-side setup.
Where server-side becomes your long-term moat
A server-side setup is not a hack.
It’s infrastructure. It gives you:
full control over what you send
full control over what you remove
clean conversion signals
deduplication keys
hashed PII handling
compliant audience building
resilience against domain flags
insulation from future Meta updates
And because the logic runs on your own server, it is:
browser-proof
cookie-proof
policy-proof
future-proof