Reale Vacancies.
Öffentlich auffindbar.
Eine serverseitig auslieferbare Public-Schicht für circa 5.000 Jobs – mit belastbarer Vacancy-Identität, anonymisierungsfähigen Jobdetailseiten und einem maschinenlesbaren Publishing Gate.
Outcome statt SEO-Experiment
P1 baut eine dauerhafte Akquisitions- und Publishing-Infrastruktur. Der Erfolg wird nicht an Textvarianten gemessen, sondern an korrekt publizierten Vacancies und qualifizierten Bewerbungen.
Drei Entscheidungen bestimmen den Erfolg
Jobs unterscheidbar machen
Für möglichst viele Public Jobs ausreichend eindeutige, jobspezifische Merkmale liefern – statt allgemeiner Arbeitgeber- oder Standardtexte.
Aufwand gegen Value abwägen
Zusätzliche Daten nur erfassen oder modellieren, wenn Verfügbarkeit, Erfassungsaufwand und erwarteter Mehrwert in einem sinnvollen Verhältnis stehen.
Mindestqualität absichern
Das Quality Gate verhindert austauschbare oder zu dünne Jobs. Seine Schwellen werden anhand der realen Datenabdeckung kalibriert.
MEDWING-Struktur × Pflegia-Datentiefe
Die öffentlich sichtbaren Seiten belegen zwei komplementäre Muster. Sie belegen nicht, welche URLs tatsächlich in Google for Jobs ausgespielt werden – dieser technische Nachweis bleibt ein eigenes Audit.
Von MEDWING lernen
Architektur- Öffentliche Jobsuche und Matching bestehen nebeneinander.
- Berufe, Städte, Einrichtungen und Jobs sind miteinander verlinkt.
- Filter spiegeln fachliche Attribute wie Einrichtung, Schicht, Gehalt und Erfahrung.
- Anonyme Vermittlerangebote existieren öffentlich – ihre Google-for-Jobs-Eligibility ist aber unbewiesen.
Von Pflegia lernen
Datentiefe- Konkrete Adresse, Vertrag, Urlaub, Tarif und Überstundenregelung.
- Einrichtungsmerkmale wie Bettenzahl und Teamgröße.
- Ambulante Merkmale wie Patienten pro Tour und Einsatzgebiet.
- Jobdetail und ähnliche lokale Jobs bilden eine nutzbare Weiterklick-Struktur.
Nicht blind kopieren
Caveat- Öffentlich erreichbar bedeutet nicht automatisch indexiert oder in Google for Jobs sichtbar.
- Generische Vermittlerseiten sind kein Beleg für eigenständige Vacancies.
- Pflegia bezeichnet Gehaltswerte teilweise als Schätzung; solche Werte dürfen nicht automatisch als Arbeitgeber-
baseSalarymarkiert werden. - JSON-LD, Canonicals und Expiry müssen separat geprüft werden.
Ein Datensatz, zwei Produktschichten
Die öffentliche Akquisitionsschicht bleibt vollständig lesbar und intern verlinkt. Profil, Matching und Kommunikation liegen in der geschlossenen App.
/jobsJobsucheEinstieg, Suchfelder und kontrollierte Filter. Kein JobPosting-Markup./jobs/{beruf}/{stadt}Beruf-Ort-HubNur indexierbar bei echten aktiven Jobs und ausreichendem eigenem Nutzen./arbeitgeber/{slug-id}EinrichtungsprofilNur für freigegebene benannte Arbeitgeber; Jobs und echte Standortdaten./jobs/{slug}-{vacancy-id}JobdetailGenau eine Vacancy, vollständiges sichtbares HTML und JobPosting./app/jobs/{id}/applyApply-HandoffVacancy-ID bleibt durch Registrierung und Matching erhalten.Publishing Gate + Quality Score
Harte Gates entscheiden über die technische und fachliche Publikationsfähigkeit. Das vorläufige Qualitätsminimum verlangt einen jobspezifischen Anker plus mindestens zwei entscheidungsrelevante Bereiche. Einrichtungsdaten erhöhen den Score, reichen allein aber nicht aus.
Vacancy-spezifischer Anker
Mindestens ein Merkmal unterscheidet den Job: etwa Station, Fachbereich, Patientengruppe, Nacht-/Springerfunktion oder konkretes Schichtmodell.
Entscheidungsrelevante Substanz
Arbeitszeit, Konditionen, Vergütung sowie jobspezifische Aufgaben und Anforderungen.
Einrichtungskontext
Bettenzahl, Teamgröße und allgemeine Benefits verbessern die Seite, ersetzen aber kein jobspezifisches Merkmal.
Erst messen, was wirklich verfügbar ist
Nicht der kleinste gemeinsame Nenner aller Jobs und nicht eine Wunschliste neuer Felder bestimmen die Qualität. Das Audit verfolgt jedes relevante Merkmal vom Rohdatensatz über Speicherung und Freigabe bis zur öffentlichen Ausgabe.
Source Payload
Welche maximalen Informationen liefern API, Feed, Scraper oder operative Erfassung tatsächlich?
Stored
Was wird strukturiert gespeichert – und was geht heute beim Mapping oder Import verloren?
Permitted
Welche Daten dürfen je Arbeitgeber, Quelle und Anonymitätsstufe öffentlich erscheinen?
Rendered
Was landet konsistent in sichtbarem HTML und, soweit zulässig, im JobPosting-Markup?
| Feldgruppe | Heute auffindbare Kandidaten | Coverage-Frage | Audit-Status |
|---|---|---|---|
| Universelle Basis | ID/Quelle, Rolle, Beschreibung, Standort, Arbeitsmodell, Status | Was liegt bei nahezu allen aktiven Jobs valide und öffentlich nutzbar vor? | Coverage messen |
| Job-Kontext | care_type, Spezialisierung, Station, Wohnbereich, Tour, Patientengruppe | Welche kontextgebenden Werte stecken strukturiert oder nur im Rohtext? | Source prüfen |
| Operativer Alltag | shift, working_hours, shift_plan, Wochenenden, Patienten pro Tour | Welche konkreten Arbeitsrealitäten unterscheiden Jobs desselben Titels? | Coverage messen |
| Konditionen | benefits, tarif, days_of_vacation, overtime_regulation | Sind Werte jobspezifisch, aktuell und strukturiert – oder nur Arbeitgeber-Defaults? | Herkunft prüfen |
| Vergütung | min_salary, max_salary, salary_options | Arbeitgeberwert oder Schätzung? Währung, Einheit, Zeitraum und Aktualität vorhanden? | Provenienz prüfen |
| Anforderungen | Ausbildung, Weiterbildung, Erfahrung, besondere Anforderungen | Welche Kriterien sind strukturiert filterbar und welche nur Freitext? | Mapping prüfen |
| Einrichtungskontext | Bettenzahl, Teamgröße, Wohnbereiche, allgemeine Benefits | Welche Werte verbessern die Orientierung, sind aber bei mehreren Jobs derselben Einrichtung identisch? | nur Quality-Bonus |
| Lifecycle | status, created_at, updated_at, Source-Daten | Lassen sich Original-Posting, Ablauf, Schließung und Reaktivierung verlässlich ableiten? | Lücken messen |
| Publikationsrecht | show_company_name, Quelle, Arbeitgebervereinbarung | Welche Feldgruppen sind benannt, vertraulich-präzise oder vertraulich-reduziert erlaubt? | Matrix erstellen |
Vacancy-Anker + 2 von 4 Bereichen
Die universelle Basis bleibt Pflicht. Darüber hinaus braucht jeder Job ein unterscheidendes, zum Jobtyp passendes Merkmal sowie Substanz in mindestens zwei Bereichen: Arbeitszeit, Konditionen, Vergütung oder jobspezifische Aufgaben und Anforderungen.
Station & Versorgung
Fachbereich oder Station, Schichtmodell und relevante Patientengruppe.
Wohnbereich & Versorgung
Wohnbereich, Versorgungsform oder Dienstmodell als Anker; Bettenzahl zählt nur als Kontext.
Tour & Einsatz
Patienten pro Tour oder Gebiet, Tourzeiten und Fahrzeugregelung.
Fall & Dienstlänge
Abstrakter Versorgungskontext, Dienstlänge und zulässige Standortpräzision.
Zielgruppe & Schlüssel
Zielgruppe, Gruppenstärke oder Betreuungsschlüssel und Arbeitszeit.
Verantwortung & Mandat
Personal-, Fach- oder Budgetverantwortung als Anker; Teamgröße ergänzt nur den Kontext.
Ein Status-Rad für alle Kanäle
Datenbankstatus, öffentliche Seite, Sitemap, Structured Data und Indexing API müssen aus demselben Event abgeleitet werden.
Noch nicht öffentlich
Kein Sitemap-Eintrag, kein JobPosting-Markup, interne Vorschau geschützt.
200 + indexierbar
Selbstreferenzierendes Canonical, Sitemap, vollständiges Markup und URL_UPDATED.
Sofort aus dem Jobindex
Markup und Sitemap entfernen; anschließend 410 oder archivierte Seite mit noindex und URL_DELETED.
Vier Phasen bis zum Rollout
Inventory & Evidence
- Source-to-Public-Feldinventar
- Coverage je Segment
- Vacancy-Definition
- Freigabematrix
Hard-Gate Foundation
- Notwendige Feldlücken schließen
- Eligibility Service
- Public View Model
- Lifecycle Events
Shadow Pilot
- 100–300 Vacancies
- Quality Score ohne Blocking
- manuelle Qualitätsstichprobe
- Schwellen je Jobtyp kalibrieren
Enforce & Scale
- Qualitätsminimum aktivieren
- Voll-Rollout nach Segment
- Monitoring & Alerts
- Regeln laufend nachschärfen
Konkrete ToDos aus der Analyse
Die Reihenfolge verhindert, dass wir zuerst Templates oder tausende URLs bauen und erst danach feststellen, dass Identität, Freigabe oder Datenqualität fehlen.
Beweise und Regeln schaffen
| # | ToDo | Owner | Output / Definition of Done |
|---|---|---|---|
| 01 | 20-URL-Wettbewerbsaudit Je 10 MEDWING- und Pflegia-Jobdetails: sichtbare Daten, JSON-LD, Canonical, Status, interne Links, Arbeitgeberdarstellung. | SEO + Engineering | Audit-Tabelle mit Screenshot/HTML-Beleg je URL; öffentlich prüfbar strikt von GSC-internen Aussagen getrennt. |
| 02 | Vacancy- und Duplicate-Contract Arbeitgeber-Requisition, Standort, Rolle, Einheit, Arbeitsmodell und Reaktivierung definieren. | Product + Operations | Entscheidungsbaum mit Beispielen und testbaren Regeln; keine neue URL allein wegen Text, Slug oder neuer länk-ID. |
| 03 | Disclosure-Matrix Benannt, vertraulich-präzise und vertraulich-reduziert je Kunde festlegen. | Sales + Legal | Freigabe pro Feldgruppe: Name, Logo, Adresse, Einrichtungsdaten, Gehalt, Kontaktperson, Fotos. |
| 04 | Source-to-Public Field Inventory Rohdaten, Mapping, Speicherung, Freigabe und Ausgabe für alle relevanten Felder abgleichen. | Data + Backend | Coverage je Quelle und Jobtyp; Verluststellen sind sichtbar. Werte sind als jobspezifisch/default sowie mit Aktualität und Provenienz klassifiziert. |
Nur belegte Lücken schließen und Publishing bauen
| # | ToDo | Owner | Output / Definition of Done |
|---|---|---|---|
| 05 | Field-Gap-Entscheidung Erst nach dem Audit entscheiden, welche wertvollen Quelldaten nur gemappt und welche wirklich neu modelliert werden müssen. | Product + Data + Backend | Priorisierte Gap-Liste mit Coverage, Nutzen und Aufwand; keine Schema-Erweiterung ohne belegte Quelle. Gehaltsschätzung und Arbeitgeberwert bleiben technisch getrennt. |
| 06 | Eligibility Endpoint + Shadow Score/publication-eligibility/ trennt Hard Gates, Vacancy-Anker, Entscheidungsbereiche und Kontextbonus. | Backend | Deterministische JSON-Antwort und Unit-Tests; Hard Gates steuern Publishing, quality_gate_enforced=false im Pilot. |
| 07 | Public Vacancy View Model Eine Quelle für sichtbares HTML und JSON-LD. | Backend + Frontend | Keine Abweichung zwischen Markup und Seite; benannt und confidential als getrennte Fälle getestet. |
| 08 | Lifecycle-Orchestrierung Sitemap, Indexing API, Canonical, Expiry und HTTP-Status aus Jobevents ableiten. | Platform | Active/Changed/Closed/Reactivated als Integrationstests; keine abgelaufenen Jobs im aktiven Feed. |
Discovery Graph kontrolliert live bringen
| # | ToDo | Owner | Output / Definition of Done |
|---|---|---|---|
| 09 | SSR-Jobdetail + Apply-Handoff Vollständige öffentliche Vacancy und Übergabe der Vacancy-ID in die App. | Frontend + Product | 200-HTML ohne JS vollständig; Bewerbung bleibt bis zum Abschluss dem konkreten Job zugeordnet. |
| 10 | Hubs und Einrichtungsprofile Nur freigegebene, nützliche Seiten mit echten aktiven Jobs. | SEO + Frontend | Indexability-Schwellen, interne Links und Empty-State-Regeln dokumentiert; Facetten standardmäßig nicht indexierbar. |
| 11 | Shadow-Scoring & manuelle Stichprobe Vacancy-Anker, Entscheidungsbereiche und Kontextbonus für alle Pilotjobs berechnen und repräsentative Seiten redaktionell bewerten. | Analytics + SEO + Operations | Score-Verteilung je Jobtyp und Quelle, Fehlklassifikationen dokumentiert; noch kein Job wird wegen des Scores blockiert. |
| 12 | Schwellen kalibrieren & Pilot-Gate Erst nach QA von 100–300 Jobs ein Qualitätsminimum je Jobtyp beschließen und auf 5.000 skalieren. | Project Lead | Go/No-Go berücksichtigt Coverage, manuelle Qualität, Indexierung, Fehlerquote und Bewerbungen; Aktivierung des Quality Gates ist eine explizite Entscheidung. |
Vor Umsetzung verbindlich klären
Was gilt als Bewerbung?
Konkrete Bewerbung auf die Vacancy oder lediglich Eintritt in einen allgemeinen Matching-Pool?
Welche Standortpräzision ist erlaubt?
Offen, PLZ/Stadt oder nur Region – inklusive Schutz vor indirekter Deanonymisierung.
Welches Datum ist das Original-Posting?
Arbeitgeberdatum, Feed-Datum oder erstmalige Veröffentlichung bei länk.
Wann entsteht eine neue Vacancy?
Reaktivierung, neue Schicht, weitere Planstelle oder neue Arbeitgeber-Requisition.