No Pings Before Permission: Click-to-Load Maps for UK Contact Pages
Photo: Frombowen, CC BY-SA 4.0, via Wikimedia Commons
A contact page is meant to reassure people. Yet the humble map embed is often the first thing on the page to start chatting to a third party, usually before the visitor has clicked anything at all. For UK sites, that is an awkward look: the consent banner is still asking the question while Google has already had a request.
The fix is not to remove the map. It is to make the map wait its turn. This is a build pattern for Elementor Pro contact pages that keeps the useful bits, gives visitors a clear choice, and leaves a sensible fallback for anyone who never taps the button.
The map is a third-party request wearing a friendly hat
An embedded Google Map is an iframe. The moment it renders, the browser is talking to Google. Cookies may be set, the visitor's IP address is shared, and a chunk of JavaScript is pulled in whether or not the visitor wanted an interactive map. Under UK PECR and GDPR expectations, that is not a neutral design choice. The ICO has been consistent on this point: non-essential third-party requests should not run before consent, and a consent banner does not magically undo requests that already happened.
There is a performance angle too. On a mobile connection in a train station or a rural high street, an iframe map can add weight and delay to a page whose real job is to show a phone number, an address, and opening hours. Click-to-load solves both problems at once: fewer initial requests, and an explicit action from the visitor.
What the block actually needs
The pattern has two states. In the closed state, the visitor sees the address in text, a self-hosted static map image, a short line explaining that the interactive map is optional, and a button labelled something like Load interactive map. In the open state, that button is replaced by the iframe, with focus moved sensibly and the rest of the block unchanged.
The static image matters. Do not hotlink a Google Static Maps image as the fallback, because that is still a request to Google on page load. Generate a map screenshot once, host it in the WordPress media library, and add clear attribution if you are using OpenStreetMap-derived imagery. A simple location card with a pin icon also works; the point is to give people a visual anchor without a third-party call.
Accessibility is part of the pattern, not a polish pass. The trigger should be a real button element, not a div with a click handler. It should have an accessible name, expose its state with aria-expanded, and sit inside a container that receives focus when the iframe loads. The iframe needs a descriptive title, such as the business name and street. Directions links should be ordinary links to Google Maps or Apple Maps, opening in a new tab with rel set to noopener, plus the full address written out for anyone using a screen reader, a paper diary, or a satnav.
Building it in Elementor Pro
Start with a Section or Container on the contact page. Add a Heading for the location, a Text Editor block for the address and opening hours, and an Image widget for the self-hosted static map. Keep the visual treatment consistent with the rest of the site; this should look like part of the page, not a compliance warning.
Add an HTML widget for the button and the empty map container. Give the container a data-map-src attribute holding the Google Maps embed URL. The button should not contain the iframe URL in the visible markup, and nothing should preload it. A short inline script, or a snippet loaded in the footer through your usual code snippets plugin, listens for the click, creates the iframe, copies the data-map-src value into src, sets the title, and appends it to the container. Then hide the button and move focus to the iframe or to a status message.
If you are using Elementor Pro's built-in Google Maps widget, check its behaviour carefully. It is designed to render the map on page load, which is exactly what we are trying to avoid. Use the HTML widget approach instead, or wrap the widget in your own click-to-load logic. Test on a staging site with the browser network panel open; do not assume the widget is lazy just because it sits lower down the page.
Keep the styling in Elementor where possible. The button can use the site's existing button styles, and the container can have a fixed aspect ratio so the page does not jump when the iframe appears. A small CSS rule for the iframe, width 100% and height 100%, is usually enough.
Consent scripts: sequence, don't stack
Most UK client sites now run a consent management platform, whether that is CookieYes, Complianz, Cookiebot, or a custom build. The click-to-load map should work independently of that banner. It is a direct action by the visitor, not an analytics category. If the consent tool blocks all iframes by default, make sure it does not also block the map after the visitor clicks the button. Double-gating is a common bug: the visitor says yes to the map, and the consent script quietly says no.
If the client wants the map to load automatically after consent, that is a separate enhancement. Listen for the consent tool's event, check the relevant category, and only then inject the iframe. Do not use analytics consent as a proxy for map consent. They are different purposes, and a visitor who rejects analytics may still want directions to the shop.
Also check the order of scripts. If your consent banner loads late, the map button must still be usable. If the banner loads early and blocks the inline script, test again with the banner in its default state. The pattern should degrade to a visible address and directions links even if JavaScript fails entirely.
A five-minute test routine
Open the contact page in a private window with DevTools on the Network tab. Filter for google and maps. Before clicking anything, there should be no requests to Google Maps, no map tiles, and no third-party cookies from the embed. The static image should load from your own domain.
Next, click the button. The iframe should appear, the network panel should show the Google requests, and keyboard focus should land somewhere sensible. Reload the page and repeat with the consent banner in both accept and reject states. On mobile, check that the button is easy to tap and that the page does not shift when the map loads.
Finally, run a quick accessibility check: tab to the button, press Enter, and confirm the iframe has a title. Use a screen reader if you have one to hand. The directions links should be reachable without loading the map at all.
What to tell the client
Explain the change in plain terms: the map is still there, but it now waits for a click, which keeps the contact page cleaner under UK privacy rules and speeds up the first load. Give them the static image and the directions links as the fallback story, and note that the interactive map is one click away. Most clients will be relieved that the page still does the job, and you will have one fewer third-party request firing before anyone has said yes.