Was ist Google for Jobs – und warum es für Recruiting zählt
Google for Jobs bündelt Stellenanzeigen aus dem offenen Web in der Google-Suche. Nutzer:innen sehen ein Jobs-Karussell oder eine gefilterte „Jobs“-Ansicht mit Titel, Arbeitgeber, Standort, Veröffentlichungsdatum und – wenn gepflegt – Vergütung oder Beschäftigungsart. Ein Klick führt zur Stellenquelle: oft Ihre Karriereseite, manchmal ein Applicant-Tracking-System (ATS) oder eine Jobbörse.
Für Arbeitgeber ist das ein organischer Kanal neben Jobboards und Social Ads: Sie zahlen nicht pro Klick an Google nur deshalb, weil Ihre Stelle erscheint. Die Investition sitzt in Technik (korrekte Auszeichnung, saubere URLs), Prozess (Stellen ein- und ausblenden, keine veralteten Inserate) und Inhalt (klarer Stellentext, der zur Suche passt).
Die zentrale Voraussetzung: Google muss Ihre Seite crawlen, eine Stelle erkennen und einem gültigen JobPosting-Objekt nach Schema.org zuordnen können – typischerweise als JSON-LD. Alternativ können qualifizierte Partner-Feeds (manche ATS- oder Board-Anbindungen) die gleiche Information liefern; die meisten mittelständischen Setups arbeiten heute mit eigener Domain + Schema oder ATS-Embed auf der eigenen Domain.
Wie Stellen bei Google „ankommen“
Google indexiert Stellen wie normale Webdokumente, mit einem Schwerpunkt auf strukturierten Daten:
- Crawling: Die Job-URL muss für Googlebot erreichbar sein (kein Block in robots.txt, keine Noindex auf der live geschalteten Stelle).
- Rendering: Stelleninfo und JSON-LD sollten im HTML-Response oder im initialen Rendering stehen. Reine Client-Only-Listen ohne SSR riskieren, dass Crawler leere Seiten sehen.
- Validierung: Das JobPosting muss den aktuellen Anforderungen von Google entsprechen; der Rich-Results-Test und die Search Console zeigen konkrete Fehler.
- Deduplizierung: Dieselbe physische Stelle sollte nur eine bevorzugte URL haben – sonst konkurrieren ATS, Karriereseite und Drittboards miteinander.
Nach dem Go-Live: In der Google Search Console unter „Jobs“ bzw. strukturierten Daten / Verbesserungen sehen Sie, ob JobPosting erkannt wird und welche URLs betroffen sind. Fehlermeldungen wörtlich nehmen und gezielt pro Feld beheben – oft sind es Datumsformate, fehlende hiringOrganization oder mehrdeutige Standorte.
Pflichtlogik vs. empfohlene Felder
Die Google-Dokumentation zu JobPosting listet erforderliche und empfohlene Properties; fehlende Pflichtfelder führen dazu, dass die Stelle nicht für Rich Results qualifiziert ist. Typischerweise zählen zu den sensiblen Pflichtfeldern Kombinationen aus:
- title – der sichtbare Jobtitel, ohne Tricks wie „BEST JOB!!!“ oder Keyword-Stuffing.
- description – vollständiger HTML- oder Fließtext mit Aufgaben, Profil, Benefits; reine Generisch-Boilerplates wirken dünn und verwässern Signale.
- datePosted – ISO 8601; achten Sie auf Zeitzone (z. B. mit Offset), wenn das ATS Datumswerte automatisch setzt.
- hiringOrganization – Organisation mit Name;
sameAs(z. B. Link zur Unternehmensseite oder konsistentes Profil) stärkt die Zuordnung. - jobLocation bzw. je nach Setup applicantLocationRequirements bei reinem Remote – Remote-Jobs brauchen eine klare Modellierung (siehe unten).
validThrough ist nicht überall formal „Pflicht“, aber praktisch unverzichtbar: Ohne realistisches Ende oder Update wirken Stellen wie Altlasten. Setzen Sie ein Ablaufdatum oder entfernen Sie Schema und Inhalt, sobald die Rolle besetzt ist.
identifier (interne Stellen-ID), employmentType (FULL_TIME, PART_TIME, CONTRACTOR …), baseSalary mit Währung und Zeitraum (YEAR/MONTH/HOUR), industry, occupationalCategory – all das verbessert Filter in der Oberfläche und Matching. Wo Tarifbindung oder interne Policy Gehaltsnennung verbieten, lassen Sie Gehalt weg – dann entfallen zwar manche Filtervorteile, die Stelle kann dennoch lauffähig sein, wenn alle Pflichtfelder stimmen.
Remote, hybrid und mehrere Standorte
Mischung aus Büro und Homeoffice ist Regelfall. Google unterscheidet Jobs mit physischem Standort von Jobs mit Remote-Charakter. Je nach Schema-Version und Empfehlung können u. a. gelten:
- Physische Rolle: jobLocation mit PostalAddress oder Place.
- Rein remote (wo rechtlich und organisatorisch klar): Nutzung der vorgesehenen Felder für TELECOMMUTE bzw. applicantLocationRequirements – statt eines erfundenen Pflicht-Standorts.
- Mehrere Büros „für denselben Job“: Entweder eine URL pro Standort oder eine saubere URL-Logik – vermeiden Sie, dieselbe Stellen-ID mit widersprüchlichen Orten auf vielen URLs zu spiegeln.
Wichtig: Was im Schema steht, muss zum sichtbaren Stellenkopf und zum Bewerbungsweg passen. Widersprüche (Remote im Titel, aber nur Hamburg im Schema) verwirren Kandidat:innen und sind ein klassischer Grund für schlechtere Darstellung oder manuelle Korrektur.
Bewerbungs-URL: Flow und Tracking
Der konkrete Bewerbungsweg hängt von CMS und ATS ab (Felder wie direkter Link, ApplicationContact etc.). Kernpunkte:
- Eine klare, messbare URL pro Kanal hilft: UTM-Parameter sind erlaubt, solange die Seite nicht auf Noindex oder Soft-404 läuft.
- Wenn Bewerbungen über ein externes ATS laufen, sollten Nutzer:innen nicht durch eine Kette unnötiger Weiterleitungen fallen; Mobile-UX wirkt sich auf Absprungrate und Conversion aus.
- Consent & DSGVO: Formulare, Hinweise zu Speicherfristen und ggf. Cookie-Banner müssen zum Rest der Karriereseite passen – technische Sichtbarkeit ersetzt keine Compliance-Prüfung des Bewerbungsprozesses.
Für kampagnenbasiertes Recruiting ergänzen sich sinnvoll unsere Artikel zur Lead-Generierung und zu Recruiting-KPIs – dort gehen wir tiefer auf Conversion und Attribution ein.
ATS vs. eigene Seite: Wo liegt die „Wahrheit“?
Viele Unternehmen pflegen Stellen primär im ATS; die Karriereseite zieht per Feed oder Embed nach. Das ist gut skalierbar, birgt aber Risiken:
- Doppelte Quellen: ATS auf Subdomain und Kopie auf der Hauptdomain – beide mit JobPosting ergibt Duplikate.
- Verzögerte Syncs: Stelle intern geschlossen, Website zeigt noch „offen“.
- Eingeschränktes HTML: Der Feed liefert zu kurze Descriptions oder entfernt Formatierung.
Best Practice: Eine canonical Quelle definieren (meist die öffentliche URL auf Ihrer Hauptdomain), von dort JobPosting generieren und andere Systeme nur verlinken oder per Canonical bündeln. Wenn Ihr ATS das nicht sauber kann, ist ein schlankes Next.js-Frontend mit serverseitig erzeugtem Schema oft die stabilste Lösung.
Technische Fehlerquellen (und wie Sie sie lösen)
1. JavaScript-only Stellenlisten
SPAs ohne SSR: Google kann zwar rendern, aber Zeitbudget und Reihenfolge sind endlich. Stellenlisten und Details sollten im ersten Response oder per statischer Generierung sichtbar sein – besonders bei vielen offenen Jobs.
2. Session-IDs und Parameter-URLs
Jede Stelle braucht eine stabile URL. Zufalls- oder Session-Parameter erzeugen technische Duplikate.
3. Noindex auf Jobdetail
Entwickler setzen manchmal pauschal „noindex“ auf „alles außer Marketing“ – und blockieren damit Jobs. Prüfen Sie Meta-Robots und Header pro Template.
4. Abgelaufenes JobPosting bei noch erreichbarer URL
Wenn die Rolle geschlossen ist: Stelle offline nehmen. Ein 404/410 für die URL ist vertretbar – dann darf kein altes JobPosting mehr mit ausgeliefert werden.
5. Mehrsprachigkeit
Pro Sprache eine URL plus hreflang; nicht Deutsch und Englisch im selben description-String mischen. JSON-LD sollte zur sichtbaren Sprache der Seite passen.
Inhaltliche Qualität: Stellentext als SEO- und Conversion-Hebel
Google for Jobs ersetzt keinen überzeugenden Inhalt. Gute Anzeigen:
- Beantworten in den ersten Absätzen Rolle, Team, Standort/Remote, nächste Schritte.
- Nennen Anforderungen realistisch (Must-haves vs. Nice-to-haves).
- Erklären Arbeitsmodell, Benefits, Entwicklung – ohne leere Marketing-Floskeln.
- Nutzen Begriffe, die Kandidat:innen wirklich suchen – nicht nur interne Joblevel-Codes.
Das stützt parallel die Karriereseite SEO: Tiefe, interne Verlinkung und Arbeitgeberstory erhöhen Vertrauen vor dem Klick auf Bewerben.
Praxis-Checkliste vor dem Livegang
- URL-Konzept: Eine kanonische Job-URL pro Stelle; Parameter- und Duplikat-URLs bereinigt.
- JSON-LD: JobPosting im Rich Results Test validiert; Pflichtfelder ohne Fehler.
- Datumswerte: datePosted korrekt; validThrough oder automatisches Auslaufen geklärt.
- Standort/Remote: Modellierung konsistent mit Stellentext und internen Vorgaben.
- Gehalt: Wenn möglich und erlaubt eintragen – in vielen Märkten starker Hebel in der Jobsuche.
- Bewerbungsflow: Mobile getestet; Formular funktioniert; Danke-Seite bzw. Event messbar.
- Search Console: Property verifiziert; Sitemap mit Job-URLs; Jobs-Bericht beobachten.
- HR ↔ Marketing: Prozess, wenn Stellen geschlossen werden – ohne Lücken zwischen ATS und Website.
Google for Jobs und bezahltes Recruiting
Organische Jobs ergänzen Performance-Recruiting – sie ersetzen es in angespannten Arbeitsmärkten selten vollständig. Sinnvolle Arbeitsteilung:
- Google for Jobs liefert nachhaltige Sichtbarkeit für Rollen mit klarer Suchnachfrage.
- Paid Social / Search erreicht passive Kandidat:innen und bringt kurzfristig Volumen.
- Gleiche Story und konsistente Bewerbungs-URLs vermeiden verwirrtes Reporting.
Häufige Fragen (FAQ)
Muss jedes Unternehmen eigenes JSON-LD bauen?
Nein – wenn CMS oder ATS valides JobPosting ausliefert und Duplikate vermeidet, reicht das. Eigenbau lohnt sich, wenn Templates zu starr oder fehleranfällig sind.
Warum erscheint die Stelle nicht, obwohl der Test „grün“ ist?
Indexierung braucht Zeit; außerdem greifen Qualitäts- oder Duplikatslogiken. Prüfen Sie Search Console, Crawling und ob die URL unter der kanonischen Domain indexiert wird.
Dieselbe Stelle auf Jobbörse und eigener Seite?
Ja – aber definieren Sie die Hauptquelle (canonical / eine vollständige JobPosting-Seite). Mehrfach identische Snippets schaden der Nutzererfahrung.
Wie oft JobPosting aktualisieren?
Bei Änderungen an Titel, Gehalt, Remote etc. zeitnah; im Betrieb validThrough und HR-Status synchron halten.
Fazit
Google for Jobs ist ein technik- und prozessgetriebenes System: sauberes JobPosting, stabile URLs, keine Duplikate und stets aktuelle Daten sind das Fundament. Darauf setzt ein Stellentext, der Menschen und Suchmaschinen gleichermaßen überzeugt. Wer das dauerhaft pflegt, sichert sich Sichtbarkeit in der Job-Suche – ergänzend zu und nicht zwingend im Wettbewerb mit bezahlten Kanälen.
Wenn Sie Schema, Karriereseite und Recruiting-Kampagnen zusammenführen möchten, melden Sie sich bei uns – wir unterstützen bei Architektur, Umsetzung und Messbarkeit über den Bewerbungsweg hinweg.
