scrape google shopping

Extrair dados do Google Shopping consiste em coletar dados estruturados de produtos (títulos, preços, vendedores, avaliações e notas de envio) dos resultados de compras do Google em grande escala. Como esses resultados são muito protegidos e localizados, fazê-lo de forma confiável exige IPs rotativos e uma geolocalização correta em vez de um único scraper em uma única conexão.

Este guia prioriza o código. Ele percorre as solicitações geolocalizadas, o roteamento por meio de proxies específicos por país, a análise dos cartões de produto que o Google ofusca deliberadamente, a paginação, as novas tentativas e a espera diante dos limites de taxa, uma alternativa com navegador headless que trata o diálogo de consentimento, um modelo de dados limpo com exportação para CSV, um rastreador do histórico de preços e um agendamento de monitoramento. Ele também é honesto sobre a realidade dos sistemas antibot, o equilíbrio entre um scraper feito por você mesmo e uma API SERP paga, e onde ficam os limites legais.

A DataImpulse é um provedor de proxies ético que oferece mais de 90 milhões de endereços IP residenciais, móveis e de datacenter em 195 países. Ela usa um modelo de pagamento conforme o uso a partir de 1 dólar por GB com tráfego que não expira, e é usada para web scraping, verificação de anúncios, monitoramento de preços, pesquisa de mercado e gestão de múltiplas contas.

Fatos principais

  • Preços localizados: para extrair dados do Google Shopping com precisão você deve definir os parâmetros gl e hl e rotear as solicitações por meio de um IP no país de destino, porque os preços, os vendedores e a disponibilidade diferem conforme a região.
  • Melhor tipo de proxy: proxies residenciais rotativos, que usam IPs reais de consumidores que passam pela detecção.
  • Preço: a partir de 1 dólar por GB, pagamento conforme o uso, com tráfego que não expira e sem assinatura.
  • Cobertura: mais de 90M de IPs de origem ética em 195 países.
  • Confiabilidade: taxa de sucesso de 99.51%, avaliada com 4.8 de 5 no G2.
  • Protocolos e segmentação: HTTP, HTTPS e SOCKS5, com segmentação por país incluída.
Collecting Google Shopping product data

Quais dados você pode extrair do Google Shopping?

O Google Shopping exibe fichas de produtos com vários campos estruturados que são úteis para a definição de preços e a pesquisa de mercado. Cada resultado geralmente traz um conjunto coerente de atributos que você pode extrair e normalizar em linhas.

  • Detalhes do produto: título, trecho da descrição, marca, modelo e URL da imagem do produto.
  • Preço: o preço indicado, a moeda e, às vezes, uma faixa de preços entre vendedores.
  • Vendedor: o nome do comerciante e, na página de detalhes do produto, uma lista de vendedores concorrentes que oferecem o mesmo item.
  • Avaliações e resenhas: a avaliação média em estrelas e a quantidade de resenhas quando presentes.
  • Disponibilidade e envio: o status de estoque e as notas de envio que variam conforme a região.

Os campos exatos mudam sempre que o Google atualiza seu layout, então qualquer analisador precisa tolerar valores ausentes e marcação em mudança. Trate cada campo como opcional e valide os tipos após a extração em vez de supor que sempre há uma avaliação ou um vendedor. Como o mesmo produto pode aparecer a preços diferentes em países diferentes, planeje seu esquema em torno de uma chave (produto, país, carimbo de data e hora) desde o início em vez de acrescentar a geografia depois.

Como enviar uma solicitação geolocalizada ao Google Shopping?

Você envia uma solicitação geolocalizada acessando o endpoint de busca do Google com o sinalizador da aba de compras mais os parâmetros de configuração regional, e depois enviando os mesmos sinais de IP e de parâmetros que um comprador real enviaria. Os dois parâmetros que mais importam são gl (o país, por exemplo gl=de para a Alemanha) e hl (o idioma da interface, por exemplo hl=de). Um terceiro útil é um termo do tipo location que você integra ao contexto da consulta, mas gl junto com um IP de saída correspondente faz a maior parte do trabalho.

Definir apenas os parâmetros não basta, porque o Google também lê o IP da solicitação para decidir quais preços e vendedores mostrar. A solicitação mínima a seguir envia cabeçalhos realistas e o par de configuração regional. Ela está deliberadamente sem proxy para que você possa ver a chamada base antes de acrescentar uma camada 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))

Mantenha o cabeçalho Accept-Language alinhado com hl. Uma página de preços alemã solicitada com um cabeçalho de idioma inglês é uma incoerência que parece pouco natural e pode retornar a moeda errada. Quando você escala, essa função base se torna o único lugar onde a configuração regional é decidida, o que mantém coerente cada chamada posterior.

Como rotear solicitações por meio de proxies segmentados por país?

Você roteia por meio de um proxy segmentado por país apontando requests para um único gateway e codificando o país de destino no nome de usuário do proxy. Com a DataImpulse o gateway é gw.dataimpulse.com:823, e acrescentar __cr.us ou __cr.de ao seu nome de usuário seleciona o país de saída. A segmentação por país está incluída no preço base, enquanto a segmentação por estado, cidade, CEP e ASN são complementos pagos. Se a autenticação de proxy é novidade para você, nosso guia sobre autenticação de proxy aborda em profundidade a mecânica do nome de usuário e da senha.

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))

A disciplina importante é trocar juntos o país do proxy e o par gl/hl. Para criar uma comparação de preços entre mercados, percorra uma lista de países e mantenha sincronizados o IP de saída e a configuração regional para que cada resposta reflita uma localização de comprador única e coerente.

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))

A DataImpulse fornece a camada de IP, não um serviço de scraping gerenciado, então o scraper é seu. Os proxies residenciais rotativos costumam se encaixar aqui porque vêm de dispositivos de consumidores reais; os proxies de datacenter são mais baratos, mas mais fáceis de detectar, e os proxies móveis trazem IPs de nível de operadora para os alvos mais difíceis.

Como analisar os cartões de produto do Google Shopping?

Você analisa os cartões de produto com uma biblioteca HTML tolerante e se ancora em padrões de texto estáveis em vez de seletores profundos e frágeis, porque os nomes de classe do Google são ofuscados e rotacionam com frequência. Qualquer seletor que você copie hoje das ferramentas de desenvolvedor do seu navegador pode quebrar em semanas, então crie o analisador para se degradar com elegância em vez de falhar diante de uma mudança de layout.

Uma abordagem robusta lê cada cartão candidato, obtém o título e a imagem da estrutura de tags e extrai o preço com uma expressão regular que reconhece a moeda. Os seletores a seguir são exemplos realistas, não garantias; conte com atualizá-los e mantenha a expressão regular como sua alternativa confiável.

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 a marcação ofuscada é a norma aqui, algumas equipes recorrem a um DOM renderizado. Para conhecer os compromissos mais amplos entre analisar HTML estático e páginas renderizadas, consulte nosso guia sobre scraping de páginas web dinâmicas.

Como paginar e aplicar espera quando o Google retorna 429?

Você pagina avançando o deslocamento start em passos que correspondam ao tamanho da sua página, e sobrevive aos limites de taxa tratando o HTTP 429 (e as respostas vazias ou com CAPTCHA) como um sinal para esperar e tentar novamente por meio de um IP novo. O Google limita de forma agressiva as solicitações automatizadas repetidas, então a paginação e a espera pertencem ao mesmo laço.

Percorra as páginas até que uma solicitação não retorne cartões ou você atinja um limite de páginas. Rode o IP de saída entre páginas relendo o dicionário do proxy, e detecte bloqueios leves verificando marcadores de consentimento ou de CAPTCHA no corpo em vez de confiar apenas no código de status.

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

O auxiliar de novas tentativas a seguir usa uma espera exponencial com jitter, que distribui as tentativas para que uma rajada de workers bloqueados não tente novamente toda no mesmo instante. Cada tentativa busca novamente o dicionário do proxy, então um pool rotativo entrega a você um IP novo na próxima tentativa.

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

Mantenha taxas de solicitação razoáveis mesmo quando as novas tentativas têm sucesso. Um atraso base educado entre páginas, combinado com a rotação, faz mais pela estabilidade a longo prazo do que insistir com força e depender das novas tentativas. Nossas notas sobre boas práticas de web scraping abordam com mais detalhe o ritmo e a higiene dos cabeçalhos.

Como renderizar páginas bloqueadas com um navegador headless?

Quando uma solicitação HTTP simples continua esbarrando em muros de consentimento ou conteúdo renderizado com JavaScript, recorra a um navegador headless que execute a página como um cliente real e feche o diálogo de consentimento antes de ler o DOM. O Playwright encaixa bem porque oferece suporte a proxies por contexto e uma espera confiável.

O script a seguir inicia o Chromium por meio de um proxy da DataImpulse segmentado por país, trata o diálogo de cookies ou de consentimento que as configurações regionais europeias costumam exibir, espera pelo conteúdo e retorna o HTML renderizado para que você possa passá-lo à mesma função 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

Um navegador headless consome mais CPU e memória do que uma solicitação simples, então use-o como alternativa específica para as páginas que realmente precisam de renderização em vez de como caminho padrão. Muitas equipes executam HTTP direto por velocidade e só escalam para o Playwright quando is_blocked dispara repetidamente. Se sua stack é JavaScript em vez de Python, o mesmo padrão se aplica com o Puppeteer; consulte web scraping com JavaScript.

Como estruturar e exportar os dados extraídos?

Você estrutura os dados em torno de um registro estável que sempre inclui o mercado e um carimbo de data e hora de captura, e depois os exporta para CSV para que a saída seja fácil de comparar, carregar em uma planilha ou enviar a um data warehouse. Uma dataclass fornece dicas de tipo e uma definição clara de uma linha.

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

Escrever o CSV é então uma questão de despejar os campos da dataclass. O modo de acréscimo mais uma proteção de cabeçalho permitem que um trabalho agendado faça crescer um único arquivo ao longo do tempo sem reescrevê-lo.

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))

Manter o país e o carimbo de data e hora em cada linha é o que depois permite responder a perguntas como qual mercado está mais barato hoje para um SKU, ou como um preço se moveu nesta semana. Essa chave de geografia e tempo é a base do rastreador do histórico de preços da próxima seção.

Como rastrear o histórico de preços do Google Shopping ao longo do tempo?

Você rastreia o histórico de preços inserindo ou atualizando (upsert) cada observação em um pequeno banco de dados com chave de produto, país e dia, de modo que executar o scraper novamente atualiza a linha de hoje em vez de duplicá-la, preservando os dias anteriores. O SQLite é suficiente para milhões de linhas e não precisa de servidor, o que mantém autônomo um trabalho de monitoramento.

O esquema a seguir usa uma chave única composta e um upsert ON CONFLICT. Executar o scraper duas vezes em um dia sobrescreve o último preço daquele (produto, país, dia); executá-lo ao longo de vários dias constrói a série temporal que você pode representar em gráfico mais 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()

Fazer os títulos coincidirem entre dias é a parte difícil na prática, porque os títulos do Google variam ligeiramente entre capturas. Para uma pequena lista de acompanhamento, mapeie os títulos brutos para um id de produto canônico que você controla antes de fazer o upsert, em vez de confiar no título extraído como chave estável.

Como agendar o monitoramento contínuo de preços?

Você agenda o monitoramento envolvendo as etapas de obter, analisar e armazenar em um único ponto de entrada e executando-o em uma cadência fixa com cron, de modo que os preços se atualizem automaticamente sem execuções manuais. Uma execução uma vez por dia é um padrão sensato para o acompanhamento de preços; execuções mais frequentes elevam tanto o custo quanto o risco de bloqueio sem acrescentar muito sinal para a maioria dos 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)

Depois registre-o com o cron. A entrada a seguir executa o monitor todos os dias às 06:15 e registra a saída para depuração, o que importa porque, caso contrário, um scraper agendado falha silenciosamente.

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

Adicione um leve jitter dentro do trabalho (uma espera aleatória de alguns minutos no início) para que as solicitações não cheguem ao Google exatamente no mesmo segundo do relógio todos os dias. Rode os países de saída e regule o ritmo das solicitações como explicado antes, e fique de olho no registro em uma taxa crescente de bloqueios, que é o sinal mais precoce de que o Google mudou suas defesas ou de que seus padrões ficaram regulares demais.

Qual abordagem de coleta você deve escolher: DIY, endpoints ocultos, API SERP ou headless?

Escolha com base em quanta fragilidade e engenharia você está disposto a assumir em relação a quanto está disposto a pagar por solicitação. Não há uma única resposta certa; o compromisso honesto é controle e custo em relação à carga de manutenção e à exposição aos sistemas antibot.

A realidade antibot: o Google defende ativamente esses resultados com limitação de taxa, CAPTCHAs, muros de consentimento, marcação ofuscada e rotativa, e sinais de comportamento. Qualquer scraper feito por você mesmo vai quebrar periodicamente e precisa de manutenção contínua. Os proxies e a espera reduzem os bloqueios; não os eliminam. Qualquer um que prometa um scraper do Google permanentemente indesbloqueável está exagerando.

Abordagem Custo Fragilidade Controle
Análise HTML DIY Baixo (apenas proxy) Alta Total
Endpoints JSON ocultos Baixo (apenas proxy) Muito alta Total
API SERP Alto (por solicitação) Baixa Limitado
Navegador headless Médio (computação + proxy) Média Total

API SERP versus DIY: uma API SERP de terceiros retorna os resultados de compras já analisados em JSON e absorve por você o trabalho de análise e desbloqueio, a um preço por solicitação e com dependência do fornecedor e menos controle sobre exatamente o que é obtido. Um scraper feito por você mesmo sobre proxies custa muito menos por solicitação e dá controle total, mas o analisador, as novas tentativas e a manutenção quando o Google muda são seus. Para deixar claro onde a DataImpulse se encaixa: ela é a camada de proxy por baixo de qualquer uma dessas abordagens DIY, não uma API SERP nem um serviço de scraping gerenciado. Se você quer zero trabalho de análise, uma API SERP é a recomendação honesta; se você quer baixo custo e controle e pode manter um scraper, o DIY sobre proxies rotativos oferece melhor economia. Os endpoints JSON ocultos podem ser ainda mais baratos, mas são os mais frágeis de todos, já que o Google pode alterá-los ou removê-los sem aviso.

É legal e ético extrair dados do Google Shopping?

Extrair dados de produtos visíveis publicamente é geralmente considerado de menor risco do que acessar conteúdo privado ou restrito, mas não está livre de regras, e isto não é aconselhamento jurídico. Os preços e as fichas do Google Shopping são públicos, mas como você os coleta e usa ainda importa, e você deve confirmar seu caso específico com um advogado qualificado.

  • Termos de serviço: o acesso automatizado pode entrar em conflito com os termos do Google, o que é uma questão contratual distinta do direito autoral ou da lei de acesso a computadores.
  • Dados pessoais: as fichas de produtos geralmente não são dados pessoais, mas evite coletar nomes de avaliadores ou outros identificadores, e siga o GDPR onde ele se aplica.
  • Taxa e carga: mantenha razoável o volume de solicitações para não degradar o serviço que você consulta.
  • Uso dos dados: reutilizar em massa imagens ou descrições protegidas por direitos autorais acarreta mais risco do que analisar os preços como fatos.

No lado da coleta, a ética começa com os IPs que você usa. A DataImpulse obtém seus IPs de usuários que dão consentimento e são compensados, alinha-se com o GDPR e oferece um acordo de tratamento de dados, o que sustenta um pipeline defensável. Para um tratamento mais completo do consentimento, da origem e da prática responsável, consulte nosso guia sobre web scraping ético. Combine uma fonte de IP ética com um ritmo educado e um uso restrito e factual dos dados, e você manterá baixos tanto o risco legal quanto o reputacional.

Ways to pull Google Shopping data

Perguntas frequentes

Eu preciso de proxies residenciais para extrair dados do Google Shopping?

Os proxies residenciais são a opção mais confiável porque usam IPs reais de consumidores que se misturam ao tráfego normal. Os proxies de datacenter podem servir para um volume leve, mas são detectados e bloqueados com mais facilidade.

Como obtenho preços localizados do Google Shopping?

Defina os parâmetros gl e hl com o país e o idioma de destino, e roteie a solicitação por meio de um IP de proxy nesse mesmo país usando a sintaxe de país, por exemplo um nome de usuário terminado em __cr.de para a Alemanha. O Google lê tanto os parâmetros quanto o IP da solicitação para decidir quais preços mostrar.

A DataImpulse é uma API de scraping do Google Shopping?

Não. A DataImpulse fornece a camada de proxy (IPs residenciais, móveis e de datacenter), não uma API de scraping gerenciado nem uma API SERP. Você executa seu próprio scraper ou uma ferramenta de terceiros sobre os IPs dela.

Por que meu scraper do Google Shopping continua sendo bloqueado?

O Google limita as solicitações automatizadas repetidas de um único IP e serve CAPTCHAs e muros de consentimento. Os proxies residenciais rotativos, os cabeçalhos realistas, a espera exponencial diante das respostas 429 e taxas de solicitação razoáveis reduzem os bloqueios de forma significativa, embora nenhum método os elimine por completo.

Devo usar uma API SERP ou criar meu próprio scraper?

Uma API SERP elimina o trabalho de análise e desbloqueio a um custo maior por solicitação e com menos controle, o que convém às equipes que querem zero manutenção. Um scraper feito por você mesmo sobre proxies rotativos custa muito menos e dá controle total, mas você mantém o analisador e as novas tentativas conforme o Google muda.

Quando a DataImpulse não é a opção adequada?

Se você precisa de proxies ISP estáticos, uma API de scraping totalmente gerenciada ou acesso a sites bancários e governamentais, a DataImpulse não é a ferramenta adequada. Ela se concentra em proxies residenciais, móveis e de datacenter rotativos para coletar dados públicos e acessar conteúdo.

Comece a extrair dados do Google Shopping com proxies confiáveis

Se você está pronto para coletar dados do Google Shopping em vários mercados, a DataImpulse oferece IPs residenciais, móveis e de datacenter rotativos e fixos com segmentação por país incluída, a partir de um dólar por GB. Crie uma conta e roteie seu primeiro scraper por meio de um pool de IP limpo.


Share article: