CLS (Cumulative Layout Shift) nedir ve nasıl düzeltilir? 2026

CLS (Cumulative Layout Shift) nedir, neden kritik bir metriktir?

CLS, bir sayfa yüklenirken ya da kullanıcı akışı sırasında ekrandaki öğelerin beklenmedik şekilde yer değiştirmesinin toplam etkisini ölçer. Kullanıcı bir butona tam tıklayacakken sayfanın aşağı itilmesi, haber kartlarının sonradan açılması veya hero görselin yüklenince metni aşağı kaydırması tipik örneklerdir. Teknik terimlerin temelini hızlıca gözden geçirmek isterseniz teknik SEO terimleri sözlük sayfası iyi bir başlangıç olur.

2026 tarafında hedef değişmiş değil. Google Search Central’ın 10 Aralık 2025 güncellemesine göre iyi CLS değeri 0.1 ve altı, 0.1-0.25 arası geliştirmeye açık, 0.25 üzeri zayıf kabul ediliyor. Aynı eşik web.dev rehberlerinde de korunuyor ve ölçümün 75. persentilde, mobil ve masaüstü ayrı değerlendirilmesi öneriliyor. Bu yüzden tek bir ekran kaydına değil, dağılıma ve cihaz kırılımına bakmak gerekir.

Bu metriğin kritik olmasının sebebi yalnızca Core Web Vitals raporunda görünmesi değil. CLS, kullanıcının sayfayı güvenilir algılayıp algılamadığını doğrudan etkiler. LCP içeriğin ne kadar hızlı göründüğünü, INP etkileşime ne kadar çabuk karşılık verildiğini ölçer; CLS ise görsel düzenin stabil kalıp kalmadığını anlatır. Arama görünürlüğü açısından da mesele budur: hızlı açılan ama sürekli kayan bir sayfa yine kötü deneyim üretir.

CLS nasıl ölçülür? PageSpeed Insights, Search Console, Lighthouse ve CrUX

Pratik teşhis akışı şu olmalı: önce Search Console’da hangi URL grubunun mobil ya da masaüstünde sorun çıkardığını bulun, sonra aynı temsilî URL’yi PageSpeed Insights’ta açın, ardından Chrome DevTools Performance kaydıyla kayan öğeyi izole edin. Search Console yardım dokümanında raporun veriyi benzer kullanıcı deneyimine sahip URL grupları halinde topladığı ve platformu mobil ile masaüstü diye ayırdığı açıkça belirtiliyor.

PageSpeed Insights iki farklı katman gösterir. Google’ın PSI dokümanına göre saha verisi CrUX üzerinden son 28 günlük gerçek kullanıcı deneyimini taşır; laboratuvar verisi ise anlık test koşuludur. Bu yüzden PSI’da field data kötü, Lighthouse iyi çıkabilir. Özellikle cookie banner, sonsuz scroll, oturum açma çubuğu veya reklam gibi post-load kaymalar laboratuvar koşullarında her zaman birebir yakalanmaz.

Skor farklarının üçüncü nedeni veri çözünürlüğüdür. Search Console URL grubu düzeyinde konuşur, PSI çoğu zaman tek URL gösterir, veri yetersizse origin seviyesine düşebilir. CrUX API ise URL veya origin bazında ve cihaz form faktörüne göre sorgulanabilir. Kısacası bu araçlar birbirini yanlışlamaz; her biri aynı sorunu farklı büyüteçle gösterir ve doğru okunduğunda kök nedeni daha hızlı bulmanızı sağlar.

CLS sorununa neler yol açar? Modern arayüzlerde en yaygın senaryolar

En yaygın neden hâlâ boyutu önceden ayrılmamış medya alanları. web.dev’nin 7 Şubat 2025 güncellenen optimizasyon rehberi, dimensions belirtilmemiş görselleri, reklamları, embed’leri ve iframe’leri zayıf CLS’nin başlıca kaynakları arasında sayıyor. Bir görsel geç yükleniyor ve tarayıcı yüksekliğini baştan bilmiyorsa, üstteki içerik yerinde kalırken alttaki her şey aşağı itilir.

• Width ve height verilmeyen görseller, video blokları ve ürün galerileri
• Yüksekliği sonradan açılan reklam slotları, iframe’ler ve sosyal medya embed’leri
• Sayfanın üstüne sonradan giren cookie banner, promosyon şeridi ve sticky header değişimleri
• Hydration sırasında sunucu ve istemci çıktısı farklı olan SPA bileşenleri
• Fallback ile nihai font arasında büyük metrik farkı olan başlık ve menü alanları

Modern arayüzlerde ikinci büyük küme dinamik bileşenlerdir. Cookie banner’ın DOM’a sonradan eklenmesi, sticky header’ın scroll anında yükseklik değiştirmesi, sonsuz scroll’da yeni kartların araya basılması veya hydration sırasında sunucu ve istemci markup’ının uyuşmaması kaymaya yol açar. Özellikle SPA yapılarında sorun ilk yüklemeden çok kullanıcı sayfada gezinirken oluşur.

Font tarafı da sık gözden kaçar. MDN’nin 11 Temmuz 2025 güncel CLS sözlüğü, metin ölçüleri sonradan değiştiğinde layout kaymasının görülebileceğini hatırlatıyor. FOIT ve FOUT tek başına sorun değildir; asıl risk, fallback font ile nihai fontun metrikleri ciddi farklıysa başlık bloklarının yeniden akmasıdır. Kullanıcı etkileşimi sonrası kaymalar ise ancak beklenen bir etkileşimin 500 ms içinde kalıyorsa CLS dışında tutulabilir.

CLS nasıl düzeltilir? Geliştirici düzeyinde çözüm kalıpları

Alanı yüklemeden önce ayırın

İlk kural, sonradan gelecek öğe için yer ayırmaktır. Görsellerde width ve height ya da CSS aspect-ratio, videolarda sabit oranlı wrapper, reklam ve embed alanlarında min-height veya reserved slot kullanın. Boyut tam sabit değilse en kötü senaryoya göre konteyner ayırmak, görünüm kusursuz olmasa da CLS’yi dramatik biçimde düşürür.

Önce ve sonra farkı genelde basittir: önce hero görseli yalnızca genişlikle render edilir, sonra yüklenince içerik aşağı kayar; düzeltme sonrası tarayıcı yüksekliği baştan bilir ve metin sabit kalır. Lazy-load kullanıyorsanız placeholder’ın gerçek içeriğe yakın oran taşıması gerekir; aksi halde iskelet bileşen kalkınca ikinci bir kayma üretirsiniz.

Font, hydration ve animasyonu stabil tasarlayın

Fontlarda font-display stratejisini tek başına yeterli görmeyin. Fallback ile asıl font arasındaki fark büyükse metric override veya benzer font eşleştirmesi kullanın. SSR ve CSR geçişinde istemci tarafında farklı kart sayısı, farklı başlık yüksekliği ya da geç enjekte edilen promosyon bloğu varsa hydration mismatch doğar. Burada çözüm, sunucu çıktısı ile istemci ilk render’ını aynı iskelette tutmak ve kritik bileşenleri sonradan yukarıdan eklememektir.

Animasyonda da kural nettir: yer değiştirme için top, left veya height kullanmak yerine transform tercih edin. 17 Aralık 2025 tarihli Layout Instability API taslağı, layout-shift kayıtlarını PerformanceObserver üzerinden toplayabileceğinizi gösteriyor. DevTools’ta Layout Shift Regions ve Performance panelini açıp değişiklikten önce ve sonra kayıt almak, düzeltmenin gerçekten işe yarayıp yaramadığını görmenin en güvenli yoludur.

• Görsel, video ve iframe alanlarını aspect-ratio ile önceden rezerve edin
• Reklam ve embed bloklarında boş durum için de minimum yükseklik tanımlayın
• Header, banner ve duyuru barlarını içeriği itmeyecek şekilde overlay veya sabit slot mantığıyla kurgulayın
• Hydration öncesi ve sonrası DOM sırasını koruyun, geç eklenen üst bileşenlerden kaçının

Mini vaka: Aynı URL’de neden üç farklı CLS skoru gördük?

Kendi test ortamımızda yeniden ürettiğimiz bir kampanya URL’sinde ilk mobil ölçüm ilginçti: PSI saha verisi 0.27 gösterirken aynı sayfanın tek bir Lighthouse koşusu 0.06 veriyordu. DevTools kaydını açınca dört ayrı kayma anı gördük: sonradan eklenen cookie banner, oranı tanımlanmamış hero görsel, geç yüklenen web font ve açılıp kapanan reklam slotu. Tek tek bakınca sorun küçük görünüyordu; toplam etki kullanıcı akışında büyüyordu.

Düzeltme sırası kritik oldu. Önce banner’ı sayfa üstüne itmek yerine overlay olarak konumlandırdık, hero görsele aspect-ratio verdik, font fallback’ini metrik olarak yaklaştırdık ve reklam alanına minimum yükseklik ayırdık. Sonraki laboratuvar kayıtlarında CLS 0.06 bandına indi, en kötü oturumda 0.08’i gördü. Search Console tarafındaki iyileşme ise anında görünmedi; çünkü grup skoru p75 mantığı ve 28 günlük pencereyle hareket ediyor.

Buradaki önemli ders şu: aynı URL’de üç farklı skor görmek normaldir. Search Console grup seviyesinde ve gecikmeli konuşur, PSI gerçek kullanıcı geçmişini ve anlık laboratuvar testini aynı ekranda toplar, DevTools ise o anki oturumun kök nedenini verir. Son 12 ayda en sık gördüğümüz hata, ekiplerin Lighthouse yeşile dönünce sorunun bittiğini sanması oldu; oysa mobil saha verisi toparlanmadan CLS kapanmış sayılmaz.

Adım Adım CLS sorunu tespit etme ve düzeltme akışı

CLS düzeltmesinde hız, doğru sırayla hareket etmekten gelir. Aşağıdaki akış tekil URL yerine şablon ve cihaz kırılımı üzerinden çalıştığı için 2026’da daha güvenilir sonuç verir.

1. Search Console’da sorunlu URL grubunu belirleyin. Mobil ve masaüstü raporlarını ayrı açın; en çok URL etkileyen ve Poor durumunda olan gruplar ilk önceliğiniz olsun.
2. PSI’da field ve lab verisini ayırın. Üstteki CrUX verisini kullanıcı gerçeği, alttaki Lighthouse bölümünü teşhis ortamı olarak okuyun; ikisini aynı skor sanmayın.
3. DevTools ile kayan öğeyi izole edin. Performance kaydı alın, layout shift region işaretlerini açın ve her kaymanın hangi bileşenden çıktığını tek tek not edin.
4. Boyut rezervasyonu ve font düzeltmelerini uygulayın. Görsel, reklam, embed ve font kaynaklı her blok için alan ayırın; hydration farklarını kaldırın.
5. Mobil ve desktop’ta yeniden test edin. Aynı şablonu farklı breakpoint’lerde tekrar ölçün; sorun çoğu zaman yalnızca mobil üst kısımda yoğunlaşır.
6. CrUX veya RUM ile sonucu doğrulayın. Saha verisinin hemen güncellenmeyeceğini kabul edin ve 28 günlük pencereyi izleme planına dahil edin.

Bu akışın avantajı, geliştirme eforunu önce en çok görünürlük ve gelir etkisi taşıyan şablonlara yönlendirmesidir. Böylece tek tek URL peşinde koşmak yerine aynı kusuru üreten bileşeni kalıcı olarak ortadan kaldırabilirsiniz.

CLS düzeltmelerini nasıl önceliklendirirsiniz ve SEOYEN ile nasıl izlersiniz?

Önceliklendirmeyi iki eksende yapın: kaymanın şiddeti ve düzeltme maliyeti. Şablonun üst kısmındaki hero, header, ürün fiyatı, CTA ve reklam alanları en yüksek etkiye sahiptir. Genelde en hızlı kazanımlar width ve height eklemek, placeholder oranını düzeltmek, yukarıdan içerik enjekte etmeyi durdurmak ve mobil header davranışını sadeleştirmekten gelir.

• Önce Poor durumundaki mobil şablonları kapatın
• Ardından çok URL etkileyen ortak bileşenleri düzeltin
• En son tekil sayfa istisnalarını ve düşük etkili görsel kusurları temizleyin

Operasyon tarafında izleme dağınık kalıyorsa sorun tekrarlar. Bu noktada site sağlığı görünümüyle hangi sayfa tiplerinin teknik olarak bozulduğunu, sıralama takibi ile de görünürlük tarafında hangi kümelerin baskılandığını birlikte okumak daha pratiktir. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer benzeri platformlarda da raporlama yapılır; SEOYEN bunu Türkiye pazarına uyarlanmış Türkçe arayüz, TL bazlı fiyatlandırma ve yerel destekle tek platformda toplar.

Takibin sürdürülebilir olması için raporu URL değil şablon mantığıyla kurgulayın: kategori, ürün, blog ve landing page gibi. Böylece bir düzeltmenin gerçekten yayılıp yayılmadığını daha erken görürsünüz. Operasyonel ayrıntılar ve plan yapısı için fiyat paketleri sayfasına bakılabilir; asıl hedef, teknik ekiple SEO ekibinin aynı ekran üzerinden karar alabilmesidir.

Sıkça Sorulan Sorular