Teknik SEO ve Site Hızı Optimizasyonu: Google'ın Hız Beklentilerini Karşılama Rehberi

Google'ın PageSpeed Insights raporunuzda kırmızı uyarılar görüyorsanız ya da Search Console'daki "Yetersiz URL'ler" bölümü büyüyorsa, yalnız değilsiniz. Türkiye'deki KOBİ sitelerinin büyük çoğunluğu mobil bağlantı hızlarına göre optimize edilmemiş sunucu altyapısı, sıkıştırılmamış görseller ve render-blocking kaynaklar barındırıyor. Sonuç: Google'ın crawler'ı sayfanızı yavaş buluyor, organik sıralama düşüyor, ziyaretçi sayfa yüklenmeden geri tuşuna basıyor. Bu rehber, teknik SEO'nun ölçülebilir parçalarını — Core Web Vitals'tan sunucu yanıt süresine, JavaScript render sorunlarından yapısal veriye — somut düzeltme adımlarıyla birlikte ele alıyor.

Core Web Vitals Nedir ve Eşik Değerleri Nelerdir?

Google, 2021'de Core Web Vitals'ı resmi bir sıralama sinyali olarak duyurdu. Bu metrikler "gerçek kullanıcı deneyimini" sayısal olarak ifade eder; laboratuvar testi değil, gerçek ziyaretçi verisiyle (field data) ölçülür. Üç temel metrik şunlardır: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ve CLS (Cumulative Layout Shift). 2024 itibarıyla FID (First Input Delay) yerini INP'e bırakmıştır — bu değişiklikten haberdar olmayan ekiplerin raporları hâlâ eski metriği referans gösterebilir, dikkat edin.

LCP, sayfanın görünür alanındaki en büyük içerik bloğunun (genellikle kapak görseli veya büyük bir başlık) yüklenme süresini ölçer. Google'ın "İyi" eşiği 2,5 saniyenin altıdır; 4 saniyenin üzeri "Zayıf" kategorisine girer. INP, kullanıcı etkileşimine (tıklama, dokunma, klavye) verilen yanıt gecikmesini ölçer ve bu gecikmenin 200 milisaniyenin altında kalması beklenir. CLS ise sayfa yüklenirken elemanların ne kadar beklenmedik şekilde kaydığını gösterir; 0,1'in altı "İyi", 0,25'in üzeri "Zayıf" kabul edilir.

• LCP — İyi: <2,5 sn / Geliştirme gerekiyor: 2,5-4,0 sn / Zayıf: >4,0 sn
• INP — İyi: <200 ms / Geliştirme gerekiyor: 200-500 ms / Zayıf: >500 ms
• CLS — İyi: <0,1 / Geliştirme gerekiyor: 0,1-0,25 / Zayıf: >0,25

Görsel Optimizasyonu: En Yüksek Etkili İlk Adım

Sayfa ağırlığının ortalama yüzde altmışından fazlası görselden kaynaklanır. Bu nedenle görsel optimizasyonu, çoğu site için en hızlı kazanımı sağlayan alandır. Modern web formatları olan WebP ve AVIF, aynı kalitede JPEG'e göre sırasıyla yaklaşık yüzde 25-35 ve yüzde 50 daha küçük dosya boyutu sunar (web.dev karşılaştırmalarına göre). Next.js, Gatsby veya benzer modern framework kullanan siteler bu dönüşümü otomatik yapabilir; WordPress tabanlı sitelerde Imagify, ShortPixel gibi eklentiler aynı işlevi görür.

Görsellerin boyutlandırılması da kritiktir. 1920 piksel genişliğinde çekilen bir ürün fotoğrafını 400 piksel geniş bir kutucukta göstermek, gereksiz veri aktarımı demektir. Her görsele srcset ve sizes nitelikleri eklenerek tarayıcının ekran boyutuna uygun çözünürlüğü seçmesi sağlanır. Ekran dışındaki görseller için loading="lazy" özelliği, ilk yüklemede gereksiz istekleri önler. Ancak LCP görseli (sayfa açıldığında hemen görünen en büyük eleman) için lazy-load kullanılmamalı; aksine fetchpriority="high" ile önceliklendirilmelidir.

• JPEG/PNG yerine WebP veya AVIF formatına geçin
• Tüm görsellere doğru width/height nitelikleri yazın (CLS önleme)
• Görünür alanın dışındaki tüm görsellere loading="lazy" ekleyin
• LCP görseline fetchpriority="high" ve preload link etiketi ekleyin
• Maksimum görüntü boyutunu göstered genişlikle eşleştirin (srcset/sizes)

Render-Blocking Kaynaklar, Kritik CSS ve Font Yükleme

Tarayıcı bir sayfayı render etmeden önce tüm CSS dosyalarını ve başlıkta tanımlanan JavaScript dosyalarını indirip işlemek zorundadır. Buna "render-blocking" denir ve LCP süresini doğrudan uzatır. Çözümün ilk katmanı, JavaScript dosyalarını async veya defer nitelikleriyle yüklemektir: async tarayıcıya "bu betiği fırsatın olduğunda indir, hazır olunca çalıştır" der; defer ise DOM hazır olduktan sonra sırayla çalıştırmayı garanti eder. Kritik olmayan üçüncü taraf betikler (sohbet widget'ları, analitik) için type="module" veya bir facade pattern kullanılabilir.

CSS tarafında ise "kritik CSS" kavramı öne çıkar: sayfanın ekranda ilk görünen bölümünü (above the fold) oluşturmak için gereken stilleri satır içi (inline) olarak HTML'in head bölümüne gömmek, geri kalan büyük CSS dosyasının yüklenmesini engellemez hale getirir. Google Fonts başta olmak üzere harici font kaynaklarında FOUT (stillenmemiş metin yanıp sönmesi) ve FOIT (görünmez metin yanıp sönmesi) sorunlarını önlemek için font-display: swap kullanımı önerilir. Fontları kendi sunucunuzdan sunmak (self-hosting) ise DNS çözümleme gecikmesini ortadan kaldırır ve çoğunlukla daha hızlı yükleme sağlar.

INP metriğinin kötü çıktığı durumlarda genellikle uzun görev (long task) sorunu vardır: ana thread'i 50 milisaniyeden fazla meşgul eden JavaScript blokları etkileşim gecikmesine yol açar. Chrome DevTools'un "Performance" sekmesi bu uzun görevleri görselleştirir; React veya Vue gibi framework kullanan sitelerde gereksiz yeniden render ve büyük bundle boyutları birincil şüpheli olmalıdır. Kod bölme (code splitting) ve route tabanlı lazy import, ilk yüklemede indirilen JavaScript miktarını önemli ölçüde azaltabilir.

CDN, Önbellek ve Sunucu Yanıt Süresi (TTFB) Nasıl İyileştirilir?

TTFB (Time to First Byte), tarayıcının ilk HTTP isteğini göndermesinden sunucunun ilk byte'ı geri göndermesine kadar geçen süredir. Google'ın önerisi 800 milisaniyenin altıdır. Yüksek TTFB genellikle üç kaynaktan gelir: aşırı yüklenmiş veya coğrafi olarak uzak sunucu, yavaş veritabanı sorguları, veya önbelleksiz dinamik sayfa üretimi. Türkiye'deki KOBİ sitelerinin önemli bir kısmı yurt dışı sunucularda barındırılır; bu durum tek başına 200-400 ms ekstra gecikme anlamına gelebilir.

İçerik Dağıtım Ağı (CDN) kullanımı, statik dosyaları (görseller, CSS, JS, font) kullanıcıya coğrafi olarak yakın sunucularda önbelleğe alarak hem TTFB'yi hem de toplam yükleme süresini düşürür. Cloudflare, BunnyCDN ve benzeri servisler Türkiye merkezli varlık noktaları (PoP) sunar. Sunucu tarafında HTTP/2 veya HTTP/3 protokolü, çoklu isteğin tek bağlantıda paralel taşınmasını sağlar. Browser önbellekleme için statik dosyalara uzun Cache-Control süreleri (örneğin 1 yıl) ve içerik değiştiğinde URL fingerprinting (örneğin main.abc123.js) kombinasyonu en iyi pratiktir.

• Türkiye trafiği için Türkiye veya Avrupa merkezli sunucu/CDN tercih edin
• Sayfa önbellekleme (Redis, Varnish, edge caching) ile TTFB'yi düşürün
• Statik dosyalara Cache-Control: max-age=31536000, immutable uygulayın
• HTTP/2 veya HTTP/3 protokolünün etkin olduğunu doğrulayın
• TTFB sorununu izole etmek için Chrome DevTools > Network > Timing sekmesini kullanın

Sitenizin Hızını Ücretsiz Analiz Etmemizi İster Misiniz?

ADWEBX olarak 2009'dan bu yana İstanbul merkezli dijital projeler geliştiriyoruz. Sitenizin Core Web Vitals puanlarını, render-blocking kaynaklarını ve teknik SEO engellerini tespit etmek için ücretsiz site analizi sunuyoruz. /analiz sayfamızda birkaç adımda başvurunuzu iletebilir, kapsamlı bir teknik rapor alabilirsiniz. Hızlı dönüş tercih ederseniz WhatsApp danışma hattımızdan da ulaşabilirsiniz — sorunuzu yazmanız yeterli.

Teknik SEO Temelleri: Taranabilirlik ve İndekslenebilirlik

Hız metrikleri iyi olsa bile Googlebot sitenizi doğru tarayıp indeksleyemiyorsa organik sıralama gelişmez. Taranabilirlik (crawlability) ve indekslenebilirlik (indexability) farklı kavramlardır: Google sayfanıza ulaşabilir (taranabilir), ancak onu arama sonuçlarına eklemeyebilir (indekslenemez). robots.txt dosyası hangi alanların taranacağını belirtir; XML sitemap ise keşfedilmesini istediğiniz tüm URL'lerin listesini Google'a iletir. Her iki dosyanın da düzenli olarak güncellenmesi ve Search Console aracılığıyla doğrulanması gerekir.

Canonical tag (rel="canonical"), yinelenen içerik sorunlarını çözer: aynı ürün sayfasının farklı filtre parametreleriyle (örneğin ?renk=kirmizi&boyut=M) onlarca URL oluşturduğu e-ticaret sitelerinde canonical olmadan Google değer dağılımını böler ve ana sayfanın sıralaması düşer. Hreflang etiketi çok dilli sitelerde hangi sayfanın hangi dil/bölge için geçerli olduğunu bildirir ve dilden bağımsız içerik kopyalama cezasını önler. HTTPS zorunluluk haline gelmiştir; karışık içerik uyarıları (HTTP kaynak barındıran HTTPS sayfa), bazı tarayıcılarda kaynak engellenmesine ve güven sinyali kaybına yol açar.

• robots.txt'i Search Console'daki Robots.txt Test Aracı ile doğrulayın
• XML sitemap'i Search Console'a gönderin ve düzenli güncelleyin
• Yinelenen URL'ler için canonical tag doğru kaynak URL'e işaret etmeli
• Çok dilli site varsa hreflang'ı her sayfada her dil varyasyonu için ekleyin
• HTTPS'e geçiş sonrası HTTP->HTTPS 301 yönlendirmelerini kontrol edin
• 4xx hata ve yönlendirme zincirlerini Search Console Kapsam raporundan izleyin

Yapısal Veri (Schema), Mobil-First ve JS-Render Sorunları

Yapısal veri (Schema.org işaretlemesi), Google'ın sayfanızın içeriğini anlam düzeyinde kavramasını sağlar ve zengin sonuç (rich result) görünümüne kapı açar: yıldız derecelendirmeleri, ürün fiyatları, SSS kutuları, tarifler, etkinlikler. Bu tıklama oranını (CTR) doğrudan etkiler. JSON-LD formatı tercih edilen yöntemdir çünkü HTML yapısını bozmadan head bölümüne eklenir. Schema geçerliliğini Google'ın Zengin Sonuç Testi ve schema.org'un validator'ı ile kontrol edin.

Google artık mobil-first indexing kullanmaktadır: bir sayfanın masaüstü sürümü ne kadar zengin olursa olsun, mobil sürüm eksikse ya da farklı içerik barındırıyorsa indekslemede eksik içerik olarak değerlendirilir. Türkiye'de web trafiğinin büyük çoğunluğu mobil cihazlardan gelir; dolayısıyla responsive tasarım ve mobil hız, KOBİ siteleri için masaüstüne göre daha öncelikli bir meseledir.

JavaScript ile render edilen içerik ciddi bir risk noktasıdır. Eğer siteniz içeriği istemci tarafında oluşturuyorsa (Client-Side Rendering, CSR), Googlebot sayfayı ilk ziyaretinde boş HTML görür; JavaScript'i çalıştırıp içeriği render etmek için ek bir "ikinci dalga" tarama gerekir. Bu gecikme indeksleme süresini uzatır ve bazı içerikler hiç indekslenmeyebilir. Sunucu taraflı render (SSR) veya statik oluşturma (SSG), Googlebot'un sayfayı ilk ziyarette dolu HTML olarak görmesini sağlar ve hem indeksleme hem sıralama açısından belirgin avantaj sunar.

Ölçüm Araçları: PageSpeed Insights, Lighthouse, Search Console ve CrUX

PageSpeed Insights (PSI), hem laboratuvar hem de gerçek alan (field) verisi sunan Google'ın ücretsiz aracıdır. Laboratuvar verisi, her seferinde kontrollü koşullarda aynı sanal makine ortamında ölçüm yapar; hızlı geri bildirim için değerlidir. Alan verisi ise Chrome Kullanıcı Deneyimi Raporu'ndan (CrUX) beslenir: gerçek Chrome kullanıcılarının son 28 günlük deneyimlerinin agregasyonudur. Sıralama sinyali olarak kullanılan metrik alan verisidir; laboratuvarda 100 puan alan bir site, gerçek kullanıcı koşullarında yine de düşük CWV puanına sahip olabilir.

Google Search Console'daki "Core Web Vitals" raporu, sitenizin hangi URL'lerinin yetersiz veya iyileştirme gerektiren durumda olduğunu URL grubu bazında gösterir. Bu raporda tespit edilen sorunlu URL'leri düzelttikten sonra "Doğrulama İste" butonuyla Google'ın yeniden değerlendirmesini talep edebilirsiniz. Lighthouse, Chrome DevTools veya Node CLI aracılığıyla çalıştırılabilen bir denetim aracıdır; performansın yanı sıra erişilebilirlik, SEO kontrol listesi ve en iyi uygulamalar için de puanlama sunar. Düzenli Lighthouse denetimleri, deploy öncesi hız regresyonlarını erken yakalamaya yardımcı olur.

• PageSpeed Insights: hem mobil hem masaüstü için ayrı ayrı test edin
• Search Console > Core Web Vitals raporunu haftalık inceleyin
• Lighthouse: her büyük özellik deploy'u öncesinde çalıştırın
• CrUX Dashboard (Looker Studio şablonu): site geneli trend takibi için kullanın
• Alan verisi ile laboratuvar verisi arasındaki büyük farkı araştırın (üçüncü taraf betikler, A/B testleri)

Hangi Düzeltmeyle Başlamalı? Etki-Çaba Öncelik Çerçevesi

Teknik SEO ve hız optimizasyonu listesi uzadıkça yönetilmesi güçleşir. Pratikte en verimli yaklaşım, her düzeltmeyi "beklenen sıralama/hız etkisi" ile "uygulama süresi ve maliyeti" eksenlerinde değerlendirmektir. Çoğu site için en yüksek etki-çaba oranına sahip düzeltmeler şunlardır: görsel formatı dönüşümü (WebP/AVIF), LCP görselinin önyüklemesi (preload), render-blocking JS kaldırma ve sunucu önbelleklemesi. Bu dört adım birlikte uygulandığında LCP süresinde kayda değer iyileşme gözlemlenir.

Orta öncelikte yer alan konular — kritik CSS çıkarımı, font self-hosting, kod bölme, canonical + hreflang denetimi — genellikle bir geliştirici sprintiyle kapanabilir. Düşük öncelikli ama ihmal edilmemesi gereken alanlar ise yapısal veri zenginleştirmesi, CLS ince ayarları ve üçüncü taraf betik denetimi olarak sıralanabilir. Önceliği yanlış kurmak, ekibin zamanını ölçülemeyen kazanımlara harcaması anlamına gelir; bu nedenle ölçüm-düzeltme-doğrulama döngüsü her zaman temel prensip olarak kalmalıdır.

Teknik SEO denetimini kendi başınıza yürütmek zaman alıcı ve hata riski yüksek bir süreçtir. ADWEBX olarak sitenizin tam teknik fotoğrafını çıkarmak için ücretsiz site analizi sunuyoruz: /analiz sayfamızdan başvurabilir, sıralama kayıplarınızın arkasındaki teknik engelleri net olarak görebilirsiniz. Daha hızlı iletişim için WhatsApp danışma hattımız her zaman açık — teknik bir sorunuz varsa doğrudan yazın.

Sık Sorulan Sorular

Core Web Vitals puanım düşük ama sıralamam iyi — neden optimize etmeliyim?

Mevcut sıralama diğer güçlü sinyaller (kaliteli backlink, içerik otoritesi) sayesinde korunuyor olabilir. Ancak rakipleriniz teknik performanslarını iyileştirdikçe CWV sinyali tiebreaker olarak devreye girer. Ayrıca düşük hız, hemen çıkma oranını (bounce rate) artırarak zaten kazandığınız trafikten dönüşüm almanızı engeller. Kısaca: sıralama korunsa bile gelir kaybı devam edebilir.

LCP görselim optimize edildi ama puanim hâlâ düşük — başka ne bakmalıyım?

LCP yalnızca görsel boyutuyla sınırlı değildir. Sunucudan ilk byte geç geliyorsa (yüksek TTFB), render-blocking CSS/JS görsel indirilmeden önce ana thread'i meşgul ediyorsa ya da LCP görseli geç keşfediliyorsa (HTML'de değil, CSS background-image veya JavaScript ile oluşturuluyorsa), optimize edilmiş bir görsel yine de geç yüklenir. LCP'yi bileşenlerine ayırmak için Chrome DevTools > Performance kaydını inceleyin.

Googlebot JavaScript'i render ediyor mu, benim için önemli mi?

Evet, Googlebot modern JavaScript'i render edebiliyor; ancak bu render işlemi ilk taramadan saatler hatta günler sonra gerçekleşen ikinci bir adımdır. Bu gecikme, yeni içeriğin indekslenmesini önemli ölçüde yavaşlatır. Eğer siteniz ağırlıklı olarak CSR (React/Vue SPA) kullanıyorsa kritik içeriği — başlık, meta tag, ana metin — SSR veya prerender ile ilk HTML yanıtına dahil etmek hem indeksleme hızını hem sıralamayı doğrudan etkiler.

INP metriğini iyileştirmek için nereden başlamalıyım?

INP sorunlarının büyük çoğunluğu uzun JavaScript görevlerinden kaynaklanır. Chrome DevTools Performance panelinde "Long Tasks" işaretliyken kayıt alın, hangi fonksiyonun 50 ms'yi aştığını tespit edin. React tabanlı sitelerde gereksiz yeniden render, büyük state güncellemeleri ve senkron veri işlemleri başlıca nedenlerdir. Görevleri setTimeout ile parçalara bölmek (task chunking), ağır işlemleri Web Worker'a taşımak veya Transition API ile öncelik atamak pratik çözümlerdir.

Teknik SEO denetimi için hangi araçlara öncelik vermeliyim?

Başlangıç için Google Search Console (ücretsiz, alan verisi + indeksleme durumu) ve PageSpeed Insights (ücretsiz, laboratuvar + CrUX) temel araçlardır. Daha kapsamlı site taraması için Screaming Frog SEO Spider (500 URL'ye kadar ücretsiz) kırık bağlantı, yönlendirme zinciri, canonical hataları ve meta tag sorunlarını tespit eder. Teknik denetimi uzman bir ekiple yürütmek istiyorsanız ADWEBX'in ücretsiz site analizi (/analiz) tüm bu kontrolleri yapılandırılmış bir raporla sunar.