AI Tarayıcı Günlük Analizi

Sunucu veya CDN günlüklerini nasıl çekip AI bot etkinliğini analiz edeceğiniz — GPTBot, ClaudeBot ve PerplexityBot'u sahteciliğe karşı doğrulama, araç seçimi ve tarama sıklığı, tarama-ve-işleme ile durum kodlarını okuma.

İlk yayın tarihi: 3 Tem 2026 · Son güncelleme: 22 Ağu 2026 · Advanced
Diller
Bu sayfada 1 kanıt sinyali

AI tarayıcı günlük analizi, kendi birinci taraf günlüklerinizle (satıcı paneli değil) hangi iddia edilen AI botlarının sitenizi istediğini ve sunucunun ne döndürdüğünü inceleme yöntemidir. Doğrulama sağlayıcıya özeldir: OpenAI botlara özel IP aralığı dosyaları yayınlar ve Anthropic güncel bir ortak bots.json listesi yayınlar; güncel resmi doğrulama yöntemi olmayan bir kullanıcı ajanı, doğrulanmış bir kimlik değil, bir iddiadır. Ham HTML bağımlılığını, her büyük AI tarayıcısının JavaScript çalıştırmadığını iddia etmek yerine gözlemlenen bir risk olarak değerlendirin; varlık istek desenleri evrensel bir işleme sözleşmesini değil, ölçülen örneği tanımlar. Tarama sıklığı hala alıntıyı tahmin etmez — erişim gerekli ancak yeterli değildir. Araçlar grep'ten Screaming Frog LFA'ya, ELK/Splunk'a ve BigQuery/Cloudflare'a kadar ölçeklenir.

TL;DR — Apache/Nginx veya CDN erişim günlüklerinizi alın, ardından dört işlem yapın: doğrulayın (kullanıcı aracısını eşleştirin ve IP’yi her operatörün yayınladığı listeyle doğrulayın; sahtecilik oranları HUMAN Security’nin %5,7’lik ölçümünden Duane Forrester’ın kendi testindeki %81,8’e kadar değişmektedir); ölçeğe göre bir araç seçin (grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare); bota göre tarama sıklığını, ziyaret edilen sayfaları, tarama-işleme farkını ve durum kodlarını ölçün; son olarak dürüstçe yorumlayın — içeriğin alınması gerekli ama yeterli değildir, dolayısıyla “daha fazla tarama = daha fazla alıntı” iddiası kanıtlanmış değildir. Bu yöntem; botların ne olduğunu ele alan AI tarayıcıları, tıklama tarafını ele alan AI trafik atıflaması ve alınan → bahsedilen → alıntılanan çerçevesinin ilk aşamasını gözlemleyen LLM görünürlüğü konularının tamamlayıcısıdır.

Bu makalenin kapsadığı — ve kapsamadığı

Günlükler istekleri gösterir, içeriğin eğitim, erişim veya bir yanıt için kullanılıp kullanılmadığını değil. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: Apache: Log files Mümkün olduğunda sağlayıcı tarafından yayınlanan mekanizmaları kullanarak botları doğrulayın ve atıflamayı sınırlı kanıt olarak değerlendirin. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: OpenAI: Crawlers

İlgili AI tarayıcıları makalesi, botlara göre hazırlanmış tabloyu, üç kategorili sınıflandırmayı (eğitim / AI araması / kullanıcı tarafından tetiklenen getirme), Google-Extended’ın bot değil belirteç olması ayrımını ve robots.txt tariflerini zaten kapsıyor. Bunları burada yeniden türetmiyorum. AI trafik atıflaması, GA4/yönlendiren tarafını, yani botun geri gönderdiği trafiği ele alır. Bu makale huninin diğer tarafıyla, yani botun aldığı içerikle ilgilidir. LLM görünürlüğü ise alınan → bahsedilen → alıntılanan çerçevesini kapsar; günlük analizi yalnızca alınan aşamasını gözlemlemenizi sağlar, sonrasını değil.

Bu, klasik SEO günlük dosyası analizinin AI çağındaki devamıdır. Ahrefs’in How to Do an SEO Log File Analysis başlıklı çalışmasını incelediğimde boyutlar; tarama sıklığı, taranan URL’ler, durum kodları ve botların Google’ın yayınladığı IP’lerle doğrulanmasıydı. Burada da aynı iskelet kullanılıyor; ancak çoğunlukla JavaScript işlemeyen, sürekli taklit edilen ve düzenli bir akış yerine düzensiz patlamalar hâlinde tarama yapan bir bot grubuna uygulanıyor.

Adım 1 — Günlüklerinizi alın

Günlükleriniz şu iki yerden birinde veya her ikisinde bulunur:

  • Kaynak sunucu günlükleri. Apache (access.log), Nginx (access.log) veya uygulama sunucunuz. Her satır en azından zaman damgası, istemci IP’si, istek yöntemi + yolu, durum kodu, bayt sayısı, yönlendiren ve kullanıcı aracısı içerir.
  • CDN / uç günlükleri. Cloudflare, Fastly, Akamai vb. arkasındaysanız bot trafiğinin büyük bölümü uçta yanıtlanır ve kaynak sunucunuza hiç ulaşmayabilir. Bu nedenle uç günlüğü daha eksiksiz bir kayıttır. Cloudflare bunu Logpush (ve bir GraphQL API’si), Fastly ise gerçek zamanlı günlük akışı yoluyla sunar.
Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: Apache: Log files

AI bot analizi için gerçekten ihtiyaç duyduğunuz alanlar şunlardır: zaman damgası, istemci IP’si, kullanıcı aracısı, istek yolu, durum kodu ve tercihen bayt sayısı ile yönlendiren.

Pratikteki sorun saklama süresidir. Birçok barındırma sağlayıcısı günlükleri yalnızca birkaç gün tutar. Lauren Busby’nin Search Engine Land yazısı çözümü doğrudan açıklar: zamanlanmış bir çekim, kısa bir zaman aralığını zaman içinde analiz edilebilir hâle getirir. n8n gibi bir iş akışı aracında oluşturulan veya betikle çalışan zamanlanmış bir SFTP işi, kısa saklama süresini zaman içinde gerçekten analiz edebileceğiniz bir veri kümesine dönüştürmek için yeterlidir (Busby, SEL). Bunu verilere ihtiyaç duymadan önce kurun.

Başlangıçtan itibaren göz önünde bulundurmanız gereken önemli bir sınırlama vardır: Busby’nin ifade ettiği gibi günlük dosyaları sitenize neyin ulaştığını gösterir, ancak neyin ulaşmaya çalıştığını her zaman göstermez (SEL); üst katmanda engellenen veya yanıtlanan istekler günlüklerde hiç görünmeyebilir.

Adım 2 — Kullanıcı aracısına güvenmeden önce doğrulayın

AI bot günlük analizini klasik sürümden ayıran ve rakip rehberlerin çoğunun atladığı adım budur. Kullanıcı aracısı dizeleri son derece kolay taklit edilebilir. Sorunun boyutunu gösteren iki bağımsız veri noktası şöyledir:

  • HUMAN Security, iyi bilinen 16 AI tarayıcısından biri olduğunu iddia eden iki haftalık trafiği analiz etti ve trafiğin %5,7’sinin sahte olduğunu belirledi; bu, yaklaşık her 18 istekten 1’idir (SEJ aracılığıyla aktarıldı).
  • Duane Forrester, aynı kontrolü kendi günlüklerinde gerçekleştirdi ve çok daha kötü bir sonuç buldu. Canlı getirme adlarından birini taşıyan 33 isteğin altısı satıcının yayınladığı bir IP’den geldi, yirmi yedisi ise gelmedi. Bu, kontrol edebildiği isteklerde %81,8 sahtecilik oranı anlamına geliyordu (SEJ). Googlebot sonucu daha da kötüydü: Googlebot adını taşıyan 799 isteğin yalnızca 107’si doğrulanmış bir Google adresinden gelmişti; kalan yaklaşık %87 Google’a ait değildi (SEJ).

Bunları farklı örneklemlerden ve yöntemlerden gelen yönlendirici bilgiler olarak ele alın, evrensel bir sayı olarak değil. Daha da önemlisi, bir sağlayıcının doğrulama yöntemini her bota genellemeyin. Bazı operatörler adres aralıklarını yayınlar; diğerleri, güncel bir genel aralık veya DNS doğrulama sözleşmesi olmadan kullanıcı aracısı belirteçlerini belgeler (SEJ).

Doğrulama yöntemi:

  1. Kullanıcı aracısı dizesini eşleştirin. GPTBot kendisini Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot olarak tanımlar; OAI-SearchBot ve ChatGPT-User kendi belirteçlerini taşır (OpenAI bot belgeleri).
  2. Varsa sağlayıcının güncel resmî doğrulama yöntemini kullanın. OpenAI openai.com/gptbot.json, searchbot.json ve chatgpt-user.json dosyalarını sunar. Anthropic’in güncel tarayıcı belgeleri, yayınladığı listedeki bir adresin tarayıcının Anthropic’ten geldiğini gösterdiğini belirtir. Sağlayıcıya özgü bu güncel yöntemi kullanın; bunu evrensel bir bot doğrulama kuralı olarak genellemeyin.
  3. Bir yedek yöntem uydurmayın. Ters ve ileri DNS doğrulaması yalnızca sağlayıcı beklenen ana bilgisayar adı kalıbını ve doğrulama prosedürünü yayınladığında o sağlayıcı için geçerlidir. Genel bir PTR eşleşmesi, iddia edilen bot kimliğini değil yalnızca DNS üzerindeki kontrolü kanıtlar. Screaming Frog Log File Analyser, mevcut olduğu durumlarda herkese açık biçimde doğrulanmış listeleri uygulayabilir; içe aktarım sırasında doğrulama özelliği, botların gerçekliğini doğrulamak için herkese açık biçimde doğrulanmış IP listelerini sorgular (Screaming Frog).

Doğrulama, hassas politika kararlarına ve olay müdahalesine temel oluşturmalıdır. Tarama politikası için sağlayıcının belgelediği robots belirtecini tercih edin; ağ kontrollerini kötüye kullanım veya güvenlik vakaları için kullanın ve bunları robots uyumluluğundan ayrı olarak sınıflandırın.

Adım 3 — Aracınızı seçin

Aracı işin ölçeğine göre seçin; kabaca ücretsizden ücretliye, ham gerçek veriden yönetilen çözümlere doğru:

  • grep / PowerShell — hızlı bir tek seferlik sayım ve doğrulama bilincine sahip bir filtre. AI tarayıcılar makalesi temel bot sayım kod parçacığını içerir; buradaki Scripts sekmesi bunu IP doğrulama, durum kodu dökümü ve tarama-ile-işleme algılama ile genişletir.
  • Screaming Frog Log File Analyser — yerleşik AI bot ön ayarlarına (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot) ve bir “Verify Bots When Importing” geçişine sahip bir masaüstü içe aktarıcı. Response Codes sekmesi URL başına 2XX/3XX/4XX/5XX’i ayırır, User Agents sekmesi bot başına istekleri ve hata oranlarını gösterir, URLs sekmesi Num Events’e (en çok getirilen sayfalar) göre sıralar ve IPs sekmesi şüpheli kaynakları araştırmanıza olanak tanır (öğretici).
  • ELK Stack (Elasticsearch / Logstash / Kibana) veya Splunk — tek seferlik içe aktaran bir masaüstü aracı çok yavaşladığında veya periyodik dışa aktarmalar yerine sürekli izleme istediğinizde, panolar ve uyarılarla sürekli, daha büyük ölçekli alım için.
  • BigQuery — uzun vadeli saklama ve ölçekte SQL sorgulama için, genellikle Cloudflare Logpush veya Cloudflare’in httpRequestsAdaptiveGroups veri kümesinden zamanlanmış bir GraphQL çekmesiyle beslenir; böylece düz dosyaları yeniden içe aktarmadan bot etkinliğini sayfa, tarih ve durum koduna göre sorgulayabilirsiniz.
  • Cloudflare AI Crawl Control (Cloudflare arkasındaki siteler için) — kendi hattınızı oluşturmadan tarayıcı etkinliği ve istek modelleri, bot doğrulama ve yönerge uyumluluk takibi için yönetilen bir panel (belgeler).

Adım 4 — Ne ölçülmeli ve nasıl okunmalı

Bota göre tarama sıklığı. Her bot adı için günlük/haftalık istek sayısı. AI botları düzenli akışlar hâlinde değil, ani patlamalar hâlinde tarama yapar. WISLR’ın 48 günlük CDN günlüğü vaka çalışmasında GPTBot haftalarca hiç görünmedi, ardından tek bir haftada 187 istek yaptı; bunların 152’si üç dakikalık bir patlama sırasında gerçekleşti ve hız dakikada 114 istekle zirveye ulaştı (WISLR). Sıklığı yalnızca toplam sayı olarak değil, bir davranış örüntüsü olarak değerlendirin.

Hangi sayfalar ziyaret ediliyor, hangi önemli sayfalar edilmiyor? İstek sayısına göre sıralayın. Busby, AI tarayıcılarının genellikle yüzeyde kaldığını belirtir; yalnızca ana sayfa, birincil gezinme sayfaları ve az sayıdaki üst düzey URL ile sınırlı kalmaları yaygındır (SEL). Alıntılanma açısından en önemli olabilecek derin sayfalara gelindiğinde istekler keskin biçimde azalır. Günlüklerde hiç görünmeyen derin bir sayfa alınamaz.

Ham HTML bağımlılığı — ölçün, genellemeyin. Sağlayıcı belgeleri GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot ve diğer aracılar için ortak bir JavaScript işleme sözleşmesi sunmaz. Yine de gözlemlenen bir işaret yararlı olabilir: WISLR örneğinde ChatGPT-User yalnızca HTML getirdi; görseller, CSS veya JS dosyaları için hiç istek yapmadı. Googlebot ve OAI-SearchBot ise görselleri de aldı (WISLR). Günlükleriniz AI botlarının ham HTML’si neredeyse boş bir JS kabuğundan oluşan sayfalara sürekli istek yaptığını gösteriyorsa bu, kontrol edilebilir bir bağımlılık riskidir; her sağlayıcının daima böyle davrandığının kanıtı değildir. Sunulan HTML’yi sonuçlarla veya sağlayıcıya özgü getirme testleriyle karşılaştırın. (İşleme temelleri için JavaScript SEO’ya bakın.)

Durum kodları / engellenen istekler dökümü. Şunları izleyin: 200 (başarılı), 304 (değiştirilmedi — verimli yeniden tarama), 404 (botun izlediği bozuk bağlantılar) ve 403/429 (engellendi / hız sınırına takıldı). Busby, günlük dosyalarının tarayıcıların sorun yaşadığı noktaları; özellikle 403 yanıtlarını (engellenen istekler) ve 429 yanıtlarını (hız sınırlaması) ortaya çıkardığını belirtir (SEL). Engellemenin kasıtlı mı yoksa yanlışlıkla mı uygulandığını kontrol edin.

robots.txt ve llms.txt isteklerini kendi sinyalleri olarak ele alın. Hangi botların taramadan önce /robots.txt dosyasını hiç kontrol etmediğini çapraz referanslayın — WISLR örneğinde, GPTBot ve Meta-WebIndexer 48 gün boyunca bunu hiç kontrol etmedi — ve yasaklanan yolların yine de ziyaret edilip edilmediğini kontrol edin. WISLR ayrıca bu 48 gün boyunca herhangi bir yapay zeka botundan /llms.txt dosyasına sıfır istek kaydetti (WISLR); bu, AI tarayıcılar makalesinde ele alınan yaklaşık %97 oranında okunmama bulgusuyla tutarlıdır. Günlüklerinizde llms.txt isteklerini, onun “çalıştığının” kanıtı olarak beklemeyin.

Daha fazla tarama daha fazla alıntı anlamına mı gelir? Dürüst olun.

“Daha çok taranırsanız daha çok alıntılanırsınız” iddiasını destekleyen yerleşik bir veri yoktur. İçeriğin alınması, alıntılanmak için gerekli bir ön koşuldur ancak yeterli olmaktan çok uzaktır. Sayfalar; istemci tarafında işleme, ödeme duvarları, zayıf veya yinelenen içerik ya da modelin alma/sıralama aşamasında daha iyi bir kaynağa yenilme gibi nedenlerle sürekli tarandıkları hâlde hiç alıntılanmayabilir. Temel çerçeve LLM görünürlüğü makalesinde yer alır: alınan → bahsedilen → alıntılanan. Günlük analizi yalnızca ilk aşamayı gözlemler.

Döngüyü dürüstçe tamamlamanın yolu, tarama girdisi tarafını (günlüklerinizi) alıntı çıktısı tarafıyla eşleştirmektir. Bing’in AI Performance raporu (genel önizleme, Şubat 2026), alıntı verilerini grounding sorgularıyla, yani AI’ın ürettiği yanıtlarda kaynak gösterilen içeriği alırken kullandığı anahtar ifadelerle birlikte sunan ilk resmî araçtır (Bing Webmaster Blog). Günlükler neyin alındığını; grounding sorguları ve alıntı sayıları ise bunun sonucunda ne olduğunu gösterir. Bunların hiçbiri tek başına resmin tamamını sunmaz. Bu katmanların nasıl bir araya geldiğini görmek için ölçüm ve raporlama merkezine bakın.

Gizli tarama sorunu

Doğrulama tek seferlik bir denetim değildir. Seer Interactive’den Clint Spaulding’e göre, engellendikten sonra gizli tarayıcılar genel tarayıcı başlıkları ve ilgisiz IP’ler altında yeniden ortaya çıkabilir — bu oturumlar günlüklerde insan gibi görünür; bu da oturum sayılarının şişirilmesine, bot trafiğinin eksik sayılmasına ve GEO segmentasyonunun daha az güvenilir hale gelmesine neden olur (Seer). Onun net özeti: bu gizli tarayıcıları göremezseniz, etkilerini ölçemezsiniz. Günlük analizinin tek bir geçiş değil, periyodik yeniden doğrulama ve yeniden temel belirleme gerektirmesinin nedeni tam olarak budur.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.