Do embedded maps and store locators need cookie consent?

Published 2026-10-05

Embedded maps are everywhere: contact pages, store locators, delivery coverage checkers, event venues. They feel like page furniture, but each one is a third-party application running inside your page, and it starts working the moment the page loads, not when the visitor touches the map.

The short answer is yes, consent is required in most cases. The longer answer depends on what the map provider loads, which is more than most site owners realize, and on whether the map is decorative or functional. Here is how to think about it.

What an embedded map actually loads

A standard map embed pulls in far more than tiles. The provider's scripts load on page render, set cookies, and collect interaction and device data for the provider's own purposes, which include advertising and product improvement well beyond showing your store location. This happens on load, before any click, pan, or zoom.

The site owner did not choose most of this. The embed is a black box: you get the map, and the provider gets the data collection that comes with it. That asymmetry is exactly why consent applies. The visitor's data is going to a third party for the third party's purposes, which is the textbook case for requiring a choice.

When consent is required and when it might not be

Consent is required when the embed sets non-essential cookies or sends data to the provider for its own purposes, which is the default behavior of the major map providers. The map is not strictly necessary for the page in the legal sense: the page works without it, and the location information can be conveyed as text.

The narrow exception is a genuinely necessary map, and it is narrower than people hope. A delivery checkout where the map is the mechanism for choosing a delivery zone is a stronger case than a contact page decoration. Even then, the necessity argument covers the map function, not the provider's advertising data collection riding along with it. If the embed cannot be configured to disable the extra collection, consent is still the honest answer.

The click-to-load pattern

The standard compliant pattern is click-to-load, also called two-click: show a static placeholder, usually a map image or a styled box with the address, and load the real embed only after the visitor clicks to activate it. The click is the consent moment for the map specifically, and it should be presented as such, not buried.

This pattern has a usability bonus people overlook. Map embeds are heavy, often among the heaviest third parties on a contact page. Deferring them until click improves page load for every visitor, including the ones who never needed the map. It is one of the rare compliance fixes that also makes the site faster. For store locators with search, the same principle applies: the search interface can be first-party, with the map tiles loading only after interaction.

What to check on your own site

Audit where maps appear: contact pages, location pages, footers with mini-maps, store locators, and anywhere a developer dropped an embed years ago and forgot. For each one, check whether it loads on page render or on interaction, what cookies it sets, and whether your consent setup gates it.

Then decide per embed. Decorative maps become click-to-load or get replaced with a static image and a link. Functional locators get the click-to-activate treatment on the map portion. And the address itself should always be present as text, because the visitors who need your location most, including those using screen readers and those on slow connections, should not need a third-party application to find you.

The bottom line

Maps feel like content but behave like tracking. Treat them as third-party applications that need a visitor's go-ahead, use click-to-load to get it, and keep the address as plain text for everyone the map does not serve.

Frequently asked questions

Why do consent rates differ so much between sites?

Mostly audience, device mix, and how much trust the site has built before the banner appears, plus design clarity. Compare your rate against your own history and your sector, not against a headline number from a different kind of site. A sudden change in rate usually signals a site change, not a visitor change.

What should we do when a new tracker appears in a scan?

Treat it as a process question before a settings question: who added it, for what purpose, and why did it bypass the consent gate. Then classify it, disclose it, gate it, and fix the process gap. A tracker that arrived silently once will arrive silently again.

Can a consent banner hurt search rankings?

A banner that blocks content loading, shifts the page layout aggressively, or traps mobile users can hurt the experience signals search engines measure. Keep the banner fast, stable in layout, and dismissible to the preference state. Compliance and performance are compatible; sloppy implementation is what makes them fight.