Find the script that runs before the visitor answers and hold it back

A script sends requests before the visitor answers when it keeps its own type, exists a second time without a tag, or reaches the page outside your markup. Other scripts run on page load by design, through page_load_consent_levels, implied consent, or an untagged Google tag under Google Consent Mode. Untagged Meta Pixel, TikTok Pixel, Microsoft Clarity, or HubSpot code that takes a consent command contacts its host before the answer by design too. TermsFeed Free Cookie Consent holds only <script type="text/plain" data-cookie-consent="..."> elements, and every other script runs as the browser loads it. The EU ePrivacy Directive and the UK Privacy and Electronic Communications Regulations (PECR) require consent before most analytics and advertising cookies are set.

Find the early request first. Close every private window, open a new one, open DevTools, and select the Network tab. Type the host the tool loads from or sends to in the filter, such as google-analytics.com, facebook.com/tr, or clarity.ms, and load the page without clicking anything. Each request that appears before you answer, other than one by design, comes from a script you need to fix.

Cause 1: The script tag is wrong or incomplete

A script runs at once when it keeps its own type, and never runs with a misspelled category, so check both attributes on every script tag. Cookie Consent reads a script only with type="text/plain" and a data-cookie-consent attribute that names one of the 4 categories exactly, in lower case.

Search the page source (Ctrl+U) for the tool ID, such as the G- measurement ID of Google Analytics 4 or the Meta pixel ID. Read every script tag of the snippet that holds it. A search for the ID finds the inline configuration too, which does not name a host. Where the snippet does not carry an ID, search for the host it loads from. A script that keeps its own type runs before the answer, and the other mistakes keep the script from running.

  • A part of the snippet keeps its type. Some vendor snippets have 2 script tags, such as the external gtag.js tag and the inline configuration of Google Analytics 4 and Google Ads. Every script tag of the snippet needs both attributes.
  • The category is misspelled or capitalized. data-cookie-consent="Tracking" or "analytics" never runs, and debug mode prints Invalid cookie-consent tag level for JavaScript script: Tracking. The 4 values are strictly-necessary, functionality, tracking, and targeting.
  • The attribute is missing. A type="text/plain" script without data-cookie-consent never runs, and Cookie Consent does not print a line about it.
  • The category is not in use. A tagged script of an optional category missing from notice_banner_purposes_levels never runs, and debug mode prints JavaScript script of the category "tracking" never runs: the category is not in notice_banner_purposes_levels.

Correct each script tag that shows one of these mistakes. Compare it with the rules in tagging your scripts.

Cause 2: A second, untagged copy of the script exists

A tool added twice, once tagged and once untagged, sends requests from the untagged copy before consent. A theme setting, an old snippet in a footer file, or a plugin often holds the second copy.

Search the page source (Ctrl+U) for the tool ID. One Google tag holds its ID twice, in the gtag/js address and the config call, so count snippets, not matches. A second snippet with that ID whose script tags lack type="text/plain" is an untagged copy that runs beside the tagged one. Remove every copy except one tagged copy, then clear the page cache.

Cause 3: Your platform adds the script itself

Site builders and plugins add tracking through their own settings, outside your markup, so Cookie Consent never sees the script. The Google & YouTube app in Shopify, the built-in Google Analytics field in Squarespace, and Site Kit in WordPress all add Google tags this way.

On Squarespace and WordPress, a script added this way appears in the page source, but not in any code you pasted. Shopify runs app pixels and custom pixels in a sandbox outside the page source, so on Shopify look for their requests in the Network tab too. Settings > Customer events in the Shopify admin lists them.

Shopify runs those pixels by the consent recorded in the Customer Privacy API. An early request from an app pixel or a custom pixel means a region is not selected in Customer privacy. A custom pixel with its Permission set to "Not required" runs before consent too. In the Customer privacy section of that pixel, set Permission to Required, select its data purposes, and click Save. Select every region and forward the answer with Add a Cookie Banner to Shopify.

Outside Shopify and Wix, remove the tool from the platform setting and paste its snippet yourself, tagged. On Wix, keep these tools in Marketing Integrations instead, because Wix runs Google Analytics, Google Tag Manager, and the Meta and TikTok pixels only from there. Marketing Integrations follow the Wix consent banner, so keep that consent banner on. Find the setting for each platform in Install a Cookie Banner on Any Website.

Cause 4: A tag manager loads the script

An untagged tag manager runs every tag it holds on page load, so each of those tags fires before consent. Cookie Consent holds the tag manager only when the snippet that loads it is tagged.

Clear the Network filter, type gtm.js or the file name of your tag manager script, and reload. A request for it before you answer means the tag manager runs untagged, or its category runs on page load through page_load_consent_levels or implied consent. An untagged container is intended only for Google tags under Consent Mode, which send cookieless pings by design.

The 4 categories are independent switches, so a container tagged targeting runs its tracking tags for a visitor who accepts only targeting. Keep the tags of one category in each container, and tag the snippet that loads it with that category. The other fix is to remove the tracker from the tag manager and paste its snippet into your page, tagged. Read every tagging rule in Block Scripts Until Consent.

The page_load_consent_levels option and implied consent run the listed categories before the visitor answers, by design. Express consent, the default, releases only strictly-necessary tagged scripts before the answer when page_load_consent_levels is not set.

Add "debug": true to the configuration object and publish the change. Close every private window, load the page in a new one, and read the debug line that shows what page load allowed, such as consentExpress loadInitialCookiesForNewUser: strictly-necessary (true), functionality (false), tracking (true), targeting (false). A true for the category of your script means page load ran it.

A line that names consentExpress points to page_load_consent_levels, so remove that category from the option. A line that names consentImplied points to implied consent. Set "consent_type": "express" and "page_load_consent_levels": ["strictly-necessary"], because the code the generator writes for implied consent lists all 4 categories in that option. Compare the 2 modes in Express and Implied Consent.

A Google tag loaded untagged with Google Consent Mode v2 defaults set to denied sends requests before consent, without cookies. Google calls these cookieless pings, and they are how Consent Mode works when the Google tag runs on page load.

The request to google-analytics.com/g/collect carries gcs=G100 while both storage signals are denied. Google uses the gcs parameter to send the ad_storage and analytics_storage choices. No _ga cookie appears in the Application tab.

So that the Google tag does not send a request before consent, tag it with tracking, which is basic consent mode. Set "user_consent_saved_on_page_load": true, so user_consent_saved sends the update on every later page too. Compare both methods in Set Up Google Consent Mode v2.

A tracking cookie in the Application tab without a matching request usually comes from an earlier visit, because Cookie Consent does not delete cookies that other scripts set. A visitor who accepted, then declined, keeps the cookies the tools set while they ran. Neither the answer nor the 365-day expiry of the consent removes them.

Cookie Consent writes cookie_consent_level before any answer, on the first page load, and in implied mode cookie_consent_user_consent_token too. These cookies hold the consent state, not tracking data. Close every private window and test in a new one, and remove the tracking cookies on withdrawal with Rejecting does not delete cookies already set.

In express mode with the default page_load_consent_levels, no tagged script sends a request before the answer, and the first one follows a click on the "I agree" button. In implied mode, requests on page load are by design. A Google tag under Consent Mode differs: its cookieless collect requests appear before the answer too. Test both answers. Publish your change and clear any page cache first.

  1. Close every private window, open a new one, and open DevTools with F12.
  2. Open the Network tab and type the host the tool loads from in the filter, such as connect.facebook.net for a tagged Meta Pixel, or collect for a Google tag.
  3. Load the page and confirm that no request appears before you answer. For a Google tag under Consent Mode, only collect requests with gcs=G100 appear, and the Application tab does not list a _ga cookie.
  4. Click the "I agree" button and confirm that the first request appears, without a page reload, or on the reloaded page when page_refresh_confirmation_buttons is on. For a Google tag under Consent Mode, confirm that the collect requests carry gcs=G111, or gcs=G101 without targeting in use, and that the _ga cookie appears in the Application tab.
  5. Close every private window, open a new one, open DevTools with the same Network filter, and load the page. Click the "I decline" button, and confirm that no request appears. For a Google tag under Consent Mode, only collect requests with gcs=G100 appear, and no _ga cookie is stored.