Un client m'appelle en panique. Sa nouvelle home page est en ligne depuis trois jours, et le trafic organique a chuté de moitié. Le développeur jure que « tout fonctionne ». Sauf qu'en ouvrant son fichier robots.txt, je découvre une ligne oubliée depuis la préprod : Disallow: /. Quatre caractères. Trois jours de trafic perdu, et deux semaines pour revenir au niveau d'avant.
Ce genre d'histoire, je l'ai vue assez souvent pour avoir développé une discipline : avant de toucher à un site, on l'audite. Pas un audit de surface pour rassurer le client. Un vrai audit technique avant refonte, celui qui liste ce qui existe, ce qui marche, ce qui casse et ce qu'on risque de détruire en appuyant sur « déployer ».
Ce que je vous propose ici, c'est la checklist que j'utilise réellement, dans l'ordre où je l'exécute. Avec les seuils chiffrés, les outils, et ce que personne ne pense à vérifier (moi le premier, pendant longtemps).
Points clés à retenir
- Un audit technique pré-refonte sert d'abord à figer une baseline : sans mesure avant, aucune comparaison après.
- Le crawl complet et l'inventaire des URL sont les deux livrables non négociables.
- Le mapping de redirections 301 se prépare avant la mise en ligne, jamais après.
- Les erreurs coûteuses sont rarement visuelles : robots.txt, canoniques, sitemap, codes HTTP.
- Un audit utile tient en un tableur priorisé, pas en un PDF de 60 pages.
Comment auditer un site web sans y passer trois semaines ?
Un audit de site web consiste à inventorier méthodiquement l'état d'un site existant : structure des URL, contenu indexé, performances, erreurs serveur, dépendances techniques. Rien de mystique. La difficulté n'est pas de savoir quoi regarder, c'est de savoir dans quel ordre et à quel niveau de détail s'arrêter.
Par où commencer concrètement
Mon premier réflexe, avant même de lancer le moindre outil : récupérer les accès. Tous. Serveur, DNS, Search Console, analytics, CMS, base de données. J'ai perdu une semaine sur un projet parce que personne ne savait qui avait les clés du compte Search Console, hérité d'une ancienne agence. Un audit qui démarre sans les accès est un audit qui démarre à l'envers.
Ensuite, dans cet ordre précis :
- Export complet des URL depuis le sitemap et depuis la Search Console, puis comparaison des deux listes.
- Crawl du site avec un outil dédié pour obtenir la photographie réelle des statuts HTTP.
- Relevé des performances sur les 10 pages qui pèsent le plus en trafic.
- Inventaire des redirections existantes, avec chaînes et boucles.
- Documentation de tout ce qui est branché sur le site : formulaires, API, scripts tiers.
Le point 5 est celui que j'oubliais systématiquement. Sur un projet mené pour une PME industrielle, la refonte a été livrée impeccable côté pages. Sauf que le script de suivi des demandes de devis envoyait ses données vers un webhook dont l'URL pointait vers l'ancien serveur. Trois semaines de demandes de devis perdues, sans aucune alerte. Personne ne s'en est aperçu avant que le commercial ne râle sur le silence des prospects.
Que doit contenir une checklist d'audit ?
Une checklist d'audit doit couvrir quatre familles de contrôles : l'indexation, la structure des URL, les performances et la couche applicative. Si votre liste ne contient que du SEO on-page, elle est incomplète.
Volet indexation et crawl
C'est le socle. Sans lui, tout le reste est décoratif.
- Le fichier robots.txt : règles actives, directives de préprod oubliées, chemins vers le sitemap.
- Les balises canoniques sur les pages à contenu proche ou dupliqué.
- Le sitemap XML : nombre d'URL, cohérence avec le site réel, date de dernière génération.
- Les balises meta robots, page par page, pas seulement sur l'accueil.
- La gestion des paramètres d'URL (filtres, tri, pagination) et leur indexabilité.
Volet URL et redirections
Un changement de structure d'URL sans mapping page-à-page, c'est une loterie. Je veux un tableau avec trois colonnes : URL ancienne, URL cible, code de statut prévu. Une ligne par URL. Pas de règle générique du type « tout ce qui commence par /blog/ va vers /actualites/ » — ça marche pour 90 % des cas et casse les 10 % qui comptaient le plus.
Vérifiez aussi les redirections existantes. Sur un site que j'ai repris, une page accumulait quatre sauts successifs avant d'arriver à destination. Chaque saut ajoute de la latence et brouille le signal envoyé aux moteurs. Le plan de redirection doit être plat : une URL, une cible, un saut.
Volet performances et Core Web Vitals
Relevez les indicateurs sur mobile d'abord. Sur les projets que j'ai suivis, les scores desktop sont presque toujours corrects et le mobile catastrophique — ce qui est exactement l'inverse de ce qui compte. Notez les trois mesures (affichage du plus grand élément, stabilité visuelle, interactivité) page par page sur les URL à fort trafic. Ce relevé servira de référence après refonte.
Volet applicatif
Formulaires et points d'envoi. Espacements de noms DNS et sous-domaines. Certificats. Scripts tiers et leur poids. Règles de pare-feu ou de limitation de débit qui pourraient bloquer un robot d'exploration. Et une sauvegarde complète, testée, avant toute manipulation — pas une sauvegarde « normalement ça tourne ».
Comment construire une checklist de site web utile ?
La plupart des checklists que je vois circuler sont des listes de courses : 120 lignes, toutes cochées à la fin, aucune priorisée. Elles rassurent. Elles ne servent à rien.
Partir de la baseline, pas de la théorie
Une bonne checklist se construit à partir de ce que le site est réellement. Vous crawlez, vous exportez, et vous observez. Ensuite seulement vous écrivez les contrôles adaptés. Sur un site de 40 pages, un contrôle d'indexation prendra une heure. Sur un catalogue de 12 000 références, il faudra une stratégie par gabarit de page.
Fixer des seuils de décision chiffrés
C'est l'angle qui manque le plus souvent. Un audit doit permettre de trancher : refonte complète ou optimisation ciblée ? Trois critères me suffisent, en général :
- Part du trafic organique portée par les pages obsolètes. Si moins de 15 % du trafic passe par des pages techniquement condamnées, une refonte complète est envisageable sans risque majeur. Au-delà de 40 %, il faut un plan de migration chirurgical.
- Nombre d'erreurs serveur sur les URL qui convertissent. Une seule URL de conversion en erreur 500 justifie de repousser la mise en ligne.
- Dette technique de la plateforme actuelle, mesurée en temps de correction estimé. Si deux semaines de correctifs suffisent, la refonte n'est peut-être pas la bonne réponse.
Le livrable attendu
Un tableur, pas un document. Colonnes : URL, constat, sévérité, action prévue, responsable. Trié par sévérité décroissante. Un rapport qui liste 300 problèmes sans hiérarchie est un rapport que personne ne lira, vous compris.
| Type de contrôle | Outil courant | Livrable | Temps réel constaté |
|---|---|---|---|
| Crawl et statuts HTTP | Outil de crawl dédié | Export CSV des URL | 2 à 4 h |
| Indexation | Console de recherche | Liste des URL indexées | 1 h |
| Performances | Mesure terrain + labo | Tableau par page | 3 h |
| Mapping redirections | Tableur | URL → URL → statut | Variable, souvent 1 à 2 j |
| Dépendances applicatives | Entretien + relevé manuel | Schéma des branchements | 2 à 3 h |
Qu'est-ce qu'une checklist d'audit, au fond ?
Une checklist d'audit est un outil de vérification reproductible : une suite de contrôles définis à l'avance, exécutés dans un ordre stable, dont chaque résultat est documenté. Son intérêt n'est pas la liste elle-même, c'est la régularité d'exécution.
Et franchement, c'est là que je pêche. Ma première checklist comptait 80 lignes. Je l'ai utilisée deux fois. Trop longue, trop abstraite, trop de cases à cocher sans conséquence. Aujourd'hui elle tient sur une page, avec une quinzaine de contrôles répartis par volet, et un champ « à vérifier après mise en ligne » qui s'est révélé plus utile que tout le reste. C'est le seul endroit où je note les redirections promesses, les contrôles d'indexation à refaire, les scripts tiers à reconnecter.
Spoiler : ce champ post-ligne est celui que tout le monde saute quand le projet est en retard. Ce qui est précisément le moment où il sert le plus.
Les erreurs que j'ai vraiment commises
Un audit se rate rarement sur la technique. Il se rate sur le périmètre et le calendrier.
Erreur numéro un : auditer après avoir validé les maquettes. Les décisions d'architecture sont prises, l'audit devient un document de justification. J'ai fait ça sur un projet de refonte e-commerce, l'audit est arrivé trois semaines trop tard et n'a servi qu'à confirmer des choix déjà faits. 12 % du trafic organique est parti, en silence, sur des URL de fiches produits dont personne n'avait noté les codes.
Erreur numéro deux : auditer sans le développeur qui reprend le code. Il voit des choses que l'auditeur ne voit pas — les dépendances cachées, les scripts lourds, les hacks accumulés. Le faire intervenir tôt change la nature du rapport.
Erreur numéro trois, la plus stupide : ne pas mesurer la baseline de façon assez précise. Un « trafic global » ne sert à rien. Il faut du trafic par URL, par gabarit de page, par requête. Sans ça, impossible de savoir, après refonte, si une baisse vient d'un problème technique ou d'une simple saisonnalité.
Ce qu'il faut retenir avant de lancer la refonte
Une refonte ne détruit pas un site parce qu'elle est mal codée. Elle le détruit parce qu'on a changé des choses qu'on n'avait pas mesurées. L'audit technique sert exactement à ça : rendre visible ce qui fonctionnait, avant de le remplacer.
Si vous ne devez retenir qu'une seule chose de tout ce qui précède, c'est la séquence : crawl, inventaire, mapping, baseline. Dans cet ordre. Le reste — les outils, les seuils, la mise en forme du rapport — s'ajuste.
Et posez-vous la question inverse de celle qu'on me pose toujours. Non pas « qu'est-ce que je peux améliorer ? », mais : qu'est-ce qui marche aujourd'hui, et que vais-je casser en changeant ceci ? La réponse à cette question-là vaut plus que la refonte entière.
