WordPress sitenizi açtığınızda yalnızca "There has been a critical error on this website." ya da Türkçe arayüzde "Sitenizde ciddi bir sorun çıktı." cümlesini görüyorsanız (Türkçe aramalarda bu hata çoğunlukla "WordPress kritik hata" diye geçer), PHP tarafında site kodunun çalışmasını durduran ölümcül bir hata (fatal error) oluşmuş demektir. WordPress bu durumda eskiden olduğu gibi bomboş bir beyaz sayfa göstermek yerine bu kısa mesajı gösterir ve sunucu yanıtını HTTP 500 durum koduyla döndürür.
İyi haber şu: hatanın kaynağı neredeyse her zaman belirli bir eklenti, tema, PHP sürümü uyumsuzluğu ya da bellek sınırıdır ve siteye erişiminiz olmasa bile adım adım bulunabilir. Bu yazıda önce ziyaretçinin yapabileceği basit kontrolleri, ardından site sahibinin Kurtarma Modu (Recovery Mode), debug.log, eklenti klasörünü yeniden adlandırma ve tema değiştirme gibi yöntemlerle sorunu nasıl çözeceğini anlatıyoruz.
Bu hata ne anlama geliyor?
WordPress 5.2 sürümüyle birlikte "fatal error protection" (ölümcül hata koruması) geldi. Bir eklenti ya da tema PHP ölümcül hatasına yol açtığında WordPress hatayı yakalar, ziyaretçiye genel bir hata ekranı gösterir ve site yöneticisine bir e-posta gönderir. WordPress kaynak kodundaki varsayılan şablona göre ekranda şu metinlerden biri görünür:
- There has been a critical error on this website. En sade hâli; ziyaretçilerin gördüğü mesajdır.
- There has been a critical error on this website. Please check your site admin email inbox for instructions. Tek siteli kurulumda giriş ve yönetim gibi korunan sayfalarda görünür; yöneticiye e-posta gönderildiğini belirtir.
- There has been a critical error on this website, putting it in recovery mode. Kurtarma Modu etkin olduğunda görülür.
- Çok siteli (multisite) ağlarda yönetici e-postası yerine site yöneticisiyle iletişime geçmeniz istenir.
Mesajın altında genellikle "Learn more about troubleshooting WordPress." bağlantısı bulunur. Bu ekran yalnızca bir perdedir; asıl hata mesajı (hangi dosyada, hangi satırda ne olduğu) sunucunun hata kaydında veya WordPress hata ayıklama günlüğünde durur.
Ziyaretçiyseniz: sizin yapabilecekleriniz
Bu hata sitenin sunucusunda oluşur; tarayıcınızda bir sorun olduğunu göstermez. Yine de birkaç kısa kontrol yapabilirsiniz:
- Sayfayı birkaç dakika sonra yenileyin. Site sahibi o sırada güncelleme yapıyor olabilir.
- Sitenin başka bir sayfasını açmayı deneyin. Hata yalnızca belirli bir sayfadaki eklentiden kaynaklanıyor olabilir.
- Farklı bir tarayıcı ya da cihazla deneyin; hata devam ediyorsa sorun kesinlikle sitededir.
- Siteyle iletişim kurabiliyorsanız (e-posta, sosyal medya) hata mesajının ekran görüntüsünü ve saatini site sahibine iletin.
Önbellek temizlemek veya VPN kapatmak bu hatayı çözmez, çünkü hata PHP kodunun sunucuda çalışırken çökmesinden kaynaklanır.
Site sahibiyseniz 1. adım: Kurtarma Modu e-postası
Hata oluştuğunda WordPress, [Site Adı] Your Site is Experiencing a Technical Issue konulu bir e-postayı yönetici adresine gönderir (Türkçe WordPress kurulumlarında konu satırı "[Site Adı] sitenizde teknik bir sorun yaşanıyor" olarak gelir). Bu e-posta hangi eklenti veya temanın hataya neden olduğunu ve gizli bir Kurtarma Modu bağlantısını içerir.
- Bağlantıya tıkladığınızda tarayıcınıza bir çerez yerleştirilir ve hataya neden olan eklenti veya tema yalnızca sizin oturumunuz için duraklatılır. Ziyaretçiler için site hâlâ hatalıdır.
- Giriş yaptıktan sonra Eklentiler veya Temalar ekranında sorunlu eklentiyi devre dışı bırakın, güncelleyin ya da silin.
- İşiniz bitince yönetim çubuğunda görünen Kurtarma Modundan çıkma düğmesine basın. Sorun çözülmediyse hata tekrar görünür.
WordPress kaynak koduna göre e-posta varsayılan olarak en fazla günde bir kez gönderilir ve bağlantı da varsayılan olarak bir gün geçerlidir. E-posta RECOVERY_MODE_EMAIL sabiti tanımlıysa o adrese, değilse Ayarlar > Genel ekranındaki yönetici e-posta adresine gider.
// wp-config.php: kurtarma e-postasının gideceği adres (isteğe bağlı)
define( 'RECOVERY_MODE_EMAIL', 'teknik@ornekalanadi.com' );Site sahibiyseniz 2. adım: hata kaydını açın (WP_DEBUG ve debug.log)
Bu adımda wp-config.php, .htaccess veya veritabanı üzerinde değişiklik yapacaksanız önce yedek alın. Dosyayı kendi bilgisayarınıza indirmek ya da cPanel Dosya Yöneticisi ile bir kopyasını oluşturmak yeterlidir; veritabanı için phpMyAdmin dışa aktarma veya panelinizin yedek aracını kullanın.
Hatanın tam metnini görmek için WordPress hata ayıklama sabitlerini kullanın. WordPress belgelerine göre bu satırlar wp-config.php dosyasında /* That's all, stop editing! Happy blogging. */ satırından önce eklenmelidir:
// Hata ayıklama modunu aç
define( 'WP_DEBUG', true );
// Hataları wp-content/debug.log dosyasına yaz
define( 'WP_DEBUG_LOG', true );
// Hataları ziyaretçilere gösterme
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUGvarsayılan olarakfalsedeğerindedir. Değeri tırnak içinde yazmayın; belgeler'false'şeklinde yazılan değerin true sayıldığını belirtir.WP_DEBUG_LOGtrue olduğunda hatalar içerik klasöründekidebug.logdosyasına, yani genelliklewp-content/debug.logyoluna yazılır. Bir dosya yolu da verebilirsiniz.WP_DEBUG_DISPLAYvarsayılan olarak true değerindedir; canlı sitede hataların sayfada görünmemesi için false yapın.
Ayarı kaydettikten sonra hatalı sayfayı bir kez yenileyin ve wp-content/debug.log dosyasını Dosya Yöneticisi veya FTP ile açın. En alttaki PHP Fatal error satırı size dosya yolunu gösterir. Örneğin yol wp-content/plugins/eklenti-adi/ ile başlıyorsa suçlu o eklentidir; wp-content/themes/ ile başlıyorsa temadır.
PHP Fatal error: Uncaught Error: Call to undefined function ornek_fonksiyon()
in /home/kullanici/public_html/wp-content/plugins/eklenti-adi/eklenti.php:42cPanel kullanıyorsanız Metrics bölümündeki Errors arayüzü, web sunucusu hata kayıtlarındaki en son 300 kaydı en yeniden eskiye doğru listeler. PHP hata kayıtlarının nereye yazıldığı sunucu yapılandırmasına göre değişir; bulamazsanız barındırma firmanıza sorun.
Site sahibiyseniz 3. adım: eklentileri FTP veya Dosya Yöneticisi ile devre dışı bırakın
Yönetim paneline giremiyorsanız WordPress belgelerinin önerdiği yöntem eklenti klasörünün adını değiştirmektir. Bu yöntem eklenti ayarlarını silmez, yalnızca hepsini devre dışı bırakır:
- FTP istemcisi (örneğin FileZilla) veya cPanel Dosya Yöneticisi ile sitenizin
wp-contentklasörüne gidin. pluginsklasörünün adınıplugins.holdgibi bir adla değiştirin./wp-admin/plugins.phpadresinden giriş yapın. WordPress eklentilerin bulunamadığını bildirir ve onları devre dışı sayar.- Klasörün adını tekrar
pluginsyapın. Eklentiler devre dışı kalır; şimdi tek tek etkinleştirip hangisinin hatayı geri getirdiğini bulun.
Sorunlu eklentiyi zaten debug.log sayesinde biliyorsanız bütün klasör yerine yalnızca o eklentinin klasörünü (örneğin wp-content/plugins/eklenti-adi) yeniden adlandırmanız yeterlidir.
WordPress belgeleri ikinci bir yol olarak phpMyAdmin ile wp_options tablosundaki active_plugins satırının option_value değerini a:0:{} yapmayı da gösterir. Bu yöntem bütün eklentileri devre dışı bırakır; veritabanında değişiklik yapmadan önce mutlaka yedek alın. Tablo ön eki sizin kurulumunuzda wp_ dışında bir şey olabilir.
Site sahibiyseniz 4. adım: varsayılan temaya geçin
Hata yeni bir tema etkinleştirdikten veya tema güncellemesinden sonra başladıysa tema şüphelidir. Panele girebiliyorsanız Görünüm > Temalar ekranından Twenty Twenty-Five gibi varsayılan bir WordPress temasını etkinleştirin. Giremiyorsanız WordPress belgelerine göre wp-content/themes/ altındaki etkin temanızın klasör adını değiştirin; WordPress bu durumda yüklü bir varsayılan temaya döner. Bunun için sunucuda en az bir varsayılan tema yüklü olmalıdır.
PHP sürümü uyumsuzluğu
Hosting firmanız PHP sürümünü yükselttiyse ya da siz yeni bir sürüme geçtiyseniz, eski bir eklenti veya tema artık var olmayan bir PHP fonksiyonunu çağırdığı için çökebilir. Tersi de mümkündür: güncel bir eklenti eski PHP sürümünde çalışmayabilir.
- WordPress.org gereksinimler sayfası şu anda PHP 8.3 veya üstünü önerir.
- php.net destek tablosuna göre 31 Ekim 2026 itibarıyla PHP 8.4 ve 8.5 etkin destekte, 8.2 ve 8.3 yalnızca güvenlik düzeltmesi alıyor; 8.2 için güvenlik desteği 31 Aralık 2026'da bitiyor. 8.1 ve öncesi desteklenmiyor.
- Hangi WordPress sürümünün hangi PHP sürümleriyle uyumlu olduğu WordPress Hosting Handbook uyumluluk tablosunda listelenir.
cPanel'de PHP sürümünü MultiPHP Manager arayüzünden değiştirebilirsiniz: alan adının yanındaki kutuyu işaretleyin, PHP Version menüsünden sürümü seçin ve Apply düğmesine basın. Hata sürüm değişikliğinden hemen sonra başladıysa önce önceki sürüme dönüp siteyi ayağa kaldırın, ardından eklentileri güncelleyip yeniden deneyin.
Nedenler, belirtiler ve çözümler
| Neden | Belirti (debug.log veya zamanlama) | Çözüm |
|---|---|---|
| Eklenti hatası | Hata yolu wp-content/plugins/... içinde; çoğu zaman güncelleme sonrası | Kurtarma Modu ile veya klasörü yeniden adlandırarak eklentiyi devre dışı bırakın, güncelleyin ya da değiştirin |
| Tema hatası | Hata yolu wp-content/themes/... içinde | Varsayılan temaya geçin, tema güncellemesini veya functions.php değişikliğinizi geri alın |
| PHP sürümü uyumsuzluğu | Call to undefined function gibi hatalar; PHP değişikliğinden hemen sonra | MultiPHP Manager ile uyumlu sürüme dönün, eklentileri güncelleyin |
| Bellek sınırı | Allowed memory size of ... bytes exhausted | Bellek sınırını kontrollü artırın, bellek tüketen eklentiyi bulun |
| Bozuk veya eksik çekirdek dosyalar | Hata yolu wp-includes veya wp-admin içinde | WordPress çekirdek dosyalarını aynı sürümün temiz kopyasıyla yeniden yükleyin (wp-content ve wp-config.php hariç) |
Bellek hatası alıyorsanız ayrıntılar için Allowed memory size exhausted hatası rehberimize bakın. Yönetim paneline giremediğiniz için şifre sorununuz varsa SQL ile WordPress admin şifresi sıfırlama yazısı işinize yarar.
WP_DISABLE_FATAL_ERROR_HANDLER ne işe yarar?
WordPress belgelerine göre WP_DISABLE_FATAL_ERROR_HANDLER sabiti, 5.2 ile gelen ölümcül hata işleyicisini ve Kurtarma Modunu tamamen kapatır. Belgeler bunu özellikle geliştirme ortamında hataları doğrudan ekranda görmek için önerir:
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 ve sonrasıSık Sorulan Sorular
"Sitenizde ciddi bir sorun çıktı" (kritik hata) mesajı verilerimin silindiği anlamına mı gelir?
Hayır. Bu mesaj PHP kodunun çalışırken durduğunu gösterir; yazılarınız, sayfalarınız ve veritabanınız genellikle yerindedir. Hatalı eklenti veya tema devre dışı bırakıldığında site normal açılır.
Kurtarma Modu e-postası gelmedi, ne yapmalıyım?
Spam klasörüne bakın ve Ayarlar > Genel ekranındaki yönetici e-postasının doğru olduğundan emin olun. E-posta gelmiyorsa debug.log ile sorunlu eklentiyi bulup FTP veya Dosya Yöneticisi ile klasörünü yeniden adlandırabilirsiniz.
Hata yalnızca yönetim panelinde çıkıyor, site açılıyor. Neden?
Bazı eklentiler yalnızca yönetim ekranlarında çalışan kod yükler. Ayrıca WordPress yönetim alanında daha yüksek bir bellek sınırı (WP_MAX_MEMORY_LIMIT) kullanır; buna rağmen ağır bir işlem sınırı aşabilir. debug.log kaydı hangisi olduğunu gösterir.
Eklentileri tekrar açınca hata geri geliyor. Ne yapmalıyım?
Eklentileri tek tek etkinleştirin ve her seferinde siteyi kontrol edin. Hatayı geri getiren eklentiyi güncelleyin; güncelleme yoksa geliştiricisine debug.log satırıyla birlikte bildirin veya alternatif bir eklentiye geçin. Güvenlik eklentisi hataya neden oluyorsa kalıcı olarak kapalı bırakmak yerine güncelleyin ya da muadiliyle değiştirin.
Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: 500 Internal Server Error çözümü · PHP memory limit hatası · Veritabanı bağlantısı kurulurken hata · wp-config.php sabitleri rehberi · WordPress dosya izinleri · PHP nedir?