Core Web Vitals Raporu Nasıl Okunur ve Neye Öncelik Verilir?

Search Console’da core web vitals raporu kırmızıya döndüğünde panik yapmak kolaydır. Zor olan, hangi sorunun gerçek iş etkisi yarattığını ayırmaktır.

Çünkü her kötü metrik aynı ağırlıkta değildir. Bazı sorunlar yüzlerce URL’ye yayılır, bazıları yalnızca düşük trafikli birkaç sayfayı etkiler. Bu yüzden raporu okumak kadar, doğru sırayla hareket etmek de önemlidir.

Aşağıda Search Console ve PageSpeed Insights verilerini birlikte nasıl yorumlayacağınızı, hangi sorunu önce ele almanız gerektiğini ve ekip içinde işi nasıl hızlandıracağınızı net şekilde bulacaksınız.

Search Console raporunu doğru okumak

Search Console’daki Core Web Vitals raporu, tek tek URL kontrol ekranı değildir. Asıl gücü, benzer sorunu yaşayan sayfaları grup halinde göstermesidir. Bu yüzden ilk işiniz kırmızı URL sayısına değil, sorun örüntüsüne bakmak olmalı.

Raporu okurken mobil ve masaüstünü ayrı değerlendirin. Çoğu sitede öncelik mobil taraftadır, çünkü saha verisindeki bozulma burada daha sert görünür. Ayrıca Search Console, son 28 güne yayılan gerçek kullanıcı verisini kullanır. Bu nedenle anlık test sonucu ile rapor birebir aynı görünmeyebilir. Search Console Yardım sayfası bu farkı temel düzeyde açıklar.

İlk bakılacak üç metrik bellidir. LCP, ana içeriğin görünme hızını ölçer. INP, tıklama veya dokunma sonrası sayfanın ne kadar hızlı tepki verdiğini gösterir. CLS ise sayfa öğelerinin ne kadar kaydığını anlatır. Güncel eşikler kabaca şöyledir: LCP 2,5 saniye altı, INP 200 ms altı, CLS 0,1 altıysa iyi kabul edilir.

Burada yapılan yaygın hata, listedeki örnek URL’yi tek başına incelemektir. O URL, genelde daha büyük bir şablon sorununun temsilcisidir. Örneğin kategori sayfasındaki büyük hero görseli, aynı şablonu kullanan 80 URL’nin tamamında LCP sorununa yol açabilir. Tek sayfayı düzeltip geçerseniz, rapor yeşile dönmez.

Raporu okurken şu sırayı izleyin: önce “Kötü” durumdaki mobil grupları açın, sonra etkilenen URL sayısını görün, ardından örnek URL’leri inceleyin. Son olarak da trend çizgisine bakın. Sorun yeni mi çıktı, yoksa bir sürümdür mi büyüyor? Bu ayrım, kök nedeni bulmayı hızlandırır.

Rapor size “hangi URL yavaş?” sorusundan çok, “hangi sayfa tipi bozuk?” sorusunun cevabını verir.

PageSpeed Insights veriyi açıklar, kararı vermez

Search Console size nerede sorun olduğunu söyler. PageSpeed Insights ise çoğu zaman nedenini açığa çıkarır. Bu iki aracı birlikte okumadığınızda, ekipler sık sık yanlış yere müdahale eder.

PageSpeed Insights’ta iki veri katmanı vardır. İlki saha verisi, yani gerçek kullanıcı davranışıdır. İkincisi lab verisi, yani kontrollü test koşullarındaki teknik teşhistir. Karar verirken saha verisini esas alın. Düzeltme yaparken lab verisini kullanın. Aradaki çizgi budur.

Mesela Search Console’da mobil LCP sorunu görüyorsanız, örnek URL’yi PageSpeed Insights’ta açın. Ardından LCP öğesinin ne olduğunu bulun. Büyük bir banner mı, yavaş bir ürün görseli mi, yoksa web font mu? Sonra render-blocking CSS, sunucu yanıt süresi, görsel sıkıştırma ve önceliklendirme sorunlarına bakın. Bu yaklaşım, geliştiriciye net görev çıkarır.

INP tarafında tablo daha da önemlidir. Çünkü interaksiyon gecikmesi genelde uzun JavaScript görevlerinden, üçüncü taraf etiketlerden veya ana iş parçacığındaki yükten kaynaklanır. PageSpeed Insights içindeki Lighthouse çıktıları burada çok işe yarar. Lighthouse metrikleri rehberi, hangi teşhislerin hangi kullanıcı sorununa işaret ettiğini iyi özetler.

Ancak kritik bir sınır var: lab verisi kötü diye o sorunu otomatik olarak ilk sıraya alamazsınız. Eğer saha verisinde bozulma yoksa, bu yalnızca bir izleme notudur. Tersi durumda, yani saha verisi kötüyse ama lab tarafı çok dramatik görünmüyorsa, yine de öncelik saha verisindedir. Çünkü kullanıcı siteyi laboratuvarda değil, gerçek cihazda kullanır.

Bu ayrım, performans ekibinin en çok zaman kaybettiği noktadır. Bu yüzden PageSpeed Insights’a bir “öncelik aracı” gibi değil, “teşhis ekranı” gibi yaklaşın.

Öncelik matrisi: İlk hangi sorunu çözmeli?

Net cevap şu: Önce kırmızı durumda olan, şablon düzeyinde yayılan, yüksek trafik veya gelir etkisi taşıyan ve makul eforla çözülebilen sorunu çözün. Tekil URL’ler ve düşük trafikli sayfalar bekleyebilir.

Pratikte dört faktörü birlikte düşünün. Sorunun şiddeti, kapsadığı URL sayısı, iş değeri ve çözüm maliyeti. Bir sorun ana sayfa, kategori ya da ürün detay şablonunu etkiliyorsa, birkaç puan birden kazanır. Aynı sorun arşivlenmiş kampanya sayfalarında görünüyorsa, listenin altına iner.

Aşağıdaki tablo, ekip toplantısında hızlı karar vermek için iş görür:

Senaryo	Etki alanı	İş etkisi	Tahmini efor	Öncelik
Mobil kategori şablonunda LCP > 4 sn, büyük görseller ve bloklayan CSS var	120 URL, organik giriş yüksek	Gelir ve giriş sayfaları etkileniyor	Orta	1
Sepet ve ödeme adımlarında kötü INP, üçüncü taraf script yükü fazla	6 URL, ama dönüşüm kritik	Doğrudan gelir etkisi var	Orta-Yüksek	1
Blog şablonunda CLS yüksek, görsel boyutları tanımsız	400 URL, trafik orta	Okuma deneyimi bozuluyor	Düşük	2
Ürün detaylarda “iyileştirme gerekli” INP sorunu	900 URL, trafik yüksek	Ticari etki var ama kırmızı değil	Orta	3
Eski kampanya sayfalarında kötü LCP	35 URL, trafik düşük	İş değeri sınırlı	Düşük	4

Tablonun verdiği mesaj açık. Yalnızca metrik seviyesine bakmayın. Ödeme adımlarındaki kötü INP, sayfa sayısı az olsa bile ilk sıraya çıkabilir. Çünkü etki alanı küçük, iş etkisi büyüktür.

Benzer şekilde, 400 blog URL’sindeki CLS sorunu kulağa büyük gelebilir. Fakat o sayfalar düşük değerliyse, kategori veya checkout şablonundan sonra gelmelidir. web.dev’deki öncelik önerileri de benzer biçimde, en yüksek kullanıcı etkisine sahip düzeltmelerden başlamayı tavsiye eder.

Bir puanlama mantığı kullanmak isterseniz basit tutun: şiddet x şablon yayılımı x iş değeri / efor. Mükemmel model aramayın. Ama herkesin aynı cetvelle bakmasını sağlayın.

Eğer teknik SEO, ürün ve geliştirme tarafı aynı öncelikte buluşamıyorsa, bu süreç ayrı bir çalışma disiplini ister. Bu tür durumlarda profesyonel SEO danışmanlığı desteği, raporu iş hedefiyle eşleştirmeyi kolaylaştırır.

En sık yapılan okuma hataları

İlk hata, düşük trafikli sayfalara gereğinden fazla zaman ayırmaktır. Search Console’da kırmızı görmek rahatsız eder; ama her kırmızı alan, aynı iş sonucunu doğurmaz. Trafik, dönüşüm ve şablon kapsaması düşükse, sıranın gerisine atın.

İkinci hata, tekil URL’ye odaklanıp şablon sorununu kaçırmaktır. Örnek ürün sayfasında LCP bozuksa, çoğu zaman problem aynı kart yapısı, aynı görsel bileşeni ya da aynı JavaScript paketidir. Sayfayı değil, kalıbı düzeltin.

Üçüncü hata, lab verisini saha verisinin yerine koymaktır. Lighthouse puanı 55 çıktı diye savaş moduna geçmek doğru değildir. Search Console ve CrUX verisinde bozulma yoksa, bu sonuç bir uyarıdır; öncelik sinyali değildir. Tersi durumda ise saha verisi kötüyse ve lab testinde neden net görünüyorsa, işe başlanacak yer orasıdır.

Dördüncü hata, düzeltmeden hemen sonra raporun yeşile dönmesini beklemektir. Search Console son 28 günlük veriyi kullandığı için toparlanma gecikir. Kod yayına alındıktan sonra “Doğrulamayı başlat” sürecini yürütün, ama sonucu birkaç günde beklemeyin.

Beşinci hata, mobili ikinci plana atmaktır. Masaüstünde iyi görünen sayfalar, düşük güçlü telefonlarda ağır script yükü yüzünden kötü INP verebilir. Gerçek kullanıcı deneyimi çoğu zaman burada kırılır.

Kısa kontrol listesi ve ekip akışı

Aşağıdaki kısa liste, raporu gördüğünüz gün işe yarar:

• Mobil rapordaki “Kötü” grupları önce açın.
• Örnek URL’yi değil, ortak şablonu belirleyin.
• Her sorun için etkilenen URL sayısını ve iş değerini yazın.
• PageSpeed Insights’ta saha verisi ile lab verisini ayrı okuyun.
• Her düzeltme için bir sahip, hedef metrik ve tarih atayın.
• Yayın sonrası Search Console doğrulamasını başlatın ve 28 günlük pencereyi hesaba katın.

Bunu haftalık akışa çevirmek de kolaydır. Pazartesi günü Search Console’dan sorun gruplarını çıkarın. Salı günü örnek URL’lerde teşhis yapın. Çarşamba günü geliştirici görevlerini açın. Sonra yayına alın, doğrulama başlatın ve metrik trendini izleyin.

Kâğıt üstünde karmaşık görünür. Oysa düzenli yapıldığında süreç sadedir: raporu oku, kalıbı bul, iş etkisini hesapla, sonra düzelt.

Sonuç

Core Web Vitals raporunu iyi okumak, metrik ezberlemekten çok daha değerlidir. Asıl farkı yaratan şey, saha verisini iş etkisiyle birlikte yorumlamaktır.

Öncelik sırası da nettir: kırmızı durumda olan, çok sayfaya yayılan, gelir veya giriş sayfası etkisi yüksek sorunları önce çözün. PageSpeed Insights’ı teşhis için kullanın, tekil URL’ye takılmayın ve şablon bazında düşünün.

Bunu yaptığınızda rapor yalnızca bir uyarı ekranı olmaktan çıkar. Ekip için net bir aksiyon planına dönüşür.

This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.