Commencez par la page et une fonctionnalité prise en charge
Ne commencez pas en ajoutant tous les types schema.org qui semblent liés à votre activité. Schema.org est un vaste vocabulaire partagé, tandis que la Search Gallery de Google documente les fonctionnalités de résultats enrichis qu'il prend en charge et les propriétés requises. Une page produit, événement ou article doit d'abord être utile sans balisage.
Pour chaque gabarit, nommez son sujet principal et les faits visibles qui l'accompagnent. Ensuite, lisez le guide actuel de Google pour la fonctionnalité correspondante. Product, Recipe, Article, Breadcrumb, Event, Organization, LocalBusiness et Video sont des exemples. Un type de vocabulaire seul ne crée pas une fonctionnalité Google ; ce sont les propriétés requises par cette fonctionnalité qui déterminent l'éligibilité.
Faites de l'élément visible principal l'élément principal du balisage.
Utilisez le guide de Google pour le comportement de la fonctionnalité et schema.org pour le vocabulaire.
Faites de la page visible la source de vérité
Le balisage doit représenter le contenu principal de la page, pas du contenu caché, non pertinent ou trompeur. S'il indique qu'un artiste se produit, la page doit présenter cet artiste. S'il marque une note agrégée, les visiteurs doivent voir cette note. Cela évite qu'un gabarit dérive vers un résumé trompeur.
Construisez le texte de la page et le balisage à partir des mêmes enregistrements approuvés. Un flux produit, un système d'événements ou un CMS peut alimenter les deux, mais les valeurs doivent être révisées avant publication. Ne copiez pas un prix, un état de stock, une date ou un total d'avis dans un champ réservé au balisage qui pourrait être oublié. Mettez à jour ou supprimez le balisage lorsque l'information visible change.
Gardez noms, dates, prix, disponibilité et notes alignés avec la page.
Ne remplissez jamais des propriétés avec des valeurs devinées ou périmées.
Utilisez JSON-LD comme couche de données maintenable
JSON-LD est un format linked-data basé sur JSON placé dans un document HTML. Google prend en charge JSON-LD, Microdata et RDFa, et indique que JSON-LD est généralement le plus simple à implémenter et à maintenir à grande échelle. Sa séparation du balisage visible peut faciliter la modélisation d'informations imbriquées.
Utilisez un objet de données clair pour chaque élément réel, avec un type schema.org approprié et des propriétés prises en charge et exactes. Pour chaque gabarit, documentez le guide de la fonctionnalité, le champ source, le comportement des champs obligatoires et le propriétaire. Inspectez aussi le rendu final : un plug-in ou un composant peut ajouter un balisage dupliqué ou en conflit.
Choisissez le format que votre équipe peut maintenir de façon cohérente.
Ne créez pas une valeur requise quand la source de données est absente.
Validez le code et la page accessible
La validation répond à deux questions. D'abord, le balisage est-il suffisamment complet pour une fonctionnalité prise en charge ? Le Rich Results Test accepte du code collé ou une URL publique et signale les résultats enrichis pouvant être générés à partir des données structurées. Testez des exemples représentatifs pour chaque gabarit, pas une page exceptionnellement complète.
Ensuite, Google peut-il accéder à la page publiée et à ses ressources ? Ne bloquez pas les pages balisées avec robots.txt, l'en-tête noindex ou des contrôles d'accès. Vérifiez les URLs d'images concernées. Le test n'est pas une garantie de qualité : des problèmes de contenu visible ou de conformité aux règles peuvent toujours empêcher l'affichage.
Testez le code d'abord, puis testez une URL publique accessible.
Comparez la page rendue, le source et le résultat du test lorsque des outils ajoutent du balisage.
La possibilité d'affichage n'est pas une promesse d'affichage futur.
Publiez-le comme une modification de gabarit utilisateur
Les données structurées dépendent souvent de gabarits, de flux et de règles de publication. Une refonte, un changement d'intégration d'inventaire, une mise à jour de localisation ou la suppression d'un composant peut casser de nombreux éléments. Ajoutez des vérifications représentatives du balisage à la revue pré-publication utilisée pour les balises canoniques, les titres et les images. Enregistrez le gabarit, des exemples de pages, les champs source et la date de publication.
Quand un gabarit émet un balisage erroné, corrigez la source partagée ou le gabarit, validez un petit échantillon, déployez la correction la plus ciblée et retestez les URLs affectées. Si la correction se comporte de façon inattendue, utilisez votre processus normal de rollback. L'objectif est la remédiation basée sur des preuves d'une capacité web dégradée, pas une alerte d'incident.
Vérifiez des ensembles de pages représentatifs, pas une seule URL.
Enregistrez la modification et le composant de balisage avant une correction ultérieure.
Maintenez, mesurez et acceptez la limite d'affichage
Après le déploiement, utilisez le rapport Search Console pertinent pour les résultats enrichis afin d'investiguer les problèmes et confirmer les corrections. Les rapports sont des échantillons plutôt qu'un inventaire complet, et les comptages concernent des éléments (items), pas des pages. Inspectez une URL spécifique si nécessaire.
Mesurez prudemment. Google suggère une comparaison avant/après sur des pages stables et suffisamment lues pendant plusieurs mois dans Search Console. Enregistrez la date de publication et les autres changements de page. Un balisage correct ne fait qu'activer l'éligibilité ; Google détermine la présentation dans la recherche.
Recontrôlez après des changements de CMS, gabarit, flux, politique ou modèle de contenu.
Évitez les comparaisons où d'autres changements majeurs de page diffèrent.