Naver serves at most 300 results per query. That number is not in any documentation, it is not affected by your input, and it is the single constraint that decides how a Korean local dataset has to be built.
The ceiling
Three hundred, per query, regardless of the match count Naver reports. Setting maxResults to 1,000 on a single query does nothing useful: the Actor cannot request a 301st result that Naver will not serve.
The Actor says so in the run log rather than letting a 300-row dataset imply that a district has exactly 300 businesses.
Why the match count cannot size the gap
On a normal capped source you would compute what you are missing: reported minus served. Here you cannot, because the reported count includes the padding. 638 reported against 162 in-area does not mean 476 dentists are missing; it means the count is measuring something else entirely.
Partitioning by region
The primary axis. Korean administrative divisions nest — 시/도, then 구/군, then 동 — so a query that overflows at city level can be split into districts, and a district that overflows into neighbourhoods.
{
"queries": ["치과"],
"regions": [
"서울 강남구", "서울 서초구", "서울 송파구",
"서울 마포구", "서울 용산구", "서울 종로구"
],
"maxResults": 1500
}Each region gets its own query and its own ceiling, so six districts is up to 1,800 served results rather than 300. Deduplicate on place_id afterwards, because adjacent districts share padding.
Partitioning by term
The second axis, and often the better one. Korean business vocabulary is finer-grained than English translations suggest: a single English category maps to several Korean terms that Naver indexes separately.
So instead of one broad term that overflows, use two or three specific ones. This also improves precision — a narrow term returns fewer irrelevant businesses before any filtering.
The cost of partitioning
Effectively nothing. Billing is per delivered row, so six district queries returning 1,200 unique businesses cost the same as 1,200 businesses from one impossible query. What you pay extra is a handful of requests, and what you get is a dataset that is not silently truncated.
Verifying that a sweep is complete
Two checks, both from the run log:
- Did any query return exactly 300 in-area results? If so it was truncated. Split that region or narrow the term.
- What was the padding ratio? A very high ratio means the district genuinely has little supply, so the low row count is the answer rather than a failure.
Between those two you can tell the difference between “I covered this district” and “I hit a ceiling” — which is the distinction that most scraped datasets cannot make about themselves.
