Accept-Language, moneda y geo-cookie: estamos arreglando el parser.

El parser se inicia, el código no falla, los datos llegan, pero los precios están en dólares en lugar de rublos, el texto está en inglés, y los productos son diferentes de los que ve un usuario real en Rusia. Este es uno de los problemas más comunes y frustrantes del scraping: técnicamente todo funciona, pero el contenido "no es el correcto". Vamos a analizar por qué sucede esto y cómo construir una solicitud que obtenga exactamente la versión de la página que necesita.

Síntomas: cómo entender que el parser ve la versión incorrecta

Antes de solucionar el problema, es importante diagnosticarlo correctamente. Hay tres escenarios típicos por los cuales el parser recibe datos diferentes a los que ve un usuario normal del navegador:

El idioma del contenido no coincide — usted espera texto en ruso, pero recibe una versión en inglés o ucraniano de la página.
La moneda y los precios son diferentes — el sitio muestra el precio en USD o EUR, aunque en el navegador desde Rusia usted ve rublos, o simplemente los números son diferentes (precios regionales).
El catálogo de productos/contenido es diferente — la disponibilidad de productos, promociones, la vitrina en su totalidad dependen de la región que el sitio "vio" en usted.

La razón casi siempre es una de las tres (o una combinación de ellas): el encabezado Accept-Language, cookies faltantes o incorrectas, o la geolocalización de la dirección IP desde la que se realiza la solicitud. Vamos a analizar cada uno en orden.

Accept-Language: cómo el servidor elige el idioma de respuesta

El navegador envía en cada solicitud el encabezado Accept-Language, en el que se enumeran los idiomas preferidos del usuario con pesos (valores q). Un ejemplo de lo que realmente envía Chrome con la configuración regional rusa:

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

Las bibliotecas para scraping (requests, httpx, scrapy) por defecto o no envían este encabezado en absoluto, o envían algo como */*. En este caso, el servidor o devuelve el idioma por defecto (más a menudo inglés), o determina el idioma por IP — y aquí es donde entra en juego la parte geográfica, de la que hablaremos a continuación.

Un matiz importante: muchos sitios utilizan precisamente la combinación "Accept-Language + geolocalización IP", y no solo uno de ellos. Es decir, incluso si envía el encabezado de idioma correcto, pero la solicitud proviene de una IP de otro país, el sitio puede aún así cambiarlo a la versión en inglés o local para la región de donde realmente provino la solicitud.

Moneda y localización: de dónde obtiene el sitio los precios

La moneda casi nunca se determina directamente por el encabezado Accept-Language. Más bien, se utiliza uno de tres mecanismos (o una combinación de ellos):

Base de datos GeoIP — el servidor verifica de qué país proviene la IP y asigna automáticamente la moneda y la localización correspondientes en la primera visita.
Cookie con la región previamente seleccionada — si el usuario alguna vez eligió manualmente el país y la moneda, el sitio guarda esto en una cookie y ya no verifica la IP.
Parámetro en la URL o subdominio — algunos sitios utilizan marcadores explícitos como ?country=ru o ru.example.com.

En la práctica, si está scraping un comercio electrónico y ve precios en dólares en lugar de rublos, en el 80% de los casos no se trata de los encabezados, sino de la dirección IP de la solicitud. El sitio simplemente "vio" una IP no rusa y asignó la vitrina internacional por defecto.

Después de que el sitio determina su región una vez (por IP o por selección manual en el banner "Seleccione su ciudad"), guarda esta decisión en una cookie — generalmente con nombres como region, geo_city, currency o locale. Luego, todas las solicitudes con esta cookie se procesan según la región guardada — incluso si la IP cambia repentinamente.

Esto crea una trampa para el parser: si una vez obtuvo la "versión incorrecta" y guardó la cookie de la sesión, todas las solicitudes posteriores reproducirán el mismo error, incluso si corrige los encabezados o el proxy. Por lo tanto, al diagnosticar, siempre verifique el scraping con una sesión limpia — sin cookies guardadas de ejecuciones anteriores.

El lado opuesto de la misma mecánica es útil: si conoce el nombre de la cookie necesaria y su valor correcto para la región objetivo (por ejemplo, lo vio en DevTools del navegador en la ubicación deseada), puede forzar este valor en la solicitud sin cambiar la IP. Esto funciona para sitios donde la región se determina solo a través de la cookie, pero no funciona si el servidor verifica la IP con la base de datos GeoIP en cada solicitud.

El papel de la dirección IP y el proxy en la determinación de la región

La determinación GeoIP es la forma más confiable para que el sitio entienda de dónde proviene realmente la solicitud, porque los encabezados y las cookies se pueden falsificar, pero la dirección IP no se puede falsificar (solo se puede cambiar por otra real). Es por eso que para obtener de manera estable la "versión correcta" regional de la página no son suficientes solo los encabezados HTTP — se necesita una IP que realmente pertenezca al país deseado.

Aquí hay una diferencia significativa entre los tipos de direcciones IP:

IP de centros de datos — las bases de datos GeoIP a menudo las identifican correctamente por país, pero muchos sitios grandes (especialmente marketplaces y servicios con protección contra bots) marcan los rangos de centros de datos como sospechosos y pueden mostrar una versión reducida o por defecto del contenido independientemente de la geolocalización.
IP residenciales — pertenecen a proveedores reales y direcciones físicas, por lo que GeoIP determina la región con mayor precisión, y el sitio percibe la solicitud como la de un usuario normal de ese país/ciudad.
IP móviles — están vinculadas a operadores móviles de un país específico, lo que es especialmente importante para sitios y aplicaciones que funcionan de manera diferente con el tráfico móvil y de escritorio.

Para tareas como el monitoreo de precios en Wildberries, Ozon o Avito desde ciudades específicas, los proxies residenciales son los más adecuados — proporcionan IP vinculadas a una región real, y las bases de datos GeoIP de los sitios determinan el país y la ciudad correctamente, sin cambiar a la vitrina internacional por defecto.

Práctica: construyendo la solicitud correcta en Python

Construyamos una solicitud que resuelva simultáneamente los tres problemas: envía un Accept-Language correcto, utiliza una sesión limpia con las cookies necesarias y pasa a través de la IP de la región deseada.

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])

Algunos puntos importantes en este código:

Se utiliza requests.Session(), y no una única requests.get(), para que el servidor pueda establecer cookies adicionales si es necesario, y estas se conserven entre solicitudes de una misma sesión de scraping.
Los valores de las cookies region y currency son condicionales, sus nombres y valores reales deben ser verificados en DevTools del navegador (pestaña Application → Cookies) en el sitio objetivo con la ubicación deseada.
El proxy debe estar realmente en el país deseado — de lo contrario, incluso los encabezados y cookies correctos pueden ser sobrescritos por el servidor al volver a determinar la geolocalización.

Sitios JS: Playwright y gestión de encabezados/cookies

Si el sitio renderiza contenido a través de JavaScript (los precios se cargan en una solicitud separada después de cargar la página), una simple solicitud de requests no es suficiente — se necesita un navegador sin cabeza. En Playwright, la localización, el idioma y el proxy se establecen a nivel de contexto del 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 atención al parámetro timezone_id — muchos sitios también verifican la zona horaria del navegador con la esperada para la región, y una discrepancia (por ejemplo, IP de Rusia, pero la zona horaria del navegador es estadounidense) puede ser una señal para el sistema anti-bots de que la solicitud es sospechosa, incluso si el idioma y la moneda son formalmente correctos.

Errores comunes y lista de verificación antes de ejecutar

Antes de ejecutar el parser en producción, pase por una breve lista de verificación — esto ahorra horas de depuración:

✅ El encabezado Accept-Language está establecido y corresponde a la región esperada.
✅ La sesión está limpia — las cookies no se han heredado de una solicitud fallida anterior.
✅ La IP del proxy se encuentra físicamente en el país deseado (verifique con cualquier verificador geo-IP antes del scraping).
✅ El User-Agent corresponde a un navegador real y no contiene signos de modo sin cabeza.
✅ La zona horaria y la localización del navegador (para Playwright/Selenium) coinciden con el país de la IP.
✅ Si el sitio utiliza selección manual de región en un banner — las cookies de esta selección se envían manualmente.

Es importante mencionar la rotación de proxies: si cambia la IP en cada solicitud, pero las cookies de la sesión permanecen iguales, el sitio puede ver la discrepancia "cookie de región A, pero IP de región B" y restablecer la sesión. Para tareas de monitoreo de precios, es mejor fijar una IP para toda la sesión de scraping de una región específica, en lugar de rotarla en medio de la recolección de datos.

Qué tipo de proxy elegir para la tarea

La elección del tipo de proxy afecta directamente a cuán precisamente el sitio determinará su región y no sospechará de la automatización. Aquí hay una comparación para tareas típicas de scraping de versiones regionales de sitios:

Tipo de proxy	Precisión de geolocalización	Cuándo usar
Proxies de centros de datos	Promedio, país correcto, pero la IP puede ser marcada como "no residencial"	Scraping de sitios sin estricta protección contra bots, alta velocidad y volumen de solicitudes
Proxies residenciales	Alta, hasta el nivel de la ciudad	Monitoreo de precios en marketplaces, contenido regional, eludir verificaciones GeoIP
Proxies móviles	Alta, más la etiqueta del operador móvil	Sitios y aplicaciones que funcionan de manera diferente con el tráfico móvil de un país específico

Si la tarea es precisamente el monitoreo del catálogo y precios en marketplaces desde diferentes ciudades, los proxies residenciales suelen ofrecer el resultado más predecible: las bases de datos GeoIP ven una dirección residencial real, y no un rango de centro de datos, que algunos sitios procesan con lógica separada.

Conclusión

El problema de "el parser ve la versión incorrecta de la página" casi siempre se compone de tres factores: el encabezado Accept-Language, que determina el idioma preferido de la respuesta; las cookies, que recuerdan la región y moneda seleccionadas anteriormente; y la geolocalización de la dirección IP, que el servidor utiliza para determinar el país de la solicitud en la primera visita. Para obtener exactamente la versión del sitio que ve un usuario real, es necesario sincronizar los tres parámetros simultáneamente, y no arreglarlos por separado.

Si regularmente scrapea versiones regionales de sitios, monitorea los precios de los competidores en marketplaces o recopila datos de diferentes países, es recomendable comenzar precisamente con la elección de la IP adecuada — las demás configuraciones (encabezados, cookies, zona horaria) se construyen alrededor de ella. Para un ajuste preciso en la región deseada, recomendamos probar proxies residenciales, que ofrecen una geolocalización predecible y minimizan el riesgo de obtener la versión internacional por defecto del sitio en lugar de la local.