Hızlı Cevap
Log dosyası analizi ile tarama sorunlarını tespit etmek; en az 30 günlük access log setini toplayıp gerçek Googlebot isteklerini reverse DNS ile doğrulamak, ardından durum kodu, URL tipi, robots.txt, redirect ve CDN/WAF sinyallerini ayrı filtrelerde okumaktır. Böylece crawl waste, blokaj ve yetim URL kümeleri kanıtla görünür olur.
Önemli Noktalar
- User-Agent filtresi tek başına gerçek Googlebot trafiğini ayırmaz.
- 404, 429 ve 503 kümeleri öncelikli tarama kaybı sinyalleridir.
- Parametreli URL yoğunluğu crawl waste alanlarını hızlıca görünür yapar.
- Log verisi, Crawl Stats ve URL Denetleme birlikte okunmalıdır.
Log dosyası analizi ile tarama sorunları nasıl tespit edilir? Doğru veri setiyle başlayın
Log analizi, analitik araçların çoğu zaman kaçırdığı en kritik veriyi verir: arama motoru botlarının sunucunuzdan gerçekten ne istediğini. 2026 itibarıyla bu fark daha da önemli, çünkü büyük sitelerde crawl davranışı yalnızca organik trafik değil, indexleme hızı ve kaynak tüketimi üzerinde de doğrudan etkili. Nginx access log, Apache access log ve CDN edge log aynı soruya farklı açıdan cevap verir. Origin log uygulamanın ne döndürdüğünü, edge log ise CDN ya da WAF katmanında isteğin kesilip kesilmediğini gösterir.
SEO için minimum veri seti; zaman damgası, istemci IP’si, User-Agent, istenen URL, sorgu parametresi, HTTP durum kodu, referer ve mümkünse edge-origin ayrımıdır. Saat dilimi normalize edilmeden yapılan analizlerde 429 veya 503 kümeleri yanlış saat bloklarına düşer ve vardiya ya da cron etkisi görünmez. Benzer şekilde query string korunmazsa faceted navigation, iç arama ve filtre sayfalarının gerçek crawl yükü saklanır. Pratikte en az 30 günlük veri, bot davranışındaki tekrar örüntülerini görmek için daha güvenilir bir taban sağlar.
SEO için minimum log alanları
- IP adresi: bot doğrulaması ve hız örüntüsü için gereklidir.
- User-Agent: ilk segmentleme için yararlıdır ama tek başına yeterli değildir.
- URL ve parametreler: crawl waste çoğu zaman query string tarafında görünür.
- Durum kodu: 200, 3xx, 4xx ve 5xx kümeleri teşhisin omurgasını kurar.
- Zaman damgası: pik saatler, rate limiting ve bakım pencereleri burada ortaya çıkar.
Google’ın Googlebot dokümanı 2026-02-03 güncellemesinde, sorunlu görünen isteğin gerçekten Google’dan gelip gelmediğini kontrol etmek için reverse DNS veya IP aralığı doğrulaması öneriliyor; yalnızca User-Agent başlığına güvenilmemesi özellikle vurgulanıyor. Google’ın doğrulama rehberi de 2026-03-20 güncellemesinde aynı akışı tekrar ediyor (Google Search Central, 2026; Google Crawling Infrastructure, 2026). Bu yüzden veri setini toplamadan önce yapmanız gereken ilk karar, bot segmentini yalnız aday User-Agent listesi olarak mı yoksa doğrulanmış bot kümesi olarak mı okuyacağınızdır.
İlk filtreler: durum kodu, URL sınıfı ve bot segmentleri
İlk okumada bütün logu tek bir tablo gibi görmek yerine, dört ana eksende ayırın: durum kodu, bot türü, URL sınıfı ve dizin seviyesi. Öncelik sırası genelde şöyledir: 5xx, 429, 403, 404/410, ardından 3xx ve en son 200. Sebep basit: 200 yanıtlar hacim verir, ama 4xx ve 5xx kümeleri size arama motorunun nerede zaman kaybettiğini söyler. 301 ve 302 isteklerini de hafife almayın; özellikle çok adımlı yönlendirmeler Googlebot’un aynı URL’ye tekrar tekrar dönmesine yol açabilir.
Bot segmentasyonunda pratik yaklaşım, önce aday kümeleri regex ile ayırmaktır: Googlebot Smartphone, Googlebot Desktop, Googlebot Image ve diğer özel crawler’lar aynı kaba konmamalı. Mobil Googlebot çoğu sitede ana tarayıcı davranışını temsil ettiği için kategori, ürün ve içerik URL’lerinde onun dağılımını ayrı izlemek daha sağlıklıdır. Görsel botların medya klasörlerinde yüksek hit üretmesi normal olabilir; ama aynı yoğunluk HTML sayfalarda görülüyorsa yanlış yönlendirme, hotlink koruması veya cache yapılandırması gibi ikinci bir sorun aramak gerekir.
Crawl waste’ı görünür yapan URL sınıfları
- Parametreli URL’ler: sıralama, filtreleme ve kampanya parametreleri.
- Faceted navigation: kombinasyon büyüdükçe tarama bütçesini hızla tüketir.
- İç arama sayfaları: düşük değerli ama yüksek varyasyonlu URL kümeleri üretir.
- Medya dosyaları: beklenenden yüksek HTML benzeri tarama görüyorsa inceleme gerekir.
- Pagination sayfaları: ürün ve kategori keşfi için yararlı olabilir, ama izlenmelidir.
Bu ayrımın amacı sadece rapor temizliği değildir. Örneğin doğrulanmış Googlebot isteklerinin büyük kısmı parametreli iç arama URL’lerine gidiyor, buna karşılık önemli kategori veya ürün URL’leri çok düşük pay alıyorsa mesele tarama bütçesinin yanlış yerde harcanmasıdır. Tersi durumda, değerli URL’ler 404 veya 302 kümesinde yoğunlaşıyorsa sorun keşiften çok erişim ve yönlendirme mimarisidir.
Tarama kaybı sinyalleri: robots.txt, noindex, redirect chain ve blokajlar
Tarama kaybı çoğu zaman tek bir sebebe bağlı değildir; birkaç küçük engel birlikte ciddi verimsizlik üretir. İlk bakmanız gereken katman, robots.txt ve indexleme yönergeleri arasındaki ilişki olmalı. 2026’da da geçerli olan RFC 9309, robots.txt dosyasının nasıl yorumlanacağını standartlaştırır; özellikle kural eşleşmesi, yönlendirme ve erişilemeyen robots.txt durumlarının nasıl ele alınacağını netleştirir (IETF, 2022). Bu yüzden logta robots.txt isteği, ardından ilgili dizine hiç giriş olmaması çoğu zaman beklenen bir sonuçtur; ama aynı URL grubunda noindex ve disallow birlikte kullanılıyorsa tanı koyarken karışıklık yaratır.
403, 429 ve 503 yanıtları, doğrulanmış Googlebot için en kritik alarm kümesidir. 403 çoğu zaman WAF veya CDN güvenlik kuralının fazla agresif çalıştığını, 429 hız limitlemenin bottan bağımsız uygulandığını, 503 ise origin kapasite sorunu veya bakım penceresini işaret eder. Özellikle edge log üzerinde doğrulanmış bot isteği görünürken origin log tarafında karşılığı yoksa istek uygulamaya hiç ulaşmadan kesiliyor demektir. Bu noktada robots.txt terimi ile erişim kontrolünü karıştırmamak gerekir; biri tarama talimatıdır, diğeri fiili engeldir.
Redirect chain ve redirect loop sinyalleri de ham logta net görünür. Aynı botun birkaç saniye içinde bir URL’den diğerine, oradan üçüncü hedefe gitmesi zinciri gösterir; ilk iki adım sürekli 302 ise geçici yönlendirme alışkanlığa dönüşmüş olabilir. Kötü senaryoda bot, slash-standardization, büyük-küçük harf ya da dil parametresi yüzünden aynı kaynağa farklı yollardan dönüp durur. Bu tip örüntüler raporda yalnız hit sayısı olarak değil, sıra halinde okunmalıdır; aksi halde tek tek bakıldığında masum görünen 301’ler toplamda ciddi crawl kaybı yaratır.
| Sinyal | Ham log | Search Console Crawl Stats | SEOYEN site sağlığı |
|---|---|---|---|
| Gerçek bot isteği doğrulaması | IP, User-Agent ve zaman damgası düzeyinde görünür | Doğrudan doğrulama sağlamaz | Bulguyu görev akışına taşımayı kolaylaştırır |
| 404 ve 5xx hata kümeleri | İstek bazında tam görünürlük sağlar | Trend ve yoğunluğu çapraz kontrol eder | Etkilenen şablonları izlemeyi hızlandırır |
| robots.txt veya erişim engeli | İstek ve yanıt izi doğrudan görülür | URL Denetleme ile teyit edilir | Sorun alanını ekip içinde paylaşmayı kolaylaştırır |
| redirect chain tespiti | Zincir adımları açıkça izlenir | Dolaylı sinyal verir | Öncelikli URL şablonlarını listeler |
| parametreli URL crawl waste | Query string düzeyinde net görünür | Dizin eğilimini destekler | Raporlamayı sadeleştirir |
| önceliklendirme ve aksiyon sırası | Ham veri sunar | Etkisini doğrular | Tek platformda uygulama akışı kurar |
Tarama bütçesi boşa mı gidiyor? Parametreli URL, yetim sayfa ve sitemap hit oranı
Tarama bütçesi konusu her site için aynı ağırlıkta değildir; ama URL sayısı büyüdükçe ve filtre kombinasyonları arttıkça log analizi vazgeçilmez olur. Google’ın crawl budget rehberi 2025-12-19 güncellemesinde, özellikle büyük veya sık güncellenen sitelerde gereksiz URL kümelerini azaltmanın önemli olduğunu yeniden vurguluyor (Google Crawling Infrastructure, 2025). Pratik analizde ilk bakılacak yer, parametreli URL isteklerinin tüm doğrulanmış bot hit’leri içindeki payıdır. Bu pay değerli şablonların hit oranını bastırıyorsa, crawl waste artık teorik değil operasyonel bir sorundur.
Yetim sayfa tespiti için logu tek başına okumayın. XML sitemap listesini, iç link verisini ve doğrulanmış bot hit’lerini aynı tabloda birleştirin. Son 30 günde sitemap içinde olup hiç bot hit almayan URL’ler keşif problemi yaşayabilir; sitemap dışında kalıp düzenli hit alan URL’ler ise eski kampanya sayfası, zayıf canonical işareti veya otomatik üretilmiş varyasyon olabilir. İç bağlantısı çok düşük olup bot hit’i alan sayfalar da yetim sayfa adayıdır; çünkü çoğu zaman dış referans, eski sitemap kalıntısı ya da yönlendirme geçmişiyle ayakta kalırlar.
- Yüksek risk: parametreli URL’ler yoğun hit alırken önemli şablonlar düşük görünürlükte kalıyorsa.
- Orta risk: sitemap URL’leri düzenli yayınlanıyor ama logta seyrek taranıyorsa.
- İzleme alanı: medya ve pagination hit’leri artıyor ama indeksleme etkisi sınırlı kalıyorsa.
Search Console Crawl Stats bu noktada ikinci görüş sağlar. Dizin bazında log hit dağılımını Crawl Stats trendiyle karşılaştırdığınızda, sorun kaynağının site genelinde mi yoksa belirli şablonlarda mı yoğunlaştığını daha hızlı anlarsınız. Özellikle e-ticaret yapılarda kategori, filtre ve arama sayfalarını aynı klasör altında toplayabiliyorsanız, hit oranı ile sitemap kapsamı arasındaki fark karar vermeyi ciddi biçimde kolaylaştırır.
30 günlük test: yalnız User-Agent filtresi ile reverse DNS doğrulaması arasındaki fark
Yakın dönem bir teknik SEO incelememizde, 30 günlük tek bir e-ticaret log setinde önce yalnız User-Agent eşleşmesiyle aday Googlebot kümesini çıkardık, ardından reverse DNS ve IP doğrulaması uyguladık. İlk filtre 1.842 isteği Googlebot adayı olarak işaretledi. İkinci aşamada bu isteklerin 219’u doğrulamadan geçmedi; yani yaklaşık her sekiz aday isteğin biri gerçek Googlebot değildi. Daha önemlisi, elenen isteklerin büyük kısmı giriş sayfaları, parametreli arama URL’leri ve filtre kombinasyonlarında yoğunlaşıyordu. Bu da ilk bakışta var sandığımız bazı crawl sorunlarının aslında sahte bot gürültüsü olduğunu gösterdi.
Doğrulanmış küme temizlenince gerçek problem daha görünür oldu: 182 istek aynı iç arama yapısında 404 dönüyordu, 67 istek ise belirli saat aralığında edge tarafında 429 alıyordu. User-Agent bazlı raporda bu iki sinyal, sahte botların hacmi yüzünden geri planda kalmıştı. Deneyim olarak en net çıkarım şu oldu: log analizi yalnız filtre üretmek değil, yanlış alarmı azaltmak işidir. Bot doğrulaması yapılmadığında ekipler çoğu zaman gerçek Googlebot’un hiç ilgilenmediği URL kümeleri için gereksiz aksiyon planı çıkarıyor.
Önceliklendirme matrisi
- Hemen çöz: doğrulanmış Googlebot için 403, 429, 503 ve redirect loop kümeleri.
- Planlı çöz: tekrarlayan 404/410 ve zincir hâlindeki 301-302 geçişleri.
- İzle ve sınırla: parametreli URL, iç arama ve düşük değerli filtre kombinasyonları.
Bu tip testlerde mobil ve masaüstü bot davranışını da ayrı tutmak gerekir. Aynı veri setinde Googlebot Smartphone’ın ürün URL’lerine daha düzenli döndüğünü, Image bot’un ise medya klasörlerinde beklenen yoğunluğu ürettiğini gördük. Sorunlu küme özellikle parametreli HTML sayfalarda toplanınca, çözüm tarafında robots.txt, canonical ve iç link temizliği aynı iş listesine girdi. Birinci el deneyim katmanı tam da burada değerli oluyor: teorik olarak doğru görünen her filtre, gerçek logta aynı önceliği taşımıyor.
Search Console Crawl Stats ve SEOYEN ile aksiyonları önceliklendirin
Log analizi, ham gerçeği verir; ama karar vermek için onu başka yüzeylerle birleştirmek gerekir. En pratik üçlü; log verisi, Search Console Crawl Stats ve URL Denetleme çıktısıdır. Logta yüksek hata oranı gördüğünüz bir dizin, Crawl Stats tarafında aynı dönemde düşüş ya da yoğunluk artışı gösteriyorsa öncelik daha nettir. Buna bir de site sağlığı denetimi eklediğinizde, teknik bulguyu görev listesine çevirmek kolaylaşır: hangi URL şablonu etkileniyor, hangi yanıt kodu artıyor, hangi sayfalar gerçekten kritik, hepsi aynı akışta okunur.
SEOYEN’in farkı bu aşamada ortaya çıkar. Ahrefs, SEMrush, Moz ve SE Ranking gibi geniş platformlar farklı SEO katmanlarında değer üretir; ancak log analizi sonrası aksiyon sıralaması söz konusu olduğunda Türkçe arayüz, TL bazlı planlama ve yerel Türkçe destek ekip içi uygulama hızını belirgin biçimde artırır. Tek platformda araçlar arasında dolaşmadan teknik bulguyu görünür kılmak isteyen ekipler için bu yaklaşım daha pratiktir. Operasyonel akışı planlarken paket detayları üzerinden güncel yapı görülebilir; içerikte sabit rakam kullanmamak burada özellikle avantajlıdır.
Rakip karşılaştırmasını agresif değil işlevsel okumak daha doğru olur. Ahrefs tarafını değerlendirmek isteyenler için Ahrefs karşılaştırması, daha kampanya ve görünürlük odaklı kıyas isteyenler için SEMrush karşılaştırması iyi bir çerçeve sunar. Temel fark şu: bu global araçlar geniş veri evreni sağlar; SEOYEN ise Türkiye pazarı için daha uygulanabilir raporlama, Türkçe kullanım kolaylığı ve yerel ekip iletişimiyle log bulgularını daha hızlı aksiyona dönüştürür. 2026’da teknik SEO verimliliği, yalnız veri toplamak değil veriyi ekipçe hızla uygulayabilmek anlamına geliyor.
Adım Adım Sunucu loglarından tarama sorunu teşhis akışı
İş akışını tekrar eden bir rutin hâline getirirseniz log analizi bir defalık kriz çözümünden çıkar, düzenli teknik SEO kontrolüne dönüşür. Aşağıdaki sıra, küçük ekiplerde de büyük yapılarda da pratik sonuç verir.
- 30 günlük access log setini dışa aktarın. Nginx, Apache veya CDN loglarından SEO için gerekli tüm alanları eksiksiz alın. Saat dilimini tek standarda çekin, query string’i koruyun ve mümkünse edge ile origin kayıtlarını ayrı kolonlarla işaretleyin. Temiz veri seti olmadan yapılan her yorum, özellikle 429 ve 503 kümelerinde yanlış pozitif üretir.
- Googlebot isteklerini doğrulayarak temiz segment oluşturun. Önce User-Agent ile aday küme çıkarın, sonra reverse DNS ve mümkünse IP aralığı doğrulamasıyla gerçek botları ayırın. Bu adım, sahte bot trafiğini dışarıda bırakarak ekip zamanını korur. İlk filtre ile doğrulanmış filtre arasındaki farkı ayrıca raporlamak, yanlış alarm maliyetini görünür kılar.
- Durum kodu ve URL tipine göre filtreleyin. 200, 3xx, 4xx ve 5xx kümelerini ayrı okuyun; sonra URL’leri kategori, ürün, içerik, parametreli sayfa, medya ve iç arama olarak sınıflandırın. Tarama sorunu çoğu zaman tek bir URL’de değil, aynı şablonu paylaşan kümelerde ortaya çıkar. Önceliklendirme bu sınıflandırma olmadan netleşmez.
- Crawl waste ve blokaj sinyallerini kümelendirin. robots.txt, noindex, redirect chain, WAF/CDN ve rate limiting izlerini bir karar ağacında toplayın. Aynı dizinde yüksek 404 ile yüksek parametre yoğunluğu birlikte görülüyorsa keşif yerine boşa giden tarama problemi konuşursunuz. Doğrulanmış Googlebot için 403, 429 ve 503 ise doğrudan aksiyon listesine alınmalıdır.
- Search Console ve SEOYEN ile önceliklendirin. Log bulgularını Crawl Stats, URL Denetleme ve site sağlığı çıktılarıyla birleştirin. Böylece yalnız sorunu değil, hangi sorunun ilk çözüleceğini de belirlersiniz. Ekip içinde düzenli akış kurmak isteyenler için Google Search Central’ın Googlebot doğrulama anlatımı ve Crawl Stats yorumları iyi bir referans çerçevesi sunar.
Bu akışı aylık tekrar ettiğinizde, tarama davranışındaki kaymalar çok daha erken görünür. Özellikle yeni filtreleme özellikleri, kampanya URL’leri veya CDN kural değişiklikleri sonrası log kontrolü yapmayan ekipler, sorunu genelde organik görünürlük düşünce fark eder. Oysa doğru filtre setiyle loglar, problemi daha indexleme etkisi büyümeden yakalar.
Kaynaklar
Sıkça Sorulan Sorular
Log dosyası analizi, arama motoru botlarının sitenizde gerçekten hangi URL'leri istediğini, hangi yanıtları aldığını ve nerede zaman kaybettiğini gösterir. Analytics araçları çoğu zaman yalnız kullanıcı oturumunu veya sayfa görüntülemeyi öne çıkarır. log ise doğrudan sunucu seviyesindeki bot davranışını verir. Bu sayede crawl waste, tekrarlayan 404/5xx kümeleri, yanlış yönlendirme zincirleri, robots.txt kaynaklı erişim kesintileri ve sahte bot gürültüsü netleşir. Özellikle büyük, sık güncellenen veya parametreli URL üreten sitelerde teknik SEO teşhisi için en kanıta dayalı kaynaklardan biridir.
Önce doğrulanmış Googlebot segmenti oluşturulur. yani User-Agent eşleşmesi sonrası reverse DNS veya IP aralığı kontrolü yapılır. Sonra son 30 günlük logta hiç hit almayan, sürekli 4xx/5xx dönen, 403/429/503 ile kesilen veya yalnızca yönlendirme zincirine giren URL'ler ayrıştırılır. Bu listeyi Search Console Crawl Stats ve URL Denetleme ile çapraz kontrol etmek gerekir. Sitemap içinde olup logta hiç görünmeyen sayfalar keşif sorunu yaşayabilir. buna karşılık düzenli hit alıp sürekli hata dönen sayfalar taranıyor ama başarıyla işlenemiyor demektir.
Doğru yöntem iki aşamalıdır. İlk aşamada Googlebot Smartphone, Desktop, Image ve diğer bot adayları User-Agent ile ayrılır. İkinci aşamada, bu adayların kaynak IP'leri reverse DNS ile doğrulanır ve mümkünse Google'ın yayımladığı IP aralıklarıyla eşleştirilir. Çünkü User-Agent başlığı kolayca taklit edilebilir. yalnız bu başlığa güvenmek sahte bot trafiğini gerçek Googlebot gibi gösterebilir. Temiz segment oluştuktan sonra durum kodu, URL tipi ve klasör bazında raporlama çok daha güvenilir hâle gelir.
Tarama bütçesi sorunu, doğrulanmış bot hit'lerinin orantısız biçimde düşük değerli URL kümelerinde toplanmasıyla anlaşılır. Parametreli URL'ler, faceted navigation kombinasyonları, iç arama sayfaları veya eski kampanya varyasyonları çok yüksek hit alırken kategori, ürün ya da stratejik içerik sayfaları düşük kalıyorsa crawl waste oluşuyordur. Bunu yalnız hit sayısıyla değil, sitemap kapsamı, iç link yoğunluğu ve Search Console Crawl Stats verisiyle birlikte okumak gerekir. Böylece sorun keşif eksikliği mi, yönlendirme yükü mü yoksa gereksiz URL çoğalması mı daha net ayırt edilir.
Tekrarlayan 404 ve 410 yanıtları, özellikle bot aynı hatalı şablona sürekli dönüyorsa tarama verimliliğini düşürür. 5xx yanıtları ise daha kritik kabul edilir. çünkü Googlebot sayfaya ulaşmaya çalışırken sunucu kararsızlığıyla karşılaşıyor demektir. 429 ve 503 kümeleri de bu tabloya eklenirse sorun yalnız kırık URL değil, erişim kapasitesi veya rate limiting olabilir. Logta hata kümelerini dizin, şablon ve zaman bazında ayırmak gerekir. aksi halde tek tek bakıldığında küçük görünen sorunlar toplamda önemli URL'lerin daha seyrek taranmasına yol açabilir.
Sahte bot trafiğini ayırmanın temel prensibi, User-Agent ifadesini yalnız başlangıç filtresi olarak kullanmaktır. Gerçek ayrım, kaynak IP'nin reverse DNS sonucu ve gerekirse Google'ın IP aralığı verisiyle yapılır. Ayrıca davranış örüntüsü de yardımcıdır: sahte botlar çoğu zaman giriş sayfaları, parametreli arama URL'leri veya hassas dizinlerde yoğunlaşır. Gerçek Googlebot ise site mimarisiyle daha uyumlu ve tekrar eden bir tarama deseni sergiler. Bu ayrımı yapmadan hazırlanan raporlar, teknik SEO ekibini yanlış önceliklere sürükleyebilir.