Site Hızı ve SEO: Core Web Vitals Rehberi (2026)

Core Web Vitals (Önemli Web Verileri), Google'ın bir sayfanın gerçek kullanıcılara ne kadar hızlı ve stabil hissettirdiğini ölçtüğü üç metrikten oluşur: LCP yüklenme hızını, INP etkileşim tepkisini, CLS ise görsel kaymayı ölçer. Bu üç metrik Google'ın sıralama sinyalleri arasında yer alır; yani yavaş bir site hem arama sonuçlarında rakiplerinin gerisine düşer hem de zar zor kazandığı ziyaretçiyi daha sayfa açılmadan kaybeder. İyi haber şu: eşik değerleri bellidir (LCP 2,5 saniyenin, INP 200 milisaniyenin, CLS 0,1'in altında olmalı) ve sorunların büyük kısmı görsel optimizasyonu, script azaltma ve doğru önbellekleme gibi bilinen adımlarla çözülür.

Search Console'da "Zayıf" ya da "İyileştirilmeli" uyarısı gördüyseniz veya siteniz artık size bile yavaş geliyorsa doğru yerdesiniz. Bu rehberde üç metriği teknik jargona boğulmadan açıklayacak, neyin neyi bozduğunu tek tek gösterecek ve geliştirici olmasanız bile bugün uygulamaya başlayabileceğiniz bir öncelik listesi vereceğiz.

Site hızı SEO'yu gerçekten etkiliyor mu?

Kısa cevap: evet, ama mekanizma çoğu kişinin sandığından farklı işler. Google, Core Web Vitals'ı resmî bir sıralama sinyali olarak kullanır; ancak bu sinyal, içerik kalitesi ve alaka düzeyi gibi ana faktörlerin önüne geçmez. Dünyanın en hızlı sitesine sahip olmak, zayıf içerikle ilk sayfaya çıkmanızı sağlamaz. Hızın asıl gücü iki yerde ortaya çıkar: benzer kalitedeki içerikler yarışırken teraziyi sizden yana eğmesi ve kullanıcı davranışını doğrudan şekillendirmesi.

İkinci etki, çoğu işletme için birincisinden çok daha değerlidir. Yavaş açılan bir sayfada ziyaretçi beklemez; geri tuşuna basıp arama sonuçlarına döner ve büyük ihtimalle rakibinize tıklar. Sektörel kabul gören eğilim nettir: mobilde yüklenme süresi uzadıkça hemen çıkma oranı hızla tırmanır, sepete ekleme ve form doldurma oranları düşer. Yani hız yalnızca bir SEO konusu değil, aynı zamanda doğrudan bir dönüşüm konusudur; bu tarafın taktiklerini dönüşüm oranı artırma rehberimizde ayrıntılı işlemiştik.

İşin bir de reklam boyutu var: yavaş bir açılış sayfası Google Ads tarafında kalite puanını aşağı çeker ve aynı tıklama için daha fazla ödemenize neden olur. Üstelik tarama tarafında da etkisi vardır; yavaş yanıt veren siteleri Googlebot daha az verimli tarar, yeni içeriklerin ve ürün sayfalarının keşfi gecikebilir. Kısacası hız yatırımı tek kaleme değil; organik görünürlük, reklam verimi ve dönüşüm olmak üzere üç kaleme birden yazılır.

Yönettiğimiz e-ticaret hesaplarında en sık karşılaştığımız tablo şudur: reklam bütçesi büyütülür, trafik artar ama satış yerinde sayar. İlk baktığımız yerlerden biri her zaman mobil LCP değeridir; çünkü Türkiye'de trafiğin büyük kısmı mobilden gelir ve mobil şebeke koşullarında masaüstünde hiç hissedilmeyen 1-2 saniyelik fark, satın alma yolculuğunda uçuruma dönüşür.

Üç metrik sade dille: LCP, INP ve CLS

Google'ın ölçtüğü üç metrik, aslında ziyaretçinizin üç basit sorusuna karşılık gelir: "Sayfa geldi mi?" (LCP), "Tıkladım, tepki veriyor mu?" (INP) ve "Ekran neden zıplıyor?" (CLS). Her metrik için üç bant vardır: İyi, İyileştirilmeli ve Zayıf. Hedefiniz, ziyaretçilerinizin en az dörtte üçü için "İyi" bandında kalmaktır.

LCP: Sayfa ne zaman "geldi" hissi veriyor?

LCP, ekranda görünen en büyük öğenin — çoğu sitede bir kapak görseli, ürün fotoğrafı veya büyük başlık — yüklenmesinin ne kadar sürdüğünü ölçer. Ziyaretçinin "tamam, sayfa açıldı" dediği an budur. LCP'yi en çok bozanlar:

• Optimize edilmemiş dev görseller: Telefonla çekilip olduğu gibi yüklenen birkaç megabaytlık kapak fotoğrafı, tek başına LCP'yi katlayabilir.
• Yavaş sunucu yanıtı: Sayfanın ilk baytı geç geliyorsa — ucuz paylaşımlı hosting'lerin klasik sorunu — geri kalan her şey de gecikir.
• Render'ı engelleyen CSS ve JavaScript: Tarayıcı, sayfayı çizmeden önce büyük stil ve script dosyalarını beklemek zorunda kalır.
• Kapak görseline yanlışlıkla lazy loading uygulamak: Ekranın en üstündeki görsele "sonra yükle" demek, LCP'yi bilerek geciktirmekle aynı şeydir ve şaşırtıcı derecede yaygın bir hatadır.

Çözüm tarafında ilaç bellidir: görselleri WebP veya AVIF formatına çevirip gerçek görüntülenme boyutunda sunmak, kapak görselini öncelikli yüklemek, iyi bir hosting ve CDN kullanmak, kritik olmayan scriptleri ertelemek.

INP: Tıklayınca ne oluyor?

INP, ziyaretçinin sayfadaki tüm tıklama, dokunma ve klavye etkileşimlerine sitenin ne kadar hızlı tepki verdiğini ölçer. 2024'te eski FID metriğinin yerini aldı ve ondan çok daha zorlu bir ölçüt; çünkü yalnızca ilk etkileşimi değil, oturum boyunca yaşanan en yavaş tepkilerden birini esas alır. "Sepete ekle" butonuna bastınız ve buton yarım saniye donuk kaldı — işte o his INP'dir.

INP'nin baş düşmanı ağır JavaScript yüküdür. Tarayıcının ana iş parçacığı meşgulken tıklamanız sıraya girer ve site "donmuş" hisseder. Pratikte bu yükü şişiren şeyler:

• Üçüncü taraf script yığını: Canlı destek, ısı haritası, KVKK çerez bandı, pazarlama pikselleri, eski kampanya araçları... Her biri tek başına masum görünür; toplamı siteyi kilitler.
• Kullanılmayan eklenti ve uygulamalar: Bir kez denenip unutulan her uygulama, kodunu her sayfada yüklemeye devam eder.
• Verimsiz tema kodu: Özellikle "her özellik içinde" diye satılan çok amaçlı temalar, kullanmadığınız özelliklerin scriptini de her ziyaretçiye taşır.

İyileştirmenin yolu eklemekten değil çıkarmaktan geçer: sitenizde hangi scriptlerin yüklendiğini görün, işinize yaramayanlarla vedalaşın, vazgeçemediklerinizi ise sayfa yüklendikten sonra çalışacak şekilde erteleyin. Danışanlarımızda INP sorunlarının önemli bir kısmı tek satır kod yazılmadan, yalnızca script temizliğiyle çözülüyor.

CLS: Tam tıklayacakken kayan buton

CLS, sayfa yüklenirken öğelerin ne kadar yer değiştirdiğini ölçer. Klasik senaryo: ürün sayfasında "Satın al" butonuna uzandınız, tam o anda üstten bir kampanya şeridi yüklendi, sayfa aşağı kaydı ve bambaşka bir yere tıkladınız. Hem sinir bozucu hem de ölçülebilir bir hata. CLS'yi bozan başlıca etkenler ve çözümleri:

• Boyutu belirtilmemiş görseller: Tarayıcı görselin kaplayacağı alanı bilmezse, görsel gelince içeriği iter. Çözüm: her görsele genişlik-yükseklik bilgisi tanımlamak.
• Sonradan yüklenen banner ve duyuru çubukları: İçeriğin üstüne sonradan giren her öğe kaymadır. Çözüm: bu alanlara baştan sabit yer ayırmak.
• Web fontu değişimi: Yazı önce sistem fontuyla görünüp sonra özel fonta dönünce satırlar kayar. Çözüm: font yüklemesini doğru yapılandırmak ve özel fonta yakın ölçülerde bir yedek font seçmek.

Laboratuvar verisi ve gerçek kullanıcı verisi: hangisine bakacaksınız?

Hız konusunda en çok kafa karıştıran nokta, ortada iki farklı veri türünün olmasıdır. Laboratuvar verisi (Lighthouse testi gibi), sayfanızı standart bir cihaz ve bağlantı simülasyonuyla o an ölçer; tekrarlanabilir olduğu için sorun ayıklamada idealdir, ama gerçek ziyaretçinizin deneyimi değildir. Gerçek kullanıcı verisi (CrUX — Chrome Kullanıcı Deneyimi Raporu) ise sitenizi gerçekten ziyaret eden Chrome kullanıcılarından toplanan son 28 günlük ölçümlerdir.

Kritik ayrıntı şu: Google sıralamada gerçek kullanıcı verisini kullanır. Bu yüzden "PageSpeed puanım 90 ama Search Console hâlâ Zayıf diyor" çelişkisi aslında çelişki değildir: sizin ofis bilgisayarınızda ve simülasyonda hızlı görünen site, ziyaretçilerinizin orta segment telefonlarında ve değişken mobil şebekede yavaş olabilir. Ölçüm araçlarının nasıl çalıştığını, puanların nasıl yorumlanacağını ve hangi aracın ne zaman kullanılacağını PageSpeed Insights rehberimizde araç odaklı anlattık; bu yazıda ise metriklerin kendisine ve SEO etkisine odaklanıyoruz.

Pratik kural: teşhis için laboratuvar, karar için saha. Neyi düzelteceğinizi laboratuvar testleriyle bulun; düzelip düzelmediğine gerçek kullanıcı verisiyle karar verin.

Search Console Core Web Vitals raporu nasıl okunur?

Search Console'daki Core Web Vitals raporu, sitenizin gerçek kullanıcı verisini mobil ve masaüstü için ayrı ayrı gösterir; URL'leri İyi, İyileştirilmeli ve Zayıf olarak sınıflar. Raporu okurken üç şeyi bilmek işinizi çok kolaylaştırır:

1. Rapor URL'leri tek tek değil, grup hâlinde değerlendirir. Benzer şablonu kullanan sayfalar — örneğin tüm ürün sayfaları veya tüm blog yazıları — birlikte gruplanır. Bu aslında iyi haberdir: sorun genellikle şablondadır ve şablonu düzelttiğinizde grubun tamamı birden düzelir.
2. Önce mobile bakın. Hem trafiğin çoğunluğu mobildedir hem de Google dizinlemeyi mobil sürüm üzerinden yapar. Masaüstü raporu yemyeşilken mobil raporu kırmızı olan site sayısı hiç az değildir.
3. Veri 28 günlük pencereyle gelir. Bugün yaptığınız düzeltme raporda hemen görünmez. Düzeltmeden sonra rapor içindeki doğrulama sürecini başlatın ve dört-altı hafta sabırla izleyin; aradaki sessizlik, çalışmanın boşa gittiği anlamına gelmez.

Bir not: trafiği düşük sitelerde rapor kısmen ya da tamamen boş görünebilir, çünkü Google yeterli gerçek kullanıcı ölçümü toplayamamıştır. Bu durumda laboratuvar testleri ve kendi telefonunuzla mobil şebeke üzerinden yapacağınız gerçek denemeler ana pusulanız olur.

Hazır altyapılarda hız: ikas, Shopify ve WordPress'te elinizde ne var?

Türkiye'de e-ticaret yapan işletmelerin önemli kısmı ikas veya Shopify gibi hazır altyapılar ya da WordPress/WooCommerce kullanıyor. Hazır altyapının doğası gereği sunucu, çekirdek kod ve CDN katmanı size kapalıdır — bu hem avantajdır (altyapı bakımıyla uğraşmazsınız) hem de tavandır (belirli bir noktadan sonrasına müdahale edemezsiniz).

Hazır altyapıda kontrolünüzdeki alanlar şaşırtıcı derecede etkilidir: görselleri yüklemeden önce optimize etmek, uygulama ve eklenti sayısını azaltmak, hafif ve güncel bir tema seçmek, üçüncü taraf scriptleri ayıklamak. Yönettiğimiz mağazalarda hazır altyapı üzerindeki hız sorunlarının çoğunun kaynağı platformun kendisi değil, zaman içinde üzerine eklenenlerdir. Altyapı seçiminin hız dahil tüm boyutlarını ikas mı Shopify mı karşılaştırmamızda ayrıntılı ele almıştık.

WordPress tarafı ayrıca dikkat ister: en esnek ama en kolay bozulan altyapıdır. Eklenti şişmesi, ucuz paylaşımlı hosting ve üst üste bindirilmiş sayfa oluşturucu katmanları en yaygın üç darboğazdır. İyi bir hosting, güvenilir bir önbellek çözümü ve görsel optimizasyonu üçlüsü, çoğu WordPress sitesini "Zayıf" banttan çıkarmaya tek başına yeter.

Özel geliştirmenin performans avantajı

Hazır altyapının tavanına dayandıysanız — yani yapılabilecek temizliği yaptınız ama metrikler hâlâ istediğiniz yerde değilse — konu yapısal demektir. Hazır platformlarda binlerce farklı mağazanın ihtiyacını karşılamak için yazılmış ortak kod tabanını, kullanmadığınız özellikleriyle birlikte taşırsınız. Özel geliştirmede denklem tersine döner: sayfaya yalnızca o sayfanın ihtiyacı olan kod gider.

Modern bir özel geliştirmede sunucu tarafında oluşturulan sayfalar, otomatik görsel optimizasyonu, akıllı önbellekleme ve uç sunucu dağıtımı baştan kurgulanır; Core Web Vitals sonradan yetişilmeye çalışılan bir sınav değil, tasarım aşamasında konulan bir hedef olur. Biz özel yazılım ve web sitesi projelerimizde bu hedefleri proje başında yazılı kabul kriteri olarak tanımlarız; çünkü sonradan hızlandırmak, baştan hızlı kurmaktan her zaman daha pahalıdır.

Dengeli olalım: özel geliştirme her işletme için doğru cevap değildir. Bakım sorumluluğu size veya çalıştığınız ekibe geçer, başlangıç maliyeti daha yüksektir ve kötü yazılmış bir özel site, iyi yönetilen bir hazır altyapıdan daha yavaş bile olabilir. Hangi durumda hangisinin mantıklı olduğunu hazır site mi, özel yazılım mı rehberimizde, bütçe tarafını ise özel yazılım maliyeti yazımızda ayrıntılı inceledik.

Hızı iyileştiren yedi adım

Hangi altyapıda olursanız olun, iyileştirme çalışmasının iskeleti aynıdır. Etki ve zahmet dengesine göre sıraladık:

1. Görselleri optimize edin. Çoğu sitede en büyük kazanım buradadır. Görselleri WebP veya AVIF formatına çevirin, gerçekte görüntülenecekleri boyutta yükleyin ve makul oranda sıkıştırın. Birkaç megabaytlık bir ürün fotoğrafının yüz-iki yüz kilobayta inmesi olağandır ve gözle görülür kalite kaybı yaşanmaz.
2. Lazy loading'i doğru kullanın. Ekranın altında kalan görselleri ihtiyaç anında yüklemek doğrudur; ama ilk ekranda görünen kapak görseline uygulanırsa en kritik metriğiniz olan LCP'yi gereksiz yere uzatır. Kural basit: ilk ekrandakiler hemen, gerisi sonra.
3. Script envanteri çıkarın. Sitenizde yüklenen her üçüncü taraf scripti listeleyin: pikseller, canlı destek, ısı haritası, eski kampanya araçları. Son üç ayda verisine bakmadığınız her araç kaldırılma adayıdır. Kalanları erteleyerek yükletin.
4. Önbellek ve CDN kullanın. Sayfanın her ziyaretçi için sıfırdan oluşturulması israftır. Önbellekleme sunucu yükünü düşürür; CDN içeriği ziyaretçiye coğrafi olarak yakın sunucudan ulaştırır. Hazır altyapılarda bu katman genellikle dahildir; WordPress ve özel sitelerde sizin kurmanız gerekir.
5. Font yüklemesini sadeleştirin. Bir-iki font ailesi ve toplamda üç-dört ağırlık çoğu site için fazlasıyla yeterlidir. Kullanmadığınız ağırlıkları yüklemeyin, font dosyalarını kendi alan adınızdan sunun ve yazının font beklemeden görünmesini sağlayın.
6. Sunucu yanıt süresini iyileştirin. İlk bayt gecikiyorsa hiçbir ön yüz optimizasyonu sizi kurtarmaz. Aylık çok düşük ücretli paylaşımlı hosting paketleri yoğun saatlerde tıkanır; trafiğiniz büyüdüyse hosting'iniz de onunla birlikte büyümeli.
7. Ölçmeden değiştirmeyin. Her değişiklikten önce ve sonra aynı sayfayı aynı araçla ölçün, mümkünse tek seferde tek değişiklik yapın ki neyin işe yaradığını bilin. "Her şeyi aynı anda değiştirdik, galiba hızlandı" yaklaşımı, bir sonraki sorunda sizi kör bırakır.

Geliştirici olmayanlar için öncelik listesi

Kod bilmiyorsanız bile sürecin önemli bir kısmını kendiniz yönetebilirsiniz. Sıra şöyle:

1. Search Console'daki Core Web Vitals raporunu açın; mobilde "Zayıf" grup var mı, hangi metrik kötü, not edin.
2. Ana sayfanızı ve en çok trafik alan iki-üç sayfanızı PageSpeed Insights'ta test edin; özellikle gerçek kullanıcı verisi bölümüne odaklanın.
3. Hangi metrik kötüyse oraya yönelin: LCP kötüyse görseller ve sunucu, INP kötüyse script kalabalığı, CLS kötüyse görsel boyutları ve sonradan yüklenen öğeler ilk şüphelilerdir.
4. En büyük görsellerinizi sıkıştırın ve formatlarını dönüştürün — bunun için ücretsiz araçlar fazlasıyla yeterlidir.
5. Kullanmadığınız eklenti, uygulama ve scriptleri kaldırın. Emin olamadıklarınızı geçici olarak kapatıp bir hafta izleyin.
6. Yeni tema, uygulama veya pazarlama aracı eklerken tek bir soruyu alışkanlık hâline getirin: "Bu, sayfa hızıma ne kadar mal olacak?"
7. Bunlara rağmen metrikler düzelmiyorsa sorun büyük olasılıkla şablon veya altyapı katmanındadır; bu noktada teknik destek almak, deneme-yanılmayla aylar kaybetmekten daha ucuzdur.

Bu listenin güzel tarafı şu: ilk beş madde hiçbir teknik bilgi gerektirmez ama tipik bir KOBİ sitesindeki hız sorununun büyük bölümünü çözer. Hızın ötesindeki teknik SEO başlıkları için e-ticaret SEO rehberimize de göz atabilirsiniz.

Sonuç: Hız bir kerelik proje değil, alışkanlıktır

Core Web Vitals'ı bir kez "yeşile çevirip" unutacağınız bir sınav gibi düşünmeyin. Her yeni kampanya görseli, her eklenen script, her tema güncellemesi metrikleri yeniden etkiler. Kazananlar, hızı düzenli kontrol edilen bir sağlık göstergesi gibi izleyen ve "eklemeden önce maliyetini sor" disiplinini kuran işletmelerdir. Üç metriği anladıysanız, Search Console raporunu okuyabiliyorsanız ve yukarıdaki öncelik listesini uyguluyorsanız, rakiplerinizin çoğundan zaten öndesiniz.

Siteniz tüm temizliğe rağmen istediğiniz hıza ulaşmıyorsa ya da yeni bir site yatırımını baştan doğru kurmak istiyorsanız, Alis Dijital olarak özel yazılım ve web sitesi projelerinde Core Web Vitals hedeflerini işin kabul kriteri olarak tanımlıyor, sonucu ölçülebilir şekilde teslim ediyoruz. Mevcut sitenizin nerede takıldığını birlikte inceleyelim; çoğu zaman sorunun kaynağı, dışarıdan göründüğünden çok daha basit çıkıyor.