Pre-consent cookies: what the server sets before any click

The check reads the Set-Cookie header of the first response, before any script runs and before anyone clicks. Every cookie in it is "to review", not automatically a violation.

What we check

Over HTTP: the scan requests the page once, without a browser and without a click, and reads the Set-Cookie headers of the response after the last redirect. No cookie means "ok". Any cookie means "to review", with the first three names in the line. The scan does not rate the names, it does not know their purpose. Starting the scan as "cookieless" turns the "to review" into a note.

What the scan cannot see here: cookies set by JavaScript. _ga, _fbp, _gcl_au and relatives appear in the browser, and the deep scan checks those in the reject respected finding, separately for the accept and reject state. Cookies from foreign domains are covered by the third-party cookies finding.

Why it matters

The server sets cookies before any banner appears. That is fine for session, cart and load balancer, and not fine for anything else. The problem is rarely the violation, it is the gap in the documentation: the privacy policy lists the analytics tool's cookies, but not the variant cookie of the server-side A/B test, not the affiliate cookie from the backend, not the bot protection's cookie. Exactly those names are what the scan delivers. Match them against the policy once and you have done the part of the audit that reviewers open first.

Common causes

Server-side session or load-balancer cookies (PHPSESSID, AWSALB) are harmless but belong in the documentation as essential.
A CDN or bot protection sets its own cookies, which are simply missing from the cookie documentation.
The backend writes affiliate or attribution cookies with the very first response, before any consent.
Server-side A/B testing assigns variant cookies before the consent decision.

The fix

Match the named cookies against the cookie documentation and the privacy policy. Keep session, cart, load balancer, CSRF protection and the consent cookie itself listed as technically necessary. Move everything that stores attribution, personalisation or test variants behind consent; on the server that means setting the cookie only once the consent state allows it. Then read the deep scan, because the cookies that really count come from the browser.

Matching template

CMP and GTM Consent QA Template

The repeatable test plan for default-denied, consent update and reject, across all four signals.

Get the QA template →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

The scan names PHPSESSID and AWSALB. Is that a problem?

No. Session and load-balancer cookies are technically necessary and need no consent. The line still reads "to review", because the scan cannot know what each cookie is for; it names what gets set, and you match that against your cookie documentation. A cookie that is not in there is the real finding.

Why does this check see no _ga or _fbp cookies?

Because it only reads the server's HTTP response, before any script runs. Tracking cookies are almost always set by JavaScript in the browser, and only the deep scan sees those: the reject respected finding lists the non-essential cookies that appear after "reject", with names such as _ga, _gcl_au or _fbp.

Our setup is cookieless. Why does the scan still report cookies?

Cookieless describes the analytics tool, not the server. A CDN, a bot protection or the shop software set their own cookies regardless. In the "cookieless" context the scan downgrades the line to a note; the names stay visible so the documentation stays correct.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint