"Sitemi hızlandırdım ama sıralamam değişmedi" cümlesini yıllardır duyuyorum ve genellikle arkasında aynı yanlış anlaşılma yatıyor: site hızı, SEO'da tek başına sıralamayı belirleyen bir kaldıraç değil, belirli bir eşiğin altına düştüğünüzde sizi cezalandıran, üstüne çıktığınızda ise etkisi hızla azalan bir eşik faktörüdür. Yani 8 saniyeden 2 saniyeye inmek gerçekten fark yaratır; 1,4 saniyeden 1,1 saniyeye inmek ise arama sonuçlarında büyük ihtimalle hiçbir şey değiştirmez. Bu ayrımı bilmeden yapılan optimizasyon çalışması, çoğu zaman yanlış yere harcanan zamandır.
Bu yazıda site hızı ile SEO sıralaması arasındaki ilişkiyi mühendislik tarafından ele alacağım: Google'ın gerçekten neyi ölçtüğünü, Core Web Vitals metriklerinin hangi eşiklerde "iyi" sayıldığını, sunucu tarafındaki TTFB'nin neden çoğu ön uç optimizasyonundan daha belirleyici olduğunu, tarama bütçesinin hızla nasıl ilişkilendiğini ve lab verisi ile saha verisi arasındaki farkın neden raporlarınızı yanıltabileceğini anlatacağım. Sonunda da en sık gördüğüm tuzakları toplu halde bulacaksınız.
Hız Bir Sıralama Faktörü mü, Yoksa Efsane mi#
Kısa cevap: evet, sıralama sinyallerinden biridir, ama küçük ağırlıklı bir sinyaldir. Google'ın kendi açıklamalarında tekrar ettiği çerçeve şudur: sayfa deneyimi sinyalleri (hız dahil), içerik kalitesi ve alaka düzeyi eşitken devreye giren bir ayrıştırıcıdır. Yani zayıf içerikli ama çok hızlı bir sayfa, güçlü içerikli ama biraz yavaş bir sayfayı geçmez. Buna karşılık iki sayfa da aynı derecede alakalıysa, hızlı olan öne çıkar.
İkinci ve çoğu kişinin gözden kaçırdığı gerçek şu: hızın asıl etkisi dolaylıdır. Yavaş bir sayfa daha yüksek hemen çıkma oranı, daha kısa oturum süresi, daha az iç sayfa gezinme ve daha düşük dönüşüm üretir. Bu davranışsal sonuçlar zamanla sitenizin genel kalite algısını aşağı çeker. Özellikle mobilde, 3G benzeri bağlantılarda 5 saniyeyi geçen bir yüklemede kullanıcıların ciddi bir bölümü geri tuşuna basar ve arama sonuçlarına döner; bu "pogo-sticking" davranışı sizin sayfanızın o sorgu için iyi bir cevap olmadığına dair güçlü bir sinyaldir. Yani hız SEO'yu doğrudan az, dolaylı olarak çok etkiler.
Core Web Vitals: Ölçtüğünüz Şey Tam Olarak Nedir#
Google'ın hız değerlendirmesini somutlaştırdığı metrik ailesi Core Web Vitals'tır. Üç metrik vardır ve her biri kullanıcı deneyiminin farklı bir anını ölçer: sayfanın ne zaman "yüklenmiş göründüğü", ne zaman "kullanılabilir olduğu" ve yüklenirken "ne kadar zıpladığı". Eşikler şöyledir:
| Metrik | Ne ölçer | İyi | İyileştirme gerekli | Kötü |
|---|---|---|---|---|
| LCP | En büyük içerik öğesinin çizilme anı | 2,5 sn altı | 2,5 - 4,0 sn | 4,0 sn üstü |
| INP | Etkileşime verilen yanıt gecikmesi | 200 ms altı | 200 - 500 ms | 500 ms üstü |
| CLS | Beklenmedik düzen kayması toplamı | 0,1 altı | 0,1 - 0,25 | 0,25 üstü |
Bu tabloda kritik nokta, ölçümün 75. yüzdelik dilim üzerinden yapılmasıdır. Yani ziyaretçilerinizin en yavaş çeyreğini görmezden gelemezsiniz; ortalamanız iyi olsa bile kuyruk kötüyse metrik kötü çıkar. Kendi masaüstünüzde fiber bağlantı ile ölçüm yapıp "sitem 0,9 saniyede açılıyor" demek bu yüzden yanıltıcıdır.
LCP genellikle en kolay iyileştirilen metriktir çünkü sebebi tektir: en büyük görsel ya da başlık bloğu geç geliyordur. Ayrıntılı yöntemler için LCP nasıl iyileştirilir yazısına bakabilirsiniz. CLS ise neredeyse her zaman boyutu belirtilmemiş görseller, sonradan yüklenen reklam alanları veya web fontu değişimi kaynaklıdır; CLS düzen kayması nasıl düzeltilir yazısı bu tarafı ele alıyor.
TTFB: SEO'nun Görünmeyen Yarısı#
Core Web Vitals'ta doğrudan yer almasa da, TTFB (Time To First Byte) bütün zincirin başlangıç noktasıdır. Tarayıcı ilk baytı 900 ms'de aldıysa, LCP'nin 2,5 saniyenin altında kalması için elinizde yalnızca 1,6 saniye kalır ve bu sürede DNS, TLS, HTML ayrıştırma, CSS indirme ve görsel çizme işlerinin hepsini bitirmeniz gerekir. Pratikte TTFB 600 ms'i geçtiğinde ön uç optimizasyonlarının çoğu anlamını kaybeder.
TTFB'yi kendi terminalinizden ölçmek için ek bir araca ihtiyacınız yok:
# Tek bir isteğin zaman dökümü: DNS, TCP, TLS, ilk bayt, toplam
curl -o /dev/null -s -w \
"dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} toplam:%{time_total}\n" \
https://firmaniz.com/
# Örnek çıktı:
# dns:0.021 tcp:0.048 tls:0.112 ttfb:0.734 toplam:0.812
Bu çıktıda tls ile ttfb arasındaki fark, tamamen sunucunuzun HTML'i üretmek için harcadığı süredir. Yukarıdaki örnekte bu değer 622 ms'dir ve neredeyse tamamı PHP + veritabanı tarafındadır. Aynı ölçümü art arda beş kez alıp değişkenliğe bakın; her seferinde farklı bir sonuç geliyorsa büyük ihtimalle paylaşımlı bir sunucuda komşu yükünün etkisindesiniz. Bu konuyu paylaşımlı hostingde hız limitleri yazısında ayrıntılı ele aldım.
TTFB'yi düşürmenin en etkili üç yolu sırasıyla şudur: tam sayfa önbelleği (nginx FastCGI cache ya da LiteSpeed Cache), veritabanı sorgu sayısını azaltmak ve uygulama katmanına nesne önbelleği eklemek. Sunucu tarafı önbellek yapılandırması için nginx FastCGI cache yapılandırma ve LiteSpeed Cache yazıları doğrudan uygulanabilir örnekler içeriyor.
Tarama Bütçesi ve Hız İlişkisi#
Büyük sitelerde hızın en somut SEO etkisi tarama bütçesinde görülür. Googlebot her siteye sınırsız istek göndermez; sunucunuzun yanıt süresine ve hata oranına bakarak kendini otomatik olarak yavaşlatır. Sunucunuz 200 ms'de cevap veriyorsa bot saniyede birkaç sayfa çekebilir; 2 saniyede cevap veriyorsa aynı zaman diliminde onda biri kadar sayfa tarar. On binlerce ürün sayfası olan bir e-ticaret sitesinde bu, yeni ürünlerin dizine girme süresinin günlerden haftalara çıkması demektir.
Sunucu günlüklerinizden Googlebot'un gerçekten ne kadar beklediğini ölçebilirsiniz. Nginx erişim günlüğüne yanıt süresini eklemediyseniz önce onu ekleyin:
# Yanıt süresini ve upstream süresini günlüğe ekle
log_format zamanli '$remote_addr - $status $request_time $upstream_response_time "$request" "$http_user_agent"';
server {
access_log /var/log/nginx/firmaniz.access.log zamanli;
}
Ardından sadece bot isteklerinin ortalama süresini çıkarın:
# Googlebot isteklerinin ortalama yanıt süresi (saniye)
grep -i googlebot /var/log/nginx/firmaniz.access.log \
| awk '{ toplam += $4; adet++ } END { print "ortalama:", toplam/adet, "s / istek:", adet }'
Bu değerin 500 ms'in altında olması hedeftir. Üstündeyse, önce önbelleklenebilir sayfaların gerçekten önbellekten dönüp dönmediğine bakın; çoğu sitede bot istekleri çerezsiz geldiği için önbellek isabet oranı yüksek olmalıdır ama yanlış bir Vary ya da Cache-Control: private başlığı bunu tamamen bozar.
Lab Verisi ile Saha Verisi Arasındaki Fark#
Raporlarınızın birbirini tutmamasının en yaygın sebebi bu ikisini karıştırmanızdır. Lab verisi (Lighthouse, GTmetrix, WebPageTest) tek bir makineden, sabit bir ağ koşulunda, tek seferlik yapılan sentetik bir ölçümdür. Saha verisi (Chrome UX Report, Search Console'daki Core Web Vitals raporu) gerçek kullanıcılarınızın tarayıcılarından toplanan 28 günlük yuvarlanan bir veri setidir. Google sıralama tarafında saha verisine bakar.
| Özellik | Lab verisi | Saha verisi |
|---|---|---|
| Kaynak | Sentetik test makinesi | Gerçek ziyaretçi tarayıcıları |
| Örneklem | Tek istek | 28 günlük toplam, 75. yüzdelik |
| Sıralamaya etkisi | Yok (dolaylı teşhis aracı) | Doğrudan sayfa deneyimi sinyali |
| Ne zaman kullanılır | Sorunu bulmak, değişikliği test etmek | Gerçek durumu görmek, hedef belirlemek |
| Güncellenme | Anında | Haftalar sürer |
Bu yüzden bir iyileştirme yaptıktan sonra Search Console'da hemen değişiklik beklemeyin; 28 günlük pencere dolana kadar metrikler karışık veri gösterir. Lab tarafında hızlı geri bildirim almak için ölçümü tekrarlanabilir tutun: aynı sayfayı, aynı bağlantı profiliyle, en az üç kez ölçüp medyanı alın. GTmetrix ile WordPress hız testi yazısında bu ölçüm disiplinini adım adım anlattım.
Hangi İyileştirme Ne Kadar Kazandırır#
Sınırlı zamanınız varsa sıralamayı şöyle kurun. Aşağıdaki tablo, onlarca sitede tekrarlanan tipik kazanç aralıklarını özetliyor; sizin sitenizde rakamlar değişir ama sıralama nadiren değişir.
| İyileştirme | Tipik LCP kazancı | Zorluk | Kalıcılık |
|---|---|---|---|
| Tam sayfa önbelleği açmak | 400 - 1500 ms | Düşük | Yüksek |
| Görselleri WebP/AVIF'e çevirmek | 200 - 900 ms | Düşük | Yüksek |
| Hero görseline preload vermek | 150 - 600 ms | Düşük | Orta |
| Kullanılmayan eklentileri kaldırmak | 100 - 800 ms | Orta | Yüksek |
| Daha hızlı diske/sunucuya geçmek | 100 - 700 ms | Orta | Yüksek |
| CDN eklemek (yurt dışı trafik) | 100 - 600 ms | Orta | Yüksek |
| CSS/JS küçültme ve birleştirme | 30 - 150 ms | Orta | Düşük |
Dikkat edin: listenin en altındaki iş, çoğu ajansın ilk yaptığı iştir. Küçültme ve birleştirme kâğıt üzerinde iyi görünür, Lighthouse puanını birkaç sayı yükseltir ama gerçek kullanıcı deneyiminde ölçülebilir bir fark yaratmaz. Önbellek ve görsel işleri ise neredeyse her zaman kazandırır.
Sık Yapılan Hatalar#
Lighthouse puanını hedef sanmak. 100/100 bir puan, saha verisinde kötü LCP ile bir arada bulunabilir. Puan bir teşhis özetidir, hedef değildir. Hedefiniz, gerçek kullanıcıların 75. yüzdelik diliminde LCP'yi 2,5 saniyenin altında tutmaktır.
Ana sayfayı optimize edip bırakmak. Organik trafiğinizin çoğu ana sayfaya değil, iç sayfalara gelir. Ürün, kategori ve blog şablonlarını ayrı ayrı ölçün; genellikle en yavaş şablon, en çok trafik alan şablondur.
Mobil ölçümü atlamak. Google mobil öncelikli dizine alma yapıyor. Masaüstünde 1,2 saniyede açılan sayfa, orta seviye bir Android telefonda 4 saniyeyi bulabilir çünkü JavaScript ayrıştırma ve çalıştırma maliyeti CPU'ya bağlıdır ve mobil CPU'lar çok daha yavaştır.
Önbelleği açıp doğrulamamak. Eklentiyi kurup "önbellek aktif" yazısını görmek yetmez. Yanıt başlığına bakın; x-cache: HIT benzeri bir başlık ya da LiteSpeed'de x-litespeed-cache: hit yoksa önbellek çalışmıyordur.
# Önbellek başlıklarını doğrula
curl -sI https://firmaniz.com/ | grep -iE 'cache|age|x-cache|expires'
Aynı anda beş şey değiştirmek. Hangi değişikliğin ne kazandırdığını bilemezsiniz ve bir regresyon olduğunda geri alacağınız şeyi bulamazsınız. Tek tek uygulayın, her adımdan sonra ölçün.
Sıkça Sorulan Sorular#
Site hızı gerçekten sıralamayı etkiliyor mu#
Evet, ama beklediğiniz kadar büyük bir doğrudan etkiyle değil. Hız, sayfa deneyimi sinyalleri arasında yer alır ve içerik kalitesi ile alaka düzeyi benzer olan sayfalar arasında ayrıştırıcı görevi görür. Asıl büyük etkisi dolaylıdır: yavaş sayfa daha fazla terk edilir, daha az dönüşüm yapar ve zamanla sitenizin genel performansını aşağı çeker.
Kaç saniyede açılan bir site yeterince hızlı sayılır#
Hedefinizi tek bir "yükleme süresi" yerine Core Web Vitals eşikleri üzerinden kurun. Gerçek kullanıcılarınızın yüzde 75'inde LCP 2,5 saniyenin altında, INP 200 milisaniyenin altında ve CLS 0,1'in altında olmalı. Sunucu tarafında ise TTFB'nin 600 milisaniyenin altında kalması pratikte iyi bir eşiktir.
Hız iyileştirmesi yaptıktan ne kadar sonra sıralamam değişir#
Saha verisi 28 günlük yuvarlanan bir pencere üzerinden hesaplandığı için Search Console'daki Core Web Vitals raporunuz tam olarak yansımayı yaklaşık dört haftada tamamlar. Sıralama etkisini görmek ise genellikle daha uzun sürer, çünkü Google'ın sayfalarınızı yeniden değerlendirmesi ve tarama döngüsünün tamamlanması gerekir. Sabırlı olun ve bu sürede başka büyük değişiklikler yapmayın.
PageSpeed Insights puanım 100 ama sitem yavaş, neden#
Çünkü PageSpeed Insights'ın üst kısmındaki puan sentetik bir lab ölçümüdür; belirli bir cihaz ve ağ profilinde, tek seferlik yapılır. Sayfanın alt kısmındaki "Gerçek Kullanıcı Deneyimi" bölümü ise sizin ziyaretçilerinizin gerçek verisidir ve Google'ın baktığı yer orasıdır. İkisi çeliştiğinde her zaman saha verisine güvenin.
Mobil hız mı yoksa masaüstü hızı mı daha önemli#
Google mobil öncelikli dizine alma kullandığı için değerlendirme mobil sürüm üzerinden yapılır. Ayrıca Türkiye'de çoğu sitede organik trafiğin büyük bölümü mobilden gelir. Bu yüzden optimizasyon önceliğiniz her zaman mobil olmalı; masaüstü genellikle mobil düzeldiğinde kendiliğinden iyileşir.
CDN kullanmak SEO sıralamama yardımcı olur mu#
CDN doğrudan bir sıralama faktörü değildir, ama coğrafi olarak uzaktaki ziyaretçilerin gecikmesini düşürerek LCP ve TTFB metriklerini iyileştirir; bu metrikler de sayfa deneyimi sinyaline girer. Trafiğinizin tamamı Türkiye'den geliyorsa ve sunucunuz da Türkiye'deyse kazanç sınırlı kalır. Karşılaştırma için CDN mi daha iyi hosting mi yazısına bakın.
Hızlandırma eklentisi kurmak yeterli olur mu#
Bir önbellek eklentisi genellikle en büyük tek kazancı sağlar, ama yeterli değildir. Eklentinin gerçekten önbellek döndürdüğünü yanıt başlıklarından doğrulamanız, görselleri modern formata çevirmeniz ve gereksiz eklentileri kaldırmanız gerekir. Ayrıca sunucunuzun kaynakları yetersizse hiçbir eklenti bunu telafi edemez.
Kapanış#
Site hızı ile SEO arasındaki ilişkiyi doğru kurmanın yolu, hızı bir puan yarışı olarak değil bir eşik problemi olarak görmekten geçiyor. Aklınızda kalması gereken dört alışkanlık şu: ölçümü her zaman saha verisi üzerinden yapın, önce TTFB'yi düşürün çünkü zincirin başlangıcı orasıdır, en çok trafik alan şablonu optimize edin ve her değişikliği tek tek uygulayıp sonucunu doğrulayın. Bu dört şeyi yapan bir site, Lighthouse puanını hiç umursamadan da rakiplerinin önüne geçer.
Sunucu tarafı gecikmesi çoğu sitede en büyük kalemdir ve donanım değiştirmeden çözülmesi bir yere kadar mümkündür. NVMe diskli ve modern işlemcili altyapı arıyorsanız web hosting ve WordPress hosting paketlerimiz tam sayfa önbelleğiyle birlikte gelir; daha fazla kaynak ve tam kontrol istiyorsanız VDS tarafına geçebilirsiniz. Teknik SEO ve hız çalışmasını bize bırakmak isterseniz SEO hizmetimiz ölçüm ve iyileştirme döngüsünü sizin yerinize yürütür, mevcut sitenizi taşımak isterseniz site taşıma ekibimiz geçişi kesintisiz yapar.