# Troubleshooting FlowConsent The five most common FlowConsent issues and their fixes: missing banner, a Google tag firing despite refusal, unexpected verdicts, scan errors. > Canonical: https://www.flowconsent.com/en/doc/troubleshooting > Last updated: 2026-07-30 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. ## The banner does not appear 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 ``. ## 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 ``. See the [Webflow guide](/en/doc/webflow-integration). ## 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](/en/doc/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 Compliance page warns about an undeclared cookie 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. > [!TIP] > Retry, switching the profile to **ultra**: it extends the scan budget to ~190 s per page, enough for pages that time out under the default **deep** profile. If it still fails, check that the URL is publicly reachable — the scan browses from Europe (`eu-central-1`), so a geo-blocked or password-protected page cannot be verified.