Un audit SEO WordPress commence par un diagnostic des signaux de terrain, pas par un rapport d’outil. Trop d’audits s’arrêtent à un score PageSpeed ou à une liste d’erreurs générée automatiquement – sans établir de lien entre les problèmes identifiés et leurs effets mesurables sur le trafic ou les positions. La méthode présentée ici part des données réelles pour remonter aux causes techniques.
INP, LCP, CLS : les Core Web Vitals que votre audit WordPress doit couvrir
En mars 2024, Google a remplacé le First Input Delay par l’Interaction to Next Paint (INP). Un audit qui conserve FID comme indicateur de réactivité est structurellement incomplet. L’INP évalue la réponse du navigateur à l’ensemble des interactions utilisateur – clics, appuis tactiles, saisies clavier – avec un seuil « bon » fixé à 200 ms ou moins.
La distinction entre données de laboratoire et données de terrain est ici déterminante. Les mesures simulées (PageSpeed Insights, Lighthouse) servent à diagnostiquer ; les Core Web Vitals de Search Console reflètent l’expérience de visiteurs réels, sur leurs appareils, en conditions réseau variables. Les deux séries doivent être confrontées, notamment sur mobile où les écarts sont les plus fréquents.
Un cas concret illustre ce décalage : une page peut afficher un LCP correct en laboratoire mais présenter un INP dégradé à cause de scripts tiers qui bloquent le thread principal. Le chargement initial paraît fluide ; chaque clic répond avec retard. Ce type de problème ne remonte pas si l’audit s’arrête au score global.
Diagnostiquer les tâches longues JavaScript
L’onglet Performance de Chrome DevTools permet d’identifier les tâches JavaScript qui bloquent le navigateur plus de 50 ms. Sur WordPress, les coupables habituels sont les plugins de formulaires, les scripts de chat, les pixels de tracking et les bibliothèques de sliders chargées sur toutes les pages sans condition. L’audit doit tester les interactions importantes du site (soumission de formulaire, ajout panier, navigation menu) et non se limiter au temps de chargement initial.
Indexation WordPress : ce que Google Search Console révèle au-delà des erreurs
La couverture d’index dans Search Console distingue les pages exclues volontairement (noindex, canonicales) des pages que Google ne parvient pas à explorer. Ces deux catégories appellent des corrections opposées et ne doivent jamais être traitées comme un seul bloc de problèmes.
Sur WordPress, les sources fréquentes de pages parasites indexées sont les archives d’auteur sur les sites mono-auteur, les pages de tags qui dupliquent le contenu des catégories, les pages de résultats de recherche interne accessibles via ?s=, et les versions paginées générées automatiquement. Chaque page inutile consomme du budget de crawl et dilue l’autorité du site.
- Vérifier que le fichier robots.txt ne bloque pas les ressources CSS et JS nécessaires au rendu, ce qui fausserait l’évaluation du site par Googlebot.
- Contrôler la cohérence entre le sitemap XML (généré par Yoast, Rank Math ou All in One SEO) et les pages effectivement indexables : un sitemap qui soumet des URL en noindex est une erreur fréquente après une migration.
- Identifier les canonicales auto-référentielles mal positionnées, notamment sur les pages de pagination qui pointent toutes vers la page 1.
PHP, thème et plugins : l’état de la base technique WordPress
La version de PHP en production conditionne à la fois les performances et la sécurité. Une version en fin de vie ne reçoit plus de correctifs de sécurité et peut présenter des incompatibilités avec les plugins récents. L’audit doit relever la version active et vérifier la compatibilité du thème et des plugins avant toute mise à jour.
Le nombre de plugins actifs n’est pas un indicateur pertinent en lui-même. Ce qui compte, c’est la nature des requêtes que chaque plugin exécute à chaque chargement de page. Un plugin de SEO bien codé impacte moins les performances qu’un plugin de galerie qui charge ses scripts sur toutes les pages, y compris celles sans images. Désactiver puis tester l’impact sur le TTFB reste la méthode la plus fiable pour isoler les plugins coûteux.
Thème et dette technique
Un thème page-builder (Divi, Elementor, WPBakery) génère structurellement plus de CSS et de JS qu’un thème code-first. Cela ne disqualifie pas ces outils, mais l’audit doit quantifier le poids du CSS non utilisé et vérifier que le chargement des scripts est conditionné à leur présence sur la page. L’outil Coverage dans Chrome DevTools affiche le ratio CSS/JS chargé vs utilisé sur une page donnée.
Contenu et balises : les signaux on-page à vérifier lors de l’audit SEO
Un audit technique WordPress sans contrôle du contenu reste partiel. Les balises title dupliquées et les meta descriptions absentes sont les anomalies les plus fréquentes – elles apparaissent dans Search Console sous « Problèmes HTML » et se corrigent directement dans le plugin SEO actif.
Au-delà des doublons, la structure H1/H2/H3 mérite un contrôle systématique. WordPress génère automatiquement un H1 à partir du titre de la page ou de l’article ; des thèmes mal configurés peuvent en produire plusieurs, ce qui crée un signal ambigu pour l’exploration sémantique.
La question du contenu mince (thin content) est moins simple à traiter que les erreurs de balises. Une page courte n’est pas nécessairement un problème si elle répond précisément à une intention de recherche. L’audit doit évaluer la correspondance entre l’intention derrière chaque URL stratégique et ce que la page propose réellement, pas seulement le nombre de mots.
Maillage interne et profondeur de clic
Sur un site WordPress avec une architecture de contenu dense, la profondeur de clic depuis la page d’accueil détermine en partie la fréquence de crawl des pages les plus profondes. Toute page stratégique accessible en plus de trois clics depuis l’accueil doit être évaluée : soit elle mérite d’être remontée dans la structure, soit son importance réelle est moindre que supposée. Screaming Frog, avec le paramètre de profondeur activé, produit ce diagnostic en quelques minutes.
Prioriser les corrections après l’audit WordPress
Un audit produit rarement une liste courte. La priorisation doit croiser l’impact estimé sur le trafic ou les conversions avec l’effort de correction – pas simplement suivre l’ordre de sévérité affiché par les outils. Une erreur 404 sur une page orpheline sans backlink est moins urgente qu’un problème INP qui dégrade l’expérience sur toutes les pages transactionnelles.
Un bon score de vitesse ne garantit pas une hausse de classement. Google intègre les Core Web Vitals dans ses systèmes de classement, mais une page pertinente peut rester visible même avec une expérience dégradée. Corriger les lenteurs qui nuisent aux visiteurs réels – et pas courir après un score parfait en laboratoire – reste la priorité opérationnelle d’un audit WordPress bien conduit.
