Audit SEO WordPress : tout ce qu’il faut vérifier sur votre site

Audit technique : crawl et indexation

C’est le premier pilier à vérifier. Un site mal crawlé ou mal indexé ne peut pas performer, peu importe la qualité de son contenu. WordPress crée par défaut une architecture qui peut compliquer le travail des robots si elle n’est pas correctement configurée.

Le fichier robots.txt

Le robots.txt de WordPress est souvent laissé à sa valeur par défaut ou mal configuré par un plugin. Les erreurs courantes à vérifier :

• Blocage accidentel de tout le site avec Disallow: /
• Blocage du dossier /wp-content/uploads/ qui empêche Google d’accéder aux images
• Blocage des fichiers CSS et JS qui empêche Google de rendre les pages correctement
• Absence de la déclaration du sitemap XML en bas du fichier
• Directives contradictoires entre plusieurs plugins SEO installés en même temps

Vérifiez votre robots.txt en accédant directement à votresite.fr/robots.txt et validez-le dans Google Search Console via l’outil de test dédié.

Le sitemap XML

Le sitemap doit être propre, déclaré dans la Search Console et ne contenir que les pages que vous voulez indexer. Les problèmes fréquents :

• Sitemap non déclaré dans Google Search Console
• Sitemap qui inclut des pages noindex (contradiction : vous dites à Google de ne pas indexer mais vous lui soumettez quand même)
• Sitemap avec des URLs en erreur 404 ou redirigées
• Plusieurs sitemaps générés par plusieurs plugins SEO installés simultanément
• Sitemap qui n’est pas mis à jour automatiquement après publication

Redirections et erreurs 404

Les redirections mal gérées consomment du budget de crawl et font perdre du jus de lien. Les points à auditer :

• Redirections 302 à la place de 301 sur des URLs définitivement déplacées
• Chaînes de redirection : A redirige vers B qui redirige vers C, à aplatir en redirection directe A vers C
• Boucles de redirection : A redirige vers B qui redirige vers A
• Erreurs 404 sur des pages qui avaient des backlinks ou du trafic, à rediriger en 301 vers la page la plus pertinente
• Pages supprimées sans redirection mise en place

Screaming Frog remonte toutes ces situations automatiquement dans ses rapports de réponse et de redirection.

Profondeur de clic et structure

Google accorde plus d’importance aux pages proches de l’accueil dans l’architecture du site. Les pages stratégiques doivent être accessibles en moins de 3 clics depuis la page d’accueil. Ce qui crée des problèmes de profondeur sur WordPress :

• Catégories avec trop de niveaux d’imbrication
• Articles de blog paginés sur 10 pages avec du contenu important en page 8
• Pages importantes sans aucun lien interne qui y pointe
• Structure de permaliens trop longue : /category/sous-category/article/

Logs serveur et erreurs invisibles

Les logs serveur révèlent ce que les outils SEO ne voient pas : les erreurs 500, les timeouts, les pages que Googlebot essaie de crawler et n’arrive pas à charger. Sur WordPress, les sources d’erreurs serveur fréquentes sont :

• Conflits entre plugins qui génèrent des erreurs PHP fatales
• Version PHP trop ancienne incompatible avec les dernières versions de plugins
• Limites mémoire WordPress atteintes (WP_MEMORY_LIMIT insuffisant)
• Fichier .htaccess mal configuré qui génère des erreurs 500
• Hébergement mutualisé qui bride les ressources aux heures de pointe

Le plugin Query Monitor affiche les erreurs PHP en temps réel. Pour les logs serveur complets, accédez aux logs d’erreur via votre hébergeur ou via un accès SSH.

Balises hreflang (sites multilingues)

Si votre site WordPress est en plusieurs langues, les balises hreflang mal configurées sont une source fréquente de cannibalisation entre versions linguistiques. Points à vérifier :

• Balise hreflang x-default absente ou mal assignée
• Balises hreflang non réciproques : la version FR pointe vers EN mais EN ne pointe pas vers FR
• URLs dans les balises hreflang qui renvoient des erreurs 404
• Conflit entre le plugin de traduction (WPML, Polylang) et le plugin SEO pour la génération des balises

Les pages parasites WordPress : le problème que personne ne règle

WordPress génère automatiquement des dizaines de pages que vous n’avez jamais créées et que Google indexe volontiers si vous ne faites rien. Ces pages diluent le budget de crawl, créent du contenu dupliqué et envoient des signaux de mauvaise qualité à Google. C’est l’un des problèmes les plus fréquents sur les sites WordPress audités et l’un des plus simples à corriger.

Les pages d’auteur

Sur un site WordPress solo, la page d’auteur (/author/votre-nom/) liste tous vos articles. Son contenu est quasiment identique à votre page d’archive blog. Google voit deux URLs avec le même contenu, ce qui dilue l’autorité et peut générer des signaux de contenu dupliqué. Sur un site avec un seul auteur, cette page n’a aucune valeur : il faut la passer en noindex ou la rediriger vers l’accueil.

Les archives par date

WordPress crée automatiquement des archives par année, par mois et par jour :

• /2024/ : archive annuelle
• /2024/06/ : archive mensuelle
• /2024/06/29/ : archive quotidienne

Ces pages n’ont aucune valeur éditoriale, aucune intention de recherche et dupliquent le contenu de vos articles. À passer systématiquement en noindex.

Les archives de tags vides ou mal utilisées

Les tags WordPress sont l’une des sources de pages parasites les plus prolifiques. Un site avec 200 articles et 400 tags crée 400 pages d’archive dont la plupart ne contiennent qu’un ou deux articles. Ce qui se passe en pratique :

• Tags créés en doublon des catégories avec les mêmes mots-clés
• Tags au singulier et au pluriel traités comme deux pages distinctes
• Tags avec un seul article indexés et crawlés inutilement
• Balises canoniques absentes sur les pages de tags

La règle simple : soit vous utilisez les tags avec une vraie logique éditoriale et vous les optimisez comme des pages à part entière, soit vous les passez tous en noindex.

Les pages de résultats de recherche interne

Chaque recherche effectuée sur votre site génère une URL du type /?s=mot-clé. Ces pages sont indexables par défaut et Googlebot les crawle. Résultat : des centaines de pages vides ou quasi-vides dans l’index Google. La directive Disallow: /?s= dans le robots.txt suffit à bloquer leur crawl. Vous pouvez aussi les passer en noindex via votre plugin SEO.

Les flux RSS et pages /feed/

WordPress génère des flux RSS pour chaque type de contenu :

• /feed/ : flux principal
• /category/nom/feed/ : flux par catégorie
• /tag/nom/feed/ : flux par tag
• /author/nom/feed/ : flux par auteur
• /comments/feed/ : flux des commentaires

Ces URLs sont indexables et dupliquent intégralement le contenu de vos articles. À bloquer dans le robots.txt ou à passer en noindex.

Les paramètres d’URL parasites

WordPress et certains plugins ajoutent des paramètres à vos URLs qui créent des versions dupliquées de vos pages :

• ?replytocom=123 : généré par le système de commentaires natif
• ?p=123 : URLs courtes générées par WordPress avant la configuration des permaliens
• ?preview=true : pages de prévisualisation accessibles publiquement
• ?utm_source=, ?fbclid= : paramètres de tracking qui génèrent des doublons si mal configurés dans la Search Console
• Paramètres de pagination WooCommerce : ?paged=2, ?orderby=price

Ces paramètres doivent être déclarés dans Google Search Console comme paramètres à ignorer, ou bloqués via le robots.txt.

Les pages de pagination

La pagination WordPress génère des URLs du type /page/2/, /page/3/ sur les archives et les catégories. Ces pages ont peu de valeur individuelle et peuvent diluer l’autorité de la page principale. Les options :

• Ajouter une balise canonique sur toutes les pages paginées qui pointe vers la page 1
• Passer les pages de pagination au-delà de la page 2 en noindex
• Utiliser le chargement infini ou le « load more » côté front pour éviter la pagination indexable

Les pages WordPress système

Certaines pages générées par WordPress ou ses plugins n’ont rien à faire dans l’index Google :

• Page de connexion : /wp-login.php et /wp-admin/
• Pages générées par WooCommerce : panier, commande, mon compte, checkout
• Pages générées par des plugins de formulaire ou de membership
• Page d’exemple « Hello World » et page « Exemple de page » laissées par défaut
• Pages brouillon ou en attente de révision accessibles publiquement
• Anciennes pages de politique de confidentialité ou CGV non supprimées après mise à jour

Un crawl complet avec Screaming Frog révèle en quelques minutes l’ensemble de ces pages. Le filtre « Indexable » vous donne la liste exacte de ce que Google peut indexer sur votre site.

Les erreurs de configuration WordPress courantes

Ces erreurs ne génèrent pas d’alerte dans la Search Console. Elles s’accumulent silencieusement depuis l’installation et pénalisent le référencement sans que personne ne s’en rende compte. Ce sont souvent les premières choses que je corrige sur un site audité.

Les permaliens mal structurés

Le format des permaliens conditionne la structure de toutes vos URLs. Une fois des centaines d’articles publiés, changer les permaliens génère autant d’erreurs 404. Les erreurs fréquentes à l’installation :

• Permaliens laissés en /?p=123 (format par défaut à la création du site)
• Inclusion du nom de la catégorie dans l’URL des articles : /categorie/article/ : si vous renommez la catégorie, toutes les URLs changent
• URLs avec des dates : /2024/06/article/ : vieillit mal et crée des URLs longues
• Accents ou caractères spéciaux dans les slugs d’articles non nettoyés

La structure recommandée pour un blog ou un site vitrine est simplement /nom-de-larticle/, propre et pérenne.

La page d’accueil statique non définie

Par défaut, WordPress affiche les derniers articles en page d’accueil. Pour un site professionnel, la page d’accueil doit être une page statique définie manuellement dans Réglages > Lecture. Sans cette configuration :

• La page d’accueil n’a pas de title ni de meta description optimisés
• Le contenu de la page d’accueil change à chaque publication d’article
• Impossible d’optimiser l’accueil sur un mot-clé cible précis

Le titre du site et le tagline par défaut

À l’installation, WordPress attribue « Mon site WordPress » comme titre et « Tout sur WordPress » comme tagline. Ces valeurs se retrouvent dans le title de chaque page si elles ne sont pas remplacées. Vérifiez dans Réglages > Général que le titre du site correspond à votre nom de marque ou à votre positionnement cible.

Les catégories et les tags utilisés en doublon

C’est l’une des erreurs de configuration les plus fréquentes sur les sites WordPress avec beaucoup de contenu :

• Une catégorie « SEO » et un tag « SEO » qui génèrent deux pages d’archive avec le même contenu
• Des sous-catégories qui reprennent exactement les mêmes mots-clés que les articles qu’elles contiennent
• Des catégories créées à la volée sans réflexion sur l’architecture globale
• La catégorie par défaut « Non classé » laissée active et utilisée sur des articles

L’URL de WordPress différente de l’URL du site

Dans Réglages > Général, les champs « Adresse web de WordPress » et « Adresse web du site » doivent être identiques et en HTTPS. Des incohérences entre ces deux champs génèrent des boucles de redirection ou des problèmes d’accès au tableau de bord.

Les révisions d’articles en nombre illimité

Par défaut, WordPress sauvegarde une révision à chaque fois que vous enregistrez un article. Sur un site actif depuis plusieurs années, cela génère des milliers d’entrées en base de données qui ralentissent les requêtes. Ce n’est pas un problème SEO direct mais il impacte le temps de réponse serveur. La limite se configure dans le fichier wp-config.php avec la constante WP_POST_REVISIONS.

Les fichiers de debug en production

Le mode debug de WordPress (WP_DEBUG activé en production) peut afficher des erreurs PHP directement dans la source HTML des pages, visibles par Googlebot et par n’importe quel visiteur qui inspecte le code. À désactiver impérativement en production et à remplacer par un log vers un fichier privé.

Open Graph et Twitter Card absents ou mal configurés

Les balises Open Graph et Twitter Card ne sont pas des facteurs de classement directs mais elles conditionnent l’affichage de vos pages lors des partages sur les réseaux sociaux et dans certains résultats enrichis. Les erreurs courantes :

• Balises Open Graph absentes faute de plugin SEO configuré
• Image Open Graph non définie : le réseau social choisit n’importe quelle image de la page
• Description Open Graph identique à la meta description ou absente
• Conflit entre le plugin SEO et le thème qui génèrent tous les deux des balises Open Graph en doublon

Audit de sécurité WordPress

La sécurité fait partie intégrante d’un audit SEO WordPress. Un site piraté perd ses positions du jour au lendemain : Google le signale comme dangereux, les navigateurs affichent une alerte rouge et le trafic organique s’effondre. Les problèmes de sécurité ont aussi un impact direct sur les performances et la disponibilité du site. Voici les points à vérifier systématiquement.

Les mises à jour

C’est le point le plus simple et le plus négligé. Un site WordPress non mis à jour est une cible facile. Les trois niveaux à vérifier :

• Core WordPress : chaque version corrige des failles de sécurité documentées publiquement ; un site en retard de plusieurs versions est une invitation pour les bots d’attaque
• Plugins : les failles de sécurité les plus exploitées sur WordPress viennent des plugins, pas du core
• Thème : les thèmes reçoivent aussi des correctifs de sécurité, même s’ils sont moins fréquemment ciblés
• Version PHP : une version PHP en fin de vie (PHP 7.4 et antérieur) ne reçoit plus de correctifs de sécurité

Le plugin Health Check & Troubleshooting affiche en un coup d’œil l’état de santé de l’installation et les mises à jour manquantes.

La page de connexion exposée

L’URL par défaut /wp-admin/ et /wp-login.php est connue de tous les bots d’attaque. Les bonnes pratiques :

• Changer l’URL de connexion avec un plugin dédié (WPS Hide Login par exemple)
• Activer l’authentification à deux facteurs
• Limiter les tentatives de connexion (plugin Limit Login Attempts Reloaded)
• Bloquer l’accès à /wp-admin/ par IP si vous travaillez depuis une IP fixe

Le fichier xmlrpc.php

Le fichier xmlrpc.php est activé par défaut sur WordPress. Il permet des attaques par force brute amplifiées : un attaquant peut tester des milliers de combinaisons login/mot de passe en une seule requête via ce fichier. Sauf cas d’usage spécifique (application mobile WordPress, Jetpack), il doit être désactivé ou son accès bloqué dans le .htaccess.

Les comptes utilisateurs

Les comptes inutiles ou mal configurés sont une faille courante sur les sites WordPress qui ont eu plusieurs intervenants :

• Comptes administrateurs d’anciens prestataires non supprimés
• Compte « admin » avec le nom d’utilisateur par défaut, à renommer car c’est le premier testé par les bots
• Comptes avec des rôles trop élevés par rapport à leur usage réel
• Mots de passe faibles sur des comptes éditeurs ou contributeurs
• Comptes sans activité depuis plus d’un an non désactivés

Le SSL et HTTPS

HTTPS est un facteur de classement confirmé par Google depuis 2014. Les problèmes de configuration SSL fréquents sur WordPress :

• Certificat SSL installé mais site toujours accessible en HTTP sans redirection
• Contenu mixte : des ressources (images, scripts, feuilles de style) chargées en HTTP sur une page HTTPS
• Certificat expiré non renouvelé automatiquement
• URLs hardcodées en HTTP dans la base de données après migration vers HTTPS

Le plugin Really Simple SSL détecte et corrige automatiquement la plupart des problèmes de contenu mixte. Pour les URLs en base de données, l’outil Better Search Replace permet de remplacer toutes les occurrences HTTP en HTTPS en une opération.

Le fichier wp-config.php

Le fichier wp-config.php contient les identifiants de la base de données, les clés de sécurité et la configuration de l’installation. Il doit être protégé :

• Le déplacer un niveau au-dessus de la racine du site si votre hébergeur le permet
• Bloquer son accès direct via une règle .htaccess
• Vérifier que WP_DEBUG est bien à false en production
• S’assurer que les clés de sécurité (salts) sont générées et uniques

Les plugins et thèmes abandonnés

Un plugin non mis à jour depuis plus de deux ans et incompatible avec la version WordPress actuelle est une faille potentielle. Sur WordPress.org, vérifiez pour chaque plugin :

• Date de la dernière mise à jour
• Compatibilité avec la version WordPress actuelle
• Présence dans les bulletins de sécurité WPScan ou Wordfence

Le plugin Wordfence Security effectue un scan complet de l’installation et signale les fichiers modifiés, les plugins vulnérables et les tentatives d’intrusion récentes. C’est un bon point de départ pour évaluer l’état de sécurité global d’un site.

Audit des plugins et du thème

Les plugins sont la force de WordPress et sa principale faiblesse. Un site avec 30 plugins dont 10 inutiles, 5 en doublon de fonction et 3 abandonnés, c’est un site lent, instable et vulnérable. L’audit des plugins est souvent la partie qui génère les gains de performance les plus rapides. Pour un panorama complet des plugins SEO à conserver, consultez mon article sur les meilleurs plugins WordPress SEO.

Les plugins désactivés non supprimés

Un plugin désactivé ne charge pas ses scripts en front-end, mais il reste présent sur le serveur. Les conséquences :

• Les fichiers du plugin restent accessibles publiquement : s’il contient une faille, elle est exploitable même désactivé
• Il apparaît dans les scans de sécurité comme surface d’attaque potentielle
• Il occupe de l’espace disque et alourdit les sauvegardes

La règle est simple : si un plugin est désactivé depuis plus d’un mois et que vous ne prévoyez pas de le réactiver, supprimez-le.

Les plugins en doublon de fonction

C’est l’erreur la plus fréquente sur les sites qui ont eu plusieurs intervenants ou qui ont évolué au fil du temps. Les doublons les plus courants :

• Deux plugins de cache actifs simultanément : WP Rocket + W3 Total Cache, ou WP Super Cache + le cache de l’hébergeur mal configuré
• Deux plugins SEO actifs : Yoast SEO + Rank Math qui génèrent des balises en doublon dans le head
• Deux plugins de formulaire de contact : Contact Form 7 + WPForms
• Deux plugins de sécurité qui scannent les mêmes fichiers et se marchent dessus
• Deux plugins d’optimisation d’images qui recompressent les mêmes fichiers
• Un plugin de redirection alors que le plugin SEO gère déjà les redirections

Les plugins qui chargent leurs scripts partout

Certains plugins ajoutent leurs fichiers CSS et JavaScript sur toutes les pages du site, même là où ils ne servent à rien. Un plugin de formulaire de contact qui charge ses scripts sur chaque article de blog, un plugin de galerie qui injecte ses styles sur la page d’accueil : c’est du poids inutile sur chaque chargement de page. Query Monitor permet de voir exactement quels scripts et styles sont chargés sur chaque page et quel plugin en est responsable.

Les plugins abandonnés

Un plugin non mis à jour depuis plus de deux ans mérite une attention particulière. Sur le répertoire WordPress.org, vérifiez pour chaque plugin installé :

• Date de la dernière mise à jour
• Mention « Ce plugin n’a pas été testé avec les 3 dernières versions majeures de WordPress »
• Nombre d’installations actives en chute : signal que la communauté l’abandonne
• Absence de réponses aux tickets de support ouverts

Les plugins qui font une seule chose remplaçable par du code

Certains plugins installés pour une fonction mineure peuvent être remplacés par quelques lignes dans le fichier functions.php du thème enfant, sans dépendance externe :

• Plugin pour supprimer l’emoji WordPress du front-end
• Plugin pour désactiver les commentaires
• Plugin pour ajouter rel= »noopener » sur les liens externes
• Plugin pour modifier le login URL (faisable via .htaccess)
• Plugin pour supprimer la version WordPress du head

L’audit du thème

Le thème est la fondation technique du site. Les problèmes récurrents à l’audit :

• Modifications directes dans le thème parent : perdues à chaque mise à jour, toujours travailler dans un thème enfant
• Thème premium avec licence expirée : plus de mises à jour de sécurité, plus de support
• Thème avec page builder intégré non utilisé (Divi, Elementor inclus dans le thème) qui charge ses scripts même si vous utilisez Gutenberg
• Thème lourd avec des dizaines de fichiers CSS et JS chargés sur chaque page sans conditionnement
• Thème qui génère des erreurs PHP dans le debug log
• Thème non testé avec la version PHP actuelle du serveur

Pour évaluer l’impact réel du thème sur les performances, désactivez temporairement tous les plugins et testez le score PageSpeed avec le thème seul. Si le score est déjà mauvais sans plugins, le problème vient du thème.

Le nombre total de plugins

Il n’y a pas de chiffre magique, mais au-delà de 20 plugins actifs sur un site vitrine ou un blog, c’est souvent le signe d’une architecture mal pensée. Chaque plugin ajoute des requêtes en base de données, des fichiers à charger et une surface d’attaque supplémentaire. L’objectif à l’audit est d’identifier tout ce qui peut être supprimé, fusionné ou remplacé par une solution native WordPress sans perte de fonctionnalité.

Performance et Core Web Vitals

Depuis 2021, les Core Web Vitals sont des facteurs de classement officiels. Un site WordPress lent perd des positions face à des concurrents plus rapides à contenu équivalent. C’est aussi un problème de conversion : chaque seconde de chargement supplémentaire augmente le taux de rebond. Pour aller plus loin sur ce sujet, j’ai rédigé un guide complet sur les Core Web Vitals WordPress.

Les trois métriques à connaître

• LCP (Largest Contentful Paint) : temps d’affichage du plus grand élément visible à l’écran. Seuil à viser : moins de 2,5 secondes. C’est souvent l’image hero ou le titre principal qui déclenche cette métrique.
• CLS (Cumulative Layout Shift) : stabilité visuelle de la page pendant le chargement. Seuil à viser : moins de 0,1. Un bandeau cookie qui pousse le contenu, une image sans dimensions définies, une police qui se charge après le texte : autant de sources de CLS.
• INP (Interaction to Next Paint) : réactivité aux interactions utilisateur. Remplace le FID depuis mars 2024. Seuil à viser : moins de 200ms. Les scripts JavaScript lourds en sont la principale cause.

Les images

Les images sont la première cause de mauvais LCP et de pages lentes sur WordPress. Ce qu’il faut vérifier :

• Format : passer toutes les images en WebP, qui réduit le poids de 25 à 35% par rapport au JPEG sans perte visible de qualité
• Dimensions : servir des images à la bonne taille, ne pas charger une image 2000px pour l’afficher en 400px
• Compression : utiliser un plugin d’optimisation automatique à l’upload (Imagify, ShortPixel, Smush)
• Lazy loading : activer le chargement différé sur les images hors écran, natif WordPress depuis la version 5.5
• Préchargement du LCP : ajouter un attribut fetchpriority="high" sur l’image hero pour qu’elle se charge en priorité
• Images sans attribut alt : problème d’accessibilité et signal SEO manquant

Le cache

Sans cache, WordPress génère une page dynamiquement à chaque visite en interrogeant la base de données. Avec un cache correctement configuré, la page est servie comme un fichier statique, bien plus rapide. Les points à vérifier :

• Présence d’un plugin de cache actif et correctement configuré (WP Rocket, W3 Total Cache, LiteSpeed Cache selon l’hébergeur)
• Cache navigateur activé pour les ressources statiques (CSS, JS, images)
• Compression GZIP ou Brotli activée côté serveur
• Cache incompatible avec l’hébergeur : certains hébergeurs ont leur propre système de cache qui peut entrer en conflit avec un plugin de cache
• Pages exclues du cache à tort : pages de panier WooCommerce, pages membres, ou incluses par erreur : pages avec contenu personnalisé

Les scripts JavaScript et CSS

Les fichiers JS et CSS mal gérés bloquent le rendu de la page et dégradent le LCP et l’INP. Les optimisations à vérifier :

• Minification des fichiers CSS et JS : supprimer les espaces et commentaires pour réduire le poids
• Concaténation : regrouper plusieurs fichiers CSS en un seul pour réduire le nombre de requêtes HTTP
• Chargement différé des scripts non critiques : attribut defer ou async sur les scripts qui ne sont pas nécessaires au rendu initial
• Google Fonts chargées depuis les serveurs Google : générer des requêtes DNS supplémentaires, à auto-héberger ou à précharger
• Scripts de tracking mal configurés : GTM qui charge des dizaines de tags inutiles, pixels publicitaires sur toutes les pages
• Page builders qui injectent leur CSS global sur chaque page même quand ils ne sont pas utilisés

L’hébergement

Le Time to First Byte (TTFB) mesure le temps de réponse du serveur avant que le navigateur reçoive le premier octet de la page. Un TTFB supérieur à 800ms signale un problème d’hébergement ou de configuration serveur. Les causes fréquentes sur WordPress :

• Hébergement mutualisé bas de gamme avec des ressources partagées sur des centaines de sites
• Absence de CDN pour les visiteurs éloignés du serveur principal
• Base de données non optimisée : tables fragmentées, révisions en nombre illimité, transients expirés non nettoyés
• Version PHP obsolète : PHP 8.x est significativement plus rapide que PHP 7.x sur WordPress
• Requêtes N+1 générées par des plugins mal développés : détectables avec Query Monitor

Le mobile

Google utilise l’indexation mobile-first depuis 2019 : c’est la version mobile de votre site qui détermine votre classement, pas la version desktop. Les points à vérifier spécifiquement sur mobile :

• Thème responsive : les éléments s’adaptent-ils correctement à tous les formats d’écran
• Texte lisible sans zoom : taille de police minimale de 16px sur mobile
• Éléments cliquables suffisamment espacés : boutons et liens trop proches génèrent des erreurs dans la Search Console
• Contenu identique entre version mobile et desktop : ne pas masquer du contenu important en CSS sur mobile
• Score PageSpeed mobile : souvent bien inférieur au score desktop, c’est pourtant lui qui compte

Audit du contenu et des balises SEO

Le contenu et les balises SEO sont ce que Google lit pour comprendre de quoi parle votre site et comment le classer. Des balises title en doublon, un H1 absent ou un contenu trop court sur des dizaines de pages : autant de signaux négatifs qui s’accumulent et pénalisent l’ensemble du domaine.

Les balises title

La balise title est le signal on-page le plus fort pour Google. Les erreurs à corriger en priorité :

• Titles en doublon : deux pages avec exactement le même title envoient un signal de confusion à Google sur laquelle classer
• Title absent : WordPress utilise par défaut le nom du site, sans mot-clé cible
• Title trop long : au-delà de 60 caractères, il est tronqué dans les résultats de recherche
• Title trop court ou générique : « Accueil », « Contact », « Blog » sans mot-clé
• Nom du site répété dans chaque title au détriment du mot-clé : « Mon Site | Article » au lieu de « Mot-clé principal | Mon Site »
• Titles générés automatiquement par le thème sans passer par le plugin SEO

Les meta descriptions

La meta description n’est pas un facteur de classement direct mais elle influence le taux de clic dans les résultats de recherche. Les problèmes courants :

• Meta descriptions absentes : Google en génère une automatiquement depuis le contenu, souvent peu engageante
• Meta descriptions en doublon entre plusieurs pages
• Meta descriptions trop longues : tronquées au-delà de 155 à 160 caractères
• Meta descriptions qui ne reprennent pas l’intention de recherche de la page

La structure des balises Hn

Les balises de titre structurent le contenu pour Google et pour les lecteurs. La hiérarchie doit être logique et cohérente :

• H1 absent : chaque page doit avoir exactement un H1 qui correspond au sujet principal
• Plusieurs H1 sur la même page : le thème peut en générer un, le contenu un autre
• H1 identique au title : autorisé mais une légère variation est préférable
• Hiérarchie cassée : H3 sans H2 parent, H4 sans H3 parent
• Balises de titre utilisées pour la mise en forme plutôt que pour la structure sémantique

Le contenu dupliqué interne

Le contenu dupliqué interne est fréquent sur WordPress sans que les propriétaires de sites s’en rendent compte. Les sources principales :

• Pages d’archive qui reprennent les extraits des articles : catégorie, tag, auteur, date
• Pagination : le contenu de la page 1 d’une catégorie et de la page 2 se recoupent partiellement
• Version HTTP et HTTPS du même site accessibles simultanément sans redirection
• Version avec et sans www accessibles simultanément
• URL avec slash final et sans slash final qui renvoient toutes les deux du contenu : /article/ et /article
• Paramètres de tri WooCommerce qui créent des variantes d’URL pour les mêmes pages produits

Le thin content

Le thin content désigne les pages avec trop peu de contenu pour apporter une valeur réelle à l’utilisateur. Google les perçoit comme des pages de faible qualité qui dégradent la perception globale du domaine. Sur WordPress, les sources de thin content sont :

• Pages de catégorie sans texte d’introduction optimisé : juste une liste d’articles
• Articles très courts publiés pour remplir un calendrier éditorial sans apporter d’information concrète
• Pages de tag avec un seul article
• Pages créées automatiquement par des plugins avec peu ou pas de contenu
• Pages de résultats de recherche WooCommerce vides ou quasi-vides

Les balises canoniques

La balise canonique indique à Google quelle est la version de référence d’une page quand plusieurs URLs affichent un contenu similaire. Les erreurs de configuration fréquentes sur WordPress :

• Canonique auto-référentielle mal configurée : une page pointe vers une autre URL comme canonique alors qu’elle devrait pointer vers elle-même
• Canonique vers une page noindex : contradiction qui perturbe Google
• Absence de canonique sur les pages paginées
• Conflit entre la canonique générée par le plugin SEO et celle générée par le thème ou un autre plugin

Les données structurées

Les données structurées Schema.org permettent à Google de comprendre le type de contenu d’une page et d’afficher des résultats enrichis (étoiles, FAQ, fil d’Ariane, etc.). Sur WordPress, les points à vérifier :

• Schema Article ou BlogPosting sur les articles de blog
• Schema BreadcrumbList pour le fil d’Ariane : généré automatiquement par Yoast SEO et Rank Math si bien configuré
• Schema Organization ou Person sur la page d’accueil selon que le site représente une entreprise ou un individu
• Schema FAQPage sur les pages avec des questions-réponses
• Données structurées invalides ou incomplètes : à vérifier avec le Rich Results Test de Google
• Schémas en doublon générés par le thème et le plugin SEO simultanément

La cannibalisation de mots-clés

La cannibalisation se produit quand plusieurs pages de votre site ciblent le même mot-clé. Google ne sait pas quelle page classer et les deux se retrouvent souvent mal positionnées. Pour la détecter :

• Recherche site:votresite.fr "mot-clé cible" dans Google pour voir toutes les pages qui l’utilisent
• Rapport de performance dans la Search Console : filtrer par requête et voir si plusieurs URLs apparaissent pour la même requête
• Ahrefs ou Semrush : rapport de cannibalisation de mots-clés disponible dans l’outil d’audit de site

Maillage interne

Le maillage interne est l’un des leviers SEO les plus sous-exploités sur WordPress. Il permet de distribuer l’autorité entre les pages, de guider Google dans la compréhension de votre architecture et d’aider les visiteurs à naviguer vers le contenu le plus pertinent. Un bon maillage interne peut faire progresser des pages sans toucher au contenu ni acquérir un seul backlink. Pour aller plus loin, consultez mon guide SEO WordPress complet.

Les pages orphelines

Une page orpheline est une page sans aucun lien interne qui y pointe. Google peut la trouver via le sitemap mais elle n’accumule aucune autorité interne et reste peu visible dans l’architecture du site. Sur WordPress, les pages orphelines les plus fréquentes sont :

• Pages de services créées puis oubliées dans le menu
• Articles de blog jamais cités dans d’autres articles
• Pages de destination créées pour des campagnes et jamais linkées depuis le site
• Anciennes pages dont les liens internes ont été supprimés lors d’une refonte

Screaming Frog identifie les pages orphelines en croisant le crawl du site avec le sitemap XML. Tout ce qui est dans le sitemap mais jamais cité dans le crawl est orphelin.

Les ancres de liens internes

L’ancre d’un lien interne est un signal sémantique fort pour Google : elle lui dit de quoi parle la page de destination. Les erreurs courantes :

• Ancres génériques : « cliquez ici », « en savoir plus », « voir aussi » : aucune information sémantique
• Ancres toujours identiques vers la même page : sur-optimisation qui peut être perçue comme artificielle
• Ancres qui ne correspondent pas au sujet de la page cible
• Liens internes sans ancre : image cliquable sans attribut alt, bouton sans texte descriptif

La distribution de l’autorité

Toutes vos pages n’ont pas la même valeur stratégique. Les pages commerciales et les pages piliers de votre cocon sémantique doivent recevoir le plus de liens internes. Ce qu’il faut vérifier :

• Vos pages les plus importantes reçoivent-elles suffisamment de liens internes depuis vos autres contenus
• Les articles de blog récents lient-ils vers les articles plus anciens sur des sujets connexes
• Les pages de catégorie sont-elles linkées depuis les articles qu’elles contiennent
• La page d’accueil concentre-t-elle trop de liens internes au détriment des pages profondes

Le nombre de liens par page

Il n’y a pas de limite officielle mais une page avec 200 liens internes dilue l’autorité transmise par chacun d’eux. Les situations à corriger :

• Footer avec des dizaines de liens vers toutes les pages du site sur chaque page
• Menus de navigation très profonds qui multiplient les liens sur chaque page
• Articles de blog avec des liens internes systématiques vers les mêmes pages à chaque occurrence d’un mot-clé

Les liens internes cassés

Un lien interne qui pointe vers une page en erreur 404 ou vers une URL redirigée perd de l’autorité en route. Screaming Frog et le plugin Broken Link Checker remontent ces situations automatiquement. Les causes fréquentes sur WordPress :

• Changement de structure de permaliens sans mise à jour des liens dans les anciens articles
• Pages supprimées sans mise à jour des liens qui y pointaient
• Migration HTTP vers HTTPS incomplète : liens internes encore en HTTP dans les articles anciens
• Changement de nom de domaine sans mise à jour des liens en base de données

Checklist audit SEO WordPress : par où commencer

Un audit complet prend du temps. Si vous ne savez pas par où commencer, voici comment je priorise les actions sur chaque site audité. Les problèmes sont classés par impact potentiel et par facilité de correction.

Ce qu’un audit ne remplace pas

Un audit SEO WordPress identifie les problèmes et les opportunités. Il ne les corrige pas automatiquement. La valeur réelle d’un audit est dans le plan d’action priorisé qui suit : quoi corriger en premier, pourquoi, et quel impact attendre. Sur un site avec des dizaines de problèmes techniques, tout corriger en même temps sans ordre de priorité est contre-productif.

Si vous préférez déléguer cette étape plutôt que de la faire vous-même, je propose un accompagnement SEO WordPress complet qui inclut l’audit, le plan d’action et la mise en oeuvre. Le pré-audit est gratuit.