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

A tracking script that runs before the visitor answers comes from a setting, a vendor script Type, or code outside the Cookie Consent kit. The Cookie Consent kit in TermsFeed AutoTerms holds back only the scripts on its Vendor Scripts tab. Of those, it holds back only the scripts in an optional category that the visitor has not accepted and page_load_consent_levels does not list. Every other script on the page runs as WordPress prints it.

Private windows share their cookies while any of them is open, so close every private window between tests. Then open a new one, open DevTools, filter the Network tab for the tool host, and load the page before you click anything on the consent banner. The host is google-analytics or googletagmanager for Google Analytics 4, and facebook for Meta Pixel. A request to that host before you answer shows a script that runs before consent, except for a Google tag in Advanced Consent Mode.

Cause 1: Optional categories run on page load

A vendor script runs before the visitor answers when its category is in page_load_consent_levels, the list of categories the kit runs on page load. The Compliance preference "ePrivacy Directive (i.e. OK button)" puts all 4 categories in that list. A list edited by hand on the Configuration Parameters tab keeps extra categories under the GDPR preference too.

Read both settings, because the Customization tab alone does not show a list edited by hand. Open TermsFeed > Compliance Kits, click the "Configure" button in the Cookie Consent box, and read the Compliance preference. Then open the Configuration Parameters tab and read page_load_consent_levels. Any category beyond "strictly-necessary" runs its vendor scripts before consent.

Fix the setting that put the categories there. Read how the list follows the preference in Cookie Banner JSON Settings in WordPress.

With the ePrivacy preference, select "GDPR Directive (i.e. I Agree & I Decline buttons)" and click the "Save Changes" button. The plugin resets the list to ["strictly-necessary"] with the new preference.

With the GDPR preference already selected, open the Configuration Parameters tab, set "page_load_consent_levels": ["strictly-necessary"], and click the "Save Changes" button. Selecting the GDPR preference again leaves the edited list in place, because only a change of preference resets it.

Clear the page cache, close every private window, and repeat the test in a new one.

Cause 2: The vendor script has the type "Strictly Necessary"

A vendor script of the Type "Strictly Necessary (i.e. account login related cookies)" runs on every page load, because the visitor has no switch to refuse that category. The category is meant for code the site needs to work, such as a login or a shopping cart. A tracking tool filed there runs before consent on every page.

The Vendor Scripts tab and the page source both show the category. The Type column of the row shows strictly-necessary, and the script in the page source carries data-cookie-consent="strictly-necessary".

Replace the row with one that carries a tracking or advertising Type. Choose the Type of each tool with Block WordPress Scripts Until Consent.

  1. Copy the tool code again from the vendor, because a row has no edit button.
  2. Click the "Delete" button in the row.
  3. Add the code again with the Type "Tracking and Performance (i.e. Google Analytics)" or "Targeting and Advertising (i.e. Google AdSense, Google AdWords)", and click the "Add vendor script" button.
  4. Click the "Save Changes" button.
  5. Clear the page cache, close every private window, and repeat the test in a new one.

Cause 3: The script comes from the theme or another plugin

The AutoTerms plugin holds back only the code on the Vendor Scripts tab, so a tag that your WordPress theme or another plugin prints runs at once. Site Kit by Google, Meta Pixel plugins, WooCommerce analytics plugins, and plugins that insert code into the header each print their own tags. A tag pasted into the theme templates or into a theme option runs the same way.

Search the page source for the tool host, such as googletagmanager.com/gtag/js. The kit prints comments ending in "Vendor Script" around each vendor script. A <script> without type="text/plain" outside those comments comes from the theme or another plugin.

As the site owner, move the tag from the plugin or theme into the Vendor Scripts tab. Find more places a script comes from in Scripts Run Before Consent With Free Cookie Consent.

  1. Turn off the tag output in the plugin that prints it, or remove the tag from the theme option.
  2. Add the same tag as a vendor script with the right Type.
  3. Clear the page cache, close every private window, and check in a new one that the request waits for a click on the "I agree" button.

A developer removes a tag that a theme template prints by editing the child theme, then adds the tag to the Vendor Scripts tab. Keep a single copy of each tag on the page, because a second copy outside the kit runs before consent whatever the visitor chooses.

A browser that accepted earlier runs the accepted vendor scripts at once on every page load, which looks like a script that runs before consent. Under the default GDPR preference, optional vendor scripts still wait for a visitor with no saved answer, so the kit needs no change.

Compare your normal window with a new private window opened after you close the others, since that window starts with no cookies. A request to the tool in your normal window and none in the private window before you answer points to your own earlier consent. Read what the consent cookies of TermsFeed Free Cookie Consent 4.2.0 hold in Consent Cookie Storage and Duration in Free Cookie Consent.

Check each script in a new private window, opened after you close the others. To check in your normal window, click the "Update cookies preferences" link at the end of the page. Select the tab of each category you accepted, set its switch to Inactive, and click the "Save my preferences" button. From the next page load on, the vendor scripts of those categories stay blocked until you accept them again.

A Google tag that another plugin or the theme prints without Google Consent Mode v2 defaults sets its cookies and measures in full before the visitor answers. Google Consent Mode v2 is the Google signal that tells the Google tag whether to store cookies. The default Callbacks of the kit switch Google Consent Mode v2 to granted only once the targeting category loads, and they do not set a denied default.

Close every private window, open a new one, and load the page, so no earlier consent hides the result. Type dataLayer in the Console tab and press Enter before you answer the consent banner. An entry with "consent" and "default" before the "config" entry shows defaults. No such entry, or a _ga cookie in the Application tab, means the tag runs without Consent Mode defaults.

As the site owner, let the kit load the Google tag in place of the other plugin.

  1. Turn off the Google tag in the other plugin.
  2. Add the Google tag code as a vendor script with the Type "Tracking and Performance (i.e. Google Analytics)".
  3. Clear the page cache, close every private window, and confirm in a new one that no _ga cookie appears before you click the "I agree" button.

A developer who keeps the Google tag outside the kit makes the Consent Mode defaults the first script in <head>, after only the charset meta. The defaults sit above the Google tag, any Google Tag Manager container, and the Cookie Consent script. WordPress prints the Cookie Consent script at priority 9 of wp_head, so the defaults come from a wp_head action with priority 1. The developer then replaces the default Callbacks of the kit with a user_consent_saved callback that sends the Consent Mode updates, and sets "user_consent_saved_on_page_load": true in the Configuration Parameters. Copy the defaults from Set Up Google Consent Mode v2 With Free Cookie Consent, and edit the Callbacks with Cookie Consent Callbacks in WordPress.

The checks assume the default GDPR preference with page_load_consent_levels at ["strictly-necessary"]. In that default setup, a tool that the kit holds back does not send requests or set tracking cookies until the visitor clicks the "I agree" button.

  1. Clear the page cache, close every private window, open a new one, open DevTools with F12, and type the tool host in the Network filter.
  2. Load your page and confirm that no request to the tool appears before you answer.
  3. Open the Application tab, expand Cookies, and confirm that no cookie from the tool, such as _ga, exists yet.
  4. Click the "I agree" button and confirm that the request to the tool appears, with status 200 for most tools. For Google Analytics 4, change the filter to collect and confirm a collect request with status 204.
  5. Close every private window, open a new one, open DevTools on the Network tab filtered on the tool host, and load your page. Click the "I decline" button and open 2 more pages: no request to the tool appears on any of them.

A consent banner with "notice_banner_reject_button_hide": true in the Configuration Parameters does not show the "I decline" button. To decline on that site, click the "Change my preferences" button, leave every optional category off, and click the "Save my preferences" button.

A Google tag in Advanced Consent Mode, with denied defaults above it, sends cookieless requests before the visitor answers and after a refusal, by design. Check the consent state and the cookies of that setup instead of the requests. Check that the defaults read denied and that no _ga cookie appears before consent with Set Up Google Consent Mode v2 With Free Cookie Consent.