// stack · schnittstelle
rexx systems ist eine modulare HR-Software aus Hamburg — mit einem Recruiting-Modul, in dem Stellenausschreibungen und Bewerbungen zusammenlaufen. Die spannende Frage für eine Website ist die Strecke dazwischen: Wie kommen diese Stellen auf die eigene Karriereseite — und zwar so, dass sie dort wie eigene Seiten aussehen, funktionieren und gefunden werden. siteway baut diese Strecke.
// definition
rexx systems ist eine modulare HR-Software der rexx systems GmbH aus Hamburg. Das Unternehmen wurde im Jahr 2000 gegründet, sitzt in der Süderstraße und hat weitere Standorte in Wien und Zürich. Die rexx Suite gliedert sich in drei Bereiche: HR-Management rund um die digitale Personalakte, Bewerbermanagement mit Karriereportal, Multiposting und Online-Assessment sowie Talent Management mit Mitarbeiterentwicklung, Skill-Management und Nachfolgeplanung. Typische Nutzer sind Personalabteilungen im Mittelstand und in Konzernen, die ihre Prozesse in einem System bündeln.
Für eine Website ist davon genau ein Ausschnitt relevant: das Recruiting-Modul. Dort legt die Personalabteilung Ausschreibungen an, dort läuft der Bewerbungsprozess, dort liegen die Unterlagen. Die Website ist die Schauseite dieses Systems — sie zeigt die offenen Stellen und nimmt Bewerbungen entgegen, ohne selbst zum zweiten Datenhaushalt zu werden. Genau diese Trennung macht die Anbindung überhaupt erst sauber: siteway behandelt rexx als führendes System und die Website als Anzeige.
// praxis
daten holen · selbst rendern
Es gibt nicht den einen Anschluss. rexx selbst beschreibt gleich mehrere Wege, wie Stellenanzeigen aus der Recruiting-Software auf eine Unternehmens-Website kommen: eine eigenständige Karriereseite mit eigener URL, Reverse Proxy beziehungsweise Server Side Includes, eine iFrame-Einbindung, ein Popup- oder Layer-Fenster, den XML-Export samt RSS-Feed sowie Widgets für Blogs und Microsites. Daneben steht der rexx Hub, die Integrationsplattform des Herstellers mit einer REST-API nach OpenAPI-Standard, Berechtigungssteuerung und Protokollierung.
Wir gehen den datengetriebenen Weg, wo er möglich ist: Stellen als Daten abholen, ins CMS übersetzen und die Seiten selbst rendern. Der Grund ist nicht Geschmack, sondern Kontrolle. Nur bei eigenem Markup entscheiden wir über strukturierte Daten, Barrierefreiheit, Ladeverhalten und URL-Struktur — also über genau die Punkte, an denen eine Karriereseite gefunden wird oder eben nicht.
Der erste Schritt ist deshalb immer eine Sichtung: Welche Wege sind in eurem Vertrag freigeschaltet, welche Felder liefert die Quelle, wie sind Standorte und Bereiche benannt, wie sieht der Bewerbungsweg aus. Daraus entsteht ein Feld-Mapping, und erst danach wird gebaut — dasselbe Vorgehen wie bei jeder anderen Schnittstelle.
Drei Bauweisen, drei Charaktere. Sie unterscheiden sich nicht in der Qualität, sondern darin, wo die Arbeit liegt und wem das Ergebnis gehört. Das hier ist die Entscheidungshilfe, mit der wir in ein Briefing gehen.
// w-01daten
Die Ausschreibungen kommen als XML oder RSS aus der Recruiting-Software, die Website holt sie in festem Takt ab. Robust, sparsam mit Rechten, unabhängig von der Verfügbarkeit der Quelle im Moment des Seitenaufrufs — und ausreichend, solange die Felder im Feed alles hergeben, was die Stellenseite zeigen soll.
stärke: robust · einfach
// w-02api
Über den rexx Hub steht eine REST-API nach OpenAPI-Standard bereit, mit feingranularen Berechtigungen und Audit-Log. Der Weg trägt mehr: mehr Felder, gezielte Abfragen — und vor allem eine Richtung zurück, wenn eine Bewerbung aus dem eigenen Formular ins System soll.
stärke: beide richtungen
// w-03einbettung
iFrame, Popup-Layer, Widget oder Reverse Proxy zeigen das fertige Jobportal des Anbieters im Rahmen der Website. Das ist der schnellste Start, weil praktisch nichts gebaut wird. Gestaltung, Markup und Ladeverhalten kommen dann allerdings vom Anbieter — inklusive der Frage, unter welcher Adresse der Inhalt zählt.
stärke: sofort startklar
Die Zuordnung fällt meist schnell. Ein Feed reicht, wenn eine überschaubare Zahl Stellen mit klaren Feldern gezeigt werden soll und ein Abgleich im Minuten- oder Stundentakt genügt. Eine Schnittstelle braucht es, sobald Daten zurücklaufen sollen oder Felder gefragt sind, die im Feed nicht auftauchen. Eine Einbettung ist der richtige Griff, wenn es schnell gehen muss oder das Bewerberportal mit Login ohnehin beim Anbieter bleibt.
Häufig ist die Kombination die beste Antwort: Stellenliste und Detailseiten aus dem Feed auf der eigenen Domain, der geschützte Bewerberbereich mit Statusanzeige beim Anbieter. Welche Wege in eurem Vertrag freigeschaltet sind, klären wir vorab beim Hersteller oder eurer HR-IT — das steht am Anfang des Konzepts, nicht am Ende.
// bausteine · 6 details
jedes teil mit klarem zweck
Zwischen „Stelle steht in rexx" und „Stelle steht auf der Website" liegen sechs Bauteile. Sie sind bei jedem Projekt gleich — was sich unterscheidet, sind die Feldnamen und der Takt.
// d-01abholung
Ein geplanter Job holt die Stellen in festem Takt und legt sie lokal ab. Kein Besucher wartet auf ein Fremdsystem, kein Seitenaufruf erzeugt einen Zugriff nach außen. Antwortet die Quelle einmal nicht, bleibt der letzte gute Stand stehen, statt dass die Karriereseite leer läuft.
zweck: tempo · ausfallsicherheit
// d-02mapping
Jedes Feld der Quelle bekommt ein Zuhause im CMS: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Ablaufdatum, Bewerbungslink. Was fehlt, ergänzt die Redaktion daneben — etwa ein Teamfoto oder ein Ansprechpartner, den das HR-System gar nicht kennt.
zweck: felder statt textblock
// d-03liste
Die Übersicht filtert nach Standort, Bereich und Anstellungsart — mit sprechenden URLs, damit ein Filterstand teilbar bleibt. Weil die Liste aus eigenen Daten entsteht, taucht sie auch in der Website-Suche auf statt in einem abgeschotteten Rahmen.
zweck: finden statt scrollen
// d-04detailseite
Jede Stelle bekommt eine eigene, stabile Adresse unter deiner Domain — teilbar per Mail, verlinkbar aus Social, sauber in der Vorschau. Das Layout ist deins: dieselbe Typografie, dieselbe Navigation, derselbe Footer wie auf dem Rest der Website.
zweck: eine stelle · eine url
// d-05lebenszyklus
Verschwindet eine Stelle aus der Quelle, verschwindet sie aus der Liste. Für die Detailseite gibt es drei saubere Optionen: Ablaufdatum in die Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wir wählen je Projekt eine — und leiten Besucher auf die Übersicht statt in die Sackgasse.
zweck: keine karteileichen
// d-06betrieb
Ein Abgleich, der stillschweigend scheitert, ist gefährlicher als einer, der laut abbricht. Deshalb wird jeder Lauf protokolliert, Fehler werden gemeldet, und ein leeres Ergebnis überschreibt niemals einen gefüllten Stand. Mehr dazu unter Deployment & Betrieb.
zweck: fehler fallen auf
An dieser Stelle entscheidet sich, wie sich die Karriereseite anfühlt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerbungsformular von rexx. Upload, Pflichtfelder und Eingangsbestätigung liegen dann beim Hersteller, die Bewerbung ist ohne Umweg im Bewerbermanagement, und auf dem Webserver entstehen gar keine Bewerberdaten. Der Preis ist ein sichtbarer Wechsel — anderes Layout, mitunter ein eigener Consent-Hinweis.
Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über die Schnittstelle an rexx übergibt. Der Bewerber bleibt durchgehend bei dir, Felder und Fehlermeldungen sind gestaltbar, die Barrierefreiheit liegt in unserer Hand — wie bei allen Formularstrecken. Dafür braucht es freigeschaltete Endpunkte, ein sorgfältiges Mapping und eine ehrliche Fehlerbehandlung: Was passiert, wenn die Übergabe scheitert, nachdem der Bewerber auf „Absenden" geklickt hat?
Welcher Weg gebaut wird, hängt weniger an der Technik als an der Erwartung: Soll die Bewerbung Teil der Website sein oder Teil des HR-Systems? Wir stellen diese Frage im Briefing — und beantworten sie gemeinsam, bevor eine Zeile Template entsteht.
// integration · 3 systeme
drei systeme · ein muster
Ein Bewerbermanagement liefert Daten, ein CMS macht daraus Seiten. Der Weg dazwischen sieht in jedem System gleich aus: Ein geplanter Job holt den Stellen-Feed in festem Takt ab, legt jede Ausschreibung als eigenen Inhalt im CMS an — mit einer eigenen URL je Stelle — und das Frontend rendert daraus Liste, Filter und Detailseite. Aus denselben Feldern entsteht beim Rendern das JobPosting-Markup für Google for Jobs. Unterschiedlich ist nur, wie das jeweilige System Inhalte modelliert und wiederkehrende Aufgaben plant.
Im CMS liegt dabei das Datenmodell: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Ablaufdatum und Bewerbungslink als einzelne Felder statt als Textblock — dazu Platz für das, was die Redaktion daneben ergänzt. Die Auslieferung übernimmt der Cache, sodass kein Seitenaufruf auf ein Fremdsystem wartet. Der Bewerbungsweg setzt an der Detailseite an: Der Button führt in das Formular von rexx oder in ein eigenes auf deiner Domain. Und genau hier liegt der Unterschied, der weiter oben schon anklang: Liegen die Stellen als echte Seiten deiner Domain, entsteht eigenes Markup aus deinen Feldern und zählt zu deiner Adresse. Eine Einbettung zeigt das fertige Portal des Anbieters schneller, Gestaltung und Markup kommen dann von dort. Beide Wege haben ihren Platz — für Sichtbarkeit unter der eigenen Adresse trägt der Weg über eigene Seiten.
// cms-01typo3
Der übliche Weg ist eine eigene Extension: Ein Scheduler-Task holt den Feed im festen Takt und schreibt die Stellen als eigene Datensätze in einen Ordner im Seitenbaum. Das Site Handling erzeugt daraus sprechende URLs, Fluid rendert Liste und Detailseite. Standort, Bereich und Anstellungsart liegen als eigene Felder, damit Filter und Sprachbäume mitlaufen. Die Redaktion ergänzt daneben, was das HR-System nicht kennt — Teamfoto, Ansprechpartner, Einstiegstext. Mehr zum System unter TYPO3.
weg: eigene extension · scheduler
// cms-02wordpress
Hier entsteht ein eigenes Plugin: Ein geplanter Lauf holt den Feed und legt jede Stelle als Beitrag eines Custom Post Types an, Standort, Bereich und Anstellungsart als Taxonomien daneben. Damit greifen Permalinks, Archivseiten und die Website-Suche wie bei jedem anderen Inhalt, und jede Stelle hat ihre eigene Adresse. Das eigene Theme rendert Liste und Detailseite im Layout der Website; ergänzende Bilder und Textblöcke pflegt die Redaktion im Block-Editor. Mehr zum System unter WordPress.
weg: eigenes plugin · custom post type
// cms-03statamic
Unter Statamic liegt ein vollständiges Laravel — der Abruf ist deshalb ein Artisan-Kommando im Scheduler, das die Stellen als Entries in eine Collection schreibt. Das Blueprint gibt die Felder vor, die Route der Collection ergibt die eigene URL je Stelle, Antlers oder Blade rendern Liste und Detailseite. Das Static Caching liefert den fertigen Stand aus und wird beim Speichern erneuert; Ergänzungen pflegt die Redaktion im Control Panel. Mehr zum System unter Statamic.
weg: artisan-kommando · entries
// sichtbarkeit
markup entscheidet, nicht layout
Wer eine Stelle sucht, tippt einen Jobtitel bei Google ein. Damit eine Anzeige in der Job-Box darüber erscheint, verlangt Google zweierlei: Die Seite muss gecrawlt werden können, und sie muss JobPosting als strukturierte Daten enthalten. Pflichtangaben sind Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort. Empfohlen kommen unter anderem Ablaufdatum, Anstellungsart, eine eigene Kennung und die Gehaltsangabe dazu — und gerade Letztere entscheidet mit, ob eine Anzeige in gefilterten Ergebnissen überhaupt auftaucht.
Genau darin liegt der Mehrwert einer eigenen Karriereseite: Liegen die Stellen als eigene Seiten auf deiner Domain, entsteht das Markup beim Rendern automatisch aus den Feldern, die aus rexx kommen — ein Feld, ein Attribut. Wird ein Jobportal dagegen von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiterhin zu dieser Adresse; erfasst wird die Stelle dann dort und nicht unter deiner URL. Beides kann nebeneinander bestehen, aber nur der eigene Weg baut Sichtbarkeit auf der eigenen Domain auf.
Dazu gehört auch das Ende: Google nennt drei Wege für besetzte Stellen — Ablaufdatum in der Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wie wir strukturierte Daten grundsätzlich bauen, steht unter Strukturierte Daten; was speziell für Stellenanzeigen gilt, unter Google for Jobs.
// datenschutz
so wenig wie möglich, so kurz wie möglich
Eine Bewerbung ist kein Kontaktformular. Lebenslauf, Zeugnisse, Geburtsdatum, manchmal ein Foto — das sind personenbezogene Daten der empfindlichsten Sorte, und sie werden ausgerechnet von Menschen übergeben, die dem Unternehmen noch nicht verbunden sind. Deshalb ist die erste Regel bei der Anbindung Datensparsamkeit: Die Website fragt nur ab, was für die Auswahl gebraucht wird, und legt nichts länger ab, als der Weitertransport dauert.
Technisch heißt das: Übertragung ausschließlich verschlüsselt, Zugangsdaten in der Serverkonfiguration statt im Repository, Anhänge direkt weiterreichen statt in einem Upload-Ordner sammeln, Zugriffe protokollieren. Führendes System bleibt rexx — dort greifen Rollen, Protokolle und die Löschfristen, die das Personalwesen ohnehin einhalten muss. Der Hersteller ist nach ISO 27001:2022 zertifiziert und betreibt die Software wahlweise in Rechenzentren in Deutschland und der Schweiz oder auf euren eigenen Servern.
Rechtlich gehört ein Auftragsverarbeitungsvertrag dazu, ebenso ein Datenschutzhinweis an genau der Stelle, an der die Daten erhoben werden — kurz, verständlich und ohne vorangekreuzte Einwilligung. Wie siteway das grundsätzlich hält, steht unter Sicherheit & Datenschutz.
Ein Bewerbungsformular ist die engste Stelle der ganzen Strecke: Wer hier scheitert, bewirbt sich nicht. Deshalb bekommt jedes Feld ein sichtbares, dauerhaft verknüpftes Label statt eines Platzhalters, der beim Tippen verschwindet. Pflichtfelder sind im Text benannt, nicht nur durch ein Sternchen. Fehler stehen am Feld, in Worten, und der Fokus springt dorthin — nicht in eine rote Zeile ganz oben, die eine Screenreader-Nutzerin nie erreicht.
Der Datei-Upload nennt erlaubte Formate und Größen, bevor jemand die falsche Datei wählt, und bleibt per Tastatur bedienbar. Nach dem Absenden gibt es eine Rückmeldung, die auch angesagt wird. Das gilt für das eigene Formular ebenso wie für die Entscheidung, in das Formular des Herstellers weiterzuleiten — dann prüfen wir vorher, wie es sich dort verhält. Die Grundlagen dazu stehen unter Barrierefreiheit.
// faq
rexx systems ist ein Hamburger Anbieter von HR-Software. Die rexx Suite ist modular aufgebaut und deckt drei Bereiche ab: HR-Management mit digitaler Personalakte, Bewerbermanagement mit Karriereportal, Multiposting und Online-Assessment sowie Talent Management mit Mitarbeiterentwicklung, Skill-Management und Nachfolgeplanung. Das Unternehmen wurde 2000 gegründet, sitzt in der Süderstraße in Hamburg und hat weitere Standorte in Wien und Zürich. Für die Website zählt vor allem das Recruiting-Modul: Dort entstehen die Stellenausschreibungen, die auf der Karriereseite erscheinen sollen.
rexx nennt dafür mehrere Wege: eine eigenständige Karriereseite mit eigener URL, Reverse Proxy beziehungsweise Server Side Includes, eine iFrame-Einbindung, ein Popup- oder Layer-Fenster, den XML-Export samt RSS-Feed und Widgets für Blogs und Microsites. Dazu kommt der rexx Hub, die Integrationsplattform des Herstellers mit einer REST-API nach OpenAPI-Standard. siteway arbeitet bevorzugt datengetrieben: Wir holen die Stellen als Feed oder über die Schnittstelle ab und bauen Liste und Detailseite selbst — im Design deiner Website, auf deiner Domain.
Ein Feed reicht, wenn die Felder überschaubar sind und Stellen nicht sekundengenau stimmen müssen — er ist der robusteste Weg und braucht die wenigsten Rechte. Eine Schnittstelle lohnt sich, wenn zusätzlich Daten zurückfließen sollen, etwa eine Bewerbung aus einem eigenen Formular, oder wenn Felder gebraucht werden, die im Feed nicht stehen. Die Einbettung über iFrame oder Reverse Proxy ist der schnellste Start, weil kaum etwas gebaut werden muss — dafür liegen Gestaltung, Markup und Ladeverhalten beim Anbieter. Entschieden wird am Ziel: Wer eigene Stellenseiten mit eigenem Markup will, geht über Feed oder Schnittstelle.
Ja. In allen drei Systemen trägt derselbe Aufbau: Ein geplanter Job holt die Stellen aus rexx, legt jede Ausschreibung als eigenen Inhalt im CMS an, und das Template rendert Liste, Filter und Detailseite — jede Stelle mit einer eigenen URL auf deiner Domain. In WordPress ist das ein eigenes Plugin mit einem Custom Post Type für Stellen und Taxonomien für Standort und Bereich. In TYPO3 eine eigene Extension mit Scheduler-Task, eigenen Datensätzen und Fluid-Templates. In Statamic ein Artisan-Kommando im Scheduler, das Entries in eine Collection schreibt. Weil die Feldnamen je rexx-Installation unterschiedlich ausfallen, baut siteway die Abholung als schlanken eigenen Code und stimmt das Feld-Mapping vorab ab. Das JobPosting-Markup entsteht anschließend in allen drei Systemen aus denselben Feldern.
Google zeigt eine Stelle in der Job-Box nur, wenn die Seite gecrawlt werden kann und JobPosting-Markup als strukturierte Daten enthält. Pflicht sind Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort; empfohlen sind unter anderem Ablaufdatum, Anstellungsart und Gehalt. Genau dieses Markup entsteht, wenn die Stellen als eigene Seiten auf deiner Domain liegen — siteway erzeugt es beim Rendern aus den Feldern, die aus rexx kommen. Wird ein Jobportal dagegen von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiter zu dieser Adresse und wird dort erfasst, nicht unter deiner URL.
Beides trägt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerbungsformular von rexx, dort läuft der Upload, und die Bewerbung liegt sofort im Bewerbermanagement. Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über die Schnittstelle an rexx übergibt — durchgängig im Design deiner Website, mit voller Kontrolle über Pflichtfelder, Fehlermeldungen und Barrierefreiheit, dafür mit mehr Aufwand und einer Abhängigkeit von den freigegebenen Endpunkten. siteway klärt das vor dem Bauen, weil daran der ganze Bewerbungsweg hängt.
Fällt eine Stelle aus dem Feed, verschwindet sie beim nächsten Abgleich aus der Liste. Für die Detailseite nennt Google drei saubere Wege: das Ablaufdatum in die Vergangenheit setzen, die Seite mit Statuscode 404 oder 410 beantworten oder das JobPosting-Markup entfernen. Welcher Weg gewählt wird, legt siteway je Projekt fest — und leitet abgelaufene Stellen dorthin, wo es weitergeht: auf die Karriereübersicht statt in eine Sackgasse.
Bewerbungsunterlagen gehören zum Sensibelsten, was eine Website verarbeitet. Deshalb gilt: so wenig wie möglich auf dem Webserver. Die Übertragung läuft verschlüsselt, Zugangsdaten liegen in der Serverkonfiguration statt im Repository, und Anhänge werden weitergereicht statt dauerhaft abgelegt. Führendes System bleibt rexx — dort greifen Rollen, Protokollierung und Löschfristen. Der Hersteller ist nach ISO 27001:2022 zertifiziert und betreibt die Software wahlweise in Rechenzentren in Deutschland und der Schweiz oder auf euren eigenen Servern. Der Auftragsverarbeitungsvertrag gehört ins Projekt, nicht ins Nachspiel.
// womit das zusammenhängt
komponente, leistung & nachbarn
// komponente · buchen
Der Baustein, der auf deiner Website entsteht: Stellenliste, Detailseiten, Bewerbungsformular und Karriere-Übersicht. Hier wird gebucht.
zur komponente →
// leistung · buchen
Die Leistung hinter dieser Seite: Scoping, Feld-Mapping, Entwicklung, Test und Monitoring — für rexx wie für jedes andere Fremdsystem.
zur leistung →
// stack · sichtbarkeit
Was eine Stellenanzeige mitbringen muss, um in der Job-Box zu erscheinen — Pflichtfelder, Ablaufdatum und die häufigsten Stolpersteine.
zur technik →
// stack · schwester
Dieselbe Frage, anderes System: wie Stellen aus Personio auf die eigene Karriereseite kommen — und wo sich die Wege unterscheiden.
zur technik →
// stack · markup
Wie wir Schema.org grundsätzlich bauen — die Basis, auf der das JobPosting-Markup einer Stellenseite entsteht.
zur technik →
// stack · schutz
Verschlüsselung, Header, Datensparsamkeit und der Umgang mit Zugangsdaten — die Regeln, nach denen jede Anbindung gebaut wird.
zur technik →
// Stellen aus rexx auf deiner eigenen Karriereseite?
Anbindung anfragen