Raspar preços do Google Shopping em 2026 é uma das tarefas mais valiosas — e mais frustrantes — para analistas de preços e equipes de inteligência competitiva. O Google Shopping agrega ofertas de milhares de lojistas, exibindo preços, vendedores, avaliações e disponibilidade em tempo real. Mas a infraestrutura anti-bot do Google evoluiu drasticamente: CAPTCHAs, redirecionamentos sorry/index e limites de taxa por IP tornaram o scraping ingênuo praticamente inviável.
Neste guia prático, você vai aprender como raspar Google Shopping de forma confiável, usando proxies residenciais com geo-localização. Vamos cobrir o trade-off entre API e HTML, os padrões de URL, os seletores CSS atuais, um exemplo completo em Python com a ProxyHat, e as melhores práticas para evitar bloqueios.
API vs. HTML: Por que raspar Google Shopping é necessário
A primeira pergunta que toda equipe técnica faz é: "por que não usar a API oficial?" A resposta é simples e cruel. O Content API for Shopping do Google serve apenas os produtos do próprio lojista — ou seja, você só consegue acessar dados da sua própria conta Merchant Center. Para dados competitivos — preços de concorrentes, ofertas de outros vendedores, comparações de mercado — a API oficial é inútil.
Isso significa que, para construir um Google Shopping price scraper competitivo, você precisa analisar o HTML do SERP tbm=shop ou as páginas de detalhe de produto em /shopping/product/. Não há atalho oficial.
Existem APIs de terceiros que encapsulam essa raspagem (SerpApi, Zyte SERP, etc.), mas elas cobram por requisição — tipicamente entre $0,001 e $0,005 por busca — e adicionam latência e dependência de fornecedor. Para volumes altos (centenas de milhares de produtos por dia), raspar diretamente com proxies próprios é significativamente mais econômico e flexível.
A pilha anti-bot do Google: o que você enfrenta
O Google emprega múltiplas camadas de defesa contra raspagem automatizada. Entender cada uma é essencial para projetar um scraper robusto.
1. reCAPTCHA Enterprise
O Google Shopping é protegido por reCAPTCHA Enterprise, que analisa sinais comportamentais — velocidade de requisições, padrões de mouse, headers HTTP, fingerprinting do navegador — para atribuir um score de risco a cada sessão. Scores baixos resultam em desafios visuais ou bloqueios diretos. Segundo a documentação oficial do reCAPTCHA, o sistema pode bloquear requisições sem sequer exibir um desafio visível.
2. Redirecionamento sorry/index
Quando o Google detecta comportamento suspeito, redireciona a requisição para https://www.google.com/sorry/index — uma página de erro que exige resolução de CAPTCHA. Esse redirecionamento retorna HTTP 429 ou 503 e é o sinal mais confiável de que seu IP foi marcado. Se você continuar raspando do mesmo IP após receber o sorry/index, o próximo passo é um banimento temporário que pode durar de horas a dias.
3. Limites de taxa por IP
O Google aplica limites de taxa agressivos por IP, mas não publica os thresholds exatos. Baseado em observações práticas da comunidade de scraping, IPs de datacenter são tipicamente limitados a 10–20 requisições por hora antes de receberem um desafio. IPs residenciais autênticos aguentam consideravelmente mais — 100–200 requisições por hora por IP, dependendo da consistência do comportamento e dos headers enviados.
É aqui que os proxies residenciais se tornam essenciais. Com um pool de milhares de IPs residenciais rotativos, você distribui a carga de forma que nenhum IP individual se aproxime do limite de taxa.
Padrões de URL e seletores CSS para Google Shopping
Para raspar Google Shopping, você precisa conhecer os padrões de URL e os seletores CSS atuais. O Google muda sua marcação com frequência, então é importante tratar seletores como frágeis e atualizáveis.
URL de busca do Shopping
https://www.google.com/search?tbm=shop&q=QUERY&gl=US&hl=enO parâmetro tbm=shop ativa a aba de Shopping. Os parâmetros gl (geolocalização) e hl (idioma) controlam qual versão localizada do Shopping você recebe — isso é crítico e vamos detalhar adiante.
Contêineres de resultados
Os resultados de produtos aparecem dentro de contêineres com as seguintes classes (válidas em 2025–2026, mas sujeitas a mudanças):
.sh-dgr__content— contêiner principal de cada resultado de produto na grade..sh-pr__product-results— wrapper da lista de resultados em algumas variações de layout..a8Pemb— nó de preço (preço principal exibido)..sh-dgr__offer-title— título do produto..sh-dgr__seller— nome do vendedor..sh-dgr__rating— avaliação em estrelas.
Página de detalhe do produto
Ao clicar em um resultado, o Google leva para uma página de detalhe:
https://www.google.com/shopping/product/PRODUCT_IDEssa página contém o painel de ofertas de vendedores (seller-offer panels), onde você encontra todos os vendedores que oferecem o produto, com preços individuais, custos de envio e disponibilidade. Os seletores típicos incluem .sh-osd__offer para cada oferta de vendedor e .sh-osd__price para o preço individual.
Por que preços localizados exigem proxies residenciais com geo de cidade
Este é um ponto que muitos scrapers iniciantes ignoram, e que custa caro. O Google Shopping exibe preços, vendedores e disponibilidade diferentes dependendo da localização geográfica do usuário. Um comprador nos Estados Unidos vê vendedores americanos com preços em USD; um comprador na Alemanha vê vendedores europeus com preços em EUR — e às vezes produtos totalmente diferentes.
Isso acontece porque:
- Vendedores definem regiões de envio e preços por mercado.
- O Google filtra resultados com base no IP e nos parâmetros
gl/hl. - Disponibilidade de estoque varia por região.
Para capturar preços precisos por mercado, você precisa de duas coisas combinadas:
- Proxies residenciais com geo-localização — IPs que o Google reconhece como pertencentes a um ISP residencial real na região alvo.
- Parâmetros
glehlalinhados —gl=US&hl=enpara o mercado americano,gl=DE&hl=depara o alemão.
Com a ProxyHat, você controla isso via flags no username. Para o mercado americano:
http://user-country-US:pass@gate.proxyhat.com:8080Para o mercado alemão, com geo de cidade:
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080Essa combinação de IP residencial + parâmetros de URL alinhados é o que faz o Google retornar a versão correta do Shopping. Usar um IP de datacenter com gl=DE frequentemente não funciona — o Google detecta a inconsistência entre o IP e o parâmetro e pode retornar resultados genéricos ou acionar um desafio.
Exemplo prático em Python com ProxyHat
Vamos construir um Google Shopping price scraper funcional em Python usando requests e BeautifulSoup, roteando através da ProxyHat com geo-localização dos EUA.
import requests
from bs4 import BeautifulSoup
import urllib.parse
import random
import time
# Credenciais ProxyHat com geo dos EUA
PROXY_USER = "user-country-US"
PROXY_PASS = "SUA_SENHA"
PROXY_URL = f"http://{PROXY_USER}:{PROXY_PASS}@gate.proxyhat.com:8080"
proxies = {
"http": PROXY_URL,
"https": PROXY_URL,
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ("
"KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
}
def scrape_google_shopping(query, gl="US", hl="en"):
encoded_q = urllib.parse.quote(query)
url = f"https://www.google.com/search?tbm=shop&q={encoded_q}&gl={gl}&hl={hl}"
try:
resp = requests.get(url, proxies=proxies, headers=headers, timeout=30)
except requests.exceptions.RequestException as e:
print(f"Erro de requisição: {e}")
return []
# Detectar soft-block
if resp.status_code == 429 or "sorry/index" in resp.url:
print("Soft-block detectado. Pausando e rotacionando IP.")
return ["BLOCKED"]
soup = BeautifulSoup(resp.text, "html.parser")
results = []
# Contêineres de produtos
product_cards = soup.select(".sh-dgr__content")
for card in product_cards[:5]: # truncado para exemplo
title_el = card.select_one(".sh-dgr__offer-title, h3")
price_el = card.select_one(".a8Pemb")
seller_el = card.select_one(".sh-dgr__seller")
rating_el = card.select_one("[aria-label*='rated']")
title = title_el.get_text(strip=True) if title_el else "N/A"
price = price_el.get_text(strip=True) if price_el else "N/A"
seller = seller_el.get_text(strip=True) if seller_el else "N/A"
rating = rating_el.get("aria-label", "N/A") if rating_el else "N/A"
results.append({
"title": title,
"price": price,
"seller": seller,
"rating": rating,
})
return results
# Exemplo de uso
if __name__ == "__main__":
data = scrape_google_shopping("macbook pro 14 M4", gl="US", hl="en")
for item in data:
print(item)Exemplo de resposta truncada:
{
'title': 'Apple MacBook Pro 14" M4 Pro',
'price': '$1,799.00',
'seller': 'Amazon.com',
'rating': 'Rated 4.8 out of 5'
}
{
'title': 'Apple MacBook Pro 14" M4 Pro',
'price': '$1,849.00',
'seller': 'Best Buy',
'rating': 'Rated 4.7 out of 5'
}Note o uso de user-country-US no username do proxy. Isso garante que a ProxyHat atribua um IP residencial americano, alinhado com gl=US na URL. Para o mercado alemão, troque para user-country-DE-city-berlin e ajuste gl=DE&hl=de.
Paginação, batching, delays e detecção de soft-blocks
Raspar Google Shopping em escala exige estratégia. Aqui estão as práticas recomendadas.
Paginação
O Google Shopping paginha resultados via parâmetro start na URL. A primeira página usa start=0, a segunda start=20, e assim por diante. O Google tipicamente limita a profundidade a 10–15 páginas (200–300 resultados) por consulta. Além disso, resultados além da página 5–6 frequentemente têm qualidade reduzida e menor relevância.
for page in range(0, 80, 20): # 4 páginas
url = f"https://www.google.com/search?tbm=shop&q={q}&gl={gl}&hl={hl}&start={page}"
# ... requisição e parsingQuery batching
Se você está monitorando milhares de produtos, agrupe consultas em lotes. Em vez de fazer 10.000 requisições individuais, processe em lotes de 100–200 com pausas entre lotes. Isso reduz a probabilidade de qualquer IP individual acumular sinais de risco suficientes para acionar um bloqueio.
Delays randomizados
Nunca use delays fixos. O Google detecta padrões regulares de tempo entre requisições. Use delays aleatórios entre 3 e 8 segundos entre requisições, com pausas mais longas (15–30 segundos) a cada 50–100 requisições.
delay = random.uniform(3.0, 8.0)
time.sleep(delay)
# Pausa longa periódica
if request_count % 50 == 0:
time.sleep(random.uniform(15.0, 30.0))Detecção de soft-blocks
Um soft-block é o aviso antes do bloqueio total. Detecte-o cedo para evitar banimentos:
- HTTP 429 — Too Many Requests. Pausa imediata de 10–15 minutos e rotação de IP.
- Redirecionamento para
/sorry/index— verifique sesorry/indexestá na URL final. - HTML sem resultados — se a página carrega mas não contém
.sh-dgr__content, pode ser uma versão degradada do SERP. - CAPTCHA inline — se
recaptchaaparece no HTML, o IP está marcado.
Implemente um circuit breaker: se mais de 5% das requisições em um lote retornarem soft-blocks, pause o scraping por 30–60 minutos e troque todos os IPs.
Erros comuns e casos de borda
1. Conflito entre geo do proxy e parâmetros gl/hl
O erro mais comum: usar gl=DE na URL mas um IP americano no proxy. O Google detecta a inconsistência e pode retornar resultados americanos ou acionar um desafio. Sempre alinhe o país do proxy com o parâmetro gl.
2. User-Agent desatualizado
User-Agents antigos ou inconsistentes são bandeiras vermelhas. Use um User-Agent recente do Chrome ou Firefox, e mantenha o Accept-Language consistente com o mercado alvo (de-DE,de;q=0.9 para Alemanha, en-US,en;q=0.9 para EUA).
3. Ignorar a página de detalhe do produto
O SERP tbm=shop mostra apenas o preço do vendedor principal. Para capturar todos os vendedores e preços de um produto, você precisa visitar a página /shopping/product/PRODUCT_ID e raspar o painel de ofertas. Muitos scrapers param no SERP e perdem 70–80% dos dados de preço.
4. Não respeitar robots.txt
Verifique o robots.txt do Google. Embora o caminho /search não seja totalmente bloqueado para crawlers conhecidos, é importante entender as regras. Use google.com/robots.txt como referência.
Configuração específica da ProxyHat e links úteis
A ProxyHat oferece proxies residenciais, móveis e de datacenter. Para Google Shopping, recomendamos fortemente os proxies residenciais com geo-localização por país e cidade, pois eles são os únicos que o Google trata como tráfego legítimo de consumidor.
Configuração recomendada:
| Parâmetro | Valor |
|---|---|
| Gateway | gate.proxyhat.com |
| Porta HTTP | 8080 |
| Porta SOCKS5 | 1080 |
| Tipo recomendado | Residencial rotativo |
| Geo para EUA | user-country-US |
| Geo para Alemanha | user-country-DE-city-berlin |
| Sessão sticky | user-session-abc123 |
Para sessões sticky (úteis quando você precisa manter o mesmo IP por algumas requisições para paginação consistente):
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080Para SOCKS5 (útil quando você precisa de menor latência ou roteamento via protocolo diferente):
socks5://user-country-US:pass@gate.proxyhat.com:1080Consulte a documentação oficial da ProxyHat para detalhes completos de configuração. Para ver preços e planos, visite /pt/pricing. Para explorar as localizações disponíveis, veja /pt/locations. Leia também nossos guias de web scraping e SERP tracking.
Ética, TOS e considerações legais
Raspar Google Shopping levanta questões legais e éticas que você deve considerar seriamente.
Dados públicos apenas
Este guia trata exclusivamente de dados de preço publicamente visíveis — informações que qualquer consumidor veria ao visitar o Google Shopping. Não cobrimos raspagem de dados protegidos por login, conteúdo premium ou informações pessoais.
Computer Fraud and Abuse Act (CFAA)
Nos EUA, o CFAA (18 U.S.C. § 1030) criminaliza acesso não autorizado a sistemas de computador. A interpretação de "não autorizado" no contexto de raspagem de dados públicos é complexa e tem sido litigada. O caso Van Buren v. United States (2021) estreitou a definição de acesso excedido, mas a aplicação ao scraping permanece em área cinzenta. Consulte um advogado antes de operar em escala comercial.
GDPR
Na União Europeia, o GDPR regula o processamento de dados pessoais. Dados de preço de produtos geralmente não são dados pessoais, mas se você coleta avaliações de usuários, nomes de revisores ou qualquer informação que possa identificar um indivíduo, o GDPR se aplica. Tenha uma base legal e política de retenção adequada.
Termos de Serviço do Google
Os TOS do Google proíbem raspagem automatizada sem permissão. Violar TOS pode resultar em banimento de contas Google e, em alguns contextos, ação legal. Para uso comercial em escala, considere:
- Parcerias oficiais do Google Shopping para dados de produto.
- APIs de SERP de terceiros licenciadas.
- Coleta manual para volumes baixos.
Este artigo é educacional e não constitui aconselhamento jurídico. Sempre consulte um advogado qualificado para sua situação específica.
Principais conclusões
Key Takeaways:
- A Content API for Shopping do Google só serve dados do próprio lojista — dados competitivos exigem raspagem do HTML do SERP
tbm=shop.- Use proxies residenciais com geo-localização por país/cidade alinhada aos parâmetros
gl/hlpara capturar preços localizados corretos.- Detecção de soft-blocks (HTTP 429,
sorry/index, HTML vazio) deve pausar o scraping e rotacionar IPs antes de um banimento.- Delays randomizados de 3–8 segundos e pausas periódicas reduzem a probabilidade de detecção.
- A página de detalhe
/shopping/product/contém todos os vendedores e preços — não pare no SERP.- Considere o contexto legal (CFAA, GDPR, TOS do Google) e consulte um advogado para uso comercial em escala.
Com a ProxyHat, você tem acesso a milhares de IPs residenciais com geo-localização precisa, rotação automática e sessões sticky para paginação consistente. Comece hoje explorando nossos planos em /pt/pricing e veja as localizações disponíveis em /pt/locations.
