Audit SEO WordPress : ce que les checklists ne vous disent pas

Vous cherchez à faire l’audit SEO de votre site WordPress ? Vous avez probablement déjà lu trois ou quatre checklists qui vous conseillent d’installer Yoast, de vérifier votre sitemap et de tester votre vitesse sur PageSpeed Insights. Ce n’est pas faux. Mais ce n’est pas un audit.

WordPress fait tourner 40,2 % de l’ensemble des sites web et 58,6 % des sites dont le CMS est identifiable, selon W3Techs (octobre 2026). Cette domination a une conséquence que les guides génériques oublient : la majorité des problèmes SEO rencontrés sur un site WordPress ne viennent pas de ce que vous avez fait, mais de ce que WordPress, votre thème et vos plugins font tout seuls, par défaut, sans vous le dire.

En tant que consultant SEO spécialisé WordPress depuis plus de dix ans, j’ai audité des dizaines de sites WordPress : vitrines de PME, blogs B2B, boutiques WooCommerce. Les mêmes défauts reviennent, et aucun plugin ne les détecte. Voici ma méthode, étape par étape, et surtout l’ordre dans lequel traiter les problèmes.

Votre site WordPress stagne malgré des contenus publiés régulièrement ? Le problème est rarement là où vous le cherchez. Parlons-en 30 minutes, c’est gratuit.

Qu’est-ce qu’un audit SEO WordPress ?

Un audit SEO WordPress est un diagnostic complet de la capacité d’un site WordPress à être exploré, indexé, compris et classé par Google, puis cité par les moteurs d’IA générative. Il couvre quatre couches : l’infrastructure (hébergement, thème, plugins), la technique (indexation, performance, structure), le contenu (pertinence, qualité, maillage) et la visibilité externe (liens, mentions).

Ce qui le distingue d’un audit SEO classique, c’est la part prise par la couche infrastructure. Sur un site codé sur mesure, le développeur contrôle chaque balise. Sur WordPress, votre thème génère des archives que vous n’avez jamais demandées, votre plugin SEO écrit un sitemap que vous n’avez jamais relu, et votre page builder injecte des centaines de kilo-octets de scripts que vous ne voyez pas.

Les trois niveaux d’un audit WordPress

Je distingue trois niveaux de lecture, du plus superficiel au plus utile.

– Ce que le plugin SEO voit. Yoast, Rank Math ou SEOPress analysent chaque page individuellement : présence du mot clé, longueur de la meta description, lisibilité. Utile pour la rédaction, inutile pour comprendre pourquoi le site ne ranke pas.

– Ce que le crawler voit. Screaming Frog, Semrush Site Audit ou Ahrefs explorent le site comme Googlebot. Ils révèlent les URLs parasites, les redirections en chaîne, les canoniques incohérentes, les pages orphelines. C’est le cœur de l’audit technique.

– Ce que seul un humain voit. La cannibalisation entre deux articles, l’inadéquation entre une page et l’intention de recherche, la faiblesse des signaux E-E-A-T, le contenu générique qui n’apporte rien. Aucun outil ne juge cela correctement.

Audit technique et audit sémantique : deux chantiers distincts

Cet article traite de l’audit technique et structurel propre à WordPress. L’analyse en profondeur de vos mots clés, de vos intentions de recherche et de votre champ sémantique relève d’un audit SEO sémantique, qui est une prestation à part entière. Les deux sont complémentaires : corriger la technique sans revoir le contenu, cela revient à construire une voiture de course sans carburant dans le réservoir.

Étape 1 : préparer l’audit (ce que la plupart des gens sautent)

Avant de lancer un crawler, récupérez trois choses.

– Un accès à Google Search Console. Sans elle, vous travaillez à l’aveugle. Le rapport « Pages » vous dit déjà quelles URLs Google refuse d’indexer et pourquoi.

– Un inventaire du site. Thème actif (et thème enfant éventuel), version de PHP, liste complète des plugins avec leur date de dernière mise à jour, présence d’un page builder, d’un plugin de cache, d’un CDN.

– Un objectif business. Un audit qui ne sait pas si le site doit générer des leads, vendre en ligne ou recruter ne peut pas prioriser. Cette question conditionne tout le reste.

Ensuite, lancez un crawl complet avec Screaming Frog (gratuit jusqu’à 500 URLs) ou l’outil d’audit de Semrush ou Ahrefs. Activez le rendu JavaScript et le respect du robots.txt. Croisez le nombre d’URLs crawlées avec le nombre d’URLs dans le sitemap et le nombre d’URLs indexées selon Search Console. Ces trois chiffres devraient être proches. S’ils divergent fortement, vous avez trouvé votre premier chantier.

Étape 2 : traquer les URLs parasites générées par WordPress

C’est le problème numéro un des sites WordPress, et il est quasi invisible depuis le tableau de bord. WordPress crée automatiquement une URL pour chaque catégorie, chaque étiquette, chaque auteur, chaque mois d’archive et, pire, chaque image téléversée (les pages de pièces jointes).

Un site vitrine de 30 pages peut ainsi exposer 400 URLs à Google. Sur ces 400, 370 sont des pages quasi vides, en doublon, qui diluent votre autorité et consomment inutilement le « crawl budget» ou budget d’exploration – le nombre maximal de pages qu’un robot comme Googlebot choisit d’explorer sur un site web dans un laps de temps donné.

Ce qu’il faut vérifier

– Les pages de pièces jointes. Les plugins SEO récents les redirigent par défaut vers le fichier image, mais vérifiez-le : tapez site:votredomaine.fr inurl:attachment ou cherchez dans votre crawl des URLs contenant uniquement le nom d’une image.

– Les archives d’étiquettes. Si vous avez 150 tags pour 40 articles, vous avez 150 pages d’archives qui n’ont aucune raison d’exister. Soit vous les mettez en noindex, soit vous supprimez les tags.

– Les archives d’auteur, de date et de format. Sur un site d’entreprise avec un seul rédacteur, l’archive auteur est un doublon exact de la page blog. noindex systématique.

– Les paramètres d’URL. ?replytocom=, ?s=, les filtres WooCommerce (?filter_couleur=, ?orderby=). Vérifiez dans Search Console si Google les explore.

– Les pages de résultats de recherche interne et les pages de pagination au-delà de la page 2 ou 3.

Google ne pénalise pas le contenu dupliqué en tant que tel, mais sa documentation est claire : il dégrade l’expérience et gaspille des ressources d’exploration sur des URLs qui ne vous rapportent rien.

Le sitemap XML : relisez-le

Yoast et Rank Math génèrent le sitemap automatiquement. C’est pratique, et c’est exactement pourquoi personne ne le relit. J’y trouve régulièrement des archives de tags en noindex (contradiction qui agace Google), des types de contenus personnalisés oubliés, ou des pages de politique de confidentialité et de mentions légales qui n’ont rien à faire dans un plan de site destiné au référencement.

Étape 3 : performance et Core Web Vitals, le problème est souvent l’hébergement

Les Core Web Vitals sont un signal de classement confirmé par Google, et WordPress est le CMS qui s’en sort le moins bien parmi les grandes plateformes. Dans le crawl de juin 2026 du HTTP Archive, analysé sur 4,47 millions de sites WordPress par HostingStep, seuls 48,8 % des sites WordPress passent les trois Core Web Vitals sur mobile (53,3 % sur desktop). Pour la France spécifiquement, le taux mobile est de 58,9 %. Les trois seuils à retenir, définis par web.dev : LCP sous 2,5 secondes, INP sous 200 millisecondes, CLS sous 0,1.

La lecture fine de ces données est plus intéressante que le chiffre global.

Le vrai goulot d’étranglement : le TTFB

L’INP (réactivité) est passé par 90,9 % des sites WordPress mobiles. Le CLS (stabilité visuelle) par 87,2 %. Là où WordPress s’effondre, c’est sur le temps de réponse serveur : seuls 33,2 % des sites WordPress affichent un TTFB correct (sous 800 ms) sur desktop, et 24,2 % sur mobile.

Ce chiffre a bougé de sept points en six ans alors que tous les autres ont gagné entre 26 et 38 points. Traduction : les thèmes, les formats d’image et le lazy loading se sont améliorés, mais l’hébergement mutualisé à 3 € par mois, lui, n’a pas changé.

Avant d’installer un énième plugin d’optimisation, testez votre TTFB brut (WebPageTest, ou l’onglet Réseau de votre navigateur). Au-dessus de 600 ms sur une page mise en cache, le problème est en dessous de WordPress, pas dedans.

Le page builder, deuxième suspect

W3Techs mesure qu’Elementor est installé sur 31,5 % des sites WordPress et WPBakery sur 7,4 %. Dans les données du HTTP Archive, les sites sous Elementor passent les Core Web Vitals sur mobile dans 36,8 % des cas, contre 53 % pour les sites utilisant l’éditeur de blocs natif. Divi tombe à 31,6 % sur desktop, plombé par la stabilité visuelle.

Attention à la lecture : ce sont des corrélations sur des millions de sites construits indépendamment, pas une expérience contrôlée. Elementor attire un public moins technique qui empile aussi plus de plugins. Mais la tendance est nette et cohérente avec ce que j’observe en audit : un builder lourd sur un hébergement faible, c’est la combinaison perdante type.

Les images, le poste le plus lourd

La page WordPress mobile médiane pèse 2,64 Mo, dont 1 015 Ko d’images. WordPress sert ce que vous avez téléversé, sauf si un plugin intervient. Vérifiez dans le crawl les images de plus de 200 Ko, l’absence de format WebP ou AVIF, et surtout l’image héro de vos pages principales : c’est presque toujours elle qui détermine le LCP.

Vous avez déjà changé trois fois de plugin de cache sans résultat ? Un accompagnement SEO commence par identifier le vrai goulot avant de dépenser.

Étape 4 : auditer les plugins, le thème et la sécurité

Cette étape n’existe pas dans les audits SEO génériques. Sur WordPress, elle est indispensable, pour deux raisons : la performance et le risque.

Combien de plugins ?

Il n’y a pas de chiffre magique, et j’ai vu des sites rapides avec 40 plugins bien choisis. Les vraies questions sont : chaque plugin a-t-il une fonction unique ? Charge-t-il ses scripts sur toutes les pages alors qu’il ne sert que sur une (formulaire de contact, slider, galerie) ? Est-il encore maintenu ? Deux plugins de cache, trois optimiseurs d’images ou deux plugins SEO actifs en parallèle sont des erreurs que je rencontre régulièrement.

La sécurité est un sujet SEO

Un site piraté qui diffuse du spam pharmaceutique dans ses pages ou redirige ses visiteurs mobiles vers des sites douteux perd ses positions en quelques jours, et les récupère en plusieurs mois. Or le risque se concentre là où on ne regarde pas : selon le rapport Patchstack « State of WordPress Security 2026 », 11 334 nouvelles vulnérabilités ont été recensées dans l’écosystème WordPress en 2025 (+42 % sur un an). 91 % concernent des plugins, 9 % des thèmes, et seulement 6 le cœur de WordPress, toutes de faible gravité.

Le même rapport note que les plugins premium ne sont pas plus sûrs que les gratuits ; ils sont simplement moins audités, leur code étant moins accessible aux chercheurs.

Dans l’audit, je vérifie donc : la version de PHP (une version non maintenue est un drapeau rouge), la présence de plugins non mis à jour depuis plus d’un an ou retirés du répertoire officiel, l’activation du HTTPS sur toutes les URLs sans contenu mixte, et l’absence de pages indexées en japonais ou en vente de médicaments dans site:votredomaine.fr.

Étape 5 : structure du site et maillage interne

WordPress organise les contenus en articles et en pages, avec des catégories plates. Cette logique de blog ne produit pas naturellement une architecture SEO. La plupart des thèmes ne proposent pas de liens contextuels entre contenus, et les widgets « articles récents » créent un maillage aléatoire qui change à chaque publication.

Dans le crawl, regardez trois indicateurs.

– La profondeur de clic. Vos pages de services ou vos catégories produits stratégiques doivent être accessibles en deux clics depuis l’accueil. Au-delà de quatre, Google les considère comme secondaires, et vos visiteurs ne les trouvent pas.

– Les pages orphelines. Un article qui ne reçoit aucun lien interne n’existe pour Google que via le sitemap. Les blogs WordPress en accumulent des dizaines.

– La distribution des liens entrants internes. Si votre page de mentions légales reçoit plus de liens internes (depuis le footer de chaque page) que votre page de services principale, votre maillage est à l’envers. C’est le cas sur la majorité des sites que j’audite.

Le fil d’Ariane, les liens contextuels dans le corps des articles et les blocs « pour aller plus loin » rédigés à la main corrigent cela. Un plugin de liens internes automatiques peut dépanner, mais il crée souvent du bruit : des ancres identiques répétées, des liens vers des pages hors sujet.

Cette étape rejoint directement la stratégie éditoriale : on ne maille bien que ce qu’on a structuré en amont, par thématiques et par intentions.

Étape 6 : le contenu et l’on-page, là où les outils s’arrêtent

Le crawler vous donne la liste des titres dupliqués, des meta descriptions manquantes, des H1 multiples (un classique des thèmes qui mettent le logo en H1). Corrigez tout cela, c’est rapide. Mais ce n’est que la partie mécanique.

Les trois diagnostics que seul un humain fait

– La cannibalisation. Deux articles qui ciblent la même requête se partagent les positions. Sur un blog WordPress de trois ans, c’est systématique : filtrez votre Search Console par requête et repérez celles qui remontent deux URLs différentes selon les semaines.

– L’adéquation à l’intention. Une page de service qui essaie de ranker sur une requête informationnelle (« qu’est-ce que… ») ne rankera pas, quelle que soit son optimisation. L’inverse est tout aussi vrai.

– La valeur ajoutée réelle. Google le dit sans détour dans son guide sur l’optimisation pour l’IA générative : le contenu « commodité », basé sur des connaissances communes que n’importe qui pourrait produire, a de moins en moins de chances d’émerger. Ce qui compte, c’est le point de vue, l’expérience de première main, le cas concret.

C’est ici que l’audit WordPress rejoint les critères E-E-A-T : auteur identifié avec une biographie réelle, dates de publication et de mise à jour visibles, sources citées, exemples issus de votre pratique. Les thèmes WordPress masquent souvent l’auteur et la date par souci esthétique. C’est une erreur.

Étape 7 : la section GEO, auditer sa visibilité dans les moteurs d’IA

L’optimisation pour les moteurs génératifs (GEO, pour Generative Engine Optimization) est devenue une composante légitime de l’audit, parce que le comportement des utilisateurs a changé. Selon Pew Research, les utilisateurs de Google qui voient un résumé IA cliquent sur un résultat classique dans 8 % des visites, contre 15 % sans résumé ; les liens cités dans le résumé lui-même ne sont cliqués que dans 1 % des cas. L’étude porte sur 900 adultes américains en mars 2025 ; le marché français n’a pas d’équivalent aussi rigoureux, mais la tendance est la même dans toutes les Search Console que je consulte.

Le piège, sur WordPress, est de croire que le GEO se résout avec un plugin. Voici ce qui compte réellement, et ce qui ne sert à rien.

Ce qui compte : du HTML lisible sans JavaScript

C’est le point technique le plus important, et il est directement lié aux page builders. L’analyse de Vercel et MERJ sur le trafic de leur réseau en décembre 2024 (569 millions de requêtes GPTBot, 370 millions de requêtes des robots d’Anthropic) a constaté qu’aucun des grands crawlers IA n’exécute le JavaScript. Ils téléchargent les fichiers JS, ils ne les lancent pas. Seul Google, qui partage son infrastructure de rendu entre Search et Gemini, fait exception.

Concrètement : si votre contenu principal est injecté par un slider, un onglet, un accordéon ou un bloc « lire la suite » dépendant de JavaScript, ChatGPT, Perplexity et Claude ne le voient pas. Test simple : désactivez JavaScript dans votre navigateur et rechargez vos pages clés. Ce qui disparaît est invisible pour les moteurs d’IA. Les sections FAQ en accordéon, très populaires sur WordPress, sont le premier endroit où regarder.

Ce qui compte : le contenu non-commodité et la citabilité

Les moteurs génératifs citent des sources qui apportent une information précise et attribuable : un chiffre daté, une méthode, une prise de position argumentée. Un article qui reformule les cinq premiers résultats de Google n’a aucune raison d’être cité à leur place. Structurez vos pages avec des titres qui sont de vraies questions, des réponses directes en début de section, et des données sourcées. C’est la logique que je détaille dans mon guide sur le GEO.

Ce qui ne sert (presque) à rien : le fichier llms.txt

Plusieurs plugins WordPress proposent désormais de générer un fichier llms.txt. Les données disponibles invitent à ne pas y consacrer de temps. Dans l’étude Ahrefs de juin 2026 portant sur 137 000 domaines, 28 % publiaient un fichier llms.txt, et 97 % de ces fichiers n’ont reçu aucune requête en un mois, d’aucun robot. Les robots de recherche IA (OAI-SearchBot, PerplexityBot) représentaient 1,1 % des rares requêtes observées. Google indique de son côté, dans sa section « mythbusting », que son moteur ignore ces fichiers.

Même constat sur le « chunking » (découper artificiellement le contenu en petits blocs) et la réécriture « pour l’IA » : Google les classe explicitement parmi les pratiques inutiles. La seule chose que je retiens des plugins GEO pour WordPress, c’est qu’ils vérifient parfois que vos robots.txt n’interdit pas par erreur les crawlers d’IA. Vérifiez-le vous-même : un ancien Disallow global suffit à vous effacer de ChatGPT.

Comment mesurer

Deux sources fiables : le rapport « Performance dans l’IA générative » de Search Console pour Google, et vos logs serveur (ou un outil comme Ahrefs Bot Analytics) pour voir quels robots IA explorent réellement vos pages. Les outils payants de suivi de visibilité LLM (Otterly, Peec, Profound) ont leur utilité, mais commencez par taper vous-même vingt requêtes clients dans ChatGPT et Perplexity. C’est gratuit et souvent suffisant pour un premier état des lieux.

Étape 8 : prioriser, sinon l’audit finit dans un tiroir

Un audit WordPress complet produit facilement 150 points. Si vous les livrez en vrac, rien ne sera corrigé. Je classe tout selon deux axes : l’impact estimé et l’effort de correction.

À traiter en premier (fort impact, effort faible à moyen) :

– Pages stratégiques en noindex par erreur ou bloquées par le robots.txt

– Changement d’hébergement si le TTFB dépasse 600 ms en cache

– Fermeture des archives parasites et nettoyage du sitemap

– Compression de l’image héro des dix pages les plus visitées

– Suppression des plugins redondants ou abandonnés

À planifier (fort impact, effort élevé) :

– Fusion ou refonte des contenus cannibalisés

– Restructuration du maillage interne autour des pages business

– Migration du page builder vers l’éditeur de blocs sur les pages clés

À faire si le temps le permet (faible impact) :

– Uniformisation des meta descriptions sur les pages secondaires

– Optimisation des attributs alt des images décoratives

– Données structurées au-delà d’Organization, Article et BreadcrumbList

Chaque recommandation doit nommer un responsable, une échéance et un indicateur de vérification. Un audit sans plan d’action chiffré est un document, pas un levier.

Vous dirigez une PME et vous voulez un diagnostic qui dit quoi faire en premier, pas une liste de 150 points ? Découvrez comment je construis une stratégie SEO pour PME, ou contactez-moi directement.