ATS guides
Reading order: why a two-column CV can scramble
This is the failure nobody sees, because there is nothing to see. The PDF renders exactly as designed, the applicant sends it with confidence, and the text that reaches the database has a skills list spliced through the middle of every job. Appliora weights Reading order at 14 of 100 - the heaviest single check in the model - and caps the whole report at 69 when the scrambling is critical.
A PDF has no reading order until something invents one
The format stores glyphs and where to draw them. Paragraphs, columns and sections are not in the file; they are inferred afterwards.
When you place a sidebar on the left and your experience on the right, you have not told the file that one is a sidebar. You have placed two sets of glyphs at two ranges of x coordinates. Whatever reads the file later has to decide whether the page is one column read top to bottom, or two columns read one after the other, or something else entirely - and different extractors decide differently on the same file.
The common wrong answer is to read by vertical position: take everything on the topmost baseline, then the next, and so on. On a single-column page that is correct. On a two-column page it produces a line of your summary, then a line of your skills, then the next line of your summary, alternating all the way down. The words are all present. The sentences are gone.
The second common failure is narrower and sneakier: a right-aligned date band. Dates that sit in a column of their own, level with the role they belong to, get resolved inconsistently. One extractor glues the date onto the end of the title, producing something like "Marketing Manager2024 - 2027"; another detaches every date and parks them together after the last entry. Neither leaves a date attached to its role, which is the only thing a date on a CV is for. That damage lands on Consistent dates (7 points) as well.
What it costs, in published points
Reading order is scored on its own and it also gates the report, which is unusual and deliberate.
| Check | Weight | Why a scrambled layout hurts it |
|---|---|---|
| Reading order | 14 points | Measured directly: column detection, fused tokens, detached date bands. |
| Bullet quality | 13 points | Bullet length, action verbs and passive voice are all measured on extracted text. Interleaved lines are not the bullets you wrote. |
| Recognised sections | 10 points | A heading fused with a sidebar item stops matching the heading dictionary, so a section you clearly have reads as missing. |
| Consistent dates | 7 points | A date that detaches from its role cannot be checked for consistency or for gaps against anything. |
| Concrete skills | 8 points | A skills column split across the gutter arrives as fragments rather than as skills. |
Only the first row is charged to reading order. The other four are charged to themselves, on text the layout has already corrupted - which is why the cap at 69 exists.
The cap has a measured origin. A two-column test file scored 91 out of 100 before it was introduced: the content checks were all reporting on text with the sidebar spliced through the middle of every summary sentence, and 86 of those 100 points described a document that does not survive parsing. 69 is the top of the readable-but-leaking band, which is the literal situation - the words arrive, the order does not.
The cap is also generous with information, unlike the text-layer gate. Every check still runs and still reports, because every finding is still actionable, and the columns finding recomputes its own "points if fixed" to include the lifted cap. Fixing the layout visibly pays back everything it costs.
How to test your own file in two minutes
You do not need a tool for the first pass. You need a text editor.
- Open your CV in any PDF viewer. Select all, copy.
- Paste into a plain text editor - anything that will not re-flow the result.
- Read the first twenty lines. Your name and contact details should arrive together, not split by a heading from the other column.
- Find a job title. The lines under it should be that job's bullets, uninterrupted.
- Search for a date. It should sit next to the role it belongs to, with a space before it and nothing fused onto it.
If any of those fail, the layout is leaking. The free checker does the same extraction and shows you the result directly, with the specific lines it thinks were fused or interleaved, which is faster than reading a paste by eye. Either way, the thing to trust is the extracted text, not the rendered page.
When two columns are safe
The rule is about what crosses the gutter, not about the number of columns.
- Safe: a sidebar carrying self-contained blocks - contact details, a skills list, languages - with a clear vertical gap and nothing spanning it.
- Safe: a full-width experience section under a two-column header. The header is short, and a short interleave at the top is recoverable.
- Risky: a sidebar whose blocks start and end level with paragraphs in the main column, so every sidebar line has a body line to interleave with.
- Risky: a gutter that does not straddle the page centre. Column detection that assumes a mid-page split misses an asymmetric layout entirely, and Appliora's detector was rewritten specifically because a real CV with an off-centre gutter scored a clean 100 on reading order while its extracted text was interleaved.
- Avoid: content flowing from the bottom of one column to the top of the other. A human follows that; a parser reading by position does not.
If you want the design without the risk, the practical move is to keep the two-column look in the top third of page one and run the experience full width. You keep the visual identity where a reader looks first and remove the interleave from the part of the document that carries the most text. Appliora's template categories mark which layouts do this.
The related failure: contact details in the page margin
Not a reading-order problem, but it comes from the same place and it is scored separately.
A header or footer that repeats your name, email and phone on every page looks tidy and is one of the more damaging habits available. Several applicant tracking products strip the header and footer band before parsing, on the reasonable assumption that it holds page numbers. Your application then lands in the database with no way to reach you, and you never learn why nobody called.
Appliora scores Contact details (8 points) on reachability rather than presence. A detail found only in the header or footer band scores half of what it would score in the body, and the finding is marked critical. The fix takes one minute: put email and phone in the body text of page one, and leave the footer for the page number if you want one at all.
A note on DOCX
One more caveat worth stating plainly: everything above describes Appliora's parser, measured on files run through Appliora's checker. Nobody outside a given vendor can tell you exactly how that vendor's extractor resolves a two-column page. What is safe to say is that the reconstruction problem is universal, because it is a property of the PDF format rather than of any product.
Questions people ask
How do I check my own CV's reading order without any tool?
Open the PDF in a viewer, select all the text, copy it and paste it into a plain text editor. What you see pasted is roughly what a parser receives. If your job titles are interrupted by items from a sidebar, or a date has fused onto the end of a heading, the reading order is not what you designed.
Are two-column CVs always a problem?
No. The failure is content interleaving across the gutter, not the presence of two columns. A sidebar holding whole self-contained blocks, with a clear vertical gap and nothing spanning the divide, usually extracts in a sensible order. A layout where a summary paragraph and a skills list share the same horizontal lines is the one that scrambles.
Why does reading order carry more weight than the text layer?
Because a missing text layer is obvious once anyone checks, and a scrambled reading order is invisible. The file looks perfect on screen, the applicant has no reason to suspect anything, and the damage falls on every content check at once. Reading order is worth 14 points and it also caps the overall report at 69 when the scrambling is critical.
My CV scored well on everything except reading order. Is that possible?
It is possible and it is misleading, which is why the cap exists. Before the cap was added a two-column test file scored 91, with 86 of those points describing content measured on text that arrives in the wrong arrangement. The cap holds the headline number down while leaving every finding visible.
Does a DOCX have a reading order problem too?
It has a different one. Appliora cannot measure reading order on a DOCX at all, because the check needs per-glyph coordinates and a DOCX has no page geometry. The check is reported as unavailable rather than scored as zero, and its weight is redistributed across the checks that could be measured.
See what a parser reads from your CV
Upload your current file and get the extracted text plus a 0-100 score across 14 checks. No signup.