Temel Web Verileri ve Gecikme: Daha Hızlı Sayfalar Daha Fazla Yapay Zeka Atfı Alır mı?

Temel Web Verileri ve Gecikme: Daha Hızlı Sayfalar Daha Fazla Yapay Zeka Atfı Alır mı?

Giriş

Hızlı bir web sitesi, insanların kullanımı için daha kolaydır. Ayrıca arama motorları ve yapay zeka sistemleri için sayfaları getirme, oluşturma ve anlama açısından da daha kolay olabilir.

Ancak önemli bir ayrım sıklıkla gözden kaçırılır:

Daha hızlı bir sayfa, taramayı ve içeriğin kullanılabilirliğini artırabilir. Ancak bu, yalnızca hızın bir yapay zeka sisteminin sayfayı atıf olarak göstermesine neden olduğu anlamına gelmez.

2 Ağustos 2026 itibarıyla Google, kararlı sunucu yanıt sürelerinin ve daha düşük gecikmenin bir sitenin tarama kapasitesini artırabileceğini belirtmektedir. Google ayrıca, yapay zeka arama özelliklerinin geleneksel arama ile aynı temel arama ve dizinleme sistemlerini kullandığını ve özel yapay zeka işaretlemesi veya hız optimizasyonları gerektirmediğini belirtmektedir. (developers.google.com)

Bu makale, tamamlanmış bir deneyin zaten yürütüldüğünü iddia etmek yerine, kanıta dayalı bir test planı sunmaktadır. Herhangi bir site, sayfa kümesi, sunucu günlüğü veya atıf veri kümesi sağlanmamıştır. Amaç, aşağıdakileri ölçebilecek kontrollü bir çalışma tanımlamaktır:

1. Daha düşük ilk bayta kadar geçen sürenin tarama sıklığını artırıp artırmadığı.
2. Daha düşük En Büyük İçeriksel Boyamanın (Largest Contentful Paint) keşfedilebilirliği veya dizinlemeyi iyileştirip iyileştirmediği.
3. Daha düşük Kümülatif Düzen Kaymasının (Cumulative Layout Shift) taramayı veya yapay zeka geri alımını etkileyip etkilemediği.
4. Performans iyileştirmelerinin, sayfaların yapay zeka arama sistemleri tarafından görünür şekilde atıfta bulunulma oranını artırıp artırmadığı.

Kısa Cevap

Daha düşük ilk bayta kadar geçen süre, doğru koşullarda taramayı iyileştirebilir

Google’ın mevcut tarama belgeleri, bir sitenin ilk bayta kadar geçen süre de dahil olmak üzere kararlı veya iyileşen yanıt sürelerine sahip olması durumunda tarama kapasitesi sınırının artabileceğini belirtir. Yanıt süreleri artarsa veya bir site çok fazla sunucu hatası veya hız sınırı yanıtı döndürürse, Google taramayı azaltabilir. (developers.google.com)

Ancak, daha hızlı yanıt süresi daha fazla taramayı garanti etmez. Tarama talebi ayrıca aşağıdaki gibi faktörlere de bağlıdır:

• Sitenin ne sıklıkta değiştiği.
• Sitenin ve sayfalarının ne kadar popüler olduğu.
• İçeriğin yararlı ve benzersiz olup olmadığı.
• Ne kadar yinelenen veya düşük değerli URL olduğu.
• Güncellenmiş URL’lerin site haritalarına dahil edilip edilmediği.

Bu, daha düşük gecikmenin, sınırlı yeni içeriğe sahip küçük bir siteden ziyade, büyük, sık güncellenen veya sunucu kısıtlı web siteleri üzerinde en güçlü etkiye sahip olması gerektiği anlamına gelir.

Daha düşük En Büyük İçeriksel Boyama dolaylı olarak yardımcı olabilir

En Büyük İçeriksel Boyama, ana görünür içeriğin bir kullanıcı için ne zaman göründüğünü ölçer. Google ayrıca hem sunucu yanıt süresinin hem de sayfaları ve gömülü kaynakları oluşturmak için gereken sürenin tarama verimliliğini etkileyebileceğini belirtir. (developers.google.com)

Muhtemel ilişki dolaylıdır:

Daha düşük gecikme → daha hızlı kaynak teslimi → daha verimli oluşturma veya getirme → daha az tarama zaman aşımı veya eksik getirmeler.

Önemli içerik aşağıdaki durumlara bağlı olduğunda etki en güçlü olmalıdır:

• Yavaş JavaScript.
• Büyük resimler.
• Oluşturmayı engelleyen stil sayfaları.
• İstemci tarafı oluşturma.
• Ağır gömülü kaynaklar.

Hızlı bir En Büyük İçeriksel Boyama puanının tek başına doğrudan bir yapay zeka atıf sinyali olması pek olası değildir.

Daha düşük Kümülatif Düzen Kaymasının muhtemelen doğrudan tarama etkisi azdır

Kümülatif Düzen Kayması, görünür içeriğin beklenmedik hareketini ölçer. Esas olarak bir kullanıcı deneyimi metriğidir. Yaygın nedenler arasında boyutsuz resimler, dinamik olarak eklenen reklamlar, gömülü içerik ve web yazı tipleri bulunur. (web.dev)

Bir tarayıcı, bir insan ziyaretçinin yaşadığı şekilde bir düzen kayması yaşamaz. Bu nedenle, daha düşük Kümülatif Düzen Kayması ile daha fazla tarama arasında doğrudan bir ilişki olası değildir.

Yüksek bir düzen kayması aşağıdaki nedenlerden kaynaklandığında dolaylı bir ilişki olabilir:

• JavaScript tarafından geç eklenen içerik.
• Komut dosyaları çalışana kadar gizlenen önemli metin.
• Sayfa yapımını geciktiren resimler veya yerleştirmeler.
• Farklı getirmeler sırasında farklı içerik üreten kararsız şablonlar.

Bu durumlarda, asıl sorun düzen kayması puanı değildir. Asıl sorun, sayfanın işlenmesinin zor olması veya önemli içeriği çok geç ortaya çıkarması olabilir.

Daha hızlı sayfalar otomatik olarak daha sık atıfta bulunulmaz

Google, yapay zeka özelliklerinde görünen sayfaların öncelikle dizine eklenmesi ve normal arama sonuçlarında bir özetle görünmeye uygun olması gerektiğini belirtir. Google ayrıca, yapay zeka genel bakışları ve yapay zeka modu için ek teknik gereksinimler veya özel yapay zeka optimizasyonları bulunmadığını da belirtir. (developers.google.com)

OpenAI de benzer şekilde, ChatGPT arama sıralamalarının birden fazla faktöre bağlı olduğunu ve arama tarayıcısı OAI-SearchBot'a izin vermenin dahil edilme için önemli olduğunu belirtmektedir. Daha düşük Temel Web Verilerinin atıf olasılığını doğrudan artırdığını belirtmez. (help.openai.com)

Bu, dört aşamalı bir model önermektedir:

1. Keşif — Sistem URL'nin var olduğunu öğreniyor mu?
2. Getirme ve işleme — Sistem sayfayı alıp anlayabiliyor mu?
3. Dizinleme ve geri alma — Sayfa belirli bir sorgu için seçiliyor mu?
4. Atıf seçimi — Sayfa yanıtta görünür bir kaynak olarak gösteriliyor mu?

Sayfa hızı ilk iki aşamayı etkileyebilir. Dördüncü aşamanın doğrudan nedeni olarak belirlenmemiştir.

Son araştırmalar, yapay zeka sistemlerinin birçok ilgili sayfayı okuyabildiğini ancak bunlardan yalnızca bazılarını atıf olarak gösterdiğini de göstermektedir. Başka bir deyişle, geri alma ve atıf ayrı olaylardır. (cambridge.org)

Ne Test Edilmeli?

Çalışma, “yapay zeka görünürlüğünü” tek bir metrik olarak ele almak yerine iki farklı soruyu test etmelidir.

Soru 1: Performans taramayı etkiliyor mu?

Birincil sonuçlar:

• Yayımdan ilk tarayıcı isteğine kadar geçen süre.
• Günlük sayfa başına tarayıcı isteği sayısı.
• Başarılı yeniden taramalar arasındaki süre.
• Yayımlanan her 1.000 sayfa başına taranan sayfa sayısı.
• Başarılı getirmelerin yüzdesi.
• Sunucu hataları ve hız sınırı yanıtlarının oranı.
• Yayımdan dizinlemeye kadar geçen süre.

Soru 2: Performans atıf seçimini etkiliyor mu?

Birincil sonuçlar:

• Görünür bir atıf üreten test edilen sorguların yüzdesi.
• Uygun sayfa başına atıf oranı.
• Bir sorgu içindeki atıf payı.
• Görünür atıf haline gelen alınan sayfaların yüzdesi.
• Zamanla atıf kalıcılığı.
• Yapay zeka sistemine göre atıf oranı.

Bu sonuçlar sağlayıcıya göre ayrılmalıdır. Bir Google yapay zeka genel bakışı, ChatGPT arama sonucu, Microsoft Copilot yanıtı, Perplexity yanıtı ve Claude arama yanıtı farklı dizinler, tarayıcılar, sıralama sistemleri ve yenileme programları kullanabilir.

Deneysel Tasarım

1. Kontrollü bir sayfa kümesi oluşturun

Anlamlı tarayıcı ve atıf verileri üretecek kadar büyük bir sayfa kümesi kullanın.

Pratik bir başlangıç tasarımı şunları içerecektir:

• 240 ila 800 sayfa.
• Her sayfa şablonu için en az 20 sayfa.
• Üç ila beş içerik kategorisi.
• Eskimeyen (evergreen) ve düzenli olarak güncellenen sayfaların bir karışımı.
• Her tedavi grubunda eşit sayıda sayfa.

Her sayfa şunlara sahip olmalıdır:

• Benzer HTML yapısı.
• Benzer içerik uzunluğu.
• Aynı yayınlama sistemi.
• Aynı dahili bağlantı düzeni.
• Aynı kanonik kurallar.
• Aynı site haritası işlemi.
• Aynı robots.txt izinleri.
• Benzersiz, faydalı bir konu.

Yalnızca deney için yüzlerce ince veya neredeyse yinelenen sayfa oluşturmayın. Google’ın rehberliği, yinelenen ve düşük değerli URL’lerin tarama kaynaklarını boşa harcayabileceği ve bir sitenin verimliliğini azaltabileceği konusunda uyarıyor. (developers.google.com)

Eşleştirilmiş bir tasarım faydalıdır. Örneğin, benzer özelliklere sahip sayfaları eşleştirin:

• İçerik uzunluğu.
• Konu talebi.
• Güncelleme sıklığı.
• Dahili bağlantı sayısı.
• Harici bağlantı sayısı.
• Geçmiş trafik.
• Arama sıralama konumu.

Ardından, her çiftten bir sayfayı kontrol grubuna, diğerini ise bir tedavi grubuna yerleştirin.

2. Faktöriyel tedavi tasarımı kullanın

Ana performans tedavileri bağımsız olarak ve birlikte test edilmelidir.

Bu, istenen üç optimizasyon için kontrollü bir deney oluşturur:

• HTTP/3.
• İçerik dağıtım ağı kenar önbellekleme.
• Görüntü sıkıştırma.

Düzen kararlılığı tedavisi gereklidir çünkü ilk üç optimizasyon Kümülatif Düzen Kaymasını güvenilir bir şekilde izole etmez. Görüntü sıkıştırma, düzen kararlılığını hiç değiştirmeden En Büyük İçeriksel Boyamayı düşürebilir.

HTTP/3 neden kendi ölçümüne ihtiyaç duyar?

HTTP/3, QUIC taşıma protokolünü kullanır ve TCP üzerinden HTTP/2'de bulunan taşıma katmanı baş-satır engellemesini önleyebilen bağımsız akışlar sağlar. Faydaları, istemcinin veya tarayıcının gerçekten HTTP/3'ü pazarlık edip etmediğine bağlıdır. (rfc-editor.org)

Bu nedenle, her istek için anlaşılan protokolü kaydedin:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

HTTP/3'ü etkinleştirmenin her tarayıcının onu kullandığı anlamına geldiğini varsaymayın. Googlebot, OAI-SearchBot veya başka bir tarayıcı HTTP/2 kullanmaya devam ederse, HTTP/3 o tarayıcının isteklerini etkileyemez.

Kenar önbellekleme neden dikkatli test edilmelidir?

Bir içerik dağıtım ağı, içeriği talep edene daha yakın sunarak ilk bayta kadar geçen süreyi azaltabilir. Ayrıca kaynak sunucuya ulaşan istek sayısını da azaltabilir. (web.dev)

En az üç önbellek durumunu test edin:

1. Soğuk önbellek — Kenar sunucu kaynağa başvurmalıdır.
2. Sıcak önbellek — Kenar sunucu, kaynağa başvurmadan sayfayı sunar.
3. Yeniden doğrulanmış önbellek — Kenar sunucu veya tarayıcı bir ETag veya Last-Modified değeri kullanır ve 304 Not Modified yanıtı alır.

Google, özellikle verimli HTTP önbelleklemesini önerir ve gereksiz işlemeyi ve bant genişliğini azaltmak için 304 Not Modified yanıtlarının kullanımını destekler. (developers.google.com)

Önbelleklemenin tarayıcılara eski veya yanlış içerik sunmasına izin vermeyin. Şunları kaydedin:

• Önbellek isabeti veya kaçışı.
• Önbellek yaşı.
• Kenar konumu.
• Kaynak yanıt süresi.
• İçerik sürümü.
• Durum kodu.
• Doğrulama başlıkları.

Görüntü sıkıştırma neden En Büyük İçeriksel Boyama ile ilişkilendirilmelidir?

WebP ve AVIF genellikle eski görüntü formatlarından daha iyi sıkıştırma sağlar. Daha küçük görüntüler aktarım süresini azaltabilir ve görüntü En Büyük İçeriksel Boyama öğesiyse En Büyük İçeriksel Boyamayı iyileştirebilir. (web.dev)

Test şunları kullanmalıdır:

• Aynı görüntü boyutları.
• Aynı görsel kalite hedefi.
• Duyarlı srcset görüntüleri.
• Uygun bir geri dönüşlü modern bir format.
• Açık width ve height değerleri.
• En Büyük İçeriksel Boyama görüntüsü için tembel yükleme (lazy loading) yok.
• Başlangıç HTML'sinde görünür bir görüntü URL'si.

Gerçek gecikme JavaScript'ten veya geç kaynak keşfinden geliyorsa, yalnızca görüntü sıkıştırması En Büyük İçeriksel Boyamayı iyileştirmeyebilir. Google’ın performans rehberliği, En Büyük İçeriksel Boyama öğesi geç ortaya çıkarsa, görüntü indirme süresini azaltmanın gecikmeyi sayfanın başka bir bölümüne kaydırabileceğini belirtir. (web.dev)

3. Testi yeterince uzun süre çalıştırın

Kısa bir test, tarama programlaması ve dizin yenilemenin etkilerini gözden kaçırabilir.

Pratik bir tasarım şöyledir:

• İki haftalık başlangıç ölçümü.
• Altı ila on iki haftalık tedavi ölçümü.
• Mümkünse son bir tersine çevirme veya çapraz geçiş dönemi.

Çapraz geçiş testi için, eşleşen sayfa grupları arasında tedavileri değiştirin. Tedavi kaldırıldığında performans etkisi kaybolursa, sonuç basit bir öncesi-sonrası karşılaştırmasından daha güçlüdür.

Temel Web Verileri alan verileri uygun bir süre boyunca değerlendirilmelidir. Chrome Kullanıcı Deneyimi Raporu, 28 günlük yuvarlanan bir toplama kullanır, bu nedenle bir dağıtımdan sonra anlık değişiklikleri göstermek için tasarlanmamıştır. (developer.chrome.com)

4. Tüm tarayıcı popülasyonunu ölçün

Tüm otomatik trafiği tek bir grup olarak ele almayın.

Minimumda, şunları ayırın:

Arama tarayıcıları

• Googlebot.
• Bingbot.

Yapay zeka arama tarayıcıları

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Kullanıcı tarafından talep edilen getiriciler

• Perplexity-User.
• Claude-User.
• Tanımlanabildiğinde ChatGPT kullanıcı getiricileri.

Eğitim tarayıcıları

• GPTBot.
• ClaudeBot.
• Google-Extended kontrolleri.

Eğitim tarayıcıları, yapay zeka arama atıfları için bir vekil olarak kullanılmamalıdır. Anthropic, OpenAI ve Google, eğitim, arama veya kullanıcı tarafından talep edilen geri alma için kullanılan tarayıcılar arasında ayrım yapar. Google ayrıca Google-Extended'ın Google Arama'ya dahil olmayı veya sıralamayı etkilemediğini belirtir. (help.openai.com)

Perplexity de benzer şekilde, arama dizinlemeyi destekleyen PerplexityBot ile bir kullanıcı isteğine yanıt olarak bir sayfayı alabilen Perplexity-User arasında ayrım yapar. (docs.perplexity.ai)

Tarayıcı kimliğini, sağlayıcının desteklediği yerlerde yayımlanmış IP aralıkları veya ters DNS kullanarak doğrulayın. Kullanıcı aracısı dizeleri, ilgisiz tarayıcılar tarafından kopyalanabilir. Google özellikle Googlebot kullanıcı aracısı dizelerinin taklit edilebileceği konusunda uyarır. (developers.google.com)

Toplanacak Metrikler

Performans metrikleri

Hem laboratuvar hem de gerçek kullanıcı verilerini toplayın:

• İlk bayta kadar geçen süre (Time to first byte).
• İlk İçeriksel Boyama (First Contentful Paint).
• En Büyük İçeriksel Boyama (Largest Contentful Paint).
• Kümülatif Düzen Kayması (Cumulative Layout Shift).
• Sonraki Boyamaya Etkileşim (Interaction to Next Paint).
• Toplam sayfa ağırlığı.
• Başlangıç HTML boyutu.
• Görüntü aktarım boyutu.
• İstek sayısı.
• Sunucu işlemede harcanan süre.
• En Büyük İçeriksel Boyama kaynağı için beklemede harcanan süre.
• HTTP protokolü.
• Önbellek durumu.

Google, ilk bayta kadar geçen süre için yaklaşık olarak 800 milisaniye veya daha az bir hedef önermektedir, ancak ilk bayta kadar geçen süre başlı başına bir Temel Web Verisi değildir. (web.dev)

75. yüzdelikteki mevcut Temel Web Verileri “iyi” eşikleri şunlardır:

• En Büyük İçeriksel Boyama: 2,5 saniye veya daha az.
• Kümülatif Düzen Kayması: 0,1 veya daha az.
• Sonraki Boyamaya Etkileşim: 200 milisaniye veya daha az. (web.dev)

Tarama metrikleri

Her doğrulanmış tarayıcı isteği için şunları kaydedin:

text zaman damgası url kullanıcı_aracısı doğrulanmış_bot kaynak_ip http_protokolü durum_kodu yanıt_süresi ilk_bayta_kadar_geçen_süre gönderilen_bayt önbellek_durumu kenar_konumu etag son_değiştirme_tarihi yönlendiren

Hesaplayın:

text sayfa_başına_günlük_tarama_istekleri başarılı_getirme_oranı 5xx_oranı 429_oranı medyan_yeniden_tarama_aralığı p75_yeniden_tarama_aralığı yayımdan_ilk_getirmeye_kadar yayımdan_ilk_dizinlemeye_kadar

Yapay zeka atıf metrikleri

Her platformda sabit bir sorgu kümesi kullanın. Sorgu kümesi şunları içermelidir:

• Doğrudan olgusal sorular.
• Karşılaştırma soruları.
• “En iyi” veya tavsiye soruları.
• Tazeliğe duyarlı sorular.
• Test edilen sayfanın en güçlü yanıt olduğu sorular.
• Test edilen sayfanın ilgili ancak baskın olmadığı sorular.

Her sorgu için şunları kaydedin:

text arama_motoru model_veya_deneyim zaman_damgası konum cihaz sorgu kaynak_olarak_gösterilen_sayfalar sayfa_atıf_sırası test_edilen_sayfa_atıf_olarak_gösterildi_mi test_edilen_sayfa_alındı_ancak_atıf_olarak_gösterilmedi_mi yanıt_metni_özeti

Yapay zeka yanıtları değişebileceğinden sorguları tekrarlayın. Haftada üç kez gibi sabit bir program kullanın ve arama motoru veya modeldeki değişiklikleri kaydedin.

Microsoft Bing Webmaster Tools artık desteklenen Microsoft yapay zeka deneyimlerinde atıf yapılan sayfaları, temel alınan sorguları ve atıf eğilimlerini gösteren bir Yapay Zeka Performans raporu sunmaktadır. Microsoft, verilerin toplandığını, örneklemeli olduğunu ve gözlemsel olduğunu; belirli bir sayfa değişikliğinin bir atıf değişikliğine neden olduğunu kanıtlayamayacağını uyarmaktadır. (bing.com)

Google, Haziran 2026'da Search Console'da özel üretken yapay zeka performans raporlarını da kullanıma sunmaya başladı. Raporlar başlangıçta yalnızca belirli web siteleri alt kümesine açıktı, bu nedenle erişim değişebilir. (developers.google.com)

İstatistiksel Analiz

Tarama sıklığı

Negatif binom modeli gibi karma etkili bir sayım modeli kullanın:

text tarama_sayısı ~ tedavi + ilk_bayta_kadar_geçen_süre + sayfa_yaşı + güncelleme_sıklığı + site_haritası_durumu + dahili_bağlantılar + sunucu_hataları + (1 | sayfa) + (1 | tarayıcı)

Sayfa ve tarayıcı etkileri önemlidir çünkü bazı sayfalar doğal olarak diğerlerinden daha fazla dikkat çeker ve farklı tarayıcıların farklı programları vardır.

Keşif ve dizinleme

Aşağıdakiler için sağkalım analizi kullanın:

• Yayımdan ilk getirmeye kadar geçen süre.
• Yayımdan ilk dizine kadar geçen süre.
• Güncellemeden yeniden taramaya kadar geçen süre.

Temel sonuç, bir sayfanın sonunda taranıp taranmadığı değildir. Sayfanın bulunması ve işlenmesi için gereken süreyi tedavinin azaltıp azaltmadığıdır.

Yapay zeka atıf seçimi

Hiyerarşik bir lojistik model kullanın:

text atıf_mevcudiyeti ~ tedavi + ilk_bayta_kadar_geçen_süre + en_büyük_içeriksel_boyama + kümülatif_düzen_kayması + dizinlenme_durumu + arama_görünürlüğü + içerik_tazeliği + sayfa_otoritesi + (1 | sorgu) + (1 | arama_motoru) + (1 | sayfa)

İki ayrı model çalıştırın:

1. Geri alma modeli — Sayfa geri alındı mı yoksa aday olarak mı gösterildi?
2. Atıf modeli — Geri alındıysa, sayfa görünür şekilde atıf olarak gösterildi mi?

Bu ayrım çok önemlidir. Taramayı artıran ancak geri almayı artırmayan bir performans iyileştirmesi, yapay zeka atıf etkisi değildir. Geri almayı artıran ancak atıfları artırmayan bir performans iyileştirmesi, sayfanın dikkate alındığını ancak kaynak seçimi sırasında kaybedildiğini düşündürür.

Beklenen Bulgular

Bunlar çalışma hipotezleri olup, iddia edilen deneysel sonuçlar değildir.

Hipotez 1: İlk bayta kadar geçen süre en net tarama etkisine sahip olacaktır

Daha düşük ilk bayta kadar geçen süre ile tarama kapasitesi arasında pozitif bir ilişki bekleyin, özellikle şu durumlarda:

• Sitede çok sayıda sayfa varsa.
• Sayfalar sık sık değişiyorsa.
• Kaynak sunucu yavaş veya aşırı yüklenmişse.
• Site 5xx veya 429 yanıtları döndürüyorsa.
• Tarayıcı yanıtları beklemekle önemli zaman harcıyorsa.

Düşük tarama talebi olan küçük bir sitede ölçülebilir bir etki beklenmez.

Hipotez 2: En Büyük İçeriksel Boyama, oluşturma ve kaynak teslimi yoluyla önemli olacaktır

Daha düşük En Büyük İçeriksel Boyama'nın şu durumlarda yardımcı olmasını bekleyin:

• Sayfa tarayıcı oluşturmasına bağlıysa.
• Önemli içerik JavaScript'in arkasındaysa.
• Dizinleme için büyük resimler veya stil sayfaları gerekiyorsa.
• Tarayıcı birçok sayfa kaynağını getiriyorsa.
• Daha yavaş tedavi zaman aşımları veya eksik oluşturma üretiyorsa.

Sayfanın önemli metni zaten başlangıç HTML'sinde mevcut olduğunda zayıf bir ilişki bekleyin.

Hipotez 3: Kümülatif Düzen Kaymasının doğrudan etkisi az olacaktır

Sayfa yapısı ve JavaScript davranışı kontrol edildikten sonra Kümülatif Düzen Kayması ile tarama sıklığı veya atıf oranı arasında anlamlı bir doğrudan ilişki beklemeyin.

Kümülatif Düzen Kayması atıfları tahmin ediyor gibi görünüyorsa, aşağıdakiler için bir vekil görevi görüp görmediğini araştırın:

• İstemci tarafı oluşturma.
• Geç içerik ekleme.
• Kararsız reklamlar.
• Gizli veya gecikmiş metin.
• Kötü yapılandırılmış HTML.

Hipotez 4: Yalnızca hız daha fazla yapay zeka atıfı üretmeyecektir

Atıf seçiminin en güçlü öngörücüleri muhtemelen şunlar olmaya devam edecektir:

• Sorguyla alaka düzeyi.
• İçerik kalitesi.
• Net yanıtlar.
• Tazelik.
• Otorite ve güven.
• Arama dizini uygunluğu.
• Geri alma sıralaması.
• Sayfanın yapılan iddiayı doğrudan destekleyip desteklemediği.

Google’ın rehberliği, yararlı, güvenilir, insan odaklı içeriği vurgular ve yapay zeka arama özelliklerinin mevcut arama ve dizinleme sistemlerine dayandığını belirtir. (developers.google.com)

Yapay Zeka Geri Alımı İçin Ayarlanmış Bir Performans Bütçesi

Aşağıda önerilen bir işletme bütçesi bulunmaktadır. Bu, yayımlanmış bir yapay zeka sıralama formülü değildir.

Google’ın mevcut belgeleri, Googlebot'un desteklenen bir dosyanın ilk 2 megabaytını getirdiğini ve harici komut dosyalarını ve stil sayfalarını ayrı ayrı getirdiğini belirtir. Ayrıca önemli meta verileri ve yapılandırılmış verileri HTML'de erken yerleştirmeyi önerir. (developers.google.com)

Uygulama Önerileri

HTTP/3

Barındırma sağlayıcısı ve içerik dağıtım ağı tarafından desteklendiğinde HTTP/3 kullanın.

Ölçün:

• HTTP/3 pazarlık oranı.
• HTTP/2 geri dönüş oranı.
• Bağlantı kurulum süresi.
• İlk bayta kadar geçen süre.
• Coğrafi bölgeye göre performans.
• Tarayıcıya göre performans.

HTTP/3'ü garantili bir arama veya yapay zeka optimizasyonu olarak görmeyin. Bu, yalnızca onu kullanan istemcilere yardımcı olabilecek bir taşıma iyileştirmesidir.

İçerik Dağıtım Ağı Kenar Önbellekleme

Genel, kişiselleştirilmemiş sayfalar için:

• Açık Cache-Control kuralları belirleyin.
• Sürümlenmiş statik varlıklar için uzun ömürlü önbellekleme kullanın.
• Sık güncellenen HTML için kısa ama faydalı önbellekleme kullanın.
• Gereksiz sorgu parametrelerinden kaynaklanan önbellek parçalanmasını önleyin.
• Kanonik URL'leri koruyun.
• ETag ve Last-Modified destekleyin.
• Soğuk, sıcak ve yeniden doğrulanmış önbellek durumlarını test edin.
• Tarayıcı isteklerinin insan istekleriyle aynı önemli içeriği aldığını onaylayın.

Bir içerik dağıtım ağı, eski, tutarsız veya bota özel sayfa sürümleri oluşturmadan gecikmeyi azaltmalıdır.

Görüntü Sıkıştırma

Görseller için:

• Görsel kalite kabul edilebilir olduğunda AVIF veya WebP kullanın.
• Duyarlı görüntü boyutları sağlayın.
• Küçük bir mobil ekrana masaüstü boyutunda bir görüntü sunmayın.
• En Büyük İçeriksel Boyama görüntüsünü tembel yükleme (lazy-load) yapmayın.
• Görüntü boyutlarını dahil edin.
• En Büyük İçeriksel Boyama görüntüsünü başlangıç HTML'sine yerleştirin.
• fetchpriority="high"'ı yalnızca uygun olduğunda kullanın.
• Önemli açıklamaları sadece görsellere yerleştirmek yerine metin olarak tutun.

Görüntü sıkıştırma, görüntü En Büyük İçeriksel Boyama öğesi olduğunda en değerlidir. Ana gecikmesi sunucu oluşturma veya JavaScript yürütmesinden kaynaklanan bir sayfayı düzeltmeyecektir. (web.dev)

Düzen Kararlılığı

Kümülatif Düzen Kaymasını azaltmak için:

• Görüntülere genişlik ve yükseklik öznitelikleri ayarlayın.
• Reklamlar için yer ayırın.
• Gömülü video ve sosyal içerik için yer ayırın.
• Mevcut metnin üzerine bannerlar eklemekten kaçının.
• Kararlı yazı tipi yükleme stratejileri kullanın.
• Sayfa yüklendikten sonra sunucu tarafından oluşturulan büyük içerik bloklarını değiştirmekten kaçının.

Bu değişiklikler, tarama veya atıflar üzerinde ölçülebilir bir etkisi olmasa bile kullanıcı deneyimini iyileştirir. (web.dev)

Araçlar ve İzleme

Performans araçları

Şunları kullanın:

• Gerçek kullanıcı Temel Web Verileri için Chrome Kullanıcı Deneyimi Raporu.
• Otomatik alan verisi toplama için Chrome Kullanıcı Deneyimi Raporu uygulama programlama arayüzü.
• Laboratuvar denetimleri ve alan verileri için PageSpeed Insights.
• Tekrarlanabilir laboratuvar testleri için Lighthouse.
• Çekme isteği performansı bütçeleri için Lighthouse Sürekli Entegrasyon.
• Çoklu konum testleri, önbellek durumları ve protokol karşılaştırmaları için WebPageTest.
• En Büyük İçeriksel Boyama ve düzen kayması hata ayıklaması için Chrome DevTools.
• Gerçek kullanıcı izlemesi için web-vitals JavaScript kütüphanesi.

Chrome Kullanıcı Deneyimi Raporu uygulama programlama arayüzü, En Büyük İçeriksel Boyama, Kümülatif Düzen Kayması, Sonraki Boyamaya Etkileşim ve deneysel ilk bayta kadar geçen süre dahil olmak üzere sayfa düzeyinde ve kaynak düzeyinde toplanmış alan verileri sağlar. (developer.chrome.com)

Lighthouse Sürekli Entegrasyon, her kod değişikliğinde performans kontrolleri yapabilir ve bütçeler aşıldığında derlemelerin başarısız olmasına neden olabilir. (github.com)

Tarayıcı izleme

Sunucu günlükleri, kenar günlükleri ve küçük bir sentetik prob kümesi kullanın.

Örnek prob:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Aynı testi şunlarla çalıştırın:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normal bir tarayıcı kullanıcı aracısı.

Test şunları doğrulamalıdır:

• Durum kodu.
• Robots izni.
• Yanıt başlıkları.
• HTML içeriği.
• HTTP sürümü.
• Önbellek durumu.
• Yanıt süresi.
• Önemli metnin JavaScript olmadan mevcut olup olmadığı.

Arama ve dizinleme izleme

Şunları kullanın:

• Google Search Console tarama istatistikleri.
• Google Search Console sayfa dizinleme raporları.
• Google Search Console URL Denetimi.
• Google Search Console site haritası verileri.
• Mevcut olduğunda Google Search Console üretken yapay zeka raporları.
• Bing Webmaster Tools tarama istekleri ve dizine eklenmiş sayfalar.
• Bing Webmaster Tools Yapay Zeka Performansı.
• Günlük site haritası ve lastmod kontrolleri.

Search Console uygulama programlama arayüzü, veri limitlerine tabi olarak sayfa, sorgu, tarih, cihaz ve arama görünümüne göre performans verilerini alabilir. (developers.google.com)

Atıf izleme

Konu başına 50 ila 200 kararlı sorgu içeren bir atıf paneli oluşturun. Paneli sabit bir programda çalıştırın ve şunları kaydedin:

• Platformun arama yapıp yapmadığı.
• Hangi kaynakların göründüğü.
• Test edilen URL'nin atıf olarak gösterilip gösterilmediği.
• Atıf sırası.
• Yanıt tarihi ve saati.
• Sayfanın değişip değişmediği.
• Modelin veya arama deneyiminin değişip değişmediği.

Farklı sistemlerden gelen atıf sayılarını eşdeğerlermiş gibi karşılaştırmayın. Microsoft, atıf etkinliğinin bir sıralama puanı, otorite puanı, trafik ölçüsü veya kalite puanı olmadığını belirtir. (bing.com)

Uyarı Kuralları

Şunlar için uyarılar oluşturun:

• İlk bayta kadar geçen sürenin yüzde 25'ten fazla artması.
• En Büyük İçeriksel Boyamanın 75. yüzdelikte 2,5 saniyenin üzerine çıkması.
• Kümülatif Düzen Kaymasının 0,1'in üzerine çıkması.
• 5xx veya 429 yanıtlarında sürekli bir artış.
• Tarayıcı başarı oranında bir düşüş.
• Bir robots.txt değişikliği.
• Bir site haritası hatası.
• Dizinlenmiş sayfalarda ani bir düşüş.
• Birkaç platformda yapay zeka atıflarında ani bir düşüş.
• Yalnızca bir platformu etkileyen atıf hacminde bir değişiklik.

Tek bir platformu etkileyen bir atıf düşüşü, sayfa performans sorunundan ziyade bir model, dizin, sorgu veya ürün değişikliğinden kaynaklanabilir. Microsoft, atıf eğilimlerinin gözlemsel olduğunu ve içerik güncellemeleri, kullanıcı talebi ve sistem veya model değişiklikleri nedeniyle değişebileceğini açıkça belirtmektedir. (bing.com)

Nihai Sonuç

En savunulabilir sonuç şudur:

Daha hızlı sayfalar, özellikle sunucu gecikmesi, kaynak boyutu, hatalar veya oluşturma gecikmeleri sınırlayıcı faktörler olduğunda, tarama verimliliğini artırabilir. Ancak şu anda, daha düşük Temel Web Verilerinin yapay zeka sistemlerinin bir sayfayı doğrudan atıf olarak seçmesine neden olduğuna dair güçlü bir kanıt bulunmamaktadır.

Beklenen nedensel zincir şöyledir:

text Daha düşük gecikme → daha iyi sunucu kapasitesi → daha az başarısız veya gecikmiş getirme → daha hızlı keşif ve işleme → dizine eklenme ve geri alınma şansının artması → atıflarda olası artış

Son adım belirsizliğini korumaktadır çünkü atıf seçimi, alaka düzeyi, kalite, tazelik, otorite, sorgu amacı, geri alma sıralaması ve her yapay zeka sisteminin davranışına bağlıdır.

Bu nedenle çoğu web sitesi için doğru performans stratejisi, tek başına “yapay zeka atıfları için optimize etme” değildir. Şöyledir:

1. Önemli içeriği başlangıç HTML'sinde hazır bulundurun.
2. İlk bayta kadar geçen süreyi sabit tutun.
3. Genel içerik için kenar önbellekleme kullanın.
4. Önemli görselleri sıkıştırın ve önceliklendirin.
5. Düzen kaymalarını önleyin.
6. Güvenilir durum kodları döndürün.
7. Site haritalarını ve dahili bağlantıları güncel tutun.
8. Doğru arama tarayıcılarına izin verin.
9. Taramayı, dizinlemeyi, geri almayı ve atıfı ayrı aşamalar olarak ölçün.

Bu yaklaşım, insanlar için daha hızlı bir web sitesi, arama tarayıcıları için daha sağlıklı bir site ve yapay zeka görünürlüğünü anlamak için test edilebilir bir temel sağlar.