Modèle de checklist d'audit SEO technique

Audit de crawlabilité et d'indexation

Vérifiez que les moteurs de recherche peuvent découvrir, explorer et indexer les bonnes pages, et rien d'autre.

Robots et directives d'exploration

• ☐ Confirmez que le robots.txt se résout sur le domaine racine et renvoie un statut 200, pas un 4xx/5xx.
• ☐ Vérifiez qu'aucune règle Disallow ne bloque le CSS, le JavaScript ou les répertoires de contenu importants nécessaires au rendu.
• ☐ Vérifiez que les hôtes de staging ou de développement sont bloqués de la production, et que la production n'est pas accidentellement interdite sur tout le site (['Disallow: /']).
• ☐ Confirmez qu'une référence de sitemap valide est déclarée dans le robots.txt.
• ☐ Passez en revue les meta robots et les en-têtes X-Robots-Tag pour repérer tout noindex ou nofollow involontaire sur des pages indexables.
• ☐ Assurez-vous que les pages que vous voulez indexer ne sont pas bloquées par le robots.txt (une URL interdite ne peut pas lire sa propre balise noindex).

Sitemaps XML

• ☐ Confirmez que le sitemap ne liste que des URL canoniques, indexables et en statut 200 : aucune redirection, aucun noindex, aucune URL bloquée.
• ☐ Vérifiez que le sitemap reste sous les limites par fichier (['50,000 URLs / 50 MB non compressé']) et utilise un index de sitemaps si nécessaire.
• ☐ Vérifiez que les URL utilisent des chemins https absolus et cohérents correspondant au domaine préféré.
• ☐ Soumettez le sitemap dans la Search Console et confirmez qu'il est lu sans erreur.
• ☐ Rapprochez le nombre d'URL du sitemap du nombre d'URL indexées et enquêtez sur les écarts importants.

Canonicalisation

• ☐ Confirmez que chaque page indexable déclare une canonique auto-référente (URL absolue).
• ☐ Vérifiez que les balises canoniques pointent vers des URL actives en statut 200, pas vers des redirections ou des 404.
• ☐ Vérifiez l'absence de signaux contradictoires (canonique vs. noindex, canonique vs. hreflang, canonique vs. sitemap).
• ☐ Assurez-vous que les variantes à paramètres, à facettes, paginées et à session-ID se canonicalisent correctement.
• ☐ Confirmez qu'une seule version d'URL est canonique parmi les variantes http/https, www/non-www et avec barre oblique finale.

Couverture de l'index

• ☐ Consultez le rapport Indexation des pages de la Search Console et triez chaque motif de Non indexée.
• ☐ Enquêtez sur Explorée, actuellement non indexée et Détectée, actuellement non indexée pour des problèmes de qualité ou de budget d'exploration.
• ☐ Résolvez les motifs Page en double sans URL canonique sélectionnée par l'utilisateur et Autre page avec balise canonique correcte.
• ☐ Utilisez l'Inspection d'URL pour confirmer le HTML rendu, la canonique et l'indexabilité des principaux modèles.
• ☐ Vérifiez les logs serveur ou le rapport Statistiques d'exploration pour repérer les pics de réponses 4xx/5xx et le gaspillage d'exploration.
• ☐ Confirmez que les pages importantes sont accessibles via des liens internes, pas uniquement via le sitemap.

Audit d'architecture du site et de maillage interne

Assurez-vous que vos pages les plus importantes sont peu profondes, bien maillées et reçoivent le jus de liens interne.

Profondeur d'exploration et structure

• ☐ Lancez une exploration complète depuis la page d'accueil et enregistrez la profondeur de clic de chaque URL.
• ☐ Confirmez que les pages prioritaires se situent à une faible profondeur de la page d'accueil (['3 clics ou moins']).
• ☐ Repérez les pages profondes enfouies derrière la pagination, les filtres ou des pages hub légères et aplatissez la structure là où c'est pertinent.
• ☐ Vérifiez une hiérarchie d'URL logique et cohérente qui reflète les sections du site.
• ☐ Confirmez que la navigation principale et le pied de page exposent les principales catégories et les pages commerciales clés.

Pages orphelines et sans issue

• ☐ Croisez les données d'exploration avec le sitemap et les données analytics/logs pour trouver les pages orphelines (URL sans lien interne entrant).
• ☐ Ajoutez des liens internes contextuels pour récupérer un contenu orphelin de valeur, ou supprimez/redirigez les orphelines à faible valeur.
• ☐ Repérez les pages sans issue avec peu ou pas de liens internes sortants et ajoutez des liens pertinents.
• ☐ Confirmez que les pages paginées et filtrées exposent toujours des chemins d'exploration vers les éléments sous-jacents.

Jus de liens et texte d'ancre

• ☐ Cartographiez le nombre de liens internes entrants et signalez les pages à forte valeur qui sont sous-maillées.
• ☐ Réduisez les liens pointant vers des URL à faible valeur (connexion, panier, pages utilitaires) qui diluent le jus de liens.
• ☐ Utilisez un texte d'ancre descriptif, varié et pertinent par rapport aux mots-clés plutôt que le générique cliquez ici.
• ☐ Confirmez que les liens internes importants sont des éléments <a href> explorables, et non de simples gestionnaires de clic JavaScript.
• ☐ Corrigez les liens internes qui passent par des redirections ou aboutissent à des 404 afin que le jus circule directement.

Fil d'Ariane et pages hub

• ☐ Implémentez un fil d'Ariane sur les modèles profonds et balisez-le avec des données structurées BreadcrumbList.
• ☐ Assurez-vous que les liens du fil d'Ariane sont de vraies ancres et reflètent la véritable hiérarchie du site.
• ☐ Construisez ou renforcez des pages hub/catégorie qui renvoient vers du contenu de cluster connexe.
• ☐ Confirmez que les modules de contenu connexe et contextuel relient latéralement des pages thématiquement pertinentes.

Audit des Core Web Vitals et des performances

Diagnostiquez et priorisez les problèmes de vitesse et de stabilité de page qui nuisent à l'expérience utilisateur et au classement.

Données de terrain et diagnostic

• ☐ Consultez le rapport Core Web Vitals de la Search Console et notez les groupes d'URL en échec sur mobile et desktop.
• ☐ Privilégiez les données de terrain (utilisateurs réels) aux scores de laboratoire ; n'utilisez les outils de laboratoire que pour reproduire et déboguer.
• ☐ Confirmez les cibles : LCP à ou sous ['2.5s'], INP à ou sous ['200ms'], CLS à ou sous ['0.1'] au 75e centile.
• ☐ Auditez des modèles représentatifs (accueil, catégorie, produit/article) plutôt que la seule page d'accueil.

Largest Contentful Paint (LCP)

• ☐ Identifiez l'élément LCP sur chaque modèle clé et confirmez qu'il se charge tôt.
• ☐ Préchargez l'image ou la police du LCP et évitez le lazy-loading des médias au-dessus de la ligne de flottaison.
• ☐ Servez les images hero dans des formats modernes, aux bonnes dimensions et avec un srcset responsive.
• ☐ Réduisez le temps de réponse serveur (TTFB) via la mise en cache et un CDN.

Interaction to Next Paint (INP)

• ☐ Fractionnez les longues tâches JavaScript et différez les scripts non critiques.
• ☐ Minimisez le travail du thread principal issu des balises tierces, des outils d'A/B et des widgets de chat.
• ☐ Supprimez le JavaScript et le CSS inutilisés et fractionnez les gros bundles par code-splitting.
• ☐ Testez de vraies interactions (appuis, ouvertures de menu, saisies de formulaire) sur un mobile de milieu de gamme.

Cumulative Layout Shift (CLS)

• ☐ Définissez une largeur et une hauteur explicites (ou aspect-ratio) sur les images, vidéos et intégrations.
• ☐ Réservez de l'espace pour les publicités, bannières et contenus injectés dynamiquement.
• ☐ Préchargez les polices web et utilisez font-display pour limiter les décalages liés aux changements de texte.
• ☐ Évitez d'insérer du contenu au-dessus d'un contenu existant après le chargement.

Diffusion, mise en cache et mobile

• ☐ Éliminez le CSS/JS bloquant le rendu et n'inlinez que le CSS critique.
• ☐ Activez la compression de texte (gzip/Brotli) et des en-têtes de cache longue durée pour les ressources statiques.
• ☐ Vérifiez que HTTP/2 ou HTTP/3 et un CDN diffusent les ressources au plus près des utilisateurs.
• ☐ Confirmez que la mise en page mobile est responsive, avec des cibles tactiles et des tailles de police adaptées au toucher.
• ☐ Retestez après chaque correctif et surveillez les données de terrain sur une fenêtre de collecte complète avant de déclarer le succès.

Audit des données structurées et des résultats enrichis

Validez que votre balisage schema est exact, éligible et obtient les résultats enrichis auxquels il a droit.

Couverture du schema et choix des types

• ☐ Inventoriez quels modèles ont des données structurées et à quels modèles éligibles elles manquent.
• ☐ Associez chaque page aux types appropriés (['Article, Product, FAQPage, BreadcrumbList, Organization, LocalBusiness']).
• ☐ Privilégiez le JSON-LD placé dans le code source de la page et conservez un format de balisage cohérent par page.
• ☐ Implémentez une entité Organization ou de niveau site avec logo et profils sameAs là où c'est pertinent.

Règles d'exactitude et d'éligibilité

• ☐ Confirmez que le contenu balisé est visible pour les utilisateurs sur la page : aucune donnée cachée ou présente uniquement dans le balisage.
• ☐ Incluez toutes les propriétés requises pour chaque type et ajoutez les propriétés recommandées pour renforcer l'éligibilité.
• ☐ Assurez-vous que les valeurs sont exactes et à jour (prix, disponibilité, notes, dates) et reflètent le contenu de la page.
• ☐ N'utilisez le balisage review/rating que pour de véritables avis présents sur la page et respectez les règles actuelles sur les avis autopromotionnels.
• ☐ Confirmez que les références d'entité et les ID sont cohérents entre les blocs de balisage liés.

Validation et tests

• ☐ Passez chaque modèle clé au Test des résultats enrichis et à un validateur de schema.
• ☐ Corrigez toutes les erreurs signalées et résolvez les avertissements qui bloquent les améliorations.
• ☐ Testez le HTML rendu, car une partie du balisage est injectée par JavaScript après le chargement.
• ☐ Contrôlez par sondage plusieurs URL réelles par modèle, pas un seul exemple.

Surveillance et maintenance

• ☐ Suivez chaque type de résultat enrichi dans les rapports Améliorations de la Search Console pour repérer les nouvelles erreurs.
• ☐ Mettez en place des alertes ou une vérification récurrente après les changements de modèle, de CMS ou de plugin.
• ☐ Revalidez lorsque les consignes changent ou qu'une fonctionnalité est abandonnée.
• ☐ Tenez un journal indiquant quels modèles émettent quels types de schema et qui en est responsable.

Audit SEO international

Assurez-vous que la bonne version linguistique et régionale de chaque page est servie et indexée pour la bonne audience.

Mise en œuvre du hreflang

• ☐ Confirmez que chaque page d'un ensemble langue/région renvoie vers toutes les variantes, y compris un hreflang auto-référent.
• ☐ Vérifiez que les balises de retour sont bidirectionnelles : chaque variante renvoie vers les autres (aucune référence unilatérale).
• ☐ Utilisez des codes de langue valides et des codes de région optionnels (['en, en-GB, es-MX']) au format ISO.
• ☐ Incluez une balise x-default pour le repli global/sélecteur de langue.
• ☐ Choisissez une méthode de diffusion (en-tête HTML, en-tête HTTP ou sitemap) et appliquez-la de façon cohérente.
• ☐ Faites pointer les URL hreflang vers des pages actives, indexables et canoniques en statut 200, jamais vers des redirections ou des pages noindex.

Interaction entre canonique et indexation

• ☐ Assurez-vous que chaque URL localisée est auto-canonique, et non canonicalisée vers une autre version linguistique.
• ☐ Confirmez que le hreflang et la canonique ne se contredisent pas sur la même page.
• ☐ Vérifiez que les pages localisées quasi dupliquées ne sont pas regroupées sous une seule canonique.
• ☐ Vérifiez que les pages localisées figurent dans leurs propres sitemaps avec les bonnes références de variantes.

Ciblage géographique et structure d'URL

• ☐ Confirmez une structure claire et évolutive pour les langues/régions (ccTLD, sous-domaine ou sous-répertoire) et appliquez-la de façon cohérente.
• ☐ Définissez un ciblage par pays là où c'est pertinent et alignez-le sur votre stratégie d'URL.
• ☐ Évitez les redirections automatiques basées sur l'IP qui bloquent les robots ou piègent les utilisateurs dans la mauvaise version ; préférez une bannière ou un sélecteur de langue.
• ☐ Localisez le contenu de manière pertinente (devise, unités, coordonnées, orthographe) plutôt que de dupliquer une seule langue.

Validation

• ☐ Explorez le site avec le reporting hreflang activé et résolvez les balises de retour manquantes ou cassées.
• ☐ Utilisez l'outil d'Inspection d'URL pour confirmer comment les variantes sont détectées.
• ☐ Contrôlez par sondage plusieurs locales pour vérifier le rendu, l'indexabilité et la diffusion corrects.
• ☐ Réauditez après l'ajout de nouvelles locales ou de nouveaux modèles.

Audit de migration / refonte du site

Protégez le classement et le trafic avant, pendant et après une migration ou une refonte en vérifiant les redirections et la parité.

Préparation avant lancement

• ☐ Explorez le site en ligne et exportez, comme référence, un inventaire complet des URL indexables, titres, métadonnées et codes de statut.
• ☐ Enregistrez les performances de référence : principales pages de destination organiques, classements, trafic, conversions et couverture d'index.
• ☐ Confirmez que le site de staging est bloqué à l'indexation et protégé (authentification ou liste d'IP autorisées), mais vérifiez que les directives seront retirées au lancement.
• ☐ Construisez une carte de redirection complète de chaque ancienne URL vers son équivalent le plus proche.
• ☐ Préparez les nouveaux sitemaps XML, le robots.txt et les propriétés analytics/Search Console pour la nouvelle structure.

Cartographie des redirections

• ☐ Utilisez des redirections permanentes 301 pour les URL modifiées et évitez les 302 pour les déplacements permanents.
• ☐ Faites correspondre les anciennes URL une à une vers les nouvelles pages pertinentes ; évitez les redirections en masse vers la page d'accueil.
• ☐ Éliminez les chaînes et boucles de redirection pour que chaque ancienne URL se résolve en un seul saut.
• ☐ Conservez ou migrez le hreflang, la canonique et les données structurées vers les nouvelles URL.
• ☐ Prévoyez le cas des anciens paramètres, des fichiers média et de toute URL disposant de backlinks externes.

Parité de contenu et technique

• ☐ Vérifiez que les titres, meta descriptions, titres de section, contenu du corps et images ont été repris ou améliorés.
• ☐ Confirmez que les liens internes pointent directement vers les nouvelles URL, et non via des redirections.
• ☐ Vérifiez que les balises canoniques, les données structurées et le hreflang sont corrects sur les nouveaux modèles.
• ☐ Comparez les Core Web Vitals et la vitesse des pages clés avant et après pour détecter les régressions.

Validation au lancement et après lancement

• ☐ À la mise en ligne, retirez les blocages noindex/robots du staging et confirmez que le site de production est explorable.
• ☐ Soumettez les nouveaux sitemaps et utilisez l'Inspection d'URL pour demander l'indexation des pages prioritaires.
• ☐ Ré-explorez le nouveau site pour confirmer que les redirections se résolvent, qu'aucun 404 critique n'existe et qu'aucun modèle n'émet de noindex involontaire.
• ☐ Surveillez quotidiennement la couverture d'index, les statistiques d'exploration, les classements et le trafic durant les premières semaines et guettez les baisses durables.
• ☐ Maintenez les redirections à long terme et corrigez tout chemin cassé nouvellement découvert.

À quelle fréquence dois-je réaliser un audit SEO technique ?

Pour la plupart des sites, un audit technique complet chaque trimestre fonctionne bien, associé à une surveillance continue entre-temps. Les grands sites qui changent souvent (gros e-commerces ou éditeurs de presse) tirent parti de plongées approfondies mensuelles, tandis que les petits sites stables peuvent souvent attendre six mois. Au-delà du calendrier, lancez toujours le module d'audit pertinent après tout événement majeur : une migration, une refonte, un changement de CMS ou une mise à jour de modèle, car c'est à ces moments que les problèmes techniques sont introduits.

Quelle est la différence entre un audit et une surveillance continue ?

Un audit est un examen complet à un instant donné, où vous inspectez systématiquement la crawlabilité, l'architecture, la performance, les données structurées et davantage pour trouver et prioriser les problèmes. La surveillance est la couche continue et automatisée qui guette les nouveaux problèmes entre les audits, en suivant la couverture d'index, les liens cassés, les pics de codes de statut, les Core Web Vitals et les erreurs de données structurées pour que les régressions apparaissent vite. Les audits fixent le cap et révèlent les problèmes profonds ; la surveillance attrape vite les nouveaux. Vous avez besoin des deux.

Les Core Web Vitals sont-ils un facteur de classement ?

Oui. Les Core Web Vitals font partie des signaux d'expérience de page de Google et peuvent influencer le classement, surtout comme critère de départage entre des pages de pertinence et de qualité similaires. Ils ne sont pas une solution miracle (un contenu pertinent et utile reste le facteur dominant), alors traitez les Core Web Vitals comme un signal d'expérience utilisateur et de classement important à bien maîtriser, et non comme un substitut à la qualité du contenu et à la santé globale du site.

Google interprète-t-il le JavaScript, et pourquoi est-ce important pour un audit ?

Google peut interpréter le JavaScript, mais le rendu se fait lors d'une seconde passe après l'exploration initiale et dépend de la crawlabilité des ressources. Si du contenu critique, des liens internes, des canoniques ou des données structurées n'apparaissent qu'après l'exécution du JavaScript côté client, ils peuvent être découverts tardivement ou manqués si les scripts sont bloqués ou échouent. Lors d'un audit, vérifiez toujours le DOM rendu en plus du HTML brut et confirmez que votre robots.txt autorise le JavaScript et le CSS nécessaires au rendu.

Quels problèmes techniques dois-je corriger en premier ?

Priorisez tout ce qui bloque l'exploration ou l'indexation des pages importantes : balises noindex accidentelles, règles disallow trop larges dans le robots.txt, canoniques cassées ou contradictoires, erreurs serveur (5xx) et chaînes ou boucles de redirection. Elles peuvent retirer entièrement des pages de la recherche, elles priment donc sur les correctifs cosmétiques. Après avoir levé les bloqueurs d'exploration et d'indexation, descendez par gravité à travers l'architecture du site, les Core Web Vitals, les données structurées et les problématiques internationales.

Combien de temps après la correction des problèmes verrai-je des résultats ?

Cela varie selon le problème et la rapidité avec laquelle les moteurs de recherche ré-explorent les pages concernées. La levée d'un bloqueur d'indexation peut se refléter en quelques jours pour les URL prioritaires que vous demandez via l'Inspection d'URL, tandis que des changements étendus sur un grand site peuvent prendre des semaines, le temps que la ré-exploration s'achève. Les métriques de terrain comme les Core Web Vitals ne se mettent à jour qu'après le passage d'une fenêtre complète de collecte de données, attendez-vous donc à un délai avant que les améliorations n'apparaissent dans ces rapports. Ré-explorez, validez et surveillez plutôt que de présumer un changement instantané.