Yerel SERP takibi için residential proxy

Bir kullanıcı İzmir’de telefonundan “diş kliniği” yazdığında gördüğü sayfa ile Ankara’daki bir kullanıcının aynı dakikada gördüğü sayfa farklıdır ve ikisi de doğrudur. Arama motoru sorguyu yalnız kelimelerden değil, kimin, nereden, hangi dilde ve hangi cihazla sorduğundan da yorumlar. Yerel SERP takibi bu yorumun sonucunu sistemli biçimde kaydetmektir: belirli bir sorgu, belirli bir konum bağlamında, belirli bir anda hangi işletmeleri, hangi sayfaları ve hangi sonuç türlerini öne çıkarıyor?

Genel sıra takibinden farkı, konumun bir arka plan ayarı değil ölçülen değişkenin kendisi olmasıdır. Ülke çapında satış yapan bir e-ticaret sitesi için “Türkiye’de dördüncü sıradayız” cümlesi çoğu zaman yeterlidir. Şubeli bir işletme, bir klinik zinciri, bir çilingir ya da bir restoran için aynı cümle pek bir şey anlatmaz; çünkü müşteri bulunduğu şehirde, çoğu zaman da bulunduğu semtte arama yapar ve işletmenin görünürlüğü şehirden şehre değişir.

Sonucu etkileyen sinyalleri katman katman düşünmek, ölçümde hangisini sabitleyeceğinize karar vermeyi kolaylaştırır. Aşağıdaki tablo bu katmanları, her birinin nereden geldiğini ve ölçümde nasıl sabitlendiğini özetler.

Tablonun son satırı çoğu ekipte gözden kaçar. Bir işletmenin yerel paketteki görünümü sabah dokuzda ve gece yarısı aynı olmayabilir; çalışma saatleri, “şu an açık” gibi bilgiler ve gün içinde değişen arama niyeti sonucu etkileyebilir. Bu yüzden yerel ölçümde zaman, en az konum kadar dikkatle sabitlenmesi gereken bir değişkendir. Aynı sorguyu bir gün sabah, ertesi gün akşam ölçüp aradaki farkı sıralama hareketi diye raporlamak, yerel takipteki en yaygın yanılgılardan biridir.

Yerel niyet taşıyan bir sorguda sonuç sayfası tek bir sıralı liste değildir. Çoğu zaman üstte ya da organik sonuçların arasında, harita ile birlikte birkaç işletmeyi gösteren bir yerel paket yer alır; altında klasik organik sonuçlar, bazen de rehber siteleri, yorum platformları ve soru kutuları bulunur. Haritaya geçildiğinde ise sıralama, haritanın gösterdiği alana ve yakınlaştırma düzeyine göre yeniden kurulur.

Bu üç yüzey farklı mantıkla çalışır ve tek bir “sıra” sayısında birleştirilmemelidir. Google’ın yerel sıralamaya ilişkin yardım belgelerinde yerel sonuçlar için alaka, mesafe ve öne çıkma gibi etkenler sayılır. Mesafe, organik listede çoğu zaman ikincil kalırken yerel pakette belirleyici olabilir. Bir işletmenin organik listede üçüncü sırada, yerel pakette hiç yokken haritada sekizinci sırada görünmesi çelişki değildir; üç ayrı sorunun üç ayrı cevabıdır.

Ölçümün çıktığı IP adresi, arama motorunun gördüğü ilk konum sinyallerinden biridir. Ofis ağından, bir bulut sunucusundan ya da bir veri merkezinden gönderilen sorgu, raporladığınız pazardaki sıradan bir kullanıcının bağlantısına benzemez. Residential çıkış isteği gerçek ISP aboneliklerine ait bir adresten gönderir; böylece ülke sinyali, hedef pazardaki gerçek kullanıcı trafiğine yakın bir zeminde oluşur. Yurt dışındaki bir pazarı ölçüyorsanız bu fark daha da büyür: Türkiye’deki ofisten bir İngiltere aramasını taklit etmek, İngiltere’deki bir ev bağlantısından gelen sorguyla aynı şey değildir.

ResidentialProxy kataloğunda bu iş için iki IPv4 ailesi öne çıkar. Static IPv4 Residential; Türkiye, Amerika Birleşik Devletleri, Almanya, Birleşik Krallık, Hollanda, Fransa, Polonya, Avusturya, Portekiz, İspanya, Kanada ve Brezilya olmak üzere 12 ülkeyi listeler. Bu listede İspanya için şu an yayınlanmış bir paket görünmez; bu ülkeyi planlıyorsanız sipariş adımında durumu kontrol edin. Rotating IPv4 Residential ise bu 12 ülkeye Avustralya, Japonya ve Hindistan’ı ekleyerek 15 ülkeyi doğrulanmış lokasyon olarak listeler ve kapsam notunda 180+ lokasyon belirtir. Listede olmayan bir pazar için ölçüm planı kurmadan önce güncel kapsamı panelden ya da destekten doğrulayın.

Sınır da aynı netlikte yazılmalıdır: residential çıkışın taşıdığı konum sinyali ülke düzeyindedir. Katalogdaki ürünler şehir ya da semt hedefleme iddia etmez. Bir residential adresin hangi şehirde göründüğü, kullanılan IP konum veritabanına göre değişir; aynı adres bir veritabanında İstanbul, diğerinde Ankara, bir üçüncüsünde yalnız “Türkiye” olarak görünebilir. Konum veritabanları ülke düzeyinde genellikle tutarlıyken şehir düzeyinde daha sık ayrışır, çünkü bir ISP’nin adresleri abonenin oturduğu yere göre değil, sağlayıcının ağ yapısına göre kaydedilmiş olabilir.

Bu ayrımın pratik sonucu şudur: residential proxy yerel ölçümün ülke katmanını sağlamlaştırır, şehir katmanını ise ölçüm tasarımınıza bırakır. Bir sonraki bölüm, şehir katmanını meşru ve tekrarlanabilir biçimde nasıl ekleyebileceğinizi ele alıyor.

Şehir düzeyinde sonuç görmek için bir IP adresini belirli bir şehre bağlamaya uğraşmak hem güvenilmez hem de gereksizdir. Arama motorları ve SERP veri hizmetleri, konumu açıkça belirtmenin yollarını zaten sunar. Hangisini kullanacağınız ölçüm hacminize, bütçenize ve kaynağın kullanım koşullarına bağlıdır.

• —Arama arayüzünün konum ve bölge ayarları: Birçok arama arayüzü, sonuçların hangi bölgeye göre gösterileceğini seçmenize izin verir. Elle yapılan kontrollerde ve kanıt amaçlı ekran görüntülerinde en anlaşılır yöntemdir; seçtiğiniz konum kayda aynen yazılır.
• —Reklam önizleme ve tanılama araçları: Reklam platformlarının önizleme araçları, bir aramanın belirli bir konumda nasıl göründüğünü reklam gösterimi ya da tıklaması üretmeden görmek için tasarlanmıştır. Yerel sonuçlara genel bir bakış için de işe yarar; önizleme ile gerçek kullanıcı görünümü arasında fark olabileceğini not edin.
• —Lisanslı SERP veri hizmetleri: Konum parametresini resmi olarak kabul eden ücretli hizmetler, şehir ya da posta kodu düzeyinde sorgu yapmanın en temiz yoludur. Bu durumda erişim katmanı hizmetin kendi tarafında yönetilir; sizin residential çıkışınız elle doğrulama ve örneklem kontrolü için kalır.
• —Sahadan örnek: Şubelerdeki çalışanlardan, belirli günlerde kendi telefonlarından birkaç sorguyu oturum kapalı bir tarayıcıda arayıp ekran görüntüsü almalarını istemek, otomatik ölçümün gerçeğe ne kadar yakın olduğunu sınamanın en ucuz yoludur.
• —Kendi işletme profilinizin istatistikleri: İşletme profili panelleri, profilinizin hangi aramalarda ve ne sıklıkla gösterildiğine dair birinci elden veri sunar. Bu veri sıralama ölçümünün yerine geçmez, ama ölçümle çelişen bir tablo gördüğünüzde ilk bakılacak yerdir.

Bu yöntemlerin ortak noktası, şehir bilgisinin açık bir ayar olarak verilmesi ve kaydedilebilmesidir. Residential çıkış bu ayarla birlikte kullanıldığında iki sinyal üst üste biner: IP ülkeyi, konum ayarı şehri söyler. İkisi tutarlı olduğunda ölçüm, o şehirdeki bir kullanıcının görünümüne makul ölçüde yaklaşır.

Yerel ölçümde sık yapılan hatalardan biri, ayarları bir yapılandırma dosyasında tutup sonuçları ayrı bir tabloda saklamaktır. Ayarlar zamanla değişir: biri dil başlığını günceller, biri cihaz profilini değiştirir, konum ayarı bir kütüphane güncellemesiyle sessizce düşer. Altı ay sonra bir grafiğe baktığınızda eğrideki kırılmanın sıralama hareketinden mi yoksa ayar değişikliğinden mi geldiğini bilmenin tek yolu, her sonucun kendi ayarlarıyla birlikte saklanmış olmasıdır.

Bu yüzden her ölçümü bir “ölçüm kartı” olarak düşünün: sonucu ve sonucu üreten bütün bağlamı aynı kayıtta tutan küçük bir belge. Aşağıdaki örnek, İzmir bağlamıyla yapılmış tek bir mobil ölçümü gösterir. Alan adları örnektir; kendi şemanızda farklı adlar kullanabilirsiniz, önemli olan alanların eksiksiz olmasıdır.

{
  "olcum_id": "tr-izm-implant-mobil-0042",
  "zaman_utc": "2026-10-14T07:42:10Z",
  "yerel_saat": "10:42",
  "sorgu": "implant tedavisi",
  "hedef_pazar": "TR",
  "sehir_baglami": {
    "deger": "İzmir",
    "yontem": "kaynağın konum ayarı",
    "ip_ile_uyum": "yalnız ülke düzeyinde"
  },
  "dil": {
    "accept_language": "tr-TR,tr;q=0.9",
    "arayuz_dili": "tr",
    "sonuc_bolgesi": "TR"
  },
  "cikis": {
    "urun": "rotating-ipv4",
    "ip": "203.0.113.24",
    "ip_ulkesi": "TR",
    "ip_sehri_veritabani": "Ankara"
  },
  "cihaz": "mobil",
  "cerez": "temiz",
  "hesap_oturumu": false,
  "sonuc": {
    "durum": "gecerli",
    "yerel_paket_var": true,
    "yerel_paket_sayfa_yeri": "ilk organik sonuçtan önce",
    "yerel_paket_sirasi": 2,
    "organik_sira": 7,
    "paketteki_rakipler": ["Klinik A", "Klinik B"]
  }
}

Örnekte iki alana dikkat edin. sehir_baglami alanı şehrin hangi yoldan verildiğini söyler; ileride yöntemi değiştirirseniz eski ve yeni ölçümleri birbirinden ayırabilirsiniz. ip_sehri_veritabani alanı ise IP’nin konum veritabanındaki şehrini tutar ve örnekte bilinçli olarak İzmir değil, Ankara’dır. Ölçüm bu yüzden geçersiz sayılmaz, çünkü IP’nin görevi yalnız ülkeyi taşımaktır; ama uyuşmazlık kayıt altındadır ve gerektiğinde süzülebilir.

Dil tarafında üç ayrı değer tutmanızı öneririz: istemcinin gönderdiği Accept-Language başlığı, arama arayüzünün dili ve sonuçların hangi bölgeye göre istendiği. Bu üç değer çoğu zaman birbirine bağlı görünür ama ayrı ayarlanabilir ve kullandığınız kaynakta farklı adlarla geçebilir. Kanada’da Fransızca arama yapan kullanıcıları hedefleyen bir işletme için doğru kombinasyon Kanada çıkışı, Fransızca dil, Kanada bölgesi ve gerekiyorsa Montréal şehir bağlamıdır. Raporda bu kombinasyonun “CA / fr / Montréal” gibi açık bir etiketle gösterilmesi, aynı ülkedeki İngilizce serinin onunla karıştırılmasını önler.

Kart, kişisel veri açısından da sınır çizer. Yerel paket ve harita sonuçları işletme adlarının yanında yorum parçacıkları ve yorum yazanların adlarını da gösterebilir. Ölçüm kartına işletme adı, puan ve yorum sayısı yeterlidir. Yorum yazan kişilerin adları, fotoğrafları ya da yorum metinleri sıralama ölçümü için gerekli değildir; KVKK ve GDPR’ın veri en aza indirme ilkesi gereği saklanmamalıdır. Hata ayıklama için ham sayfa kopyası tutuyorsanız saklama süresini kısa tutun ve süre dolunca silin.

Yanlış ülkeden toplanmış bir gün, hiç ölçülmemiş bir günden daha zararlıdır; çünkü raporda gerçek bir hareket gibi görünür. Bu yüzden her tur, arama kaynağına tek bir sorgu göndermeden önce kısa bir ön kontrolle başlamalıdır: çıkış IP’si hangi ülkede görünüyor, dil profili beklenen değerde mi, bağlantı sağlıklı mı?

Aşağıdaki kabuk betiği bu kontrolü yapar ve sonucu bir günlük dosyasına yazar. Bağlantı biçimi, desteklenen protokol ve ülke seçiminin nasıl yapıldığı, yani kimlik bilgisinin içinde mi yoksa ayrı bir ayarda mı verildiği, ürüne göre değişebilir; doğru yazımı panelden kontrol edin. Konum servisi olarak, çıkış adresini ve ülkesini döndüren ve kullanım koşulları bu tür kontrollere izin veren bir servis seçin; yanıttaki alan adları servise göre değişir.

#!/usr/bin/env bash
# Tur öncesi ön kontrol: çıkış ülkesi ve dil profili.
# Gerçek kimlik bilgilerini bu dosyaya yazmayın; ortam değişkeni olarak verin.
PROXY="http://KULLANICI:ŞİFRE@GATEWAY:PORT"   # biçim ve şema panelde yazana göre
KONUM_URL="HEDEF_URL"   # çıkış IP ve ülkesini JSON döndüren, izinli bir servis
BEKLENEN_ULKE="TR"
DIL="tr-TR,tr;q=0.9"
GUNLUK="onkontrol.log"

yanit=$(curl -s --max-time 20 -x "$PROXY" -H "Accept-Language: $DIL" "$KONUM_URL")
ip=$(printf '%s' "$yanit" | jq -r '.ip // empty')
ulke=$(printf '%s' "$yanit" | jq -r '.country // empty')   # alan adı servise göre değişir
zaman=$(date -u +%Y-%m-%dT%H:%M:%SZ)

if [ -z "$ip" ]; then
  echo "$zaman DUR baglanti_yok" >> "$GUNLUK"
  exit 2
fi

if [ "$ulke" != "$BEKLENEN_ULKE" ]; then
  echo "$zaman DUR ulke_uyusmazligi beklenen=$BEKLENEN_ULKE gelen=$ulke ip=$ip" >> "$GUNLUK"
  exit 1
fi

echo "$zaman OK ip=$ip ulke=$ulke dil=$DIL" >> "$GUNLUK"

Betik bilinçli olarak sert davranır: ülke tutmazsa turu başlatmaz ve nedeni günlüğe yazar. Dönen bir havuzda her istek farklı bir adresten çıkabileceği için bu kontrolün yalnız tur başında değil, tur içinde de belirli aralıklarla tekrarlanması iyi olur; örneğin her elli ölçümde bir. Static bir adres kullanıyorsanız tur başına tek kontrol çoğu zaman yeterlidir, ama adresin konum veritabanlarındaki görünümü zamanla değişebileceği için kontrolü tamamen atlamayın.

İki IP davranışı yerel ölçümde farklı sorulara cevap verir. Static bir adres, aynı ülkeden aynı kimlikle tekrar tekrar bakmanızı sağlar; bir sorgunun sonucu değiştiğinde IP sabit olduğu için değişimin adresten kaynaklanmadığını bilirsiniz. Dönen adresler ise aynı ülkedeki farklı ev bağlantılarından örnek almanızı sağlar; bir sonucun tek bir adrese mi özgü olduğunu, yoksa o ülkede yaygın mı göründüğünü anlamaya yarar.

Yerel ölçümde bu ikisi rakip değil, tamamlayıcıdır. Küçük bir referans seti sabit adresten, geniş set dönen havuzdan ölçüldüğünde, referans setindeki ani bir değişim “arama motorunda bir şey oldu” sinyali verir; geniş setteki dağılım ise sonucun ne kadar kararlı olduğunu gösterir. Referans setinde hiçbir şey kıpırdamazken geniş sette büyük bir kayma görüyorsanız, önce geniş setin ölçüm düzeneğini, özellikle konum ayarını ve dil profilini kontrol edin. Aşağıdaki tablo katalogdaki ürünleri yerel ölçüm işleriyle eşleştirir.

Tablodaki son satır bir uyarı taşır. Arama kaynağı IPv6 üzerinden de yanıt veriyor olabilir, ama IPv6 adreslerinin konum veritabanlarındaki karşılığı IPv4’le aynı titizlikte doğrulanmalıdır. IPv6 ile ölçüme geçmeden önce aynı sorgu setini bir süre iki adres ailesinden paralel ölçüp sonuçları karşılaştırın; fark anlamlıysa iki aileyi aynı seride karıştırmayın.

Static adresin cazip bir yan faydası, ekip üyelerinin aynı adresi tarayıcıda kullanarak elle kontrol yapabilmesidir. Burada tek kural, arama motoruna kişisel ya da kurumsal bir hesapla giriş yapılmamasıdır. Oturum açık bir hesabın arama geçmişi sonuçları o hesaba göre kişiselleştirir; ölçtüğünüz şey artık pazar değil, o hesabın kendisi olur. Elle kontroller için ayrı, temiz bir tarayıcı profili açmak bu riski büyük ölçüde ortadan kaldırır.

Yerel sonuçlar organik listeye göre daha hareketli olabilir, ama bu her sorguyu her gün ölçmeyi gerektirmez. Sıklığı sorgunun iş değerine ve sonucun ne kadar hızlı değiştiğine göre belirleyin; hız planını ise sıklıktan değil, kaynağın kurallarından türetin. Aşağıdaki tablo bir başlangıç noktasıdır; pilot döneminde gözlediğiniz değişim hızına göre ayarlayın.

Hız planında amaç, toplam işi kaynağı zorlamadan zamana yaymaktır. Yerel ölçümde buna bir koşul daha eklenir: her sorgu her turda günün aynı saatinde ölçülmelidir, çünkü zaman da sonucu etkileyen bir sinyaldir. İki hedefi birlikte karşılamanın basit yolu sabit saat yuvası yöntemidir. Ölçüm penceresini, örneğin hedef pazarın yerel saatiyle 09.00 ile 19.00 arasını, eşit aralıklı yuvalara bölün ve her sorgu bağlamına kalıcı olarak bir yuva atayın. Böylece “İzmir, implant tedavisi, mobil” bağlamı her turda aynı dakikada ölçülür; yük güne yayılır, zaman etkisi seriden çıkar.

Yuva aralığını, kaynağın kullanım koşullarının ve hız sınırlarının izin verdiği düzeyden daha sık tutmayın. Bir tur için gereken yuva sayısı pencereye sığmıyorsa çözüm aralığı kısaltmak değil, turu iki güne bölmek ya da sorgu setini daraltmaktır. Paralel çalışma gerekiyorsa her paralel kolun kendi aralığını koruduğundan ve kolların aynı anda başlamadığından emin olun; aynı saniyede başlayan kollar kısa sürede yoğun bir yük oluşturur ve sabit yuvanın sağladığı düzeni bozar.

Kaynağın kullanım koşulları ve robots.txt dosyası otomatik sorguya izin vermiyorsa, hız planı ya da residential çıkış bu durumu değiştirmez; yükümlülük isteği gönderen taraftadır. Yüksek hacimli, şehir bazlı ölçümler için lisanslı bir SERP veri hizmeti çoğu zaman hem daha uyumlu hem de daha az bakım gerektiren yoldur. Böyle bir kurulumda kendi residential çıkışınız, hizmetin döndürdüğü sonuçları seçilmiş örneklerde bağımsız olarak doğrulamak için değerini korur.

Ankara, İzmir ve Bursa’da şubeleri olan bir ağız ve diş sağlığı kliniği zincirini düşünelim. Klinik hem bu üç şehirde yerel hasta kazanmak hem de Birleşik Krallık ve Hollanda’dan tedavi için Türkiye’ye gelmeyi düşünen kişilere ulaşmak istiyor. Pazarlama ekibi üç soruya cevap arıyor: her şehirde çekirdek hizmet sorgularında yerel pakette görünüyor muyuz, pakette kimlerle yan yanayız ve yurt dışında Türkiye’deki tedavi seçeneklerini araştıran kullanıcılar bizi organik listede nerede görüyor?

Aşağıdaki hesapta fiyatlar ResidentialProxy kataloğundandır. Sorgu sayıları, sıklıklar, istek başına veri miktarı ve tekrar payı varsayımdır; kendi pilot ölçümünüzle değiştirmeniz gerekir.

• —Varsayım 1: Türkiye’de 60 yerel niyetli sorgu vardır ve her biri üç şehir bağlamında ölçülür; toplam 180 sorgu bağlamı. Şehir bağlamı kaynağın konum ayarıyla verilir, IP yalnız Türkiye’yi taşır.
• —Varsayım 2: Türkiye bağlamları mobil profille haftada iki tur, masaüstü profille haftada bir tur ölçülür. Ay dört hafta kabul edilir.
• —Varsayım 3: Birleşik Krallık ve Hollanda’da 40’ar sorgu, şehir bağlamı olmadan, mobil ve masaüstü profille haftada bir tur ölçülür.
• —Varsayım 4: Yalın bir HTTP istemcisiyle istek başına ortalama 350 KB veri aktarılır; tekrar ve ertelemeler için yüzde 15 pay eklenir. Hesapta 1 GB = 1.000.000 KB alınır.
• —Varsayım 5: Raporda gösterilecek 30 öncelikli sorgunun üç şehirdeki görünümü, haftada bir tam tarayıcıyla açılıp ekran görüntüsüyle kanıt arşivine alınır; tarayıcıyla açılan sayfa başına 2.500 KB veri varsayılır.
• —Varsayım 6: 20 çekirdek sorgudan oluşan referans seti, Türkiye’deki tek bir static IPv4 adresinden ve Ankara bağlamıyla her gün bir kez ölçülür.

“Aylık eşdeğer” ifadesi bilinçli seçildi. Rotating IPv4 paketleri GB bazlı ve tek seferlik faturalanır; gerçek harcama paket alındığında gerçekleşir. Katalogda 10, 20, 50 ve 100 GB paketlerinin hepsi GB başına 1,20 USD’ye denk gelir; 2 GB’lık paket ise GB başına 1,25 USD’dir. Bu tüketimle 10 GB’lık paket (12 USD) yaklaşık 4,9 ay yeter (10 / 2,03). 2 GB’lık paket (2,50 USD) aylık 2,03 GB’lık tüketimin biraz altında kaldığı için tek başına bir ayı karşılamaz; pilot için uygundur, düzenli ölçüm için değil. Paketlerin kullanım koşullarını sipariş adımında kontrol edin. Static IPv4 tarafında trafik koşulu katalogda ayrıca yazmaz; referans hattının günde 20 sorguluk yükü düşük olsa da bunu da sipariş adımında doğrulayın.

Hesaptan üç ders çıkar. Birincisi, kanıt arşivi rotating havuzdan açılan sayfaların yaklaşık yüzde 10’unu oluşturduğu halde trafiğin yaklaşık yüzde 44’ünü tüketir (360 / 3.580 sayfa; 0,90 / 2,03 GB). Tam tarayıcıyla açılan her sayfa yalın bir istekten kat kat ağırdır; ekran görüntüsünü yalnız raporda gerçekten gösterilecek sorgularla sınırlamak, bütçeyi en çok etkileyen karardır.

İkincisi, yurt dışı pazarlar için static adres almak bu senaryoda mantıklı değildir. Birleşik Krallık ve Hollanda’da static IPv4 paketleri 5 IP ile 17,5 USD’den başlar ve iki ülke için aylık 35 USD eder. Aynı ölçümün rotating havuzdaki payı ise yaklaşık 0,26 GB, yani aylık 0,31 USD civarıdır (640 × 1,15 × 350 KB; 0,26 × 1,20). Static adres, aynı ülkeden her gün ve aynı kimlikle bakmanız gereken durumlar için anlamlıdır; haftada bir yapılan ülke düzeyi ölçüm bu tanıma girmez.

Üçüncüsü, şehir sayısını artırmak maliyeti doğrusal büyütür ama ürün değişikliği gerektirmez. Dördüncü bir şehir eklemek Türkiye kalemlerini üçte bir oranında artırır (2.160 istekten 2.880 isteğe), çünkü şehir bağlamı IP’den değil konum ayarından gelir. Aynı nedenle yeni şehir için ayrı bir adres satın almak da gerekmez; gereken, ölçüm kartına yeni bir şehir değeri ve sabit yuva planına yeni yuvalar eklemektir.

Hız planı da aynı hesaptan çıkar. Rotating havuzdaki 3.580 sayfa, dört haftalık bir ayda kabaca günde 128 sayfa eder (3.580 / 28), yani yük her güne yayıldığında bile sıfır değildir. Bunu 10 saatlik bir pencereye dağıttığınızda saatte yaklaşık 13 sayfa, yani ortalama dört ila beş dakikada bir istek düşer (varsayım: yük tek bir kolda, eşit aralıklarla akar). Bu aralığın kaynağın koşullarına uygun olup olmadığını pilotta sınayın; uygun değilse turları haftanın daha fazla gününe yayın.

Aşağıdaki sıra, yerel ölçüm düzeneğini gerçek bir şehir görünümüyle sınamak ve ancak ondan sonra ölçeklemek için tasarlandı. Adımların çoğu bir öğleden sonra sürer; asıl zaman alan, sahadan gelen örneklerle otomatik ölçümün karşılaştırılmasıdır.

1. 01Şehir ve sorgu matrisini yazın: Her şube şehri için hizmet sorgularını, şehir adı içeren ve içermeyen varyantlarıyla listeleyin. “implant tedavisi” ile “implant tedavisi İzmir” farklı niyetler taşır ve ikisi de yerel paket üretebilir.
2. 02Ölçüm kartı şemasını sabitleyin: Dil, bölge, şehir bağlamı ve yöntemi, cihaz, çıkış ülkesi, IP’nin veritabanındaki şehri ve yerel saat alanlarını ilk ölçümden önce kesinleştirin; sonradan eklenen alanlar eski kayıtlarda boş kalır.
3. 03Küçük paketlerle başlayın: Pilot için Rotating IPv4’ün 2 GB’lık paketi ve referans hattı planlıyorsanız Türkiye için tek bir static IPv4 adresi yeterlidir.
4. 04Ön kontrolü çalıştırın: Her pazar için çıkış ülkesini ve dil profilini doğrulayın; ülke tutmayan bir pazarda ölçüme başlamayın.
5. 05Sabit yuva planını oluşturun: Her sorgu bağlamına pencere içinde kalıcı bir dakika atayın ve planı bir dosyada saklayın; yeni sorgular boş yuvalara eklenir, mevcutların yeri değişmez.
6. 06Sahadan karşılaştırma örneği toplayın: Pilotun ilk haftasında her şubeden birkaç çekirdek sorgunun telefon ekran görüntüsünü, otomatik ölçümle aynı gün ve aynı saat yuvasında, oturum kapalı bir tarayıcıyla isteyin.
7. 07Otomatik ölçümü sahayla karşılaştırın: Yerel paketteki işletmeler ve sıraları iki kaynakta ne kadar örtüşüyor? Belirgin bir fark varsa önce konum ayarının ölçüme ulaşıp ulaşmadığını, sonra dil ve cihaz profilini kontrol edin.
8. 08Yükü temkinli başlatın: İlk turlarda yuva aralığını planlananın iki katı tutun; doğrulama sayfası ya da 429 görülmezse birkaç tur içinde plana yaklaşın.
9. 09Trafik varsayımını gerçek veriyle değiştirin: Pilotta ölçülen ortalama sayfa ağırlığını 350 KB varsayımının yerine koyup aylık hesabı yeniden yapın ve paketi buna göre seçin.
10. 10Raporu göstergelere bölün: Organik sıra, yerel pakette görünme oranı ve paketteki ortalama konum ayrı sütunlarda raporlansın; hepsini tek bir ortalama sıra sayısında birleştirmeyin.

Altıncı ve yedinci adımlar yerel ölçümü genel sıra takibinden ayıran adımlardır. Otomatik ölçümün ürettiği şehir görünümü, o şehirdeki gerçek bir telefonun gördüğüyle hiç karşılaştırılmadıysa raporun “İzmir” etiketi bir varsayımdan ibarettir. Saha örneği az sayıda olabilir; amacı istatistik üretmek değil, ölçüm düzeneğinin doğru şehri gösterip göstermediğini sınamaktır. Karşılaştırmayı her çeyrekte bir tekrarlamak, arama motorunun konum sinyallerini yorumlama biçimindeki değişiklikleri de erken yakalamanızı sağlar.

Yerel ölçümde sorunların çoğu bağlantı kopmasından değil, bağlamın eksik ya da yanlış aktarılmasından doğar. Aşağıdaki tablo en sık karşılaşılan belirtileri, olası nedenleri ve çözüm yolunu bir arada verir.

Tablodaki belirtilerin çoğunun ortak kökü, ölçümle birlikte saklanmayan bir bağlam bilgisidir. Ölçüm kartı eksiksiz tutulduğunda teşhis, kayıtları ilgili alana göre süzmekten ibarettir. Tutulmadığında ise geçmiş ölçümleri yeniden yorumlamanın yolu kalmaz ve tek seçenek, sorunlu dönemi rapordan çıkarmaktır.

Aşağıdaki listeyi ilk düzenli turdan önce, ardından her ayar değişikliğinde gözden geçirin. Her madde, bu sayfada anlatılan yanılgılardan birini kaynağında önler.

• —Her pazar için çıkış ülkesi, dil profili, sonuç bölgesi ve cihaz profili tek bir yerde tanımlı.
• —Şehir bağlamı IP’ye bırakılmamış; kaynağın konum ayarıyla veriliyor ve yöntemi kayda yazılıyor.
• —Ölçüm kartında IP’nin konum veritabanındaki şehri ayrı bir alan olarak tutuluyor.
• —Organik sıra, yerel pakette görünme oranı ve paketteki konum ayrı göstergeler olarak raporlanıyor.
• —Harita ölçümü yapılıyorsa merkez noktası ve yakınlaştırma düzeyi sabit ve kayıtlı.
• —Her sorgu bağlamına sabit bir saat yuvası atanmış; ölçümün yerel saati karta yazılıyor.
• —Ön kontrol tur başında çalışıyor; ülke tutmayan pazarda tur başlamıyor.
• —Doğrulama sayfası ve 429 yanıtında tur duruyor; bu ölçümler geçersiz olarak işaretleniyor.
• —Ölçüm ya da elle kontrol sırasında arama motoruna hiçbir hesapla giriş yapılmıyor.
• —Yorum yazanların adları, fotoğrafları ve yorum metinleri saklanmıyor; ham sayfa kopyalarının saklama süresi belli.
• —Kaynağın kullanım koşulları ve robots.txt dosyası gözden geçirildi; yüksek hacimli şehir bazlı ölçüm için lisanslı veri hizmeti değerlendirildi.
• —Seçilen pazarların katalogdaki ülke listelerinde yer aldığı doğrulandı; İspanya gibi static IPv4 paketi görünmeyen ülkeler için sipariş adımı kontrol edildi.
• —Pilot sonrası trafik varsayımı gerçek sayfa ağırlığıyla güncellendi ve paket buna göre seçildi.
• —Sahadan alınan karşılaştırma örnekleri arşivlendi ve bir sonraki karşılaştırmanın tarihi belirlendi.

Yerel SERP takibi doğru kurulduğunda, bir şubenin kendi şehrindeki görünürlüğünü ülke ortalamasının arkasına saklamadan gösterir. Residential çıkış bu tablonun ülke katmanını sağlam kılar; şehir katmanını, zamanı ve dili ise ölçüm tasarımınız taşır. İkisini birbirine karıştırmadığınız sürece raporunuzdaki her şehir etiketi neyi temsil ettiğini açıkça söyler.