Naver is South Korea's portal, and its blog and cafe products are where Korean consumers write reviews, ask questions and trade. On 28 September 2026 we fetched them 20 times through residential exits in South Korea, the United States and Germany. The desktop blog is a frame that returns 0 words with or without JavaScript. The same post on the mobile subdomain returns 768 words in 155,493 bytes over plain HTTP, identical from all three countries. The blog RSS hands over 50 posts in 99,632 bytes, a public cafe serves 8,280 words in a 1990s Korean charset, and the Open API answers a keyless request with 113 bytes and a documented quota of 25,000 calls a day.
The keyword is shopping, geo-restriction and two false friends
Naver proxies has no autocomplete. The United States SERP opens with a Reddit thread reporting that Naver Shopping hides product details from non-Korean addresses, then two proxy vendor pages, a research repository from naver-ai about proxy rewards in language-model alignment, a Naver Labs dataset called proxy virtual worlds, a scraping-vendor tutorial about search results and Smart Store, a buy-and-ship service, a Facebook travel group and a page selling Naver accounts. Two of those results are not about proxies in our sense at all, and none measures the two surfaces that carry Korean consumer opinion: Naver Blog and Naver Cafe.
The data intent is under naver scraper, which autocompletes to novel scraper, blog-scraper and shopping scraper, and under naver api: hub, key, documentation, client id, map, mcp. This page is for that reader, doing brand monitoring, product research and social listening in Korean, with Naver's own rules quoted where they are written down. Buying Naver accounts is on the SERP and is not something we help with.
The desktop blog is a frame; three other doors are open
We requested the official Naver blog at blog.naver.com/naver_diary. It redirected to NBlogTop.naver?blogId=naverofficial and returned a page with a title, a meta robots tag of noindex,follow and 0 words, without JavaScript and after rendering alike. The desktop blog is a frame document that loads the real post inside an iframe, so a client that reads the outer page reads nothing, in any mode. Three other surfaces serve the same content directly:
| Surface | URL shape | Status | Bytes | Markdown words | Time |
|---|---|---|---|---|---|
| Desktop blog (frame) | blog.naver.com/<id> | 200 | shell | 0 | 9.0 s audit |
| Mobile post | m.blog.naver.com/<id>/<logNo> | 200 | 155,493 | 843 | 3.1 s |
| Desktop post document | blog.naver.com/PostView.naver?blogId=&logNo= | 200 | 301,067 | 1,220 | 3.5 s |
| Blog RSS | rss.blog.naver.com/<id>.xml | 200 | 99,632 | 50 items | 1.9 s |
The mobile post is the clean one: UTF-8, meta robots index,follow, the title, a description, an h1 and an Open Graph URL pointing at the desktop permalink, so the mobile page tells you the canonical desktop identity of the post. The PostView document is the thing the desktop iframe loads, and it is fetchable directly with the blog id and the post number; it is heavier because it carries the sidebar and seven tables of widgets. The RSS feed is the cheapest listing on the platform: 50 posts with links and summaries in 99,632 bytes, about 1,993 bytes per item, no key, no cookie.
The exit country changes nothing on the blog
We audited the mobile post with and without JavaScript from three countries, sending no Accept-Language header:
| Exit | No-JS words | Rendered words | No-JS bytes | Render time |
|---|---|---|---|---|
| South Korea | 768 | 768 | 155,493 | 5.0 s |
| United States | 768 | 768 | 155,493 | 8.2 s |
| Germany | 768 | 768 | 155,493 | 4.0 s |
Nine numbers, three distinct values. The rendered pass added zero words from every exit and cost 302,616 bytes and 5.5 seconds against 155,493 bytes and 3.1 seconds over plain HTTP. On Naver Blog the browser is pure overhead, and the country is a latency choice, not a content choice: Germany was the fastest exit that afternoon and Korea was second. The geo-restriction that the SERP talks about belongs to Naver Shopping, a surface we did not measure here; on the blog and the cafe we saw identical bytes from three continents. This is the same shape we found on Mastodon, where one cached response served four continents, and the opposite of TikTok.
The cafe is plain HTML in a charset your parser has forgotten
Naver Cafe is the platform's forum product, and the largest public cafe, 중고나라, is Korea's second-hand marketplace. Its home page over plain HTTP from a Korean exit returned HTTP 200, 895,417 bytes, 8,280 markdown words, 34 headings and 212 images, and exactly the same 895,417 bytes from Germany. The audit counted 1,788 words of body text without JavaScript and 2,430 rendered, from Korea in 12.1 seconds and from the United States in 21.7 seconds: the render adds the login-dependent widgets, and the listing content was already there.
The trap is in one header. The response declares Content-Type: text/html;charset=MS949, the Windows extension of the EUC-KR encoding. Our no-JS audit read the title as Áß°í³ª¶ó : ³×À̹ö Ä«Æä, which is what you get when CP949 bytes are decoded as Latin-1; the rendered pass, which lets the browser honour the header, read it as 중고나라 : 네이버 카페. Same bytes, two strings. A parser that assumes UTF-8 will store 8,280 words of mojibake and never raise an error, so decode by the declared charset before you touch the text. The blog surfaces are UTF-8; the cafe is not. The cafe also carries meta robots noindex, nofollow, which is the platform's stated preference about what happens to that text next.
The Open API is the sanctioned door, and it has a number on it
Naver publishes a search API for blogs, news, cafes, shopping and more at openapi.naver.com. We called the blog search endpoint without credentials from three countries. It answered each time with HTTP 200-class routing to a 113-byte JSON body naming the missing client id in Korean and English, identical from Korea, the United States and Germany. The documentation states the terms plainly: register an application at the developer centre, send X-Naver-Client-Id and X-Naver-Client-Secret as request headers, and the search API allows 25,000 calls per day per client id.
That number decides the architecture. A monitoring job that needs a few thousand Korean blog and cafe matches a day fits inside the free quota with no proxy at all, and returns structured JSON with titles, links, descriptions and dates. A job that needs the full post body, the comments or more than 25,000 lookups a day reads the mobile post or the PostView document over plain HTTP, which is where the proxy earns its keep. Use both: the API to find, the page to read.
What robots.txt says, three times over
Naver publishes a separate robots file per subdomain, and they disagree in instructive ways. blog.naver.com/robots.txt is 1,623 bytes. Its first block disallows everything for Yeti, which is Naver's own search crawler, because the blog has its own index. Then comes a line in capitals stating that bot access for AI training and retrieval-augmented generation is strictly prohibited, followed by Disallow: / for GPTBot, OAI-SearchBot, PerplexityBot, Google-Extended, ClaudeBot, Claude-SearchBot, meta-externalagent, Applebot-Extended and CCBot. The wildcard block that governs everyone else is a list of paths, print views, previews, buddy lists, guestbooks, /post/ and /npost/, and PostView.naver is not on it. m.blog.naver.com/robots.txt is 12,267 bytes with the same AI block and a longer path list.
cafe.naver.com/robots.txt is 804 bytes and stricter: the same AI notice, then Disallow: / for the wildcard, for Googlebot, Bingbot, Baiduspider, Yandex, Amazonbot, Applebot and every AI crawler named above. The only agents allowed are facebookcatalog and facebookexternalhit, the link unfurlers. So the honest line is this: Naver serves blog posts and cafe pages to any client, tells AI systems in writing not to train on them, tells general crawlers to stay out of the cafe entirely, and publishes an API with a daily quota for anyone who registers. The API and the blog RSS are the doors it built; the rest is readable but not invited.
What it costs, and what to stop paying for
Every number came through residential proxies on the Basic line at $0.80/GB, counting a gigabyte as 10^9 bytes:
| Job | Bytes per request | Requests per GB | Cost per request |
|---|---|---|---|
| Blog RSS, 50 posts | 99,632 | 10,037 | $0.000080 |
| Mobile post, plain HTTP | 155,493 | 6,431 | $0.00012 |
| Mobile post, rendered | 302,616 | 3,305 | $0.00024 |
| PostView document, plain HTTP | 301,067 | 3,322 | $0.00024 |
| Cafe home, plain HTTP | 895,417 | 1,117 | $0.00072 |
Ten thousand blog posts a day over plain HTTP is 1.55 GB, about $1.24; rendered, about $2.42 for the same 768 words each. The RSS route is about 501,800 post summaries per gigabyte. On mobile proxies at $2.30/GB the plain-HTTP post is $0.00036; nothing we measured on the blog or the cafe examined the network type, so the cheaper line is the right one for these surfaces. We did not measure Naver Shopping, and this page makes no claim about it.
The setting that works on Naver
- Network: residential, Basic line at $0.80/GB. Blog and cafe returned identical bytes from Korea, the United States and Germany; the network type is not what these surfaces examine.
- Fetch mode:
engine: tls, plain HTTP, againstm.blog.naver.com/plus the blog id and post number: 843 markdown words and 768 audit words from 155,493 bytes. Rendered it is 302,616 bytes for the same 768 words. Never fetch the desktop frame, which is 0 words in every mode. - Country: any. The post was 155,493 bytes and 768 words from all three exits; Germany rendered fastest at 4.0 seconds and Korea at 5.0. Pin Korea only when a job also touches surfaces we did not measure here.
- Parser rule: decode by the declared charset. The cafe serves
text/html;charset=MS949and its 8,280 words are mojibake under a UTF-8 assumption; the blog is UTF-8. - When the proxy is not enough: there is no Naver collector in our catalogue today. For discovery, the Open API returns structured matches at 25,000 calls a day per registered client id with no proxy; for post bodies as clean markdown or JSON, the web scraping API without rendering is $0.0002 per page and reads the mobile post in full.
- Every account gets $2 of free API usage per month.
For the Chinese platforms measured the same week, where the head carries the note text or the counters and the browser is equally unnecessary, read Xiaohongshu and Bilibili.