Sunucu Yanıt Süresi Dalgalanması: SEO Etkisi ve Teşhis

Sunucu yanıt süresi dalgalanması neden SEO sorunudur?

Sunucu yanıt süresi, isteğin sunucuya ulaştığı andan ilk anlamlı yanıtın üretilmesine kadar geçen süreyi anlatır. TTFB ise istemcinin ilk baytı ne zaman aldığına bakar; bu yüzden yalnızca uygulama süresi değildir. MDN’nin TTFB tanımına göre bu ölçüm DNS, TCP ve TLS kurulumunu da kapsayabilir. Yani ping, RTT, TTFB ve origin işlem süresi aynı şey değildir; birbirine karıştırıldığında teşhis yanlış başlar.

SEO tarafında sorun, sadece “site yavaş” hissi değildir. Dalgalı yanıt süresi, botun aynı host üzerinde kısa sürede daha az URL işlemesine neden olabilir; bu da tarama verimliliğini düşürür. İkinci etki, yeni veya güncellenmiş sayfaların keşfedilse bile daha geç işlenmesiyle indeksleme hızında hissedilir. Üçüncü etki ise kullanıcı tarafındadır: TTFB geciktiğinde LCP’ye giden zincir de gecikir, fakat bu durum Core Web Vitals ile birebir aynı değildir; daha çok CWV sonucunu etkileyen üst katmanlı bir sebeptir.

Chrome for Developers dokümanında ana doküman isteği için 600 ms üzeri bekleme, Lighthouse denetiminde problem sinyali olarak işaretlenir. web.dev’in 2025 sonunda güncellenen TTFB rehberi ise çoğu sitenin p75 seviyesinde yaklaşık 0,8 saniye ve altını hedeflemesini önerir. Bu iki referansı birlikte okuyunca şu netleşir: tek bir kötü skor değil, sürekli oynayan gecikme daha kritik sinyaldir. Kavramları hızlıca ayırmak isterseniz SEO terimleri sözlüğü bu ayrımı ekip içinde standartlaştırmak için iyi bir başlangıçtır.

Dalgalanma ağda mı, cache’te mi, uygulamada mı başlar?

İlk iş, dalgalanmayı katmanlara ayırmaktır. Aynı URL bazen 250 ms, bazen 1,4 saniye TTFB veriyorsa bunun tek bir açıklaması yoktur. Ağ yolundaki değişim, CDN edge davranışı, origin yükü veya veritabanı beklemesi aynı dış semptomu üretir. Doğru teşhis için isteğin yolculuğunu istemciden origin’e kadar parçalara ayırmak gerekir.

Ağ katmanı

RTT artışı, paket kaybı, rota değişimi, DNS çözümleme gecikmesi, TLS el sıkışması ve yönlendirme zincirleri çoğu zaman uygulama hatası sanılır. Oysa özellikle farklı ülke veya şehirlerden yapılan testlerde, origin iyi durumda olsa bile ağ yolu uzadığı için TTFB şişebilir. Bu yüzden tek lokasyondan bakmak yanıltıcıdır; İstanbul’da normal görünen istek, Frankfurt veya Londra’da sorunlu görünebilir.

CDN ve cache katmanı

Google Cloud Documentation, cache hit ratio metriğini bir nesnenin ne sıklıkla doğrudan cache’den servis edildiğini gösteren oran olarak tanımlar. Hit oranı düşünce origin daha çok çağrılır, cold cache veya yanlış cache key kullanımı nedeniyle TTFB oynar. Özellikle kampanya sayfaları, filtreli URL’ler ve kısa TTL kullanılan dinamik içerikler aynı gün içinde hit-miss salınımı üretebilir. Kullanıcı “sunucu yavaşladı” der, ama kök neden çoğu kez önbellek politikasıdır.

Uygulama ve veri katmanı

CPU kuyruğu, render süresi, cold start, kilitlenen worker süreçleri, yavaş veritabanı sorguları ve harici API beklemeleri origin süresini artırır. Microsoft Learn, sorgu timeout vakalarında en yaygın nedenin sorgunun beklenen süreden uzun çalışması olduğunu açıkça söylüyor. Bu katmanda dalgalanma genelde belirli saatlerde artar: deploy sonrası cache ısınmadan önce, cron işleri çalışırken, kampanya trafiği yükselirken veya üçüncü taraf bir servis geç cevap verirken.

Sunucu yanıt süresi dalgalanması nasıl ölçülür ve doğrulanır?

Tek bir Lighthouse raporu, sorunun varlığına işaret eder; kök nedeni vermez. Sentetik test size kontrollü koşullarda ölçüm verir. CrUX ve RUM gerçek kullanıcı deneyiminin sahadaki karşılığını gösterir. En iyi yaklaşım, ana URL için birkaç sentetik tekrar çalıştırmak, ardından saha verisinde p75 eğilimini ve saat bazlı sapmayı doğrulamaktır. Böylece “laboratuvarda kötü ama kullanıcıda normal” ya da tam tersi senaryoları ayırabilirsiniz.

2026 itibarıyla yorum farkı yaratan iki teknik nüans var. Chrome for Developers’ın 2025 tarihli Lighthouse 13 notlarına göre eski server-response-time denetimi, Document request latency içgörüsüne taşındı; yani artık belge isteği zincirini daha bütüncül okumak gerekiyor. MDN de 103 Early Hints kullanan sitelerde TTFB’nin ara 103 yanıtını kapsayabileceğini, final yanıtı görmek isteyenlerin uygun yerde finalResponseHeadersStart ölçümüne bakması gerektiğini not ediyor. Bu nedenle farklı araçlar arasında küçük TTFB farkları görmek normaldir.

Katman bazlı teşhis için Server-Timing başlığı, APM kayıtları, CDN logları ve yavaş sorgu logları aynı zaman eksenine yerleştirilmelidir. web.dev örneğinde Server-Timing: auth;dur=55.5, db;dur=220 gibi ayrımların doğrudan görülebildiği anlatılıyor; bu, SEO ekibinin “sorun frontend’de mi yoksa origin’de mi” sorusunu hızla yanıtlar. Bu ayrımı tek ekranda toplamak için SEOYEN’in Sayfa Hızı Testi aracı, TTFB ile LCP sapmasını birlikte okumada pratik bir çerçeve sunar.

7 günlük saha günlüğü: üç lokasyonda aynı URL neden farklı davrandı?

Pratikte en yararlı günlük, aynı URL’yi İstanbul, Frankfurt ve Londra’dan 5 dakikada bir izleyip p50, p75 ve p95 dağılımını karşılaştıran günlük olur. Örnek bir okumada İstanbul p50 260 ms, p75 410 ms, p95 910 ms; Frankfurt p50 320 ms, p75 560 ms, p95 1,2 s; Londra p50 340 ms, p75 590 ms, p95 1,3 s verebilir. Burada tek seferlik en yüksek değer değil, yüzde dilimlerinin birlikte kayması önemlidir. p50 sabit kalıp yalnız p95 sıçrıyorsa sorun çoğu zaman anlık spike’tır.

Aynı günlükte cache hit oranı spike saatlerinde düşüyorsa, origin’e daha çok istek gitmeye başladığını anlarsınız. Eğer RTT de eş zamanlı artıyorsa ağ yolu ve edge-origin mesafesi şüphelenilir. Buna karşılık RTT sabit kalırken Server-Timing içindeki db veya app süresi yükseliyorsa problem hosting paketinden çok uygulama kodu, sorgu planı veya harici servis beklemesidir. Yani üç lokasyonda farklı davranış görmek tek başına “CDN şart” demek değildir; hangi katmanın oynadığını kanıtlamak gerekir.

Yanlış pozitifleri de ayıklamak gerekir. Deploy sonrası ilk dakikalarda cold cache, botların yoğun tarama pencereleri, ani kampanya trafiği veya raporlama işlerinin aynı saate denk gelmesi p95’i yukarı çekebilir. Bu yüzden günlükte sadece süre değil, cache hit/miss, yönlendirme sayısı, yanıt kodu, Server-Timing kırılımı ve trafik notu da tutulmalıdır. Teknik SEO ekipleri için fark yaratan nokta budur: dalgayı görmek yetmez, dalganın hangi olayla eşleştiğini görmek gerekir.

Düzeltme sırası: CDN, sorgu optimizasyonu veya sunucu yükseltmesi

Düzeltme sırası, en pahalı adımdan değil en güçlü kanıttan başlamalıdır. Yüksek RTT ve coğrafi fark baskınsa ağ yolu, DNS, yönlendirme zinciri ve CDN konfigürasyonu önce gelir. RTT normal ama origin süresi dalgalıysa uygulama mantığı, worker kuyruğu ve veritabanı sorguları öne çıkar. Cache hit oranı düşükse önce önbellek anahtarı, TTL, varyasyon kuralları ve edge davranışı incelenmelidir; doğrudan sunucu yükseltmek çoğu zaman pahalı ama etkisiz bir ilk adımdır.

• Redirect chain temizleyin; gereksiz yönlendirme her isteğe ek gecikme bindirir.
• Cache TTL ve cache key kurallarını gözden geçirin; gereksiz varyasyon hit oranını düşürür.
• Sorgu indekslerini ve yavaş sorgu planlarını inceleyin; uzun çalışan sorgu TTFB’yi doğrudan şişirir.
• Harici API timeout bütçelerini sıkılaştırın; üçüncü taraf beklemesi ana dokümanı rehin almamalı.
• Kuyruk ve worker doygunluğunu izleyin; ani trafik altında süreç birikmesi dalgalanmayı büyütür.

Google Cloud Documentation, cache hit ratio’yu kısa ve uzun zaman aralıklarında izlemenin mümkün olduğunu belirtiyor; bu metrik düzeltme sonrası gerçekten iyileşme olup olmadığını görmek için kritik. Microsoft Learn ise query timeout teşhisinde önce yavaş sorguyu tanımlamayı, sonra uygulama ile veritabanı tarafındaki farkı izlemeyi öneriyor. Kısacası karar matrisi şudur: RTT yüksekse ağ/CDN, origin süresi yüksekse uygulama/veritabanı, hit oranı oynuyorsa cache stratejisi önce gelir.

SEOYEN ile dalgalanmayı izleyip teknik SEO kararını hızlandırma

Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer gibi araçlar SEO ekiplerinin farklı ihtiyaçlarına cevap verir; ancak performans sapmasını Türkçe iş akışta yorumlamak çoğu ekip için ayrı bir operasyon yükü oluşturur. SEOYEN’in farkı burada netleşir: tek platformda SEO araçları, Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek sayesinde teknik ekip, performans sinyalini rapor değil karar formatında okuyabilir. Bu, özellikle küçük işletmeler ve saha odaklı SEO uzmanları için önemlidir.

Pratik akışta önce Sayfa Hızı Testi ile TTFB, LCP ve tekrar eden performans sapmaları izlenir; ardından site sağlığı denetimi ile yönlendirme, taranabilirlik ve teknik hataların etkisi birlikte değerlendirilir. Böylece “sunucu mu yavaş, sayfa mı ağır, yoksa her ikisi de mi” sorusu daha hızlı yanıtlanır. Paket detayını metin içinde sabitlemek yerine güncel seçenekleri SEOYEN fiyatları sayfasından kontrol etmek daha doğru olur.

Adım Adım: Sunucu yanıt süresi dalgalanmasını ölçme ve düzeltme

Aşağıdaki akış, teknik SEO tarafında gereksiz tahmini azaltır ve ekip içi öncelik sırasını netleştirir. Amaç tek bir skor yakalamak değil, dalgalanmanın hangi katmanda başladığını kanıtlayıp aynı senaryoda yeniden ölçmektir.

1. Ana URL için baz sentetik ölçüm al: Aynı URL’yi aynı cihaz profili ve aynı ağ emülasyonuyla birkaç kez çalıştırın. Tek bir sonuç yerine en az üç tekrar alın ki ilk gözlemde yönlendirme, TLS veya anlık yük kaynaklı sapmaları fark edebilin.
2. CrUX ve RUM ile dalgayı doğrula: Laboratuvarda gördüğünüz gecikme sahada gerçekten yaşanıyor mu, önce bunu netleştirin. Gerçek kullanıcı verisi kötü değilse sorun yalnız belirli bölge, cihaz veya test koşulu olabilir.
3. Server-Timing ile katman sürelerini ayır: Uygulama, veritabanı, kimlik doğrulama ve harici servis sürelerini başlıklara veya APM ekranına bölün. TTFB yükselirken hangi alt bileşenin yükseldiğini görmeden kök neden çıkarmayın.
4. Cache ve CDN davranışını eşleştir: Aynı zaman aralığında cache hit ratio, edge lokasyonu, cache miss ve origin istek hacmine bakın. Hit oranı düşüyorsa performans sorunu çoğu kez origin kapasitesi değil cache politikasıdır.
5. Spike saatlerinde kök nedeni sınıfla: Deploy, cron, bot trafiği, kampanya veya üçüncü taraf API gecikmesi gibi olayları ölçüm saatleriyle eşleyin. Süre artışını olay defteriyle bağlamadan yapılan optimizasyonlar rastgele kalır.
6. Önceliğe göre düzelt ve yeniden ölç: Önce düşük maliyetli ve yüksek kanıtlı müdahaleleri uygulayın. Redirect zinciri, cache TTL, sorgu planı ve timeout bütçesi gibi değişikliklerden sonra aynı test senaryosunu tekrar ederek gerçek kazanımı doğrulayın.

Sıkça Sorulan Sorular