Search Console Tarama İstatistikleri Raporu Rehberi

Tarama İstatistikleri raporu, Google'ın sitenize ne kadar istek attığını, bu isteklerin ne kadar sürede ve hangi yanıt koduyla döndüğünü Search Console içinden gösterir. Kısa cevap şu: raporu bir yargı değil bir alarm paneli gibi okuyun. Önce ana bilgisayar durumuna, sonra yanıt kodu dağılımına, en sonda da istek hacmindeki değişime bakın. Tek bir günün düşüşü ya da çıkışı sonuç değildir, birkaç haftalık yön önemlidir.

Bu raporun temel kaynağı Google'ın Tarama İstatistikleri raporu yardım sayfasıdır (yeni sekmede açılır). Rapordaki her bölümün neyi saydığını, hangi satırın sizi harekete geçirmesi gerektiğini ve hangi satırın yalnızca bilgi olduğunu adım adım göreceksiniz. Sunucu erişim kayıtlarını çözümleme ayrı bir işlemdir; burada yalnızca Search Console'un hazır sunduğu rapora odaklanıyoruz. Rapor, sitenize özel bir teşhisin yerini tutmaz.

Rapor Nerede, Kimler Görebilir

Raporun ilk sürprizi, her mülkte görünmemesidir. Yardım sayfasına göre rapor yalnızca kök düzeydeki mülklerde bulunur: bir alan adı mülkü ya da kök düzeyde URL öneki mülkü. Alt klasör düzeyinde tanımladığınız bir mülkte raporu bulamazsınız. Sayfa ayrıca raporun ileri düzey kullanıcılara yönelik olduğunu ve bin sayfadan az sitelerin genellikle buna ihtiyaç duymadığını belirtir.

Raporu açmanın yolu

Mülk ayarlarına gidip dişli simgesinden Tarama istatistikleri bölümünü açabilir ya da yardım sayfasında verilen doğrudan adresi kullanabilirsiniz. Raporun sol menüde standart bir kısayolu bulunmadığı için ekipteki herkesin yolu bilmesi gerekir. Küçük bir ajansın ortak müşteri notlarına rapor yolunu yazması, yeni gelen çalışanın raporu aramasını önler.

Rapor neyi kapsamaz

Kapsam sınırlarını bilmeden yorum yapmak yanlış sonuç üretir. Yardım sayfasındaki sınırlar şöyle özetlenebilir:

• Veriler seçili alan adıyla sınırlıdır. Başka bir alan adında barındırılan sayfa kaynakları (örneğin görsel ya da betik sunucusu) bu raporda görünmez.
• Kardeş alt alan adları birbirinin raporunda görünmez. Ancak alt alan adları arasındaki istekler ana alan adının raporunda yer alır.
• URL öneki mülklerinde http ve https istekleri birlikte sayılır, fakat örnek URL'ler yalnızca mülkte tanımlı protokolle sınırlıdır.
• Tarayıcı tarafında (istemci) gerçekleşen yönlendirmeler sayılmaz. Sunucu tarafı yönlendirmelerin her adımı ayrı istek olarak sayılır.

Bu son madde önemli bir sonuç doğurur: iki adımlı bir yönlendirme zinciri, tek bir sayfa için iki istek harcar. Rapordaki toplam isteği "taranan sayfa sayısı" gibi okumak bu yüzden yanıltıcıdır.

Sunucu Kayıtlarından Farkı

Rapor ile sunucu erişim kayıtları aynı şeyi ölçmez. Kayıtlar sunucunuza ulaşan her isteği satır satır tutar ve Googlebot kimliğini kendiniz doğrularsınız. Rapor ise Google'ın kendi gözünden özetlenmiş bir görünümdür. Yardım sayfası, raporun bazı istekleri kaçırabileceğini ve bu yüzden sunucu kayıtlarıyla farkların beklenen bir durum olduğunu söyler. Ayrıca robots.txt dosyası uzun süre ulaşılamaz olduğunda, raporun gerçekte yapılmamış taramaları da saydığı için toplamların sunucu kayıtlarından yüksek çıkabileceği belirtilir.

Yani iki kaynak çeliştiğinde ilk tepki "biri yanlış" olmamalıdır. Rapor trend ve sınıflandırma için, kayıtlar ise tek tek istek ve doğrulama için kullanılır. Kayıt tarafını ayrıntılı işleyen SEO için sunucu log analizi yazısı ayrı bir konudur; bu yazıdaki iş akışı önce hızlı bir panel taraması, gerekirse ardından kayıtlara inme sırasını önerir.

İstek, Boyut ve Yanıt Süresi Grafikleri

Raporun üst bölümünde üç ana grafik bulunur. Her biri farklı bir soruyu cevaplar ve birbirinden bağımsız okunmaz.

Toplam tarama isteği

Yardım sayfasına göre bu sayı başarılı ve başarısız istekleri birlikte içerir; yinelenen istekler tek tek sayılır. Başarısız istekler arasında DNS hataları, bağlantı hataları ve yönlendirme döngüleri vardır. Dolayısıyla istek sayısının artması her zaman iyi haber değildir. Hatalı yönlendirmeler ya da yeni üretilmiş çok sayıda parametreli adres de sayıyı yukarı çeker.

Toplam indirme boyutu

Tarama sırasında indirilen bayt miktarıdır. Sayfaya göre önbelleğe alınmış bir kaynak yalnızca ilk ihtiyaç duyulduğunda istenir. Sitenizde büyük bir betik paketini ya da görsel klasörünü değiştirdiğinizde bu grafikte bir sıçrama beklemek normaldir. Boyut yükselirken istek sayısı sabitse, aynı sayıda sayfa daha ağır dosyalarla sunuluyor demektir.

Ortalama yanıt süresi

Dönemde alınan tüm kaynakları kapsar ve bağlı her kaynak ayrı sayılır. Bu yüzden sayfa içi bir yavaşlama, ortalamayı tek başına yükseltebilir. Yanıt süresi artarken istek sayısı düşüyorsa, sunucunun işi yetiştiremediği ve taramanın buna göre yavaşladığı bir tablo oluşmuş olabilir. Yardım sayfası, tarama hızının bir iki hafta boyunca fazla oynamaması gerektiğini; ani düşüşlerin geniş robots.txt kuralları, yavaş yanıtlar, artan sunucu hataları veya düşük değerli içerik gibi nedenlerden doğabileceğini söylüyor.

Örnek senaryo: sıçrama sonrası okuma

Bir ürün kataloğunda kategori sayfalarına yeni filtreler eklendiğini düşünün (örnek senaryo, rakamsız). Birkaç gün sonra toplam istek yükselir, ortalama yanıt süresi de artar. Burada iki hipotez vardır: Google yeni adres kombinasyonlarını keşfediyor ya da sunucu filtreli sayfaları geç üretiyor. Hangisi olduğunu aynı raporun "amaç" ve "yanıt" bölümleri söyler. Keşif payı yükselmişse ilk hipotez, 5xx ya da zaman aşımı payı yükselmişse ikinci hipotez güçlenir. Bu karar ağacı raporu okumanın özüdür: bir grafikten başlayıp bir sonraki dökümle sınamak.

Ana Bilgisayar Durumu

Ana bilgisayar durumu (host status) bölümü, raporun en az dikkat çeken ama en çok eyleme dönük kısmıdır. Yardım sayfasına göre üç durum vardır:

1. Son 90 günde önemli bir sorun yok.
2. Son 90 günde sorun yaşandı, ancak bir haftadan daha uzun süre önce.
3. Son bir hafta içinde erişilebilirlik sorunu var.

Değerlendirilen kategoriler robots.txt dosyasının alınması, DNS çözümü ve sunucu bağlantısıdır. Her grafikte kırmızı noktalı bir eşik çizgisi bulunur. Sayfanın örneği, bir günde isteklerin yüzde 5'inden fazlasında DNS'in başarısız olmasıdır.

robots.txt hatasının sonuçları

Sayfada robots.txt için net bir kural özeti var. Google, 200 yanıtını (geçerli, geçersiz ya da boş dosya) ve 403, 404, 410 yanıtlarını başarılı sayar. 429 ve 5xx yanıtları başarısızdır. İlk 12 saatte başarısızlık varsa tarama durur. 12 saatten 30 güne kadar son başarıyla alınan dosya kullanılır. 30 günden sonra ana sayfa erişilebiliyorsa Google kısıtsız tarar, erişilemiyorsa taramayı durdurur.

Bu kuralın pratik karşılığı şudur: robots.txt adresi 5xx döndüren bir sunucu, yalnızca o dosyayı değil bütün taramayı etkiler. Bakım penceresinde ya da CDN değişikliğinde bu dosyanın ayrıca denenmesi gerekir. Erişim engeli tarafında güvenlik duvarı ve CDN kaynaklı sorunlar için Googlebot erişimini doğrulama ve WAF/CDN engelleri yazısına bakabilirsiniz.

Ne zaman müdahale edilir

Yeşil durum rahatlatıcıdır ama bilgi vermez. Sarı ya da kırmızı durumda sıra şöyledir: önce hangi kategorinin (robots.txt, DNS, sunucu bağlantısı) eşiği aştığına, sonra aşıldığı güne bakın. O güne denk gelen dağıtım, DNS değişikliği veya hosting olayını arayın. Kaynağı bulup düzelttikten sonra durumun toparlanmasını raporda izleyin, ama toparlanma hızı konusunda belgelerde bir süre taahhüdü yoktur.

Yanıt Kodu Dağılımı

Yanıt bölümü, Google'ın aldığı HTTP yanıtlarını gruplar. Pay hesabı benzersiz URL değil istek sayısı üzerindendir. Yardım sayfası gruplamayı şöyle yapar:

404 satırını doğru okumak

404 sayfada "muhtemelen iyi" olarak anılır, çünkü kalıcı olarak kaldırılmış bir sayfa için doğru bir yanıttır. Sorun, sitenizin kendi içinden hâlâ bu adreslere bağlantı verilmesidir. Yanıt sınıfı aynı kalsa bile 404 payının dönem dönem büyümesi, silinen ürünlerin site içi bağlantılarının temizlenmediğini gösterebilir. Yanıt kodlarının anlamını ve yönlendirme seçimlerini HTTP durum kodları rehberinde bulabilirsiniz.

Yönlendirme payı ne anlatır

Her sunucu yönlendirmesi ayrı bir istek olduğundan, taşınmış bir site ya da yeniden yazılmış bir URL yapısı yönlendirme payını geçici olarak yükseltir. Taşımadan aylar sonra hâlâ yüksekse, site içi bağlantıların eski adreslere işaret ettiğinden ve sitemap dosyasının güncellenmediğinden şüphelenin. Hedefe doğrudan giden bağlantılar hem kullanıcıyı hem taramayı bir adım kısaltır.

Kötü sınıfta hangi satır önce

Karar kuralı: sunucu hataları ve zaman aşımı sizin tarafınızdadır, öncelik alır. Yetkilendirme hataları (401 ve 407) genellikle bir erişim kısıtının yanlış yerde durmasına işaret eder. DNS ve robots.txt satırları ise ana bilgisayar durumuyla birlikte okunur. Her satır için örnek URL'lere tıklayıp gerçek bir adres alın, tarayıcıdan ya da komut satırından yanıtı kendiniz görün.

Dosya Türü ve Tarama Amacı

Dosya türü bölümü, Google'ın hangi tür kaynakları istediğini yanıt sayısı üzerinden gösterir. Yüzdeler bayt değil yanıt payıdır. Kategoriler HTML, görsel, video, JavaScript, CSS, PDF, diğer XML, JSON, yayın akışı (syndication), ses, coğrafi veri, diğer dosya türü (yönlendirmeler dahil) ve bilinmeyen (başarısız) olarak listelenir.

Dosya türü payı neyi gösterir

Bir içerik sitesinde HTML payının baskın olması beklenir. JavaScript ya da CSS payı yüksekse sayfanın çok sayıda kaynağa bağımlı olduğunu düşünebilirsiniz. Ancak tek başına bu paylar bir hata değildir. Yeni bir ön yüz paketi yayınladıysanız JavaScript payının değişmesi doğaldır. Önemli olan ani değişimin bir dağıtım tarihine denk gelip gelmediğini sorgulamaktır.

Keşif ve yenileme

Amaç bölümü iki sınıf sunar. Keşif, Google'ın daha önce hiç taramadığı bir URL'dir. Yenileme ise bilinen bir sayfanın yeniden taranmasıdır. Yardım sayfası hızlı değişen sayfaların sitemap dosyasına eklenmesini, yavaş değişen sayfalar için ise yeniden tarama isteği göndermeyi önerir.

Yeni içerik yayınlayan bir blog için olağan bir resim, yayın günlerinde keşif payının yükselmesi ve ardından yenileme payının dengelenmesidir. Sürekli yüksek bir keşif payı ve düşük bir yenileme payı, Google'ın yeni adresleri keşfetmeye devam ettiği ama bilinen önemli sayfalara dönmediği anlamına gelebilir. Bu durumda yeni adreslerin gerçekten yeni ve değerli sayfalar mı, yoksa filtre ve oturum parametresi kaynaklı kopyalar mı olduğuna bakın. Tarama kaynağının nasıl harcandığına dair kapsamlı çerçeve için tarama bütçesi optimizasyonu rehberini kullanabilirsiniz.

Googlebot türü

Rapor, isteği yapan Googlebot türünü de ayırır: akıllı telefon, masaüstü, görsel, video, sayfa kaynağı yükleme (görsel ve CSS gibi ikincil getirmeler, bu kalemde sayılır), AdsBot, StoreBot ve diğer. Sayfaya göre AdsBot yaklaşık iki haftada bir görünür. Reklam hedef sayfalarında bir sorun varsa bunun AdsBot satırında iz bırakması mümkündür, ancak bu bir çıkarımdır ve doğrulama için örnek URL'lere bakmak gerekir.

Örnek URL'ler ve Veri Sınırları

Her dökümde Google, örnek URL'ler listeler. Yardım sayfası bu listelerin kapsamlı olmadığını, temsili bir örneklem olduğunu belirtir. Bir adresin listede görünmemesi, istenmediği anlamına gelmez. Örnekler gün bazında ağırlıklandırıldığı için bazı kategoriler daha çok örnek gösterebilir; sayfa bunun zamanla dengelendiğini söyler.

Örneklemi doğru kullanmak

Örnek URL'yi "kanıt" olarak değil "ipucu" olarak kullanın. Örneğin 5xx dökümünde tek bir yol deseni tekrar ediyorsa, o desene ait birkaç adresi elle deneyin. Sorun yeniden üretilirse düzeltme yapın. Üretilemiyorsa aralıklı bir sunucu sorunu ya da koruma katmanı olasılığı vardır; bu durumda sunucu kaydını incelemek gerekir.

Tarama hızı beklentisi

Yardım sayfasına göre Google tarama hızını talep üzerine artırmaz, ancak sizin tarama hızını düşürmenizi isteyebilirsiniz. robots.txt engellerinin etkisi bir güne kadar sürebilir ve bu engellerin çok uzun süre bırakılmaması önerilir. Geçici olarak 503 ya da 429 döndürmek gerekiyorsa bunun iki üç günden uzun sürmemesi gerekir; aksi halde Google uzun vadede daha seyrek tarayabilir.

Eylem Tablosu

Aşağıdaki tablo, rapor bölümlerini bir karar akışına çevirir. Her satır bir gözlemi, olası nedeni ve ilk kontrol adımını verir. Nedenler olasılıktır, kesin teşhis sayılmaz.

Haftalık kontrol listesi

• Ana bilgisayar durumunu açın, son bir haftada kırmızı bir kategori olup olmadığına bakın.
• Toplam isteği, indirme boyutunu ve yanıt süresini aynı tarih aralığında yan yana okuyun.
• Yanıt dökümünde kötü sınıfın payını önceki haftayla karşılaştırın.
• Amaç dökümünde keşif ve yenileme dengesini not edin.
• Bir değişiklik fark ettiyseniz, yayın ve dağıtım takviminizle eşleştirin.
• Örnek URL'lerden en az birini elle deneyin.
• Bulguyu tarihle birlikte tek satır olarak bir günlüğe yazın.

Hızlı Teşhis Akışı

Rapora panikle girenler için sabit bir sıra, yorumu daraltır. Aşağıdaki sıra, dakikalar içinde ilk ayrımı yapmanıza yardım eder.

1. Ana bilgisayar durumuna bakın. Kırmızıysa robots.txt, DNS ve sunucu bağlantısı kategorilerinden hangisinin eşiği aştığını bulun. Gerisini bırakın, bu satır önceliklidir.
2. Yanıt dökümünde kötü sınıfın payı arttı mı? Arttıysa hangi yanıt türü: 5xx, zaman aşımı, DNS, robots.txt alınamadı.
3. Yanıt süresi grafiğinde aynı tarihte bir sıçrama var mı? Varsa dağıtım ve altyapı günlüğüyle eşleştirin.
4. İstek grafiğine bakın. Düşüş varsa robots.txt değişikliğini ve sunucu hatalarını eleyin, ardından düşük değerli içerik olasılığını tartın.
5. Amaç dökümünde keşif payı değişti mi? Değiştiyse yeni adres üretimini inceleyin.
6. Son olarak dosya türü ve Googlebot türü kırılımlarına bakıp beklenmeyen bir kaymayı not edin.

Örnek senaryo: taşıma sonrası okuma

Bir site alan adı ya da URL yapısını değiştirdi (örnek senaryo, rakamsız). İlk haftalarda yönlendirme payının yüksek, keşif payının da yüksek olması beklenen bir görünümdür. Asıl soru, birkaç hafta sonra bunun yatışıp yatışmadığıdır. Yatışmıyorsa site içi menü, sitemap ve kanonik etiketlerin hâlâ eski adresleri işaret edip etmediğini kontrol edin. Hedef, Google'ın tek adımda doğru sayfaya ulaşmasıdır.

Yaygın Yanlış Okumalar

Raporu kullanan ekiplerin çoğu aynı tuzaklara düşer. Bunları bilmek, gereksiz alarmları azaltır.

İstek artışını başarı saymak

İstek sayısı yükseldiğinde ilk refleks sevinmektir. Oysa toplam, başarısız istekleri ve yinelenen istekleri de içerir. Bir yönlendirme zinciri bir sayfa için birden fazla istek üretir. Sevinmeden önce yanıt dağılımına ve amaç paylarına bakın.

İstek düşüşünü ceza sanmak

Düşüş her zaman bir cezanın işareti değildir. Yardım sayfası, geniş robots.txt kurallarının, yavaş yanıtların ve düşük değerli içeriğin tarama hızını etkileyebildiğini söyler. Önce bunları eleyin. Belgelerde düşüşün bir ceza sinyali olarak yorumlanması gerektiğine dair bir ifade yoktur.

Raporu sıralama sonucu gibi okumak

Tarama, dizine eklenme ve sıralama ayrı aşamalardır. Çok taranan bir sayfanın iyi sıralanacağına dair bir garanti yoktur ve az taranan bir sayfa kötü sayfa demek değildir. Raporu erişilebilirlik ve tarama sağlığı için kullanın, görünürlük ölçümü için Search Console'un performans raporlarına ve kendi ölçümlerinize dönün.

Küçük sitede gereğinden fazla zaman harcamak

Yardım sayfası bin sayfadan az sitelerin genellikle bu rapora ihtiyaç duymadığını söyler. Küçük bir sitede ana bilgisayar durumu ve yanıt dökümüne ayda bir bakmak çoğu zaman yeterlidir. Zamanınızı içerik ve sayfa kalitesine ayırmak daha yüksek getiri sağlayabilir.

Büyük ve Küçük Siteler İçin Farklı Okuma

Aynı rapor, yüz sayfalık bir kurumsal sitede ve yüz binlerce adresi olan bir pazaryerinde farklı sorulara hizmet eder. Küçük sitede asıl amaç alarm vermektir: ana bilgisayar durumu temiz mi, robots.txt erişilebilir mi, yanıt dökümünde beklenmeyen bir 5xx var mı. Rapora ayda bir bakmak yeterli olur ve bulgu çoğunlukla bir sunucu ya da DNS sorununa çıkar.

Büyük sitede rapor bir segmentasyon aracına dönüşür. Dosya türü, amaç ve Googlebot türü kırılımlarını birlikte okuyarak taramanın nereye harcandığını anlarsınız. Burada rapor tek başına yeterli kalmaz; örnek URL desenlerinden yola çıkıp sunucu kayıtlarıyla birlikte analiz edersiniz. Rapor "nerede" sorusunu, kayıtlar "hangi adres ve kaç kez" sorusunu yanıtlar.

Kimin okuması gerekir

SEO uzmanı raporu yön ve segment için, geliştirici yanıt kodları ile yanıt süresi için, altyapı sorumlusu ise ana bilgisayar durumu için okur. Üçüne tek bir ortak görünüm sunmak yerine her role kendi bakacağı satırı yazılı olarak verin. Bu, haftalık toplantıda aynı grafiğe farklı gözlerle bakıp çatışmayı önler.

Aylık Rapor Notu Nasıl Yazılır

Raporun değeri, her ay aynı şablonla not alındığında ortaya çıkar. Bir not üç bölümden oluşabilir: gözlem, olası neden, yapılan iş. Örneğin "Yanıt süresi üç hafta boyunca arttı, aynı dönemde bir eklenti güncellemesi yapıldı, önbellek kuralı yeniden yazıldı" gibi bir satır, altı ay sonra bile anlam taşır.

Raporlamayı müşteriye ya da yöneticiye sunarken rakamdan çok yönü ve alınan kararı öne çıkarın. Hangi satırın izlendiğini, hangi eşikte aksiyon alındığını önceden yazın. Böylece düşüş ya da yükseliş ortaya çıktığında tartışma zeminden değil karar kuralından başlar.

Bir not şablonu

1. Tarih aralığı ve mülk adı.
2. Ana bilgisayar durumu: yeşil, sarı ya da kırmızı ve kategori.
3. Üç ana grafik için yön: yükseliyor, düşüyor, sabit.
4. Yanıt dökümünde en büyük kötü sınıf satırı.
5. Keşif ve yenileme dengesi.
6. Yapılan veya planlanan iş, sorumlusu ve tekrar bakma tarihi.

Düzeltmeden sonra neyi beklemeli

Bir düzeltme yaptıktan sonra raporun hemen değişmesini beklemeyin. Yardım sayfası tarama hızının bir iki hafta boyunca fazla oynamaması gerektiğini söylediği için, etkiyi değerlendirmek için de benzer bir pencere kullanın. Düzeltmeden sonraki ilk günlerde yalnızca ters bir yönün olup olmadığına bakın, sonuç için birkaç hafta bekleyin. Karar kuralı: bir hafta içinde kötü sınıf payı düşmediyse, düzeltmenin gerçekten canlıya ulaştığını sunucudan ayrıca doğrulayın.

Bu Raporu Başka Verilerle Eşleştirmek

Tarama İstatistikleri tek başına hikayenin yarısıdır. Eşleştirebileceğiniz üç kaynak vardır: dağıtım takvimi, sunucu ya da CDN olayları ve içerik yayın takvimi. Dağıtım takvimi yanıt süresi ve dosya türü değişimlerini açıklar. Sunucu olayları 5xx ve zaman aşımı sıçramalarını açıklar. İçerik takvimi keşif payındaki dalgalanmaları açıklar.

Bu eşleştirmeyi yapmak için ekibin ortak bir olay günlüğü tutması yeterlidir. Günlüğe her önemli değişiklik tarihiyle yazılır: robots.txt düzenlemesi, URL yapısı değişikliği, yeni bir eklenti, DNS değişikliği, büyük bir yayın. Raporda bir değişim fark ettiğinizde önce günlüğe bakmak, çoğu zaman teşhis süresini kısaltır.

Ne zaman sunucu kayıtlarına inilir

• Örnek URL'lerden sorunu yeniden üretemediğinizde.
• Rapor ile bir üçüncü taraf aracın verisi çeliştiğinde.
• Belirli bir istemcinin gerçek Googlebot olup olmadığından şüphelendiğinizde.
• Yanıt süresi artışının hangi yol desenlerinden geldiğini bulmanız gerektiğinde.

Kayıtlara indiğinizde de raporun sınıflandırmasını rehber olarak kullanın: aynı yanıt gruplarını kayıtlarda yeniden kurmak, iki kaynağı karşılaştırmayı kolaylaştırır. Raporda 5xx payı yükseldiyse kayıtlarda önce 5xx satırlarını süzün; yönlendirme payı yükseldiyse 301 ve 302 satırlarının hedeflerine bakın. Böylece rapor sizi nereye bakacağınıza, kayıtlar ise tam olarak hangi adreslerin etkilendiğine götürür.

Sık Sorulan Sorular

Tarama İstatistikleri raporunu neden mülkümde göremiyorum?

Yardım sayfasına göre rapor yalnızca kök düzeydeki mülklerde bulunur: alan adı mülkü ya da kök düzeyde URL öneki mülkü. Bir alt klasör için tanımlanmış mülkte rapor görünmez. Ayrıca sayfa raporun ileri düzey kullanıcılara yönelik olduğunu ve bin sayfadan az sitelerin genellikle ona ihtiyaç duymadığını belirtir.

Rapordaki toplam istek sayısı kaç sayfanın tarandığını gösterir mi?

Hayır. Toplam, başarılı ve başarısız istekleri birlikte içerir, yinelenen istekler tek tek sayılır ve her sunucu tarafı yönlendirme adımı ayrı istektir. Bu yüzden sayı, taranan benzersiz sayfa sayısından farklıdır.

Rapor ile sunucu kayıtlarım neden farklı çıkıyor?

Yardım sayfası raporun bazı istekleri kaçırabileceğini ve sunucu kayıtlarıyla farkların beklendiğini söyler. Ayrıca robots.txt dosyası uzun süre ulaşılamazsa rapor yapılmamış taramaları da sayabileceği için toplamlar kayıtlardan yüksek görünebilir.

404 yanıtlarının payı yüksekse acil bir sorun var mı?

Yardım sayfası 404'ü "muhtemelen iyi" sınıfına koyar: kırık bağlantıları işaret edebilir, ama gerçekten kaldırılmış sayfalar için doğru bir yanıttır. Örnek URL'lerin kaynağına bakın. Siteniz bu adreslere hâlâ bağlantı veriyorsa o bağlantıları güncelleyin.

Tarama hızını artırmasını Google'dan isteyebilir miyim?

Yardım sayfasına göre Google tarama hızını talep üzerine artırmaz. Hızı düşürmenizi isteyebilirsiniz. Hızlı değişen sayfaları sitemap dosyasına eklemek ve yavaş değişen sayfalar için yeniden tarama istemek sayfada önerilen yoldur.

Ana bilgisayar durumu kırmızı olursa ne yapmalıyım?

Önce hangi kategorinin (robots.txt, DNS, sunucu bağlantısı) eşiği geçtiğini ve hangi günde geçtiğini bulun, sonra o tarihteki dağıtım ve altyapı olaylarını inceleyin. Kalıcı çözüm için hosting ve geliştirme ekibinizle çalışın.

Sonuç

Google yardım sayfalarındaki sınırlar ve süreler değişebilir; uygulamadan önce güncel sayfaya bakın.

Tarama İstatistikleri raporu, Google'ın sitenize bakışını izlemek için hazır bir panel sunar. Sırası şudur: ana bilgisayar durumu, yanıt dökümü, ardından istek, boyut ve yanıt süresi eğilimleri, en son amaç ve dosya türü payları. Örnek URL'ler ipucudur, sunucu kayıtlarının yerini tutmaz. Yönü birkaç hafta boyunca izleyin, değişiklikleri dağıtım günlüğüyle eşleştirin ve rapora bir ceza ya da sıralama sinyali yüklemeyin.

Rapor sitenize özgü bir teşhis ya da sonuç garantisi sunmaz. Teknik bakımı tamamlayan görünürlük çalışmaları için backlink paketlerimizi inceleyebilirsiniz.