Tüm Yazılara Dön
Teknik SEO
19 Haziran 2025
25 dk okuma

JavaScript SEO, SPA ve PWA Optimizasyonu: React/Vue Siteleri Neden Sıralama Alamaz?

Elif Keskin
İçerik Stratejisi Lideri

[!TIP] AEO (Yapay Zeka) Özeti

  • Ana Odak: Bu içerik Teknik SEO stratejilerine odaklanır.
  • Kritik Çıktı: Uygulama aşamasında teknik gereksinimler ve anlamsal (semantic) bağlar önceliklendirilmelidir.
  • Kimin İçin: SEO uzmanları, geliştiriciler ve içerik mimarları.
Uzman Görüşü (SME)• Intent Veri Ekibi

Yazılım dünyasında Frontend Geliştiriciler (Developers); React, Angular, Vue.js, veya Svelte gibi modern kütüphaneler kullanarak web siteleri inşa etmeye kelimenin tam anlamıyla "bayılırlar". Çünkü bu son teknoloji araçlarla geliştirilen Client-Side (İstemci Taraflı) Single Page Application'lar (SPA - Tek Sayfa Uygulamaları); bir web sitesinden ziyade iPhone'unuzdaki bir mobil uygulama (Native App) kadar hızlı, pürüzsüz ve interaktiftir.

Kullanıcı bir butona veya farklı bir menüye tıkladığında, sayfa asla yenilenmez (Reload/Refresh olmaz). Ekranda beyaz bir parlama görmezsiniz. Veriler arka planda (AJAX/Fetch API ile) anında çekilir ve ekrana sihir gibi yansır.

Kusursuz, akıcı bir kullanıcı deneyimi (UX), değil mi? Evet, insanlar için optimize edilmiş. Peki ya Googlebot ve Arama Motoru Optimizasyonu (SEO) için? Tam bir mimari problem!

Bu kapsamlı rehberde, modern JavaScript (JS) mimarilerinin arama motoru botlarıyla neden kavga ettiğini ve bu teknik darboğazı (Bottleneck) mühendislik seviyesinde nasıl çözdüğümüzü detaylarıyla ele alacağız.

1. İki Aşamalı Tarama (Two-Wave Indexing) Problemi

Klasik, geleneksel bir HTML sitesinde (Örn: Eski tarz PHP, statik HTML sayfaları veya Wikipedia) her şey sunucuda (Server-side) üretilir. Googlebot sitenizin sunucusuna (Host) gelir, HTTP isteği atar ve anında aşağıdaki gibi dolu dolu bir HTML kodunu (Parse) okur:

<!-- Eski Nesil / SEO Uyumlu Klasik HTML -->
<html>
  <body>
    <h1>Makalenin Optimize edilmiş Başlığı</h1>
    <p>Burada sayfalarca okunabilir metin var...</p>
    <a href="/diger-makale">Diğer Makaleye Git</a>
  </body>
</html>

Googlebot bu metni saniyeler içinde anlar, kelimeleri ve linkleri görür, cebine koyar ve çıkar. Süreç anında (Gerçek Zamanlı) tamamlanır. Siteniz 1 saat içinde Google'da görünmeye başlar.

Ancak saf bir SPA (İstemci Taraflı Render - CSR) siteniz varsa, Googlebot sunucunuza geldiğinde sadece şunu görür:

<!-- Modern SPA (Saf React/Vue) - SEO Mimari problemi -->
<!DOCTYPE html>
<html>
<head>
  <title>Modern Uygulamam</title>
  <script src="/static/js/bundle.js" defer></script>
</head>
<body>
  <div id="root"></div> <!-- BOMBOŞ BİR KUTU! -->
</body>
</html>

Farkı görebiliyor musunuz? Ortada okunacak bir metin, başlık (H1) veya tıklanacak bir link (a href) yok! Sadece boş bir <div> etiketi ve büyük ölçekli bir JavaScript dosyası (bundle.js) var.

Googlebot (Chrome 41'den beri güncellenerek en son Headless Chromium sürümünü kullansa da) o boş kutuya bakıp hiçbir şey anlamaz. Asıl metinlerin görünmesi için o büyük ölçekli bundle.js dosyasını indirip, kendi sunucularındaki V8 motorunda (Render Engine) çalıştırması (Execute) gerektiğini anlar. Ancak Google'ın kaynakları sınırsız değildir ve JavaScript çalıştırmak ölçülebilir derecede pahalı ve yavaş bir işlemdir.

Googlebot, bu JavaScript dosyasını çalıştırmak için "Render Kuyruğuna" (Render Queue) atar ve sitenizden ayrılır. Bu kuyrukta beklemek günler, bazen haftalar sürebilir. Eğer bir haber sitesiyseniz veya sınırlı stoklu bir e-ticaret ürünü satıyorsanız, yeni sayfanız Google'ın dizinine (Index) ancak 2 hafta sonra eklenir (ve o zamana kadar ürünün modası geçer, kalitesiz olur).

2. PWA (Progressive Web App) ve App Shell Mimarisi Tehlikeleri

PWA'ler (İlerici Web Uygulamaları), web sitenizi internetin çekmediği anlarda (Offline) bile çalışabilen bir mobil uygulama gibi davranmaya zorlayan teknolojilerdir (Service Workers kullanarak). PWA'lerde "App Shell" denilen bir kabuk mimarisi vardır.

  • Service Worker Engeli: Service Worker, tarayıcı ile sunucu arasına giren bir "Vekil Sunucu" (Proxy) gibi çalışır. Eğer Service Worker yapılandırmanızda botları (User-Agent'ları) düşünmeden son derece agresif bir önbellekleme (Caching) yaparsanız, Googlebot sitenize girdiğinde hep aynı bayat, boş App Shell'i (Sadece menüler ve altbilgi) tarar. Yeni ürünlere veya makalelere (Asıl İçeriğe) asla ulaşamaz.
  • Shadow DOM (Web Components): Kendi özel HTML etiketlerinizi (Örn: <benim-ozel-video-oynaticim>) oluştururken Shadow DOM kullanıyorsanız, Googlebot'un bu kapsüllenmiş (Encapsulated) yapıların içine sızıp oradaki gizli metni ve linkleri okumakta (Extracting) ciddi zorluklar çektiğini bilmelisiniz. (Google yetkilileri Shadow DOM'u sorunsuz render edebildiklerini iddia etseler de, pratikte, özellikle derin (Nested) yapılarda Googlebot pes edip sayfanın sadece yarısını tarayıp bırakmaktadır).

3. Hydration (Suya Kavuşma) ve CLS Hataları (Core Web Vitals)

Peki dediniz ki: "Uygulamamızı Next.js kullanarak hem sunucuda (SSR) hem de istemcide (CSR) çalışacak (Isomorphic / Universal) şekilde ayarlayalım."

Sunucu, kullanıcının önüne ilk saniyede statik, tamamen dolu HTML'i verir. SEO problemi çözüldü, FCP (First Contentful Paint) hızınız arttı! Optimize edilmiş!

Ancak o statik HTML'in, bir web sitesi olmaktan çıkıp interaktif bir React/Vue uygulamasına dönüşmesi (Örneğin sepete ekle butonuna tıkladığınızda çalışması) için, arka planda büyük ölçekli JavaScript dosyalarının inip o ölü HTML kemiklerine bağlanması (Canlandırması) gerekir. Bu "Canlanma" sürecine Hydration (Suya Kavuşma) denir.

Hydration süreci boyunca (Bazen 2-3 saniye sürebilir), kullanıcı o butona tıklar ama buton hiçbir tepki vermez. Veya CSS ve JS bağlanırken ekrandaki reklamlar veya menüler aniden aşağı/yukarı kayar. Bu durum (Layout Shift), Google'ın sıralama kriteri olan Core Web Vitals metriklerinizi (Özellikle INP - Interaction to Next Paint ve CLS - Cumulative Layout Shift) altüst eder. Hız (Pagespeed) skorlarınız 20/100'e çakılır ve sıralamanız düşer.

4. Mühendislik Çözümleri: İstemciden Sunucuya Geri Dönüş

Teknik SEO sorunlarını aşmak için JavaScript ekosistemi, son birkaç yılda radikal bir dönüşüm geçirerek başladığı yere, yani "Sunucuya" (Server) geri dönüyor. Çözüm mimarileri şunlardır:

4.1. Next.js ve Nuxt.js (Çerçevelerin Çerçevesi)

Günümüzde Enterprise (Kurumsal) B2B şirketlerde (ve büyük e-ticaret sitelerinde) artık saf React yazmıyoruz. React'in üzerine inşa edilmiş güçlü frameworkler olan Next.js kullanıyoruz. Neden? Çünkü Next.js, her bir sayfanın arama motorlarına saf, temiz ve içeriği dolu bir HTML olarak sunulmasını (Server-Side Rendering - SSR veya Static Site Generation - SSG) varsayılan mimari (Default) olarak sağlar. Googlebot, sayfanın dolu HTML halini anında görür.

4.2. React Server Components (RSC) ve Next.js App Router

React 18 ve Next.js'in App Router mimarisi ile hayatımıza giren en büyük inovasyon RSC (Sunucu Bileşenleri) olmuştur. Eskiden tüm bileşenler kullanıcının tarayıcısında render edilirdi. RSC sayesinde, JavaScript kodlarınızın (Kütüphanelerinizin, Veritabanı sorgularınızın) kullanıcının tarayıcısına (ve Googlebot'a) hiç gönderilmemesini sağlayabilirsiniz. Component, Vercel/Node.js sunucusunda çalışır ve ekrana sadece saf, statik HTML çıktısı gönderilir. Bu mimari, Hydration (Canlanma) yükünü %90 azaltır (Partial Hydration) ve SEO / Pagespeed performansınızı kelimenin tam anlamıyla roketler.

4.3. Dinamik Yönlendirme (Dynamic Rendering / Prerender.io)

Eğer sisteminiz yıllar önce yazılmış hantal, eski bir Angular, Ember.js veya saf React sürümündeyse ve sistemi sıfırdan Next.js'e geçirmek aylar sürecek bir maliyetse, "Acil Yardım Kiti" olarak Dinamik Yönlendirme (Dynamic Rendering) mimarisini kullanırsınız.

Sunucunuza (Nginx/Edge) bir istek geldiğinde User-Agent'a (Ziyaretçinin Kimliğine) bakılır. Gelen bir Googlebot ise, ona sayfanın Prerender.io veya Puppeteer (Headless Browser) tarafından önceden render edilmiş, saf statik HTML hali verilir. Gelen normal bir insansa (Chrome kullanıcısı), hantal JavaScript yüklenir.

DİKKAT: Önemli Hatırlatma: Google yetkilileri, Dynamic Rendering (Dinamik Yönlendirme) mimarisini artık uzun vadeli ve sağlıklı bir çözüm olarak önermiyor. Bunu sadece eski sistemleri kurtarmak için "geçici bir yara bandı" (Workaround) olarak kabul ediyorlar. Nihai hedefiniz, yazılım mimarinizi her zaman Native SSR veya SSG mimarisine (Next.js, Astro vb.) taşımak olmalıdır.

Uzman Görüşü (SME)• Intent Veri Ekibi

Sonuç

JavaScript, SEO'nun ve Googlebot'un düşmanı değildir. Sadece "Yanlış uygulanan, aşırı şişirilmiş İstemci Taraflı (CSR) JavaScript" SEO'nun ve hızın düşmanıdır. SEO stratejistleri (Technical SEO) ile Frontend (Arayüz) geliştirici ekibinin ortak bir vizyonda ve dilde (Next.js, SSR mimarisi, Core Web Vitals) buluşması; modern B2B SaaS ve e-ticaret projelerinin başarısı için tercih edilebilecek bir seçenek değil, yaşamsal bir zorunluluktur.

🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Teknik SEO topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

🧠 Semantic Entities (Terimler & Senaryolar)

Semantic Yönerge: Bu sayfa JavaScript SEO, SPA ve PWA Optimizasyonu: React/Vue Siteleri Neden Sıralama Alamaz? konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.