WordPress 500 Internal Server Error: Nedenleri, Tanısı ve Adım Adım Çözüm Rehberi

Site açılsın diye sayfayı her yenilediğinizde karşınıza yine aynı kuru mesaj çıkıyor: 500 Internal Server Error. Ne bir ipucu, ne bir hata kodu detayı, ne de “şunu dene” diyen bir yol işareti. Sadece sitenizin çalışmadığını söyleyen, tarayıcının arka planında boyun bükmüş duran bir sayfa. WordPress ile yıllardır ilgilenen herkes bu ekranı en az bir kez görmüştür — ve çoğu zaman göründüğünden çok daha hızlı çözülebilecek bir sorundan kaynaklanır.

Bu rehberde WordPress 500 Internal Server Error hatasını baştan sona, gerçekten işe yarayan bir sırayla ele alacağım. Önce hatanın ne anlama geldiğini açıklayacağım, ardından günlük olarak karşıma çıkan sekiz ana nedeni tek tek göstereceğim. Sonrasında adım adım bir teşhis akışı vereceğim: hangi dosyaya bakılır, hangi log satırı neyi söyler, hangi değişiklikten sonra siteyi yenilemek gerekir. Yazının sonunda ise bu sorunla bir daha karşılaşmamak için alabileceğiniz kalıcı önlemleri ve sık sorulan soruları bulacaksınız.

İçindekiler

• 500 Internal Server Error Nedir?
• WordPress’te Hangi Belirtilerle Karşınıza Çıkar?
• En Sık Görülen 8 Neden
• Tanı: Beş Dakikada Kaynağı Bulmak
• Adım 1: .htaccess Dosyasını Yenileyin
• Adım 2: Eklentileri Toplu Devre Dışı Bırakın
• Adım 3: Temayı Varsayılana Çevirin
• Adım 4: PHP Bellek Limitini Yükseltin
• Adım 5: PHP Sürümünü Kontrol Edin
• Adım 6: WP_DEBUG ile Gerçek Hatayı Görün
• Adım 7: WordPress Çekirdek Dosyalarını Yenileyin
• Adım 8: Sunucu Hata Kayıtlarına Bakın
• Özel Durumlar: WooCommerce, Elementor, Admin Paneli
• Kalıcı Önleyici Tedbirler
• Sıkça Sorulan Sorular

500 Internal Server Error Nedir?

HTTP protokolünde 500 kodu, “sunucu isteği alamadı ya da işleyemedi ama nedenini söyleyecek kadar bile çalışmıyor” demektir. Yani sunucu kendi kendine “bende bir sorun var, ne olduğunu da tam bilemedim” diyor. İsminin başındaki internal ifadesi tam olarak buradan geliyor: sorun istemcide (tarayıcıda), ağda ya da kullanıcıda değil; doğrudan web sunucusunun içinde.

WordPress özelinde bu hata neredeyse her zaman üç katmandan birinde patlar: Apache/Nginx yapılandırmasında, PHP yorumlayıcısında ya da WordPress’in kendi kod akışında. Kodun herhangi bir noktasında çözülmesi mümkün olmayan bir durum oluşur — bir modül yanıt vermez, bir dosya izni yanlıştır, bir eklenti eski bir PHP fonksiyonunu çağırır — ve sunucu, istemciye sayfa yerine bu jenerik hatayı döner.

Önemli bir detay: 500 bir belirtidir, hastalık değil. Tıpkı beyaz ekran hatası (WSoD) gibi, farklı onlarca kaynağın ortak yüzü. Hatayı çözmenin ilk adımı, kaynağı doğru teşhis etmek. Deneme-yanılma ile yürümek mümkün ama genelde çok yavaştır ve işleri karmaşıklaştırır. Ben hep şöyle derim: “Log okumadan müdahale etme.” Bu yazıda neyi nasıl okuyacağımızı da sırayla göstereceğim.

WordPress’te Hangi Belirtilerle Karşınıza Çıkar?

500 Internal Server Error her zaman aynı kelimelerle gelmez. Tarayıcı ve sunucu kombinasyonuna göre şu yüzleri görebilirsiniz:

• HTTP ERROR 500 — Chrome ve Edge’in kuru versiyonu.
• Internal Server Error — The server encountered an internal error… — Apache’nin klasik mesajı.
• 500 — Internal Server Error — Nginx’in sade versiyonu.
• There is a problem with the resource you are looking for, and it cannot be displayed — IIS sunucularda görülür.
• Beyaz sayfa + tarayıcı başlığında “500” ibaresi — Bazı sunucu yapılandırmalarında hata mesajı gizlenir, tarayıcı tabında yalnızca kod görünür.

Bazen de hatayı yalnızca belirli bir bölümde yaşarsınız. Örneğin önyüz çalışır, sadece wp-admin açılmaz; ya da tam tersi. Admin paneli sorunsuz çalışır, ürün sayfaları 500 döner. Bu ayrım, kaynağı tahmin etmede büyük bir ipucu. Admin tarafı etkilenmiyorsa büyük ihtimalle sorun önyüzde çalışan bir eklenti veya temada; önyüz temizken admin patlıyorsa sorun admin’e özel bir eklenti veya admin-ajax çağrısında.

En Sık Görülen 8 Neden

Yıllardır onlarca sitede benzer senaryolarla uğraşırken fark ettim ki 500 hatası aslında nadiren “esrarengiz”. Aşağıdaki sekiz neden, karşıma çıkan vakaların neredeyse tamamını kapsıyor. Sitenizde son 24 saat içinde hangi değişiklik yapıldıysa, suçlu büyük ihtimalle bu listede.

1. Bozuk veya Aşırı Şişmiş .htaccess

Apache sunucularda 500’ün bir numaralı sebebidir. Güvenlik eklentileri, cache eklentileri, otomatik yönlendirme eklentileri — hepsi kök dizindeki .htaccess dosyasına kural yazar. Zamanla dosya yüzlerce satıra çıkar, kurallar çelişir ve tek bir hatalı satır tüm siteyi düşürür.

2. PHP Bellek Limiti Aşımı

WordPress varsayılan olarak 40-64 MB civarında bellek kullanır. WooCommerce, Elementor gibi ağır eklentiler, büyük bir medya kütüphanesi, yedekleme işlemleri ya da ani trafik artışı bu sınırı aşabilir. Bellek bittiğinde PHP süreci kapanır, sunucu 500 döner.

3. Hatalı Dosya veya Klasör İzinleri

Dosyaların 777, klasörlerin de 777 olarak kalması hem güvenlik hem de stabilite açısından risklidir. Bazı sunucular yanlış izinli klasörlerde kod yürütmeyi reddeder ve doğrudan 500 döner. Standart WordPress izinleri dosyalarda 644, klasörlerde 755’tir; wp-config.php için 600 önerilir.

4. Eklenti Çakışması veya Bozuk Güncelleme

İki eklentinin aynı WordPress kancasına (hook) uyumsuz şekilde müdahale etmesi, ya da bir eklentinin yeni sürümünün PHP tarafında artık desteklenmeyen bir fonksiyon kullanması tipik bir 500 yaratır. En sık yaşadığım çakışmalar: cache eklentisi + güvenlik eklentisi, WooCommerce + ödeme sağlayıcısı eklentisi, SEO eklentisi + sayfa oluşturucu.

5. Tema Hatası

Özellikle child theme’deki functions.php‘ye eklenen bir kod bloğunun sözdiziminde (syntax) hata olması, tüm WordPress’i anında 500’e düşürür. Noktalı virgül unutmak ya da kapama parantezini eksik bırakmak bile yeterlidir.

6. PHP Sürüm Uyumsuzluğu

Barındırıcınız sunucuyu PHP 8.3 veya 8.4’e yükselttiyse, eski eklenti veya temalardaki each(), create_function() gibi kaldırılmış fonksiyonlar aniden çalışmaz hale gelir. Tersine, PHP 7.4 gibi çok eski bir sürümdeyseniz yeni WordPress sürümlerindeki modern sözdizimi karşılanamaz.

7. WordPress Çekirdek Dosyalarında Bozulma

Yarıda kesilen bir güncelleme, FTP üzerinden yapılmış başarısız bir yükleme, disk kotasının dolması ya da kötü niyetli bir müdahale çekirdek dosyalarını bozabilir. Çekirdek bozuksa WordPress ne önyüzde ne admin panelinde sağlıklı yanıt üretir.

8. Sunucu Seviyesi Sorunlar

Paylaşımlı hosting’lerde komşu bir sitenin kaynak tüketimi sizin sürecinizi de çökertebilir. Ya da FastCGI, FPM, OpCache gibi alt katmanlarda bir servis düşmüş olabilir. Bazen hosting sağlayıcısı arka planda bakım yapar ve geçici 500 yaşarsınız.

Tanı: Beş Dakikada Kaynağı Bulmak

Çözüme geçmeden önce on saniyelik bir teşhis yapın. Şu üç soruyu kendinize sorun:

1. Son 24 saatte sitede ne değişti? Eklenti kurdunuz mu, güncelleme yaptınız mı, bir satır kod eklediniz mi, hosting panelinde bir şey değiştirdiniz mi? Genelde suçlu en son dokunulan şeydir.
2. Hata sitenin tamamında mı, belirli bir bölümünde mi? Yalnızca admin’de ise eklenti; yalnızca önyüzde ise tema; yalnızca /checkout‘ta ise WooCommerce veya ödeme entegrasyonu olma ihtimali yüksek.
3. Ziyaretçi gözünden mi, sizin gözünüzden mi 500 görünüyor? Farklı tarayıcı, incognito sekme, farklı IP (mobil veri) ile deneyin. Sorun sizde ise cache veya çerez, herkeste ise gerçek sunucu hatası.

Bu üç soru sayesinde hangi adıma öncelik vereceğinizi bilirsiniz. Yoksa sekiz adımı baştan sona tek tek uygulamak saatlerinizi yer.

Adım 1: .htaccess Dosyasını Yenileyin

İstatistiksel olarak 500 hatalarının en büyük dilimi .htaccess kaynaklıdır, o yüzden taşları en ağır olandan yerleştiriyoruz. FTP, SFTP veya hosting panelinin dosya yöneticisi üzerinden sitenin kök dizinine gidin. .htaccess dosyasını bulun (başındaki nokta nedeniyle gizli olabilir; dosya yöneticisinde “gizli dosyaları göster” seçeneğini açmanız gerekebilir).

Dosyanın yedeğini masaüstünüze indirin, sonra adını .htaccess.old olarak değiştirin. Ardından siteyi yenileyin. Hata kayboldu mu? Harika — sorun bu dosyadaydı. Şimdi boş bir .htaccess dosyası oluşturun ve şu standart WordPress kurallarını yazın:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Kaydedin ve siteyi yenileyin. Bu satırlar WordPress’in kalıcı bağlantı yapısı için gerekli en temel yönlendirme kurallarıdır; başka hiçbir şeye ihtiyacınız yok. Güvenlik ve cache eklentileriniz zaten kendi kurallarını sonradan otomatik olarak yeniden yazacaktır. Eğer bilerek yazdığınız özel kurallar vardıysa (örneğin bir IP bloğu, özel yönlendirme), tek tek .htaccess.old‘dan alıp bu dosyaya geri ekleyin — hangisinin hata yarattığını tespit etmiş olursunuz.

Nginx kullanıyorsanız .htaccess yerine nginx.conf ya da site config dosyasına bakmanız gerekir. Nginx yapılandırmasını yanlışlıkla bozma olasılığı daha düşük olduğu için (direkt kendi konfig dilini kullanır) 500’ün kaynağı olması da daha nadirdir.

Adım 2: Eklentileri Toplu Devre Dışı Bırakın

.htaccess çözüm getirmediyse ve son günlerde bir eklenti kurduysanız ya da güncellediyseniz, sıra eklentilerde. Admin paneline girebiliyorsanız iş kolay: Eklentiler sayfasında tüm eklentileri tek seferde seçip “Etkinliği Kaldır” yapabilirsiniz. Ardından siteyi yenileyin.

Admin paneline giremiyorsanız FTP yolunu kullanın. Sitenizin /wp-content/plugins/ klasörüne gidin ve adını geçici olarak plugins-disabled olarak değiştirin. WordPress eklentileri bulamayınca hepsini devre dışı sayar ve büyük olasılıkla site açılır.

Site açıldıysa suçlu bir eklenti. Şimdi klasör adını plugins‘e geri alın. İçindeki tek tek her eklenti klasörünü yeniden adlandırarak devre dışı bırakın (woocommerce → woocommerce-off gibi) ve her seferinde siteyi yenileyin. Hangisinde site tekrar 500’e düşüyorsa suçlu odur.

Küçük bir pratik tavsiye: Çok eklentili sitelerde (30+) ikili arama yapmak daha hızlıdır. Eklentilerin yarısını kapatın, site açılıyorsa suçlu diğer yarıda. Yine yarısını kapatın. Altıncı adımda debug log’undan doğrudan eklenti adını öğrenme yolunu da göstereceğim; büyük sitelerde doğrudan oraya atlamak çok zaman kazandırır.

Adım 3: Temayı Varsayılana Çevirin

Eklentiler temiz çıktıysa sıra temada. Özellikle child theme kullanıyorsanız ve son dönemde functions.php‘ye kod eklediyseniz, ilk bakacağınız yer orası. Admin panelden Görünüm → Temalar üzerinden varsayılan bir temaya (Twenty Twenty-Five, Twenty Twenty-Four) geçin.

Admin’e giremiyorsanız FTP ile /wp-content/themes/ klasöründeki aktif temanızın klasör adını değiştirin. WordPress otomatik olarak varsayılan temaya düşecektir. Hiçbir varsayılan tema kurulu değilse, tr.wordpress.org/themes adresinden Twenty Twenty-Five’i indirip themes klasörüne ekleyin.

Site varsayılan temada açılıyorsa suçlu kendi temanızdır. Önce functions.php‘de en son eklediğiniz kod bloğunu yorum satırına alın ve test edin. Çoğu zaman sorun budur. Değilse sırasıyla header.php, footer.php ve single.php‘yi varsayılan haline geri alarak ilerleyin. Temanın tamamını elden geçirmek yerine son değiştirilen dosyayı bulmak için sunucudaki dosya tarihlerine bakmak iş görür:

ls -lt wp-content/themes/your-theme/*.php | head -n 10

Bu komut en son düzenlenen on dosyayı sıralar. Genelde en üstteki iki üç dosya suçludur.

Adım 4: PHP Bellek Limitini Yükseltin

Error log’unda “Allowed memory size of X bytes exhausted” benzeri bir mesaj görüyorsanız teşhis net: bellek bitmiş. wp-config.php dosyanızda /* That's all, stop editing! */ satırının üzerine şu iki tanımı ekleyin:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

İlk satır önyüz için, ikincisi admin paneli ve medya yüklemesi içindir. Kaydedin, siteyi yenileyin.

Bu satırlar etkisiz kaldıysa sorun hosting seviyesinde dayatılan bir üst limit olabilir. Bu durumda .htaccess‘e şu satırı ekleyebilirsiniz (Apache için):

php_value memory_limit 256M

Ya da php.ini veya hosting panelinizdeki PHP ayarları bölümünden memory_limit değerini 256M’e çekin. Paylaşımlı hosting’lerde sabit bir tavan olabilir; o zaman hosting desteğine yazmanız gerekir. Saygın bir barındırıcı bu talebi genelde birkaç saat içinde karşılar.

Bellek sınırı meselesi sadece 500’ü değil, sitenin genel hızını da doğrudan etkiler. Bu konunun altında daha geniş bir performans hikâyesi yatar. İlgileniyorsanız Core Web Vitals rehberimiz LCP ve FID skorlarınızı nasıl toparlayacağınızı ayrıntılı anlatıyor.

Adım 5: PHP Sürümünü Kontrol Edin

Hosting paneli (cPanel, Plesk, DirectAdmin, hPanel, Cloudways) üzerinden PHP sürümünüzü kontrol edin. WordPress 6.x için önerilen aralık 8.1 – 8.2‘dir.

• PHP 7.4 veya daha eski: Resmi destek dışı. Eklentilerinizin çoğu artık uyumsuz. Güvenlik riski. Mutlaka güncelleyin.
• PHP 8.3 veya 8.4: Yeni ama bazı eski eklenti/temalarla sorun çıkarabilir. 500 aldıysanız 8.2’ye düşürüp tekrar deneyin.
• PHP 8.1 – 8.2: Modern WordPress için tatlı nokta.

Sürüm değişikliği hosting panelinde neredeyse anında uygulanır. Değiştirdikten sonra 30 saniye bekleyip siteyi yenileyin. Ani bir 500 birkaç gün önce başladıysa ve hosting firmanız o aralıkta otomatik PHP yükseltmesi yaptıysa, genelde sorunun kaynağı budur.

Eğer PHP sürümünü değiştirme yetkiniz yoksa ve paylaşımlı hosting’deyseniz, bu aslında daha büyük bir sorunun ipucu. Yetersiz bir hosting paketi, zamanla böyle teknik engellerin kaynağı olur. WordPress için en uygun hosting seçimi rehberimizde hangi tip paketin hangi trafik seviyesine uyduğunu detaylı anlatıyorum.

Adım 6: WP_DEBUG ile Gerçek Hatayı Görün

Buraya kadar geldiyseniz ama sorunu hâlâ bulamadıysanız, artık karanlıkta atış yapmayı bırakıp ışığı açma vakti. WordPress’in dahili hata ayıklama modunu etkinleştireceğiz. wp-config.php dosyasını açın ve şu üç satırı ekleyin:

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

Bu yapılandırmayla hatalar ziyaretçinin ekranına basılmaz (güvenlik açısından çok önemli), sadece /wp-content/debug.log dosyasına yazılır. Kaydedip siteyi birkaç kez yenileyin. Sonra FTP ile debug.log dosyasını açın.

Beklediğiniz gibi bir çıktıyla karşılaşacaksınız:

[19-Apr-2026 14:32:01 UTC] PHP Fatal error: Uncaught Error: Call to undefined function WC() in /home/user/public_html/wp-content/plugins/my-shipping-plugin/init.php:47
Stack trace:
#0 /home/user/public_html/wp-includes/class-wp-hook.php(324): MyShipping->init('')
#1 /home/user/public_html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters('', Array)
#2 /home/user/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#3 /home/user/public_html/wp-settings.php(592): do_action('plugins_loaded')
#4 /home/user/public_html/wp-load.php(50): require_once('/home/user/publ...')

Bu beş satır size her şeyi söyler: hatanın tipi (Call to undefined function), sorunlu dosya yolu (plugins/my-shipping-plugin/init.php), satır numarası (47) ve hatanın tetiklendiği fonksiyon (WC()). Bu örnek, my-shipping-plugin‘in WooCommerce’in bulunmasına rağmen yüklenme zamanlamasında ondan önce çalıştığı veya WooCommerce’in bir sonraki güncellemede kaldırdığı bir fonksiyonu beklediği anlamına gelir. Çözüm: eklentiyi güncel sürümüne çıkarmak ya da geliştiricisine sorunu bildirmek.

WP_DEBUG’ı işi bitince mutlaka kapatın. Canlı ortamda uzun süre açık bırakmak küçük bir performans maliyeti yaratır; tarihi hata satırları log dosyasında birikir ve disk dolmaya başlar.

Adım 7: WordPress Çekirdek Dosyalarını Yenileyin

Debug log’unda hata wp-includes/ veya wp-admin/ altındaki bir dosyaya işaret ediyorsa ya da log hiçbir şey göstermeden 500 devam ediyorsa, çekirdek dosyaları bozulmuş olabilir. Endişe etmeyin, doğru yaparsanız hiçbir içeriğiniz silinmez.

Adım adım:

1. tr.wordpress.org/download adresinden son sürüm WordPress’i indirin.
2. ZIP arşivini bilgisayarınızda açın.
3. FTP ile sunucuya bağlanın. wp-admin ve wp-includes klasörlerini içlerindekilerle birlikte sunucudaki karşılıklarının üzerine yazın.
4. Kök dizindeki index.php, wp-login.php, wp-activate.php, wp-blog-header.php, wp-cron.php, wp-load.php, wp-mail.php, wp-settings.php, xmlrpc.php, license.txt, readme.html dosyalarını da yenileyin.
5. Sakın dokunmayın: wp-config.php ve wp-content. Siteniz, eklentileriniz, medyanız ve veritabanı bağlantınız oradadır.

İşlem bittikten sonra siteyi yenileyin. Güncelleme yarıda kalmış veya çekirdek kısmen bozulmuşsa %90 ihtimalle sorun burada çözülür.

Adım 8: Sunucu Hata Kayıtlarına Bakın

WordPress’in hiç haberi olmayan hatalar da vardır. Çünkü sorun WordPress çalışmaya başlamadan önce oluşmuştur — PHP-FPM havuzu çökmüştür, disk dolmuştur, ya da Apache bir modülü yüklerken takılmıştır. Bu durumda WP_DEBUG bile yazılmadan 500 gelir.

Sunucu hata kayıtlarına nereden bakacağınız barındırıcınıza göre değişir:

• cPanel: Metrics → Errors menüsü veya File Manager’da public_html’in üzerindeki error_log dosyası.
• Plesk: Domains → ilgili alan adı → Logs.
• Apache sunucu (VPS): /var/log/apache2/error.log veya /var/log/httpd/error_log.
• Nginx sunucu (VPS): /var/log/nginx/error.log.
• Cloudways / LiteSpeed panelleri: Hosting panelinde Logs / Error Logs menüsü.

Arayacağınız satırlar genelde şunlardır:

• segmentation fault — genelde bozuk bir PHP modülü.
• disk quota exceeded — hosting disk kotası dolmuş.
• too many open files — sistem düzeyinde dosya tanımlayıcı limiti aşılmış.
• FastCGI: comm with server aborted — PHP-FPM süreci iletişim kuramıyor; genelde bellek/timeout kaynaklı.
• Premature end of script headers — PHP, HTTP başlıklarını dönmeden önce çökmüş.

Bu satırlardan birini görürseniz, sorun artık WordPress değil, sunucu seviyesinde. Hosting desteğine başvurmadan önce elinize sağlam bir delil geçmiş olur.

Özel Durumlar: WooCommerce, Elementor, Admin Paneli

Checkout’ta 500 — WooCommerce Ödeme Hatası

Sadece sepet veya ödeme sayfasında 500 görüyorsanız neredeyse her zaman suçlu ödeme sağlayıcısı eklentisidir. İyzico, PayTR, Stripe, PayPal gibi sağlayıcıların eklentileri sunucuya giden/gelen SSL istekleriyle çalışır; sertifika sorunu, webhook hatası, cURL yapılandırması ya da bellek limiti bu sayfaları yere serer. WooCommerce → Durum → Log menüsünden o sağlayıcının log’unu mutlaka okuyun — neredeyse her zaman sorunu söyler.

Elementor Editor Açılmıyor

Elementor editörü açılırken 500 alıyorsanız sorun %95 oranında ya bellek limitinde ya da max_input_vars değerindedir. wp-config.php‘ye WP_MEMORY_LIMIT 256M ekleyin, .htaccess veya php.ini‘de max_input_vars = 3000 yazın. Hâlâ devam ediyorsa Elementor menüsündeki Tools → General → Regenerate CSS & Data işlemini deneyin.

Admin Paneli 500, Önyüz Temiz

Büyük ihtimalle admin tarafında çalışan bir eklenti suçlu. FTP ile /wp-content/plugins/ içindeki eklentileri tek tek devre dışı bırakın. Sıklıkla form eklentileri (Contact Form 7, WPForms), SEO eklentileri (Yoast, Rank Math) veya özel admin paneli widget’ları çıkar karşımıza.

Önyüz 500, Admin Çalışıyor

Tema veya önyüzde çalışan bir eklenti (cache, CDN, slider, optimizasyon). Önce temayı varsayılana çevirin, sonra sırasıyla cache ve CDN eklentilerini kapatın.

Güncelleme Sonrası 500

WordPress veya eklenti güncellemesi yarıda kesildiyse kök dizinde .maintenance adlı bir dosya takılı kalabilir. Bu dosyayı silin; eğer yarıda kalmış bir çekirdek güncellemesi varsa Adım 7’yi uygulayın.

500 + “Siteniz Hacklendi” Şüphesi

500 ile birlikte Google Search Console’dan “güvenlik sorunu” uyarısı gelmeye başladıysa, yalnızca teknik bir düzeltme yetmez. WordPress sitem hacklendi rehberimiz o senaryoda izlemeniz gereken sıralı adımları içeriyor.

Kalıcı Önleyici Tedbirler

500 hatasını ilk kez gören biri için bu yazıdaki adımlar bile yeterli. Ama ikinci, üçüncü kez aynı şeyle uğraşmak ciddi zaman kaybı. Aşağıdaki alışkanlıkları yerleştirirseniz bu yazıya yıllarca dönme ihtiyacı duymazsınız:

• Staging ortamı kullanın: Canlı sitede güncelleme yapmayın. Klon ortamda test edin, sonra canlıya alın. Çoğu modern hosting bu özelliği ücretsiz sunar.
• Otomatik yedekleme: UpdraftPlus, BlogVault, Solid Backups, Duplicator Pro. Her güncellemeden önce otomatik yedek alır; bir şeyler ters giderse 10 dakikada eski duruma dönersiniz.
• Eklenti diyeti: Gerçekten kullanmadığınız her eklentiyi silin. “Lazım olur” diye bekletilen eklentiler güvenlik yüzeyini büyütür ve çakışma riskini artırır.
• Bellek sınırını sabitleyin: Her yeni kurulumda WP_MEMORY_LIMIT‘i 256M’e çekin. Geleceğin sorunlarını bugünden önlersiniz.
• Log izleme: Sunucu error log’una haftada bir göz atın. Felaket olmadan önce ipuçlarını görmek mümkün.
• Uptime takibi: UptimeRobot, Better Uptime, StatusCake gibi servisler siteyi her dakika kontrol eder. 500 olur olmaz size bildirim düşer; ziyaretçilerden önce siz haberdar olursunuz.
• PHP yol haritası: Barındırıcınızın PHP güncelleme programını takip edin. Sunucu PHP 8.3’e çıkacaksa siteyi önceden staging’de test edin.
• Düzenli bakım rutini: Ayda bir eklenti/tema/çekirdek güncellemesi, yedek testi, güvenlik taraması ve performans kontrolü. Tek başınıza yapıyorsanız takvime koyun; yapmıyorsanız profesyonel desteğe devredin.

Bakım Yükünü Üzerinizden Almak

Yukarıdaki adımların neredeyse hepsi teknik bilgi gerektirir ve yanlış yapılan bir müdahale (özellikle wp-config.php‘de sözdizimi hatası veya çekirdek dosyaların yanlış yerine yüklenmesi) sorunu büyütebilir. WPNeta WordPress Bakım Paketi tam olarak bu alanda fark yaratmak için kuruldu: haftalık yedek, PHP ve eklenti uyumluluk testleri, güvenlik taramaları, 7/24 uptime izleme, çekirdek ve eklenti güncellemelerinin staging’de test edilip canlıya geçirilmesi. Siz siteniz üzerinde üretmeye odaklanırken biz arka planda sitenin ayakta kalmasını garanti altına alıyoruz. 500 yerine yeni bir kampanyanın metnine odaklanmak her zaman daha iyidir.

Sonuç

WordPress 500 Internal Server Error ilk bakışta panik yaratan bir hata. Ama gördüğünüz gibi, ardındaki neden çoğu zaman .htaccess, PHP, bellek veya bir eklenti kaynaklı — ve her biri için net, tekrarlanabilir bir müdahale var. Bu yazıda gösterdiğim sekiz adım, sitenizdeki sorunun büyük çoğunluğunu en fazla yarım saatte çözer.

En önemli tavsiyem: kaynağı görmeden müdahale etmeyin. Beş dakika debug.log‘u okumak, iki saat süren deneme-yanılmadan her zaman daha verimlidir. Hata üzerinize geldiğinde soğukkanlı olup sırayla ilerleyin — ve bir dahaki sefere hazır olmak için bu yazıya not düşmeyi unutmayın.

Sıkça Sorulan Sorular

500 Internal Server Error verilerimi siler mi?

Hayır. 500, sunucunun sizin sitenizi sunamaması anlamına gelir; ama veritabanınız, medya dosyalarınız ve yazılarınız olduğu yerde durur. Yine de müdahale etmeden önce tam bir yedek almak altın kuraldır. Özellikle .htaccess, çekirdek dosyalar veya wp-config.php üzerinde çalışacaksanız, bir yanlış adımda geri dönebilmek çok değerlidir.

Admin paneline giremiyorum, nasıl devam edebilirim?

FTP veya hosting panelinin dosya yöneticisi ile /wp-content/plugins/ klasörünün adını plugins-off olarak değiştirin. WordPress eklentileri bulamaz, hepsini devre dışı sayar ve genelde admin paneli açılır. Giriş yaptıktan sonra klasör adını geri alıp eklentileri tek tek aktifleştirerek suçluyu izole edebilirsiniz.

WP_DEBUG’ı canlı sitede açık bırakmak güvenli mi?

WP_DEBUG_DISPLAY = false olarak bırakılırsa ziyaretçiler hatayı görmez, yalnızca log dosyasına yazılır. Bu yüzden canlıda da kullanabilirsiniz. Ancak sorun çözüldükten sonra üç satırı da kapatın — log dosyası büyümeye devam eder ve küçük bir performans maliyeti yaratır.

Tüm eklentileri kapattım ama hata devam ediyor. Şimdi ne yapmalıyım?

Sıra temada ve sunucu seviyesinde. Önce temayı varsayılana çevirin (Adım 3). O da işe yaramazsa PHP sürümü (Adım 5), bellek limiti (Adım 4), .htaccess (Adım 1) ve sunucu error log’una (Adım 8) bakın. Her durumda debug.log‘u mutlaka kontrol edin. Hatanın söylediğini dinlemeden iterasyon yapmak sürelerinizi katlar.

Site bazen açılıyor, bazen 500 veriyor. Neden?

Bu tipik olarak kaynak sınırlarının dönem dönem aşıldığını gösterir: bellek limiti, eş zamanlı bağlantı sayısı, PHP-FPM süreç sayısı. Paylaşımlı hosting’de komşu sitelerin yoğun kullanımı sizi de etkileyebilir. Sunucu error log’unda “too many connections”, “memory exhausted” veya “resource temporarily unavailable” arayın. Sık yaşanıyorsa hosting paketini büyütmek ya da değiştirmek şart.

500 hatası Google sıralamamı etkiler mi?

Birkaç saatlik 500 Google için normaldir; geçici bir hata olarak işaretlenir ve sıralama kaybı yaratmaz. 24 saati geçen kesintilerde Googlebot sayfaları yeniden taramaya başlar ve bazı URL’ler dizinden düşebilir. Search Console’dan “Canlı URL’yi Test Et” özelliği ile kritik sayfalarınızı kontrol etmek iyi bir alışkanlıktır. 500 uzun sürdüyse, toparlandıktan sonra Search Console’dan yeniden tarama talebi gönderin.

Ödeme sayfasında 500 alıyorum, WooCommerce buna dayanamaz, ne yapmalıyım?

WooCommerce → Durum → Log menüsüne gidin. Ödeme sağlayıcınızın (İyzico, PayTR, Stripe, PayPal vb.) log’u orada listelenmiş olur. Sorunun kaynağı çoğu zaman üç yerden biridir: SSL sertifikası, webhook yapılandırması, cURL zaman aşımı. Log size hangisi olduğunu direkt söyler. Düzeltilmezse ilgili ödeme sağlayıcısının destek ekibiyle paylaşacağınız en doğru belge o log’dur.

Hosting firmam “bizden kaynaklı değil” diyor, ne yapabilirim?

Önce üç şeye sahip olduğunuzdan emin olun: debug.log‘un son 200 satırı, sunucu error log’unun ilgili kısmı, sorunun başladığı kesin saat. Bu üç bilgiyle hosting’e dönerseniz “bizden değil” cevabı verecek yer kalmaz. Özellikle sunucu log’larında FastCGI, FPM, segmentation fault gibi ibareler varsa sorun sunucudadır ve destekte ısrarcı olmanız gerekir.

Paylaşımlı hosting mi, VPS mi? Hangi tipte 500 daha az görülür?

İstatistiksel olarak paylaşımlı hosting’de daha sık görülür. Bellek sınırları daha düşük, paylaşılan kaynak havuzu daha küçük, komşu site riski daha büyük. Yüksek trafikli ya da kritik sitelerde yönetilen WordPress hosting veya VPS neredeyse her zaman daha stabildir. Bütçe izin veriyorsa özellikle WooCommerce ve kurumsal siteler için paylaşımlı paketten uzaklaşmak yatırımına değer.