Tek sayfa uygulamada SEO sorunu ve SSR seçenekleri

SPA mimarisi geliştirici deneyimi açısından çok cazip: hızlı geçişler, zengin etkileşimler, net bir istemci/sunucu ayrımı. Ama bir ürün üzerinde çalışırken organik arama trafiğinin beklenenden düşük geldiğini fark ettim. Sorun SPA’nın arama motorlarıyla ilişkisindeydi. Bu konuyu araştırınca karar sürecini not almak istedim.

SPA’nın arama motoru sorunu

SPA’da tarayıcı boş (veya minimal) bir HTML belgesi alır. JavaScript çalışınca içerik oluşturulur ve DOM’a eklenir. Kullanıcı için bu gayet iyi çalışır; ama arama motorunun tarayıcısı için (Googlebot gibi) bu süreç daha karmaşık.

Google, JavaScript çalıştırabilen bir tarayıcı kullanıyor. Ama bu süreç kuyruğa alınıyor ve gecikiyor. Yani sayfanız ilk tarama anında boş görünebilir; içerik ancak JavaScript işlenince ortaya çıkıyor. Google bunu er ya da geç yapıyor, ama “er ya da geç” SEO için belirsiz bir garanti.

Bing, Yandex ve diğer motorlar için JavaScript desteği daha sınırlı ya da güvenilmez.

Sonuç: içerik yoğun sayfalar — ürün açıklamaları, blog yazıları, kategori sayfaları — tam olarak indekslenmiyor ya da gecikmeli indeksleniyor.

Seçenek 1: SSR

SSR’da her istek için HTML sunucuda oluşturulur ve tarayıcıya gönderilir. Tarayıcı (veya arama motoru botu) tam HTML belgesini alır.

Next.js (React için) ve Nuxt.js (Vue için) bu yaklaşımı framework düzeyinde sunuyor. Geliştirici deneyimini korurken tarayıcıya tam HTML gönderiyor.

İstek → Sunucu → React/Vue bileşen ağacı render edilir → Tam HTML → Tarayıcı

Avantajlar: Arama motorları tam içeriği ilk yüklemede görür. Sosyal medya önizlemeleri (Open Graph) doğru çalışır. İlk sayfa yükleme (First Contentful Paint) genellikle daha hızlı.

Dezavantajlar: Sunucu kaynağı tüketir; her istek için sunucunun render yapması gerekir. Geliştirme karmaşıklığı artar — istemci/sunucu bağlamı farkları hata üretebilir. Deployment daha karmaşık; statik dosya servisi yetmez, Node.js sunucusu gerekir.

Seçenek 2: SSG

SSG build zamanında tüm sayfaların HTML’ini oluşturur. Tarayıcı önceden hazırlanmış HTML’i alır.

Next.js ve Nuxt.js bunu da destekliyor. Gatsby bu yaklaşım üzerine kurulu.

Avantajlar: CDN üzerinden sunulabilir, sunucu gerekmez ya da çok az gerekir. Çok hızlı. SEO için mükemmel — bot ne görürse kullanıcı da onu görür.

Dezavantajlar: Sayfa sayısı arttıkça build süresi uzar. Dinamik içerik (kullanıcıya özel veriler, gerçek zamanlı güncellemeler) için sınırlı. Her içerik değişikliğinde yeniden build gerekir.

Seçenek 3: ISR

Next.js’in getirdiği ISR (Incremental Static Regeneration) SSG ile SSR arasında bir orta yol. Sayfalar statik olarak önceden oluşturulur ama belirli aralıkta arka planda yenilenir.

İlk istek → Statik HTML (cache'den) → Arka planda yeniden oluşturulur
Sonraki istek (süre dolunca) → Yeni statik HTML

Büyük içerik siteleri için SSG’nin derleme süresini ve SSR’nin sunucu yükünü dengelemenin iyi bir yolu.

Seçenek 4: Prerendering

Mevcut SPA’yı değiştirmek istemiyorsanız ve geliştirme maliyetini düşük tutmak istiyorsanız prerender hizmetleri var. Prerender.io gibi servisler, arama motoru botlarını tespit edip onlara başka bir sunucuda önceden oluşturulmuş HTML sunuyor; gerçek kullanıcılara SPA gidiyor.

Bu yaklaşımın cazibesi dönüşüm maliyetinin düşük olması. Dezavantajı ek bir bağımlılık ve senkronizasyon sorunu: prerender edilen içerik gerçek içerikle her zaman senkron olmayabilir.

Hangi durumda ne seçerdim

Yeni bir içerik yoğun proje (blog, e-ticaret, pazaryeri) için Next.js veya Nuxt.js ile SSG veya ISR kombinasyonu ilk tercihim.

Mevcut bir SPA’yı dönüştürmek ciddi bir refaktör. Bu maliyete değip değmediği projenin organik arama bağımlılığına göre değişiyor. Kullanıcı oturum açmadan eriştiği ve arama motorundan bulduğu sayfalar varsa dönüşüm anlamlı. İçerik tamamen authentication arkasındaysa SEO sorunu gerçek bir sorun değil.

SPA çok iyi bir araç, ama “her şey için SPA” başlangıç noktası olunca bu tür trade-off’lar görünmez oluyor. Projenin görünürlük gereksinimi mimari kararın bir parçası olmalı.