Naver Place Business & Reviews Scraper (Korea)

What it does

Korean local business data from Naver Place — the directory Koreans actually use, where Google Maps coverage is thin — with businesses, visitor reviews, Naver's own reputation aggregates, menus and photos. Naver pads its search results with businesses from outside the area you asked for, silently and with no marker; this Actor filters them out and reports how many it dropped.

{
  "place_id": "1234567890",
  "name": "강남예치과",
  "category": "Dentist",
  "category_ko": "치과",
  "region": "서울 강남구",
  "phone": "0507-1234-5678",
  "phone_is_virtual": true,
  "road_address": "서울 강남구 테헤란로 123",
  "full_address": "서울 강남구 역삼동 678-9",
  "latitude": 37.5006,
  "longitude": 127.0364,
  "hours_status": "영업 중",
  "visitor_review_count": 214,
  "blog_review_count": 88,
  "reputation": {
    "average_rating": null,
    "star_distribution": null,
    "reviewer_count": 196,
    "image_review_count": 41,
    "themes": [{ "name": "친절해요", "count": 63 }]
  },
  "place_url": "https://map.naver.com/p/entry/place/1234567890",
  "scraped_at": "2026-08-19T09:12:00.000Z",
  "from_cache": false,
  "fetched_at": null,
  "data_age_hours": null
}

Why this one

Use cases

• Build a region-accurate directory of Korean businesses in a vertical, without the neighbouring-area padding.
• Analyse Korean visitor reviews — text, star rating, visit date, receipt-verified flag — without collecting reviewer identities.
• Read Naver's own reputation aggregates: average rating, the ten-band star distribution and its theme analysis with counts.
• Collect menus with prices in KRW for restaurant and café benchmarking.
• Compare a vertical across districts by adding regions, which is also how you get past the 300-per-query ceiling.
• Reach Korean local data where Google Maps coverage is thin, which is most of it.

Input

Every field has a default, and the defaults are deliberately small so a first run is cheap enough to inspect before you commit to a sweep. This table mirrors the Actor's own input schema field for field.

Output and fill rates

A field being in the schema is not the same as it having a value. The percentages below were counted on real runs; the sample sizes are in Measurements. Anything not listed here is not promised.

Every key is always present. A field that exists but is empty comes back as explicit null, so a parser never has to guess.

Datasets

Different record types go to different datasets, so the main table never carries columns that are blank on most rows.

Pricing

Pay per delivered result. Charges are applied as each row is produced rather than in a lump at the end, so an aborted run bills only for what it actually gave you.

Measurements

Each figure is shown with the method that produced it. A benchmark without a method is a marketing claim wearing a number's clothes.

What it will not do

Stated plainly so you can judge fit before spending anything.

• Naver serves at most 300 results per query. Wide coverage needs more regions or narrower terms, and the run log states this.
• Reviewer identities are never returned, under any setting.
• Star ratings do not exist for every vertical: clinics, academies and pharmacies have none, and the field is `null`.
• One entity type per run — businesses, reviews, menu items or photos — so each dataset has one shape.
• `businessType` does not filter search results. Naver ignores it; the search term is what selects the category.
• Photo author information is never returned with photos.
• Shared caching is designed but not switched on, so `from_cache` is always false and `fetched_at` is null today.

Privacy

• Reviewer nicknames, account ids and review-history links are never returned. A build-time test enforces it at any depth of the row.
• Photo author information is never returned.
• Business contact details are published by the businesses themselves, and `phone_is_virtual` distinguishes Naver's relay number from the real line.
• Data policy and removal requests: naver.actorstack.dev, or privacy@actorstack.dev

See also the data removal process.

Guides for this Actor

• Scrape Naver PlaceGoogle Maps coverage in Korea is thin; Naver Place is where the data is. A walkthrough of querying it, and of the padding you have to remove before the results mean anything.
• Naver Place APINaver publishes developer APIs, but not the one people are looking for. What exists, what it covers, and why the public pages are the practical route.
• The padding findingNaver silently pads its search results with businesses from neighbouring areas. Measured across ten queries — and it is the difference between a local dataset and a regional blur.
• The 300 ceilingEvery Naver query stops at 300 results regardless of what it claims to have matched. Coverage is a function of how you partition the map, not of how high you set a limit.
• Naver Place fieldsMeasured on 3,295 businesses across 8 verticals and 8 regions — including which fields simply do not exist for clinics, academies and pharmacies.
• Virtual phone numbersNaver puts a relay number in front of many businesses' real lines. Between 37% and 87% of them, depending on vertical, publish only that — and a dataset that does not flag it is a call list into a redirect.
• Reviews without identitiesEvery Naver review carries a nickname, a stable account id and a link to the reviewer's entire history. None of it is returned, and a test fails the build if it ever is.
• Naver vs Google MapsIn most countries this is not a question. In Korea it is the whole question, because the platform Koreans use is not the one most tooling targets.
• Reputation aggregatesAverage rating, a ten-band star distribution, reviewer counts and a theme analysis with counts — all computed by Naver, and all cheaper than deriving them from raw reviews.
• Korean search termsNaver's search is Korean-first. The choice of term decides coverage more than any other input, and the region list decides whether the results are where you think they are.