Vergleich der 5 besten APIs zum Scrapen von Stellenanzeigen
Wir haben fünf führende Web-Scraping- Anbieter auf fünf großen Jobplattformen verglichen, indem wir insgesamt 12.500 Anfragen durchgeführt und anschließend die Erfolgsquote, die Bearbeitungszeit und die Metadatenausgabe jedes Anbieters gemessen haben.
Benchmark für Job-Posting-Scraper
Weitere Einzelheiten zum Testverfahren finden Sie im Abschnitt zur Benchmark-Methodik .
Domainabdeckung durch Anbieter
✅ = unterstützt, gibt HTML zurück
✅ ✅ = unterstützt, gibt strukturierte Daten zurück
❌ = Keine Daten zurückgegeben
Job-Scraping-Performance nach Domäne
Verfügbare Metadatenfelder für Stellenanzeigen-APIs
Bright Data ist der einzige Anbieter, der strukturiertes JSON für Stellenanzeigen liefert. Die folgende Tabelle gruppiert die strukturierten Felder von Bright Data in gemeinsame Kategorien, sodass Sie die verfügbaren Funktionen der einzelnen Plattformen vergleichen können.
Job-Scraping-Benchmark-Ergebnisse
Bright Data führte den Benchmark mit einer durchschnittlichen Erfolgsquote von 90 % über alle fünf Jobplattformen hinweg an. Die Einrichtung ist in zwei Integrationsmodi unterteilt:
- Spezielle Datensatz-APIs (strukturiertes JSON) für LinkedIn , Indeed und Glassdoor
- Web Unblocker- Proxy (gerendertes HTML) für Craigslist und ZipRecruiter
Vier Domains erreichten eine Erfolgsquote von 100 %: LinkedIn, Indeed, Craigslist und Glassdoor. Die Bearbeitungszeiten hingen von der Integration ab. Web-Unblocker-Anfragen an Craigslist wurden im Durchschnitt in etwa einer Sekunde beantwortet, an LinkedIn in sieben und an Indeed in 17 Sekunden. Glassdoor benötigte 53 Sekunden. ZipRecruiter war mit 53 % die einzige Domain, die unter dem Schwellenwert lag. Hier stieß der Web-Unblocker bei einem Teil der URLs auf Weiterleitungen aufgrund abgelaufener Token.
Sichern Sie sich 25 % Rabatt auf die Web-Scraping-APIs (9912591833) mit dem Aktionscode API25 (
Website besuchen2828391027).
Oxylabs erreichte eine durchschnittliche Erfolgsquote von 77 % auf allen fünf Plattformen. Der Benchmark wurde über die Web Scraper API mit source: universal ausgeführt, die gerendertes HTML zur lokalen Analyse zurückgibt.
Vier Domains erzielten gute Ergebnisse: Craigslist (100 %), Indeed (100 %), LinkedIn (98 %) und ZipRecruiter (90 %). Glassdoor bildete die Ausnahme; die meisten Anfragen brachen mit einem HTTP-408-Timeout ab, da der Echtzeit-Endpunkt die JavaScript-lastigen Seiten von Glassdoor nicht innerhalb seines internen Limits rendern konnte. Die Bearbeitungszeiten der funktionierenden Domains lagen zwischen 11 und 28 Sekunden.
Sichern Sie sich 2.000 kostenlose Scraping-Credits
Website besuchen Die Gesamtleistung von Decodo entsprach der von Oxylabs, mit einer durchschnittlichen Erfolgsquote von 77 %. Die Web-Scraper-API lief mit headless: html und proxy_pool: premium und lieferte gerendertes HTML, das wir lokal über CSS-Selektoren analysierten.
Die Ergebnisse pro Plattform entsprachen nahezu denen von Oxylabs: 100 % bei Craigslist, 100 % bei Indeed, 98 % bei LinkedIn, 89 % bei ZipRecruiter und 0 % bei Glassdoor. Der Fehler bei Glassdoor war jedoch anders gelagert: Die meisten Anfragen wurden auf API-Ebene abgelehnt, bevor die Seite geladen werden konnte. Die Ladezeiten auf den funktionierenden Domains lagen zwischen 12 und 29 Sekunden, wodurch Decodo im langsameren Bereich lag.
Nutzen Sie den Code SCRAPE30 für 30 % Rabatt
Website besuchen Das Gesamtergebnis von Nimble betrug 69 %, wobei der Großteil des Verlusts auf eine einzelne Plattform zurückzuführen war. Die zugehörige Web Extract API wurde mit aktiviertem Browser-Rendering ausgeführt ( render: true , driver: vx10 ).
Craigslist erreichte eine Trefferquote von 100 %, LinkedIn 86 %, Glassdoor 79 % und ZipRecruiter 69 %. Indeed fiel auf 14 %, da die gerenderten Seiten selten die von unseren Selektoren anvisierten DOM-Elemente für Stellenbeschreibungen enthielten. Die herausragende Stärke lag in der Geschwindigkeit: Indeed, Craigslist, LinkedIn und ZipRecruiter lieferten alle innerhalb von 6 bis 8 Sekunden Ergebnisse, während Glassdoor mit 30 Sekunden als einziger Anbieter eine Ausnahme darstellte.
Die Domain Zyte wies mit 58 % die niedrigste Erfolgsquote auf. Ihre Extract API lief mit browserHtml: true und rendert Seiten über einen Headless-Browser. Drei Domains funktionierten einwandfrei: 100 % bei Craigslist, 100 % bei Glassdoor und 89 % bei ZipRecruiter. Die beiden anderen schlugen komplett fehl.
- LinkedIn antwortete bei allen 500-Anfragen mit dem HTTP-Statuscode 451 (Nicht verfügbar aus rechtlichen Gründen).
- Der von Indeed gerenderte HTML-Code enthielt niemals die Job-Detail-DOM-Elemente.
Die Bearbeitungszeiten auf den untersuchten Plattformen reichten von 7 Sekunden bei ZipRecruiter bis 17 Sekunden bei Craigslist, bei Glassdoor lagen sie bei 16 Sekunden.
Benchmark-Methodik für Job-Scraping
Wir haben fünf führende Web-Scraping-Anbieter auf fünf großen Jobplattformen (LinkedIn, Indeed, Glassdoor, Craigslist und ZipRecruiter) verglichen und insgesamt 12.500 Anfragen durchgeführt. Jeder Anbieter erhielt pro Plattform die gleichen 500 URLs einzelner Stellenanzeigen, die nacheinander mit einer Verzögerung von zwei Sekunden zwischen den Anfragen übermittelt wurden.
Anbieter und Integration
Jeder Provider betrieb seinen eigenen Produktionsendpunkt, ohne vorgeschaltete benutzerdefinierte Proxys oder Middleware von Drittanbietern.
Bright Data kombinierte zwei Integrationsmodi. Für LinkedIn, Indeed und Glassdoor wurden dedizierte Dataset-APIs verwendet, die strukturiertes JSON zurückgeben. Für Craigslist und ZipRecruiter kam der Web-Unblocker-Proxy zum Einsatz, der gerendertes HTML liefert.
Oxylabs durchlief seine Web Scraper API mit source: universal und gab gerendertes HTML auf jeder Domain zurück.
Decodo durchlief seine Web Scraper API mit headless: html und proxy_pool: premium und gab ebenfalls gerendertes HTML zurück.
Nimble wurde mit render: true und driver: vx10 über seine Web Extract API ausgeführt und erzeugte gerendertes HTML.
Zyte durchlief seine Extract API mit browserHtml: true und erzeugte erneut gerendertes HTML.
Bei HTML-Antworten haben wir die Seite lokal mit CSS-Selektoren analysiert, die auf die Job-Detail-Elemente jeder Plattform abzielen (Stellenbezeichnung, Firmenname, Standort, Gehalt, Beschäftigungsart und ein Seitenindikator).
Timeout und Ratenbegrenzung
Asynchrone Anfragen hatten eine maximale Ausführungszeit von 10 Minuten. HTTP-429-Antworten lösten eine Wartezeit von 30 Sekunden mit bis zu 3 Wiederholungsversuchen aus; alles darüber hinaus wurde als Fehler für die URL protokolliert.
Validierungsregeln
Jede Anfrage wurde dreifach geprüft.
Die Übermittlungsprüfung erforderte einen HTTP-Statuscode von 200 bis 399 oder 404 vom Provider. Die Ausführungsprüfung verlangte, dass asynchrone Jobs innerhalb des Timeout fehlerfrei abgeschlossen werden; synchrone Provider bestanden diese Prüfung automatisch. Die Validierungsprüfung verlangte, dass mindestens einer der job_title oder company_name als nicht leerer String zurückgegeben wurde. Bei JSON-Providern stammte dieser Wert aus der geparsten Antwort; bei HTML-Providern aus den CSS-Selektorübereinstimmungen.
Eine Anfrage, die eine 404-Seite erkannte (HTTP 404, „Seite nicht gefunden“-Inhalt oder das explizite „tote Seite“-Signal eines Anbieters), wurde ebenfalls als gültig gezählt, da der Anbieter korrekt einen nicht verfügbaren Eintrag identifiziert hatte.
Leere Antworten ohne Fehlermeldung wurden zunächst als gültig gewertet und anschließend erneut geprüft: Falls ein anderer Anbieter tatsächliche Auftragsdaten unter derselben URL extrahierte, wurde die leere Antwort als ungültig eingestuft. 404-Fehler waren von dieser Umstufung ausgenommen; dem expliziten Signal eines Anbieters „Seite existiert nicht“ wurde vertraut, sofern es nicht durch tatsächlich extrahierte Daten eines anderen Anbieters widerlegt wurde.
Ein Durchlauf wurde nur dann als insgesamt erfolgreich gewertet, wenn Einreichung, Ausführung und Validierung alle erfolgreich waren.
Gemessene Kennzahlen
Die Validierungserfolgsrate ist der Anteil der URLs, die alle drei Prüfungen bestanden haben.
Die End-to-End-Bearbeitungszeit ist die Zeit in Sekunden, die von der Anfrage bis zum Empfang der Antwort vergeht. Bei asynchronen Anbietern beinhaltet dies die Abfragezeit bis zum Abschluss des Datensatz-Jobs.
Die verfügbaren Metadatenfelder für Anbieter, die strukturiertes JSON zurückgeben, entsprechen der Anzahl eindeutiger Felder in allen Antworten, berechnet als Mengenvereinigung. Für HTML-Anbieter entspricht dies dem festen CSS-Schema mit fünf Selektoren, das wir pro Plattform verwendet haben.
FAQs
Gesammelte Stellenanzeigendaten werden häufig für die Analyse des Arbeitsmarktes, Gehaltsvergleiche, Wettbewerbsanalysen (welche Unternehmen welche Positionen besetzen), Talentpool-Mapping, Automatisierung des Rekrutierungsprozesses und die Bereitstellung von Stellenportalen verwendet. Unternehmen nutzen sie außerdem, um Trends bei der Anzahl der Stellenanzeigen, geografische Konzentrationen und die Besetzungsgeschwindigkeit von Stellen bei Wettbewerbern zu verfolgen.
Das hängt vom Anwendungsfall ab. Für die Echtzeit-Recruiting-Automatisierung sind tägliche oder stündliche Datenabfragen üblich. Für Marktberichte reichen wöchentliche oder monatliche Abfragen in der Regel aus. Stellenanzeigen werden nach Besetzung der Stelle meist schnell entfernt, daher verlieren ältere Daten rasch an Wert.
Das Auslesen öffentlich zugänglicher Daten ist in den meisten Ländern grundsätzlich legal, doch die meisten großen Jobplattformen (LinkedIn, Glassdoor, Indeed) haben Nutzungsbedingungen, die den automatisierten Zugriff verbieten. In der Vergangenheit wurden bereits mehrere Klagen gegen solche Nutzer eingereicht. Bei kommerziellen Anwendungsfällen ist eine rechtliche Prüfung ratsam, insbesondere wenn personenbezogene Daten betroffen sind.
Jobplattformen investieren massiv in Maßnahmen gegen Web-Scraping. CAPTCHAs, Login-Overlays, JavaScript-generierte Inhalte, häufige Layoutänderungen und IP-basierte Ratenbegrenzung gehören zum Standard. Manche Plattformen verwenden zudem unterschiedliche DOM-Strukturen für Bots und reguläre Nutzer. Aufgrund dieser Schutzmaßnahmen setzen viele Teams auf Managed-Scraping-APIs, anstatt eigene Scraper zu entwickeln.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.