Core Web Vitals Raporu (Google Search Console)

TL;DR — Google Search Console’daki Core Web Vitals raporu, sayfalarınızın Google’ın üç hız ve kararlılık metriğinde (LCP, INP, CLS) gerçek ziyaretçiler için nasıl performans gösterdiğini açıklar. Benzer sayfalar gruplarına ayrılan gerçek Chrome kullanıcı verilerini kullanır ve Mobile ile Desktop sekmelerini ayrı tutar. Sayfaları tek tek denetleyen bir hız testi değil, site genelinde önceliklendirme aracıdır. Küçük veya yeni bir siteniz varsa hiç veri göstermeyebilir. Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: 2026-07-14 Google Search Console: Core Web Vitals report Evidence for this claim The current Core Web Vitals are LCP, INP, and CLS, evaluated at the 75th percentile over field data. Scope: Current web.dev metric set and assessment method. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Core Web Vitals raporu nedir?

Bu raporu Google Search Console’daki Experience bölümünde bulabilirsiniz. Google’ın kendi tek cümlelik açıklamasına göre rapor “shows how your pages perform, based on real world usage data (sometimes called field data).”

Başta netleştirilmesi gereken önemli nokta şudur: Bu bir rapordur, metriklerin kendisi değildir. Core Web Vitals — LCP, INP ve CLS — sayfanızın gerçek bir ziyaretçiye nasıl hissettirdiğini ölçen üç metriktir (ana içeriğin ne kadar hızlı yüklendiği, sayfanın bir dokunuşa ne kadar hızlı yanıt verdiği ve yükleme sırasında öğelerin ne kadar yer değiştirdiği). Bu metrikler sitenin başka bölümlerinde ayrıntılı olarak tanımlanmıştır. Bu makalenin konusu ise rapordur: Search Console’da bu sayıları gösterip düzenleyen araç.

Veriler nereden gelir?

Rapor bir hız testi çalıştırmaz. Sayfalarınızı ziyaret eden gerçek Chrome kullanıcılarının anonimleştirilmiş zamanlama verilerini içeren Chrome User Experience Report’tan (CrUX) alan verilerini alır. Bu, sayfanızı kontrollü bir ortamda bir kez yükleyen PageSpeed Insights gibi bir laboratuvar testinden farklıdır. Alan verileri, gerçek kişilerin yaşadığı deneyimi son 28 günün ortalamasıyla gösterir.

Rapor nasıl düzenlenir?

URL’lerin nasıl gruplandırıldığı hakkında bilinmesi gereken üç nokta vardır:

• Mobile ve Desktop ayrı sekmelerdir. Bir sayfa aynı anda mobilde “Good”, masaüstünde “Poor” olabilir. Bu verilerin ortalaması hiçbir zaman birlikte alınmaz.
• Üç durum grubu vardır: Poor, Need improvement ve Good. Bir URL’nin durumunu en kötü metriği belirler; tek bir kötü değer tüm sayfanın durumunu düşürür.
• URL’ler tek tek puanlanmak yerine gruplandırılır. Google benzer sayfaları (genellikle aynı sayfa şablonunu kullananları) aynı gruba yerleştirir. Bu nedenle çoğu zaman tek bir sorunun birçok URL’yi aynı anda etkilediğini görürsünüz.

Çoğu kişinin yanlış anladığı nokta

Bu rapor, belirli bir sayfanın yavaş olup olmadığını güvenilir biçimde söyleyemez. Google bunu açıkça belirtir: Rapor “not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” Site genelindeki şablon düzeyindeki sorunları saptamak için kullanılır. Tek bir sayfayı kontrol etmek için PageSpeed Insights veya URL Inspection aracını kullanın.

Baştan bilinmesi yararlı olan iki nokta daha vardır:

• “No data available” yaygın bir durumdur ve genellikle sayfalarınızda sorun olduğu anlamına gelmez. Search Console mülkünüz çok yenidir veya görüntülediğiniz cihazda (mobile ya da desktop) Google’ın raporlama eşiğini aşacak kadar Chrome trafiği yoktur.
• Rapor yaklaşık bir ay geriden gelir. 28 günlük ortalama kullandığı için bugün yayımladığınız bir düzeltmenin etkisi burada haftalar boyunca tam olarak görünmez. Daha hızlı geri bildirim için PageSpeed Insights’ı kullanın.

URL gruplandırmasının nasıl çalıştığı, sonuçların neden PageSpeed Insights ile eşleşmediği, doğrulama iş akışı ve FID’ye ne olduğu gibi tüm ayrıntıları mı öğrenmek istiyorsunuz? Advanced sekmesine geçin.

TL;DR — Core Web Vitals raporu, dizine eklenmiş URL’leriniz için CrUX alan verilerini (28 günlük hareketli dönem, 75. yüzdelik dilim) gösterir; yeni bir şey hesaplamaz. URL’leri cihaza (bağımsız Mobile/Desktop sekmeleri), duruma (Poor / Need improvement / Good; en kötü metrik belirleyicidir) ve URL grubuna (aynı durumu paylaşan, benzer şablonlu sayfa kümeleri) göre düzenler. Yalnızca dizine eklenmiş URL’ler görünür ve tüm URL’ler değil, bir örneklem sunulur. Bir URL grubu gizliliği koruyarak raporlanamayacak kadar küçükse Google daha üst düzey bir kaynak grubuna döner. Bu grup da eşiği aşamazsa “No data available” mesajını görürsünüz. Sonuçlar PageSpeed Insights ile eşleşmez (grup ile tek URL farkı; GSC URL parametrelerini ayrı tutarken PSI bunları kaldırır). Araç tek URL sorguları için değil, site genelinde önceliklendirme içindir. INP bir Core Web Vital olduğunda, 12 Mart 2024’te FID kaldırıldı; PSI/CrUX’taki altı aylık geçiş döneminin aksine GSC bunu hemen kaldırdı. Önce “Poor” sorunlarını düzeltin, Start Tracking ile doğrulayın ve alan verilerinin yaklaşık bir ayda güncellenmesini bekleyin. Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: 2026-07-14 Google Search Console: Core Web Vitals report Evidence for this claim The current Core Web Vitals are LCP, INP, and CLS, evaluated at the 75th percentile over field data. Scope: Current web.dev metric set and assessment method. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Metriklerin yeniden tanımı değil, bir rapordur

Bu makale için en yararlı çerçeve şudur: Core Web Vitals raporu yeni bir ölçüm değil, mevcut verilere açılan bir penceredir. Google bunu açıkça şöyle belirtir: “the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: 2026-07-14 Google Search Console: Core Web Vitals report

Dolayısıyla raporda hiç laboratuvar verisi yoktur: Lighthouse puanları veya sentetik testler içermez. Verilerin %100’ü alan verisidir; gerçek Chrome kullanıcılarından gelen, cihazlara göre ayrılmış 28 günlük hareketli dönemin 75. yüzdelik dilimidir. Metrik tanımları, eşikler ve sıralama sinyalindeki ağırlık Core Web Vitals sözlüğü ile web-vitals konusunda ele alınır; bunları burada yeniden türetmeyeceğim. Buradaki konu araçtır.

Yalnızca dizine eklenmiş URL’ler ve yalnızca bir örneklem

İnsanların gözden kaçırdığı üç kapsam kuralı vardır. Birincisi ve en temel olanı: Bir URL grubu ancak hem LCP hem de CLS için veri eşiğini aştığında görünür. Grup her ikisi için de yeterli raporlama verisine sahip değilse başarılı olarak işaretlenmek yerine rapordan tamamen çıkarılır. İkincisi: “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” Bu nedenle raporu kapsamlı bir denetim olarak görmeyin. Üçüncüsü, diğer GSC raporlarına alışkın kişileri şaşırtan ince bir ayrıntıdır: “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” Search Console raporlarının çoğu verileri standart URL altında birleştirir; bu rapor birleştirmez.

Mobile ve Desktop bağımsız veri kümeleridir

Rapor her şeyi cihaza göre ayırır ve iki sekme tamamen bağımsızdır; ortalamaları birlikte alınmaz. Farklı cihazları, ağları ve CPU sınıflarını yansıtan ayrı CrUX veri kümeleri olduklarından bir URL grubu aynı anda mobilde Good, masaüstünde Need improvement olabilir. Her zaman iki sekmeyi de kontrol edin; birindeki “Good” özeti, diğerindeki “Poor” grubunu gizleyebilir.

Durum: En kötü metrik belirleyicidir

Her URL grubu Poor, Need improvement veya Good durumlarından birine girer. Grubun durumunu en kötü performans gösteren metriği belirler. LCP ve INP değeri iyi, CLS değeri kötü olan bir grup “Poor” sayılır. Bu “en kötü metrik belirleyicidir” kuralı, tek bir kararsız düzen öğesinin diğer yönlerden hızlı bir şablonun durumunu neden düşürebildiğini açıklar.

Temel eşikler (“Good” için p75 düzeyinde LCP ≤ 2,5 s / INP ≤ 200ms / CLS ≤ 0,1), Core Web Vitals sözlüğünde ele alınan metrik tanımlarıdır. Şunu da belirtmek gerekir: Araştırmam sırasında yayındaki Search Central belgeleri hâlâ bu özgün değerleri listeliyordu. Google’ın “Good” LCP eşiğini sessizce 2,0 saniyeye düşürdüğü veya 2025’in sonlarındaki bir çekirdek güncellemenin Core Web Vitals’ı çok daha büyük bir sıralama faktörü hâline getirdiği iddialarını görmüş olabilirsiniz. Bunların hiçbirini Google’a ait bir kaynakla doğrulayamadım ve belgeler bu iddialarla çelişiyor. Bunları söylenti olarak değerlendirin.

URL grupları: Temel mekanizma

Bu, raporun ayırt edici özelliği ve PageSpeed Insights’ın tek URL alışkanlığından gelen kişiler için en büyük zihinsel model değişikliğidir. Google şöyle açıklar: “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.”

John Mueller 2021’de mekanizmayı şöyle açıklamıştı: “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” Daha da önemlisi, grubun verileri kendi verisi olmayan bir URL’nin yerine kullanılabilir: “If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.”

Raporun gerçekte tek bir hatadan kaynaklanan bir durumda neden endişe verici görünebildiğini de bu açıklar. Mueller şöyle devam eder: “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” Tek bir şablon kusuru, binlerce URL’nin işaretlenmesine yol açabilir.

Gruplandırmanın can sıkıcı değil, yararlı olmasının nedeni tam olarak budur. Ahrefs’in Core Web Vitals rehberinde şöyle yazmıştım: “This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” PageSpeed Insights rehberinde de şöyle yazdım: “The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” Şablonu bir kez düzeltirseniz tüm grubu düzeltirsiniz. Bunu Outside Communications röportajında şöyle ifade ettim: “Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.”

Gizlilik eşiği ve kaynak grubu geri dönüşü

Gruplandırma yalnızca kolaylık sağlamaz; aynı zamanda bir gizlilik gereğidir. Google: “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” Dolayısıyla sıra şöyledir: URL grubu → kaynak grubu → hiçbir şey. Kaynak grubu bile eşiği aşamadığında “No data available” mesajını görürsünüz. Düşük trafikli sitelerin geniş, kaba gruplar veya hiç veri görmemesinin mekanik nedeni budur.

”Poor” bir grup neden hızlı sayfalar içerebilir?

Durum, grubun tamamına 75. yüzdelik dilimde uygulandığından hızlı bir URL yavaş bir gruba dâhil olabilir. Poor grubunda bulunmak, o URL’nin yavaş olduğunu kanıtlamaz; kümenin bir bütün olarak sorunlu olduğu anlamına gelir. Her üyeyi suçlu saymayın; analiz birimi gruptur.

Raporu okumak: Grafik ve tablo

Çoğu üçüncü taraf rehberin atladığı, gerçekten kafa karıştırıcı bir ayrıntı vardır. Giriş grafiği ile sorun tablosu farklı sayım yapar: “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” Bu nedenle bir Poor ve bir Need-improvement sorunu olan URL grafikte bir kez (Poor olarak), tabloda ise iki satırda da görünür. Toplamların eşleşmemesinin nedeni budur; bu bir hata değil, tasarım gereğidir. Bir soruna tıkladığınızda, benim ifademle “gives you a breakdown of page groups that are impacted” ve gösterim sayısına göre sıralanmış örnek URL’leri görürsünüz.

Düzeltmeleri doğrulamak: Start Tracking iş akışı

Raporda gözden kaçırılması kolay yerleşik bir doğrulama döngüsü vardır. Google: “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” Bu işlem sorun için 28 günlük bir izleme oturumu başlatır. Google sorunu anında yeniden kontrol etmek yerine bu dönem boyunca grubun alan verilerinin birikmesini izler. Sürecin nasıl sonuçlandığıyla ilgili üç nokta önemlidir: Dönem boyunca başarısız olmaya devam eden tek bir etkilenen URL bile tüm sorunun başarılı sayılmasını engelleyebilir; sorun düzeyinde Not started / Started / Looking good / Passed / N/A / Failed, URL düzeyinde ise Pending / Passed / Failed durumlarını görürsünüz; ayrıca Start Tracking’e tıklamak yeniden dizine eklemeyi tetiklemez veya başka bir etkin tarama davranışı başlatmaz. Bu yalnızca Google’ın zaten topladığı veriler üzerindeki bir izleme işaretidir. Bir düzeltmenin alan verilerine yansıdığını doğrulamanın doğru yolu budur; toplu grafiğe bakıp sonuç ummak değildir.

Core Web Vitals raporu ile PageSpeed Insights karşılaştırması

Bu iki araç aynı CrUX kaynağından veri alır ancak verileri farklı biçimde sunar. Bu nedenle bir URL için sonuçları çoğu kez uyuşmaz. Belgelenmiş iki neden vardır:

• Grup ve tekil URL farkı. Google: “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” Tek bir URL grubunda aykırı değer olabilir; dolayısıyla grup durumu ile tam olarak o URL’nin PSI değeri eşleşmeyebilir.
• URL parametreleri. “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” “Bu iki araç neden aynı sonucu vermiyor?” şikâyetlerinin çoğunu tek başına bu fark açıklar.

“Alan verisi” ve “laboratuvar verisi” terimleri gevşek kullanıldığından veri kapsamı farkını da netleştirmek gerekir. GSC raporu yalnızca gruplandırılmış CrUX alan verilerini içerir; başka hiçbir şey içermez. PageSpeed Insights üç ayrı unsuru birleştirir: URL düzeyinde CrUX alan verisi, URL’nin yeterli verisi olmadığında kaynak düzeyinde CrUX alan verisine geri dönüş ve canlı bir Lighthouse laboratuvar çalıştırması. PSI rehberinde belirttiğim gibi: “PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” GSC raporunda bu laboratuvar katmanının hiçbiri yoktur; yalnızca alan verisi vardır.

Benim gerçek iş akışım ve rakip makalelerin çoğunun atladığı pratik ipucu şudur: PSI’ın laboratuvar verilerinde hızlıca teşhis edip doğrulayın; yavaş gelen gerçek durumu GSC’de onaylayın. PSI rehberinde şöyle yazdım: “The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” Değişikliğin yararlı olup olmadığına ilişkin anında laboratuvar geri bildirimi alırsınız; ardından GSC alan verilerinin sonraki haftalarda güncellenmesini beklersiniz.

”No data available” ve düşük trafikli siteler

Google’ın kendi açıklaması şöyledir: “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” CrUX’un bir uygunluk eşiği vardır. Herhangi bir alan verisinin görünmesi için URL’nin veya kaynağın yeterli Chrome trafiğine sahip olması gerekir.

Bu ne kadar yaygın? Oldukça yaygın. CrUX’u 43,66 M benzersiz Site Audit sayfasıyla eşleştirdiğim Ocak 2022 tarihli çalışmamda, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” Bu çalışma GSC’nin kendisini değil, GSC raporunun da kullandığı ham CrUX veri kümesini inceledi ve sayı Ocak 2022’ye aittir. Bu nedenle bunu güncel bir oran değil, ölçeği gösteren bir değer olarak ele alın. Temel nokta geçerlidir: Web’deki sayfaların çoğu alan verisi oluşturacak kadar Chrome trafiği almaz. Raporun kaynak düzeyinde gruplandırmaya dayanmasının ve birçok sitenin hiçbir şey görmemesinin nedeni tam olarak budur. Siz de bu sitelerden biriyseniz bu, sitenizin sorunsuz olduğunu göstermez; tekil URL’leri PageSpeed Insights veya Lighthouse ile test edin.

FID kaldırıldı: Mart 2024’te ne değişti?

Eski eğitimler hâlâ yanlış gösterdiği için bunu tam olarak doğru anlamak gerekir. Interaction to Next Paint (INP), 12 Mart 2024 tarihinde Core Web Vital olarak First Input Delay’in (FID) yerini aldı. Neredeyse hiç kimsenin ele almadığı Search Console’a özgü ayrıntı, Chrome ekibinin web.dev announcement açıklamasında yer alır: “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” Dolayısıyla GSC, FID’yi geçiş dönemi olmadan hemen kaldırırken PSI ve CrUX altı ay daha göstermeye devam etti. Bir Search Console ekran görüntüsünde FID görüyorsanız görüntü Mart 2024’ten öncesine aittir.

Page Experience raporuna ne oldu?

Bu, gerçek ve hâlâ sıkça aranan bir kafa karışıklığıdır. Google, Core Web Vitals’ı HTTPS ve diğer UX sinyalleriyle birleştiren eski toplu kontrol paneli olan bağımsız Page Experience raporunu 19 Nisan 2023 tarihinde Search Console’dan kaldırdı. Core Web Vitals raporu ile HTTPS raporu ise bağımsız raporlar olarak varlığını sürdürüyor. Yalnızca birleşik özet kaldırıldı. “Page Experience” kontrol panelini arayıp bulamamanızın nedeni budur; onun altındaki iki rapor hâlâ mevcuttur. (Performance raporu ve Page Indexing raporu gibi ilişkili raporlar, Search Console kapsamınızın geri kalanını ele alır.)

Raporun bulduğu sorunları önceliklendirme ve düzeltme

Google kendi rehberini teknik olmayan kullanıcılar ve geliştiriciler için iki kola ayırır; bu da raporun çok farklı kitlelerce okunduğunu gösterir. Herkes için önceliklendirme kuralı şudur: Önce “Poor”, ardından “Need improvement” sorunlarını düzeltin. Geliştiriciler için grup içindeki URL’ler gösterim sayısına göre azalan sırada listelenir; en üsttekiler grup durumunu en fazla etkiler.

Google’ın belirttiği yaygın sayfa düzeyindeki düzeltmeler doğrudan ama gerçektir: “Reduce your page size: best practice is less than 500KB for a page and all its resources.” Bunun ötesinde LCP, INP ve CLS’yi iyileştirme yöntemleri ilgili metrik konularına aittir; bunları burada tekrarlamayacağım. Raporun görevi, hangi şablonları düzeltmeniz gerektiğini söylemektir; bunları sizin yerinize düzeltmek değildir.

Hiçbir şeye dokunmadığım hâlde durum neden değişti?

Bu son derece yaygındır ve genellikle bir hata değildir. Google’ın sorun giderme açıklaması: “If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” Trafik dağılımındaki değişiklikler, CDN veya görsel sunucusu gecikmesindeki bir değişim ya da geniş çapta benimsenen bir tarayıcı güncellemesi, zaten sınıra yakın URL grubunu bir anda eşiğin ötesine taşıyabilir. Çünkü rapor, 28 günlük bir p75 toplamasıdır.

Bazen uygun URL sayısı da dalgalanır. Uygun verisi görüntülenen URL sayısının (özellikle mobilde) düştüğü Temmuz 2025 döneminde John Mueller bu hareketi sorun olarak değil, normal örneklem büyüklüğü değişimi olarak nitelendirdi. Bu raporların Google’ın bir site hakkında bildiklerinden alınan örneklere dayandığını, örneklem büyüklüklerinin değiştiğini ve bunun bir soruna işaret etmediğini belirtti. Core Web Vitals projesinde çalışan Google’dan Barry Pollard da düşüşü kabul ederek bir düzeltmenin dağıtılmakta olduğunu söyledi. Çıkarılacak ders şudur: Uygun URL sayısı ile temel metrik kalitesi iki farklı şeydir; örneklemin değişmesi sayfalarınızın yavaşladığı anlamına gelmez.

Rapor sıralamaları etkiler mi?

Rapor, Google’ın sıralama sistemlerinin hesaba katabileceği aynı alan verilerini yansıtır. Ancak Google temsilcileri Core Web Vitals’ı sürekli olarak içerik alaka düzeyinin yanında küçük, eşitliği bozan düzeyde bir sinyal olarak tanımlamıştır. Sıralama ağırlığına ilişkin kapsamlı tartışma Core Web Vitals sözlüğünde yer aldığından burada tek cümleyle yetineceğim. Açık görüşüm şu: Bu eşiklere ulaşmanın bugün büyük bir fark yarattığını düşünmüyorum; ancak Google zaman içinde mobile-friendliness ve HTTPS’te yaptığı gibi bu sinyale daha fazla ağırlık verebilir. Önemsenmesi gereken, gözden kaçan ve sıralamayla ilgisi olmayan başka bir neden de vardır: Daha hızlı sayfalar daha fazla kayıtlı veri (CrUX ve kendi analizleriniz) toplar; çünkü sayfa yüklenmeden ayrılan kullanıcıların sayısı azalır. Bu metrikleri iyileştirmenin başlıca yararı, gerçekten daha iyi bir deneyimi temsil etmesidir.

Bing hakkında kısa bir not

Bing Webmaster Tools içinde URL gruplandırması kullanan, CrUX tarzı özel bir Core Web Vitals raporunun doğrudan karşılığı yoktur. Bing, raporlamasını alan verilerine dayalı bir Core Web Vitals dökümü yerine Performance Report (tıklamalar/gösterimler) ve Site Scan teknik denetimi etrafında şekillendirir. Bing rehberlerinde Core Web Vitals tarzı metriklere değinir ancak Google’ınkiyle karşılaştırılabilir, gruplandırılmış bir alan verisi raporu yayımlamamıştır. Bing’in araçları oldukça sık değiştiğinden bu konu sizin için önemliyse güncel Bing Webmaster Tools belgelerini kontrol edin.

Bu raporun yeri

Bu, Google Search Console’daki çeşitli raporlardan biridir. Performance raporu aramada nasıl performans gösterdiğinizi (tıklamalar, gösterimler, konum), Page Indexing raporu ise kapsam ve dizine ekleme tarafını ele alır. Bu raporun gösterdiği Core Web Vitals ve CrUX metrikleri ile laboratuvar verisi eşlikçisi PageSpeed Insights, web performansı kümesinde ayrı ayrı ayrıntılı olarak incelenir. Evidence for this claim Search Console's Core Web Vitals report groups URL performance using real-world CrUX data and may lack data for low-traffic URLs or origins. Scope: Current Search Console Core Web Vitals report. Confidence: high · Verified: 2026-07-14 Google Search Console: Core Web Vitals report

AI özeti

Advanced sürümün kısa özeti:

• Bu bir rapordur, metriklerin kendisi değildir. Core Web Vitals raporu (GSC → Experience), dizine eklenmiş URL’ler için CrUX alan verilerini (28 günlük hareketli dönem, 75. yüzdelik dilim) gösterir. Yeni bir şey hesaplamaz ve laboratuvar verisi içermez.
• Üç gruplandırma: cihaz (bağımsız Mobile/Desktop sekmeleri; ortalamaları birlikte alınmaz), durum (Poor / Need improvement / Good; en kötü metrik belirleyicidir) ve URL grubu (aynı durumu paylaşan benzer şablonlu sayfa kümeleri).
• Temel birim tekil URL değil, URL grubudur. Tek bir şablon düzeltmesi binlerce işaretli URL’yi temizleyebilir (Mueller). “Poor” grubu hızlı sayfalar da içerebilir.
• Gizlilik sıralaması: URL grubu → kaynak grubu → “No data available.” Yeni veya düşük trafikli sitelerde çoğu zaman hiçbir şey görünmez; Patrick’in 2022 çalışmasında sayfaların yalnızca yaklaşık %12’sinde herhangi bir CrUX verisi vardı.
• PageSpeed Insights ile eşleşmez: Grup ile tek URL verisi farklıdır; ayrıca GSC URL parametrelerini ayrı tutarken PSI bunları kaldırıp yalın URL’ye indirger.
• Uygunluk eşiği: Bir URL grubunun görünmesi için hem LCP hem de CLS açısından eşik verisine sahip olması gerekir. Bunlardan biri yetersizse başarılı sayılmak yerine rapordan çıkarılır. Yalnızca dizine eklenmiş URL’ler ve bunların yalnızca bir örneklemi gösterilir; veriler standart URL’ye değil, gerçek URL’ye atanır.
• Grafik ile tablo farklı sayım yapar (grafik = her URL’yi en kötü sorununa göre bir kez; tablo = her sorunu sayar), dolayısıyla toplamlar eşleşmez.
• INP bir Core Web Vital olduğunda FID 12 Mart 2024’te kaldırıldı; PSI/CrUX’un altı aylık geçiş döneminin aksine GSC bunu hemen kaldırdı.
• Page Experience raporu Nisan 2023’te kaldırıldı; Core Web Vitals ve HTTPS raporları varlığını sürdürüyor.
• İş akışı: Önce Poor sorunlarını düzeltin ve Start Tracking ile doğrulayın. Bu, hâlâ başarısız olan tek bir URL’nin başarıyı engellediği ve hiçbir şeyin yeniden dizine eklenmediği 28 günlük bir izleme oturumudur. PSI’da hızlıca teşhis yapın ve alan verilerinin güncellenmesi için yaklaşık bir ay bekleyin. Sitede değişiklik yapılmadan oluşan durum değişiklikleri genellikle sınıra yakın URL’lerin eşiği aşmasından veya örneklem büyüklüğü gürültüsünden kaynaklanır.

Resmî belgeler

Google’ın birincil kaynak belgeleri.

Google

• Core Web Vitals report — temel Yardım sayfası: veri kaynağı (CrUX), cihaz/durum/URL grubu düzeni, “No data available”, kaynak grubuna geri dönüş, grafik ile tablo sayımı, PageSpeed Insights farklılıkları ve Start Tracking doğrulama iş akışı.
• Interaction to Next Paint becomes a Core Web Vital on March 12 — Chrome ekibinin duyurusu; FID’nin GSC’den hemen kaldırıldığını belirten Search Console’a özgü açıklamayı da içerir (PSI/CrUX’taki altı aylık geçiş döneminin aksine).
• Introducing INP to Core Web Vitals — Google Search Central’ın Mayıs 2023 tarihli FID → INP geçişi duyurusu.
• Understanding Core Web Vitals and Google Search results — araştırma sırasında hâlâ 2,5 s / 200ms / 0,1 olan güncel eşikleri içeren Search Central genel bakışı.

Kaynaktan alıntılar

Google’ın kayda geçmiş açıklamaları. Her bağlantı, kaynak sayfadaki alıntılanan bölüme doğrudan gider.

Google — raporun ne olduğu ve verilerin nereden geldiği

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” — Search Console Yardımı. Alıntıya git
• “The data for the Core Web Vitals report comes from the CrUX report… The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” Alıntıya git
• “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” Alıntıya git
• “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” Alıntıya git

Google — URL grupları ve gizlilik nedeniyle geri dönüş

• “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” Alıntıya git
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” Alıntıya git

Google — raporu okumak ve düzeltmeleri doğrulamak

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” Alıntıya git
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” Alıntıya git
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” Alıntıya git

Google — PageSpeed Insights karşılaştırması ve “No data available”

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” Alıntıya git
• “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” Alıntıya git
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” Alıntıya git

Google — Search Console’da FID → INP (Chrome ekibi, web.dev)

• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” Alıntıya git

John Mueller, Google — rapor URL’leri neden gruplandırıyor? (2021)

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.”
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” Haberi okuyun

Hangi aracı (veya yolu) seçmeliyim?

“Belirli bir sayfanın Core Web Vitals değerlerini kontrol etmek istiyorum.” → Bu raporu kullanmayın. Söz konusu URL’nin alan ve laboratuvar verileri için PageSpeed Insights’ı veya URL Inspection aracını kullanın. Core Web Vitals raporu, “not designed [to] find the status of a specific URL.”

“Raporda ‘No data available’ yazıyor.” → Mülk çok mu yeni? CrUX verilerinin oluşması için birkaç gün bekleyin. → Aksi hâlde bunun nedeni neredeyse kesin olarak yetersiz trafiktir; kaynak grubu bile gizlilik eşiğini aşamıyordur. Bunun yerine tekil URL’leri PageSpeed Insights / Lighthouse ile test edin. “No data”, sitenin sorunsuz olduğunu göstermez.

“Bir grup ‘Poor’ durumunda; önce neyi düzeltmeliyim?” → Need improvement etiketli sorunlardan önce Poor etiketli tüm sorunları düzeltin. → Grup içinde URL’ler gösterim sayısına göre azalan sırada listelenir; en üsttekiler grup durumunu en fazla etkiler. → Durumu grubun en kötü metriği belirler. LCP / INP / CLS metriklerinden hangisinin başarısız olduğunu bulun ve onu düzeltin.

“Aynı URL için GSC durumu ile PageSpeed Insights sonucu uyuşmuyor.” → Bu beklenen bir durumdur. GSC grubu, PSI ise aykırı değer olabilecek tekil URL’yi raporlar. Ayrıca GSC URL parametrelerini ayrı tutarken PSI bunları kaldırıp yalın URL’ye indirger. İkisi de yanlış değildir; farklı şeyleri ölçerler.

“Bir düzeltme yayımladım; işe yaradığını nasıl doğrularım?” → Hızlı geri bildirim için PageSpeed Insights’taki laboratuvar sonucunu hemen kontrol edin. → Alan verilerinde doğrulamak için GSC’deki sorunda Start Tracking’e tıklayın. → Ardından bekleyin: 28 günlük hareketli dönem nedeniyle raporun değişikliği tam olarak yansıtması yaklaşık bir ay sürer.

“Siteye dokunmadığım hâlde durum değişti.” → Bunun nedeni genellikle dışarıdaki bir değişiklikle (trafik dağılımı, CDN/görsel gecikmesi veya tarayıcı güncellemesi) eşiği aşan sınıra yakın URL’ler ya da basit bir örneklem büyüklüğü dalgalanmasıdır. Değişenin uygun URL sayısı mı yoksa temel metrik kalitesi mi olduğunu kontrol edin; bunlar farklı şeylerdir.

Core Web Vitals raporunu okumak için hızlı kontrol listesi

Sonuç çıkarmadan veya geliştiriciye görev listesi vermeden önce hızlıca şunları kontrol edin:

• Hem Mobile hem de Desktop sekmelerini kontrol ettiniz; bunlar bağımsızdır ve uyuşmayabilir.
• Analiz birimi olarak tekil URL’leri değil, URL gruplarını ele alıyorsunuz; tek bir düzeltme muhtemelen tüm grubu temizler.
• “Poor” bir grubun hızlı sayfalar içerebileceğini biliyorsunuz (grup durumu, kümenin p75 değerine dayanır).
• Grafik ile tablo toplamlarının eşleşmeyeceğini biliyorsunuz (grafik her URL’yi en kötü sorununa göre bir kez, tablo ise her sorunu sayar).
• En çok gösterim alan URL’lere öncelik vererek “Need improvement”dan önce “Poor” sorunlarını düzeltiyorsunuz.
• Koda dokunmadan önce her grubun durumunu hangi metriğin (LCP / INP / CLS) belirlediğini saptadınız.
• Tek URL kontrolleri için bu rapor yerine PageSpeed Insights / URL Inspection aracına geçtiniz.
• GSC’nin PageSpeed Insights ile eşleşmesini beklemiyorsunuz (grup ve URL farkı; parametrelerin korunması ve kaldırılması farkı).
• “No data available” görürseniz sayfaların sorunsuz olduğunu varsaymak yerine trafik ve uygunluğu kontrol ettiniz.
• Düzeltmeden sonra Start Tracking’e tıkladınız ve alan verilerinin güncellenmesi için ~bir ay bekliyorsunuz.
• Gerçekte sınıra yakın eşiklerden veya örneklem büyüklüğü gürültüsünden kaynaklanan bir durum değişikliğinin peşine düşmüyorsunuz.

Zihinsel modeller

1. Bu bir rapordur, ölçüm cihazı değildir. Her sayı CrUX alan verisidir: gerçek Chrome kullanıcıları, 28 günlük hareketli dönem, 75. yüzdelik dilim. Rapor bu verileri gösterir; yeni bir şey hesaplamaz ve laboratuvar katmanı içermez. Bu yüzden hiçbir zaman “şu anı” değil, her zaman yakın geçmişi anlatır.

2. Temel birim URL grubudur. Tek URL’ler üzerinden düşünmeyi bırakın. Google benzer şablonlu sayfaları gruplandırır, tüm kümeye tek durum atar ve tek bir şablon kusuru nedeniyle binlerce URL’yi işaretleyebilir. Şablonu bir kez düzeltirseniz grubu düzeltirsiniz. Hızlı bir URL yine de “Poor” grubunda bulunabilir.

3. En kötü metrik belirleyicidir. Bir grubun durumunu LCP / INP / CLS arasındaki en zayıf metrik belirler. Herhangi bir şeyi optimize etmeden önce hangi metriğin başarısız olduğunu bulun. “Grubu” değil, grubu aşağı çeken metriği düzeltirsiniz.

4. Gizlilik sıralaması boşlukları açıklar. URL grubu → kaynak grubu → “No data available.” Gizliliği koruyarak raporlama yapmak için yeterli trafik yoksa kaba gruplar veya hiçbir şey görünür. “No data”, temiz bir site değil, yetersiz CrUX verisi anlamına gelir.

5. İki araç, iki görev: Hızlı teşhis edin, yavaşça doğrulayın. PageSpeed Insights = tek URL, alan + laboratuvar, anında geri bildirim. GSC raporu = gruplandırılmış, yalnızca alan verisi, ~bir ay gecikmeli. Düzeltmeyi PSI’ın laboratuvar verilerinde teşhis edip doğrulayın; gerçek dünyadaki sonucu GSC alan verilerinin onaylamasını bekleyin.

Core Web Vitals raporu: Hızlı başvuru tablosu

Nasıl düzenlenir?

GSC raporu ile PageSpeed Insights karşılaştırması

Kısa bilgiler

• Veri kaynağı: Cihaz başına CrUX alan verileri, 28 günlük hareketli dönem, p75.
• Yalnızca dizine eklenmiş URL’ler gösterilir; tümü değil, bir örneklem sunulur. Veriler standart URL’ye değil, gerçek URL’ye atanır.
• “No data available” = yeni mülk veya yetersiz CrUX trafiği (URL grubu → kaynak grubu → hiçbir şey).
• Grafik her URL’yi bir kez (en kötü sorun), tablo her sorunu sayar; toplamlar eşleşmez.
• FID, 12 Mart 2024’te GSC’den kaldırıldı (hemen; PSI/CrUX 6 ay daha tuttu).
• Page Experience raporu 19 Nisan 2023’te kaldırıldı; Core Web Vitals ve HTTPS raporları varlığını sürdürüyor.
• Önce Poor sorunlarını düzeltin, Start Tracking ile doğrulayın ve rapora yansıması için yaklaşık 28 gün bekleyin.
• Sayfa ağırlığı için pratik kural (Google): Sayfa ve tüm kaynakları için 500KB’nin altı.

Core Web Vitals raporunda yapılan hatalar

Poor grubundaki her URL’yi tek başına yavaş kabul etmek. Durum, 75. yüzdelik dilimde gruba aittir; dolayısıyla tek bir üye daha hızlı veya yavaş olabilir. Temsilî URL’lerde teşhis yapın, ardından ortak şablonu veya bileşeni düzeltin.

Yalnızca Mobile veya yalnızca Desktop sekmesini kontrol etmek. Veri kümeleri ayrıdır ve uyuşmayabilir. Sonuçları tek bir anlatıda ortalamak yerine iki sekmeyi bağımsız olarak önceliklendirin.

“No data available” sonucunu başarılı kabul etmek. Bu genellikle URL’nin veya kaynağın raporlama için yeterli uygun CrUX trafiğine sahip olmadığı anlamına gelir. Laboratuvar testlerini ve diğer alan verisi kaynaklarını kullanın; sayfanın Good olduğunu iddia etmeyin.

Tek bir URL için GSC’nin PageSpeed Insights ile eşleşmesini beklemek. GSC grupları raporlar ve URL parametrelerini korur; PSI ise genellikle tek bir yalın URL’yi raporlar. Bir farkı hata saymadan önce analiz birimini ve URL işleme yöntemini anlayın.

Zaten Good olan metriği optimize etmek. Grubun durumunu en zayıf metriği belirler. Bir geliştiriciye iş vermeden önce sorumlunun LCP, INP veya CLS olup olmadığını saptayın.

Yalnızca laboratuvarda yapılan bir düzeltmenin hemen ardından Start Tracking’i başlatmak. Önce değişikliğin yalnızca önizlemede değil, etkilenen tüm şablonlarda üretime dağıtıldığını doğrulayın. Ardından alan doğrulamasını bir kez başlatın ve hareketli CrUX döneminin gerçek kullanıcı kanıtlarını toplamasına izin verin.

Grafik ve tablo toplamlarını mutabakat kontrolü olarak kullanmak. Grafik her URL’yi en kötü sorununa göre bir kez, tablo ise URL’ye bağlı her sorunu sayar. Toplamların farklı olması beklenir.

Bir Core Web Vitals düzeltmesini doğrulama

Üç kanıt katmanı kullanın. Tek bir katman kendi başına yeterli değildir.

1. Dağıtım kanıtı

• Yavaş etkileşimi, kararsız öğeyi veya geç yüklenen en büyük öğeyi etkilenen temsilî bir URL’de yeniden oluşturun.
• Değiştirilen kodun yalnızca önizlemede değil üretimde ve URL grubunun temsil ettiği her şablonda bulunduğunu doğrulayın.
• Aynı test koşullarında önce ve sonra Lighthouse veya başka bir laboratuvar izi çalıştırın. Hedeflenen metrik, başka bir Core Web Vital gerilemeden iyileşmelidir.

2. Rapor iş akışı kanıtı

• Tam sorun satırını açın; cihazını, durumunu, metriğini, URL grubunu ve örnek URL’lerini kaydedin.
• Tekil bir URL’nin GSC grubundan farklı olabileceğini unutmadan örnekleri PageSpeed Insights’ta noktasal olarak kontrol edin.
• Start Tracking’e yalnızca üretim dağıtımı tamamlandıktan sonra tıklayın. İşlemi tekrar tekrar başlatmak yerine sorunun doğrulama durumunu izleyin.

3. Alan sonucu kanıtı

• 28 günlük hareketli CrUX döneminin sürüm sonrası ziyaretleri kapsamasını bekleyin.
• Etkilenen grubun, başlangıçta başarısız olan aynı cihaz ve metrikte iyileştiğini doğrulayın.
• Hem Mobile hem de Desktop’ı kontrol edin; gerçek bir metrik iyileşmesiyle, hangi URL’lerin uygun olacak kadar veriye sahip olduğundaki değişikliği birbirinden ayırın.
• GSC değişmeden kalırsa dağıtımın başarısız olduğuna karar vermeden önce grubun örnek URL’lerini URL ve kaynak düzeyindeki PSI verileriyle karşılaştırın.

Başarı koşulu “Lighthouse bir kez yeşile döndü” değildir. Başarı; üretim düzeltmesinin grup genelinde mevcut olması, kontrollü laboratuvar kanıtlarının iyileşmesi ve yeterli gerçek kullanıcı verisi geldikten sonra ilgili GSC alan sorununun temizlenmesidir.

Bir performans puanı uydurmadan ilerlemeyi ölçme

Bunları cihaz, metrik, URL grubu ve yayın tarihi temelinde ayrı ayrı izleyin:

Kalite ölçütü olarak Google’ın yayımladığı Good eşiklerini kullanın: 75. yüzdelik dilimde ölçülen LCP 2,5 saniye veya altı, INP 200 milisaniye veya altı ve CLS 0,1 veya altı. Evrensel bir son tarih veya yüzdelik iyileştirme hedefi uydurmayın. Yararlı eğilim; başarısız gruplarda daha az uygun URL, temizlenmiş sorun doğrulamaları ve bir metriği diğerine feda etmeden art arda gelen 28 günlük dönemlerde kararlı kazanımlardır.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• What Are Core Web Vitals (CWVs) & How To Improve Them — metriklerin kendisi ve GSC raporunun etkilenen sayfaları şablona göre nasıl gruplandırdığı hakkındaki rehberim.
• Google PageSpeed Insights For SEOs & Developers — laboratuvar verisi eşlikçisi ve “diagnose in PSI, monitor in GSC” iş akışım (28 günlük gecikme ipucu burada yer alır).
• Core Web Vitals Data Study w/ CrUX & 5.2M Pages — neden çoğu sitede “No data available” ekranı görüldüğünü açıklayan, sayfaların ne kadar azında herhangi bir CrUX verisi bulunduğuna ilişkin geniş ölçekli incelemem (yaklaşık %12 değeri).

Konuşmalarım / röportajlarım

• Google’s Core Web Vitals for SMBs: A Conversation with Patrick Stox (Outside Communications) — raporun ne işe yaradığını açıklayan kısa ve teknik olmayan bir anlatım: “you fix it once, you fix that issue for all those pages.”

Resmî

• Core Web Vitals report — Search Console Help — bu makaledeki her şey için temel başvuru kaynağı.
• INP becomes a Core Web Vital on March 12 — web.dev — FID’nin GSC’den hemen kaldırılmasıyla ilgili ayrıntı.

Sektörden kaynaklar

• Google Discusses Grouping URLs for Core Web Vitals Scores (Search Engine Journal) — tek bir grubun neden binlerce URL’yi işaretleyebildiğine ilişkin John Mueller Office Hours transkripti.
• Google Search Console: How To Use The Core Web Vitals Report (DebugBear) — kurulumdan düzeltmeye uzanan pratik bir rehber ve hızlı sayfaların neden yavaş gruplara girebildiğine ilişkin iyi bir açıklama.
• Core Web Vitals in Google Search Console: Fix & Optimize (Quattr) — yapılandırılmış bir optimizasyon iş akışı (sırala → önceliklendir → test et → çöz → doğrula).
• Google Search Console page experience report going away (Search Engine Land) — Page Experience toplu raporunun Nisan 2023’te kaldırılmasına ilişkin haber.
• Core Web Vitals report within Google Search Console updated (Search Engine Land) — kaynak grubuna geri dönüş katmanının Mart 2023’te eklenmesi.
• Google Core Web Vitals Search Console Update (Search Engine Roundtable) — örneklem büyüklüğü dalgalanmasına ilişkin Mueller ve Pollard açıklamalarıyla Temmuz 2025’teki uygun URL düşüşü.

Alıntılanmaya değer istatistikler

• Ocak 2022 örneklemindeki 43,66 M benzersiz Site Audit sayfasının yalnızca yaklaşık %12’sinde herhangi bir CrUX metriği vardı. Çalışmamda: “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” Bu, raporun kullandığı temel CrUX veri kümesidir ve birçok sitenin neden “No data available” gördüğünün ölçeğini ortaya koyar.
• FID, 12 Mart 2024’te GSC’den kaldırıldı — PSI ve CrUX altı aylık bir geçiş dönemi sunarken GSC bunu bekleme süresi olmadan hemen yaptı. Kaynak
• Sayfa ağırlığı için pratik kural: 500KB’nin altı — Google’ın rapordaki “Fix issues” bölümünde yer alan kendi rehberine göre bir sayfa ve tüm kaynakları için. Kaynak
• Page Experience raporu 19 Nisan 2023’te kaldırıldı — eski toplu rapordan Core Web Vitals ve HTTPS raporları kaldı. Haber

Kendinizi sınayın: Core Web Vitals raporu

Search Console’daki Core Web Vitals raporunun nasıl çalıştığına ilişkin beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü