Tracking cookie is set before the consent banner can be answered

Why it matters

This page shows a consent mechanism, and an analytics or advertising tracking cookie was already set by the very first response — before the banner was displayed, and before the visitor could accept or reject anything. Consent that is asked for after the cookie is set cannot be prior consent, which is what the EU/EEA and UK rules on storing identifiers actually require. Usually this means the tracking script (or a server-side session) runs ahead of the consent tool rather than being gated behind it: load the tag only after a positive choice, or use your consent platform's blocking mode / Google Consent Mode so tags are held until then. This finding is about ORDER only — what a single page load can show. It says nothing about what your banner does when a visitor clicks reject, which this scan does not test. (The specific cookie and vendor are named in this finding's evidence.)

How ShipReady detects it

Per-page privacy signals read straight from the fetched HTML and response headers — no extra requests. Page-scoped because trackers, cookies and forms genuinely differ between routes (a marketing homepage vs a bare /login), and the route that carries the signup form is exactly the one worth seeing.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.0.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

Your site shows a consent banner, but the tracking cookie affected is already set in the very first response — before the banner is displayed and before anyone can answer it. Consent asked for after the cookie is set is not prior consent. Find what sets it: if it is a tag loaded in your HTML, move it behind your consent tool's blocking mechanism (Cookiebot, OneTrust, CookieYes, Osano and Termly all support blocking scripts until a category is accepted — usually by changing the script's type attribute or wrapping it in their API), or use Google Consent Mode so Google tags start in a denied state and only store identifiers after a positive choice. If it is set by your own server, gate it on the consent cookie instead of setting it unconditionally. Verify by opening your site in a fresh private window with devtools on the Application/Storage tab: before you touch the banner, the only cookies present should be strictly necessary ones (session, CSRF, load balancing). Note that this finding is about ordering only — it does not test what happens when a visitor clicks reject, which is worth checking yourself in the same way.

Frequently asked questions

What does "Tracking cookie is set before the consent banner can be answered" mean?

This page shows a consent mechanism, and an analytics or advertising tracking cookie was already set by the very first response — before the banner was displayed, and before the visitor could accept or reject anything.

How serious is it?

ShipReady rates this medium. Fix soon. Meaningfully weakens a defence or degrades how the site works.

How do I fix it?

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• A device-fingerprinting script is presentmedium
• A form collecting personal data submits via GETmedium
• Session-replay or behaviour-recording script is presentmedium
• Tracking cookie is set on the first responsemedium
• Analytics or advertising tracker loads without a detected consent steplow
• Fonts are loaded from Google's serverslow