Un site peut sembler “propre”. Rapide. Bien structuré. Et pourtant, vous sentez cette gêne sourde : Google rampe mal, certaines pages disparaissent, votre trafic se met à glisser sans prévenir. Le pire ? Vous avez déjà essayé de comprendre. Vous avez parcouru GSC, lancé un crawl, noté des anomalies. Mais vous ne savez plus quoi traiter en premier. Vous perdez du temps. Vous corrigez des détails. Les urgences, elles, restent cachées.
Ici, vous allez obtenir l’inverse : une lecture claire, une checklist priorisée et des actions prêtes à exécuter. Rien de théorique. Rien d’abstrait. Juste ce qu’il faut pour reprendre le contrôle et avancer sans hésitation. On commence par cadrer l’audit, pour éviter de corriger “à l’aveugle”.
Cadrer l’audit : périmètre, objectifs, risques
Un audit technique mal cadré, c’est comme réparer un moteur sans savoir quel voyant clignote. Vous avancez, mais vous ne comprenez rien. Et surtout, vous perdez du temps.
Quand déclencher un audit technique
Trois situations reviennent toujours.
- La première : la chute de trafic. GSC vire au rouge, et vous ne savez pas si c’est Google, votre site ou un mix des deux.
- La deuxième : la refonte. Beaucoup d’équipes pensent que la technique “ira après”. C’est faux. Une refonte sans audit préalable, c’est la recette parfaite pour perdre des pages stratégiques.
- La troisième : le scale e-commerce. Quand un catalogue passe de 500 à 10 000 références, tout explose si l’architecture n’est pas solide.
Une directrice e-commerce m’avait contacté pour ce cas. Indexation chaotique, filtres mal gérés, URLs dupliquées. Résultat : 40 % du trafic non indexé. L’audit a posé les bases. Trois mois plus tard, 90 % des pages utiles étaient revenues dans l’index.
Périmètre : templates, sections, sous-domaines, langues, paramètres
Un bon audit ne se fait jamais “en global”. On découpe. Templates : fiche produit, catégorie, article, homepage. Sections : blog, e-commerce, institutionnel. Sous-domaines : surtout si vous mélangez plusieurs stacks techniques.
Langues : une seule erreur hreflang peut tout casser. Paramètres : pagination, filtres, tri, tracking. C’est ce périmètre qui empêche de partir dans tous les sens. Et qui évite de rendre le rapport inutilisable.
Les 3 sorties attendues : diagnostics, priorités, backlog dev
Beaucoup d’agences livrent un PDF de 80 pages. Beau, mais inutilisable. Ce que vous voulez réellement :
- Un diagnostic clair : ce qui bloque aujourd’hui.
- Une priorisation nette : P0 / P1 / P2.
- Un backlog dev : tickets prêts à intégrer dans Jira ou Notion.
Sans ces trois éléments, votre audit ne vaut rien. L’audit n’est pas un document. C’est une décision. Un point contre-intuitif : supprimer des tâches. Oui. Retirer 30 % des recommandations qui n’apportent pas de valeur. C’est ce qu’on fait souvent chez Heroic Impulsion, et c’est ce qui débloque les projets.
Crawl & indexation : la base (si Google ne passe pas, vous n’existez pas)
robots.txt
Bloque l’accès à Google
noindex
Retire de l’index mais autorise la lecture
Quand un site ne performe pas, je commence toujours ici. Pas par l’optimisation. Pas par le contenu. Par le passage de Google. Si Googlebot ne circule pas, tout le reste est inutile.
Robots.txt vs noindex : ne pas confondre
C’est l’erreur classique. Le robots.txt bloque l’accès. Le noindex retire une page de l’index tout en laissant Google la lire. J’ai accompagné une scale-up B2B qui avait bloqué son répertoire /blog/ en pensant “désindexer des articles”. Résultat : Google n’arrivait même plus à découvrir les nouvelles URLs. Simple confusion. Grosse conséquence.
Sitemaps : ce qu’on met / ce qu’on exclut
Un sitemap XML n’est pas une poubelle où l’on met “tout le site”. On y met : pages stratégiques, propres, indexables. On exclut : paramètres, redirections, 404, pages orphelines non voulues. Un sitemap trop large donne un signal brouillon à Google. Et un sitemap propre accélère la couverture d’indexation.
GSC : pages exclues, canonique Google vs canonique déclaré
C’est l’endroit où vous voyez ce que Google pense réellement de votre site. Deux questions simples guident tout :
- “Quelles pages Google refuse d’indexer et pourquoi ?”
- “Google choisit-il les mêmes pages canoniques que moi ?”
Si la réponse est non, vous avez un problème structurel. Les sites à forte volumétrie le vivent souvent : Google remplace vos choix par ce qu’il estime logique.
Crawl budget : quand c’est utile, quand c’est du bruit
Beaucoup en parlent. Peu en ont besoin. Le crawl budget devient un sujet quand vous avez : un gros site, des URLs générées dynamiquement, un e-commerce avec facettes, ou des millions de pages. Pour un site vitrine ou B2B : ce n’est pas un sujet.
Duplication & canonicals : là où les sites se sabotent en silence
Sources classiques de duplication
?utm_source=, ?ref=
Couleur, taille, matière
/page/2/, /page/3/…
Versions non consolidées
Versions ouvertes
Doublons non filtrés
La duplication, c’est le piège le plus silencieux. Rien ne casse. Rien ne plante. Mais Google s’y perd, et votre visibilité s’effondre sans bruit. Dans un audit pour un e-commerce textile, on a découvert que 12 variantes couleur généraient autant d’URLs.
Résultat : Google passait son temps sur des pages secondaires. Les fiches principales restaient au placard. Trois semaines après nettoyage + canonical propre, les pages stratégiques ont regagné leurs positions.
Sources classiques de duplication (paramètres, filtres, pagination, http/https, www)
Les causes reviennent toujours, peu importe la taille du site. Voici les plus fréquentes :
- Paramètres d’URL ajoutés par le tracking
- Filtres e-commerce (couleur, taille, matière)
- Pagination mal gérée
- Versions http / https non consolidées
- Versions www / non-www laissées ouvertes
- URLs en double dans le sitemap
SEMrush a publié une étude sur les problèmes on-site indiquant que le contenu dupliqué apparaissait sur 50% des sites analysés. Ce n’est pas une “pénalité” automatique, mais ça brouille les signaux et Google choisit parfois une autre URL que celle que vous vouliez voir ranker.
Semrush — 11 Most Common On-Site SEO Mistakes (2016)
Canonicalisation : ce que Google recommande, ce qu’il ignore parfois
La balise canonique sert à dire “cette version est la source officielle”. Le problème : Google ne suit pas toujours votre choix.
Google l’explique clairement : même si vous désignez une URL canonique, il peut en choisir une autre selon les signaux (qualité, cohérence, signaux internes). Donc si vos liens internes, sitemaps et canonicals ne racontent pas la même histoire, Google tranche à votre place.
Google Search Central — Fix canonicalization issues
J’ai eu le cas sur un site SaaS : toutes les pages US étaient auto-canonisées, mais le maillage interne poussait les versions FR. Google a fini par choisir les FR comme pages principales. Le trafic US s’est effondré. On a corrigé le maillage, nettoyé les paramètres et clarifié les canonicals. Deux mois plus tard, les URL US reprenaient le dessus.
Diagnostic rapide dans GSC + crawler (signaux concrets)
Vous pouvez repérer les duplications en moins de dix minutes. Regardez :
- Dans GSC, les “pages dupliquées sans sélection canonique”
- Les pages où Google a choisi un canonical différent du vôtre
- Les clusters de pages similaires dans un crawl Screaming Frog
- Les séries d’URL avec paramètres répétés
Un crawler révèle souvent des dizaines de variantes inutiles. Et si vous gérez un catalogue large, le problème peut être massif :
Ahrefs a publié une étude (2023) montrant que 96,55% des pages de leur index ne reçoivent aucun trafic depuis Google. Quand un site génère des milliers d’URLs proches (filtres, paramètres, pagination), vous augmentez mécaniquement la part de pages “invisibles” et vous diluez les signaux.
Ahrefs — Search traffic study (2023)
Outil pratique immédiat
Activez dans Screaming Frog le rapport “Duplicate” + “Near Duplicates”. C’est le moyen le plus simple d’isoler les clusters problématiques et de corriger votre stratégie canonique avant que Google ne le fasse à votre place.
Conseil contre-intuitif
Ne mettez pas de canonical sur des pages que vous ne souhaitez pas indexer. C’est une erreur fréquente. Si une page doit disparaître, utilisez un noindex. Le canonical sert à orienter, pas à cacher.
Architecture & maillage : faire circuler le crawl et l’autorité
Points de vigilance
Une architecture claire, c’est comme un plan de métro lisible. Google comprend tout de suite où aller. Une mauvaise structure, c’est l’inverse : le robot tourne, gaspille du budget, et laisse les pages importantes dans l’ombre.
On l’a vécu sur un site immobilier B2B : 70 % des pages profondes n’étaient quasiment jamais crawlées. Après restructuration et maillage vers les pages money, la fréquence d’exploration a doublé.
Profondeur de clics, pages orphelines, hubs
Un site efficace garde ses pages importantes à deux ou trois clics maximum. Au-delà, Google considère souvent la page secondaire. Les signaux à vérifier :
- Pages à plus de 4 niveaux de profondeur
- Pages orphelines (surtout si elles sont stratégiques)
- Absence de hubs (pages piliers regroupant les contenus clés)
- Pages liées uniquement via le sitemap
- Sections sans lien retour vers la homepage
Un audit sérieux corrige d’abord la circulation interne avant d’optimiser quoi que ce soit d’autre.
Pagination & catégories : erreurs fréquentes (indexation inutile, dilution)
La pagination mal pensée crée des séries infinies. Google déteste ça. Les erreurs qu’on retrouve partout :
- Catégories trop larges
- Pagination indexée alors qu’elle ne devrait pas l’être
- Pages “page 2, page 3…” en canonical sur elles-mêmes
- Liens vers des filtres ouverts aux bots
- Absence de liens vers les produits prioritaires
Dans un audit, si votre catalogue est large, corriger ces points peut être plus rentable qu’ajouter 50 nouveaux contenus.
Maillage “décideur” : prioriser les pages business / money pages
Le maillage interne doit parler business. La question est simple : “Quelles pages doivent absolument recevoir de l’autorité ?” Dans 90 % des audits, les pages les plus rentables sont peu ou mal liées. Pour muscler votre architecture, concentrez-vous sur :
- Les pages services
- Les fiches produit les plus rentables
- Les contenus experts qui driv ent les conversions
- Les pages catégories bien travaillées
- Les pages guides à forte valeur
- Les landing pages stratégiques
C’est ce maillage orienté décision qui crée un vrai effet levier.
Méthode actionnable immédiate
Utilisez un crawler et exportez le “Link Score” des pages. Listez les 20 pages importantes de votre business. Si elles n’apparaissent pas dans le top 30 par Link Score, vous avez un problème de circulation d’autorité.
Si vous sentez que votre structure part dans tous les sens, un audit cadré peut éviter des mois de perte. C’est ce qu’on fait au quotidien dans notre accompagnement chez Heroic Impulsion.
Performance & UX technique : CWV (INP) + mobile (là où ça coûte cher)
Field Data vs Lab Data
La performance, c’est le sujet qui revient toujours sur la table. Surtout quand un site “semble rapide”, mais que les utilisateurs décrochent. J’ai accompagné un média national où le site chargeait “correctement” en apparence.
Pourtant, le LCP dépassait les 4 secondes sur mobile et l’INP explosait. Résultat : baisse du trafic mobile et chute des pages AMP supprimées. Après optimisation, les signaux sont revenus au vert. Leur taux d’engagement a gagné +22 %. Ça montre une chose simple : la vitesse, ça se voit d’abord dans les comportements, pas dans le code.
Core Web Vitals : INP a remplacé FID (ce que ça change)
Depuis mars 2024, Google a remplacé le FID par INP (Interaction to Next Paint). L’idée est simple : mesurer le pire moment d’interactivité, pas juste la première interaction.
En clair : si votre site répond bien au début mais se bloque dès qu’un script se lance, l’INP le verra. C’est là que beaucoup tombent dans le panneau. Le site “semble” rapide. Mais le JavaScript gèle l’interface. Votre utilisateur attend. Et Google le mesure.
CrUX s’appuie sur des données d’utilisateurs réels (field data). C’est ce que Google utilise pour les Core Web Vitals. Les tests “lab” (Lighthouse/PageSpeed) restent utiles, mais ils simulent. Donc on lit d’abord CrUX, puis on utilise le lab pour trouver quoi corriger.
Chrome Developers — Overview of CrUX
Diagnostiquer sans se faire piéger (field vs lab )
C’est une confusion fréquente :
- Field = réalité terrain (CrUX + données utilisateurs).
- Lab = simulation (PageSpeed, Lighthouse).
- Un site peut être excellent en lab et catastrophique en field.
- C’est souvent le cas sur mobile bas de gamme.
- Trois signaux doivent vous alerter immédiatement :
- LCP supérieur à 2,5 secondes
- CLS instable (bannières, images sans dimensions)
- INP dégradé après interactions répétées
Dans notre accompagnement chez Heroic Impulsion, on commence toujours par les field . C’est le seul indicateur qui vous dit ce que vivent réellement vos utilisateurs.
Quick wins perf (images, JS, fonts, cache) & quand escalader au dev
Vous pouvez améliorer une grande partie de la performance sans toucher au backend.
Voici les leviers les plus rentables :
- Compresser les images et charger les formats modernes
- Supprimer les scripts inutiles (et il y en a toujours)
- Retarder le JS non critique
- Charger les polices en local pour réduire les blocages
- Activer un vrai cache serveur, pas un plugin “magique”
- Minimiser les iframes (YouTube en lazy-load, par exemple)
J’ai eu le cas d’un site SaaS où 70 % de la dette performance venait d’un seul script marketing mal configuré. Retiré en 5 minutes, impact immédiat : -1,2 s sur le LCP.
Et voici le conseil contre-intuitif : ne cherchez pas à tout optimiser. Certaines optimisations coûtent des semaines de dev pour 1 % de gain.
Priorités d’action : la matrice Impact × Effort + modèle de livrables
| Priorité | Type | Exemples | Impact |
|---|---|---|---|
|
P0
|
Bloquant
Empêche l’indexation
|
Erreurs HTTP 500/404 massives
Robots.txt bloquant
Noindex non souhaité
Canonicals incohérents
|
★
|
|
P1
|
Croissance
Améliore les performances
|
Core Web Vitals dégradés
Maillage interne faible
Architecture à revoir
Duplication modérée
|
↑
|
|
P2
|
Confort
Optimisations mineures
|
Micro-optimisations perf
Cosmétique technique
Détails non critiques
|
~
|
Un audit technique efficace n’est pas un document. C’est un plan d’exécution.
Classer P0 / P1 / P2 (bloquant / croissance / confort)
Voici la grille que j’utilise systématiquement :
- P0 : Bloquant — erreurs HTTP, robots.txt, noindex non souhaité, canonicals incohérents
- P1 : Croissance — performance, maillage, architecture, duplication modérée
- P2 : Confort — micro-optimisations, cosmétique technique, détails non critiques
Dans la majorité des cas, les P0 expliquent la majorité des pertes de trafic. Les P2 font perdre du temps. C’est souvent une révélation pour les équipes : on ne traite pas “tout”, on traite juste ce qui compte.
Exemple de backlog dev SEO (tickets prêts à copier)
Une bonne livraison contient des tickets actionnables.
Exemples concrets :
- “Ajouter width/height sur toutes les images du template catégorie”
- “Corriger canonical des pages filtrées : forcer canonical sur version propre”
- “Désindexer pagination 2+ via noindex”
- “Mettre en cache le JS marketing non essentiel”
- “Créer hub catégorie → relier 20 pages stratégiques”
KPIs & suivi : quoi mesurer après corrections (GSC, logs, CWV, indexation)
KPIs à surveiller post-audit
Mesures clés pour valider l’impact des corrections
Fréquence de crawl
Analyse des logs serveur
Couverture indexation
Pages valides vs exclues
Core Web Vitals
LCP, INP, CLS sur 28 jours
Pages actives
Volume indexé et performant
Trafic SEO stratégique
Sur pages money ciblées
Un audit sert à corriger, mais surtout à valider. Les KPIs les plus fiables après intervention sont :
- Fréquence de crawl (via logs)
- Couverture d’indexation GSC
- Évolution du LCP / INP / CLS
- Volume de pages actives dans l’index
- Impact sur le trafic SEO des pages stratégiques
Un audit technique, ce n’est pas un “check-up”
C’est une méthode pour lever les blocages, prioriser, puis exécuter rapidement. Quand c’est bien cadré, vous gagnez du temps. Quand c’est mal fait, vous perdez des mois. Si vous avez l’impression que votre site travaille contre vous, une analyse propre peut tout remettre d’aplomb.
Vous pouvez démarrer avec une checklist ou, si vous voulez aller plus vite, demander un audit structuré depuis la page audit SEO de mon agence.
Vos questions les plus fréquentes sur l’audit technique SEO
Comment choisir entre un audit technique fait en interne ou avec un expert ?
Dans beaucoup d’entreprises, on commence en interne avec Google Search Console et un crawler. Mais rapidement, on se rend compte que l’analyse “brute” ne suffit pas pour décider quoi prioriser. Un consultant expérimenté vous aide à distinguer les signaux qui valent de l’or de ceux qui sont du bruit, et à structurer un plan d’action exploitable (plutôt qu’une longue liste d’erreurs sans logique).
Audit interne ou externe : quand faut-il passer le relais ?
Beaucoup d’équipes poussent l’audit jusqu’à un certain seuil avant de se heurter à un mur. Si vous passez trop de temps à interpréter des logs, canonicals ou Crawl Budget sans impact clair sur vos pages business, c’est souvent le signe qu’il est temps d’avoir un œil externe pour débloquer la situation et orienter les décisions.
Quels leviers techniques ont le plus d’impact rapide sur la visibilité ?
Pour moi, trois leviers reviennent constamment sur le terrain : corriger la couverture d’indexation, nettoyer les duplications d’URL et améliorer les Core Web Vitals sur mobile. Ce sont les points qui, une fois débloqués, dégagent de la visibilité quasi instantanément, car ils permettent à Google de comprendre et visiter efficacement vos pages avant d’optimiser quoi que ce soit d’autre.
Mon site est lent uniquement sur mobile, est-ce normal ?
Oui. Beaucoup de sites techniques “passent” sur desktop mais s’écroulent sur mobile à cause de scripts JS lourds, de polices mal chargées ou d’images non adaptées. L’audit technique doit toujours comparer field (terrain mobile) et lab (simulations), car ce sont les données réelles qui dictent la visibilité.
Faut-il faire un audit technique avant une refonte ?
Absolument. Sans repères avant refonte, vous risquez de perdre des positions en reconstruisant ce qui fonctionnait déjà. Un audit donne des repères précis pour répliquer les signaux importants, et pas seulement reconstruire une arborescence. C’est une assurance contre les pertes de trafic après refonte, une erreur que j’ai déjà vue sur plusieurs projets chez Heroic Impulsion.
Sources et références utilisées
Les éléments factuels et statistiques mentionnés dans cette page s’appuient uniquement sur des sources publiques, vérifiables et reconnues dans l’écosystème SEO.
-
Semrush (2016) – Étude des erreurs SEO on-site les plus courantes (incluant la présence de contenu dupliqué).
https://www.semrush.com/blog/on-site-seo/ -
Ahrefs (2023) – Étude “Search traffic” sur la part de pages sans trafic organique depuis Google.
https://ahrefs.com/blog/search-traffic-study/ -
Google Search Central (2008) – Clarification officielle sur le “duplicate content penalty” et les risques réels liés au contenu dupliqué.
https://developers.google.com/search/blog/2008/09/demystifying-duplicate-content-penalty -
Google Search Central – Guide officiel : résoudre les problèmes de canonicalisation (Google peut choisir une autre canonique selon les signaux).
https://developers.google.com/search/docs/crawling-indexing/canonicalization -
Google Search Central – Guide officiel : consolider les URLs dupliquées (redirections, canonical, signaux cohérents).
https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls -
Google Search Central (2024) – Annonce : INP remplace FID comme Core Web Vital.
https://developers.google.com/search/blog/2023/05/introducing-inp -
web.dev (2024) – Référence officielle : INP devient un Core Web Vital en mars 2024 et remplace FID.
https://web.dev/blog/inp-cwv/ -
Chrome Developers – Présentation de CrUX (Chrome UX Report) et des données “field” issues d’utilisateurs réels.
https://developer.chrome.com/docs/crux/ -
web.dev – Explication des différences “lab data vs field data” (et comment les interpréter sans se tromper).
https://web.dev/articles/lab-and-field-data-differences -
Google Search Central – Seuils officiels Core Web Vitals (LCP, INP, CLS).
https://web.dev/articles/defining-core-web-vitals-thresholds
Les exemples chiffrés issus de projets clients sont volontairement anonymisés et exprimés sans données sensibles afin de respecter la confidentialité.






