Google bu yanıtları nasıl ele alır?
Google’ın HTTP durum kodları belgesi, 429’u aşırı yük sinyali olarak sunucu hatalarıyla birlikte değerlendirir. 5xx ve 429 yanıtları taramanın geçici olarak yavaşlamasına yol açabilir. Kalıcı biçimde sunucu hatası veren adresler zamanla arama indeksinden düşebilir; tek bir hata gözlemi bu sonucun gerçekleştiğini kanıtlamaz.
Aynı belge başarılı 2xx yanıtının indeksleme garantisi olmadığını da açıklar. Bu yüzden düzeltme sonrası yalnız “200 dönüyor” kaydı yetmez. Beklenen hizmet metni gerçekten geliyor mu, yoksa 200 koduyla bir hata ekranı mı sunuluyor, ayrıca inceleyin.
Hatanın kapsamını hangi kanıtla belirlersiniz?
Bir denetim aracının başarısız isteği ile bütün ziyaretçilerin hizmete erişememesi aynı gözlem değildir. Tek bir cihazda sayfanın açılması da diğer istemcilerin durumunu açıklamaz. Erişim olayı kaydında ilk bulguyu koruyun; daha sonra yapılan başarılı denemeyi eski hatanın hiç yaşanmadığı şeklinde sunmayın.
Teknik sorumludan ilgili zaman aralığındaki sunucu ve varsa ön katman kayıtlarını istemek yararlıdır. Amaç hangi bileşenin yanıt verdiğini ve olayın ne kadar yaygın olduğunu anlamaktır. Kayıtları rapora taşırken erişim belirteçlerini, oturum bilgilerini ve kişisel verileri gereksiz yere paylaşmayın. İstemcinin adında Googlebot yazması kimlik doğrulaması değildir; bunun için Googlebot doğrulama rehberini kullanın.
Tekrar denemesi ne zaman yapılmalı?
Google’ın tarama hızını azaltma belgesi, 503 veya 429 yanıtında Retry-After başlığıyla saniye cinsinden süre ya da mutlak UTC zamanı bildirilebildiğini açıklar. Çok sayıda hata aynı ana makine adı genelindeki tarama hızını etkileyebilir. Uzun süren hata yanıtları görünürlüğe zarar verebilir; bu yöntem kalıcı bir yayın ayarı gibi kullanılmamalıdır.
Tekrar zamanı kaydına varsa sunucunun bildirdiği beklemeyi ekleyin. Başlık yoksa deneme sıklığını teknik sorumluyla belirleyin ve aynı hatayı saniyeler içinde tekrar üretmeyin. Erişim kısıtını farklı kimlik veya bağlantı yollarıyla aşmak yerine yetkili incelemeyle nedenini çözün. Bu öneri herhangi bir güvenlik kuralının kaldırılması talimatı değildir.
Kurgusal örnek: tek araç hata aldı
Hayali bir içerik denetçisi aynı hizmet adresine kısa sürede çok sayıda istek göndermiş ve 429 almış olsun. Normal ziyaretçinin sayfayı açabildiği ayrıca gözlenmiş olsun. Bu gerçek müşteri olayı değildir. İlk sonuç bütün sitenin kapalı olduğunu söylemeye yetmez; ikinci sonuç da tarayıcının mutlaka sorunsuz eriştiğini kanıtlamaz.
Ekip önce yoğun denemeyi durdurur, hata zamanını ve yanıtı saklar. Yetkili teknik incelemeden ve belirlenen beklemeden sonra aynı URL kontrollü biçimde tekrar açılır. Başarılı yanıtta doğru içerik kontrol edilir. Google’ın daha sonra bildirdiği indeks durumu ayrı bir takip satırında kalır.
| Olay alanı | Kaydedilecek bilgi |
|---|---|
| İlk bulgu | URL, zaman ve HTTP kodu |
| İstek kapsamı | Hangi araç veya doğrulanmış istemci? |
| Bekleme | Retry-After veya kararlaştırılan kontrol saati |
| Teknik inceleme | Yanıtı üreten bileşen ve bulunan neden |
| Sonraki deneme | Yeni HTTP yanıtı ve gerçek sayfa içeriği |
| Arama durumu | Ayrı tarihli Google kanıtı veya açık bekleme |
Erişim düzeldikten sonra kalan kontroller
Robots, noindex ve canonical rehberi sayfa alınabildiğinde ayrı yayın kurallarını incelemeyi sağlar. Geçici erişim sorununu çözmek bu ayarları kendiliğinden doğrulamaz.
GEO görünürlük analizi sonrasında bir kaynağa ulaşılamadıysa raporda yalnız gerçekten gözlenen durumu belirtin. Teknik erişim, indekslenme ve yapay zekâ yanıtında kaynak olarak görünme farklı sonuçlardır. Olayı kapatırken hangi sorunun çözüldüğünü, hangi gözlemin hâlâ beklediğini açık bırakın.