The ATS résumé checklist: once, per application, and before you send

This is the working checklist that the rest of our guides explain — every item sorted by when it happens: structural work you do once, alignment work you redo per application, and a two-minute pass before each send. If an item's reasoning isn't obvious, the link next to it goes to the full explanation. Nothing here predicts an outcome; every item removes a specific, mechanical risk.

Part 1 — once: make the file parse (the skeleton)

These are properties of the document. Fix them once and they hold until you change the layout. (Full reasoning per item.)

• Single column, top to bottom — parsers read one stream; side-by-side content can interleave.
• No tables holding content — cell storage order scrambles reading order (real broken output).
• Name and contact details as plain body text, first lines of page one — never in the Word header/footer.
• Standard section headings — "Experience", "Education", "Skills" are the anchors field mapping needs.
• Selectable text everywhere — the cursor test; no scanned pages, no text baked into graphics.
• Plain bullets, standard fonts, no icon labels — glyph-level failures are quiet but real.
• Exported .docx or text-based PDF — the format choice matters less than the export path.

Part 2 — per application: make the words match (the language)

These reset with every posting, because the posting is the best proxy for what its recruiter will search.

• Compare vocabularies — your résumé's actual words against this posting's, hard skills first.
• Add what is true and missing — in the entry where you used it, in the posting's spelling ("e-commerce" vs "ecommerce" is a real miss).
• Name tools by their names — "a leading BI tool" does not contain "Tableau".
• Skip what is not true of you — a surfaced lie is an interview you cannot back up; a large true gap is targeting information.

Part 3 — before you send: the two-minute final pass

• Filename — firstname-lastname-resume.pdf beats resume_final_v7 (2).pdf; a human sees it in a list.
• Fresh export — re-export after edits; don't send the stale file from your downloads folder.
• One parse view — if anything structural changed since the last check, look at the extraction once: text order, contact fields found, sections recognized.
• Form fields over hope — where the application form asks you to type your history, fill it; it is the one data path parsing cannot damage.

What is deliberately not on this list

No white-text keywords, no keyword density targets, no "ATS-certified" template purchases, no score thresholds — the reasoning for each exclusion is in the myths guide. Short version: parsers read hidden text out loud, humans read whatever surfaces, no cross-vendor certification exists, and the scores were invented by whoever printed them.