How to scrape Naver Place, the directory Koreans actually use

Korea is one of the few markets where the local data does not live on Google. It lives on Naver, and Naver Place answers plain HTTP requests — no login, no browser, no proxy. The work is not in getting the data; it is in making sure the data is where you think it is.

Why Naver and not Google Maps

Koreans search, review and navigate on Naver. A Korean dentist often has hundreds of Naver reviews and a handful on Google, and the menus with prices in KRW exist on Naver and not elsewhere. A Korea dataset built on Google Maps is not wrong so much as thin — the comparison in full.

Step 1 — query in Korean

This single choice moves coverage more than any other input. 치과 returns far more dentists than dentist, because businesses register their category in Korean and Naver's index is Korean-first. English terms work and undercount.

Choosing terms and regions goes into which administrative level to query and why it changes the padding ratio.

Step 2 — name the regions

Regions are space-separated administrative names, widest level first: 서울 강남구, 부산 해운대구. Leaving the list empty sweeps all 17 first-level regions.

Naming the region does two jobs. It partitions the search, which matters because of the 300-result ceiling — and it gives the Actor something to check each result's address against, which is what removes the out-of-area padding.

Step 3 — pick one entity type

entityType takes businesses, reviews, menus or photos, one per run, so each dataset has a single clean shape. Reviews cost more than businesses to collect, because each business needs its own paginated sweep — start small and see the shape before running wide.

Step 4 — run it and read the log

{
  "queries": ["치과", "카페"],
  "regions": ["서울 강남구", "서울 마포구"],
  "entityType": "businesses",
  "maxResults": 200,
  "includeReputation": true
}

The run log is not decoration here. It reports, per region, something like:

"역삼동": 162 of 300 results are actually located in this area.
138 were padding from neighbouring areas and were dropped.
Naver reports 638 matches for this query, but that count includes
out-of-area padding and is not an inventory figure.

The padding you have to remove

Naver fills its result pages with businesses from neighbouring areas — silently, with HTTP 200 and no marker in the response. Measured on 역삼동 치과: 638 matches reported, 300 served, 162 actually in 역삼동.

Pass that through and your “dentists in 역삼동” dataset is 46% wrong on geography while looking complete. The Actor filters on the address and reports the dropped count. The full measurement across ten queries.

Reading the output

A business row carries name, translated category with the Korean original, phone with phone_is_virtual, road and jibun addresses, coordinates, opening status, review counts and — if enabled — Naver's own reputation aggregates.

Two fields need reading before you trust the others. phone_is_virtual says whether you got Naver's 0507 relay rather than the real line. And rating is null for verticals where Naver computes none — clinics, academies, pharmacies — rather than a zero that would read as a bad score.

What a run costs

$0.0014 per business, $0.0008 per reputation block, $0.00045 per review, $0.0002 per menu item or photo. Two hundred businesses with reputation is about 44 cents. Failed requests go to the key-value store under ERRORS and are never charged.

Four mistakes that waste a run

1. Searching in English. You get a fraction of the businesses and no warning.
2. Leaving regions empty for a city-level job. Without a named region there is nothing to filter padding against.
3. Setting `maxResults` above 300 for one query. Naver stops at 300; the number above it does nothing.
4. Treating a null rating as zero. For clinics and pharmacies Naver computes no score at all.