Por que o parser mostra a região errada do site: Accept-Language, moeda e cookies geográficos

O parser é iniciado, o código não falha, os dados chegam — mas os preços estão em dólares em vez de rublos, o texto está em inglês, e os produtos diferem daqueles que um usuário real na Rússia vê. Este é um dos problemas mais comuns e frustrantes da extração de dados: tecnicamente tudo funciona, mas o conteúdo é "diferente". Vamos analisar por que isso acontece e como montar uma solicitação que obtenha exatamente a versão da página que você precisa.

Sintomas: como entender que o parser vê a versão errada

Antes de corrigir o problema, é importante diagnosticá-lo corretamente. Existem três cenários típicos que fazem com que o parser receba dados diferentes do que um usuário comum do navegador vê:

• O idioma do conteúdo não coincide — você espera texto em russo, mas recebe a versão em inglês ou ucraniano da página.
• A moeda e os preços diferem — o site mostra o preço em USD ou EUR, enquanto no navegador da Rússia você vê rublos, ou os números simplesmente são diferentes (formação de preços regional).
• O catálogo de produtos/conteúdo é diferente — a disponibilidade de produtos, promoções, a vitrine como um todo dependem da região que o site "viu" em você.

A razão é quase sempre uma das três (ou uma combinação delas): o cabeçalho Accept-Language, cookies ausentes ou incorretos, ou a geolocalização do endereço IP de onde a solicitação está sendo feita. Vamos analisar cada um por ordem.

Accept-Language: como o servidor escolhe o idioma da resposta

O navegador envia a cada solicitação o cabeçalho Accept-Language, que lista os idiomas preferidos do usuário com pesos (valores q). Um exemplo do que realmente o Chrome envia com a localidade russa:

Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

Bibliotecas para extração de dados (requests, httpx, scrapy) por padrão ou não enviam esse cabeçalho, ou enviam algo como */*. O servidor, nesse caso, ou fornece o idioma padrão (geralmente inglês), ou determina o idioma pelo IP — e é aqui que a parte geo entra em jogo, sobre a qual falaremos a seguir.

Um ponto importante: muitos sites usam a combinação "Accept-Language + geolocalização IP", e não apenas um deles. Ou seja, mesmo que você envie o cabeçalho de idioma correto, se a solicitação vem de um IP de outro país, o site pode ainda assim alternar você para a versão em inglês ou local para a região de onde a solicitação realmente veio.

Moeda e localidade: de onde o site obtém os preços

A moeda quase nunca é determinada diretamente pelo cabeçalho Accept-Language. Geralmente, um dos três mecanismos (ou uma combinação deles) é utilizado:

1. Base GeoIP — o servidor verifica de qual país o IP veio e insere automaticamente a moeda e a localidade correspondentes na primeira visita.
2. Cookie com a região escolhida anteriormente — se o usuário alguma vez escolheu manualmente o país e a moeda, o site salva isso em um cookie e não verifica mais o IP.
3. Parâmetro na URL ou subdomínio — alguns sites usam marcadores explícitos como ?country=ru ou ru.example.com.

Na prática, se você está extraindo dados de uma loja online e vê preços em dólares em vez de rublos, em 80% dos casos o problema não está nos cabeçalhos, mas sim no endereço IP da solicitação. O site simplesmente "viu" um IP não russo e inseriu a vitrine internacional padrão.

Geo-cookie: como o site lembra a região escolhida

Depois que o site uma vez determinou sua região (por IP ou pela escolha manual em um banner "Escolha sua cidade"), ele salva essa decisão em um cookie — geralmente com nomes como region, geo_city, currency ou locale. A partir daí, todas as solicitações com esse cookie são processadas de acordo com a região salva — mesmo que o IP mude repentinamente.

Isso cria uma armadilha para o parser: se você uma vez obteve a "versão errada" e salvou o cookie da sessão, todas as solicitações subsequentes reproduzirão o mesmo erro, mesmo que você corrija os cabeçalhos ou o proxy. Portanto, ao diagnosticar, sempre verifique a extração com uma sessão limpa — sem cookies salvos de execuções anteriores.

O lado oposto da mesma mecânica é útil: se você conhece o nome do cookie necessário e seu valor correto para a região-alvo (por exemplo, se você o viu nas DevTools do navegador na localização desejada), pode forçar esse valor na solicitação, sem mudar o IP. Isso funciona para sites onde a região é determinada apenas através de um cookie-flag, mas não funciona se o servidor verifica novamente o IP com a base GeoIP a cada solicitação.

O papel do endereço IP e do proxy na determinação da região

A determinação GeoIP é a maneira mais confiável para o site entender de onde a solicitação realmente veio, porque cabeçalhos e cookies podem ser falsificados, mas o endereço IP não pode ser falsificado (pode apenas ser substituído por outro real). É por isso que, para obter de forma estável a "versão correta" regional da página, não basta apenas os cabeçalhos HTTP — é necessário um IP que realmente pertença ao país desejado.

Aqui há uma diferença significativa entre os tipos de endereços IP:

• IP de data centers — as bases GeoIP frequentemente os identificam corretamente por país, mas muitos sites grandes (especialmente marketplaces e serviços com proteção contra bots) marcam intervalos de data centers como suspeitos e podem mostrar uma versão reduzida ou padrão do conteúdo, independentemente da geolocalização.
• IPs residenciais — pertencem a provedores reais e endereços físicos, portanto a GeoIP determina a região com mais precisão, e o site percebe a solicitação como se fosse um usuário comum desse país/cidade.
• IPs móveis — estão vinculados a operadoras móveis de um país específico, o que é especialmente importante para sites e aplicativos que tratam de maneira diferente o tráfego móvel e de desktop.

Para tarefas como monitoramento de preços na Wildberries, Ozon ou Avito de cidades específicas, os proxies residenciais são os mais adequados — eles fornecem IPs vinculados a uma região real, e as bases GeoIP dos sites determinam o país e a cidade corretamente, sem substituir pela vitrine internacional padrão.

Prática: montando a solicitação correta em Python

Vamos montar uma solicitação que resolve simultaneamente todos os três problemas: envia um Accept-Language correto, usa uma sessão limpa com os cookies necessários e passa pelo IP da região desejada.

import requests

proxies = {
    "http": "http://user:[email protected]:8080",
    "https": "http://user:[email protected]:8080",
}

headers = {
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/124.0.0.0 Safari/537.36",
}

cookies = {
    "region": "ru",
    "currency": "RUB",
}

session = requests.Session()
response = session.get(
    "https://example.com/catalog",
    headers=headers,
    cookies=cookies,
    proxies=proxies,
    timeout=15,
)

print(response.status_code)
print(response.text[:500])

Alguns pontos importantes neste código:

• É utilizada requests.Session(), e não uma única requests.get(), para que, se necessário, o servidor possa estabelecer cookies adicionais, e eles sejam salvos entre as solicitações de uma mesma sessão de extração.
• Os valores dos cookies region e currency são condicionais, seus nomes e valores reais precisam ser verificados nas DevTools do navegador (aba Application → Cookies) no site alvo com a localização desejada.
• O proxy deve realmente estar no país desejado — caso contrário, mesmo os cabeçalhos e cookies corretos podem ser sobrescritos pelo servidor ao reavaliar a geolocalização.

Sites JS: Playwright e gerenciamento de cabeçalhos/cookies

Se o site renderiza conteúdo através de JavaScript (os preços são carregados em uma solicitação separada após o carregamento da página), uma simples solicitação requests não é suficiente — é necessário um navegador headless. No Playwright, a localidade, idioma e proxy são definidos no nível do contexto do navegador:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    context = browser.new_context(
        locale="ru-RU",
        timezone_id="Europe/Moscow",
        proxy={
            "server": "http://gate.proxycove.com:8080",
            "username": "user",
            "password": "pass",
        },
    )
    context.add_cookies([
        {"name": "region", "value": "ru", "domain": "example.com", "path": "/"},
        {"name": "currency", "value": "RUB", "domain": "example.com", "path": "/"},
    ])

    page = context.new_page()
    page.goto("https://example.com/catalog")
    page.wait_for_selector(".price")
    print(page.content()[:500])

    browser.close()

Preste atenção ao parâmetro timezone_id — muitos sites verificam adicionalmente o fuso horário do navegador com o esperado para a região, e a discrepância (por exemplo, IP da Rússia, mas o fuso horário do navegador é americano) pode ser um sinal para o sistema anti-bots de que a solicitação é suspeita, mesmo que o idioma e a moeda estejam formalmente corretos.

Erros comuns e checklist antes da execução

Antes de executar o parser em produção, passe por um breve checklist — isso economiza horas de depuração:

• ✅ O cabeçalho Accept-Language está definido e corresponde à região esperada.
• ✅ A sessão está limpa — os cookies não foram herdados de uma solicitação anterior malsucedida.
• ✅ O IP do proxy está fisicamente localizado no país desejado (verifique através de qualquer verificador geo-IP antes da extração).
• ✅ O User-Agent corresponde a um navegador real e não contém sinais de modo headless.
• ✅ O fuso horário e a localidade do navegador (para Playwright/Selenium) coincidem com o país do IP.
• ✅ Se o site usa a escolha manual da região em um banner — os cookies dessa escolha são passados manualmente.

É importante mencionar sobre a rotação de proxies: se você muda o IP a cada solicitação, mas os cookies da sessão permanecem os mesmos, o site pode ver a inconsistência "cookie da região A, mas IP da região B" e reiniciar a sessão. Para tarefas de monitoramento de preços, é melhor manter um IP fixo durante toda a sessão de extração de uma região específica, em vez de rotacioná-lo no meio da coleta de dados.

Qual tipo de proxy escolher para a tarefa

A escolha do tipo de proxy afeta diretamente a precisão com que o site determinará sua região e não suspeitará da automação. Aqui está uma comparação para tarefas típicas de extração de versões regionais de sites:

Tipo de proxy	Precisão da geolocalização	Quando usar
Proxies de data centers	Média, país correto, mas o IP pode ser marcado como "não residencial"	Extração de sites sem proteção rigorosa contra bots, alta velocidade e volume de solicitações
Proxies residenciais	Alta, até a cidade	Monitoramento de preços em marketplaces, conteúdo regional, contornando verificações GeoIP
Proxies móveis	Alta, além da marcação da operadora móvel	Sites e aplicativos que funcionam de maneira diferente com o tráfego móvel de um país específico

Se a tarefa é monitorar o catálogo e os preços em marketplaces de diferentes cidades, os proxies residenciais geralmente oferecem o resultado mais previsível: as bases GeoIP veem um endereço residencial real, e não um intervalo de data center, que alguns sites processam com lógica separada.

Conclusão

O problema "o parser vê a versão errada da página" quase sempre se resume a três fatores: o cabeçalho Accept-Language, que determina o idioma preferido da resposta; cookies, que lembram a região e a moeda escolhidas anteriormente; e a geolocalização do endereço IP, com base na qual o servidor determina o país da solicitação na primeira visita. Para obter exatamente a versão do site que um usuário real vê, é necessário sincronizar todos os três parâmetros simultaneamente, e não corrigi-los separadamente.

Se você regularmente extrai versões regionais de sites, monitora preços de concorrentes em marketplaces ou coleta dados de diferentes países, é aconselhável começar pela escolha do IP adequado — as outras configurações (cabeçalhos, cookies, fuso horário) são ajustadas em torno dele. Para atingir com precisão a região desejada, recomendamos experimentar proxies residenciais, que oferecem geolocalização previsível e minimizam o risco de obter a versão internacional padrão do site em vez da local.