JavaScript SEO İçin Google'ın Render Süreci: Taramadan İndekse
SEO

JavaScript SEO İçin Google'ın Render Süreci: Taramadan İndekse

Google, 200 durum kodu dönen her sayfayı JavaScript içerip içermediğine bakmadan render queue'ya alır. JavaScript SEO açısından bekleme çoğunlukla kısa: 2024'te nextjs.org üzerinde ölçülen 37.000'den fazla render'da medyan 10 saniye, en yavaş %10'luk dilimde 3 saat ve üzeriydi.

Sercan Gökpınar
11 dk

JavaScript ile kurulmuş siteler hakkında dolaşan tablo üç parçadan oluşuyor. JavaScript ağırlıklı sayfalar ayrı bir kuyruğa giriyor, bekleme haftalar sürüyor ve crawler modern kodu çalıştıramıyor. Google'ın dokümanı ve bugüne kadarki en büyük açık ölçüm, bu üç parçanın üçüyle de çelişiyor.

JavaScript SEO'daki gerçek riskler başka yerde duruyor. Render motorunun yapmadığı işlerde, Google'ın sayfayı okuma sırasında ve hiç render etmeyen crawler'larda. Aşağıdaki bölümler bu sırayı izliyor ve her sayıyı tarihi ve kapsamıyla veriyor.

Google JavaScript'li Bir Sayfayı Nasıl İşler

Google'ın JavaScript SEO temelleri rehberi süreci üç faza ayırıyor: crawling, rendering ve indexing. Googlebot crawl queue'dan bir URL alıyor ve istek göndermeden önce robots.txt dosyasına bakıyor. Disallow edilmiş URL atlanıyor, Google engellenmiş dosyalardaki JavaScript'i de render etmiyor. Next.js'te /_next/ yolunu engellemenin sayfayı boşaltması bu ikinci kuraldan doğuyor.

Googlebot, Mayıs 2019'dan beri render işini Chromium'un güncel bir sürümüyle yapıyor. Google duyurusunda bu yapıya "evergreen" adını verdi. Bing aynı taahhüdü Ekim 2019'da Microsoft Edge için verdi. Arama motorlarının modern JavaScript'i işleyemediği fikri yedi yıldır geçerli değil.

Media

Sayfa İki Kez Okunur

Google bir sayfayı linkler için iki kez ayrıştırıyor. İlk tur HTML yanıtını okuyor ve href özniteliğinde bulduğu her URL'yi crawl queue'ya ekliyor. İkinci tur render edilmiş HTML'i okuyor, linkleri yeniden arıyor ve bulduklarını da kuyruğa ekliyor.

Google indekslemeyi de render edilmiş HTML'den yapıyor ve orada olmayan içerik indekslenemiyor. Sunucuda render edilen bir sayfada iki tur neredeyse aynı belgeyi görüyor. Uygulama kabuğu (app shell) modelindeki bir sayfada ise ilk tur yalnızca bir kapsayıcı ve bir script etiketi görüyor. Önemli olan her şey ikinci turda geliyor.

Başarısız bir render turu, taranmak ile indekslenmek arasındaki farkın teknik sebeplerinden biri. Sunucu logunda sağlıklı bir 200 görünüyor. Google'ın elinde ise indekslenecek hiçbir şey taşımayan bir sayfa kalıyor.

Render Queue'ya Hangi Sayfalar Girer

Render queue sayfaları teknolojiye göre seçmiyor. Google'ın cümlesi açık: "All pages with a 200 HTTP status code are sent to the rendering queue." Doküman bunun sayfada JavaScript olsun olmasın geçerli olduğunu ekliyor. Statik bir sayfa ile tek sayfalık bir uygulama (single-page application, SPA) aynı sırada bekliyor.

İki durum sayfayı kuyruğun dışında tutuyor. Durum kodu 200 değilse render atlanabiliyor ve Google'ın örneği bir 404 sayfası. İndekslemeyi engelleyen bir robots meta etiketi ya da başlığı da sayfayı dışarıda bırakıyor.

Vercel ve MERJ iki koşulu Nisan 2024'te canlı sitelerde test etti. JavaScript miktarı ne olursa olsun 200 dönen her HTML sayfası render edildi. Diğer 3xx, 4xx ve 5xx kodlarını dönen sayfalar render edilmedi.

Durum kodu bu yüzden indeksleme kararıyla birlikte render maliyetini de belirliyor. Hata sayfalarını 200 ile sunan bir SPA, Google'ın soft 404 olarak işaretleyebileceği bozuk sayfaları kuyruğa sokuyor. Google iki çıkış yolu veriyor: gerçek bir 404 dönen URL'ye JavaScript yönlendirmesi ya da JavaScript ile eklenen bir noindex etiketi.

noindex Tuzağı

noindex kuralı tek yönde çalışıyor. JavaScript bir noindex etiketi ekleyebilir ve Google etiketi render sırasında görür. JavaScript var olan bir noindex etiketini ise güvenilir biçimde kaldıramaz.

Sebebi Google'ın rehberinde yazılı: Google noindex gördüğünde "it may skip rendering and JavaScript execution." Etiketi silecek script hiç çalışmıyor. Vercel ve MERJ de aynı sonucu gözledi ve ilk HTML'de noindex taşıyan sayfaların hiçbiri render edilmedi.

Media

Hata en sık, noindex ile açılıp veri yüklenince etiketi kaldıran şablonlarda çıkıyor. Tarayıcı render edilmiş Document Object Model'i (DOM) gösterdiği için sayfa orada doğru görünüyor. Kontrolü view-source ile yapın.

Render Queue Ne Kadar Sürer

Google'ın kendi cevabında sayı yok. Dokümana göre sayfa kuyrukta "a few seconds" kalabilir, "but it can take longer than that." Render, Google'ın kaynakları izin verdiğinde başlıyor.

Elimizde iki sayı var. Google, Chrome Dev Summit 2019'da medyan render süresini 5 saniye, 90. yüzdelik dilimi "dakikalar" olarak açıkladı. O dönem Google'da çalışan Ilya Grigorik rakamları 13 Kasım 2019'da X'te paylaştı. Rakamlar Google'ın dokümanına hiç girmedi.

Daha yeni sayı bir ölçüme dayanıyor. Vercel ve MERJ, nextjs.org üzerindeki 37.000'den fazla Googlebot taramasını her render'ın bittiği anla eşleştirdi. Medyan gecikme 10 saniye çıktı ve sayfaların %25'i 4 saniye içinde render edildi.

Media

Kuyruğun etkisi dağılımın ucunda görünüyor: 90. yüzdelikte yaklaşık 3 saat, 95. yüzdelikte 6 saat, 99. yüzdelikte 18 saat.

2024 Rakamları Neyi Ölçüyor

Çalışma, sık güncellenen tek bir dokümantasyon sitesini bir ay boyunca kapsıyor. /docs gibi sık değişen bölümler, durağan bölümlerden daha hızlı render edildi. Kuyruk bu yüzden ilk gelen ilk çıkar mantığıyla işlemiyor.

Query string taşıyan URL'ler daha uzun bekledi. 75. yüzdelikte parametresiz URL'ler 22 saniyede, parametreli URL'ler 31 dakikada render edildi. Tek bir sayfayı takip ya da filtre parametreleriyle çoğaltan site bu gecikmeyi her varyantta ödüyor. Aynı varyantlar crawl budget'tan da pay alıyor.

"9 Kat Yavaş" Rakamı Nereden Geliyor

Bazı SEO rehberleri, Google'ın JavaScript içeriğini düz HTML'e göre dokuz kat yavaş taradığını hâlâ yazıyor. Rakam, açamadığımız tarihsiz bir ajans deneyine dayanıyor. Arama özetleri deneyi, Google'ın yedi sayfalık bir link zincirini ne kadar sürede izlediğinin ölçümü olarak anlatıyor. Böyle bir ölçüm tek sayfanın bekleme süresini göstermiyor, birkaç adıma yayılan keşif süresini gösteriyor.

Rakamın yönü makul. Yalnızca render sonrası var olan her link, zincire bir render beklemesi ekliyor. Güncel veriler ise rakamın büyüklüğünü desteklemiyor, bu yüzden onu bir olgu gibi tekrarlamıyoruz.

Googlebot Render Ederken Neleri Yapamaz

Güncel bir motor, Googlebot render işini bir ziyaretçi gibi yapıyor anlamına gelmiyor. Google'ın sorun giderme rehberi ve lazy-loading rehberi, tarayıcı testinde hiç görünmeyen farkları sıralıyor.

Media

Tıklamaz ve Kaydırmaz

Lazy-loading rehberinin cümlesi net: "Google Search does not interact with your page." Tıklamadan sonra yüklenen içerik render edilmiş HTML'in dışında kalıyor. Sunucudan yeni metin çeken bir "devamını göster" düğmesi buna örnek. İçeriği DOM'da duran ve yalnızca CSS ile gizlenen sekme ve akordeonlarda sorun yok.

Kaydırma da aynı biçimde işliyor. Görselleri ve bölümleri scroll olayına bağlamayın. Onları görünüm alanına girdiklerinde yükleyin; tarayıcının yerleşik lazy-loading özelliği ya da IntersectionObserver bunu sağlıyor. Sonsuz scroll için her parçanın benzersiz ve kalıcı bir URL'si olan sayfalı bir sürüm gerekiyor.

Sayfalar Arasında Hiçbir Şey Hatırlamaz

Google'ın Web Rendering Service'i (WRS) her URL'yi temiz bir oturumla açıyor. Local Storage, Session Storage ve HTTP çerezleri sayfa yüklemeleri arasında siliniyor. Google bu yüzden sayfanın ilk kez gelen ziyaretçiye gösterilen hâlini indeksliyor. Onay vermemiş, dil seçmemiş ve tercih kaydetmemiş bir ziyaretçinin gördüğü hâl bu.

Dil tercihi çerezde tutuluyorsa Google her sayfada varsayılan dili görüyor. Makaleyi ancak onaydan sonra yükleyen bir çerez bannerı Google'a makale göstermiyor, çünkü Google o onayı hiç vermiyor.

Yalnızca HTTP Konuşur

Googlebot içeriği yalnızca HTTP üzerinden çekiyor ve WebSocket ya da WebRTC bağlantısı kurmuyor. Bu bağlantılarla akan içerik indekse hiç ulaşmıyor. Googlebot kamera erişimi gibi izin isteklerini reddediyor ve WebGL desteklemiyor. Google'ın üç durum için önerisi aynı: özelliği tespit edin ve bir yedek yol bırakın.

Yalnızca Render Sonrası Bulunan Linkler

Google bir linki ancak href özniteliği taşıyan bir <a> elemanıysa güvenilir biçimde takip edebiliyor. Link rehberi, JavaScript ile eklenen linklerin de aynı HTML biçimini kullandıkları sürece taranabildiğini ekliyor. routerLink özniteliği, href taşıyan bir <span> ya da bir onclick işleyicisi ayrıştırılmayabilir.

Framework'lerin link bileşenleri, örneğin next/link, sonunda href taşıyan bir <a> üretiyorsa sorun yok. Kontrolü kaynak kodda bırakmayın ve render edilmiş HTML'de yapın.

Zamanlama da şekil kadar önemli. HTML yanıtındaki link ilk turda crawl queue'ya giriyor. Yalnızca render sonrası ortaya çıkan link önce render queue'yu bekliyor. Bu tür linklerden oluşan bir zincir o beklemeyi her adımda tekrarlıyor.

Vercel ve MERJ maliyeti azaltan iki ayrıntı buldu. Google, render edilmemiş bir JSON yükünün içindeki URL'leri de keşfetti. Çalışmaya göre güncel bir XML sitemap, render yöntemleri arasındaki keşif farkını büyük ölçüde kapatıyor, hatta tamamen ortadan kaldırabiliyor.

Google yine de bir linkin site mimarisindeki değerini ancak render tamamlandıktan sonra değerlendirdi. Ana navigasyonu ilk HTML'e düz <a> linkleri olarak koyun.

JavaScript SEO İçin Client-Side Rendering mi, Server-Side Rendering mi

Arama açısından render yöntemi seçimi tek bir soruya iniyor: içerik ilk HTML yanıtında mı? Client-side rendering (CSR) bir kabuk gönderiyor ve sayfayı tarayıcıda kuruyor. Server-side rendering (SSR) HTML'i her istekte üretiyor. Static site generation (SSG) ise HTML'i istek gelmeden önce hazırlıyor.

Google client-side rendering ile üretilen içeriği görüyor, yani CSR görünmezlik anlamına gelmiyor. CSR'ın getirdiği şey bağımlılık: render queue'ya, taranabilir script'lere ve yukarıdaki sınırlara. Google yine de server-side rendering ya da pre-rendering öneriyor ve gerekçelerinden biri "not all bots can run JavaScript". Sunucuda kurulan sayfaya etkileşim ekleyen hydration da aynı öneri listesinde.

Dynamic Rendering Geçici Bir Çözümdü

Dynamic rendering botlara sunucuda render edilmiş sayfayı, kullanıcılara client-side sürümü veriyor. Google'ın dokümanı bugün geçmiş zaman kullanıyor: "Dynamic rendering was a workaround and not a long-term solution." Doküman iki render yolunun karmaşıklığı ve kaynak ihtiyacını artırdığını yazıyor.

Yöntemi hâlâ öneren rehberler çoğunlukla Bing'e dayanıyor. Bing Ekim 2018'de yöntemi JavaScript'e ağır dayanan siteler için gerçekten önermişti. Bir yıl sonra render motorunu evergreen Microsoft Edge'e taşıdı. Güncel yönergeleri dynamic rendering'den hiç söz etmiyor ve kritik içeriği client-side rendering arkasına saklamamayı istiyor.

Media

Her Crawler Render Etmez

Google'ın dynamic rendering sayfası, diğer arama motorlarının JavaScript'i yok saymayı seçebileceğini yazıyor. Render pahalı bir iş. Firecrawl'ın sözlüğüne göre düz bir HTTP isteği yalnızca statik HTML'i getiriyor. Render etmek her sayfa için tam bir tarayıcı çalıştırmak demek.

AI crawler'ları için tek bir ölçüm var. Vercel ve MERJ'in Aralık 2024 çalışmasında OpenAI, Anthropic, Meta, ByteDance ve Perplexity botlarının hiçbiri JavaScript çalıştırmadı. ChatGPT ve Claude botları JavaScript dosyalarını çekti ama çalıştırmadı. Aynı çalışmaya göre Gemini, Googlebot altyapısını kullandığı için render ediyor.

Aralık 2024'ten sonra yeni bir birincil ölçüm bulamadık ve botların sahipleri render konusunda bir şey yazmıyor. Google dışındaki crawler'ların ilk HTML'i okuduğunu varsayın.

W3Techs'e göre Eylül 2026'da izlenen sitelerin %98,9'u JavaScript kullanıyor. JavaScript SEO açısından JavaScript'ten kaçınmak bir seçenek sayılmaz. Seçilebilecek olan, içeriğin nerede üretildiği.

Google'ın Neyi Render Ettiği Nasıl Kontrol Edilir

Google bu iş için iki araç gösteriyor. Google Search Console'daki URL Inspection aracı indeksteki sürümü View crawled page, canlı testi View tested page altında gösteriyor. Rich Results Test aynı render'ı mülk erişimi olmadan çalıştırıyor.

İki araç da yüklenen kaynakları, konsol çıktısını ve render edilmiş DOM'u gösteriyor. Ekran görüntüsüne güvenmek yerine render edilmiş HTML'de arama yapın. WebGL, WebSocket ve izin hataları yalnızca konsolda görünüyor, çünkü kendi tarayıcınız üçünü de destekliyor.

Mobile-Friendly Test artık bu listede yer almıyor. Google aracı, Mobile Usability raporuyla birlikte 1 Aralık 2023'te kapattı.

Tarayıcıda JavaScript'i kapatmak başka bir soruyu cevaplıyor. Googlebot render ettiği için bu test Google'ın gördüğünü göstermiyor. Gösterdiği, hiç render etmeyen bir crawler'ın okuyacağı sürüm.

Kontrolleri her şablondan bir sayfada bu sırayla yapın:

  1. Hata URL'lerinin gerçek bir 404 döndüğünü doğrulayın.
  2. view-source açın ve ilk HTML'de noindex, canonical etiketi, title ve ana navigasyonu bulun.
  3. URL Inspection'da canlı test çalıştırın ve render edilmiş HTML'de metninizi ve linklerinizi arayın.
  4. Konsolda, kendi tarayıcınızın hiç vermediği hataları okuyun.

Yalnızca bir tıklamadan, kayıtlı bir çerezden ya da bir WebSocket mesajından sonra görünen içeriğin yeri ilk yanıt. Bu taşıma, sayfanın önemli kısmında JavaScript SEO riskini render queue'dan bağımsız hâle getiriyor.

Sıkça Sorulan Sorular

Google JavaScript'i render eder mi?

Evet. Googlebot render işini evergreen bir Chromium ile yapıyor ve 200 durum kodu dönen her sayfa render queue'ya giriyor. Başka bir durum kodu dönen ya da noindex taşıyan sayfalarda render atlanabiliyor.

Google JavaScript'i ne kadar sürede render eder?

Google bir sayfanın birkaç saniye ya da daha uzun bekleyebileceğini söylüyor. 2024'te nextjs.org üzerinde 37.000'den fazla render'ı kapsayan ölçüm, medyanı 10 saniye, 90. yüzdeliği yaklaşık 3 saat buldu.

Client-side rendering SEO için kötü mü?

Tek başına kötü sayılmaz, çünkü Google client-side içeriği render ediyor. Ancak görünürlüğü render queue'ya, taranabilir script'lere ve render motorunun sınırlarına bağlıyor. Google bunun yerine server-side rendering, static rendering ya da hydration öneriyor.

Dynamic rendering hâlâ öneriliyor mu?

Hayır. Google'ın dokümanı dynamic rendering'i geçici bir çözüm olarak tanımlıyor ve karmaşıklık ile kaynak ihtiyacı yüzünden önermiyor. Bing'in 2018 tavsiyesi, Bing'in Ekim 2019'da Edge tabanlı evergreen render motoruna geçmesinden önce yazıldı.

Google'ın gördüğü render edilmiş HTML nasıl görülür?

Google Search Console'daki URL Inspection aracını kullanın. Mülkünüz dışındaki sayfalar için Rich Results Test aynı işi görüyor. İki araç da render edilmiş HTML'i, yüklenen kaynakları ve konsol hatalarını gösteriyor.

Kaynaklar ve Referanslar

Üç nokta yukarıdaki kaynaklarda yazılı değil ve Beaked'in kendi analizidir: "9 kat" rakamının bir zincir keşfi ölçümü olarak okunması, render beklemesinin render'a bağlı link zinciri boyunca birikmesi ve JavaScript kapalı testin Googlebot'u değil render etmeyen crawler'ı göstermesi.

Google'ın render queue'sunu kendi sitemizde ölçmedik; bu yüzden buradaki her sayı başkasına ait ve tarihi ile kapsamını taşıyor. Dolaşımdaki JavaScript SEO rehberlerinin iddialarını Google Search Central, Search Console Yardım, Bing Webmaster Blog ve Vercel ile MERJ'in iki çalışmasıyla karşılaştırdık. Üç iddia bu kontrolden geçemedi: kapatılmış bir test aracı, güncelmiş gibi sunulan 2018 tarihli bir Bing tavsiyesi ve tarihsiz bir yavaşlama rakamı.

Beaked

Gerçek gelir artıran veriye dayalı SEO, e-ticaret pazarlaması, performans pazarlaması ve potansiyel müşteri edinimi. Her kampanya ölçülebilir bir geri dönüş sağlar ve bütçe, dönüşüm getiren alanlara aktarılır. GEO, yapay zeka destekli aramalarda markanızın görünür kalmasını sağlar.

sales@beaked.io
+90 510 220 24 71
Fatih Sultan Mehmet Mah. Balkan Cad. Meydan İstanbul AVM NO: 62/A Ümraniye / İstanbul

Hizmetler

Legal

© 2026 Beaked Agency. All rights reserved.