Fix guide · Webflow · medium · about 30 min

Facebook click ID (fbclid) lost on Webflow

For the finding “Click ID from Meta ads is not stored”. Also for: Any website, Shopify, WordPress, Framer.

What this means

When someone clicks a Meta ad, Meta adds ?fbclid=... to the link. The Meta Pixel (still often called the Facebook Pixel) on your Webflow site should save it in the first-party cookie _fbc, so later events (a form submission, a purchase) can be tied back to the ad click. On your site, the click ID did not end up in _fbc.

Why it costs you money:

  • Meta has a weaker link between ad clicks and conversions, which lowers event match quality and can lower reported results.
  • Campaigns optimize on less complete data, so you may pay more per result.
  • If you send server events through the Conversions API, they usually rely on the same _fbc value, so they lose it too.

How to confirm it yourself

Our check opens your page in a browser in the EU as if arriving from a Meta ad, with a test click ID in the URL, accepts the cookie banner and looks for _fbc. If our report shows a redirect chain, start there: it often shows exactly where the click ID was dropped.

  1. Open a private (incognito) window, open developer tools (F12) on Network, and tick Preserve log.
  2. Open the exact URL your ads use, with a made-up click ID added: https://yourdomain.com/landing?fbclid=test123. (This sends a normal page view to your own pixel. It does not create an ad click.)
  3. If the first request is a redirect (301, 302, 307, 308), check its Location header. Does the new address still contain ?fbclid=test123?
  4. Accept the cookie banner, wait a few seconds, then go to Application > Cookies (Chrome) or Storage > Cookies (Firefox) and look for _fbc. It should look like fb.1.<timestamp>.test123. You should also see _fbp, the pixel’s browser ID.

How to fix

Work through the chain: the link must arrive with fbclid, the pixel must run on that page, and it must be allowed to write cookies.

  1. Point your ads at the final address. Webflow redirects your other connected domains (for example the version without www) to the default domain, set in Site settings > Publishing > Production with Make default. In our tests on Webflow-hosted sites, Webflow also redirected http to https and removed a trailing slash from page addresses, and all of these redirects kept the query string, including fbclid. Still use the exact final address in every ad (default domain, https, no trailing slash), so the visitor lands without a redirect.
  2. Do not send ads through Webflow 301 redirects. In our tests, redirect rules from Site settings > Publishing > 301 redirects sent visitors to the new address without the query string, so ?fbclid=... was lost before the pixel could run. This includes the redirect Webflow creates when you change a page’s slug and tick Permanently redirect the old URL to this new one. Check every ad URL against your redirect list, and update ads to link to the new page directly. Test with ?fbclid=test123 as described above after any change.
  3. Check localized pages. Webflow’s 301 redirects do not apply to localized subdirectories, so /es/old-url needs its own rule. The automatic routing to a visitor’s preferred locale (on Localize plans that include it) uses a 302 redirect; in our test it kept the query string, but link ads for a given language to that locale’s URL anyway.
  4. Check redirects outside Webflow, such as a domain registrar’s forwarding, rules in a proxy or CDN in front of the site, link shorteners or campaign link tools. These commonly drop the query string.
  5. Check scripts that clean the address bar. A script that removes query parameters after the page loads (for example Finsweet’s removequery Attribute, or custom “clean URL” code) can erase fbclid before a consent-gated pixel starts. Remove it from landing pages, or make sure it runs only after the pixel has loaded.
  6. Make sure the pixel runs on the landing page after consent. _fbc is written by the pixel. If it only starts on the next page, fbclid is no longer in the address. With Webflow’s built-in integration and Delay for cookie consent, something must call fbq('consent', 'grant') right after Accept on the same page; with GTM, the Meta tag must fire on the consent event, not only on the next page view. See “Meta Pixel not firing after cookie consent on Webflow”.
  7. Check that first-party cookies are on. In Meta Events Manager, open Data sources, select your pixel and open Settings. Under Cookie settings, Cookie usage shows whether first-party cookies are on (the default). If they were turned off, click Edit, turn First-party cookies on and save.
  8. Check that your consent tool keeps the cookie. After Accept, _fbc should stay, including on the next page. Some tools delete cookies when the visitor changes preferences; Finsweet’s older Cookie Consent documents that it erases cookies and re-runs scripts in that case.
  9. Publish to your custom domain after any change.

Common causes

  • Ads link to an old URL that Webflow now 301-redirects (often after a slug change), and the redirect drops the query string.
  • A registrar forwarding rule, proxy rule or link shortener in front of the site drops fbclid.
  • A script removes query parameters from the address before the pixel starts.
  • The pixel waits for consent and only starts on the next page.
  • First-party cookies are disabled for the pixel.

How to verify the fix

  1. Repeat the test above using the exact ad URL: no redirect drops ?fbclid=test123, and after accepting cookies _fbc ends with test123.
  2. Open another page of the site: _fbc is still there.
  3. Re-run the check on IsPixelWorking. The issue should be gone, and the redirect chain in the report (if any) should keep the click ID.

Sources