JavaScript SEO: SPA, SSR ve Next.js Sitelerde Tarama ve Render

React, Vue ya da Angular ile kurulmuş bir sitede tarayıcıda her şey kusursuz görünür, ama Search Console'da sayfalar boş başlıkla ya da hiç dizine eklenmemiş hâlde durabilir. Sebep çoğu zaman içerik değil, içeriğin ne zaman ve nerede üretildiğidir.

Bu yazıda istemci tarafı (CSR), sunucu tarafı (SSR) ve statik (SSG) render farkını, Google'ın JavaScript'i işleme sürecini, URL Denetimi ile nasıl test edeceğinizi ve SPA ile Next.js projelerinde en sık karşılaştığım hataları anlatıyorum.

Kısa cevap: Google JavaScript'i güncel bir Chromium ile render edebilir, ancak render ayrı bir aşamadır ve her sayfada aynı güvenilirlikte çalışmaz. Önemli içeriği, başlık, canonical ve robots etiketlerini ilk HTML yanıtında sunmak (SSR veya SSG) en güvenli yoldur. Sonucu URL Denetimi'nin canlı testindeki işlenmiş HTML ile doğrulayın.

CSR, SSR ve SSG arasındaki fark nedir?

Üç yöntem arasındaki temel soru şu: Tarayıcıya ilk gelen HTML'de içerik var mı? CSR'de sunucu neredeyse boş bir kabuk gönderir, içeriği JavaScript sonradan çizer. SSR'de her istekte HTML sunucuda hazırlanır. SSG'de sayfalar derleme sırasında üretilip dosya olarak sunulur.

Next.js'in App Router yapısında bileşenler varsayılan olarak sunucuda render edilir; sorun genellikle kritik içeriğin "use client" bileşenlerinde ve tarayıcıda çekilen verilerde kalmasıyla başlar. Genel tarama ve dizine ekleme mantığını teknik SEO rehberinde ayrıntılı anlattım.

Google JavaScript'i nasıl tarar ve render eder?

Google'ın JavaScript SEO dokümanı süreci üç aşamada anlatır: tarama, render ve dizine ekleme. Aşağıdaki akış, bir URL'nin bu aşamalardan nasıl geçtiğini özetliyor.

İki ayrıntı sahada çok iş çıkarıyor. Birincisi, dokümana göre durum kodu 200 dışındaki sayfalarda render atlanabilir. İkincisi, ilk HTML'de noindex varsa Google render ve JavaScript çalıştırmayı atlayabilir; yani noindex'i JavaScript ile kaldırmaya çalışmak işe yaramayabilir.

SPA ve Next.js sitelerde en sık yapılan hatalar

Denetimlerde karşılaştığım JavaScript kaynaklı sorunların büyük kısmı aşağıdaki altı başlığa giriyor:

Bu hataların çoğu Search Console'da "Tarandı – şu anda dizine eklenmemiş" ya da soft 404 olarak görünür; teşhis için tarandı ama dizine eklenmemiş sayfalar yazısındaki gruplama yöntemini kullanabilirsiniz. Kaynak engelleme tarafında robots.txt yapılandırması yazısı işinize yarar.

URL Denetimi ile render testi nasıl yapılır?

Tarayıcıda "kaynağı görüntüle" ilk HTML'i, geliştirici araçları ise sizin tarayıcınızın ürettiği DOM'u gösterir. Google'ın gördüğünü anlamak için Search Console'daki URL Denetimi aracının canlı testi en doğru kaynaktır. Yardım dokümanına göre işlenmiş sayfanın ekran görüntüsü yalnızca canlı testte sunuluyor.

• URL Denetimi'nde "Canlı URL'yi test et" deyin, ardından "Test edilen sayfayı görüntüle" bölümünü açın.
• HTML sekmesinde ana metin, h1, title, meta description ve canonical yer alıyor mu?
• Ekran görüntüsünde içerik alanı dolu mu, yoksa yükleniyor simgesi mi var?
• Diğer bilgiler bölümünde yüklenemeyen sayfa kaynaklarını ve JavaScript konsol mesajlarını kontrol edin.
• Sahibi olmadığınız bir sayfa için Zengin Sonuçlar Testi'ni kullanın; o da işlenmiş HTML gösterir.
• Aynı kontrolü her şablondan (ürün, kategori, blog) birkaç örnekle yapın.

Render sorunu sayfa hızıyla da iç içe geçer: büyük JavaScript paketleri LCP ve INP değerlerini zorlar. Eşikler için Core Web Vitals 2025 rehberi yazısına bakabilirsiniz.

Dinamik render hâlâ bir seçenek mi?

Bir dönem botlara önceden render edilmiş HTML, kullanıcılara JavaScript sürümü sunan dinamik render sık öneriliyordu. Google'ın güncel dokümanı ise açık: dinamik render geçici bir çözümdür ve önerilen bir yöntem değildir.

Ayrıca yalnızca Google'ı düşünmek yetmez. Dokümanın da belirttiği gibi her bot JavaScript çalıştırmaz; yapay zekâ asistanlarının taramalarında ilk HTML'in dolu olması daha da önem kazanıyor.

Hangi sayfa için hangi render yöntemi?

Pratik kural şu: Aramadan trafik bekleyen her sayfa ilk HTML'de içeriğini taşımalı. Giriş arkasındaki paneller, sepet ve hesap ekranları ise CSR ile kalabilir; zaten dizine eklenmeleri gerekmez.

• Ürün ve kategori sayfaları: SSR ya da kısa yeniden doğrulama süreli ISR. Fiyat ve stok gibi alanlar da HTML'de olmalı.
• Blog ve rehber içerikleri: SSG. Yapısal veriyi de sunucuda üretin; schema oluşturucu ile JSON-LD taslağı çıkarabilirsiniz.
• Filtre ve sıralama ekranları: dizine eklenmesi istenen kombinasyonlar için gerçek URL, gerisi için parametre kontrolü.
• Kullanıcıya özel ekranlar: CSR, noindex gerekmez çünkü genellikle giriş gerektirir.

Büyük mağazalarda bu karar şablon bazında verilmeli; filtre ve varyant yapısı için e-ticaret SEO rehberi iyi bir çerçeve sunuyor. Ağır JavaScript paketlerini küçültmek ve hız bütçesi koymak performans ve büyüme hizmeti kapsamında ele aldığım konulardan.

Next.js ya da SPA projenizde hangi şablonların risk taşıdığını görmek isterseniz SEO uzmanı olarak render denetimi yapabilirim; kısa bir görüşme ile başlayabiliriz.

150+ projede e-ticaret, SaaS, sağlık ve yerel işletme sektörlerinde 8+ yıllık uygulamalı SEO ve GEO deneyimi. Teoriye değil, gerçek müşteri verilerine dayanarak yazıyor.