Google Maps with Astro
A static map embed is fine for one address. A real locations page needs the Maps API, CMS data, key restrictions and a loading strategy so every page view does not become a billable map load.
Google Maps at a glance
- What I do
- Add a searchable, CMS-driven Google Map to Astro with locations, custom markers, clustering and loading rules that control cost.
- Typical setup
- Adds 2–5 days
- How it is bought
- Part of a migration scope, or a Continuous development request once the site is yours
- Category
- Maps and motion
Setup
How I set up Google Maps
A single office address can use the built-in element. A searchable, CMS-driven locations page needs a real map implementation.
I store location data alongside the content, including latitude and longitude, then render the map and list from the same source. That avoids paying to geocode the same address every time someone loads the page.
The API key is public by nature when the map runs in the browser. That is fine when the key is restricted correctly. It is risky when it is unrestricted, because anyone can copy it from the page source and spend against it.
How the handoff works
- 01
Location
Address and coordinates in the CMS
- 02
Load
The Maps API loads when needed
- 03
Render
CMS locations become markers
- 04
Sync
Map and list share one state
Key handoff
- 05
Verify
Filters, bounds and markers agree
Why this is the key handoff
The map is the easy part. Keeping it in step is not. A map appearing only proves the API loaded. I check that the CMS, the markers, the filters and the list beside them stay in step as somebody actually uses the page.
Included
What gets connected
-
Locations from your content layer displayed on a Google Map
-
Custom markers and map styling that matches the site
-
Clustering, bounds fitting and synced location lists
-
Stored coordinates instead of repeated geocoding
-
Keys restricted by site and by API, with a deliberate loading strategy
Before you add it
What to watch out for
- 01
The map and the list beside it are two renderings that drift
They are two views of the same data. Filter one without sharing state and the other keeps showing locations that supposedly disappeared, which reads as a bug rather than as a missing feature.
- 02
An unrestricted key is somebody else's quota
Browser keys are visible by design, so an unrestricted one can be used outside the site it was issued for. The defense is two restrictions rather than one: where the key may be used, and which Maps APIs it may call.
- 03
The map is one of the heaviest things on the page
A map is a substantial thing for a page to load. Where it is secondary I defer the API until the section nears the viewport or somebody interacts with it, which changes what that section looks like beforehand. Where the map is the experience, it loads with the experience.
More tools
Keep exploring
-
GSAP
Rebuild the motion a Webflow site had, in Astro: CSS where it is enough and GSAP where it is not, chosen on the control, the data and the maintenance the project needs.
Adds 3 days–2 weeks
-
Google Analytics
GA4 and Tag Manager set up on an Astro site with clean events, consent behavior and performance-conscious loading.
Adds 2–4 days
-
Salesforce
Site forms that create the right Salesforce records, preserve attribution and fail visibly when Salesforce rejects a submission.
Adds 3–5 days
Let me plan your next step.
I can scope a migration. Send a brief and I will reply by email with next steps.