Teknik SEO ve Core Web Vitals (Infisale Perspektifi)

Web dünyasında sıkça duyulan bir klişe vardır: "İçerik kraldır." Ancak krallığın ayakta kalabilmesi için üzerine inşa edildiği kalenin surlarının sağlam olması gerekir. Teknik SEO, o kalenin görünmez ama sarsılmaz temelidir. Sitenizin içeriği ne kadar harika olursa olsun; arama motoru botları sayfalarınızı tarayamıyorsa, indeksleyemiyorsa veya siteniz kullanıcıyı milisaniyelerce bekletiyorsa, görünürlük yarışına daha başlamadan geride kalmışsınız demektir.

Önceki yazılarımızda arama motorlarının çalışma mantığını ve site hızının dönüşümlere etkisini ele almıştık. Bu yazımızda ise işi bir adım daha ileriye götürüyor; modern web dünyasının teknik kurallarını belirleyen Core Web Vitals metriklerini, temiz kod yapısını, sunucu tarafında render edilmenin (SSR) önemini ve tarama bütçesi (Crawl Budget) yönetimini Infisale'in mühendislik perspektifiyle mercek altına alıyoruz. Bu, teknik otoriteyi ve geleceğin arama motoru optimizasyonunu kurma yolundaki üçüncü rehberimizdir.

1 Core Web Vitals: Kullanıcı Deneyiminin Ölçülebilir Metrikleri

Google'ın 2020 yılında duyurduğu ve 2021'den itibaren resmi sıralama faktörü yaptığı Core Web Vitals (Önemli Web Verileri), bir web sitesinin hızını, etkileşim kalitesini ve görsel kararlılığını ölçen standartlaştırılmış metriklerdir. Google, bu verileri gerçek kullanıcı deneyimlerini temel alan Chrome Kullanıcı Deneyimi Raporu (CrUX) üzerinden toplar.

Arama motorlarının ve kullanıcıların öncelik verdiği bu metriklerin ideal eşiklerini aşağıdaki karşılaştırma tablosundan inceleyebilirsiniz:

Bu metriklerin her birinin ne anlama geldiğini ve nasıl optimize edileceğini detaylarıyla ele alalım:

LCP (Largest Contentful Paint) — En Büyük İçerikli Boyama

LCP, kullanıcının sayfaya girdiğinde gördüğü en büyük görsel veya metin bloğunun ekranda tamamen görünür hale gelme süresidir. Genellikle bir kahraman (hero) görseli, büyük bir başlık veya öne çıkan bir resim LCP elemanıdır.

• Neden Gecikir? Yavaş sunucu yanıt süreleri (TTFB), oluşturmayı engelleyen JavaScript ve CSS dosyaları, yavaş yüklenen büyük görsel formatları ve istemci tarafında gecikmeli render edilen dinamik elemanlar.
• Optimizasyon Yolu: Kritik görselleri modern AVIF veya WebP formatında sunmak, görsel boyutlarını ekran genişliğine göre sınırlandırmak ve tarayıcıya LCP görselini önceliklendirmesini söyleyen fetchpriority="high" özniteliğini (attribute) eklemek. Sitenizde `Picture.svelte` gibi akıllı bileşenler kullanarak görsellerin otomatik dönüştürülmesini sağlamak LCP'yi dramatik ölçüde düşürür.

INP (Interaction to Next Paint) — Sonraki Boyamayla Etkileşim

Teknik SEO'da en kritik güncellemelerden biri Mart 2024'te gerçekleşti: Google, eski etkileşim metriği olan FID'yi (First Input Delay) rafa kaldırıp yerine INP (Interaction to Next Paint) metriğini getirdi. Kaynak: Google Search Central — Core Web Vitals in Google Search FID yalnızca kullanıcının siteyle gerçekleştirdiği ilk etkileşimin gecikmesini ölçerken, INP kullanıcının sayfada kaldığı tüm süre boyunca yaptığı tıklamalar, dokunmalar ve klavye girişlerinin ekrandaki görsel geri bildirime dönüşme süresini (en yavaş etkileşim gecikmesini) izler.

• Neden Gecikir? Tarayıcının ana iş parçacığını (main thread) kilitleyen yoğun ve optimize edilmemiş JavaScript kodları, büyük framework hidratasyonları (hydration) ve üçüncü parti takip kodları.
• Optimizasyon Yolu: Ağır ve karmaşık JavaScript kütüphanelerinden kaçınmak. Örneğin React veya Angular gibi devasa runtime gerektiren altyapılar yerine, derleme aşamasında (build-time) kodu minimal düzeyde optimize eden **Svelte 5** gibi hafif yapılar tercih edilmelidir. DOM üzerinde işlem yaparken uzun görevleri (long tasks) parçalara ayırmak (yield to main thread) INP'yi yeşil bölgede tutmanın anahtarıdır.
• Yeni Nesil LoAF API ile Gerçek Zamanlı Analiz: İş parçacığı blokajlarını tespit etmek için geleneksel Long Tasks API yetersiz kalır; çünkü sadece bir işin uzun sürdüğünü söyler, kaynağını göstermez. Chrome 123 ile sunulan **Long Animation Frames (LoAF) API** mimarisi ise, gecikmeye sebep olan spesifik Javascript betiklerini, derleme sürelerini ve render engellerini detaylıca ilişkilendirir. Kaynak: Chrome Web Dev — Long Animation Frames API Geliştiriciler LoAF API'yi şu şekilde kurarak production ortamındaki kullanıcıların yaşadığı etkileşim blokajlarını gerçek zamanlı loglayabilir:

  const observer = new PerformanceObserver((list) => {
     for (const entry of list.getEntries()) {
        console.log('LoAF Tespit Edildi:', {
           duration: entry.duration,
           blockingDuration: entry.blockingDuration,
           scripts: entry.scripts.map(s => ({
              invoker: s.invoker,
              source: s.sourceLocation?.charStart
           }))
        });
     }
  });
  observer.observe({ type: 'long-animation-frame', buffered: true });

CLS (Cumulative Layout Shift) — Kümülatif Düzen Kayması

CLS, sayfa yüklenirken veya kullanıcı sayfayı kaydırırken elemanların beklenmedik şekilde yer değiştirmesini ve düzenin kaymasını ölçer. Bir makale okurken yukarıda aniden yüklenen bir reklamın yazıyı aşağıya kaydırması, en klasik kötü CLS örneğidir. Bu durum kullanıcıyı yanlış yere tıklamaya zorladığı için deneyimi doğrudan sabote eder.

• Neden Gecikir? Genişlik ve yükseklik öznitelikleri (width/height) belirtilmemiş görseller ve videolar, sonradan yüklenen ve yer ayrılmamış dinamik reklam alanları, tarayıcının geç algıladığı özel web fontlarının (FOUT/FOIT) yüklenme anında metin boyutunu değiştirmesi.
• Optimizasyon Yolu: Tüm raster görsellere ve dynamic iframe alanlarına aspect-ratio veya kesin width ve height değerleri atamak. Web fontlarını yüklerken font-display: swap kullanıp yedek font ile orijinal fontun boyutlarını CSS font-size-adjust ile eşitlemek kaymaları engeller.

2 Temiz Kod Yapısı: Botlar ve AI Ajanları İçin Okunabilirlik

Google'ın tarama algoritmaları ve Perplexity, Gemini, ChatGPT gibi yapay zeka tabanlı üretken arama motorları (GEO) sitenizi ziyaret ettiğinde, görsel tasarımdan ziyade **kodun anlamsal bütünlüğünü** okurlar. Kirli, karmaşık veya iç içe geçmiş yüzlerce gereksiz etiketten oluşan bir kod yapısı sitenizi anlaşılamaz hale getirir.

Temiz kod mimarisinin iki temel unsuru vardır:

Anlamsal (Semantic) HTML

Sayfanızı sadece <div> ve <span> etiketleriyle tasarlamak, tarayıcıya ve botlara hiçbir hiyerarşik bilgi sunmaz. Bunun yerine HTML5'in sunduğu anlamsal etiketler kullanılmalıdır. Bir makale gövdesi <article>, ana menü <nav>, sayfa başlığı <header>, yan sütunlar <aside> ve alt bilgi alanı <footer> içinde sarmalanmalıdır.

Bu yapı, botların sayfadaki en değerli içeriğin nerede başladığını ve nerede bittiğini anlamasını sağlar. Yapay zeka motorları da anlamsal olarak yapılandırılmış makalelerden veri çekmeyi ve bunları referans göstermeyi çok daha kolay başarır.

DOM Derinliği (DOM Depth) ve Eleman Sayısı

Document Object Model (DOM), tarayıcının HTML kodunu bir ağaç yapısına dönüştürerek render etme biçimidir. Bir sayfada aşırı miktarda iç içe geçmiş etiket kullanılması (örneğin popüler sayfa oluşturucularla (page builders) hazırlanan WordPress sitelerindeki iç içe geçmiş 15-20 div katmanı) DOM derinliğini artırır.

Lighthouse standartlarına göre, bir sayfadaki toplam DOM elemanı sayısı 800'ün altında, maksimum derinlik ise 32 katmandan az olmalıdır. Bunu aşan "kod çöplüğü" yapılar, teknik olarak SEO sıralamalarını aşağı çeker. Bu konu hakkında daha fazla bilgiye WordPress eklenti cehennemi ve sitelerin çökme nedenleri yazımızdan ulaşabilirsiniz.

Modern Bir Çözüm: CSS content-visibility: auto ile Render Yükünü Azaltma

Büyük DOM derinliğine sahip veya çok uzun sayfalarda, tarayıcının tüm elemanlar için CSS kurallarını hesaplaması ve sayfayı çizmesi (paint) ciddi işlemci yükü getirir. CSS dünyasına yeni katılan ve tarayıcı performansı açısından devrim niteliğinde olan content-visibility: auto özelliği, bu CSS hesaplama yükünü azaltmanın en modern yoludur.

content-visibility: auto, tarayıcıya ekranın dışında (out-of-viewport) kalan elemanların **render ve düzen hesaplamalarını atlama (skip)** yetkisi verir. Kullanıcı sayfayı kaydırıp o bölgeye yaklaştığında tarayıcı hesaplamaları anında tamamlar. Böylece başlangıç yükündeki DOM derinliği performansı olumsuz etkilemez.

Uygulama Adımları:

• 1. Doğru Alanları Seçin: Sayfanın ekranın altında kalan (below-the-fold) büyük bileşenlerini (örneğin yorum alanları, detay tabloları, makalenin altındaki diğer öneriler veya sitenin devasa footer alanı) belirleyin.
• 2. Boyut Rezervasyonu Yapın (Layout Shift Önleme): Tarayıcı render edilmeyen alanın yüksekliğini bilmediği için, kullanıcı kaydırma yaparken sayfa boyutu aniden değişebilir ve bu da **CLS (kümülatif düzen kayması)** sorununa yol açar. Bunu önlemek için contain-intrinsic-size özelliğiyle tahmini bir alan rezervasyonu yapmalısınız.
• 3. CSS Tanımını Ekleyin:

  .lazy-render-section {
     content-visibility: auto;
     contain-intrinsic-size: 0 500px; /* Genişlik 0, Yükseklik tahmini 500px */
  }

Önemli İpucu: Sitenin en üstündeki (above-the-fold) elemanlara content-visibility: auto vermekten kaçının. Aksi takdirde, sayfa ilk açıldığında LCP süresinin gecikmesine yol açabilirsiniz.

3 Server-Side Rendering (SSR) ve Statik Oluşturmanın Önemi

Modern Javascript framework'leri (React, Vue vb.) ilk çıktıklarında tüm yükü tarayıcıya yıkan **Client-Side Rendering (CSR)** modelini benimsediler. CSR sitelerinde sunucudan gelen ilk yanıt, içi boş bir HTML kabuğudur: <div id="app"></div>. İçerik, tarayıcıda indirilen megabaytlarca JavaScript kodunun çalıştırılmasıyla dinamik olarak doldurulur.

Bu durum kullanıcı için yavaşlık demek olduğu gibi, arama motorları için de büyük bir indeksleme problemidir. Googlebot sitenizi ziyaret ettiğinde, JavaScript kodunu anında çalıştıracak render kaynaklarına sahip değildir. Sitenizi iki dalga halinde indeksler:

Bu gecikme, haber sitelerinde, e-ticaret sitelerinde veya dinamik SaaS sayfalarında yeni eklenen içeriklerin günlerce Google'da çıkmaması anlamına gelir. Çözüm, **Server-Side Rendering (SSR)** veya önceden oluşturulmuş statik sayfaların sunulduğu hibrit modellerdir (SSG/ISR).

SSR modelinde sayfa sunucuda veya CDN edge ağında derlenir ve bot sitenize geldiğinde içeriği dolu, başlıkları yerinde, bağlantıları taranmaya hazır temiz bir HTML dosyasıyla karşılaşır. Böylece sayfa render kuyruğuna girmeden anında birinci dalgada indekslenir. Bu hem indeks hızınızı artırır hem de sunucu maliyetlerinizi düşürerek bot bütçenizi korur.

4 Crawl Budget (Tarama Bütçesi) Yönetimi: Botları Doğru Yönlendirme

Arama motorlarının kaynakları sınırsız değildir. Googlebot, her web sitesine popülerliğine, boyutuna ve sunucu hızına göre değişen günlük veya haftalık belirli bir **tarama bütçesi (crawl budget)** ayırır. Kaynak: Google Search Central — Large Site Owner's Guide to Managing Crawl Budget Eğer sitenizde tarama bütçesi doğru yönetilmiyorsa, bot önemli sayfalarınızı (ürünler, güncel yazılar) taramak yerine gereksiz sayfalarla bütçeyi tüketir.

Tarama bütçesini verimli yönetmek için yapılması gereken teknik hamleler şunlardır:

1. Parametrik URL'lerin Denetlenmesi

Özellikle e-ticaret sitelerindeki filtreleme sistemleri (renk, beden, fiyat vb.) sonsuz sayıda varyasyon oluşturabilir. Googlebot bu parametreli URL'lerin her birini yeni bir sayfa gibi taramaya kalktığında bütçeniz saniyeler içinde tükenir. Çözüm, arama hacmi olmayan parametreli sayfaları robots.txt üzerinden taramaya kapatmak ve asıl indekslenmesi gereken sayfalara rel="canonical" etiketiyle işaret etmektir.

2. Sunucu Hızı ve TTFB Optimizasyonu

Eğer sunucunuz bir sayfayı getirmek için botu 1 saniye bekletiyorsa, Googlebot ayırdığı süre boyunca sitenizde sadece 50 sayfa tarayabilir. Ancak sunucu yanıt süreniz (TTFB - Time to First Byte) 50 milisaniye ise, bot aynı sürede 1000 sayfanızı kolayca tarayıp indeksine ekleyebilir. Sunucu hızı, tarama derinliğiyle doğrudan korelasyon gösterir.

3. Yönlendirme Zincirlerinin (Redirect Chains) Kırılması

Sitenizde A sayfasından B'ye, oradan C'ye giden 301 yönlendirmeleri varsa Googlebot her adımda yeni bir istek yapmak zorunda kalır. 2'den fazla adıma sahip yönlendirmeler bot bütçesini sızdırır. İç bağlantıların her zaman doğrudan hedeflenen son URL'ye verilmesi teknik olarak bir zorunluluktur.

"

The Economic Times, teknik SEO çalışmalarında sayfa performansını iyileştirip Core Web Vitals eşiklerini geçtikten sonra, siteden hemen çıkma (bounce) oranında %43'lük bir düşüş kaydetti. Kaynak: How The Economic Times passed Core Web Vitals thresholds and achieved an overall 43% better bounce rate, 2021 Teknik kararlar doğrudan kullanıcı bağlılığına ve SEO görünürlüğüne dönüşür.

5 Infisale Perspektifi: Baştan Optimize Altyapı

Piyasada "SEO eklentisi" kurarak teknik sorunların çözülebileceği yanılgısı yaygındır. Ancak hiçbir eklenti, sunucunun yavaşlığını veya kodun gereksiz eklentilerle şişmiş olmasını düzeltemez. Infisale olarak bizim yaklaşımımız, teknik SEO'yu sonradan yamalanan bir katman olarak değil, **altyapının ana omurgası** olarak kurmaktır.

Sistemimiz, arama motorlarının ve modern GEO yapay zeka ajanlarının en sevdiği teknik mimariyi varsayılan olarak sunar:

Özetle teknik SEO, arama motorlarının sitenizi bulması, anlaması ve yukarı taşıması için gereken altyapı mühendisliğidir. Bu altyapıyı doğru kurduğunuzda, içerik pazarlaması ve semantik SEO çalışmalarınız gerçek karşılığını bulur. Serimizin bir sonraki yazısında, anahtar kelime doldurmanın bittiği 2026 dünyasında Semantik SEO ve Topikal Otorite (Topic Authority) inşasını ele alacağız. Sitenizi bu teknik temeller üzerinde yükseltmek için altyapınızı şimdiden modernize edin.

Ana Çıkarımlar