Eine einzelne Google-Shopping-Suchergebnisseite kann bezahlte Platzierungen mitten zwischen organischen Treffern verstecken, bei nicht vorrätigen Artikeln Preise komplett weglassen und dasselbe Produkt über fünf verschiedene Händler hinweg mehrfach anzeigen. Ich habe mir in den letzten Wochen neun Tools angesehen, die dieses Durcheinander in saubere, nutzbare Daten verwandeln sollen — und die ehrliche Antwort ist: Das „beste“ Tool hängt vollständig davon ab, ob Sie als Entwickler eine Pipeline bauen oder als Marketer einfach nur bis Freitag Zahlen in einer Tabelle brauchen.
Diese Trennung zieht sich durch die gesamte Recherche. In r/learnpython und r/node tauschen sich Leute über Puppeteer, Playwright und Proxy-Rotation aus. In r/PPC fragen Nutzer eher nach etwas in der Art von „Gebt mir einfach die Daten, ich will keinen Code anfassen“. Statt diese neun Tools also alphabetisch aufzulisten oder einem Anbieter mit der schillerndsten Startseite pauschal ein „Best Overall“-Abzeichen zu verleihen, habe ich jedes Tool anhand von sechs klaren Kriterien bewertet und nach Workflow sortiert: zuerst Managed-SERP-APIs, dann Proxy- und Scraper-Infrastruktur, anschließend eine Developer-Actor-Plattform und zuletzt ein No-Code-Browser-Tool.
Was macht einen „besten“ Google-Shopping-Scraper aus? Unsere Bewertungskriterien
„Best“ trägt in den meisten Listicles viel zu viel Gewicht, also definiere ich hier genau, was damit gemeint ist. Ich habe alle neun Tools anhand derselben sechs Faktoren bewertet, statt einfach die Marketingversprechen der jeweiligen Anbieter zu wiederholen:
- Datenabdeckung — liefert das dokumentierte Schema zuverlässig Preis, Händler, Bewertung, Anzahl der Reviews, Versand und eine echte Unterscheidung zwischen bezahlten und organischen Treffern?
- Locale-/Geo-Support — lassen sich Land, Sprache oder Gerät wirklich gezielt ansteuern, oder hängt alles davon ab, wohin die IP des Proxys zufällig aufgelöst wird?
- Einrichtungsaufwand — ist das nur ein API-Key plus GET-Request, oder ein geplanter Task mit Callbacks, oder ein Workflow aus zwei Schritten mit Token-Verkettung, oder eine Seite, auf die man klickt?
- Wartungsaufwand — wer ist zuständig, wenn Google sein HTML ändert oder ein CAPTCHA auftaucht: Sie oder der Anbieter?
- Export-/Integrationspfad — JSON-Export oder direkte Anbindung an Sheets, Airtable oder Ihr Data Warehouse?
- Preistransparenz — veröffentlicht der Anbieter echte Stückkosten, die man kalkulieren kann, oder muss man erst „Sales kontaktieren“, um überhaupt zu erfahren, was etwas kostet?
Was ich hier nicht mache: Erfolgsquoten, Geschwindigkeits-Benchmarks oder Genauigkeitsprozente erfinden. Niemand in dieser Liste hat unabhängig gegen die anderen gemessen, und Aussagen wie „99,9 % Erfolg“ oder „rasend schnell“ sind Marketingtexte, keine Messwerte. Sie bekommen stattdessen das, was die jeweilige Dokumentation tatsächlich belegt — und das ist, wie sich zeigt, ziemlich viel.
Entwickler wollen Code, Marketer wollen keinen Code
Wer schon länger in scraping-nahen Foren unterwegs ist, kennt diese Trennung bereits. Trotzdem lohnt es sich, sie klar auszusprechen, weil sie die Reihenfolge dieser Liste erklärt. Entwickler, die eine Datenpipeline aufbauen, wollen einen API-Key, vorhersehbares JSON, explizite Locale-Parameter und ein Schema, das sich downstream validieren und normalisieren lässt. Genau diese Nutzer fragen nach Proxy-Rotation und Headless-Browser-Rendering.
Marketing- und PPC-Teams wollen eher etwas nach dem Motto: „Zeig auf die Seite, gib mir die Tabelle.“ Sie möchten kein Puppeteer-Skript pflegen, wenn Google das Shopping-Layout zum dritten Mal in diesem Quartal ändert (und das passiert — Google ändert das Shopping-Markup oft genug, dass sogar API-Anbieter Changelogs dazu veröffentlichen).
Darum führt diese Liste von Managed-SERP-API-Anbietern (SerpApi, Serper, SearchAPI, DataForSEO) — strukturiertes JSON, keine Proxy-Arbeit, aber trotzdem Code nötig — über Proxy- und Scraper-Infrastruktur (Bright Data, Oxylabs), die mehr Kontrolle bei mehr Setup-Aufwand bietet, weiter zu einer vollständig anpassbaren Developer-Actor-Plattform (Apify) und endet mit Thunderbit, einem No-Code, agentischen Browser-Tool für alle, die wirklich keinen Scraping-Code schreiben oder pflegen wollen.
Die 9 besten Google-Shopping-Scraper im Überblick
| Tool | Erfassungsmodell | Einrichtungsaufwand | Locale-Support | Geeignet für | Wartungsaufwand |
|---|---|---|---|---|---|
| SerpApi | Verwaltete Shopping-API | Gering (API-Key) | Stark (location, gl, hl, device) | Data Engineers, SEO-Tools | Vom Anbieter übernommen |
| Serper | Allgemeine SERP-API, Shopping als Ergebnistyp | Gering | Mittel (Land/Sprache dokumentiert) | Kostenbewusste Entwickler | Vom Anbieter übernommen |
| SearchAPI | Verwaltete Shopping- + Product-Offers-API | Gering bis mittel (zweistufig für Offers) | Mittel | Teams für Angebots-/Händlervergleiche | Vom Anbieter übernommen |
| DataForSEO | Task-basierte Merchant-API | Mittel (Queue/Callback) | Stark | Große oder geplante Pipelines | Vom Anbieter übernommen |
| Bright Data | Dataset + Scraper API + SERP API | Mittel (je nach Oberfläche) | Sehr stark | Enterprise-Datenteams | Geteilt |
| Oxylabs | Zweistufige Suche + Produktdetail-API | Mittel (Token-Verkettung) | Sehr stark | Enterprise-Datenteams | Geteilt |
| Scrapingdog | Dedizierter Shopping-Endpunkt | Gering bis mittel | Mittel | Budgetbewusste Entwickler | Vom Anbieter übernommen |
| Apify | Actor-/Developer-Plattform | Mittel bis hoch | Hängt vom Actor ab | Individuelle Pipeline-Bauer | Vom Nutzer verwaltet |
| Thunderbit | Agentische No-Code-Browser-Extraktion | Sehr gering (Ein-Klick-Extraktion) | Hängt von der Zielseite ab | Marketing/PPC, Nicht-Entwickler | Gering, seitenabhängig |
(Bitte prüfen Sie aktuelle Preise, Credit-Limits und Locale-Abdeckung direkt in den Live-Dokumentationen der Anbieter, bevor Sie sich festlegen — das ändert sich schnell, und mehrere dieser Anbieter haben 2026 bereits Breaking Changes veröffentlicht.)
1. SerpApi — Verwaltet, funktionsreich und ausdrücklich cache-bewusst
SerpApi betreibt eine dedizierte Google-Shopping-Engine (engine=google_shopping), die Ihre Suchanfrage entgegennimmt und strukturierte shopping_results zurückliefert — Position, Titel, Produkt-ID, Preis plus extrahierter numerischer Preis, alter Preis/Ratenzahlung, Lieferung, Zustand, Bewertung, Reviews und Bilder. Das ist ein wirklich starkes Schema, und SerpApi dokumentiert bezahlte Shopping-Ergebnisse separat über sein Google-Ads-Shopping-Schema, sodass man Sponsored Placements finden kann — nur eben nicht als einzelnes, verlässliches sponsored: true/false-Feld direkt in der dedizierten Shopping-Antwort.
Was SerpApi besonders macht, ist die Offenheit bei den Punkten, die später typischerweise Probleme verursachen. Beim Location-Targeting werden entweder eine kanonische Stadtangabe über location oder ein exaktes uule unterstützt, plus die separaten Parameter gl (Land), hl (Sprache) und device (Desktop, Tablet, Mobile). Außerdem wird klar gesagt, dass identische Suchanfragen standardmäßig bis zu einer Stunde aus dem Cache kommen können — Cache-Treffer sind kostenlos, no_cache=true erzwingt einen frischen Abruf. Solche Offenheit lassen die meisten Anbieter unter den Tisch fallen.
Die Preise (geprüft am 13.08.2026) sind öffentlich und monatlich: Free-Tier mit 250 Suchanfragen, Starter für 25 $ mit 1.000, bis hin zu Big Data für 275 $ mit 30.000. Nur erfolgreiche Suchen werden auf das Kontingent angerechnet — Cache-Treffer und fehlgeschlagene Requests nicht. Wichtig zu wissen: Google hat SerpApi Anfang 2026 wegen seiner Datenzugriffsmethoden verklagt; SerpApi bestreitet die Darstellung und sagt, man greife auf öffentliche, nicht authentifizierte Ergebnisse zu. Das ist eine laufende rechtliche Auseinandersetzung, kein Urteil — also als Risikofaktor betrachten, nicht als pauschalen Grund, das Tool zu meiden.
Am besten für: Entwickler, die das reichhaltigste dokumentierte Shopping-Schema und die klarste Kontrolle über Cache und Locale wollen.
2. Serper — Schnell, preiswert und mit der klarsten Freshness-Aussage
Serper positioniert sich als allgemeine Google-SERP-API, in der Shopping nur einer von mehreren Ergebnistypen ist — neben Search, Images, News, Maps und weiteren. Wenn Sie bereits normale Suchergebnisse abrufen und Shopping-Daten einfach ergänzen möchten, ist das deutlich reibungsloser, als noch einen zweiten dedizierten Anbieter aufzusetzen.
Das öffentliche Shopping-Beispiel liefert Titel, Quelle, direkten Händlerlink, formatierten Preis, Lieferung, Bewertung, Bewertungsanzahl, Angebotsanzahl, Produkt-ID und Position — solide für grundlegendes Monitoring von Produktkarten. Allerdings zeigen die öffentlichen Dokumente nicht dieselbe Tiefe bei Händlerangeboten oder Promo-Preisfeldern wie SearchAPI oder Oxylabs. Das stärkste Verkaufsargument von Serper ist die Freshness-Zusage: Jeder Abruf fragt Google live ab, nichts wird gecacht. Damit entfällt die Cache-Entscheidung, vor der SerpApi-Nutzer stehen — allerdings bezahlt man dann auch jeden wiederholten Abruf erneut.
Die Preisstruktur basiert auf vorab gekauften Credits statt auf Abos — zunächst 2.500 kostenlose Suchanfragen, danach 50 $ für 50.000 Credits, mit sinkendem Preis bis zu 0,30 $ pro 1.000 im obersten Tarif; die Credits sind sechs Monate gültig. Die Preisseite verrät zudem angenehm ehrlich, dass einzelne Requests 2–4 Sekunden dauern können, „wenn die Anfrage bei Google erneut versucht werden muss“ — eine reale Latenz, mit der man planen sollte, statt sie als bloßen Benchmark zu betrachten.
Am besten für: Teams, die bereits eine breitere SERP-API integrieren und Shopping als Zusatzfunktion wollen, nicht als eigenständiges Produkt.
3. SearchAPI — Starke Offer-Details, aber mit einem Doku-Haken
SearchAPI arbeitet mit einem zweistufigen Workflow, der wirklich nützlich ist, wenn Sie Preisvergleiche auf Händler-Ebene brauchen. Der Shopping-Endpunkt liefert die üblichen Kartenfelder plus ein product_token — und genau dieses Token schaltet eine separate Product Offers API frei, die ein offers-Array mit Händlerlink, Preis, Lieferkosten, Gesamtpreis, Lagerstatus und Zahlungsmethoden pro Verkäufer zurückgibt. Wenn Ihr Anwendungsfall lautet: „Zeig mir jeden Preis, zu dem dieses exakte Produkt bei verschiedenen Händlern verkauft wird“, ist das hier der direkteste Weg in dieser Liste.
Es gibt allerdings einen echten Stolperstein: Seit dem 15. Mai 2026 erzwingen Googles Änderungen, dass SearchAPI pro Anfrage ein frisches product_token benötigt — die älteren Parameter product_id/prds liefern jetzt nur noch einen einfachen 400-Fehler. Wer auf Basis älterer Codebeispiele oder Tutorials integriert, merkt das erst, wenn es zu spät ist.
SearchAPI weist außerdem ausdrücklich darauf hin, dass natürlichsprachliche Filter in Ihrer Anfrage (z. B. „unter 30 $“ oder „gebraucht“) nur Hinweise sind, keine harten Filter — Google kann trotzdem Ergebnisse außerhalb dieser Grenzen anzeigen, wenn die Trefferlage dünn ist. Encodierte shoprs-Filter sind der strikte Weg. Und es gibt einen ungelösten Dokumentationskonflikt, den man kennen sollte: SearchAPI bewirbt den Endpunkt als „real-time“, während das eigene Data-Processing-Agreement sagt, dass Ergebnisse zur Performance gecacht werden. Eine öffentliche TTL wird in beide Richtungen nicht dokumentiert. Wenn sich Preise schnell ändern, testen Sie also mit wiederholten Anfragen, bevor Sie eine Pipeline auf einer Freshness-Annahme aufbauen.
Die Preise (geprüft am 13.08.2026) beginnen bei 40 $/Monat im Developer-Tier mit 4 $ pro 1.000 Suchanfragen und sinken bei höheren Volumina; dokumentiert ist ein stündliches Limit von 20 % Ihres Monatskontingents.
Am besten für: Teams, die Vergleiche auf Verkäufer-/Offer-Ebene machen und einen Zweier-Request-Workflow sowie eigene Freshness-Tests akzeptieren können.
4. DataForSEO — Merchant- und Shopping-Daten im großen Stil, per Queue
DataForSEO fällt in dieser Gruppe wirklich aus dem Rahmen, weil es keine Live-Request-Response-API ist, sondern eine taskbasierte Queue. Sie posten einen Task mit Keyword, Standort und Sprache, erhalten eine Task-ID und holen Ergebnisse entweder per Polling ab oder per Callback-URL. Standardabruf only; für die Kern-Shopping-Endpunkte gibt es keinen Live-Modus, egal was die allgemeine Marketing-Sprache suggeriert.
Das ist wichtig, weil es den Einrichtungsaufwand verändert. Nicht schwer, aber ein anderes Denkmodell als „API aufrufen, JSON zurückbekommen“ — Sie verwalten Task-Zustände. Und die eigene Dokumentation sagt, dass ein Callback-Server, der innerhalb von 10 Sekunden nicht antwortet, den Task in eine „Tasks Ready“-Queue verschiebt, die man dann manuell abfragen muss.
Seinen Platz in dieser Liste verdient das Tool durch Bulk-Recherche: Der Products-Endpunkt liefert Ranking, Domain, Titel, Preis, alten Preis, Bewertung und Stimmzahl; Ergebnis-Typ-IDs unterscheiden explizit zwischen google_shopping_sponsored_carousel, google_shopping_paid und organischen Ergebnissen — tatsächlich eine der klarsten Sponsored-vs.-Organic-Unterscheidungen in der gesamten Liste. Außerdem wird offen gesagt, dass product_id dynamisch ist und null sein kann, und dass personalisierte Ranking-Faktoren (Nutzerhistorie, Standortpräferenzen) bewusst aus den Ergebnissen entfernt werden — eine ehrliche Einordnung, die viele Anbieter auslassen.
Abgerechnet wird pro Ergebnisblock (40 für Products, 10 für Sellers/Reviews) bei normaler Queue-Geschwindigkeit von bis zu 45 Minuten oder in einer Prioritäts-Queue in bis zu einer Minute zum doppelten Preis. Neue Konten erhalten 1 $ Testguthaben ohne Ablaufdatum.
Am besten für: Teams, die sich mit Queue-/Task-Workflows wohlfühlen und große Mengen Merchant-/Produktdaten auf Termin brauchen.
5. Bright Data — Drei Produkte unter einem Namen
Hier muss ich etwas langsamer werden, weil Bright Data tatsächlich drei verschiedene Wege für Google-Shopping-Daten anbietet — und die funktionieren überhaupt nicht gleich. Es gibt ein vorab erstelltes Dataset (beworben mit über 7,4 Milliarden Datensätzen, ausgeliefert als JSON/CSV/Parquet in Ihr Cloud-Data-Warehouse nach Zeitplan), eine Google Scraper API mit dedizierten Shopping-Scraper-IDs, die synchron oder asynchron Jobs ausführt, und eine SERP API, die Live-Shopping-URLs abruft und Ergebnisse in Echtzeit parst. Diese drei Dinge als ein einziges Produkt zu behandeln, machen viele Vergleichsartikel schlampig — hier nicht.
Die eigenen Beispieldaten des Datasets zeigen bei manchen Datensätzen null für Produkt-ID, Beschreibung, Bewertung und Review-Anzahl — ein guter Beleg aus erster Hand dafür, dass „strukturiertes Dataset“ nicht bedeutet, dass jedes Feld immer gefüllt ist. Die SERP API dokumentiert Product Listing Ads separat als eigene Ergebnistypen (top_pla, bottom_pla, jackpot_pla) mit Titel, Preis, Shop und Position — eine wirklich nützliche Trennung zwischen Sponsored und Organic, wenn Sie speziell die SERP API nutzen und nicht das Dataset.
Asynchrone Jobs über die Scraper API können insgesamt als „success“ zurückkommen, obwohl einzelne Eingaben im Batch fehlschlagen — die Doku weist ausdrücklich darauf hin, dass man ein errors-Feld prüfen und diese Fälle einzeln erneut versuchen soll. Das ist ein Wartungsdetail, das bei großen Batches eingeplant werden sollte.
Die Preise (geprüft am 13.08.2026) unterscheiden sich stark je nach Oberfläche: Das Dataset zeigte 250 $ für 100.000 einmalige Datensätze, die SERP API listete 5.000 kostenlose monatliche Requests mit Pay-as-you-go zu 1,50 $/1.000, und die dedizierte Shopping Scraper API hatte wiederum eigene Free-Tier- und Tarifangaben. Diese Werte sind nicht austauschbar — prüfen Sie die konkrete Produktseite, die Sie tatsächlich nutzen.
Am besten für: Enterprise-Teams, die eine Plattform für vorbereitete Datasets und Live-API-Zugriffe wollen und bereit sind, jede Oberfläche separat zu bepreisen.
6. Oxylabs — Die klarste Zweistufen-Kette für Suche plus Produktdetails
Oxylabs trennt Shopping in zwei dedizierte Ziele: google_shopping_search für Listing-Ergebnisse und google_shopping_product für detaillierte Produktdaten, verbunden über ein Produkt-Token. Die Suchantwort trennt sauber zwischen pla (bezahlte Listing Ads) und organic Produkten — vermutlich die klarste dokumentierte Sponsored-vs.-Organic-Aufteilung in der gesamten Liste — während der Produkt-Endpunkt pro Händler Angebote mit numerischem Preis, Zustand, Steuer, Gesamtpreis und Versand ergänzt.
Der Haken, und der ist real: Dieser Token-Workflow funktioniert nur, wenn die Suchanfrage sowohl render: "html" als auch parse: true verwendet. Lässt man einen der beiden Parameter weg, gibt es kein Produkt-Token, und der gesamte Produktdetail-Schritt bricht zusammen. Oxylabs weist außerdem ausdrücklich darauf hin, dass Such- und Produktanfragen identische Lokalisierungswerte verwenden müssen — weicht geo_location zwischen den beiden Aufrufen ab, können Produktdaten unvollständig oder falsch zurückkommen. Und wenn das Panel „More stores“ für zusätzliche Händlerangebote aufgeklappt werden soll, muss auch dafür Rendering aktiviert sein, was zusätzliche Kosten verursacht.
Ein Detail, das leicht übersehen wird: In der Preis-FAQ definiert Oxylabs „erfolgreiche“ und damit abrechenbare Requests als sowohl 2xx- als auch 4xx-Antworten. Wenn Ihr Request also fehlerhaft ist, kann er trotzdem berechnet werden.
Produktbewertungen sind laut Dokumentation nur für US-Locale verfügbar, und Locale/Sprache sowie Locale/Ergebnissprache sind tatsächlich getrennte Steuerungen — das eine setzt nicht automatisch das andere.
Am besten für: technische Teams, die sowohl Ranking-Daten als auch Händler-Offer-Details brauchen und Token-Verkettung sowie Locale-Konsistenz im Setup beherrschen können.
7. Scrapingdog — Einfacher Endpunkt, wenig öffentliche Detailtiefe
Scrapingdog bietet einen einzelnen, dedizierten Google-Shopping-Endpunkt, der einen API-Key und eine Suchanfrage entgegennimmt und JSON mit Titel, Preis und extrahiertem numerischem Preis, altem Preis, Bewertung, Reviews, Quelle/Händler, Lieferung und Position zurückgibt. Auf der Seite werden außerdem Filter nach Preis, Marke, Land und Sprache erwähnt sowie eine separate „ads“-Antwortkategorie zum Tracken bezahlter Platzierungen — allerdings sind das genaue Ads-Schema und die exakten Parameternamen für Locale-Filter auf der öffentlichen Seite nicht vollständig dokumentiert. Planen Sie also Zeit zum Testen ein, bevor Sie darauf Automatisierung aufbauen.
Das ist der einzige Eintrag in dieser Liste, bei dem die Credit-Kosten aus der öffentlichen Doku allein schlicht nicht sauber aufgehen: Die Preisseite zeigt monatliche Kreditkontingente (LITE mit 40 $/Monat für 200.000 Credits, STANDARD mit 90 $/Monat für 1.000.000), sagt aber nicht klar, wie viele Credits ein einzelner Google-Shopping-Request kostet. Gehen Sie nicht davon aus, dass das 1:1 mit den allgemeinen Search-API-Beispielen übereinstimmt — klären Sie die realen Kosten vorab direkt mit dem Anbieter.
Wie die meisten Anbieter hier bewirbt auch Scrapingdog integrierte rotierende Residential Proxies und automatisches CAPTCHA-Handling als vom Anbieter verwaltet. Verstehen Sie das als Aussage zur Wartungsgrenze, nicht als Garantie auf dauerhaften Zugriff.
Am besten für: kostenbewusste Entwickler, die einen schmalen, dedizierten Endpunkt wollen und die Credit-Kosten vorab direkt verifizieren möchten.
8. Apify — Bewerten Sie den Actor, nicht den Marktplatz
Ich muss hier etwas klarstellen: Apify ist kein einzelner Google-Shopping-Scraper, sondern ein Marktplatz unabhängig gepflegter „Actors“. Der Actor, den ich mir genauer angesehen habe (Google Shopping Insights, veröffentlicht vom Entwickler epctex und als „Maintained by Community“ markiert), verhält sich ganz anders als die oben genannten Anbieter-Tools. Apify liefert Laufzeitumgebung, Proxy-Infrastruktur und Dataset-/Export-Tools. Die eigentliche Logik zur Shopping-Extraktion — und auch die Wartung — liegt bei epctex, nicht bei Apify selbst.
Diese Unterscheidung ist wichtig, weil das offizielle Beispiel-Output dieses Actors ein null price field enthält. Nicht „manchmal“, nicht „bei nicht vorrätigen Artikeln“ — schon der dokumentierte Beispieldatensatz zeigt price: null und withoutDiscountPrice: null, obwohl Produktname, Händler und Bewertungsfelder gefüllt sind. Das ist wohl der klarste First-Party-Beleg in dieser gesamten Übersicht dafür, dass Preisdaten nicht als vollständig angenommen werden dürfen — direkt aus der eigenen Dokumentation des Tools.
Man bekommt konfigurierbare Eingaben — includeSponsoredResults, includeComparisonPrices für Preisvergleiche über Händler hinweg, Ländercode-Targeting, maxItemsPerQuery — sowie eine erforderliche Proxy-Konfiguration (eigene oder über Apify). Die Ergebnisse lassen sich über das Dataset-System von Apify als JSON, XML, CSV oder Excel exportieren. Der von mir geprüfte Store-Eintrag zeigte damals rund 2.300 Gesamt-Nutzer, aber nur 2 monatlich aktive Nutzer — ein Wert, den man beachten sollte, denn „community maintained“ wirkt in beide Richtungen: flexibel, aber nur so zuverlässig wie die Leute, die es aktiv nutzen und Probleme melden.
Am besten für: Entwickler, die die Wartungsaktivität eines bestimmten Actors und dessen echtes Output-Schema prüfen können, bevor sie sich festlegen — nicht für alle, die von Apify als Marke eine gleichbleibende Funktion erwarten.
9. Thunderbit — No-Code-Erfassung für Marketer
Thunderbit steht am anderen Ende dieser Liste: ein browserbasierter No-Code-Workflow für alle, die die sichtbare Seite in eine strukturierte Tabelle verwandeln möchten, statt eine Google-Shopping-API zu integrieren. Das passt natürlich zu Marketing-, PPC- und kleineren E-Commerce-Teams, die punktuelle Prüfungen durchführen, statt eine hochvolumige Backend-Pipeline zu betreiben.
Was Sie bekommen, ist browserseitige Extraktion: Öffnen Sie die Shopping-Ergebnisseite, die Sie wirklich brauchen, lassen Sie Thunderbit die gerenderte Seite mit einem Klick auslesen und exportieren Sie die Felder direkt nach Excel, Google Sheets, Airtable oder Notion. Es gibt eine echte Einschränkung — aber sie betrifft Shopping selbst und nicht nur ein einzelnes Tool: Da die Extraktion gegen die Seite läuft, die Sie gerade sehen, übernimmt das Ergebnis die Browser-Location, Sprache und Session. Fixieren Sie diese Einstellungen, bevor Sie den Abruf dieser Woche mit dem der letzten Woche vergleichen. Genau dieses Problem der Feldzuverlässigkeit behandelt auch der nächste Abschnitt, und es betrifft jede Option in dieser Liste.
Am besten für: nicht-technische Teams, die sichtbare, geprüfte Browser-Extraktion höher bewerten als eine von Entwicklern gepflegte JSON-Pipeline — und die konkrete Shopping-Seiten bei Bedarf abrufen statt einen großen Multi-Geo-Crawl zu fahren.
Welche Daten kann man wirklich trauen? Das Problem der Feldzuverlässigkeit
Das ist der Teil, den die meisten Google-Shopping-Vergleichsartikel komplett auslassen — und gleichzeitig der wichtigste Punkt, den man vor jeder Automatisierung verstehen muss: Nicht jedes Feld erscheint bei jedem Listing, und wenn man „fehlend“ einfach als „0“ behandelt, verdirbt man sich stillschweigend die Daten.
| Feld | Zuverlässigkeit | Der Haken |
|---|---|---|
| Titel | Hoch | Varianten/Bundles vor dem Produktabgleich über Quellen hinweg normalisieren |
| Produkt-ID | Bedingt | DataForSEO dokumentiert sie explizit als dynamisch und manchmal null |
| Preis | Bedingt | Im offiziellen Apify-Beispiel ist der Preis bei einem vollständig gefüllten Datensatz null |
| Händler/Merchant | Meist vorhanden | Multi-Seller-Listings bedeuten, dass ein Produkt mehrere separate Angebote haben kann |
| Bewertung/Anzahl der Reviews | Bedingt | Neue oder unbewertete Produkte lassen das Feld oft einfach weg — nicht auf Null zwingen |
| Versand/Lieferung | Inkonsistent | Kann von Zielort, Lagerbestand des Händlers und Session abhängen |
| Sponsored-Flag | Tool-abhängig | Oxylabs trennt pla sauber von organic; mehrere andere erlauben Sponsored ein-/auszuschließen, liefern aber kein verlässliches Label pro Zeile |
Die praktische Regel lautet: Bevor Sie irgendeinen Workflow automatisieren, ziehen Sie ein echtes Sample mit Ihren tatsächlichen Keywords und prüfen Sie, was wirklich null, doppelt oder fehlend ist — nicht das, was die Doku impliziert.
Offizielles Google Merchant Center vs. Google-Shopping-Scraper: Was brauchen Sie?
Das ist eine Frage, die E-Commerce-Teams schon stellen, bevor sie überhaupt Anbieter vergleichen — und sie verdient eine klare Antwort: Wenn Sie Ihre eigenen Produktlisten, Preise oder Shopping-Anzeigen verwalten, ist das ein Job für Googles offizielle Merchant-Center-Tools — nicht für einen Drittanbieter-Scraper. Die Tools in dieser Liste sind dafür da, die Listings anderer zu beobachten: Wettbewerberpreise, Marktpräsenz, Kategorierecherche, Monitoring bezahlter Platzierungen. Bitte nicht verwechseln. Prüfen Sie Googles aktuelle offizielle Dokumentation direkt, um den aktuellen Namen und den Umfang der First-Party-API zu sehen, denn solche Dinge werden regelmäßig umbenannt und umstrukturiert.
Wie diese Tools mit Googles Anti-Bot-Schutz umgehen
Ich formuliere das als Governance-Frage und nicht als „So umgeht man Google“-Tutorial, weil das die ehrliche Perspektive ist. Mehrere Anbieter hier — SerpApi, SearchAPI, Bright Data, Oxylabs, Scrapingdog — erklären öffentlich, dass sie Proxy-Rotation, Browser-Rendering und CAPTCHA-Handling auf ihrer Seite übernehmen. Das ist eine echte und wichtige Wartungsgrenze: Sie müssen nicht um 2 Uhr nachts eine gesperrte IP debuggen. Es ist aber keine Garantie für dauerhaften oder universellen Zugriff — und sollte auch nie so gelesen werden.
Was auch bei einem vollständig verwalteten Anbieter nicht verschwindet: Rate- und Budget-Kontrollen, Fehlerklassifizierung, Retries und Monitoring für Google-Änderungen (die, wenn man die Changelogs von SearchAPI und Oxylabs betrachtet, durchaus regelmäßig vorkommen). Bright Data dokumentiert partielle Batch-Fehler explizit; DataForSEO beschreibt das Verhalten bei Callback-Timeouts; Oxylabs dokumentiert ungültige Token-Fehler. Das ist keine Anleitung zum Umgehen von irgendetwas — nur eine ehrliche Aufstellung, wer welchen Fehlermodus verantwortet.
So wählen Sie den besten Google-Shopping-Scraper für Ihr Team aus
Arbeiten Sie diese Punkte der Reihe nach durch:
- Bestimmen Sie Ihre Rolle. Sind Sie Entwickler, der eine Pipeline baut, oder Marketing-/Ops-Person, die Ergebnisse ohne Code möchte?
- Definieren Sie die wirklich benötigten Felder. Ranking-Daten sind etwas anderes als Händler-/Offer-Preise — SearchAPI und Oxylabs verdienen ihren Platz genau für Letzteres.
- Seien Sie ehrlich bei Ihrer Wartungskapazität. API-Mapping und Error Handling, Actor-Konfiguration und Proxy-Setup oder browserbasierte Extraktion mit Review — wählen Sie das Modell, das Ihr Team langfristig realistisch tragen kann.
- Testen Sie Locale- und Geräteverhalten mit echten Suchanfragen, bevor Sie sich festlegen, denn öffentliche Dokumentation und Live-Verhalten stimmen nicht immer exakt überein.
- Prüfen Sie, ob Ihr Exportpfad zu Ihrem bestehenden Stack passt — ein JSON-Export ins Data Warehouse ist etwas völlig anderes als eine Tabelle, die ein Marketer direkt öffnen kann.
Fazit: Welchen Google-Shopping-Scraper sollten Sie verwenden?
Einen einzigen „besten“ gibt es hier nicht — und wenn ein Listicle etwas anderes behauptet, sollten Sie skeptisch sein. Wenn Sie als Entwickler eine Datenpipeline bauen und das reichhaltigste dokumentierte Schema mit klaren Cache- und Locale-Kontrollen wollen, starten Sie mit SerpApi. Wenn Ihr eigentliches Ziel Preisvergleiche auf Offer- bzw. Händler-Ebene sind, kommen Sie mit SearchAPI oder dem Token-Workflow von Oxylabs direkter ans Ziel. Wenn Sie große, geplante Recherchen fahren und eine Queue tolerieren, skaliert DataForSEO gut. Wenn Sie eine Enterprise-Plattform wollen, die sowohl vorbereitete Datasets als auch Live-Abfragen abdeckt, bietet Bright Data die größte Breite — allerdings sollten Sie jede Oberfläche separat bepreisen.
Und wenn Sie in einem PPC- oder Marketing-Team arbeiten und keinen API-Key anfassen möchten, ist die browserbasierte Kategorie, die Thunderbit repräsentiert, die direkte Antwort auf „Ich brauche nur die Daten, nicht noch ein Coding-Projekt“. Wichtig ist nur, welche Oberfläche Sie wählen: Der Browser-Workflow ist für Seiten gedacht, die Sie selbst öffnen und prüfen, während Thunderbits API-Dokumentation und CLI getrennte, entwicklerorientierte Wege sind. Wählen Sie das Modell, das zu Ihrer tatsächlichen Arbeitsweise passt.
Egal wofür Sie sich entscheiden: Ziehen Sie zuerst ein echtes Sample. Jeder Anbieter hier dokumentiert mindestens ein Feld, das nicht immer vorhanden ist — prüfen Sie das vorab, bevor Sie etwas darauf aufbauen.
FAQs
Ist es legal, Google-Shopping-Daten zu scrapen? Das ist keine Frage, die ich pauschal beantworten kann — und das sollte auch kein Listicle tun. Öffentlich sichtbare Daten und Compliance-Aussagen eines Anbieters machen nicht automatisch jeden Use Case legal. Prüfen Sie vor dem Aufbau die aktuellen Google-Nutzungsbedingungen, die für Ihre Jurisdiktion geltenden Gesetze und stellen Sie sicher, dass Ihre Erfassungsmethode autorisiert ist. Verstehen Sie das als „bitte mit eigener Rechtsberatung klären“, nicht als etwas, das ein Blogpost abschließend entscheidet.
Was ist der Unterschied zwischen einer SERP-API und einem Google-Shopping-Scraper? Eine SERP- oder Shopping-API nimmt strukturierte Request-Parameter entgegen und gibt geparstes JSON zurück — der Anbieter übernimmt den Großteil der Abruf-Infrastruktur. Ein browserbasierter Scraper (wie Thunderbit) extrahiert von einer Seite, die Sie oder ein Nutzer tatsächlich geöffnet hat. Dataset-Produkte (wie ein Teil des Bright-Data-Angebots) liefern vorab erfasste Datensätze nach Plan statt Live-Requests. Der Zweck überschneidet sich, aber Freshness, Locale-Kontrolle und der eigentliche Wartungsaufwand unterscheiden sich deutlich.
Brauche ich Programmierkenntnisse, um Google Shopping zu scrapen? Nicht unbedingt. Thunderbits gesamtes Konzept ist genau deshalb ein No-Code-Workflow per Klick. Apify kann technisch über die Weboberfläche laufen, ohne Code zu schreiben, auch wenn echte Anpassungen etwas technisches Verständnis begünstigen. Jedes API-basierte Tool in dieser Liste — SerpApi, Serper, SearchAPI, DataForSEO, Bright Data, Oxylabs, Scrapingdog — erfordert mindestens grundlegende Entwicklerkenntnisse: Authentifizierung, Parameterhandling und Fehlerprüfung.
Wie oft ändern sich Google-Shopping-Daten? Öfter, als viele annehmen — aber es gibt keine universelle Regel nach dem Motto „aktualisiert sich alle X Stunden“. Preise, Lagerbestand, bezahlte Platzierungen und Rankings können je nach Session, Locale und Tageszeit schwanken. Mehrere Anbieter hier bieten ausdrücklich Live-/Real-Time-Modi an, weil gecachte Daten in dieser Kategorie schnell veralten. Wenn Ihre Entscheidung von aktuellen Preisen abhängt, führen Sie die Abfrage neu aus, statt einem Ergebnis von gestern zu vertrauen.
Mehr erfahren
- Der vollständige Leitfaden zum Price Scraping
- Die 10 besten Amazon-Price-Scraper für die E-Commerce-Datenerfassung
- So scrapen Sie Google-Shopping-Daten — mit oder ohne Code
- Ist Web Scraping illegal? Die rechtlichen Auswirkungen verstehen
- Wie man Web Scraping in Python betreibt, ohne blockiert zu werden
