Vérificateur de schema IA

Cinq portent l'essentiel : author, datePublished, dateModified, publisher et sameAs. Les trois premières établissent la provenance, ce dont un moteur a besoin pour juger si votre page est à jour et qui se tient derrière. Publisher rattache le contenu à une organisation au lieu de le laisser orphelin. sameAs est la plus souvent absente et la plus sous-estimée. Elle relie votre entité à ses autres identités publiques, ce qui permet à un moteur d'établir que l'entreprise de votre site et celle mentionnée ailleurs sont la même. Sans elle, votre marque peut être citée comme plusieurs entités distinctes, ou n'être pas reconnue comme une entité du tout.

La réponse honnête est qu'aucun n'a publié de description complète de leur usage, et que quiconque affirme le contraire extrapole. Ce qui est documenté, c'est que les AI Overviews de Google reposent sur la même infrastructure que Google Search, qui lit abondamment les données structurées, et que plusieurs assistants ancrent leurs réponses dans des index de recherche qui les exploitent. La position défendable est que les données structurées coûtent peu, qu'elles lèvent une ambiguïté que la prose ne lève pas, et qu'elles sont déjà lues par la couche de recherche sur laquelle s'appuient la plupart des assistants. Ce n'est pas un levier qui produit des citations à lui seul, c'est une façon de supprimer l'ambiguïté sur qui vous êtes.

Le score mesure une couverture et non une qualité : lisez-le comme une liste de contrôle, pas comme une cible. Il pondère la présence des types clés à soixante-cinq pour cent et les propriétés d'attribution à trente-cinq. Tous les types ne s'appliquent pas à toutes les pages. Un article de blog n'a aucune raison de porter un balisage Product, et l'outil le marque non applicable plutôt que manquant. Ce qui compte vraiment, c'est qu'Organization et WebSite existent quelque part sur votre site, que les pages de contenu portent Article avec un auteur et des dates, et que les pages qui répondent à des questions portent FAQPage. Un score dans les quatre-vingts avec un manque assumé vaut mieux qu'un cent obtenu en déclarant des types que la page ne contient pas.

Cela signifie qu'une balise script se déclare en application/ld+json alors que son contenu n'est pas du JSON valide : aucun consommateur ne peut donc le lire. Les causes habituelles sont une virgule en trop, un guillemet non échappé dans une chaîne, ou un gabarit qui a injecté une valeur sans l'encoder. Cette panne est silencieuse. La page s'affiche normalement, rien n'apparaît dans vos journaux, et le balisage semble présent quand vous regardez le code source. Toutes les machines qui lisent la page ignorent le bloc entièrement : vous portez donc le coût de maintenance des données structurées sans en tirer aucun bénéfice. C'est à corriger en premier, avant d'ajouter le moindre balisage.

Non. Les données structurées doivent décrire ce qui se trouve réellement sur la page, et ajouter un balisage qui surestime le contenu est un vrai risque plutôt qu'un raccourci. Déclarer FAQPage sur une page sans questions, ou Product sur une page qui ne vend rien, fait partie de ce que les moteurs sanctionnent et de ce que les assistants apprennent à ignorer. L'approche utile est par couches. Organization et WebSite relèvent de l'ensemble du site, généralement du gabarit. BreadcrumbList relève de toute page située dans une hiérarchie. Article avec auteur et dates relève du contenu éditorial. FAQPage relève des pages où de vraies questions reçoivent une réponse. Tout le reste doit mériter sa place.