Audit SEO technique : une checklist priorisée pour 2026

En bref : un audit SEO technique répond à quatre questions, dans l'ordre : Google peut-il accéder à vos pages, peut-il indexer la bonne version de chacune, peut-il comprendre de quoi parle chaque page, et la page fonctionne-t-elle bien pour les internautes qu'il lui envoie ? Commencez par les codes de statut, le fichier robots.txt et les règles noindex, puis les redirections, les balises canoniques et les sitemaps, puis les balises title, les données structurées et hreflang, enfin HTTPS, la parité mobile et les Core Web Vitals. Corrigez selon l'impact, pas selon la longueur de la liste de problèmes, et revérifiez après chaque mise en production.

La plupart des audits échouent de la même façon. Un crawler liste 214 « problèmes » triés par nombre, et l'équipe passe une semaine à ajouter des textes alternatifs à des images décoratives pendant qu'une balise noindex oubliée depuis la préproduction garde la page de tarifs hors de Google. Le volume n'est pas une priorité.

Cette checklist suit le chemin qu'une page parcourt dans Google : explorée, indexée, comprise, servie. Un problème en début de chaîne rend tout ce qui suit sans objet : auditez et corrigez donc dans cet ordre. Chaque règle ci-dessous provient de la documentation de Google.

Ce que couvre un audit SEO technique

Un audit technique porte sur l'accès et l'interprétation, pas sur la question de savoir si votre contenu mérite de se positionner. Les exigences techniques de Google sont courtes : Googlebot n'est pas bloqué, la page renvoie un code HTTP 200 et elle contient du contenu indexable. Google précise que les respecter « ne signifie pas qu'une page sera indexée ; l'indexation n'est pas garantie ». Tout le reste d'un audit consiste à supprimer les raisons pour lesquelles Google pourrait ignorer, mal interpréter ou déclasser une page.

Avant de commencer : quatre sources de vérité

1. Rapport d'indexation des pages de la Search Console : quelles URL Google a indexées et pourquoi il a ignoré les autres.
2. Outil d'inspection d'URL : la vision de Google sur une URL, avec le HTML rendu et la canonique qu'il a retenue.
3. Un crawler de site : codes de statut, redirections, balises title et canoniques de chaque page accessible.
4. Un vérificateur au niveau de la page : notre outil gratuit d'analyse SEO de site web effectue 38 contrôles sur la page que vous saisissez (votre page d'accueil par défaut) et sur les fichiers du site qui l'entourent en environ 20 secondes.

Notez d'abord un état de référence (pages indexées, pages non indexées par motif, URL trouvées par le crawler), faute de quoi vous ne pourrez pas savoir si les correctifs ont fonctionné.

Étape 1 : Google peut-il accéder à vos pages ?

Codes de statut

Chaque URL que vous voulez voir dans les résultats doit répondre par un 200. Google documente son traitement des autres codes dans How HTTP status codes affect Google Search et Redirects and Google Search :

Deux détails comptent en pratique. Google indique que « toutes les erreurs 4xx, à l'exception de 429, sont traitées de la même façon » : un 404 et un 410 aboutissent donc au même résultat. Et le 429 est le code qu'envoient les pare-feu et les protections anti-bots lorsqu'ils jugent un crawler trop rapide, raison pour laquelle un produit de sécurité peut discrètement ralentir votre indexation.

Google interprète une meta refresh instantanée comme permanente et une meta refresh différée comme temporaire. Les redirections JavaScript ne fonctionnent que si le rendu réussit ; Google conseille de ne les utiliser que lorsque les redirections côté serveur ou par meta refresh sont impossibles.

robots.txt

Le fichier robots.txt gère le trafic des robots d'exploration. Selon l'introduction à robots.txt de Google, il « n'est pas un mécanisme permettant d'exclure une page web de Google ». Une page interdite d'exploration « peut quand même être indexée si d'autres sites pointent vers elle », et s'affiche sans description.

Vérifiez trois points :

• Le fichier existe à la racine et renvoie un 200 en texte brut, pas une page HTML, ou un 404 propre si vous n'avez besoin d'aucune règle. Jamais un 5xx : Google suspend alors l'exploration.
• Aucune règle ne bloque les sections que vous voulez voir dans les résultats. Le désastre classique est un Disallow: / copié depuis la préproduction.
• Les fichiers CSS et JavaScript nécessaires au rendu de la page ne sont pas bloqués.

Le vérificateur robots.txt lit votre fichier comme le fait Googlebot et signale les règles qui bloquent l'ensemble du site ou la page saisie, ainsi qu'un robots.txt qui répond par une erreur serveur.

noindex et X-Robots-Tag

Une balise meta noindex ou un en-tête HTTP X-Robots-Tag: noindex garde une page hors des résultats. La version en en-tête fonctionne aussi pour les PDF, images et vidéos, qui ne peuvent pas porter de balise meta (Block Search indexing with noindex).

Le piège : si robots.txt bloque la même URL, « le robot ne verra jamais la règle noindex, et la page peut quand même apparaître dans les résultats de recherche ». Pour retirer une page, autorisez l'exploration et servez un noindex. Auditez à la fois le HTML et les en-têtes de réponse, car les CDN et les plugins peuvent ajouter un X-Robots-Tag sans que personne ne modifie la page.

Étape 2 : Google peut-il indexer la bonne version ?

Un site, une adresse

http://example.com, http://www.example.com, https://example.com et https://www.example.com sont quatre URL différentes pour un crawler. Choisissez-en une et redirigez définitivement les trois autres vers elle en un seul saut. Faites de même pour les slashs finaux et les chemins en majuscules si votre serveur répond dans les deux cas. Le vérificateur de redirections teste les quatre versions d'hôte, affiche le code de statut de chaque saut et signale les redirections temporaires, les boucles et les longues chaînes.

Balises canoniques

Le guide de canonicalisation de Google classe les signaux : les redirections et rel="canonical" sont des signaux forts, la présence dans le sitemap est un signal faible. Tous sont des signaux, pas des ordres ; Google peut choisir une autre canonique. Ses bonnes pratiques :

• Utiliser des URL absolues dans les balises canoniques.
• Ajouter une canonique auto-référencée sur la page canonique elle-même.
• Indiquer la même canonique dans toutes les méthodes (balise, en-tête, sitemap).
• « N'utilisez pas le fichier robots.txt à des fins de canonicalisation. »

Constats typiques : toutes les pages qui ont pour canonique la page d'accueil, et des canoniques qui pointent vers des URL redirigées ou en 404.

Sitemaps XML

D'après Build and submit a sitemap :

• Un sitemap est limité à 50 000 URL ou 50 Mo non compressés. Les sites plus volumineux le répartissent en plusieurs fichiers listés dans un index de sitemaps.
• Google ignore <priority> et <changefreq>.
• Google n'utilise <lastmod> que « s'il est systématiquement et vérifiablement exact », et il doit refléter des modifications significatives, pas une nouvelle année de copyright.
• Soumettez-le dans la Search Console et référencez-le dans robots.txt avec une ligne du type Sitemap: https://example.com/sitemap.xml.

Un sitemap ne doit lister que des URL canoniques, indexables et renvoyant un 200. Les redirections, les 404 et les pages noindex dans le sitemap envoient des signaux contradictoires et figurent parmi les constats les plus fréquents d'un crawl.

Soft 404

Une soft 404 est une page qui renvoie un 200 mais ressemble à une erreur : une catégorie vide, un message « produit introuvable », une page de recherche sans résultat. La Search Console les signale sous « Soft 404 ». Renvoyez un vrai 404 ou 410 pour un contenu absent, ou placez un contenu utile sur l'URL.

Rendu JavaScript

Google explore, puis effectue le rendu avec un Chromium headless, puis indexe le HTML rendu (JavaScript SEO basics). Le rendu a lieu « dès que les ressources de Google le permettent » : un contenu qui n'existe qu'après l'exécution des scripts arrive donc plus tard et est plus fragile. Vérifiez :

• Les liens sont des éléments <a> avec un href. Google indique qu'il ne peut découvrir vos liens que de cette façon ; les gestionnaires de clic sur des <div> ou <span> lui sont invisibles.
• Les routes côté client utilisent l'History API, pas des fragments #.
• Les applications monopage évitent les soft 404 en redirigeant vers une URL qui renvoie un 404 ou en ajoutant noindex aux vues d'erreur.
• Le texte important est présent dans la réponse du serveur. Google recommande toujours le rendu côté serveur ou le prérendu, et note que « tous les robots ne peuvent pas exécuter JavaScript », ce qui compte encore plus pour les crawlers IA (voir l'étape 5).

Utilisez le test en direct de l'inspection d'URL pour comparer le HTML brut et le HTML rendu pour un template de chaque type.

Étape 3 : Google peut-il comprendre chaque page ?

Balises title

La documentation sur les liens de titre de Google demande une balise <title> distincte, descriptive et concise sur chaque page, sans bourrage de mots-clés ni texte répétitif. Elle précise qu'il n'y a pas de limite de longueur, mais que les titres sont tronqués pour s'adapter à l'appareil. Google réécrit aussi automatiquement les liens de titre, à partir du <title>, du titre principal, de og:title, du texte d'ancre et d'autres sources, surtout quand le title est absent, dupliqué ou peu utile. Une plage pratique d'environ 30 à 60 caractères garde les mots importants visibles ; c'est une convention, pas une règle de Google.

Meta descriptions

Google indique que les extraits « sont principalement créés à partir du contenu de la page elle-même » et qu'il utilise parfois la meta description lorsqu'elle offre un résumé plus fidèle (Control your snippets). Il n'y a pas de limite de longueur ; l'extrait est tronqué au besoin. Ce contre quoi Google met en garde, ce sont les descriptions identiques sur de nombreuses pages et les descriptions faites de listes de mots-clés. Repérez les descriptions manquantes et dupliquées sur vos templates importants, et rédigez un résumé lisible pour chacun. Le vérificateur de balises meta prévisualise l'aspect d'une page dans les résultats.

Données structurées

Google recommande JSON-LD « si la configuration de votre site le permet » et le Test des résultats enrichis pour le valider (intro to structured data). Dans un audit, vérifiez que chaque template porte le balisage qu'il doit avoir (Organization sur la page d'accueil, Product sur les fiches produit, Article sur les articles, BreadcrumbList là où il y a un fil d'Ariane), qu'il est valide et qu'il correspond à ce qui est visible sur la page. Les types qui donnent encore des résultats enrichis en 2026 et la façon de les rédiger sont détaillés dans notre guide du balisage schema ; le vérificateur de balisage schema liste ce qu'une page déclare actuellement.

hreflang

Pour les sites avec des versions par langue ou par pays, le guide des versions localisées de Google fixe les règles :

• Utiliser des balises HTML link, des en-têtes HTTP ou le sitemap ; Google les considère comme équivalents.
• Chaque version se liste elle-même et liste toutes les autres versions. Les annotations non réciproques peuvent être ignorées.
• Utiliser un code de langue ISO 639-1, éventuellement suivi d'une région ISO 3166-1 alpha-2 (en, en-GB, pt-BR). Un code pays seul n'est pas valide.
• Utiliser des URL absolues, et éventuellement x-default pour les visiteurs qui ne correspondent à aucune de vos versions.

Google détecte la langue d'une page à partir du contenu grâce à ses propres algorithmes, et non à partir de hreflang ou de l'attribut lang : une URL allemande avec un corps de texte en anglais reste donc une page en anglais. Le vérificateur hreflang valide les codes selon ces règles, vérifie l'auto-référence et indique si x-default est défini ; il lit une seule page, vérifiez donc aussi les liens retour sur les autres versions.

Étape 4 : la page fonctionne-t-elle bien pour les visiteurs ?

HTTPS et contenu mixte

Servez chaque URL en HTTPS avec un certificat valide et redirigez le HTTP de façon permanente. Les recommandations sur l'expérience de page de Google demandent : « Vos pages sont-elles diffusées de manière sécurisée ? » Recherchez aussi le contenu mixte (scripts ou images chargés en http://), que les navigateurs bloquent en partie. Le vérificateur d'en-têtes de sécurité couvre le certificat, la redirection HTTPS, HSTS et le contenu mixte.

Indexation mobile-first

« Google utilise la version mobile du contenu d'un site, explorée avec l'agent smartphone, pour l'indexation et le classement », selon ses bonnes pratiques d'indexation mobile-first. La question d'audit est la parité : la version mobile doit avoir le même contenu principal, les mêmes données structurées, les mêmes balises meta robots et des balises title et descriptions équivalentes. Google déconseille aussi le chargement différé (lazy-loading) du contenu principal au moment d'une interaction de l'utilisateur, car Googlebot ne clique pas, ne fait pas défiler et ne saisit rien.

Notez que Google a retiré son Test d'optimisation mobile et le rapport Ergonomie mobile de la Search Console le 1er décembre 2023, en renvoyant les propriétaires de sites vers Lighthouse (Google Search Central Blog). Notre test de compatibilité mobile vérifie les bases : la balise viewport, les images adaptatives, le favicon et la langue de la page.

Core Web Vitals

Google affirme que « les Core Web Vitals sont utilisés par nos systèmes de classement », tout en précisant que de bons scores ne garantissent pas les premières places et que la pertinence passe avant tout. Les objectifs sur web.dev, mesurés au 75e centile des visites réelles :

INP a remplacé First Input Delay comme Core Web Vital en 2024. Dans un audit technique, notez les templates qui échouent et passez à la suite ; diagnostiquer et corriger chaque métrique est un projet à part entière, détaillé pas à pas dans notre guide des Core Web Vitals. Le vérificateur de Core Web Vitals lit les données réelles des utilisateurs Chrome de votre site.

Étape 5 : préparation à la recherche IA

Pour les AI Overviews et le mode IA, Google indique qu'une page doit être indexée et éligible à un extrait, sans exigence supplémentaire, et que votre CDN ou votre hébergeur doit aussi autoriser l'exploration. Les autres assistants utilisent leurs propres crawlers : OpenAI utilise OAI-SearchBot pour la recherche ChatGPT et GPTBot pour l'entraînement, et les sites qui bloquent OAI-SearchBot « ne seront pas affichés dans les réponses de la recherche ChatGPT ». Auditez trois points : les crawlers de recherche IA sont autorisés dans robots.txt et par le pare-feu, le contenu clé figure dans la réponse HTML, et la page d'accueil indique qui vous êtes grâce au balisage Organization. Le vérificateur de préparation à la recherche IA teste ces trois points ; notre guide sur le generative engine optimization couvre le reste.

Lire le rapport d'indexation des pages

Le rapport d'indexation des pages est l'endroit où l'audit rencontre la réalité. Le cadrage de Google lui-même : « Vous ne devez pas vous attendre à ce que toutes les URL de votre site soient indexées, seulement les pages canoniques. » L'objectif n'est donc pas de vider la liste « Non indexées », mais de s'assurer que chaque page canonique importante est indexée et que chaque exclusion est voulue.

Après avoir corrigé un problème partout, cliquez sur Valider la correction. Google indique que la validation s'arrête dès qu'une seule occurrence subsiste et qu'elle « prend généralement jusqu'à environ deux semaines ».

Inspection d'URL pour les pages individuelles

L'outil d'inspection d'URL affiche la version indexée (pas en direct) et, avec Tester l'URL en direct, la page actuelle telle que Googlebot la récupère : disponibilité, autorisation d'exploration et d'indexation, canonique déclarée par l'utilisateur et canonique choisie par Google, capture d'écran rendue, HTML brut, en-têtes HTTP et ressources chargées. Utilisez-le sur une URL par template après chaque correctif. Demander une indexation aide pour quelques pages clés ; pour de nombreuses pages, Google recommande un sitemap avec des valeurs lastmod exactes. Les inspections comme les demandes d'indexation sont soumises à des limites quotidiennes par propriété.

Budget de crawl : uniquement pour les très grands sites

Le budget de crawl est le problème le plus souvent surdiagnostiqué en SEO. Le guide du budget de crawl de Google s'adresse aux sites d'environ 1 million de pages uniques ou plus changeant chaque semaine, aux sites de 10 000 pages ou plus changeant chaque jour, et aux sites dont une grande part des URL est en « Détectée, actuellement non indexée ». Google parle d'estimations approximatives, pas de seuils exacts, et indique que si vos pages sont explorées le jour même de leur publication, vous n'avez pas besoin de ce guide. Pour la plupart des sites, un sitemap à jour et un coup d'œil régulier à l'indexation des pages suffisent.

Comment prioriser : impact fois effort

Évaluez chaque constat selon l'impact (combien de pages importantes il touche et à quel point) et l'effort (la difficulté de correction), puis travaillez de haut en bas.

Corrigez les templates, pas les pages : une balise title manquante sur un template produit, c'est une seule correction.

Exemple concret (hypothétique)

L'exemple suivant est hypothétique, il ne s'agit pas de données réelles. Northwind Outfitters, une boutique d'équipement outdoor inventée comptant environ 1 200 pages produit et catégorie, réalise un audit après une refonte. La Search Console affiche 640 pages indexées, contre 1 050 avant le lancement.

Le crawler signale 312 constats. Triés par nombre, les trois premiers sont les textes alternatifs manquants (148), les balises title trop longues (61) et les meta descriptions manquantes (40). Triés selon l'ordre de cette checklist, le tableau change :

1. Accès : robots.txt est correct, mais 38 URL renvoient un 429 pendant le crawl. La nouvelle protection anti-bots limite le débit de tout ce qui va plus vite qu'un humain.
2. Indexation : chaque URL de catégorie filtrée (?color=, ?size=) porte une canonique vers elle-même, ce qui crée 400 quasi-doublons. Le sitemap liste encore 90 anciennes URL qui redirigent désormais. Toutes les pages produit en http://www. redirigent deux fois : vers https://www., puis vers https://.
3. Compréhension : les 61 balises title « trop longues » dépassent de quelques caractères.
4. Expérience : le LCP échoue sur le template de catégorie parce que l'image principale est chargée en différé.

L'ordre des correctifs : laisser passer les crawlers vérifiés à travers la protection anti-bots, canonicaliser les URL filtrées vers la catégorie non filtrée, régénérer le sitemap à partir des seules URL canoniques, ramener la chaîne de redirections à un seul saut, puis charger immédiatement l'image principale de la catégorie. Les textes alternatifs et la longueur des balises title passent dans le prochain sprint de contenu. Six semaines plus tard, la baisse d'indexation est résorbée, et les URL restantes « non indexées » sont les pages filtrées, comme prévu.

À quelle fréquence auditer

Lancez un audit complet chaque trimestre et autour de chaque migration, refonte ou changement d'URL (crawlez la préproduction avant le lancement, la production le lendemain), et automatisez chaque semaine l'essentiel : codes de statut, changements de noindex et de robots.txt, erreurs de sitemap et tendance de l'indexation des pages. Le SEO technique se dégrade rarement lentement ; il casse un jour de mise en production.

Une checklist d'une heure pour démarrer

1. Lancez l'outil gratuit d'analyse SEO de site web et notez les échecs de haute priorité.
2. Relevez dans la Search Console le nombre de pages dans l'indexation des pages, par motif.
3. Testez en direct une URL par template dans l'inspection d'URL ; comparez le HTML brut et le HTML rendu.
4. Vérifiez robots.txt, les quatre versions d'hôte et une chaîne de redirections.
5. Contrôlez dix URL du sitemap : chacune doit renvoyer un 200, être indexable et canonique.
6. Placez les constats dans le tableau impact × effort et corrigez les trois premiers cette semaine.

Comment Searvia réalise un audit SEO technique

L'outil gratuit d'analyse SEO de site web de Searvia lit la page que vous saisissez (la page d'accueil si vous ne saisissez qu'un domaine) et les fichiers du site qui l'entourent (robots.txt, sitemap, llms.txt), votre certificat, vos enregistrements DNS de messagerie et les données de vitesse réelles des utilisateurs de Chrome. Il effectue 38 contrôles répartis en six sections : apparence dans la recherche (9), exploration et indexation (6), préparation à la recherche IA (7), vitesse (6), mobile (4) et sécurité (6), et attribue une note de A+ à F avec une liste de correctifs priorisée et un rapport partageable. Des versions ciblées du même moteur sont listées sur la page des outils gratuits.

Pour l'ensemble du site, l'audit de site d'un compte Searvia explore vos pages comme un moteur de recherche, regroupe les problèmes en erreurs, avertissements et notices (pages et liens cassés, redirections dans le sitemap, pages noindex dans le sitemap, canoniques pointant ailleurs, balises title dupliquées, pages orphelines et plus encore), et se relance chaque semaine pour que vous voyiez ce que vous avez corrigé et ce qui a cassé. Le nombre de pages par audit dépend de votre offre ; l'offre gratuite en couvre 100. Connectez la Search Console pour voir l'indexation et les clics réels de Google à côté de l'audit, et vérifiez votre site pour envoyer les pages nouvelles et modifiées aux moteurs compatibles IndexNow, comme Bing et Yandex, après chaque audit.