404, 500, 502 ve 503 Hataları: Doğru Katmanda Sorun Giderme
· PoolByte
Bir web sitesinde hata gördüğünüzde ilk iş bütün ayarları değiştirmek olmamalıdır. HTTP durum kodu, sorunun hangi bölümde araştırılması gerektiğine dair başlangıç bilgisi verir. Aynı hata sayfası tasarımının kullanılması, bütün sorunların aynı nedenden kaynaklandığı anlamına gelmez. URL, uygulama, web sunucusu ve aradaki hizmetler ayrı değerlendirilmelidir.
Ayrıca ekranda yazan kod ile sunucunun gerçekten döndürdüğü kod farklı olabilir. “Sayfa bulunamadı” yazan bir yanıt 200 döndürüyorsa bu başarılı bir HTTP yanıtıdır; içerik ise hata sayfasıdır. Tarayıcının geliştirici araçları veya uygun HTTP kontrolüyle gerçek durum kodunu doğrulayın.
Önce olayı daraltın
Hatanın görüldüğü tam URL'yi, saatini, kullanıcı durumunu ve son değişikliği kaydedin. Sorun tek bir sayfada mı, tüm sitede mi? Oturum açanlarda mı, anonim ziyaretçilerde mi? Mobilde ve masaüstünde aynı mı? CDN veya ters vekil varsa onun ürettiği yanıtla kaynak sunucunun yanıtını ayırmaya çalışın.
Örneğin yalnızca görseller 404 veriyorsa dosya yolları önceliklidir. Bütün dinamik sayfalar 502 verirken statik dosyalar açılıyorsa uygulama süreçleri veya üst sunucu bağlantısı araştırılabilir. Bunlar kesin teşhis değil, kontrol sırasını daraltan ipuçlarıdır.
404: İstenen kaynak bulunamadı
404, sunucunun istenen kaynağı bulamadığını belirtir. Yanlış URL, silinmiş içerik, taşınmış dosya, büyük-küçük harf farkı veya yönlendirme kuralı buna neden olabilir. Önce dosya ya da içerik gerçekten var mı ve doğru adreste mi kontrol edin.
Bir yazıyı yeni adrese taşıdıysanız anlamlı eski URL'yi ilgili yeni URL'ye yönlendirin. Bütün bulunamayan sayfaları ana sayfaya yönlendirmek, ziyaretçinin aradığı içeriğe ulaşmasını sağlamaz. Gerçekten kaldırılan ve karşılığı olmayan içerik için doğru hata yanıtını korumak daha açıklayıcıdır.
WordPress'te yalnızca yazı adresleri çalışmıyorsa kalıcı bağlantı ve sunucu yönlendirme yapılandırması incelenebilir. Önce mevcut ayarları kaydedin; rastgele .htaccess parçaları ekleyip durumu daha karmaşık hale getirmeyin. Kaynakların isimlerini ve dizin yolunu da karşılaştırın.
500: Uygulama veya sunucuda beklenmeyen durum
500 genel bir sunucu hatasıdır; tek başına hangi satırın sorunlu olduğunu söylemez. Yeni eklenti, hatalı yapılandırma, PHP uyumsuzluğu, eksik bağımlılık veya kaynak sınırı gibi nedenler olabilir. Hata günlüğündeki zaman ve istek bilgisi, tahminden daha değerlidir.
Son değişikliğin sürümünü ve kapsamını belirleyin. Mümkünse aynı hatayı staging ortamında tekrar üretin. Eklentileri rastgele silmek yerine kontrollü bir izolasyon planı kullanın. Bir bileşeni kapatmanın sipariş, üyelik veya içerik davranışını etkilemediğini düşünmeden canlıda işlem yapmayın.
WordPress hata ayıklama seçenekleri test ortamında yardımcı olabilir. Ayrıntılı hata çıktısını ziyaretçiye açmak yerine erişimi korunan günlükte inceleyin. Dosya yolu, bağlantı bilgisi ve hassas veriler herkese açık sayfada gösterilmemelidir. PHP değişikliği şüpheliyse sürüm yükseltme rehberindeki kontrol sırasını kullanın.
502: Aradaki sunucu geçerli yanıt alamadı
502, ağ geçidi veya vekil olarak çalışan sunucunun üst sunucudan geçerli bir yanıt alamadığını belirtir. Uygulama süreci durmuş olabilir, bağlantı yolu hatalı olabilir veya üst sunucu beklenen biçimde yanıt üretmemiş olabilir. Sorunu yalnızca tarayıcı önbelleğine bağlamayın.
Kontrol sırası bağlantı mimarisine göre değişir: CDN, ters vekil, web sunucusu ve PHP süreçleri. Hangi bileşenin kodu ürettiğini günlüklerden belirleyin. Yakın zamanda port, sertifika, PHP-FPM veya vekil ayarı değiştiyse bunu incelemeye ekleyin. Sunucuya erişiminiz yoksa sağlayıcıya tam saat ve URL ile başvurun.
Körlemesine hizmet yeniden başlatmak geçici olarak belirtileri azaltabilir, ancak nedenin bulunmasını zorlaştırabilir. Önce ilgili günlükleri ve kaynak durumunu kaydedin. Başlatma işlemi gerekiyorsa etkilediği siteleri ve sorumlu kişiyi belirleyin.
503: Hizmet geçici olarak kullanılamıyor
503, hizmetin o anda isteği karşılayamadığını belirtir. Planlı bakım veya aşırı yük olası nedenlerdir. Uygulamanın bakım modu ile sunucu kapasite sınırını ayırın. Bir güncelleme yarıda kaldıysa geride kalan bakım durumunu, işlemin gerçekten tamamlandığını doğrulamadan kaldırmayın.
Uygun durumlarda Retry-After başlığı yeniden deneme zamanına ilişkin bilgi verebilir. Ancak sırf hata sayfasına bu başlığı eklemek kapasiteyi düzeltmez. Hosting kaynakları rehberi, CPU, bellek ve işlem limitlerini yorumlamaya yardımcı olur.
Ödeme ekranında yeniden denemeyi dikkatli yönetin
Bir ödeme isteği hata gösterse bile sağlayıcı işlemi kabul etmiş olabilir. Kullanıcıyı tekrar tekrar ödeme yapmaya yönlendirmeden önce sipariş ve sağlayıcı kayıtlarını karşılaştırın. Hatanın oluştuğu zaman, sipariş referansı ve durum bilgisi önemlidir.
Teknik incelemede kart bilgisi, parola veya erişim anahtarı paylaşmayın. Destek ekibine temizlenmiş hata metni, URL, zaman ve yapılan son değişikliği iletin. Mümkünse ağ yanıtındaki istek kimliğini de ekleyin.
Düzeltmeden sonra ne doğrulanmalı?
- Sorunlu URL'yi ve ilgili başka sayfaları yeniden deneyin.
- Gerçek HTTP kodunu kontrol edin.
- Form ve oturum gibi işlevlerin çalıştığını doğrulayın.
- Günlükte yeni hataların oluşup oluşmadığını izleyin.
- Önbelleği gereken kapsamda temizleyin.
- Değişiklik ve sonucu kısa bir kayıtla kapatın.
Arama motorları açısından da doğru durum kodu önemlidir. Hata içeriğini sürekli başarılı yanıtla sunmak veya sunucu hatalarını uzun süre sürdürmek, tarama ve indeksleme sorunları yaratabilir. Teknik SEO rehberinde bu kontrollerin devamını bulabilirsiniz.
Sık sorulan sorular
Önbelleği temizlemek her hatayı düzeltir mi?
Hayır. Eski yanıtın gösterildiği durumlarda yararlı olabilir; bozuk uygulama veya çalışmayan üst sunucuyu onarmaz.
Hosting paketini yükseltmeli miyim?
Önce kaynak limitinin gerçekten aşıldığını ölçün. Kapasite sorunu doğrulanırsa web hosting seçeneklerini değerlendirin; kod veya yönlendirme hatası için farklı çözüm gerekir.