Wir schicken unsere Lebenslauf-Vorlagen durch drei kommerzielle Parser-Engines — dieselbe Technik, die in den Bewerbersystemen des deutschen Marktes steckt. Wir prüfen die ATS-Kompatibilität durchgehend und passen die Vorlagen an, sobald eine Messung etwas findet. Auf dieser Seite steht beides: was wir belegen können und was nicht.
Eine E-Mail-Adresse in einer schmalen Seitenspalte, drei kommerzielle Engines. So kam sie im jeweiligen Datensatz an:
Die Zahl steht in fast jedem deutschen Ratgeber zum Thema, meist ohne Quelle. Wir zeigen, woher sie kommt.
Der meistzitierte Wert im deutschen ATS-Diskurs — ohne Studie dahinter
Das echte Risiko ist leiser: Deine Daten kommen beschädigt an, und niemand merkt es.
Kein System wirft dich raus, weil du zweispaltig gestaltest. Aber wenn deine E-Mail-Adresse im Datensatz unvollständig landet, kann dir niemand antworten — und der Recruiter sieht keinen Fehler, sondern nur einen Bewerber, der sich nicht zurückmeldet. Genau diese Klasse von Schaden messen wir.
Sie kaufen ihn ein — und zwar großteils beim selben Anbieter. Im deutschsprachigen Kernmarkt arbeiten sechs von neun geprüften Systemen mit Textkernel; die internationalen Suiten, denen du hier ebenfalls begegnest, setzen teils auf andere Engines, teils auf Eigenbau. Jede Zeile trägt ihren öffentlichen Beleg — zusammen steht das in keinem Vergleichsartikel.
SuccessFactors liest im Standard mit Textkernel — RChilli ist als Zusatzmodul installierbar. Bei Oracle ist es genau umgekehrt. Zwei Firmen mit demselben HR-System können deinen Lebenslauf also mit unterschiedlicher Technik lesen.
Für dich hat das eine praktische Folge und eine beruhigende. Die praktische: „für jedes System einzeln optimieren“ funktioniert nicht, weil du das System gar nicht zuverlässig kennst. Die beruhigende: Wenn du dich bei zehn Firmen bewirbst, landest du statistisch mehrfach bei derselben Software — ein sauber gebautes Dokument wirkt also mehrfach.
Fehler entstehen dabei im Dokument, nicht in den Systemen dieser Anbieter. Wir bewerten hier keinen von ihnen.
Eine schmale Seitenspalte zwingt lange Werte auf zwei Zeilen. Für dich ist das unsichtbar, im PDF steht ja alles vollständig da. Für einen Parser ist es der teuerste Umbruch im ganzen Dokument. Genau das provozieren und messen wir. Die Tabelle zeigt den härtesten gemessenen Fall: ein und dieselbe Adresse, am Bindestrich umbrochen, gelesen von drei Engines. Das Blatt daneben zeigt an einer unserer Vorlagen, wie so eine Bruchstelle aussieht. Wie wir das im Dauerbetrieb verhindern, steht in Sektion 05 — und wo ein Umbruch bleiben darf, in Sektion 07.
| Engine | Ankommender Wert | Fehlerart |
|---|---|---|
| Engine A | [email protected] | Bindestrich verschlucktsieht gültig aus |
| Engine B | aarav@patel | nach dem Umbruch abgeschnittenunvollständig |
| Engine C | (kein Wert) | Feld komplett verworfenleer |
Engine A, B und C sind drei kommerzielle Parser aus genau diesem Markt. Welche Engines in welchem Bewerbersystem stecken, steht in der Landkarte oben — die Messwerte hier ordnen wir bewusst keinem Namen zu.
Der erste Fall ist der teuerste. Die Adresse ist syntaktisch gültig und faktisch unzustellbar: Der Recruiter kann dir nicht antworten, und niemand erfährt, woran es liegt. Telefonnummern kamen übrigens überall korrekt an — es trifft das längste Feld im schmalsten Container.
Und bevor das jemand als Anbietervergleich liest: Keine der drei kommt hier gut weg, und schuld ist auch keine von ihnen. Der Umbruch steckt im Dokument, die Engines gehen nur unterschiedlich damit um. Eine Konfiguration und eine Momentaufnahme sind viel zu dünn für eine Bewertung der Anbieter.
Eine zerrissene Profil-Adresse kostet nicht nur das eigene Feld. Sie verunreinigt die Namenserkennung: Eine Engine las den Vornamen aus einem Bruchstück der LinkedIn-URL statt aus der Kopfzeile des Dokuments.
Das „Lin“ stammt aus linkedin.com/in/… — das Dokument war optisch unverändert korrekt. Ein einziger Umbruch an der falschen Stelle kann also mehrere Felder gleichzeitig verderben.
Die Messreihe ist nicht als Marketing angelegt, sondern als Prüfung der eigenen Vorlagen — im Dauerbetrieb: Die Fehlerklassen, die sie sichtbar macht, laufen als blockierende Tests bei jeder Änderung mit. So sieht das konkret aus.
Ein PDF speichert Text in der Reihenfolge, in der er gezeichnet wird — nicht in der, in der du liest. Bei zwei Spalten verschachtelt sich beides. Unsere Vorlagen schreiben den Textstrom in Lesereihenfolge: Zwischen Dokumentanfang und erkanntem Namen liegen 9 Positionen, nicht 516 wie bei naiver Zeichenreihenfolge
E-Mail-Adresse und Profil-Adresse werden so gesetzt, dass sie nicht umbrechen — bis auf zwei dokumentierte Ausnahmen, die in Sektion 07 stehen
Die Umbruch-Prüfung läuft als blockierender Test bei jeder Änderung mit und schlägt in beide Richtungen an: bei einem neuen Umbruch genauso wie bei einem erwarteten, der plötzlich verschwindet
Wenn deine Adressen für eine schmale Seitenleiste zu lang sind, sagt das Studio es dir beim Gestalten — mit dem einspaltigen Layout als Alternative
Deshalb trauen wir keinem Siegel — wir sehen ja selbst, was eine Messung zutage fördert.
Wer seine Vorlagen nie gegen echte Engines gehalten hat, hat auch nie die Gelegenheit gehabt, eigene Fehler zu finden. Ein Prüfsiegel ohne veröffentlichte Methode sagt nichts darüber, ob überhaupt jemand hingesehen hat.Der glaubwürdigste Teil einer Messreihe ist der, in dem man falsch liegt. Zwei eigene Annahmen hat die Messung kassiert — mit nur einer Engine wären beide nie aufgefallen.
„Ein Umbruch schadet nur am Bindestrich und am Punkt, nicht am @-Zeichen“
Wir haben eine Variante gebaut, die genau dort umbricht — und es wurde schlechter. Eine Engine lieferte danach überhaupt kein E-Mail-Feld mehr und reimte sich aus dem abgetrennten Rest zusätzlich eine Website-Adresse zusammen.
Kontaktwerte dürfen gar nicht umbrechen, egal an welcher Stelle.
„Wir haben zwei weitere Defekte in unseren Vorlagen gefunden“
Ein falsch gelesener Vorname und zerrissene Positionsangaben traten nur bei einer Engine auf. Die Gegenprobe mit der zweiten las beides korrekt — es waren Eigenheiten dieser einen Engine, keine Dokumentfehler. Die dritte holte einen der beiden Effekte dann doch wieder zurück.
Ein Befund aus einer einzigen Engine ist keine Erkenntnis, sondern eine Vermutung.
Ein „ATS-geprüft“-Siegel auf Basis eines einzigen Tools ist so aussagekräftig wie ein Rechtschreibtest in einer einzigen Sprache.
Wir schauen uns an, worauf die gängigen Kompatibilitäts-Versprechen beruhen. Sie zerfallen in drei Muster — und keines davon enthält Messdaten.
„ATS-optimierte Vorlagen“, „leichter für ATS zu lesen“ — ohne Methode, ohne Daten, ohne Prüfung, die man nachvollziehen könnte
Ein eigener Checker mit „30 Prüfungen“, der „liest wie ein ATS“ — gemessen wird gegen eine Nachbildung, nicht gegen eine echte Engine
Getestet gegen ungenannte Parser, ohne Namen, ohne Methode, ohne Zahlen — von Dritten teilweise bereits widerlegt
„Wenn du deinen Lebenslauf auf eine Stelle einreichst, bewertet das ATS ihn nicht. Die Übereinstimmungsrate in unserem Scanner ist ein Visualisierungs-Werkzeug.“Aus dem eigenen Hinweistext eines der größten Score-Anbieter · sinngemäß übersetzt
Das ist bemerkenswert offen — und es entwertet die gesamte Score-Kategorie. Es gibt keine Punktzahl, die dein Lebenslauf beim Arbeitgeber erreicht. Es gibt nur Felder, die ankommen, und Felder, die nicht ankommen.
Ohne diesen Abschnitt wäre diese Seite selbst nur eine Behauptung. Drei Dinge können wir nicht belegen, und ein Rest bleibt in unserem eigenen Produkt offen.
Die beliebteste Frage lautet: „Erkennt das System meine Überschrift als Berufserfahrung?“ Keine der drei Engines liefert für deutschsprachige Dokumente ein Abschnittsmodell — die entsprechenden Felder blieben bei allen zwölf deutschsprachigen Vorlagen leer und waren nur bei den englischsprachigen gefüllt. Wir können die Frage für den deutschen Markt also nicht beantworten, und wir tun auch nicht so.
Was eine Firma mit den ausgelesenen Daten anstellt — filtern, sortieren, bewerten — ist eine andere Ebene und in jedem Unternehmen anders konfiguriert. Darüber sagt diese Messreihe nichts.
Standardkonfiguration, je Vorlage eine Testperson. Anbieter ändern ihre Modelle, und eine andere Konfiguration kann andere Ergebnisse liefern. Jede einzelne Messung gegen die Engines ist deshalb eine Momentaufnahme — ihren Stand nennt das Messreihen-PDF weiter unten.
Auf den vier Vorlagen mit schmaler Seitenleiste passen sehr lange Adressen nicht in eine Zeile. In unserem Prüflauf betrifft das zwei von sechzehn Testprofilen, jeweils mit Adressen um die 39 Zeichen. Wir entscheiden uns bewusst dagegen, das Design dafür zu brechen: Die Optik dieser Vorlagen ist der Grund, warum jemand sie wählt.
Stattdessen sagt dir das Studio beim Gestalten, dass deine Adresse zu lang für diese Leiste ist — und bietet dir das einspaltige Layout an. Du triffst die Entscheidung, nicht wir, und du triffst sie vorher statt hinterher.
Du brauchst dafür weder uns noch ein Bewertungs-Tool, und auch keine Zusatzsoftware. Deinen Lebenslauf so zu sehen, wie eine Maschine ihn liest, kostet dich drei Handgriffe, die du längst kennst.
Im Betrachter deiner Wahl — Vorschau, Acrobat oder einfach im Browser
Strg + A, dann Strg + C — am Mac Cmd statt Strg
Editor, TextEdit, ein leeres Dokument — Hauptsache ohne Layout. Was dort erscheint, ist ungefähr das, was ein Bewerbersystem aus deiner Datei herausliest: dein Textstrom, ohne Gestaltung
Steht deine E-Mail-Adresse in einem Stück da, oder auf zwei Zeilen zerlegt?
Ist deine Profil-Adresse vollständig, inklusive des letzten Zeichens?
Kommt der Inhalt spaltenweise, oder springt er zwischen den Spalten hin und her?
Steht dein Name ganz oben, oder taucht davor ein Bruchstück aus der Seitenleiste auf?
Ehrlich dazu: Das bildet nur die einfachste Parser-Klasse nach. Kommerzielle Engines haben zusätzlich eine Layout-Analyse und ordnen Spalten oft richtig zu — dein Kopier-Ergebnis sieht also eher schlechter aus als das, was bei ihnen ankommt. Aber genau die Fehlerklasse, um die es auf dieser Seite geht — zerrissene Werte in schmalen Spalten — wird so sichtbar. Steht dort alles sauber und in vernünftiger Reihenfolge, bist du bei der großen Mehrheit der Systeme auf der sicheren Seite.
Wenn du es genauer wissen willst: Der Weg mit Werkzeugen — dieselbe Prüfung auf der Kommandozeile — steht im Messreihen-PDF weiter unten.
Die Fragen, die rund um ATS und CV-Parsing immer wieder auftauchen — beantwortet mit dem, was wir belegen können.
In aller Regel ja. Die verbreitete Regel „einspaltig, sonst wird es nicht gelesen“ hat unsere Messung in dieser Härte nicht bestätigt: Die Engines mit Layout-Analyse ordnen Spalten korrekt zu. Das reale Risiko sind nicht die Spalten, sondern die Zeilenumbrüche darin — eine schmale Seitenleiste zwingt lange Werte wie die E-Mail-Adresse auf zwei Zeilen, und genau dort entstehen die Fehler. Wenn du zweispaltig gestalten willst, achte darauf, dass Kontaktdaten in einer Zeile bleiben oder in der breiten Spalte stehen. Kurze Adressen sind robuster, und Profil-Adressen schreibst du ohne den Vorsatz „https://www.“ — das spart zwölf Zeichen, die niemand braucht.
Die Regeln für den ATS-LebenslaufNach allem, was sich belegen lässt: praktisch nie. Nur etwa ein Prozent der Unternehmen in Deutschland lässt Bewerbungen von KI vorsortieren. Die viel zitierte Zahl von 75 Prozent aussortierter Lebensläufe geht auf ein Verkaufsgespräch aus dem Jahr 2012 zurück, nicht auf eine Studie. Das Risiko liegt woanders: Wenn deine Daten unvollständig im System landen, wirst du bei einer Suche nicht gefunden — oder niemand kann dich erreichen. Aussortiert wirst du nicht, du bist einfach nicht auffindbar.
Beides funktioniert, solange der Text echter Text bleibt. Ein als Text gespeichertes PDF ist meist die sicherste Wahl, weil es dein Layout unterwegs schützt. Entscheidend ist nicht das Dateiformat, sondern was im Textstrom steht — genau das prüfst du mit dem Selbsttest weiter oben. Tabu bleibt ausschließlich das Bild-PDF oder der eingescannte Lebenslauf: Dort gibt es für die Maschine überhaupt keinen lesbaren Text.
Meistens gar nicht — und das ist weniger schlimm, als es klingt. Oft verrät die Domain des Bewerbungsformulars den Anbieter, aber die eingebaute Engine ist nicht zwingend die einzige, und zwei Firmen mit demselben System können mit unterschiedlicher Technik lesen. Deshalb bringt „für jedes System einzeln optimieren“ wenig. Was hilft, ist ein Dokument, dessen Werte in jeder Engine vollständig ankommen.
So viel wie die Methode, die dahintersteht — und die wird fast nie genannt. Wir haben in unserer eigenen Messreihe zwei vermeintliche Defekte gefunden, die sich in der Gegenprobe als Eigenheiten einer einzelnen Engine erwiesen haben. Ein Siegel, das auf einem Tool beruht, hätte beide als echte Fehler gemeldet. Frag also nicht, ob geprüft wurde, sondern womit, wogegen und mit welchem Ergebnis.
Methodik, Befunde und Grenzen als zusammenhängendes Dokument, zum Weitergeben an Kolleginnen und Kollegen, in Karriereberatungen oder in die Bewerbungsvorbereitung.
Teilen erwünscht · Zitieren mit Quellenangabe
Dieselbe Prüfung, die diese Seite dokumentiert, läuft bei jeder Änderung an unseren Vorlagen mit. Du musst dich um Textströme und Umbrüche nicht kümmern — du siehst nur das Ergebnis.
Kostenlos starten · keine Kreditkarte · Server in der EU