Résoudre l'erreur interne du serveur 500

Un 500 Erreur interne du serveur fait partie des erreurs de site Web côté serveur les plus courantes. Le message signifie que le serveur Web a reçu une requête, mais n'a pas pu la traiter avec succès en raison d'une erreur interne.

Le code d'état 500 sans pour autant en mentionner la cause réelle. Il s'agit souvent d'erreurs PHP, d'un dysfonctionnement .htaccess, des plugins ou thèmes incompatibles, des paramètres PHP incorrects ou des problèmes de fichiers et de permissions.

Dans ce guide, nous vous montrons comment résoudre une erreur interne de serveur 500 dans l'hébergement web CURIAWEB diagnostiques de manière systématique et trouves la cause réelle.

Important : Une erreur 500 est un message générique. Ne modifiez donc pas au hasard la version de PHP, les permissions de fichiers, les extensions et .htaccess simultanément. Le moyen le plus rapide de trouver une solution consiste généralement à identifier le moment exact de l'erreur et à consulter le journal des erreurs.

Que signifie l'erreur 500 Internal Server Error ? #

En gros, une requête se déroule de la manière suivante :

Le navigateur envoie la requête
        ↓
Le serveur web reçoit la requête
        ↓
Le traitement côté serveur échoue
        ↓
500 Erreur interne du serveur

Le navigateur ne sait généralement pas quel erreur interne est survenue sur le serveur. C'est pourquoi seul le code d'état HTTP général 500 affiché.

À quoi peut ressembler une erreur 500 ? #

Selon le serveur Web, l'application et le navigateur, le message visible peut être formulé différemment.

Les exemples sont :

500 Erreur interne du serveur

Erreur interne du serveur

ERREUR HTTP 500

Le serveur a rencontré une erreur interne
et n'a pas pu traiter votre demande.

Ce qui compte n'est pas la formulation exacte, mais que la requête avec le code d'état HTTP 500 échoue.

différencier 500, 403, 404 et 503 #

Statut	En termes simples, il
403 Interdit	Accès refusé
404 Non trouvé	Ressource introuvable
500 Erreur interne du serveur	Le traitement interne côté serveur a échoué
503 Service indisponible	Le service ne peut pas traiter la demande temporairement.

Si un code 403 s'affiche réellement, utilise plutôt notre guide Résoudre l'erreur 403 Forbidden.

Tout d'abord, cerner le problème #

Avant de modifier quoi que ce soit, vérifie quand et où l'erreur se produit.

Établis par exemple :

• Est-ce que tout le site web est concerné ?
• Une seule page ?
• Seulement l'espace d'administration WordPress ?
• Seulement une action spécifique ?
• Un seul script PHP ?
• Un simple import ou export ?
• L'erreur est-elle apparue immédiatement après une modification ?
• L'erreur est-elle permanente ou seulement sporadique ?

Ces informations aident à cibler nettement la recherche de pannes.

1. Noter la date, l'heure et l'URL concernée #

Note le moment exact où l'erreur se produit.

Exemple :

28.08.2026
15:42
https://example.ch/wp-admin/
500 Internal Server Error

Si l'erreur ne se produit que lors d'une action spécifique, notez-la également.

Par exemple :

WordPress fonctionne
→ Mettre à jour le plugin
→ 500 Internal Server Error

L'heure exacte est importante pour que tu puisses ensuite trouver l'entrée correspondante dans le journal des erreurs.

2. Vérifier le journal des erreurs cPanel #

Ouvrez dans le cPanel de CURIAWEB :

Valeurs mesurées → Erreur

Rechercher les entrées qui coïncident temporellement avec l'erreur 500.

Le journal des erreurs est l'un des points de diagnostic les plus importants en cas d'erreur interne du serveur 500.

Nous vous expliquons en détail comment lire correctement les messages sur Lire le journal des erreurs cPanel et trouver les erreurs du site Web.

Conseil pratique : Si l'erreur est reproductible, notez l'heure actuelle, visitez la page défectueuse une fois, puis vérifiez directement le journal des erreurs (error log). Cela permet souvent d'isoler plus facilement l'entrée pertinente.

Le message d'erreur exact est plus important que „ Erreur 500 “ #

L'erreur 500 visible n'est que le symptôme.

Un enregistrement de journal des erreurs, en revanche, peut par exemple contenir des indications telles que :

Erreur fatale PHP

Taille de mémoire autorisée épuisée

Appel à une fonction non définie

Classe introuvable

Permission refusée

Erreur de configuration .htaccess

Ces informations mènent beaucoup plus près de la cause réelle.

3. Vérifier les dernières modifications #

Si un site Web fonctionnait auparavant, la question la plus importante est souvent :

Qu'a-t-il été modifié immédiatement avant la première erreur 500 ?

Vérifiez par exemple :

• Extension installée ou mise à jour
• Thème mis à jour
• WordPress se met à jour
• Version PHP modifiée
• .htaccess modifié
• Paramètres PHP modifiés
• Fichiers téléchargés ou remplacés
• Site Web migré
• code PHP personnalisé modifié
• nouveau cronjob configuré

Une relation temporelle étroite est un indice diagnostique important.

Vérifier le fichier .htaccess #

Une instruction Apache erronée dans une .htaccess-Le fichier peut provoquer une erreur interne du serveur 500.

Cela est particulièrement probable si l'erreur a commencé immédiatement après une modification manuelle de ce fichier.

Le dé .htaccess se trouve souvent dans la racine du document du site Web.

Si elle n'est pas visible dans le gestionnaire de fichiers, lis d'abord Afficher les fichiers cachés comme .htaccess dans cPanel.

.Ne pas simplement supprimer le .htaccess #

Le fichier peut contenir des règles importantes, par exemple pour :

• Permaliens WordPress
• Redirections
• Protection contre l'accès non autorisé
• instructions de serveur individuelles

Faites donc d'abord une sauvegarde.

Nous expliquons comment effectuer des modifications de manière contrôlée sur .htaccess expliqué et modifié en toute sécurité.

Annuler la dernière règle .htaccess insérée #

Si le déroulement est clair :

Site Web fonctionne
        ↓
.htaccess modifié
        ↓
Erreur 500 (Internal Server Error)

tu devrais d'abord annuler exactement cette modification.

Ne supprime pas au hasard toutes les règles existantes.

.Renommer temporairement le fichier .htaccess #

Si vous avez un fort soupçon de .htaccess as, mais que tu ne parviens pas à identifier quelle règle est erronée, tu peux, après avoir fait une sauvegarde préalable, renommer temporairement le fichier.

Par exemple :

.htaccess
→
.htaccess-test

Ensuite, recharge le site Web.

Si l'erreur 500 disparaît, il y a de fortes chances pour que la cause se situe au sein des éléments précédents. .htaccess-Configuration précédente.

Important : Le changement de nom est une étape de diagnostic et non une solution définitive. Des fonctionnalités telles que les permaliens WordPress ou les redirections peuvent ainsi cesser de fonctionner correctement de manière temporaire.

5. Vérifier la version de PHP #

Une erreur 500 peut se produire lorsqu'un site Web n'est pas compatible avec la version de PHP utilisée.

C'est particulièrement pertinent si l'erreur est intervenue immédiatement après un changement de version de PHP.

Chez CURIAWEB, vous gérez fondamentalement la version PHP d'un domaine via :

Logiciel → MultiPHP-Manager

Vous trouverez le mode d'emploi complet sur Modifier la version PHP dans cPanel.

Ne pas changer de version de PHP au hasard #

Ne teste pas successivement des versions de PHP au hasard en espérant que l'une d'elles fonctionne.

Vérifie d'abord :

• quelle version de PHP est actuellement utilisée
• quelle version fonctionnait auparavant
• quelle version l'application prend en charge
• si les plugins et thèmes sont compatibles avec cela

Si l'erreur a commencé directement après un changement de version de PHP, un retour contrôlé à la version précédente qui fonctionnait et qui reste adaptée peut constituer un test judicieux.

6. Vérifier les erreurs fatales PHP #

Une erreur fatale PHP peut empêcher qu'une requête ne soit exécutée avec succès.

Les messages types peuvent par exemple commencer ainsi :

Erreur fatale PHP :

Le reste du texte du message est crucial pour le diagnostic.

Il peut par exemple :

• un fichier PHP spécifique
• un plugin WordPress
• un thème
• une fonction manquante
• une classe manquante
• une erreur de mémoire

indiquer.

Lire le chemin dans le message d'erreur #

Si le message contient un chemin de fichier, celui-ci peut fournir un indice important sur le composant responsable.

Exemple :

/wp-content/plugins/beispiel-plugin/...

indique que le code situé dans ce répertoire de plugin est impliqué dans l'erreur.

Cela ne prouve pas automatiquement que l'ensemble du plugin est défectueux, mais cela restreint considérablement le champ de l'investigation.

7. Vérification des extensions PHP manquantes #

Après un changement de version de PHP ou une migration, une application peut s'attendre à une extension PHP qui n'est pas disponible dans l'environnement PHP utilisé.

Les indications typiques sont par exemple :

Appel à une fonction non définie ...

Classe ... introuvable

nécessite l'extension ...

Nous expliquons comment enquêter sur de tels cas sous Activer et gérer les extensions PHP dans cPanel.

Considérer les extensions PHP et la version de PHP ensemble #

Les extensions PHP dépendent de la version.

Par conséquent, si une erreur survient immédiatement après un changement de version de PHP, vous ne devez pas seulement examiner le numéro de version, mais aussi vérifier si l'application dispose de toutes les fonctionnalités requises dans cet environnement PHP.

8. Vérifier la limite de mémoire PHP #

Si le journal des erreurs contient par exemple le message suivant :

Taille de mémoire autorisée de ... octets épuisée

a un processus PHP configuré limite_mémoire atteint.

C'est une indication concrète et il ne faut pas la confondre avec la mémoire physique de CloudLinux.

Nous expliquons comment vérifier et configurer judicieusement les limites PHP sur Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.

Ne pas augmenter la limite de mémoire de manière arbitraire #

Si une application consomme une quantité inhabituelle de mémoire, une limite plus élevée peut éventuellement reporter le symptôme sans éliminer la cause profonde.

Vérifiez par conséquent également :

• quel processus nécessite de la mémoire
• si le besoin pour la tâche en question est plausible
• si un plugin ou un script fonctionne mal

9. Vérifier les autres paramètres PHP #

Si l'erreur a commencé après des modifications de la configuration PHP, vérifiez les dernières valeurs modifiées.

Sur CURIAWEB, vous utilisez pour cela en principe le :

Logiciel → Éditeur INI MultiPHP

Tu trouveras nos instructions sur Modifier les paramètres PHP dans cPanel.

Ne modifiez pas les valeurs PHP au pif. Utilisez le message d'erreur et les exigences de l'application comme base.

10. Vérifier les autorisations de fichiers #

Des autorisations de fichiers ou de répertoires inappropriées peuvent également causer des problèmes côté serveur.

Ouvrir :

Fichiers → Gestionnaire de fichiers

Vérifiez en particulier les fichiers et répertoires qui ont été modifiés, téléchargés ou décompressés immédiatement avant l'erreur.

Sur les sites web typiques, les valeurs suivantes sont souvent utilisées :

Fichiers :       644
Répertoires : 755

Vous trouverez la procédure exacte sous Définir correctement les autorisations de fichiers 644 et 755 dans cPanel.

Attention : Ne définissez pas les autorisations globalement sur 777. Ce n'est pas une solution propre pour une erreur 500 et cela peut causer des problèmes de sécurité.

11. Contrôler les fichiers après la migration ou le chargement #

Si l'erreur a commencé après une migration ou un téléchargement manuel, vérifiez :

• si tous les fichiers ont été transférés
• si les fichiers se trouvent dans le bon dossier racine du document
• ont été entièrement extraites de l'archive
• si des fichiers de configuration existent
• si les autorisations sont plausibles
• si la version de PHP correspond à l'application

Un plugin, un thème ou un framework transféré de manière incomplète peut également provoquer des erreurs côté serveur.

12. Contrôler le répertoire racine du document #

Si vous examinez éventuellement des fichiers dans le mauvais répertoire, vérifiez sous :

Domaines → Domaines

la racine du document du domaine concerné.

Tu trouveras notre guide à ce sujet sous Ajouter et gérer un domaine dans cPanel.

13. Analyser les plugins WordPress #

Sous WordPress, les plugins font partie des composants d'application les plus fréquemment impliqués dans une erreur 500.

Un plugin est particulièrement suspect si l'erreur survient immédiatement après :

• Installation
• Activation
• Mettre à jour
• Modification de configuration

ce plugin a commencé.

Vérifie d'abord le journal des erreurs. Le message d'erreur contient-il un chemin dans :

/wp-content/plugins/

pouvez-vous concentrer l'examen sur l'extension en question.

Désactiver un plugin WordPress lorsque wp-admin est inaccessible #

Si un plugin défectueux rend l'espace d'administration de WordPress inaccessible, il peut être nécessaire de désactiver l'extension en dehors du backend de WordPress.

Vous trouverez les instructions correspondantes sous Désactiver ou supprimer un plugin WordPress.

Ne pas désactiver tous les plugins en même temps si la cause est connue #

Si le journal d'erreurs pointe clairement vers une extension spécifique, tu devrais d'abord examiner précisément ce composant.

Une désactivation complète de tous les plugins relève plutôt d'une étape de diagnostic lorsque la cause ne peut pas être cernée.

14. Examiner le thème WordPress #

Un thème peut également contenir du code PHP qui provoque une erreur fatale.

Si le journal des erreurs indique un chemin tel que :

/wp-content/themes/mein-theme/

montre, la composante de thème en question devrait être examinée.

C'est particulièrement vrai si l'erreur a commencé immédiatement après une mise à jour du thème ou une modification du code.

Vérifier systématiquement les conflits de plugins et de thèmes #

Si la cause n'est pas évidente, utilise le mode d'emploi Détecter et résoudre les conflits de plugins et thèmes WordPress.

Procède de manière contrôlée et documente chaque modification.

15. Utiliser le débogage WordPress #

Si le journal d'erreurs normal ne fournit pas suffisamment d'informations, une sortie de débogage ciblée ou un enregistrement (journalisation) peut s'avérer utile dans WordPress.

WordPress peut commettre des erreurs, par exemple dans :

wp-content/debug.log

enregistrer dans les journaux si le débogage a été configuré en conséquence.

Nous vous expliquons comment configurer cela en toute sécurité sur Utiliser le débogage et les journaux d'erreurs de WordPress.

Important : N'activez pas durablement un affichage détaillé des erreurs pour les visiteurs sur un site web en production. Les messages d'erreur peuvent révéler des détails techniques et des chemins internes.

16. Prendre en compte l'erreur critique WordPress #

WordPress peut afficher son propre message concernant une erreur critique au lieu d'une erreur 500 classique en cas de certaines erreurs fatales de PHP.

Les deux types d'erreurs peuvent avoir la même cause technique.

Lorsque WordPress affiche le message :

Il y a eu une erreur critique sur votre site Web.

indique, utilise en plus Résoudre l'erreur critique WordPress ou la page blanche.

17. Erreur sur une seule page #

Si la page d'accueil fonctionne, mais qu'une seule URL génère une erreur 500, vous devez concentrer le diagnostic sur cette requête.

Les causes possibles sont par exemple :

• certain plugin
• code PHP personnalisé
• données erronées
• requête de base de données spécifique
• Règle de réécriture
• fonction gourmande en mémoire

Ne modifiez pas toute la configuration de l'hébergement si l'erreur ne concerne qu'une seule fonction.

18. Erreur uniquement dans l'espace d'administration WordPress #

Si le site web public fonctionne, mais /wp-admin/ générant une erreur 500, un problème général de DNS ou de domaine est improbable.

Vérifie particulièrement :

• Journal des erreurs
• Extensions
• Thème ou code personnalisé
• Version PHP
• Limite de mémoire PHP
• mises à jour récentes

19. Erreur uniquement lors de l'enregistrement ou de la mise à jour #

Lorsque WordPress se charge normalement, mais que, par exemple, l'enregistrement d'un article échoue avec une erreur 500, il convient d'analyser le traitement côté serveur de cette action précise.

Reproduisez l'erreur une seule fois et contrôlez immédiatement après le journal des erreurs.

Ce type d'erreur peut par exemple être lié à un plugin, à du code PHP ou à un traitement gourmand en ressources.

20. Erreur lors des téléversements #

Si l'erreur 500 se produit uniquement lors du téléchargement de fichiers volumineux, vérifiez également les limites PHP.

Peuvent par exemple être pertinents :

upload_max_filesize
post_max_size
memory_limit
max_execution_time

Notez que ces valeurs ont des rôles différents et ne doivent pas être augmentées de manière aléatoire.

21. Erreur lors des importations #

Si seulement un grand import avec 500 échoue tandis que le reste du site web fonctionne, vous devriez examiner le traitement des imports.

Vérifie en particulier :

• Journal des erreurs
• Limite de mémoire PHP
• Temps d'exécution
• Compatibilité PHP
• Taille de l'importation
• Erreur de l'application d'importation utilisée

Si possible, une application peut prendre en charge des lots de traitement plus petits. Le paramètre le plus judicieux dépend de l'outil d'importation utilisé.

22. Erreur dans les tâches cron #

Un script PHP peut échouer lors d'une tâche cron, même si le site Web fonctionne fondamentalement dans le navigateur.

Si l'erreur se produit dans le cadre d'un processus planifié, vérifiez :

• Commande cron
• Chemin PHP ou version PHP
• Chemin d'accès
• Autorisations
• Message d'erreur

Tu trouveras le diagnostic détaillé sous La tâche cron ne fonctionne pas : causes et solutions.

23. Vérification des ressources CloudLinux #

Si l'erreur 500 ne se produit que de manière sporadique ou sous charge, tu devrais également vérifier l'utilisation des ressources CloudLinux au même moment.

Ouvrir :

Valeurs mesurées → Utilisation des ressources

Vérifiez si une limite de ressources a été atteinte au moment de l'erreur.

Nous expliquons comment interpréter les valeurs sous Comprendre l'utilisation des ressources CloudLinux dans cPanel.

500 et Resource Limit Is Reached ne sont pas la même chose #

Une limite CloudLinux et une erreur HTTP 500 sont deux choses différentes.

Cependant, un goulot d'étranglement des ressources peut affecter le traitement d'une application. C'est pourquoi une comparaison temporelle est judicieuse en cas d'erreurs sporadiques.

Si expressément 508 Limite de ressources atteinte affiché, utilise notre guide Limite de ressources atteinte : identifier et corriger les limites CloudLinux.

24. Vérifier l'espace de stockage #

Un compte d'hébergement entièrement saturé peut perturber diverses applications et opérations d'écriture.

Si l'erreur survient par exemple lors de mises à jour, de la création de cache, de téléversements ou d'autres opérations d'écriture, vérifiez également l'espace de stockage disponible.

Vous trouverez la procédure sous Vérifier l'espace disque et la bande passante dans cPanel.

25. Tenir compte des erreurs de base de données #

Une application peut générer une erreur 500 si le code côté serveur échoue lors d'une opération de base de données.

Cela ne signifie pas pour autant que tu devrais immédiatement réparer ou modifier des tables dans phpMyAdmin.

Vérifie d'abord le message d'erreur précis.

Si un problème de base de données est mentionné, notez :

• genauen Fehlertext
• betroffene Tabelle, falls angegeben
• betroffene Anwendung
• Moment

Datenbank nicht auf Verdacht bearbeiten #

Lösche oder ändere keine Tabellen, nur weil ein 500-Fehler auftritt.

Ein Fehler in Anwendungscode kann genauso gut die Datenbankabfrage verursachen.

Les bases de la gestion de bases de données se trouvent sur Utiliser phpMyAdmin dans cPanel.

26. Fehler nach Website-Migration #

Wenn eine Website unmittelbar nach einer Migration einen 500-Fehler erzeugt, solltest du besonders folgende Punkte prüfen:

• Version PHP
• extensions PHP requises
• Paramètres PHP
• .htaccess
• Autorisations de fichiers
• vollständige Dateiübertragung
• Connexion à la base de données
• anwendungsspezifische Pfade und Konfigurationen

Versuche nicht, alle Punkte gleichzeitig zu verändern. Das Error Log sollte auch hier die Diagnose führen.

27. Fehler nach PHP-Wechsel #

Wenn der zeitliche Ablauf lautet:

Website funktioniert
        ↓
PHP-Version geändert
        ↓
500 Internal Server Error

prüfe zuerst:

• Kompatibilität der Anwendung
• Extensions et thèmes
• extensions PHP requises
• Journal des erreurs

Ein Wechsel zurück auf die zuvor funktionierende und weiterhin unterstützte Version kann als kontrollierter Test sinnvoll sein.

28. Fehler nach Plugin-Update #

Wenn ein 500-Fehler unmittelbar nach einem Plugin-Update beginnt, prüfe zuerst das Error Log auf einen entsprechenden Plugin-Pfad.

Falls die Erweiterung tatsächlich beteiligt ist, können je nach Situation folgende Schritte sinnvoll sein:

• Plugin deaktivieren
• Kompatibilität prüfen
• Update korrigieren beziehungsweise erneut sauber installieren
• Herstellerhinweise prüfen

Führe kein Downgrade auf eine unsichere oder bekannte fehlerhafte Version durch, ohne die Auswirkungen zu prüfen.

29. Fehler nach Theme-Update #

Dasselbe gilt für Themes.

Wenn das Error Log auf:

/wp-content/themes/...

verweist und der Fehler direkt nach einem Theme-Update begonnen hat, konzentriere die Diagnose auf diese Komponente.

30. Fehler nach Bearbeitung von functions.php #

Individueller PHP-Code in einer Theme-Datei kann bereits durch einen Syntax- oder Programmierfehler die Ausführung unterbrechen.

Wenn der Fehler unmittelbar nach einer Änderung an:

fonctions.php

auftritt, stelle zunächst die zuvor funktionierende Version dieser Änderung wieder her.

Bearbeite produktiven PHP-Code nicht ohne Sicherung.

31. Fehler nach Code Snippet #

Dasselbe Prinzip gilt für individuell eingefügten PHP-Code über ein Snippet-Plugin.

Si :

Snippet aktiviert
        ↓
500 Internal Server Error

ist dieses Snippet ein naheliegender Ausgangspunkt der Diagnose.

Prüfe das Error Log und deaktiviere gezielt den betreffenden Code, sofern dies sicher möglich ist.

32. Fehler nach Entpacken eines Archivs #

Wenn eine Website nach dem Hochladen und Entpacken eines ZIP-Archivs einen 500-Fehler erzeugt, prüfe:

• ob das Archiv vollständig entpackt wurde
• ob Dateien im richtigen Verzeichnis liegen
• Autorisations de fichiers
• .htaccess
• Compatibilité PHP
• Fichiers de configuration

Wie du Archive korrekt verarbeitest, erklären wir unter Compresser et décompresser des fichiers ZIP dans cPanel.

33. 500 nur zeitweise #

Ein sporadischer 500-Fehler ist schwieriger zu diagnostizieren als ein dauerhaft reproduzierbarer Fehler.

Notiere deshalb jeden bekannten Zeitpunkt und vergleiche:

Zeitpunkt des 500-Fehlers
        ↓
Error Log
        ↓
CloudLinux-Ressourcen
        ↓
Cronjobs / Hintergrundaufgaben
        ↓
Traffic / besondere Aktivität

Wiederkehrende Zeitmuster können besonders hilfreich sein.

34. 500 immer zur selben Uhrzeit #

Wenn der Fehler regelmäßig ungefähr zur gleichen Uhrzeit auftritt, prüfe geplante Prozesse.

Cela peut par exemple inclure :

• Tâches cron
• Importe
• Exporte
• Synchronisations
• Plugins de sauvegarde
• Tâches d'arrière-plan WordPress

Der wiederkehrende Zeitpunkt ist dabei ein starker Diagnosehinweis.

35. 500 nur bei hoher Last #

Wenn der Fehler ausschließlich während hoher Auslastung auftritt, prüfe zusätzlich CloudLinux und die Art der Anfragen.

Ein hoher Traffic allein beweist noch nicht, dass das Hosting-Paket die Ursache ist.

Auch langsame PHP-Prozesse, ineffiziente Datenbankabfragen oder fehlendes Caching können dazu führen, dass sich Anfragen unter Last stärker aufstauen.

36. Caching kontrollieren #

Bei WordPress kann geeignetes Caching die dynamische Verarbeitung reduzieren.

CURIAWEB stellt dafür AccelerateWP in der Hosting-Umgebung bereit.

Die Verwendung erklären wir unter AccelerateWP dans cPanel expliqué.

Caching ist jedoch keine Reparatur für einen PHP Fatal Error oder eine fehlerhafte .htaccess.

37. Nicht mehrere Cache-Systeme als Fehlerbehebung installieren #

Ein 500-Fehler sollte nicht dadurch behandelt werden, dass zusätzliche Performance-Plugins installiert werden.

Dadurch kann die technische Situation sogar komplizierter werden.

Finde zuerst die Ursache des Fehlers.

38. Browser-Cache ist selten die Ursache eines echten 500 #

Ein HTTP-500 wird serverseitig erzeugt.

Ein privates Browserfenster kann bei Tests trotzdem hilfreich sein, ändert aber nicht die zugrunde liegende Serverursache.

Wenn der Webserver weiterhin mit 500 antwortet, muss die serverseitige Verarbeitung untersucht werden.

39. DNS ist normalerweise nicht die Ursache eines 500 #

Wenn du von einem Webserver bereits einen HTTP-500 erhältst, wurde grundsätzlich ein Server erreicht.

Une panne DNS classique se manifeste différemment.

Nach DNS-Änderungen kann eine Domain allerdings versehentlich auf einen anderen Server zeigen. Prüfe deshalb bei einer kürzlichen Migration, ob du tatsächlich die erwartete Hosting-Umgebung erreichst.

40. SSL-Fehler und HTTP 500 unterscheiden #

Ein Zertifikatsfehler ist ebenfalls eine andere Fehlerklasse.

Wenn der Browser einen echten HTTP-Statuscode 500 erhält, wurde die Verbindung bereits weit genug aufgebaut, damit der Webserver eine HTTP-Antwort senden konnte.

Ersetze deshalb nicht auf Verdacht SSL-Zertifikate.

41. 500-Fehler nicht durch display_errors dauerhaft offenlegen #

Es kann verlockend sein, PHP-Fehler direkt auf der öffentlichen Website anzeigen zu lassen.

Auf einer produktiven Website ist das keine gute dauerhafte Lösung, weil Fehlermeldungen interne Informationen wie Dateipfade oder technische Details offenlegen können.

Verwende für die Diagnose bevorzugt Fehlerprotokolle.

42. Fehler nach Änderung erneut reproduzieren #

Nach jeder gezielten Korrektur solltest du exakt dieselbe URL oder Aktion erneut testen.

Ein sinnvoller Ablauf lautet:

Fehler reproduzieren
        ↓
Log prüfen
        ↓
eine Ursache ändern
        ↓
gleiche Aktion erneut testen
        ↓
Ergebnis vergleichen

Dadurch kannst du feststellen, ob deine Änderung tatsächlich relevant war.

43. Nicht fünf Dinge gleichzeitig ändern #

Si vous en même temps :

PHP wechselst
.htaccess löschst
Plugins deaktivierst
Berechtigungen änderst
Cache leerst

und die Website danach wieder funktioniert, weißt du nicht, was die Ursache war.

Das erschwert spätere Fehler erheblich.

Règle de base : Bei einem 500 Internal Server Error sollte das Error Log die Diagnose führen. Eine konkrete Fehlermeldung ist wertvoller als zehn Änderungen auf Verdacht.

500 Internal Server Error systematisch diagnostizieren #

1. Notiere betroffene URL, Datum und Uhrzeit.
2. Prüfe, ob die ganze Website oder nur eine bestimmte Aktion betroffen ist.
3. Ouvrir Valeurs mesurées → Erreur.
4. Suche den zeitlich passenden Error-Log-Eintrag.
5. Prüfe die zuletzt vorgenommenen Änderungen.
6. Untersuche bei entsprechendem Hinweis die .htaccess.
7. Kontrolliere PHP-Version und Anwendungskompatibilität.
8. Prüfe gemeldete PHP Fatal Errors.
9. Kontrolliere gegebenenfalls benötigte PHP-Erweiterungen.
10. Prüfe bei Speicherfehlern das PHP Memory Limit.
11. Kontrolliere relevante Datei- und Verzeichnisberechtigungen.
12. Prüfe bei WordPress den im Log genannten Plugin- oder Theme-Pfad.
13. Kontrolliere bei sporadischen Fehlern die CloudLinux-Ressourcen.
14. Prenez en compte les tâches cron et les tâches d'arrière-plan.
15. Ändere nur eine mögliche Ursache gleichzeitig.
16. Teste anschließend exakt dieselbe Aktion erneut.

Schnelldiagnose nach Fehlermeldung #

Hinweis	Premier point de contrôle
Erreur fatale PHP	genannten PHP-Pfad beziehungsweise Komponente prüfen
Taille de mémoire autorisée épuisée	PHP Memory Limit und verursachenden Prozess prüfen
Appel à une fonction non définie	PHP-Kompatibilität beziehungsweise Erweiterung prüfen
Classe introuvable	Anwendung, Autoloading oder benötigte Erweiterung prüfen
Fehler direkt nach .htaccess-Änderung	zuletzt geänderte Regel prüfen
Fehler direkt nach PHP-Wechsel	PHP-Kompatibilität und Erweiterungen prüfen
Fehler direkt nach Plugin-Update	Error Log und betreffendes Plugin prüfen
Fehler nur unter Last	CloudLinux-Ressourcen und Anwendung prüfen
Fehler regelmäßig zur gleichen Uhrzeit	Cronjobs und Hintergrundaufgaben prüfen

Was du bei einem 500-Fehler nicht tun solltest #

Évitez en particulier :

• Autorisations de fichiers par lot sur 777 mettre
• .htaccess supprimer sans sauvegarde
• Changer de version PHP au hasard
• PHP Memory Limit extrem erhöhen
• alle Plugins ohne Diagnose löschen
• Modifier les tables de base de données par suspicion
• installer plusieurs plugins de cache
• DNS oder SSL ohne entsprechenden Hinweis ändern
• effectuer plusieurs modifications techniques simultanément

Quand devez-vous contacter le support CURIAWEB ? #

Wenn der 500 Internal Server Error weiterhin besteht oder die Ursache aus dem Error Log nicht eindeutig hervorgeht, dokumentiere das Problem möglichst genau.

Sont particulièrement utiles :

• domaine concerné
• URL complète concernée
• Date et heure exactes
• message d'erreur visible
• relevanter Error-Log-Eintrag
• ob die gesamte Website oder nur eine bestimmte Aktion betroffen ist
• modifications récentes
• aktuell verwendete PHP-Version
• ob der Fehler dauerhaft oder sporadisch auftritt
• bei sporadischen Fehlern gegebenenfalls auffällige CloudLinux-Werte

Wenn der Fehler reproduzierbar ist, beschreibe zusätzlich die genauen Schritte, mit denen er ausgelöst werden kann.

Résumé #

Un 500 Erreur interne du serveur bedeutet, dass eine serverseitige Anfrage nicht erfolgreich verarbeitet werden konnte. Der Statuscode selbst nennt noch nicht die eigentliche Ursache.

Der wichtigste erste Diagnosepunkt ist deshalb das cPanel Error Log unter Valeurs mesurées → Erreur. Vergleiche den dortigen Eintrag mit dem genauen Zeitpunkt des Fehlers.

Häufige Ursachen sind PHP Fatal Errors, fehlerhafte .htaccess-Regeln, inkompatible Plugins oder Themes, ungeeignete PHP-Versionen, fehlende PHP-Erweiterungen, erreichte PHP-Limits oder Probleme nach einer Migration beziehungsweise Dateiänderung.

Bei sporadischen Fehlern solltest du zusätzlich die CloudLinux-Ressourcennutzung, Cronjobs und Hintergrundaufgaben zum gleichen Zeitpunkt untersuchen.

Ändere nicht mehrere Komponenten gleichzeitig. Reproduziere den Fehler, prüfe das Log, formuliere eine konkrete Ursache und teste anschließend genau eine gezielte Änderung.

La règle la plus importante est : „500 Internal Server Error“ ist nicht die Diagnose – die eigentliche Diagnose beginnt mit der Fehlermeldung im Log.