Google Maps API è uno strumento potente per il geocoding degli indirizzi, la ricerca di organizzazioni e la raccolta di dati su aziende locali. Ma quando si inizia a lavorare con esso su larga scala, compaiono blocchi delle chiavi, superamenti dei limiti e richieste sospette. In questo articolo vedremo perché ciò accade e come configurare i proxy in modo che le chiavi non vengano bloccate e i dati vengano raccolti in modo stabile.
Perché Google Maps API blocca chiavi e richieste
Quando invii centinaia o migliaia di richieste a Google Maps API da un singolo indirizzo IP o da una singola chiave, Google percepisce questo come un'attività anomala. Il sistema di protezione funziona su più criteri contemporaneamente: frequenza delle richieste, geografia dell'IP, schemi comportamentali e storia della chiave.
Ecco le principali ragioni per cui le chiavi ricevono limitazioni o un ban completo:
- Superamento del limite giornaliero di richieste — ogni chiave ha una quota, e quando questa viene esaurita, l'API restituisce un errore
OVER_QUERY_LIMIT. - Alta frequenza di richieste da un singolo IP — anche all'interno del limite, Google registra richieste consecutive troppo rapide come automazione.
- Un IP per più chiavi — se ruoti le chiavi ma non ruoti l'IP, Google le collega in un'unica sessione.
- Incongruenza tra la geolocalizzazione della chiave e l'IP — la chiave è registrata in un paese, mentre le richieste provengono da un altro, il che suscita sospetti.
- Assenza di ritardi tra le richieste — schemi automatici senza pause vengono rilevati immediatamente.
- Utilizzo di IP di data center senza mascheramento — Google conosce bene gli intervalli di IP dei fornitori di cloud (AWS, GCP, Azure) e aumenta il livello di verifica per loro.
È importante capire: Google Maps API è un prodotto a pagamento, e Google lo protegge non solo da abusi, ma anche da tentativi di elusione della fatturazione. Per questo motivo, il sistema di rilevamento qui è significativamente più severo rispetto a quello, ad esempio, della ricerca web normale. Il blocco di una chiave significa perdere l'accesso ai dati e dover creare un nuovo account Google Cloud, il che è già di per sé dispendioso in termini di tempo.
Importante sapere
Google monitora non solo l'indirizzo IP, ma anche l'User-Agent, le intestazioni delle richieste, il tempo tra le richieste e il modello degli endpoint utilizzati. I proxy sono un elemento necessario, ma non l'unico per proteggere le chiavi.
Chi e perché utilizza Google Maps API nel business
Prima di passare ai dettagli tecnici, esaminiamo alcuni scenari reali di utilizzo. Questo aiuterà a scegliere il tipo di proxy giusto e la strategia di rotazione per il compito specifico.
Geocoding di indirizzi in modalità massiva
Le aziende di logistica, gli aggregatori immobiliari e i marketplace di consegna convertono regolarmente migliaia di indirizzi testuali in coordinate. Ad esempio, durante il caricamento di un database di 50.000 indirizzi clienti per la pianificazione di percorsi. Geocoding API consente di automatizzare questo processo, ma 50.000 richieste da una sola chiave in breve tempo sono un modo diretto per essere bloccati.
Parsing dei dati su aziende locali (Places API)
Le agenzie di marketing, i lead generator e i database aziendali utilizzano Places API per raccogliere informazioni sulle organizzazioni: nomi, numeri di telefono, siti web, valutazioni, orari di apertura, recensioni. Un compito tipico è raccogliere tutti i ristoranti, studi dentistici o officine in diverse città per successive chiamate o invii di email.
Monitoraggio dei concorrenti e geoanalisi
I rivenditori monitorano l'apertura di nuovi punti vendita dei concorrenti nelle loro aree. Le reti in franchising analizzano potenziali posizioni per nuovi negozi. Le agenzie pubblicitarie controllano il geotargeting — come appare il risultato in una città o in un'area specifica.
Arricchimento dei dati CRM
I prodotti SaaS e i servizi B2B arricchiscono automaticamente le schede aziendali nel CRM: aggiungono coordinate, verificano l'accuratezza degli indirizzi, estraggono dati da Google Business Profile. Questo richiede richieste regolari in background all'API in modo automatico.
In tutti questi scenari c'è un elemento comune: alta frequenza di richieste, che senza proxy porta inevitabilmente a blocchi. L'approccio alla soluzione varia a seconda del compito.
Quali proxy sono adatti per lavorare con Google Maps API
La scelta del tipo di proxy influisce direttamente sulla stabilità del lavoro e sulla probabilità di blocchi. Esaminiamo tre opzioni principali relative ai compiti di Google Maps API.
| Tipo di proxy | Affidabilità | Velocità | Prezzo | Migliore per |
|---|---|---|---|---|
| Proxy residenziali | ★★★★★ | ★★★☆☆ | Alta | Parsing di Places API, geocoding in regioni sensibili |
| Proxy mobili | ★★★★★ | ★★★★☆ | Alta | Massima affidabilità, compiti a lungo termine |
| Proxy di data center | ★★★☆☆ | ★★★★★ | Bassa | Geocoding massivo con bassa sensibilità |
Proxy residenziali — la scelta ottimale per la maggior parte dei compiti
I proxy residenziali utilizzano indirizzi IP di veri utenti domestici di internet. Per Google, sembrano persone normali che aprono mappe nel browser. Questo li rende l'opzione più sicura per lavorare con Places API e geocoding ad alta frequenza di richieste. Un grande pool di IP consente di ruotare ad ogni richiesta o ogni poche richieste — Google non riesce a collegarli in un'unica sessione.
Proxy mobili — quando è necessaria la massima affidabilità
Gli IP mobili degli operatori di telefonia mobile sono un caso particolare. Un singolo IP mobile è realmente utilizzato da molti dispositivi dietro NAT, quindi Google blocca raramente tali indirizzi anche con alta attività. Se il tuo compito è critico e non puoi permetterti interruzioni, i proxy mobili offriranno la massima stabilità. Lo svantaggio è il prezzo più alto e un pool di indirizzi più piccolo.
Proxy di data center — solo per compiti non sensibili
I proxy server sono veloci ed economici, ma Google Maps API li considera con maggiore sospetto. Se li utilizzi per geocoding di un grande volume di indirizzi con frequenza moderata e buona rotazione, potrebbero funzionare. Ma per il parsing di Places API o per lavorare in regioni con restrizioni severe, il rischio di blocco della chiave è significativamente più alto.
Configurazione dei proxy per geocoding: guida passo passo
Esaminiamo la configurazione pratica utilizzando Geocoding API — lo scenario più comune. Compito: convertire un elenco di 10.000 indirizzi in coordinate senza bloccare la chiave.
Passo 1. Prepara l'infrastruttura
Prima di tutto, decidi il numero di chiavi e proxy. Regola di base: una chiave — un pool di IP. Non utilizzare lo stesso pool di proxy per chiavi diverse — Google può collegarli tramite schemi comportamentali. Per un compito di 10.000 indirizzi, si consiglia di avere almeno 2-3 chiavi Google Cloud e un pool di oltre 50 IP residenziali.
Passo 2. Configura la rotazione degli IP
La strategia ottimale per il geocoding è cambiare IP ogni 10-20 richieste, e non ad ogni richiesta. Cambiare IP troppo frequentemente può sembrare sospetto. La maggior parte dei fornitori di proxy residenziali offre un endpoint rotante — un indirizzo unico che cambia automaticamente IP a intervalli prestabiliti. Utilizza proprio questo, invece di un cambio manuale.
Python — esempio base di richiesta tramite proxy
import requests
GOOGLE_API_KEY = "LA_TUA_CHIAVE"
PROXY_HOST = "rotating.proxyprovider.com"
PROXY_PORT = "8080"
PROXY_USER = "username"
PROXY_PASS = "password"
proxies = {
"http": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
"https": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
}
def geocode_address(address):
url = "https://maps.googleapis.com/maps/api/geocode/json"
params = {
"address": address,
"key": GOOGLE_API_KEY,
"language": "it"
}
response = requests.get(url, params=params, proxies=proxies, timeout=10)
return response.json()
# Esempio di utilizzo
result = geocode_address("Mosca, via Tverskaya, 1")
print(result["results"][0]["geometry"]["location"])
Passo 3. Aggiungi ritardi tra le richieste
Non inviare mai richieste in modalità "il più velocemente possibile". Aggiungi un ritardo casuale da 0.5 a 2 secondi tra le richieste. La casualità è importante: un intervallo fisso (ad esempio, esattamente 1 secondo) appare anch'esso come uno schema automatico. In Python, questo si realizza tramite time.sleep(random.uniform(0.5, 2.0)).
Passo 4. Configura intestazioni di richiesta corrette
Le richieste API a Google Maps devono contenere un User-Agent realistico. Anche se tecnicamente l'API non richiede un User-Agent da browser, la sua assenza o un User-Agent standard di Python aumentano la probabilità di rilevamento. Utilizza un User-Agent che imita un vero browser e non cambiarlo troppo frequentemente all'interno di una singola sessione.
Passo 5. Gestisci errori e tentativi di ripetizione
Implementa una corretta gestione degli stati di risposta. Quando ricevi OVER_QUERY_LIMIT — fai una pausa di 60 secondi e cambia IP. Con REQUEST_DENIED — la chiave è bloccata, passa a quella di riserva. Con ZERO_RESULTS — c'è un problema con l'indirizzo, non con il proxy.
Parsing dei dati aziendali tramite Places API con proxy
Places API è un endpoint significativamente più sensibile rispetto a Geocoding API. Google comprende che l'obiettivo principale delle richieste massicce è la raccolta di dati commerciali, quindi la protezione qui è più rigorosa. Esaminiamo l'approccio corretto per lavorare con esso.
Strategia di raccolta dati tramite Places API
Places API funziona attraverso due metodi principali: Nearby Search (ricerca per coordinate e raggio) e Text Search (ricerca per query testuale). Per coprire un'ampia area viene utilizzato il metodo a griglia — suddivisione della regione in celle sovrapposte, attraversando ciascuna cella con una richiesta.
Una caratteristica chiave: Places API restituisce un massimo di 60 risultati per ogni ricerca (3 pagine da 20). Se ci sono più di 60 oggetti nella zona, è necessario ridurre il raggio di ricerca e aumentare la densità della griglia. Questo aumenta automaticamente il numero di richieste, rendendo la rotazione dei proxy criticamente importante.
Python — richiesta a Places API tramite proxy con paginazione
import requests
import time
import random
def search_places_nearby(lat, lng, radius, place_type, api_key, proxies):
results = []
url = "https://maps.googleapis.com/maps/api/place/nearbysearch/json"
params = {
"location": f"{lat},{lng}",
"radius": radius,
"type": place_type,
"key": api_key,
"language": "it"
}
while True:
response = requests.get(url, params=params, proxies=proxies, timeout=15)
data = response.json()
if data.get("status") == "OVER_QUERY_LIMIT":
print("Limite di richieste — pausa di 60 sec")
time.sleep(60)
continue
results.extend(data.get("results", []))
# Token per la pagina successiva
next_token = data.get("next_page_token")
if not next_token:
break
# Pausa obbligatoria prima della pagina successiva (richiesta da Google)
time.sleep(random.uniform(2.0, 3.5))
params = {"pagetoken": next_token, "key": api_key}
return results
Ottenere dati dettagliati tramite Place Details
Dopo aver ottenuto l'elenco di place_id tramite Nearby Search o Text Search, è necessario effettuare una richiesta separata Place Details per ogni luogo, per ottenere telefono, sito web, orari di apertura e recensioni. Questo raddoppia il numero di richieste. Qui la rotazione degli IP è particolarmente importante: ogni richiesta Place Details è meglio farla da un nuovo indirizzo del pool.
Richiedi solo i campi necessari tramite il parametro fields. Questo riduce il costo della richiesta e diminuisce il volume dei dati trasmessi, rendendo il modello delle richieste meno sospetto dal punto di vista del volume di traffico.
Rotazione delle chiavi e IP: come organizzare un lavoro stabile
Lavorare professionalmente con Google Maps API richiede non solo proxy, ma un approccio sistemico alla gestione delle chiavi e degli IP. Ecco come appare un'infrastruttura correttamente strutturata.
Pool di chiavi Google Cloud
Crea diversi progetti nella Google Cloud Console — almeno 3-5 per compiti seri. Ogni progetto riceve la propria chiave API. Distribuisci il carico tra le chiavi in modo uniforme: se hai 10.000 richieste al giorno e 5 chiavi, ogni chiave effettua 2.000 richieste — significativamente al di sotto della soglia di sospetto.
Regola importante: collega ogni chiave a un intervallo di IP separato dal tuo pool di proxy. La chiave n. 1 funziona solo tramite IP dell'intervallo A, la chiave n. 2 — tramite l'intervallo B. Mescolare chiavi e IP è uno degli errori principali che porta a blocchi di massa.
Pianificazione delle richieste
Non avviare tutte le richieste di notte o durante l'orario non lavorativo — questo è un modello atipico per un "utente normale". Distribuisci i compiti durante la giornata lavorativa, simulando un'attività naturale. Se il compito consente di essere eseguito su più giorni, è meglio estenderlo su 3-5 giorni con un carico moderato, piuttosto che fare tutto in una notte.
Monitoraggio dello stato delle chiavi
Implementa un monitoraggio automatico degli stati di risposta dell'API. Ai primi segni di limitazioni (aumento degli errori OVER_QUERY_LIMIT) riduci immediatamente la frequenza delle richieste per quella chiave e lasciala "riposare" per alcune ore. Non aspettare il blocco completo — curare è significativamente più difficile che prevenire.
Raccomandazione per l'architettura
Per compiti seri di parsing di Places API, si consiglia di utilizzare una coda di attività (Redis + Celery o simile) con controllo della frequenza delle richieste a livello di worker. Questo consente di controllare con precisione il RPS (richieste al secondo) per ogni chiave e di passare automaticamente a quella di riserva in caso di problemi.
Limiti di Google Maps API e come lavorarci
Comprendere i limiti di Google Maps API è fondamentale per pianificare l'infrastruttura. I limiti sono di due tipi: quote (quante richieste al giorno/mese) e rate limits (quante richieste al secondo). I proxy aiutano con entrambi i tipi se utilizzati correttamente.
| API | Quota gratuita | Rate Limit | Prezzo oltre il limite |
|---|---|---|---|
| Geocoding API | $200/mese (~40.000 richieste) | 50 QPS | $5 per 1.000 |
| Places API (Nearby Search) | $200/mese (~6.600 richieste) | 100 QPS | $32 per 1.000 |
| Places API (Place Details) | $200/mese (~3.400 richieste) | 100 QPS | $17–$32 per 1.000 |
| Distance Matrix API | $200/mese (~40.000 elementi) | 1.000 QPM | $5 per 1.000 |
Nota: i limiti sono legati alla chiave, non all'IP. Per questo motivo, la rotazione delle chiavi insieme alla rotazione degli IP è l'unico modo per scalare il lavoro senza aumentare i costi dell'API. Diverse chiavi con una quota gratuita di $200 ciascuna consentono di aumentare significativamente il volume totale di richieste gratuite.
Come i proxy aiutano con i rate limits
Un rate limit di 50 QPS per Geocoding API significa: non più di 50 richieste al secondo da una singola chiave. I proxy non aiutano a superare questo limite — è legato alla chiave. Ma aiutano a distribuire il carico tra le chiavi in modo che ciascuna chiave rimanga nella zona sicura (si consiglia di non superare il 70-80% del rate limit massimo).
Errori comuni e come evitarli
Negli anni di lavoro con Google Maps API si è formato un elenco di errori tipici che portano alla perdita delle chiavi. Esaminiamo ciascuno e forniamo una soluzione concreta.
Errore 1: Utilizzo di un solo IP per più chiavi
Questo è l'errore più comune. Se ruoti le chiavi, ma tutte le richieste provengono da un solo proxy o da un piccolo pool di IP — Google vede che da un singolo indirizzo vengono utilizzate chiavi diverse e le collega in un'unica sessione. Quando una chiave viene bloccata, tutte le altre sono a rischio.
Soluzione: Separa rigorosamente i pool di IP per chiavi. Ogni chiave funziona solo tramite il proprio intervallo di indirizzi dedicati.
Errore 2: Ignorare la pausa obbligatoria tra le pagine di Places API
Places API richiede una pausa di almeno 2 secondi prima di richiedere la pagina successiva tramite pagetoken. Se richiedi la pagina successiva immediatamente, l'API restituirà un risultato vuoto o un errore. Molti sviluppatori ignorano questo requisito e ottengono dati errati.
Soluzione: Aggiungi sempre una pausa di 2-3 secondi prima di richiedere la pagina successiva. Questo è un requisito documentato da Google, non una raccomandazione opzionale.
Errore 3: Chiavi non protette nel codice
Le chiavi API di Google Maps che finiscono in repository pubblici su GitHub vengono automaticamente scansionate da bot e utilizzate da malintenzionati. Google rileva automaticamente le perdite di chiavi e invia notifiche, ma il danno può essere causato prima.
Soluzione: Conserva le chiavi in variabili di ambiente o in sistemi di gestione dei segreti (Vault, AWS Secrets Manager). Non hardcodare mai le chiavi nel codice sorgente. Configura restrizioni per IP nella Google Cloud Console — la chiave deve funzionare solo dai tuoi indirizzi proxy.
Errore 4: Richiesta di tutti i campi in Place Details
Per impostazione predefinita, Place Details restituisce tutti i campi disponibili, inclusi quelli costosi (atmosfera, recensioni). Questo aumenta il costo di ogni richiesta di 2-4 volte. Inoltre, un grande volume di risposta rallenta l'elaborazione.
Soluzione: Utilizza sempre il parametro fields e richiedi solo i dati necessari. Ad esempio: fields=name,formatted_phone_number,website,opening_hours,rating.
Errore 5: Utilizzo di proxy gratuiti o pubblici
I proxy gratuiti da elenchi pubblici sono un modo sicuro per perdere la chiave. Tali IP sono già utilizzati da migliaia di altri utenti, molti dei quali fanno esattamente ciò da cui Google si protegge. La reputazione di tali IP è estremamente bassa e Google li blocca preventivamente.
Soluzione: Utilizza solo proxy a pagamento da fornitori affidabili con indirizzi IP puliti e garanzia di utilizzo esclusivo.
Checklist prima del lancio
- ✅ Ogni chiave è collegata a un pool di IP separato
- ✅ Le chiavi sono limitate per IP nella Google Cloud Console
- ✅ Ci sono ritardi casuali tra le richieste (0.5–2 sec)
- ✅ È stata implementata la gestione di tutti gli stati di errore API
- ✅ Le chiavi sono conservate in variabili di ambiente, non nel codice
- ✅ È stato configurato il monitoraggio delle quote nella Google Cloud Console
- ✅ Vengono utilizzati solo i campi necessari nelle richieste
Conclusione
Lavorare con Google Maps API su larga scala è sempre un equilibrio tra la velocità di raccolta dei dati e la sicurezza delle chiavi. I proxy risolvono il problema dei blocchi per IP, ma non sostituiscono un'architettura intelligente: rotazione delle chiavi, controllo della frequenza delle richieste, gestione corretta degli errori e separazione dei pool di IP per compiti.
Le principali conclusioni dell'articolo: i proxy residenziali con rotazione sono adatti per la maggior parte dei compiti con Places API e geocoding; ogni chiave deve funzionare tramite il proprio pool di indirizzi isolati; i ritardi tra le richieste sono obbligatori; il monitoraggio dello stato delle chiavi deve essere automatizzato.
Se prevedi di lavorare regolarmente con Google Maps API — geocodificare indirizzi, raccogliere dati su aziende o monitorare concorrenti — ti consigliamo di prestare attenzione ai proxy residenziali. Offrono un alto livello di fiducia da parte di Google e un rischio minimo di blocco delle chiavi con una corretta rotazione degli IP. Per compiti in cui è necessaria la massima affidabilità senza interruzioni, considera i proxy mobili — i loro IP non vengono praticamente mai bloccati anche con alta attività.