The job-board tax: why aggregators show 30 percent of roles 5 days late

Every major job aggregator (LinkedIn, Indeed, Glassdoor, ZipRecruiter) shows you a "posted" timestamp on each role - "2 days ago", "1 week ago", that sort of thing. Most people read that timestamp as the moment the company opened the role. It isn't. It's the moment the aggregator first ingested the role into its index, which is usually a day or two after the company actually posted it on their own careers page. We've looked at this gap in some detail: typical lag is 1.5-3 days, the long tail stretches to a working week, and roughly 30% of roles are 5 days late or worse.

You don't notice this happening because the aggregator is the only timestamp you ever see. The role goes live on the company's ATS on Monday morning. LinkedIn shows it to you on Wednesday afternoon and calls it "new". You apply on Thursday. You are applicant #75.

That is the job-board tax: a delay you pay in time, on every role, that you didn't know was being charged.

What the tax costs in applicant position

If a role typically receives 200 applicants in its first week and applications arrive roughly linearly, the practical cost of the aggregator delay looks like this:

Recruiter response rate data consistently shows that applicants #1 to #25 receive 3 to 5 times the screen rate of applicants #100 to #200. The aggregator delay isn't just an inconvenience; it's a structural conversion-rate hit.

Why the tax exists

The tax isn't malicious. It's the cost of running an aggregator. Our piece on why aggregators show stale roles covers the structural reasons in depth, but the short version is:

1. Crawl politeness. An aggregator like Indeed has to respect rate limits when fetching company career pages. Indeed indexes millions of company URLs, and hitting each once a day is heavy infrastructure. Many pages are crawled every 2 to 5 days, not daily.
2. Deduplication. The same role appears on the company's own site, on recruitment agency sites, and on multiple aggregators-of-aggregators. The dedupe step is computationally expensive and a major source of latency.
3. Classification. Each role needs to be tagged (industry, seniority, location, salary band, remote-eligible). This happens after ingestion using imperfect machine-learning models, and adds queue time.
4. Email batching. Saved-search digests batch overnight to reduce email volume, adding another 12 to 24 hours.

Each of these steps is a reasonable engineering choice. Together, they add up to the tax.

The 5-day tail

The median delay is 1.5 to 3 days, but the tail is where the tax really hurts. About 30 percent of roles, on the measurements above, appear on LinkedIn 5 days or more after they were posted to the canonical source. Some never appear at all, particularly for small companies on Ashby or Greenhouse that don't pay for LinkedIn syndication.

If you only use aggregators, you don't see the roles in this tail at all. You are not just late; you are absent. Our piece on early-stage startup jobs covers the specific gap for YC and seed-stage employers.

Why this matters more for some sectors

The structural cost of the aggregator tax scales with how fast the underlying funnel moves. Our time-to-fill data shows the median visible lifespan of a posting:

• Aviation cabin crew, hospitality, retail ops: 5 to 7 days. A 3-day aggregator delay means you miss half the window entirely.
• Junior and mid-level tech roles: 14 to 21 days. A 3-day delay still hurts but isn't fatal.
• Senior leadership and specialised research: 30 to 90 days. Aggregator delay is largely irrelevant; the funnel is hunting on a long timescale.
• Public sector with fixed close dates: the close date is the close date. Aggregator delay is irrelevant within the window.

The "aggregator tax" framing is most useful for the first two categories. For the latter two, the aggregator delay is a non-issue; what matters is application quality.

What to do instead

There is one structurally correct alternative: read the canonical source directly. Our complete guide to monitoring careers pages compares every practical method (manual bookmarks, RSS, page-change monitors, rolling your own, purpose-built services).

For most active job seekers with a defined target list of 20 to 50 employers, the highest-leverage setup is:

1. Direct ATS monitoring on the target list, with same-day email alerts.
2. One broad LinkedIn or Google Jobs alert for discovery, to surface employers you didn't know about.
3. Skip the saved-search email digests; they're optimised for engagement, not freshness.

Our comparison of LinkedIn alerts, Indeed alerts and direct ATS monitoring covers the practical setup for each.

The argument for aggregators

To be even-handed: aggregators are not useless. They are excellent for discovery, for exploring adjacent industries, and for casting a wide net when you don't yet have a target list. The mistake is using them as your primary channel once you do have one.

Use aggregators to learn. Use direct monitoring to apply.

What's worth taking from this

Aggregators aren't villains, and the people who built them aren't trying to slow you down. The lag is the cost of doing what they do at scale. But once you know the tax exists, you can stop paying it on the part of your search where it actually matters. Use aggregators to learn what's out there; use direct monitoring to apply.

The role you saw on LinkedIn on Wednesday and the role the canonical source published on Monday are not, in any sense the recruiter would care about, the same opportunity. Our complete guide to applying early covers the broader playbook for getting your name into the first batch instead of the second hundred.

---

← Back to blog  ·  Try FirstPost free →