Sayfa Hızı AI Görünürlüğünü Etkiler mi? LCP, TTFB ve Gerçek Kullanıcı Verisi

Sayfa hızı AI görünürlüğünü tek bir yoldan etkilemez, çünkü kullanıcının tarayıcıda gördüğü hız ile AI botunun sunucudan aldığı yanıt aynı şey değildir. Sheltron'un gerçek kullanıcı ölçümünde (RUM), Nisan–Ağustos 2026 döneminde p75 LCP değeri 41,2 saniye olan bir blog URL'si, 9 Ağustos 2026'ya uzanan 365 günde Microsoft Copilot'ta 84 kez kaynak gösterilmişti. Google'ın web.dev ölçeğinde LCP için "iyi" eşik 2,5 saniye; bu sayfa eşiğin 16 katından daha yavaştı ve yine de alıntılandı.

Bu yazı iki hız katmanını birbirinden ayırıyor: tarayıcıda ölçülen LCP, INP ve CLS ile botun doğrudan yaşadığı TTFB, HTML boyutu ve HTTP durum kodları. 9 Ağustos 2026'da çekilen 11.767 RUM kaydını, 29 Eylül 2026'da AI ve arama botu user-agent'larıyla (karşılaştırma için Chrome dahil) yaptığımız 126 isteklik ölçümle ve AI botlarının zaman aşımı hakkında Eylül 2026 itibarıyla bulunabilen tek somut veriyle birlikte okuyoruz. Hızın atıfı mı, yoksa atıftan gelen ziyaretçinin davranışını mı etkilediği sorusunu da nedensellik iddiası kurmadan tartışıyoruz.

Sayfa hızı AI görünürlüğünü nasıl etkiler? Önce iki hız katmanını ayırın

Sayfa hızı AI görünürlüğünü iki ayrı katmanda etkiler. Kullanıcı katmanı LCP, INP ve CLS ile tarayıcıda ölçülür; bot katmanı ise TTFB, HTML boyutu ve HTTP durum kodlarından oluşur. AI botları sayfayı çizmediği için LCP'yi yaşamaz; onlar için belirleyici olan, sunucunun ilk baytı ne kadar hızlı ve hangi içerikle gönderdiğidir.

Tanımlar bu ayrımı netleştiriyor. web.dev'e göre LCP, görünür alandaki en büyük görselin, metin bloğunun ya da videonun tarayıcıda çizildiği anı ölçer. Ölçüt, mobil ve masaüstü ayrı ayrı olmak üzere sayfa yüklemelerinin 75. yüzdelik dilimidir (p75). TTFB ise sayfaya gezinmenin başladığı an ile yanıtın ilk baytının gelmeye başladığı an arasındaki süredir; yönlendirme, DNS, bağlantı ve TLS kurulumu bu süreye dahildir. Tarayıcıdaki standart karşılığı, W3C'nin Navigation Timing belirtimindeki responseStart değeridir.

Google'ın Web Vitals çerçevesinde Core Web Vitals yalnız üç metrikten oluşur: LCP, INP ve CLS. TTFB ve FCP bu üçlünün parçası değildir; LCP sorunlarını teşhis etmeye yarayan yardımcı metrikler olarak tanımlanır. AI görünürlüğü açısından tablo tersine döner: botun doğrudan yaşadığı tek hız metriği TTFB'dir.

Bot katmanı web genelinde de zayıf halka. HTTP Archive Web Almanac 2025 verisine göre iyi TTFB oranı (0,8 saniyenin altı) mobilde yalnız %44, masaüstünde %55. Core Web Vitals'ın üçünü birden geçme oranı ise mobilde %48, masaüstünde %56. Mobilde web'in yarısından fazlası, gerçek kullanıcı verisinde ilk bayt metriğinde "iyi" bandın dışında kalıyor; sunucu tarafı yavaşsa bu gecikme botlara da yansır.

Google'ın sıralama tarafındaki tutumu da bu ayrımla uyumlu. Page experience dokümanı "Core Web Vitals are used by our ranking systems" diyor, ama hemen ardından Google Arama'nın sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeye çalıştığını ekliyor. Hız bir sinyaldir, alakanın yerine geçmez.

AI botları hangi hızı yaşar: ilk bayt, yanıt boyutu ve durum kodu

Büyük AI tarayıcıları sayfayı bir tarayıcı gibi çizmez; HTML'i indirir ve metni oradan okur. Vercel'in Aralık 2024 analizine göre büyük AI tarayıcılarının hiçbiri JavaScript çalıştırmıyordu. Bot için belirleyici olan bu yüzden LCP değil; ilk baytın ne kadar sürede geldiği ve HTML'in içeriği JavaScript olmadan taşıyıp taşımadığıdır.

Vercel'in ölçümünde GPTBot ayda 569 milyon, Claude'un tarayıcısı 370 milyon istek yapıyordu; büyük AI tarayıcılarının toplamı Googlebot'un 4,5 milyar isteğinin yüzde 28'ini biraz aşıyordu. Aynı analizde ChatGPT isteklerinin %34,82'si, Claude isteklerinin %34,16'sı 404 ile sonuçlanmıştı. Yani ChatGPT ve Claude isteklerinin üçte birinden fazlası, hız konusu gündeme gelmeden bulunamayan sayfalara takılıyordu. Cloudflare de 2025 tarayıcı raporunda AI ve arama botu trafiğinin Mayıs 2024 ile Mayıs 2025 arasında %18 arttığını yazıyor.

Google tarafında durum biraz farklı. JavaScript SEO dokümanı Googlebot'un sayfaları render kuyruğuna aldığını, bunun birkaç saniye ya da daha uzun sürebildiğini söylüyor ve ekliyor: sunucu tarafı render hâlâ iyi bir fikir, çünkü her bot JavaScript çalıştıramıyor. Googlebot dokümanına göre desteklenen dosya tiplerinde yalnız ilk 2 MB taranıyor. İçeriği istemci tarafında yükleyen, ağır bir HTML gönderen ya da sık 5xx veren site, botların okuduğu metni kısaltır.

EdgeComet'in testinde de ChatGPT-User'ın HTML'i alıp JavaScript çalıştırmadan durduğu görüldü. Metin ham HTML'de değilse bu botlar için sayfa fiilen boştur. Ham HTML'deki yapının atıfı nasıl etkilediğini LLM'lerin sayfanın neresinden alıntı yaptığını incelediğimiz yazıda ayrıca ele almıştık.

Sheltron ölçümü: 6 bot ve 1 tarayıcı user-agent'ıyla 126 istek

Bot katmanını kendi sitemizde test etmek için 29 Eylül 2026'da 6 canlı blog URL'sine 7 farklı user-agent dizesiyle (Chrome, GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, bingbot) üçer istek gönderdik: toplam 126 istek. Seçilen sayfalar master rehber, en çok atıf alan rapor ve RUM verisinde en yavaşlar arasında yer alan dört canlı sayfaydı. TTFB curl ile ölçüldü, ham HTML'deki <h2 etiketleri sayıldı.

126 isteğin 126'sı HTTP 200 döndü. Medyan TTFB 0,354 saniye, en yüksek değer 0,412 saniyeydi. User-agent'lar arasında anlamlı fark çıkmadı: medyanlar 0,348 ile 0,358 saniye arasında kaldı. Her sayfa ham HTML'de 15–18 H2 başlığıyla, yani tam metniyle geldi. Gerçek kullanıcıya p75'te 18,9–37,3 saniyede çizilen sayfalar, bot user-agent'larına 0,35 saniye civarındaki medyan TTFB ile ve eksiksiz yanıt veriyordu.

Bu ölçümün sınırları açık. Gerçek botlar değil, yalnız onların user-agent dizeleri kullanıldı; CDN gerçek botları IP adresine göre farklı işleyebilir. Ölçüm tek istemciden ve tek anda yapıldı; bir örnek istekte yanıt başlıkları sayfanın CDN önbelleğinden geldiğini gösterdi, yani önbelleğe alınmamış bir sayfada TTFB daha yüksek çıkabilir. Kullanıcı RUM verisi ise Firebase dönemine ait; iki katman aynı altyapıyı ölçmüyor.

LCP'si 41 saniye olan sayfa nasıl 84 atıf aldı?

Yavaş bir sayfa da alıntılanabilir, çünkü LCP tarayıcıdaki en büyük öğenin çizilme süresidir; botun okuduğu metin bu çizimi beklemez. Sheltron'un RUM verisinde p75 LCP'si 18 saniyeyi aşan 7 blog path'inden 3'ü toplam 165 Copilot atıfı almıştı. En çok atıf alan sayfa (224 atıf) ise 3.712 ms ile "iyileştirilmeli" bandındaydı. Bu bir korelasyon değil, bir karşı örnektir.

Aşağıdaki tablo iki ayrı dosyanın birleşimi: 9 Ağustos 2026'da çekilen RUM özetindeki en yavaş path'ler ve aynı gün dışa aktarılan 365 günlük Copilot atıf verisi. RUM özetinde yalnız en yavaş 10 path yer alıyor; bunlardan biri yönetim paneli olduğu için tabloya alınmadı.

Yavaş sayfaların aldığı 165 atıf, sitenin 365 günlük toplam 1.422 atıfının %11,6'sı ediyor. Sitenin en çok alıntılanan sayfası da hızlı değildi: 136 ölçümde p75 LCP 3.712 ms, yani web.dev ölçeğinde 2,5 ile 4,0 saniye arasındaki "iyileştirilmeli" bandı. Copilot'un kaynak seçiminde bu sayfaları eleyen bir hız eşiği görünmüyor.

Bu veriden çıkarılamayacak şeyler de var. Birincisi, örneklemler küçük: en kötü path'lerde ölçüm sayısı 11 ile 34 arasında. İkincisi, pencereler farklı: RUM Nisan–Ağustos 2026'yı, atıf verisi ise 365 günü kapsıyor. Üçüncüsü, elimizde yalnız en yavaş 10 path'in RUM özeti var; tüm sayfaların dağılımı olmadığı için hız ile atıf arasında bir korelasyon hesaplanamaz. RUM kaydı yavaşlığın nedenini de söylemez.

Bir not daha: 41 saniyelik URL artık yayında değil. Bu sayfa Temmuz 2026'da işletmeler için AI uyum master rehberine birleştirildi; yukarıdaki değerler Nisan–Ağustos 2026 RUM kaydına aittir.

AI botlarının zaman aşımı kaç saniye? Resmî bir değer yok

Eylül 2026 itibarıyla AI botları için resmî olarak yayımlanmış bir zaman aşımı değeri bulamadık; OpenAI'ın bot dokümanında hız, boyut ya da zaman aşımı şartı geçmiyor. Tek somut veri bağımsız bir satıcı testinden geliyor: ChatGPT-User 5 saniyeden sonra HTTP 499 ile vazgeçti, GPTBot ise 9 saniyeye kadar bekledi.

OpenAI'ın tarayıcı dokümanı botların ne işe yaradığını anlatıyor: OAI-SearchBot'u engelleyen sitelerin ChatGPT arama cevaplarında gösterilmeyeceğini, ChatGPT-User'ın ise web'i otomatik olarak taramak için kullanılmadığını yazıyor. Zaman aşımı, yanıt boyutu ya da hız eşiğiyle ilgili bir satır yok. Web'de dolaşan "OAI-SearchBot 3 saniyede vazgeçer" türü iddiaların izini sürdüğümüzde resmî bir kaynağa ulaşamadık.

Bu noktada kendi içeriğimizi de düzeltmemiz gerekiyor. CTO'lar için AI search altyapı kararları yazımızda "2-3 saniye üzerine çıkan site retrieval zaman aşımına uğruyor" ve "TTFB + LCP AI cevap kalitesini doğrudan etkiliyor" demiştik. İlk ifadenin yayımlanmış bir kaynağı yok; ikincisi ise yarı yarıya doğru, çünkü LCP botun yaşadığı bir metrik değil. Aynı yazıdaki "TTFB 800 ms'nin altında" hedefi ise web.dev eşiğiyle örtüşüyor ve geçerliliğini koruyor.

EdgeComet'in OpenSeoTest çalışması (Ocak 2026, Şubat 2026'da güncellendi) ChatGPT-User için "5 saniyeyi geçince bot tutarlı biçimde zaman aşımına uğruyor" diyor. Bu değeri kesin bir eşik gibi okumamak gerekir: EdgeComet bot render hizmeti satan bir şirket, gecikmenin nasıl üretildiğini ve kaç deneme yapıldığını açıklamıyor, test tek ve yeni bir alan adında yapılmış.

Belgelenmiş olan tek mekanizma Google'a ait. Tarama bütçesi dokümanına göre site yavaşlarsa, 5xx hatası ya da 429 gibi hız sınırı sinyali verirse tarama kapasitesi düşer ve Google daha az tarar. Pratikte güvenli yaklaşım, bilinmeyen eşiği tahmin etmek yerine TTFB'yi web.dev'in 0,8 saniyelik "iyi" sınırının altında tutmaktır. Bu, en temkinli bağımsız gözlem olan 5 saniyeye karşı geniş bir pay bırakır. Botların sitenize ne sıklıkla geldiğini ve karşılığında ne getirdiğini AI crawler ekonomisi yazımızda ayrıca inceledik.

CrUX'ta veriniz yoksa ne yapmalısınız? RUM ile kendi saha verinizi toplayın

CrUX yalnız yeterince popüler sayfa ve origin'leri kapsar; eşik açıklanmaz ve veri yoksa API 404 "chrome ux report data not found" hatası döner. Düşük trafikli sitelerde tek gerçek kullanıcı verisi kaynağı kendi RUM kurulumunuzdur: web-vitals kütüphanesi, sendBeacon ve basit bir toplama uç noktası yeterlidir.

Chrome UX Report'un yöntem dokümanı dahil olmayı iki koşula bağlıyor: sayfa herkese açık olarak keşfedilebilir ve "yeterince popüler" olmalı. Eşik açıklanmıyor; yalnız yeterli örnek toplanmasını sağlayacak şekilde seçildiği belirtiliyor. Veri varsa CrUX API 28 günlük kayan ortalama döndürüyor. Veri yoksa Search Console'daki Core Web Vitals raporu "No data available" gösteriyor. Düşük trafikli siteler için bu boş rapor bir hata değil, beklenen durumdur.

Kendi sitenizin CrUX'ta olup olmadığını tek bir istekle kontrol edebilirsiniz:

curl -s -X POST "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  -H "Content-Type: application/json" -d '{"origin":"https://ornek.com.tr"}'

Yanıt 404 ve "chrome ux report data not found" ise origin CrUX'ta yok; Google'ın CrUX API rehberi bu hatanın yetersiz örnek nedeniyle de oluşabileceğini söylüyor.

En sade RUM kurulumu

Google'ın açık kaynak web-vitals kütüphanesi her metriği ölçüp bir geri çağırma fonksiyonuna verir. Aşağıdaki örnek, kütüphanenin kendi dokümanındaki kalıba dayanıyor:

import {onCLS, onINP, onLCP, onTTFB} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id,
    path: location.pathname,
  });
  navigator.sendBeacon('/api/rum/', body);
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onTTFB(sendToAnalytics);

Kütüphane dokümanına göre onCLS yalnız Chromium tabanlı tarayıcılarda çalışıyor; LCP, INP, FCP ve TTFB ise Chromium, Firefox ve Safari'de ölçülebiliyor. CLS verinizin Safari kullanıcılarını içermeyeceğini baştan bilin.

Sheltron'un kurulumuna eklediği üç kural

Kendi sitemizde aynı kalıp üç ek kuralla çalışıyor. Birincisi, bot ve Lighthouse trafiği hem tarayıcıda hem sunucuda 12 user-agent deseniyle eleniyor (headlesschrome, lighthouse, googlebot, bingbot, gptbot, claudebot, oai-searchbot, perplexitybot ve benzerleri); aksi halde laboratuvar ölçümleri saha verisine karışır. İkincisi, sendBeacon desteklenmiyorsa fetch isteği keepalive seçeneğiyle gönderiliyor. Üçüncüsü, sunucu yalnız LCP, INP, CLS, FCP ve TTFB adlarını ve geçerli bir rating değerini kabul ediyor.

Sayfa bazında p75 hesaplamak için kayıtları metrik ve path bazında gruplayıp değerleri sıralamanız ve yüzde 75'teki değeri almanız yeterli. web.dev ölçütü mobil ve masaüstünü ayrı değerlendirir. Ölçüm sayısı 30'un altındaki path'leri "gösterge" diye etiketleyin; yukarıdaki tabloda 41 saniyelik path'in dayandığı ölçüm sayısı yalnız 16.

Laboratuvar araçlarını tamamen bırakmak gerekmiyor. web.dev'in laboratuvar ve saha verisi farkı yazısı laboratuvar testini tek cihaz, tek ağ ve tek konumdan yapılan ölçüm olarak tanımlıyor; saha verisi ise çok çeşitli ağ ve cihaz koşullarını içeriyor. İkisi farklı soruları cevaplar: laboratuvar "neden yavaş?", saha "kime ve ne kadar yavaş?"

Sheltron RUM verisi ne gösterdi? Site ortalaması yeşil, bazı sayfalar kırmızı

9 Ağustos 2026'da çekilen 11.767 gerçek kullanıcı ölçüm kaydında sitemizin genel p75 değerleri dört eşiğin hepsinde "iyi" bandındaydı: LCP 1.532 ms, TTFB 626 ms, INP 64 ms, CLS 0,06. Aynı veride 7 blog path'inin p75 LCP değeri 18 saniyeyi aşıyordu; site ortalaması sayfa düzeyindeki sorunu gizliyordu.

Kaydın birimi önemli: 11.767, ziyaret ya da kullanıcı sayısı değil, metrik olayı sayısıdır. Kurulumumuz LCP, INP, CLS, FCP ve TTFB'yi ayrı ayrı gönderdiği için bir sayfa görüntülemesi birden fazla kayıt üretir. Veri Nisan–Ağustos 2026 dönemini kapsıyor ve site o dönemde Firebase App Hosting üzerinde çalışıyordu.

Aynı dönemde laboratuvar ölçümü daha iyimser bir resim çiziyordu: 9 Ağustos 2026 tarihli ölçüm setindeki PageSpeed Insights koşusu mobil performans puanını 90, CLS'yi 0 olarak gösteriyordu. Laboratuvar testi tek URL'yi tek koşulda ölçer; gerçek kullanıcıların bir kısmı ise bazı sayfalarda yarım dakikayı aşan çizim süreleri yaşıyordu. Saha verisi olmadan bu sayfaları bulmak mümkün olmazdı; 9 Ağustos 2026 itibarıyla site CrUX'ta yer almıyordu ve RUM tek saha verisi kaynağımızdı.

İki güncel not ekleyelim. Birincisi, site Eylül 2026'da Firebase'den AWS altyapısına taşındı; 29 Eylül 2026 itibarıyla geçiş sonrası RUM özeti henüz çekilmedi. Yukarıdaki bot ölçümünde çıkan 0,354 saniyelik TTFB yeni altyapıya, 626 ms'lik kullanıcı TTFB'si eski altyapıya ait. Kullanıcı TTFB'si mobil ağları, DNS, TLS ve yönlendirmeleri de içerdiği için iki rakam doğrudan karşılaştırılamaz. İkincisi, CrUX yokluğu 9 Ağustos 2026 tarihli bir tespit; 29 Eylül 2026'daki yeniden kontrol API kotası nedeniyle tamamlanamadı.

Hız verisini atıf ve referral ölçümüyle birlikte okumak için ölçüm yığınının tamamını GEO ölçüm rehberinde topladık; RUM bu yığında sayfa deneyimini ölçen katmandır.

Hız atıfı mı etkiler, dönüşümü mü? Korelasyon verisini doğru okumak

Dış veriler hız ile atıf arasında ilişki gösteriyor, nedensellik göstermiyor. SE Ranking'in 216.524 sayfalık çalışmasında FCP'si 0,4 saniyenin altındaki sayfalar ortalama 6,7, 1,13 saniyenin üstündekiler 2,1 ChatGPT atıfı aldı. Aynı çalışmada INP'si en hızlı sayfalar en az atıfı aldı; hız tek başına açıklayıcı bir değişken gibi davranmıyor.

SE Ranking'in Kasım 2025 çalışması 20 nişte 129.000 alan adından 216.524 sayfayı inceledi. FCP'de tablo düzenli görünüyor: orta bant (0,65–0,82 saniye) ortalama 4,2 atıf alıyor. INP'de ise tersine dönüyor: INP'si 0,4 saniyenin altındaki sayfalar ortalama 1,6, 0,8–1,0 saniye bandındakiler 4,5 atıf alıyor. Çalışma XGBoost modeli ve SHAP değerleriyle yapılmış, faktörlerin etkilerinin birbirine bağlı olduğunu kendisi yazıyor; hız verisinin laboratuvardan mı sahadan mı geldiği ise belirtilmemiş. Search Engine Journal da aynı çalışmayı aktarırken bulguların kanıt değil, yön gösteren korelasyonlar olarak okunmasını öneriyor.

Olası bir açıklama şu: hızlı siteler aynı zamanda daha fazla yatırım yapılmış, daha çok bağlantı alan ve daha iyi yapılandırılmış siteler olabilir. Bu durumda hız, atfın nedeni değil, başka güçlü sinyallerin eşlikçisidir. Google'ın kendi dokümanları da hızı ayrı bir AI sinyali olarak tanımlamıyor: AI özellikleri dokümanı, AI Overviews ya da AI Mode'da görünmek için ek bir teknik gereklilik veya özel optimizasyon olmadığını açıkça yazıyor. Doküman iyi sayfa deneyimini genel SEO en iyi uygulamaları arasında sayıyor, ama AI Overviews için ayrı bir hız eşiği tanımlamıyor. Sayfanın dizine eklenmiş ve snippet ile gösterilebilir olması yeterli. AI Overviews için ayrı bir "hız sinyali" belgelenmiş değil.

Hızın doğrudan hissedilen etkisi atıftan sonra başlıyor. Bir kullanıcı AI cevabındaki kaynağa tıkladığında, sayfa ona 41 saniyede çiziliyorsa atıfın getirdiği ziyaret büyük olasılıkla boşa gider. Bu tıklamalar değerlidir, çünkü sayıları azdır: Sheltron'un 9 Ağustos 2026 tarihli Copilot verisinde Share of Authority %29,54 iken AI kaynaklı referral trafiği %1'in altında kalıyordu. Az sayıdaki ziyareti kaybetmemek, hızın AI görünürlüğündeki asıl işidir.

Bu etkiyi ölçmek için AI kaynaklı ziyaretleri GA4 ve Search Console'da ayrı bir kanal olarak izlemek gerekir. Kurulumu GA4 ve GSC ile AI referral attribution modeli yazısında adım adım anlattık. AI arama sıralamasını etkileyen diğer sinyallerin tam listesini ise AI search ranking faktörleri yazısında bulabilirsiniz; hız o listede tek başına belirleyici bir faktör değil, birçok sinyalden biridir.

AI görünürlüğü için hız kontrol listesi: hangi metrik, hangi eşik, hangi araç?

Önceliği bot katmanına verin: ham HTML'de içerik var mı, TTFB 0,8 saniyenin altında mı, 5xx ve 429 hataları düşük mü, HTML 2 MB'ın altında mı? Ardından kullanıcı katmanına geçin: p75 LCP 2,5 saniye, INP 200 ms, CLS 0,1. CrUX'ta veri yoksa RUM kurun ve p75 değerini sayfa bazında izleyin.

1. Botların erişimini doğrulayın. Hız, erişimden sonra gelir. robots.txt'in AI botlarını engelleyip engellemediğini robots.txt AI bot kontrolü aracıyla görün.
2. Ham HTML'i kontrol edin. curl -s URL | grep -c "<h2" komutu 0 döndürüyorsa içerik JavaScript ile geliyor ve AI botları metni göremeyebilir.
3. Botun gördüğü TTFB'yi ölçün. Aşağıdaki komutu birkaç user-agent ile, birkaç kez çalıştırın; hedef 0,8 saniyenin altı.
4. Hata oranlarını izleyin. Search Console'daki tarama istatistikleri raporu ortalama yanıt süresini ve sunucu yanıt sorunlarını gösterir; 5xx ve 429 artışı Google'ın taramasını azaltır.
5. CrUX'ı kontrol edin, yoksa RUM kurun. web-vitals ile LCP, INP, CLS ve TTFB toplayın; bot trafiğini eleyin.
6. Ortalamaya değil, sayfaya bakın. Site geneli p75 iyi görünse bile en yavaş 10 path'i ayrı listeleyin ve ölçüm sayısını yanına yazın.

Botun gördüğü hızı ölçmek için kendi ölçümümüzde kullandığımız komut:

curl -s -o /dev/null \
  -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.3; +https://openai.com/searchbot" \
  -w "kod=%{http_code} ttfb=%{time_starttransfer}s toplam=%{time_total}s boyut=%{size_download}B\n" \
  https://ornek.com.tr/blog/yazi/

Hız sorunları çözüldüğünde görünürlük sorunu devam ediyorsa neden büyük olasılıkla başka bir katmandadır: içerik yapısı, kaynak otoritesi ya da varlık tutarlılığı. ChatGPT'de görünmemenin hız dışındaki teknik nedenlerini ChatGPT görünürlüğünün 7 nedeni yazısında, sayfa içeriğinin AI'a hazır olup olmadığını ise ücretsiz içerik denetimi aracıyla kontrol edebilirsiniz. Atıf ölçümünün yöntemsel tartışmaları için The GEO Authority, tek tek atıfların izlenmesi için First Citation iyi başlangıç noktaları.

Sayfalarınızın botlara ne kadar hızlı ve ne kadar eksiksiz yanıt verdiğini bilmek, atıf kaybının bir nedenini dışarıda bırakır; geriye hangi sorguda, hangi rakibe kaybettiğinizi bulmak kalır. Sheltron hızlı değerlendirme ile sitenizin ChatGPT ve Gemini'deki görünürlüğünü ölçtürüp hız verinizle aynı tabloya koyabilirsiniz.

Ajans desteği mi arıyorsunuz? Partner GEO ajansımız Lein Digital.