Hace unos meses, un desarrollador en Stack Overflow publicó una pregunta que sigue abierta desde 2012: "Google Places API Place Details limitado a 5 reseñas?" Catorce años, cientos de votos positivos y la respuesta sigue siendo la misma: sí, máximo cinco reseñas. Esa sola limitación ya deja claro por qué este debate sigue tan vivo.
Si alguna vez has necesitado datos de Google Places a gran escala — listas de leads, reseñas de competidores, patrones de afluencia, auditorías de SEO local — seguro que te has topado con el mismo cruce de caminos. La API oficial de Google Places es limpia, estructurada y está muy bien documentada. Pero no devuelve todo lo que ves en una página de Google Maps, y la factura puede dispararse cuando te pasas del nivel gratuito. El scraping captura más, tiene una estructura de costes distinta y también sus propios dolores de cabeza (CAPTCHAs, selectores rotos, zonas grises legales). Me he pasado bastante tiempo analizando ambos lados — la documentación de la API, los precios por SKU, la cadena de herramientas de scraping y los compromisos reales en producción — y este artículo es el resultado. Vamos a revisar las lagunas de datos campo por campo, los costes reales con 10K/100K/1M registros, la realidad anti-bots y una estrategia híbrida práctica. Además, te dejo un flujo de decisión, porque nadie quiere leer 3.000 palabras y seguir sin saber qué escoger.
¿Qué es la Google Places API y qué te da realmente?
La Google Places API es la vía oficial y estructurada de Google para sacar datos de negocios — nombres, direcciones, teléfonos, valoraciones, reseñas, fotos — desde su base de datos. Haces una petición HTTP y recibes JSON ya formateado. Es el canal autorizado.
La versión actual (Places API "New") organiza todo alrededor de field masks. Cuando llamas a Place Details, indicas exactamente qué campos quieres — displayName, formattedAddress, rating, reviews, photos, etc. — y Google te cobra según el nivel más alto del campo solicitado. Si no incluyes la field mask, te devuelve un error, no una respuesta por defecto. Está hecho así a propósito: Google quiere que pagues solo por lo que usas, y que pagues más por lo más valioso.
Los campos disponibles se agrupan en niveles de precio:
| Nivel | Campos de ejemplo | Qué obtienes |
|---|---|---|
| Essentials | Place ID, dirección formateada, ubicación, metadatos de fotos | Identidad y ubicación básicas |
| Pro | Nombre mostrado, estado del negocio, URI de Google Maps, tipo principal | Información empresarial más completa |
| Enterprise | Valoración, número de reseñas, web, teléfonos, horario, nivel de precio | Los campos que más suele buscar la gente de negocio |
| Enterprise + Atmosphere | Reseñas, resumen de reseñas, resumen generativo, servicios, aparcamiento, para llevar/envío | Los datos más completos (y más caros) |
Los endpoints más útiles para la mayoría son: Autocomplete (búsqueda mientras escribes), Text Search y Nearby Search (para descubrir lugares), Place Details (para enriquecer un lugar ya conocido) y Place Photos (para imágenes).
Ahora, las limitaciones que de verdad importan:
- Reseñas: el recurso Place devuelve un máximo de 5 reseñas por lugar, ordenadas por relevancia. Y punto. No 50, no "todas". Cinco.
- Fotos: limitado a 10 referencias de foto por lugar en el recurso Place.
- Popular times / afluencia en vivo: no existe como campo estándar en Places API. Google confirma que esos datos existen en superficies de consumo (basados en Location History agregada y anonimizada), y su blog de Maps explica cómo funciona — pero la lista de campos no lo incluye.
- Sección de preguntas y respuestas: no está expuesta.
- Competidores tipo "las personas también buscan": no está expuesto.
- Menú / lista de precios: no es un campo estándar.
¿Quién suele usar la Google Places API?
- Empresas de logística que validan y geocodifican direcciones
- Apps de viajes y hostelería que muestran hoteles, restaurantes y atracciones cercanas
- Plataformas inmobiliarias que enriquecen anuncios con datos de negocios locales
- Agencias de SEO local que auditan la consistencia de NAP (nombre, dirección, teléfono)
- Equipos de ventas que construyen listas de leads a partir de Place IDs e información básica de negocio
Si tu caso encaja bien con "necesito datos estructurados de lugares en una app de producción", la API es el punto de partida correcto. Si tu caso incluye palabras como "todas las reseñas", "popular times" o "análisis de competidores", sigue leyendo.
¿Qué significa "scrapear" datos de Google Places?
Web scraping significa usar software para extraer automáticamente datos de una página web — en este caso, Google Maps o resultados de Google Search — en vez de pasar por una API oficial. El scraper lee la página igual que lo haría tu navegador y luego extrae las partes estructuradas: nombres de negocios, direcciones, texto de reseñas, estrellas, histogramas de popular times, Q&A, sugerencias de competidores, la galería completa de fotos y cualquier otra cosa que aparezca en pantalla.
La diferencia clave: la API te da lo que Google decide exponer. El scraping te da, en teoría, todo lo que una persona puede ver en la página.
Aun así, "scraping" no es una sola cosa. Hay tres enfoques muy distintos, y las diferencias entre ellos importan bastante.
Scripts DIY vs. APIs de scraping gestionadas vs. herramientas no-code
| Enfoque | Cómo funciona | Mejor para | Principal sacrificio |
|---|---|---|---|
| Scripts DIY (Puppeteer, Playwright, Selenium) | Escribes y mantienes un script con navegador headless que navega por Google Maps y analiza el DOM | Desarrolladores que necesitan control total y lógica personalizada | Máxima carga de mantenimiento — los selectores se rompen cuando Google cambia la interfaz |
| APIs de scraping gestionadas (Thunderbit API, SerpApi, Outscraper) | Envías una URL o consulta a una API; esta se encarga del renderizado, anti-bot y parsing, y devuelve datos estructurados | Desarrolladores que quieren salida estructurada sin mantener scrapers | El precio y la calidad varían según el proveedor; dependes de un tercero |
| Extensiones de navegador no-code (Thunderbit Chrome Extension) | Extracción con clics desde el navegador: la IA sugiere campos, haces clic en "Scrape" y exportas a Sheets/Excel | Usuarios de negocio, marketing, ventas que necesitan datos rápido en una hoja de cálculo | Menos flexible para pipelines complejos; depende de la calidad de la IA de la herramienta |
Versión corta: DIY = más flexible, pero más mantenimiento. APIs gestionadas = salida estructurada, sin mantenimiento. Herramientas no-code = lo más rápido para no programadores.
Google Places API vs scraping: comparación campo por campo
Esta es la tabla que me habría gustado tener cuando empecé a investigar este tema. Cada campo que podría necesitar un usuario de negocio o un desarrollador, comparado lado a lado:
| Campo de datos | Google Places API | Web Scraping |
|---|---|---|
| Nombre del negocio | ✅ Completo (nivel Pro) | ✅ Completo |
| Dirección / ubicación | ✅ Completo (nivel Essentials) | ✅ Completo |
| Número de teléfono | ✅ Nivel Enterprise | ✅ Cuando está visible |
| URL del sitio web | ✅ Nivel Enterprise | ✅ Cuando está visible |
| Valoración media | ✅ Nivel Enterprise | ✅ Completa |
| Número de valoraciones | ✅ Nivel Enterprise | ✅ Completo |
| Reseñas individuales (texto + valoración) | ⚠️ Máximo 5 reseñas | ✅ Todas las reseñas disponibles |
| Popular times / afluencia en vivo | ❌ No es un campo estándar de la API | ✅ Extraíble (cuando se renderiza) |
| Sección de preguntas y respuestas | ❌ No expuesto | ✅ Extraíble |
| Metadatos de fotos | ✅ Máximo 10 referencias vía el endpoint de fotos | ✅ Galería completa |
| Menú / lista de precios | ❌ No es un campo estándar | ⚠️ Cuando aparece en la página |
| "Las personas también buscan" (competidores) | ❌ No expuesto | ✅ Extraíble |
| Horario de apertura | ✅ Nivel Enterprise | ✅ Cuando está visible |
| Nivel de precio | ✅ Nivel Enterprise | ✅ Cuando está visible |
| Place ID | ✅ Muy sólido (Essentials) | ⚠️ Posible, pero la API es la fuente canónica |
| URI de Google Maps | ✅ Nivel Pro | ✅ Es la URL de la página |
| Respuestas del propietario a las reseñas | ⚠️ Conviene verificar la disponibilidad actual | ✅ A menudo visible |
| Posición en SERP / map pack | ❌ No es el propósito de la API | ✅ Mediante scraping de SERP |
La gran diferencia está en esto: si necesitas el conjunto completo de reseñas para análisis de sentimiento, seguimiento de reputación o benchmarking competitivo, la API por sí sola no te sirve. Cinco reseñas por lugar es una muestra, no un dataset.
¿Popular times y patrones de afluencia? Lo mismo. Si eres consultor retail o analista inmobiliario comercial, el scraping es el único camino: ese dato simplemente no está en la API.
En cambio, para Place IDs canónicos, direcciones estructuradas para geocodificación o para alimentar un localizador de tiendas, la API es más limpia, más fiable y está oficialmente soportada.
El coste real: Google Places API vs scraping con 10K, 100K y 1M de registros
El coste es la parte peor entendida de esta decisión. Mucha gente se registra en el nivel gratuito de la API, monta un prototipo y luego recibe una factura que duele cuando escala. En scraping, la gente suele subestimar el coste de proxies y el tiempo de desarrollo.
Vamos con los números.
Desglose de precios de Google Places API
Google renovó la estructura de precios de Maps Platform en marzo de 2025, sustituyendo el antiguo crédito mensual fijo de $200 por límites gratuitos por SKU y tramos de volumen. El precio actual funciona así:
- Campos Essentials (Place Details): 10.000 solicitudes gratis al mes, luego 5,00 $ por 1.000 hasta 100K
- Campos Pro (Place Details): 5.000 gratis, luego 7,00 $/1K
- Campos Enterprise (Place Details): 1.000 gratis, luego 20,00 $/1K
- Enterprise + Atmosphere (reseñas, servicios): 1.000 gratis, luego 25,00 $/1K
Detalle clave: si tu field mask incluye incluso un solo campo de Enterprise + Atmosphere (como reviews), toda la solicitud se factura en ese nivel. Y un flujo típico encadena varios SKUs — Text Search Pro para descubrir lugares, luego Place Details Enterprise + Atmosphere para enriquecerlos — así que los costes se acumulan.
Una sola "consulta" rara vez es una sola solicitud facturable.
Costes de scraping: herramientas, proxies y tiempo de desarrollo
Los costes del scraping se dividen en tres bloques:
- Suscripción de herramienta o créditos de API: las APIs de scraping gestionadas cobran por solicitud, por crédito o por registro. SerpApi cobra por búsqueda. Outscraper usa pago por uso por registro. La API de Thunderbit usa un sistema de créditos (Extract = 20 créditos por solicitud). La extensión de Chrome de Thunderbit cobra 1 crédito por fila de salida.
- Gasto en proxies (solo DIY): los proxies residenciales para scraping de Google Maps suelen costar entre 50 y 300 $ al mes, según volumen y proveedor.
- Tiempo de desarrollo (solo DIY): construir y mantener scripts de Puppeteer/Playwright. Este es el coste oculto que suele matar la economía del DIY (más abajo lo explico).
Tabla de costes lado a lado: API vs scraping a escala
| Escala | Google Places API (Enterprise + Atmosphere) | API de scraping gestionada (est.) | Scraping DIY (proxy + tiempo de dev) |
|---|---|---|---|
| 10K registros/mes | ~225 $ (1K gratis, 9K × 25 $/1K) | ~50–150 $ según proveedor | ~50 $ en proxies + 2–4 horas de desarrollo/mes |
| 100K registros/mes | ~2.475 $ (tras el límite gratuito se aplican tramos por volumen) | ~250–500 $ | ~150 $ en proxies + 8–16 horas de desarrollo/mes |
| 1M registros/mes | ~17.975 $ (los tramos por volumen reducen el coste unitario, pero el total sigue siendo alto) | ~1.500–3.000 $ | ~300 $ en proxies + 20+ horas de desarrollo/mes + riesgo de roturas |
Notas: las estimaciones de la API usan los tramos de volumen publicados para Place Details Enterprise + Atmosphere, aplicados después del límite gratuito de 1K. Las estimaciones de las APIs de scraping gestionadas son rangos aproximados entre proveedores. El tiempo de desarrollo DIY asume un coste cargado de 50–100 $/hora.
El patrón es claro: a pequeña escala (menos de 10K), los topes gratuitos de la API pueden convertirla en la opción más barata, especialmente si solo necesitas campos Essentials o Pro. A escala de negocio (100K+), el coste de la API sube con fuerza, sobre todo para campos ricos. A escala empresarial (1M+), la API puede acercarse a cinco cifras al mes, y el scraping o los servicios de datasets se vuelven económicamente atractivos — siempre que realmente necesites los campos extra que la API no expone.
Si solo necesitas direcciones y Place IDs, no hagas scraping. La API es más barata y mejor para eso. El argumento económico del scraping solo se sostiene cuando necesitas datos que la API no puede devolver.
La realidad anti-bot: por qué se rompen los scrapers DIY de Google
Aquí está la parte que los defensores del scraping suelen saltarse. Google no quiere que scrapées Google Maps. Han montado varias capas de defensa y las actualizan con bastante frecuencia.
Las defensas por capas de Google
- Retos reCAPTCHA: los navegadores automatizados activan CAPTCHAs con mucha más frecuencia que los usuarios humanos
- Renderizado JavaScript del lado del cliente: Google Maps es una aplicación pesada en JavaScript. Una simple petición HTTP no te entrega el contenido renderizado; necesitas un navegador headless completo
- Fingerprinting del navegador: Google detecta navegadores headless mediante fingerprints de canvas, WebGL, propiedades de navigator y otras señales
- Limitación por IP: demasiadas peticiones desde la misma IP (o la misma subred de proxy) y te bloquean
- Cambios en la estructura del DOM: Google cambia con regularidad la estructura de sus páginas — el consenso en Reddit y en issues de GitHub es que los selectores se rompen cada pocas semanas o meses
Ese último punto es el asesino silencioso. Un script de Puppeteer que funcionaba perfecto en junio puede devolverte resultados en blanco en julio porque Google renombró una clase CSS o reestructuró un div.
El coste oculto de mantener scripts DIY
Cada vez que Google cambia su DOM, alguien de tu equipo tiene que:
- Darse cuenta de que el scraper se ha roto (idealmente antes de que se propaguen datos incorrectos)
- Inspeccionar la nueva estructura de la página
- Actualizar selectores, manejar nuevos tipos de CAPTCHA, ajustar la lógica de reintentos
- Probar y desplegar de nuevo
A lo largo de un año, este tiempo de mantenimiento puede superar fácilmente el coste de suscripción de una API de scraping gestionada. He visto equipos gastar más de 40 horas de desarrollo al año solo en mantener vivo un scraper de Google Maps — y esa es una estimación conservadora para una configuración moderadamente compleja.
Por qué existen las APIs de scraping gestionadas
Precisamente por esta carga de mantenimiento existen servicios como Thunderbit API, SerpApi y Outscraper. Absorben la complejidad anti-bot — renderizado JS, resolución de CAPTCHAs, rotación de proxies, mantenimiento de selectores — y devuelven datos estructurados.
El endpoint POST /extract de Thunderbit, con renderMode: "full", gestiona páginas pesadas en JavaScript como Google Maps y devuelve JSON estructurado que encaja con el esquema, no HTML en bruto que todavía haya que parsear. El servidor MCP amplía esto a agentes de IA: Claude, Cursor u otros flujos basados en LLM pueden scrapear datos de Google Maps en mitad de una tarea sin salir de su entorno.
Para usuarios no técnicos, la Thunderbit Chrome Extension es la opción sin mantenimiento: abre una página de Google Maps, haz clic en "AI Suggest Fields", haz clic en "Scrape" y exporta a Sheets. Sin selectores, sin proxies, sin depuración.
SerpApi y Outscraper son alternativas sólidas con modelos de precios y formatos de salida distintos. SerpApi devuelve JSON estructurado por búsqueda; Outscraper cobra por registro con pago por uso. La elección correcta depende de tu volumen, tu presupuesto y de si necesitas JSON estructurado o te sientes cómodo analizando una salida semiestructurada.
La estrategia híbrida: usar Google Places API y scraping juntos
Ninguno de los artículos mejor posicionados sobre este tema sugiere lo que yo he visto que mejor funciona en la práctica: usar ambas cosas. Muchos equipos acaban apoyándose en la API oficial para unas tareas y en scraping para otras. La clave está en asignar a cada herramienta el trabajo correcto.
Cuándo gana la API oficial
- Autocomplete en una app de producción en tiempo real: baja latencia, compatible con los Términos de Servicio, SLA fiable. No hay discusión aquí.
- Backends de apps basadas en ubicación: localizadores de tiendas, validación de direcciones, coincidencia de Place IDs. La API es estructurada, soportada y documentada.
- Integraciones sensibles al cumplimiento: contratos enterprise, productos de cara al público o cualquier contexto en el que cumplir los Términos de Servicio de Google sea innegociable.
Cuándo gana el scraping
- Extracción completa de reseñas (5K+ reseñas por lugar): análisis de sentimiento, monitorización de reputación, benchmarking competitivo. El límite de 5 reseñas de la API lo vuelve inútil aquí.
- Extracción puntual de listas de leads: más barato para trabajos por lotes sin facturación continua. Una herramienta no-code como Thunderbit puede extraer una lista de negocios y exportarla a una hoja de cálculo en minutos.
- Análisis de popular times / afluencia: no está disponible vía API. Sin más.
- Datos de Q&A y "las personas también buscan" de competidores: solo visibles en la página, no en la API.
Cuándo tiene sentido un enfoque híbrido
- Monitorización continua de precios/valoraciones: usa la API para datos estructurados básicos (Place ID, dirección, valoración media) y luego scrapéa los campos profundos que la API no cubre (reseñas completas, popular times).
- Flujos de enriquecimiento: usa la API para obtener Place IDs e información canónica del negocio, y luego scrapéa fichas individuales para conjuntos completos de reseñas, Q&A y contexto de competidores.
- Monitorización programada: el scraper programado de Thunderbit (para usuarios no-code) o la extracción por lotes vía CLI con cron (para desarrolladores) puede gestionar scraping recurrente sin infraestructura a medida.
Matriz de decisión por caso de uso
| Caso de uso | Método recomendado | Por qué |
|---|---|---|
| Autocomplete en una app en vivo | ✅ API oficial | Baja latencia, compatible con Términos, fiable |
| Obtener 5K+ conjuntos completos de reseñas | ✅ Scraping / API de scraping | La API se limita a 5 reseñas por lugar |
| Lista puntual de leads de negocios locales | ✅ Scraping (o extensión de Thunderbit) | Más barato para trabajos por lotes; sin facturación continua |
| Análisis de popular times / afluencia | ✅ Solo scraping | No disponible vía API |
| Monitorización continua de precios/valoraciones | ⚠️ Híbrido | API para datos básicos, scraping para campos profundos |
| Backend de una app basada en ubicación | ✅ API oficial | Estructurada, soportada, con SLA |
| Seguimiento de posición en SERP para SEO local | ✅ Scraping / SERP API | No es el objetivo de Places API |
| "Las personas también buscan" de competidores | ✅ Solo scraping | No expuesto vía API |
Flujo de decisión: Google Places API vs scraping — ¿cuál deberías escoger?
En lugar de un vago "depende", aquí tienes un marco concreto. Recorre estas cuatro preguntas:
1. ¿Necesitas datos en tiempo real en una app de producción? → Sí: usa la API oficial. Está soportada, tiene SLA y cumple los Términos de Servicio. Detente aquí. → No: continúa.
2. ¿Necesitas datos que la API no devuelve (reseñas completas, popular times, Q&A)? → Sí: el scraping es obligatorio. La API literalmente no puede darte esos datos. → No: continúa.
3. ¿Cuántos registros al mes? → Menos de 10K: la API probablemente sea la opción más barata, sobre todo si solo necesitas campos Essentials o Pro. Los topes gratuitos cubren mucho a esta escala. → Más de 10K: el scraping o una API de scraping gestionada probablemente sea más económico, especialmente para campos ricos.
4. ¿Tienes recursos de desarrollo para construir y mantener scrapers? → Sí: DIY con Puppeteer/Playwright te da el máximo control (pero reserva presupuesto para mantenimiento continuo). → No: usa una API de scraping gestionada (Thunderbit API, SerpApi, Outscraper) o una herramienta no-code (Thunderbit Chrome Extension).
Comparativa rápida de alternativas orientadas a desarrolladores
| Herramienta | Modelo de precios | Formato de salida | Gestiona anti-bot | Soporte por lotes |
|---|---|---|---|---|
| Thunderbit API / MCP | Basado en créditos (Extract = 20 créditos/solicitud) | JSON estructurado que encaja con el esquema | ✅ Renderizado JS, rotación de proxies, geo-routing | ✅ Hasta 100 URLs por lote |
| SerpApi | Por búsqueda (planes escalonados) | JSON estructurado | ✅ | ✅ Mediante parámetros de API |
| Outscraper | Por registro (pago por uso) | JSON / CSV | ✅ | ✅ Mediante colas de tareas |
| DIY (Puppeteer/Playwright) | Proxies + tiempo de desarrollo | HTML en bruto (tú lo analizas) | ❌ Lo gestionas tú | ✅ Lo que construyas |
El diferenciador de la API de Thunderbit: devuelve JSON estructurado que encaja con el esquema definido por ti en JSON Schema, no HTML o Markdown en bruto que todavía haya que analizar. Si alimentas un pipeline con LLM o cargas una base de datos, eso ahorra tiempo real de posprocesado.
Cómo encaja Thunderbit aquí (para usuarios de negocio y desarrolladores)
Construimos Thunderbit para cerrar la brecha entre "necesito datos de Google Maps" y "no quiero convertirme en ingeniero de infraestructura de scraping". Así funciona para ambos perfiles.
Para usuarios no técnicos: la extensión de Chrome
- Abre una página de Google Maps — una página de resultados o una ficha individual de negocio
- Haz clic en "AI Suggest Fields" — la IA de Thunderbit lee la página y propone columnas (nombre del negocio, dirección, valoración, reseñas, teléfono, etc.)
- Haz clic en "Scrape" — la extensión extrae los datos en una tabla estructurada. Usa el modo cloud para hasta 50 páginas simultáneas
- Scrape subpages — haz clic en "Scrape Subpages" para visitar cada ficha y extraer los detalles completos
- Exporta — a Excel, Google Sheets, Airtable o Notion. Exportación gratuita de datos, sin muro de pago
Para monitorización recurrente — revisiones semanales de valoraciones de competidores, nuevas fichas de negocios — el scraper programado se ejecuta automáticamente con la frecuencia que definas.
Para desarrolladores: API, servidor MCP y CLI
POST /extractcon un JSON Schema: envías una URL de Google Maps, defines los campos que quieres y recibes JSON estructurado. UsarenderMode: "full"para páginas pesadas en JavaScript. Thunderbit se encarga del renderizado, anti-bot, rotación de proxies y geo-routing.POST /distill: obtiene Markdown limpio de cualquier página — útil para pipelines de LLM que necesitan contenido bruto en lugar de campos estructurados. 1 crédito por solicitud frente a 20 para Extract.- Servidor MCP: agentes de IA (Claude, Cursor) pueden scrapear datos de Google Maps en mitad del flujo. Soporta distillation, extracción estructurada, sugerencia de campos y trabajos por lotes de hasta 100 URLs.
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsonpara scraping programado o integrado en CI/CD.
Precios por créditos: Extract = 20 créditos por solicitud, Distill = 1 crédito por solicitud. Los créditos de API se cobran por solicitud, no por fila (a diferencia de la extensión, donde 1 crédito = 1 fila de salida). Consulta Thunderbit Pricing para ver los planes actuales.
Consideraciones legales y de Términos de Servicio
Lo mantendré breve y factual, sin tácticas de miedo ni discurso comercial.
La Google Places API viene con términos claros: los términos específicos del servicio de Google indican que el contenido de Places API puede usarse sin un mapa de Google, pero no debe utilizarse con un mapa que no sea de Google. Los valores de latitud/longitud pueden almacenarse en caché hasta 30 días naturales consecutivos; los Place IDs pueden almacenarse indefinidamente. La atribución es obligatoria para detalles, fotos y reseñas.
Scrapear Google Maps puede violar los Términos de Servicio de Google. La aplicación varía: los riesgos incluyen bloqueos de IP, muros de CAPTCHA y, en casos raros, acciones legales. Las APIs de scraping gestionadas suelen asumir parte de la carga de cumplimiento en nombre de los usuarios, pero eso no constituye protección legal.
Para apps de producción orientadas al usuario final, la API oficial es la opción más segura. Para investigación interna, análisis por lotes e inteligencia competitiva, el scraping es una práctica habitual en la industria. Consulta con tu propio asesor legal para flujos comerciales.
Qué elegiría yo realmente y por qué
Después de revisar los SKUs de precios, las listas de campos, los hilos de la comunidad y la documentación de herramientas, esta es mi conclusión:
- Usa la API oficial cuando necesites datos en tiempo real, compatibles con los Términos de Servicio, en una app de producción, o cuando los campos Essentials/Pro sean suficientes y tu volumen esté por debajo de 10K/mes. Los límites gratuitos son generosos a pequeña escala y la calidad de los datos es impecable.
- Usa scraping (API gestionada o herramienta no-code) cuando necesites reseñas completas, popular times, Q&A, contexto de competidores o cualquier campo que la API no exponga. También cuando tu volumen supere 10K–100K registros/mes y estés solicitando campos ricos (Enterprise + Atmosphere): la factura de la API se vuelve difícil de justificar.
- Usa ambos cuando tu flujo requiera Place IDs canónicos y datos estructurados básicos (API), más inteligencia profunda visible en la página (scraping). Esto es más común de lo que muchos artículos admiten.
El punto de inflexión en costes: por debajo de ~10K registros/mes con campos básicos, la API es más simple y muchas veces gratuita. Por encima de eso, especialmente para datos ricos, el scraping se vuelve más económico. Con 1M de registros y campos Enterprise + Atmosphere, estás mirando ~18K $ al mes en la API frente a una fracción de eso con un scraper gestionado.
Si quieres probarlo tú mismo, la Thunderbit Chrome Extension es la forma más rápida de ver qué captura el scraping frente a la API. Para flujos de trabajo de desarrollador, la documentación de Thunderbit API tiene todo lo necesario para empezar. Y para leer más sobre web scraping sin programar o AI web scraping en general, hemos cubierto esos temas a fondo en el blog.
Puntos clave
- La Google Places API es la herramienta adecuada para apps de producción, autocomplete y consultas estructuradas de lugares — pero limita las reseñas a 5, las fotos a 10 y no expone popular times, Q&A ni sugerencias de competidores.
- El scraping captura todo lo visible en una página de Google Maps, incluidos conjuntos completos de reseñas y datos de popular times, pero exige gestionar defensas anti-bot o pagar un servicio gestionado.
- Por debajo de 10K registros/mes, los límites gratuitos de la API suelen convertirla en la opción más barata. Por encima de 100K, el scraping o las APIs de scraping gestionadas suelen ser más económicas para datos ricos.
- Los scrapers DIY se rompen con frecuencia por las defensas anti-bot de Google y los cambios en el DOM — calcula 40+ horas de desarrollo al año para mantenimiento, o usa una herramienta gestionada.
- La mejor estrategia real suele ser híbrida: API para IDs canónicos y campos básicos, scraping para la inteligencia profunda que la API no puede devolver.
- Thunderbit cubre ambos lados: una extensión de Chrome para usuarios no-code y una API/servidor MCP con JSON estructurado para desarrolladores.
Preguntas frecuentes
¿Se pueden obtener más de 5 reseñas de Google a través de Places API?
No. La Google Places API limita las reseñas a 5 por lugar, ordenadas por relevancia. Esto ha sido así desde el lanzamiento de la API y no ha cambiado pese a años de peticiones por parte de desarrolladores. Para acceder a todas las reseñas disponibles de un negocio, el scraping (ya sea DIY o mediante una API de scraping gestionada) es la única opción.
¿Es legal scrapear Google Maps?
No existe una respuesta universal de sí o no. Scrapear datos públicamente visibles de Google Maps puede violar los Términos de Servicio de Google, y la aplicación va desde bloqueos de IP hasta, rara vez, acciones legales. Muchas empresas usan scraping para investigación interna e inteligencia competitiva sin problemas. Las APIs de scraping gestionadas absorben parte del riesgo de cumplimiento, pero no son un blindaje legal. Si vas a crear un producto comercial o procesar datos personales, consulta con un abogado.
¿Cuánto cuesta la Google Places API para 100K consultas?
Depende de los campos que pidas. Para Place Details en nivel Essentials, unos 450 $. En nivel Pro, unos 1.615 $. En Enterprise + Atmosphere (que incluye reseñas y servicios), unos 2.475 $. Si tu flujo también necesita Text Search Pro para descubrimiento, suma otros ~3.040 $. Estas estimaciones usan los tramos de volumen publicados por Google y asumen una solicitud facturable por registro después del límite gratuito.
¿Cuál es la diferencia entre una scraping API y una herramienta no-code de scraping?
Una scraping API (como la Open API de Thunderbit) está pensada para desarrolladores que integran scraping en código, pipelines de automatización o flujos con agentes de IA mediante peticiones HTTP. Una herramienta no-code (como la Thunderbit Chrome Extension) permite a usuarios no técnicos señalar, hacer clic y exportar datos desde el navegador sin escribir código. Ambas pueden devolver datos estructurados; la diferencia está en la interfaz y el modelo de integración.
¿Thunderbit funciona en páginas de Google Maps?
Sí. La extensión de Chrome puede scrapear resultados de búsqueda de Google Maps y fichas individuales de negocios — la IA sugiere campos automáticamente, y puedes usar el modo cloud para hasta 50 páginas concurrentes. El endpoint POST /extract de la API, con renderMode: "full", gestiona las páginas renderizadas con JavaScript de Google Maps y devuelve JSON estructurado que encaja con el esquema. El servidor MCP permite que los agentes de IA extraigan datos de Google Maps en mitad del flujo de trabajo.
Más información
