WordPress kritik hata ve beyaz ekran nasıl çözülür?
“Sitenizde ciddi bir sorun çıktı.” veya “Sitenizde kritik bir hata oluştu” mesajı, WordPress çalışırken işlemin tamamlanamadığını belirtir. Bazı durumlarda aynı sorun yalnız beyaz bir ekran olarak görünür. Tek başına bu görüntü, hatanın eklentiden mi, temadan mı, PHP uyumsuzluğundan mı kaynaklandığını söylemez.
Bu rehberde önce hatayı ilgili kayıtla eşleştirecek, ardından WordPress yönetim paneli açılmıyorsa cPanel'den sorunlu eklentiyi devre dışı bırakıp siteyi yeniden kontrol edeceksiniz. Ekran görüntüleri, ayrı bir demo WordPress kurulumundaki kontrollü eklenti hatasına aittir. Kendi sitenizde aynı hatayı oluşturmanız gerekmez.
Başlamak için DCHost müşteri portalından cPanel'e giriş yapın. cPanel ve WordPress yönetimi farklı panellerdir; WordPress hata verirken cPanel üzerinden site dosyalarına erişebilirsiniz.
1. Hangi ekranın hata verdiğini belirleyin
Önce tam sayfa adresini, hata saatini ve son yapılan değişikliği not edin. Bir eklenti güncellemesi, tema düzenlemesi veya PHP sürümü değişikliği teşhis için başlangıç noktası olabilir.
- Siteyi oturum açılmamış bir tarayıcı penceresinde açın.
- Daha önce çalışan bir iç sayfayı kontrol edin.
- Aynı WordPress kurulumunun
/wp-admin/adresini açın. WordPress alt klasördeyse bu klasör adresin içinde kalmalıdır. - Hatanın hangi adreslerde göründüğünü karşılaştırın. Yalnız giriş sayfasının açılması, yönetim panelinin de çalıştığı anlamına gelmez.
Site içeriği yerine görünen mesajı okuyun ve sorunun başladığı saati not edin.


1. adım: Mesajı kaydedin
- Mesajı kaydedin
Sitenizde ciddi bir sorun çıktı. mesajı WordPress’in sayfayı normal şekilde tamamlayamadığını gösterir. Nedenini belirlemek için aynı zamana ait hata kaydını inceleyin.
Bu kontrollü demo hatasında ziyaretçi isteği 500 yanıtı verdi. Yanıt kodu görselde gösterilmez. Bu mesaj tek başına hangi eklentinin, temanın veya PHP ayarının sorumlu olduğunu söylemez.
Ziyaretçi ekranından ayrı olarak WordPress yönetim adresini açın.


1. adım: Yönetim erişimini ayrı değerlendirin
- Yönetim erişimini ayrı değerlendirin
Bu sitede ciddi bir sorun çıktı. mesajı yönetimin de açılmadığını gösterir. Gelen kutunuzda geçerli bir WordPress kurtarma e-postası varsa onun yönergelerini izleyin; yoksa cPanel üzerinden hata kaydına ilerleyin.
Bu kontrollü demoda yönetim isteği de 500 yanıtı verdi; kurtarma e-postası gönderilmedi. Ekrandaki gelen kutusu yönlendirmesi, bir e-postanın gönderildiğini veya teslim edildiğini kanıtlamaz.
Bu denemede oturum açılmamış tarayıcıdan açılan aynı ana sayfa HTTP 500 yanıtı verdi. Türkçe WordPress ekranında “Sitenizde ciddi bir sorun çıktı.” mesajı ve “WordPress sorunlarını gidermek ile ilgili ayrıntılı bilgi alın.” bağlantısı göründü.
Mevcut yönetici oturumuyla açılan /wp-admin/ adresi de HTTP 500 döndü. Bu ekrandaki mesaj şöyleydi:
Bu sitede ciddi bir sorun çıktı. Lütfen yönergeler için site yöneticisinin gelen kutusuna bakın. Sorun sürerse, lütfen destek forumlarını deneyin.
Örnekte kritik hata ekranı doğrulandı; beyaz ekran oluşmadı. Gelen kutusu yönlendirmesi, e-postanın teslim edildiğini tek başına göstermez; aşağıda kurtarma e-postasına ihtiyaç duymadan ilerleyeceğiz.
| Gördüğünüz durum | İzlenecek yol |
|---|---|
| “Sitenizde ciddi bir sorun çıktı.” / “Sitenizde kritik bir hata oluştu” / “There has been a critical error on this website” | Bu rehberdeki hata kaydı ve eklenti kontrolü. |
| Tamamen beyaz sayfa | Aynı saate ait PHP hata kaydını ve gerçek yanıt kodunu kontrol edin. Beyaz ekran tek başına bellek sorunu demek değildir. |
| “Error establishing a database connection” | WordPress veritabanı bağlantı hatası. |
| Genel “500 Internal Server Error” | cPanel 500 rehberindeki PHP ve .htaccess ayrımı. |
| Ana sayfa açık, yazı veya sayfalar 404 veriyor | WordPress 404 ve kalıcı bağlantı kontrolü. |
Tarayıcınızın F12 → Network bölümünden ilgili sayfa isteğinin gerçek yanıt kodunu görebilirsiniz. Görünen mesajla yanıt kodunu ayrı değerlendirin. Ödeme veya sipariş gibi bir işlemi hata verdiği için tekrar tekrar göndermeyin.
2. Değişiklikten önce geri dönüş yolunu hazırlayın
cPanel'de Domains → Domains → Document Root alanından ilgili sitenin yayın klasörünü bulun. Files → File Manager ile o klasöre girin. wp-admin, wp-content ve wp-includes klasörleri doğru WordPress kurulumunu ayırt etmenize yardımcı olur.
- Dosya ve veritabanı yedeğinizin tarihini kontrol edin. Hata başlamadan önce alınmış çalışan bir kopya ile mevcut hatalı durumun kopyasını ayrı saklayın.
- Yeniden adlandıracağınız eklenti klasörünün tam adını ve bulunduğu yolu not edin. Günlükte adı geçen klasörle eşleştirin.
- Dosya düzenleyecekseniz önce Download ile indirin; mevcut izin değerini de kaydedin.
- Yedekleri bilgisayarınızda veya bütün sitelerin yayın klasörleri dışında, özel bir konumda tutun. Site klasörüne parola içeren
.bak,.txtveya ZIP kopyaları bırakmayın.
cPanel File Manager içinde sitenizin kurulu olduğu WordPress klasörünü açın.


1. adım: Doğru wp-config.php dosyasını seçin
- Doğru wp-config.php dosyasını seçin
wp-admin ve wp-content klasörlerinin yanında bulunan wp-config.php satırını seçin. Birden fazla WordPress kurulumu varsa sorun yaşanan sitenin klasöründe olduğunuzu kontrol edin.
- Download ile dosyayı bilgisayarınıza indirin
Üstteki Download düğmesine basın. İndirme tamamlandıktan sonra dosyanın bilgisayarınızda bulunduğunu kontrol edin; düzenlemeye başlamadan önce bu kopyayı saklayın.
Bu işlem yalnızca wp-config.php dosyasını yedekler; tam site veya veritabanı yedeği değildir. İndirilen dosya parola ve gizli anahtarlar içerir. Güvenli bir yerde saklayın, herkese açık bir klasöre yüklemeyin.
Aynı anda PHP sürümünü, temayı ve bütün eklentileri değiştirmeyin. Tek değişikliğin sonucunu görmek, neyin işe yaradığını anlamanızı sağlar. Dosya işlemleri için cPanel Dosya Yöneticisi, yedeğin kullanılabilirliği için yedek doğrulama rehberine bakabilirsiniz.
3. WordPress kurtarma e-postası geldiyse
WordPress, bazı eklenti veya tema kaynaklı ciddi hatalarda site yöneticisinin e-posta adresine hata bilgisi ve özel bir kurtarma bağlantısı gönderebilir. Bu adres, her zaman DCHost müşteri portalında kullandığınız adresle aynı değildir.
- WordPress'in yönetici e-posta kutusunu ve gereksiz/spam klasörünü kontrol edin. Mesajdaki site adresinin sizin siteniz olduğundan emin olun.
- E-postadaki kurtarma modu bağlantısını açın ve kendi WordPress yönetici hesabınızla giriş yapın. Bağlantı parola yerine geçmez.
- Yönetim ekranındaki bildirimin işaret ettiği eklenti veya temayı okuyun.
- Eklenti sorunuysa Eklentiler → Yüklü eklentiler (Plugins → Installed Plugins) bölümünden yalnız ilgili eklentiyi Etkisizleştir (Deactivate) ile kapatın. Tema veya özel kod sorunuysa ilgili bölümle ilerleyin.
- Sorunu giderdikten sonra Kurtarma modundan çık (Exit Recovery Mode) seçeneğini kullanın ve normal ziyaretçi kontrolünü yapın.
Kurtarma modunda bir bileşenin duraklatılması yalnız o kurtarma oturumu için geçerlidir. Yönetim ekranına girebilmeniz, ziyaretçilerin gördüğü sitenin düzeldiğini kanıtlamaz. Düzeltme veya kalıcı olarak devre dışı bırakma işleminden sonra siteyi normal oturumda kontrol edin.
Kurtarma e-postası gelmiyorsa
Her kritik hata kurtarma e-postası üretmez. Hatanın oluştuğu aşama, WordPress yapılandırması, yakın zamanda gönderilmiş bildirimler ve e-posta teslimi sonucu etkileyebilir. Ekranda e-posta kutusunu kontrol etmenizin söylenmesi, mesajın teslim edildiğini kanıtlamaz.
E-postayı beklerken siteyi tekrar tekrar hataya düşürmeyin. cPanel erişiminiz varsa aşağıdaki günlük ve dosya adımlarıyla ilerleyebilirsiniz. Kurtarma bağlantısını destek mesajına, ekran görüntüsüne veya herkese açık bir yere koymayın; özel erişim bilgisi içerir.
Aşağıdaki görselli adımlar, kurtarma e-postası gerektirmeyen cPanel yöntemini gösterir.
4. Hata kaydından ilgili eklentiyi veya dosyayı bulun
cPanel → Metrics → Errors bölümüne ve hizmetinizin PHP hata günlüğüne bakın. Errors bütün uygulama günlüklerini bir araya getirmez. Alan adına ait etkin PHP günlüğü ayrı bir dosyada olabilir; konumu görünmüyorsa destek ekibinden öğrenin. Ayrıntılı yol tarifi 500 rehberinin günlük bölümündedir.
WordPress için ayrıca bir günlük tanımlandıysa wp-config.php içindeki WP_DEBUG_LOG değeri hedef dosya yolunu gösterir. Aşağıdaki ekranda bu tanımları görebilirsiniz. Mevcut günlük yeterliyse yeni ayar eklemeyin; ek kayıt gerektiğinde özel günlük adımlarını izleyin.
wp-config.php içinde hata kaydını açarken ayrıntıların ziyaretçilere gösterilmesini kapalı tutun.


1. adım: Kaydı açın, ekranda hata göstermeyi kapatın
- Kaydı açın, ekranda hata göstermeyi kapatın
WP_DEBUG true olarak, WP_DEBUG_DISPLAY ise false olarak ayarlanmış. Böylece WordPress hata ayıklama açılır; ayrıntıların sayfada ziyaretçiye gösterilmesi istenmez.
- Kayıt dosyasını site kökünün dışında tutun
WP_DEBUG_LOG için public_html ve diğer web köklerinin dışında, hesabınızın yazabildiği bir dosyanın tam yolu kullanılır. Bu demoda özel klasör ayrıca doğrulandı. Ekrandaki yol güvenlik için gizlenmiştir.
Bu geçici teşhis ayarıdır. Mevcut sabitleri düzenleyin; aynı sabiti ikinci kez eklemeyin. İnceleme sonunda eski ayarları geri yükleyin. Gizlenen yol bu demo hesaba aittir; kendi hesabınızdaki doğrulanmış özel yolu kullanın.
File Manager → View ile günlüğü açın. En alttaki kaydın saatini, az önce denediğiniz adresle eşleştirin. Günlüklerin saat dilimi bilgisayarınızdan farklı olabilir.
Özel hata kaydını açın ve sorunla aynı zamana ait kaydı okuyun.


1. adım: Fatal error satırını bulun
- Fatal error satırını bulun
PHP Fatal error, işlemi durduran önemli bir PHP hatasını belirtir. Ekrandaki kayıt 20:10:05 UTC saatindedir; hata saatiyle logun saat dilimini birlikte değerlendirin.
- İlgili eklenti klasörünü not edin
Alttaki thrown in satırında wp-content/plugins/dchost-critical-error-demo yolu ve on line 16 bilgisi görünüyor. Bu demoda incelenecek klasör dchost-critical-error-demo; tüm eklentileri değiştirmek yerine önce bu doğrulanmış kaynağa odaklanın.
Bu kayıt kontrollü demo eklentisine aittir; kendi sitenizde kendi güncel kaydınızı esas alın. Dosya yolunda bir eklentinin görünmesi her durumda tek başına kök nedeni kanıtlamaz. Bu demoda hata kaynağı ayrıca doğrulandı.
Bu örnekte wp-config.php dosyası önce indirilerek yedeklendi. WP_DEBUG açık, WP_DEBUG_DISPLAY kapalı olacak şekilde, WP_DEBUG_LOG için bütün yayın klasörlerinin dışında özel bir dosya yolu tanımlandı. Oluşan günlük cPanel'den indirilip View ile incelendi; yalnız ayarın kaydedilmesine bakılarak sonuç çıkarılmadı.
Günlükte 15 Ekim 2026, 20:10:05 UTC zamanında aşağıdaki hata kaydedildi. Hesaba özel yol gizlenmiştir; eklenti klasörü ve satır numarası korunmuştur:
PHP Fatal error: Uncaught Error: DCHost demo: kontrollu eklenti hatasi. in [gizli yol]/wp-content/plugins/dchost-critical-error-demo/dchost-critical-error-demo.php:16
Kayıt, hatanın dchost-critical-error-demo klasöründeki dosyanın 16. satırından çıktığını gösteriyor. Bu eklenti yalnız rehber için hazırlanmış kontrollü örnektir; sitenizde aynı adı aramayın. Kendi günlüğünüzde gösterilen bileşeni esas alın.
| Kayıttaki bilgi | Ne yapmalısınız? |
|---|---|
wp-content/plugins/eklenti-adi/ | Bu klasöre ait eklentiyi belirleyin. Yalnız o eklentiyle başlayın. |
wp-content/themes/tema-adi/ | Etkin tema/alt tema ve son değişikliği karşılaştırın. Tema kontrolüne bakın. |
Uncaught Error / Uncaught TypeError | Mesajın devamını, dosyayı ve çağrı sırasını inceleyin. Sadece “Fatal error” ifadesi nedeni açıklamaz. |
Call to undefined function | İşlevin yazımı, ilgili bileşenin yüklenmesi, PHP sürümü veya gereken uzantı incelenir. |
Allowed memory size ... exhausted | Bellek kullanımı ve etkin PHP sınırı incelenir. |
Parse error / syntax error | Son düzenlenen dosyada yazım hatası veya desteklenmeyen PHP sözdizimi olabilir. |
Çağrı yığınında wp-includes görünmesi, WordPress çekirdek dosyalarının bozuk olduğunu tek başına göstermez. Asıl hata mesajına ve onu başlatan eklenti/tema koduna bakın. Her Warning veya Notice kritik hata değildir; eski kaydı yeni hatayla karıştırmayın.
5. Yönetim paneli açılmıyorsa sorunlu eklentiyi cPanel'den kapatın
Günlükte veya kurtarma e-postasında belirli bir eklenti gösteriliyorsa bütün eklentileri kapatmak yerine önce o klasörü hedefleyin.
- File Manager içinde doğru WordPress kurulumunun
wp-content → pluginsklasörüne gidin. - Hata kaydındaki eklenti klasörünü bulun. Klasörün adı, WordPress'te gördüğünüz eklenti başlığından farklı olabilir.
- Klasörü seçip Rename düğmesine basın.
- Mevcut adın sonuna
.disabledekleyin. Örneğinornek-eklenti→ornek-eklenti.disabled. Yalnız klasör adını değiştirin; klasörü silmeyin veya başka sitenin klasörüne taşımayın. - Rename File ile onaylayın. Eklentinin önceki dosya yolu artık bulunamayacağı için WordPress bu yoldan yükleyemez.
File Manager içinde ilgili WordPress kurulumunun wp-content/plugins klasörünü açın.


1. adım: Hata kaydındaki klasörü seçin
- Hata kaydındaki klasörü seçin
Bu örnekte seçilen klasör dchost-critical-error-demo. Klasör adını hata kaydıyla karşılaştırın; wp-content veya plugins klasörünün tamamını seçmeyin.
- Rename düğmesini açın
Üst araç çubuğundaki Rename düğmesine basın. Sonraki ekranda yalnızca seçtiğiniz eklentinin klasör adını değiştireceksiniz.
Burada yalnızca kontrollü hataya neden olduğu doğrulanan demo eklentisi seçildi. Diğer eklenti ve WordPress dosyaları değiştirilmedi. Kendi sitenizde logda belirlediğiniz klasör adını esas alın.
Rename penceresinde klasör adının sonuna .disabled ekleyin.


1. adım: Yeni klasör adını yazın
- Yeni klasör adını yazın
Bu örnekte dchost-critical-error-demo adı dchost-critical-error-demo.disabled olarak değiştiriliyor. Üstteki Old file name alanının doğru eklentiyi gösterdiğini kontrol edin.
- Rename File ile işlemi uygulayın
Rename File düğmesine basın. Önce aynı WordPress kurulumunun Eklentiler (wp-admin/plugins.php) ekranını açın ve ilgili eklentinin pasif olduğunu doğrulayın. Ardından ziyaretçi sayfasını kontrol edin.
Klasörün adını değiştirmek WordPress’in eklentiyi eski konumunda yüklemesini engeller; eklentinin hatalı kodunu düzeltmez ve dosyaları silmez. Önceki klasör adını not edin.
Ardından aynı kurulumun /wp-admin/plugins.php adresini, yani Eklentiler ekranını açın. WordPress, eski dosya yolunda bulunmayan etkin eklentiyi denetleyip devre dışı bırakabilir. “Eklenti dosyası mevcut değil” bildirimi bu ad değişikliğinin sonucu olabilir; tek başına yeni bir arıza değildir.
Klasörü yeniden adlandırdıktan sonra WordPress yönetiminde Eklentiler sayfasını açın.


1. adım: Eski eklenti yolu için bildirimi okuyun
- Eski eklenti yolu için bildirimi okuyun
Eklenti dosyası bulunamadı. bildirimi, WordPress’in eklentiyi eski klasör adından yükleyemediğini gösterir. Bu demoda bildirimin nedeni yaptığımız klasör adı değişikliğidir.
- Etkisiz eklenti durumunu kontrol edin
Bu ekranda Etkisiz (3) yazıyor; demo eklentisi dahil üç eklenti pasif. Sorunlu eklentinin Etkinleştir bağlantısına basmayın. Ziyaretçi sayfalarının da açıldığını ayrıca kontrol edin.
Bu ilk kurtarma aşamasıdır. Uyarı eklentinin eski yoluna aittir; dosyalar silinmedi. Klasörün yeniden adlandırılması eklenti kodunu düzeltmez. Sorun giderilene kadar ilgili eklentiyi yeniden etkinleştirmeyin.
Gerçek örnekte yalnız dchost-critical-error-demo klasörü, cPanel'in yeniden adlandırma penceresinden dchost-critical-error-demo.disabled yapıldı. Ardından /wp-admin/plugins.php açıldı; ekran HTTP 200 döndü ve ilgili eklentinin “bir hata nedeniyle etkisizleştirildi” bildirimiyle birlikte “Eklenti dosyası bulunamadı.” açıklaması görüldü. Listedeki üç eklenti de etkin değildi.
Bu durum doğrulandıktan sonra klasörün özgün dchost-critical-error-demo adı geri verildi. Eklentiler ekranı yeniden HTTP 200 ile açıldı ve demo eklentisinin devre dışı kaldığı görüldü. Hatalı eklenti yeniden etkinleştirilmedi.
Klasörün eski adını hemen geri koymayın. WordPress'teki etkinlik kaydı henüz kaldırılmadıysa hatalı eklenti tekrar yüklenebilir. Önce Eklentiler ekranına erişin ve durumunu kontrol edin. Sonra düzeltme ve yeniden etkinleştirme adımlarıyla ilerleyin.
Site açıldıysa eklentinin devre dışı kalması hatayı ortadan kaldırmış olabilir; ancak eklentinin sağladığı form, ödeme, üyelik veya diğer işlevler de durmuş olabilir. Bu işlem hatalı kodun kalıcı düzeltmesi değildir.
Sorunlu eklenti belli değilse
Önce günlük ve son değişiklik bilgisiyle kapsamı daraltın. Gerekirse test kopyasında eklentileri tek tek devre dışı bırakın. Canlı sitede toplu test ödeme, üyelik, güvenlik ve önbellek gibi işlevleri etkiler.
Bütün normal eklentileri geçici olarak durdurmanız gerekiyorsa wp-content/plugins klasörünü plugins-disabled olarak yeniden adlandırabilirsiniz. Sonra /wp-admin/plugins.php ekranını açın, bulunamayan eklentilerin devre dışı bırakıldığını kontrol edin ve klasörün adını tekrar plugins yapın. Eklentileri topluca etkinleştirmeyin; bağımlılıkları ve işlevleri kontrol ederek tek tek ilerleyin.
Bu yöntem mu-plugins, object-cache.php veya advanced-cache.php gibi özel yüklenen bileşenleri kapsamaz. WordPress Multisite kurulumlarında ağ genelinde etkin eklentiler de ayrıca değerlendirilir. Bu dosyaları rastgele yeniden adlandırmayın; yapılandırmayı yöneten kişiyle inceleyin. Görselli örnekte toplu eklenti kapatma uygulanmadı.
6. Eklenti çakışmasını giderin; hatalı sürümü tekrar açmayın
Yönetim ekranı açılınca hatayı üreten eklentinin sürümünü, son güncellemesini ve WordPress/PHP gereksinimlerini kaydedin. Aynı eklenti tek başına sorunsuz, başka bir eklentiyle birlikte hatalı çalışabilir; ilk görünen dosya yolu her zaman tek neden değildir.
- Geliştiricinin düzeltmesini ve uyumluluk bilgisini kontrol edin. Yükleme için eklentinin resmî kaynağını kullanın.
- Güncelleme veya dosya değişikliğini önce test kopyasında deneyin. Eski sürüme dönüş, eklentinin veritabanı değişikliklerini otomatik olarak geri almaz. Sürüm düşürürken güvenlik düzeltmelerini geri almayın; bilinen güvenlik açığı bulunan veya artık desteklenmeyen bir sürümde kalmayın.
- Sorun giderildikten ve eklenti devre dışı durumu doğrulandıktan sonra klasörün doğru adını geri verin.
- Eklentiler ekranından yalnız bu eklentiyi etkinleştirin. Hata veren sayfayı ve eklentinin işlevini yeniden deneyin.
- Hata geri gelirse aynı eklentiyi kapatın; yeni kaydı, sürüm bilgileriyle geliştiriciye veya desteğe iletin.
Delete / Sil kullanmayın. Bazı eklentiler kaldırılırken kendi ayarlarını veya verilerini temizler. Geçici kapatma ile kaldırma farklı işlemlerdir.
7. Hata tema, PHP veya bellek kaynaklıysa
Günlük etkin tema ya da alt temanın dosyasını gösteriyorsa önce son düzenlemeyi inceleyin. functions.php dosyası yeni değiştirildiyse indirdiğiniz mevcut kopyayı saklayıp yalnız hatalı değişikliği bilinen çalışan hâline döndürün. Dosyanın tamamını boşaltmayın.
Kurtarma modu veya normal yönetim açıksa Görünüm → Temalar (Appearance → Themes) bölümünde, önceden kurulu ve mevcut WordPress sürümüyle uyumlu bir varsayılan temaya geçiş test edilebilir. Bunu önce test kopyasında yapın: canlı görünüm, menü konumları ve temaya bağlı işlevler değişebilir. Tema değiştirmeden önce etkin tema/alt tema adını not edin.
Yönetim açılmıyorsa etkin tema klasörünü rastgele yeniden adlandırmayın. Uygun yedek tema bulunmadığında site düzelmeyebilir; alt temanın bağlı olduğu ana temayı devreden çıkarmak da başka hata doğurabilir. Günlükte belirtilen son düzenlemeyi geri alın veya destekle güvenli geçiş planlayın.
PHP sürümü ve bellek sınırını nasıl ayırt edersiniz?
| Belirti | Kontrol | Uygun sonraki adım |
|---|---|---|
| Hata PHP sürümü değişikliğinin hemen ardından başladı. | Software → MultiPHP Manager altında yalnız ilgili alan adının sürümü; WordPress, tema ve eklentilerin desteklediği sürümler. | Uyumlu güncel sürümle test edin. Destek dışı PHP'ye kalıcı dönüşü çözüm saymayın. |
Allowed memory size ... exhausted kaydı var. | Hata veren işlem, PHP'nin o istekteki etkin memory_limit değeri ve son değişiklik. | Gereksiz bellek tüketimini bulun; hizmetin izin verdiği sınır ve uygulamanın ihtiyacını birlikte değerlendirin. |
| İşlev bulunamıyor veya beklenen türde olmayan değer kullanılıyor. | Tam hata, bileşen sürümü, yükleme sırası ve gerekiyorsa PHP uzantısı. | Mesaja göre ilgili bileşeni düzeltin; bütün uzantıları açmak veya belleği artırmak genel çözüm değildir. |
WP_MEMORY_LIMIT ve WP_MAX_MEMORY_LIMIT, WordPress'in belirli istekler için kullanmaya çalıştığı bellek değerlerini etkiler; hosting hesabına RAM eklemez ve sunucunun izin verdiği sınırı aşmayı garanti etmez. Rastgele 512M veya sınırsız değer yazmayın. Ayrıntılar PHP ve performans ayarları ile bellek hatası incelemesinde bulunur.
8. Gerekirse WordPress hata kaydını özel bir konumda alın
Önce hostingin mevcut PHP günlüğünü kullanın. WordPress'e özel ek teşhis gerekiyorsa bunu tercihen test kopyasında yapın. Canlı sitede kısa süreli kayıt gerekiyorsa özel dosya yolu ve geri dönüş adımlarını destek ekibiyle belirleyin.
wp-config.phpdosyasını değişiklikten önce indirin. Dosyayı bulma ve yedekleme adımlarına bakabilirsiniz.- Bütün alan adlarının yayın klasörleri dışında, yalnız hesabınıza ait yazılabilir bir günlük konumu belirleyin.
- File Manager içinde
wp-config.phpdosyasını seçip Edit düğmesine basın. Kodlama penceresi açılırsa buradaki Edit ile devam edin. MevcutWP_DEBUG,WP_DEBUG_LOGveWP_DEBUG_DISPLAYtanımlarını bulun. Aynı sabiti iki kez eklemeyin. Gerekli değişiklikler WordPress'in yüklenmesinden önce, “That's all, stop editing!” satırının üstünde olmalıdır. WP_DEBUGtrue,WP_DEBUG_DISPLAYfalse,WP_DEBUG_LOGise özel günlük dosyasının tam yolu olacak şekilde düzenlenir.truevefalsesözcüklerini tırnak içine almayın. Save Changes ile kaydedin ve başarılı kayıt bildirimini kontrol edin. Doğrulama ekranı veya hata görünüyorsa değişikliğin kaydedildiğini varsaymayın.- Sorunlu sayfayı bir kez açın; kaydı cPanel'den okuyun. Kayıt oluşmuyorsa dosya yolunu, yazma erişimini ve hizmetin etkin PHP günlük ayarını doğrulayın.
- İnceleme bitince eklediğiniz teşhis ayarlarını kaldırıp dosyayı önceki hâline döndürün. Günlüğü güvenli yerde saklayın veya gerekmiyorsa kaldırın.
WP_DEBUG_LOG=true, varsayılan olarak wp-content/debug.log dosyasına yazabilir. Dosyanın webden okunamadığını varsaymayın. Özel yol kullanmak da hostingin üst düzey PHP-FPM ayarlarını mutlaka geçersiz kılmaz. Siteye açık hata çıktısı, phpinfo() veya parola içeren test dosyası bırakmayın.
Bu ayarlar teşhis içindir; hatalı eklentiyi düzeltmez. WP_DEBUG=false yapmak da kritik hatanın nedenini ortadan kaldırmaz.
9. Siteyi ve WordPress yönetimini yeniden kontrol edin
| Kontrol | Beklenen sonuç |
|---|---|
| Başta hata veren aynı adres | Beklenen içerik açılıyor; kritik hata veya beyaz ekran görünmüyor. |
| Önceden çalışan iç sayfa ve yazı | Doğru içerik ve bağlantılar çalışıyor. |
| WordPress yönetimi | Normal oturumda yönetim, yazı/sayfa listeleri ve Eklentiler ekranı açılıyor. |
| Etkilenen eklentinin işlevi | Form, üyelik veya diğer hizmette oluşan etkiler biliniyor; gerekiyorsa düzeltmeden sonra ayrıca test edildi. |
| Hata kaydı | Aynı işlemin yeni saatli kaydında önceki fatal hata tekrarlamıyor. Eski satırın dosyada kalması normal. |
| Geçici değişiklikler | Özel hata kaydı ayarları geri alındı; yedekler web kökü dışında; mevcut izinler ve site ayarları korunuyor. |
Sorunlu eklenti devre dışı bırakıldıktan sonra siteyi ziyaretçi olarak kontrol edin.


1. adım: Beklenen içeriğin yüklendiğini doğrulayın
- Beklenen içeriğin yüklendiğini doğrulayın
Bu örnekte Hello world! yazısı yeniden görünüyor. Kendi ana sayfanızı, bir yazıyı ve bir sayfayı açın; yalnızca hata mesajının kaybolmasına değil, doğru içeriğin gelmesine de bakın.
Bu sayfa son kontrolde 200 yanıtı verdi; yanıt başlıkları görselde yer almaz. Ana sayfa, örnek yazı ve örnek sayfa ayrıca açıldı. Kendi sitenizde form, sepet veya üyelik gibi kullandığınız işlevleri de ayrı ayrı kontrol edin.
Başlangıç ekranını açın ve sitenizin mevcut içerik özetini kontrol edin.


1. adım: Yönetimde içerik özetinin açıldığını görün
- Yönetimde içerik özetinin açıldığını görün
Bir bakışta kutusunda 1 yazı yayımlanmış, 1 sayfa yayımlanmış ve 1 yorum görünüyor. Kendi sitenizin Yazılar ve Sayfalar listelerini de açarak yönetim erişimini kontrol edin.
Arama motorları engellendi bu demo sitenin önceden var olan tercihidir; kritik hatayı çözmek için önerilen bir ayar değildir. Yönetim erişimini ve ziyaretçi erişimini ayrı ayrı doğrulayın.
Son kontrolde ana sayfa, mevcut Sample Page ve tarihli Hello world! yazısı beklenen içerikle HTTP 200 döndü. Normal yönetici oturumunda yönetim ekranı, yazı listesi, sayfa listesi ve Eklentiler bölümü de HTTP 200 ile açıldı.
wp-config.php özgün hâline döndürüldükten sonra sunucudan tekrar indirildi. Dosyanın ilk yedekle birebir aynı olduğu ve mevcut 0644 izninin korunduğu doğrulandı. Böylece geçici hata ayıklama ayarları da kaldırılmış oldu.
Kurtarma doğrulandıktan sonra yalnız bu çalışma için oluşturulan demo eklentisi WordPress yönetiminden kaldırıldı. Başlangıçta bulunan diğer iki eklenti, önceki gibi devre dışı bırakılmış durumda korundu. Özel günlük güvenli bir çalışma klasörüne arşivlendi; yalnız deneme için oluşturulan uzak günlük klasörü temizlendi. Kendi sitenizde kullandığınız gerçek eklentiyi silmeniz bu kurtarma işleminin bir adımı değildir.
Görsellerdeki “Arama motorları engellendi” bildirimi, demo sitenin mevcut görünürlük ayarıdır. Sitenin noindex, nofollow ayarı hata giderme sırasında değiştirilmedi.
Kurtarma modu kullandıysanız çıkış yaptıktan sonra deneyin. Gizli pencere sunucu veya CDN önbelleğini temizlemez; ilgili önbelleği de kontrol edin. Bir eklentinin kapalı kalması gerekiyorsa bunun müşterilerinizin kullandığı işlevlere etkisini ayrıca değerlendirin.
Değişiklik işe yaramazsa nasıl geri dönersiniz?
Yalnız yaptığınız değişikliği geri alın; bütün siteyi veya veritabanını ilk adımda eski yedeğe döndürmeyin. Özellikle yeni sipariş ve kayıt alan sitelerde tam veritabanı geri dönüşü güncel verilerin kaybına yol açabilir.
- Eklenti klasörü yanlış hedeflendiyse önceki adını ve yolunu notlarınızla karşılaştırın. WordPress'in devre dışı bıraktığı eklentinin durumunu ayrıca kontrol edin.
- Hatalı eklentiyi yeniden etkinleştirmek hatayı geri getiriyorsa kapalı tutun; düzeltme veya uyumlu alternatif olmadan tekrar açmayın.
wp-config.phpveya başka bir dosya düzenlemesi yeni hata oluşturduysa indirdiğiniz kopyayı aynı konuma, önceki izinleriyle geri koyun.- Tema/PHP değişikliği yaptıysanız önceki değerleri kayıtlarınızdan kontrol edin. Mevcut içerikle uyumlu geri dönüş gerektiğinde destek isteyin.
Destek talebine ne eklemelisiniz?
DCHost müşteri portalından destek talebi açarken hizmeti, etkilenen tam adresi, hata saatini ve saat dilimini belirtin. Ana sayfa ile yönetim panelinin durumunu ayrı yazın. Son değişikliği, ilgili eklenti/tema ve PHP sürümünü, denediğiniz adımları ve aynı saate ait ilgili hata satırını ekleyin.
Hata satırını paylaşırken hesap adını, özel dosya yollarını, e-posta adreslerini ve anahtarları gizleyin. Parola, tam wp-config.php, veritabanı yedeği veya kurtarma bağlantısı göndermeyin.
Sık sorulan sorular
WordPress beyaz ekran sorunu her zaman bellek yetersizliği midir?
Hayır. Eklenti/tema hatası, PHP kodunun durması veya başka bir uygulama sorunu da beyaz sayfa oluşturabilir. Bellek müdahalesinden önce aynı isteğe ait Allowed memory size ... exhausted gibi somut kaydı arayın.
WordPress yönetim paneli açılmıyor; eklentiyi nasıl kapatırım?
cPanel Dosya Yöneticisi'nde doğru sitenin wp-content/plugins klasörünü açın. Günlüğün işaret ettiği eklenti klasörünün adını geçici olarak değiştirin, ardından aynı sitenin /wp-admin/plugins.php ekranını açıp eklenti durumunu kontrol edin. Ayrıntılı sıra yukarıdaki görselli bölümde yer alır.
Eklentiyi devre dışı bırakınca içeriklerim silinir mi?
Devre dışı bırakma, eklentiyi kaldırmakla aynı değildir. Klasör adını değiştirmek eklenti dosyalarını silmez; ancak o eklentinin ürettiği görünüm ve işlevler durabilir. Silme veya kaldırma işlemi bazı eklentilerde veri temizliği yapabildiğinden geçici teşhiste bu düğmeleri kullanmayın.
Kurtarma modu açıldı ama ziyaretçiler neden hâlâ hata görüyor?
Sorunlu bileşenin kurtarma modunda duraklatılması sizin oturumunuzla sınırlıdır. Sorun kalıcı olarak giderilmeli veya ilgili eklenti devre dışı bırakılmalı; ardından kurtarma modundan çıkılıp site normal ziyaretçi olarak kontrol edilmelidir.
WordPress'i yeniden kurmak gerekli mi?
Kritik hata mesajı tek başına yeniden kurulum gerekçesi değildir. Önce günlükteki nedeni bulun. Eklenti veya tema hatasında WordPress'i yeniden yüklemek aynı sorunlu kodu ve ayarı düzeltmeyebilir; mevcut dosya veya verilerin üzerine yazmak ek sorun oluşturabilir.
İlgili rehberler
- cPanel 500 Internal Server Error
- WordPress veritabanı bağlantı hatası
- WordPress 404 hatası
- cPanel Dosya Yöneticisi ve yedek işlemleri
- cPanel PHP ve performans ayarları
- Yedeğin kullanılabilir olduğunu doğrulama
Resmî kaynaklar
Kaynaklar 15 Ekim 2026 tarihinde kontrol edildi. Menü adları kullanılan sürüme ve arayüz diline göre değişebilir.