180 lignes de rapport CSV pour un site de taille moyenne, et à peine la moitié concerne réellement des problèmes actionnables sur une installation WordPress. C’est le chiffre qui revient sur trois audits menés cette année avec SEMrush Site Audit sur des sites clients, comparés en parallèle à des scripts maison lancés via WP-CLI et une exploration directe de la base de données. Le décalage n’est pas anecdotique : il change la manière dont un développeur doit lire ces rapports avant de les transmettre à un client ou de les traduire en tickets.
Aucun des deux outils n’est mauvais en soi. SEMrush Site Audit crawle comme un navigateur, mesure des temps de réponse, détecte des chaînes de redirection et des balises manquantes à grande échelle, sans installation ni accès serveur. Un script interne, lui, connaît la structure des tables wp_posts et wp_postmeta, sait qu’un type de contenu personnalisé n’est pas censé être indexé, et peut croiser les données avec les logs serveur. La question n’est donc pas lequel est meilleur, mais où chacun aveugle l’autre.
Ce que SEMrush voit bien
Sur des critères génériques, l’outil est redoutable. Il repère en quelques minutes les balises title dupliquées, les temps de chargement anormaux, les liens cassés à grande échelle et les problèmes de maillage interne mesurés en profondeur de clic. Sur un site vitrine classique avec peu de logique conditionnelle, le rapport est directement exploitable : chaque ligne correspond à une action concrète, sans besoin de contexte supplémentaire sur l’architecture WordPress sous-jacente.
Le point fort réel, c’est la vitesse d’obtention d’une vue d’ensemble. Sur un audit initial pour un prospect, produire ce rapport en une heure a une valeur commerciale que n’a pas un script maison qui demande une journée de calibrage. C’est un outil de diagnostic rapide, pas un outil de diagnostic complet.
Ce qu’il rate sur une installation WordPress réelle
Les limites apparaissent dès que le site s’appuie sur une logique métier propre à WordPress. Un exemple concret : sur un site avec des Custom Post Types privés utilisés comme composants internes (blocs réutilisables stockés en wp_block, par exemple), SEMrush les traite comme des pages ordinaires et signale des « pages orphelines » ou des « contenus fins », alors qu’il s’agit de contenus jamais destinés à être visités directement.
Autre angle mort : les redirections conditionnelles gérées par un plugin ou du code sur mesure via template_redirect. L’outil ne connaît pas la logique de rôle utilisateur ou de géolocalisation qui déclenche ces redirections ; il voit une seule branche du comportement et en tire des conclusions partielles. Il en va de même pour les pages générées par le bloc Requête avec des filtres dynamiques : le crawler suit les liens visibles, mais ne reproduit pas les combinaisons de filtres réellement utilisées par les visiteurs.
Un cas concret : le faux positif des pages de recherche interne
Sur un des sites audités, SEMrush signalait plus de 200 « pages à contenu dupliqué » correspondant en réalité à des résultats de recherche interne WordPress (URLs en ?s=) qui n’étaient de toute façon pas censées être indexées, déjà bloquées en noindex via le filtre wp_robots. L’alerte n’était pas fausse techniquement, mais elle générait un travail de tri inutile côté client, qui a fini par ignorer d’autres alertes plus sérieuses noyées dans le volume.
Ce que l’audit interne fait mieux
Un script WP-CLI personnalisé, lui, part de la base de données et connaît la sémantique des contenus. Une commande simple permet de lister tous les articles publiés sans extrait, sans image mise en avant, ou rattachés à un auteur désactivé :
wp post list --post_type=post --post_status=publish --fields=ID,post_title,post_excerpt --format=csv | awk -F',' '$3==""'Ce type de requête ne demande aucun crawl, s’exécute en quelques secondes même sur 50 000 contenus, et croise directement avec les métadonnées SEO stockées par l’extension utilisée (Yoast, Rank Math ou une solution maison), champ par champ. Un audit interne peut aussi interroger directement les journaux du serveur pour savoir quelles pages Googlebot a réellement explorées récemment, une donnée que SEMrush ne possède tout simplement pas.
Comparatif synthétique
| Critère | SEMrush Site Audit | Script interne WP-CLI |
|---|---|---|
| Temps de mise en place | Quelques minutes | Plusieurs heures à calibrer |
| Connaissance du contexte WordPress | Aucune | Totale |
| Détection des pages jamais explorées | Non (pas d’accès aux logs) | Oui, via les logs serveur |
| Volume de faux positifs | Élevé sur sites complexes | Faible, mais dépend du script |
| Coût récurrent | Abonnement mensuel | Temps de développement initial |
Notre verdict
Aucun des deux ne remplace l’autre sur un site WordPress de taille conséquente. La bonne pratique consiste à utiliser SEMrush comme premier filtre grossier pour repérer les tendances générales — temps de réponse, maillage, balises manquantes — puis à valider chaque catégorie d’alerte avec un script interne qui connaît la structure réelle du site avant de la transmettre en ticket. Sur les trois audits comparés, environ 40 % des alertes SEMrush n’ont débouché sur aucune action après vérification interne, non parce qu’elles étaient fausses, mais parce qu’elles concernaient des contenus volontairement exclus de l’indexation.
Un rapport d’audit n’a de valeur que si quelqu’un qui connaît l’architecture du site le relit avant de le transmettre. Sinon, c’est une liste de symptômes sans diagnostic.
Pour un développeur qui facture un audit technique, la vraie valeur ajoutée n’est pas dans l’outil choisi, mais dans le tri qu’il applique entre ce qui relève d’un vrai problème et ce qui relève d’une architecture volontaire que l’outil ne pouvait pas connaître.
