500 Internal Server Error Nedir, Nasıl Çözülür? HTTP 500 Rehberi

500 Internal Server Error nedir?

500 Internal Server Error, sunucunun isteği karşılarken beklenmedik bir durumla karşılaştığını ve daha uygun bir 5xx kodu bulamadığını bildiren genel bir HTTP hata kodudur. Sorun ziyaretçinin tarayıcısında değil, sunucu tarafındadır. Nedeni çoğu zaman bozuk bir yapılandırma, yetersiz bellek ya da çalışmayan bir uygulama kodudur.

Bu rehberi web sitesi ve e-ticaret sahipleri ile kendi VPS'ini ya da cPanel hesabını yöneten yazılımcılar için hazırladık. Amacımız, 500 hatasını gördüğünüzde panikle rastgele dosya silmek yerine sıralı bir teşhis yapmanızı sağlamak.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu nedenle anlatım MDN HTTP durum kodu belgesine, RFC 9110'a ve WordPress, Apache ile cPanel'in resmi dokümanlarına dayanıyor. Emin olmadığımız komutu ya da varsayılan değeri yazmadık.

500 hatasından kim sorumlu: ziyaretçi, site sahibi ya da sunucu yöneticisi?

Kısa cevap şu: sorumluluk sunucu tarafındadır. MDN belgesi de bu tür hataların sunucu sahipleri ya da yöneticileri tarafından incelenmesi gerektiğini söyler. Yine de her rolün yapabileceği bir şey var.

• Ziyaretçi: Sayfayı bir kez yenileyin, biraz bekleyin ve tekrar deneyin. Başka bir şey yapamazsınız, çünkü sorun sizin cihazınızda değil.
• Site sahibi: Hatadan hemen önce ne değiştirdiğinizi düşünün. Eklenti güncellemesi, tema değişikliği ya da yeni bir kod dosyası çoğu zaman suçludur.
• Sunucu yöneticisi: Hata günlüğünü okuyun, yapılandırmayı sınayın ve kaynak kullanımına bakın.

Paylaşımlı hostingde sunucu yöneticisi sizin hosting sağlayıcınızdır. Dolayısıyla bazı adımları yalnızca onlar yapabilir. VPS kullanıyorsanız bu rol sizindir.

500 hatası ekranda nasıl görünür?

Ekranda gördüğünüz metin sunucuya, tarayıcıya ve temaya göre değişir. Bazen sade bir "500 Internal Server Error" yazısı çıkar, bazen tarayıcı "bu sayfa çalışmıyor" gibi kendi mesajını gösterir. Bazı siteler ise özel tasarlanmış bir hata sayfası kullanır.

Bu yüzden metne değil, HTTP durum koduna bakmak gerekir. Tarayıcının geliştirici araçlarındaki Ağ (Network) sekmesi ya da komut satırında şu komut gerçek kodu gösterir:

curl -I https://example.com/

Çıktının ilk satırında örneğin HTTP/2 500 görürseniz sunucu gerçekten 500 döndürüyor demektir. Ayrıca bir sayfa hata mesajı gösterip 200 koduyla yanıt verebilir. Buna soft hata denir ve Google için ayrı bir sorundur; soft 404 rehberimizde ayrıntısını anlattık.

Siteniz açılıyor mu diye hızlı bakmak için site çöktü mü aracını da kullanabilirsiniz.

500 Internal Server Error'un en yaygın nedenleri nelerdir?

MDN belgesi olası nedenler arasında yanlış sunucu yapılandırmasını, bellek yetersizliğini, ele alınmayan istisnaları ve hatalı dosya izinlerini sayar. Pratikte bu liste birkaç somut senaryoya iner. Aşağıdaki tablo, her nedenin tipik belirtisini ve ilk bakacağınız yeri özetler.

Bu altı neden vakaların büyük bölümünü kapsar, ancak her durumda geçerli olduğunu iddia etmiyoruz. Hata günlüğü her zaman tablodan daha kesin cevap verir.

500 Internal Server Error teşhisine hangi sırayla başlamalısınız?

Rastgele denemek, bir sorunu iki soruna çevirir. Önce en az risk taşıyan ve en çok bilgi veren adımdan başlayın. Aşağıdaki sıra, riskten bağımsız olarak en mantıklı akışı verir.

1. Hatanın tüm sitede mi, yoksa tek sayfada mı olduğunu belirleyin.
2. Hata günlüğünü okuyun ve mesajı not edin.
3. Hatadan hemen önce yaptığınız değişikliği geri alın.
4. .htaccess dosyasını geçici olarak devre dışı bırakın.
5. PHP sürümünü ve eklentileri kontrol edin.
6. Bellek sınırına ve dosya izinlerine bakın.
7. Çözemezseniz günlük satırıyla birlikte hosting desteğine yazın.

Her adımdan sonra sayfayı yeniden deneyin. Böylece hangi adımın sorunu çözdüğünü bilirsiniz ve aynı hata tekrar ettiğinde vakit kazanırsınız.

500 hatası yalnızca belirli sayfalarda çıkıyorsa ne yaparsınız?

Hatanın kapsamı, nedeni daraltmanın en hızlı yoludur. Tüm sitede aynı anda çıkan bir hata genellikle ortak bir dosyaya, yani .htaccess, wp-config.php ya da PHP yapılandırmasına işaret eder. Tek bir sayfada çıkan hata ise o sayfanın kullandığı eklentiye, şablona ya da veritabanı sorgusuna işaret eder.

Kapsamı belirlemek için şu soruları sırayla sorun:

• Ana sayfa açılıyor mu, yoksa yalnızca belirli bir adres mi hata veriyor?
• Yönetim paneli açılıyor mu? Panel açılıyorsa sorun ön yüzdeki bir eklentide ya da temada olabilir.
• Hata yalnızca form gönderirken ya da ödeme adımında mı çıkıyor?
• Giriş yapmış ve yapmamış kullanıcılar aynı sonucu görüyor mu?

Örnek bir senaryo kuralım (örnek hesap değil, varsayımsal bir akış): ana sayfa açılıyor ama ürün sayfaları 500 veriyor. Bu durumda ürün şablonunu ya da ürün eklentisini şüpheli sayarsınız. Böylece tüm siteyi kurcalamak yerine yalnızca ilgili eklentiyi kapatırsınız.

Önbellek ve CDN 500 hatasını nasıl gizler ya da uzatır?

Hatayı çözdüğünüz hâlde ekranda hâlâ 500 görmeniz mümkündür. Önbellek eklentisi, sunucu önbelleği ya da bir CDN hata sayfasını saklamış olabilir. Bu nedenle çözümden sonra önbelleği temizlemeden sonuca güvenmeyin.

Tersi de geçerlidir: önbellek, aslında bozuk olan bir sitenin bazı sayfalarını sağlıklı gösterebilir. Yani siz sorunu fark etmezsiniz, ama önbelleği olmayan sayfalar hata verir. Bu yüzden testi hem tarayıcıda hem komut satırında yapın.

curl -I "https://example.com/sayfa/?test=1"

Adrese eklediğiniz rastgele parametre, çoğu önbellek yapılandırmasında isteğin yeniden üretilmesini sağlar, ancak bu davranış her kurulumda aynı değildir. Önbellek ve kalıcı bellek mantığı için OPcache yazımıza bakabilirsiniz.

Bir CDN kullanıyorsanız, hatanın CDN'den mi yoksa kaynak sunucudan mı geldiğini ayırmanız gerekir. Bu ayrım, hata sayfasının kim tarafından üretildiğine bağlıdır.

Hata günlüğünü (error log) nerede bulursunuz?

Hata günlüğü, 500 teşhisinin en değerli kaynağıdır. Apache belgesi de sunucu hatası aldığınızda önce httpd hata günlüğüne bakmanızı önerir. Günlük size neyin bozulduğunu, hangi dosyada ve hangi satırda söyler.

cPanel'de Metrikler bölümündeki Hatalar (Errors) ekranı, web sunucusunun en son 300 kaydına kadar olan hata girdisini ters kronolojik sırayla gösterir. Hosting sağlayıcınız bu özelliği kapatmış olabilir. Ayrıca bazı kurulumlarda site klasörünüzde PHP'nin yazdığı bir error_log dosyası oluşur; bunun varlığı yapılandırmaya bağlıdır.

VPS'te günlük konumu dağıtıma ve yapılandırmaya göre değişir. Doğru yolu bulmak için Apache'de ErrorLog, Nginx'te error_log yönergesine bakın. Günlüğün son satırlarını şöyle okursunuz:

tail -n 50 /path/to/error.log

Yukarıdaki yolu kendi yapılandırmanızdaki gerçek dosya yoluyla değiştirin. Hata tekrar edene kadar günlüğü canlı izlemek için tail -f kullanabilirsiniz.

Bozuk .htaccess dosyası 500 hatasına nasıl yol açar?

WordPress belgesine göre en olası neden bozuk bir .htaccess dosyasıdır. Apache belgesi de yanlış yazılmış bir yönergenin günlüğe "bad flag delimiters" ya da "not allowed here" gibi satırlar düştüğünü ve sunucunun 500 döndürdüğünü gösterir. Yani tek bir hatalı karakter tüm siteyi kapatabilir.

Teşhis için dosyayı silmeyin, yeniden adlandırın. FTP ya da cPanel Dosya Yöneticisi ile site kök klasöründe şunu yaparsınız:

1. .htaccess dosyasının adını .htaccess_old olarak değiştirin.
2. Siteyi yenileyin. Hata kaybolduysa suçlu bu dosyadır.
3. WordPress kullanıyorsanız Ayarlar, Kalıcı Bağlantılar ekranında kaydet düğmesine basın. WordPress yeni bir dosya üretir.

Standart bir WordPress dosyası şöyle görünür; kendi dosyanızda bunun dışında kalan satırlar yeni eklenmiş olabilir:

# 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

Dosyayı yeniden adlandırdığınızda güvenlik ya da yönlendirme kuralları da gider. Bu yüzden eski dosyayı saklayın ve hatalı satırı bulduktan sonra yalnızca o satırı düzeltin.

PHP sürümü ve eklenti uyumsuzluğu 500 hatası verir mi?

Evet. Eski bir eklenti ya da tema, yeni PHP sürümünde kaldırılmış bir özelliği çağırırsa PHP çalışamaz ve sunucu 500 döndürebilir. Tersi de olur: yeni kod, eski PHP sürümünde bulunmayan bir özelliğe ihtiyaç duyabilir. Hata günlüğünde genellikle ölümcül hata (fatal error) olarak geçer.

Güncelleme sonrası başlayan bir hatada şu sırayı izleyin:

• Günlükte hatayı veren dosyanın yolunu bulun. Yol wp-content/plugins altındaysa eklenti, themes altındaysa tema sorumludur.
• Hosting panelinden PHP sürümünü bir önceki sürüme alıp tekrar deneyin.
• Eklenti ya da tema geliştiricisinin desteklediği PHP sürümlerini kontrol edin.

cPanel'de sürüm değiştirme adımlarını ayrı bir kardeş yazıda anlatıyoruz, bu yüzden burada tekrar etmiyoruz. PHP performansı için OPcache ayarları rehberimize göz atabilirsiniz.

Üretim sitesinde sürüm değiştirmeden önce yedek alın. Sürümü geri çevirmek bir çözüm değil, geçici bir kaçıştır; asıl hedef uyumlu kodu kullanmaktır.

memory_limit yetersizse 500 hatası görür müsünüz?

Görebilirsiniz. PHP betiği izin verilen belleği aşarsa çalışmayı durdurur. Günlükte genellikle izin verilen bellek boyutunun tükendiğini söyleyen bir mesaj yer alır. MDN de bellek yetersizliğini 500'ün olası nedenleri arasında sayar.

WordPress belgesi, PHP bellek sınırını wp-config.php üzerinden artırmayı önerir. Aşağıdaki satır örnek bir değerdir; gerçek ihtiyacınız eklentilerinize göre değişir:

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

Bu satırı wp-config.php içinde "That's all, stop editing!" yorumundan önce eklersiniz. Hosting sağlayıcınız genel bir üst sınır koyuyorsa bu satır tek başına yetmeyebilir. Bu durumda php.ini ya da panel ayarlarından memory_limit değerini artırmanız gerekir.

Bellek sınırını sürekli yükseltmek de çözüm değildir. Bir eklenti sürekli şişiyorsa asıl sorun odur. Yavaşlık belirtileri için sunucu kaynaklı yavaşlık yazımıza bakabilirsiniz.

Dosya ve klasör izinleri 755 ve 644 olmalı mı?

Çoğu paylaşımlı hostingde klasörler için 755, dosyalar için 644 yaygın ve güvenli bir başlangıçtır. MDN, hatalı dosya izinlerini 500'ün nedenleri arasında sayar. Bazı hosting yapılandırmaları aşırı açık izinleri (örneğin 777) güvenlik gerekçesiyle reddeder ve bu da 500 olarak görünebilir.

Kendi VPS'inizde ya da SSH erişimi olan bir hesapta, yalnızca site klasörünün içinde şu komutları çalıştırırsınız:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Önce hangi klasörde olduğunuzu pwd ile doğrulayın. Yanlış klasörde çalıştırırsanız sistem dosyalarının izinlerini bozabilirsiniz. Ayrıca wp-config.php gibi hassas dosyalar için daha sıkı izinler gerekebilir; hosting sağlayıcınızın önerisine uyun.

Dosya sahibi de önemlidir. Dosyalar yanlış kullanıcıya aitse izin sayıları doğru olsa bile sunucu çalıştıramaz. Bu durumu hosting desteği daha hızlı çözer.

WordPress'te eklenti ve temayı nasıl kapatırsınız?

Yönetim paneline giremiyorsanız eklentileri dosya düzeyinde kapatırsınız. WordPress belgesi önce tüm eklentileri devre dışı bırakıp sorunun eklentiden gelip gelmediğine bakmayı önerir. Ardından temayı varsayılan bir temaya çevirmeyi önerir.

1. FTP ya da Dosya Yöneticisi ile wp-content klasörüne girin.
2. plugins klasörünün adını plugins_old yapın. Böylece tüm eklentiler devre dışı kalır.
3. Siteyi yenileyin. Hata gittiyse klasörü eski adına çevirin ve eklentileri tek tek açın.
4. Hata sürüyorsa themes altında etkin temanın klasörünü yeniden adlandırın. WordPress varsayılan temaya döner.

SSH erişiminiz ve WP-CLI varsa şu komut tüm eklentileri kapatır:

wp plugin deactivate --all

Hâlâ düzelmediyse WordPress belgesi, wp-admin ve wp-includes klasörlerini temiz bir kurulumdan yeniden yüklemeyi de önerir. wp-content ve wp-config.php dosyanıza dokunmayın.

WordPress'te hata ayıklamayı (WP_DEBUG) nasıl açarsınız?

Günlükte yeterli bilgi yoksa WordPress'in kendi hata kaydını açabilirsiniz. Resmi hata ayıklama belgesi şu üç sabiti tanıtır: WP_DEBUG ana anahtardır, WP_DEBUG_LOG hataları dosyaya yazar, WP_DEBUG_DISPLAY ise hataların sayfada görünüp görünmeyeceğini belirler.

Belgedeki önerilen kurulum, hataları kaydeder ama ziyaretçiye göstermez:

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

Bu satırları wp-config.php içinde "That's all, stop editing!" yorumundan önce eklersiniz. Kayıtlar wp-content klasöründeki debug.log dosyasına yazılır.

Belge bir uyarı da yapar: hata ayıklama araçları canlı sitede önerilmez, yerel ve staging ortamları için tasarlanmıştır. Canlıda zorunluysa işiniz biter bitmez kapatın, debug.log dosyasını da silin; çünkü dosya yol bilgisi gibi ayrıntılar içerebilir.

cPanel'de 500 Internal Server Error nasıl çözülür?

cPanel'de paylaşımlı hosting kullanıyorsanız elinizdeki araçlar sınırlıdır, ancak çoğu 500 vakası bu araçlarla çözülür. Sırayla ilerleyin ve her adımdan sonra siteyi test edin.

1. Metrikler bölümünde Hatalar ekranını açın ve son kayıtları okuyun.
2. Dosya Yöneticisi'nde gizli dosyaları göstererek .htaccess dosyasını bulun ve yeniden adlandırın.
3. PHP sürümünü ve eklentilerini kontrol edin.
4. Disk ve inode kullanımınızı kontrol edin. Dolu bir hesap yeni dosya yazamaz.
5. Eklentileri ya da temayı yukarıda anlattığımız gibi dosya düzeyinde kapatın.
6. Son yedeğe dönmeyi düşünün. Yedek stratejiniz yoksa web sitesi yedekleme stratejisi yazımıza bakın.

Bu adımlar sonuç vermezse günlükteki satırı kopyalayıp hosting desteğine gönderin. Destek ekibi sunucu tarafındaki sınırları ve yapılandırmayı sizden çok daha hızlı görür.

VPS'te Apache veya Nginx ile 500 hatası nasıl teşhis edilir?

VPS'te sunucunun tüm sorumluluğu sizdedir. Önce yapılandırmanın söz dizimini sınayın. Apache için apachectl -t, Nginx için nginx -t komutu yapılandırma dosyalarında hata olup olmadığını söyler. Komutlar yetki isteyebilir, bu durumda başına sudo koyarsınız.

Ardından kaynak durumuna bakın:

free -h
df -h
df -i

Birinci komut belleği, ikincisi disk alanını, üçüncüsü inode sayısını gösterir. Bellek bittiyse ya da disk dolduysa sunucu beklenmedik hatalar verebilir.

PHP-FPM kullanıyorsanız servisin çalışıp çalışmadığını systemctl status ile kontrol edin. Servis adı dağıtıma ve PHP sürümüne göre değişir, bu yüzden adı kendi sisteminizde doğrulayın. Nginx önünde bir uygulama sunucusu varsa upstream kaynaklı 502 ve 504 hatalarını 500'den ayırmanız gerekir.

Sunucuda yaptığınız her yapılandırma değişikliğinden önce dosyanın bir kopyasını alın. Değişiklikten sonra servisi yeniden yüklemeden önce söz dizimini mutlaka sınayın.

500 Internal Server Error kullanıcıyı ve Google'ı nasıl etkiler?

Ziyaretçi için etki açıktır: sayfa açılmaz, sepet tamamlanmaz, form gönderilmez. E-ticarette bu doğrudan kaybolan sipariş demektir. Kaç sipariş kaybedeceğinizi tahmin edemeyiz, ancak hata ne kadar uzun sürerse kayıp o kadar büyür.

Google tarafında resmi belge net konuşur. 5xx ve 429 hataları Google tarayıcılarının taramayı geçici olarak yavaşlatmasına yol açar. Google, 5xx durum koduyla aldığı içeriği yok sayar. Sunucu hatası veren URL sayısı arttıkça tarama hızı orantılı olarak düşer.

Kalıcı hata ise daha ciddidir. Belgeye göre indeksleme hattı, sürekli sunucu hatası veren URL'leri dizinden çıkarır. Belge bunun için kesin bir süre vermez. Sunucu yeniden 2xx dönmeye başlayınca Google tarama hızını kademeli olarak artırır.

Taramanın neden yavaşladığını anlamak için Googlebot tarama sıklığı yazımıza ve Search Console rehberimize bakabilirsiniz. Sunucu günlüklerini okumak için log analizi aracı işinize yarar.

Veritabanı sorunları 500 hatasına yol açar mı?

Bazen açar, ancak WordPress genellikle veritabanı bağlantı sorunu için ayrı bir mesaj gösterir. Yine de uygulamanıza ve yapılandırmanıza bağlı olarak aynı sorun 500 olarak da görünebilir. Bu nedenle günlükte veritabanıyla ilgili bir satır görürseniz bu yolu da inceleyin.

Kontrol edeceğiniz noktalar şunlardır:

• wp-config.php içindeki veritabanı adı, kullanıcı ve sunucu bilgileri doğru mu?
• Veritabanı kullanıcısının parolası yakın zamanda değişti mi?
• Hosting hesabınızın veritabanı kotası ya da disk alanı doldu mu?
• Veritabanı sunucusu çalışıyor mu? Paylaşımlı hostingde bunu yalnızca sağlayıcınız görebilir.

Ayrıca bir eklenti veritabanına yanlış sorgu gönderiyorsa hata yine günlüğe düşer. Yedek alma ve geri yükleme tarafı için veritabanı yedekleme rehberimize göz atın. Parolaları bu tür dosyalarda saklarken dikkatli olun; bu bilgileri hiçbir zaman herkese açık bir yere yazmayın.

Search Console'da 500 hatasını nasıl takip edersiniz?

Hata düzelse bile Google'ın bunu fark etmesi zaman alır. Search Console'daki Sayfa dizine ekleme raporu, sunucu hatası (5xx) nedeniyle dizine eklenemeyen sayfaları ayrı bir başlık altında listeler. Ayrıca Tarama istatistikleri raporu, sunucu yanıtlarının zaman içindeki seyrini gösterir.

Düzeltmeden sonra şu adımları izleyin:

1. URL Denetimi aracıyla etkilenen bir adresin canlı testini çalıştırın.
2. Sayfa 200 dönüyorsa raporda ilgili sorun için doğrulamayı başlatın.
3. Birkaç gün boyunca tarama istatistiklerini izleyin.
4. Hata tekrar ederse günlük kayıtlarıyla zaman damgalarını eşleştirin.

Google'ın bu doğrulamayı ne kadar sürede tamamlayacağını kesin söyleyemeyiz. Rapor arayüzü zamanla değişebilir, bu yüzden menü adlarını kendi hesabınızda doğrulayın.

Hata çözüldükten sonra kök nedeni nasıl kaydedersiniz?

Hata geçti diye konuyu kapatmayın. Çünkü nedenini bilmezseniz aynı sorun, belki daha kötü bir anda, yeniden çıkar. Kısa bir olay notu tutmak, ekibiniz için de ileride size de zaman kazandırır.

Notta şu başlıkları yazmanız yeterlidir:

• Hata ne zaman başladı ve ne zaman bitti?
• Günlükteki mesaj ve etkilenen dosya neydi?
• Hatadan önce hangi değişiklik yapılmıştı?
• Çözüm olarak hangi adım işe yaradı?
• Gelecekte bu hatayı önlemek için hangi kural eklendi?

Örneğin bir eklenti güncellemesi hataya yol açtıysa, bundan sonra güncellemeleri önce staging ortamında denemeyi kural hâline getirirsiniz. Böylece aynı hata ikinci kez canlı siteye ulaşmaz. Ayrıca not, bir hosting sağlayıcısıyla yazışırken de kanıt işlevi görür.

Küçük işletmelerde bile bu alışkanlık işe yarar. Yani amaç kusursuz bir süreç kurmak değil, aynı hatayı iki kez yaşamamaktır. Bu nedenle notu kısa tutun, ama her olay için yazın.

500, 502, 503 ve 401 hataları arasındaki fark nedir?

Hepsi farklı bir sorunu anlatır, bu yüzden aynı çözümü uygulamayın. 500 genel bir sunucu hatasıdır. 502 ve 503 ise sunucu zincirinin farklı bir noktasını işaret eder. 401 ise sunucu hatası değil, kimlik doğrulama durumudur.

Bu kodların her biri için ayrı kardeş yazılar hazırlıyoruz. Burada yalnızca farkı gösteriyoruz, çünkü her birinin teşhis sırası farklıdır. Kodlar arasındaki sınır için RFC 9110 birincil kaynaktır.

Güvenlik duvarı kaynaklı 403 için ModSecurity ve 403 hatası yazımıza bakın.

Ne zaman kendiniz uğraşmamalı, hosting sağlayıcınıza bırakmalısınız?

Her 500 hatası sizin müdahale edeceğiniz bir hata değildir. Bazı durumlarda en doğru adım, vakit kaybetmeden hosting desteğine yazmaktır. Dürüst olalım: yanlış bir müdahale küçük bir sorunu büyütebilir.

• Hata günlüğüne erişiminiz yoksa ve panelde Hatalar ekranı kapalıysa.
• Hata birden fazla sitenizde aynı anda başladıysa; sorun büyük olasılıkla sunucudadır.
• Günlükte disk, kota ya da sunucu servisleriyle ilgili mesaj varsa.
• Yapılandırma dosyalarını okumayı bilmiyorsanız ve canlı bir e-ticaret siteniz varsa.
• Yedeğiniz yoksa; önce yedek, sonra müdahale.

Destek talebinde şunları yazın: hatanın başladığı saat, o saatten önce yaptığınız değişiklik, günlükten kopyaladığınız satır ve denediğiniz adımlar. Bu bilgilerle çözüm süresi kısalır.

500 hatası tekrar etmesin diye hangi önlemleri alırsınız?

Hatayı çözmek yarım iştir. Aynı hatanın tekrar etmemesi için birkaç düzen kurmanız gerekir. Bu düzenler büyük yatırım istemez, ama disiplin ister.

• Staging ortamı: Güncellemeleri önce kopya sitede deneyin, sonra canlıya alın.
• Yedek: Değişiklikten önce yedek alın ve geri yüklemeyi bir kez test edin.
• Sürüm uyumu: PHP sürümünü değiştirmeden önce eklenti ve tema desteğini kontrol edin.
• İzleme: Sitenin durum kodunu düzenli kontrol eden bir izleme servisi kurun.
• Değişiklik kaydı: Ne zaman neyi değiştirdiğinizi not edin.

Hosting seçimi de önemlidir; kaynak sınırları ve destek kalitesi bu hataların sıklığını belirler. Seçim kriterleri için hosting seçimi rehberimize bakın.

Sorun giderirken nelerden kaçınmalısınız?

Telaşla yapılan hamleler sorunu büyütür. Bu nedenle aşağıdaki riskleri bir kontrol listesi gibi düşünün.

• Dosyaları silmeyin: Yeniden adlandırmak geri alınabilir, silmek alınamaz.
• İzinleri 777 yapmayın: Hem güvenlik riski doğurur hem de bazı yapılandırmalarda hatayı daha da kötüleştirir.
• Canlıda hata gösterimini açık bırakmayın: Sayfada görünen hata ayrıntıları dosya yollarını ifşa eder.
• Yedeksiz müdahale etmeyin: Önce yedek, sonra değişiklik.
• Aynı anda birden fazla şey değiştirmeyin: Hangisinin işe yaradığını anlayamazsınız.

Son kural özellikle önemlidir: tek seferde beş şey değiştirirseniz nedeni öğrenemezsiniz.

500 hatası için hızlı kontrol listesi nedir?

Özetle, 500 Internal Server Error genel bir sunucu hatasıdır ve cevabı hata günlüğünde bulursunuz. Aşağıdaki liste, bu yazının tamamını tek bakışta toplar. Hata anında bu listeyi yukarıdan aşağıya takip edin.

1. Durum kodunu doğrulayın; gerçekten 500 mü?
2. Tek sayfada mı, tüm sitede mi olduğuna bakın.
3. Hata günlüğünü okuyun.
4. Son değişikliği geri alın.
5. .htaccess dosyasını yeniden adlandırarak test edin.
6. Eklentileri ve temayı kapatın.
7. PHP sürümünü ve memory_limit değerini kontrol edin.
8. Dosya izinlerini kontrol edin.
9. Disk ve bellek durumuna bakın.
10. Çözemediyseniz hosting desteğine günlük satırıyla yazın.

Bu rehberdeki kaynakları kendiniz de okuyabilirsiniz: Google Search Central HTTP ve ağ hataları belgesi, WordPress yaygın hatalar belgesi, Apache .htaccess belgesi, WordPress hata ayıklama belgesi ve cPanel Hatalar belgesi.