← Voltar ao blog

Google Sheets IMPORTXML atingiu limites: 7 sinais de que é hora de usar seu próprio parser com proxy

Se o IMPORTXML no Google Sheets começou a apresentar erros #N/A, travar ou bloquear seu IP ao monitorar os preços dos concorrentes, é hora de rever a abordagem. Vamos analisar quando exatamente esse momento ocorre e como migrar para um parser próprio com proxy sem perda de dados.

📅2 de novembro de 2026

Se você está monitorando os preços dos concorrentes no Wildberries, Ozon ou Avito através do IMPORTXML no Google Sheets, mais cedo ou mais tarde a tabela começa a apresentar erros #N/A, os dados são atualizados com um atraso de horas e, às vezes, simplesmente param de ser puxados. Isso não é um bug — é um esbarrão nos limites do próprio Google Sheets e na proteção dos sites contra solicitações em massa de um mesmo endereço IP do Google. Neste artigo, vamos analisar quais sinais indicam que a tabela esgotou seus recursos e como mudar para seu próprio parser com proxy sem dor.

Como funciona o IMPORTXML e por que é utilizado

IMPORTXML — é uma função embutida do Google Sheets que extrai dados de uma página usando uma consulta XPath e insere-os diretamente em uma célula. A fórmula do tipo =IMPORTXML("URL"; "//span[@class='price']") permite, sem uma única linha de código, extrair o preço de um produto na página do Wildberries ou Ozon e atualizá-lo automaticamente a cada hora.

Para vendedores e profissionais de marketing, isso parece uma solução ideal: não é necessário um desenvolvedor, não é necessário um servidor, tudo funciona diretamente na tabela familiar. Uma pequena loja com 20-30 produtos realmente pode sobreviver por anos apenas com um IMPORTXML, sem perceber problemas. Mas assim que o número de SKUs monitorados ultrapassa algumas centenas, e a frequência de atualização necessária não é uma vez por dia, mas uma vez por hora — começam a ocorrer falhas sistêmicas que não podem ser resolvidas apenas com as configurações da função.

O problema é que todas as solicitações do IMPORTXML são feitas a partir dos servidores do Google, e não do seu computador. O Google tem um conjunto limitado de endereços IP para essas solicitações, e os marketplaces conhecem bem esses intervalos. Quando o número de solicitações aumenta, a proteção do site é acionada — e em vez do preço na célula, aparece um erro ou um valor vazio.

7 sinais de que o IMPORTXML já não está funcionando

Antes de gastar tempo mudando para uma solução mais complexa, certifique-se de que o problema está realmente nos limites, e não em um erro de digitação na fórmula. Aqui estão os sintomas específicos que indicam isso:

  1. Massivas #N/A — 30-50% das fórmulas param de funcionar ao mesmo tempo, embora ontem tudo estivesse normal e a estrutura das páginas não tenha mudado.
  2. Atraso na atualização aumenta — antes os dados eram atualizados em 5-10 minutos, agora a tabela "pensa" por 30-40 minutos ou não atualiza de forma alguma sem um recálculo manual.
  3. Erro "Resource at url contacted too many times" — uma mensagem direta do Google informando que você atingiu o limite interno de solicitações a um único domínio.
  4. Dados chegam desatualizados — o preço na tabela difere do real no site, porque o Google retorna uma versão em cache da página em vez da atual.
  5. Número de linhas excede 300-500 — quanto mais fórmulas IMPORTXML em um único documento, maior a chance de um banimento coletivo por domínio.
  6. Necessidade de frequência de atualização maior que uma vez por hora — o IMPORTXML não é fisicamente projetado para monitoramento em tempo real, não possui um mecanismo de rotação de IP.
  7. O site exige autenticação ou captcha — Wildberries e Ozon cada vez mais exibem páginas com verificação JavaScript, que o IMPORTXML não consegue passar.

Se você se identificou com pelo menos 2-3 itens da lista — isso não é um erro temporário do Google Sheets, mas um limite estrutural da tecnologia. A partir daí, você pode consertar as fórmulas infinitamente, adicionar IFERROR e recalcular manualmente, mas o volume de trabalho manual crescerá mais rápido do que o volume de dados úteis.

Por que os sites bloqueiam solicitações do Google Sheets

Marketplaces como Wildberries e Ozon recebem diariamente milhões de solicitações automáticas de concorrentes, serviços de análise e bots. Para não sobrecarregar os servidores e proteger os dados de preços contra a extração em massa, eles implementam vários níveis de proteção:

  • Limitação de taxa por IP — se um único endereço recebe mais de N solicitações por minuto, o IP é temporariamente bloqueado.
  • Análise de User-Agent — as solicitações dos bots do Google para IMPORTXML são facilmente diferenciadas de um navegador comum pelos cabeçalhos.
  • Renderização JavaScript — parte do conteúdo é carregada dinamicamente através de scripts, e o IMPORTXML vê apenas o HTML original sem executar o JS.
  • Geo-filtragem — solicitações de IPs de servidores do Google frequentemente caem sob o filtro "não se parece com um comprador real".

O principal problema é que todos os usuários do IMPORTXML em todo o mundo tecnicamente usam o mesmo conjunto limitado de endereços IP de servidores do Google. Quando milhares de tabelas puxam simultaneamente o mesmo domínio Wildberries, a proteção do site bloqueia não um usuário específico, mas um intervalo inteiro — e todos sofrem, inclusive você.

IMPORTXML vs parser sem código vs seu parser: tabela de comparação

Mudar da função embutida do Google Sheets não significa necessariamente contratar um programador. Existem opções intermediárias. Vamos comparar três abordagens com base em parâmetros-chave:

Critério IMPORTXML Parser sem código (Octoparse, ParseHub) Seu parser com proxy
Necessita de código Não Não Sim (ou contratado)
Limite de solicitações Rígido, oculto Depende do plano Você controla
Rotação de IP Indisponível Parcialmente embutida Controle total através de proxy
Trabalho com páginas JS Não Sim Sim (com Selenium/Playwright)
Frequência de atualização Uma vez por hora ou menos Configurável Qualquer uma, até em tempo real
Escala (SKU) Até 200-300 Até várias milhares Sem limitações práticas

Parsers sem código são um bom passo intermediário, se você precisa fechar a tarefa rapidamente sem um desenvolvedor. Mas se o monitoramento de preços é um processo de negócios contínuo, e não uma tarefa única, seu parser com proxy se paga pelo controle sobre os dados e pela ausência de dependência de serviços externos e seus limites.

Quais proxies são necessários para a extração de dados de marketplaces

A principal razão pela qual seu parser funciona de forma mais estável que o IMPORTXML é a capacidade de distribuir as solicitações entre diferentes endereços IP em vez de um único pool de servidores do Google. Mas o tipo de proxy também é importante:

  • Proxies de datacenter — a opção mais rápida e acessível para começar. Adequados se o marketplace ainda não reconheceu o padrão de solicitações automáticas. Bons para os primeiros testes do parser e um pequeno número de SKUs.
  • Proxies residenciais — usam endereços IP reais de provedores domésticos, portanto, parecem para Wildberries e Ozon como compradores comuns. Esta é a opção principal para monitoramento regular de preços em larga escala, quando é importante não ser bloqueado por geolocalização ou padrão de tráfego.
  • Proxies móveis — IPs de operadores móveis, que os marketplaces bloqueiam muito relutantemente, pois um único IP móvel frequentemente atende milhares de usuários diferentes ao mesmo tempo. Relevantes se a extração for através das versões móveis do site ou aplicativo.

Para começar o monitoramento de preços no Wildberries e Ozon, a combinação ideal é: proxies residenciais com rotação de IP a cada solicitação ou a cada poucos minutos. Isso reduz o risco de atingir o limite de taxa e permite distribuir milhares de solicitações entre centenas de endereços diferentes, simulando o comportamento de usuários comuns de diferentes regiões.

Plano passo a passo para mudar para seu parser

Mudar do IMPORTXML não requer uma parada total do trabalho — a tabela pode ser mantida como um canal de reserva enquanto o novo parser passa por testes.

  1. Registre a lista de SKUs e seletores XPath que já foram usados nas fórmulas IMPORTXML — isso é um mapa de dados pronto para a nova solução.
  2. Escolha o formato do parser: serviço sem código (Octoparse, ParseHub, Apify) para um início rápido sem programador, ou um script em Python/Node.js, se houver um desenvolvedor ou freelancer na equipe.
  3. Conecte proxies com rotação de IP. Sem isso, o novo parser enfrentará os mesmos bloqueios que o IMPORTXML, apenas um pouco mais tarde.
  4. Configure um cronograma de solicitações com pequenos atrasos aleatórios entre as solicitações (2-5 segundos) — isso reduz a probabilidade de ativar a proteção por padrão.
  5. Envie os dados de volta para o Google Sheets através da API do Google Sheets ou um serviço como Zapier/Make, para não quebrar os relatórios e dashboards familiares da equipe.
  6. Teste em 10-15% dos produtos durante uma semana, comparando a precisão com os dados das antigas fórmulas IMPORTXML, antes de mudar completamente.
  7. Configure alertas para erros — notificação no Telegram ou e-mail, se o parser começar a receber captchas ou código 403, para mudar imediatamente o proxy ou reduzir a frequência das solicitações.

Parser mínimo em Python com proxy

Se há um desenvolvedor na equipe, a versão básica do parser ocupa literalmente algumas dezenas de linhas de código. Abaixo está um exemplo simplificado de uma solicitação de página de produto através de proxy usando a biblioteca requests:

import requests
import time
import random

proxies = {
    "http": "http://login:senha@proxy_host:porta",
    "https": "http://login:senha@proxy_host:porta",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36"
}

urls = [
    "https://example-marketplace.com/product/12345",
    "https://example-marketplace.com/product/67890",
]

for url in urls:
    try:
        response = requests.get(url, headers=headers, proxies=proxies, timeout=10)
        if response.status_code == 200:
            # aqui você pode fazer o parsing do preço com BeautifulSoup ou lxml
            print(f"OK: {url}")
        else:
            print(f"Status {response.status_code} para {url}")
    except requests.exceptions.RequestException as e:
        print(f"Erro na solicitação: {e}")

    time.sleep(random.uniform(2, 5))  # pausa entre as solicitações

Para páginas com carregamento dinâmico de preços via JavaScript (característico do Wildberries e Ozon), em vez do requests comum, será necessário usar Selenium ou Playwright, que conseguem renderizar a página como um navegador real e também suportam a passagem de proxies através de parâmetros de inicialização.

Checklist antes do lançamento

  • Lista de URLs e seletores de dados transferida das antigas fórmulas IMPORTXML
  • Proxies conectados com rotação de IP (residenciais ou móveis para marketplaces)
  • Atrasos aleatórios configurados entre as solicitações (2-5 segundos)
  • User-Agent realista e cabeçalhos de navegador em cada solicitação
  • Registro de erros e alertas configurados para código 403/captcha
  • Dados exportados no formato familiar (Google Sheets, CRM, BI-dashboard)
  • Teste realizado na primeira ou segunda semana em uma amostra de produtos antes da mudança completa

Conclusão

O IMPORTXML é uma excelente ferramenta para começar, enquanto a lista de produtos é pequena e a frequência de atualização não é crítica. Mas assim que você começa a ver massivas #N/A, atrasos crescentes e mensagens diretas de erro de limite — isso é um sinal de que a função embutida do Google Sheets atingiu seu limite arquitetônico. Tecnicamente, isso não pode ser corrigido apenas com configurações da tabela, pois o problema está no conjunto limitado de endereços IP do Google, que os marketplaces bloqueiam por completo.

Mudar para seu próprio parser, seja um serviço sem código ou um script em Python, resolve o problema exatamente pelo controle sobre os endereços IP das solicitações. Se você planeja monitorar regularmente os preços no Wildberries, Ozon ou Avito em larga escala, recomendamos começar com proxies residenciais — eles oferecem o menor risco de bloqueio devido à semelhança com o tráfego de compradores reais. Para testes rápidos no início, você pode usar proxies de datacenter mais acessíveis, e para cenários com versões móveis dos sites — considerar proxies móveis.