CrUX Alan ve Laboratuvar Verisi: CWV Raporu Rehberi

Aynı site için bir araç "iyi", başka bir araç "zayıf" derse hangisine inanacaksınız? Core Web Vitals raporlarında en sık yaşanan karışıklık budur ve çoğu zaman sorun araçlarda değil, hangi verinin okunduğunun bilinmemesindedir. Bir rapor gerçek ziyaretçilerin son haftalarda yaşadığı deneyimi anlatır, bir başkası ise tek bir cihazda, tek bir anda yapılan simülasyonu. İkisi de doğrudur, fakat farklı soruları yanıtlar.

Bu yazı SEO uzmanı, geliştirici ve müşterisine rapor sunan ajans çalışanı için hazırlandı. Önce alan verisi ile laboratuvar verisinin ne ölçtüğünü ayırır, ardından CrUX'ın kimi saydığını, hangi sitelerin dahil olduğunu ve yüzdelik mantığını anlatır. Sonra Search Console raporu ile PageSpeed Insights'ı karşılaştırır, iki verinin neden ayrıştığını sıralar, veri yetersizliğinde yapılabilecekleri tarif eder ve raporu önceliklendirme kararına çevirmek için bir yöntem önerir.

Alan Verisi ve Laboratuvar Verisi: Ne Ölçülür

İki veri türü arasındaki ayrım teknik bir ayrıntı değil, raporun nasıl okunacağını belirleyen temel çerçevedir. Bu çerçeveyi kurmadan hiçbir eşik değeri ya da puan anlamlı olmaz.

Alan verisi: gerçek ziyaretçilerin dağılımı

Alan verisi (field data), sitenizi gerçekten kullanan insanların tarayıcılarından toplanan ölçümlerdir. Her ziyaretçinin cihazı, ağı, konumu ve davranışı farklıdır; dolayısıyla tek bir değer değil, değerlerden oluşan bir dağılım ortaya çıkar. web.dev'in Core Web Vitals sayfası bu noktayı açıkça yazar: Core Web Vitals her şeyden önce alan metrikleridir ve laboratuvar ölçümü bunların yerine geçmez; yalnızca alan ölçümü bütün resmi doğru biçimde yakalayabilir. Kaynak olarak web.dev Web Vitals makalesine (yeni sekmede açılır) bakabilirsiniz.

Laboratuvar verisi: kontrollü bir simülasyon

Laboratuvar verisi (lab data), önceden belirlenmiş bir cihaz ve ağ koşulunda sayfanın yüklenmesiyle üretilir. Lighthouse bunun en bilinen örneğidir. PageSpeed Insights belgesi, laboratuvar verisinin tek bir cihazda ve sabit bir ağ koşulları kümesiyle yapılan simüle yüklemeye dayandığını söyler. Kontrollü olduğu için tekrarlanabilir; bu da hata ayıklamada büyük avantajdır. Aynı koşulda iki kez ölçüm yapıp bir değişikliğin etkisini görebilirsiniz.

Hangisi hangi soruya cevap verir?

Core Web Vitals'ın üç metriği ve iyi eşikleri

web.dev, Core Web Vitals'ı tüm web sayfalarına uygulanan Web Vitals alt kümesi olarak tanımlar. Üç metrik vardır: yükleme performansını ölçen LCP, etkileşim hızını ölçen INP ve görsel kararlılığı ölçen CLS. Aynı makaledeki iyi eşikler şöyledir: LCP için sayfa yüklenmeye başladıktan sonra 2,5 saniye içinde gerçekleşmesi, INP için 200 milisaniye veya altı, CLS için 0,1 veya altı. Eşikler sayfa yüklemelerinin 75. yüzdeliğinde, mobil ve masaüstü ayrı ayrı değerlendirilir. Bir sayfanın geçmesi için üç metriğin de bu hedefleri 75. yüzdelikte karşılaması gerekir.

INP için ayrıca bir ara bant vardır: INP makalesi (yeni sekmede açılır), 200 ms'nin üstü ile 500 ms ve altı arasını "iyileştirme gerekli", 500 ms'nin üstünü ise "zayıf" olarak tanımlar. INP; tıklama, dokunma ve klavye etkileşimlerinin gecikmesini ziyaret boyunca izler ve en kötü etkileşimi, aykırı değerleri dışarıda bırakarak raporlar. Kaydırma, üzerine gelme ve yakınlaştırma izlenmez.

Araçlar hangi tarafa düşer?

web.dev'e göre alan araçları Chrome Kullanıcı Deneyimi Raporu (CrUX), PageSpeed Insights ve Search Console'daki Core Web Vitals raporudur; üç metrik de bunlarda desteklenir. Chrome DevTools hem alan hem laboratuvar tarafında yer alır. Lighthouse ise laboratuvar aracıdır ve LCP ile CLS'yi ölçer, INP'yi ölçmez; makale INP yerine Toplam Engelleme Süresi (TBT) metriğine bakmayı önerir. Bu, "Lighthouse'ta INP görünmüyor" şikayetinin sebebidir ve hata değildir.

CrUX Nedir: Uygunluk, 28 Günlük Pencere ve 75. Yüzdelik

Alan verisinin pratikte en çok okunan kaynağı Chrome Kullanıcı Deneyimi Raporu'dur (Chrome UX Report, CrUX). Search Console, PageSpeed Insights ve birçok üçüncü taraf pano aynı veri kümesinden beslenir; bu yüzden CrUX'ın sınırlarını bilmek, bütün bu raporların sınırlarını bilmektir.

Tanım ve kullanım alanı

CrUX belgeleri (yeni sekmede açılır), veri kümesini web'deki popüler hedefleri gerçek Chrome kullanıcılarının nasıl deneyimlediğini yansıtan bir kaynak olarak tanımlar. Google'ın Web Vitals programının veri kümesidir ve kullanıcı odaklı tüm Core Web Vitals metrikleri bu veri kümesinde temsil edilir. Aynı sayfa, Google Arama'nın sayfa deneyimi sıralama faktöründe bu veriyi kullandığını da belirtir. Google, sayfa deneyiminin sıralamadaki ağırlığını bir sayıyla tarif etmez.

Kim sayılır, kim sayılmaz

CrUX'ın metodoloji sayfası kullanıcı uygunluğunu ayrıntılandırır. Kullanım istatistiği raporlamanın açık olması, tarayıcı geçmişinin eşitlenmesi ve bir eşitleme parolasının belirlenmemiş olması gerekir. Desteklenen platformlar Windows, macOS, ChromeOS ve Linux üzerindeki masaüstü Chrome ile Android Chrome'dur (Custom Tabs ve WebAPK dahil). iOS üzerindeki Chrome, WebView kullanan Android uygulamaları ve Edge gibi diğer Chromium tarayıcılar dışarıda kalır. Sonuç olarak CrUX metodolojisi (yeni sekmede açılır) size ziyaretçilerinizin tamamını değil, uygun bir alt kümesini anlatır. Hedef kitleniz ağırlıklı olarak iOS'taysa bu sınır özellikle önemlidir; analitiğinizdeki cihaz dağılımıyla birlikte okuyun.

Sayfa ve site uygunluğu

Aynı metodoloji sayfasına göre bir sayfa ya da origin'in CrUX'a girmesi için herkese açık keşfedilebilir ve yeterince popüler olması gerekir; popülerlik eşiği için kesin bir sayı açıklanmaz. Keşfedilebilirlik, sayfa 200 dışında bir durum kodu dönerse veya X-Robots-Tag başlığı ya da robots meta etiketiyle noindex verilmişse bozulur. Sayfa düzeyindeki veriye girmek için tüm uygunluk ölçütlerinin birlikte sağlanması gerekir. Kullanıcı ve origin ölçütünü sağlayıp sayfa ölçütünü sağlamayan deneyimler sayfa düzeyinden çıkar ama origin düzeyinde sayılmaya devam eder. Yani tek tek sayfa için "veri yok" yazarken origin için bir sonuç görmek mümkündür.

Toplama ve işleme

Deneyimler sayfa ve origin düzeyinde dağılımlara toplanır. URL'lerdeki sorgu dizileri ve parça tanımlayıcıları atılır; böylece bir sayfanın varyasyonları tek sayfa olarak gruplanır. Iframe içindeki deneyimler üst sayfaya eklenir. Ayrıca gizlilik amacıyla veriye rastgele gürültü katılır ve uygun olmayan boyut kombinasyonları nedeniyle trafiğinin yüzde yirmisinden fazlası dışarıda kalan sayfalar ya da origin'ler tamamen çıkarılır. Metriklerin çoğu yüzdelik olarak değil, histogramlar olarak yayımlanır.

28 günlük kayan pencere

CrUX API belgesi (yeni sekmede açılır), veriyi toplanmış metriklerin 28 günlük kayan ortalaması olarak tanımlar ve verinin her gün yaklaşık 04:00 UTC'de güncellendiğini yazar. PageSpeed Insights de gerçek kullanıcı metriklerinin önceki 28 günlük toplama dönemini kapsadığını söyler. Bunun üç pratik sonucu vardır. Birincisi, bir düzeltme yaptıktan sonra eski deneyimler pencereden çıkana kadar sonuç tam yansımaz. İkincisi, kısa süreli bir bozulma da yeni hükme bir süre taşınır. Üçüncüsü, bir kampanya ya da yayın günündeki değişim gün gün değil, ağırlıklı olarak haftalar içinde okunur.

75. yüzdelik ne demek?

CrUX API belgesi p75'i, sayfa yüklemelerinin yüzde yetmiş beşinin ilgili metriği bu değerde ya da daha iyi yaşadığı nokta olarak tanımlar. Yani değer bir ortalama değildir. Ziyaretçilerin dörtte biri bu değerden daha kötü bir deneyim yaşamış olabilir. PageSpeed Insights belgesi gerekçeyi şöyle açıklar: amaç sayfaların çoğunluk için iyi çalışmasını sağlamaktır; bu yüzden sayfalar daha zor cihaz ve ağ koşullarına karşı da değerlendirilir. Bir kullanıcı grubunun ortalaması iyi görünürken yavaş cihazlardaki ziyaretçilerin yaşadığı sorun bu şekilde görünür kılınır.

Kurgusal örnek: yüzdelik neden aldatabilir

Kurgusal örnek: bir haber sitesinde ziyaretçilerin çoğu yeni telefonlarla hızlı bağlantıdan giriyor, küçük bir bölümü ise eski cihazlarla yavaş mobil ağdan. Ortalama değer iyi görünür, fakat 75. yüzdelik hesabında yavaş grup yeterince büyükse hüküm "iyileştirme gerekli" çıkar. Bu örnekte sayı verilmedi; yalnızca yüzdelik mantığını gösteriyor. Sonuç: ortalamaya değil, dağılımın kuyruğuna bakın.

Search Console CWV Raporu ile PageSpeed Insights Farkı

İki araç aynı CrUX verisinden beslense de farklı birimlerde sunar ve farklı soruya yanıt verir. Aralarındaki farkı bilmeyen bir ekip, aynı sitenin iki ekranını birbiriyle çelişen iki rapor sanır.

Search Console: URL grupları ve site geneli

Search Console yardım sayfası (yeni sekmede açılır), Core Web Vitals raporunun verisinin CrUX raporundan geldiğini söyler. Rapordaki URL'ler benzer kullanıcı deneyimine sahip sayfa gruplarına ayrılır. Etiketler (Zayıf, İyileştirme gerekli, İyi) o cihaz türü için URL grubuna uygulanır; mobil ve masaüstü ayrı değerlendirilir. Dolayısıyla bir grup mobilde İyi, masaüstünde İyileştirme gerekli olabilir. Bir grubun durumu en kötü performans gösteren metriğin durumudur: LCP iyi olsa da CLS zayıfsa grup zayıf sayılır.

Bu bir yanlış okumaya açık noktadır. Raporda çok sayıda URL'nin "zayıf" göründüğünü görseniz bile bu her URL'nin tek tek ölçüldüğü anlamına gelmez; gruptaki sayfalar benzer deneyim paylaştığı için ortak bir hüküm alır. Düzeltme de tek tek URL'de değil, grubu oluşturan ortak şablonda, bileşende ya da üçüncü taraf komut dosyasında yapılır.

Search Console'da doğrulama

Yardım sayfasına göre bir sorunu düzelttikten sonra doğrulamayı başlatabilirsiniz. İzleme dönemi 28 gün sürer. Bu pencere boyunca sorun sitedeki hiçbir URL'de görülmezse sorun çözülmüş sayılır; görülürse doğrulama başarısız olur ve yeniden başlatılabilir. Aynı sayfa, doğrulamanın yeniden indeksleme tetiklemediğini de belirtir.

PageSpeed Insights: tek URL, iki ayrı kaynak

PageSpeed Insights belgesi (yeni sekmede açılır) iki ayrı veri bloğunu açıklar. Gerçek kullanıcı deneyimi bölümü alan verisidir ve önceki 28 günü kapsar. URL için yeterli veri yoksa araç origin düzeyine geri düşer; bu düzey sitenin tüm sayfalarındaki bütün kullanıcı deneyimlerini kapsar. Lighthouse bölümü ise verilen URL'yi simüle bir ortamda analiz eder ve performans, erişilebilirlik, en iyi uygulamalar ve SEO kategorileri için sonuç üretir.

Performans puanında 90 ve üstü iyi, 50 ile 89 arası iyileştirme gerekli, 50'nin altı zayıf sayılır. Bu puan laboratuvar verisinden gelir. Core Web Vitals değerlendirmesi ise farklı bir kuraldır: belgeye göre üç metriğin 75. yüzdelik değerlerinin tümü İyi ise toplam değerlendirme geçer. Yeterli INP verisi yoksa değerlendirme yalnızca LCP ve CLS'ye dayanır. PageSpeed Insights puanını nasıl yorumlayıp iyileştireceğinizi ayrı bir yazıda ele aldık: PageSpeed Insights puanı ne anlama gelir ve nasıl yükseltilir.

İki aracı yan yana koymak

Sayfa hızı çalışmasının geniş çerçevesi, ölçüm sırası ve optimizasyon adımları için sayfa hızı ve Core Web Vitals rehberine göz atabilirsiniz.

Laboratuvar ve Alan Verisi Neden Ayrışır

İki ölçümün farklı sonuç vermesi bir hata belirtisi değil, beklenen bir durumdur. Aradaki fark çoğunlukla kullanıcı koşullarının çeşitliliğinden ve ölçümün zamanlamasından gelir. web.dev'in laboratuvar ve alan verisi farkları makalesi (yeni sekmede açılır) nedenleri ayrıntılı sayar. Aşağıda bunları işe yarar gruplara ayırdık.

Koşul farkları

• Cihaz ve ekran boyutu: Farklı ekran boyutlarında görünür alandaki öğeler değişir. Laboratuvar tek bir cihazı taklit ettiği için çoğu kullanıcıdan farklı bir LCP öğesi seçebilir.
• Ağ ve cihaz çeşitliliği: Alan verisi çok geniş bir ağ ve cihaz yelpazesini içerir; laboratuvar tek bir sabit bağlantı ve cihaz kullanır.
• Coğrafya: Laboratuvar testi tek bir konumdan çalışır; gerçek kullanıcılar dünyanın farklı yerlerindedir.
• Önbellek: Laboratuvar testleri genellikle soğuk önbellekle yükler; geri dönen gerçek ziyaretçilerde kaynaklar çoğu zaman önbellektedir ve bu LCP, INP ve CLS'yi iyileştirebilir.

İçerik ve davranış farkları

• Kişiselleştirme ve A/B testleri: Hedefli reklamlar ya da deneyler hangi öğelerin yüklendiğini ve düzeni nasıl kaydırdığını değiştirir; laboratuvar çoğunlukla genel bir sürümü yükler.
• Paylaşılan URL'ler: Parça tanımlayıcılı adreslerle gelen kullanıcılarda LCP öğesi sayfanın daha aşağısında olabilir.
• Geri/ileri önbelleği (bfcache): Geri yüklenen sayfalar neredeyse anında açılır ve bu ziyaretler alan verisine girer; laboratuvar bunu hesaba katmaz.
• Kaydırma ve etkileşim: Alanda LCP ölçümü kullanıcı kaydırınca ya da etkileşime girince durur; laboratuvarda sayfa yüklemesi bitene kadar sürer. CLS ise alanda kaydırma ve etkileşimden sonra olan kaymaları da kapsar.
• Etkileşim zamanı: Laboratuvar, gerçek kullanıcının ne zaman etkileşime gireceğini bilemez; bu yüzden INP'yi doğru yakalayamaz.
• Boyutu belirtilmemiş geç yüklenen medya: Boyutu olmayan görsel ya da iframe, kullanıcı oraya kaydırınca kaymaya yol açar; laboratuvar testleri bunu sıklıkla kaçırır.

Makale bir noktayı özellikle vurgular: alan verisi tek bir sayı değil, bir sayı dağılımıdır ve alan araçları genellikle 75. yüzdeliği raporlar. Tek bir laboratuvar yüklemesi bu değerle eşleşmeyebilir. Makalenin önerisi de açıktır: çabalarınıza öncelik vermek için alan verisini kullanın; hata ayıklarken ve yayına almadan önce özellik denerken laboratuvar verisini kullanın. Alan puanları iyi, laboratuvar puanları kötü olsa bile başka iyileştirme fırsatları aramaya değer.

Mobil görünüm alanı ve dokunma gecikmesi

Makalede küçük ama sık gözden kaçan bir ayrıntı daha vardır: mobil görünüm alanı (viewport) tanımlanmamış sayfalarda tarayıcılar dokunmadan sonra 300 ms'lik bir gecikme ekleyebilir. Bu gecikme INP'yi bozar ama Toplam Engelleme Süresi'nde görünmez. Makale her zaman bir mobil viewport belirtmeyi önerir.

Kendi alan verinizi toplamak

CrUX yalnızca uygun kullanıcıları ve uygun sayfaları kapsar. web.dev makalesi, kendi alan verinizi toplamanın CrUX'tan daha ayrıntılı içgörü verebileceğini söyler. Bu seçenek özellikle CrUX'ın yetersiz kaldığı küçük siteler ve sayfa bazında teşhis gerektiren durumlar için değerlidir. Kendi ölçümünüzü kurarken kullanıcı verisi topluyorsanız çerez ve rıza kurallarına uygunluk ayrıca gözden geçirilmelidir.

Laboratuvarın hâlâ vazgeçilmez olduğu yerler

Alan verisi nedeni değil sonucu gösterir. Yavaş LCP'nin hangi görselden, hangi sunucu gecikmesinden ya da hangi engelleyici kaynaktan geldiğini bulmak için kontrollü ve tekrarlanabilir bir test gerekir. Makale ayrıca laboratuvar verisinin, yavaş ağdaki ya da düşük özellikli cihazdaki, sayfayı hiç açamayan kullanıcıları fark etmek için de kullanılabileceğini söyler. Yani iki veri rakip değildir; biri hangisinin sorunlu olduğunu, diğeri neden sorunlu olduğunu gösterir.

Veri Yok veya Yetersiz: Küçük Sitelerde Ne Yapılır

Yeni bir site, düşük trafikli bir blog ya da sınırlı sayıda kullanıcıya hizmet veren bir kurumsal site Search Console'da "yeterli veri yok" durumuyla karşılaşabilir. Bu durum bir ceza değil, ölçümün istatistiksel anlam taşıyacak kadar kullanıcı bulunmaması demektir.

Neden veri görünmeyebilir?

• Popülerlik eşiği: CrUX belgeleri sayfa ve origin için yeterince büyük ziyaretçi sayısı şartı koşar ve tam sayıyı açıklamaz.
• Keşfedilebilirlik: 200 dışındaki durum kodu ya da noindex kullanan sayfalar sayfa düzeyindeki veriye giremez.
• Kullanıcı uygunluğu: İzleyicileriniz ağırlıkla iOS Chrome ya da Edge kullanıyorsa, uygun kullanıcı sayısı düşük kalabilir.
• Yeni mülk: Search Console yardım sayfası, yeni bir mülkte CrUX verisinin görünmesinin birkaç gün sürebileceğini söyler.
• Yetersiz LCP ve CLS verisi: Search Console, yeterli LCP ve CLS verisi olmayan URL'leri rapordan çıkarır.

Origin düzeyine bakın

Sayfa düzeyinde veri yoksa PageSpeed Insights origin düzeyine geri düşer. Origin verisi sitenin tüm sayfalarının birleşimidir ve çoğu zaman daha kolay oluşur. Bu veri, hangi sayfanın sorunlu olduğunu söylemez ama sitenin genel durumuna dair kaba bir fikir verir. CrUX API'ye göre origin verisinde sitedeki bütün sayfalar birlikte toplanır; tek bir ağır şablon ortalamayı aşağı çekiyor olabilir. Bunun için sayfa gruplarını ayrı ayrı laboratuvarda deneyin.

Veri yokken izlenecek yol

1. Laboratuvar ölçümünü düzenli yapın: Ana şablonlar için (ana sayfa, kategori, makale, ürün) belirli bir cihaz profili ve ağ koşuluyla Lighthouse ölçümü alın ve sonuçları bir tabloda kaydedin.
2. Bilinen sorunları ilk günden önleyin: Görsellerde boyut belirtin, mobil viewport tanımlayın, geç yüklenen medya için yer ayırın, ağır üçüncü taraf betiklerini sayfayı engellemeyecek biçimde yükleyin.
3. Kendi alan ölçümünüzü kurun: Hafif bir gerçek kullanıcı ölçümü, CrUX'ın göremediği sayfaları da kapsar. Gizlilik ve rıza gereklilikleri bu aşamada gözden geçirilmelidir.
4. Trafik büyüdükçe raporu yeniden kontrol edin: Veri çoğu zaman bir eşiğin aşılmasıyla görünür hale gelir.
5. Dizinlenebilirliği doğrulayın: Sayfaların 200 dönmesi ve noindex olmaması hem arama görünürlüğü hem CrUX uygunluğu için ön koşuldur.

Kurgusal örnek: yeni bir butik blog

Kurgusal örnek: yeni açılmış bir butik blog, ilk haftalarda Search Console'da Core Web Vitals raporunda hiçbir URL görmüyor. Sahibi bunu sorun sanıp sürekli kurcalamak yerine, yazı şablonunun mobil Lighthouse sonuçlarını kaydediyor, görsellerin boyutlarını belirtiyor ve yorum eklentisinin yüklemeyi engellediğini fark edip erteliyor. Birkaç ay sonra trafik eşiği aştığında rapor ilk URL gruplarını gösteriyor ve zaten temiz bir başlangıç noktası oluyor. Örnek rakam içermez; yalnızca sürecin sırasını anlatır.

Veri yokken yapılmaması gerekenler

Eksik raporu "site hızlı" diye yorumlamayın, aynı şekilde "site yavaş" diye de yorumlamayın. Yetersiz veri hüküm üretmez. Ayrıca laboratuvar puanını alan verisinin vekili gibi göstererek müşteriye "Core Web Vitals geçiyor" demeyin; geçme kararı alan verisindeki 75. yüzdelik üzerinden verilir.

Rapora Karar Çevirme: Hangi Sorun Önce

Rapor okumak amaç değil, öncelik sırası çıkarmak içindir. Aşağıdaki akış, alan verisini önce, laboratuvar verisini sonra kullanır ve ajans raporlamasında da uygulanabilir.

1. Cihaz türünü ayırın

Search Console mobil ve masaüstünü ayrı raporlar. Önce trafiğinizin ağırlıklı geldiği cihaz türüne bakın; bu bilgiyi analitiğinizden alın. Bir grup masaüstünde İyi iken mobilde Zayıfsa, öncelik mobildir.

2. En kötü metriği belirleyin

Grup durumu en zayıf metriğe göre belirlendiği için sorunlu grubun hangi metrikte takıldığını öğrenin: LCP, INP ya da CLS. Üç metriğin sebepleri farklıdır; LCP genellikle ana içerik öğesinin geç yüklenmesiyle, INP etkileşim sırasında ana iş parçacığının meşgul olmasıyla, CLS ise boyutu belirtilmemiş öğelerin sonradan yerleşmesiyle ilgilidir. Bu eşleşmeler genel bilgidir; her sitede neden farklı çıkabilir.

3. Grubu ortak şablona bağlayın

Search Console'daki sorunlu grubun örnek URL'lerine bakıp ortak şablonu bulun: makale, kategori, ürün detay, arama sonucu. Düzeltmeyi tek sayfada değil şablonda yapın, böylece birçok URL'ye aynı anda etki edersiniz.

4. Laboratuvarda nedeni bulun

Sorunlu şablondan örnek bir URL'yi PageSpeed Insights ve Lighthouse ile çalıştırın. Alan verisinin sorun gösterdiği metriği laboratuvarda yeniden üretmeye çalışın. INP için laboratuvarın sınırı olduğunu unutmayın; gerçek etkileşim verisi ve DevTools profilleme birlikte kullanılmalıdır.

5. Düzeltin, doğrulayın, bekleyin

Değişikliği yayına alın, Search Console'da doğrulamayı başlatın ve 28 günlük pencerenin tamamlanmasını bekleyin. Pencere dolmadan "işe yaramadı" kararı vermek en sık yapılan hatadır.

Öncelik matrisi

Reklam ve üçüncü taraf etkisi

Reklam gösteren sitelerde alan verisi çoğunlukla reklam yerleşiminden etkilenir; reklam yüklenince düzenin kayması CLS'yi, ağır reklam betikleri INP'yi bozabilir. Laboratuvar testinde reklamlar farklı yüklenebileceği için sorun orada görünmeyebilir. Bu dengeyi reklam ve Core Web Vitals dengesi yazısında ayrıca ele aldık.

Ajans raporunda neyi göstermeli?

Müşteriye sunulan raporda tek bir puan yerine şunları gösterin: cihaz türüne göre Search Console durumu, sorunlu URL grubunun metrik adı, düzeltmenin yapıldığı tarih ve doğrulamanın başladığı tarih, ayrıca laboratuvar bulgusu. Rapor bu şekilde "ne gördük, neden, ne yaptık, ne zaman netleşir" sırasını izler. Sıralama etkisi vaat eden cümle kurmayın; Core Web Vitals sayfa deneyimi sinyalinin bir parçasıdır ve kaynak belgeler etkinin büyüklüğünü sayıyla tarif etmez.

Sık Yapılan Okuma Hataları

• Laboratuvar puanını CrUX hükmü sanmak: 90 üstü puan, Core Web Vitals değerlendirmesinin geçtiği anlamına gelmez. Geçme kararı alan verisindeki 75. yüzdelikten çıkar.
• Origin verisini sayfa verisi gibi okumak: Origin düzeyi tüm sayfaları birleştirir; belirli bir URL hakkında hüküm vermez.
• Bir günlük değişime anlam yüklemek: Veri 28 günlük kayan bir pencerededir; günlük dalgalanma ya da tek bir yayın etkisi gecikmeli yansır.
• Bütün ziyaretçileri temsil ettiğini varsaymak: CrUX uygun kullanıcıları ve uygun sayfaları kapsar; iOS Chrome ve diğer Chromium tarayıcılar dışarıdadır.
• Ortalamaya bakmak: Hedef değer yüzdelik değeridir; yavaş kuyruk ihmal edilirse bir kullanıcı grubu görünmez kalır.
• Tek URL'yi düzeltip grubu unutmak: Search Console URL grupları ortak deneyimi paylaştığı için çözüm şablon düzeyinde olmalıdır.
• Lighthouse'ta INP aramak: Lighthouse INP'yi ölçmez; TBT'ye bakılır ve gerçek INP için alan verisi gerekir.
• Doğrulamayı yeniden indeksleme sanmak: Doğrulama yalnızca izleme penceresidir, yeniden indeksleme tetiklemez.

Sıkça Sorulan Sorular

CrUX nedir ve verisi kimin tarayıcısından gelir?

CrUX, Chrome kullanan gerçek ziyaretçilerin deneyimini yansıtan, Google'ın Web Vitals programına ait bir veri kümesidir. Veri, kullanım istatistiği raporlamayı açmış ve tarayıcı geçmişini eşitlemiş kullanıcılardan toplanır; masaüstü Chrome ve Android Chrome kapsama girerken iOS'taki Chrome ve diğer Chromium tarayıcılar dışarıda kalır. Bu yüzden CrUX tüm ziyaretçilerinizin birebir kopyası değil, uygun kullanıcıların örneğidir.

Alan verisi ile laboratuvar verisi arasındaki en önemli fark nedir?

Alan verisi gerçek kullanıcıların farklı cihaz, ağ ve konumlarda yaşadığı deneyimin dağılımıdır; laboratuvar verisi ise tek bir cihazda ve sabit ağ koşulunda yapılan simüle bir yüklemenin sonucudur. Öncelik belirlemek için alan verisi, hata ayıklamak ve yayından önce denemek için laboratuvar verisi kullanılır. Laboratuvar ölçümü alan ölçümünün yerine geçmez.

Search Console'da Core Web Vitals raporunda neden hiç URL görünmüyor?

Rapor, yeterli LCP ve CLS verisi olmayan URL gruplarını dışarıda bırakır ve yeni bir mülkte CrUX verisinin görünmesi birkaç gün sürebilir. Sayfalar yeterince popüler değilse, herkese açık keşfedilebilir değilse ya da 200 durum kodu dönmüyorsa da CrUX'a girmez. Bu durumda rapor boş kalır; sitenin hızlı ya da yavaş olduğu anlamına gelmez.

PageSpeed Insights puanı yeşilken Search Console neden kırmızı gösteriyor?

PageSpeed Insights'taki performans puanı Lighthouse'un laboratuvar ölçümüdür; Search Console ise son 28 günün gerçek kullanıcı verisinden gelir. İkisi farklı sorulara yanıt verir ve farklı sonuç vermesi olağandır. Değerlendirme için alan verisindeki üç metriğin 75. yüzdelik değerlerine bakılır; puan bu hükmün yerine geçmez.

Düzeltme yaptım, rapor ne zaman değişir?

CrUX verisi 28 günlük kayan bir ortalamadır, bu yüzden iyileşme dağılıma kademeli olarak yansır. Search Console'da doğrulama başlatırsanız izleme dönemi 28 gün sürer ve sorun bu pencerede hiçbir URL'de görülmezse çözülmüş sayılır. Tek günlük bir dalgalanmaya göre karar vermeyin.

Sonuç

Alan verisi ile laboratuvar verisi birbirine rakip değil, farklı iki soruya cevap veren iki ölçümdür. Alan verisi, gerçek ve uygun Chrome kullanıcılarının son 28 günde yaşadığı deneyimin 75. yüzdelikteki özetidir ve önceliğe karar vermenin dayanağıdır. Laboratuvar verisi tekrarlanabilir bir simülasyondur ve nedeni bulmanın, düzeltmeyi sınamanın aracıdır. Search Console URL grupları ve en zayıf metrik üzerinden size nerede sorun olduğunu söyler; PageSpeed Insights tek bir URL için hem alan hem laboratuvar tarafını yan yana verir. Veri yoksa hüküm de yoktur; bu durumda laboratuvar ölçümü, önleyici iyileştirme ve kendi alan ölçümünüzle ilerleyin. Hiçbir adım belirli bir sıralama sonucunu garanti etmez; amaç gerçek ziyaretçi için ölçülebilir biçimde daha iyi bir deneyimdir.

Raporlama ve teknik rehber metinlerinizi daha düzenli üretmek istiyorsanız, Akua Adforce'ta SEO içerik yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.