Home / Blog / Server Side Tagging and Consent: Keeping the Signal Intact

Consent Cookie Lifetimes: Auditing Expiry Dates Nobody Set on Purpose

Published 2026-10-31

Ask a room of site owners how long their consent cookie lasts and you will get shrugs, then a look up, then a number nobody remembers choosing. Thirteen months. Twenty four. In one memorable category, a decade, set by a default in a plugin update and never read again.

Expiry is not housekeeping. In European guidance the consent storage period is part of the consent's validity, and a notice that promises one period while the cookie enforces another is a false statement in production. The audit is short. The embarrassment is in how rarely it has been run.

Build the real inventory

Start from the browser, not the policy page. In a clean profile, load the site, accept everything, and export every cookie with its domain, path, and expiry. Then refuse everything in a second profile and export again. The difference between the two lists is your actual consent behaviour, and it regularly contains cookies the notice never mentions, set by embeds and tag manager containers added since the notice was written.

Sort by lifetime and read from the top. Multi year expiries on identifiers are the finding that matters: advertising and analytics cookies set for 13, 24, or 36 months by vendor default, silently extending recognition far past any period a user would infer from the word session or from a notice that mentions none of it. Session cookies that persist because they were set with a rolling renewal deserve the same look.

Consent's own clock

The consent cookie or local storage entry has its own lifetime, and it defines when a returning visitor gets asked again. Set it deliberately. Too long, and consent goes stale across changes in purposes, vendors, and the law itself: several European regulators treat consent older than roughly six to twelve months as due for renewal, and guidance varies by country. Too short, and you train regular visitors to click accept reflexively to end the interruption, which degrades the quality of every consent you collect.

Whatever period you choose, the notice, the banner settings, and the stored value have to agree, and a material change to purposes should force a re ask regardless of the clock. A new advertising partner should not inherit a two year old yes given to a different list.

Fix defaults at the source

Most lifetime problems are configuration, not code. Consent platforms expose the consent duration. Tag managers and analytics tools expose identifier expiry, and privacy forward analytics configuration often means shortening it on purpose. Advertising pixels are the stubborn ones: where a vendor will not shorten an expiry, that fact belongs in the vendor assessment, because you are publishing their clock under your notice.

Re run the export after every fix and file it dated. The inventory decays the moment a new embed ships, so the audit is a habit, quarterly or at every major release, not a project with an end date.

Related reading

These earlier guides cover connected questions in more depth: Auditing Tag Manager Consent Defaults: Where the Leaks Actually Are, Consent State Across Subdomains: Why Your Banner Keeps Coming Back, and Consent Logs in a Data Breach: What Your Banner Records Expose.

Frequently asked questions

How long should a consent cookie last?

There is no single mandated period, but European regulators commonly expect renewal within about six to twelve months, and the stated period must match the configured one. Choose a period you can defend, state it, and force a fresh ask when purposes change materially.

Why do some cookies last for years?

Vendor defaults. Analytics, advertising, and embed tools often set identifier expiries of one to three years or more unless the site configures otherwise. The site remains responsible for what loads under its notice, default or not.

Does deleting cookies reset consent?

Yes for that browser and device, because the consent record usually lives in a cookie or local storage. The user will be asked again on the next visit, which is correct behaviour, though services with accounts can also store consent server side tied to the login.

Should session cookies appear in the cookie notice?

Strictly necessary session cookies are commonly exempt from consent but should still be listed for transparency, with their purpose. The audit finding to worry about is a cookie labelled session that in practice persists or is renewed across visits.