Explication de JSON-LD pour un site web personnel

 (hawksley.dev)
2 points par GN⁺ 8 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Même un site web personnel peut tirer parti des données structurées : elles aident les crawlers à mieux comprendre les relations entre les pages, la personne et les articles, et peuvent améliorer les aperçus de liens ainsi que la qualité de l’affichage dans les résultats de recherche
  • L’implémentation consiste à placer dans le <head> un <script type="application/ld+json">, à définir @context sur Schema.org, puis à disposer dans @graph des nœuds comme WebSite, Person et BlogPosting
  • Lorsqu’on réutilise le même @id, les crawlers web peuvent fusionner les propriétés de nœuds provenant de plusieurs pages, mais les scrapers ou les LLM qui ne lisent qu’une seule page ne le font pas
  • Sur la page racine, on place généralement WebSite, ProfilePage et Person ; pour les pages de blog, de projets ou de listes, on ajoute selon le cas Blog, BlogPosting, SoftwareApplication, CollectionPage et BreadcrumbList
  • Les champs sameAs de Person, breadcrumb des pages, ainsi que image, license et les dates des articles servent directement à l’identification de la personne, au chemin affiché dans les résultats de recherche, à l’aperçu des articles, aux conditions d’utilisation et à l’évaluation de leur fraîcheur

Rôle de JSON-LD et structure de base

  • JSON-LD signifie JSON Linked Data ; c’est un format permettant d’ajouter des données structurées à une page web
  • Il aide les crawlers à comprendre la structure sémantique d’un site et peut contribuer à des aperçus de liens plus riches ainsi qu’à une amélioration potentielle du classement dans les moteurs de recherche
  • Pour l’ajouter à une page, on insère dans la section <head> un script de la forme suivante
    • <script type="application/ld+json"> déclare le type MIME application/ld+json
    • Une fois ce type indiqué, le moteur JavaScript du navigateur ne l’exécute pas
    • Des crawlers spécialisés comme Googlebot repèrent cet élément et en analysent le contenu

@context, @graph et identifiants de nœuds

  • @context définit le contexte suivi par les données JSON-LD, et les crawlers web utilisent Schema.org comme standard
  • Schema.org définit les paires clé-valeur valides utilisables dans le JSON
  • Un document JSON-LD peut être vu comme un graphe orienté étiqueté, et les données sont stockées sous @graph
  • Le graphe peut contenir plusieurs nœuds, reliés entre eux par des liens orientés
  • Chaque nœud se compose des éléments suivants
    • @type : indique ce qu’est le nœud. Ex. : WebSite, SoftwareApplication
    • @id : identifiant du nœud, généralement une URL suivie d’un fragment hash unique
    • Propriétés : paires clé-valeur décrivant les caractéristiques du nœud
  • Les crawlers web peuvent fusionner sur plusieurs pages les propriétés des nœuds qui partagent le même @id
  • En revanche, les scrapers ou LLM qui ne lisent qu’une seule page ne fusionnent pas les propriétés ; il faut donc tenir compte de cette différence lorsqu’on réutilise le JSON-LD sur plusieurs pages
  • Pour @id, il est recommandé d’ajouter à l’URL un fragment identifiant unique comme #website

Nœuds décrivant le site et les pages

  • WebSite

    • WebSite contient les métadonnées du site et donne aux crawlers des indices sur la façon de l’afficher
    • Sur la page racine, on peut utiliser une version détaillée incluant des propriétés comme url, name, alternateName, description, inLanguage, publisher et image
    • Il n’est pas nécessaire d’inclure le nœud WebSite complet sur toutes les pages
    • Il vaut mieux détailler la page racine du domaine et, sur les autres pages, une version abrégée avec seulement @type, @id, url et name suffit
    • Cette version abrégée fournit le contexte nécessaire pour que les crawlers qui ne lisent qu’une seule page identifient correctement le nom du site

  • WebPage

    • WebPage représente la page actuelle elle-même, c’est-à-dire la page HTML physique
    • Il faut le distinguer d’un type de contenu comme BlogPosting : WebPage désigne la page qui héberge ce contenu
    • Parmi les propriétés courantes figurent url, isPartOf, name, inLanguage et breadcrumb
    • ProfilePage et CollectionPage sont des sous-types plus spécifiques de WebPage
    • D’autres sous-types moins courants sont listés dans la définition de WebPage sur Schema.org

Identification personnelle et page de profil

  • Person

    • Il est recommandé d’ajouter un nœud Person sur toutes les pages d’un site personnel
    • Person indique qui est le propriétaire du site et entre en jeu dans certains indicateurs de qualité de contenu de Google
    • Les crawlers de LLM utilisent aussi de plus en plus les informations Person pour décider qui citer dans leurs réponses
    • Contrairement à WebSite, Person constitue un contexte suffisamment important pour être inclus sur toutes les pages
    • Les propriétés importantes sont les suivantes
      • url : pointe vers la page racine pour ancrer le nœud
      • name, givenName, familyName : expriment clairement l’identité
      • image : si possible, utilise une photo de la personne ou un logo pertinent pour lier une image officielle
      • sameAs : signale d’autres profils aux crawlers afin d’aider à l’identification
    • sameAs est particulièrement utile pour distinguer les homonymes lorsqu’on porte un nom courant, et sert à construire une représentation en graphe de connaissances sur plusieurs pages
    • D’autres propriétés de Person peuvent enrichir les détails, mais ne sont pas indispensables ; les omettre a peu d’impact

  • ProfilePage

    • ProfilePage désigne une page du site consacrée à une personne donnée
    • Si la page d’accueil sert à se présenter, on peut l’y utiliser ; s’il existe une page about distincte, il peut être plus pertinent de l’y placer
    • Il est important de le relier au nœud WebSite plus large via isPartOf
    • mainEntity indique aux crawlers de qui parle cette page
    • dateCreated et dateModified sont utiles comme signaux de fraîcheur, mais il ne faut pas trop s’en préoccuper si le site ne peut pas facilement les fournir

Projets et affichage du chemin

  • SoftwareApplication

    • Si une page présente un logiciel, il est utile d’y inclure un nœud SoftwareApplication pour en décrire les métadonnées
    • Des types plus spécifiques comme MobileApplication, WebApplication ou VideoGame peuvent aussi être utilisés
    • La propriété url doit pointer vers l’endroit où le projet est distribué
    • Une page de distribution comme crates.io en est un exemple
    • sameAs sert pour d’autres pages liées au projet, comme un dépôt de code source
    • Les valeurs valides de applicationCategory sont indiquées dans la définition de SoftwareApplication par Google
    • Même pour un projet FOSS, il faut inclure offers et définir le prix à 0

  • BreadcrumbList

    • BreadcrumbList est largement utile sur toutes les pages sauf la page racine
    • Il représente le chemin de navigation de la page, sans devoir nécessairement correspondre exactement à l’URL réelle
    • Il peut servir à contrôler la façon dont les moteurs de recherche affichent le chemin d’une page donnée
    • Si le chemin du site est déjà court, l’intérêt de ce nœud est limité et on peut l’omettre
    • Sur les sites aux chemins longs, BreadcrumbList aide à raccourcir le chemin affiché dans les résultats de recherche

Pages de liste, blog et articles

  • CollectionPage

    • CollectionPage est un sous-type de WebPage principalement utilisé pour les pages contenant des listes
    • Une page /elsewhere/ regroupant d’autres profils ou une page /blog/ listant des billets de blog en sont des exemples
    • On peut y relier le nœud Person associé via about
    • breadcrumb doit impérativement pointer vers le bon BreadcrumbList de la page actuelle

  • Blog

    • Le nœud Blog s’ajoute à l’index ou à la page d’accueil du blog
    • Il joue le rôle de nœud intermédiaire entre WebSite et les différents BlogPosting
    • dateModified est utile comme signal de fraîcheur, mais peut être omis s’il n’est pas simple à fournir
    • license permet aux crawlers de savoir sous quelles conditions les articles peuvent être utilisés
    • Sur un site personnel, publisher peut être défini sur Person plutôt que sur Organization
    • La documentation Google l’autorise désormais explicitement, et cela peut être plus juste pour un site personnel

  • BlogPosting

    • BlogPosting doit figurer sur chaque billet de blog publié
    • Il fournit des informations supplémentaires pour permettre aux crawlers de représenter l’article plus précisément
    • Il peut être utilisé pour améliorer le positionnement et les détails enrichis dans les résultats de recherche
    • Sur un site personnel, author et publisher peuvent tout à fait pointer vers le même nœud Person
    • Il est préférable d’aligner la propriété image sur l’image OG déjà utilisée pour l’aperçu du lien de l’article
    • license peut servir à indiquer les conditions d’utilisation du billet

Implémentation minimale et critères d’application

  • Le JSON-LD nécessaire à un site personnel peut être composé de façon sélective selon la nature de chaque page
  • Même un site statique sans étape de build peut en tirer parti en ajoutant au minimum les nœuds suivants sur la page racine
    • WebSite
    • ProfilePage
    • Person
  • Si le site comporte un blog, on peut ajouter Blog et BlogPosting, et utiliser CollectionPage pour les pages listant des articles ou des profils externes
  • Pour les pages de présentation de projet, on peut envisager SoftwareApplication, et pour les pages autres que la racine, BreadcrumbList

À lire aussi

1 commentaires

 
GN⁺ 8 시간 전
Commentaires sur Hacker News

  • Pour reprendre une métaphore, on a l’impression de refaire la guerre précédente
    Du point de vue de mon site WWW, Google affiche désormais en haut un long résumé généré par LLM truffé d’erreurs, au lieu d’envoyer les gens vers mes vrais articles
    Obtenir un joli nom d’affichage à la place d’un « fil d’Ariane » ou d’un domaine ne change rien à la réalité : Google accorde de moins en moins de priorité au fait d’embellir ou non ces éléments
    En pratique, cela revient à investir énormément d’efforts dans quelque chose que les visiteurs du site ne verront jamais directement, et que les utilisateurs de Google auront du mal à trouver, relégué sous la version LLMisée de Google lui-même

    • Si on veut d’un monde où ces données ont du sens, il faut d’abord semer les graines
      Même si Google ne les utilise pas, si l’ensemble d’Internet adopte ce type de métadonnées, cela crée un terrain favorable pour que des concurrents proposant des alternatives, sans passer par le scraping des LLM, puissent émerger
      Se soumettre à Google ne fait que renforcer sa domination, relever les barrières à l’entrée pour les concurrents et les pousser, eux aussi, à utiliser les mêmes techniques
    • C’est exactement ça. Notre entreprise apparaît désormais ainsi dans Google Search :
      $STATE est une société IT basée dans l’État, spécialisée dans la création de workflows d’IA pratiques et de solutions de gestion de l’information pour les entreprises du Midwest. Elle fonctionne avec un modèle contractuel agile à prix fixe et se concentre sur la fourniture de résultats concrets sans les lourdeurs des grandes structures d’entreprise
      J’ignorais que nous proposions désormais des workflows d’IA pratiques
      Ensuite, Google mélange le nom d’un concurrent au nom similaire mais clairement différent, et m’affiche comme cadre dirigeant. Le seul point positif, c’est que le concurrent cache ses coordonnées derrière un formulaire « réserver une consultation », donc seules les nôtres s’affichent
    • Je n’autorise même plus Google à crawler et indexer mon site
    • Google fait désormais aussi partie des cibles qui, « quand un bot entre sur le site, reçoivent une zipbomb de 10GB »
      À ce stade, cela n’apporte plus aucune valeur et ne fait qu’ajouter des problèmes
    • Oui. Pendant des années, j’ai bourré mon site de balises et d’attributs microdata dans l’espoir d’obtenir du trafic
      Au final, je n’ai fait qu’entraîner l’IA de Google pour que les gens ne quittent pas Google

  • Si vous avez une approche pragmatique, je recommande de lire la documentation Google sur JSON-LD pour les sites web
    https://developers.google.com/search/docs/appearance/structu...
    Vous verrez aussi qu’une grande partie des informations ne concerne que certains types de sites. Rotten Tomatoes peut publier des notes de critiques de films en JSON-LD, mais même si j’écris des critiques de films, ce n’est pas vraiment pertinent pour moi
    JSON-LD est simple et les moteurs de recherche l’utilisent réellement, donc c’est acceptable. Il peut dupliquer des informations déjà présentes dans la page web, mais le rêve d’annoter parfaitement les données pour qu’une information n’apparaisse qu’une seule fois dans le document me semble relever d’une idéalisation du type vache sphérique et corde sans masse
    Créer une page web demande déjà un effort humain, et un peu de duplication dans le résultat final n’a rien de grave

    • On peut utiliser JSON-LD pour des critiques de films même sans avoir un gros site
      Sur mon site, je l’utilise pour des critiques de livres, de jeux et de films, et la plupart des moteurs de recherche semblent afficher des informations comme la note en étoiles
    • 403. That’s an error.
      Il est indiqué que le client n’est pas autorisé à récupérer l’URL /search/docs/appearance/structured-data/intro-structured-data sur ce serveur
    • Mais si on duplique les données, la consommation d’eau va augmenter. /s

  • Pour les aperçus enrichis de liens, OpenGraph est bien plus souvent pris en charge que JSON-LD
    Pour l’optimisation pour les moteurs de recherche, les types de JSON-LD pris en charge par les moteurs sont très spécifiques et limités. Il vaut bien mieux consulter la documentation du moteur visé, c’est-à-dire Google[1] ou Bing[2], et suivre cela à la lettre ; le reste est presque une perte de temps
    En dehors des moteurs de recherche, JSON-LD est généralement peu utile s’il n’existe pas d’objectif précis. S’il y a un besoin concret de JSON-LD, on peut y mettre les données utiles ; sinon, ajouter d’autres données revient un peu à crier dans le vide
    IndieWeb[3] utilise des données structurées, mais considère JSON-LD comme une violation du principe DRY et utilise à la place des Microformats[4]
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • Ce qu’on veut réellement implémenter sur tous les sites web, ce sont des données structurées utilisant le vocabulaire Schema.org
    JSON-LD n’est qu’une des méthodes possibles, il y a aussi RDFa et Microdata
    Je m’étais appuyé sur cet article quand j’ai commencé à apprendre le sujet, et il vaut le détour : https://neilpatel.com/blog/get-started-using-schema/
    On peut explorer quelles données ajouter avec cet outil : https://technicalseo.com/tools/schema-markup-generator/
    La liste complète est disponible sur le site de schema.org : https://schema.org/docs/schemas.html

  • Il y a quelques années, j’ai découvert que les fonctions avancées des e-mails, comme l’insertion de billets d’avion ou l’affichage d’informations de suivi de livraison, étaient entièrement implémentées via du JSON-LD dans les e-mails
    Mais à ma connaissance, seul Gmail le prend en charge
    Plus d’infos : https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook et iCloud prennent aussi en charge certaines fonctions comme les billets ou les réservations

  • Je me demande si ces attributs aident réellement à la visibilité dans les résultats de recherche, ou s’ils servent surtout à permettre aux moteurs de recherche de garder plus facilement les utilisateurs sur leur propre page de résultats

    • Après avoir ajouté JSON-LD, Google a commencé à afficher des liens secondaires menant vers des pages internes de mon site. Ça, c’était plutôt bien
    • Pour un site d’entreprise, JSON-LD peut servir à alimenter les plateformes cartographiques en données
      comme l’adresse, les horaires d’ouverture, le numéro de téléphone ou le menu

  • On a déjà du HTML sémantique, et pourtant, de façon assez étrange, il faut encore réexprimer le sens d’un site web dans un JSON personnalisé bizarre placé dans une balise script que le navigateur ne traite même pas

    • J’ai testé JSON-LD sur mon site, et je pense qu’il répond à un besoin distinct du HTML sémantique
      Le HTML sémantique sert à indiquer ce que le navigateur traite, comme les titres et les en-têtes. Les données JSON-LD, elles, relèvent des métadonnées comme la date de création, la date de modification, les tags ou l’auteur
      On peut aussi exprimer tout cela dans le HTML avec du microdata, mais JSON-LD est plus simple, donc j’ai arrêté d’utiliser microdata
      JSON-LD est alimenté à partir des mêmes données que celles utilisées pour générer le site, et ces métadonnées me servent aussi à créer des pages d’index comme la liste des billets de blog de 2024 ou tous les articles liés au sujet X. Le principal consommateur de JSON-LD reste les moteurs de recherche
      Et si tu veux t’énerver encore plus, pense au fait qu’on ajoute aussi des métadonnées OpenGraph sur la même page. Ça fait donc deux formats de métadonnées différents sur une seule page
    • Il y a aussi Microdata, qui, si je ne me trompe pas, prend en charge le même vocabulaire que JSON-LD. schema.org est une bonne ressource
      Mais JSON-LD est devenu la valeur par défaut depuis un moment, un peu comme quand on a largement abandonné REST au profit de RPC. Je ne sais même pas si tous les parseurs importants prennent encore complètement en charge microdata, et surtout, quand on développait des sites clients comme des sites e-commerce voulant de la visibilité dans Google, on partait par défaut sur du LD
      Il y a aussi un point intéressant par rapport au HTML sémantique. Le HTML sémantique aide à définir la structure du balisage, mais il ne permet pas d’exprimer jusqu’au contexte du monde réel comme « ceci est un produit en vente » ou « ceci est un horaire de train »
    • J’ai l’impression de ne pas avoir bien compris l’article
      On peut utiliser des ontologies comme Schema.org/FOAF/WikiData dans le HTML même, sans JSON-LD ni balise script
    • Dans un monde idéal, le serveur et le navigateur pourraient faire de la négociation de contenu, et le navigateur commencerait par demander uniquement le JSON-LD du site web avant d’utiliser son propre format de rendu interne
    • Le HTML sémantique ne couvre pas tout le périmètre traité par JSON-LD et les autres microformats
      Rien qu’avec les exemples de l’article, on peut se demander quels éléments sémantiques existent en HTML pour représenter une personne, un fil d’Ariane, une application logicielle, un blog ou un billet de blog
      Le HTML sémantique sert à aider les personnes utilisant des lecteurs d’écran à naviguer dans des éléments génériques comme « navigation » ou « article »

  • En gros, ce n’est pas juste OpenGraph écrit en JSON ? Quel est l’avantage ?

  • Depuis 2024, le trafic vers nos pages marketing basées sur le contenu a chuté d’environ 85 %
    Ce que je ne comprends pas, c’est que si les pages de résultats sans clic se sont multipliées, Google n’aurait-il pas dû être lui aussi fortement touché ?
    Les revenus publicitaires des pages de résultats, qui reposent eux aussi sur les clics, auraient dû baisser de manière tout aussi sévère, mais je n’ai pas trouvé de chiffres publics permettant d’infirmer ou de confirmer cette hypothèse

  • Il existe un équilibre subtil où, passé un certain point, une relation symbiotique se transforme en exploitation
    La relation dans laquelle les sites web gagnaient en visibilité grâce aux moteurs de recherche était en grande partie mutuellement bénéfique
    Mais aujourd’hui, on se dirige clairement vers une situation où les propriétaires de sites ne retirent plus rien du travail qu’ils ont produit à la sueur de leur front