Yüzlerce Sayfası Olan Sitelerde TTFB ve Crawl Bütçesi İlişkisi

Googlebot TTFB'yi nasıl ölçer ve crawl hızını nasıl belirler?

Googlebot, her istek gönderdiğinde sunucunun ilk byte'ı gönderene kadar geçen süreyi kaydeder. Bu ölçüm, botun kendi ağ gecikmesini de içerdiğinden gerçek TTFB değerinizden biraz farklı olabilir. Ancak sunucunuz tutarlı biçimde 800 ms ile 2 saniye arasında yanıt veriyorsa, botun kendi kayıtlarında da benzer ölçümler üretir ve bu bilgi crawl hızı hesabına girer.

Google, crawl hızını iki bileşenle belirler: crawl rate limit ve crawl demand. Crawl rate limit, sunucunun kaldırabileceği yük üst sınırını temsil eder. Crawl demand ise indeksleme ihtiyacına göre değişen taleptir: yeni içerik, gelen bağlantılar, sitemap güncellemeleri bu talebi artırır. Yanıt süreleri birinci bileşene, yani rate limit'e girer. Sunucu tutarlı biçimde yavaş yanıt verdiğinde bot, oturum başına istek sayısını kendiliğinden düşürür. Bir cezalandırma mekanizması değildir bu; sunucu kaynaklarını korumak için otomatik geri çekilmedir.

Küçük sitelerde bu kısıt neredeyse fark edilmez. Googlebot birkaç günde tüm içeriği tarar, TTFB 1,5 saniye olsa da sonuç değişmez. Ölçek büyüdükçe tablo değişir. 200+ sayfalık sitede crawl demand yüksek olabilir, yani Googlebot siteyi taramak ister; ama rate limit bunu kısıtlıyorsa talep karşılanamaz ve yeni sayfalar sıraya bekler. Darboğaz, talep ile hız sınırı arasındaki bu açıktadır.

Google Search Console'daki crawl hızı ayarını da gözden geçirin. Elle düşürülmüş bir hız limiti varsa, TTFB iyileştirmenizin etkisini tamamen maskeleyebilir. Ayarı "otomatik" konumuna almak, botun sunucu davranışına göre kendini kalibre etmesine izin verir.

GSC Crawl Stats raporunda yavaş yanıt süresinin izleri

Google Search Console'da Settings bölümündeki Crawl Stats raporunu açtığınızda üç ana grafik görürsünüz: toplam tarama istekleri, indirilen veri miktarı ve ortalama yanıt süresi. Üçü ayrı ayrı incelendiğinde anlam taşısa da, asıl değer birlikte okunduğunda ortaya çıkar.

Tipik bir sorun senaryosu şöyle görünür: ortalama yanıt süresi birkaç günlük bir dönemde 350 ms'den 1,4 saniyeye çıkar, ardından 5-7 gün içinde tarama istekleri sayısı belirgin biçimde düşer. İki grafik arasındaki bu gecikme önemlidir; bot yanıt süresindeki artışı anlık değil, birkaç günlük örüntü olarak değerlendirir. Süre normale döndükten sonra hızın yeniden artması daha da uzun sürebilir.

Yanıt süresi grafiğinde ani yükselişleri incelerken şu soruyu sorun: o tarihte sunucuda ne değişti? Yeni bir eklenti kurulumu, veritabanı yedeklemesinin çalışma saati, ani trafik artışı ya da hosting planı değişikliği, bunların hepsi bu izde görünebilir. Grafik sizi olaya değil, etkiye götürür; nedeni log dosyalarında aramanız gerekir.

Raporun alt bölümündeki yanıt kodu dağılımına da bakın. 5xx hatalarının artması veya 404 oranının yükselmesi ayrı bir crawl bütçesi sızıntısı yaratır; bot hata sayfalarını tarayarak hem zaman hem de bütçe harcar. Yüksek TTFB ile birleşen hata oranı, indexlenebilir sayfa başına düşen etkili crawl kapasitesini ciddi ölçüde daraltır.

Son olarak, "Host" seçicisini kullanarak farklı subdomain'ler veya protokoller arasındaki farkı kontrol edin. HTTP ile HTTPS arasında, www ile non-www arasında farklı yanıt süreleri görüyorsanız yönlendirme zinciri veya SSL yapılandırmasında bir sorun olabilir; bu da her yönlendirmenin ek gecikme eklemesiyle sonuçlanır.

Log dosyalarında Googlebot oturumlarını okumak

Sunucu log dosyaları, GSC Crawl Stats'ın göstermediği ayrıntıyı verir: hangi URL'nin kaç milisaniyede yanıt verdiği. Nginx access log'larında standart format genellikle şu şekilde yapılandırılır:

$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time

Son alan olan $request_time, saniye cinsinden tam işlem süresini verir. Apache'de benzer bilgi %T (tam saniye) veya mikrosaniye için %D değişkeniyle elde edilir. Log formatınızda bu alan yoksa, önce onu etkinleştirip birkaç gün veri biriktirmeniz gerekecektir.

Googlebot isteklerini ayıklamak ve yavaş URL'leri sıralamak için şu komut işe yarar:

grep "Googlebot" access.log | awk '{print $NF, $7}' | sort -rn | head -50

Sonuçta 2 saniyenin üzerinde yanıt veren URL'lerin belirli bir template veya URL yapısına ait olduğunu görürseniz, sorunu izole etmişsinizdir. Tüm yavaş URL'ler aynı category sayfasına ya da aynı sıralama parametresine aitsse, iyileştirme hedefini çok daha net tanımlayabilirsiniz.

Oturum analizi ise URL bazlı analizden farklı bir görüntü sağlar. Googlebot'un IP aralıklarını kullanarak istekleri oturumlara gruplandırdığınızda, her oturumda yapılan istek sayısı ve oturumlar arasındaki bekleme süresi görünür hale gelir. Yanıt süresi yüksek dönemlerde oturum başına istek sayısının düştüğünü ve oturumlar arası aralığın uzadığını görmek, crawl bütçesi kısıtlamasının doğrudan kanıtıdır. GSC grafiğindeki düşüşe log verisiyle neden-sonuç bağlamak, gerçekten doğru problemi çözdüğünüzü teyit eder.

Log analizi için sunucunuza doğrudan erişiminiz yoksa, hosting panelinizin sunduğu ham log indirme seçeneğini kullanın. Bazı yönetilen hosting sağlayıcıları günlük log arşivi sunar; aylık toplu indirme yerine günlük veriyle çalışmak, anomalileri daha net görmenizi sağlar.

Hangi URL grupları crawl bütçesini en fazla harcar?

200+ sayfalık bir sitede crawl bütçesi sorunu iki kaynaktan beslenir: sunucu performansı ve URL enflasyonu. Yüksek TTFB her iki durumda da etkisini katlayarak gösterir; yavaş sayfaların sayısı arttıkça kümülatif maliyet büyür.

URL enflasyonu yaratan yaygın kaynaklar şunlardır: arama filtresi veya sıralama parametresi taşıyan URL'ler, uzun sayfalama zincirleri, dahili arama sonuç sayfaları, session ID içeren URL'ler ve canonicalization sorunundan kaynaklanan yinelenen içerik varyasyonları. Bir içerik sitesinde tag sayfalarının her kombinasyonu ayrı URL oluşturuyorsa, Googlebot teorik olarak yüzlerce düşük değerli sayfayı tarar. Bunların TTFB'si çoğunlukla statik içerik sayfalarından daha yüksektir; veritabanı sorgusu gerektirdikleri için hem "değersiz" hem de "yavaş" sayfalar crawl bütçesinin ciddi bir bölümünü tüketir.

Asıl indexlenmesini istediğiniz sayfalar bu rekabette kaybedebilir. Log dosyasında Googlebot'un son 30 gün içinde URL bazında yaptığı ziyaretleri incelediğinizde, kategori veya ürün sayfalarınızın aldığı ziyaret sayısıyla parametreli URL'lerin aldığını karşılaştırın. Değerli sayfaların oranı düşükse, URL enflasyonu problemi bir değil iki boyutludur: hem bütçeyi hem de bütçenin içindeki TTFB maliyetini artırıyordur.

Robots.txt ile parametreli URL'leri tarama dışına almak veya <link rel="canonical"> etiketlerini doğru yapılandırmak, crawl bütçesini daha verimli kullandırır. Ancak bu adımları atmadan önce log analizinde ilgili URL'lerin gerçekten taranıp taranmadığını doğrulayın. Gözlemlenmeyen bir probleme verilen kör bir Disallow kuralı, indexlenmiş değerli sayfaları da etkileyebilir.

TTFB iyileştirmesinin crawl frekansına yansıması

TTFB'yi düşürdüğünüzde crawl hızının hemen artmasını beklemeyin. Googlebot, sunucu davranışını tekrar değerlendirmek için tutarlı bir geçmiş arar ve bu geçmişi birkaç günde kuramaz.

Ortalama TTFB 800 ms'nin altına indiğinde, GSC Crawl Stats grafiğinde tarama isteklerinin artması genellikle 1-3 hafta alır. Bu süreyi kısaltmanın doğrudan bir yolu yoktur. Sunucu yanıt geçmişi bir yere kaydedilir ve güven yeniden inşa etmek tutarlı performans ister. Yükseltme yaptıktan hemen sonra "neden fark göremiyorum?" sorusu bu gecikmeye dayanır.

İyileştirmenin etkisini ölçmek için iki veriyi yan yana takip edin: log dosyalarındaki haftalık Googlebot istek sayısı ve GSC Crawl Stats'taki ortalama yanıt süresi. Yanıt süresi grafiği düştükten yaklaşık 2 hafta sonra istek sayısı grafiğinin yükselmeye başlaması, nedensellik ilişkisini destekler. Bu takibi en az 6 hafta sürdürün; mevsimsel trafik dalgalanmaları ve içerik güncellemeleri veriye gürültü katar.

Yavaş artış sizi yanıltmasın. Crawl hızı iyileşince yeni yayımlanan sayfalar daha kısa sürede indexe girer; bu fark, GSC'deki Pages raporu ve Coverage bölümündeki "Discovered - currently not indexed" listesinde de görünür. Liste kısalıyorsa, crawl bütçesi açığı kapanıyor demektir.

TTFB kaynaklarını önceliklendirmek: neyi önce çözmeli?

TTFB tek bir sayıdır ama arkasında farklı nedenler yatar. Crawl bütçesi açısından önceliklendirme yapmak için kaynakları ayrıştırmak gerekir; her kaynak, farklı URL gruplarını farklı ölçülerde etkiler.

Veritabanı sorgu süresi, çoğu dinamik sitede TTFB'nin en büyük bileşenidir. Index'siz sütunlar üzerinde çalışan sorgular, büyük tablolarda tam tarama (full scan) yapar ve yanıt süresini ciddi biçimde uzatır. Slow query log'unu etkinleştirerek 200 ms'nin üzerindeki sorguları listelemek ve bu sorguların hangi URL template'lerine ait olduğunu tespit etmek, doğrudan bir iyileştirme noktası sağlar. Özellikle filtreleme, sıralama veya sayfalama işlemlerine katkıda bulunan sorgular, hem en yavaş hem de en çok tarama yapılan URL'lerle örtüşür.

Uygulama çalıştırma süresi ikinci kaynaktır. Eklenti tabanlı CMS'lerde her sayfa yükünde tetiklenen gereksiz hook'lar veya başlangıçta yüklenen büyük kütüphaneler bu süreyi artırır. Hangi fonksiyonların en uzun çalıştığını bir profiling aracıyla görmek, neyi çıkarabileceğinizi netleştirir. Bazen tek bir eklentinin devre dışı bırakılması, tüm URL grupları için TTFB'yi 300-500 ms düşürür.

Üçüncü kaynak dış servis çağrılarıdır. Sayfa oluşturulurken yapılan senkron API istekleri, o servisin yanıt süresini doğrudan TTFB'ye ekler. Googlebot bir sayfayı yüklerken üçüncü taraf bir API 600 ms gecikirse, bot da 600 ms fazladan bekler. Dış çağrıları asenkron hale getirmek veya sonuçlarını cache'lemek bu etkiyi ortadan kaldırır.

Cache başarısız kalması ise ayrı bir kategoridir. Bir sayfa her yüklenişinde sıfırdan oluşturuluyorsa, tüm ziyaretçiler için yüksek TTFB demektir. Tam sayfa cache'i devreye almak, TTFB'yi genellikle en hızlı ve en belirgin şekilde düşüren müdahaledir. Ancak cache yapılandırmasının Googlebot isteklerine de uygulandığını doğrulamak gerekir; bazı kurulumlar cookie varlığına göre cache kararı alır ve bot cookie taşımadığı için farklı bir işleme düşebilir.