Troubleshooting FlowConsent

Most FlowConsent problems fall into five patterns, and each has a built-in check that identifies it: the installation assistant for snippet issues, the console error and telemetry for the Consent Mode race, the compliance scan for anything that leaks. Work through the symptom that matches yours.

Almost always the snippet: absent from the page, or carrying the wrong license code. Run the installation assistant (Builder → Integration): it fetches your live page server-side and reports exactly that — loader found or not, and whether the license code in the snippet matches your banner. Common causes behind its findings:

the snippet was pasted but the site was never published (Webflow and most site builders only ship custom code on publish);
the snippet comes from another banner or another workspace — the license code in the URL does not match;
the snippet is in the body or a footer widget instead of the <head>.

A Google tag fires despite refusal

This is the dataLayer race: a gtag('config') entered the dataLayer before the consent defaults, so Google processed it with no restrictions — cookies are set no matter what the banner does, and no CMP can prevent it after the fact.

Two checks identify it immediately:

the browser console shows a FlowConsent error naming the tag IDs that entered before the consent default (the banner also reports it as ConsentDefaultRaceLost telemetry);
the installation assistant flags "Google tag before the stub", and on Webflow specifically flags a tag injected by the site settings.

The fix: remove the tag from the channel that injects it early — on Webflow, the GA Measurement ID in Site settings → Apps & Integrations — and declare the service in Builder → Services. Then keep the Consent Mode stub first in your <head>. See the Webflow guide.

The scan says "Violations" and you don't know why

The verdict lists which tracker domains were contacted and which services were identified. When it surprises you, the tag usually runs through a channel the banner never sees at injection time:

a site-builder or hosting integration (Webflow settings, a WordPress plugin) loading the tag natively;
a tag manager container firing tags regardless of consent state;
a script hardcoded in a template by a past developer.

Open the proof report of the scan: the sample URLs tell you where each request went, which usually identifies who injected it. The banner blocks tags by URL pattern whatever channel injected them — but only if they enter the page as scripts it can intercept before execution.

The last scan observed cookies that your banner does not declare — neither via an active service nor in your custom cookies. Typically first-party, home-made cookies (attribution, cart session…) that no service catalog can know about; only a scan discovers them.

The alert offers a one-click declaration into the banner's custom cookies. Two follow-ups remain yours: fill in the cookie's purpose text (the alert cannot guess it), and republish the banner so the public cookie list reflects it.

The scan returns "error"

An error verdict means the scan could not finish — most often a timeout on a slow or heavy page — and no conclusion can be drawn from it: it is neither compliant nor a violation, and it never triggers a regression alert.

The banner does not appear

A Google tag fires despite refusal

The scan says "Violations" and you don't know why

The Compliance page warns about an undeclared cookie

The scan returns "error"