Start a query in Google Maps and it proposes ten completions - a mix of places, brands and phrasings people search for. This service turns that dropdown into a table: one row per suggestion, with the rank it held, for as many seed queries as you submit.
This is the property that decides how you use the export, so it goes first rather than in a footnote.
We ran the same seed word repeatedly. It returned a different top ten almost every time - one seed came back with six different lists across six runs, and only four of its ten suggestions were common to the first two. Another shared just two of ten. A third was steadier, sharing seven. So Maps autocomplete is not a fixed list you can look up; it is a live surface that moves between one request and the next.
What follows from that is simple and worth stating plainly. One run is an anecdote. If a suggestion matters to you, sample it repeatedly and count how often it appears, rather than reading a single pull as the answer. Conversely, a suggestion that turns up in every sample is telling you something genuinely stable. The volatility is not noise to be engineered away - treated correctly, frequency across runs is the actual measurement.
The shape of the file is, by contrast, completely predictable. Every seed returns exactly ten suggestions, so rows equals seeds times ten, and position runs 1 to 10 before restarting for the next query - it is the rank inside one dropdown, not a row number. Group by query before you sort by anything.
No map to pan, no URL to build. You submit words, optionally with a location bias.
1000 queries per request.coordinates from a Maps URL to bias towards a location.Ten rows come back per seed, so a hundred seeds is a thousand rows. Billing follows rows.
The whole export. Three columns describe the suggestion; the fourth records what you asked for.
query group.@lat,lng,zoom fragment from a Google Maps URL. It is an input, identical on every row of a run, not a position for the suggested place. Empty when none was supplied.Do not read coordinates as an output. It is the parameter you sent, repeated - across our 100 rows it held only two distinct values, one of them empty, and it never varied within a run. In particular it is not the location of the suggested place: a suggestion here is a text completion, not a listing, and this service returns no place id, address or rating. When you have chosen the phrasings worth pursuing, the Maps scraper is what turns them into actual places.
Eight runs, six of them populated, ten query-blocks, three distinct seeds. Small, but the behaviour was consistent enough to design around - and one finding should change how you use it.
One seed was run six times and produced six different lists; only four of its ten suggestions were shared between the first two runs. Another seed shared two of ten. This is the headline property of Maps autocomplete and it is measured, not inferred. Build for it: sample a seed several times and rank suggestions by how often they appear, rather than trusting any single pull.
All ten query-blocks in our data returned exactly ten suggestions - no short blocks, no long ones. So while the contents move, the size does not: rows equals seeds times ten, known before you spend anything. The contrast is the useful part. You can budget a run precisely while still needing to repeat it to trust the contents.
The coordinates column repeats the location bias you sent - the @lat,lng,zoom fragment from a Maps URL. Across our 100 rows it held two values: empty, and one non-empty value that is the exact default the published reference documents for that parameter. So our runs demonstrate the column exists and echoes the input; they do not demonstrate what a deliberately chosen coordinate does to the results. If location matters to your work, set it yourself and compare.
This service returns text completions - there is no place id, address, rating or coordinate pair for the thing being suggested. That is a scope boundary, not a gap: autocomplete is where you learn how people phrase a search, and the Maps scraper is where a phrase becomes a list of businesses. Two of our eight runs came back empty, so build a retry into any scheduled job rather than assuming every request always returns.
Where the Maps dropdown is more useful as a spreadsheet than as a dropdown.
Nobody searches the way a category taxonomy says they should. Seed the service with your category and read what Maps proposes - the shorthand, the misspellings, the near-synonyms that carry real intent. Sample each seed a few times and keep the completions that recur; those are the phrasings worth optimising a listing for.
Moving into an unfamiliar vertical or an unfamiliar country means guessing at words. This is a cheap way to stop guessing: submit the obvious seeds, collect what comes back, and you have the surrounding vocabulary in minutes. Combine it with the language and region parameters and you can do the same exercise per market.
The natural next step is to stop reading suggestions and start using them. Take the completions that survive repeated sampling, hand them to the Maps scraper as search terms, and you get businesses found through the language customers actually use rather than the language you assumed.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.
For every new account, one time. No credit card. All scrapers unlocked. At ten rows per seed that is fifty seed queries - or, better, ten seeds sampled five times each, which is how you should be using this one anyway.
Roughly $2 per 1,000 suggestions - about $0.02 per seed query, since each returns ten rows. Because the list moves between runs, budget for repeats: sampling one seed five times costs ten cents and is worth far more than five different seeds pulled once.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams sampling large seed lists across languages, regions and coordinates on a repeating schedule. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.Autocomplete tells you how people search. These two turn that into places and into rankings.
The obvious next step: hand the surviving completions over as search terms and get back the actual businesses, with addresses, phones and websites.
The same idea on web search, where the dropdown is markedly steadier between runs and always opens with your own query.
Short answer: yes. A suggestion is a public feature of a public search box, shown to everyone who starts typing.
Maps autocomplete is public. Anyone can see it without an account, on any device, simply by typing. Collecting publicly visible information for research is long-settled practice, and as long as the data is publicly available and the process does not disrupt the service, there are no federal laws against it.
The subject matter is about as harmless as data gets. A suggestion is an aggregate - a phrase common enough across many people's searching that Google offers it to everyone. It is not one person's search history, and nothing in these four columns identifies anybody: there is no user, no session and no author. The one column that is not about the suggestion is the coordinate you yourself supplied.
Google's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
query, suggestion, position and coordinates. One row per suggestion. That header was identical on all eight of our runs, including the two that came back empty.position is the rank inside one query's dropdown, so it runs 1 to 10 and then restarts for the next seed. A file covering fifty seeds contains the number 1 fifty times. Always group by query first.@lat,lng,zoom fragment from a Google Maps URL. It is an input, not an output: it does not give the position of the suggested place, and it is identical on every row of a run. Across our 100 rows it held only two distinct values, one of them empty.query as an array and batches up to 1000 queries per request, and documents language (default en) and region parameters alongside coordinates. Record whatever you set, because none of the output columns except coordinates reports it back.Hand over a list of seed words and get the Maps dropdown back as rows - the suggestion and the rank it held, ten per seed. Your first 500 rows are free.
Type the first few letters of anything into Google Maps and it proposes ten completions. They are drawn from what people actually search for on Maps, which makes them a direct read on how customers ask for a category - the shorthand, the near-synonyms, the local phrasings that no internal taxonomy contains. This service turns that dropdown into a table: one row per suggestion, four columns, exported as CSV, JSON or Excel, for as many seed queries as you want to submit. The published reference accepts the query parameter as an array and batches up to a thousand seeds in a single request.
The export has two properties that pull in opposite directions, and understanding both is the whole job. Its size is perfectly predictable: every seed returns exactly ten suggestions - that held on every block we measured, with no short blocks and no long ones - so rows equals seeds times ten, known before you spend anything. Its contents are not predictable at all. We ran one seed six times and received six different lists, with only four of its ten suggestions common to the first two runs; another seed shared just two of ten between runs. Maps autocomplete is a live surface, not a lookup table, and one pull is an anecdote rather than an answer.
That instability is workable once you stop fighting it. Sample each seed several times and rank the completions by how often they recur: a phrase that appears in every sample is genuinely stable demand phrasing, and a phrase that appears once is not worth acting on. Frequency across runs is the real measurement here, which also means the cost model is different from most scrapers - sampling ten seeds five times each is a better use of the same spend than pulling fifty seeds once. Two of our runs came back empty, so a scheduled job should retry rather than assume every request returns.
Two smaller things to get right. The position column is a rank within one seed's dropdown, not a row number: it runs 1 to 10 and restarts for the next query, so a fifty-seed file contains the number 1 fifty times and grouping by query has to precede any sorting. And the coordinates column is an input echoed back - the @lat,lng,zoom fragment from a Maps URL, identical on every row of a run - not the location of the suggested place. Across our hundred rows it carried only two distinct values, one of them empty and the other the exact default the reference documents, so our data shows the column exists and repeats what you sent, and shows nothing about how a deliberately chosen coordinate changes results. Note too that a suggestion is a phrase and not a listing: there is no place id, address or rating here. Collect the phrasings, then hand them to the Maps scraper. Start free: your first 500 rows cost nothing and need no credit card.