What makes a CV ATS-friendly

ATS-friendly is a property of the file, not a look

An applicant tracking system stores applications and searches them. Before it can do either it has to convert your document into text and guess at its structure.

Everything that goes wrong goes wrong in that conversion. The PDF on your screen is a set of glyphs with coordinates; it does not contain paragraphs, columns or sections, and it has no opinion about which of two side-by-side blocks comes first. A parser reconstructs all of that. When the reconstruction is wrong, nothing on your screen changes - the file still looks exactly as you designed it - and the version that reaches the database is a different document.

So "ATS-friendly" is not a style. It is a list of properties, each of which either survives extraction or does not. A sidebar is fine if the parser can tell it is a sidebar. A table is fine if its cells read in the order you meant. Colour is irrelevant. A scanned page is fatal. The useful version of this advice ranks those properties by how much damage each one does, which is exactly what a published scoring model is for.

If you have never seen your own CV as a parser sees it, the fastest route is to run it through the free checker and read the extracted text panel before you read the score. Everything below will make more sense against your own file.

What each property is worth

Appliora scores 14 checks in four groups. The weights sum to 100, so the table adds up by hand and a change to one is visibly a redistribution rather than a quiet inflation.

Model version 4.5. The version changes whenever a weight, a threshold or a check moves, which is what makes two runs of the same file comparable.

Two things in that table are worth arguing with, because they are not what the folklore predicts. The single heaviest check is Reading order (14 points), not a keyword count. And the content group carries 30 of the 100, more than machine readability does - what the CV actually says is where most of the recoverable points live, once the document parses at all.

There is no check called "keywords". That is deliberate and it is covered in the keywords guide: the terms an advert cares about are scored where they appear, inside Concrete skills (8 points) and Bullet quality (13 points), rather than counted in a bag.

Fix them in this order

Two of the checks do not merely cost points. They cap the whole report, which makes them the only sensible place to start.

1. A real text layer. A file with no extractable text caps the report at 25 out of 100, because every other check would be measuring the absence of input rather than the quality of a CV. This is the failure mode of a scan, a photograph, or a page exported as an image. What a text layer is, and how to test yours.
2. Reading order. A critically scrambled layout caps the report at 69. The words arrive; the order does not. Unlike the text-layer cap, every other check still runs and still reports, because the findings remain actionable - only the headline number is held down. Why a two-column CV can scramble.
3. Structure. Recognised sections (10 points) and Contact details (8 points) are worth 18 between them and are usually the cheapest points on the page to recover: rename a heading, move an email out of the page footer. Headings a parser recognises.
4. Content. Bullet quality (13 points) is the heaviest check after reading order. It measures quantification, action verbs, passive voice and bullet length, not keyword density.
5. Hygiene. Format traps (6 points), File hygiene (3 points) and the rest. Small individually, cheap to fix, and they are the difference between a good score and a clean one.

The short version

If you read nothing else on this site, this is the list.

• Export from the source document. Never scan, never photograph, never "save as image".
• One reliable reading order. If you keep a sidebar, keep whole sections in it rather than splitting a sentence across the gutter.
• Email and phone in the body of page one, not in the header or footer band. Several systems strip those before parsing.
• Section headings a dictionary would recognise: Experience, Education, Skills, Summary.
• Consistent date formats, one style throughout, attached to the role they belong to.
• Skills written as words, never as filled circles, stars or bars.
• Fonts embedded on export.
• A filename carrying your actual surname.
• Send the format the advert asks for. If it does not ask, both are fine and the trade-offs are real.

Rules that are not rules

Four pieces of standard advice that cost people good CVs for no measurable gain.

• "Use a plain single-column template or you will be filtered out"

  Two columns are a risk, not a disqualification, and the risk is specific: content that interleaves across the gutter. A sidebar holding contact details and a skills list, with the experience running full width, extracts cleanly in Appliora's parser. The reading-order guide shows how to check your own file rather than guessing.

• "Never use a photo"

  In Poland and Czechia a photo is entirely normal and its absence is the unusual choice. Appliora reports a photo so you know it was detected, and charges nothing for it: the Personal details check is worth 3 points and a photo costs zero of them. A check cannot tell you a photo is conventional and take points for it in the same breath.

• "Repeat the job title from the advert as often as possible"

  Appliora's skills check treats a list beyond about 40 entries as stuffing rather than as coverage, and a term repeated in a keyword block scores worse than the same term used once inside a bullet that proves it. See how to write a skills section.

• "One page, always"

  Appliora scores length against experience, not against a fixed ideal. Under 3 years the expectation is one page; up to 10 years one or two; beyond that, two. Both directions are errors - see one page or two.

What this measurement is and is not

Questions people ask

Is there an ATS-friendly font?

Not in the sense the advice usually means. A parser reads the characters a font encodes, not its shape, so Calibri and Garamond extract identically. What does matter is whether the font is embedded in the PDF, because a font the recipient does not have is re-rendered with a substitute and the spacing can break. That is one of the things the Format traps check looks for.

Does a CV have to be black and white to be ATS-friendly?

No. Colour is a property of how the page is drawn, not of the text layer underneath it, and Appliora's parser recovers the same words from a navy heading as from a black one. Colour becomes a problem only when it replaces text, for example when a skill level is shown as five filled circles and nothing else.

Which single change usually gains the most points?

Reading order, because it carries 14 of the 100 points and because a critically scrambled layout also caps the whole report at 69. A CV that is losing points everywhere in the content dimensions is often losing them because the content was extracted in the wrong order in the first place.

Can a CV be ATS-friendly and still look designed?

Yes. Every property that matters here is about what a parser can recover: a real text layer, a single reliable reading order, headings it recognises, contact details in the body rather than the page margin. None of those forbid a colour, a rule, a sidebar that carries only skills, or generous spacing.

Does Appliora tell me what a specific employer's system will do?

No, and neither can anyone else outside those companies. Appliora reports how its own parser reads your file and flags the failures that are common across systems. Treat the result as a readability measurement of your document, not as a prediction about one employer's software.