Two lines at the top of your CV carry more weight than their word count suggests. A phone number that parses badly means the recruiter who wants to call you cannot, and a location string that parses badly means the search that would have surfaced you never returns your record at all. Neither failure has anything to do with how well you write.
The two fields work in completely different ways
It helps to know that an applicant tracking system handles these two pieces of text with different machinery.
A phone number is found by pattern matching. The parser scans the text layer of your document for a run of digits of plausible length, optionally preceded by a plus sign and a country code, with a small set of accepted separators between groups. If the run matches, it goes into the phone field. If it does not match, nothing goes in, and there is usually no warning.
A location is resolved by lookup. The parser takes your string and tries to match it against a list of known places, then attaches a set of coordinates to your record. That resolved point, not your words, is what a radius filter later queries.
So a phone number fails when the characters around the digits are wrong. A location fails when the place name cannot be found. Different problems, different fixes.
Six ways a phone number gets mangled
The plus sign and the optional zero
Local convention in several countries is to write the international prefix with the trunk zero in parentheses, as in +33 (0)6 12 34 56 78. This is correct typography and a parsing hazard. Some parsers strip every non-digit character and keep the zero, producing a ten-digit national number welded onto a country code. The result dials nowhere.
Pick one form and commit to it. Either the full international form with no parenthesised zero, or the plain national form with no country code at all. Never the hybrid.
Wide spacing read as a column break
PDF text extraction does not see lines, it sees glyphs with coordinates, and it reconstructs lines by looking at horizontal gaps. A gap above a threshold is treated as a column boundary. If your contact block is spread across the page width with tabs or generous letter spacing, a single number can be split into two fragments that end up on two reconstructed lines. Half a number matches no pattern.
Single spaces between groups. No tabs inside the number. No justified alignment on the contact block.
The number lives outside the body text
A phone number placed in the header or footer of a Word document sits in a separate part of the file, and plenty of parsers only read the main body stream. The same is true of a number inside a text box or a shape in a two-column template: the content is anchored to a position rather than sitting in the document flow. We have written separately about why headers and footers get skipped, and the phone number is the single field that suffers most from it.
Put your contact details in the first lines of the body. Not in a sidebar, not in a decorative band.
Invisible characters
Non-breaking spaces, soft hyphens, zero-width characters picked up when you pasted the number from a web page, and the typographic dash a template designer used instead of a hyphen. To your eye the number is fine. To the pattern matcher the separator is not an accepted one, so either the match fails or the whole run is swallowed as a single unrecognised token.
Retype the number by hand in a plain text editor, then paste the retyped version. Never paste a number straight from a browser or a signature block.
The number welded to the next field
A contact line that reads as one continuous string, with a vertical bar or a bullet glyph between fields and no spaces, gives the parser a token that is part phone and part email address. Sometimes the phone survives and the email is lost. Sometimes it is the reverse.
One field per line is the least elegant and most reliable arrangement.
Truncation and extra words
Target fields in an applicant tracking system have character limits, and a parser that captures more text than the field accepts will cut the end off. A line like "Mobile, evenings and weekends only: +33 6 12 34 56 78" invites that. Extensions are another common loss.
The safe format is one number, on its own line, in the body, in digits separated by single spaces, with an explicit country code and no parenthesised zero. A short label such as Phone or Mobile before it is harmless and sometimes helps field assignment.
The location field is a filter input, not decoration
This is the half that changes outcomes. Your location is indexed and queried. In most recruiting workflows a geographic filter is applied before anyone reads a word of your experience, which makes it one of the earliest points at which you can be removed from consideration without a human decision.
Why a metro area usually beats a street address
A full street address resolves to a precise point. That point tells a screener exactly how far you would commute, which is information you have volunteered and cannot take back. It also adds several lines of text to the block most likely to be confused with your name. And it buys you nothing, because no recruiter searches for a street.
A metro area name resolves cleanly, sits comfortably inside almost any radius drawn around jobs in that metro, and reads as normal to a human. City plus country is the sensible default for anything international, because same-named cities are common and a bare city name can resolve to the wrong continent.
There is a real exception. Some public-sector and regulated employers ask for a complete postal address as part of the formal application. Give it to them in the form, and keep the CV line as the city.
Relocating and remote, where people lose the most
The instinctive move is to replace the location with an intention. "Open to relocation" and "Remote" are both statements about the future, and neither is a place. Neither resolves to coordinates. Your record becomes location-null, and a location-null record drops out of every radius filter, including ones for jobs you would happily take.
Put a real current city in the location field. Then say the rest in words somewhere it can be read: a single line under your name such as "Relocating to Berlin, available from March", or the relocation checkbox in the application form, which in most systems feeds a separate flag that the recruiter actually filters on. The form field beats the CV line here, so fill the form.
The location that quietly filters you out
Three patterns cost people interviews, and they are all self-inflicted.
- The village name. You live forty minutes outside the city, you commute in every day, and your CV says the name of a place with four thousand residents. A search for candidates within twenty-five kilometres of the centre will not return you.
- The stale location. You moved six months ago and updated your LinkedIn but not your CV. The parser believes the CV.
- The double location. "London and Dubai" resolves to one of them, or to neither, depending on the parser. You cannot control which.
The counter-move is to name the metro anchor you are genuinely reachable from and stop there.
How recruiters actually search on location
Two mechanisms run on different inputs, which is why you want to satisfy both. Boolean keyword searches inside the tracking system look for the literal string, so the common everyday name of the place matters. Radius filters run on the geocoded point, so resolvability matters. A plain city name does both jobs at once. A postal code satisfies the second and fails the first, because nobody types a postal code into a keyword box.
What to do this afternoon
Open your CV, extract the plain text from it, and read only two lines. If the phone number appears as one clean string you could dial, and the location appears as a city a recruiter would type, you are done. If either is fragmented, missing, or dressed up as an intention rather than a place, fix that before you rewrite a single bullet. Tools like Postulit build the contact block from structured profile data, which sidesteps most of this, but the test is the same either way: extract the text and look.
Adjacent reading on this blog covers how to run a parser test on your own file and which file types survive best. Start there once these two lines are clean.