Hızlı Cevap
JavaScript ile yüklenen içerikler Google’da görünmüyorsa yapılacak ilk iş, aynı URL için ham kaynak kodu, Search Console canlı testindeki oluşturulan HTML’yi ve dizine eklenen sürümü karşılaştırmaktır. Farkın nedeni çoğu zaman render gecikmesi, engellenen kaynak, noindex, canonical sapması veya scroll tetikli içeriktir.
Önemli Noktalar
- Tarama, render ve indeksleme aynı aşama değildir.
- Canlı test sonucu, dizine eklenme garantisi vermez.
- Ham HTML ile rendered HTML farkı teşhisin merkezindedir.
- Scroll veya oturum tetikli metinler görünürlük riski taşır.
- Düzeltme sonrası etkiyi şablon bazında izlemek gerekir.
Google’ın görmediği JavaScript içeriklerinde önce tarama mı render mı ayrılır?
Teşhise başlarken en kritik hata, tarama, oluşturma ve dizine ekleme aşamalarını tek şey sanmaktır. Google for Developers dokümanına göre Google, JavaScript sayfalarını üç ana aşamada işler: tarama, oluşturma ve dizine ekleme; ayrıca bu süreçte JavaScript’i Chromium’un evergreen sürümüyle çalıştırır (Google for Developers, 2026-03-06). Bu bilgi önemli çünkü sayfa 200 dönüyor diye ana içeriğin gerçekten işlendiğini varsayamazsınız.
Pratikte iki farklı tablo görürsünüz. Birincisi, sayfa canlı testte de boş görünür; burada sorun çoğu zaman gerçek render arızası, engellenen kaynak veya istemci tarafında hiç üretilemeyen içeriktir. İkincisi, canlı testte içerik görünür ama Google sonuçlarında hâlâ eski sürüm yer alır; bu durumda gecikmeli işleme, standart URL tercihi, noindex sinyali veya dizin sürümünün henüz yenilenmemesi daha olasıdır. Search Console Yardım, canlı testin gerçek zamanlı olduğunu ve dizindeki URL’den farklı çıkabileceğini açıkça belirtir (Google Search Console Yardım, 2026).
- robots.txt taramayı engelliyor mu kontrol edin.
- noindex veya x-robots-tag sinyali var mı bakın.
- canonical başka bir URL’yi işaret ediyor mu doğrulayın.
Bu ilk eleme yapılmadan JavaScript’e suç atmak gereksiz zaman kaybettirir. Özellikle ekip içinde teknik terimler karışıyorsa kısa bir SEO terimleri sözlüğü referansı ortak dil kurmanızı hızlandırır. Küçük işletme sitelerinde sık gördüğümüz hata şudur: boş görünen sayfanın asıl nedeni render değil, yanlış canonical veya istemeden eklenmiş noindex olur.
Aynı URL’de üç görünüm testi: kaynak kod, rendered HTML ve dizin sürümü
En güvenilir saha testi, aynı URL’yi üç görünümde yan yana açmaktır: tarayıcıdaki view-source, Search Console canlı testindeki oluşturulan HTML ve Google’ın gösterdiği dizin sürümü. Bu üçlü karşılaştırma tek başına birçok teşhisi hızlandırır. Ham kaynakta olmayan ama oluşturulan HTML’de görünen bloklar, JavaScript’in içeriği sonradan ürettiğini gösterir. Oluşturulan HTML’de de yoksa sorun daha derindir: içerik ya hiç çalışmıyordur ya da etkileşim bekliyordur.
Bu karşılaştırmada özellikle üç senaryoyu işaretleyin: yalnızca scroll sonrası gelen metinler, yalnızca kullanıcı oturumunda beliren bloklar ve ilk yüklemede sadece app shell bırakan yapı. Eğer kategori açıklaması, ürün metni veya kritik iç bağlantılar ancak kullanıcı aşağı kaydırınca geliyorsa, Googlebot bunları düzenli biçimde göremeyebilir. Benzer şekilde, oturum açılınca çıkan açıklamalar ya da tarayıcıda depolanan veriye bağlı modüller arama görünürlüğü için güvenilir değildir.
Search Console Yardım, oluşturulan HTML’yi tüm kaynaklar yüklenip tüm komut dosyaları çalıştıktan sonraki nihai sayfa kodu olarak tanımlar; bu yüzden ham HTML ile farkları satır satır okumak gerekir (Google Search Console Yardım, 2026). Deneyim tarafında en işe yarayan yöntem, üç görünümde aynı başlık, ana metin, canonical ve ana iç linkleri blok blok işaretlemektir. DOM’da var ama sonuçlarda yoksa indeks yorumunu; DOM’da hiç yoksa render zincirini sorgularsınız.
| Kontrol noktası | Ham HTML | Rendered HTML | Dizine eklenen sürüm |
|---|---|---|---|
| Ana metin var mı? | İlk yanıtta var mı kontrol edilir | Script çalıştıktan sonra gerçekten oluşmuş mu görülür | Snippet ve indeks yorumuna ne kadar yansıdığı anlaşılır |
| Kritik iç linkler var mı? | Menü ve gövde linkleri ham kodda aranır | JS ile eklenen linkler burada doğrulanır | Google’ın ilişkilendirdiği bağlantı sinyali dolaylı okunur |
| Canonical doğru mu? | Kaynakta beyan edilen değer görülür | Hydration sonrası değişip değişmediği anlaşılır | Google’ın seçtiği standart URL ile kıyaslanır |
| Noindex veya x-robots-tag sinyali var mı? | HTML ve üstbilgiler başlangıç sinyalini verir | İstemci tarafı meta değişiklikleri kontrol edilir | Dizine eklenme durumuyla birlikte yorumlanır |
| JS/CSS kaynakları eksiksiz yüklenmiş mi? | Sadece referansları görünür | Başarısız yüklemeler ve istisnalar teşhis edilir | Dolaylı olarak eksik işleme etkisi okunur |
| Snippet'e yansıyan içerik güncel mi? | Doğrudan göstermez | Canlı oluşturulan metinle karşılaştırma zemini sağlar | Google’ın gördüğü son yorum burada görünür |
Adım adım teşhis: URL Denetleme, hatalar ve yüklenmeyen kaynaklar
URL Denetleme Aracı’nda izlenecek sıra nettir: önce Canlı URL’yi test et, sonra ekran görüntüsü, oluşturulan HTML ve yüklenen kaynaklar. Google’ın sorun giderme kılavuzu, bu araçta yüklü kaynakları, JavaScript konsolu çıkışını, istisnaları ve oluşturulan DOM’yi görebileceğinizi söyler (Google for Developers, 2025-12-18). Buradaki amaç tek tek veri toplamak değil, karar ağacı kurmaktır: sayfa açıldı mı, ana içerik oluştu mu, kritik kaynaklar geldi mi?
Ardından hata katmanına inin. 4xx veya 5xx dönen JS ve CSS dosyaları, engellenen API istekleri, CORS sorunları, hydration kırılmaları ve beklenmeyen yönlendirmeler ana içeriği görünmez hale getirebilir. Google’ın aynı kılavuzu, JavaScript hatalarının toplanıp denetlenmesini ayrıca önerir; çünkü bazı durumlarda sorun SEO aracında değil doğrudan uygulama hatasında yatar (Google for Developers, 2025-12-18). Özellikle React veya Vue tabanlı sayfalarda veri isteği başarısız olunca sayfa 200 döner ama içerik boş kalır.
Burada soft 404 ile gerçek render sorunu birbirine karışır. Google’ın kılavuzunda SPA yapılarında soft 404 riskinin özellikle vurgulanması tesadüf değildir (Google for Developers, 2025-12-18). Sayfa başlığı ve iskelet tasarım geliyor ama içerik “kayıt bulunamadı” benzeri zayıf bir gövdeye düşüyorsa, render aslında çalışmış olabilir; sorun içerik kalitesi veya hata şablonudur. Buna karşılık canlı testte canonical beklenmedik bir URL’ye kayıyorsa, önce standart URL sorununu çözmek gerekir. Search Console Yardım da Google tarafından seçilen standart URL’nin beklediğiniz URL’den farklı olabileceğini söyler (Google Search Console Yardım, 2026).
CSR, SSR, lazy load ve framework farkları nasıl yorumlanır?
CSR ile kurulan sayfalarda ana içerik çoğu zaman tarayıcıda sonradan üretilir. SSR, prerender veya hibrit yapılarda ise temel metin, başlık ve iç linkler ilk HTML’de hazır gelmelidir. Teknik SEO açısından güvenli yaklaşım şudur: makalenin ana gövdesi, kategori açıklaması, ürün açıklaması ve kritik bağlantılar mümkün olduğunca ilk HTML yanıtında yer alsın. Google JavaScript’i işleyebiliyor olsa da bu, her geç çalışan bileşenin aynı güvenle anlaşılacağı anlamına gelmez.
Framework düzeyinde tipik kırılma noktaları bellidir. React ve Next.js tarafında hydration hatası yüzünden sunucudan gelen içerik istemci tarafında silinebilir. Vue ve Nuxt yapılarda route değişimi sonrası meta verinin geç güncellenmesi veya içerik bileşeninin yalnızca istemci tarafında yüklenmesi sorun çıkarabilir. Infinite scroll kurgusunda ilk partiden sonrası sadece etkileşimle geliyorsa, kategori sayfalarının derin ürünleri ve bağlantıları zayıf sinyal üretir. Bu nedenle framework adı değil, içeriğin hangi anda DOM’a girdiği önemlidir.
Lazy load tarafında da ince bir ayrım var. Google’ın 2026 tarihli JavaScript SEO dokümanı, resimler ve geç yüklenen içerikler için aramaya uygun uygulama gerektirdiğini açıkça hatırlatır (Google for Developers, 2026-03-06). Görsel lazy loading çoğu durumda yönetilebilirken, ana metnin ve ana bağlantıların scroll tetiklerine bağlanması daha risklidir. MDN’nin güncel JavaScript dokümantasyonu da istemci tarafında modüller, promise zincirleri ve asenkron yüklemelerin uygulama akışını doğrudan etkilediğini gösterir (MDN Web Docs, 2026-05-22). Kısacası, gecikmeli yüklenen her şey aynı değildir; metin ve linkler için tolerans daha düşüktür.
Düzeltme sonrası önceliklendirme ve SEOYEN ile izleme nasıl kurulur?
Düzeltme tamamlandığında tüm URL’leri aynı sepete atmayın. Önce sorunlu şablonları ayırın: ana sayfa, kategori, ürün veya içerik sayfası. Sonra her şablonda en görünür örnek URL’leri doğrulayın. Canlı testten geçen ama sonuçlarda hâlâ iyileşme göstermeyen sayfaları ayrı kuyruğa alın; bunlar çoğu zaman indeks yenilenmesi, canonical tercihi veya daha geniş kalite sinyalleriyle ilgilidir. Yeniden tarama isteği ancak kritik düzeltme doğrulandıktan sonra mantıklıdır.
İzleme tarafında tek panel yaklaşımı işinizi kolaylaştırır. Render sorunu çözüldükten sonra hem site sağlığı kontrolü hem de sıralama takibi panosu birlikte izlenmelidir. SEOYEN’in güçlü tarafı burada görünür: Türkçe arayüz, tek platformda birden fazla SEO iş akışı, TL bazlı fiyatlandırma ve yerel Türkçe destek sayesinde teknik SEO çıktısını ekip içinde daha hızlı okunur hale getirir. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer gibi platformlar güçlü referans noktalarıdır; SEOYEN ise bu ihtiyacı Türkiye pazarına uyarlanmış, daha yerel bir operasyon akışında toplar.
- Kritik şablonları önce doğrulayın, tekil URL’leri sonra genişletin.
- Canlı test ile dizin sürümünü ayrı raporlama listelerinde tutun.
- Görünürlük etkisini en az iki hafta düzenli takip edin.
Operasyon kısmında dokümantasyonu da güncel tutun. Ekip bütçe ve satın alma tarafını konuşuyorsa sabit rakam yerine TL fiyatlandırma paketleri sayfasını referans vermek daha sağlıklıdır. Böylece render düzeltmesinden sonra hangi araç setiyle hangi metriklerin izleneceği netleşir ve içerik bayatlamaz.
Adım Adım Google’ın görmediği JavaScript içeriklerini teşhis etme
Aşağıdaki akış, küçük işletme sitelerinde ve daha büyük içerik projelerinde tekrar tekrar çalışır. Mantık basit görünür ama adımları karıştırmamak önemlidir: önce ilk HTML’yi, sonra Google’ın gördüğü oluşturulan sürümü, en son da dizin yorumunu kontrol edersiniz.
- Ham HTML çıktısını alın. Tarayıcıda view-source açın ve başlık, ana metin, canonical ile kritik iç linklerin ilk yanıtta bulunup bulunmadığını işaretleyin. Eğer ana içerik burada hiç yoksa sayfanın büyük kısmı istemci tarafında üretiliyor olabilir; bu tek başına hata değildir ama risk alanını daraltır.
- Canlı testte oluşturulan HTML’yi açın. Search Console’da URL Denetleme üzerinden canlı testi çalıştırın. Ekran görüntüsüne, oluşturulan HTML’ye ve yüklenen kaynaklara birlikte bakın. Google Search Console Yardım bu görünümün gerçek zamanlı olduğunu söyler; yani burada gördüğünüz tablo, indekslenmiş sürümle aynı olmak zorunda değildir.
- Dizin sürümüyle farkları karşılaştırın. Google Dizini ve Canlı Test sekmeleri arasında geçiş yapın. Başlık, snippet, canonical ve kapsanan içerik alanları farklıysa sorunun render mı, gecikmeli işlenme mi yoksa standart URL tercihi mi olduğunu daha net ayırırsınız.
- JS hataları ve engelli kaynakları bulun. 4xx-5xx dönen script dosyaları, başarısız API çağrıları, hydration hataları ve robots engelleri bu adımda ortaya çıkar. Kritik veri isteği başarısızsa sayfa 200 dönse bile boş app shell oluşabilir; bu da Google’ın eksik DOM görmesine neden olur.
- Render modeli ve yükleme biçimini yorumlayın. Sayfanın CSR, SSR, prerender veya hibrit mantıkla çalıştığını belirleyin. Metin ve bağlantılar yalnızca scroll, tıklama veya oturum durumuna bağlı geliyorsa sorun büyük ihtimalle gerçek render erişilebilirliğidir; yalnızca dizin sürümü geri kaldıysa sabır ve tekrar doğrulama gerekir.
- Düzeltme sonrası etkileri izleyin. Sorun düzeldikten sonra şablon bazlı izleme başlatın. Görünürlük, indeks durumu ve sıra değişimini birlikte okuyun; sadece gerekli URL’ler için yeniden tarama isteği verin. Böylece geliştirici düzeltmesi ile SEO etkisini aynı çizgide takip edebilirsiniz.
Kaynaklar
Sıkça Sorulan Sorular
Evet, görebilir. ancak burada kritik nokta içeriğin hangi aşamada üretildiğidir. Google, JavaScript sayfalarını tarama, oluşturma ve dizine ekleme adımlarıyla işler. Bu yüzden içerik yalnızca geç çalışan bir script’e, scroll davranışına veya kullanıcı durumuna bağlıysa Google bazı URL’lerde içeriği hiç göremeyebilir ya da daha geç işleyebilir. Güvenilir teşhis için ham kaynak kodu, Search Console’daki oluşturulan HTML’yi ve dizine eklenen sürümü birlikte kontrol etmek gerekir. Canlı testte görünmesi de tek başına sonuç sayılmaz. canonical, noindex veya dizin sürümünün eski kalması tabloyu değiştirebilir.
Önce ilgili URL’yi Search Console’daki URL Denetleme Aracı’na girin ve canlı testi başlatın. Test tamamlandıktan sonra test edilen sayfayı göster bölümüne girerek HTML sekmesini açın. Burada gördüğünüz içerik, Google’ın o an oluşturduğu sürümdür. Sonra bunu tarayıcıdaki view-source çıktısıyla yan yana koyun. Eksik başlık, eksik metin, kayıp iç link, yanlış canonical veya meta robot farklarını bu şekilde işaretleyebilirsiniz. Özellikle istemci tarafında sonradan eklenen bloklar için bu karşılaştırma çok değerlidir. çünkü sorun içerik hiç üretilmemesi mi, yoksa üretilip dizine yansımaması mı sorusunu netleştirir.
Bazen evet. Eğer içerik sayfa yüklenir yüklenmez güvenilir biçimde JavaScript ile oluşturuluyor ve Google canlı testte bunu rendered HTML içinde görebiliyorsa, bu içerik dizine eklenebilir. Ancak bu her durumda garanti değildir. İçerik scroll, tıklama, oturum, tarayıcı deposu veya geç başarısız olabilen API isteklerine bağlıysa Google aynı içeriği tutarlı biçimde göremeyebilir. Bu yüzden yalnızca “kaynak kodda yok ama tarayıcıda görünüyor” demek yeterli değildir. Asıl soru, Google’ın oluşturulan HTML’de bunu gerçekten görüp görmediği ve dizin sürümünün buna ne kadar yansıdığıdır.
Çünkü bu iki görünüm aynı şeyi anlatmaz. Canlı URL testi, sayfanın o anda gerçek zamanlı olarak taranabilir ve oluşturulabilir olup olmadığını gösterir. Dizin sürümü ise Google’ın daha önce işlediği ve arama sonuçlarında kullandığı sürümdür. Arada süre farkı olabilir. Ayrıca canonical tercihi, noindex sinyali, robots kısıtı veya render kuyruğundaki gecikme nedeniyle canlı test temiz görünse bile dizinde farklı bir sürüm kalabilir. Bu yüzden teşhis sırasında iki görünümü birlikte okumak gerekir. Canlı test iyiyse ama sonuçlar değişmiyorsa, sorun artık çoğu zaman indeks yorumunda veya standart URL seçimindedir.
Lazy load yaklaşımı içerik tipine göre farklı risk taşır. Görseller için geç yükleme çoğu zaman daha yönetilebilir kabul edilir. çünkü ana metin ve sayfa anlamı bundan daha az etkilenir. Ancak asıl metin, ürün açıklaması, kategori linkleri veya dahili bağlantılar scroll ya da etkileşim sonrasında geliyorsa görünürlük riski artar. Google bu tür içerikleri her zaman kullanıcı davranışı simüle ederek almayabilir. Bu nedenle SEO açısından güvenli yaklaşım, anlam taşıyan metin ve önemli linkleri ilk HTML ya da en azından etkileşim gerektirmeyen bir render akışı içinde sunmaktır.
Kritik script’ler hata verirse Google eksik DOM görür. Bunun sonucu yalnızca bir görsel bozulma değildir. başlık, ana metin, dahili linkler, structured data ve hatta canonical sinyali bile kaybolabilir. Özellikle API yanıtı alamayan bileşenler, hydration kırılmaları, 4xx-5xx dönen JS dosyaları ve modül yükleme sorunları arama görünürlüğünü doğrudan etkiler. Bu yüzden URL Denetleme’de yalnızca ekran görüntüsüne bakmak yetmez. yüklenen kaynaklar, konsol hataları ve oluşturulan HTML birlikte incelenmelidir. Sayfa 200 dönüyor olsa bile kullanıcıya ve Google’a boş app shell göstermek, görünürlük açısından gerçek bir sorundur.