Términos Google Places API: scraping, caché y storage

Sobre el tema del scraping Google es directo: los Términos de servicio de Google Maps Platform establecen que los clientes no deben "exportar, extraer o de otro modo hacer scraping del contenido de Google Maps para usos externos a los Servicios" (en el texto original: "export, extract, or otherwise scrape Google Maps Content for use outside the Services"), y el caching está prohibido salvo donde los Service Specific Terms lo permitan expresamente. Dos excepciones prácticas que conocer: los place IDs pueden conservarse sin límite de tiempo, y las coordenadas de los lugares pueden mantenerse en caché hasta 30 días naturales consecutivos. Todo lo demás - nombres, valoraciones, reseñas, fotos, números de teléfono - debe solicitarse en tiempo real y mostrarse con la atribución de Google Maps, no archivarse.

Esta guía repasa lo que los términos y las políticas oficiales dicen de verdad, sección por sección, con los enlaces a los documentos de Google para poder verificar cada afirmación. Está pensada para desarrolladores que deben elegir entre la API Places oficial, un scraper de Google Maps y una API de datos de empresas con licencia - tres vías con posturas contractuales muy diferentes. No es asesoramiento legal; leed siempre los documentos vigentes, porque Google los actualiza.

Las reglas en síntesis

Verificado en julio de 2026 sobre los términos oficiales de Maps Platform, los Service Specific Terms y las políticas de la API Places. Google revisa estos documentos; comprobad el texto vigente antes de construir.

La cláusula anti-scraping, en palabras simples

La restricción central está en los Términos de servicio de Google Maps Platform, entre las restricciones de licencia (sección 3.2.3 en la numeración actual). El cliente se compromete a no exportar, extraer o de otro modo hacer scraping del contenido de Google Maps para usos externos a los servicios. El "contenido de Google Maps" se define de forma amplia: cubre los datos devueltos por la plataforma, incluidas fichas, reseñas, fotos y otros contenidos visibles en Google Maps.

De esta formulación siguen dos consecuencias:

1. Cargar páginas de Google Maps con un navegador headless y hacer el parsing del HTML es exactamente el comportamiento descrito por la cláusula, ya sea que gestionéis vosotros el navegador o alquiléis un actor de scraping alojado. La herramienta no cambia la postura contractual.
2. Incluso los datos obtenidos mediante la API Places oficial siguen siendo contenido de Google Maps. Pagar las llamadas API no os autoriza a extraerlos en un dataset autónomo vuestro - es precisamente lo que la cláusula de caching de abajo delimita.

Si estáis evaluando los compromisos prácticos (no solo contractuales) entre scraping y API oficial, la comparativa completa está en Alternativa a Google Places API: datos en JSON.

Qué podéis mantener en caché y guardar

La misma sección de los términos prohíbe el caching del contenido de Google Maps "salvo lo expresamente permitido" - y los permisos expresos viven en los Service Specific Terms y en la página de políticas de la API Places. A julio de 2026 las excepciones que importan para Places son dos:

• Place IDs: conservables sin límites. Las políticas Places de Google establecen que el place ID, que identifica un lugar de forma única, está exento de las restricciones de caching. Es la forma soportada de "recordar" un lugar: conservad el ID y solicitad detalles frescos cuando debáis mostrarlos.
• Coordenadas: caché hasta 30 días. Los Service Specific Terms permiten mantener temporalmente en caché las latitudes/longitudes Places durante no más de 30 días naturales consecutivos, tras los cuales deben borrarse.

Todo lo demás - nombres mostrados, direcciones formateadas, valoraciones, reseñas, horarios, fotos, números de teléfono, URL de los sitios - cae en la regla general: solicitad en tiempo real, mostrad, no archivéis. Por eso "llamar a Place Details para cada empresa de la ciudad y guardar las filas" no es una estrategia de base de datos conforme, aunque cada llamada API individual sea legítima.

Atribución: la parte que la mayoría de las integraciones olvida

Las políticas de la API Places fijan también reglas de visualización para los datos solicitados:

• Mostrad la atribución Google Maps dondequiera que aparezcan datos Places. Google prefiere el logo Google Maps; donde falte el espacio, el texto "Google Maps" es aceptable.
• Acreditad al autor cuando mostréis contenidos generados por los usuarios como reseñas y fotos. Para las reseñas en layouts estrechos, el avatar del autor es el mínimo documentado.

Si vuestra interfaz muestra datos Places sin atribución, es una violación de las políticas incluso cuando sourcing y caching son por lo demás limpios.

Entonces, ¿qué vía es de verdad conforme?

Un scraper de páginas no lo es. Los crawlers Playwright caseros y los actors "Google Maps scraper" alojados extraen ambos contenido de Google Maps para usos externos a los servicios - exactamente lo que la cláusula anti-scraping prohíbe. La guía del Google Maps Scraper explica qué significa a nivel operativo (CAPTCHA, proxies, selectores que se rompen), además de la exposición contractual.

La API Places oficial es conforme para la tarea para la que nació: búsqueda y visualización de lugares en tiempo real en vuestro producto, con field masks, atribución y ninguna conservación a largo plazo más allá de los place IDs. Su límite son los datos que el objeto Place sencillamente no contiene - el primero de todos, la dirección de email de las empresas, que ninguna SKU Places devuelve.

Una API de datos de empresas con licencia recorre una tercera vía. biz collect efectúa la búsqueda mediante la búsqueda oficial de Google Places, mantiene el modelo de los identificadores duraderos y luego enriquece cada registro desde el sitio web público de la empresa - emails, perfiles sociales y otros campos de contacto provienen del sitio de la empresa, no del contenido de Google Maps. El crawler de enriquecimiento respeta robots.txt en el modo respetuoso predeterminado, y los límites están publicados en la acceptable use policy y en la visión general de seguridad.

Situaciones típicas, respuestas claras

"Quiero una base de datos de todos los dentistas de mi región." Construirla guardando respuestas de la API Places choca con la cláusula de caching, y hacer scraping de las páginas Maps choca con la cláusula anti-scraping. Las opciones conformes son los proveedores de datos con licencia o un modelo de enriquecimiento como el descrito arriba.

"Quiero mostrar las cafeterías cercanas en mi app." Es exactamente la tarea de la API Places. Solicitad en tiempo real, mostrad con atribución, conservad solo los place IDs.

"Ya hice scraping de Google Maps para un informe puntual." Los términos no distinguen las actividades puntuales, así que entended el riesgo corrido: la aplicación de los términos se traduce normalmente en claves o cuentas bloqueadas más que en demandas inmediatas, pero una dependencia de producción del scraping es un riesgo de empresa, no solo legal.

"Mi proveedor de scraper dice que está bien." Quien vende scrapers de Google Maps describe la capacidad de su propia herramienta, no vuestro permiso. Los términos vinculan a la parte que extrae los contenidos - leedlos vosotros mismos.

En conclusión

Los documentos oficiales son breves y merecen una lectura directa: los Términos de servicio de Google Maps Platform, los Service Specific Terms y las políticas de la API Places. El cuadro que emerge: usad Places en tiempo real para la visualización, conservad los place IDs, mantened brevemente en caché las coordenadas, atribuid todo, y no hagáis scraping ni archivo del contenido de Google Maps.

Cuando el trabajo requiere datos de negocios locales estructurados y conservables - enriquecimiento CRM, investigación de leads, agentes IA -, elegid una vía construida para eso. La comparativa Alternativa a Google Places API guía la decisión, y la guía de las business data API explica cómo evaluar a los proveedores.