Régler les problèmes critiques de Santé du site WordPress sur un serveur cPanel

Cet article vous montre comment régler les éléments que la Santé du site WordPress marque en rouge sur un serveur cPanel ou WHM. Il s’adresse à toute personne qui exploite le site et qui peut aussi ouvrir une session en ligne de commande sur le serveur. La Santé du site se trouve sous Outils → Santé du site ; elle lance une série de vérifications automatiques et classe chacune en réussite, recommandation ou problème critique. Sa formulation reste volontairement générale, si bien qu’une ligne rouge comme L'API REST a rencontré une erreur recouvre une douzaine de causes différentes. La réponse courte, c’est de reproduire chaque élément avec une seule commande avant tout le reste, parce que la commande vous donne le vrai code de statut et le vrai texte d’erreur. À la fin, les vraies pannes seront corrigées et vous aurez la liste des éléments que vous pouvez laisser rouges volontairement.

Ce que vous allez accomplir

• Reproduire n’importe quel élément de Santé du site avec une commande, au lieu de deviner.
• Corriger les pannes d’API REST et de bouclage à la couche qui en est responsable.
• Placer le compte sur une version de PHP encore soutenue, avec les extensions d’images voulues.
• Sortir les tâches planifiées du pseudo-cron et les confier à une vraie tâche cron.
• Distinguer les vraies pannes des vérifications qui peuvent rester rouges sans danger.

Prérequis

• WordPress 6.0 ou plus récent. La Santé du site est arrivée avec la 5.2 et sa liste de tests s’allonge, donc votre écran peut afficher des éléments absents d’ici.
• Un accès en ligne de commande sur le compte, par SSH ou par le Terminal de cPanel, et curl.
• WP-CLI, l’outil WordPress en ligne de commande, disponible comme wp. La plupart des serveurs cPanel le fournissent, et chaque étape ci-dessous fonctionne aussi depuis cPanel et le navigateur.
• Un accès cPanel au Gestionnaire MultiPHP et à l’Éditeur INI MultiPHP. Trois correctifs demandent plutôt WHM ou root, et chacun le précise.
• Savoir si Cloudflare ou un autre WAF se trouve devant le site. WAF veut dire pare-feu applicatif web, un filtre qui inspecte les requêtes avant qu’elles n’atteignent votre serveur.

Comment ça fonctionne

La Santé du site lance deux types de tests. Les tests directs s’exécutent dans la requête de page et lisent tout de suite votre version de PHP, celle de la base de données et la liste des extensions. Les tests asynchrones partent ensuite de votre navigateur, sous forme de requêtes REST distinctes vers le site. REST veut dire Representational State Transfer ; dans WordPress, cela désigne l’interface JSON sous /wp-json/. Ce second groupe produit la plupart des points rouges, parce que ces tests exigent que le site se joigne lui-même par le réseau.

Deux vérifications rendent cette dépendance évidente. Le test de l’API REST demande wp-json/wp/v2/types/post en contexte d’édition et attend un 200. Le test de bouclage envoie un POST à wp-cron.php sur votre propre adresse de site et attend un 200 lui aussi. Une requête de bouclage, c’est WordPress qui demande une page de son propre site en HTTP, par votre nom d’hôte public plutôt que par un raccourci dans le système de fichiers. Elle sort du serveur et doit revenir.

L’autre moitié de l’outil, c’est l’écran d’information de débogage sous Outils → Santé du site → Info. Il liste votre logiciel serveur, la version de PHP, les extensions chargées, les constantes et la taille des répertoires. Son bouton Copier les infos du site produit un bloc de texte à coller dans un billet au bureau de support.

Le cœur de WordPress ne fournit aucune commande wp site-health pour WP-CLI ; le triage en ligne de commande passe donc par wp, curl, php et grep. Gardez aussi en tête que les tests de Santé du site sont des heuristiques à deux issues. Ce sont des règles du pouce écrites pour une installation moyenne, et plusieurs restent rouges sur un serveur bien tenu, pour de bonnes raisons.

Étape par étape

1. Confirmez les deux adresses qu’utilise WordPress. Chaque test ci-dessous en découle.

wp option get home
wp option get siteurl

https://example.com
https://example.com

Si l’une des deux diffère de l’adresse que vous tapez dans le navigateur, corrigez-la d’abord. WordPress construit ses URL de bouclage et d’API REST à partir de siteurl, donc une valeur périmée envoie chaque autotest au mauvais endroit.

2. Reproduisez l’élément de l’API REST et lisez le code de statut. L’option -w '%{http_code}\n' n’affiche que le statut ; -o /dev/null jette le corps.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-json/wp/v2/types/post

200

Un 200 veut dire que la route répond aux lecteurs anonymes. Lisez maintenant le corps, car une extension peut retourner un 200 qui transporte une erreur :

curl -sS https://example.com/wp-json/wp/v2/types/post | head -c 160

{"post":{"description":"","hierarchical":false,"name":"Posts","slug":"post"

Du JSON qui commence par {"post": est une réponse saine. Du HTML ou un avis PHP en tête du corps veut dire que quelque chose s’affiche avant la réponse de WordPress. Le test du navigateur échoue là-dessus même avec un statut 200.

3. Reconnaissez les codes qui ne sont pas des pannes. Le test de Santé du site envoie votre témoin de connexion et ajoute context=edit. Sans témoin, cette requête doit être refusée :

curl -sS -o /dev/null -w '%{http_code}\n' 'https://example.com/wp-json/wp/v2/types/post?context=edit'

401

Un 401 à cet endroit est le comportement normal, pas la panne que vous cherchez. Les codes qui signalent vraiment un défaut sont 403, 404 et 500. Un 403 avec un corps HTML vient d’habitude d’une extension de sécurité, ou de ModSecurity, le module Apache de filtrage des requêtes que cPanel active par défaut :

grep -c 'wp-json' /usr/local/apache/logs/modsec_audit.log

17

Tout compte supérieur à zéro veut dire que ModSecurity accroche des requêtes REST. WHM liste les mêmes événements avec les numéros de règles sous Centre de sécurité → Outils ModSecurity → Liste des occurrences, et c’est là qu’on désactive une règle pour un seul domaine. Désactivez cet identifiant de règle plutôt que le moteur au complet.

Un 404 avec un corps {"code":"rest_no_route" est plutôt un problème de réécriture. Réenregistrez les permaliens sous Réglages → Permaliens, puis vérifiez que le .htaccess du compte porte toujours le bloc WordPress. Si la panne survit à cela, le guide des erreurs de l’API REST WordPress couvre chaque code d’erreur, et le manuel de l’API REST WordPress documente les routes.

4. Rétablissez l’en-tête Authorization si les mots de passe d’application échouent. Certaines configurations cPanel exécutent PHP par CGI, ce qui retire l’en-tête Authorization avant que PHP le voie. Testez avec un mot de passe d’application créé sous Utilisateurs → Profil :

curl -sS -o /dev/null -w '%{http_code}\n' -u 'admin:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://example.com/wp-json/wp/v2/users/me

200

Si la réponse est 401 alors que les mêmes identifiants fonctionnent dans l’administration, ajoutez deux lignes en tête du .htaccess du compte :

CGIPassAuth On
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Relancez la commande curl. Le 200 apparaît sans aucun redémarrage.

5. Reproduisez l’élément de bouclage depuis l’intérieur du compte. Lancez ceci par SSH sur le serveur, pas depuis votre poste, parce que la question porte sur ce que le serveur voit.

curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' -X POST https://example.com/wp-cron.php

200 198.51.100.40

Un 200 veut dire que le bouclage fonctionne et que l’élément est périmé ; rechargez la page. Le champ %{remote_ip} montre quelle adresse le serveur a réellement jointe. Épinglez maintenant le nom d’hôte sur la machine locale et comparez :

curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' \
  --resolve example.com:443:127.0.0.1 -X POST https://example.com/wp-cron.php

200 127.0.0.1

L’option --resolve garde le nom d’hôte et le certificat intacts tout en envoyant les paquets à l’adresse que vous nommez. Si la requête épinglée passe et que la publique échoue, la cassure est hors du serveur, dans le DNS, le CDN ou le pare-feu. Si les deux échouent pareil, la cassure est dans WordPress ou dans l’hôte virtuel, et l’étape 6 la démêle.

Dans le premier cas, demandez à la personne qui gère le pare-feu de laisser l’adresse publique du serveur joindre les ports 80 et 443 sur lui-même. Ajouter le domaine et l’adresse interne du serveur dans /etc/hosts fonctionne aussi, mais cela exige root et touche tous les comptes de la machine.

6. Déterminez à qui appartient chaque élément restant avant de modifier quoi que ce soit. La même forme de réponse vaut pour chaque ligne de l’écran.

Quand les deux requêtes de bouclage échouent, la responsable habituelle est une extension. Listez ce qui tourne, puis arrêtez les suspectes une à une sur une copie de préproduction :

wp plugin list --status=active --field=name

akismet
wordfence
woocommerce

Les extensions de sécurité, de mise en cache et de mode « bientôt en ligne » sont les trois familles qui répondent aux requêtes de bouclage par un 403 ou une redirection.

7. Corrigez « Une tâche planifiée a échoué ». Un crochet a manqué sa fenêtre. Regardez d’abord la file :

wp cron event list --fields=hook,next_run_relative,recurrence | head -5

+------------------------+-------------------+------------+
| hook                   | next_run_relative | recurrence |
+------------------------+-------------------+------------+
| wp_version_check       | 3 hours 12 mins   | 12 hours   |
| woocommerce_cleanup    | now               | 1 day      |

Tout ce qui affiche now est en retard. Passez l’arriéré à la main :

wp cron event run --due-now

Success: Executed a total of 3 cron events.

Si les tâches s’exécutent proprement à la main et échouent quand même toutes seules, la cause est le pseudo-cron. WordPress déclenche le travail planifié au chargement des pages par les visiteurs ; un site tranquille ne le lance donc jamais, et une panne de bouclage l’arrête aussi. Le correctif durable consiste à mettre DISABLE_WP_CRON à vrai et à ajouter une vraie tâche cron :

wp config get DISABLE_WP_CRON

true

Ajoutez ensuite cette entrée dans les Tâches cron de cPanel, avec votre propre chemin de compte et votre version de PHP :

*/5 * * * * /opt/cpanel/ea-php82/root/usr/bin/php /home/exampleco/public_html/wp-cron.php >/dev/null 2>&1

Cinq minutes conviennent à la plupart des sites. Prenez une minute là où une confirmation de commande ou une reprise de paiement doit partir vite. La configuration complète, multisite compris, se trouve dans remplacer WP-Cron par le cron système.

8. Répondez honnêtement à « Vous devriez utiliser un cache objet persistant ». Vérifiez ce que WordPress utilise en ce moment :

wp eval 'echo wp_using_ext_object_cache() ? "external" : "internal", "\n";'

internal

Cet élément est une recommandation, jamais un problème critique. Un cache objet persistant garde les résultats de requêtes de base de données entre deux requêtes web, en général dans Redis. Il rapporte quand la plupart des visiteurs sont connectés, quand WooCommerce ou une extension d’adhésion tourne, ou quand vos pages les plus lentes passent leur temps dans la base. Il change peu de chose sur un site vitrine qui sert le même HTML en cache à tout le monde. La mesure qui tranche se trouve dans la recommandation de cache objet persistant.

9. Fixez la version de PHP et ajoutez les extensions manquantes. Le binaire php de votre session diffère souvent de celui qui sert le site ; vérifiez les deux :

php -v
/opt/cpanel/ea-php82/root/usr/bin/php -v

PHP 8.1.29 (cli) (built: Jun 12 2026 11:20:41) (NTS)
PHP 8.2.23 (cli) (built: Sep  3 2026 09:11:02) (NTS)

Le chemin sous /opt/cpanel/ea-phpXX/ est le binaire d’une version de PHP bâtie par EasyApache 4, la pièce de cPanel qui empaquette Apache et PHP. Réglez la version d’un domaine sous Logiciel → Gestionnaire MultiPHP, en prenant la plus récente que vos extensions acceptent. Vérifiez ensuite les bibliothèques d’images :

/opt/cpanel/ea-php82/root/usr/bin/php -m | grep -Ei '^gd$|^imagick$'

gd

WordPress utilise imagick quand il est présent et retombe sur gd sinon ; les deux redimensionnent et recadrent les images. imagick, la liaison PHP vers ImageMagick, lit aussi les PDF et conserve les profils de couleur, d’où la mention dans la Santé du site. Un site avec seulement gd fonctionne. Pour l’ajouter, un utilisateur root installe le paquet EasyApache 4 de cette version exacte de PHP :

dnf install -y ea-php82-php-imagick

Installed:
  ea-php82-php-imagick-3.7.0-1.el8.x86_64

WHM fait la même chose sous Logiciel → EasyApache 4 → Personnaliser → Extensions PHP. Vérifiez contre le même binaire :

/opt/cpanel/ea-php82/root/usr/bin/php -i | grep -i 'imagick module'

imagick module => enabled
imagick module version => 3.7.0

Les réglages par compte comme memory_limit appartiennent à l’Éditeur INI MultiPHP de cPanel, qui les écrit pour la version que ce compte exécute. La référence de cPanel pour ces écrans se trouve sur docs.cpanel.net.

10. Sortez le journal de débogage de la racine web. L’élément sur les erreurs consignées dans un fichier potentiellement public a deux volets. WP_DEBUG_LOG est actif, et le journal se trouve là où les visiteurs peuvent le lire.

wp config get WP_DEBUG_LOG
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/debug.log

true
200

Ce 200 confirme que n’importe qui peut télécharger le fichier. Les journaux de débogage transportent des chemins, des erreurs de base de données et parfois des jetons. Déplacez le fichier au-dessus de la racine web plutôt que de le cacher par une règle de réécriture. Modifiez wp-config.php :

define( 'WP_DEBUG_LOG', '/home/exampleco/logs/wp-debug.log' );

Créez le répertoire, puis vérifiez que l’ancienne URL a disparu et que le nouveau fichier se remplit :

mkdir -p /home/exampleco/logs
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/debug.log
tail -2 /home/exampleco/logs/wp-debug.log

404
[11-Sep-2026 14:02:55 UTC] PHP Notice:  Function _load_textdomain_just_in_time was called incorrectly.

Si vous n’êtes pas en train de déboguer, mettez plutôt WP_DEBUG_LOG à faux.

11. Réglez les mises à jour en arrière-plan et HTTPS. Les mises à jour passent au rouge dans trois cas. AUTOMATIC_UPDATER_DISABLED est défini, le répertoire WordPress n’est pas accessible en écriture, ou le bouclage a déjà échoué. Corrigez le bouclage d’abord et cet élément se règle souvent tout seul. L’élément HTTPS vérifie que les deux adresses de l’étape 1 sont en https et que le certificat se valide :

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://example.com/

200 0

Un 0 dans le second champ veut dire que la chaîne s’est validée. Tout autre nombre veut dire qu’elle est incomplète ou expirée, ce qui se renouvelle sous Sécurité → État SSL/TLS.

Vérifier que ça fonctionne

Lancez depuis le serveur les trois requêtes qui intéressent la Santé du site :

for u in / /wp-json/wp/v2/types/post /wp-cron.php; do
  printf '%-28s ' "$u"
  curl -sS -o /dev/null -w '%{http_code}\n' -X POST "https://example.com$u"
done

/                            200
/wp-json/wp/v2/types/post    200
/wp-cron.php                 200

Trois lignes 200 veulent dire que le côté réseau est sain. Confirmez que l’ordonnanceur est reparti en cherchant des heures d’exécution à venir plutôt que now :

wp cron event list --fields=hook,next_run_relative | head -4

| wp_version_check       | 11 hours 44 mins  |
| woocommerce_cleanup    | 22 hours 3 mins   |

Rechargez ensuite Outils → Santé du site et laissez les tests asynchrones repartir. L’écran garde son dernier résultat en cache ; faites un rechargement forcé avant de conclure qu’un correctif n’a rien donné.

Dépannage

La Santé du site affiche encore l’ancienne erreur après un curl réussi. Les tests du navigateur portent votre témoin de connexion et la vue DNS du navigateur. Le curl lancé sur le serveur n’a ni l’un ni l’autre. Rechargez une fois, puis cherchez une règle WAF qui traite le trafic du navigateur autrement.

Le test de bouclage passe avec --resolve et échoue sur l’adresse publique. La cassure est hors du serveur. Portez-la à la personne qui gère le CDN ou le pare-feu.

Chaque requête REST retourne 403 avec un corps HTML, même depuis curl. C’est ModSecurity ou une extension de sécurité. Le grep de l’étape 3 dit laquelle, parce qu’une extension ne laisse rien dans modsec_audit.log.

La version de PHP a changé mais la Santé du site annonce l’ancienne. Un domaine et ses sous-domaines peuvent exécuter des versions différentes. Un alias peut aussi pointer encore vers l’ancien gestionnaire. Vérifiez chaque entrée du compte, puis confirmez par HTTP plutôt qu’en ligne de commande.

Quand ce n’est pas la bonne approche

Certains éléments de Santé du site peuvent rester rouges sans danger, et savoir lesquels évite bien du travail perdu. Ignorez la recommandation de cache objet quand les visiteurs sont surtout déconnectés. L’avertissement sur les mises à jour en arrière-plan est normal quand votre hébergeur applique les correctifs sur un calendrier maîtrisé. L’élément imagick peut rester si vous ne servez ni PDF ni photographie de qualité d’impression. Les avertissements sur un thème inactif, ou le test de cache de page sur un site servi par un CDN, sont cosmétiques. Chacun signale un écart par rapport à une installation typique, pas un défaut.

Trois éléments méritent une action chaque fois. Une version de PHP dépassée et un journal de débogage lisible sont une exposition de sécurité. Une requête de bouclage en panne arrête en silence le travail planifié, les mises à jour et plusieurs fonctions d’extensions.

La Santé du site est aussi le mauvais outil pour les questions de performance. Elle rend compte de la configuration, pas de ce que vivent les visiteurs ; un site qui réussit tous les tests peut rester lent. Sur un hébergement partagé sans root, les étapes 3, 5 et 9 ne sont pas les vôtres. Envoyez à votre hébergeur la sortie des commandes curl ci-dessus : un code de statut et un remote_ip transforment un billet flou en billet sur lequel il peut agir.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.