Audit technique SEO : comment auditer un site web étape par étape

En bref : un audit technique SEO consiste à vérifier tout ce qui permet à Google d’explorer, d’indexer et d’afficher correctement votre site. On passe en revue neuf points : le crawl, l’indexation, les codes HTTP, la vitesse, les Core Web Vitals, le mobile, la structure et le maillage interne, le hreflang et les données structurées. Google Search Console, PageSpeed Insights et un crawler comme Screaming Frog suffisent pour la plupart des sites. Le résultat attendu n’est pas un rapport rempli d’alertes, mais une courte liste de problèmes classés par impact.

Qu’est-ce qu’un audit technique de site web ?

L’audit technique d’un site web examine ce qui se trouve sous le contenu. Comment le serveur répond-il ? Quelles pages Google a-t-il le droit et la possibilité d’explorer ? Quelle version d’une page est considérée comme la version principale ? Les pages se chargent-elles vite et sans décalage, y compris sur mobile ? Et un moteur de recherche comprend-il la langue et le sujet de chaque page ?

La qualité des textes et l’analyse des backlinks relèvent d’autres audits, même si tout est lié. Pourquoi traiter la technique à part ? Parce qu’une page que Google ne peut ni explorer ni indexer ne compte pas, quelle que soit la qualité du texte. Et les erreurs techniques passent souvent inaperçues pour les visiteurs : une balise noindex oubliée après la mise en ligne, une redirection qui aboutit sur une 404, un sitemap rempli d’anciennes URL.

Un bon audit technique SEO produit trois choses : la liste des problèmes, les URL ou gabarits concernés pour chacun, et un ordre de traitement.

Quels outils utiliser ?

Quatre outils suffisent pour la plupart des sites, dont trois gratuits.

• Google Search Console est la seule source qui montre comment Google voit réellement votre site. Les rapports utiles ici sont Indexation des pages, Core Web Vitals, HTTPS et Sitemaps, ainsi que l’outil d’inspection d’URL. Si ce n’est pas encore configuré, commencez par notre guide de la Google Search Console.
• Un crawler comme Screaming Frog SEO Spider. Il parcourt votre site comme un moteur de recherche et affiche, pour chaque URL, le code HTTP, la balise title, la canonique, la meta robots, les liens internes et la profondeur de clic. La version gratuite explore jusqu’à 500 URL par crawl (source : Screaming Frog), ce qui suffit pour beaucoup de sites de PME. Les audits de site de Semrush ou Ahrefs font un travail comparable.
• PageSpeed Insights fournit deux types de données : des données terrain issues de vrais utilisateurs de Chrome (Chrome User Experience Report) sur les 28 derniers jours, et des données de laboratoire issues d’un chargement simulé sur un seul appareil avec un réseau fixe (Google for Developers).
• Le test des résultats enrichis de Google, pour contrôler les données structurées.

Exportez votre crawl dans un tableur avec une colonne par point de contrôle. Vous pourrez ensuite filtrer par gabarit ou par section et voir tout de suite si un problème touche une page ou cent.

Étapes 1 à 3 : crawl, indexation et codes HTTP

Étape 1 : le crawl

Lancez le crawler depuis la page d’accueil et comparez trois chiffres : le nombre d’URL trouvées par les liens, le nombre d’URL dans le sitemap et le nombre de pages indexées selon la Search Console. Les écarts sont parlants. Des pages présentes dans le sitemap mais introuvables par le crawler ne reçoivent sans doute aucun lien interne. Des milliers d’URL avec paramètres absentes du sitemap signalent un problème de contenu dupliqué.

Ouvrez ensuite le fichier robots.txt. Selon Google, il sert surtout à gérer le trafic des robots pour éviter de surcharger le serveur. Ce n’est pas un moyen de tenir une page hors de Google : une URL bloquée peut toujours apparaître dans les résultats, simplement sans description. Pour exclure réellement une page, utilisez noindex ou une protection par mot de passe (Google Search Central). Vérifiez aussi qu’aucune règle Disallow ne bloque une section importante ni les fichiers CSS et JavaScript.

Passez au sitemap XML. N’y mettez que les URL canoniques que vous voulez voir dans les résultats, sous forme d’URL absolues complètes. Un sitemap est limité à 50 000 URL ou 50 Mo non compressé. Google ignore les champs priority et changefreq et n’utilise lastmod que s’il est exact de façon constante (Google Search Central). Soumettez-le dans la Search Console ou indiquez-le avec une ligne Sitemap dans le robots.txt.

Étape 2 : l’indexation

Ouvrez le rapport Indexation des pages de la Search Console. Google y précise qu’il ne faut pas s’attendre à ce que chaque URL du site soit indexée. L’objectif est que la version canonique de chaque page importante le soit (Aide Search Console). Parcourez les raisons de non-indexation et cherchez-y vos pages importantes : pages avec une balise noindex, pages bloquées par le robots.txt, soft 404 et doublons pour lesquels Google a choisi une autre canonique que la vôtre.

Contrôlez ensuite les balises canoniques. Pour Google, une redirection permanente et un rel="canonical" sont des signaux forts, la présence dans le sitemap un signal faible. N’utilisez pas le robots.txt pour désigner une version canonique, ni noindex, qui bloque complètement la page (Google Search Central). Dans votre crawl, chaque canonique doit pointer vers la page elle-même ou vers la bonne version principale, jamais vers une redirection ou une 404. Pour vos dix pages les plus importantes, vérifiez avec l’inspection d’URL quelle canonique Google a réellement retenue.

Étape 3 : les codes HTTP

Filtrez votre crawl par code de réponse. Voici comment Google traite les principaux codes (Google Search Central) :

Googlebot suit par défaut jusqu’à dix redirections successives, mais chaque étape supplémentaire est inutile. Faites pointer vos liens internes directement vers l’URL finale, surtout après une migration. Vérifiez enfin le HTTPS : chaque page doit se charger en https, les adresses en http doivent rediriger, et aucune image ni aucun script ne doit être chargé en http. Google cite la diffusion sécurisée parmi les aspects de l’expérience sur la page et propose un rapport HTTPS dans la Search Console (Google Search Central).

Étapes 4 à 6 : vitesse, Core Web Vitals et mobile

Étape 4 : la vitesse

Ne testez pas seulement la page d’accueil. Choisissez une page représentative par gabarit, par exemple une page service, une page catégorie, une fiche produit et un article de blog, et passez-les dans PageSpeed Insights. Servez-vous des données de laboratoire pour trouver les causes et des données terrain pour savoir ce que vivent vos visiteurs. Les coupables habituels : des images trop lourdes, beaucoup de JavaScript, des scripts tiers comme les widgets de chat ou les traceurs, et un serveur lent à répondre.

Étape 5 : les Core Web Vitals

Google fixe trois seuils : un LCP sous 2,5 secondes, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, mesurés au 75e centile des chargements de page, séparément sur mobile et sur ordinateur (web.dev). Le rapport Core Web Vitals de la Search Console donne la vue d’ensemble du site. Google confirme que ses systèmes de classement utilisent les Core Web Vitals, tout en précisant que de bons scores ne garantissent pas les premières positions (Google Search Central). Pour savoir comment améliorer chaque métrique, lisez notre guide des Core Web Vitals.

Étape 6 : le mobile

Google utilise la version mobile de votre site, explorée par son robot pour smartphone, pour l’indexation et le classement (Google Search Central). Ce qui manque sur mobile ne compte donc pas. Vérifiez que la version mobile contient le même contenu principal que la version ordinateur, les mêmes données structurées et les mêmes balises meta robots. Ne chargez pas un contenu important seulement après un clic ou un appui, car Google risque de ne pas le charger. Dans votre crawler, choisissez un user-agent smartphone et comparez le résultat avec un crawl ordinateur.

Étapes 7 à 9 : structure, maillage interne, hreflang et données structurées

Étape 7 : structure et maillage interne

Google suit en général uniquement les éléments <a> dotés d’un attribut href. Les liens qui ne fonctionnent qu’avec un onclick ou une balise span sont déconseillés. Chaque page qui compte pour vous doit recevoir un lien depuis au moins une autre page du site, avec un texte d’ancre qui décrit la destination plutôt qu’un « cliquez ici » (Google Search Central).

• Pages orphelines : présentes dans le sitemap, mais sans aucun lien interne.
• Profondeur de clic : des pages importantes pour votre chiffre d’affaires accessibles seulement après de nombreux clics.
• Liens internes vers des redirections ou des 404 : corrigez-les pour qu’ils pointent vers l’URL finale.
• Doublons : filtres et paramètres, variantes avec et sans www ou avec et sans barre oblique finale.
• Arborescence des URL : des chemins lisibles et cohérents avec l’organisation du menu.

Étape 8 : hreflang

Si votre site existe en plusieurs langues ou pour plusieurs pays, contrôlez le hreflang. Les règles de Google : chaque version doit se citer elle-même et citer toutes les autres, sinon les balises peuvent être ignorées. Les URL doivent être complètes, protocole https compris. Le code de langue suit la norme ISO 639-1, avec éventuellement un code de région ISO 3166-1 Alpha 2, mais jamais un code pays seul : fr-BE est valable, BE non. La valeur x-default désigne la page par défaut. Balises HTML, en-têtes HTTP et sitemap sont trois méthodes équivalentes pour Google (Google Search Central). Faites aussi pointer le hreflang uniquement vers des pages canoniques, indexables et en code 200. Pour aller plus loin, lisez notre guide du hreflang.

Étape 9 : les données structurées

Les données structurées sont un format standardisé qui décrit une page et classe son contenu. Google recommande le JSON-LD et précise qu’un balisage qui ne respecte pas ses consignes peut ne pas être éligible aux résultats enrichis. Testez pendant le développement avec le test des résultats enrichis, puis suivez les rapports de la Search Console après la mise en ligne (Google Search Central). Vérifiez aussi que le balisage correspond au contenu visible de la page. Notre article sur la mise en œuvre du schema markup détaille les types les plus utiles.

Comment prioriser les corrections ?

Un crawler remonte vite des centaines d’alertes. Les traiter de haut en bas, c’est passer des semaines sur des détails. Classez-les plutôt en quatre groupes :

1. Bloquant : des pages importantes qui ne peuvent pas être indexées à cause d’un noindex, d’un blocage robots.txt, d’erreurs serveur ou d’une mauvaise canonique.
2. Étendu : des erreurs de gabarit qui touchent beaucoup de pages d’un coup, comme des canoniques absentes sur toutes les fiches produit, un LCP lent sur toutes les pages catégorie ou une chaîne de redirections dans le menu.
3. Ponctuel : quelques liens cassés, quelques pages lentes, une erreur de hreflang sur une seule version.
4. Cosmétique : des alertes sans effet visible, comme une balise title qui dépasse de quelques caractères.

Pour chaque problème, notez combien de pages importantes il touche, l’effort nécessaire et qui le corrige : développeur, rédacteur ou hébergeur. Ne visez pas un score parfait dans un outil, ce score n’est qu’un moyen. Après chaque correction, vérifiez avec l’inspection d’URL et un nouveau crawl que le problème a bien disparu.

Pas le temps ou pas de développeur en interne ? Avec notre audit SEO, nous passons ces étapes en revue pour vous et vous indiquons ce qu’il faut corriger en premier.

À quelle fréquence faire un audit ?

Il n’existe pas de règle officielle. Voici ce que nous recommandons :

• Un audit complet au démarrage du travail SEO, puis une à deux fois par an pour un site qui évolue peu.
• Toujours avant et juste après un changement important : refonte, nouveau CMS, changement de domaine ou nouvelle version linguistique.
• Un contrôle rapide chaque mois dans la Search Console : indexation des pages, Core Web Vitals et HTTPS. Activez aussi les alertes par e-mail.
• Les sites e-commerce et les gros sites, où des pages apparaissent et disparaissent tous les jours, gagnent à programmer un crawl mensuel.