When "remote" isn't: how RemNavi scores the hybrid listings the rest of the industry hides

Most remote job boards fail this test before the user clicks. They aggregate listings from company career pages, apply a "remote" tag to anything that mentions the word, and present the result as a curated remote jobs feed. What they are actually presenting is an unaudited stream that conflates fully-distributed positions with hybrid arrangements that require you to live in Austin and come in three days a week.

We pulled every listing in the RemNavi corpus as of 2026-09-01 – 10,153 active roles aggregated from Jobicy, Remote OK, We Work Remotely, Greenhouse, Lever, Remotive, and Hacker News Who's Hiring. We ran each one through the work-mode classifier built for our Real Remote Score methodology. Here is what came out:

• 76% (7,719) are fully remote as advertised – no office requirement in the description.
• 19% (1,905) say "remote" somewhere in the listing but require office time in the body – anywhere from one day a week to "flexible hybrid" near a specific city.
• 0% are onsite-only roles that survived into a remote index.
• 5% are ambiguous enough that no classifier should pretend to know.

One of those numbers used to be wrong, and it was ours. Our first classifier treated any occurrence of the word "hybrid" as evidence of a hybrid work arrangement, and it tested for that word before it tested for an explicit remote phrase. So a listing offering "hybrid oder auch 100 % remote", or a platform role describing a "hybrid cloud" architecture, got filed as hybrid. Method v2, deployed 2026-09-01, ranks the evidence instead: an explicit split schedule wins outright, an explicit remote phrase beats a bare mention of the word, and a bare mention counts only where it actually describes how the work happens. That reclassified 973 listings as fully remote and tightened the hybrid set from 3,132 to 1,905. An index that grades employers has to be willing to re-grade itself in public, with the numbers moving where anyone can see them.

The problem with the hybrid bucket is not that hybrid is bad. Hybrid is a legitimate working arrangement that many people prefer. The problem is that these listings get filed under "remote" and then reveal – on page two, below the benefits section – that you need to be within commuting distance of a specific city. That is not a remote job. That is a local job with a marketing problem.

The Real Remote Score already handles the problem for fully-remote listings – it grades how genuinely remote a position is on five dimensions (compensation transparency, location openness, source credibility, listing clarity, and freshness). But the RRS was designed for fully-remote evaluation. A hybrid listing will score poorly on RRS by design – location openness collapses – which is the right call for a remote index but tells the candidate nothing about whether the employer disclosed what they need to make a decision.

We built the Hybrid Transparency Score as a parallel 0–100 metric specifically for listings our classifier identifies as hybrid. HTS does not penalise a listing for being hybrid – it grades whether the employer told candidates the things they need to know:

A fully-disclosed hybrid listing – days stated, city stated, schedule flexibility described, relocation terms addressed, sourced from the company's own ATS – scores 90–100 and earns the Exceptional tier. An opaque hybrid listing that says "hybrid role, some office time required" without specifying where or how much scores below 30 and lands in the Weak tier.

Full HTS methodology at /methodology/

We ran HTS against every listing method v2 identifies as hybrid in our 10,153-listing corpus, then scored the 750 of them still inside their 30-day validity window – the ones a candidate could actually apply to today. The results:

The industry median on hybrid transparency is 25/100 – well into the Weak band. 59.6% of live hybrid listings fail to disclose enough for a candidate to make an informed decision before clicking through, and 88% score below 50. Exactly 0% score Exceptional; the highest single score in the live cohort is 70. The most basic disclosure of all – how many days you are expected in the office – is missing from 97.9% of them.

This is the same pattern we found with the Real Remote Score: the platforms that aggregate listings do not grade them, so opacity travels undisturbed from the employer to the candidate. The candidate clicks, spends 20 minutes on the application, and discovers the commute requirement on page three of the interview process.

One note on reproducing these: the facet endpoints report the full tracked corpus (1,905 hybrid), while the scores cited above use the live cohort – the 750 listings still inside their 30-day validity window. The endpoints gain an explicit basis field when that split ships; until then, filter on posted_at to reproduce the live figures exactly.

Ranked by average Hybrid Transparency Score across all hybrid listings with ≥ 20 entries in the RemNavi corpus. Score is 0–100; higher means the employer has disclosed more of the information a candidate needs before clicking through: days-per-week, city, core hours, remote share, and relocation terms.

Data sourced live from /jobs_api.php?facet=hts_by_company. Employers with fewer than 20 hybrid listings are excluded from this view; the full dataset (≥ 5 listings) is available via the API. Scores reflect the corpus at time of page load.

The aggregation model has a built-in opacity bias. Aggregators are measured on listing volume – the more listings, the more search traffic, the more clicks. Grading listings on transparency reduces apparent volume (Weak listings become less prominent) and requires infrastructure that pure aggregators have no incentive to build.

RemNavi's position is different: our value proposition is not listing volume, it is listing accuracy. A smaller corpus where every listing is graded and classified is worth more to a job seeker than a large corpus of undifferentiated results. HTS is the extension of that thesis into the hybrid category – the half of the market that RRS does not cover by design.

For candidates: HTS tells you, before you click through, whether a hybrid listing has disclosed what you need. A listing with HTS Weak means the employer has not told you how many days or which city. A listing with HTS Strong means the terms are disclosed. You decide whether the commute is acceptable; we make sure you have the information to decide at all.

For employers: the disclosure bar is low. Stating "3 days/week in our London office, Monday–Wednesday core hours" takes 12 words. Those 12 words move a listing from Weak to Strong and demonstrate that the employer respects candidates' time enough to be specific.

Method note. Classification method v2 since 2026-09-01 (remote-signal precedence, work-mode context). Historical daily series computed under v1 are marked as such, and are not directly comparable across that date.

The HTS classifier and scorer are open and documented. The full methodology – including factor weights, tier thresholds, and edge-case handling – is published at /methodology/. The source code for the JavaScript scoring library is at frontend/src/lib/hybridScore.js in our public repository.

All corpus statistics on this page are drawn from live API endpoints. Reporters can reproduce them at any time using the curl commands above. The numbers will change as new listings enter the corpus and the HTS backfill extends coverage to older listings. If a number cited in a published piece differs materially from the live API, the live API is the authoritative source – not the snapshot at time of writing.

This piece is published under CC BY 4.0. You may reproduce, reuse, and build on it with attribution to RemNavi and a link to this URL.

Published by RemNavi Editorial Desk · 2026-04-25 · Editorial policy · Scoring methodology