Die Herausforderung
Ein Benchmark von ApplyArc vom Juni 2026 testete fünf LinkedIn-Job-Scraper bei 200 echten Job-Abrufen. Drei führten dazu, dass der Account markiert oder nach etwa 50 Saves unbemerkt gedrosselt wurde. Nur zwei überlebten unbeschadet.
Dieser Benchmark erzählt die ganze Geschichte. Früher waren Jobbörsen einfache Ziele. Heute gehören sie zu den schwierigsten im offenen Web.
Wenn du etwas baust, das von Stellenanzeigendaten abhängt (Personalplanung, Gehalts-Benchmarking, Talent-Mapping, Hiring-Signale für die Aktienanalyse), kämpft deine Datenerfassungsschicht gegen eine Reihe von Abwehrmethoden, die es vor zwei Jahren noch nicht gab. Indeed wirft unbekannten Sessions CAPTCHAs entgegen. LinkedIn korreliert browserseitige Signale über IP-Rotationen hinweg. Glassdoor nutzt Rate Limits pro ASN, nicht pro IP. ZipRecruiter verlagert die Gehaltsspanne und das Veröffentlichungsdatum in JavaScript, das nur gerendert wird, wenn deine Header wie ein Mensch aussehen und nicht wie ein Skript.
Die 50-Saves-Sperre ist also kein LinkedIn-Problem. Sie ist eine Eigenschaft der gesamten Kategorie.
Warum Jobbörsen immer schwieriger werden
Drei Dinge haben sich 2026 geändert, und sie summieren sich.
Erstens: Die Bot-Erkennung ist verhaltensbasiert geworden. Statische Prüfungen (User-Agent, IP-Reputation, Requests pro Sekunde) reichten früher aus, um Hobby-Scraper zu stoppen. Heute nicht mehr. Heutige Abwehrmethoden beobachten, wie du dich durch die Website bewegst: welche Seiten du in welcher Reihenfolge lädst, wie lange du verweilst, ob du dieselben JS-Bundles erneut abrufst, die ein echter Browser cachen würde. Wir haben über diesen Wandel in Die Bot-Erkennung ist verhaltensbasiert geworden geschrieben. Jobbörsen haben dies früh übernommen, da ihre Besucher eine geringe Anzahl wiederholbarer Aktionen ausführen (suchen, klicken, lesen, speichern), was ein Skript leicht erkennbar macht, wenn es die Hälfte der Sequenz überspringt.
Zweitens: Die Größe des Proxy-Pools spielt keine Rolle mehr. Ein Residential-Pool mit 50 Millionen IPs hilft nicht, wenn die Abwehr auf Fingerprint-Korrelation auf der Verbindungsebene und der ASN-Reputation basiert. Wir haben das in Warum die Größe des Proxy-Pools keine Rolle mehr spielt behandelt. Was funktioniert, ist die Auswahl des richtigen Exits für die Zielseite, nicht mehr Exits als alle anderen zu haben.
Drittens: Rechtliche Schritte. Indeed und LinkedIn haben beide Rechtsteams, die Klage einreichen. Die Ära, in der man einen öffentlichen Scraper von der eigenen Heim-IP aus betreibt, ist für jeden vorbei, der plant, die gesammelten Daten zu verkaufen.
Wie die Datenerfassung heute aussieht
Für die Talent-Intelligence-Arbeit im Jahr 2026 ist das Muster, das weiterhin funktioniert, ein geteilter Stack: ein echter, im Browser gerenderter Abruf für die geschützten Boards, kombiniert mit einer sorgfältigen Exit-Auswahl, damit du nicht vom selben Anbieter wie jeder andere Bot kommst.
Mit einer Plattform wie FourA sind das zwei Produkte, die miteinander kommunizieren.
Der 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 Prüfungen auf Verbindungsebene, die die meisten einfachen Clients abfangen. Die Proxy-Auswahl läuft im Hintergrund: Die Plattform wählt pro Request einen Exit und gibt dessen opake Base36-ID in der Response zurück (unter r.proxy auf der obersten Ebene bei Single/Browser oder unter r.session.proxy bei Auto), sodass nachfolgende Aufrufe denselben Exit wiederverwenden können, wenn du Session-Kontinuität benötigst. Für die meiste Arbeit mit Jobbörsen ist Auto der richtige Einstiegspunkt. Es orchestriert Single, Proxy und Browser basierend auf 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 tatsächlich bringt.
Die 50-Saves-Sperre im ApplyArc-Stil ist meist ein Session-Problem, kein Pool-Problem. Eine echte Browser-Session, die klug rotiert wird, hält weitaus länger durch, bevor sie das Rate Limit auslöst, als es ein nackter HTTP-Client tun würde. Und die Response enthält eine opake Proxy-ID anstelle eines rohen Exits, sodass dein Code einfach bleibt und du nicht nachverfolgen musst, welcher Exit welchen Request verarbeitet hat.
Die zweite Anmerkung betrifft das, was NICHT im Snippet enthalten ist. Die Deduplizierung über verschiedene Plattformen hinweg (dieselbe Data-Engineer-Rolle auf LinkedIn, Indeed und der eigenen Karriereseite des Unternehmens mit drei leicht unterschiedlichen Titeln) ist dein Problem, nicht das der Erfassungsschicht. Wir haben erlebt, dass Teams dies unterschätzen. Die Normalisierung verschlingt mehr Entwicklungszeit als das Abrufen selbst, und genau hier konkurrieren die meisten Talent-Intelligence-Produkte letztendlich.
Ergebnisse
Ein Talent-Intelligence-Team, das 200 Unternehmen auf drei Plattformen verfolgt, benötigt etwa 50.000 Seitenabrufe pro Woche: Suchergebnisse, Job-Detailseiten und gelegentliche Aktualisierungen der Unternehmensseiten. Die Zahlen, die du bei diesem Arbeitspensum erreichen möchtest:
- Erfolgsquote von über 95 % bei Zielen der Indeed-Klasse, wobei Erfolg gerendertes HTML mit ausgefüllter Gehaltsspanne und Veröffentlichungsdatum bedeutet.
- Kosten pro Job unter 0,004 $ End-to-End, einschließlich Rendering und Exit-Auswahl.
- Aktualisierungsintervall 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-Muster nutzen. Deine tatsächlichen Kosten hängen davon ab, welche Jobbörsen du anvisierst und wie aggressiv du nach neuen Beiträgen filterst.
Wichtigste Erkenntnis
Jobbörsen sind heute vom Schwierigkeitsgrad her näher an Ad-Tech und Ticketing als an allgemeinem E-Commerce. Das ist eine echte Veränderung, und sie erklärt, warum Scraping-Bibliotheken, die 2024 noch funktionierten, im Jahr 2026 immer wieder an derselben Sperre scheitern.
Die Teams, die diese Hürde erfolgreich überwinden, betrachten den „Scraper“ nicht mehr als eine einzige Arbeitseinheit. Sie betrachten Sessions, Exits und Deduplizierung als drei separate Aufgabenbereiche. Sie kaufen die Infrastruktur für die ersten beiden ein, damit ihre Entwickler ihre Zeit für den dritten Bereich nutzen können. Die günstigsten Stellenanzeigendaten sind diejenigen, die du nach einer Sperrung nicht erneut erfassen musstest.