500 Internal Server Error Nedir? WordPress 500 Hatası Neden Olur, Nasıl Çözülür?

Sunucu Hata Günlüğü ve WP_DEBUG_LOG ile Teşhis Nasıl Yapılır?

500 Internal Server Error hatasının nedeni, sunucunun hata günlüğünde ya da WordPress’in debug.log dosyasında yazan satırdan okunur. Hata sayfası ziyaretçiye ayrıntı vermez ama sunucu, hatayı hangi dosyanın hangi satırında yaşadığını çoğu zaman kayda geçirir. Teşhise buradan başlamak, rastgele eklenti kapatmaktan daha hızlı sonuç verir.

Hosting panelindeki hata günlüğü

Hosting panelleri genellikle bir hata günlüğü bölümü sunar; bazı sunucularda PHP hataları, hatanın oluştuğu klasöre error_log adlı bir dosya olarak da yazılır. Günlükte “PHP Fatal error”, “Allowed memory size exhausted” ya da “Invalid command” gibi ifadeler aranır. Dosya yolunda wp-content/plugins altındaki bir klasör adı geçiyorsa sorumlu eklenti çoğu zaman oradan anlaşılır.

WP_DEBUG ve WP_DEBUG_LOG

WordPress’in hata ayıklama belgesine göre WP_DEBUG varsayılan olarak kapalıdır; WP_DEBUG_LOG açıldığında hatalar wp-content/debug.log dosyasına yazılır. WP_DEBUG_DISPLAY false yapıldığında hatalar ziyaretçiye gösterilmeden yalnızca dosyaya kaydedilir. wp-config.php dosyasına eklenen satırlar şunlardır:

• define( 'WP_DEBUG', true );
• define( 'WP_DEBUG_LOG', true );
• define( 'WP_DEBUG_DISPLAY', false );

Aynı belge, hata ayıklama araçlarının canlı sitelerde kullanılmasını önermez; bunlar yerel ve hazırlık kurulumları içindir. Canlı sitede teşhis için kısa süreliğine açılırsa, sorun bulunduktan sonra ayarlar kapatılır ve debug.log dosyası silinir. Günlüğün okunması ve kurtarma modu e-postası WordPress kritik hata rehberinde adım adım anlatılır.

Bozuk .htaccess Dosyası Nasıl Yeniden Oluşturulur?

Bozuk .htaccess dosyası, adı değiştirilip Kalıcı bağlantılar ayarı yeniden kaydedilerek temiz haliyle oluşturulur. WordPress belgeleri bu yöntemi Internal Server Error için ilk adım olarak verir. İşlem FTP ya da hosting panelinin dosya yöneticisiyle yapılır:

1. Sitenin kök dizininde, wp-config.php ile aynı klasördeki .htaccess dosyası bulunur; adı nokta ile başladığı için “gizli dosyaları göster” seçeneği açılmalıdır.
2. Dosyanın adı .htaccess_old yapılır; silinmez, çünkü içinde yönlendirme veya güvenlik kuralları olabilir.
3. Site yeniden denenir. Açılıyorsa sorun .htaccess dosyasındadır.
4. Yönetim panelinde Ayarlar › Kalıcı bağlantılar ekranı açılır ve hiçbir şey değiştirilmeden “Değişiklikleri kaydet” düğmesine basılır; WordPress yeni bir .htaccess dosyası yazar.
5. Eski dosyadaki özel kurallar (örneğin 301 yönlendirmeleri) satır satır kontrol edilerek yeni dosyaya geri eklenir.

Nginx kullanan sunucularda .htaccess dosyası okunmaz; bu sunucularda yeniden yazma kuralları sunucu yapılandırmasında durur ve bu adım sonuç vermez. Dosya yeniden oluşmuyorsa klasörün yazma izni kontrol edilir.

Eklenti ve Tema Çakışması Panele Girmeden Nasıl Test Edilir?

Panele girilemiyorsa eklentiler, wp-content/plugins klasörünün adı değiştirilerek topluca devre dışı bırakılır. WordPress klasörü bulamadığı eklentileri yüklemez; dosyalar silinmediği için ayarlar yerinde kalır. Bu yöntem WordPress’in sık karşılaşılan hatalar belgesinde de yer alır.

Uygulama sırası şöyledir: plugins klasörünün adı plugins_old yapılır ve site denenir. Site açılıyorsa klasörün adı geri verilir ve eklentiler panelden tek tek etkinleştirilir; 500 hatasını geri getiren eklenti sorumludur. Hangi eklentiden şüphelenildiği biliniyorsa yalnızca o eklentinin klasör adı değiştirilir.

Tema şüphesi varsa wp-content/themes altındaki etkin temanın klasör adı değiştirilir ve WordPress kurulu bir varsayılan temaya döner. Belgeler, hiçbiri sonuç vermezse temiz bir WordPress paketinden wp-admin ve wp-includes klasörlerinin yeniden yüklenmesini de önerir. Bu iki klasör yalnızca çekirdek dosyaları içerir; wp-content klasörüne ve wp-config.php dosyasına dokunulmaz.

PHP Bellek Sınırı, PHP Sürümü ve Dosya İzinleri Nasıl Kontrol Edilir?

Günlükte “Allowed memory size exhausted” yazıyorsa PHP bellek sınırı, “syntax error” ya da tanımsız fonksiyon hatası görülüyorsa PHP sürümü, “Permission denied” görülüyorsa dosya izinleri incelenir. Bu üç neden, eklentiler kapatıldıktan sonra da süren 500 hatalarının büyük kısmını açıklar.

WP_MEMORY_LIMIT ile bellek artırma

WordPress’in wp-config.php belgesine göre WordPress, PHP belleğini tek sitede 40 MB’a, çoklu sitede 64 MB’a çıkarmayı dener. Daha fazlası için wp-config.php dosyasına, wp-settings.php satırından önce define( 'WP_MEMORY_LIMIT', '96M' ); gibi bir tanım eklenir; yönetim paneli işlemleri için WP_MAX_MEMORY_LIMIT ayrıca tanımlanabilir. Belge, bazı hosting firmalarının bu artışa izin vermediğini ve bu durumda hosting firmasıyla görüşülmesi gerektiğini belirtir.

PHP sürüm uyumu

WordPress’in sunucu gereksinimleri sayfası PHP 8.3 veya üzerini önerir ve PHP 7.4 gibi eski sürümlerin resmi destek süresinin dolduğunu yazar. Hata PHP sürümü değiştikten hemen sonra başladıysa hosting panelinden önceki sürüme geçici olarak dönülür, uyumsuz eklenti bulunup güncellenir ve ardından güncel sürüme yeniden geçilir.

Dosya izinleri

WordPress’in dosya izinleri belgesi klasörler için 755 veya 750, dosyalar için 644 veya 640, wp-config.php için 440 veya 400 değerlerini verir. Aynı belge 777 izninin güvenlik riski taşıdığını vurgular ve doğru değerlerin sunucudan sunucuya değişebileceğini belirtir. Bazı sunucular, yazma izni fazla açık bir PHP dosyasını güvenlik gerekçesiyle hiç çalıştırmaz ve 500 döndürür.

Hosting kaynak sınırı

Paylaşımlı hosting paketlerinde her hesabın işlemci, bellek ve eş zamanlı işlem sınırı vardır; sınır aşıldığında sunucu isteği yarıda keser ve 500 ya da 503 dönebilir. Hata yalnızca yoğun saatlerde, toplu e-posta gönderiminde veya yedekleme sırasında çıkıyorsa hosting panelindeki kaynak kullanım raporları incelenir. Sorun sürekli tekrarlıyorsa paket yükseltme ya da daha uygun bir altyapı değerlendirilir; Onur Freelance’ın işletme adına açtığı hosting paketi yıllık 2.000 TL’dir ve ayrıntılar hosting fiyatları sayfasında yer alır.

500, 502, 503 ve 504 Hataları Arasındaki Fark Nedir?

500 internal server error genel sunucu hatasıdır; 502 ve 504 aracı sunucu ile arkadaki sunucu arasındaki iletişim sorununu, 503 ise sunucunun geçici olarak hizmet verememesini anlatır. RFC 9110’daki tanımlara göre dört kodun farkı şu tabloda yer alır:

Cloudflare gibi bir CDN kullanılan sitelerde hata sayfasının CDN’den mi, kaynak sunucudan mı geldiği ayrıca kontrol edilir. Hata zaman zaman ve yavaşlıkla birlikte görülüyorsa WordPress site yavaşlığına yönelik performans kontrolleri de devreye girer.

500 Hatası SEO’yu ve Google Sıralamasını Nasıl Etkiler?

Kısa süreli bir 500 internal server error sıralamayı genellikle kalıcı olarak etkilemez, ama uzun süren 5xx hataları taramayı yavaşlatır ve sayfaların dizinden düşmesine yol açabilir. Google Search Central’ın HTTP durum kodları ve ağ hataları belgesi, 5xx ve 429 hatalarının Google tarayıcılarının taramayı geçici olarak yavaşlatmasına neden olduğunu yazar. Aynı belgeye göre Google’ın dizine ekleme sistemi, sürekli sunucu hatası döndüren URL’leri dizinden kaldırır.

Google’ın bir sayfayı ne kadar süre sonra dizinden çıkardığına dair belgede bir süre verilmez; hatanın olabildiğince kısa sürede giderilmesi en güvenli yoldur. Onarımdan sonra izlenecek adımlar şunlardır:

• Search Console’da sayfa dizine ekleme raporundaki sunucu hatası (5xx) kayıtları kontrol edilir.
• Önemli sayfalar URL denetimi aracıyla yeniden test edilir.
• Planlı bakım gerekiyorsa site 500 değil, geçici durumu anlatan 503 koduyla kapatılır.
• Düzeltmeden sonra hata kayıtlarının birkaç gün içinde azalıp azalmadığı izlenir.

Rastgele Deneme mi, Sistemli Teşhis mi? Sık Yapılan Hatalar

500 internal server error karşısında en çok zaman, günlüğe bakılmadan art arda yapılan denemelerde kaybedilir. Genel uygulamada eklentiler silinir, rastgele kod parçaları eklenir ya da site baştan kurulur; sistemli yaklaşımda ise önce yedek alınır, günlük okunur ve tek seferde tek değişiklik yapılır. Sık görülen hatalar ve doğru karşılıkları şöyledir:

• Eklentiyi panelden ya da FTP’den silmek: Silme, bazı eklentilerde ayarları da kaldırır; doğru yol klasör adını değiştirmektir.
• .htaccess dosyasını silmek: İçindeki yönlendirme ve güvenlik kuralları kaybolur; dosyanın adı değiştirilir, içerik saklanır.
• Bellek sınırını çok yüksek değerlere çekmek: Asıl neden olan hatalı eklenti gizlenir, sorun bir sonraki işlemde geri döner.
• Dosya izinlerini 777 yapmak: Hata geçici olarak kalkabilir ama site saldırıya açık hale gelir.
• Canlı sitede hataları ekrana yazdırmak: WP_DEBUG_DISPLAY açık bırakılırsa dosya yolları ziyaretçilere görünür.
• Yedeksiz müdahale: Her deneme, geri dönülecek noktayı biraz daha uzaklaştırır.

Kendi onarım sürecimizde her müdahaleden önce dosyalar ve veritabanı yedeklenir, yapılan her değişiklik kayda geçer ve hata kalktıktan sonra ana sayfa, panel, iletişim formu ve varsa ödeme adımı ayrıca test edilir. Sitede tanınmayan dosyalar veya yeni yönetici hesapları görülüyorsa 500 hatası bir uyumsuzluk değil, güvenlik ihlalinin belirtisi olabilir.

500 Internal Server Error İçin Ne Zaman Uzmana Başvurulmalı?

.htaccess yenilendiği, eklentiler kapatıldığı ve bellek kontrol edildiği halde 500 internal server error sürüyorsa uzman desteği zaman kazandırır. Özellikle güncel yedek yoksa, e-ticaret sitesinde sipariş akışı durduysa, hata günlüğüne erişilemiyorsa ya da hata yalnızca belirli saatlerde çıkıyorsa teşhis sistemli yürütülmelidir.

Tek seferlik arızalarda WordPress problem çözme hizmetiyle günlük okunur, neden bulunur ve site yayına döndürülür. Güncellemelerin, yedeklerin ve PHP sürüm geçişlerinin düzenli takip edilmesi isteniyorsa yıllık WordPress bakım ve güncelleme hizmeti bu işi sürekli hale getirir. WordPress bakım hizmeti, sitenin büyüklüğüne ve kapsamına göre aylık 500–2.000 TL arasındadır.