---
title: "Scrape Google Business Listings: Fields, Dedup, Cost"
description: "Scrape Google business listings properly: which fields to trust, the cap that truncates your list, how to deduplicate, and the cost per usable row."
canonical: "https://derrick-app.com/business-data/scrape-google-business-listings"
category: "Business Data"
updated: "2026-08-26"
---
# Scrape Google Business Listings: What You Get, and What You Have to Fix
> When you scrape Google business listings you get three tiers of field, not one record: machine generated keys you can join on, owner declared details you have to verify, and crowd produced review counts that work as a size proxy. A single search silently caps out around 100 to 120 results, so real coverage needs geographic segmentation, which in turn manufactures duplicates. Deduplicate on the place identifier first and on normalised address plus phone second, never on the business name. The number that matters is cost per usable row, not per row returned.
*Canonical: https://derrick-app.com/business-data/scrape-google-business-listings* · *Business Data*
---
A listing export looks finished the moment it lands. It is not. It is truncated in a way nothing warns you about, duplicated by the very method that made it complete, and full of fields that were produced by different people with very different levels of care. This guide walks the gap between an export and a list a rep can actually work.
## What you get when you scrape Google business listings
A Google business listing is not one record. It is a small bundle of fields that were filled in at different times, by different people, with very different levels of care. The owner typed the name and the category. Google generated the coordinates and the place identifier. Customers produced the rating and the review count. Nobody verified any of it against a registry.
That matters, because the fields do not deserve equal trust. Sorting them by how they were produced is the single most useful thing you can do before importing anything.
| Tier | Fields | Why you can lean on it |
| --- | --- | --- |
| Machine generated | Place identifier, latitude and longitude, Maps URL | Produced by Google, stable across pulls, safe as a join key |
| Owner declared | Business name, category, phone, address, website, opening hours, price band | Accurate when the listing is claimed, stale or wrong when it is not |
| Crowd produced | Star rating, review count, photos, review text | Never a fact about the business, always a signal about its visibility |
The practical rule that falls out of this: join on the machine tier, segment on the crowd tier, and treat the owner tier as a claim you may have to check. A phone number on an unclaimed listing is a lead, not a fact. The same phone number on a claimed listing with 300 reviews is close to certain.
One field deserves a warning of its own. The website URL is the field most people build their whole pipeline on, and it is the field most likely to be missing entirely. Independent local businesses very often run on a social page and a phone line. If your downstream process assumes a domain, a large slice of the list falls out of the funnel before you have even looked at it.
## Is this allowed, and what the official route gives you instead
This question comes up before the first row is pulled, and most guides answer it with a shrug. The honest answer has three parts, and they are not the same question.
**The data is public.** A business listing is published so that customers can find it. A name, an address, a phone number and opening hours displayed on a public page are not personal data in the sense that a private individual's details are, and collecting them for business to business prospecting is ordinary commercial research. That said, the moment you attach a named person to a record, European data protection obligations attach with them: you owe that person information about the processing and a way to object, and you need a lawful basis you can actually articulate.
**Google's terms are a contract question, not a legality question.** Automated collection sits outside what the consumer product invites you to do, and the practical consequence is technical rather than judicial: rate limits, blocks and challenges. This is the real reason most teams stop hand rolling a scraper. It is not that it cannot be built. It is that keeping it alive is a permanent maintenance job that nobody budgeted.
**There is an official route, and it answers a different need.** The Places API is the sanctioned way to read this data programmatically. It is built to look up a place you already identified, so it is excellent for verifying and enriching a record and poor at handing you every business in a category across a territory, which is exactly what list building requires. Its pricing is per request and its terms restrict what you may store and for how long.
| Route | Best at | Main constraint |
| --- | --- | --- |
| Official Places API | Verifying or enriching a place you already have | Storage and retention limits, per request cost, not built for bulk discovery |
| Your own scraper | Full control over fields and cadence | Permanent maintenance against blocks and layout changes |
| A managed extraction service | Coverage across a territory without infrastructure | You inherit someone else's field mapping and refresh rate |
Whichever route you take, two habits keep you out of trouble: collect only the fields you have a concrete use for, and honour a removal request quickly when one arrives. Neither costs anything, and both are what a reasonable operator does.
## The result cap that silently truncates your list
Here is the failure that ruins more local lists than any other. You search a category across a whole city, you get a few hundred rows back, and you conclude that this is the market. It is not. Maps does not return everything that matches. It returns what it considers most relevant for the area you asked about, and in practice a single search tops out on the order of 100 to 120 listings.
The figure is not published by Google, so treat it as an observed ceiling rather than a documented limit: run the same category against a city and against its postal codes, and compare the counts. Every serious guide on the subject reports a ceiling in that band, and so does the arithmetic of any grid you build yourself.
The cap is silent. Nothing in the export says truncated. You get a clean file, it looks complete, and it is missing most of the long tail, which in local prospecting is exactly where the businesses that nobody else has called are sitting.
The fix is geographic segmentation. Instead of one query for a city, you run many queries against smaller areas: postal codes, districts, or a grid of coordinates. Each subdivision gets its own allowance, so the total you can reach grows with the number of cells rather than being fixed at the city level.
Two consequences follow, and both are worth planning for before you start. First, your query count multiplies, so the cost model is driven by cells and not by cities. Second, segmentation manufactures duplicates by design, because a business near a boundary shows up in more than one cell. That is not a bug in the method. It is the price of completeness, and it is why the next section exists.
## Scrape Google business listings without building a duplicate pile
Almost every guide on this topic stops at the export. That is the point where the actual work starts, because a segmented pull is duplicated by construction and the obvious deduplication key is the wrong one.
**Do not deduplicate on business name.** Local naming is chaotic. The same restaurant appears as its brand, as its brand plus the district, and as its brand with a legal suffix. Meanwhile two genuinely different businesses in the same city share a generic name like Pharmacie du Centre. Name matching merges records it should keep and keeps records it should merge, in the same pass.
**Deduplicate on the place identifier when you have it.** It is the machine generated key, it is stable, and two rows carrying it are the same listing. This resolves the boundary overlap from grid segmentation instantly and without judgement.
**Fall back to normalised address plus phone.** When the identifier is absent, this pair is the most reliable composite key available. Normalise before comparing: strip accents, collapse whitespace, lowercase everything, reduce street type words to a single form, and store phone numbers in international format with no spaces or separators. Comparing raw strings will fail on formatting alone and leave you convinced you have twice the market you actually have.
### The three pass cascade
1. **Pass 1.** Match on the place identifier. Exact, no judgement, resolves the grid overlap.
2. **Pass 2.** Match on normalised address plus normalised phone, for the rows with no identifier.
3. **Pass 3.** Send whatever is left to a manual review queue rather than guessing.
Run these in order and stop at the first hit. The cascade is enough for local data, and the residue is usually under 2% of rows. If you are curious about how far normalisation has to go before two records are safely comparable, our guide on [which field comes from which input](https://derrick-app.com/business-data/company-enrichment) works through the same problem on company records.
## Chains, franchises and the multi location trap
Deduplication has an evil twin, and it catches people who did the first part correctly. Once your keys work, you will start collapsing rows that are genuinely distinct.
A franchise network is many businesses. Each outlet has its own owner, its own decision maker, its own budget and often its own supplier contracts. Collapsing forty outlets into one row because they share a brand name destroys the list. Conversely, a single company with a head office and two showrooms is one account with three addresses, and treating it as three prospects means three reps calling the same person.
The distinction is not visible in the listing data, which is precisely why it gets missed. What separates the two cases is the legal entity behind the address, and that lives in a business register rather than on a map. In France the registration number attached to each establishment settles it directly, since the structure encodes the parent company and the specific site. Our guide on [what the SIRET number breaks in a database](https://derrick-app.com/business-data/siret-number) covers the format and the traps.
A workable heuristic when you have no register at hand: identical brand name with distinct phone numbers and distinct owners usually means independent outlets, so keep them. Identical brand name sharing one phone number across addresses usually means one company with several sites, so merge them and keep the addresses as a child table. Flag the ambiguous cases rather than guessing, because the cost of a wrong merge is a lost account and the cost of a wrong split is an annoyed prospect.
## Rating and review count as a size proxy
Every tool in this space lists rating and review count among the extractable fields, and then nobody does anything with them. They are the most underused columns in the export, because they are read as a quality score when they are actually a size and maturity proxy.
The star rating tells you very little for prospecting. Local ratings cluster in a narrow band near the top of the scale, so the spread between a good business and a mediocre one is thin and noisy. The review count is the interesting number. It scales with foot traffic, with how long the business has been operating, and with whether anyone is actively managing the listing.
Read as a band rather than a value, it segments a raw local list into groups that deserve different treatment:
| Review count | What it usually means | How to treat the row |
| --- | --- | --- |
| Zero to five | New, very small, or nobody manages the listing | Low priority, and expect the contact fields to be stale |
| Six to fifty | Established and active, owner reachable directly | The sweet spot for most local offers |
| Fifty one to three hundred | Significant local presence, often several staff | Worth a named decision maker rather than a generic inbox |
| Three hundred plus | Chain, franchise, or a genuine local landmark | Check for a head office before treating it as one site |
Two derived columns are worth computing while you have the data open. Reviews divided by years since the first review approximates activity rather than accumulated age, which stops long dormant businesses from ranking as active ones. And the presence of owner responses to reviews is a strong indicator that somebody is actually reading the notifications on that listing, which correlates with the phone number being answered.
Once you have these bands, industry becomes the second axis and the segmentation gets genuinely useful. If your category labels from Maps are too coarse, our guide on [finding any business industry](https://derrick-app.com/business-data/find-industry) covers mapping loose labels onto a real classification.
## Which fields survive a CRM import
The temptation after a big pull is to push every column into the CRM. Resist it. Listing data decays at very different speeds, and a CRM full of fields nobody refreshes becomes a CRM nobody trusts.
Import the fields that are stable and that someone will actually use: name, address, phone, website, category, place identifier, and your derived review band. Keep coordinates if you do territory assignment. Leave opening hours, photo counts and price bands out of the CRM entirely, because they change often, nobody updates them, and their only real use is at list building time.
Two rules save a lot of pain later. Store the place identifier on the account record even though no salesperson will ever look at it, because it is what lets you re-pull the listing in six months and update the row instead of creating a second one. And stamp every imported row with the date of the pull, so that anybody reading the record knows whether they are looking at something from last week or from last year.
## Scrape Google business listings at scale: Sheets, MCP or API
There are three shapes this work takes, and picking the wrong one is where teams lose weeks. The question is not which surface is best. It is which one matches how the work arrives.
| Surface | Fits when | Who runs it |
| --- | --- | --- |
| Google Sheets sidebar | You have a territory to cover now and want the rows in front of you | Sales, RevOps, growth |
| MCP server | You want to ask for a list inside a chat and get structured data back | Anyone using an AI client |
| REST API | Listing pulls belong inside a product, a CRM sync or a scheduled job | Engineering |
Most teams should start in the spreadsheet, because it lets you check coverage and duplicate rates on real rows before anyone writes code. The grid segmentation from part two is trivial there: one row per cell, one call per row, and the results accumulate in place where you can see the overlap you are about to deduplicate.
The API and the MCP server are the right answer once the pull becomes recurring, for example a monthly refresh of a territory to catch new openings and closures. On Derrick both surfaces are included from the STANDARD plan at 20 euros per month upward, alongside PLUS at 47.5 euros, PRO at 175 euros and SCALE at 320 euros. Whichever surface you use, the underlying operation and its cost are identical, so you can prototype in a sheet and move to the API later without repricing the project.
Signals are the natural companion to a listing pull, since a static local list ages quietly. Company news gives you a reason to call this month rather than next quarter, and Derrick's [Google News Scraper](https://derrick-app.com/features/google-news-scraper) returns it at 1 credit per news item as a paid feature.
## What it costs to scrape Google business listings per usable row
The headline price of any listing pull is misleading, because you do not pay for rows you keep. You pay for rows returned, and then you throw a share of them away at the deduplication stage. The number that matters is cost per usable row, and it depends almost entirely on how aggressively you segmented.
Derrick's Google Maps Scraper bills 1 credit per place returned. A credit costs 0.00225 euros on MINI and 0.0016 euros on SCALE, which is the lowest per credit price. A pull of 5,000 places therefore costs between 8.00 euros on SCALE and 11.25 euros on MINI. If your grid overlap means 20% of those rows are duplicates, the real cost per usable row is that figure divided by 4,000, not 5,000, which makes every kept row 25% more expensive than the headline suggests.
That is the calculation people skip, and it is why the estimator below asks for your overlap rather than assuming it.
Interactive
### Estimate your cost per usable listing
Pick how many places you expect to pull, how much your grid overlaps, and your plan. You get the credit cost, the duplicate loss and the real price of a row you keep.
1. Places returned by the pull
2. Expected duplicate rate
3. Your plan
Answer the three questions to see your cost per usable row.
## Where the listing data stops and the contact work begins
A deduplicated, segmented listing table is a good asset and an incomplete one. It gives you a company, a category, a location, a size proxy and a switchboard number. What it does not give you is a person, and for most offers the phone number on a listing reaches a front desk rather than whoever decides.
That is a genuinely different problem with its own methods and its own hit rates, and it is where a lot of local prospecting quietly fails. Getting from a listing to an inbox depends entirely on what the business exposes: a website, a social page only, or nothing but the phone line you already have. Each of those cases has a distinct route and a distinct cost, and the case nobody plans for is the third one.
If your list is made of larger accounts rather than independent shops, the work shifts again toward named executives and account research. Our guides on [finding a company's CEO from its name or domain](https://derrick-app.com/business-data/find-ceo) and on [researching a company for sales](https://derrick-app.com/business-data/research-a-company-for-sales) pick up from there.
## A field checklist before you import
Run this before anything touches your CRM. It takes ten minutes and it catches the errors that are expensive to unwind later.
- **Did you segment?** If one search covered a whole city, your list is truncated and you do not know by how much. Re-run against smaller areas before you judge the market size.
- **Did you deduplicate on the right key?** Place identifier first, normalised address plus phone second, name never.
- **Did you check for chains?** Same brand and same phone across addresses means one account. Same brand and different phones means independent outlets.
- **Did you normalise phone numbers?** International format, no separators, before any comparison and before any dialler sees them.
- **Did you band the review counts?** It is the cheapest segmentation available and it is already in your export.
- **Did you drop the volatile fields?** Opening hours, photo counts and price bands belong in the working file, not in the CRM.
- **Did you stamp the pull date?** A local record with no date is a record nobody can trust in six months.
- **Do you know your cost per usable row?** Not per row returned. The two differ by whatever your duplicate rate turned out to be.
Listing data is the cheapest, broadest company data available for local markets, and it is genuinely good raw material. It just is not a prospect list on the day it lands. The gap between an export and a list a rep can work is deduplication, segmentation and one honest look at what each field is really worth.
## Use Derrick in Claude (MCP) or via API
Derrick isn't only a Google Sheets add-on. The same B2B data enrichment runs as an MCP server (use it directly inside Claude and other AI agents) and as a REST API:
- **Claude / AI agents (MCP)**: connect the Derrick MCP server, then enrich from chat. Setup: /mcp
- **REST API**: call the same enrichment endpoints from your own stack (PLUS plan and up). Docs: https://app1.derrick-app.com/api/v1/docs/
## FAQ
### What data do you get when you scrape Google business listings?
You get business name, category, full address, phone number, website URL when one exists, opening hours, price band, star rating, review count, photos, plus machine generated fields like the place identifier and the coordinates. The useful distinction is not the list of fields but their origin: the place identifier and coordinates come from Google and are stable, the contact details were declared by the owner and may be stale, and the rating and review count come from customers and describe visibility rather than the business itself.
### Why does a Google Maps search return only about a hundred results?
Maps returns what it considers most relevant for the area you searched rather than everything that matches, and a single search tops out on the order of 100 to 120 listings. Nothing in the export flags this, so a city wide search looks complete while missing most of the long tail. The fix is to split the area into postal codes, districts or a coordinate grid and run one search per cell, which multiplies both your coverage and your duplicate rate.
### Is it legal to scrape Google business listings?
The listing data itself is published for the public to see, and collecting business names, addresses, phone numbers and opening hours for business to business prospecting is ordinary commercial research. Two caveats matter. As soon as a named person is attached to a record, European data protection obligations apply, so you need a lawful basis and you must honour objections. And automated collection sits outside Google's consumer terms, which in practice shows up as rate limits and blocks rather than as a legal problem. The sanctioned programmatic route is the Places API, which is built to verify a place you already have rather than to discover every business in a territory.
### How do you deduplicate scraped business listings?
Use the place identifier as the primary key, because it is generated by Google, stable across pulls and unambiguous. When it is missing, fall back to normalised address plus phone number, with accents stripped, whitespace collapsed, street types reduced to one form and phone numbers stored in international format without separators. Never deduplicate on business name: local naming is inconsistent enough that name matching merges distinct businesses and splits identical ones in the same pass.
### Should you merge all the outlets of a chain into one record?
Only when they belong to one company. A franchise network is many businesses, each with its own owner, budget and decision maker, so collapsing them destroys the list. A single company with a head office and several showrooms is one account with several addresses. Listing data does not show the difference, so check the legal entity in a business register, or use the heuristic that a shared phone number across addresses usually means one company while distinct phone numbers usually mean independent outlets.
### Is the star rating useful for prospecting?
Barely. Local ratings cluster tightly in the high fours, so the spread carries little information. The review count is the field worth using, because it scales with foot traffic, with how long the business has been operating and with whether anyone actively manages the listing. Read as bands rather than as a value, it separates dormant listings from established owner run businesses and from chains that need a head office check.
### Which listing fields should you import into a CRM?
Import the stable, actionable ones: name, address, phone, website, category, the place identifier and a derived review band, plus coordinates if you assign territories. Leave opening hours, photo counts and price bands in the working file, because they change often and nobody refreshes them. Always store the pull date, so anyone reading the record later knows how old it is, and keep the place identifier so a future pull updates the row instead of creating a duplicate.
### What does it cost to scrape Google business listings?
Derrick's Google Maps Scraper is a paid feature that bills 1 credit per place returned. A credit costs 0.00225 euros on MINI and 0.0016 euros on SCALE, the lowest per credit price, so 5,000 places costs between 8.00 and 11.25 euros depending on plan. The figure to plan against is cost per usable row: you pay for every place returned including the duplicates your segmentation created, so a 20% duplicate rate raises the real cost per kept row by 25%.
## Related
- [The State of B2B Company Data 2026: Firmographic Decay, Coverage Gaps and What Stale Records Cost](https://derrick-app.com/business-data/b2b-company-data-report-2026)
- [Company Founding Year: How to Find It in 2026 (5 Ways, Tested)](https://derrick-app.com/business-data/find-founding-year)
- [How to Find Company Headquarters Country: Complete Guide.](https://derrick-app.com/business-data/find-headquarters)
- [Company Industry Lookup: How to Find Any Business Industry Instantly](https://derrick-app.com/business-data/find-industry)
- [Email & Social Extractor Playbook: 3 Sales Moves to Get on Your Prospect’s Radar Instantly](https://derrick-app.com/business-data/find-social-from-website)
- [How to Find Company Revenue (Public, Private, or Neither)](https://derrick-app.com/business-data/find-revenue)
- [How to Find a Company Name from a Domain](https://derrick-app.com/business-data/find-company-name)
- [How to Find a Company's CEO from a Company Name or Domain](https://derrick-app.com/business-data/find-ceo)
- [How to Find a Company's Description and Location from Its Website](https://derrick-app.com/business-data/find-description-from-website)
- [How to Research a Company for Sales Without Losing an Hour per Account](https://derrick-app.com/business-data/research-a-company-for-sales)
- [NAF code: how to find and use French activity codes](https://derrick-app.com/business-data/naf-code)
- [NAF Code List: Every Division and Sub-Class, With Labels](https://derrick-app.com/business-data/naf-code-list)
- [SIRET Number: How to Read, Validate and Use It as a Data Key](https://derrick-app.com/business-data/siret-number)
- [Company enrichment: which field comes from which input, and how to get it](https://derrick-app.com/business-data/company-enrichment)