Die meisten FlowConsent-Probleme folgen fünf Mustern, und jedes hat eine eingebaute Prüfung, die es identifiziert: der Installationsassistent für Probleme mit dem Code, 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 liegt es am Code: Er 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 Code zu Ihrem Banner passt. Häufige Ursachen hinter seinen Befunden:
- der Code wurde eingefügt, aber die Website nie veröffentlicht (Webflow und die meisten Website-Baukästen liefern Custom Code erst bei der Veröffentlichung aus);
- der Code stammt von einem anderen Banner oder Workspace: Der Lizenzcode in der URL passt nicht;
- der Code steht im Body oder in 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 Skript.
Ö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 Skripte in die Seite gelangen, die es vor der Ausführung abfangen kann.
Die Konformitätsseite 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 es 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.