Stellenanzeigen auf der Website einbinden: Widget oder eigene Seiten?

Was das Job-Widget wirklich einbindet

Jedes Bewerbermanagement bringt eine fertige Einbindung mit. Ein Codeschnipsel ins CMS, und die offenen Stellen erscheinen auf der Karriereseite. Personio, d.vinci, talentstorm und Recruitee bieten das alle an, und für den ersten Tag ist es die richtige Entscheidung: Es kostet nichts und dauert zwanzig Minuten.

Was dabei entsteht, ist allerdings meist nur eine Liste. Klickt jemand auf eine Stelle, landet er auf einer Detailseite, die beim Anbieter liegt, erkennbar an Adressen wie unternehmen.jobs.personio.de oder einer vergleichbaren Subdomain. Die Stellenbeschreibung, also der eigentliche Inhalt, für den Leute suchen, steht damit nicht auf deiner Website.

Das hat drei Folgen, die im Alltag nacheinander auffallen. Die Stelle lässt sich nicht als Seite deiner Domain teilen. Das Design endet dort, wo der Anbieter sein eigenes beginnt. Und die Suchmaschine ordnet die Anzeige nicht deinem Unternehmen zu, sondern der fremden Domain.

Was Google für eine Stellenanzeige braucht

Google zeigt Stellen in einer eigenen Oberfläche an, der Jobsuche, die in Deutschland aktiv ist. Damit eine Anzeige dort erscheinen kann, braucht Google eine indexierbare Seite mit strukturierten Daten vom Typ JobPosting. Pflicht sind fünf Angaben: title, description, datePosted, hiringOrganization und jobLocation. Hat die Stelle ein Ablaufdatum, kommt validThrough dazu.

Der verbreitete Einwand lautet, dass Google JavaScript rendert und ein modernes Widget deshalb gelesen wird. Das stimmt auch. Nur beantwortet es die falsche Frage. Entscheidend ist nicht, ob der Text irgendwann gerendert wird, sondern welche URL Google für diese Stelle kennt. Liegt die Detailseite auf der Anbieter-Subdomain, ist es deren Seite, nicht deine.

Dazu kommt ein zweiter Punkt, der selten erwähnt wird. Google betreibt neben dem normalen Crawling eine Indexing API, und die akzeptiert bis heute genau zwei Inhaltstypen: JobPosting und BroadcastEvent. Über sie lässt sich eine neue Stelle sofort zum Crawling anmelden und eine besetzte Stelle sofort wieder aus dem Index entfernen. Google weist ausdrücklich darauf hin, dass viele abgelaufene Anzeigen die Sichtbarkeit aller Anzeigen einer Website drücken können.

Diesen Kanal kannst du nur nutzen, wenn die Stellen auf deiner Domain liegen. Für eine Stelle, die zwei Wochen offen ist, ist das der Unterschied zwischen „ab morgen sichtbar“ und „sichtbar, wenn der Crawler das nächste Mal vorbeikommt“.

Vier Wege auf die Website im Vergleich

Zwischen dem Codeschnipsel und der vollen Anbindung liegen zwei weitere Stufen. Die Entscheidung hängt weniger am Budget als an der Frage, wie viele Stellen du führst und wie lange sie offen sind.

Für drei Stellen im Jahr ist das Widget völlig ausreichend. Wer dauerhaft zehn oder mehr Positionen offen hat, verschenkt damit den Kanal, der für kurzlebige Inhalte gebaut wurde.

Richtung eins: die Stellen aus dem System holen

Die Redaktion soll Stellen weiterhin im Bewerbermanagement pflegen, nicht zusätzlich im CMS. Das ist die Grundregel jeder Anbindung: Ein System führt, alle anderen zeigen an. Die Website holt sich die Daten also regelmäßig ab und legt sie als eigene Inhalte an.

Was die vier Systeme dafür anbieten

Bei Personio und Recruitee ist die Dokumentation öffentlich, du kannst den Feed vor dem Projekt im Browser ansehen und weißt sofort, welche Felder geliefert werden. Bei d.vinci und talentstorm liegt sie hinter dem Kundenzugang. Fordere sie an, bevor jemand einen Aufwand schätzt, denn genau dort entscheidet sich, ob Filter nach Standort und Abteilung später möglich sind oder nicht.

Aus Feed-Einträgen werden eigene Seiten

Technisch ist das kein Hexenwerk: Ein geplanter Abruf liest den Feed, legt für jede Stelle einen eigenen Inhalt an, aktualisiert geänderte und nimmt verschwundene offline. In WordPress ist das ein eigener Inhaltstyp mit eigenen Feldern, ähnlich wie bei eigenen Gutenberg-Blöcken die Struktur vorgegeben wird, statt sie in einen Freitext zu kippen.

Drei Punkte entscheiden über die Qualität, und alle drei werden gern übersehen:

• Was passiert mit besetzten Stellen? Eine gelöschte Seite liefert 404. Besser ist eine Weiterleitung auf die Stellenübersicht, damit Besucher aus Suchergebnissen und Mails nicht ins Leere laufen.
• Was passiert, wenn der Feed nicht antwortet? Die letzte funktionierende Fassung muss stehen bleiben. Eine Karriereseite, die bei einer Zeitüberschreitung „keine offenen Stellen“ zeigt, ist schlimmer als eine veraltete.
• Wie oft wird abgerufen? Stellen ändern sich selten. Ein Abruf alle fünfzehn Minuten reicht praktisch immer, stündlich meistens auch.

Das JobPosting-Schema, die Pflichtfelder

Auf jeder Stellenseite steht dann ein Block strukturierter Daten. Dieses Beispiel enthält die Pflichtfelder und lässt sich als Vorlage nehmen. Wer nur wissen will, ob sich der Aufwand lohnt, kann den Block überspringen.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Bilanzbuchhalter (m/w/d)",
  "description": "<p>Vollständige Beschreibung als HTML</p>",
  "datePosted": "2026-09-19",
  "validThrough": "2026-11-30",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Musterfirma GmbH",
    "sameAs": "https://www.musterfirma.de"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "Musterstraße 1",
      "postalCode": "10115",
      "addressLocality": "Berlin",
      "addressCountry": "DE"
    }
  }
}
</script>

Die Beschreibung gehört als HTML in das Feld, mit Absätzen und Listen, nicht als zusammengeschobener Fließtext. Und sie muss mit dem übereinstimmen, was auf der Seite sichtbar steht. Strukturierte Daten, die mehr behaupten als die Seite zeigt, sind ein Grund für eine manuelle Maßnahme und keine Abkürzung.

Gehalt, Homeoffice-Anteil und Beschäftigungsart sind freiwillig, werden aber ausgespielt, wenn sie da sind. Wenn dein Bewerbermanagement diese Felder führt, nimm sie mit.

Richtung zwei: die Bewerbung zurück ins System

Die zweite Richtung wird oft vertagt, und das rächt sich. Wenn die Stellen zwar schön auf der Website liegen, der Bewerbungsknopf aber auf das Portal des Anbieters springt, war der ganze Aufwand nur halb gemacht. Der Bruch sitzt genau an der Stelle, an der jemand bereit ist, sich zu bewerben.

Ein eigenes Formular auf deiner Seite, das die Bewerbung per API ins System schreibt, löst das. Personio nimmt Bewerbungen über die Recruiting API entgegen, Recruitee über die Careers Site API, bei der Name, E-Mail und Lebenslauf als Pflichtfelder vorgesehen und teilweise abschaltbar sind.

Was das Formular können muss

• Anhänge mit Grenzen. Lebenslauf, Zeugnisse, Anschreiben. Maximale Dateigröße und erlaubte Formate stehen im Zielsystem, nicht in deiner Fantasie. Wer zwanzig Megabyte zulässt, die das System ablehnt, produziert Abbrüche nach dem Upload.
• Große Dateien im Hintergrund. Ein Upload von mehreren Megabyte darf den Absendevorgang nicht blockieren. Erst annehmen und bestätigen, dann übertragen.
• Eine Bestätigung, die ankommt. Wer sich beworben hat, will es schwarz auf weiß. Ob die Mail aus deinem System oder aus dem Bewerbermanagement kommt, ist eine Entscheidung, keine Nebensache.
• Pflichtfelder aus dem Zielsystem ableiten. Fehlt ein Feld, das die API verlangt, scheitert die Übertragung erst nach dem Absenden. Das merkt niemand, außer der Bewerberin, die nie eine Antwort bekommt.

Wenn die Übertragung fehlschlägt

Der wichtigste Teil ist der, den niemand plant. Die API ist nicht erreichbar, das Zertifikat läuft aus, ein Feld wurde umbenannt: Dann darf die Bewerbung nicht verloren gehen. Der belastbare Aufbau speichert sie zuerst bei dir, versucht die Übertragung danach und wiederholt sie bei einem Fehler.

Dazu gehört eine Benachrichtigung an einen Menschen, nicht nur ein Eintrag im Protokoll. Eine Bewerbung, die drei Tage in einer Warteschlange liegt, ohne dass jemand davon weiß, ist praktisch verloren, denn wer sich bewirbt, bewirbt sich selten nur bei einem Unternehmen.

Bewerberdaten sind ein eigener Fall

Bewerbungsunterlagen gehören zu den sensibleren Daten, die eine Website verarbeitet. Sie enthalten Lebenslauf, Anschrift, oft ein Foto und gelegentlich Angaben, die man gar nicht haben will. Vier Punkte sind vor dem Livegang zu klären, und sie gehören schriftlich geklärt, nicht mündlich:

• Wo liegen die Anhänge zwischen Formular und Zielsystem? Auf dem Webserver, und wie lange? Nach erfolgreicher Übertragung gehören sie dort gelöscht.
• Wer ist Auftragsverarbeiter? Für das Bewerbermanagement braucht es einen Vertrag nach Art. 28 DSGVO, für den Hoster ebenfalls.
• Welche Löschfristen gelten? Nach einer Absage werden Unterlagen üblicherweise nach einigen Monaten gelöscht, sofern keine Einwilligung für einen längeren Verbleib im Talentpool vorliegt. Diese Einwilligung muss freiwillig und getrennt erfolgen.
• Was steht im Formular? Ein Hinweis auf die Datenverarbeitung mit Verweis auf die Datenschutzerklärung gehört dorthin, wo abgesendet wird. Was sonst noch zu beachten ist, steht in der DSGVO-Checkliste für Websites.

Ein praktischer Nebeneffekt der eigenen Anbindung: Du weißt, wo die Daten liegen. Beim Widget eines Anbieters läuft die Erfassung über dessen Infrastruktur, und die Frage nach dem Verarbeitungsverzeichnis ist trotzdem deine.

Was vor der Umsetzung geklärt sein muss

Bevor jemand einen Aufwand nennt, gehören die üblichen Fragen auf den Tisch: Welches System führt, wie kommen die Daten heraus, was passiert bei Konflikten und Ausfällen, und gibt es eine Testumgebung. Für Bewerbermanagement gilt dasselbe wie für eine Warenwirtschaft oder ein Buchungssystem. Der vollständige Fragenkatalog steht auf der Seite zu Schnittstellen und Anbindungen, zusammen mit dem Ablauf und dem, was den Aufwand bestimmt.

Fazit

Das Widget ist nicht falsch, es ist nur eine Entscheidung mit Preis. Der Preis ist, dass deine Stellen auf einer fremden Domain liegen, kein eigenes JobPosting-Schema tragen und der einzige schnelle Weg in den Google-Index für dich verschlossen bleibt.

Wer wenige Stellen im Jahr besetzt, kann das getrost hinnehmen. Wer dauerhaft sucht, sollte die Stellen als eigene Seiten führen und das Bewerbungsformular gleich mitnehmen: Die Redaktion pflegt weiter im Bewerbermanagement, die Sichtbarkeit bleibt bei dir, und der Bewerbungsweg endet nicht auf einer fremden Subdomain.

Agenturen, die eine Karriereseite für einen Kunden bauen und die Anbindung nicht selbst machen wollen, finden den Rahmen dafür unter WordPress-Entwicklung für Agenturen.

Quellen

• Google Search Central: JobPosting structured data
• Google Search Central: Using the Indexing API
• Personio: Stellen per XML in die Website einbinden
• Personio: Overview of the Recruiting API
• Recruitee: Intro to Careers Site API