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-region-state_of_berlin-city-berlin:pass@gate.proxyhat.com:8080

# Sessão fixa (sticky) para manter o mesmo IP entre requisições
http://user-country-US-sid-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-region-rrr-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.