SS
Key Takeaways
- Count requirements, not keywords - a typical posting has five to eight things that genuinely matter.
- Cover each central term once properly rather than several terms shallowly.
- The practical ceiling is whatever you can discuss under questioning, which for most people is ten to fifteen technical items.
- Terms inside described work count for more than the same terms in a list.
- If you are counting keywords rather than checking evidence, you are optimising the wrong thing.
"How many keywords" is the wrong question, but people ask it for a good reason: they want to know when to stop. So here is a usable answer, and then the better question underneath it.
Start by Counting Requirements
A posting might contain forty distinct nouns. It rarely contains more than eight actual requirements.
Work out which by looking at three signals - position, repetition, and framing. Anything in the title or opening paragraph, repeated across sections, or marked "required" is real. Anything appearing once, near the bottom, under "nice to have," is not.
For most postings that exercise leaves five to eight items. Those are your keywords. Cover each one once, properly, and you have done the job.
Why the list is always shorter than it looks
Long requirement lists are an artefact of how postings get written, not a statement of expectation. Each contributor adds items and almost nobody removes them.
Once you can see which parts came from which author, an eighteen-item list routinely reduces to four that decide the shortlist. Reading a posting by source is the fastest way to do that reduction.
Running the three signals
Take the posting and mark up three things before you write anything:
Position. Anything in the title or the first paragraph. That is the hiring manager's own text and it is the highest-signal part of the document.
Repetition. Anything appearing in two or more places. Multiple contributors independently thought it mattered.
Framing. "Required," "must have," and specific named tools are real. "Familiarity with," "exposure to," and category hedges are not.
Items scoring on two of three signals are your list. In most postings that is five to eight.
What "Covered Properly" Means
One well-evidenced mention beats three scattered ones.
Three shallow mentions: Skills: SQL. Summary: experienced in SQL. Bullet: used SQL daily.
One proper mention: Rebuilt the weekly revenue model in SQL, replacing four manual spreadsheets and cutting reporting time from two days to under an hour.
The second appears once. It is stronger with the scanner - because context-weighted systems credit terms inside described work more than terms in a list - and far stronger with the human, who now knows what you can actually do.
So the count that matters is not mentions. It is requirements covered with evidence.
The three-mention version is worse than it looks
It is not merely weaker. Repeating a term across summary, skills and a duty-statement bullet is one of the patterns that reads as keyword padding, because the repetition is visible and the evidence never arrives.
A reader who sees "SQL" three times and learns nothing about what you built with it concludes the opposite of what the repetition intended.
A Working Structure
For a typical posting, this is enough:
Skills section: eight to fifteen items. The central technical terms from the posting that you genuinely have, grouped so they can be scanned.
Summary: two or three terms. The two most-repeated requirements, named in the posting's language.
Experience bullets: each central term appearing once, inside real work. This is where the weight is.
That produces a resume where every important term from the posting appears once or twice, with evidence, and nothing appears four times.
Where each term should land
| Term type | Skills section | Summary | Experience bullet | Notes |
|---|---|---|---|---|
| Central requirement you evidence well | Yes | Yes, if top two | Yes, with outcome | The only terms worth all three |
| Central requirement, thinner evidence | Yes | No | Yes, stated honestly | Let the bullet set the scale |
| Secondary tool you use daily | Yes | No | Where it happened | Skills list is sufficient |
| Secondary tool, occasional use | Yes | No | No | Do not manufacture a bullet |
| Tool from a cluster ("Tableau/Looker/PBI") | The one you know | No | Where it happened | One is sufficient |
| Acronym with a common long form | Both, once | No | Either form | "SEO (search engine optimisation)" |
| Soft skill named in the posting | Never | Rarely | Demonstrated | Asserted traits get discounted |
| Requirement you genuinely lack | No | No | No | Leave it; decide on fit instead |
| Methodology (Agile, Scrum) | If genuine | No | Where it shaped work | Usually process noise |
| Domain knowledge (fintech, clinical) | If genuine | Yes, if central | In context | Strong differentiator when real |
| Certification the posting requires | Yes, in its own section | If central | No | Needs its own line, with dates |
| Adjacent tool from the same family | Name what you used | No | Where it happened | Do not substitute brands |
The pattern: terms earn placement by how much evidence you have, not by how much the posting wants them.
Where the Ceiling Is
The hard limit is not a number a scanner enforces. It is the interview.
Every term in your skills section is a candidate question. Interviewers pick from that list precisely because it is your own claim about yourself. So the ceiling is: how many terms can you talk about for two minutes each?
For most people that is ten to fifteen technical items. Beyond that you are listing things you have touched rather than things you know, and the marginal scoring gain is bought with interview risk.
The ceiling moves with seniority, in both directions
A fresher's ceiling is lower in absolute terms and that is expected. Six well-evidenced items from coursework and projects read as honest.
A senior candidate's ceiling is higher, but the evidence bar rises faster than the count - a staff engineer listing twenty tools with no systems attached reads worse than a junior doing the same thing, because the reader expects depth where the experience claims it.
What Overshooting Looks Like
Technical Skills: Python, R, Java, Scala, SQL, NoSQL, MongoDB, PostgreSQL, MySQL, Snowflake, Redshift, BigQuery, Databricks, Spark, Hadoop, Kafka, Airflow, dbt, Tableau, Power BI, Looker, Excel, Git, Docker, Kubernetes, AWS, Azure, GCP, Terraform, Jenkins
Thirty items. A few are genuine strengths; most are acquaintances. The reader cannot tell which, so they learn nothing and discount the whole list.
Ten items, ordered with the strongest first, communicates more.
The same candidate, cut to ten
Technical: SQL (advanced), Python (pandas, Airflow), dbt, Snowflake, Tableau, Git Cloud: AWS (Redshift, S3, Lambda)
Seven lines of content, every item defensible, the strongest first. This is the same person - nothing was lost except the items they could not have discussed.
The discipline is not "list less." It is ordering by what this posting asked for and stopping where the evidence stops.
A Second Example: The Career Changer
The count question gets harder when your evidence sits in a different field, so the method needs adjusting.
A teacher moving into instructional design. The posting names curriculum development, stakeholder management, LMS platforms, project management and data-informed iteration.
The instinct is to pad, because the direct evidence looks thin. The better move is to recognise that four of the five requirements describe work already done under other names.
Padded: Skills: instructional design, curriculum development, LMS, Articulate, Captivate, SCORM, xAPI, ADDIE, project management, stakeholder management, data analysis, learning analytics.
Covered: Designed and revised a three-year Key Stage 4 curriculum for 180 students, iterating on assessment data each term to lift attainment from 61% to 74% A*-C. Managed rollout across a six-teacher department and ran termly reporting to senior leadership. Built and maintained all course content in Google Classroom and Moodle.
The second names four of the five requirements with evidence and quietly concedes the fifth. It is a shorter list and a much stronger claim, because transferable work stated in the target field's vocabulary is the whole of what a changer has to offer.
The Better Question
Instead of "how many keywords," ask: for each of this posting's five to eight real requirements, is there a line on my resume that shows I have done it, in words the employer would recognise?
If yes for all of them, you are finished - whatever the count.
If no for some, you have two honest options: name work you did do in the posting's language, or accept the gap and decide whether the application is still worth sending.
That question takes five minutes and produces a better resume than any amount of counting.
Sorting the gaps
Not every gap is the same kind of problem, and the sorting takes a minute:
Vocabulary gaps. You did the work under another name. Rename it - this is most of the list, and adjacent experience usually accounts for more of it than people expect.
Depth gaps. You have touched it but shallowly. State the real extent rather than the term alone, which keeps you on the right side of the line between framing and fabrication.
Genuine gaps. You have not done it. Leave it out, and use it as information about fit rather than something to write around.
The sorting matters because the three categories need completely different responses. A vocabulary gap is a ten-second rename. A depth gap needs one honest sentence about the real extent. A genuine gap is not a writing problem at all - it is information telling you whether this application is worth sending, and treating it as something to phrase around is how people end up with claims they cannot defend at interview.
Most people find the first category is the largest by some distance. A typical missing list of nine terms sorts into roughly five renames, three depth statements, and one real gap. That is why the list looks alarming and turns out to be an hour of work rather than a reason not to apply.
Edge Cases
The posting lists twenty requirements and means it
Rare, but it happens in regulated and highly specified roles. The tell is specificity throughout - named frameworks, named standards, named systems, no generic filler.
Here the list really is the job. If you match half, the honest read is that this is a stretch, and no amount of keyword work changes that.
You are applying to the same company for several roles
Keep coverage consistent across the applications. Recruiters at one company do compare, and a skills list that changes shape between two submissions in a fortnight is noticeable.
Cover each posting's real requirements from the same honest base rather than assembling a new list each time - which is also why managing resume versions matters more than it seems.
The role is at a startup with no formal process
Smaller companies frequently have no ranking stage; a founder reads every application. Keyword count is close to irrelevant and evidence is everything.
Write for the human and the machine question resolves itself.
Your strongest term is one the posting never mentions
Keep it if it differentiates you and it is genuinely relevant to the work. Coverage is about ensuring the posting's terms are present, not about deleting everything else.
What to cut is the irrelevant, not the unmentioned.
Common Mistakes
Mistakes about what to count
Treating the missing list as a shopping list. A scan tells you what is absent, not what belongs. A good proportion of any missing list is terms worth ignoring.
Counting mentions instead of covered requirements. Three shallow mentions of one term is worse than one evidenced mention, on both sides of the screen.
Ignoring whether the terms arrived at all. A term placed in a header, a text box or a sidebar frame can vanish during extraction, and the copy-paste test is the only way to see it. Counting keywords on a page that does not parse is wasted effort.
Mistakes about placement and stopping
Adding terms to the skills list because it is the easiest place. It is also the weakest, and the place interviewers pick questions from.
Letting the list grow across applications without ever pruning. Skills sections accumulate. Review yours every few months against what you could actually defend today.
Chasing a number past the point of return. Once the score is workable, further keyword work returns almost nothing while your bullets still have a lot of room. Past that point the deciding factor is recruiter judgment rather than the score, and that stage reads evidence rather than counting terms.
Assuming more terms means more searches. It means more searches surfacing a resume that then converts worse, because the reader cannot tell what you are for.
Frequently Asked Questions
Is there a keyword density target for resumes?
No. Density is an SEO idea that does not transfer - resumes are read by a human after the scan, and density optimisation is visible to them.
Should I repeat the most important keyword several times?
Once in the skills section and once inside an achievement is enough. A third mention adds little and starts to read oddly.
What if a posting has twenty genuine-looking requirements?
It almost certainly does not. Long lists are usually assembled by several contributors. Apply the position, repetition and framing test and the real list shortens considerably.
Do I need every keyword to get past the scanner?
No. Scanners rank rather than demand completeness. Covering the central requirements well outperforms covering everything thinly.
Should my skills list be long if I am genuinely multi-skilled?
List the ones relevant to this posting. A focused ten tells the reader what you are for; an unfocused thirty tells them nothing.
How many keywords should be in my summary specifically?
Two or three, drawn from the posting's most repeated requirements. The summary is high-visibility and low-credibility, so it should frame rather than enumerate - the principles in matching your summary to a posting apply directly.
Does the count differ for a one-page versus two-page resume?
Not meaningfully. Page count changes how much evidence you can show, not how many of the posting's requirements are real. The requirement list is set by the posting, not by your layout.
What if two postings for the same role want different terms?
Cover each one separately at the vocabulary level - that is the per-application work. Your underlying evidence does not change, only which words name it.
Should certifications count toward the keyword total?
Treat them separately. A certification is a credential with a date and an issuer, and it belongs in its own section rather than padding a skills line.
Is it worth adding keywords for a role I am underqualified for?
No. Keyword work cannot close an experience gap, and a well-covered resume for a role you plainly do not fit still fails at the human stage. Spend the time on better-matched postings.
Check Coverage Against a Real Posting
The count matters less than whether your five to eight central requirements each have evidence behind them.
Scan your resume against a posting and look at which central terms come back missing - that list is usually short, and shorter still once you discard the ones you cannot honestly claim.
Then work through the claimable ones by rewriting the bullet where that work already sits. If you would rather see the rewrite drafted against the posting's own wording first, the tailoring tool starts from the same comparison.
Free, about a minute. Related: where to place keywords so they count and keyword stuffing versus coverage.
See which keywords you are missing
Scan your resume against the posting and get the exact terms it did not find.
Drop your resume here or choose a file
PDF only. Max 2 MB.
We never share your data or use it to train AI models.
Where those keywords actually go
A layout with a real skills section gives the parser somewhere clean to find every term you just added.
Was this guide useful?
Be the first to rate it.
