Sur cette page: [cacher]
Le propre écran de crash de WordPress est un HTTP 500. Il en va de même pour une page blanche vierge. Il en va de même pour la page sans style que votre serveur Web sert lorsqu'il abandonne. Le gestionnaire d’erreurs fatales de Core remet un 500 réponse à wp_die() avant d'imprimer “Il y a eu une erreur critique sur ce site Web.” Le code d'état est identique dans les trois cas, donc ça ne te dit presque rien. Le corps de la page vous en dit long. Qui l'a imprimé réduit la liste des causes environ de moitié, avant de toucher un seul fichier.
Réponse rapide: Lisez ce qui a été rendu, pas le code. Une page WordPress stylisée signifie que PHP a été exécuté, WordPress chargé, puis un plugin ou un thème est mort. Vérifiez la boîte de réception de l'administrateur du site pour un lien de récupération. Une page de serveur nue sans style WordPress signifie que la demande n'est jamais allée aussi loin, alors renommez .htaccess et lisez le journal du serveur. Une page blanche vierge se trouve entre les deux, et le journal de débogage le règle en une minute environ.
Dernière révision: septembre 2026. Constantes, memory defaults and PHP support dates verified against WordPress core documentation and php.net this month.
Trois écrans, Un code de statut
Every guide opens with a list of causes. Corrupt .htaccess, plugin conflict, memory limit, permissions, and so on down the page. That list is accurate and close to useless, because you can’t tell from a status code which entry applies to you. Sorting by what rendered is faster.
A styled WordPress page. Grey background, small centered box, the sentence “Il y a eu une erreur critique sur ce site Web” with a link to a WordPress support page. This is core talking. PHP started, wp-config.php parsed, WordPress booted far enough to register its shutdown handler, and then something threw a fatal error. Almost always a plugin, un thème, or code you pasted into functions.php. Aller à the recovery section.
A bare server page. Times New Roman on white, the words “Erreur Interne du Serveur”, maybe an Apache or LiteSpeed version string at the bottom. Or your host’s own branded error page. WordPress never got a word in. The failure happened in the web server, in the PHP process manager, or in a config file the server read before handing anything to PHP. Start at .htaccess.
Nothing at all. A white page, no text, view-source shows an empty document. PHP died with error display switched off, and either the fatal came before WordPress could install its handler, or the handler itself couldn’t finish. Fatals inside wp-config.php, inside a must-use plugin, or in an opcache-stale file land here. So do out-of-memory kills, because PHP can run out of memory while trying to render the error about running out of memory.
One more screen gets confused with this constantly. “Erreur de connexion à la base de données” is not a 500. C'est WordPress qui rapporte que MySQL l'a refusé, et le correctif réside dans les informations d'identification de votre base de données, pas dans aucun des fichiers ci-dessous.
Ce que ce guide a vérifié, et ce que ça n'a pas fait
Où un numéro apparaît dans ce guide, ça vient de celui qui l'a publié, vérifié en septembre 2026. Les valeurs par défaut de la mémoire et les constantes de débogage proviennent de la documentation principale de WordPress et de la propre référence des fonctions du noyau.. Le comportement de PHP provient du manuel PHP, spécifiquement les pages sur les fichiers INI par répertoire et sur les versions prises en charge. Les emplacements des journaux proviennent de la documentation officielle de chaque panneau de contrôle plutôt que d'un message du forum le citant..
Nous avons volontairement exclu trois choses. Les conseils qui ne fonctionnent que sur un seul hôte sont signalés comme tels plutôt que présentés comme généraux. Les correctifs nécessitant des modifications de la base de données sont disponibles, parce qu'un 500 l'erreur ne vient presque jamais de là et le risque est disproportionné. And any claim we could not trace to a vendor page or to core source was dropped instead of hedged.
The plugin-package failure described later was verified first-hand. We downloaded three release archives from WordPress.org, listed their contents, and compared them against the plugin’s own bootstrap file. Everything else here is documentation work. We did not reproduce each error on a live server, and we did not benchmark anything. We also can’t tell you which cause is statistically most common. Nobody publishes that data, and the guides claiming to know it don’t cite a source.
Confirmez que c'est vraiment un 500
Browsers paper over the difference between server errors. Chrome shows the same unhelpful page for several of them, and a cached copy can show you yesterday’s failure. Vérifiez l'en-tête de réponse réel avant de passer une heure sur le mauvais problème.
Depuis un terminal, exécutez curl -i https://yoursite.com. Utilisez -i et non -I. La capitale envoie une requête HEAD et jette le corps de la page, quelle est la moitié qui vous indique qui a imprimé l'erreur. Dans un navigateur, ouvrir les outils de développement, allez dans l'onglet Réseau, recharger, et cliquez sur la première demande. Quoi qu'il en soit, vous voulez le numéro à trois chiffres, et peu importe celui que vous obtenez:
- 500 signifie que le serveur a essayé et que quelque chose dans votre application est tombé en panne. Presque tout ce qui suit s'applique.
- 502 signifie un proxy devant (généralement NGINX) j'ai reçu une réponse inutile du backend avec lequel il parlait. Souvent un processus PHP-FPM qui plantait ou ne fonctionnait jamais.
- 503 signifie que le serveur est opérationnel et refuse délibérément. Surcharge, un mode maintenance, ou un plafond de ressources atteint par votre plan.
- 504 signifie que le backend a été atteint mais n'a jamais répondu à temps. Une requête lente, un appel d'API externe bloqué, un travail cron mange un travailleur.
La définition est brutale quant à la raison pour laquelle la première est si vague. La référence HTTP de Mozilla décrit 500 comme un fourre-tout générique “indiquant que le serveur ne peut pas trouver une erreur 5XX plus appropriée pour répondre avec”. Un serveur qui savait ce qui n'allait pas l'aurait dit.
Deux choses à exclure dans la même minute. Charger le site dans une fenêtre privée. Un service worker ou un cache agressif servira volontiers une page d'erreur stockée longtemps après la récupération du site. Et essayez le front-end et /wp-admin séparément. Un frontal qui se charge pendant que wp-admin lance 500 points quelque part spécifiques, et on y revient plus bas.
Quand WordPress a imprimé la page
Si vous avez le style “erreur critique” page, WordPress a déjà effectué l'essentiel du travail de diagnostic et a essayé de vous donner la réponse. Depuis la version 5.2, core catches fatal errors and pauses whatever caused them. It then emails the address in Settings, General with a link into recovery mode. Follow that link and the broken plugin stays disabled for your browser session only. You can log in and remove it while visitors keep seeing the error page.
Check that inbox first, spam included. Then know why it so often arrives empty.
The WordPress documentation is candid about the failure mode. Plugins load in order. If the fatal fires before your SMTP plugin loads, the email goes out through the server’s own mail function instead. On a shared IP with no SPF alignment, that message gets filtered or dropped outright. The alert about your broken site is itself broken, by the same crash. You can’t fix that in the moment, but it does explain the missing email. Notre guide pour why WordPress stops sending email covers the deliverability side properly.
Obtenir le vrai message d'erreur
No email means you read the log instead. Two lines in wp-config.php, au-dessus du “arrêter l'édition” comment:
- définir( «WP_DEBUG», vrai );
- définir( «WP_DEBUG_LOG», vrai );
Core writes to wp-content/debug.log par défaut. Reload the broken page once, then open that file and read the last entry. A PHP fatal names the file and the line number, and the folder in that path is your culprit. That’s the whole diagnosis, and it takes longer to describe than to do.
Leave WP_DEBUG_DISPLAY alone while you do it, or set it to false explicitly. Printing errors to the screen on a live site publishes your absolute server paths to anyone reloading the page (and some people go looking for exactly that).
There’s a blunter instrument for the cases where the log stays empty. Adding define( 'WP_DISABLE_FATAL_ERROR_HANDLER', vrai ); éteint complètement le gestionnaire, donc la propre erreur de PHP fait surface au lieu du substitut poli de WordPress. Core vérifie cette constante dans wp_is_fatal_error_handler_enabled(), et l'effet est immédiat. Utilisez-le pendant les trente secondes nécessaires à la lecture du message, puis sors-le. Une fois le gestionnaire parti, vous perdez également le mode de récupération., et chaque visiteur voit l'erreur brute.
Isoler le plugin ou le thème
Vous ne pouvez pas cliquer sur Désactiver sur un tableau de bord auquel vous ne pouvez pas accéder. Alors faites-le depuis le système de fichiers. Vérifications principales file_exists() sur chaque plugin actif avant qu'il ne charge l'un d'entre eux, et ignore silencieusement ceux qui ont disparu.
Par FTP ou via le gestionnaire de fichiers de votre hébergeur, rebaptiser wp-content/plugins aux plugins désactivés. Recharger le site. Si ça revient, tu as trouvé la couche fautive.
Ensuite, faites une chose avant de renommer le dossier, parce que l'ordre compte plus que n'importe quel guide ne l'admet. Chargez d'abord /wp-admin. Ignorer sur le front-end et désactiver dans la base de données sont deux comportements différents, géré par deux fonctions différentes. L'avant saute juste. Seul le côté administrateur exécute validate_active_plugins(), qui appelle deactivate_plugins() et écrit réellement le changement. Renommez le dossier sans visiter le tableau de bord et tous vos plugins sont toujours marqués actifs, celui cassé inclus. Le site meurt à nouveau au moment où vous le faites, et on dirait que le test n'a rien prouvé.
Une fois que le tableau de bord a vu le dossier vide, renommez-le et réactivez les plugins un par un, rechargement après chaque. Celui qui tue encore le site est votre réponse. Même technique pour les thèmes: renommez le dossier du thème actif et WordPress revient à celui par défaut.
Avec SSH, WP-CLI le fait en une seule commande, et ses drapeaux mondiaux sont la partie utile. Exécution du plugin wp désactivé –tout avec –skip-plugins démarre WordPress sans charger de plugins du tout. Le fatal ne tire jamais, donc la commande se termine. Notez la limite documentée: les plugins mu se chargent toujours dans les deux cas. Un fatal dans wp-content/mu-plugins survit aux deux approches, et ce dossier doit être déplacé à la main.
Le mai 2026 cas qui a rendu cela concret
Les erreurs fatales des plugins proviennent généralement d'un conflit, où deux choses qui fonctionnent seules ne fonctionnent pas ensemble. Parfois, le colis lui-même est simplement cassé, et une version de cette année montre clairement le mécanisme.
Codes courts ultimes, un plugin actif sur 400,000 des sites, version livrée 7.5.1 sur 18 Mai 2026 avec le répertoire /freemius/ fourni manquant dans le package. Doubler 31 du fichier principal de cette version toujours appelé require_once sur /freemius/start.php, sans file_exists, vérifiez-le. Nous avons téléchargé les trois archives pour le confirmer. Version 7.5.0 tient 223 fichiers sous ce dossier, 7.5.1 n'en détient aucun, et 7.5.3 restaure 222. L'archive cassée est un mégaoctet plus petit que la version de chaque côté..
Un require_once pointant vers un fichier qui n'existe pas est une erreur fatale. Chaque demande, chaque visiteur, aucune exception. L'auteur a tagué le remplaçant, 7.5.3, le lendemain matin sur 19 Mai 2026. Son entrée dans le journal des modifications est une ligne: “Correction d'un problème avec le dossier /freemius/ manquant”. Versions 7.5.1 et 7.5.2 n'apparaissent plus du tout dans la liste des balises du plugin.
Deux choses en découlent pour quiconque lit un journal en ce moment. Blâmer un conflit est une supposition. Un fatal qui nomme un chemin de fournisseur dans un dossier de plugin n'est généralement pas un conflit. Et si le site mourait juste après une mise à jour automatique, restaurer ce plugin d'une version est un premier pas équitable, pas un dernier recours. L'objet cassé a peut-être déjà été retiré.
Le correctif .htaccess, et celui qui se retourne contre lui
Ce fichier est le premier suspect lorsque le serveur a imprimé la page d'erreur, parce qu'Apache le lit avant que PHP ne soit impliqué. Une directive invalide renvoie 500 pour chaque requête vers ce répertoire et tout ce qu'il contient.
La réparation est un changement de nom, pas une modification. Par FTP, renommez .htaccess dans votre racine WordPress en htaccess-old et rechargez. Retour du site? Le fichier était le problème. Allez dans Paramètres, Permaliens dans le tableau de bord et cliquez sur Enregistrer les modifications sans rien modifier, et WordPress écrit un bloc de réécriture propre. Site toujours en panne? Renommez-le et continuez, parce que tu l'as éliminé.
Maintenant, la partie qui fait trébucher les gens. La plupart des guides d'erreur 500 vous demandent d'augmenter votre limite de mémoire en ajoutant une ligne comme php_value memory_limit 256M à .htaccess. Sur beaucoup d'hébergement dans 2026, cette ligne est lui-même le 500.
Voici le mécanisme. php_value est une directive fournie par mod_php, l'ancien modèle où PHP s'exécute dans le processus Apache. Les hôtes sont largement passés à PHP-FPM ou FastCGI, où PHP s'exécute comme un pool séparé et mod_php n'est pas chargé. Apache répond à une directive qu'aucun module chargé ne reconnaît, refuse de servir l'annuaire, et revient 500. Le manuel PHP indique clairement la division. Fichiers INI par répertoire “sont traités uniquement par le SAPI CGI/FastCGI”, et les utilisateurs du module Apache sont pointés vers .htaccess pour le même effet. Deux mécanismes, et vous avez besoin de celui que votre hôte exécute réellement.
Alors lequel as-tu? La découverte prend un seul fichier, et presque aucun guide ne vous dit de regarder. Déposez un fichier appelé check.php à la racine de votre site Web, contenant un appel à phpinfo(). Chargez-le dans un navigateur et lisez le API du serveur ligne vers le haut.
“Apache 2.0 Gestionnaire” est mod_php, donc php_value fonctionne. “FPM/FastCGI” ou “CGI/FastCGI” ça veut dire que non. “LiteSpeed V” est celui qui est ambigu. Cette même chaîne couvre LiteSpeed Enterprise, qui honore php_value, et OpenLiteSpeed, qui prend les règles de réécriture de .htaccess et ignore le reste. Soit sur, ignorez la question et utilisez .user.ini. Puis supprimez check.php, parce que phpinfo() remet toute la configuration de votre serveur à quiconque devine l'URL. Et si check.php lance un 500 ainsi que, votre .htaccess est toujours cassé et vous ne l'avez pas encore renommé.
Sur FPM ou FastCGI, le fichier équivalent est .utilisateur.ini, placé à la racine de votre WordPress, contenant memory_limit = 256M et rien d'autre. Un piège documenté l'accompagne, et ça fait perdre beaucoup de temps. PHP met en cache ces fichiers pour 300 secondes par défaut, défini par user_ini.cache_ttl. Enregistrez le fichier, recharger immédiatement, je ne vois aucun changement, et il semble que le correctif ait échoué. Ce n'est pas le cas. Attends cinq minutes.
Deux pièges liés vivent dans le même fichier. Toute règle copiée à partir d'un didacticiel faisant référence à un module que votre serveur ne charge pas fait exactement ce que fait php_value. Le contrevenant habituel est une ligne SecFilterEngine, collé pour désactiver un pare-feu. Sur NGINX, entre-temps, rien de tout cela ne s'applique. NGINX n'a pas de mécanisme .htaccess, donc le fichier reste là, ignoré et ne peut pas être votre cause. LiteSpeed et OpenLiteSpeed le lisent, c'est pourquoi “vérifiez .htaccess” reste de bons conseils sur la plupart des hébergements mutualisés.
Limites de mémoire: Les vrais chiffres
Les valeurs par défaut sont inférieures à ce que la plupart des gens pensent, and knowing them saves you from raising a limit that was never the constraint.
WordPress sets WP_MEMORY_LIMIT to 40M sur un seul site, and 64M on multisite. It lifts the admin side to WP_MAX_MEMORY_LIMIT of 256M for heavier jobs like media handling and core updates. The core documentation adds the qualifier that matters. WordPress checks what PHP has been allocated first, and it can only request within that. If your host caps PHP at 128M, setting 512M in wp-config.php changes nothing.
That asymmetry between 40M and 256M also explains one common symptom directly. A site whose front end loads fine but whose dashboard throws 500 is often a site sitting between the two limits.
To test it, add define( «WP_MEMORY_LIMIT», «256 M’ ); to wp-config.php and reload. Si l'erreur disparaît, treat that as a diagnosis and not a repair. Something in your stack is using six times the default to render one page. The honest next step is finding out what. Otherwise the next plugin you install pushes you over the new ceiling too.
Autorisations de fichiers et à qui appartiennent vos fichiers
Permission errors produce 500s reliably. They turn up most often after a migration or a restored backup, when files arrive owned by the wrong user.
The safe values are 755 pour les répertoires, 644 pour les fichiers. Set wp-config.php to 640 ou 600 if your host allows it. And don’t reach for 777 because a tutorial promised it would fix an upload problem.
Si 777 actually returns a 500 depends on your handler, and most advice on this point is about a decade out of date. suPHP refuses to run anything group-writable or world-writable, and it announces itself in the log with a distinctive string: SoftException in Application.cpp. Le suEXEC d'Apache applique une règle similaire aux programmes CGI. Il vérifie que la cible est “NON inscriptible par quelqu'un d'autre”, et que le propriétaire du fichier correspond à l'utilisateur sous lequel il s'exécute. PHP-FPM n'a pas un tel refus, et cPanel le recommande désormais à la place de suPHP. Donc sur une pile actuelle, 777 est un problème de sécurité plutôt que la cause de votre 500. Recherchez dans le journal des erreurs cette chaîne SoftException avant de passer une heure sur chmod.
La propriété compte autant que le mode. Chaque fichier sous votre racine Web doit appartenir à l'utilisateur de votre compte d'hébergement. Ne pas rooter, et non à l'utilisateur du serveur Web. Si un correctif d'autorisation ne prend pas et que vous êtes sur un hébergement partagé, ouvrez un ticket ici. La correction de la propriété nécessite un accès que votre compte n'a pas.
Sauts de version PHP
Un site qui s’est arrêté du jour au lendemain sans que rien n’ait changé de votre côté a souvent été modifié du côté de votre hébergeur. Les dates de fin de vie de PHP déterminent les mises à niveau planifiées, et un plugin qui n'a pas été mis à jour depuis trois ans répond à une syntaxe qui n'existe plus.
Les dates proviennent directement du tableau des versions prises en charge de php.net. PHP 8.1 a cessé de recevoir des correctifs de sécurité sur 31 décembre 2025. PHP 8.2 est uniquement axé sur la sécurité depuis la fin de 2024, avec sa propre coupure 31 décembre 2026. PHP 8.3 fait passer les correctifs 2027, 8.4 à travers 2028, et 8.5, libéré 20 novembre 2025, à travers 2029.
WordPress lui-même est resté immobile pendant que PHP a déménagé. WordPress 7.0 “Armstrong” expédié le 20 Mai 2026 et 7.1 “Marie Lou” sur 19 août 2026, et ni l'un ni l'autre n'a élevé le plancher PHP au-dessus 7.4. La recommandation est toujours PHP 8.3 Ou plus récent. Cet écart est le piège. WordPress fonctionne parfaitement sur une version PHP qui a cessé de recevoir des correctifs de sécurité il y a des années. Rien dans votre tableau de bord ne vous prévient, jusqu'à ce qu'une mise à niveau côté hôte force le problème.
Si votre panneau de contrôle vous permet de changer de version de PHP, retirer une version mineure est un test rapide. Il confirme la cause en moins d'une minute. Considérez la restauration comme temporaire, bien que. Vous utilisez maintenant un ancien PHP pour prendre en charge le code qui doit être remplacé. Notre guide du WordPress “nécessite une version PHP plus récente” avertissement explique comment trouver quelle extension vous retient.
Quand c'est le serveur, Pas votre site
Certains 500 ne vous appartiennent pas, et les repérer tôt vous évite de renommer des dossiers qui n'ont jamais été un problème.
Une règle de pare-feu échoue. ModSecurity renvoie généralement 403 quand ça bloque quelque chose. Deux cas reviennent 500 au lieu. Une règle qui échoue lors du traitement de la demande, ou une ligne .htaccess écrite pour désactiver le pare-feu là où cela n'est pas autorisé. Le tell est dans le journal des erreurs du serveur, où les requêtes bloquées portent un identifiant de règle entre crochets. Vous ne pouvez pas régler ces règles à partir d'un compte partagé, donc celui-ci va au support avec la ligne de journal attachée.
Un pool de processus PHP décédé. Plus souvent un 502 qu'un 500, mais cela vaut la peine de vérifier quand les erreurs vont et viennent sous charge plutôt qu'à chaque demande. Les pannes intermittentes liées au trafic constituent un problème de ressources, pas un problème de code, et aucun renommage de plugin ne les touche.
Quota de disque. Un compte complet empêche PHP d'écrire les données de session, fichiers temporaires ou son propre journal, et ces échecs apparaissent comme un 500. Si le site allait bien il y a une heure, vérifiez votre chiffre d'utilisation dans le panneau de contrôle avant toute autre chose.
Où se trouve réellement votre journal d’erreurs
Le journal de débogage WordPress enregistre les erreurs PHP dans WordPress. Il n'enregistre pas les erreurs de syntaxe .htaccess, refus d'autorisation ou blocage du pare-feu, parce que cela se produit avant que PHP ne s'exécute. For those you need the server log, and each panel puts it somewhere different:
- cPanel: the Errors interface under Metrics. cPanel’s own documentation describes it as showing up to 300 of the most recent entries, newest first. Many configurations also drop an error_log file directly in public_html.
- Hostinger hPanel: Gestionnaire de fichiers, then the .logs directory in your account root, holding a file named error_log_ plus your domain. PHP errors only, so server-level failures won’t appear there.
- SiteGround Site Tools: Statistiques, then Error Log for recent server-detected errors, with a php_errorlog file in the site root for PHP-level ones.
- Cloudways: the logs folder inside your application directory, reachable over SSH or SFTP, with separate Apache, NGINX and PHP files.
- Plain VPS: /var/log/apache2/error.log on Debian and Ubuntu, /var/log/httpd/error_log on RHEL-family systems, /var/log/nginx/error.log pour NGINX.
Deux lignes de journal Apache valent la peine d'être reconnues à vue. “Fin prématurée des en-têtes de script” et “Fin de la sortie du script avant les en-têtes” ça veut dire la même chose. Le script s'est arrêté avant de renvoyer tout ce que le serveur pourrait utiliser. C'est un processus PHP qui est mort au milieu de la requête, ce qui vous ramène du côté PHP plutôt que du côté configuration.
Quel correctif essayer en premier
En appliquant chaque méthode ci-dessus dans l'ordre, voici comment un problème de quinze minutes devient un après-midi.. Ce que tu as fait en dernier, et ce qui fonctionne encore, le réduit plus rapidement que n'importe quelle liste de contrôle.
Quelque chose a changé, et tu sais quoi. Mise à jour d'un plugin, fonctions.php modifiées, collé un extrait, thème changé. Annulez cette chose, et rien d'autre. Si c'était une mise à jour automatique, vérifiez si la version que vous utilisez existe toujours sur WordPress.org avant de la déboguer. Une version retirée n'est pas votre bug à résoudre.
Rien n'a changé, and it broke overnight. This is host-side until proven otherwise. Check your PHP version first, then your disk quota, then the server error log. A scheduled PHP upgrade or a hit resource cap explains most of these, and neither leaves a trace in wp-content/debug.log.
Only /wp-admin throws 500. The front end loads fine, so memory is the first candidate, given core’s own 40M against 256M split. Second is a corrupted file in wp-admin or wp-includes. A clean core reinstall fixes that without touching your content. Replace those two directories from a fresh WordPress download, and leave wp-content and wp-config.php exactly where they are.
A browser and nothing else. No FTP, pas de SSH, pas de gestionnaire de fichiers. Your host’s control panel almost certainly has a file manager, so start there. Si ce n'est pas le cas, the sequence is: check the inbox for a recovery link, puis enregistrez un ticket avec l'heure exacte du premier échec. L'assistance peut lire les journaux, ce que vous ne pouvez pas faire.
Ça va et vient. Les 500 sous trafic intermittents constituent un problème de capacité. Renommer les dossiers du plugin n'aidera pas, et une mémoire constante non plus. La limite que vous atteignez appartient au compte, pas à la demande. Soit le site nécessite moins de pièces mobiles, soit le plan nécessite plus de marge.. C'est ici que hébergement WordPress géré cesse d'être un luxe, puisque les plafonds de ressources et les mises à niveau PHP sont gérés pour vous plutôt que annoncés.
L'empêcher de revenir
La plupart des répétitions de 500 correspondent à une seule habitude: mise à jour en direct, tout à coup, sans aucun retour. Une réparation qui coûte pas cher.
Mettre à jour par petits lots et recharger le site entre eux. Dix plugins mis à jour ensemble vous donnent dix suspects et aucune information. Effectuez une sauvegarde avant tout ce qui touche au cœur ou à un plugin profondément intégré. Confirmez ensuite que vous pouvez le restaurer, parce qu'une sauvegarde non testée est une hypothèse sur l'avenir.
Définir l'e-mail de l'administrateur sur une boîte aux lettres que quelqu'un lit. Le mode de récupération ne sert à rien si le lien atterrit dans une boîte de réception abandonnée. Conservez PHP sur une version qui reçoit toujours des correctifs de sécurité. Dès septembre 2026 qui comprend techniquement 8.2, mais seulement jusqu'à 31 décembre, donc 8.3 ou plus récent est celui sur lequel il faut être. Considérez l'avis de mise à niveau d'un hôte comme une date limite de test, pas une annonce à classer. Et si un plugin trône au centre de votre site, vérifiez son historique de publication de temps en temps. Celui qui expédie un colis cassé une fois a tendance à le faire à nouveau.
La mise en scène est la vraie réponse, et de nombreux forfaits partagés l'incluent désormais au lieu de le réserver aux niveaux coûteux. Un clic pour copier le site, casser la copie, et laissez la version live tranquille. If your plan doesn’t have it, that’s worth weighing against price the next time you renew.
Questions fréquemment posées
Qu'est-ce qui cause un 500 erreur de serveur interne tout d'un coup?
Quelque chose a changé, even if you didn’t change it. On your side, that’s usually a plugin or theme update, an edit to functions.php, or a snippet pasted into wp-config.php. On your host’s side, it’s a PHP version upgrade, a hit resource cap, or a full disk. If you genuinely changed nothing, check your PHP version and your disk usage before you start renaming folders.
Puis-je réparer un 500 erreur de serveur interne moi-même, ou ai-je besoin de mon hôte?
La plupart d'entre eux, Oui. Renaming .htaccess, renaming the plugins folder, raising the memory limit and fixing file permissions all work over FTP or a file manager. Three cases need your host. File ownership problems, ModSecurity rules firing on your requests, and PHP-FPM pools that keep dying. Each needs access your account doesn’t have. Send support the exact time of the failure, plus the log line if you have one.
Pourquoi est-ce que je reçois un 500 erreur uniquement dans wp-admin lorsque le front-end fonctionne?
Usually memory. WordPress allows 40M by default on the front end, and raises it to 256M for admin tasks. A dashboard that dies while the site loads is often sitting between those two figures, on a plan that can’t reach the higher one. The other common cause is a corrupted file in wp-admin or wp-includes. Fix that by replacing both directories from a fresh WordPress download, leaving wp-content and wp-config.php alone.
Est-ce un 500 erreur la même que 502, 503 ou 504?
Non, and the difference tells you who fixes it. UNE 500 means the application broke, so it’s usually yours. UNE 502 means a proxy got an invalid response from the backend, typically a dead PHP-FPM process. UNE 503 means the server is refusing requests deliberately, through overload or a maintenance mode. UNE 504 means the backend never answered in time. The last three point at infrastructure, so they go to your host with the timestamp attached.
Comment puis-je réparer un 500 erreur si je ne parviens pas du tout à me connecter à WordPress?
You don’t need the dashboard for any of the main fixes. Renaming .htaccess and renaming wp-content/plugins both work over FTP or a hosting file manager. WordPress skips plugins whose folders have disappeared, though you have to load /wp-admin once to make that stick in the database. Avec SSH, wp plugin deactivate –all plus the –skip-plugins flag boots WordPress without loading plugins, so the fatal never fires. If the crash happens only at the login screen rather than site-wide, the cookie and lockout causes are a separate list.
Est-ce qu'un 500 une erreur de serveur interne a nui à mon classement Google?
A short one won’t. Google’s own crawling documentation says 5xx errors make its crawlers “temporarily slow down with crawling”. Il indique également que les URL déjà indexées sont conservées, puis “finalement abandonné” si l'erreur persiste. Donc les heures, c'est bien, et les jours ne sont pas. Corrigez-le le même jour et vous ne verrez presque certainement aucun effet de classement. Le coût réel d'une panne est la perte de trafic et la perte de confiance, pas de pénalité durable par la suite.
Combien de temps faut-il pour réparer un 500 Erreur?
S'il s'agit de .htaccess ou d'un seul plugin, dix minutes, et la majeure partie attend FTP. S'il s'agit d'un plafond de mémoire ou d'une incompatibilité de version PHP, une heure ou deux, puisque vous testez plutôt que de simplement revenir en arrière. Si c'est la propriété, une règle de pare-feu ou un pool de processus en voie de disparition, cela prend autant de temps que la file d'attente des tickets de votre hôte. C’est le véritable argument pour identifier lequel des trois vous avez avant de commencer.
La version courte
Regardez la page avant de consulter une liste de contrôle. Une erreur WordPress de style signifie que le crash s'est produit dans WordPress, alors vérifiez la boîte de réception de l'administrateur pour un lien de récupération, puis lisez wp-content/debug.log. Une page de serveur nue signifie que le crash s'est produit avant le chargement de WordPress, alors renommez .htaccess, puis vérifiez que les répertoires sont 755 et les fichiers sont 644. Une page vierge signifie que désactiver le gestionnaire d'erreurs fatales pendant trente secondes vous dira ce que PHP a réellement vu.
Alors résistez à la solution que tout le monde recommande sans réserve. L'ajout de php_value memory_limit à .htaccess est un correctif fonctionnel sur mod_php et un instant 500 est PHP-FPM, et le propre manuel de PHP indique lequel est lequel. Si votre hôte exécute FPM, le fichier est .user.ini, et il est mis en cache pendant cinq minutes avant que votre modification ne fasse quoi que ce soit.
J'ai atterri ici à partir d'un symptôme différent? Deux problèmes voisins ont leurs propres guides. “Brièvement indisponible pour la maintenance programmée” est une mise à jour bloquée plutôt qu'un crash, et ça s'efface au bout de dix minutes. Un crash qui ne touche que l'écran de connexion est encore un problème différent, avec des causes de cookie et de verrouillage qui ne touchent jamais .htaccess.