Cómo extraer datos de Google Shopping con proxies

Extraer datos de Google Shopping consiste en recopilar datos estructurados de productos (títulos, precios, vendedores, valoraciones y notas de envío) de los resultados de compras de Google a gran escala. Como esos resultados están muy protegidos y localizados, hacerlo de forma fiable requiere IPs rotativas y una geolocalización correcta en lugar de un único scraper sobre una única conexión.

Esta guía prioriza el código. Recorre las solicitudes geolocalizadas, el enrutamiento a través de proxies específicos por país, el análisis de las tarjetas de producto que Google ofusca deliberadamente, la paginación, los reintentos y la espera ante los límites de tasa, una alternativa con navegador headless que gestiona el diálogo de consentimiento, un modelo de datos limpio con exportación a CSV, un rastreador del historial de precios y una programación de monitorización. También es honesta sobre la realidad de los sistemas antibot, el equilibrio entre un scraper hecho por ti mismo y una API SERP de pago, y dónde se sitúan los límites legales.

DataImpulse es un proveedor de proxies ético que ofrece más de 90 millones de direcciones IP residenciales, móviles y de centro de datos en 195 países. Utiliza un modelo de pago por uso desde 1 dólar por GB con tráfico que no caduca, y se usa para web scraping, verificación de anuncios, monitorización de precios, investigación de mercado y gestión de múltiples cuentas.

¿Qué datos puedes extraer de Google Shopping?

Google Shopping muestra fichas de productos con varios campos estructurados que resultan útiles para la fijación de precios y la investigación de mercado. Cada resultado suele incluir un conjunto coherente de atributos que puedes extraer y normalizar en filas.

• Detalles del producto: título, fragmento de descripción, marca, modelo y URL de la imagen del producto.
• Precio: el precio indicado, la moneda y, a veces, un rango de precios entre vendedores.
• Vendedor: el nombre del comerciante y, en la página de detalle del producto, una lista de vendedores competidores que ofrecen el mismo artículo.
• Valoraciones y reseñas: la valoración media con estrellas y el número de reseñas cuando están presentes.
• Disponibilidad y envío: el estado de existencias y las notas de envío que varían según la región.

Los campos exactos cambian cada vez que Google actualiza su diseño, así que cualquier analizador debe tolerar valores faltantes y marcado cambiante. Trata cada campo como opcional y valida los tipos después de la extracción en lugar de suponer que siempre hay una valoración o un vendedor. Como el mismo producto puede aparecer a precios diferentes en países diferentes, planifica tu esquema en torno a una clave (producto, país, marca de tiempo) desde el principio en lugar de añadir la geografía más tarde.

¿Cómo se envía una solicitud geolocalizada a Google Shopping?

Envías una solicitud geolocalizada llamando al endpoint de búsqueda de Google con el indicador de la pestaña de compras más los parámetros de configuración regional, y luego enviando las mismas señales de IP y parámetros que enviaría un comprador real. Los dos parámetros que más importan son gl (el país, por ejemplo gl=de para Alemania) y hl (el idioma de la interfaz, por ejemplo hl=de). Un tercero útil es un término de tipo location que integras en el contexto de la consulta, pero gl junto con una IP de salida que coincida hace la mayor parte del trabajo.

Definir solo los parámetros no basta, porque Google también lee la IP de la solicitud para decidir qué precios y vendedores mostrar. La solicitud mínima siguiente envía encabezados realistas y el par de configuración regional. Está deliberadamente sin proxy para que puedas ver la llamada base antes de añadir una capa de IP.

import requests

def build_params(query, country="us", lang="en", start=0):
    return {
        "q": query,
        "tbm": "shop",   # shopping vertical
        "gl": country,    # country bias, e.g. de, gb, fr
        "hl": lang,       # interface language
        "num": 40,        # results per page (soft cap)
        "start": start,   # pagination offset
    }

HEADERS = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    ),
    "Accept-Language": "en-US,en;q=0.9",
}

resp = requests.get(
    "https://www.google.com/search",
    params=build_params("wireless headphones", country="us", lang="en"),
    headers=HEADERS,
    timeout=30,
)
print(resp.status_code, len(resp.text))

Mantén el encabezado Accept-Language alineado con hl. Una página de precios alemana solicitada con un encabezado de idioma inglés es una incoherencia que parece poco natural y puede devolver la moneda equivocada. Cuando escalas, esta función base se convierte en el único lugar donde se decide la configuración regional, lo que mantiene coherente cada llamada posterior.

¿Cómo se enrutan las solicitudes a través de proxies segmentados por país?

Enrutas a través de un proxy segmentado por país apuntando requests a una única puerta de enlace y codificando el país de destino en el nombre de usuario del proxy. Con DataImpulse la puerta de enlace es gw.dataimpulse.com:823, y añadir __cr.us o __cr.de a tu nombre de usuario selecciona el país de salida. La segmentación por país está incluida en el precio base, mientras que la segmentación por estado, ciudad, código postal y ASN son complementos de pago. Si la autenticación de proxy es nueva para ti, nuestra guía sobre autenticación de proxy cubre en profundidad la mecánica del nombre de usuario y la contraseña.

import requests

USER = "your_login"
PASS = "your_password"
GATEWAY = "gw.dataimpulse.com:823"

def proxy_for(country):
    # __cr. pins the exit IP to that country
    cred = f"{USER}__cr.{country}:{PASS}"
    url = f"http://{cred}@{GATEWAY}"
    return {"http": url, "https": url}

resp = requests.get(
    "https://www.google.com/search",
    params=build_params("wireless headphones", country="de", lang="de"),
    headers=HEADERS,
    proxies=proxy_for("de"),
    timeout=30,
)
print(resp.status_code, len(resp.text))

La disciplina importante es cambiar juntos el país del proxy y el par gl/hl. Para crear una comparación de precios entre mercados, recorre una lista de países y mantén sincronizados la IP de salida y la configuración regional para que cada respuesta refleje una ubicación de comprador única y coherente.

MARKETS = [
    {"country": "us", "lang": "en"},
    {"country": "de", "lang": "de"},
    {"country": "gb", "lang": "en"},
    {"country": "fr", "lang": "fr"},
]

def fetch_market(query, market):
    c, lang = market["country"], market["lang"]
    return requests.get(
        "https://www.google.com/search",
        params=build_params(query, country=c, lang=lang),
        headers={**HEADERS, "Accept-Language": f"{lang};q=0.9"},
        proxies=proxy_for(c),
        timeout=30,
    )

for m in MARKETS:
    r = fetch_market("wireless headphones", m)
    print(m["country"], r.status_code, len(r.text))

DataImpulse proporciona la capa de IP, no un servicio de scraping gestionado, así que el scraper es tuyo. Los proxies residenciales rotativos suelen encajar aquí porque provienen de dispositivos de consumidores reales; los proxies de centro de datos son más baratos pero más fáciles de detectar, y los proxies móviles llevan IPs de nivel de operador para los objetivos más difíciles.

¿Cómo se analizan las tarjetas de producto de Google Shopping?

Analizas las tarjetas de producto con una biblioteca HTML tolerante y te anclas en patrones de texto estables en lugar de selectores profundos y frágiles, porque los nombres de clase de Google están ofuscados y rotan con frecuencia. Cualquier selector que copies hoy de las herramientas para desarrolladores de tu navegador puede dejar de funcionar en semanas, así que crea el analizador para que se degrade con elegancia en lugar de fallar ante un cambio de diseño.

Un enfoque robusto lee cada tarjeta candidata, obtiene el título y la imagen de la estructura de etiquetas y extrae el precio con una expresión regular que reconoce la moneda. Los selectores siguientes son ejemplos realistas, no garantías; cuenta con actualizarlos y mantén la expresión regular como tu alternativa fiable.

from bs4 import BeautifulSoup
import re

# Currency-aware price matcher: symbol optional, thousands and decimals tolerated.
PRICE_RE = re.compile(r"(?:[$€£]|USD|EUR|GBP)\s?\d[\d.,]*")

def parse_cards(html):
    soup = BeautifulSoup(html, "html.parser")
    rows = []
    # These class names ROTATE; treat them as hints, keep the fallbacks.
    candidates = soup.select("div.sh-dgr__content, div.sh-dlr__list-result, div[data-docid]")
    if not candidates:
        candidates = soup.find_all("div")  # last-resort sweep
    for card in candidates:
        text = card.get_text(" ", strip=True)
        price_match = PRICE_RE.search(text)
        if not price_match or len(text) > 400:
            continue
        img = card.find("img")
        link = card.find("a", href=True)
        rows.append({
            "title": _first_text(card, ["h3", "h4"]),
            "price_raw": price_match.group(0),
            "image": img.get("src") if img else None,
            "url": link["href"] if link else None,
        })
    return rows

def _first_text(card, tags):
    for t in tags:
        el = card.find(t)
        if el and el.get_text(strip=True):
            return el.get_text(strip=True)
    return None

CURRENCY = {"$": "USD", "€": "EUR", "£": "GBP"}

def normalize_price(raw):
    if not raw:
        return None, None
    symbol = next((s for s in CURRENCY if s in raw), None)
    code = CURRENCY.get(symbol, "USD")
    digits = re.sub(r"[^\d.,]", "", raw).replace(",", "")
    try:
        return float(digits), code
    except ValueError:
        return None, code

Como el marcado ofuscado es la norma aquí, algunos equipos recurren a un DOM renderizado. Para conocer los compromisos más amplios entre analizar HTML estático y páginas renderizadas, consulta nuestra guía sobre scraping de páginas web dinámicas.

¿Cómo se pagina y se aplica espera cuando Google devuelve un 429?

Paginas avanzando el desplazamiento start en pasos que coincidan con el tamaño de tu página, y sobrevives a los límites de tasa tratando el HTTP 429 (y las respuestas vacías o con CAPTCHA) como una señal para esperar y reintentar a través de una IP nueva. Google limita de forma agresiva las solicitudes automatizadas repetidas, así que la paginación y la espera pertenecen al mismo bucle.

Recorre las páginas hasta que una solicitud no devuelva tarjetas o alcances un límite de páginas. Rota la IP de salida entre páginas releyendo el diccionario del proxy, y detecta bloqueos leves comprobando marcadores de consentimiento o de CAPTCHA en el cuerpo en lugar de confiar solo en el código de estado.

BLOCK_MARKERS = ("unusual traffic", "/sorry/", "consent.google", "captcha")

def is_blocked(resp):
    if resp.status_code in (429, 503):
        return True
    body = resp.text.lower()
    return any(m in body for m in BLOCK_MARKERS)

def paginate(query, market, max_pages=5, page_size=40):
    all_rows = []
    for page in range(max_pages):
        params = build_params(query, market["country"], market["lang"],
                              start=page * page_size)
        resp = get_with_retry(
            "https://www.google.com/search",
            params=params, proxies=proxy_for(market["country"]),
        )
        if resp is None:
            break
        rows = parse_cards(resp.text)
        if not rows:
            break  # no more results
        all_rows.extend(rows)
    return all_rows

El ayudante de reintentos siguiente usa una espera exponencial con jitter, que distribuye los reintentos para que una ráfaga de workers bloqueados no reintente toda en el mismo instante. Cada intento vuelve a obtener el diccionario del proxy, así que un pool rotativo te entrega una IP nueva en el siguiente intento.

import time, random

def get_with_retry(url, params, proxies, max_attempts=4):
    for attempt in range(max_attempts):
        try:
            resp = requests.get(url, params=params, headers=HEADERS,
                                proxies=proxies, timeout=30)
        except requests.RequestException:
            resp = None
        if resp is not None and not is_blocked(resp):
            return resp
        # exponential backoff: 2, 4, 8 seconds, plus jitter
        wait = (2 ** (attempt + 1)) + random.uniform(0, 1.5)
        time.sleep(wait)
    return None  # exhausted; caller decides what to do

Mantén tasas de solicitud razonables incluso cuando los reintentos tienen éxito. Un retardo base cortés entre páginas, combinado con la rotación, hace más por la estabilidad a largo plazo que insistir con fuerza y depender de los reintentos. Nuestras notas sobre buenas prácticas de web scraping tratan con más detalle el ritmo y la higiene de los encabezados.

¿Cómo se renderizan las páginas bloqueadas con un navegador headless?

Cuando una solicitud HTTP simple sigue topando con muros de consentimiento o contenido renderizado con JavaScript, recurre a un navegador headless que ejecute la página como un cliente real y cierra el diálogo de consentimiento antes de leer el DOM. Playwright encaja bien porque admite proxies por contexto y una espera fiable.

El script siguiente lanza Chromium a través de un proxy de DataImpulse segmentado por país, gestiona el diálogo de cookies o de consentimiento que suelen mostrar las configuraciones regionales europeas, espera el contenido y devuelve el HTML renderizado para que puedas pasarlo a la misma función parse_cards.

from playwright.sync_api import sync_playwright

def render_shopping(query, country="de", lang="de"):
    cred_user = f"{USER}__cr.{country}"
    params = f"?q={query.replace(' ', '+')}&tbm=shop&gl={country}&hl={lang}"
    url = "https://www.google.com/search" + params
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        context = browser.new_context(
            proxy={
                "server": "http://gw.dataimpulse.com:823",
                "username": cred_user,
                "password": PASS,
            },
            locale=f"{lang}-{country.upper()}",
            user_agent=HEADERS["User-Agent"],
        )
        page = context.new_page()
        page.goto(url, wait_until="domcontentloaded", timeout=45000)
        _dismiss_consent(page)
        page.wait_for_timeout(2000)
        html = page.content()
        browser.close()
        return html

def _dismiss_consent(page):
    # Consent dialogs vary by locale; try a few common accept buttons.
    for label in ("Accept all", "Alle akzeptieren", "Tout accepter",
                  "I agree", "Accept"):
        try:
            btn = page.get_by_role("button", name=label)
            if btn.count() > 0:
                btn.first.click(timeout=3000)
                page.wait_for_timeout(1000)
                return
        except Exception:
            continue

Un navegador headless consume más CPU y memoria que una solicitud simple, así que úsalo como alternativa específica para las páginas que realmente necesitan renderizado en lugar de como camino por defecto. Muchos equipos ejecutan HTTP directo por velocidad y solo escalan a Playwright cuando is_blocked se dispara una y otra vez. Si tu stack es JavaScript en lugar de Python, el mismo patrón se aplica con Puppeteer; consulta web scraping con JavaScript.

¿Cómo se estructuran y exportan los datos extraídos?

Estructuras los datos en torno a un registro estable que siempre incluye el mercado y una marca de tiempo de captura, y luego los exportas a CSV para que la salida sea fácil de comparar, cargar en una hoja de cálculo o enviar a un almacén de datos. Una dataclass te da sugerencias de tipo y una definición clara de una fila.

from dataclasses import dataclass, asdict, field
from datetime import datetime, timezone
import csv

@dataclass
class Offer:
    query: str
    country: str
    title: str | None
    price: float | None
    currency: str | None
    seller: str | None = None
    url: str | None = None
    captured_at: str = field(
        default_factory=lambda: datetime.now(timezone.utc).isoformat()
    )

def to_offers(rows, query, country):
    offers = []
    for r in rows:
        price, currency = normalize_price(r.get("price_raw"))
        offers.append(Offer(
            query=query, country=country, title=r.get("title"),
            price=price, currency=currency, url=r.get("url"),
        ))
    return offers

Escribir el CSV se reduce entonces a volcar los campos de la dataclass. El modo de anexado más una protección de encabezado permiten que un trabajo programado haga crecer un único archivo con el tiempo sin reescribirlo.

import os

def export_csv(offers, path="google_shopping.csv"):
    if not offers:
        return
    fieldnames = list(asdict(offers[0]).keys())
    write_header = not os.path.exists(path)
    with open(path, "a", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=fieldnames)
        if write_header:
            writer.writeheader()
        for o in offers:
            writer.writerow(asdict(o))

Mantener el país y la marca de tiempo en cada fila es lo que después te permite responder preguntas como qué mercado es hoy el más barato para un SKU, o cómo se movió un precio esta semana. Esa clave de geografía y tiempo es la base del rastreador del historial de precios de la siguiente sección.

¿Cómo se rastrea el historial de precios de Google Shopping a lo largo del tiempo?

Rastreas el historial de precios insertando o actualizando (upsert) cada observación en una pequeña base de datos con clave de producto, país y día, de modo que volver a ejecutar el scraper actualiza la fila de hoy en lugar de duplicarla mientras conserva los días anteriores. SQLite es suficiente para millones de filas y no necesita servidor, lo que mantiene autónomo un trabajo de monitorización.

El esquema siguiente usa una clave única compuesta y un upsert ON CONFLICT. Ejecutar el scraper dos veces en un día sobrescribe el último precio de ese (producto, país, día); ejecutarlo a lo largo de varios días construye la serie temporal que puedes graficar más tarde.

import sqlite3

DDL = """
CREATE TABLE IF NOT EXISTS price_history (
    product   TEXT NOT NULL,
    country   TEXT NOT NULL,
    day       TEXT NOT NULL,
    price     REAL,
    currency  TEXT,
    seller    TEXT,
    captured_at TEXT,
    PRIMARY KEY (product, country, day)
);
"""

def init_db(path="prices.db"):
    conn = sqlite3.connect(path)
    conn.execute(DDL)
    conn.commit()
    return conn

def upsert_offers(conn, offers):
    sql = """
    INSERT INTO price_history
        (product, country, day, price, currency, seller, captured_at)
    VALUES (?, ?, ?, ?, ?, ?, ?)
    ON CONFLICT(product, country, day) DO UPDATE SET
        price=excluded.price,
        currency=excluded.currency,
        seller=excluded.seller,
        captured_at=excluded.captured_at;
    """
    for o in offers:
        day = o.captured_at[:10]  # YYYY-MM-DD
        conn.execute(sql, (o.title, o.country, day, o.price,
                           o.currency, o.seller, o.captured_at))
    conn.commit()

def price_trend(conn, product, country, days=14):
    cur = conn.execute(
        """SELECT day, price, currency FROM price_history
           WHERE product = ? AND country = ?
           ORDER BY day DESC LIMIT ?""",
        (product, country, days),
    )
    return cur.fetchall()

Hacer coincidir los títulos entre días es la parte difícil en la práctica, porque los títulos de Google varían ligeramente entre capturas. Para una pequeña lista de seguimiento, asigna los títulos sin procesar a un id de producto canónico que tú controles antes de hacer el upsert, en lugar de confiar en el título extraído como clave estable.

¿Cómo se programa la monitorización continua de precios?

Programas la monitorización envolviendo los pasos de obtener, analizar y almacenar en un único punto de entrada y ejecutándolo con una cadencia fija mediante cron, de modo que los precios se actualicen automáticamente sin ejecuciones manuales. Una ejecución una vez al día es un valor por defecto sensato para el seguimiento de precios; ejecuciones más frecuentes elevan tanto el coste como el riesgo de bloqueo sin aportar mucha señal adicional para la mayoría de los catálogos.

# run_monitor.py
def run_once(queries):
    conn = init_db()
    for query in queries:
        for market in MARKETS:
            rows = paginate(query, market, max_pages=3)
            offers = to_offers(rows, query, market["country"])
            export_csv(offers)
            upsert_offers(conn, offers)
            print(f"{query} / {market['country']}: {len(offers)} offers")
    conn.close()

if __name__ == "__main__":
    WATCHLIST = ["wireless headphones", "mechanical keyboard"]
    run_once(WATCHLIST)

Luego regístralo con cron. La entrada siguiente ejecuta el monitor cada día a las 06:15 y registra la salida para la depuración, lo que importa porque, de lo contrario, un scraper programado falla en silencio.

# crontab -e
# minute hour day month weekday  command
15 6 * * * cd /opt/shopping && /usr/bin/python3 run_monitor.py >> monitor.log 2>&1

Añade un ligero jitter dentro del trabajo (una espera aleatoria de unos minutos al inicio) para que las solicitudes no lleguen a Google exactamente en el mismo segundo del reloj cada día. Rota los países de salida y regula el ritmo de las solicitudes como se explicó antes, y vigila en el registro una tasa creciente de bloqueos, que es la señal más temprana de que Google ha cambiado sus defensas o de que tus patrones se han vuelto demasiado regulares.

¿Qué enfoque de recopilación deberías elegir: DIY, endpoints ocultos, API SERP o headless?

Elige en función de cuánta fragilidad e ingeniería estás dispuesto a asumir frente a cuánto estás dispuesto a pagar por solicitud. No hay una única respuesta correcta; el compromiso honesto es control y coste frente a carga de mantenimiento y exposición a los sistemas antibot.

La realidad antibot: Google defiende activamente estos resultados con limitación de tasa, CAPTCHAs, muros de consentimiento, marcado ofuscado y rotativo, y señales de comportamiento. Cualquier scraper hecho por ti mismo se romperá periódicamente y necesita mantenimiento continuo. Los proxies y la espera reducen los bloqueos; no los eliminan. Cualquiera que prometa un scraper de Google permanentemente indetectable está exagerando.

API SERP frente a DIY: una API SERP de terceros devuelve los resultados de compras ya analizados en JSON y absorbe por ti el trabajo de análisis y desbloqueo, a un precio por solicitud y con dependencia del proveedor y menos control sobre exactamente qué se obtiene. Un scraper hecho por ti mismo sobre proxies cuesta mucho menos por solicitud y te da control total, pero el analizador, los reintentos y el mantenimiento cuando Google cambia son tuyos. Para dejar claro dónde encaja DataImpulse: es la capa de proxy por debajo de cualquiera de estos enfoques DIY, no una API SERP ni un servicio de scraping gestionado. Si quieres cero trabajo de análisis, una API SERP es la recomendación honesta; si quieres bajo coste y control y puedes mantener un scraper, el DIY sobre proxies rotativos ofrece mejor economía. Los endpoints JSON ocultos pueden ser aún más baratos, pero son los más frágiles de todos, ya que Google puede cambiarlos o eliminarlos sin previo aviso.

¿Es legal y ético extraer datos de Google Shopping?

Extraer datos de productos visibles públicamente se considera en general de menor riesgo que acceder a contenido privado o restringido, pero no está exento de reglas, y esto no es asesoramiento legal. Los precios y las fichas de Google Shopping son públicos, pero cómo los recopilas y los usas sigue importando, y deberías confirmar tu caso concreto con un asesor cualificado.

• Términos de servicio: el acceso automatizado puede entrar en conflicto con los términos de Google, lo cual es una cuestión contractual distinta del derecho de autor o de la ley de acceso informático.
• Datos personales: las fichas de productos no suelen ser datos personales, pero evita recopilar nombres de reseñadores u otros identificadores, y cumple el RGPD donde sea aplicable.
• Tasa y carga: mantén razonable el volumen de solicitudes para no degradar el servicio que consultas.
• Uso de los datos: reutilizar de forma masiva imágenes o descripciones con derechos de autor conlleva más riesgo que analizar los precios como hechos.

En el lado de la recopilación, la ética empieza con las IPs que usas. DataImpulse obtiene sus IPs de usuarios que dan su consentimiento y reciben una compensación, se alinea con el RGPD y ofrece un acuerdo de tratamiento de datos, lo que respalda una canalización defendible. Para un tratamiento más completo del consentimiento, el origen y la práctica responsable, consulta nuestra guía sobre web scraping ético. Combina una fuente de IP ética con un ritmo cortés y un uso restringido y factual de los datos, y mantendrás bajo tanto el riesgo legal como el reputacional.

Preguntas frecuentes

Guías relacionadas

• Cómo extraer datos de Google Trends
• Cómo extraer anuncios de hoteles
• Extraer datos de páginas web dinámicas

Empieza a extraer datos de Google Shopping con proxies fiables

Si estás listo para recopilar datos de Google Shopping en varios mercados, DataImpulse te ofrece IPs residenciales, móviles y de centro de datos rotativas y fijas con segmentación por país incluida, desde un dólar por GB. Crea una cuenta y enruta tu primer scraper a través de un pool de IP limpio.