Vor ein paar Monaten stellte ein Entwickler auf Stack Overflow eine Frage, die seit 2012 offen ist: "Google Places API Place Details limited to 5 reviews?" Vierzehn Jahre, Hunderte Upvotes – und die Antwort ist immer noch dieselbe: Ja, maximal fünf Bewertungen. Genau diese eine Begrenzung zeigt schon ziemlich klar, warum diese Debatte überhaupt immer wieder aufkommt.
Wenn du schon einmal in größerem Stil Google-Places-Daten gebraucht hast – etwa für Lead-Listen, Wettbewerber-Bewertungen, Fußgängerfrequenzen oder lokale SEO-Audits – bist du wahrscheinlich an genau derselben Weggabelung gelandet. Die offizielle Google Places API ist sauber, strukturiert und gut dokumentiert. Aber sie liefert nicht alles, was du auf einer Google-Maps-Seite sehen kannst, und die Kosten können mit wachsendem Umfang schnell aus dem Ruder laufen, sobald du die Free-Tier-Grenze überschreitest. Scraping erfasst mehr, kostet anders und bringt eigene Baustellen mit sich (CAPTCHAs, kaputte Selektoren, rechtliche Grauzonen). Ich habe mich intensiv mit beiden Seiten beschäftigt – mit der API-Dokumentation, den Preisstufen, dem Scraping-Toolstack und den echten Kompromissen – und genau daraus ist dieser Artikel entstanden. Wir schauen uns die Datenlücken Feld für Feld an, die realen Kosten bei 10K/100K/1M Datensätzen, die Anti-Bot-Realität und einen praxisnahen Hybrid-Ansatz. Dazu gibt es ein Entscheidungs-Flowchart, weil niemand 3.000 Wörter lesen und am Ende trotzdem unsicher sein will.
Was ist die Google Places API – und was liefert sie tatsächlich?
Die Google Places API ist Googles offizielle, strukturierte Möglichkeit, Geschäftsdaten wie Namen, Adressen, Telefonnummern, Bewertungen, Rezensionen und Fotos aus ihrer Datenbank abzurufen. Du sendest eine HTTP-Anfrage, und du bekommst formatiertes JSON zurück. Das ist der freigegebene Weg.
Die aktuelle Version (Places API „New“) organisiert alles über Field Masks. Wenn du Place Details aufrufst, legst du exakt fest, welche Felder du willst – displayName, formattedAddress, rating, reviews, photos usw. – und Google berechnet dir den Preis anhand der höchsten Feldstufe, die du angefragt hast. Lässt du die Field Mask weg, bekommst du einen Fehler statt einer Standardantwort. Das ist Absicht: Google möchte, dass du nur für das bezahlst, was du wirklich nutzt (und für die interessanteren Felder eben mehr).
Die verfügbaren Felder sind in Preisstufen unterteilt:
| Stufe | Beispiel-Felder | Was du bekommst |
|---|---|---|
| Essentials | Place ID, formatierte Adresse, Standort, Foto-Metadaten | Grundlegende Identität und Standortdaten |
| Pro | Anzeigename, Geschäftsstatus, Google-Maps-URI, primärer Typ | Ausführlichere Geschäftsinformationen |
| Enterprise | Bewertung, Anzahl der Nutzerbewertungen, Website, Telefonnummern, Öffnungszeiten, Preisniveau | Die Felder, die die meisten Business-User wirklich brauchen |
| Enterprise + Atmosphere | Rezensionen, Review-Zusammenfassung, generative Zusammenfassung, Ausstattung, Parken, Takeaway/Lieferung | Die umfangreichsten (und teuersten) Daten |
Die wichtigsten Endpunkte sind für die meisten Nutzer: Autocomplete (für Suche während der Eingabe), Text Search und Nearby Search (zum Finden von Orten), Place Details (zum Anreichern eines bekannten Orts) und Place Photos (für Bilder).
Die entscheidenden Einschränkungen:
- Bewertungen/Rezensionen: Die Place-Ressource liefert pro Ort maximal 5 Rezensionen, sortiert nach Relevanz. Mehr nicht. Nicht 50, nicht „alle“. Fünf.
- Fotos: In der Place-Ressource sind pro Ort maximal 10 Foto-Referenzen enthalten.
- Beliebte Zeiten / Live-Auslastung: Nicht als Standardfeld in der Places API verfügbar. Google bestätigt, dass diese Daten existieren (auf Basis aggregierter, anonymisierter Standortverläufe), und ihr Maps-Blog erklärt die Funktionsweise – aber die Feldliste enthält sie nicht.
- Q&A-Bereich: Nicht exponiert.
- „Nutzer suchen auch nach“ / Wettbewerber: Nicht exponiert.
- Speisekarte / Preisübersicht: Kein Standardfeld.
Wer nutzt die Google Places API typischerweise?
- Logistikunternehmen, die Adressen validieren und geokodieren
- Reise- und Hospitality-Apps, die Hotels, Restaurants und Sehenswürdigkeiten in der Nähe anzeigen
- Immobilienplattformen, die Objektanzeigen mit lokalen Geschäftsdaten anreichern
- Lokale SEO-Agenturen, die NAP-Konsistenz (Name, Adresse, Telefonnummer) prüfen
- Sales-Teams, die aus Place IDs und Basisinformationen Lead-Listen bauen
Wenn dein Anwendungsfall sauber in „Ich brauche strukturierte Ortsdaten in einer produktiven App“ passt, ist die API der richtige Startpunkt. Wenn deine Anforderungen Wörter wie „alle Bewertungen“, „beliebte Zeiten“ oder „Wettbewerberanalyse“ enthalten, lies weiter.
Was bedeutet „Scraping“ von Google-Places-Daten?
Web Scraping bedeutet, mit Software automatisch Daten von einer Webseite auszulesen – in diesem Fall von Google Maps oder Google-Suchergebnissen – statt über eine offizielle API. Der Scraper liest die Seite so, wie es dein Browser tut, und zieht dann die strukturierten Elemente heraus: Firmennamen, Adressen, Rezensionstexte, Sternebewertungen, Diagramme zu beliebten Zeiten, Q&A, Wettbewerber-Vorschläge, die komplette Fotogalerie und alles andere, was auf dem Bildschirm gerendert wird.
Der zentrale Unterschied: Die API liefert, was Google freigibt. Scraping liefert dir – zumindest theoretisch – alles, was ein Mensch auf der Seite sehen kann.
„Scraping“ ist dabei aber nicht gleich Scraping. Es gibt drei sehr unterschiedliche Ansätze, und die Unterschiede bei Aufwand und Risiko sind erheblich.
DIY-Skripte vs. verwaltete Scraping-APIs vs. No-Code-Tools
| Ansatz | Funktionsweise | Am besten geeignet für | Hauptnachteil |
|---|---|---|---|
| DIY-Skripte (Puppeteer, Playwright, Selenium) | Du schreibst und pflegst ein Headless-Browser-Skript, das Google-Maps-Seiten aufruft und das DOM ausliest | Entwickler, die volle Kontrolle und eigene Logik brauchen | Höchster Wartungsaufwand – Selektoren brechen, wenn Google die UI ändert |
| Verwaltete Scraping-APIs (Thunderbit API, SerpApi, Outscraper) | Du sendest eine URL oder Suchanfrage an eine API; sie übernimmt Rendering, Anti-Bot und Parsing und gibt strukturierte Daten zurück | Entwickler, die strukturierte Ergebnisse ohne eigene Scraper-Wartung wollen | Preis und Qualität variieren; du vertraust einem Drittanbieter |
| No-Code-Browser-Erweiterungen (Thunderbit Chrome Extension) | Extraktion per Klick direkt im Browser – KI schlägt Felder vor, du klickst auf „Scrape“, Export nach Sheets/Excel | Business-User, Marketer, Sales-Teams, die schnell Daten in einer Tabelle brauchen | Weniger flexibel für komplexe Pipelines; hängt von der KI-Qualität des Tools ab |
Kurz gesagt: DIY = am flexibelsten, aber am wartungsintensivsten. Verwaltete APIs = strukturierte Ergebnisse ohne Pflegeaufwand. No-Code-Tools = am schnellsten für Nicht-Entwickler.
Google Places API vs. Scraping: Feld-für-Feld-Datenvergleich
Diese Tabelle hätte ich mir gewünscht, als ich mit der Recherche angefangen habe. Jedes Feld, das für Business-User oder Entwickler relevant sein könnte, direkt nebeneinander:
| Datenfeld | Google Places API | Web Scraping |
|---|---|---|
| Firmenname | ✅ Vollständig (Pro-Tier) | ✅ Vollständig |
| Adresse / Standort | ✅ Vollständig (Essentials-Tier) | ✅ Vollständig |
| Telefonnummer | ✅ Enterprise-Tier | ✅ Wenn sichtbar |
| Website-URL | ✅ Enterprise-Tier | ✅ Wenn sichtbar |
| Gesamtbewertung | ✅ Enterprise-Tier | ✅ Vollständig |
| Anzahl der Nutzerbewertungen | ✅ Enterprise-Tier | ✅ Vollständig |
| Einzelne Rezensionen (Text + Bewertung) | ⚠️ Max. 5 Rezensionen | ✅ Alle verfügbaren Rezensionen |
| Beliebte Zeiten / Live-Auslastung | ❌ Kein Standard-API-Feld | ✅ Extrahierbar (wenn gerendert) |
| Q&A-Bereich | ❌ Nicht exponiert | ✅ Extrahierbar |
| Foto-Metadaten | ✅ Über den Fotos-Endpunkt max. 10 Referenzen | ✅ Komplette Galerie |
| Speisekarte / Preisübersicht | ❌ Kein Standardfeld | ⚠️ Wenn auf der Seite vorhanden |
| „Nutzer suchen auch nach“ (Wettbewerber) | ❌ Nicht exponiert | ✅ Extrahierbar |
| Öffnungszeiten | ✅ Enterprise-Tier | ✅ Wenn sichtbar |
| Preisniveau | ✅ Enterprise-Tier | ✅ Wenn sichtbar |
| Place ID | ✅ Sehr zuverlässig (Essentials) | ⚠️ Möglich, aber die API ist die kanonische Quelle |
| Google-Maps-URI | ✅ Pro-Tier | ✅ Das ist die Seiten-URL |
| Antworten des Inhabers auf Rezensionen | ⚠️ Aktuelle Verfügbarkeit prüfen | ✅ Oft sichtbar |
| SERP-/Map-Pack-Position | ❌ Nicht Zweck der API | ✅ Über SERP-Scraping |
Die wichtigste Lücke: Wenn du vollständige Review-Sets für Sentiment-Analysen, Reputations-Monitoring oder Wettbewerbs-Benchmarks brauchst, reicht die API allein nicht aus. Fünf Rezensionen pro Ort sind eine Stichprobe, kein Datensatz.
Beliebte Zeiten und Fußgängerfrequenz? Dasselbe Bild. Wenn du Retail-Berater oder Analyst für Gewerbeimmobilien bist, führt am Scraping kein Weg vorbei – diese Daten sind schlicht nicht in der API enthalten.
Auf der anderen Seite sind für kanonische Place IDs, strukturierte Adressen für Geokodierung oder einen Store Locator die API-Daten sauberer, zuverlässiger und offiziell unterstützt.
Die echten Kosten: Google Places API vs. Scraping bei 10K, 100K und 1M Datensätzen
Kosten sind der am häufigsten missverstandene Teil dieser Entscheidung. Viele Nutzer starten mit dem Free-Tier der API, bauen einen Prototypen und bekommen später eine Rechnung, die sie überrascht, sobald sie skalieren. Beim Scraping unterschätzen viele die Proxy-Kosten und die Entwicklerzeit.
Hier also die Rechnung.
Aufschlüsselung der Google-Places-API-Preise
Google hat die Preisstruktur der Maps Platform im März 2025 überarbeitet und den alten pauschalen $200-Monatsgutschein durch kostenlose Nutzungsgrenzen auf SKU-Ebene und volumenbasierte Staffelungen ersetzt. Die aktuellen Preise funktionieren so:
- Essentials-Felder (Place Details): 10.000 kostenlose Anfragen/Monat, danach 5,00 $ pro 1.000 bis 100K
- Pro-Felder (Place Details): 5.000 kostenlos, danach 7,00 $/1K
- Enterprise-Felder (Place Details): 1.000 kostenlos, danach 20,00 $/1K
- Enterprise + Atmosphere (Rezensionen, Ausstattung): 1.000 kostenlos, danach 25,00 $/1K
Wichtiger Punkt: Wenn deine Field Mask auch nur ein einziges Enterprise+-Atmosphere-Feld enthält (z. B. reviews), wird die gesamte Anfrage in dieser Stufe abgerechnet. Und ein typischer Workflow nutzt oft mehrere SKUs hintereinander – etwa Text Search Pro, um Orte zu finden, und anschließend Place Details Enterprise + Atmosphere, um sie anzureichern – sodass sich die Kosten addieren.
Ein einzelnes „Lookup“ ist selten nur eine einzige abrechenbare Anfrage.
Scraping-Kosten: Tools, Proxies und Entwicklerzeit
Die Kosten beim Scraping lassen sich in drei Blöcke aufteilen:
- Tool-Abonnement oder API-Credits: Verwaltete Scraping-APIs berechnen pro Anfrage, pro Credit oder pro Datensatz. SerpApi verlangt Gebühren pro Suche. Outscraper arbeitet mit Pay-as-you-go pro Datensatz. Die Thunderbit API nutzt ein Credit-System (Extract = 20 Credits/Anfrage). Die Thunderbit Chrome Extension berechnet 1 Credit pro Ausgabereihe.
- Proxy-Kosten (nur DIY): Residential Proxies für Google-Maps-Scraping liegen typischerweise bei 50–300 $/Monat, je nach Volumen und Anbieter.
- Entwicklerzeit (nur DIY): Das Erstellen und Warten von Puppeteer-/Playwright-Skripten. Das ist der versteckte Kostenblock, der die DIY-Ökonomie oft kippen lässt (dazu gleich mehr).
Kostenvergleich auf einen Blick: API vs. Scraping in großem Maßstab
| Umfang | Google Places API (Enterprise + Atmosphere) | Verwaltete Scraping-API (ca.) | DIY-Scraping (Proxy + Entwicklerzeit) |
|---|---|---|---|
| 10K Datensätze/Monat | ca. 225 $ (1K frei, 9K × 25 $/1K) | ca. 50–150 $ je nach Anbieter | ca. 50 $ Proxy + 2–4 Std. Entwicklung/Monat |
| 100K Datensätze/Monat | ca. 2.475 $ (nach Free Cap greifen Volumenstaffeln) | ca. 250–500 $ | ca. 150 $ Proxy + 8–16 Std. Entwicklung/Monat |
| 1M Datensätze/Monat | ca. 17.975 $ (Volumenstaffeln senken den Stückpreis, aber die Gesamtkosten bleiben hoch) | ca. 1.500–3.000 $ | ca. 300 $ Proxy + 20+ Std. Entwicklung/Monat + Bruchrisiko |
Hinweis: Die API-Schätzungen basieren auf den veröffentlichten Volumenstufen für Place Details Enterprise + Atmosphere, angewendet nach dem 1K-Free-Cap. Die Schätzungen für verwaltete Scraping-APIs sind grobe Spannweiten über mehrere Anbieter hinweg. Die Entwicklerzeit beim DIY-Ansatz setzt 50–100 $/Std. Gesamtkosten an.
Das Muster ist klar: Im Hobby- oder Kleinstmaßstab (unter 10K) können die Free Caps der API sie zur günstigsten Option machen, vor allem wenn du nur Essentials- oder Pro-Felder brauchst. Auf Business-Ebene (100K+) steigen die API-Kosten deutlich, besonders bei umfangreichen Feldern. Im Enterprise-Maßstab (1M+) kann die API monatlich in den fünfstelligen Bereich rutschen, und Scraping oder Datendienstleister werden wirtschaftlich sehr attraktiv – vorausgesetzt, du brauchst wirklich die zusätzlichen Felder, die die API nicht anbietet.
Wenn du nur Adressen und Place IDs brauchst, dann scrappe nicht. Dafür ist die API günstiger und besser. Das Kostenargument für Scraping gilt nur dann, wenn du Daten benötigst, die die API nicht liefern kann.
Der Anti-Bot-Realitätscheck: Warum DIY-Google-Scraper kaputtgehen
Hier ist der Teil, den Scraping-Evangelisten gerne auslassen. Google möchte nicht, dass du Google Maps scrapest. Sie haben mehrere Schutzebenen eingebaut und aktualisieren sie regelmäßig.
Googles mehrstufige Schutzmechanismen
- reCAPTCHA-Herausforderungen: Automatisierte Browser lösen CAPTCHAs deutlich häufiger aus als menschliche Nutzer
- Clientseitiges JavaScript-Rendering: Google Maps ist eine schwere JavaScript-Anwendung. Eine einfache HTTP-Anfrage reicht nicht für gerenderte Inhalte – du brauchst einen vollständigen Headless Browser
- Browser-Fingerprinting: Google erkennt Headless Browser über Canvas-Fingerprints, WebGL, Navigator-Eigenschaften und weitere Signale
- IP-Rate-Limiting: Zu viele Anfragen von derselben IP (oder demselben Proxy-Subnetz), und du wirst blockiert
- Änderungen an der DOM-Struktur: Google verändert regelmäßig den Aufbau seiner Seiten – der Konsens in Reddit-Threads und GitHub-Issues ist, dass Selektoren alle paar Wochen bis Monate kaputtgehen
Dieser letzte Punkt ist der stille Killer. Ein Puppeteer-Skript, das im Juni perfekt lief, kann im Juli plötzlich leere Ergebnisse liefern, weil Google eine CSS-Klasse umbenannt oder ein div umstrukturiert hat.
Die versteckten Wartungskosten von DIY-Skripten
Jedes Mal, wenn Google sein DOM ändert, muss jemand in deinem Team:
- merken, dass der Scraper kaputt ist (hoffentlich bevor falsche Daten weiterverarbeitet werden)
- die neue Seitenstruktur untersuchen
- Selektoren aktualisieren, neue CAPTCHA-Typen abfangen, Retry-Logik anpassen
- testen und neu ausrollen
Über ein Jahr hinweg kann dieser Wartungsaufwand die Abokosten einer verwalteten Scraping-API locker übersteigen. Ich habe Teams gesehen, die jährlich 40+ Entwicklerstunden nur dafür aufwenden, einen Google-Maps-Scraper am Leben zu halten – und das ist noch eine eher konservative Schätzung für ein mittelkomplexes Setup.
Warum verwaltete Scraping-APIs existieren
Genau wegen dieses Wartungsaufwands gibt es Services wie Thunderbit API, SerpApi und Outscraper. Sie übernehmen die Anti-Bot-Komplexität – JavaScript-Rendering, CAPTCHA-Lösung, Proxy-Rotation, Selector-Pflege – und liefern strukturierte Daten zurück.
Der POST /extract-Endpunkt von Thunderbit mit renderMode: "full" verarbeitet JavaScript-lastige Seiten wie Google Maps und gibt schema-passendes, strukturiertes JSON zurück, nicht bloß rohes HTML, das erst noch geparst werden muss. Der MCP-Server erweitert das auf KI-Agenten – Claude, Cursor oder andere LLM-basierte Workflows können Google-Maps-Daten mitten im Task auslesen, ohne ihre Umgebung zu verlassen.
Für nicht-technische Nutzer ist die Thunderbit Chrome Extension die Variante ohne Wartungsaufwand: Google-Maps-Seite öffnen, auf „AI Suggest Fields“ klicken, auf „Scrape“ klicken, in Sheets exportieren. Keine Selektoren, keine Proxies, kein Debugging.
SerpApi und Outscraper sind solide Alternativen mit unterschiedlichen Preismodellen und Ausgabeformaten. SerpApi liefert strukturiertes JSON pro Suche; Outscraper rechnet pro Datensatz im Pay-as-you-go-Modell ab. Die richtige Wahl hängt von deinem Volumen, Budget und davon ab, ob du strukturiertes JSON brauchst oder mit halbstrukturierten Ausgaben gut zurechtkommst.
Der Hybrid-Ansatz: Google Places API und Scraping zusammen nutzen
Keiner der Top-Artikel zu diesem Thema empfiehlt das, was in der Praxis meiner Erfahrung nach am besten funktioniert: beides zu nutzen. Viele Teams verlassen sich bei manchen Aufgaben auf die offizielle API und bei anderen auf Scraping. Der Trick ist, jedes Werkzeug der passenden Aufgabe zuzuordnen.
Wann die offizielle API gewinnt
- Autocomplete in einer Live-Produktiv-App: geringe Latenz, ToS-konform, zuverlässiges SLA. Keine Frage.
- Standortbasierte App-Backends: Store Locator, Adressvalidierung, Place-ID-Abgleich. Die API ist strukturiert, unterstützt und dokumentiert.
- Integrationen mit hohem Compliance-Bedarf: Enterprise-Verträge, öffentliche Produkte oder jeder Kontext, in dem die Einhaltung der Google-ToS nicht verhandelbar ist.
Wann Scraping gewinnt
- Vollständige Review-Extraktion (5K+ Bewertungen pro Ort): Sentiment-Analyse, Reputations-Monitoring, Wettbewerbs-Benchmarking. Das 5-Review-Limit der API macht sie hier unbrauchbar.
- Einmalige Lead-Listen-Extraktion: Günstiger für Batch-Jobs ohne laufende Abrechnung. Ein No-Code-Tool wie Thunderbit kann in wenigen Minuten eine Liste von Unternehmen auslesen und als Tabelle exportieren.
- Analyse beliebter Zeiten / Fußgängerfrequenz: Nicht per API verfügbar. Punkt.
- Q&A-Daten, „Nutzer suchen auch nach“ für Wettbewerber: Nur auf der Seite sichtbar, nicht in der API.
Wann ein Hybrid-Ansatz sinnvoll ist
- Laufendes Preis-/Bewertungsmonitoring: Nutze die API für die grundlegenden strukturierten Daten (Place ID, Adresse, Gesamtbewertung) und scrappe dann die tiefen Felder, die der API fehlen (vollständige Rezensionen, beliebte Zeiten).
- Enrichment-Workflows: Nutze die API, um Place IDs und kanonische Geschäftsdaten zu erhalten, und scrappe anschließend einzelne Eintragsseiten für komplette Review-Sets, Q&A und Wettbewerber-Kontext.
- Geplantes Monitoring: Der geplante Scraper von Thunderbit (für No-Code-Nutzer) oder ein CLI-Batch-Extract mit Cron (für Entwickler) kann wiederkehrendes Scraping ohne eigene Infrastruktur übernehmen.
Entscheidungsmatrix nach Anwendungsfall
| Anwendungsfall | Empfohlene Methode | Warum |
|---|---|---|
| Autocomplete in einer Live-App | ✅ Offizielle API | Geringe Latenz, ToS-konform, zuverlässig |
| 5K+ vollständige Review-Sets abrufen | ✅ Scraping / Scraping-API | API begrenzt auf 5 Rezensionen pro Ort |
| Einmalige Lead-Liste lokaler Unternehmen | ✅ Scraping (oder Thunderbit-Erweiterung) | Günstiger für Batch; keine laufenden Gebühren |
| Analyse beliebter Zeiten / Fußgängerfrequenz | ✅ Nur Scraping | Nicht über die API verfügbar |
| Laufendes Preis-/Bewertungsmonitoring | ⚠️ Hybrid | API für Basisdaten, Scraping für tiefe Felder |
| Standortbasiertes App-Backend | ✅ Offizielle API | Strukturiert, unterstützt, SLA |
| SERP-Ranking-Tracking für lokales SEO | ✅ Scraping / SERP-API | Nicht der Zweck der Places API |
| „Nutzer suchen auch nach“-Wettbewerberdaten | ✅ Nur Scraping | Nicht über die API exponiert |
Entscheidungs-Flowchart: Google Places API vs. Scraping – was solltest du wählen?
Statt eines vagen „kommt drauf an“ hier ein konkretes Entscheidungsmodell. Geh diese vier Fragen durch:
1. Brauchst du Echtzeitdaten in einer Produktions-App? → Ja: Nutze die offizielle API. Sie wird unterstützt, hat ein SLA und ist ToS-konform. Hier aufhören. → Nein: Weiter.
2. Brauchst du Daten, die die API nicht liefert (vollständige Rezensionen, beliebte Zeiten, Q&A)? → Ja: Scraping ist erforderlich. Diese Daten kann die API schlicht nicht liefern. → Nein: Weiter.
3. Wie viele Datensätze pro Monat? → Unter 10K: Die API ist wahrscheinlich am günstigsten, besonders wenn du nur Essentials- oder Pro-Felder brauchst. Die Free Caps decken bei diesem Umfang schon sehr viel ab. → Über 10K: Scraping oder eine verwaltete Scraping-API ist wahrscheinlich wirtschaftlicher, vor allem bei umfangreichen Feldern.
4. Hast du Entwicklerressourcen, um Scraper zu bauen und zu pflegen? → Ja: DIY mit Puppeteer/Playwright gibt dir maximale Kontrolle (aber plane laufende Wartung ein). → Nein: Nutze eine verwaltete Scraping-API (Thunderbit API, SerpApi, Outscraper) oder ein No-Code-Tool (Thunderbit Chrome Extension).
Schneller Vergleich entwicklerorientierter Alternativen
| Tool | Preismodell | Ausgabeformat | Anti-Bot-handling | Batch-Support |
|---|---|---|---|---|
| Thunderbit API / MCP | Credit-basiert (Extract = 20 Credits/Anfrage) | Schema-passendes strukturiertes JSON | ✅ JavaScript-Rendering, Proxy-Rotation, Geo-Routing | ✅ Bis zu 100 URLs pro Batch |
| SerpApi | Pro Suche (gestaffelte Pläne) | Strukturiertes JSON | ✅ | ✅ Über API-Parameter |
| Outscraper | Pro Datensatz (Pay-as-you-go) | JSON / CSV | ✅ | ✅ Über Task-Queues |
| DIY (Puppeteer/Playwright) | Proxy + Entwicklerzeit | Rohes HTML (du parsest es selbst) | ❌ Du musst alles selbst lösen | ✅ Was immer du selbst baust |
Der entscheidende Vorteil der Thunderbit API: Sie liefert schema-passendes, strukturiertes JSON auf Basis eines von dir definierten JSON-Schemas – nicht rohes HTML oder Markdown, das erst noch aufbereitet werden muss. Wenn du in eine LLM-Pipeline einspeist oder eine Datenbank befüllst, sparst du damit echte Post-Processing-Zeit.
Wie Thunderbit ins Bild passt (für Business-User und Entwickler)
Wir haben Thunderbit gebaut, um die Lücke zwischen „Ich brauche Google-Maps-Daten“ und „Ich will nicht zum Scraping-Infrastruktur-Engineer werden“ zu schließen. So funktioniert es für beide Zielgruppen.
Für nicht-technische Nutzer: Die Chrome Extension
- Google-Maps-Seite öffnen – eine Suchergebnisseite oder einen einzelnen Unternehmenseintrag
- „AI Suggest Fields“ anklicken – Thunderbits KI liest die Seite und schlägt Spalten vor (Firmenname, Adresse, Bewertung, Rezensionen, Telefonnummer usw.)
- „Scrape“ anklicken – die Extension extrahiert die Daten in eine strukturierte Tabelle. Nutze den Cloud-Modus für bis zu 50 Seiten gleichzeitig
- Unterseiten scrapen – mit „Scrape Subpages“ jeden Eintrag öffnen und vollständige Details abrufen
- Exportieren – nach Excel, Google Sheets, Airtable oder Notion. Kostenloser Datenexport, keine Paywall
Für wiederkehrendes Monitoring – wöchentliche Wettbewerber-Bewertungen, neue Unternehmenseinträge – läuft der geplante Scraper automatisch in dem von dir festgelegten Rhythmus.
Für Entwickler: API, MCP-Server und CLI
POST /extractmit JSON-Schema: Google-Maps-URL senden, gewünschte Felder definieren, strukturiertes JSON zurückbekommen. Für JavaScript-lastige SeitenrenderMode: "full"setzen. Thunderbit übernimmt Rendering, Anti-Bot, Proxy-Rotation und Geo-Routing.POST /distill: Sauberes Markdown von jeder Seite erhalten – nützlich für LLM-Pipelines, die Rohinhalte statt strukturierter Felder brauchen. 1 Credit/Anfrage statt 20 für Extract.- MCP-Server: KI-Agenten (Claude, Cursor) können Google-Maps-Daten mitten im Workflow scrapen. Unterstützt Distillation, strukturierte Extraktion, Feldvorschläge und Batch-Jobs mit bis zu 100 URLs.
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsonfür geplantes oder in CI/CD eingebundenes Scraping.
Credit-Preisgestaltung: Extract = 20 Credits/Anfrage, Distill = 1 Credit/Anfrage. API-Credits gelten pro Anfrage, nicht pro Zeile (im Gegensatz zur Extension, wo 1 Credit = 1 Ausgabereihe). Die aktuellen Pläne findest du unter Thunderbit Pricing.
Rechtliche und Terms-of-Service-Aspekte
Ich halte es kurz und sachlich – ohne Panikmache, ohne Verkaufs-Pitch.
Die Google Places API hat klare Bedingungen: Laut Googles produktspezifischen Nutzungsbedingungen dürfen Inhalte der Places API ohne Google Map verwendet werden, aber nicht zusammen mit einer nicht von Google stammenden Karte. Breiten-/Längengrade dürfen bis zu 30 aufeinanderfolgende Kalendertage gecacht werden; Place IDs dürfen unbegrenzt gespeichert werden. Für Details, Fotos und Rezensionen ist eine Attribution erforderlich.
Das Scrapen von Google Maps kann gegen Googles Nutzungsbedingungen verstoßen. Die Durchsetzung variiert – mögliche Risiken reichen von IP-Blocks über CAPTCHA-Sperren bis hin zu (seltenen) rechtlichen Schritten. Verwaltete Scraping-APIs übernehmen in der Regel einen Teil des Compliance-Risikos für die Nutzer, sind aber kein rechtlicher Schutzschild.
Für Produktions-Apps mit Endnutzern ist die offizielle API die sicherere Wahl. Für interne Recherche, Batch-Analysen und Competitive Intelligence ist Scraping gängige Praxis. Für kommerzielle Workflows solltest du eigene Rechtsberatung einholen.
Was ich tatsächlich wählen würde – und warum
Nach dem Durcharbeiten von Preisstufen, Feldlisten, Community-Threads und Tool-Dokumentation lande ich hier:
- Nutze die offizielle API, wenn du Echtzeitdaten, ToS-konforme Daten in einer Produktions-App brauchst oder wenn Essentials-/Pro-Felder ausreichen und dein Volumen unter 10K/Monat liegt. Die Free Caps sind bei kleinen Volumina großzügig, und die Datenqualität ist tadellos.
- Nutze Scraping (verwaltete API oder No-Code-Tool), wenn du vollständige Bewertungen, beliebte Zeiten, Q&A, Wettbewerber-Kontext oder irgendein Feld brauchst, das die API nicht ausspielt. Ebenso, wenn dein Volumen 10K–100K Datensätze/Monat übersteigt und du umfangreiche (Enterprise + Atmosphere) Felder anfragst – dann lässt sich die API-Rechnung schwer rechtfertigen.
- Nutze beides, wenn dein Workflow kanonische Place IDs und grundlegende strukturierte Daten (API) plus tiefere Informationen von der sichtbaren Seite (Scraping) verlangt. Das ist in der Praxis häufiger, als viele Artikel zugeben.
Der Kosten-Kipppunkt: Unter etwa 10K Datensätzen/Monat mit Basisfeldern ist die API einfacher und oft kostenlos. Darüber, besonders bei umfangreichen Daten, wird Scraping wirtschaftlicher. Bei 1M Datensätzen mit Enterprise+-Atmosphere-Feldern liegst du bei der API bei rund 18K $/Monat – mit einem verwalteten Scraper nur bei einem Bruchteil davon.
Wenn du das selbst testen willst, ist die Thunderbit Chrome Extension der schnellste Weg, um zu sehen, was Scraping im Vergleich zur API erfasst. Für Entwickler-Workflows findest du in den Thunderbit API-Dokumenten alles, was du für den Einstieg brauchst. Und wenn du tiefer in Web Scraping ohne Programmierung oder AI Web Scraping allgemein einsteigen möchtest, haben wir dazu im Blog bereits ausführlich geschrieben.
Die wichtigsten Erkenntnisse
- Die Google Places API ist das richtige Werkzeug für Produktions-Apps, Autocomplete und strukturierte Ortsabfragen – aber sie begrenzt Rezensionen auf 5, Fotos auf 10 und gibt beliebte Zeiten, Q&A oder Wettbewerber-Vorschläge nicht frei.
- Scraping erfasst alles, was auf einer Google-Maps-Seite sichtbar ist, einschließlich vollständiger Review-Sets und Popular-Times-Daten, erfordert aber das Management von Anti-Bot-Schutz oder den Einsatz eines verwalteten Dienstes.
- Unter 10K Datensätzen/Monat machen die Free Caps der API sie oft zur günstigsten Option. Ab 100K ist Scraping oder eine verwaltete Scraping-API für umfangreiche Daten meist wirtschaftlicher.
- DIY-Scraper gehen wegen Googles Anti-Bot-Schutz und DOM-Änderungen regelmäßig kaputt – plane über 40 Entwicklerstunden pro Jahr für Wartung ein oder nutze ein verwaltetes Tool.
- In der Praxis ist der beste Weg oft hybrid: API für kanonische IDs und Basisfelder, Scraping für die tieferen Insights, die die API nicht liefern kann.
- Thunderbit bedient beide Seiten: eine Chrome Extension für No-Code-Nutzer und eine strukturierte JSON-API/MCP-Server-Lösung für Entwickler.
FAQs
Kann man über die Places API mehr als 5 Google-Bewertungen abrufen?
Nein. Die Google Places API begrenzt die Rückgabe von Rezensionen auf 5 pro Ort, sortiert nach Relevanz. Das ist seit dem Start der API so und hat sich trotz jahrelanger Entwicklerwünsche nicht geändert. Wenn du alle verfügbaren Rezensionen eines Unternehmens brauchst, bleibt nur Scraping – entweder selbst gebaut oder über eine verwaltete Scraping-API.
Ist das Scrapen von Google Maps legal?
Es gibt keine pauschale Ja-oder-Nein-Antwort. Das Scrapen öffentlich sichtbarer Google-Maps-Daten kann gegen Googles Nutzungsbedingungen verstoßen; die Durchsetzung reicht von IP-Blocks bis hin zu seltenen rechtlichen Schritten. Viele Unternehmen nutzen Scraping für interne Recherche und Competitive Intelligence ohne Probleme. Verwaltete Scraping-APIs senken das Compliance-Risiko etwas, sind aber kein rechtlicher Schutz. Wenn du ein kommerzielles Produkt baust oder personenbezogene Daten verarbeitest, sprich mit einer Rechtsberatung.
Was kostet die Google Places API für 100K Lookups?
Das hängt davon ab, welche Felder du anfragst. Für Place Details im Essentials-Tier etwa 450 $. Im Pro-Tier etwa 1.615 $. Bei Enterprise + Atmosphere (inklusive Rezensionen und Ausstattung) etwa 2.475 $. Wenn dein Workflow zusätzlich Text Search Pro für die Suche benötigt, kommen noch einmal rund 3.040 $ dazu. Diese Schätzungen basieren auf Googles veröffentlichten Volumenstufen und gehen von einer abrechenbaren Anfrage pro Datensatz nach dem Free Cap aus.
Was ist der Unterschied zwischen einer Scraping-API und einem No-Code-Scraping-Tool?
Eine Scraping-API (wie Thunderbits Open API) richtet sich an Entwickler, die Scraping per HTTP-Anfrage in Code, Automatisierungs-Pipelines oder KI-Agenten-Workflows integrieren. Ein No-Code-Tool (wie die Thunderbit Chrome Extension) ermöglicht es nicht-technischen Nutzern, Daten direkt im Browser per Klick auszulesen und zu exportieren – ganz ohne Code. Beide können strukturierte Daten liefern; der Unterschied liegt in Oberfläche und Integrationsmodell.
Funktioniert Thunderbit auf Google-Maps-Seiten?
Ja. Die Chrome Extension kann Google-Maps-Suchergebnisse und einzelne Unternehmenseinträge scrapen – die KI schlägt Felder automatisch vor, und du kannst im Cloud-Modus bis zu 50 Seiten gleichzeitig verarbeiten. Der POST /extract-Endpunkt der API mit renderMode: "full" verarbeitet die per JavaScript gerenderten Google-Maps-Seiten und gibt schema-passendes, strukturiertes JSON zurück. Der MCP-Server ermöglicht es KI-Agenten, Google-Maps-Daten mitten im Workflow zu scrapen.
Mehr erfahren
