JavaScript SEO, içeriğini tarayıcıda JavaScript ile oluşturan sitelerin Google tarafından eksiksiz taranması, render edilmesi ve dizine eklenmesi için yapılan teknik çalışmaların bütünüdür. React, Vue, Angular veya Next.js ile geliştirilen modern bir site, kullanıcıya uygulama akıcılığında bir deneyim sunar; ama aynı mimari, arama motoruyla sitenin arasına görünmez bir katman koyar. Kullanıcının ekranında dopdolu duran bir sayfa, Google'ın ilk baktığı anda boş bir HTML iskeletinden ibaret olabilir.
Bunu neden umursamalısınız? Çünkü Google sıralamayı gördüğü içerik üzerinden yapar. Render edilemeyen bir ürün açıklaması, geç yüklenen bir kategori listesi ya da JavaScript'e gömülü bir başlık, sizin için var ama dizin için yok demektir. Üstelik sorun sinsidir: site tarayıcıda kusursuz çalıştığı için ekip her şeyin yolunda olduğunu düşünür; belirti çoğu zaman aylar sonra, organik trafik beklenenin altında kaldığında fark edilir. 2026'da tablo daha da netleşti: AI Overviews yaygınlaştı ve yapay zekâ destekli arama araçları cevaplarını taranabilir içerikten üretiyor — bu botların önemli bir bölümü ise JavaScript çalıştırmıyor. İçeriğiniz sunucudan gelmiyorsa yalnızca klasik arama sonuçlarında değil, yapay zekâ özetlerinde de görünmez olursunuz.
Bu yazıyı bir sorun giderme rehberi olarak kurguladık: önce Google'ın JavaScript'i nasıl işlediğine, sonra CSR, SSR ve SSG mimarilerinin risk profillerine bakacağız; ardından belirtilerden teşhise geçip React ve Next.js sitelerde en sık karşılaşılan hataları çözümleriyle birlikte ele alacağız.
Google JavaScript'i nasıl işler: tarama, render, dizine ekleme
Klasik bir HTML sayfada süreç yalındır: Googlebot sayfayı indirir, metni okur, bağlantıları çıkarır, dizine ekler. JavaScript ağırlıklı sayfalarda araya bir aşama daha girer: render. Google Search Central dokümantasyonunun tanımladığı akış üç adımdan oluşur. Googlebot önce URL'yi tarar ve sunucunun döndürdüğü ilk HTML'i alır. İçerik bu HTML'de yoksa sayfa render kuyruğuna girer; Google'ın Web Rendering Service (WRS) adını verdiği ve 2019'dan beri güncel Chromium sürümü üzerinde çalışan render altyapısı, sayfayı gerçek bir tarayıcı gibi açar, JavaScript'i çalıştırır ve ortaya çıkan DOM'u dizine ekleme sistemine iletir.
Kâğıt üzerinde bu, "Google JavaScript'i zaten çalıştırıyor, sorun yok" diye okunabilir. Pratikte üç risk vardır. Birincisi zamanlama: render, taramayla eşzamanlı gerçekleşmez, kuyruğa girer. Google çoğu sayfanın dakikalar içinde render edildiğini söylüyor; ancak bu bir ortalamadır, garanti değildir ve yoğun dönemlerde ya da büyük sitelerde gecikme uzayabilir. İkincisi maliyet: JavaScript çalıştırmak, düz HTML okumaya göre kat kat fazla işlem gücü ister. Google hiçbir siteye sınırsız kaynak ayırmaz; on binlerce URL barındıran bir sitede bu, bazı sayfaların geç render edilmesi ya da tarama önceliğini hiç alamaması anlamına gelebilir. Üçüncüsü kırılganlık: render sırasında bir JavaScript hatası oluşursa, kritik bir API isteği zaman aşımına uğrarsa veya gerekli bir kaynak engellenmişse Google sayfanın eksik hâlini dizine ekler ve size bunu ayrıca haber vermez.
Bir de sık atlanan güncel bir gerçek var: Google render yapabiliyor olsa da, cevap üreten yapay zekâ tarayıcılarının çoğu ilk HTML ile yetinir. Sunucudan içerik göndermeyen bir site, bu sistemlerin gözünde büyük ölçüde boştur. Arama davranışının yapay zekâ araçlarına doğru genişlediği bir dönemde bu, göz ardı edilemeyecek bir görünürlük kaybıdır; konunun stratejik boyutunu yapay zekâ aramalarında SEO yazımızda ayrıntılı işledik. Bu tabloya bakınca temel ilke kendiliğinden ortaya çıkıyor: dizine girmesini istediğiniz içerik, JavaScript'in insafına bırakılmamalı, ilk HTML'de var olmalıdır.
CSR, SSR, SSG: aynı içerik, üç farklı teslimat şekli
JavaScript SEO sorunlarının kökeninde neredeyse her zaman aynı soru yatar: HTML nerede üretiliyor? Cevap üç ana mimariden biridir ve her birinin risk profili farklıdır.
İstemci tarafı render (CSR)
Saf React veya Vue uygulamalarının varsayılan davranışıdır. Sunucu, neredeyse boş bir HTML kabuğuyla birlikte büyük bir JavaScript paketi gönderir; içerik tarayıcıda kod çalıştıktan ve genellikle bir API'den veri çekildikten sonra oluşur. Kullanıcı için sorun yoktur ama arama motoru için en riskli senaryodur: ilk HTML'de ne başlık ne metin ne bağlantı vardır. Dizine girmek tamamen render aşamasının sorunsuz tamamlanmasına bağlıdır; JavaScript çalıştırmayan botlar içinse sayfa fiilen yoktur.
Sunucu tarafı render (SSR)
HTML her istekte sunucuda üretilir; tarayıcıya da bota da içerik dolu bir sayfa gider. Next.js ve Nuxt gibi çatıların temel vaadi budur ve SEO açısından en güvenli yaklaşımdır: içerik, Google'ın render aşamasını beklemeden ilk HTML'de hazırdır. Bedeli, her istekte oluşan sunucu yükü ve doğru kurgulanmadığında uzayan yanıt süresidir. SSR'ın işi tamamen bitirmediğini de bilmek gerekir: sayfa tarayıcıda "hydration" denen süreçle etkileşimli hâle getirilir ve ağır JavaScript paketleri bu aşamada kullanıcı deneyimi metriklerini aşağı çeker.
Statik üretim (SSG) ve artımlı yenileme (ISR)
Sayfalar derleme anında HTML olarak üretilir ve CDN'den servis edilir. Blog, dokümantasyon, kurumsal sayfalar ve nadiren değişen açılış sayfaları için hem en hızlı hem en güvenli seçenektir; render edilecek bir şey kalmaz, sunucu maliyeti neredeyse sıfırdır. İçeriği sık değişen büyük sitelerde ise Next.js'in ISR (Incremental Static Regeneration) yaklaşımı, statik sayfaları belirli aralıklarla arka planda yenileyerek güncellik ile hız arasındaki gerilimi çözer.
Pratik kural şudur: organik trafik beklediğiniz her sayfa — ana sayfa, kategori, ürün, blog — SSR veya SSG ile sunulmalıdır. Giriş gerektiren panel, sepet ve hesap ekranları gibi dizine girmesi gerekmeyen alanlarda CSR tamamen meşrudur. Sorun mimarilerin kendisinden değil, tek mimariyi ayrım yapmadan her yere uygulamaktan çıkar. Bu arada Google'ın yıllarca geçici çözüm olarak andığı "dynamic rendering" (botlara ayrı, kullanıcılara ayrı sürüm sunma) yaklaşımını artık uzun vadeli bir çözüm olarak önermediğini de not edelim; güncel tavsiye sunucu tarafı render veya statik üretimdir.
Belirtiden teşhise: sorununuz hangisi?
Sorun giderme belirtiyi doğru okumakla başlar. Aşağıdaki listeyi bir eşleştirme tablosu gibi kullanın:
- site: aramasında tüm sayfalar aynı başlıkla listeleniyorsa meta etiketleriniz büyük olasılıkla yalnızca istemcide yazılıyor.
- Ana sayfa dizindeyken kategori ve detay sayfaları dizine girmiyorsa iç bağlantılarınız gerçek href üretmiyor olabilir; Google sayfaları keşfedemiyordur.
- Search Console'da "Tarandı – şu anda dizine eklenmedi" satırı kabarıksa render sonrası içerik zayıf bulunuyor ya da render maliyeti sayfanın algılanan değerini aşıyor olabilir.
- Sayfa dizinde ama snippet'te eksik veya alakasız metin görünüyorsa içeriğin bir bölümü render edilemiyordur.
- Görselleriniz Google Görseller'de hiç çıkmıyorsa lazy loading uygulamanız botun göremediği bir yöntemle çalışıyordur.
- Olmayan URL'ler Search Console'da "soft 404" olarak işaretleniyorsa uygulamanız her adrese 200 durum kodu döndürüyordur.
Bu belirtilerin her biri, aşağıdaki yedi hatadan birine işaret eder.
React ve Next.js sitelerde en sık görülen yedi hata ve çözümleri
1. İçeriğin yalnızca istemcide oluşması
En yaygın ve en pahalı hata. Veri useEffect içinde çekiliyor, bileşen dynamic import ile ssr: false olarak yükleniyor ya da içerik bir istemci durumuna bağlı; sonuçta ilk HTML'de ana metin yok. Örnek bir senaryo üzerinden düşünelim: 5.000 ürünlü bir e-ticaret sitesi ürün açıklamalarını istemcide bir API'den çekiyor olsun. API'nin yavaş yanıt verdiği ya da hata döndürdüğü her render denemesinde Google o ürün sayfasını içeriksiz görür; birkaç ay içinde dizindeki sayfa sayısı ile sitedeki sayfa sayısı arasında binlerle ifade edilen bir makas açılabilir. Çözüm: Next.js App Router'da bileşenler varsayılan olarak sunucuda render edilir; veri çekme işlemini sunucu bileşenlerine taşıyın. "use client" ve ssr: false yalnızca gerçekten etkileşimli, dizine girmesi gerekmeyen parçalara ayrılmalıdır. Basit test: sayfa kaynağını görüntülediğinizde ana içerik metnini okuyabiliyor olmalısınız.
2. href üretmeyen bağlantılar
Googlebot yalnızca href özniteliği taşıyan bağlantı etiketlerini izler. Bir div'e eklenen onClick ile router.push çağırmak kullanıcı için bağlantıdır, bot için ölü noktadır; Google butonlara tıklamaz, form doldurmaz. Aynı şekilde hash tabanlı yönlendirme (site.com/#/urunler gibi adresler) Google'ın gözünde ayrı sayfa oluşturmaz; kare işaretinden sonrası dizin açısından yok sayılır. Çözüm: Next.js'in Link bileşeni doğal olarak href üretir, onu kullanın; özel tıklama davranışı gerekiyorsa bile geçerli bir href mutlaka bulunmalı, yönlendirme geçmişi API'siyle (history API) gerçek URL'ler üzerinden çalışmalıdır.
3. Meta etiketlerin ve canonical'ın istemcide yazılması
Başlık, açıklama, canonical ve robots yönergeleri react-helmet benzeri araçlarla yalnızca tarayıcıda ekleniyorsa Google bunları ancak render sonrasında görür; JavaScript çalıştırmayan botlar hiç görmez. Daha kritik bir nüans var: Google'ın dokümantasyonuna göre ilk HTML'de noindex bulunan bir sayfa render aşamasına hiç alınmaz. Yani "noindex'i JavaScript ile kaldırırız" yaklaşımı çalışmaz; sayfa daha JavaScript çalışmadan elenir. Çözüm: tüm meta etiketleri sunucudan gönderin — Next.js'te Metadata API bu işi sayfa bazında, sunucu tarafında çözer.
4. robots.txt ile JavaScript ve CSS dosyalarını engellemek
Eski nesil sitelerden kalma bir alışkanlık, modern sitelerde ağır sonuç doğurur: /assets, /static veya /_next gibi dizinler robots.txt ile engellenirse WRS sayfayı render edemez ve içeriği eksik ya da bozuk görür. Google Search Central'ın uyarısı açıktır: render için gereken kaynaklar taranabilir olmalıdır. Ek bir ayrıntı olarak WRS, JavaScript dosyalarını agresif biçimde önbelleğe alır; sürüm değişikliklerinin fark edilmesi için dosya adlarında içerik karması (hash) kullanmak en sağlıklı yoldur — modern derleme araçları bunu zaten varsayılan yapar. Çözüm: robots.txt'teki JS/CSS engellerini kaldırın ve Search Console'un URL denetimi aracıyla engellenen kaynak kalıp kalmadığını doğrulayın.
5. Soft 404: olmayan sayfanın 200 dönmesi
CSR uygulamalarda sunucu her URL'ye aynı uygulama kabuğunu 200 durum koduyla döndürür; "Ürün bulunamadı" mesajı istemcide üretilir. Google, durum kodu 200 olduğu hâlde hata içeriği taşıyan bu sayfaları soft 404 olarak işaretler. Sayı büyüdükçe tarama bütçesi olmayan sayfalara harcanır ve sitenin genel kalite algısı zedelenir. Çözüm: hata durumlarını sunucuda çözün. Next.js'te notFound() çağrısı gerçek bir 404 döndürür; kalıcı olarak kaldırılan içerik için 410, taşınan içerik için 301 kullanın.
6. Etkileşime saklanan içerik
Googlebot tıklamaz, kaydırmaz, form doldurmaz; sayfayı uzun bir görüntü alanıyla render eder ve DOM'da o anda ne varsa onu görür. "Daha fazla yükle" butonuyla gelen ürünler, yalnızca tıklanınca DOM'a eklenen sekme içerikleri ve sonsuz kaydırmayla beslenen listeler botun erişemediği içeriktir. Çözüm: sonsuz kaydırmayı sayfalandırılmış URL'lerle destekleyin; her dilimin kendi adresi ve önceki/sonraki bağlantıları olsun. Sekme ve akordeon içeriklerini ise DOM'a baştan koyup CSS ile gizleyebilirsiniz: render edilen DOM'da mevcut olan içerik, görsel olarak gizli olsa da dizine eklenir.
7. Hydration yükünün Core Web Vitals'ı çökertmesi
SSR'a geçmek render sorununu çözer ama megabaytlarca JavaScript göndermeyi çözmez. Şişkin paketler LCP'yi geciktirir, hydration sırasındaki uzun görevler INP'yi bozar; Core Web Vitals ise hem Google'ın sayfa deneyimi sinyalidir hem de dönüşüm oranını doğrudan etkiler. Kaba bir hesap: 4G bağlantıda saniyede yaklaşık 1,5 MB indirilebildiğini varsayarsak, 900 KB'lık bir JavaScript paketi yalnızca inişte yarım saniyeden fazla yer; buna ayrıştırma ve çalıştırma süresi eklenince orta segment bir telefonda etkileşim gecikmesi kolayca 1-2 saniyeyi bulur. Çözüm: kod bölme (code splitting), kullanılmayan bağımlılıkları ayıklama ve etkileşim gerektirmeyen bileşenleri sunucu bileşeni olarak bırakma. Ölçüm ve iyileştirme adımları için Core Web Vitals rehberimize bakabilirsiniz.
Beş adımda teşhis: Google'ın gözünden sitenize bakın
Bu hataların sitenizde bulunup bulunmadığını anlamak için pahalı araçlara gerek yok; aşağıdaki beş adım sorunların büyük bölümünü ortaya çıkarır:
- URL denetimi yapın: Search Console'da URL Denetimi aracını açın, "Taranan sayfayı görüntüle" seçeneğiyle Google'ın render ettiği HTML'e ve ekran görüntüsüne bakın. Ana içerik orada yoksa sorun kesinleşmiştir. Aracın ayrıntılı kullanımını Search Console rehberimizde anlattık.
- İlk HTML'i kontrol edin: Sayfada "kaynağı görüntüle" deyin ve ana metinden bir cümleyi aratın. Kaynakta yoksa içerik istemcide üretiliyor demektir.
- JavaScript'i kapatın: Tarayıcı ayarlarından JavaScript'i devre dışı bırakıp siteyi gezin. Gördüğünüz tablo, JavaScript çalıştırmayan botların gördüğüne en yakın tablodur.
- site: araması yapın: Google'da site:alanadiniz.com sorgusuyla dizindeki sayfaların başlık ve açıklamalarının sayfaya özgü olup olmadığını kontrol edin.
- Dizine ekleme raporunu okuyun: Search Console'un sayfa dizine ekleme raporunda "Tarandı – şu anda dizine eklenmedi" ve "Bulundu – şu anda dizine eklenmedi" gruplarının hangi URL kalıplarında yığıldığını inceleyin; kalıp size hatanın adresini verir.
Bu testler sorunun varlığını gösterir; kök nedeni bulup önceliklendirmek içinse sistematik bir denetim gerekir. Teknik SEO kontrol listemiz, render sorunlarını tarama bütçesi, site mimarisi ve durum kodlarıyla birlikte ele alan geniş çerçeveyi sunar.
Sonuç: Google ile anlaşmak bir çeviri işidir
Modern JavaScript çatıları ile arama motorları arasındaki ilişki bir uyumsuzluk değil, bir çeviri meselesidir. Google JavaScript'i işleyebilir; ama gecikmeli, maliyetli ve koşullu işler. Yapay zekâ tarayıcılarının çoğu ise hiç işlemez. Kural bu yüzden nettir: trafik beklediğiniz her sayfanın içeriği, meta etiketleri ve bağlantıları ilk HTML'de var olmalıdır. CSR'ı etkileşimli alanlara saklamak, kritik sayfaları SSR veya SSG ile sunmak ve düzenli render denetimi yapmak bu sözleşmenin üç maddesidir.
İyi haber şu: JavaScript SEO sorunları doğru teşhis edildiğinde çoğunlukla sınırlı sayıda mimari kararla çözülür ve çözüm site genelinde etki gösterir. Zor kısım, tarayıcıda kusursuz görünen bir sitede sorunun var olduğunu fark edebilmektir; bunun için Google'ın gözünden bakmayı bilmek gerekir.
Welda'da SEO ekibimiz bu bakışı geliştirici perspektifiyle birleştiriyor: React ve Next.js projelerinde render denetimi yapıyor, hangi sayfanın SSR hangi sayfanın SSG ile sunulması gerektiğini veriyle gerekçelendiriyor ve bulguları geliştirme ekibinizin doğrudan uygulayabileceği teknik görevlere çeviriyoruz. Bu çalışmayı SEO danışmanlığı hizmetimiz kapsamında, ölçülebilir bir yol haritasına bağlıyoruz. Sitenizin Google'a gerçekte nasıl göründüğünü merak ediyorsanız iletişime geçin; mevcut durumu somut bulgularla birlikte ortaya koyalım.