Teknik SEO Nedir? Uygulamalı Denetim ve Kontrol Listesi

Teknik SEO; arama motorlarının sitenizi keşfetmesini, taramasını, içeriği işlemesini ve doğru URL’yi dizine eklemesini destekleyen çalışmalardır. İyi içerik kadar, o içeriğin erişilebilir olması da gerekir. Teknik uygunluk ise tek başına sıralama garantisi değildir.

Bu rehberde tarama ve indeksleme, hız, site mimarisi, sitemap, yapılandırılmış veri, JavaScript ve yapay zekâ tarayıcılarını ele alıyoruz. Her şeyi sırayla okumak yerine yaşadığınız sorundan başlayabilirsiniz.

Çalışmanın planlanması ve uygulanması için SEO hizmet kapsamımızı inceleyebilirsiniz. Buradaki rehber, teknik kontrolleri kendiniz yapabilmeniz için hazırlanmıştır.

Teknik SEO neyi kapsar?

Bir sayfanın arama sonucunda yer alabilmesi için arama motorunun onu bulması, alması, işlemesi ve dizine eklemesi gerekir. Teknik SEO bu zincirin her halkasındaki engeli bulur ve kaldırır. Aşağıdaki liste, rehberdeki bölümlerin hangi aşamaya karşılık geldiğini gösterir.

• Keşif: URL’nin iç bağlantılar ve XML sitemap ile bulunması. Bkz. site mimarisi ve sitemap.
• Tarama: robots.txt izinleri, HTTP durum kodları ve sunucu yanıtı. Bkz. tarama ve indeksleme.
• Render: JavaScript ile oluşan içeriğin ve bağlantıların görülebilmesi. Bkz. JavaScript SEO.
• İndeksleme: noindex, canonical ve yinelenen URL’ler arasında doğru adresin seçilmesi. Bkz. canonical.
• Sunum ve deneyim: Core Web Vitals, mobil uyum, HTTPS ve yapılandırılmış veri. Bkz. performans ve schema.

Teknik SEO, sayfa içi SEO ve site dışı SEO farkı

SEO çalışması genellikle üç alana ayrılır. Sınırlar kesin değildir; örneğin title etiketi hem sayfa içi çalışmada hem teknik denetimde kontrol edilir. Ayrım, sorunu doğru kişiye ve doğru araca yönlendirmek için işe yarar. Üç alanın tek bir çalışmada nasıl incelendiğini ve bulguların nasıl önceliklendirildiğini SEO analizi rehberinde anlattık.

“Sayfa içi teknik SEO” ifadesiyle genellikle iki alanın kesiştiği işler kastedilir: title ve meta etiketlerinin her sayfada tekil olması, başlık hiyerarşisi, görsel boyutları, sayfa bazında canonical ve robots etiketleri. SEO’nun bütün türlerini SEO türleri bölümünde, site dışı tarafı backlink rehberinde bulabilirsiniz. Bu rehber yalnız teknik katmanı ele alır.

Tarama ve indeksleme

Arama motorlarının sitenizi bulabilmesi, tarayabilmesi ve indeksleyebilmesi, görünürlüğünüz için ön koşuldur. Bu bölümde, crawling ve indexing süreçlerinde karşılaşılan en yaygın sorunları ve çözümlerini ele alacağız.

Crawling Nedir, Nasıl Çalışır?

Crawling, arama motorlarının web sitelerindeki içeriği keşfetme ve toplama sürecidir. Arama motoru botları (Googlebot gibi), bir sayfayı ziyaret eder, içeriğini okur ve o sayfadaki linkleri takip ederek yeni sayfalar keşfeder.

Crawling Süreci:

1. Bot Ana Sayfaya Gelir
   ↓
2. İçeriği ve Linkleri Okur
   ↓
3. Bulunan Linkleri Takip Eder
   ↓
4. Yeni Sayfaları Keşfeder
   ↓
[Döngü devam eder]

Site Indexing Kontrolü

Önce kontrol edeceğiniz URL’yi belirleyin. Google’da site:alanadi.com araması hızlı bir fikir verir; tüm indekslenmiş URL’leri veya güvenilir bir toplam sayıyı göstermez.

1. Search Console’da URL Denetimi’ni açın; URL’nin indeks durumunu, son taramayı ve Google’ın seçtiği canonical’ı inceleyin.
2. Canlı testle sayfanın şu anda erişilebilir olup olmadığını kontrol edin. Canlı test, URL’nin dizine eklendiğini veya ekleneceğini kanıtlamaz.
3. Sayfa Dizine Ekleme raporunda aynı sorunun başka URL’lerde bulunup bulunmadığına bakın.

Robots.txt Optimizasyonu

robots.txt, uyumlu botların hangi URL’leri tarayabileceğini belirtir. Tarama kontrolü, arama sonuçlarından çıkarma ve özel içeriği koruma farklı işlerdir.

Robots.txt’nin “Rehber” Rolü

Gereksiz filtre kombinasyonları gibi geniş URL kümelerinde taramayı sınırlandırmak için kullanılabilir. Küçük bir sitede, ölçülmüş bir ihtiyaç yokken yeni engeller eklemek yerine önemli sayfaların erişilebilirliğini kontrol edin.

Örnek Senaryo: E-Ticaret Sitesi

Ürün, kategori ve arama talebi olan seçilmiş filtre sayfaları taranabilir kalmalıdır. Sıralama parametreleriyle üretilen çok sayıda eşdeğer URL için ayrı politika gerekir. Her filtreyi aynı kuralla kapatmayın.

User-agent: *
Disallow: /*?sirala=
Disallow: /*&sirala=

Bu örnek yalnız sirala parametresini hedefler. Gerçek URL yapınızda ilk ve sonraki parametre konumlarını test edin; kuralı doğrudan kopyalamayın. Shopify’da varsayılan robots.txt dosyası sort_by ve birleşik filtre parametrelerini zaten engeller; robots.txt.liquid dosyasını düzenlemeden önce Shopify robots.txt bölümüne bakın. Sayfanın anlaşılması için gereken CSS ve JavaScript kaynaklarını erişilebilir tutun.

Önemli Uyarı: Robots.txt Gizlemez, Yönlendirir

• Taramayı durdurmak: robots.txt kullanılabilir; URL yine de başka kaynaklardan keşfedilip sonuçlarda görünebilir.
• İndekslenmesini istememek: Taranabilir sayfada noindex kullanın. Google engellenmiş sayfanın etiketini okuyamaz.
• Gizli içeriği korumak: Kimlik doğrulama ve erişim kontrolü gerekir; noindex güvenlik sağlamaz.

Duplicate Versions (HTTP / HTTPS / WWW) Sorunu

HTTP/HTTPS ve www/www’suz adreslerde aynı içerik açılıyorsa tercih edilen alan adını belirleyin. Diğer sürümleri, yol ve gerekli sorgu bilgilerini koruyarak doğru HTTPS adresine kalıcı yönlendirin. İç linkler, canonical ve sitemap aynı tercihi desteklemelidir.

Testi yalnız ana sayfada yapmayın: bir ürün, hizmet ve blog URL’sini de kontrol edin. Tarayıcı geliştirici araçlarının Network bölümünde ilk yanıtı ve ulaşılan son adresi görün. Search Console’da ayrıca bir “tercih edilen alan adı” ayarı aramanıza gerek yoktur.

Shopify gibi yönetilen platformlarda alan adı ayarlarını kullanın. Apache/Nginx kuralları ise yalnız o sunucuları yönettiğiniz kurulumlarda uygulanır.

Canonical Etiketi ve Kanonikleştirme

Canonical, aynı veya çok benzer içeriğe sahip URL’ler arasında tercih edilen adresi belirtir. Google için güçlü bir sinyaldir; kesin bir emir değildir. Sitemap desteği daha zayıf bir sinyaldir. İç bağlantıların da tercih edilen adrese gitmesi tutarlılık sağlar.

<link rel="canonical" href="https://example.com/urun/ayakkabi">

• Asıl sayfada kendisini, eşdeğer kopyalarda asıl sayfayı gösterin.
• Mutlak HTTPS adresi kullanın; hedefin erişilebilir ve indekslenebilir olduğunu doğrulayın.
• Tema, eklenti ve JavaScript’in birbiriyle çelişen canonical üretmediğini kontrol edin.
• Birbirinden farklı içerikleri yalnızca aynı konuda oldukları için tek canonical altında toplamayın.

noindex aramada yer almama isteğidir; kopyaların sinyallerini birleştirme aracı değildir. Amaç birleştirmekse canonical veya uygun yönlendirme kullanın. Amaç URL’yi kaldırmaksa indeksleme kontrolünü ayrı planlayın.

Google farklı canonical seçtiğinde iki URL’nin içeriklerini, iç linklerini ve sitemap kaydını karşılaştırın. Seçim bazen beklenen bir sonuçtur; her farklılık düzeltilmesi gereken hata değildir.

Redirect Chains ve Redirect Loops (301 Karmaşası)

Yönlendirme zinciri, bir URL’nin aradaki adresler üzerinden hedefe ulaşmasıdır. Döngüde ise URL’ler birbirine yönlenir ve sayfa açılamaz.

Zincir:  Eski URL → Ara URL → Yeni URL
Tercih:  Eski URL → Yeni URL
Döngü:   URL A → URL B → URL A

Kalıcı yönlendirmeler otomatik PageRank kaybı oluşturmaz. Buna rağmen zincirler ek istek ve gecikme yaratır; çok uzun zincirler tarama sorununa dönüşebilir. Eski adresi doğrudan ilgili son sayfaya yönlendirin, site içi linkleri de yeni adrese güncelleyin.

Kontrol ederken ilk yanıtın durum kodunu, Location başlığını ve son sayfanın 200 yanıtını birlikte kaydedin. Kalıcı taşımada 301/308, gerçekten geçici durumda 302/307 kullanın. Her eski sayfayı ana sayfaya göndermek doğru eşlemenin yerini tutmaz.

Server Errors (5xx Hataları) ve SEO Etkisi

500 uygulama/sunucu hatası, 502 geçersiz üst sunucu yanıtı, 503 geçici hizmet verememe, 504 ise üst sunucunun zaman aşımı anlamına gelir. Tek bir kısa kesinti ile önemli sayfaları sürekli etkileyen hata aynı öncelikte değildir.

1. Search Console Tarama İstatistikleri ve sunucu/CDN kayıtlarında hangi URL’lerin, ne zamandan beri etkilendiğini belirleyin.
2. Son dağıtımı, eklenti değişikliğini ve kaynak kullanımını kontrol edin. Canlı sitede rastgele ayar değiştirmek yerine bulguyu geliştirici veya sağlayıcıya iletin.
3. Düzeltmeden sonra örnek URL’leri ve kritik formları yeniden test edin; hata oranının normale döndüğünü izleyin.

Planlı bakımda geçici 503 ve uygun Retry-After başlığı kullanılabilir. Uzayan 5xx yanıtları tarama ve indekslemeyi etkileyebilir; 503 eski indeks kaydının süresiz korunacağını garanti etmez.

Crawl Budget Optimizasyonu

Tarama bütçesi, tarayıcının kapasitesi ve tarama talebiyle ilişkilidir. Büyük, sık değişen veya çok fazla gereksiz URL üreten sitelerde anlamlı bir inceleme konusudur. Küçük bir sitede indeksleme sorununun nedenini peşinen bütçeye bağlamayın.

Önce Search Console Tarama İstatistikleri’nde istekleri, yanıt sürelerini ve sunucu hatalarını inceleyin. Önemli URL’lerin keşfedilmesini zorlaştıran mimariyi, sonsuz filtre kombinasyonlarını ve yönlendirme zincirlerini düzeltin.

noindex taramayı hemen durdurmaz: botun etiketi görmek için sayfaya erişmesi gerekir. Aramadan çıkarma hedefi ile tarama tasarrufu hedefini ayrı değerlendirin. Ayrıntılı inceleme gerekiyorsa log analizi bölümüne geçin.

Googlebot’un Sayfa Başına İndirme Limiti (2 MB)

Google’ın güncel belgesine göre (son güncelleme 3 Şubat 2026) Search için Googlebot, desteklenen dosyaların ilk 2 MB’ını; PDF dosyalarının ilk 64 MB’ını tarar. Sınır sıkıştırılmamış veriye uygulanır. HTML’de referans verilen CSS ve JavaScript dosyaları ayrı alınır; toplam sayfa indirme boyutunu HTML sınırıyla karıştırmayın.

Gereksiz büyük HTML ve gömülü veriyi azaltın. Kritik içeriğin yanıt içinde bulunduğunu doğrulayın; yalnızca schema’yı başa taşımak performans veya indeksleme çözümü değildir.

SEO Açısından HTTP Durum Kodları

404 mü, 410 mu?

404 kaynağın bulunamadığını, 410 kaldırıldığını bildirir. Google bu kodları genel olarak aynı şekilde işler; 410 için daha hızlı kaldırılma sözü vermeyin. Uygun bir yeni karşılık varsa kalıcı yönlendirin. Yoksa gerçek hata kodunu ve ziyaretçiye yardımcı bağlantıları sunun; ilgisiz bir sayfaya yönlendirmeyin.

Kontrol Listesi: Crawling ve Indexing

Hemen Yapılması Gerekenler:

• Sitenizin indekslendiğini kontrol edin (site:alanadi.com)
• Google Search Console’da “Sayfalar” raporunu inceleyin
• Robots.txt dosyanızı kontrol edin, önemli sayfaları engellememekten emin olun
• HTTP/HTTPS ve WWW kopyalarını kontrol edin
• Tercih ettiğiniz domain versiyonuna 301 redirect yapın
• Her sayfada canonical tag olduğundan emin olun

Haftalık/Aylık Bakım:

• Redirect chain ve loop taraması yapın
• 5xx server hatalarını kontrol edin
• Tarama İstatistikleri raporunda hata ve yanıt süresini izleyin (küçük sitelerde tarama bütçesi nadiren sorundur)
• Yeni hataları düzenli kontrol edin

Unutmayın:

• Crawling ve indexing, SEO’nun temel taşıdır
• İçeriğiniz mükemmel olabilir, ama indekslenmemişse görünmezsiniz
• Bu sorunların çoğu kolay düzeltilebilir ama büyük etki yaratır
• Düzenli monitoring yapın, sorunları erken tespit edin

Site performansı ve kullanıcı deneyimi

Site performansı ve kullanıcı deneyimi (UX), modern SEO’nun vazgeçilmez unsurlarıdır. Google’ın sıralama sistemleri Core Web Vitals ölçümlerinden yararlanır; iyi sonuçlar tek başına üst sırayı garanti etmez, zayıf sonuçlar ise kullanıcıyı ve dönüşümü doğrudan etkiler. Hızlı, mobil uyumlu ve güvenli bir site oluşturmak, hem kullanıcılarınızı mutlu eder hem de arama motorlarında daha iyi sıralamanıza yardımcı olur. Bu bölüm metrikleri ve teknik çözümleri anlatıyor; ölçüm araçlarını adım adım kurmak için site hızı testi ve optimizasyonu rehberine bakabilirsiniz.

Core Web Vitals: Google’ın Performans Metrikleri

Core Web Vitals yükleme, etkileşime yanıt ve görsel kararlılığı ölçer. web.dev’in Web Vitals açıklamasına göre iyi eşikler LCP için 2,5 saniye, INP için 200 ms, CLS için 0,1 veya altıdır. Değerlendirme, mobil ve masaüstü ayrı ele alınarak ziyaretlerin 75. yüzdelik diliminde yapılır.

Tek bir Lighthouse skoru bu değerlendirmeyle aynı değildir. Sayfa türü, cihaz, ağ ve gerçek kullanıcı deneyimi birlikte incelenmelidir.

1. LCP (Largest Contentful Paint) – Yükleme Hızı

LCP Nedir?

LCP, sayfanın görünen alanındaki (viewport) en büyük içerik öğesinin ne kadar sürede yüklendiğini ölçer. Bu, kullanıcının “sayfa yüklendi” algısını en iyi yansıtan metriktir.

LCP’ye Etki Eden Öğeler:

• Büyük görseller (<img>)
• Video poster görselleri
• Arka plan görselleri (CSS background-image)
• Büyük metin blokları

LCP Değerlendirmesi:

🟢 İYİ:    0 - 2,5 saniye
🟡 ORTA:   2,5 - 4,0 saniye
🔴 KÖTÜ:   4,0+ saniye

LCP’yi İyileştirme Stratejileri:

A. Görselleri Optimize Edin

<!-- ❌ KÖTÜ: Optimize edilmemiş büyük görsel -->
<img src="hero-image.jpg" alt="Ana görsel">
<!-- Dosya boyutu: 5MB -->

<!-- ✅ İYİ: Optimize edilmiş, modern format, LCP görseli için eager + yüksek öncelik -->
<img 
  src="hero-image.webp" 
  alt="Ana görsel"
  width="1200" 
  height="600"
  loading="eager"
  fetchpriority="high"
>
<!-- Dosya boyutu: 200KB -->

Görsel Optimizasyon Kontrol Listesi:

• WebP veya AVIF formatı kullanın (JPEG/PNG yerine)
• Görselleri sıkıştırın (TinyPNG, ImageOptim)
• Doğru boyutta görseller kullanın (gereksiz büyük görseller yüklemeyin)
• Width ve height attribute’leri ekleyin (CLS’yi de iyileştirir)
• Özellikle LCP görseli için loading="eager" ve fetchpriority="high" kullanın
• CDN kullanın (görselleri daha hızlı sunmak için)

B. Sunucu Yanıt Süresini İyileştirin (TTFB)

TTFB (Time To First Byte): Tarayıcının sunucudan ilk byte'ı 
alması için geçen süre

TTFB: sunucu, ağ ve önbellek gecikmesini birlikte inceleyin.

TTFB İyileştirme:

• Sunucu kapasitesini ve yanıt süresini ölçün; barındırma kararını veriye göre verin
• Server-side caching aktif edin (Redis, Memcached)
• CDN kullanın
• Veritabanı sorgularını optimize edin
• PHP versiyonunu güncel tutun

Bu liste kendi sunucunuzu yönettiğiniz kurulumlar içindir. Shopify gibi yönetilen platformlarda sunucu tarafı ayarlara erişemezsiniz; orada tema kodu, uygulamalar ve görseller üzerinden ilerleyin: Shopify site hızı ve Core Web Vitals.

Ziyaretçinin konumu, sunucu yanıtı ve CDN önbelleği birlikte ölçülmelidir. Yakın konum tek başına hızlı yanıt garantisi vermez.

web.dev’in kaba eşiğine göre TTFB için 0,8 saniye ve altı iyi, 1,8 saniyenin üstü zayıf kabul edilir. TTFB bir Core Web Vitals metriği değildir; LCP’yi doğrudan geciktirdiği için izlenir. PageSpeed Insights veya Lighthouse’ta “İlk sunucu yanıt süresini azaltın” gibi bir öneri görüyorsanız (öneri adı araç sürümüne göre değişebilir), sorun HTML belgesinin sunucudan gelişindedir. WordPress’te önce sayfa önbelleğinin gerçekten devrede olduğunu, yavaş eklenti sorgularını ve barındırma kaynaklarını kontrol edin; görselleri küçültmek bu öneriyi çözmez.

C. Render-Blocking Kaynaklarını Azaltın

<!-- ❌ KÖTÜ: Render-blocking CSS -->
<link rel="stylesheet" href="style.css">

<!-- ✅ İYİ: Kritik CSS inline, geri kalan async -->
<style>
  /* Critical CSS inline olarak buraya */
  body { margin: 0; font-family: Arial; }
  .hero { background: #000; }
</style>
<link rel="preload" href="style.css" as="style" onload="this.rel='stylesheet'">

JavaScript için:

<!-- ❌ KÖTÜ: Render-blocking JS -->
<script src="script.js"></script>

<!-- ✅ İYİ: Defer veya async kullanın -->
<script src="script.js" defer></script>
<!-- veya -->
<script src="analytics.js" async></script>

Defer vs Async:

Defer:  HTML parse → JS indir → HTML bitti → JS çalıştır
Async:  HTML parse || JS indir → JS çalıştır (hemen)

Defer:  Sıralı çalışma garantisi (bağımlılıklar için)
Async:  Bağımsız scriptler için (analytics, ads)

D. Preload Kritik Kaynakları

<head>
  <!-- LCP görselini önceden yükle -->
  <link rel="preload" as="image" href="hero-image.webp">
  
  <!-- Kritik fontları önceden yükle -->
  <link rel="preload" as="font" href="font.woff2" type="font/woff2" crossorigin>
  
  <!-- Kritik CSS'i önceden yükle -->
  <link rel="preload" as="style" href="critical.css">
</head>

2. INP (Interaction to Next Paint) – Etkileşim Yanıt Hızı

INP, sayfa yaşamı boyunca tıklama, dokunma ve klavye etkileşimlerine yanıtı değerlendirir. Gecikme; olayın başlamasını bekleme, işlem süresi ve sonraki görüntünün çizilmesi aşamalarından oluşur. İyi değer 200 ms veya altıdır; 200–500 ms iyileştirme gerektirir, 500 ms üzeri zayıftır.

1. DevTools Performance kaydında yavaş etkileşimi yeniden üretin. Sorun menü açılırken mi, filtre seçilirken mi, form gönderilirken mi oluşuyor?
2. Etkileşim işleyicisindeki gereksiz işleri çıkarın. Uzun işlemleri parçalara bölün; uygun hesaplamalarda Web Worker değerlendirin.
3. Üçüncü taraf scriptleri ve büyük DOM güncellemelerini inceleyin. Scripti üç saniye geciktirmek, maliyetini ortadan kaldırmaz.
4. Görsel geri bildirimi geciktirmeyin. Debounce/throttle bazı akışlarda gereksiz işi azaltabilir; tek başına INP çözümü veya garantili ölçüm iyileştirmesi değildir.

Google Tag Manager etiket yönetimini kolaylaştırabilir; içine eklenen etiketlerin performans maliyeti ayrıca denetlenmelidir.

async function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    await globalThis.scheduler.yield();
  } else {
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

async function processInBatches(items, processItem) {
  const batchSize = 50;
  for (let i = 0; i < items.length; i += batchSize) {
    for (const item of items.slice(i, i + batchSize)) {
      processItem(item);
    }
    await yieldToMain();
  }
}

Örnek, uzun işi görevler arasında böler. Parti büyüklüğünü gerçek işin maliyetine göre ölçerek seçin; tek bir öğe bile uzun sürüyorsa algoritmayı veya çalışma katmanını değiştirin.

3. CLS (Cumulative Layout Shift) – Görsel Kararlılık

CLS Nedir?

CLS, sayfanın yaşamı boyunca oluşan beklenmedik yerleşim kaymalarını ölçer. Yükleme sonrasında eklenen içerikler de soruna neden olabilir.

CLS Değerlendirmesi:

🟢 İYİ:    0 - 0,1
🟡 ORTA:   0,1 - 0,25
🔴 KÖTÜ:   0,25+

Search Console’un Core Web Vitals raporu, benzer sayfaları gruplar ve grubun 75. yüzdelik değeri eşiği aştığında “CLS sorunu: 0,25’ten fazla (mobil)” benzeri bir satır gösterir. Raporda görünen örnek URL bütün grubu temsil eder; düzeltmeyi o şablonda yapın ve doğrulamayı ancak değişiklik yayındayken başlatın.

Yaygın CLS Sebepleri:

1. Boyut belirtilmemiş görseller ve videolar
2. Dinamik olarak eklenen içerik (reklamlar)
3. Web fontları yüklenirken metin değişimi
4. Async yüklenen içerikler

CLS’yi İyileştirme Stratejileri:

A. Görsellere ve Videolara Boyut Verin

<!-- ❌ KÖTÜ: Boyut yok, layout shift olur -->
<img src="product.jpg" alt="Ürün">

<!-- ✅ İYİ: Width ve height belirtilmiş -->
<img 
  src="product.jpg" 
  alt="Ürün"
  width="800"
  height="600"
>

<!-- ✅ DAHA İYİ: Aspect-ratio ile responsive -->
<img 
  src="product.jpg" 
  alt="Ürün"
  style="aspect-ratio: 4/3; width: 100%; height: auto;"
>

CSS ile:

/* Responsive görseller için aspect-ratio kullanın */
.video-poster {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

B. Reklamlar ve Embed’ler için Yer Ayırın

<!-- ❌ KÖTÜ: Reklam için yer ayrılmamış -->
<div id="ad-container">
  <!-- Reklam async yükleniyor -->
</div>

<!-- ✅ İYİ: Minimum yükseklik ile yer ayrılmış -->
<div id="ad-container" style="min-height: 250px;">
  <!-- Reklam yüklenene kadar 250px yer ayrılmış -->
</div>

YouTube Embed için:

<!-- Aspect-ratio ile embed container -->
<div style="position: relative; padding-bottom: 56.25%; height: 0;">
  <iframe 
    src="https://www.youtube.com/embed/VIDEO_ID"
    style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
    frameborder="0"
    allowfullscreen>
  </iframe>
</div>

C. Font Loading Stratejisini Optimize Edin

/* ❌ KÖTÜ: FOIT (Flash of Invisible Text) */
@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2');
}

/* ✅ İYİ: font-display ile kontrol */
@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2');
  font-display: swap; /* veya optional */
}

Font-display seçenekleri:

auto:     Tarayıcı kararı (genellikle block)
block:    3 saniye bekle, sonra fallback (FOIT)
swap:     Hemen fallback göster, font gelince değiştir (FOUT)
fallback: 100ms bekle, 3 saniye fallback, sonra vazgeç
optional: Hızlı bağlantıda yükle, yavaşsa vazgeç

Font stratejisini metnin görünürlüğü ve yerleşim kaymasıyla birlikte test edin. font-display: swap metni erken gösterebilir; font değişimindeki boyut farkları yine CLS oluşturabilir.

D. Dinamik İçeriği Doğru Yönetin

/* Dinamik yüklenen içerik için placeholder */
.content-placeholder {
  min-height: 400px;
  background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
  background-size: 200% 100%;
  animation: loading 1.5s infinite;
}

@keyframes loading {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

CLS İyileştirme Kontrol Listesi:

• Tüm görsellere width ve height attribute’leri ekleyin
• Görselin gerçek oranına uygun CSS aspect-ratio kullanın
• Reklamlar için yer ayırın (min-height)
• Web fontları için font-display: swap veya optional kullanın; font değişiminin yerleşimi kaydırıp kaydırmadığını test edin
• Dinamik içerik için placeholder kullanın
• Banner’lar için sabit alan ayırın
• Animasyonları transform ile yapın (layout değişikliği yerine)

Core Web Vitals Nasıl Ölçülür?

Adım adım test ve rapor okuma için: site hızı testi nasıl yapılır ve hız raporu nasıl okunur.

Search Console: Benzer deneyim gösteren URL gruplarını ve gerçek kullanıcı verisindeki sorunları inceleyin.

PageSpeed Insights: Üstteki alan verisi ile alttaki laboratuvar testini ayırın. Verinin tek URL’ye mi alan adına mı ait olduğuna bakın; düşük trafikte alan verisi bulunmayabilir.

DevTools: Yavaş sayfanın ağ ve Performance kaydını inceleyin. Menü açma, filtreleme ve form kullanma gibi etkileşimleri de test edin; yalnız ilk yükleme testi INP teşhisi için yeterli değildir.

Düzeltme sonrası laboratuvar testi hızlı karşılaştırma sağlar; gerçek kullanıcı raporunun değişikliği yansıtması zaman alır. Aynı cihaz/ağ koşullarında birkaç ölçüm yapın, tek iyi sonucu seçmeyin.

Görsel ve Video Teknik SEO’su

LCP bölümünde görselleri hız açısından ele aldık. Ama görsellerin ikinci bir işi daha var: kendileri de arama sonucu. Google Görseller ciddi bir trafik kanalı ve çoğu sitede tamamen ihmal ediliyor.

Responsive görseller: srcset ve sizes

Tek bir büyük görseli her cihaza göndermek, mobilde hem bant genişliği hem LCP israfıdır. Doğrusu, tarayıcının kendi ekranına uygun dosyayı seçmesine izin vermektir:

<img
  src="urun-800.webp"
  srcset="urun-400.webp 400w,
          urun-800.webp 800w,
          urun-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="800" height="600"
  alt="Siyah deri spor ayakkabı, yandan görünüm"
  loading="lazy"
  decoding="async"
>

sizes değerini yanlış yazmak sık yapılan bir hatadır: tarayıcıya “bu görsel ekranda ne kadar yer kaplayacak” dersiniz. Yanlış değer, gereğinden büyük dosya indirilmesine yol açar.

Alt metni: erişilebilirlik ve sıralama

• Görselin ne olduğunu anlatın, anahtar kelime doldurmayın. “Siyah deri spor ayakkabı” iyi; “ayakkabı satın al ucuz ayakkabı spor ayakkabı” spam.
• Dekoratif görsellerde alt="" bırakın — ekran okuyucu atlar. alt özniteliğini tamamen silmeyin.
• Dosya adı da bir sinyaldir: IMG_4821.jpg yerine siyah-deri-spor-ayakkabi.webp.

LCP görseline lazy loading uygulamayın. Yüksek indirme önceliğini gerçekten kritik görseller için kullanın; ilk ekrandaki her görsele vermek önceliklendirmeyi zayıflatabilir. Aşağıdaki uygun görsellerde lazy loading kullanılabilir.

Arama sonucundaki küçük resim

Google, Mart 2026’da belgelerine eklediği açıklamaya göre arama sonuçları ve Discover’daki küçük resmi seçerken schema.org işaretlemesindeki görseli ve og:image meta etiketini birlikte kaynak olarak kullanır. İkisinin de sayfayı temsil eden, erişilebilir aynı görseli göstermesi tutarlılık sağlar; hangi görselin seçileceğinin garantisi değildir.

Görsel sitemap’i

Görselleriniz JavaScript ile yükleniyorsa veya CDN’den farklı bir alan adından geliyorsa, Google onları kaçırabilir. XML sitemap’e görsel uzantısı ekleyin:

<url>
  <loc>https://alanadi.com/urun/ayakkabi</loc>
  <image:image>
    <image:loc>https://cdn.alanadi.com/ayakkabi-800.webp</image:loc>
  </image:image>
</url>

Video

VideoObject işaretlemesinde güncel tür gerekliliklerini, video ve küçük resim erişimini kontrol edin. Google’ın video özellikleri için sayfanın rolü ve videonun belirginliği de önemlidir; yalnız schema eklemek yeterli değildir.

Videoları iframe ile gömüyorsanız, CLS bölümündeki aspect-ratio tekniğini uygulamayı unutmayın — gömülü oynatıcılar layout kaymasının en yaygın sebeplerindendir.

Mobile-Friendliness (Mobil Uyumluluk)

Mobil sayfada ana içerik, bağlantılar, görseller ve önemli meta bilgileri erişilebilir olmalıdır. Masaüstünde görünen bir bölümün mobilde tamamen kaldırılması ile HTML’de bulunan bir akordion içinde sunulması aynı şey değildir.

• Telefon genişliğinde başlık, tablo, kod ve form taşmalarını kontrol edin.
• Metni rahat okunur, dokunma alanlarını birbirinden yeterince ayrı tutun; yakınlaştırmayı engellemeyin.
• Menüyü, çerez tercihini, form hatalarını ve gönderim düğmesini gerçek cihazda deneyin.
• Açılır içeriklerin klavye ve ekran okuyucuyla kullanılabildiğini kontrol edin.

Lighthouse ve PageSpeed Insights yardımcıdır; Core Web Vitals raporu tek başına mobil kullanılabilirlik testi değildir. Google’ın eski Mobile-Friendly Test ve Mobile Usability raporu yerine cihaz testi, DevTools ve erişilebilirlik kontrollerini birlikte kullanın.

<meta name="viewport" content="width=device-width, initial-scale=1">

HTTPS Kullanımı

HTTPS, tarayıcı ile sunucu arasındaki iletişimi şifreler. Sertifikanın alan adını kapsadığını ve geçerli olduğunu tarayıcının güvenlik panelinden kontrol edin; yalnız adres çubuğundaki simgeye bakmayın. Site güvenliği de teknik SEO’nun parçasıdır; bir güvenlik açığının sitemizi nasıl bahis aramalarında sıralattığını spam backlink vaka incelememizde anlattım.

HTTP URL’lerini doğru HTTPS karşılığına yönlendirin. Formlar, görseller, scriptler ve canonical adresleri de HTTPS kullanmalı. Sertifikanın geçerli olması sitenin bütün güvenlik risklerinin çözüldüğü anlamına gelmez.

HSTS ve Mixed Content

Mixed content: HTTPS sayfada HTTP kaynak çağrıları tarayıcı tarafından yükseltilebilir veya engellenebilir. Console ve Network panellerinde uyarıları inceleyip kaynak adreslerini düzeltin.

HSTS: Tarayıcıya belirlenen süre boyunca HTTPS kullanmasını söyler. includeSubDomains tüm alt alan adlarını kapsar; bu ayarı ancak onların da HTTPS uyumunu doğruladıktan sonra kullanın. Uzun süre veya preload kararı vermeden önce kısa süreli test yapın.

Sertifika yenilemesini sağlayıcınız üzerinden izleyin. Süre dolması veya TLS hatası ziyaretçi ve bot erişimini bozabilir; belirli bir günde indeks kaybı olacağı şeklinde sabit süre vermeyin.

Pop-up Kullanımı

Sayfa açılır açılmaz ana içeriği kapatan ve zor kapatılan pencereler ziyaretçinin işini zorlaştırır. Özellikle mobilde ilk ekranı kampanya mesajıyla tamamen kapatmayın. Yasal bildirimlerle pazarlama pencerelerini aynı akışa zorlamayın.

• Kapatma düğmesi görünür ve klavyeyle kullanılabilir olsun.
• Odak yönetimi ve ekran okuyucu etiketleri doğru olsun; kapanınca odak uygun yere dönsün.
• Aynı ziyaretçiye aynı teklifi her sayfada tekrar göstermeyin.
• Çerez tercihlerini ve formları farklı ekran genişliklerinde test edin.

Küçük bir bant veya içerik içi teklif çoğu zaman daha sade bir seçenektir. Kararı yalnız açılma/tıklanma oranıyla vermeyin; ziyaretçinin asıl işini tamamlayıp tamamlayamadığını da ölçün.

Performans ve UX İyileştirme Yol Haritası

Hangi hız sorununu önce çözeceğinize karar vermek için optimizasyon öncelikleri bölümüne bakın.

1. En çok kullanılan sayfa şablonlarını ve kritik kullanıcı akışlarını seçin.
2. Alan verisi ve laboratuvar kaydında görülen darboğazı belirleyin.
3. Etkisi yüksek, ölçülebilir bir değişikliği uygulayın: örneğin LCP görselini küçültmek veya filtre etkileşimindeki uzun işi bölmek.
4. Aynı koşullarda yeniden ölçün; form, menü ve ölçüm etiketlerinin çalıştığını da kontrol edin.

Her siteye otomatik CDN, PWA veya bütün dosyaları birleştirme listesi uygulamayın. Çözüm, ölçümde gördüğünüz soruna karşılık gelmeli.

Performans İzleme ve Sürekli İyileştirme

Tema, eklenti, kampanya scripti veya büyük içerik değişikliğinden sonra temsili sayfalarda kontrol yapın. Gerçek kullanıcı ölçümünde cihaz, URL türü ve değişiklik tarihini birlikte kaydedin.

GA4’ün varsayılan kurulumu ayrıntılı Core Web Vitals ölçümü değildir. RUM kullanacaksanız ilgili ölçümün kurulduğunu ve doğru veri gönderdiğini doğrulayın. Laboratuvar iyileşmesi ile gerçek kullanıcı raporundaki değişimi ayrı izleyin.

Site mimarisi ve iç bağlantılar

Site mimarisi, web sitenizin sayfalarının nasıl organize edildiği ve birbirine bağlandığıdır. İyi bir site mimarisi, hem kullanıcıların hem de arama motorlarının sitenizde kolayca gezinmesini sağlar. Kötü bir mimari ise değerli içeriğinizin kaybolmasına ve düşük sıralamalara yol açar.

Site Mimarisi Nedir ve Neden Bu Kadar Önemlidir?

Site mimarisi, bir web sitesindeki tüm sayfaların nasıl organize edildiğini, birbirine nasıl bağlandığını ve hem kullanıcılar hem de arama motorları tarafından nasıl keşfedildiğini belirleyen yapısal sistemdir.

Basitçe:

Site mimarisi = Sayfalar + Hiyerarşi + İç bağlantılar + Navigasyon mantığı

İçeriğiniz ne kadar kaliteli olursa olsun, yanlış kurgulanmış bir site mimarisi, bu içeriğin:

• Geç keşfedilmesine,
• Geç indekslenmesine,
• Yanlış değerlendirilmesine,
• Veya hiç sıralama alamamasına neden olabilir.

Bu yüzden site mimarisi, SEO’nun “görünmeyen ama belirleyici” katmanıdır.

İdeal Site Yapısı: Hiyerarşik ve Mantıksal

İyi bir site yapısı, bir ağaç gibi hiyerarşik olmalıdır: Ana sayfadan kategorilere, kategorilerden alt kategorilere ve oradan da içerik sayfalarına doğru bir akış olmalıdır.

İdeal Site Yapısı Görseli:

                    Ana Sayfa
                        |
        _______________________________________________
        |               |               |             |
   Kategori 1      Kategori 2      Kategori 3    Kategori 4
        |               |               |             |
    _________       _________       _________     _________
    |       |       |       |       |       |     |       |
Alt Kat. Alt Kat. Alt Kat. Alt Kat. Alt Kat. Alt Kat. Alt Kat. Alt Kat.
    |       |       |       |       |       |     |       |
 Sayfalar Sayfalar Sayfalar Sayfalar Sayfalar Sayfalar Sayfalar Sayfalar

E-Ticaret Örneği:

Ana Sayfa (example.com)
    |
    ├── Elektronik (/elektronik)
    |       ├── Telefonlar (/elektronik/telefonlar)
    |       |     ├── iPhone 15 Pro (/elektronik/telefonlar/iphone-15-pro)
    |       |     ├── Samsung S24 (/elektronik/telefonlar/samsung-s24)
    |       |     └── ...
    |       ├── Bilgisayarlar (/elektronik/bilgisayarlar)
    |       └── Tabletler (/elektronik/tabletler)
    |
    ├── Giyim (/giyim)
    |       ├── Erkek (/giyim/erkek)
    |       ├── Kadın (/giyim/kadin)
    |       └── Çocuk (/giyim/cocuk)
    |
    └── Ev & Yaşam (/ev-yasam)
            ├── Mobilya (/ev-yasam/mobilya)
            └── Dekorasyon (/ev-yasam/dekorasyon)

İyi Site Mimarisinin Özellikleri:

✅ Sığ Derinlik: Önemli sayfalara az adımda ve anlaşılır bağlantılarla erişim
✅ Mantıksal Gruplama: İlgili içerikler bir arada
✅ Ölçeklenebilir: Yeni içerik eklenebilir
✅ URL Yapısı ile Uyumlu: URL’ler hiyerarşiyi yansıtır
✅ Breadcrumb Uyumlu: Kullanıcı nerede olduğunu bilir

Kötü Site Mimarisinin Sorunları:

❌ Çok Derin: İçeriğe ulaşmak için 5+ tıklama
❌ Düz Yapı: Her şey ana sayfaya bağlı (binlerce link)
❌ Kötü Kategorilendirme: İlgisiz içerikler bir arada
❌ Orphan Sayfalar: Hiçbir internal link almayan sayfalar
❌ Karmaşık: Kullanıcı ve bot kaybolur

Tıklama Derinliği (Click Depth)

Tıklama derinliği, bir başlangıç sayfasından bağlantıları izleyerek hedefe kaç adımda ulaşıldığıdır. Önemli içeriğe gereksiz dolaşmadan ulaşılabilmesi iyi bir tasarım hedefidir; Google’ın tüm siteler için koyduğu “en fazla üç tıklama” kuralı değildir.

Ürün ve rehberleri ilgili kategori, hizmet ve içeriklerden bağlayın. Yalnız derinliği azaltmak için menüye yüzlerce bağlantı doldurmayın. Sitemap keşfi destekleyebilir; kullanıcıya sunulan gezinmenin yerini almaz.

Internal Linking (İç Bağlantı) Stratejisi

İç bağlantılar ziyaretçiyi ilgili içeriğe götürür ve arama motorlarının sayfaları keşfetmesine yardımcı olur. Menü bağlantıları, içerik içi bağlantılar, breadcrumb ve ilgili yazılar birbirini tamamlar.

• Link metni hedefi anlatsın: “buraya tıklayın” yerine “teknik SEO kontrol listesi” gibi.
• Bağlantıları normal <a href> öğeleriyle oluşturun; yalnız tıklama olayına bağlı düğmeye güvenmeyin.
• Hedef doğrudan doğru canonical URL olsun; kaldırılmış bloga veya yönlendirme zincirine gitmesin.
• Sırf sayı doldurmak için link eklemeyin. Her yazı için evrensel bir “ideal link sayısı” yoktur.

Bu sitedeki örnekte SEO hizmet sayfası çalışma kapsamını, bu rehber teknik denetimi, anahtar kelime analizi yazısı ise araştırma sürecini, anahtar kelime rehberi ise kelimelerin nasıl bulunacağını anlatır. Konu ilişkisi olan sayfalar birbirine okuyucunun ihtiyacı doğrultusunda bağlanabilir; farklı hizmetlerin tek URL’ye taşınması gerekmez.

Yetim sayfa kontrolü: Sitenin iç linklerini izleyen taramanın bulduğu URL’leri CMS/sitemap envanteriyle karşılaştırın. Envanterde bulunup taramada bulunmayan URL’ler inceleme adayıdır. Tarama ayarları, robots engeli veya JavaScript nedeniyle kaçırılan sayfaları ayırın. GA4’te görüntülenme olmaması tek başına yetim sayfa kanıtı değildir.

Değerli sayfaya ilgili kategori veya rehberden bağlantı ekleyin. İçeriği gereksiz bulduğunuzda ise önce trafik, bağlantı ve kullanıcı ihtiyacını inceleyin; otomatik silme veya ilgisiz yönlendirme yapmayın.

Breadcrumbs (Kırıntı İzi)

Breadcrumb, kullanıcının site içindeki konumunu ve üst kategorilere dönüş yolunu gösterir. Örneğin: Ana sayfa → Rehber → Teknik SEO. Tarayıcı geçmişinin birebir kopyası olmak zorunda değildir.

Bağlantıları erişilebilir HTML ile kurun; mevcut sayfayı anlaşılır biçimde belirtin. Görünür yapı ile BreadcrumbList işaretlemesi tutarlı olsun. Arama sonuçlarında görünümü ve tıklama artışını garanti etmeyin. Küçük veya düz yapılı bir sitede ek navigasyonun kullanıcıya katkısını değerlendirin.

Site Mimarisi Optimizasyonu: Pratik Adımlar

1. Envanter çıkarın: Hizmet, kategori, ürün ve rehber URL’lerini gruplayın. Ana sayfadan taranan URL’lerle sitemap/CMS listesini karşılaştırın.
2. Önemli sayfaları belirleyin: Trafik kadar satış, talep ve kullanıcı yolculuğundaki rolü değerlendirin.
3. Bağlantıları düzenleyin: Anlamlı kategori yapısı, açıklayıcı menüler ve bağlamsal linkler kullanın.
4. Tekrar tarayın: Yetim sayfaları, kırık linkleri, yönlendirmeleri ve erişim derinliğini önceki raporla karşılaştırın.

URL’yi yalnız daha kısa görünsün diye değiştirmeyin. Gerekiyorsa önce eski–yeni eşlemesini ve bağlantı güncellemesini hazırlayın. Yapının okunabilir olması, klasör sayısının belirli bir rakama uymasından daha önemlidir.

Faceted Navigation (Filtrelenmiş Navigasyon)

Renk, marka ve beden filtreleri çok sayıda URL oluşturabilir. Önce hangi kombinasyonların ayrı bir arama ihtiyacını karşıladığını belirleyin. Her filtreyi ana kategoriye canonical vermek veya tüm parametreleri engellemek uygun bir genel kural değildir.

İndekslenmiş bir URL’yi robots.txt ile kapatmak onu otomatik kaldırmaz. Filtre politikasını kategori, ürün ve sayfalama bağlantılarına zarar vermeden test edin. Öncelikleri belirlerken e-ticaret performans göstergelerini de kullanın.

Pagination (Sayfalama)

Sayfalama; ürünlerin ve yazıların sonraki liste sayfalarından keşfedilmesini sağlar. “Daha fazla yükle” veya sonsuz kaydırma kullanıyorsanız aynı içerik kümelerine ayrı URL’ler ve takip edilebilir bağlantılarla da ulaşılabilsin.

• Sayfalar arasında gerçek <a href> bağlantıları verin; yalnız kullanıcı etkileşimiyle içerik yüklemeye güvenmeyin.
• İkinci ve sonraki sayfaları otomatik olarak ilk sayfaya canonical göstermeyin; farklı içerik kümesi sunuyorlarsa kendi adreslerini kullansınlar.
• Sayfalama URL’lerini erişilebilir tutun. Ürünlerin sitemap’te bulunması da keşfi destekleyebilir.
• Başlıkta “Sayfa 2” gibi bir ayrım kullanıcıya yardımcı olabilir; sayfalamada aynı başlık kullanımı tek başına ihlal değildir.

Google’ın e-ticaret sayfalama belgesine göre rel="next" ve rel="prev" etiketleri artık sayfalama sinyali olarak kullanılmıyor; diğer arama motorları bu etiketleri kullanmaya devam edebilir. Sitemap’e dahil etme kararını URL’nin rolüne göre verin; bütün ikinci sayfalar için otomatik yasak koymayın.

URL Yapısı Nasıl Olmalı?

URL, sayfanın ne olduğunu kullanıcıya ve arama motoruna anlatan kalıcı adrestir. İyi bir URL kısa olmaktan çok okunabilir ve tutarlıdır.

• Kelimeleri tire (-) ile ayırın; alt çizgi, boşluk ve anlamsız kimlik dizilerinden kaçının. Örnek: /rehber/teknik-seo.
• Küçük harf kullanın. URL’ler büyük/küçük harfe duyarlıdır; /Urun ve /urun iki ayrı adres sayılabilir.
• Türkçe karakter kullanılabilir, ancak paylaşıldığında yüzde kodlu (%C3%BC gibi) görünür. Hangi yolu seçerseniz bütün sitede aynı kuralı uygulayın.
• Oturum kimliği, takip ve sıralama parametreleri gibi aynı içeriği çoğaltan parametreleri sınırlayın; gerekenleri canonical ve tarama politikasıyla yönetin.
• İçerik her yıl güncellenecekse URL’ye yıl yazmayın; başlıktaki yılı değiştirmek URL değiştirmeyi gerektirmemeli.

Yayındaki bir URL’yi değiştirmek teknik bir taşımadır: eski–yeni eşleme, 301 yönlendirme ve iç bağlantı güncellemesi olmadan yapmayın. Süreç için site taşıma ve SEO rehberine bakın.

Çok Dilli ve Çok Bölgeli Siteler: Hreflang

hreflang, aynı içeriğin farklı dil veya bölge sürümleri arasındaki ilişkiyi belirtir. Sayfa içeriği, dil seçimi ve canonical ayarlarıyla birlikte değerlendirilir.

<link rel="alternate" hreflang="tr" href="https://example.com/urun">
<link rel="alternate" hreflang="en" href="https://example.com/en/product">

Her dil sürümünde kendisini ve diğer karşılıklarını listeleyin; bağlantılar karşılıklı ve mutlak URL olmalıdır. Dil/bölge kodlarını doğru kullanın. x-default gerektiğinde dil seçimi veya varsayılan karşılık için kullanılabilir.

Örnek sayfaları tarayıp karşılıklı işaretlemeyi, HTTP yanıtlarını ve canonical uyumunu kontrol edin. Birbirinin çevirisi olmayan sayfaları eşleştirmeyin. Search Console’un Uluslararası Hedefleme raporu kaldırıldığı için doğrulamayı o rapora bağlamayın.

Site Mimarisi Kontrol Listesi

• Önemli sayfalar ilgili kategori veya rehberlerden erişilebilir mi?
• İç linkler doğru ve çalışan URL’lere gidiyor mu?
• Tarama envanteri ile CMS/sitemap listesi karşılaştırıldı mı?
• Mobil menü ve sayfalama kullanılabiliyor mu?
• Filtre URL’lerinin hangilerinin aramada yer alacağı açık mı?
• Dil sürümleri ve breadcrumb ilişkileri tutarlı mı?

Yeni içerik veya kategori ekledikçe bu kontrolleri tekrar edin. Bulduğunuz sorunu örnek URL ve beklenen davranışla kaydedin.

XML sitemap ve indeks yönetimi

Sitemap, indekslenmesini istediğiniz tercih edilen URL’leri arama motorlarına bildirir. İç bağlantıları tamamlar; Google’a bir sayfayı indeksleme veya başka bir sayfayı kaldırma emri vermez.

XML Sitemap Nedir?

XML sitemap; URL’ler ve gerektiğinde son önemli değişiklik tarihi gibi bilgiler içeren dosyadır. Search Console’un Sitemaps raporundan gönderilebilir. Dosyanın okunması, içindeki her URL’nin indekslenmesi anlamına gelmez.

XML Sitemap SEO’ya Nasıl Katkı Sağlar?

Crawling Verimliliği

Sitemap yeni, güncellenmiş veya bağlantısı az URL’lerin keşfine yardımcı olur. Ancak botun yalnız bu listede dolaşmasını sağlamaz. Gereksiz URL üretimini ve iç bağlantı sorunlarını ayrıca çözün.

Indexing Kontrolü

Sitemap’teki örnek URL’lerin HTTP durumunu, canonical’ını ve indeksleme iznini kontrol edin. Listeye eklenmiş olması sayfanın canlı veya sorunsuz olduğunu kanıtlamaz. Search Console’daki indeksleme nedenleriyle karşılaştırın.

Index Bloat’ın Önlenmesi

Aramada bulunmasını istemediğiniz URL’leri yalnız sitemap’ten çıkarmak yeterli değildir. Soruna göre içerik birleştirme, canonical, noindex veya kaldırma kararı gerekir. Bir parametreli sayfa yararlı olabilir; kararını URL biçimine değil içerik ve arama ihtiyacına göre verin.

XML Sitemap Best Practices (Altın Kurallar)

• İndekslenmesini istediğiniz tercih edilen URL’leri kullanın.
• Yönlendirme, hata ve noindex durumundaki URL’leri temizleyin. Shopify gibi sitemap’i otomatik üreten platformlarda bu temizlik yayın durumu ve gizleme ayarıyla yapılır (bkz. Shopify sitemap).
• Yeni ve henüz trafik almayan değerli sayfaları da ekleyin.
• Canonical ve site içi bağlantılarla aynı adresleri kullanın.
• Filtre veya sayfalama URL’lerini rolüne göre değerlendirin; toplu varsayım yapmayın.

IndexNow ve lastmod disiplini

IndexNow, URL değişimini Bing ve bazı motorlara anında bildirir. Google’ın ana kanalı hâlâ XML sitemap + Search Console’dur. İkisini karıştırmayın.

• Sitemap’teki lastmod değerini her generate’de “bugün” yapmayın. İçerik gerçekten değişince güncelleyin.
• Sitemap’e yalnızca 200 + indexable + canonical URL koyun (bu kural yukarıdaki altın kurallarla aynıdır).

Yapılandırılmış veri (Schema)

Schema (yapılandırılmış veri), sayfadaki varlıkları — makale, yazar, ürün, SSS — arama motorlarının ve ajanların makinece okuyacağı formata çevirir. Sıralama sihri değildir. Doğru kullanıldığında rich result üretebilir, yanlış kullanıldığında yok sayılır veya manuel işlem riski doğurur.

Schema nedir, ne değildir?

Schema; makale, ürün, kurum gibi varlıkları ve ilişkilerini tanımlar. Görünmeyen puanlar, sahte stok veya sayfada olmayan bilgiler eklemeyin. JSON-LD yaygın bir uygulama biçimidir.

Kaynak HTML’de üretmek yönetimi kolaylaştırabilir; JavaScript ile üretilen işaretlemeyi de Google işleyebilir. Önemli olan doğru render, erişim ve görünür içerikle tutarlılıktır. Aynı bilginin tema ve eklentiler tarafından çelişkili biçimde üretilmediğini kontrol edin.

Schema’nın Yapay Zeka Tarafı

Yapılandırılmış veri, sayfada gerçekten bulunan bilgiyi makine tarafından okunabilir biçimde tanımlar. Yazar, kurum, ürün ve tarih bilgileri görünür içerikle tutarlı olmalıdır. JSON-LD kullanmak bilgilerin doğruluğunu veya bir yapay zekâ cevabında kaynak gösterilmeyi garanti etmez.

Google AI Overviews ve AI Mode için özel bir schema türü veya ek teknik işaretleme gerekmiyor (GEO rehberimizde ayrıntılar var). Google’ın temel indeksleme ve arama uygunluğu koşulları geçerlidir. Diğer sağlayıcılar için de “schema ekledim, artık alıntılanırım” varsayımıyla hareket etmeyin.

Hangi sayfada hangi tür?

Schema.org’da bir türün bulunması Google’ın o tür için zengin sonuç sunduğu anlamına gelmez. FAQ ve HowTo dahil türleri kullanmadan önce güncel Google desteğini kontrol edin; bu rehbere sırf soru-cevap içeriyor diye görünürlük vaadiyle işaretleme eklemeyin. Güncel durum: Google, SSS (FAQ) zengin sonucunu 7 Mayıs 2026’dan itibaren arama sonuçlarında göstermiyor ve Haziran 2026’da bu özelliğin belgesini kaldırdı. Sayfadaki soru-cevap metni okuyucu için yararlı olmaya devam eder; FAQPage işaretlemesinin Google aramada ayrı bir görünüm sağlamasını beklemeyin.

JSON-LD örneği (Article)

Şablon motorunda dinamik alanlarla doldurun. Aşağıdaki blok bir örnektir — olduğu gibi yazınızın içine yapıştırmayın.

Önce şunu kontrol edin: Shopify, WordPress ve çoğu modern tema zaten Article / BlogPosting schema’sı üretir. Üzerine bir tane daha eklerseniz aynı sayfada iki ana varlık olur — bu bölümün az aşağıda “sık hatalar” başlığında uyardığı durumun ta kendisi. Kaynak kodda ld+json arayın; varsa mevcut bloğu düzenleyin, yenisini eklemeyin. Shopify’da tema ile uygulamanın çift Product işaretlemesi üretmesi de aynı sorundur: Temaya güvenip kontrolü bırakmayın.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Teknik SEO Nedir? Uygulamalı Denetim ve Kontrol Listesi",
  "datePublished": "2025-12-25",
  "dateModified": "2026-09-24",
  "author": {
    "@type": "Person",
    "name": "Metehan Yılmaz",
    "url": "https://metehanyilmaz.com.tr/pages/hakkimizda"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Metehan Yılmaz",
    "url": "https://metehanyilmaz.com.tr"
  },
  "image": "https://cdn.shopify.com/s/files/1/0908/8273/6162/articles/wp-0ca16948-teknik-seo-rehberi.png?v=1789412434",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://metehanyilmaz.com.tr/blogs/rehber/teknik-seo-rehberi"
  }
}
</script>

BreadcrumbList (kısa)

Görünür breadcrumb ile aynı hiyerarşiyi verin. Mimari bölümündeki breadcrumb anlatımıyla çelişmesin.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Ana sayfa", "item": "https://metehanyilmaz.com.tr" },
    { "@type": "ListItem", "position": 2, "name": "Rehber", "item": "https://metehanyilmaz.com.tr/blogs/rehber" },
    { "@type": "ListItem", "position": 3, "name": "Teknik SEO Nedir? Uygulamalı Denetim ve Kontrol Listesi", "item": "https://metehanyilmaz.com.tr/blogs/rehber/teknik-seo-rehberi" }
  ]
}
</script>

Doğrulama ve sık hatalar

Rich Results Test ile Google’ın desteklediği türleri ve hataları kontrol edin. Desteklenmeyen schema.org türleri için genel bir schema doğrulayıcısı ayrıca kullanılabilir. Geçerli işaretleme, zengin sonuç gösterileceği garantisi değildir.

• JSON sözdizimi ve zorunlu alanları doğrulayın.
• Tema ve eklenti çıktılarındaki çelişen tarih, fiyat veya yazar bilgisini temizleyin.
• İşaretlemenin gerçek içeriği temsil ettiğini kontrol edin.
• Varsa ilgili Search Console geliştirme raporunda yayın sonrası durumu izleyin.

JavaScript SEO ve yapay zekâ tarayıcıları

JavaScript kullanılması tek başına SEO sorunu değildir. Asıl soru, önemli içerik ve bağlantıların tarayıcı tarafından hangi aşamada görülebildiğidir. Google’ın render süreciyle diğer sağlayıcıların erişim biçimlerini ayrı değerlendirin.

Google nasıl işler?

Google sayfayı tarar, uygun olduğunda JavaScript’i render eder ve elde ettiği içeriği indeksleme açısından değerlendirir. Kaynaklar engelliyse veya içerik yalnız kullanıcı etkileşimiyle geliyorsa eksik sonuç oluşabilir. Kaynak HTML ile URL Denetimi’nin render çıktısını karşılaştırın.

JavaScript SEO ne zaman risklidir?

• İçerik, ürün, kategori veya internal linkler JS ile sonradan yükleniyorsa
• Infinite scroll içerik üretip URL değişmiyorsa
• Lazy-load içerik viewport dışındaysa ve taranmıyorsa
• Menü / navigasyon yalnızca JS ile oluşuyorsa
• Canonical, meta veya schema JS ile inject ediliyorsa

Kritik kural: Google’ın ve AI botlarının görmesini istediğiniz her şey, mümkünse ilk HTML yanıtında dursun.

noindex ve Canonical Zamanlaması

• Ham HTML’de noindex varsa Google render’ı atlayabilir. JS ile noindex kaldırmak hiç çalışmayabilir.
• Canonical kaynak HTML ve render çıktısında tutarlı olmalıdır. Script ile HTML’dekinden farklı canonical yazmak çelişki üretir.
• GSC URL Inspection’da taranan HTML ile rendered çıktıyı yan yana bakın.
• Google 200 durum kodlu sayfaları render kuyruğuna alır; 404 gibi 200 dışı kod döndüren sayfalarda render atlanabilir (Google’ın Aralık 2025 belge notu). Hata kodu döndüren bir şablonun içeriğini JavaScript ile “kurtarmaya” güvenmeyin.

Güvenli yaklaşım

• SSR (server-side rendering) veya static / prerender tercih edin.
• Internal linkleri gerçek <a href="..."> ile üretin.
• Infinite scroll varsa pagination + ayrı URL kullanın.
• Lazy-load’u görseller için kullanın; kritik metni arkasına saklamayın.
• Meta, canonical ve schema ilk HTML’de olsun.
• CSS ve JS dosyalarını robots.txt ile kapatmayın — Google sayfayı doğru render edemez.

SPA’larda Core Web Vitals ve Soft Navigation

Tek sayfa uygulamalarında URL değişmesi her zaman yeni bir sayfa yüklemesi oluşturmaz. Bu nedenle tam yükleme metrikleri ile uygulama içi rota geçişlerini aynı ölçüm gibi yorumlamayın. INP etkileşimleri sayfa yaşam döngüsü boyunca değerlendirir; LCP’yi her rota için otomatik yeniden ölçülmüş varsaymayın.

Rota geçiş süresini ve kullanıcıya gösterilen yükleme durumunu ayrıca izleyin. Kullandığınız ölçüm kütüphanesinin ve tarayıcının soft navigation desteğini uygulama sırasında kontrol edin. SSR kullanmak içerik erişimini kolaylaştırabilir, fakat uygulama içi geçiş performansını tek başına çözmez.

AI crawler’lar Googlebot değildir

Google Search, model eğitimi, arama indeksi ve kullanıcının isteğiyle sayfa getirme farklı süreçlerdir. Tüm botların render yeteneğinin aynı olduğunu varsaymayın. Önemli metni ve bağlantıları ilk HTML yanıtında sunmak, JavaScript desteğine bağımlılığı azaltır.

Kontrolü iki adımda yapın: sunucunun döndürdüğü HTML’yi ve tarayıcının render ettiği içeriği karşılaştırın; ardından ilgili sağlayıcının bot belgelerini ve doğrulanmış erişim kayıtlarını inceleyin. Bir user-agent adıyla yapılan yerel istek, gerçek botun sayfayı gördüğünü kanıtlamaz.

Hangi Yapay Zeka Botu Ne Yapar?

Eğitim botunu engellemek ile arama botunu engellemek aynı karar değildir. Botun açık olması da indeksleme veya kaynak gösterilme garantisi vermez. Bing görünürlüğünü ayrıca kontrol edebilirsiniz; tek bir arama indeksine girmek tüm cevap motorlarında görünmek anlamına gelmez.

Bot adları ve görevleri sağlayıcıların kendi belgelerine dayanır; tablodaki bağlantılar bu belgelere gider. OpenAI’nin belgesine göre OAI-SearchBot’u engelleyen siteler ChatGPT arama cevaplarında gösterilmez, yalnız gezinme bağlantısı olarak görünebilir.

Yapay Zeka Cevaplarında Alıntılanmak İçin

Açık tanımlar, sorunun hemen altında verilen cevaplar, kaynaklı veriler ve kimin yazdığını gösteren bilgiler okuyucunun değerlendirmesini kolaylaştırır. Bunları alıntılanma garantisi veya tek bir paragraf optimizasyon formülü gibi sunmayın.

• Önemli iddianın kaynağını ilgili cümleye yakın verin.
• Tablo ve listelerde gerçek metin kullanın; bilgiyi yalnız görsele bırakmayın.
• Güncelleme tarihini ancak anlamlı değişiklik yaptığınızda yenileyin.
• Bot ziyaretini, cevapta kaynak gösterilmeyi ve siteye gelen trafiği ayrı ölçün.

Google’ın AI özelliklerinden gelen trafik Search Console’un Web performans verileri içinde raporlanır. Diğer yüzeylerde yönlendirme trafiği ve tarih/soru kaydı tutulan örnek kontroller yardımcı olabilir; birkaç kişisel sorgu görünürlüğün tamamını ölçmez.

robots.txt ve AI botları

Önce hangi kullanım için izin verdiğinizi belirleyin. Aşağıdaki örnek OpenAI eğitim taramasını kapatırken arama botuna izin verir; diğer sağlayıcılar için kendi belgelerini okuyun.

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Mevcut robots.txt kurallarınızı silip bu örneği tek başına koymayın. CDN/WAF engelleri ve sağlayıcının doğrulama yöntemi de erişimi etkileyebilir. Özellikle kullanıcı tarafından başlatılan isteklerde robots.txt davranışının otomatik taramadan farklı olabileceğini dikkate alın.

Content Signals: robots.txt’in yeni sözlüğü

Cloudflare Content Signals; search, ai-input ve ai-train gibi amaçlar için kullanım tercihlerini ifade eder. Bu tür beyanları tüm botların desteklediği evrensel bir standart veya teknik erişim engeli olarak değerlendirmeyin.

CDN kullanıyorsanız ziyaretçiye sunulan gerçek robots.txt dosyasını kontrol edin. Yönetim panelindeki tercih, kaynak dosya ve sunulan yanıt farklı olabilir. Gizli bilgiyi korumak için kimlik doğrulama gerekir.

llms.txt

llms.txt bazı sitelerde içerik keşfine yardımcı olma amacıyla yayımlanır. Google AI Overviews ve AI Mode için böyle bir dosya gerekmiyor. Önceliğiniz taranabilir içerik, doğru indeksleme ve anlaşılır site yapısı olmalı; dosya eklemek sıralama veya kaynak gösterilme garantisi değildir.

Google, Haziran 2026’da üretken yapay zekâ özellikleri rehberine eklediği notta Google Search’ün llms.txt dosyalarını kullanmadığını, dosyanın görünürlüğe ne zarar ne katkı sağladığını belirtti; başka hizmetler için dosyayı tutmanızda sakınca görmüyor. Aynı rehbere göre içeriği yapay zekâ için küçük parçalara bölmek (“chunking”) de gerekli değil.

Hızlı kontrol

• Kaynak HTML’de ana metin ve gerçek iç bağlantılar var mı?
• URL Denetimi’nin render sonucunda içerik tamamlanıyor mu?
• JavaScript kapalıyken temel içerik okunabiliyor mu?
• Canonical, robots etiketi ve HTTP durumu birbiriyle tutarlı mı?
• Bot erişimi sağlayıcının belgeleriyle doğrulanıyor mu?

Log analizi ve tarama bütçesi

Log analizi, Googlebot’un sitenizde gerçekte ne yaptığını gösterir. GSC özet sunar; log satır satır gerçektir.

Ne zaman gerekli?

• 50.000+ URL’li siteler
• E-ticaret ve marketplace
• Index gecikmesi, crawl budget şikâyeti
• Ani trafik veya index kaybı

Küçük sitelerde genellikle gerekli değildir. Önce GSC Crawl Stats + Sayfalar raporu yeter.

Log ile ne öğrenilir?

• Önemli sayfalar yeterince crawl ediliyor mu?
• Googlebot en çok hangi URL’leri tarıyor?
• Parametreli / filtreli URL’ler bütçeyi yiyor mu?
• 404 / 5xx’e bot geliyor mu?

Log’dan aksiyon

Önce bot kimliğini yalnız user-agent metnine bakarak kabul etmeyin; sağlayıcının IP veya DNS doğrulama yöntemini kullanın. Ardından hataları URL türüne göre gruplayın: ürün, kategori, filtre, kaldırılmış içerik.

Önemli sayfalarda 5xx yoğunluğu varsa sunucu sorununu; gereksiz kombinasyonlar baskınsa URL üretimini ve tarama politikasını ele alın. noindex, canonical ve robots.txt’yi aynı sorunun birbirinin yerine geçen çözümleri gibi kullanmayın. Değişiklikten sonra aynı zaman aralığı ve URL gruplarıyla karşılaştırma yapın.

Teknik SEO denetim ve kontrol listesi

Önceliği etkilenen URL’lerin iş değeri, sorunun kapsamı ve çözüm riskiyle belirleyin. Aşağıdaki sıra başlangıç noktasıdır; her projede aynı değildir.

Her kayıt için örnek URL, beklenen davranış, mevcut bulgu, sorumlu kişi ve tamamlanma ölçütü yazın. Araçtaki tüm uyarıları aynı aciliyette görev olarak açmayın.

Teknik SEO Denetimi Adım Adım Nasıl Yapılır?

1. Kapsamı belirleyin: Hangi alan adı, alt alan adları ve dil sürümleri denetlenecek? Ana sayfa, kategori, ürün veya hizmet, blog ve form sayfalarından birer temsili URL seçin.
2. Search Console’dan başlayın: Sayfa dizine ekleme raporundaki nedenleri, Tarama İstatistikleri’ndeki yanıt kodlarını ve Core Web Vitals raporundaki URL gruplarını not edin.
3. Siteyi tarayın: Bir tarama aracıyla durum kodlarını, yönlendirme zincirlerini, canonical ve noindex etiketlerini, yinelenen title’ları ve kırık iç bağlantıları çıkarın. İçerik JavaScript ile oluşuyorsa render açık tarama da yapın.
4. Envanterle karşılaştırın: Taramada bulunan URL’leri sitemap ve CMS listesiyle karşılaştırın; yetim ve gereksiz URL’leri ayırın.
5. Örnek URL’leri elle doğrulayın: URL Denetimi’nde Google’ın seçtiği canonical’ı ve render çıktısını, tarayıcıda HTTP yanıtını kontrol edin.
6. Performansı ölçün: PageSpeed Insights’ta alan verisini, DevTools’ta yavaş etkileşimleri inceleyin.
7. Önceliklendirin: Yukarıdaki sırayı ve etkilenen URL’lerin iş değerini kullanın. Her bulgu için örnek URL, beklenen davranış ve doğrulama ölçütü yazın.
8. Düzeltmeden sonra yeniden test edin: Aynı URL’leri aynı araçla tekrar kontrol edin. Search Console’da düzeltme doğrulamasını yalnız sorun gerçekten giderildikten sonra başlatın.

Küçük bir sitede bu denetim birkaç saatte yapılabilir; binlerce URL’li bir e-ticaret sitesinde log analizi ve şablon bazlı inceleme eklenir. Denetimi yalnız takvime bağlamayın: tema değişikliği, platform taşıması ve büyük içerik eklemelerinden sonra da tekrarlayın.

Teknik SEO Araçları

Tek Sayfalık Teknik SEO Kontrol Listesi

Bu liste, rehberdeki bölüm sonu kontrollerini tek yerde toplar. Her maddeyi önemli şablonlarınızdan birer örnek URL ile kontrol edin.

Sık Görülen Teknik SEO Hataları

Kendi sitemizden örnek: blogdan hizmet sayfasına geçiş

Bu sitede dört ana konunun blog içeriğini kendi hizmet sayfalarına taşıdık. Örneğin /blogs/rehber/seo-nedir adresi /pages/seo adresine yönleniyor. Google reklam, Instagram reklam ve dijital pazarlama da kendi ayrı hizmet URL’lerine taşındı.

1. Eski yazının konularını ilgili hizmet sayfasındaki rehberle eşleştirdik.
2. Eski URL’leri doğrudan doğru hedefe 301 yönlendirdik.
3. İç bağlantıları ve menüleri yeni adreslerle güncelledik.
4. Hedeflerin 200 yanıtını, canonical’ını, sitemap kaydını ve eski bölüm bağlantılarını kontrol ettik.

Bu teknik geçişin doğrulanmış örneğidir; henüz ölçülmüş bir trafik veya sıralama artışı iddiası değildir. Teknik SEO gibi bağımsız alt konu rehberleri kendi adreslerinde kaldı.

Alan adı değişikliğinde bir adım daha vardır. Google, Haziran 2026’da site taşıma rehberini güncelleyerek Adres Değişikliği aracının eski alan adının doğrulanmış bütün varyantları (www, www’suz ve alt alan adları) için gönderilmesini önerdi; kullanmadığınız varyantlar da buna dahildir. Yönlendirmeleri mümkün olduğunca uzun, genellikle en az bir yıl koruyun.

WordPress, Shopify ve özel yazılımda uygulama

Sık sorulan sorular

Teknik SEO ne kadar sürede sonuç verir?

Düzeltme yayına girdiği anda geçerlidir, ama Google’ın etkilenen URL’leri yeniden taraması ve işlemesi günler ile haftalar sürebilir. robots.txt engelini kaldırmak gibi erişim düzeltmeleri genellikle en hızlı etkiyi gösterir; canonical değişiklikleri ve site taşımaları daha uzun sürer. Core Web Vitals raporu 28 günlük gerçek kullanıcı verisine dayandığı için iyileşme raporda kademeli görünür.

Teknik SEO bir kez yapılıp biter mi?

Hayır. Tema güncellemesi, yeni uygulama veya eklenti, kampanya scripti, URL değişikliği ve platform taşıması yeni sorunlar üretebilir. Search Console’u ayda bir kontrol edin; kapsamlı denetimi yılda bir ve her büyük değişiklikten sonra tekrarlayın.

Kod bilmeden teknik SEO yapılabilir mi?

Denetimin büyük kısmı yapılabilir: Search Console raporlarını, PageSpeed Insights sonuçlarını, tarama aracı çıktısını ve robots.txt dosyasını okumak kod gerektirmez. Shopify ve WordPress gibi platformlarda yönlendirme ve sitemap ayarları paneldedir. Render, sunucu ve şablon kaynaklı düzeltmeler için geliştirici gerekir.

Küçük bir site için teknik SEO gerekli mi?

Gerekli, ama kapsamı daha dardır. Google’ın tarama bütçesi belgesi bu konuyu 1 milyondan fazla sayfası olan ya da 10.000’den fazla sayfası günlük değişen siteler için ele alır; küçük sitede log analizi genellikle gerekmez. Önce indeksleme, HTTPS, mobil kullanım ve hız kontrol edilir.

Site hızı sıralamayı etkiler mi?

Google’ın sıralama sistemleri Core Web Vitals’tan yararlanır, ama içeriğin aramayla ilgisi çok daha belirleyicidir. Hız, benzer kalitedeki sayfalar arasında fark yaratabilir; tek başına üst sıra getirmez. Daha doğrudan etkisi kullanıcı deneyimi ve dönüşüm üzerindedir.

SEO için 301 mi, 302 mi kullanılmalı?

Taşıma kalıcıysa 301 veya 308, gerçekten geçiciyse 302 veya 307 kullanın. Google iki türü de takip eder; fark, hangi URL’nin tercih edilen adres sayılacağına dair verdiği sinyaldedir. Uzun süre yerinde kalan bir 302 zamanla kalıcı gibi değerlendirilebilir, ama bunu plan olarak kullanmayın.

TTFB nedir, iyi değer kaçtır?

TTFB (Time to First Byte), tarayıcının isteği gönderdikten sonra sunucudan ilk baytı alana kadar geçen süredir. web.dev kaba bir rehber olarak 0,8 saniye ve altını iyi, 1,8 saniyenin üstünü zayıf kabul eder. Core Web Vitals metriği değildir ama LCP’yi doğrudan etkiler. İyileştirme adımları LCP bölümünde.

FAQ schema hâlâ işe yarar mı?

Google, SSS zengin sonucunu 7 Mayıs 2026’dan itibaren arama sonuçlarında göstermiyor. Soru-cevap içeriği okuyucu için yararlı olmaya devam eder; ancak FAQPage işaretlemesinin Google aramada ayrı bir görünüm sağlamasını beklemeyin. Ayrıntı için schema türleri bölümüne bakın.

Özet

İlk hedefiniz önemli sayfaların erişilebilir ve indekslenebilir olmasıdır. Ardından doğru URL seçimi, iç bağlantılar, mobil deneyim ve performansa geçin. Her değişiklik için önceki durumu, uygulanan işlemi ve doğrulama sonucunu kaydedin.

Denetim bulgularını uygulama sırasına koymak için SEO çalışma sürecimizi inceleyebilirsiniz. Denetimi ve düzeltmeleri birlikte planlamak isterseniz teknik SEO hizmeti kapsamımıza bakın.

Bu yazıdaki bilgiler en son 22 Ekim 2026’da gözden geçirildi.