Consent Banner Audits for Redesigns: What Breaks When a Site Relaunches
A redesign changes templates, scripts, and load order all at once, which is exactly the combination that breaks consent tooling. The banner that worked for two years can vanish because a new theme loads the tag manager earlier, a consent script gets dropped from the build, or a fresh cookie name appears that nobody categorized. None of this shows up in a visual review, so the site launches looking perfect while collecting data it has no permission to collect.
The fix is to treat consent as a launch dependency with its own audit track. The teams that relaunch cleanly do three things: they document the old setup before anyone touches it, they test the new build in staging with real blocking checks, and they re-scan the live site in the first week, when leftover issues are still cheap to fix.
Inventory the old site before it disappears
Screenshot and export everything: banner configuration, category assignments, the full cookie list from a scan, and a sample of consent records. Once the old site is gone, questions like which cookies were declared or how long records were kept become archaeology. Run a crawl based scan on the old site and save it as the baseline. Every cookie on the new site will be compared against that baseline, and any newcomer needs a category, a description, and a blocking decision before launch, not after a visitor complains.
Rebuild blocking on the new stack, do not copy settings blindly
Consent platforms store configuration against script patterns and page structures that a redesign changes. A tag that was blocked by a wrapper on the old theme may fire freely through a new tag manager container. Rebuild the blocking rules against the new stack and test each category by declining it in a clean browser profile, then watching the network requests. If an analytics or advertising request fires before a choice, the banner is decoration, whatever the settings screen claims.
Test the records, not just the banner
A banner can look right while its records silently fail: a changed consent mode integration, a new storage key, or a consent string that no longer reaches downstream tools. During staging, make choices in each combination, then pull the records the way an auditor would and confirm the timestamp, the categories, and the banner version are stored and retrievable. Also confirm returning visitors are handled sensibly. A redesign that wipes stored choices and re-asks everyone is annoying; one that invents choices nobody made is a compliance problem.
Re-scan in the first week after launch
Staging is never identical to production. Caching layers, regional variants, and last minute marketing tags all appear at launch. Schedule a live scan and a manual decline test within days, compare against the baseline inventory, and log anything new that slipped in through a launch week tag request. Most redesign consent failures are found by whoever looks first. The goal is for that to be your team, working from a checklist, rather than a regulator or a customer working from a complaint.
Related reading
These earlier guides cover connected questions in more depth: Consent Mode Signals When a Visitor Declines: What Your Tags Should Actually Do, Reading your consent string: how to confirm vendors honor what the banner recorded, and Consent record retention: how long to keep proof of consent, and how to honor deletion requests.
Frequently asked questions
When should a consent audit happen during a redesign?
Twice: a baseline audit of the old site before design work starts, and a verification audit on staging plus the live site at launch. The baseline tells you what to rebuild, and the launch checks prove the rebuild actually blocks and records correctly.
What breaks most often in a relaunch?
Tag load order and dropped scripts. A new theme or tag manager setup lets marketing tags fire before the consent tool initializes, or the consent script itself never makes it into the new build. Both are invisible in visual testing, which is why network level checks matter.
Should returning visitors be asked for consent again after a redesign?
Only if the purposes or vendors materially changed, or stored choices were genuinely lost in the migration. Re-asking everyone by default trains visitors to click accept without reading. If you must re-ask, say plainly that the site changed and choices need confirming.
How long should we keep the old consent records?
At least as long as your retention policy states, and they must stay retrievable after the migration. Consent given on the old site is still the legal basis for data collected then, so records should be exported and archived before the old platform is switched off.