Superyacht Crew Jobs Scraper — Yacrew, Meridian & The Crew Network

Yacht crew vacancies are split across boards that publish the same job in three different shapes. This Actor reads Yacrew, Meridian and The Crew Network in one run and returns a single normalised dataset — every board's department, contract type and vessel length on the same scale, whichever board a row came from.

Disclaimer. This is an unofficial, independent job aggregator. It is not affiliated with, endorsed by, sponsored by, or connected to Yacrew, Meridian, The Crew Network, or any employer or yacht listed on those sites. Their names are used here only to identify the publicly accessible websites this Actor reads. All job content belongs to its respective publishers.

What this Actor does

A recruiter or crew agency covering the superyacht market has to check three sites with three different data models: one publishes an expiry date that means what it says, one computes a fake one on every page load, and one never removes an old posting at all. This Actor absorbs those differences so you don't have to.

1. It reads each selected board through the method that actually fits it — Yacrew's sitemap, Meridian's paginated listing pages, The Crew Network's public JSON API — and opens the individual job page or record where the board publishes richer data there.
2. One board blocked or slow never fails the run: each source is crawled independently, and a broken source is reported FAILED in the run summary while the others finish and are billed normally.
3. It maps all three sources onto one shared record shape (44 columns), so department, contractType and vesselLengthM mean the same thing in every row. A field only one board publishes is never thrown away — it survives under siteSpecificExtra.
4. It works out whether a listing is actually open using the signal that is true for that board, not a one-size-fits-all date check — see "How liveness works" below.
5. It enriches each record with derived fields no board publishes: a monthly wage in USD and EUR, a seniority tier and a days-since-posted count.
6. Every string field is scrubbed of emails, phone numbers and messaging handles before it is saved — this Actor collects job postings, not the personal contact details sometimes left inside them.
7. It offers a cross-board possibleDuplicateKey, because the same berth is sometimes posted through more than one channel.
8. When the run finishes it builds an HTML run report and saves it to the run's key-value store.

The three sources

Source	Site	Approx. active vacancies	Extraction	Notes
Yacrew	yacrew.com	A few hundred, out of 23,600+ pages in its sitemap	Sitemap → individual job pages	The only source with a real archive: includeArchive unlocks it here specifically
Meridian	meridiango.com	~550	56 paginated listing pages → job pages for richer records	No posting date field at all — see firstSeenAt below
The Crew Network	crewnetwork.com	~75	Public JSON API, no login	The only source that publishes the yacht's own name

Use the sources input to pick which boards actually run. Every source you include adds to the record count, and therefore the cost, of a run — deselecting a board you don't need is the main cost control here.

How liveness works — two different signals, on purpose

Yacrew publishes a real, checkable expiry signal: the page's own Apply button disappears exactly when a listing closes. Meridian and The Crew Network do not — Meridian's "valid through" field is computed fresh on every page load (today + 30 days) rather than stored, and neither board removes old postings from its listing at all (Meridian entries from 2023 were still listed at the time this was built).

So this Actor reads each board on its own terms instead of forcing one rule onto all three:

• Yacrew — a record is isArchived: true or false based on that real Apply-button/expiry signal. With includeArchive off (the default), you get only currently open listings; turn it on to pull the archive too, useful as salary and demand history.
• Meridian and The Crew Network — every record is isArchived: false. Neither board publishes an expiry, and neither removes old postings, so "currently in the board's own listing" is the signal, full stop — that's how these two boards work, not a gap in the parser. Want to know when a listing disappeared from one of them? Compare two runs' sourceListingId sets.

firstSeenAt — for boards that publish no reliable posting date

Meridian publishes no posting date on most listings (a usable date exists on some job pages, not the fast listing view), and a small share of its individual pages have none at all. For any record that arrives with no date, this Actor records the moment it first saw that listing as firstSeenAt, with the record flagged FIRST_SEEN_BASELINE on the very first run of a given stateKey (because on that run "first seen" really means "seen for the first time by this Actor", not "posted today"). The postedWithinDays filter uses firstSeenAt as a fallback for exactly these records, and excludes them by default when it cannot tell whether they are within the window.

How it treats the source sites

• robots.txt is fetched and honoured for every source on every request; personal-data zones (candidate search, CV pages, recruiter directories) are never requested regardless of what robots.txt allows.
• Each site's own published rate limit wins where it is stricter than your maxRequestsPerMinute. The Crew Network publishes a 10-second crawl delay and is never crawled faster than 6 requests per minute regardless of the input.
• Only publicly accessible pages are read. There is no login, no paywall circumvention and no bot-protection evasion of any kind.
• Every text field is scrubbed for emails, phone numbers and common messaging-app handles before it reaches the dataset or the run report. This is pattern-based, not a guarantee against every possible format, and it does not remove a person's name on its own when no contact detail sits next to it.

Input parameters

Every parameter is optional. With no input at all the Actor pulls a small 60-record sample so a plain run finishes quickly — raise maxItems once you know how many records your filters actually return.

Parameter	Type	Default	Description
sources	array	all three	Which boards to crawl: yacrew, meridian, crewnetwork.
includeArchive	boolean	false	Also return closed listings. Applies to Yacrew only — see "How liveness works" above.
maxItems	integer	60	Hard cap on records saved across all sources combined, counted after the filters below. 0 for no cap. Enforced exactly.
onlyNew	boolean	false	Skip listings an earlier run with the same stateKey already saved. Detects by listing id; an edited listing already saved is not "new".
categories	array	all	Keep only these departments: DECK, ENGINEERING, GALLEY, INTERIOR, SPECIALIST, SHORE_BASED, OTHER.
positionKeywords	array	none	Keep only vacancies whose position or title contains one of these words (case-insensitive). Up to 20 entries, 60 characters each.
regions	array	none	Keep only vacancies whose location text contains one of these words. Same limits as above. Listings with no location text are excluded while this is set.
postedWithinDays	integer	none	Keep only vacancies from the last N days, by datePosted/dateUpdated, or firstSeenAt where a board has no date.
minVesselLengthM / maxVesselLengthM	integer	none	Yacht length bounds in metres. Listings with no known length are excluded while either is set.
includeJobDescription	boolean	true	Include the plain-text description (contact details always removed). Turn off for a compact export.
stateKey	string	default	Names the saved-listing set onlyNew reads and writes. Change it to keep two schedules apart.
maxRequestsPerMinute	integer	40	Courtesy rate limit per source. A site's own stricter limit still wins.
proxyConfiguration	object	disabled	Usually unnecessary — all three sources serve plain HTML or a public JSON API with no challenge.

Example input

{
  "sources": ["yacrew", "meridian", "crewnetwork"],
  "categories": ["DECK", "INTERIOR"],
  "minVesselLengthM": 40,
  "maxItems": 500
}

Output

One dataset item per vacancy, on a stable 44-column set that does not depend on which sources a run included. Fields a given board does not publish are null rather than omitted.

Core fields

Field	Type	Description
sourceSite	string	yacrew, meridian or crewnetwork. Part of the public contract; these values will not be renamed.
sourceUrl	string	A page a person can open for this listing.
sourceListingId	string	The board's own id. Unique per source, not globally.
dataCompleteness	string	FULL (built from a detail page/record) or LISTING_ONLY (built from a listing card, when includeJobDescription allows the faster path).
scrapedAt	string	ISO 8601 timestamp of the extraction.
isArchived	boolean	See "How liveness works" above. Always false for Meridian and The Crew Network.
title / positionLabel	string	Posting title, and the role on its own where the board publishes them separately.
department	string	One of the values above. Normalised from each board's own category or, where a board publishes none, inferred from the position text and flagged DEPARTMENT_INFERRED_FROM_POSITION.
seniorityTier	string	Coarse level derived from the role text — a heuristic, not an official grade.
companyName / agencyName	string	companyName is null on every record — none of the three boards publishes the actual employer, and a placeholder would be a lie. agencyName holds the crewing/recruitment agency where a board publishes one; The Crew Network's own name (TCN) is kept as published, not filtered out.
locationText	string	As published; the three boards give this at different granularity (region, city, or only inside the description).
yachtName	string	The vessel's name — published only by The Crew Network, and not always a real yacht (some are agency office listings; see FAQ).
vesselType	string	MOTOR or SAILING, where a board's field actually means that. Meridian's own "Vessel Type" field means the yacht's use (private/charter), not this, so it stays null there — the raw value is kept under siteSpecificExtra.
vesselLengthM / vesselLengthFt	number	Yacht length. vesselLengthSourceUnit records which unit the board actually published.
salaryMin / salaryMax / salaryCurrency / salaryPeriod	number/string	Wage bounds as published. salaryPeriod is only ever filled when the board states it explicitly — see "No guessed salary period" below.
salaryTerms	string	Free-text pay terms the boards attach (e.g. "DOE", net/gross), kept as published.
rotationRaw / rotationOn / rotationOff	string/integer	Rotation schedule as published; On/Off day counts only when the board states a ratio like 5:1.
contractType	string	One of PERMANENT, TEMPORARY, SEASONAL, CHARTER_SHORT, DAY_WORK, DELIVERY, FREELANCE, mapped from each board's own wording. null where a board's field means something else (e.g. Meridian's "Full-Time" is an employment mode, not a contract type) — the raw value is always kept under siteSpecificExtra.
contractLengthValue / contractLengthUnit	number/string	Contract duration, where stated as a fixed term.
startDateText / startDateIso / startMonth	string	Requested start date as published, and resolved forms where the text parses safely.
datePosted / dateUpdated / validThrough	string	As published, where a board's field is a genuine fact rather than a computed placeholder (see "How liveness works").
firstSeenAt	string	See above. null for any record that arrived with its own date.
daysSincePosted	integer	From datePosted (or firstSeenAt where that is the only date available) to today.
descriptionText	string	Plain text only — contact details removed, original HTML never returned.
siteSpecificExtra	object	Everything one board publishes and the others do not, or that a shared column's strict definition excludes. See below.
possibleDuplicateKey	string	Cross-board cross-post signal. See below.
extractionFlags	array	Machine-readable notes on how a value was produced — see "Reading extractionFlags" below.

siteSpecificExtra

Examples: Yacrew's raw multi-department category string when a listing spans two departments; Meridian's vessel-use wording (Private/Charter and Private) and employment-mode text; The Crew Network's public apply link and raw job id. A parser gaining a new field never silently loses it — anything that does not fit a shared column lands here instead of being dropped.

Derived fields

Field	Type	Description
monthlyEquivalentUsd / monthlyEquivalentEur	number	The published wage restated as a monthly figure, in whichever of the two currencies the wage was published in — daily rates × 30, weekly × 52/12, annual ÷ 12, monthly unchanged. null when no wage is published, the currency is neither USD nor EUR, or the period is not stated (see below).
salaryNormalization	string	Why the wage above is or is not present: NORMALIZED, NO_SALARY_PUBLISHED, PERIOD_NOT_STATED, CURRENCY_MISSING or UNSUPPORTED_PAY_PERIOD.
daysSincePosted	integer	See above.

No guessed salary period

Some listings publish a figure ("3500-3800 USD") with no period attached. This Actor does not assume "per month" — salaryPeriod and the monthly-equivalent fields stay null for these, flagged PERIOD_NOT_STATED, and the raw text is preserved under siteSpecificExtra. Inventing a period would be a guess dressed up as data; the run report shows what share of a run this affected so you know how much of the wage picture is missing rather than wrong.

Cross-posting: possibleDuplicateKey

The same berth is sometimes advertised through more than one channel. possibleDuplicateKey hashes the identifying parts every board can publish — the role, normalised, and the yacht's length rounded to a 5-metre bucket — so cross-posts collide. Fields that only some sources publish (yacht name, agency, location, salary, posting date) are deliberately not in the hash: including them would tie the key to whichever source happens to publish it, not to the vacancy itself.

This Actor never de-duplicates on it. Two matching keys are evidence, not proof — two different "Deckhand, 50 m" berths on two boards will also collide. The key is exported and the decision is yours. It is null when either signal is missing, and always null on an archived record — an old, closed Yacrew listing cannot be the same open vacancy as a live one, so tagging it would only add noise on the one board large enough for that noise to matter.

Dataset views

The dataset ships with views selectable in the Console's dataset tab and in exports, covering an overview, compensation fields, cross-posting signals, and source/completeness provenance.

Run report (HTML dashboard)

Every run writes a self-contained HTML report to the run's key-value store under the key DASHBOARD. The Actor logs its URL at the end of the run log, and you can also reach it from the run's Storage → Key-value store tab. Open it in a browser — no download, no spreadsheet, no notebook.

The report shows run summary tiles (records scraped, wage coverage, distinct employers and vessel types), a wage distribution histogram, top departments and vessel types, and a source/completeness breakdown per board. Every chart has a plain data table underneath it, follows your system light/dark setting, and is readable on a phone.

Why this rather than a bare-JSON scraper

Most job-board Actors stop at one site: whatever fields it renders, whatever shape it uses, no idea whether a listing has actually expired. The work of making that usable — reading the other boards, reconciling their field names, working out which "valid through" date is real and which is computed on every page load, converting wage periods, spotting cross-posts, then building a chart to see what you actually got — lands on you, every run.

	Typical single-board Actor	This Actor
Coverage	One board	Three boards, selectable per run
Field names	Whatever the site used	One shared 44-column shape across all sources
Is it still open?	Unstated, or trusts whatever date the board shows	The signal that's actually true for each board — see "How liveness works"
One-board-only fields	Dropped, or left in an ad-hoc blob	Preserved under siteSpecificExtra
Wage fields	Whatever string the site printed	Parsed bounds and currency, plus a monthly USD/EUR equivalent — never a guessed period
Department	Whatever category (or none) the board used	Normalised to one vocabulary, inferred from the role where a board publishes no category, and flagged when it is
Cross-posts between boards	Invisible	possibleDuplicateKey, exported and left to you
Contact details	Left in the description text, if the board didn't remove them	Scrubbed from every field before it's saved
Missing data	Field absent, or a silent 0	Explicit null with a reason code (extractionFlags)
Seeing your results	Open the JSON	An HTML report linked from every run

Who this is for

Crewing and recruitment agencies

An agency placing interior and deck crew needs to know what's actually open today, not a board's stale listing — filter to categories: ["INTERIOR"], minVesselLengthM: 40, and you get open Yacrew listings, Meridian's whole current board and The Crew Network's whole current board in one table, wage already restated to a monthly figure so a day-rate posting doesn't look cheap next to a monthly one. Because department is normalised, "which boards are we missing candidates on" is one GROUP BY sourceSite, not three separate reads.

Independent yacht crew recruiters and placement consultants

Running a schedule with onlyNew turns this into a live feed of new berths instead of a manual daily check of three bookmarks — set positionKeywords to the ranks you place and get only the postings that match, with possibleDuplicateKey flagging the ones a competing agent has also posted.

Maritime market analysts

Track how department mix, vessel length and wage move over a season across three boards at once, or enrich an existing yacht-crew feed with a source that arrives already normalised and already flagged for cross-posting.

Reading extractionFlags

Each record carries a list of short codes noting how a value was produced, so a filtered or derived column is never silently wrong. Examples: DEPARTMENT_INFERRED_FROM_POSITION (department guessed from the role text, not published by the board), PERIOD_NOT_STATED (salary figure with no period attached), FIRST_SEEN_BASELINE (this run is the first time this Actor has seen the listing, so firstSeenAt is a lower bound, not a posting date), LIVENESS_WEAK (a rare case on The Crew Network where a listing appeared in the board's own results but its individual record could not be confirmed). An unrecognised flag never breaks a run — anything not in the published list is kept under siteSpecificExtra.unnormalisedValues instead.

Pricing

This Actor uses Apify's pay-per-event model. One event is charged once per job record saved to the dataset — one price for every record, live or archived, from every source. You pay nothing for pages that yield no data, nothing for a blocked source, and nothing for retries.

• You are never billed twice for the same listing. Records are de-duplicated by sourceListingId within each source during the crawl.
• maxItems is a hard spend cap, enforced exactly across all sources combined, guarded against concurrent source crawlers.

Frequently asked questions

Why does a Meridian or Crew Network record never show isArchived: true?

Because neither board removes old postings from its own listing, and neither publishes a field that reliably means "this has expired" — see "How liveness works" above. isArchived is false for every record from these two, by design, not because old listings were filtered out.

Why is yachtName sometimes not a real yacht?

The Crew Network is the only source that publishes it, and a few of its listings are shore-based roles at an agency's own office rather than aboard a vessel — the field is published as the board wrote it, including those cases, rather than filtered.

Why do some records have less data than others?

Check dataCompleteness. FULL records were built from an individual job page or API record; LISTING_ONLY records come from a faster listing-card path used when includeJobDescription is off and a board's own listing view already carries enough fields.

Why is the salary period missing on some jobs?

Because the board did not state one. See "No guessed salary period" above — this Actor does not assume "per month".

How current is the data?

Every run reads the live sites. datePosted/dateUpdated come from the posting where a board publishes them, firstSeenAt covers the rest, and scrapedAt records when the extraction happened.

Can I run only one board?

Yes. Set sources to just that one. It is also the cheapest way to sample: one board, maxItems: 20.

Does it need a proxy?

Normally no. All three sources have been reached from an Apify platform run with no proxy configured — two serve plain server-rendered HTML and one a public JSON API, none behind a bot-protection challenge.

Can I run this on a schedule?

Yes. Use onlyNew with a fixed stateKey to get just what changed since the last run.

Legal and responsible use

This Actor collects only publicly available job postings from employers and agencies. It does not collect candidate resumes, CVs or personal contact details — every text field is scrubbed of emails, phone numbers and messaging handles before it is saved, and paths that lead to candidate search or CV pages on these sites are never requested at all. It does not access any account-protected area and does not bypass authentication or bot protection on any of the three sources.

Job listing content remains the property of the publishers. You are responsible for ensuring your use of the data complies with applicable law — including data protection rules in your jurisdiction — and with each source site's own terms. If you intend to republish scraped listings, review those terms first.