Site Hızı SEO'yu Nasıl Etkiler? Hızlı Sitenin Sıralama ve Satış Avantajları

Site hızı, müşterilerimle yaptığım SEO görüşmelerinde en çok yanlış anlaşılan konulardan biri. Kimi hızı her şeyin anahtarı sanıyor, kimi de "içerik iyiyse hız önemsiz" diyor. İki görüş de eksik. Bu yazıda Google'ın hızı hangi ölçütlerle değerlendirdiğini, sıralamadaki gerçek ağırlığını ve asıl kazancın neden satış tarafında olduğunu resmi belgelere dayanarak anlatıyorum.

Site hızı SEO'yu nasıl etkiler?

Site hızı, sayfanın ne kadar çabuk yüklendiğini, tıklamalara ne kadar hızlı yanıt verdiğini ve yüklenirken ne kadar sabit kaldığını anlatan bir kullanıcı deneyimi özelliğidir. Google bunu Core Web Vitals ölçütleriyle değerlendirir ve sıralama sistemlerinde kullanır. Ancak etkisi sınırlıdır: alaka ve içerik kalitesi her zaman önce gelir.

Yani hızlı bir site, zayıf bir içeriği birinci sıraya taşımaz. Buna karşılık benzer kalitede iki sayfa aynı sorguda yarışıyorsa, deneyimi daha iyi olan sayfa öne geçebilir. Bu yüzden hızı bir sıralama kaldıracı olarak değil, bir hijyen kuralı olarak görüyorum. Üstelik hızın asıl getirisi çoğu zaman sıralamada değil, ziyaretçinin formu doldurup doldurmamasında ortaya çıkıyor.

Google site hızını hangi ölçütlerle değerlendirir?

Google, hızı tek bir "yükleme süresi" rakamıyla ölçmez. Bunun yerine üç ölçütten oluşan Core Web Vitals setine bakar. Her biri kullanıcı deneyiminin farklı bir anını temsil eder:

• LCP (Largest Contentful Paint): Sayfadaki en büyük görünür öğenin, çoğu zaman ana görselin veya başlığın, ekrana gelme süresi. Kullanıcının "sayfa açıldı" hissini ölçer.
• INP (Interaction to Next Paint): Kullanıcı bir düğmeye bastığında veya menüyü açtığında ekranın ne kadar sürede tepki verdiği. Sayfanın ne kadar "akıcı" hissettirdiğini ölçer.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken öğelerin beklenmedik şekilde kayma miktarı. Yanlış yere tıklatan o sinir bozucu kaymaları ölçer.

Dikkat ederseniz CLS aslında bir hız ölçütü değil, görsel kararlılık ölçütü. Yine de kullanıcı bunu "site yavaş ve dağınık" diye algılıyor. Bu nedenle ben müşterilerime site hızını üç parçalı bir deneyim olarak anlatıyorum: açılış, tepki ve düzen. Ayrıca INP, Mart 2024'te FID'in yerini aldı; dolayısıyla eski raporlarda gördüğünüz FID değerleri artık güncel değerlendirmeyi yansıtmıyor.

Core Web Vitals eşikleri kaç olmalı?

Google Search Central'daki Core Web Vitals belgesi hedefleri net veriyor: LCP ilk 2,5 saniye içinde gerçekleşmeli, INP 200 milisaniyenin altında, CLS ise 0,1'in altında kalmalı. web.dev'deki Web Vitals açıklaması ise "zayıf" sınırlarını ve ölçüm yöntemini tamamlıyor. Aşağıdaki tablo bu değerleri tek yerde topluyor:

Burada kritik ayrıntı şu: eşikleri ortalamaya göre değil, gerçek kullanıcı yüklemelerinin 75. yüzdelik dilimine göre değerlendirirsiniz. Yani ziyaretlerinizin en az dörtte üçü eşiğin içinde kalmalı. Üstelik mobil ve masaüstü ayrı ayrı ölçülür; masaüstünde yeşil olan bir sayfa mobilde kırmızı kalabilir.

Eşikleri geçip geçmediğinizi hangi veri gösterir?

Google'ın sıralamada dikkate aldığı veri, sizin bilgisayarınızda çalıştırdığınız testin sonucu değildir. Belirleyici olan, Chrome kullanıcılarından toplanan gerçek kullanım verisidir. Bu veriye saha verisi, test ortamında üretilen skorlara ise laboratuvar verisi diyoruz. Laboratuvar skoru sorunu bulmanıza yarar; saha verisi ise kullanıcının gerçekte ne yaşadığını gösterir.

Pratikte ilk bakacağınız yer Search Console'daki Core Web Vitals raporudur. Rapor benzer sayfaları gruplar ve her grubu en kötü ölçütüne göre "iyi", "iyileştirme gerekli" veya "zayıf" olarak işaretler. Küçük sitelerde bazı sayfaların yeterli verisi olmayabilir; bu durumda rapor boş kalır ya da yalnızca birkaç grup gösterir.

Testi nasıl çalıştıracağınızı ve raporu nasıl okuyacağınızı Google Lighthouse ile site performans testi rehberinde adım adım anlattım. Burada tekrar etmiyorum. Bu yazıda asıl sorumuz şu: bu ölçütler sıralamada ve satışta ne kadar fark yaratıyor?

Site hızı sıralamada gerçekte ne kadar ağırlık taşır?

Dürüst cevap: sınırlı ama sıfır değil. Google'ın sayfa deneyimi belgesi Core Web Vitals'ın sıralama sistemlerinde kullanıldığını açıkça yazıyor. Aynı belge, tek bir "sayfa deneyimi sinyali" olmadığını da belirtiyor. Sıralama sistemleri deneyimle uyumlu birçok sinyale birlikte bakıyor.

Belgenin en önemli cümlesi bence şu: Google Arama, sayfa deneyimi vasat olsa bile her zaman en alakalı içeriği göstermeye çalışır. Yani alaka, hızın önündedir. Google, iyi sayfa deneyiminin ancak yararlı içeriğe sahip birden fazla sayfa aynı sorgu için yarıştığında başarıya katkı sağlayabileceğini söylüyor.

Kısacası site hızı bir eşitlik bozucu gibi çalışıyor. İçeriğiniz rakibinizle aynı seviyedeyse hız size avantaj sağlayabilir. İçeriğiniz belirgin şekilde zayıfsa, en hızlı altyapı bile bu açığı kapatmaz. Sahada gördüğüm tablo da bununla uyumlu: yalnızca hız çalışmasıyla büyük sıralama sıçraması yaşayan bir site görmedim; bu bir saha gözlemi, kural değil.

Hızlı bir site neden tek başına birinci sıraya çıkmaz?

Çünkü Google'ın ilk işi soruyu en iyi cevaplayan sayfayı bulmaktır. Hız bu cevabın kalitesini değiştirmez, sadece cevaba ulaşma deneyimini iyileştirir. Örneğin "en iyi ortopedik yatak" araması yapan birine, bir saniyede açılan boş bir kategori sayfası, üç saniyede açılan kapsamlı bir karşılaştırmadan daha az işe yarar.

Müşteri projelerinde en sık karşılaştığım hata da burada başlıyor. İşletme sahibi Lighthouse skorunu 60'tan 95'e çıkarmak için haftalar harcıyor, ama sayfanın arama niyetine uymadığını fark etmiyor. Sonuçta skor yükseliyor, sıralama yerinde sayıyor. Bu yüzden bir hız projesine başlamadan önce şu sırayı öneriyorum:

1. Sayfa, hedeflediği aramanın niyetine gerçekten cevap veriyor mu?
2. İçerik, sıralamadaki rakiplerle aynı derinlikte mi?
3. Teknik olarak taranabilir ve dizine eklenebilir durumda mı?
4. Bunlar tamamsa, Core Web Vitals değerleri eşiğin içinde mi?

Bu sıra, bütçenizi en çok getiri sağlayan işe yönlendirir. Öte yandan dördüncü maddedeki sorunlar ağırsa, yani sayfa mobilde altı saniyede açılıyorsa, sırayı değiştirip hızı öne alırsınız. Çünkü o noktada hız artık bir ayrıntı değil, kullanıcıyı sayfaya hiç ulaştırmayan bir engeldir.

Site hızı hangi durumlarda sıralama farkı yaratır?

Deneyimime göre hızın sıralamada hissedilir fark yarattığı üç tipik durum var. Birincisi rekabetin sıkı olduğu, ilk sayfadaki sonuçların içerik olarak birbirine çok benzediği sorgulardır. Örneğin yerel hizmet aramalarında veya ürün kategorilerinde içerikler çoğu zaman aynı bilgiyi verir; bu durumda deneyim sinyalleri daha görünür hâle gelir.

İkincisi, değerleri "zayıf" bölgesinde olan sitelerdir. 2,6 saniyelik bir LCP'yi 2,3'e indirmek küçük bir fark yaratır. Buna karşılık 7 saniyelik bir LCP'yi 2,5'in altına çekmek, hem kullanıcı hem de Google açısından bambaşka bir sayfa demektir. Üçüncüsü ise binlerce sayfası olan büyük sitelerdir; burada hız, taramayı da etkiler.

Dolayısıyla "hız sıralamayı etkiler mi" sorusunun cevabı sitenin nerede durduğuna bağlıdır. Zaten eşiğin içindeyseniz, milisaniye kovalamak yerine içeriğe yatırım yapmanızı öneririm. Eşiğin çok dışındaysanız, hız çalışması ilk sıradaki işiniz olmalı.

Yavaş sunucu Google'ın taramasını nasıl etkiler?

Hızın sıralamaya en az konuşulan etkisi tarama tarafındadır. Google'ın tarama bütçesi belgesine göre site istikrarlı yanıt veriyor ve yanıt süreleri sabit kalıyor ya da iyileşiyorsa, tarama kapasitesi sınırı yükselir. Site yavaşlarsa ya da sunucu hataları dönerse, sınır düşer ve Google daha az tarar.

Bu durum küçük bir kurumsal site için pek önemli değildir; birkaç düzine sayfayı Google zaten rahatça tarar. Ancak binlerce ürünü olan bir e-ticaret sitesinde veya sürekli yeni içerik yayımlayan bir yayıncıda tablo değişir. Yavaş sunucu, yeni ürünlerin ve güncellenen fiyatların arama sonuçlarına geç yansıması anlamına gelir.

Bu yüzden büyük sitelerde hız çalışmasına sadece Core Web Vitals açısından değil, sunucu yanıt süresi açısından da bakıyorum. Teknik altyapının bu yönünü yapay zeka sonrası teknik SEO yazısında daha geniş ele aldım. Özetle, sunucunuz ne kadar hızlı yanıt verirse Google o kadar rahat tarar.

Yavaş site kullanıcı davranışı üzerinden SEO'ya nasıl yansır?

Burada dikkatli olmak gerekiyor, çünkü internette çok abartılı iddialar dolaşıyor. Google, Analytics'teki hemen çıkma oranınızı doğrudan sıralama sinyali olarak kullandığını söylemiyor. Bu nedenle "hemen çıkma yüksek, Google cezalandırır" gibi cümlelere mesafeli yaklaşmanızı öneririm.

Yine de dolaylı bir bağ var. Yavaş açılan sayfa, kullanıcının geri dönüp başka bir sonuca tıklama ihtimalini artırır. Sayfanızı okumayan kullanıcı sizi paylaşmaz, bağlantı vermez, markanızı hatırlamaz ve bir daha aramaz. Böylece hız sorunu, zamanla sitenizin kazanabileceği doğal sinyallerin önünü keser.

Ziyaretçiyi sayfada tutmanın hız dışındaki yollarını hemen çıkma oranını düşürme rehberinde anlattım. Orada da vurguladığım gibi, sorun çoğu zaman tek bir sebepten değil, hız, içerik ve tasarımın birlikte yarattığı sürtünmeden kaynaklanır.

Site hızı satışı ve dönüşümü nasıl etkiler?

Hızın asıl getirisini burada görüyorsunuz. Google'ın desteklediği ve Deloitte'un yürüttüğü "Milliseconds Make Millions" çalışması, 37 markanın mobil sitelerindeki 30 milyonu aşkın kullanıcı oturumunu inceledi. Çalışmaya göre mobil site hızındaki 0,1 saniyelik iyileşme, perakende sitelerde dönüşümü yüzde 8,4, ortalama sipariş değerini ise yüzde 9,2 artırdı.

Aynı çalışmada seyahat sitelerinde dönüşüm artışı yüzde 10,1 oldu. Ayrıca ürün listeleme sayfasından ürün detay sayfasına geçişte yüzde 3,2'lik, ürün detayından sepete eklemeye geçişte ise yüzde 9,1'lik artış ölçüldü. Bu rakamlar sayfanın ilk açılışından çok, kullanıcının sitede ilerlediği adımların hızlanmasıyla ilgili.

Ancak bu rakamları kendi siteniz için bir vaat gibi okumayın. Bunlar belirli sektörlerde, belirli markaların ortalamalarıdır. Sizin sitenizde etki daha küçük veya daha büyük olabilir. Benim bu çalışmadan çıkardığım ders şu: hız, satın alma yolculuğunun her adımında küçük sürtünmeleri azaltıyor ve bu küçük kazanımlar birikiyor.

Vodafone'un A/B testi hız hakkında ne gösteriyor?

Hız ile satış arasındaki ilişkiyi kanıtlamanın en temiz yolu kontrollü bir testtir. web.dev'de yayımlanan Vodafone vaka çalışması tam olarak bunu yapıyor. Vodafone İtalya, trafiği görsel ve işlevsel olarak aynı iki sayfa arasında eşit böldü. Tek fark, bir sürümün Web Vitals için optimize edilmiş olmasıydı.

Sonuçta LCP'deki yüzde 31'lik iyileşme, yüzde 8 daha fazla satış getirdi. Bunun yanında potansiyel müşteri oranında yüzde 15, sepet oranında ise yüzde 11 artış görüldü. Ekip bu kazancı kritik HTML'i sunucu tarafında oluşturarak, görselleri küçültüp sıkıştırarak ve bazı bileşenleri sunucu tarafına taşıyarak elde etti.

Bu testi önemli bulmamın sebebi şu: tasarım, metin ve teklif aynı kaldı. Değişen tek şey hızdı. Dolayısıyla buradaki satış artışını başka bir değişikliğe bağlamak zor. Kendi projelerinizde de mümkünse hız iyileştirmesini tasarım değişikliğiyle aynı anda yayına almayın; aksi hâlde hangi etkinin nereden geldiğini ayırt edemezsiniz.

Hız iyileştirmesinin getirisini nasıl hesaplarsınız?

Hız projesine bütçe ayırmadan önce kaba bir getiri hesabı yapmanızı öneririm. Aşağıdaki rakamlar tamamen örnek hesaptır, gerçek bir müşteriye ait değildir. Diyelim ki e-ticaret siteniz ayda 40.000 oturum alıyor, dönüşüm oranınız yüzde 1,5 ve ortalama sepetiniz 1.200 TL.

Bu durumda aylık cironuz yaklaşık 720.000 TL olur. Hız çalışması sonrasında dönüşüm oranınız yüzde 1,5'ten yüzde 1,6'ya çıkarsa, yani yüzde 7 civarında göreli artış olursa, aynı trafikle aylık ciro yaklaşık 768.000 TL'ye ulaşır. Aradaki 48.000 TL, projenin kaç ayda kendini ödeyeceğini gösterir.

Bu hesabı yaparken iyimser rakamlar yerine temkinli bir artış varsayın. Ayrıca kazancı tek seferlik değil, aylık tekrarlayan bir getiri olarak düşünün. Çünkü hızlanan bir site, reklam bütçenizin, SEO emeğinizin ve sosyal medya trafiğinizin tamamından daha fazla verim alır. Kısacası hız, diğer kanalların çarpanıdır.

Hangi sayfalarda site hızı daha çok para kazandırır?

Her sayfanın hızı aynı değerde değildir. Bu yüzden ben hız çalışmasını sitenin tamamına eşit dağıtmak yerine, parayı getiren sayfalardan başlatıyorum. Genellikle öncelik sırası şöyle oluyor:

• Reklam açılış sayfaları: Her tıklamaya para ödüyorsunuz; yavaş sayfa bu parayı doğrudan boşa harcar.
• Ürün ve hizmet detay sayfaları: Satın alma kararı burada verilir.
• Sepet ve ödeme adımları: En sıcak kullanıcıyı burada kaybetmek en pahalı kayıptır.
• Organik trafiğin en çok girdiği sayfalar: Search Console'da en çok tıklama alan sayfalar.
• Kategori ve listeleme sayfaları: Kullanıcının ürüne ulaştığı ara adım.

Örneğin kurumsal bir sitede blog yazılarını 1,8 saniyeden 1,2 saniyeye indirmek güzel bir teknik başarıdır. Fakat teklif formunun bulunduğu hizmet sayfası 5 saniyede açılıyorsa, önce o sayfayı düzeltmeniz gerekir. Kısacası öncelik listenizi Lighthouse skoruna göre değil, gelir katkısına göre kurun.

Reklam trafiğinde site hızı neden ayrıca önemlidir?

Organik trafikte yavaş bir sayfa size fırsat kaybettirir. Reklam trafiğinde ise doğrudan para kaybettirir. Çünkü Google Ads'te tıklamanın bedelini, kullanıcı sayfanızı görse de görmese de ödersiniz. Sayfa açılmadan geri dönen her kullanıcı, harcanmış bir bütçe kalemidir.

Üstelik reklam trafiği genellikle mobil ağırlıklıdır ve kullanıcı zaten bir karar anındadır. Yavaş bir açılış sayfası, tam bu anda rakibinizin reklamına dönme ihtimalini artırır. Bu nedenle Google Ads yönetimi yaptığım hesaplarda açılış sayfasının mobil hızını kampanya kurulumunun bir parçası olarak kontrol ediyorum.

Pratik bir öneri: reklam için özel açılış sayfası kullanıyorsanız, bu sayfalara sitenin geri kalanındaki ağır betikleri, sohbet eklentilerini ve kaydırıcıları taşımayın. Sade tutulan bir açılış sayfası hem hızlı açılır hem de kullanıcıyı tek bir eyleme odaklar. Böylece aynı bütçeyle daha fazla potansiyel müşteri toplarsınız.

Siteyi yavaşlatan iş kararları nelerdir?

Hız sorunlarının çoğu kötü koddan değil, zamanla biriken iş kararlarından doğar. Her ekip kendi aracını ekler, kimse eskisini kaldırmaz. Sahada en sık karşılaştığım yavaşlatıcılar şunlar:

1. Birden fazla analiz ve piksel betiği; çoğu zaman artık kullanılmayan eski etiketler de sayfada kalır.
2. Canlı sohbet, açılır pencere ve kampanya eklentileri; her biri ayrı bir üçüncü taraf yükü getirir.
3. Ana sayfanın üst kısmında otomatik oynayan kaydırıcı veya büyük video.
4. Telefonla çekilip küçültülmeden yüklenen, birkaç megabaytlık ürün görselleri.
5. Kullanılmayan özellikleriyle birlikte yüklenen hazır temalar ve sayfa oluşturucular.
6. Ucuz ama aşırı kalabalık paylaşımlı sunucu.

Bu listenin iyi tarafı şu: çoğu madde teknik bilgi gerektirmeden karar verilebilecek konulardır. Örneğin görselleri yüklemeden önce resim küçültme aracıyla boyutlandırmak, geliştirici beklemeden yapabileceğiniz bir iyileştirmedir. Video kullanıyorsanız, hız etkisini azaltmanın yollarını web sitesinde video kullanımı yazısında anlattım.

Sunucu ve altyapı seçimi site hızını nasıl belirler?

Sayfanın ilk baytı sunucudan çıkmadan hiçbir optimizasyon işe başlayamaz. Bu yüzden altyapı, site hızının temelidir. Ucuz paylaşımlı barındırma paketlerinde aynı sunucuyu yüzlerce site paylaşır; komşu sitelerden biri yoğunlaştığında sizin sayfanız da yavaşlar. Üstelik bu yavaşlık düzensiz olduğu için laboratuvar testinde görünmeyebilir, ama saha verisinde ortaya çıkar.

Altyapı kararında ben üç soruya bakıyorum. İlk olarak sunucu, ziyaretçilerinizin çoğunluğuna coğrafi olarak yakın mı? Türkiye'deki müşterilere hizmet veren bir sitenin sunucusu çok uzak bir veri merkezindeyse, her istekte gereksiz bir gecikme oluşur. İkinci olarak sayfa önbelleği ve sıkıştırma gibi temel ayarlar açık mı? Son olarak statik dosyalar, yani görseller, stil ve betik dosyaları bir içerik dağıtım ağı üzerinden sunuluyor mu?

Bu soruların cevabı çoğu zaman aylık birkaç yüz liralık fark yaratan bir paket seçimine dayanır. Oysa bu fark, yukarıda anlattığım dönüşüm kaybının yanında küçük kalır. Dolayısıyla barındırmayı bir maliyet kalemi olarak değil, satış altyapısının parçası olarak değerlendirmenizi öneririm.

Mobil site hızı neden ayrı değerlendirilmelidir?

Google, siteleri dizine eklerken ve sıralarken mobil sürümü esas alır. Buna ek olarak Core Web Vitals değerleri mobil ve masaüstü için ayrı ayrı ölçülür. Dolayısıyla masaüstünde hızlı açılan bir site, mobilde eşiğin çok dışında kalabilir ve siz bunu masaüstünden bakarak fark etmezsiniz.

Mobil kullanıcıların cihazları genellikle daha zayıf işlemcilere sahiptir ve bağlantıları daha değişkendir. Bu yüzden özellikle INP sorunları mobilde çok daha belirgin çıkar. Masaüstünde anında açılan bir menü, orta segment bir telefonda yarım saniye gecikebilir.

Mobil öncelikli yaklaşımı ve bunun sıralamaya etkisini mobil öncelikli tasarım yazısında ayrıntılı anlattım. Buradaki pratik önerim şu: site hızı raporlarınızda her zaman önce mobil değerlere bakın. Çünkü ziyaretçilerinizin büyük kısmı büyük ihtimalle oradan geliyor ve Google da siteyi o gözle değerlendiriyor.

Hız için tasarımdan vazgeçmek zorunda mısınız?

Hayır, ama bazı tercihleri yeniden düşünmeniz gerekir. Güzel bir tasarım ile hızlı bir site birbirinin rakibi değildir. Sorun, tasarımın ağır teknik çözümlerle hayata geçirilmesidir. Örneğin aynı etkiyi yüzlerce kilobaytlık bir animasyon kütüphanesiyle de, birkaç satır CSS ile de yaratabilirsiniz.

Web tasarım projelerinde ben hızı işin sonunda değil, başında konuşuyorum. Tasarım aşamasında her büyük görsel, her video ve her animasyon için "bu öğe kullanıcıya ne kazandırıyor?" sorusunu soruyorum. Cevabı zayıf olan öğeleri ya sadeleştiriyor ya da ekranın alt kısmına, geç yüklenecek şekilde taşıyoruz.

Tasarım ile SEO arasındaki diğer gerilimleri UX ve SEO dengesi yazısında ele aldım. Google'ın sayfa deneyiminde önemsediği diğer unsurları, yani HTTPS ve rahatsız edici ara reklamları ise SEO ve UX uyumu yazısında bulabilirsiniz. Böylece hızı, genel kullanıcı deneyiminin bir parçası olarak ele alırsınız.

Site hızı hakkındaki en yaygın yanılgılar nelerdir?

Müşteri görüşmelerinde tekrar tekrar karşılaştığım yanılgıları topladım. Her birinin arkasında gerçek bir yanlış yatırım hikâyesi var:

• "Lighthouse skoru 100 olmalı." Google sıralamada Lighthouse skorunu değil, gerçek kullanıcı verisini dikkate alır. Skor bir teşhis aracıdır, hedef değildir.
• "Hız her şeydir." Google'ın kendi belgesine göre alaka her zaman önce gelir. Hız, eşit içerikler arasında fark yaratır.
• "Eşiği geçtik, iş bitti." Her yeni eklenti, kampanya ve görsel hızı yeniden bozabilir. Hız sürekli bakım isteyen bir konudur.
• "Önbellek eklentisi her şeyi çözer." Önbellek sunucu tarafını hızlandırır, ama ağır görselleri ve üçüncü taraf betikleri düzeltmez.
• "Masaüstünde hızlıysa sorun yok." Değerlendirme mobil ve masaüstü için ayrıdır; mobil çoğu zaman daha kötüdür.

Bu yanılgıların ortak noktası, hızı bir sayı olarak görmek. Oysa hız, kullanıcının yaşadığı bir deneyimdir. Bu nedenle ölçerken de karar verirken de o deneyimi merkeze almanızı öneririm.

Site hızı çalışmasını kime ve nasıl yaptırmalısınız?

Hız çalışması teknik bir iştir, ama kararların çoğu işletme tarafında verilir. Bu nedenle çalışmayı yalnızca geliştiriciye bırakmak yerine, SEO ve pazarlama tarafının da masada olmasını öneririm. Aksi hâlde geliştirici skoru yükseltmek için satışa katkı sağlayan bir öğeyi kaldırabilir.

Bir ajansla veya serbest geliştiriciyle çalışırken şu soruları sormanızı öneririm: Hangi ölçütü, hangi sayfa grubunda, hangi değerden hangi değere çekmeyi hedefliyorsunuz? Başarıyı laboratuvar skoruyla mı, saha verisiyle mi ölçeceksiniz? Hangi eklentiler ve betikler kaldırılacak, bunun pazarlama tarafına etkisi ne olacak?

Net cevap alamıyorsanız, çalışmanın sonunda elinizde yalnızca daha yüksek bir skor kalabilir. SEO danışmanlığı süreçlerinde ben hız hedeflerini her zaman trafik ve dönüşüm hedefleriyle birlikte yazıyorum. E-ticaret sitelerinde ise bu hedefleri e-ticaret danışmanlığı kapsamında sepet ve ödeme adımlarıyla ilişkilendiriyorum.

Hız kazanımını zamanla nasıl korursunuz?

Hız çalışmasının en zor kısmı, iyileştirmeyi yapmak değil, onu korumaktır. Birkaç ay sonra yeni bir kampanya eklentisi, yeni bir piksel veya büyük bir ana sayfa görseli kazanımın önemli kısmını geri alabilir. Bu yüzden ben müşterilerime basit bir "performans bütçesi" kuruyorum.

Performans bütçesi, sayfanın aşmaması gereken sınırları tanımlar: en fazla kaç üçüncü taraf betik, ana görsel için en fazla kaç kilobayt, hedef LCP değeri gibi. Yeni bir öğe eklemek isteyen ekip, önce bu bütçeye bakar. Böylece hız, tek seferlik bir proje olmaktan çıkar ve günlük kararların bir parçası hâline gelir.

Ayrıca Search Console'daki Core Web Vitals raporunu ayda bir kontrol etmenizi öneririm. Saha verisi son 28 günün toplamını yansıttığı için, yaptığınız değişikliğin etkisini görmeniz birkaç hafta sürebilir. Dolayısıyla bir iyileştirmeden sonra sonucu hemen ertesi gün değil, en az bir ay sonra değerlendirin.

Sonuç: site hızı sıralamada destek, satışta kaldıraç mı?

Bence tam olarak öyle. Site hızı, Google'ın sıralama sistemlerinde kullandığı gerçek ama sınırlı bir sinyaldir. İçeriğiniz rakiplerle aynı seviyedeyse size avantaj sağlar; içeriğiniz zayıfsa bu açığı kapatmaz. Buna karşılık satış tarafında etkisi çok daha doğrudandır, çünkü her saniye kullanıcının karar sürecine dokunur.

Özetle önerim şu: önce Search Console'da gerçek kullanıcı verinize bakın. Zayıf bölgedeyseniz hızı öncelikli iş yapın ve para getiren sayfalardan başlayın. Eşiğin içindeyseniz, milisaniye kovalamak yerine enerjinizi içeriğe ve dönüşüm deneyimine verin. Son olarak kazanımı bir performans bütçesiyle koruyun; böylece hız, hem Google'ın hem de müşterinizin gözünde kalıcı bir artıya dönüşür.