Embedding Google Maps under the GDPR: four options compared

The map on the contact page is one of the most harmless ideas there is. People should be able to see where you are. Technically it is anything but harmless: a normally embedded Google Maps frame connects to Google before the visitor clicks anything. With their IP address, browser data, the specific page they are on, and identifiers from cookies. To the US.

The annoying part is that four workable solutions exist, and most websites use none of them. They use the snippet from Google's help pages.

What actually happens on load

As soon as the browser sees the <iframe> with a Maps URL, it opens the connection. Before the map is in view, before anyone scrolls. Google receives the IP address, the date and time, the referrer URL (meaning the specific subpage), details about browser, operating system, language and screen resolution, plus identifiers from cookies and local storage. For Maps that usually means NID, AEC, SOCS and __Secure-ENID. If the visitor happens to be signed in to their Google account, all of it can be tied to that account.

The referrer URL is the part people overlook. For a medical practice, a law firm or a counselling service, the sensitive bit is not the IP address but the path. /services/hiv-test/ says more about a visitor than any IP ever will.

Why this is three requirements, not one

Most guides treat it as a single question. It is three, and they stack.

Access to the terminal equipment falls under Art. 5(3) of the ePrivacy Directive, transposed nationally: § 25(1) TDDDG in Germany, § 165(3) TKG 2021 in Austria, art. 82 of the Loi Informatique et Libertés in France. The rule is technology-neutral. It says "information", not "cookies".

The processing itself needs a legal basis under Art. 6 GDPR. More on that below, because this is where most privacy policies get it wrong.

The transfer to Google LLC in the US needs its own transfer tool under Chapter V.

Consent is the only thing that covers all three at once. That is the entire reason the two-click pattern exists.

Legitimate interest does not work here

Plenty of generated privacy policies cite Art. 6(1)(f) for Google Maps, a legitimate interest in showing your location conveniently. It sounds reasonable and it does not hold.

If the national ePrivacy rule requires consent for the access to the device, you cannot base the processing that flows directly from that access on a different ground. The consent requirement would be worthless, because you could route around it by swapping the legal basis. The EDPB said as much in Opinion 5/2019 on the interplay between ePrivacy and the GDPR.

Then there is the necessity test, which is short: an interactive map is not necessary to run a contact page. The postal address as text achieves the same purpose with no transfer at all.

Four ways to solve it

Option 1: address as text plus a link

No map. The address sits on the page as text with an "Open in Google Maps" link underneath. A link transmits nothing until someone clicks it. No consent, no banner entry, no privacy policy section, no third-country question.

The downside is obvious: it looks like nothing. For a restaurant down a side street that is not enough. For a tradesperson who drives to the customer it is plenty.

Option 2: a static map image

The map is rendered once when the site is built and then served like any other image. The visitor sees a map with a marker, taps it, and lands in Google Maps or their own maps app. At runtime nothing is requested from a third party, because the image comes from your own server.

For the by far most common case, "show where we are", this is the best answer. It is legally unremarkable, it loads fast, and it still works for someone blocking every cookie. What you lose is panning and zooming inside the page. Anyone who wants a route taps the link anyway and switches to an app that can actually navigate.

You need a tile provider whose licence permits it. MapTiler, Mapbox and Geoapify all offer static map APIs where the call happens once at build time rather than in the visitor's browser.

Option 3: an interactive map from the EU

If panning and zooming genuinely matter, the tiles come from a European provider instead of Google. In practice that means Leaflet or MapLibre plus tiles from MapTiler, Stadia Maps, or your own tile server running OpenStreetMap data.

The third-country problem disappears, and depending on the provider and configuration so does the consent requirement, as long as nothing is stored on or read from the device. This is the option with the most implementation work, and the only one that gives you full interactivity with no consent banner.

One warning, because this trips people up: the OpenStreetMap Foundation's public tile servers are not meant for commercial embedding. Their usage policy is explicit about it. Use a commercial provider or host your own.

Option 4: Google Maps behind consent

The classic two-click pattern. Nothing is requested from Google on page load, a local placeholder sits where the map goes and explains what data goes where, and the real map loads only after an affirmative action.

This is what most people pick, because Google Maps is familiar and its routing is better than the alternatives. It is also the option with the most ways to get it subtly wrong, which is why it gets its own section.

The usual objection is "then my visitors have to click on every single page". They do not. A consent manager stores the decision, and on the next page the map reads that stored state and loads on its own. One click, not one click per page.

The direction matters though. The map asks the consent manager, not the other way around. It starts blocked and loads only once a stored consent has been confirmed. Built the other way round, loading first and switching off when no consent turns up, is exactly the mistake this whole article is about.

There is a small price. Because the stored consent cannot be read until the consent script has loaded, even a returning visitor sees the placeholder for a moment. That is the deliberate trade. An implementation that avoids the flicker by shipping the map with its address already in the HTML and removing it later has, by then, already sent the data.

Side by side

	Consent required	US transfer	Interactive	Effort
Address plus link	no	no	no	minimal
Static map image	no	no	no	low
EU map (Leaflet/MapLibre)	usually no	no	yes	medium to high
Google behind consent	yes	yes	yes	medium

My honest read: option 2 solves the problem completely for most websites and nobody misses anything. Option 4 is still the most common, because Google Maps is Google Maps. That is a legitimate call. It should just be a call, rather than the result of copying the default snippet.

If it has to be Google, the details decide

The principle is easy to state. No request on page load, a local placeholder with a notice, loading only after an affirmative action, refusing as easy as accepting. Implementations still go wrong, and usually in the same places.

An empty src is not a missing src.

<!-- Wrong: depending on the browser this requests the current page -->
<iframe src=""></iframe>

<!-- Right -->
<iframe></iframe>

On withdrawal, an overlay or display: none also does not cut it. Google's document keeps running, with timers, further requests and postMessage. The frame has to be navigated to about:blank. In a screenshot the two look identical. In the network tab they do not.

Then there is the referrer. Left alone, the browser sends the full URL of the embedding page, and for the usual keyless embed it is not needed at all.

<iframe referrerpolicy="no-referrer" ...></iframe>

A preconnect undoes everything. This is the quietest mistake of the lot. One line in the <head>, often added by a performance plugin, and the connection is open before anything else happens:

<link rel="preconnect" href="https://maps.googleapis.com">

The same goes for dns-prefetch, preload and prefetch. If you have built the two-click pattern and still see Google in the network tab, look here first.

You should not lean on the consent tool by itself either. These tools usually block iframes with a MutationObserver. That works reliably for elements inserted later, but an iframe already present in the HTML at parse time is not always caught, particularly when the consent script loads after the page has rendered. The only thing you can rely on is what ships in the HTML.

One more that gets forgotten: if an ad blocker eats the consent script, or the provider has a bad five minutes, clicking "Load map" does nothing at all. The visitor can neither see the map nor consent to it. A dead button is worse than no button, so that case needs a plain link to Google Maps as a fallback.

The address as text belongs there regardless

Whichever option you take, the full address should be on the page as text. Three independent reasons.

Data minimisation under Art. 5(1)(c): the purpose is achievable with no transfer whatsoever. If the only route to the address runs through consenting to a US transfer, the "freely given" part of that consent starts to wobble.

Accessibility: a slippy map is close to unusable with a screen reader. The text address is the meaningful alternative. alt="Map" is not.

And you need it anyway, because the address belongs in your legal notice.

What belongs in the privacy policy

A clean technical gate does not help much if the privacy policy is silent or claims something else. Name both Google entities: Google Ireland Limited in Dublin, and Google LLC in the US as the recipient of the transfer. Naming only the Irish company while admitting a US transfer does not add up.

The legal basis is Art. 6(1)(a) together with the national ePrivacy provision, with no second mention of (f). Describe what data is processed, and state concretely what the third-country transfer relies on. "Adequacy decision or standard contractual clauses" is not a statement, it is a menu. Art. 13(1)(f) wants the instrument that actually applies, and for Google Maps that is the European Commission's adequacy decision of 10 July 2023 for the EU-U.S. Data Privacy Framework. For withdrawal, give the actual route: the cookie settings link in the footer.

That is exactly why consent is load-bearing here rather than a second layer of comfort. If the adequacy decision falls, there is no fallback. Not a theoretical worry either: the Latombe challenge was dismissed by the General Court on 3 September 2025, and the appeal is now before the Court of Justice (C-703/25 P). The same court struck down Safe Harbor and Privacy Shield.

How big is the risk, really

A lot gets muddled here, so in order.

The Regional Court of Munich I ruled on 20 January 2022 (case 3 O 17493/20) that embedding Google Fonts dynamically without consent was unlawful, and awarded 100 euros in damages. Then came the warning-letter wave: tens of thousands of automated letters, typically demanding a 170 euro settlement, deliberately priced below the cost of getting legal advice.

And then the wave collapsed. The Regional Court of Baden-Baden enjoined the senders. The Local Court of Ludwigsburg dismissed the claim as an abuse of rights on 28 February 2023 (case 8 C 1361/22). In December 2022 the Berlin public prosecutor searched premises and seized roughly 346,000 euros in collected settlements, investigating attempted cease-and-desist fraud.

Here is the part that almost always gets left out. The Ludwigsburg court expressly endorsed the substantive law. The claim failed on the claimant's conduct, not on the merits. No court said the embed was lawful. They said this claimant could not turn it into a business. Anyone concluding the topic is settled is relying on the next claimant also acting in bad faith.

So where does the risk actually sit? Fines are less likely than people assume. In the coordinated Google Analytics decisions of 2022, the closest comparable, authorities issued orders with deadlines but no fines against site operators. Damages run in the tens to low hundreds of euros, and the CJEU requires proof of actual non-material harm.

The realistic path in Germany is a different one. Since the CJEU's Lindenapotheke ruling (C-21/23, October 2024), breaches of the Art. 12 and 13 information duties can be pursued by competitors and consumer associations as unfair competition. No data subject, no proven damage. That is precisely the shape of a missing or wrong privacy policy, and for clubs and small businesses it is far closer than a fine.

The short checklist

• No request to any Google host on page load, verified in the network tab rather than assumed
• The iframe has no src attribute, not merely an empty one
• No preconnect, dns-prefetch, preload or prefetch pointing at a Google host
• referrerpolicy="no-referrer" set
• On withdrawal the frame is navigated to about:blank, not hidden
• A fallback for when the consent tool fails to load
• Consent carries across pages: the map loads by itself on the next page, with no second click
• Full postal address as text, independent of the map
• Consent dialog operable by keyboard, "Reject" as visible as "Accept"
• Privacy policy: (a) rather than (f), both Google entities, the actual transfer instrument
• No claim about standard contractual clauses that do not exist

How BlenSite handles it

On sites built with BlenSite the map is consent-gated out of the box. The <iframe> ships with no src attribute, so the guarantee sits in the HTML rather than in the timing of a script. The address is set only after consent, and on withdrawal the frame is actively navigated to about:blank. Anyone who has consented once gets the map automatically on the next page, with no second click. The referrer is suppressed, the frame runs sandboxed, and the full postal address sits next to it as text for everyone who never loads the map. If the consent tool fails, the page swaps the button for a plain link so nobody is left pressing something dead.

Fonts are self-hosted anyway, which leaves Google Maps as the only possible point of contact with Google on a generated site. The matching privacy policy section is generated along with it, with the right legal basis, both Google entities and the transfer instrument that actually applies. In every supported language, each citing the destination country's own national provision instead of pointing at the German rule.

For the wider picture, the GDPR checklist for 2026 works through every mandatory item on a website. Examples by sector are under Industries. Your first website is free.