The "find us here" map is a data transfer
A contact page with a Google Map feels harmless. It is one of the most common consent leaks there is. The standard Maps embed, the <iframe src="https://www.google.com/maps/embed?..."> you copy from the Share dialog, connects to Google's servers on load, sets cookies including the NID advertising cookie, and hands Google the visitor's IP and referrer before anyone scrolls to it. None of that is necessary to show a page. Under ePrivacy rules, non-essential storage like that needs consent first.
Data protection guidance across the EU treats an embedded Google Map as a third-party integration that may only load after the visitor's informed, active agreement. The map is useful, so the goal is to keep it while stopping it from loading uninvited.
Why the map counts as non-essential
The test is not whether a map is nice to have. It is whether loading Google's map is strictly necessary to deliver something the visitor explicitly requested. On a contact or store-locator page, it is not: you can show the address as text, and the interactive map is an enhancement. Because the embed also passes data to a third party (Google) and sets an advertising-associated cookie, it sits firmly in the consent-required bucket alongside the other trackers described in our guide to cookie categories.
There is a transfer angle too. Google receives the request in a context governed by US law, so the same cross-border considerations that apply to other Google services apply here. Getting consent before the map loads is the clean way to cover both the storage and the transfer.
Option one: click-to-load facade
Keep Google Maps, but do not let it load until the visitor asks. Show a static preview (a screenshot, a styled placeholder, or a static map image) with a clear button. On click, inject the real iframe:
<div class="map-facade">
<img src="/img/office-map-preview.png"
alt="Map showing our office on Example Street">
<button type="button" class="map-facade__load">
Show interactive map (loads Google Maps, sets cookies)
</button>
</div>
document.querySelector('.map-facade__load')
.addEventListener('click', (e) => {
const wrap = e.target.closest('.map-facade');
const iframe = document.createElement('iframe');
iframe.src = 'https://www.google.com/maps/embed?pb=YOUR_EMBED_CODE';
iframe.title = 'Google Map of our office';
iframe.loading = 'lazy';
iframe.style.border = '0';
iframe.setAttribute('allowfullscreen', '');
wrap.replaceChildren(iframe);
});
The button text does the informing, and the click does the consenting. If you prefer to drive it from your consent categories instead of a per-map click, mark the iframe with a harmless src="about:blank" and a data-src, and let your consent platform swap it in when the relevant category is granted. That is the same iframe-gating technique covered for video embeds.
Option two: drop Google for a cookieless map
If the map is decorative or you just need to show a pin, you do not need Google at all. A map built with the open-source Leaflet library and OpenStreetMap tiles can render without setting any tracking cookies, which sidesteps the consent problem entirely:
<div id="map" style="height: 400px"></div>
<script>
const map = L.map('map').setView([48.137, 11.575], 14);
L.tileLayer('https://tiles.example.com/{z}/{x}/{y}.png', {
attribution: '© OpenStreetMap contributors'
}).addTo(map);
L.marker([48.137, 11.575]).addTo(map);
</script>
One honest caveat: the public OpenStreetMap tile servers have a usage policy that forbids heavy production traffic, and any tile host still sees visitor IPs. For a real site, self-host tiles or use a privacy-respecting tile provider, and point the tileLayer URL there. Static map images are another cookieless route: render a flat picture of the location and link out to full Google or Apple Maps for directions. No embed, no cookies, no gate.
A note on the Maps JavaScript API
The embed iframe is the simple case. If your site uses the Maps JavaScript API (the programmatic google.maps.Map you configure in code, used for store locators, custom markers, and interactive features), the consent picture is the same and often heavier: loading maps.googleapis.com/maps/api/js pulls in Google's script, sets cookies, and bills against your API key on every page view. Gate the API loader exactly like any other marketing script. Do not inject the <script src="...maps/api/js..."> tag until consent, then initialize the map inside its callback.
One misconception worth clearing up: Google's Consent Mode governs Google's own measurement tags like Analytics and Ads. It does not exempt a Maps embed or the Maps JavaScript API from ePrivacy consent. Having Consent Mode configured does nothing for the map, so do not assume it is covered.
Confirming the fix
After you change the map, verify it rather than assuming. Load the page with a fresh browser profile, reject or ignore consent, and watch the network panel. You should see no request to maps.google.com or maps.googleapis.com and no NID cookie until you actively load the map. A consent platform like CookieBeam helps two ways here: it holds the Maps iframe until the matching category is granted, and its scanner flags the outbound connection to Google's map domains so a stray embed on some deep page does not slip through unnoticed.
Maps, video, fonts, and social posts are the four embeds that most often leak data before consent on otherwise-compliant sites. Handle them the same way: nothing third-party loads until the visitor has genuinely agreed, or swap in something that sets no cookies at all. For the font version of this exact problem, which produced a real court award in Germany, see our guide on Google Fonts and the GDPR.
Quick checklist
- No request to
maps.google.com,maps.googleapis.com, ormaps.gstatic.comfires before consent. - A facade or static preview stands in until the visitor loads the map, and its button text tells them the map connects to Google.
- The Maps JavaScript API loader is gated like any marketing script, not assumed to be covered by Consent Mode.
- Where a live Google map is not essential, a cookieless Leaflet map or a static image replaces it outright.
- You verified the deep pages too, since store locators and footers often carry a second map beyond the main contact page.