Réponse en bref
Un audit SEO technique examine l'accès au crawl, l'éligibilité à l'index, le rendu JavaScript, les signaux de page, la performance auprès de vrais visiteurs, ainsi que les doublons et versions linguistiques. Le livrable n'est pas un export d'outil, mais une liste de tâches priorisée où chaque constat porte une preuve, le modèle d'URL concerné, l'impact, l'effort, un responsable et une vérification.
Faits vérifiés
- Vérification des sources
- Les sources ont été vérifiées le 29 août 2026.
- Besoin du lecteur
- audit SEO technique pour problème d’indexation
Six couches d'examen et une seule liste priorisée
Que contient un audit SEO technique ? Six couches, dans l'ordre où un moteur de recherche rencontre une page : crawl, éligibilité à l'index, rendu JavaScript, signaux de page, performance sur de vraies visites et, enfin, URL en double et versions linguistiques. Vous devez recevoir une liste de tâches priorisée, pas un export d'outil : chaque ligne nomme le problème, montre la preuve, indique le gabarit concerné, estime impact et effort, assigne un responsable et précise comment vérifier le correctif. Un rapport qui n'y tient pas vous renvoie l'analyse.
L'ordre compte : chaque couche dépend de la précédente, et une page au mauvais code de statut ne gagne rien à un meilleur titre. L'audit précède donc un budget de contenu plus large : des articles publiés sur un site aux défauts de découverte héritent des mêmes limites.
Crawl et éligibilité à l'index en premier
La première passe vérifie si les URL censées se positionner peuvent être atteintes et rester dans l'index : codes de statut, chaînes de redirections, règles du robots.txt, sitemaps XML et maillage interne, y compris la profondeur des pages importantes et celles sans aucun lien.
Une page explorable peut rester exclue par une balise noindex, une canonique pointant ailleurs ou un soft 404, quand elle affiche « rien trouvé » alors que le serveur répond avec succès. Le rapport d'indexation de Search Console liste ces motifs avec des URL d'exemple ; plafonnées, ces listes révèlent des tendances, pas un inventaire complet.
Imaginez une boutique de 1 200 produits dont les filtres génèrent bien plus de combinaisons explorables que de produits : le constat utile n'est pas « trop d'URL », mais quelles combinaisons méritent d'être explorées et quelles pages pivots doivent pointer vers les catégories qui vendent.
Le rendu des pages construites en JavaScript
Google traite les pages JavaScript en trois phases : exploration, rendu, indexation. Les pages au code de succès patientent dans une file de rendu qui, selon Google, peut durer quelques secondes ou bien plus. L'audit compare, gabarit par gabarit, le HTML du serveur et celui obtenu après les scripts, en signalant ce qui n'existe qu'après.
Plusieurs vérifications viennent des bases du SEO JavaScript selon Google : les liens ne comptent que via des éléments a avec attribut href, donc un menu à clics peut masquer des sections entières, et un noindex d'origine peut faire sauter le rendu même si un script le retire plus tard. Les scripts ne doivent pas réécrire la canonique, et une application monopage a besoin d'une gestion d'erreurs correcte.
La preuve, ici, est une capture, pas une opinion : le HTML rendu et l'image d'un test en direct dans l'inspection d'URL ou l'outil de résultats enrichis, conservés près du constat. Un simple « rendu potentiellement problématique » sans cette capture signifie que personne n'a vérifié.
Signaux de page et Core Web Vitals réels
Les signaux de page sont les éléments du HTML qui la décrivent : titre, meta description, titres, ancres et données structurées. Ce qui compte, c'est la cohérence, pas le volume : prix et disponibilité doivent correspondre à la page visible, et les titres générés par un gabarit ne doivent pas se répéter. Ajouter des types de schéma est peu prioritaire tant que le balisage existant contredit la page.
La performance impose une distinction que beaucoup confondent : les données de terrain viennent de vrais visiteurs, via le Chrome UX Report, PageSpeed Insights et le rapport Core Web Vitals de Search Console ; celles de laboratoire, de charges simulées dans Lighthouse ou Chrome DevTools. web.dev précise que le laboratoire ne remplace pas le terrain, et que sans utilisateur réel, l'Interaction to Next Paint ne se mesure pas.
Un constat de performance solide part des données de terrain d'un groupe de pages similaires, nomme la métrique qui échoue sur mobile ou sur ordinateur, puis s'appuie sur le laboratoire pour localiser la cause, comme l'élément responsable du Largest Contentful Paint.
URL en double, canonique et versions linguistiques
Les sites génèrent des doublons sans le vouloir : paramètres de suivi, ordres de tri, barres obliques finales, variantes de protocole. Google traite redirections et rel=canonical comme des signaux forts, l'inclusion au sitemap comme un signal faible, précise qu'ils s'additionnent quand ils concordent, et déconseille robots.txt ou noindex pour choisir une canonique interne.
Être propriétaire de la canonique suppose deux décisions par groupe de doublons : quelle URL le représente, et quelle partie du système émet ce signal, champ du CMS, fonction de gabarit ou générateur de sitemap. L'inspection d'URL affiche la canonique déclarée à côté de celle choisie par Google ; en cas de divergence, le rapport nomme le signal qui l'emporte.
Les versions linguistiques appellent leur propre vérification : chacune déclare une canonique dans sa propre langue, et les jeux de hreflang doivent être complets dans toutes les directions. Imaginez un site en cinq langues où une même fonction imprime la canonique anglaise partout : le rapport nomme cette fonction une fois, sans lister chaque page touchée.
Défauts de gabarit contre défauts isolés
La plupart des défauts techniques naissent dans les gabarits : une fiche produit sans canonique, ou une catégorie qui transforme chaque filtre en lien, répète le défaut sur toutes les URL construites à partir d'elle. Des défauts isolés existent aussi, comme une boucle de redirections, mais ils expliquent rarement un motif sur tout le site.
Cela change l'échantillonnage : plutôt que de classer les alertes par nombre, l'auditeur liste les gabarits, prélève quelques URL représentatives de chacun (ancienne, récente, atypique) et les examine en détail. Ce regroupement apparaît déjà dans le rapport Search Console sur les Core Web Vitals ; l'exploration complète mesure ensuite l'étendue du défaut.
Cela change aussi la lecture du rapport. Supposons qu'une clinique ait quarante pages de services sur un même gabarit, et qu'un outil remonte deux cents alertes de titres réductibles à deux champs : comme cause unique, une tâche de développement ; comme deux cents lignes, un mois de travail qui se retrouve reporté.
La ligne que chaque constat doit remplir
Le format du rapport, point où les audits diffèrent le plus, se négocie avant que le travail ne commence : demandez les colonnes dans le brief, ou une ligne d'exemple anonymisée. Un constat sans preuve ne se revoit pas, sans responsable il ne se planifie pas, et sans vérification il ne se referme jamais.
La priorité combine l'impact du défaut, la valeur des pages concernées et l'effort du correctif. Une canonique absente sur un listing filtré et la même absence sur le gabarit de catégorie principale ne représentent pas la même priorité, même si un outil leur attribue la même gravité.
Le constat et sa preuve
Formulez le problème en une phrase qu'un développeur peut exécuter, puis joignez une preuve reproductible par quelqu'un d'extérieur à l'audit : extrait de crawl, résultat d'inspection d'URL, capture du HTML rendu, donnée de terrain ou lignes de journal serveur.
Gabarit ou modèle d'URL concerné
Nommez le gabarit, le composant ou le modèle d'URL, par exemple les fiches produit portant un paramètre de couleur, avec un décompte et des adresses d'exemple. L'équipe dimensionne ainsi le travail et confirme ensuite que tout le modèle a été corrigé.
Impact et estimation de l'effort
L'impact précise ce que le défaut bloque, découverte, indexation, sélection de la canonique ou expérience réelle, et sur quel groupe de pages. L'effort est une taille approximative convenue avec qui l'implémentera, car un changement d'infrastructure ne se compare pas à un simple ajustement.
Responsable et étape de vérification
Indiquez le rôle responsable, développeur back-end, rédacteur ou hébergeur, ainsi que la vérification qui referme la ligne : canonique attendue après rendu, code de statut, rapport Search Console à valider ou métrique de terrain à surveiller. Cette colonne double comme passation vers la mise en œuvre.
Valider que l'audit est complet avant signature
Valider un audit, c'est confirmer qu'il est complet et exact, pas long. Avant de démarrer, convenez d'un échantillon fixe d'URL : accueil, pages commerciales principales, quelques articles, une ancienne adresse redirigée, une page utilitaire comme la recherche interne et une page connue comme défaillante. Le rapport donne un verdict sur chacune, y compris « aucun problème » quand c'est honnête.
Viennent ensuite les vérifications ponctuelles : reproduisez trois ou quatre constats avec votre développeur via le test en direct, le HTML rendu, les en-têtes de réponse ou les données de terrain. Si la preuve ne se reproduit pas, le reste du rapport mérite le même doute ; chaque gabarit devrait y figurer, ne serait-ce que vérifié et sans défaut.
Une fois les premiers correctifs déployés, Search Console apporte une preuve datée : « Valider la correction », dans le rapport d'indexation, réexamine les URL connues et peut prendre plusieurs jours. C'est facultatif, puisque Google détecte aussi les correctifs en explorant normalement, mais cela laisse une trace ; une nouvelle exploration referme la boucle.
Quand un contrôle ciblé suffit, et quels accès donner
Un audit complet se justifie après une migration, une refonte, un changement de CMS ou de rendu, une importation massive de contenu, une nouvelle langue ou une chute inexpliquée de pages indexées. Après une mise en production modeste, un contrôle ciblé suffit : ré-explorer les gabarits concernés, comparer leur HTML rendu à la version précédente et confirmer codes de statut, canoniques et données structurées.
Dans tous les cas, l'auditeur a besoin d'accès, sans quoi ses constats restent des suppositions de l'extérieur : droits Search Console pour l'inspection d'URL et l'export de rapports, analytique, journaux serveur s'ils existent, emplacement des sitemaps, accès à la préproduction, liste des gabarits, familles d'URL générant du revenu et dates des dernières mises en production. Chaque élément manquant réduit ce que l'audit peut démontrer.
Checklist pratique
- Convenez d'un échantillon fixe d'URL par gabarit avant le lancement et exigez un verdict écrit pour chacune.
- Vérifiez que le rapport compare le HTML serveur et le HTML rendu pour chaque gabarit en JavaScript.
- Assurez-vous que chaque groupe de doublons nomme son URL préférée et le signal qui la désigne, redirection, canonique ou sitemap.
- Exigez que les constats de performance citent des données de terrain par groupe de pages et réservent le laboratoire aux causes.
- Refusez les lignes sans modèle d'URL concerné, sans responsable ou sans étape de vérification.
- Reproduisez vous-même trois ou quatre constats avant d'accepter le rapport comme complet.
- Donnez accès à Search Console, à l'analytique, aux journaux et à la préproduction avant le début des travaux.
- Notez les résultats de la nouvelle exploration et de la validation à côté de chaque ligne refermée.
Questions et réponses
Que contient un audit SEO technique ?
Il vérifie si les moteurs de recherche peuvent atteindre vos pages, quelles URL sont éligibles à l'index, comment se rendent les pages générées par script, si titres, liens et données structurées envoient des signaux cohérents, comment les visiteurs réels perçoivent la vitesse et la stabilité, et comment doublons et versions linguistiques sont consolidés. Le résultat est une liste de correctifs classée, avec preuve et responsable.
Que doit contenir un rapport d'audit SEO ?
Cherchez une liste de tâches priorisée plutôt que des pages de captures d'écran. Chaque ligne doit décrire le défaut, joindre une preuve reproductible, nommer le gabarit ou le modèle d'URL, estimer impact et effort, désigner un responsable et définir la vérification qui confirme le correctif. La liste des URL échantillonnées et une note sur le hors périmètre gardent le rapport exploitable des mois plus tard.
Un rapport d'outil d'audit SEO automatique suffit-il ?
C'est une matière première, pas un audit. Un outil signale des règles enfreintes sans savoir quelles pages génèrent du revenu, quels noindex sont volontaires, comme sur le panier ou le compte client, ou si des centaines d'alertes proviennent d'un seul gabarit. Il faut encore reproduire chaque problème, le confronter aux données de Search Console et décider quoi corriger en premier.
À quelle fréquence faire un audit SEO technique ?
Reliez-le à des événements, pas à un calendrier : une migration, une refonte, un nouveau CMS ou moteur de rendu, une importation massive de pages, une nouvelle langue ou une chute inexpliquée d'URL indexées. Entre ces événements, une surveillance plus légère des codes de statut, des rapports d'indexation et des données de performance de terrain suffit généralement à repérer une dérive tôt.
Un audit SEO technique inclut-il la correction des problèmes ?
Normalement non. L'audit diagnostique et classe les problèmes, tandis que les correctifs relèvent du travail d'implémentation, pour des développeurs ou une équipe de mise en œuvre SEO technique. Un audit bien construit facilite cette passation, car chaque ligne indique déjà qui doit agir et comment le résultat sera vérifié, sans nouvelle analyse.