Santé du site WordPress : comprendre, corriger et maîtriser chaque test

Votre WordPress affiche "devrait être amélioré" dans l’outil Santé du site et vous commencez à paniquer… Spoiler : ce score ne mesure pas la qualité de votre site. Il mesure la configuration technique de votre installation. Et ça, c’est une bonne nouvelle, parce que ça se corrige.

On l’oublie trop souvent, mais l’outil Santé du site est probablement le plus sous-estimé de toute l’administration WordPress. Apparu avec WordPress 5.2 en 2019, il s’inspire du plugin Health Check & Troubleshooting développé par la communauté WordPress.org. Depuis, il a considérablement évolué : nouveaux tests de performance (cache objet, cache de page), onglet dédié, et même des commandes WP-CLI depuis WordPress 6.6.

En 15 ans de WordPress et après avoir formé des centaines de personnes, je constate que la majorité des utilisateurs ne regardent jamais cet outil. Et quand ils le découvrent, ils ne savent pas quoi faire des recommandations affichées. Cet article va corriger ça : chaque test expliqué, chaque section de l’onglet Informations décortiquée, et des astuces avancées pour les profils techniques.

Où trouver l’outil Santé du site

L’outil Santé du site est accessible depuis le menu Outils > Santé du site de votre administration WordPress. L’URL directe est votre-site.com/wp-admin/site-health.php.

Sur cette page, vous trouverez deux onglets principaux :

• État : le diagnostic en temps réel. Tests de sécurité, tests de performance, score global. C’est ici que WordPress vous signale ce qui fonctionne, ce qui mérite attention, et ce qui est critique.
• Informations : la fiche technique complète de votre installation. Version PHP, modules installés, taille de la base de données, répertoires, constantes actives… Tout y est.

Depuis WordPress 5.9, un troisième aspect a été ajouté : les tests de performance dédiés (cache objet persistant, détection du cache de page). Ces tests n’existaient pas à la sortie de l’outil et beaucoup de tutoriels ne les mentionnent même pas.

Vous ne trouvez pas l’onglet Santé du site ? Certains plugins de sécurité ou d’optimisation le masquent. Vérifiez que vous êtes connecté en tant qu’administrateur (les autres rôles n’y ont pas accès). Si l’onglet reste invisible, désactivez temporairement vos plugins un par un pour identifier le coupable.

Vous pouvez aussi ajouter un widget "Santé du site" directement sur votre tableau de bord WordPress. Allez sur la page d’accueil de l’admin, cliquez sur "Options de l’écran" en haut à droite, puis cochez "Santé du site". Pratique pour garder un oeil sans aller chercher l’outil à chaque fois.

Onglet État : les tests de sécurité expliqués

L’onglet État classe les résultats en trois catégories : les tests passés (tout va bien), les recommandations (améliorations souhaitables) et les problèmes critiques (à corriger en priorité). Voyons les principaux tests de sécurité et comment réagir pour chacun d’eux.

HTTPS et certificat SSL

L’outil Santé du site vérifie que votre site utilise le protocole HTTPS et qu’un certificat SSL valide est en place. En 2026, un site sans HTTPS n’a plus aucune raison d’exister : Google pénalise les sites non sécurisés dans ses résultats, les navigateurs Chrome et Firefox affichent une alerte "Non sécurisé" dans la barre d’adresse, et vos visiteurs n’ont aucune confiance face à ce message.

Si ce test échoue, contactez votre hébergeur pour activer un certificat SSL (souvent gratuit via Let’s Encrypt). Ensuite, forcez HTTPS dans votre fichier wp-config.php :

define( 'FORCE_SSL_ADMIN', true );
define( 'WP_HOME', 'https://votre-site.com' );
define( 'WP_SITEURL', 'https://votre-site.com' );

Mon conseil : après avoir activé SSL, vérifiez que TOUTES vos ressources (images, scripts, feuilles de style) passent aussi en HTTPS. Le "mixed content" (mélange HTTP/HTTPS) peut casser l’affichage du cadenas dans le navigateur. Le plugin "Really Simple SSL" règle ça automatiquement, mais c’est encore mieux de corriger directement dans la base de données avec un Search & Replace (Better Search Replace ou WP-CLI).

Mode debug activé en production

Bon. Celui-là, c’est le classique. Le mode debug (WP_DEBUG) est un outil de développement qui affiche les erreurs PHP. En production, il expose vos chemins de fichiers, vos requêtes SQL, et parfois même des informations sensibles… directement à vos visiteurs. Et aux attaquants.

Trois constantes à vérifier dans votre wp-config.php :

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

Le piège : certains tutos vous disent d’activer WP_DEBUG_LOG pour écrire les erreurs dans un fichier. C’est vrai… sauf que ce fichier (wp-content/debug.log) est souvent accessible publiquement. Autant envoyer vos erreurs par carte postale. Si vous avez besoin du log, spécifiez un chemin en dehors du dossier public :

define( 'WP_DEBUG_LOG', '/home/user/logs/debug.log' );

Et si le fichier doit rester dans wp-content, ajoutez cette ligne dans votre .htaccess pour le protéger :

<Files debug.log>
  Order allow,deny
  Deny from all
</Files>

Extensions et thèmes inactifs

Désactiver ne suffit pas. Une extension désactivée reste présente sur votre serveur avec tout son code PHP. Si une faille est découverte dans ce plugin, elle est exploitable même s’il est désactivé. En tant que co-créateur de WPS Hide Login (2 millions d’installations actives), j’ai vu des dizaines de sites compromis par des plugins "juste désactivés". La faille existait dans le code PHP présent sur le serveur, peu importe l’état d’activation.

La règle est simple : si vous ne l’utilisez pas, supprimez-le. Pareil pour les thèmes : gardez votre thème actif, un éventuel thème enfant, et un thème par défaut (Twenty Twenty-Five en 2026) comme filet de sécurité pour le Recovery Mode. Supprimez tout le reste.

Cas particulier : vous gardez un plugin désactivé "au cas où" ? Mauvaise idée. Si vous en avez besoin plus tard, vous le réinstallerez en 30 secondes. En attendant, il représente une surface d’attaque inutile sur votre serveur.

Mises à jour en arrière-plan

WordPress gère les mises à jour mineures (sécurité, corrections) automatiquement en arrière-plan. C’est un mécanisme de protection important : quand une faille critique est découverte, WordPress peut se patcher tout seul en quelques heures, sans attendre que vous vous connectiez à l’admin. Mais certaines constantes ou certains plugins bloquent ce mécanisme.

Les constantes qui bloquent :

• AUTOMATIC_UPDATER_DISABLED à true : bloque TOUTES les mises à jour auto (core, plugins, thèmes, traductions)
• WP_AUTO_UPDATE_CORE à false : bloque uniquement les mises à jour du coeur WordPress
• DISALLOW_FILE_MODS à true : bloque toute modification de fichier (mises à jour incluses, mais aussi installation de plugins)

Des plugins de gestion comme MainWP, ManageWP ou InfiniteWP prennent parfois le contrôle des mises à jour et désactivent le mécanisme natif. C’est normal si c’est voulu, mais vérifiez que c’est bien le cas. Si l’outil Santé du site vous signale un problème ici et que vous n’avez pas de plugin de gestion, vérifiez d’abord votre wp-config.php.

Communication avec WordPress.org

WordPress doit pouvoir communiquer avec les serveurs WordPress.org pour vérifier les mises à jour disponibles et télécharger les traductions. Si ce test échoue, le pare-feu de votre hébergeur bloque peut-être les connexions sortantes vers api.wordpress.org.

Solutions : contactez votre hébergeur pour whitelister les domaines WordPress.org. Vérifiez aussi que la constante WP_HTTP_BLOCK_EXTERNAL n’est pas à true dans votre wp-config.php. Si elle est nécessaire pour des raisons de sécurité, ajoutez une exception :

define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org' );

Requête de bouclage (loopback)

Le test de la requête de bouclage, ça vous parle ? C’est WordPress qui s’envoie une requête HTTP à lui-même. Si ça échoue, les tâches planifiées (WP-Cron), les mises à jour en arrière-plan et l’éditeur de blocs Gutenberg risquent de ne pas fonctionner correctement.

Pas de panique, c’est souvent un problème temporaire ou facile à résoudre. Les causes les plus fréquentes :

• Un plugin de sécurité (Wordfence, Sucuri, iThemes) qui bloque les requêtes internes : désactivez-le temporairement pour tester
• Un fichier .htaccess trop restrictif avec des règles de blocage IP
• Un problème de résolution DNS locale (le serveur ne sait pas résoudre son propre nom de domaine) : contactez votre hébergeur
• Un conflit avec un CDN mal configuré (Cloudflare en mode "Under Attack" par exemple)

Tâches planifiées (WP-Cron)

Ce test vérifie que le système de tâches planifiées WordPress fonctionne correctement. WP-Cron gère les publications programmées, les mises à jour automatiques, les nettoyages de corbeille, et tout ce que vos plugins planifient en arrière-plan.

Le problème : WP-Cron se déclenche uniquement quand un visiteur charge une page. Si votre site a peu de trafic, les tâches planifiées peuvent prendre du retard. C’est exactement notre cas sur wpformation.com : en architecture headless, personne ne visite l’admin WordPress directement, donc WP-Cron natif ne se déclenche jamais.

La solution : remplacer WP-Cron par un vrai cron système. Ajoutez dans wp-config.php :

define( 'DISABLE_WP_CRON', true );

Puis créez un cron serveur (via cPanel ou SSH) qui appelle wp-cron.php toutes les 5 minutes :

*/5 * * * * curl -s https://votre-site.com/wp-cron.php > /dev/null 2>&1

Résultat : vos tâches planifiées s’exécutent avec précision, et vous économisez le temps de chargement supplémentaire que WP-Cron natif ajoutait à chaque visite.

API REST disponible

WordPress teste que son API REST est fonctionnelle et accessible. L’API REST est le coeur du système en 2026 : l’éditeur Gutenberg en dépend, les mises à jour l’utilisent, et de nombreux plugins modernes communiquent via cette API.

Si ce test échoue, vérifiez que vos permaliens WordPress sont correctement configurés (Réglages > Permaliens, puis enregistrez sans rien changer, ça régénère le .htaccess). Vérifiez aussi qu’aucun plugin de sécurité ne bloque l’accès à /wp-json/. Certains plugins "durcissent" un peu trop les choses en désactivant l’API REST, ce qui casse Gutenberg et l’outil Santé du site lui-même.

Onglet État : les tests de performance

Au-delà de la sécurité, l’outil Santé du site analyse aussi la performance de votre configuration. Et c’est là que les choses deviennent vraiment intéressantes, parce que ces tests ont un impact direct sur la vitesse de votre site.

Version PHP

En 2026, le minimum requis par WordPress est PHP 7.4, mais il est fortement recommandé d’utiliser PHP 8.2 ou 8.3. PHP 7.4 est en fin de vie depuis novembre 2022 : plus aucune mise à jour de sécurité. PHP 8.0 est en fin de vie depuis novembre 2023. De facto, utiliser une version non maintenue expose votre site à des failles connues et non corrigées.

La différence de performance entre PHP 7.4 et PHP 8.x est considérable : on parle de 2 à 3 fois plus rapide pour le même code, grâce au compilateur JIT et aux optimisations internes. Sur un WordPress standard, le passage de PHP 7.4 à PHP 8.2 réduit le Time To First Byte (TTFB) de 30 à 50%. C’est l’optimisation la plus simple et la plus efficace que vous puissiez faire.

Pour changer de version PHP, rendez-vous dans le panneau de contrôle de votre hébergeur WordPress (cPanel > MultiPHP Manager chez O2switch, ou l’équivalent chez votre hébergeur). Mais avant de basculer, vérifiez la compatibilité de vos plugins et de votre thème. Le plugin "PHP Compatibility Checker" peut vous aider à anticiper les problèmes. Prévoir 30 minutes pour le test + la bascule.

Modules PHP requis et optionnels

WordPress a besoin de certains modules PHP pour fonctionner correctement. L’outil Santé du site liste ceux qui manquent. Voici le détail :

Modules requis : curl (requêtes HTTP), dom (traitement XML/HTML), exif (métadonnées images), fileinfo (détection type MIME), gd ou imagick (traitement images : recadrage, miniatures), intl (internationalisation), mbstring (caractères multi-octets : accents, emojis), openssl (chiffrement SSL), xml (parsing XML), zip (compression/décompression).

Modules recommandés : sodium (chiffrement moderne, requis pour les mises à jour sécurisées depuis WP 5.2), opcache (mise en cache du bytecode PHP : +30% de performances sans rien changer au code), redis ou memcached (pour le cache objet persistant).

Chez la plupart des hébergeurs (O2switch, Infomaniak, OVH), ces modules sont activés par défaut. Si l’un manque, contactez le support technique : c’est généralement une activation en un clic côté serveur. Point important : imagick est préférable à GD pour le traitement d’images (meilleure qualité, support WebP/AVIF natif). Si les deux sont présents, WordPress utilise automatiquement imagick.

Version du serveur SQL

WordPress recommande MariaDB 10.4+ ou MySQL 8.0+. Le test vérifie aussi la prise en charge du jeu de caractères UTF8mb4, indispensable pour stocker les emojis et tous les caractères spéciaux (y compris certains idéogrammes et symboles mathématiques). Si votre serveur ne le supporte pas, vous risquez de perdre des caractères dans vos contenus.

MariaDB ou MySQL ? La plupart des hébergeurs mutualisés utilisent MariaDB, qui est un fork de MySQL compatible et souvent plus performant. Pour un site WordPress standard, les deux fonctionnent parfaitement. Si vous êtes chez O2switch ou Infomaniak, vous êtes probablement sur MariaDB 10.6+ et UTF8mb4 est activé par défaut.

Cache objet persistant

Ce test est apparu avec WordPress 6.1. Le cache objet persistant (Redis ou Memcached) stocke en mémoire vive les résultats des requêtes à la base de données. Sans lui, WordPress interroge MySQL/MariaDB à chaque chargement de page, même pour des données qui ne changent jamais (options du site, structure des menus, widgets). Avec lui, ces données sont servies directement depuis la RAM : c’est 10 à 50 fois plus rapide qu’un accès disque.

Votre hébergeur prend-il en charge le cache objet persistant ? O2switch propose Redis en option (activable dans cPanel > Software > Redis). Kinsta, WP Engine et Cloudways l’activent par défaut. Infomaniak le propose sur ses offres WordPress gérées. Si le vôtre ne le fait pas et que vous dépassez quelques centaines de visiteurs par jour, la différence se fait sentir…

Redis ou Memcached ? Les deux font le même travail. Redis est plus populaire en 2026 car il offre la persistance des données (les données survivent à un redémarrage du service) et supporte des structures de données plus complexes. Pour WordPress, la différence pratique est négligeable. Prenez celui que votre hébergeur propose.

Détection du cache de page

Également ajouté avec WordPress 6.1, ce test vérifie si votre site utilise un système de cache de page. Le cache de page stocke la version HTML finale de vos pages et la sert directement, sans exécuter PHP ni interroger la base de données. C’est la couche de performance la plus visible pour vos visiteurs : le TTFB passe de 500-800ms à 50-100ms.

Si ce test échoue et que vous n’avez pas de plugin de cache, commencez par LiteSpeed Cache (si votre hébergeur utilise LiteSpeed : O2switch, Infomaniak, Hostinger), WP Super Cache (gratuit, simple) ou WP Rocket (payant, complet). Sur wpformation.com, nous utilisons LiteSpeed Cache avec d’excellents résultats : PageSpeed mobile 98.

Limite mémoire PHP

WordPress recommande une limite mémoire PHP d’au moins 128 Mo (256 Mo pour les sites avec WooCommerce ou beaucoup de plugins). Si la limite est trop basse, vous verrez des erreurs "Allowed memory size exhausted" lors de tâches gourmandes : import de médias, mises à jour groupées, ou exécution de plugins complexes.

Pour vérifier et modifier la limite, deux options. Dans wp-config.php :

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // pour l'admin uniquement

Ou dans le fichier .htaccess (si votre hébergeur le permet) :

php_value memory_limit 256M

Mon conseil : 256 Mo suffit pour 90% des sites WordPress. Au-delà, si vous avez encore des erreurs mémoire, c’est probablement un plugin qui fuit (memory leak) plutôt qu’un besoin réel d’augmenter la limite.

L’onglet Informations : chaque section décryptée

L’onglet Informations est souvent ignoré, et c’est une erreur. C’est LE premier endroit où regarder quand quelque chose ne fonctionne pas sur votre WordPress. Pas besoin de fouiller dans phpMyAdmin ou de se connecter en SSH : tout est là, organisé en 12 sections dépliables.

Vous contactez le support d’un plugin et on vous demande vos infos système ? Cliquez sur le bouton "Copier les informations du site dans le presse-papiers" en haut de l’onglet. En 2 clics, vous avez un rapport complet à coller dans votre ticket de support au lieu de passer 15 minutes à chercher chaque information manuellement.

Quand j’ai fondé WPServeur, on recevait des dizaines de tickets support par jour. La première chose qu’on demandait au client : "Collez-nous les infos de l’onglet Santé du site". Ça fait gagner un temps fou, des deux côtés. Et ça évite les allers-retours du type "quelle version de PHP ?", "quel thème ?", "quels plugins actifs ?"…

Voyons chaque section en détail.

Section WordPress

C’est la carte d’identité de votre installation. Vous y trouvez : la version de WordPress, l’URL du site et l’URL de WordPress (qui peuvent être différentes si WordPress est installé dans un sous-dossier), la structure des permaliens, le statut multisite, les constantes de debug actives, l’environnement (production, staging, development), et si les mises à jour automatiques sont activées.

Ce que je regarde en premier : la version de WordPress (est-elle à jour ?) et l’environnement. Si l’environnement est sur "development" en production, certains comportements changent (pas de cache de requêtes, plus de verbosité dans les erreurs). Vérifiez la constante WP_ENVIRONMENT_TYPE dans wp-config.php et assurez-vous qu’elle est bien sur "production".

Section Répertoires et tailles

C’est ici que vous repérez les problèmes de poids. Cette section affiche la taille du dossier WordPress, du dossier plugins, du dossier thèmes, du dossier uploads, et de la base de données. Chaque valeur est accompagnée du pourcentage par rapport à l’espace total.

Les signaux d’alerte :

• Base de données > 500 Mo pour un site de quelques centaines d’articles : problème de révisions non nettoyées, transients, ou logs accumulés
• Uploads > 5 Go : images non optimisées (originaux en 5000×3000 px), ou fichiers inutiles accumulés au fil des années
• Plugins > 500 Mo : un ou plusieurs plugins très lourds (Elementor avec ses templates, WooCommerce avec ses assets). Ça ne veut pas forcément dire qu’il y a un problème, mais ça mérite un coup d’oeil

Sur wpformation.com, la base de données fait environ 120 Mo pour 344 articles. Si la vôtre est disproportionnée, commencez par nettoyer les révisions (limitez-les à 5 via la constante WP_POST_REVISIONS dans wp-config.php) et purgez les transients expirés.

Section Serveur

La section serveur révèle tout sur l’environnement d’exécution PHP. Vous y trouverez : la version PHP, le handler SAPI (apache2handler, litespeed, fpm-fcgi), la mémoire allouée (memory_limit), la taille maximale d’upload (upload_max_filesize), la taille maximale de POST (post_max_size), le temps d’exécution maximum (max_execution_time), et la liste de toutes les extensions PHP chargées.

Tips concrets :

• max_execution_time : la valeur par défaut est 30 secondes. Si vous importez du contenu ou faites des opérations lourdes, 60 à 120 secondes est plus confortable. Chez O2switch, la valeur est de 300 secondes par défaut
• upload_max_filesize : si vous ne pouvez pas uploader un fichier, vérifiez cette valeur ET post_max_size (qui doit être supérieur). 64M suffit pour la plupart des usages
• SAPI litespeed ou fpm-fcgi : vous bénéficiez de meilleures performances que apache2handler (le handler Apache classique)

Section Base de données

Ici, vous voyez la version du serveur SQL (MySQL ou MariaDB), le nom de la base, l’utilisateur, le préfixe des tables, le jeu de caractères (charset) et l’interclassement (collation).

Deux vérifications rapides : le charset doit être utf8mb4 (pas utf8 qui est limité à 3 octets) et l’interclassement doit être utf8mb4_unicode_ci ou utf8mb4_unicode_520_ci. Si vous voyez latin1 quelque part, il y a un problème d’encodage à corriger, et certains caractères spéciaux ne s’afficheront pas correctement.

Le préfixe des tables (par défaut wp_) est aussi visible ici. Pour des raisons de sécurité, utiliser un préfixe personnalisé est recommandé. Si vous voyez wp_, c’est un changement facile à faire lors d’une nouvelle installation de WordPress, mais complexe à modifier sur un site existant (il faut renommer toutes les tables ET mettre à jour les options dans la base).

Sections Extensions et Thème actif

La liste complète des extensions actives et inactives, avec pour chacune : le nom, la version, l’auteur, et si les mises à jour automatiques sont activées. C’est ici que vous repérez un plugin en retard de 3 versions ou un plugin qui n’a pas été mis à jour depuis plus d’un an (potentiellement abandonné).

Pour le thème : nom, version, thème parent (si c’est un thème enfant), auteur. Vérifiez que votre thème actif est bien à jour et que la version correspond à celle du développeur.

Astuce : si un plugin premium n’affiche pas de mise à jour disponible alors qu’une nouvelle version existe, c’est souvent que votre licence a expiré. Le plugin ne peut plus communiquer avec le serveur de mises à jour. Renouvelez la licence ou trouvez une alternative.

Section Gestion des médias

Cette section indique quel éditeur d’images est actif (Imagick ou GD), les formats supportés, et la taille maximum d’upload. Imagick est meilleur que GD pour la qualité d’image et le support des formats modernes (WebP, AVIF). Si seul GD est disponible, vos images seront un peu plus lourdes à qualité égale.

Depuis WordPress 5.8, la génération automatique des images en format WebP est supportée nativement (si votre serveur le permet). Depuis WordPress 6.5, le format AVIF est aussi supporté. Vérifiez ici si votre serveur est compatible avec ces formats : ça peut diviser le poids de vos images par 2 ou 3 sans perte de qualité visible.

Section Constantes WordPress

Toutes les constantes définies dans wp-config.php et ailleurs sont listées ici avec leur valeur. C’est extrêmement utile pour diagnostiquer un problème sans accéder au serveur. Vous verrez si WP_DEBUG est activé, si DISALLOW_FILE_EDIT bloque l’éditeur de thème, si WP_CACHE est activé, si CONCATENATE_SCRIPTS est désactivé (ce qui peut ralentir l’admin)…

Les constantes à vérifier en priorité : WP_DEBUG (doit être false en prod), WP_CACHE (true si vous utilisez un plugin de cache), DISALLOW_FILE_EDIT (true pour la sécurité), WP_POST_REVISIONS (un nombre raisonnable, 5 ou 10, pas "true" qui est illimité).

Aller plus loin : les options avancées

Tout ce qu’on a vu jusqu’ici, c’est le socle. Mais si vous voulez vraiment exploiter l’outil Santé du site, il y a un niveau au-dessus. Et c’est pas fini…

Le plugin Health Check & Troubleshooting

Développé par la communauté WordPress.org (avec des contributeurs du core WordPress), c’est le plugin dont s’est inspiré l’outil natif. Il ajoute une fonctionnalité unique : le mode Troubleshooting. Ce mode désactive tous vos plugins et active un thème par défaut, mais uniquement dans votre session d’administration. Le site public reste intact pour vos visiteurs. C’est l’outil idéal pour diagnostiquer un conflit entre extensions sans casser quoi que ce soit.

Le principe : vous activez le mode Troubleshooting, puis vous réactivez vos plugins un par un jusqu’à identifier celui qui pose problème. Ça prend 5 minutes au lieu de 2 heures de tâtonnements. J’utilise cette méthode systématiquement en formation quand un stagiaire a un "bug bizarre" : 9 fois sur 10, c’est un conflit entre deux extensions.

Le plugin ajoute aussi un onglet "Troubleshooting" dans l’outil Santé du site avec des informations supplémentaires : vérification des fichiers du coeur (pour détecter des modifications non autorisées), et la possibilité de lancer des tests d’intégrité.

WP-CLI et Site Health

Depuis WordPress 6.6, la commande wp site health est disponible dans WP-CLI. C’est un changement important pour les administrateurs et les développeurs : vous pouvez maintenant lancer un diagnostic complet en ligne de commande, via SSH, sans même ouvrir l’administration WordPress.

# Lancer tous les tests Site Health
wp site health check

# Lister les tests disponibles avec leur statut
wp site health list --format=table

# Afficher les informations système complètes
wp site health info

# Filtrer un test spécifique
wp site health check --slug=debug_enabled

Ça paraît évident, mais… c’est indispensable quand votre site est inaccessible via le navigateur (écran blanc, erreur 500). En SSH avec WP-CLI, vous pouvez diagnostiquer le problème sans interface graphique. Et c’est aussi très pratique pour automatiser la surveillance de plusieurs sites : un script qui lance wp site health check sur chacun et vous alerte si un test échoue.

Les autoloaded options : le problème invisible

Les autoloaded options sont des données stockées dans la table wp_options de votre base de données et chargées automatiquement à chaque requête WordPress. Chaque. Requête. Même si les données ne servent pas pour cette page spécifique. C’est le problème de performance le plus fréquent et le moins visible sur les sites WordPress établis.

Pour mesurer leur poids, utilisez WP-CLI ou phpMyAdmin :

# Lister les autoloaded options triées par taille
wp option list --autoload=on --format=table --orderby=size_bytes --order=desc

# Voir le poids total des autoloaded options
wp db query "SELECT SUM(LENGTH(option_value)) as total_bytes FROM wp_options WHERE autoload='yes';"

# Identifier les 20 plus grosses options
wp db query "SELECT option_name, LENGTH(option_value) as size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Les seuils : en dessous de 800 Ko, tout va bien. Entre 800 Ko et 1 Mo, surveillez. Au-delà de 1 Mo, vous avez un problème. Au-delà de 5 Mo, c’est urgent (j’ai vu des sites à 15 Mo d’autoloaded options : le TTFB était à 3 secondes).

Les coupables habituels :

• Transients non nettoyés : des données temporaires qui s’accumulent quand le cron ne fonctionne pas
• Plugins désinstallés proprement mais qui laissent leurs options : un uninstall mal codé laisse des Ko voire Mo d’options inutiles
• Plugins d’analytics ou de statistiques qui stockent les données en base au lieu de les envoyer à un service externe
• Plugins de formulaire (Gravity Forms, WPForms) qui stockent les entrées dans wp_options au lieu de tables dédiées
• Fichiers CSS/JS inlinés par des thèmes premium qui stockent le CSS personnalisé dans une option de 500 Ko

Pour corriger : identifiez les options volumineuses avec la requête ci-dessus, puis désactivez l’autoload pour celles qui ne sont pas critiques au démarrage. En WP-CLI, la commande wp option update avec le flag –autoload=no fait le travail en une seconde. Attention : ne touchez pas aux options du coeur WordPress (siteurl, blogname, etc.).

Créer ses propres tests Site Health

Si tu es développeur ou que tu as un profil technique, WordPress te permet d’ajouter tes propres tests à l’outil Santé du site via le filtre site_status_tests. C’est extrêmement utile pour surveiller des choses spécifiques à votre installation.

Voici un exemple concret : un test qui vérifie si le répertoire uploads est accessible en écriture.

add_filter( 'site_status_tests', function( $tests ) {
    $tests['direct']['wpf_uploads_writable'] = array(
        'label' => 'Répertoire Uploads accessible en écriture',
        'test'  => function() {
            $result = array(
                'label'       => 'Le répertoire uploads est accessible en écriture',
                'status'      => 'good',
                'badge'       => array( 'label' => 'Performance', 'color' => 'blue' ),
                'description' => 'WordPress peut écrire dans le répertoire uploads.',
                'test'        => 'wpf_uploads_writable',
            );
            if ( ! wp_is_writable( wp_upload_dir()['basedir'] ) ) {
                $result['status'] = 'critical';
                $result['label']  = 'Le répertoire uploads n\'est PAS accessible en écriture';
                $result['description'] = 'WordPress ne peut pas télécharger de fichiers.';
            }
            return $result;
        },
    );
    return $tests;
});

Ce code se place dans un mu-plugin (plus fiable que functions.php, car il s’exécute avant les thèmes). Vous pouvez aussi utiliser le filtre debug_information pour ajouter vos propres sections dans l’onglet Informations. Les possibilités sont nombreuses : vérifier une clé API, tester la connexion à un service externe, contrôler la taille d’un répertoire, surveiller le nombre de révisions en base…

Autre exemple utile : un test qui vérifie le poids des autoloaded options et alerte au-delà de 1 Mo :

add_filter( 'site_status_tests', function( $tests ) {
    $tests['direct']['wpf_autoload_size'] = array(
        'label' => 'Poids des autoloaded options',
        'test'  => function() {
            global $wpdb;
            $size = $wpdb->get_var(
                "SELECT SUM(LENGTH(option_value)) FROM {$wpdb->options} WHERE autoload='yes'"
            );
            $size_mb = round( $size / 1024 / 1024, 2 );
            $result = array(
                'label'  => "Autoloaded options : {$size_mb} Mo",
                'status' => $size < 800000 ? 'good' : ( $size < 1500000 ? 'recommended' : 'critical' ),
                'badge'  => array( 'label' => 'Performance', 'color' => 'orange' ),
                'description' => "Les autoloaded options occupent {$size_mb} Mo en base de données.",
                'test'   => 'wpf_autoload_size',
            );
            return $result;
        },
    );
    return $tests;
});

Sécurité : ce que Site Health révèle (et ce qu’il cache)

L’outil Santé du site teste votre configuration technique. Mais il ne teste PAS tout ce qui fait la sécurité d’un site WordPress. Et cette nuance est importante.

Ce qu’il teste : HTTPS, mode debug, extensions inactives, mises à jour, communication avec WordPress.org, requêtes de bouclage, tâches planifiées, API REST. C’est déjà beaucoup.

Ce qu’il ne teste PAS : la solidité de vos mots de passe, les permissions de fichiers détaillées (est-ce que wp-config.php est en 644 ou 600 ?), les headers de sécurité (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), la présence d’un pare-feu applicatif (WAF), les tentatives de connexion brute force, les fichiers modifiés, les backdoors dans le code… Pour ça, vous avez besoin d’un audit de sécurité complet. On a un guide dédié pour sécuriser WordPress.

Un mot sur le Recovery Mode (mode de récupération). Depuis WordPress 5.2, quand une erreur fatale PHP se produit, WordPress ne plante plus avec un écran blanc. Il détecte l’erreur, désactive le code responsable, et vous envoie un email avec un lien de connexion spécial valable 24h pour corriger le problème. C’est un filet de sécurité précieux.

Si vous ne recevez pas ces emails, vérifiez votre adresse admin dans Réglages > Général. Vous pouvez aussi forcer l’adresse dans wp-config.php :

define( 'RECOVERY_MODE_EMAIL', 'votre@email.com' );

Quid des endpoints REST API de Site Health ? Les URLs /wp-json/wp-site-health/v1/tests/ sont protégées par authentification. Seuls les administrateurs connectés peuvent les appeler. Mais si votre API REST est mal configurée ou si vous avez un plugin qui expose trop de données, ces endpoints peuvent révéler des informations sur votre configuration serveur. Pour aller plus loin sur la protection de votre installation, pensez aussi à activer la double authentification (2FA).

Les erreurs les plus courantes et leurs solutions

Passons au concret. Voici les messages d’erreur les plus fréquents dans l’outil Santé du site, avec pour chacun la cause probable et la marche à suivre. Format : problème, cause, solution. Efficace.

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

C’est l’erreur la plus fréquente et souvent la plus déroutante.

Cause #1 : un plugin de sécurité (Wordfence, Sucuri, iThemes Security) bloque les requêtes internes. Désactivez-le temporairement et retestez. Cause #2 : le pare-feu de votre hébergeur bloque la requête, contactez le support. Cause #3 : la constante WP_HTTP_BLOCK_EXTERNAL est à true dans wp-config.php, ajoutez l’exception avec WP_ACCESSIBLE_HOSTS. Cause #4 : un timeout serveur (max_execution_time trop bas ou serveur surchargé). Cause #5 : un CDN mal configuré (Cloudflare en mode "I’m Under Attack" bloque les requêtes internes du serveur).

"Des extensions ont des mises à jour disponibles"

Ça paraît simple : mettez à jour. Sauf que ce n’est pas toujours aussi évident. Les extensions premium (Elementor Pro, WP Rocket, ACF Pro, Astra Pro) ne se mettent pas à jour via le système standard si votre licence a expiré. Et certains plugins abandonnés par leurs développeurs n’auront plus jamais de mise à jour.

La bonne approche : pour les plugins premium, renouvelez la licence ou trouvez une alternative maintenue. Pour les plugins abandonnés (pas de mise à jour depuis plus de 2 ans), remplacez-les : un plugin abandonné est une bombe à retardement. Consultez notre guide sur les erreurs WordPress pour les cas les plus complexes.

"Le mode debug est actif"

Ouvrez votre wp-config.php, mettez les 3 constantes (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY) à false, enregistrez. C’est réglé en 30 secondes. Si vous avez besoin du mode debug pour diagnostiquer un problème, activez-le le temps de votre test, puis désactivez-le immédiatement après. Jamais plus de quelques minutes en production.

"Votre version de PHP est obsolète"

Changez de version PHP dans le panneau de votre hébergeur. Avant de le faire, installez le plugin "PHP Compatibility Checker" et lancez un scan. Si tout est vert, basculez. Si des incompatibilités sont détectées, mettez à jour les plugins concernés d’abord. À minima, visez PHP 8.1 en 2026. Idéalement PHP 8.2 ou 8.3.

"Un cache objet persistant n’est pas utilisé"

Si votre hébergeur propose Redis ou Memcached, activez-le. Chez O2switch, c’est disponible dans cPanel. Chez Infomaniak, c’est dans le panneau WordPress. Si votre hébergeur ne le propose pas et que votre site est un petit blog avec peu de trafic, vous pouvez ignorer cette recommandation. Mais si vous gérez un site avec du trafic (plus de 500 visiteurs/jour), c’est le moment de considérer soit l’option Redis de votre hébergeur, soit un hébergement qui le supporte nativement.

"Un ou plusieurs modules PHP requis sont manquants"

Le message vous indique quel module manque. Contactez votre hébergeur : l’activation prend quelques secondes côté serveur. Les modules les plus souvent manquants : imagick (traitement d’images avancé), intl (internationalisation), sodium (chiffrement moderne). Chez les hébergeurs sérieux, une demande au support suffit. Si votre hébergeur ne peut pas activer le module, c’est un signal sur la qualité de l’hébergement.

Comment les hébergeurs personnalisent Site Health

Un aspect souvent méconnu : les hébergeurs modifient les tests de l’outil Santé du site. Et ça a un impact direct sur votre score.

WordPress permet aux hébergeurs d’ajouter, supprimer ou modifier des tests via le filtre site_status_tests. C’est le même filtre que celui utilisé pour créer des tests custom. En pratique :

• LiteSpeed ajoute des tests spécifiques à son cache (LiteSpeed Cache). Si vous êtes chez un hébergeur LiteSpeed (O2switch, Infomaniak), vous verrez des recommandations que les utilisateurs d’Apache ou Nginx classique ne voient pas
• Kinsta et WP Engine suppriment certains tests qui ne s’appliquent pas à leur infrastructure gérée (version PHP contrôlée par eux, cache objet intégré)
• Cloudways ajoute des tests liés à son système de cache Varnish
• Certains hébergeurs désactivent le test du cache objet persistant quand ils gèrent eux-mêmes cette couche, pour ne pas afficher de faux négatif

Ce que ça signifie pour vous : votre score Santé du site peut varier d’un hébergeur à l’autre sans que vous ayez changé quoi que ce soit à votre installation. Ne comparez pas votre score avec celui d’un autre site hébergé ailleurs. Concentrez-vous sur VOS problèmes critiques, pas sur un chiffre.

Questions fréquentes

Un score "Bien" sur Santé du site garantit-il que mon site est sécurisé ?

Non. L’outil Santé du site teste votre configuration technique (HTTPS, mode debug, mises à jour, extensions inactives), pas la qualité de vos mots de passe, la solidité de vos extensions ou la présence d’un pare-feu. C’est un diagnostic partiel. Pour une sécurité complète, il faut un audit dédié et des mesures complémentaires : 2FA, pare-feu applicatif, headers de sécurité, monitoring.

Faut-il viser un score parfait sur l’outil Santé du site ?

Non. Certaines recommandations sont contextuelles. Par exemple, une extension inactive sur un site de développement n’est pas un problème. WordPress lui-même indique que le score est informatif. Corrigez les problèmes critiques en priorité, évaluez les recommandations au cas par cas. Un score "Bien" suffit pour un site en bonne santé.

L’outil Santé du site ralentit-il mon WordPress ?

Non. Les tests s’exécutent uniquement quand vous visitez la page Santé du site ou via des appels REST API périodiques en arrière-plan. L’impact sur les performances est négligeable en fonctionnement normal. L’outil ne fait rien quand personne ne le consulte.

Comment désactiver un test Site Health qui ne me concerne pas ?

Utilisez le filtre PHP site_status_tests dans votre functions.php ou un mu-plugin. Exemple pour retirer le test du mode debug : add_filter(‘site_status_tests’, function($tests) { unset($tests[‘direct’][‘debug_enabled’]); return $tests; }); Chaque test a un identifiant que vous pouvez retrouver dans le code source de WordPress (fichier wp-admin/includes/class-wp-site-health.php).

Santé du site affiche "problème critique" mais mon site fonctionne normalement. Que faire ?

Un problème critique ne signifie pas que votre site est cassé. Ça signifie qu’il y a un risque de sécurité, de performance ou de compatibilité. Corrigez-le même si tout semble fonctionner : le problème peut se manifester plus tard, lors d’une mise à jour ou sous charge de trafic. Mieux vaut prévenir.

Le plugin Health Check and Troubleshooting est-il toujours utile si WordPress intègre déjà l’outil Santé du site ?

Oui. Le plugin ajoute un mode Troubleshooting exclusif qui désactive plugins et thèmes uniquement pour votre session d’administration. Le site public reste intact pour vos visiteurs. C’est l’outil de diagnostic idéal quand vous soupçonnez un conflit entre extensions. L’outil natif ne propose pas cette fonctionnalité.

Garder un oeil sur la santé de votre WordPress

L’outil Santé du site est un point de départ, pas une destination. Il vous donne une photographie à un instant T de votre configuration. Mais WordPress évolue, vos plugins se mettent à jour, votre hébergeur change des paramètres… Ce diagnostic mérite d’être consulté régulièrement, à minima une fois par mois.

Bref. Pour ceux qui gèrent plusieurs sites, des outils comme ManageWP ou WP Umbrella centralisent ces diagnostics et vous alertent quand quelque chose change. Et pour les profils techniques, les tests custom via site_status_tests transforment l’outil en un vrai tableau de bord de monitoring personnalisé.

Et vous, à quelle fréquence vous allez vérifier la santé de votre WordPress ? Certain d’en avoir oublié, mais l’essentiel est là. Pour creuser le sujet de la performance et de la maintenance, jetez un oeil à nos guides sur la sécurité WordPress, sur WP-CLI et sur comment préparer son WordPress pour les vacances.