Google Maps scraping works everywhere — except Korea. Here's the Naver Place equivalent.

If you've ever built a lead-gen pipeline, a local-SEO tool, or any "pull every business in this city" scraper, you've probably leaned on Google Maps / the Places API. It works in almost every country on earth.

Then a client asks for Korea, and the whole stack quietly falls apart.

I'm a Korean developer, and I want to explain why Korea is a black hole for every Western location tool — and show you the ~10-line equivalent that actually works here.

Why Google Maps is broken in Korea (it's not your code)

This trips up almost everyone the first time. You run your normal Google Places pipeline against Seoul and get back thin, wrong, or empty data. You assume you misconfigured something. You didn't.

South Korea has a decades-old law that bars exporting high-precision national map data to servers outside the country. Google has never been allowed to host Korea's detailed map data abroad, so Google Maps in Korea is permanently crippled: no real driving directions, sparse POI coverage, missing hours, missing phone numbers, missing reviews. Locals know this and simply don't use it.

What they use instead is Naver — Korea's dominant search engine — and specifically Naver Place (네이버 플레이스), which is the real "Google Maps of Korea." Every café, clinic, restaurant, gym, and repair shop in the country lives there with hours, phone, rating, and reviews. Kakao Map is the #2.

So the practical reality for anyone outside Korea:

• Google Maps / Places API → the tool the rest of your product uses → useless in Korea.
• Naver Place → where the actual data is → Korean-only UI, no public API, aggressive anti-bot.

That gap is why "Korea coverage" is a line item Western data vendors quietly skip.

What actually stops you

It's not just "translate the UI." Three things stack up:

1. No clean public API. Naver's map endpoints are internal, undocumented, and change without notice.
2. Korean-native everything. Query semantics, address formats (도로명주소 vs 지번), category taxonomy — all Korean-first. You can't guess the right query as a non-Korean speaker.
3. Datacenter IPs get gated fast. Hit it from an AWS range and you'll eat rate-limits and CAPTCHAs within a few hundred requests, especially once you paginate into per-place reviews. You need Korean residential IPs and sane session handling.

None of these are hard individually. Together they're why most people give up and mark Korea "not supported."

The ~10-line version that works

I ended up packaging this as a pay-per-result Apify actor so I never have to babysit the anti-bot layer again. Here's the whole thing — no local browser, no proxy setup, just an API call:

import requests

TOKEN = "YOUR_APIFY_TOKEN"
ACTOR = "naver-place-scraper"

resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items?token={TOKEN}",
    json={
        "searchQuery": "강남역 카페",   # "Gangnam Station cafe"
        "maxPlaces": 20,
        "includeReviews": True,
        "maxReviewsPerPlace": 10,
    },
)

for place in resp.json():
    print(place["name"], "—", place["rating"], f'({place["reviewCount"]} reviews)')

The query is the one part you can't fake as a non-Korean speaker. The trick locals use: location + category. 강남역 카페 (Gangnam Station + café), 홍대 맛집 (Hongdae + good-eats), 제주 흑돼지 (Jeju + black pork). That combo is what makes Naver return a tight, relevant list instead of noise.

The output

Everything comes back as clean, English-keyed JSON — no Korean field names to map, no HTML to parse:

{
  "name": "Starbucks Gangnam-daero",
  "category": "Cafe",
  "phone": "1522-3232",
  "roadAddress": "390 Gangnam-daero, Gangnam-gu, Seoul",
  "businessHours": "07:00 - 22:00",
  "rating": 4.3,
  "reviewCount": 1842,
  "coordinates": { "lat": 37.4979, "lng": 127.0276 },
  "reviews": [
    {
      "rating": 5,
      "date": "2026-06-30",
      "text": "Clean, quiet on weekday mornings, fast wifi.",
      "keywords": ["clean", "good for work", "friendly staff"]
    }
  ]
}

Name, category, phone, both address formats, hours, rating, review count, coordinates, and paginated per-place reviews with the sentiment keywords Naver attaches. That's the exact shape a lead-gen enrichment step, a local-SEO audit, or a "should we enter this neighborhood" market study needs — and it's the shape Google's API can't give you inside Korea.

Reviewer identities are never collected — just the review text, rating, date, and keywords.

Where this is useful

• Lead generation — every local business in a category/area, with phone + address, for outbound.
• Local SEO / listings — audit and monitor how businesses show up on the platform Koreans actually search.
• Market-entry research — density, ratings, and review volume by neighborhood before you commit.
• Review mining — pull the Korean-language review corpus for a brand or category and run sentiment on it.

The honest build-in-public part

This is one of ~30 Korean-platform scrapers I've been building solo — the sites that are big inside Korea but that nobody outside can crawl: Naver Place, Olive Young (K-beauty rankings), Encar (used cars — huge for exporters), KREAM (sneaker resale), and so on. Same thesis every time: Korean-native in → clean English JSON out. The language wall and the anti-bot wall are exactly what make these worth packaging instead of leaving as a DIY afternoon.

I'd genuinely like input from people who scrape for a living:

1. For lead-gen and local-SEO use cases, is per-place review pagination worth the extra requests, or is the summary (rating + count) enough for most of you?
2. On Korean hosts specifically, what's your go-to for session rotation — sticky sessions with retry, or per-request rotation? I've had far better luck with sticky+retry and I'm curious if that matches your experience.

If you want to try the Naver Place one, it's here: Naver Place Scraper on Apify. First runs are on the free tier, so you can see the JSON before deciding anything.

And if there's a Korean site you've hit this exact wall on, tell me — that's how I pick what to build next.