Comment bien paramétrer le micro format recipe pour optimiser vos recettes ?
- Comment bien paramétrer le micro format Recipe ?
- Choisir la bonne méthode : JSON-LD, Microdata, RDFa
- Les champs indispensables (et ceux qui font gagner des points)
- Formats et cohérence : le nerf de la guerre
- Écrire des instructions utiles (et lisibles par une machine)
- Images, vidéos et médias : ne donnez pas une assiette vide
- Encadré «checklist» avant mise en ligne
- Exemple JSON-LD propre (modèle à adapter)
- Tests, débogage et erreurs qui reviennent souvent
-
FAQ
- Dois-je forcément utiliser JSON-LD pour Recipe ?
- Quels champs sont vraiment indispensables pour une recette ?
- Comment gérer les durées pour éviter les erreurs ?
- Puis-je déclarer une note si je n'affiche pas d'avis ?
- Peut-on baliser une recette générée par un plugin ou un bloc Gutenberg ?
- Que faire si Google n'affiche pas l'extrait enrichi malgré un balisage valide ?
Sur un site de conseil webmaster, la recette est un cas d'école : un contenu structuré, répétitif en apparence, mais bourré de détails qui font la différence. Bien réglé, le micro format Recipe aide les moteurs à comprendre vos pages, à afficher des extraits enrichis (temps, notes, calories) et à limiter les erreurs d'interprétation. Mal réglé, c'est l'inverse : données incohérentes, balisage rejeté, et une page qui «cuisine» dans le vide.
Comment bien paramétrer le micro format Recipe ?
Imaginez vos données comme une mise en place en cuisine : si chaque ingrédient est au bon endroit, le service roule. Ici, la «mise en place» consiste à fournir des champs attendus, au bon format, sans contradictions entre le visible et le balisé. Le plus simple, dans la majorité des sites, reste le balisage JSON-LD : il est clair, isolé du HTML, et plus facile à maintenir.
Gardez une règle d'or : tout ce que vous déclarez dans le balisage doit exister réellement sur la page. Une note, un temps de cuisson, une liste d'ingrédients... si l'utilisateur ne le voit pas, évitez de l'inventer côté données.
Choisir la bonne méthode : JSON-LD, Microdata, RDFa
Trois approches coexistent. Dans la pratique, la plupart des webmasters privilégient le JSON-LD, car il évite de «saupoudrer» des attributs dans tout le code. Les microdonnées (Microdata) peuvent convenir à un CMS très balisé, mais elles deviennent vite pénibles à relire. Quant à RDFa, c'est plus rare sur des sites de recettes classiques.
Le bon balisage, c'est comme une étiquette lisible sur un bocal : vous savez tout de suite ce que c'est, sans devoir l'ouvrir.
Si vous avez déjà des microdonnées en place, inutile de tout casser. Vous pouvez migrer page par page vers le JSON-LD, en gardant une cohérence stricte entre les deux pendant la transition.
Les champs indispensables (et ceux qui font gagner des points)
Le type Recipe s'appuie sur un tronc commun. Certains champs sont quasi incontournables pour espérer un affichage enrichi correct : name, image, recipeIngredient, recipeInstructions. Ajoutez ensuite ce qui rend la fiche vraiment «compréhensible» : prepTime, cookTime, totalTime, recipeYield.
Si votre site affiche des notes, soyez carré : utilisez aggregateRating uniquement si la note est visible, basée sur des votes réels, et cohérente partout (page, widget, données). Même vigilance pour nutrition : mieux vaut s'abstenir que publier des calories approximatives «au doigt mouillé».
Tableau de repères : champs, formats, pièges courants
| Propriété | Format attendu | Exemple | Erreur fréquente |
|---|---|---|---|
| name | Texte | «Quiche aux poireaux» | Titre différent de celui affiché |
| image | URL(s) d'image | https://exemple.tld/img/quiche.jpg | Image bloquée, trop petite ou non accessible |
| prepTime | Durée ISO 8601 | PT20M | «20 minutes» en texte libre |
| totalTime | Durée ISO 8601 | PT55M | Temps total incohérent avec préparation + cuisson |
| recipeIngredient | Liste de chaînes | «2 œufs», «200 g de farine» | Mettre des étapes au lieu d'ingrédients |
| recipeInstructions | Liste (texte ou HowToStep) | 1) Préchauffer... | Un bloc illisible, sans étapes |
| aggregateRating | Objet (ratingValue, ratingCount...) | 4.6 / 128 avis | Note déclarée mais non affichée |
Formats et cohérence : le nerf de la guerre
Les durées doivent être en ISO 8601 : PT15M pour 15 minutes, PT1H pour 1 heure, PT1H30M pour 1 h 30. Oui, c'est un peu austère. Mais c'est le format compris sans ambiguïté. Un oubli ici suffit parfois à faire «tomber» tout le balisage.
Autre point : l'alignement entre vos données et le contenu visible. Si vous affichez «Préparation : 10 min» et «Cuisson : 25 min», évitez de déclarer totalTime à 60 minutes juste parce que «ça fait plus sérieux». Les moteurs aiment la cohérence, pas les effets de manche.
Écrire des instructions utiles (et lisibles par une machine)
Vous pouvez baliser les étapes en simple texte, ou en objets HowToStep. Pour un site de conseil webmaster, le choix dépend surtout de votre gabarit : si votre éditeur permet une liste d'étapes propre, profitez-en. Dans tous les cas, évitez l'étape unique du type «Tout mélanger et cuire». Une recette trop vague, c'est comme un plan de site sans URLs : ça «existe», mais ça n'aide personne.
Petite astuce terrain : gardez 6 à 12 étapes courtes. Certaines fiches montent à 20, ça passe, mais l'expérience de lecture peut en pâtir si chaque ligne ressemble à un roman.
Images, vidéos et médias : ne donnez pas une assiette vide
Une recette sans visuel, c'est dur à vendre. Déclarez au moins une image nette, accessible, et suffisamment grande. Si vous avez une vidéo, vous pouvez l'ajouter via un objet VideoObject, mais seulement si elle est bien intégrée à la page. Là encore, cohérence : la vidéo doit exister pour l'utilisateur, pas uniquement dans le script.
Pour éviter les soucis, vérifiez que l'URL d'image renvoie un code 200, qu'elle n'est pas bloquée par robots.txt, et qu'elle n'exige pas de cookie ou d'authentification. Ce genre de détail fait perdre du temps (et quelques cheveux).
Encadré «checklist» avant mise en ligne
Checklist rapide : titre identique, image accessible, ingrédients en liste, étapes découpées, durées ISO 8601, note affichée si déclarée, pas de données inventées, et un test dans l'outil de validation.
Ajoutez aussi un contrôle côté CMS : un champ vide peut générer un JSON cassé. C'est bête, mais fréquent, surtout avec des thèmes qui concatènent des virgules au mauvais endroit.
Exemple JSON-LD propre (modèle à adapter)
Voici un squelette réaliste. Adaptez-le à votre page, et gardez le texte visible aligné avec les valeurs déclarées. C'est la base d'un balisage Schema.org stable.
Tests, débogage et erreurs qui reviennent souvent
Testez avec un validateur de données structurées et relisez le JSON comme vous reliriez une recette avant de servir. Les erreurs classiques : virgule en trop, guillemets mal fermés, image inaccessible, champ requis manquant, ou aggregateRating utilisé sans votes réels. Côté SEO, une seule page cassée n'est pas dramatique. Cent pages cassées, c'est un signal de négligence.
Un bon réflexe : logguez vos validations. Un simple tableau de bord interne (URL, statut, erreur) rend le suivi beaucoup plus serein, surtout quand plusieurs personnes publient.
FAQ
Voici les questions qui reviennent le plus souvent quand on met en place une recette propre et durable.
Dois-je forcément utiliser JSON-LD pour Recipe ?
Non, mais c'est la méthode la plus simple à maintenir : un bloc clair, facile à corriger, et moins sensible aux modifications de mise en page.
Quels champs sont vraiment indispensables pour une recette ?
Au minimum : name, image, recipeIngredient et recipeInstructions. Ajoutez ensuite prepTime, cookTime, totalTime et recipeYield si vous les affichez sur la page.
Comment gérer les durées pour éviter les erreurs ?
Utilisez le format ISO 8601 : PT10M, PT1H, PT1H20M. Vérifiez aussi que totalTime correspond à la logique de votre fiche. [ En savoir plus ici ]
Puis-je déclarer une note si je n'affiche pas d'avis ?
Mieux vaut éviter. Une note balisée sans preuve visible (avis, compteur) est souvent considérée comme non fiable et peut entraîner des avertissements.
Peut-on baliser une recette générée par un plugin ou un bloc Gutenberg ?
Oui, tant que le balisage reflète ce qui est rendu à l'écran. Sur CMS, le point sensible reste la qualité du HTML final et la stabilité des champs.
Que faire si Google n'affiche pas l'extrait enrichi malgré un balisage valide ?
Un balisage valide n'oblige pas l'affichage. Travaillez la qualité de la page (clarté, média, structure), la cohérence des données, et vérifiez qu'aucune règle technique n'empêche l'exploration.
Si vous voulez aller plus loin côté «conseil webmaster», mettez en place une règle de validation à la publication : si l'auteur oublie l'image ou laisse des instructions vides, le CMS bloque la mise en ligne et affiche un message clair. C'est un garde-fou simple, et ça évite les recettes qui partent en production avec une liste d'ingrédients... sans ingrédients.
A propos de moi : Clara MetaWeb
Passionnée de web depuis plus de dix ans, je partage sur Ton Site mes astuces et conseils pour aider les webmasters à optimiser et sécuriser leurs sites. De la gestion technique à l’ergonomie, j’aime explorer tous les aspects qui rendent un site performant et agréable à utiliser. Mon parcours m’a permis d’accompagner aussi bien des débutants que des experts dans leurs projets digitaux. Je crois fermement que chaque webmaster peut progresser avec les bons outils et les bonnes pratiques. Rejoignez-moi pour découvrir ensemble les secrets d’un web efficace et durable !