Accept-Language, valuta e geo-cookie: ripariamo il parser.

Il parser si avvia, il codice non fallisce, i dati arrivano — ma i prezzi sono in dollari invece che in rubli, il testo è in inglese, e i prodotti differiscono da quelli che vede un utente reale in Russia. Questo è uno dei problemi più comuni e frustranti del parsing: tecnicamente tutto funziona, ma il contenuto è "sbagliato". Analizziamo perché ciò accade e come costruire una richiesta che ottiene esattamente la versione della pagina di cui hai bisogno.

Sintomi: come capire che il parser vede una versione errata

Prima di risolvere il problema, è importante diagnosticarlo correttamente. Ci sono tre scenari tipici per cui il parser riceve dati diversi da quelli che vede un normale utente del browser:

La lingua del contenuto non corrisponde — ti aspetti un testo in russo, ma ricevi una versione in inglese o ucraino della pagina.
La valuta e i prezzi sono diversi — il sito mostra il prezzo in USD o EUR, mentre nel browser dalla Russia vedi rubli, oppure i numeri sono semplicemente diversi (prezzi regionali).
Il catalogo di prodotti/contenuti è diverso — la disponibilità dei prodotti, le promozioni, l'intero negozio dipendono dalla regione che il sito "ha visto" da te.

La causa è quasi sempre una delle tre (o una loro combinazione): l'intestazione Accept-Language, cookie mancanti o errati, oppure la geolocalizzazione dell'indirizzo IP da cui viene effettuata la richiesta. Analizziamo ciascuna nel dettaglio.

Accept-Language: come il server sceglie la lingua di risposta

Il browser invia ad ogni richiesta l'intestazione Accept-Language, in cui sono elencate le lingue preferite dall'utente con pesi (valori q). Un esempio di ciò che realmente invia Chrome con la locale russa:

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

Le librerie per il parsing (requests, httpx, scrapy) per impostazione predefinita non inviano affatto questa intestazione, oppure inviano qualcosa come */*. In questo caso, il server restituisce la lingua predefinita (spesso l'inglese), oppure determina la lingua in base all'IP — ed è qui che entra in gioco la parte geo, di cui parleremo più avanti.

Un punto importante: molti siti utilizzano proprio la combinazione "Accept-Language + geolocalizzazione IP", e non qualcosa di singolo. Quindi anche se invii l'intestazione della lingua corretta, ma la richiesta proviene da un IP di un altro paese, il sito può comunque reindirizzarti alla versione inglese o locale per la regione da cui è realmente arrivata la richiesta.

Valuta e locale: da dove il sito prende i prezzi

La valuta quasi mai è determinata direttamente dall'intestazione Accept-Language. Più spesso viene utilizzato uno dei tre meccanismi (o una loro combinazione):

GeoIP-database — il server guarda da quale paese proviene l'IP e inserisce automaticamente la valuta e la locale corrispondenti al primo accesso.
Cookie con la regione precedentemente selezionata — se l'utente ha mai scelto manualmente un paese e una valuta, il sito lo memorizza nei cookie e non controlla più l'IP.
Parametro nell'URL o sottodominio — alcuni siti utilizzano marcatori espliciti come ?country=ru o ru.example.com.

Nella pratica, se stai facendo parsing di un negozio online e vedi prezzi in dollari invece che in rubli, nell'80% dei casi non si tratta delle intestazioni, ma proprio dell'indirizzo IP della richiesta. Il sito ha semplicemente "visto" un IP non russo e ha inserito la vetrina internazionale predefinita.

Dopo che il sito ha determinato una volta la tua regione (tramite IP o selezione manuale sul banner "Seleziona la tua città"), memorizza questa decisione nei cookie — di solito con nomi come region, geo_city, currency o locale. Da quel momento in poi tutte le richieste con questo cookie vengono elaborate in base alla regione memorizzata — anche se l'IP cambia improvvisamente.

Questo crea una trappola per il parser: se hai ricevuto una volta la "versione errata" e hai salvato il cookie della sessione, tutte le richieste successive riprodurranno lo stesso errore, anche se correggi le intestazioni o il proxy. Pertanto, durante la diagnosi, controlla sempre il parsing con una sessione pulita — senza cookie salvati da esecuzioni precedenti.

Il rovescio della medaglia di questa meccanica è utile: se conosci il nome del cookie necessario e il suo valore corretto per la regione target (ad esempio, se lo hai visto in DevTools del browser nella posizione desiderata), puoi forzare questo valore nella richiesta, senza cambiare l'IP. Questo funziona per i siti in cui la regione è determinata solo tramite il flag del cookie, ma non funziona se il server verifica nuovamente l'IP con la GeoIP-database ad ogni richiesta.

Il ruolo dell'indirizzo IP e del proxy nella determinazione della regione

La determinazione GeoIP è il modo più affidabile per il sito di capire da dove è realmente arrivata la richiesta, perché le intestazioni e i cookie possono essere falsificati, mentre l'indirizzo IP non può essere falsificato (può solo essere sostituito con un altro reale). È proprio per questo che per ottenere stabilmente la "versione corretta" regionale della pagina non bastano le sole intestazioni HTTP — è necessario un IP che appartenga realmente al paese desiderato.

Qui c'è una differenza sostanziale tra i tipi di indirizzi IP:

IP dei data center — le GeoIP-database spesso li identificano correttamente per paese, ma molti grandi siti (soprattutto marketplace e servizi con protezione anti-bot) contrassegnano le gamme di data center come sospette e possono mostrare una versione ridotta o predefinita del contenuto indipendentemente dalla geolocalizzazione.
IP residenziali — appartengono a fornitori reali e indirizzi fisici, quindi GeoIP determina la regione con maggiore precisione, e il sito percepisce la richiesta come quella di un normale utente di quel paese/città.
IP mobili — sono legati agli operatori mobili di un paese specifico, il che è particolarmente importante per i siti e le applicazioni che trattano in modo diverso il traffico mobile e desktop.

Per compiti come il monitoraggio dei prezzi su Wildberries, Ozon o Avito da città specifiche, i proxy residenziali sono i più adatti — forniscono IP legati a una regione reale, e le GeoIP-database dei siti identificano correttamente il paese e la città, senza sostituire con la vetrina internazionale predefinita.

Pratica: costruiamo la richiesta corretta in Python

Costruiamo una richiesta che risolve contemporaneamente tutti e tre i problemi: invia un Accept-Language corretto, utilizza una sessione pulita con i cookie necessari e passa attraverso l'IP della regione desiderata.

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

Alcuni punti importanti in questo codice:

Si utilizza requests.Session(), e non una singola requests.get(), in modo che, se necessario, il server possa impostare cookie aggiuntivi, e questi vengano mantenuti tra le richieste di una stessa sessione di parsing.
I valori dei cookie region e currency — sono condizionali, i loro nomi e valori reali devono essere osservati in DevTools del browser (scheda Applicazione → Cookie) sul sito target con la posizione desiderata.
Il proxy deve trovarsi realmente nel paese desiderato — altrimenti anche le intestazioni e i cookie corretti possono essere sovrascritti dal server durante la nuova determinazione della geolocalizzazione.

Siti JS: Playwright e gestione delle intestazioni/cookie

Se il sito rende il contenuto tramite JavaScript (i prezzi vengono caricati con una richiesta separata dopo il caricamento della pagina), una semplice richiesta requests non è sufficiente — è necessario un browser headless. In Playwright, la locale, la lingua e il proxy vengono impostati a livello di contesto del browser:

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

Fai attenzione al parametro timezone_id — molti siti verificano anche il fuso orario del browser con quello atteso per la regione, e una discrepanza (ad esempio, IP dalla Russia, ma fuso orario del browser — americano) può di per sé essere un segnale per il sistema anti-bot che la richiesta è sospetta, anche se lingua e valuta sono formalmente corrette.

Errori comuni e checklist prima del lancio

Prima di lanciare il parser in produzione, segui una breve checklist — questo ti farà risparmiare ore di debug:

✅ L'intestazione Accept-Language è impostata e corrisponde alla regione attesa.
✅ La sessione è pulita — i cookie non sono ereditati da una precedente richiesta non riuscita.
✅ L'IP del proxy si trova fisicamente nel paese desiderato (controlla tramite qualsiasi geo-IP checker prima del parsing).
✅ L'User-Agent corrisponde a un browser reale e non contiene segni di modalità headless.
✅ Il fuso orario e la locale del browser (per Playwright/Selenium) corrispondono al paese dell'IP.
✅ Se il sito utilizza la selezione manuale della regione su un banner — i cookie di questa selezione vengono trasmessi manualmente.

Vale la pena menzionare la rotazione dei proxy: se cambi l'IP per ogni richiesta, ma i cookie della sessione rimangono gli stessi, il sito può vedere una discrepanza "cookie della regione A, ma IP della regione B" e resettare la sessione. Per compiti di monitoraggio dei prezzi è meglio mantenere un IP per tutta la sessione di parsing di una regione specifica, piuttosto che ruotarlo a metà raccolta dei dati.

Quale tipo di proxy scegliere per il compito

La scelta del tipo di proxy influisce direttamente su quanto accuratamente il sito determinerà la tua regione e non sospetterà l'automazione. Ecco un confronto per compiti tipici di parsing delle versioni regionali dei siti:

Tipo di proxy	Precisione della geolocalizzazione	Quando utilizzare
Proxy dei data center	Media, il paese è corretto, ma l'IP può essere contrassegnato come "non residenziale"	Parsing di siti senza protezione anti-bot rigorosa, alta velocità e volume di richieste
Proxy residenziali	Alta, fino alla città	Monitoraggio dei prezzi sui marketplace, contenuti regionali, bypass delle verifiche GeoIP
Proxy mobili	Alta, più il segnale dell'operatore mobile	Siti e applicazioni che trattano in modo diverso il traffico mobile di un paese specifico

Se il compito è precisamente il monitoraggio del catalogo e dei prezzi sui marketplace da diverse città, i proxy residenziali di solito forniscono il risultato più prevedibile: le GeoIP-database vedono un indirizzo residenziale reale, e non un intervallo di data center, che alcuni siti elaborano con una logica separata.

Conclusione

Il problema "il parser vede una versione errata della pagina" è quasi sempre composto da tre fattori: l'intestazione Accept-Language, che determina la lingua di risposta preferita; i cookie, che memorizzano la regione e la valuta precedentemente selezionate; e la geolocalizzazione dell'indirizzo IP, tramite la quale il server determina il paese della richiesta al primo accesso. Per ottenere esattamente la versione del sito che vede un utente reale, è necessario sincronizzare tutti e tre i parametri contemporaneamente, e non correggerli singolarmente.

Se fai regolarmente parsing delle versioni regionali dei siti, monitori i prezzi dei concorrenti sui marketplace o raccogli dati da diversi paesi, è consigliabile iniziare proprio dalla scelta di un IP adatto — le altre impostazioni (intestazioni, cookie, fuso orario) si costruiscono attorno ad esso. Per un preciso accesso alla regione desiderata ti consigliamo di provare i proxy residenziali, che forniscono una geolocalizzazione prevedibile e minimizzano il rischio di ottenere la versione internazionale predefinita del sito invece di quella locale.