Termini Google Places API: scraping, cache e storage

Sul tema scraping Google è diretto: i Termini di servizio di Google Maps Platform stabiliscono che i clienti non devono "esportare, estrarre o comunque effettuare scraping dei contenuti di Google Maps per usi esterni ai Servizi" (nel testo originale: "export, extract, or otherwise scrape Google Maps Content for use outside the Services"), e il caching è vietato salvo dove i Service Specific Terms lo consentono espressamente. Due eccezioni pratiche da conoscere: i place ID possono essere conservati senza limiti di tempo, e le coordinate dei luoghi possono essere tenute in cache fino a 30 giorni di calendario consecutivi. Tutto il resto - nomi, valutazioni, recensioni, foto, numeri di telefono - va richiesto in tempo reale e mostrato con l'attribuzione Google Maps, non archiviato.

Questa guida ripercorre ciò che i termini e le policy ufficiali dicono davvero, sezione per sezione, con i link ai documenti di Google così da poter verificare ogni affermazione. È pensata per sviluppatori che devono scegliere tra l'API Places ufficiale, uno scraper di Google Maps e un'API di dati aziendali con licenza - tre strade con posture contrattuali molto diverse. Non è consulenza legale; leggete sempre i documenti in vigore, perché Google li aggiorna.

Le regole in sintesi

Verificato a luglio 2026 sui termini ufficiali di Maps Platform, sui Service Specific Terms e sulle policy dell'API Places. Google rivede questi documenti; controllate il testo in vigore prima di costruire.

La clausola anti-scraping, in parole semplici

La restrizione centrale sta nei Termini di servizio di Google Maps Platform, tra le restrizioni di licenza (sezione 3.2.3 nella numerazione attuale). Il cliente si impegna a non esportare, estrarre o comunque fare scraping dei contenuti di Google Maps per usi esterni ai servizi. I "contenuti di Google Maps" sono definiti in modo ampio: coprono i dati restituiti dalla piattaforma, incluse schede, recensioni, foto e altri contenuti visibili su Google Maps.

Da questa formulazione seguono due conseguenze:

1. Caricare pagine di Google Maps con un browser headless e fare il parsing dell'HTML è esattamente il comportamento descritto dalla clausola, sia che il browser lo gestiate voi sia che affittiate un actor di scraping in hosting. Lo strumento non cambia la postura contrattuale.
2. Anche i dati ottenuti tramite l'API Places ufficiale restano contenuti di Google Maps. Pagare le chiamate API non vi autorizza a estrarli in un vostro dataset autonomo - è proprio ciò che la clausola di caching qui sotto delimita.

Se state valutando i compromessi pratici (non solo contrattuali) tra scraping e API ufficiale, il confronto completo è in Alternativa a Google Places API: dati in JSON.

Cosa potete tenere in cache e salvare

La stessa sezione dei termini vieta il caching dei contenuti di Google Maps "salvo quanto espressamente consentito" - e i permessi espressi vivono nei Service Specific Terms e nella pagina delle policy dell'API Places. A luglio 2026 le eccezioni che contano per Places sono due:

• Place ID: conservabili senza limiti. Le policy Places di Google stabiliscono che il place ID, che identifica un luogo in modo univoco, è esente dalle restrizioni di caching. È il modo supportato di "ricordare" un luogo: conservate l'ID e richiedete dettagli freschi quando dovete mostrarli.
• Coordinate: cache fino a 30 giorni. I Service Specific Terms permettono di tenere temporaneamente in cache le latitudini/longitudini Places per non più di 30 giorni di calendario consecutivi, dopo i quali vanno cancellate.

Tutto il resto - nomi visualizzati, indirizzi formattati, valutazioni, recensioni, orari, foto, numeri di telefono, URL dei siti - ricade nella regola generale: richiedete in tempo reale, mostrate, non archiviate. Ecco perché "chiamare Place Details per ogni azienda della città e salvare le righe" non è una strategia di database conforme, anche se ogni singola chiamata API è legittima.

Attribuzione: la parte che la maggior parte delle integrazioni dimentica

Le policy dell'API Places fissano anche regole di visualizzazione per i dati richiesti:

• Mostrate l'attribuzione Google Maps ovunque compaiano dati Places. Google preferisce il logo Google Maps; dove lo spazio manca, il testo "Google Maps" è accettabile.
• Accreditate l'autore quando mostrate contenuti generati dagli utenti come recensioni e foto. Per le recensioni in layout stretti, l'avatar dell'autore è il minimo documentato.

Se la vostra interfaccia mostra dati Places senza attribuzione, è una violazione delle policy anche quando sourcing e caching sono per il resto puliti.

Quindi quale strada è davvero conforme?

Uno scraper di pagine non lo è. I crawler Playwright fai-da-te e gli actor "Google Maps scraper" in hosting estraggono entrambi contenuti di Google Maps per usi esterni ai servizi - esattamente ciò che la clausola anti-scraping vieta. La guida al Google Maps Scraper spiega cosa significa a livello operativo (CAPTCHA, proxy, selettori che si rompono), oltre all'esposizione contrattuale.

L'API Places ufficiale è conforme per il compito per cui è nata: ricerca e visualizzazione di luoghi in tempo reale nel vostro prodotto, con field mask, attribuzione e nessuna conservazione a lungo termine oltre i place ID. Il suo limite sono i dati che l'oggetto Place semplicemente non contiene - primo fra tutti l'indirizzo email delle aziende, che nessuna SKU Places restituisce.

Un'API di dati aziendali con licenza percorre una terza via. biz collect effettua la ricerca tramite la ricerca ufficiale di Google Places, mantiene il modello degli identificatori durevoli e poi arricchisce ogni record dal sito web pubblico dell'azienda - email, profili social e altri campi di contatto provengono dal sito dell'azienda, non dai contenuti di Google Maps. Il crawler di arricchimento rispetta robots.txt nel modo respectful predefinito, e i confini sono pubblicati nell'acceptable use policy e nella panoramica sulla sicurezza.

Situazioni tipiche, risposte chiare

"Voglio un database di tutti i dentisti della mia regione." Costruirlo salvando risposte dell'API Places confligge con la clausola di caching, e fare scraping delle pagine Maps confligge con la clausola anti-scraping. Le opzioni conformi sono i fornitori di dati con licenza o un modello di arricchimento come quello descritto sopra.

"Voglio mostrare i caffè nelle vicinanze nella mia app." È esattamente il compito dell'API Places. Richiedete in tempo reale, mostrate con attribuzione, conservate solo i place ID.

"Ho già fatto scraping di Google Maps per un report una tantum." I termini non distinguono le attività una tantum, quindi capite il rischio corso: l'applicazione dei termini si traduce di solito in chiavi o account bloccati più che in cause immediate, ma una dipendenza di produzione dallo scraping è un rischio d'impresa, non solo legale.

"Il mio fornitore di scraper dice che va bene." Chi vende scraper di Google Maps descrive la capacità del proprio strumento, non il vostro permesso. I termini vincolano la parte che estrae i contenuti - leggeteli voi stessi.

In conclusione

I documenti ufficiali sono brevi e meritano una lettura diretta: i Termini di servizio di Google Maps Platform, i Service Specific Terms e le policy dell'API Places. Il quadro che ne emerge: usate Places in tempo reale per la visualizzazione, conservate i place ID, tenete brevemente in cache le coordinate, attribuite tutto, e non fate scraping né archiviazione dei contenuti di Google Maps.

Quando il lavoro richiede dati aziendali locali strutturati e conservabili - arricchimento CRM, ricerca di lead, agenti AI -, scegliete una strada costruita per quello. Il confronto Alternativa a Google Places API guida la decisione, e la guida alle business data API spiega come valutare i fornitori.