Malls, airports, office towers, hospitals and food halls each hold dozens of businesses that a normal area search barely surfaces. Google keeps them in the venue's directory. This pulls places from those directory results, so a single address becomes the list of everyone trading at it.
Same entry point as the rest of the Maps toolkit - you identify the place you're interested in, and the job returns what's associated with it.
The tool shows the input formats and parameters it accepts when you open it, and the estimator prices the run before it starts.
Google already models the idea of a business sitting inside another one. You can see it in the data our Maps Scraper returns.
Every place row from the Google Maps Scraper carries two containment fields: located_in, described in our data dictionary as "name of the place if the business is inside another business", and located_google_id, "google id of the place where the business is located". Those exist because a great many businesses are not standalone addresses - they're units within a larger venue.
The catch is direction. Those fields tell you, for a business you already found, what it sits inside. They don't help you go the other way. And a category-and-city search tends to under-surface nested businesses, because what ranks in an area search is not the same as what a venue's directory lists.
This tool inverts the relationship: start from the venue, get the places its directory holds. If located_in is the field you keep wishing you could query backwards, this is that query.
A single office tower or mall can hold more prospects than a whole suburban high street - all sharing one postcode, which is exactly why proximity searches skate past them.
Knowing which brands actually trade in a venue is the difference between an informed view of a location and an assumption based on the anchor tenant's name on the sign.
Output lands in the same shape as the rest of the Maps toolkit, so directory rows sit alongside the places you already pulled rather than in a separate silo.
A run returns the places a venue's Maps directory lists, as rows - the occupants rather than the container.
8 columns per occupant - every column above on every plan, including the free tier.
Worth noticing what that combination gives you: category plus rating
and reviews on every occupant means a single run tells you not just who is in a
building but what mix of trades it holds and how each one is regarded - a tenant profile rather
than a list of names. And because place_id comes with each row, any occupant worth a
closer look can be passed straight to another service without a matching step.
Two honest caveats. Not every venue has a directory on Maps - smaller buildings often don't, and a run against one has little to return. And a directory reflects what Google currently knows: tenants arrive and leave, so treat any export as a dated snapshot rather than a lease schedule.
A few examples of how teams use directory data.
For anyone selling to businesses in person, a multi-tenant tower is the most efficient territory there is - dozens of prospects behind one door. A directory pull turns that building into a call list instead of a guess about who's upstairs.
Before valuing a retail scheme or pitching a landlord, knowing who currently trades there - and in what categories - is basic diligence. Collecting it across several schemes makes them comparable rather than anecdotal.
Rivals with concessions inside malls, airports and stations are the ones most often missing from a competitor list built by area search, precisely because they don't hold a street address of their own.
No subscription, no minimum, no per-venue licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked, full feature set - enough to try a venue or two and see what a directory actually returns.
Roughly $2 per 1,000 places. The pre-flight estimator shows the count and credit cost before a run starts - no surprises, no compute units to translate.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for recurring coverage across many schemes or buildings. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Directory rows are most useful once you've found the venues and can reach the occupants.
Where the venues come from - search a category and city to find the malls, towers and terminals worth opening up. It's also the source of located_in and located_google_id.
A tenant list you can't contact isn't a pipeline. Point this at the websites in your directory export to pull emails, phones and social handles.
Short answer: yes - this is business listing data, published for customers to find.
A venue directory is public: Google shows anyone the businesses inside a mall, terminal or tower, signed in or not, because the entire purpose of the listing is to help customers locate them. Collecting publicly visible business information for research and prospecting is long-established practice, and as long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
This one is also low on personal data. Directory entries describe businesses - names, categories, locations within a venue - rather than individuals. Nothing here identifies a person beyond whatever a business chose to publish about itself.
The usual platform caveat still applies: Google's terms restrict automated access, so this is a terms question as much as a legal one. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
located_in and located_google_id. This starts from the venue instead and returns the places its directory lists. Same containment relationship, read from the opposite end.500 one-time free rows on every new account - no expiry. After that it's $0.002 per row, pay-as-you-go - no card on file until you say so.
Livescraper's Google Maps Directory Places collects the businesses a venue's Maps directory lists. You add the venues you want covered, pick an output format, and download the occupants as CSV, JSON or Excel - turning one address into the set of businesses trading at it.
Google already models this containment relationship, and you can see it in the data our Google Maps Scraper returns: every place row carries located_in, described in our data dictionary as the name of the place if the business is inside another business, and located_google_id, the Google id of the place where the business is located. Those fields answer the question one way round - for a business you already found, what contains it. This tool answers it the other way: given the venue, what's inside.
That matters because category-and-city searches under-surface nested businesses. A mall unit, an airport concession, an office suite or a hospital clinic shares the venue's address rather than holding its own, so proximity-driven results tend to skate past them even though a single tower can hold more prospects than a suburban high street.
Field sales teams turn a multi-tenant building into a call list. Commercial property teams read a scheme's tenant mix before valuing it or pitching a landlord. Competitive teams find in-venue rivals that never appear in a competitor list built from area search. Two caveats worth carrying: not every building has a directory on Maps, and a directory reflects what Google currently knows rather than a lease schedule - so treat exports as dated snapshots. Start free: your first 500 rows cost nothing and need no credit card.