Top 6 Essensliefer-Scraper: Benchmark & Anwendungsfälle
Wir haben 6 Web-Scraping-Anbieter einem Benchmark unterzogen, um zu sehen, wie sie das Scraping von Essenslieferdaten handhaben. Dazu haben wir insgesamt 12.000 Anfragen über die Top-4-Essenslieferplattformen gesendet und Erfolgsquote, Fertigstellungszeit und Metadatenabdeckung gemessen.
Gesamtergebnisse des Benchmarks zum Scraping von Essenslieferdaten
Siehe den Abschnitt Benchmark-Methodik für weitere Details zum Testverfahren.
Domain-spezifische Ergebnisse des Benchmarks zum Scraping von Essenslieferdaten
Welche Art von Daten kann von Essensbestellplattformen extrahiert werden?
Verschiedene Plattformen legen unterschiedliche Datenschichten offen, etwa Menüdaten, Filialdaten und Produktdaten. In unserem Food-Delivery-Scraper-Benchmark haben wir beispielsweise Produktdaten von Instacart extrahiert.
Nur Bright Data lieferte eine strukturierte JSON-Antwort, und wir haben die 26 gelieferten Metadatenfelder unten gruppiert:
Menüdaten umfassen in der Regel Artikelnamen, Beschreibungen, Preise, Rabatte, Bilder, Ernährungskennzeichnungen, Kalorien, Anpassungsoptionen und Verfügbarkeit.
Restaurantdaten umfassen in der Regel den Restaurantnamen, die Adresse, Küchenarten, Bewertungen und Rezensionsanzahl, Liefergebühr, Mindestbestellwert, geschätzte Lieferzeit, Öffnungszeiten und aktive Aktionen.
Scraper für Essenslieferdaten
Bright Data war der einzige Anbieter, der sowohl die höchste Gesamterfolgsquote (94 %) als auch die schnellste durchschnittliche Fertigstellungszeit (11) über die vier Essensliefer-Domains erreichte. Die Erfolgsquote fiel in keiner einzelnen Domain unter 83 %.
Bright Data bietet zwei Hauptprodukte für das Scraping von Essenslieferdaten an:
Bright Data Web Unlocker API: ein einziger Unblocking-Endpoint, der Anti-Bot-Herausforderungen, CAPTCHAs und Proxy-Rotation automatisch verarbeitet und die HTML-Antwort der Seite zurückgibt. Zomato, Uber Eats und iFood wurden über diesen Endpoint gesendet.
Scraper-APIs: Bright Data veröffentlicht dedizierte Scraper-APIs und vorgefertigte Datasets für bestimmte Ziele. Unter den von uns getesteten Essensliefer-Domains wurde Instacart über die Bright Data-Instacart-Scraping-APIs unterstützt, mit vier fertigen Produkten im Katalog:
- Instacart Products per URL erfassen: nimmt eine Instacart-Produkt-URL entgegen.
- Instacart Products per Kategorie-URL entdecken: nimmt eine Kategorieseiten-URL entgegen.
- Instacart Products unified schema per URL erfassen: wie der URL-Sammler, mit normalisiertem Ausgabeschema.
- Instacart Products unified schema per Kategorie-URL entdecken: wie der Kategorie-Entdecker, mit normalisiertem Ausgabeschema.
Alle liefern strukturiertes JSON mit den vollständigen Produktmetadaten wie Name, Marke, Beschreibung, Preis, Filialname und Bewertungen. Für Instacart haben wir die Variante „Collect by URL“ verwendet.
Oxylabs zählte zu den zuverlässigsten Anbietern und erzielte die zweithöchste Gesamterfolgsquote von 91 % über die vier Essensliefer-Domains. Bei Instacart lag es mit Bright Data und Decodo bei einer Erfolgsquote von 100 % gleichauf, lieferte aber mit 10s die schnellste Fertigstellungszeit auf dieser Plattform. Die Gesamtfertigstellungszeit lag im Durchschnitt bei 27s.
Oxylabs bietet eine Web-Scraper-API mit mehreren Integrationsmodi (Realtime, Push-Pull, Proxy Endpoint). Mit dem Realtime-Endpoint rendert source=universal plus render=html die Seite in einem Headless-Browser und gibt die HTML-Antwort zurück.
Darüber hinaus bietet es dedizierte Quellen für bestimmte Websites. Für Instacart gibt es drei:
instacart_product: nimmt eine Produkt-ID entgegen und gibt geparstes JSON mit den vollständigen Metadaten des Produkts zurück.instacart_search: scraped Instacart-Suchergebnisse für ein bestimmtes Keyword.instacart: akzeptiert jede Instacart-URL.
Im Benchmark zum Scraping von Essenslieferdaten liefen Instacart-URLs über instacart_product.
Decodo zählte zu den konsistentesten Anbietern und erzielte mit 90 % die dritthöchste Gesamterfolgsquote sowie eine durchschnittliche Fertigstellungszeit von 29s über die vier Essensliefer-Domains. Auf UberEats erzielte es mit 94 % die höchste Erfolgsquote, war aber mit einem Durchschnitt von 29s insgesamt der langsamste Anbieter.
Decodo bietet eine einzige Web-Scraper-API (v2), die jedes Essensliefer-Ziel über einen Endpoint verarbeitet. Die Anfrage akzeptiert eine URL, einen Parameter target, gesetzt auf universal, und ein Flag headless, gesetzt auf html, sodass die Seite in einem echten Browser gerendert wird, bevor das HTML zurückgegeben wird. Anti-Bot-Umgehung, Proxy-Rotation und Rendering werden auf Decodos Seite übernommen.
Es gibt keine dedizierten Endpoints oder vorgefertigten Datasets für einzelne Essenslieferplattformen.
Nimble zählte zu den schnelleren Anbietern und erreichte mit 14s die zweitschnellste Gesamtfertigstellungszeit über die vier Essensliefer-Domains.
Nimble zählte zu den schnelleren Anbietern und erreichte mit 14s die zweitschnellste Gesamtfertigstellungszeit über die vier Essensliefer-Domains. Es erzielte auf iFood mit 98 % die höchste Erfolgsquote und erreichte wie Bright Data auf Zomato eine Erfolgsquote von 100 %. Allerdings blieb die Gesamterfolgsquote von 85 % hinter den Spitzenreitern zurück, was hauptsächlich auf die schwächere Leistung bei UberEats (67 %) und Instacart (74 %) zurückzuführen war.
Nimble bietet keine dedizierten APIs für eine der Essenslieferplattformen, daher lief jede URL über die allgemeine Extract-API. Der Endpoint akzeptiert eine beliebige URL zusammen mit einem Flag render: true und einem Stealth-Browser-Treiber (vx10 in unserem Setup) und gibt die Seite als gerendertes HTML zurück, wobei Anti-Bot-Umgehung, Proxy-Rotation und JavaScript-Ausführung vollständig innerhalb des Stacks von Nimble verwaltet werden.
Zyte belegte bei der Gesamterfolgsquote mit durchschnittlich 82 % über die vier Essensliefer-Domains den zweitniedrigsten Platz, lieferte jedoch eine moderate durchschnittliche Fertigstellungszeit von 18s. Die stärkste Leistung zeigte es auf iFood mit einer Erfolgsquote von 96 %, dort lag es nur hinter Nimble auf Platz zwei. Auf Instacart hatte es jedoch mit 62 % Erfolg zu kämpfen – das niedrigste Ergebnis aller Anbieter auf dieser Plattform.
Es verfolgt einen Single-Endpoint-Ansatz. Dieselbe Zyte-API bedient jede Anfrage, und das Verhalten wird über Flags in der Payload gesteuert. Das Setzen von browserHtml: true startet einen Headless-Browser, führt das JavaScript der Seite aus und gibt das vollständig gerenderte HTML zurück – der einzige Modus, der für clientseitig gerenderte Essensliefer-Websites brauchbare Ausgabe liefert. Dieses Flag blieb für jede von uns gescrapte Essensliefer-URL aktiviert.
Apify belegte bei beiden Kennzahlen den letzten Platz, mit einer durchschnittlichen Erfolgsquote von 56 % und der langsamsten Fertigstellungszeit von 41s über die vier Essensliefer-Domains. Bei Instacart versagte es vollständig. Die stärkste Leistung zeigte es auf Zomato mit einer Erfolgsquote von 89 %, lag damit aber unter den Anbietern mit Ergebnissen ungleich null auf jeder einzelnen getesteten Plattform auf dem letzten Platz.
Apify verfolgt einen anderen Ansatz. Statt eines einzigen universellen Endpoints läuft es auf einem Marketplace von Actors, jeweils ein eigenständiger Scraper für eine bestimmte Website. Keine der Essenslieferplattformen im Food-Delivery-Daten-Scraping-Benchmark hat einen First-Party-Apify-Actor, daher verwendeten wir den allgemeinen Web Scraper-Actor (apify/web-scraper) für jedes Ziel. Daher verwendeten wir den allgemeinen Web Scraper-Actor (apify/web-scraper) für jedes Ziel.
Web Scraper öffnet jede URL in einem Headless-Chrome-Browser, führt eine von uns geschriebene JavaScript-Seitenfunktion aus und gibt das Ergebnis als JSON zurück, mit Proxy-Rotation über den Apify Proxy und vollständigem JS-Rendering.
Ein wichtiger Unterschied: Das JSON von Apify ist kein eingebautes Produktschema. Die Bright Data-Instacart-Scraper-API gibt einen festen Satz von Feldern zurück (Produktname, Marke, Preis, Zutaten, Filialkette usw.), die Bright Data auf seiner Seite parst. Beim Apify Web Scraper enthält das JSON nur die Felder, die wir in der Seitenfunktion definieren.
Herausforderungen beim Scraping von Essenslieferdaten
Web-Scraping-Tools ermöglichen es Unternehmen, Menüs, Preise, Bewertungen und Bestände von Plattformen wie Zomato, Uber Eats, iFood und Instacart abzurufen. Dabei treten einige wiederkehrende Herausforderungen auf.
Clientseitiges Rendering: Die meisten Essensliefer-Websites sind Single-Page-Apps, die mit React, Next.js oder Angular erstellt wurden, und ein großer Teil des sichtbaren Inhalts befindet sich nicht im anfänglichen HTML. DoorDash-Produktseiten rendern das eigentliche Produkt beispielsweise innerhalb eines Modals, das erst nach der JavaScript-Hydration geöffnet wird. Scraper ohne echte Browser-Schicht geben nur das Gerüst der Filiale ohne Produktdaten zurück.
Geo-Blocking: iFood ist auf Brasilien beschränkt und weist die meisten Nicht-BR-IPs zurück. Ein Anbieter kann jeden Anti-Bot-Check bestehen und diese Domain dennoch nicht bestehen, wenn sein Proxy-Pool keine stabilen brasilianischen Residential-Exits hat.
Bot-Erkennung: Instacart und DoorDash sitzen hinter aggressiven Bot-Erkennungssystemen (Cloudflare bei DoorDash, Systeme der Klasse DataDome / PerimeterX bei Instacart), die JavaScript-Challenges, verhaltensbasiertes Fingerprinting und Rate-Limits pro Konto kombinieren. Generische HTTP-Scraper erhalten 403s oder stecken bleibende Challenge-Seiten, weshalb sich jeder Anbieter in unserem Benchmark bei diesen Zielen auf eine eingebaute Unblocking- und JavaScript-Rendering-Schicht stützt.
Sitzungsstabilität: Bei langen Paginierungsjobs verringern Sticky-Residential-Sessions mit langen TTLs Blockierungen während des Laufs. Ein zu aggressiver IP-Wechsel mitten im Scrollen verwirft das Session-Cookie und zwingt die Website, die erste Seite erneut anzuzeigen.
Als bevorzugte Quelle hinzufügenMethodik des Benchmarks zum Scraping von Essenslieferdaten
Wir haben 6 Web-Scraping-Anbieter gegen 4 Essenslieferplattformen getestet: Zomato, Uber Eats, iFood und Instacart.
Diese Plattformen wurden auf Grundlage der am besten bewerteten Essensliefer-Websites von Tranco ausgewählt. Jede Plattform steuerte 500 eindeutige Produkt- oder Filial-URLs bei, die aus echten Katalog-Feeds gesammelt wurden, für insgesamt 2.000 URLs und 12.000 Anfragen über alle Anbieter hinweg.
Essensliefer-Dataset
Das Dataset umfasste 500 URLs pro Plattform. Jede URL war eine echte, zur Laufzeit aktive Seite. Die URLs wurden dedupliziert und das Dataset wurde über alle Anbieter hinweg identisch gehalten, um einen fairen Vergleich zu gewährleisten.
Setup des Essensliefer-Benchmarks
Alle Anbieter wurden mit den von ihnen empfohlenen Konfigurationen für beliebige Webseiten aufgerufen: universelle Endpoints mit JavaScript-Rendering, wo verfügbar.
In zwei Fällen verwendeten wir dedizierte APIs anstelle des universellen Endpoints, weil der Anbieter das Ziel explizit unterstützt. Bright Data wurde über seine Instacart-Dataset-API aufgerufen, die strukturiertes JSON zurückgibt, und Oxylabs wurde über seine Quelle instacart_product mit der Produkt-ID aufgerufen, die ebenfalls strukturiertes JSON zurückgibt.
Jede Anfrage wurde als einzelner Aufruf an den Anbieter gesendet. Die Anbieter wurden nacheinander getestet, einer nach dem anderen, um eine Vermischung des Rate-Limit-Drucks über die Dienste hinweg zu vermeiden. HTTP-429-Antworten lösten ein automatisches Back-off von 30 Sekunden aus und wurden bis zu 3 Mal wiederholt.
Was als erfolgreicher Scrape zählt
Eine Anfrage wurde nur dann als gültig gewertet, wenn alle folgenden Bedingungen erfüllt waren. Erstens musste der Anbieter einen 2xx, 3xx oder 404-HTTP-Status zurückgeben; alles andere, einschließlich 4xx-Blockierungen und 5xx-Fehlern, wurde als Fehlschlag gewertet.
Zweitens musste der Parser bei 200-Antworten mindestens eines der Zielfelder der Plattform aus dem zurückgegebenen Inhalt extrahieren. Die Extraktionsmethode hing vom Antwortformat ab. Für Anbieter, die rohes HTML zurückgaben (Decodo, Oxylabs Web Unblocker, Nimble, Zyte und Apify), verwendeten wir CSS-Selektoren, die auf die strukturierten Produkt- oder Restaurantdaten-Container auf den einzelnen Plattformen abzielten. Für Anbieter, die strukturiertes JSON zurückgaben (Bright Datas Instacart-Scraper-API und die Oxylabs’ instacart_product-Quelle), lasen wir die entsprechenden Felder direkt aus der JSON-Antwort, ohne CSS-Selektoren zu benötigen. Für Zomato, Uber Eats und iFood suchte der Parser nach einem der Felder Titel, Bewertungspunktzahl, Bewertungslabel oder Preisspanne. Für Instacart suchte er nach Produktname, Marke, Beschreibung oder einem positiven numerischen Preis.
Drittens wurden Seiten, die erfolgreich geladen wurden, aber eine entfernte Auflistung darstellten (HTML mit Formulierungen wie „nicht gefunden“, „nicht mehr verfügbar“ oder „Restaurant nicht gefunden“), als gültig gewertet, da der Anbieter seine Aufgabe erfüllt hatte und der Inhalt einfach nicht mehr vorhanden war.
3xx- und 404-Antworten wurden als automatisch-pass behandelt: Der Anbieter hatte bewiesen, dass er die Seite erreichen konnte, und das Fehlen von Produktdaten war eine Eigenschaft der URL, nicht des Scrapers.
Was wir gemessen haben
Für jede Anfrage protokollierte der Runner den Validierungserfolg als booleschen Wert, die End-to-End-Zeit als gesamte Wanduhr-Sekunden von der Übermittlung bis zu dem Zeitpunkt, zu dem die Antwort nutzbar war, sowie die Gesamtzahl der Metadaten als Anzahl der im geparsten Ergebnis vorhandenen Felder.
Diese Forschung zitieren
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{sipi2026,
author = {Şipi, Nazlı},
title = {{Top 6 Essensliefer-Scraper: Benchmark & Anwendungsfälle}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/scrape-food-delivery-data}},
note = {AIMultiple. Abgerufen am 29. September 2026}
}Ergebnisse und Zeitstempel von 15.5 Tausend Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 2 CSV-Dateien und eine README enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
3 AktualisierungenEin Benchmark für Food-Delivery-Scraping mit 6 Anbietern samt Erfolgsraten, Antwortzeiten und Ergebnissen je Anbieter hinzugefügt.
Abschnitt zur Benchmark-Methodik hinzugefügt, der die 6 Anbieter, 4 Plattformen, 2.000 URLs, Datensatz, Setup, Gültigkeitsregeln und Metriken abdeckt.
Eine Abbildung und ihre Quelle wurden aus dem Abschnitt „Bewertungen\Rezensionen“ entfernt.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.