How to Scrape the Most Out of Google Maps Places

Every place-details tutorial shows you a perfect JSON object with every field filled in. I have never seen one in real life.

So I audited the Serpent Google Maps API place endpoint against four real businesses on August 3, 2026. The result is not a screenshot of a dream schema. It is a measured list of which fields actually come back, which fields are always missing, and how to store identifiers so your database survives the differences.

Real Data from Four Businesses

I ran four place detail lookups after two Maps searches. Every request returned HTTP 200. Here is what came back, with the elapsed time for each:

Core contact and display fields came back on every record. But a fuller audit of the standard 15-field set tells the real story:

12 of 15 standard fields present on every record; description, business_status, and price_range absent in all four. August 2026, sample size 4.

That 12-of-15 result is the practical contract. The three missing fields are not bugs — they are fields the public place view does not reliably expose. In the broader 97-place search sample, business_status was actually present on 100% of complete records, which shows the same business can expose different fields through different surfaces. Store the record, not the assumption.

Identifier Choices

The endpoint accepts exactly one of place_id, data_id, or a Google Maps URL. For a durable database, keep every identifier you receive. Use place_id for API follow-ups when present, but keep data_id and maps_url as fallbacks because Google can rotate which identifier is stable for a given place over time.

curl --get "https://apiserpent.com/api/maps/place" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "place_id=ChIJ..."

Field Storage Pattern

Design your table so every non-key field can hold NULL. The honest-null contract means a missing field is absent, never fabricated. A record like this is what a real response looks like:

{
  "place_id": "ChIJ...",
  "data_id": "...",
  "maps_url": "https://www.google.com/maps/...",
  "name": "South Austin Dentist",
  "phone": "...",
  "website": "https://...",
  "rating": 4.9,
  "opening_hours": {},
  "cover_image": "https://...",
  "description": null,
  "price_range": null,
  "business_status": null
}

Note the three null fields at the bottom. In the audit, those came back null on every single record. If your downstream code treats them as required, you will build a bug that looks like a data problem.

How This Compares to Search Records

The place endpoint is a single-record view; the search endpoints return ranked lists. Both draw from the same public place data, but coverage differs. Across 97 complete search records, the reliably-achievable rates were:

• 100%: business_status, opening_hours, images, rating, plus_code
• 96%: amenities
• 92%: website
• 70%: phone

Phone is the one that bites. Even a complete record can come back without a phone roughly a third of the time. If you are building lead generation on this data, the Maps-to-email pipeline and the no-website finder both start from this same completion-aware rule: classify only complete records, and never treat a missing field as a confirmed fact.

Primary Sources

• Google Place Details documentation
• Google Places field masks and billing
• Serpent Google Maps API

FAQ

Which identifier should I store?

Store place_id when available, plus data_id and maps_url if your workflow receives them. Keep every identifier you receive because Google can rotate which one is stable for a given place.

Are place detail fields always present?

No. In a four-business audit, 12 of 15 standard fields were present on every record. Description, business_status, and price_range were absent in all four. Treat those as nullable.

What fields did the August 2026 audit show?

Four place detail lookups returned place_id, data_id, maps_url, name, phone, website, rating, review_count, opening_hours, timezone, cover_image, and image_count on every record.

Can I look up a place by URL instead of an ID?

Yes. The endpoint accepts exactly one of place_id, data_id, or a Google Maps URL. Each route resolves to the same rich place record.

How does place details field coverage compare to search?

Across 97 complete search records, business status, opening hours, images, rating, and plus code hit 100%. In the four-business detail audit, business status was absent on all four. The same place can expose different fields through different surfaces.

Is a missing field fabricated or null?

Null. Fields Google does not expose for a place come back null, never fabricated. Absence is honest, so plan your schema around nullable fields.