Accept-Language, Währung und Geo-Cookie: Wir reparieren den Parser.

Der Parser wird gestartet, der Code stürzt nicht ab, die Daten kommen an – aber die Preise sind in Dollar statt in Rubel, der Text ist auf Englisch, und die Produkte unterscheiden sich von denen, die ein echter Benutzer aus Russland sieht. Dies ist eines der häufigsten und ärgerlichsten Probleme beim Parsen: technisch funktioniert alles, aber der Inhalt ist „nicht der richtige“. Wir analysieren, warum das passiert und wie man eine Anfrage zusammenstellt, die genau die Version der Seite erhält, die Sie benötigen.

Symptome: wie man erkennt, dass der Parser nicht die richtige Version sieht

Bevor Sie das Problem beheben, ist es wichtig, es richtig zu diagnostizieren. Es gibt drei typische Szenarien, in denen der Parser Daten erhält, die von dem abweichen, was ein normaler Benutzer im Browser sieht:

Die Sprache des Inhalts stimmt nicht überein – Sie erwarten russischen Text, aber es kommt die englische oder ukrainische Version der Seite.
Währung und Preise unterscheiden sich – die Website zeigt den Preis in USD oder EUR an, während Sie im Browser aus Russland Rubel sehen, oder die Zahlen sind einfach anders (regionale Preisgestaltung).
Katalog von Waren/Inhalten ist anders – die Verfügbarkeit von Waren, Aktionen, die gesamte Schaufenster hängen von der Region ab, die die Website „gesehen“ hat.

Der Grund ist fast immer einer von dreien (oder eine Kombination davon): der Header Accept-Language, fehlende oder falsche Cookies oder die Geolokalisierung der IP-Adresse, von der die Anfrage kommt. Lassen Sie uns jede einzeln durchgehen.

Accept-Language: wie der Server die Sprache der Antwort auswählt

Der Browser sendet bei jeder Anfrage den Header Accept-Language, in dem die bevorzugten Sprachen des Benutzers mit Gewichten (q-Werte) aufgelistet sind. Ein Beispiel dafür, was tatsächlich Chrome mit russischer Locale sendet:

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

Parsing-Bibliotheken (requests, httpx, scrapy) senden standardmäßig entweder gar keinen Header oder senden etwas wie */*. Der Server gibt in diesem Fall entweder die Standardsprache (häufig Englisch) zurück oder bestimmt die Sprache anhand der IP — und hier kommt der Geo-Teil ins Spiel, den wir weiter unten behandeln.

Ein wichtiger Punkt: Viele Websites verwenden genau die Kombination „Accept-Language + Geolokalisierung der IP“ und nicht nur eines davon. Das bedeutet, selbst wenn Sie den korrekten Sprachheader senden, aber die Anfrage von einer IP aus einem anderen Land kommt, kann die Website Sie trotzdem auf die englische oder lokale Version für die Region umschalten, aus der die Anfrage tatsächlich kam.

Währung und Locale: woher die Website die Preise bezieht

Die Währung wird fast nie direkt durch den Accept-Language-Header bestimmt. Häufig wird einer von drei Mechanismen (oder deren Kombination) verwendet:

GeoIP-Datenbank – der Server schaut, aus welchem Land die IP kommt, und setzt automatisch die entsprechende Währung und Locale beim ersten Besuch ein.
Cookie mit zuvor ausgewählter Region – wenn der Benutzer irgendwann manuell ein Land und eine Währung ausgewählt hat, speichert die Website dies in Cookies und überprüft die IP nicht mehr.
Parameter in der URL oder Subdomain – einige Plattformen verwenden explizite Marker wie ?country=ru oder ru.example.com.

In der Praxis, wenn Sie einen Online-Shop parsen und Preise in Dollar anstelle von Rubel sehen, liegt in 80% der Fälle das Problem nicht an den Headern, sondern an der IP-Adresse der Anfrage. Die Website hat einfach eine nicht-russische IP „gesehen“ und die standardmäßige internationale Schaufenster angezeigt.

Nachdem die Website einmal Ihren Standort bestimmt hat (entweder durch IP oder durch manuelle Auswahl im Banner „Wählen Sie Ihre Stadt“), speichert sie diese Entscheidung in einem Cookie – normalerweise mit Namen wie region, geo_city, currency oder locale. Alle weiteren Anfragen mit diesem Cookie werden dann nach der gespeicherten Region verarbeitet – selbst wenn sich die IP plötzlich ändert.

Dies schafft eine Falle für den Parser: Wenn Sie einmal die „falsche“ Version erhalten haben und das Sitzungscookie gespeichert haben, werden alle nachfolgenden Anfragen denselben Fehler reproduzieren, selbst wenn Sie die Header oder den Proxy korrigieren. Daher sollten Sie bei der Diagnose immer das Parsing mit einer sauberen Sitzung überprüfen – ohne gespeicherte Cookies von früheren Läufen.

Die Kehrseite derselben Mechanik ist nützlich: Wenn Sie den Namen des benötigten Cookies und dessen korrekten Wert für die Zielregion kennen (zum Beispiel, wenn Sie ihn in den DevTools des Browsers an der gewünschten Location gesehen haben), können Sie diesen Wert in der Anfrage erzwingen, ohne die IP zu ändern. Dies funktioniert für Websites, bei denen die Region nur über das Cookie-Flag bestimmt wird, funktioniert jedoch nicht, wenn der Server bei jeder Anfrage die IP erneut mit der GeoIP-Datenbank abgleicht.

Die Rolle der IP-Adresse und des Proxys bei der Bestimmung der Region

GeoIP-Bestimmung ist die zuverlässigste Methode für die Website, um zu verstehen, woher die Anfrage tatsächlich kam, denn Header und Cookies können gefälscht werden, während die IP-Adresse nicht gefälscht werden kann (man kann sie nur durch eine andere echte ersetzen). Aus diesem Grund ist es für eine stabile Erfassung der „richtigen“ regionalen Version der Seite nicht ausreichend, nur HTTP-Header zu verwenden – es wird eine IP benötigt, die tatsächlich dem gewünschten Land gehört.

Hier gibt es einen wesentlichen Unterschied zwischen den Typen von IP-Adressen:

IP von Rechenzentren – GeoIP-Datenbanken bestimmen sie oft korrekt nach Land, aber viele große Websites (insbesondere Marktplätze und Dienste mit Bot-Schutz) kennzeichnen IP-Bereiche von Rechenzentren als verdächtig und können unabhängig von der Geolokalisierung eine reduzierte oder standardmäßige Version des Inhalts anzeigen.
Residential IPs – gehören echten Anbietern und physischen Adressen, daher bestimmt GeoIP die Region genauer, und die Website betrachtet die Anfrage als von einem normalen Benutzer aus diesem Land/Stadt.
Mobile IPs – sind an Mobilfunkanbieter eines bestimmten Landes gebunden, was besonders wichtig ist für Websites und Anwendungen, die unterschiedlich mit mobilem und Desktop-Traffic umgehen.

Für Aufgaben wie die Preisüberwachung auf Wildberries, Ozon oder Avito aus bestimmten Städten sind residential Proxies am besten geeignet – sie bieten IPs mit Bezug zu einer realen Region, und die GeoIP-Datenbanken der Websites bestimmen das Land und die Stadt korrekt, ohne auf die standardmäßige internationale Schaufenster umzuschalten.

Praxis: wir erstellen die richtige Anfrage in Python

Lassen Sie uns eine Anfrage erstellen, die gleichzeitig alle drei Probleme löst: sie sendet den korrekten Accept-Language, verwendet eine saubere Sitzung mit den benötigten Cookies und geht über die IP der gewünschten Region.

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

Einige wichtige Punkte in diesem Code:

Es wird requests.Session() verwendet, anstelle von einem einzelnen requests.get(), damit der Server bei Bedarf zusätzliche Cookies setzen kann, die zwischen den Anfragen einer Parsing-Sitzung gespeichert werden.
Die Werte der Cookies region und currency sind Platzhalter, ihre tatsächlichen Namen und Werte sollten in den DevTools des Browsers (Registerkarte Anwendung → Cookies) auf der Zielwebsite mit der gewünschten Location überprüft werden.
Der Proxy muss sich tatsächlich im gewünschten Land befinden – andernfalls können selbst die richtigen Header und Cookies vom Server bei einer erneuten Geolokalisierung überschrieben werden.

JS-Websites: Playwright und das Management von Headern/Cookies

Wenn die Website Inhalte über JavaScript rendert (Preise werden nach dem Laden der Seite über eine separate Anfrage geladen), reicht eine einfache requests-Anfrage nicht aus – ein Headless-Browser ist erforderlich. In Playwright werden Locale, Sprache und Proxy auf der Ebene des Browserkontexts festgelegt:

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

Beachten Sie den Parameter timezone_id — viele Websites überprüfen zusätzlich die Zeitzone des Browsers mit der erwarteten für die Region, und eine Diskrepanz (zum Beispiel, IP aus Russland, aber die Zeitzone des Browsers ist amerikanisch) kann selbst ein Signal für das Anti-Bot-System sein, dass die Anfrage verdächtig ist, selbst wenn Sprache und Währung formal korrekt sind.

Typische Fehler und Checkliste vor dem Start

Bevor Sie den Parser in die Produktion starten, gehen Sie eine kurze Checkliste durch – das spart Stunden der Fehlersuche:

✅ Der Accept-Language-Header ist gesetzt und entspricht der erwarteten Region.
✅ Die Sitzung ist sauber – Cookies sind nicht von vorherigen fehlgeschlagenen Anfragen geerbt.
✅ Die IP des Proxys befindet sich physisch im gewünschten Land (überprüfen Sie dies vor dem Parsen mit einem beliebigen Geo-IP-Checker).
✅ Der User-Agent entspricht einem echten Browser und enthält keine Anzeichen des Headless-Modus.
✅ Die Zeitzone und Locale des Browsers (für Playwright/Selenium) stimmen mit dem Land der IP überein.
✅ Wenn die Website eine manuelle Auswahl der Region im Banner verwendet – werden die Cookies dieser Auswahl manuell übergeben.

Besonders erwähnenswert ist die Rotation der Proxys: Wenn Sie die IP bei jeder Anfrage ändern, die Sitzungscookies jedoch gleich bleiben, kann die Website eine Diskrepanz „Cookie Region A, aber IP Region B“ sehen und die Sitzung zurücksetzen. Für Aufgaben zur Preisüberwachung ist es besser, eine IP für die gesamte Parsing-Sitzung einer bestimmten Region zu verwenden, anstatt sie mitten im Datensammeln zu rotieren.

Welchen Proxy-Typ für die Aufgabe wählen

Die Wahl des Proxy-Typs beeinflusst direkt, wie genau die Website Ihre Region bestimmt und keine Automatisierung vermutet. Hier ist ein Vergleich für typische Parsing-Aufgaben regionaler Versionen von Websites:

Proxy-Typ	Genauigkeit der Geolokalisierung	Wann verwenden
Rechenzentrums-Proxys	Durchschnittlich, Land ist korrekt, aber IP kann als „nicht bewohnt“ markiert werden	Parsing von Websites ohne strengen Anti-Bot-Schutz, hohe Geschwindigkeit und Volumen von Anfragen
Residential Proxys	Hoch, bis hin zur Stadt	Preisüberwachung auf Marktplätzen, regionaler Inhalt, Umgehung von GeoIP-Überprüfungen
Mobile Proxys	Hoch, plus Markierung des Mobilfunkanbieters	Websites und Anwendungen, die unterschiedlich mit mobilem Traffic eines bestimmten Landes umgehen

Wenn die Aufgabe darin besteht, den Katalog und die Preise auf Marktplätzen aus verschiedenen Städten zu überwachen, bieten Residential Proxys normalerweise die vorhersehbarsten Ergebnisse: GeoIP-Datenbanken sehen die tatsächliche Wohnadresse und nicht den Bereich des Rechenzentrums, den einige Websites mit separater Logik verarbeiten.

Fazit

Das Problem „der Parser sieht nicht die richtige Version der Seite“ ergibt sich fast immer aus drei Faktoren: dem Header Accept-Language, der die bevorzugte Sprache der Antwort bestimmt; Cookies, die die zuvor ausgewählte Region und Währung speichern; und der Geolokalisierung der IP-Adresse, anhand der der Server das Land der Anfrage beim ersten Besuch bestimmt. Um genau die Version der Website zu erhalten, die ein echter Benutzer sieht, müssen alle drei Parameter gleichzeitig synchronisiert werden, anstatt sie einzeln zu reparieren.

Wenn Sie regelmäßig regionale Versionen von Websites parsen, die Preise von Wettbewerbern auf Marktplätzen überwachen oder Daten aus verschiedenen Ländern sammeln, sollten Sie mit der Auswahl der passenden IP beginnen – die anderen Einstellungen (Header, Cookies, Zeitzone) werden darum herum aufgebaut. Für eine genaue Erfassung der gewünschten Region empfehlen wir, Residential Proxys auszuprobieren, die eine vorhersehbare Geolokalisierung bieten und das Risiko minimieren, die standardmäßige internationale Version der Website anstelle der lokalen zu erhalten.