Faut-il vraiment limiter vos propriétés JSON-LD au strict minimum affichable dans les rich snippets ?

Que signifie vraiment cette recommandation de Google ?

Google nous dit ici de limiter nos propriétés JSON-LD à ce qui peut effectivement apparaître dans les rich snippets. Pour les recettes, cela concerne les éléments visuels : image, temps de préparation, calories, note globale. L'idée sous-jacente est simple : pourquoi structurer des données que le moteur n'affichera jamais ?

Cette position tranche avec une approche maximaliste où certains SEO ajoutent toutes les propriétés possibles du schema.org/Recipe. Temps de cuisson, de repos, de marinade, équipement nécessaire, rendement précis, catégories multiples, mots-clés de cuisine... Tout y passe. Google suggère que cette surcharge est inutile.

Pourquoi cette déclaration pose-t-elle question ?

Le problème réside dans l'ambiguïté du terme « compatible ». Compatible avec quoi exactement ? Avec l'affichage actuel des rich snippets, ou avec une version future que Google pourrait déployer ? Les SERP évoluent constamment, et ce qui n'est pas affiché aujourd'hui pourrait l'être demain.

Par ailleurs, Google ne dit pas que les propriétés supplémentaires sont pénalisantes. Il dit simplement de s'assurer qu'elles sont « compatibles ». Cette nuance laisse un flou stratégique. Est-ce une recommandation d'optimisation ou un avertissement contre le spam de données structurées ?

Quelles propriétés sont réellement affichées dans les rich snippets ?

Pour les recettes, l'affichage SERP standard inclut : image, titre, note agrégée, nombre d'avis, temps total, calories. Parfois, on voit aussi la préparation et la cuisson séparées, mais c'est moins systématique. Le rendement (nombre de portions) apparaît rarement.

Les propriétés comme recipeCategory, recipeCuisine, keywords, tool, suitableForDiet ne s'affichent quasiment jamais dans les résultats organiques classiques. Elles pourraient servir au classement interne ou à des filtres futurs, mais aucune donnée publique ne le confirme.

• Propriétés essentielles : name, image, author, datePublished, description, aggregateRating, recipeYield, prepTime, cookTime, totalTime, recipeIngredient, recipeInstructions, nutrition (calories)
• Propriétés affichées en rich snippet : image, aggregateRating, totalTime (ou prepTime + cookTime), nutrition.calories
• Propriétés rarement exploitées : recipeCategory, recipeCuisine, keywords, tool, suitableForDiet, video (sauf contexte particulier)
• Propriétés requises pour la validation : name, image, author, datePublished sont obligatoires même si non toutes affichées
• Zone grise : video devient parfois un carrousel séparé, nutrition au-delà des calories n'apparaît pas, les étapes détaillées (HowToStep) sont validées mais rarement affichées intégralement

Cette recommandation est-elle cohérente avec les pratiques observées sur le terrain ?

Pas vraiment. Les sites qui rankent le mieux sur les requêtes de recettes utilisent souvent des implémentations riches avec bien plus que le minimum affichable. Ils structurent les ingrédients en détail, les étapes en HowToStep, ajoutent video, recipeCategory, recipeCuisine. Est-ce corrélation ou causalité ? Impossible à dire avec certitude. [À vérifier]

Google n'a jamais confirmé publiquement que les propriétés non affichées contribuent au ranking. Mais plusieurs tests A/B menés par des agences montrent que l'ajout de propriétés supplémentaires coïncide parfois avec une amélioration de visibilité. Le lien de causalité reste flou, mais la corrélation existe.

Quelles nuances faut-il apporter à cette directive ?

Première nuance : « compatible » ne veut pas dire « uniquement ». Google ne dit pas d'exclure toute propriété non affichée. Il dit de s'assurer que ce qu'on ajoute est compatible avec ce qui peut s'afficher. Autrement dit, ne pas inventer de propriétés fictives ou mal structurées.

Deuxième nuance : les propriétés supplémentaires peuvent servir à d'autres produits Google. Google Assistant, Google Discover, Google Lens exploitent potentiellement des données que la Search classique n'affiche pas. Limiter son JSON-LD au strict affichage SERP, c'est ignorer ces canaux.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle contre-productive ?

Si votre stratégie de contenu repose sur la richesse sémantique pour des assistants vocaux ou des agrégateurs tiers, alors limiter vos propriétés est une erreur. Les données structurées nourrissent bien plus que les rich snippets : elles alimentent les knowledge graphs, les suggestions de recherche, les filtres avancés.

Autre cas : les sites de niche avec des recettes très spécialisées (régimes particuliers, cuisines régionales) ont intérêt à structurer finement suitableForDiet, recipeCuisine, recipeCategory. Même si ces propriétés ne s'affichent pas aujourd'hui, elles préparent le terrain pour des filtres futurs.

Que faut-il faire concrètement avec vos balises Recipe actuelles ?

Première étape : auditer vos implémentations JSON-LD pour identifier les propriétés présentes. Utilisez l'outil de test des résultats enrichis de Google, puis comparez ce qui est validé versus ce qui s'affiche réellement dans les SERP pour vos pages de recettes. Notez les écarts.

Deuxième étape : prioriser les propriétés essentielles. Assurez-vous que name, image, author, datePublished, aggregateRating, totalTime, recipeIngredient, recipeInstructions, nutrition.calories sont présents et correctement formatés. Ce sont les piliers du rich snippet. Sans eux, pas d'affichage enrichi.

Quelles erreurs éviter lors de l'implémentation ?

Erreur classique : surcharger avec des propriétés redondantes ou mal formatées. Par exemple, ajouter prepTime, cookTime ET totalTime alors que totalTime devrait être la somme des deux. Google peut s'y perdre ou ignorer certaines valeurs. Restez cohérent.

Autre piège : utiliser des propriétés non standardisées ou obsolètes. Schema.org évolue, certaines propriétés sont dépréciées. Vérifiez régulièrement la documentation officielle. Une propriété mal nommée ou mal typée ne sera tout simplement pas lue, et vous perdez du temps de crawl pour rien.

Comment vérifier que votre implémentation est optimale ?

Testez vos URLs dans l'outil de test des résultats enrichis de Google Search Console. Regardez les avertissements, pas seulement les erreurs. Un avertissement sur une propriété manquante peut signaler une opportunité d'amélioration, pas forcément une obligation.

Comparez ensuite l'affichage réel dans les SERP. Faites des recherches incognito sur vos requêtes cibles et voyez ce qui apparaît. Si une propriété que vous avez structurée ne s'affiche jamais, deux options : soit elle est inutile pour l'affichage (mais utile ailleurs), soit elle est mal formatée.

• Auditer toutes les pages de recettes avec l'outil de test des résultats enrichis
• Vérifier la présence et la validité des propriétés essentielles : image haute résolution (minimum 1200px), aggregateRating avec ratingValue et ratingCount, totalTime au format ISO 8601
• Nettoyer les propriétés non standardisées ou redondantes qui génèrent des avertissements
• Tester l'affichage réel dans les SERP pour au moins 10 recettes représentatives
• Documenter les propriétés supplémentaires que vous conservez (recipeCategory, recipeCuisine, video) et justifier leur présence stratégique
• Mettre en place un monitoring mensuel des rich snippets pour détecter toute perte d'affichage