Search Console API ile Günlük SEO Uyarı Sistemi Kurma

Organik trafik bazen bir gecede düşmez, siz geç fark edersiniz. Sabah açtığınız ilk raporda sorun görünüyorsa, çoğu zaman kayıp saatler önce başlamıştır.

Bu yüzden Search Console API ile çalışan günlük bir uyarı sistemi, manuel kontrolden daha değerlidir. Doğru kurulduğunda size sadece “düşüş var” demez; hangi sayfada, hangi metrikte ve ne kadar ciddi olduğunu da söyler. Aşağıdaki akış, bunu günlük iş rutininin parçası haline getirir.

Elle kontrol yerine her sabah çalışan bir sistem kurun

Search Console arayüzü iyi bir başlangıç noktasıdır, fakat düzenli takip için yavaştır. Her sabah site geneli, klasör bazlı sayfalar, kritik landing page’ler ve indeksleme sinyallerini tek tek kontrol etmek sürdürülebilir değildir.

Günlük uyarı sistemi daha basit bir mantıkla çalışır. Önce veriyi çeker. Sonra dünkü değil, son tamamlanmış günü doğru bir bazla karşılaştırır. Eşik aşılırsa bildirim yollar. Bu kadar.

Kurulumu şu sırayla düşünün:

1. Search Console’dan günlük veriyi alın.
2. Veriyi küçük bir tabloya veya veritabanına kaydedin.
3. Son günü geçmişteki benzer günlerle karşılaştırın.
4. Eşikleri aşan sapmaları işaretleyin.
5. Slack, e-posta veya Telegram ile uyarı gönderin.

İlk kez kuruyorsanız, önce property erişimini ve veri tutarlılığını netleştirin. Domain property ile URL-prefix property’yi karıştırmak sık görülen bir sorundur. Teknik tarafınız karışıksa, önce bir detaylı SEO analizi yapmak daha sağlıklı olur.

Bağlantı kısmında takılanlar için, Python ile Search Console API bağlantısı üzerine hazırlanmış pratik bir örnek işinizi hızlandırır. Ancak asıl farkı yaratan nokta bağlantı değil, karşılaştırma mantığıdır.

Veri çekme katmanında neyi, nasıl toplamalısınız

Günlük uyarı sisteminin omurgası searchanalytics.query çağrısıdır. Python tarafında çekirdek yapı kısa kalır: build("searchconsole", "v1", credentials=creds) ile servisi başlatır, ardından service.searchanalytics().query(...).execute() ile veriyi çekersiniz.

Veriyi tek seviyede toplamayın. Farklı amaçlar için farklı boyutlar gerekir. Site geneli alarm için date, sayfa kaybı için date,page, sorgu analizi için date,query yeterlidir. Cihaz veya ülke bazında izleme istiyorsanız bu boyutları ayrı raporlarda çalıştırın.

Ham veriyi dosyada bırakmayın. Küçük projelerde CSV iş görür, ama günlük karşılaştırma için SQLite daha rahattır. pandas.DataFrame(rows) ile tabloya dönüştürüp her çalışmada üstüne yazmak yerine tarih damgasıyla saklayın. Böylece yanlış alarmı sonradan inceleyebilirsiniz.

Bugünün verisiyle alarm kurmayın. Search Console verisi çoğu mülkte aynı gün netleşmez, bu yüzden son tamamlanmış günü baz alın.

Uygulamada çoğu ekip D-3 veya API’nin en güncel dolu tarihini kullanır. Sonra buna bir “veri var mı” kontrolü ekler. rows boşsa sistem hata vermesin, o gün bildirim göndermeden çıksın.

Daha geniş veri çekme ve tabloya dönüştürme örnekleri için Search Console verilerini Python ile otomatize etmek iyi bir referanstır. Sayfa, ülke ve filtre mantığını büyütmek isterseniz Search Console veri takibi örnekleri de faydalıdır.

Önceki günlerle kıyaslama yaparken doğru baz alın

En büyük hata, son günü bir önceki günle karşılaştırmaktır. Pazartesi ile pazar aynı davranmaz. Kampanya günleri, hafta sonu etkisi ve markalı sorgular bunu daha da bozar.

Daha sağlam bir yöntem, son tamamlanmış günü aynı haftanın günleriyle kıyaslamaktır. Örneğin salı gününü önceki 4 salının medyanıyla karşılaştırın. Böylece tek bir anormal gün tüm sistemi saptırmaz.

Basit oran hesabı yeterlidir: degisim = (son_gun - baz_deger) / baz_deger. Burada baz değeri medyan veya hareketli ortalama olabilir. Benzer şekilde konum için mutlak fark kullanın, yüzde değil.

Eşik belirlerken hacmi hesaba katın. Günlük 12 tıklama alan sayfa için yüzde 40 düşüş gürültüdür. Günlük 500 tıklama alan kategori için aynı düşüş alarmdır. Bu yüzden her kuralda bir de alt hacim sınırı tanımlayın.

Pratik bir başlangıç seti şöyle olabilir:

• Site genelinde tıklama düşüşü için, baz hacim en az 200 ise yüzde 25 alarm.
• Gösterim düşüşü için, baz hacim en az 1000 ise yüzde 30 alarm.
• Ortalama konum için, en az 1000 gösterimde 2 puandan fazla kötüleşme alarm.
• Kritik URL’lerde, baz hacim en az 20 tıklama ise yüzde 50 düşüş alarm.

Ayrıca klasör bazlı kurallar da ekleyin. /blog/, /kategori/ veya para sayfaları ayrı izlenirse sorunun kapsamını daha hızlı görürsünüz.

Hangi sinyaller alarm üretmeli, hangileri sadece not düşmeli

İlk sürümde her şeyi izlemeye çalışmayın. Az sayıda, güvenilir sinyal daha iyi sonuç verir. Aşağıdaki tablo, günlük sistem için en kullanışlı alarm tiplerini özetler.

Uyarı tipi	Kural örneği	Ek filtre	İlk kontrol
Site geneli tıklama düşüşü	Aynı haftanın günü medyanına göre yüzde 25 altı	Baz hacim 200+	Genel görünürlük kaybı var mı
Gösterim düşüşü	Medyana göre yüzde 30 altı	Marka dışı segment ayrı izlenmeli	Tarama, indeksleme, talep düşüşü ayrımı
Ortalama konum kaybı	2 puan veya daha kötü	En az 1000 gösterim	Cihaz ve ülke dağılımı değişti mi
Belirli sayfada trafik kaybı	Kritik URL’de yüzde 50 düşüş	Son 7 gün ortalaması 20+ tıklama	Başlık, canonical, noindex, iç linkler
İndeksleme sinyali	Yeni hata veya dizinlenebilirlik bozulması	Kritik URL listesi	robots, canonical, sitemap, sunucu durumu

Ortalama konum uyarılarını tek başına kullanmayın. Çünkü bazen tıklama sabit kalır, yalnızca sorgu karışımı değişir.

Ortalama konum, bağlam olmadan yanıltır. Tıklama veya gösterim desteği yoksa bunu düşük öncelikli uyarı sayın.

Belirli sayfalarda trafik kaybı, en hızlı aksiyon alınan alarm türüdür. Mesela ürün kategorisi sayfası yüzde 60 düşmüşse, önce başlık değişimini, canonical etiketini, noindex riskini ve dahili bağlantıları kontrol edin. Site geneli sabitken tekil sayfa düşüyorsa sorun çoğu zaman şablon, içerik veya teknik yayındadır.

İndeksleme ve coverage tarafını da ikinci katman olarak ekleyin. Bu sinyal performans verisinden ayrı düşünülmeli. Kritik URL listesi oluşturup düzenli URL denetimi veya indeks raporu farklarını izleyin. Bu konuda daha derin bir çerçeve için Google Search Console indeks sorunları rehberi işe yarar.

Görsel doğrulama için bazen hızlı bir tablo yeterlidir. Bunun için Search Console verilerini Google Sheets ile analiz etme yaklaşımı, alarm sonrası manuel kontrolü hızlandırır.

Bildirim gönderme ve cron zamanlamasını sade tutun

Alarm üretildiğinde mesaj kısa ve karar verdiren formatta olmalı. Uzun rapor kimseyi harekete geçirmez. İyi bir bildirimde metrik, sapma oranı, etkilenen sayfa grubu ve karşılaştırılan baz net görünür.

Örnek bir Slack mesajı şu yapıda olabilir: “Organik tıklama düşüşü, /kategori/ klasöründe yüzde 38, son 4 aynı gün medyanına göre. En çok etkilenen URL: /x”. Python’da bunu requests.post(slack_webhook, json=payload) ile gönderebilirsiniz. E-posta tercih ediyorsanız smtplib yeterlidir.

Zamanlama tarafında cron hâlâ en temiz çözümdür. Linux sunucuda günlük görev için 0 8 * * * /usr/bin/python3 /home/seo/gsc_alerts.py mantığı yeterlidir. Saat seçerken veri gecikmesini hesaba katın. Çoğu ekip sabah erken yerine biraz daha geç saat kullanır.

Windows kullanıyorsanız Görev Zamanlayıcı da aynı işi görür. Yerel makinede çalıştırmak mümkün, fakat ajans veya ekip kullanımı için küçük bir VPS daha güvenlidir. Çünkü bilgisayar kapalıysa alarm da susar.

Bildirim akışında tek bir hata tüm zinciri bozmasın. Veri çekme başarılıysa ama Slack düşerse, sonuç yine log’a yazılsın. Sonra yeniden deneme yapılsın.

Yanlış alarmı azaltan kontrol noktaları ve hata ayıklama ipuçları

Günlük sistemin değeri, ne kadar çok alarm ürettiğinde değil, ne kadar az gereksiz alarm ürettiğinde ortaya çıkar. Bu yüzden kurulumdan sonra birkaç savunma katmanı ekleyin.

• Son çalışmanın tarihini ve çekilen satır sayısını log’layın.
• 403 ve 429 hataları için yeniden deneme ekleyin.
• Domain property ile URL-prefix property’nin karışmadığını kontrol edin.
• Mobil, masaüstü ve ülke kırılımlarını ayrı izleyin.
• Düşük hacimli sayfalarda yüzde bazlı alarmı tek başına kullanmayın.
• Aynı sorunu her gün tekrar göndermemek için “cooldown” kuralı tanımlayın.

Bir diğer sık sorun, sayfa URL’lerinin değişmesidir. Parametreli URL’ler, slash farkı veya canonical değişimi nedeniyle sayfa bazlı karşılaştırma bozulabilir. Bu yüzden kritik URL listesini normalize edin.

Veri gelmiyorsa önce kodu değil yetkiyi kontrol edin. Property erişimi silinmiş olabilir. Yanlış site adresi kullanılmış olabilir. Hâlâ sorun varsa, en son başarılı API yanıtını ve sorgu gövdesini saklayın. Sorunu saniyeler içinde bulursunuz.

Sonuç

İyi bir günlük uyarı sistemi, her sabah panel açma işini ortadan kaldırır. Daha önemlisi, gerçek sorunu erken gösterir.

En sağlam kurgu şudur: son tamamlanmış günü çekin, doğru bazla kıyaslayın, düşük hacmi filtreleyin ve sadece anlamlı sapmaları bildirin. İlk sürümde site geneli tıklama düşüşü ile kritik sayfa kaybını kurmanız bile büyük fark yaratır. Sonrası, aynı iskeletin üstüne yeni sinyaller eklemekten ibarettir.

This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.