Balises schema pour les recettes : guide du balisage structuré

Une recette correctement balisée n'apparaît pas nécessairement enrichie dans les résultats de recherche. Le balisage structuré ouvre une possibilité, il ne la garantit pas. Cette distinction est au cœur de la question : les données structurées décrivent le contenu à destination des moteurs, mais leur exploitation dépend ensuite de règles qui échappent largement aux éditeurs.

Ce que décrit le balisage de recette

Le vocabulaire Schema.org définit un type Recipe qui permet d'associer à une page un ensemble de propriétés normalisées. L'objectif est de rendre explicite, pour une machine, ce qu'un lecteur humain comprend en parcourant la page : le nom du plat, la liste des ingrédients, les étapes de préparation, le temps de cuisson, le nombre de portions.

Les propriétés les plus fréquemment utilisées couvrent l'essentiel du contenu éditorial. name désigne l'intitulé de la recette, recipeIngredient liste les ingrédients, recipeInstructions contient les étapes, totalTime et cookTime expriment les durées au format normalisé, recipeYield indique le nombre de portions, et image référence une ou plusieurs photographies.

Le format d'écriture le plus courant est JSON-LD, un bloc de code inséré dans la page et indépendant du HTML visible. Les formats Microdata et RDFa, intégrés directement aux balises de contenu, restent pris en charge mais sont aujourd'hui moins répandus pour ce type de données.

Ce que le balisage permet, et ce qu'il ne permet pas

Un balisage valide rend une recette éligible à des affichages enrichis : durée, note, image, parfois étapes directement dans les résultats. Cette éligibilité n'est pas un droit. Les moteurs décident de l'affichage selon leurs propres critères, qui évoluent et ne sont pas entièrement publics.

Plusieurs limites méritent d'être signalées. Un balisage absent ou erroné n'empêche pas une page d'être indexée : il prive seulement le contenu d'un canal d'affichage supplémentaire. À l'inverse, un balisage présent mais incohérent avec le texte visible peut être ignoré, voire traité comme une tentative de tromperie. Les propriétés obligatoires varient selon le type de résultat visé, et une recette peut être techniquement valide sans jamais déclencher d'affichage enrichi.

La maintenance compte également. Une recette modifiée sans mise à jour du bloc JSON-LD produit un décalage entre ce que déclarent les données et ce que lit l'utilisateur. Ce décalage est l'une des causes les plus fréquentes de perte d'éligibilité.

Vérifier et corriger un balisage existant

Deux contrôles complémentaires s'imposent. Le premier porte sur la validité syntaxique : le code doit respecter les règles du format choisi. Le second porte sur la cohérence sémantique : chaque propriété déclarée doit correspondre à une information réellement présente sur la page.

Plusieurs points de vigilance reviennent régulièrement dans les audits de balisage :

• Les durées doivent respecter le format ISO 8601 (par exemple PT30M pour trente minutes), faute de quoi elles sont ignorées.
• Les unités d'ingrédients gagnent à être écrites de façon exploitable, sans abréviation ambiguë.
• Les images référencées doivent être accessibles et correspondre au plat décrit.
• Le balisage ne doit pas mentionner de contenu absent du texte visible.

Les outils de test proposés par les moteurs permettent de simuler le rendu et de repérer les propriétés manquantes ou mal formées. Ils ne préjugent pas de l'affichage final, qui reste soumis à des arbitrages internes aux moteurs.

Le balisage structuré constitue donc une condition technique parmi d'autres. Il améliore la lisibilité d'une recette pour les systèmes automatisés, sans exercer d'effet direct sur le classement ni sur la décision d'afficher un résultat enrichi. Les sites qui l'intègrent le font pour rendre leur contenu exploitable, non pour obtenir une garantie de visibilité.