Un audit WordPress consiste à vérifier méthodiquement la sécurité, la performance et le SEO technique de votre site pour détecter les failles avant qu’elles ne coûtent des visites ou un piratage. La méthode complète tient en 15 contrôles précis : version du cœur, PHP, HTTPS, mode debug, éditeur de fichiers, API REST, XML-RPC, préfixe de base, compte admin, listage des dossiers, cache objet, révisions, WP-Cron, visibilité moteurs et permaliens. Pour aller vite, notre plugin gratuit Ausculte exécute ces 15 contrôles en un clic, note votre site sur 100 et fournit le remède en une ligne pour chaque problème. Ce guide détaille la méthode manuelle complète, puis montre comment l’automatiser.
Qu’est-ce qu’un audit WordPress exactement ?
Un audit WordPress est un état des lieux technique structuré de votre installation. Il répond à trois questions : votre site peut-il être compromis facilement, sert-il ses pages assez vite, et les moteurs de recherche peuvent-ils l’explorer sans obstacle. Ces trois axes correspondent aux trois familles de contrôles : sécurité, performance et SEO technique.
Un bon audit se distingue d’un simple coup d’œil par deux propriétés : il est reproductible, c’est à dire que deux personnes qui suivent la même checklist obtiennent le même diagnostic, et il est actionnable, c’est à dire que chaque constat s’accompagne d’une correction concrète. C’est exactement ce que produit la checklist en 15 points de ce guide.
La bonne fréquence : un audit complet après chaque installation, après chaque migration ou changement d’hébergeur, puis un contrôle mensuel de routine. Un site WordPress évolue en permanence, avec les mises à jour du cœur, des extensions et du thème, et un réglage correct aujourd’hui peut se dégrader demain.
Pourquoi auditer votre site maintenant
Le cœur WordPress obsolète reste le vecteur d’infection numéro un, devant les extensions vulnérables et les mots de passe faibles. La majorité des compromissions exploitent des failles corrigées depuis des mois : les correctifs existaient, ils n’étaient simplement pas appliqués. Un audit régulier transforme ce risque invisible en liste de tâches claire.
La performance suit la même logique. Un back office qui rame ou des pages lentes proviennent rarement d’une seule cause spectaculaire : ce sont des révisions accumulées par milliers, un WP-Cron déclenché à chaque visite ou l’absence de cache objet qui s’additionnent. Chaque point se corrige en quelques minutes une fois identifié. Si votre tableau de bord se traîne déjà, notre guide sur le back office WordPress lent complète parfaitement cet audit.
La checklist d’audit WordPress en 15 points
Voici la checklist complète, celle que nous appliquons à nos propres sites. Chaque ligne indique le contrôle, sa famille et le risque encouru si le point est défaillant.
| Contrôle | Famille | Risque si défaillant |
|---|---|---|
| Cœur WordPress à jour | Sécurité | Failles connues exploitables |
| Version PHP supportée | Sécurité | Plus de correctifs de sécurité |
| HTTPS actif partout | Sécurité | Identifiants interceptables |
| Mode debug désactivé | Sécurité | Chemins et erreurs PHP exposés |
| Éditeur de fichiers bloqué | Sécurité | Injection de code via wp-admin |
| Énumération REST bloquée | Sécurité | Identifiants de connexion révélés |
| XML-RPC désactivé | Sécurité | Amplification de force brute |
| Préfixe de base personnalisé | Sécurité | Injections SQL automatisées facilitées |
| Aucun compte « admin » | Sécurité | Moitié du travail offerte aux robots |
| Listage des dossiers bloqué | Sécurité | Contenu de uploads exposé |
| Cache objet persistant | Performance | Requêtes SQL répétées à chaque page |
| Révisions limitées | Performance | Table wp_posts qui enfle |
| WP-Cron maîtrisé | Performance | Tâches déclenchées par les visiteurs |
| Site visible des moteurs | SEO technique | Désindexation totale silencieuse |
| Permaliens propres | SEO technique | URL illisibles et pauvres en mots clés |
Vous pouvez vérifier chaque point à la main, réglages par réglages, fichiers par fichiers. Comptez 45 minutes à une heure la première fois. Ou vous pouvez laisser un outil le faire en quelques secondes : c’est la raison d’être d’Ausculte.
Ausculte : le plugin gratuit qui automatise ces 15 contrôles
Ausculte est le plugin d’audit que notre rédaction a développé, d’abord pour nos propres sites. Il exécute les 15 contrôles de la checklist ci-dessus directement dans votre tableau de bord, calcule un score de santé sur 100 et affiche, pour chaque problème détecté, une explication d’une ligne et le remède exact : la constante wp-config à poser, le réglage à changer ou la règle serveur à ajouter.

Trois choix de conception le distinguent des services d’audit en ligne :
- 100 % local : tous les contrôles s’exécutent sur votre serveur. Aucune donnée n’est envoyée à un service tiers, aucun compte n’est requis, aucun traceur n’est embarqué. Les seules requêtes HTTP sont des boucles de votre site vers lui-même pour tester les points d’entrée publics.
- Léger : quelques fichiers PHP, zéro dépendance externe, des résultats mis en cache 5 minutes. Les contrôles ne tournent que dans wp-admin, jamais pour vos visiteurs.
- Transparent : le code est publié sous licence GPL et lisible en quelques minutes. Vous pouvez vérifier ce qu’il fait avant de lui faire confiance, et l’adapter à vos besoins.
Le plugin est en cours de validation sur le répertoire officiel wordpress.org. En attendant la publication de sa fiche, vous pouvez le télécharger directement depuis notre site.
Installer Ausculte et lancer votre premier audit
- Téléchargez
ausculte.zipdepuis le lien ci-dessus, ou depuis la fiche wordpress.org dès sa mise en ligne. - Dans votre tableau de bord, ouvrez Extensions puis Ajouter, cliquez sur Téléverser une extension et sélectionnez le fichier zip.
- Activez le plugin. C’est terminé : aucune configuration n’est nécessaire.
Dès l’activation, deux éléments apparaissent : un widget « Ausculte » sur l’accueil du tableau de bord, avec le score et les 3 problèmes prioritaires, et une entrée « Ausculte » dans le menu latéral qui ouvre le rapport complet, organisé par famille de contrôles, avec un bouton pour relancer l’audit à la demande.

Comprendre le score sur 100
Le score part de 100 points et retire un poids par problème selon sa gravité : un point critique coûte cher, un avertissement coûte moins, une simple notice coûte peu. Quatre paliers de lecture : excellent au dessus de 90, correct entre 75 et 90, à travailler entre 50 et 75, préoccupant en dessous de 50.

Exercice de transparence : au moment où nous écrivons ces lignes, wpadminlab.com affiche 54 sur 100. Un cœur WordPress en retard d’une version mineure, un préfixe de base par défaut hérité de l’installation initiale, pas de cache objet persistant sur notre hébergement mutualisé et des révisions illimitées. Le rapport nous donne l’ordre exact des corrections, en commençant par le seul point critique. Un score parfait n’est pas toujours atteignable selon votre hébergement : l’important est de traiter les points critiques et de connaître la raison de chaque point restant.
Audit sécurité : les 10 contrôles qui comptent
La famille sécurité concentre 10 des 15 contrôles, et ce n’est pas un hasard : c’est là que se joue la survie du site. Ausculte classe toujours les points critiques en premier, pour que vous sachiez par où commencer.

Deux remèdes parmi les plus rentables se posent en une minute dans wp-config.php, au dessus de la ligne « happy publishing » :
define( 'DISALLOW_FILE_EDIT', true ); // bloque l'éditeur de code dans wp-admin
define( 'WP_DEBUG', false ); // aucune erreur PHP affichée aux visiteurs
Le blocage du listage des dossiers se règle côté serveur, dans le fichier .htaccess à la racine si votre hébergement utilise Apache ou LiteSpeed :
Options -Indexes
L’énumération des utilisateurs via l’API REST mérite une attention particulière : par défaut, l’adresse /wp-json/wp/v2/users révèle les identifiants de connexion de vos auteurs, la moitié du travail d’une attaque par force brute. Ausculte vérifie ce point de l’extérieur, comme le ferait un attaquant. Sur le même front, les formulaires exposés attirent aussi les robots : notre guide pour stopper le spam de commentaires WordPress applique la même philosophie de durcissement sans plugin superflu.
Audit performance : les 3 gains rapides
Trois contrôles suffisent à capturer l’essentiel des gains de performance côté serveur. D’abord les révisions : chaque enregistrement d’article crée une ligne supplémentaire dans la table wp_posts, et un article retravaillé cinquante fois pèse cinquante lignes. Limitez les révisions dans wp-config.php :
define( 'WP_POST_REVISIONS', 5 );
Ensuite WP-Cron. Par défaut, WordPress déclenche ses tâches planifiées au passage des visiteurs, ce qui ralentit des pages au hasard et rend les horaires imprévisibles. Confiez le travail à un vrai cron système :
define( 'DISABLE_WP_CRON', true );
# crontab -e : appel toutes les 5 minutes
*/5 * * * * curl -s https://votre-site.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Enfin le cache objet persistant : sans lui, les mêmes requêtes SQL se répètent à chaque affichage. Si votre hébergeur propose Redis ou Memcached, activez le drop-in correspondant. Sinon, un bon cache de page compense en partie : voyez notre guide pour gérer et vider le cache WordPress proprement.
Audit SEO technique : les 2 pièges silencieux
Deux réglages peuvent anéantir votre référencement sans aucun symptôme visible. Le premier est la case « Demander aux moteurs de recherche de ne pas indexer ce site », cochée pour une préproduction puis oubliée lors de la mise en ligne : le site fonctionne parfaitement, il a simplement disparu de Google. Ausculte marque ce point comme critique car ses conséquences sont totales.
Le second est la structure des permaliens restée sur le réglage « simple » : des adresses en ?p=123 qui ne portent aucun mot clé et se partagent mal. Le remède tient en un clic dans Réglages puis Permaliens, avec la structure « Titre de la publication ».
Les remèdes en une ligne à copier coller
Récapitulatif des constantes wp-config.php recommandées à l’issue de l’audit. Posez uniquement celles qui correspondent à des points signalés sur votre site, puis relancez l’audit pour valider :
// Sécurité
define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_DEBUG', false );
// Performance
define( 'WP_POST_REVISIONS', 5 );
define( 'DISABLE_WP_CRON', true ); // avec un cron système en relais
Pour les développeurs : wp-doctor, la version CLI en Python
Ausculte a un grand frère en ligne de commande : wp-doctor, notre outil open source en Python qui audite un site WordPress de l’extérieur, sans rien installer sur le site cible. Même philosophie, trois familles de contrôles, un score sur 100 et des rapports exportables en HTML, JSON ou Markdown. Le code est sur GitHub.
git clone https://github.com/wpadminlab/wp-doctor.git
cd wp-doctor
python3 -m venv .venv && source .venv/bin/activate
python3 -m pip install .
wp-doctor https://votre-site.fr --quick
Son option --fail-on renvoie un code de sortie non nul dès qu’une observation atteint la gravité demandée, ce qui en fait un garde-fou naturel en intégration continue. Exemple de workflow GitHub Actions qui audite un site de staging chaque lundi matin :
name: Audit WordPress
on:
schedule:
- cron: '15 6 * * 1'
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: python -m pip install .
- run: wp-doctor https://staging.exemple.fr --quick --fail-on high
Règle d’or valable pour les deux outils : n’auditez que des sites qui vous appartiennent ou pour lesquels vous avez une autorisation explicite.
Ausculte, Site Health, WPScan, PageSpeed : lequel choisir ?
Ces outils ne se concurrencent pas, ils se complètent. Chacun observe le site depuis un poste différent :
| Outil | Où il s’exécute | Ce qu’il voit le mieux | Sa limite |
|---|---|---|---|
| Ausculte | Dans wp-admin | Les 15 réglages critiques, avec remèdes | Pas de base de CVE d’extensions |
| Site Health (natif) | Dans wp-admin | PHP, base de données, extensions actives | Verbeux, sans priorisation claire |
| WPScan | Depuis l’extérieur | Vulnérabilités connues, empreinte du site | Base complète payante via API |
| PageSpeed Insights | Depuis Google | Rendu réel et Core Web Vitals | Ignore sécurité et réglages internes |
En pratique : Ausculte pour le contrôle de premier niveau et la priorisation, Site Health pour l’environnement serveur, WPScan pour la veille sur les CVE, PageSpeed pour l’expérience utilisateur, et la Search Console pour l’indexation.
La routine d’audit mensuelle en 20 minutes
- Ouvrez le rapport Ausculte et relancez les contrôles : traitez d’abord tout point critique apparu depuis le mois précédent.
- Passez les mises à jour en attente : cœur, extensions, thème, après une sauvegarde complète.
- Vérifiez la vitesse d’une page représentative dans PageSpeed Insights et comparez au mois précédent.
- Jetez un œil à la Search Console : couverture d’indexation et erreurs d’exploration.
- Notez le score du mois. La tendance compte plus que la valeur absolue : un site qui passe de 54 à 78 progresse, un site qui stagne à 85 sans raison identifiée mérite une inspection.
Sources
- Guide officiel WordPress de durcissement
- Référence officielle des constantes wp-config.php
- Versions PHP supportées, php.net
- OWASP Web Security Testing Guide
- Core Web Vitals, web.dev
- Google Search Central : blocage d’indexation
FAQ : audit WordPress
Combien coûte un audit WordPress ?
Un audit prestataire se facture généralement entre 300 et 1500 euros selon la profondeur. La méthode de ce guide couvre gratuitement le socle technique : les 15 contrôles d’Ausculte, Site Health et PageSpeed. Un audit payant garde son intérêt pour les aspects métier, les sauvegardes testées, les journaux serveur et l’analyse d’une compromission avérée.
À quelle fréquence faire un audit WordPress ?
Un audit complet à l’installation, après chaque migration, puis une routine mensuelle de 20 minutes. Ajoutez un contrôle immédiat après tout événement inhabituel : pic de trafic suspect, ralentissement brutal, alerte de votre hébergeur ou disparition de pages dans Google.
Ausculte envoie-t-il des données à l’extérieur de mon site ?
Non. Tous les contrôles s’exécutent localement sur votre serveur. Les seules requêtes HTTP sont des boucles du site vers lui-même pour tester les points d’entrée publics comme l’API REST ou xmlrpc.php. Aucun compte, aucun traceur, aucune télémétrie : c’est un choix de conception délibéré et vérifiable dans le code, publié sous GPL.
Un audit WordPress peut-il casser mon site ?
L’audit en lui-même ne modifie rien : Ausculte lit la configuration et observe les réponses HTTP, sans écrire. Ce sont les corrections qui demandent de la prudence. Sauvegardez la base et les fichiers avant de toucher wp-config.php, appliquez un remède à la fois et testez le site après chacun.
Quelle différence entre Ausculte et Site Health de WordPress ?
Site Health, l’outil natif, inventorie l’environnement serveur de façon exhaustive mais peu hiérarchisée. Ausculte fait l’inverse : 15 contrôles choisis pour leur impact réel, un score sur 100 qui priorise, et un remède concret par problème. Les deux se complètent bien : Ausculte pour décider quoi corriger en premier, Site Health pour explorer un point d’environnement en profondeur.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.