SEO technique : la checklist ultime pour auditer son site

Un titre réécrit, une méta description plus vendeuse, trois articles publiés. Et le trafic qui ne bouge pas d'un pixel. Je connais cette situation, je l'ai vécue sur un site de conseil B2B il y a deux ans : six semaines de travail éditorial, aucun résultat. Le problème n'était pas le contenu. Il était trois crans plus bas : Google ne parvenait pas à lire correctement la moitié du site. Une balise noindex oubliée sur un modèle de page, un sitemap qui listait des URL en 301, un rendu JavaScript qui renvoyait du vide aux robots. Trois lignes de code, six semaines perdues.

C'est pour cette raison que je place toujours l'audit SEO technique avant toute autre chose. Pas parce que c'est plus noble que le contenu. Parce que corriger une redirection cassée demande dix minutes, alors que réécrire vingt articles pour rien demande trois semaines. Encore faut-il une checklist qui ne se contente pas de cocher des cases : une checklist qui hiérarchise.

Une checklist d'audit SEO technique qui sert vraiment à quelque chose

La plupart des checklists que je croise sur le web comptent cinquante points, tous au même niveau, sans hiérarchie. Résultat : on coche les faciles (balises title, alt d'images) et on repousse indéfiniment les difficiles (rendu JS, budget de crawl). Sauf que les difficiles sont ceux qui bloquent l'indexation.

Ma méthode tient en quatre étapes, dans cet ordre strict. Chaque étape ne démarre que si la précédente est propre.

Étape 1 : vérifier l'accès et le contrôle

Avant de parler de performance ou de contenu, il faut s'assurer que les robots peuvent entrer. Ça paraît évident. Ça ne l'est jamais.

• Le fichier robots.txt ne bloque rien d'important (une ligne Disallow: / oubliée après une mise en maintenance arrive plus souvent qu'on ne le croit)
• Les balises noindex sont-elles bien absentes des pages stratégiques ?
• Le site répond-il en HTTPS sur toutes les variantes (avec et sans www, http et https) ?
• Les redirections 301 sont-elles en une seule étape, sans chaîne ?
• Le sitemap XML est à jour et ne contient que des URL en 200

J'ai déjà trouvé, sur un site client, une chaîne de quatre redirections successives sur la page d'accueil. Quatre. Chaque clic ramenait le robot un peu plus loin. En corrigeant, on a récupéré environ un tiers des pages qui traînaient en « Découverte, actuellement non indexée » dans Search Console.

Étape 2 : croiser crawl et indexation

Search Console donne des symptômes. Elle ne donne jamais le diagnostic. Une page marquée « Explorée, actuellement non indexée » peut l'être pour six raisons différentes : contenu trop mince, canonical pointant ailleurs, paramètre d'URL dupliqué, rendu JS vide, blocage robots, ou simplement absence de maillage interne.

Le croisement utile, c'est : liste des URL crawlées contre liste des URL indexées. La différence, c'est votre chantier. Sur un site de 400 pages que j'ai audité l'an dernier, l'écart était de 180 URL. Sur ces 180, 140 étaient des pages de paramètres de filtre générées automatiquement par un module e-commerce. Une seule balise canonical correctement posée a réglé le problème en une journée.

Concrètement, vérifiez aussi :

• La cohérence des balises canonical (auto-référentes sur les pages de contenu, cohérentes sur les versions paginées)
• L'absence de contenu dupliqué entre versions mobile/desktop ou entre sous-domaines
• Le maillage interne : combien de clics séparent une page profonde de l'accueil ? Au-delà de trois, c'est souvent le signe d'un problème de structure
• Le comportement des balises hreflang si le site est multilingue

Étape 3 : vérifier le rendu JavaScript

Voilà le point que je vois le plus souvent négligé, et de loin.

Un site React, Next.js ou Vue qui charge son contenu côté client peut paraître parfait dans votre navigateur et renvoyer une coquille vide au robot. Google sait exécuter le JavaScript, mais il le fait dans un second passage, avec un budget limité. Si votre contenu arrive après trois appels API et deux secondes d'attente, il y a de bonnes chances pour qu'il ne soit jamais vu.

Le test simple : désactivez JavaScript dans votre navigateur, puis ouvrez trois ou quatre pages clés. Si le contenu principal disparaît, vous avez un problème. Pas forcément fatal, mais à traiter en priorité si ces pages comptent.

Deuxième vérification, plus récente et souvent oubliée : les robots des assistants conversationnels. Depuis que les gens posent leurs questions à un modèle plutôt qu'à un moteur de recherche classique, la question du crawl par ces agents devient concrète. Aucun standard ne s'est imposé, mais un fichier llms.txt à la racine, qui résume la structure du site en texte brut, commence à être lu par certains d'entre eux. Ça ne coûte rien à mettre en place.

Étape 4 : performance et Core Web Vitals

Les seuils à connaître, une fois pour toutes :

Métrique	Seuil « bon »	Ce qu'elle mesure
LCP	< 2,5 s	Temps d'affichage du plus gros élément visible
INP	< 200 ms	Réactivité aux interactions
CLS	< 0,1	Stabilité visuelle (sauts de mise en page)

Le LCP est presque toujours ralenti par la même chose : une image mal dimensionnée en haut de page, chargée sans priorité. Ajouter fetchpriority="high" sur l'image héro et passer le reste en lazy loading règle une bonne partie des cas. Ce n'est pas de la magie, c'est de la mécanique.

Le CLS, lui, vient souvent des polices web ou des bannières publicitaires insérées sans réserver d'espace. Réservez la hauteur dans le CSS, et le score remonte.

Comment prioriser quand tout semble cassé

Un audit qui remonte 80 problèmes ne sert à rien si vous ne savez pas par lequel commencer. J'utilise un scoring simple, à deux axes : impact estimé (sur l'indexation ou le trafic) et effort de correction (en heures de dev).

Un exemple concret de mon dernier audit, sur un site vitrine de 200 pages :

• Impact fort, effort faible : balise canonical dupliquée sur 60 pages, corrigée en 2 heures → traité en premier
• Impact fort, effort moyen : refonte du maillage interne des catégories → planifié sur 3 semaines
• Impact faible, effort faible : compression des images secondaires → traité en batch
• Impact faible, effort fort : migration du CMS → reporté sine die, rien ne le justifiait

Cette grille m'a évité, plus d'une fois, de partir sur un chantier de refonte technique alors que trois corrections ciblées suffisaient. Avouons-le : on aime les refontes. Elles sont visibles, elles font un beau compte rendu. Elles sont rarement la bonne réponse.

Quels outils, et à quelle fréquence réauditer ?

Trois familles d'outils, trois usages différents. Inutile d'en empiler dix.

Search Console pour la vérité côté Google. Un crawler (Screaming Frog, Sitebulb ou équivalent) pour voir le site comme un robot le voit, à grande échelle. Et PageSpeed Insights pour les Core Web Vitals, avec la distinction utile entre données de terrain et données de laboratoire.

Pour la cadence : un audit complet tous les six mois sur un site stable. Immédiatement après une refonte, une migration ou un changement de CMS. Et une vérification mensuelle des seuls indicateurs critiques : pages indexées, erreurs de crawl, Core Web Vitals.

Une erreur que j'ai faite, tôt dans ma pratique : lancer un audit complet tous les mois. Résultat, je passais mon temps à cocher des cases vertes et je ne voyais plus ce qui changeait vraiment. Le suivi mensuel doit être étroit, l'audit complet doit rester un événement.

Les questions qu'on me pose le plus souvent

Combien de temps prend un audit SEO technique complet ?

Sur un site de moins de 500 pages, comptez une journée pour le crawl et l'analyse, puis deux à trois jours pour la rédaction du rapport et la priorisation. Au-delà de 5 000 URL, prévoyez une semaine, essentiellement à cause du rendu JavaScript et du budget de crawl qu'il faut analyser page par page.

Un audit SEO gratuit automatisé suffit-il ?

Non, et il faut le dire clairement. Un audit automatique détecte les symptômes (balises manquantes, images sans alt, redirections en chaîne) mais jamais la cause. Il vous dira que 40 pages ne sont pas indexées. Il ne vous dira pas que c'est parce que votre canonical pointe vers une version de test oubliée en production. C'est précisément le travail d'analyse qui compte.

Peut-on faire un audit SEO technique sans être développeur ?

Oui pour les deux tiers. Le crawl, l'analyse de Search Console, la vérification des redirections et des canonical se font sans écrire une ligne de code. Le tiers restant (rendu JavaScript, réglages serveur, optimisation du LCP) nécessite l'accès au code ou un développeur. Un bon audit identifie précisément ce qui doit passer par la case technique, avec des instructions assez claires pour être exécutées sans réunion supplémentaire.

Ce qui reste après avoir coché la liste

Une checklist, même bien construite, ne vous dira jamais une chose : si votre site mérite d'être indexé. Elle vérifie que Google peut le lire. Elle ne vérifie pas qu'il y a quelque chose à lire.

La question que je me pose à la fin de chaque audit technique, et à laquelle aucun outil ne répond : si un robot parfaitement obéissant venait de crawler l'intégralité de votre site, est-ce qu'il aurait appris quelque chose ? Si la réponse est non, les balises canonical et le sitemap ne vous sauveront pas. Ils rendront juste la chute plus propre.

Le technique, c'est le plancher. Ce qui se joue au-dessus, c'est une autre histoire.