Modern web mimarilerinde React, Vue ve Angular gibi mimarilerle inşa edilen Tek Sayfa Uygulamaları (SPA), kullanıcı deneyimi açısından kusursuz bir akıcılık sunsa da arama motoru botları için ciddi bir arama mantığı karmaşası oluşturur. Doğru kurgulanmamış bir Javascript SEO stratejisi, milyarlarca dolarlık yatırımla hazırlanan web uygulamalarının arama sonuçlarında görünmez olmasına yol açabilir. Sunucu tarafında hazır HTML döndürmeyen, tüm DOM yapısını tarayıcı üzerinde JavaScript vasıtasıyla oluşturan uygulamalar, taranabilirlik ve indekslenme aşamalarında kritik darboğazlarla karşılaşır.
Googlebot her ne kadar güncel bir Chromium derleyicisi (Web Rendering Service – WRS) kullansa da, JavaScript dosyalarını indirmek, ayrıştırmak (parse) ve çalıştırmak (execute) inanılmaz bir işlemci maliyeti gerektirir. Bu durum ‘İki Aşamalı İndekslenme’ (Two-Wave Indexing) sürecini doğurur. İlk aşamada statik HTML taranır; işlenecek JS kütüphaneleri ise WRS kuyruğuna alınır. Kaynak yetersizliği veya zamanaşımı (timeout) durumunda sayfanızın kritik içerikleri hiç render edilemeyebilir. Konu hakkında detaylı teknik belgeler için Google JavaScript SEO belgeleri kaynağını inceleyebilirsiniz.
Javascript SEO Nedir ve SPA Yapılarında Neden Kriz Yaratır?
Javascript SEO, istemci taraflı (Client-Side) çalışan kod bloklarının, arama motoru tarayıcıları tarafından doğru bir şekilde işlenmesini, taranmasını ve dizine eklenmesini sağlayan teknik optimizasyonlar bütünüdür. Klasik monolithic sistemlerde (WordPress, Laravel vb.) sunucu doğrudan tamamen işlenmiş HTML kodunu Googlebot’a iletirken, SPA mimarilerinde sunucudan yalnızca boş bir HTML şablonu (örneğin <div id="root"></div>) ve devasa JS paketi döner. Bu durum, arama motorunun içeriği okuyabilmesi için JS kodunu çalıştırmasını zorunlu kılar.
Sorun tam olarak bu aşamada başlar. Googlebot bir sayfayı ziyaret ettiğinde HTTP yanıt süresi ve render zamanaşımı kısıtlarıyla hareket eder. Eğer uygulamanız API isteklerini tamamlayıp DOM’u güncelleyene kadar geçen süre tavan yaparsa, bot boş bir sayfa indeksler. Üstelik Google dışındaki Yandex, Bing ve Baidu gibi diğer arama motorlarının JavaScript çalıştırma yetenekleri oldukça kısıtlıdır ya da hiç yoktur. Dolayısıyla uluslararası veya çok kanallı bir SEO stratejisinde saf CSR (Client-Side Rendering) kullanmak doğrudan organik trafik kaybı anlamına gelir.
SPA Projelerinde Karşılaşılan Temel İndekslenme Sorunları
SPA yapılarındaki en yaygın teknik SEO problemi Soft 404 hatalarıdır. Geleneksel web sitelerinde var olmayan bir sayfaya gidildiğinde sunucu HTTP 404 durum kodu üretir. Ancak SPA mimarisinde sunucu her rotada varsayılan olarak HTTP 200 OK yanıtı verir ve sayfanın olmadığını JS tarafında anlar. Googlebot sunucudan 200 kodu aldığı ancak ekran bomboş kaldığı için bu durumu Soft 404 olarak sınıflandırır ve dizinden çıkarır. Durum kodlarının başlık seviyesinde (HTTP response header) doğru ayarlanmaması dizin tutarsızlıklarının ana kaynağıdır.
Bir diğer hayati problem ise dahili yönlendirmeler (internal routing) ve link inşasıdır. HTML standartlarında bir bağlantının taranabilmesi için mutlaka <a href="/sayfa-url"> yapısında tanımlanması gerekir. React veya Vue projelerinde sıklıkla kullanılan <button onClick="goToPage()"> veya <div data-link="..."> gibi olay dinleyicilere (event listener) bağlı yönlendirmeler Googlebot tarafından kesinlikle takip edilmez. Ayrıca URL yapısında kullanılan hashbang (site.com/#/kategori) parametreleri arama motorları tarafından yok sayılır; bu nedenle mutlaka HTML5 History API (pushState) kullanılmalıdır.
Sunucu Taraflı Render Etme (SSR) ve Hydration Stratejileri
İstemci taraflı rendering krizini aşmanın en radikal ve efektif yolu Sunucu Taraflı Render Etme (Server-Side Rendering – SSR) mimarisine geçmektir. Next.js (React), Nuxt.js (Vue) veya Universal (Angular) gibi çatı yapılar (frameworks), kullanıcı veya bot sayfayı talep ettiği anda JS kodunu sunucuda çalıştırarak tam teşekküllü HTML çıktısı üretir. Bu sayede Googlebot, istemci tarafında hiçbir JS çalıştırma ihtiyacı duymadan sayfa içeriğine, meta etiketlerine ve yapılandırılmış verilere (Schema markup) anında erişir.
Ancak SSR ile birlikte hayatımıza ‘Hydration’ kavramı ve buna bağlı performans maliyetleri girer. Hydration, sunucudan gelen statik HTML’in istemci tarafında indirilen JavaScript paketiyle eşleşip interaktif hale gelmesi sürecidir. Eğer JS paket boyutunuz aşırı büyükse veya veritabanı sorguları optimize edilmemişse, hydration süreci ana iş parçacığını (main thread) kilitler. Bu durum Core Web Vitals metriklerinden INP (Interaction to Next Paint) ve TBT (Total Blocking Time) değerlerini mahveder. Çözüm olarak Statik Site Üretimi (SSG) veya Artırımlı Statik Yeniden Üretim (ISR) kombinasyonları tercih edilmelidir.
Dinamik Rendering ve Pre-rendering Çözüm Yolları
Mevcut bir SPA projesini tamamen SSR altyapısına taşımak yüksek mühendislik maliyeti gerektirebilir veya mimari açıdan imkansız olabilir. Bu senaryoda Dinamik Rendering (Dynamic Rendering) veya Pre-rendering teknikleri hayat kurtarıcı bir alternatif olarak öne çıkar. Dinamik rendering yaklaşımında sunucu önünde duran bir katman (Rendertron, Prerender.io vb.), gelen isteğin User-Agent bilgisine bakar. İstek gerçek bir kullanıcıdan geliyorsa standart CSR çıktı verilir; istek Googlebot gibi bir arama motoru botundan geliyorsa önceden render edilmiş statik HTML sunulur.
Dinamik rendering kullanırken dikkat edilmesi gereken en kritik husus, gizli yönlendirme (cloaking) cezası almamaktır. Botlara sunulan HTML içeriği ile kullanıcılara sunulan JS çıktısının birebir aynı semantic yapıya sahip olması gerekir. Projenizin taranabilirlik durumunu ve teknik altyapısını düzenli olarak denetlemek için En Popüler 7 Ücretsiz SEO Aracı ve Kullanımı rehberimizden yararlanarak arama motorlarının sitenizi nasıl gördüğünü simüle edebilirsiniz.
Javascript SEO Performansını Ölçümleme ve Test Etme
Bir SPA uygulamasının arama motoru gözündeki başarısını doğrulamak için teorik varsayımlar yerine deneysel testler yapılmalıdır. İlk adım Google Search Console içerisindeki ‘URL İnceleme’ (URL Inspection) aracını kullanmaktır. Bu araç ile ‘Canlı Test’ çalıştırarak Google’ın sayfanızı render ettikten sonra oluşturduğu ekran görüntüsünü (screenshot) ve DOM ağacını (HTML çıktısını) inceleyebilirsiniz. Eğer kritiği yüksek metinler veya linkler DOM çıktısında yer almıyorsa, JS execution aşamasında hata var demektir.
Bunun yanı sıra Screaming Frog SEO Spider gibi profesyonel tarayıcı araçlarını ‘JavaScript Rendering’ moduna alarak tüm sitenizi talamanız gerekir. Chrome Headless altyapısı ile yapılan bu taramada, sayfaların taranma süreleri, render sonrası oluşan yönlendirmeler ve kayıp canonical etiketleri net bir şekilde tespit edilir. Sonuç olarak, doğru uygulanan bir Javascript SEO süreci; tarama bütçenizi (crawl budget) korur, indekslenme hızınızı artırır ve SPA projenizin arama sonuçlarında hak ettiği tepe noktalara ulaşmasını sağlar.
Sıkça Sorulan Sorular
Evet, Googlebot Chromium tabanlı Web Rendering Service (WRS) ile JS kodlarını çalıştırabilir. Ancak bu işlem iki aşamalı (two-wave indexing) yapıldığı için zamanaşımı ve kaynak kısıtları nedeniyle içeriklerin eksik veya geç indekslenme riski vardır.
Sunucu var olmayan bir rota için de HTTP 200 OK yanıtı döndürüp yönlendirmeyi istemci tarafında JS ile yaptığında, Googlebot sayfayı boş görünce içeriği Soft 404 olarak işaretler. Çözüm sunucunun doğru HTTP durum kodunu vermesidir.
SSR (Server-Side Rendering) her istek anında veya derlemede sunucuda dinamik HTML üretirken, Pre-rendering önceden oluşturulmuş statik HTML sayfalarını yalnızca bot taraması anında sunar.
Evet, arama motorları URL içerisindeki kare (#) simgesinden sonra gelen dizgileri yok sayar. SPA projelerinde temiz ve taranabilir adresler için HTML5 History API (pushState) kullanılmalıdır.
Aşırı büyük JavaScript paketlerinin istemci tarafında çalıştırılması (hydration) ana iş parçacığını kilitler. Bu durum özellikle INP (Interaction to Next Paint) ve TBT metriklerini olumsuz etkileyerek sıralamayı düşürür.