Données structurées recette : le schema Recipe

Le type Recipe de schema.org sert à décrire une recette de cuisine dans un format que Google peut lire directement, indépendamment du design de la page. Bien renseigné, il permet à une page recette d'afficher une note en étoiles, un temps de préparation et une photo dans les résultats de recherche, et de figurer dans le carousel de recettes sur mobile. Mal renseigné — propriétés manquantes, durées au mauvais format, note sans avis visible sur la page — il ne produit aucun de ces effets, et peut dans certains cas déclencher une action manuelle pour non-respect des consignes sur les extraits d'avis.

Cet article détaille les propriétés que Google exige et celles qu'il recommande pour le type Recipe, les conditions qui déclenchent réellement le rich result et le carousel, les erreurs les plus courantes sur les notes, les durées et les images, et la règle qui relie tout cela : ce qui est balisé doit correspondre à ce que voit un visiteur sur la page.

Le rôle du type Recipe dans schema.org

Recipe est un sous-type de HowTo, lui-même rattaché à CreativeWork, dans le vocabulaire schema.org. Il existe depuis longtemps dans la spécification, mais Google n'en exploite qu'un sous-ensemble précis de propriétés pour générer ses résultats enrichis : posséder le balisage complet du vocabulaire ne garantit rien, seules les propriétés que Google lit réellement comptent pour le rich result.

Google accepte les trois syntaxes autorisées par schema.org — JSON-LD, microdonnées et RDFa — mais recommande explicitement le JSON-LD pour les nouveaux projets. L'avantage est structurel : le bloc JSON-LD est autonome, il ne dépend pas de la façon dont chaque propriété est encapsulée dans le HTML visible. Un changement de thème ou de template ne casse donc pas le balisage, contrairement aux microdonnées où chaque propriété est un attribut posé sur un élément précis de la page.

Une page ne doit décrire qu'une seule recette. Une page qui liste plusieurs recettes — une catégorie, une page d'accueil de blog culinaire — n'est pas le bon endroit pour un balisage Recipe complet ; c'est la page de détail de chaque recette qui doit le porter, une instance par page.

Propriétés requises

Google distingue deux niveaux de propriétés pour le type Recipe. Les propriétés requises sont la condition minimale sans laquelle le rich result n'est pas généré du tout ; les propriétés recommandées ne bloquent rien si elles manquent, mais chacune conditionne l'apparition d'un élément visuel précis dans le résultat.

• name : le nom de la recette, qui doit correspondre au titre visible sur la page.
• image : au moins une photo de la recette, sous forme d'URL absolue ou d'objet ImageObject.

Propriétés recommandées

Au-delà de ce socle minimal, chaque propriété recommandée déverrouille un élément d'affichage spécifique plutôt que le rich result dans son ensemble. Il n'est pas nécessaire de toutes les renseigner d'un coup : mieux vaut couvrir correctement six ou sept propriétés qui correspondent à un contenu réellement présent sur la page que d'en lister quinze dont la moitié sont approximatives ou copiées d'une autre recette.

• author : l'auteur de la recette.
• datePublished : la date de publication, au format ISO 8601.
• description : un résumé court de la recette.
• prepTime, cookTime et totalTime : les durées de préparation, de cuisson et totale, au format de durée ISO 8601, comme PT30M pour trente minutes ou PT1H15M pour une heure et quart.
• recipeYield : le nombre de portions ou la quantité produite.
• recipeCategory et recipeCuisine : la catégorie du plat et son origine culinaire.
• recipeIngredient : la liste des ingrédients, une chaîne de texte par ingrédient dans un tableau, jamais un seul bloc de texte.
• recipeInstructions : les étapes de préparation, idéalement sous forme de tableau d'objets HowToStep plutôt qu'un paragraphe unique.
• nutrition : les informations nutritionnelles, notamment le nombre de calories.
• video : un objet décrivant une vidéo de préparation, si elle existe.
• aggregateRating et review : la note moyenne et les avis, seulement s'ils existent réellement sur la page.

Comment le rich result et le carousel se déclenchent

Le rich result de base, l'affichage enrichi dans les résultats classiques avec la photo et éventuellement le temps de préparation, se déclenche dès que les propriétés requises sont présentes et valides. Il n'apparaît pas systématiquement pour chaque recherche : Google décide au cas par cas si l'extrait enrichi apporte une valeur suffisante par rapport à un résultat texte classique, et rien dans le balisage ne force cette décision.

Le carousel de recettes, visible sur mobile en haut de certaines recherches culinaires, est un format différent et plus exigeant. Il agrège plusieurs pages de plusieurs sites autour d'une même requête, et repose sur les filtres que l'utilisateur peut appliquer : temps de préparation, note, régime alimentaire. Une page ne peut être filtrée par note que si elle expose un aggregateRating valide, et ne peut être filtrée par temps que si prepTime ou totalTime sont renseignés au bon format de durée. Une recette sans ces propriétés recommandées peut apparaître dans les résultats classiques enrichis, mais n'a pas la même chance d'apparaître dans le carousel filtrable.

La présence d'un objet video bien formé augmente aussi la probabilité d'un affichage avec vignette vidéo, utile en particulier pour les recherches faites depuis un mobile où l'utilisateur cherche une démonstration plutôt qu'un texte. Rien de tout cela n'est garanti de façon binaire : le balisage rend l'affichage possible, il ne l'impose pas.

Un cas particulier mérite une décision explicite : la recette présentée uniquement en vidéo, sans texte d'étapes écrit sur la page, format courant sur les blogs qui publient d'abord pour les réseaux sociaux avant de republier sur leur site. Le balisage recipeInstructions attend du texte, pas une simple référence à une vidéo ; s'il n'existe aucune étape écrite nulle part sur la page, il n'y a rien d'honnête à baliser dans cette propriété. La solution correcte n'est pas de transcrire approximativement la vidéo dans le JSON-LD sans l'afficher au lecteur, mais d'ajouter un minimum d'étapes écrites visibles sur la page elle-même, même courtes, avant de les baliser. Le balisage video reste pertinent en complément, mais ne remplace pas des instructions textuelles absentes.

L'erreur la plus coûteuse : une note sans avis visibles

L'erreur la plus surveillée par Google sur les extraits d'avis, recette incluse, consiste à afficher une note en étoiles générée par un aggregateRating qui ne correspond à aucun avis visible sur la page. C'est explicitement couvert par les consignes sur les extraits d'avis, et ce n'est pas une simple erreur de validation : c'est un cas où Google peut retirer manuellement le droit à l'extrait enrichi pour l'ensemble du site, pas seulement pour la page concernée.

Le cas typique est une note importée automatiquement d'un plugin de recette qui agrège des avis venus d'un autre système, commentaires ou réseau social externe, sans que ces avis n'apparaissent nulle part sur la page elle-même. Le correctif n'est pas de retirer le plugin, mais de s'assurer que chaque avis compté dans ratingCount ou reviewCount est effectivement lisible par un visiteur qui arrive sur la page, avec le même total.

Un aggregateRating sans le moindre avis, un ratingCount à zéro ou absent, ne doit simplement pas être balisé. Il vaut mieux ne pas inclure la propriété du tout que d'inventer une note ou de reprendre un score par défaut affiché par un thème.

Erreurs fréquentes sur les durées et les images

Les propriétés de durée, prepTime, cookTime et totalTime, doivent être écrites au format de durée ISO 8601, pas en langage naturel. « 30 minutes » ou « 1h30 » écrits tels quels dans le balisage ne sont pas reconnus ; la syntaxe attendue est PT30M pour trente minutes, PT1H30M pour une heure trente, PT2H pour deux heures, ou encore P0DT2H, la même durée de deux heures écrite en incluant explicitement zéro jour, une forme plus rare mais également valide. C'est une source d'erreur fréquente parce que la valeur affichée sur la page, en langage naturel pour le lecteur, n'est jamais la même chaîne que la valeur balisée, ce qui déroute les personnes qui remplissent le champ à la main.

Sur les images, trois points reviennent régulièrement. D'abord, l'URL doit être absolue, jamais relative, et effectivement accessible sans blocage par un fichier robots.txt ou une balise noindex posée sur l'image elle-même. Ensuite, Google recommande de fournir la photo dans plusieurs formats de cadrage, 16x9, 4x3 et 1x1, pour s'adapter aux différents emplacements d'affichage ; une seule image dans un format inhabituel peut être ignorée pour certains formats de résultat. Enfin, l'image doit avoir une résolution suffisante : une vignette compressée à outrance, pensée pour charger vite plutôt que pour être zoomée, se retrouve régulièrement écartée du rich result faute de largeur minimale.

Une dernière erreur, plus discrète, concerne les cas où la photo balisée n'est pas celle affichée sur la page. Cela arrive quand une image mise en avant, différente de la photo utilisée dans le corps de l'article, est renseignée dans le balisage, par exemple une photo générique de la catégorie plutôt que la photo du plat réellement présenté.

La cohérence entre le balisage et le contenu visible

Toutes les erreurs précédentes se ramènent à un seul principe que Google énonce dans ses consignes générales sur les données structurées : le balisage doit décrire un contenu que le visiteur peut effectivement voir ou atteindre sur la page, pas un contenu qui existe ailleurs, qui a existé dans le passé, ou qui n'existe que dans une base de données interne.

Concrètement pour une recette, cela veut dire que la liste d'ingrédients balisée dans recipeIngredient doit être la même liste que celle affichée à l'écran, pas une version simplifiée pour le balisage, pas une version étendue avec des ingrédients optionnels absents du texte. Les étapes balisées dans recipeInstructions doivent correspondre au nombre et à l'ordre des étapes réellement écrites, sans les fusionner ni les réordonner pour raccourcir le JSON-LD.

Le même principe interdit de masquer un élément visuellement, par exemple avec un texte de la couleur du fond ou une hauteur réduite à zéro, tout en le conservant dans le balisage pour continuer à bénéficier du rich result. Un contrôle qui détecte l'écart retire l'éligibilité, et la remise en conformité prend du temps à se répercuter dans les résultats, le temps que Google réexplore et revalide la page.

Mise en œuvre pratique et validation

Pour une implémentation neuve, la structure la plus robuste consiste en un seul bloc JSON-LD par page de recette, avec recipeIngredient comme tableau de chaînes courtes, un ingrédient par entrée avec sa quantité, et recipeInstructions comme tableau d'objets HowToStep, chacun avec une propriété text correspondant exactement à une étape numérotée affichée sur la page. Cette structure en étapes distinctes, plutôt qu'un bloc de texte unique, est aussi ce qui permet un affichage étape par étape dans certains contextes, comme un assistant vocal.

Pour la propriété image, deux écritures sont valides et le choix dépend surtout de l'existant : une simple chaîne d'URL suffit si la photo est déjà accessible en HTTPS dans une taille correcte, alors qu'un objet ImageObject, avec ses propres propriétés url, width et height, devient utile quand plusieurs formats de cadrage doivent être déclarés explicitement plutôt que déduits par Google au moment du crawl. Un site qui ne génère qu'une seule taille d'image par photo n'a aucune raison de complexifier son balisage avec un ImageObject ; celui qui sert déjà trois recadrages différents depuis son gestionnaire de médias a tout à gagner à les déclarer explicitement.

L'outil de test des résultats enrichis de Google permet de vérifier une page individuelle avant publication : il distingue les erreurs bloquantes, qui empêchent tout rich result, des avertissements, qui signalent une propriété recommandée manquante sans bloquer l'affichage. Une fois la page publiée, c'est le rapport d'amélioration Recettes dans Search Console qui donne la vue d'ensemble sur l'intégralité du site, avec le nombre de pages valides, invalides et avec avertissements, et le détail de chaque type d'erreur rencontré.

Un délai est à prévoir entre une correction et sa prise en compte : Search Console ne revalide pas une page au moment où elle est corrigée, il faut que Google la réexplore, ce qui peut prendre plusieurs jours selon la fréquence de crawl du site. Corriger dix pages d'un coup et vérifier le lendemain donnera donc souvent un rapport encore ancien, pas un signe que la correction a échoué.