Audit SEO technique : ce qu'il vérifie et comment le lire

Un audit SEO technique vérifie une seule chose : la capacité des moteurs à explorer, à indexer et à afficher correctement les pages d’un site. La qualité des textes et la notoriété du domaine relèvent d’autres examens. Le livrable attendu est une liste de constats datés, classés par gravité, avec les adresses concernées.

Un audit SEO technique répond à une question de lecture

Trois examens différents portent le nom d’audit en référencement, et leur confusion coûte du temps. L’audit de contenu juge les textes et les intentions visées. L’audit de popularité examine les liens reçus et leur caractère naturel. Le périmètre d’un audit SEO technique tient en trois verbes : explorer, indexer, afficher.

La question reste étroite, et c’est sa force. Un robot atteint-il les pages utiles du site ? Le moteur comprend-il quelle adresse fait référence ? La page se charge-t-elle correctement sur un téléphone ?

L’image de la bibliothèque éclaire la différence : le fonds relève du contenu, la réputation de l’établissement relève de la popularité, mais une porte fermée rend les deux inutiles.

Cette hiérarchie dicte l’ordre des travaux. Réécrire vingt pages pendant qu’une directive bloque leur exploration gaspille l’effort éditorial. Les signaux de notoriété, dont la mécanique est détaillée dans l’article consacré aux liens entrants, ne compensent jamais un blocage d’indexation.

Dernière différence : un audit technique produit des constats vérifiables, code de réponse à l’appui. Un désaccord sur la qualité d’un texte se discute, une erreur 404 non.

Exploration et indexation : ce que les moteurs atteignent vraiment

Le premier bloc de contrôles porte sur l’accès : ce que les robots parcourent, et ce que le moteur conserve. Le couple exploration et indexation se vérifie fichier par fichier.

• Le fichier robots.txt, qui autorise ou refuse le parcours des adresses.
• Les directives noindex, en balise meta ou en en-tête HTTP.
• Les balises canoniques, qui désignent l’adresse de référence d’un contenu.
• Le plan du site au format XML, et les redirections, par type et par longueur de chaîne.
• Les codes de réponse : pages introuvables, erreurs de serveur, accès refusés.
• Les pages qu’aucun lien interne ne désigne.

Directives, canoniques et redirections

Deux pièges reviennent dans la plupart des rapports. La documentation de Google Search Central écrit que le robots.txt n’est pas un mécanisme destiné à tenir une page hors de Google : une adresse interdite au parcours peut rester indexée si d’autres sites la citent, et s’afficher alors sans description. Second piège : une directive noindex agit seulement si le robot accède à la page, donc si le robots.txt ne la bloque pas.

La balise canonique mérite la même prudence : Google la présente comme un signal fort en faveur de l’adresse indiquée, pas comme un ordre, et garde la possibilité de retenir une autre version. Le contenu dupliqué naît souvent là, une même fiche joignable par trois chemins se présentant comme trois pages concurrentes. Chaque fichier de plan du site reste de son côté limité à 50 Mo non compressés ou 50 000 adresses, d’après Google Search Central en octobre 2026.

Les redirections se lisent par type : Google utilise une redirection permanente, de code 301 ou 308, comme signal de canonisation vers la cible, et ne le fait pas pour une redirection temporaire, de code 302 ou 307. Le rapport Indexation des pages de la Search Console de Google nomme ces anomalies : chaîne trop longue, boucle, erreur de serveur de type 500, soft 404.

Budget d’exploration et pages orphelines

Le budget d’exploration inquiète souvent à tort : le guide de Google sur ce sujet s’adresse aux sites d’au moins un million d’adresses mises à jour chaque semaine, ou d’au moins dix mille adresses mises à jour chaque jour. Pour les autres, la même page conseille de tenir le plan du site à jour et de suivre le rapport Indexation des pages. Les pages orphelines se détectent par recoupement entre le plan du site, un parcours automatique et les liens internes posés.

Vitesse et expérience de page : les mesures qui comptent

La vitesse de chargement ne se juge pas à l’impression laissée sur un poste de bureau raccordé à la fibre. Google publie trois mesures normalisées, les signaux web essentiels, documentées sur web.dev dans une page mise à jour en 2024.

• Le Largest Contentful Paint, LCP, rapporte le temps d’affichage du plus grand texte, de la plus grande image ou de la vidéo visible dans la fenêtre, compté depuis le début de la navigation : seuil de bonne qualité à 2,5 secondes.
• L’Interaction to Next Paint, INP, évalue la réactivité de la page en observant la latence des clics, des appuis tactiles et des interactions au clavier : seuil à 200 millisecondes.
• Le Cumulative Layout Shift, CLS, mesure la plus forte rafale de décalages de mise en page inattendus survenus pendant la vie de la page : seuil à 0,1.

Ces seuils s’apprécient au 75e centile des chargements, séparément sur mobile et sur ordinateur, toujours d’après web.dev. Les décalages de mise en page proviennent surtout d’images aux dimensions non déclarées, de polices qui remplacent une police de secours de taille différente, et de blocs tiers qui se redimensionnent après coup.

Mobile et poids des images

La compatibilité mobile se contrôle sur le contenu, pas seulement sur l’apparence. Google indexe et classe à partir de la version mobile, parcourue par son agent pour téléphone, et sa documentation demande que cette version porte le même contenu que celle destinée aux ordinateurs, titre et méta description compris. Une mise en page différente reste permise, un contenu amputé non.

Le poids des images ferme ce bloc : la documentation de Google sur les images rappelle que les illustrations constituent souvent le premier contributeur au poids total d’une page. Trois contrôles suffisent : nom de fichier court et descriptif, texte alternatif qui décrit vraiment l’illustration, variantes de taille servies selon l’écran.

Structure et balisage : ce que la page déclare

Un moteur lit une page comme un document structuré : le bloc suivant porte sur ses déclarations, celles que le visiteur ne remarque pas toujours.

Le titre de la page arrive en tête. Google rappelle qu’il génère parfois un titre de résultat différent, construit à partir des ancres de liens ou du texte visible, lorsqu’il détecte un problème sur la page. Sa recommandation tient en trois points : un texte distinct par page, descriptif, débarrassé des mots-clés empilés et des libellés vagues du type « Accueil ».

La méta description suit un régime voisin : les extraits affichés en résultat sont d’abord construits à partir du contenu de la page, et la description est retenue quand elle décrit mieux ce contenu, explique la documentation de Google. Des descriptions identiques d’une page à l’autre ne servent personne. La hiérarchie des intertitres se vérifie ensuite : un seul titre principal, des niveaux qui descendent sans saut, des intitulés qui annoncent le bloc.

Fil d’Ariane, HTTPS et maillage interne

Les données structurées entrent dans ce périmètre sans en devenir le sujet, tant leur vocabulaire mérite un examen séparé : le fil d’Ariane en donne l’exemple le plus simple, un balisage BreadcrumbList que Google Search utilise pour catégoriser l’information de la page dans les résultats.

Reste le protocole. Le chiffrement HTTPS protège l’intégrité des échanges entre le site et le navigateur, et conditionne l’accès à plusieurs fonctions récentes des navigateurs, d’après la documentation publiée par Google sur web.dev. Le contrôle porte sur la validité du certificat, la redirection de la version non chiffrée vers la version chiffrée, et les ressources encore chargées en clair. Le maillage interne ferme l’examen : les pages importantes doivent recevoir plus de liens internes que les autres.

Le livrable : lire un rapport d’audit sans être technicien

Un rapport d’audit utile ressemble moins à un mémoire qu’à un tableau de bord. Chaque anomalie y occupe une ligne, et cette ligne porte cinq informations.

• Le constat, formulé en une phrase compréhensible par un non-spécialiste.
• La preuve : liste des adresses concernées, code de réponse observé, date du relevé.
• La gravité, graduée selon l’effet attendu sur l’exploration, l’indexation ou l’affichage.
• L’effort de correction, estimé en heures ou en journées de travail.
• Le responsable : prestataire technique, rédacteur, ou éditeur du site.

La lecture croise ensuite deux colonnes, la gravité et l’effort. Les anomalies graves et faciles passent dans la semaine. Les graves et coûteuses deviennent un projet daté.

Les mineures et faciles se traitent par lots. Les mineures et coûteuses attendent, et cette attente s’écrit dans le rapport.

Trois exigences protègent le commanditaire. Réclamer la liste des pages concernées par chaque constat, car un constat sans adresses ne se corrige pas. Refuser un rapport dépourvu de priorisation des correctifs : deux cents anomalies présentées à plat produisent de la paralysie. Demander une mesure avant travaux, faute de quoi aucun effet ne sera démontrable.

Un rapport technique ne vit pas seul. Les correctifs se rangent dans le plan d’ensemble décrit dans la méthode de mise en place d’une stratégie SEO, et plusieurs constats renvoient à des décisions éditoriales : deux pages qui se disputent la même requête relèvent du travail décrit dans l’article sur les mots-clés SEO, pas d’une correction de code.

Qui réalise l’audit et à quel rythme

Deux voies existent, et elles se complètent. En interne, les rapports gratuits de Google couvrent déjà une large part du terrain : Indexation des pages pour l’accès, Signaux web essentiels pour l’expérience de page, l’outil d’inspection d’URL pour une adresse précise. Une demi-journée par trimestre tient cette veille sur un site de quelques dizaines de pages.

Un prestataire apporte autre chose : un parcours complet du site, la lecture des journaux de serveur, l’habitude des anomalies rares. La commande se formule en livrables plutôt qu’en promesses, export du parcours et priorisation comprises. Les critères de lecture d’une proposition commerciale rejoignent ceux détaillés dans le guide de création de site internet en Guyane.

Le rythme dépend de l’activité du site. Un examen complet se justifie avant et après une refonte, lors d’un changement d’outil de publication, après une migration de domaine, ou quand les impressions chutent sans raison éditoriale. Entre deux examens, une surveillance mensuelle coûte une demi-heure. Trois erreurs reviennent sans cesse.

• Corriger avant de mesurer, ce qui rend tout bilan impossible.
• Traiter toutes les anomalies la même semaine, au risque de ne plus savoir laquelle a produit l’effet.
• Oublier les pages de proximité, fiches d’établissement et pages de zone, dont les contraintes sont décrites dans le dossier consacré au référencement local.

Par où commencer cette semaine

Trois gestes tiennent dans une heure. Ouvrir la Search Console de Google, lire le rapport Indexation des pages, noter le nombre d’adresses indexées et les trois premiers motifs de non-indexation. Lister les dix pages qui comptent pour l’activité : accueil, pages de service, page de contact, meilleures fiches. Vérifier le statut de chacune avec l’outil d’inspection d’URL, que Google recommande pour connaître l’état d’indexation d’une page donnée.

Le résultat tient sur une feuille : dix lignes, un statut par ligne, et la liste des pages à remettre dans l’index avant toute nouvelle publication.