Troubleshooting
Common issues and how to diagnose them.
Common issues
Banner does not render | Open the browser console and look for a CookieLint log line. If absent, the snippet is not in <head>. If present and the banner still does not show, the visitor likely has a persisted decision; reset by clearing the cl:consent:<siteId> key from localStorage and reloading. |
Banner appears in dev but not production | The current page hostname must be in the site’s declared domains list (Site settings > Domains). The runtime refuses to render on any host outside the list. Add a wildcard such as *.example.com to cover staging and preview deploys. |
GCM tags still fire after reject | A Google tag was likely loaded by a hand-rolled <script> tag rather than via gtag bootstrapping. Either move the loader to use the gtag default-deny pattern, or add data-cookielint-category="MARKETING" to the <script> so the blocking engine gates it directly. |
Inline analytics runs before banner installs | Module scripts are implicitly deferred, so they run after the HTML parser finishes. An inline <script> earlier in <head> can race ahead of the engine. Add data-blocking-mode="strict" to the snippet (see the strict-load example in Quick start), or move the snippet above the inline tag. |
Wrong regime shown to a visitor | Regime selection runs against the visitor’s detected country code. If a VPN or corporate proxy rewrites geo, the regime will follow that. Use the Override regime per visitor field in the editor only when you are absolutely sure; the default geo logic is correct for the vast majority of traffic. |
Cookie still set after reject | The cookie’s name is likely not in the vendor database under any matching pattern. Add it manually in the dashboard (Site settings > Cookies) with the correct category, then republish; the blocking engine will gate it on next page load. |
Scanner reports a cookie our app does not set | Third-party SDKs (chat widgets, embedded videos, A/B testing tools) often set cookies under their own domain that look unfamiliar. Click the row to see the request URL that initialised it; that tells you which vendor SDK is responsible. |