SEO technique : protocole d’audit vérifiable des fondations d’un site

Dire qu’une page est « SEO compatible » masque souvent l’étape qui échoue. Une URL peut être découverte mais bloquée, explorée mais rendue sans contenu, indexée sous une autre canonique, ou indexée sans être retenue pour une requête. Le diagnostic commence donc par localiser la rupture.

Le nombre de contrôles varie selon le risque : la symétrie d’un tableau ne doit pas dicter l’audit. Le JSON public v1.1 est l’unique source canonique des identifiants, méthodes, preuves, sources et limites. Le tableau HTML indexable et la matrice XLSX sont générés à partir de ce dataset.

Les identifiants TS01 à TS44 restent stables entre les versions. Pour citer un contrôle précis, utiliser son fragment direct, par exemple #TS41.

Le JSON versionné est l’unique source canonique. Le tableau ci-dessous et le XLSX en sont deux représentations générées, lisibles et citables. La colonne « accès » empêche de confondre un test public avec une preuve Search Console, serveur ou de configuration. Chaque ligne possède une ancre stable : #TS01 à #TS44.

Un test HEAD seul est insuffisant : CDN, pare-feu et application peuvent traiter HEAD et GET différemment. Le protocole relève le code final, le nombre de redirections, l’URL effective et la durée. Il rejoue au minimum l’URL canonique, une ancienne URL, une ressource supprimée et une URL inexistante.

Disallow demande à un robot conforme de ne pas explorer un chemin. Il ne garantit pas la disparition de l’URL des résultats. Une directive noindex doit être lue dans le HTML ou l’en-tête HTTP ; si la ressource est bloquée par robots.txt, le moteur peut ne jamais la voir. Une donnée confidentielle, enfin, doit être refusée par authentification ou autorisation côté serveur.

Cette distinction corrige une recommandation trop répandue : associer noindex à Disallow ne renforce pas mécaniquement l’exclusion. Cela peut empêcher la lecture du noindex. La documentation Google sur les directives robots et le RFC 9309 bornent précisément ces mécanismes.

Google classe la redirection et rel="canonical" parmi les signaux forts de canonicalisation, et la présence dans un sitemap parmi les signaux plus faibles. Ces signaux se renforcent lorsqu’ils convergent. Ils ne transforment pas la canonique déclarée en ordre absolu : le moteur peut choisir une autre URL.

Le contrôle public compare URL finale, canonique déclarée, sitemap et liens internes. Le contrôle privé compare ensuite la canonique utilisateur à la canonique Google dans l’inspection d’URL. Sans cette seconde étape, l’audit ne peut conclure qu’à une déclaration cohérente, pas à une canonique effectivement choisie.

Un sitemap utile contient des URL absolues, finales, indexables et canoniques. Chaque fichier respecte la limite de 50 000 URL ou 50 Mo non compressés. Les grands périmètres sont répartis dans un index de sitemaps pour permettre un diagnostic par famille.

lastmod doit correspondre à une modification significative de la page, pas à l’heure de génération du fichier. Google indique ne pas utiliser priority et changefreq. Un lastmod systématiquement réécrit détruit le signal qu’il prétend fournir.

Google recommande que chaque page importante reçoive au moins un lien depuis une autre page. Le format fiable reste un élément <a> avec un attribut href résoluble. Un gestionnaire onclick, une carte cliquable sans lien ou un état produit uniquement côté client peut rester invisible à certains crawlers.

Le rapport d’orphelines naît de la comparaison entre trois inventaires : pages découvertes par le crawl, URL déclarées dans les sitemaps et URL connues du CMS ou de la base. Une différence n’est pas automatiquement une erreur ; elle doit être qualifiée. Une page de campagne volontairement isolée n’a pas la même fonction qu’une offre principale sans lien entrant.

Les filtres, tris, calendriers et paramètres peuvent produire des combinaisons infinies. Le protocole regroupe les URL par motif, mesure les combinaisons, puis décide pour chaque famille : navigable, indexable, canonicalisée, bloquée à l’interface ou réellement indisponible.

Chaque variante pointe vers elle-même et vers les autres variantes du groupe. Les retours doivent exister. Les codes de langue et de région doivent être valides. Les URL doivent répondre, rester indexables et publier une canonique compatible avec leur propre langue.

x-default peut désigner une page neutre ou la variante assumée par défaut. Il n’est pas obligatoire dans tous les cas. Surtout, hreflang ne compense pas une traduction pauvre, un contenu identique non localisé ou une géolocalisation forcée qui empêche l’utilisateur et le crawler de choisir.

Google traite le JavaScript selon trois phases documentées : crawl, rendu, indexation. Un site rendu côté client peut être indexable. Un site rendu côté serveur peut échouer. Le choix SSR, SSG ou CSR ne prouve rien à lui seul ; la preuve vient de la présence réelle du contenu, des liens et des métadonnées au stade attendu.

Le contrôle porte sur la langue du document, le titre, le contenu principal, la hiérarchie de titres, les liens, les libellés et les états d’interface. La validation HTML repère des erreurs de structure ; elle ne prouve ni la qualité, ni la pertinence, ni l’accessibilité complète.

Cette couche relie SEO technique, accessibilité et compréhension machine. Pour approfondir, voir le protocole Edikka sur l’accessibilité, le SEO et le HTML sémantique, ainsi que l’analyse des limites d’un score Lighthouse de 100.

Le JSON-LD doit décrire des entités réellement présentes, utiliser des propriétés appropriées et relier les mêmes objets avec des identifiants @id stables. Les nœuds Organization, Person, WebSite, WebPage et Article ne doivent pas être recréés sans relation à chaque bloc.

Les consignes Google sont explicites : un balisage valide ne garantit pas l’affichage d’un résultat enrichi. Une donnée structurée trompeuse peut faire perdre cette éligibilité sans que cela signifie automatiquement une baisse de classement organique. Le contrôle sépare donc syntaxe Schema.org, politique Google et cohérence avec le contenu visible.

Voir aussi le guide dédié aux données structurées pour le SEO et le GEO.

Lighthouse produit un test de laboratoire dans des conditions définies. Il localise un problème et permet une non-régression ; il ne remplace pas les données d’utilisateurs réels. L’absence de données CrUX signifie parfois seulement que le volume public est insuffisant.

Les Core Web Vitals participent aux systèmes de classement de Google, mais la documentation sur l’expérience de page rappelle qu’un score parfait ne garantit pas la première position. Le protocole relie donc performance, contenu, indexation et suivi sans transformer une métrique en causalité unique.

Une page en 200 peut rester techniquement incohérente : certificat invalide sur une variante d’hôte, ressource active chargée en HTTP, slash final qui crée une seconde URL, redirection géographique dépendante de l’IP ou cache CDN qui conserve un ancien noindex. Le protocole teste donc HTTPS, HSTS, hôte, casse, slash, Vary et règles edge séparément.

Pour l’international, Google accepte trois méthodes équivalentes pour hreflang : HTML, en-tête HTTP ou sitemap XML. Les cumuler ne crée pas de bénéfice Search et multiplie les sources de divergence. L’audit nomme une source de vérité, puis vérifie auto-référence, réciprocité et URL canoniques dans cette méthode.

Le pipeline ne cherche pas à « automatiser le SEO ». Il rejoue des invariants observables sur un échantillon représentatif : code final, nombre de redirections, absence de noindex involontaire, canonical absolue, groupe hreflang, contenu critique dans le HTML serveur, liens essentiels et JSON-LD parsable. Chaque échec pointe vers une URL, une règle et une sortie conservée.

Search Console, les logs et la revue éditoriale restent indispensables. La CI empêche seulement qu’une erreur déjà connue franchisse silencieusement une nouvelle mise en ligne.

Les opérateurs ne publient pas tous les mêmes jetons ni les mêmes finalités. OpenAI distingue OAI-SearchBot pour la recherche, ChatGPT-User pour les actions déclenchées par un utilisateur et GPTBot pour l’entraînement. Anthropic sépare notamment Claude-SearchBot, Claude-User et ClaudeBot. Google-Extended est un jeton de contrôle et non un user-agent HTTP autonome.

Le test technique utilise une requête GET avec la chaîne complète documentée, puis rapproche la réponse des logs. Imiter un user-agent ne prouve jamais qu’une visite provient réellement de l’opérateur. Enfin, le contenu critique, les preuves et les liens doivent rester disponibles dans le HTML serveur ou dans une ressource publique reliée : un fichier llms.txt ou Markdown peut faciliter l’accès, mais ne garantit ni citation ni classement.

Le guide Google consulté le 22 août 2026 cible principalement les sites très grands — environ un million de pages ou davantage avec des changements hebdomadaires —, les sites d’au moins dix mille pages qui changent quotidiennement, ou les sites où une part importante des URL reste « Découverte, actuellement non indexée ». Ces ordres de grandeur sont des repères, pas une frontière universelle.

Sur un site vitrine de cinquante pages, parler d’abord de crawl budget détourne souvent l’attention de causes plus probables : pages sans lien, canonicalisation contradictoire, contenu faible, rendu cassé ou absence d’intention distincte. La documentation crawl budget de Google doit être lue avant de prescrire des optimisations complexes.

Observation effectuée le 22 août 2026 avant publication de cette nouvelle édition, depuis une connexion externe non authentifiée. Le début de collecte est horodaté 08 :13 :55 CEST dans l’artefact ; la réponse HTTP porte 06 :13 :55 GMT, soit le même instant exprimé dans deux fuseaux. Le cas sert à montrer la discipline de preuve ; il n’est pas présenté comme un audit complet de l’ensemble du domaine.

La matrice ne calcule pas une note sur 100. Une moyenne diluerait une erreur critique : 43 réussites ne compensent pas un noindex involontaire sur la page d’offre. La règle est donc une porte : un Bloquant non conforme, ou un Bloquant applicable non testé, impose NO-GO ; un Majeur non conforme impose un arbitrage documenté.

Cet article et la Grille d’audit SEO technique Edikka v1.1 sont publiés sous licence CC BY 4.0. La réutilisation est autorisée avec attribution à Edikka et à cette URL canonique. Les fichiers sont accessibles sans formulaire.