JavaScript ile üretilen içerikler eksik görülüyorsa ne yapılmalı?

JavaScript ile üretilen içerikler eksik görülüyorsa teşhise nereden başlanır?

2026 itibarıyla en doğru başlangıç hâlâ aynı: sorunu crawl, render ve index diye üçe ayırmak. Google Search Central’ın 2026-03-04 güncellenen JavaScript SEO dokümanı, Googlebot’un JavaScript sayfaları önce taradığını, sonra render kuyruğuna aldığını ve son aşamada indexlediğini açıkça söylüyor. Bu yüzden “Google içeriği görmüyor” cümlesi tek başına yeterli teşhis değildir; bazen sayfa hiç taranmıyordur, bazen taranır ama render sırasında ana metin geç gelir, bazen de içerik görünür olduğu hâlde canonical veya noindex yüzünden indexe girmez.

İlk pratik adım, ilgili URL’yi Search Console’da incelemektir. URL Inspection yardım sayfası, tek bir URL için crawl izni, page fetch, indexing allowed ve Google-selected canonical bilgisinin birlikte okunması gerektiğini gösterir. Bu ekran sana aynı anda şu soruların cevabını verir: robots.txt engeli var mı, sayfa 404 veya sunucu hatası veriyor mu, meta noindex basılıyor mu, Google bu URL’yi kopya mı görüyor? Teknik SEO’da zaman kaybı çoğu zaman bu temel dörtlüyü kontrol etmeden framework tartışmasına atlamaktan çıkar.

Buradan sonra asıl ayrım başlar: ana içerik ilk HTML’de mi geliyor, yoksa sonradan API çağrısıyla mı ekleniyor? Eğer kaynak HTML yalnızca uygulama kabuğunu taşıyor ve gerçek metin hydration sonrası ekleniyorsa, sorun doğrudan client side rendering bağımlılığıdır. Üstelik Google’ın 2025-12-18 güncellenen sorun giderme dokümanı, render ortamının sayfa yüklemeleri arasında local storage, session storage ve çerez durumunu korumayabileceğini hatırlatır. Yani içerik oturum, önceki gezinme veya kullanıcı etkileşimi bekliyorsa, tarayıcıda görünse bile arama motoruna eksik gidebilir.

İlk kontrol listesi

• HTTP durum kodu gerçekten 200 mü, yoksa uygulama kabuğu üstünde gizlenmiş 404 mü?
• robots.txt, meta robots veya X-Robots-Tag sayfayı engelliyor mu?
• Canonical doğru URL’yi mi işaret ediyor, yoksa başka varyanta mı kaçıyor?
• Ana metin ve başlık ilk HTML’de var mı, yalnızca API sonrası mı geliyor?
• JS ve CSS kaynakları render sırasında erişilebilir mi?
• Kimlik doğrulama, lokasyon izni veya kullanıcı aksiyonu olmadan içerik okunabiliyor mu?

Aynı URL’de üç görünüm testi: canlı sayfa, view-source ve rendered HTML

JavaScript SEO sorunlarında en verimli debug akışı, aynı URL’yi üç ayrı pencerede okumaktır: kullanıcının gördüğü canlı sayfa, view-source çıktısı ve rendered HTML. Search Console Help, başarılı bir URL için View crawled page veya View tested page ekranında HTML ile HTTP istek/yanıtlarının görülebileceğini söyler. Bu ayrım kritiktir; çünkü canlı DOM çoğu zaman geliştiriciyi rahatlatır, ama index sinyalini belirleyen şey çoğunlukla ilk HTML ve arama motorunun render sonrası elde ettiği çıktıdır.

Pratikte en sık gördüğümüz vaka şu oluyor: tarayıcıda H1, ürün açıklaması ve sık sorulan sorular bloku görünür; fakat view-source içinde yalnızca birkaç script etiketi ve boş bir uygulama kökü yer alır. Rendered HTML tarafında ise metnin bir kısmı gelmiştir ama title, meta description, canonical veya structured data eksik kalır. Bu tablo, “Google hiçbir şeyi görmüyor” değil, “Google bazı şeyleri görüyor ama kritik sinyaller aynı render anında üretilmiyor” anlamına gelir. Sorunun kökü çoğu zaman geciken API çağrısı, hydration hatası, istemci tarafında atılan exception veya koşullu render mantığıdır.

Neyi işaretlemelisin?

• İçerik farkı: H1, ilk paragraf, ürün açıklaması, kategori metni rendered HTML’de var mı?
• Meta farkı: title ve meta description JS sonrası değişiyor ama kaynakta boş mu?
• Canonical farkı: Canlı sayfa doğru URL’yi gösterirken rendered HTML başka varyanta mı dönüyor?
• Yapısal veri farkı: JSON-LD tarayıcıda oluşuyor ama render çıktısına düşmüyor mu?
• Link farkı: Gerçek a href bağlantıları yerine tıklama olayı mı kullanılıyor?

Bu testte yardımcı bir yan sinyal de JavaScript kapalı görünümüdür. Bu tek başına index kararı verdirmez; çünkü Google çoğu durumda JavaScript işleyebilir. Yine de no-JS görünümde ana metin tamamen kayboluyorsa, rendered HTML testini özellikle ciddiye almak gerekir. Eğer canlı sayfa ile rendered HTML birebir uyuşuyor ama URL hâlâ görünmüyorsa, artık konu rendering değil; keşfedilebilirlik, canonical seçimi, zayıf dahili linkleme veya indeksleme önceliği tarafına kayar.

İlgili video kaynak olarak Google Search Central kanalındaki Martin Splitt’in JavaScript SEO debugging anlatımları, ekip içi incelemelerde canlı DOM ile rendered HTML arasındaki farkı aynı terminolojiyle konuşmak için iyi bir referans oluşturur.

CSR, SSR, SSG, hydration ve prerendering arasında doğru seçim nasıl yapılır?

Buradaki temel karar, kritik SEO içeriğinin ne kadarını ilk HTML’de görmek istediğin sorusuna dayanır. web.dev’in 2026-01-05 güncellenen Rendering on the Web makalesi, server-side rendering ve static rendering yaklaşımlarını performans ve SEO açısından hâlâ güçlü varsayılanlar olarak konumlandırıyor. Eğer sayfanın görevi ürün, kategori, blog veya landing page görünürlüğü üretmekse; ana metni, başlıkları, dahili linkleri ve temel yapılandırılmış veriyi ilk HTML’de sunmak çoğu zaman en güvenli yoldur.

Saf CSR, uygulama ekranları ve oturum sonrası alanlar için makul olabilir; ancak organik görünürlük beklenen URL’lerde gereksiz risk taşır. SSR, istek anında tam HTML üretir; sık değişen ürün ve kategori sayfalarında güçlüdür. SSG, blog ve rehber içeriklerde daha basit bir yapı sunar. Hydration, sunucudan gelen HTML’yi etkileşimli hâle getirir; içerik ağırlıklı ama filtreleme, favorileme, karşılaştırma gibi istemci etkileşimi isteyen sayfalarda dengeli çözümdür. Prerendering ise sınırlı rota sayısına sahip pazarlama sayfaları ve SPA landing’lerde pratik bir ara yol olabilir. Tanımlar arasında hızlı bir hatırlatma gerekiyorsa SEO terimleri sözlüğü ekip içi hizalamayı kolaylaştırır.

Dynamic rendering tarafında ise yorum netleşmiş durumda. Google’ın 2025-12-10 güncellenen dokümanı, dynamic rendering’i uzun vadeli önerilen mimari değil, workaround olarak tanımlar ve ek karmaşıklık getirdiğini söyler. Yani botlara ayrı, kullanıcılara ayrı sunum mantığı yalnızca geçiş döneminde düşünülmeli; kalıcı varsayılan olarak değil. React tarafında çoğu içerik URL’si için Next.js ile SSR veya SSG, Vue tarafında Nuxt, Angular tarafında ise SSR veya hybrid render düzeni genelde daha güvenli seçimdir. Uygulama ekranını CSR bırakıp indekslenmesi gereken sayfaları SSR veya prerender ile sunmak da sık kullanılan hibrit çözümdür.

Kararı verirken şu kısa kural işe yarar: arama trafiği beklediğin her URL, kullanıcıdan önce HTML üretmeli. İçerik neredeyse hiç değişmiyorsa SSG, sık değişiyor ama herkese açıksa SSR, rota sayısı sınırlıysa prerender, yoğun etkileşim gerekiyorsa hydration en mantıklı çerçeveyi kurar. Böylece “server side rendering SEO için gerekli mi” sorusunu soyut değil, URL bazlı cevaplamış olursun.

SPA sorunları: hash routing, lazy-load, infinite scroll ve soft 404

SPA mimarisinde ilk kırılma noktası routing’tir. Google Search Central, Google’ın bağlantıları güvenilir biçimde keşfedebilmesi için gerçek a href öğeleri gerektiğini; Google’ın JavaScript sorunlarını düzeltme rehberi ise farklı içerik yüklemek için URL parçalarına güvenilmemesi ve bunun yerine History API kullanılması gerektiğini söyler. Kısacası #/kategori/urun gibi hash tabanlı yapılar yerine benzersiz, doğrudan açılabilir URL’ler ve gerçek HTML linkleri kullanmak gerekir.

İkinci büyük risk, etkileşime bağlı içerik yükleme modelidir. Ana metin yalnızca sekmeye tıklayınca, kullanıcı aşağı kaydırınca veya filtre açınca geliyorsa arama motoru bu içeriği geç ya da eksik görebilir. Infinite scroll kurulumunda ilk parti içeriği ilk HTML veya erken render aşamasında sunmak, sonraki partiler için de ayrı URL’ler ya da paginated keşif mantığı oluşturmak daha güvenlidir. Aynı şekilde önemli metni yalnızca local storage durumuna, önceki sayfadan gelen veri taşımasına veya istemci önbelleğine bağlamak da risklidir; render ortamı bu durumu her zaman yeniden üretmeyebilir.

• Hash routing yerine History API kullanın ve her görünüm için gerçek URL üretin.
• Lazy-load yalnızca görsel veya ikincil bloklarda kalsın; ana metin ertelenmesin.
• Infinite scroll varsa alt içeriklerin keşfedilebilir URL veya link karşılığı olsun.
• Gerçek linkler için onclick yerine a href yapısını koruyun.

Üçüncü kırılma noktası, hata ve erişim yönetimidir. Google’ın resmi dokümanı, SPA’lerde soft 404 riskinin özellikle yüksek olduğunu ve hata durumunda yanlışlıkla 200 dönülmesinin sorun yarattığını açıkça vurgular. Bir ürün yoksa gerçek 404 döndürmek, mümkün değilse noindex eklemek gerekir. Kimlik doğrulama duvarı arkasındaki içerik zaten herkese açık değilse indekslenmemesi normaldir; fakat kamuya açık bir sayfa login yönlendirmesi, 401, 403 veya uygulama içi boş durum arasında savruluyorsa sorun SEO değil uygulama akışıdır. Burada amaç botu kandırmak değil, kullanıcıya ve arama motoruna aynı URL için tutarlı durum kodu ve tutarlı içerik vermektir.

Düzeltme sonrası doğrulama, izleme ve SEOYEN ile operasyonel takip

Düzeltme yayınlandıktan sonra iş bitmiş sayılmaz. Aynı URL için yeniden rendered HTML testi yapmalı, Page Indexing durumunu izlemeli, sitemap keşfini ve dahili link akışını kontrol etmelisin. Search Console tarafında URL Inspection, son crawl tarihi ve canonical kararı yeniden okunmalı; eksik sayfa varsa site: sorgusu ve dahili link keşfiyle birlikte düşünülmelidir. Burada odak, “kod deploy edildi” değil, “Google artık doğru HTML’yi gördü mü” sorusudur.

Operasyonel tarafta bu takip dağınık yürüdüğünde sorunlar tekrar eder. Bu yüzden teknik ekipler, canonical sapmaları, noindex sızıntıları, 404 kümeleri ve zayıf HTML çıktısı işaretlerini toplu görmek ister. Bu noktada site sağlığı taraması ile hata kümelerini toplamak, sıralama takibi paneli ile düzeltmenin organik etkisini gözlemek ve AI görünürlük analizi ile içeriğin yapay zekâ yüzeylerinde nasıl yansıdığını ayrı ayrı izlemek daha net bir operasyon sağlar. Teknik düzeltmenin sıralamaya, snippet görünümüne ve keşfedilebilirliğe nasıl döndüğünü tek ekranda görmek karar kalitesini artırır.

Ahrefs ve SEMrush gibi platformlar geniş SEO iş akışları için sık kullanılan referanslardır; ancak Türkiye’de küçük ekipler için araçların tek tek dağılması ayrı bir operasyon yükü yaratır. SEOYEN bu ihtiyacı tek platformda toplayan, Türkçe arayüz sunan, TL bazlı fiyatlandırma kullanan ve yerel destekle ilerleyen bir yapı kurar. Bu fark özellikle teknik SEO ile içerik takibini aynı akışta yürütmek isteyen ekiplerde pratikleşir. Paket yapısını görmek gerekiyorsa sabit rakam yerine fiyatlandırma sayfası üzerinden güncel plan mantığına bakmak daha doğru olur.

Daha karşılaştırmalı bakmak istersen Ahrefs ve SEMrush sayfaları, teknik takip ihtiyaçlarını Türkiye pazarına uygun operasyonel çerçevede değerlendirmek için yararlı olur. Buradaki amaç araç yarıştırmak değil; rendered HTML, indeksleme ve görünürlük takibini ekip gerçekliğine en az sürtünmeyle oturtmaktır.

Adım Adım JavaScript içerik görünürlüğünü teşhis ve düzeltme akışı

JavaScript ile yüklenen içerik Google tarafından eksik görülüyorsa dağınık denemeler yerine tek bir tekrar edilebilir akış kullanmak gerekir. Aşağıdaki sıra, hem geliştirici hem SEO uzmanı tarafında ortak çalışma zemini kurar ve sorunun gerçekten render kaynaklı mı, yoksa indeksleme veya keşif problemi mi olduğunu kısa sürede ayırır.

1. URL Inspection ile mevcut durumu doğrula. İlgili URL için page indexing, crawl allowed, indexing allowed, page fetch ve canonical alanlarını tek ekranda oku. Live test çalıştır ve son crawl tarihini not al. Amaç, sorunun daha render aşamasına gelmeden robots, noindex, canonical veya durum kodu tarafında mı takıldığını netleştirmektir.
2. Canlı sayfa ile kaynak HTML’i karşılaştır. Tarayıcıda gördüğün H1, giriş paragrafı, ürün açıklaması, dahili linkler ve önemli schema alanlarını view-source ile kıyasla. Eğer kaynak HTML neredeyse boşsa ve gerçek içerik yalnızca istemci tarafında oluşuyorsa, kritik SEO sinyallerini JavaScript kuyruğuna bıraktığını kabul etmen gerekir.
3. Rendered HTML farklarını işaretle. Search Console’daki View tested page veya View crawled page görünümünde eksik kalan metin, canonical, title, meta description ve structured data parçalarını tek tek not et. Böylece “hiç görünmüyor” ile “kısmen görünüyor ama eksik sinyalle gidiyor” durumlarını ayırırsın. Bu ayrım düzeltme önceliğini belirler.
4. Uygun rendering modelini seç. Sorun ana metnin geç gelmesiyse SSR, SSG veya prerendering’e geç; sorun link keşfi ise routing ve a href yapısını düzelt; sorun soft 404 ise durum kodlarını netleştir. Dynamic rendering yalnızca geçici geçiş çözümü olarak düşünülmeli, kalıcı mimari tercih olarak değil.
5. Düzeltmeyi yeniden test edip izlemeye al. Yayın sonrası aynı URL’yi yeniden test et, rendered HTML artık tam mı bak, ardından Request indexing ve rutin izleme adımlarına geç. Sonraki haftalarda index kapsaması, sıralama değişimi, snippet görünümü ve crawl davranışı birlikte okunursa düzeltmenin gerçek etkisi netleşir.

Bu akışın değeri, ekip içi tartışmayı “Google JavaScript’i anlar mı” gibi genel sorulardan çıkarıp “bu URL’de hangi sinyal hangi aşamada kayboluyor” seviyesine indirmesidir. O noktadan sonra çözüm genelde netleşir: daha güçlü ilk HTML, daha tutarlı routing, daha doğru durum kodu ve daha disiplinli doğrulama.

Sıkça Sorulan Sorular