On vous propose de refaire votre site, parce qu'il est lent, qu'il vieillit ou qu'il se met mal à jour. Avant de signer, un audit technique de site vous dit ce qui est vraiment cassé, et surtout si une refonte répare ce problème-là. Certaines pannes survivent très bien à un site neuf : un cache mal réglé ou un flux de données mal défini se retrouvent à l'identique dans le nouveau projet.
J'ai fait des audits techniques en mission, et mes missions commencent par quelques jours de diagnostic. Voici ce que je regarde, dans quel ordre, et comment je range ce que je trouve pour que vous puissiez décider.
01Ce qu'un audit avant refonte doit vous aider à décider
Avant la première vérification, je pose une question : quelle décision prendrez-vous avec cet audit ? Un rapport qui ne sert aucune décision finit dans un dossier partagé. Dans le cas d'une refonte, il y a en général trois issues.
- Réparer : le socle tient, les pannes sont localisées, et quelques corrections suffisent.
- Migrer : le contenu et la structure tiennent, mais l'outil bloque la publication, les langues ou les intégrations. C'est le cas que je décris dans migrer un site vers Next.js et Sanity.
- Refaire : les contenus sont mal découpés, les gabarits ne peuvent plus évoluer, et réparer coûterait plus que reconstruire.
Je préfère écrire ces trois issues en tête du document. Elles obligent à relier chaque constat à quelque chose de concret, et elles évitent qu'un audit serve seulement à justifier une refonte déjà vendue.
02Comprendre comment le site fonctionne avant de lancer un outil
Dans une courte vidéo de Google Search Central, Martin Splitt découpe l'audit en quatre temps : comprendre le site, l'examiner, évaluer ce qu'on trouve, expliquer ce qu'on recommande (How to perform a technical SEO audit). Il regrette les rapports aux scores arbitraires, difficiles à interpréter, et demande de ne pas suivre ses outils aveuglément. Je le rejoins sur l'ordre. Un crawler lancé en premier produit des centaines de lignes, et vous ne savez pas encore lesquelles comptent pour votre site.
Je commence donc par une page qui décrit le site, sans outil, en parlant aux personnes qui s'en occupent :
- l'outil de publication, l'hébergement et le cache ;
- la façon dont les pages sont produites, sur le serveur ou dans le navigateur ;
- les langues et les pays visés ;
- tout ce qui est branché au site : CRM, ERP, paiement, formulaires, outils de mesure ;
- qui publie, qui a les accès, qui répond quand le site tombe.
Cette page change le reste de l'audit. Splitt donne l'exemple des balises de langue : à contrôler sur un site international, sans objet sur un site à une seule langue.
Elle sert aussi à repérer ce qu'un crawler ne voit pas. Un site porte parfois plus que des pages. Celui de Moonworkers, mon entreprise, a des calculateurs gratuits que j'ai vérifiés un par un contre les outils officiels : perdre cette vérification dans une refonte serait bien plus grave qu'une balise manquante. Les données comptent autant. J'ai appris en mission qu'un mélange de centimètres et de millimètres entre deux outils peut déformer tout un rendu. Depuis, je cherche quelle donnée fait référence, et où c'est écrit.
03Ce que je vérifie, couche par couche
Je vais du plus bloquant au plus fin. Inutile de discuter des images si le serveur répond une fois sur deux.
Exploration et indexation
Search Console donne déjà beaucoup, gratuitement. Le rapport sur l'indexation des pages indique l'état de toutes les URL que Google connaît, avec les motifs de non-indexation. Le rapport sur les statistiques d'exploration montre comment votre serveur répond à Google. J'y regarde le temps de réponse moyen et l'état de l'hôte, parce que Google y prévient de deux choses : sans réponse valide pour le fichier robots.txt, il ralentit ou arrête l'exploration, et quand les erreurs serveur augmentent, Googlebot réduit ses demandes.
Google réserve ce rapport aux utilisateurs avancés et dit qu'un site de moins de mille pages n'a normalement pas à s'en soucier : sur un petit site, il suffit de vérifier que le serveur répond bien.
Les erreurs 404 demandent du recul. La même aide dit qu'il n'est ni possible ni souhaitable de toutes les corriger. Splitt précise qu'un grand nombre de 404 après un retrait de contenu est normal, alors qu'une hausse sans explication mérite une enquête.
Redirections, liens et rendu
Je cherche les chaînes et les boucles de redirection. Google recommande de les éviter, idéalement pas plus de 3 redirections de suite (Google Search Central, migrer un site). J'en profite pour commencer la liste des URL, à partir des sitemaps, des journaux serveur et du CMS. Si la refonte a lieu, cette liste devient la table de redirections.
Puis je regarde le code reçu par le navigateur. Google dit ne découvrir les liens que dans des éléments `<a>` avec un attribut href, et continue de recommander le rendu côté serveur ou le pré-rendu, parce que tous les robots n'exécutent pas JavaScript (les bases du SEO JavaScript). Un menu en boutons JavaScript peut sembler parfait à l'œil et rester invisible pour un robot.
La vitesse chez vos vrais visiteurs
Un score mesuré une fois sur un poste de bureau ne dit pas grand-chose. Les données de terrain viennent de vos utilisateurs réels et forment une distribution, et un test de laboratoire peut donner un autre chiffre pour la même page (web.dev, données de test et données réelles). Je compare aux seuils publiés par Google : LCP à 2,5 secondes, INP à 200 millisecondes et CLS à 0,1, au 75e centile, mobile et ordinateur séparés (web.dev, Web Vitals).
Une page lente ne prouve pas qu'il faille refaire le site. Souvent, c'est une image trop lourde ou un script tiers de trop, et cela se corrige sans refonte.
Ce que voit un visiteur sans session
C'est le contrôle que je ne saute jamais. En mission, j'ai vu un site qui semblait normal à l'équipe connectée et qui était cassé pour les visiteurs, à cause d'un cache. Je vérifie donc en navigation privée, sur l'adresse publique. J'envoie un formulaire et je regarde s'il arrive. Je fais publier une modification et je regarde quand elle apparaît.
Cookies et accessibilité
Ces deux points entrent dans le cahier des charges de la refonte, autant les connaître avant. La CNIL demande le consentement avant le dépôt des cookies concernés, et un refus aussi simple que l'acceptation (CNIL, cookies et traceurs). Je charge la page sans rien cliquer et je regarde ce qui est déjà déposé.
Depuis le 28 juin 2025, des exigences d'accessibilité s'appliquent à certains services, dont le commerce électronique. La directive prévoit une dispense pour les entreprises de moins de 10 salariés avec moins de 2 millions d'euros de chiffre d'affaires (DGCCRF, directive Accessibilité). Je ne suis pas juriste : je signale le sujet, et votre conseil tranche sur votre cas.
04Classer chaque constat en rouge, orange ou vert
J'ai emprunté ce classement à ma machine de contenu, où un contrôle relit chaque article avant publication. Les règles marchent aussi bien pour un audit.
- Rouge : le constat empêche des visiteurs ou des moteurs d'accéder au site, ou touche une obligation. Il se traite, quelle que soit la décision sur la refonte.
- Orange : le constat peut être légitime. Il reste ouvert jusqu'à ce que quelqu'un écrive pourquoi on le garde ou pourquoi on le corrige. Les 404 d'un ancien catalogue retiré entrent ici.
- Vert : le contrôle a eu lieu et la preuve est notée.
Une règle compte plus que les autres : une vérification qui n'a pas eu lieu est un rouge. Le piège d'un contrôle, c'est le vert par défaut. Si je n'ai pas eu l'accès à Search Console ou aux journaux serveur, je ne l'écris pas en vert ni en petit à la fin. C'est un rouge, jusqu'à ce que le contrôle soit fait.
Chaque constat tient sur une ligne du même modèle :
- Constat : le formulaire de contact n'arrive pas si le cache est actif
- Preuve : envoi en navigation privée, aucune réception
- Couleur : rouge
- Effort : faible
- Impact : les demandes de contact sont perdues
- Refonte : ne le répare pas, le réglage du cache suivrait
Cet exemple illustre le format, ce n'est pas un cas réel. La dernière colonne est celle qui sert à décider : quand la plupart des rouges se réparent sans refonte, le projet de refonte change de nature. Je trie ensuite par effort et par impact, comme le conseille Splitt, puis je relis le tout avec l'équipe. Elle sait souvent pourquoi une chose bizarre a été faite de cette façon, et elle m'évite de présenter comme un problème un choix assumé.
05Ce qu'un audit technique ne vous dira pas
Il ne dit pas si votre site convainc. Un site techniquement propre peut ne rien vendre, parce que le message ou l'offre ne tiennent pas. Cela relève du cadrage, que je décris dans cadrer un projet digital en une semaine.
Il ne remplace pas non plus un test d'intrusion. Je regarde les certificats et les en-têtes, mais une vraie revue de sécurité demande un spécialiste, et je préfère le dire.
C'est aussi une photo à une date donnée. Et si vous décidez de migrer ensuite, l'audit ne supprime pas le risque : Google prévient que le classement peut fluctuer, et qu'il faut compter quelques semaines pour la majorité des pages d'un site de petite à moyenne taille (Google Search Central, migrer un site).
Enfin, un petit site vitrine de cinq pages n'en a pas besoin sous cette forme. Une heure avec Search Console et une navigation privée suffit souvent.
06Par où commencer votre audit
Si une refonte est sur la table, voici ce que je ferais lundi :
- Écrire la décision à prendre et les trois issues possibles.
- Rédiger la page qui décrit le site, avec les personnes qui s'en occupent.
- Réunir les accès : Search Console, outil de mesure, hébergement, CMS. Tout accès manquant est noté en rouge.
- Ouvrir les rapports d'indexation et d'exploration, et noter ce qui bouge.
- Tester le site en navigation privée : les pages clés, un formulaire, une publication.
- Ranger les constats sur le modèle ci-dessus, puis poser la question de la dernière colonne.
Si la refonte est décidée, ces constats nourriront votre checklist de recette et de mise en production : chaque rouge y devient un test à repasser avant la bascule. Si vous voulez un regard extérieur sur votre site, la page services dit comment je travaille ; on peut en parler.