Cookies still set after "Reject all"? How to find the cause

Start with one question: did the cookie already exist, or did the site write it after you rejected? The Application panel can show a cookie left over from an earlier visit. That alone does not tell you when it was created, whether its value changed, or whether a request sent it back to a server. Record a clean visit before changing your CMP settings.

This guide is for the awkward case where the banner closes as expected but the browser still shows analytics or advertising cookies. You will separate stored data from new activity, identify the component responsible, and write a retest that another developer can repeat. A cookie name is a clue, not enough evidence for a legal conclusion.

Capture a clean rejection without losing the evidence

1. Use a dedicated test profile without unrelated extensions. If you use incognito, check that your auditing extension is enabled there. Record browser version and third-party cookie settings.
2. Before opening the target, clear its test data or start a fresh session. Do not clear data from an account you need to keep signed in. Open DevTools and start recording Network activity before navigation.
3. Load the exact page under test. Do not choose anything yet. Note the time, visible banner, existing cookies and storage keys.
4. Click Reject all once and note the time. Keep the network log. Inspect the same cookie names and any new responses that attempt to set them.
5. Reload without clearing the saved refusal. Then follow an internal link. Rejection should be tested on the next page as well as the first one.
6. Save the evidence before resetting the session. Run acceptance followed by withdrawal as a separate test; do not mix it into the clean rejection capture.

Disable ConsentScope Auto-Reject while testing manually so that your recorded click is the only banner action. If a site offers subscription choices instead of an ordinary rejection button, document that interface. Do not describe a paid subscription action as a completed rejection test unless you actually completed that flow.

Work out which of these cases you have

A useful bug report says "the response attempted to set this cookie after the recorded refusal; Chrome accepted it." A weaker report says "I saw this name in a list." Those statements lead to different fixes. Keep the domain and path with the name because two cookies can share a name and still be separate entries.

Trace the write to a tag, plugin or server response

For an HTTP cookie, inspect the response headers of the request that sets it. For a JavaScript write, start with the script or request evidence captured around the event. Follow the cookie source investigation rather than assuming the banner vendor owns every cookie on the page.

• Check for two installations of the same analytics service: a tag-manager tag plus a theme snippet or plugin.
• Review custom HTML tags separately. A CMP integration does not automatically make every piece of arbitrary code consent-aware.
• Check category mappings. A service can be technically wired to the CMP but assigned to the wrong category.
• Look at redirects and document responses. A server-set cookie will not be fixed by removing only a client-side script.
• Compare the deployed container and CMP configuration with the versions you edited. A saved draft is not proof that production changed.

A request after refusal is not automatically a cookie write

Google distinguishes basic and advanced Consent Mode. In advanced mode, Google tags can send cookieless measurements while consent is denied; basic mode blocks the tags when consent is not granted. Check the intended implementation before treating every Google request as the same failure. See Google's Consent Mode documentation.

That distinction does not approve the implementation or its payload. It tells you what to inspect. Record consent state, cookie behavior and outgoing data separately, and have the responsible privacy reviewer assess the policy. A green consent-state indicator is not a substitute for those observations.

Prove the fix survives another visit

Repeat the clean rejection on the same URL after deployment. Then reload with the saved refusal, navigate to a page containing an embed, and return using the back button. Finally, test acceptance followed by withdrawal in a separate session. A fix that only works immediately after a full refresh is incomplete for an application that uses client-side navigation.

Record an explicit result for each case: expected behavior observed, unexpected behavior observed, or inconclusive. An unavailable CMP, blocked test request or timed-out page is inconclusive, not a pass. Use the regression checklist to keep those cases consistent across releases.

Questions that come up during rejection tests

Should I delete every cookie after clicking Reject all?

Not during the observation window. Manual deletion destroys the evidence of what the site did. Capture the state first, then reset for a new scenario. A preference cookie can be part of remembering a refusal, so do not classify everything left in storage as a tracking failure.

Does an old analytics cookie prove tracking continued?

No. Check whether it was updated, read or sent, and whether the implementation should remove it on withdrawal. Its continued presence and its continued use are different findings. If you cannot establish use, state that limitation rather than filling in the missing evidence.

For CMP-specific configuration steps, continue with the Cookiebot or OneTrust guide. This article covers the browser investigation, not a universal replacement for either vendor's integration instructions.