How to find the ATS keywords in any job description

When an ATS scores your CV, it is not reading for narrative. It is counting keyword matches against the job description and weighting them by importance. The candidates who appear at the top of the recruiter's queue are not necessarily the best qualified — they are the ones whose CVs contain the right tokens in the right frequency.

This creates a specific, solvable problem: how do you identify which keywords the ATS is actually weighting, and how do you add them without making your CV unreadable or dishonest?

This guide covers both questions.

Why JD keywords matter — and why not all of them are equal

Every job description contains dozens of words, but not all of them influence your ATS score. The system gives most of its weight to a small set of terms that signal role fitness, and gives very little weight to the surrounding language.

The distinction matters because candidates who try to match every word in a job description — including the generic corporate language — waste space and risk keyword stuffing. The ones who correctly identify the high-signal terms and work them naturally into their bullets and skills section are the ones who score well.

What separates a high-signal keyword from a low-signal one?

Specificity. A rare or specific term carries more signal than a common one. "Kubernetes" is more specific than "cloud infrastructure." "dbt" is more specific than "data tooling." Specific terms appear in fewer CVs, so their presence is a stronger match signal. Common adjectives like "collaborative," "proactive," and "detail-oriented" are nearly universal and contribute almost nothing to your score.

Position in the JD. Keywords that appear in the job title, the first paragraph of the description, or explicitly in a "Requirements" or "Must have" section receive higher weight in most ATS scoring models. A skill buried in a "Nice to have" list is still worth including if you have it, but it will not move your score as much as a requirement mentioned in the opening paragraph and repeated in the responsibilities list.

Frequency. A keyword that appears three times in a JD — once in the title, once in the requirements, once in the responsibilities — is weighted higher than a keyword that appears once. The ATS parser reads this repetition as an editorial signal about importance. This is also a clue about what to surface in multiple places in your own CV: if "stakeholder management" appears four times in the JD, mentioning it once in your summary and once in your bullets is appropriate. Mentioning it six times is not.

The three keyword types

Job description keywords fall into three categories. Recognising which type each keyword belongs to tells you where to use it in your CV and how prominently to feature it.

Type 1 — Hard skills and technologies. Specific, often testable competencies: programming languages, tools, platforms, methodologies, certifications. These carry the highest ATS weight because they are unambiguous and the most reliable signal of role fit. A data engineering role that requires "Apache Spark, dbt, Snowflake" is looking for those specific tokens. No amount of flowery prose about data transformation will substitute for their presence.

Type 2 — Role and title terms. Terms related to the function itself: "product roadmap," "sprint planning," "stakeholder management," "P&L ownership," "go-to-market." These are not specific tools but they signal role seniority and scope. Candidates who have held similar roles use this vocabulary naturally; candidates who are stretching into a new role often miss it. ATS systems weight these terms at the section level — they are extracted from experience bullets and matched against the job requirements, not just the skills section.

Type 3 — Domain and methodology terms. Industry, domain, and methodology vocabulary: "B2B SaaS," "agile," "GDPR compliance," "regulated financial services," "consumer growth." These are lower weight individually but their presence signals that you understand the context of the role. They also contribute to semantic matching if the platform uses it. A candidate applying to a fintech role whose CV never mentions financial services will score below a candidate with equivalent skills whose CV does.

The table below illustrates all three types with examples from two sample roles:

For any given role, you are looking to populate all three columns. The hard skills are non-negotiable; the role and domain terms give the ATS the contextual signal it needs to rank you as a strong fit rather than a generic match.

Manual extraction in five minutes

You do not need a tool to extract the important keywords from a job description. The following method takes about five minutes and works reliably.

Step 1 — Copy the full JD text into a plain document. Do not work from the web page. Copy everything: job title, responsibilities, requirements, nice-to-haves, and the company description paragraph. You want the complete text.

Step 2 — Highlight the job title and opening paragraph separately. Keywords here receive the highest weight. Note every specific term — not adjectives, not vague nouns, but specific role vocabulary and technology names.

Step 3 — Go through the requirements and must-haves line by line. For each line, ask: is this a specific, testable competency (Type 1), a role-level term (Type 2), or a domain/industry term (Type 3)? Categorise as you go. Skip generic phrases like "strong communication skills" and "self-starter" — they will not move your score.

Step 4 — Scan the responsibilities section for repetition. Any term that appears more than once across the full JD is worth noting as higher-priority. Terms that appear only in the "nice to have" list and nowhere else are lower priority.

Step 5 — Build a three-column shortlist. Organise your extracted terms by type. You should end up with roughly 5–10 hard skills, 5–8 role terms, and 3–5 domain terms for a typical professional role. If your shortlist is longer, rank within each column: which terms appeared most frequently and earliest in the JD?

Here is what this looks like for a sample JD snippet:

"We are looking for a Senior Data Engineer to join our platform team. You will design and maintain scalable data pipelines using Python, Apache Spark, and dbt, and work closely with analytics engineers to support Snowflake-based reporting. Experience with Airflow or a similar orchestration tool is required. You will operate in an agile environment and must have strong understanding of data modelling, schema design, and data governance best practices. Fintech or regulated financial services experience is a plus."

From this paragraph alone:

Those fifteen terms are the core of what the ATS is matching against. Your CV should contain all the Type 1 terms you genuinely have experience with, and the relevant Type 2 and Type 3 terms in context, not just in a skills list.

Automated extraction — and how RecastCV does it

Manual extraction is reliable but slow when you are applying to multiple roles. Automated keyword extraction speeds this up, but the quality of the output depends on how the tool approaches the problem.

The naive approach — counting word frequency and removing stop words — produces a list dominated by the role's general vocabulary rather than its specific requirements. "Experience," "team," "role," "work," and "manage" will all appear near the top. These are useless for CV matching.

A better approach uses the JD's structure. The requirements section is parsed separately from the responsibilities section and the company description. Terms in the requirements section are weighted higher. Named entity recognition identifies technologies, tool names, and certification terms that a simple frequency count would not distinguish from generic nouns. The output is a ranked list of role-specific, high-signal terms rather than a word cloud.

RecastCV's keyword extraction works by fetching the JD from its URL and identifying the high-signal terms using the structural and NLP approach above. It then compares those terms against your CV text and shows you the gap: which required terms are absent or underweighted, which are present but only mentioned once, and which are well-covered. This comparison drives the tailoring step — the AI rewrites your bullets to incorporate the missing terms in context, grounded in the actual experience in your master CV rather than invented.

The tailored CV feature and the ATS CV checker both use this extraction model. The checker lets you audit an existing CV against any JD; the tailoring feature uses the extracted keywords to drive the rewrite. If you want to understand what the checker is looking for, how ATS parsers actually work explains the underlying matching mechanisms in detail.

How many keywords is too many

Keyword stuffing is a real problem and a counterproductive one. It refers to the practice of loading a CV with keywords in a way that defeats natural readability — inserting terms that do not fit the surrounding context, repeating the same term five times, or adding a hidden white-text block of keywords at the bottom of the document (a tactic that used to work in 2008 and now actively triggers spam flags in modern ATS platforms).

The line between good keyword coverage and stuffing is less blurry than most guides suggest. There are two clear tests:

The human reading test. Read your CV out loud. If a sentence sounds like it was written by someone assembling a list of terms rather than describing what they did, it has probably been over-optimised. "Stakeholder management across cross-functional teams using agile methodologies in a B2B SaaS environment" is jargon soup. "Coordinated roadmap planning with five engineering and design leads across two time zones" is a real sentence that still contains the relevant terms.

The repetition test. Each keyword should appear in your CV at most two or three times, across different sections. A term in your skills list, mentioned once in a bullet, and referenced in your summary is appropriate coverage. The same term in every bullet in your experience section is stuffing. ATS systems in 2026 do flag repetition anomalies, and human recruiters who read CVs past the ATS stage immediately notice when every sentence contains the same set of terms.

The practical target is full coverage of your Type 1 hard skills shortlist (every technology or method you genuinely have experience with), selective coverage of Type 2 role terms (in the sections where they arise naturally — experience bullets, summary), and light coverage of Type 3 domain terms (summary, one or two bullets where they fit). Missing a Type 3 term rarely sinks a strong application. Missing several Type 1 terms that the JD marks as required will.

A final note on honesty: keywords you add to your CV should represent experience you actually have. Adding "Kubernetes" to your skills because the JD requires it when you have no meaningful Kubernetes experience is a bad strategy for two reasons. First, many employers test technical claims in interviews. Second, even if you pass the initial screen, a role that requires skills you lack will be uncomfortable to do. The goal of keyword matching is to make your genuine experience legible to the ATS — not to manufacture qualifications you do not have. For the ATS resume format rules that govern how those keywords are parsed once they are in your CV, the companion post has the full list.