SEO İçin Datacenter Proxy

Bir SEO ekibinin sıralama verisine ihtiyaç duymasının nedeni basittir: hangi anahtar kelimede hangi sayfanın, hangi pazarda, hangi konumda göründüğünü bilmeden içerik ve teknik iyileştirmelerin etkisini ölçemezsiniz. Sorun, bu bilginin bulunduğu yerden bağımsız olmamasıdır. Arama sonuç sayfası (SERP) sorgunun yapıldığı ülkeye, dile, cihaz türüne, kişiselleştirme sinyallerine ve zamana göre değişir. Ofisinizdeki bilgisayardan elle yapılan bir kontrol, yalnız o anki, o ağdaki, o tarayıcı geçmişiyle görülen sonucu gösterir.

Datacenter proxy bu tabloya üç şey ekler. Birincisi coğrafi bağlam: ölçümü ofisinizin bulunduğu ülkeden değil, raporladığınız pazardan yaparsınız. İkincisi tutarlılık: her gün aynı ülkeden, aynı istemci ayarlarıyla, isterseniz aynı çıkış IP’siyle ölçüm alırsınız; böylece iki gün arasındaki fark ölçüm düzeneğinden değil, gerçek sıralama hareketinden kaynaklanır. Üçüncüsü ölçek: yüzlerce ya da binlerce anahtar kelimeyi tek bir ağ bağlantısına yüklemek yerine iş yükünü planlı biçimde dağıtırsınız.

Proxy’nin çözmediği şeyleri baştan yazmak, beklentiyi doğru kurmak için önemlidir. Proxy bir sıralama faktörü değildir; sitenizi yukarı taşımaz, arama motoruna olumlu ya da olumsuz sinyal göndermez. Kötü kurgulanmış bir ölçüm hattını da düzeltmez: sorgu dili yanlışsa, cihaz türü karışıksa ya da sonuçlar yanlış ayrıştırılıyorsa, en temiz IP bile yanlış veri üretir. Son olarak proxy, hedefin kullanım koşullarını ortadan kaldırmaz. Otomatik sorgu gönderdiğiniz her kaynağın kurallarına uymak sizin sorumluluğunuzdadır; bu konuya aşağıda ayrı bir bölümde dönüyoruz.

Kendi siteniz için gösterim, tıklama ve ortalama konum verisini arama motorlarının resmi web yöneticisi araçlarından alırsınız. Proxy ile yapılan ölçüm bu veriyi tamamlar: rakip görünürlüğü, belirli bir pazardaki SERP düzeni ve günlük anlık görüntü gibi resmi araçların vermediği bağlamı ekler. İkisini birbirinin yerine koymayın.

Sıralama ölçümünü bir betik değil, bir hat olarak düşünmek hataların çoğunu önler. Pratikte dört katman vardır ve proxy bunlardan yalnız biridir. Katmanları ayrı tasarladığınızda, bir sorun çıktığında hangisinden kaynaklandığını hızla bulursunuz.

1. Planlayıcı: Hangi anahtar kelimenin, hangi pazarda, hangi cihaz profiliyle, günün hangi saatinde sorgulanacağını belirler. Sorgu hacmini güne yayar ve her hedef için hız sınırını uygular.
2. Erişim katmanı: HTTP istemcisi ve proxy. Çıkış ülkesi, IP türü (static ya da rotating), protokol (HTTP, HTTPS ya da SOCKS5), zaman aşımı ve yeniden deneme politikası burada tanımlanır.
3. Ayrıştırıcı: Gelen yanıttan organik sonuçları, konumları ve izlenen alan adının bulunduğu sırayı çıkarır. Yanıtın gerçekten bir sonuç sayfası olup olmadığını, yoksa bir doğrulama ya da hata sayfası mı olduğunu da bu katman ayırt eder.
4. Depolama ve raporlama: Her ölçümü zaman damgası, çıkış IP’si, HTTP kodu ve deneme sayısıyla birlikte saklar. Raporlar yalnız geçerli ölçümlerden üretilir.

Bu ayrımın pratik faydası şudur: hazır bir rank tracker kullanıyorsanız planlayıcı ve ayrıştırıcı aracın içindedir, siz yalnız erişim katmanını yapılandırırsınız. Kendi aracınızı yazıyorsanız dört katmanın hepsi sizdedir ve proxy seçimi, planlayıcının üreteceği sorgu hacmine göre yapılır. Her iki durumda da proxy kararı, sorgu hacmi ve ölçüm sıklığı bilinmeden verilmemelidir.

Datacenter proxy’nin bu mimarideki yeri, hız ve maliyet tarafındadır. Datacenter çıkışları veri merkezlerinde barındırılır; bağlantı kurulumu ve yanıt süresi genellikle öngörülebilirdir ve trafik maliyeti, ev kullanıcısı bağlantılarına dayanan ürün ailelerine göre çoğu senaryoda daha düşüktür. Karşılığında bazı hedefler datacenter ağlarından gelen otomatik trafiğe daha temkinli davranabilir. Bu nedenle datacenter proxy, hız sınırına uyan, sorgu hacmini yayan ve doğrulama sayfası gördüğünde duran disiplinli bir planlayıcıyla birlikte en iyi sonucu verir.

DatacenterProxy kataloğunda dört datacenter ürün ailesi vardır ve her biri farklı bir faturalama modeline sahiptir. Static IPv4 IP adedine göre 30 günlük dönemlerle, rotating IPv4 tek seferlik GB paketleriyle, rotating IPv6 port başına aylık, static IPv6 ise ülke bazlı IP adedine göre aylık faturalanır. Sıra takibinde doğru ürün, ölçümün karakterine göre seçilir. Aşağıdaki tablo tipik SEO iş yüklerini katalogdaki ürünlerle eşleştirir.

Tabloda dikkat edilmesi gereken satır Türkiye satırıdır. Türk pazarında sıra takibi yapan ekiplerin ilk refleksi static IPv4 almaktır; ancak katalogdaki static IPv4 ülke seti Amerika Birleşik Devletleri, Birleşik Krallık, Hollanda, Almanya ve Kanada’dan oluşur. Türkiye çıkışı gereken ölçümlerde rotating IPv4 ya da, hedef IPv6 üzerinden erişilebiliyorsa, static IPv6 değerlendirilmelidir. Static IPv6’da Türkiye, Almanya ve ABD için 100 IP’lik küçük paketler de bulunur; bu, deneme ölçümü için düşük bir giriş maliyeti demektir.

Lokasyon seçiminin genel ilkeleri ayrı bir konu; burada yalnız sıra takibini doğrudan etkileyen datacenter tarafına değiniyoruz. İlk kural değişmez: ölçümü raporladığınız pazarın ülkesinden yapın. Almanya pazarının sonuçlarını Hollanda çıkışıyla ölçmek, yakın ülke olsa bile farklı bir sonuç sayfası üretebilir. Katalogda bulunmayan bir ülkeyi “yakın olan” ile ikame etmek, raporun güvenilirliğini sessizce bozar.

İkinci konu gecikmedir. Datacenter çıkışında toplam yanıt süresi üç parçadan oluşur: sizin sunucunuzdan proxy çıkışına giden yol, proxy çıkışından hedefe giden yol ve hedefin yanıt üretme süresi. Ölçüm sunucunuz İstanbul’daysa ve çıkış ABD’deyse, ilk parça her istekte okyanus aşırı bir gidiş dönüş ekler. Bu tek bir sorguda önemsiz görünür; binlerce sorguda zaman aşımı eşiğini, paralel bağlantı sayısını ve toplam iş süresini belirler. Pratik çözüm, ölçüm işini çalıştıran sunucuyu mümkünse ölçülen pazara yakın bir bölgede konumlandırmak ya da en azından zaman aşımını çıkış ülkesine göre ayrı tanımlamaktır.

Üçüncü konu tutarlılıktır. Aynı pazar için ölçümü bir gün Almanya çıkışından, ertesi gün Hollanda çıkışından yaparsanız, gördüğünüz sıralama değişiminin bir kısmı lokasyon değişiminden gelir. Her anahtar kelime grubunu bir ülkeye kilitleyin ve bu eşleştirmeyi yapılandırma dosyasında tutun. Şehir düzeyinde yerel sonuç ölçümü ayrı bir ihtiyaçtır ve bu sitedeki datacenter ürünlerinde katalogda şehir hedefleme yer almadığı için ülke düzeyinde planlama yapılmalıdır.

Sıralama verisinin değeri, iki ölçümün karşılaştırılabilir olmasından gelir. Bir anahtar kelimede dünkü 7. sıranın bugün 9. sıra olması, ancak iki ölçüm aynı koşullarda alındıysa anlamlıdır. Tekrarlanabilir ölçüm, değişkenleri bilinçli biçimde sabitlemek ve sabitleyemediklerinizi kaydetmek demektir.

Aşağıdaki adımlar, hazır bir araca proxy bağlayan ekip için de kendi betiğini yazan ekip için de geçerlidir. Sıra önemlidir: proxy satın almayı dördüncü adıma koymamızın nedeni, sorgu hacmi ve ülke listesi netleşmeden doğru paketin seçilememesidir.

1. Anahtar kelime envanterini çıkarın: Her kelime için pazar (ülke), dil, cihaz profili ve katman (A, B, C) sütunlarını içeren tek bir tablo oluşturun.
2. Sorgu hacmini hesaplayın: Katman başına kelime sayısını aylık ölçüm sayısıyla çarpın, toplamı pazar bazında yazın. Tekrar denemeler için yüzde 10–15 pay ekleyin.
3. Veri kaynağını ve kuralları belirleyin: Ölçümü hangi kaynaktan, hangi koşullar altında yapacağınızı netleştirin; kullanım koşullarını, robots.txt dosyasını ve varsa resmi erişim yöntemlerini inceleyin.
4. Ürünü seçin ve küçük başlayın: Tutarlılık gereken pazarlar için static IPv4’ün 100 IP’lik paketi, hacim için rotating IPv4’ün 10 GB paketi gibi küçük bir girişle pilot yapın.
5. İstemciyi yapılandırın: Proxy adresini KULLANICI, ŞİFRE, PROXY_HOST ve PORT bilgileriyle tanımlayın; protokolü (HTTP, HTTPS veya SOCKS5) istemcinizin desteğine göre seçin.
6. Çıkışı doğrulayın: Her IP için bir IP kontrol uç noktasına istek atıp çıkış adresini ve ülkesini kaydedin. Beklenen ülke ile gelen ülke eşleşmiyorsa ölçüme başlamayın.
7. Hız sınırını koyun: Hedef başına iki istek arasında en az bekleme süresini ve saatlik üst sınırı yapılandırma dosyasına yazın; sürelere rastgele küçük sapma ekleyin.
8. Geçerlilik kontrolünü ekleyin: Yanıtın gerçek bir sonuç sayfası olduğunu doğrulayan kuralları yazın. Doğrulama sayfası, boş sonuç ya da beklenmeyen dil görürseniz ölçümü geçersiz işaretleyin.
9. Kayıt formatını sabitleyin: Her satırda tarih, anahtar kelime, pazar, cihaz, çıkış IP’si, HTTP kodu, bulunan sıra, süre ve deneme sayısı olsun.
10. Bir hafta pilot çalıştırın: Kontrol sorgularının istikrarını, geçersiz ölçüm oranını ve gerçek GB tüketimini izleyin.
11. Ölçekleyin: Pilotta ölçtüğünüz istek başına ortalama veri miktarıyla aylık ihtiyacı yeniden hesaplayın ve paketi buna göre büyütün.

Onuncu adımdaki pilot, varsayımlarla yapılan bütçe hesabını gerçek veriye bağladığı için kritiktir. Sonuç sayfasının boyutu, kullandığınız istemciye (tam tarayıcı mı, yalın HTTP istemcisi mi), sıkıştırmaya ve sayfa düzenine göre büyük ölçüde değişir. Bir hafta boyunca istek başına aktarılan veri miktarını kaydederseniz, GB paketi seçimini tahmin yerine ölçüme dayandırırsınız.

Aşağıdaki iskelet, bir anahtar kelime listesini planlı ve hız sınırlı biçimde işler, her ölçümün sonucunu CSV dosyasına yazar. Hedef adresi kasıtlı olarak HEDEF_URL yer tutucusuyla bırakılmıştır: kullanım koşullarının izin verdiği bir ölçüm kaynağını, kendi test ortamınızı ya da lisanslı bir veri sağlayıcısının uç noktasını buraya koyarsınız. Sıra bulma fonksiyonu da bilinçli olarak boş bırakılmıştır; ayrıştırma kuralı kullandığınız kaynağa özeldir.

import csv
import random
import time
from datetime import datetime, timezone

import requests

PROXY = "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT"
PROXIES = {"http": PROXY, "https": PROXY}
HEDEF_URL = "HEDEF_URL"            # izinli ölçüm kaynağı (yer tutucu)
IP_KONTROL_URL = "IP_KONTROL_URL"  # çıkış IP'sini döndüren uç nokta (yer tutucu)
IZLENEN_ALAN = "example.com"

MIN_ARALIK = 10.0      # iki istek arası en az saniye (varsayım, kurala göre ayarlayın)
SAPMA = 4.0            # bekleme süresine eklenen rastgele sapma
SAATLIK_TAVAN = 200    # saatlik en fazla istek (varsayım)
ZAMAN_ASIMI = (5, 20)  # bağlantı / okuma zaman aşımı, saniye
MAKS_DENEME = 2


def cikis_ip():
    r = requests.get(IP_KONTROL_URL, proxies=PROXIES, timeout=ZAMAN_ASIMI)
    r.raise_for_status()
    return r.text.strip()


def gecerli_mi(html):
    # Doğrulama sayfası, boş yanıt veya beklenmeyen dil burada elenir.
    return bool(html) and "dogrulama-isareti" not in html


def sirayi_bul(html, alan):
    # Kaynağa özel ayrıştırma kuralınızı buraya yazın; bulunamazsa None.
    return None


def olc(kelime, pazar, oturum):
    for deneme in range(1, MAKS_DENEME + 1):
        bas = time.monotonic()
        try:
            r = oturum.get(HEDEF_URL, params={"q": kelime, "pazar": pazar},
                           proxies=PROXIES, timeout=ZAMAN_ASIMI)
        except requests.RequestException:
            time.sleep(MIN_ARALIK * deneme)
            continue
        sure_ms = int((time.monotonic() - bas) * 1000)
        if r.status_code == 429:
            bekle = int(r.headers.get("Retry-After", 60))
            time.sleep(bekle)
            continue
        if r.status_code != 200 or not gecerli_mi(r.text):
            return r.status_code, None, sure_ms, deneme, "gecersiz"
        return r.status_code, sirayi_bul(r.text, IZLENEN_ALAN), sure_ms, deneme, "ok"
    return 0, None, 0, MAKS_DENEME, "hata"


def calistir(kelimeler, pazar, dosya="siralama.csv"):
    ip = cikis_ip()
    oturum = requests.Session()
    oturum.headers["Accept-Language"] = "tr-TR,tr;q=0.9"
    saat_basi, sayac = time.monotonic(), 0
    with open(dosya, "a", newline="", encoding="utf-8") as f:
        yazici = csv.writer(f)
        for kelime in kelimeler:
            if sayac >= SAATLIK_TAVAN:
                kalan = 3600 - (time.monotonic() - saat_basi)
                time.sleep(max(kalan, 0))
                saat_basi, sayac = time.monotonic(), 0
            kod, sira, sure_ms, deneme, durum = olc(kelime, pazar, oturum)
            yazici.writerow([datetime.now(timezone.utc).isoformat(), kelime,
                             pazar, ip, kod, sira, sure_ms, deneme, durum])
            f.flush()
            sayac += 1
            if durum == "gecersiz":
                break  # doğrulama sayfası: zorlamayın, turu durdurun
            time.sleep(MIN_ARALIK + random.uniform(0, SAPMA))

İskeletin üç tasarım kararı önemlidir. Birincisi, 429 yanıtında Retry-After başlığına uyulur ve beklenir; istek başka bir IP’den hemen tekrarlanmaz. İkincisi, geçersiz yanıt görüldüğünde tur durdurulur; doğrulama sayfasını atlatmaya çalışmak hem kurallara aykırıdır hem de ölçüm verisini kirletir. Üçüncüsü, çıkış IP’si her satıra yazılır; böylece raporda bir sapma gördüğünüzde hangi IP’den ölçüldüğünü geriye dönük bulabilirsiniz.

Toplam süreyi kısaltmak için ilk akla gelen, iş parçacığı sayısını artırmaktır. Sıra takibinde daha sağlıklı yol, aynı hız sınırını koruyarak işi günün daha geniş bir zaman aralığına yaymak ve pazarları ayrı süreçlerde çalıştırmaktır. Paralellik ancak her paralel kol kendi hız sınırını ayrı bir IP üzerinde koruyorsa anlamlıdır.

Bir e-ticaret markasının SEO ekibini düşünelim. Ekip Türkiye, Almanya ve Birleşik Krallık pazarlarında sıralama izliyor. Aşağıdaki hesapta fiyatlar DatacenterProxy kataloğundandır; anahtar kelime sayıları, ölçüm sıklıkları ve istek başına veri miktarı ise açıkça varsayımdır. Kendi pilot ölçümünüzle bu varsayımları değiştirmeniz gerekir.

• Varsayım 1: Katman A’da toplam 300 anahtar kelime vardır (Türkiye 150, Almanya 100, Birleşik Krallık 50) ve her gün ölçülür.
• Varsayım 2: Katman B ve C’de toplam 2.200 anahtar kelime vardır ve ortalama haftada bir ölçülür; ay dört hafta kabul edilir.
• Varsayım 3: Bir ölçüm isteği, sıkıştırılmış ve yalın HTTP istemcisiyle ortalama 250 KB veri aktarır. Tam tarayıcı kullanırsanız bu değer çok daha yüksek olabilir.
• Varsayım 4: Tekrar denemeler için yüzde 15 pay eklenir. Hesapta 1 GB = 1.000.000 KB alınmıştır.

Katman A’nın Almanya ve Birleşik Krallık kısmı static IPv4 ile ölçülür, çünkü bu iki pazar static IPv4 ülke setindedir. Katman A’nın Türkiye kısmı ve B ile C katmanlarının tamamı rotating IPv4 ile ölçülür. Rotating IPv4 trafiği şöyle hesaplanır: Türkiye katman A için 150 kelime × 30 gün = 4.500 istek; B ve C için 2.200 kelime × 4 = 8.800 istek. Toplam 13.300 istek, yüzde 15 payla yaklaşık 15.295 istek eder. 15.295 × 250 KB yaklaşık 3,8 GB’a karşılık gelir.

Birim fiyatlar katalogdan türetilmiştir. Rotating IPv4’te 10, 20, 50 ve 100 GB paketlerinin tamamı GB başına 0,60 USD’ye denk gelir (6/10, 12/20, 30/50, 60/100); 2 GB’lık 1 USD’lik hoş geldin paketi ise GB başına 0,50 USD’dir ve pilot için uygundur. Static IPv4’te IP başına 30 günlük maliyet paket büyüdükçe düşer: 100 IP’de 0,15 USD, 250 IP’de 0,10 USD, 500 IP’de 0,09 USD, 1.000 IP’de 0,08 USD.

Hesabın asıl öğrettiği şey, sıra takibinde maliyetin büyük kısmının trafikten değil, tutarlılık için ayrılan sabit IP’lerden gelebileceğidir. Senaryoda static IPv4 paketi 150 kelime için fazlasıyla IP sağlar; ama paket 100 IP’den küçük satılmadığı için bu bir tabandır. Aynı paketi rakip sayfa kontrolü ve elle görsel doğrulama gibi işlere de bölüştürerek verimini artırabilirsiniz. Türkiye ölçümünü IPv6 üzerinden yapabiliyorsanız, static IPv6’nın Türkiye için 100 IP’lik 2 USD’lik aylık paketi başka bir seçenek sunar; ancak bu, hedefin IPv6 üzerinden erişilebilir olmasına bağlıdır ve satın almadan önce sitedeki IPv6 Destek Kontrolü aracıyla doğrulanmalıdır.

Sıra takibindeki sorunların çoğu proxy’nin “çalışmaması” değil, ölçüm düzeneğinin bir parçasının sessizce değişmesidir. Aşağıdaki tablo belirtiden yola çıkarak teşhis yapmanıza yardım eder.

Datacenter IP’leri için ayrıca bilinmesi gereken bir nokta, bazı hedeflerin trafiği IP adresinin ait olduğu ağa, yani ASN’ye bakarak değerlendirebilmesidir. Bu durumda tek tek IP değiştirmek sorunu çözmez; çözüm, istek hacmini ve örüntüsünü hedefin kabul ettiği düzeye çekmek ya da ölçümü resmi ve izinli bir kaynağa taşımaktır.

Ölçüm hattı çalışmaya başladıktan sonra iş bitmez; asıl değer, ham satırları güvenilir bir rapora dönüştürmekte ortaya çıkar. Bu aşamada üç kural uygulanmalıdır.

• Geçersiz ölçümü sıfır kabul etmeyin: Sıranın bulunamaması ile ölçümün başarısız olması farklıdır. “İlk 100’de yok” ile “ölçülemedi” durumlarını ayrı kodlayın; aksi halde başarısız bir tur, raporda sert bir düşüş gibi görünür.
• Düzenek değişikliklerini not edin: Proxy ürününü, ülkeyi, ayrıştırıcı sürümünü ya da cihaz profilini değiştirdiğiniz tarihleri rapora işaretleyin. Grafikteki bir kırılmanın nedenini aylar sonra ararken bu notlar zaman kazandırır.
• Medyan ve aralık kullanın: Günlük tek değer yerine yedi günlük medyan ve en iyi ile en kötü konum aralığını gösterin. Yöneticiye giden raporda gürültü azalır, gerçek eğilim belirginleşir.

Raporlamada sık yapılan bir başka hata, farklı düzeneklerden gelen verileri tek ortalamada birleştirmektir. Static IPv4 ile her gün ölçülen katman A ile rotating IPv4 ile haftalık ölçülen katman C aynı görünürlük skoruna katılırsa, skor ölçüm sıklığındaki farkı yansıtır, sıralamadaki farkı değil. Her katman için ayrı skor hesaplayın ve toplam görünürlüğü yalnız aynı sıklıkta ölçülen kelimelerden üretin.

Son olarak, proxy tarafındaki sağlığı da raporun bir parçası yapın. Her tur için geçersiz ölçüm oranını, ortalama yanıt süresini ve tüketilen veri miktarını kaydedin. Bu üç gösterge, sıralama verisinin ne kadar güvenilir olduğunu gösteren bir kalite etiketidir. Geçersiz ölçüm oranı yükseldiğinde o günün sıralama değişimlerini yorumlamadan önce düzeneği kontrol edersiniz.

Sıra takibi meşru ve yaygın bir SEO faaliyetidir, ancak yöntemi önemlidir. Arama motorları ve web siteleri, otomatik sorgulara ilişkin koşullarını kullanım şartlarında ve robots.txt dosyalarında belirtir. Bu koşullar kaynaktan kaynağa değişir ve zamanla güncellenir. Ölçüme başlamadan önce kullandığınız kaynağın koşullarını okumak, izin verilen bir erişim yöntemi sunuluyorsa onu tercih etmek ve hız sınırlarına uymak sizin sorumluluğunuzdadır. Proxy kullanmak bu sorumluluğu değiştirmez ya da azaltmaz.

Pratik bir yaklaşım, ölçüm kaynaklarını üç gruba ayırmaktır: kendi siteniz ve resmi web yöneticisi araçları, lisanslı veri sağlayıcıları ve doğrudan erişim. İlk iki grup kural belirsizliğini büyük ölçüde ortadan kaldırır. Doğrudan erişimde ise hız sınırı, kimlik doğrulama gerektiren alanlardan uzak durma ve doğrulama sayfası görüldüğünde durma ilkeleri vazgeçilmezdir.

Ekip içinde de basit bir kural belgesi işe yarar: hangi kaynakların hangi sıklıkla ölçülebileceği, hız sınırı değerleri, doğrulama sayfası görüldüğünde ne yapılacağı ve verinin ne kadar süre saklanacağı. Bu belge, yeni bir ekip üyesi betiğe dokunduğunda yanlışlıkla agresif bir yapılandırmanın canlıya çıkmasını önler.

Aşağıdaki liste, yeni bir takip projesini canlıya almadan önce gözden geçirmeniz gereken noktaları toplar. Her madde, yukarıdaki bölümlerden birinde anlatılan bir hatanın önlemidir.

• Her anahtar kelimenin pazarı, dili, cihaz profili ve katmanı tek bir tabloda tanımlı.
• Aylık sorgu hacmi pazar bazında hesaplandı; tekrar payı eklendi.
• Ölçüm kaynağının kullanım koşulları ve robots.txt dosyası incelendi; varsa resmi erişim yöntemi değerlendirildi.
• Ürün seçimi ülke kapsamına göre doğrulandı; Türkiye ölçümü için static IPv4 yerine rotating IPv4 veya static IPv6 planlandı.
• IPv6 ürünü seçildiyse hedefin IPv6 erişilebilirliği IPv6 Destek Kontrolü aracıyla test edildi.
• Her çıkış IP’sinin ülkesi ölçüm öncesi doğrulanıyor ve kayda geçiyor.
• Hedef başına en az bekleme süresi, rastgele sapma ve saatlik tavan yapılandırma dosyasında.
• 429 yanıtında Retry-After süresine uyuluyor; doğrulama sayfasında tur duruyor.
• “Bulunamadı” ile “ölçülemedi” ayrı kodlanıyor.
• Kontrol sorguları her turda ölçülüyor.
• İstek başına veri miktarı pilot haftasında ölçüldü; paket bu veriye göre seçildi.
• Ayrıştırıcı yalnız gerekli alanları kaydediyor; kişisel veri saklanmıyor.
• Düzenek değişiklikleri için tarihli bir değişiklik günlüğü tutuluyor.

Bu listenin tamamı işaretlendiğinde elinizde, sıralamadaki gerçek hareketi ölçüm gürültüsünden ayırabilen bir sistem olur. Datacenter proxy bu sistemin hızlı ve öngörülebilir maliyetli erişim katmanıdır; asıl değeri, çevresine kurduğunuz ölçüm disiplini belirler.