One of the things that troubles me the most about scraped Google Maps data is how many different "IDs" a single place can have, and how inconsistent they are depending on where you find them.
There's place_id, cid, /g/... identifiers, and those long data=!4m7!... strings that look like someone accidentally exposed an internal serialization format. At some point you stop thinking in terms of "what is the ID" and start thinking "which version of the ID did I manage to catch this time".
Google Maps identifiers
Truth be told, the only identifier that really behaves the way you'd expect is place_id. It comes from the Google Places API, and it's clearly designed for external use. It's relatively stable, works cleanly across APIs, and ends up being the thing everything else gets normalized toward.
cid sits somewhere in between. You'll often see it in URLs like /maps?cid=..., and unlike most of the other fragments in Maps URLs, it is actually useful in practice. It's not part of any official contract, and it lives closer to how Google Maps represents listings internally in its UI layer, but it still works well enough as a direct pointer to a place.
Beyond these two, everything else is mostly noise for scraping purposes. /g/... identifiers are internal graph-style IDs that also refer to the same place entity, but they're opaque and not really practical outside Google's systems. Similarly, long data=!4m7!... fragments are just serialized UI state, bundling together coordinates, internal references, and sometimes embedded hints of cid or place_id, but not in a clean or reusable way.
So in practice, only two identifiers are actually worth caring about. place_id is the stable, API-level anchor. cid is a weaker but still usable UI-level pointer. Everything else is just incidental structure that happens to leak through when you inspect Maps URLs.
Why cid changes so often
While cid looks like a stable identifier, it actually behaves more like a pointer to a specific version of a listing inside Google Maps. That version can be rewritten at any time, which is why the same place can suddenly appear under a different cid.
It usually changes because:
- listing merges where duplicate places are consolidated
- recreation or re-verification via Google Business Profile
- internal cleanup or spam filtering that rewrites listings
- backend restructuring that regenerates identifiers
- edge-case deduplication based on name, address, or coordinates
From the outside, it just feels like the CID changed for no reason, even though the underlying place hasn't really changed in any meaningful human sense.
Extracting the IDs from scraped data
When you start working with scraped URLs from Google Search or Google Maps, the identifiers are rarely presented cleanly. Instead, they tend to be embedded inside a mix of URL fragments and encoded state, and you end up pulling out different pieces depending on whether you're targeting a place_id, a cid, or both.
Take this example:
https://www.google.com/maps/place/Arabica+Mississauga+Square+One/
data=!4m7!3m6!1s0x882b47ebb409bf1b:0xa706239755275e73
!8m2!3d43.5920654!4d-79.6440167
!16s%2Fg%2F11y7sw775z
!19sChIJG78JtOtHK4gRc14nVZcjBqc
Extracting place_id
- Find
!19s - Take everything after it until the next
!
Result:
ChIJG78JtOtHK4gRc14nVZcjBqc
Extracting cid
- Find the pattern
0x...:0x... - Take the second value:
0xa706239755275e73
- Convert it from hex to a regular decimal number
Result:
120706023975527573
The annoying part is that this place_id isn't always present in the URL, especially when you're just browsing normally. It tends to show up more reliably when you're scraping, rather than in links you copy directly from the browser.
Constructing URLs from place_id and cid
Once you’ve gone through the trouble of extracting these IDs, you can also use them to reconstruct direct links back into Google Maps.
If you have a place_id, the URL format is straightforward:
https://www.google.com/maps/place/?q=place_id:ChIJocoQ1PjL1IkRMAuLR_E-WA4
This uses the API-facing identifier, so it tends to be the more reliable option.
If you only have a cid, you can still build a working link:
https://www.google.com/maps?cid=120706023975527573 (but no, this link is no longer working as the cid has expired)
In cases where the cid came from the 0x... format in a scraped URL, you just convert it to decimal first, then drop it into the same structure.