JavaScript ile yüklenen içerikler eksikse nasıl teşhis edilir

Sorunu doğru adlandırın: crawl, render ve index ayrımını kurun

JavaScript ile yüklenen bir sayfada içerik eksik görünüyorsa ilk hata, tüm problemi tek kelimeyle indeksleme sorunu diye etiketlemektir. Oysa Google, JavaScript sayfaları tarama, render ve indeksleme olarak üç ayrı aşamada işler. Google Search Central’ın JavaScript SEO Basics dokümanı bu ayrımı açık biçimde anlatır: URL bulunabilir, HTML indirilebilir, fakat içerik ancak render aşamasında görünür hale gelebilir. Bu yüzden sorun bazen keşifte, bazen kaynak erişiminde, bazen de son HTML üretiminde oluşur.

Belirtileri doğru okumak teşhisi kısaltır. Metin görünmüyorsa çoğu zaman render zinciri kırılmıştır. İç linkler görünmüyorsa client-side routing ya da JavaScript ile sonradan enjekte edilen bağlantılar yeterince erken oluşmuyor olabilir. Meta description, canonical veya noindex etiketleri farklı görünüyorsa sorun yalnızca içerik değil, başlık ve yönerge katmanına da taşınmıştır. Özellikle canonical ve noindex sinyallerinin JavaScript ile değiştirilmesi, aynı URL’nin kullanıcıya normal görünmesine rağmen arama motoruna zayıf veya yanlış sürüm gönderebilir.

2026’da teşhis yaklaşımı daha disiplinli olmak zorunda. Çünkü güncel dokümanlarda WRS, canlı test, son tarama tarihi ve Google-seçimli canonical bilgisinin birlikte yorumlanması öne çıkıyor. WRS kavramını hızlıca netleştirmek isterseniz WRS terimi için sözlük faydalı bir referanstır. Ayrıca Search Console URL Inspection yardımında canlı test verisinin indeks verisinden ayrı olduğu açıkça belirtilir; yani canlı testte görünen temiz sonuç, indekslenmiş sürümün de mutlaka doğru olduğu anlamına gelmez.

• Crawl belirtisi: URL bulunmuyor, son tarama tarihi boş, iç link keşfi zayıf.
• Render belirtisi: Ham HTML eksik, rendered HTML kısmi, son DOM tam.
• Index belirtisi: İçerik render edilmiş olsa da canonical, noindex veya kalite sinyali devreye giriyor.

Aynı URL’yi üç görünümde karşılaştırın: ham HTML, rendered HTML ve son DOM

JavaScript SEO teşhisinde en yararlı pratik, aynı URL’yi üç farklı görünümde yan yana açmaktır: view-source ile görülen ham HTML, Search Console veya benzer testlerde görülen rendered HTML ve tarayıcı tamamen sakinleştikten sonra inspect panelinde gördüğünüz son DOM. Bu üçü aynı şey değildir. Ham HTML, sunucunun ilk cevabıdır. Rendered HTML, arama motorunun JavaScript çalıştırdıktan sonra değerlendirdiği çıktıdır. Son DOM ise kullanıcının tarayıcısında, ek istekler ve etkileşimler sonrasında ortaya çıkan en geç sürümdür.

Teknik denetimlerde sık gördüğümüz desen şu olur: view-source içinde yalnızca başlık, birkaç boş konteyner ve temel meta etiketleri vardır; tarayıcıda birkaç saniye sonra ürün açıklaması, iç link bloğu ve SSS açılır; fakat Search Console rendered HTML sürümünde bu blokların yalnızca bir kısmı görünür. Bu mini vaka, problemin kullanıcı tarafında çözüldüğünü ama arama motorunun render penceresinde tamamlanmadığını gösterir. Yani sayfa çalışıyor gibi görünür, fakat SEO açısından eksik işleniyordur.

Mini vaka: hangi katmanda ne kayboluyor?

Örneğin kategori sayfasında filtre açıklaması yalnızca son DOM’da varsa, bu blok büyük olasılıkla gecikmeli API çağrısı veya hydration sonrası ekleniyordur. İç link kartları ham HTML’de yok, rendered HTML’de de yok, ama son DOM’da varsa sorun keşif tarafını etkiler. Canonical etiketi ham HTML’de doğru, son DOM’da farklıysa JavaScript sonradan gereksiz bir yeniden yazım yapıyor olabilir. Google’ın JavaScript sorun giderme dokümanı tam bu nedenle loaded resources, console output ve rendered DOM karşılaştırmasını önerir.

• Yalnız ham HTML’de eksik: Sunucu ilk yanıtı zayıf veriyor, SSR veya ön işleme düşünülmeli.
• Ham HTML’de eksik, rendered HTML’de var: Google içeriği görebilir; sorun indeksleme veya kalite katmanında olabilir.
• Rendered HTML’de eksik, son DOM’da var: En tipik JavaScript SEO kırılması budur.
• Üç katmanda da eksik: Sorun veri kaynağı, erişim, yönlendirme veya yanlış URL eşlemesidir.

Bu karşılaştırmayı ekran görüntüsü ve kısa bir tablo mantığıyla belgelemek ekip içi iletişimi de hızlandırır. Geliştiriciye “Google görmüyor” demek soyut kalır; ama “ürün açıklaması yalnızca son DOM’da var, rendered HTML’de yok” derseniz hata sınıfı anında daralır. Özellikle React CSR, Next.js client bileşenleri veya Vue/Nuxt route geçişlerinde bu netlik kritik fark yaratır.

Adım adım teşhis akışı: URL Inspection, canlı test ve tam metin kontrolü

Tek URL teşhisinde referans ekran URL Inspection olmalı. İlk bakacağınız sıra şu olsun: Indexing allowed, Page fetch, Last crawl ve Google-selected canonical. Search Console’un tekil sayfa yardımına göre bu alanlar, URL’nin Google dizinindeki gerçek durumunu gösterir; canlı test ise ayrı bir veri kaynağıdır ve doğrudan arama sonucunda kullanılan sürüm değildir. Bu ayrım 2026’da daha da önemli, çünkü birçok ekip canlı testi temiz görünce indeks sürümünü de temiz varsayıyor.

Sonra Test Live URL ile canlı sürüme geçin. Burada yüklenmeyen resource dosyaları, JavaScript console hataları, erişilemeyen API çağrıları ve render farkları daha görünür hale gelir. Google’ın 2025-12-18 güncellenen sorun giderme rehberi, URL Inspection veya Rich Results Test içinde loaded resources, JavaScript console output ve rendered DOM incelemesini açıkça tavsiye ediyor. Bu yüzden canlı test ekranında yalnızca “başarılı” ibaresine değil, gerçekten eksik blokların HTML içinde var olup olmadığına bakın.

Render mı, indeksleme mi?

Canlı testten sonra kritik metin parçalarını tam metin aramasıyla kontrol edin. Sayfanın benzersiz bir cümlesini Google’da ve gerekirse Bing’de aratın. Metin rendered HTML içinde var ama sonuçlarda görünmüyorsa bu her zaman JavaScript kırığı değildir; canonical seçimi, düşük öncelik, yeni içerik veya kalite sorunları devrede olabilir. Buna karşılık metin rendered HTML içinde yoksa, problem büyük olasılıkla render aşamasındadır. Bing Webmaster Guidelines da Bing ve Copilot görünürlüğünün aynı crawl-index-rank temeline dayandığını vurgular; bu yüzden Bing’deki çapraz kontrol, motorlar arası ortak render sorunlarını ayırmak için hâlâ işe yarar.

• Indexing allowed: No ise önce noindex veya robots yönergesini çözün.
• Page fetch başarısız ise render tartışmasına geçmeden erişim sorununu düzeltin.
• Last crawl çok eski ise canlı testteki başarı henüz dizine yansımamış olabilir.
• Google-selected canonical farklı ise içerik doğru URL’de görünse bile bu URL seçilmeyebilir.

İlgili video kaynak olarak Google Search Central YouTube kanalındaki JavaScript SEO demoları da yararlıdır; özellikle rendered HTML ile kullanıcı DOM’u arasındaki farkı görsel olarak anlatırlar. Yine de karar anında esas belge, tek URL üzerinde gördüğünüz gerçek HTML farkları olmalıdır.

Adım Adım JavaScript ile yüklenen içerikte eksik görünme sorununun teşhisi

Aşağıdaki akış, ekip içinde tekrar tekrar uygulanabilecek kısa bir karar ağacıdır. Buradaki amaç, semptomu bir araç listesine boğmak değil; sorunun hangi katmanda çıktığını mümkün olan en az adımda netleştirmektir. Önce indeks verisini, sonra canlı render’ı, en sonda tarayıcı davranışını okuyun.

Bu sırayı korumak önemlidir. Çünkü tarayıcıdaki son DOM çoğu zaman en rahat görünen sürümdür; ama SEO tarafında asıl belirleyici olan, arama motorunun makul sürede oluşturabildiği rendered HTML’dir. Bu yüzden aşağıdaki adımların dizilimi bilinçli olarak indeks verisinden kullanıcı tarafına doğru ilerler.

1. Belirtiyi crawl mu render mı ayır. URL hiç bulunmuyor mu, metin mi eksik, yoksa canonical mi değişiyor? Belirtiyi baştan sınıflandırırsanız yanlış aracı kurcalamazsınız.
2. URL Inspection verilerini temel referans al. Indexing allowed, last crawl, page fetch ve Google-selected canonical alanlarını tek tabloda toplayın. Böylece indeks kaydı ile canlı sayfa karışmaz.
3. Canlı testte rendered HTML farkını kontrol et. Eksik metin, link veya meta etiketini arayın. Yüklenmeyen resource ve console hatası varsa not alın; bunlar çoğu zaman doğrudan kök nedene götürür.
4. Ham HTML ile son DOM’u yan yana karşılaştır. View-source ve inspect görünümünü aynı URL’de açın. Bir blok yalnızca son DOM’da görünüyorsa Google’ın görmesi garanti değildir.
5. Tam metin ve çapraz motor kontrolü yap. Sayfadan benzersiz bir cümleyi Google ve gerekirse Bing’de aratın. Böylece render edilmiş ama henüz seçilmemiş içerikle hiç render edilmemiş içeriği ayırabilirsiniz.
6. Düzeltme sonrası etkiyi izlemeye bağla. Tek URL düzeldikten sonra benzer desenleri site genelinde tarayın; aksi halde aynı framework veya komponent başka URL’lerde yeniden kırılır.

Kök nedeni bulun: lazy load, infinite scroll, engellenen JS ve framework desenleri

JavaScript SEO sorunlarının önemli kısmı, içeriğin kullanıcı etkileşimine bağlı şekilde yüklenmesinden çıkar. Google’ın 2025-12-10 güncel lazy-loading dokümanı, içeriğin scroll veya click olmadan, görünür olduğunda yüklenmesini önerir; çünkü Google Search sayfayla bir kullanıcı gibi etkileşime girmez. Bu cümle, lazy load ve infinite scroll teşhisinde doğrudan yol göstericidir. Eğer ürün listesi, açıklama bloğu veya yorumlar ancak scroll sonrası geliyorsa risk baştan yüksektir.

Framework desenlerini ayrı okuyun

React CSR boş shell senaryosunda ilk HTML neredeyse boştur; içerik tamamen istemcide oluşur. Next.js hydration sonrası eksik blok durumunda temel HTML gelir, fakat kritik modül sonradan değişir veya hata alır. Vue veya Nuxt route geçişi tarafında, URL değişse bile sayfa içeriği standarda uygun bağlantılarla keşfedilmeyebilir. AJAX ile gelen içerik ise çoğu zaman kullanıcının gördüğü ama rendered HTML’ye zamanında girmeyen bloklar üretir. Bu desenlerin hepsinde semptom benzeyebilir; ama çözüm aynı değildir.

Kaynak engelleri de sık gözden kaçar. JavaScript veya CSS dosyası robots.txt ile engellenmişse, arama motoru sayfanın tamamını kurgulayamayabilir. API timeout, 403 yanıtı veya region bazlı engel varsa tarayıcıda çalışan akış, Googlebot tarafında kısmen kırılabilir. Ayrıca canonical veya noindex etiketinin JavaScript ile sonradan eklenmesi daha sinsi bir sorundur. Google’ın JavaScript SEO Basics sayfası, robots meta etiketlerinin JavaScript ile değiştirilebildiğini açıkça belirtir; bu yüzden rendered HTML içinde bu sinyalleri ayrıca kontrol etmek gerekir.

• Lazy load riski: İçerik yalnızca scroll veya click sonrası geliyor.
• Infinite scroll riski: Her parça için kalıcı URL yok, History API kullanılmıyor.
• Hydration riski: Sunucu HTML’i ile istemci sonrası içerik birbirini tutmuyor.
• Kaynak engeli: JS, CSS veya API isteği bot için başarısız oluyor.
• Yönerge çakışması: JavaScript canonical veya noindex sinyalini sonradan değiştiriyor.

Buradaki amaç suçluyu hızlı bulmaktır. “Google JavaScript sevmez” gibi kaba bir açıklama artık yeterli değil. 2026’da sorun çoğu zaman framework seçimi değil, o framework içindeki veri akışının, link üretiminin ve meta yönetiminin arama motoru için ne zaman tamamlandığıdır.

Düzeltme sonrası etkiyi izleyin: SEOYEN ile sürekli görünürlük kontrolü kurun

Resmî araçlar tek URL teşhisinde güçlüdür; fakat aynı hata deseninin onlarca şablona yayıldığı projelerde operasyonel boşluk oluşur. Bu yüzden düzeltmeden sonra benzer URL kümelerini topluca izlemek gerekir. Burada site sağlığı taraması, tekil render sorununu şablon seviyesinde tekrar eden teknik risklere bağlamak için yararlıdır. Özellikle aynı component farklı kategori, ürün veya blog şablonunda kullanılıyorsa, tek URL çözümü kalıcı güvence sağlamaz.

İkinci katman görünürlük etkisidir. Bir render kırığı düzeldikten sonra yalnızca indekslenme değil, sorgu kapsaması ve sıralama hareketi de izlenmelidir. Bunun için sıralama takibi paneli ile kritik sorgulardaki değişimi düzenli okumak anlamlıdır. Benzer biçimde, içerik arama sonuçlarında düzelmiş olsa bile yeni nesil cevap yüzeylerinde etkisini görmek için AI görünürlük analizi katmanı ayrı değer üretir. Bing’in güncel yönergelerinde Copilot ve grounding sonuçlarının aynı indeks temeline bağlı olduğunun vurgulanması, bu takibin neden artık yalnızca klasik SERP meselesi olmadığını gösteriyor.

SEOYEN’in burada farkı, bu izlemeyi Türkiye pazarına uyarlanmış tek bir akışta toplamasıdır: tek platformda SEO araçları, Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek. Yurt dışı araç setlerinde farklı paneller arasında dağılabilen teşhis-sonrası süreç, burada daha operasyonel yönetilebilir hale gelir. Plan ve abonelik detayları gerektiğinde fiyatlar sayfası üzerinden güncel biçimde kontrol edilebilir. Asıl nokta şudur: tek URL testleri sorunu bulur, sürekli izleme ise aynı sorunun geri dönmesini engeller.

Sıkça Sorulan Sorular