Audit technique SEO, la méthode pour diagnostiquer votre site

Des pages commerciales absentes de Google, un trafic organique qui baisse après une refonte, des visiteurs qui attendent avant de pouvoir utiliser une page : ces signaux peuvent justifier un audit technique SEO. Ils ne disent toutefois pas encore où se trouve le problème.

La priorité dépend des pages touchées, du blocage constaté et des preuves disponibles. Une catégorie qui génère des ventes mais porte une directive interdisant son indexation ne demande pas la même intervention qu’une ancienne URL supprimée volontairement.

Voici comment examiner votre site, interpréter les résultats des outils et construire un plan de correction.

Qu’est-ce qu’un audit technique SEO ?

Un audit technique SEO examine les éléments du site internet qui peuvent faciliter ou empêcher la découverte, l’exploration et le traitement de ses pages par les moteurs de recherche. Il porte notamment sur les liens internes, les réponses du serveur, les directives d’indexation, les balises canoniques, le rendu du contenu et les performances.

Il constitue un volet de l’audit SEO global, qui peut aussi analyser les contenus, les intentions de recherche, la concurrence et les liens entrants. Ces dimensions contribuent au référencement naturel, mais répondent à des questions différentes.

L’audit technique cherche d’abord à déterminer si les moteurs peuvent accéder aux bonnes pages et traiter correctement leur contenu. La pertinence des contenus, la demande de recherche ou la popularité du site nécessitent d’autres analyses.

Pour comprendre le rôle de la technique, distinguez quatre étapes :

• Découvrir : le moteur trouve l’URL, par exemple grâce à un lien.
• Explorer et rendre : il récupère la page et traite son contenu, notamment lorsqu’il dépend de JavaScript.
• Indexer : il décide de retenir la page dans son index.
• Classer : il détermine sa place parmi les réponses à une recherche.

Une page accessible n’est donc pas nécessairement indexée, et une page indexée n’est pas nécessairement bien positionnée. L’audit cherche les freins techniques ; il ne garantit pas une hausse de trafic.

Si les clics diminuent alors que l’indexation et les positions restent stables, examinez aussi les changements dans les résultats de recherche. Notre analyse des AI Overviews en France illustre pourquoi une baisse de clics n’établit pas automatiquement un incident technique.

Par où commencer pour auditer votre site ?

Choisir les pages qui méritent votre attention

Identifiez d’abord ce que le site doit produire : ventes, demandes de devis, prises de rendez-vous ou audience. Repérez les pages qui contribuent à ces objectifs, puis les modèles qui les génèrent. Un gabarit est le modèle commun à plusieurs fiches produits, catégories ou pages de services.

Sur un e-commerce, sélectionnez des catégories stratégiques et plusieurs fiches produits. Sur un site de services, examinez les pages d’offres, leurs points d’entrée et les formulaires associés. Ajoutez des pages récemment modifiées et quelques URL signalées comme problématiques.

Cette sélection donne un point de départ, pas une justification pour ignorer le reste. Si plusieurs pages partagent un défaut, élargissez les contrôles à leur gabarit.

Délimitez les domaines, sous-domaines et langues concernés. Notez les migrations de sites web, changements de CMS, modifications de navigation et mises en production. Cette chronologie permet de rechercher une origine possible sans transformer une coïncidence en certitude.

Réunir les données et lancer un crawl adapté

Un crawler comme Screaming Frog suit les liens et collecte les caractéristiques des URL accessibles. Avant le lancement, vérifiez le domaine de départ, les sous-domaines inclus, le mode de rendu et les règles d’exploration appliquées. Si le contenu dépend de JavaScript, un crawl limité au HTML initial peut manquer des informations.

Consignez les réglages et les limites rencontrées. Un blocage du crawler ou un crawl interrompu ne prouve pas que Google rencontre le même obstacle. La documentation de Screaming Frog détaille les réglages concernés.

Confrontez ensuite ses résultats à d’autres sources :

Source	Information utile	Limite
Crawl	Liens, réponses HTTP, directives et balises des URL analysées	Observe son propre parcours, pas celui de Google
Google Search Console	Indexation et performances de recherche	Rapports avec leurs délais et listes d’exemples limitées
Export du CMS et sitemaps XML	Inventaire complémentaire des URL	Ne prouvent pas l’indexation
Google Analytics 4	Trafic et conversions si le tracking est fiable	Ne permet pas de confirmer la présence dans l’index
Journaux serveur	Requêtes reçues, dont celles des robots identifiés	Une exploration ne prouve pas une indexation

Un outil d’audit SEO peut accélérer la collecte. La qualité du diagnostic dépend ensuite du rapprochement entre ces observations, les pages visées et le contexte du site.

Vos pages importantes sont-elles accessibles à Google ?

Vérifier les liens qui permettent de les trouver

Examinez les liens internes menant aux pages stratégiques. Sont-elles accessibles depuis la navigation, une catégorie ou un contenu pertinent ? Les liens hypertextes pointent-ils vers leur version actuelle ?

Comparez les URL découvertes par le crawl à celles du CMS et du sitemap XML. Une page présente dans l’inventaire mais absente du crawl peut être orpheline, c’est-à-dire sans lien interne dans le périmètre analysé. Vérifiez aussi qu’elle n’a pas été écartée par les réglages du crawler.

La profondeur indique le nombre de liens à suivre depuis le point de départ. Une catégorie commerciale éloignée de la navigation mérite un examen, surtout si des pages moins utiles sont beaucoup mieux reliées. Il n’existe pas de nombre de clics qui suffise, seul, à définir la bonne architecture SEO.

Contrôlez également la forme des liens : Google recommande un élément HTML <a> avec un attribut href pour découvrir les URL de manière fiable. Un bouton déclenchant seulement un script n’offre pas nécessairement le même accès.

Contrôler robots.txt, sitemaps et accès sécurisé

Le fichier robots.txt indique quelles URL les robots peuvent explorer. Vérifiez qu’il ne bloque pas des catégories, pages d’offres ou ressources nécessaires au rendu.

Bloquer une URL dans robots.txt ne garantit pas sa disparition des résultats : Google peut connaître l’adresse sans avoir accès à son contenu. Cette règle d’exploration doit être distinguée d’une directive de désindexation.

Le sitemap XML aide les moteurs à découvrir les URL signalées. Vérifiez son accessibilité, ses éventuelles erreurs et la cohérence de ses entrées avec les pages destinées à la recherche. Il ne garantit pas leur indexation.

Testez aussi l’accès en HTTPS : certificat TLS valide, couramment appelé certificat SSL, redirections entre les variantes du domaine et absence de ressources nécessaires au fonctionnement chargées par une connexion non sécurisée. Une erreur de certificat bloquant l’accès à une page de devis mérite une intervention indépendamment du nombre d’alertes SEO.

Sur les très grands sites fréquemment mis à jour, l’accumulation de paramètres ou de facettes peut justifier une analyse du budget d’exploration. Ne supposez pas ce problème sur un petit site sans élément montrant une difficulté de crawl.

Sources : robots.txt, sitemaps et budget de crawl.

Repérer les erreurs et les redirections qui posent problème

Une erreur HTTP demande une interprétation. Le contexte compte autant que le code :

Observation	Vérification et décision
Erreurs 404 ou 410	Page supprimée volontairement, ou page utile encore liée et devenue inaccessible ?
Redirections 301	Déplacement permanent cohérent ? Destination pertinente et accessible ?
Redirections 302	Déplacement temporaire intentionnel, ou configuration à revoir ?
Réponses 5xx	Incident serveur ponctuel ou récurrent ? Quelles pages et quels robots sont touchés ?
Réponse 200 avec message d’erreur	Le serveur annonce un succès, mais renvoie-t-il le contenu attendu ?

Une ancienne page sans remplacement peut normalement rester en 404. Une catégorie active renvoyant cette réponse depuis le menu pose un problème d’accès.

Après une migration, suivez chaque redirection jusqu’à sa destination finale. Réduisez les étapes inutiles et corrigez les liens internes qui continuent de pointer vers d’anciennes adresses. Ne redirigez pas automatiquement toutes les pages supprimées vers l’accueil : recherchez un équivalent lorsque celui-ci existe.

Pourquoi certaines pages restent-elles absentes de Google ?

Comprendre ce que Search Console vous indique

Dans le rapport d’indexation, repérez les motifs associés aux pages importantes, puis inspectez plusieurs URL représentatives. Les pages de tri, doublons ou contenus volontairement exclus ne doivent pas être traités comme des catégories commerciales manquantes.

Pour une page donnée, distinguez les informations enregistrées par Google du test en direct. Le premier renseigne l’état connu ; le second vérifie l’accessibilité actuelle pour les contrôles qu’il effectue. Un test réussi ne confirme pas que la version corrigée figure déjà dans l’index et ne prédit pas la canonique choisie.

Une page « explorée, actuellement non indexée » ne fournit pas, à elle seule, la cause de l’exclusion. Vérifiez l’accès, les directives, la duplication et la qualité de la page avant de prescrire une correction technique.

Vérifier les directives et le contenu dupliqué

Une directive noindex, dans le HTML ou l’en-tête HTTP X-Robots-Tag, demande de ne pas indexer la ressource. Google doit accéder à la page pour la lire : un blocage robots.txt peut l’en empêcher.

Les balises canoniques répondent à une autre question : quelle version préférer parmi des pages identiques ou très similaires ? La balise rel="canonical" est un signal, pas une garantie de sélection.

Comparez la canonique déclarée, sa destination et le choix de Google lorsqu’il est disponible. Vérifiez la cohérence avec les liens internes et les sitemaps. Ne confondez pas contenu dupliqué et pages différentes répondant à des besoins voisins : une canonical ne remplace pas une décision éditoriale.

Prenons deux exemples hypothétiques.

• Des catégories commerciales portent un noindex après une refonte. Le rapport signale leur exclusion. L’inspection, le code source et les en-têtes confirment la directive sur plusieurs catégories. La vérification du gabarit révèle une règle de test conservée après mise en ligne. Il faut corriger cette règle sur les pages visées, contrôler le déploiement puis suivre leur indexation.

• Des URL de tri affichent les mêmes produits dans un ordre différent. Elles déclarent la catégorie principale comme canonique, et Google retient cette version. L’exclusion des variantes peut être attendue. En revanche, un filtre répondant à une demande de recherche distincte nécessite un arbitrage propre.

Le nombre d’URL exclues ne suffit donc pas à définir la gravité du problème. La fonction des pages et la raison de leur exclusion déterminent l’intervention.

Google voit-il le bon contenu, et vos visiteurs peuvent-ils utiliser la page ?

Vérifier l’affichage du contenu sur ordinateur et mobile

Comparez le code source initial, le contenu affiché après exécution de JavaScript et les éléments disponibles dans l’inspection d’URL. Recherchez la description de l’offre, les produits, les informations essentielles et les liens de navigation.

L’absence d’un texte dans le HTML initial n’est pas, seule, une preuve d’inaccessibilité : Google exécute JavaScript. Mais une ressource bloquée, une erreur ou un contenu disponible seulement après une interaction demande une vérification.

Le rendu JavaScript doit aussi être examiné sur mobile. Google utilise la version mobile du contenu pour l’indexation et le classement. Vérifiez que les informations essentielles restent accessibles, même lorsque la mise en page change.

Testez enfin l’ergonomie mobile : menu, boutons, champs et formulaire. Un formulaire inutilisable peut freiner les demandes de devis sans empêcher l’indexation. Ce constat relève du parcours de conversion ; il doit être distingué d’un obstacle pour le moteur.

Contrôler les balises générées par les gabarits

Le crawl permet de repérer des balises title absentes, identiques ou incohérentes avec les pages. Vérifiez si ces observations viennent du gabarit, d’un réglage du CMS ou d’un choix éditorial.

Exemple : toutes les catégories d’une boutique affichent « Catalogue » dans leur balise title et leur H1. Avant de réécrire chaque page, vérifiez si le modèle utilise le même champ fixe. Une correction du gabarit peut résoudre la répétition ; la pertinence du titre reste ensuite une question de contenu.

Sur plusieurs pages d’un même modèle, vérifiez aussi la génération du H1 et de la structure Hn : les champs attendus sont-ils repris, et la hiérarchie reste-t-elle lisible ? Le H1 visible dans la page et la balise title sont deux éléments distincts ; Google utilise plusieurs sources pour construire le titre du résultat.

Un défaut de gabarit peut également produire la même meta description sur toutes les pages ou omettre les descriptions des images utiles. L’attribut alt aide à comprendre l’image et contribue à l’accessibilité. Contrôlez la règle de génération avant de prescrire une retouche de chaque page ; Google peut construire l’extrait du résultat à partir du contenu plutôt que de la meta description.

Ces contrôles complètent l’audit technique lorsqu’ils révèlent des défauts de génération. Ils ne transforment pas chaque champ vide en blocage d’indexation.

Analyser la vitesse au-delà du score

La vitesse de chargement participe à l’expérience utilisateur. Examinez plusieurs pages d’un même modèle pour déterminer si le problème est isolé ou partagé.

Les Core Web Vitals couvrent trois dimensions :

Indicateur	Question à examiner	Seuil considéré comme bon
LCP	Quand le contenu principal apparaît-il ?	≤ 2,5 secondes
INP	La page répond-elle rapidement aux interactions ?	≤ 200 ms
CLS	Les éléments se déplacent-ils pendant l’affichage ?	≤ 0,1

Les seuils s’évaluent au 75e percentile des observations, en distinguant mobile et ordinateur.

PageSpeed Insights présente des données terrain, lorsqu’elles sont disponibles, et des diagnostics de laboratoire produits par Lighthouse. Les premières reflètent des expériences d’utilisateurs ; les seconds simulent des conditions pour examiner des pistes. Vérifiez aussi si les données concernent l’URL ou l’origine du site.

Un temps de chargement élevé peut avoir plusieurs causes : temps de réponse du serveur, image principale tardive ou scripts retardant l’affichage. Les mesures doivent permettre de préciser la cause avant de demander de changer d’hébergement web ou de supprimer des fonctionnalités.

Le score global de Google Lighthouse ne suffit pas à arbitrer. Sur une page d’offre, cherchez aussi ce que la lenteur empêche : lire les informations, utiliser un bouton ou remplir le formulaire.

Quelles corrections traiter en premier ?

Une même alerte peut être secondaire sur une URL peu utile et importante sur un modèle de pages commerciales. Nous proposons donc une grille de lecture qui relie le constat à la décision, sans score artificiel :

Critère	Question
Page	Quel rôle joue-t-elle dans l’acquisition ou le parcours utilisateur ?
Preuve	Le problème est-il confirmé, ou reste-t-il une hypothèse ?
Portée	Touche-t-il une URL, un gabarit ou une partie entière du site ?
Conséquence	Empêche-t-il la découverte, l’indexation, la lecture ou une action utile ?
Dépendances	Quels accès, changements et ressources faut-il réunir pour corriger ?
Validation	Quel contrôle permettra de confirmer la correction ?

Les catégories commerciales bloquées par noindex demandent une intervention. Les variantes de tri correctement canonicalisées peuvent ne nécessiter aucun changement. Une amélioration de performance dépendra de l’expérience touchée, de sa portée et des contraintes de déploiement.

L’objectif est de corriger d’abord les problèmes confirmés qui touchent les pages importantes, sans attribuer à chaque anomalie une perte de trafic ou de chiffre d’affaires non démontrée.

Transformez ensuite la priorité en tâche. Voici une recommandation issue de notre exemple :

Élément	Contenu du ticket
Constat	Catégories destinées à la recherche portant un noindex
Preuve	Directive observée sur les URL jointes, avec date de contrôle
Périmètre	Gabarit catégorie ; étendue à confirmer sur les autres catégories
Conséquence	Empêche l’indexation des pages concernées lorsque Google lit la directive
Action	Corriger la règle produisant le noindex sur les catégories visées
Responsable	Équipe chargée du CMS ou du gabarit
Validation	Contrôler HTML et en-têtes sur plusieurs URL ; vérifier les pages qui doivent rester exclues
Suivi	Observer ensuite les nouvelles explorations et l’état d’indexation

L’effort, les dépendances et la date se déterminent avec l’équipe technique. Une recommandation exploitable précise un résultat vérifiable ; « améliorer le référencement SEO » n’est pas une tâche suffisante.

Comment savoir si les corrections ont fonctionné ?

Après mise en ligne, rejouez les contrôles sur les mêmes URL et sur d’autres pages du modèle. Ne clôturez pas une tâche uniquement parce qu’un correctif a été déployé.

Distinguez trois niveaux de suivi :

Niveau	Ce qu’il faut vérifier
Correction technique	La directive, le lien, la réponse ou le défaut de rendu a-t-il été corrigé ?
Traitement par Google	La nouvelle version a-t-elle été explorée ? Les informations d’indexation ont-elles évolué ?
Résultats d’acquisition	Les impressions, clics, visites et conversions des pages évoluent-ils sur une période pertinente ?

Une directive supprimée ne prouve pas une indexation immédiate. Une hausse après déploiement ne démontre pas que la correction en est l’unique cause.

Consignez les dates et comparez les pages concernées en tenant compte des autres changements, de la demande et de la saisonnalité. Cela permet de savoir si la suite relève encore de la technique ou d’un autre volet de l’audit SEO.

Élargissez les contrôles lorsque le contexte le justifie : versions linguistiques mal associées sur un site multilingue, balisage produit incohérent avec les informations visibles ou exploration excessive des facettes d’un catalogue. Vérifiez alors les éléments en cause — liens de retour hreflang, données structurées ou requêtes consignées dans les journaux serveur, plutôt que d’ajouter systématiquement tous ces chantiers à l’audit.

Un balisage valide ne garantit pas l’affichage d’un résultat enrichi.

Notre accompagnement en SEO technique présente ces champs d’intervention.