Integrating an interactive map into a website is not just about pasting a piece of HTML code into a page. The choice of mapping provider, the integration method, and the legal obligations related to third-party trackers affect both technical performance and user experience. This guide breaks down the concrete friction points posed by adding a custom map, from GDPR consent to the hidden costs of APIs.
Third-party trackers and GDPR consent: the prerequisite that the map imposes
Before even discussing iframe or script, a legal point needs to be addressed. As soon as a third-party map loads on your page, it can drop cookies or trackers on the visitor’s browser.
Regulations require that these trackers be identified according to their origin and purpose. When they require consent, it must be obtained before the tracker is placed or read. Refusal must be as easy as acceptance, and the choice should be modifiable later.
In practice, this means that an embedded Google Maps or Mapbox map loads with the page, before any interaction. If your consent banner has not yet received a response, you are potentially in violation. There are two technical solutions to manage this case properly, each with a cost in user experience.
- Deferred loading (lazy consent): the map only loads after explicit acceptance of cookies. In the meantime, the visitor sees a static placeholder (an image of the map or an information message). Legally reliable, but the visitor who refuses cookies will never see the map.
- Self-hosted map with OpenStreetMap or MapLibre tiles: no third-party tracker is placed since the mapping data is served from your own infrastructure or from servers that do not drop cookies. More complex to set up, but consent is no longer an obstacle to display.
- Fallback image: a clickable screenshot that links to the full-screen map after consent. A minimalist approach, suitable for showcase sites with a single location point.
Testing your site without prior consent, in private browsing, allows you to check which trackers are actually placed by the map. It’s a quick audit that many developers overlook.
To delve deeper into web mapping on Portail Web, the integration steps are detailed there with concrete examples according to the platforms.

Actual cost of mapping APIs: Google Maps, Mapbox, and free alternatives
The advertised free tier from major mapping providers hides a pricing structure that depends on the features actually used. A simple map display, an address search, and route calculation are not billed at the same rate.
Google Maps Platform
Google offers 10,000 free loads per month for map displays. Beyond that, billing goes to $7 for 1,000 additional loads. Geocoding, routes, and Street View views fall under separate pricing grids. A high-traffic site using several of these services can see its bill rise without the number of displayed maps changing.
Mapbox
Mapbox offers a more generous free threshold: 50,000 free loads per month, then $5 for 1,000 loads. The visual style of Mapbox maps offers more latitude in customization than Google Maps, which explains its adoption by editorial projects and tourism offices.
OpenStreetMap and MapLibre
OpenStreetMap provides mapping data under a free license. MapLibre GL JS, the client-side rendering library, allows displaying this data without relying on a paid service. The trade-off: hosting vector tiles and configuring the rendering remain your responsibility. The documentation for MapLibre GL JS v6 notes integration constraints related to modules and worker loading, which requires front-end skills that not all projects have in-house.
The choice of provider cannot be made solely based on the display price. The total cost depends on traffic volume, enabled features (geocoding, routing, places), and the technical capacity of the team to maintain a self-hosted solution.
Iframe vs script: what each method implies for SEO
The majority of tutorials propose the iframe as the default integration method. Copying and pasting a Google Maps integration link into an iframe tag takes thirty seconds. The result displays correctly on the page.
The problem lies on the SEO side. Google does not guarantee that the content of an iframe is attached to the page that hosts it. Place listings, route names, and descriptions embedded in the map remain in a separate document, invisible to the crawler in the context of your page. A map rich in useful data for local SEO loses all its SEO value if served in an iframe.
Script integration (JavaScript) loads the map directly into the page’s DOM. The associated data (markers, popups, listings) become part of the HTML document. This method requires more work, but it allows structuring the mapping information in a way that search engines can utilize.

For a showcase site with a single address, the iframe remains acceptable. For a site displaying a network of points, routes, or detailed listings, script integration protects the SEO of the mapping content.
Measuring real engagement on an interactive map
Displaying a map is not enough. Knowing whether visitors actually use it helps justify the technical investment and the potential cost of the API. Production data from territorial maps shows telling results: 5 minutes 56 seconds average session duration on an interactive territorial map, and 41.4% of sessions open at least one route or place listing.
These metrics are not transferable to all sites. An e-commerce site with a store locator will not achieve the same session durations as a tourism office. The measurement tool (Google Analytics, Matomo, custom JavaScript events) must be configured to capture interactions specific to the map: clicks on markers, opening listings, changing filters, going full screen.
Without this tracking, the map remains a decorative element whose utility cannot be assessed. With it, it becomes a measurable component of the user journey, capable of justifying its maintenance or replacement with a lighter solution.



