Googlebot Bir Sayfayı Neden Daha Az Taramaya Başlar?

Googlebot bir sayfayı iki ana nedenle daha az taramaya başlar: sunucu yavaşladığında veya 5xx ve 429 gibi hatalar döndürdüğünde Google siteyi yormamak için tarama hızını kendiliğinden düşürür; ya da sayfaya olan tarama talebi azalır, yani sayfa uzun süredir değişmiyor, iç linklerden zayıf besleniyor veya düşük değerli görünüyor. Search Console'daki Tarama İstatistikleri raporu hangisinin geçerli olduğunu çoğu zaman birkaç dakikada gösterir.
Hızlı sıra şudur: (1) Search Console'da Ayarlar altındaki Tarama İstatistikleri raporunu açın ve ortalama yanıt süresine bakın; (2) Ana makine durumu bölümünde robots.txt, DNS ve sunucu bağlantısı uyarılarını kontrol edin; (3) yanıt türleri dağılımında 5xx, 429 ve zaman aşımı oranını inceleyin; (4) sunucu tarafı sorun yoksa sayfanın güncellik, iç link ve sitemap sinyallerini gözden geçirin; (5) düzeltmeden sonra birkaç hafta boyunca raporu izleyin ve kararları tek günlük dalgalanmaya göre vermeyin.
Tarama azalması gerçekten sorun mu?
Önce paniği bir kenara koymak gerekiyor. Google'ın kendi belgelerinde açıkça belirtildiği gibi tarama bütçesi kavramı esas olarak çok büyük sitelerin, yani yüz binlerce veya milyonlarca URL'si olan ya da her gün çok sayıda sayfası değişen sitelerin konusudur. Birkaç yüz veya birkaç bin sayfalık bir blog, kurumsal site ya da küçük e-ticaret mağazası için Googlebot'un günlük istek sayısının düşmesi çoğu durumda doğal bir dalgalanmadır. Google, bir sayfanın değişmediğini defalarca gördüğünde onu daha seyrek ziyaret eder; bu bir ceza değil, kaynak tasarrufudur.
Sorun, tarama düşüşü başka belirtilerle birlikte geldiğinde başlar: yeni yazılar günlerce dizine girmiyorsa, güncellediğiniz fiyat veya başlık arama sonuçlarında eski haliyle kalıyorsa, Search Console'da "Tarandı, şu anda dizine eklenmedi" ya da "Keşfedildi, şu anda dizine eklenmedi" sayıları artıyorsa, tarama tarafında gerçekten bir darboğaz vardır. Tek başına grafiğin aşağı inmesi ise teşhis için yeterli değildir.
| Belirti | Muhtemel anlamı | Aciliyet |
|---|---|---|
| Toplam tarama isteği düştü, dizine ekleme normal | Değişmeyen sayfalara talep azaldı, doğal durum | Düşük |
| Ortalama yanıt süresi arttı, istek sayısı düştü | Google sunucuyu yavaş görüp hızı kıstı | Yüksek |
| 5xx veya 429 oranında sıçrama | Sunucu hata veriyor, Google geri çekiliyor | Çok yüksek |
| "Keşfedildi, dizine eklenmedi" sayısı artıyor | Google URL'yi biliyor ama taramaya sıra gelmiyor | Orta ile yüksek |
| robots.txt getirme hatası | Google taramayı tamamen askıya alabilir | Çok yüksek |
Tarama bütçesi nasıl oluşur: kapasite ve talep
Google tarama davranışını iki bileşenle açıklar. Birincisi tarama kapasitesi sınırıdır: Googlebot'un sitenize aynı anda kaç bağlantı açabileceği ve istekler arasında ne kadar bekleyeceği. Bu sınır, sunucunuzun sağlığına göre sürekli ayarlanır. Sunucu hızlı ve kararlı yanıt verirse sınır yükselir; yavaşlar veya hata verirse düşer. İkincisi tarama talebidir: Google'ın sitenizdeki URL'leri ne kadar taramak istediği. Talep; sayfanın popülerliği, ne sıklıkla değiştiği, sitenin genel algılanan kalitesi ve Google'ın dizinindeki kopyasının ne kadar eskidiği gibi etkenlerden beslenir.
Gerçek tarama miktarı bu ikisinin kesişimidir. Sunucunuz ne kadar güçlü olursa olsun talep yoksa Googlebot gelmez; talep ne kadar yüksek olursa olsun sunucu zorlanıyorsa Googlebot yavaşlar. Bu yüzden "daha az tarama" sorununu çözerken önce hangi tarafın daraldığını bulmak gerekir. Yanlış tarafa müdahale etmek, örneğin sunucu yavaşken içerik üretmeye yüklenmek, sonucu değiştirmez.
| Bileşen | Neye bağlı | Sizin kontrolünüzdeki kaldıraçlar |
|---|---|---|
| Tarama kapasitesi | Yanıt süresi, hata oranı, bağlantı kararlılığı | Sunucu kaynakları, önbellek, CDN, hata düzeltme |
| Tarama talebi | Popülerlik, güncellik, algılanan kalite, envanter büyüklüğü | İç link, sitemap, içerik kalitesi, kopya URL temizliği |
| Envanter verimliliği | Taranacak gereksiz URL sayısı | Parametre ve filtre yönetimi, yönlendirme zincirleri, soft 404 |
Sunucu tarafı nedenler: yanıt süresi, 5xx ve 429
Tarama düşüşlerinin en sık ve en hızlı çözülebilen nedeni sunucu tarafıdır. Googlebot, sunucunuzun yanıt süresi uzadığında bunu "bu site zorlanıyor" sinyali olarak okur ve eşzamanlı istek sayısını azaltır. Burada kastedilen, kullanıcının gördüğü tam sayfa yükleme süresi değil, Googlebot'un HTML veya kaynak dosyasını indirmesi için geçen süredir. Veritabanı sorgularının şiştiği, önbelleğin devre dışı kaldığı ya da paylaşımlı barındırmada komşu sitelerin kaynak tükettiği dönemlerde bu süre belirgin şekilde artar.
5xx sunucu hataları (500, 502, 503, 504) daha güçlü bir sinyaldir. Google belgelerine göre 500, 503 ve 429 yanıtları Googlebot'un tarama hızını düşürmesine yol açar. Bu davranış bilinçli bir güvenlik önlemidir: Google, zaten zorlanan bir sunucuyu daha fazla isteğe boğmak istemez. Sorun geçici ise Google birkaç gün içinde hızı tekrar artırır. Ancak aynı URL'ler uzun süre boyunca sürekli hata döndürürse, Google bunları dizinden düşürmeye başlayabilir. Bu nedenle 503'ü planlı bakım gibi kısa süreli durumlar için kullanmak doğrudur; günlerce süren 503 ise kalıcı bir sorun gibi değerlendirilebilir.
429 (Çok Fazla İstek) yanıtı genellikle bir güvenlik duvarı, hız sınırlayıcı veya bot koruma katmanından gelir. Pek çok site sahibi, saldırıya karşı kurduğu kuralın Googlebot'u da yakaladığını fark etmez. Özellikle CDN veya WAF tarafında "saniyede şu kadar istekten fazlasını engelle" türü kurallar, doğrulanmış Googlebot IP'lerini istisna tutmuyorsa tarama doğrudan kısılır. Bu tür altyapı ayarlarını gözden geçirirken genel güvenlik denetimi mantığı da işe yarar; sızma testi nedir ve nasıl yapılır yazısındaki yaklaşım, hangi kuralın meşru trafiği de engellediğini bulmak için iyi bir çerçeve sunar.
| Yanıt kodu | Googlebot'un tepkisi | Yapılacak |
|---|---|---|
| 200 ama yavaş | Eşzamanlı istekleri azaltır | Sunucu önbelleği, sorgu optimizasyonu, daha güçlü kaynak |
| 500 / 502 / 504 | Tarama hızını düşürür, süreklilikte URL düşebilir | Hata günlüklerini inceleyin, uygulama ve proxy hatalarını düzeltin |
| 503 | Geçici durum sayar, hızı düşürür, sonra tekrar dener | Yalnız kısa bakım için kullanın, uzun süre bırakmayın |
| 429 | Hızı düşürür | WAF ve hız sınırı kurallarında doğrulanmış Googlebot'u istisna tutun |
| Zaman aşımı / bağlantı hatası | Ana makine durumunda sorun olarak raporlanır | Barındırma, DNS ve ağ katmanını kontrol edin |
Ana makine durumu: robots.txt, DNS ve sunucu bağlantısı
Tarama İstatistikleri raporundaki Ana makine durumu bölümü üç şeyi izler: robots.txt getirme, DNS çözümleme ve sunucu bağlantısı. Bunlardan robots.txt en kritik olanıdır. Google, robots.txt dosyanıza erişmeye çalıştığında sunucu hata verirse (dosya yok anlamındaki 404 değil, 5xx gibi bir erişilemezlik), taramanın güvenli olup olmadığını bilemez ve siteyi taramayı durdurabilir. Yani kendi başına masum görünen bir robots.txt hatası, tüm sitenin taramasını neredeyse sıfıra indirebilir.
DNS sorunları da benzer etki yaratır. Alan adı sağlayıcınızın ad sunucuları zaman zaman yanıt vermiyorsa ya da kayıtlar yanlış yapılandırılmışsa, Googlebot sitenize ulaşamaz ve bunu raporda kırmızı bir uyarı olarak görürsünüz. Sunucu bağlantısı başlığı ise bağlantı reddi veya zaman aşımı durumlarını gösterir. Raporda son 90 gün içinde kabul edilebilir olmayan bir hata oranı varsa Search Console bunu uyarı simgesiyle belirtir; ayrıntıya tıklayarak hangi günlerde sorun yaşandığını görebilirsiniz.
Talep tarafı nedenler: kalite ve güncellik sinyalleri
Sunucu tarafı temizse, sıra tarama talebine gelir. Google bir sayfayı ne sıklıkla taramak istediğine karar verirken sayfanın ne kadar değiştiğini gözlemler. Her ziyarette aynı içeriği bulduğu bir sayfayı giderek daha seyrek ziyaret eder. Bu tamamen mantıklıdır: bir yıl boyunca hiç güncellenmeyen bir "Hakkımızda" sayfasının her gün taranmasına gerek yoktur. Dolayısıyla eski bir yazının tarama sıklığının düşmesi, yazının kötü olduğu anlamına gelmez; yalnızca durağan olduğunu gösterir.
Öte yandan sitenin genel algılanan kalitesi de talebi etkiler. Google, çok sayıda ince, birbirinin kopyası ya da değersiz sayfa bulduğu sitelerde taramaya daha temkinli yaklaşabilir. Otomatik üretilmiş etiket arşivleri, boş kategori sayfaları, sayısız filtre kombinasyonuyla oluşan URL'ler ve neredeyse aynı metni taşıyan sayfalar bu algıyı olumsuz yönde besler. Google bunları taramak için zaman harcadıkça, gerçekten önemli sayfalara ayırdığı ilgi azalır.
Burada sık yapılan bir hata da "tarih değiştirerek güncel görünme" çabasıdır. Sayfada anlamlı bir değişiklik yapmadan yalnızca yayın tarihini veya sitemap'teki lastmod değerini güncellemek kalıcı bir fayda sağlamaz. Google, lastmod değerini yalnızca tutarlı ve doğru olduğunu gördüğü sitelerde dikkate aldığını belirtir. Sürekli yanlış tarih veren bir sitemap zamanla güvenilirliğini kaybeder.
| Talep sinyali | Taramayı azaltan durum | Taramayı artıran durum |
|---|---|---|
| Güncellik | İçerik aylarca değişmiyor | Anlamlı, düzenli güncellemeler |
| Popülerlik | Hiç dış veya iç bağlantı almıyor | Önemli sayfalardan ve dış sitelerden bağlantı alıyor |
| Algılanan kalite | Çok sayıda ince veya kopya sayfa | Özgün, derinlikli, kullanıcıya faydalı içerik |
| lastmod güvenilirliği | Değişiklik olmadan tarih güncelleniyor | Tarih yalnız gerçek değişiklikte güncelleniyor |
| Envanter temizliği | Sonsuz filtre ve parametre URL'leri | Kanonik, tekil ve anlamlı URL yapısı |
İç linklerin tarama sıklığına etkisi
Googlebot yeni ve güncellenen sayfaları büyük ölçüde bağlantıları takip ederek bulur. Ana sayfadan veya sık taranan kategori sayfalarından bağlantı alan bir sayfa, derinlerde kalmış ve yalnızca sayfalamanın yirminci sayfasından ulaşılabilen bir sayfaya göre çok daha sık ziyaret edilir. Bir sayfanın tarama sıklığı düştüyse, önce o sayfaya sitenin içinden kaç bağlantı gittiğine bakın. Menüden kaldırılmış, ilgili yazılar bölümünden çıkmış ya da bir yeniden tasarımda bağlantıları kopmuş sayfalar sıklıkla "unutulur".
İç bağlantıların Googlebot tarafından izlenebilir olması da önemlidir. Bağlantılar standart <a href> etiketiyle verilmeli; yalnızca JavaScript tıklama olaylarıyla çalışan, href değeri olmayan "bağlantılar" güvenilir şekilde takip edilmez. Aynı şekilde içeriği iframe içinde yükleyen yapılar, bağlantıların ve metnin ana sayfaya ait sayılmasını zorlaştırabilir; bu tür bir sorunla uğraşıyorsanız WordPress iframe sorunu nasıl çözülür yazısı teknik tarafı açıklıyor.
Pratik bir kural: önemli bir sayfaya ana sayfadan en fazla birkaç tıklamayla ulaşılabilmeli, en az birkaç ilgili sayfadan bağlam içi bağlantı almalı ve bu bağlantıların anlamlı bir metni olmalıdır. "Buraya tıklayın" yerine sayfanın konusunu anlatan bir bağlantı metni, hem kullanıcıya hem de Google'a sayfanın ne hakkında olduğunu söyler.
Sitemap'in rolü ve sınırları
XML site haritası, Google'a "bu URL'ler var ve önemli" demenin en doğrudan yoludur. Ancak sitemap bir garanti değil, bir ipucudur. Sitemap'e eklenen bir URL'nin taranacağı veya dizine gireceği kesin değildir; Google yine talep ve kapasite dengesine göre karar verir. Yine de doğru kurulmuş bir sitemap, özellikle yeni ve derinde kalan sayfaların keşfini belirgin şekilde hızlandırır.
Sitemap'in tarama verimliliğine katkı sağlaması için birkaç kurala uyulmalıdır. Yalnızca kanonik, 200 döndüren ve dizine eklenmesini istediğiniz URL'ler listelenmelidir. Yönlendiren, 404 veren, noindex taşıyan veya başka bir sayfayı kanonik gösteren URL'ler sitemap'te bulunmamalıdır; aksi halde Google boşa istek harcar ve sitemap'inize olan güveni azalır. lastmod değeri gerçek değişiklik tarihini yansıtmalıdır. Büyük sitelerde sitemap'i konulara veya içerik türüne göre bölmek, Search Console'da hangi bölümün ne kadar dizine girdiğini ayrı ayrı izlemeyi kolaylaştırır.
Search Console Tarama İstatistikleri raporu nasıl okunur?
Rapora Search Console'da sol menüdeki Ayarlar bölümünden, Tarama başlığı altındaki Tarama İstatistikleri seçeneğiyle ulaşılır. Rapor yalnızca alan adı düzeyindeki veya kök düzey mülklerde tam olarak görüntülenir; arayüz ayrıntıları sürüme göre değişebilir. Ekranın üstünde üç temel grafik bulunur: toplam tarama isteği, toplam indirme boyutu ve ortalama yanıt süresi. Bu üç çizgiyi birlikte okumak teşhisin anahtarıdır.
Ortalama yanıt süresi yükselirken istek sayısı düşüyorsa, tablo neredeyse kesin olarak kapasite sorununu gösterir. Yanıt süresi sabit ve düşükken istek sayısı azalıyorsa, sorun büyük olasılıkla talep tarafındadır. İndirme boyutunun ani artışı ise sayfalarınızın ağırlaştığını, örneğin büyük satır içi kodlar veya sıkıştırılmamış kaynaklar eklendiğini gösterebilir.
Grafiklerin altında dört döküm bulunur: yanıta göre, dosya türüne göre, amaca göre ve Googlebot türüne göre. Yanıta göre dökümde 5xx, 429, 404 ve yönlendirme oranlarını görürsünüz. Amaca göre döküm, isteklerin ne kadarının keşif (daha önce bilinmeyen URL'ler) ne kadarının yenileme (bilinen URL'lerin tekrar taranması) olduğunu gösterir. Yeni içerik yayınladığınız halde keşif oranı çok düşükse, Google yeni URL'lerinizi bulmakta zorlanıyor olabilir; bu da iç link ve sitemap tarafına işaret eder. Googlebot türüne göre dökümde akıllı telefon ve masaüstü tarayıcıların yanı sıra görsel, video ve sayfa kaynağı yükleme istekleri de görünür.
Adım adım çözüm planı
Teşhisi yaptıktan sonra müdahaleyi sırayla uygulamak, hangi değişikliğin işe yaradığını anlamanızı sağlar. Aşağıdaki sıra, en çok etki yaratan ve en hızlı sonuç veren adımlardan başlar.
Birinci adım, sunucu sağlığını düzeltmek. Sunucu erişim günlüklerinde Googlebot isteklerini filtreleyin ve yanıt kodları ile sürelerini inceleyin. Günlüklerde Googlebot gibi görünen her isteğin gerçekten Google'dan gelmediğini unutmayın; ters DNS sorgusu veya Google'ın yayımladığı IP aralıklarıyla doğrulama yapın. Veritabanı sorgularını hızlandırın, sayfa önbelleğini etkinleştirin, gerekiyorsa barındırma paketini yükseltin. Paylaşımlı sunucudaysanız ve yanıt süreleri gün içinde büyük dalgalanma gösteriyorsa, sorun komşu sitelerden kaynaklanıyor olabilir.
İkinci adım, hata ve engel kurallarını temizlemek. 5xx veren URL'leri tespit edip uygulama hatalarını giderin. WAF, CDN ve hız sınırlayıcı ayarlarında doğrulanmış arama motoru tarayıcılarını istisna tutun. robots.txt dosyasının her zaman 200 ile ve hızlı şekilde döndüğünden emin olun.
Üçüncü adım, tarama israfını azaltmak. Sonsuz filtre kombinasyonları, oturum kimliği taşıyan URL'ler, takvim sayfaları gibi Googlebot'un zamanını tüketen alanları belirleyin. Dizine girmesini hiç istemediğiniz ve taranmasına da gerek olmayan bölümler için robots.txt engeli uygun olabilir. Yönlendirme zincirlerini tek adıma indirin, soft 404 veren sayfaları gerçek 404 veya 410 yapın.
Dördüncü adım, talebi güçlendirmek. Önemli sayfalara iç bağlantı ekleyin, eski içerikleri anlamlı şekilde güncelleyin, ince ve kopya sayfaları birleştirin veya kaldırın. Sitemap'i yalnız kanonik URL'lerle sadeleştirin.
Beşinci adım, izlemek. Değişikliklerden sonra Tarama İstatistikleri raporunu birkaç hafta boyunca izleyin. Kapasite sorunları düzeldiğinde Google hızı genellikle kademeli olarak artırır; bir gecede eski seviyeye dönmesini beklemeyin.
| Adım | Kontrol edilecek yer | Başarı işareti |
|---|---|---|
| Sunucu sağlığı | Tarama İstatistikleri, ortalama yanıt süresi; sunucu günlükleri | Yanıt süresi düşüyor ve kararlılaşıyor |
| Hata temizliği | Yanıta göre döküm, ana makine durumu | 5xx ve 429 oranı sıfıra yakın |
| Tarama israfı | Sayfa dizine ekleme raporu, günlüklerdeki parametreli URL'ler | Gereksiz URL isteklerinin payı azalıyor |
| Talep | Amaca göre döküm (keşif / yenileme) | Yeni içerik daha hızlı keşfediliyor |
| İzleme | Toplam tarama isteği grafiği | Birkaç haftalık kademeli toparlanma |
Yapılmaması gerekenler
Tarama sorunlarıyla uğraşırken iyi niyetli ama zararlı birkaç hamle sık görülür. Birincisi, tarama bütçesini "önemli sayfalara yönlendirmek" için noindex kullanmaktır. noindex bir sayfanın dizine girmesini engeller, ancak Google'ın o sayfayı taramasını engellemez; Google noindex'i görmek için sayfayı zaten taramak zorundadır. Bu yüzden noindex tarama tasarrufu sağlamaz.
İkincisi, robots.txt'yi sürekli değiştirerek bütçeyi bir bölümden diğerine kaydırmaya çalışmaktır. Google, robots.txt'nin tarama bütçesini geçici olarak yeniden dağıtmak için kullanılmamasını önerir; bu dosya, uzun vadede taranmasını istemediğiniz alanları belirlemek içindir. Üçüncüsü, sunucu zorlanırken tüm siteyi 403 veya 404 ile kapatmaktır. Bu kodlar "içerik yok" veya "erişim yasak" anlamına gelir ve URL'lerin dizinden düşmesine yol açabilir; acil yük azaltma için kısa süreli 503 veya 429 çok daha güvenlidir.
Dördüncüsü, URL denetleme aracındaki dizine eklenme isteğini toplu şekilde kullanmaya çalışmaktır. Bu özellik tek tek önemli sayfalar içindir, günlük bir kotası vardır ve genel tarama sorununu çözmez. Beşincisi de tarama hızının artacağı beklentisiyle yapay ve anlamsız güncellemeler yapmaktır; Google'ın değişikliği değersiz bulması, uzun vadede güncellik sinyalinizi zayıflatır.
Farklı site türlerinde tipik senaryolar
Küçük bir işletme sitesinde tarama düşüşü çoğunlukla ya barındırma kaynaklıdır ya da doğal bir durulmadır. Örneğin yeni açılan bir site ilk haftalarda yoğun taranır, Google envanteri öğrendikten sonra istek sayısı azalır. Yerel işletmeler için tarama sıklığından daha belirleyici olan genellikle işletme profilinin ve sitenin tutarlılığıdır; bu konuda Google Harita açma ve işletme kaydetme rehberi tamamlayıcı bilgi sunar.
Blog ve haber sitelerinde, yeni yazıların hızlı keşfi kritik olduğundan, ana sayfadaki son yazılar listesinin ve kategori sayfalarının sunucu tarafında oluşturulmuş, izlenebilir bağlantılar içermesi önemlidir. Sonsuz kaydırma ile yüklenen listelerde, her sayfanın ayrı ve erişilebilir bir URL'si olması gerekir. Etiket sayfalarının kontrolsüz çoğalması da bu tür sitelerde en yaygın tarama israfı kaynağıdır.
E-ticaret sitelerinde asıl risk faset navigasyondur. Renk, beden, fiyat aralığı ve sıralama seçeneklerinin her kombinasyonu ayrı bir URL üretiyorsa, Googlebot on binlerce neredeyse aynı sayfayla karşılaşır. Bu durumda gerçekten aranan kombinasyonları kanonik ve taranabilir bırakıp gerisini tarama dışında tutmak, ürün sayfalarının daha sık taranmasını sağlar. Stoktan kalkan ürünlerin nasıl ele alındığı da önemlidir: kalıcı olarak kalkan ürünler için ilgili bir sayfaya yönlendirme veya 404/410, geçici olanlar için ise sayfanın açık kalması genellikle doğru yaklaşımdır.
| Site türü | En yaygın neden | Öncelikli çözüm |
|---|---|---|
| Küçük kurumsal site | Yavaş paylaşımlı barındırma, doğal durulma | Önbellek ve barındırma iyileştirmesi |
| Blog / haber | Zayıf iç link, etiket sayfası şişkinliği | Son yazılar bağlantıları, etiket temizliği, güncel sitemap |
| E-ticaret | Faset ve parametre URL patlaması | Kanonik yapı, gereksiz kombinasyonları tarama dışı tutma |
| Çok dilli site | Yanlış hreflang ve kopya dil sürümleri | Tutarlı hreflang, her dil için ayrı sitemap |
| JavaScript ağırlıklı site | Bağlantıların yalnız istemci tarafında oluşması | Sunucu tarafı işleme veya ön işleme, gerçek href bağlantıları |
Sunucu günlükleriyle derin teşhis
Tarama İstatistikleri raporu özet bir görünüm sunar; ayrıntıya inmek için sunucu erişim günlükleri en güvenilir kaynaktır. Günlüklerde doğrulanmış Googlebot isteklerini ayıkladıktan sonra şu sorulara yanıt arayın: Googlebot günde hangi URL'leri kaç kez istiyor? İsteklerin ne kadarı parametreli, yönlendirilen veya hata veren adreslere gidiyor? En önemli sayfalarınız son ne zaman ziyaret edilmiş? Yanıt süreleri günün hangi saatlerinde uzuyor?
Bu analiz çoğu zaman şaşırtıcı sonuçlar verir. Örneğin Googlebot'un zamanının önemli bir kısmını eski bir kampanyadan kalan takip parametreli adreslere, silinmiş sayfalara giden yönlendirme zincirlerine veya dahili arama sonuç sayfalarına harcadığı ortaya çıkabilir. Bu israf alanlarını kapattığınızda, aynı tarama kapasitesiyle önemli sayfalar daha sık ziyaret edilir. Günlük analizi için özel araçlar kullanılabileceği gibi, küçük sitelerde basit bir tablo programı ve filtreleme de yeterli olur.
Günlüklerde ayrıca yanıt süresinin belirli saatlerde sıçrayıp sıçramadığına bakın. Yedekleme işleri, zamanlanmış görevler veya yoğun kampanya saatleri sunucuyu zorluyorsa, Googlebot tam o saatlerde yavaş yanıt alır ve hızı genel olarak düşürebilir. Ağır işleri trafiğin düşük olduğu saatlere kaydırmak, bazen tek başına tarama grafiğini toparlar.
Sayfa ağırlığı ve kaynak dosyaları
Googlebot yalnızca HTML'i değil, sayfanın işlenmesi için gereken CSS, JavaScript ve bazı görsel kaynakları da indirir. Bu kaynak istekleri de tarama kapasitesinden pay alır. Her sayfada sürüm numarası değişen, önbelleğe alınamayan ya da gereksiz yere çok sayıda parçaya bölünmüş kaynak dosyaları, Googlebot'un HTML'e ayırabileceği zamanı azaltır. Kaynak dosyalarını mümkün olduğunca paylaşımlı, uzun süre önbelleğe alınabilir ve sıkıştırılmış şekilde sunmak, tarama verimliliğine dolaylı ama gerçek bir katkı sağlar.
Ayrıca HTML sayfaların kendisinin gereksiz yere büyümemesine dikkat edin. Satır içi gömülmüş devasa veri blokları, tekrar eden şablon kodları veya sayfaya eklenen büyük izleme betikleri indirme boyutunu artırır. Tarama İstatistikleri raporundaki toplam indirme boyutu grafiği, bu tür ağırlaşmayı fark etmenin kolay bir yoludur. Sunucunuzun sıkıştırma desteği ve koşullu istek yanıtları (değişmemiş içerik için 304) da Googlebot'un aynı içeriği tekrar tekrar indirmesini önleyebilir.
Son olarak, yeniden tasarım veya altyapı değişikliği sonrasında tarama düşüşü yaşıyorsanız, değişiklik tarihini raporla eşleştirin. Yeni tema, eklenti veya sunucu taşıması, çoğu zaman yanıt süresinde veya hata oranında görünür bir iz bırakır. Bu eşleştirme, sorunun kaynağını tahmin etmek yerine kanıta dayalı bulmanızı sağlar.
Sık Sorulan Sorular
Googlebot'un siteyi daha az taraması sıralamayı düşürür mü?
Doğrudan hayır. Tarama sıklığı bir sıralama faktörü değildir. Ancak güncellemeleriniz geç fark edilirse veya yeni sayfalar dizine geç girerse, dolaylı olarak trafik kaybı yaşayabilirsiniz.
Tarama hızını Search Console'dan elle artırabilir miyim?
Hayır. Eski tarama hızı sınırlayıcı aracı kaldırıldı ve zaten yalnızca hızı düşürmeye yarıyordu. Tarama hızını artırmanın yolu sunucu kapasitesini ve sayfa talebini iyileştirmektir.
Ortalama yanıt süresi kaç milisaniye olmalı?
Google kesin bir eşik vermez. Genel olarak daha düşük ve kararlı yanıt süresi daha fazla tarama kapasitesi anlamına gelir. Önemli olan, sürenin zaman içinde yükselmemesi ve gün içinde sert dalgalanmamasıdır.
503 hatası ne kadar süre güvenlidir?
Kısa bakım süreleri için uygundur. Google, uzun süre boyunca hata döndüren URL'leri dizinden düşürmeye başlayabilir; bu yüzden 503'ü birkaç saatlik veya en fazla kısa süreli durumlarla sınırlamak en güvenlisidir.
Sitemap göndermek taramayı hemen artırır mı?
Hayır, sitemap bir ipucudur. Yeni URL'lerin keşfini hızlandırır ama tarama miktarını belirleyen yine kapasite ve taleptir.
Bir sayfanın en son ne zaman tarandığını nasıl görürüm?
Search Console'daki URL denetleme aracında sayfanın URL'sini sorgulayın. Dizine eklenmiş sayfalar için son tarama tarihi ve taramayı yapan tarayıcı türü gösterilir.
robots.txt ile engellediğim sayfalar yine de dizinde görünebilir mi?
Evet. robots.txt taramayı engeller, dizine eklemeyi değil. Başka sitelerden bağlantı alan engelli bir URL, içeriği olmadan dizinde görünebilir. Dizinden çıkarmak için sayfanın taranabilir olup noindex taşıması gerekir.
Günlüklerde çok fazla Googlebot isteği görüyorum, gerçek mi?
Her zaman değil. Birçok bot kendini Googlebot olarak tanıtır. Ters DNS sorgusuyla alan adının googlebot.com veya google.com ile bittiğini ve ileri sorgunun aynı IP'ye döndüğünü doğrulayın ya da Google'ın yayımladığı IP listeleriyle karşılaştırın.
Tarama düzelince eski seviyeye ne kadar sürede döner?
Kesin bir süre yoktur. Kapasite sorunları giderildiğinde Google hızı genellikle kademeli olarak artırır; birkaç gün ile birkaç hafta arasında toparlanma görmek olağandır.

Yorumlar (0)
Yorum Yaz
Henüz yorum yapılmamış. İlk yorumu siz yapın!