JavaScript, SSR ve AI Tarayıcıları: Siteniz Yapay Zekaya Görünüyor mu?

Hangi yapay zeka tarayıcısı JavaScript çalıştırıyor?

Neredeyse hiçbiri. Ölçümlere göre GPTBot, ClaudeBot ve PerplexityBot dahil büyük yapay zeka tarayıcılarının (crawler) %69'u JavaScript çalıştıramıyor. İçeriğiniz yalnızca JavaScript çalıştıktan sonra ekrana geliyorsa bu botlar gerçek anlamda boş bir sayfa görür — hata almazlar, 404 dönmez, sadece okuyacak bir şey bulamazlar. Bu eşiği geçmeden GEO tarafında yaptığınız içerik çalışmasının karşılığını almanız mümkün değil.

Burada çoğu ekibin gözden kaçırdığı bir nüans var. "JavaScript indirmek" ile "JavaScript çalıştırmak" iki ayrı iştir. GPTBot isteklerinin %11,5'inde bir JavaScript dosyası çekiyor; ClaudeBot bu oranı %23,84'e taşıyor. İkisi de dosyayı alıyor, ikisi de çalıştırmıyor.Sunucu loglarınızda .js uzantılı istekler görüp "demek ki render ediyor" diye düşünmek, bu yüzden sık yapılan ve pahalıya patlayan bir çıkarım. Fetch, execute değildir.

Aşağıdaki tablo Haziran 2026 itibarıyla gözlenen davranışı özetliyor. Bot yetenekleri sabit değil; bunu ezberlenecek bir liste değil, o günün fotoğrafı olarak okuyun. Kendi sitenizde ne olduğunu ise en sonda anlattığım testlerle doğrudan görebilirsiniz.

Tablodaki "tür" sütunu, çoğu tartışmanın atladığı ayrımı taşıyor. Eğitim botları (GPTBot, ClaudeBot, Bytespider) model eğitimi için veri toplar; getirim botları (OAI-SearchBot, Claude-SearchBot, PerplexityBot) kullanıcının az önce sorduğu soruya yanıt üretmek için sitenize gelir.İkisi de JavaScript çalıştıramıyor. Ama getirim botları sitenizi geçmişte bir ara değil, şu anda okuyor — ve okuyamadıklarında kaybettiğiniz şey gelecekteki bir eğitim seti değil, bu haftaki ChatGPT atıfları.

Bot davranışını erişim tarafından yönetmek ayrı bir konu; hangi botu içeri alacağınıza karar vermek için yapay zeka botları ve robots.txt sayfasına bakın. Bu sayfanın konusu ise şu: botu içeri aldınız, peki içeride ne buluyor?

Hydration gap: kullanıcı için milisaniye, bot için kalıcı boşluk

Hydration gap, sunucunun HTML'i gönderdiği an ile istemci tarafındaki JavaScript'in sayfayı içerikle doldurduğu an arasındaki penceredir. İnsan kullanıcı için bu pencere birkaç yüz milisaniye — fark etmez bile. GPTBot ya da ClaudeBot içinse kapanmayan bir boşluktur, çünkü o pencereyi kapatacak kodu hiç çalıştırmazlar.

Somutlaştıralım. Bir e-ticaret katalog sayfasında ürün adı ve sayfa iskeleti sunucu tarafında render ediliyor; spesifikasyon tablosu, fiyat, stok durumu ve JSON-LD ise bileşen mount olduktan sonra gelen API çağrısıyla yerleşiyor. Ekranda her şey yolunda. Yapay zeka tarayıcısının gördüğü ise yalnızca ürün adı: altmış dolu özellik hiçbir indekse girmiyor.Aynı sayfa Google'da üst sıralarda durabilir, çünkü Googlebot render ediyor. Bu da yanlış bir güven duygusu üretir — teknik SEOtarafında hiçbir alarm çalmaz.

Son bir yılda bu sorunun yeni bir kaynağı çıktı: yapay zeka destekli kodlama araçları. Build hatasını en hızlı yoldan susturmak için dosyanın başına'use client' direktifini ekliyorlar. Direktif işe yarıyor, hata kayboluyor, kimse geri dönüp bakmıyor. Oysa o tek satır koca içerik bloklarını istemci tarafına itiyor ve bloğu yapay zeka tarafına görünmez kılıyor.Kod incelemelerinde aranacak şey artık bu: gerekçesiz eklenmiş istemci direktifleri.

"SSR kullanıyoruz" demek de tek başına yetmiyor. Streaming SSR ve kısmi hidrasyon gibi yaklaşımlarda sayfanın bir bölümü sunucudan gelirken kalanı sonradan akıyor; bot ilk yanıtı alıp bağlantıyı kapattığında akan kısmı hiç görmemiş oluyor. Aynı şekilde çerez onayı arkasına gizlenen içerik, "devamını oku" ile açılan bloklar ve sekmeli arayüzlerin pasif sekmeleri de ham HTML'de bulunmayabiliyor. Ölçüt basit: içerik ilk sunucu yanıtının gövdesinde var mı, yok mu?

Sunucudan ne geldiği kadar, ne sırayla geldiği de sayıyor. ChatGPT atıflarının %44,2'si sayfanın ilk %30'luk bölümünden geliyor.Yani cevabı sayfanın üçte birlik ilk diliminde vermek, aşağıda ne yazdığınızdan daha belirleyici. Bunu içerik tarafında nasıl kuracağınıziçerik parçalama konusunun işi; teknik tarafta karşılığı, o ilk dilimin sunucudan hazır gelmesi.

SSR neden teknik değil gelir meselesi?

Çünkü yapay zeka üzerinden gelen ziyaretçi, arama trafiğinden çok daha yüksek niyetle geliyor. Bir ölçümde yapay zeka kaynaklı ziyaretlerin dönüşüm oranı %14,2, Google organik trafiğinde ise %2,8 çıktı — beş kat fark. Render edemediği için ürün sayfanızı okuyamayan bir bot, size trafik değil, doğrudan ciro kaybettiriyor.

Bu dönüşüm farkı tek bir sağlayıcının ölçümü; nesnel bir sabit gibi okumayın. Yine de yönü mantıklı: kullanıcı yapay zekaya sorusunu sorup karşılaştırmayı yaptırdıktan sonra sitenize geliyor, yani araştırma aşamasını dışarıda tamamlamış oluyor. Aynı ölçüm setinde ChatGPT atıflarının %20,1'i doğrudan ürün sayfalarına yapılıyor.Ürün sayfası, JavaScript sorununun en yoğun olduğu sayfa tipi. Çakışma tam olarak burada.

Hızın da bir payı var. İlk içerikli boyama (FCP) süresi 0,4 saniyenin altında olan sayfalar ortalama 6,7 ChatGPT atıfı alırken, daha yavaş sayfalar 2,1'de kalıyor.Buradan "sayfayı hızlandırın, atıf gelsin" sonucu çıkmaz; bu bir korelasyon. Hızlı sayfalar genellikle teknik bakımı düzgün, sunucudan render eden sitelerde bulunur — muhtemelen ölçülen şey hızın kendisi değil, hızı üreten disiplin.Core Web Vitals tarafında yaptığınız iş burada da işinize yarıyor, ama nedenselliği tersten kurmayın.

Ölçek tarafında çarpıcı bir vaka var: bir SPA'ya pre-rendering eklendikten sonra yapay zeka botları tüm sayfa isteklerinin %47,95'ini oluşturmuş.Tek vaka, genelleme değil. Ama sunucunuzun kapasite planında artık ikinci bir kitle olduğunu hatırlatıyor: sayfalarınızı insanlar kadar sık isteyen, hiç tıklama üretmeyen, buna karşılık sizi yanıtlara sokan bir kitle.

Bu ikinci kitlenin bütçeye yansıması iki yönlü. Bir yandan sunucu maliyeti ve önbellek stratejisi yeniden düşünülmeyi gerektiriyor; diğer yandan trafik raporlarında görünmeyen bir görünürlük kanalı açılıyor. Yapay zeka botlarının ziyaretleri oturum sayınıza yazılmıyor, ama o ziyaretlerde okudukları içerik kullanıcının önüne yanıt olarak çıkıyor. Klasik analitik bakışıyla "değersiz trafik" diye kesilen bot erişimi, aslında satış hunisinin en üstündeki katman hâline geldi.

Hangi rendering stratejisi hangi sayfaya?

Tek doğru cevap yok; sayfanın işine bakılır. İçeriği yapay zekaya görünmesi gereken her sayfa — makaleler, servis sayfaları, ürün sayfaları — sunucudan render edilmeli. Katalog gibi hacimli ama yavaş değişen bölümlerde ISR sunucu yükünü düşürür. Etkileşimli arayüzlerde istemci tarafı render sorun değildir, çünkü zaten indekslenecek bir içerik yoktur.

Tablodaki en tehlikeli satır dynamic rendering. Prerender.io benzeri servisleri yalnızca Googlebot user-agent'ı için tetikleyen kurulumlar hâlâ yaygın; bu kurulumda GPTBot ve PerplexityBot boş sayfayla karşılaşmaya devam eder.Google da bu yaklaşımı yıllardır kalıcı bir çözüm değil, geçici bir yama olarak tanımlıyor.Dynamic rendering kullanmaya devam edecekseniz en azından bot listesini genişletin; aksi hâlde yapay zeka tarafında hiçbir şey çözmemiş olursunuz.

Bir de beklemeye dair soru var. 2027'ye kadar yapay zeka tarayıcılarının %65'inin JavaScript'i destekleyeceği yönünde bir öngörü dolaşıyor.Bu bir tahmin, ölçüm değil — tutabilir de tutmayabilir de. Kararı değiştirmiyor: tahmin tutsa bile o tarihe kadar geçen sürede içeriğiniz yanıtlara girmeyecek, tutmazsa zaten SSR'siz kalıcı olarak görünmez olacaksınız. Her iki senaryoda da yapılacak iş aynı.

Nereden başlamalı: düzeltme sırası

Tüm siteyi bir anda SSR'a taşımak nadiren gerçekçi. Önce şablonları etkiye göre sıralayın: yapay zekanın alıntılamasını istediğiniz sayfa tipleri — ürün, kategori, rehber içerik, servis sayfaları — ilk sırada. Ardından o şablonlarda hangi alanların istemci tarafında kaldığını çıkarın. Genellikle sayfanın tamamı değil, üç beş alan sorunlu oluyor ve düzeltme sanıldığından küçük çıkıyor.

Şablon envanteri çıkarmanın hızlı yolu şu: her sayfa tipinden bir örnek alın, cURL çıktısıyla tarayıcıdaki görüntüyü yan yana koyun ve eksik alanları listeleyin. Bu liste doğrudan iş emrine dönüşür. Deneyimime göre listenin başında hep aynı şeyler oluyor: fiyat, stok, varyantlar, yorum özeti ve JSON-LD. Bunlar sayfanın kelime sayısının küçük bir bölümü, ama yapay zekanın bir ürünü yanıtta önerebilmesi için ihtiyaç duyduğu bilginin neredeyse tamamı.

Framework tarafında karşılıkları kabaca şöyle. Next.js App Router'da iş,'use client' sınırını yaprak bileşenlere itmek ve veriyi sunucu bileşeninde çekmek; etkileşim gerektiren küçük parçalar istemcide kalabilir, metin ve veri kalmamalı. Nuxt tarafında useAsyncData ile sunucudan gelen veriyi ilk yanıtın parçası yapmak yeterli oluyor. Astro gibi varsayılanı statik olan kurulumlarda sorun genellikle "island" olarak işaretlenmemesi gereken bileşenlerin işaretlenmesinden çıkıyor. WordPress üzerinde React tabanlı bir tema veya blok kullanılıyorsa, kontrol edilecek şey blokların sunucu tarafında da render edilip edilmediği.

Katalog büyükse ISR'ı ciddi biçimde değerlendirin. Bir spesifikasyon tablosunun dakikada bir tazelenmesi gerekmiyor; fiyat ve stok gibi hızlı değişen alanları sunucudan gelen HTML'e yazıp gerisini belirli aralıklarla yenilemek, hem sunucu yükünü hem de bakım maliyetini makul tutuyor. Sunucu tarafında her isteği canlı render etmek, on binlerce ürünlü bir katalogda hızla bir altyapı sorununa dönüşür.

Son olarak bir ölçüm noktası kurun. Düzeltmeden önce ve sonra, aynı şablonlar için cURL çıktısındaki içerik uzunluğunu kaydedin; sunucu loglarında yapay zeka botlarının aldığı yanıt boyutunu izleyin. Değişimi somut bir sayıyla göstermek, bir sonraki teknik bütçeyi almanın en kolay yolu.

Türkiye'de bu sorun nerede birikiyor?

İki yerde: hazır e-ticaret altyapılarına sonradan eklenen istemci tarafı bileşenlerde ve ajans eliyle yapılan headless geçişlerde. Türkiye'deki mağazaların büyük bölümü Ticimax, İdeaSoft, T-Soft, Shopify, WooCommerce ya da OpenCart üzerinde duruyor. Bu altyapıların çekirdek şablonları sunucudan HTML üretir — yani temel sağlamdır. Sorun çekirdekte değil, üzerine eklenen katmanda başlıyor.

Tipik senaryo şöyle işliyor. Ürün sayfası sunucudan geliyor, ama beden ve renk varyant seçicisi, taksit tablosu, kargo süresi hesaplayıcısı, yorum modülü ve "benzer ürünler" bloğu üçüncü taraf bir widget olarak JavaScript'le sonradan yerleşiyor. İnsan için sayfa zenginleşiyor. PerplexityBot içinse ürün sayfası fiyatsız, yorumsuz, varyantsız bir başlıktan ibaret kalıyor — üstelik JSON-LD de çoğu zaman aynı widget'la beraber geldiği içinyapay zeka için schematarafı da boşa düşüyor.

Kategori sayfalarında mekanizma biraz farklı. Filtreleme ve sıralama hızlı hissettirsin diye tamamen istemci tarafına alınıyor; ilk yükte gelen HTML'de ürün listesi ya hiç yok ya da ilk birkaç ürünle sınırlı. Sonsuz kaydırma varsa durum daha kötü: bot ilk ekranın ötesini hiç görmüyor. Türkçe sorgularda yapay zekanın seçebileceği kaynak havuzu İngilizceye kıyasla dar olduğu için, listeden düşmenin bedeli de orantısız biçimde yüksek.

Headless geçişler ise sorunun daha pahalı versiyonu. Son yıllarda kurumsal markalarda "Next.js ile headless'a geçelim" kararı sık veriliyor ve teknik olarak doğru bir karar. Ancak proje sonunda ortaya çıkan şey çoğu zaman Next.js kabuğu içinde çalışan bir istemci uygulaması oluyor: veri storefront API'sindenuseEffect içinde çekiliyor, sayfa isteğe bağlı olarak dinamikleşiyor,'use client' ağacın tepesine çıkıyor. Kabul testlerinde kimse ham HTML'e bakmadığı için sorun aylarca fark edilmiyor.

Bir de dil katmanı var. Türkçe içerikte yapay zekanın seçebileceği kaynak sayısı sınırlı olduğu için, doğru yapılandırılmış tek bir sayfa İngilizce bir pazarda olacağından daha fazla yer kaplayabiliyor. Bunun tersi de geçerli: kategorinizde ham HTML'i temiz olan üç rakip varsa, yanıtlarda sürekli o üçü görürsünüz. Görece küçük bir teknik düzeltmenin görünürlük getirisinin bu kadar yüksek olmasının nedeni, havuzun dar olması.

Pratik öneri: geçiş projelerinin kabul kriterlerine tek satır ekleyin — "kritik şablonların her birinde fiyat, stok, açıklama ve JSON-LD, JavaScript kapalıyken ham HTML'de görünür olacak". Bu maddeyi sözleşmeye koymak, canlıya çıktıktan sonra yapılacak refactor'un maliyetinin yanında bedava kalıyor. Denetimi bir çerçeveye oturtmak istersenizGEO teknik denetimadımlarını takip edebilirsiniz.

Sitenizi test edin: yapay zeka tarayıcısı ne görüyor?

Teşhis için araç satın almanız gerekmiyor. Sayfanın ham kaynağına bakmak, cURL ile tek bir istek atmak ve JavaScript'i kapatıp yenilemek — bu üçü on dakikada net bir cevap veriyor. Ölçeği büyütmek gerektiğinde tarama araçları ve sunucu logları devreye giriyor. Sıra önemli: önce teşhis, sonra ölçüm.

Ham kaynağa bakın

Ctrl+U ile sayfanın sunucudan gelen HTML'ini açın ve içerikte aradığınız metni orada arayın. Boş <div> kabukları ve<script> etiketlerinden başka bir şey yoksa GPTBot, ClaudeBot ve PerplexityBot da aynı boşluğu görüyor demektir.DevTools'un Elements sekmesini bu iş için kullanmayın: orada gördüğünüz DOM, JavaScript çalıştıktan sonraki hâldir ve size her zaman iyi haber verir.

cURL ile botun bakış açısını taklit edin

Tarayıcı devrede olmadığı için cURL, bir yapay zeka tarayıcısının gördüğüne çok yakın bir çıktı verir:

curl -s "https://siteniz.com/sayfa" | grep -i "json-ld\|product\|<table"

Çıktıda JSON-LD bloğunu ve gerçek içerik değerlerini — fiyatı, spesifikasyonu, tablo satırlarını — görüyorsanız sunucu tarafı render çalışıyor.Boş dönüyorsa ya da yalnızca şablon iskeletini alıyorsanız teşhis konmuş demektir. Aynı komutu ürün, kategori, blog ve servis sayfası için ayrı ayrı çalıştırın; çoğu sitede şablonlar arasında ciddi fark çıkıyor.

JavaScript'i kapatıp yenileyin

Geliştirici araçlarından JavaScript'i devre dışı bırakın ve sayfayı yenileyin. İçerik kayboluyorsa SSR ya da pre-rendering şart. Testi mobil genişlikte de tekrarlayın; bazı temalarda mobil şablon masaüstünden farklı davranıyor ve içeriğin daha büyük bölümü sonradan yükleniyor.

Tarama araçlarıyla ölçeği büyütün

Tek tek sayfa kontrolü teşhis için yeterli, envanter için değil. Screaming Frog'da JS rendering açıkken "JS" sekmesindeki render edilmiş kelime sayısı değişim yüzdesine bakın: yüksek fark, o sayfada içeriğin JavaScript'e bağlı olduğunu söyler. Sitebulb'ün Response vs Render raporu aynı farkı doğrudan gösteriyor.Google Search Console'daki "İncelenen sayfayı görüntüle" özelliği ise yalnızca Google'ın ne gördüğünü verir — yapay zeka tarayıcıları için iyimser bir tablo çizdiğini akılda tutun.

Sunucu loglarını okuyun

Log dosyalarında GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot ve PerplexityBot ziyaretlerini filtreleyin. Bakılacak iki şey var: 200 durum kodu alıyorlar mı, ve aldıkları yanıtın boyutu ne kadar?Her isteğe 200 dönüyor ama yanıt boyutu şablon iskeletiyle aynıysa, bot içeri giriyor ve elleri boş çıkıyor demektir. Bu, tek bir sayfa testinden çok daha güvenilir bir kanıt.Perplexity tarafındaki davranışı izlemenin en doğrudan yolu da bu.

Temel sinyalleri statikleştirin

Canonical etiketi ve metadata JavaScript ile enjekte edilmemeli;<head> içinde statik durmalı. JSON-LD ilk sunucu yanıtında bulunmalı — sonradan eklenen schema, render etmeyen bir bot için hiç yok demektir.Karşılaştırma verisi sunuyorsanız HTML tablo biçimini tercih edin; tablolar ayrıştırılması en kolay yapılardan biri.Bu arada llms.txt dosyasının getirim davranışı üzerinde maddi bir etkisi Haziran 2026 itibarıyla hiçbir büyük platform tarafından doğrulanmadı; dosyayı koymak zararsız ama render sorununun yerine geçmiyor.

Render katmanı, yapay zeka görünürlüğünün en somut ve en hızlı düzelen kısmı — ama tek başına yeterli değil. Sitenizin yapay zeka yanıtlarındaki konumunu içerik, varlık ve teknik taraflarıyla birlikte ele almak istersenizGEO danışmanlığı sayfasına göz atın.

Sıkça Sorulan Sorular

GPTBot hiç JavaScript çalıştırmıyor mu?

Hayır. Haziran 2026 itibarıyla GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot ve PerplexityBot dahil büyük yapay zeka tarayıcılarının tamamı JavaScript render etmiyor. GPTBot isteklerinin bir kısmında JavaScript dosyasını indiriyor, ancak indirmek çalıştırmak anlamına gelmiyor.

ChatGPT Operator diğer botlardan farklı mı?

Evet, farklı. Ocak 2025'te tam JavaScript render ve bilgisayarlı görü yetenekleriyle tanıtıldı; bir tarayıcıyı gerçekten sürüyor. Ama Operator bir kullanıcının talebiyle tekil sayfalara giden bir ajan, sitenizi sistematik olarak tarayan bir bot değil. GPTBot veya OAI-SearchBot ile aynı kefeye koyup "demek ki OpenAI render ediyor" sonucuna varmak yanıltıcı olur.

Gemini veya Copilot için SSR şart mı?

Doğrudan şart değil. Gemini ve Copilot canlı arama kullandığında zaten render edilmiş arama indekslerinden yararlanıyor; Googlebot ve Bingbot işi önceden yapmış oluyor. Tek ölçüme göre ChatGPT'nin web arama yanıtlarının yaklaşık %92'si Bing indeksinden besleniyor. Yine de bu, SSR'siz kalmanın güvenli olduğu anlamına gelmez: ChatGPT, Claude ve Perplexity'nin kendi botları sitenize doğrudan geliyor ve orada arama indeksinin koruması yok.

llms.txt dosyası yapay zeka görünürlüğünü artırıyor mu?

Şu an için kanıtlanmış bir etkisi yok. Hiçbir büyük platform dosyayı kullandığını doğrulamadı.

Yapay zeka kodlama araçları SSR kurulumunu bozuyor mu?

Bozabiliyor. Build hatasını hızlıca gidermek için dosyaların başına'use client' direktifi ekliyorlar; direktif hatayı susturuyor ama içerik bloğunu istemci tarafına taşıyor. Kod incelemesinde gerekçesiz eklenmiş istemci direktiflerini aramak, bu sorunun en ucuz önlemi.

Dynamic rendering yeterli bir çözüm mü?

Geçici yama olarak iş görüyor, uzun vadeli strateji değil. Google yıllardır bu yaklaşımı geçici çözüm diye tanımlıyor. Kullanacaksanız bot listesine yapay zeka tarayıcılarını da eklediğinizden emin olun; yalnızca Googlebot için kurulmuş bir dynamic rendering, bu sayfada anlatılan sorunun hiçbirini çözmez.

Google'da iyi sıralanıyorum, yine de sorun olabilir mi?

Evet, hatta en sık karşılaşılan durum bu. Googlebot JavaScript çalıştırdığı için sayfanız Google'da sorunsuz görünür ve hiçbir SEO aracı alarm vermez. Yapay zeka tarayıcıları aynı sayfayı boş okur. İki kanalın teşhisi ayrı yapılmalı; Search Console'un yeşil olması yapay zeka tarafı hakkında bilgi vermiyor.

Sitemin tamamını SSR'a taşımam gerekiyor mu?

Hayır. Yapay zekanın alıntılamasını istediğiniz şablonlarla sınırlı kalabilirsiniz. Sohbet arayüzü, hesaplayıcı, harita gibi etkileşimli bileşenlerin istemci tarafında kalması sorun değil — orada indekslenecek bir içerik zaten yok. Kritik olan, ürün ve içerik sayfalarındaki metin, fiyat, stok ve schema verisinin ilk sunucu yanıtında bulunması.