Audit SEO WordPress : ce que votre extension met vraiment dans la page

Par SEOgrinder · Publié le 4 novembre 2026 · 9 min de lecture

Réponse courte : Un audit SEO WordPress lit la page que votre site livre réellement, car c’est ce que reçoivent les moteurs de recherche, et non les réglages saisis dans une extension (souvent appelée plugin). Ouvrez un article, lisez son title, sa méta-description, sa canonical, ses règles robots, son sitemap et ses données structurées, puis comparez avec ce que vous vouliez régler. Quatre lignes curl ou l’analyse gratuite de SEOgrinder suffisent, quelle que soit l’extension. Une page propre retire des obstacles ; elle ne promet aucun classement.

Qu’est-ce qu’un audit SEO WordPress, et pourquoi lire la page plutôt que les réglages ?

Un audit SEO WordPress ouvre une page publique de votre site comme le ferait un visiteur ou un robot d’exploration, et rapporte ce qu’il trouve dans le HTML et dans la réponse du serveur : quel title, quelle description, quelle adresse canonical, quelles règles robots, s’il existe un sitemap, si des données structurées sont présentes et lisibles.

C’est différent des écrans de votre extension SEO. Un écran de réglages montre ce que vous avez saisi. La page montre ce qui est arrivé. Entre les deux se trouvent votre thème, d’autres extensions, des copies en cache et WordPress lui-même, et chacun peut modifier ou supprimer ce que vous aviez prévu d’envoyer. La page de Google sur les méta-descriptions cite d’ailleurs WordPress parmi les systèmes où l’on ne peut pas toujours modifier le HTML directement et où l’on passe par une page de réglages.

Cet article montre comment lire le résultat en quelques minutes, pour n’importe quelle extension, et ce qu’une vérification de l’extérieur ne peut pas vous dire. SEOgrinder est notre outil ; nous le développons. Une extension WordPress de notre part est prévue ; elle n’existe pas encore, et l’outil web suffit pour tout ce qui suit.

Qui écrit dans le HTML d’une page WordPress ?

Quatre intervenants peuvent toucher aux mêmes balises. C’est pourquoi les réglages seuls ne vous disent jamais le résultat.

WordPress lui-même. Le noyau écrit certaines balises sans aucune extension. Sa fonction rel_canonical() est documentée ainsi : « Outputs rel=canonical for singular queries » (developer.wordpress.org). Elle concerne donc les contenus uniques comme les articles et les pages, pas les archives. Depuis la version 5.5, le noyau propose aussi un index de sitemaps à l’adresse /wp-sitemap.xml et le référence dans le robots.txt (annonce de l’équipe du noyau, 22 juillet 2020).
Les extensions et les thèmes, par des filtres. La documentation de wp_get_document_title() énumère quatre filtres qui modifient le title, et le filtre wp_robots fait de même pour la balise meta robots (title, robots). Toute extension ou tout thème peut les utiliser.
Le thème. Les balises de l’en-tête sont affichées par le hook wp_head. La documentation indique que, même si cela dépend du thème, le hook est largement pris en charge. Notre lecture : un thème qui ne l’appelle jamais n’affiche rien de ce qui s’y accroche.
Les caches. Un cache de pages ou un CDN peut servir une copie plus ancienne du HTML que celle que vos réglages produisent aujourd’hui.

L’audit SEO WordPress en six points à lire sur la page

Prenez un article, et pas seulement la page d’accueil. Lisez ces six points dans cet ordre.

1. Le title

Cherchez un seul <title>, propre à cette page. La page de Google sur les liens de titre conseille d’éviter le « repeated or boilerplate text », c’est-à-dire les textes répétés ou génériques, dans les titres. Si votre extension utilise un modèle de title, lisez le résultat sur un article, sur une page et sur l’index du blog.

2. La méta-description

La balise <meta name="description"> est facultative pour Google : il « will sometimes use » son contenu pour le snippet quand elle décrit la page mieux que le texte de la page (documentation sur les snippets). La même page dit : « Identical or similar descriptions on every page of a site aren’t helpful when individual pages appear in search results. » Si vous avez rédigé des descriptions dans l’extension et qu’aucune n’apparaît dans le HTML, quelque chose entre les réglages et la page les a absorbées.

3. La canonical

Cherchez exactement un <link rel="canonical"> avec une adresse https absolue qui, sur une page normale, pointe vers la page elle-même. La page de Google sur les canonical recommande une canonical auto-référente sur la page canonique et des adresses absolues plutôt que relatives. Deux canonical aux adresses différentes se contredisent : quelque chose en écrit une seconde, et il faut trouver quoi.

4. Les règles robots

Les règles se trouvent à trois endroits : la balise meta robots dans le HTML, l’en-tête de réponse X-Robots-Tag (il n’apparaît jamais dans le code source de la page) et le fichier /robots.txt. Cherchez un noindex sur toute page qui doit pouvoir être trouvée.

Le cas classique de WordPress est la case « Discourage search engines from indexing this site » (libellé de la documentation en anglais) sous Réglages, Lecture. La documentation (dernière mise à jour : 8 juin 2024) dit qu’elle écrit <meta name='robots' content='noindex,nofollow' /> dans l’en-tête « if wp_head is used », et que « it is up to search engines to honor your request ». L’annonce du noyau ajoute que les sitemaps sont désactivés avec ce réglage. Une case, deux effets, tous deux visibles sur la page.

Une balise robots seule n’est pas une alerte. Le 4 novembre 2026, nous avons lancé la commande ci-dessous sur https://wordpress.org/news/ : sa seule balise robots était <meta name='robots' content='max-image-preview:large' />, sans noindex. Si des règles se contredisent, Google applique la plus stricte : « the more restrictive rule applies » (balise meta robots). Un noindex oublié l’emporte donc sur tout ce que dit l’extension.

Pour le robots.txt, lisez le fichier, pas le réglage : WordPress peut le générer (do_robots() : « Displays the default robots.txt file content ») et du code peut le modifier par le filtre robots_txt (fonction, filtre).

5. Le sitemap

Cherchez un sitemap qui répond 200, liste les pages que vous voulez voir dans la recherche et est annoncé dans le robots.txt par une ligne Sitemap:. L’adresse du noyau est /wp-sitemap.xml ; une extension peut en utiliser une autre, suivez donc la ligne du robots.txt. Un sitemap n’est pas une promesse : selon Google, il « doesn’t guarantee that all the items in your sitemap will be crawled and indexed » (présentation des sitemaps).

6. Les données structurées

Cherchez des blocs <script type="application/ld+json"> qui se lisent sans erreur et dont les types correspondent à la page. Google recommande JSON-LD quand votre installation le permet (introduction aux données structurées). Un balisage cassé est ignoré : leur simple présence ne prouve donc pas grand-chose.

Comment faire la vérification : quatre lignes ou une analyse

En ligne de commande. Remplacez l’adresse par celle de l’un de vos articles. La première ligne affiche chaque balise concernée : le title, la description et la canonical doivent apparaître chacun une fois (plusieurs blocs JSON-LD sont normaux), et la première ligne de title est celui de la page. Les autres montrent l’en-tête, le robots.txt et le statut du sitemap du noyau.

curl -s https://example.com/mon-article/ | grep -o -i -E '<title>[^<]*</title>|<meta[^>]*name=.(description|robots).[^>]*>|<link[^>]*rel=.canonical.[^>]*>|<script[^>]*ld\+json[^>]*>'
curl -sI https://example.com/mon-article/ | grep -i x-robots-tag
curl -s https://example.com/robots.txt
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-sitemap.xml

Avec SEOgrinder. C’est gratuit et sans compte.

Ouvrez SEOgrinder, saisissez l’adresse d’un article ou d’une page publique et lancez l’analyse.
Lisez l’onglet Tâches. Il liste les constats triés par effet, par exemple « Aucune méta-description », « Aucune balise canonical », « 2 balises canonical différentes », « La page est exclue de Google », « robots.txt bloque cette URL », « Aucun sitemap trouvé », « Aucune donnée structurée ».
Ouvrez Page sur Google. Ses cartes montrent ce qui a été trouvé, pas seulement ce qui ne va pas : Titre et description affiche le texte des deux balises, Indexation indique si la page peut être indexée, son statut HTTP, si le robots.txt l’autorise et si elle figure dans le sitemap, Canonical donne l’adresse et précise si elle « Pointe vers elle-même », Données structurées liste les types et le nombre de blocs JSON-LD.
Modifiez le réglage dans WordPress, videz le cache de vos pages et cliquez sur Réanalyser. Les rapports restent en cache jusqu’à 24 heures.

SEOgrinder lit ce que reçoit n’importe quel visiteur. Il ne se connecte pas à WordPress, ne voit pas vos réglages et ne dit pas quelle extension a écrit une balise.

Ce que disent les pages des extensions, et ce que seule la page confirme

Sur wordpress.org, les grandes extensions SEO décrivent leurs fonctions avec leurs propres mots. Yoast SEO met en avant « Canonical URLs to prevent duplicate content issues » et « Advanced XML sitemaps for clear site indexing » (page de l’extension). Rank Math cite « 16+ Schema types to add rich results in a few clicks » (page de l’extension). All in One SEO cite « automatic canonical URLs and per-post canonical tags to prevent duplicate content » (page de l’extension). Les trois portent les mots-clés schema, seo et xml sitemap (vérifié le 4 novembre 2026).

Ces phrases disent quelles fonctions une extension propose. Elles ne disent pas ce que contient votre page aujourd’hui, car cela dépend de vos réglages, de votre thème, des autres extensions et des caches. Nous n’avons pas testé ces extensions et nous ne les comparons pas : rien ici ne dit que l’une écrit un meilleur HTML qu’une autre. La seule preuve, c’est la page.

Ce qu’une vérification de l’extérieur ne peut pas dire

Si Google a indexé la page. L’analyse montre ce que votre serveur livre maintenant. L’outil d’inspection de l’URL de Google « provides information about Google’s indexed version of a specific page », et la même page d’aide prévient : « Your page may have changed or become unavailable since Google last saw it. » Si une page manque dans Google, c’est donc la Search Console qu’il faut interroger.
Qui a écrit une balise. Vous voyez la balise, pas si c’est le noyau, le thème ou une extension qui l’a affichée. Notre conseil : sur une copie du site, désactivez les suspects un par un.
Les classements. Aucun outil ne peut promettre une position.
Tout ce qui se trouve derrière une connexion. SEOgrinder ne vérifie que les pages publiques.

Erreurs fréquentes

Juger d’après l’écran de réglages. Il montre ce que vous avez saisi, pas ce qui est arrivé.
Ne vérifier que la page d’accueil. Les articles, les pages, les archives et les catégories viennent de modèles différents, et la fonction canonical du noyau ne s’exécute que sur les contenus uniques. Lisez un article, une page, l’index du blog et une catégorie.
Laisser « Discourage search engines » coché après le lancement. Selon la documentation, la case écrit une balise noindex et, selon l’annonce du noyau, elle désactive les sitemaps du noyau.
Deux auteurs pour une même balise. Une seconde extension ou le thème ajoute une autre canonical. SEOgrinder signale une page qui nomme plus d’une adresse différente.
Lire une ancienne copie. Videz le cache après chaque modification, et utilisez Réanalyser dans SEOgrinder.
Confondre « la balise existe » et « la balise est juste ». Une canonical peut pointer vers une page qui ne répond pas (« La canonical pointe vers une page inaccessible »), et un sitemap peut lister des adresses qui redirigent.

Questions fréquentes

Ai-je besoin d’une autre extension pour faire un audit SEO WordPress ?

Non. Une vérification de l’extérieur n’installe rien. Les lignes curl demandent un terminal ; SEOgrinder n’a besoin que de l’adresse.

Est-il important d’utiliser Yoast, Rank Math ou All in One SEO ?

Pas pour la vérification. Elle lit la page livrée et ne demande pas quelle extension l’a écrite. Ce que chaque extension propose figure sur sa propre page wordpress.org ; ce que contient votre page, seule la page le montre.

Pourquoi ma méta-description manque-t-elle alors que je l’ai écrite dans l’extension ?

Nous ne voyons pas votre site : ce sont des causes à écarter, pas un diagnostic. Une ancienne copie en cache ; un thème qui n’appelle pas wp_head ; une description définie pour un autre type de page que celui que vous avez vérifié ; une autre extension ou le thème qui l’écrase.

Votre prochaine étape

Choisissez un article de votre site et lancez les quatre lignes ou l’analyse gratuite de SEOgrinder. Corrigez la première balise qui diffère de ce que vous aviez voulu régler, videz le cache et cliquez sur Réanalyser. Pour la liste plus large des contrôles, consultez notre checklist audit SEO.