SSR veya SSG Kullanımı

SSR (Server-Side Rendering), her kullanıcı isteğinde HTML çıktısının sunucu tarafında oluşturularak istemciye gönderilmesidir. 2026 itibarıyla JavaScript bağımlılığı yüksek sitelerde SSR veya SSG kullanımı, Googlebot'un indeksleme süresini ortalama %70 kısaltmaktadır. Bu performans farkının kökeninde, botun render kuyruğu darboğazı ve request-response döngüsündeki gecikme yatmaktadır.

Client-Side Rendering ve Arama Motoru Botları Arasındaki Temel Sorun

Client-Side Rendering (CSR), sayfa içeriğinin tarayıcıda JavaScript çalıştırılarak oluşturulmasını gerektirir. Kullanıcı URL'ye girdiğinde sunucu neredeyse boş bir HTML iskeleti döndürür. Gerçek içerik, JavaScript dosyaları indirilip çalıştırıldıktan sonra DOM'a eklenir. Bu süreç, modern tarayıcılarda milisaniyeler içinde tamamlansa da bot perspektifinden tamamen farklı bir maliyet tablosu üretir.

Googlebot bir sayfayı tararken iki aşamalı bir süreç izler. İlk aşamada ham HTML indirilir ve temel metin içeriği okunur. İkinci aşamada JavaScript çalıştırılır ve dinamik olarak üretilen içerik render edilir. Bu ikinci aşama, render kuyruğuna bağımlıdır ve kuyruktaki yoğunluğa göre saatlerden günlere uzayabilir. Dolayısıyla CSR ile sunulan kritik içerik, botun ilk tarama geçişinde görünmez kalır. Bu gecikme, indeksleme hızını ve dolayısıyla sıralama performansını doğrudan etkiler.

SSR Mimarisinin İşleyiş Mantığı

SSR, her HTTP isteğinde sunucu tarafında HTML'in tam olarak oluşturulup istemciye gönderilmesini ifade eder. Bot veya tarayıcı, sunucudan aldığı yanıtta sayfanın tam içeriğini HTML olarak görür. JavaScript çalıştırma ihtiyacı ortadan kalkar. Bu yaklaşım, botun ilk tarama geçişinde tüm içeriği okumasını garanti eder.

Next.js'te SSR, getServerSideProps fonksiyonu ile uygulanır. Bu fonksiyon her istekte sunucu tarafında çalışır, gerekli veriyi çeker ve sayfayı tam HTML olarak render eder:

    
export async function getServerSideProps(context) {
  const data = await fetch('https://api.example.com/products');
  const products = await data.json();
  return { props: { products } };
}        
    

Nuxt.js'te ise asyncData veya Nuxt 3'te useAsyncData composable'ı aynı işlevi görür. Her iki framework'te de sunucu, isteği aldığında veriyi çeker, bileşeni render eder ve tam HTML yanıtını döndürür.

SSG Mimarisinin İşleyiş Mantığı

SSG (Static Site Generation), sayfaların build aşamasında önceden oluşturularak statik HTML dosyaları olarak sunulmasını ifade eder. SSR'den temel farkı, HTML'in her istekte değil, yalnızca build sırasında üretilmesidir. Bu yaklaşım, sunucu tarafında hiçbir runtime işlem gerektirmez ve sayfalar doğrudan CDN üzerinden sunulabilir.

Next.js'te SSG, getStaticProps fonksiyonuyla uygulanır:

    
export async function getStaticProps() {
  const data = await fetch('https://api.example.com/posts');
  const posts = await data.json();
  return { props: { posts }, revalidate: 3600 };
}      
    

Buradaki revalidate parametresi, ISR (Incremental Static Regeneration) mekanizmasını devreye sokar. Belirtilen süre (saniye cinsinden) dolduktan sonra gelen ilk istek arka planda sayfayı yeniden oluşturur. Dolayısıyla SSG'nin "statik olduğu için güncellenemez" algısı yanlıştır. ISR, SSG'nin performans avantajını korurken içerik tazeliğini sağlar.

SSR ile SSG Arasındaki Performans ve Ölçeklenebilirlik Farkları

SSR, her istekte sunucu tarafında işlem gerektirdiği için sunucu yükünü artırır. Yüksek trafikli bir sitede saniyede binlerce SSR isteği, backend altyapısını zorlayabilir. SSG ise build aşamasında tüm işlemi tamamladığı için runtime'da sunucu yükü sıfıra yakındır. Statik dosyalar CDN edge noktalarından sunulur ve TTFB (Time to First Byte) değeri dramatik biçimde düşer.

Ancak SSG'nin sınırı, build süresindedir. 100.000 ürün sayfasına sahip bir e-ticaret sitesinde tüm sayfaları build aşamasında oluşturmak, build süresini saatlere uzatabilir. Bu noktada ISR veya on-demand revalidation devreye girer. Sık güncellenen sayfalar ISR ile yönetilir, nadiren değişen sayfalar ise full SSG olarak kalır. SEO açısından SSR ve SSG arasında indeksleme farkı yoktur; her ikisi de bota tam HTML sunar. Karar, sunucu yükü, içerik tazeliği ve build süresi dengesine göre verilmelidir.

Googlebot'un Render Kuyruğu ve WRS Mekanizması

Googlebot, JavaScript render işlemini Web Rendering Service (WRS) adlı ayrı bir altyapıda gerçekleştirir. WRS, headless Chromium tabanlıdır ve güncel Chrome versiyonunu kullanır. Ancak render kuyruğu sınırsız değildir. Milyarlarca sayfanın render edilmesi gereken bir ekosistemde, her sayfa kuyruğa alınır ve sırası geldiğinde render edilir.

Bu kuyruğun getirdiği gecikme, SEO açısından doğrudan risk oluşturur. CSR ile sunulan bir sayfa yayınlandığında, botun ilk geçişinde yalnızca JavaScript referanslarını ve boş bir HTML iskeleti görür. İçerik, render kuyruğundan geçtikten sonra ancak ikinci geçişte okunur. Bu iki geçiş arasında günler hatta haftalar geçebilir. SSR veya SSG kullanıldığında ise bot, ilk geçişte tam içeriği alır ve render kuyruğuna ihtiyaç duymaz. Bu fark, özellikle haber siteleri ve hızlı indeksleme gerektiren içeriklerde kritik önem taşır.

Hydration Kavramı ve SEO Üzerindeki Gizli Etkisi

Hydration, sunucu tarafında render edilmiş statik HTML'in istemcide JavaScript ile etkileşimli hale getirilmesi sürecidir. SSR veya SSG ile üretilen sayfa, tarayıcıya tam HTML olarak ulaşır. Ardından JavaScript dosyaları indirilir, parse edilir ve DOM üzerindeki elemanlara event listener'lar bağlanır. Bu süreç tamamlanana kadar sayfa görünür ancak etkileşimsizdir.

Hydration gecikmesi, INP (Interaction to Next Paint) ve FID (First Input Delay) metriklerini doğrudan etkiler. Büyük JavaScript bundle'ları olan uygulamalarda hydration süresi 2-5 saniyeye ulaşabilir. Bu süre zarfında kullanıcı butona tıklasa bile tepki alamaz. SEO açısından hydration gecikmesinin bir diğer riski, hydration sırasında DOM'un yeniden yazılmasıdır. Sunucu tarafında render edilen HTML ile istemci tarafında hydrate edilen HTML arasında fark varsa (hydration mismatch), tarayıcı DOM'u yeniden oluşturur ve bu durum CLS (Cumulative Layout Shift) artışına neden olur.

Partial Hydration ve Island Architecture Yaklaşımı

Geleneksel hydration, sayfanın tamamını JavaScript ile etkileşimli hale getirir. Ancak bir blog yazısının başlık ve paragraf bölümleri zaten etkileşim gerektirmez; yalnızca yorum formu veya paylaşım butonları JavaScript'e ihtiyaç duyar. Partial hydration, yalnızca etkileşimli bileşenleri hydrate ederek gereksiz JavaScript yükünü ortadan kaldırır.

Astro framework'ü, island architecture yaklaşımını doğal olarak uygular. Statik HTML varsayılan render yöntemidir; JavaScript yalnızca client: direktifiyle işaretlenen bileşenlere yüklenir. Bu yaklaşım, toplam JavaScript bundle boyutunu %60-80 oranında küçültebilir. SEO perspektifinden bakıldığında, daha az JavaScript hem TTFB'yi düşürür hem de hydration gecikmesini minimuma indirir. Dolayısıyla bot ve kullanıcı aynı anda kazançlı çıkar.

Streaming SSR ve Aşamalı HTML Teslimi

Geleneksel SSR'de sunucu, sayfanın tamamını render edene kadar bekler ve ardından tek parça olarak gönderir. Streaming SSR ise HTML'i parça parça (chunk) göndererek ilk byte'ın istemciye ulaşma süresini kısaltır. React 18 ile gelen renderToPipeableStream API'si, bu yaklaşımı doğal olarak destekler.

Next.js App Router, streaming SSR'i loading.js dosyaları ve React Suspense bileşenleri aracılığıyla uygular. Sayfanın üst kısmı (header, başlık, ilk paragraf) anında gönderilir; veri bağımlı bileşenler hazır olduğunda akış içinde yerlerine yerleşir. Bot perspektifinden streaming SSR, geleneksel SSR ile aynı nihai HTML'i üretir. Ancak TTFB metriği önemli ölçüde iyileşir, çünkü ilk byte sunucu işlemi tamamlanmadan gönderilir.

Next.js App Router ve Server Components'ın SEO Etkisi

Next.js 13 ile gelen App Router, React Server Components (RSC) mimarisini temel alır. Server Components, sunucu tarafında çalışır ve istemciye hiç JavaScript göndermez. Bu bileşenler tam HTML olarak render edilir ve istemcide hydration gerektirmez. Client Components ise etkileşim gerektiren bileşenler için kullanılır ve yalnızca bu bileşenler hydrate edilir.

SEO açısından bu ayrım kritik bir avantaj sunar. Server Components ile render edilen içerik, botun ilk geçişinde tam olarak görünür, JavaScript bağımlılığı sıfırdır ve sayfa boyutu küçülür. "use client" direktifi yalnızca gerçekten etkileşim gerektiren bileşenlerde kullanılmalıdır. Yaygın hata, tüm bileşenleri Client Component olarak tanımlamaktır; bu durumda Server Components'ın performans ve SEO avantajı tamamen yitirilir.

Nuxt.js Rendering Modları ve SEO Yapılandırması

Nuxt.js, rendering modunu nuxt.config dosyasında esnek biçimde yapılandırmaya olanak tanır. Nuxt 3'te routeRules özelliği, farklı URL kalıpları için farklı rendering stratejileri tanımlamayı mümkün kılar:

    
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { prerender: true },
    '/products/**': { ssr: true },
    '/dashboard/**': { ssr: false }
  }
})    
    

Bu yapılandırmada blog sayfaları build aşamasında statik olarak üretilir (SSG), ürün sayfaları her istekte sunucu tarafında render edilir (SSR) ve dashboard sayfaları yalnızca istemci tarafında render edilir (CSR). SEO gerektirmeyen dashboard gibi alanlar CSR olarak bırakılabilir. Ancak arama sonuçlarında görünmesi gereken tüm sayfalar SSR veya SSG olarak yapılandırılmalıdır. Bu hibrit yaklaşım, her sayfa tipine en uygun rendering stratejisini uygulayarak hem performansı hem de indeksleme verimliliğini maksimize eder.

Gatsby ve Statik Site Oluşturucuların SEO Avantajları

Gatsby, React tabanlı bir statik site oluşturucudur ve varsayılan olarak tüm sayfaları build aşamasında HTML olarak üretir. GraphQL tabanlı veri katmanı, farklı kaynaklardan (CMS, API, markdown) veri çekmeyi ve build sırasında sayfalara enjekte etmeyi sağlar. Üretilen statik dosyalar CDN üzerinden sunulduğunda TTFB değeri 50 ms altına düşebilir.

Gatsby'nin SEO avantajı, botun hiçbir JavaScript bağımlılığı olmadan tam HTML almasıdır. Ancak build süresi büyük sitelerde ciddi bir darboğazdır. 50.000 sayfalık bir Gatsby projesi, build süresinin 30 dakikayı aşmasına neden olabilir. Gatsby Cloud ve DSG (Deferred Static Generation) bu soruna kısmi çözüm sunar; ancak ölçeklenebilirlik açısından Next.js'in ISR mekanizması daha esnek bir alternatiftir.

Angular Universal ve Vue SSR Entegrasyonu

Angular ekosisteminde SSR, Angular Universal modülü aracılığıyla sağlanır. @nguniversal/express-engine paketi, Express.js sunucusu üzerinde Angular bileşenlerini server-side render eder. Angular 17 ile gelen hydration iyileştirmeleri, önceki versiyonlardaki performans sorunlarını büyük ölçüde çözmüştür.

Vue.js ekosisteminde Nuxt.js dışında, vanilla Vue ile SSR uygulamak vue-server-renderer paketi aracılığıyla mümkündür. Ancak bu yaklaşım, routing, veri fetching ve state yönetimi gibi konularda manuel yapılandırma gerektirir. Dolayısıyla Vue tabanlı projelerde Nuxt.js kullanmak, SSR/SSG yapılandırmasını önemli ölçüde basitleştirir ve hata olasılığını düşürür.

CSR'den SSR/SSG'ye Geçiş Stratejisi

Mevcut bir CSR projesini SSR veya SSG'ye dönüştürmek, sıfırdan yazmaktan daha karmaşık bir süreçtir. Bu geçiş, veri fetching katmanının sunucu tarafına taşınmasını, browser API'lerine (window, document, localStorage) bağımlı kodların izole edilmesini ve routing yapısının framework'ün SSR mekanizmasıyla uyumlu hale getirilmesini gerektirir.

Sahadaki gerçek tecrübemiz gösteriyor ki, en verimli geçiş stratejisi kademeli yaklaşımdır. İlk aşamada yalnızca SEO kritik sayfalar (ana sayfa, ürün sayfaları, blog yazıları) SSR'e taşınır. İkinci aşamada geri kalan sayfalar dönüştürülür. Üçüncü aşamada performans optimizasyonu ve hydration iyileştirmeleri yapılır. Next.js'in Pages Router ile App Router'ın bir arada çalışabilmesi, bu kademeli geçişi destekleyen güçlü bir özellik olarak öne çıkmaktadır.

JavaScript Devre Dışıyken İçerik Görünürlüğü Testi

SSR veya SSG'nin doğru çalışıp çalışmadığını test etmenin en basit yöntemi, JavaScript'i devre dışı bırakarak sayfayı yüklemektir. Chrome DevTools'ta F12 > Settings (F1) > Debugger > Disable JavaScript yolunu izleyerek JavaScript'i kapatın ve sayfayı yenileyin. Eğer başlık, ana metin, görseller ve navigasyon görünüyorsa, SSR/SSG doğru çalışıyordur.

Bu testte dikkat edilmesi gereken nokta, yalnızca ana içeriğin değil, yapısal veri (structured data) ve meta etiketlerin de kontrol edilmesidir. view-source: ile sayfanın kaynak kodunu incelediğinizde, <script type="application/ld+json"> blokları ve <meta name="description"> etiketleri HTML içinde görünmelidir. Bu elemanlar JavaScript ile enjekte ediliyorsa, bot bunları ilk geçişte göremez. SSR/SSG yapılandırmasında structured data ve meta etiketlerin sunucu tarafında render edilmesi zorunludur.

Dynamic Rendering ve Bot Tespiti Yaklaşımı

Dynamic rendering, bot isteklerini tespit edip yalnızca botlara önceden render edilmiş HTML sunarken, normal kullanıcılara CSR deneyimi sunmayı ifade eder. Google bu yaklaşımı bir ara çözüm olarak tanımlamış, ancak uzun vadeli strateji olarak önermemiştir. Prerender.io ve Rendertron gibi araçlar, bu yaklaşımı uygulamak için kullanılır.

Dynamic rendering'in temel riski, cloaking (gizleme) ile karıştırılma potansiyelidir. Bot ve kullanıcıya farklı içerik sunmak Google kurallarına aykırıdır. Ancak aynı içeriğin farklı render yöntemleriyle sunulması, Google tarafından kabul edilmektedir. Bununla birlikte, dynamic rendering ek altyapı karmaşıklığı getirir, render cache'inin güncellenmesi gereken ayrı bir katman oluşturur ve uzun vadede SSR/SSG'ye geçiş kaçınılmaz olduğundan teknik borç biriktirir. Yeni projelerde dynamic rendering yerine doğrudan SSR veya SSG tercih edilmelidir.

Meta Etiketlerin ve Open Graph Verilerinin Sunucu Taraflı Render Edilmesi

Sosyal medya platformlarının crawler'ları (Facebook, Twitter, LinkedIn) JavaScript çalıştırmaz. Dolayısıyla Open Graph etiketleri (og:title, og:description, og:image) ve Twitter Card etiketleri JavaScript ile enjekte ediliyorsa, sosyal medya paylaşımlarında başlık, açıklama ve görsel görünmez. Bu durum, sosyal medyadan gelen trafik potansiyelini doğrudan etkiler.

SSR ve SSG mimarilerinde meta etiketler, HTML'in <head> bölümünde sunucu tarafında render edilir. Next.js'te generateMetadata fonksiyonu veya <Head> bileşeni, Nuxt.js'te useHead composable'ı bu amaçla kullanılır. Her sayfanın benzersiz meta etiketlere sahip olması ve bu etiketlerin view-source: ile doğrulanabilir olması, SEO ve sosyal medya optimizasyonunun temel koşuludur.

Edge Rendering ve Sunucu Konumunun TTFB Etkisi

Edge rendering, SSR işleminin merkezi bir sunucu yerine kullanıcıya en yakın CDN edge noktasında gerçekleştirilmesini ifade eder. Vercel Edge Functions, Cloudflare Workers ve Deno Deploy bu yaklaşımı destekleyen platformlardır. Edge rendering ile TTFB, coğrafi mesafeden bağımsız olarak 50-100 ms bandına düşürülebilir.

Ancak edge ortamları, Node.js runtime'ının tam özellik setini desteklemez. Dosya sistemi erişimi, belirli native modüller ve uzun süreli işlemler edge'de çalışmaz. Dolayısıyla karmaşık veri fetching veya ağır hesaplama gerektiren sayfalar edge rendering'e uygun olmayabilir. Hibrit yaklaşımda, statik ve basit dinamik sayfalar edge'de render edilirken, ağır backend işlemi gerektiren sayfalar merkezi sunucuda SSR ile render edilir.

Core Web Vitals Metrikleri Üzerinde Rendering Yönteminin Etkisi

Rendering yöntemi, Core Web Vitals'ın üç temel metriğini farklı biçimlerde etkiler. LCP (Largest Contentful Paint) açısından SSG en avantajlıdır; statik HTML doğrudan CDN'den sunulduğu için en hızlı LCP değerlerini üretir. SSR, sunucu işlem süresine bağlı olarak SSG'den yavaştır. CSR ise JavaScript'in indirilip çalıştırılmasını beklediği için en yavaş LCP değerlerini oluşturur.

CLS (Cumulative Layout Shift) açısından SSR ve SSG, sayfa yapısının HTML'de tanımlı olması sayesinde düşük CLS değerleri üretir. CSR'de ise JavaScript çalıştıktan sonra DOM'a eklenen elemanlar layout shift'e neden olabilir. INP (Interaction to Next Paint) metriği ise hydration süresine bağlıdır. SSG ile partial hydration kombinasyonu, üç CWV metriğinde birden en iyi sonuçları üretir. Bu kombinasyon, 2026 itibarıyla performans odaklı sitelerin standart mimarisi haline gelmiştir.

Structured Data ve JSON-LD'nin SSR/SSG Uyumluluğu

JSON-LD formatındaki structured data, sayfanın <head> veya <body> bölümünde <script type="application/ld+json"> etiketi içinde sunulur. CSR mimarilerinde bu script etiketi JavaScript ile DOM'a enjekte edildiğinde, botun ilk tarama geçişinde yapısal veriyi okuyamaması riski doğar. SSR ve SSG'de ise JSON-LD, HTML ile birlikte sunucu tarafında render edilir ve bot için ilk geçişte erişilebilir olur.

Next.js'te JSON-LD'yi SSR/SSG uyumlu biçimde eklemek için:

    
export default function ProductPage({ product }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.description,
    offers: {
      '@type': 'Offer',
      price: product.price,
      priceCurrency: 'TRY'
    }
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      {/* Sayfa içeriği */}
    </>
  );
}  
    

Bu yapı, structured data'nın HTML kaynağında doğrudan görünmesini garanti eder. Google Rich Results Test aracıyla URL'yi kontrol ettiğinizde, yapısal verinin doğru parse edildiğini doğrulayabilirsiniz.

SSR/SSG Yapılandırmasında Sık Yapılan Kritik Hatalar

SSR veya SSG mimarisine geçen projelerde tekrarlanan hatalar, rendering avantajını ortadan kaldırabilir. Bu hataların farkında olmak, geçiş sürecinin başarısını belirler:

• Browser API'lerinin sunucu tarafında çağrılması: window, document, localStorage gibi nesneler sunucu ortamında mevcut değildir. Bu çağrılar typeof window !== 'undefined' kontrolüyle korunmalı veya useEffect hook'u içine alınmalıdır.
• Hydration mismatch hataları: Sunucu ve istemci tarafında farklı HTML üretilmesi, React'ın DOM'u yeniden oluşturmasına ve CLS artışına neden olur. Tarih, rastgele sayı veya kullanıcıya özel veri gibi değişkenler bu uyumsuzluğun kaynağıdır.
• Tüm veri fetching'in istemci tarafında kalması: SSR/SSG framework'üne geçilmesine rağmen veri çekme işlemlerinin useEffect içinde bırakılması, sayfanın sunucu tarafında boş render edilmesine neden olur.
• Meta etiketlerin istemci tarafında enjekte edilmesi: document.title veya document.querySelector('meta') ile yapılan meta yönetimi, SSR'nin SEO avantajını tamamen yok eder.
• Bundle boyutunun kontrolsüz büyümesi: Tüm bileşenlerin tek bir JavaScript dosyasında toplanması, hydration süresini uzatır ve INP metriğini kötüleştirir.

Rendering Stratejisinin İçerik Tipine Göre Seçimi

Çoğu uzman aksini iddia etse de, tek bir rendering stratejisi tüm sayfa tipleri için optimal değildir. Modern web mimarileri hibrit rendering yaklaşımını destekler ve her içerik tipi için en uygun stratejiyi seçmek, hem performansı hem de SEO verimliliğini maksimize eder.

Blog yazıları ve statik sayfalar SSG için idealdir; nadiren değişirler ve CDN üzerinden saniyenin kesri altında sunulabilirler. Ürün sayfaları, stok durumu ve fiyat güncellemesi gerektirdiği için ISR ile yönetilmelidir. Arama sonuçları ve filtreleme sayfaları, kullanıcı girdisine bağlı olarak her istekte farklı içerik ürettiği için SSR gerektirir. Dashboard ve hesap sayfaları SEO gerektirmediğinden CSR olarak bırakılabilir. Bu karar matrisini projenin başında oluşturmak, sonradan yapılacak mimari revizyonların maliyetini ortadan kaldırır.

Rendering stratejisi, teknik SEO altyapısının temel taşıdır. Botun ilk tarama geçişinde tam içerik alıp almadığı, indeksleme hızından sıralama performansına uzanan zincirin ilk halkasını oluşturur. SSR veya SSG'yi doğru yapılandıran siteler, bu zincirin kontrolünü elinde tutar.