Google, aynı sorgu için, kişiselleştirme devre dışı bırakıldığında bile, isteğin coğrafi kaynağına bağlı olarak farklı organik sonuçlar sunar. New York veri merkezi IP'sinden yapılan "en iyi kahve çekirdekleri" sorgusu, Berlin'deki bir konut IP'sinden yapılan aynı sorgudan farklı bir SERP döndürür. Fark yalnızca görsel değildir; Google'ın bölgesel sıralama algoritmaları, içerik yerelleştirmesi ve gl (ülke), hl (dil) ile cr (ülke kısıtlaması) parametrelerinin etkileşimi tarafından zorlanır. Bu mekanizmaları anlamadan yapılan coğrafi hedefli SEO izlemesi, yanıltıcı verileri garanti eder. Bu makale, SERP'lerin neden bölgelere göre farklılaştığını, proxy rotasyonunun tespiti nasıl azalttığını ve 30'dan fazla pazarda sıralama takibi için operasyonel iş akışını açıklamaktadır.
SERP Neden Bölgelere Göre Farklılık Gösterir? — ccTLD, gl, hl ve Kişiselleştirme
Google, "yerel" SERP'yi bir dizi sinyal aracılığıyla belirler. En basiti, arama alan adının TLD'sidir — google.de vs google.co.jp. Ancak yalnızca bir ccTLD kullanmak yetersizdir. Google ayrıca, varsayılan ülkeyi geçersiz kılmak için gl parametresini okur. Örneğin, google.com?gl=DE, küresel alan adında bile Almanca sonuçları zorlar. hl parametresi arayüz dilini ayarlar; bu, sonuç dilini etkiler ancak coğrafi ağırlıklandırmayı etkilemez. hl=en&gl=JP ile yapılan bir istek, Japonca sonuçları İngilizce olarak döndürür — bu yaygın bir kafa karışıklığı kaynağıdır.
Parametrelerin ötesinde, Google IP tabanlı coğrafi konumlandırma uygular. Bir ABD IP'sinden google.de adresine istek gönderirseniz, Google IP kaynağını tespit ettiği için yine de İngilizce ve Almanca sonuçların bir karışımını sunabilir. SEO izlemesi için temel sorun budur: IP adresi, kullanıcının konumunu sızdırır. pws=0 aracılığıyla kişiselleştirmeyi devre dışı bırakmak, kullanıcı geçmişini kaldırır ancak konum çıkarımını devre dışı bırakmaz. Yerel bir kullanıcıyı simüle etmenin tek güvenilir yolu, trafiği hedef pazara ait bir IP üzerinden yönlendirmektir — ideal olarak bir konut IP'si.
Konut ve Veri Merkezi IP'leri — Tespit ve Captcha Önleme
Google, IP aralıklarını aktif olarak sınıflandırır. Veri merkezi IP'leri — AWS, GCP, DigitalOcean — saniyeler içinde insan dışı olarak işaretlenir. Dahili testlerimiz, gl parametreleriyle Google'a sorgulama yaparken veri merkezi IP'leri için %60–80 başarısızlık oranı göstermektedir; birçok istek bir captcha veya sadeleştirilmiş bir SERP döndürür. Öte yandan konut IP'leri, normal trafiğe karışır. Ancak konut proxy havuzlarının kendi sorunları vardır: yüksek gecikme, sınırlı bant genişliği ve değişken coğrafi konum doğruluğu. Bir proxy sağlayıcısından alınan "konut" IP'si aslında Google'ın farklı bir bölgeye eşlediği bir mobil operatör NAT'ı olabilir.
Captcha önleme, "gizlenmekle" ilgili değildir — gerçek bir tarayıcıyı taklit etmekle ilgilidir. Doğru User-Agent, Accept-Language ile eşleşen hl ve her oturum için yeni bir Cookie kavanozu gönderin. Google'ın bot tespiti ayrıca istek zamanlamasına da bakar. Aynı IP'den 2 saniye içinde 100 sorguluk bir patlama, bir captcha tetikler. IP başına dakikada 1-2 isteğe kadar azaltın. Verimliliği korumak için pazar başına en az 50 IP'lik bir havuz kullanın. Ödünleşim: daha yüksek gecikme ve maliyet karşılığında daha düşük captcha oranı. %5-10 captcha oranını normal kabul ediyor ve farklı bir IP ile yeniden deniyoruz.
30'dan Fazla Ülkede Sıralama Takibi için İş Akışı
Operasyonel desen basittir: pazar başına bir IP, sorgu başına yeni bir oturum. Çerezleri pazarlar arasında yeniden kullanmayın. Aşağıdaki shell parçacığı, bir konut proxy'si kullanarak Almanca bir SERP için minimal bir curl tabanlı sondalamayı göstermektedir:
#!/bin/bash
# Query Google for "SEO tools" with German gl and English hl, via a residential proxy
PROXY="http://user:pass@residential-proxy-pool:8080"
curl -s --proxy "$PROXY" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept-Language: en-US,en;q=0.9,de;q=0.8" \
-H "Cookie: NID=...; CONSENT=..." \
"https://www.google.com/search?q=SEO+tools&gl=DE&hl=en&pws=0&num=10" \
| grep -oP '(?<=&url=)[^&]+' | head -10Bu, ilk 10 organik URL'yi getirir. Bir üretim sistemi için, statik proxy'yi istek başına yeni bir IP döndüren dönen bir uç nokta ile değiştirin. proxy-chain gibi araçlar veya IP başına bir oturum ile requests kullanan özel Python betikleri iyi çalışır. Her pazarın proxy listesini ayrı bir dosyada saklayın ve döngüsel olarak döndürün.
30'dan fazla ülke için 30'dan fazla proxy havuzuna ihtiyacınız vardır — her havuz, hız sınırlarını aşmamak için en az 20-50 IP içermelidir. Tek bir küresel IP havuzu yetersizdir çünkü Google'ın coğrafi konumlandırması yanlış yönlendirme yapacaktır. Ülke kodlarını proxy uç noktalarına eşleyen bir yapılandırma dosyası kullanıyoruz:
{
"DE": "http://user:pass@de-residential.zone:8080",
"JP": "http://user:pass@jp-residential.zone:8080",
"BR": "http://user:pass@br-residential.zone:8080"
}Her pazar sorgusu, her 10 istekten sonra IP başına 60 saniyelik bir bekleme süresi ile ayrı bir iş parçacığında veya async görevde çalışır. Bu tempo, çoğu pazarda captcha oranlarını %3'ün altında tutar. Zor kısım kod değil, doğrulanmış coğrafi konuma sahip güvenilir konut proxy'lerini temin etmektir. Birçok sağlayıcı "DE" iddiasında bulunur ancak Frankfurt veri merkezleri üzerinden yönlendirme yapar. IP'nin ASN'sini kontrol ederek ve Google'ın konum çıkarımıyla karşılaştırarak doğrulayın (örneğin, X-Robots-Tag başlığını veya bilinen bir yerel sonucu kullanarak).
Ödünleşim: Tazelik ve Maliyet
30 pazarı her saat konut proxy'leriyle çalıştırmak, sağlayıcıya ve veri hacmine bağlı olarak yalnızca proxy ücretlerinde ayda yaklaşık 200–500 dolara mal olur. Google'ın daha az agresif olduğu pazarlar için (genellikle daha küçük ülkeler) veri merkezi IP'leri kullanarak maliyeti düşürebilirsiniz. Ancak veriler daha gürültülü olacaktır. Alternatif, 24 saatlik bir yenileme döngüsünü kabul etmek ve captcha oranlarının düştüğü gece saatlerinde toplu sorgulamalar yapmaktır. Bedava öğle yemeği yoktur. 30 ülkede günlük sıralama takibine ihtiyacınız varsa, konut proxy'leri ve sağlam bir yeniden deneme mekanizması için bütçe ayırın. Daha azı, hassas görünen ancak temelde yanlış sonuçlar üretir — ve bu, hiç veri olmamasından daha kötüdür.