FlowConsent-Fehlerbehebung
Die fünf häufigsten FlowConsent-Probleme und ihre Lösungen: fehlendes Banner, Google-Tag trotz Ablehnung, unerwartete Urteile, Scans mit Fehler.
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
<head>.
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 <head> halten. Siehe den Webflow-Leitfaden.
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 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.