Kapsamlı Teknik SEO Rehberi

Teknik SEO, web sitenizin arama motorları tarafından bulunabilmesi, taranabilmesi (crawl), anlaşılabilmesi ve indekslenebilmesi için yapılan teknik optimizasyonlardır. İçeriğiniz ne kadar kaliteli olursa olsun, teknik temeller sağlam değilse arama motorlarında görünmezsiniz.

Technical SEO, SEO başarınızın temel direğidir. Çünkü bu faaliyetlerin çoğunun, diğer SEO taktiklerinizin sonuç vermeden önce gerçekleşmesi gerekir.

2026’da teknik SEO artık yalnız Googlebot’u mutlu etmek değil. Yapay zeka tarayıcıları da sayfanızı okuyor — ve onlar Google gibi davranmıyor. Sayfanın ham HTML’i; Google’ın ikinci dalga render’ı, AI Overviews ve ChatGPT / Perplexity / Claude tarayıcıları tarafından da okunuyor. Bu rehber crawl ve hızın yanına kanonikleştirme, schema ve AI crawler görünürlüğünü de ekler.

Rehber sekiz bölümden oluşuyor: tarama ve indeksleme, performans, site mimarisi, sitemap, yapılandırılmış veri, JavaScript ve AI crawler’lar, log analizi ve kapanışta uçtan uca bir denetim listesi. Sıradan okuyabilir ya da doğrudan sorununuzun olduğu bölüme geçebilirsiniz.

1. Crawling ve Indexing (Temel)

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ü

Sitenizin indekslendiğinden emin olmanız gerekir çünkü indekslenmemiş bir site arama sonuçlarında görünmez.

Hızlı Kontrol Yöntemi:

Google’da şu aramayı yapın:

site:yourdomain.com

Bu, Google’ın sitenizden kaç sayfayı indekslediğini gösterir.

Detaylı Kontrol: Google Search Console

Google Search Console (GSC), indexing durumunuzu kontrol etmek için en iyi araçtır.

Adımlar:

1. GSC’de “Sayfalar” raporuna gidin
2. İndekslenen ve indekslenmeyen sayfaları görün
3. İndekslenmeme nedenlerini inceleyin

Yaygın İndekslenmeme Nedenleri:

Düzeltme Süreci:

1. Sorunu tespit edin ve düzeltin
2. GSC’de “Validate Fix” düğmesine tıklayın
3. Google’ın sayfayı yeniden taramasını isteyin
4. Doğrulama sürecini takip edin (birkaç gün sürebilir)

Robots.txt Optimizasyonu

Robots.txt dosyası, arama motorlarına ve AI botlarına sitenizin hangi bölümlerine erişebileceklerini söyleyen bir talimat dosyasıdır.

Geleneksel olarak, robots.txt dosyası, “arama motorlarının admin paneli gibi hassas dizinlere girmesini engellemek” için kullanılırdı. Ancak günümüzde asıl görevi, Tarama Bütçesi (Crawl Budget) Yönetimidir.

Robots.txt’nin “Rehber” Rolü

Bu noktada robots.txt devreye girer. Amacımız, Googlebot’un kısıtlı zamanını en iyi şekilde kullanmasını sağlamaktır.

Örnek Senaryo: E-Ticaret Sitesi

Bir e-ticaret siteniz var. Google’ın taramasını istediğiniz en önemli sayfalar: Ürün Sayfaları ve Kategori Sayfaları.

Google’ın taramasını istemediğiniz sayfalar (çünkü bunlar ya yinelenen içeriktir ya da değerleri düşüktür): Sepet, Ödeme, Üye Girişi, Filtreler (?fiyat=, ?renk=, ?sirala=).

Doğru Strateji:

User-agent: *
Disallow: /sepet/
Disallow: /odeme/
Disallow: /uye-girisi/

# Filtre ve sıralama parametreleri — her biri AYRI satırda olmalı.
# Aynı satıra iki kural yazarsanız ikincisi yok sayılır.
Disallow: /*?fiyat=
Disallow: /*?sirala=
Disallow: /*?renk=

# Bu engellemeler Google'a şunu der:
# "Bu sayfalarla uğraşma, ürün sayfalarına bakmaya devam et."

# CSS ve JS'i ASLA engellemeyin — Google sayfayı render edemez.
Allow: /*.css$
Allow: /*.js$

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

Unutulmaması gereken en önemli teknik detay şudur:

1. Disallow komutu, Google’ın bir URL’yi tarayamayacağı anlamına gelir.
2. Ancak indeksleyemeyeceği anlamına gelmez.

Eğer harici bir kaynak (başka bir site) engellediğiniz bir URL’ye link verirse, Google URL’yi tarayamasa bile linkteki anchor text ve URL’nin kendisi nedeniyle sayfayı indeksleyebilir (Genellikle “Bu sayfa robots.txt tarafından engellenmiştir” uyarısıyla).

Nihai Kural: Gizlenmesi gereken hassas içeriğiniz varsa, robots.txt kullanmak yerine sayfaya noindex meta etiketi eklemeli veya şifre koruması kullanmalısınız. Robots.txt ise sadece tarama bütçesini yönlendirmek için kullanılmalıdır.

Duplicate Versions (HTTP / HTTPS / WWW) Sorunu

Sitenizin birden fazla versiyonunun erişilebilir olması, duplicate content sorununa ve otoritenin bölünmesine yol açar.

Olası Duplicate Versiyonlar:

1. https://example.com
2. https://www.example.com
3. http://example.com
4. http://www.example.com

Teknik olarak bunlar 4 farklı URL’dir ve Google bunları farklı siteler olarak görebilir.

Kontrol Yöntemi:

Her versiyonu tarayıcınıza yazın ve hangilerinin yüklendiğini kontrol edin. Birden fazla versiyon yükleniyorsa sorununuz var demektir.

Çözüm: 301 Redirect ve Canonical

1. Tercih Edilen Versiyonu Seçin

İki temel seçeneğiniz var:

• https://example.com (www’suz)
• https://www.example.com (www’li)

Hangisini seçmelisiniz? Tamamen tercihinize bağlı. Ancak:

• Daha kısa URL’ler için: www’suz
• Subdomain esnekliği için: www’li

2. Diğer Tüm Versiyonları 301 Redirect ile Yönlendirin

.htaccess ile (Apache sunucular):

# www'suz versiyonu tercih ediyorsanız
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# www'li versiyonu tercih ediyorsanız
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Nginx ile:

# www'suz versiyonu tercih ediyorsanız
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

3. Canonical Tag Ekleyin

Her sayfanın <head> bölümüne:

<link rel="canonical" href="https://example.com/sayfa-adi/" />

4. Google Search Console’da Tercih Bildirin

Güncelleme: Tercih edilen versiyonu GSC’ye bildirmek artık zorunlu değildir. Google, 301 yönlendirmelerini ve canonical etiketlerini temel alarak tercihi otomatik belirler. Ancak mülkünüzü (https://www) GSC’ye doğru şekilde eklediğinizden emin olun.

Doğrulama:

1. Farklı versiyonları tarayıcıda test edin
2. 301 redirect’in çalıştığından emin olun
3. Canonical tag’lerin doğru olduğunu kontrol edin

Canonical Etiketi ve Kanonikleştirme

Bir önceki başlık, sitenin dört farklı versiyonundan tekini seçmeyi anlattı. Kanonikleştirme aynı sorunun sayfa düzeyindeki hâlidir: aynı ya da çok benzer içeriğe birden fazla URL’den ulaşılabildiğinde, Google’a “asıl adres bu” demenin yolu.

Bu, teknik SEO’da en çok yanlış anlaşılan konudur. Net olalım:

Canonical bir direktif değil, ipucudur. Google onu sinyallerden yalnızca biri sayar. Sayfa içeriği, iç linkler, sitemap ve yönlendirmeler başka bir URL’yi işaret ediyorsa, Google sizin canonical’ınızı yok sayar ve kendi seçimini yapar.

Tipik duplicate URL kaynakları:

/urun/ayakkabi              ← asıl sayfa
/urun/ayakkabi?utm_source=newsletter   ← kampanya parametresi
/urun/ayakkabi?renk=siyah              ← varyant
/urun/ayakkabi/                        ← sondaki slash
/URUN/Ayakkabi                         ← büyük/küçük harf
/kadin/ayakkabi                        ← ikinci kategori yolu
/urun/ayakkabi?sayfa=1                 ← ilk sayfanın parametreli hâli

Doğru uygulama — dört kural:

1. Her sayfada self-referencing canonical bulunsun. Duplicate sorunu olmasa bile. Sayfa kendi kendini işaret ettiğinde, birisi URL’nize parametre ekleyerek link verdiğinde otomatik korunmuş olursunuz.
2. Mutlak URL kullanın. /sayfa değil https://alanadi.com/sayfa. Göreli canonical, staging ortamında yanlış alan adını işaret edebilir.
3. Canonical hedefi 200 dönmeli, indekslenebilir olmalı. Yönlendirilen, 404 veren veya noindex’li bir URL’yi canonical göstermek en sık görülen hatadır.
4. Tek sayfada tek canonical. Tema bir tane, eklenti bir tane basarsa Google ikisini de yok sayabilir.

Canonical ile noindex’i asla birlikte kullanmayın. Bu ikisi çelişen emirler verir: canonical “bu içeriği şu URL’de birleştir” derken, noindex “bu içeriği indeksten çıkar” der. Google çoğunlukla noindex’i uygular ve canonical hedefi de zarar görebilir.

“Duplicate, Google chose different canonical than user”

Search Console → Sayfalar raporunda bu uyarıyı görüyorsanız: Google canonical’ınızı gördü ve reddetti. Bu bir hata mesajı değil, bir anlaşmazlık bildirimidir. Kontrol sırası:

• URL Denetimi aracına sorunlu URL’yi girin; “Kullanıcı tarafından belirtilen” ile “Google tarafından seçilen” canonical’ı yan yana görün.
• Google’ın seçtiği URL’ye kendi sitenizden daha çok iç link veriyor musunuz? Verdiğiniz her iç link bir oy.
• Sitemap’inizde hangi versiyon var? Sitemap’teki URL güçlü bir canonical sinyalidir.
• İki sayfa gerçekten farklı mı? Eğer içerik %90 aynıysa Google haklı olabilir — canonical’ı zorlamak yerine sayfaları birleştirin.

Cross-domain canonical da mümkündür: içeriğinizi başka bir sitede yayımlıyorsanız (syndication), o site sizin URL’nizi canonical göstermelidir. Google bunu genellikle dikkate alır ama garanti etmez.

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

Redirect chain’ler ve loop’lar, SEO performansınızı olumsuz etkiler çünkü:

• Sayfa yükleme hızını düşürür
• Crawl budget’ı israf eder
• Ranking gücünün tam aktarılmasını engeller

📊 İSTATİSTİK: Ahrefs’in 1 milyondan fazla alan adını kapsayan site audit derlemesinde, incelenen sitelerin yaklaşık %12’sinde redirect chain veya loop tespit edilmişti (Ahrefs, 2020 — oran güncel olmayabilir, büyüklük mertebesi fikri için verilmiştir).

Redirect Chain Nedir?

Bir URL’nin başka bir URL’ye, onun da başka bir URL’ye yönlendirmesidir.

❌ KÖTÜ: Redirect Chain

URL A → 301 → URL B → 301 → URL C → 301 → URL D

Kullanıcı: 4 adım bekler
Bot: Crawl budget israfı
SEO: Her adımda güç kaybı

✅ İYİ: Doğrudan Redirect

URL A → 301 → URL D

Kullanıcı: Hızlı yönlendirme
Bot: Verimli crawling
SEO: Maksimum güç aktarımı

Redirect Loop Nedir?

URL’lerin birbirlerine sonsuz döngü halinde yönlendirilmesidir.

❌ Redirect Loop:

URL X → 301 → URL Y → 301 → URL X
[Sonsuz döngü]

Sonuç: Sayfa yüklenemez, kullanıcı hata görür

Tespit Yöntemi:

1. Tarayıcı Geliştirici Araçları:

Chrome DevTools’u açın (F12) → Network → Sayfayı yenileyin → Status kodlarını kontrol edin

2. Online Araçlar:

• Redirect Checker: https://httpstatus.io/
• Screaming Frog SEO Spider

3. Ahrefs Site Audit:

Ahrefs Site Audit’te otomatik tespit edilir ve raporlanır.

Düzeltme:

Redirect Chain İçin:

1. Chain’deki ara URL’leri belirleyin
2. Tüm eski URL’leri final URL’ye doğrudan yönlendirin
3. .htaccess veya sunucu yapılandırmasını güncelleyin

# Yanlış (Chain):
Redirect 301 /eski-sayfa /ara-sayfa
Redirect 301 /ara-sayfa /yeni-sayfa

# Doğru (Direct):
Redirect 301 /eski-sayfa /yeni-sayfa
Redirect 301 /ara-sayfa /yeni-sayfa

Redirect Loop İçin:

1. Döngüyü oluşturan redirect’leri tespit edin
2. Yanlış yapılandırılmış kuralı kaldırın veya düzeltin
3. URL’lerin kendilerine yönlendirilmediğinden emin olun

Best Practices:

• Maksimum 1 redirect kullanın (kaynak → hedef)
• Redirect’leri düzenli kontrol edin
• Site yapısı değişikliklerinde redirect planlaması yapın
• 302 (temporary) yerine 301 (permanent) kullanın

Server Errors (5xx Hataları) ve SEO Etkisi

Server hataları, sunucunuzun bir sorunu olduğunu ve isteği yerine getiremediğini gösterir. Bu hatalar, arama motorlarının içeriğinizi taramasını ve indekslemesini engeller.

📊 İSTATİSTİK: Aynı derlemede sitelerin yaklaşık %10’unda düzenli olarak bir tür sunucu hatası görülmüştü (Ahrefs, 2020). Kendi oranınızı Search Console → Ayarlar → Tarama istatistikleri’nden ölçün; sektör ortalaması yerine kendi verinize bakın.

Yaygın 5xx Hataları:

500 Internal Server Error:

En yaygın server hatası. Nedenleri:
- Yanlış yapılandırılmış .htaccess
- PHP hataları
- Sunucu kaynakları yetersiz
- Veritabanı bağlantı sorunları
- Plugin veya tema uyumsuzluğu

503 Service Unavailable:

Genellikle geçicidir. Nedenleri:
- Ani trafik artışı
- DDoS saldırısı
- Sunucu bakımı
- Kaynak limitleri aşıldı

Tespit Yöntemi:

1. Ahrefs Site Audit & Semrush Site Audit:

Site Audit → Issues → “5xx” ara

2. Google Search Console:

Search Console → Sayfalar (eski adıyla Coverage) → “Sunucu hatası (5xx)” nedeni

3. Server Logları:

cPanel veya hosting kontrolünde error logs kontrol edin.

Düzeltme:

Server hataları teknik uzmanlık gerektirir. Genellikle:

1. Hosting sağlayıcınızla iletişime geçin
2. Error loglarını inceleyin (hata mesajları ipucu verir)
3. Son değişiklikleri geri alın (plugin, tema güncellemeleri)
4. .htaccess dosyasını kontrol edin (syntax hataları)
5. Sunucu kaynaklarını artırın (gerekirse hosting planını yükseltin)

WordPress Özel İpuçları:

500 Hatası için:
1. Tüm plugin'leri devre dışı bırakın
2. Varsayılan temaya geçin
3. PHP memory limit'i artırın (wp-config.php)
4. .htaccess'i yeniden oluşturun

Önleyici Tedbirler:

• Uptime monitoring kullanın (UptimeRobot, Pingdom)
• Düzenli backup alın
• CDN kullanın (trafik dağılımı için)
• Caching aktif edin
• Sunucu kaynaklarını izleyin

Crawl Budget Optimizasyonu

Önce şunu netleştirelim: bu konu çoğu siteyi ilgilendirmiyor. Google’ın kendi kılavuzu açık — birkaç bin URL’nin altındaki siteler genellikle verimli taranır ve tarama bütçesiyle uğraşmaları gerekmez. Tarama bütçesi; on binlerce URL’li e-ticaret siteleri, haber siteleri ve marketplace’ler için gerçek bir kısıttır. 200 sayfalık bir kurumsal sitede indekslenmeyen sayfalarınız varsa sorun bütçe değil, neredeyse her zaman içerik kalitesi veya iç link eksikliğidir.

Crawl Budget Nedir?

Google, her web sitesine, içeriğini taramak için günde, haftada veya ayda ayıracağı sınırlı bir zaman ve kaynak tahsis eder. Buna Tarama Bütçesi denir.

Büyük Siteler İçin Kritik: Eğer sitenizde 100.000 sayfa varsa, ancak Google size günde sadece 5.000 sayfa tarama bütçesi ayırıyorsa, en önemli sayfalarınızın (yeni ürünler, güncel makaleler) taranması ve indekslenmesi gecikebilir.

Boşa Harcanan Bütçe: Googlebot, tarama bütçesini; filtreli sayfalar, sıralanmış URL’ler, teşekkür sayfaları, eski yorum dizinleri, veya zayıf ve tekrarlanan (thin/duplicate) içerik barındıran sayfaları tarayarak boşa harcayabilir.

Crawl Budget’ı Etkileyen Faktörler:

1. Site popülaritesi: Popüler siteler daha sık taranır
2. İçerik güncellik sıklığı: Sık güncellenen siteler daha sık taranır
3. Sayfa sayısı: Çok sayfalı siteler için daha kritik
4. Sunucu yanıt süresi: Yavaş sunucu = daha az tarama
5. Site hataları: Çok hata = azalan tarama

Crawl Budget’ı Optimize Etme:

• ✅ Gereksiz sayfaları engelleyin
• ✅ Duplicate content’i azaltın
• ✅ Redirect chain’leri düzeltin
• ✅ 404 hatalarını minimize edin
• ✅ Sunucu hızını artırın
• ✅ Sitemap kullanın
• ✅ Düşük kaliteli sayfaları noindex yapın

Google Search Console’da Crawl Stats:

GSC → Settings → Crawl Stats

Burada görebilirsiniz:

• Günlük ortalama crawl istekleri
• Günlük ortalama indirilen veri
• Ortalama yanıt süresi

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

Googlebot bir URL’yi çekerken içeriğin bir kısmını kesebilir. 2026’da bu tavan pratikte URL başına yaklaşık 2 MB seviyesine indi (önceki dönemlerde daha yüksekti). Limitin ötesi truncate edilir; o noktadan sonraki metin, link ve JSON-LD hem render’a hem indekse girmeyebilir.

• Kritik içerik, canonical ve schema’yı HTML’in başına yakın koyun.
• Tek sayfada dev HTML + sayfa sonuna gömülü markup taşımayın.
• Şişmiş DOM (üçüncü parti widget, dev inline CSS) hem CWV’yi hem crawl’ı bozar.

SEO Açısından HTTP Durum Kodları

Sunucunuzun döndürdüğü üç haneli sayı, Googlebot’a ne yapacağını söyleyen en temel sinyaldir. Yanlış kod, doğru içeriği görünmez yapar.

En pahalı hata 302 ile 301’i karıştırmaktır. Kalıcı bir taşımayı 302 ile yaparsanız Google eski URL’yi indekste tutmaya devam eder ve yeni URL uzun süre sıralama alamaz. Emin değilseniz kalıcı taşımalarda her zaman 301 kullanın.

Bakım sırasında 200 dönmeyin. “Sitemiz bakımda” yazan bir sayfa 200 dönerse Google onu gerçek içerik sanır ve indeksler. Doğrusu:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

404 mü, 410 mu?

Soft 404 (sayfa boş / “bulunamadı” ama 200 dönüyor) Google’ı şaşırtır. Temiz sinyal:

• 404 — kaynak yok; geri gelebilir.
• 410 — kalıcı silindi; indeksten düşmesini hızlandırmak istiyorsanız daha nettir.
• 503 + Retry-After — geçici bakım. 200 + “bakımdayız” metni kullanmayın.

Kontrol Listesi: Crawling ve Indexing

Hemen Yapılması Gerekenler:

• Sitenizin indekslendiğini kontrol edin (site:yourdomain.com)
• Google Search Console’da “Sayfalar” raporunu inceleyin
• Robots.txt dosyanızı kontrol edin, önemli sayfaları engellememekten emin olun
• HTTP/HTTPS ve WWW duplicate’lerini 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
• Crawl budget kullanımını GSC’de izleyin
• 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

2. Site Performansı ve UX

Site performansı ve kullanıcı deneyimi (UX), modern SEO’nun vazgeçilmez unsurlarıdır. Google, 2021’den itibaren “Page Experience” sinyallerini resmi sıralama faktörü olarak kullanmaya başladı. 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, Google’ın kullanıcı deneyimini ölçmek için belirlediği üç temel metrikten oluşur ve resmi olarak bir sıralama faktörüdür.

Üç Temel Metrik:

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, lazy loading -->
<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)
• Above-the-fold görseller 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

İdeal TTFB: < 200ms

TTFB İyileştirme:

• Kaliteli hosting kullanın (shared hosting yerine VPS/dedicated)
• Server-side caching aktif edin (Redis, Memcached)
• CDN kullanın
• Veritabanı sorgularını optimize edin
• PHP versiyonunu güncel tutun

Türkiye notu: TTFB için hosting lokasyonu işe yarar. Ziyaretçilerin çoğu TR ise İstanbul / Avrupa edge’li CDN, ABD origin’den daha kısa ilk byte verir. Shared hosting + uzak origin, LCP’yi daha HTML optimize etmeden bozar.

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 Nedir?

INP, kullanıcı bir etkileşimde bulunduğunda (tıklama, tuşa basma, dokunma) sayfanın görsel olarak yanıt vermesi için geçen süreyi ölçer. 2024’te FID (First Input Delay) metriğinin yerini aldı.

INP Değerlendirmesi:

🟢 İYİ:    0 - 200 ms
🟡 ORTA:   200 - 500 ms
🔴 KÖTÜ:   500+ ms

INP’yi İyileştirme Stratejileri:

A. JavaScript Yürütme Süresini Azaltın

// ❌ KÖTÜ: Ana thread'i blokleyen uzun işlem
function processLargeData() {
  const result = [];
  for (let i = 0; i < 1000000; i++) {
    result.push(complexCalculation(i));
  }
  return result;
}

// ✅ İYİ: İşi parçalara böl ve her parça arasında main thread'e yield et
async function processLargeData(data) {
  const result = [];
  const batchSize = 1000;

  for (let i = 0; i < data.length; i += batchSize) {
    const end = Math.min(i + batchSize, data.length);
    for (let j = i; j < end; j++) {
      result.push(complexCalculation(data[j]));
    }
    // Tarayıcıya "araya gir, kullanıcıya yanıt ver" izni verir
    await yieldToMain();
  }
  return result;
}

function yieldToMain() {
  // scheduler.yield() INP için tasarlanmış modern API'dir
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }
  // Fallback: setTimeout 0 da main thread'i serbest bırakır
  return new Promise(resolve => setTimeout(resolve, 0));
}

Not: Bu iş için requestIdleCallback önerildiğini sık görürsünüz. Ancak o API, tarayıcı boşta kalana kadar bekler — yoğun bir sayfada hiç çalışmayabilir. INP için doğru araç scheduler.yield(), desteklenmeyen yerde setTimeout(…, 0) fallback’idir.

B. Third-Party Script’leri Optimize Edin

Üçüncü parti scriptler INP’nin bir numaralı düşmanıdır. Bunları tek tek sayfaya gömmek yerine Google Tag Manager üzerinden yönetmek, hangi scriptin ne zaman yükleneceğini tek yerden kontrol etmenizi sağlar — ama GTM’in kendisi de bir script olduğundan, içine attığınız her etiketi aynı titizlikle denetlemeniz gerekir.

<!-- Third-party scriptlerin etkisini azaltın -->

<!-- ❌ KÖTÜ: Senkron yükleme -->
<script src="https://third-party.com/script.js"></script>

<!-- ✅ İYİ: Async + gecikmeli yükleme -->
<script>
  // Sayfa yüklendikten sonra third-party script'i yükle
  window.addEventListener('load', function() {
    setTimeout(function() {
      const script = document.createElement('script');
      script.src = 'https://third-party.com/script.js';
      script.async = true;
      document.body.appendChild(script);
    }, 3000); // 3 saniye gecikme
  });
</script>

C. Event Handler’ları Optimize Edin

// ❌ KÖTÜ: Tıklamadan sonra boyama, ağır hesap bitene kadar bekler
button.addEventListener('click', function() {
  const result = expensiveCalculation(); // main thread kilitli
  updateUI(result);
});

// ❌ AYNI DERECEDE KÖTÜ: Tıklamayı debounce etmek
// Debounce, INP'yi İYİLEŞTİRMEZ — boyamayı 300ms geciktirir.
button.addEventListener('click', debounce(handler, 300));

// ✅ İYİ: Önce görsel geri bildirimi boya, SONRA ağır işi yap
button.addEventListener('click', async function() {
  // 1) Kullanıcı anında tepki görsün — INP burada ölçülür
  button.setAttribute('aria-busy', 'true');
  showSpinner();

  // 2) Tarayıcının boyamasına izin ver
  await yieldToMain();

  // 3) Ağır işi şimdi çalıştır
  const result = expensiveCalculation();
  updateUI(result);
  button.removeAttribute('aria-busy');
});

Kritik ayrım: Debounce ve throttle, scroll ve input gibi saniyede onlarca kez tetiklenen olaylar için doğru araçtır. Tek bir tıklamada ise yanlıştır: INP, etkileşimden sonraki ilk boyamaya kadar geçen süreyi ölçer — o boyamayı geciktiren her şey metriği doğrudan kötüleştirir.

D. CSS Animasyonları için GPU Kullanın

/* ❌ KÖTÜ: CPU-intensive animasyon */
.element {
  transition: left 0.3s, top 0.3s;
}

.element:hover {
  left: 100px;
  top: 100px;
}

/* ✅ İYİ: GPU-accelerated animasyon */
.element {
  transition: transform 0.3s;
}

.element:hover {
  transform: translate(100px, 100px);
}

/* will-change'i KALICI bırakmayın — her eleman için GPU katmanı
   ayrılır ve bellek tüketir. Yalnızca animasyon başlamadan hemen
   önce, hover edilen kapsayıcı üzerinden verin: */
.card:hover .element {
  will-change: transform;
}

INP İyileştirme Kontrol Listesi:

• JavaScript bundle boyutunu küçültün (code splitting)
• Gereksiz JavaScript’leri kaldırın
• Third-party script’leri async yükleyin
• Uzun işlemleri Web Workers’a taşıyın
• Event listener’ları optimize edin (debounce/throttle)
• CSS animasyonları için transform ve opacity kullanın

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

CLS Nedir?

CLS, sayfa yüklenirken öğelerin beklenmedik şekilde yer değiştirmesini ölçer. Kullanıcı bir butona tıklamak üzereyken öğelerin kayması kötü bir deneyimdir.

CLS Değerlendirmesi:

🟢 İYİ:    0 - 0.1
🟡 ORTA:   0.1 - 0.25
🔴 KÖTÜ:   0.25+

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 */
img {
  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ç

Öneri: Çoğu durum için font-display: swap idealdir.

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
• CSS aspect-ratio kullanın
• Reklamlar için yer ayırın (min-height)
• Web fontları için font-display: swap kullanın
• 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?

1. Google Search Console

GSC → Core Web Vitals → Open Report

• Mobil ve masaüstü için ayrı raporlar
• “Poor”, “Needs Improvement”, “Good” kategorileri
• Hangi URL’lerin sorunlu olduğunu gösterir

2. PageSpeed Insights

URL: https://pagespeed.web.dev/

• Hem lab hem de field data gösterir
• Spesifik iyileştirme önerileri sunar
• Her metrik için detaylı analiz

3. Chrome DevTools (Lighthouse)

Chrome DevTools → Lighthouse → Performance

• Detaylı metrikler
• Opportunities ve Diagnostics
• Film strip view (yükleme süreci)

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.

Kritik incelik — loading="lazy" nereye konmaz: Görünen alandaki (above-the-fold) görsele, özellikle LCP elemanına lazy loading uygularsanız LCP’yi doğrudan geciktirirsiniz. Kural basit: ekranın ilk görünen kısmındaki görsellerde loading="eager" + fetchpriority="high", aşağıdakilerde loading="lazy".

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

Video barındıran sayfalarda VideoObject schema’sı, videonun arama sonuçlarında küçük resimle çıkmasını ve “önemli anlar” (key moments) özelliğini mümkün kılar. Zorunlu alanlar: name, description, thumbnailUrl, uploadDate. Video dosyasını contentUrl veya embedUrl ile verin; Google erişemezse zengin sonuç üretmez.

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)

Google, 2019’dan itibaren “mobile-first indexing”e geçti ve Temmuz 2024’te bu geçiş tüm siteler için tamamlandı. Artık masaüstü-öncelikli taranan site kalmadı: Google sitenizin mobil versiyonunu indeksliyor ve sıralıyor. Pratik sonucu net — mobilde göstermediğiniz içerik, masaüstünde dursa bile indekslenmez.

Mobil Uyumluluğun Önemi:

• Google yalnızca mobil versiyonu indeksler
• Mobil trafik masaüstü trafiği geçti
• Mobil UX doğrudan ranking faktörü

Mobil Uyumlu Tasarım Prensipleri:

1. Responsive Design

/* Mobile-first approach */
.container {
  width: 100%;
  padding: 15px;
}

/* Tablet */
@media (min-width: 768px) {
  .container {
    max-width: 720px;
    margin: 0 auto;
  }
}

/* Desktop */
@media (min-width: 1024px) {
  .container {
    max-width: 960px;
  }
}

2. Viewport Meta Tag

<!-- ✅ Zorunlu: Responsive davranış için -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- ❌ Kullanmayın: Zoom'u engeller (UX sorunu) -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

3. Dokunma Hedefleri (Touch Targets)

/* Butonlar ve linkler en az 48x48 px olmalı */
.button {
  min-height: 48px;
  min-width: 48px;
  padding: 12px 24px;
  
  /* Dokunma hedefleri arası boşluk */
  margin: 8px;
}

4. Okunabilir Font Boyutları

/* ❌ KÖTÜ: Çok küçük font */
body {
  font-size: 12px;
}

/* ✅ İYİ: Okunabilir font boyutu */
body {
  font-size: 16px; /* Mobilde minimum */
  line-height: 1.5;
}

h1 {
  font-size: 2rem; /* 32px */
}

5. Yatay Kaydırmayı Önleyin

/* Tüm elementlerin container'a sığmasını sağlayın */
img, video, iframe {
  max-width: 100%;
  height: auto;
}

/* body { overflow-x: hidden } bir çözüm DEĞİL, örtbastır:
   içindeki tüm position:sticky elemanlarını bozar.
   Taşmanın kaynağını bulup düzeltin. DevTools konsolunda
   taşan elemanı şöyle bulabilirsiniz:

   document.querySelectorAll('*').forEach(el => {
     if (el.getBoundingClientRect().right > innerWidth) console.log(el);
   });
*/

Mobil Uyumluluk Testi:

Önce bir uyarı: Google’ın Mobile-Friendly Test aracı, aynı adlı API ve Search Console’daki Mobile Usability raporu 1 Aralık 2023’te emekli edildi. Eski test URL’si artık Lighthouse dokümantasyonuna yönleniyor. Bu araçları öneren kaynaklar güncelliğini yitirmiştir.

Bugün kullanılacak yöntemler:

1. Lighthouse (Chrome DevTools)

DevTools → Lighthouse → Mobile → Analyze. Google’ın resmî olarak yönlendirdiği yerine geçen araçtır. Performans, erişilebilirlik ve “Best Practices” skorlarını mobil emülasyonla verir.

2. PageSpeed Insights — Mobil sekmesi

pagespeed.web.dev hem gerçek kullanıcı verisini (field) hem lab verisini mobil için ayrı gösterir. Core Web Vitals mobil skoru, artık mobil uyumluluğun en anlamlı tek göstergesidir.

3. Search Console → Core Web Vitals

Mobil ve masaüstü için ayrı raporlar. Mobile Usability raporunun bıraktığı boşluğu pratikte bu rapor dolduruyor.

4. Responsive Design Mode

Chrome DevTools → Toggle Device Toolbar (Ctrl+Shift+M). Gerçek cihaz genişliklerinde gözle kontrol; viewport, taşma ve dokunma hedefi sorunlarını en hızlı burada görürsünüz.

Yaygın Mobil Uyumluluk Sorunları:

HTTPS Kullanımı

HTTPS (Hypertext Transfer Protocol Secure), web siteniz ile kullanıcılar arasındaki iletişimi şifreler. 2014’ten beri resmi sıralama faktörüdür.

HTTPS’nin Faydaları:

• ✅ SEO: Hafif sıralama avantajı
• ✅ Güvenlik: Veri şifreleme, MITM saldırılarını önleme
• ✅ Güven: Tarayıcılarda “Güvenli” rozeti
• ✅ HTTP/2: Sadece HTTPS ile çalışır (daha hızlı)
• ✅ Chrome Gereksinimi: Modern tarayıcı özellikleri için zorunlu
• ✅ Kullanıcı Güveni: Kullanıcılar HTTPS bekler

HTTP vs HTTPS:

❌ HTTP:  http://example.com
         Tarayıcı: "Güvenli Değil" uyarısı
         Veri: Şifrelenmemiş

✅ HTTPS: https://example.com
         Tarayıcı: 🔒 Kilit ikonu
         Veri: Şifrelenmiş

HTTPS Kontrol:

1. Sitenizi ziyaret edin, kilit ikonu göründüğünü kontrol edin
2. Chrome DevTools → Security → View Certificate
3. SSL Labs Test: https://www.ssllabs.com/ssltest/

HSTS ve Mixed Content

Sertifika kurmak işin yalnızca başlangıcı. İki yaygın açık kalır:

1. Mixed content (karışık içerik)

HTTPS bir sayfada HTTP üzerinden görsel, script veya stylesheet yüklüyorsanız tarayıcı uyarı verir veya kaynağı tamamen engeller. Engellenen bir CSS/JS dosyası, Google’ın sayfayı yanlış render etmesi demektir — yani doğrudan SEO sorunu.

# Sitenizdeki http:// referanslarını bulun
grep -rn "http://" --include="*.html" --include="*.css" --include="*.js" .

# Tarayıcıda: DevTools → Console → "Mixed Content" uyarılarına bakın

Protokolü sabitlemek yerine göreli protokol (//cdn.site.com/x.js) kullanmak eski bir çözümdür; bugün doğrusu her yerde açıkça https:// yazmaktır.

2. HSTS (HTTP Strict Transport Security)

301 yönlendirmesi çalışır ama her HTTP isteğinde bir tur fazladan gidiş-dönüş yaratır. HSTS başlığı tarayıcıya “bu alan adına bir daha asla HTTP ile bağlanma” der; yönlendirme ortadan kalkar, hem hız hem güvenlik kazanırsınız.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Dikkat: includeSubDomains tüm alt alan adlarını kapsar. HTTPS’i olmayan bir alt alan adınız varsa (eski bir blog. veya test. gibi) erişilemez hâle gelir. Önce kısa bir max-age ile (örneğin 300) test edin, sorun çıkmazsa bir yıla çıkarın.

Sertifika yenilemeyi otomatikleştirin. Süresi dolmuş sertifika, tarayıcının tam ekran güvenlik uyarısı göstermesine ve Googlebot’un sayfaya erişememesine yol açar — birkaç gün sürerse indeks kaybı başlar. Let’s Encrypt kullanıyorsanız certbot renew cron’da çalışıyor olmalı, ayrıca bir uptime servisiyle sertifika bitiş tarihini izleyin.

Pop-up Kullanımı

Google, 2017’den itibaren mobilde kullanıcı deneyimini engelleyen pop-up’ları cezalandırıyor.

Intrusive Interstitial Nedir?

Ana içeriği kapatan ve kullanıcının içeriğe erişimini engelleyen pop-up’lar, overlay’ler ve modallar.

Müdahaleci Kabul Edilen Pop-up’lar:

❌ Sayfa yüklenir yüklenmez tam ekran pop-up
❌ Ana içeriği tamamen kapatan standalone interstitial
❌ Above-the-fold alanını kaplayan layout (içerik aşağıda)
❌ İçeriğe erişmeden önce kapatılması gereken pop-up

İzin Verilen Pop-up’lar:

✅ Yasal zorunluluklar (Çerez bildirimi, yaş doğrulama)
✅ Login dialog’ları (paywall arkasındaki içerik)
✅ Küçük banner’lar (ekranın makul bir kısmını kaplar)
✅ Exit-intent pop-up’lar (kullanıcı ayrılırken)
✅ Scroll-triggered pop-up’lar (kullanıcı içerikle etkileşime geçtikten sonra)

İyi Pop-up Uygulamaları:

1. Zamanlama

// ❌ KÖTÜ: Hemen göster
window.addEventListener('load', function() {
  showPopup();
});

// ✅ İYİ: Kullanıcı etkileşime geçtikten sonra
let scrolled = false;
window.addEventListener('scroll', function() {
  if (window.scrollY > 1000 && !scrolled) {
    scrolled = true;
    setTimeout(showPopup, 3000); // 3 saniye sonra
  }
});

2. Boyut

/* Ekranın en fazla %30-40'ını kaplasın */
.popup {
  max-width: 400px;
  max-height: 300px;
  
  /* Mobilde daha küçük */
  @media (max-width: 768px) {
    max-width: 90%;
    max-height: 40vh;
  }
}

3. Kolay Kapatma

<div class="popup">
  <!-- Büyük, açık kapatma butonu -->
  <button class="close-btn" aria-label="Kapat">✕</button>
  
  <!-- Arka plana tıklayarak da kapatılabilir -->
  <div class="popup-content">
    <!-- İçerik -->
  </div>
</div>

<style>
.close-btn {
  position: absolute;
  top: 10px;
  right: 10px;
  width: 40px;
  height: 40px;
  font-size: 24px;
}
</style>

4. Exit-Intent (Kullanıcı ayrılırken)

// Kullanıcı sayfadan ayrılmaya çalıştığında göster
document.addEventListener('mouseleave', function(e) {
  if (e.clientY < 0 && !popupShown) {
    showPopup();
    popupShown = true;
  }
});

Çerez Bildirimi (GDPR/KVKK):

<!-- ✅ İYİ: Küçük, alt tarafta -->
<div class="cookie-banner" style="
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
  background: #333;
  color: #fff;
  padding: 15px;
  font-size: 14px;
  z-index: 9999;
">
  <p>Bu site çerez kullanıyor. <a href="/cerez-politikasi">Detaylı bilgi</a></p>
  <button onclick="acceptCookies()">Kabul Et</button>
</div>

Pop-up Kullanımı Nasıl Olmalı?

• Sayfa yüklendiğinde hemen göstermeyin
• Kullanıcı içerikle etkileşime geçtikten sonra gösterin
• Mobilde ekranın %40’ından fazlasını kaplamayın
• Kolay kapatma butonu ekleyin
• Arka plana tıklayarak kapatmaya izin verin
• Exit-intent kullanın
• A/B test yapın (conversion vs SEO etkisi)

Pop-up’ın dönüşüme katkısıyla kullanıcı deneyimine maliyetini birlikte ölçmek gerekir: kazandırdığı kayıt sayısı kadar hemen çıkma oranına etkisine de bakın. Test kurgusunu doğru kurmak için dönüşüm oranı optimizasyonu rehberindeki yöntemi izleyebilirsiniz.

Performans ve UX İyileştirme Yol Haritası

Performans ve UX İyileştirme Yol Haritası”, site hızını ve kullanıcı deneyimini hangi sırayla, hangi adımlarla iyileştireceğini anlatan pratik bir aksiyon planıdır. Acil, kısa, orta ve uzun vadeli işleri ayırarak hem Core Web Vitals’ı hem de genel kullanıcı deneyimini sistematik şekilde optimize etmeni sağlar. Hadi bunu önceliklendirelim;

Öncelikli Maddeler:

1. Google Search Console’da Core Web Vitals’ı kontrol edin
2. Sitenizi PageSpeed Insights ile test edin
3. HTTPS aktif değilse hemen aktif edin
4. Viewport meta tag’i ekleyin
5. Müdahaleci pop-up’ları kaldırın veya optimize edin

Kısa Vadeli Öncelikler:

6. Görselleri optimize edin (WebP, sıkıştırma)
7. Görsellere width/height attribute ekleyin
8. CSS/JS minify ve combine edin
9. Browser caching aktif edin
10. CDN kullanmaya başlayın

Orta Vadeli Öncelikler:

11. Above-the-fold CSS’i inline yapın
12. JavaScript’leri defer/async yapın
13. Font loading stratejisini optimize edin
14. Third-party script’leri gözden geçirin
15. Server yanıt süresini iyileştirin

Uzun Vadeli Planlama:

16. HTTP/2 veya HTTP/3’e geçin
17. Progressive Web App (PWA) düşünün
18. Advanced caching stratejileri
19. Code splitting ve lazy loading
20. Web Workers kullanmayı değerlendirin

Performans İzleme ve Sürekli İyileştirme

Düzenli Kontrol:

• Haftalık: PageSpeed Insights kontrolü
• Aylık: Full Core Web Vitals audit
• Çeyreklik: Detaylı performance audit
• Sürekli: Real User Monitoring (RUM) – Google Analytics

Monitoring Araçları:

1. Google Search Console (Field data – gerçek kullanıcılar)
2. PageSpeed Insights (Lab + Field data)
3. Chrome UX Report (CrUX)
4. Lighthouse CI (Otomatik testler için)
5. WebPageTest (Detaylı waterfall analizi)
6. GTmetrix (Performans raporları)

Unutmayın:

• Performans optimizasyonu sürekli bir süreçtir
• Her güncelleme sonrası performansı test edin
• Gerçek kullanıcı verilerine odaklanın (field data)
• Lab data iyi olabilir ama field data kötü olabilir
• Mobile-öncelikli düşünün, masaüstü ikinci planda

3. Site Mimarisi ve Navigation

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: Her sayfa, ana sayfadan maksimum 3-4 tıklama uzaklıkta
✅ 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 sayfaya ana sayfadan kaç tıklamayla ulaşılabildiğini gösterir. Google, daha sığ derinlikteki sayfaları daha önemli olarak değerlendirir.

Tıklama Derinliği Sınıflandırması:

DerinlikSayfa TipiÖncelik0 tıklamaAna SayfaEn Yüksek1 tıklamaAna kategoriler, hizmetlerÇok Yüksek2 tıklamaAlt kategoriler, önemli içeriklerYüksek3 tıklamaÜrünler, blog yazılarıOrta4+ tıklamaDerin içerikler, arşivDüşük

Kural: Önemli sayfalarınız 3 tıklamadan fazla uzakta olmamalıdır.

Örnek:

✅ İYİ: 
Ana Sayfa → Elektronik → Telefonlar → iPhone 15 Pro
(3 tıklama)

❌ KÖTÜ:
Ana Sayfa → Ürünler → Kategoriler → Elektronik → Mobil → Akıllı Telefonlar → Apple → iPhone → iPhone 15 Pro
(8 tıklama)

Tıklama Derinliğini Azaltma:

1. Yatay genişletme: Daha fazla kategori, daha az derinlik
2. Internal linking: Derin sayfalara kısayol linkleri
3. Hub pages: Ana konular için merkezi sayfalar
4. Footer/Header links: Önemli sayfalara her yerden erişim
5. Sitemap: Tüm sayfaları listele

Internal Linking (İç Bağlantı) Stratejisi

Internal linkler, sitenizin bir sayfasından başka bir sayfasına verdiğiniz linklerdir. SEO’nun en güçlü araçlarından biridir.

Internal Linking’in Faydaları:

1. Crawling: Botların yeni sayfaları keşfetmesine yardımcı olur
2. Indexing: Sayfaların indekslenmesini hızlandırır
3. PageRank Flow: Otoritenin sayfalar arasında dağıtılması
4. Kullanıcı Deneyimi: Ziyaretçilerin ilgili içeriği bulması
5. Keyword Relevance: Anchor text ile konu ilişkisi kurma

Internal Link Türleri:

1. Navigation Links (Navigasyon Linkleri)

Menü, header, footer ve sidebar’daki linkler.

html

<!-- Header Navigation -->
<nav>
  <ul>
    <li><a href="/">Ana Sayfa</a></li>
    <li><a href="/hakkimizda">Hakkımızda</a></li>
    <li><a href="/hizmetler">Hizmetler</a></li>
    <li><a href="/blog">Blog</a></li>
    <li><a href="/iletisim">İletişim</a></li>
  </ul>
</nav>

2. Contextual Links (İçerik İçi Linkler)

İçerik içinde, doğal olarak yer alan linkler. En değerli link türüdür.

html

<p>
  SEO çalışmalarınızda 
  <a href="/anahtar-kelime-arastirmasi">anahtar kelime araştırması</a> 
  yapmak kritik öneme sahiptir. Doğru anahtar kelimeleri belirledikten sonra, 
  <a href="/on-page-seo">on-page optimizasyon</a> yaparak içeriğinizi 
  güçlendirebilirsiniz.
</p>

3. Breadcrumb Links

Kullanıcının sayfadaki konumunu gösteren linkler.

html

<nav aria-label="breadcrumb">
  <ol>
    <li><a href="/">Ana Sayfa</a></li>
    <li><a href="/elektronik">Elektronik</a></li>
    <li><a href="/elektronik/telefonlar">Telefonlar</a></li>
    <li aria-current="page">iPhone 15 Pro</li>
  </ol>
</nav>

4. Related Posts / Benzer İçerikler

Makale sonunda veya sidebar’da ilgili içeriklere linkler.

html

<aside class="related-posts">
  <h3>İlgili Makaleler</h3>
  <ul>
    <li><a href="/link-building-stratejileri">Link Building Stratejileri</a></li>
    <li><a href="/backlink-analizi">Backlink Analizi Nasıl Yapılır?</a></li>
    <li><a href="/guest-posting">Guest Posting Rehberi</a></li>
  </ul>
</aside>

Internal Linking Best Practices:

1. Tanımlayıcı Anchor Text Kullanın

html

<!-- ❌ KÖTÜ: Generic anchor text -->
<a href="/seo-rehberi">buraya tıklayın</a>
<a href="/urunler">daha fazla bilgi</a>

<!-- ✅ İYİ: Descriptive anchor text -->
<a href="/seo-rehberi">kapsamlı SEO rehberi</a>
<a href="/urunler">tüm ürünlerimiz</a>

2. Relevant (İlgili) Sayfalara Link Verin

✅ İYİ: 
"iPhone 15 Özellikleri" makalesinden 
→ "iPhone 15 vs iPhone 14 Karşılaştırması"

❌ KÖTÜ:
"iPhone 15 Özellikleri" makalesinden 
→ "Pasta Tarifleri"

3. Dofollow Kullanın (Internal Linklerde)

html

<!-- ✅ İYİ: Internal linkler varsayılan olarak dofollow -->
<a href="/diger-sayfa">Link</a>

<!-- ❌ KÖTÜ: Internal linkleri nofollow yapma -->
<a href="/diger-sayfa" rel="nofollow">Link</a>

İstisna: Login, kayıt, sepet gibi sayfalara nofollow kullanabilirsiniz.

4. Link Sayısını Dengeleyin

• Sayfada aşırı fazla internal link olmasın (spam sinyali)
• Çok az link de olmasın (bağlantısız kalan sayfalar)
• Makale içi: 2-5 contextual link ideal
• Toplam link sayısı için sabit bir üst sınır yok. Google’ın eski “sayfa başına 100 link” kılavuzu yıllar önce kaldırıldı; ölçü, linklerin kullanıcıya anlamlı gelmesidir. Navigasyon şişkinliğinden kaçının — 300 linklik bir mega menü, link değerini gerçekten seyreltir.

5. Derin Sayfalara Link Verin

Sadece kategorilere değil, derin içeriklere de link verin:

✅ İYİ:
Ana Sayfa → Blog İndeksi → Spesifik Makale

Ayrıca:
Ana Sayfa → Doğrudan Popüler Makaleye

6. Link Dilution’dan Kaçının

Aynı hedefe aynı sayfadan üst üste link vermekten kaçının. “Yalnızca ilk linkin anchor text’i sayılır” eski bir gözlemdir, Google’ın açıkladığı bir kural değildir — bu yüzden kesin bir yasak gibi değil, temizlik ilkesi olarak uygulayın: bir hedefe bir anlamlı bağlantı yeter, gerisi okuru yorar.

html

<!-- ❌ KÖTÜ: Aynı sayfaya 3 link -->
<a href="/seo-rehberi">SEO Rehberi</a>
...
<a href="/seo-rehberi">rehber sayfası</a>
...
<a href="/seo-rehberi">buraya tıklayın</a>

<!-- ✅ İYİ: Bir link yeterli -->
<a href="/seo-rehberi">kapsamlı SEO rehberi</a>

Internal Linking Stratejileri:

A. Hub and Spoke Model (Merkez ve Kol Modeli)

                   Hub Page
              (Ana Konu Sayfası)
                      |
        ______________|______________
        |       |       |       |        |
    Spoke   Spoke   Spoke   Spoke    Spoke
   (Alt     (Alt    (Alt    (Alt     (Alt
   Konu 1)  Konu 2) Konu 3) Konu 4)  Konu 5)

Hub Page: "SEO Rehberi"
Spoke Pages: 
- "Anahtar Kelime Araştırması"
- "On-Page SEO"
- "Link Building"
- "Technical SEO"
- "SEO Araçları"

Her spoke, hub'a geri link verir.

B. Content Silo Structure (İçerik Silolama)

İlgili içerikleri gruplar halinde organize etmek.

Silo 1: SEO
    ├── On-Page SEO
    ├── Off-Page SEO
    └── Technical SEO
        (Silo içi linkler yoğun)

Silo 2: İçerik Pazarlama
    ├── Blog Yazma
    ├── Copywriting
    └── İçerik Stratejisi
        (Silo içi linkler yoğun)

Silolar arası minimal link

C. Pillar-Cluster Model

Geniş bir ana sayfa (pillar) ve onu besleyen spesifik alt içerikler. Örneğin bir dijital pazarlama pillar sayfası; SEO, Google Ads ve analitik cluster’larını toplar, her cluster da pillar’a geri link verir.

Pillar Page: Geniş, kapsamlı ana sayfa
    |
    ├── Cluster 1 (spesifik alt konu)
    ├── Cluster 2 (spesifik alt konu)
    ├── Cluster 3 (spesifik alt konu)
    └── Cluster 4 (spesifik alt konu)

Örnek:
Pillar: "Dijital Pazarlama Rehberi"
Clusters:
- SEO Temelleri
- Google Ads Stratejileri
- Sosyal Medya Pazarlama
- E-mail Marketing

Orphan Pages (Yetim Sayfalar)

Orphan page, sitede hiçbir internal link almayan sayfalardır. Bu sayfalar:

• Botlar tarafından keşfedilmesi zor
• Düşük PageRank
• Düşük görünürlük

📊 İSTATİSTİK: 50.000’den fazla alan adının incelendiği bir Ahrefs analizinde sitelerin %69’unda en az bir orphan page bulunmuştu (Ahrefs, 2020). Tarih eski olsa da sorun hâlâ çok yaygın ve genellikle gözden kaçıyor.

Orphan Page Tespiti:

1. Google Analytics 4

GA4 → Raporlar → Etkileşim → Sayfalar ve ekranlar. (Universal Analytics’teki “Behavior → Site Content” menüsü Temmuz 2023’te kapandı, GA4’te karşılığı bu rapordur.)

Sitemap’te olup burada hiç görüntülenme almayan sayfalar orphan adayıdır. Google Analytics kurulumu eksikse bu kontrol yanıltıcı sonuç verir; önce ölçümün doğruluğundan emin olun.

2. Screaming Frog

Screaming Frog → Crawl → Orphan Pages

3. Ahrefs Site Audit

Site Audit → Issues → “Orphan pages”

Orphan Page Çözümü:

1. Internal link ekleyin: İlgili sayfalardan link verin
2. Navigation’a ekleyin: Önemliyse menüye ekleyin
3. Related posts: Benzer içeriklerle bağlayın
4. Sitemap: XML sitemap’e eklenmişse Google bulur (ama yeterli değil)
5. Silin: Gerçekten gereksizse 404 verin veya 301 redirect yapın

Breadcrumbs (Kırıntı İzi)

Breadcrumb, kullanıcının sitedeki konumunu gösteren ve geçmiş sayfalara dönmesini sağlayan navigasyon yardımcısıdır.

Breadcrumb Örneği:

Ana Sayfa > Elektronik > Telefonlar > iPhone 15 Pro

Breadcrumb’ın Faydaları:

✅ Kullanıcı Deneyimi: Nerede olduğunu bilir, kolayca geri döner ✅ SEO: Internal linking güçlenir ✅ SERP Görünümü: Google arama sonuçlarında gösterilir ✅ Tıklama Oranı: SERP’te daha çekici görünüm

SERP’te Breadcrumb Görünümü:

example.com › Elektronik › Telefonlar
iPhone 15 Pro İnceleme ve Özellikleri
iPhone 15 Pro'nun tüm özelliklerini, fiyatını ve kullanıcı 
yorumlarını inceleyin...

Breadcrumb Türleri:

1. Location-Based (Konum Bazlı)

En yaygın türdür. Site hiyerarşisini gösterir.

Ana Sayfa > Kategori > Alt Kategori > Sayfa

2. Attribute-Based (Özellik Bazlı)

E-ticaret filtrelerinde kullanılır.

Ana Sayfa > Telefonlar > Marka: Apple > Renk: Siyah

3. History-Based (Geçmiş Bazlı)

Kullanıcının gezinme geçmişini gösterir (önerilmez, SEO faydası yok).

Ana Sayfa > Blog > Başka Sayfa > Mevcut Sayfa

Breadcrumb Best Practices:

✅ Her sayfada gösterin (ana sayfa hariç)
✅ Schema markup ekleyin (Google Rich Results için)
✅ Kısa tutun (maksimum 4-5 seviye)
✅ Tıklanabilir yapın (son öğe hariç)
✅ URL yapısıyla uyumlu olsun
❌ JavaScript ile dinamik oluşturmayın (SEO sorunu)
❌ Sayfa başlığını tekrar etmeyin

Breadcrumb Ne Zaman Kullanılmaz?

• Küçük siteler (5-10 sayfa)
• Düz hiyerarşi (sadece ana sayfa + içerik sayfaları)
• Tek seviye blog siteleri

Site Mimarisi Optimizasyonu: Pratik Adımlar

1. Mevcut Yapınızı Analiz Edin

A. Site Crawl:

Screaming Frog veya Ahrefs Site Audit kullanarak:

• Tüm sayfaları listeleyin
• Tıklama derinliğini görün
• Orphan sayfaları tespit edin
• Internal link dağılımını analiz edin

B. Görselleştirin:

Excel veya araçlarla site haritası oluşturun:
- Ana sayfadan her sayfaya kaç tıklama?
- Hangi sayfalar en çok internal link alıyor?
- Hangi sayfalar hiç link almıyor? (orphan)

2. İdeal Yapıyı Planlayın

Kategorileri Belirleyin:

Sorular:
- Ana konularım neler?
- Bu konular kaç alt kategoriye ayrılabilir?
- Maksimum kaç seviye gerekli?

Örnek Plan:
Seviye 1: 4-8 ana kategori
Seviye 2: Her kategoride 3-6 alt kategori
Seviye 3: İçerik sayfaları

Kategorileri iç sezgiyle değil talep verisiyle belirleyin. Anahtar kelime analizi, hangi konunun ana kategori olacak kadar arama hacmine sahip olduğunu ve hangisinin tek bir içerik sayfası olarak kalması gerektiğini gösterir — site mimarisi kararları aslında anahtar kelime kararlarıdır.

3. URL Yapısını Uyumlu Hale Getirin

❌ KÖTÜ:
/p?id=123
/sayfa/12345/

✅ İYİ:
/kategori/alt-kategori/sayfa-adi
/blog/seo/teknik-seo-rehberi

4. Navigation Menüsünü Optimize Edin

html

<!-- Temiz, semantik navigation -->
<nav role="navigation" aria-label="Ana Menü">
  <ul>
    <li><a href="/">Ana Sayfa</a></li>
    <li>
      <a href="/hizmetler">Hizmetler</a>
      <ul>
        <li><a href="/hizmetler/seo">SEO</a></li>
        <li><a href="/hizmetler/web-tasarim">Web Tasarım</a></li>
        <li><a href="/hizmetler/sosyal-medya">Sosyal Medya</a></li>
      </ul>
    </li>
    <li><a href="/blog">Blog</a></li>
    <li><a href="/hakkimizda">Hakkımızda</a></li>
    <li><a href="/iletisim">İletişim</a></li>
  </ul>
</nav>

5. Internal Linking Programı Oluşturun

Sistemik Yaklaşım:

Haftalık:
- Yeni içerik yayınlarken 2-3 ilgili eski içeriğe link verin
- Eski içeriklere yeni içerikten link ekleyin

Aylık:
- En çok trafik alan sayfaları inceleyin
- Bu sayfalardan önemli ama az trafik alan sayfalara link ekleyin
- Orphan sayfaları bulun ve link ekleyin

Çeyreklik:
- Full site audit yapın
- Internal link dağılımını analiz edin
- Önemli sayfaların link sayısını kontrol edin

6. Footer ve Sidebar Linklerini Stratejik Kullanın

html

<!-- Footer - Önemli sayfalara site-wide linkler -->
<footer>
  <div class="footer-links">
    <div>
      <h4>Ürünler</h4>
      <ul>
        <li><a href="/urunler/kategori-1">Kategori 1</a></li>
        <li><a href="/urunler/kategori-2">Kategori 2</a></li>
      </ul>
    </div>
    <div>
      <h4>Şirket</h4>
      <ul>
        <li><a href="/hakkimizda">Hakkımızda</a></li>
        <li><a href="/kariyer">Kariyer</a></li>
        <li><a href="/basin">Basın</a></li>
      </ul>
    </div>
    <div>
      <h4>Destek</h4>
      <ul>
        <li><a href="/sss">SSS</a></li>
        <li><a href="/iletisim">İletişim</a></li>
        <li><a href="/yardim">Yardım Merkezi</a></li>
      </ul>
    </div>
  </div>
</footer>

7. Breadcrumb Ekleyin

Tüm içerik sayfalarına breadcrumb navigation ekleyin (yukarıdaki kod örneklerine bakın).

Faceted Navigation (Filtrelenmiş Navigasyon)

E-ticaret siteleri için kritik bir konu. Faceted navigation, kullanıcıların ürünleri filtrelemesine olanak tanır (marka, fiyat, renk, beden vs.). Hangi filtrelerin indekslenmeye değer olduğuna karar verirken trafik değil gelir verisine bakın; e-ticaret KPI’ları bu önceliklendirmenin çerçevesini verir.

Faceted Navigation Sorunu:

Her filtre kombinasyonu yeni bir URL oluşturur:

/telefonlar
/telefonlar?marka=apple
/telefonlar?marka=apple&renk=siyah
/telefonlar?marka=apple&renk=siyah&hafiza=256gb
/telefonlar?renk=siyah&marka=apple  (duplicate!)

Sonuç: Binlerce duplicate URL!

Faceted Navigation Çözümleri:

1. Canonical Tag Kullanımı (En Yaygın)

html

<!-- Filtrelenmiş URL: /telefonlar?marka=apple&renk=siyah -->
<link rel="canonical" href="https://example.com/telefonlar" />

<!-- Tüm filtre kombinasyonları ana kategori sayfasına işaret eder -->

2. Noindex Kullanımı

html

<!-- Filtrelenmiş sayfalar için -->
<meta name="robots" content="noindex, follow">

<!-- Follow: Linkleri takip et, ama sayfayı indeksleme -->

3. Robots.txt ile Engelleme

User-agent: *
Disallow: /*?marka=
Disallow: /*?renk=
Disallow: /*?fiyat=
Allow: /

4. Stratejik İndeksleme

Bazı filtre kombinasyonlarını indeksleyin:

✅ İNDEKSLE:
/telefonlar
/telefonlar/apple  (popüler marka)
/telefonlar/samsung  (popüler marka)

❌ İNDEKSLEME:
/telefonlar?marka=apple&renk=siyah&hafiza=256gb
/telefonlar?sort=price-low

URL Parametresi Yönetimi:

Önemli: Search Console’un URL Parameters aracı 26 Nisan 2022’de kapatıldı. Google, parametreleri artık otomatik yorumluyor. Yani parametre davranışını Google’a elle bildiremezsiniz; kontrol tamamen sizin sayfanızdadır.

Bugünkü doğru parametre yönetimi üç katmandan oluşur:

• Canonical: Her parametreli varyant, filtresiz ana kategoriyi işaret etsin.
• robots.txt: Sonsuz kombinasyon üreten sıralama / filtre pattern’lerini tarama dışı bırakın.
• İç link disiplini: Parametreli URL’lere sitenizin içinden link vermeyin — verdiğiniz her link Google için “bu önemli” sinyalidir.

Kampanya parametrelerini (UTM) elle yazmak yerine URL oluşturucu ile üretmek, yanlış yazımdan doğan gereksiz varyantları da engeller.

Pagination (Sayfalama)

Kategori listeleri, blog arşivleri ve arama sonuçları birden fazla sayfaya bölünür. Bu yapı yanlış kurulduğunda derin sayfalardaki ürünler hiç taranmaz.

Önce ölü bir kuralı gömelim: rel="next" ve rel="prev" etiketlerini Google 2019’da desteklemeyi bıraktığını açıkladı — hem de yıllardır kullanmadığını söyleyerek. Bu etiketleri eklemek zarar vermez ama Google için hiçbir şey yapmaz. Hâlâ öneren kaynaklara güvenmeyin.

Bugün işe yarayan üç şey:

1. Gerçek <a href> linkleri. Sayfa numaraları JavaScript ile üretiliyorsa (onclick, button) Googlebot 2. sayfayı bulamaz. Sayfalama linkleri ham HTML’de, gerçek bağlantı olarak durmalı.
2. Her sayfa kendi kendine canonical versin. En sık yapılan hata, 2., 3., 4. sayfaları 1. sayfaya canonical göstermektir. Bunu yaparsanız Google o sayfalardaki ürünleri “kopya” sayar ve taramayı keser — derin sayfalardaki içerik indekse hiç girmez.
3. Benzersiz title ve meta description. “Spor Ayakkabı — Sayfa 2” gibi. Aynı başlığı 40 sayfada tekrar etmek duplicate sinyali üretir.

Sayfalanmış URL’ler sitemap’e girmeli mi? Hayır. Sitemap “indekslenmesini istediğim sayfalar” listesidir; 2. sayfa genellikle o listeye ait değildir. Ama taranabilir olmalıdır — ikisi farklı şeydir. Sayfalamayı robots.txt ile engellemek, derin ürünlerinizi keşfedilemez yapar.

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

Sitenizin Türkçe ve İngilizce versiyonu varsa ya da Türkiye ile Almanya’daki kullanıcılara farklı sayfalar sunuyorsanız, Google’ın hangi kullanıcıya hangi versiyonu göstereceğini bilmesi gerekir. hreflang bunu söyler.

Hreflang bir sıralama faktörü değildir. Sayfalarınızı yukarı taşımaz; doğru kullanıcıya doğru versiyonu eşleştirir ve dil versiyonlarının birbirini duplicate olarak yemesini önler.

Temel kurulum — her sayfanın <head>’ine, tüm versiyonları listeleyin:

<link rel="alternate" hreflang="tr" href="https://alanadi.com/urun" />
<link rel="alternate" hreflang="en" href="https://alanadi.com/en/product" />
<link rel="alternate" hreflang="de-DE" href="https://alanadi.com/de/produkt" />
<link rel="alternate" hreflang="x-default" href="https://alanadi.com/" />

En sık yapılan dört hata:

1. Karşılıklılık eksikliği. A sayfası B’yi gösteriyorsa, B de A’yı göstermek zorundadır. Tek yönlü hreflang tamamen yok sayılır.
2. Kendini listelememek. Her sayfa, kendi dil versiyonunu da (self-referencing) listelemelidir.
3. Yanlış kodlar. Dil kodu ISO 639-1, bölge kodu ISO 3166-1 Alpha-2’dir. Birleşik Krallık en-GB’dir, en-UK diye bir kod yoktur. Türkçe tr’dir; tr-TR yalnızca Türkiye’deki Türkçe konuşurları hedefliyorsanız doğrudur.
4. Canonical ile çelişmek. İngilizce sayfanın canonical’ı Türkçe sayfayı gösteriyorsa hreflang çalışmaz. Her dil versiyonu kendi kendine canonical vermelidir.

x-default, hiçbir dil eşleşmediğinde gösterilecek sayfadır — genellikle dil seçim ekranı veya ana versiyon. Doğrulama için Search Console → Uluslararası Hedefleme raporunu ve hreflang test araçlarını kullanın; karşılıklılık hatalarını en hızlı orada görürsünüz.

Site Mimarisi Kontrol Listesi

Yapı ve Hiyerarşi:

• Site hiyerarşisi mantıksal ve sığ (3-4 seviye max)
• Her kategori net ve birbirinden ayrı
• URL yapısı hiyerarşiyi yansıtıyor
• Önemli sayfalar 3 tıklamadan erişilebilir

Internal Linking:

• Her sayfaya en az bir internal link var
• Orphan sayfalar tespit edildi ve düzeltildi
• Contextual linkler kullanılıyor
• Anchor text’ler tanımlayıcı
• İlgili içerikler birbirine bağlı
• Hub and spoke veya pillar-cluster model uygulandı

Navigation:

• Temiz, semantik navigation menüsü
• Breadcrumb tüm sayfalarda mevcut
• Footer’da önemli sayfalara linkler
• Mobile navigation optimize edilmiş

E-Ticaret Özel:

• Faceted navigation duplicate problemi çözüldü
• Filtre sayfaları canonical veya noindex
• Parametreli URL’ler canonical + robots.txt ile yönetiliyor (GSC’nin URL Parameters aracı 2022’de kapandı)
• Popüler filtreler ayrı sayfa olarak indekslendi

Monitoring:

• Aylık site audit yapılıyor
• Orphan sayfalar düzenli kontrol ediliyor
• Internal link dağılımı analiz ediliyor
• Tıklama derinliği izleniyor

Önemli Hatırlatmalar:

• Site mimarisi bir kez kurulup unutulan bir şey değildir
• Site büyüdükçe revize edilmelidir
• İyi bir yapı hem kullanıcılar hem botlar için faydalıdır
• Internal linking, SEO’nun en az kullanılan ama en etkili taktiklerinden biridir
• Orphan sayfalar potansiyel trafiğin israfıdır

4. XML Sitemap ve Index Yönetimi

Site mimarisi, Google’a sitenizin mantığını anlatır.

XML Sitemap ise Google’a “hangi sayfalarım gerçekten önemli ve indekslenmeli?” sorusunun cevabını verir.

Bu iki yapı birlikte çalışmadığında şu sorunlar ortaya çıkar:

• Önemsiz sayfalar indekslenir
• Önemli sayfalar geç veya hiç indekslenmez
• Crawl budget boşa harcanır
• Index bloat (şişkin indeks) oluşur

Bu yüzden XML Sitemap ve index yönetimi, teknik SEO’nun kontrol merkezi olarak düşünülmelidir.

XML Sitemap Nedir?

XML Sitemap, arama motorlarına sitenizdeki indekslenmesini istediğiniz URL’leri bildiren bir dosyadır.

Basit ama kritik bir kural:

XML Sitemap = “İndekslenmesini İSTEDİĞİM sayfalar”

Sitemap:

• Crawling’i kolaylaştırır
• Yeni sayfaların daha hızlı keşfedilmesini sağlar
• Google’a öncelik sinyali verir Ama tek başına indeks garantisi değildir.

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

Crawling Verimliliği

Özellikle:

• Büyük sitelerde
• Derin mimarilerde
• Yeni veya az link alan sayfalarda

Googlebot sitemap sayesinde:

• Hangi URL’lerin önemli olduğunu bilir
• Boş yere filtre, parametre, arşiv sayfalarında dolaşmaz

Indexing Kontrolü

Sitemap, Google’a şu mesajı verir:

• “Bu URL canonical”
• “Bu URL canlı ve güncel”
• “Bu URL indekslenmeye aday”

Eğer sitemap’te olup indekslenmeyen sayfalar varsa:

Bu, içerik, kalite veya teknik problem sinyalidir.

Index Bloat’ın Önlenmesi

Index bloat, Google’ın: gereksiz, düşük kaliteli, SEO değeri olmayan sayfaları indekslemesidir.

Sonuçları:

Crawl budget israfı
Otorite dağılması
Önemli sayfaların geç taranması
Genel ranking performansının düşmesi

Yanlış yapılandırılmış sitelerde Google:

• Arama sonuç sayfalarını
• Filtre URL’lerini
• Parametreli sayfaları
• Zayıf içerikleri indeksleyebilir.

Doğru sitemap stratejisi:

• Gereksiz URL’leri dışarıda bırakır
• Google’ın indeksini “temiz” tutar

XML Sitemap Best Practices (Altın Kurallar)

✅ Sitemap’e GİRMESİ GEREKEN Sayfalar

• 200 status code dönen
• Canonical olan
• Noindex olmayan
• Gerçek trafik ve SEO değeri olan sayfalar
• Kategori, ürün, içerik, hizmet sayfaları

❌ Sitemap’e GİRMEMESİ GEREKEN Sayfalar

• Noindex olan URL’ler
• Redirect (301/302) URL’ler
• 404 / 410 sayfalar
• Filtreli ve parametreli URL’ler
• Arama sonuç sayfaları
• Teşekkür / login / sepet sayfaları

Altın kural: Sitemap’teki her URL = “Google’da görmek istediğim URL”

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).

5. 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?

• Nedir: Sayfada zaten görünen bilginin JSON-LD (veya Microdata) ile etiketlenmesi. Yazar bilgisini işaretlerken author.url alanının gerçek bir yazar sayfasına gitmesi, E-E-A-T açısından boş bir isim alanından çok daha değerlidir.
• Değildir: Görünmeyen 5 yıldız, sahte stok, sayfada olmayan SSS.
• Google’ın tercihi: Çoğu sitede JSON-LD. HTML’den ayrı durur, şablonla üretilmesi kolaydır.

Kritik kural: Markup, ekranda görünenle birebir aynı olsun. Schema JS ile sonradan basılacaksa, ilk HTML’de de durduğundan emin olun — bir sonraki bölüm bunun nedenini anlatıyor.

Schema’nın Yapay Zeka Tarafı

Schema uzun süre “rich result üretir mi, üretmez mi” çerçevesinde konuşuldu. 2026’da ikinci bir işlevi var: sayfadaki varlıkları dil modelleri için de netleştiriyor.

Bir model sayfanızı okurken şunu çözmeye çalışır: bu metni kim yazdı, ne zaman güncellendi, hangi ürünün fiyatı, hangi sorunun cevabı. Bu bilgiler düz metnin içinde dağınık durduğunda modelin çıkarım yapması gerekir — ve çıkarım hata payı demektir. JSON-LD ise aynı bilgiyi belirsizliğe yer bırakmadan verir.

Netleştirelim: schema bir sıralama ya da alıntılanma garantisi değildir. Google, llms.txt için söylediğine benzer şekilde schema’yı da yapay zeka görünürlüğü için bir kaldıraç olarak sunmuyor. Ama author, datePublished, dateModified ve Organization alanlarını doğru doldurmak, 6. bölümde anlatılan varlık netliği işini zaten yapmış olur. Yani yapmanız gereken bir şeyin ikinci bir faydası var.

Pratik sonuç bölüm başındaki kuralı güçlendiriyor: schema’yı ilk HTML yanıtına koyun. JS ile enjekte edilen JSON-LD’yi Google ikinci dalgada görebilir; yapay zeka tarayıcıları hiç göremez.

Hangi sayfada hangi tür?

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.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Kapsamlı Teknik SEO Rehberi",
  "datePublished": "2025-12-25",
  "dateModified": "2026-09-19",
  "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://metehanyilmaz.com.tr/cdn/shop/articles/teknik-seo-rehberi.jpg",
  "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": "Kapsamlı Teknik SEO Rehberi", "item": "https://metehanyilmaz.com.tr/blogs/rehber/teknik-seo-rehberi" }
  ]
}
</script>

Doğrulama ve sık hatalar

• Google Rich Results Test + Search Console → Zengin sonuçlar raporu.
• Çift escape / bozuk JSON: tek geçersiz virgül tüm bloğu düşürür.
• Aynı sayfada çelişen iki Article (eklenti + tema).
• FAQPage’i her blog yazısına basmak — spam sinyali.
• Markup’ı HTML’in en altına, 2 MB sınırına yakın gömmek.

Hızlı kontrol: Sayfayı kaydet → Rich Results Test → “Geçerli öğeler” gör. GSC’de uyarı gelirse aynı gün düzelt, “Düzeltmeyi doğrula”ya bas.

6. JavaScript SEO, Render ve Yapay Zeka Tarayıcıları

Modern sitelerin çoğu JavaScript kullanır. Google JS’i işleyebilir; bu her zaman sorunsuz demek değildir. 2026’da ikinci bir katman var: yapay zeka tarayıcıları (AI crawler’lar) sayfayı Google gibi render etmez. Bu bölüm önce Google’ın nasıl işlediğini, sonra yapay zeka motorlarında görünür ve alıntılanabilir olmanın ne gerektirdiğini anlatıyor.

Google nasıl işler?

Google’ın sayfa işleme süreci iki aşamalıdır:

1. HTML crawling — ilk tarama, ham kaynak.
2. Rendering — JS çalıştıktan sonraki DOM. Ayrı kuyruk, gecikmeli olabilir.

Kritik içerik ve linkler yalnız JS ile üretiliyorsa Google bu içeriği geç indeksleyebilir, yanlış anlayabilir veya hiç görmeyebilir.

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 hem render öncesi hem sonrası okunur. Script ile HTML’dekinden farklı canonical yazmak çelişki üretir.
• GSC URL Inspection’da taranan HTML ile rendered çıktıyı yan yana bakın.

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

React, Vue veya benzeri bir framework ile kurulmuş tek sayfa uygulamalarında (SPA) ölçümün kör bir noktası vardır: Core Web Vitals yalnızca ilk sayfa yüklemesinde ölçülür.

Kullanıcı sitenize girer (LCP ölçülür), sonra beş sayfa gezer — bu geçişlerin hiçbiri ölçülmez, çünkü tarayıcı açısından yeni bir sayfa yükleme yaşanmamıştır. Sonuç: Search Console’daki CWV skorlarınız yeşil görünürken kullanıcılarınız yavaş bir site deneyimliyor olabilir.

Pratik sonuçları:

• Sayfa içi geçişler ne kadar yavaş olursa olsun raporlarınızı bozmaz — bu, sorunu görmezden gelmek için bir sebep değil, ölçümünüze güvenmemek için bir sebeptir.
• INP bir istisnadır: sayfa ömrü boyunca tüm etkileşimleri ölçer. SPA’da kötü INP, en görünür CWV sorunudur.
• Google “soft navigation” ölçümü üzerinde çalışıyor; bugün deneysel durumda. Buna bel bağlamayın.

Ne yapmalı: Sayfa geçişlerini web-vitals kütüphanesiyle kendiniz ölçüp analitiğinize gönderin. Ayrıca her rota için gerçek bir URL ve sunucudan dönen ham HTML olduğundan emin olun — SSR veya statik üretim, hem bu ölçüm sorununu hem de bir sonraki başlıkta anlatılan AI crawler sorununu aynı anda çözer.

AI crawler’lar Googlebot değildir

GPTBot, ClaudeBot, PerplexityBot ve benzeri tarayıcılar pratikte JavaScript çalıştırmaz. Ham HTML neyse onu okuyup geçerler. İkinci bir render kuyruğu yoktur.

AI Overviews ve benzeri yüzeylerde geçmek isteyen sayfa: özet paragraf, net H2’ler, fiyat / SSS / yazar bilgisi ve schema kaynak kodda durmalı. “Sayfa tarayıcıda doluyor” yetmez.

Hangi Yapay Zeka Botu Ne Yapar?

“AI crawler” tek bir şey değil. Aynı şirketin farklı işler yapan birkaç botu var ve bunları ayırt etmemek en pahalı hatadır. Örneğin GPTBot’u engelleyip “ChatGPT’ye kapattım” sanmak yanlıştır: o yalnızca model eğitimini kapatır, ChatGPT’nin arama tarafı başka bir botla çalışır.

Bingbot’u küçümsemeyin. ChatGPT’nin arama tarafı Microsoft ortaklığı üzerinden Bing verisinden besleniyor. Yani Bing’de indekslenmemek, ChatGPT’de görünürlüğü de zayıflatır. Türkiye’de Bing’i “kimse kullanmıyor” diye geçmek, 2026’da yapay zeka görünürlüğünü göz ardı etmek anlamına geliyor.

Bir uyarı: bu botların hiçbiri JavaScript çalıştırmıyor. OpenAI tarayıcılarının düz HTML okuduğu bağımsız testlerle de doğrulandı. Üstteki tablo ne derse desin, CSR-only bir sayfada hepsi aynı şeyi görür: boş iskelet.

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

Buraya kadar olan her şey botun sayfanızı okuyabilmesiyle ilgiliydi. Okunmak gerekli şart ama yeterli değil: yapay zeka cevaplarında kaynak olarak gösterilmek ayrı bir iş.

Aradaki farkı şöyle düşünün: klasik SEO’da hedef, kullanıcının tıklayacağı bir sonuç olmaktır. Yapay zeka cevaplarında ise model sayfanızdan bir parçayı alıp cevabın içine koyar ve altına kaynak verir. Yani optimize ettiğiniz birim artık sayfa değil, paragraf.

1. Her pasaj kendi başına ayakta dursun

Model, sayfanızı baştan sona okuyup özetlemez; ilgili parçayı çeker. “Yukarıda bahsettiğimiz gibi” ya da “bu yöntem” diye başlayan bir paragraf, bağlamından koparıldığında anlamsızlaşır ve alıntılanmaz. Kritik paragraflarda özneyi tekrar edin:

❌ "Bu limit aşıldığında içerik kesilir."
✅ "Googlebot 2 MB'lık indirme limitini aştığında sayfanın
   geri kalanı kesilir ve indekslenmez."

2. Cevabı başlığın hemen altına koyun

Bir H2 soru soruyorsa, cevap ilk cümlede olmalı — üç paragraf giriş yaptıktan sonra değil. Bu, hem yapay zekanın doğru parçayı bulmasını kolaylaştırır hem de okuru memnun eder. Klasik gazetecilikteki ters piramit mantığı.

3. Sayı verin, kaynak gösterin

Modeller iddia yerine doğrulanabilir veriyi alıntılamaya eğilimli. “Sayfa hızı önemlidir” alıntılanmaz; “LCP 2,5 saniyenin altında olmalı (Google, Core Web Vitals eşiği)” alıntılanır. Bu rehberin istatistiklere kaynak ve tarih eklemesinin sebebi de bu.

4. Varlıkları netleştirin

Model, sayfanın kim tarafından, ne hakkında yazıldığını anlamak ister. Yazar adı, kurum, tarih ve konu; hem görünür metinde hem schema’da net durmalı. “Uzmanımıza göre” değil, adı soyadı ve bağlantılı bir yazar sayfası.

5. Tablo ve listeleri gerçek HTML ile kurun

Karşılaştırma tablosu, adım listesi ve tanım kutuları, modelin yapıyı çözmesini kolaylaştırır. Ama gerçek <table>, <ul>, <dl> etiketleriyle — görsele gömülmüş bir tablo, yapay zeka için yok hükmündedir. Aynı şey ekran görüntüsüne alınmış kod için de geçerli.

6. Güncelliği görünür kılın

Yapay zeka yüzeyleri taze içeriği tercih ediyor. Görünür bir “son güncelleme” tarihi ve schema’daki dateModified tutarlı olsun. Tarihi değiştirip içeriği değiştirmemek ise ters teper.

Ölçemediğiniz şeyi yönetemezsiniz. Bu alanda henüz Search Console benzeri resmî bir rapor yok. Pratik yöntem: sunucu loglarınızda OAI-SearchBot, PerplexityBot ve ClaudeBot isabetlerini izlemek, ayrıca markanızla ilgili tipik soruları düzenli aralıklarla ChatGPT ve Perplexity’ye sorup kaynak gösterilip gösterilmediğinize bakmak. Kaba ama şu an elimizdeki en dürüst ölçüm.

Son bir uyarı. Bu maddelerin hiçbiri sihirli değil; iyi yapılandırılmış, doğrulanabilir ve gerçekten bilgi veren içeriğin tarif edilmiş hâli. “Yapay zeka için ayrı içerik” yazmaya çalışanlar genelde ikisini de kaybediyor.

robots.txt ve AI botları

Karar sizin. Eğitim verisine kapatmak ile cevap motorlarında görünmek ayrı tercihler. Dogma yok; bilinçli seçin.

İzin vermek:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Kapatmak:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Google-Extended Gemini / model eğitimi tarafıdır; Googlebot tarama ve Search indeksini kapatmaz. Googlebot’u Disallow etmek ayrı ve çok daha ağır bir karardır.

Yaygın hata: Yukarıdaki “kapatmak” bloğu yalnızca eğitimi kapatır. ChatGPT aramasında görünmeye devam edersiniz, çünkü o OAI-SearchBot ile çalışır. Çoğu site sahibinin istediği de tam olarak budur: eğitim verisi olma, ama cevaplarda kaynak göster. Bunun karşılığı:

# Eğitime kapalı, cevap motorlarında görünür
User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

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

robots.txt bir botu ya içeri alır ya almaz; “gir ama şu amaçla kullanma” diyemez. Cloudflare’in 2025’te başlattığı Content Signals politikası bu boşluğu doldurmayı hedefliyor ve içeriğin erişildikten sonra nasıl kullanılabileceğini üç sinyalle ayırıyor:

• search — arama indeksine gir, sonuçlarda göster
• ai-input — yapay zeka cevaplarına canlı girdi olarak kullan
• ai-train — model eğitiminde kullan

# Cloudflare'in yaygın varsayılanı:
# aramaya açık, eğitime kapalı, AI cevaplarında nötr
User-agent: *
Content-Signal: search=yes, ai-train=no

Cloudflare bunu yönetimindeki milyonlarca alan adına varsayılan olarak dağıttı. Sitenizde Cloudflare varsa, robots.txt’inizde sizin yazmadığınız satırlar olabilir — bir kontrol edin.

Ama asıl nokta şu: robots.txt ve Content Signals birer tercih beyanıdır, teknik engel değil. Uymayan bot uymaz. Gerçekten engellemek istiyorsanız iş CDN veya WAF katmanına düşer — Cloudflare tarafında bot yönetimi kuralları, sunucu tarafında user-agent bazlı engelleme. Yani “robots.txt’e yazdım, artık alamazlar” doğru bir cümle değil.

llms.txt

Bazı siteler kökte llms.txt yayınlar. Google Search Central’e göre bu tür AI metin / markdown dosyaları Search sıralamasına özel yardım da zarar da etmez; Search (AI Overviews / AI Mode dahil) bunları ranking sinyali olarak kullanmaz. Başka ajanlar için tutmak isteğe bağlıdır. “llms.txt ekledim, AI’da 1. oldum” iddiası teknik SEO değildir.

Hızlı kontrol

• view-source: → H1, ana metin, iç linkler, schema var mı?
• GSC → URL Inspection → Taranan sayfa
• JS’i kapatıp (tarayıcı) sayfaya bakın: iskelet ayakta mı?
• curl -A "GPTBot" URL → botun gördüğü HTML’de içerik var mı?

7. Log Analizi ve Crawl Budget (ileri seviye)

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

Filtre URL’leri yoğun crawl alıyorsa, eski veya noindex sayfalar taranıyorsa, para kazandıran URL’ler nadir görünüyorsa:

• robots.txt ile gereksiz pattern’i yönlendirin (1. bölümdeki e-ticaret örneği)
• Canonical + noindex stratejisini sıkılaştırın
• Sitemap’i sadeleştirin
• Redirect zinciri ve 404’ü temizleyin
• Sunucu yanıt süresini düşürün — yavaş site daha az taranır

8. Teknik SEO Audit Checklist

Özet

• Crawl ve hız olmadan içerik görünmez. Bu rehberin 1–4. bölümü temeldir.
• Schema, sayfada duranı etiketler — icat etmez.
• JavaScript SEO yanlış yapılırsa görünmezlik yaratır; AI botlarında bu risk daha keskin.
• llms.txt Google sıralama faktörü değildir.
• Yapay zeka tarayıcıları JavaScript çalıştırmaz. Ham HTML’de olmayan içerik onlar için yoktur.
• GPTBot’u engellemek eğitimi kapatır, ChatGPT aramasını değil — o OAI-SearchBot’tur. İkisini bilerek ayırın.
• Alıntılanmak için optimize edilen birim sayfa değil paragraftır: bağlamsız okunabilen, sayı ve kaynak içeren pasajlar.
• Canonical bir emir değil ipucudur; Google onu iç linkleriniz ve sitemap’iniz destekliyorsa dinler.
• Sayfalama ve hreflang’de en sık yapılan hata çelişkili sinyal vermektir — 2. sayfayı 1’e canonical göstermek gibi.
• Log analizi sorun büyükse oyunu değiştirir; küçük sitede şart değildir.