Tarama istatistikleri raporunda ani düşüşte önce hangi sinyaller?

Tarama istatistikleri raporunda ani düşüşte önce kapsamı daraltın

Tarama istatistikleri raporunda ani bir düşüş gördüğünüzde ilk refleks tüm sitenin taramadan çıktığını varsaymak olmamalı. Önce düşüşün site geneline mi, belirli bir hosta mı, tek bir alt alana mı yoksa tek klasöre mi sıkıştığını ayırın. Google Search Console Yardımı’ndaki Tarama İstatistikleri raporu açıklamasına göre rapor; toplam istek, ortalama yanıt süresi, ana makine durumu, tarama yanıtları, dosya türü ve tarama amacı kırılımlarıyla okunmalı (Google Search Console Yardımı, 2026).

Pratikte en hızlı yöntem son 7 günü önceki 28 günle karşılaştırmaktır. Aynı zamanda saatlik kırılımı açıp düşüşün tek bir yayın saatine mi denk geldiğini, yoksa gün boyu yaygın mı olduğunu kontrol edin. Domain property kullanıyorsanız host listesinde belirli alt alanı seçin; örneğin yalnızca blog alt alanı düşmüşse kök alan adı için panik üretmeyin. Bu ayrım, sizi gereksiz CDN, veritabanı veya içerik denetimlerinden kurtarır.

• HTML istekleri düştü ama resim ve JS stabil kaldıysa sorun çoğu zaman sayfa keşfi veya uygulama katmanındadır.
• Tek klasör düştüyse yeni routing, canonical veya noindex hatası ihtimali güçlenir.
• Yalnızca belirli saatlerde düşüş varsa deploy, cron veya rate limit kuralı şüphesi öne çıkar.

Bu aşamada tek hedef, problemi daraltmaktır. Çünkü ani düşüşlerin önemli bir kısmı tüm alan adına değil, tek hosta veya tek teslim katmanına çarpar. Özellikle son 90 gün içinde birden fazla alt alanı olan yapılarda Search Console’un host kapsamı ayrımı, ilk karar ağacının temelidir. Düşüşün gerçek sınırını görmeden 5xx ya da crawl demand yorumuna geçmek çoğu zaman yanlış teşhise yol açar.

Ana makine durumu, robots.txt, DNS ve sunucu bağlantısını ilk sırada kontrol edin

Eğer ana makine durumu sarıdan kırmızıya dönmüşse ilk bakılacak alanlar nettir: robots.txt getirme, DNS çözümleme ve sunucu bağlantısı. Search Console Yardımı açık biçimde, kırmızı host status durumunda bu üç kırılımın ayrı ayrı incelenmesini önerir; ayrıca robots.txt erişilemezse Google’ın kabul edilebilir bir yanıt alana kadar taramayı yavaşlatabileceğini veya durdurabileceğini söyler (Google Search Console Yardımı, 2026).

İlk kontrolü değişiklik günlüğü üzerinden yapın. Son deploy ile birlikte robots meta, robots.txt, CDN kuralı, WAF filtresi, origin routing veya cache davranışı değişti mi? Robots.txt tarafında yalnızca dosyanın içeriğine bakmak yetmez; dosyanın gerçekten 200, 404 veya 410 gibi kabul edilebilir bir yanıt döndürdüğünü de doğrulamak gerekir. Geçici 503, sonsuz yönlendirme veya bağlantı zaman aşımı, dosya içeriği doğru olsa bile tarama akışını bozar.

DNS ve ağ tarafı ayrı düşünülmelidir. Google’ın 2025-12-18 tarihli DNS ve ağ hata kılavuzu, ağ zaman aşımlarını, connection reset vakalarını ve DNS hatalarını 5xx benzeri güçlü negatif sinyal olarak ele aldığını; bu durumda taramanın hızla yavaşlamaya başladığını söyler (Google for Developers, 2025-12-18). Bu yüzden A kaydı, CNAME, nameserver değişimi, CDN geçişi, firewall kuralı ve bot koruması aynı anda gözden geçirilmelidir.

• Robots.txt isteği gerçekten yanıt alıyor mu, yoksa CDN katmanında boşa mı düşüyor?
• DNS kayıtları son değişiklikten sonra doğru IP ve hosta mı işaret ediyor?
• Firewall veya bot koruması Googlebot’u yanlışlıkla zorlaştırıyor mu?
• Origin sunucu bağlantı kabul ediyor ama tam yanıtı yarıda mı kesiyor?

Buradaki kritik nokta şudur: host status kırmızıysa içerik kalitesinden önce erişilebilirlik konuşulur. İçerik güncellemesi, sitemap iyileştirmesi veya anahtar kelime genişletmesi daha sonra gelir. Önce Googlebot’un kapıya ulaşıp ulaşamadığını, ulaştıysa robots.txt ve ilk HTML yanıtlarını güvenli biçimde alıp almadığını netleştirin.

5xx, 429 ve ortalama yanıt süresiyle crawl capacity daralmasını doğrulayın

Host status temiz görünse bile tarama grafiği düşmüş olabilir. Bu durumda ikinci katman 5xx, 429 ve ortalama yanıt süresi okumaktır. Google’ın 2026-02-04 güncel HTTP durum kodları dokümantasyonu, 429’u sunucunun aşırı yük sinyali olarak ele alır ve 5xx ile birlikte tarama hızının geçici olarak düşebileceğini açıkça belirtir. Sunucu yeniden sağlıklı 2xx döndürmeye başladığında tarama da kademeli olarak toparlanır (Google for Developers, 2026-02-04).

Burada Search Console grafiğini tek başına okumayın. Saatlik ham sunucu logları, CDN logları ve WAF olay kayıtları ile eşleştirme yapın. Eğer 11:00 ile 14:00 arasında 429 ve 503 artışı varsa, aynı zaman penceresinde kuyruk gecikmesi, veritabanı bekleme süresi, PHP worker doygunluğu, edge timeout veya yanlış rate limit kuralı olup olmadığına bakın. Ortalama yanıt süresindeki sıçrama çoğu zaman sorunun belirtilerinden biridir; kök neden ise uygulama veya teslim katmanında saklıdır.

Bu bölümde 404 ve yönlendirme oranlarını da okuyun ama önceliği doğru verin. Google dokümanına göre 429 dışındaki çoğu 4xx kodu crawl rate’i düşürmez; asıl daralma sinyali 429 ile 5xx tarafında görünür. Uzun yönlendirme zincirleri, soft 404’ler ve gereksiz URL envanteri ise kapasiteyi doğrudan değil, verimliliği düşürerek etkiler. Teknik görünümü tek ekranda toparlamak için bir site sağlığı kontrolü akışı bu aşamada faydalı olur.

• GSC yanıt kodu eğrisi ile loglardaki saatlik hata artışı eşleşiyor mu?
• TTFB yükselirken uygulama kuyruğu ve veritabanı bekleme süresi de artıyor mu?
• 429 yalnızca anonim trafik için mi, yoksa Googlebot benzeri tarayıcılarda da mı görülüyor?
• CDN, WAF veya origin tarafında farklı timeout limitleri birbirini mi tetikliyor?

Eğer 5xx ve 429 belirgin biçimde artmış, yanıt süresi de yükselmişse yorum nettir: sorun büyük olasılıkla crawl capacity tarafındadır. Yani Google istemediği için değil, siteniz aynı hızda servis veremediği için daha temkinli tarıyordur. Bu ayrımı erken koymak, gereksiz içerik denetimlerini ikinci plana atar.

Keşif mi yenileme mi düştü: dahili bağlantı, sitemap ve lastmod sinyalleri

Teknik erişilebilirlik normal, 5xx ve 429 düşük, yanıt süresi stabilse artık crawl demand tarafına geçebilirsiniz. Google’ın 2025-12-19 güncel crawl budget dokümanı, tarama bütçesinin iki ana unsurdan oluştuğunu söyler: crawl capacity limit ve crawl demand. Aynı dokümana göre kapasite tavanına hiç çarpmasanız bile talep düşükse Google sitenizi daha az tarır (Google for Developers, 2025-12-19).

Tarama amacı bölümünde keşif düşüyorsa yeni URL akışınız, dahili bağlantı mimariniz ve sitemap kapsamınız incelenmelidir. Yeni sayfalar ana şablonlardan zayıf link alıyorsa, derin klasörlerde kalıyorsa veya XML sitemap’te eksikse Google bunları daha geç keşfeder. Aynı zamanda gereksiz filtre URL’leri, parametreli çoğaltmalar ve yinelenen varyasyonlar envanteri şişirerek gerçek önemli URL’lerin keşif payını aşağı çeker.

Yenileme düşüyorsa soru farklıdır: Google bildiği URL’lere neden daha az dönüyor? Bu noktada içerik tazeliği, lastmod doğruluğu, canonical tutarlılığı, soft 404 sinyalleri ve yönlendirme zincirleri devreye girer. Lastmod alanı sürekli güncelleniyor ama içerikte gerçek değişiklik yoksa sinyal değeri düşer. Canonical kararsızsa veya aynı niyeti taşıyan çok sayıda benzer sayfa varsa, Google hangi URL’yi daha sık yenileyeceği konusunda daha seçici davranır.

Bu ayrımı ekip içinde doğru isimlerle konuşmak önemlidir. crawl budget sözlüğü üzerinden capacity, demand, soft 404 ve canonical kavramlarını netleştirmek, rapor yorumlarını hızlandırır. Teknik sinyaller temiz kaldığı halde keşif ve yenileme zayıflıyorsa; içerik güncelliği, URL popülerliği, iç link yerleşimi ve sitemap dürüstlüğü çoğu zaman asıl çalışma alanıdır.

GSC, sunucu logu ve CDN/WAF loglarında üç gerçek düşüş paterni

Pratikte en sık gördüğümüz üç patern var ve hepsi Search Console ekranında benzer görünen bir düşüş üretse de kök nedenleri farklıdır. Bu yüzden tek grafiğe bakmak yerine GSC, ham sunucu logları ve CDN/WAF loglarını aynı zaman eksenine koymak gerekir. Saat saat olay akışı, özellikle ani düşüşlerde rapor yorumundan daha güvenilir bir teşhis dili sağlar.

Birinci patern robots.txt dağıtım hatasıdır. Tipik akış şudur: sabah deploy alınır, birkaç dakika sonra robots.txt isteği edge tarafında 503 döndürmeye başlar, ardından host status sarıya ve kırmızıya yaklaşır. GSC grafiğinde toplam istekler sert kırılırken uygulama ana HTML sayfaları bazen hâlâ 200 döndürür; bu yüzden sorun yalnızca sayfa örneklerine bakınca kaçırılır. Robots.txt düzeltildiğinde aynı gün loglar normale döner, GSC ise bir sonraki veri döngüsünde toparlanır.

İkinci patern 429 ve 5xx sıçramasıdır. Burada asıl hata çoğu zaman yanlış rate limit, aşırı agresif bot koruması veya origin kapasite sınırıdır. User-agent adına güvenip karar vermek yanlıştır; gerçek Googlebot trafiğini log tarafında ayrıca doğrulamak gerekir. Eğer hata yoğunluğu yalnızca belirli path gruplarında artıyorsa CDN kuralı, yalnızca belirli saatlerde artıyorsa kuyruk ve kapasite baskısı daha olasıdır. Bu vakalarda GSC yanıt kodu grafiği ile log korelasyonu doğrudan kanıt üretir.

Üçüncü patern daha sessizdir: teknik arıza yoktur ama crawl demand azalır. Host status yeşildir, 5xx ve 429 normaldir, yanıt süresi bozulmamıştır; buna rağmen keşif veya yenileme grafiği aşağı eğilir. Bu durumda içerik tazeliği, iç link görünürlüğü ve sorgu değerindeki değişim öne çıkar. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer benzer veri katmanları sunar; SEOYEN ise bu ayrımı Türkiye pazarına uyarlanmış biçimde, Türkçe arayüz ve yerel Türkçe destekle tek platformda toplar. Özellikle sıralama takibi ile teknik olmayan düşüşü ayırın ve anahtar kelime aracı ile talep düşüşünü ölçün yaklaşımı, teknik sorun yokken arama talebi ve görünürlük tarafını daha hızlı netleştirir.

Bu son tabloda operasyonel pratik de önemlidir. Teknik ekip, içerik ekibi ve SEO tarafı tek bir çalışma dili kullanmıyorsa demand düşüşü çoğu zaman geç fark edilir. SEOYEN’in TL fiyatlı paket ve abonelik detayları ayrı bir sayfada tutulurken; site sağlığı, görünürlük ve anahtar kelime takibini aynı akışta buluşturması küçük ekipler için işi sadeleştirir. Özellikle yerli destek ihtiyacı olan işletmelerde bu, yalnızca araç tercihi değil operasyon hızıdır.

Adım Adım: Tarama düşüşünde ilk 30 dakikalık teşhis akışı

Ani düşüşte amaç her metriği aynı anda incelemek değil, yanlış ihtimalleri hızla elemek olmalı. Aşağıdaki akış ilk 30 dakikada sorunu teknik erişilebilirlik, kapasite veya demand tarafına yerleştirmek için yeterlidir. Ekip içinde ekran paylaşımı yapıyorsanız bu adımları aynı zaman ekseninde işlemek en verimli yöntemdir.

1. Düşüşün kapsamını segmentlere ayırın: Önce site geneli, host, alt alan, klasör ve saatlik kırılımı ayırın. Ardından dosya türü ve tarama amacı kırılımlarını açın. Böylece düşüşün tüm mülkte mi, tek dizinde mi, yalnızca HTML’de mi, yoksa keşif tarafında mı yoğunlaştığını birkaç dakika içinde netleştirirsiniz.
2. Host status ve robots.txt erişimini doğrulayın: Ana makine durumu sarı veya kırmızıysa ilk iş robots.txt getirimini doğrulamak olmalı. Dosyanın yalnızca içeriğini değil, CDN ve origin boyunca gerçekten kabul edilebilir yanıt verip vermediğini test edin. Son deploy, header, firewall veya cache kuralı değişikliklerini aynı anda kontrol edin.
3. DNS ve sunucu bağlantı hatalarını ayıklayın: DNS çözümleme, TLS el sıkışması, bağlantı zaman aşımı ve edge reset kayıtlarını ayrı okuyun. Özellikle son nameserver, CDN veya routing değişikliği varsa A ve CNAME kayıtlarını doğrulayın. Ağ katmanındaki sorunlar, uygulama sağlıklı görünse bile Googlebot tarafında ani düşüş üretebilir.
4. 5xx, 429 ve yanıt süresini eşleştirin: Search Console yanıt kodu grafiğini ham loglarla karşılaştırın. Aynı zaman aralığında 5xx veya 429 artışı, TTFB sıçraması, kuyruk doygunluğu ya da veritabanı gecikmesi varsa capacity daralması ihtimali güçlenir. GSC tek başına işaret verir; kanıtı loglar sağlar.
5. Crawl demand sinyallerini tazelikle test edin: Teknik katmanlar temizse keşif ve yenileme kırılımını açın. Sitemap dürüst mü, lastmod gerçek değişimi mi yansıtıyor, önemli URL’ler ana şablonlardan yeterli iç link alıyor mu, içerik güncelliği düşmüş mü sorularını yanıtlayın. Böylece teknik olmayan düşüşü yanlışlıkla altyapı arızası gibi ele almazsınız.

Bu akışın avantajı, en pahalı hatayı önlemesidir: yanlış ekibi yanlış soruna koşturmak. İlk yarım saatte erişilebilirlik, kapasite ve demand ayrımını doğru kurarsanız hem log analizi hem de içerik tarafındaki sonraki işler çok daha hızlı sonuç verir. İsterseniz bu süreci ekip içi ekran kaydı veya kısa bir Crawl Stats walkthrough videosuyla standart operasyon prosedürüne dönüştürebilirsiniz.

Sıkça Sorulan Sorular