← Bloga geri dön
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Neden parser site için yanlış bölgeyi gösteriyor: Accept-Language, para birimi ve coğrafi çerezler

Neden bir parser, canlı bir kullanıcının gördüğü sayfanın yanlış versiyonunu indiriyor ve bunu başlıklar, çerezler ve doğru proxy seçimi ile nasıl düzeltebiliriz.

📅22 Ekim 2026

Parser başlatılıyor, kod çökmeden çalışıyor, veriler geliyor — ama fiyatlar ruble yerine dolar, metin İngilizce, ve ürünler, Rusya'daki canlı bir kullanıcının gördüğünden farklı. Bu, parsing'in en sık karşılaşılan ve can sıkıcı sorunlarından biridir: teknik olarak her şey çalışıyor, ama içerik "yanlış". Bunun neden olduğunu ve tam olarak hangi sayfa versiyonunu almanız gerektiğini belirlemek için nasıl bir istek oluşturacağınızı inceleyelim.

Belirtiler: parser'ın yanlış versiyonu gördüğünü nasıl anlayabilirsiniz

Sorunu düzeltmeden önce, onu doğru bir şekilde teşhis etmek önemlidir. Parser'ın, normal bir tarayıcı kullanıcısının gördüğünden farklı veriler aldığı üç tipik senaryo vardır:

  • İçerik dili uyuşmuyor — siz Rusça metin bekliyorsunuz, ancak İngilizce veya Ukraynaca sayfa geliyor.
  • Para birimi ve fiyatlar farklı — site USD veya EUR cinsinden fiyat gösteriyor, oysa Rusya'daki tarayıcıda ruble görüyorsunuz, ya da rakamlar tamamen farklı (bölgesel fiyatlandırma).
  • Ürünler/İçerik Kataloğu farklı — ürünlerin mevcudiyeti, kampanyalar, vitrin tamamen sizin için "görülen" bölgeye bağlıdır.

Neden genellikle üç şeyden biri (veya bunların kombinasyonu) olur: Accept-Language başlığı, eksik veya yanlış çerezler ya da istek yapılan IP adresinin coğrafi konumu. Her birini sırayla inceleyelim.

Accept-Language: sunucu yanıt dilini nasıl seçer

Tarayıcı her istekte Accept-Language başlığını gönderir, burada kullanıcının tercih ettiği diller ve ağırlıkları (q-değerleri) listelenir. Gerçekten Rusça yerel ayar ile Chrome'un gönderdiği bir örnek: 

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

Parsing kütüphaneleri (requests, httpx, scrapy) varsayılan olarak ya bu başlığı hiç göndermez, ya da */* gibi bir şey gönderir. Bu durumda sunucu ya varsayılan dili (genellikle İngilizce) verir ya da IP'ye göre dili belirler — ve burada coğrafi kısım devreye girer, aşağıda bahsedeceğiz.

Önemli bir nokta: birçok site, "Accept-Language + IP coğrafi konumu" kombinasyonunu kullanır, tek bir şey değil. Yani, eğer doğru dil başlığını gönderirseniz ama istek başka bir ülkeden gelen bir IP ile geliyorsa, site yine de sizi İngilizce veya o bölgeye ait yerel versiyona yönlendirebilir.

Para birimi ve yerel ayar: site fiyatları nereden alır

Para birimi neredeyse hiç doğrudan Accept-Language başlığı ile belirlenmez. Genellikle üç mekanizmadan biri (veya bunların kombinasyonu) kullanılır:

  1. GeoIP veritabanı — sunucu, IP'nin hangi ülkeden geldiğine bakar ve ilk ziyarette otomatik olarak uygun para birimini ve yerel ayarı yerleştirir.
  2. Daha önce seçilen bölge ile çerez — eğer kullanıcı bir zamanlar manuel olarak ülke ve para birimini seçtiyse, site bunu çerezde saklar ve IP'yi daha fazla kontrol etmez.
  3. URL'deki parametre veya alt alan adı — bazı platformlar ?country=ru veya ru.example.com gibi belirgin işaretler kullanır.

Pratikte, eğer bir e-ticaret sitesini parse ediyorsanız ve ruble yerine dolar fiyatları görüyorsanız, %80 durumunda sorun başlıklarda değil, isteğin IP adresindedir. Site, sadece "Rus" olmayan bir IP'yi "görmüş" ve varsayılan uluslararası vitrine geçmiştir.

Site bir kez bölgenizi belirledikten sonra (IP veya "Şehrinizi Seçin" bannerındaki manuel seçimle), bu kararı çerezde saklar — genellikle region, geo_city, currency veya locale gibi isimlerle. Sonraki tüm istekler bu çerez ile saklanan bölgeye göre işlenir — IP birden değişse bile.

Bu, parser için bir tuzak oluşturur: eğer bir kez "yanlış" versiyonu aldıysanız ve oturum çerezini sakladıysanız, tüm sonraki istekler aynı hatayı tekrar edecektir, başlıkları veya proxy'yi düzeltmiş olsanız bile. Bu nedenle, teşhis sırasında her zaman temiz bir oturumla parsing yapmayı kontrol edin — önceki çalışmalardan kalan çerezler olmadan.

Aynı mekanizmanın ters tarafı faydalıdır: eğer gerekli çerezin adını ve hedef bölge için doğru değerini biliyorsanız (örneğin, gerekli konumda tarayıcıda DevTools'ta gördüyseniz), bu değeri istekte zorla ayarlayabilirsiniz, IP'yi değiştirmeden. Bu, bölge yalnızca çerez bayrağı ile belirleniyorsa çalışır, ancak sunucu her istekte IP'yi GeoIP veritabanı ile yeniden kontrol ediyorsa çalışmaz.

IP adresinin ve proxy'nin bölge belirlemedeki rolü

GeoIP belirleme, sitenin isteğin gerçekten nereden geldiğini anlamanın en güvenilir yoludur, çünkü başlıklar ve çerezler sahte olabilir, ancak IP adresi sahte olamaz (sadece başka bir gerçek IP ile değiştirilebilir). Bu nedenle, "doğru" bölgesel sayfa versiyonunu istikrarlı bir şekilde almak için yalnızca HTTP başlıkları yeterli değildir — gerçekten gerekli ülkeye ait bir IP'ye ihtiyaç vardır.

Burada IP adresi türleri arasında önemli bir fark vardır:

  • Veri merkezi IP'leri — GeoIP veritabanları genellikle bunları ülkeye göre doğru belirler, ancak birçok büyük site (özellikle pazar yerleri ve bot koruma hizmetleri) veri merkezi aralıklarını şüpheli olarak işaretler ve coğrafi konuma bakılmaksızın kısıtlı veya varsayılan içerik versiyonunu gösterebilir.
  • İkamet IP'leri — gerçek sağlayıcılara ve fiziksel adreslere aittir, bu nedenle GeoIP bölgeyi daha doğru belirler ve site isteği bu ülke/şehirden normal bir kullanıcı olarak algılar.
  • Mobil IP'ler — belirli bir ülkenin mobil operatörlerine bağlıdır, bu da özellikle belirli bir ülkenin mobil ve masaüstü trafiği ile farklı şekilde çalışan siteler ve uygulamalar için önemlidir.

Wildberries, Ozon veya Avito gibi belirli şehirlerden fiyat izleme gibi görevler için en uygun ikamet proxy'leridir — bunlar gerçek bölgeye bağlı IP sağlar ve sitelerin GeoIP veritabanları ülkeyi ve şehri doğru bir şekilde belirler, varsayılan uluslararası vitrine geçmeden.

Uygulama: Python'da doğru isteği oluşturma

Hem doğru Accept-Language'ı gönderen, hem de gerekli çerezlerle temiz bir oturum kullanan ve gerekli bölgeden IP ile giden bir istek oluşturalım. 

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

Bu kodda birkaç önemli nokta:

  • requests.Session() kullanılıyor, tek bir requests.get() değil, böylece sunucu gerektiğinde ek çerezler ayarlayabilir ve bunlar bir parsing oturumu boyunca istekler arasında saklanır.
  • region ve currency çerez değerleri şartlıdır, gerçek isimleri ve değerlerini hedef sitedeki gerekli konumda DevTools'ta (Uygulama sekmesi → Çerezler) kontrol etmeniz gerekir.
  • Proxy gerçekten gerekli ülkede olmalıdır — aksi takdirde, doğru başlıklar ve çerezler bile sunucu tarafından coğrafi konum yeniden belirlendiğinde üzerine yazılabilir.

JS siteleri: Playwright ve başlıklar/çerezler yönetimi

Eğer site içeriği JavaScript ile render ediyorsa (fiyatlar sayfa yüklendikten sonra ayrı bir istekle yükleniyorsa), basit bir requests isteği yeterli değildir — headless bir tarayıcı gerekir. Playwright'ta yerel ayar, dil ve proxy tarayıcı bağlamı seviyesinde ayarlanır: 

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

timezone_id parametresine dikkat edin — birçok site, tarayıcının saat dilimini beklenen bölge ile karşılaştırır ve bir uyumsuzluk (örneğin, IP Rusya'dan, ancak tarayıcı saat dilimi — Amerikan) kendiliğinden bir sinyal olabilir anti-bot sistemine, isteğin şüpheli olduğunu gösterir, dil ve para birimi resmi olarak doğru olsa bile.

Tipik hatalar ve başlatmadan önce kontrol listesi

Parser'ı üretime almadan önce, kısa bir kontrol listesinden geçin — bu, hata ayıklama saatlerini tasarruf ettirir:

  • ✅ Accept-Language başlığı ayarlanmış ve beklenen bölgeye uygun.
  • ✅ Oturum temiz — çerezler önceki başarısız istekten miras alınmamış.
  • ✅ Proxy'nin IP'si fiziksel olarak gerekli ülkede (parsing öncesinde herhangi bir geo-IP kontrol aracı ile kontrol edin).
  • ✅ User-Agent gerçek bir tarayıcıya uygun ve headless mod belirtilerini içermiyor.
  • ✅ Tarayıcının saat dilimi ve yerel ayarı (Playwright/Selenium için) IP'nin ülkesine uyuyor.
  • ✅ Eğer site banner'da bölgeyi manuel olarak seçiyorsa — bu seçimin çerezleri manuel olarak iletiliyor.

Proxy döngüsü hakkında ayrıca bilgi vermek gerekir: eğer her istekte IP'yi değiştiriyorsanız, ancak oturum çerezleri aynı kalıyorsa, site "A bölgesi çerezi, ancak B bölgesi IP'si" tutarsızlığını görebilir ve oturumu sıfırlayabilir. Fiyat izleme gibi görevler için belirli bir bölgedeki tüm parsing oturumu için bir IP'yi sabit tutmak daha iyidir, verileri toplarken ortada değiştirmektense.

Görev için hangi tür proxy seçilmeli

Proxy türünün seçimi, sitenin bölgenizi ne kadar doğru belirleyeceğini ve otomasyonu şüphelenip şüphelenmeyeceğini doğrudan etkiler. İşte bölgesel versiyonların parsing'inde tipik görevler için bir karşılaştırma:

Proxy Türü Coğrafi Konum Doğruluğu Ne Zaman Kullanılmalı
Veri Merkezi Proxy'leri Ortalama, ülke doğru, ancak IP "yaşayan" olarak işaretlenebilir Sıkı anti-bot koruması olmayan sitelerin parsing'i, yüksek hız ve istek hacmi
İkamet Proxy'leri Yüksek, şehir düzeyine kadar Pazar yerlerinde fiyat izleme, bölgesel içerik, GeoIP kontrollerini aşma
Mobil Proxy'ler Yüksek, ayrıca mobil operatör etiketi Belirli bir ülkenin mobil trafiği ile farklı şekilde çalışan siteler ve uygulamalar

Eğer görev, farklı şehirlerden pazar yerlerinde katalog ve fiyat izleme ise, ikamet proxy'leri genellikle en öngörülebilir sonucu verir: GeoIP veritabanları gerçek ikamet adresini görür, veri merkezi aralığını değil, bazı sitelerin ayrı bir mantıkla işlediği.

Sonuç

"Parser yanlış sayfa versiyonunu görüyor" sorunu neredeyse her zaman üç faktörden oluşur: tercih edilen yanıt dilini belirleyen Accept-Language başlığı; daha önce seçilen bölge ve para birimini hatırlayan çerezler; ve sunucunun ilk ziyarette isteğin ülkesini belirlediği IP adresinin coğrafi konumu. Canlı bir kullanıcının gördüğü sayfa versiyonunu almak için, bu üç parametreyi aynı anda senkronize etmek gerekir, ayrı ayrı düzeltmek yeterli değildir.

Eğer düzenli olarak bölgesel versiyonları parse ediyorsanız, pazar yerlerinde rakip fiyatlarını izliyorsanız veya farklı ülkelerden veri topluyorsanız, uygun IP seçimi ile başlamanız önemlidir — diğer ayarlar (başlıklar, çerezler, saat dilimi) onun etrafında inşa edilir. Hedef bölgeye tam olarak ulaşmak için ikamet proxy'lerini denemenizi öneririz, bunlar öngörülebilir bir coğrafi konum sağlar ve yerel yerine varsayılan uluslararası site versiyonunu alma riskini minimize eder.

İlgili yazılar