Teknik SEO ve Core Web Vitals Raporu Nasıl Yorumlanır?

Teknik SEO raporları ve Core Web Vitals (CWV) ekranları çoğu ekipte aynı yere takılır: “Skor kırmızı, ne yapacağız?” Oysa gerçek soru skor değil; hangi sayfada hangi sorun var, bu sorun kullanıcı deneyimini ve iş sonucunu nasıl etkiliyor, öncelik sırası ne? Teknik SEO’yu doğru okumak; CWV metriklerini (LCP/CLS/INP) tarama–index–status kod bulgularıyla birleştirip error→impact mapping yapmaktır: sorunları tek listede değil, etki alanına göre yönetirsiniz.

Teknik SEO KPI’ları, “Google bizi nasıl görüyor ve kullanıcı sayfayı nasıl yaşıyor?” sorusunu ölçer. Burada amaç; her şeyi raporlamak değil, karar verdiren KPI seti oluşturmaktır. Otel ve hizmet sitelerinde teknik KPI’lar genellikle iki ana yere bağlanır: (1) görünürlük kaybı riski (index/tarama), (2) dönüşüm sürtünmesi (performans/UX).

Temel teknik KPI aileleri

• •Tarama & Index: indexlenen URL sayısı, tarama hataları, canonical/robots/sitemap uyumu
• •Durum kodları: 404/5xx artışı, yanlış yönlendirme zincirleri
• •Performans & UX: CWV (LCP/CLS/INP), TTFB (bazı araçlarda), JS render gecikmeleri
• •Site sağlığı: büyük şablon sorunları (templated issues), mobil/desktop ayrışması

Mini örnek (otel): Rezervasyon sayfası hızlı değilse (LCP yüksek) yalnız “SEO” değil, “rezervasyon tamamlama” da etkilenir. Teknik KPI’ların değeri, bu etkiyi görünür yapmasındadır.

CWV, gerçek kullanıcı deneyimini ölçen üç metrikle özetler: yükleme (LCP), görsel stabilite (CLS), etkileşim (INP). Google Search Console’daki CWV raporu, URL’leri “Good / Need improvement / Poor” olarak sınıflandırır ve URL gruplarıyla gösterir.

Core Web Vitals raporu nasıl okunur?

CWV eşik değerleri pratikte ne demek?

Rapor okurken “iyi/kötü” etiketlerinin arkasındaki eşiği bilmek, ekiple aynı dili konuşmanızı sağlar. PageSpeed Insights, Web Vitals girişimine uyumlu eşikleri bu şekilde sınıflandırır:

• •LCP: iyi ≤ 2.5s, geliştirmeli 2.5–4.0s, kötü > 4.0s
• •CLS: iyi ≤ 0.1, geliştirmeli 0.1–0.25, kötü > 0.25
• •INP: iyi ≤ 200ms, geliştirmeli 200–500ms, kötü > 500ms

Not: INP, Core Web Vitals içinde etkileşim metriği olarak FID’in yerini aldı.

Mini örnek: Bir otel ana sayfasında LCP kötü ama INP iyi olabilir: ana görsel/hero ağır, ama etkileşim hızlıdır. Bu durumda “tek skor” yerine “LCP odaklı çözüm” gerekir.

CWV sorunlarının büyük bölümü üç kökten beslenir:

1. Sunucu yanıtı (TTFB, gecikmeli backend, CDN eksikleri)
2. Render bloklayıcı kaynaklar (CSS/JS, üçüncü parti scriptler)
3. Ağır görsel/video ve font stratejisi

Buradaki kritik nokta: CWV “puan” değildir; sayfanın gerçekten kullanıcıda nasıl hissettirdiğini anlatır. Field veride kötü görünen bir LCP, çoğu zaman “zayıf cihaz + yavaş ağ” gerçeğini de taşır; lab testiniz iyi çıkabilir. Bu fark normaldir, önemli olan ikisini doğru amaçla kullanmaktır.

LCP’yi bozan tipik nedenler (otel/hizmet örnekleri)

• •Hero görseli çok büyük / yanlış format / lazy-load hatalı
• •Fontlar geç geliyor (FOIT/FOUT), kritik CSS gecikiyor
• •Üçüncü parti scriptler (chat, pixel, A/B test) render’ı kilitliyor
• •Sunucu cevap süresi yüksek (özellikle kampanya dönemlerinde)

INP’yi bozan tipik nedenler

• •Ana thread yoğun (aşırı JS, ağır framework işleri)
• •Uzun task’lar, event handler’lar, gereksiz DOM işlemleri
• •Özellikle rezervasyon formu, tarih seçici, fiyat bileşeni gibi etkileşimli alanlar

CLS’yi bozan tipik nedenler

• •Görsel/iframe boyutları sabit değil
• •Sonradan yüklenen banner, pop-up, cookie bar sayfayı zıplatıyor
• •Font swap stratejisi kötü

CWV “kullanıcı” tarafını ölçer; tarama ve index ise “Google’ın içeriği keşfetmesi ve değerlendirmesi” tarafıdır. Teknik raporunuzun ikinci omurgası burası olmalı: çünkü tarama/index bozulduğunda, en iyi içerik bile görünmez hale gelir.

Teknik SEO raporunda ilk bakılması gereken alanlar neler?

Tarama/index sorunlarını “iş etkisi” ile okumak

• •Index düşerse: görünürlük kaybı riski (talep azalır)
• •5xx artarsa: tarama bütçesi ve kullanıcı deneyimi birden bozulur
• •Yanlış robots/canonical: yanlış sayfalar görünür, doğru sayfalar kaybolur

Mini örnek: Otel “kampanya” landing’i sezon başında robots ile yanlış bloklanırsa, “SEO çalışmıyor” gibi görünür ama problem içerik değil teknik karardır.

Bu bölüm, teknik raporu aksiyona çeviren ana parçadır: “ne bozuk” listesini “neye zarar veriyor” haritasına dönüştürür. Burada küçük bir model kurun:

Teknik SEO → Sonuç modeli (AIO uyumlu)

• •Crawl/Index sorunları → görünürlük kaybı (impressions/clicks düşer)
• •CWV/Performans sorunları → dönüşüm sürtünmesi + tıklama verimi (CTR/etkileşim düşer)
• •Status code/redirect sorunları → tarama verimsizliği + kullanıcı kaybı

Bu model, “technical health reporting” yaklaşımıdır: metrikler tek başına değil, etki zinciriyle okunur.

Sorun → Etki → İlk aksiyon (özet harita)

Key Statistics / Data Point (soft): Birçok çalışmada, CWV metriği iyileştirilen sayfalarda hem sıralama hem dönüşüm tarafında anlamlı artışlar gözlendiği raporlanıyor. (Kesin rakam iddiası değil; genel gözlem/rapor bulgusu olarak düşünün.)

CWV ve teknik SEO raporları aksiyona dönmüyorsa, genellikle iki nedenle:

• •“Hangi sayfa?” sorusu net değildir (URL grubu/landing eşleştirmesi yok)
• •“Hangi iş etkisi?” net değildir (dönüşüm/lead bağlantısı kurulmamış)

Bu nedenle basit bir öncelik kuralı önerin:

Mini örnek (otel): Rezervasyon formu bulunan sayfada INP kötü ise (etkileşim gecikiyor), efor orta bile olsa öncelik yükselir; çünkü iş etkisi kritik.

Teknik SEO ve Core Web Vitals raporları, yalnızca kırmızı/yeşil skor ekranları olarak okunursa ekipleri aksiyonsuz bırakır. Doğru yaklaşım; URL gruplarını, CWV metriklerini, tarama/index durumunu ve status kod bulgularını aynı çerçevede değerlendirip “sorun → etki → aksiyon” haritası çıkarmaktır.

Bu sayede teknik rapor, geliştirici backlog’u ile pazarlama hedefleri arasında ortak bir dile dönüşür. Önceliklendirme; trafik, dönüşüm etkisi ve efor üzerinden yapıldığında, teknik SEO çalışmaları yalnızca site sağlığını değil, kullanıcı deneyimi ve iş sonucunu da iyileştirir.