Audit SEO technique : ce qui est vérifié et dans quel ordre

Imaginons une entreprise de taille moyenne dont le site grandit depuis dix ans. Il y a des pages de services, un blog, des archives de communiqués de presse, deux campagnes abandonnées et un catalogue de produits avec filtres. Plusieurs prestataires y ont travaillé, chacun avec ses propres habitudes. Le CMS a été changé deux fois, et lors d'aucun des changements chaque ancienne adresse n'a été redirigée proprement.

Cette situation de départ est typique, pas un cas isolé. Dans la Search Console, sous « Pages », figure une longue liste d'adresses non indexées dont les raisons sont difficiles à interpréter. En même temps, des pages de services importantes manquent dans les résultats de recherche, tandis que des combinaisons de filtres sans importance apparaissent. L'équipe soupçonne un problème de contenu, parce que le contenu est la partie visible.

Un audit SEO technique commence par une question sobre : que sait Google de ce site, et cela correspond-il à ce que l'entreprise veut proposer ? Ce n'est qu'en connaissant cet écart que l'on peut décider si le goulot d'étranglement est la technique, la structure ou le contenu. C'est exactement cette séparation que l'audit réalise, et c'est la véritable valeur de l'exercice.

Le statut « Détectée, actuellement non indexée » signifie que Google connaît l'adresse, par exemple grâce au sitemap ou à un lien, mais ne l'a pas encore demandée. Une priorisation se cache souvent derrière : Google juge la requête peu rentable sur ce site et la repousse. Avec « Explorée, actuellement non indexée », en revanche, Google a lu la page et a décidé de ne pas l'indexer.

Les deux messages se ressemblent et ont des causes différentes. Dans le premier cas, le problème se situe souvent dans la structure et les signaux, par exemple une page enfouie très profondément ou un déluge d'adresses sans valeur propre. Dans le second cas, il s'agit plutôt de la page elle-même : contenu très mince, doublons ou canonical pointant vers une autre adresse.

S'y ajoutent des schémas d'erreurs qui se superposent. Un noindex posé par inadvertance pendant la phase de développement, un robots.txt qui bloque un répertoire, des chaînes de redirections, des pages soft 404 qui renvoient le statut 200 alors qu'il n'y a rien dessus. Celui qui les corrige une à une sans respecter l'ordre corrige souvent des symptômes et laisse la cause en place.

Avant de planifier des mesures, il vous faut trois sources de données qui se recoupent. La première est la Search Console, avec le rapport d'indexation des pages, les statistiques d'exploration et les rapports de sitemap. La deuxième est une exploration réalisée par vos soins, par exemple avec Screaming Frog, qui montre ce qu'un robot trouve en suivant les liens. La troisième, ce sont les journaux du serveur, lorsqu'ils sont disponibles, car ils documentent ce que Googlebot a réellement demandé.

Chaque source a ses angles morts. L'exploration ne trouve que ce qui est lié, la Search Console fournit des échantillons et des états différés, et les journaux manquent chez de nombreux hébergeurs ou ne sont pas facilement accessibles. Lorsque deux sources se contredisent, c'est souvent le constat le plus instructif. Une page qui figure dans le sitemap mais n'apparaît pas dans l'exploration est orpheline.

Le budget d'exploration appelle une mise en perspective : pour les petits sites de quelques centaines de pages, il est rarement un goulot d'étranglement. Il devient pertinent avec de grands volumes, de nombreuses adresses générées automatiquement ou des réponses lentes du serveur. Il influence alors la rapidité avec laquelle les pages nouvelles et modifiées sont prises en compte. Les statistiques d'exploration indiquent si cela concerne votre site, et non une règle empirique.

La méthode évidente consisterait à traiter l'export de l'exploration de haut en bas. Cela égare, car la liste d'erreurs est triée par fréquence, pas par impact. Cent images sans texte alternatif pèsent moins qu'une ligne du robots.txt qui bloque le répertoire des services. L'ordre de vérification doit donc suivre la chaîne que parcourt Google : atteindre, demander, comprendre, indexer.

Nous procéderions dans cet ordre : d'abord l'accessibilité et les codes d'état, puis le pilotage par robots.txt et balises meta, ensuite canonicals et doublons, puis sitemap et maillage interne, enfin rendu et affichage. Chaque étape suppose la précédente. Un canonical propre ne sert à rien si la page ne peut même pas être demandée à cause du robots.txt.

Une alternative est l'audit par type de page : d'abord toutes les pages de services, puis le blog, puis le catalogue. Cela vaut la peine pour des sites très hétérogènes, car chaque modèle produit ses propres erreurs. Nous combinons les deux en utilisant la chaîne comme grille et en regroupant par modèles au sein de chaque étape. Une erreur dans un modèle touche en effet toutes les pages qui l'utilisent.

Les outils d'audit entièrement automatiques sont une troisième voie, et ils ont leur place : ils fournissent rapidement un état des lieux. Leur faiblesse est la pondération, car ils ne connaissent pas votre liste cible et signalent les avertissements avec la même urgence. Nous les utilisons comme source de données, pas comme verdict, et interprétons les résultats dans le contexte du site.

De la chaîne de vérification découle une grille de domaines thématiques que l'on parcourt par modèle. Elle évite que, dans l'échange avec l'équipe de développement, des constats isolés soient discutés sans lien entre eux. Elle aide aussi à répondre à la question de ce qui n'a pas été vérifié. Un audit qui nomme ses limites est plus fiable qu'un audit qui prétend à l'exhaustivité.

La grille reste volontairement technique et renonce à évaluer les textes. Les questions de contenu, par exemple si deux pages répondent à la même intention de recherche, apparaissent dans l'audit comme une indication, mais sont approfondies dans une analyse de contenu distincte. Cette délimitation garde l'audit lisible et les responsabilités claires, car la technique et l'éditorial sont souvent entre des mains différentes.

L'ordre au sein de la grille compte, pas seulement son exhaustivité. Un constat sur les codes d'état modifie ce qu'il reste à évaluer pour les canonicals et le sitemap. C'est pourquoi la grille est parcourue deux fois par modèle : une fois pour l'état des lieux, une fois après les premières corrections, afin d'exclure les erreurs induites qui n'apparaissent qu'une fois le correctif appliqué.

Tout commence par une exploration du site en ligne avec un agent utilisateur mobile, complétée par le rapprochement avec le sitemap et l'export de la Search Console. Les données brutes sont regroupées par répertoire et par modèle. On voit ainsi que 40 adresses de la même classe d'erreur remontent souvent à une seule cause, par exemple une fonction de filtre qui crée une nouvelle URL après chaque clic sur une valeur.

Nous vérifions les fichiers de pilotage avec le test robots et dans le code source. Les erreurs typiques sont un Disallow repris de l'environnement de préproduction, un noindex dans le modèle qui ne s'applique qu'à certains types de pages, ou un X-Robots-Tag que le serveur définit pour les PDF et qui touche par inadvertance des répertoires entiers. Pour les canonicals, nous contrôlons si l'adresse cible est réellement accessible, indexable et identique à celle du sitemap.

Pour le rendu, nous comparons le code source brut avec le DOM rendu et utilisons l'inspection d'URL de la Search Console pour voir ce que Google a affiché. Si la navigation ou le texte principal manquent dans le code source brut et n'apparaissent que via JavaScript, ce n'est pas automatiquement une erreur, mais c'est un risque que nous évaluons. L'essentiel est de savoir si les liens existent comme de vraies références avec href, car Googlebot ne suit pas les gestionnaires de clic.

Nous considérons le maillage interne comme un graphe. Combien de clics séparent la page d'accueil d'une page de services, quelles pages n'ont aucun lien interne entrant, et où circule le poids interne ? La règle empirique selon laquelle les contenus importants devraient être atteignables en trois ou quatre clics sert de repère, mais n'est pas une limite fixée par Google.

Les URL à paramètres sont le cas particulier le plus fréquent. Un catalogue avec tri, couleur, taille et numéro de page peut transformer cent produits en milliers d'adresses. Le choix de l'outil est un arbitrage : un canonical vers la page de base autorise l'exploration mais regroupe les signaux. Un blocage par robots.txt économise l'effort d'exploration, mais empêche Google de lire le canonical. Un noindex ne doit pas être combiné à un blocage, sinon il n'est jamais vu.

Un deuxième cas particulier est celui des chemins multiples après un changement de CMS : la même page en http et https, avec et sans www, avec et sans barre oblique finale. Ce qui compte ici, c'est une forme normale unique imposée côté serveur et une redirection qui mène à la cible en une seule étape. Les chaînes de trois sauts gaspillent des requêtes, et avec de nombreux sauts les robots abandonnent le suivi.

Troisièmement, les pages que vous laissez délibérément minces : pages de remerciement, résultats de recherche internes, versions imprimables. Elles n'ont pas leur place dans le sitemap et reçoivent généralement un noindex, mais ne doivent pas être bloquées dans le robots.txt si Google doit lire le noindex. Pour les sites multilingues s'ajoutent des relations hreflang, qui doivent être confirmées réciproquement. Ces cas particuliers expliquent pourquoi un rapport automatique ne suffit pas à lui seul.

Un quatrième cas concerne les pages derrière une connexion, des demandes de cookies ou des aiguillages par pays. Si le site redirige les robots vers une seule version en fonction de l'adresse IP ou de la langue, les autres variantes restent invisibles. Nous vérifions donc ce que renvoie une requête sans cookies et sans langue définie, car c'est exactement ainsi que Googlebot voit la page.

Un audit technique améliore les conditions de départ, pas le résultat. Si Google n'a pas indexé jusqu'ici des pages importantes parce qu'un blocage ou un mauvais canonical faisait obstacle, la correction peut conduire à leur indexation. Qu'elles se classent ensuite bien dépend du contenu, de la concurrence et de l'autorité. L'audit fait en sorte que ces facteurs puissent jouer.

L'apport se mesure avec des indicateurs proches de la cause. Il s'agit du nombre de pages indexées par rapport à la liste cible, du rapport entre pages valides et pages exclues dans le rapport d'indexation, des statistiques d'exploration avec temps de réponse et codes d'état, ainsi que de la part des adresses du sitemap réellement indexées. Les impressions, clics et positions des groupes de pages concernés ne viennent qu'ensuite.

Comptez en semaines, pas en jours. Google traite les corrections avec un décalage, et pour les pages situées en profondeur, il peut falloir plusieurs semaines avant qu'un nouvel état apparaisse. Il n'existe aucune garantie de positions ou de gains précis, et celui qui en promet vend autre chose qu'un audit. Ce qui est réaliste, c'est l'objectif de lever les obstacles et de documenter l'évolution de façon traçable.

Un exemple d'interprétation : si le nombre de pages indexées augmente alors que le nombre d'adresses du sitemap diminue, c'est bon signe, pour autant que la liste cible explique l'écart. Si le nombre de pages indexées baisse après un nettoyage, cela peut aussi être voulu, par exemple lorsque des pages de filtres sans valeur de recherche propre sortent de l'index. Les chiffres seuls disent peu tant qu'ils ne sont pas lus par rapport à la liste cible.

Un audit ne s'achève pas avec la liste des constats, mais avec un ordre de priorité. Nous classons chaque constat selon deux questions : combien de pages importantes touche-t-il, et quel est l'effort de correction ? Un noindex erroné dans le modèle touche de nombreuses pages et coûte une ligne de code : il passe tout en haut. Une restructuration complète de la navigation a un fort effet, mais mobilise des semaines et relève d'un projet à part.

Il est important de rendre les dépendances visibles. Des canonicals nettoyés et un sitemap propre devraient être livrés ensemble, sinon les signaux se contredisent temporairement. Les redirections passent avant le nouveau maillage interne, afin qu'aucun lien ne pointe vers des chaînes. Les mesures sont donc regroupées en lots qui donnent chacun un état cohérent.

Ne rien faire délibérément en fait aussi partie. Certains constats, comme l'absence de textes alternatifs sur des images décoratives ou des pages d'archives non indexées, ne sont pas un défaut, mais une décision défendable. Les documenter épargne à l'équipe des discussions futures. Une nouvelle exploration ne vaut la peine qu'après la première vague de mesures, car on peut alors vérifier si les corrections agissent comme prévu.

Les erreurs techniques naissent rarement de la négligence, mais des changements. Une mise en production remet le noindex, un nouveau plugin crée des pages d'archives, une refonte modifie les chemins. Un audit est donc un instantané. Il est judicieux d'en déduire quelques contrôles qui s'exécutent à chaque modification importante : une exploration des modèles les plus importants et un coup d'œil au rapport d'indexation.

Deux enseignements portent le plus loin. Premièrement, la liste cible et le sitemap sont le même document, sous des formes différentes, et devraient provenir de la même source. Deuxièmement, la Search Console est plutôt un système d'alerte précoce qu'un verdict. Un bloc de pages exclues qui grossit lentement révèle souvent un problème structurel des semaines avant que les positions réagissent.

L'audit a des limites. Il ne dit rien de la qualité des textes, de la force de la marque ou de la concurrence, et il ne remplace ni le travail éditorial ni le netlinking. Celui qui contrôle la technique supprime des obstacles. Celui qui veut de la visibilité doit ensuite fournir des contenus qui justifient l'indexation. Les deux vont ensemble, et l'ordre est rarement inversable.

Un audit SEO technique vaut la peine lorsque votre site s'est étoffé et que vous n'êtes plus sûr de ce que Google en retient. Il ne fournit aucune garantie de positions, mais une image fiable : quelles pages sont indexées, lesquelles devraient l'être et quelles raisons techniques se trouvent entre les deux. Cela vous épargne des mesures qui interviennent au mauvais endroit.

L'étape suivante est modeste. Ouvrez dans la Search Console le rapport d'indexation des pages et comparez le nombre de pages indexées avec le nombre de pages que vous voulez réellement voir dans l'index. Si l'écart est important ou flou, un contrôle plus précis se justifie. Nous regardons cela volontiers avec vous, avec une première exploration et une appréciation honnête de la rentabilité d'un audit complet.

Une estimation honnête de l'effort fait partie du tableau. Pour un site de quelques centaines de pages, l'analyse est faisable en quelques jours ouvrés ; pour des catalogues de dizaines de milliers d'adresses et plusieurs systèmes, elle est nettement plus lourde. Nous indiquons l'ordre de grandeur après la première exploration, pas avant.