Audit SEO complet : savoir précisément ce qui freine votre site sur Google, et dans quel ordre le corriger

Qu'est-ce qu'un audit SEO complet, et qu'est-ce qu'il ne fait pas ?

Un audit SEO complet répond à une question simple : pourquoi ce site n'obtient-il pas, sur Google, la place que son offre mérite ? Pour y répondre, on examine le site comme le fait un moteur de recherche, page par page, puis comme le fait un client, recherche par recherche. Le résultat n'est pas une note sur 100 : c'est une liste de causes, chacune prouvée par une donnée, accompagnée de la correction à faire, de son effet attendu et de l'effort qu'elle demande.

C'est une prestation fermée. Elle commence par un cadrage, se termine par une restitution, et vous laisse un document que vous gardez. Vous pouvez ensuite appliquer le plan vous-même, le confier à votre développeur, à votre agence actuelle ou à n'importe quel prestataire, ou demander à Richard de le mettre en œuvre. L'audit n'engage à rien d'autre : c'est même son intérêt, puisqu'il vous donne de quoi juger les devis qui suivront, y compris le sien.

L'audit ne corrige rien sur le site. Les corrections, la rédaction et le suivi mensuel relèvent de l'accompagnement en référencement naturel. Il ne met pas non plus en place la présence dans les assistants d'IA, qui relève du référencement IA (GEO), ni la fiche d'établissement, qui relève du SEO local. Il signale en revanche ce qui, dans ces trois domaines, bloque aujourd'hui, et il dit lequel doit passer en premier.

Il arrive que la conclusion soit dure à entendre : le site ne mérite pas d'être réparé. Une plateforme qui interdit les redirections, un thème qui génère des centaines de pages vides ou un code que personne ne peut plus modifier coûtent plus cher à rafistoler qu'à reconstruire. L'audit le dit, chiffres de la Search Console à l'appui, et oriente alors vers une refonte avec migration. Dans la majorité des cas, il conclut plutôt à une série de corrections ciblées.

Pourquoi croiser la Search Console, un crawl complet et les journaux du serveur ?

Chaque instrument voit une partie du problème. La Search Console dit ce que Google a retenu : pages indexées, requêtes, clics, erreurs signalées. Le crawl dit ce que le site expose : toutes les adresses accessibles par les liens, leurs codes, leurs balises, leurs textes. Les journaux du serveur disent ce que les robots ont réellement demandé, jour après jour. Un audit qui n'en lit qu'un seul passe à côté des écarts entre les trois, et c'est presque toujours là que se cachent les vraies causes.

Un exemple fréquent : le crawl trouve 300 pages propres, la Search Console en indexe une poignée, et les journaux montrent que Googlebot passe surtout sur des adresses à paramètres générées par un filtre de catalogue. Le site n'est pas « pénalisé » : le robot dépense son temps ailleurs. Encore faut-il que ces visites viennent bien de Google. La documentation de Google sur la vérification de Googlebot, mise à jour le 25 mars 2026, décrit la méthode : recherche DNS inverse sur l'adresse IP, nom appartenant à googlebot.com, google.com ou googleusercontent.com, puis recherche directe qui doit redonner la même adresse.

Le rapport Statistiques sur l'exploration complète les journaux quand l'hébergeur ne les fournit pas. Il n'existe que pour une propriété de domaine ou une propriété à la racine du site, répartit les requêtes par code de réponse, type de fichier, objectif (découverte ou actualisation) et type de Googlebot, et suit l'état de l'hôte sur 90 jours. L'aide signale par exemple un problème quand le robots.txt reste indisponible pendant une journée, ou quand les erreurs de résolution DNS dépassent 5 % des requêtes d'un jour.

Le budget d'exploration, enfin, est souvent invoqué à tort. Le guide de Google sur ce sujet, mis à jour le 16 septembre 2026, vise les sites de plus d'un million de pages modifiées chaque semaine, ceux de plus de 10 000 pages modifiées chaque jour, et ceux dont beaucoup d'adresses restent « détectées, actuellement non indexées ». Pour un site de quelques centaines de pages, l'audit cherche donc ailleurs : qualité des pages, doublons, liens internes, plutôt qu'un rationnement de l'exploration.

Comment mesure-t-on la vitesse sans se tromper de chiffre ?

La confusion la plus courante oppose deux types de données. Selon la documentation de PageSpeed Insights, mise à jour le 25 juillet 2025, les données de terrain viennent du rapport d'expérience utilisateur de Chrome (CrUX) et décrivent ce qu'ont vécu de vrais visiteurs sur les 28 derniers jours ; les données de laboratoire viennent de Lighthouse, qui charge la page dans un environnement simulé. Les premières servent à décider s'il y a un problème, les secondes à trouver sa cause. Un score Lighthouse de 45 n'est pas un verdict si les visiteurs réels sont bien servis.

Quand une adresse n'a pas assez de visites, PageSpeed Insights se replie sur l'origine, c'est-à-dire sur l'ensemble du site. Le rapport Core Web Vitals de la Search Console procède autrement : il regroupe les pages qui offrent une expérience semblable, attribue à chaque groupe l'état de sa métrique la plus lente, et ignore les groupes sans données suffisantes pour le LCP et le CLS. L'audit lit donc les groupes, pas des pages isolées : corriger le gabarit d'une fiche produit règle d'un coup des centaines d'adresses.

Le choix du 75e centile n'est pas arbitraire. L'article de web.dev sur la définition des seuils, signé Bryan McQuade et Barry Pollard et mis à jour le 7 mai 2025, explique qu'il garantit une bonne expérience à la majorité des visites tout en limitant l'effet des valeurs aberrantes. Il précise aussi que les seuils sont les mêmes sur mobile et sur ordinateur, les attentes des utilisateurs ne dépendant pas de l'appareil. Pour un public qui navigue surtout sur téléphone, c'est le chiffre mobile qui guide les priorités.

Lighthouse, que la documentation de Chrome for Developers décrit comme un outil d'audit des performances, de l'accessibilité, des bonnes pratiques et du SEO, se lance depuis les outils de développement de Chrome, en ligne de commande ou par PageSpeed Insights. Ses résultats varient d'une exécution à l'autre selon le réseau et la machine : dans l'audit, chaque mesure de laboratoire est répétée plusieurs fois, sur les gabarits principaux, avec un profil mobile, et seule la tendance est retenue.

Canonicals, doublons et cannibalisation : comment l'audit démêle-t-il les pages qui se ressemblent ?

Un site produit des doublons sans le vouloir : adresses avec et sans barre finale, paramètres de suivi, versions imprimables, filtres de catalogue, pages d'étiquettes. La page de Google sur la consolidation des URL en double, mise à jour le 13 juillet 2026, classe les moyens d'indiquer la bonne version : la redirection et l'annotation rel="canonical" sont des signaux forts, la présence dans le sitemap un signal faible. Google peut retenir une autre version que celle déclarée ; l'inspection d'URL montre alors les deux.

La même page écarte deux réflexes répandus : ne pas utiliser le robots.txt pour choisir la version canonique, et ne pas poser de noindex sur une variante pour forcer ce choix, au risque de faire sortir la page de la recherche. L'audit vérifie donc que les quatre signaux disent la même chose : la balise canonique, les redirections, les liens internes et le sitemap. Quand ils se contredisent, Google tranche seul, et pas forcément en faveur de la page que vous préférez.

La cannibalisation est un cas différent : deux pages distinctes, chacune légitime, visent la même recherche. Elle se repère dans le rapport sur les performances en filtrant une requête puis en ouvrant l'onglet des pages. L'aide de la Search Console signale un piège de lecture : les données regroupées par requête sont agrégées par propriété, celles regroupées par page le sont par page. Les totaux ne concordent donc pas toujours, et l'audit raisonne requête par requête avant de conclure qu'il faut fusionner, différencier ou relier.

Comment l'audit vérifie-t-il le rendu JavaScript, les données structurées et la lisibilité par les moteurs d'IA ?

L'outil central est l'inspection d'URL de la Search Console. Sa vue par défaut décrit la dernière version indexée, pas la page actuelle ; le test en direct, lui, charge la page maintenant et affiche une capture d'écran, le HTML obtenu après exécution des scripts, les en-têtes HTTP et les ressources chargées ou bloquées. L'aide prévient qu'un résultat valide ne garantit pas l'indexation, et que le nombre d'inspections par jour et par propriété est limité. L'audit réserve donc ces tests aux gabarits représentatifs.

Pour un site bâti en Vue ou en React, la question décisive est de savoir si le texte et les liens existent avant l'exécution des scripts. Selon les principes de base du référencement JavaScript, mis à jour le 6 mars 2026, Googlebot explore, affiche puis indexe ; il peut sauter l'affichage d'une page qui ne répond pas 200 ou qui porte un noindex. Une application monopage qui répond 200 sur une adresse inexistante produit donc des soft 404. L'audit compare le HTML brut et le HTML rendu, gabarit par gabarit.

Les données structurées passent par le test des résultats enrichis, qui accepte une adresse ou un extrait de code, utilise un agent smartphone par défaut et ne couvre que les types de résultats pris en charge par Google ; les autres se contrôlent avec le validateur de schema.org. Google y précise qu'il ne garantit pas que la page s'affichera comme dans l'aperçu. L'audit relève les erreurs, les blocs en double émis par plusieurs extensions et toute information balisée qui ne serait pas visible sur la page.

La lisibilité par les moteurs d'IA s'évalue avec les mêmes preuves : robots des assistants autorisés ou refoulés, dans le robots.txt et au niveau du pare-feu, texte présent dans le HTML, identité de l'entreprise décrite sans contradiction. L'audit s'arrête au constat et à la priorité. La construction du panel de questions, la fiche d'entité et la mesure des citations sont l'objet du référencement IA (GEO).

Titres, descriptions et images : que regarde l'audit au-delà de la présence des balises ?

Qu'une balise title existe ne suffit pas ; l'audit regarde ce que Google en fait. La page sur les liens de titre, mise à jour le 18 décembre 2025, énumère les sources qu'il peut préférer à votre balise : titre principal visible, élément h1, balise og:title, texte bien en vue, ancres des liens qui pointent vers la page. Elle ajoute qu'il n'existe aucune limite de longueur, l'affichage étant seulement tronqué à la largeur de l'écran. Quand Google réécrit vos titres en série, c'est le signe d'un titre vague, répété ou bourré de mots-clés.

Pour l'extrait, la documentation sur les extraits, mise à jour le 22 avril 2026, indique que Google part d'abord du contenu de la page et n'utilise la meta description que si elle décrit mieux la page ; elle n'impose pas de longueur et recommande une description propre à chaque page, avec des informations utiles comme les horaires, le prix ou la date. L'audit compare donc les descriptions déclarées aux extraits réellement affichés sur vos recherches cibles, et repère les commandes nosnippet ou max-snippet posées par erreur.

Les images comptent à double titre : elles alourdissent les pages et elles peuvent amener du trafic par la recherche d'images. La documentation de Google sur les images, mise à jour le 3 mars 2026, demande des éléments img standards plutôt que des images posées en CSS, un texte alternatif descriptif, des noms de fichiers parlants, des images placées près du texte qui les explique, et cite les formats pris en charge, dont WebP, SVG et AVIF. Le crawl relève pour chaque image son poids, ses dimensions, son format et son texte alternatif.

Comment l'audit lit-il le profil de liens et les signaux locaux ?

Le rapport Liens de la Search Console est le point de départ : pages les plus citées, sites qui vous citent, textes d'ancrage, liens internes. L'aide prévient qu'il s'agit d'un échantillon et non d'une liste exhaustive, que ses tableaux s'arrêtent à 1 000 lignes et que certains exports montent à 100 000. L'audit en tire trois constats : quelles pages concentrent la confiance venue de l'extérieur, si ces pages sont bien reliées à vos pages de service, et si des motifs suspects apparaissent, comme des centaines d'ancres identiques venues de sites sans rapport.

Le rapport Actions manuelles dit si un examinateur de Google a sanctionné le site, par exemple pour liens artificiels, contenu de faible valeur ou texte caché. Sans action manuelle, le nettoyage des liens est rarement une priorité. L'aide sur l'outil de désaveu l'écrit : dans la plupart des cas, Google sait évaluer seul les liens dignes de confiance, et l'outil n'a pas d'utilité pour la majorité des sites. Il ne se justifie qu'avec un volume important de liens artificiels ayant provoqué, ou risquant de provoquer, une action manuelle.

Pour une activité qui reçoit des clients ou intervient dans une zone, l'audit vérifie aussi les signaux locaux portés par le site : nom, adresse et téléphone identiques partout, page de contact explicite, zones desservies écrites en texte, cohérence avec la fiche d'établissement et les annuaires. Il s'en tient à ce constat. L'optimisation de la fiche Google Business Profile, la collecte d'avis et le travail sur le bloc de cartes forment un chantier à part, décrit sur la page du SEO local et de Google Business Profile.

Connexion, journaux, données personnelles, langue : que change le contexte local pendant un audit ?

La connexion pèse d'abord sur la mesure. Un site béninois, ivoirien ou sénégalais à l'audience modeste n'a souvent pas assez de visites dans les données de Chrome pour afficher des valeurs de terrain : l'audit s'appuie alors sur des mesures de laboratoire avec un profil mobile, complétées par des chargements réels depuis un téléphone sur le réseau local. Il mesure aussi le temps de réponse du serveur depuis la région des visiteurs, car un hébergement lointain ou saturé suffit parfois à expliquer un LCP médiocre.

Les journaux du serveur contiennent des adresses IP, donc des données personnelles. Au Bénin, la loi n° 2017-20 du 20 avril 2018 portant code du numérique encadre leur traitement. L'audit ne demande qu'un extrait limité à la période utile ; les adresses des visiteurs peuvent être tronquées, seules celles qui se réclament d'un robot devant rester complètes pour la vérification DNS. La CNIL, dans sa recommandation sur la journalisation du 18 novembre 2021, rappelle que les journaux contiennent eux-mêmes des données personnelles et préconise six mois à un an de conservation pour tracer les accès des utilisateurs habilités.

En Europe, transmettre ces journaux à un auditeur fait de lui un sous-traitant au sens du RGPD. L'article 28, publié par la CNIL, demande un contrat qui fixe l'objet, la durée, la nature et la finalité du traitement ainsi que le type de données, et prévoit qu'au terme de la prestation le sous-traitant supprime les données ou les renvoie, selon le choix du client, et détruit les copies. Pour un audit, cela tient en quelques lignes du devis : extrait de journaux, usage limité au diagnostic, suppression à la remise du rapport.

Le mobile money et la langue complètent la grille. Les pages qui expliquent les moyens de paiement méritent d'être trouvées ; le panier, le compte client et les retours de paiement des agrégateurs n'ont rien à faire dans l'index, et l'audit vérifie qu'ils en sont exclus. Le rapport est rédigé en français, la facturation se fait en francs CFA ou en euros selon le pays du client, et un site bilingue fait l'objet d'un contrôle séparé de chaque langue : balises hreflang réciproques, pages anglaises relues, recherches propres à chaque marché.

Qu'a montré l'audit de richardsalanon.com, mené par Richard sur son propre site ?

À l'été 2026, la Search Console montrait qu'une petite partie seulement des pages publiées étaient indexées, et Richard envisageait de reconstruire le site sur une autre technologie. Il a d'abord appliqué sa propre grille. Les fondations techniques tenaient : balises, canonicals, données structurées et sitemap étaient en place. Les causes étaient ailleurs : un domaine jeune, peu de liens venus d'autres sites, des pages de services de quelques lignes, et des blocs de gabarit identiques sur toutes les pages, si bien que chacune n'apportait presque aucun texte propre.

La conclusion a été de ne pas reconstruire : changer de technologie aurait déplacé le problème sans le traiter. Le plan a porté sur le contenu, avec des pages moins nombreuses au départ puis approfondies, et sur une structure de données qui oblige chaque page à apporter sa propre matière. Le site a ensuite migré vers richardsalanon.com en septembre 2026, et chaque nouvelle page passe aujourd'hui un contrôle automatique qui la compare à ses voisines et la refuse si elle reprend trop de leurs passages.

Ce récit montre une démarche, pas un résultat chiffré, et aucun chiffre de progression n'est avancé ici. Il illustre deux points de méthode qui valent pour tout audit : chercher la cause avant de choisir le remède, et préférer la correction ciblée à la reconstruction quand les fondations sont saines.

Pourquoi confier l'audit SEO de votre site à Richard SALANON ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Développeur avant d'être auditeur, il lit un gabarit Laravel, une configuration de serveur ou le rendu d'une application React, et formule ses recommandations dans des termes qu'un développeur peut appliquer sans traduction. Il connaît les deux côtés du rapport : celui qui le reçoit et celui qui doit l'exécuter. C'est ce qui permet de classer chaque correction selon son effort réel, et pas seulement selon son effet théorique.

Formé à EPITECH, dont il est sorti en 2022, Richard a plus de 6 ans d'expérience dans le numérique et plus de 50 projets livrés. Il a travaillé, sur place ou à distance, pour des structures au Bénin, en Côte d'Ivoire, au Togo, au Sénégal, au Burkina Faso, au Mali, au Niger, au Tchad, au Gabon, en RD Congo, en France, en Belgique, en Suisse et au Canada. Il a créé Wapy, un assistant WhatsApp à intelligence artificielle, et il est co-fondateur d'Audyxa.

Sa façon de mener un audit suit la méthode décrite sur cette page : périmètre écrit avant le démarrage, accès en lecture seule, constats appuyés sur des données datées, rapport classé par impact et par effort, restitution orale. Il répond sous 24 heures. Votre équipe peut ensuite suivre la formation SEO et visibilité sur Google pour lire elle-même la Search Console. Son parcours complet figure sur la page Richard SALANON, et les pays couverts dans les zones d'intervention.