# FlowConsent-Fehlerbehebung Die fünf häufigsten FlowConsent-Probleme und ihre Lösungen: fehlendes Banner, Google-Tag trotz Ablehnung, unerwartete Urteile, Scans mit Fehler. > Canonical: https://www.flowconsent.com/de/doc/troubleshooting > Last updated: 2026-07-30 Die meisten FlowConsent-Probleme folgen fünf Mustern, und jedes hat eine eingebaute Prüfung, die es identifiziert: der Installationsassistent für Snippet-Probleme, der Konsolenfehler und die Telemetrie für das Consent-Mode-Rennen, der Compliance-Scan für alles, was leckt. Gehen Sie das Symptom durch, das zu Ihrem passt. ## Das Banner erscheint nicht Fast immer das Snippet: fehlt auf der Seite oder trägt den falschen Lizenzcode. Starten Sie den **Installationsassistenten** (Builder → Integration): Er ruft Ihre Live-Seite serverseitig ab und stellt genau das fest — Loader gefunden oder nicht, und ob der Lizenzcode im Snippet zu Ihrem Banner passt. Häufige Ursachen hinter seinen Befunden: - das Snippet wurde eingefügt, aber die Website nie **veröffentlicht** (Webflow und die meisten Site-Builder liefern Custom Code erst beim Publish aus); - das Snippet stammt von einem anderen Banner oder Workspace — der Lizenzcode in der URL passt nicht; - das Snippet steht im Body oder einem Footer-Widget statt im ``. ## Ein Google-Tag feuert trotz Ablehnung Das ist das **dataLayer-Rennen**: Ein `gtag('config')` gelangte vor den Einwilligungs-Standardwerten in den dataLayer, Google hat es also ohne jede Einschränkung verarbeitet — Cookies werden gesetzt, was auch immer das Banner tut, und keine CMP kann das nachträglich verhindern. Zwei Prüfungen identifizieren es sofort: - die Browserkonsole zeigt einen FlowConsent-Fehler mit den Tag-IDs, die vor dem Consent Default eingetroffen sind (das Banner meldet ihn auch als `ConsentDefaultRaceLost`-Telemetrie); - der Installationsassistent meldet „Google-Tag vor dem Stub" und markiert auf Webflow gezielt ein von den Website-Einstellungen injiziertes Tag. Die Lösung: das Tag aus dem Kanal entfernen, der es zu früh injiziert — auf Webflow die GA Measurement ID in **Site settings → Apps & Integrations** — und den Dienst in **Builder → Services** deklarieren. Dann den Consent-Mode-Stub **an erster Stelle** im `` halten. Siehe den [Webflow-Leitfaden](/de/doc/webflow-integration). ## Der Scan meldet „Verstöße", und Sie wissen nicht warum Das Urteil listet, welche Tracker-Domains kontaktiert und welche Dienste identifiziert wurden. Überrascht es Sie, läuft das Tag meist über einen Kanal, den das Banner zum Injektionszeitpunkt nie sieht: - eine Site-Builder- oder Hosting-Integration (Webflow-Einstellungen, ein WordPress-Plugin), die das Tag nativ lädt; - ein Tag-Manager-Container, der Tags unabhängig vom Einwilligungsstatus feuert; - ein von einem früheren Entwickler fest in ein Template codiertes Script. Öffnen Sie den [Nachweisbericht](/de/doc/proof-report) des Scans: Die Beispiel-URLs zeigen, wohin jede Anfrage ging, was meist identifiziert, wer sie injiziert hat. Das Banner blockiert Tags per URL-Muster, egal über welchen Kanal sie kommen — aber nur, wenn sie als Scripts in die Seite gelangen, die es vor der Ausführung abfangen kann. ## Die Compliance-Seite warnt vor einem nicht deklarierten Cookie Der letzte Scan hat Cookies beobachtet, die Ihr Banner nicht deklariert — weder über einen aktiven Dienst noch in Ihren benutzerdefinierten Cookies. Typischerweise hausgemachte First-Party-Cookies (Attribution, Warenkorb-Session…), die kein Dienstkatalog kennen kann; nur ein Scan entdeckt sie. Die Warnung bietet eine **Deklaration mit einem Klick** in die benutzerdefinierten Cookies des Banners. Zwei Nacharbeiten bleiben bei Ihnen: den **Zweck** des Cookies ausformulieren (die Warnung kann ihn nicht erraten) und das Banner **neu veröffentlichen**, damit die öffentliche Cookie-Liste ihn ausweist. ## Der Scan endet mit „error" Ein `error`-Urteil bedeutet, dass der Scan nicht abgeschlossen werden konnte — meist ein Timeout auf einer langsamen oder schweren Seite — und **daraus keine Schlussfolgerung gezogen werden kann**: Es ist weder konform noch ein Verstoß und löst nie einen Regressions-Alarm aus. > [!TIP] > Wiederholen Sie den Scan mit dem Profil **ultra**: Es erweitert das Budget auf rund 190 s pro Seite — genug für Seiten, die unter dem Standardprofil **deep** in den Timeout laufen. Schlägt es weiterhin fehl, prüfen Sie, ob die URL öffentlich erreichbar ist — der Scan surft aus Europa (`eu-central-1`), eine geoblockierte oder passwortgeschützte Seite lässt sich nicht prüfen.