Is your Consent Mode v2 actually set up?

It fetches your page HTML and looks for the gtag consent default call, reads the four Consent Mode v2 signals — ad_storage, analytics_storage, ad_user_data and ad_personalization — and checks the ordering: the default must come before your Google tags load, and before any consent update. You get a per-signal verdict, not a vague score.

Probably not. This is a static check of the served HTML — it cannot execute JavaScript. Most CMPs (Cookiebot, OneTrust, CookieYes…) set the consent default at runtime from their SDK, which is invisible to a static fetch. When we recognise a CMP on your page we say "couldn't verify" instead of falsely reporting a missing setup. A real-browser test — Google Tag Assistant or our deep scan — settles it.

For visitors in the European Economic Area, yes: the default must deny storage until the visitor consents, then an update call reflects their choice. A "granted" default before any choice defeats the point of Consent Mode. Region-scoped defaults (deny for the EEA, grant elsewhere) are a valid pattern — the checker flags them so you can verify the region list.

Since March 2024, Google requires the two v2 signals (ad_user_data, ad_personalization) for EEA traffic. Without them, Google Ads remarketing audiences stop filling and conversion measurement degrades — even for visitors who click "Accept". A v1-era setup silently loses you data.

Yes — no signup, no card. It is limited to 5 checks per hour per IP to keep it fair. If you want the runtime truth (which trackers actually fire before consent, in a real browser), that is what the free deep scan and a FewCookies trial add.