Sunucu yanıt süresi dalgalandığında organik görünürlükteki etkiler nasıl okunur?

Sunucu yanıt süresi dalgalandığında önce neyin bozulduğunu ayırın

2026’da bu soruyu doğru okumak için ilk iş, gördüğünüz yavaşlığın kısa süreli pik mi yoksa kalıcı bozulma mı olduğunu ayırmaktır. Saatlik trafik baskısında yükselen p95 TTFB ile günlerce süren yanıt bozulması aynı SEO etkisini üretmez. Kısa pikler çoğu zaman kampanya, cron, cache purge veya veritabanı yoğunluğu ile ilişkilidir; kalıcı bozulma ise tarama hızını düşürüp görünürlük eğrisine daha net yansır. Bu yüzden ilk grafiğiniz tek bir ortalama değil, aynı tarih aralığında p75, p95, 5xx oranı ve yoğun trafik saatlerini göstermelidir.

Saatlik pik ile günler süren bozulmayı farklı okuyun

Pratikte şu ayrım iş görür:

• p75 yükseliyor, p95 zıplamıyorsa sorun çoğu kullanıcıya yayılmış olabilir.
• p95 sıçrıyor, p75 sabitse belirli saatlerdeki darboğazı ararsınız.
• 5xx oranı eşlik ediyorsa yalnız hız değil, erişilebilirlik de etkileniyordur.
• Trafik saatiyle çakışıyorsa kapasite veya cache verimsizliği ihtimali güçlenir.

Burada TTFB ile sunucu yanıt süresini de karıştırmamak gerekir. web.dev’in 28 Kasım 2025 güncellenen TTFB rehberine göre TTFB; redirect, DNS, bağlantı ve ilk byte’a kadar geçen toplam süreyi kapsar. Chrome for Developers’ın 27 Mart 2025 tarihli document request latency dokümanında ise 600 ms eşiği özellikle server response time için anlatılır. Yani kullanıcı tarafında gördüğünüz şişme bazen origin’den değil, redirect zincirinden veya DNS çözümünden gelir.

Field data ile lab data çelişirse hangisi ağır basar?

Görünürlük yorumunda önceliği çoğunlukla field data alır; çünkü organik kaybı gerçek kullanıcı deneyimi ve gerçek trafik koşullarıyla okursunuz. Lab test, teşhisi hızlandırır ama tek başına karar verdirmez. Field veri kötüleşiyor, lab veri temiz görünüyorsa çoğu zaman sorun belirli saatlerde, cihaz gruplarında veya coğrafyalarda ortaya çıkıyordur. Bu nedenle hipotez ağacını origin, DNS, redirect ve CDN katmanlarına bölmek gerekir: DNS hatası varsa lookup süresi yükselir, redirect fazlaysa TTFB şişer, CDN miss oranı artarsa yalnız yoğun saatlerde ilk byte uzar, origin yavaşsa hem kullanıcı hem Googlebot tarafı birlikte bozulur.

Organik görünürlükteki etkiler nasıl okunur: tarama, sıralama ve UX

Sunucu dalgalanmasının organik görünürlüğe etkisini okumak için GSC performans verisini olay öncesi ve sonrası mantığıyla değerlendirin. Önce impression düşüyor mu, sonra average position mu bozuluyor, yoksa ilk tepki CTR‘de mi geliyor? Bu sıralama önemlidir. Google’ın 10 Aralık 2025 güncellenen Page Experience dokümanında açıkça söylediği gibi, tek bir page experience sinyali yoktur; Core Web Vitals sıralama sistemlerinde kullanılır ama tek başına zirveyi garanti etmez. Bu yüzden yalnız LCP kötüleşti diye sıralama kaybını kesin hüküm gibi okumayın; görünürlük tarafında içerik ve sorgu rekabeti de aynı anda kontrol edilmelidir.

Tarama cephesinde ise daha sert bir ilişki vardır. Google’ın 19 Aralık 2025 tarihli crawl budget dokümanına göre site bir süre hızlı yanıt verirse crawl capacity limit yükselebilir; site yavaşlar veya server error üretirse Google daha az tarar. Bu davranışı Search Console’daki Crawl Stats ile yan yana okuduğunuzda tablo netleşir. Crawl Stats report içindeki average response time grafiği yukarı giderken host status yeşilden kırmızıya yaklaşıyorsa, Googlebot tarafındaki daralma başlamış olabilir. Özellikle DNS resolution, host connectivity veya robots.txt availability tarafında kırmızı sinyal görüyorsanız sorunun yalnız kullanıcı tarafında kalmadığını anlarsınız.

Algoritma etkisi ile altyapı etkisini ayırmanın en pratik yolu segmentasyondur. Aşağıdaki kırılımlar çoğu teşhiste yeterlidir:

• Sorgu tipi: markalı, markasız, bilgi odaklı, ticari.
• Cihaz: mobil ve masaüstü ayrımı.
• Sayfa şablonu: kategori, ürün, blog, landing page.
• Saat ve gün: kampanya saati, mesai dışı, hafta sonu.

Eğer düşüş yalnız bir şablonda ve aynı saat aralığında görünüyorsa altyapı ihtimali güçlenir. Eğer tüm segmentlerde eş zamanlı pozisyon kaybı var ama Crawl Stats ve LCP sabitse, bu kez algoritmik veya rekabet kaynaklı açıklamaları öne alırsınız. Ekip içi hizalama için Google Search Central ve Chrome for Developers’ın kısa eğitim videolarını referans almak da yararlıdır; çünkü teknik ekip ile SEO ekibi aynı metriğe farklı isimler verebiliyor.

TTFB, document request latency ve LCP aynı grafikte nasıl ayrıştırılır?

Bu üç metriği tek çizgi gibi okumak hatadır. web.dev çoğu site için iyi TTFB’yi yaklaşık 0,8 saniye ve altı, zayıf TTFB’yi 1,8 saniye üzeri olarak konumlar. Chrome’ın document request latency içgörüsü ise ana doküman isteğinde 600 ms üzeri server response time’ı ayrı bir problem olarak işaretler. Aradaki fark şudur: TTFB toplam ilk byte süresidir; document request latency içindeki server response time ise özellikle sunucunun cevap üretme bölümünü vurgular. Bu nedenle 900 ms TTFB gördüğünüzde bunun 250 ms’i redirect, 120 ms’i DNS, 530 ms’i origin olabilir. Karar, toplamdan değil bileşenden verilir.

LCP kötüleştiğinde de otomatik olarak “sunucu sorunu” dememek gerekir. LCP’nin geç başlaması TTFB’den etkilenebilir, ama sorun render-blocking CSS, ağır istemci JavaScript’i, geç keşfedilen LCP kaynağı veya zincir redirect de olabilir. 2026’da iyi uygulama, aynı tarih ekseninde şu üç katmanı yan yana koymaktır: ana doküman TTFB, ana doküman server response time ve gerçek kullanıcı LCP dağılımı. Eğer yalnız TTFB yükseliyor ama LCP sabit kalıyorsa CDN veya cache katmanı darbeyi emiyor olabilir. Eğer TTFB ile birlikte LCP de bozuluyorsa, kullanıcı deneyimi tarafına yansıyan daha sistemik bir problem vardır.

• Redirect zinciri varsa TTFB şişer, server response time tek başına suçlu olmayabilir.
• DNS gecikmesi özellikle belirli bölgelerde ilk byte’ı taklit eden sahte sunucu sorunu yaratabilir.
• CDN miss oranı arttığında p95 TTFB yükselir, p50 daha sakin kalabilir.
• Origin darboğazı varsa hem Googlebot hem kullanıcı metriği birlikte bozulur.

Burada istemci tarafı doğrulama için MDN’in responseStart referansı çok işe yarar. responseStart ile requestStart farkını inceleyerek ilk byte gecikmesini gerçek kullanıcı oturumlarında da izleyebilirsiniz. Böylece APM’in gösterdiği p95 değerleri ile tarayıcı tarafındaki gözlemi eşleyip, hatanın yalnız backend’de mi yoksa ağ yolunda mı yoğunlaştığını daha net ayırırsınız.

Mini vaka: p95 TTFB sıçramasını GSC ve loglarla nasıl okuduk?

Benzer denetimlerde en öğretici desen, kampanya saatlerinde oluşan p95 sıçramaları oluyor. Yakın dönemde incelediğimiz anonim bir B2B e-ticaret vakasında 19:00-22:00 aralığında p95 TTFB 640 ms seviyesinden 2,1 saniyeye çıktı. Aynı pencerede 5xx oranı yüzde 0,3’ten yüzde 2,2’ye yükseldi. Dört gün sonra Crawl Stats average response time belirgin biçimde yukarı kaydı ve host status sarı uyarı vermeye başladı. Kullanıcı tarafında mobil LCP medyanı 2,4 saniyeden 3,5 saniyeye çıktı; ardından 11 günlük pencerede category template’lerde impression trendi yaklaşık yüzde 12 geriledi.

Bu veriyi ilk gördüğümüzde doğrudan algoritma değişikliği demedik. Önce markalı sorguları, masaüstünü ve blog şablonlarını ayırdık. Markalı sorgular görece sabit kaldı, blog içerikleri etkilenmedi, bozulma esas olarak kampanya trafiği alan kategori ve ürün sayfalarında toplandı. Bu, sorunun içerik kalitesi veya genel site otoritesinden çok kapasite ve render zinciriyle ilişkili olduğunu gösterdi. Sonra GSC performans verisini Crawl Stats, APM ve hata loglarıyla üst üste bindirdik. Görünürlük kaybı aynı gün başlamadı; önce crawl ve UX bozuldu, görünürlük etkisi birkaç gün gecikmeyle geldi. Bu sıralama, altyapı kaynaklı düşüşlerde sık gördüğümüz bir imzadır.

İstemci tarafı doğrulamada responseStart ölçümünü kullandık ve özellikle cache miss olan sayfalarda ilk byte gecikmesinin tarayıcıda da yükseldiğini gördük. Log tarafında en pahalı sorguların kampanya filtreleriyle çakıştığı, redirect zincirinde iki gereksiz adım olduğu ve edge cache süresinin fazla kısa tutulduğu ortaya çıktı. Düzenlemeler sonrası p95 TTFB 780 ms seviyesine, mobil LCP 2,6 saniyeye indi. Impression toparlanması anlık olmadı; yaklaşık iki haftalık gecikmeyle geri dönüş başladı. Bu da şu noktayı netleştirir: sunucu dalgalanmasını çözmek gerekir, ama organik görünürlük toparlanmasının tarama ve yeniden değerlendirme döngüsü yüzünden gecikmeli gelmesi normaldir.

Adım Adım: Sunucu yanıt süresi dalgalanmasının SEO etkisini okuma süreci

Ekibinizde SEO, geliştirme ve operasyon aynı olaya farklı panellerden bakıyorsa aşağıdaki akış en az sürtünmeyle karar vermeyi sağlar.

1. Ölçüm kaynaklarını tek zaman ekseninde toplayın: GSC performans verisi, Crawl Stats, APM, sunucu logları ve Core Web Vitals ölçümlerini aynı tarih aralığında hizalayın. En sık hata, bir ekibin saatlik APM grafiğine bakarken diğer ekibin günlük GSC çıktısını yorumlamasıdır. Aynı eksen kurulmadan neden-sonuç ilişkisi sağlıklı görünmez.
2. Dalgalanma ile kalıcı bozulmayı ayırın: p75, p95, 5xx oranı ve trafik saatlerini birlikte okuyun. Sadece ortalama TTFB’ye bakarsanız anlık pikleri saklarsınız. p95 yükseliyor, 5xx eşlik ediyor ve artış birkaç gün sürüyorsa bu durum organik görünürlük açısından daha kritik kabul edilmelidir.
3. Tarama ve görünürlük kırılımını eşleştirin: Impression, average position, average response time ve host status değişimini aynı olay çevresinde karşılaştırın. Tarama yavaşlayıp görünürlük birkaç gün sonra geriliyorsa altyapı hipotezi güçlenir. Tersine, görünürlük düşüp crawl metrikleri sabit kalıyorsa içerik ya da rekabet boyutunu öne alın.
4. TTFB bileşenlerini katman katman teşhis edin: Redirect, DNS, CDN ve origin gecikmesini ayrı kontrol edin. Bu adım, 600 ms server response time ile 0,8 saniyelik TTFB eşiğini neden farklı okumak gerektiğini de açıklar. Gerçek darboğazı bulmadan yapılan optimizasyonlar genelde yalnız semptomu yumuşatır.
5. İyileştirme sonrası eşikleri sabitleyin: Düzeltmeden sonra yeniden ölçüm yapın ve p95 TTFB, 5xx ve LCP için alarm eşikleri tanımlayın. Amaç yalnız bugünü düzeltmek değil, bir sonraki kampanya veya crawl yoğunluğunda aynı sorunun sessizce geri gelmesini önlemektir.

SEOYEN, Ahrefs ve SEMrush arasında teşhis akışı farkı

Ahrefs ve SEMrush görünürlük, rakip izleme ve araştırma tarafında güçlü araçlardır; ekipler bu platformlarla trend değişimini rahat görür. Ancak sunucu kaynaklı bir anomali yaşandığında asıl sorun çoğu zaman verinin parçalı kalmasıdır. SEO ekibi ayrı panelde pozisyon bakar, teknik ekip ayrı panelde hata arar, karar süresi uzar. SEOYEN burada Türkiye pazarına daha uyarlanmış bir akış sunar: site sağlığı taraması ile performans ve teknik sinyalleri, sıralama takibi ile görünürlük tarafını aynı operasyon mantığında birleştirir.

Bu fark özellikle hızlı teşhiste önemlidir. Ahrefs veya SEMrush size görünürlükteki kırılmayı gösterebilir; SEOYEN bunu Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destekle ekip içinde daha hızlı aksiyona çevirmeyi hedefler. Rakip karşılaştırmasını daha detaylı incelemek isteyenler için Ahrefs farkları ve SEMrush karşılaştırması sayfaları karar çerçevesini netleştirir. Böylece mesele yalnız veri görmek değil, veriyi doğru sırayla yorumlayıp iş akışına çevirmek olur.

Küçük işletme sahipleri ve SEO uzmanları için kritik nokta şudur: sunucu yanıt süresi dalgalandığında en pahalı hata, metrikleri geç okumaktır. Tek platformda sağlık ve görünürlük sinyallerini yan yana görmek bu gecikmeyi azaltır. SEOYEN’in plan yapısını ve canlı kapsamını incelemek isterseniz paket detayları sayfası güncel başvuru noktasıdır. Son kararınız hangi araç olursa olsun, doğru teşhis sırası değişmez: önce dalga mı trend mi, sonra crawl mı UX mi, en son da görünürlük etkisi.

Sıkça Sorulan Sorular