# 500 hatası ya da boş sayfa: arıza nereden geliyor

> 500 hatası bir teşhis değil, kibar bir başarısızlık itirafıdır. Sunucu isteği almış, programı başlatmış ve program geçerli bir yanıt üretmeden durmuştur. Tamamen boş bir sayfa da aynı mekanizmadan doğar, yalnızca farklı görüntülenir. Gerçek gerekçe bir yere yazılmıştır — güvenlik nedeniyle ekrana değil. O okunmadıkça denenen her şey tahmindir.

- Source canonique : [https://allaux.fr/tr/problemes/erreur-500-d-ou-vient-elle](https://allaux.fr/tr/problemes/erreur-500-d-ou-vient-elle)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Barındırma hesabının error_log dosyasını okuyun; site kökünde ya da panelin logs klasöründedir: son denemenize ait zaman damgalı satır dosya adını ve satır numarasını verir. Bunu PrestaShop’ta var/logs/ ile, WordPress’te wp-config.php içinde WP_DEBUG ve WP_DEBUG_LOG değerlerini true yaptıktan sonra wp-content/debug.log ile tamamlayın. Sitenin tamamı 500 dönüyorsa .htaccess dosyasını yeniden adlandırın; yanıt anında gelir.

## 500 kodunun zaten elediği şeyler

Aramaya başlamadan önce bu kodun neleri elediğini not etmek yararlıdır. Alan adı doğru çözümleniyordur, aksi hâlde hiçbir şey yanıt vermezdi. Web sunucusu çalışıyordur, çünkü hata sayfasını üreten odur. Ağ çalışıyordur. Barındırma hesabı askıya alınmamıştır.

Olası nedenler böylece sitenin çalıştırılmasıyla sınırlanır: bu siteye ait sunucu yapılandırması, uygulama kodu ya da bu belirli çalıştırmaya ayrılan kaynaklar. Bu iyi bir haberdir, çünkü bu üç aile basit ipuçlarıyla birbirinden ayrılır ve hiçbiri üçüncü bir taraftan yanıt beklemeyi gerektirmez.

Bu sayfa tüm platformlarda ortak olan mekanizmayı anlatır. Bir PrestaShop mağazasında kesin konumlar — var/logs, _PS_MODE_DEV_ sabiti, override/ klasörü — ve platforma özgü nedenler PrestaShop 500 hatası sayfasında ayrıntılı olarak anlatılıyor. WordPress’te aynı belirti WordPress kritik hatası biçiminde ortaya çıkar.

## Karşılaştığım nedenler, sıklık sırasına göre

- Yapılandırma: sunucunun okuduğu bir yapılandırma dosyasındaki tek bir geçersiz yönerge, CMS başlamadan önce bile tüm sayfalarda 500 döndürmeye yeter. Bir önbellek ya da güvenlik modülünün eklediği bir satır çoğu zaman bunun kaynağıdır.
- Uygulama kodu: kaldırılmış bir işleve yapılan çağrı, PHP sürümüyle uyumsuz bir modül, çekirdeğin önceki bir sürümü için yazılmış bir geçersiz kılma, artık var olmayan dosyalara atıf yapan derlenmiş bir önbellek ya da doğrudan bir tema dosyası değiştirilirken yapılmış basit bir söz dizimi hatası — eksik bir süslü parantez veya noktalı virgül yeterlidir.
- Kaynaklar: istenen sayfa için yetersiz ayrılmış bellek, dolan süreç sınırı, geçici dosyaların yazılmasını engelleyen dolu disk.
- İzinler: sunucunun reddettiği izinlere sahip bir dosya ya da dizin; özellikle bazı paylaşımlı barındırma yapılandırmalarında izinler fazla açık olduğunda.

## Gerçek mesajı bulmak

1. **Önce kapsamı not edin** — Tüm site mi, tek bir sayfa mı, yalnızca yönetim paneli mi, yoksa yalnızca bazı kayıtlar mı? Genel bir hata yapılandırmayı ya da sunucuyu; hedefli bir hata tek bir modülü ya da tek bir veriyi işaret eder.
2. **Sunucunun hata kaydını açın** — Tam mesaj dosya ve satır numarasıyla oradadır. Çoğu sağlayıcıda destek talebi açmadan panelden erişilebilir.
3. **Uygulama kaydına da bakın** — CMS, sunucununkinden ayrı kendi kaydını tutar. İkisi birbirini tamamlar: birincisi teknik hatayı, ikincisi işlevsel bağlamı verir.
4. **Bir deneme süresince hata ayıklama modunu açın** — Mesajı ekrana geri getirir. Hemen ardından kapatılır: açık bırakılırsa yolları ve tablo adlarını tüm ziyaretçilere gösterir.
5. **Şüpheli yapılandırma dosyasını bir kenara alın** — Hata tüm siteyi etkiliyorsa, sunucunun okuduğu yapılandırma dosyasını geçici olarak yeniden adlandırmak kaynağın o olup olmadığını bir saniyede söyler.
6. **Son müdahaleyle ilişkilendirin** — Güncelleme, modül kurulumu, tema dosyasında değişiklik: arıza neredeyse her zaman bir eylemin ardından gelir; başkası yapmış olsa bile, hatta bir önbellek etkisini geciktirdiyse günler öncesinde yapılmış olsa bile.

## 500, 502, 504 ve boş sayfayı karıştırmayın

> 500 sitenin kendisinden gelir: program başlamış ve sonra çökmüştür. 502 ya da 504, geçerli bir yanıt alamayan ya da çok uzun bekleyen bir aracıdan gelir. Boş sayfa çoğu zaman 500 ile aynı nedendir, sunucu yapılandırmasına göre farklı görüntülenir. Bunları karıştırmak yanlış kayıt dosyasında aramaya yol açar.

## Aynı arıza boş sayfa olarak göründüğünde

Sunucu yapılandırmasına göre aynı ölümcül hata, bir kurulumda 500 hata ekranı, diğerinde tamamen boş bir sayfa üretir. Boş sayfa bu yüzden yanıt yokluğu değildir: sunucu yanıt vermiş, program yolun ortasında durmuş ve mesaj bir kayda gitmiştir. Yukarıdaki yöntem olduğu gibi geçerlidir.

Tek bir ek hareket olası nedenleri ikiye böler: sayfa kaynağını görüntülemek. Pencere boşsa yürütme hiçbir şey yazmadan durmuştur — ölümcül bir PHP hatası ya da bellek sınırı, yani tam olarak 500 ile aynı zemin. HTML varsa ama görünür hiçbir şey yoksa program çalışmıştır ve bozuk olan görüntülemedir: yüklenmemiş bir stil dosyası, boş bir şablon, içeriği gizleyen bir betik. Bu ikinci durum sunucunun kaydında değil, tarayıcı konsolunda okunur.

Bir de ara durum vardır, bilgi bakımından en zengini: sayfa yarısına kadar görünüp cümlenin ortasında kesilir. Yürütme yazma sırasında kesilmiştir ve kesilmenin tam yeri, sorunlu olan sayfa bloğunu adlandırır.

## Sitenin yalnızca bir bölümünü etkileyen hata

Bilgi bakımından en zengin ve en çok harcanan durum budur. Tek bir sayfayla sınırlı 500 hatası, hatalı kodun yalnızca orada çalıştığı anlamına gelir. O sayfayı diğerlerinden ayıran şey bu yüzden doğrudan ipucudur: yalnızca o konuma bağlanmış bir modül, belirli bir kayıt, boş bir alan, hatalı biçimlenmiş bir varyant.

Yalnızca yönetim panelinde: neredeyse her zaman yönetim tarafında yüklenen bir modül ya da çok fazla kayıt listeleyen bir sayfa.

Yalnızca birkaç ürün sayfasında: o sayfaların birbirinden ayrıldığı noktayı değil ortak yönünü arayın.

Sipariş onayı anında: olası nedenler sipariş sürecine ve ödeme ya da kargo modüllerine iner.

Aralıklı olarak: bu bir kod kusuru değil kaynak sınırıdır.

## Doğru sayfadan devam edin

- **PrestaShop 500 hatası** — Hata ayıklama modundan geçersiz kılmalara, eksiksiz PrestaShop teşhisi. ([/prestashop/erreur-500](/prestashop/erreur-500))
- **WordPress'te kritik hata** — Aynı belirtinin WordPress ve WooCommerce tarafındaki kendine özgü nedenleri. ([/wordpress-woocommerce/erreur-critique](/wordpress-woocommerce/erreur-critique))
- **Hata kayıtlarını okumak** — Geliştirici olmadan bir hata izini nasıl okursunuz. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop))
- **500 hatası nedir** — Kodun tanımı ve diğer sunucu yanıtları arasındaki yeri. ([/glossaire/erreur-500](/glossaire/erreur-500))
- **PrestaShop'ta hata ayıklama modunu açmak** — Gizlenen mesajı ekrana geri getirmek için izlenecek kesin adımlar. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop))

## FAQ

### 500 hatası verilerimin kaybolduğu anlamına mı gelir?

Hayır. Kesintiye uğramış bir çalıştırmayı bildirir, bir yok oluşu değil. Veriler veritabanında kalır ve vakaların büyük çoğunluğunda kesinti nedeni giderilir giderilmez site normale döner.

### Hata mesajı neden doğrudan gösterilmiyor?

Çünkü canlıdaki bir site bir dosya yolunu, tablo adını ya da kimliği asla göstermeyecek şekilde yapılandırılır. Bu kullanılabilir bir bilgi olurdu. Ayrıntı bu yüzden yalnızca sizin erişebildiğiniz bir kayda gider.

### 500 hatası bir barındırma sorunu mudur?

Dar anlamda nadiren. Sunucu çalışıyordur, çünkü bu sayfayı o döndürür. Neden bir bellek sınırı, dolu disk ya da dayatılmış bir PHP sürüm değişikliğiyse barındırma işin içindedir — ama düzeltme çoğu zaman yine site tarafındadır.

### Modülleri tek tek devre dışı bırakabilir miyim?

Dosya erişimi ve önceden alınmış yedekle geçerli bir yöntemdir. Devre dışı bırakmanın veritabanından yapılması gerektiğinde riskli hâle gelir; orada özensiz bir düzenleme arızadan pahalıya mal olur.

### Kimse siteye dokunmadan hata çıktı, mümkün mü?

Evet: sağlayıcının kararıyla değişen PHP sürümü, dolan disk, dolan veritabanı kotası ya da bir modülün kullandığı anahtarın süresinin dolması. Bunların hiçbiri sizden bir işlem gerektirmez.

### Kurtulmak için her şeyi yeniden kurmalı mıyım?

Neredeyse hiçbir zaman. Yeniden kurulum özelleştirmeleri yok eder ve ilk yüklemede geri gelecek olan bir sürüm uyumsuzluğunu düzeltmez. Hata mesajını okumak birkaç dakika sürer ve dönüşü olmayan bir sıfırlamayı önler.