- Konu sahibi
- #1
Search Console'da görülen sunucu hatasını araştırmaya web sunucusunun erişim logu ve hata loguyla başlayın. Ardından isteğin geçtiği CDN, WAF, reverse proxy veya yük dengeleyici loglarını; uygulama, veritabanı ve altyapı loglarını aynı zaman aralığında karşılaştırın. Amaç yalnızca hatalı URL'yi bulmak değil, isteğin hangi katmanda ve neden 5xx yanıtına dönüştüğünü belirlemektir.
Erişim logundaki user-agent tek başına isteğin Googlebot olduğunu kanıtlamaz. Google kaynaklı istekleri resmî IP listesi veya ileri/geri DNS doğrulamasıyla ayırın; canlı URL testi Google-InspectionTool kullanabilir. Log korelasyonunda zaman, istenen URL, host, durum kodu ve mümkünse istek kimliği birlikte kullanılmalıdır. Zaman dilimlerini UTC'ye çevirerek karşılaştırın; Search Console'daki hata ile log arasındaki gözlem zamanı birebir örtüşmeyebilir.
İstek, DNS/TLS aşamasında veya kenarda kesildiyse origin access logunda satır bulunmayabilir. Aynı host için IPv4/IPv6 ve tüm backend’leri değerlendirin. Kayıtlarda cookie, Authorization, parola veya reset tokenını açık tutmayın; URL query alanlarını maskeleyin ve hata araştırması için gereken kayıtları erişim/saklama politikasıyla koruyun.
Bir ürün URL'si Search Console'da sunucu hatasıyla raporlanmış olsun. Erişim logu 504 ve 30 saniyelik yanıt süresi gösteriyor; reverse proxy logu upstream timeout kaydediyor; uygulama logu ise ürün sorgusunun veritabanı bağlantısı beklediğini belirtiyor. Bu durumda sorun Googlebot'a özel bir engel değil, uygulama ile veritabanı arasındaki gecikmedir. Sorgu planını, bağlantı havuzunu ve timeout ayarlarını incelemek; ardından URL'yi yeniden test etmek gerekir. Yalnızca Search Console'da doğrulama istemek nedeni ortadan kaldırmaz.
Log satırlarını merkezi sistemde şu alanlarla birlikte tutmak teşhisi kolaylaştırır:
Yalnızca uygulama loguna bakmak, hatanın CDN veya proxy'de üretilmesi durumunda sonuç vermez. Yalnızca tek bir sunucuyu incelemek de yük dengelemeli sistemlerde yanıltıcıdır. Ayrıca loglarda sadece URL aramak yerine durum kodu, süre ve zaman aralığını birlikte filtreleyin. Sorun düzeldikten sonra eski kayıtların temizlenmesi teşhisi zorlaştırabileceğinden, log saklama ve döndürme ayarlarının hata araştırmasına yetecek şekilde olduğundan emin olun.
Önce doğru hostu, tarih aralığını ve tüm proxy/CDN loglarını kontrol edin. İstek kenar katmanında engellenmiş veya farklı bir sunucuya yönlenmiş olabilir; merkezi log yoksa her katmanın kayıtlarını aynı UTC aralığında karşılaştırın.
Hayır. User-agent değeri taklit edilebilir ve botlara uygulanan ayrı cache, WAF, oran sınırlaması veya yönlendirme kuralları bulunabilir. Aynı URL'yi farklı istemci koşullarıyla test ederken proxy, WAF ve uygulama loglarını birlikte değerlendirin.
Hangi log neyi gösterir?
- Erişim logu: İstenen URL, HTTP yöntemi, durum kodu, user-agent, zaman damgası ve yapılandırılan diğer alanları gösterir. Host/yanıt süresi/upstream süreleri her varsayılan log biçiminde bulunmaz; gerekirse hassas veri toplamadan log formatına eklenir. Search Console'daki tarama ile sunucudaki gerçek isteği eşleştirmek için ana kaynaktır.
- Web sunucusu hata logu: Nginx, Apache veya benzeri sunucunun upstream bağlantı hatası, timeout, yanlış yapılandırma ve bağlantı kesilmesi gibi nedenlerini açıklar.
- CDN, WAF, reverse proxy ve yük dengeleyici logu: İstek uygulama sunucusuna ulaşmadan 502, 503 veya 504 üretildiyse asıl açıklama burada bulunabilir.
- Uygulama logu: PHP, Node.js, Python, Java veya kullandığınız uygulamanın istisnalarını, çöken işlemleri, bellek sınırını ve bağımlılık hatalarını gösterir.
- Veritabanı, önbellek ve kuyruk logları: Uygulama çalışıyor görünse de sorgu timeout'u, bağlantı havuzu tükenmesi veya Redis gibi bir bağımlılığın yanıt vermemesi 5xx üretebilir.
- Platform ve dağıtım logları: Yeniden başlatma, deploy, otomatik ölçekleme, disk doluluğu veya kaynak sınırına ulaşma gibi olayları zaman çizelgesine ekler.
Erişim logundaki user-agent tek başına isteğin Googlebot olduğunu kanıtlamaz. Google kaynaklı istekleri resmî IP listesi veya ileri/geri DNS doğrulamasıyla ayırın; canlı URL testi Google-InspectionTool kullanabilir. Log korelasyonunda zaman, istenen URL, host, durum kodu ve mümkünse istek kimliği birlikte kullanılmalıdır. Zaman dilimlerini UTC'ye çevirerek karşılaştırın; Search Console'daki hata ile log arasındaki gözlem zamanı birebir örtüşmeyebilir.
Uygulanabilir araştırma sırası
- Hatalı kapsamı belirleyin. Search Console'daki örnek URL'leri ve hata türünü not edin. 500, 502, 503 ve 504 aynı anlama gelmez; ayrıca 4xx yanıtları genel olarak sunucu hatasıyla karıştırılmamalıdır.
- Erişim logunda arayın. Örnek URL, aynı host ve ilgili zaman aralığıyla filtreleyin. Birden fazla sunucu varsa tüm düğümlerin loglarını veya merkezi log sistemini kontrol edin.
- Yanıt süresini karşılaştırın. 500 hızlı dönüyorsa uygulama istisnası; 502 veya 504 upstream bağlantısı; 503 ise bakım, kapasite veya geçici kullanılamazlık ihtimalini öncelikli inceleyin. Bu kodlar tek başına kesin neden değildir.
- İstek kimliğini takip edin. Proxy veya uygulama her isteğe bir request ID yazıyorsa bunu hata logunda arayın. Kimlik yoksa aynı URL ve zaman damgası üzerinden korelasyon yapın.
- Bir alt katmana inin. Erişim logu isteğin sunucuya ulaştığını gösteriyorsa web sunucusu hata loguna, oradan uygulamaya; uygulama beklerken timeout oluşuyorsa veritabanı, önbellek ve dış servis loglarına geçin.
- Düzeltmeyi kontrollü doğrulayın. Sorunlu URL'yi normal bir HTTP istemcisiyle ve yetkili bir test ortamında kontrol edin. Beklenen sonuç, kararlı bir 2xx yanıtı ve olağandışı uzun olmayan yanıt süresidir. Hata sürüyorsa yeniden tarama istemek yerine önce logdaki kök nedeni çözün.
İstek, DNS/TLS aşamasında veya kenarda kesildiyse origin access logunda satır bulunmayabilir. Aynı host için IPv4/IPv6 ve tüm backend’leri değerlendirin. Kayıtlarda cookie, Authorization, parola veya reset tokenını açık tutmayın; URL query alanlarını maskeleyin ve hata araştırması için gereken kayıtları erişim/saklama politikasıyla koruyun.
Varsayımsal örnek
Bir ürün URL'si Search Console'da sunucu hatasıyla raporlanmış olsun. Erişim logu 504 ve 30 saniyelik yanıt süresi gösteriyor; reverse proxy logu upstream timeout kaydediyor; uygulama logu ise ürün sorgusunun veritabanı bağlantısı beklediğini belirtiyor. Bu durumda sorun Googlebot'a özel bir engel değil, uygulama ile veritabanı arasındaki gecikmedir. Sorgu planını, bağlantı havuzunu ve timeout ayarlarını incelemek; ardından URL'yi yeniden test etmek gerekir. Yalnızca Search Console'da doğrulama istemek nedeni ortadan kaldırmaz.
Log satırlarını merkezi sistemde şu alanlarla birlikte tutmak teşhisi kolaylaştırır:
| Alan | Neden gerekli? |
|---|---|
| UTC zaman damgası | Farklı sunucu ve hizmetleri aynı olayda eşleştirmek için |
| URL ve HTTP yöntemi | Hatanın belirli kaynakta mı, tüm isteklerde mi olduğunu görmek için |
| Durum kodu ve süre | Uygulama hatası ile timeout ihtimalini ayırmak için |
| Host, düğüm ve request ID | İsteğin hangi katmandan ve sunucudan geçtiğini izlemek için |
Sık yapılan hatalar
Yalnızca uygulama loguna bakmak, hatanın CDN veya proxy'de üretilmesi durumunda sonuç vermez. Yalnızca tek bir sunucuyu incelemek de yük dengelemeli sistemlerde yanıltıcıdır. Ayrıca loglarda sadece URL aramak yerine durum kodu, süre ve zaman aralığını birlikte filtreleyin. Sorun düzeldikten sonra eski kayıtların temizlenmesi teşhisi zorlaştırabileceğinden, log saklama ve döndürme ayarlarının hata araştırmasına yetecek şekilde olduğundan emin olun.
Kaynaklar
Sık sorulan sorular
Search Console'daki örnek URL erişim logunda görünmüyorsa ne yapılır?
Önce doğru hostu, tarih aralığını ve tüm proxy/CDN loglarını kontrol edin. İstek kenar katmanında engellenmiş veya farklı bir sunucuya yönlenmiş olabilir; merkezi log yoksa her katmanın kayıtlarını aynı UTC aralığında karşılaştırın.
5xx hatası yalnızca Googlebot'ta görülüyorsa sorun kesin olarak Googlebot mudur?
Hayır. User-agent değeri taklit edilebilir ve botlara uygulanan ayrı cache, WAF, oran sınırlaması veya yönlendirme kuralları bulunabilir. Aynı URL'yi farklı istemci koşullarıyla test ederken proxy, WAF ve uygulama loglarını birlikte değerlendirin.
