WordPress · Panne · Erreur 500 · Maintenance · Diagnostic
Réponse rapide
Quand un site WordPress ne répond plus, le message affiché indique où chercher : une erreur 500 renvoie au journal d’erreurs du serveur, une « erreur critique » à l’e-mail envoyé à l’administrateur du site, une erreur de connexion à la base de données à l’hébergeur et au fichier wp-config.php, une maintenance qui ne finit pas à une mise à jour interrompue. Une erreur d’affichage ne supprime rien par elle-même. Notez le message exact, sauvegardez, lisez les journaux, puis changez une seule chose à la fois.
Il y a un moment désagréable, entre le constat et la première action, où l’on ne sait pas encore si c’est grave. Le site ne s’affiche plus. Peut-être une page blanche, peut-être un message en anglais, peut-être une phrase qui parle d’erreur critique.
Le vrai risque n’est pas la panne. C’est ce qu’on fait dans les dix minutes qui suivent.
Cet article est organisé par ce que vous voyez à l’écran, parce que c’est la seule information dont vous disposez au départ.
1. Constater
↓
2. Sauvegarder
↓
3. Lire
↓
4. Agir
Ce que vous voyez, et ce que cela veut dire
| Ce qui s’affiche | Ce que cela signifie | Première action sûre |
|---|---|---|
| Page blanche, aucun message | une erreur PHP ou de base de données, sans affichage du détail | chercher un e-mail de WordPress, puis le journal d’erreurs |
| « Internal Server Error » / erreur 500 | le serveur n’a pas pu aboutir ; les causes possibles sont nombreuses | lire le journal d’erreurs du serveur avant toute manipulation |
| Message d’« erreur critique » sur le site | WordPress a intercepté une erreur fatale | ouvrir la boîte mail de l’administrateur du site |
| Erreur de connexion à la base de données | WordPress ne joint pas sa base | vérifier d’abord l’état de l’hébergement |
| Un message de maintenance qui ne disparaît pas | une mise à jour s’est interrompue | voir la section dédiée plus bas |
| 403 / accès refusé | le serveur refuse de servir la page | se demander ce qui a changé juste avant |
L’erreur 500 WordPress : celle qui ne dit rien
« Internal Server Error » est, dans la documentation de WordPress, une erreur qui peut avoir de nombreuses causes. Le message ne permet donc pas de deviner laquelle : il faut aller la lire ailleurs.
Le premier endroit est le journal d’erreurs du serveur, que de nombreux hébergeurs rendent consultable depuis leur espace client. Ensuite, WordPress documente plusieurs pistes, à tester une par une :
- renommer le fichier .htaccess, puis le régénérer depuis Réglages > Permaliens ;
- désactiver les extensions pour voir si l’une d’elles est en cause ;
- passer temporairement sur un thème par défaut de WordPress ;
- augmenter la limite de mémoire PHP.
Le journal de débogage de WordPress peut compléter celui du serveur : avec la constante WP_DEBUG_LOG, les erreurs sont écrites dans un fichier debug.log, en général dans le dossier wp-content. WordPress déconseille ces outils sur un site en ligne. Si vous les activez le temps du diagnostic, gardez WP_DEBUG_DISPLAY à false pour que les erreurs ne s’affichent pas dans les pages, puis désactivez le débogage et supprimez le fichier debug.log une fois la cause trouvée.
Le message d’erreur critique : lisez vos e-mails avant tout
La documentation de WordPress cite ce message, dans sa version anglaise : « There has been a critical error on this website. Please check your site admin email inbox for instructions. » Il indique que WordPress a intercepté une erreur fatale au lieu de s’arrêter sans rien dire.
Depuis WordPress 5.2, c’est le mode de récupération : WordPress envoie à l’adresse e-mail d’administration un message avec des détails sur l’erreur et un lien de connexion spécial. Avec ce lien, l’extension ou le thème fautif est mis en pause pour votre seule session d’administration : vous pouvez vous connecter et le désactiver sans FTP.
L’e-mail n’arrive pas ? WordPress précise qu’il peut partir directement du serveur et finir en indésirables, voire être bloqué. Vérifiez le dossier spam avant de conclure qu’il n’existe pas.
Si vous n’avez pas accès à cette boîte mail, c’est le moment de s’en occuper : c’est le canal par lequel votre site vous parle quand il ne peut plus rien afficher.
La page blanche : l’écran blanc de WordPress
La documentation de WordPress l’appelle le « White Screen of Death » : une page blanche, sans aucune information. Elle précise qu’une erreur PHP comme une erreur de base de données peut produire ce symptôme. Une extension, un thème ou du code personnalisé peuvent donc tous être en cause.
La page blanche ne vous apprend rien sur la cause. Les deux premiers réflexes sont les mêmes que pour l’erreur critique : l’e-mail de récupération, puis les journaux d’erreurs.
L’erreur de connexion à la base de données
Le message signifie, selon WordPress, qu’il y a un problème de connexion à la base de données. La documentation oriente vers trois pistes :
Dans le fichier wp-config.php, vérifier le nom de la base, l’utilisateur, le mot de passe et l’hôte. C’est la piste que WordPress désigne comme la plus habituelle.
Le serveur est arrêté, ou la base a atteint son quota et a été coupée. Rien à corriger dans vos fichiers : c’est l’hébergeur qui a la réponse.
WordPress recommande aussi d’écarter un piratage avec une analyse de sécurité du site. Votre hébergeur peut vous y aider.
Regardez d’abord l’état de l’hébergement : c’est rapide et ne modifie rien. Ouvrez wp-config.php juste après. Modifier un fichier de configuration pendant une panne d’hébergeur ajoute un problème à un problème.
La maintenance qui ne se termine jamais
WordPress documente ce cas précis : pendant une mise à jour, il crée automatiquement un fichier .maintenance et affiche un message de maintenance (en anglais : « Briefly unavailable for scheduled maintenance. Please check back in a minute. »). Si la mise à jour s’interrompt, le fichier reste, et le message aussi.
Le site n’est pas cassé : il est resté à mi-chemin. La solution documentée consiste à supprimer ce seul fichier .maintenance à la racine du site, par FTP ou par le gestionnaire de fichiers de l’hébergeur, puis à vérifier que la mise à jour interrompue s’est bien terminée.
L’erreur 403
Un 403 signifie que le serveur a compris la demande et refuse d’y répondre. Avant de modifier quoi que ce soit, posez une seule question : qu’est-ce qui a changé juste avant ? Une extension de sécurité installée, une règle serveur, des droits de fichiers modifiés. Si rien n’a été touché sur le site, la question va à l’hébergeur.
La méthode sûre en 4 étapes
Ouvrir le FTP et supprimer « ce qui semble en trop » transforme une panne réversible en panne durable : plus personne ne sait dans quel état était le site avant.
Constater
Notez le message exact, l’heure, et la dernière action effectuée sur le site. Une capture d’écran suffit.
Sauvegarder
Avant toute modification, sans exception : fichiers et base de données, ou la sauvegarde proposée par votre hébergeur.
Lire
Le journal d’erreurs du serveur, l’e-mail de récupération de WordPress, la page d’état de l’hébergeur. Ce sont les trois endroits où une cause a une chance d’être nommée.
Agir
Une seule variable à la fois, en notant chaque changement : désactiver une extension, revenir au thème par défaut, corriger un identifiant. Puis vérifier avant de passer à la suivante.
Et Google, pendant la panne ?
Google documente le comportement de ses robots face aux erreurs serveur : une erreur 5xx les fait ralentir temporairement l’exploration, et les URL déjà indexées sont conservées dans l’index, mais finissent par en être retirées si la situation dure.
Pour une indisponibilité volontaire, Google recommande une page informative servie avec un code 503 pendant un à deux jours, quelques jours au maximum ; au-delà, l’effet sur la présence dans la recherche devient important.
À retenir
Rétablir le site dans la journée n’a rien à voir avec une panne qui s’installe sur plusieurs jours. C’est la durée qui fait le risque pour votre référencement.
Le piège du « soft 404 »
Si, pendant la panne, vos pages répondent 200 tout en affichant une page vide ou un message d’erreur, Google le signale dans la Search Console comme un soft 404. Le serveur dit que tout va bien, le contenu dit le contraire.
Si votre site fonctionne mais n’apparaît plus sur Google, ce n’est pas une panne : c’est une question d’indexation, traitée dans l’article pourquoi mon site n’apparaît pas sur Google.
Quand appeler quelqu’un, et ce qu’il faut lui donner
Appelez quand la deuxième tentative échoue, pas la cinquième. Chaque manipulation supplémentaire rend le diagnostic plus difficile pour la personne qui prendra la suite.
Les informations qui font gagner du temps
Éviter la prochaine panne
Plusieurs des pannes décrites ici sont liées à une mise à jour : la maintenance bloquée en est un cas documenté, et une extension ou un thème incompatible peut déclencher une erreur fatale. Les prévenir demande surtout une méthode : sauvegarde avant chaque mise à jour, mises à jour espacées plutôt que toutes en même temps, vérification du site juste après, et un accès vérifié à l’e-mail d’administration.
La routine de contrôle est détaillée dans la checklist de maintenance WordPress mensuelle. Un site qui ralentit sans tomber relève d’un autre diagnostic : site WordPress trop lent. Et si vous préférez déléguer ces gestes, l’offre de maintenance WordPress détaille ce qui est couvert.
Un site en panne se répare d’abord en ne cassant rien de plus
Erreur 500, page blanche, erreur critique, base de données injoignable, maintenance bloquée ou 403 : les messages diffèrent, la situation est la même. Votre site ne répond plus, et la cause n’est pas encore connue. Le bon réflexe ne consiste donc pas à deviner, mais à suivre toujours le même ordre : constater, sauvegarder, lire les journaux, puis agir une seule variable à la fois.
Côté Google, une panne réglée dans la journée n’a pas les mêmes conséquences qu’une indisponibilité qui dure plusieurs jours : c’est la durée qui fait le risque. Si la deuxième tentative échoue, passez la main avec le message exact, l’heure, la dernière action et l’état de la sauvegarde. Et une fois le site rétabli, la meilleure réparation reste celle qu’on n’aura pas à faire : des mises à jour sauvegardées, espacées et vérifiées.
Besoin d’une maintenance WordPress ?
Je peux prendre en charge les mises à jour de WordPress et des extensions, les sauvegardes régulières et la vérification après mise à jour, avec les petites corrections et une assistance par mail.
FAQ – Site WordPress qui ne répond plus
Vais-je perdre mon contenu ?
L’affichage d’une erreur ne supprime rien par lui-même : vos pages sont toujours dans la base de données. Deux situations font exception : une base endommagée, et les manipulations faites sans sauvegarde pendant la panne. D’où la règle : sauvegarder avant de toucher à quoi que ce soit.
Mes visiteurs voient-ils le mode de récupération ?
Non. Selon WordPress, les visiteurs voient un écran indiquant que le site rencontre des difficultés techniques. L’extension ou le thème fautif n’est mis en pause que pour la session de l’administrateur connectée avec le lien de récupération.
Comment désactiver une extension sans accès à l’administration ?
WordPress documente une méthode par FTP ou par le gestionnaire de fichiers de l’hébergeur : renommer le dossier de l’extension dans wp-content/plugins, ce qui la désactive. Faites-le une extension à la fois, après sauvegarde, en commençant par la dernière installée ou mise à jour.
Faut-il restaurer une sauvegarde tout de suite ?
Pas en premier réflexe. Restaurer efface les traces de ce qui s’est passé, et toute modification faite depuis la sauvegarde. Lisez d’abord les journaux et l’e-mail de WordPress. La restauration devient le bon choix quand la cause reste introuvable et que la sauvegarde date d’avant la panne.
Comment savoir si la panne vient de mon site ou de mon hébergeur ?
Consultez la page d’état ou les annonces de l’hébergeur, et vérifiez si d’autres services du même hébergement fonctionnent : messagerie, autre site, espace client. Si tout est en panne en même temps, la cause est probablement chez l’hébergeur et c’est son support qu’il faut contacter.
Sources et ressources officielles
-
WordPress – Common WordPress Errors
– erreur interne du serveur, erreur critique, connexion à la base de données, maintenance après mise à jour, écran blanc. -
WordPress – Recovery Mode
– e-mail à l’administrateur, lien de connexion, mise en pause de l’extension ou du thème fautif, désactivation par FTP. -
WordPress – Debugging in WordPress
– WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY et fichier debug.log. -
Google Search Central – Codes d’état HTTP et erreurs réseau
– erreurs 5xx, conservation puis retrait des URL indexées, soft 404. -
Google Search Central – Suspendre temporairement un site
– code 503 et durée maximale recommandée.
