Job aggregator sites: where each one actually gets its listings

From the outside every job aggregator looks identical: a search box, a list of postings, an apply button. Underneath they source those postings in four completely different ways, and which one an aggregator uses decides everything you actually care about - how fresh the listings are, how much of the market they cover, whether the apply link works, and whether you can get the data out programmatically.

This is a breakdown by sourcing mechanism rather than by brand. If you want to build one rather than evaluate one, the job aggregator build guide covers the architecture instead.

Aggregator or job board?

A job board holds postings employers submitted directly to it. An aggregator collects postings that live somewhere else. The distinction matters because it determines who owns the canonical record: on a board the listing is the original; on an aggregator it is a copy that can drift out of date.

Most large sites are both. Indeed takes direct postings and aggregates. LinkedIn does the same. That hybrid is why coverage numbers from different vendors are so hard to compare - see where to get job posting data for how much deduplication swings the totals.

Mechanism 1: XML and RSS feeds

The oldest and still the most common. An employer or ATS publishes a feed of open roles, and the aggregator polls it on a schedule. Indeed built its early index this way, and the pattern is still how most large aggregators ingest at volume.

What it means for you: feed-sourced listings are usually clean and well-structured, because the publisher chose the fields. The weakness is inclusion - a company only appears if someone set up a feed. Feeds are also polled, so freshness is bounded by the polling interval rather than by when the job actually opened.

Mechanism 2: ATS APIs

Most companies post through an applicant tracking system, and many of those systems expose the public job board over an API. Greenhouse, Lever and Ashby all serve public postings as JSON without authentication, which makes them the highest-quality source available.

What it means for you: this is the closest thing to ground truth. The ATS record is what the employer edits, so it reflects status changes fastest and the apply URL points at the real application flow rather than an intermediary. The catch is fragmentation - every ATS has a different schema, and some gate access entirely. We wrote up which ones are open in public vs gated ATS APIs.

Mechanism 3: Scraping

When there is no feed and no API, aggregators crawl the career page. This is how coverage gets extended into the long tail of companies that never set anything up.

What it means for you: scraped listings have the widest coverage and the weakest guarantees. Field extraction is inferred rather than declared, so salary, seniority and employment type are frequently missing or wrong. Scraped records also go stale hardest, because nothing notifies the crawler when a role closes - the aggregator has to re-crawl to find out. That recheck loop is the expensive part, and it is why expired postings linger on so many sites.

Mechanism 4: Paid inclusion and partnerships

Some listings are there because someone paid, or because two companies signed a syndication deal. Sponsored postings, partner feeds and pay-per-click placements all fall here.

What it means for you: this is the mechanism that most distorts what you see. Ranking reflects commercial arrangements as well as relevance, and coverage of any given employer depends on whether they bought placement. If you are measuring a hiring market rather than looking for a job, paid inclusion is a source of bias you have to account for.

How the major aggregators compare

Grouping the well-known sites by their dominant mechanism, rather than by size:

• Indeed - hybrid at the largest scale: direct postings, employer feeds, crawling, and sponsored placement. Broadest coverage of anything on this list. There is no open public read API for the index; the practical routes are covered in the Indeed API guide.
• Google for Jobs - not an aggregator you can query but a SERP feature. It ingests structured JobPosting markup that sites publish, which makes schema correctness the entry ticket. No public read API exists; the Google Jobs API post explains what people actually use instead.
• LinkedIn - direct postings plus aggregation, with the richest company metadata and the tightest access controls of any source here.
• Adzuna - feed and partner driven, and unusual in offering a genuinely free documented API with salary analytics. Details in the Adzuna API post.
• Jooble, Careerjet, Talent.com - classic feed-plus-crawl aggregators with strong international coverage, generally reachable through partner APIs rather than open ones. See the Jooble API post.
• SimplyHired - long-running aggregator, now closely tied to the same index Indeed operates.
• Vertical aggregators - Dice for tech, We Work Remotely and similar for remote. Narrower by design, and usually fresher inside their niche because the crawl surface is small enough to poll often.

What actually decides quality

Three questions separate a useful aggregator from a large one, and none of them are about listing count:

• How is duplication handled? The same role posted to an ATS, a feed and a board is one job, not three. Whether a vendor collapses those changes totals by several times over, which is why headline coverage figures are close to meaningless without a stated methodology.
• How is closure detected? Age is not status. Plenty of legitimate roles stay open for months, and plenty close in days. An aggregator that ages listings out on a timer is guessing; one that rechecks the source knows.
• Where does the apply link point? At the employer, or at another page on the aggregator? The second costs the candidate a hop and is the most common reason an apply flow dead-ends.

If you are consuming this programmatically

Browsing an aggregator and building on one are different problems. Most of the sites above either have no public read API or gate it behind a partner agreement, which is the wall people hit after prototyping against a scraper.

The two honest options are to run your own collection across the mechanisms above - which is the whole of build vs buy - or to read from an API that already normalizes them. The JobsPipe API returns one schema across sources with deduplication and verified-open status:

curl https://api.jobspipe.dev/v1/jobs/search \
  -H "Authorization: Bearer jp_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "job_title_or": ["backend engineer"], "remote": true, "limit": 25 }'

Whichever route you take, the framework holds: identify which mechanism a listing came from, and you know in advance how much to trust its salary field, its freshness, and its apply link.