Die Herausforderung
Ein Benchmark von ApplyArc aus dem Juni 2026 testete fünf LinkedIn Job-Scraper bei 200 echten Abrufen. Bei dreien wurde der Account nach etwa 50 Saves markiert oder unbemerkt gedrosselt. Nur zwei überstanden dies sauber.
Dieser Benchmark sagt alles. Früher waren Jobbörsen leichte Ziele. Heute gehören sie zu den härtesten im offenen Web.
Wenn du etwas baust, das von Stellenanzeigen abhängt (Personalplanung, Gehalts-Benchmarking, Talent-Mapping, Hiring-as-a-Signal für Aktienanalysen), kämpft dein Collection Layer gegen Abwehrmaßnahmen, die es vor zwei Jahren nicht gab. Indeed wirft unbekannten Sessions CAPTCHAs vor. LinkedIn korreliert browserseitige Signale über IP-Rotationen hinweg. Glassdoor nutzt Rate Limits pro ASN statt pro IP. ZipRecruiter schiebt Gehaltsband und Veröffentlichungsdatum in JavaScript, das nur gerendert wird, wenn deine Header wie ein Mensch aussehen und nicht wie ein Script.
Die 50-Save-Wall ist also kein LinkedIn-Problem. Es ist eine Eigenschaft der gesamten Kategorie.
Warum Jobbörsen immer härter werden
Drei Dinge haben sich 2026 geändert, und sie summieren sich.
Erstens wurde die Bot-Erkennung verhaltensorientiert. Statische Prüfungen (User-Agent, IP-Reputation, Requests pro Sekunde) reichten früher aus, um Hobby-Scraper zu stoppen. Das ist vorbei. Heutige Abwehrmechanismen beobachten, wie du dich durch die Seite bewegst: welche Seiten du in welcher Reihenfolge lädst, wie viel Zeit du verbringst, ob du dieselben JS-Bundles neu abrufst, die ein echter Browser cachen würde. Wir haben über diesen Wandel in Bot Detection Went Behavioral geschrieben. Jobbörsen haben das früh übernommen, weil ihre Besucher wenige wiederholbare Aktionen ausführen (suchen, klicken, lesen, speichern). Das macht ein Script leicht erkennbar, wenn es die halbe Sequenz überspringt.
Zweitens spielt die Größe des Proxy-Pools keine Rolle mehr. Ein Residential Pool mit 50 Millionen IPs hilft nicht, wenn die Abwehr aus Fingerprint-Korrelation auf dem Connection Layer plus ASN-Reputation besteht. Das haben wir in Why Proxy Pool Size Stopped Mattering behandelt. Was funktioniert, ist die Wahl des richtigen Exits für die Zielseite und nicht mehr Exits als alle anderen zu haben.
Drittens rechtliche Aspekte. Indeed und LinkedIn haben Rechtsteams, die klagen. Die Ära öffentlicher Scraper von der Heim-IP ist vorbei für alle, die ihre gesammelten Daten verkaufen wollen.
Wie die Datenerfassung heute aussieht
Für Talent-Intelligence-Arbeit im Jahr 2026 funktioniert ein Split Stack am besten: ein echter browserbasierter Fetch für die geschützten Jobbörsen plus sorgfältige Exit-Auswahl, damit du nicht vom selben Provider kommst wie jeder andere Bot.
Bei einer Plattform wie FourA sind das zwei Produkte, die miteinander kommunizieren.
Browser übernimmt das Rendering: Sende eine URL mit unblocker: true, erhalte gerendertes HTML, Cookies und einen Screenshot einer echten Browser-Session zurück. JS wird ausgeführt, Lazy-Loading-Felder werden befüllt und der Request besteht die Connection-Layer-Prüfungen, die die meisten einfachen Clients abfangen. Die Proxy-Auswahl läuft im Hintergrund. Die Plattform wählt einen Exit pro Request und gibt dessen opake Base36-ID in der Response zurück (auf r.proxy Top-Level bei Single/Browser oder r.session.proxy bei Auto). So können Folgeaufrufe denselben Exit wiederverwenden, wenn du Session-Kontinuität brauchst. Für die meiste Jobbörsen-Arbeit ist Auto der richtige Einstiegspunkt. Es orchestriert Single, Proxy und Browser basierend auf den Anforderungen jedes Ziels, sodass dein Code das nicht tun muss.
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
"validate": {
"status": {"accept": [200]},
"data": {"accept": ["data-testid=\"job-card\""],
"fail": ["Just a moment", "captcha"]},
},
},
).json()
# r["data"] or r["body"] — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"] — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.
Zwei Anmerkungen dazu, was dir das konkret bringt.
Die 50-Save-Wall im Stil von ApplyArc ist vor allem ein Session-Problem, kein Pool-Problem. Eine echte Browser-Session, die überlegt rotiert wird, hält viel länger durch, bevor sie das Rate Limit auslöst, als ein roher HTTP-Client. Und die Response enthält eine opake Proxy-ID statt eines rohen Exits. Dein Code bleibt einfach und du musst nicht tracken, welcher Exit welchen Request bearbeitet hat.
Die zweite Anmerkung betrifft das, was NICHT im Snippet steht. Die Deduplizierung über Jobbörsen hinweg (dieselbe Data-Engineer-Rolle auf LinkedIn, Indeed und der eigenen Karriereseite des Unternehmens, mit drei leicht unterschiedlichen Titeln) ist dein Problem, nicht das des Collection Layers. Wir haben beobachtet, wie Teams dies unterschätzen. Normalisierung frisst mehr Engineering-Zeit als das Fetchen. Hier konkurrieren letztendlich die meisten Talent-Intelligence-Produkte.
Ergebnisse
Ein Talent-Intelligence-Team, das 200 Unternehmen über drei Jobbörsen verfolgt, benötigt etwa 50.000 Page Fetches pro Woche: Suchergebnisse, Detailseiten von Jobs und gelegentliche Aktualisierungen von Unternehmensseiten. Die Zahlen, die du bei diesem Workload erreichen möchtest:
- Erfolgsquote über 95 % bei Zielen der Indeed-Klasse. Erfolg bedeutet hier gerendertes HTML mit ausgefülltem Gehaltsband und Veröffentlichungsdatum.
- Kosten pro Job unter 0,004 $ End-to-End, einschließlich Rendering und Exit-Auswahl.
- Refresh-Kadenz von 6 bis 12 Stunden für aktive Rollen, damit deine Hiring-Signal-Dashboards dem Markt nicht hinterherhinken.
Diese Zahlen dienen der Veranschaulichung und basieren auf Berichten von Teams, die dieses Split-Stack-Pattern nutzen. Deine tatsächlichen Kosten hängen davon ab, welche Jobbörsen du ins Visier nimmst und wie aggressiv du nach frischen Einträgen filterst.
Fazit
Jobbörsen sind im Schwierigkeitsgrad mittlerweile näher an Ad-Tech und Ticketing als am allgemeinen E-Commerce. Das ist ein echter Wandel und erklärt, warum Scraping-Bibliotheken, die 2024 funktionierten, 2026 immer wieder an derselben Wand scheitern.
Teams, die darüber hinaus skalieren, betrachten den "Scraper" nicht mehr als Arbeitseinheit. Sie sehen Sessions, Exits und Deduplizierung als drei getrennte Anliegen. Sie kaufen die Infrastruktur für die ersten beiden, damit ihre Engineers ihre Woche mit dem dritten verbringen können. Die günstigsten Stellenanzeigen-Daten sind die, die du nach einer Markierung nicht neu erfassen musst.