Schema HowTo

Ce que HowTo décrit vraiment

Le type HowTo de la spécification schema.org modélise une tâche accomplie pas à pas : un objectif nommé par la propriété name, une séquence ordonnée d’étapes portée par step, et autour de ça le matériel consommé (HowToSupply), les outils réutilisables (HowToTool), la durée totale (totalTime, au format ISO 8601) et parfois le coût estimé (estimatedCost). Ce n’est pas un gabarit de page, c’est la description machine d’une procédure. La nuance a des conséquences très concrètes : une page peut contenir une procédure sans être une page de procédure, et c’est exactement là que la majorité des implémentations dérapent.

Dans la hiérarchie schema.org, Recipe est un sous-type de HowTo : une recette n’est qu’une procédure dont les fournitures sont des ingrédients typés. Cette filiation explique pourquoi Recipe a survécu là où HowTo est tombé. Le carrousel de recettes a une valeur d’usage et une valeur commerciale évidentes pour Google, alors que le rendu HowTo dépliait les étapes directement dans la page de résultats, absorbait le clic et ne rendait rien à l’éditeur qui avait payé la rédaction et l’intégration.

Ne le confondez pas non plus avec le balisage FAQPage, qui décrit des paires question/réponse indépendantes, ni avec Article, qui décrit un document éditorial et son auteur. Un tutoriel long a souvent besoin des deux : Article pour le document publié, HowTo pour la séquence opératoire imbriquée dedans. Les deux cohabitent sans conflit dans un même graphe, reliés par @id, et c’est la seule façon propre de baliser un guide qui contient à la fois de l’analyse et une marche à suivre.

L’anatomie du markup : name, step, itemListElement

Deux propriétés suffisent à rendre un objet HowTo interprétable : name, la formulation de l’objectif, et step, la liste ordonnée. Tout le reste est recommandé, jamais requis. step accepte soit une suite de HowToStep, soit des HowToSection qui regroupent des étapes en phases quand la procédure est longue (préparation, montage, réglage). Chaque HowToStep porte à son tour un name court, un text qui décrit l’action, une url pointant vers l’ancre de l’étape dans la page, et une image quand l’étape est visuelle.

Le point qui pose problème à tout le monde est itemListElement. À l’intérieur d’un HowToStep, cette propriété accueille des HowToDirection (les gestes à faire) et des HowToTip (les conseils qui ne sont pas des gestes). Un HowToStep se décrit donc soit par un text en prose, soit par un itemListElement décomposé en directions, mais jamais par les deux avec le même contenu dupliqué. La duplication est l’erreur de nesting la plus fréquente : elle produit un objet valide au parseur mais absurde à la lecture machine, avec chaque geste compté deux fois.

Sur le format, la question JSON-LD contre microdata n’a plus lieu d’être débattue. Le JSON-LD injecté dans un bloc script est découplé du DOM : un intégrateur peut refondre le template sans casser le graphe. Le microdata éparpille les itemprop et les itemtype dans le HTML de rendu, et le jour où quelqu’un déplace une div, la propriété part avec elle sans que rien ne le signale. En dix ans d’audits, les cas de données structurées cassées silencieusement viennent presque toujours du microdata ou d’un plugin qui l’écrase. La seule raison résiduelle de garder du microdata, c’est un CMS legacy où l’injection de script est impossible.

Ce que Google en fait depuis 2023

Rien. Google a retiré les rich results HowTo des résultats mobiles en août 2023, puis des résultats desktop en septembre 2023. Le rendu a disparu, le rapport d’amélioration correspondant dans la Search Console aussi, et le Rich Results Test a cessé de valider le type. La boucle a été bouclée en mai 2026 : d’après le journal de mises à jour de la documentation Google Search Central, la page de documentation How-to et son étude de cas ont été supprimées, avec pour motif explicite que la fonctionnalité n’est plus affichée ni sur desktop ni sur mobile.

Ce retrait s’inscrit dans un mouvement plus large. Le 5 novembre 2025, Google a annoncé une simplification des résultats de recherche et la fin du support de plusieurs types de données structurées dans la Search Console et son API à partir de janvier 2026, en citant un usage faible ou une valeur utilisateur insuffisante : Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement, Vehicle Listing, Practice Problem. Et le 7 mai 2026, Google a supprimé les rich results FAQ de l’ensemble de la recherche, le support Search Console et Rich Results Test devant suivre en juin, l’API en août. La lecture est sans ambiguïté : les embellissements de SERP à base de questions et de procédures sont en retraite générale, parce qu’ils déportaient la réponse hors du site sans contrepartie.

Il faut ajouter un point que beaucoup de prestataires évitent de dire à leurs clients : le guide Google de mai 2026 sur l’optimisation pour les fonctionnalités génératives indique explicitement qu’aucun balisage schema.org particulier n’est requis pour ces fonctionnalités, et renvoie aux fondamentaux (titres clairs, sections, contenu unique, pages crawlables). Vendre du HowTo comme un levier d’entrée dans les réponses génératives, c’est vendre quelque chose que l’éditeur du moteur a écrit noir sur blanc ne pas utiliser.

Ce qui porte réellement la visibilité d’une page procédurale

Les données récentes convergent. Une étude Ahrefs publiée le 9 juin 2026 a suivi 1 885 pages ayant ajouté du JSON-LD entre août 2025 et mars 2026, comparées à 4 000 pages témoins, sur les AI Overviews, l’AI Mode et ChatGPT : aucun gain notable de citations, et même un recul de 4,6 % des citations en AI Overviews par rapport aux témoins, avec la réserve honnête des auteurs que ces pages étaient déjà sur une tendance baissière. À l’inverse, une expérience contrôlée relayée par Search Engine Land le 23 septembre 2025 sur trois pages très similaires a vu la seule page correctement balisée apparaître en AI Overview et se positionner sur six requêtes, jusqu’à la position 3. Ce résultat teste la qualité globale du balisage, pas HowTo en particulier, et sur trois pages : il suggère, il ne prouve pas.

Ce qui pèse, en revanche, est mesuré : les recherches Ahrefs de 2026 montrent qu’une page positionnée sur les requêtes dérivées d’un éclatement de la requête initiale a 161 % de chances de plus d’être citée qu’une page positionnée sur la seule requête principale, avec une corrélation de Spearman rapportée à 0,77. Pour un éditeur de contenu procédural, la conclusion opérationnelle est directe : couvrir la tâche entière, ses prérequis, ses variantes, ses cas de panne et les questions qui suivent, avec des intertitres descriptifs et un maillage interne solide, rapporte infiniment plus que trois heures d’intégration de HowToDirection.

Le second levier reste hors site, et le balisage n’y peut rien : un objet JSON-LD ne crée pas de lien et ne transmet pas d’autorité. Une page tutoriel doit être traitée comme une ressource à faire citer, avec des données originales, des captures, des tests réels, puis promue auprès d’éditeurs pertinents. C’est ce qu’on applique sur les médias éditoriaux français que nous opérons en propre chez Nautilinks : un guide qui documente un protocole que personne d’autre n’a mesuré attire des liens éditoriaux, pas parce qu’il est balisé, mais parce qu’il est le seul à répondre. Pour cette partie du travail, le catalogue de médias consultable sans inscription permet de cibler les supports dont l’audience correspond réellement au sujet du tutoriel, et les tarifs affichés en clair évitent de découvrir la facture après coup.

Les erreurs qu’on voit en audit

La plus coûteuse est un faux diagnostic : une baisse de trafic datée de fin 2023 attribuée à un problème de balisage, alors que la cause est la disparition de l’affichage lui-même. Du markup déprécié est ignoré, pas sanctionné. Aucune pénalité n’est associée à la présence d’un HowTo obsolète, et aucune correction technique ne rendra un rendu que Google ne produit plus.

Les autres reviennent avec une régularité désolante :

• Du HowTo posé sur des pages qui ne décrivent aucune procédure, typiquement une fiche produit ou un comparatif, parce qu’un plugin l’active par défaut sur un type de contenu entier.
• Des étapes balisées qui ne correspondent pas au contenu visible de la page, ce qui contrevient au principe de base des données structurées et fragilise tout le reste du graphe aux yeux des systèmes qui le lisent.
• Une propriété url d’étape pointant vers une ancre qui n’existe pas dans le HTML, souvent après une refonte de template.
• Des tableaux de bord techniques qui surveillent encore un rapport d’amélioration HowTo supprimé de la Search Console, et qui remontent donc un zéro permanent interprété comme une régression.
• Une extension WordPress payée pour ses types de schémas, alors que la capacité du plugin ne dit rien du support côté moteur. Des relevés tiers de 2026 situent l’offre gratuite de Rank Math autour de dix-huit types de schémas, HowTo compris, et la version Pro autour de 7,99 € par mois en facturation annuelle : c’est une fonctionnalité d’outil, pas une garantie d’affichage.

Garder, retirer, ou simplement arrêter d’en produire

Ma position est nette et tient en trois temps. Ne lancez pas de chantier de suppression : un HowTo valide déjà en place ne coûte rien en visibilité et le temps de développeur consacré à le retirer est du temps volé au contenu. Arrêtez d’en produire par défaut, en désactivant l’injection automatique dans le CMS pour les nouveaux gabarits. Et conservez-le délibérément sur les pages où il sert un consommateur identifié : une application interne, un assistant qui lit vos propres flux, un graphe de connaissances maison, un export vers une base documentaire, ou une contrainte d’accessibilité et de lisibilité machine dans un contexte industriel ou réglementé.

Le critère de décision est toujours le même, et il vaut bien au-delà de ce type de balisage : qui lit cette donnée, et qu’en fait-il ? Si la réponse est « on espère un affichage dans la SERP », l’espoir a été démenti par l’éditeur du moteur en 2023 puis confirmé mort par la suppression de sa propre documentation en 2026. Si la réponse est « notre application de support consomme ce flux », le balisage se justifie tout seul et n’a jamais eu besoin de Google pour ça. Le temps libéré par cet arbitrage est mieux investi dans la profondeur du contenu procédural et dans les liens éditoriaux qui le rendent visible.