An iframe from google.com/maps or the Maps JavaScript loads resources from Google (USA) when the page opens and can set identifiers.
When embedding Google Maps there are two technically different routes with the same data protection problem: the simple iframe (google.com/maps/embed) and the Maps JavaScript API with its own API key. Both load resources from Google servers in the USA on page view, transmitting the IP address, and can set identifiers. An interactive map is rarely strictly necessary for the basic function of the page — so § 25 (1) TDDDG applies.
The clean standard solution is the two-click embed: until the click, only a local preview image or a schematic graphic of the address is shown, and only afterwards does the real map load. There are ready-made blocks for WordPress, TYPO3 and the common site builders; it is important that the preview image is local and does not itself call Google's Static Maps API.
Anyone who does not need the interactivity is often better off with an alternative: a simple "Plan route" link (opens Google Maps or Apple Maps in a new tab), a static, self-generated map graphic or an OpenStreetMap embed via a data-minimising provider such as the uMap or MapLibre solution. These variants transmit no data to Google on page view.
The map request is usually not strictly necessary for the basic function of the site, so § 25 (1) TDDDG applies. Without consent or a two-click solution there is no basis; the US transfer must also be justified.
The free scan checks the delivered HTML and shows which services are embedded, whether a cookie banner is detected and whether privacy-policy and legal-notice links are present — with context for each finding. It is not a substitute for legal advice.
This text is general information to the best of our knowledge, not legal advice. For an individual case, consult a law firm specialising in IT law.