The short version
- No ATS vendor documents a keyword density score. The two that publish matching docs describe skill concepts, not term frequency.
- Greenhouse states directly that a longer list of matched terms does not always mean a higher match score, and that its matching never auto-rejects anyone.
- Parsers collapse synonyms. Textkernel's taxonomy carries over 300,000 synonyms, so "JS", "JavaScript" and "ECMAScript" resolve to one skill. Writing all three earns one match, not three.
- Most keyword matching you actually face is a recruiter typing a Boolean query, not an algorithm ranking you.
- The "75% of resumes are rejected by an ATS" number traces back to a 2012 sales pitch by a resume-optimisation vendor that no longer exists.
Keyword advice for resumes has calcified into a ritual. Count the terms in the job description, mirror them back, hit some density target, and the machine lets you through. It is repeated so widely that almost nobody checks it against what the systems actually do.
The pressure behind it is real enough. Greenhouse's hiring benchmarks, drawn from more than 640 million applications across 6,000 companies, put applications per recruiter at 746 in 2025, up from 146 in 2022, while recruiter headcount per organisation fell from 10.43 to 4.62. Someone is triaging far more people with far less time.
But that pressure does not produce the mechanism the advice assumes. Read the vendor documentation and the density model falls apart, and what replaces it changes what you should actually do.
What keyword matching actually does
In Greenhouse, the keyword feature a recruiter uses most is Boolean search. A human types a query with AND, OR and NOT, and gets back candidates whose parsed text matches. There is no score involved. You are either in the result set or you are not, and the query was written by a person who decided what mattered.
Greenhouse does also run an assistive matching feature, and its own FAQ is unusually direct about the limits. It says the feature "does not auto-reject or auto-advance any candidate", that recruiters and hiring managers make all advancement and rejection decisions, and that for skills it compares related terms on a resume against calibrated skills, where multiple terms can map to the same skill.
Then comes the sentence that undoes the entire density model: a longer list of matched terms does not always mean a higher match score. That is the vendor, in its own support documentation, saying term count is not the scoring variable.
“Repetition is not the input. A term you use once and a term you use nine times resolve to the same skill.”
Why synonym expansion makes stuffing pointless
The mechanism behind that sentence sits one layer down, in the parsers that ATS products license. Textkernel's skills taxonomy covers over 4,500 professions and more than 12,000 skills, connected by over 300,000 synonyms and over 500,000 weighted links between skills and professions. Its ontology API exposes those relationships directly, including acronyms and alternative wordings.
Follow that through. If "JS", "JavaScript" and "ECMAScript" all normalise to one canonical skill, listing all three does not produce three matches. It produces one, and it costs you a line of resume space that could have carried evidence instead.
This is why the two findings reinforce each other rather than merely coexisting. The taxonomy collapses your variants into a single node, and the matching layer does not reward how many terms landed on that node anyway. Stuffing fails twice over, for two independent reasons, documented by two unrelated companies.
| Common belief | What vendor documentation says | What to do instead |
|---|---|---|
| The ATS scores keyword density | No vendor documents a density score; Greenhouse says more matched terms does not raise the score | Use each important term once, in context |
| List every variant of a skill to catch the filter | Parsers normalise synonyms and acronyms to one skill | Pick the phrasing the job description uses |
| The system auto-rejects low scorers | Greenhouse states its matching never auto-rejects or auto-advances | Write for the recruiter reading the shortlist |
| Keywords in a skills list are enough | Matching maps terms to skills, and recruiters search parsed text | Put the term where the evidence is, in the bullet |
| White text hides extra keywords | iCIMS says most vendors have fixed that trick | Do not. It is detectable and it reads as fraud |
The match scores that are real
None of this means scoring never happens. Some products genuinely do compute a match, and it is worth knowing what they look at. Workday's HiredScore AI for Recruiting grades candidates as a way of prioritising them, based on a comparison of job requirements against candidate resumes.
Note what that description is not. It is not term frequency. Where vendors describe their matching at all, they describe structured attributes: skills, work history, seniority, education. The unit is the concept, not the string, which is exactly what the taxonomy layer would predict.
It is also worth being honest about a gap. Workday's public documentation states the purpose of grading and says very little about the inputs. The detailed accounts circulating about exactly how it ranks you against the applicant pool do not appear in any Workday document we could find. Treat those as unsourced.
See which keywords your resume actually matches
Optimize your application materials in under 2 minutes.
Tools that compare a resume against a specific job description report which requirements are evidenced and which are missing, which is a more useful question than how many times a word appears.
Where to put keywords so they survive
If frequency is not the lever, placement and evidence are. A term carries weight when it sits next to proof that you did the thing, because that is what a recruiter is scanning for once the search returns a stack of people who all technically match.
- Use the job description's own phrasing for each key skill, once, rather than inventing variants.
- Put the term inside a bullet that shows the work, not only in a skills list. "Rebuilt the payments service in Go" beats a comma-separated row of languages.
- Cover the responsibilities, not just the technologies. Matching compares against calibrated skills, and many of those are activities.
- Keep the parsed structure clean, because a term the parser never extracted cannot match anything. Formatting decides what gets extracted.
- Write the bullets so the evidence is legible in seconds, using the action, context, result shape.
A three-step keyword audit
This takes about fifteen minutes per application and replaces guessing with checking.
- Pull the eight to twelve requirements the job description states as must-haves. Ignore the boilerplate about culture and passion.
- For each one, find the bullet on your resume that proves it. If there is no bullet, that is a genuine gap, and adding the word alone will not close it in front of a human.
- Check the phrasing matches the posting for the terms that are genuinely standard in the field (a resume tailoring tool can show which are missing), then stop. Once each requirement is evidenced once, additional repetition buys nothing.
If a requirement has no supporting evidence anywhere in your history, the honest move is to target roles where it is not a must-have, or to go and acquire it. A resume that keyword-matches a job it cannot support survives the search and fails the screen, which wastes the recruiter's time and yours.
Where the 75% number came from
You have seen the claim that 75% of resumes are rejected by an applicant tracking system before a human sees them. It is the most repeated statistic in this subject and there is no study behind it. It has been traced to a 2012 sales pitch by Preptel, a resume-optimisation vendor that shut down the following year. No methodology was ever published.
Worth noticing who benefits. That number is marketing from a company selling resume optimisation, and it is repeated most enthusiastically by companies selling resume optimisation. We sell resume tools too, which is exactly why the claims in this post are sourced to Greenhouse's and Textkernel's documentation rather than to our own opinion. Check them yourself.