How to Fix Cookie Consent Issues

A scan tells you what fired before the visitor answered the cookie banner. That is the diagnosis. The How to fix guide is the treatment: a PDF written for that one scan that says where each problem lives and what to change, step by step, in the tools your team already uses.

It is generated for every scan on Pro and Agency plans, usually within a minute of the scan finishing, and it can be requested for any earlier scan of your account. The guide comes as a PDF for people and as Markdown for AI coding agents and tickets.

Most sites with a consent banner and pre-consent tracking load their tags through Google Tag Manager, and a GTM container is public. The guide downloads it, reads every tag, and crosses each host the scan saw before consent with the tag that requested it.

The result is a list of tag ids, not vendor names: tag 141 fires on All Pages with no consent check and reaches connect.facebook.net; tag 152 fires on Initialization and reaches analytics.tiktok.com. For each one the guide names the consent type to require in the tag's Consent Settings (ad_storage for advertising pixels, analytics_storage for analytics and session recording) and, when your container already has a correctly gated tag, points to it as the pattern to copy.

Google's own tags (Google tag, GA4, Google Ads, Floodlight) are governed by Consent Mode rather than by per-tag checks, so the guide reports whether they behaved (the consent state in their first pings) instead of asking you to change them.

Not everything comes from GTM. A chat widget pasted into the theme, a pixel added by a plugin, a script in the page head: these reach the browser before consent and no tag in the container requests them. The guide lists them separately, so you know to look in the page HTML, the theme or a plugin rather than in GTM.

It also covers the banner itself: whether it offers a one-click reject, whether it blocks non-essential scripts until answered, and what to change in your consent platform's console if it does not.

Every guide is also available as Markdown, one click from the report: a brief that starts with instructions for an agent, then the facts (hosts, timings, tag ids), then the fixes as numbered steps with a table of tags and the consent type each needs.

Paste it into Claude Code, Codex, Cursor or any agent that can edit your site's templates, and it has what it needs to gate the hardcoded scripts, document the GTM changes, and prepare the verification checklist. Nothing in the brief is an opinion: every host and tag id was measured on the live site.

For the GTM part itself the change happens in the GTM console, in the tag's Consent Settings. The brief gives the agent, or the person, the exact tag ids and consent types so the console work takes minutes.

Each guide ends with a checklist: open GTM Preview, load the homepage without touching the banner, confirm the Consent tab reads denied and the gated tags sit under Tags Not Fired with reason consent, then accept and watch them fire.

Publish, re-scan, and the next guide reflects the new state. Compliance monitoring on Pro and Agency re-scans on a schedule and emails you if a deploy brings a tag back.

It does not change your site for you, and it is not legal advice. It is a technical observation of what the browser did, with the specific settings that stop it, written so a marketer or a developer can act without a consultant.

If a container is private, server-side or cannot be read, the guide still comes out, with the host-level fixes and without tag ids, and it says so on the first page.