Accept-Language, mata uang, dan geo-cookie: memperbaiki parser

Parser dijalankan, kode tidak gagal, data datang — tetapi harga dalam dolar alih-alih rubel, teks dalam bahasa Inggris, dan produk berbeda dari yang dilihat pengguna nyata di Rusia. Ini adalah salah satu masalah paling umum dan menyebalkan dalam parsing: secara teknis semuanya berfungsi, tetapi kontennya "tidak sesuai". Mari kita bahas mengapa ini terjadi dan bagaimana mengumpulkan permintaan yang mendapatkan versi halaman yang tepat yang Anda butuhkan.

Gejala: bagaimana memahami bahwa parser melihat versi yang salah

Sebelum memperbaiki masalah, penting untuk mendiagnosisnya dengan benar. Ada tiga skenario tipikal yang menyebabkan parser mendapatkan data yang berbeda dari yang dilihat pengguna biasa di browser:

Bahasa konten tidak cocok — Anda mengharapkan teks dalam bahasa Rusia, tetapi yang datang adalah versi dalam bahasa Inggris atau Ukraina.
Mata uang dan harga berbeda — situs menunjukkan harga dalam USD atau EUR, sementara di browser dari Rusia Anda melihat rubel, atau angkanya hanya berbeda (penetapan harga regional).
Katalog produk/konten berbeda — ketersediaan produk, promosi, etalase secara keseluruhan tergantung pada wilayah yang "dilihat" situs dari Anda.

Penyebabnya hampir selalu salah satu dari tiga (atau kombinasi mereka): header Accept-Language, cookie yang hilang atau salah, atau geolokasi alamat IP dari mana permintaan dilakukan. Mari kita bahas satu per satu.

Accept-Language: bagaimana server memilih bahasa respons

Browser mengirimkan header Accept-Language pada setiap permintaan, yang mencantumkan bahasa yang disukai pengguna dengan bobot (nilai q). Contoh dari apa yang sebenarnya dikirim oleh Chrome dengan lokal Rusia:

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

Perpustakaan untuk parsing (requests, httpx, scrapy) secara default tidak mengirimkan header ini sama sekali, atau mengirimkan sesuatu seperti */*. Dalam hal ini, server akan memberikan bahasa default (seringkali bahasa Inggris), atau menentukan bahasa berdasarkan IP — dan di sinilah bagian geo mulai berperan, yang akan dibahas di bawah.

Nuansa penting: banyak situs menggunakan kombinasi "Accept-Language + geolokasi IP", bukan hanya salah satu. Jadi bahkan jika Anda mengirimkan header bahasa yang benar, tetapi permintaan berasal dari IP negara lain, situs dapat tetap mengalihkan Anda ke versi bahasa Inggris atau lokal untuk wilayah dari mana permintaan sebenarnya datang.

Mata uang dan lokal: dari mana situs mendapatkan harga

Mata uang hampir tidak pernah ditentukan oleh header Accept-Language secara langsung. Lebih sering digunakan salah satu dari tiga mekanisme (atau kombinasi mereka):

Basis GeoIP — server melihat dari negara mana IP berasal, dan secara otomatis mengatur mata uang dan lokal yang sesuai pada kunjungan pertama.
Cookie dengan wilayah yang dipilih sebelumnya — jika pengguna pernah memilih negara dan mata uang secara manual, situs menyimpan ini dalam cookie dan tidak lagi memeriksa IP.
Parameter dalam URL atau subdomain — beberapa platform menggunakan penanda eksplisit seperti ?country=ru atau ru.example.com.

Dalam praktiknya, jika Anda melakukan parsing toko online dan melihat harga dalam dolar alih-alih rubel, dalam 80% kasus masalahnya bukan pada header, tetapi pada alamat IP permintaan. Situs hanya "melihat" bukan IP Rusia dan menampilkan etalase internasional default.

Setelah situs menentukan wilayah Anda sekali (melalui IP atau pemilihan manual di banner "Pilih kota Anda"), ia menyimpan keputusan ini dalam cookie — biasanya dengan nama seperti region, geo_city, currency atau locale. Selanjutnya, semua permintaan dengan cookie ini diproses berdasarkan wilayah yang disimpan — bahkan jika IP tiba-tiba berubah.

Ini menciptakan jebakan bagi parser: jika Anda sekali mendapatkan versi "salah" dan menyimpan cookie sesi, semua permintaan berikutnya akan menghasilkan kesalahan yang sama, bahkan jika Anda memperbaiki header atau proxy. Oleh karena itu, saat mendiagnosis, selalu periksa parsing dengan sesi bersih — tanpa cookie yang disimpan dari peluncuran sebelumnya.

Sisi lain dari mekanisme yang sama bermanfaat: jika Anda mengetahui nama cookie yang dibutuhkan dan nilai yang benar untuk wilayah target (misalnya, Anda melihatnya di DevTools browser di lokasi yang tepat), Anda dapat memaksa menetapkan nilai ini dalam permintaan, tanpa mengubah IP. Ini berfungsi untuk situs di mana wilayah ditentukan hanya melalui cookie flag, tetapi tidak berfungsi jika server memeriksa IP dengan basis GeoIP pada setiap permintaan.

Peran alamat IP dan proxy dalam menentukan wilayah

Penentuan GeoIP adalah cara paling andal bagi situs untuk memahami dari mana permintaan sebenarnya berasal, karena header dan cookie dapat dipalsukan, tetapi alamat IP tidak dapat dipalsukan (hanya dapat diganti dengan yang lain yang nyata). Itulah sebabnya untuk mendapatkan "versi" regional halaman yang "benar", tidak cukup hanya dengan header HTTP — Anda memerlukan IP yang benar-benar berasal dari negara yang diinginkan.

Di sini ada perbedaan signifikan antara jenis alamat IP:

IP pusat data — Basis GeoIP sering menentukan mereka dengan benar berdasarkan negara, tetapi banyak situs besar (terutama marketplace dan layanan dengan perlindungan terhadap bot) menandai rentang pusat data sebagai mencurigakan dan dapat menunjukkan versi konten yang dipotong atau default terlepas dari geolokasi.
IP residensial — dimiliki oleh penyedia nyata dan alamat fisik, sehingga GeoIP menentukan wilayah dengan lebih akurat, dan situs mempersepsikan permintaan sebagai pengguna biasa dari negara/kota tersebut.
IP seluler — terikat pada operator seluler dari negara tertentu, yang sangat penting untuk situs dan aplikasi yang beroperasi secara berbeda dengan lalu lintas seluler dan desktop.

Untuk tugas seperti memantau harga di Wildberries, Ozon atau Avito dari kota tertentu, yang paling cocok adalah proxy residensial — mereka memberikan IP yang terikat pada wilayah nyata, dan basis GeoIP situs menentukan negara dan kota dengan benar, tanpa mengganti dengan etalase internasional default.

Praktik: mengumpulkan permintaan yang benar di Python

Mari kita kumpulkan permintaan yang sekaligus menyelesaikan ketiga masalah: mengirimkan Accept-Language yang benar, menggunakan sesi bersih dengan cookie yang diperlukan dan melalui IP wilayah yang diinginkan.

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

Beberapa poin penting dalam kode ini:

Digunakan requests.Session(), bukan hanya requests.get(), agar server dapat menetapkan cookie tambahan jika diperlukan, dan mereka disimpan antara permintaan dalam satu sesi parsing.
Nilai cookie region dan currency — bersifat kondisional, nama dan nilai aslinya harus dilihat di DevTools browser (tab Application → Cookies) di situs target dengan lokasi yang diinginkan.
Proxy harus benar-benar berada di negara yang diinginkan — jika tidak, bahkan header dan cookie yang benar dapat ditimpa oleh server saat menentukan geolokasi kembali.

Situs JS: Playwright dan pengelolaan header/cookie

Jika situs merender konten melalui JavaScript (harga dimuat melalui permintaan terpisah setelah halaman dimuat), permintaan sederhana tidak cukup — diperlukan browser headless. Di Playwright, lokal, bahasa, dan proxy ditentukan pada tingkat konteks 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()

Perhatikan parameter timezone_id — banyak situs juga memeriksa zona waktu browser dengan yang diharapkan untuk wilayah, dan perbedaan (misalnya, IP dari Rusia, tetapi zona waktu browser — Amerika) dapat menjadi sinyal bagi sistem anti-bot bahwa permintaan tersebut mencurigakan, bahkan jika bahasa dan mata uang secara formal benar.

Kesalahan umum dan daftar periksa sebelum memulai

Sebelum menjalankan parser di produksi, lakukan pemeriksaan daftar periksa singkat — ini menghemat jam debugging:

✅ Header Accept-Language ditetapkan dan sesuai dengan wilayah yang diharapkan.
✅ Sesi bersih — cookie tidak diwarisi dari permintaan yang tidak berhasil sebelumnya.
✅ IP proxy secara fisik berada di negara yang diinginkan (periksa melalui geo-IP checker sebelum parsing).
✅ User-Agent sesuai dengan browser nyata dan tidak mengandung tanda-tanda mode headless.
✅ Zona waktu dan lokal browser (untuk Playwright/Selenium) sesuai dengan negara IP.
✅ Jika situs menggunakan pemilihan wilayah manual di banner — cookie pemilihan ini dikirim secara manual.

Secara terpisah, perlu dibahas tentang rotasi proxy: jika Anda mengubah IP untuk setiap permintaan, tetapi cookie sesi tetap sama, situs dapat melihat ketidaksesuaian "cookie wilayah A, tetapi IP wilayah B" dan mereset sesi. Untuk tugas pemantauan harga, lebih baik menetapkan satu IP untuk seluruh sesi parsing dari wilayah tertentu, daripada merotasinya di tengah pengumpulan data.

Jenis proxy apa yang harus dipilih untuk tugas ini

Pemilihan jenis proxy secara langsung mempengaruhi seberapa akurat situs akan menentukan wilayah Anda dan tidak mencurigai otomatisasi. Berikut adalah perbandingan untuk tugas parsing versi regional situs yang tipikal:

Jenis proxy	Akurasi geolokasi	Kapan digunakan
Proxy pusat data	Rata-rata, negara benar, tetapi IP dapat ditandai sebagai "tidak dihuni"	Parsing situs tanpa perlindungan anti-bot yang ketat, kecepatan tinggi dan volume permintaan
Proxy residensial	Tinggi, hingga kota	Pemantauan harga di marketplace, konten regional, melewati pemeriksaan GeoIP
Proxy seluler	Tinggi, plus tanda operator seluler	Situs dan aplikasi yang beroperasi secara berbeda dengan lalu lintas seluler dari negara tertentu

Jika tugasnya adalah memantau katalog dan harga di marketplace dari berbagai kota, proxy residensial biasanya memberikan hasil yang paling dapat diprediksi: basis GeoIP melihat alamat tempat tinggal yang nyata, bukan rentang pusat data yang beberapa situs proses dengan logika terpisah.

Kesimpulan

Masalah "parser melihat versi halaman yang salah" hampir selalu terdiri dari tiga faktor: header Accept-Language, yang menentukan bahasa respons yang disukai; cookie, yang mengingat wilayah dan mata uang yang dipilih sebelumnya; dan geolokasi alamat IP, yang digunakan server untuk menentukan negara permintaan pada kunjungan pertama. Untuk mendapatkan versi situs yang sama dengan yang dilihat pengguna nyata, perlu untuk menyinkronkan ketiga parameter ini secara bersamaan, bukan memperbaikinya satu per satu.

Jika Anda secara teratur melakukan parsing versi regional situs, memantau harga pesaing di marketplace, atau mengumpulkan data dari berbagai negara, sebaiknya mulai dengan memilih IP yang sesuai — pengaturan lainnya (header, cookie, zona waktu) dibangun di sekitarnya. Untuk mencapai wilayah yang tepat, kami merekomendasikan untuk mencoba proxy residensial, yang memberikan geolokasi yang dapat diprediksi dan meminimalkan risiko mendapatkan versi internasional default situs alih-alih lokal.