JavaScript SEO ve Dinamik Renderlama: Google SPA'nı Belki Hiç Okumuyor
JavaScript SEO, Google'ın içeriğini görüp görmediğine karar verir. Googlebot JS'yi nasıl renderlar, SPA'lar neden sıralamada ölür ve Nuxt ile SSR sorunu yapısal olarak nasıl çözer.
Cagri Ersöz
Cagri Ersöz, Hannover'deki dijital ajans Storyable'ın kurucusu ve genel müdürüdür. Satış psikolojisine dayalı web tasarımı ve full-stack geliştirme (Vue.js, Nuxt, React) deneyimiyle KOBİ'ler için 50'den fazla dijital projeyi hayata geçirmiştir. Uzmanlık alanları: dönüşüm optimizasyonu, yapay zeka entegrasyonu ve veri odaklı pazarlama.
Şimdi İletişime GeçBu makalenin içeriği↓
React, Vue veya Angular ile harika ve animasyonlu bir Single Page App'in başlatıyorsun. Tasarım stüdyosundan çıkmış gibi görünüyor. Google trafiği bekliyorsun – ve hiçbir şey gelmiyor. Altı ay sonra Search Console'u açıyorsun ve görüyorsun: İçerikler indekslenmemiş. JavaScript SEO'nun 2026'daki sert gerçeğine hoş geldin.
Storyable olarak Hannover'da bu hatayı Create-React-App veya saf Vue-CLI tabanlı bir SPA ile başlayan müşterilerde sürekli görüyoruz. Görsel olarak kusursuz, teknik olarak SEO mezarı. Sebep, Googlebot'un JavaScript'i Chrome tarayıcıdan temelde farklı işlemesinde yatıyor. Bunu anlamayan görünürlükle ödüyor. Bazen tüm organik erişimle.
„SSR'siz bir SPA, okuyucunun önce çevirmesi gereken bir dilde yazılmış bir kitap gibidir. Bazen zamanını ayırır. Çoğu zaman bir kenara koyar. Googlebot tam o okuyucudur – ve seçebileceği 8 milyar başka kitabı vardır."
Sorun: Google JavaScript'i Tarayıcından Farklı Şekilde Tarar
Chrome'da bir web sitesini açtığında tarayıcı HTML'i yükler, JavaScript'i alır, çalıştırır, DOM'u kurar, pikselleri renderlar. Üç saniye sonra hazır sayfayı görürsün. „Tarayıcım yapabiliyorsa Google da yapabilir" diye düşünürsün. Yanlış.
Googlebot iki aşamalı çalışır – sıralamaları gelmediğinde çoğu geliştiricinin öğrendiği bir detay:
- 1. Aşama – Crawling: Bot URL'i çağırır ve ham HTML'i okur. Burada içerik yoksa (SPA'larda tipik) indeksleyici neredeyse hiçbir şey almaz.
- 2. Aşama – Rendering: Saatler veya günler sonra Google sayfayı Web Rendering Service'e (WRS) gönderir. Burada JavaScript çalıştırılır, DOM kurulur – sonuç indeksleyiciye geri gider.
- ve 2. aşama arasındaki bu boşluk sorunun özüdür. İçeriğin yalnızca JavaScript ile görünüyorsa Google bekler. Bazen günler. Bazen haftalar. Büyük SPA'larda WRS çoğu zaman yetişemez – ve sayfalarının önemli bir kısmı zayıf veya hiç indekslenmemiş kalır.
Önemli rakamlar: Onely'nin 2024 çalışması 1.000 SPA tabanlı web sitesini inceledi: Önemli içeriklerin %35'i Google'ın gördüğü renderlanmış DOM'da görünmüyordu. E-ticaret SPA'larında indekslenmemiş ürün sayfası oranı %50'ye kadar çıkıyordu. Mükemmel bir uygulama. Yarı görünürlükle.
SPA vs. SSR vs. SSG: Google Her Mimariyi Nasıl Farklı İndeksler
Modern web geliştirmeye üç mimari hakim. SEO özellikleri temelden farklıdır – ve seçim Google'da görünür olup olmamana karar verir. Performans yönünü Yüklenme süresi cirodur – Next.js ile e-ticaret performansı yazımızda detaylı inceledik, burada konu indeksleme mantığı.
| Mimari | Örnek Framework'ler | İlk HTML | İndeksleme Davranışı | SEO Riski |
|---|---|---|---|---|
| SPA (Client-Side Render) | Create-React-App, Vue CLI, Angular | Boş iskelet | Render aşaması gerektirir, çoğu zaman eksik | Yüksek |
| SSR (Server-Side Render) | Nuxt, Next.js, Remix | Tam içerik | Anında indekslenebilir | Çok düşük |
| SSG (Static Site Generation) | Nuxt SSG, Astro, Hugo | Önceden derlenmiş HTML | Anında indekslenebilir | Çok düşük |
| ISR (Incremental SSR) | Next.js ISR, Nuxt Hybrid | Statik + dinamik güncellemeler | Anında indekslenebilir | Çok düşük |
SPA Neden Risk Modelidir
Saf bir SPA ilk istekte şöyle bir HTML sunar:
<!DOCTYPE html>
<html>
<head><title>App</title></head>
<body>
<div id="root"></div>
<script src="/static/js/main.js"></script>
</body>
</html>
Heading yok, metin yok, yapılandırılmış veri yok. Googlebot 1. aşamada bunu görüyorsa tek semantik bilgi başlıktaki „App". Geri kalanı WRS'in daha sonra başarılı render etmesine bağlı. Şansa bağımlı olan SEO liginde değildir.
SSR Neden Yapısal Cevaptır
SSR uygulaması ilk istekte zaten tam HTML'i sunar – heading'ler, metinler, görseller, meta etiketler ve JSON-LD şema dahil. Googlebot 1. aşamada ihtiyacı olan her şeyi alır. 2. aşama artık indeksleme açısından kritik değil, sadece etkileşimli özellikler için bonus.
Tam bu yüzden Storyable olarak her müşteriyi saf Vue-SPA yerine SSR'li Nuxt üzerine inşa ediyoruz. First Contentful Paint farkı çoğu zaman %60–80 oluyor. SEO farkı: Haftalar üzerinden ölçülen indeksleme hızında 3-5 katı.
2026 başında bir Web App alanından müşterimiz React-SPA'dan SSR'li Next.js'e geçti. Öncesi: Dahili rotaların %40'ı indekslenmiş, ortalama indeksleme gecikmesi 12 gün. Sonrası: Rotaların %100'ü indekslenmiş, ortalama gecikme 18 saat. 90 günde organik trafik +%210. Tek bir yeni backlink olmadan saf mimari sorusu.
Googlebot Tarayıcısı: Crawl Bütçesi ve Render Gecikmesi
Google'ın muazzam kaynakları var, ancak sonsuz değil. Algoritma her alan adı için bir crawl bütçesi tanımlar – Googlebot'un belirli bir sürede çağırdığı URL sayısı. JavaScript sitelerinde render geçişi de eklendiği için yük iki katına çıkar.
JavaScript Sitelerinde Crawl Bütçesi Nasıl Yakılır
Storyable SEO audit'lerinde sürekli gördüğümüz üç tipik tuzak:
- Render döngüleri: JavaScript'te ek rotaları lazy yükleyen bir SPA, tarayıcıyı tekrarlanan render geçişlerine zorlar. Crawl bütçesi tavan yapar
- MB boyutunda JS bundle'ları: Main bundle'ın 3 MB ise WRS render süresi de o kadar uzun olur. Büyük sitelerde bot yetişemez
- Dış bağımlılıklar: Render geçişinde yüklenen üçüncü taraf script'ler (tracking, widget, chatbot) indeksleyiciyi ek olarak geciktirir
Sonuç: Audit verilerimize göre orta büyüklükte SPA'larda (5.000+ rota) URL'lerin yalnızca %40–60'ı temiz indekslenmiş. Saf SSR sitelerinde değer %95+.
Gecikmenin İşine Maliyeti
İndeksleme gecikmesi sadece teknik bir detay değil – ciro kaybıdır. Üç somut zarar:
- Yeni içerikler sıralamaları geciktirir: 14 gün sonra indekslenen bir blog yazısı, en çok trafik alacağı güncellik dalgasını kaybeder
- Ürün güncellemeleri geç gelir: Google'ın haftalar sonra gördüğü yeni bir koleksiyon, alışveriş sonuçlarında hiçbir listeleme oluşturmaz
- Rakipler farkı kapatır: İçeriğin render kuyruğunda asılı kalırken SSR'li rakip aynı kavramları 24 saatte sıralar
2026'da bir SPA üzerinde e-ticaret işleten her hafta ciro feda eder. Bu teoride değil – analiz ettiğimiz her Search Console'da geçerlidir.
Dinamik Renderlama: Son Kullanma Tarihi Olan Ara Çözüm
Dinamik Renderlama, Google'ın 2018'de SPA'lar için geçiş stratejisi olarak önerdiği köprüdür: Tarayıcılar önceden renderlanmış HTML versiyonu alır, gerçek kullanıcılar normal JavaScript uygulamasını. Prerender.io, Rendertron veya kendi Puppeteer kurulumu gibi araçlar bu işi üstlenir.
Dinamik Renderlama Teknik Olarak Nasıl Çalışır
- Sunucu istek geldiğinde User-Agent'ı kontrol eder
- Crawler bot'lar için (Googlebot, Bingbot, FacebookBot) önceden renderlanmış HTML snapshot'u sunulur
- Normal tarayıcılar standart SPA'yı çalıştırır
- Renderer (Headless Chrome) snapshot'ları arka planda üretir ve cache'ler
Google Neden 2024'te Dinamik Renderlamayı Workaround Olarak Tanımladı
Google 2023/2024 resmi açıklamalarında netleştirdi: Dinamik Renderlama uzun vadeli bir konsept değil. Resmi argümanlar:
- Cloaking riski: Bot ve kullanıcılara farklı içerik sunan, içerik birbirinden saparsa Google yaptırımı riskine girer
- Bakım yükü: Renderer kurulumları sık sık kırılır (yeni tarayıcı sürümleri, yeni JS özellikleri), fark edilmemiş indeksleme hatalarına yol açar
- Performans: Renderer sunucusu, SSR mimarisinde hiç düşmeyecek kaynaklara mal olur
Storyable olarak Dinamik Renderlamayı yalnızca geçici köprü olarak kullanırız – örneğin büyük bir Legacy SPA'yla migre olan ve SSR'i 2. fazda devreye alan müşterilerde. Asla son durum olarak değil.
SPA'dan SSR'e geçiş mi gerekli? Mevcut JavaScript uygulamanı analiz ediyor, kritik SEO açıklarını tespit ediyor ve seninle birlikte SSR'li Nuxt veya Next.js'e dönüşümü planlıyoruz. Ranking düşüşü olmadan, ara durum testleri ve kayıpsız URL migrasyonuyla net bir göç planı alırsın.
Nuxt ile SSR Sorunu Yapısal Olarak Neden Çözer
Belirtiyi tedavi etmek yerine hastalığı baştan kurmazsın. Server-Side Rendering tam bunu yapar: JavaScript SEO sorununu kökten ortadan kaldırır, çünkü Googlebot 1. aşamada indeksleme için ihtiyacı olan her şeyi zaten görür.
Nuxt SSR'ın Detaylı Avantajları
- İlk yanıtta tam HTML: Heading'ler, metin, görseller, Schema.org JSON-LD, Open Graph – hepsi zaten teslim edilir
- Etkileşim için Hydration: Render sonrası JavaScript devralır ve sayfayı etkileşimli yapar – ama ilk render eksiksiz kalır
- Schema.org out-of-the-box:
nuxt-schema-orgile yapılandırılmış markup sunucu tarafında üretilir – Rich Results ve Entity SEO için kritik - Edge Rendering: Nuxt 3 Edge dağıtımları (Cloudflare, Vercel) destekler – HTML milisaniyeler içinde teslim edilir, Core Web Vitals kendiliğinden gelir
Nuxt'u doğru kuran sadece SEO'yu kontrol altına almaz, aynı zamanda performansı, güvenliği ve ölçeklenebilirliği eş zamanlı optimize eder. Üç sorun, tek mimari cevap.
Next.js, Remix, SvelteKit – Alternatifler
Vue ekosistemi projelerimize ideal uyduğu için Nuxt standart seçimimiz. Ama mantık her modern meta-framework için geçerli:
| Framework | Stack | SSR Olgunluğu | Edge Desteği |
|---|---|---|---|
| Nuxt 3 | Vue | Çok yüksek | Var (Cloudflare, Vercel) |
| Next.js 15 | React | Çok yüksek | Var (Vercel, AWS) |
| Remix | React | Yüksek | Var (Cloudflare, Fly.io) |
| SvelteKit | Svelte | Yüksek | Var (Cloudflare, Vercel) |
| Astro | Multi-Stack | Çok yüksek (SSG odaklı) | Var |
Hangi framework'ü seçtiğin ikincil. Saf bir Client-Side SPA yerine bunlardan birini seçmen birincil.
Uygulama Testi: Google Sayfanı Gerçekten Görüyor mu?
Teori yeter. İşte başka her optimizasyona dokunmadan önce her Storyable SEO audit'inde uyguladığımız üç zorunlu test.
Test 1: Google Search Console URL İncelemesi
Search Console, Google'ın fiilen ne indekslediğine dair tek güvenilir kaynaktır. İş akışı:
- URL'i URL incelemesine gir
- „Canlı URL'i test et" tıkla
- „Renderlanmış HTML" sekmesinde tüm içeriklerin var olup olmadığını kontrol et
- Ekran görüntüsünde sayfanın görsel olarak tam renderlanıp renderlanmadığını kontrol et
Renderlanmış HTML boş veya eksikse Google'ın JavaScript'inle bir sorunu vardır. Nokta.
Test 2: Render Ekran Görüntüsüyle Mobile-Friendly Test
Mobile-Friendly Test aracı (search.google.com/test/mobile-friendly) Googlebot'un renderladığı ekran görüntüsünü gösterir. Hızlı, ücretsiz, acımasızca dürüst. Header'ın orada eksikse – Googlebot da göremiyor demektir.
Test 3: JavaScript Rendering Modunda Screaming Frog
Orta ve büyük siteler için Screaming Frog (veya alternatif olarak Sitebulb) zorunlu. JS Rendering modunda araç sitenizi Googlebot gibi tarar ve gösterir:
- Hangi URL'ler JS olmadan içeriğe sahip (iyi) vs. yalnızca JS ile (risk)
- Hangi meta etiketler istemci tarafında üretiliyor (çoğu zaman kritik)
- Hangi rotalar yavaş veya hiç renderlanmıyor
Tek bir tarama içinde alan adının yapısal JavaScript SEO sorunlarını görürsün. Tipik bir 5.000 URL'lik sitede audit 2 saatten kısa sürer.
Audit'lerin %80'inde gördüğümüz klasik: Meta-Title ve Meta-Description istemci tarafında react-helmet, vue-meta veya benzeriyle ayarlanır. Ham HTML'de jenerik bir varsayılan vardır. Googlebot 1. aşamada varsayılanı indeksler. Sonuç: SERP'lerde aynı başlığa sahip yüzlerce sayfa. SSR (veya statik üretim) ile sorun tek satır kodda çözülür.
Sonuç: JavaScript SEO Var Olup Olmadığına Karar Verir
JavaScript SEO 2026'da niş değil, modern web sitesi işleten herkes için zorunlu bilgi. Saf bir SPA inşa edip Google sıralamalarını uman, kontrol etmediği bir render pipeline'ına bahse girer. İki aşamalı Googlebot, sınırlı crawl bütçesi ve büyüyen JavaScript bundle'ları Client-Side Rendering'i stratejik bir riske dönüştürür.
Üç yol kalır: Birincisi sorunu Server-Side Rendering ile kökünden çözmek – Nuxt veya Next.js 2026 endüstri standartları. İkincisi nadir değişen içerikler için Static Site Generation – sunucu yükü olmadan performans artı SEO. Üçüncüsü Dinamik Renderlama yalnızca migrasyon henüz tamamlanmadıysa köprü olarak – asla kalıcı durum olarak değil.
Storyable olarak Hannover'da görüyoruz: Uygulamasını baştan Nuxt SSR ile kuran müşteriler hiç indeksleme sorunu yaşamaz. Sonradan migre eden müşteriler 90 gün içinde çoğu zaman yeni içerik veya yeni backlink olmadan organik trafikte 2-4 katı kazanır. Bu mimaridir, pazarlama değil. JavaScript SEO'yu yok sayan, Google'ın görmediği bir dünya için optimize ediyor.
Google JavaScript uygulamanı görüyor mu – yoksa boş bir iskelet mi?
Web siteni URL incelemesi, Mobile-Friendly Test ve JS Rendering modunda Screaming Frog ile kontrol ediyoruz. Hangi rotaların indekslendiği, hangilerinin indekslenmediği konusunda net bir bulgu ve mimarinin SEO'yu engelliyorsa SSR'li Nuxt ya da Next.js'e somut göç planı alırsın.
Sıkça Sorulan Sorular
Bu konuyla ilgili en önemli soruların hızlı cevapları
JavaScript SEO nedir?+
Google neden bazı Single Page App'leri doğru okuyamıyor?+
SPA, SSR ve SSG arasındaki fark nedir?+
Dinamik Renderlama nedir – kullanmalı mıyım?+
Nuxt veya Next.js ile SSR JavaScript SEO sorununu neden çözer?+
Google'ın JavaScript sayfamı görüp görmediğini nasıl test ederim?+
İlgili Yazılar
Bu konu alanından diğer yazılar
Entity SEO ve Knowledge Graphs: Google 2026'da Neden URL Yerine Markaları Sıralıyor
Entity SEO, anahtar kelimelerden anlama geçişin adı. Google'ın markanı Knowledge Graph'a nasıl yerleştirdiği, neden Topical Authority her şeyi geçtiği ve Google'ın seni varlık olarak tanıyıp tanımadığını test etme yolu.
Google yapay zeka araması için web sitesi optimizasyonu
Google resmi olarak yapay zeka aramasında neyin önemli olduğunu söyledi – ve hangi GEO hilelerini (llms.txt, chunking) unutabileceğini. Hannover'dan net konuşma.
Yapay Zeka İçin İçerik Tasarımı: 2026'da Yapı ve Schema Markup Neden Backlinklerden Daha Önemli
Yapay zekalar insanlar gibi okumaz, veriyi parse eder. ChatGPT, Perplexity ve Google AI'ya içeriğini temiz HTML hiyerarşisi, tablolar, listeler ve JSON-LD ile gümüş tepside nasıl sunarsın.