Rendered HTML Kontrolü Neden Önemlidir?

Kaynak HTML ile JavaScript çalıştıktan sonra oluşan DOM arasındaki farkın tespit edilmesi, JavaScript bağımlı içeriklerin indeks dışı kalıp kalmadığını anlamanın tek güvenilir yoludur.

Rendered HTML ile kaynak HTML karşılaştırması ve Googlebot render süreci şeması

Bir sayfanın kaynak kodunu açtığınızda gördüğünüz ile Googlebot'un o sayfayı taradığında gördüğü her zaman aynı değildir. Bu fark teknik bir ayrıntı gibi dursa da indeksleme sonuçlarını doğrudan şekillendirir. Sayfanızın başlığı, ana içerik bloğu, iç linklerin bir kısmı ya da structured data işaretlemesi yalnızca JavaScript çalıştıktan sonra DOM'a ekleniyorsa, render olmaksızın yapılan bir inceleme bu eksikliği göstermez. JSON-LD bloğunu doğrulamak veya okunaksız gelen yapılandırılmış veri çıktısını incelemek için bir JSON formatter süreci hızlandırır.

Pek çok teknik SEO denetimi hâlâ kaynak kodu merkezlidir. Ctrl+U ile açılan kaynak ekranı sayfanın sunucudan gönderildiği ham hali gösterir. Ancak modern web uygulamalarının büyük bölümünde içerik bu ham halden sonra üretilir: React, Vue ya da Angular tabanlı bir yapıda sayfanın görsel çıktısını ve içeriğini oluşturan JavaScript tarayıcıda çalışmak zorundadır. Kaynak kodda yalnızca bir <div id="root"></div> görmek sayfanın boş olduğu anlamına gelmez; ama Googlebot'un o sayfadan ne aldığını da söylemez.

Rendered HTML kontrolü tam bu noktada başlar. Sayfanın tarayıcıda çizildikten sonra nasıl göründüğünü, hangi metinlerin DOM'a girdiğini, hangi linklerin gerçekten var olduğunu ve hangi içeriklerin asla yüklenemediğini anlamak için kaynak koda değil, render sonrasına bakılır.

Kaynak kod ile render edilmiş DOM her zaman aynı değil

Bir sayfanın sunucudan gönderilen HTML'i ile tarayıcıda JavaScript çalıştıktan sonra oluşan DOM'u farklı yapılardır. Sunucu taraflı render (SSR) kullanılan sitelerde bu fark küçük olabilir; içerik çoğunlukla ilk yanıtta gelir. Ancak istemci taraflı render (CSR) ağırlıklı yapılarda sayfa iskeleti sunucudan gelir, içerik ise JavaScript çalıştıktan sonra yerleştirilir. Bu durumda kaynak kodu okumak, tamamlanmamış bir belge okumak demektir.

Bunun SEO açısından sonucu şudur: Googlebot bir sayfayı taradığında önce ham HTML'yi alır, ardından JavaScript'i işleyerek render eder. Ama bu iki adım aynı anda gerçekleşmez. Google, JavaScript renderını tarama kuyruğuna alır ve ilk taramadan saatler, hatta günler sonra gerçekleştirebilir. Bu süre içinde kaynak kodda görünmeyen içerikler indekslenmemiş sayılır. Sayfanın başlığı, ürün açıklaması ya da kategori bağlantıları bu beklemede kaybolabilir.

Dolayısıyla sorun yalnızca "JavaScript var mı, yok mu" değildir. Daha kritik olan soru şudur: JavaScript çalıştıktan sonra hangi içerik DOM'da görünüyor, hangisi görünmüyor ve Googlebot bu içeriğe zamanında ulaşıyor mu?

Googlebot JavaScript'i her sayfada aynı biçimde işlemez

Googlebot'un JavaScript işleme kapasitesi son yıllarda gelişmiş olsa da her sayfayı tam bir tarayıcı gibi render ettiği varsayımı yanıltıcıdır. Google'ın resmi açıklamalarına göre render kaynakları sınırlıdır ve öncelikli URL'lere tahsis edilir; bu da tüm sayfaların eşit derinlikte işlenmeyeceği anlamına gelir.

Özellikle şu durumlar Googlebot'un render başarısını olumsuz etkiler: sayfanın render sürecinin uzun sürmesi, JavaScript kaynaklarından bazılarının robots.txt ile engellenmiş olması, JavaScript hatalarının render sürecini kesmesi ve lazy-load ile ertelenen içeriklerin Googlebot'un bekleme süresi dolmadan görünür hale gelememesi. Bu durumların herhangi biri kaynak kodda değil, yalnızca rendered çıktıda tespit edilebilir.

Bir başka konu da üçüncü taraf JavaScript kaynaklarıdır. Consent management platform (CMP) araçları, A/B test scriptleri ya da tag manager tetikleyicileri belirli içeriklerin render edilip edilmeyeceğini doğrudan etkileyebilir. Googlebot bu araçlarla her zaman bir kullanıcı gibi etkileşime girmediğinden bazı içerikler hiç render edilmeyebilir. Bunu kaynak koddan anlamak mümkün değildir.

Rendered HTML ile kaynak kod karşılaştırması nasıl yapılır

Rendered HTML kontrolünün en pratik yolu Google Search Console'daki URL Denetleme aracıdır. "Sayfayı Görüntüle" seçeneği Googlebot'un o sayfayı en son nasıl gördüğünü gösterir. Sayfa başlığı, meta description, h1 etiketi, ana içerik paragrafları ve iç linkler bu ekranda aranır; bunlar kaynak koddaki değerlerle karşılaştırılır. Aralarında fark varsa bu render sorununun somut göstergesidir.

Daha ayrıntılı bir karşılaştırma için Chrome DevTools kullanılır. Ctrl+U ile açılan kaynak kod ile F12 → Elements sekmesinde görünen DOM yan yana incelendiğinde hangi elemanların sonradan eklendiği, hangi metinlerin JavaScript tarafından oluşturulduğu ve hangi linklerin statik HTML'de yer almadığı görülür. Özellikle <nav> içindeki linklerin, <article> bloklarının ve <script type="application/ld+json"> etiketlerinin her iki görünümde de eşleşip eşleşmediği kontrol edilmelidir.

Screaming Frog, JavaScript render modunda çalıştırıldığında iki tarama profili karşılaştırmaya imkân tanır: biri kaynak HTML, diğeri render edilmiş çıktı. Bu karşılaştırmada hangi sayfalarda içerik farkı oluştuğu, hangi linklerin yalnızca render sonrası göründüğü ve hangi sayfaların başlık ya da description bilgisini JavaScript'ten aldığı toplu olarak görülür. Büyük sitelerde bu yöntem sayfa tek tek incelemenin önüne geçer.

Yalnızca rendered görünümde ortaya çıkan sorunlar

Bazı sorunlar kaynak kod incelemesinde hiç görünmez; ancak rendered HTML kontrolü yapıldığında hemen fark edilir. Bunların başında JavaScript tarafından oluşturulan iç linkler gelir. Navigasyon, breadcrumb ya da "ilgili yazılar" blokları bir JavaScript bileşeni olarak üretildiğinde kaynak kodda link yoktur, ama render sonrasında DOM'a eklenir. Googlebot bu linkleri iki aşamalı tarama sürecinde görecektir; ama gecikme kaçınılmazdır. İç link yapısı analizi yaparken bu farkı gözden kaçırmak, siteye gerçekte aktarılan bağlantı değerini yanlış ölçmek demektir.

Structured data işaretlemesinde de render bağımlılığı görülür. JSON-LD bloğunu sayfaya JavaScript ile ekleyen bir yapıda kaynak kodda schema yoktur. Google bu schema'yı ancak render aşamasında görebilir. Dolayısıyla GSC'de "Zengin Sonuçlar" hatasını araştırırken önce rendered HTML'de schema bloğunun var olup olmadığını doğrulamak gerekir.

Lazy-load içerikler de yalnızca rendered görünümde test edilebilir. Görüntü alanı dışındaki içerikler, kullanıcı kaydırdıkça yüklenen metin ya da ürün açıklamaları kaynak kodda placeholder hâlinde bulunur. Googlebot kaydırma eylemi gerçekleştirmediğinden bu içeriklerin render edilip edilmediği belirsiz kalır. Taranabilirlik sorunlarını araştırırken lazy-load ile ertelenen içeriklerin rendered çıktıda göründüğünü doğrulamak bu nedenle önemlidir.

Bir de hata durumları vardır. JavaScript'te bir istisna fırladığında sayfa kısmen render edilebilir; bazı bileşenler yüklenirken diğerleri yüklenmez. Kaynak kodda böyle bir durumun izi yoktur. Rendered HTML'de ise eksik bloklar, yüklenmemiş içerik alanları ya da tamamen boş kalan <div> elemanları görünür hale gelir.

Render gecikmesi indeksleme zamanlamasını nasıl etkiler

Google'ın iki aşamalı tarama modelinde ilk aşama hızlı gerçekleşir: Googlebot HTML'yi alır, kaynak kodunu işler ve linkleri kuyruğa ekler. Render ise ikinci aşamadır ve bu aşamaya geçiş, sayfanın önceliğine, crawl bütçesine ve Google'ın render kapasitesine göre değişir. Crawl budget sınırlı sitelerde bazı sayfalar render edilmeden indekste kalabilir; bu durumda JavaScript bağımlı içerikler hiç işlenmemiş olur.

Bu gecikmenin pratik sonucu şudur: Yeni yayınlanan bir sayfa içeriğini JavaScript ile oluşturuyorsa arama sonuçlarında başlangıçta eksik ya da yanıltıcı bir snippet ile görünebilir. Sayfa başlığı <title> etiketiyle sabit verilmişse bu kısmen korunur; ama meta description, h1 ya da ana içerik paragrafı JavaScript'e bağlıysa snippet boş ya da hatalı çıkabilir.

Render gecikmesi aynı zamanda içerik güncellemelerini de etkiler. Mevcut bir sayfanın içeriğini JavaScript üzerinden değiştirdiğinizde bu değişiklik yalnızca render edilmiş DOM'da görünür. Google sayfayı bir sonraki tarama döngüsünde HTML olarak alır, render kuyruğuna ekler ve ancak ondan sonra yeni içeriği görebilir. Log analizi ile tarama sıklığını takip ediyorsanız bu gecikmeli döngüyü log kayıtlarından gözlemlemek mümkündür.

Rendered HTML kontrolü denetim sürecinde nereye oturur

Rendered HTML kontrolü, teknik SEO denetiminin başlangıcında değil, kaynak kod incelemesinin ardından yapılır. Önce statik sorunlar (başlık eksiklikleri, canonical hatalar, robots.txt engellemeleri) tespit edilir; ardından JavaScript bağımlılığı olan alanlar belirlenerek rendered görünüm kontrol edilir. Bu sıralama gereksiz render testinin önüne geçer.

H1 başlığı kaynak kodda mı üretiliyor yoksa JavaScript'e mi bırakılmış, ana içerik paragrafları render öncesinde mevcut mu, iç linkler statik HTML'de mi duruyor ve JSON-LD schema bloğu kaynak kodda mı tanımlı: bu dört sorunun yanıtı sitenin render bağımlılığını ve dolayısıyla indeksleme riskini kabaca ortaya koyar.

Teknik SEO analizi kapsamında rendered HTML kontrolü her sitede zorunlu değildir; ama JavaScript ağırlıklı bir yapı söz konusuysa bu adımı atlamak ciddi bir kör nokta bırakır. Statik HTML tabanlı sitelerde kaynak kod çoğunlukla yeterli olur. Ancak modern JavaScript çerçeveleri üzerine kurulu yapılarda, özellikle SPA mimarisinde, rendered görünümü incelemeden yapılan denetim eksik kalır.

Kaynak kodu okumak bir başlangıç noktasıdır, ama JavaScript render sonrasını görmeden teknik denetim tamamlanamaz. Sayfanın içeriğini, başlıklarını, linklerini ve structured data işaretlemesini JavaScript üretiyorsa Googlebot'un bu öğelere ne zaman ve ne ölçüde ulaştığı ancak rendered HTML üzerinden anlaşılır.

Bu kontrolü rutin hale getirmek karmaşık değildir. GSC'deki URL Denetleme aracı, Chrome DevTools ve JavaScript modunda yapılandırılmış bir tarayıcı taraması çoğu durumda yeterlidir. Sorun, rendered HTML'nin hiç bakılmamış olmasında değil, kaynak kodun yeterli kabul edilmesindedir.

Bir sayfanın arama motorlarında nasıl göründüğünü anlamak istiyorsanız, onu bir kullanıcı gibi değil bir bot gibi okumayı deneyin: JavaScript desteği olmadan, render gecikmesiyle, lazy-load tetikleyicisi olmaksızın. O bakış açısı çoğu zaman kaynak kodun hiç göstermediği şeyleri yüzeye çıkarır.