Audit SEO WordPress en français : la checklist

Tapez « audit SEO WordPress » dans Google depuis la France et regardez ce qui remonte : des pages en anglais, presque exclusivement. Des éditeurs d'extensions, des agences américaines, des plateformes d'hébergement infogéré. Le moteur ne trouve pas mieux à vous proposer en français, alors il vous sert de l'anglais. Ce n'est pas un détail de classement, c'est un aveu : sur un sujet que des dizaines de milliers de personnes gèrent chaque jour dans ce pays, il n'existe presque rien d'écrit dans leur langue et avec les mots de leur interface.

Ce guide est cette page manquante. Il est écrit en français, il utilise les noms des écrans tels qu'ils apparaissent dans la traduction française de WordPress — Réglages, Lecture, Médias, Permaliens, Santé du site — et il ne vous demande d'acheter aucun outil. Vous n'y trouverez pas non plus de liste de trois cents points à cocher. Ces listes existent déjà, elles sont impressionnantes, et elles produisent chez presque tout le monde le même résultat : on les ouvre, on les regarde, on referme l'onglet et on ne corrige rien.

Le plan est simple. On commence par les trois niveaux auxquels une erreur peut vivre, parce que c'est la seule idée qui change vraiment la façon de travailler : selon le niveau, une correction se fait une fois ou trois cents fois. On passe ensuite aux neuf contrôles à mener sur une page, chacun avec le geste exact qui le vérifie en trente secondes dans votre navigateur. Vient après la partie proprement WordPress : les extensions qui se doublent, les plans de site en double, les archives qui fabriquent des pages toutes seules, les images qui se multiplient par huit. Puis les signaux web essentiels, avec les seuils publiés et la cause locale la plus fréquente pour chacun. Enfin, l'ordre dans lequel corriger, et un rendez-vous mensuel de quarante-cinq minutes qui tient dans la vraie vie.

Une précision de méthode avant de commencer. Les seuls chiffres de cet article sont des règles publiées par les éditeurs eux-mêmes, relues en français le jour de la rédaction : la documentation francophone de WordPress d'un côté, l'aide de la Search Console de l'autre. Vous ne trouverez ici aucune statistique du genre « x % des sites WordPress souffrent de tel problème ». Ces nombres circulent, ils ne portent jamais de date, ils ne sont reproductibles nulle part, et surtout ils ne vous disent rien sur votre site. Vous ne trouverez pas non plus de note de performance affichée par telle ou telle extension : chaque éditeur note selon sa propre grille, ce qui rend le chiffre incomparable, y compris avec lui-même d'une version à l'autre.

Les trois niveaux d'un audit, et celui que WordPress rate le plus souvent

La plupart des audits ratent pour une raison qui n'a rien à voir avec la technique : ils confondent la page où l'on constate l'erreur et l'endroit où l'erreur se répare. Vous ouvrez un rapport, vous voyez « titre dupliqué » sur cent quarante adresses, vous corrigez les trois premières à la main, et vous abandonnez au bout de vingt minutes. Le problème n'était pas votre courage. Le problème est que ces cent quarante titres sont fabriqués par une seule ligne dans un modèle, et qu'il fallait aller la modifier là-bas, une fois.

Niveau 1 : le site entier

Ce niveau contient peu de choses, mais chacune peut effacer tout le reste. On y trouve l'indexation générale, le plan de site, le fichier robots.txt, l'adresse canonique du domaine, le certificat, et la manière dont les contenus sont rangés les uns par rapport aux autres.

Le point le plus dangereux de tout le niveau 1 tient dans une case à cocher. Dans la documentation francophone de WordPress, la page « Écran Réglages de lecture » décrit un réglage nommé Visibilité par les moteurs de recherche. Quand la case « Demander aux moteurs de recherche de ne pas indexer ce site » est cochée, WordPress ajoute dans la section head du code source une balise meta robots qui porte les valeurs noindex et nofollow, et il retire du fichier robots.txt la ligne indiquant l'adresse du plan de site qu'il génère lui-même. La documentation ajoute une précision honnête et souvent mal comprise : ce réglage ne bloque pas l'accès au site, il appartient aux moteurs d'honorer ou non la demande.

Cette case est cochée par défaut sur beaucoup de sites en construction, et elle le reste. Un développeur la coche pour travailler tranquillement, la mise en ligne se passe, personne ne pense à revenir dessus. Le site est parfaitement visible pour un humain, il est simplement invisible pour le moteur. On voit régulièrement des refontes entières attendre plusieurs mois avant que quelqu'un remarque cette ligne dans le code source. C'est le premier contrôle de la liste plus bas, et ce n'est pas un hasard.

Niveau 2 : le gabarit, celui que personne ne regarde

Un site WordPress ne contient pas des pages, il contient des modèles qui fabriquent des pages. Le thème définit ce qui apparaît en haut, comment se construit la balise titre, quel intertitre reçoit le nom de la catégorie, quels blocs se répètent en bas de chaque article, à quoi ressemble une archive de catégorie, comment se comporte la deuxième page d'une liste. Toutes les pages qui passent par un même modèle héritent des mêmes qualités et des mêmes défauts.

C'est le niveau le plus rentable, et de très loin. Une correction dans un modèle change d'un coup toutes les pages qui en sortent, y compris celles que vous publierez l'an prochain. C'est aussi le seul niveau où le travail se capitalise : une page corrigée à la main reste une page corrigée à la main, tandis qu'un modèle corrigé continue de travailler pour vous sans que vous y pensiez.

Et pourtant, c'est le niveau que les outils grand public ignorent. Une extension de référencement note vos pages une par une. Un robot d'exploration liste vos adresses une par une. Ni l'un ni l'autre ne vous dit « ces cent quarante pages viennent du même modèle, allez voir le modèle ». Ce regroupement, vous devez le faire vous-même, et il ne demande rien d'autre que du bon sens : quand la même erreur revient sur beaucoup d'adresses qui se ressemblent, cherchez ce qu'elles ont en commun.

Niveau 3 : la page

Le troisième niveau est celui que tout le monde connaît : le titre, la description, les intertitres, le contenu réel, les images, les liens qui entrent et qui sortent. C'est le niveau des neuf contrôles de la section suivante. Il est indispensable, mais il vient en dernier dans la réflexion, même s'il vient souvent en premier dans les rapports d'outils.

Une remarque de méthode. Le niveau 3 est le seul où le contenu compte vraiment, c'est-à-dire où l'on peut se demander si la page répond ou non à la question de la personne qui arrive. Cet aspect-là dépasse largement la technique, et il a sa méthode propre : nous l'avons décrite dans un guide entier consacré à l'audit sémantique et à la façon de reprendre un contenu déjà publié. Le présent article ne rejoue pas cette méthode ; il s'occupe de tout ce qui, autour du contenu, l'empêche d'être vu.

Ce que l'outil intégré à WordPress teste vraiment

Beaucoup de personnes commencent leur audit par le seul écran qui porte un nom rassurant : Outils, puis Santé du site. L'écran affiche une note globale, une liste de problèmes critiques, des améliorations recommandées et des tests passés. C'est un excellent outil. Il ne teste simplement rien de ce qui décide d'un référencement.

Ce n'est pas une opinion. La documentation francophone de WordPress publie elle-même la liste des éléments testés, et elle la range en deux familles : Sécurité et Performance. Du côté Sécurité : le mode de débogage, l'utilisation du HTTPS, la présence de thèmes ou d'extensions inactives, la prise en charge de SSL, les mises à jour en arrière-plan, la communication avec wordpress.org, les en-têtes d'autorisation, les requêtes de bouclage. Du côté Performance : la version de WordPress, celle de PHP, celle du serveur SQL, les modules PHP installés, la validité du fuseau horaire, la présence de sessions PHP, la prise en charge du jeu de caractères UTF8mb4.

Comptez : seize tests, et aucun ne regarde une balise, une adresse, un plan de site, un contenu ou un lien. Un site peut afficher une note parfaite sur cet écran et être entièrement désindexé. L'inverse est vrai aussi : une alerte sur la version de PHP ne dit rien de vos chances d'être trouvé. Gardez cet écran pour ce qu'il fait très bien, la santé technique de l'installation, et ne lui demandez pas un diagnostic qu'il n'a jamais prétendu fournir.

La conséquence pratique, en une phrase

Avant d'ouvrir la moindre liste d'erreurs, prenez l'habitude de poser une question unique devant chaque ligne : est-ce que cela se répare au niveau du site, du gabarit ou de la page ? Trois secondes de réflexion, et vous saurez si la correction prendra deux minutes pour tout le site ou deux minutes multipliées par le nombre d'adresses concernées. Cette question, à elle seule, sépare les audits qui aboutissent de ceux qui finissent dans un tableur qu'on ne rouvre jamais.

Neuf contrôles à l'échelle d'une page, avec le geste qui les vérifie

Voici la partie que vous pouvez faire aujourd'hui, sans rien installer et sans créer aucun compte. Choisissez une page importante de votre site — une page de service, une fiche produit, un article qui reçoit du trafic — et ouvrez son code source. Sur un ordinateur, la combinaison est la même dans tous les navigateurs : la touche Contrôle et la touche U, ou Commande et U sur un Mac. Le code s'ouvre dans un onglet. Vous n'avez pas besoin de le comprendre, seulement d'y chercher des mots avec la fonction de recherche du navigateur.

1. La page est-elle seulement indexable ?

Cherchez la chaîne name="robots" dans le code source. Si vous y trouvez le mot noindex sur une page qui devrait être trouvée, arrêtez tout : rien d'autre n'a d'importance tant que ce mot est là. Cherchez ensuite l'origine. Trois candidats, dans cet ordre : la case de l'écran Réglages de lecture décrite plus haut, un réglage de votre extension de référencement qui exclut tout un type de contenu, ou une case cochée par erreur dans l'encadré de cette page précise au moment de la rédaction.

Faites le même contrôle sur une page d'archive, une page de catégorie et la page d'accueil. Il arrive fréquemment que les articles soient indexables et que les catégories ne le soient pas, ou l'inverse, sans que personne ne l'ait décidé consciemment : le réglage vient du thème ou d'une extension installée il y a trois ans.

2. Le titre de la page

Cherchez la balise title dans le code source, et lisez-la comme si vous la voyiez dans une page de résultats. Trois défauts reviennent constamment sur WordPress. Le premier : le titre commence par le nom du site, si bien que vos vingt premières pages commencent toutes par les mêmes quinze caractères et que la partie utile est repoussée hors de l'affichage. Le deuxième : le titre est identique sur plusieurs pages, ce qui arrive dès qu'un modèle le fabrique à partir d'un champ vide. Le troisième : le titre est correct mais il ne contient pas les mots que les gens tapent réellement, parce qu'il a été écrit comme un titre de couverture de magazine.

Le contrôle rapide consiste à ouvrir cinq pages de familles différentes — un article, une page de service, une catégorie, une étiquette, la page d'accueil — et à comparer leurs cinq titres côte à côte. Si deux sont identiques, vous venez de trouver une erreur de gabarit, pas une erreur de page.

3. La description

Cherchez name="description". Son absence n'est pas une faute grave : le moteur fabrique alors sa propre description à partir du texte, et il s'en tire souvent très bien. En revanche, une description reprise mot pour mot du premier paragraphe est une occasion perdue, et une description identique sur cinquante pages est le signe d'un modèle mal réglé.

Écrivez-en une seulement pour les pages qui comptent : celles qui reçoivent des impressions dans votre rapport de performances. Pour les autres, laissez faire le moteur. Passer trois heures à rédiger des descriptions pour des pages que personne ne voit dans les résultats est le prototype du travail d'audit qui n'a jamais rien changé.

4. Le H1

Cherchez la balise h1 et comptez les occurrences. Zéro H1 arrive quand un thème choisit d'afficher le titre dans une balise de niveau inférieur pour des raisons de mise en page. Deux H1 arrivent quand le logo du site est lui aussi dans un H1, ce qui était courant dans les thèmes d'une certaine génération. Un H1 qui contient uniquement le nom du site est la version la plus ennuyeuse du problème : le premier titre de la page ne dit pas de quoi parle la page.

Ce contrôle est typiquement un contrôle de gabarit. Si le H1 est mal réglé sur un article, il l'est sur tous vos articles. Vérifiez-le une fois par famille de page et corrigez au modèle.

5. L'adresse de la page

Lisez l'adresse à voix haute, sans regarder la page. Est-ce qu'une personne comprend le sujet ? La documentation francophone de WordPress rappelle sur la page « Écran Réglages des permaliens » que la structure par défaut est la structure dite Simple, de la forme point d'interrogation p égale un numéro, et que l'adresse d'une publication doit être permanente et ne jamais changer. Ces deux phrases contiennent tout le sujet : choisissez une structure lisible dès le premier jour, puis n'y touchez plus.

Le piège vient plus tard. Deux ans après, quelqu'un trouve que les adresses contenant une date font vieillot, et modifie la structure. WordPress accepte sans broncher, toutes les anciennes adresses cessent de répondre, les liens que d'autres sites vous avaient faits pointent dans le vide, et le rapport d'indexation se remplit de pages introuvables. Si vous devez vraiment changer, préparez d'abord la table de correspondance entre anciennes et nouvelles adresses, et mettez les redirections en place le même jour.

6. L'adresse canonique

Cherchez rel="canonical" et comparez la valeur avec l'adresse affichée dans la barre du navigateur. Elles doivent coïncider. Deux anomalies fréquentes sur WordPress : toutes les pages déclarent la page d'accueil comme adresse canonique, ce qui revient à dire au moteur que seule la page d'accueil existe ; ou bien deux balises canoniques cohabitent dans le même code source, chacune posée par une extension différente, et le moteur choisit celle qu'il veut.

Ce deuxième cas nous amène directement à la section suivante, parce qu'il n'a pas de sens ailleurs que sur cette plateforme : sur un site fabriqué à la main, personne n'installe deux fois le même mécanisme sans s'en apercevoir.

7. Les images

Cherchez alt= dans le code source et regardez combien d'attributs sont vides. Puis regardez le poids réel des fichiers servis. Une image de couverture de plusieurs mégaoctets est un problème de vitesse avant d'être un problème de référencement, et elle est extrêmement fréquente sur WordPress pour une raison mécanique que nous détaillons plus bas : le téléversement fabrique plusieurs formats, mais il ne compresse pas votre fichier d'origine à votre place.

Pour le texte alternatif, une règle suffit : décrivez ce que montre l'image à quelqu'un qui ne la voit pas. N'y recopiez pas votre mot clé. Une image décorative peut légitimement porter un attribut vide, et c'est même préférable à une description inventée.

8. Les liens que la page reçoit

Une page vers laquelle aucune autre page ne pointe est une page orpheline. Elle existe, elle est peut-être excellente, et elle vit seule. Le contrôle le plus rapide ne demande aucun outil : utilisez le champ de recherche de votre propre site pour chercher le sujet de la page, et regardez si d'autres contenus abordent le même thème sans pointer vers elle. Vous trouverez presque toujours deux ou trois occasions de lien évidentes, écrites il y a des mois, qui n'attendaient que vous.

Ce contrôle est celui qui rapporte le plus pour l'effort demandé, et c'est aussi celui que les audits techniques rangent en bas de liste. Ajouter cinq liens internes pertinents depuis des pages qui reçoivent déjà des visites vaut mieux que réécrire douze descriptions.

9. Le contenu réellement utile

Dernier contrôle, et le plus inconfortable. Retirez par la pensée le menu, le pied de page, la barre latérale, les blocs d'articles suggérés, le formulaire d'inscription et le bandeau de consentement. Que reste-t-il ? Sur beaucoup de pages de catégorie ou d'étiquette, il reste trois lignes de texte et une liste de titres. Ce n'est pas une faute morale, c'est simplement une page qui n'a pas grand-chose à offrir à quelqu'un venu de la recherche.

Trois issues possibles, et il faut en choisir une : enrichir la page pour qu'elle mérite sa place, la fusionner avec une autre qui traite du même sujet, ou la retirer des pages destinées à être trouvées tout en la gardant pour la navigation interne. Ne rien décider est la quatrième issue, et c'est celle que choisissent la plupart des sites, ce qui explique la taille de leur plan de site.

Ce qui n'arrive que sur WordPress

Les neuf contrôles précédents valent pour n'importe quel site. Cette section-ci ne vaut que pour le vôtre. Elle rassemble six situations qui n'existent pratiquement pas ailleurs, non pas parce que WordPress serait mal fait, mais parce qu'il est extensible : chaque extension ajoute son mécanisme sans savoir ce que font les autres, et parce que ses réglages par défaut ont été choisis à une époque où le sujet ne se posait pas de la même manière.

Deux extensions de référencement installées en même temps

C'est la première chose à vérifier sur un site que vous reprenez. Le scénario habituel : le thème acheté embarque sa propre gestion des balises, quelqu'un a installé une extension dédiée par-dessus, et personne n'a désactivé la première. Résultat, deux mécanismes fabriquent chacun leur balise titre et leur balise canonique. Le code source contient les deux, et rien dans l'administration ne vous prévient.

Le contrôle : ouvrez le code source d'un article et cherchez title, puis canonical. Si vous trouvez deux fois la même famille de balise, vous tenez le problème. La correction demande un peu de méthode : identifiez laquelle des deux contient vos réglages réels, désactivez l'autre, puis relisez dix pages représentatives avant de refermer. Ne désactivez jamais les deux d'un coup en vous disant que vous choisirez ensuite ; vous perdrez les réglages saisis à la main sur vos pages importantes.

Deux plans de site

Depuis plusieurs versions, WordPress génère seul un plan de site, sans qu'aucune extension soit nécessaire. La plupart des extensions de référencement en génèrent un aussi, avec leurs propres règles d'exclusion. Vous vous retrouvez donc avec deux plans de site accessibles, dont le contenu diffère : l'un liste des pages que l'autre a volontairement écartées.

Le contrôle : essayez les deux adresses habituelles de plan de site sur votre domaine et voyez si les deux répondent. Comparez ensuite le nombre d'adresses. La documentation francophone de WordPress signale par ailleurs un effet de bord utile à connaître : quand vous cochez la case demandant aux moteurs de ne pas indexer le site, la ligne indiquant l'adresse du plan de site généré par WordPress disparaît du fichier robots.txt. Autrement dit, le contenu de ce fichier vous renseigne sur l'état du réglage d'indexation.

La correction : n'en gardez qu'un, celui dont vous maîtrisez les règles, et ne déclarez que celui-là. Un moteur qui reçoit deux listes contradictoires ne fait pas la moyenne ; il explore les deux et vous fait dépenser du budget d'exploration sur des adresses que vous ne vouliez pas montrer.

Les archives et la pagination, le vrai gisement de pages inutiles

C'est le point le plus sous-estimé de tout l'article. Sur une installation standard, chaque article que vous publiez crée bien plus qu'une page. Il alimente une page de catégorie, une ou plusieurs pages d'étiquette, une archive d'auteur, une archive de date, et il pousse d'un cran la pagination de chacune de ces listes. Publiez deux cents articles avec des étiquettes généreuses, et votre site expose plusieurs milliers d'adresses pour deux cents contenus réels.

Le contrôle : ouvrez votre plan de site et comparez le nombre total d'adresses au nombre de contenus que vous avez réellement écrits. Un écart d'un facteur dix est le signal. Regardez ensuite la composition : combien d'étiquettes ne portent qu'un seul article, combien d'archives d'auteur pour un site tenu par une seule personne, combien de pages de date que personne ne consultera jamais.

La correction se fait par familles, pas par pages. Gardez les catégories, parce qu'elles structurent le site et qu'un visiteur s'en sert. Fermez les archives d'auteur si le site n'a qu'un auteur, fermez les archives de date si vous ne publiez pas d'actualité datée, et faites le ménage dans les étiquettes en supprimant celles qui ne portent qu'un ou deux articles. Ce n'est pas de la suppression de contenu : aucun de vos textes ne disparaît, seules disparaissent des listes automatiques qui n'apportaient rien.

Les pages de pièce jointe

Chaque fichier que vous téléversez dans la médiathèque reçoit sa propre page sur le site, distincte du fichier lui-même. Cette page contient l'image, un titre, et à peu près rien d'autre. Sur un site de deux cents articles illustrés, cela fait des centaines d'adresses au contenu quasi vide, exposées à l'exploration.

Le contrôle : cliquez sur une image dans un de vos articles, ou copiez l'adresse d'une image depuis la médiathèque. Si l'adresse ouvre une page de votre site, avec votre menu et votre pied de page, au lieu d'afficher le fichier seul, ces pages existent chez vous. La correction se fait en une fois, dans les réglages de l'extension de référencement qui gère ce cas, en renvoyant ces pages vers le contenu qui contient l'image.

Une image téléversée, huit fichiers créés

Ce mécanisme est documenté noir sur blanc. La page « Écran Réglages des médias » de la documentation francophone de WordPress explique que le téléversement d'une image de 4000 par 3000 pixels crée les fichiers suivants : 150 par 150 pour la miniature, 300 par 225 pour la taille moyenne, 768 par 576 pour la taille moyenne large destinée aux téléphones et tablettes, 1024 par 768 pour la grande taille, 1536 par 1152 qui vaut deux fois la moyenne large, 2048 par 1536 qui vaut deux fois la grande taille, l'original en 4000 par 3000, et un fichier suffixé « -scaled » de 2560 par 1920. Huit fichiers pour un seul téléversement.

Ce comportement est utile : il permet de servir une petite image sur un téléphone et une grande sur un écran large. Mais il produit deux effets qu'il faut connaître. D'abord, la médiathèque grossit très vite, et une sauvegarde qui prenait deux minutes en prend vingt. Ensuite, et surtout, WordPress redimensionne mais ne compresse pas à votre place le fichier que vous lui donnez : si vous téléversez une photographie de huit mégaoctets sortie d'un appareil, la version « -scaled » reste lourde, et c'est souvent elle qui se retrouve en couverture d'article.

Ce que vous faites	Ce qui se passe réellement	Ce que vous voyez ensuite
Vous téléversez la photo telle qu'elle sort de l'appareil	Huit fichiers sont créés, dont plusieurs restent très lourds faute de compression	Une page de service qui met quatre secondes à afficher son image principale
Vous installez une extension de compression après coup	Elle traite ce qui existe déjà, mais chaque nouveau téléversement repose le problème	Un gain visible une fois, puis une lente dégradation sur six mois
Vous redimensionnez et compressez avant de téléverser	Les huit fichiers sont fabriqués à partir d'un original déjà raisonnable	Une médiathèque qui reste petite et des pages qui s'affichent vite sans rien d'autre à faire
Vous réutilisez la même image sur dix pages	Un seul jeu de fichiers, servi dix fois, et la mise en cache travaille pour vous	Aucun coût supplémentaire, contrairement à dix téléversements de la même photo

La règle pratique tient en une phrase : redimensionnez et compressez avant de téléverser, pas après. Une image de couverture d'article n'a presque jamais besoin de dépasser deux mille pixels de large, et un fichier de deux cents kilo-octets est déjà confortable pour un grand écran.

Les permaliens qu'on refait « pour faire propre »

Le sixième point n'est pas un défaut du système, c'est une tentation humaine. Un jour, le site paraît mal rangé. Quelqu'un ouvre l'écran des permaliens et change la structure. WordPress applique le changement immédiatement, sans avertissement, et toutes les anciennes adresses cessent de répondre.

Le contrôle est indirect : si votre rapport d'indexation se remplit soudainement de pages introuvables sans que vous ayez supprimé quoi que ce soit, cherchez de ce côté. La correction est une table de redirections. La prévention est plus simple : décider la structure au premier jour, l'écrire quelque part, et considérer le sujet comme clos. La documentation officielle est très claire sur ce point, et c'est l'un des rares endroits où elle donne un conseil aussi ferme.

Les signaux web essentiels : où lire les chiffres, quoi corriger d'abord

La vitesse est le sujet sur lequel on dépense le plus d'énergie pour le moins de résultat, essentiellement parce qu'on regarde le mauvais chiffre. Commençons donc par le bon endroit : le rapport dédié dans la Search Console, qui repose sur des mesures d'usage réel, et non sur un test lancé depuis votre bureau.

Les trois signaux et leurs seuils publiés

La page d'aide « Rapport Core Web Vitals » de la Search Console donne les plages de performances pour chacun des trois signaux, en trois états : Bon, Amélioration nécessaire, Médiocre. Pour le LCP, le temps d'affichage du plus grand élément visible : moins de 2,5 secondes, jusqu'à 4 secondes, au-delà de 4 secondes. Pour l'INP, qui mesure le délai entre le geste de la personne et la réponse visible : jusqu'à 200 millisecondes, jusqu'à 500 millisecondes, au-delà. Pour le CLS, qui mesure le déplacement des blocs pendant le chargement : jusqu'à 0,1, jusqu'à 0,25, au-delà.

Deux règles de lecture accompagnent ces seuils sur la même page, et elles comptent autant que les chiffres. La première : la mesure porte sur les vingt-huit derniers jours et le seuil est considéré comme atteint quand 75 % des chargements de la page y arrivent. Vous ne visez donc pas une moyenne, vous visez trois quarts des visites, ce qui est beaucoup plus exigeant et beaucoup plus juste. La seconde : le rapport regroupe les adresses par similarité et n'affiche qu'un échantillon — le tableau d'exemples ne peut d'ailleurs contenir que 200 lignes. Ce regroupement est exactement le niveau du gabarit dont nous parlions au début : le rapport vous dit « ce modèle de page est lent », pas « cette page-là est lente ».

Dernier point de méthode, publié sur la même page : quand vous déclarez un problème corrigé, une session de surveillance de vingt-huit jours s'ouvre, et le problème n'est considéré comme résolu que si aucune adresse ne le présente plus pendant toute cette période. Concrètement, vous ne saurez pas demain si votre correction a fonctionné. Prévoyez-le, sinon vous allez modifier trois autres choses entre-temps et vous ne saurez jamais laquelle a produit l'effet.

Les causes typiques sur WordPress, dans l'ordre

Le LCP est presque toujours une image. Sur un site WordPress, c'est l'image mise en avant de l'article ou la grande image de la section d'en-tête, servie dans un format bien plus large que l'espace où elle s'affiche. Deuxième cause, plus rare mais coûteuse : un thème qui charge quatre familles de police pour en utiliser deux. Troisième cause : un hébergement mutualisé qui met une seconde entière à produire la page avant même que le navigateur ait commencé son travail.

L'INP est presque toujours une histoire d'extensions. Chaque extension charge son propre code, et beaucoup le chargent sur toutes les pages, y compris là où elles ne servent à rien : le code d'un formulaire de contact s'exécute sur vos articles, celui d'une galerie s'exécute sur votre page de mentions légales. Le symptôme est reconnaissable : la page s'affiche vite, mais le premier clic ne répond pas tout de suite.

Le CLS est presque toujours le bandeau de consentement, ou une image sans dimensions déclarées. Le bandeau s'insère après le début de l'affichage et pousse tout le contenu vers le bas ; l'image sans largeur ni hauteur écrites laisse un espace de zéro pixel puis s'ouvre d'un coup. Les deux se corrigent avec le même principe : réserver la place à l'avance.

La méthode qui économise le plus de temps

Ne corrigez qu'un signal à la fois, sur un seul gabarit à la fois, puis attendez la mesure. C'est frustrant, et c'est la seule façon de savoir ce qui a marché. Dans la grande majorité des cas, un seul des trois signaux est réellement en cause sur un site donné ; s'attaquer aux trois la même semaine multiplie le travail par trois et divise par trois vos chances de comprendre le résultat.

Un mot enfin sur les outils de test que l'on lance à la demande. Ils sont utiles pour diagnostiquer, parce qu'ils vous montrent quel élément précis est lent. Ils ne sont pas la référence pour juger, parce qu'ils mesurent un chargement depuis une machine qui n'est pas celle de vos visiteurs. Diagnostiquez avec eux, jugez avec les données d'usage réel. La question de savoir quels outils garder et lesquels désinstaller mérite d'ailleurs une réponse à part entière ; nous l'avons traitée dans un guide consacré aux outils qui servent vraiment au quotidien, et qui laisse volontairement de côté toute la partie WordPress puisqu'elle est ici.

Pourquoi une liste de trois cents erreurs vous empêche de corriger quoi que ce soit

Vous avez peut-être déjà vécu la scène. Une extension ou un service en ligne analyse le site et rend un rapport : trois cent quarante-deux problèmes, dont quatre-vingt-onze critiques. Le chiffre impressionne, le rapport paraît sérieux, et il ne se passe rien. Six semaines plus tard, le rapport est toujours là, le site aussi, et aucune des trois cent quarante-deux lignes n'a bougé.

Il ne s'agit pas de paresse. Il s'agit d'un défaut de conception de ces rapports, et il vaut la peine de le nommer précisément, parce que c'est ce qui permet de s'en servir quand même.

Premier défaut : la gravité affichée n'est pas votre gravité

Un outil qui classe une erreur en « critique » le fait selon une grille universelle, sans savoir laquelle de vos pages reçoit des visites. Une balise titre manquante sur une page d'étiquette que personne n'a jamais ouverte apparaîtra en rouge, exactement comme une balise titre manquante sur votre page de service principale. Le rouge ne vous dit rien de l'enjeu ; il vous dit seulement que la règle n'est pas respectée.

Votre gravité à vous se calcule autrement : elle croise le type d'erreur avec le trafic réel de la page concernée, et avec la place qu'occupe cette page dans votre activité. Une erreur mineure sur une page qui apporte des demandes de devis passe avant une erreur grave sur une archive de date.

Deuxième défaut : le rapport compte des pages, pas des causes

Nous y revenons parce que c'est le cœur du sujet. Trois cent quarante-deux problèmes, ce n'est presque jamais trois cent quarante-deux causes. C'est souvent six causes, dont l'une frappe deux cents pages. Un rapport qui ne regroupe pas par cause vous présente donc son résultat sous la forme la plus décourageante possible, et la moins actionnable.

Le premier geste à faire devant n'importe quel rapport est donc toujours le même : trier par type d'erreur, compter combien d'adresses sont concernées par chaque type, et regarder si ces adresses se ressemblent. Cinq minutes de tri transforment trois cents lignes en une liste de six chantiers, dont trois se règlent dans un réglage.

Troisième défaut : tout est présenté comme corrigeable

Une partie des lignes d'un rapport ne doit pas être corrigée. Certaines décrivent un comportement voulu : une page de connexion volontairement exclue de l'indexation, une redirection en place depuis une refonte, une page sans description parce que le moteur s'en sort mieux tout seul. D'autres décrivent des règles qui ne s'appliquent pas à votre cas.

Créez donc trois colonnes, et forcez-vous à ranger chaque type d'erreur dans l'une des trois : à corriger, à ignorer volontairement, à surveiller. La deuxième colonne est la plus importante des trois, parce qu'elle est la seule qui vous autorise à refermer le rapport avec la conscience tranquille.

L'ordre de correction : par trafic réel, pas par couleur

Voici la règle qui remplace la couleur de l'extension. Vous corrigez d'abord ce qui empêche d'être vu, ensuite ce qui touche les pages qui reçoivent déjà des visites, ensuite ce qui se répare au niveau du gabarit, et enfin le reste, si vous en avez encore envie.

Rang	Ce que vous traitez	Pourquoi ce rang	Combien de temps
1	Tout ce qui bloque l'indexation ou l'accès : noindex posé par erreur, robots.txt qui interdit trop, certificat expiré, pages introuvables en masse	Tant que la porte est fermée, aucun autre travail n'a d'effet visible	Une demi-journée au maximum, souvent quinze minutes
2	Les erreurs situées sur les pages qui reçoivent déjà des impressions et des clics	Ce sont les seules pages dont l'amélioration se voit dans le mois	Deux heures pour les dix premières pages
3	Les erreurs qui se réparent au niveau du gabarit et touchent des dizaines de pages d'un coup	Meilleur rapport entre effort et portée : une correction, cent pages	Une demi-journée avec l'aide de la personne qui gère le thème
4	Le ménage structurel : étiquettes vides, archives inutiles, pages de pièce jointe, contenus faibles à fusionner	Effet lent mais durable, et cela allège tout le reste	Deux heures par mois pendant trois mois
5	Le reste du rapport	Si vous n'avez pas trouvé le temps en quatre étapes, la cinquième n'était pas urgente	Jamais, et ce n'est pas grave

Où trouver le trafic réel sans rien installer

Le rapport de performances de la Search Console suffit. Triez vos pages par impressions, prenez les vingt premières, et vous tenez la liste des pages sur lesquelles votre travail se verra. C'est exactement le même point de départ que pour un travail de contenu : on part de ce qui existe déjà et qui a déjà une audience, plutôt que d'une page blanche. Ce principe vaut d'ailleurs bien au-delà de la technique, et il structure la façon dont on choisit quoi écrire ; nous l'avons détaillé dans un guide sur le type de contenu qui génère réellement des demandes en B2B.

Une nuance de bon sens : les impressions ne sont pas des visites, et une page qui reçoit beaucoup d'impressions en position vingt-cinq n'apporte encore rien. C'est justement pour cela qu'elle vaut le déplacement : elle est déjà connue du moteur, elle demande moins de travail qu'une page inexistante, et un gain de dix places s'y traduit immédiatement en visites.

Ce qu'il ne faut pas mettre dans un audit

Un audit n'est pas un plan de refonte. Si votre document se termine par « changer de thème », « refaire l'arborescence » et « migrer d'hébergeur », vous n'avez pas fait un audit, vous avez rédigé un devis. Ces trois décisions peuvent être justes, mais elles ne se prennent pas au terme d'un examen technique ; elles se prennent avec un budget, un calendrier et quelqu'un qui assume le risque.

Un audit n'est pas non plus un tableau de bord. Il photographie un état, il ne suit pas une évolution. Le suivi dans la durée est un autre exercice, avec ses propres indicateurs et sa propre forme ; si c'est ce que vous cherchez, la question des indicateurs qui méritent réellement un tableau a sa réponse ailleurs, et celle de la forme à donner à ce tableau selon la personne qui le lit aussi.

Le rendez-vous mensuel de quarante-cinq minutes

Un audit annuel de quarante pages ne sert à rien si personne ne le rouvre. Un examen mensuel de quarante-cinq minutes attrape les régressions pendant qu'elles sont encore petites. Voici comment répartir ces quarante-cinq minutes, dans l'ordre, sans jamais dépasser.

Minutes 1 à 10 : est-ce que la porte est toujours ouverte ?

Ouvrez le code source de trois pages de familles différentes et cherchez le mot noindex. Vérifiez que le fichier robots.txt n'a pas changé. Regardez le rapport d'indexation et comparez le nombre de pages indexées avec celui du mois dernier : une chute brutale signale presque toujours un réglage modifié, pas une sanction. Ces dix minutes sont non négociables, parce qu'elles couvrent la seule catégorie d'incident capable de tout annuler.

Minutes 11 à 20 : qu'est-ce qui a bougé dans les extensions ?

Regardez la liste des extensions actives et comparez-la mentalement avec celle du mois précédent. Une extension ajoutée entre-temps est la première suspecte devant n'importe quel changement de comportement, qu'il s'agisse de vitesse, de balises en double ou de pages qui apparaissent dans le plan de site. Profitez-en pour désactiver, puis supprimer, celles qui ne servent plus : une extension inactive continue d'occuper de la place et reste un point d'entrée.

Minutes 21 à 30 : le plan de site a-t-il grossi tout seul ?

Comparez le nombre d'adresses de votre plan de site avec le chiffre du mois dernier. Si vous avez publié quatre articles et que le plan de site a gagné soixante adresses, quelque chose fabrique des pages à votre place : des étiquettes nouvelles, un type de contenu ajouté par une extension, ou une pagination qui s'est ouverte. Cherchez la cause, pas les soixante adresses.

Minutes 31 à 40 : les dix pages qui comptent

Ouvrez le rapport de performances, prenez les dix premières pages par impressions, et passez les neuf contrôles sur celles dont la position a reculé. Dix minutes suffisent si vous vous limitez à ces pages-là, et c'est précisément l'intérêt de la limite.

Minutes 41 à 45 : écrire la ligne du mois

Notez dans un fichier unique, à la suite, ce que vous avez vu et ce que vous avez fait. Une ligne par mois. Au bout d'un an, ce fichier vaudra tous les rapports automatiques du monde, parce qu'il sera le seul document qui explique pourquoi le site est dans l'état où il est. C'est aussi le document qui vous évitera de refaire trois fois la même correction.

Si vous voulez aller plus loin sur la partie strictement technique — exploration, indexation, erreurs qui empêchent un moteur de faire son travail —, le sujet est traité en profondeur dans un article en anglais consacré au SEO technique. Et pour la conduite générale d'un audit, indépendamment de la plateforme, un article en anglais détaille ce qu'un audit vérifie et comment le mener.

Ce qu'Orova SEO fait ici, et ce qu'il ne fait pas

Cette section existe pour une raison précise : il serait facile, à la fin d'un guide comme celui-ci, de laisser croire qu'un logiciel remplace le travail décrit plus haut. Ce n'est pas le cas, et la limite mérite d'être posée noir sur blanc avant tout le reste.

Commençons par ce qui est vraiment différent. L'examen de santé d'Orova SEO note vos pages une par une. Ce n'est pas un robot d'exploration qui parcourt tout le domaine et rend une liste de trois cents lignes ; c'est une notation par page, qui vous dit sur quelle page se pose quel problème. Si vous cherchez un explorateur technique complet, du type de ceux qui simulent le passage d'un moteur sur l'intégralité d'un site, ce n'est pas ce que fait ce module, et il vaut mieux le savoir avant qu'après.

La deuxième différence est celle qui change le plus de choses au quotidien : l'optimisation en masse. Vous chargez une liste d'adresses existantes depuis un tableur, et le module travaille sur l'ensemble. C'est exactement le geste qui manque quand on sort d'un audit avec quatre-vingts pages à reprendre : le problème n'est jamais de savoir quoi corriger, il est de corriger quatre-vingts fois sans y passer trois semaines.

La troisième différence concerne la remise en ligne. Le module publie et met à jour directement dans WordPress par une cible de publication configurée une fois, ou par l'interface de programmation de votre propre site. Autrement dit, les corrections repartent d'où elles viennent, sans copier-coller article par article dans l'éditeur. Pour un site WordPress, c'est la partie la plus concrètement utile de tout ce qui précède.

Autour de ces trois points, le module se connecte à la Search Console, accepte une voix de marque que vous définissez, sait prendre Google Drive comme source documentaire, charge vos mots clés depuis un tableur, rédige, scanne et note les concurrents, et produit des rapports téléchargeables.

Voici maintenant ce qu'il ne fait pas, et il vaut mieux le lire avant de demander une démonstration. Il ne fait pas de recherche de mots clés avec volumes et difficulté : ce n'est pas un outil d'exploration de marché. Il ne fournit pas de données de liens entrants. Il n'explore pas votre site de fond en comble à la manière d'un robot technique : la notation se fait par page. Il ne modifie pas votre thème, ne touche pas au code PHP, n'optimise pas votre serveur et ne compresse pas votre médiathèque. Ce n'est ni un entrepôt de données, ni un outil de gestion de la relation client. Tout le travail décrit dans les trois premières sections de ce guide — la case d'indexation, les extensions en double, les archives, les images, les signaux web essentiels — reste un travail humain, fait dans l'administration de votre site.

Questions fréquentes

Par où commencer un audit SEO WordPress quand on n'a jamais fait cela ?

Par le code source d'une seule page importante, et par la recherche du mot noindex. Ensuite, vérifiez le nombre de pages indexées dans la Search Console et comparez-le au nombre de contenus que vous avez réellement écrits. Ces deux gestes prennent dix minutes et détectent la majorité des situations vraiment graves. Le reste peut attendre la semaine suivante.

Faut-il une extension de référencement pour auditer son site ?

Non pour auditer, oui pour corriger confortablement. Tous les contrôles décrits ici se font dans le code source affiché par le navigateur et dans la Search Console, sans rien installer. Une extension devient utile au moment d'écrire les balises, de gérer les redirections et de piloter le plan de site. Une seule extension, jamais deux.

Combien de temps prend un audit complet ?

Comptez une demi-journée pour un site de moins de cent pages, à condition de travailler par famille de pages et non page par page. Ouvrez un article, une page de service, une catégorie, une étiquette, la page d'accueil et une page de résultats de recherche interne : six pages représentatives vous donnent l'essentiel. Un site de mille pages ne demande pas dix fois plus de temps, parce que ce sont les mêmes gabarits qui se répètent.

Mon extension affiche une note de 85 sur 100. Est-ce bon ?

Cette note ne veut rien dire hors de l'extension qui la produit. Chaque éditeur applique sa propre grille, et la même page peut obtenir des notes très différentes selon l'extension installée. Ces notes sont utiles pour repérer des oublis mécaniques : description absente, titre trop long. Elles ne mesurent ni la pertinence de la page, ni ses chances d'être trouvée.

Faut-il supprimer les étiquettes et les archives d'un site WordPress ?

Ni les supprimer aveuglément, ni les garder toutes. Gardez les catégories, qui structurent le site et servent aux visiteurs. Fermez les archives d'auteur si le site n'a qu'un auteur et les archives de date si vous ne publiez pas d'actualité datée. Pour les étiquettes, appliquez une règle simple : une étiquette qui ne porte qu'un ou deux articles n'a aucune raison d'exister.

Le score de vitesse affiché par les outils de test compte-t-il pour le référencement ?

Ce qui compte est mesuré sur les visites réelles, sur vingt-huit jours, avec le seuil atteint quand trois quarts des chargements y arrivent. Les outils de test lancés à la demande servent à diagnostiquer, c'est-à-dire à savoir quel élément ralentit la page. Ils ne servent pas à juger, parce qu'ils mesurent depuis une machine qui n'est pas celle de vos visiteurs.

Que faire quand deux extensions de référencement sont installées ?

Identifiez d'abord celle qui contient vos réglages réels, en ouvrant les deux et en regardant laquelle porte des titres et des descriptions écrits à la main. Désactivez l'autre, puis relisez le code source de dix pages représentatives pour vérifier qu'il ne reste qu'une balise titre et une balise canonique. Certaines extensions proposent d'importer les réglages de leur concurrente : utilisez cette fonction avant de désactiver, jamais après.

Mon plan de site contient dix fois plus d'adresses que d'articles. Est-ce grave ?

Ce n'est pas une faute en soi, mais c'est le signe que le site expose beaucoup de pages fabriquées automatiquement. L'effet concret est un budget d'exploration dépensé sur des listes vides plutôt que sur vos contenus. Regardez la composition avant de vous inquiéter : si l'écart vient des étiquettes et des archives de date, la correction est un réglage, pas un chantier.

Faut-il refaire les adresses des articles pour qu'elles soient plus lisibles ?

Seulement si vous n'avez pas encore de trafic, ou si vous êtes prêt à installer toutes les redirections le même jour. La documentation officielle de WordPress rappelle qu'une adresse de publication doit être permanente et ne jamais changer. Un gain esthétique ne vaut jamais la perte de tous les liens que d'autres sites vous ont faits.

À faire cette semaine

Trois gestes, dans cet ordre, et rien d'autre. Premier geste, aujourd'hui : ouvrez le code source de votre page la plus importante et cherchez le mot noindex, puis la balise canonique, puis le nombre de balises titre. Cinq minutes. Si l'un des trois est anormal, vous venez de trouver quelque chose qui vaut plus que le reste de cet article.

Deuxième geste, demain : ouvrez le rapport de performances de votre Search Console, triez par impressions, notez les dix premières adresses sur une feuille. Ce sont vos pages. Tout le travail que vous ferez sur ces dix-là se verra ; tout le travail que vous ferez ailleurs attendra son tour.

Troisième geste, dans la semaine : comparez le nombre d'adresses de votre plan de site au nombre de contenus que vous avez réellement écrits. Si l'écart dépasse un facteur cinq, allez voir du côté des étiquettes et des archives, et fermez ce qui ne sert à personne. C'est la seule correction de cette liste qui améliore à la fois l'exploration, la vitesse de sauvegarde et votre propre lisibilité du site.

Posez ensuite le rendez-vous mensuel de quarante-cinq minutes dans votre agenda, avec les cinq blocs décrits plus haut. Les autres guides de cette série sont rassemblés dans nos articles, et le module évoqué dans la section précédente est présenté sur la page Orova SEO.