Wer eine Stellenanzeige mit korrektem JobPosting-Markup ausstattet, sorgt dafür, dass Google die Stelle in den speziellen Job-Suchergebnissen anzeigen kann. Dafür braucht es sechs Pflichtfelder: Jobtitel, Arbeitgeber, Standort, Beschäftigungsart, Bewerbungslink und Veröffentlichungsdatum. Als Nächstes folgt die technische Umsetzung: JSON-LD in die Seite einbauen, die URL indexierbar halten und das Ergebnis mit einem Validator prüfen.

Kurz gesagt:

• Nur vollständig ausgefüllte Pflichtfelder wie Jobtitel, Arbeitgeber, Standort, Beschäftigungsart, Bewerbungslink und Veröffentlichungsdatum gewährleisten die korrekte Anzeige bei Google for Jobs.

• Die technische Umsetzung erfordert eine saubere Einbettung des JSON-LD Markups im HTML, stabile URLs sowie die Vermeidung von noindex- oder robots-blockierenden Anweisungen.

• Für eine bessere Sichtbarkeit sollten auch optionale Felder wie Gehalt, Arbeitsmodell und Ablaufdatum korrekt genutzt und im ISO-Format eingetragen werden.

• Fehlerhafte oder inkonsistente Daten zwischen sichtbarem Text und Schema-Einträgen führen häufig dazu, dass Stellen bei Google nicht angezeigt werden.

• Automatisierte Tools und zentrale Datenpflegelösungen wie Recruitify können helfen, Widersprüche zu vermeiden und die Datenqualität dauerhaft sicherzustellen.

RecruitifySaubere Jobdaten zentral verwaltenRecruitify verbindet ATS, Sales CRM und IT-Contracting, damit Recruiting-Teams Daten und Workflows in einem operativen System bündeln.Recruitify entdecken

Inhaltsverzeichnis

• Was ist strukturierte Daten für Stellenanzeigen und warum zählt sie?

• Welche Felder braucht ein JobPosting-Schema wirklich?

• Technische Richtlinien: Damit das Markup auch wirkt

• Wie sehen fertige JobPosting-Beispiele aus?

• Wie prüft man strukturierte Daten auf Fehler?

• Warum werden Stellenanzeigen bei Google nicht angezeigt?

• Wie sollte ein ATS strukturierte Jobdaten technisch ausgeben?

• Strukturierte Daten sind kein Randthema mehr

• Recruitify als zentrale Lösung für saubere Jobdaten

• Quellen

• FAQ

Was ist strukturierte Daten für Stellenanzeigen und warum zählt sie?

Strukturierte Daten für Stellenanzeigen sind maschinenlesbare Zusatzinformationen im Quellcode einer Jobseite, die Suchmaschinen exakt mitteilen, worum es auf der Seite geht. Das zugrunde liegende Vokabular liefert Schema, der Felder wie Titel, Arbeitgeber oder Gehalt in einer festen Struktur definiert. Ohne dieses Markup sieht eine Suchmaschine nur Fließtext und muss raten, was der Jobtitel ist, wo die Stelle liegt und ob sie noch offen ist.

Genau hier liegt der Unterschied zwischen strukturierten Jobanzeigen und einer normalen Textseite. Google for Jobs nutzt das JobPosting-Schema als Grundvoraussetzung, um Stellen in den erweiterten Suchergebnissen mit Filtern für Standort, Gehalt und Beschäftigungsart anzuzeigen. Die Einbindung kostet nichts, und die Indexierung neuer Stellenanzeigen erfolgt laut Google-Dokumentation zu JobPosting meist innerhalb weniger Tage.

Für Karriereportale bedeutet das einen direkten Sichtbarkeitshebel, der nichts mit klassischer Suchmaschinenoptimierung im Sinne von Backlinks oder Content-Länge zu tun hat. Es geht um Datenqualität. Viele Unternehmen optimieren nur die Anzeige, die ein Mensch auf dem Bildschirm sieht, und vergessen, dass dieselben Kerndaten auch strukturiert und maschinenlesbar vorliegen müssen, damit ATS-Systeme und Suchmaschinen sie korrekt verarbeiten können. Wer beides synchron hält, gewinnt doppelt: bessere Auffindbarkeit und weniger Fehler bei automatisierten Prozessen.

Welche Felder braucht ein JobPosting-Schema wirklich?

Ein JobPosting-Datensatz unterscheidet zwischen Feldern, die Google zwingend verlangt, und solchen, die zwar optional sind, aber die Klickrate und die Qualität der Bewerbungen deutlich verbessern. Wer strukturierte Datensätze für Jobs korrekt aufbaut, sollte beide Kategorien im Blick behalten.

Diese Felder sind laut Google-Richtlinie Pflicht:

• title: der exakte Jobtitel, wie er auch im sichtbaren Text erscheint.

• hiringOrganization: der Name des Arbeitgebers, meist als Organization-Objekt mit Namen und Logo.

• jobLocation: die Adresse des Arbeitsortes als Place-Objekt mit Straße, Ort und Land.

• employmentType: die Beschäftigungsart, etwa FULL_TIME, PART_TIME oder CONTRACTOR.

• datePosted: das Veröffentlichungsdatum im ISO-8601-Format.

• description: die vollständige Stellenbeschreibung als reiner Text, nicht als HTML-Fragment mit Formatierungsresten.

Empfohlene Felder verbessern vor allem die Darstellung und die Relevanz in der Ergebnisliste:

• baseSalary: die Gehaltsspanne, idealerweise mit currency, value und unitText.

• jobLocationType: Kennzeichnung für Remote-Stellen (TELECOMMUTE).

• validThrough: das Ablaufdatum, damit die Anzeige nicht länger als tatsächlich gültig angezeigt wird.

• industry und occupationalCategory: hilfreich für die Kategorisierung in Fachportalen.

Profi-Tipp: Tragen Sie das Datum niemals als Text wie „15. März 2026“ ein. Nutzen Sie durchgängig das ISO-8601-Format (2026-03-15), sonst ignorieren viele Parser das Feld komplett.

Stellenanzeigen mit vollständig ausgefüllten empfohlenen Feldern, insbesondere Gehaltsangabe und Arbeitsmodell, erscheinen in der Google-Job-Suche mit mehr Filteroptionen. Das erhöht die Wahrscheinlichkeit, dass ein passender Kandidat die Anzeige überhaupt zu sehen bekommt, bevor er sie wegklickt.

Technische Richtlinien: Damit das Markup auch wirkt

Ein technisch korrektes JobPosting-Schema nützt nichts, wenn die zugrunde liegende Seite nicht sauber ausgeliefert wird. Google prüft nicht nur, ob die Felder vorhanden sind, sondern auch, ob die Seite selbst indexierbar ist.

1. Eigene, dauerhafte URL pro Stelle. Jede Position braucht eine feste Adresse, die nicht bei jedem Sync des ATS neu generiert wird. Dynamische Parameter oder wechselnde IDs verwirren die Indexierung.

2. Keine automatischen Redirects auf abgelaufene Stellen. Wenn eine Position besetzt ist, sollte die Seite das klar zeigen oder mit Statuscode 410 verschwinden, statt stillschweigend auf die Startseite umzuleiten.

3. Keine noindex-Anweisung und keine robots-Blockade. Ein einzelner noindex-Meta-Tag oder eine Sperre in der robots.txt reicht aus, um die gesamte strukturierte Auszeichnung wirkungslos zu machen.

4. JSON-LD statt Microdata. Google empfiehlt JSON-LD, weil es unabhängig vom sichtbaren HTML eingebettet werden kann und Entwickler es leichter pflegen. Microdata verlangt, dass jedes Attribut direkt im sichtbaren Markup sitzt, was bei Redesigns schnell bricht.

5. Platzierung im HTML-Head oder -Body. JSON-LD funktioniert an beiden Stellen, solange das Skript vom Server ausgeliefert wird und nicht erst nachträglich per JavaScript nachgeladen werden muss, ohne dass eine serverseitige Fassung existiert.

6. Konsistente Datumslogik. datePosted darf nicht nach validThrough liegen, und beide Werte sollten mit dem sichtbaren Text übereinstimmen.

Profi-Tipp: Bauen Sie eine automatisierte Prüfung in Ihre Veröffentlichungs-Pipeline ein, die vor dem Live-Schalten kontrolliert, ob die JSON-LD-Struktur vollständig ist. Das spart deutlich mehr Zeit als die manuelle Fehlersuche nach dem Launch.

Die technische Indexierbarkeit ist erfahrungsgemäß die größte Stolperquelle: Ohne eine stabile URL, ohne serverseitig ausgeliefertes HTML und ohne saubere Canonical-Tags bleibt selbst ein perfekt gefülltes Schema wirkungslos, wie auch 360HR in seiner Analyse zu Google-Jobs-Fehlern beschreibt.

Wie sehen fertige JobPosting-Beispiele aus?

Die folgenden drei JSON-LD-Blöcke lassen sich direkt kopieren und an die eigene Stelle anpassen. Jedes Beispiel zeigt eine andere Konstellation, wie sie in der Praxis am häufigsten vorkommt.

Standard-Stellenanzeige (Vollzeit, Büro vor Ort):

{

"@context": "https://schema.org/",

"@type": "JobPosting",

"title": "Softwareentwickler (m/w/d) Java",

"description": "Wir suchen einen erfahrenen Java-Entwickler für unser Backend-Team.",

"datePosted": "2026-02-10",

"validThrough": "2026-04-10",

"employmentType": "FULL_TIME",

"hiringOrganization": {

"@type": "Organization",

"name": "Musterfirma GmbH",

"sameAs": "https://www.musterfirma.de"

},

"jobLocation": {

"@type": "Place",

"address": {

"@type": "PostalAddress",

"streetAddress": "Musterstraße 12",

"addressLocality": "München",

"postalCode": "80331",

"addressCountry": "DE"

}

},

"baseSalary": {

"@type": "MonetaryAmount",

"currency": "EUR",

"value": {

"@type": "QuantitativeValue",

"minValue": 55000,

"maxValue": 70000,

"unitText": "YEAR"

}

}

}

Remote- beziehungsweise Homeoffice-Stelle: Hier kommt zusätzlich jobLocationType mit dem Wert TELECOMMUTE hinzu, ergänzt um applicantLocationRequirements, das die zulässigen Länder für Bewerber festlegt.

Teilzeit- oder befristete Stelle: employmentType wechselt zu PART_TIME oder TEMPORARY, und ein zusätzliches Feld workHours kann die genaue Stundenzahl angeben, etwa „20 Stunden pro Woche“.

Kommentarzeilen im eigenen Code, auch wenn sie im finalen JSON-LD entfernt werden müssen, helfen Entwicklern und Recruitern beim Onboarding neuer Kollegen, weil sie sofort erkennen, welches Feld wofür steht.

Wie prüft man strukturierte Daten auf Fehler?

Zwei Werkzeuge gehören in jeden Veröffentlichungsprozess. Der Google Rich Results Test zeigt, ob Google die Stelle tatsächlich als Rich Result erkennt und welche Felder für die erweiterte Darstellung fehlen. Validator prüft dagegen unabhängig von Google, ob die Syntax und die Feldnamen dem Schema.org-Standard entsprechen. Beide Tools ergänzen sich: Der eine zeigt Google-spezifische Anforderungen, der andere die allgemeine Schema-Konformität.

Eine kurze Checkliste vor jedem Livegang:

• Erscheint die Stelle im Rich-Results-Test als gültig, ohne Warnungen bei Pflichtfeldern?

• Stimmen Jobtitel und Standort im JSON-LD exakt mit dem sichtbaren Text überein?

• Führt der Bewerbungslink tatsächlich zu einem funktionierenden Formular, nicht zu einer 404-Seite?

• Liegt datePosted vor validThrough, und sind beide im ISO-8601-Format?

• Leitet die URL nirgendwo unerwartet weiter?

Bei Validierungsfehlern lohnt sich eine Priorisierung: Fehlende Pflichtfelder blockieren die gesamte Ausspielung und müssen zuerst behoben werden. Warnungen zu empfohlenen Feldern wie baseSalary verringern nur die Darstellungsqualität, sind aber kein Show-Stopper.

Warum werden Stellenanzeigen bei Google nicht angezeigt?

Die häufigste Ursache ist ein Widerspruch zwischen dem sichtbaren Text und den strukturierten Feldern, etwa wenn im Fließtext „Homeoffice möglich“ steht, das Schema aber keinen jobLocationType enthält. Google wertet solche Diskrepanzen als Qualitätsproblem.

• Ein noindex-Tag oder eine robots.txt-Sperre auf der Job-URL verhindert jede Indexierung, unabhängig davon, wie sauber das JSON-LD ist.

• Fehlerhafte Canonical-Tags, die auf eine andere Seite verweisen, entwerten das Markup der eigentlichen Stelle.

• Abgelaufene Stellen sollten nicht einfach gelöscht werden, ohne den Status zu kennzeichnen. Besser ist ein klarer 410-Statuscode oder eine sichtbare Kennzeichnung als „besetzt“, statt eine stille Weiterleitung.

• Beim Multiposting auf mehrere Jobbörsen entstehen oft Inkonsistenzen, weil Portale wie StepStone oder XING eigene Eingabemasken und Anzeigenformate verlangen, die von der eigenen Karriereseite abweichen können.

Profi-Tipp: Führen Sie ein zentrales Änderungsprotokoll für Jobdaten. Wenn Gehalt oder Standort geändert werden, muss das gleichzeitig im sichtbaren Text, im JSON-LD und auf allen verbundenen Jobbörsen aktualisiert werden.

Wie sollte ein ATS strukturierte Jobdaten technisch ausgeben?

Ein Bewerbermanagementsystem sollte für jede Stelle automatisch eine stabile, dauerhaft erreichbare URL erzeugen, die auch nach internen Umstrukturierungen bestehen bleibt. Die Grundlage dafür ist ein einziges „Single Source of Truth“-Datenmodell: Sichtbarer Text und JSON-LD werden aus derselben Datenbank generiert, statt getrennt gepflegt zu werden. Das verhindert genau die Widersprüche, die weiter oben als häufigste Fehlerquelle genannt wurden.

1. Zentrale Datenhaltung: Ein Feld ändert sich einmal, wirkt sich aber überall aus, wo die Stelle erscheint.

2. Portalspezifische Ausgabe beim Multiposting: Jobbörsen wie meinestadt.de oder HotelCareer verlangen eigene Formate und teils eigene Brandingansätze, etwa ein flexibles Anzeigen-Layout, das sich an das jeweilige Portal-Design anpasst.

3. Lifecycle-Management: Veröffentlichung, Ablaufdatum und Archivierung sollten automatisiert ablaufen, damit keine verwaisten, aber weiterhin indexierten Altanzeigen im Netz stehen bleiben.

Strukturierte Daten sind kein Randthema mehr

Strukturierte Daten in Stellenanzeigen sind längst kein technisches Detail für Spezialisten mehr, sondern die Brücke zwischen dem ATS und der Art, wie Suchmaschinen Inhalte heute verarbeiten. Wer CV-Parsing, Automatisierung und DSGVO-konforme Prozesse ernst nimmt, sollte dieselbe Sorgfalt auf die Ausgabeseite legen. Recruitify unterstützt genau diesen Übergang mit einem integrierten Ansatz aus ATS und Datenmanagement.

- Recruitify Team

Recruitify als zentrale Lösung für saubere Jobdaten

Recruitify ist die Antwort auf genau das Problem, das dieser Artikel beschrieben hat: getrennte Datenquellen, die zu Widersprüchen zwischen sichtbarer Anzeige und strukturiertem Markup führen. Statt Jobdaten manuell in mehreren Systemen zu pflegen, bündelt Recruitify ATS, CRM und Multiposting in einer Plattform, sodass Titel, Standort, Gehalt und Beschäftigungsart aus einer einzigen Quelle stammen und automatisch konsistent bleiben.

Ein CV-Parser extrahiert Kandidatendaten aus PDFs und Scans schnell, während Rollenmanagement und DSGVO-Anonymisierung dazu beitragen, dass Datenbanken rechtlich sauber bleiben. Für Recruiting-Agenturen und HR-Abteilungen, die ihre Karriereseite mit korrektem JobPosting-Schema ausstatten wollen, ohne jede Stelle manuell zu pflegen, sind Automatisierungsfunktionen von SaaS-Plattformen hilfreich. Wer prüfen möchte, wie sich das in der eigenen Umgebung umsetzen lässt, kann direkt eine Demo bei Recruitify buchen und sich zeigen lassen, wie strukturierte Jobdaten ohne zusätzlichen manuellen Aufwand entstehen.

Quellen

• Strukturierte Daten für Stellenausschreibungen (JobPosting) – Google Developers

• Schema

• Validator

FAQ

Was sind Beispiele für strukturierte Daten in Stellenanzeigen?

Beispiele sind Felder wie title, hiringOrganization, jobLocation und datePosted im JSON-LD-Format, die Google und andere Suchmaschinen direkt auslesen können, wie im JSON-LD-Beispiel weiter oben gezeigt.

Was ist die Definition von strukturierten Daten?

Strukturierte Daten sind ein standardisiertes Format, mit dem Inhalte einer Webseite in einem maschinenlesbaren Vokabular wie Schema.org ausgezeichnet werden, damit Suchmaschinen die Bedeutung der Inhalte eindeutig erkennen.

Wie kann ich strukturierte Daten überprüfen?

Nutzen Sie den Google Rich Results Test für die Google-spezifische Darstellung und validator.schema.org für die allgemeine Schema-Konformität von Syntax und Feldnamen.

Welches ist das beste Jobportal für strukturierte Anzeigendaten?

Es gibt keine einzelne beste Plattform, da Portale wie StepStone, XING/onlyfy oder meinestadt.de jeweils eigene Eingabemasken und Brandingformate verlangen. Eine ATS-Plattform wie Recruitify kann diese Portalspezifika beim Multiposting automatisch berücksichtigen.

Reicht ein JobPosting-Schema für gute Platzierungen bei Google for Jobs?

Ein vollständiges Schema ist die Grundvoraussetzung, aber die Seite muss zusätzlich technisch indexierbar sein, also ohne noindex-Tag, mit stabiler URL und korrekten Canonicals, damit die Ausspielung tatsächlich funktioniert.