Erreur 500, 502, 503 ou 504 sur votre site : comprendre et corriger sur un hébergement Plesk

Erreur 500 site web : ce que disent les codes 500, 502, 503 et 504

Une erreur 500 site web signifie que le serveur a reçu la demande du visiteur, a tenté d’y répondre et a échoué. Les codes 502, 503 et 504 appartiennent à la même famille : le problème est côté serveur, pas côté navigateur. Vider le cache de Chrome ne change rien. Ce qui change tout, c’est de savoir quel composant a renvoyé le code, car chaque code désigne un coupable différent.

Sur un hébergement web mutualisé NovaHoster, une page passe par trois étages : nginx reçoit la requête, la transmet à Apache, qui la confie à PHP-FPM pour exécuter WordPress, PrestaShop ou votre application. Le code indique à quel étage la chaîne s’est rompue.

Règle de lecture : 500 pointe presque toujours vers votre code ou votre configuration, 503 vers un manque de ressources ou une maintenance, 502 et 504 vers un traitement trop lent ou un processus PHP qui a cessé de répondre.

Tableau de dépannage : code, causes probables, vérification, correction

Ce tableau résume les situations que le support NovaHoster rencontre le plus souvent sur un hébergement mutualisé Plesk. Partez du code affiché et vérifiez les causes dans l’ordre.

Erreur 500 : les causes les plus fréquentes sur un hébergement Plesk

Le vrai message d’une erreur 500 est écrit dans le journal d’erreurs. Avant toute manipulation, ouvrez les Journaux de Plesk et notez la dernière ligne contenant error ou Fatal : elle désigne le fichier fautif dans la plupart des cas.

Le fichier .htaccess invalide

Cause numéro un après une intervention humaine : une règle de redirection copiée depuis un forum, une extension de cache qui écrit ses directives. Apache refuse alors de servir tout le site. Renommez .htaccess en .htaccess.old dans le Gestionnaire de fichiers. Si le site revient, remettez le fichier et supprimez les blocs un par un.

Une extension, un thème ou un module en erreur

Après une mise à jour, une extension peut appeler une fonction qui n’existe plus. Le journal nomme le fichier : wp-content/plugins/… sous WordPress, modules/… sous PrestaShop. Renommer le dossier suffit à désactiver l’élément, même sans accès à l’administration.

Une version de PHP incompatible

Un site écrit pour PHP 7.4 et basculé en PHP 8.3 sans test produit des erreurs fatales dès la première page ; à l’inverse, un thème récent peut exiger PHP 8.1. Le guide sur la faille PHP2Shell explique comment changer la version dans Plesk et quelles versions chaque CMS accepte. Ne redescendez vers une branche ancienne que le temps de corriger le code : elle ne reçoit plus de correctifs de sécurité.

La limite mémoire PHP

Le message Allowed memory size of 134217728 bytes exhausted signifie que le script a dépassé 128 Mo. Augmenter memory_limit dans Paramètres PHP règle le symptôme. La cause est souvent une extension d’import, une galerie qui redimensionne des images trop grandes ou un constructeur de pages lourd.

Erreur 503 service unavailable : ressources, maintenance ou robot

Une erreur 503 service unavailable ne dit pas que votre site est cassé, mais qu’à cet instant personne n’est disponible pour servir la page. Trois situations couvrent la quasi-totalité des cas en mutualisé.

Une limite LVE atteinte avec CloudLinux

Chaque compte NovaHoster dispose d’une enveloppe de processeur, de mémoire, d’entrées-sorties et de processus simultanés. Quand une limite est atteinte, les requêtes sont mises en attente puis refusées. Le guide CloudLinux, LVE et CageFS détaille les symptômes, dont le code 508 propre à la limite de processus entrants. Dans Plesk, les Statistiques affichent l’utilisation des ressources ; une courbe au plafond pendant plusieurs minutes confirme le diagnostic. Cherchez ensuite ce qui consomme : tâche planifiée trop fréquente, extension de statistiques, recherche interne sans index, ou robot.

Une maintenance ou une mise à jour en cours

WordPress crée un fichier .maintenance pendant chaque mise à jour et affiche « Brièvement indisponible pour une opération de maintenance planifiée ». Si la mise à jour est interrompue, le fichier reste et le site répond 503 indéfiniment : supprimez-le. PrestaShop et WordPress Toolkit ont aussi un mode maintenance explicite ; vérifiez qu’il n’est pas resté actif.

Une attaque ou un robot trop insistant

Un robot qui parcourt chaque page du catalogue avec tous les filtres, ou qui teste des mots de passe sur wp-login.php, consomme votre enveloppe à votre place. Le journal d’accès le montre : une même adresse IP, des centaines de lignes par minute. Imunify360 bloque les comportements les plus agressifs ; un blocage ciblé dans .htaccess ou un robots.txt strict reste de votre ressort.

Erreur 502 bad gateway et erreur 504 gateway timeout : quand PHP ne répond plus

Ces deux codes sont émis par nginx, en façade. Avec une erreur 502 bad gateway, le processus PHP a fermé la connexion brutalement : il a planté, a été tué faute de mémoire, ou PHP-FPM n’avait plus de processus libre. Avec une erreur 504 gateway timeout, le processus est vivant mais n’a pas répondu dans le délai imparti, souvent 60 secondes.

• Un script trop long : export comptable, import de catalogue, régénération de miniatures. Lancez ces tâches en tâche planifiée plutôt que depuis le navigateur.
• Une requête SQL lente : table sans index, extension de statistiques qui agrège des mois de données à chaque affichage.
• Un appel externe qui ne répond pas : passerelle de paiement, API de transporteur, vérification de licence d’un thème. Le script attend, le visiteur attend, nginx abandonne.
• PHP-FPM saturé : trop de visiteurs ou de robots simultanés pour le nombre de processus de votre offre. Les Statistiques montrent alors un pic de processus.

Une 502 isolée sur une page d’administration lourde n’est pas inquiétante. Des 502 répétées sur la page d’accueil demandent une analyse immédiate des journaux. Sur un site à fort trafic, l’infogérance serveur NovaHoster prend en charge ce suivi : surveillance, alertes et intervention sur incident.

Où regarder dans Plesk : Journaux, Paramètres PHP et Statistiques

Trois écrans suffisent au diagnostic, tous accessibles depuis la carte de votre domaine dans « Sites Web & Domaines ».

1. Journaux. Filtrez sur « Apache error », « nginx error » et « PHP error » et lisez de bas en haut : la dernière ligne correspond à votre dernier rechargement. Un Fatal error nomme le fichier et la ligne ; un Invalid command désigne le .htaccess ; un upstream timed out confirme une 504. Le guide pour lire les logs et diagnostiquer une application en production décrit la méthode de lecture et de corrélation des événements ; nous ne la répétons pas ici.
2. Paramètres PHP. Vous y choisissez la version de PHP et les directives memory_limit, max_execution_time, upload_max_filesize, display_errors, log_errors et error_reporting. Chaque changement s’applique en quelques secondes.
3. Statistiques et utilisation des ressources. Consommation de processeur, de mémoire, d’entrées-sorties et de processus, face aux limites de votre offre. Premier endroit où regarder en cas de 503 ou de lenteur générale.

Si aucune ligne n’apparaît alors que la page renvoie 500, c’est souvent que log_errors est désactivé ou que le CMS intercepte l’erreur. La section suivante explique comment la faire apparaître.

Activer temporairement l’affichage des erreurs, sans l’oublier

Afficher les erreurs accélère le diagnostic, mais expose des chemins de fichiers, des noms de tables et parfois des identifiants à tous les visiteurs. On l’active pour une session de travail, on le désactive avant de fermer l’onglet.

Dans Plesk, pour tout le domaine

1. Ouvrez Paramètres PHP du domaine.
2. Passez display_errors et log_errors sur on.
3. Réglez error_reporting sur E_ALL pour voir aussi les avertissements.
4. Rechargez la page en erreur : le message apparaît en haut de page ou dans le journal PHP.
5. Cause trouvée : repassez display_errors sur off. Laissez log_errors actif, il n’expose rien.

Dans WordPress

Ajoutez dans wp-config.php, avant la ligne « C’est tout, ne touchez plus à rien » :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Les erreurs s’écrivent dans wp-content/debug.log sans s’afficher aux visiteurs. Revenez à false une fois le problème réglé et supprimez debug.log, lisible par n’importe qui.

Dans PrestaShop

Dans config/defines.inc.php, passez _PS_MODE_DEV_ à true. La page blanche laisse place au message complet. Remettez false dès que possible : en mode développeur, la boutique est plus lente et affiche ses erreurs à vos clients.

Page blanche WordPress : la procédure en 10 étapes

Une page blanche WordPress est une erreur 500 que le CMS n’a pas réussi à habiller. Depuis WordPress 5.2, le message « Il y a eu une erreur critique sur ce site web » la remplace souvent, et un e-mail de récupération part vers l’adresse de l’administrateur. Sur un hébergement WordPress NovaHoster, WordPress Toolkit dans Plesk permet d’exécuter les étapes 5 à 7 sans toucher aux fichiers.

1. Vérifiez votre boîte e-mail. Le lien de récupération ouvre l’administration avec l’élément fautif désactivé et le nomme.
2. Lisez le journal. Journaux, filtre « PHP error » : notez le fichier cité dans la dernière ligne Fatal error.
3. Testez le .htaccess. Renommez-le. Si le site revient, recréez-le depuis Réglages, Permaliens, en enregistrant sans rien changer.
4. Vérifiez la mémoire. En cas de memory exhausted, montez memory_limit dans Paramètres PHP et ajoutez define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php.
5. Désactivez l’extension citée en renommant son dossier dans wp-content/plugins/, ou depuis WordPress Toolkit.
6. Si aucune extension n’est citée, désactivez-les toutes en renommant wp-content/plugins/ en plugins.off. Si le site revient, remettez le nom et réactivez-les une par une.
7. Basculez sur un thème par défaut en renommant le dossier du thème actif : WordPress retombe sur un thème Twenty installé.
8. Vérifiez la version de PHP face aux exigences du thème et des extensions mises à jour récemment.
9. Vérifiez la base de données dans phpMyAdmin avec les identifiants de wp-config.php ; réparez les tables marquées corrompues.
10. Réinstallez le cœur via la vérification d’intégrité de WordPress Toolkit, sans toucher à wp-content ni à la base, ou restaurez la sauvegarde de la veille.

Notez chaque étape et son résultat : si vous contactez le support, ce compte rendu lui fera gagner une heure.

Erreur 500 PrestaShop : cache, modules et version de PHP

Une erreur 500 PrestaShop a trois origines récurrentes : un cache obsolète après une mise à jour ou une migration, un module incompatible, et une version de PHP hors de la plage acceptée par votre version de PrestaShop.

1. Videz le cache manuellement. Sur PrestaShop 1.7, 8 et 9, supprimez le contenu de var/cache/prod/ et var/cache/dev/. Sur 1.6, supprimez cache/class_index.php et le contenu de cache/smarty/compile/. La première page sera lente, le temps de la régénération.
2. Activez le mode développeur comme décrit plus haut et lisez le message : il cite presque toujours un module ou une classe.
3. Désactivez le module fautif en renommant son dossier dans modules/, puis mettez-le à jour ou remplacez-le.
4. Vérifiez la version de PHP. Le guide sur la faille PHP2Shell donne la correspondance entre versions de PrestaShop et de PHP. Un décalage se traduit par une page blanche dès l’accueil ou dès l’administration.
5. Contrôlez les droits des fichiers. Après une migration, des dossiers var/, img/ ou upload/ non inscriptibles produisent une 500 à la génération des miniatures ou des factures. Fichiers en 644, dossiers en 755.
6. Vérifiez la base de données. Link to database cannot be established signifie que les identifiants de app/config/parameters.php (ou config/settings.inc.php sur 1.6) sont faux, ou que la base est hors ligne.

Une boutique qui renvoie des 503 ou des 504 à chaque pic de commandes a un problème de ressources, pas de code : faites analyser les requêtes lentes, puis envisagez une offre e-commerce avec ressources garanties.

Restaurer une sauvegarde quand la correction tarde

Un site en erreur pendant deux heures coûte moins cher qu’une correction improvisée qui aggrave la situation. Une fois les causes simples écartées (.htaccess, fichier .maintenance, extension citée par le journal), la restauration de la dernière sauvegarde saine est souvent le chemin le plus court.

Dans Plesk, le Gestionnaire de sauvegardes liste les sauvegardes quotidiennes de votre abonnement ; vous pouvez restaurer l’ensemble, les fichiers seuls ou la base seule. Le guide pour sauvegarder, migrer et restaurer un site hébergé chez NovaHoster détaille chaque option. Quelques règles avant de cliquer :

• Choisissez une sauvegarde d’avant l’apparition de l’erreur, pas d’avant votre dernière tentative de correction.
• Sur une boutique, ne restaurez pas la base seule sans mesurer les commandes perdues entre-temps. Restaurer les fichiers seuls suffit souvent quand l’erreur vient d’un module ou d’une mise à jour.
• Sauvegardez l’état actuel avant de restaurer, même cassé.
• Rejouez ensuite la mise à jour fautive sur une copie de test, par exemple le staging en un clic de l’offre WordPress.

Si l’erreur vient d’un piratage, la restauration ne suffit pas : la porte d’entrée est encore ouverte. Une sauvegarde automatique hors hébergement conserve une copie quotidienne hors du serveur et permet de remonter plus loin qu’une sauvegarde locale, jusqu’à un état antérieur à l’intrusion.

Quand contacter le support, quoi envoyer, et liste de contrôle finale

Contactez le support NovaHoster, par livechat ou par ticket, dès que l’erreur touche plusieurs sites de votre abonnement, que les Statistiques sont normales mais que le site renvoie 502 ou 503, qu’aucune ligne n’apparaît dans les journaux malgré log_errors actif, ou que vous soupçonnez une attaque. Dans ces cas, la cause peut être côté serveur. Le guide pour ouvrir une demande de support qui sera traitée efficacement explique comment rédiger la demande ; pour une erreur 500 à 504, joignez :

• le nom de domaine et l’URL exacte en erreur ;
• le code, l’heure de la première apparition et la fréquence (permanent, intermittent, heures de pointe) ;
• les cinq à dix dernières lignes du journal concerné, copiées telles quelles ;
• vos modifications des 48 dernières heures : mise à jour, extension, version de PHP, migration, DNS ;
• les tests déjà effectués et leur résultat ;
• jamais de mot de passe ni d’identifiant de base de données.

Liste de contrôle

• J’ai identifié le code exact et noté l’heure.
• J’ai lu la dernière ligne des journaux Apache, nginx et PHP.
• J’ai vérifié les Statistiques de ressources du compte.
• J’ai testé le site sans .htaccess.
• J’ai cherché un fichier .maintenance ou un mode maintenance actif.
• J’ai désactivé l’élément cité par le journal.
• J’ai vérifié la version de PHP et memory_limit.
• J’ai vérifié que la base de données répond.
• J’ai désactivé l’affichage des erreurs et supprimé les fichiers de débogage.
• J’ai noté la cause et la correction, et sauvegardé l’état sain.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

• Administrer un abonnement Plesk sans interrompre son site — Découvrez une méthode fiable pour administrer un abonnement Plesk, modifier les réglages d’un domaine et limiter les risques avant chaque…
• Déployer un site avec Git dans Plesk et dépanner les erreurs courantes — Configurez un dépôt Git distant dans Plesk, choisissez le mode de déploiement et diagnostiquez les erreurs de clonage, webhook, publication…
• Se connecter à Plesk et retrouver les principaux réglages d’un site — Apprenez à accéder à Plesk, sélectionner le bon abonnement et retrouver les réglages essentiels de votre domaine avec une méthode sûre et…
• Changer d’hébergeur WordPress sans perdre son référencement : la méthode complète, phase par phase — Changer d’hébergeur WordPress sans perdre son référencement : préparation, copie, test, bascule DNS avec TTL abaissé, vérifications SEO et…
• Combien coûte un hébergement web en France en 2026 : grille de prix réaliste et coûts cachés — Prix hébergement web en France en 2026 : budget annuel HT par profil de site, prix d’appel, options facturées, TVA et liste de contrôle…

Sources techniques

[1] MDN Web Docs — 500 Internal Server Error [2] MDN Web Docs — 502 Bad Gateway [3] MDN Web Docs — 503 Service Unavailable [4] MDN Web Docs — 504 Gateway Timeout [5] Plesk — Guide de l’utilisateur Obsidian : Fichiers log [6] Plesk — Customer Guide Obsidian: Backing Up and Restoring Data