Hızlı Cevap
Core Web Vitals iyi görünürken şikayet sürüyorsa bakılması gereken veri yalnızca CrUX skoru değildir; cihaz ve ağ segmentli RUM olayları, INP etkileşim hedefleri, JS hata oranı, API gecikmesi, rage click, scroll abandonment ve destek kayıtlarıyla eşleşen oturum davranışı birlikte incelenmelidir.
Önemli Noktalar
- 75. persentil yeşil olsa da sorunlu segmentler gizlenebilir.
- Tekil URL yerine görev, şablon ve kullanıcı segmenti okuyun.
- INP için hedef, tip ve zaman damgası olay düzeyinde şarttır.
- JS hatası, API gecikmesi ve rage click birlikte yorumlanmalıdır.
- CrUX trendi kök nedeni değil, dağılımı ve yönü gösterir.
Core Web Vitals iyi görünürken şikayet neden sürer?
Core Web Vitals skorunun iyi görünmesi, bütün kullanıcıların iyi bir deneyim yaşadığı anlamına gelmez. Google Search Central 2026’da da resmi çerçevenin LCP, INP ve CLS üzerinden sürdüğünü söylüyor; ancak bu çerçeve bir sayfanın tüm deneyimini değil, yükleme, etkileşim ve görsel stabiliteyi özetler. Kullanıcı “site yavaş” dediğinde sorun bazen sayfanın ilk açılışında değil, filtre paneli, hesap alanı, form doğrulaması ya da sonsuz kaydırma gibi yükleme sonrası anlarda ortaya çıkar.
İkinci kritik nokta, raporların çoğunun 75. persentil mantığıyla okunmasıdır. Google Search Console Yardım dokümantasyonuna göre Core Web Vitals raporu gerçek kullanıcı verisini CrUX’tan alır ve URL gruplarını son 28 günlük alan verisine göre sınıflandırır. Bu yüzden çoğunluk iyi görünürken, örneğin düşük kaliteli ağda kalan mobil kullanıcılar veya oturum açmış kullanıcılar gibi daha küçük ama ticari açıdan kritik bir segment hâlâ kötü deneyim yaşayabilir.
PageSpeed Insights ile Search Console arasında fark görmeniz de normaldir. Search Console benzer deneyim üreten URL gruplarını okur; PageSpeed Insights ise çoğu zaman tekil URL görünümüne yaklaşır. Bir URL grubunun “iyi” olması, o gruptaki tüm sayfaların ve tüm etkileşimlerin kusursuz olduğu anlamına gelmez. Bu ayrımı ekip içinde netleştirmek için bir referans ihtiyacınız varsa teknik SEO terimleri sözlüğü bu kavramları aynı terminolojiyle hizalamayı kolaylaştırır.
Hangi gerçek kullanıcı verileri önce segmentlenmeli?
İlk iş, veriyi sayfa bazında değil kullanıcı ve koşul bazında bölmektir. En çok kaçırılan hata, bütün oturumları tek havuzda okuyup ortalama bir performans hikâyesi çıkarmaktır. Oysa aynı sayfa; iPhone Safari’de iyi, düşük Android cihazlarda kötü; giriş yapmamış kullanıcıda akıcı, oturum açmış kullanıcıda ağır olabilir. Search Console’un cihaz bazlı görünümü değerli bir başlangıçtır ama gerçek teşhis için birinci taraf RUM tarafında daha derine inmek gerekir.
- Cihaz türü, işletim sistemi ve tarayıcı: Mobil şikayetleri çoğu zaman masaüstü ortalamasında kaybolur.
- Ağ kalitesi ve ülke: 4G, zayıf Wi‑Fi ya da bölgesel CDN farkları algılanan hızı ciddi biçimde değiştirir.
- Yeni ve dönen ziyaretçi: Dönen kullanıcıların cache avantajı, ilk kez gelenlerdeki sorunu örtebilir.
- Giriş yapmış ve yapmamış kullanıcı: Hesap alanları, sepet ve panel ekranları daha ağır JavaScript taşır.
- Kaynak kanal: Organik, reklam ve e-posta trafiği farklı sayfalara ve farklı niyetlere gelir.
- Görev bazlı akışlar: Arama, filtreleme, checkout, kayıt ve form gönderimi tek tek okunmalıdır.
Search Console Yardım, Core Web Vitals verisini URL grupları üstünden sunduğunu açıkça belirtir. Bu nedenle analizde tek tek URL listesinden çok şablon ve görev mantığı daha faydalıdır. Kategori şablonu, ürün detay şablonu, filtre paneli, dahili arama, üyelik girişi ve checkout gibi akışları ayrı kümelerseniz, “CWV iyi ama şikayet var” senaryosunda hangi davranışın problem ürettiği daha hızlı görünür.
Pratikte şu sıralama iyi çalışır: önce cihaz ve ağ, sonra kullanıcı tipi, ardından görev bazlı akış. Çünkü kullanıcı şikayetleri çoğu zaman “hangi sayfa yavaş” sorusundan çok “hangi iş yapılırken takılma oluyor” sorusuna cevap verir. Tekil URL odaklı okumalar, özellikle parametreli arama ve filtre sayfalarında, sorunun şablon seviyesindeki gerçek nedenini kaçırır.
INP iyi olsa bile hangi debug sinyalleri toplanmalı?
Genel INP değeri iyi görünse bile, etkileşim tarafında olay düzeyi veri toplamıyorsanız kör uçuş yaparsınız. web.dev alan debug rehberi, INP için sahada yakalanması gereken en kritik bilgileri net söylüyor: hangi öğeyle etkileşim kurulduğu, etkileşim tipi ve etkileşimin ne zaman gerçekleştiği. Buna rota, yüklenme aşaması ve kullanıcı segmenti eklendiğinde, yavaş tıklamanın ilk render sırasında mı, veri beklerken mi, yoksa sonradan yüklenen bir bileşende mi oluştuğu anlaşılır.
- Etkileşim hedefi: Buton, filtre, autocomplete alanı, sekme, modal açıcı.
- Etkileşim tipi: Tıklama, dokunma, klavye girişi, kaydırma sonrası tetiklenen olay.
- Zaman damgası ve yüklenme aşaması: Sayfa açıldıktan kaç saniye sonra oldu, ilk yükleme sürüyor muydu?
- JS error rate: Kullanıcı “dondu” derken altta sessiz bir JavaScript hatası olabilir.
- API latency ve timeout: Arayüz hızlı açılır ama veri cevabı geç gelirse deneyim yine kötü hissedilir.
- Long task ve render blokajı: Ana thread doluluğu etkileşimi geç boyatır.
- Rage click ve dead click: Kullanıcı tepki alamadığı için aynı noktaya tekrar tekrar basar.
- Scroll abandonment: Kullanıcı kritik içeriğe gelmeden akışı terk eder.
Bu sinyalleri birlikte okumak gerekir; tek başına hiçbiri yeterli değildir. Örneğin filtre çekmecesi hızlı açılıyor olabilir ama API gecikmesi yüzünden sonuçlar geç yenileniyorsa kullanıcı bunu “sayfa kasıyor” diye tarif eder. Ya da JS hata oranı sadece belirli bir tarayıcı sürümünde yükseliyorsa genel INP ortalaması sorunu gizler. Sorunun etkileşim anında mı yoksa sonuç beklerken mi oluştuğunu ayıran şey bu yardımcı sinyallerdir.
web.dev’in 2 Eylül 2025’te güncellenen INP rehberi, kullanıcı zamanının büyük bölümünün ilk yükleme sonrasında geçtiğini vurgular. Bu da 2026’da hâlâ şu gerçeği değiştirmez: yalnızca açılış performansını ölçmek, hissedilen deneyimi açıklamaya yetmez. Yavaş autocomplete, takılan sepet butonu, tepki vermeyen filtre ve geç kapanan modal çoğu şikayetin gerçek kaynağıdır.
30-60 günlük vaka: CrUX, RUM ve destek kayıtları nasıl eşleştirilir?
Sahada en temiz yöntem, aynı akış için 30 gün önce ve 30 gün sonra karşılaştırması yapmaktır. Tek günlük sıçramalar yanıltıcı olabilir; release etkisi, kampanya trafiği veya mevsimsel cihaz dağılımı sonuçları bozabilir. Bu yüzden önce destek kayıtlarını rota, cihaz ve problem türüne göre etiketleyin; ardından birinci taraf RUM oturumlarıyla aynı zaman penceresinde eşleyin. Burada amaç “şikayet arttı” demek değil, şikayetin hangi davranışla birlikte arttığını görmek olmalıdır.
Çalışan bir inceleme akışı genelde şu sırayı izler: destek ticket metinlerini normalize et, ilgili rota ve kullanıcı tipini işaretle, release notu zamanlarını ekle, sonra session replay ve olay düzeyi RUM verisini aynı segmentte aç. Böyle yaptığınızda “genel skor iyi ama kullanıcı takılıyor” cümlesi teknik olarak anlam kazanır. Özellikle giriş yapmış mobil kullanıcılar, dahili arama kullananlar veya filtreyi üst üste deneyenler ayrı okunduğunda kök neden çok daha hızlı görünür.
Session replay burada tek başına kanıt değil, nicel sinyali doğrulayan görsel bağlam rolündedir. Rage click artışı gördüğünüz rotada replay açıp, aynı anda API bekleme süresi ve uzun task verisini kontrol ederseniz, kullanıcının neden akışı terk ettiğini anlamak kolaylaşır. Ekip içinde tekrar tekrar işe yarayan desen şudur: tek URL raporu nadiren yeterlidir; rota, segment ve etkileşim hedefi üçlüsü aynı anda eşleştiğinde sorun görünür hâle gelir.
Search Console, PageSpeed Insights ve site audit birlikte nasıl okunur?
Bu üç aracı aynı soruya cevap veriyormuş gibi okumak en sık yapılan hatalardan biridir. Search Console size hangi URL grubunun ve hangi cihaz tarafının kötüleştiğini söyler. PageSpeed Insights, belirli bir URL’de alan verisi varsa onun özetini ve laboratuvar ipuçlarını birlikte gösterir. Birinci taraf RUM ise hangi butonun, hangi API çağrısının ve hangi oturum davranışının problemi ürettiğini verir. Yani biri yön gösterir, diğeri teşhis derinliği sağlar.
2026 tarafında önemli güncel not şu: Chrome ekibi CrUX Dashboard’un Kasım 2025 sonunda sonlandırıldığını duyurdu. Trend okumada bugün daha güncel seçenek CrUX Vis veya History API yaklaşımıdır. Buna karşılık CrUX BigQuery yayınları aylık olarak sürer ve 2026 verileri ikinci Salı kadansıyla yayınlanmaya devam eder; örneğin Haziran 2026 veri seti 14 Temmuz 2026’da yayımlandı. Bu ayrım önemlidir: trend var mı sorusu için CrUX, neden oldu sorusu için RUM gerekir.
Operasyon tarafında ise SEO ve UX’i aynı panelde görmek işinizi hızlandırır. Ahrefs, SEMrush, Moz veya SE Ranking görünürlük ve rekabet bağlamı için yararlı araçlardır; SEOYEN bunu Türkiye pazarına daha yakın bir operasyon katmanıyla tamamlar. site audit görünümü ile şablon ve teknik riskleri, sıralama takibi paneli ile organik görünürlük etkisini aynı akışta takip edebilirsiniz. Türkçe arayüz, TL bazlı güncel fiyatlandırma ve yerel Türkçe destek, performans regresyonlarını yalnızca ölçmek değil hızlı aksiyona çevirmek isteyen ekipler için pratik bir avantaj sağlar.
| Veri kaynağı | Ne gösterir | En iyi kullanım | Kör nokta |
|---|---|---|---|
| Search Console Core Web Vitals raporu | CrUX alan verisiyle URL grubu durumu | Hangi şablon grubu kötüleşti sorusu | Olay düzeyi sebebi göstermez |
| PageSpeed Insights alan verisi | Tek URL veya origin için alan ve lab görünümü | Belirli URL’de farkı hızlı doğrulama | Az trafikli URL’de alan verisi olmayabilir |
| CrUX Dashboard / CrUX Vis trendi | Tarihsel dağılım ve cihaz kırılımı | Uzun dönem trend ve yayın kadansı takibi | Kullanıcı oturumu ve ticket bağlamı yok |
| Birinci taraf RUM | Olay, hedef, zaman, cihaz ve ağ bağlamı | Kök neden ve regresyon tespiti | Kurulum zayıfsa veri eksik kalır |
| Session replay | Davranışın görsel akışı | Rage click ve takılma doğrulaması | Ölçekli nicel özet sunmaz |
| Destek ticket’ları | Kullanıcının problemi kendi diliyle anlatması | İş etkisi ve öncelik belirleme | Tek başına teknik neden kanıtlamaz |
Adım Adım: CWV yeşilken gizli UX sorunu teşhisi
Genel skorların iyi görünmesi sizi rahatlatmasın. Teşhis sürecini tek araçtan değil, aynı akışa bakan birkaç veri katmanından kurduğunuzda gerçek darboğaz daha hızlı bulunur. Aşağıdaki sıralama, hem SEO hem ürün tarafının aynı dili konuşmasını sağlar.
- Şikayetleri kritik akış ve segmentlere ayır. Destek kayıtlarını cihaz, ağ, kullanıcı tipi ve görev bazında etiketleyin; önce hangi grubun şikayet ürettiğini netleştirin.
- CrUX ile birinci taraf RUM farkını karşılaştır. CrUX özetinin kötü göstermediği ama RUM’un yoğun sorun gösterdiği rota ve segmentleri ayrı işaretleyin.
- INP etkileşim alanlarını olay düzeyinde kaydet. Hedef öğe, etkileşim tipi, zaman damgası ve yüklenme aşaması olmadan etkileşim sorunu teşhis edilmez.
- Hata, gecikme ve replay sinyallerini eşleştir. JS hatası, API gecikmesi, long task, rage click ve replay görüntüsünü aynı oturum bağlamında okuyun.
- SEO ve dönüşüm etkisini rapora bağla. Sorunlu akışların organik açılış sayfaları, sıralama görünürlüğü ve dönüşüm kaybıyla ilişkisini birlikte önceliklendirin.
Bu akışın asıl faydası, “performans iyi görünüyor ama kullanıcı mutsuz” çelişkisini ölçülebilir parçalara bölmesidir. Sonuçta hedef yalnızca metrik iyileştirmek değil; kullanıcıların arama, filtreleme, gezinme ve satın alma gibi ana görevleri kesintisiz tamamlayabildiği bir deneyim kurmaktır.
Kaynaklar
Sıkça Sorulan Sorular
Core Web Vitals raporu, Google Search Console içindeki ve CrUX alan verisine dayanan bir rapordur. Burada tekil test sonucu değil, benzer deneyim üreten URL gruplarının LCP, INP ve CLS durumu gösterilir. Yani rapor, gerçek kullanıcıların son 28 gündeki deneyimini özetler. laboratuvar simülasyonu değildir. Bu yüzden geliştirme önceliği belirlemek için güçlüdür, ancak bir butonun neden geç tepki verdiğini tek başına açıklamaz. Olay düzeyi teşhis için RUM, hata logları ve gerekiyorsa session replay ile birlikte okunmalıdır.
Core Web Vitals, Google’ın sayfa deneyimi çerçevesindeki sinyallerden biridir. ancak tek başına sıralamaları açıklamaz. Arama görünürlüğü hâlâ içerik kalitesi, alaka düzeyi, niyet uyumu, bağlantı profili ve diğer sıralama sistemleriyle birlikte şekillenir. Bu nedenle iyi CWV skorları almak faydalıdır ama otomatik olarak daha yüksek sıralama garanti etmez. Pratikte doğru yaklaşım, CWV verisini organik açılış sayfaları, sorgu performansı ve dönüşüm verileriyle birlikte yorumlamaktır. Böylece hem kullanıcı deneyimini hem SEO etkisini aynı çerçevede okuyabilirsiniz.
PageSpeed Insights içinde alan verisi bölümü varsa, bu bölüm CrUX’tan gelen gerçek kullanıcı ölçümlerini gösterir. Aynı ekranda yer alan laboratuvar bölümü ise simülasyonla üretilir ve teşhis amacı taşır. Bu iki bölümün farklı sonuç vermesi normaldir. çünkü biri kontrollü koşullarda tek sayfa yüklemesini, diğeri ise gerçek kullanıcı davranışını yansıtır. Eğer URL düzeyinde yeterli veri yoksa araç origin düzeyine düşebilir veya hiç alan verisi göstermeyebilir. Bu nedenle PageSpeed Insights sonuçlarını, Search Console grup verisi ve birinci taraf RUM ile birlikte değerlendirmek gerekir.
CrUX, gerçek Chrome kullanıcılarından toplanan toplulaştırılmış alan verisini sağlar ve trend okumak için çok değerlidir. Origin, URL, cihaz ve zaman serisi bazında performans eğilimlerini görmenizi sağlar. bu da özellikle Search Console ve PageSpeed Insights verisini bağlama oturtur. Ancak CrUX olay düzeyinde debug aracı değildir. Hangi kullanıcı hangi butonda takıldı, hangi API çağrısı gecikti veya hangi hata tetiklendi sorularını cevaplamaz. Bu yüzden en doğru kullanım, CrUX’u dış görünüm ve trend katmanı. birinci taraf RUM’u ise kök neden katmanı olarak konumlandırmaktır.
CWV dışında mutlaka izlenmesi gereken sinyaller arasında JS error rate, API latency, long task oranı, render blokajı, rage click, dead click, scroll abandonment ve dönüşüm hunisi kırılımları bulunur. Bunlar özellikle CWV yeşilken kullanıcının neden hâlâ memnun olmadığını anlamada çok etkilidir. Ayrıca kullanıcıyı cihaz, ağ kalitesi, tarayıcı, yeni-dönen ziyaretçi ve giriş durumu gibi segmentlere ayırmak gerekir. En verimli yaklaşım, bu sinyalleri olay düzeyinde toplayıp destek kayıtları ve session replay ile ilişkilendirmektir. Böylece metrik ile hissedilen sorun aynı bağlamda okunur.
Çünkü bu iki veri türü farklı soruları cevaplar. Laboratuvar verisi, kontrollü koşullarda potansiyel sorunları hızlıca teşhis etmek için idealdir. alan verisi ise gerçek kullanıcıların sahadaki deneyimini temsil eder. Bir sayfa laboratuvarda iyi görünüp sahada kötü hissedebilir ya da tam tersi olabilir. Özellikle etkileşim, kaydırma ve oturum içi davranışlar laboratuvar testinde sınırlı görünür. Bu nedenle PageSpeed Insights’ın iki görünümü birlikte sunması, hem sorun tahmini hem de gerçek etkiyi aynı ekranda değerlendirebilmeniz için gereklidir.