Die Herausforderung
Ein Benchmark von ApplyArc aus dem Juni 2026 hat fünf LinkedIn-Job-Scraper bei 200 realen Job-Abrufen getestet. Drei führten dazu, dass der Account nach etwa 50 Speichervorgängen markiert oder unbemerkt gedrosselt wurde. Nur zwei blieben völlig unberührt.
Dieser Benchmark bringt es auf den Punkt. Jobbörsen waren früher leichte Ziele. Heute gehören sie zu den härtesten im offenen Web.
Wenn du etwas entwickelst, das auf Stellenanzeigendaten basiert (Personalplanung, Gehalts-Benchmarking, Talent-Mapping, Hiring-Signale für Aktienanalysen), kämpft deine Erfassungsschicht gegen eine Reihe von Abwehrmechanismen, die es vor zwei Jahren noch nicht gab. Indeed zeigt unbekannten Sessions Verifizierungsseiten an. LinkedIn korreliert browserseitige Signale über IP-Rotationen hinweg. Glassdoor setzt Rate-Limits pro ASN durch, nicht pro IP. ZipRecruiter verlagert Gehaltsspannen und Veröffentlichungsdaten in JavaScript, das nur gerendert wird, wenn deine Header wie ein echter Mensch aussehen und nicht wie ein Skript.
Die Grenze von 50 Abrufen ist also kein reines LinkedIn-Problem. Sie betrifft die gesamte Kategorie.
Warum Jobbörsen immer schwieriger werden
Im Jahr 2026 haben sich drei Dinge geändert, die sich gegenseitig verstärken.
Erstens: Die Bot-Erkennung basiert jetzt auf Verhalten. Statische Prüfungen (User-Agent, IP-Reputation, Requests pro Sekunde) reichten früher aus, um einfache Scraper zu stoppen. Heute nicht mehr. Aktuelle Schutzmechanismen analysieren, wie du dich auf der Website bewegst: Welche Seiten du in welcher Reihenfolge lädst, wie viel Zeit du dort verbringst und ob du dieselben JS-Bundles erneut abrufst, die ein echter Browser cachen würde. Wir haben über diese Entwicklung in Bot Detection Went Behavioral geschrieben. Jobbörsen haben das früh eingeführt, weil ihre Besucher wenige, wiederkehrende Aktionen ausführen (suchen, klicken, lesen, speichern). Das macht Skripte leicht erkennbar, wenn sie die halbe Kette überspringen.
Zweitens: Die Größe des Proxy-Pools spielt keine Rolle mehr. Ein Pool von 50 Millionen Residential-IPs nützt nichts, wenn die Abwehr auf Fingerprint-Korrelation auf Verbindungsebene und ASN-Reputation basiert. Das haben wir in Why Proxy Pool Size Stopped Mattering analysiert. Was funktioniert, ist die Wahl des passenden Exits für die Zielseite, nicht mehr Exits als alle anderen zu haben.
Drittens: die rechtliche Lage. Indeed und LinkedIn haben beide Rechtsabteilungen, die aktiv klagen. Die Zeiten, in denen man einen öffentlichen Scraper von der eigenen Heim-IP aus betreiben konnte, sind für jeden vorbei, der die gesammelten Daten kommerziell nutzen will.
Wie Datenerfassung heute aussieht
Für Talent-Intelligence-Projekte im Jahr 2026 funktioniert weiterhin ein zweigeteilter Stack: ein echter, im Browser gerenderter Abruf für geschützte Portale, kombiniert mit gezielter Exit-Auswahl, damit du nicht denselben Provider wie jeder andere Bot nutzt.
Mit einer Plattform wie FourA sind das zwei Produkte, die ineinandergreifen.
Browser übernimmt das Rendering: Sende eine URL mit unblocker: true und du erhältst gerendertes HTML, Cookies sowie einen Screenshot aus einer echten Browser-Session zurück. JS wird ausgeführt, lazy-loaded Felder werden befüllt und der Request besteht die Checks auf Verbindungsebene, die die meisten einfachen Clients blockieren. Die Proxy-Auswahl läuft im Hintergrund: Die Plattform wählt pro Request einen Exit-Knoten und gibt dessen opake Base36-ID in der Response zurück (auf oberster Ebene unter r.proxy bei Single/Browser oder r.session.proxy bei Auto). Folgeaufrufe können denselben Exit wiederverwenden, wenn du Session-Kontinuität benötigst. Für die meisten Jobbörsen ist Auto der richtige Einstiegspunkt. Es orchestriert Single, Proxy und Browser passend zu den Anforderungen des jeweiligen 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 wirklich bringt.
Die 50-Save-Wall nach ApplyArc-Art ist meist ein Session-Problem, kein Pool-Problem. Eine echte Browser-Session, die durchdacht rotiert wird, hält wesentlich länger durch, bevor sie das Rate Limit auslöst, als ein nativer HTTP-Client. Zudem enthält die Response eine opake Proxy-ID statt eines direkten Exits. Dein Code bleibt dadurch einfach und du musst nicht nachverfolgen, welcher Exit welchen Request verarbeitet hat.
Die zweite Anmerkung betrifft das, was NICHT im Snippet steht. Die Deduplizierung über mehrere Jobbörsen hinweg (dieselbe Data-Engineer-Rolle auf LinkedIn, Indeed und der Karriere-Website des Unternehmens mit drei leicht abweichenden Titeln) ist deine Aufgabe, nicht die der Erfassungsschicht. Wir haben oft erlebt, dass Teams das unterschätzen. Die Normalisierung bindet mehr Engineering-Zeit als das eigentliche Abrufen. Genau hier differenzieren sich letztlich die meisten Talent-Intelligence-Produkte.
Ergebnisse
Ein Talent-Intelligence-Team, das 200 Unternehmen auf drei Jobbörsen trackt, benötigt etwa 50.000 Seitenabrufe pro Woche: Suchergebnisse, Detailseiten von Stellenangeboten und gelegentliche Aktualisierungen von Unternehmensseiten. Die Richtwerte, die du bei diesem Workload anpeilen solltest:
- Erfolgsquote über 95% bei Zielen wie Indeed, wobei Erfolg gerendertes HTML mit Gehaltsspanne und Veröffentlichungsdatum bedeutet.
- Kosten pro Stelle unter 0,004 $ End-to-End, inklusive Rendering und Exit-Auswahl.
- Aktualisierungsintervall von 6 bis 12 Stunden für aktive Rollen, damit deine Hiring-Signal-Dashboards nicht hinter dem Markt zurückbleiben.
Diese Zahlen dienen der Veranschaulichung und basieren auf Berichten von Teams, die dieses Split-Stack-Muster einsetzen. Deine tatsächlichen Kosten hängen davon ab, welche Jobbörsen du ansteuerst und wie aggressiv du nach neuen Stellenanzeigen filterst.
Fazit
Jobbörsen sind im Schwierigkeitsgrad mittlerweile näher an Ad-Tech und Ticketing als an klassischem E-Commerce. Das ist ein spürbarer Wandel und erklärt, warum Scraping-Bibliotheken aus dem Jahr 2024 im Jahr 2026 immer wieder an denselben Hürden scheitern.
Teams, die erfolgreich skalieren, betrachten den "Scraper" nicht mehr als einzelne Arbeitseinheit. Sie behandeln Sessions, Exits und Deduplizierung als drei getrennte Aufgaben. Sie kaufen die Infrastruktur für die ersten beiden Punkte ein, damit ihre Engineers ihre Arbeitszeit voll auf den dritten Punkt konzentrieren können. Die günstigsten Jobdaten sind immer die, die du nach einer Blockierung nicht erneut erfassen musstest.