Webflow has no native Meta integration, so every pixel on a Webflow site was put there by hand. That is where the gaps come from. This is the audit we run on a Webflow project before we touch a campaign: the failure points specific to Webflow, the checks that confirm each one, and what to do about what you find.
Webflow gives you three ways to get a Meta pixel onto a site and no way to connect one in a single click. You can paste it into project-level custom code, paste it into a single page's custom code, or load it through a Google Tag Manager container. All three work. None of them announce themselves to the others.
That is the whole problem in one sentence. There is no settings screen that says "your Meta pixel is connected." There is only code, spread across places that different people edited at different times, and a published site that may or may not reflect any of it.
The typical history goes like this. A designer drops the pixel into the homepage's page settings because that is the page open at the time. A year later a marketer adds GTM at the project level and puts the pixel in there too. Nobody removes the first copy. Now the homepage fires PageView twice, the CMS template pages fire once, and a set of landing pages built before GTM went in fires nothing at all. Nothing in Webflow will tell you any of that.
Then there are forms. A native Webflow form submit is invisible to the Meta pixel by default: the form posts, the success state swaps in, the URL does not change, and no event fires. Lead-generation sites run for months on PageView only. And custom code does not run in the designer, so what you see while building is never proof of what visitors get.
Six findings cover most of what we see. Work through them in this order, because the first one changes what the rest of your data means.
Page settings in Webflow carry their own head and body custom code, and that code runs on that page only. It is the fastest place to paste a pixel and the easiest place to forget you pasted it. The result is partial coverage: the homepage tracks, the pricing page does not, CMS collection templates do not, and any page added later does not.
Why it matters: partial coverage is worse than no coverage, because the account still reports numbers. Retargeting audiences fill up only from the pages that happen to be tracked, landing pages built for a campaign drop out of the funnel entirely, and you cannot tell from the reporting that half your traffic was never seen.
The mirror image of the first problem. The same pixel ID loads once from project-level custom code and again from a Google Tag Manager container, or twice from two different tags inside the same container. Every page load sends PageView twice, and any event covered by both layers doubles with it.
Why it matters: your reported volume inflates and Meta optimizes against a signal that overstates how often people act. Deduplication does not save you here. The event_id mechanism matches a browser event to a server event. Two browser pixels firing the same event are two real events as far as Meta is concerned.
Webflow forms need help to become conversions. There is no toggle that turns a form submit into a Meta standard event. You need one of three things: a script that listens for the submit or for the success state appearing and calls the Lead event, a Google Tag Manager trigger doing the same job, or a redirect to a thank-you page that fires Lead on load. The redirect is the most reliable of the three because a real page load is easy to verify and hard to break, and it gives you a URL you can also use as a custom conversion.
Why it matters: without a Lead event you cannot run lead-optimized campaigns properly. Meta is bidding toward whatever event you gave it, and if the only event is PageView, it will find you people who load pages.
Publishing in Webflow is per domain. You can publish to the webflow.io subdomain, to a custom domain, or to both, and the checkbox state at publish time decides which. A pixel added and published to staging only will pass every test you run on staging and be absent from the site your ads point at. The reverse also happens: code removed on staging while the custom domain still serves the old build.
Webflow Ecommerce does not send Meta events for you. Purchase has to be added as event code on the order confirmation step, and it has to carry the order value and the currency. Purchase code written quickly often ships without them, or with a hard-coded value that never changes. A Purchase without value and currency tells Meta a sale happened but not what it was worth, so value-based bidding has nothing to optimize toward and your ROAS column stays empty.
Consent tools on Webflow are almost always third-party embeds, and many of them are configured to block marketing tags until the visitor accepts. The embed remembers the consent you gave it months ago, which is why the pixel looks healthy every time you check it yourself. Visitors in an enforced region are served a different page than you are, and the difference surfaces later as analytics sessions Meta never received. Test in a private window from a region where your banner is enforced.
An hour, start to finish, on the published site. This is the sequence we use.
Open your live custom domain in a normal browser window. Not the designer preview, not the webflow.io staging URL. Custom code does not execute in the designer canvas, so anything you check there tells you nothing. If the live domain and staging disagree, republish to both and note which build was serving your ad traffic.
Open Project settings and read the head and body custom code fields. Then open page settings on a sample of pages: the homepage, a CMS collection template, a pricing or contact page, and at least one campaign landing page. Search each field for fbq and connect.facebook.net. Write down every pixel ID and where it came from. Two IDs is a different problem from one ID appearing twice, and you want to know which you have before you change anything.
If a Google Tag Manager container loads on the site, open it and read what is inside. Look for Meta pixel tags, the pixel IDs they carry, the triggers attached to them, and whether a base pixel tag and a custom HTML tag are both loading the same ID. This is also where you find events firing on triggers that no longer match your site, such as a form-success trigger pointing at a class name that was renamed during a redesign.
Install the Meta Pixel Helper extension and visit one page per template: the homepage, a static page, a CMS template page, a landing page, and the ecommerce product and checkout steps if you run them. Template type is the unit that matters on Webflow, because code lives per page and per template rather than per section. Pixel Helper is fast at spotting a second pixel ID and at showing missing parameters.
Open developer tools, go to the Network tab, and filter for facebook.com/tr. Each pixel fire is a request you can inspect. The ev parameter is the event name, the id parameter is the pixel ID that sent it, and the rest of the parameters show exactly what was attached. Two requests with the same ev value on one page load is a duplicate you can prove. Then submit a form and watch: if no new request appears, your Lead event does not exist.
Open Events Manager, choose your dataset, and go to Test Events. Copy the test code, open the published site in a private window, and walk the real path: landing page, form submit, thank-you page, and a test order if you run Webflow Ecommerce. Watch each event land and check it for duplicates and for the parameters that should be attached. This is the most useful check on the list because it shows what Meta received, not what your page tried to send. For the cross-platform version of this scoring, our full Meta pixel audit guide covers the fixes in more depth.
Webflow has no native Conversions API integration, so server-side events come from somewhere else: a server-side Google Tag Manager container, a CAPI gateway, or your CRM or form backend sending the conversion after it receives the submission. That last option is often the practical one for lead-generation sites, because the CRM holds the email and phone number that lift event match quality and the browser does not.
The check that matters: once server-side events are live, confirm in Events Manager that the event shows both browser and server as connections and that deduplication is being recognized. Two channels sending the same conversion without a shared event ID is worse than one channel sending it well.
Server-side tracking is a second path for the same events, not a replacement for a clean pixel. If you want the longer comparison, we wrote it up in Meta pixel vs Conversions API. And once your events are trustworthy, expect your reported numbers to move, which is the subject of why your ROAS numbers are wrong.
Most of steps 2, 3, and 5 can be done for you. Our free Meta pixel audit detects Webflow automatically and scans your live published site the way an outside browser sees it: which pixel IDs load, whether the same ID appears through more than one install path, which funnel events it can find across your key pages, whether the events it can read carry value, currency, and content IDs, what else is in your tracking stack, and whether a consent banner is sitting in front of your tags. It opens your Google Tag Manager container and reads the Meta tags inside it, and it checks Meta's public config for each pixel ID it finds.
It is upfront about its limits. Events that only fire after a form submit, anything behind a login, and Conversions API internals cannot be verified from outside, so the scan marks them as needs verification rather than guessing. Those are the items you confirm with Test Events in step 6, and we spell out exactly where that line sits on the audit methodology page. The scan takes about 20 seconds, needs no login and no pixel ID, and gives you a prioritized fix list.
On other platforms the failure points differ. We have the same walkthrough for Shopify, Squarespace, and Wix. And if you would rather someone else own the whole thing, that is what our B2B and SaaS practices do: tracking verified before any campaign work, then kept verified while spend scales.
Because it was installed as page-level custom code instead of project-level custom code. Page settings in Webflow hold their own head and body code, and that code only runs on that one page. Paste the pixel there and it covers the homepage while every other page, every CMS template, and every landing page stays untracked. Move the base pixel to Project settings so it loads site wide, then remove the page-level copy so you do not end up with two installs on the page that already had one.
One place, chosen deliberately. Either the base pixel goes in project-level head custom code and standard events go in page-level code where they belong, or everything goes through a Google Tag Manager container that itself loads from project-level head code. Both work. What breaks sites is running both at once, because the pixel then loads twice on every page and your PageView count doubles.
Because nothing told them to. A native Webflow form submits and swaps in the success state, and the Meta pixel has no idea that happened. There is no built-in setting that turns a form submit into a Lead event. You have to add it: a script that listens for the submit or watches for the success message and calls the Lead event, a Google Tag Manager trigger doing the same job, or a redirect to a dedicated thank-you page that fires Lead on load. Until one of those exists, the pixel is recording traffic and no conversions.
Yes. Custom code you paste into project or page settings does not run in the designer canvas, and it only reaches visitors once you publish. It also publishes per domain, so a site published to the webflow.io staging domain but not to the custom domain leaves your live site running the previous code. Always test the published custom domain in a normal browser window, not the designer preview and not the staging URL.
With event code you add yourself. Webflow does not send a Meta Purchase event for you, so the order confirmation step needs a script or a Google Tag Manager tag that fires Purchase with the order value and the currency attached. A Purchase without value and currency tells Meta a sale happened but not what it was worth, which leaves value-based bidding and ROAS reporting with nothing to work from. Verify it with a real test order in Events Manager Test Events.
Every Webflow account we take on starts with tracking verified end to end: one install layer, every template covered, form submits firing real Lead events, deduplication confirmed. Scan your site yourself in 20 seconds, or have us walk it with you.