Tarama anormalliği uyarısında teknik inceleme nasıl başlatılır?

Tarama anormalliği uyarısı görüldüğünde önce kapsamı ayırın

2026’da doğru başlangıç, etiketin kendisinden çok kapsamın netleştirilmesidir. Tarama anormalliği tek bir hata kodu değildir; Googlebot’un URL’yi beklenen şekilde alamadığı birkaç farklı durumu aynı uyarı altında toplayabilir. Bu yüzden önce uyarının hangi Search Console görünümünde çıktığını not edin: URL Denetleme sonucunda mı gördünüz, Sayfa dizine ekleme tarafında mı, yoksa Tarama İstatistikleri raporunda host düzeyinde mi bir bozulma var? Terimlerin bugünkü anlamını hızlı hatırlamak isterseniz SEO terimleri sözlüğü işe yarar.

İkinci adım, sorunu ölçek bazında ayırmaktır. Tek bir ürün sayfası etkileniyorsa URL veya içerik düzeyi; aynı klasördeki onlarca URL etkileniyorsa şablon, cache ya da kural düzeyi; farklı klasörlerden rastgele URL’ler etkileniyorsa host, DNS veya proxy katmanı daha olasıdır. Özellikle Tarama İstatistikleri’nde ana makine durumu bozuluyorsa önce uygulama koduna değil, bağlantı ve erişilebilirlik katmanına bakmak gerekir.

Üçüncü adım, bunun geçici bir Google tarafı test farkı mı yoksa kalıcı site problemi mi olduğunu ayırmaktır. Bu ayrım için canlı Google Search Status Dashboard kontrolü önemlidir; yaygın bir tarama olayı varsa gereksiz rollback yapmazsınız. Dashboard tarafında sorun görünmüyor, aynı anda loglarda 5xx veya 429 artıyorsa artık site içi teşhis moduna geçebilirsiniz.

• Tek URL: içerik, canonical, soft 404 veya render farkı şüphesi yüksektir.
• Klasör ya da şablon: yönlendirme, cache kuralı, CDN sayfa kuralı veya aynı bileşen hatası aranır.
• Host düzeyi: DNS, robots.txt getirme, WAF, bağlantı ve 5xx sınıfı önceliklidir.

URL Denetleme Aracı ve Tarama İstatistikleri ile ilk teyidi alın

İncelemeye varsayımla değil veriyle başlayın. Google’ın URL Denetleme Aracı belgesine göre araç, hem son dizine eklenen sürümün durumunu hem de canlı test ile mevcut erişilebilirliği ayrı ayrı gösterir. Bu ayrım kritik olduğu için aynı hatayı veren 3-5 URL seçip her biri için canlı test çalıştırın; tek örnek üzerinden karar vermek, geçici ağ hatasını kalıcı indeksleme sorunu sanmanıza yol açabilir.

Canlı test ile son dizine eklenen sürüm neden farklı çıkabilir? En yaygın nedenler son deploy sonrası değişen yanıt, anlık timeout, Google’ın daha önce gördüğü kaynaklarla bugünkü kaynakların farklı olması ve render sırasında kritik JavaScript ya da CSS dosyalarının alınamamasıdır. URL Denetleme ekranında taranan sayfa, alınan kaynaklar ve oluşturulmuş görünüm birlikte okunmadan sadece üstteki etiketle teşhis koymak eksik kalır.

Ardından Tarama İstatistikleri raporuna geçin. Bu rapor tek URL yerine host davranışını gösterir: ana makine durumu, robots.txt getirme, DNS çözümleme ve sunucu bağlantısı burada toplanır. Google’ın rapor açıklamasındaki örneğe göre günlük isteklerin yüzde 5’inden fazlasında DNS çözümlemesi başarısız olursa bu kategori sorun olarak işaretlenebilir; bu da sorunun artık sayfa bazlı değil host bazlı ele alınması gerektiğini gösterir.

• URL Denetleme: canlı erişim, render, alınan kaynak, son dizine eklenen sürüm.
• Tarama İstatistikleri: host durumu, yanıt dağılımı, robots.txt ve DNS sinyalleri.
• İlk teyit mantığı: önce birkaç URL’de doğrula, sonra host düzeyinde genellenip genellenmediğine bak.

DNS, robots.txt, 4xx, 5xx ve 429 sinyallerini sınıflandırın

Tarama anormalliğini çözmenin en pratik yolu, sinyali katmanlara ayırmaktır: ağ, erişim ve HTTP. Google’ın HTTP durum kodları belgesi 2026-02-04 UTC güncellemesinde 429 durum kodunun sunucunun aşırı yüklendiğine işaret eden bir sunucu hatası gibi ele alındığını, 5xx ve 429 yanıtlarının tarama hızını geçici olarak düşürdüğünü, 429 dışındaki 4xx yanıtlarının ise zamanla URL’nin kullanımını sonlandırdığını açıkça anlatır. Bu yüzden 404 ile 429’u aynı sepete koymak yanlış olur.

Robots.txt tarafı ayrı sınıflandırılmalıdır. Search Console’un Tarama İstatistikleri belgesinde robots.txt için 200, 404 ve 410 kabul edilebilir yanıtlar olarak geçer; buna karşılık 429 ve 5xx başarısız kabul edilir. Aynı belgede Google’ın başarılı bir robots.txt yanıtını yaklaşık 24 saat kullanabildiği, başarısızlıkta ilk 12 saat taramayı durdurabildiği ve 30 güne kadar son başarılı kopyayı kullanabildiği açıklanır. Bu, küçük görünen robots.txt erişim hatalarının neden host çapında etki yaratabildiğini açıklar.

Standart tarafında da çerçeve nettir. RFC 9309, robots.txt erişimi başarısız olduğunda tarayıcı davranışını tanımlar; Google Arama’nın pratik davranışını ise kendi dokümantasyonu daha ayrıntılı açıklar. Teşhiste bu ikisini birlikte okumak gerekir: standart size protokol mantığını verir, Google belgeleri ise Search Console’da göreceğiniz gerçek davranışı anlatır.

• DNS çözümleme hatası: host adı çözülemez ya da yanıt vermez; uygulama koduna gitmeden DNS sağlayıcısı ve zone kayıtları kontrol edilir.
• 429 Too Many Requests: çoğunlukla rate limit, WAF veya aşırı yük belirtisidir; tarama hızı düşebilir.
• 5xx hataları: origin, uygulama, upstream ya da proxy katmanında gerçek erişilebilirlik sorunu vardır.
• Kalıcı 4xx: özellikle 404 ve 410, sayfanın dizinden düşmesine giden yolu açar.
• robots.txt başarısızlığı: küçük bir dosya sorunu gibi görünse de tüm host taramasını yavaşlatabilir.

CDN, WAF, yönlendirme ve render engellerini kanıtlayın

Tarayıcıda sayfa açılıyor diye Googlebot’un aynı içeriği alabildiğini varsaymayın. Özellikle CDN, WAF, bot koruması ve ülke bazlı kurallar devredeyse normal tarayıcı 200 alırken Googlebot 403, 429, 503 ya da challenge sayfası görebilir. Bu tip sessiz engeller genelde uygulama logunda değil, proxy ve güvenlik loglarında görünür; bu yüzden tarama anormalliği soruşturmasında yalnızca origin erişim kayıtlarına bakmak yetmez.

Cloudflare’ın 5xx hata dokümantasyonu 2026-04-23 güncellemesinde, 5xx teşhisinde edge ve origin ayrımının ayrı okunması gerektiğini vurgular. Pratikte şu fark önemlidir: edge tarafında 502, 522 ya da 524 görüyorsanız sebep doğrudan uygulama kodu olmayabilir; arada timeout, origin’e ulaşılamama, SSL el sıkışması ya da güvenlik cihazı kesintisi olabilir. Bu ayrımı yapmadan sadece web sunucusuna odaklanmak zaman kaybettirir.

Yönlendirme ve render tarafında da benzer bir tuzak vardır. Google’ın HTTP belgesine göre genel tarayıcılar çoğu durumda 10 atlamaya kadar yönlendirme izler; buna karşılık Inspection Tools davranışı farklıdır ve uzun zincirler teşhisi bulanıklaştırabilir. Ayrıca yanlış canonical, istemci tarafında çalışan kırık yönlendirme, boş şablon, engellenmiş JS dosyası veya hata mesajı veren ama 200 dönen sayfalar Google’ın tarama hata giderme belgesinde anlatıldığı gibi soft 404 ya da render sorunu olarak yüzeye çıkabilir.

• Tarayıcı 200, Googlebot 403/429: WAF ya da bot koruması olasılığı artar.
• Edge 5xx, origin 2xx: CDN veya ara katman davranışı incelenir.
• Uzun yönlendirme zinciri: özellikle canlı test ile gerçek tarama davranışı farklılaşabilir.
• Boş ya da eksik render: kritik kaynakların yüklenememesi soft 404 benzeri sonuç üretir.

3-5 URL’de canlı test, curl ve logları yan yana okuyun

Tek URL ile teşhis koymak çoğu zaman yanıltır. Pratikte en güvenli yaklaşım, aynı uyarıyı veren 3-5 URL seçip her biri için tek bir kanıt zinciri oluşturmaktır: URL Denetleme canlı testi, access log, error log, varsa CDN/WAF kaydı ve curl başlık çıktısı. Bu dizilim bize en hızlı şekilde sorunun URL’ye mi, şablona mı, yoksa host katmanına mı ait olduğunu gösterir.

Burada izlediğimiz sıra nettir. Önce canlı testte hata türünü not ederiz; sonra aynı URL’ye hem normal kullanıcı aracısıyla hem de Googlebot kullanıcı aracısıyla HEAD isteği bakarız. Ardından access log’da zaman damgası, durum kodu, yanıt süresi ve upstream sonucu eşleştirilir. Eğer tarayıcıda açılan URL, Googlebot benzer isteğinde 429 ya da 503 veriyorsa problem artık içerikten çok rate limit, güvenlik kuralı veya kapasite tarafına kayar.

Gerçek Googlebot isteğini doğrularken sadece user-agent metnine güvenmeyin. Google’ın Google tarayıcı isteklerini doğrulama belgesi 2026-03-25 UTC itibarıyla ters DNS ve ileri DNS doğrulamasını önerir; yani logdaki IP için önce alan adını çözersiniz, sonra o alan adının tekrar aynı IP’ye döndüğünü doğrularsınız. Böylece kendini Googlebot gibi tanıtan sahte botları gerçek tarama sorunuyla karıştırmazsınız.

Google’ın tarama hatalarını giderme belgesi 2026-01-06 UTC güncellemesinde, aşırı yük anında 503 veya 429’un kısa süreli savunma mekanizması olarak kullanılabileceğini; ancak bunun birkaç günü aşması halinde taramayı kalıcı biçimde yavaşlatabileceğini hatırlatır. Yani loglarda bu kodları görmek bazen kontrollü bir koruma davranışı olabilir, fakat kalıcı hale gelmişse artık çözüm değil yeni sorundur.

• Canlı test: Google’ın anlık gördüğü erişim ve render sonucu.
• Access log: gerçek istek zamanı, durum kodu, user-agent, yanıt süresi.
• Error log: upstream timeout, PHP/FPM, veritabanı ya da reverse proxy sorunu.
• CDN/WAF logu: challenge, block, rate limit, bot skoru ve edge sonucu.
• curl doğrulaması: başlık, yönlendirme, cache ve HTTP davranışının hızlı teyidi.

Düzeltme sonrası doğrulama ve SEOYEN ile sürekli izleme

Düzeltme yapıldıktan sonra iş bitmiş sayılmaz; sorunun gerçekten kapandığını kanıtlamak gerekir. Önce aynı 3-5 URL’de canlı testi tekrar çalıştırın. Ardından host düzeyinde Tarama İstatistikleri raporunu izleyin: ana makine durumu yeşile dönüyor mu, robots.txt getirme hatası kayboluyor mu, 5xx ve 429 oranları düşüyor mu? Eğer sadece tek bir URL düzeldiyse ama host sinyali düzelmediyse kök neden hâlâ açıkta demektir.

İkinci doğrulama katmanı görünürlük etkisidir. Sorun çözülse bile tarama kesintisinin etkisi birkaç gün daha sürebilir; bu nedenle aynı dönemde hem teknik sağlık hem pozisyon değişimi izlenmelidir. Bu noktada tek platform yaklaşımı iş kolaylaştırır: site sağlığı taraması benzer teknik örüntülerin yeniden doğup doğmadığını, sıralama takibi etkilenen sayfa gruplarındaki görünürlük toparlanmasını ve AI görünürlük analizi marka anılmalarındaki olası etkileri ayrı araçlara dağılmadan izlemeye yardımcı olur.

SEOYEN’in farkı burada daha net görünür: tüm SEO araçlarını tek platformda toplaması, Türkçe arayüz sunması, TL bazlı fiyatlandırma ile planları erişilebilir kılması ve yerel Türkçe destek sağlaması. Özellikle manuel teşhisten düzenli izlemeye geçerken ekiplerin farklı paneller arasında kaybolmaması önemli olur; ayrıntı gerekiyorsa paketler ve fiyatlar sayfası güncel yapıyı gösterir. Bu yaklaşım agresif bir satış katmanı değil, tarama anormalliği tekrar ettiğinde dağınık teşhisi azaltan bir operasyon katmanıdır.

• Yeniden canlı test: aynı URL setinde hata gerçekten bitti mi kontrol edilir.
• Host status takibi: sorun tekil mi kaldı, yoksa host düzeyi tamamen temizlendi mi görülür.
• Tekrar eşiği: aynı şablonda yeni URL’ler yine hata veriyorsa düzeltme yüzeyseldir.
• Sürekli izleme: teknik sinyal ile görünürlük sinyali birlikte okunmalıdır.

Adım Adım Tarama anormalliği uyarısında teknik inceleme akışı

Aşağıdaki akış, uyarıyı gördüğünüz ilk 30 dakikada gereksiz panik yaşamadan ilerlemenizi sağlar. Buradaki amaç her şeyi aynı anda kontrol etmek değil, en fazla bilgi üreten sırayı izlemektir.

1. Uyarının rapor ve kapsamını netleştirin. Uyarının URL Denetleme, Sayfa dizine ekleme ya da Tarama İstatistikleri bağlamında nerede göründüğünü not edin. Sonra bunun tek URL, klasör, şablon veya host düzeyinde mi yayıldığını ayırın. Bu sınıflandırma yapılmadan başlanan her inceleme, genelde yanlış katmanda vakit kaybettirir.
2. Canlı URL testi ile ilk teyidi alın. Aynı hatayı veren 3-5 URL seçin ve canlı test çalıştırın. Son dizine eklenen sürüm ile canlı sürüm arasında fark varsa bunun deploy, cache, yönlendirme ya da render kaynaklı olup olmadığını düşünün. Tek URL yerine küçük bir örnek kümesiyle bakmak, geçici test farkını kalıcı sorun sanmayı önler.
3. Tarama İstatistikleri raporunda host sinyallerini okuyun. Ana makine durumu, robots.txt getirme, DNS çözümleme ve sunucu bağlantısı alanlarını aynı zaman aralığında inceleyin. Host status kırmızıysa uygulama katmanından önce ağ ve erişilebilirlik katmanını ele alın. Buradaki amaç sorunun yaygınlığını ölçmektir.
4. HTTP ve ağ hatalarını sınıflandırın. 4xx, 429, 5xx, timeout ve DNS hatalarını aynı torbaya atmayın. 429 ve 5xx tarama hızını düşürürken kalıcı 4xx davranışı daha farklı sonuç verir. Robots.txt için 404 ile 5xx arasındaki fark da ayrıca değerlendirilmelidir.
5. Log ve curl çıktısıyla Googlebot’u doğrulayın. Access ve error log’larda ilgili istekleri bulun, zaman damgasını canlı test zamanı ile eşleştirin. Gerekirse CDN/WAF logunu ekleyin. Googlebot kimliği için user-agent’a değil, ters DNS ve ileri DNS doğrulamasına güvenin; aksi halde sahte botları gerçek tarama isteği sanabilirsiniz.
6. Düzeltmeyi doğrulayın ve izlemeyi kurun. Değişiklik sonrası aynı URL setini yeniden test edin, gerekiyorsa dizine ekleme isteği gönderin ve host status iyileşmesini izleyin. Sorun kapandıktan sonra benzer hataların erken yakalanması için düzenli teknik sağlık ve görünürlük takibi kurun.

Bu akışın ana fikri şudur: tarama anormalliği, tahmin yürütülerek değil kanıt zinciri kurularak çözülür. Canlı test, host sinyali, log ve HTTP davranışı aynı sonuca işaret ediyorsa doğru kök nedene yaklaşmışsınız demektir.

Sıkça Sorulan Sorular