Two inputs decide whether a Naver run produces a usable dataset: the term and the region. Get the term wrong and you undercount; get the region wrong and you cannot tell where anything is.
Why Korean terms return more
Naver's index is Korean-first, and Korean businesses register their category in Korean. So 치과 matches how dentists describe themselves and dentist matches whatever happens to carry the English word.
The gap is not marginal. Searching in English is the most common way to build a Korean dataset that looks complete and covers a fraction of the market — and nothing in the response warns you.
Choosing the term
Korean business vocabulary is finer-grained than English translations suggest. One English category frequently maps to several Korean terms that Naver indexes separately, which is useful twice over: better coverage, and a way past the 300-result ceiling.
Practical approach: start with the broad category term, look at what the businesses call themselves in the category field of the results, and use those as your next queries. The data tells you its own vocabulary.
The administrative hierarchy
| Level | Example | Notes |
|---|---|---|
| 시 / 도 | 서울, 부산 | First-level. 17 of them; an empty region list sweeps all. |
| 구 / 군 | 서울 강남구 | District. Usually the right level for a city sweep. |
| 동 | 역삼동 | Neighbourhood. Precise, and where the padding ratio gets extreme. |
Write them space-separated from the widest level inward: 서울 강남구. That is the form Naver uses and the form the Actor filters against.
Which level to query
District (구) is the usual answer. City level overflows the 300-result ceiling in any dense category; neighbourhood level (동) is precise but returns mostly padding in small areas — 2 of 52 results in one measured case.
The input that does not filter
businessType looks like a category filter and is not: Naver ignores it for search. It selects which vertical's detail pages get read. The search term chooses the category.
This is the same class of trap as the thirteen Workana parameters that accept a value and ignore it. The difference is that here the input is kept because it does something real — just not the thing its name suggests — so the description says so.
A concrete recipe
{
"queries": ["치과", "치과의원", "교정치과"],
"regions": [
"서울 강남구", "서울 서초구", "서울 송파구", "서울 강동구",
"서울 마포구", "서울 영등포구", "서울 용산구", "서울 종로구"
],
"entityType": "businesses",
"maxResults": 3000,
"includeReputation": true
}Three terms across eight districts is 24 queries, each with its own 300-result ceiling and its own padding filter. Deduplicate on place_id afterwards, because a business in a border district legitimately appears in more than one result set.
