How can I embed a Google Map showing multiple locations?

General
1

I’m trying to embed a Google Map on my website that shows several business locations with markers on a single map, but I’m confused about the best way to set this up. Do I need to use My Maps, the Maps JavaScript API, or something else to display and customize multiple pins, info windows, and map styles? I’d really appreciate clear steps or code examples so I can get this working correctly and keep it easy to update in the future.

2

Short version.

You have 3 realistic options, each fits a different use case:

  1. Easiest, no coding, few locations, static map
    Use Google My Maps.
    Steps:
    • Go to https://www.google.com/mymaps
    • Create a new map
    • Search each business, click “Add to map” for each one
    • Style the markers if you want
    • Click “Share”, set it to “Public” or “Anyone with the link”
    • Click the three dots next to the map name, pick “Embed on my site”
    • Copy the iframe code and paste it in your page HTML

Pros
• Fast.
• No API key.
• Works fine if your needs are simple.

Cons
• Limited styling.
• Not great if you need to update markers from code or a database.

  1. Flexible, code based, live data, more work
    Use Google Maps JavaScript API.
    You need this if you want custom behavior, custom marker icons, filtering, or dynamic locations.

High level steps:
• Go to Google Cloud Console
• Create a project
• Enable “Maps JavaScript API”
• Create an API key, restrict it to your domain
• Include the JS API in your page:

• In JS, do something like:

const locations = [
{ lat: 40.7128, lng: -74.0060, title: ‘NY Store’ },
{ lat: 34.0522, lng: -118.2437, title: ‘LA Store’ }
];

const map = new google.maps.Map(document.getElementById(‘map’), {
center: { lat: 39, lng: -95 },
zoom: 4
});

locations.forEach(loc => {
new google.maps.Marker({
position: { lat: loc.lat, lng: loc.lng },
map: map,
title: loc.title
});
});

• Add a

in your HTML with a fixed height via CSS.

Pros
• Full control over markers, popups, styles, clustering.
• Pull locations from your database or API.

Cons
• Requires an API key and billing account.
• More code to maintain.

  1. Simple embed for each address, no single shared map
    This is what a lot of people do by mistake. They embed separate maps for each address
    through the standard Google Maps UI. That gives you one iframe per location, not one map with many markers. You do not want this for your case.

What you pick:
• Use My Maps if you have a small fixed set of locations and you prefer a UI over code.
• Use the Maps JavaScript API if you have many locations, want to update them programmatically, or need custom features like search, filters, or clustering.

From your description, you want a single map with multiple markers on your site, no heavy custom behavior. I would start with My Maps, embed that iframe, and only move to the JS API if you hit My Maps limits later.

3

You’re basically choosing between “Google does the work for me” and “I control everything and suffer slightly for it.”

@caminantenocturno covered the two big paths (My Maps vs JS API), so I’ll fill in some gaps and nuance instead of repeating the same click‑here, click‑there instructions.

1. How to decide in under a minute

Ask yourself:

  • Do my locations change often?
  • Do I want the data to come from my own system (database / CMS / API)?
  • Do I care about performance with lots of markers?
  • Do I want the map to actually feel like part of my site design?

Rough rule:

  • If the answer to all of those is “no,” My Maps is usually fine.
  • If you said “yes” to even one in a serious way, you’re probably headed to the Maps JavaScript API.

Where I slightly disagree with @caminantenocturno:
If you have more than ~20 locations or you expect to keep adding them, I would not start with My Maps. It gets messy to manage, and non‑dev users end up accidentally changing stuff. You’ll eventually redo it in code anyway.

2. A middle ground people forget: static data + JS API

You don’t have to jump straight into some huge dynamic system. A nice compromise:

  • Keep your locations in a simple JSON file or inline JS array.
  • Use the Maps JS API just to loop over them and drop markers.
  • No database, no backend coding, but still much easier to maintain than editing a My Map through the UI.

Example structure (pseudo, not full code):

const locations = [
  { name: 'Main Store', lat: 40.1, lng: -73.9, url: '/locations/main' },
  { name: 'Branch A',  lat: 39.9, lng: -74.2, url: '/locations/branch-a' }
];

// Init the map once, then:
locations.forEach(addMarker);

You can later swap that array for data loaded from your backend without changing the rest of the logic. Future you will thank past you. Maybe.

3. Things no one tells you until it’s too late

  • Mobile usability:
    My Maps embed is ok, but it can feel a bit “stuck in an iframe.” With the JS API, you can control zoom limits, gesture handling, and where info windows open so the user isn’t pinching around in a postage stamp.

  • Branding and styling:
    If you want custom colors, custom map styles, or branded marker icons, JS API wins hard. My Maps lets you change colors and icons a bit, but it will always look “Googley.”

  • Clustering:
    Once you hit a bunch of locations in a city, you get a mess of overlapping pins. With JS API you can add marker clustering, so it groups pins into clusters and expands as you zoom. My Maps has only basic handling; with lots of points it becomes a glitter explosion.

  • Control over links and behavior:
    Want clicking a marker to open a panel on your page instead of a Google bubble? Or trigger analytics events when users click a location? That is JS API territory.

4. When My Maps is actually the right answer

Despite all that, My Maps is still legit if:

  • You have under ~20 mostly fixed locations.
  • A non‑technical person needs to edit locations.
  • You are ok with a basic iframe that just “shows the spots.”

In that case, set it up once, embed it, forget about it until you move offices.

5. My recommendation based on your post

You said: one map, multiple business locations, not sure what to use.

  • If this is a small business with a handful of branches and you don’t expect big changes:
    My Maps is acceptable, embed it and move on with life.

  • If you’re building something a bit more serious (lots of locations, ongoing updates, or you care about UX / branding):
    Bite the bullet, set up the Maps JavaScript API once, store your locations in a simple data structure, and render them with code. It’s more work day one but a lot less annoying in the long run.

If you share how many locations you’ve got and whether they come from a CMS or are just typed in by hand, you can get a much more specific “do this, skip that” answer.

4

Short analytical breakdown, building on what @waldgeist and @caminantenocturno already covered:

  1. Where I slightly disagree
    They both lean pretty strongly into “My Maps for simple / few locations, JS API for serious stuff.” I’d add a third mental filter: who is going to maintain this in 6–12 months.
  • If it is always a dev: skip My Maps entirely and go straight to the Maps JavaScript API or a small wrapper around it. Even for 5–10 locations, code is usually cleaner long term than a My Maps UI that only one person remembers how to edit.
  • If it is a non‑technical team: My Maps is fine, but I would keep a parallel spreadsheet of locations as the “real” source of truth, because people forget what they added to the My Map.
  1. A pattern that works well in real projects
    Instead of choosing hard between “pure My Maps” and “full custom JS,” a lot of teams do:
  • Start with an internal spreadsheet or a JSON file listing: name, address, lat, lng, URL, category.
  • Use that same data to generate:
    • A My Map (for marketing / internal people to play with).
    • A JS-based embed on the website that you actually control.
      This avoids the trap where your website map quietly diverges from the list in your CMS or CRM.
  1. What everyone forgets: maintenance and ownership
    Questions that matter more than “My Maps vs API” in practice:
  • Who updates locations when you open or close a branch?
  • How often does that happen?
  • Does legal / compliance care about how locations are displayed, grouped, or filtered?
    If your business changes locations a lot or you have to be precise (for example regulated services, delivery zones, etc.), then the Maps JavaScript API with a single canonical datastore wins almost every time, even if it is more work up front.
  1. Performance & UX details that tip the scale
  • My Maps
    Pros: dead simple setup, no code, quick embed.
    Cons: clunky with many markers, less control over mobile behavior, harder to A/B test or track events.
  • Maps JavaScript API
    Pros: clustering, custom styles, control of click behavior, can integrate analytics, can preload data efficiently.
    Cons: billing setup, rate limits to watch, more code surface to keep secure and up to date.
  1. About the empty product title ’
    If you are thinking of this as a reusable “store locator” component on your site, treat ’ as a kind of internal product: a central map module that all location pages share.
  • Pros: one place to maintain logic, easier branding, consistent UX across the site.
  • Cons: initial setup cost, you need someone comfortable with JavaScript, testing on multiple devices is on you.

Compared to what @waldgeist and @caminantenocturno suggested, I would say:

  • If you already have any dev velocity at all, investing in that central JS-based locator (your internal ') sooner rather than later tends to pay off.
  • My Maps is fine as a short-term or marketing-only solution, but expect to outgrow it if your locations or requirements change more than occasionally.