Google Places API Nutzungsbedingungen: Speichern + Cachen

Google formuliert das Scraping-Verbot unmissverständlich: Die Google Maps Platform Nutzungsbedingungen legen fest, dass Kunden Google-Maps-Inhalte nicht "exportieren, extrahieren oder anderweitig scrapen" dürfen - wobei die Bedingungen im Original von "export, extract, or otherwise scrape Google Maps Content for use outside the Services" sprechen. Caching ist untersagt, ausser die Service Specific Terms erlauben es ausdrücklich. Zwei praktische Ausnahmen sollten Sie kennen: Place-IDs dürfen unbegrenzt gespeichert werden, und Places-Koordinaten dürfen bis zu 30 aufeinanderfolgende Kalendertage zwischengespeichert werden. Alles andere - Namen, Bewertungen, Rezensionen, Fotos, Telefonnummern - ist für den Live-Abruf mit Google-Maps-Attribution gedacht, nicht für die eigene Datenbank.

Dieser Guide geht die offiziellen Bedingungen und Richtlinien Abschnitt für Abschnitt durch, mit Links zu Googles eigenen Dokumenten, damit Sie jede Aussage selbst prüfen können. Er richtet sich an Entwickler, die zwischen der offiziellen Places API, einem Google Maps Scraper und einer lizenzierten Firmendaten-API abwägen - drei Wege mit sehr unterschiedlicher Vertragslage. Er ist keine Rechtsberatung; lesen Sie immer die aktuellen Dokumente selbst, denn Google aktualisiert sie.

Die Regeln auf einen Blick

Geprüft gegen Googles offizielle Maps Platform Bedingungen, Service Specific Terms und Places-API-Richtlinien im Juli 2026. Google überarbeitet diese Dokumente; prüfen Sie den aktuellen Text, bevor Sie bauen.

Die No-Scraping-Klausel, verständlich erklärt

Die Kernbeschränkung steht in den Google Maps Platform Nutzungsbedingungen unter den Lizenzbeschränkungen (Abschnitt 3.2.3 in der aktuellen Nummerierung). Der Kunde verpflichtet sich, Google-Maps-Inhalte nicht für die Nutzung ausserhalb der Dienste zu exportieren, zu extrahieren oder anderweitig zu scrapen. "Google-Maps-Inhalte" sind breit definiert: Der Begriff umfasst die Daten, die die Plattform zurückliefert, einschliesslich Einträgen, Rezensionen, Fotos und weiteren Inhalten, die Sie auf Google Maps sehen.

Aus dieser Formulierung folgen zwei Dinge:

1. Google-Maps-Seiten mit einem Headless-Browser zu laden und das HTML zu parsen ist exakt das Verhalten, das die Klausel beschreibt - egal, ob Sie den Browser selbst betreiben oder einen gehosteten Scraping-Actor mieten. Das Werkzeug ändert nichts an der Vertragslage.
2. Auch Daten aus der offiziellen Places API bleiben Google-Maps-Inhalte. Bezahlte API-Calls lizenzieren Sie nicht dazu, die Daten in einen eigenen, dauerhaften Datenbestand zu extrahieren - genau das begrenzt die Caching-Klausel weiter unten.

Wenn Sie die praktischen (nicht nur vertraglichen) Abwägungen zwischen Scraping und offizieller API interessieren: Der vollständige Vergleich steht in Google Places API Alternative: Firmendaten als JSON.

Was Sie cachen und speichern dürfen

Derselbe Abschnitt der Bedingungen untersagt das Caching von Google-Maps-Inhalten, "sofern nicht ausdrücklich erlaubt" - und die ausdrücklichen Erlaubnisse stehen in den Service Specific Terms und auf der Richtlinien-Seite der Places API. Stand Juli 2026 zählen für Places zwei Ausnahmen:

• Place-IDs: unbegrenzt speicherbar. Googles Places-Richtlinien legen fest, dass die Place-ID, die einen Ort eindeutig identifiziert, von den Caching-Beschränkungen ausgenommen ist. Das ist der unterstützte Weg, sich einen Ort zu "merken": ID behalten und frische Details neu anfragen, wenn Sie sie anzeigen wollen.
• Koordinaten: bis zu 30 Tage cachebar. Die Service Specific Terms erlauben das temporäre Caching von Places-Breiten-/Längengraden für bis zu 30 aufeinanderfolgende Kalendertage; danach müssen sie gelöscht werden.

Alles andere - Anzeigenamen, formatierte Adressen, Bewertungen, Rezensionen, Öffnungszeiten, Fotos, Telefonnummern, Website-URLs - fällt unter die Grundregel: live anfragen, anzeigen, nicht einlagern. Deshalb ist "einfach für jeden Betrieb der Stadt Place Details aufrufen und die Zeilen speichern" keine konforme Datenbankstrategie, auch wenn jeder einzelne API-Call legitim ist.

Attribution: der Teil, den die meisten Integrationen übersehen

Die Places-API-Richtlinien setzen auch Anzeige-Regeln für die angefragten Daten:

• Zeigen Sie Google-Maps-Attribution überall dort, wo Places-Daten erscheinen. Google bevorzugt das Google-Maps-Logo; wo der Platz knapp ist, ist der Text "Google Maps" akzeptabel.
• Nennen Sie den Autor, wenn Sie nutzergenerierte Inhalte wie Rezensionen und Fotos anzeigen. Bei Rezensionen in engen Layouts ist der Avatar des Autors das dokumentierte Minimum.

Zeigt Ihre Oberfläche Places-Daten ohne Attribution, ist das ein Richtlinienverstoss - selbst wenn Bezug und Caching ansonsten sauber sind.

Welcher Weg ist nun tatsächlich konform?

Ein Seiten-Scraper ist es nicht. Selbstgebaute Playwright-Crawler und gehostete "Google Maps Scraper"-Actors extrahieren beide Google-Maps-Inhalte für die Nutzung ausserhalb der Dienste - genau das, was die No-Scraping-Klausel untersagt. Der Google Maps Scraper Guide zeigt, was das operativ bedeutet (CAPTCHAs, Proxys, brechende Selektoren), zusätzlich zum Vertragsrisiko.

Die offizielle Places API ist konform für ihren vorgesehenen Zweck: Live-Ortssuche und -Anzeige in Ihrem Produkt, mit Field-Masks, Attribution und ohne Langzeitspeicherung jenseits der Place-IDs. Ihre Grenze sind Daten, die das Place-Objekt schlicht nicht enthält - allen voran E-Mail-Adressen von Betrieben, die keine Places-SKU liefert.

Eine lizenzierte Firmendaten-API geht einen dritten Weg. biz collect nutzt für die Suche die offizielle Google-Places-Suche, behält das Modell dauerhafter Identifikatoren und reichert dann jeden Datensatz aus der eigenen, öffentlichen Website des Betriebs an - E-Mails, Social-Profile und weitere Kontaktfelder stammen von der Website des Betriebs, nicht aus Google-Maps-Inhalten. Der Anreicherungs-Crawler respektiert robots.txt im standardmässigen respectful-Modus; die Grenzen sind in der Acceptable Use Policy und der Sicherheitsübersicht veröffentlicht.

Typische Situationen, beantwortet

"Ich will eine Datenbank aller Zahnärzte meines Kantons." Diese per Speichern von Places-API-Antworten aufzubauen kollidiert mit der Caching-Klausel, und das Scrapen von Maps-Seiten kollidiert mit der No-Scraping-Klausel. Die konformen Optionen sind lizenzierte Datenanbieter oder ein Anreicherungsmodell wie oben beschrieben.

"Ich will Cafés in der Nähe in meiner App anzeigen." Genau dafür ist die Places API da. Live anfragen, mit Attribution anzeigen, nur Place-IDs speichern.

"Ich habe Google Maps schon einmal für einen Einmal-Report gescrapt." Die Bedingungen unterscheiden nicht nach Einmal-Aktionen; verstehen Sie also das eingegangene Risiko: Durchsetzung heisst typischerweise gesperrte Keys oder Konten statt sofortiger Klagen, aber eine Produktionsabhängigkeit vom Scraping ist ein Geschäftsrisiko, nicht nur ein rechtliches.

"Mein Scraper-Anbieter sagt, das sei in Ordnung." Anbieter von Google-Maps-Scrapern beschreiben die Fähigkeit ihres Tools, nicht Ihre Erlaubnis. Die Bedingungen binden die Partei, die die Inhalte extrahiert - lesen Sie sie selbst.

Das Fazit

Die offiziellen Dokumente sind kurz und lohnen die direkte Lektüre: die Google Maps Platform Nutzungsbedingungen, die Service Specific Terms und die Places-API-Richtlinien. Das Muster, das sich daraus ergibt: Places live für die Anzeige nutzen, Place-IDs behalten, Koordinaten kurz cachen, alles attribuieren - und Google-Maps-Inhalte weder scrapen noch einlagern.

Wenn Ihr Job strukturierte, speicherbare lokale Firmendaten verlangt - CRM-Anreicherung, Lead-Recherche, KI-Agenten -, wählen Sie einen Weg, der dafür gebaut ist. Der Vergleich Google Places API Alternative führt durch die Entscheidung, und der Business Data API Guide zeigt, wie Sie Anbieter bewerten.