Qualche mese fa, uno sviluppatore su Stack Overflow ha pubblicato una domanda rimasta aperta dal 2012: "Google Places API Place Details limited to 5 reviews?" Quattordici anni, centinaia di voti positivi e la risposta è ancora la stessa: sì, massimo cinque recensioni. Questo solo limite dice già tutto sul perché esista questo dibattito.
Se ti è mai capitato di aver bisogno di dati di Google Places su larga scala — liste di lead, recensioni dei competitor, analisi dei flussi di passaggio, audit SEO locali — probabilmente ti sei trovato davanti allo stesso bivio. L’API ufficiale di Google Places è pulita, strutturata e ben documentata. Ma non restituisce tutto ciò che vedi in una pagina di Google Maps, e il conto può diventare salato non appena superi il livello gratuito. Lo scraping cattura di più, ha costi diversi e porta con sé altri problemi (CAPTCHA, selettori che si rompono, zone grigie dal punto di vista legale). Ho passato molto tempo ad approfondire entrambi i lati — documentazione API, SKU di prezzo, tool di scraping e compromessi reali — e questo articolo è il risultato. Vedremo le lacune campo per campo, i costi reali a 10K/100K/1M record, la realtà anti-bot e un playbook ibrido pratico. In più, un flowchart decisionale, perché nessuno vuole leggere 3.000 parole e restare comunque indeciso.
Cos’è la Google Places API (e cosa ti restituisce davvero)?
La Google Places API è il modo ufficiale e strutturato di Google per estrarre dati sulle attività commerciali — nomi, indirizzi, numeri di telefono, valutazioni, recensioni, foto — dal loro database. Tu invii una richiesta HTTP e ricevi in risposta JSON formattato. È il canale autorizzato.
L’attuale versione, Places API "New", organizza tutto attorno alle field mask. Quando chiami Place Details, specifichi esattamente quali campi vuoi — displayName, formattedAddress, rating, reviews, photos, ecc. — e Google ti addebita in base al livello più alto del campo richiesto. Se ometti la field mask, non ottieni una risposta di default: ricevi un errore. È una scelta intenzionale: Google vuole che tu paghi solo ciò che usi (e di più per i dati più appetibili).
I campi disponibili sono suddivisi in livelli di prezzo:
| Livello | Campi di esempio | Cosa ottieni |
|---|---|---|
| Essentials | Place ID, indirizzo formattato, posizione, metadati foto | Identità e posizione di base |
| Pro | Nome visualizzato, stato dell’attività, URI di Google Maps, tipo principale | Informazioni aziendali più ricche |
| Enterprise | Valutazione, numero di recensioni, sito web, numeri di telefono, orari di apertura, fascia di prezzo | I campi che la maggior parte degli utenti business vuole davvero |
| Enterprise + Atmosphere | Recensioni, riepilogo recensioni, riepilogo generativo, servizi, parcheggio, asporto/consegna | I dati più completi (e più costosi) |
Gli endpoint principali che interessano alla maggior parte degli utenti sono: Autocomplete (per la ricerca mentre digiti), Text Search e Nearby Search (per scoprire luoghi), Place Details (per arricchire un luogo già noto) e Place Photos (per le immagini).
Ora, i limiti che contano davvero:
- Recensioni: il Place resource restituisce un massimo di 5 recensioni per luogo, ordinate per rilevanza. Fine. Non 50, non "tutte". Cinque.
- Foto: limitate a 10 riferimenti foto per luogo nel Place resource.
- Popular times / affluenza in tempo reale: non disponibili come campo standard della Places API. Google conferma che questi dati esistono nelle superfici rivolte ai consumatori (basate su Location History aggregata e anonimizzata), e il blog di Maps spiega come funzionano — ma l’elenco dei campi non li include.
- Sezione Q&A: non esposta.
- Competitor "people also search for": non esposti.
- Menu / listino prezzi: non è un campo standard.
Chi usa di solito la Google Places API?
- Aziende logistiche che verificano e geocodificano indirizzi
- App travel e hospitality che mostrano hotel, ristoranti e attrazioni nelle vicinanze
- Piattaforme immobiliari che arricchiscono gli annunci con dati delle attività locali
- Agenzie SEO locali che controllano la coerenza NAP (nome, indirizzo, telefono)
- Team sales che costruiscono liste di lead partendo da Place ID e informazioni base sulle attività
Se il tuo caso d’uso rientra chiaramente in "mi servono dati strutturati sui luoghi in un’app di produzione", l’API è il punto di partenza giusto. Se invece compaiono parole come "tutte le recensioni", "popular times" o "analisi dei competitor", continua a leggere.
Cosa significa davvero "scraping" dei dati di Google Places?
Web scraping significa usare un software per estrarre automaticamente dati da una pagina web — in questo caso Google Maps o i risultati di Google Search — invece di passare da un’API ufficiale. Lo scraper legge la pagina come farebbe il browser, poi raccoglie gli elementi strutturati: nomi delle attività, indirizzi, testo delle recensioni, stelle, istogrammi degli orari di punta, Q&A, suggerimenti sui competitor, l’intera galleria fotografica e qualsiasi altra cosa venga renderizzata a schermo.
La distinzione chiave è questa: l’API ti dà ciò che Google decide di esporre. Lo scraping ti dà, in teoria, tutto quello che una persona vede sulla pagina.
Però "scraping" non è una sola cosa. Esistono tre approcci molto diversi, e i compromessi cambiano parecchio.
Script fai-da-te vs API di scraping gestite vs strumenti no-code
| Approccio | Come funziona | Ideale per | Principale compromesso |
|---|---|---|---|
| Script fai-da-te (Puppeteer, Playwright, Selenium) | Scrivi e mantieni uno script con browser headless che naviga nelle pagine di Google Maps e analizza il DOM | Sviluppatori che vogliono controllo totale e logica personalizzata | Il carico di manutenzione più alto: i selettori si rompono quando Google cambia l’interfaccia |
| API di scraping gestite (Thunderbit API, SerpApi, Outscraper) | Invi una URL o una query a un’API; lei gestisce rendering, anti-bot e parsing e restituisce dati strutturati | Sviluppatori che vogliono output strutturato senza mantenere scraper | Prezzi e qualità variano in base al fornitore; ti affidi a terzi |
| Estensioni browser no-code (Thunderbit Chrome Extension) | Estrazione point-and-click dal browser — l’AI suggerisce i campi, clicchi "Scrape", esporti in Sheets/Excel | Utenti business, marketer, team sales che vogliono i dati in un foglio di calcolo in fretta | Meno flessibile per pipeline complesse; dipende dalla qualità dell’AI dello strumento |
In breve: fai-da-te = massima flessibilità ma manutenzione elevata. API gestite = output strutturato, zero manutenzione. Strumenti no-code = la scelta più veloce per chi non sviluppa.
Google Places API vs scraping: confronto campo per campo
Questa è la tabella che avrei voluto trovare quando ho iniziato a studiare l’argomento. Ogni campo che un utente business o uno sviluppatore potrebbe voler ottenere, messo a confronto:
| Campo dati | Google Places API | Web Scraping |
|---|---|---|
| Nome attività | ✅ Completo (livello Pro) | ✅ Completo |
| Indirizzo / posizione | ✅ Completo (livello Essentials) | ✅ Completo |
| Numero di telefono | ✅ Livello Enterprise | ✅ Quando visibile |
| URL sito web | ✅ Livello Enterprise | ✅ Quando visibile |
| Valutazione aggregata | ✅ Livello Enterprise | ✅ Completa |
| Numero di recensioni utenti | ✅ Livello Enterprise | ✅ Completo |
| Recensioni individuali (testo + valutazione) | ⚠️ Massimo 5 recensioni | ✅ Tutte le recensioni disponibili |
| Popular times / affluenza in tempo reale | ❌ Non è un campo standard dell’API | ✅ Estraibile (quando renderizzato) |
| Sezione Q&A | ❌ Non esposta | ✅ Estraibile |
| Metadati delle foto | ✅ Massimo 10 riferimenti tramite endpoint Photos | ✅ Galleria completa |
| Menu / listino prezzi | ❌ Non è un campo standard | ⚠️ Quando presente sulla pagina |
| "People also search for" (competitor) | ❌ Non esposto | ✅ Estraibile |
| Orari di apertura | ✅ Livello Enterprise | ✅ Quando visibile |
| Fascia di prezzo | ✅ Livello Enterprise | ✅ Quando visibile |
| Place ID | ✅ Forte (Essentials) | ⚠️ Possibile, ma la fonte canonica resta l’API |
| URI di Google Maps | ✅ Livello Pro | ✅ È l’URL della pagina |
| Risposte del proprietario alle recensioni | ⚠️ Verificare disponibilità attuale | ✅ Spesso visibili |
| Posizione nella SERP / map pack | ❌ Non è lo scopo dell’API | ✅ Tramite scraping della SERP |
La lacuna più evidente: se ti servono set completi di recensioni per sentiment analysis, monitoraggio della reputazione o benchmarking competitivo, da sola l’API non basta. Cinque recensioni per luogo sono un campione, non un dataset.
Popular times e pattern di flusso pedonale? Stessa storia. Se sei un consulente retail o un analista immobiliare commerciale, lo scraping è l’unica strada: quei dati semplicemente non sono nell’API.
Dall’altra parte, per Place ID canonici, indirizzi strutturati per la geocodifica o per alimentare un store locator, l’API è più pulita, più affidabile e ufficialmente supportata.
Il vero costo: Google Places API vs scraping su 10K, 100K e 1M record
Il costo è la parte più fraintesa di questa scelta. Molti utenti si iscrivono al livello gratuito dell’API, costruiscono un prototipo e poi si ritrovano con una fattura che fa male non appena scalano. Sul fronte scraping, invece, si sottovalutano i costi dei proxy e il tempo degli sviluppatori.
Facciamo i conti.
Dettaglio prezzi della Google Places API
Google ha rivisto i prezzi di Maps Platform nel marzo 2025, sostituendo il vecchio credito mensile fisso da $200 con limiti gratuiti a livello di SKU e una tariffazione per volume. I prezzi attuali funzionano così:
- Campi Essentials (Place Details): 10.000 richieste gratuite/mese, poi $5,00 ogni 1.000 fino a 100K
- Campi Pro (Place Details): 5.000 gratuite, poi $7,00/1K
- Campi Enterprise (Place Details): 1.000 gratuite, poi $20,00/1K
- Enterprise + Atmosphere (recensioni, servizi): 1.000 gratuite, poi $25,00/1K
Dettaglio critico: se la tua field mask include anche solo un campo Enterprise + Atmosphere (come reviews), l’intera richiesta viene addebitata a quel livello. E un flusso tipico concatena più SKU — ad esempio Text Search Pro per scoprire i luoghi e poi Place Details Enterprise + Atmosphere per arricchirli — quindi i costi si sommano.
Un singolo "lookup" raramente corrisponde a una sola richiesta fatturabile.
Costi dello scraping: strumenti, proxy e tempo degli sviluppatori
I costi dello scraping si dividono in tre voci:
- Abbonamento allo strumento o crediti API: le API di scraping gestite addebitano per richiesta, per credito o per record. SerpApi addebita per ricerca. Outscraper usa un modello pay-as-you-go per record. La API di Thunderbit usa un sistema a crediti (Extract = 20 crediti/richiesta). L’estensione Chrome di Thunderbit addebita 1 credito per ogni riga di output.
- Spesa per i proxy (solo fai-da-te): i proxy residenziali per lo scraping di Google Maps costano in genere tra $50 e $300/mese, in base al volume e al provider.
- Tempo degli sviluppatori (solo fai-da-te): costruire e mantenere script Puppeteer/Playwright. È il costo nascosto che manda in crisi l’economia del fai-da-te (ne parlo meglio sotto).
Tabella costi affiancata: API vs scraping su larga scala
| Scala | Google Places API (Enterprise + Atmosphere) | API di scraping gestita (stima) | Scraping fai-da-te (proxy + tempo dev) |
|---|---|---|---|
| 10K record/mese | ~$225 (1K gratis, 9K × $25/1K) | ~$50–$150 a seconda del provider | ~$50 di proxy + 2–4 ore dev/mese |
| 100K record/mese | ~$2.475 (dopo il tetto gratuito, si applicano i tier per volume) | ~$250–$500 | ~$150 di proxy + 8–16 ore dev/mese |
| 1M record/mese | ~$17.975 (i tier per volume riducono il costo unitario, ma il totale resta alto) | ~$1.500–$3.000 | ~$300 di proxy + 20+ ore dev/mese + rischio di rotture |
Note: le stime API usano i tier di volume pubblicati per Place Details Enterprise + Atmosphere, applicati dopo il tetto gratuito di 1K. Le stime per le API di scraping gestite sono intervalli indicativi tra diversi provider. Il tempo dev fai-da-te assume un costo pieno di $50–$100/ora.
Il pattern è chiaro: su volumi piccoli o da hobby (sotto 10K), i limiti gratuiti dell’API possono renderla l’opzione più economica, soprattutto se ti bastano i campi Essentials o Pro. Su scala business (100K+), i costi dell’API salgono rapidamente, soprattutto per i campi ricchi. Su scala enterprise (1M+), l’API può avvicinarsi a cinque cifre al mese, mentre scraping o dataset service diventano economicamente più interessanti — sempre che ti servano davvero i campi extra che l’API non espone.
Se ti servono solo indirizzi e Place ID, non fare scraping. L’API è più economica e migliore per questo scopo. L’argomento economico a favore dello scraping vale solo quando hai bisogno di dati che l’API non può restituire.
La realtà anti-bot: perché gli scraper DIY per Google si rompono
Ecco la parte che gli evangelisti dello scraping saltano. Google non vuole che tu faccia scraping di Google Maps. Ha costruito più livelli di difesa e li aggiorna regolarmente.
Le difese stratificate di Google
- Sfide reCAPTCHA: i browser automatizzati attivano CAPTCHA molto più spesso degli utenti reali
- Rendering JavaScript lato client: Google Maps è una pesante applicazione JavaScript. Una semplice richiesta HTTP non basta per ottenere il contenuto renderizzato: serve un browser headless completo
- Browser fingerprinting: Google rileva i browser headless tramite fingerprint canvas, WebGL, proprietà di navigator e altri segnali
- Rate limiting degli IP: troppe richieste dallo stesso IP (o dallo stesso subnet proxy) e vieni bloccato
- Modifiche alla struttura DOM: Google cambia regolarmente la struttura delle sue pagine — il consenso diffuso su Reddit e nei ticket GitHub è che i selettori si rompono ogni poche settimane o mesi
Quest’ultimo punto è il killer silenzioso. Uno script Puppeteer che a giugno funzionava perfettamente può restituire risultati vuoti a luglio perché Google ha rinominato una classe CSS o riorganizzato un div.
Il costo nascosto della manutenzione degli script DIY
Ogni volta che Google cambia il DOM, qualcuno nel tuo team deve:
- Accorgersi che lo scraper è rotto (meglio prima che i dati errati si diffondano)
- Ispezionare la nuova struttura della pagina
- Aggiornare i selettori, gestire nuovi tipi di CAPTCHA, modificare la logica di retry
- Testare e rilasciare di nuovo
Su un anno, questo tempo di manutenzione può facilmente superare il costo di abbonamento di un’API di scraping gestita. Ho visto team bruciare più di 40 ore di sviluppo all’anno solo per tenere in vita uno scraper per Google Maps — e si tratta di una stima prudente per una configurazione di complessità media.
Perché esistono le API di scraping gestite
Proprio questo carico di manutenzione spiega l’esistenza di servizi come Thunderbit API, SerpApi e Outscraper. Assorbono la complessità anti-bot — rendering JS, risoluzione dei CAPTCHA, rotazione dei proxy, manutenzione dei selettori — e restituiscono dati strutturati.
L’endpoint POST /extract di Thunderbit con renderMode: "full" gestisce pagine pesanti in JavaScript come Google Maps e restituisce JSON strutturato e allineato allo schema, non HTML grezzo da parsare ancora. Il server MCP estende tutto questo agli agenti AI — Claude, Cursor o altri flussi basati su LLM possono estrarre dati da Google Maps durante il task senza uscire dal loro ambiente.
Per gli utenti non tecnici, la Thunderbit Chrome Extension è l’opzione senza manutenzione: apri una pagina di Google Maps, clicca "AI Suggest Fields", clicca "Scrape", esporta in Sheets. Niente selettori, niente proxy, niente debug.
SerpApi e Outscraper sono alternative solide con modelli di prezzo e formati di output diversi. SerpApi restituisce JSON strutturato per ricerca; Outscraper addebita per record con pricing pay-as-you-go. La scelta giusta dipende dal volume, dal budget e dal fatto che tu abbia bisogno di JSON strutturato o ti vada bene parsare un output semi-strutturato.
Il playbook ibrido: usare insieme Google Places API e scraping
Nessuno degli articoli che si posizionano in alto su questo tema suggerisce quello che nella pratica ho visto funzionare meglio: usare entrambi. Molti team finiscono per affidarsi all’API ufficiale per alcuni task e allo scraping per altri. Il trucco è abbinare ogni strumento al lavoro giusto.
Quando vince l’API ufficiale
- Autocomplete in un’app di produzione live: bassa latenza, conforme ai ToS, SLA affidabile. Nessun confronto possibile.
- Backend di app basate sulla posizione: store locator, validazione indirizzi, matching dei Place ID. L’API è strutturata, supportata e documentata.
- Integrazioni sensibili alla compliance: contratti enterprise, prodotti rivolti al pubblico o qualsiasi contesto in cui la conformità ai ToS di Google sia non negoziabile.
Quando vince lo scraping
- Estrazione completa delle recensioni (5K+ recensioni per luogo): sentiment analysis, monitoraggio reputazionale, benchmark competitivo. Il limite di 5 recensioni dell’API la rende inutile qui.
- Estrazione una tantum di liste lead: più economica per job batch senza fatturazione ricorrente. Un tool no-code come Thunderbit può estrarre una lista di attività ed esportarla in un foglio di calcolo in pochi minuti.
- Analisi dei popular times / flussi di passaggio: non disponibile via API. Punto.
- Dati Q&A, "people also search for" dei competitor: visibili solo sulla pagina, non nell’API.
Quando ha senso un approccio ibrido
- Monitoraggio continuo di prezzo/valutazione: usa l’API per i dati strutturati di base (Place ID, indirizzo, valutazione aggregata), poi fai scraping per i campi profondi che mancano all’API (recensioni complete, popular times).
- Workflow di enrichment: usa l’API per ottenere Place ID e informazioni canoniche sull’attività, poi fai scraping delle pagine singole per avere set completi di recensioni, Q&A e contesto dei competitor.
- Monitoraggio programmato: lo scraper schedulato di Thunderbit (per utenti no-code) o l’estrazione batch da CLI (per sviluppatori) possono gestire scraping ricorrenti senza infrastruttura custom.
Matrice decisionale per use case
| Caso d’uso | Metodo consigliato | Perché |
|---|---|---|
| Autocomplete in un’app live | ✅ API ufficiale | Latenza bassa, conforme ai ToS, affidabile |
| Estrazione di 5K+ set completi di recensioni | ✅ Scraping / API di scraping | L’API si ferma a 5 recensioni per luogo |
| Lista lead di attività locali una tantum | ✅ Scraping (o estensione Thunderbit) | Più economico per batch; niente fatturazione ricorrente |
| Analisi popular times / flussi di passaggio | ✅ Solo scraping | Non disponibile via API |
| Monitoraggio continuo di prezzo/valutazione | ⚠️ Ibrido | API per i dati base, scraping per i campi profondi |
| Backend di app basata sulla posizione | ✅ API ufficiale | Strutturata, supportata, con SLA |
| Tracking della posizione SERP per SEO locale | ✅ Scraping / SERP API | Non è lo scopo della Places API |
| "People also search for" dei competitor | ✅ Solo scraping | Non esposto via API |
Flowchart decisionale: Google Places API vs scraping — quale scegliere?
Invece del classico "dipende", ecco un framework decisionale concreto. Passa in rassegna queste quattro domande:
1. Ti servono dati in tempo reale in un’app di produzione? → Sì: usa l’API ufficiale. È supportata, ha SLA ed è conforme ai ToS. Fermati qui. → No: continua.
2. Ti servono dati che l’API non restituisce (recensioni complete, popular times, Q&A)? → Sì: lo scraping è necessario. L’API, letteralmente, non può darti quei dati. → No: continua.
3. Quanti record al mese? → Sotto 10K: l’API è probabilmente la più economica, soprattutto se ti bastano campi Essentials o Pro. I limiti gratuiti coprono molto a questa scala. → Oltre 10K: scraping o un’API di scraping gestita sono probabilmente più convenienti, soprattutto per i campi ricchi.
4. Hai risorse di sviluppo per costruire e mantenere scraper? → Sì: il fai-da-te con Puppeteer/Playwright ti dà il massimo controllo (ma metti a budget la manutenzione continua). → No: usa un’API di scraping gestita (Thunderbit API, SerpApi, Outscraper) oppure uno strumento no-code (Thunderbit Chrome Extension).
Confronto rapido delle alternative orientate agli sviluppatori
| Strumento | Modello di prezzo | Formato output | Gestione anti-bot | Supporto batch |
|---|---|---|---|---|
| Thunderbit API / MCP | A crediti (Extract = 20 crediti/richiesta) | JSON strutturato e allineato allo schema | ✅ Rendering JS, rotazione proxy, geo-routing | ✅ Fino a 100 URL per batch |
| SerpApi | Per ricerca (piani a livelli) | JSON strutturato | ✅ | ✅ Tramite parametri API |
| Outscraper | Per record (pay-as-you-go) | JSON / CSV | ✅ | ✅ Tramite code di task |
| DIY (Puppeteer/Playwright) | Proxy + tempo dev | HTML grezzo (da parsare) | ❌ Lo gestisci tu | ✅ Qualunque cosa tu costruisca |
La differenza di Thunderbit: restituisce JSON strutturato e allineato allo schema in base a uno JSON Schema che definisci tu — non HTML o Markdown grezzo che richiedono ancora parsing. Se alimenti una pipeline LLM o carichi un database, questo fa risparmiare tempo reale nel post-processing.
Come si inserisce Thunderbit qui dentro (per utenti business e sviluppatori)
Abbiamo creato Thunderbit per colmare il divario tra "mi servono dati di Google Maps" e "non voglio diventare un ingegnere di infrastrutture per scraping". Ecco come funziona per entrambi i pubblici.
Per gli utenti non tecnici: l’estensione Chrome
- Apri una pagina di Google Maps — una pagina di risultati di ricerca o la scheda di un’attività
- Clicca "AI Suggest Fields" — l’AI di Thunderbit legge la pagina e propone le colonne (nome attività, indirizzo, valutazione, recensioni, telefono, ecc.)
- Clicca "Scrape" — l’estensione estrae i dati in una tabella strutturata. Usa la modalità cloud per arrivare fino a 50 pagine in parallelo
- Fai scraping delle subpage — clicca "Scrape Subpages" per aprire ogni scheda e raccogliere i dettagli completi
- Esporta — in Excel, Google Sheets, Airtable o Notion. Esportazione gratuita, senza paywall
Per il monitoraggio ricorrente — controlli settimanali delle valutazioni dei competitor, nuove schede attività — lo scraper schedulato gira automaticamente con la frequenza che imposti.
Per gli sviluppatori: API, server MCP e CLI
POST /extractcon uno JSON Schema: invii una URL di Google Maps, definisci i campi che vuoi, ricevi JSON strutturato. ImpostarenderMode: "full"per le pagine pesanti in JavaScript. Thunderbit gestisce rendering, anti-bot, rotazione proxy e geo-routing.POST /distill: ottieni Markdown pulito da qualsiasi pagina — utile per pipeline LLM che hanno bisogno di contenuto grezzo invece che di campi strutturati. 1 credito/richiesta contro 20 per Extract.- MCP Server: agenti AI (Claude, Cursor) possono estrarre dati da Google Maps durante il workflow. Supporta distillazione, estrazione strutturata, suggerimento dei campi e job batch fino a 100 URL.
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsonper scraping schedulato o integrato in CI/CD.
Prezzi in crediti: Extract = 20 crediti/richiesta, Distill = 1 credito/richiesta. I crediti API sono per richiesta, non per riga (a differenza dell’estensione, dove 1 credito = 1 riga di output). Controlla Thunderbit Pricing per i piani aggiornati.
Aspetti legali e considerazioni sui Termini di Servizio
Sarò breve e concreto — niente allarmismi, niente vendita aggressiva.
La Google Places API ha termini chiari: i termini specifici del servizio di Google dicono che i contenuti della Places API possono essere usati senza una Google Map, ma non con una mappa non Google. Le coordinate latitudine/longitudine possono essere memorizzate nella cache fino a 30 giorni di calendario consecutivi; i Place ID possono essere conservati indefinitamente. Per dettagli, foto e recensioni è richiesta l’attribuzione.
Lo scraping di Google Maps può violare i Termini di Servizio di Google. L’applicazione delle regole varia — i rischi includono blocchi IP, muri CAPTCHA e, in rari casi, azioni legali. Le API di scraping gestite in genere si assumono parte dell’onere di compliance per conto degli utenti, ma non costituiscono uno scudo legale.
Per app di produzione rivolte agli utenti finali, l’API ufficiale è la scelta più sicura. Per ricerca interna, analisi batch e competitive intelligence, lo scraping è una pratica comune nel settore. Per workflow commerciali, consulta il tuo legale.
Cosa sceglierei davvero io (e perché)
Dopo aver analizzato SKU di prezzo, elenchi dei campi, thread della community e documentazione degli strumenti, questa è la mia conclusione:
- Usa l’API ufficiale quando ti servono dati in tempo reale, conformi ai ToS, in un’app di produzione, oppure quando i campi Essentials/Pro bastano e il volume è sotto i 10K/mese. I limiti gratuiti sono generosi su piccola scala e la qualità dei dati è inattaccabile.
- Usa lo scraping (API gestita o tool no-code) quando ti servono recensioni complete, popular times, Q&A, contesto dei competitor o qualunque campo l’API non esponga. Anche quando il volume supera 10K–100K record/mese e stai richiedendo campi ricchi (Enterprise + Atmosphere): il conto API diventa difficile da giustificare.
- Usa entrambi quando il tuo flusso richiede Place ID canonici e dati strutturati di base (API) più intelligence profonda visibile sulla pagina (scraping). È molto più comune di quanto ammettano molti articoli.
Il punto di svolta sui costi: sotto circa 10K record/mese con campi base, l’API è più semplice e spesso gratuita. Sopra quella soglia, soprattutto per dati ricchi, lo scraping diventa più economico. A 1M record con campi Enterprise + Atmosphere, l’API arriva a circa $18K/mese contro una frazione di quella cifra con uno scraper gestito.
Se vuoi testarlo di persona, la Thunderbit Chrome Extension è il modo più rapido per vedere cosa cattura lo scraping rispetto all’API. Per i workflow da sviluppatore, la documentazione dell’API Thunderbit contiene tutto ciò che serve per iniziare. E per approfondire web scraping senza codice o AI web scraping in generale, abbiamo trattato estesamente questi temi sul blog.
Punti chiave
- La Google Places API è lo strumento giusto per app di produzione, autocomplete e lookup strutturati dei luoghi — ma limita le recensioni a 5, le foto a 10 e non espone popular times, Q&A o suggerimenti dei competitor.
- Lo scraping cattura tutto ciò che è visibile su una pagina di Google Maps, inclusi set completi di recensioni e dati sui popular times, ma richiede di gestire difese anti-bot o pagare un servizio gestito.
- Sotto i 10K record/mese, i limiti gratuiti dell’API spesso la rendono l’opzione più economica. Oltre i 100K, scraping o API di scraping gestite risultano di solito più convenienti per dati ricchi.
- Gli scraper DIY si rompono spesso a causa delle difese anti-bot di Google e delle modifiche al DOM — metti a budget 40+ ore/anno di manutenzione, oppure usa uno strumento gestito.
- La strategia migliore nel mondo reale è spesso ibrida: API per ID canonici e campi base, scraping per l’intelligence profonda che l’API non può restituire.
- Thunderbit copre entrambi i lati: un’estensione Chrome per utenti no-code e un’API / server MCP con JSON strutturato per sviluppatori.
FAQ
Si possono ottenere più di 5 recensioni Google tramite la Places API?
No. La Google Places API limita le recensioni a 5 per luogo, ordinate per rilevanza. È così fin dal lancio dell’API e non è cambiato nonostante anni di richieste da parte degli sviluppatori. Per accedere a tutte le recensioni disponibili di un’attività, lo scraping — fai-da-te oppure tramite un’API di scraping gestita — è l’unica opzione.
Lo scraping di Google Maps è legale?
Non esiste una risposta universale sì/no. Lo scraping dei dati pubblicamente visibili di Google Maps può violare i Termini di Servizio di Google, e l’applicazione varia dai blocchi IP fino, raramente, ad azioni legali. Molte aziende usano lo scraping per ricerca interna e competitive intelligence senza problemi. Le API di scraping gestite assorbono parte del rischio di compliance, ma non sono uno scudo legale. Se stai costruendo un prodotto commerciale o trattando dati personali, consulta un legale.
Quanto costa la Google Places API per 100K lookup?
Dipende dai campi richiesti. Per Place Details al livello Essentials, circa $450. Al livello Pro, circa $1.615. Con Enterprise + Atmosphere (che include recensioni e servizi), circa $2.475. Se il tuo flusso richiede anche Text Search Pro per la discovery, aggiungi altri circa $3.040. Queste stime usano i tier di volume pubblicati da Google e assumono una richiesta fatturabile per record dopo il tetto gratuito.
Qual è la differenza tra un’API di scraping e uno strumento di scraping no-code?
Un’API di scraping (come Thunderbit Open API) è pensata per sviluppatori che integrano lo scraping in codice, pipeline di automazione o workflow di agenti AI tramite richieste HTTP. Uno strumento no-code (come la Thunderbit Chrome Extension) permette a utenti non tecnici di cliccare, selezionare ed esportare dati dal browser senza scrivere codice. Entrambi possono restituire dati strutturati; cambia l’interfaccia e il modello di integrazione.
Thunderbit funziona sulle pagine di Google Maps?
Sì. L’estensione Chrome può fare scraping dei risultati di ricerca di Google Maps e delle singole schede attività — l’AI suggerisce automaticamente i campi e puoi usare la modalità cloud per arrivare fino a 50 pagine contemporaneamente. L’endpoint POST /extract dell’API con renderMode: "full" gestisce le pagine di Google Maps renderizzate in JavaScript e restituisce JSON strutturato e allineato allo schema. Il server MCP consente agli agenti AI di estrarre dati da Google Maps durante il workflow.
Scopri di più
