Een ATS-veilige persoonsgegevens-header bevat in 2026 zes velden: voornaam plus achternaam, telefoonnummer, e-mail, woonplaats en LinkedIn-URL, plus optioneel portfolio. Vijf velden moeten weg: geboortedatum, burgerlijke staat, nationaliteit, pasfoto en volledig adres. Textkernel parseert de zes verplichte velden in gestructureerde candidate-profile-velden; de vijf weg-velden activeren bias-risico onder de Algemene Wet Gelijke Behandeling en vallen vanaf augustus 2026 onder de high-risk eisen van de EU AI Act.
Deze gids dekt per veld wat een ATS-parser ermee doet, welke format-keuzes parsing breken, en waarom de NL-conventie in 2026 strikter is dan internationale templates suggereren. 99% van de Fortune 500-bedrijven gebruikt automatische CV-screening [2], en Textkernel verwerkt 90% van de Nederlandse CVs zonder menselijke tussenkomst [1]. Je header is de eerste sectie die de parser leest; fouten hier nullen het effect van een sterke werkervaring-sectie.
TL;DR:
- Wel in 2026: voornaam plus achternaam, telefoon (+31 landcode), professioneel e-mail, woonplaats, LinkedIn-URL (publiek plus custom-URL plus klikbaar), optioneel portfolio of GitHub.
- Weg in 2026: geboortedatum, burgerlijke staat, nationaliteit, pasfoto, volledig straat-adres. Vijf velden die bias-risico activeren zonder match-voordeel.
- Parser-mapping per veld: Textkernel en Workday hebben gestructureerde candidate-profile-velden voor de zes verplichte items. Vrije-tekst varianten (slogans, headerbalken) vallen in een ongestructureerd veld zonder match-gewicht.
- LinkedIn-URL eisen: publiek profiel + custom-URL ingesteld + klikbare hyperlink in PDF. De ATS-checker in MyCVCraft accepteert het veld pas bij 5 of meer karakters.
- Telefoon-format: +31 6 12345678 met spaties. Vermijd creatieve scheidingstekens en haakjes; dat breekt parser-extractie.
- 2026 anti-discriminatie-shift: EU AI Act Annex III Section 4 classificeert recruitment-AI als high-risk vanaf 2 augustus 2026 [3][4]. Werkgevers moeten kunnen aantonen dat hun ATS niet op beschermde kenmerken filtert.
Inhoudsopgave
- Welke velden horen op een ATS-veilige CV-header in 2026?
- Hoe parseert Textkernel elk veld in je header?
- Welke velden moeten weg in 2026 (Awgb plus EU AI Act)?
- Hoe moet je LinkedIn-URL eruitzien om parser-leesbaar te zijn?
- Welk telefoon- en e-mailformat herkent een ATS-parser?
- Welke header-fouten breken section-recognition?
- ATS-veilige header template voor 2026
Welke velden horen op een ATS-veilige CV-header in 2026?
Zes velden horen in 2026 op je CV-header en die zijn allemaal verplicht: voornaam plus achternaam, telefoonnummer, professioneel e-mailadres, woonplaats, LinkedIn-URL en functietitel-aanduiding direct onder je naam. Een optioneel zevende veld is portfolio-URL (GitHub voor developers, dribbble voor designers, persoonlijke site voor consultants). Alles wat erbuiten valt verlaagt je matchscore zonder iets toe te voegen.
De zes-velden-set is geen smaakkwestie. Het is wat Textkernel als Nederlands marktleider in CV-parsing 90% van de Nederlandse CVs in gestructureerde velden van het candidate-profile-schema kan plaatsen [1]. Workday, Recruitee en SmartRecruiters volgen dezelfde structuur. Velden buiten de zes-set vallen in een vrije-tekst variant van het candidate-profile en wegen niet mee in de ranking-algoritmes die op gestructureerde data scoren.
De volgorde matters ook. Recruiters lezen je CV in 6 tot 8 seconden voor de eerste filter; hun ogen volgen een vast patroon van linksboven naar rechtsonder. Een parser scant op vergelijkbare wijze van boven naar beneden en verwacht naam-eerst, dan rol-aanduiding, dan contact-blok. Wijk je af, dan moet de parser meer rekenwerk doen om je velden te herkennen en gaat de kans op fouten omhoog.
| Veld | Verplicht | Parser-veld in Textkernel | Format-voorbeeld |
|---|---|---|---|
| Voornaam | Ja | first_name | Jan |
| Achternaam | Ja | last_name | de Vries |
| Functietitel | Aanbevolen | current_role | Senior Developer |
| Telefoon | Ja | phone | +31 6 12345678 |
| Ja | email | jan.devries@protonmail.com | |
| Woonplaats | Ja (NL) | city | Amsterdam |
| LinkedIn-URL | Ja | social_urls[linkedin] | linkedin.com/in/jan-de-vries |
| Portfolio-URL | Optioneel | social_urls[other] | github.com/jandevries |
Het 4-pijler ATS-cornerstone behandelt waarom de header-pijler het zwaarste weegt: een fout in de header (verkeerd format, ontbrekend veld, ongestructureerde plaatsing) propageert door de hele parser-output en kan de structurering van andere secties ondermijnen.
Hoe parseert Textkernel elk veld in je header?
Textkernel en Workday gebruiken een two-stage parsing-flow waarbij eerst je sectie-koppen worden herkend en daarna entity-extraction per sectie loopt. Voor de header werkt het iets anders: er is geen sectie-kop omdat de header altijd bovenaan staat. De parser gebruikt named-entity recognition (NER) plus regex-patronen om elk veld te identificeren zonder dat je "Persoonsgegevens" als kopje hoeft te schrijven.
Voor de naam-velden gebruikt de parser regex op "twee tot vier woorden met hoofdletters bovenaan de eerste pagina". Voorvoegsels zoals "van", "de", "der" worden expliciet in een aparte voorvoegsel-token gezet om te voorkomen dat ze als tweede achternaam worden gelezen. "Jan de Vries" parseert correct als first_name="Jan" + middle_particle="de" + last_name="Vries". "Jan-Willem" parseert als first_name="Jan-Willem" door het koppelteken. Vermijd creatieve typografie ("JAN de VRIES" of "j a n d e v r i e s") want NER faalt op niet-standaard spacing.
Voor het telefoon-veld scant de parser op getallenreeksen met 10 of 12 cijfers, eventueel voorafgegaan door een landcode-marker (+31 of 0031). Spaces tussen groepen worden genegeerd; haakjes en koppeltekens kunnen wel verwarring opleveren. Het format dat Textkernel als primary herkent is +31 6 12345678 met spaties. "06-1234-5678" of "(06) 12345678" werkt soms maar minder robuust.
Voor het e-mail-veld gebruikt de parser de RFC-5322 regex (de internet-standaard voor e-mail-formaten). Vrijwel elke geldige e-mail wordt herkend. Wat NIET werkt is een e-mail in een afbeelding (sommige CVs zetten contact-info in een grafisch element om scraping te voorkomen) want de parser doet geen OCR op embedded images. Onze ATS-check tool flagt e-mail-velden die als image worden opgeslagen.
Voor het woonplaats-veld gebruikt de parser een gazetteer (een database met geografische namen) van Nederlandse steden. "Amsterdam", "Den Haag", "Rotterdam" worden direct herkend. Wijken of buurten ("Amsterdam-Zuid", "Rotterdam Centrum") worden meestal correct gestript naar de hoofdstad. Voor DE-templates verwacht de parser straat plus postcode plus stad; voor NL is alleen woonplaats voldoende, en een volledig adres is zelfs af te raden om privacy- en bias-redenen.
Voor het LinkedIn-URL veld zoekt de parser naar de string linkedin.com/in/ ergens in je header. Wat erna komt wordt als profiel-identifier behandeld en doorgegeven aan de social-URL-extractor. De parser dedupliceert vervolgens tegen je LinkedIn-publieke-profiel-data: matcht je functietitel, periode en bedrijfsnaam op LinkedIn met wat in je CV staat? Bij meer dan kleine discrepanties komt er een rode vlag in het candidate-profile.
Hoe deze gehele parsing-pijplijn werkt staat in de gids over ATS-parsing. De header is dus de meest-geparseerde sectie van je CV; elke parser start hier met NER voordat hij naar werkervaring of opleiding gaat.
Welke velden moeten weg in 2026 (Awgb plus EU AI Act)?
Vijf velden horen in 2026 niet meer op een Nederlands CV: geboortedatum, burgerlijke staat, nationaliteit, pasfoto en volledig straat-adres. Drie van die vijf vallen onder de beschermde kenmerken van de Algemene Wet Gelijke Behandeling (Awgb); de andere twee verhogen bias-risico of privacy-risico zonder match-voordeel. De aanbeveling is in 2026 strenger dan in 2020 omdat de EU AI Act vanaf 2 augustus 2026 high-risk eisen activeert voor recruitment-AI [3][4].
Geboortedatum: weg. Leeftijd is geen beschermd kenmerk onder de Awgb-hoofdtekst, maar staat wel in aanvullende leeftijdsdiscriminatie-wetgeving (Wet gelijke behandeling op grond van leeftijd bij de arbeid). Een werkgever mag niet op leeftijd selecteren; geboortedatum vermelden vergroot bias-risico zonder match-voordeel. Sinds 2026 vallen geautomatiseerde recruitment-systemen onder de high-risk classificatie van de EU AI Act Annex III Section 4 [3], en werkgevers moeten kunnen aantonen dat hun ATS niet op leeftijd filtert. Concreet: laat geboortedatum weg, ongeacht wat formulieren suggereren.
Burgerlijke staat: weg. Onder de Awgb expliciet beschermd kenmerk. Werkgever mag er in een sollicitatiegesprek niet eens naar vragen. Vermelding op je CV is enkel anker voor onbewuste vooroordelen en heeft geen rol in geschiktheidsbeoordeling. Geldt voor "ongehuwd", "gehuwd", "geregistreerd partnerschap" en alle varianten.
Nationaliteit: weg, behalve uitzonderingen. Onder de Awgb beschermd kenmerk. Vermelden alleen als de functie een specifieke werkvergunning of veiligheidsmachtiging vereist (bijvoorbeeld defensie, financiele toezichtsfuncties met EU-passporting, bepaalde overheidsfuncties). Voor 95% van de vacatures hoort het niet op je CV. EU-nationaliteit is impliciet onder de werkvergunning-context; als je werk mag in NL onder EU-vrij verkeer, hoeft je nationaliteit niet expliciet vermeld.
Pasfoto: weg in NL. UvA-onderzoek (Lancee, 2019) toont aan dat een foto het discriminatie-risico verhoogt zonder match-voordeel. Sinds 2026 geldt onder de EU AI Act een verhoogd risico-profiel voor geautomatiseerde screening met foto's: een werkgever moet kunnen aantonen dat zijn ATS niet op foto-attributes filtert. Drie uitzonderingen (sectoren waar foto sectorgebruik is): horeca/hospitality, modeling/acteursfuncties, en bepaalde sales-rollen met klant-facing. Voor de andere 95% van de vacatures: geen foto. De foto-gids voor 2026 behandelt de uitzonderingen en de drie criteria om te beslissen.
Volledig adres: weg, woonplaats blijft. Privacy-conventie. Werkgever heeft geen reden om je straatnaam of postcode te kennen voor het sollicitatieproces. Woonplaats wel relevant voor reisafstand en regio-pasbaarheid; volledig adres niet. Voor DE-templates is volledig adres nog wel conventie, voor NL al jaren niet meer.
De parallel met de bredere anti-discriminatie-context op je CV loopt door alle vijf weg-velden. De loontransparantie-gids behandelt de andere kant van diezelfde wettelijke shift: werkgevers krijgen meer transparantie-verplichtingen, sollicitanten krijgen meer rechten op uitleg bij geautomatiseerde afwijzing.
Hoe moet je LinkedIn-URL eruitzien om parser-leesbaar te zijn?
Je LinkedIn-URL moet aan drie eisen voldoen om parser-leesbaar en recruiter-bruikbaar te zijn: publiek profiel, custom-URL ingesteld, en klikbare hyperlink in je CV-PDF. De ATS-checker in onze tool vereist een ingevuld LinkedIn-veld van minimaal 5 karakters; korter wordt als ontbrekend behandeld. Een verkeerd-geformatteerde URL is hetzelfde signaal als een ontbrekende URL.
Eis 1: Publiek profiel. Je LinkedIn-instellingen moeten je profiel als "publiek-zichtbaar" markeren (niet "alleen-zichtbaar-voor-contacten"). Een ATS-parser kan je profiel pas dedupliceren tegen je CV-data als de pagina open is. Recruiters die je URL klikken landen anders op een lege placeholder en interpreteren dat als "kandidaat heeft iets te verbergen". Check: log uit van LinkedIn, plak je URL in een browser, en kijk of je hele profiel zichtbaar is.
Eis 2: Custom-URL ingesteld. Standaard geeft LinkedIn je een URL met een ID-achtervoegsel (linkedin.com/in/jan-de-vries-123abc4). Onder Settings > Public Profile > Customize Your Public URL kun je dit aanpassen naar linkedin.com/in/jan-de-vries. Een custom-URL is korter, professioneler en parser-vriendelijker. De ID-versie werkt technisch wel maar de korte versie wordt door recruiters direct gelinkt aan je naam in de match-database.
Eis 3: Klikbare hyperlink in PDF. In je CV-PDF moet de URL als clickable hyperlink ingesloten zijn, niet als platte tekst. Test: open je gegenereerde PDF, hover over je LinkedIn-URL, en controleer of de cursor verandert in een hand-icon. Bij MyCVCraft en de meeste moderne CV-tools is dit standaard; bij Word-export moet je expliciet "Hyperlink invoegen" gebruiken. Een platte tekst-URL werkt nog wel voor de parser, maar recruiters moeten dan handmatig kopieren-en-plakken; dat is friction die je niet wilt.
Parser-dedup gedrag. Na URL-detectie haalt de Textkernel-parser je publieke LinkedIn-profiel data op en vergelijkt drie velden met je CV: functietitel (huidige rol), tijdsperiode (start- en einddatums per ervaring) en bedrijfsnaam. Discrepanties van meer dan een paar maanden of een afwijkende werkgevernaam triggeren een "data-inconsistency" flag in het candidate-profile dat recruiters bovenaan zien. Houd je LinkedIn synchroon met je CV; een achterhaalde LinkedIn is een rode vlag waar weinig kandidaten aan denken.
Welk telefoon- en e-mailformat herkent een ATS-parser?
Het telefoonnummer-format dat Textkernel en Workday als primary herkennen is +31 6 12345678 met spaties tussen landcode, mobiel-prefix en de hoofdreeks. Voor het e-mailadres geldt de RFC-5322 internet-standaard; vrijwel elke geldige e-mail wordt herkend, met als belangrijke uitzondering e-mails ingebed in een afbeelding (waar de parser geen OCR op uitvoert). Format-fouten op deze twee velden komen veel voor en breken stilletjes je contact-extractie.
Telefoon-formats per kwaliteit:
| Format | Parser-herkenning |
|---|---|
| +31 6 12345678 | Beste; internationaal en met spaties |
| +31612345678 | Werkt; zonder spaties iets minder robuust |
| 0031 6 12345678 | Werkt; verouderd internationaal-prefix |
| 06 12345678 | Werkt voor NL-only; geen landcode |
| 06-1234-5678 | Risicovol; koppeltekens kunnen verwarring geven |
| (06) 12345678 | Risicovol; haakjes vallen vaak buiten regex |
| 06.12.34.56.78 | Faalt vaak; punten als scheidingsteken niet standaard |
Voor internationale sollicitaties is +31 met landcode altijd te prefereren. NL-only sollicitaties accepteren 06-format ook. Vermijd creatieve scheidingstekens; ze ogen "design-bewust" maar kosten je een leeg telefoon-veld in 5 tot 10% van de parser-runs.
E-mail-formats die werken:
- voornaam.achternaam@protonmail.com (sterkst, plus protonmail-domein signaleert privacy-bewustzijn)
- voornaam.achternaam@gmail.com (universeel geaccepteerd)
- voornaam-achternaam@outlook.com (geaccepteerd)
- j.devries@eigen-domein.nl (signaleert professionaliteit, bij eigen domein)
E-mail-formats die werken maar zwak signaleren:
- cooltype23@hotmail.com (parser leest hem prima, recruiter leest "onprofessioneel")
- devries1990@gmail.com (geboortejaar onthult leeftijd; ondermijnt de geboortedatum-weg-keuze)
- voornaam.achternaam@hotmail.com (hotmail-domein is gedateerd voor recruitment in 2026)
E-mail-formats die falen:
- E-mail als afbeelding (parser doet geen OCR)
- E-mail in een tekstvak of geannoteerde PDF-laag (kan buiten tekstextractie vallen)
- E-mail met zero-width characters of unicode-look-alikes (jan@gmaıl.com met Turkse i: faalt of pingt als spam)
Onze ATS-check tool flagt e-mail-velden die niet aan RFC-5322 voldoen of die als image zijn opgeslagen. Voor de telefoon-controle accepteert de tool elk format dat 10 of 12 cijfers bevat; format-warning-flags zijn er voor de niet-standaard scheidingstekens.
Welke header-fouten breken section-recognition?
Vijf header-fouten breken section-recognition consequent en zijn de hoofdoorzaak van CVs die "spoorloos" lijken te verdwijnen in de parser-output. Section-recognition is de eerste stap in de parsing-flow: zonder herkende sectie-koppen valt al je werkervaring en opleiding in een vrije-tekst veld zonder match-gewicht. De fout zit dan niet in je inhoud maar in je layout-keuzes bovenaan.
Fout 1: Tweekoloms-layout met de header gesplitst over kolommen. Sidebar links met naam en contact, hoofdkolom rechts met inhoud. Visueel modern, parser-funest. Textkernel verwerkt de twee kolommen typisch als sequentiele blokken: eerst de hele sidebar, dan de hele hoofdkolom. Je naam en je werkervaring komen daardoor mogelijk niet in elkaars context terecht en de NER-koppeling tussen "Jan de Vries" en zijn rol breekt. Eenkoloms is altijd veiliger. Onze 10 CV-fouten gids behandelt dit als Fout 1.
Fout 2: Header in afbeelding of grafisch logo. Sommige design-CVs zetten naam, contact-info en functietitel in een grafische headerbalk (PNG of SVG) met de tekst eronder in een tekstvak. Parser leest geen tekst uit images zonder OCR; je hele identificatie verdwijnt uit het candidate-profile. Test: open je PDF in Adobe Reader, probeer de header-tekst te selecteren met je muis. Lukt het niet, dan is het een image en moet het hertypt worden als platte tekst.
Fout 3: "Curriculum Vitae" of "CV van Jan de Vries" als page-header. Klinkt netjes; verwart NER. De parser krijgt twee naamkandidaten ("Curriculum Vitae" en "Jan de Vries") en kan de verkeerde als primary kiezen. Resultaat: candidate-profile met "name_first=Curriculum, name_last=Vitae". Laat de page-header weg. Begin met alleen je naam in de eerste regel.
Fout 4: Functietitel boven je naam. "Senior Developer" als grote eerste regel met "Jan de Vries" eronder in kleinere font. Visueel goed; parser-volgorde-funest. NER-algoritmes zoeken naam in de eerste paar regels; functietitel-eerst maakt dat je naam in regel 2 of 3 valt en buiten het NER-window kan vallen. Plaats altijd: naam-eerst, functietitel-eronder.
Fout 5: Kolomvormige tabel voor contact-velden. Telefoon links, e-mail midden, woonplaats rechts in een 3-koloms tabel met onzichtbare borders. Sommige parsers lezen de tabel-cellen in willekeurige volgorde en koppelen je telefoonnummer aan een andere kandidaat-row. Zet contact-info op aparte regels onder elkaar of gescheiden met simpele pipes ("|") in een doorlopende zin. Geen tabel-elementen voor contact-data.
ATS-veilige header template voor 2026
Een ATS-veilige header in 2026 is platte tekst, eenkoloms, met de zes verplichte velden in vaste volgorde. Geen tabellen, geen kolommen, geen afbeeldingen, geen page-header. Hieronder de standaard template die in Textkernel, Workday, Recruitee en SmartRecruiters parser-tests consequent in alle gestructureerde velden plaatst.
Jan de Vries
Senior Developer
+31 6 12345678 | jan.devries@protonmail.com | Amsterdam
linkedin.com/in/jan-de-vries | github.com/jandevries
Waarom dit format werkt:
- Regel 1: Voornaam plus achternaam alleen. NER-algoritme vindt de naam in zijn primary search window (eerste 2 regels). Voorvoegsel "de" wordt correct als middle_particle gelezen.
- Regel 2: Functietitel direct onder de naam. Parser koppelt aan current_role veld. Geen "Mijn doel:" prefix, geen vrij-tekst slogan.
- Lege regel: Visuele scheiding tussen identiteit-blok en contact-blok. Parser herkent paragrafen-break maar negeert het verder.
- Regel 3 (contact-blok): Telefoon plus e-mail plus woonplaats gescheiden met pipes. Doorlopende tekst dus parser leest sequentieel, geen tabel-cellen. Telefoon-format met landcode en spaties. E-mail in voornaam.achternaam-stijl. Woonplaats zonder volledig adres.
- Regel 4 (URLs): LinkedIn-URL plus optioneel portfolio-URL gescheiden met pipe. Custom-URLs (geen ID-achtervoegsels). Beide klikbaar in PDF-export.
Wat NIET in deze template staat: geboortedatum, burgerlijke staat, nationaliteit, pasfoto, straatnaam, postcode, slogan-tekst, persoonlijke missie-statement, kleur-blok of grafisch logo. De vijf weg-velden uit sectie 3 ontbreken bewust. Slogans en missie-statements horen in de persoonlijk profiel sectie, niet in de header.
Controle-stap voor je publiceert:
- Plak je CV in onze ATS-check tool. De tool checkt of alle zes verplichte velden ingevuld zijn, of LinkedIn een geldige URL is, of het telefoon-format herkend wordt, en flagt aanwezigheid van weg-velden zoals geboortedatum.
- Test in een tekst-editor. Open je PDF in Adobe Reader, selecteer de hele header met je muis, en plak in Notepad. Lees wat eruit komt. Krijg je de naam op regel 1, functietitel op regel 2, contact-blok in leesbare volgorde? Goed. Krijg je een chaos van losse woorden in willekeurige volgorde? Dan is je layout te complex voor parsers.
- Cross-check met de umbrella CV-gids. De umbrella behandelt de hele CV-anatomie (acht secties in vaste volgorde); je header is sectie 1 en moet aansluiten op de andere zeven.
Voor sollicitaties op posities waar je je CV in een online ATS-portaal moet uploaden (Workday, SmartRecruiters), is de header-kwaliteit de belangrijkste enkele factor in hoe correct je profile wordt aangemaakt. De parser leest je header binnen seconden; bij correcte velden krijg je een ingevuld kandidaat-profile dat de recruiter direct kan beoordelen, bij gebroken velden krijg je een hand-ingevuld formulier waar je elke veld opnieuw moet typen.
Een sterke header is geen design-kwestie. Het is een parser-kwestie. Zes velden in vaste volgorde, vijf velden weg, geen tabel-of-image-trucs, en LinkedIn-URL die aan de drie eisen voldoet. Check je huidige CV-header tegen deze template met onze ATS-check tool; de gemiddelde header-revisie kost 10 minuten en flipt je match-score meetbaar omhoog.
Bronnen
- Cv-parsing: hoe werkt het en wat levert het op?- recruitmenttraining.pro
- New study says 'hidden workers' are being excluded- news.harvard.edu
- Annex III, EU AI Act: high-risk AI systems (recruitment)- artificialintelligenceact.eu
- EU AI Act Implementation Timeline- artificialintelligenceact.eu
- Onderzoek Solliciteren: Alle cijfers op een rij- beaks.nl
Related Posts
Vrijwilligerswerk op je CV: werkervaring of hobby? [2026]
Wanneer telt vrijwilligerswerk als werkervaring op je CV en wanneer als hobby? 3-assige beslismatrix plus parser-behavior per sectie-kop.
Hobby's, talen en referenties op je CV [2026]
Wat zet je onderaan je CV in 2026? Triage matrix per sub-topic: hobby's, talen (ERK-niveau) en referenties, met parser-behavior per sectie.
Lopende opleiding op je CV: 'verwacht' vs 'heden' [2026]
Hoe vermeld je een lopende opleiding op je CV in 2026: welke datum-notatie ATS-parsers correct lezen, wel/niet vermelden, en sector-verschillen.