L’état de santé du site (site-health) de WordPress : liste de tous les messages d’erreur et solutions aux problèmes

Qu’est-ce que l’écran Etat de santé du site de WordPress ?

Depuis WordPress 5.2, tout site WP propose dans l’admin une page de diagnostic technique, qui affiche les résultats d’une série de tests. Il s’agit de l’écran « Etat de santé du site ».

On y accède via le menu Outils en colonne de gauche, puis Santé du site :

Cette page se divise en deux onglets :

• Etat, liste les problèmes « critiques », les « améliorations recommandées » et les « tests passés avec succès »
• Informations, donne l’ensemble des paramètres de la configuration actuelle de votre site et de votre serveur

L’onglet Etat donne donc le résultat d’une série de « tests de santé du site ». Si les tests sont passés avec succès, WordPress les classe dans cette catégorie et n’en dit rien de plus.

Mais si les tests diagnostiquent des problèmes, alors WordPress les classe selon leur niveau de gravité.

En gros, ça fonctionne comme un médecin un peu tatillon : si tout va bien il vous laisse sortir, sinon il vous colle une liste d’analyses à faire.

Par ailleurs, l’écran de santé classe aussi ses tests par thématique :

• Sécurité
• Performances
• Internationalisation
• WP Mail SMTP

Dans certains cas, vous verrez aussi des rubriques ajoutées par des plugins (par exemple un bloc spécifique pour un plugin de sécurité, un plugin de cache, ou un hébergeur qui a intégré ses propres tests).

Pour les webmasters, l’écran de santé est donc un outil très pratique qui permet d’identifier très vite des optimisations possibles. Typiquement, c’est la première page que j’ouvre quand un client me dit : « Mon site rame et j’ai peur qu’il soit cassé ». Ça ne remplace pas un audit complet, mais ça donne vite quelques pistes très concrètes.

Problèmes critiques, améliorations recommandées : explications et solutions

Je vais maintenant lister tous les tests faits par la fonctionnalité site-health, et vous expliquer ce qu’ils veulent dire.

Quand ces tests diagnostiquent un problème, je vais vous donner des solutions pour le régler. Et parfois aussi vous dire quand il vaut mieux ignorer un message plutôt que de tout casser pour faire disparaître une alerte orange…

Les options chargées automatiquement peuvent affecter les performances

Ce problème est lié aux données stockées par les plugins WordPress dans la table wp_options de la base de données.

Le principe est simple : pour fonctionner, les plugins ont besoin de réglages faits par le webmaster. Ils stockent tous ces réglages dans la table options.

Or, ces réglages ont un paramètre « autoload« , qui a 2 valeurs possibles : Oui, ou Non.

Cet autoload, c’est le chargement automatique de ces données en mémoire, à chaque chargement de page. Donc si vous avez 3 Mo de réglages en autoload, chaque page va se trimballer ces 3 Mo, même si la page en question n’en a pas besoin. C’est un peu comme si vous partiez faire vos courses en emmenant avec vous tout le contenu du grenier, “au cas où”.

De fait, beaucoup de plugins ont de mauvaises pratiques :

• ils stockent trop d’options inutiles en autoload (logs, stats, réglages temporaires… tout y passe)
• quand on les désactive ou les supprime, ils ne font pas le ménage et laissent derrière eux des paramètres dans la table options, y compris en autoload !

Concrètement, sur un vieux site que personne n’a nettoyé depuis des années, on peut facilement avoir plusieurs dizaines de milliers de lignes dans wp_options, dont une bonne partie en autoload. Et là, oui, ça plombe clairement les performances.

La solution, du coup, consiste à nettoyer de temps en temps la table options.

Le faire à la main, en SQL, c’est possible mais risqué : une mauvaise requête, et vous explosez le site. Et après, c’est “white screen of death” et panique générale.

C’est compliqué à faire à la main mais j’ai découvert un excellent plugin qui facilite ce travail.

Pour les détails, lisez ce tuto :

Comment régler le problème « Les options chargées automatiquement peuvent affecter les performances »

La mise en cache des pages n’est pas détectée et le temps de réponse du serveur est lent

Ce problème est bien réel, et très fréquent.

La mise en cache des pages, c’est un système pour mémoriser les pages demandées par les internautes, au lieu de les recalculer à chaque fois.

Le fonctionnement standard du chargement d’une page sur un site WordPress ressemble à ceci :

• un internaute appelle, dans son navigateur, une page d’un site WordPress
• le serveur répond en exécutant du code PHP
• ce code PHP crée du code HTML
• ce code HTML appelle d’autres fichiers, des images, du CSS, du JS

Ainsi, charger une page c’est faire une série d’opérations qui prennent du temps.

Le cache sert à garder en mémoire le résultat de tous ces calculs. Au lieu de refaire toute la recette à chaque fois, le cache mémorise le HTML final (HTML statique).

Résultat : le chargement d’une page en cache est beaucoup plus rapide que celui d’une page qui n’est pas dans le cache. On parle parfois de pages servies en quelques millisecondes, contre plusieurs secondes sans cache sur un hébergement moyen.

Si un site n’a aucun cache, alors toutes ses pages doivent être entièrement calculées. Si les internautes demandent 100 fois votre page d’accueil en une journée, elle est recalculée 100 fois.

Ceci explique aussi en partie que « le temps de réponse du serveur est lent » : forcément, vu qu’il repart de 0 à chaque fois, le pauvre.

Autre effet concret : si vous prenez une claque de trafic (passage TV, post viral sur un réseau social, promo…), un site sans cache peut tomber en PLS très vite. Avec un bon cache, le serveur encaisse beaucoup mieux.

La solution est donc assez simple : il faut installer un cache de page.

Beaucoup de plugins feront ce travail plus ou moins bien :

• des plugins basiques, peu puissants, mais simples à configurer, comme Cache Enabler ou WP Fastest Cache. Parfaits pour un petit blog ou un site vitrine qui ne reçoit pas des milliers de visiteurs en simultané.
• des plugins plus puissants, mais plus compliqués à configurer, comme W3 Total Cache ou WP Super Cache. Ils permettent de gérer finement le cache page, le cache objet, la minification, etc. Mais si on clique partout au hasard, on peut aussi tout casser.
• ou ma solution préférée : LiteSpeed Cache, qui s’installe sur le serveur (chez certains hébergeurs, comme O2Switch, mais pas sur OVH…), et se paramètre avec un plugin. C’est la solution la plus puissante et la plus compliquée à mettre en oeuvre.

Sur certains hébergeurs, il existe aussi un cache au niveau serveur ou proxy (Varnish, Nginx reverse proxy, etc.). Dans ce cas, parfois, l’écran de santé ne “voit” pas le cache, alors qu’il est bien actif. Donc ne paniquez pas si le site est en réalité rapide aux tests (PageSpeed, GTmetrix, WebPageTest…) mais que WordPress se plaint quand même.

A noter : le cache de page, qui stocke le HTML statique des pages web, doit être distingué du cache objet, qui stocke le résultat de requêtes SQL à la base de données, et du cache navigateur, où c’est le navigateur de l’internaute qui stocke le HTML statique des pages déjà visitées.

Votre site est configuré pour enregistrer le journal des erreurs dans un fichier potentiellement public

Ce problème concerne la sécurité de votre site.

Des paramètres de WordPress créent un « journal des erreurs« , appelé debug.log.

Si ce journal est public, n’importe qui peut le lire sur le web. Et donc, un pirate peut exploiter ces erreurs. C’est comme laisser traîner sur la table un dossier marqué “toutes les failles de mon site” et espérer que personne ne le lira.

On a donc 2 solutions :

• soit on désactive la journalisation des erreurs
• soit on stocke le journal des erreurs dans un dossier qui n’est pas accessible au public

D’abord, ce message affiché par l’écran de santé du site WordPress signifie que le fichier wp-config.php contient ces lignes :

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

Ces lignes disent :

• est-ce qu’on diagnostique les erreurs ? oui
• est-ce qu’on les enregistre dans le journal des erreurs ? oui

On peut donc simplement remplacer true par false, si on est sûr que tout va bien. Mais perdre la liste des erreurs, c’est perdre une occasion de diagnostiquer facilement des problèmes (et je vous garantis qu’un jour ou l’autre, on a besoin de ce log).

Donc, je ne conseille pas de désactiver la journalisation des erreurs. Je recommande simplement de les stocker dans un dossier non accessible au public, ou d’en interdire l’accès.

Pour ce faire, on aura donc ces lignes dans le fichier wp-config.php :

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', '/chemin/vers/un/dossier-securise/debug.log');

Remplacez /chemin/vers/un/dossier-securise/ par un chemin en dehors du dossier qui contient votre site WordPress (il s’agit souvent de dossiers nommés public_html ou www).

Ou, autre solution : vous pouvez laisser le fichier debug.log dans votre dossier public, mais en interdire l’accès en ajoutant ceci à votre fichier .htaccess sur serveur Apache :

<Files "debug.log">
Order allow,deny
Deny from all
</Files>
Sur Nginx, la logique est similaire mais la syntaxe se mettra dans le bloc de configuration du site. Si vous ne savez pas où c’est, évitez de cliquer partout dans le manager d’hébergement…

Votre site est réglé pour afficher les erreurs à vos visiteurs

Ce problème est très similaire au précédent. Le régler est très simple.

Quand cette option est active, les visiteurs voient s’afficher des messages d’erreur PHP en haut des pages, voire un écran tout blanc avec juste un message technique. Niveau UX, on a vu mieux.

Allez dans votre fichier wp-config.php et remplacez true par false dans la ligne qui dit :

define('WP_DEBUG', true);


Vous pouvez aussi vous assurer d’avoir :

define('WP_DEBUG_DISPLAY', false);


En développement, sur un site de test, ok pour afficher les erreurs. En production, sur un vrai site avec de vrais clients, non. Jamais.

Un évènement planifié a échoué

Ce message d’erreur de l’écran de santé du site concerne la fonctionnalité qu’on appelle les tâches cron. On lit souvent un message du style :

L’évènement planifié [nom de l’évènement] a échoué. Votre site fonctionne toujours, mais cela pourrait indiquer que les publications planifiées ou les mises à jour automatiques ne fonctionnent pas comme elles le devraient.

Une tâche cron est l’exécution d’un code de manière programmée. On la paramètre sur le serveur. On peut dire par exemple : « Lance l’exécution des tâches toutes les heures ».

Ces tâches consistent par exemple à faire la mise à jour des plugins, ou à faire ce que les plugins sont prévus pour faire : créer une sauvegarde toutes les semaines, vérifier les liens internes toutes les 24h, envoyer un email de rappel panier abandonné, etc, etc.

Idéalement, chaque site WordPress devrait avoir une tâche cron lancée toutes les minutes. Pour cela, il faudrait donc que tous les propriétaires de sites WordPress sachent paramétrer une tâche cron sur le serveur. Or, ce n’est évidemment pas le cas. De plus, tous les hébergeurs ne le permettent pas.

WordPress a donc adopté une solution de compromis. Il s’abstient d’imposer la création d’une tâche cron sur le serveur. A la place, il déclenche, par défaut, un lancement de tâche cron à chaque visite sur le site. Ceci peut évidemment poser problème : un site rarement visité aura souvent des tâches en retard.

Exemple typique : vous planifiez un article pour demain matin, mais votre site n’a aucun visiteur avant l’après‑midi. Résultat, l’article ne se publie que quand le premier visiteur arrive. Pratique.

La solution idéale consiste donc à désactiver le cron par défaut de WordPress, et à créer une tâche cron sur le serveur, si l’hébergeur vous en laisse le droit, comme chez O2Switch.

Pour désactiver le cron interne, on ajoute dans wp-config.php :
define('DISABLE_WP_CRON', true);

Ensuite, on configure sur le serveur une tâche qui appelle régulièrement :
https://votre-site.fr/wp-cron.php?doing_wp_cron

A partir du moment où une tâche cron est lancée toutes les minutes, aucun évènement planifié ne sera en retard. Et l’écran de santé arrêtera normalement de se plaindre.

Les mises à jour d’arrière-plan ne fonctionnent pas comme prévu

Ce problème survient plutôt rarement car WordPress est configuré par défaut pour que les mises à jour du coeur (« core »), des thèmes et des plugins, puissent se faire automatiquement.

L’écran de santé peut par exemple vous dire que les mises à jour de sécurité du core ne peuvent pas être appliquées, ou que certaines mises à jour ont échoué.

Si le problème se pose sur votre site, il est possible que les mises à jour automatiques aient été désactivées via une instruction dans votre fichier wp-config.php. Si c’est le cas, vous devriez y trouver des instructions comme :

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Si vous trouvez cette ligne, remplacez true par false et sauvegardez.

Ou cette ligne :

define( 'WP_AUTO_UPDATE_CORE', false );

Si vous la trouvez, remplacez false par true.

Il est aussi possible que la désactivation des mises à jour vienne d’un ajout de filtre dans le fichier functions.php de votre thème. Mais ce fichier est susceptible de contenir plus ou moins de code important, et si vous n’avez pas des compétences de développeur, je vous déconseille d’y toucher vous-même. Développeurs, vous trouverez de l’info ici.

Autres causes possibles :

• le système de fichiers n’est pas inscriptible (problème de permissions sur les dossiers, WordPress n’arrive pas à créer/modifier des fichiers)
• l’hébergement bloque certaines fonctions PHP nécessaires aux mises à jour (comme fsockopen, curl, etc.)
• un plugin de sécurité bloque les connexions sortantes vers les serveurs de mise à jour

Dans le doute : testez les mises à jour manuellement, regardez si des erreurs s’affichent, et si vraiment ça coince, ouvrez un ticket chez l’hébergeur.

Les mises à jour automatiques des extensions et/ou des thèmes semblent désactivées, mais les réglages s’affichent tout de même

Je n’ai jamais rencontré ce problème.

Pour le régler, je pense qu’il suffit d’activer les mises à jour automatique des extensions et des thèmes, CQFD… en allant sur la page des extensions et en cliquant sur « Activer » sur chaque fin de ligne.

Il se peut que l’erreur soit causée par une désactivation des mises à jour qui aurait été faite par un précédent webmaster, dans ce cas reportez-vous au cas précédent ci-dessus et inspectez les fichiers wp-config.php et functions.php.

Dans certains environnements managés (par exemple des offres “WordPress managé” chez certains hébergeurs), c’est l’hébergeur qui force sa propre politique de mises à jour. L’écran de santé se retrouve un peu perdu : il voit des options, mais n’a pas la main. Ce n’est pas forcément grave, mais ça peut expliquer le message.

Vous devriez retirer les thèmes inactifs

L’écran de santé du site peut diagnostiquer le fait que vous ayez plus de 2 thèmes disponibles. Il considère alors que c’est un problème.

Pourquoi ? Parce que chaque thème installé en plus augmente un peu le risque de faille, de vulnérabilité, d’obsolescence, donc de piratage.

Par définition, un site web n’utilise durablement qu’un seul thème graphique. Donc, avoir 5 thèmes inactifs est aussi inutile que d’avoir 5 roues de secours dans son coffre. En plus, chacun de ces thèmes peut recevoir des mises à jour : si vous ne les faites pas, ils deviennent des portes d’entrée possibles.

La bonne pratique consiste à avoir :

• 1 thème principal inactif
• 1 thème enfant activé (child theme)
• 1 thème de secours, de préférence la dernière version du thème officiel de WordPress de l’année en cours

En général, le thème de secours c’est “Twenty Twenty‑Something” (le dernier thème par défaut WordPress). Il sert si vous devez passer temporairement sur un thème propre pour déboguer un conflit.

Faites cela, et l’erreur disparaitra. Et accessoirement, vous simplifiez aussi la liste “Apparence > Thèmes” qui ressemble souvent à un musée de thèmes testés un jour à 2h du matin “pour voir”.

Impossible de rejoindre WordPress.org

La traduction française de cette erreur de l’écran de santé est inexacte. Plus clairement, l’erreur signifie que votre site ne peut pas aller récupérer les mises à jour de WordPress, de ses thèmes et de ses plugins, sur le serveur de WordPress.org, qui est le serveur officiel de WordPress.

L’erreur est donc assez simple à comprendre, par contre elle peut avoir de multiples causes difficiles à expliciter.

Il faudrait donc investiguer au cas par cas. Le blocage de la communication entre votre site et les serveurs de WordPress.org peut venir de :

• un mauvais réglage sur votre serveur, chez votre hébergeur (notamment relatif à ModSecurity ou à un pare‑feu applicatif)
• un plugin, probablement de sécurité, réglé pour bloquer les requêtes sortantes et le trafic http sortant
• du code rajouté quelque part dans vos fichiers, et interdisant les communications avec l’extérieur
• un problème DNS (le serveur ne sait tout simplement pas résoudre api.wordpress.org)
• une configuration PHP qui bloque certaines fonctions réseau (désactivation de curl, allow_url_fopen à Off, etc.)

Premier réflexe : tester la connexion depuis le serveur (via un curl https://api.wordpress.org/ si vous avez un accès SSH), ou demander à l’hébergeur de le faire. Si même le serveur n’arrive pas à joindre WordPress.org, ce n’est pas un problème WordPress, mais un problème d’infrastructure.

Les requêtes HTTP sont bloquées

Les requêtes http sont des appels que fait votre site vers d’autres sites en utilisant le protocole http, celui-là même qu’utilise votre navigateur pour accéder à la page que vous êtes en train de lire.

WordPress et vos plugins les utilisent pour :

• vérifier les mises à jour de thèmes, plugins et du core
• appeler des API externes (Mailchimp, Stripe, PayPal, services d’emailing, services de SMS…)
• vérifier des licences de plugins premium
• récupérer des polices, des scripts ou des données à distance

Si ces requêtes http sont bloquées, cela peut venir :

• du module ModSecurity sur votre serveur. Essayez de le désactiver pour voir s’il cause l’erreur. Si oui, réactivez-le après avoir modifié ses réglages, car ModSecurity est une défense essentielle.
• d’un pare-feu / firewall sur le serveur.
• du fichier wp-config.php qui pourrait contenir une instruction define('WP_HTTP_BLOCK_EXTERNAL', true); – dans ce cas, supprimez cette ligne ou remplacez true par false.
• de mauvais réglages dans votre fichier .htaccess à la racine des dossiers de votre site sur votre serveur (par exemple des règles qui bloquent wp-cron.php ou wp-admin/admin-ajax.php)
• de plugins de sécurité comme Wordfence ou iThemes Security qui bloqueraient les requêtes HTTP sortantes, dans ce cas inspectez les réglages de firewall pour annuler l’interdiction de ces requêtes

Dans l’écran de santé, vous pouvez parfois cliquer sur “plus de détails” pour voir quelle URL exactement WordPress essaye d’appeler. Ça donne souvent une bonne piste sur ce qui bloque.

Votre site n’a pas pu terminer la requête de bouclage

Ce problème est assez similaire au précédent.

Une requête de bouclage, c’est une requête que fait votre site et votre serveur vers lui-même. Il se demande quelque chose. Divers plugins peuvent en avoir besoin. Par exemple, WooCommerce. Les tâches cron lancées avec wp-cron.php en dépendent aussi.

Concrètement, WordPress essaie d’appeler une URL du style :
https://votre-site.fr/wp-cron.php?doing_wp_cron=...
ou
https://votre-site.fr/wp-admin/admin-ajax.php

Si cet appel échoue, l’écran de santé vous indique que la requête de bouclage n’a pas abouti.

Pour le régler, vous pouvez appliquer les solutions du problème précédent. Ajoutez à ça quelques vérifications supplémentaires :

• vérifiez que votre site est bien accessible en HTTP/HTTPS exactement comme défini dans Réglages > Général (pas de mélange http / https, pas de www d’un côté et pas de www de l’autre)
• désactivez temporairement les plugins de sécurité pour voir si l’un d’eux ne bloque pas le trafic venant de votre propre serveur (certains croient à une attaque DDoS… de vous contre vous-même)
• regardez si votre .htaccess ne contient pas de règles trop agressives qui bloqueraient wp-cron.php ou admin-ajax.php

Une session PHP active a été détectée

Cette erreur signale le fait qu’il y a une instruction session_start(); cachée quelque part dans un fichier PHP de votre site.

Cette instruction démarre une session PHP classique, alors que WordPress a son propre système (cookies, gestion interne). Mélanger les deux peut créer des comportements bizarres (cache qui saute, headers déjà envoyés, etc.).

Cette instruction pourrait être :

• dans le code d’un de vos plugins, donc désactivez-les un par un jusqu’à ce que l’erreur disparaisse, et remplacez ce plugin mal codé
• dans le fichier functions.php de votre thème (un codeur pourrait avoir oublié d’enlever cette instruction, supprimez-la à la main)

L’erreur pourrait aussi venir d’un cache mal configuré (Redis, Memcached, OPcache, etc).

Pour le savoir, videz le cache WordPress (WP Super Cache, W3 Total Cache, LiteSpeed Cache), désactivez Redis ou Memcached dans votre hébergeur (o2switch, OVH, Hostinger…) et voyez si ça a réglé le problème.

Une astuce : faites une recherche dans tous les fichiers de votre installation (via votre IDE, ou un “chercher dans les fichiers” du manager de fichiers) sur session_start(. Si vous en voyez dans un plugin “random” téléchargé sur un site exotique, posez-vous la question de son utilité réelle…

Votre site utilise une version obsolète de PHP, qui devrait être mise à jour

Ce problème est sérieux. PHP est le principal langage qui fait tourner votre site WordPress. Si sa version est obsolète :

• cela pose un gros souci de sécurité (les versions d’avant PHP8 ne sont plus mises à jour et ouvrent donc des failles de sécurité connues des pirates, donc exploitables)
• le coeur de WordPress, les thèmes et les plugins sont en permanence réécrits dans les versions actuelles de PHP : une version obsolète va donc causer un certain nombre de bugs un peu partout

On voit encore des sites tourner en PHP 5.6 “parce que ça marche encore”. Oui, jusqu’au jour où un plugin important refuse de s’installer, ou qu’un attaquant exploite une faille publiée depuis 5 ans.

Pour mettre à jour PHP, rendez-vous sur votre hébergeur, trouvez les paramètres de PHP et choisissez la dernière version. Vous devrez peut-être activer certains modules et gérer les options. Si vous ne savez pas le faire, demandez de l’aide à un professionnel.

Bon réflexe avant de changer de version :

• faites une sauvegarde complète (fichiers + base de données)
• si possible, testez la nouvelle version PHP sur un staging (copie de votre site)
• une fois la version modifiée, naviguez un peu sur le site (front + admin), vérifiez surtout les pages critiques (panier, paiement, formulaires, etc.)

L’API REST a rencontré une erreur

Ce message apparaît parfois dans l’état de santé, généralement sous une forme du genre :

L’API REST a rencontré une erreur. L’API REST est un moyen par lequel WordPress et d’autres applications communiquent avec le serveur.

L’API REST est utilisée par Gutenberg, par certains plugins, par les applications mobiles WordPress, etc. Si elle est cassée, vous pouvez avoir des blocs qui se chargent mal, des mises à jour d’articles qui échouent, ou des fonctionnalités d’extension qui refusent de se lancer.

Causes possibles :

• une règle .htaccess ou de configuration Nginx qui bloque l’accès à wp-json/
• un plugin de sécurité qui bloque les requêtes vers l’API REST (certains le font par “excès de zèle”)
• un conflit de plugin qui renvoie une erreur fatale avant la réponse JSON
• une redirection mal configurée qui renvoie l’API REST vers une autre URL (ou vers le HTTPS mal configuré)

Test simple : ouvrez https://votre-site.fr/wp-json/ dans un navigateur. Vous devez voir un gros JSON moche mais lisible. Si vous voyez une erreur 403, une page 404 ou une redirection infinie, vous tenez déjà une bonne piste.

Les boucles de fond (background updates) rencontrent un problème

Un autre message que l’écran de santé peut montrer ressemble à :

Les mises à jour en arrière-plan ne fonctionnent pas correctement.

Il est proche de celui sur les mises à jour d’arrière-plan, mais plus large : il peut concerner les processus qui tournent en tâche de fond pour WordPress ou pour certains plugins (indexation, optimisation, traitement de files d’attente…).

Les causes les plus classiques :

• un timeout PHP trop bas : les scripts “longs” sont tués avant la fin
• un plugin de sécurité ou un firewall qui coupe les requêtes internes jugées “suspectes”
• un hébergeur qui limite trop agressivement les ressources (process PHP bruts, mémoire, I/O disque)

La solution dépend vraiment du contexte :

• regardez les logs d’erreur PHP
• vérifiez si vous n’avez pas un plugin qui lance des tâches monstrueuses toutes les minutes pour rien
• demandez à l’hébergeur si des limites particulières sont atteintes régulièrement

La communication par e‑mail ne fonctionne pas correctement

Un autre type de message que l’écran de santé peut afficher concerne le mail, par exemple via la section WP Mail SMTP ou similaire :

Une erreur est survenue lors de l’envoi d’un e‑mail de test.

WordPress, par défaut, envoie les mails avec la fonction mail() de PHP. Selon l’hébergeur, ça passe… ou pas du tout. Et même si ça part, ça finit souvent en spam.

Si le test de mail échoue, on peut suspecter :

• une configuration serveur qui bloque mail()
• des paramètres SMTP incorrects dans un plugin de type WP Mail SMTP
• un port de sortie (587, 465, 25) bloqué par l’hébergeur

Solution propre : configurer l’envoi avec un SMTP authentifié (celui de votre hébergeur ou d’un service tiers type SendGrid, Mailgun, etc.) via un plugin spécialisé. L’écran de santé vous aidera souvent en expliquant précisément quelle étape du test a échoué.

La taille de votre base de données est importante

Certains outils ajoutés à l’écran de santé (ou des extensions de monitoring) peuvent aussi vous remonter que la base de données est très volumineuse, avec par exemple beaucoup de révisions, de transients expirés, ou de tables laissées par des plugins désinstallés à moitié.

Sans être toujours “critique”, ça impacte :

• les sauvegardes (plus longues, plus lourdes)
• les restaurations de site
• certaines requêtes lentes si les index ne sont pas propres

La solution passe par :

• nettoyer les révisions d’articles inutilement nombreuses
• supprimer les transients expirés
• supprimer, avec précautions, des tables orphelines de plugins

Là encore, mieux vaut utiliser un plugin sérieux plutôt que de taper des commandes SQL au hasard à 1h du matin. Je dis ça, je dis rien…

Conclusion rapide

L’écran État de santé du site, c’est un peu comme le tableau de bord d’une voiture : si un voyant rouge s’allume, on ne l’ignore pas éternellement. Tout ne demande pas une intervention immédiate, mais tous ces messages racontent quelque chose de votre installation.

En prenant l’habitude d’y jeter un œil régulièrement, de comprendre ce que les erreurs signifient, et de corriger ce qui est vraiment problématique, vous vous évitez pas mal de surprises (et quelques nuits blanches). Et si un message vous semble obscur ou trop technique, il vaut mieux demander un coup de main plutôt que de “tenter un truc” en prod et casser la moitié du site.