Audit SEO technique : la checklist complète en 30 points

Un audit SEO technique répond à une seule question : Google peut-il explorer vos pages, les indexer et comprendre ce qu’elles contiennent ? Si ce n’est pas le cas, un excellent contenu reste invisible. Bonne nouvelle : l’essentiel se vérifie avec des outils gratuits, sans abonnement à une plateforme d’audit.

Voici la checklist que j’utilise, en 30 points regroupés par famille, de l’indexation aux données structurées. Pour chaque point : ce que vous devez constater, et l’outil gratuit qui permet de le vérifier. Sur ce site, une partie de ces contrôles est automatisée : un script les relance sur toutes les pages après chaque génération du site. J’y reviens à la fin.

Les outils gratuits qui suffisent pour l’audit

Exploration et indexation : Google peut-il lire vos pages ? (points 1 à 6)

• 1. Le fichier robots.txt ne bloque aucune page utile, ni les fichiers CSS et JavaScript nécessaires à l’affichage. Outil : rapport robots.txt de la Search Console.
• 2. Les pages à écarter de Google portent une balise noindex au lieu d’être bloquées dans le robots.txt. Outil : inspection d’URL.
• 3. Vos pages importantes (accueil, services, produits, guides) sont indexées. Outil : rapport Indexation des pages, puis inspection d’URL page par page.
• 4. Chaque motif de non-indexation est voulu : doublon, redirection, noindex volontaire, page supprimée. Outil : rapport Indexation des pages.
• 5. Le contenu principal apparaît dans la page telle que Google la voit, même s’il est chargé en JavaScript. Outil : inspection d’URL, « Tester l’URL active » puis « Afficher la page testée ».
• 6. Aucune action manuelle ni aucun problème de sécurité n’est signalé. Outil : rapports Actions manuelles et Problèmes de sécurité de la Search Console.

Le point 2 est le plus souvent mal compris. Google le rappelle : le robots.txt sert à gérer l’exploration, ce n’est pas un moyen de garder une page hors de Google. Une URL bloquée peut même apparaître dans les résultats, sans description. Pour écarter une page, l’aide de la Search Console conseille de retirer le blocage du robots.txt et d’utiliser noindex : Google doit pouvoir lire la page pour voir la balise.

Pour le point 4, ne visez pas zéro page exclue. Une URL non indexée n’est pas un problème quand la raison est légitime. Les deux statuts à surveiller sont « Détectée, actuellement non indexée » et « Explorée, actuellement non indexée » lorsqu’ils touchent des pages que vous jugez importantes. Dans ce cas, je regarde d’abord deux causes : une page trop peu reliée au reste du site, ou un contenu trop mince.

URL, canonical et doublons : une seule adresse par contenu (points 7 à 11)

• 7. Une seule version du site répond : https, avec ou sans www ; les trois autres variantes redirigent en 301 vers elle. Outil : votre navigateur, en saisissant les quatre adresses.
• 8. Chaque page indexable porte une seule balise canonical, dans le head, en URL absolue, qui pointe vers elle-même. Outil : code source, ou Screaming Frog pour tout le site.
• 9. Google retient la même URL canonique que vous. Outil : inspection d’URL, en comparant « URL canonique déclarée par l’utilisateur » et « URL canonique sélectionnée par Google ».
• 10. Les URL à paramètres (tri, filtres, suivi de campagne) ne créent pas de doublons indexés. Outil : rapport Indexation des pages, motifs « Page en double ».
• 11. Chaque page a un title et une meta description uniques, qui décrivent son contenu. Outil : Screaming Frog, filtres des doublons.

Pour Google, la balise canonical est un signal fort, comme une redirection, et il recommande des URL absolues plutôt que relatives. Un signal, pas un ordre : si vos indications se contredisent (canonical vers une adresse, liens internes vers une autre, sitemap vers une troisième), Google choisit lui-même. D’où l’intérêt du point 9. Pour les titres, la consigne de Google tient en une ligne : un title descriptif et concis sur chaque page, sans accumulation de mots-clés.

Redirections et codes HTTP : chaque URL répond juste (points 12 à 16)

• 12. Les anciennes URL (refonte, migration, changement de structure) redirigent en 301 vers la page équivalente la plus proche. Outil : Screaming Frog en mode liste, avec la liste de vos anciennes adresses.
• 13. Aucune chaîne de redirections : une ancienne URL mène à la page finale en un seul saut. Outil : Screaming Frog.
• 14. Les liens internes pointent directement vers l’URL finale, pas vers une adresse qui redirige. Outil : Screaming Frog, liens internes en 3xx.
• 15. Une page supprimée sans remplaçant renvoie un vrai code 404 ou 410, pas une page « introuvable » servie avec un code 200. Outil : rapport Indexation des pages, motif « Erreur soft 404 ».
• 16. Aucune erreur serveur (5xx) sur les pages importantes. Outil : rapport Indexation des pages et rapport Statistiques sur l’exploration.

Quand une URL change pour de bon, Google recommande une redirection permanente côté serveur (301 ou 308). Ses robots suivent jusqu’à 10 redirections successives, mais chaque saut ajoute un délai et un risque d’erreur : visez un seul saut. Pour les suppressions, la même page précise que tous les codes 4xx, sauf 429, sont traités de la même façon : l’URL sort de l’index.

Sur ce site, j’ai redirigé en 301 les adresses de l’ancien site vers leurs équivalents, et renvoyé un 410 pour les contenus retirés volontairement. Google traite le 410 comme un 404, mais le code dit clairement aux autres outils que la ressource a disparu de façon probablement permanente.

Sitemap et versions linguistiques (points 17 à 20)

• 17. Le sitemap XML ne contient que des URL canoniques, indexables, qui répondent en 200. Outil : rapport Indexation des pages filtré par sitemap.
• 18. Le sitemap est déclaré dans le robots.txt et envoyé dans la Search Console, avec l’état « Opération effectuée ». Outil : rapport Sitemaps.
• 19. Si le site existe en plusieurs langues, chaque version déclare en hreflang elle-même et toutes les autres, en URL complètes, et chaque lien est réciproque. Outil : code source, ou Screaming Frog, dont la version gratuite audite les hreflang.
• 20. Une version x-default est déclarée pour les visiteurs dont la langue ne correspond à aucune version. Outil : code source.

Un sitemap est limité à 50 000 URL ou 50 Mo non compressés : au-delà, il faut le découper. Pour les langues, la règle de Google est stricte : chaque version doit se citer elle-même et citer toutes les autres, et si deux pages ne pointent pas l’une vers l’autre, leurs balises sont ignorées. Ce site existe en français et en anglais : c’est précisément le genre d’erreur qu’un contrôle automatique attrape mieux qu’une relecture.

Performance, mobile et HTTPS (points 21 à 25)

• 21. Les Core Web Vitals sont « Bons » sur mobile et sur ordinateur : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1. Outil : rapport Core Web Vitals de la Search Console, PageSpeed Insights pour une page précise.
• 22. La version mobile contient le même contenu principal que la version ordinateur. Outil : inspection d’URL (capture de la page testée) et mode appareil de Chrome.
• 23. Les images sont compressées, dans un format moderne comme WebP ou AVIF, avec leurs dimensions indiquées dans le HTML. Outil : Lighthouse.
• 24. Les scripts tiers (chat, pixels, widgets) se limitent à ceux qui servent vraiment. Outil : Lighthouse et l’onglet Réseau de Chrome.
• 25. Tout le site est servi en HTTPS, sans URL HTTP indexée. Outil : rapport HTTPS de la Search Console.

Les seuils viennent de la documentation de Google, et ils s’apprécient au 75e percentile des chargements : il ne suffit pas qu’une visite sur deux soit rapide. Attention à la différence entre les deux outils : Lighthouse simule un chargement, alors que le rapport de la Search Console repose sur des données d’utilisation réelles. Un petit site peut n’y afficher aucune donnée ; PageSpeed Insights prend alors le relais, page par page.

Pour le mobile, Google indexe la version mobile de votre site : un contenu masqué ou absent sur mobile compte comme absent. Enfin, le rapport HTTPS rappelle que Google préfère indexer la version HTTPS quand une page existe dans les deux.

Données structurées et maillage interne (points 26 à 30)

• 26. Les données structurées ne contiennent aucune erreur critique. Outil : Test des résultats enrichis, puis rapports de résultats enrichis de la Search Console (rubrique Améliorations, et Extraits de produits pour une boutique).
• 27. Chaque type décrit ce que la page est vraiment et ce qu’elle montre au visiteur : pas de Product sur une page qui ne vend rien. Outil : relecture, validateur Schema.org.
• 28. Les images qui portent une information ont un texte alternatif descriptif. Outil : Lighthouse, partie accessibilité.
• 29. Chaque page indexable reçoit au moins un lien interne, sous la forme d’un vrai lien HTML (balise a avec un attribut href). Outil : crawl de Screaming Frog comparé à la liste du sitemap, rapport Liens de la Search Console.
• 30. Aucun lien interne ne mène à une page en erreur 404. Outil : Screaming Frog, filtre des codes 4xx.

Le point 29 compte plus qu’il n’y paraît : Google ne suit de façon fiable que les liens écrits avec une balise a et un attribut href. Un menu construit uniquement avec des événements JavaScript peut cacher la moitié du site. Pour le point 27, les consignes de Google exigent que les données structurées représentent fidèlement le contenu de la page. J’en ai fait l’expérience sur ce site : la Search Console a signalé une étude de cas balisée en Product. Je raconte la correction dans le guide sur les données structurées.

Automatiser les contrôles : ce que fait ce site à chaque génération

Un audit ponctuel vieillit vite : une modification de gabarit, un lien renommé, et une erreur revient sans bruit. Sur ce site, statique et sans dépendance, un script de contrôle relit toutes les pages après chaque génération : il doit finir sans aucune erreur avant la mise en ligne. Il vérifie notamment :

• une seule balise canonical par page, identique à l’adresse de la page ;
• des hreflang entre le français et l’anglais : chaque page se cite elle-même, le lien est réciproque, la page cible est dans la langue annoncée, et un x-default est présent ;
• aucun lien interne cassé, aucune ancre introuvable, aucune page indexable orpheline ;
• un seul h1 par page, aucun saut de niveau dans les titres, un attribut alt sur chaque image ;
• des title de 60 caractères au plus et des meta descriptions de 70 à 160 caractères, tous différents ;
• un seul bloc JSON-LD par page, lisible, avec un type sur chaque élément et des références (@id) qui mènent toutes à un élément défini ; un BlogPosting complet (image, dates, auteur) sur chaque guide, un Service et une FAQPage sur chaque page de service ;
• un sitemap qui contient toutes les pages indexables et aucune page en noindex, déclaré dans le robots.txt ;
• un robots.txt sans interdiction, où chacun des principaux robots de recherche et d’IA a sa propre section avec Allow: / ;
• un llms.txt et un llms-full.txt qui citent toutes les pages de service, études de cas et guides, sans lien mort ;
• les redirections de l’ancien site reprises dans la configuration de l’hébergement, et aucun en-tête noindex sur les pages en production ;
• le poids des deux pages d’accueil (française et anglaise), avec un budget de 150 Ko hors polices.

Ce que l’automatisation ne remplace pas : la Search Console. Mon script vérifie que le JSON-LD est valide, typé et cohérent ; il ne savait pas que Google demande offers, review ou aggregateRating pour afficher un Product en extrait de produit. C’est la Search Console qui l’a signalé. Le script empêche les régressions, la Search Console dit ce que Google pense de vos pages : il faut les deux.

Par où commencer : l’ordre des corrections

Les 30 points n’ont pas le même poids. Je traite les problèmes dans cet ordre :

1. Ce qui empêche l’indexation : robots.txt trop large, noindex oublié après une refonte, erreurs serveur, pages importantes absentes de l’index. Tant que ces points sont rouges, le reste ne sert à rien.
2. Ce qui disperse les signaux : doublons, canonical contradictoires, chaînes de redirections, liens internes vers des adresses redirigées.
3. Ce qui dégrade l’expérience : Core Web Vitals médiocres, version mobile incomplète, scripts tiers trop lourds.
4. Ce qui enrichit l’affichage : données structurées, textes alternatifs, maillage plus fin.

Ne courez pas après un score parfait dans chaque outil : corrigez d’abord ce qui touche vos pages qui comptent. Refaites l’audit complet après chaque refonte (le guide refonte sans perdre son référencement détaille ce moment), et suivez le reste chaque mois avec les rapports essentiels de la Search Console. Si vous voulez un regard extérieur sur votre site, ou mettre en place ce type de contrôle automatique, c’est le cœur de mon accompagnement SEO et web analytics.