Cookiebot price increase: record what Reject stops before you switch

What is changing in Cookiebot's USD pricing?

Cookiebot's support article, published October 29, 2026, lists new Premium prices per domain per month, in USD, excluding VAT. The new price applies to invoices issued from November 30, 2026 (UTC). Monthly plans see it on every invoice issued from that date. Annual plans move to the new price at the next yearly invoice, and a yearly invoice already issued for the current period is not affected. The change covers everyone billed in USD, regardless of country.

Cookiebot says the exact price for your account, including any discount, is shown in your Cookiebot account. Check that and your latest invoice before you plan around these numbers. The same article says your domains, banners, and settings stay as they are, so the price change on its own does not change what your banner does.

Why record Reject before you switch?

Migration guides tell you to open the browser's Network tab after the new banner goes live and check that it looks clean. That check needs a reference. If you did not save what the old banner let through after Reject, you cannot tell whether the new one blocks the same requests, blocks more, or misses some.

The record you want is a list of hosts, split into three windows:

1. Before any click, while the banner is on screen.
2. After the Reject click, on the same page.
3. On the next page the visitor opens.

On the stores below, each window gave a different result.

How we tested three Cookiebot stores

We tested three Shopify stores that load Cookiebot: Store Q, Store Z, and Store AA. Store Q is the same store as our AppLovin AXON test. We captured it on October 26, 2026, and again on November 2, 2026. We captured Stores Z and AA on November 2, 2026. Where the two Store Q captures differ, this page uses the November 2 numbers.

Each store got three passes from a US connection, each in a new headless Chrome profile with Global Privacy Control off: once without clicking (Fresh), once with Deny (Reject), and once with Allow all (Accept). Each pass waited 12 seconds after the click, then opened the same product page about 16 seconds after it. All timings below are counted from the Deny click, or from Allow all on the Accept pass.

The three banners put Deny in different places.

• Store Q. The first layer shows Customize and Allow all. Deny is inside Customize. On the Reject pass we opened Customize, unchecked Preferences, Statistics, and Marketing, and clicked Deny 10.7 seconds after the page opened.
• Store Z. Deny only appears after you open Customize. An SMS sign-up overlay from another app covered the page and caught normal mouse clicks, so we clicked Customize, Deny, and Allow all with a DOM click() on Cookiebot's own buttons. We did not close the overlay. Deny was clicked 8.5 seconds after the page opened.
• Store AA. Deny is on the first layer, with every category unchecked. We clicked it once, 4.9 seconds after the page opened.

Twelve seconds after Deny, all three stores reported Cookiebot.declined as true, with marketing and statistics false. Shopify's currentVisitorConsent() returned no for marketing, analytics, and preferences on all three.

What did Store Q send after Deny?

On the product page after Deny, the ad pixels in this table sent nothing. On the same page, two did. X sent 2 requests to /i/adsct 2.5 seconds after Deny. TikTok sent an EngagedSession event and an interaction ping 2.7 seconds after Deny, and one more interaction ping 12.7 seconds after Deny. On October 26 the same requests came 2.9, 3.1, and 13.1 seconds after Deny, and every vendor at 0 after Deny was also at 0 on October 26. We did not check whether these were events queued before Deny.

Meta's pixel sent one event, a SubscribedButtonClick with buttonText set to Deny, 0.1 seconds before our script logged the Deny click. Because it falls before Deny in our log, the table does not count it after Deny.

Klaviyo kept loading its on-site scripts and sent 4 /onsite/track-analytics posts after Deny. Impact sent 2 requests on the product page. The AXON pixel logged the Deny click itself as a clicked event, which the AXON test covers in detail.

What changed in Google's requests after Deny?

Before any click, Store Q's Google requests carried gcs=G111. After Deny, every GA4 and Google Ads request we logged carried gcs=G100. In Consent Mode, the two digits after G1 show ad storage and analytics storage. G111 means both granted, G100 means both denied.

Google tags kept sending after Deny. They sent 11 requests marked as denied, all with npa=1: 6 to GA4, the first 12.2 seconds after Deny, and 5 to Google Ads /ccm/collect on the product page. That fits Consent Mode's advanced setup, where tags still load when consent is denied and send requests without cookies. Whether you want those requests is a setup choice, and our page on cookieless pings shows how to tell them apart from full events. For a migration, write the gcs values down. If your old setup sent G100 after Reject and the new one sends nothing, or sends G111, your Google data will change after the switch.

What did Store Q send before anyone clicked?

On all three passes, Store Q's homepage sent requests to TikTok, Pinterest, Meta, Reddit, X, and AppLovin before any click, with Google requests marked G111. Shopify's consent API returned no on all four values at that point. On the Fresh pass, where we never touched the banner, the product page sent requests to the same ad vendors as Accept, in lower numbers for some (TikTok 8 against 13, Pinterest 6 against 10).

US banners are often set up so tags run until the visitor opts out. That may be how this store chose to configure Cookiebot for US visitors, and this capture cannot tell us. Keep it in your record anyway. If your new tool defaults differently for US visitors, the before-click window will change even when Reject behaves the same. Not legal advice.

What did Store Z send around the Deny click?

On the Reject pass, Store Z's homepage sent requests to Meta and Google before any click. Meta's pixel sent a PageView event 6.8 seconds before Deny. When we opened Customize, 2.2 seconds before Deny, it sent a SubscribedButtonClick event with buttonText set to Customize. At the Deny click, 0.0 seconds after Deny, it sent another SubscribedButtonClick, this time with buttonText set to Deny. After that, Meta sent 0 requests on the same page and 0 on the product page. Google sent 6 requests before the click, marked G111, and 0 after Deny.

The Accept pass logged the same kind of event when we clicked Allow all, with buttonText set to Allow all. SubscribedButtonClick is the event name Meta's pixel uses for a button click it records on the page, and buttonText holds the button's label. Our log shows the label and the time it was sent. It does not show what Meta did with the event. Not legal advice.

Two apps kept loading on the product page after Deny: Hotjar sent 2 requests and the SMS sign-up app sent 14. On the Fresh pass, the product page sent no Meta or Google requests. On the Accept pass, it sent 4 to Meta and 13 to Google.

What did Store AA send after Deny?

Store AA puts Deny on the first layer. On the Fresh and Reject passes, it sent 0 requests to Meta and 0 to any Google host: before the click, on the same page after Deny, and on the product page. Google Tag Manager did not load on either pass.

After Allow all, Google Tag Manager loaded 0.6 seconds after the click, Google requests started 0.8 seconds after it, and Meta's pixel sent a PageView 1.4 seconds after it. Every Google request on that pass carried G111. Klaviyo, Gorgias, Riskified, Wisepops, and Elevar loaded on all three passes, Reject included.

Store AA shows that a Cookiebot setup can keep Meta and Google requests at zero on a US visit until the visitor accepts. We did not read the store's Cookiebot settings, so we cannot say which setting does it.

Checklist before you switch

Run this on the live store, in a new browser profile, from the region you care about. Save the results with the date, time, and region.

1. Note where Reject sits. Is it on the first layer, or inside a settings panel? Count the clicks, and note any popup that covers the banner.
2. Run three passes on the same URL: no click, Reject, Accept. Open the same second page on each.
3. For each pass, list hosts in three windows: before the click, after the click on the same page, and on the second page.
4. After Reject, read the consent state your tags see. On Cookiebot that is Cookiebot.declined, Cookiebot.consent.marketing, and Cookiebot.consent.statistics. On Shopify, also read window.Shopify.customerPrivacy.currentVisitorConsent().
5. Write down the gcs value on Google requests before the click and after Reject.
6. List the tags that do not go through the banner, such as Shopify app embeds and web pixels. On Store Q, AXON loaded as an app embed.
7. If you serve California visitors, add one pass with Global Privacy Control turned on and save it with the rest.

Checklist after you switch

1. Repeat the same three passes, same URL, same region, same second page.
2. Confirm the old banner is gone. On all three stores, the product page after Deny still sent 4 or 5 requests to Cookiebot's own hosts. After a switch, a request to consent.cookiebot.com or consentcdn.cookiebot.com means the old script still loads from the theme, a tag manager, or an app.
3. Compare host lists window by window. Flag any host that sent 0 requests after Reject before the switch and sends requests now.
4. Compare the gcs values after Reject with the ones you saved.
5. On Shopify, check that currentVisitorConsent() after Reject matches what it returned before the switch.
6. Check that only one banner shows on a first visit.
7. Re-run the Reject pass after you install or update any app that adds a pixel. How often to re-run a cookie audit covers the timing.

More checklists for cookies, CMPs, and GPC are on our website compliance checklists page.

Limits of this test

This is three stores, tested from one US connection, with one pass per state on each capture date. We captured Store Q on October 26, 2026, three days before Cookiebot announced the price change, and again on November 2, 2026. We captured Stores Z and AA only on November 2. On Store Z, an overlay from another app covered the banner, so we clicked Cookiebot's buttons with a DOM click() instead of a mouse click. A visitor would close the overlay first, which could change what loads. We did not run an EU visit or a GPC pass, log in, add to cart, or check out. The counts are requests the browser sent. We cannot see what any server did with them, or what a server sent on its own. Another Cookiebot setup, region, or banner type can give different results. These numbers do not rank consent tools, and they do not say any store did anything wrong. We also logged browser storage on these passes and will cover it in a separate article. For how other stores handled GPC timing, see our four-store GPC test. Not legal advice.

FAQ