Sürdürülebilir SEO İçin Log Dosyası Analizi

Bir SEO crawler size sitenin hangi sayfalarının erişilebilir olduğunu gösterebilir, ancak Googlebot'un dün gece saat 03.17'de gerçekten hangi URL'yi istediğini ancak sunucu kayıtlarından öğrenebilirsiniz. İşte log analizinin teknik SEO açısından fark yarattığı nokta tam olarak burasıdır. Sürdürülebilir SEO İçin Log Dosyası Analizi, varsayımlarla değil gerçek bot istekleriyle çalışmayı sağlar ve özellikle büyük sitelerde tarama davranışını anlamak için güçlü bir veri kaynağı sunar. Yaklaşık on yıllık teknik SEO çalışmalarında en değerli bulguların önemli bölümünü crawler raporları ile gerçek sunucu kayıtları arasındaki farklardan elde ettiğimi söyleyebilirim. Bu rehberde SEO için log dosyası analizi nasıl yapılır, Googlebot davranışı nasıl doğrulanır, crawl budget kaybı nasıl bulunur ve log verisi sürdürülebilir teknik SEO izleme sistemine nasıl dönüştürülür sorularına uygulamaya dönük yanıtlar bulacaksınız.

SEO İçin Log Dosyası Analizi Nedir?

SEO için log dosyası analizi, web sunucusu, CDN, WAF veya uygulama katmanlarında oluşan istek kayıtlarını arama motoru botlarının davranışını anlamak amacıyla inceleme sürecidir. Log kayıtları bir botun hangi URL'yi ne zaman istediğini, hangi HTTP durum kodunu aldığını ve isteğin ne kadar sürede yanıtlandığını gösterebilir. Bu veriler sayesinde teknik SEO uzmanı, Googlebot'un teorik olarak hangi sayfaları tarayabileceğini değil gerçekten hangi sayfaları taradığını görür. Özellikle milyonlarca URL üretebilen e-ticaret, ilan, içerik ve pazar yeri yapılarında bu ayrım önemlidir. Sağlıklı bir analiz, crawler, sitemap, Search Console ve analytics verileriyle birleştirildiğinde sitenin gerçek tarama davranışına ilişkin oldukça güçlü bir görünüm sağlar.

Server Log Nedir?

Server log, web sunucusu veya ilgili altyapı bileşeninin gelen istekler hakkında oluşturduğu kayıtların genel adıdır. Bir ziyaretçi, bot, API istemcisi veya tarayıcı sunucuya istek gönderdiğinde sistem bu olay hakkında belirli alanları kaydedebilir. Kayıt içinde zaman, istenen kaynak, HTTP yöntemi, durum kodu ve user agent gibi bilgiler bulunabilir. SEO açısından önemli olan, arama motoru botlarının yaptığı istekleri diğer trafikten ayırarak bu kayıtların davranışsal biçimde analiz edilmesidir. Her altyapının log yapısı aynı olmadığı için analize başlamadan önce hangi katmanın hangi bilgiyi tuttuğunu anlamak gerekir.

Access Log Nedir?

Access log, sunucuya gelen erişim isteklerini kayıt altına alan log türüdür. SEO log analizinde çoğu çalışma bu kayıtlarla başlar çünkü Googlebot gibi botların URL bazlı erişim geçmişi burada görülebilir. Bir access log satırı tek başına sınırlı bilgi verir, fakat milyonlarca satır URL grupları ve zaman serileri halinde incelendiğinde anlamlı örüntüler ortaya çıkar. Örneğin Googlebot'un sürekli 404 dönen belirli bir URL ailesini taradığı fark edilebilir. Benzer biçimde önemli ürün sayfalarının haftalardır tekrar ziyaret edilmediği de access log üzerinden gözlemlenebilir.

Log Dosyası Hangi Bilgileri İçerir?

Bir log dosyasının değeri yalnızca satır sayısıyla değil içerdiği alanlarla belirlenir. SEO analizi için tarih ve saat, URL, HTTP method, status code, user agent, IP, response size ve response time gibi alanların bulunması oldukça yararlıdır. CDN veya load balancer katmanlarında cache status ve upstream status gibi ek alanlar da önemli ipuçları sağlayabilir. Veri eksikse bazı analizler yine yapılabilir, ancak bot doğrulama veya performans karşılaştırması sınırlı kalabilir. Bu nedenle SEO ekibinin engineering veya DevOps ekibiyle ortak bir log şeması üzerinde anlaşması uzun vadede büyük kolaylık sağlar.

Timestamp

Timestamp isteğin hangi tarihte ve hangi saatte gerçekleştiğini gösterir. Bu alan olmadan crawl frequency, crawl freshness ve deployment sonrası değişim analizi sağlıklı yapılamaz. Farklı log kaynakları farklı timezone kullanıyorsa tüm kayıtlar ortak bir zaman dilimine normalize edilmelidir. Özellikle CDN ile origin verisi birleştirilecekse zaman uyumsuzluğu yanlış korelasyonlara yol açabilir. Analizde tarih kadar saat ve dakika seviyesi de önemlidir çünkü 5xx veya crawl düşüşleri belirli deployment anlarıyla ilişkilendirilebilir.

URL

URL alanı botun hangi kaynağa istek yaptığını gösterir ve log analizinin merkezindedir. Tam URL mevcutsa host, path ve query string ayrı alanlara ayrılarak daha güçlü segmentasyon yapılabilir. Büyük sitelerde tek tek URL incelemek yerine URL space yaklaşımı tercih edilmelidir. Örneğin /product/, /blog/ veya ?filter= gibi örüntüler toplu olarak analiz edilebilir. Bu sayede Googlebot'un tarama kapasitesini hangi site bölümlerinde harcadığı daha net görülebilir.

HTTP method

HTTP method isteğin GET, HEAD, POST veya başka bir yöntemle yapıldığını gösterir. SEO crawler davranışında çoğu kaynak isteği GET üzerinden gerçekleşir, ancak log setinde diğer yöntemleri de görmek mümkündür. Analiz sırasında method alanı kullanılarak yalnızca anlamlı sayfa veya kaynak istekleri filtrelenebilir. API ve uygulama logları birleştirildiğinde POST gibi yöntemler insan veya uygulama trafiğini ayırmaya da yardımcı olur. Tekrarlanabilir pipeline içinde method filtresinin açıkça tanımlanması veri tutarlılığını artırır.

status code

Status code sunucunun isteğe nasıl yanıt verdiğini gösterir ve teknik SEO açısından çok değerlidir. 2xx başarıyı, 3xx yönlendirmeyi, 4xx istemci taraflı erişim problemlerini ve 5xx sunucu problemlerini temsil eder. Loglarda durum kodlarını URL space ve bot türü bazında dağıtmak, hangi site bölümünde problem olduğunu hızlı biçimde gösterir. Özellikle sürekli taranan 404'ler, yoğun 3xx zincirleri ve 5xx artışları öncelikli inceleme alanlarıdır. Status code verisi tek başına yeterli değildir, fakat zaman ve URL segmentiyle birlikte kullanıldığında güçlü bir teşhis aracına dönüşür.

user-agent

User agent isteği yapan istemcinin kendini nasıl tanımladığını gösterir. Googlebot, tarayıcılar, SEO araçları ve sahte botlar bu alanda farklı değerler kullanabilir. Ancak user agent metninde Googlebot yazması isteğin gerçekten Google altyapısından geldiğini kanıtlamaz. Bu nedenle kritik analizlerde IP doğrulama, reverse DNS ve forward DNS kontrolü yapılmalıdır. User agent ilk filtre olarak yararlıdır fakat doğrulama katmanının yerine kullanılmamalıdır.

IP

IP adresi isteğin geldiği ağ kaynağını belirlemeye yardımcı olur. Googlebot doğrulamasında user agent bilgisini tek başına kabul etmek yerine IP tabanlı kontrol yapılması önemlidir. Reverse DNS ve ardından forward DNS doğrulaması sahte botların ayıklanmasında kullanılabilir. IP verisi kişisel veri ve güvenlik gereksinimleri açısından kontrollü tutulmalıdır. SEO ekibine ham IP paylaşmak yerine doğrulanmış bot etiketi içeren filtrelenmiş dataset sunmak çoğu kurumsal yapı için daha güvenli bir çözümdür.

response size

Response size sunucunun isteğe gönderdiği yanıtın boyutunu gösterir. Çok büyük HTML, JavaScript veya API yanıtları tarama ve altyapı maliyeti açısından incelenebilir. Googlebot'un gereksiz derecede büyük düşük değerli sayfaları yoğun biçimde taraması, toplam kaynak kullanımını artırabilir. Response size verisi URL template ile birleştirildiğinde hangi şablonların daha ağır olduğu görülebilir. Bu metrik tek başına SEO başarısını belirlemez, ancak crawl verimliliği ve altyapı optimizasyonu açısından yararlı bir göstergedir.

response time

Response time sunucunun isteğe ne kadar sürede yanıt verdiğini gösterir. Ortalama yerine p95 ve p99 gibi üst yüzdelikler incelendiğinde dönemsel yavaşlamalar daha görünür olur. Bot trafiğinde artan yanıt süresi crawl davranışıyla birlikte değerlendirilebilir. Özellikle belirli saatlerde veya belirli URL template'lerinde yavaşlama görülmesi backend, cache veya upstream sorunlarına işaret edebilir. SEO ve platform ekiplerinin aynı response time dashboardunu kullanması sorunun daha hızlı teşhis edilmesini sağlar.

Log Analizi SEO Crawler'dan Nasıl Farklıdır?

SEO crawler, sizin belirlediğiniz kurallara göre siteyi tarar ve hangi URL'lerin keşfedilebilir olduğunu gösterir. Server log ise gerçek dünyada arama motoru botlarının hangi URL'lere gerçekten istek gönderdiğini kaydeder. Crawler bir sayfayı bulabiliyor diye Googlebot'un o sayfayı yakın zamanda taradığı varsayılamaz. Tersine crawler'ın internal linklerle bulamadığı eski bir URL, backlink veya geçmiş keşif nedeniyle Googlebot tarafından hâlâ taranıyor olabilir. En değerli analizlerden biri bu iki veri setini birleştirip crawler buluyor ve Googlebot tarıyor, crawler buluyor ama Googlebot taramıyor veya crawler bulamıyor ama Googlebot tarıyor segmentlerini karşılaştırmaktır.

Log Dosyası Analizi SEO İçin Neden Önemlidir?

Log analizi SEO çalışmalarına doğrudan gerçek crawler davranışı ekler. Bir URL'nin sitemap'te olması veya iç bağlantı alması, arama motoru botunun onu gerçekten ne sıklıkla ziyaret ettiğini tek başına göstermez. Log verisi bu boşluğu doldurur ve crawl allocation, hatalar, yönlendirmeler, yanıt süresi ile tarama tazeliği hakkında ölçülebilir bilgi sunar. Büyük sitelerde bu bilgiler, teknik SEO backlogunun varsayıma göre değil gerçek etkiye göre önceliklendirilmesini sağlar. Ayrıca düzenli log monitoring kurulduğunda teknik SEO çalışması dönemsel audit yaklaşımından sürekli gözlem ve erken uyarı modeline geçebilir.

Search Engine Botlarının Gerçek Davranışını Gösterir

Arama motoru crawlerının hangi URL'yi teorik olarak keşfedebileceği ile gerçekten hangi URL'yi taradığı farklı konulardır. Log dosyası gerçek isteği gösterdiği için bu davranışın en doğrudan veri kaynaklarından biridir. Örneğin sitemap içinde yer alan kritik ürün sayfası haftalardır taranmıyorsa bu durum crawler raporundan anlaşılamayabilir. Aynı zamanda parametre URL'lerinin yoğun biçimde tarandığı loglarda açıkça görülebilir. Server log analizi ile Googlebot tarama davranışı nasıl incelenir sorusunun temel yanıtı, doğrulanmış bot isteklerini zaman, URL space ve HTTP durum kodu bazında segmentlemektir.

Crawl Sorunlarını Varsayım Yerine Veriyle Doğrular

Teknik SEO ekipleri bazen robots, sitemap veya internal link değişikliğinin beklenen sonucu verdiğini varsayar. Log verisi bu varsayımı doğrulamak veya yanlışlamak için kullanılabilir. Örneğin belirli bir parametre alanını robots.txt ile sınırladıktan sonra Googlebot'un bu URL space üzerindeki isteklerinin gerçekten azalıp azalmadığı izlenebilir. Migration sonrasında eski URL'lerin taranma eğilimi ve yeni URL keşfi de aynı şekilde takip edilebilir. Böylece teknik değişiklik yalnızca uygulanmış olmakla kalmaz, gerçek crawler davranışı üzerinde sonuç üretip üretmediği de ölçülür.

Teknik Problemleri Erken Yakalar

Düzenli log monitoring 404, 429 ve 5xx artışlarını erken gösterebilir. Özellikle deployment sonrasında bot isteklerinde oluşan hata spike'ları kısa sürede fark edilebilir. Kritik URL gruplarının crawl sıklığında ani düşüş de uyarı sinyali olarak kullanılabilir. Bu yaklaşım, sorun Search Console raporlarında veya organik performansta belirgin hale gelmeden önce teknik ekibin aksiyon almasını mümkün kılar. Sürdürülebilir teknik SEO açısından loglar yalnızca geçmişi inceleyen audit dosyası değil aktif monitoring kaynağı olarak değerlendirilmelidir.

Site Değişikliklerinin Etkisini Doğrular

Migration, robots değişikliği, internal link güncellemesi veya redirect temizliği yapıldığında crawler davranışının nasıl değiştiği önemlidir. Loglarda değişiklik tarihini işaretleyip önce ve sonra dönemleri karşılaştırmak doğrudan sonuç görmeyi sağlar. Örneğin eski URL isteklerinin azalması ve yeni URL crawl oranının yükselmesi migration açısından olumlu sinyal olabilir. Aynı şekilde redirect zincirini temizledikten sonra Googlebot'un artık nihai URL'ye daha fazla doğrudan istek gönderip göndermediği izlenebilir. Bu doğrulama adımı teknik SEO işlerinin tamamlanma kriterinin bir parçası olmalıdır.

Sürdürülebilir Teknik SEO Monitoring'i Sağlar

Tek seferlik audit belirli bir günün fotoğrafını verir. Log monitoring ise crawler davranışını zaman içinde izleyerek değişiklikleri ve anomalileri yakalar. Günlük otomatik alarmlar, haftalık özetler ve aylık derin analizler birlikte kullanıldığında daha sürdürülebilir bir sistem oluşur. Böyle bir yapı, teknik SEO problemlerini büyük projelere dönüşmeden önce küçük sinyaller halinde fark etmeye yardımcı olur. Sürdürülebilir SEO İçin Log Dosyası Analizi tam olarak bu nedenle yalnızca analiz değil gözlemlenebilirlik ve operasyon yaklaşımı olarak düşünülmelidir.

Log Analizi ile Google Search Console Arasındaki Fark Nedir?

Google Search Console ile server log verisi birbirinin alternatifi değildir. Search Console arama görünürlüğü, indeksleme durumu, crawl istatistikleri ve çeşitli teknik raporlar sunarken loglar gerçek HTTP isteklerinin ayrıntılı geçmişini gösterir. Search Console size belirli bir URL'nin indekslenme durumuyla ilgili bilgi verebilir, ancak her tarama isteğinin zamanını ve sunucudan aldığı yanıtı ham şekilde sunmaz. Loglar ise crawling hakkında ayrıntılı bilgi verir fakat tek başına bir URL'nin indekslendiğini veya sıralandığını kanıtlamaz. En doğru yaklaşım bu iki kaynağı URL ve zaman boyutunda birlikte değerlendirmektir.

Search Console Hangi Soruları Cevaplar?

Search Console bir URL'nin Google tarafından bilinen indeksleme durumu, sitemap sağlığı, organik sorgu performansı ve genel crawl istatistikleri hakkında bilgi sağlayabilir. Site genelindeki teknik sorunların geniş ölçekli etkisini anlamak için oldukça değerlidir. Ancak veriler her zaman ham HTTP istek seviyesinde değildir ve bazı raporlarda örnekleme veya gecikme olabilir. Bu nedenle ayrıntılı crawler davranışı analizi için loglarla tamamlanması gerekir. Search Console daha çok arama ve indeksleme perspektifi sunarken loglar altyapı seviyesindeki gerçek erişim geçmişini ortaya koyar.

Server Log Hangi Soruları Cevaplar?

Server log belirli bir botun hangi URL'ye hangi anda istek yaptığını, hangi status code'u aldığını ve yanıtın ne kadar sürdüğünü gösterebilir. URL template bazında crawl frequency hesaplanabilir. Sürekli taranan 404'ler, redirect kaynakları ve 5xx sorunları gerçek bot istekleri üzerinden görülebilir. CDN veya cache alanları mevcutsa crawlerın hangi altyapı katmanından yanıt aldığı da analiz edilebilir. Bununla birlikte log verisi bir URL'nin indekslendiğini, arama sonuçlarında gösterildiğini veya hangi pozisyonda sıralandığını tek başına söylemez.

URL Seviyesi Crawl Geçmişi

Log verisinin güçlü yanlarından biri URL seviyesinde gerçek crawl geçmişi sunmasıdır. Bir URL'nin son taranma tarihi, belirli dönemde kaç kez istendiği ve aldığı status code'lar hesaplanabilir. Bu veri özellikle kritik landing page ve hızlı güncellenen içeriklerin freshness analizinde önemlidir. Sitemap veya internal crawl verisiyle karşılaştırıldığında Googlebot'un hangi sayfalara daha fazla ilgi gösterdiği görülebilir. Geçmiş veri yeterince uzun tutulursa migration veya mimari değişikliklerin crawler davranışı üzerindeki uzun dönem etkisi de ölçülebilir.

İki Veri Kaynağı Neden Birlikte Kullanılmalıdır?

Loglar crawling katmanını güçlü biçimde gösterirken Search Console indeksleme ve arama performansı hakkında farklı sinyaller sunar. Crawled ve indexed, crawled ve not indexed veya discovered ve not crawled segmentleri oluşturmak sorunun hangi aşamada olduğunu anlamayı kolaylaştırır. Örneğin Googlebot sayfayı sık tarıyor ama URL indekslenmiyorsa yalnızca crawl budget üzerinde çalışmak yanlış öncelik olabilir. Tersine kritik bir URL uzun süredir taranmıyorsa internal link, sitemap veya crawl demand tarafı incelenebilir. Bu nedenle çoklu veri modeli tek rapora bağlı kalmaktan daha sağlıklı teknik SEO kararları üretir.

Crawling, Rendering, Indexing ve Ranking Arasındaki Fark Nedir?

Teknik SEO analizinde crawling, rendering, indexing ve ranking kavramlarının birbirinden ayrılması gerekir. Googlebot'un bir URL'ye istek göndermesi yalnızca crawling olayını kanıtlar. İçeriğin nasıl render edildiği, indekslenip indekslenmediği ve arama sonuçlarında hangi pozisyonda yer aldığı farklı aşamalardır. Log analizinde en sık yapılan yorum hatalarından biri taranmış URL'yi otomatik olarak indekslenmiş kabul etmektir. Sağlıklı analizde her veri kaynağının hangi aşama hakkında kanıt sunduğu açıkça belirlenmelidir.

Crawling

Crawling arama motoru botunun URL'yi ziyaret ederek kaynağı istemesi sürecidir. Server log bu aşamayı doğrudan gözlemlemeye yardımcı olur çünkü istek sunucu katmanına ulaşmıştır. İstek zamanı, status code ve user agent bilgisi kayıt içinde bulunabilir. Bu nedenle log analizi crawl frequency ve freshness ölçümünde oldukça güçlüdür. Ancak taramanın gerçekleşmesi daha sonraki rendering, indexing veya ranking aşamalarının başarıyla gerçekleştiğini tek başına kanıtlamaz.

Loglarla görülebilir

Bir bot isteği log sisteminin kapsadığı altyapı katmanından geçtiyse crawling olayı görülebilir. Burada hangi log katmanına bakıldığı önemlidir çünkü CDN'de yanıtlanan istek origin access loguna ulaşmayabilir. Bu yüzden yalnızca origin verisine bakmak bazı crawler isteklerini eksik gösterebilir. CDN veya WAF kullanılan yapılarda uç katman logları da değerlendirilmelidir. Doğru veri kaynağı seçildiğinde loglar crawling davranışının en somut kayıtlarından birini sağlar.

Rendering

Rendering taranan HTML ve bağlı kaynakların işlenerek sayfanın kullanılabilir temsilinin oluşturulması sürecidir. JavaScript kullanan sitelerde bu aşama daha fazla önem kazanır. Server loglar JavaScript, CSS veya API isteklerini gösterebilir ve rendering davranışı hakkında bazı dolaylı sinyaller verebilir. Ancak yalnızca loglara bakarak sayfanın tam olarak nasıl render edildiği kesin biçimde söylenemez. Render testi için ayrı araçlar ve Search Console gibi kaynaklar gerekebilir.

Loglarla kısmen gözlemlenebilir

JavaScript dosyası veya API endpointi arama motoru altyapısı tarafından istendiğinde bu istek loglarda görülebilir. Böylece botun bazı render kaynaklarına ulaştığı anlaşılabilir. Fakat kaynak isteğinin gerçekleşmesi nihai DOM'un doğru oluştuğunu kanıtlamaz. JavaScript hatası, içerik koşulu veya client side davranış log kayıtlarında tam olarak görünmeyebilir. Bu nedenle rendering analizi log, DevTools, crawler render testleri ve Search Console verileriyle birlikte yapılmalıdır.

Indexing

Indexing, arama motorunun taradığı içeriği değerlendirmesi ve uygun görürse indeksine dahil etmesi sürecidir. Log dosyası URL'nin tarandığını gösterebilir ama indekslenip indekslenmediğini tek başına doğrulamaz. Bir sayfa sık taransa bile canonical, kalite, noindex veya diğer nedenlerle indeks dışında kalabilir. Bu ayrımı anlamak crawl budget ile indeksleme problemlerini birbirine karıştırmamak açısından önemlidir. Search Console URL inspection ve indeksleme raporları bu aşama için daha uygun veri kaynaklarıdır.

Log tek başına kanıtlamaz

Googlebot'un bir URL'ye 200 yanıtıyla ulaşmış olması o URL'nin indekste yer aldığı anlamına gelmez. Log yalnızca isteğin ve sunucu yanıtının kaydını sunar. İndeksleme için arama motoru daha farklı değerlendirmeler yapabilir. Bu nedenle crawled ve indexed iki ayrı durum olarak modellenmelidir. Teknik SEO dashboardunda bu ayrım açık biçimde gösterildiğinde yanlış aksiyon alma riski azalır.

Ranking

Ranking bir URL'nin belirli arama sorgularında hangi konumda gösterildiğiyle ilgilidir. Server log verisi bu alanı doğrudan ölçmez. Botun sık taradığı sayfanın daha yüksek sıralanacağı gibi basit bir sonuç çıkarılamaz. Crawl frequency birçok farklı faktörden etkilenebilir ve ranking için tek başına başarı göstergesi değildir. Ranking analizi Search Console performans verisi ve diğer arama görünürlüğü ölçümleriyle yapılmalıdır.

Log analizinin doğrudan ölçüm alanı değildir

Log dosyaları crawling davranışını anlamak için kullanılır. Arama sonucundaki pozisyon, tıklama ve gösterim verileri bu kayıtların doğal parçası değildir. Bu nedenle log KPI'ları ile ranking KPI'ları aynı şey gibi yorumlanmamalıdır. Yine de log sorunlarının düzeltilmesi teknik erişilebilirlik ve tarama verimliliği açısından SEO sistemini destekleyebilir. Etki değerlendirilirken crawl verisi ile Search Console performansı farklı katmanlar olarak izlenmelidir.

Crawled ≠ Indexed ≠ Ranked

Bir URL'nin crawled olması yalnızca arama motoru botunun o kaynağa eriştiğini gösterir. Indexed olması, arama motorunun içeriği indeksine dahil ettiğini ifade eder. Ranked olması ise belirli bir sorguda arama sonuçlarında konum elde etmesiyle ilgilidir. Bu üç durum birbirinin otomatik sonucu değildir ve farklı veri kaynaklarıyla doğrulanmalıdır. Teknik SEO analizinde bu ayrım korunursa log bulguları daha doğru yorumlanır ve crawl problemi olmayan bir sayfada gereksiz crawl optimizasyonu yapılmasının önüne geçilir.

Crawl Budget Nedir?

Crawl budget, arama motorunun bir siteyi ne kadar ve hangi hızda tarayabileceği ile ne kadar taramak istediğinin birleşimi olarak düşünülebilir. Her sitede aynı önem düzeyine sahip değildir. Küçük ve statik bir kurumsal sitede yüzlerce gereksiz parametre URL'si yoksa crawl budget genellikle en önemli SEO problemi değildir. Buna karşılık milyonlarca ürün, facet, filtre veya sık güncellenen içerik üreten büyük sistemlerde crawl allocation ciddi bir konu haline gelebilir. Log file analysis ile crawl budget ve indexleme sorunları nasıl tespit edilir sorusunda ilk adım crawling ve indexing sorunlarını birbirinden ayırmaktır.

Crawl Capacity

Crawl capacity arama motorunun siteyi sunucuya aşırı yük bindirmeden ne ölçüde tarayabileceğiyle ilişkilidir. Sunucu sürekli yavaşlıyor veya 5xx üretiyorsa crawler davranışı bundan etkilenebilir. Response time, 429 ve 5xx oranları loglardan takip edilebilir. CDN, cache ve origin kapasitesi bu açıdan önemlidir. Teknik ekipler yalnızca SEO metriklerine değil altyapının bot isteklerine sağlıklı yanıt verip veremediğine de bakmalıdır.

Crawl Demand

Crawl demand arama motorunun hangi URL'leri ne sıklıkta yeniden ziyaret etmek istediğiyle ilgilidir. Sık güncellenen veya önemli sayfaların daha yüksek talep görmesi mümkündür. Eski, düşük değerli veya kopya URL alanlarında crawl talebi zamanla azalabilir. Loglarda frequency ve days since last crawl ölçümü bu davranışı anlamaya yardımcı olur. Ancak demand yorumları kesin ranking sinyali olarak değerlendirilmemelidir.

Crawl Budget Her Site İçin Kritik midir?

Hayır, crawl budget her site için ana teknik SEO konusu değildir. Yüz veya birkaç bin temiz URL barındıran küçük sitelerde temel teknik erişilebilirlik, içerik kalitesi ve indeksleme sorunları genellikle daha yüksek öncelik taşır. Crawl budget konusu özellikle çok büyük veya hızlı değişen URL alanlarında anlam kazanır. Log analizi yine de küçük sitelerde migration veya hata kontrolü için yararlı olabilir. Maliyet ve fayda değerlendirmesi yaparak sürekli monitoring gerekip gerekmediğine karar verilmelidir.

Büyük Siteler

Büyük sitelerde milyonlarca potansiyel URL üretilebilir ve bunların hepsi aynı iş değerine sahip değildir. Parametre, filtre ve düşük değerli duplicate alanlar Googlebot isteklerinin önemli bölümünü tüketebilir. URL space segmentasyonu sayesinde yüksek ve düşük değerli bölümlerin crawl payları karşılaştırılabilir. Priority crawl share metriği burada yararlıdır. Amaç her requesti azaltmak değil tarama dağılımının stratejik sayfalar lehine sağlıklı olup olmadığını anlamaktır.

Hızlı Güncellenen Siteler

Haber, ilan, stok veya fiyat bilgisi sık değişen platformlarda crawl freshness önem kazanır. Kritik URL'lerin son crawl tarihi ve ortalama ziyaret aralığı loglardan hesaplanabilir. Güncellenen içerik uzun süre tekrar taranmıyorsa discovery ve crawl demand tarafı incelenebilir. Sitemap lastmod, internal linking ve site mimarisi bu süreçte değerlendirilebilir. Sadece toplam request sayısı yerine önemli içeriğin ne kadar hızlı yeniden tarandığına bakmak daha anlamlıdır.

E-Ticaret ve Marketplace Siteleri

E-ticaret ve marketplace sistemlerinde ürün, kategori, facet, filtre, sıralama ve arama parametreleri çok geniş URL alanı oluşturabilir. Bu yapılar crawl waste analizi için tipik örnektir. Loglarda ?filter=, ?sort= veya benzeri patternler ayrı segmentlere ayrılabilir. Kritik ürün ve kategori sayfalarının request payı düşük kalıyorsa internal mimari ve URL kontrol stratejisi yeniden değerlendirilmelidir. Kurumsal web siteleri için SEO log analizi ve crawl optimizasyonu hizmeti de bu tür büyük ölçekli sistemlerde özellikle anlamlı hale gelir.

Küçük Sitelerde Log Analizi Yapmak Gerekir mi?

Küçük bir sitede sürekli log pipeline kurmak her zaman gerekli değildir. Ancak migration, beklenmeyen indeksleme sorunu, yoğun 404, güvenlik katmanı problemi veya bot erişim sorunu olduğunda kısa dönem log analizi çok değerli olabilir. Buradaki karar site büyüklüğünden çok sorunun niteliği ve operasyon maliyetiyle ilgilidir. Küçük sitelerde dönemsel audit çoğu zaman yeterli olurken büyük veya dinamik yapılarda otomatik monitoring daha güçlü fayda sağlar. Bu nedenle log analizi her projeye aynı kapsamda uygulanmamalıdır.

Dönemsel Audit'in Yeterli Olduğu Durumlar

URL sayısı sınırlı, içerik değişim hızı düşük ve teknik altyapısı stabil sitelerde dönemsel audit yeterli olabilir. Migration veya önemli altyapı değişikliğinin ardından 30 ile 90 günlük log örneği incelenebilir. Kritik bot erişimi ve hata oranları kontrol edilir. Sorun bulunmazsa sürekli dashboard kurmak yerine belirli aralıklarla tekrar analiz yapılabilir. Böylece teknik maliyet düşük tutulurken ihtiyaç duyulan görünürlük korunur.

Sürekli Monitoring Gerektiren Durumlar

Çok büyük URL alanı, sık deployment, dinamik facet üretimi veya önemli gelir bağımlılığı bulunan sitelerde sürekli monitoring daha anlamlıdır. Günlük 5xx, 404, 429 ve Googlebot request değişimleri izlenebilir. Kritik sayfaların freshness ve priority crawl share değerleri takip edilebilir. Anomaly alert sistemi beklenmeyen değişiklikleri hızlıca görünür kılar. Bu model teknik SEO'yu dönemsel rapordan operasyonel kalite sürecine dönüştürür.

Maliyet-Fayda Kararı

Log pipeline depolama, parsing, güvenlik ve bakım maliyeti oluşturur. Bu nedenle sistem kurulmadan önce hangi sorulara yanıt vereceği netleştirilmelidir. Küçük bir site için aylık manuel export yeterliyken büyük marketplace için gerçek zamanlı dashboard daha doğru yatırım olabilir. Veri hacmi, log retention ihtiyacı ve iş değeri birlikte değerlendirilmelidir. İyi bir teknik SEO sistemi en fazla veriyi değil karar almaya yetecek doğru veriyi toplar.

SEO Analizi İçin Hangi Log Katmanları İncelenmelidir?

Modern web altyapısında kullanıcı veya bot isteği çoğu zaman doğrudan origin web servera gitmez. İstek önce CDN, WAF, load balancer veya reverse proxy gibi katmanlardan geçebilir. Bu nedenle yalnızca origin loguna bakmak gerçek crawler davranışının tamamını göstermeyebilir. CDN tarafından cache hit ile yanıtlanan istek origin kayıtlarında görünmeyebilir veya WAF tarafından engellenen Googlebot isteği origin'e hiç ulaşmayabilir. Sağlıklı SEO log analizi, talebin izlediği altyapı yolunu anlayıp gerekli katmanlardan veri toplamalıdır.

CDN/WAF Logs

CDN ve WAF logları bot isteklerinin origin'e ulaşmadan önce nasıl işlendiğini gösterir. Cache hit, miss, 403, 429 ve rate limiting gibi olaylar burada görülebilir. Özellikle Googlebot yanlış güvenlik kuralı nedeniyle engelleniyorsa origin access logunda bu olay hiç bulunmayabilir. Bu yüzden bot erişim problemi incelenirken edge katmanı kritik veri kaynağıdır. CDN loglarını SEO datasetine dahil etmek, crawlerın gerçek kullanıcıya en yakın altyapı katmanındaki deneyimini anlamayı sağlar.

403

403 yanıtı isteğin sunucu veya güvenlik katmanı tarafından reddedildiğini gösterir. Doğrulanmış Googlebot isteklerinde 403 görülmesi erişim problemi açısından incelenmelidir. URL, zaman, WAF rule ve bot türü birlikte değerlendirilmelidir. Yanlış pozitif güvenlik kuralı varsa ilgili ekip tarafından düzeltilmelidir. Her 403 aynı öncelikte değildir, ancak kritik içerik alanlarına gelen doğrulanmış bot istekleri yüksek öncelik taşır.

429

429 sunucunun veya güvenlik katmanının istek oranını sınırlandırdığını gösterir. Googlebot'un yoğun tarama sırasında bu yanıtı alması crawl kapasitesi açısından önemli olabilir. Hangi saatlerde ve hangi URL alanlarında 429 oluştuğu analiz edilmelidir. Rate limiting kuralı ile altyapı kapasitesi birlikte değerlendirilmelidir. Gereksiz botları sınırlarken doğrulanmış arama motoru crawlerlarını yanlışlıkla etkileyen kurallar ayrıca kontrol edilmelidir.

rate limiting

Rate limiting sistemi altyapıyı aşırı istekten korumak için kullanılır. Ancak bot doğrulaması yapılmadan genel user agent veya IP kuralları uygulanırsa arama motoru crawlerları da etkilenebilir. Loglarda rate limit olaylarının bot segmenti bazında dağılımı incelenmelidir. Security ve SEO ekipleri hangi botların güvenilir olduğunu ortak biçimde tanımlamalıdır. Kapasite problemi varsa yalnızca limiti yükseltmek yerine backend ve cache davranışı da değerlendirilmelidir.

cache

CDN cache durumu crawler isteklerinin origin yüküne etkisini anlamaya yardımcı olur. HIT durumunda yanıt edge üzerinden hızlı verilebilir ve origin isteği oluşmayabilir. MISS veya BYPASS oranlarının yüksek olduğu bot trafiğinde cache politikası incelenebilir. Ancak her HTML kaynağın cache edilmesi doğru değildir ve kişiselleştirme gereksinimleri dikkate alınmalıdır. SEO analizi cache metriğini işlevsel ve güvenli uygulama tasarımıyla birlikte değerlendirmelidir.

Load Balancer Logs

Load balancer logları isteğin hangi backend'e yönlendirildiğini ve upstream davranışını görmeye yardımcı olur. Timeout, routing problemi ve backend failure gibi olaylar burada kayıt altına alınabilir. Googlebot'un aldığı 5xx yanıtının web uygulamasından mı yoksa yönlendirme katmanından mı kaynaklandığını anlamak için değerlidir. Birden fazla origin veya bölge kullanılan yapılarda trafik dağılımı da incelenebilir. SEO log pipeline tasarımında load balancer verisi özellikle hata kök nedeni analizi için faydalıdır.

timeout

Timeout isteğin belirlenen süre içinde sağlıklı yanıt alamadığını gösterir. Bot isteklerinde sık timeout görülmesi crawl kapasitesi ve kullanıcı deneyimi açısından incelenmelidir. URL template ve backend instance bazında dağılım çıkarmak sorunlu bölümü belirlemeyi kolaylaştırır. Deployment veya trafik artışıyla korelasyon kurulabilir. Sorun yalnızca SEO açısından değil altyapı güvenilirliği açısından da ele alınmalıdır.

routing

Routing kuralları isteğin hangi servis veya backend'e gönderileceğini belirler. Yanlış yapılandırma belirli URL gruplarının hatalı servise gitmesine veya beklenmeyen redirect üretmesine neden olabilir. Loglarda host, path ve upstream bilgisi birlikte tutulursa bu problemler daha kolay fark edilir. Migration dönemlerinde routing değişiklikleri özellikle izlenmelidir. Kritik URL'lerin beklenen altyapı yolunu kullandığı doğrulanmalıdır.

upstream failure

Upstream failure load balancer veya proxy arkasındaki uygulamanın sağlıklı yanıt veremediği durumları temsil eder. 502 veya 504 gibi status code'lar bu olaylarla ilişkili olabilir. Bot requestleri üzerinde oluşan spike, belirli backend sürümü veya deployment ile karşılaştırılabilir. CDN üzerinden gelen kayıtlarla origin verisi eşleştirilerek hata katmanı bulunabilir. Bu ayrım doğru ekibin hızlı aksiyon almasını sağlar.

Web Server Access Logs

Web server access logları URL, status code, user agent ve response time gibi temel alanları sağlayabilir. Apache, Nginx veya IIS gibi sistemlerde formatlar farklılaşsa da SEO açısından aynı temel sorular cevaplanır. Googlebot hangi URL'leri taradı, hangi hata kodlarını aldı ve yanıt süresi neydi soruları bu kayıtlarla analiz edilebilir. Büyük veri hacminde loglar ortak bir tablo şemasına dönüştürülmelidir. Bu sayede farklı sunuculardan gelen kayıtlar tek dashboard içinde karşılaştırılabilir.

Application Logs

Application logları access logların göstermediği iş mantığı ve backend hata ayrıntılarını sağlayabilir. Belirli API timeoutları, template render hataları veya veri kaynağı sorunları burada görülebilir. Bot isteği 500 ile sonuçlandığında application error kaydı kök nedeni bulmaya yardımcı olur. SEO ekibinin tüm uygulama loglarına doğrudan erişmesi gerekmez. Daha güvenli yaklaşım, gerekli teknik alanların incident sürecinde engineering ekipleriyle paylaşılmasıdır.

Origin Log Tek Başına Neden Yetersiz Olabilir?

CDN kullanılan sistemde birçok istek origin'e ulaşmadan edge katmanında yanıtlanabilir. WAF tarafından engellenen bot isteği de origin access logunda görünmez. Bu nedenle origin kayıtları gerçek crawler trafiğini eksik gösterebilir. Özellikle 403, 429 ve cache analizinde edge logları kritik öneme sahiptir. İstek akışını uçtan uca anlamadan yapılan log analizi yanlış crawl hacmi ve hata oranı hesaplarına yol açabilir.

SEO Ekibi Engineering'den Hangi Log Alanlarını İstemelidir?

SEO log analizi için her altyapı alanının paylaşılması gerekmez. Amaç karar vermeye yetecek standart bir veri seti oluşturmaktır. Timestamp, hostname, HTTP method, tam URL, query string, status code, user agent, client IP, response time ve response bytes temel alanlardır. CDN veya proxy kullanılıyorsa cache status ile upstream status eklenmesi faydalıdır. Veri güvenliği nedeniyle ham IP veya kişisel query parametreleri SEO ekibine doğrudan verilmek yerine filtrelenmiş ve gerektiğinde anonimleştirilmiş dataset hazırlanabilir.

Timestamp

Timestamp günlük, saatlik ve deployment bazlı analiz için gereklidir. Ortak timezone kullanılması farklı log kaynaklarını birleştirmeyi kolaylaştırır. Zaman alanı milisaniye hassasiyetine kadar tutulabilir fakat SEO analizi için saniye seviyesi çoğu zaman yeterlidir. Günlük aggregation yanında ham olay zamanı da korunmalıdır. Bu sayede anomali tespitinden kök neden analizine geçildiğinde ayrıntılı kayıtlar incelenebilir.

Hostname

Hostname aynı log pipeline içinde birden fazla domain veya subdomain bulunuyorsa önemlidir. Kariyer, blog, ürün veya ülke siteleri ayrı hostlar üzerinde çalışabilir. Host bazında crawl payı ve hata oranı hesaplanabilir. Migration sırasında eski ve yeni hostname istekleri karşılaştırılabilir. Bu alan URL normalizasyonu ve data quality kontrolü açısından da faydalıdır.

HTTP Method

HTTP method GET ve HEAD gibi crawler açısından ilgili istekleri filtrelemeyi kolaylaştırır. API veya kullanıcı trafiği içeren karma datasetlerde diğer yöntemler ayrıştırılabilir. SEO pipeline yalnızca gerekli request türleri üzerinde çalışacak şekilde tasarlanabilir. Method değerlerinin standardize edilmesi önemlidir. Beklenmeyen yöntemlerin yüksek hacimde görülmesi ayrıca veri veya güvenlik kontrolü gerektirebilir.

Full URL

Tam URL host, path ve query parametrelerini birlikte gösterir. Bu alan URL space ve parameter analizinde büyük değer taşır. Ancak şifre, token veya kişisel veri içeren query parametreleri loglanmamalı veya analiz öncesi maskelenmelidir. URL normalization pipeline ile protokol, slash ve parametre sırası gibi farklılıklar ele alınabilir. Ham URL ile normalize edilmiş URL'yi ayrı alanlarda tutmak daha sağlıklı analiz sağlar.

Query String

Query string faceted navigation, sıralama, arama ve tracking parametrelerini analiz etmek için gereklidir. ?filter=, ?sort= ve ?page= gibi patternler crawl waste segmenti oluşturabilir. Ancak query string içinde kişisel veri bulunma riski vardır. Data minimization yaklaşımıyla yalnızca SEO açısından gerekli parametreler tutulmalıdır. Parametre normalizasyonu sayesinde aynı mantıksal URL ailesinin yüzlerce varyasyonu tek segment altında analiz edilebilir.

HTTP Status

HTTP status code botun aldığı yanıtı gösterir. 2xx, 3xx, 4xx ve 5xx oranları bot ve URL space bazında hesaplanmalıdır. Hata trendleri günlük veya saatlik grafiklerle izlenebilir. Migration dönemlerinde 3xx ve 404 dağılımı özellikle önemlidir. Teknik SEO log dashboardunun temel metriklerinden biri status code dağılımıdır.

User-Agent

User agent bot türünü ilk aşamada sınıflandırmak için kullanılır. Smartphone Googlebot, image botları ve diğer crawler türleri farklı etiketlerle ayrılabilir. Ancak sahte user agent riski nedeniyle doğrulanmış Googlebot etiketi ayrıca üretilmelidir. Pipeline içinde raw user agent saklanıp bot family alanı türetilebilir. Böylece yeni crawler patternleri çıktığında sınıflandırma yeniden çalıştırılabilir.

Client IP

Client IP bot doğrulama sürecinde yardımcıdır. Reverse DNS ve forward DNS kontrolleriyle user agent iddiası doğrulanabilir. IP verisinin hassas niteliği nedeniyle erişim sınırlandırılmalıdır. Kalıcı SEO dashboardunda ham IP yerine verified bot etiketi veya hashlenmiş değer kullanılabilir. Güvenlik ve hukuk ekipleri retention ile erişim politikasını birlikte belirlemelidir.

Response Time

Response time bot isteklerinin performansını izlemek için kullanılır. Ortalama değer tek başına yeterli olmayabilir, p95 ve p99 değerleri de hesaplanmalıdır. URL template ve saat bazında yavaşlık analizi yapılabilir. 5xx veya crawl düşüşü ile response time artışı korelasyon gösterebilir. Bu veri SEO ve DevOps ekipleri arasında ortak operasyon metriği haline getirilebilir.

Response Bytes

Response bytes yanıt boyutunu gösterir ve büyük HTML veya kaynakları tespit etmeye yardımcı olur. Template bazında median ve p95 boyutlar hesaplanabilir. Crawl edilen düşük değerli URL'lerin toplam byte maliyeti ayrıca incelenebilir. Bu veri doğrudan ranking metriği değildir fakat altyapı ve crawl verimliliğine ilişkin önemli sinyal sağlar. Büyük değişiklikler deployment sonrasında otomatik olarak izlenebilir.

Cache Status

Cache status CDN veya reverse proxy üzerinden isteğin HIT, MISS veya BYPASS ile yanıtlandığını gösterebilir. Bot response time farklılıklarını anlamada değerlidir. Çok yüksek MISS oranı origin yükünü artırabilir. Ancak dinamik veya kullanıcıya özel içerikte BYPASS beklenen davranış olabilir. SEO analizi teknik ürün gereksinimlerini dikkate alarak yapılmalıdır.

Upstream Status

Upstream status dış katmanın arkasındaki uygulamanın verdiği yanıtı görmeye yardımcı olur. Kullanıcıya 502 dönen bir istekte upstream tarafında timeout veya başka hata görülebilir. CDN, load balancer ve origin problemlerini ayırmak için bu alan önemlidir. Hata analizi daha hızlı doğru owner'a yönlendirilebilir. Özellikle 5xx incident sürecinde upstream status büyük zaman kazandırır.

Apache, Nginx, IIS ve CDN Log Formatları Nasıl Farklılaşır?

Farklı web sunucuları ve CDN platformları log kayıtlarını farklı biçimlerde üretebilir. Apache Combined Log, Nginx access log, IIS W3C ve JSON tabanlı CDN kayıtlarının alan isimleri ve formatları aynı değildir. Bu nedenle çok sistemli kurumsal altyapıda doğrudan ham loglar üzerinde ortak analiz yapmak zorlaşır. En sağlıklı yaklaşım, farklı kaynakları ortak bir SEO data schema içine dönüştüren parsing katmanı oluşturmaktır. Böylece dashboard ve SQL sorguları altyapı teknolojisinden bağımsız çalışabilir.

Apache Combined Log

Apache Combined Log yaygın erişim log formatlarından biridir. IP, timestamp, request, status, byte, referrer ve user agent gibi alanları içerebilir. SEO analizi için parser request alanından method, URL ve protokolü ayırabilir. Custom log format kullanılıyorsa response time veya host gibi ek alanlar eklenebilir. Parsing pipeline devreye alınmadan önce gerçek örnek log satırlarıyla test yapılmalıdır.

Nginx

Nginx log formatı yapılandırılabilir olduğu için farklı sistemlerde farklı alanlar bulunabilir. Varsayılan access log temel request ve response bilgisi sunarken custom format ile request time, upstream time ve host eklenebilir. SEO ekibi ihtiyaç duyduğu alanları DevOps ile baştan belirlemelidir. Büyük trafikte JSON veya yapılandırılmış format parsing işini kolaylaştırabilir. Format değişikliği yapıldığında downstream dashboardların bozulmaması için schema versioning uygulanabilir.

IIS W3C

IIS W3C logları alan başlıkları ve tarih bazlı kayıt yapısıyla farklı bir biçim kullanabilir. URI stem ve query alanları ayrı tutulabilir. SEO analizinde bu parçaların normalize edilmiş URL içinde birleştirilmesi gerekir. Status, substatus ve time taken gibi alanlar teknik teşhiste faydalıdır. Timestamp yorumlanırken kullanılan timezone mutlaka doğrulanmalıdır.

CDN JSON Logs

CDN JSON logları yapılandırılmış olmaları nedeniyle data pipeline için avantajlıdır. Cache status, edge location, security action ve origin response gibi zengin alanlar içerebilir. Ancak alan adları platformdan platforma değişebilir. SEO şemasına dönüşüm katmanı bu farklılıkları soyutlamalıdır. Raw kayıtlar arşivlenirken normalize edilmiş tablo analiz için kullanılabilir.

Cloud Hosting Logs

Cloud hosting ortamlarında web server, load balancer, gateway ve application katmanları ayrı log kaynakları oluşturabilir. Tek bir crawler isteği birden fazla sistemde iz bırakabilir. Request ID gibi ortak alanlar varsa katmanlar arası ilişkilendirme kolaylaşır. SEO pipeline için hangi katmanın authoritative request kaynağı olduğu belirlenmelidir. Aksi durumda duplicate event sayımı nedeniyle crawl hacmi yanlış hesaplanabilir.

Ortak SEO Data Schema Oluşturmak

Ortak schema timestamp, host, path, query, method, status, user agent, bot family, verified bot, response time, bytes ve cache status gibi alanları standart hale getirir. Kaynak sistem değişse bile dashboard aynı sütunlarla çalışır. Raw source ve parser version alanlarının tutulması debug sürecini kolaylaştırır. URL classification ve template ID gibi SEO'ya özel türetilmiş alanlar ayrıca eklenebilir. Bu yaklaşım log analizini tek seferlik dosya işlemeden sürdürülebilir veri ürününe dönüştürür.

Googlebot Loglarda Nasıl Tanımlanır?

Googlebot kayıtlarını ayırmanın ilk yolu user agent üzerinden filtreleme yapmaktır. Ancak güvenilir analiz için bu adım yeterli değildir çünkü herhangi bir bot kendini Googlebot olarak tanıtabilir. Bu nedenle user agent filtresinden sonra IP doğrulama süreci uygulanmalıdır. Smartphone Googlebot, image crawler ve diğer Google crawler türleri ayrı segmentlerde tutulabilir. Böylece farklı bot türlerinin site bölümlerini nasıl kullandığı daha net analiz edilir.

User-Agent

User agent Googlebot adaylarını hızlı biçimde bulmaya yardımcı olur. Pipeline ilk aşamada Google ile ilişkili bilinen user agent patternlerini etiketleyebilir. Ancak bu etiket verified anlamına gelmemelidir. Ayrı bir verification status alanı kullanmak daha güvenlidir. Böylece dashboardda yalnızca doğrulanmış Googlebot requestleri kullanılabilir.

Smartphone Googlebot

Mobil öncelikli crawling nedeniyle Smartphone Googlebot davranışı önemli bir segmenttir. User agent patterniyle ayrılabilir ve doğrulama sürecinden geçirilebilir. Mobil Googlebot'un hangi URL'leri taradığı ve aldığı status code'lar ayrı raporlanabilir. Responsive veya mobil yönlendirme sorunlarında bu segment değerlidir. Site mobile parity açısından ayrıca crawler ve rendering testleriyle doğrulanmalıdır.

Image Botları

Image crawlerlar görsel kaynakları farklı amaçla ziyaret edebilir. Büyük görsel sitelerinde bu trafik web page crawl analizinden ayrı tutulmalıdır. Aksi durumda toplam request sayısı yorumlanırken sayfa crawl hacmi olduğundan yüksek görünebilir. Resource type classification ile resim, CSS, JavaScript ve HTML istekleri ayrılabilir. Image SEO problemi varsa görsel botların status ve freshness dağılımı ayrıca incelenebilir.

Diğer Google Crawlers

Google altyapısından farklı amaçlarla gelen crawler ve fetcher türleri bulunabilir. Tüm Google user agentlarını tek Googlebot kategorisine koymak analiz hatasına yol açabilir. Bot family ve purpose alanları ayrı tutulmalıdır. SEO kararları esas olarak ilgili search crawler segmenti üzerinden verilmelidir. Yeni user agent patternleri düzenli olarak gözden geçirilmelidir.

Sahte Googlebot Nasıl Tespit Edilir?

Teknik SEO log analizinde en önemli veri kalitesi adımlarından biri gerçek Googlebot ile sahte user agentları ayırmaktır. Sadece user agent metninde Googlebot geçtiği için tüm istekleri dahil etmek crawl hacmini ciddi biçimde bozabilir. Doğrulama süreci IP adresi, reverse DNS ve forward DNS kontrolü üzerinden yürütülebilir. Sonuç verified, failed veya unknown gibi statülerle saklanabilir. Büyük pipeline sistemlerinde doğrulanmış IP aralıkları belirli süre cache edilerek her event için yeniden DNS sorgusu yapılması önlenebilir.

User-Agent Neden Yeterli Değildir?

User agent istemci tarafından gönderilen metinsel bir headerdır ve kolayca taklit edilebilir. Kötü niyetli crawler veya scraper kendini Googlebot gibi gösterebilir. Bu istekler dahil edilirse crawl frequency, error rate ve response time analizleri yanlış sonuç üretir. Bu nedenle user agent yalnızca aday filtre olarak kullanılmalıdır. Doğrulanmış bot etiketi veri modelinin temel alanlarından biri olmalıdır.

IP Doğrulama

IP doğrulama isteğin gerçekten beklenen arama motoru altyapısından gelip gelmediğini kontrol etmeye yardımcı olur. Doğrudan sabit IP listesine güvenmek yerine resmi doğrulama yöntemleri takip edilmelidir. Pipeline doğrulama sonucunu ayrı tabloda cache edebilir. Böylece milyonlarca log kaydı üzerinde performans kaybı azaltılır. Güvenlik gereksinimleri doğrultusunda ham IP erişimi sınırlı tutulmalıdır.

Reverse DNS

Reverse DNS bir IP adresinin host adına çözülmesini sağlar. Googlebot doğrulamasında ilk kontrol adımlarından biri olarak kullanılabilir. Elde edilen hostname beklenen Google alanlarıyla eşleşmelidir. Ancak reverse DNS tek başına son kanıt olarak kullanılmamalıdır. Forward DNS ile hostname'in tekrar aynı IP'ye çözüldüğü doğrulanmalıdır.

Forward DNS

Forward DNS reverse DNS sonucunda alınan hostname'in tekrar IP adresine çözülmesini sağlar. Bu iki yönlü kontrol sahte PTR kaydı riskini azaltır. Pipeline doğrulama işlemini otomatikleştirebilir. Başarısız veya timeout olan DNS sorguları unknown statüsünde tutulabilir. SEO raporlarında mümkün olduğunca yalnızca verified requestler kullanılmalıdır.

Doğrulanmış Bot Listesi

Doğrulama sonuçlarından düzenli olarak güncellenen bir bot listesi oluşturulabilir. IP veya ağ bilgisi belirli süreyle cache edilerek tekrar eden sorgular azaltılır. Bot family, verification timestamp ve source gibi alanlar tutulabilir. Bu liste güvenlik ve SEO ekipleri arasında ortak kaynak olabilir. Süre dolduğunda doğrulama yeniden çalıştırılmalıdır.

Log Verisi Analize Nasıl Hazırlanır?

Ham log dosyasını doğrudan grafikleştirmek çoğu zaman güvenilir sonuç üretmez. Önce bot trafiği doğrulanmalı, insan trafiği ayrılmalı, statik kaynaklar segmentlenmeli ve timestamp ile URL formatları normalize edilmelidir. Query parametreleri kontrollü biçimde sınıflandırılmalı ve duplicate event ihtimali kontrol edilmelidir. Büyük sistemlerde parsing aşamasının tekrar üretilebilir olması önemlidir. Data preparation doğru yapılmazsa daha sonraki crawl budget ve error analizleri teknik olarak doğru sorgular kullansa bile yanlış veri üzerinde çalışabilir.

Bot Trafiğini Filtrelemek

Bot filtering user agent ile başlar fakat doğrulama sonucu ile tamamlanmalıdır. Googlebot, Bingbot ve diğer bilinen crawlerlar ayrı family değerleriyle saklanabilir. Sahte veya bilinmeyen botlar farklı segmentte tutulmalıdır. SEO analizi ihtiyaç halinde yalnızca verified search bots üzerinde çalışabilir. Bu ayrım crawl hacmi ve response time metriklerinin güvenilirliğini artırır.

Human Traffic'i Ayırmak

Access loglar kullanıcı ve bot trafiğini birlikte içerebilir. İnsan trafiği bot analizi dışında tutulmazsa request hacimleri yanlış yorumlanır. Bot verification, user agent ve davranışsal kurallar birlikte kullanılabilir. Ancak agresif heuristic filtreler gerçek bot trafiğini yanlışlıkla dışarıda bırakmamalıdır. Analytics verisi bot ve human trafik karşılaştırmasında yardımcı kaynak olabilir.

Statik Kaynakları Segmentlemek

HTML, CSS, JavaScript, image ve API requestleri farklı amaçlarla incelenmelidir. Sayfa crawl analizinde yalnızca HTML benzeri kaynaklar öncelikli olabilir. Rendering araştırmasında JavaScript ve API istekleri de değerlidir. Resource type URL uzantısı, content type veya route bilgisiyle sınıflandırılabilir. Toplam request sayısını yorumlarken kaynak tiplerinin birbirine karıştırılmaması gerekir.

Timestamp Normalizasyonu

Farklı sistemlerde UTC, yerel saat veya farklı tarih formatları kullanılabilir. Tüm kayıtlar ortak zaman standardına dönüştürülmelidir. Analiz katmanında rapor timezone'u ayrıca tanımlanabilir. Deployment işaretleri de aynı timezone'a çevrilmelidir. Bu normalizasyon olmadan saatlik error spike veya before after karşılaştırmaları yanlış yorumlanabilir.

URL Normalizasyonu

URL normalizasyonu aynı mantıksal adresin farklı yazımlarla ayrı satırlarda görünmesini engeller. Protocol, host case, trailing slash ve bazı query parametreleri için açık kurallar belirlenmelidir. Ancak canonical mantığıyla log URL'sini kör biçimde değiştirmek doğru değildir. Raw URL her zaman korunmalıdır. Normalize URL analiz için ek bir türetilmiş alan olarak oluşturulmalıdır.

Query Parameter Normalizasyonu

Query parametreleri büyük URL patlamalarının önemli kaynağıdır. Parametre sırası değişse bile aynı mantıksal sayfa oluşabilir. Tracking parametreleri analizden kaldırılabilir, ancak facet veya pagination parametreleri ayrı segmentte tutulmalıdır. Parametre türleri SEO amacıyla sınıflandırılmalıdır. Böylece crawl waste analizi daha anlamlı hale gelir.

Duplicate Event Kontrolü

Aynı request CDN, load balancer ve origin loglarında ayrı kayıt olarak bulunabilir. Bu kayıtlar doğrudan birleştirilirse tek istek birkaç kez sayılabilir. Request ID varsa deduplication için kullanılabilir. Yoksa zaman, URL, IP ve diğer alanlarla kontrollü eşleştirme yapılabilir. Authoritative request layer tanımlamak çoğu durumda daha güvenli çözümdür.

URL Space Nedir ve Neden Tek Tek URL'lerden Daha Faydalıdır?

URL space, benzer işlev, template veya pattern taşıyan URL gruplarını ifade eder. Milyonlarca URL bulunan sitede tek tek adresleri incelemek yerine /product/, /category/, /blog/ veya ?filter= gibi alanları segmentlemek daha ölçeklenebilir sonuç verir. Bu yaklaşım Googlebot'un tarama kapasitesini hangi site bölgelerine ayırdığını anlamayı sağlar. Aynı zamanda 404, 5xx, response time ve crawl freshness metrikleri segment bazında karşılaştırılabilir. Log analizinin gerçek kurumsal değeri çoğu zaman tek sorunlu URL bulmaktan değil bütün bir URL ailesinin davranışını ortaya çıkarmaktan gelir.

Directory Bazlı Segmentasyon

Directory yapısı URL space sınıflandırmasının en basit yollarından biridir. /product/, /category/ ve /blog/ gibi dizinler farklı iş değeri ve teknik davranış gösterebilir. Request share ve unique URL sayıları bu segmentler üzerinden karşılaştırılabilir. Ancak modern sistemlerde route yapısı her zaman işlevi tam temsil etmeyebilir. Bu nedenle directory kuralı gerektiğinde template veya metadata bilgisiyle güçlendirilmelidir.

/product/

/product/ alanı ürün detay sayfalarını temsil ediyorsa crawl freshness ve status dağılımı açısından ayrı izlenebilir. Stok ve fiyat değişimi hızlı olan projelerde son crawl tarihi önemli hale gelir. 404 veya redirect oranı migration sonrası artabilir. Ürün trafiği ve revenue bilgisi eklenerek iş değeri bazlı öncelik oluşturulabilir. Böylece Googlebot request payının stratejik ürün sayfalarına yeterince gidip gitmediği ölçülebilir.

/category/

Kategori sayfaları ürün keşfi ve internal linking açısından önemli olabilir. Crawl frequency, response time ve status code dağılımı ayrı takip edilmelidir. Faceted navigation URL'leri kategori alanıyla karışıyorsa parametre segmentasyonu eklenmelidir. Kategori sayfalarının sitemap ve internal crawl durumu da log verisiyle karşılaştırılabilir. Yüksek iş değerli kategori alanlarında priority crawl share hedefi oluşturulabilir.

/blog/

Blog veya içerik alanları farklı freshness ihtiyacına sahip olabilir. Yeni yayınların ilk crawl süresi ve eski evergreen içeriklerin yeniden tarama aralıkları ölçülebilir. Çok sayıda tag veya archive sayfası varsa düşük değerli crawl alanları ayrıca segmentlenmelidir. Organik trafik verisiyle birlikte kullanıldığında hangi içeriklerin daha stratejik olduğu anlaşılır. Sadece crawl sayısını artırmak yerine güncel ve önemli içeriklerin sağlıklı keşfedilmesi hedeflenmelidir.

Pattern Bazlı Segmentasyon

URL path yapısı yeterli olmadığında query patternleri güçlü segmentasyon sağlar. ?filter=, ?sort=, ?page= ve ?search= gibi parametreler farklı tarama davranışlarını temsil eder. Regex veya SQL pattern kurallarıyla bu gruplar otomatik sınıflandırılabilir. Aynı URL birden fazla parametre taşıyorsa öncelik veya çoklu etiket modeli kullanılabilir. Pattern bazlı analiz crawl waste ve faceted navigation problemlerini görünür hale getirir.

?filter=

Filter parametreleri çok büyük kombinasyonlar üretebilir. Googlebot bu alanı yoğun tarıyorsa gerçek ürün veya kategori sayfalarının crawl payı azalabilir. Her filtre URL'si düşük değerli değildir, bu nedenle business ve search demand değerlendirmesi yapılmalıdır. Loglarda unique filter URL ve request hacmi birlikte izlenebilir. Robots, internal link ve canonical stratejileri kontrollü olarak planlanmalıdır.

?sort=

Sort parametreleri çoğu zaman aynı ürün setinin farklı sıralamasını üretir. Çok sayıda sort varyantının taranması düşük değerli crawl alanı oluşturabilir. Loglarda sort request share ve trendi izlenmelidir. Internal link veya frontend component bu URL'leri yoğun biçimde üretiyor olabilir. Sorunun kaynağı belirlendikten sonra uygun teknik kontrol uygulanmalıdır.

?page=

Pagination parametreleri içerik keşfi için gerekli olabilir ve otomatik olarak waste kabul edilmemelidir. Hangi sayfa derinliklerinin ne sıklıkta tarandığı analiz edilebilir. Çok derin pagination alanlarında düşük değerli crawl yoğunluğu görülebilir. Internal architecture ve ürün keşfi ihtiyacı birlikte değerlendirilmelidir. URL pattern analizi sayesinde pagination ile diğer parametrelerin etkisi ayrıştırılır.

?search=

Internal search URL'leri kullanıcıların site içinde arama yapması için oluşturulur. Bu sayfaların büyük bölümü arama motoru crawlerı için düşük değerli olabilir. Googlebot requestleri search query patterni üzerinden izlenebilir. Internal link, sitemap veya dış link kaynaklı discovery ihtimali araştırılmalıdır. Robots ve indexleme stratejileri birbirinden ayrı amaçlarla değerlendirilmelidir.

Template Bazlı Segmentasyon

Template segmentasyonu path yapısının ötesine geçer ve aynı sayfa bileşimiyle çalışan URL'leri gruplayabilir. Product detail, category, article, search result ve campaign gibi template ID değerleri log datasetine eklenebilir. Bu bilgi uygulama route metadata'sından veya crawler exportundan gelebilir. Status, response time ve crawl frequency template bazında karşılaştırıldığında ortak kök nedenler daha kolay bulunur. Büyük kurumsal sitelerde URL space yaklaşımının en güçlü biçimlerinden biri template sınıflandırmasıdır.

Googlebot Crawl Frequency Nasıl Ölçülür?

Crawl frequency belirli URL veya URL grubunun Googlebot tarafından ne sıklıkta ziyaret edildiğini ifade eder. Tek başına toplam hit sayısı yeterli değildir çünkü aynı URL'nin yüz kez taranması ile yüz farklı URL'nin bir kez taranması farklı davranışlardır. Bu nedenle crawl hit, unique crawled URL, last crawl date ve ortalama crawl aralığı gibi metrikler birlikte kullanılmalıdır. Template veya business priority segmenti eklenirse analiz daha anlamlı hale gelir. Amaç mümkün olan en yüksek crawl sayısını elde etmek değil önemli içeriklerin ihtiyaca uygun tazelikte taranıp taranmadığını anlamaktır.

Crawl Hit Sayısı

Crawl hit sayısı belirli dönem içindeki doğrulanmış Googlebot requestlerini toplar. Günlük, haftalık veya aylık trend olarak izlenebilir. Ani artış parameter crawl spike veya site değişikliği nedeniyle oluşabilir. Ani düşüş ise erişim, crawl demand veya altyapı problemi açısından incelenmelidir. Toplam hit sayısı URL space dağılımıyla birlikte yorumlanmalıdır.

Unique Crawled URL

Unique crawled URL metriği belirli dönemde kaç farklı URL'nin tarandığını gösterir. Toplam hit ile birlikte incelendiğinde crawlerın aynı URL'leri tekrar mı ziyaret ettiği yoksa geniş URL alanına mı yayıldığı anlaşılır. Normalize ve raw URL tanımları burada açık olmalıdır. Parameter explosion unique sayılarını yapay biçimde büyütebilir. Bu nedenle URL classification metriğin doğru yorumlanması için gereklidir.

Last Crawl Date

Last crawl date belirli URL'nin en son ne zaman doğrulanmış Googlebot isteği aldığını gösterir. Kritik landing page'ler ve güncel içerikler için önemlidir. Days since last crawl türetilerek freshness metriği oluşturulabilir. Çok eski tarih tek başına problem değildir, sayfanın değişim sıklığı ve iş değeri dikkate alınmalıdır. Yeni içerikte uzun discovery gecikmesi varsa sitemap ve internal link yapısı ayrıca incelenmelidir.

Ortalama Crawl Aralığı

Ortalama crawl aralığı aynı URL'ye gelen iki Googlebot isteği arasındaki süreyi hesaplar. Median kullanmak aşırı değerlerin etkisini azaltabilir. Ürün, kategori ve haber template'leri farklı doğal aralıklara sahip olabilir. Bu nedenle site genelinde tek bir hedef belirlemek doğru değildir. Template ve update frequency ile birlikte kullanıldığında daha anlamlı freshness standardı oluşturulabilir.

URL Template Bazında Crawl Frequency

Template bazlı frequency, binlerce URL'yi tek tek incelemek yerine davranış kümelerini karşılaştırmayı sağlar. Örneğin product detail sayfaları ortalama üç günde bir taranırken category sayfaları günlük ziyaret edilebilir. Düşük değerli filter alanı kritik template'lerden daha yüksek request alıyorsa allocation problemi düşünülebilir. İş değeri ve güncelleme sıklığı tabloya eklenmelidir. Böylece crawl frequency yalnızca teknik sayı değil stratejik bir ölçüye dönüşür.

Crawl Freshness Nedir?

Crawl freshness, önemli URL'lerin en son ne zaman crawler tarafından ziyaret edildiğini ve içerik değişikliklerinin ne kadar hızlı yeniden tarandığını anlamaya yönelik yaklaşımdır. Her sayfanın günlük taranması gerekmez. Güncel stok, fiyat, haber veya kritik landing page gibi hızlı değişen içeriklerde kısa crawl aralığı daha değerli olabilir. Evergreen sayfalarda daha uzun aralık normal kabul edilebilir. Bu nedenle freshness hedefleri URL template ve iş ihtiyacına göre tanımlanmalıdır.

Days Since Last Crawl

Days since last crawl bugünün tarihi ile son doğrulanmış bot isteği arasındaki farkı gösterir. Dashboardda dağılım veya percentile olarak sunulabilir. Priority URL'ler için üst sınır tanımlanması mümkündür. Örneğin yüksek değerli ürün sayfalarının büyük bölümü son yedi gün içinde taranmış mı sorusu izlenebilir. Hedefler site türüne göre değişmelidir.

Güncel İçerik Sayfaları

Güncel içerik sayfaları yayın veya güncelleme zamanı ile crawl zamanı arasındaki gecikme açısından incelenebilir. Yeni içerik discovery süresi teknik SEO kalitesi hakkında önemli sinyal verir. Sitemap lastmod ve internal link değişiklikleri bu analizle karşılaştırılabilir. Güncel içerikler düzenli olarak geç taranıyorsa site mimarisi gözden geçirilmelidir. Arama talebi ve içerik değeri de önceliklendirmeye eklenmelidir.

Ürün ve Stok Sayfaları

Stok ve fiyatı sık değişen ürün sayfalarında freshness iş açısından önemlidir. Loglar Googlebot'un son ziyaret zamanını gösterirken ürün veritabanı son değişiklik zamanını sağlayabilir. İki veri birleştirildiğinde update to crawl delay hesaplanabilir. Büyük kataloglarda tüm ürünler aynı öncelikte olmayabilir. Revenue ve availability gibi iş alanlarıyla segmentasyon yapılması daha anlamlıdır.

Haber Siteleri

Haber sitelerinde yeni içeriklerin hızlı keşfi önemli olabilir. Yayın timestamp ile ilk doğrulanmış Googlebot crawl arasındaki süre ölçülebilir. Site bölümü veya editoryal kategori bazında farklar analiz edilebilir. Sitemap, internal link ve ana sayfa görünürlüğüyle korelasyon kurulabilir. Uzun süreli trendler altyapı veya site mimarisi değişikliklerinin etkisini gösterebilir.

Kritik Landing Page'ler

Kritik landing page'ler yüksek organik trafik veya dönüşüm değeri taşıyan sayfalardır. Bu URL'lerin crawl freshness değeri ayrı KPI olarak izlenebilir. Uzun süre yeniden taranmayan sayfalarda iç bağlantı ve sitemap durumu kontrol edilebilir. Sayfa içerik olarak nadiren değişiyorsa düşük frequency her zaman sorun değildir. İş değeri ve update ihtiyacı birlikte yorumlanmalıdır.

HTTP Status Code'lar Log Analizinde Nasıl Yorumlanır?

HTTP status code dağılımı teknik SEO log analizinin temel parçalarından biridir. Ancak her status code'un anlamı URL'nin bağlamına göre değerlendirilmelidir. Sürekli taranan 404 ile yıllar önce kaldırılmış ve bir kez ziyaret edilmiş 404 aynı öncelikte değildir. Benzer şekilde 3xx yönlendirmeler migration döneminde normal olabilirken kalıcı internal link kaynağı haline gelirse temizlenmesi gerekebilir. Teknik SEO log analizinde bot trafiği 404 hataları ve yönlendirmeler nasıl incelenir sorusunun yanıtı frekans, kaynak ve iş değerini birlikte değerlendirmektir.

200

200 status code isteğin başarıyla yanıtlandığını gösterir. Ancak 200 alan her URL SEO açısından değerli veya indekslenebilir değildir. Soft 404 benzeri durumlar, düşük kaliteli parameter sayfaları veya noindex sayfaları yine 200 dönebilir. Bu yüzden 200 rate yalnızca erişim sağlığı göstergesidir. Sitemap, indexability ve business value bilgileriyle birlikte değerlendirilmelidir.

3xx

3xx status code yönlendirme davranışını gösterir. Migration veya URL değişikliğinde beklenen olabilir. Ancak Googlebot sürekli eski URL'leri tarıyor ve her seferinde redirect alıyorsa kaynak keşfi incelenmelidir. Internal link, sitemap veya dış kaynaklar eski adresi canlı tutuyor olabilir. 3xx oranı ve redirect target log veya crawler verisiyle birlikte analiz edilmelidir.

redirect chain

Redirect chain bir URL'nin nihai sayfaya ulaşmadan önce birden fazla yönlendirmeden geçmesidir. Loglarda aynı bot oturumunun her adımını her zaman doğrudan ilişkilendirmek kolay olmayabilir. Crawler verisi redirect zincirini çıkarmak için kullanılabilir. Loglar ise Googlebot'un zincirin hangi eski kaynaklarını hâlâ ziyaret ettiğini gösterir. Internal link ve sitemap doğrudan final URL'ye güncellenmelidir.

loop

Redirect loop URL'nin yönlendirmeler arasında döngüye girmesidir ve erişimi bozar. Crawler testleri loopu hızlı bulabilir, loglar ise gerçek Googlebot isteklerinin bu döngüden etkilenip etkilenmediğini gösterir. Status trendinde artış veya tekrar eden aynı URL patternleri görülebilir. Sorun routing veya uygulama kuralından kaynaklanabilir. Düzeltme sonrası bot requestleri loglarla tekrar doğrulanmalıdır.

404

404 istenen kaynağın bulunamadığını gösterir. Tüm 404'leri otomatik olarak kritik hata kabul etmek doğru değildir. Sürekli taranan, sitemap'te bulunan veya internal link alan 404'ler daha yüksek öncelik taşır. Backlink alan eski URL'ler de ayrıca değerlendirilebilir. Age ve crawl frequency birlikte kullanıldığında 404 backlog daha sağlıklı sıralanır.

410

410 kaynağın bilinçli olarak kaldırıldığını belirtmek için kullanılabilir. Kullanımı site stratejisi ve kaldırma politikasına göre değerlendirilmelidir. Loglarda 410 alan URL'lerin tarama sıklığının zaman içinde nasıl değiştiği izlenebilir. Ancak her eski URL'yi 410 yapmak otomatik çözüm değildir. Internal link ve sitemap temizliği yine yapılmalıdır.

429

429 fazla istek nedeniyle rate limit uygulandığını gösterir. Doğrulanmış Googlebot requestlerinde artış görülüyorsa altyapı kapasitesi ve güvenlik kuralları kontrol edilmelidir. Zaman bazlı spike ve URL space dağılımı incelenebilir. CDN ile origin logları karşılaştırılarak hangi katmanın 429 ürettiği bulunmalıdır. Düzeltme sonrası success rate ile response time yeniden ölçülmelidir.

500/502/503/504

5xx ailesi sunucu veya upstream tarafındaki problemleri gösterir. Googlebot'a yoğun biçimde 5xx sunulması crawl reliability açısından önemlidir. Hata oranı site geneli ve template bazında hesaplanmalıdır. Deployment, trafik ve backend health verisiyle korelasyon kurulabilir. CDN ile origin response kodları karşılaştırılarak hata kaynağı ayrıştırılmalıdır.

Timeout

Timeout bazı log sistemlerinde status code yerine özel hata alanı olarak görünebilir. Bot requestlerinin tamamlanamaması crawl deneyimini bozar. P95 ve p99 response time artışı timeout öncesi uyarı sinyali olabilir. URL ve upstream service bazında segmentasyon kök nedeni bulmayı kolaylaştırır. Incident düzeltildikten sonra kritik URL crawl davranışı tekrar izlenmelidir.

Googlebot'a Sunulan 5xx Hataları Nasıl Analiz Edilir?

5xx analizi yalnızca toplam hata sayısına bakılarak yapılmamalıdır. Toplam doğrulanmış Googlebot requestleri içinde 5xx oranı, etkilenen URL template, zaman spike'ları ve deployment bilgisi birlikte değerlendirilmelidir. CDN ile origin kodu farklıysa hata katmanı ayrıca belirlenmelidir. Kritik landing page veya sitemap URL'lerindeki 5xx sorunları daha yüksek öncelik alabilir. Sürekli monitoring sistemi threshold aşıldığında ilgili engineering owner'a otomatik uyarı gönderebilir.

Toplam 5xx Oranı

Toplam 5xx oranı 5xx request sayısının toplam doğrulanmış bot isteklerine bölünmesiyle hesaplanabilir. Günlük trend kısa süreli spike'ları gösterir. Tek başına oran URL önemini hesaba katmaz. Bu nedenle priority pages için ayrı success rate hesaplanabilir. SLO sistemi site genelinden daha sıkı kritik URL hedefleri kullanabilir.

URL Template Bazında 5xx

Template segmentasyonu hatanın bütün siteye mi yoksa belirli uygulama alanına mı ait olduğunu gösterir. Örneğin yalnız product detail sayfalarında 503 görülmesi belirli backend servisini işaret edebilir. Category veya blog template'leri sağlıklı kalabilir. Bu ayrım incident triage süresini kısaltır. Template owner bilgisi dashboarda eklenirse sorumluluk doğrudan yönlendirilebilir.

Zaman Bazlı Spike

5xx spike'ın başladığı dakika veya saat deployment, altyapı değişikliği veya trafik olayıyla karşılaştırılabilir. Zaman serisi grafiğinde baseline dışına çıkan değerler otomatik algılanabilir. Ani kısa spike ile saatler süren sürekli hata farklı severity seviyelerinde değerlendirilebilir. Alert fatigue önlemek için minimum duration veya request threshold kullanılabilir. Olay sonrasında timeline postmortem için saklanmalıdır.

Deployment ile Korelasyon

Deploy timestamp dashboard üzerine işaretlenirse hata değişimini görmek kolaylaşır. Yeni sürümden hemen sonra belirli template'te 5xx artıyorsa release regresyonu ihtimali güçlenir. Release ID log veya RUM verisine eklenebiliyorsa analiz daha kesin olur. Gerekirse rollback kararı hızlı alınabilir. Düzeltme sonrası loglarla success rate'in normale döndüğü doğrulanmalıdır.

CDN mi Origin mi?

Kullanıcıya veya bota görünen 5xx her zaman origin uygulamasından kaynaklanmayabilir. CDN bağlantı problemi, WAF veya load balancer da hata üretebilir. Edge status, upstream status ve origin logları karşılaştırılmalıdır. Böylece doğru ekip aksiyon alır. Katman ayrımı olmadan yapılan incident yönetimi gereksiz zaman kaybettirebilir.

404 Hataları Nasıl Önceliklendirilmelidir?

404 listesi tek başına aksiyon planı değildir. Öncelik belirlemek için URL'nin ne kadar sık tarandığı, ne kadar süredir 404 olduğu ve crawlerın URL'yi hangi kaynaktan keşfediyor olabileceği incelenmelidir. Sitemap veya internal link kaynaklı 404 genellikle sistem tarafından üretilen bir kalite problemidir. Backlink alan eski URL'de doğru redirect fırsatı bulunabilir. Tek sefer taranmış ve artık hiçbir sistemde referansı olmayan eski URL ise düşük öncelikte kalabilir.

Tek Sefer Taralanan Eski URL

Yıllar önce kaldırılmış bir URL'nin tek kez tekrar taranması büyük alarm gerektirmeyebilir. Arama motorları geçmiş keşiflerden kalan adresleri zaman zaman yeniden ziyaret edebilir. URL sitemap veya internal link içinde değilse düşük öncelik verilebilir. Backlink değeri ayrıca kontrol edilmelidir. Kaynağın sürekli tekrar taranıp taranmadığı zaman içinde izlenebilir.

Sürekli Taralanan 404

Aynı 404 URL'nin düzenli biçimde Googlebot tarafından ziyaret edilmesi keşif kaynağının hâlâ aktif olabileceğini gösterir. Internal link, sitemap, canonical veya external link kaynakları araştırılmalıdır. Log frequency ve crawler verisi birlikte kullanılabilir. Uygun yeni karşılık varsa yönlendirme düşünülebilir. Alakasız sayfaya toplu redirect yapılması yerine kullanıcı niyeti korunmalıdır.

Sitemap Kaynaklı 404

Sitemap içinde 404 dönen URL bulunması bakım problemi olduğunu gösterir. Sitemap yalnız geçerli ve stratejik URL'leri içermelidir. Log verisi bu URL'lerin gerçekten bot tarafından tarandığını gösterebilir. Sitemap generation pipeline düzeltilmelidir. Düzeltme sonrasında yeni sitemap ve crawler davranışı doğrulanmalıdır.

Internal Link Kaynaklı 404

Internal link üzerinden erişilen 404 hem kullanıcı hem crawler açısından kalite sorunudur. SEO crawler link kaynağını bulmak için kullanılabilir. Loglar ise Googlebot'un bu kırık adresi ne kadar sık ziyaret ettiğini gösterir. Kaynak link doğrudan doğru URL'ye güncellenmelidir. Sadece redirect eklemek internal mimarideki hatayı tamamen çözmez.

Backlink Kaynaklı 404

Dış sitelerden link alan eski URL'ler Googlebot tarafından uzun süre keşfedilmeye devam edebilir. Backlink değeri ve yeni içerik karşılığı birlikte değerlendirilmelidir. Uygun eşleşme varsa kalıcı redirect faydalı olabilir. Alakasız sayfaya yönlendirme kullanıcı deneyimini bozabilir. Log frequency bu URL'lerin hâlâ aktif crawler talebi alıp almadığını gösterir.

404 Age ve Frequency

404 age hatanın ne kadar süredir var olduğunu, frequency ise ne kadar sık tarandığını gösterir. Bu iki metriği birleştirmek basit ama etkili öncelik modeli oluşturur. Yeni ve yoğun taranan 404 yüksek öncelik alabilir. Eski ve çok seyrek taranan URL düşük öncelikte kalabilir. Business value ve source type eklenirse model daha da güçlenir.

Redirect Sorunları Loglarla Nasıl Bulunur?

Loglar Googlebot'un hâlâ hangi eski URL'lere istek gönderdiğini göstererek redirect temizliği için önemli veri sağlar. Migration sonrasında eski URL requestlerinin zaman içinde azalması beklenebilir, ancak internal link veya sitemap eski adresleri kullanıyorsa tarama devam eder. Redirect chain veya loop tespiti crawler ile daha kolay yapılırken loglar bu yapıların gerçek bot trafiğinde ne kadar kullanıldığını gösterir. Geçici ve kalıcı yönlendirmelerin amacı ayrıca doğrulanmalıdır. Log ve crawler verisini birlikte kullanmak redirect backlogunun gerçek etkiye göre sıralanmasını sağlar.

Googlebot'un Hâlâ Eski URL'yi Taradığı Durumlar

Eski URL'ye düzenli bot isteği geliyorsa kaynağın hâlâ keşfedilebilir olduğu düşünülebilir. Internal link, sitemap, canonical ve external link kontrol edilmelidir. Migration sonrasında bu isteklerin doğal biçimde bir süre devam etmesi mümkündür. Ancak aylar sonra yüksek request payı sürüyorsa teknik kaynak araştırılmalıdır. Final URL'ye doğrudan bağlantı verilmesi crawl yolunu sadeleştirebilir.

Redirect Chain

Redirect chain birden fazla yönlendirme adımı içerir. Internal linklerin zincirin ilk halkasına gitmesi gereksiz crawl ve kullanıcı gecikmesi oluşturabilir. Crawler final target ve chain length bilgisini çıkarabilir. Loglar hangi eski kaynakların Googlebot tarafından hâlâ ziyaret edildiğini gösterir. En çok request alan zincirler önce temizlenebilir.

Redirect Loop

Redirect loop erişimi engellediği için yüksek öncelikli teknik problemdir. Crawler testi loop adreslerini tespit edebilir. Loglarda tekrar eden yönlendirme patterni ve hata davranışı görülebilir. Routing veya uygulama kuralları kontrol edilmelidir. Fix sonrasında doğrulanmış bot requestlerinin final 200 URL'ye ulaştığı izlenmelidir.

Geçici vs Kalıcı Redirect

Yönlendirme türü değişikliğin geçici veya kalıcı niteliğine göre seçilmelidir. Loglar hangi status code'un gerçekte botlara sunulduğunu doğrular. Konfigürasyonda 301 planlanmışken CDN veya uygulama katmanı farklı yanıt verebilir. Migration sonrası status dağılımı izlenmelidir. Teknik kararın arama motoru crawlerına gerçekten uygulandığından emin olunmalıdır.

Migration Sonrası Redirect İzleme

Migration sonrasında eski URL requestleri, redirect status ve yeni URL discovery birlikte takip edilmelidir. 404 ve 5xx spike hızlıca görülmelidir. Kritik eski URL'lerin yeni karşılıkları düzenli kontrol edilmelidir. Zaman içinde eski URL crawl share azalırken yeni site bölümünün frequency değeri artabilir. Bu eğilim migration doğrulamasında değerli bir teknik sinyaldir.

Crawl Budget Waste Nasıl Hesaplanır?

Crawl budget waste, doğrulanmış bot requestlerinin düşük değerli veya stratejik olarak istenmeyen URL alanlarına ayrılan bölümünü ölçmeye yönelik bir yaklaşımdır. Burada en önemli adım waste tanımının iş ve SEO ekipleri tarafından açıkça belirlenmesidir. Parameter, faceted navigation, internal search, duplicate URL ve eski redirect kaynakları aday olabilir. Ancak her parametre veya redirect otomatik olarak waste değildir. Amaç crawler request sayısını yapay biçimde düşürmek değil stratejik URL alanlarının sağlıklı pay almasını sağlamaktır.

Düşük Değerli URL'ler

Düşük değerli URL tanımı siteye göre değişir. Arama talebi olmayan, duplicate içerik üreten veya kullanıcı yolculuğunda anlamlı rol taşımayan URL alanları bu gruba girebilir. Analytics ve Search Console verisi değerlendirmeye yardımcı olur. Bot request share ile business value birlikte analiz edilmelidir. Böylece yalnız teknik bakışla değerli sayfaların yanlışlıkla engellenmesi önlenir.

Parameter URL'leri

Parameter URL'leri tracking, filter, sort veya session amacıyla üretilebilir. Her parametre türünün SEO etkisi farklıdır. Loglarda parametre patternleri sınıflandırılarak request hacmi hesaplanabilir. Düşük değerli alanlar internal link veya robots kontrolü açısından incelenebilir. Canonical ve indexing stratejisi crawling kontrolüyle karıştırılmamalıdır.

Faceted Navigation

Faceted navigation çok sayıda filtre kombinasyonu üretebilir. Renk, beden, fiyat ve marka kombinasyonları teorik olarak milyonlarca URL oluşturabilir. Arama talebi olan facet sayfaları değerli olabilirken diğer kombinasyonlar düşük değerli crawl alanı yaratabilir. Loglarda facet depth ve parameter combination sayısı ölçülebilir. Teknik kontrol kararları SEO talebi ve kullanıcı değeriyle birlikte verilmelidir.

Internal Search

Internal search sayfaları kullanıcı için faydalı olabilir ancak crawler açısından kontrolsüz URL alanı oluşturabilir. Search query parametrelerinin Googlebot request payı izlenmelidir. Internal link veya sitemap kaynaklı discovery varsa düzeltilmelidir. Robots stratejisi indexing kararından ayrı ele alınmalıdır. İşlevi korurken crawler erişimi kontrollü yönetilebilir.

Duplicate URL'ler

Aynı içeriğe birden fazla URL üzerinden erişim duplicate crawl alanı oluşturabilir. Case, trailing slash, tracking parameter veya route varyasyonu buna neden olabilir. URL normalization ve canonical analizi birlikte yapılmalıdır. Loglarda duplicate family request share hesaplanabilir. Uygun redirect ve internal link standardı sorunu azaltabilir.

Eski URL'ler

Migration veya geçmiş site yapısından kalan eski URL'ler uzun süre taranabilir. Request trendi zaman içinde izlenmelidir. Internal ve external discovery kaynakları araştırılabilir. Doğru redirect varsa crawl zamanla yeni URL'lere kayabilir. Eski URL payının sürekli yüksek kalması mimaride veya link kaynaklarında temizlik ihtiyacına işaret edebilir.

Redirect Kaynakları

Googlebot'un sürekli redirect kaynaklarını ziyaret etmesi gereksiz ara adım oluşturabilir. Özellikle internal link veya sitemap redirect URL'yi gösteriyorsa doğrudan final URL'ye güncelleme yapılmalıdır. Loglarda 3xx request share ve en sık taranan redirect source listesi çıkarılabilir. Crawler redirect target bilgisini tamamlar. Yüksek hacimli kaynaklar öncelikli temizlenebilir.

Crawl Waste Rate Nasıl Hesaplanır?

Crawl Waste Rate basit biçimde waste olarak tanımlanan doğrulanmış bot requestlerinin toplam doğrulanmış bot requestlerine oranı olarak hesaplanabilir. Ancak formülden daha önemli konu waste segmentlerinin doğru tanımlanmasıdır. İş değeri taşıyan facet veya pagination URL'sini yanlışlıkla waste kabul etmek hatalı karar üretir. Bu nedenle segment tanımı SEO, product ve analytics verisiyle doğrulanmalıdır. Rate trendi zaman içinde izlenerek robots, internal link veya URL mimarisi değişikliklerinin etkisi ölçülebilir.

Waste URL Segmentlerinin Tanımlanması

İlk adım düşük değerli URL gruplarının açık kurallarla belirlenmesidir. ?sort=, belirli filter kombinasyonları veya eski redirect alanları örnek olabilir. Her kural dokümante edilmelidir. Business exception listesi ayrı tutulabilir. Böylece hesaplama tekrarlanabilir hale gelir.

Toplam Doğrulanmış Googlebot Request

Payda yalnız doğrulanmış ilgili Googlebot requestlerini içermelidir. Sahte bot veya human trafik metriği bozar. Resource requestleri dahil edilip edilmeyeceği önceden tanımlanmalıdır. Çoğu crawl allocation analizinde HTML URL requestleri ayrı ele alınır. Veri tanımı dashboard dokümantasyonunda açıkça belirtilmelidir.

Waste Request Sayısı

Waste request sayısı tanımlanan URL segmentlerine düşen doğrulanmış bot isteklerinin toplamıdır. Segmentler birbiriyle çakışıyorsa duplicate sayım önlenmelidir. Öncelik kuralı veya primary classification alanı kullanılabilir. Her waste kategorisinin ayrı payı da gösterilebilir. Böylece toplam oranın hangi URL ailesinden kaynaklandığı anlaşılır.

Trend Takibi

Crawl Waste Rate tek bir günlük değer yerine zaman serisi olarak izlenmelidir. Robots veya internal linking değişikliğinden sonra trendin yönü değerlendirilebilir. Mevsimsel veya bot davranışındaki doğal değişimler kısa dönem dalgalanma oluşturabilir. En az birkaç haftalık baseline yorum kalitesini artırır. Aynı grafikte priority crawl share göstermek daha dengeli bir görünüm sağlar.

Faceted Navigation Crawl Budget'ı Nasıl Etkiler?

Faceted navigation kullanıcıların ürün veya içerik listelerini filtrelemesini sağlar fakat URL üretimi kontrolsüz olduğunda çok geniş crawl alanı oluşturabilir. Tek bir renk filtresi sınırlı URL üretirken renk, beden, fiyat ve sıralama kombinasyonları geometrik biçimde büyüyebilir. Googlebot bu kombinasyonları internal linklerden keşfediyorsa request hacminin önemli bölümü düşük değerli varyantlara gidebilir. Log analizi facet patternlerinin gerçek crawl payını ölçmeyi sağlar. Teknik karar verilmeden önce hangi filtre kombinasyonlarının arama talebi ve ticari değer taşıdığı belirlenmelidir.

Renk Filtreleri

Renk filtreleri bazı e-ticaret sorgularında arama talebi taşıyabilir. Bu nedenle tüm renk URL'lerini otomatik olarak engellemek doğru olmayabilir. Log frequency, Search Console impression ve landing page conversion birlikte değerlendirilebilir. Değerli renk facetleri stratejik URL olarak tutulabilir. Düşük değerli kombinasyonlar farklı kurallarla yönetilebilir.

Boyut Filtreleri

Boyut filtreleri ürün türüne bağlı olarak kullanıcı açısından önemli olabilir. Ancak çok sayıda boyut kombinasyonu duplicate veya düşük değerli sayfa oluşturabilir. Googlebot'un boyut parametrelerine ayırdığı request payı ölçülmelidir. Internal link generation kontrol edilmelidir. SEO talebi olmayan kombinasyonlar crawl stratejisi açısından ayrıca değerlendirilebilir.

Fiyat

Fiyat filtreleri sonsuz veya çok geniş değer aralıkları üretebilir. Kullanıcının serbest aralık seçtiği sistemlerde URL space hızla büyüyebilir. Loglarda price parameter varyasyon sayısı ve request hacmi izlenebilir. Arama talebi olan sabit fiyat kategorileri ayrı tutulabilir. Crawl kontrolü ürün deneyimini bozmadan planlanmalıdır.

Sort

Sort seçenekleri genellikle aynı ürün setinin farklı sıralamasını sunar. Bu nedenle çoğu durumda arama motoru için ayrı değer üretmeyebilir. Loglarda sort parametrelerinin yoğun taranması düşük değerli allocation göstergesi olabilir. Internal links veya client side navigation bu URL'leri crawlera açıyor olabilir. Teknik çözüm mimariye göre belirlenmelidir.

Çoklu Filtre Kombinasyonları

Asıl URL patlaması birden fazla facet aynı anda kullanılınca ortaya çıkar. Renk, beden ve fiyat üçlüsü bile binlerce varyasyon üretebilir. Loglarda parameter count ve combination pattern sınıflandırması yapılabilir. Üç veya daha fazla facet içeren URL'lerin request payı ayrı ölçülebilir. Böylece crawlerın URL derinliğinde nasıl dağıldığı netleşir.

Loglarda Facet Pattern Analizi

Facet pattern analizi raw URL ve query parametrelerini sınıflandırarak yapılır. Regex, SQL veya Python kurallarıyla parameter family çıkarılabilir. Unique URL, request count ve last crawl date her facet grubu için hesaplanabilir. Search Console ve revenue verisi eklendiğinde iş değeri görünür olur. Böylece crawl optimizasyonu sadece teknik URL sayısına göre değil gerçek değere göre planlanır.

Internal Search URL'leri Loglarda Nasıl İzlenir?

Internal search URL'leri çoğu sitede kullanıcı deneyiminin parçasıdır fakat arama motoru crawlerı için sınırsız URL alanı oluşturabilir. Loglarda search query parametresi veya route patterni ile bu istekler ayrı segmentlenebilir. Googlebot'un ne kadar request ayırdığı, hangi sorgu URL'lerini tekrar ziyaret ettiği ve bu adreslerin nereden keşfedildiği araştırılmalıdır. Internal link veya sitemap yanlışlığı varsa düzeltilmelidir. Robots stratejisi uygulanacaksa bunun indexing ile aynı şey olmadığı açık biçimde anlaşılmalıdır.

Search Query URL Pattern

Önce internal search URL formatı tanımlanmalıdır. /search/, ?q= veya ?search= gibi patternler örnek olabilir. Parameter değerleri kişisel veri içerebileceği için güvenli veri işleme uygulanmalıdır. Query metnini saklamak yerine hash veya kategori kullanılabilir. SEO analizi çoğu zaman pattern ve request hacmiyle yapılabilir.

Crawl Kaynağının Belirlenmesi

Googlebot'un search URL'lerini nasıl keşfettiği araştırılmalıdır. Internal link, sitemap, external link veya geçmiş crawl kaynakları olabilir. SEO crawler internal link kaynaklarını gösterebilir. Loglar URL'nin gerçek crawl frequency'sini sağlar. Kaynak bulunmadan yalnız robots değişikliği yapmak sorunun kök nedenini çözmeyebilir.

Internal Link Kontrolü

Arama sonuçlarının linkleri yanlışlıkla HTML içinde crawlera açık biçimde üretilebilir. Header, autocomplete veya popüler arama bileşenleri search URL'lerine internal link oluşturabilir. Crawler ile link source tespit edilebilir. Gereksiz keşif noktaları kaldırılmalıdır. Kullanıcı işlevi korunurken arama motoru için kontrolsüz URL üretimi azaltılabilir.

Robots Stratejisi

Robots.txt crawling davranışını kontrol etmek için kullanılabilir. Ancak robots ile engellenen URL'nin otomatik olarak indeksten çıkacağı varsayılmamalıdır. Indexing ve crawling farklı süreçlerdir. Search URL stratejisi canonical, noindex, internal link ve robots seçenekleri birlikte değerlendirilerek belirlenmelidir. Loglar değişiklik sonrasında crawler davranışının gerçekten değişip değişmediğini gösterir.

robots.txt Değişiklikleri Log Dosyalarıyla Nasıl Doğrulanır?

robots.txt üzerinde yapılan değişiklik yalnız dosyanın yayınlanmasıyla tamamlanmış sayılmamalıdır. Önce değişiklikten önceki crawl davranışı baseline olarak kaydedilmeli, ardından hedef URL space üzerindeki bot requestlerinin nasıl değiştiği izlenmelidir. Engellenmesi amaçlanan düşük değerli alanlarda request azalışı görülebilir. Ancak robots.txt indexing kontrol aracı değildir ve bu fark paydaşlara açıkça anlatılmalıdır. Log doğrulaması teknik kararın gerçek bot davranışı üzerinde sonuç üretip üretmediğini gösterir.

Önceki Crawl Davranışı

Değişiklik öncesinde hedef URL segmentinin request sayısı ve unique URL hacmi ölçülmelidir. En az birkaç haftalık veri doğal dalgalanmayı anlamaya yardımcı olur. Priority crawl share de aynı dönemde kaydedilebilir. Böylece değişiklik sonrası yalnız toplam crawl düşüşü değil allocation değişimi de değerlendirilir. Baseline olmadan iyileşme iddiası zayıf kalır.

Değişiklik Sonrası Crawl

robots değişikliğinden sonra ilgili URL segmentinde request trendi izlenmelidir. Crawlerların robots dosyasını yeniden görmesi ve davranışın değişmesi zaman alabilir. Birkaç saatlik veriyle kesin sonuç çıkarılmamalıdır. Haftalık eğilim daha anlamlıdır. Beklenen azalma görülmüyorsa pattern veya başka erişim yolu kontrol edilmelidir.

Engellenmesi Gereken URL Space

Robots kuralı tek URL yerine çoğu zaman belirli bir pattern hedefler. Bu patternin değerli URL'leri yanlışlıkla kapsamadığı test edilmelidir. Staging veya robots tester yaklaşımıyla ön kontrol yapılabilir. Log classification kuralı aynı URL space'i takip etmelidir. Böylece yanlış kapsam kısa sürede fark edilir.

robots.txt ile Indexing Kontrolünün Farkı

robots.txt crawlerın belirli URL'leri taramasını sınırlar. Bu mekanizma doğrudan indeksleme direktifi değildir. Arama motoru URL'yi başka kaynaklardan biliyorsa farklı indeksleme davranışı görülebilir. Noindex ise sayfanın crawl edilip direktifin görülmesini gerektirir. Bu nedenle robots ve noindex farklı amaçlarla kullanılmalıdır.

Noindex Crawl Budget'ı Otomatik Olarak Korumaya Yeter mi?

Noindex, bir URL'nin indekslenmemesi için kullanılan direktiflerden biridir, fakat crawlerın bu direktifi görebilmesi için URL'yi taraması gerekir. Dolayısıyla noindex uygulamak tek başına crawler requestlerini otomatik olarak durdurmaz. Büyük düşük değerli URL alanında yalnız noindex kullanmak yine önemli tarama hacmi oluşturabilir. Crawling ve indexing hedefleri ayrı düşünülmelidir. Robots, internal link, sitemap ve URL üretimi gibi katmanlar farklı problemlere yanıt verir.

Crawling ve Indexing Ayrımı

Crawling URL'nin istenmesi, indexing ise içeriğin arama motoru indeksine dahil edilmesidir. Noindex ikinci süreci etkiler. Loglarda noindex sayfalarının hâlâ düzenli tarandığı görülebilir. Bu normal olabilir çünkü crawler direktifi yeniden kontrol edebilir. Büyük sistemlerde crawl allocation ayrıca analiz edilmelidir.

Noindex'in Görülebilmesi İçin Crawl Gereksinimi

Meta robots veya HTTP header içindeki noindex direktifi ancak crawler sayfaya eriştiğinde görülebilir. URL robots.txt ile engellenirse crawler noindex bilgisini alamayabilir. Bu nedenle iki mekanizmayı düşünmeden birlikte kullanmak istenmeyen sonuçlara yol açabilir. Teknik hedef önce tanımlanmalıdır. İndeksleme ve crawling kontrolü için uygun araç ayrı seçilmelidir.

Robots ve Noindex'in Farklı Amaçları

Robots crawling kontrolü, noindex ise indexing kontrolü için kullanılır. Uygulama tasarımı bu farkı temel almalıdır. Düşük değerli faceted URL'lerde hangi mekanizmanın gerekli olduğu URL işlevine göre belirlenir. Loglar crawl davranışını, Search Console ise indexing sonucunu doğrulamaya yardımcı olur. İki veri kaynağı birlikte kullanıldığında kararların etkisi daha net görülür.

XML Sitemap ile Log Verisi Nasıl Karşılaştırılır?

Sitemap sitenin arama motorlarına sunduğu stratejik URL listesini temsil eder. Loglar ise crawlerın gerçekte hangi URL'leri ziyaret ettiğini gösterir. Bu iki veri birleştirildiğinde sitemap'te olup taranan, sitemap'te olup taranmayan ve sitemap dışında olup taranan URL grupları oluşturulabilir. Hatalı status code dönen sitemap URL'leri ayrıca bulunabilir. Crawl freshness ölçümü sayesinde sitemap içindeki kritik URL'lerin ne kadar düzenli ziyaret edildiği de analiz edilebilir.

Sitemap'te ve Crawl Edilen URL

Bu segment beklenen temel davranışı gösterir. Sitemap içindeki URL Googlebot tarafından en az bir kez ziyaret edilmiştir. Ancak frequency ve freshness yine değerlendirilmelidir. Çok önemli URL'nin aylar önce yalnız bir kez taranmış olması ayrıca incelenebilir. Status code ve indexing bilgisi eklendiğinde analiz daha anlamlı olur.

Sitemap'te Ama Crawl Edilmeyen URL

Sitemap içinde bulunan fakat analiz döneminde taranmayan URL'ler dikkat gerektirebilir. Yeni eklenen sayfalar için discovery gecikmesi doğal olabilir. Uzun süredir sitemap'te olan kritik URL'lerde internal link ve kalite sinyalleri kontrol edilmelidir. Log retention süresi yeterli değilse yanlış yorum yapılabilir. Search Console ile indexing durumu ayrıca incelenmelidir.

Sitemap'te Olmayan Ama Crawl Edilen URL

Bu segment crawlerın başka keşif kaynaklarından ulaştığı URL'leri gösterir. Internal links, external links, eski adresler ve parameters yaygın nedenlerdir. Bu URL'lerin bazıları değerli olabilir ve sitemap'e eklenmesi gerekebilir. Diğerleri düşük değerli crawl waste alanı olabilir. URL classification ve business value kararı belirler.

Sitemap'teki Hatalı Status Code'lar

Sitemap URL'lerinin ideal olarak beklenen başarılı status code'u döndürmesi gerekir. Redirect, 404 veya 5xx veren URL'ler sitemap kalite sorunudur. Loglar Googlebot'un bu adresleri gerçekte ne sıklıkta ziyaret ettiğini gösterebilir. Sitemap generator veya yayınlama süreci düzeltilmelidir. Otomatik sitemap health SLO oluşturmak sürdürülebilir kontrol sağlar.

Crawl Freshness

Sitemap URL'lerinin last crawl date ve days since last crawl değerleri hesaplanabilir. Kritik gruplar için freshness dağılımı izlenebilir. Sitemap lastmod alanı varsa içerik değişim zamanı ile crawl zamanı karşılaştırılabilir. Bu analiz özellikle hızlı güncellenen sitelerde değerlidir. Sitemap tek başına crawl garantisi olmadığı için log doğrulaması önemlidir.

Sitemap'te Olmayan URL'ler Neden Googlebot Tarafından Taranıyor?

Googlebot URL'leri yalnız sitemap üzerinden keşfetmez. Internal links, external links, geçmiş crawl kayıtları, parametreler ve faceted navigation gibi pek çok kaynak crawlerın yeni veya eski adreslere ulaşmasını sağlayabilir. Bu nedenle sitemap dışı crawl görmek tek başına sorun değildir. Önemli olan bu URL'lerin site stratejisindeki rolünü anlamaktır. Log ve crawler verisi birleştirildiğinde discovery kaynaklarına ilişkin daha güçlü hipotezler üretilebilir.

Internal Links

Site içinde verilen bağlantılar crawler discovery'nin temel kaynaklarındandır. Sitemap'te olmayan ama internal link alan sayfalar doğal olarak taranabilir. Bu sayfaların stratejik olup olmadığı değerlendirilmelidir. Değerliyse sitemap'e eklenebilir. Düşük değerliyse link kaynağı ve crawl amacı gözden geçirilebilir.

External Links

Dış siteler sitemap'te olmayan eski veya özel URL'lere bağlantı verebilir. Googlebot bu linkleri takip ederek sayfayı yeniden keşfedebilir. Backlink analizi discovery kaynağını anlamaya yardımcı olur. Uygun yeni karşılık varsa redirect değerlendirilebilir. Değerli dış bağlantının boşa gitmemesi için kullanıcı niyeti korunmalıdır.

Geçmiş URL'ler

Arama motorları daha önce gördüğü URL'leri uzun süre hafızasında tutabilir. Sitemap'ten ve internal linklerden kaldırılmış adresler zaman zaman tekrar taranabilir. Frequency zamanla azalıyorsa bu doğal süreç olabilir. Sürekli yüksek crawl varsa başka keşif kaynağı araştırılmalıdır. Migration izleme bu nedenle uzun dönem veri gerektirir.

Parametreler

Query parametreleri linkler veya frontend davranışı nedeniyle crawler tarafından keşfedilebilir. Tracking, sort veya filter parametreleri sitemap'te yer almasa bile taranabilir. Loglarda parameter family request share hesaplanmalıdır. Değerli olmayan alanlarda discovery kaynağı kontrol edilmelidir. URL üretim sistemi mümkün olduğunca kontrollü tasarlanmalıdır.

Faceted Navigation

Facet linkleri HTML içinde crawl edilebilir biçimde sunuluyorsa Googlebot kombinasyonları keşfedebilir. Sitemap'in bu URL'leri içermemesi crawler erişimini otomatik olarak engellemez. Loglar gerçek facet crawl hacmini gösterir. Search demand ve business value ile birlikte değerlendirme yapılmalıdır. Gereksiz kombinasyonların oluşumu ve linklenmesi azaltılabilir.

Orphan-Like URL'ler

Internal crawlerın bulamadığı fakat Googlebot'un taradığı URL'ler orphan-like olarak değerlendirilebilir. Tam anlamıyla orphan olmayabilir çünkü external link veya geçmiş discovery kaynağı bulunabilir. Bu segment veri birleştirme açısından değerlidir. Stratejik URL ise internal linking eksikliği giderilebilir. Eski veya düşük değerli URL ise kaldırma veya redirect kararı verilebilir.

Orphan Page'ler Log Dosyalarıyla Nasıl Bulunur?

Log dosyası tek başına orphan page tanımlayamaz çünkü internal link grafiğini bilmez. Ancak internal crawler verisiyle birleştirildiğinde güçlü bir yöntem ortaya çıkar. Crawler'ın bulamadığı fakat Googlebot'un taradığı URL'ler ayrı segment oluşturur. Bu sayfalar geçmiş yapıdan kalmış, dış link alan veya yanlış navigasyon nedeniyle site içinde kaybolmuş olabilir. Her URL için aksiyon iş değeri ve içerik durumuna göre belirlenmelidir.

Googlebot Tarıyor Ama Internal Crawl Bulamıyor

Bu segment orphan araştırmasının temelidir. Googlebot request kaydı vardır fakat crawler site içi linklerle URL'ye ulaşamamıştır. External link, sitemap veya geçmiş URL kaynağı kontrol edilmelidir. Sitemap'te de yoksa gerçek orphan ihtimali güçlenir. Sayfanın business ve organic değeri aksiyon kararını belirler.

Eski Sayfalar

Geçmiş site mimarisinden kalan sayfalar internal linklerini kaybetmiş olabilir. Googlebot eski keşif nedeniyle bu URL'leri hâlâ ziyaret edebilir. İçerik güncelse ve değerliyse yeniden internal link verilmesi düşünülebilir. Eski ve gereksiz içerik kaldırma politikası kapsamında değerlendirilebilir. Log frequency kararın aciliyetini anlamaya yardımcı olur.

External Link Kaynaklı Sayfalar

Dış backlink alan sayfa internal bağlantısı olmasa bile Googlebot tarafından düzenli taranabilir. Backlink kalitesi ve sayfanın mevcut iş değeri kontrol edilmelidir. Değerli içerikse site mimarisine yeniden bağlanabilir. İçerik kaldırılmışsa ilgili yeni sayfaya uygun redirect düşünülebilir. Loglar dış keşfin hâlâ aktif etkisi olup olmadığını gösterir.

Yanlış Navigasyon

Teknik veya içerik değişikliği sonucu bir sayfa navigasyondan yanlışlıkla çıkarılmış olabilir. Internal crawler sayfayı bulamazken Googlebot geçmiş keşif nedeniyle taramaya devam eder. Bu durum önemli landing page için kritik olabilir. Navigation ve contextual linkler kontrol edilmelidir. Düzeltme sonrası crawler ve log verisi tekrar doğrulanmalıdır.

Aksiyon Kararı

Orphan-like URL için tek standart aksiyon yoktur. Değerli sayfa internal link almalı, gereksiz sayfa kaldırılmalı veya uygun yeni URL'ye yönlendirilebilir. Sitemap durumu ayrıca kontrol edilmelidir. Search Console indexing ve traffic verisi kararın kalitesini artırır. Amaç her orphan URL'yi aynı biçimde ele almak değil işlevine göre doğru çözüm seçmektir.

SEO Crawler ile Server Log Verisi Nasıl Birleştirilir?

SEO crawler ve server log iki farklı perspektif sunar. Crawler sitenin internal mimari üzerinden keşfedilebilir yapısını, log ise gerçek arama motoru isteklerini gösterir. Normalize URL üzerinden iki dataset join edildiğinde dört temel davranış grubu oluşturulabilir. Bu gruplar discovery ve crawl allocation problemlerini anlamayı kolaylaştırır. Tek bir araçla görülemeyen birçok teknik SEO fırsatı bu karşılaştırmadan çıkar.

Crawler Buluyor + Googlebot Tarıyor

Bu grup hem internal olarak keşfedilebilir hem de Googlebot tarafından ziyaret edilen URL'leri içerir. Genel olarak beklenen davranıştır. Ancak frequency, status ve indexing durumu yine kontrol edilmelidir. Düşük değerli URL'ler bu grupta yoğun ise internal architecture crawl waste oluşturuyor olabilir. Stratejik URL'lerde sağlıklı freshness olumlu sinyaldir.

Crawler Buluyor + Googlebot Taramıyor

Internal crawler URL'yi bulduğu halde analiz döneminde Googlebot requesti yoksa birkaç neden düşünülebilir. URL yeni olabilir, düşük crawl demand görebilir veya log retention süresi kısa olabilir. Sitemap ve Search Console durumu kontrol edilmelidir. Kritik sayfaysa internal depth ve link prominence analiz edilebilir. Tek günlük log verisinden kesin sonuç çıkarılmamalıdır.

Crawler Bulamıyor + Googlebot Tarıyor

Bu grup orphan-like, eski veya external link kaynaklı URL'leri ortaya çıkarabilir. Parameter ve migration URL'leri de burada görülebilir. Business value ve status code ile segmentasyon yapılmalıdır. Sürekli taranan düşük değerli URL'ler crawl waste fırsatı olabilir. Değerli URL'lerde internal linking eksikliği giderilebilir.

İki Kaynak Arasındaki Farklardan Aksiyon Çıkarmak

Veri birleştirme yalnız tablo üretmek için yapılmamalıdır. Her davranış grubuna açık aksiyon kuralı bağlanabilir. Örneğin crawler buluyor ve Googlebot taramıyor grubundaki priority URL'ler review listesine girebilir. Crawler bulamıyor ve Googlebot tarıyor grubundaki yüksek frequency 404'ler migration cleanup listesine alınabilir. Bu yöntem teknik SEO backlogunu gerçek crawler davranışına göre önceliklendirir.

Search Console ile Log Verisi Nasıl Birleştirilir?

Search Console ve log datasetleri URL seviyesinde birleştirildiğinde crawling ile indexing arasındaki fark daha net görülür. Crawled ve indexed URL'ler, crawled ama indexed olmayanlar, yakın zamanda taranmamış fakat indexed olanlar ve discovered ancak taranmamış URL'ler ayrı değerlendirilebilir. Bu segmentler sorunun crawl mı indexing mi olduğunu anlamayı kolaylaştırır. Log verisi burada arama motorunun gerçek istek geçmişini sağlarken Search Console sonraki aşamalara ilişkin farklı sinyaller ekler. İki kaynak birbirinin yerine değil birbirini tamamlamak için kullanılmalıdır.

Crawled + Indexed

Bu grup URL'nin log döneminde crawler isteği aldığını ve Search Console tarafında indeksleme sinyali bulunduğunu gösterir. Genellikle sağlıklı temel durumdur. Ancak status, freshness ve organic performance yine izlenebilir. Sık taranan ama düşük değerli sayfalar bu grupta da bulunabilir. Crawl efficiency analizi business value ile tamamlanmalıdır.

Crawled + Not Indexed

Bu segment önemli analiz alanıdır çünkü URL taranmış olmasına rağmen indeksleme gerçekleşmemiş olabilir. Sorunun crawl budget olduğunu varsaymak burada yanlış olabilir. İçerik kalitesi, canonical, noindex veya duplicate gibi faktörler araştırılmalıdır. Loglar yalnız crawler erişiminin gerçekleştiğini kanıtlar. Indexing teşhisi için Search Console ve sayfa analizi gerekir.

Not Recently Crawled + Indexed

Bir URL indekste bulunabilir ancak yakın zamanda tekrar taranmamış olabilir. Sayfa nadiren değişiyorsa bu normal olabilir. Kritik ve sık güncellenen içerikte freshness riski doğabilir. Last modified ve business priority verisi değerlendirilmelidir. Her indexed URL için yüksek crawl frequency hedeflemek doğru değildir.

Discovered + Not Crawled

Search Console belirli URL'lerin keşfedildiğini ancak henüz taranmadığını gösterebilir. Loglarda request olmaması bu durumu doğrulayabilir. Büyük URL space, düşük crawl demand veya site mimarisi etken olabilir. Priority URL ise internal linking ve sitemap yapısı incelenmelidir. Düşük değerli alanlarda ise bu durum mutlaka problem olmayabilir.

Sorunun Crawl mı Indexing mi Olduğunu Ayırmak

Önce loglarda crawler requestinin gerçekleşip gerçekleşmediği kontrol edilmelidir. Sayfa düzenli taranıyor ancak indekste değilse asıl sorun indexing tarafında olabilir. Hiç veya çok seyrek taranıyorsa discovery ve crawl demand araştırılmalıdır. Bu ayrım teknik ekibin yanlış probleme çalışmasını önler. Multi-data dashboard bu teşhisi standartlaştırabilir.

Analytics Verisi Log Analizine Nasıl Eklenir?

Log analizi crawler davranışını gösterir, fakat hangi URL'nin kullanıcı ve iş açısından değerli olduğunu tek başına söylemez. Analytics verisi human traffic, revenue, conversion ve landing page importance gibi alanlar ekleyerek bu boşluğu doldurur. Böylece çok taranan ama hiç değer üretmeyen URL alanı ile kritik gelir sayfaları ayrıştırılabilir. Priority crawl share iş değeriyle tanımlanmış URL grupları üzerinden hesaplanabilir. Crawl optimizasyonu bu sayede yalnız teknik request sayısı hedefinden çıkar ve iş sonuçlarıyla bağlantılı hale gelir.

Bot Trafiği

Bot trafiği loglardan doğrulanır ve analytics kullanıcı verisinden ayrı tutulur. Analytics platformları botları farklı biçimde filtreleyebilir. Bu nedenle crawler ölçümü için access log authoritative kaynak olmalıdır. URL seviyesinde iki dataset join edilebilir. Böylece bot davranışı ve insan değeri aynı sayfa üzerinde karşılaştırılır.

Human Traffic

Human traffic sayfanın gerçek kullanıcı talebini gösterir. Yüksek organik veya doğrudan trafik alan URL'ler priority segmentine dahil edilebilir. Ancak düşük trafik her zaman düşük değer anlamına gelmez. Yeni veya B2B yüksek değerli landing page farklı değerlendirilmelidir. Traffic metriği tek başına değil conversion ve iş amacıyla birlikte kullanılmalıdır.

Revenue

Revenue e-ticaret ve marketplace projelerinde güçlü business value alanıdır. Ürün ve kategori sayfalarının crawler payı gelir katkısıyla karşılaştırılabilir. Yüksek gelir getiren URL'lerin çok düşük freshness değeri varsa teknik öncelik artabilir. Revenue verisi gizlilik ve finans erişim kurallarına uygun şekilde aggregate tutulabilir. SEO dashboarda yalnız gerekli segment değerleri aktarılmalıdır.

Conversion

Conversion form, lead, purchase veya farklı iş hedefleriyle tanımlanabilir. Kritik dönüşüm sayfaları priority URL listesine eklenebilir. Googlebot request payı ve last crawl date bu segment için ayrıca izlenebilir. Düşük conversion sayfasını otomatik olarak düşük SEO değerli kabul etmek doğru değildir. Funnel rolü ve trafik kaynağı dikkate alınmalıdır.

Landing Page Importance

Landing page importance organik trafik, conversion ve stratejik iş rolünün birleşimiyle skorlanabilir. Örneğin yeni hizmet sayfası henüz trafik almıyor olsa da stratejik önceliği yüksek olabilir. Priority listesi yalnız geçmiş analytics verisine bağlı kalmamalıdır. Product ve SEO ekipleri manuel öncelik alanı ekleyebilir. Bu skor crawl freshness ve allocation analizinde kullanılır.

Business Value Segmentasyonu

URL'ler high, medium ve low business value gibi kategorilere ayrılabilir. Bu sınıflandırma revenue, traffic, conversion ve stratejik önemden türetilebilir. Crawl waste analizinde low value URL'ler daha yakından incelenirken high value alanların freshness KPI'ları takip edilir. Model düzenli olarak güncellenmelidir. Böylece teknik SEO optimizasyonu iş öncelikleriyle uyumlu kalır.

Priority Crawl Share Nedir?

Priority Crawl Share, doğrulanmış Googlebot requestlerinin ne kadarının stratejik URL grubuna gittiğini ölçmeye yarayan bir metriktir. Önce priority URL'ler business ve SEO kriterleriyle tanımlanır. Ardından bu URL'lere gelen request sayısı toplam ilgili bot requestlerine bölünür. Yüksek oran otomatik olarak iyi değildir, ancak trend ve diğer URL space dağılımlarıyla birlikte güçlü sinyal sunar. Amaç crawler davranışını iş değeriyle ilişkilendirmektir.

Stratejik URL'leri Tanımlamak

Priority listesi organik trafik, revenue, conversion ve ürün stratejisi gibi kriterlerle oluşturulabilir. Yeni sayfalar için manuel importance değeri gerekebilir. Sitemap priority gibi eski veya anlamsız alanlara körü körüne güvenilmemelidir. Liste template ve URL seviyesinde tutulabilir. Düzenli review ile güncel iş hedefleri yansıtılmalıdır.

Googlebot Request Payını Hesaplamak

Priority URL request sayısı toplam doğrulanmış ilgili bot requestlerine bölünebilir. Resource requestlerin dahil edilip edilmediği veri tanımında açık olmalıdır. Genellikle HTML URL istekleri ayrı değerlendirilir. Günlük ve haftalık trend hesaplanabilir. Ani düşüş priority crawling problemine işaret edebilir.

Site Bölümlerini Karşılaştırmak

Product, category, blog ve filter segmentlerinin request payları yan yana gösterilebilir. Priority alanların düşük payı ile waste alanların yükselişi birlikte incelenmelidir. Tek bir dönemin oranından kesin sonuç çıkarılmamalıdır. Search demand ve site update sıklığı doğal farklılık yaratabilir. Trend analizi daha güvenilir yorum sağlar.

Trendleri Yorumlamak

Priority crawl share zaman içinde yükseliyorsa yapılan URL cleanup veya internal link değişikliği olumlu sonuç üretiyor olabilir. Ancak toplam crawl request ciddi düşmüşse oran tek başına yanıltıcı olabilir. Mutlak request ve unique URL metrikleri de grafikte bulunmalıdır. Business seasonality hesaba katılmalıdır. Teknik değişiklik tarihleri dashboard üzerinde işaretlenmelidir.

Server Response Time Googlebot İçin Nasıl Analiz Edilir?

Bot response time analizi sunucunun crawler isteklerine ne kadar hızlı yanıt verdiğini gösterir. Ortalama değer faydalı olsa da p95 ve p99 gibi üst yüzdelikler gerçek sorunları daha iyi ortaya çıkarabilir. Site bölümü ve saat bazında segmentasyon yapılmalıdır. Yavaşlama dönemleri crawl request düşüşü veya 5xx artışıyla karşılaştırılabilir. Bu analiz SEO ile platform ekiplerinin ortak çalışmasını gerektirir çünkü sorun backend, cache, CDN veya network katmanında olabilir.

Ortalama Response Time

Ortalama response time genel performans eğilimini özetler. Ancak birkaç çok yavaş veya çok hızlı request sonucu etkileyebilir. Median değer de dashboardda gösterilebilir. Bot ve human response karşılaştırması altyapı davranışını anlamaya yardımcı olabilir. URL template bazında ortalamalar daha uygulanabilir sonuç verir.

P95/P99 Response Time

P95 ve p99 en yavaş requestlerin davranışını görünür kılar. Ortalama normal kalırken az sayıda request ciddi timeout sınırına yaklaşabilir. Bu tail latency büyük sitelerde önemlidir. Template, region ve upstream servis bazında dağılım çıkarılabilir. SLO sisteminde üst percentile hedefleri kullanılabilir.

Site Bölümü Bazlı Performans

Her URL space aynı backend yolunu kullanmayabilir. Product sayfaları API ve database sorgularına bağımlıyken blog sayfaları cache üzerinden hızlı yanıt verebilir. Template bazlı response time farkları kök neden bulmayı kolaylaştırır. Log datasetine upstream service veya route alanı eklenebilir. Teknik backlog en yavaş ve en değerli bölümlere öncelik verebilir.

Saat Bazlı Yavaşlama

Belirli saatlerde backend yükü veya batch işlemleri response time artışına yol açabilir. Saatlik p95 grafiği bu patterni gösterebilir. Googlebot request hacmiyle aynı zaman çizelgesinde karşılaştırma yapılabilir. Gece çalışan veri işlemleri crawler performansını etkiliyor olabilir. Platform ekibi kapasite veya schedule değişikliği yapabilir.

Crawl Davranışıyla Korelasyon

Response time artışı ile crawl request hacmi arasında korelasyon görülebilir. Ancak korelasyon tek başına nedensellik kanıtlamaz. Uzun dönem veri ve diğer altyapı metrikleri değerlendirilmelidir. 5xx ve timeout oranı da aynı grafikte izlenebilir. Amaç botlara özel performans hilesi değil herkes için sağlıklı ve güvenilir sunucu davranışı sağlamaktır.

CDN Cache Logları SEO İçin Nasıl Kullanılır?

CDN cache logları crawler isteklerinin edge üzerinden mi yoksa origin'e giderek mi yanıtlandığını gösterir. HIT, MISS ve BYPASS dağılımı bot response time ile origin yükünü anlamaya yardımcı olur. Cache kaynaklı hata veya yanlış varyasyon problemi varsa SEO erişimi etkilenebilir. Global sitelerde edge location bilgisi bölgesel farklılıkları gösterebilir. Ancak cache optimizasyonu içerik doğruluğu ve kullanıcı gereksinimleri korunarak yapılmalıdır.

HIT

HIT isteğin cache içeriğinden yanıtlandığını gösterir. Genellikle origin yükünü azaltır ve response time'ı iyileştirir. Bot HTML isteklerinde HIT oranı site mimarisine göre değişebilir. Güncellik gerektiren içerikte uzun cache süresi sorun yaratabilir. Bu nedenle performans ve freshness birlikte düşünülmelidir.

MISS

MISS gerekli içeriğin cache içinde bulunmadığını ve origin'e gidildiğini gösterebilir. Sık değişen sayfalarda normal olabilir. Beklenenden yüksek MISS oranı cache key veya TTL problemi anlamına gelebilir. Bot requestlerinde response time farkı ölçülebilir. Origin kapasitesi üzerindeki etkisi DevOps ile birlikte değerlendirilmelidir.

BYPASS

BYPASS requestin cache mekanizmasını atladığını gösterir. Authentication, cookie veya uygulama kuralı nedeniyle beklenen olabilir. Bot trafiğinde yüksek BYPASS oranı cache configuration açısından incelenebilir. Ancak dinamik içerik için doğru davranış olabilir. SEO ekibi tek başına cache kuralı değiştirmemelidir.

Cache Kaynaklı Hata

Yanlış cache key veya stale içerik beklenmedik status code ve canonical çıktısı oluşturabilir. CDN logları olayın edge katmanında gerçekleştiğini gösterebilir. Origin response ile karşılaştırma yapılmalıdır. Bot ve kullanıcıya farklı hatalı varyant sunulmadığı doğrulanmalıdır. Cache purge ve deployment süreçleri birlikte test edilmelidir.

Origin Yüküne Etki

Cache hit oranı arttığında origin'e ulaşan request sayısı azalabilir. Bu durum yüksek trafikli sitelerde altyapı kapasitesine katkı sağlar. Ancak SEO amacıyla her şeyi agresif cache etmek doğru değildir. Güncellik ve kişiselleştirme gereksinimleri korunmalıdır. Bot response time ile origin CPU veya request metriği birlikte izlenebilir.

JavaScript Sitelerinde Log Analizi Nasıl Yapılır?

JavaScript ağırlıklı sitelerde HTML requestleri yanında JavaScript, CSS ve API kaynakları da rendering davranışına ilişkin sinyaller sağlayabilir. Ancak logların bir sayfanın gerçekten doğru render edildiğini tek başına kanıtlayamayacağı unutulmamalıdır. HTML'in 200 dönmesi client side içerik yüklemesinin başarılı olduğu anlamına gelmez. Resource request patternleri, rendering testleri ve Search Console verisi birlikte kullanılmalıdır. Özellikle API'nin bot tarafında 403 veya 5xx vermesi içerik görünürlüğünü etkileyebilir.

HTML Request'leri

HTML request crawlerın URL'ye ilk erişimini gösterir. Status, response time ve response bytes izlenebilir. Client side rendered sayfada HTML başlangıç içeriği sınırlı olabilir. Log tek başına DOM'un son halini göstermez. Rendering testi ile HTML içeriği ve final çıktı karşılaştırılmalıdır.

JavaScript Resource Request'leri

JavaScript dosyalarına bot altyapısından gelen istekler loglarda görülebilir. 403 veya 404 JavaScript kaynakları rendering problemi ihtimali yaratabilir. Resource cache ve response time ayrıca izlenebilir. Ancak dosyanın indirilmiş olması kodun hatasız çalıştığını kanıtlamaz. Browser tabanlı render testi gereklidir.

CSS

CSS kaynakları bazı rendering işlemlerinde önemli olabilir. Engellenen veya hatalı CSS kullanıcı ve crawler görünümünü etkileyebilir. Loglarda bot requestleri ve status code kontrol edilebilir. Büyük CSS response size altyapı maliyetini artırabilir. Görsel render doğrulaması ayrı araçlarla yapılmalıdır.

API Request'leri

Client side içerik API üzerinden yükleniyorsa bu endpointlerin erişilebilirliği kritiktir. Bot rendering sırasında API requestleri loglarda görünebilir. 401, 403, 429 veya 5xx durumları içerik yüklenmesini engelleyebilir. Ancak user agent ve execution context farklılıkları dikkatle yorumlanmalıdır. API verisi ile render testi birlikte kullanılmalıdır.

Logların Rendering Hakkında Söyleyemeyeceği Şeyler

Loglar final DOM, görsel layout veya JavaScript execution sonucunu doğrudan göstermez. Bir kaynak 200 dönse bile script runtime hatası verebilir. İçerik client side koşul nedeniyle hiç render edilmeyebilir. Bu nedenle log analizi rendering teşhisinin yalnız bir parçasıdır. Search Console render, browser testleri ve crawler JavaScript rendering özellikleriyle tamamlanmalıdır.

Büyük Response Boyutları Nasıl Analiz Edilir?

Response bytes alanı büyük HTML, JavaScript, CSS ve API yanıtlarını belirlemek için kullanılabilir. Özellikle crawlerın düşük değerli URL alanlarında çok büyük yanıtlar indirmesi altyapı maliyetini artırabilir. Template bazında median ve p95 response size hesaplanabilir. Deployment sonrası beklenmeyen büyüme regression alarmına bağlanabilir. Crawl efficiency yalnız request sayısıyla değil toplam transfer edilen veri ve sunucu maliyetiyle de değerlendirilebilir.

HTML Payload

Büyük HTML dosyaları server render edilmiş tekrar eden içerik veya aşırı inline veri içerebilir. Template bazında HTML byte dağılımı ölçülebilir. Ani büyüme deployment ile korelasyon gösterebilir. Gereksiz markup ve embedded JSON azaltılabilir. Ancak optimization kullanıcı işlevini bozmamalıdır.

JavaScript

JavaScript response size client execution yanında crawler resource request maliyetini de etkiler. Loglar transfer boyutunu gösterirken bundle analyzer kod içeriğini açıklar. Route bazlı splitting değerlendirilebilir. Cache status ile tekrar indirme davranışı incelenebilir. Rendering için gerekli kaynakların erişimi korunmalıdır.

CSS

Büyük CSS dosyaları tasarım sistemi veya unused style birikimini gösterebilir. Log response size trendi deployment sonrası regression tespitinde kullanılabilir. Coverage ve build analizleri gereksiz CSS'i bulmaya yardımcı olur. Cache davranışı da önemlidir. Teknik SEO ekibi frontend ekibiyle ortak performans backlog oluşturabilir.

API Response

API response büyükse render ve backend süresi etkilenebilir. Loglarda bytes ve response time birlikte analiz edilebilir. Bot rendering için gerçekten gerekli verinin ne kadar olduğu incelenebilir. Payload küçültme uygulama mimarisi kararıdır. SEO bulgusu engineering ekibine ölçülebilir veriyle aktarılmalıdır.

Crawl Verimliliği

Crawl verimliliği yalnız request sayısını azaltmak değildir. Stratejik içeriklerin uygun sıklıkla taranması, hataların düşük olması ve altyapının sağlıklı yanıt vermesi birlikte değerlendirilir. Transfer edilen toplam byte ve response time bu resme eklenebilir. Düşük değerli URL alanına yüksek resource harcanması optimizasyon fırsatı olabilir. İş değeri her zaman karar modelinde bulunmalıdır.

Migration Sonrasında Log Analizi Nasıl Yapılmalıdır?

Site migration sonrasında log analizi crawlerın eski ve yeni URL yapıları arasındaki geçişini doğrudan izleme fırsatı verir. Eski URL requestleri, yeni URL discovery, redirect davranışı, 404 ve 5xx oranları birlikte takip edilmelidir. Yeni site bölümlerinin crawl frequency değeri zaman içinde yükselmelidir. Kritik URL listesi özel monitoring kapsamına alınabilir. Migration projesi yalnız yayına çıkış günüyle değil crawler davranışı stabil hale gelene kadar izlenmelidir.

Eski URL Crawl'ları

Eski URL'lere gelen Googlebot requestleri migration sonrasında bir süre devam edebilir. Trendin zaman içinde düşüp düşmediği izlenmelidir. Internal link ve sitemap eski adresleri kullanıyorsa bu düşüş yavaş olabilir. En yoğun eski URL kaynakları ayrı listelenebilir. Uygun redirectlerin çalıştığı doğrulanmalıdır.

Yeni URL Discovery

Yeni URL'lerin ilk crawl zamanı migration sağlığı için önemli sinyaldir. Priority sayfaların hızlı keşfedilip keşfedilmediği ölçülebilir. Sitemap ve internal links discovery sürecini desteklemelidir. Yeni URL hiç taranmıyorsa route veya erişim problemi olabilir. Search Console ile indexing durumu ayrıca takip edilmelidir.

Redirect Response'ları

Eski URL'lerin beklenen status code ve target ile yönlendirildiği kontrol edilmelidir. Redirect chain ve loop crawler ile bulunabilir. Loglar Googlebot'un bu kaynakları ne kadar sık kullandığını gösterir. En yüksek request alan redirectler öncelikli izlenebilir. Zamanla internal kaynaklar final URL'lere güncellenmelidir.

404 Artışı

Migration sonrası 404 spike sık görülen problemdir. Eski URL mapping eksikleri veya route hataları neden olabilir. Loglar bot requesti alan gerçek 404'leri gösterir. Sitemap ve crawler kaynaklarıyla birleştirme yapılmalıdır. High traffic veya backlink değerli URL'ler önceliklendirilmelidir.

5xx Artışı

Yeni altyapı beklenmeyen yük veya route sorunları nedeniyle 5xx üretebilir. Bot requestlerinde zaman bazlı spike izlenmelidir. Deployment ve infrastructure health verileriyle korelasyon kurulabilir. Critical URL error rate ayrı SLO olabilir. Sorun giderildikten sonra loglarla recovery doğrulanmalıdır.

Yeni Site Bölümlerinin Crawl Frequency'si

Yeni directory veya hostname alanlarının Googlebot tarafından ne sıklıkta ziyaret edildiği izlenebilir. İlk günlerde düşük frequency doğal olabilir. Trendin artması discovery'nin güçlendiğini gösterebilir. Priority URL'ler ile düşük değerli alanlar ayrı tutulmalıdır. İş değeri ve update sıklığına göre beklenen crawl davranışı tanımlanmalıdır.

Deployment Sonrası SEO Log Kontrolü Nasıl Yapılır?

Her deployment sonrasında manuel olarak binlerce log satırı okumak gerekmez. Deploy timestamp dashboarda işaretlenebilir ve önce sonra request, status code, response time ile priority crawl metrikleri otomatik karşılaştırılabilir. HTTP error spike veya bot response time artışı release regresyonunu hızlıca gösterebilir. Kritik URL listesi smoke check benzeri biçimde izlenebilir. Bu sistem teknik SEO'yu release yaşam döngüsünün kalıcı parçasına dönüştürür.

Deploy Zamanını Dashboard'a İşaretlemek

Release timestamp grafik üzerinde dikey işaret olarak gösterilebilir. Böylece metrik değişiminin deployment ile zaman ilişkisi hemen görülür. Release ID mevcutsa filtreleme yapılabilir. Büyük organizasyonlarda aynı gün birden fazla deployment olabilir. Service veya template owner bilgisi eklenmesi analizi kolaylaştırır.

Önce-Sonra Crawl Karşılaştırması

Deployment öncesi ve sonrası belirli zaman pencereleri karşılaştırılabilir. Request volume, unique crawled URL ve priority share değişimi ölçülür. Doğal günlük patternler nedeniyle aynı saat aralıklarını kıyaslamak yararlıdır. Büyük değişimlerde neden araştırılır. Kısa süreli fark ile kalıcı trend birbirinden ayrılmalıdır.

HTTP Error Spike

Yeni release sonrasında 404 veya 5xx artışı otomatik alarm oluşturabilir. URL template dağılımı hangi bölümün etkilendiğini gösterir. Status ile upstream error bilgisi birleştirilmelidir. Kritik sayfa hataları daha yüksek severity alır. Düzeltme veya rollback sonrası error rate normalleşmesi doğrulanır.

Bot Response Time

Release yeni database sorgusu veya API maliyeti oluşturmuş olabilir. Bot response p95 değeri deployment sonrası yükselirse backend profiling yapılmalıdır. Human response metrikleriyle karşılaştırma faydalıdır. Sorun yalnız botlara özel olmamalıdır. Platform ekibi genel performans ve kapasiteyi birlikte değerlendirir.

Critical URL Crawl

Kritik URL listesi deployment sonrası status ve accessibility açısından kontrol edilebilir. Googlebot'un hemen taraması garanti edilemeyeceği için sentetik HTTP testleri de kullanılabilir. Loglarda sonraki bot ziyaretinin başarılı olup olmadığı izlenir. Sitemap ve canonical değişiklikleri ayrıca doğrulanmalıdır. Critical page SLO sistemi bu kontrolleri otomatikleştirebilir.

Sürdürülebilir SEO İçin Log Analizi Ne Sıklıkla Yapılmalıdır?

Analiz sıklığı site büyüklüğü, değişim hızı ve iş riskine göre belirlenmelidir. Büyük kurumsal sistemlerde kritik hata ve anomaliler günlük otomatik izlenebilir. Haftalık hızlı kontrol request, status code, priority page ve response time trendlerini gözden geçirir. Aylık analiz crawl allocation, waste ve freshness konularına daha derin bakar. Çeyreklik review ise uzun dönem teknik borç, ROI ve mimari değişiklik ihtiyacını değerlendirmek için uygundur.

Günlük Otomatik Monitoring

Günlük otomatik monitoring temel sağlık sinyallerini yakalamalıdır. Verified Googlebot request hacmi, 5xx, 429, 404 spike ve kritik URL kaybı izlenebilir. Normal dalgalanmalar alarm üretmemelidir. Baseline veya dinamik threshold kullanılması faydalıdır. Kritik olay ilgili owner'a otomatik yönlendirilebilir.

kritik hata ve anomaliler

Günlük alarm sistemi tüm değişimleri değil iş ve SEO riski oluşturan anomalileri hedeflemelidir. Ani Googlebot düşüşü, 5xx artışı veya priority URL crawl kaybı örnek olabilir. Minimum request ve duration şartları false positive oranını azaltır. Severity seviyeleri farklı bildirim kanallarına bağlanabilir. Alert sonrası incident workflow açık olmalıdır.

Haftalık Hızlı Kontrol

Haftalık review otomatik dashboard sonuçlarının insan tarafından yorumlandığı kısa oturum olabilir. Request trend, status dağılımı, priority crawl ve response time kontrol edilir. Yeni URL pattern veya parameter spike var mı bakılır. Büyük değişiklik yoksa ayrıntılı analiz gerekmez. Bu rutin küçük problemlerin büyümesini önler.

requests

Toplam verified bot request ve unique URL sayısı haftalık karşılaştırılabilir. Ani artış yeni facet veya teknik route nedeniyle oluşabilir. Düşüş robots, WAF veya site erişim problemiyle ilişkili olabilir. Önceki haftalar ve aynı gün patternleri hesaba katılmalıdır. Mutlak sayı tek başına başarı metriği değildir.

status codes

2xx, 3xx, 4xx ve 5xx oranları haftalık izlenebilir. Yeni 404 cluster veya redirect artışı gözden geçirilir. 5xx düşük olsa bile kritik template'te yoğunlaşabilir. URL space dağılımı mutlaka kontrol edilmelidir. Değişiklikler ilgili backlog maddesine bağlanabilir.

priority pages

Priority URL'lerin last crawl ve request share değerleri kontrol edilir. Yeni stratejik sayfalar listeye eklenebilir. Eski kampanya URL'leri çıkarılabilir. Freshness hedefleri template bazında değerlendirilebilir. İş değişiklikleri bu listeye düzenli yansıtılmalıdır.

response time

Bot response time median ve p95 haftalık trend olarak incelenebilir. Ani artış backend veya CDN problemi olabilir. Saat ve template kırılımı gerektiğinde açılır. User traffic performance verisiyle karşılaştırma yapılabilir. Uzun dönem yükseliş kapasite planlaması gerektirebilir.

Aylık Derin Analiz

Aylık review URL space ve iş değeri bazında daha kapsamlı değerlendirme yapmalıdır. Crawl waste, priority share, freshness ve sitemap karşılaştırmaları yapılabilir. Yeni technical debt alanları backloga eklenir. Yapılan optimizasyonların önce ve sonra sonuçları değerlendirilir. Bu toplantı SEO, engineering ve product ekiplerinin ortak katılımıyla daha verimli olur.

crawl allocation

Googlebot requestlerinin site bölümlerine dağılımı incelenir. Priority alanların payı ile waste segmentleri karşılaştırılır. Aylar arasındaki değişim yorumlanır. Yeni URL ailesi beklenmedik biçimde yüksek pay alıyorsa kaynağı araştırılır. Allocation metriği iş değeriyle ilişkilendirilir.

crawl waste

Waste segmentleri ve toplam Crawl Waste Rate aylık raporlanabilir. En büyük contributor listesi çıkarılır. Robots, internal link veya URL generation değişikliklerinin etkisi izlenir. İş değeri değişen URL segmentleri yeniden sınıflandırılabilir. Amaç oranı mekanik olarak sıfırlamak değildir.

freshness

Priority sayfaların days since last crawl dağılımı takip edilir. Update frequency ile karşılaştırılır. Yeni içerik ve ürünler için first crawl delay ölçülebilir. Uzun gecikme gösteren template'ler detaylı incelenir. Sitemap ve internal link aksiyonları planlanabilir.

URL spaces

Yeni path ve parameter patternleri aylık olarak keşfedilebilir. URL classifier unknown kategorisi incelenmelidir. Yeni kampanya veya ürün özelliği kontrolsüz URL alanı yaratmış olabilir. Her yeni segment owner ve business purpose ile etiketlenir. Bu süreç crawl haritasını güncel tutar.

Çeyreklik Stratejik Review

Çeyreklik review günlük metriklerden daha üst seviyede düşünmeyi sağlar. Uzun dönem crawl trendi, teknik SEO borcu ve yapılan işlerin ROI etkisi değerlendirilir. Sürekli tekrar eden sorunlar mimari değişiklik gerektirebilir. Log retention ve dashboard kapsamı gözden geçirilir. Organizasyonun automation maturity seviyesi de bu toplantıda değerlendirilebilir.

uzun dönem trend

Üç veya daha fazla aylık veri seasonal ve yapısal değişimleri ayırmaya yardımcı olur. Crawl volume, waste ve freshness trendleri birlikte incelenir. Büyük migration veya ürün lansmanlarının kalıcı etkisi görülebilir. Baseline gerektiğinde yeniden hesaplanabilir. Tarihsel veri stratejik kararlar için saklanmalıdır.

SEO teknik borcu

Tekrar eden redirect, parameter ve 404 problemleri technical debt listesine alınabilir. Aynı semptom sürekli geri dönüyorsa sistemsel kök neden vardır. Örneğin CMS yanlış URL üretmeye devam ediyorsa tek tek temizleme yerine generator düzeltilmelidir. Borç iş değeri ve riskle önceliklendirilir. Çeyreklik kapasite planına dahil edilebilir.

ROI

Log optimizasyonlarının iş etkisini ölçmek her zaman doğrudan değildir. Ancak server load, error reduction, priority crawl freshness ve organic discovery gibi ara sonuçlar izlenebilir. Migration sonrası recovery veya yeni ürün discovery süresi ölçülebilir. Teknik efor ile operasyonel kazanım karşılaştırılır. Bu yaklaşım sürekli log altyapısının değerini yönetim seviyesinde daha anlaşılır hale getirir.

mimari değişiklik ihtiyacı

Bazı crawl problemleri yalnız SEO ayarıyla çözülemez. Faceted navigation, URL generator veya routing mimarisi kökten değişiklik gerektirebilir. Log trendi problemin ölçeğini kanıtlamak için kullanılabilir. Engineering ve product ekipleri maliyet ile faydayı birlikte değerlendirir. Büyük mimari kararlar veriyle desteklenmiş olur.

SEO Observability Nedir?

SEO observability, siteyi yalnız periyodik auditlerle kontrol etmek yerine logs, crawls, Search Console, analytics, alerting ve incident management verilerini sürekli bir sistemde birleştirme yaklaşımıdır. Monitoring belirli metrikleri takip ederken observability beklenmeyen durumun nedenini anlamaya yetecek bağlam üretmeyi amaçlar. Loglar crawling, crawlerlar internal architecture, Search Console indexing ve arama performansı, analytics ise iş değeri katmanı sağlar. Alerting anomalileri yakalar ve incident management aksiyonu yönetir. Sürdürülebilir SEO programı bu katmanları birbirinden kopuk raporlar yerine ortak operasyon modelinde buluşturabilir.

SEO Audit ile Farkı

SEO audit belirli bir zamanda sitenin durumunu kapsamlı biçimde değerlendirir. Observability ise değişimi sürekli izler ve beklenmedik olayları erken yakalar. Audit gerekli olmaya devam eder ancak tek başına sürekli değişen kurumsal siteler için yeterli değildir. Her deployment veya içerik değişikliğinden sonra yeni problem oluşabilir. Observability audit bulgularının yeniden oluşup oluşmadığını da takip eder.

Monitoring ile Farkı

Monitoring genellikle önceden tanımlanmış metrik ve thresholdları izler. Observability ise neden sorusunu cevaplamaya yardımcı olacak daha zengin veri bağlamını hedefler. Örneğin 5xx alarmı monitoringdir. Hatanın hangi template, release ve upstream service ile ilişkili olduğunu görebilmek observability yaklaşımını güçlendirir. SEO sistemi ikisini birlikte kullanmalıdır.

Logs

Logs gerçek crawler isteklerini sağlar. URL, status, response time ve bot bilgisi temel sinyallerdir. Release ID ve template ID gibi context alanları observability değerini artırır. Ham loglar uzun süre saklanmak zorunda değildir. Aggregate ve historical metric katmanı ayrı tutulabilir.

Crawls

Internal crawl site mimarisini ve teknik durumu simüle edilmiş crawler perspektifinden gösterir. Log ile birleştirildiğinde keşfedilebilir fakat taranmayan veya taranan fakat internal olarak bulunmayan URL'ler görülür. Scheduled crawl değişiklik trendlerini takip edebilir. Template ve link depth verisi observability sistemine eklenebilir. Crawler tek başına gerçek Googlebot davranışını temsil etmez.

Search Console

Search Console indexing ve search performance katmanı ekler. Loglardan görülen crawl davranışının sonraki aşamalarını değerlendirmeye yardımcı olur. URL inspection verileri belirli incidentlerde kullanılabilir. Coverage veya indexing trendleri zaman içinde izlenebilir. Logların alternatifi değil tamamlayıcısıdır.

Analytics

Analytics teknik metriğe business context verir. Hangi URL'nin traffic, revenue veya conversion açısından kritik olduğunu gösterir. Priority URL segmenti bu veriden beslenebilir. Incident severity iş etkisine göre yükseltilebilir. Böylece teknik SEO operasyonu iş öncelikleriyle uyumlu kalır.

Alerting

Alerting baseline dışına çıkan metrikleri ilgili ekibe bildirir. 5xx spike, Googlebot request düşüşü veya priority freshness kaybı örnek olabilir. Sabit threshold yerine dinamik baseline bazı metriklerde daha iyi çalışabilir. Severity ve duration koşulları alert fatigue'i azaltır. Her alarmın owner ve playbook bağlantısı olmalıdır.

Incident Management

Incident management alarmdan düzeltmeye kadar süreci standartlaştırır. Detect, triage, owner, fix, validate, close ve postmortem adımları kullanılabilir. SEO problemi production reliability yaklaşımıyla yönetilir. Kritik migration veya crawl erişim sorunlarında bu model özellikle değerlidir. Öğrenimler guardrail ve automation'a dönüştürülmelidir.

SEO Log Baseline Nasıl Oluşturulur?

Baseline sistemin normal davranışını tanımlar ve anomali tespitinin temelini oluşturur. Normal crawl request, error rate, response time, URL space dağılımı ve priority crawl frequency birkaç haftalık veri üzerinden hesaplanabilir. Mevsimsellik veya haftanın günü etkisi varsa modele dahil edilmelidir. Yeni site veya migration döneminde baseline daha sık güncellenebilir. Tek sabit sayı yerine dağılım ve güven aralığı kullanmak daha sağlıklı sonuç üretir.

Normal Crawl Request

Günlük verified Googlebot request hacminin normal aralığı hesaplanabilir. Haftanın günleri farklı davranış gösterebilir. Median ve percentile değerler baseline olarak kullanılabilir. Ani düşüş veya artış bu aralığın dışına çıktığında alarm üretilebilir. Request sayısının başarı metriği olmadığı unutulmamalıdır.

Normal Error Rate

2xx dışı status oranlarının doğal seviyesi belirlenmelidir. 404 her sitede sıfır olmayabilir. 5xx için daha sıkı hedef kullanılabilir. URL template ve critical page segmentleri ayrı baseline'a sahip olabilir. Yeni deployment sonrası sapmalar daha kolay görülür.

Normal Response Time

Median, p95 ve p99 response time normal aralığı hesaplanabilir. Saat ve region patternleri dikkate alınmalıdır. CDN ile origin metrikleri ayrı tutulabilir. Uzun dönem yükselen baseline kapasite problemi gösterebilir. Anomali sistemi yalnız ani spike değil trend değişimini de yakalayabilir.

Normal URL-Space Dağılımı

Bot requestlerinin product, category, blog, parameter ve diğer alanlara normal dağılımı çıkarılır. Yeni bir parameter family aniden yüzde 20 pay almaya başlarsa bu davranış belirginleşir. Site lansmanı veya kampanya doğal değişiklik yaratabilir. Deployment ve business eventler dashboarda işaretlenmelidir. Bu dağılım crawl allocation monitoring için güçlü bir araçtır.

Normal Priority Crawl Frequency

Priority URL'lerin doğal crawl aralıkları template bazında ölçülür. Yeni ürün, kategori veya landing page için farklı hedefler olabilir. Days since last crawl dağılımı baseline oluşturur. Kritik sayfaların belirli yüzdesi hedef freshness aralığında tutulabilir. Bu metrik SLO sistemine dönüştürülebilir.

Crawl Anomaly Detection Nasıl Kurulur?

Crawl anomaly detection mevcut baseline dışındaki beklenmeyen crawler davranışlarını otomatik bulmayı amaçlar. Ani Googlebot düşüşü, request artışı, 404 veya 5xx spike, parameter crawl artışı ve kritik sayfalarda freshness kaybı izlenebilir. Her anomali gerçek incident değildir. Kampanya, migration veya site büyümesi doğal davranış değişikliği yaratabilir. Bu nedenle alarm sistemi bağlam, duration ve iş etkisini hesaba katmalıdır.

Ani Googlebot Düşüşü

Verified bot request hacminin baseline'ın belirgin altına düşmesi erişim veya crawl demand değişikliğini gösterebilir. WAF, robots ve server health ilk kontrol alanlarıdır. Tüm site mi yoksa belirli hostname mi etkilendiği ayrıştırılmalıdır. Search Console crawl stats ile karşılaştırma yapılabilir. Kısa süreli doğal düşüşler false positive oluşturmamalıdır.

Ani Crawl Artışı

Crawl artışı yeni URL alanı veya parameter explosion nedeniyle oluşabilir. Unique URL sayısı da artıyorsa crawler yeni space keşfediyor olabilir. Aynı URL'lere tekrar yoğunlaştıysa farklı davranış söz konusudur. URL classifier yeni patternleri göstermelidir. Business event veya migration etkisi de kontrol edilmelidir.

404 Spike

404 spike yeni kırık internal link, migration hatası veya silinen ürün grubu nedeniyle oluşabilir. URL template ve source pattern analizi yapılmalıdır. Sitemap ile karşılaştırma önemli ipucu sağlar. Critical URL veya backlink değeri olan adresler öncelik alır. Alarm olay sayısı yanında request oranını da dikkate almalıdır.

5xx Spike

5xx artışı server veya upstream incident sinyali olabilir. Deployment timestamp ile karşılaştırılmalıdır. CDN ve origin status ayrıştırılmalıdır. Severity critical URL etkisine göre yükseltilebilir. Recovery loglarla doğrulanmalıdır.

Parameter Crawl Spike

Yeni frontend özelliği çok sayıda parameter URL üretmiş olabilir. URL classifier unknown veya facet segmentinde ani artış gösterir. Googlebot unique URL ve request share aynı anda izlenmelidir. Internal crawl yeni link patternini bulabilir. Sorun doğrulanırsa URL generation veya robots stratejisi gözden geçirilir.

Kritik Sayfalarda Crawl Kaybı

Priority URL'lerin days since last crawl değeri belirlenen sınırı aşarsa uyarı üretilebilir. Tüm site requesti normal olsa bile kritik segment kayıp yaşayabilir. Sitemap ve internal link erişimi kontrol edilmelidir. URL status ve robots durumu doğrulanmalıdır. Bu alarm iş değeri odaklı observability için önemlidir.

SEO Alert Seviyeleri Nasıl Belirlenir?

Her teknik değişiklik aynı aciliyete sahip değildir. Info, Warning, High ve Critical seviyeleri kullanılarak olayların iş ve SEO riski ayrıştırılabilir. Severity hesaplamasında etkilenen URL sayısı, priority page etkisi, hata oranı ve olay süresi kullanılabilir. Çok hassas sistem sürekli bildirim gönderirse ekip zamanla alarmları görmezden gelir. Bu nedenle alert fatigue önleme, alarm tasarımının temel parçası olmalıdır.

Info

Info seviyesi aksiyon gerektirmeyen fakat kayda değer değişiklikleri gösterebilir. Yeni bot family veya küçük crawl dağılım değişimi örnek olabilir. Günlük mesaj yerine dashboard veya haftalık özet içinde tutulabilir. Gelecekte daha büyük olayın erken sinyali olarak tarihsel bağlam sağlar. Bildirim gürültüsü oluşturmamalıdır.

Warning

Warning normal aralık dışında ancak henüz yüksek iş riski oluşturmayan durumu ifade eder. Belirli parameter segmentinde artış veya p95 response time yükselişi buna örnek olabilir. Owner belirli süre içinde review yapar. Otomatik ticket açılabilir fakat acil çağrı gerekmeyebilir. Durum kötüleşirse severity yükseltilir.

High

High seviyesi belirgin SEO veya teknik etki taşıyan olaylar için kullanılabilir. Kritik template'te 5xx artışı veya sitemap URL'lerinde yaygın 404 örnek olabilir. İlgili engineering owner hızlı inceleme yapmalıdır. Incident kanalı açılması düşünülebilir. Recovery validation zorunlu tutulmalıdır.

Critical

Critical seviyesi geniş erişim kaybı veya yüksek iş değerli URL'lerin botlara kapandığı durumlar içindir. Site genelinde doğrulanmış Googlebot requestinin aniden sıfıra yaklaşması örnek olabilir. WAF yanlışlığı veya büyük 5xx incidenti bu seviyede değerlendirilebilir. Acil owner ve rollback kararı gerekebilir. Postmortem süreci tamamlanmalıdır.

Alert Fatigue Nasıl Önlenir?

Her küçük dalgalanmaya alarm üretmek ekiplerin önemli sinyalleri kaçırmasına neden olur. Baseline, minimum request, duration ve severity koşulları kullanılmalıdır. Aynı kök nedenden gelen çok sayıda alarm cluster edilebilir. Maintenance ve deployment pencereleri sisteme tanıtılabilir. Alarm sonrası aksiyon alınmıyorsa kuralın değeri yeniden değerlendirilmelidir.

SEO SLI ve SLO'ları Nasıl Oluşturulur?

SLI ölçülen hizmet göstergesini, SLO ise hedeflenen kalite seviyesini ifade eder. SEO observability içinde Googlebot Success Rate, Priority Crawl Freshness, Bot Response Time, Sitemap Health ve Crawl Waste Rate gibi göstergeler kullanılabilir. Her metriğin gerçek iş ve teknik riskiyle ilişkisi açık olmalıdır. SLO hedefleri sitenin baseline değerlerine göre gerçekçi belirlenmelidir. Amaç mükemmel sayı üretmek değil kabul edilebilir kalite sınırlarını operasyonel olarak tanımlamaktır.

Googlebot Success Rate

Verified Googlebot requestlerinin başarılı yanıt oranı temel SLI olabilir. 2xx ile beklenen 3xx davranışlarının nasıl sınıflandırılacağı açıkça tanımlanmalıdır. Critical pages için daha sıkı hedef kullanılabilir. 5xx ve 429 düşüşleri SLO ihlali oluşturabilir. Dashboard zaman penceresini net göstermelidir.

Priority Crawl Freshness

Priority URL'lerin belirli yüzdesinin hedef gün aralığında taranmış olması SLO olarak tanımlanabilir. Örneğin hızlı güncellenen sayfalar için daha kısa eşik seçilebilir. Evergreen içerikte daha uzun süre normaldir. URL importance modeli düzenli güncellenmelidir. Bu SLO tarama sayısını iş değeriyle bağlar.

Bot Response Time

P95 bot response time altyapı sağlığını izlemek için kullanılabilir. Tek sabit eşik tüm template'ler için uygun olmayabilir. API yoğun sayfalar ile statik sayfalar farklı baseline taşıyabilir. SLO ihlalinde server, cache ve upstream verileri incelenir. Human response time ile birlikte değerlendirme yapılmalıdır.

Sitemap Health

Sitemap içindeki URL'lerin beklenen status ve indexability durumunu ölçen SLI oluşturulabilir. Redirect ve 404 URL oranı çok düşük hedeflenebilir. Sitemap generation pipeline otomatik test edilebilir. Yeni yayınlanan sitemap sonrası validation çalıştırılabilir. Bu yaklaşım sitemap kalitesini sürekli korur.

Crawl Waste Rate

Crawl Waste Rate URL strategy açısından izlenebilir ancak katı SLO olarak kullanılırken dikkatli olunmalıdır. Waste tanımı business değiştikçe güncellenebilir. Hedef trend azaltımı şeklinde belirlenebilir. Priority crawl share ile birlikte izlemek daha dengeli sonuç verir. Amaç crawlerı maksimum kısıtlamak değildir.

Örnek SLO Tanımları

Örneğin doğrulanmış Googlebot requestlerinin yüzde 99,5'inin kritik template'lerde 5xx dışı yanıt alması hedeflenebilir. Priority ürün URL'lerinin yüzde 90'ının son yedi gün içinde taranmış olması başka bir SLO olabilir. Bu sayılar yalnız örnektir ve her site kendi baseline'ına göre hedef belirlemelidir. SLO ihlali incident workflow başlatabilir. Hedefler çeyreklik review sırasında yeniden değerlendirilmelidir.

SEO Incident Management Süreci Nasıl Kurulur?

SEO incident management teknik arama sorunlarını sistematik biçimde detect, triage, owner, fix, validate, close ve postmortem adımlarıyla yönetir. Özellikle büyük sitelerde crawler erişim sorunu veya migration hatası yalnız SEO ekibinin manuel takibiyle yönetilemeyecek kadar etkili olabilir. Alert sistemi olayı yakalar, triage kapsamı belirler ve doğru engineering owner'a yönlendirir. Düzeltme sonrası loglar gerçek crawler davranışının normale döndüğünü doğrular. Postmortem sonucu aynı hata türünün tekrarını azaltacak otomasyon veya guardrail oluşturulmalıdır.

Detect

Incident otomatik alarm, Search Console değişimi veya manuel gözlemle tespit edilebilir. Log anomaly detection hızlı sinyal sağlar. Olay timestamp ve ilk etkilenen metriği kaydedilmelidir. False positive ihtimali kısa kontrolden geçirilir. Gerçek incident ise triage başlatılır.

Triage

Triage olayın kapsam ve severity seviyesini belirler. Hangi hostname, template ve priority URL'lerin etkilendiği incelenir. CDN, load balancer ve origin verileri karşılaştırılır. Son deployment ve config değişiklikleri kontrol edilir. Doğru owner belirlenir.

Owner

Her incident için tek accountable owner bulunmalıdır. SEO analizi sağlayabilir ancak düzeltme DevOps, frontend veya backend ekibinde olabilir. RACI matrisi owner seçim süresini kısaltır. Communication channel ve status update sıklığı belirlenir. Kritik olaylarda product owner da bilgilendirilebilir.

Fix

Düzeltme kök nedene göre uygulanır. WAF kuralı, routing, redirect veya uygulama bugı farklı ekip gerektirir. Geçici mitigation ile kalıcı fix ayrı takip edilmelidir. Değişiklik deployment timestamp ile kaydedilir. Risk yüksekse rollback tercih edilebilir.

Validate

Validation yalnız test ortamında başarılı olmakla bitmemelidir. Production status, response time ve log eventleri kontrol edilir. Googlebot'un kritik URL'ye sonraki isteği başarılı olduğunda ek kanıt oluşur. Search Console etkisi daha sonra izlenebilir. Incident kapanmadan önce acceptance criteria karşılanmalıdır.

Close

Incident teknik metrikler normale döndüğünde ve aksiyonlar tamamlandığında kapatılır. Kalan follow up işler backloga aktarılır. Timeline ve etki kısa biçimde kaydedilir. Paydaşlara sonuç bildirilir. Critical olaylarda postmortem zorunlu olabilir.

Postmortem

Postmortem suçlu aramak yerine sistemin neden hatayı önleyemediğini anlamalıdır. Detection gecikmesi, eksik monitoring ve deployment guardrail incelenir. Yeni test veya alert ihtiyacı belirlenir. Öğrenimler dokümante edilir. Aynı hatanın tekrarını azaltacak otomasyon backloga eklenir.

Log Analizi KPI'ları Nelerdir?

Teknik SEO log dashboardu çok sayıda sayı gösterebilir, ancak operasyon için sınırlı ve anlaşılır KPI seti daha değerlidir. Verified Googlebot Requests, Unique Crawled URLs, 2xx, 3xx, 4xx ve 5xx oranları temel sağlık ölçüleridir. Crawl Waste Rate ve Priority Crawl Share allocation kalitesini, Average Response Time ve Crawl Freshness ise performans ile tazeliği gösterir. KPI'lar template ve business value segmentleriyle desteklenmelidir. Tek bir metriğin artmasını hedeflemek yerine sistemin genel davranışı birlikte değerlendirilmelidir.

Verified Googlebot Requests

Bu KPI doğrulanmış Googlebot request hacmini gösterir. Sahte user agentlar dışarıda tutulmalıdır. Günlük ve haftalık trend izlenebilir. Ani değişimler anomaly detection için kullanılır. Mutlak sayının yüksek olması tek başına başarı değildir.

Unique Crawled URLs

Unique Crawled URLs crawlerın ne kadar geniş URL alanına yayıldığını gösterir. Parameter explosion metriği yapay biçimde artırabilir. Normalize ve raw unique sayılar ayrı sunulabilir. URL space dağılımı yorum için gereklidir. Toplam request ile birlikte değerlendirilmelidir.

2xx Rate

2xx rate başarılı request oranını gösterir. Ancak noindex veya düşük değerli URL'ler de 200 dönebilir. Bu nedenle erişim sağlığı metriğidir. Critical pages için ayrı rate hesaplanabilir. Ani düşüş teknik incident sinyali olabilir.

3xx Rate

3xx rate yönlendirme trafiğinin payını gösterir. Migration sonrası geçici artış normal olabilir. Uzun dönem yüksek oran internal link cleanup ihtiyacını gösterebilir. Top redirect source listesi eklenmelidir. Redirect chain verisi crawler ile tamamlanabilir.

4xx Rate

4xx rate 404, 410, 403 ve 429 gibi farklı durumları içerdiği için alt kategorilere ayrılmalıdır. 404 ile 429 aynı teknik anlamı taşımaz. URL template ve bot type kırılımı gerekir. Sitemap 404 oranı ayrıca izlenebilir. Critical URL 4xx durumları yüksek öncelik almalıdır.

5xx Rate

5xx rate server reliability için önemli KPI'dır. Site geneli ve critical page segmenti ayrı hesaplanabilir. Pencere ve minimum request koşulu tanımlanmalıdır. Deployment sonrası değişim izlenmelidir. SLO ihlali incident workflow başlatabilir.

Crawl Waste Rate

Crawl Waste Rate düşük değerli olarak tanımlanan URL segmentlerinin request payını gösterir. Tanımın düzenli review edilmesi gerekir. Parameter, search ve eski redirect alanları örnek olabilir. Priority Crawl Share ile birlikte yorumlanmalıdır. Tek hedef oranı sıfıra indirmek değildir.

Priority Crawl Share

Bu KPI stratejik URL'lerin toplam crawler requestleri içindeki payını gösterir. Business value segmentasyonu gerektirir. Trend artışı olumlu olabilir fakat toplam crawl düşüşüyle birlikte değerlendirilmelidir. Template farklılıkları doğal davranış yaratabilir. Quarterly review sırasında target güncellenebilir.

Average Response Time

Average response time genel sunucu hızını gösterir. Median ve p95 ile tamamlanması önerilir. Bot requestleri URL space bazında karşılaştırılabilir. Altyapı değişikliklerinin etkisi izlenebilir. Çok yüksek response time crawl kapasitesi açısından dikkat gerektirir.

Crawl Freshness

Crawl Freshness önemli URL'lerin ne kadar yakın zamanda tekrar ziyaret edildiğini gösterir. Days since last crawl temel metriktir. Priority sayfalar ve update frequency ile birlikte yorumlanır. Yeni içerik için first crawl delay ayrı KPI olabilir. Her URL'nin günlük taranması hedeflenmemelidir.

Teknik SEO Log Dashboard'unda Neler Bulunmalıdır?

İyi dashboard çok grafik içeren ekran değil doğru sorulara hızlı yanıt veren araçtır. Crawl trend, status code distribution, URL space distribution, top crawled URLs, least crawled priority URLs, error listesi, response time, bot type ve anomaly bölümleri temel yapı olabilir. Filtreler hostname, date, template, verified bot ve release bazında çalışmalıdır. Dashboard ham log satırını gerektiğinde drill down ile gösterebilmelidir. İş ekipleri için priority ve conversion bağlamı eklenmesi teknik metriklerin anlamını güçlendirir.

Crawl Trend

Crawl Trend günlük request ve unique URL sayılarını gösterir. Verified bots ayrı seri olarak sunulmalıdır. Deployment ve migration tarihleri grafik üzerinde işaretlenebilir. Ani değişimler anomaly marker ile gösterilebilir. Uzun dönem seasonal patternler böylece kolayca görülür.

Status Code Distribution

Status dağılımı 2xx, 3xx, 4xx ve 5xx oranlarını zaman içinde gösterir. 404, 429 ve 5xx ayrı seriler olmalıdır. URL template filtresi kök neden analizini hızlandırır. Critical segment için ikinci görünüm eklenebilir. Yüzde ve mutlak sayı birlikte gösterilmelidir.

URL Space Distribution

URL space dağılımı crawler allocation'ın en anlaşılır görünümlerinden biridir. Product, category, blog, facet ve search gibi segmentler gösterilebilir. Unknown segment artışı yeni pattern keşfine yardımcı olur. Business priority rengi eklenebilir. Trend değişimi teknik veya ürün değişikliğiyle ilişkilendirilebilir.

Top Crawled URLs

En çok taranan URL listesi beklenmeyen tekrar davranışını gösterebilir. Homepage veya sitemap gibi kaynaklar doğal olarak yüksek olabilir. Düşük değerli parameter URL'nin listenin üstünde olması inceleme gerektirir. Status ve template bilgisi yanında gösterilmelidir. Normalize ve raw URL görünümü sunulabilir.

Least Crawled Priority URLs

Priority listesinde yer alıp uzun süredir taranmayan URL'ler ayrı widget olarak gösterilebilir. Days since last crawl sırasına göre listelenebilir. Sitemap ve internal crawl status eklenebilir. İş owner bilgisi aksiyon sürecini hızlandırır. Bu görünüm crawler hacminden çok iş değerine odaklanır.

Error URLs

404, 429 ve 5xx URL'ler frequency ve age ile listelenmelidir. Son görülen tarih önemli alandır. Sitemap veya internal link kaynağı etiketi eklenebilir. Critical page işareti severity belirler. Export fonksiyonu engineering backlog için faydalıdır.

Response Time

Median, p95 ve p99 response time grafikleri bulunmalıdır. URL template ve cache status filtreleri eklenebilir. Slowest URL listesi ayrı gösterilebilir. Deployment marker kök neden analizini kolaylaştırır. Bot ve human infrastructure metriği birlikte karşılaştırılabilir.

Bot Type

Bot type dağılımı Smartphone Googlebot, image crawlers ve diğer doğrulanmış bot türlerini ayırır. Sahte veya unknown botlar ayrı tutulmalıdır. Her bot ailesinin request trendi gösterilebilir. Resource type filtresi eklenebilir. SEO kararları ilgili crawler family üzerinden verilmelidir.

Crawl Anomalies

Anomaly paneli detection sisteminin bulduğu olayları tarih ve severity ile listeler. İlgili metrik, URL space ve owner bilgisi görünür olmalıdır. Acknowledged, investigating ve resolved durumları kullanılabilir. Incident bağlantısı eklenebilir. Böylece dashboard yalnız rapor değil operasyon aracı haline gelir.

Log Retention Politikası Nasıl Belirlenmelidir?

Log retention, analiz ihtiyacı ile depolama, güvenlik ve gizlilik maliyetleri arasında denge kurmalıdır. Kısa audit için birkaç haftalık veri yeterli olabilirken migration veya seasonal trend analizi daha uzun süre gerektirir. Ham logların yıllarca saklanması her zaman gerekli değildir. Aggregate metrikler ve anonimleştirilmiş historical tablolar daha uzun süre tutulabilir. Rotation, compression ve archive politikası DevOps, Security ve SEO ekiplerinin ortak kararı olmalıdır.

Kısa Süreli Audit

Kısa süreli audit için 14 ile 30 günlük veri birçok soruya yanıt verebilir. Ancak düşük frequency URL'lerde bu pencere yetersiz olabilir. Site büyüklüğü ve update sıklığı dikkate alınmalıdır. Migration analizi için daha uzun tarih gerekebilir. Veri eksikse sonuçlar açık biçimde sınırlandırılmalıdır.

30-90 Günlük Operasyonel Analiz

30 ile 90 günlük veri baseline ve trend analizi için daha güçlüdür. Haftalık patternler ve deployment etkileri görülebilir. Crawl freshness hesapları daha anlamlı hale gelir. Depolama maliyeti ham event hacmine göre planlanmalıdır. Eski ham kayıtlar aggregate forma dönüştürülebilir.

Yıllık Trend Analizi

Yıllık trend seasonal davranış ve büyük mimari değişiklikleri değerlendirmeyi sağlar. Ham IP ve full query string gibi hassas alanların bir yıl saklanması gerekmeyebilir. Günlük aggregate bot request, status ve URL space metrikleri daha güvenli olabilir. Migration milestone ve major release bilgileri saklanmalıdır. Retention politikası hukuk gereksinimleriyle uyumlu olmalıdır.

Log Rotation

Log rotation dosyaların kontrolsüz büyümesini önler. Günlük veya boyut bazlı rotation uygulanabilir. Pipeline yeni dosyaları otomatik ingest etmelidir. Rotation sırasında event kaybı oluşmadığı doğrulanmalıdır. Dosya isimlendirme standardı operasyonu kolaylaştırır.

Compression

Eski logların sıkıştırılması depolama maliyetini azaltabilir. Text tabanlı loglar yüksek oranlarda sıkıştırılabilir. Analysis pipeline gerektiğinde compressed formatları okuyabilir. Çok sık erişilen sıcak veri ayrı katmanda tutulabilir. Archive politikası performans ve maliyet dengesine göre tasarlanmalıdır.

Archive

Archive uzun dönem tarihsel veri için kullanılabilir. Ham log yerine gerekli aggregate tabloların arşivlenmesi daha güvenli olabilir. Erişim sıklığı düşük olduğu için daha ucuz storage tercih edilebilir. Data catalog hangi dönemin nerede tutulduğunu göstermelidir. Silme tarihi policy içinde açıkça tanımlanmalıdır.

Log Dosyalarında Veri Gizliliği Nasıl Yönetilmelidir?

Log dosyaları IP adresi ve query string gibi hassas veriler içerebilir. SEO analizi yapılması bu alanların sınırsız paylaşılması gerektiği anlamına gelmez. Data minimization prensibiyle yalnız gerekli alanlar tutulmalı ve kişisel bilgi içeren değerler maskelenmelidir. Access control, retention ve audit kayıtları kurumsal güvenlik politikasıyla uyumlu olmalıdır. SEO ekibine read only ve filtrelenmiş dataset sağlamak çoğu durumda yeterlidir.

IP Adresleri

IP adresleri bot doğrulama için gerekebilir ancak sürekli dashboardda ham şekilde gösterilmesi şart değildir. Verification pipeline sonucunda bot status üretilebilir. Ham IP erişimi sınırlı role verilebilir. Gerekirse hash veya kısmi masking uygulanabilir. Retention süresi güvenlik ve hukuk ekipleriyle belirlenmelidir.

Query String'ler

Query string kullanıcı tarafından girilen arama terimi veya token içerebilir. SEO analizi için tüm değerlerin saklanması çoğu zaman gereksizdir. Parameter name tutulup value maskelenebilir. Search query metni aggregate kategoriye dönüştürülebilir. Sensitive parameter listesi pipeline içinde otomatik temizlenmelidir.

Kişisel Veriler

URL içinde e-posta, müşteri numarası veya başka kişisel veri oluşması log riskini artırır. Öncelikle uygulama bu tür veriyi URL'ye koymamalıdır. Pipeline ingestion sırasında detection ve masking uygulanabilir. Security ekibine alarm üretilebilir. SEO datasetinde kişisel veri bulunmaması hedeflenmelidir.

Data Minimization

Data minimization yalnız analiz için gerekli bilgiyi tutmayı amaçlar. SEO için çoğu zaman timestamp, normalized URL, status, bot type ve response time yeterlidir. Ham headers veya cookie verisine ihtiyaç yoktur. Dataset ne kadar sade olursa erişim riski ve bakım maliyeti o kadar azalır. Gereksiz alanlar ingestion öncesi çıkarılabilir.

Access Control

Log datasetine rol bazlı erişim verilmelidir. SEO read only dashboard kullanabilir. Security ve DevOps daha geniş ham erişime sahip olabilir. Sensitive export işlemleri audit log ile kaydedilebilir. Yetki matrisi periyodik olarak gözden geçirilmelidir.

Retention

Hassas alanlar için retention süresi teknik SEO ihtiyacından daha kısa tutulabilir. Aggregate metrikler daha uzun saklanabilir. Otomatik silme politikası uygulanmalıdır. Backup ve archive katmanları da aynı kurala uymalıdır. Yasal gereksinimler kurum politikasıyla birlikte değerlendirilmelidir.

SEO Ekibine Production Log Erişimi Nasıl Verilmelidir?

SEO ekibinin production sunuculara doğrudan yönetici erişimi alması çoğu kurumsal yapı için gerekli değildir. Read only dashboard, filtrelenmiş dataset veya güvenli export analiz ihtiyacını karşılayabilir. Yetki matrisi hangi rolün hangi alanı görebileceğini tanımlamalıdır. Ham IP ve hassas query string alanları sınırlandırılabilir. Bu model SEO görünürlüğünü korurken güvenlik riskini azaltır.

Read-Only Access

Read only erişim veri değiştirme riskini ortadan kaldırır. SQL warehouse veya observability platformunda yalnız select izni verilebilir. SEO analyst yalnız gerekli schema'yı görmelidir. Production configuration erişimi ayrı tutulur. Erişim logları güvenlik açısından kayıt altına alınabilir.

Filtered Dataset

Filtered dataset yalnız verified bots ve SEO için gerekli alanları içerebilir. Human requestler ve sensitive parameter değerleri çıkarılabilir. Bu yaklaşım analiz performansını da artırır. Raw dataset güvenli katmanda kalır. Data team transform pipeline'ı yönetebilir.

Dashboard

Dashboard birçok SEO kullanıcısı için ham log erişiminden daha uygundur. Standard KPI ve filtreler hazır sunulur. Drill down ile gerekli URL detayı görülebilir. Export sınırları uygulanabilir. Role based view hassas alanların görünmesini önler.

Güvenli Export

Ad hoc audit için tarih ve bot filtresi uygulanmış export hazırlanabilir. Dosya güvenli storage üzerinden paylaşılmalıdır. Retention ve download izinleri sınırlanabilir. Sensitive alanlar önceden maskelenmelidir. Export üretimi tekrarlanabilir query veya job üzerinden yapılmalıdır.

Yetki Matrisi

Yetki matrisi DevOps, Security, Data, SEO ve Developer rollerinin erişim seviyesini tanımlar. Ham log, transformed data ve dashboard ayrı katmanlar olabilir. Least privilege prensibi uygulanmalıdır. Rol değişikliklerinde erişimler güncellenmelidir. Periyodik audit güvenliği korur.

Log Analizi RACI Matrisi Nasıl Oluşturulur?

Log analizi tek bir ekibin işi değildir. DevOps log üretimi ve retention, Security erişim ve gizlilik, Data Team parsing ve storage, SEO segmentasyon ve analiz, Developer teknik düzeltme, Product Owner ise önceliklendirme rolü üstlenebilir. Her süreç için Responsible, Accountable, Consulted ve Informed rollerinin açık olması incident sırasında zaman kaybını azaltır. Özellikle büyük organizasyonlarda veri var ama owner yok problemi sık görülür. RACI matrisi log pipeline'ı teknik araç olmaktan çıkarıp sürdürülebilir operasyon sürecine dönüştürür.

DevOps

DevOps altyapı loglarının üretimi, rotation, forwarding ve retention süreçlerinde temel rol oynar. SEO ekibinin hangi katmanda hangi kayıtların bulunduğunu anlamasına yardımcı olur. Schema değişiklikleri önceden bildirilmelidir. Pipeline health metrikleri izlenebilir. Incident sırasında CDN veya origin kaynaklı sorunu teşhis eder.

log üretimi

Gerekli alanların access log formatında bulunması DevOps sorumluluğunda olabilir. Timestamp, status, user agent ve response time gibi alanlar standartlaştırılır. Sensitive veriler gerekirse ingestion öncesi maskelenir. Log format değişikliği versionlanmalıdır. Test ortamında örnek kayıt doğrulaması yapılabilir.

retention

DevOps storage ve rotation politikalarını uygulayabilir. SEO ihtiyacıyla güvenlik gereksinimleri birlikte değerlendirilir. Ham log ile aggregate retention süreleri farklı olabilir. Otomatik silme jobları kurulabilir. Kapasite ve maliyet düzenli gözden geçirilir.

pipeline

Log forwarding pipeline event kaybı olmadan çalışmalıdır. Queue, storage ve transformation health izlenebilir. Schema değişiminde downstream sistem uyarılmalıdır. Retry ve dead letter mekanizmaları kullanılabilir. Data freshness dashboardu pipeline sorunlarını erken gösterir.

Security

Security ekibi log erişimi ve kişisel veri kontrolünde önemli rol taşır. IP ve query string gibi alanların nasıl saklanacağını belirler. Bot doğrulama ve WAF kurallarıyla SEO ekipleri arasında koordinasyon sağlar. Read only ve filtered access modeli oluşturabilir. Incident sırasında yanlış güvenlik kuralının crawlerı etkileyip etkilemediğini inceler.

erişim

Role based access ve least privilege uygulanmalıdır. Ham log yalnız gerekli kişiler tarafından görülebilir. SEO dashboard hassas alanları maskeleyebilir. Export işlemleri audit edilebilir. Erişim talepleri belirli onay sürecinden geçebilir.

gizlilik

Loglarda kişisel veri bulunma riski düzenli kontrol edilmelidir. Sensitive query parameter listesi tutulabilir. Masking ve deletion kuralları uygulanır. Retention hukuk politikasıyla uyumlu hale getirilir. SEO analiz ihtiyacı kişisel veri toplamayı gerekçelendirmemelidir.

Data Team

Data Team raw logları analiz edilebilir tablolara dönüştürmede rol alabilir. Parsing, schema normalization ve storage katmanını yönetir. URL classification veya bot verification sonuçları data mart içinde sunulabilir. Dashboard performansı için aggregate tablolar oluşturabilir. Data quality testleri pipeline güvenilirliğini artırır.

parsing

Farklı log formatları ortak şemaya dönüştürülmelidir. Parser hatalı satırları ayrı queue'ya gönderebilir. Field type ve timezone normalizasyonu uygulanır. Raw source korunarak debug yapılabilir. Parser version metadata olarak tutulmalıdır.

storage

Data warehouse veya lake yapısı sorgu ve retention ihtiyacına göre seçilebilir. Partitioning tarih ve host bazında yapılabilir. Büyük event tablosu yanında günlük aggregate oluşturulabilir. Sensitive alanlar ayrı güvenlik katmanında tutulur. Maliyet ve query performansı düzenli izlenir.

SEO

SEO ekibi URL space kurallarını, priority segmentleri ve analiz sorularını tanımlar. Log metriğini Search Console, sitemap ve crawler verisiyle birleştirir. Bulguları teknik aksiyona dönüştürür. Business value ile crawl metriğini ilişkilendirir. Alert ve SLO kurallarının SEO anlamını belirler.

segmentasyon

Product, category, blog, filter ve search gibi URL class kuralları SEO ekibi tarafından tanımlanabilir. Unknown URL'ler düzenli gözden geçirilir. Yeni site özellikleri classifier'a eklenir. Segment business value etiketiyle zenginleştirilir. Kurallar versionlanmalıdır.

analiz

SEO ekibi request, status, freshness ve crawl allocation metriklerini yorumlar. Tek günlük değişim yerine trend kullanır. Crawling ile indexing sonuçlarını karıştırmaz. Crawler ve Search Console verisiyle hipotezi doğrular. Teknik bulguyu anlaşılır backlog maddesine dönüştürür.

aksiyon

Bulgular owner, impact ve acceptance criteria ile backloga eklenmelidir. Örneğin yüksek frequency sitemap 404 için sitemap generator fix istenir. Düşük değerli facet crawl için URL strategy review açılır. Düzeltme sonrasında log validation yapılır. Bu kapanış adımı sürdürülebilir SEO için kritiktir.

Developer

Developer routing, template, internal link veya uygulama kaynaklı teknik sorunları düzeltir. Log bulgusunun gerçek kod yoluyla ilişkisini analiz eder. Unit ve integration test ekleyebilir. Deployment sonrası validation SEO ve monitoring verisiyle yapılır. Tekrarlayan hataları guardrail ile önlemeye çalışır.

teknik düzeltme

Düzeltme spesifik kök nedene yönelik olmalıdır. 404 için her zaman redirect eklemek doğru değildir. URL generator, route veya internal link kaynağı düzeltilmesi gerekebilir. Change test ortamında doğrulanır. Production logları sonuç kontrolünde kullanılır.

Product Owner

Product Owner teknik SEO backlogunu iş hedefleriyle önceliklendirir. Hangi URL alanının ticari olarak kritik olduğunu belirtir. Facet veya search functionality değişikliklerinde kullanıcı gereksinimlerini açıklar. Teknik çözümün business etkisini değerlendirir. Böylece crawl optimizasyonu kullanıcı deneyimini yanlışlıkla bozmaz.

önceliklendirme

Her teknik hata aynı iş etkisine sahip değildir. Priority scoring user, revenue, SEO traffic ve engineering effort ile yapılabilir. Yüksek crawl waste ama düşük riskli alan, kritik 5xx probleminin gerisinde kalabilir. Roadmap kapasitesi görünür biçimde planlanır. Sonuç metrikleri review edilir.

Log Analizi İçin Hangi Araçlar Kullanılabilir?

Log analizi için tek doğru araç yoktur. Hazır log analiz yazılımları hızlı audit için pratik olabilirken Elastic tabanlı pipeline, kurumsal observability platformları, cloud data warehouse, Python, SQL ve komut satırı araçları daha özelleştirilebilir sistemler sunar. Araç seçimi veri hacmi, ekip yetkinliği, güvenlik ve otomasyon ihtiyacına göre yapılmalıdır. Küçük sitede birkaç milyon satırı Python ile analiz etmek yeterliyken çok büyük platformda dağıtık veri altyapısı gerekir. En önemli nokta aracın markası değil analizin tekrar üretilebilir ve güvenilir olmasıdır.

Screaming Frog Log File Analyser

Screaming Frog Log File Analyser hazır arayüz üzerinden log audit yapmak için kullanılabilen araçlardan biridir. Özellikle kısa dönem export üzerinde bot hit, status ve URL davranışını hızlı incelemek isteyen ekipler için pratik olabilir. Ancak çok büyük veya sürekli monitoring gerektiren sistemlerde özel pipeline ihtiyacı doğabilir. Araç çıktıları yine Search Console ve crawler verileriyle birlikte yorumlanmalıdır. Hangi çözüm kullanılırsa kullanılsın bot doğrulama ve veri gizliliği süreçleri ihmal edilmemelidir.

Elastic/Log Pipeline Yaklaşımları

Elastic tabanlı veya benzer log pipeline sistemleri büyük veri akışını merkezi biçimde toplamaya yardımcı olabilir. Parsing ve enrichment adımlarında verified bot, URL class ve template ID eklenebilir. Dashboard ve alerting katmanı aynı ekosistem içinde kurulabilir. Ancak storage maliyeti ve schema governance planlanmalıdır. SEO kullanım senaryosu genel observability yapısıyla entegre edilebilir.

Kurumsal Observability Platformları

Kurumsal observability platformları application, infrastructure ve log verilerini bir arada izlemeyi sağlar. SEO için bot segmenti ve URL classification özel dashboard olarak oluşturulabilir. Release marker ve incident management entegrasyonu önemli avantaj sağlar. Ham production data erişimi role based yönetilebilir. Mevcut altyapı zaten böyle bir platform kullanıyorsa ayrı SEO sistemi kurmak yerine entegrasyon daha verimli olabilir.

Cloud Data Warehouse

Cloud data warehouse büyük log datasetlerini SQL ile analiz etmek için uygundur. Date partition ve URL class alanları sorgu maliyetini azaltabilir. Search Console ve analytics tabloları aynı ortamda bulunduğunda cross data analiz kolaylaşır. Scheduled query ile günlük KPI tabloları oluşturulabilir. Güvenlik ve retention politikası warehouse katmanında uygulanmalıdır.

Python

Python parsing, bot verification, URL classification ve otomatik raporlama için kullanışlıdır. pandas orta ölçekli datasetlerde hızlı prototip sağlar. Büyük veri hacminde chunk processing veya warehouse bağlantısı kullanılabilir. Scriptler version control içinde tutulmalıdır. Tek seferlik notebook yerine tekrarlanabilir pipeline tercih edilmelidir.

SQL

SQL büyük yapılandırılmış log tablolarında aggregation ve segmentasyon için güçlüdür. Crawl frequency, status distribution ve freshness sorguları kolayca yazılabilir. Window functions URL bazlı crawl interval hesaplamasında yararlıdır. Scheduled queries dashboard tablolarını besleyebilir. Query tanımları version control altında tutulabilir.

Komut Satırı Araçları

grep, awk, sed ve benzeri araçlar hızlı server incelemesi için yararlı olabilir. Küçük dosyalarda belirli user agent veya status patterni saniyeler içinde filtrelenebilir. Ancak tekrarlanabilir kurumsal raporlama için tek başlarına yeterli olmayabilir. Komutlar script dosyasında saklanarak reproducibility artırılabilir. Hassas production erişimi güvenlik politikalarına uygun yapılmalıdır.

Log Analizi İçin En İyi Programlama Dili Hangisidir?

Log analizi için tek bir en iyi programlama dili yoktur. Python parsing ve otomasyon, SQL büyük veri sorguları, Shell hızlı server analizi, JavaScript veya TypeScript ise dashboard ve servis geliştirme açısından güçlü olabilir. Seçim veri hacmi, mevcut altyapı ve ekip yetkinliğine göre yapılmalıdır. En önemli konu analiz sürecinin tekrar üretilebilir olmasıdır. Bir defalık çalışan karmaşık script yerine düzenli ingest, test, monitoring ve reporting içeren sade pipeline daha değerlidir.

Python

Python SEO log analizi için yaygın ve erişilebilir seçeneklerden biridir. Regex, dataframe ve HTTP kütüphaneleri parsing ile veri birleştirme işlerini kolaylaştırır. Bot verification ve API entegrasyonu otomatikleştirilebilir. Script scheduled job olarak çalıştırılabilir. Büyük veri hacminde memory kullanımı için dikkatli tasarım gerekir.

parsing

Regex veya hazır parser kütüphaneleri farklı log formatlarını ayrıştırabilir. Her alanın type kontrolü yapılmalıdır. Hatalı satırlar kaybolmak yerine ayrı error dosyasına yazılabilir. Format değişiklikleri testlerle yakalanmalıdır. Parser version bilgisi dataset içinde tutulabilir.

pandas

pandas orta ölçekli veri analizi için hızlı geliştirme sağlar. Groupby ile status ve URL class aggregation yapılabilir. Timestamp üzerinden freshness hesaplanabilir. Çok büyük loglarda chunk reading kullanılmalıdır. Production pipeline için data quality testleri eklenmelidir.

otomasyon

Python scriptleri günlük log ingest ve report üretiminde kullanılabilir. Scheduler veya workflow sistemiyle belirli aralıkta çalıştırılabilir. Başarısız job alarm üretebilir. Çıktılar warehouse veya dashboard sistemine yazılabilir. Manuel dosya işleme ihtiyacı azaltılır.

API

Search Console veya diğer veri kaynakları API üzerinden log datasetine eklenebilir. Rate limit ve authentication güvenli biçimde yönetilmelidir. URL seviyesinde join yapılabilir. API snapshot tarihi saklanmalıdır. Böylece veri kaynaklarının zaman farkı analizde dikkate alınır.

SQL

SQL yapılandırılmış büyük log datasetlerinde güçlü analiz sağlar. URL class, bot type ve status gibi alanlar üzerinden hızlı aggregation yapılabilir. Window function crawl interval ve last crawl hesaplarında kullanışlıdır. Materialized table veya scheduled query dashboard performansını iyileştirebilir. SQL sorgularının test ve version kontrolü yapılması önemlidir.

büyük veri sorguları

Milyarlarca log satırında local Python yerine warehouse SQL daha verimli olabilir. Date partition ve bot filter ile taranan veri azaltılır. Approximate functions bazı dashboard metriklerinde maliyeti düşürebilir. Query cost monitoring uygulanmalıdır. Ham event yerine aggregate daily table kullanılabilir.

Shell/AWK

Shell ve AWK hızlı ad hoc analiz için çok etkilidir. Belirli user agent, status veya URL patternlerini filtrelemek kolaydır. Büyük text dosyalarını memory'ye almadan işleyebilir. Ancak karmaşık cross data join işlemleri için uygun olmayabilir. Production scriptlerinde hata kontrolü ve dokümantasyon gereklidir.

hızlı server analizi

Incident sırasında son birkaç dakikalık logu hızlı incelemek gerekebilir. grep ve awk ile 5xx veya Googlebot patterni filtrelenebilir. Bu yöntem anlık triage için değerlidir. Kalıcı KPI hesapları merkezi pipeline üzerinden yapılmalıdır. Production terminal erişimi güvenlik kurallarına bağlı olmalıdır.

JavaScript/TypeScript

JavaScript veya TypeScript dashboard backend, event processing veya internal tool geliştirme için kullanılabilir. Mevcut ekip Node.js ekosistemine hakimse ayrı dil öğrenme ihtiyacını azaltır. Stream processing yapılabilir. Bot verification servisleri geliştirilebilir. Data analysis için SQL veya Python ile birlikte hibrit model kullanılabilir.

dashboard ve servis geliştirme

Internal SEO observability dashboardu TypeScript tabanlı servisle geliştirilebilir. API warehouse sorgularını frontend'e sunabilir. Role based access uygulanabilir. Alert management workflow aynı servise entegre edilebilir. Backend dilinden çok data model ve reliability önemlidir.

Dilden Daha Önemli Olan Tekrarlanabilir Pipeline'dır

Bir analiz notebookta bir kez çalışıyor ama ertesi ay kimse yeniden üretemiyorsa sürdürülebilir değildir. Pipeline ingest, parsing, verification, classification, aggregation ve reporting adımlarını açık biçimde tanımlamalıdır. Version control, test ve monitoring bulunmalıdır. Veri kaynağı değiştiğinde hata görünür olmalıdır. Sürdürülebilir SEO İçin Log Dosyası Analizi açısından teknoloji seçiminden daha kritik olan bu operasyonel güvenilirliktir.

Python ile SEO Log Analizinde Neler Otomatikleştirilebilir?

Python log parsing, bot filtering, URL pattern classification, status aggregation, crawl frequency, anomaly detection, Search Console merge ve otomatik raporlama gibi pek çok işi otomatikleştirebilir. En iyi sonuç için scriptler küçük ve test edilebilir modüllere ayrılmalıdır. URL sınıflandırma kuralları config dosyasında tutulabilir. Bot verification sonucu cache edilerek DNS yükü azaltılabilir. Sonuçlar manuel Excel dosyası yerine merkezi tablo veya dashboarda yazılabilir.

Log Parsing

Ham log satırları yapılandırılmış kolonlara dönüştürülebilir. Apache, Nginx veya JSON kaynakları için farklı parser adapter kullanılabilir. Hatalı event oranı data quality metriği olarak izlenebilir. Timestamp ve URL normalization aynı pipeline içinde yapılabilir. Raw satır gerektiğinde debug için saklanabilir.

Bot Filtering

User agent adayları otomatik sınıflandırılabilir. IP doğrulama servisi verified bot status üretir. Sonuç belirli süre cache edilir. Human ve unknown trafiği ayrı datasetlere ayrılabilir. Dashboard yalnız verified crawler verisi kullanabilir.

URL Pattern Classification

Regex ve route kurallarıyla product, category, blog, facet ve search segmentleri üretilebilir. Unknown URL patternleri ayrı raporlanabilir. Kurallar versionlanmalıdır. Yeni ürün özelliği çıktığında classifier güncellenir. Bu otomasyon büyük URL space analizini mümkün kılar.

Status Code Aggregation

Günlük 2xx, 3xx, 4xx ve 5xx oranları otomatik hesaplanabilir. Template ve hostname kırılımları oluşturulabilir. Top error URLs ayrı çıktı üretir. Önceki dönemle delta hesaplanabilir. Threshold aşılırsa alert servisine mesaj gönderilebilir.

Crawl Frequency

URL bazında request count, first crawl, last crawl ve average interval otomatik hesaplanabilir. Template seviyesinde percentile dağılımları çıkarılabilir. Priority URL listesiyle join yapılabilir. Freshness SLO kontrolü otomatik çalışır. Dashboard güncel metrikleri gösterir.

Anomaly Detection

Basit rolling average veya daha gelişmiş istatistiksel yöntemlerle anomaly detection kurulabilir. Amaç her küçük değişimi işaretlemek değildir. Minimum request ve business severity kuralları kullanılmalıdır. Yeni parameter pattern spike otomatik bulunabilir. İnsan review kararı sistemin parçası olarak kalmalıdır.

Search Console Data Merge

Search Console API verisi belirli aralıklarla alınabilir. Normalize URL üzerinden log datasetine join yapılır. Crawled ve indexed segmentleri üretilebilir. API date ve data freshness bilgisi saklanmalıdır. Eksik veri yanlışlıkla not indexed olarak yorumlanmamalıdır.

Otomatik Raporlama

Haftalık veya aylık rapor otomatik oluşturulabilir. KPI değişimleri, top anomalies ve priority URL sorunları özetlenebilir. Rapor yalnız sayı listesi değil aksiyon maddeleri içermelidir. Teknik detay dashboard linkiyle desteklenebilir. İnsan analistin yorum bölümü rapor kalitesini artırır.

Open Source ve İşbirliği Log Analizini Nasıl Geliştirebilir?

Açık kaynak yaklaşımı log parsing, bot verification, URL classification ve dashboard bileşenlerinin ekipler arasında paylaşılmasını kolaylaştırabilir. Ortak parser veya anomaly detector farklı projelerde yeniden kullanılabilir. Community documentation teknik SEO ile yazılım ekipleri arasındaki bilgi açığını azaltır. Ancak production logların kendisi açık kaynak yapılmamalı ve veri gizliliği korunmalıdır. Paylaşılabilecek olan kod, anonim örnek veri ve metodolojidir.

Açık Kaynak Log Parser

Farklı Apache, Nginx veya CDN formatlarını ortak şemaya dönüştüren parser yararlı bir topluluk projesi olabilir. Unit test örnekleri gerçek olmayan anonim satırlarla hazırlanabilir. Parser extension sistemi yeni format eklemeyi kolaylaştırabilir. Hassas alan masking özelliği dahil edilebilir. Böylece kullanıcılar güvenli başlangıç altyapısına sahip olur.

Dashboard

Açık kaynak dashboard template'i crawl trend, status ve URL space görünümleri sunabilir. Kullanıcı kendi warehouse veya local datasetini bağlayabilir. Varsayılan grafikler metodoloji açıklaması içermelidir. Sensitive data client tarafında açığa çıkmamalıdır. Dashboard community feedback ile geliştirilebilir.

Crawl Anomaly Detector

Anomaly detector basit baseline yaklaşımıyla başlanabilir. Request drop, 5xx spike ve parameter growth kuralları config üzerinden ayarlanabilir. Alert output webhook veya e-posta entegrasyonuna gönderilebilir. False positive azaltmak için duration ve request threshold seçenekleri sunulabilir. Kullanıcılar kendi örneklerini contribution olarak paylaşabilir.

Bot Verification Tool

Bot verification aracı reverse ve forward DNS kontrollerini otomatikleştirebilir. Cache sistemi DNS sorgu sayısını azaltır. Verification timestamp ve result döndürülür. Security best practice dokümantasyonu eklenebilir. Araç user agent iddiasını tek başına güvenilir kabul etmemelidir.

URL Classifier

URL classifier regex veya config tabanlı pattern sistemi kullanabilir. Product, blog, search ve facet gibi örnek sınıflar tanımlanabilir. Kullanıcı kendi route kurallarını ekleyebilir. Unknown URL listesi otomatik raporlanabilir. Privacy açısından full query değerleri maskelenebilir.

Community Documentation

İyi dokümantasyon aracın kendisi kadar önemlidir. Crawling, indexing ve ranking farkı açıkça anlatılmalıdır. Crawl budget'ın her site için kritik olmadığı belirtilmelidir. Örnek SQL ve Python kodları anonim veri üzerinde gösterilebilir. Bu yaklaşım teknik SEO bilgisini daha erişilebilir hale getirir.

Diyarbakır Yazılım Topluluğu Gibi Yerel Topluluklarda SEO Log Analizi Nasıl Çalışılabilir?

Yerel yazılım toplulukları teknik SEO ile backend, DevOps ve veri mühendisliğini bir araya getiren uygulamalı çalışmalar için güçlü ortamlar sağlayabilir. Access log parsing, Googlebot doğrulama, SQL sorguları ve SEO observability dashboardları ortak proje konusu olabilir. Bu tür çalışmalar yalnız SEO uzmanlarının değil yazılımcı olmak isteyen katılımcıların HTTP, DNS, Linux ve veri analizi becerilerini de geliştirir. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresine bakabilirsiniz. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about sayfasını ziyaret edebilirsiniz.

Teknik SEO Workshop

Workshop gerçek olmayan örnek access log datasetleri üzerinden yürütülebilir. Katılımcılar verified bot, status code ve URL space analizleri yapabilir. Crawler ve Search Console benzeri örnek tablolarla veri join pratiği uygulanabilir. Amaç araç ezberlemek değil crawling davranışını anlamaktır. Son bölümde bulgular teknik backlog maddelerine dönüştürülebilir.

Python ile Access Log Analizi

Python atölyesinde log parsing ve dataframe işlemleri öğretilebilir. Katılımcılar user agent filtresi, status aggregation ve crawl frequency hesaplayabilir. Regex ile URL classification uygulaması yapılabilir. Örnek veri anonim ve kişisel bilgi içermeyen biçimde hazırlanmalıdır. Çıktı basit dashboard veya CSV rapora dönüştürülebilir.

DevOps + SEO Ortak Oturumu

DevOps ve SEO ekiplerinin aynı oturumda bulunması altyapı ile arama davranışı arasındaki ilişkiyi görünür kılar. CDN, WAF ve origin katmanlarının log farkları anlatılabilir. 403, 429 ve 5xx örnekleri üzerinden incident senaryosu çalışılabilir. SEO ekibi hangi alanlara ihtiyaç duyduğunu, DevOps ise güvenlik ve retention sınırlarını açıklayabilir. Bu ortak dil gerçek projelerde iletişim maliyetini azaltır.

Open Source SEO Observability Projesi

Topluluk basit log parser, URL classifier ve dashboard içeren açık kaynak starter proje geliştirebilir. Test verisi sentetik olarak oluşturulmalıdır. Git repository içinde setup ve privacy dokümantasyonu bulunabilir. Katılımcılar issue ve pull request üzerinden katkı sağlayabilir. Proje zamanla eğitim materyaline dönüşebilir.

Googlebot Verification Aracı

Reverse DNS ve forward DNS mantığını gösteren eğitim aracı geliştirilebilir. Kullanıcı IP girip doğrulama adımlarını görebilir. Sonuçların kesin güvenlik ürünü olarak değil eğitim amaçlı olduğu belirtilmelidir. DNS timeout ve cache konuları uygulamada gösterilebilir. Bu çalışma networking bilgisini SEO kullanım senaryosuyla birleştirir.

Junior-Senior Mentorluk

Junior katılımcı gerçek bir log analiz görevini senior mentorla birlikte çözebilir. Senior kişi yalnız sonucu değil düşünme yöntemini aktarır. Crawled ile indexed ayrımı gibi temel kavramlar vaka üzerinden öğrenilir. Kod review ve SQL review yapılabilir. Bu süreç topluluk içinde kalıcı teknik bilgi paylaşımını destekler.

Yazılımcı Olmak İsteyenler Log Analizi İçin Neler Öğrenmeli?

Log analizi web altyapısının farklı katmanlarını anlamayı gerektirir. HTTP, DNS, Linux ve web server bilgisi requestin nasıl ilerlediğini kavramayı sağlar. Regex, Python ve SQL büyük log datasetleriyle çalışmayı kolaylaştırır. Crawling ve indexing bilgisi teknik verinin SEO anlamını doğru yorumlamak için gereklidir. Monitoring ve observability ise tek seferlik scriptleri sürdürülebilir production sistemine dönüştürmeyi öğretir.

HTTP

HTTP method, status code, header ve redirect davranışı temel bilgidir. 200, 301, 404, 429 ve 5xx kodları SEO log analizinde sürekli kullanılır. Request ve response yaşam döngüsü anlaşılmalıdır. Cache control ve content type gibi headerlar faydalıdır. Bu temel olmadan log satırları yalnız metin olarak kalır.

DNS

DNS bot doğrulama ve site altyapısını anlamada önemlidir. Reverse DNS ile IP'den hostname bulunabilir. Forward DNS kontrolü doğrulamayı tamamlar. CDN ve load balancer mimarilerinde DNS routing rol oynar. Temel record türleri öğrenilmelidir.

Linux

Linux log dosyalarının bulunduğu ve işlendiği yaygın ortamdır. grep, tail, awk ve sort gibi araçlar hızlı analiz sağlar. Dosya izinleri ve process kavramı incident sırasında yararlıdır. Compression ve rotation işlemleri anlaşılmalıdır. Production erişiminde güvenlik kurallarına uyulmalıdır.

Web Server

Apache, Nginx veya IIS requestlerin nasıl loglandığını anlamak için temel kavramlar sağlar. Access log ile error log farkı bilinmelidir. Reverse proxy ve upstream davranışı öğrenilmelidir. Custom log format yapılandırması analiz kalitesini etkiler. Server konfigürasyonu değiştirirken engineering süreçleri izlenmelidir.

Regex

Regex URL pattern ve log parsing işlerinde sık kullanılır. ?filter=, /product/ veya status patternleri sınıflandırılabilir. Çok karmaşık regex bakım maliyeti oluşturabilir. Kurallar test örnekleriyle doğrulanmalıdır. Açıklayıcı isimler ve dokümantasyon kullanılmalıdır.

Python

Python veri temizleme, parsing ve otomasyon için güçlüdür. pandas, regex ve requests gibi araçlar yararlı olabilir. Memory yönetimi büyük loglarda önemlidir. Scriptler test ve version control altında tutulmalıdır. Notebooktan production pipeline'a geçiş ayrıca öğrenilmelidir.

SQL

SQL aggregation ve cross data analizinde çok değerlidir. GROUP BY, JOIN ve window functions öğrenilmelidir. Date partition ile büyük dataset sorguları optimize edilebilir. Search Console ve analytics verisi URL bazında birleştirilebilir. Query sonucu iş anlamıyla yorumlanmalıdır.

Crawling ve Indexing

Crawling ile indexing ayrımı teknik SEO'nun temelidir. Log crawling olayını gösterebilir fakat indexing'i kanıtlamaz. Robots ve noindex farklı amaçlara sahiptir. Sitemap crawl garantisi değildir. Bu kavramlar yanlış teknik aksiyonların önüne geçer.

Monitoring ve Observability

Monitoring metrikleri düzenli izlemeyi, observability ise problemin nedenini anlamaya yetecek bağlamı kurmayı amaçlar. Alert, SLI, SLO ve incident workflow kavramları öğrenilmelidir. Log pipeline health de izlenmelidir. Data quality bozulursa SEO metriği anlamsız hale gelir. Production sistem düşüncesi analizi daha sürdürülebilir yapar.

Sürdürülebilir Log Analizi İçin Automation Maturity Model

Automation maturity modeli ekiplerin manuel log exportundan sürekli SEO observability sistemine geçişini aşamalı biçimde düşünmesini sağlar. Birinci seviyede analiz dönemsel ve dosya tabanlıdır. İkinci seviyede düzenli rapor oluşturulur. Üçüncü seviyede otomatik dashboard, dördüncü seviyede anomaly alerting, beşinci seviyede ise detection, incident workflow, validation ve historical trend tek sistem içinde çalışır. Her şirketin doğrudan beşinci seviyeye çıkması gerekmez. Yatırım site ölçeği ve iş riskine göre yapılmalıdır.

Seviye 1: Manuel Log Export

SEO ekibi belirli tarih aralığındaki access logu manuel olarak alır. Dosya yerel araç veya scriptle analiz edilir. Audit için yeterli olabilir ancak sürekli problem tespitinde gecikme yaşanır. Tekrarlanabilirlik sınırlıdır. Veri gizliliği ve dosya paylaşım süreci özellikle kontrol edilmelidir.

Seviye 2: Düzenli Analiz

Log export haftalık veya aylık otomatik hazırlanabilir. Standard Python veya SQL sorguları kullanılır. Temel KPI'lar aynı formatta raporlanır. Hâlâ insanın raporu açıp kontrol etmesi gerekir. Baseline oluşmaya başlar.

Seviye 3: Otomatik Dashboard

Data pipeline logları merkezi storage'a aktarır. URL classification ve bot verification otomatik çalışır. Dashboard güncel crawl trend ve error metriklerini gösterir. SEO ekibi manuel dosya taşımaz. Yetki ve retention merkezi yönetilir.

Seviye 4: Anomaly Alerting

Baseline dışına çıkan olaylar otomatik algılanır. 5xx spike, parameter crawl artışı veya priority freshness kaybı alarm üretebilir. Severity ve owner kuralları tanımlanır. Alert sonrası insan review gerekir. False positive oranı düzenli optimize edilir.

Seviye 5: SEO Observability

En ileri seviyede logs, crawler, Search Console, analytics ve release verileri ortak sistemde bulunur. Anomaly otomatik tespit edilir, incident workflow açılır ve düzeltme sonrası validation çalışır. Historical trend ve SLO sonuçları yönetim reviewlarına taşınır. Teknik SEO tek seferlik audit olmaktan çıkar. Sistem devamlı öğrenen ve guardrail üreten operasyon modeline dönüşür.

otomatik detection

Detection baseline ve business priority kurallarını kullanır. Her metrik aynı algoritmayı kullanmak zorunda değildir. 5xx için threshold, crawl dağılımı için istatistiksel değişim uygulanabilir. Olay context ile birlikte kaydedilir. Human review süreci korunur.

incident workflow

Alert doğrulanınca incident kaydı açılır. Owner, severity ve etkilenen URL space atanır. Son deployment ve infrastructure eventleri otomatik bağlanabilir. Fix ve rollback adımları kaydedilir. Timeline postmortem için saklanır.

validation

Düzeltme productiona çıktıktan sonra aynı metrikler yeniden kontrol edilir. Error rate veya response time'ın baseline'a dönmesi beklenir. Kritik URL'lerde bot requesti görüldüğünde ek doğrulama oluşur. Search Console sonucu daha uzun sürede takip edilebilir. Incident acceptance criteria tamamlanmadan kapatılmaz.

historical trend

Uzun dönem aggregate metrikler saklanır. Crawl allocation, error ve freshness eğilimleri çeyreklik reviewda incelenir. Major release ve migration markerları zaman çizelgesinde tutulur. Baseline değişimleri görünür hale gelir. Teknik SEO borcu veriyle takip edilir.

AI Log Analizinde Nasıl Kullanılabilir?

AI destekli yöntemler büyük log özetlerini yorumlama, yeni URL patternlerini gruplama ve hata clusterlarını açıklama konusunda yardımcı olabilir. Ancak crawling stratejisi, indexing kararı, robots veya canonical tercihi gibi konularda nihai insan değerlendirmesi gerekir. Model yanlış pattern çıkarabilir veya iş değerini bilmeden düşük değerli URL tanımı yapabilir. Bu nedenle AI otomasyon katmanında yardımcı araç olarak kullanılmalı, doğrulanmış metriklerin yerine geçirilmemelidir. Güvenli kullanımda hassas production logların izinsiz harici sistemlere gönderilmemesi de önemlidir.

Anomali Özetleme

Anomaly detector yüzlerce teknik sinyal üretebilir. AI bu olayları kısa özet halinde sunarak insan review süresini azaltabilir. Örneğin belirli template'te 5xx ve response time artışını tek olay olarak gruplayabilir. Kaynak metrikler raporda görünür kalmalıdır. Özet doğrulanabilir veri referanslarına dayanmalıdır.

Yeni URL Pattern Tespiti

Unknown URL listeleri örüntü açısından otomatik gruplanabilir. Yeni campaign, facet veya tracking parameter family önerileri oluşturulabilir. İnsan analist patternin gerçek işlevini doğrulamalıdır. Classifier kuralı manuel review sonrasında productiona alınabilir. Bu yaklaşım URL space bakımını hızlandırır.

Error Cluster Oluşturma

Binlerce 404 veya 5xx URL path benzerliğine göre cluster edilebilir. Ortak route veya template problemi daha hızlı görünür. Status ve timestamp verisi cluster özetine eklenebilir. AI önerisi root cause kanıtı olarak kabul edilmemelidir. Engineering loglarıyla doğrulama yapılmalıdır.

Teknik Bulguları Özetleme

Aylık rapordaki çok sayıda KPI yönetim için anlaşılır dile çevrilebilir. Özet iş etkisi, trend ve önerilen aksiyonu içerebilir. Sayısal değerler değişmeden korunmalıdır. Belirsizlikler açıkça belirtilmelidir. İnsan analist yayın öncesi sonucu kontrol etmelidir.

İnsan Kararının Gerektiği Alanlar

Log verisi teknik sinyal sunar ancak stratejik karar bağlam gerektirir. Crawl stratejisi, indexing tercihi, iş önceliği ve robots veya canonical kararı site hedeflerine bağlıdır. Otomatik sistem kullanıcı niyetini veya ticari planı eksik anlayabilir. Bu nedenle AI öneri üretirken nihai onay SEO ve ilgili product ekiplerinde kalmalıdır. Güçlü süreç insan kararını hızlandırır, ortadan kaldırmaz.

crawl stratejisi

Hangi URL alanının taranmaya değer olduğu yalnız request sayısından belirlenemez. Search demand, business value ve içerik kalitesi değerlendirilmelidir. AI düşük traffic alanı yanlışlıkla waste olarak sınıflandırabilir. SEO uzmanı stratejik bağlamı ekler. Teknik uygulama kontrollü test edilir.

indexleme kararı

Bir sayfanın indekste tutulup tutulmaması içerik ve arama talebi kararını içerir. Log yalnız crawling davranışını gösterir. AI modelinin noindex önerisi doğrudan uygulanmamalıdır. Search Console ve content strategy incelenmelidir. İnsan review zorunlu olmalıdır.

iş önceliği

Revenue, campaign planı ve ürün stratejisi otomatik log analizinde tam görünmeyebilir. Yeni landing page henüz trafik almamasına rağmen çok önemli olabilir. Priority listesi product ve SEO ekiplerinin girdisini içermelidir. AI yalnız mevcut sinyalleri özetleyebilir. Roadmap kararı insanda kalır.

robots/canonical kararı

Robots ve canonical farklı teknik amaçlar taşır. Yanlış otomatik uygulama önemli URL'leri crawlerdan veya indeksleme sürecinden etkileyebilir. Karar site mimarisi ve içerik ilişkisine göre verilmelidir. Log yalnız mevcut crawl davranışını doğrular. Değişiklik test ve monitoring ile uygulanmalıdır.

Log Analizinde En Sık Yapılan Hatalar

Log analizi güçlü bir yöntemdir fakat yanlış yorumlandığında ekipleri gereksiz optimizasyona yönlendirebilir. Crawl budget'ı her site için kritik sanmak, user agentı doğrulamadan Googlebot kabul etmek ve yalnız origin loguna bakmak sık hatalardır. Tek günlük veriden sonuç çıkarmak, URL'leri segmentlemeden analiz etmek ve crawled ile indexed kavramlarını karıştırmak da yanlış sonuç üretir. Her 404 aynı öncelikte değildir ve Search Console logların alternatifi değildir. En sağlıklı yaklaşım veri kalitesi, iş değeri, zaman trendi ve çoklu veri kaynaklarını aynı analiz çerçevesinde kullanmaktır.

Crawl Budget'ı Her Site İçin Kritik Sanmak

Küçük ve temiz URL yapısına sahip sitelerde crawl budget genellikle ana SEO problemi değildir. İçerik, indexing veya teknik erişilebilirlik daha önemli olabilir. Log analizi yine migration veya hata teşhisi için fayda sağlar. Crawl optimization yalnız gerçek veri problemi gösteriyorsa öncelik kazanmalıdır. Her projeye aynı checklist uygulanmamalıdır.

User-Agent'ı Doğrulamadan Googlebot Kabul Etmek

Sahte botlar Googlebot user agentını kolayca kullanabilir. Bu trafik dahil edilirse request ve error metrikleri bozulur. IP, reverse DNS ve forward DNS doğrulaması yapılmalıdır. Verified flag dataset içinde saklanmalıdır. Dashboard yalnız güvenilir bot segmentini kullanmalıdır.

Yalnız Origin Server Loguna Bakmak

CDN veya WAF kullanılan sitelerde birçok istek origin'e hiç ulaşmaz. Cache hit, 403 veya 429 olayları edge katmanında kalabilir. Origin log crawl hacmini eksik gösterebilir. İstek mimarisi önce anlaşılmalıdır. Authoritative edge log gerektiğinde analize dahil edilmelidir.

Tek Günlük Veriden Sonuç Çıkarmak

Crawler davranışı günler arasında doğal olarak değişebilir. Tek günlük yüksek parameter request büyük problem anlamına gelmeyebilir. En az birkaç haftalık trend daha güvenilir bağlam sağlar. Migration veya incident gibi özel durumlarda kısa dönem veri yine değerlidir. Sonuçların veri penceresi açıkça belirtilmelidir.

URL'leri Segmentlemeden Analiz Etmek

Milyonlarca URL'yi tek tablo halinde görmek aksiyon üretmez. Product, blog, facet ve search gibi URL space segmentleri oluşturulmalıdır. Status ve frequency bu gruplar içinde anlam kazanır. Business value etiketi eklenebilir. Segmentasyon log analizini stratejik hale getirir.

Crawled ile Indexed'ı Karıştırmak

Logda request görmek indexing kanıtı değildir. Crawled URL noindex, duplicate veya kalite nedeniyle indeks dışında kalabilir. Search Console ile indexing durumu ayrıca kontrol edilmelidir. Bu ayrım yanlış crawl budget çalışmalarını önler. Dashboard terimleri açık tanımlanmalıdır.

Her 404'ü Aynı Öncelikte Görmek

Eski ve tek sefer taranan URL ile sitemap içinde bulunan yüksek frequency 404 aynı değildir. Age, frequency, source ve business value önceliği belirler. Backlink bilgisi de faydalıdır. Internal link kaynaklı kırık URL yüksek kalite problemidir. Backlog scoring kullanılmalıdır.

Search Console'u Logların Alternatifi Sanmak

Search Console çok değerli arama verisi sunar ancak ham request geçmişinin yerini tutmaz. Loglar timestamp ve status seviyesinde daha ayrıntılı crawl görünümü sağlar. İki kaynak birlikte kullanıldığında daha güçlü teşhis yapılır. Biri diğerini gereksiz hale getirmez. Veri rolleri ekip dokümantasyonunda açık olmalıdır.

İş Değeri Olmadan Crawl Metric'lerini Optimize Etmek

Daha az request her zaman daha iyi değildir. Değerli ürün ve kategori sayfalarının da crawl payı düşebilir. Business value ve update frequency hesaba katılmalıdır. Priority Crawl Share bu nedenle faydalıdır. Teknik metrikler iş sonucu bağlamında yorumlanmalıdır.

Teknik Değişiklik Sonrası Loglarla Doğrulama Yapmamak

Robots veya redirect değişikliği uygulandı diye iş tamamlanmış sayılmamalıdır. Bot davranışı loglarla izlenmelidir. Beklenen URL segmentinde request azalması veya yeni target crawl artışı görülmelidir. Sorun devam ediyorsa discovery kaynağı araştırılır. Validation Definition of Done içine eklenmelidir.

Log Retention Planlamamak

Incident olduğunda yalnız son iki günlük log bulunması uzun dönem analizini engelleyebilir. Retention veri hacmi ve gizlilik gereksinimine göre önceden belirlenmelidir. Aggregate metrikler daha uzun saklanabilir. Rotation ve archive otomatik olmalıdır. Data availability SLO bile tanımlanabilir.

Gizlilik Gereksinimlerini İhmal Etmek

IP ve query string alanları hassas veri içerebilir. SEO analizi için gereksiz alanlar tutulmamalıdır. Masking ve access control uygulanmalıdır. Production export güvenli biçimde paylaşılmalıdır. Security ve hukuk ekipleri retention politikasına dahil edilmelidir.

SEO Log Audit Checklist

SEO log audit checklist veri kalitesinden bot doğrulamaya, crawl davranışından HTTP durumlarına ve cross data karşılaştırmalarına kadar temel kontrolleri standartlaştırır. İlk adım doğru log kaynağının ve yeterli tarih aralığının bulunduğunu doğrulamaktır. Ardından Googlebot doğrulaması ve URL segmentasyonu yapılmalıdır. Crawl allocation, 3xx, 404, 429, 5xx ve response time incelenir. Son aşamada sitemap, Search Console ve internal crawler verileri loglarla birleştirilerek aksiyon listesi oluşturulur.

Veri Hazırlığı

Audit başlamadan önce log formatı, tarih aralığı ve field completeness kontrol edilmelidir. Timezone tutarsızlığı düzeltilir. CDN kullanılan yapıda yalnız origin verisine güvenilmez. Duplicate event ihtimali incelenir. Veri güvenliği şartları sağlanır.

doğru log kaynağı alındı mı?

İsteklerin CDN, WAF veya load balancer üzerinden geçip geçmediği anlaşılmalıdır. Origin log bütün trafiği göstermeyebilir. Authoritative request katmanı belirlenmelidir. Gerekirse birden fazla log kaynağı karşılaştırılır. Veri kapsamı audit raporunda açıklanır.

yeterli tarih aralığı var mı?

Tek günlük veri çoğu stratejik analiz için yetersizdir. En az birkaç haftalık dönem doğal crawler değişimini gösterir. Migration veya seasonal analiz daha uzun veri gerektirebilir. Retention sınırı sonuçlarda belirtilmelidir. Eksik dönem yanlışlıkla crawl kaybı olarak yorumlanmamalıdır.

gerekli alanlar mevcut mu?

Timestamp, URL, status, user agent ve mümkünse IP temel alanlardır. Response time ve bytes analizi genişletir. CDN cache status ek değer sağlar. Eksik field varsa hangi analizlerin yapılamayacağı belirlenir. Gelecek dönem için log formatı geliştirilebilir.

timezone tutarlı mı?

Tüm kaynaklar ortak timezone'a çevrilmelidir. Deployment ve incident timestamp aynı standardı kullanmalıdır. UTC storage yaygın tercihtir. Rapor yerel timezone gösterebilir. Dönüşüm kuralı dokümante edilmelidir.

Bot Kontrolü

User agent adayları bot family olarak sınıflandırılır. Googlebot gibi kritik crawlerlar IP ve DNS ile doğrulanır. Sahte veya unknown botlar ayrı tutulur. Resource ve page requestleri segmentlenir. Analiz yalnız tanımlı bot kapsamıyla yapılır.

Googlebot doğrulandı mı?

User agent tek başına yeterli değildir. Reverse ve forward DNS doğrulaması yapılmalıdır. Sonuç verification flag olarak saklanır. Cache ile tekrar sorgular azaltılır. Failed botlar SEO KPI'larına dahil edilmez.

bot segmentleri ayrıldı mı?

Smartphone Googlebot, image crawlers ve diğer bot türleri farklı davranabilir. Tek toplam bot metriği bazı sorunları gizler. Bot family sınıflandırması yapılmalıdır. Human ve unknown trafik dışarıda tutulmalıdır. Dashboard bot filtresi sunmalıdır.

Crawl

Crawl analizi request hacmi kadar allocation ve freshness konularına bakmalıdır. En çok taranan URL space ve priority sayfaların frequency değeri incelenir. Waste segmentleri business value ile doğrulanır. Unique URL sayısı parameter explosion açısından değerlendirilir. Sonuç yalnız sayı değil aksiyon üretmelidir.

en çok taranan URL space hangisi?

Product, category, blog ve facet segmentleri request share ile karşılaştırılır. En yüksek payın beklenen iş değeriyle uyumlu olup olmadığı değerlendirilir. Düşük değerli alan yüksek pay alıyorsa discovery kaynağı araştırılır. Trend zaman içinde izlenir. Yeni patternler unknown kategorisinden çıkarılır.

kritik sayfalar taranıyor mu?

Priority URL listesi loglarla join edilir. Last crawl ve frequency değerleri hesaplanır. Update sıklığına göre freshness değerlendirilir. Hiç taranmayan URL'ler sitemap ve internal link açısından incelenir. Search Console indexing durumu ayrıca kontrol edilir.

crawl waste var mı?

Waste URL segmentleri açıkça tanımlanmalıdır. Parameter, internal search ve eski redirects aday olabilir. Request share ve trend hesaplanır. Business value olmayan alanlar öncelik alır. Robots ve URL generation çözümleri kontrollü uygulanır.

HTTP

Status code analizi botların gerçekte aldığı yanıtları gösterir. 3xx, 404, 429 ve 5xx ayrı incelenmelidir. URL age ve frequency 404 önceliğini belirler. 5xx için deployment ve upstream korelasyonu yapılır. Critical URL status ayrıca raporlanır.

3xx oranı?

3xx request share migration veya redirect yoğunluğunu gösterir. Top source URL listesi çıkarılır. Internal link ve sitemap redirect kaynakları temizlenmelidir. Chain crawler ile kontrol edilir. Trend zaman içinde düşmelidir.

404?

404 URL'ler frequency, age ve source ile önceliklendirilir. Sitemap 404 ayrı kritik segmenttir. Internal link kaynakları crawler ile bulunabilir. Backlink değeri eklenebilir. Tek seferlik eski URL düşük öncelikte tutulabilir.

429?

429 rate limiting problemini gösterebilir. Bot verification özellikle önemlidir. CDN veya WAF katmanı incelenir. Saatlik spike ve URL segmenti çıkarılır. Security ile DevOps ortak aksiyon alır.

5xx?

5xx success reliability için kritik sinyaldir. Rate ve absolute count birlikte gösterilir. Template ve deployment korelasyonu yapılır. CDN ile origin ayrıştırılır. Recovery doğrulanmadan incident kapatılmaz.

Performans

Bot response time ortalama, median ve üst percentile değerlerle incelenmelidir. Site bölümü ve saat bazında yavaşlık araştırılır. Cache status ve upstream response yardımcı alanlardır. Crawl behavior ile korelasyon yalnız bağlam olarak kullanılmalıdır. Genel kullanıcı performansı da dikkate alınmalıdır.

bot response time normal mi?

Mevcut değer baseline ile karşılaştırılır. p95 ve p99 artışı tail latency sorunu gösterebilir. Deployment veya traffic event ile ilişki kontrol edilir. Yavaş template listesi çıkarılır. Platform ekibine ölçülebilir bulgu aktarılır.

Cross-Data

Log audit tek kaynakla tamamlanmamalıdır. Sitemap crawlera önerilen URL setini, Search Console indexing ve search sinyallerini, internal crawl ise site mimarisini gösterir. Bu kaynaklar normalize URL üzerinden birleştirilir. Veri tarihleri uyumlu hale getirilir. Fark segmentlerinden aksiyon çıkarılır.

sitemap karşılaştırıldı mı?

Sitemap URL'leri log datasetine join edilmelidir. Crawled ve not crawled grupları çıkarılır. Sitemap dışı crawl ayrıca incelenir. Hatalı status dönen sitemap URL'leri temizlenir. Freshness priority segmentiyle değerlendirilir.

Search Console ile birleştirildi mi?

Crawling ve indexing durumlarını ayırmak için Search Console eklenmelidir. Crawled + not indexed önemli segmenttir. Not crawled + indexed durumları da görülebilir. Data freshness farkı açıklanmalıdır. Tek kaynağa dayalı kesin sonuçlardan kaçınılmalıdır.

internal crawl ile karşılaştırıldı mı?

Internal crawler link grafiği ve discoverability sağlar. Googlebot tarıyor fakat crawler bulamıyor segmenti orphan araştırması için değerlidir. Crawler buluyor fakat bot taramıyor segmenti critical URL'lerde incelenebilir. Redirect chain ve internal link source crawlerdan alınabilir. İki veri birbirini tamamlar.

30 Günlük Sürdürülebilir SEO Log Analizi Planı

İlk 30 günlük planın amacı yalnız log audit raporu çıkarmak değil tekrar kullanılabilir bir ölçüm altyapısının temelini kurmaktır. İlk hafta log kaynakları, retention ve bot doğrulama düzenlenir. İkinci hafta crawl volume, status, response time ve priority crawl baseline oluşturulur. Üçüncü hafta crawl waste, 404, 5xx, parameter ve orphan-like URL analizi yapılır. Son hafta dashboard, alarm, owner ve haftalık review süreci devreye alınarak çalışma sürdürülebilir hale getirilir.

1-7. Gün: Veri Altyapısı

İlk hafta veri kaynağı ve quality konularına odaklanmalıdır. CDN, WAF, load balancer ve origin akışı belgelenir. Log retention süresi kontrol edilir. Googlebot verification ve URL classifier ilk sürümü hazırlanır. Sensitive data masking güvenlik ekibiyle doğrulanır.

log kaynaklarını belirle

İsteğin hangi katmanlardan geçtiği diagram ile çıkarılabilir. Hangi logun bütün edge requestlerini gördüğü belirlenir. Origin-only eksiklik riski değerlendirilir. Sample eventler sistemler arasında karşılaştırılır. Authoritative source dokümante edilir.

retention kontrol et

Mevcut logların kaç gün saklandığı öğrenilir. 30 günlük analiz için veri yeterli mi doğrulanır. Gelecek migration veya trend ihtiyacı planlanır. Sensitive raw field retention ayrıca belirlenir. Archive policy hazırlanır.

bot doğrulama

User agent adayları çıkarılır. DNS doğrulama pipeline kurulabilir. Verified ve failed statusları üretilir. Cache mekanizması DNS maliyetini azaltır. Test IP'leriyle sonuç doğrulanır.

URL segmentleri

Product, category, blog, search ve facet gibi temel URL class kuralları yazılır. Unknown bucket tutulur. Business priority alanı eklenir. Regex testleri örnek URL seti üzerinde çalıştırılır. Sınıflandırma version control altında saklanır.

8-14. Gün: Baseline

İkinci hafta normal crawler davranışını anlamaya ayrılır. Günlük request, unique URL, status dağılımı ve response time hesaplanır. Priority URL'lerin crawl frequency ve freshness değeri ölçülür. URL space share çıkarılır. Bu baseline sonraki anomaly ve optimization ölçümlerinin referansı olur.

crawl volume

Verified Googlebot request günlük ve saatlik trend olarak hesaplanır. Unique crawled URL eklenir. Bot family ayrımı yapılır. Resource requestler gerektiğinde dışarıda tutulur. Natural pattern not edilir.

HTTP status

2xx, 3xx, 4xx ve 5xx oranları hesaplanır. 404, 429 ve 5xx ayrı listelenir. Template bazında dağılım çıkarılır. Critical URL status kontrol edilir. Normal error baseline belirlenir.

response time

Median, p95 ve p99 response time hesaplanır. Template ve saat bazında farklar incelenir. Cache status varsa karşılaştırılır. Slowest URL listesi çıkarılır. Performance baseline kaydedilir.

priority crawl

Priority URL listesi analytics ve product girdileriyle oluşturulur. Last crawl date ve frequency hesaplanır. Priority Crawl Share çıkarılır. Freshness threshold önerilir. Kritik eksikler review listesine alınır.

15-21. Gün: Sorun Analizi

Üçüncü hafta baseline dışındaki ve düşük verimlilik gösteren alanlar incelenir. Crawl waste segmentleri, 404 ve 5xx, parameter growth ve orphan-like URL'ler öncelikli konulardır. Sitemap ve internal crawler verileri loglarla birleştirilir. Her bulgu impact, owner ve önerilen aksiyonla backlog maddesine dönüştürülür. Çözüm önerisi crawler davranışı ve iş değeri birlikte düşünülerek hazırlanır.

crawl waste

Waste tanımı business ve SEO tarafından onaylanır. Request share ve unique URL sayısı hesaplanır. En büyük contributor segmentleri listelenir. Internal link veya robots kaynakları araştırılır. İyileştirme için before after metriği belirlenir.

404/5xx

404'ler age, frequency ve source ile sıralanır. 5xx template ve deployment bazında analiz edilir. Sitemap hataları ayrıştırılır. Critical URL sorunları yüksek öncelik alır. Engineering owner atanır.

parameters

Query parameter family listesi çıkarılır. Filter, sort, search ve tracking ayrı segmentlenir. Request ve unique URL payı ölçülür. Search demand ve business value eklenir. Gereksiz URL production kaynağı belirlenir.

orphan URL'ler

Internal crawler bulamadığı halde Googlebot'un taradığı URL'ler çıkarılır. Sitemap ve external link olasılığı kontrol edilir. Değerli sayfalara internal link eklenebilir. Eski sayfalar kaldırma veya redirect açısından değerlendirilir. Sonuç URL owner ile paylaşılır.

22-30. Gün: Automation

Son hafta elde edilen analiz tekrar üretilebilir sisteme dönüştürülür. Dashboard temel KPI'ları gösterir, alert kuralları kritik anomalileri izler ve her metrik için owner tanımlanır. Haftalık review formatı hazırlanır. Data quality ve pipeline health ayrıca izlenir. Bu aşama tamamlandığında log analizi tek seferlik dosya çalışması olmaktan çıkar.

dashboard

Crawl trend, status, URL space, response time ve freshness grafiklerinin ilk sürümü hazırlanır. Filtreler bot, host ve template bazında çalışır. Priority URL paneli eklenir. Error drill down sağlanır. Role based access güvenlik gereksinimine göre ayarlanır.

alert

5xx spike, Googlebot drop ve parameter growth için ilk alert kuralları oluşturulur. Threshold baseline'a göre seçilir. Severity ve duration koşulları eklenir. False positive review yapılır. Alert ilgili owner'a yönlendirilir.

owner

Her alert ve dashboard alanının sorumlusu belirlenir. SEO analiz, DevOps altyapı ve Developer uygulama sorunlarını sahiplenebilir. RACI matrisi dokümante edilir. Critical incident escalation yolu tanımlanır. Owner değişiklikleri güncel tutulur.

haftalık review

Haftalık 20 ile 30 dakikalık review yeterli olabilir. Yeni anomalies, error trend ve priority crawl kontrol edilir. Açık backlog maddelerinin durumu gözden geçirilir. Gereksiz alarm kuralları temizlenir. Öğrenimler classifier ve dashboarda yansıtılır.

Sık Sorulan Sorular

Log dosyası analizi nedir?

Log dosyası analizi web sunucusu, CDN veya ilgili altyapı katmanlarında oluşan request kayıtlarının incelenmesidir. SEO bağlamında amaç arama motoru botlarının gerçek tarama davranışını anlamaktır. URL, timestamp, status code, user agent ve response time temel alanlardır. Loglar crawling hakkında doğrudan kanıt sunar. Indexing ve ranking için ek veri kaynakları gerekir.

Log analizi SEO için neden önemlidir?

Log analizi crawlerın gerçekten hangi URL'leri ziyaret ettiğini gösterir. Bu bilgi crawl allocation, hata ve freshness sorunlarını ölçmeyi sağlar. Crawler simülasyonu ile gerçek Googlebot davranışı arasındaki fark görülebilir. Migration ve teknik değişiklikler loglarla doğrulanabilir. Büyük sitelerde sürekli monitoring için özellikle değerlidir.

Log dosyası Googlebot'un hangi sayfaları taradığını gösterir mi?

Evet, doğru log katmanı ve doğrulanmış bot filtresi kullanıldığında Googlebot'un hangi URL'lere request gönderdiği görülebilir. Timestamp ve status code bilgisi de bulunabilir. Ancak CDN cache nedeniyle origin log bazı istekleri kaçırabilir. Bu yüzden edge altyapısı dikkate alınmalıdır. User agent tek başına doğrulama için yeterli değildir.

Google Search Console ile log analizi aynı şey midir?

Hayır, iki veri kaynağı farklı sorulara yanıt verir. Search Console indexing ve arama görünürlüğüyle ilgili değerli veriler sunar. Loglar ham request davranışını ayrıntılı gösterir. Birlikte kullanıldıklarında crawling ve indexing sorunları daha kolay ayrılır. Birinin diğerinin yerini aldığı düşünülmemelidir.

Crawl budget nedir?

Crawl budget bir sitenin arama motoru tarafından ne kadar taranabileceği ve ne kadar taranmak istendiğiyle ilişkili kavramdır. Crawl capacity ve crawl demand birlikte düşünülür. Her site için kritik değildir. Büyük, hızlı güncellenen veya çok sayıda parameter URL üreten sitelerde daha önemli olabilir. Log analizi gerçek request allocation'ı ölçmeye yardımcı olur.

Her site crawl budget optimizasyonu yapmalı mıdır?

Hayır, küçük ve temiz sitelerde crawl budget genellikle öncelikli problem değildir. İçerik kalitesi, teknik erişilebilirlik ve indexing sorunları daha önemli olabilir. Log audit yine migration veya hata kontrolünde faydalıdır. Sürekli crawl optimization ancak gerçek veri bir problem gösteriyorsa yapılmalıdır. Maliyet ve fayda birlikte değerlendirilmelidir.

Googlebot nasıl doğrulanır?

User agent Googlebot adayını belirlemek için kullanılır. Ardından IP üzerinde reverse DNS kontrolü yapılır. Elde edilen hostname forward DNS ile tekrar IP'ye çözülerek doğrulanır. Sonuç verified status olarak saklanabilir. Yalnız user agent metnine güvenilmemelidir.

Server loglarında hangi alanlar bulunmalıdır?

Timestamp, hostname, method, URL, query string, status, user agent, IP, response time ve response bytes yararlı temel alanlardır. CDN kullanılıyorsa cache status ve upstream status da değerlidir. Tüm alanların SEO ekibine ham biçimde verilmesi gerekmez. Sensitive veriler filtrelenebilir. Ortak data schema analiz kalitesini artırır.

Log analizi için kaç günlük veri gereklidir?

Kesin tek sayı yoktur. Kısa teknik audit için 14 ile 30 gün yeterli olabilir. Crawl freshness veya migration trendi için 30 ile 90 gün daha iyi sonuç verir. Düşük frequency URL'lerde kısa pencere yanıltıcı olabilir. Veri aralığı site büyüklüğü ve analiz sorusuna göre seçilmelidir.

404 hataları crawl budget'ı etkiler mi?

Sürekli ve çok geniş 404 URL alanı crawler requestlerinin bir bölümünü tüketebilir. Ancak tek sefer taranan eski 404 büyük problem olmayabilir. Frequency, age ve discovery source birlikte değerlendirilmelidir. Sitemap ve internal link kaynaklı 404'ler daha yüksek öncelik taşır. Her 404 aynı biçimde ele alınmamalıdır.

5xx hataları Googlebot taramasını etkiler mi?

Yüksek ve sürekli 5xx oranı crawlerın siteye sağlıklı erişemediğini gösterir. Server kapasitesi ve reliability açısından önemlidir. Loglarda 5xx rate, template ve zaman spike analizi yapılmalıdır. CDN ve origin hata kaynağı ayrıştırılmalıdır. Sorun düzeltildikten sonra bot success rate yeniden doğrulanmalıdır.

Faceted navigation loglarda nasıl bulunur?

Facet URL patternleri query parameter veya path kurallarıyla sınıflandırılabilir. ?filter=, renk, beden ve fiyat kombinasyonları örnek olabilir. Unique URL ve request share hesaplanır. Search demand ve business value ile birlikte yorumlanır. Çoklu filtre kombinasyonları ayrı segmentlenebilir.

Orphan page log dosyalarıyla bulunabilir mi?

Log tek başına orphan page kanıtlamaz. Internal crawler verisiyle birleştirildiğinde Googlebot'un taradığı fakat crawlerın bulamadığı URL'ler ortaya çıkar. External link ve sitemap kaynakları ayrıca kontrol edilir. Stratejik sayfalarda internal linking eksikliği giderilebilir. Eski URL'ler farklı aksiyon gerektirebilir.

Log analizi indexing'i gösterir mi?

Hayır, log analizi bir URL'nin crawling olayını gösterir. URL'nin indekslenip indekslenmediğini tek başına kanıtlamaz. Search Console gibi ek veri kaynakları kullanılmalıdır. Crawled + not indexed segmenti önemli teşhis alanıdır. Bu ayrım teknik SEO yorumlarının temelidir.

Crawled ve indexed arasındaki fark nedir?

Crawled arama motoru botunun URL'yi ziyaret ettiği anlamına gelir. Indexed ise içeriğin arama motorunun indeksine dahil edilmesini ifade eder. Her crawled URL indexed olmaz. Her indexed URL de analiz döneminde yeniden taranmış olmayabilir. İki durum ayrı veri kaynaklarıyla takip edilmelidir.

Log analizi ne sıklıkla yapılmalıdır?

Küçük sitelerde dönemsel audit yeterli olabilir. Büyük ve dinamik sistemlerde günlük otomatik monitoring, haftalık review ve aylık derin analiz kullanılabilir. Çeyreklik stratejik review uzun dönem trendleri değerlendirir. Sıklık iş riski ve değişim hızına göre belirlenmelidir. Her site için aynı takvim kullanılmamalıdır.

Log analizi için Python gerekli midir?

Hayır, Python zorunlu değildir. Hazır araçlar, SQL, Shell veya observability platformları kullanılabilir. Python özellikle otomasyon ve custom parsing için yararlıdır. Araç seçimi veri hacmi ve ekip becerisine göre yapılmalıdır. En önemli özellik sürecin tekrarlanabilir olmasıdır.

Log analizi için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Python parsing ve automation, SQL warehouse sorguları, Shell hızlı analiz, JavaScript veya TypeScript servis geliştirme için uygundur. Ekip mevcut altyapısına uygun seçim yapmalıdır. Data quality ve pipeline reliability dilden daha önemlidir. Kod version control ve test altında tutulmalıdır.

Açık kaynak log analizi araçları kullanılabilir mi?

Evet, açık kaynak parser, dashboard ve veri işleme araçları kullanılabilir. Güvenlik ve kişisel veri gereksinimleri yine korunmalıdır. Production loglar herkese açık hale getirilmemelidir. Kod ve anonim örnek veri paylaşılabilir. Kurumsal kullanımda bakım ve erişim politikası ayrıca planlanmalıdır.

Küçük sitelerde log analizi gerekli midir?

Sürekli log monitoring küçük sitelerde çoğu zaman şart değildir. Migration, erişim sorunu veya beklenmeyen 404 gibi durumlarda dönemsel analiz çok faydalı olabilir. Site birkaç yüz URL'den oluşuyorsa crawl budget genellikle ana problem olmaz. Maliyet ve fayda değerlendirilmelidir. Audit kapsamı ihtiyaca göre dar tutulabilir.

Log verileri ne kadar süre saklanmalıdır?

Retention tek standart sayı değildir. 30 ile 90 gün operasyonel analiz için yaygın bir pencere olabilir. Yıllık trend için aggregate veri daha uzun saklanabilir. Hassas IP ve query bilgileri daha kısa retention gerektirebilir. Security ve hukuk politikası karara dahil edilmelidir.

CDN logları SEO analizi için gerekli midir?

CDN kullanılan sitelerde çoğu zaman çok değerlidir. Cache hit veya WAF engeli origin logunda görünmeyebilir. 403, 429 ve edge status davranışı CDN kaydında bulunabilir. Tüm projelerde zorunlu değildir fakat request flow anlaşılmadan origin verisine güvenmek risklidir. Doğru katman veri modeliyle seçilmelidir.

Sürdürülebilir SEO monitoring sistemi nasıl kurulur?

Önce güvenilir log pipeline ve bot verification kurulmalıdır. Ardından URL classification, baseline ve temel KPI'lar tanımlanır. Search Console, crawler ve analytics verileriyle cross data model oluşturulur. Critical anomalies için alert ve incident workflow eklenir. Haftalık ve aylık review sistemiyle öğrenimler teknik backlog ve guardraillere dönüştürülür.

Ek Sık Sorulan Sorular

Sürdürülebilir SEO için log dosyası analizi nasıl yapılır?

Sürdürülebilir SEO için log dosyası analizi önce doğru log katmanlarının belirlenmesiyle başlar. Googlebot requestleri user agent üzerinden aday olarak seçilmeli ve IP ile DNS kontrolleri kullanılarak doğrulanmalıdır. Ardından URL'ler product, category, blog, facet, search veya diğer anlamlı URL space gruplarına ayrılmalıdır. Crawl frequency, HTTP status, response time, crawl freshness ve priority crawl share metrikleri düzenli olarak takip edilmelidir. Son aşamada Search Console, sitemap, crawler ve analytics verileriyle birleştirme yapılarak tek seferlik rapor yerine dashboard, alarm ve incident yönetimi içeren sürekli izleme sistemi kurulmalıdır.

Log dosyası analizi ile Googlebot ve diğer arama motoru botlarının tarama davranışları nasıl analiz edilir?

Bot davranışını analiz etmek için önce ilgili crawler requestlerinin gerçek olduğundan emin olmak gerekir. User agent tek başına yeterli değildir ve doğrulanmış bot segmentleri oluşturulmalıdır. Daha sonra requestler timestamp, URL space, status code, response time ve resource type bazında gruplanabilir. Crawl hit, unique crawled URL, last crawl date ve ortalama crawl interval gibi metrikler hesaplanabilir. Farklı crawler türlerinin davranışları aynı toplam altında birleştirilmek yerine ayrı segmentlerde değerlendirilmelidir.

Sunucu logları kullanılarak crawl budget kaybı, tarama hataları ve gereksiz URL taramaları nasıl tespit edilir?

Önce düşük değerli veya gereksiz kabul edilen URL segmentleri açık biçimde tanımlanmalıdır. Parameter, internal search, bazı facet kombinasyonları, eski redirect kaynakları ve duplicate URL aileleri bu gruba girebilir. Doğrulanmış bot requestlerinin ne kadarının bu segmentlere gittiği Crawl Waste Rate ile ölçülebilir. 404, 429 ve 5xx durumları frequency, age ve template bazında analiz edilmelidir. Priority Crawl Share ile stratejik URL'lerin aldığı request payı aynı tabloda gösterildiğinde crawler kaynaklarının hangi alanlara ayrıldığı daha anlaşılır hale gelir.

Log dosyası analizi SEO performansını, indeksleme sorunlarını ve site mimarisini iyileştirmek için nasıl kullanılır?

Log dosyaları doğrudan crawling davranışını gösterir ve bu veri Search Console ile birleştirildiğinde crawl ile indexing sorunlarını ayırmaya yardımcı olur. Internal crawler ile karşılaştırıldığında Googlebot'un taradığı ancak internal yapıda bulunamayan orphan-like URL'ler görülebilir. Sitemap karşılaştırması stratejik URL'lerin gerçek crawl freshness durumunu ortaya koyar. Analytics verisi eklendiğinde iş değeri yüksek sayfaların crawl davranışı ayrıca izlenebilir. Bu bulgular internal linking, sitemap, redirect, faceted navigation ve altyapı performansı gibi alanlarda ölçülebilir teknik aksiyonlar üretmek için kullanılabilir.

SEO log dosyası analizi ve teknik SEO danışmanlığını yakınımda nerede bulabilirim?

Log dosyası analizi ve teknik SEO danışmanlığı yakınımda şeklinde arama yaparken yalnız tek seferlik log exportunu inceleyen bir yaklaşım yerine bot doğrulama, URL segmentasyonu, Search Console birleştirme, monitoring ve teknik aksiyon süreci sunan bir model tercih etmek daha yararlıdır. Diyarbakır Yazılım Topluluğu hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Topluluğun proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects üzerinden ulaşabilirsiniz. Veri sistemleri ve dijital pazarlama araçlarının birlikte çalışmasıyla ilgili ek içerik için https://www.diyarbakiryazilim.com.tr/posts/crm-ve-dijital-pazarlama-araclari-arasi-veri-senkronizasyonu sayfası da yararlı bir devam kaynağıdır. Danışmanlık seçerken gerçek bot verisi, güvenli log erişimi, iş değeri bazlı önceliklendirme ve düzeltme sonrası doğrulama süreçlerinin birlikte sunulmasına dikkat edilmelidir.

Sonuç: Tek Seferlik Log Audit'inden Sürekli SEO Observability'ye

Sürdürülebilir SEO İçin Log Dosyası Analizi, birkaç milyon log satırını bir araca yükleyip hata listesi çıkarmaktan ibaret değildir. Gerçek değer, doğrulanmış crawler davranışını URL space, business value, Search Console, internal crawl ve analytics verileriyle bir araya getirdiğinizde ortaya çıkar. Crawl sayısını tek başarı metriği yapmak yerine tarama verimliliği, priority freshness, error rate ve iş etkisi birlikte izlenmelidir. Manuel auditlerden otomatik dashboard ve anomaly alert sistemine geçiş, büyük kurumsal sitelerde teknik SEO sorunlarının daha erken fark edilmesini sağlar. Log dosyası analizi ve sürdürülebilir teknik SEO çalışmaları hakkında toplulukla bağlantı kurmak için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.

Varsayımdan Gerçek Crawler Verisine

SEO crawler ve teknik dokümantasyon sitenin nasıl çalışması gerektiğini anlatabilir. Loglar ise botun gerçekten ne yaptığını gösterir. Bu fark teknik SEO kararlarının veriyle doğrulanmasını sağlar. Robots, redirect ve migration değişiklikleri gerçek crawler behavior üzerinden izlenebilir. Böylece ekip varsayım yerine production verisine dayanır.

Tek URL'den URL Space Analizine

Büyük sitelerde tek tek URL düzeltmek ölçeklenebilir değildir. Product, category, facet, search ve template segmentleri ortak davranışı gösterir. Tek root cause binlerce URL'yi etkileyebilir. URL space dashboardu crawler allocation'ı daha anlaşılır hale getirir. Teknik backlog sistem düzeyinde planlanabilir.

Crawl Sayısından Crawl Verimliliğine

Daha fazla crawl request otomatik olarak daha iyi SEO anlamına gelmez. Önemli olan crawlerın stratejik ve güncel URL'lere sağlıklı biçimde ulaşmasıdır. Hata, response time ve waste alanları birlikte değerlendirilmelidir. Priority Crawl Share ve freshness bu bakışı güçlendirir. Amaç request miktarını değil tarama kalitesini yönetmektir.

Crawl Budget'tan İş Değerine

Crawl budget teknik bir kaynak tartışması olarak kalmamalıdır. Revenue, conversion, organic traffic ve stratejik priority verileri crawler metriğine bağlanmalıdır. Böylece düşük değerli URL'lerin aşırı taranması ile kritik ürün sayfalarının freshness problemi aynı çerçevede görülebilir. Product ekibi karar sürecine dahil olur. Teknik SEO işi iş sonucu açısından daha anlaşılır hale gelir.

Search Console'dan Çoklu Veri Modeline

Search Console tek başına çok değerlidir ancak bütün crawler davranışını ham request seviyesinde sunmaz. Logs, crawler, sitemap ve analytics verileri farklı sorulara cevap verir. Normalize URL anahtarıyla bu kaynaklar birleştirilebilir. Crawled ile indexed ayrımı daha net görülür. Teknik problem daha doğru katmanda çözülür.

Manuel Audit'ten Otomatik Alert'e

Manuel audit geçmiş problemi bulur. Otomatik alert ise problem oluşurken sinyal verebilir. 5xx spike, Googlebot drop ve parameter crawl artışı izlenebilir. Baseline ve severity kuralları alarm kalitesini korur. İnsan analizci karar verme sürecinin merkezinde kalır.

Teknik Hata Listesinden SEO Incident Management'a

Hata listesi owner ve workflow olmadan uzun süre açık kalabilir. Incident management detect, triage, fix ve validation süreçlerini standartlaştırır. Kritik SEO erişim sorunları production reliability yaklaşımıyla ele alınır. Postmortem öğrenimleri yeni guardraillere dönüşür. Organizasyon aynı hatayı tekrar tekrar çözmek yerine kök nedeni azaltır.

Dönemsel SEO Kontrolünden Sürdürülebilir SEO Gözlemlenebilirliğine

En olgun modelde teknik SEO yalnız üç ayda bir yapılan kontrol değildir. Loglar, Search Console, crawler ve iş verileri sürekli bir observability sisteminde birleşir. Anomaly detection yeni sorunları görünür kılar, incident workflow aksiyonu yönetir ve validation düzeltmenin gerçek sonucunu doğrular. Bu yapı SEO, DevOps, Data, Developer ve Product ekiplerini ortak performans dili etrafında buluşturur. Sürdürülebilir SEO İçin Log Dosyası Analizi böylece bir audit tekniğinden uzun vadeli teknik SEO işletim modeline dönüşür.