How Recruiters Search the Parsed Record
Once your document has been parsed, it exists as a row in a database with a set of fields and a searchable copy of its text. Much of what happens next is not an automated verdict on your application but a person typing a query — often for a different job, weeks or months later. Understanding what that query can and cannot match explains why some formatting choices matter long after you have forgotten you applied.
Two things get stored, and they behave differently
Structured fields. Location, current title, normalised title, total experience, education level, extracted skills, dates. These support exact filters and ranges: education_level >= bachelor, experience_years >= 5, location within 40 km of Columbus. A field that is empty because extraction failed does not match anything, and it does not match “unknown” either — it is simply absent from the result set.
Full text. A copy of the extracted text, indexed for keyword search. This is where a query for an exact phrase runs, and it is more forgiving than the fields, because it does not depend on your document having been correctly sectioned. A skill named in an experience bullet is findable in full text even if the parser never filed it as a skill.
That difference is the reason the same term is worth having in both places. The skills list feeds the field. The bullet feeds the text index and gives a human the context.
What a query looks like
Recruiter search is usually boolean, and usually simpler than people imagine:
("registered nurse" OR RN) AND (paediatric OR pediatric) AND "Ohio"title:("data analyst" OR "business analyst") AND SQL AND (Tableau OR "Power BI")A few properties of that follow directly:
- It is literal.
"Power BI"does not matchPowerBIunless the index normalises punctuation, and it may not. This is the whole argument of acronyms, synonyms, and spelling variants. ANDis unforgiving. FourANDterms means all four must appear. A candidate missing one is not ranked lower; they are absent.- The recruiter chose the terms. They came from a job description, a hiring manager’s phrasing, or habit. There is no guarantee they are the terms your industry uses, and no mechanism by which a mismatch gets noticed.
- Phrase order matters for quoted strings.
"project management"does not matchmanagement of projects.
The delayed search is the one people forget
The application you submitted today gets looked at on its own terms. But your parsed record does not expire when that role is filled. It sits in the employer’s database and appears in future searches — for a similar role, for a role in another team, when a recruiter is filling a pipeline.
This is why a parsing error is worth fixing even after you have been rejected somewhere: the same broken record will keep failing the same query. And it is why the mundane fields matter more than they seem. A record with an empty location and no dates is functionally invisible to filtered search forever, even though the human who read your PDF in July thought you were fine.
It also means you cannot rely on a cover letter or a form free-text box to carry a qualification. Those are read once, by one person, in one context. The parsed record is what gets queried later.
Why “keyword match” is not the same as “keyword count”
Search matches on presence, again. A term appearing once satisfies a query exactly as well as a term appearing nine times. Where multiple mentions can help is ranking within a large result set, if the index uses a relevance score — and standard text relevance scoring also penalises long documents and gives diminishing weight to repeats, so padding is not a reliable lever even there. This is expanded in keyword density is not what parsers measure.
The reliable lever is coverage: does each true, relevant term appear at all, in the form someone would search for.
What the recruiter sees in the result list
A search result is usually not your PDF. It is a row: name, current title, location, experience, and a snippet — often a fragment of the extracted text with the matched terms highlighted.
Three implications worth acting on.
The snippet is machine text, not your design. It shows the extracted stream, which is why a shredded two-column layout produces a result row that reads like nonsense even though your document is elegant. See why your two-column resume breaks.
Anything hidden in the document shows up here in plain view. White-on-white keyword blocks, tiny-font term lists, and stuffed metadata are all extracted text, and this is the interface where extracted text is displayed to a person. The tactic is not merely ineffective; the search results screen is precisely where it gets caught.
The top of your document does disproportionate work, because snippets and preview panes tend to draw from early text. That is an argument for a plain, informative first few lines — name, location, current title, a summary that says something — rather than for a decorative banner.
Fields that are frequently used as filters
Not exhaustive, and configuration varies by employer, but these are the common ones. Each is worth a moment’s audit:
| Filter | Depends on |
|---|---|
| Location / radius | A recognisable City, Region in the contact block |
| Years of experience | Every job entry having correctly attached dates |
| Current title | The most recent entry parsing as the most recent |
| Education level | A credential word in the education block |
| Skill present | The skill name existing as extractable text |
| Licence / certification | A named credential under a recognisable heading |
| Last activity | Nothing you control |
Each row is covered in its own post on this site; the point of the table is that all six of the controllable ones are formatting outcomes, not writing outcomes.
What search cannot do for you
It cannot infer. It does not know that six years at a payments company implies familiarity with card networks, that your Coordinator title involved managing a team, or that the tool you named is a competitor of the one in the query. A query is a set of strings, and it matches strings.
That is not a reason to despair; it is a reason to be explicit. Every implicit qualification in your resume is one a search will miss, and making it explicit is usually a matter of naming a thing you already did. It is never a reason to name something you did not do — an inference the software cannot make is not an invitation to assert it.
Check it
Take a job posting you would be a strong candidate for, and write the boolean query you think a recruiter would run for it: three or four AND terms, in the posting’s own words. Then search for each term in the plain-text copy of your resume.
If a term is missing and the underlying experience is real, that is a gap to close honestly. If a term is missing and the experience is not real, that is a role to skip. The query is a diagnostic, not a target.