Un site perd 40 % de son trafic organique sur le core update de mars 2026 : par où commencer le diagnostic technique avant de toucher au contenu ?
Avant de juger la qualité éditoriale, Google évalue le SEO technique d’un site dans un ordre précis : exploration, indexation, rendu, performance, puis données structurées. Cette séquence sert de protocole sur un nouveau mandat, du jour 1 au mois 1, sans repasser par 10 onglets différents pour retrouver ce qui a déjà été contrôlé.
La check-list générique à 50 points qui circule depuis des années ne dit pas quoi corriger en premier quand tout semble urgent sur un audit initial. Ce guide reprend l’ordre documenté par Google lui-même, avec des seuils chiffrés à jour pour 2026, pour un premier passage en SEO technique qui priorise plutôt qu’il ne coche des cases.
Ce qu’il faut avoir avant de commencer
Le diagnostic suppose un minimum d’accès réunis avant la première vérification.
- La propriété Search Console vérifiée sur le domaine, en accès propriétaire complet.
- Un accès CMS ou un contact développeur capable d’appliquer un correctif dans la semaine.
- Un export des 90 derniers jours de trafic organique, utile pour dater une chute face à un core update.
Sans Search Console déjà configurée sur le site, direction d’abord les solutions gratuites de reporting SEO avant de continuer.
Vérifier que Google peut explorer le site
Le crawl budget, c’est-à-dire le nombre de pages que Googlebot accepte d’explorer sur une période donnée, ne concerne pas la majorité des sites. Google réserve la gestion active de ce budget à deux profils : les sites de plus d’un million de pages uniques dont le contenu change au moins une fois par semaine et les sites de plus de 10 000 pages dont le contenu change quotidiennement.
Google Search Central précise que la plupart des sites n’ont pas besoin de se préoccuper de la gestion du budget de crawl (documentation Crawl Budget Management for Large Sites, 2025).
Ce qui compte pour un premier diagnostic reste plus simple : le fichier robots.txt ne doit bloquer aucune ressource nécessaire au rendu (CSS, JS) et le sitemap XML doit afficher un statut « Réussite » dans Search Console. Son existence sur le serveur ne garantit rien. Le guide complet sur robots.txt détaille les directives propres aux bots IA comme GPTBot ou ClaudeBot, à traiter séparément de Googlebot.
Erreur courante sur les sites migrés depuis un environnement de recette : un robots.txt hérité bloque encore /wp-admin/ ou une règle générique trop large qui coupe aussi des URLs de contenu légitimes. Corrigez avant de continuer.
Contrôler l’indexation et le rendu des pages
Le rapport Pages de Search Console distingue les URLs indexées des URLs exclues, avec un motif par exclusion. 3 motifs reviennent le plus souvent sur un premier audit : « Explorée, actuellement non indexée » signale un contenu vu mais jugé pas assez différenciant, « Autre page avec balise canonique correcte » reste en général un signal normal et « Détectée, actuellement non indexée » indique que Google connaît l’URL sans avoir encore alloué de ressource pour la crawler.
Sur un site en React ou Vue sans rendu serveur, une partie du contenu peut n’apparaître qu’après une seconde passe de rendu, ce que Google appelle la deuxième vague d’indexation. Cette étape retarde l’indexation de plusieurs jours à plusieurs semaines selon le rendering budget alloué au domaine. L’article dédié au rendu serveur avec Next.js détaille l’impact du choix entre SSR et CSR sur ce délai.
Vérifiez ensuite l’aspect visuel avec l’outil d’inspection d’URL de Search Console : la vue « rendu » doit afficher le contenu principal déjà chargé, sans coquille vide en attente de JavaScript.
Passer les Core Web Vitals
3 métriques composent les Core Web Vitals depuis mars 2024 : le LCP mesure le temps de chargement du plus grand élément visible, l’INP mesure le délai entre une interaction et l’affichage du résultat et le CLS mesure la stabilité visuelle pendant le chargement. L’INP a remplacé le First Input Delay le 12 mars 2024, un changement que certains sites n’ont toujours pas intégré dans leur suivi.
| Métrique | Ce qu’elle mesure | Seuil « bon » (75e percentile) |
|---|---|---|
| LCP | Temps de chargement du plus grand élément visible | 2,5 secondes |
| INP | Délai entre une interaction et l’affichage du résultat | 200 millisecondes |
| CLS | Stabilité visuelle pendant le chargement | 0,1 |
Ces seuils, mesurés au 75e percentile des visites réelles du Chrome User Experience Report (documentation Core Web Vitals de Google, 2026), s’appliquent donc à 75 % des visiteurs réels. Une moyenne ne suffit pas.
Le rapport PageSpeed Insights donne un score de laboratoire utile pour déboguer. Seul le rapport Core Web Vitals de Search Console reflète les données de terrain qui comptent pour le classement. Un LCP correct en laboratoire et mauvais sur le terrain signale souvent un problème réseau chez une partie des visiteurs plutôt qu’un défaut de code. 12 réglages WordPress pour améliorer ces métriques couvrent les corrections les plus fréquentes sur ce CMS.
Structurer les données pour Google et pour les IA
Le balisage schema.org ne garantit aucun rich snippet. Il aide Google à rattacher une page à une entité précise dans son knowledge graph plutôt qu’à un ensemble de mots-clés isolés. C’est la logique de l’entity SEO : associer une page à une entité identifiable, avec les mêmes identifiants d’une page à l’autre du site.
Le leak de l’API Content Warehouse, publié par Rand Fishkin sur SparkToro le 27 mai 2024, a confirmé l’existence de NavBoost, un système qui réordonne les résultats à partir du comportement de clic observé, en distinguant un clic qui reste sur la page de celui qui repart aussitôt vers un autre résultat. Une page bien balisée en schema.org obtient souvent un extrait plus lisible dans les résultats, ce qui joue directement sur ce comportement avant même de parler de position moyenne.
Priorisez le balisage Article, Organization et Product selon le type de page. Le balisage FAQPage a perdu son intérêt après la suppression du rich result associé sur les sites non officiels, un changement détaillé dans l’article dédié à cette suppression. Ces chiffres proviennent de la documentation officielle et d’un leak vérifié, une base plus solide qu’un article recopié d’un blog à l’autre, ce qui change la nature du diagnostic à mener sur un nouveau site.
Préparer le site pour les surfaces génératives
Un site techniquement propre pour Googlebot ne l’est pas forcément pour les moteurs génératifs. L’optimisation de ces surfaces porte deux noms qui se chevauchent. Le GEO (Generative Engine Optimization) vise la visibilité dans les réponses de ChatGPT et Perplexity, quand l’AEO (Answer Engine Optimization) cible les AI Overviews et l’AI Mode de Google. Les deux s’appuient sur la même base technique que le SEO classique, avec quelques vérifications en plus.
Le fichier llms.txt, à la racine du domaine, liste les pages qu’un agent IA devrait privilégier pour comprendre le site. Il ne remplace pas robots.txt et n’a aucun statut officiel chez Google à ce jour. Une étude Ahrefs menée sur 137 210 domaines montre que 28 % publient déjà ce fichier, mais que 97 % d’entre eux n’ont reçu aucune requête d’un bot IA en mai 2026 : GPTBot et les crawlers de récupération privilégient largement le HTML classique. Le déployer coûte quelques minutes et ne fait de mal à personne, mais il ne dispense pas de rendre le contenu lui-même exploitable. Le contenu doit aussi répondre dès les premières lignes à la question posée, le format answer-first attendu quand une requête déclenche un query fanout, cette décomposition d’une question complexe en plusieurs sous-requêtes que le moteur exécute en parallèle avant de composer sa réponse.
2 listes internes chez Google conditionnent une partie de la visibilité dans l’AI Mode : Preferred Sources et Highly Cited, des ensembles de domaines que Google traite comme des références sur une thématique donnée. Aucun formulaire ne permet d’y postuler. L’entrée s’y gagne par la constance du signal technique et éditorial sur la durée. Un correctif ponctuel n’y suffit pas. Un contenu qui glisse en content decay, avec des chiffres datés ou des sections devenues fausses, perd sa place dans ces listes plus vite que dans un classement organique classique où l’inertie protège plus longtemps.
Pièges qui invalident un audit technique
Certaines erreurs reviennent régulièrement sur des sites autrement bien configurés.
- Un noindex resté actif après une migration de recette vers la production, invisible tant que personne ne recontrôle le head HTML après un déploiement.
- 2 sitemaps XML qui listent des URLs différentes après une refonte, l’ancien jamais retiré de Search Console et toujours exploré par Googlebot en parallèle du nouveau.
- Un hébergement de contenu tiers non surveillé sur un sous-dossier, la situation que Google qualifie de site reputation abuse depuis sa politique de 2024 contre l’exploitation de l’autorité d’un domaine par du contenu sans rapport avec l’éditeur principal.
Chacun de ces points passe sous le radar d’un audit rapide parce qu’il n’apparaît dans aucun outil de scoring automatique. Le noindex oublié est le plus coûteux des trois : une fois le tag retiré, Search Engine Journal rapporte qu’il faut de quelques jours à plusieurs semaines pour que Google réindexe l’ensemble des pages concernées. Ils se vérifient à la main, puis se surveillent par une alerte Search Console ou un monitoring de sitemap.
Le test à lancer maintenant
Cette séquence, exploration, indexation, rendu, Core Web Vitals, données structurées, lisibilité IA, se reparcourt à chaque nouveau mandat ou après chaque core update important. Elle ne remplace pas un audit approfondi mais elle évite de corriger dans le désordre pendant qu’un client attend des réponses.
Ouvrez Search Console et le rapport Pages : comparez le nombre d’URLs indexées à celui d’il y a 90 jours avant de toucher au moindre code.
