Checklist d’audit SEO technique : 20 points à vérifier sur le crawl, l’indexation, le rendu et la performance
1. Pourquoi un audit technique se découpe en quatre quadrants
Beaucoup de gens font un audit technique en lançant PageSpeed Insights et en jetant un œil au nombre d’erreurs dans GSC. En réalité, le SEO technique comporte quatre niveaux : Google peut-il crawler (crawl), une fois crawlé, indexe-t-il (indexation), le contenu est-il correct (rendu), le site est-il rapide (performance). Si un seul niveau pose problème, tout le travail en amont est inutile.
Un constat contre-intuitif : 100 % d’indexation n’est pas un objectif. Sur un site de 1000 pages, si 900 sont des pages pauvres, des pages de paramètres ou des pages de résultats de recherche, leur indexation complète par Google fait baisser la note de qualité globale. La bonne approche consiste à passer en noindex les pages de faible qualité et à concentrer le budget de crawl sur les 100 pages qui ont réellement de la valeur.
| Quadrant | Question clé | En cas de problème | Poids |
|---|---|---|---|
| Crawl | Googlebot peut-il atteindre vos pages | Les pages ne sont jamais visitées | Niveau de base, éliminatoire |
| Indexation | Les pages crawlees sont-elles indexees | Les pages n’entrent pas dans la base Google | Niveau de base, éliminatoire |
| Rendu | Le HTML crawlé contient-il le contenu complet | Contenu correct mais illisible pour Google | Frequence elevee sur les sites modernes |
| Performance | Le site est-il rapide | Penalites de classement ou perte d’utilisateurs | L’un des facteurs de classement |
Les quatre quadrants s’enchainent dans l’ordre : d’abord s’assurer que le crawl fonctionne, puis l’indexation, puis un rendu correct, et enfin optimiser la performance. Cet ordre ne peut pas etre inverse : si robots.txt bloque des pages importantes, optimiser le LCP ne servira a rien. Et Google SEO Relations avec les autres modules : l’audit technique est la fondation,Données structurées Schema construit la maison sur cette fondation,Optimiser les Core Web Vitals approfondit le quadrant performance.
2. Le quadrant crawl : 5 points a verifier
Le crawl est le problème le plus fondamental. Si Googlebot n’atteint pas vos pages, tout le reste ne sert à rien.
| # | Point de contrôle | Critère de conformité | Outil | Questions fréquentes |
|---|---|---|---|---|
| 1 | robots.txt ne bloque rien par erreur | Aucune page importante en Disallow | Outil de test robots de la GSC | Disallow: / écrit par erreur lors d’une refonte |
| 2 | Sitemap XML accessible | Réponse 200, aucune erreur | Rapport Sitemap de la GSC | Chemin du sitemap erroné ou non soumis |
| 3 | Erreurs de crawl 4xx/5xx < 1 % | Part d’erreurs 404/500 inférieure à 1 % | Statistiques de crawl de la GSC | Nombreux 404 après refonte sans redirection 301 |
| 4 | Budget de crawl non gaspillé | Pages à paramètres/pages dupliquées ne gaspillent pas le crawl | Statistiques de crawl de la GSC + analyse des logs | Pages de résultats de recherche crawlées sans limite |
| 5 | Aucun lien interne cassé | Tous les liens internes renvoient 200 | Crawl avec Screaming Frog | Anciens articles pointant vers des pages supprimées |
Exemple de cas 1 : après une refonte, l’équipe technique a écrit Disallow: / dans le robots.txt et a oublié de le retirer. Trois semaines plus tard, les pages « Explorée, non indexée » de la GSC sont passées de 200 à 2 000. Comment le détecter : dès que le rapport de couverture montre une hausse anormale des « Explorée, non indexée », vérifiez le robots.txt en priorité. Après correction, demandez l’indexation manuelle via l’outil d’inspection d’URL : le rétablissement prend 1 à 3 jours.
Budget de crawl : Google ne crawle chaque site qu’un nombre limité de fois. Si votre site compte de nombreuses URL à paramètres (comme /products?sort=price&filter=red), Googlebot passe beaucoup de temps sur ces pages dupliquées, et les pages produit vraiment importantes passent après. La solution : bloquer les URL à paramètres dans le robots.txt, ou pointer un canonical vers la version principale.
3. Quadrant indexation : 5 vérifications
Que Google ait crawlé vos pages ne signifie pas qu’il les mettra dans son index. Le quadrant indexation vérifie une chose : ce qui doit être indexé l’est-il, et ce qui ne doit pas l’être ne l’est-il pas ?
| # | Point de contrôle | Critère de conformité | Outil | Questions fréquentes |
|---|---|---|---|---|
| 6 | Toutes les pages importantes sont indexées | Taux d’indexation des pages produit/articles clés > 95 % | Rapport de couverture de la GSC | Nouvelles pages produit non soumises dans le sitemap |
| 7 | Aucun noindex posé par erreur | Aucune balise noindex sur les pages en production | Screaming Frog + GSC | noindex d’environnement de développement oublié |
| 8 | Aucun contenu dupliqué | Un même contenu en plusieurs versions d’URL < 5 % | Siteliner + Screaming Frog | Doublons HTTP/HTTPS et avec/sans www |
| 9 | Balises canonical correctes | Chaque page a un canonical auto-référent | GSC + outil d’inspection d’URL | canonical pointant vers la mauvaise page |
| 10 | Couverture d’indexation cohérente | Nombre de pages indexées aligné sur le nombre de pages utiles | Rapport de couverture de la GSC | Pages pauvres indexées en masse |
Exemple de cas 2 : une page liste de produits B2B proposait 50 combinaisons de filtres, chacune générant une URL (/products?category=valve&material=steel). Google les a toutes indexées, et le nombre total de pages indexées est passé de 200 à 2 000. Résultat : le site a été jugé comme contenant beaucoup de contenu pauvre et dupliqué, sa note de qualité globale a baissé, et le classement des pages produit a reculé. Comment corriger : ajouter noindex aux URL de filtres à paramètres, ou les bloquer directement dans le robots.txt.
Un noindex mal configuré est l’erreur la plus fréquente et la plus grave. Pendant le développement, pour ne pas exposer le site de test à Google, l’équipe a ajouté un noindex dans le head de tout le site, puis a oublié de le retirer à la mise en ligne. Trois mois après le lancement, impossible de trouver le site officiel en cherchant la marque sur Google. Comment vérifier : après un crawl avec Screaming Frog, filtrez sur « Meta robots contains noindex » ; les pages définitives doivent renvoyer 0 résultat.
4. Axe rendu : 5 vérifications
Les sites modernes utilisent massivement le rendu JS (React, Vue, Next.js en rendu côté client). Googlebot sait exécuter le JS, mais pas en temps réel : il récupère d’abord le HTML brut et le met en file d’attente, puis l’exécute quelques jours plus tard via la file de rendu Chrome. Ce délai et les échecs de rendu sont le plus gros piège SEO des sites SPA.
| # | Point de contrôle | Critère de conformité | Outil | Questions fréquentes |
|---|---|---|---|---|
| 11 | Googlebot sait rendre le JS | L’outil d’inspection d’URL affiche « Rendu » | Outil d’inspection d’URL de la GSC | Une erreur JS fait échouer le rendu |
| 12 | Le contenu principal est dans le code HTML | title, H1 et premier paragraphe dans le HTML brut | Afficher le code source (pas F12) | Rendu 100 % côté client, code source vide |
| 13 | Aucune erreur de rendu dans la console | Aucune erreur dans la console Chrome DevTools | Chrome DevTools | Un appel API échoue et laisse le contenu vide |
| 14 | Les données structurées sont analysables | Aucune erreur dans le Rich Results Test | Test des résultats enrichis | Le JSON-LD est injecté dynamiquement en JS |
| 15 | Les balises hreflang sont correctes | Les pages multilingues se référencent correctement | GSC + outil de vérification hreflang | Boucle hreflang ou renvoi vers la mauvaise langue |
Point clé : utilisez « Afficher le code source » (Ctrl+U, pas F12) pour voir le HTML brut. Si le title, le H1 et le premier paragraphe sont déjà visibles dans le HTML brut, c’est du SSR ou du SSG : Google lit le contenu dès le premier passage. Si le HTML brut ne contient qu’un div#app et une série de balises script, c’est du rendu 100 % côté client (CSR) : Google devra attendre la file de rendu Chrome pour lire le contenu.
Sur les sites multilingues, les erreurs hreflang sont très courantes : une page allemande pointe vers une page anglaise, une page anglaise pointe vers elle-même, ou il manque un x-default. Pour la configuration, voir Hreflang et versions multilingues. Injecter les données structurées dynamiquement en JS : Google finit par les rendre, mais la file d’exploration les oublie souvent. Mieux vaut écrire le JSON-LD dans le HTML brut.Données structurées Schema Le processus de validation de ce point complète celui décrit ici.
5. Axe performance : 5 vérifications
La performance, ce sont les trois indicateurs clés des Core Web Vitals, plus l’utilisabilité mobile et le HTTPS. La performance ne se résume pas à « aller vite » : c’est un facteur de classement Google. Depuis 2021, les Core Web Vitals sont officiellement un signal de classement.
| # | Point de contrôle | Critère de conformité | Outil | Questions fréquentes |
|---|---|---|---|---|
| 16 | LCP (affichage du plus grand contenu) | ≤ 2,5 s | PageSpeed Insights + CrUX | Image du premier écran non compressée, police bloquante |
| 17 | INP (Interaction to Next Paint) | ≤ 200 ms | PageSpeed Insights + CrUX | Un script tiers bloque le thread principal |
| 18 | CLS (Cumulative Layout Shift) | ≤ 0,1 | PageSpeed Insights + CrUX | Images sans dimensions, emplacements publicitaires non réservés |
| 19 | Utilisabilité mobile | Aucune erreur de mise en page bloquante | Rapport d’utilisabilité mobile de la GSC | Éléments cliquables trop petits, défilement horizontal |
| 20 | HTTPS sans contenu mixte sur tout le site | Toutes les ressources passent en HTTPS | Console du navigateur + GSC | Des images/CSS pointent encore vers des liens HTTP |
Exemple 3 : sur un site B2B, PageSpeed relève un LCP de 4,2 s et un INP de 350 ms. Le diagnostic montre que la bannière du premier écran est un PNG de 3 Mo non compressé et que la page d’accueil charge 8 scripts de suivi tiers. Optimisation : conversion des images en WebP compressé à 200 Ko, chargement différé des scripts via Tag Manager. Deux semaines plus tard, le LCP tombe à 1,8 s et l’INP à 120 ms. Voir la méthode d’optimisation Optimiser les Core Web Vitals.
Priorité des performances : le LCP avant l’INP, l’INP avant le CLS. Si le LCP est mauvais, vérifiez d’abord les images du premier écran (compression, lazy loading, preload) et le TTFB, puis les ressources qui bloquent le rendu.Accélération mondiale par CDN Améliore directement le TTFB et le LCP des sites à l’étranger.
FAQ — Questions fréquentes
À quelle fréquence réaliser un audit SEO technique ?
Un taux d’indexation plus élevé est-il toujours préférable ?
Comment optimiser le SEO d’un site SPA React/Vue ?
Qu’est-ce que le budget d’exploration ? Comment savoir s’il est gaspillé ?
Comment optimiser rapidement un LCP insuffisant ?
Comment détecter et corriger un noindex défini par erreur ?
Pour conclure
L’audit de SEO technique est la fondation de tout travail SEO : même avec un contenu excellent et des backlinks coûteux, si Google ne peut pas explorer la page ou ne récupère qu’une coquille JS vide, tout est perdu. Les 20 points de contrôle ne sont pas une tâche ponctuelle, mais un passage obligé chaque trimestre.
Trois étapes concrètes : cette semaine, exportez les données du rapport de couverture et des statistiques d’exploration de la GSC et cochez les 20 points de contrôle un par un ; la semaine suivante, classez les points non conformes par priorité — corrigez d’abord l’exploration et l’indexation (critère éliminatoire), puis le rendu, et enfin les performances ; la troisième semaine, après correction, retestez avec l’outil d’inspection d’URL et PageSpeed.
Une phrase à retenir : le SEO technique n’est pas meilleur quand il est plus complexe, il est meilleur quand il est plus propre — Googlebot explore vite, indexe correctement, rend bien et tourne de façon stable ; ces quatre choses faites, le reste revient au contenu et aux backlinks.