Tutoriel sur la structuration des données avec Schema.org | JSON-LD, validation et erreurs courantes
Schema.org est un système qui permet aux moteurs de recherche de comprendre la structure des pages web grâce à des balises spécifiques, mais il ne garantit pas un meilleur classement et n'est pas une condition nécessaire pour les recherches par intelligence artificielle. La précision et la pertinence sont plus importantes que la quantité ; les balises doivent être clairement visibles sur la page.
Il est important de distinguer Schema.org et les fonctionnalités de recherche de Google.
Schema.org fournit un vocabulaire générique pour décrire les entités et les relations. Google ne prend en charge qu'une partie de ces types, qui servent de base pour certains résultats de recherche spécifiques. Les sites web peuvent utiliser des propriétés Schema.org valides, mais cela ne garantit pas que Google affichera des résultats enrichis. Avant de déployer, il est important de vérifier que le contenu principal de la page est pertinent, que Google prend en charge les fonctionnalités correspondantes, et qu'il existe suffisamment de données visibles pour les décrire avec précision.
Quels types de contenus sont réellement utilisés sur ce site ?
Falcon utilise des graphes simples et cohérents, permettant ainsi au nom de marque, au site web, à l'auteur et au contenu de la page de partager le même identifiant d'entité :
Organisation : Identité de la marque et coordonnées de contact.
Site Web : Relation entre le site web et l'éditeur
Service : Portée et prestataire de services clairement définies.
Article : Contenu de l'article (avec le nom de l'auteur et la date de publication)
Liste de navigation "Pain de mie"
Page de profil / Personne : Auteurs vérifiés et liens vers des professionnels
Œuvre créative : Contenu de cas et preuves révélées
Comment déployer JSON-LD ?
Google recommande l'utilisation de JSON-LD, et prend également en charge Microdata et RDFa. Next.js permet d'intégrer un script `application/ld+json` dans le code HTML généré côté serveur. L'important n'est pas la différence entre la section `<head>` et le corps de la page, mais plutôt que les données puissent être récupérées, que le JSON soit analysable, que l'URL utilise une référence canonique valide, et que chaque champ puisse être vérifié dans le contenu principal de la page ou dans des informations connexes clairement définies. Les entités partagées doivent utiliser des identifiants stables (@id) pour éviter la création de plusieurs entités conflictuelles sur la même page.
Déterminer l'ordre de création des schémas à partir du contenu de l'image.
Il est préférable de commencer par créer un modèle de générateur avant de le remplir avec du contenu. Voici une séquence de travail plus sûre :
L'objectif principal de la page de confirmation, ainsi que la correspondance entre l'URL canonique et le contenu réellement affiché.
Sélectionnez les types qui sont pris en charge par Google et qui correspondent au contenu principal.
Seules les informations existantes concernant les auteurs, les dates, les images, les services ou les études de cas sont prises en compte.
Utilisez le "Rich Results Test" pour vérifier les fonctionnalités de Google et le "Schema Markup Validator" pour vérifier la syntaxe générale.
Après le lancement, utilisez l'outil d'inspection de URL pour vérifier le code HTML que Google a réellement récupéré.
Erreurs courantes
Ne pas utiliser de notes agrégées non vérifiées (par exemple, une note de 4,9 sur 5 basée sur 50 commentaires) – Cela constitue une violation des politiques de Google Rich Results.
Si le contenu de la balise schema ne correspond pas au contenu réel de la page, Google rejettera directement les résultats enrichis.
Bien que l'entreprise n'ait pas de magasin physique, elle peut afficher l'adresse ou les heures d'ouverture de l'entreprise locale.
Les sites web commerciaux utilisent les pages "FAQ", "Comment faire" et "Discuter" comme des raccourcis pour afficher des résultats riches ou des réponses générées par l'IA.
Pourquoi les sections FAQ, HowTo et Speakable ne devraient-elles pas être mélangées ?
Il est clair que les FAQ restent utiles pour les utilisateurs, mais les résultats enrichis de Google sont principalement limités aux sites gouvernementaux et de santé réputés. Les résultats enrichis de "HowTo" ne sont plus affichés. Les documents Google de Speakable sont spécifiquement destinés à un usage journalistique. Cela ne signifie pas que les sites web ne peuvent pas utiliser des FAQ ou des instructions, mais qu'ils ne devraient pas promettre aux entreprises qu'elles obtiendront des résultats enrichis ou des références basées sur l'IA simplement en ajoutant des balises.
Le passage d'un examen ne garantit pas nécessairement une certaine réussite.
Le test des résultats enrichis : Google peut décider de ne pas afficher les résultats, même si le contenu respecte les formats techniques et certaines exigences, en fonction du contexte de recherche, des politiques de qualité et de la pertinence de la page. Si les données structurées sont trompeuses, si elles masquent du contenu ou si elles enfreignent les règles, la page peut perdre son statut de résultat enrichi, et cela peut entraîner une intervention manuelle de Google via Search Console. Cela ne signifie pas nécessairement que le classement naturel va diminuer, mais cela peut rendre les balises incorrectes inutiles.
Si le schéma est incorrect, cela entraînera-t-il des sanctions ?
Les données structurées qui induisent en erreur ou qui enfreignent les politiques peuvent entraîner la perte de leurs attributs, ainsi que des mesures manuelles. Les risques courants comprennent la saisie d'évaluations agrégées, la mention de contenu inaccessible aux utilisateurs, et la création d'entités commerciales ou d'auteurs fictives.
JSON-LD, Microdata, RDFa : laquelle choisir ?
Google prend en charge les trois formats. La recommandation officielle est d'utiliser JSON-LD : séparation du contenu HTML et des données, facilité de maintenance, et absence de risque de casser la mise en page. Si un système existant utilise déjà largement Microdata, il est préférable d'adopter JSON-LD pour les nouveaux projets.
Les données structurées doivent-elles être présentes sur chaque page ?
Selon le type de page : « Organisation » et « Site Web » sont partagés, les pages d'articles sont étiquetées avec « Article », les pages de services avec « Service », et les pages avec une hiérarchie de navigation sont étiquetées avec « BreadcrumbList ». Évitez d'appliquer des étiquettes à des types de pages qui n'y sont pas pertinents – une étiquette incorrecte est pire que l'absence d'étiquette.
