WordPress’te 500 Internal Server Error, tarayıcıya görünen genel bir sunucu hata kodudur; asıl neden değildir. Sorun .htaccess, PHP fatal error, eklenti/tema, memory limit, dosya izinleri, disk doluluğu veya web server/PHP worker katmanından kaynaklanabilir.
En hızlı doğru yaklaşım: Önce son değişikliği ve error logu bulun. Aynı anda PHP sürümü, eklentiler, .htaccess ve dosya izinlerini birlikte değiştirirseniz hangi adımın problemi çözdüğünü anlayamazsınız.
1. Error logu kontrol edin
Hosting panelindeki error log veya sunucuda Nginx/Apache/OpenLiteSpeed ve PHP logları genellikle gerçek fatal erroru gösterir. Timestamp’i hatayı ürettiğiniz anla eşleştirin.
2. .htaccess dosyasını test edin
Apache uyumlu yapıda bozuk rewrite kuralı 500 oluşturabilir. Mevcut dosyayı yedekleyip geçici yeniden adlandırın; site açılırsa WordPress varsayılan kurallarını yeniden oluşturun. Güncel örnek için WordPress Default .htaccess Dosyası rehberini kullanın.
3. Eklenti kaynaklı hata
Panel erişiminiz yoksa wp-content/plugins klasörünü geçici yeniden adlandırarak tüm eklentileri devre dışı test edebilirsiniz. Site açılırsa klasörü geri adlandırın ve eklentileri tek tek açarak sorunlu eklentiyi bulun.
4. Tema
Tema güncellemesi veya custom function fatal error üretiyorsa logdaki dosya/satır numarasını inceleyin. Canlı sitede tema dosyasını rastgele silmek yerine çalışan bir yedek veya staging kullanın.
5. PHP sürümü ve extension
WordPress core güncel olsa bile eski tema/eklenti yeni PHP sürümünde fatal error verebilir. Hosting değişikliğinde kaynak sunucudaki PHP major/minor ve extension listesini hedefle karşılaştırın.
6. Memory limit
Allowed memory size exhausted hatası görüyorsanız memory limit yetersiz olabilir; fakat çok yüksek rastgele değer vermek memory leak veya ağır eklenti problemini gizler. Önce hangi işlem/eklenti belleği tüketiyor bulun.
7. Disk ve inode
df -h
df -iDisk veya inode %100 ise PHP session/cache, upload ve log yazımı bozulabilir. Alanın neden dolduğunu analiz edin.
8. Dosya izinleri
WordPress’te her şeyi 777 yapmak çözüm değildir ve güvenlik riskidir. Dosya sahipliği hosting kullanıcısıyla uyumlu olmalı; standart izinler sunucu modeline göre uygulanmalıdır.
Değişiklik geçmişi kontrolü
- Son eklenti/tema update’i
- PHP sürüm değişimi
- Domain/SSL/redirect değişimi
- Cache/CDN kuralı
- Sunucu taşınması
- Disk/backup temizliği
Sorun çözüldükten sonra
Debug ayarlarını üretim seviyesine geri alın, geçici log/backup dosyalarını güvenli kaldırın ve problemi oluşturan bileşeni güncelleyin veya değiştirin. Yalnız “site açıldı” noktasında bırakmayın.
İlgili UST Bilişim hizmetleri
Sunucu, hosting, DNS veya kurumsal e-posta altyapınız için Hosting / Sunucu / Mail çözümlerimizi inceleyebilir veya teknik ihtiyacınızı bize iletebilirsiniz.
Bilgiyi uygulanabilir projeye dönüştürelim.
İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.
Projenizi Anlatın
