WordPress and Next.js Cookie Consent: A Developer Test Guide

WordPress and Next.js can show the same banner while introducing tracking through different paths. WordPress often has several plugins inserting scripts. Next.js can initialize a tracker during hydration or client-side navigation. Audit the code that launches the service as well as the banner that records its consent.

Define what each consent state should do

Write these expectations for your actual tracking configuration. Google’s basic and advanced Consent Mode behave differently before consent. Define which one you intend to use so an expected cookieless ping is not reported as a cookie-blocking bug.

WordPress: identify every script owner

1. List the CMP plugin, analytics plugins, header/footer snippet plugins, theme integrations and GTM containers. Search for duplicate measurement IDs.
2. In a logged-out session, inspect the request initiator for each unexpected tracker. Match it to the plugin, theme or tag-manager configuration.
3. Review the CMP service mapping. For Complianz, check the enabled integration and custom Script Center entry; for Cookiebot, verify the loader and blocking mode.
4. Reproduce on staging with the relevant cache or optimization setting changed individually. Minification and script delay can alter execution order.
5. Publish the change, clear the relevant page/CDN caches and repeat on the live page. An administrator’s uncached view is not a sufficient test.

Use the Complianz configuration audit or Cookiebot blocking checklist for vendor-specific steps. Complianz documents how to locate a script that sets cookies when an integration does not behave as expected.

Next.js: timing is not a consent gate

The Next.js Script component controls when scripts load. In particular, afterInteractive describes application timing, not permission from the visitor. A tracker still needs a condition based on the relevant CMP choice.

1. Find every script or SDK initialization in layouts, providers and client components. Include analytics added through packages or tag managers.
2. Keep an explicit unresolved consent state while reading the CMP. Do not initialize an optional SDK merely because hydration completed.
3. Subscribe to the CMP’s ready and consent-change mechanisms. Use its documented category or vendor mapping and avoid assuming all purposes share one Boolean.
4. Test direct loads and client-side route transitions. A route-change pageview handler must use the current choice, including after withdrawal.
5. Review what unmounting does: removing a script element does not undo an already initialized SDK. Follow the vendor’s documented disable or update behavior and inspect subsequent network traffic.

Reproduce the bug before changing code

Use two tabs or sessions for two distinct cases: a direct visit to a product page and navigation to the same page from the homepage. Record whether the SDK initializes once, twice, or only after a route change. Repeat with no choice, rejection and partial acceptance. A successful homepage test can miss a tracker introduced by a later component.

Verify the result and hand it off

Record the URL, build or deployment identifier, browser, consent steps, request initiator and expected behavior. Use ConsentScope DevTools and Initiator Trace to investigate browser evidence. A debug snapshot helps preserve the conditions; review its contents before sharing.

For Google tags, compare defaults and updates with the Consent Mode checker and Google’s implementation instructions. For a portfolio of client pages, the bulk scanner supplies passive baselines; interactive acceptance and withdrawal still require separate tests.