Yanolja (NOL) Stay Scraper

Extract accommodations from Yanolja (nol.yanolja.com), Korea's largest lodging marketplace: motels, hotels, resorts, pensions and poolvillas. Every record comes from ONE stay page read and carries:

• identity: name, stay group (hotel / motel / pension), star class, badges
• location: full address, city detail, directions text, latitude, longitude
• contact: the stay's own publicly displayed booking phone
• rates: room types with per-night availability rates for the site's default next-night window, overnight and day-use sold-out flags, the site's own price-range text
• reviews: rating value, review count, reply count, the service's short review summary, and the page's own review highlights with author initials, score, date, and review text
• policies: check-in / check-out times, cancellation text, policy notices
• media: the main photo, all property photos and room photos
• rooms: one nested entry per room type with id, name, subtitle, rate pair, benefits and up to three photos

Modes

• search (default): give one or more Korean region or place names, for example 서울, 제주, 부산, 가평. The actor matches each word against the region names of the site's own ranked collection pages (it publishes about three thousand of them per stay group), then reads every matching collection for its ranked stays, then reads each stay for the full record. A word that matches no published collection is skipped with a warning, and no slug is ever invented: an unknown slug is refused by the site's edge.
• url: paste stay URLs (https://nol.yanolja.com/stay/domestic/123456) and/or collection URLs (https://nol.yanolja.com/programmatic/domestic-accommodation/<name>). A stay URL is a single full record; a collection URL is browsed like a search for its ranked stays.

Filters apply in both modes: lowest-rate price bounds (KRW) and the returned row ordering (site order, price, rating).

Notes and limits, measured live

• The default next-night window is what the site serves in one read. Date specific rate picking for arbitrary future check-in dates is an app surface and is not offered on the web read lane, so the actor does not fake one: check-in/check-out dates on each row are the window the site itself served.
• Reviews per stay are the page's own ranked set (a handful of best and recent rows plus the summary's two-sided short text), not the full review history: the web lanes do not carry a per-stay review-index page (a probe of the reviews path returned a plain 404).
• Web keyword search does not exist on this storefront (search lives in the mobile app). The search mode is the region and collection browse, which is the site's own public read surface for discovering stays.
• Collection pages are single ranked top lists, so a collection contributes up to about ten stays per run; the full catalogue universe (hundreds of thousands of stay ids) is reachable because every collection gives its own ten, and URL mode takes stay ids directly.
• The ranked feed inside a collection ROTATES between page loads (the top list disagrees on which stays it names between two reads), so incremental legs on search mode legitimately classify mostly NEW; the stable shape for incremental monitoring is URL mode with fixed pasted stay URLs, where suppression is proven live.
• Prices are Korean won as the site displays them, with comma separators stripped into the numeric fields.

Connection

The default pins a Korean resident-type Exit connection. Stay pages answered every share of the cheaper pools with an edge refusal page during live probing, so that is not an optional upgrade, it is the only lane this storefront serves. Any proxy configuration you paste wins verbatim.

Output

One row per stay. See the dataset view named overview (the default tab in the Console) for the full field set, and scrapedAt / changeType / changedFields / firstSeenAt / lastSeenAt when incremental mode is on.

Incremental mode and resume

Two separate things, in one section of the input:

• Resume from a previous run: continue ONE interrupted crawl by pasting its run or dataset id; collected record ids are skipped.
• Incremental mode: schedule the same scope and get only what changed (NEW / UPDATED / REAPPEARED / EXPIRED). Rate moves are reported as UPDATED: on an accommodation marketplace the rate is the signal.

Sample record (fictional placeholder values, never a real stay)

{
  "recordId": "100000001",
  "stayId": "100000001",
  "rowType": "stay",
  "url": "https://nol.yanolja.com/stay/domestic/100000001",
  "name": "Sample example stay at Sample Area (example campaign name)",
  "stayGroup": "Motels",
  "address": "Sample-gu, Sample-si, Sample Road 12 (example-dong)",
  "cityName": null,
  "sellerPhone": "05000000000",
  "ratingValue": 4.2,
  "reviewCount": 123,
  "lowestPriceKrw": 36000,
  "overnightPriceKrw": 36000,
  "dayUsePriceKrw": null,
  "overnightSoldOut": false,
  "dayUseSoldOut": true,
  "priceRange": "Room 20,000 KRW and up, Stay 30,000 KRW and up",
  "facilities": ["Sample amenity one", "Sample amenity two"],
  "rooms": [
    {
      "roomTypeId": 250000,
      "roomTypeName": "Sample room (sample walk-in type)",
      "subTitle": null,
      "overnightPriceKrw": 36000,
      "dayUsePriceKrw": null,
      "benefits": ["Streaming service included"]
    }
  ]
}

Reporting a blocked run

A refused window fails the run loud ("Could not read any results from the data source..."), it never leaves a record-shaped sentinel row behind, and a genuinely empty scope ends quietly with a status message. The alternate fallback tier engages only after the main connection refused everything.

Export to your apps (MCP connectors, optional)

Nothing in this section changes the dataset. Authorize an MCP connector under Apify, Settings, API & Integrations, then select it in the input's Export panel. Notion gets a page per record; other connectors receive a best-effort write or digest. The full record always stays in the dataset; the connector side channel receives a condensed summary per record.