How to Turn Brand Store Locators into a Clean Location List
A brand's store locator can reveal its retail footprint, but the list may include independent stockists as well as stores the brand operates. That distinction matters when you turn dots on a map into a business report.
The Brand Store Locator Scraper starts from brand homepages, discovers supported locator pages, and normalizes store addresses and coordinates. I maintain the Actor. This guide turns one brand's results into a checked location list that can later support a map.

Begin with one homepage
You need an Apify account and the brand's public homepage. The Actor supports adapters for Storemapper, Locally.com, and Stockist, plus static lists and some JavaScript locators. Custom implementations can still fail discovery or yield partial coverage.
In Apify, open the Actor's Input in JSON view:
{
"startUrls": [{"url": "https://www.untuckit.com"}],
"maxStoresPerBrand": 25,
"proxyConfiguration": {"useApifyProxy": false}
}
startUrls is an array of objects containing url, not a plain list of strings. The Actor follows the homepage to find the locator, so you do not have to identify its underlying service first.
maxStoresPerBrand caps each brand separately. It defaults to 100 in the deployed input schema; zero removes that cap. Start with 25 to check the location structure, then expand deliberately. Three brands at that limit can produce up to 75 records.
Click Start, wait for the run to finish, and inspect the dataset's brandUrl, sourceUrl, and locatorService. Those fields tell you which locator supplied the row, which is useful if the brand has separate stores, stockists, and service-center pages.
Recognize a retailer location
This shortened README example illustrates a stockist record:
{
"brandName": "darntough.com",
"storeName": "REI - Soho Flagship",
"address": "109 East Houston St",
"city": "New York",
"state": "NY",
"country": "US",
"postalCode": "10002",
"latitude": 40.7237,
"longitude": -73.9957,
"locatorService": "locally",
"sourceUrl": "https://darntough.com/pages/find-a-store"
}
It associates a retailer with a brand's locator. It does not say the brand owns that retailer, that every product is stocked there, or that an item is currently available. Preserve the original relationship instead of renaming every record a “brand-owned store.”

Earlier locator output illustrates the normalized address and source fields.
Clean the list before mapping
Export CSV with the address fields, storeName, brandUrl, sourceUrl, latitude, longitude, website, and extractedAt. Keep postalCode as text so leading zeros survive spreadsheet import.
Create a normalized matching key using country, postal code, street address, and store name. Trim spaces and standardize obvious abbreviations, but retain the raw fields. Coordinates help review candidate duplicates; they should not be the sole key because multiple stores in a mall can share a map point.
Within one brand, merge only rows that clearly represent the same store. Across brands, preserve both associations. If the same REI address appears for two brands, that is one physical location with two brand relationships, not an error to delete.
Separate rows with missing coordinates into a review tab. For mappable rows, check that latitude is between -90 and 90 and longitude between -180 and 180, then spot-check a few pins against the address. Swapped coordinates or a headquarters pin can produce a plausible-looking but wrong map.
Build a city or country count from the checked rows and report how many records lack enough address information to classify. With the 25-store sample, call it a sample count. It is not evidence that the brand has only 25 locations.
Expand coverage without overstating it
Pricing as of September 6, 2026: $0.006 per returned store, plus an Actor-start event of $0.00005 per GB of allocated memory, minimum one event. Twenty-five stores cost $0.15 in result fees. Check current pricing before removing the per-brand cap.
If discovery returns nothing, open the brand's locator manually and check whether it is public, requires a location search, or routes to another domain. The Actor has browser fallbacks, but they do not guarantee exhaustive coverage of every radius-based or custom locator. A blocked request and an unsupported locator require different fixes; use the run log to distinguish them before changing proxy settings.
For repeated exports, keep extractedAt and compare the normalized location key. Mark missing rows for source verification before describing them as closures. A changed locator or search boundary can remove an observation without a store closing.
The 2GIS business-listing guide is a related workflow when your starting point is a geographic directory rather than a brand.
The Node.js example shows how to run this Actor from code and retrieve its dataset.
Frequently asked questions
How should I deduplicate stores shared by several brands?
Keep a physical-location key and a separate brand-to-location relationship. Merge duplicate rows within a brand only after checking the name and address; do not delete a second brand association.
Will a higher store limit guarantee the complete network?
No. The limit controls how many discovered stores can be returned. Custom locators, geographic search behavior, and unavailable data can still restrict coverage.
