// stack · schnittstelle
Der BITE Bewerbermanager ist eine Bewerbermanagement-Software der BITE GmbH aus Ulm — dort entstehen die Ausschreibungen, dort laufen die Bewerbungen zusammen. 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
Der BITE Bewerbermanager ist eine webbasierte Bewerbermanagement-Software der BITE GmbH aus Ulm. In der Branche heißt so etwas Applicant Tracking System, kurz ATS: ein System, in dem Ausschreibungen angelegt, veröffentlicht und Bewerbungen bis zur Entscheidung begleitet werden. Der Name steht nach Angaben des Herstellers für Business IT Engineers. Zum Funktionsumfang gehören laut Hersteller unter anderem Stellenmanagement, Bewerberverwaltung, Multiposting auf Jobbörsen, ein zusammenstellbares Online-Bewerbungsformular, ein Job-Alert per E-Mail und eine automatische Arbeitszeugnisanalyse.
Für eine Website ist davon genau ein Ausschnitt relevant: das Stellenmanagement. 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 sauber: siteway behandelt BITE als führendes System und die Website als Anzeige.
Zur Einordnung, weil der Name mehrdeutig ist: Gemeint ist hier ausschließlich die Recruiting-Software der BITE GmbH aus Ulm, die unter der Bezeichnung BITE Bewerbermanager angeboten wird. Angaben zu Funktionsumfang, Zertifizierungen und Betrieb auf dieser Seite stammen aus den öffentlichen Darstellungen des Herstellers und sind als solche gekennzeichnet.
// praxis
erst klären, dann bauen
Der erste Schritt ist bei BITE wichtiger als bei manch anderem System: die Sichtung. Eine öffentlich einsehbare Entwicklerdokumentation gibt es nicht, deshalb wird der freigeschaltete Weg vorab mit dem Hersteller oder eurer HR-IT geklärt — welche Übergabe in eurem Vertrag enthalten ist, welche Felder sie liefert, in welchem Takt sie abgerufen werden darf und wie der Bewerbungsweg aussehen soll. Daraus entsteht ein schriftliches Feld-Mapping, und erst danach wird gebaut. Das ist dasselbe Vorgehen wie bei jeder anderen Schnittstelle, nur mit mehr Gewicht auf dem ersten Termin.
Was der Hersteller öffentlich beschreibt, gibt die Richtung vor: Für die eigene Homepage nennt er eine automatisierte Darstellung der Ausschreibungen, daneben steht eine eigenständige Karriereseite als Produkt, und Stellenanzeigen werden über Schnittstellen an Jobbörsen und an Google for Jobs übergeben. Für eine Website heißt das: Die Stellen sind als Daten vorhanden und werden automatisiert weitergereicht — die Frage ist nur, wohin und in welcher Form.
Wir gehen den datengetriebenen Weg, wo er möglich ist: Stellen 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.
Bei Bewerbermanagement-Systemen liegt oft schon eine fertige Anzeige bereit: ein Job-Widget oder ein eingebettetes Portal, das die aktuellen Stellen ohne großen Bauaufwand zeigt. Das ist ein legitimer und schneller Weg. Er beantwortet nur eine andere Frage als die nach der Sichtbarkeit — denn für Suchmaschinen zählt die Adresse, unter der ein Inhalt ausgeliefert wird. Drei Bauweisen, drei Charaktere:
// w-01klärung
Vor der ersten Zeile Code steht die Frage, welcher Weg für euren Zugang freigeschaltet ist und welche Felder er hergibt. Diese Auskunft kommt vom Hersteller oder aus eurer HR-IT — wir begleiten den Termin, schreiben die Antworten als Mapping fest und leiten daraus den Bauplan ab.
stärke: keine annahmen
// w-02daten
Die Stellen werden als Daten abgeholt und im CMS zu eigenen Inhalten — jede mit einer eigenen, indexierbaren URL auf deiner Domain. Layout, Ladeverhalten, Markup und Barrierefreiheit liegen damit bei dir, und die Stellen tauchen in der Website-Suche auf wie jeder andere Inhalt.
stärke: sichtbar unter deiner url
// w-03einbettung
Ein eingebettetes Portal oder Widget zeigt die Stellen sofort und bleibt automatisch aktuell, weil die Anzeige beim Anbieter liegt. Gestaltung, Markup und Ladeverhalten kommen dann von dort — ebenso die Adresse, unter der die Inhalte erfasst werden. Ein guter Start und ein guter Nachbar für eigene Seiten.
stärke: sofort startklar
In der Praxis ist die Kombination oft die beste Antwort: Stellenliste und Detailseiten als eigene Seiten auf der eigenen Domain, der geschützte Bewerberbereich mit Login und Statusanzeige beim Hersteller. So bleibt die Sichtbarkeit dort, wo die Marke sitzt, und der Prozess dort, wo das Personalwesen ohnehin arbeitet.
Welcher Weg zu euch passt, steht am Anfang des Konzepts — zusammen mit der Frage, wie oft Stellen wechseln, wie viele Standorte es gibt und ob die Karriereseite eigenständig auftreten oder Teil der Unternehmenswebsite sein soll.
// bausteine · 6 details
jedes teil mit klarem zweck
Zwischen „Stelle steht in BITE“ und „Stelle steht auf der Website“ liegen sechs Bauteile. Sie sind bei jedem Projekt gleich — was sich unterscheidet, sind die Feldnamen und der Takt. Beides kommt aus der Abstimmung, nicht aus einer Vermutung.
// 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 gelieferte Feld bekommt ein Zuhause im CMS: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Laufzeit, Bewerbungslink. Wie die Felder in eurer Installation heißen, steht im abgestimmten Mapping. Was fehlt, ergänzt die Redaktion daneben — Teamfoto, Ansprechpartner, Einstiegstext.
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 und lässt sich mit redaktionellen Inhalten mischen.
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, indexierbar für Suchmaschinen. 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 beim nächsten Abgleich aus der Liste. Für die Detailseite nennt Google drei saubere Wege: Ablaufdatum in die Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wir wählen je Projekt einen — 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 des Herstellers — laut Hersteller lässt es sich je Bedarf zusammenstellen. Upload, Pflichtfelder und Eingangsbestätigung liegen dann dort, 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 abgestimmte Schnittstelle ü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 freigegebene Endpunkte, ein sorgfältiges Mapping und eine ehrliche Fehlerbehandlung: Was passiert, wenn die Übergabe scheitert, nachdem jemand 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 ist systemunabhängig und sieht überall gleich aus: Ein geplanter Job holt die Stellen im festen Takt ab, legt jede Ausschreibung als eigenen Inhalt im CMS an — mit einer eigenen indexierbaren 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, Laufzeit 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 des Herstellers oder in ein eigenes auf deiner Domain. Weil die Feldnamen aus der Abstimmung mit dem Hersteller kommen und nicht aus einer öffentlichen Referenz, bauen wir die Abholung in allen drei Systemen als schlanken eigenen Code — austauschbar an genau einer Stelle, falls sich an der Quelle etwas ändert.
// cms-01typo3
Der Weg ist eine eigene Extension auf Extbase-Basis: Ein Scheduler-Task holt die Stellen im festen Takt und schreibt sie als eigene Records in einen Ordner im Seitenbaum, das TCA beschreibt die Felder. Das Site Handling erzeugt daraus sprechende URLs je Stelle, Fluid rendert Liste und Detailseite. Standort, Bereich und Anstellungsart liegen als eigene Felder, damit Filter und Sprachbäume mitlaufen. Mehr zum System unter TYPO3.
weg: eigene extension · scheduler
// cms-02wordpress
Hier entsteht ein eigenes Plugin statt Code im Theme — so überlebt die Anbindung jeden Design-Wechsel. Ein geplanter Lauf holt die Stellen und legt jede als Beitrag eines Custom Post Types mit Meta-Feldern an, Standort und Bereich als Taxonomien daneben. Eine eigene Permalink-Struktur gibt jeder Stelle ihre Adresse, das Markup hängt an einem Hook im <head>. 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-Command im Scheduler, der 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; Ergänzungen pflegt die Redaktion im Control Panel. Mehr zum System unter Statamic.
weg: artisan-command · 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.
Der Hersteller weist darauf hin, dass die von Google geforderten Angaben zu jeder Ausschreibung im System erfasst werden können. Damit steht die Datengrundlage — das Markup selbst entsteht aber erst dort, wo die Seite gerendert wird. Liegen die Stellen als eigene Seiten auf deiner Domain, erzeugen wir es beim Rendern automatisch aus den Feldern, die aus BITE kommen: ein Feld, ein Attribut. Wird ein Portal von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiterhin zu dieser Adresse; erfasst wird die Stelle dann dort. Beides kann nebeneinander bestehen, und 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 BITE — dort greifen Rollen, Protokolle und die Löschfristen, die das Personalwesen ohnehin einhalten muss. Nach Angaben des Herstellers ist die BITE GmbH nach ISO 27001 und ISO 9001 zertifiziert; Entwicklung und Datenhaltung finden demnach in Deutschland statt.
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, und beziehen das Ergebnis in die Empfehlung ein. Die Grundlagen dazu stehen unter Barrierefreiheit.
// faq
Der BITE Bewerbermanager ist eine webbasierte Bewerbermanagement-Software — im Sprachgebrauch der Branche ein Applicant Tracking System, kurz ATS. Hersteller ist die BITE GmbH mit Sitz in Ulm; der Name steht nach Angaben des Herstellers für Business IT Engineers. Die Software begleitet die Recruiting-Kette vom Stellen- und Ausschreibungsmanagement über die Veröffentlichung auf Jobbörsen bis zur Auswahl der Bewerberinnen und Bewerber. Für eine Website ist davon ein Ausschnitt relevant: das Stellenmanagement. Dort entstehen die Ausschreibungen, die auf der Karriereseite erscheinen sollen.
Über einen Weg, der vorab mit dem Hersteller oder eurer HR-IT geklärt wird. Der Hersteller nennt für die eigene Homepage eine automatisierte Darstellung der Ausschreibungen und bietet daneben eine eigenständige Karriereseite als Produkt an. Welche Übergabe in eurem Vertrag freigeschaltet ist, welche Felder sie liefert und in welchem Takt sie abgerufen werden darf, steht am Anfang jedes Projekts. Danach ist der Aufbau immer derselbe: Ein geplanter Job holt die Stellen, legt jede Ausschreibung als eigenen Inhalt im CMS an, und wir rendern Liste, Filter und Detailseite selbst — im Design deiner Website, auf deiner Domain.
Öffentlich einsehbar ist sie nicht. Anders als bei Systemen mit offener Entwicklerdokumentation lassen sich Endpunkte, Feldnamen und Formate deshalb nicht vorab aus einer Referenz ablesen. Das ändert nichts am Vorgehen, verschiebt nur die Reihenfolge: Zuerst holen wir gemeinsam mit euch die Freigabe und die technischen Angaben beim Hersteller oder bei eurer HR-IT ein, dann entsteht daraus ein schriftliches Feld-Mapping, und erst danach wird gebaut. Wir schreiben keine Annahmen über Endpunkte oder Feldnamen fest, bevor sie bestätigt sind.
Für den schnellen Start reicht es oft völlig: Ein eingebettetes Portal oder Widget zeigt die aktuellen Stellen sofort, ohne dass viel gebaut werden muss. Für die Suche zählt allerdings die Adresse, unter der ein Inhalt ausgeliefert wird. Wird das Portal von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiter dorthin und wird auch dort erfasst. Sollen die Stellen unter eurer Domain ranken und in der Job-Box erscheinen, entstehen sie als eigene Seiten mit eigener indexierbarer URL. Beide Wege haben ihren Platz, und sie lassen sich kombinieren — etwa eigene Stellenseiten plus geschützter Bewerberbereich beim Hersteller.
Ja. In allen drei Systemen trägt derselbe Aufbau: Ein geplanter Job holt die Stellen, 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 TYPO3 ist das eine eigene Extension mit Scheduler-Task, eigenen Datensätzen und Fluid-Templates. In WordPress ein eigenes Plugin mit einem Custom Post Type für Stellen und Taxonomien für Standort und Bereich. In Statamic ein Artisan-Kommando im Scheduler, das Entries in eine Collection schreibt. Weil die Feldnamen je Installation unterschiedlich ausfallen können, bauen wir die Abholung als schlanken eigenen Code und stimmen das Feld-Mapping vorab ab.
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. Dieses Markup entsteht nicht im Bewerbermanagement, sondern beim Rendern deiner Stellenseite — aus genau den Feldern, die aus BITE kommen. Der Hersteller weist darauf hin, dass die von Google geforderten Angaben zu jeder Ausschreibung im System erfasst werden können; damit steht die Datengrundlage, aus der wir das Markup erzeugen.
Beides trägt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerbungsformular des Herstellers, dort läuft der Upload, und die Bewerbung liegt sofort im Bewerbermanagement — auf dem Webserver entstehen dabei keine Bewerberdaten. Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über die abgestimmte Schnittstelle ü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. Wir klären das vor dem Bauen, weil daran der ganze Bewerbungsweg hängt.
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 BITE — dort greifen Rollen, Protokollierung und die Löschfristen, die das Personalwesen ohnehin einhalten muss. Nach Angaben des Herstellers ist die BITE GmbH nach ISO 27001 und ISO 9001 zertifiziert und hält die Daten in einem Rechenzentrum in Deutschland. 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 BITE 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 dem rexx-Bewerbermanagement auf die eigene Karriereseite kommen.
zur technik →
// stack · schwester
Der Weg von Personio auf die eigene Karriereseite — und wo sich die Anbindung von einem anderen HR-System unterscheidet.
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 BITE auf deiner eigenen Karriereseite?
Anbindung anfragen