Adding Google Maps to WordPress
A map is the heaviest thing most contact pages load, and on many sites it is also an untracked third-party connection. Both are fixable, and the cheapest fix is often not to embed a live map at all.
A map on a contact page is a third-party application embedded in your site. It loads scripts, tiles, fonts and often cookies, all before the visitor has scrolled to it. Before choosing how to add one, decide whether you need an interactive map at all — for most contact pages, an address, a link and a static image outperform an embed on every measure that matters.
The three ways, ranked by cost
| Method | Needs a key | Weight | Control |
|---|---|---|---|
| Share-and-embed iframe | No | Heavy | None |
| A map plugin | Usually | Heavy plus plugin assets | High |
| Maps JavaScript API by hand | Yes | Heavy, but only what you use | Total |
| Static image plus a link | No | Almost nothing | N/A |
Start at the bottom row and work up only when a requirement forces you.
The simplest embed
On Google Maps, find the place, choose Share, then the embed option, and copy the iframe. Paste it into a custom HTML block. That is the whole procedure, and it is the right answer for a single location with no custom styling.
Two changes to make to the pasted markup:
<iframe src="https://www.google.com/maps/embed?pb=…"
width="600" height="450"
style="border:0; max-width:100%;"
loading="lazy"
referrerpolicy="no-referrer-when-downgrade"
title="Map showing our office at 12 Example Street"></iframe>
loading="lazy" stops the map loading until it is near the viewport, which on a long page means most visitors never pay for it. The title attribute is what a screen reader announces — without it the frame is unlabelled. Keeping width and height also gives the browser the aspect ratio to reserve, which is one of the causes covered in cumulative layout shift.
If you are pasting the iframe into a page and it disappears, that is the editor stripping markup rather than the map failing — adding code to a page explains which editors do that and why.
When a plugin is justified
A plugin is worth it when you need something the plain embed cannot do:
- Several locations, or a store locator with search.
- Custom markers, or map styling that matches the site.
- Routes, shapes or data layers.
- Maps managed by editors who should not touch markup.
What to check before installing one:
- Does it load its assets on every page or only where a map exists. Sitewide loading for one contact page is the most common waste, and shows up when chasing render-blocking resources.
- Where does the API key live — the settings screen is fine, a hard-coded key in a template is not.
- Does it support a click-to-load placeholder, which you will need for consent.
- What happens when the plugin goes. Most store locations as a custom post type, which is portable; some keep them in their own tables, which is not.
Note that a plugin is not required for an interactive map and does not make one lighter. It replaces markup you would otherwise write with an interface.
Restricting the API key
Any method using the Maps JavaScript API needs a key, and an unrestricted key on a public page is billable by anybody who copies it.
Restrict it before it goes live:
- In the Google Cloud console, restrict the key by HTTP referrer to your domains, including the staging domain if you have one.
- Restrict it by API, enabling only the specific Maps APIs the site uses.
- Set a budget alert on the project so unexpected usage is noticed.
- Use a different key for staging and production.
A key in your page source is public by design — restriction, not secrecy, is the protection.
Consent, stated plainly
An embedded map contacts a third party and may set browser storage before any interaction. Where consent rules apply, that is a transfer you need permission for.
The practical pattern is a placeholder: show a static image or a styled box with the address and a "load map" button, and only insert the iframe or script after the click. Most cookie consent plugins can block map embeds until consent is given, and doing this also solves the performance problem for free, because visitors who never click never load anything.
The alternative worth considering seriously
For a single-location contact page, this outperforms an embed on speed, consent and reliability:
- The address as real text, so it can be copied and read by assistive technology.
- A static image of the map area, sized correctly and lazy-loaded — see optimising images.
- A link that opens the location in the visitor's own maps app, where they were going to get directions anyway.
The link is the important part. Nobody plans a route inside your iframe on a phone; they tap through to their maps app. Sending them there directly skips the heavy embed entirely.
Common mistakes
- Embedding on every page through a footer widget, paying for a map sitewide.
- An unrestricted API key, discovered through a bill.
- No lazy loading, so the map competes with content for bandwidth on first paint.
- An
http://embed on anhttps://site, which browsers block — the case covered in mixed content warnings. - No address in text. A map is not an address; search engines and screen readers need the words.
Verify
Load the contact page with the network panel open and check that no map request happens until you scroll to it or click the placeholder. Confirm the address appears as selectable text. Open the page on a phone and tap through to directions. Then check the key is referrer-restricted by loading the same embed from a domain that is not yours — it should fail.
Frequently asked
- Not for a simple share-and-embed iframe copied from Google Maps. You need a key for anything using the Maps JavaScript API, which includes most map plugins with custom markers, styling or multiple locations.
- A live map loads a third-party script, tile images and fonts, and it does that on page load whether or not the visitor scrolls to it. On a contact page it is usually the single largest resource on the page.
- Where consent rules apply, usually yes. An embedded map contacts a third party and can set storage on the visitor's browser before they have interacted with anything, so most consent setups place it behind a click-to-load placeholder.