Naver Videos Scraper

Fast extraction of public Naver Video search results. Version 3 uses validated server-rendered HTML and concurrent HTTP pagination instead of launching a browser, scrolling, and calling YouTube oEmbed for every card.

Input modes

• query: one search phrase.
• queries: multiple phrases with fair round-robin output.
• startUrls: public search.naver.com/search.naver URLs containing where=video and query.

Filters include platform, channel include/exclude lists, duration, minimum views, publication recency, YouTube Shorts, and explicit LIVE labels. Output can be sorted by Naver relevance, publication time, views, or duration. maxItems, maxPages, concurrency, retry, timeout, and proxy controls are bounded.

{
  "queries": ["K-pop", "인공지능 로봇"],
  "maxItems": 20,
  "maxPages": 2,
  "proxyConfiguration": { "useApifyProxy": true }
}

The complete input contract, including defaults, filters, and bounds, is in .actor/input_schema.json.

Dataset

Records include a stable platform/video ID, canonical video and embed URLs, direct original thumbnail, platform/domain/video ID, title, channel URL/ID/avatar and verified label, duration and numeric seconds when published, numeric and formatted Naver view counts, parsed publication time, video-type flags only when positively observed, query/page/position provenance, locale, source domain, and scrape timestamp.

The complete dataset field schema is in .actor/dataset_schema.json.

Missing optional values are omitted. The Actor does not emit nulls, empty arrays/objects, fabricated Google favicons, zero engagement placeholders, opaque player APIs, signed transport data, or unsupported false flags. Naver relative dates are converted at scrape time and marked approximate.

How to use

Enter a video query or batch in the Apify Input tab, select filters and limits, and start the Actor. Review normalized videos in the Output dataset.

Network and safety

The Actor validates HTTP status, content type, recognizable result/no-result markup, and challenge pages before parsing. It uses a consistent Korean desktop HTTP profile, cookie-persistent sessions, bounded retries, and optional Apify/custom proxies. GOOGLE_SERP is rejected because it supports Google HTTP endpoints, not Naver. CAPTCHA or access-denied content fails closed and is never stored.

Naver offsets can overlap; stable IDs remove duplicates before records are written. Page size and optional metadata can vary as Naver changes its live result mix.