Scraping Google Maps: Search Results, Reviews, and Place Details Using Python

Finding the best burger spot in the city you're visiting is EASY in Google Maps.

Extracting names, websites, and phone numbers of a few thousand businesses across tens of different cities?

A week's work.

Well, not anymore.

Google Maps is the largest local business database on the internet. And even if it really does not want you downloading it, you can.

Three extraction layers make this possible: search result listings, individual place details, and user reviews. Each has a working Python script and structured JSON output. All requests go through Scrape.do with super=true to handle Google's bot protection. If you are working on other Google properties, the Google search results scraping guide covers the general SERP approach.

You can find the complete scripts in the GitHub repository.

Scraping Google Maps Search Results

Google Maps search results contain business names, ratings, review counts, categories, addresses, coordinates, and thumbnail images. The typical approach would be to render the page in a headless browser and parse the HTML, similar to scraping JavaScript-rendered pages. But Google exposes a better path.

The tbm=map search endpoint returns structured protobuf-over-JSON data instead of HTML. No BeautifulSoup, no CSS selectors, no waiting for JavaScript to render a page. The response is a serialized nested array that can be parsed with regex against predictable field patterns.

This approach is more stable than scraping rendered HTML because the data structure follows Google's internal schema rather than a front-end layout that changes with A/B tests.

And it is significantly faster: one HTTP request instead of a full browser page load.

Prerequisites

The search scraper uses only requests and standard library modules:

A Scrape.do account is needed for the API token. Free tier available at scrape.do/register.

The token goes into the TOKEN variable at the top of each script. All scripts use the placeholder <your_token>.

Understanding the tbm=map Endpoint

Google Maps search queries can be sent to https://www.google.com/search?tbm=map instead of the standard Maps URL. The pb (Protocol Buffers) parameter controls which data fields the server returns. It acts as a field selector: !7i20 requests 20 results per page, and other segments enable metadata like coordinates, ratings, and place types.

The response starts with )]}'\n, an anti-XSSI prefix Google adds to prevent direct JSON hijacking. Strip this prefix and you get a massive nested JSON array.

Here is how the script sets up the search query and protobuf parameter:

Each ! segment in the SEARCH_PB string is a protobuf field selector. The {query} placeholder gets URL-encoded before insertion, and the full target URL points to google.com/search?tbm=map.

Sending the Request Through Scrape.do

Google Maps blocks direct requests from datacenter IPs and requires cookie/session handling to avoid CAPTCHAs. Rotating proxies are essential here. Scrape.do's super=true parameter handles residential proxy rotation and anti-bot bypass in a single API call.

The target URL is URL-encoded and passed as the url parameter to api.scrape.do. The geoCode=us parameter ensures the proxy IP is US-based, which affects which business listings Google returns. The response validation checks for the )]}'\n prefix to confirm the response is genuine Google data, not an error page.

Parsing Place Data with Regex

The response is a deeply nested JSON array. Navigating it by array indices is brittle because Google shifts positions between updates. A regex-based approach targets predictable field patterns that remain consistent: rating and review count appear as rating, review_count], followed by the feature ID in hex format, the place name, a null separator, and a type array.

Five capture groups pull out the key fields: rating (e.g., 4.7), review count (e.g., 362532), feature ID (e.g., 0x47e671d877937b0f:0xb975fcfa192f84d4), place name (e.g., Louvre Museum), and type array (e.g., "Art museum", "Museum"). A seen set deduplicates by feature ID since the same place can match multiple times in the response.

For each regex match, the script grabs a context window (500 chars before, 5000 chars after) and searches for nearby fields:

Address extraction looks for the pattern "Place Name, address string" in the surrounding context. Website extraction grabs the first non-Google HTTPS URL. Coordinates come from the [null, null, latitude, longitude] pattern. And image URLs match the lh3.googleusercontent.com/gps-cs-s/ prefix.

Each place ends up as a dict with 10 fields: name, feature_id, rating, review_count, types, address, website, latitude, longitude, and image.

Saving Search Results to JSON

The results write to maps_search_results.json with ensure_ascii=False for international characters (French museum names, accented addresses).

The sample output for "museums in paris" contains 20 places. The Louvre Museum shows up with rating 4.7, 362,532 reviews, types ["Art museum", "Museum", "Tourist attraction"], address "75001 Paris, France", and coordinates 48.86/2.34.

The feature ID is the key field here. It is the unique identifier that connects search results to the detail and review scrapers. Every feature ID from this output can feed directly into the next two scripts.

Extracting Place Details from a Single Location

Search results provide summary data: name, rating, address, types. But a full place detail page adds phone number, website, business hours, editorial description, and higher-resolution images. If you are building a lead database, you need these fields.

Google exposes place details through a /maps/preview/place endpoint that also returns protobuf-over-JSON. The input is a feature ID, which can come from the search results scraper or directly from a Google Maps URL.

Look at this URL for Musee de l'Orangerie:

The feature ID 0x47e66e2eeaaaaaa3:0xdc3fd08aa701960a is right there in the URL. That is the input the detail scraper needs.

Building the Detail Request

The /maps/preview/place endpoint takes a pb parameter with the feature ID embedded. The pb string includes field selectors for all detail data.

The !1s{fid} segment injects the feature ID. Other segments request specific data fields: !1i1024!2i768 sets the viewport for photo resolution, !4e2 enables review metadata, !17b1 enables business hours. The target URL points to google.com/maps/preview/place with the encoded pb parameter.

The Scrape.do API call uses the same super=true and geoCode=us parameters as the search scraper:

The response validation checks for the same )]}'\n anti-XSSI prefix. If it is missing, the response is likely an error page or CAPTCHA.

Extracting Detail Fields

Each field is extracted with a targeted regex pattern against the serialized response. Same strategy as the search scraper, but with more field-specific patterns.

Name and types:

The regex matches "feature_id", "name", null, ["type1", "type2"]. Rating and review count sit before the feature ID block in the response, following the rating, review_count] pattern.

The full address appears as "Place Name, full address string" in the response. The detail page returns the complete address including street number, which the search results sometimes truncate.

Website extraction is more specific here. The URL appears before the feature ID, paired with a clean domain string:

Phone number matches the international format pattern "+digits and spaces". Coordinates use the same [null, null, lat, lng] pattern. Editorial description sits in arrays like [null, "Description text", null, null, null, 1], and the regex filters out URLs and hex strings to avoid false matches.

Business hours require their own pattern. Each day appears as ["Monday", ...[[" 9 AM-5 PM":

Unicode whitespace characters (\u200b, \u202f, \xa0) need cleaning, and Google's special dash characters get normalized to standard hyphens. (Ask me how I found out about the invisible zero-width spaces. The hard way.)

Saving Place Details to JSON

The script assembles all 12 fields into a single dict and writes to maps_place_details.json.

The output for Musee de l'Orangerie shows: rating 4.6, 23,184 reviews, types ["Art museum", "Museum"], full address "Jardin des Tuileries, 75001 Paris, France", phone "+33 1 44 50 43 00", website, coordinates, editorial description ("Museum with 20th-century European art collection, showcasing 8 of Monet's water lilies murals."), and business hours for all 7 days (Tuesday: Closed).

Compared to the search results entry for the same place, the detail scraper adds three critical fields for lead generation: phone, description, and hours. These are not available in the tbm=map response.

Scraping Google Maps Reviews

Google Maps reviews contain rating, review text, timestamp, reviewer name, reviewer badge (e.g., "Local Guide"), visited date, and language tag. For businesses looking to analyze customer sentiment or competitors researching service quality, reviews are the most actionable data layer on Google Maps. Researchers working with academic institutions listed on Maps can complement this location data with citation metrics from Google Scholar.

Reviews are served through a separate RPC endpoint: /maps/preview/review/listentitiesreviews. This endpoint returns pure JSON (after stripping the anti-XSSI prefix), not HTML. A single request returns up to 10 reviews, and incrementing the offset by 10 paginates through the full review set.

The endpoint supports four sort modes: 1 = most relevant, 2 = newest, 3 = highest rated, 4 = lowest rated.

Converting the Feature ID for the Reviews Endpoint

The reviews endpoint requires the feature ID in a different format. The two hex halves need to be converted to signed 64-bit integers.

Each hex half is stripped of the 0x prefix, converted to bytes with bytes.fromhex(), then unpacked as a signed 64-bit big-endian integer with struct.unpack(">q", ...). The sys.stdout.reconfigure(encoding="utf-8") line handles international characters in reviews (Japanese, Turkish, etc.) that would break on default Windows console encoding.

Building the Review Request

The pb parameter controls pagination and sorting:

!1m2!1y{fid1}!2y{fid2} passes the two signed integer halves. !2m1!2i{OFFSET} sets the page offset (0 for the first 10 reviews, 10 for the next 10). !3e{SORT_RELEVANT} controls the sort order. And !4m5 enables review text, photos, badges, and language fields.

The Scrape.do API URL follows the same pattern as the other two scrapers.

Parsing the Review Response

Unlike the search and detail scrapers, the review response is clean enough for direct JSON parsing instead of regex:

Aggregate stats sit in data[5], which holds the star distribution as a 5-element array: [1-star count, 2-star count, 3-star count, 4-star count, 5-star count]. Overall rating is calculated as a weighted average.

Individual reviews live in data[2]. Each review is a nested array with fields at specific indices:

rev[0] holds author info (name, profile URL, photo). rev[4] is the star rating. rev[1] is the relative timestamp ("2 weeks ago", "3 months ago"). rev[3] is the full review text. And the reviewer's badge (like "Local Guide" with review count) is buried deep at rev[12][1][10].

Pagination and Sort Options

Each request returns up to 10 reviews. To collect more, increment OFFSET by 10 and send another request. A production loop would start at OFFSET = 0, check if data[2] returned results, increment by 10, and repeat until no more reviews come back.

The four sort modes produce different review sets. 1 (relevant) gives Google's default ranking, mixing recent and high-engagement reviews. 2 (newest) is chronological, useful for monitoring recent sentiment. 3 (highest) returns 5-star reviews first, good for extracting positive testimonials. 4 (lowest) returns 1-star reviews first, useful for complaint analysis.

Changing the sort value in the pb parameter is all that is needed. No other request parameters change.

Saving Reviews to JSON

The output dict includes feature_id, overall_rating, total_reviews, rating_distribution (per-star counts), extracted_count, and the reviews array. It writes to maps_reviews.json.

The sample output for Carnavalet Museum contains 20 reviews. Star distribution: 8,899 five-star, 2,060 four-star, 407 three-star, 112 two-star, 128 one-star. The overall rating calculates to 4.7 from 11,606 total reviews. Reviews include text in English with relative timestamps and visited dates.

Conclusion

Three extraction layers cover the full Google Maps data pipeline: search listings for bulk discovery, place details for complete business profiles, and reviews for sentiment and feedback data. If your pipeline also requires media monitoring, the same proxy-based approach applies to Google News.

The tbm=map and /maps/preview/ endpoints return structured protobuf-over-JSON, avoiding HTML parsing entirely. For approaches that do require HTML parsing, BeautifulSoup is the standard Python web scraping tool. Scrape.do's super=true parameter handles the anti-bot layer so the scripts focus on data extraction rather than request engineering.

The feature ID acts as the connector between all three layers. Search results return feature IDs, which feed into the detail and review scrapers. A pipeline that combines all three gives you name, category, phone, website, hours, ratings, and full review text for every business in a search query.

For teams evaluating structured API alternatives instead of raw scraping, the best SERP APIs comparison covers 8 providers with Google Search endpoints.

So what does this look like in practice? A single search query returns 20 businesses. Expand that across 50 cities and you have a lead list of 1,000 businesses with verified phone numbers, websites, ratings, and customer sentiment. For e-commerce businesses, pairing this with Google Shopping product data creates a complete competitive picture. That is the kind of dataset that turns cold outreach into informed outreach.

Get 1000 free credits and start scraping with Scrape.do

FAQ

How many results does a single Google Maps search request return?

The !7i20 segment in the protobuf parameter requests 20 results per page. Google typically returns between 15 and 20 results depending on the query and location. The same pb parameter can be modified to request different page sizes, though 20 is the practical maximum per request.

Can the reviews scraper collect all reviews for a place?

Each request returns up to 10 reviews. Pagination through the offset parameter (!2m1!2i{offset}) allows collecting the full review set. A place with 11,606 reviews (like Carnavalet Museum) would require approximately 1,161 paginated requests. Rate limiting and Scrape.do credit consumption should be factored into large-scale extraction plans.

Why use the tbm=map endpoint instead of scraping the regular Maps page?

The regular Google Maps page loads results through JavaScript rendering, requiring a headless browser. The tbm=map endpoint returns the same data as structured JSON (protobuf format), parseable with regex or direct JSON indexing. Faster (single HTTP request vs. browser page load), more reliable (no rendering failures), and cheaper (no render=true parameter required on Scrape.do).

What does the super=true parameter do?

super=true activates Scrape.do's premium proxy pool with residential IPs and advanced anti-bot bypass. Google Maps aggressively blocks datacenter IPs and requires valid browser fingerprints. The super=true mode handles TLS fingerprinting, cookie management, and IP rotation automatically. Without it, Google returns CAPTCHAs or empty responses for most Maps endpoints.

Is it possible to filter reviews by language?

The reviews endpoint returns reviews in all languages by default. The hl=en parameter in the request URL influences which language Google prioritizes but does not filter exclusively. Each review includes a language field (e.g., "en", "fr", "ja") that can be used for post-extraction filtering in Python.