Web Sitenizde Kritik Bir Hata Oluştu Uyarısı Nasıl Çözülür

Bir eklentiyi güncellediniz, sayfayı yenilediniz ve ekranda tek bir cümle kaldı: "Web sitenizde kritik bir hata oluştu. Lütfen site yöneticinizin e-posta gelen kutusunu kontrol edin." Bazen ikinci cümle olmadan, sadece "Web sitenizde kritik bir hata oluştu" şeklinde de çıkar. Panik yaratan tarafı şudur: ne ön yüz açılır ne de /wp-admin. Sitenizin bir eklentisi veya teması PHP tarafında ölümcül bir hata (fatal error) üretmiş, WordPress de bu hatayı ziyaretçiye ham şekilde göstermek yerine bu kibar ekranla örtmüştür.

Bu ekranın en önemli ayrıntısı, çoğu Türkçe rehberde hiç geçmeyen bir cümlede saklı: "site yöneticinizin e-posta gelen kutusunu kontrol edin". WordPress bu hatayla birlikte yönetici e-postasına kurtarma modu (recovery mode) bağlantısı gönderir; o bağlantı, sorunlu eklenti devre dışıyken panele girmenizi sağlar ve size hatanın hangi dosyanın kaçıncı satırından geldiğini yazar. Yani FTP'ye girip klasör adı değiştirmeden önce denenecek çok daha hızlı bir yol vardır. Bu yazıda önce o yolu kullanacağız; e-posta gelmediyse wp-content/debug.log dosyasını açıp fatal error satırını okumayı, oradan da suçluyu bulup siteyi geri açmayı adım adım göreceğiz.

Bu Ekran Tam Olarak Ne Anlatıyor#

"Kritik bir hata oluştu" ekranı, WordPress 5.2 ile gelen ölümcül hata koruma mekanizmasının çıktısıdır. Öncesinde aynı durumda beyaz bir sayfa görürdünüz — meşhur beyaz ölüm ekranı. Yeni mekanizma iki şey yapar: hatayı ziyaretçiden gizler (PHP hata metni dosya yollarını ve kod yapısını dışarı sızdırdığı için bu bir güvenlik kazancıdır) ve yönetici e-postasına bir kurtarma bağlantısı yollar.

Hata kaynağına göre üç farklı görünüm vardır ve hangisini gördüğünüz teşhisi hızlandırır:

Dördüncü satır önemlidir: tamamen boş bir beyaz sayfa görüyorsanız hata muhtemelen WordPress yüklenmeden önce, bellek limiti tükendiğinde veya wp-config.php düzeyinde oluşmuştur. O senaryo için wordpress beyaz ekran hatası yazısındaki sıra daha uygundur.

En Hızlı Yol: Kurtarma Modu E-postası#

Kurtarma modu, bu hatayı çözmenin en hızlı yoludur ve çoğu kişi varlığından haberdar olmadığı için doğrudan FTP'ye atlar. WordPress ölümcül hatayı yakaladığı anda Ayarlar > Genel ekranındaki "Yönetici E-posta Adresi" alanına bir e-posta gönderir. E-postanın konusu genellikle "Sitenizde teknik bir sorun var" şeklindedir ve içinde şuna benzer bir bağlantı bulunur:

https://siteniz.com/wp-login.php?action=enter_recovery_mode&rm_token=...&rm_key=...

Bu bağlantıya tıkladığınızda:

1. Site kurtarma moduna girer — hatayı üreten eklenti veya tema sizin oturumunuz için duraklatılır.
2. Normal kullanıcı adı ve parolanızla /wp-admin'e girebilirsiniz.
3. Panelin üstünde "Bir veya daha fazla eklenti kaldırıldı" gibi bir uyarı şeridi belirir ve hangi eklentinin soruna yol açtığını adıyla söyler.
4. Eklentiler ekranında o eklenti "Duraklatıldı" olarak işaretlenir; oradan kalıcı olarak devre dışı bırakabilir veya silebilirsiniz.

Kritik ayrıntı: kurtarma modu yalnızca sizin tarayıcı oturumunuzu etkiler. Ziyaretçiler için site hâlâ hata veriyor olabilir; eklentiyi kalıcı olarak devre dışı bıraktığınızda site herkes için düzelir. İşiniz bittiğinde panelin üstündeki "Kurtarma modundan çık" düğmesine basın.

E-postanın içindeki bağlantı ayrıca hatanın teknik ayrıntısını da taşır. Genellikle şuna benzer:

Hata Türü: E_ERROR
Hata Satırı: 812
Hata Dosyası: /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/includes/class-loader.php
Hata Mesajı: Uncaught Error: Call to undefined function wc_get_product()

Bu dört satır teşhisi bitirir: hangi eklenti, hangi dosya, hangi satır, ne hatası. Yukarıdaki örnekte eklenti WooCommerce'in bir fonksiyonunu çağırıyor ama WooCommerce yüklü/aktif değil — yani sıra yanlış devre dışı bırakma veya eksik bağımlılık sorunu.

E-posta Gelmediyse Ne Yapmalı#

Kurtarma e-postası çok sık gelmez ve bunun sebepleri tahmin edilebilir. Elemeye şuradan başlayın:

• Yönetici e-postası yanlış veya erişilemez. Site kurulurken yazılan [email protected] adresi hiç oluşturulmamış olabilir. Bu durumda e-posta gönderilir ama hiçbir yere ulaşmaz.
• Sunucu mail gönderemiyor. Paylaşımlı hostingde PHP mail() fonksiyonu kapalı olabilir veya giden postalar engelleniyordur. Zaten SMTP eklentisi kullanıyorsanız, o eklenti de çökmüş olabileceği için e-posta hiç çıkmaz.
• E-posta spam klasörüne düştü. Önce oraya bakın; gönderen adresi genellikle [email protected] biçimindedir.
• Aynı hata için 24 saat içinde zaten gönderilmiş. WordPress aynı hatayı üreten aynı eklenti için gün içinde tekrar tekrar mail atmaz.

Mail teslimat sorunu yaşıyorsanız bunun kendisi ayrı bir konudur ve site düzeldikten sonra mutlaka çözülmelidir; sipariş ve şifre sıfırlama postaları da aynı kanaldan gider. Ama acil durumda beklemeyin — doğrudan bir sonraki bölüme geçin, orada hatayı kendiniz okuyacaksınız.

Hata Ayıklama Günlüğünü Açıp Fatal Error Satırını Okuma#

Bu adım, "hangi eklenti" sorusunu tahminden çıkarıp kesin cevaba dönüştürür. FTP veya cPanel Dosya Yöneticisi ile wp-config.php dosyasını açın ve /* That's all, stop editing! */ satırından önce şunları ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Dosyada zaten define( 'WP_DEBUG', false ); satırı varsa yenisini eklemeyin, o satırı true yapın — aynı sabit iki kez tanımlanırsa PHP uyarı üretir.

Bu dörtlünün mantığı şudur: WP_DEBUG hataları yakalar, WP_DEBUG_LOG bunları dosyaya yazar, WP_DEBUG_DISPLAY false ve display_errors 0 ise hata ziyaretçiye gösterilmez. Yani teşhis yaparken siteyi daha da kötü göstermezsiniz. Canlı sitede hata ayıklarken bu dörtlünün birlikte kullanılması standarttır; sadece WP_DEBUG açıp WP_DEBUG_DISPLAY kapatmayı unutursanız hata metni ziyaretçinin ekranına düşer.

Şimdi hata veren sayfayı bir kez yenileyin, sonra şu dosyayı açın:

/wp-content/debug.log

Dosyanın en altındaki kayıt en yeni olandır. Aradığınız satır PHP Fatal error ile başlar:

[11-Aug-2026 09:14:22 UTC] PHP Fatal error:  Uncaught Error: Call to undefined method
WPForms\Forms\Handler::init() in /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/src/Bootstrap.php:64
Stack trace:
#0 /home/kullanici/public_html/wp-includes/class-wp-hook.php(324): OrnekEklenti\Bootstrap->boot()
#1 /home/kullanici/public_html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#2 /home/kullanici/public_html/wp-settings.php(578): do_action('init')
  thrown in /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/src/Bootstrap.php on line 64

Bu çıktıyı doğru okumak için üç kural:

1. Yolun içindeki klasör adı suçluyu verir. wp-content/plugins/ornek-eklenti/ görüyorsanız sorumlu o eklentidir. wp-content/themes/tema-adi/ görüyorsanız temadır.
2. wp-includes veya wp-admin içindeki bir dosya adı sizi yanıltmasın. Çekirdek dosyalar yığın izinde (stack trace) hep görünür; ilk satırdaki thrown in yolu asıl kaynaktır.
3. Hata mesajının kendisi sebebi söyler. Call to undefined function eksik bağımlılık, Allowed memory size exhausted bellek limiti, Maximum execution time exceeded zaman aşımı, syntax error, unexpected ise elle düzenlenmiş bozuk bir dosya demektir.

Bellek limitiyle karşılaşıyorsanız çözüm eklenti silmek değildir; wp-config.php içine define( 'WP_MEMORY_LIMIT', '256M' ); eklemek ya da paketin PHP bellek sınırını yükseltmek gerekir.

Teşhis bittiğinde WP_DEBUG değerini tekrar false yapın ve debug.log dosyasını silin. Bu dosya sunucu yollarınızı ve zaman zaman veritabanı sorgularını içerir; tarayıcıdan erişilebilir bir konumda durmamalıdır.

Hata Mesajına Göre Ne Yapılacağı#

Günlükte bulduğunuz mesaj, doğrudan yapılacak işi belirler:

En sık karşılaştığım iki senaryo şunlardır. Birincisi, PHP sürümü yükseltildikten sonra eski bir eklentinin çökmesi — çıktıda genellikle TypeError veya Deprecated yığını olur. İkincisi, eklenti güncellemesinin yarım kalması: FTP kesildiği veya zaman aşımı olduğu için dosyaların bir kısmı yeni, bir kısmı eskidir ve Call to undefined method üretir. İkincisinin çözümü eklentiyi silip temiz kurmaktır; ayarlar veritabanında durduğu için genellikle kaybolmaz.

Panele Hiç Giremiyorsanız: FTP ile Eleme#

Kurtarma modu çalışmadı ve günlüğe de erişemiyorsanız klasik eleme yöntemine dönersiniz. Sıra önemlidir, çünkü yanlış sırada yapılırsa siteyi daha da bozabilirsiniz.

1. Tüm eklentileri topluca kapatın. FTP ile wp-content/plugins klasörünün adını plugins-eski yapın. WordPress eklenti bulamayınca hepsini pasif sayar. Site açıldıysa suçlu bir eklentidir.
2. Klasör adını geri alın. plugins adına geri döndürün — eklentiler hâlâ pasif kalır, ayarları da durur.
3. Tek tek açın. Panele girip eklentileri birer birer etkinleştirin ve her birinden sonra ön yüzü yenileyin. Hata hangi eklentiden sonra döndüyse suçlu odur.
4. Site hâlâ açılmıyorsa temaya geçin. wp-content/themes/aktif-tema klasörünün adını değiştirin. WordPress varsayılan temaya (twentytwentyfour gibi) düşer. Açıldıysa sorun temadadır.
5. Hiçbiri değilse çekirdeği yenileyin. WordPress'in aynı sürümünü indirip wp-admin ve wp-includes klasörlerini üzerine yazın. wp-content ve wp-config.php dosyasına dokunmayın.

Eklentiyi klasör adı değiştirerek tek tek kapatmak da mümkündür ama bu, veritabanındaki aktif eklenti listesini bozabildiği için toplu kapatma + panelden açma yöntemi daha güvenlidir. Eklentiler arası uyumsuzluğun nasıl ayıklandığına dair daha ayrıntılı bir yöntem wordpress eklenti çakışması yazısında anlatılıyor.

Veritabanına erişiminiz varsa eklentileri SQL ile de topluca kapatabilirsiniz:

UPDATE wp_options
SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';

Bu komutu çalıştırmadan önce wp_options tablosunun yedeğini alın; active_plugins değerini geri yazamazsanız hangi eklentilerin açık olduğunu hatırlamanız gerekir. Tablo öneki wp_ değilse komuttaki adı kendi önekinizle değiştirin.

WP-CLI ile Saniyeler İçinde Çözüm#

Sunucuda SSH erişiminiz varsa bütün bu işi tek komutla yapabilirsiniz. WP-CLI, panel açılmasa bile çalışır çünkü doğrudan PHP ve veritabanı üzerinden iş görür.

# Sorunlu eklentiyi bulmak için tümünü kapat
wp plugin deactivate --all

# Siteyi kontrol et, sonra tek tek aç
wp plugin activate eklenti-adi

# Tema kaynaklıysa varsayılana dön
wp theme activate twentytwentyfour

# Çekirdek dosyaları bozulmuşsa yenile
wp core verify-checksums
wp core download --force --skip-content

wp core verify-checksums özellikle değerlidir: çekirdek dosyalarınızın resmi sürümle birebir aynı olup olmadığını söyler. Fark çıkan dosya varsa ya elle düzenlenmiştir ya da zararlı yazılım bulaşmıştır; ikinci ihtimalde çekirdeği yenilemek yetmez, tüm parolaları değiştirip wp-content içindeki yükleme klasörlerini de taramanız gerekir. WP-CLI'yi hiç kullanmadıysanız wp-cli kullanımı yazısı temel komutları anlatıyor.

Aynı Hatanın Tekrarlamaması İçin#

Bu hatanın büyük kısmı, canlı sitede yapılan güncellemelerden çıkar. Tekrarını engellemenin yolu daha dikkatli tıklamak değil, süreci değiştirmektir:

• Deneme (staging) ortamı kullanın. Güncellemeleri önce kopya sitede yapıp sorun çıkmadığını gördükten sonra canlıya alın; cPanel'in WordPress Toolkit'i bu kopyayı tek tıkla üretir.
• Güncellemeden önce yedek alın. Özellikle veritabanı yedeği; dosya yedeği olmadan geri dönüş yarım kalır.
• Toplu güncelleme yapmayın. Aynı anda sekiz eklentiyi güncellerseniz hangisinin çöktüğünü ayıklamak on kat uzar. Üçer beşer ilerleyin.
• PHP sürümünü tek başına yükseltmeyin. Önce eklenti ve tema uyumluluğunu kontrol edin; PHP yükseltmesi bu hatanın en sık dışsal sebebidir.
• Yönetici e-postasını gerçek ve okuduğunuz bir adres yapın. Kurtarma modu ancak o zaman işe yarar. Bu tek ayar, bir dahaki sefere sizi FTP'ye inmekten kurtarır.
• Otomatik güncellemeleri kontrol altına alın. Gece yarısı kendiliğinden güncellenen bir eklenti sabaha siteyi kapatmış olabilir.

Sıkça Sorulan Sorular#

Web sitenizde kritik bir hata oluştu mesajı veri kaybı anlamına gelir mi#

Hayır, bu mesaj veri kaybını göstermez. Hata yalnızca PHP kodunun çalışırken durduğunu söyler; yazılarınız, sayfalarınız, ürünleriniz ve medya dosyalarınız veritabanında ve diskte olduğu gibi durur. Sorunlu eklenti veya tema devre dışı bırakıldığı anda içeriğin tamamı geri gelir. Veri kaybı yalnızca veritabanı bağlantısı tamamen koptuğunda ya da tablolar bozulduğunda gündeme gelir; o durumda ekranda veritabanı bağlantısı kurulurken hata oluştu mesajını görürsünüz.

Kurtarma modu e-postası gelmiyorsa siteye nasıl girerim#

E-posta gelmediğinde wp-config.php üzerinden hata ayıklama günlüğünü açıp wp-content/debug.log dosyasındaki fatal error satırını okuyun; suçlu eklentinin klasör adı o satırın içinde yazar. Ardından FTP veya cPanel Dosya Yöneticisi ile wp-content/plugins klasörünün adını geçici olarak değiştirerek tüm eklentileri kapatın; site açılınca panele girip tek tek etkinleştirerek suçluyu doğrulayın. SSH erişiminiz varsa wp plugin deactivate --all komutu aynı işi saniyeler içinde yapar. E-postanın gelmemesi çoğu zaman yönetici adresinin yanlış olmasından veya sunucunun mail gönderememesinden kaynaklanır.

Kurtarma modundan nasıl çıkılır#

Panelin üst kısmındaki uyarı şeridinde bulunan "Kurtarma modundan çık" düğmesine tıklamak yeterlidir. Bu düğmeye basmadan önce sorunlu eklentiyi kalıcı olarak devre dışı bıraktığınızdan veya sildiğinizden emin olun; aksi halde moddan çıktığınız anda site yine hata vermeye başlar. Kurtarma modu oturumu bir süre sonra kendiliğinden de sona erer. Modun aktif olduğu süre boyunca yalnızca sizin oturumunuz korumalıdır, ziyaretçiler hâlâ hata ekranını görüyor olabilir.

Hatanın eklentiden mi temadan mı geldiğini nasıl anlarım#

En kesin yöntem debug.log dosyasındaki dosya yoluna bakmaktır: yol wp-content/plugins/ ile devam ediyorsa eklenti, wp-content/themes/ ile devam ediyorsa temadır. Günlüğe ulaşamıyorsanız önce tüm eklentileri kapatın; site açılıyorsa sorun eklentidedir. Site hâlâ açılmıyorsa aktif tema klasörünün adını değiştirip WordPress'i varsayılan temaya düşürün. Bu iki testten sonra hâlâ hata alıyorsanız sorun çekirdek dosyalarında ya da PHP yapılandırmasındadır.

PHP sürümünü yükselttikten sonra bu hata çıktı ne yapmalıyım#

Öncelikle PHP sürümünü eski değerine geri alın; site anında açılacaktır. Ardından debug.log dosyasındaki hatayı okuyup hangi eklenti veya temanın yeni sürümle uyumsuz olduğunu tespit edin — genellikle TypeError veya kaldırılmış bir fonksiyona yapılan çağrı görürsünüz. Uyumsuz bileşeni güncelledikten veya değiştirdikten sonra PHP sürümünü tekrar yükseltin. cPanel kullanıyorsanız sürüm değişimi MultiPHP Yöneticisi ekranından yapılır ve etkisi anındadır, bu yüzden geri dönüş de aynı hızdadır.

Bakım modunda kalmış bir site de bu hatayı verir mi#

Hayır, farklı bir mesaj verir: "Kısa süreliğine bakım için hizmet dışıdır" gibi bir metin görürsünüz ve bunun sebebi kök dizinde kalmış .maintenance dosyasıdır. Güncelleme yarıda kesildiğinde WordPress bu dosyayı silemez ve site o ekranda takılı kalır. Çözüm dosyayı FTP ile silmektir. Ancak yarım kalan aynı güncelleme, eksik dosyalar yüzünden kritik hataya da yol açabilir; o durumda ilgili eklentiyi silip temiz kurmanız gerekir. Konunun ayrıntısı wordpress bakım modu yazısındadır.

Kritik hata çıktıktan sonra site kendiliğinden düzelebilir mi#

Nadiren, ve düzeldiyse sebebi kalıcı olarak çözülmüş demek değildir. Hata bellek limiti aşımı veya zaman aşımı gibi kaynağa bağlı bir sebepten çıktıysa, yük azaldığında site tekrar açılır ama trafik arttığında yine çöker. Aynı şekilde bir güncelleme arka planda tamamlandıysa eksik dosyalar yerine oturmuş olabilir. Aralıklı çıkan kritik hatalarda mutlaka debug.log dosyasını açık bırakıp birkaç saat bekleyin; kayıtta tekrar eden bir desen görürsünüz ve gerçek sebep oradadır.

Kapanış#

"Web sitenizde kritik bir hata oluştu" ekranı korkutucu görünse de altında her zaman tek bir somut sebep vardır ve o sebep neredeyse her zaman yazılıdır. Sıralama nettir: önce yönetici e-postasındaki kurtarma modu bağlantısını arayın, o gelmediyse WP_DEBUG_LOG ile wp-content/debug.log dosyasını üretip fatal error satırındaki dosya yolunu okuyun, ancak bunlar da olmazsa FTP ile eleme yapın. Bu sırayı takip ettiğinizde ortalama bir vakada çözüm on dakikayı geçmez; sıra atlandığında ise saatler sürer. Teşhis bittiğinde hata ayıklama ayarlarını kapatmayı ve debug.log dosyasını silmeyi unutmayın.

Bu tür kesintileri en aza indirmenin yolu, güncellemeleri canlı sitede denememek ve geri dönebileceğiniz bir noktayı hazır tutmaktır. Deneme ortamı, günlük yedek ve otomatik güncelleme kontrolünü kendi başınıza yönetmek istemiyorsanız WordPress bakım hizmetimiz bu döngüyü üstlenir; site kaynak sınırlarına takıldığı için çöküyorsa WordPress hosting paketleri ya da kendi kaynakları ayrılmış bir VDS sunucu daha uygun olur. Kritik anlarda geri dönüş noktanız yoksa yedekleme çözümümüz en azından kaybı bir güne indirir.