Googlebot 5xx Hataları: Hosting Kaynaklı Crawl Sorunları

Google Search Console’da tarama istatistiklerinde 5xx hataları görüyorsanız önce Googlebot’u engelleyen bir SEO ayarı aramak yerine, sunucunun ilgili isteğe hangi yanıtı verdiğini bulun. Googlebot 5xx hataları çoğunlukla robots.txt veya meta robots kuralından değil, HTTP isteğinin sunucu tarafında başarısız olmasından kaynaklanır.

Hata kısa süreliyse Google yeniden deneme yapabilir. Belirli URL’lerde veya saatlerde tekrarlanan hatalar ise tarama kapasitesini azaltabilir, yeni içeriklerin keşfini geciktirebilir ve aynı sayfalarda kullanıcı hatalarına yol açabilir. Teşhisi Googlebot’a özel varsayımlarla değil, zaman eşleştirilmiş sunucu kanıtlarıyla yürütün.

Googlebot 5xx hataları ne anlama gelir?

HTTP 5xx kodları, isteği alan sunucunun isteği başarıyla tamamlayamadığını gösterir. Googlebot bir sayfayı, görseli, JavaScript dosyasını veya robots.txt dosyasını isterken 5xx yanıtı alabilir. Search Console’daki kayıt, Google’ın tarama anındaki gözlemidir; tek başına hatanın hosting sağlayıcısından kaynaklandığını kanıtlamaz.

Uygulama veritabanı bağlantısı kuramıyor, ters proxy upstream sunucudan zamanında yanıt alamıyor veya işletim sistemi yeni bir işlem oluşturmak için yeterli kaynak bulamıyor olabilir. Aynı URL’yi tarayıcıda açtığınızda başarılı görmeniz de sorunu dışlamaz. Hata yalnızca yoğun trafik anında, belirli veri merkezlerinden gelen isteklerde veya yüksek maliyetli sayfalarda ortaya çıkabilir.

5xx kodlarını birbirinden ayırın

• 500 Internal Server Error: Uygulama istisnası, hatalı PHP kodu, bozuk yapılandırma veya yakalanmamış bir sunucu hatası görülebilir.
• 502 Bad Gateway: Nginx, Apache veya başka bir proxy; PHP-FPM, uygulama sunucusu ya da upstream servisten geçerli yanıt alamamış olabilir.
• 503 Service Unavailable: Bakım modu, geçici kapasite yetersizliği, aşırı yük veya uygulamanın isteği kabul etmemesi söz konusu olabilir.
• 504 Gateway Timeout: Upstream bileşen, proxy’nin belirlediği süre içinde yanıt vermemiştir. Yavaş veritabanı sorgusu ve kilitlenmiş işlem olası nedenler arasındadır.
• 508 ve benzeri kodlar: Döngü, kaynak sınırı veya platforma özgü bir koruma mekanizması devreye girmiş olabilir. Kodun anlamını hosting sağlayıcınızın altyapı dokümantasyonuyla doğrulayın.

HTTP durum kodlarının SEO ve hosting açısından nasıl yorumlandığını görmek için HTTP Durum Kodları: SEO ve Hosting İçin 301, 302, 404, 410 ve 5xx Rehberi içeriğine de bakabilirsiniz. Buradaki amaç kodu ezberlemek değil, isteği hangi bileşenin sonlandırdığını belirlemektir.

Önce hatanın zamanını ve kapsamını belirleyin

Search Console grafiği bir dönem ve eğilim gösterir; sunucu logu ise tek tek isteklerin zamanını, URL’sini ve yanıt kodunu gösterir. İki kaynağı aynı saat dilimine getirerek başlayın. Saat dilimleri farklıysa aynı olayı yanlış aralıkta arayabilirsiniz.

Search Console verisini daraltın

Hatanın hangi raporda göründüğünü ve hangi URL grubunu etkilediğini not edin. Sitenin tamamında artış varsa genel kapasite, ağ, DNS veya platform sorunu olasılığı yükselir. Hata yalnızca ürün filtreleri, arama sonuçları veya belirli bir eklentinin ürettiği URL’lerdeyse uygulama maliyetine odaklanın.

Tüm URL’leri yeniden taratmak yerine birkaç temsilci URL seçin: ana sayfa, hata görülen bir içerik, kategori veya ürün sayfası ve mümkünse robots.txt. Bu karşılaştırma, sorunun içerik türüne, URL parametresine veya tüm sanal host’a yayıldığını ayırmanıza yardımcı olur.

Erişim loglarında Googlebot isteğini bulun

Log satırında genellikle istemci IP’si, zaman, istek yolu, HTTP yöntemi, durum kodu, yanıt boyutu ve User-Agent bulunur. User-Agent içinde Googlebot yazması tek başına isteğin gerçekten Google’a ait olduğunu kanıtlamaz. Güvenlik incelemesinde ters DNS ve ileri DNS doğrulaması ayrıca yapılmalıdır; ilk teknik teşhiste ise aynı URL ve zaman dilimindeki kayıtları eşleştirmek yeterli bir başlangıçtır.

Apache veya Nginx log formatınızda yanıt süresi yoksa, altyapı yöneticinizden upstream ve toplam istek süresini içeren bir format isteyin. Mevcut kayıt akışını değiştirmeden önce yapılandırmayı yedekleyin. Değişiklikten sonra yeni satırların beklenen alanları içerdiğini kontrol edin.

Sunucu loglarını okumaya yeni başlıyorsanız Hosting Sunucu Loglarını Okumayı Öğrenin ifadesiyle ilişkili rehber, Apache ve Nginx kayıtlarındaki alanları yorumlamak için yararlı bir başvuru olabilir.

Hosting kaynakları ve uygulama katmanını inceleyin

Bir 5xx yanıtının hosting kaynaklı olup olmadığını anlamak için yalnızca CPU kullanımına bakmayın. CPU, RAM, PHP-FPM işçi sayısı, işlem başlatma limiti, disk alanı, disk I/O, veritabanı bağlantı havuzu ve süreç başına bellek sınırı farklı darboğazlardır. Hata anında hangi değerin sınırı aştığını bulmanız gerekir.

PHP-FPM web işçileri ile CLI işlerini ayırın

PHP-FPM, web sunucusunun PHP isteklerini çalıştıran işçi havuzudur. Bir istek uzun sürerse veya havuzdaki tüm işçiler doluysa yeni HTTP istekleri bekleyebilir; proxy bekleme süresini aşarsa 502 ya da 504 görülebilir. Bu nedenle FPM durumunu, aktif işçi sayısını, bekleyen istekleri ve yavaş istek kayıtlarını hata zamanıyla karşılaştırın.

CLI cron görevleri ve kuyruk işçileri komut satırında çalışan ayrı süreçlerdir. HTTP çağrısı yapmayan bir CLI işi FPM işçisi tüketmez. Bununla birlikte aynı CPU, RAM, disk veya veritabanı gibi ortak kaynakları kullanarak web isteklerini dolaylı biçimde yavaşlatabilir. Her sürecin hangi kaynağı tükettiğini ölçmeden cron çalışıyor diye FPM havuzunun dolduğunu varsaymayın.

Kaynak limitlerini kanıtlayın

Hata zamanında aşağıdaki göstergeleri birlikte inceleyin:

• FPM havuzu maksimum çocuk süreç sayısına ulaşmış mı?
• İstekler kuyrukta bekliyor veya yavaş istek eşiğini aşıyor mu?
• RAM tükenmesi, işletim sistemi tarafından süreç sonlandırılması veya swap kullanımı görülüyor mu?
• Disk alanı, inode veya geçici dosya alanı dolu mu?
• Veritabanı bağlantı sayısı, kilitlenme veya sorgu süresi yükselmiş mi?
• Hosting hesabının CPU, I/O, işlem veya eşzamanlı bağlantı limiti aşılmış mı?

Paylaşımlı hosting ortamında bu göstergelerin tamamına erişemeyebilirsiniz. Bu durumda sağlayıcıya tam hata zamanını, etkilenen alan adını, URL’yi ve mümkünse istek kimliğini vererek kaynak kullanımı ile platform loglarının incelenmesini isteyin. Belirli zaman ve URL bilgisi, genel bir 5xx bildiriminden daha yararlı bir teşhis başlangıcı sağlar.

Timeout ve proxy zincirini kontrol edin

504 gördüğünüzde yalnızca sunucunun yavaş olduğunu söylemek yeterli değildir. İstek CDN veya yük dengeleyici, web sunucusu, PHP-FPM ya da uygulama sunucusu ve veritabanı gibi birden fazla katmandan geçebilir. Her katmanın bağlantı ve yanıt bekleme süresi farklıdır.

Önce 504’ü hangi katmanın ürettiğini belirleyin. Yanıt gövdesindeki varsayılan proxy sayfası, response header’ları, web sunucusu logu ve upstream logu ipucu verebilir. Aynı zaman damgasında web sunucusunda 504, FPM tarafında ise hiç kayıt yoksa istek FPM’e ulaşmadan kesilmiş olabilir. FPM’de işlem başladı fakat tamamlanmadıysa uygulama veya veritabanı süresini inceleyin.

Timeout değerlerini dar kapsamda ele alın

İlk düzeltme, tüm site için timeout’u büyütmek yerine sorunlu endpoint’i veya yavaş işlemi hedeflemelidir. Önce yavaş sorguyu, dış API çağrısını, dosya işlemini veya eklenti kancasını bulun. İş web isteği içinde çalışmak zorundaysa sorguyu iyileştirin, sonucu önbelleğe alın veya işlemi asenkron kuyruğa taşıyın. Kuyruk işçisinin FPM işçisi olmadığını ve ayrı kaynak tükettiğini izleme planında ayrıca değerlendirin.

Yapılandırma değişikliği için gerekli yönetici erişiminiz ve geri yüklenebilir bir kopyanız olmalıdır. Değişiklikten sonra yapılandırma sözdizimini doğrulayın, kontrollü bir istek gönderin ve hata oranını önceki dönemle karşılaştırın. Servisi yeniden başlatmak gerekiyorsa bakım penceresi ve geri dönüş adımı belirlenmeden uygulamayın.

Geçici 5xx artışlarını nasıl doğrularsınız?

Geçici bir ağ veya platform sorunu kısa süreli bir 5xx dalgası yaratabilir. Bunu incelemek için yalnızca tarayıcıdan manuel kontrol yapmayın. Aynı URL’yi birkaç farklı zamanda isteyin; her denemede durum kodunu, yanıt süresini ve mümkünse istek kimliğini kaydedin. Kontrolleri düşük sıklıkta tutun; testleriniz yeni bir yük oluşturmamalıdır.

Uptime izleme kayıtları sitenin dışarıdan erişilebilir olup olmadığını gösterir. Ancak yalnızca ana sayfayı kontrol etmek, ürün sayfasındaki veritabanı sorununu yakalamayabilir. Kritik URL türleri için düşük sıklıklı ve uygun aralıklı kontroller daha anlamlıdır. İzleme kaydı ile Search Console’daki hata zamanını aynı saat diliminde karşılaştırın.

User-Agent değiştirerek yapılan testler, uygulamanın farklı istemci başlıklarına göre davranıp davranmadığını gösterebilir; Google’ın gerçek tarama isteğini veya ağ yolunu bütünüyle temsil etmez. Bu nedenle Googlebot’a 5xx döndüğü iddiasını bu testle kanıtlamayın. Asıl kanıt, erişim logları ile altyapı kayıtlarının zaman ve URL bakımından eşleşmesidir.

Googlebot’a özel engelleme ile 5xx sorununu ayırın

robots.txt’de Disallow kullanılması taramayı kısıtlayabilir, fakat normalde sunucunun 5xx yanıtı üretmesine neden olmaz. WAF veya güvenlik katmanı Googlebot benzeri User-Agent’ları engelliyorsa 403, bağlantı kesilmesi veya platforma özgü bir hata görülebilir. 5xx ile robots.txt kuralını aynı sorun gibi ele almayın.

Googlebot istekleri için hız sınırlama, bot koruması veya IP itibarı kuralı kullanıyorsanız güvenlik loglarında eşleşen bir kayıt arayın. Kuralı tamamen kapatmak yerine yalnızca etkilenen alan adı ve URL grubu için kontrollü bir istisna değerlendirin. Gerçek Googlebot doğrulaması gerekiyorsa IP listelerini sabit kabul etmeyin; Google’ın güncel doğrulama yöntemini uygulayın.

Dar kapsamlı düzeltme ve doğrulama planı

Teşhisten sonra aynı anda birden fazla ayarı değiştirmeyin. Böylece hangi değişikliğin sonucu etkilediğini koruyabilirsiniz:

1. Kanıtı sabitleyin: Hata zamanını, URL’yi, 5xx kodunu, yanıt süresini, User-Agent’ı ve ilgili log satırlarını kaydedin.
2. Katmanı seçin: Uygulama logu 500 gösteriyorsa kod veya eklentiye, upstream zaman aşımı gösteriyorsa bağımlılık ve timeout zincirine, kaynak limiti gösteriyorsa kapasiteye odaklanın.
3. En dar düzeltmeyi uygulayın: Sorunlu sorgu, endpoint, eklenti, kuyruk görevi veya güvenlik kuralı için değişiklik yapın. Tüm sitenin ayarlarını değiştirmeyi son seçenek olarak değerlendirin.
4. Geri dönüşü hazırlayın: Yapılandırma ve uygulama değişikliklerinden önce yedek alın, mevcut değerleri not edin ve geri alma adımlarını belirleyin.
5. Sonucu ölçün: Aynı URL türlerinde 5xx oranını, yanıt süresini, FPM beklemesini ve kaynak kullanımını değişiklik öncesi dönemle karşılaştırın.
6. Search Console’u yeniden değerlendirin: Sunucu tarafı düzeldikten sonra Google’ın yeni tarama verilerinin oluşması zaman alabilir. Search Console’daki doğrulama seçeneğini kullanmadan önce canlı teknik kanıtın düzeldiğinden emin olun.

WordPress kullanıyorsanız son yüklenen eklentileri, tema değişikliklerini, otomatik görevleri ve ağır sorgu üreten özellikleri hata zamanıyla eşleştirin. WooCommerce ürün, sepet veya ödeme akışlarını test ederken gerçek sipariş oluşturmadan staging ortamını ya da güvenli bir test ürününü kullanın. Veri değiştiren işlemlerden önce veritabanı ve dosya yedeğinin geri yüklenebilir olduğunu kontrol edin.

Sık Sorulan Sorular

Googlebot 5xx hataları sıralamayı hemen düşürür mü?

Tek ve kısa süreli bir hata otomatik olarak kalıcı sıralama kaybı anlamına gelmez. Hatalar tekrarlı, yaygın veya uzun süreliyse Google sayfaları daha az tarayabilir; bu durum yeni ve güncellenmiş içeriğin keşfini geciktirebilir.

Googlebot için ayrı bir sunucu planı gerekir mi?

Gereklilik, Googlebot sayısından çok sitenizin toplam istek paterni ve sayfa üretim maliyetiyle ilgilidir. Önce darboğazı ölçün. Kaynak limiti sürekli aşılıyorsa optimizasyon, önbellekleme veya uygun kapasite planlaması değerlendirilir.

5xx hatası için URL’yi Search Console’da tekrar test etmek yeterli midir?

Hayır. URL testi anlık bir kontrol sağlar ve geçmişteki hata anını açıklamaz. Erişim logları, uygulama kayıtları ve uptime verileriyle zaman çizelgesi oluşturmanız gerekir.

CDN kullanmak 5xx sorununu tamamen çözer mi?

CDN bazı içerikleri önbellekten sunarak origin yükünü azaltabilir; dinamik sayfa, veritabanı veya origin yapılandırma hatalarını ortadan kaldırmaz. CDN ile origin arasındaki 5xx kayıtlarını ayrıca inceleyin.

Son kontrol listesi

• Search Console’da etkilenen URL türlerini ve hata zaman aralığını not ettiniz mi?
• Sunucu saat dilimini Search Console verisiyle eşleştirdiniz mi?
• İlgili erişim logunda durum kodu, URL, yanıt süresi ve User-Agent kaydını buldunuz mu?
• Hatanın web sunucusu, PHP-FPM, uygulama, veritabanı, proxy veya güvenlik katmanından hangisinde oluştuğunu belirlediniz mi?
• CPU, RAM, disk, FPM, veritabanı ve hosting limitlerinden hangisinin gerçekten aşıldığını doğruladınız mı?
• Değişiklikten önce yedek ve geri dönüş adımını hazırladınız mı?
• Dar kapsamlı düzeltmeden sonra aynı URL türlerinde 5xx ve yanıt süresini yeniden ölçtünüz mü?

İlk sonraki adımınız, Search Console’daki bir hata zaman aralığını seçip aynı dakikalardaki erişim ve uygulama loglarını yan yana koymak olsun. Tek bir 500 veya 504 satırını değiştirmeye çalışmak yerine tekrar eden örüntüyü bulduğunuzda hosting sağlayıcınıza kanıtlı ve çözülebilir bir destek talebi iletebilirsiniz.

Emre