Audit SEO technique : les corrections qui influencent d'abord le classement

Un propriétaire d'entreprise lance un outil d'audit SEO technique sur son propre site.

Le rapport revient avec quarante problèmes signalés. Du JavaScript bloquant le rendu. Une balise hreflang manquante. Plusieurs images sans texte alternatif. Quelques erreurs 404.

Rien dans le rapport n'indique lesquels de ces problèmes vous coûtent réellement des positions dans les résultats, et lesquels ne sont que du bruit généré par l'outil pour donner une impression de sérieux.

Le rapport est donc parcouru en diagonale, mis en favori, et largement ignoré, faute d'un point de départ évident.

Un audit SEO technique n'a pas besoin de couvrir quarante points pour être utile. Il doit en couvrir quatre : si Google peut explorer vos pages, leur vitesse de chargement, leur affichage sur téléphone, et la validité de vos données structurées. Voici comment parcourir ces quatre domaines dans l'ordre qui influence réellement le classement, plutôt que de haut en bas sur une longue liste.

Ce que vérifie réellement un audit SEO technique

Un audit SEO technique examine la plomberie d'un site web, et non les textes qu'il contient. Il vérifie si une page peut être atteinte, lue et affichée rapidement, sur n'importe quel appareil, plutôt que de juger si le contenu de cette page est bon.

Cette distinction compte, car une page techniquement parfaite avec un contenu mince et générique ne sera toujours pas bien classée, et une page magnifiquement rédigée que Google ne peut pas explorer ne sera tout simplement pas classée. Les deux types d'audit résolvent des problèmes différents.

Les quatre domaines traités dans cet article

La plupart des éléments qui apparaissent dans un rapport d'audit technique relèvent de l'un de ces quatre groupes : l'exploration, la vitesse du site, l'affichage mobile et les données structurées. La documentation Search Essentials de Google pose simplement l'exigence de base : une page doit être techniquement accessible et affichable avant que quoi que ce soit d'autre à son sujet ne soit évalué.

Cet article parcourt ces quatre domaines dans l'ordre qui tend à compter le plus, en commençant par savoir si Google peut même atteindre vos pages, car rien d'autre dans un audit technique n'a de sens tant que ce point n'est pas réglé.

En quoi un audit technique diffère d'un audit de contenu

Un audit de contenu vérifie si une page répond à une vraie question avec assez de détails, si elle est à jour, et si c'est la bonne page pour se positionner sur une recherche donnée. Un audit technique ne s'intéresse à rien de tout cela. Il vérifie si la page se charge, si elle est bloquée, et si un téléphone peut l'afficher correctement.

Les deux audits comptent, et un site a généralement besoin des deux à un moment donné. Cet article se limite volontairement au volet technique, car c'est la partie que la plupart des petits entrepreneurs ignorent complètement ou essaient de corriger d'un coup à partir d'une liste de problèmes déroutante.

Diagramme présentant les quatre domaines de l'audit technique par ordre de priorité : exploration, vitesse du site, affichage mobile et données structurées.

Erreurs d'exploration Google Search Console : ce qui empêche Google de lire vos pages

Avant que la vitesse d'une page ou sa mise en page mobile n'ait la moindre importance, Google doit pouvoir la trouver, la demander et l'ajouter à son index. Une erreur d'exploration brise cette chaîne, et aucun point plus bas dans une liste d'audit technique ne peut la compenser.

Lire le rapport d'indexation des pages dans Search Console

Le rapport d'indexation des pages de Search Console est le moyen le plus direct de voir comment Google traite réellement vos pages, plutôt que de deviner de l'extérieur. Il regroupe vos URL par statut : indexées, ou non indexées avec un motif précis.

Des motifs comme Bloquée par le fichier robots.txt, Erreur de serveur (5xx), Erreur de redirection et Soft 404 renvoient chacun à une cause différente, et chacun demande une correction légèrement différente. Lire ce rapport une fois par mois prend quelques minutes et permet de repérer les problèmes bien avant qu'ils ne se traduisent par une baisse de trafic.

Erreurs d'exploration courantes et leurs causes

Une page bloquée provient en général d'une ligne du fichier robots.txt destinée à une autre partie du site, mais qui a accidentellement attrapé plus que prévu. Une erreur de serveur signifie en général que la page a renvoyé une réponse de type 500 lorsque Google a tenté de la charger, souvent à cause d'un problème d'hébergement ou d'extension, et non du contenu de la page.

Une erreur de redirection signifie que Google a suivi une redirection qui a mené à un endroit inattendu, souvent une boucle ou une impasse. Une soft 404 est une page qui renvoie un statut normal 200 mais dont le contenu est si mince que Google la traite comme pratiquement vide. Cela vaut la peine d'être vérifié, car cela indique parfois une page qui a réellement besoin de plus de texte.

Pourquoi une page importante bloquée passe avant toutes les autres corrections de cette liste

Un site peut avoir une excellente vitesse, une mise en page mobile irréprochable et des données schema valides sur chaque page, et rien de tout cela ne compte si la page de service principale est bloquée par erreur dans robots.txt. Une page bloquée n'est pas jugée sévèrement. Elle n'est tout simplement pas jugée du tout.

C'est pourquoi les erreurs d'exploration viennent toujours en premier dans un audit technique, avant tout ce qui concerne la vitesse ou l'affichage. Notre guide sur la façon de faire indexer votre site par Google détaille davantage cette vérification, y compris ce qu'il faut faire lorsqu'une page qui devrait être indexée ne l'est pas.

Corriger robots.txt, les sitemaps et les chaînes de redirection

Une fois que vous savez ce que vous indique le rapport d'indexation des pages, les corrections se trouvent en général à trois endroits : le fichier robots.txt, le sitemap et les redirections enchaînées sur le site.

Vérifier robots.txt pour détecter les blocages accidentels

Ouvrez directement le fichier robots.txt de votre site, généralement situé à la racine du domaine, et lisez chaque règle. Une seule ligne destinée à bloquer un dossier d'administration ou un sous-domaine de test peut accidentellement bloquer tout un répertoire de vraies pages si elle est rédigée de façon trop large.

Le Robots.txt Checker gratuit de RepGet indique clairement ce qui est bloqué pour la recherche et pour les robots d'IA, ce qui est plus rapide que de lire la syntaxe brute ligne par ligne. Notre guide sur le générateur robots.txt explique comment créer un fichier sûr à partir de zéro si le fichier existant semble nécessiter une réécriture plutôt qu'une simple retouche.

Garder le sitemap synchronisé avec les pages réelles

Un sitemap XML n'est utile que s'il liste les pages qui existent réellement et renvoient un statut 200 normal. Un sitemap qui mentionne encore des pages supprimées il y a des mois, ou qui omet des pages ajoutées depuis sa dernière génération, envoie à Google des signaux contradictoires sur ce qui est actuel sur le site.

Le Sitemap Checker & Finder gratuit de RepGet trouve et valide le sitemap d'un site, et signale les URL qui ne répondent pas comme prévu. La plupart des plateformes de sites web régénèrent automatiquement leur sitemap, mais il vaut la peine de vérifier que cela se fait réellement plutôt que de le supposer.

Repérer et corriger les chaînes de redirection

Une chaîne de redirection se produit lorsqu'une URL redirige vers une deuxième, qui redirige vers une troisième, au lieu de pointer directement vers la page finale. Chaque étape supplémentaire ajoute du temps de chargement et donne à Google un point de plus où quelque chose peut mal tourner.

Ces chaînes s'accumulent discrètement pendant des années, généralement après plusieurs refontes du site sans que personne ne nettoie les anciennes redirections laissées derrière. Pour les trouver, vérifiez vos pages les plus citées, suivez l'endroit où chaque redirection aboutit réellement, puis faites pointer directement vers leur destination finale tout ce qui comporte plus d'un saut.

Vitesse de page et Core Web Vitals : ce qui est réellement un facteur de classement

La vitesse des pages attire beaucoup d'attention dans les audits techniques, en partie parce qu'elle est mesurable, et en partie parce que les sites lents sont vraiment courants. Dans un audit de vitesse de site, ce qui vaut la peine d'être clarifié, c'est quelles mesures de vitesse Google documente réellement comme signal de classement, et lesquelles relèvent simplement de bonnes pratiques.

Les trois métriques Core Web Vitals, expliquées simplement

Les Core Web Vitals, documentés sur web.dev, mesurent trois aspects de l'expérience de chargement d'une page. Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour que le plus grand élément visible, en général une image ou un bloc de texte, apparaisse. L'Interaction to Next Paint (INP) mesure la rapidité avec laquelle la page réagit lorsqu'un visiteur clique ou appuie sur quelque chose. Le Cumulative Layout Shift (CLS) mesure si des éléments se déplacent de façon inattendue pendant que la page se charge.

Ce qui est un signal de classement documenté et ce qui relève de conseils généraux sur la vitesse

Google a documenté les Core Web Vitals comme faisant partie de ses signaux d'expérience de page. C'est différent de nombreux conseils sur la vitesse qui circulent en ligne, comme compresser chaque image à la taille de fichier la plus petite possible ou viser un score parfait de 100 sur un outil de test de vitesse, ce qui dépasse largement ce que Google mesure réellement.

Une page qui respecte les seuils Core Web Vitals a atteint le niveau documenté. Gagner encore une demi-seconde au-delà de ce niveau peut parfois valoir la peine pour les visiteurs, mais cela ne constitue pas un avantage de classement documenté par rapport à une page qui réussit déjà.

Checklist Core Web Vitals : vérifier les scores de votre propre site

Le rapport Core Web Vitals de Search Console montre comment vos pages fonctionnent réellement pour les vrais visiteurs, regroupées selon qu'elles réussissent, doivent être améliorées ou échouent pour chaque métrique. C'est une meilleure lecture de votre site qu'un test unique effectué depuis un seul endroit sur un seul appareil, car il reflète les conditions réelles auprès de vos visiteurs.

Pour une vérification rapide d'une page, un outil dédié de test de vitesse peut montrer les éléments précis qui ralentissent le site, comme une image principale trop lourde ou un script qui se charge avant le contenu qu'il affecte. Dans les deux cas, l'objectif n'est pas d'obtenir un score parfait. Il s'agit de faire passer chaque page importante au-dessus des seuils documentés.

Rendu mobile : ce que Google voit sur un téléphone et ce que vous voyez

Une page qui s'affiche bien sur un écran d'ordinateur peut se comporter très différemment sur un écran de téléphone, et pour la plupart des sites aujourd'hui, c'est la version mobile qui compte.

Pourquoi l'indexation mobile-first change ce qui compte

Google a documenté qu'il utilise principalement la version mobile du contenu d'une page pour l'indexation et le classement, une pratique qu'il appelle indexation mobile-first. Cela signifie que la version de votre page que Google examine de plus près n'est pas forcément celle que vous voyez lorsque vous consultez votre site sur un ordinateur portable.

Si une mise en page pour ordinateur masque un bloc de texte sur mobile, ou charge du contenu supplémentaire seulement après un clic que le visiteur sur téléphone ne fait jamais, la vision principale de Google sur cette page ne contient pas ce qui n'est pas arrivé jusqu'à la version mobile. Un audit technique qui ne vérifie un site que sur ordinateur examine la mauvaise version de la page.

Problèmes courants de rendu mobile sur les sites de petites entreprises

Quelques problèmes mobiles reviennent souvent sur les sites de petites entreprises. Un texte lisible sur ordinateur rétrécit à une taille inconfortable sur téléphone, obligeant les visiteurs à pincer et zoomer. Les boutons et les liens sont suffisamment rapprochés pour qu'un toucher sur l'un déclenche accidentellement un autre.

Une fenêtre pop-up plein écran qui couvre la page avant que le visiteur ait lu quoi que ce soit en est un autre fréquent, surtout sur les sites créés à partir d'un modèle qui l'active par défaut. Et un menu de navigation conçu pour la souris ne s'ouvre parfois tout simplement pas sur un écran tactile, ce qui coupe discrètement le visiteur du reste du site.

Tester la version mobile de votre site

Le test le plus direct consiste à ouvrir votre site sur un vrai téléphone, en données mobiles plutôt qu'en wifi, et à l'utiliser comme le ferait un vrai visiteur : toucher le menu, lire le paragraphe principal, essayer d'accéder à votre page de contact. Repérez tout ce qui paraît à l'étroit, caché ou non réactif.

Notre guide sur la manière d'afficher votre site web comme Googlebot présente une méthode plus technique pour vérifier ce que le robot d'exploration de Google voit réellement lorsqu'il affiche une page, ce qui va un cran plus loin que la simple vérification visuelle de la mise en page.

Données structurées et schema : ce qu'elles apportent (et ce qu'elles n'apportent pas)

Le balisage schema est l'un des éléments les plus mal compris d'un rapport d'audit technique, en partie parce qu'il paraît plus puissant qu'il ne l'est en réalité.

Ce que le schema fait réellement pour une page

Le schema est une façon normalisée d'étiqueter les informations d'une page pour qu'un programme informatique puisse les lire de manière fiable, plutôt que de les deviner à partir d'un bloc de texte ordinaire. La documentation de Google sur les données structurées explique qu'il peut rendre une page éligible à certaines fonctionnalités enrichies dans les résultats de recherche, comme les notes en étoiles ou une liste déroulante de FAQ, mais qu'il n'améliore pas directement la position de classement d'une page.

Cette distinction est importante. Une page dotée d'un schema parfait mais d'un contenu mince et générique ne dépassera pas une page sans schema qui offre un contenu réellement utile. Le schema est une couche de présentation qui repose sur un contenu qui doit déjà être bon par lui-même.

Types de schema utiles pour une petite entreprise

La plupart des petites entreprises n'ont pas besoin d'une configuration de schema étendue. Quelques types suffisent pour les situations qui se présentent réellement, et schema documente l'ensemble du vocabulaire si un type plus précis devient nécessaire.

Valider le balisage avant sa mise en ligne

Un schema mal écrit, même avec une petite erreur de syntaxe, échoue souvent sans message d'erreur évident sur la page elle-même. Un validateur vérifie que le balisage est structuré comme le vocabulaire du schema l'attend avant sa mise en ligne, ce qui permet de repérer des erreurs qui resteraient inaperçues pendant des mois.

Search Console signale aussi les erreurs de données structurées sur les pages qu'il a déjà explorées. Il vaut la peine de vérifier régulièrement, même lorsque le balisage est en ligne depuis un moment, car une mise à jour du site peut parfois le casser sans que personne ne s'en aperçoive.

Trier les problèmes techniques selon leur impact et leur effort

Maintenant que les quatre domaines ont été abordés, la question suivante est dans quel ordre travailler un vrai rapport d'audit, surtout lorsqu'il mélange des problèmes issus de plusieurs de ces catégories à la fois.

Pourquoi les problèmes d'exploration et d'indexation passent en premier

Une page bloquée ou non indexée devance tout le reste de cette liste, car rien d'autre n'a d'importance tant qu'elle n'est pas corrigée. Une amélioration de vitesse sur une page que Google ne peut pas lire est un effort perdu, tout comme l'ajout d'un schema sur une page qui ne figure même pas dans l'index.

C'est pourquoi l'ordre de cet article n'est pas arbitraire. Les erreurs d'exploration viennent en premier, car elles peuvent rendre toutes les autres corrections inutiles. La vitesse et le rendu mobile viennent ensuite, car ils concernent des pages que Google peut déjà voir et classer, simplement pas aussi bien qu'elles le pourraient. Le schema vient en dernier, car il ajoute une valeur de présentation à une page qui fonctionne déjà.

Où se placent la vitesse, le mobile et le schema ensuite

Une fois l'exploration en ordre, les problèmes de vitesse et de mobile méritent généralement la place suivante, puisque les deux sont documentés comme faisant partie de la manière dont Google évalue l'expérience de page, et qu'ils touchent chaque visiteur qui arrive sur la page, pas seulement ceux que Google explore. Le schema vient après, comme un ajout utile mais de moindre priorité.

La même réflexion effort contre impact qui s'applique à n'importe quelle liste d'audit s'applique ici aussi. Une page bloquée demande peu d'effort et a un fort impact, elle mérite donc toujours d'être corrigée en premier, quel que soit le reste de la liste. Une page lente et riche en images demande plus de travail mais reste importante. Des textes alternatifs manquants sur quelques images sont rapides à corriger mais mineurs. Et une page d'archives rarement visitée, enfouie au fond du site, ne vaut généralement pas du tout le temps qu'on y consacre.

Matrice 2x2 triant les problèmes d'audit SEO technique selon l'effort et l'impact, avec des exemples dans chaque quadrant : une page importante bloquée comme gain rapide, des pages lentes et riches en images comme projet plus important, des textes alternatifs manquants comme rapide mais mineur, et une page d'archives rarement visitée à laisser de côté pour l'instant.

Un exemple concret : auditer un petit site d'entreprise

Imaginons une petite entreprise de paysagisme qui réalise pour la première fois depuis plusieurs années un audit technique de son site. Cet exemple est illustratif.

Ce qui a changé et dans quel ordre

L'audit fait ressortir quatre problèmes couvrant les quatre domaines abordés dans cet article : une page de service bloquée par erreur dans robots.txt, une page d'accueil chargée de grandes images non compressées, un menu mobile qui ne s'ouvrait pas sur un écran tactile, et aucun balisage schema sur l'ensemble du site. En traitant ces problèmes dans l'ordre recommandé par cet article, la démarche se présente ainsi.

Ces chiffres sont donnés à titre illustratif.

La page bloquée a été corrigée en premier, puisque rien d'autre n'avait d'importance tant que Google ne pouvait pas la lire réellement. La vitesse et le mobile sont venus ensuite, car ils touchaient de vrais visiteurs et font tous deux partie de la manière dont Google documente l'expérience de page. Le schema est arrivé en dernier, ajouté une fois que tout ce qui se trouvait dessous fonctionnait déjà.

Un contrôle technique hebdomadaire de 20 minutes

Un audit technique complet n'a pas besoin d'être refait chaque semaine, mais un contrôle rapide évite que de petits problèmes ne deviennent ceux qui n'apparaissent que des mois plus tard, sous la forme d'une baisse de trafic.

Ce qu'il faut vérifier chaque semaine

Commencez par le rapport Indexation des pages dans Search Console et regardez s'il y a du nouveau dans la colonne des pages non indexées. Une page qui fonctionnait la semaine dernière et qui est bloquée ou en erreur cette semaine indique généralement un changement récent quelque part sur le site, et il est bien plus facile de le retrouver tant qu'il est encore récent.

Ensuite, jetez un œil au rapport Core Web Vitals pour repérer une mesure passée de « conforme » à « à améliorer ». Une seule image ou un seul script ajouté sans redimensionnement suffit souvent à faire basculer une page au-delà du seuil documenté, et le repérer tôt signifie une correction de cinq minutes au lieu d'une enquête plus longue plus tard. Cette vérification fait partie de toute bonne checklist Core Web Vitals.

Enfin, vérifiez les nouvelles notifications liées aux problèmes d'ergonomie mobile et les erreurs de données structurées signalées par Search Console. Les deux apparaissent souvent après une mise à jour de thème, un changement d'extension ou une refonte, même légère, et les deux sont bien plus rapides à corriger la semaine où elles apparaissent que trois mois plus tard.

À quoi ressemble un problème récurrent

Une seule page bloquée ou une image lente se corrige une fois pour toutes. Un schéma répétitif, comme trois pages différentes qui perdent leur validation de balisage schema dans le même mois, indique généralement qu'une cause en amont, un modèle, une extension ou une modification récente du site, provoque le problème à répétition, plutôt que chaque cas soit une erreur isolée et sans lien avec les autres.

Repérer ce schéma pendant un contrôle hebdomadaire, plutôt que de le découvrir lors d'un audit annuel, c'est là toute la valeur d'un contrôle court et régulier, plutôt que de le reporter jusqu'au moment où quelque chose casse de manière visible.

Les erreurs courantes d'un audit SEO technique

Quelques habitudes réduisent systématiquement la valeur d'un audit technique pourtant soigné, et la plupart viennent du fait de traiter un rapport dans le mauvais ordre ou de courir après le mauvais chiffre.

Corriger le balisage schema avant de corriger un blocage d'exploration fait partie des erreurs les plus fréquentes. Passer une après-midi à ajouter du balisage FAQ sur une page bloquée dans robots.txt signifie que ce balisage reste inutilisé tant que le blocage sous-jacent n'est pas levé, ce qui rend l'ordre des opérations plus important que la qualité du travail lui-même.

Courir après un score de vitesse parfait en est une autre. Une page qui respecte déjà ses seuils Core Web Vitals documentés ne gagne pas d'avantage supplémentaire dans le classement en gagnant un dixième de seconde de plus, même si un score de 100 sur 100 dans un outil de test peut donner l'impression que cela vaut la peine de le faire. Un audit de vitesse de site doit d'abord viser les seuils, pas la perfection.

Ne pas tester spécifiquement sur mobile, et se contenter d'une fenêtre de navigateur de bureau réduite, fait passer à côté de vrais problèmes. Une fenêtre redimensionnée ne reproduit ni un écran tactile, ni une connexion mobile plus lente, ni la façon dont le système d'exploitation d'un téléphone affiche les polices, de sorte que les problèmes qui n'apparaissent que sur un véritable appareil passent inaperçus.

Ne pas revérifier après la mise en ligne des corrections complète la liste. Une correction qui n'a pas été réellement enregistrée, ou qui a été écrasée par une modification ultérieure, peut rester défaillante pendant des mois si personne ne revient vérifier qu'elle fonctionne.

Où se situe RepGet

La plus grande partie de cet article se réalise avec Search Console et un téléphone en main, mais un premier passage sur l'ensemble d'un site va plus vite avec un outil conçu pour cela. L'audit de site gratuit de RepGet explore un site et lui attribue un score SEO de 0 à 100, en signalant les problèmes techniques à examiner ainsi que les problèmes de contenu, y compris plusieurs de ceux abordés dans cet article : la possibilité d'accéder aux pages et de les indexer, ainsi que les problèmes de base d'expérience de page. C'est un point de départ raisonnable pour voir où en est un site sur la plupart des points de cette liste en même temps. Aucun compte ni carte bancaire n'est nécessaire.

RepGet ne remplace pas les rapports Indexation des pages et Core Web Vitals de Search Console, qui s'appuient sur des données de visiteurs réels qu'une exploration ponctuelle ne peut pas voir. Il ne remplace pas non plus le jugement nécessaire pour décider quelle correction compte le plus pour votre site cette semaine, et il ne garantit ni un classement, ni une position sur Maps, ni un résultat de trafic issu d'une correction technique, aussi soigneusement qu'elle soit réalisée.

En résumé

Pour la plupart des sites de petite entreprise, un audit SEO technique ne doit couvrir que quatre points : la capacité de Google à explorer et indexer vos pages, leur vitesse de chargement, leur affichage sur téléphone et la validité de vos données structurées.

L'ordre dans lequel vous les traitez compte davantage que la prise en charge de la quarantaine de points qu'un long rapport peut signaler. Une page bloquée remet en cause tout le reste de la liste, elle passe donc en premier. La vitesse et le mobile touchent chaque visiteur réel, ils viennent ensuite. Le balisage schema apporte une valeur supplémentaire à une page qui fonctionne déjà, il vient donc en dernier. La vitesse de page reste un facteur de classement parmi d'autres, et non un objectif en soi.

Aucun audit, aussi approfondi soit-il, ne peut garantir la position d'une page dans les résultats de recherche une fois les corrections faites. Ce qu'il peut faire, c'est s'assurer que Google voit réellement la meilleure version de votre site, plutôt que de deviner à partir d'une version comportant des problèmes que personne n'a remarqués.

Découvrez d'abord ce dont votre site a besoin

Avant de parcourir une longue liste de problèmes à la main, vérifiez où en est réellement votre site. Lancez un audit de site gratuit avec RepGet pour contrôler l'exploration, l'indexation et l'expérience de base de vos pages, en plus de votre contenu. Aucun compte ni carte bancaire n'est nécessaire.