Como Raspar Preços do Google Shopping em 2026

Raspar preços do Google Shopping em 2026 é uma tarefa que exige tanto conhecimento técnico quanto infraestrutura de proxies robusta. Se você é analista de preços ou engenheiro de inteligência competitiva, já percebeu que a Content API for Shopping do Google serve apenas os produtos do próprio comerciante autenticado — não há endpoint público para obter preços competitivos de terceiros. A única forma de obter dados de mercado é analisar o HTML da página de resultados do Google Shopping (SERP com tbm=shop) ou as páginas de detalhe de produtos. Neste guia, mostramos como fazer isso de forma confiável usando proxies residenciais da ProxyHat.

Por que raspar Google Shopping em 2026 é mais difícil do que parece

O Google Shopping é, na prática, uma SERP vertical do Google Search. Isso significa que ele herda toda a infraestrutura anti-bot do Google Search, que é uma das mais agressivas da web. Os principais obstáculos são:

• reCAPTCHA Enterprise: O Google aplica reCAPTCHA v2 e v3 em páginas de shopping quando detecta comportamento automatizado. Em alguns casos, o desafio é invisível (score-based); em outros, aparece um puzzle visual.
• Redirect sorry/index: Em vez de devolver um 403, o Google redireciona IPs suspeitos para https://www.google.com/sorry/index?..., uma página que exige resolução de CAPTCHA manual. Esse redirect é o sinal mais comum de bloqueio por IP.
• Rate limits por IP agressivos: O Google não publica limites oficiais, mas na prática, um único IP residencial consegue fazer cerca de 50–80 requisições a SERPs de shopping antes de ser sinalizado. Datacenter IPs são bloqueados muito mais rápido — às vezes em menos de 10 requisições.
• Fingerprinting de browser: O Google coleta headers, TLS fingerprint (JA3), JavaScript execution results e padrões de navegação. Requests via requests puro, sem headers realistas, são flagrados quase imediatamente.

Por isso, raspar Google Shopping com sucesso exige três coisas: proxies residenciais de alta qualidade, rotação inteligente de IPs e headers/browser fingerprints que imitem um usuário real.

API vs HTML: o trade-off fundamental

Antes de escrever uma linha de código, é preciso entender o trade-off entre usar a API oficial e raspar o HTML:

Para inteligência competitiva de preços, o scraping da SERP HTML é a única opção viável que dá acesso a dados de todos os vendedores. A Content API é excelente para gerenciar seus próprios produtos, mas não responde à pergunta "qual é o preço do produto X nos concorrentes?".

Padrões de URL e seletores CSS do Google Shopping

A URL base para uma busca no Google Shopping é:

https://www.google.com/search?tbm=shop&q=QUERY&gl=COUNTRY&hl=LANGUAGE

Onde tbm=shop ativa a vertical de shopping, gl define o país (ex: US, DE, BR) e hl define o idioma (ex: en, de, pt-BR). Esses parâmetros são essenciais porque o Google Shopping mostra resultados diferentes por região.

Seletores CSS principais

O HTML do Google Shopping muda com alguma frequência, mas os seletores abaixo são estáveis desde 2024:

• Container de resultados: .sh-dgr__content — envolve cada card de produto na SERP.
• Grid de produtos: .sh-pr__product-results — container pai de toda a lista.
• Título do produto: h3 dentro de .sh-dgr__content, ou [role="heading"].
• Preço: .a8Pemb — nó de texto com o preço formatado (ex: "$299.99", "€249,00").
• Vendedor: .a8Pemb-OAUq5d ou [class*="merchant"] — nome do vendedor exibido.
• Avaliação: [role="img"] com aria-label contendo a nota (ex: "Rated 4.5 out of 5").

Para a página de detalhe do produto, a URL segue o padrão:

https://www.google.com/shopping/product/PRODUCT_ID/offers?hl=en&gl=US

Nessa página, o painel de ofertas de vendedores (.sh-sp__offer-grid) lista cada vendedor individual com preço, frete e disponibilidade. Esse é o melhor endpoint para comparação granular de preços por vendedor.

Por que preços localizados exigem proxies residenciais com geo por cidade

Um comprador nos Estados Unidos e um comprador na Alemanha veem vendedores, preços e moedas completamente diferentes no Google Shopping para o mesmo produto. O parâmetro gl=US versus gl=DE controla parte disso, mas o Google também usa o IP do visitante para determinar quais resultados mostrar. Se o seu IP for de um datacenter em Frankfurt, o Google pode inferir gl=DE independentemente do parâmetro de URL — ou pior, pode mostrar resultados genéricos.

Por isso, proxies residenciais com geo-targeting a nível de país e cidade são essenciais. Com a ProxyHat, você controla a localização do IP diretamente no campo de usuário:

# IP residencial nos EUA
http://user-country-US:pass@gate.proxyhat.com:8080

# IP residencial em Berlim, Alemanha
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080

# Sessão fixa (sticky) para manter o mesmo IP entre requisições
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080

A combinação de gl/hl na URL com o geo do proxy garante que você veja exatamente o que um comprador local veria. Isso é crítico para análise de pricing regional — se você raspa preços dos EUA com um IP brasileiro, os resultados serão inconsistentes e não representativos.

Consulte a lista completa de localizações disponíveis em nossa página de locations.

Exemplo prático em Python: raspando um bloco de resultado

Abaixo, um exemplo completo usando requests com BeautifulSoup, roteando através do gateway da ProxyHat. O código raspa a primeira página de resultados para uma query e extrai título, preço, vendedor e avaliação de cada produto.

import requests
from bs4 import BeautifulSoup
import time
import random

# Configuração do proxy ProxyHat (residencial, EUA)
proxy_url = "http://user-country-US:pass@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}

# Headers realistas para evitar fingerprinting básico
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                  "(KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "DNT": "1",
}

def scrape_google_shopping(query, gl="US", hl="en"):
    url = f"https://www.google.com/search?tbm=shop&q={query}&gl={gl}&hl={hl}"
    
    try:
        resp = requests.get(url, headers=headers, proxies=proxies, timeout=15)
    except requests.exceptions.RequestException as e:
        print(f"Erro de conexão: {e}")
        return []
    
    # Detectar soft-block (redirect para /sorry/)
    if "sorry/index" in resp.url:
        print("SOFT-BLOCK detectado: IP provavelmente sinalizado")
        return ["BLOCKED"]
    
    if resp.status_code == 429:
        print("Rate limit (429): reduzir frequência")
        return ["RATE_LIMITED"]
    
    soup = BeautifulSoup(resp.text, "html.parser")
    results = []
    
    # Selecionar containers de produtos
    cards = soup.select(".sh-dgr__content")
    
    for card in cards[:5]:  # Truncar para exemplo
        title_node = card.select_one("h3")
        price_node = card.select_one(".a8Pemb")
        seller_node = card.select_one("[class*='merchant']")
        rating_node = card.select_one("[role='img']")
        
        product = {
            "title": title_node.get_text(strip=True) if title_node else None,
            "price": price_node.get_text(strip=True) if price_node else None,
            "seller": seller_node.get_text(strip=True) if seller_node else None,
            "rating": rating_node.get("aria-label") if rating_node else None,
        }
        results.append(product)
    
    return results

# Executar
data = scrape_google_shopping("wireless headphones")
for item in data:
    print(item)
    
# Delay aleatório entre 3–7 segundos
    time.sleep(random.uniform(3, 7))

Saída esperada (truncada):

{'title': 'Sony WH-1000XM5 Wireless Headphones', 'price': '$329.99', 'seller': 'Best Buy', 'rating': 'Rated 4.7 out of 5'}
{'title': 'Bose QuietComfort Ultra', 'price': '$379.00', 'seller': 'Amazon', 'rating': 'Rated 4.6 out of 5'}
{'title': 'Apple AirPods Max', 'price': '$549.00', 'seller': 'Apple', 'rating': 'Rated 4.8 out of 5'}

Note que o delay aleatório de 3–7 segundos entre requisições é intencional. Padrões regulares (ex: exatamente 5 segundos) são detectáveis como comportamento automatizado. A aleatoriedade imita a navegação humana.

Paginação, batching e detecção de soft-blocks

Paginação

O Google Shopping pagina resultados via parâmetro start na URL, em incrementos de aproximadamente 20 resultados:

https://www.google.com/search?tbm=shop&q=headphones&start=20
https://www.google.com/search?tbm=shop&q=headphones&start=40

Na prática, raramente vale a pena ir além da página 3–4 (start=60), pois os resultados mais relevantes estão no topo. Para análise de pricing, os primeiros 20–40 resultados cobrem a maioria dos vendedores relevantes.

Query batching

Se você monitora 500 produtos, não raspe todos em sequência. Divida em lotes:

• Lote de 50 queries por sessão de proxy (IP fixo via sticky session).
• Pause de 30–60 segundos entre lotes.
• Troque de IP (nova sessão sticky) ao iniciar cada lote.
• Distribua queries em horários diferentes ao longo do dia para evitar picos.

Detecção de soft-blocks

Antes de receber um CAPTCHA hard (página sorry/index), o Google envia sinais de aviso. Detectá-los cedo evita desperdiçar sessões de proxy:

1. Aumento de latência: Se o tempo de resposta sobe de 800ms para 3000ms+ sem motivo aparente, o Google pode estar aplicando throttle.
2. Resultados vazios: Se a SERP retorna HTML válido mas sem .sh-dgr__content, pode ser um soft-block silencioso.
3. Redirect para sorry/index: Este é o bloqueio efetivo. Troque de IP imediatamente.
4. Código 429: Rate limit explícito. Reduza a frequência e aguarde.

def detect_soft_block(resp, soup):
    """Retorna True se houver indício de soft-block."""
    if "sorry/index" in resp.url:
        return "HARD_BLOCK"
    if resp.status_code == 429:
        return "RATE_LIMITED"
    cards = soup.select(".sh-dgr__content")
    if resp.status_code == 200 and len(cards) == 0:
        # HTML válido mas sem produtos — possível soft-block
        return "EMPTY_RESULTS"
    if resp.elapsed.total_seconds() > 3.0:
        return "SLOW_RESPONSE"
    return None

Implemente essa verificação após cada requisição e mantenha um contador. Se você detectar 2 ou mais sinais em uma sessão, descarte o IP e inicie uma nova sessão com um IP residencial diferente.

Estratégia de rotação de IPs com ProxyHat

A ProxyHat oferece três modos de rotação que se aplicam ao scraping do Google Shopping:

• Rotação por requisição: Cada request recebe um IP novo automaticamente. Ideal para SERPs de volume alto, mas pode causar inconsistência se o Google associar cookies/session.
• Sessões sticky: Mantém o mesmo IP por N requisições (até ~30 minutos). Melhor para paginação — você raspa páginas 1–4 com o mesmo IP, depois troca.
• Geo-targeting por país/cidade: Essencial para preços localizados. Combine com gl/hl na URL.

Para scraping de Google Shopping, recomendamos sessões sticky de 20–30 requisições por IP, com geo-targeting alinhado ao parâmetro gl. Veja nossos planos para opções de volume.

Considerações éticas e legais

Raspar dados públicos de preços é uma prática comum em inteligência competitiva, mas há limites importantes:

• Dados públicos apenas: O Google Shopping exibe preços e vendedores publicamente, sem login. Raspar esses dados é equivalente a visitar a página como usuário. Não tente acessar dados que exigem autenticação.
• robots.txt: O Google Shopping é servido sob google.com, cujo robots.txt permite indexação de SERPs. No entanto, o Google pode considerar scraping automatizado como violação dos Termos de Serviço.
• CFAA e GDPR: Nos EUA, a Computer Fraud and Abuse Act (CFAA) tem sido interpretada de forma cada vez mais restritiva em casos de scraping (cf. hiQ Labs v. LinkedIn). Na UE, o GDPR não se aplica a preços de produtos (dados não pessoais), mas o processamento de dados pessoais em reviews/ratings deve ser evitado.
• Frequência responsável: Não sature o Google com milhares de requisições por minuto. Use delays, respeite rate limits implícitos e monitore o impacto.
• Quando usar parceiros oficiais: Se você precisa de dados de SERP em escala comercial e com SLA, considere APIs de SERP que são parceiros oficiais do Google. Para casos de uso menores, o scraping com proxies residenciais é viável e amplamente utilizado.

A ProxyHat não incentiva violação de Termos de Serviço. Use este guia para casos legítimos de pesquisa de preços públicos e competitivos. Para casos de uso mais amplos, consulte nossa documentação oficial.

Casos de uso além de pricing

Os mesmos seletores e infraestrutura de proxy servem para outros casos de uso relacionados ao Google Shopping:

• Monitoramento de SERP: Acompanhar onde seus produtos aparecem nas buscas de shopping. Veja nosso caso de uso de SERP tracking.
• Pesquisa de e-commerce: Comparar catálogos entre marketplaces. Veja web scraping para mais detalhes.
• Análise de vendedores: Identificar quais vendedores aparecem com mais frequência e seus níveis de preço.
• Treinamento de modelos de IA: Coleta de dados estruturados de produtos para fine-tuning de LLMs.

Key Takeaways

1. API oficial não serve para inteligência competitiva. A Content API for Shopping só retorna seus próprios produtos. Para ver preços de concorrentes, o scraping da SERP HTML (tbm=shop) é a única via.

2. Proxies residenciais com geo por cidade são obrigatórios. Preços e vendedores variam por região. Combine gl/hl na URL com user-country-XX-city-yyy no proxy para dados localizados e consistentes.

3. Detecte soft-blocks antes do CAPTCHA. Monitore latência, resultados vazios e redirects para sorry/index. Troque de IP ao primeiro sinal.

4. Sessões sticky de 20–30 requisições oferecem o melhor equilíbrio entre consistência e evasão de bloqueio.

5. Respeite limites éticos e legais. Raspe apenas dados públicos, use frequência responsável e considere APIs parceiras para escala comercial.

FAQ

O que é raspar preços do Google Shopping em 2026?

É o processo de extrair dados de produtos (título, preço, vendedor, avaliação) das páginas de resultados do Google Shopping via parsing do HTML da SERP. Em 2026, isso requer proxies residenciais com geo-localização, headers realistas e detecção de soft-blocks, pois o Google reforçou sua infraestrutura anti-bot com reCAPTCHA Enterprise e redirects sorry/index.

Por que raspar Google Shopping importa para usuários de proxy?

Porque o Google Shopping aplica rate limits agressivos por IP e bloqueia IPs de datacenter rapidamente. Proxies residenciais com geo-targeting por país e cidade são a única forma de acessar preços localizados de forma confiável. Sem proxies, um scraper consegue poucas dezenas de requisições antes de ser bloqueado.

Qual tipo de proxy funciona melhor para Google Shopping?

Proxies residenciais com sessões sticky e geo-targeting por país/cidade. IPs de datacenter são bloqueados em menos de 10 requisições. Proxies móveis também funcionam bem, mas têm custo maior. A combinação ideal é residencial + sticky session de 20–30 requisições + geo alinhado ao parâmetro gl da URL.

Como evitar bloqueios ao raspar Google Shopping?

Use quatro estratégias combinadas: (1) proxies residenciais com rotação a cada 20–30 requisições; (2) delays aleatórios de 3–7 segundos entre requests; (3) headers de browser realistas com Accept-Language alinhado ao geo; (4) detecção proativa de soft-blocks (redirect sorry/index, 429, resultados vazios) para trocar de IP antes do bloqueio efetivo.

É legal raspar preços do Google Shopping?

Raspar dados públicos de preços (sem login) é geralmente aceito como legal em jurisdições dos EUA e UE, desde que não viole Termos de Serviço explicitamente ou use dados pessoais. A CFAA nos EUA e o GDPR na UE têm nuances — consulte um advogado para sua situação específica. Para escala comercial com SLA, APIs parceiras oficiais do Google são a rota mais segura.