Consent Mode governs five Google products. Google says which ones, by name, in its own documentation: the Google tag, Analytics, Ads, Floodlight and Conversion Linker. Fonts, Maps and reCAPTCHA are not on that list and never check your consent state. We built a page with all seven signals set to denied before anything loaded, then added those three services. It made 46 requests to seven Google-owned hosts without a single consent grant. None of them set a cookie, which is exactly why a cookie-based audit reports the page as clean.
There is a belief, common enough that it survives most audits, that implementing Consent Mode makes a site’s relationship with Google conditional on consent. It does not. Consent Mode is a signalling layer for a specific set of tags, and everything else Google ships to your page ignores it completely.
Google names the boundary itself
The Consent Mode overview is unusually direct about scope. Its wording: “Tags and SDKs for the following Google products contain built-in consent checks and adjust their behavior based on consent state”. The list has five entries.
- The Google tag
- Google Analytics, including the Firebase SDK
- Google Ads, including Conversion Tracking and Remarketing
- Floodlight
- Conversion Linker
Fonts, Maps, reCAPTCHA, YouTube and Translate are not there. Nothing in Consent Mode reaches them, and no combination of ad_storage and analytics_storage values changes what they do.
The page does offer a route for the gap — “If you create tags that don’t have built-in consent checks, you can add checks in Tag Manager using configuration in Advanced > Consent Settings” — but read that precisely. It applies to tags fired through Tag Manager. A <link> to fonts.googleapis.com in your page head is not a tag, is not in the container, and is unreachable from those settings.
What a fully denied page still sends
We built a fixture for this: a page whose first script sets all seven consent signals to denied, with wait_for_update: 2000, before any other resource is referenced. Nothing on the page grants consent — there is no banner and no accept button. It then loads a Google Fonts stylesheet, reCAPTCHA v3 using Google’s own published test key, and a keyless Maps embed.
gtag('consent', 'default', {
ad_storage: 'denied', analytics_storage: 'denied',
ad_user_data: 'denied', ad_personalization: 'denied',
functionality_storage: 'denied', personalization_storage: 'denied',
security_storage: 'denied', wait_for_update: 2000
});Loaded in Chromium on 8 September 2026, that page made 46 requests to seven Google-owned hosts:
fonts.googleapis.com stylesheet
fonts.gstatic.com woff2 font files
www.google.com recaptcha/api.js, api2/anchor, api2/bframe,
POST api2/reload, maps/embed, maps/vt tiles
www.gstatic.com recaptcha runtime, styles, logo
maps.google.com the embed URL (301)
maps.googleapis.com maps/api/js and 12 more modules,
POST $rpc/...MapsJsInternalService/GetViewportInfo
maps.gstatic.com init_embed.js, cursor assetsTwo of those are POST requests. The Maps one is an RPC to an internal Maps service; the reCAPTCHA one is its scoring reload call. This is not passive asset loading.
The part that makes it invisible
We checked the response headers on the reCAPTCHA anchor frame and on the Maps embed individually. Neither sets a cookie. That is worth stating plainly rather than skipping, because it is the honest result and it explains why this problem survives audits: a scanner that enumerates cookies finds nothing to report on a page that has just made 46 requests to Google.
Whether that matters legally does not turn on cookies. Article 5(3) of the ePrivacy Directive covers storing information on, or gaining access to information already on, a device — and in the EDPB’s October 2024 guidelines on its technical scope, distributing a resource “does constitute storage, at the very least through the caching mechanism of the client-side software”, explicitly “even if this storage is not permanent”. Those woff2 files are cached. The reCAPTCHA runtime is cached. Separately, every one of those 46 requests carries the visitor’s IP address and a Referer naming the page they are on, to a company whose consent signals you have just set to denied. We went through this reasoning in more detail in what your cookie scanner cannot see.
Fixing each one
Fonts is the easy one. Self-host. Download the woff2 files, serve them from your own domain, declare the @font-face yourself. This removes two hosts and needs no consent logic at all, because there is no third party left. It is also faster, since you drop a DNS lookup and a connection to a second origin.
Maps is the embeds problem. An iframe pointing at Google loads Google. The pattern is a static placeholder — an image of the area, or a plain link — swapped for the real embed on click. That is the same mechanism as video embeds, and the same traps apply, including placeholder thumbnails that quietly fetch from a Google host themselves. We covered the mechanics in blocking third-party embeds until consent.
reCAPTCHA is the genuinely awkward one, because it is usually load-bearing. It has to run before the form is submitted, which is often before any consent decision has been made, and deferring it until consent means an unprotected form for anyone who declines. There is no clean configuration fix. The realistic options are to load it only on the pages that carry a form rather than site-wide, to gate it behind the first interaction with that form, or to move to a self-hosted alternative. Loading it on every page of the site, which is the default in most templates, is the one choice with no argument for it.
How to check your own site
Open a page in a clean profile, do not touch the banner, and filter the network panel for google, gstatic and googleapis. Anything with a status code is a request that already happened. Then check the pages that are not your homepage — fonts tend to be global, but Maps lives on contact pages and reCAPTCHA on anything with a form.
Note that this is a different question from whether your Consent Mode signals are correct, which you read from the gcs and gcd parameters on the outgoing tag requests — covered separately. Both can be true at once: a perfectly configured Consent Mode implementation, sending an accurate denied state, on a page that has already contacted Google seven different ways. And once you find a request you did not expect, tracing it back to the script that caused it is its own exercise.
Consent Mode reports what your tags declared. It says nothing about the other requests your pages make. Scan your site to see every third-party host that loads before consent with CookieInspector.