Web sitenizin Google’da nerede göründüğü, büyük ölçüde tasarım ve geliştirme aşamasında alınan kararlarla şekillenir. Güzel görünen ama SEO açısından sorunlu bir site, trafik çekmekte ve dönüşüm sağlamakta zorlanır. SEO uyumlu web tasarım ise kullanıcı deneyimi ve arama motoru sinyallerini birlikte optimize eden bütüncül bir yaklaşımdır — ve bu iki hedef genellikle çatışmaz, aksine birbirini besler: hızlı yüklenen, net bir hiyerarşiye sahip, kolay gezinilebilen bir site hem kullanıcıyı hem arama motorunu memnun eder.
Bu kapsamlı rehberde SEO’yu doğrudan etkileyen teknik tasarım kararlarını, Core Web Vitals optimizasyonunu, URL mimarisini, schema markup stratejisini, erişilebilirlik ile SEO’nun kesişimini, yapay zeka tarayıcılarının etkisini ve sık yapılan hataları ayrıntılı biçimde ele alıyoruz.
Tasarım ve SEO tarafını tek elden, koordineli biçimde yürütmenin ne anlama geldiğini SEO uzmanı olarak çalışma biçimimde bulabilirsiniz.
SEO ve Tasarımın Kesişimi
SEO uzmanı ile web tasarımcısı/geliştiricisi geleneksel olarak ayrı çalışmıştır. Ancak Google’ın algoritmalarının gelişmesiyle bu iki alan artık birbirinden bağımsız yürütülemez. Tasarım aşamasında düzeltilmemiş SEO sorunu, yayına alındıktan sonra çözülmesi çok daha maliyetli hale gelir.
Bu maliyet farkı somut biçimde şöyle özetlenebilir: tasarım aşamasında bir URL yapısını doğru kurmak, geliştiricinin birkaç saatlik ek planlamasıdır. Aynı düzeltmeyi site yayındayken yapmak ise 301 yönlendirme haritası çıkarmayı, mevcut backlink değerinin bir kısmını kaybetme riskini ve haftalarca sürebilecek bir geçiş dönemini gerektirir. Bu yüzden SEO’yu tasarım sürecinin sonunda değil, en başında bir girdi olarak ele almak, uzun vadede en ucuz yaklaşımdır.
Tasarımın Doğrudan Etkilediği SEO Faktörleri
| Tasarım Kararı | SEO Etkisi | Ağırlığı |
|---|---|---|
| Sayfa hızı (Core Web Vitals) | Doğrudan sıralama faktörü | Kritik |
| Mobil uyumluluk | Mobile-first indexing | Kritik |
| URL yapısı | Alaka sinyali + taranabilirlik | Yüksek |
| Başlık hiyerarşisi (H1-H6) | İçerik yapısı sinyali | Yüksek |
| Görsel optimizasyonu | Hız + görsel SEO | Yüksek |
| Navigasyon ve iç bağlantı | Otorite dağıtımı + tarama | Yüksek |
| Schema markup | Zengin sonuç + anlam | Orta-Yüksek |
| JavaScript kullanımı | İndekslenebilirlik | Orta-Yüksek |
| Canonical yapısı | Duplicate content önleme | Orta |
| Erişilebilirlik (a11y) | Kullanıcı deneyimi sinyali | Orta |
Core Web Vitals: Tasarımcının Rehberi
Güncel Core Web Vitals (INP, FID’in yerini aldı)
| Metrik | Açıklaması | İyi | İyileştir | Zayıf | Ölçüm Aracı |
|---|---|---|---|---|---|
| LCP | En büyük içeriğin yüklenmesi | 2.5 sn ve altı | 2.5–4.0 sn | 4.0 sn üstü | PageSpeed, CrUX |
| INP | Etkileşime yanıt süresi | 200 ms ve altı | 200–500 ms | 500 ms üstü | PageSpeed, CrUX |
| CLS | Beklenmedik yerleşim değişikliği | 0.1 ve altı | 0.1–0.25 | 0.25 üstü | PageSpeed, CrUX |
Dikkat: Google, CrUX (Chrome User Experience Report) verilerini kullanır. Bu gerçek kullanıcı verileridir; lab ortamı ölçümleri (Lighthouse gibi kontrollü test ortamlarında yapılan ölçümler) farklılık gösterebilir. Lab verisi geliştirme sürecinde hızlı geri bildirim için değerlidir, ama sıralama kararında belirleyici olan her zaman gerçek kullanıcı verisidir — bu yüzden PageSpeed Insights raporundaki “Alan Verisi” (Field Data) bölümüne, “Lab Verisi” bölümünden daha fazla ağırlık vermek gerekir.
LCP: Neyi Etkiler, Nasıl Optimizasyon Yapılır?
LCP, sayfanın “kullanıcı için yüklendi” hissini belirleyen en kritik metriktir; kullanıcının sayfayı terk edip etmeyeceğine dair kararının büyük ölçüde bu ilk birkaç saniyede şekillendiğini gösteren çok sayıda araştırma mevcuttur.
LCP genellikle neyi ölçer?
| İçerik Türü | LCP Olma Sıklığı | Optimizasyon Önceliği |
|---|---|---|
| Hero görsel (img, background-image) | %70–80 | En yüksek |
| H1 metin bloğu | %15–20 | Yüksek |
| Video thumbnail | %5–10 | Orta |
| SVG veya diğer | %1–5 | Duruma göre |
Hero görsel optimizasyon adımları:
- Format: WebP (JPEG’den %25–35 daha küçük) veya AVIF (WebP’den %20 daha küçük)
- Boyut: Cihaz genişliğine göre
srcsetile responsive görseller - Boyut talimatı:
widthveheightattribute’u mutlaka ekle (CLS’yi de önler) - Preload:
<link rel="preload" as="image" href="hero.webp" fetchpriority="high"> - Lazy loading YAPMA: Hero görseline
loading="lazy"ekleme; yüklemeyi geciktirir
INP Optimizasyonu: JavaScript ve Etkileşim
INP (2024’te FID’in yerini aldı), kullanıcının tıklama/dokunma gibi etkileşimlerine verilen yanıt süresini ölçer.
| INP Sorunu | Yaygın Neden | Çözüm |
|---|---|---|
| Uzun görev (long task) | Ağır JS kod bloğu | Code splitting, web workers |
| Render blocking script | 3. taraf script | Defer, async, lazy load |
| Ağır event handler | Tıklamada hesaplama | İşlemi async’e taşı |
| Senkron XHR | Eski API çağrıları | Async/await fetch |
| CSS animasyon | GPU desteklenmeyen CSS | transform/opacity kullan |
CLS: Yerleşim Kararlılığı
CLS, kullanıcı okurken öğelerin beklenmedik şekilde yerini değiştirmesini ölçer — özellikle mobilde, parmakla dokunulacak bir düğmenin son anda kayması can sıkıcı ve hatalı tıklamalara yol açabilir.
En sık CLS nedenleri ve çözümleri:
| CLS Nedeni | Nasıl Oluşur | Çözüm | Etki |
|---|---|---|---|
| Boyutsuz görseller | Görsel yüklenince alan değişir | width + height attribute | Kritik |
| Geç yüklenen reklam bloğu | Reklam gelince sayfayı iter | Placeholder div rezerve et | Yüksek |
| Web font FOUT | Font yüklenince metin boyutu değişir | font-display: optional veya swap | Orta |
| Dinamik içerik (banner, bildirim) | JS ile üstten içerik enjekte | İçeriği alta yerleştir | Yüksek |
| CSS animasyonu (top/left) | Position değişimi | transform: translateY() kullan | Orta |
| Embed (YouTube, sosyal) | Iframe boyutu belirsiz | aspect-ratio CSS | Orta |
Mobil-First Tasarım: Teknik Gereksinimler
Google mobile-first indexing kullanır; mobil sürüm indeksleme ve sıralama için referans alınır — masaüstü sürümünüz mükemmel olsa bile, mobil sürümdeki eksiklikler doğrudan sıralamayı etkiler.
Mobil SEO Kontrol Listesi
| Kontrol | Standart | Test Aracı |
|---|---|---|
| Viewport meta etiketi | <meta name="viewport" content="width=device-width, initial-scale=1"> | Manuel |
| Metin okunabilirliği | 16px minimum font | Chrome DevTools |
| Dokunma hedefi boyutu | Min. 44x44 px (Apple) veya 48x48 dp (Google) | Lighthouse |
| Yatay kaydırma | Yok olmalı | Chrome DevTools |
| Mobil hız | LCP 2.5 sn altı ayrıca mobil için | PageSpeed Insights |
| Interstitial (popup) | Ekranın büyük bölümünü kaplamamalı | Manuel |
| Görüntü boyutu | Ekran genişliğini aşmamalı | Lighthouse |
| Responsive görseller | srcset veya picture elementi | Chrome DevTools |
URL Yapısı: Doğru Mimari
İdeal URL Tasarımı
| Kural | Doğru | Yanlış | Neden |
|---|---|---|---|
| Karakter seti | Yalnızca a-z, 0-9, tire (-) | Türkçe karakter (ş, ğ, ü) | Encoding sorunları |
| Kelime ayırıcı | Tire (-) | Alt çizgi (_) | Google tireyi ayırıcı olarak okur |
| Harf | Küçük harf | Büyük harf | Duplicate URL riski |
| Uzunluk | 3–5 kelime | 10+ kelime | Kullanıcı deneyimi |
| Dinamik parametre | Gerekiyorsa canonical | Filtresiz bırakma | Duplicate content |
| Trailing slash | Tutarlı (her zaman var veya yok) | Karışık kullanım | Duplicate URL |
URL hiyerarşisi örneği:
siteniz.com/ → Ana sayfa
siteniz.com/hizmetler/ → Hizmetler
siteniz.com/hizmetler/web-tasarim/ → Web tasarım
siteniz.com/blog/ → Blog
siteniz.com/blog/seo-nedir/ → Makale
Başlık Hiyerarşisi (Heading Structure)
Doğru Heading Kullanımı
| Etiket | Kullanım | Anahtar Kelime | Sayfa Başına |
|---|---|---|---|
| H1 | Sayfanın ana başlığı | Birincil anahtar kelime | 1 adet |
| H2 | Ana bölümler | İkincil anahtar kelimeler | 3–8 adet |
| H3 | H2 altındaki alt bölümler | LSI / ilişkili terimler | Gerektiği kadar |
| H4–H6 | Derin hiyerarşi | İsteğe bağlı | Gerektiğinde |
Yaygın hatalar:
- H1 yerine CSS ile büyütülmüş div veya p kullanmak
- Her sayfada aynı H1 (örneğin hep şirket adı)
- Görsel amaçlı H2 (büyük font istendiğinde H2’ye atlamak)
- H1’den H3’e atlamak (H2’yi atlamak)
Görsel SEO: Teknik Optimizasyon
Görsel Format Karşılaştırması
| Format | Boyut | Tarayıcı Desteği | İdeal Kullanım |
|---|---|---|---|
| JPEG | Referans (%100) | Evrensel | Fotoğraf |
| PNG | Büyük (PNG-24) | Evrensel | Şeffaflık gerektiren |
| WebP | JPEG’den %25–35 küçük | Tüm modern tarayıcılar | Fotoğraf ve grafik |
| AVIF | WebP’den %20 küçük | Çoğu modern tarayıcı | En iyi sıkıştırma |
| SVG | Vektör, boyutsuz | Evrensel | İkon, logo |
| GIF | Büyük | Evrensel | Video yerine AVIF/WebP |
Görsel yükleme best practice:
<!-- Responsive görsel (srcset + sizes) -->
<img
src="gorsel-800.webp"
srcset="gorsel-400.webp 400w, gorsel-800.webp 800w, gorsel-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 800px"
alt="Açıklayıcı alt metin buraya"
width="800"
height="500"
loading="lazy"
>
<!-- Hero görseli (fetchpriority - lazy DEĞIL) -->
<img
src="hero.webp"
alt="Hero görsel açıklaması"
width="1440"
height="600"
fetchpriority="high"
>
İç Bağlantı Mimarisi
Otorite Akışı (PageRank Distribution)
İç bağlantı yapısı, site içi otorite dağılımını belirler. Ana sayfadan en önemli sayfalara bağlantı vermek onların sıralama gücünü artırır; bu mimari kararı sonradan değiştirmek, siteye tekrar tekrar müdahale gerektiren, kolayca ihmal edilen bir çalışmadır.
| Bağlantı Türü | Otorite Akışı | SEO Değeri | Kullanım |
|---|---|---|---|
| Navigasyon menüsü | Yüksek (site geneli) | Yüksek | Tüm önemli sayfalar |
| Breadcrumb | Orta (hiyerarşi) | Orta | Kategori ve ürün |
| İçerik içi bağlantı | Yüksek (bağlamsal) | Çok yüksek | İlgili içerikler |
| Footer bağlantısı | Düşük (tekrar eden) | Düşük | Yardımcı sayfalar |
| Sidebar | Orta (tekrar eden) | Orta | İlgili içerik |
Anchor text stratejisi:
| Anchor Text Türü | Örnek | İdeal Kullanım Oranı |
|---|---|---|
| Exact match | ”web tasarım fiyatları” | %10–20 |
| Partial match | ”web tasarım konusunda” | %20–30 |
| Branded | ”Onur Öztürk’ün blogu” | %15–25 |
| Generic | ”buraya tıklayın”, “bu makale” | En az, mümkünse kaçın |
| URL | siteniz.com/… | Yalnızca gerektiğinde |
Schema Markup Stratejisi
Schema Türleri ve SEO Faydaları
| Schema Türü | Sağlayabileceği Zengin Sonuç | Zorunlu Özellikler | İdeal Sayfa |
|---|---|---|---|
| Organization | Knowledge Panel | name, url, logo | Ana sayfa |
| LocalBusiness | Haritalar entegrasyonu | name, address, phone | İletişim, ana sayfa |
| BreadcrumbList | Breadcrumb SERP görünümü | item, position | Tüm sayfalar |
| Article/BlogPosting | Haber carousel, author bilgisi | headline, author, datePublished | Blog yazıları |
| FAQPage | FAQ accordion SERP | question, answer | SSS bölümleri |
| Product | Fiyat, stok, puan SERP | name, price, availability | Ürün sayfaları |
| Service | Hizmet bilgisi | name, description, provider | Hizmet sayfaları |
| HowTo | Adım adım işlem | step, name, text | Kılavuz içerikler |
| Review/Rating | Yıldız puanı SERP | ratingValue, reviewBody | Yorum sayfaları |
Teknik uygulama: Schema markup için JSON-LD formatını tercih edin (Microdata veya RDFa yerine). JSON-LD, sayfa yapısına dokunmadan <script> etiketi içinde uygulanabilir.
Yapay Zeka Tarayıcıları ve Site Mimarisi
Klasik Googlebot’un yanı sıra, ChatGPT, Perplexity ve benzeri sistemlerin kullandığı tarayıcılar da artık siteleri ziyaret ediyor. Bu tarayıcıların çoğu, Googlebot’a kıyasla JavaScript render konusunda daha sınırlı yeteneklere sahip — bu da CSR ağırlıklı sitelerin yapay zeka sistemleri tarafından hiç okunamayabileceği anlamına geliyor.
Pratik sonuç: SSR veya SSG mimarisi tercih etmek, yalnızca klasik Google sıralaması için değil, yapay zeka sistemlerinde kaynak gösterilme olasılığı için de önemli hale geliyor. Sunucu tarafında üretilmiş, temiz HTML içeren bir sayfa, hem Googlebot hem de yapay zeka tarayıcıları için en güvenilir format.
Bu tarayıcıların engellenmemesi de ayrı bir kontrol gerektiriyor — robots.txt dosyanızda yanlışlıkla bu tarayıcıları engelleyen bir kural olup olmadığını düzenli kontrol etmek gerekir; ayrıntı için AI crawler optimizasyonu yazısına bakabilirsiniz.
JavaScript ve SEO: Dikkat Edilecekler
JavaScript Render Türleri Karşılaştırması
| Render Türü | Açıklama | SEO Uyumu | Framework |
|---|---|---|---|
| SSR (Server-Side Rendering) | Sunucuda HTML üretilir | Mükemmel | Next.js, Nuxt.js |
| SSG (Static Site Generation) | Derleme zamanında HTML | Mükemmel | Next.js, Astro, Gatsby |
| CSR (Client-Side Rendering) | Tarayıcıda render | Sorunlu | React, Vue (varsayılan) |
| ISR (Incremental Static Regen.) | Periyodik yenileme | İyi | Next.js |
| Hybrid | SSR + SSG karışık | İyi | Next.js, Nuxt.js |
CSR (Client-Side Rendering) SEO sorunu: React veya Vue ile sadece CSR kullanan siteler, Googlebot’un JavaScript’i işlemedeki gecikme nedeniyle içeriğin geç veya eksik indekslenmesiyle karşılaşabilir. Bu sorun SSR veya SSG ile çözülür.
Gecikmeli dizinlemenin pratik etkisi: Googlebot artık JavaScript’i işleyebiliyor olsa da, bu işlem iki aşamalı bir kuyrukta gerçekleşiyor — önce ham HTML taranıyor, JavaScript render’ı ise ayrı, genellikle günler sonraya sarkan bir ikinci aşamada yapılıyor. Bu gecikme, hızlı hareket eden sektörlerde (haber, kampanya sayfaları, stok durumu değişen ürünler) ciddi bir dezavantaj yaratabilir; içerik dizine girene kadar güncelliğini yitirmiş olabilir.
Erişilebilirlik (a11y) ile SEO’nun Kesişimi
Erişilebilirlik ve SEO çoğu zaman ayrı disiplinler gibi ele alınır, ama pratikte büyük ölçüde örtüşürler. Ekran okuyucular için yapılan optimizasyonların çoğu, arama motorlarının sayfayı anlaması için de doğrudan fayda sağlar.
Ortak noktalar:
- Anlamlı başlık hiyerarşisi: Ekran okuyucu kullanıcıları sayfada H1-H6 hiyerarşisiyle gezinir; Google da aynı hiyerarşiyi içerik yapısını anlamak için kullanır.
- Görsel alt metni: Görme engelli kullanıcılar için açıklama sağlar, aynı zamanda Google’ın görseli anlaması için birincil kaynaktır.
- Anlamlı bağlantı metni: “Buraya tıklayın” yerine “SEO uyumlu web tasarım rehberi” gibi açıklayıcı bir anchor text, hem ekran okuyucu kullanıcısına hem Google’a bağlantının nereye gittiğini net biçimde bildirir.
- Form etiketleri (label): Doğru etiketlenmiş form alanları hem erişilebilirlik hem de kullanılabilirlik sinyali olarak değerlendirilir.
- Renk kontrastı: Düşük kontrast, okunabilirliği zorlaştırır; bu da kullanıcının sayfada geçirdiği süreyi ve etkileşim oranını olumsuz etkileyerek dolaylı bir SEO sinyaline dönüşebilir.
Erişilebilirlik denetimi için Lighthouse’un “Accessibility” skoru iyi bir başlangıç noktasıdır; WCAG 2.1 AA seviyesini hedeflemek, hem yasal uyumluluk hem de SEO açısından sağlam bir temel oluşturur.
Türkiye Bağlamı: Yerel Hosting ve CDN Kararları
Türkiye pazarına hitap eden bir site için hosting ve CDN kararı, Core Web Vitals performansını doğrudan etkiler. Sunucu Avrupa’nın batısında veya ABD’de barındırılan bir site, Türkiye’den gelen kullanıcılar için gecikme (latency) yaşayabilir — bu da LCP metriğini olumsuz etkiler.
Pratik öneriler:
- Hedef kitleniz ağırlıklı olarak Türkiye ise, İstanbul veya yakın bölgede sunucu/CDN uç noktası (edge location) sunan bir sağlayıcı tercih edin.
- Statik varlıkları (görsel, CSS, JS) mutlaka bir CDN üzerinden sunun; CDN’in Türkiye’de veya yakın coğrafyada uç noktası olduğunu doğrulayın.
- Uluslararası pazarlara da hitap ediyorsanız, çok bölgeli bir CDN yapılandırması (her bölge için en yakın uç nokta) düşünün — bu durumda uluslararası SEO yazısındaki hreflang ve bölgeleme konularını da birlikte değerlendirin.
Bu karar genellikle geliştiriciler tarafından maliyet odaklı alınır, ama gerçek kullanıcı gecikmesi (CrUX verisi) üzerindeki etkisi göz ardı edilmemelidir — birkaç yüz milisaniyelik gecikme, LCP eşiğini “iyi” kategorisinden “iyileştir” kategorisine düşürebilir.
Teknik SEO Denetim Araçları
| Araç | Ücretsiz/Ücretli | Güçlü Yönü | Kullanım |
|---|---|---|---|
| Google Search Console | Ücretsiz | Gerçek Google verisi | Sürekli izleme |
| PageSpeed Insights | Ücretsiz | Core Web Vitals | Hız analizi |
| Lighthouse | Ücretsiz | Kapsamlı denetim | Geliştirme ortamı |
| Screaming Frog | Ücretsiz (500 URL) / Ücretli | Site tarama | Teknik SEO audit |
| Ahrefs Site Audit | Ücretli | Kapsamlı SEO sorunları | Aylık denetim |
| GTmetrix | Ücretsiz/Ücretli | Hız raporu + waterfall | Hız analizi |
| Mobile-Friendly Test | Ücretsiz | Mobil uyumluluk | Kontrol |
| Rich Results Test | Ücretsiz | Schema doğrulama | Schema kontrolü |
Sık Yapılan SEO+Tasarım Hataları
| Hata | Etki | Çözüm |
|---|---|---|
| Tüm site CSR (React SPA) | Gecikmiş/eksik indeksleme | SSR/SSG’ye geçiş |
| Hero görsel background-image CSS | LCP ölçülemiyor | img elementine geçiş |
| Font boyutu görselde gömülü | Google okuyamıyor | HTML + CSS metin |
| Çok fazla thin content sayfası | Dilute quality | Noindex veya birleştir |
| Eksik viewport meta | Mobil uyum yok | Meta viewport ekle |
| Tüm görseller lazy loaded | Hero gecikmesi | Hero’ya fetchpriority=“high” |
| Infinite scroll (pagination yok) | Bot taramaz | URL tabanlı pagination |
| Büyük modal popup (mobil) | Google penalti riski | Boyutu küçült veya cihaza göre gizle |
Vaka Kurgusu: Yeniden Tasarım Sonrası Trafik Kaybı
Bir e-ticaret firması, markasını modernize etmek için sitesini React tabanlı, tamamen client-side render edilen bir SPA (Single Page Application) mimarisine taşıyor. Görsel olarak yeni site çok daha etkileyici; ancak yayına girdikten dört hafta sonra organik trafik yüzde 60 düşüyor.
Teknik denetimde sorun net görünüyor: Googlebot, JavaScript ile üretilen içeriği geç veya eksik işliyor, yüzlerce ürün sayfası dizinden düşüyor. Ürün açıklamaları, fiyatlar ve kategori bilgileri tarayıcıda görünse de, arama motorunun ilk gördüğü HTML neredeyse boş.
Ekip, mimariyi sıfırdan değiştirmek yerine Next.js’e geçerek mevcut React bileşenlerinin çoğunu koruyup sunucu tarafında render edilen (SSR) bir yapıya taşıyor. Sekiz hafta süren bu geçişten sonra dizinlenen sayfa sayısı eski seviyesine dönüyor, on ikinci haftada organik trafik yeniden tasarım öncesi seviyeyi yüzde 15 oranında geçiyor — çünkü yeni tasarımın hızı ve kullanıcı deneyimi, teknik temel düzeldikten sonra asıl avantajını gösterebiliyor. Firmanın çıkardığı ders: görsel yenileme ile teknik SEO temeli aynı anda planlanmazsa, iyi niyetli bir marka yenileme projesi bile ciddi bir trafik kaybına yol açabiliyor. (Vaka temsilidir.)
Yeniden Tasarım Öncesi Kontrol Listesi
Mevcut bir siteyi yeniden tasarlıyorsanız, aşağıdaki adımları yayına almadan önce tamamlamak, vaka kurgusundaki türden kayıpları önler:
- Mevcut URL yapısını haritalayın. Hangi sayfa hangi trafiği alıyor, hangi sayfalar backlink biriktirmiş — bu envanter olmadan yönlendirme planı kurulamaz.
- 301 yönlendirme planı hazırlayın. URL yapısı değişecekse, eski-yeni URL eşleşmesi yayın öncesi tamamlanmalı; yayın sonrasına bırakılan yönlendirme, geçici ama telafisi zor bir trafik kaybına yol açar.
- Render türünü SEO gereksinimine göre seçin. Yalnızca CSR ile çalışan bir framework seçmeden önce, sitenin dizinlenebilirlik gereksinimini değerlendirin.
- Staging ortamında teknik denetim yapın. Yeni site canlıya alınmadan önce, aynı denetim araçlarıyla (Lighthouse, Screaming Frog) test edilmeli.
- Yayın gününde ve sonraki iki haftada yakından izleyin. Search Console’da dizinleme durumunu, crawl hatalarını ve trafik trendini günlük takip edin — sorun ne kadar erken yakalanırsa müdahale o kadar ucuza gelir.
Sık Yapılan Hatalar
- Tüm siteyi CSR (client-side rendering) React SPA olarak kurmak. Googlebot içeriği geç veya eksik işleyebilir; yüzlerce sayfa dizinden düşebilir. SSR veya SSG tercih edilmeli.
- Hero görseli CSS background-image ile yüklemek. Bu durumda LCP metriği doğru ölçülemez ve Google, sayfanın asıl yükleme performansını yanlış değerlendirebilir.
imgelementi kullanılmalı. - Metni görsele gömmek. Görseldeki yazıyı Google okuyamaz; hem SEO hem erişilebilirlik açısından metin her zaman gerçek HTML metni olarak sunulmalı.
- Aşırı sayıda thin content (ince içerikli) sayfa üretmek. Az içerikli, birbirine benzeyen çok sayıda sayfa, sitenin genel kalite algısını (dilute quality) düşürür; birleştirme veya noindex değerlendirilmeli.
- Viewport meta etiketini unutmak. Mobil uyumluluk bu tek satırlık etiket olmadan kurulamaz; eksikliği mobile-first indexing’i doğrudan etkiler.
- Tüm görselleri lazy loading ile yüklemek. Hero görseline de lazy loading uygulamak, LCP metriğini geciktirir; hero görseli her zaman
fetchpriority="high"ile önceliklendirilmeli. - Infinite scroll’u pagination olmadan kurmak. Botlar sonsuz kaydırmayı takip edemez; URL tabanlı sayfalama (pagination) botun tüm içeriğe erişebilmesi için gereklidir.
- Mobilde ekranın büyük kısmını kaplayan interstitial/popup kullanmak. Google bu tür agresif interstitial’ları kullanıcı deneyimi açısından olumsuz sinyal olarak değerlendirebilir.
- Yeniden tasarım sırasında 301 yönlendirme planı yapmamak. URL yapısı değiştiğinde yönlendirme eksikse, birikmiş otorite ve backlink değeri kaybolur.
- Schema markup’ı “sıralama garantisi” sanıp asıl içerik kalitesini ihmal etmek. Schema, zengin sonuç şansı verir ama zayıf bir sayfayı tek başına yükseltmez.
Karar Çerçevesi: Hangi Render Türünü Seçmeliyim?
Framework ve render türü seçimi, projenin başında alınması gereken en kritik SEO kararlarından biridir. Aşağıdaki basit çerçeve, doğru seçimi yapmanıza yardımcı olur:
| Site tipi | Önerilen render türü | Neden |
|---|---|---|
| İçerik/blog ağırlıklı site | SSG (Static Site Generation) | İçerik nadiren değişir, önceden üretilmiş HTML en hızlı ve en SEO-dostu seçenektir |
| Sık güncellenen e-ticaret | SSR veya ISR | Stok/fiyat sık değişir ama tam statik üretim pratik değildir |
| Kullanıcıya özel panel (dashboard, üyelik alanı) | CSR kabul edilebilir | Bu sayfalar zaten dizinlenmesi gerekmeyen, oturum açmış kullanıcıya özel alanlardır |
| Kurumsal/hizmet sitesi | SSG veya SSR | İçerik nispeten sabit, hız ve SEO önceliklidir |
| Haber/içerik portalı (çok sık güncelleme) | SSR | İçerik dakikalar içinde değişebilir, statik üretim yetişemez |
Bu tabloyu kullanırken şu kurala dikkat edin: halka açık, organik trafik beklenen her sayfa SSR veya SSG ile üretilmeli; yalnızca oturum açmış kullanıcıya özel, dizinlenmesi gerekmeyen alanlarda CSR kabul edilebilir bir tercih olabilir.
Sıkça Sorulan Sorular
SEO uyumlu web tasarım, estetikten ödün vermeden teknik mükemmeliyeti bir araya getirmektir. Site yayına alınmadan bu kararların doğru alınması; sonradan yapılacak düzeltmelere kıyasla çok daha az maliyet ve kayıp sıralama riski demektir. Bu rehberdeki kontrol listelerini bir proje şablonu olarak kullanmak, ekibinizin tasarım sürecinde neyi atlamaması gerektiğini net biçimde görmesini sağlar.
İlgili yazılar: Arama Motoru Optimizasyonu | Web Tasarım Hizmetleri | WordPress SEO Uzmanı | AI Crawler Optimizasyonu
