Sunucu taraflı mı, istemci taraflı render mı? SEO için hangisi daha iyi?

Her web sitesi, mimarisinin bir yerinde HTML'in gerçekte nerede oluşturulacağına karar vermek zorundadır. Sunucu taraflı render'da (SSR) sunucu, eksiksiz bir HTML sayfasını hazırlar ve tarayıcıya içerikle dolu olarak gönderir. İstemci taraflı render'da (CSR) ise sunucu büyük ölçüde boş bir HTML iskeleti ve bir JavaScript paketi gönderir; asıl sayfayı JavaScript yüklenip çalıştıktan sonra tarayıcı oluşturur. Hızlı bağlantısı ve modern tarayıcısı olan bir kullanıcı için iki yaklaşım da birebir aynı görsel sonucu verebilir. Ayrıştıkları nokta bundan önce olanlardır ve SEO sorunları genellikle tam bu boşlukta ortaya çıkar.

Google JavaScript ağırlıklı bir sayfayla gerçekte ne yapar?

Google JavaScript'i render edebilir; bu yıllardır böyle. İnsanları yanıltan ayrıntı şu: Google'ın render işlemi, ilk taramadan ayrı, ikinci bir aşamada gerçekleşir ve Google tarafında daha fazla işlem gücü gerektirir. Bu yüzden ne anında olur ne de sınırsız bir sabırla. İçeriğini göstermek için tamamen istemci taraflı JavaScript'e dayanan bir sayfa, Google'dan sunucuda render edilen bir sayfanın hemen teslim ettiği şeyi görebilmek için ek iş yapmasını istiyor demektir. Küçük bir sitede bu nadiren ölümcül olur. On binlerce sayfası olan büyük bir sitede ise yavaş ya da güvenilmez bir render aşaması, sayfaların geç dizine eklenmesi, eksik içerikle dizine eklenmesi ya da hiç eklenmemesi anlamına gelebilir.

Diğer tarayıcı botları ve platformlar (sosyal medya bağlantı önizlemeleri, bazı yapay zekâ botları, çeşitli SEO araçları) JavaScript render etme konusunda çoğu zaman Google'dan çok daha yeteneksizdir. Yalnızca CSR kullanan bir sayfa onlara tamamen boş görünebilir; bu da bağlantı önizlemelerini, yapılandırılmış verinin çıkarılmasını ve tam bir tarayıcı çalıştırmak yerine gerçek işaretlemeyi okumaya dayanan her şeyi etkiler.

CSR'ın gerçekten sorun olmadığı yerler

Her sayfanın dizine eklenmesi, bir uygulamanın her bölümünün taranabilir olması gerekmez. Giriş ekranının arkasındaki alanlar, yönetim panelinin içi, ödeme akışı: Bunların hiçbiri arama motoru içeriği değildir ve CSR burada iyi çalışır, çünkü hedef kitle bir tarayıcı botu değil, JavaScript'i etkin gerçek bir tarayıcıdır. Ürününüz büyük ölçüde oturum açılarak kullanılan bir uygulamaysa ve yalnızca birkaç herkese açık tanıtım sayfası varsa, pragmatik çözüm çoğu zaman hibrittir: Sıralamaya girmesi gereken sayfaları sunucuda render edin, oturum açılan uygulamayı ise istemci taraflı render edilen bir tek sayfa uygulaması (SPA) olarak bırakın. Sonuçta kimse Google'da sizin oturum açılmış yönetim panelinizi aramıyor.

SSR'ın karmaşıklığına değdiği yerler

Tek görevi aramada bulunmak olan her sayfa (ürün sayfaları, blog yazıları, kategori ve listeleme sayfaları, lokasyon sayfaları, dokümantasyon) SSR'dan ya da statik üretimden (aslında her istekte değil, derleme sırasında yapılan SSR'dan ibarettir) fayda görür. İçerik ilk HTML yanıtında zaten bulunduğu için ikinci render aşamasının sorunsuz geçmesine bağımlılık kalmaz. Gerçek ziyaretçi için de genellikle daha hızlı yüklenir; çünkü tarayıcı, ekranda bakılacak bir şey belirmeden önce bir JavaScript paketinin indirilmesini, ayrıştırılmasını ve çalıştırılmasını beklemez. Bu da Core Web Vitals açısından ve nihayetinde dönüşüm açısından önemlidir.

Bedeli gerçektir: SSR sunucu tarafına karmaşıklık ekler ve kullandığınız framework'e bağlı olarak önbelleğe almayı, hydration'ı ve sunucu ile istemci arasında senkronize edilmesi gereken durumu yönetme biçiminizi değiştirir. Modern framework'ler bunu eskisine göre çok daha zahmetsiz hâle getirdi: Nadiren değişen içerik için statik üretim, değişen içerik için artımlı yeniden üretim gibi yaklaşımlar sayesinde bütün bir site için “tamamen statik” ile “tamamen dinamik” arasında seçim yapmak zorunda kalmazsınız.

Pratik kontrol listesi

• Bir sayfanın aramada sıralamaya girmesi ya da bağlantı önizlemesi olarak paylaşıldığında düzgün görünmesi gerekiyorsa, onu sunucuda veya derleme sırasında render edin.
• Bir sayfa kimlik doğrulamanın arkasındaysa ve hiçbir zaman taranmayacak ya da herkese açık paylaşılmayacaksa, istemci taraflı render makul ve daha basit bir varsayılandır.
• Yalnızca JavaScript çalıştıktan sonra tarayıcının geliştirici araçlarında gördüğünüzü değil, ham ve render edilmemiş HTML yanıtını gösteren bir araçla test edin; tarayıcı botunun ilk aşamada gördüğüne daha yakın olan budur.
• “Google JavaScript'i render edebiliyor” cümlesini “o hâlde fark etmez” diye yorumlamayın. Ölçek büyüdükçe, sunucu yavaş olduğunda ve haber ya da stok gibi zamana duyarlı her şeyde bu daha da önemli hâle gelir.

Bunu en baştan doğru kurgulamak, yani sitenin hangi bölümlerinin sunucuda render edilmesi, hangilerinin istemci tarafında kalabileceğine karar vermek, Burncode'da her web geliştirme projesinde verdiğimiz ilk mimari kararlardan biridir. Çünkü site yapılıp arama görünürlüğünü kaybetmeye başladıktan sonra bunu sonradan düzeltmek, baştan planlamaktan çok daha büyük bir iştir.