Pourquoi les moteurs de recherche ne prennent-ils pas en charge JSON-LD + Schema.org en tant que points de terminaison séparés via rel = "alternate" ou script src?

Question

Donc toute l’idée de JSON tourne autour d’objets> tableaux présentés dans un format texte simple. La variante LD n'est pas différente. Combiné à Schema.org, il se transforme en une API d’affichage flexible que de nombreuses choses peuvent consommer, très similaire aux flux existants. Contrairement aux flux, les moteurs de recherche consomment principalement données de script inline sur la page, ce qui rend les choses fastidieuses et gênantes du point de vue de l'API ou de l'automatisation.

Alors, pourquoi les moteurs de recherche veulent-ils que JSON-LD + Schema.org s’oppose au grain de l’API en ce qui concerne l’obligation d’utiliser des sites inline data? Pourquoi devons-nous rendre notre code beaucoup plus volumineux avec des données en double, telles que le contenu principal pour la visualisation humaine, puis à nouveau définies séparément dans le ou les scripts JSON-LD? Ce que je veux dire, c'est que si LD est destiné à la consommation sémantique, pourquoi ne pouvons-nous pas placer les objets LD dans une page, une route ou un fichier distinct (e)? La duplication des données dans les sources me rend fou, surtout pour les longs contenus!

À l'heure actuelle, aucun validateur de moteur de recherche ne comprend le cas d'utilisation suivant:

Example.com a une page de modèles complète pour chaque produit, avec une URL telle que https://www.example.com/this-product-name. Cette page est validée en HTML avec toutes les cloches et sifflets. Il n'inclut pas de balisage Schema.org dans la vue basée sur un modèle.
Example.com possède également une fonction de génération JSON-LD qui provient directement d'un contrôleur et crée un point de terminaison API pour chaque produit. Tout ce qui est renvoyé, ce sont les tableaux LD objet-> au format JSON ... pas de modèle. Ceci est prêt à la consommation et similaire au chemin d'un flux XML pour les agrégateurs. L'ajout de /json à l'URL restitue ce type de réponse d'objet API LD à la place de la page complète basée sur des modèles. Donc, la route serait: https://www.example.com/this-product-name/json
La page modèle complète de chaque produit comprend un <link /> dans <head> qui pointe vers son noeud final alternate LD décrit ci-dessus. C’est la même chose que ATOM les flux fonctionnent, indiquant ainsi au visiteur le "format de remplacement pour les données" utilisé par les lecteurs de flux. Donc, le remplaçant pour le LD ressemblerait à ceci: <link rel="alternate" type="application/ld+json" title="This Products Consumption API (JSON-LD + Schema.org)" href="https://www.example.com/this-product-name/json"/>
La réponse JSON-LD inclut sameAs et quelque chose comme potentialAction renvoyant à la version complète de la page, basée sur un modèle (la première puce ci-dessus). Ceci est similaire à la façon dont alternate fonctionne dans ATOM se nourrit d'eux-mêmes ... créant ainsi un cercle de remplaçants.
Le flux ATOM inclut également ces alternatives, exposant les points d'extrémité /json. Fondamentalement, il existe un chemin (entre 3 et plus) entre la page modèle, le point de terminaison JSON-LD, le flux ATOM, etc. Toutes les données sont identiques, il s'agit simplement de différentes méthodes d'affichage des formats de consommation à des fins différentes. .
Exécuter https://www.example.com/this-product-name tout au long des tests de l'extrait de code aboutit à "aucune donnée structurée trouvée", même en incluant le chemin d'accès au script src comme <script type="application/ld+json" src="https://www.example.com/this-product-name/json"></script> . Exécution du point de terminaison de consommation https://www.example.com/this-product-name/json grâce à une validation correcte.

Alors, s'agit-il simplement d'un outil de validation ou n'y a-t-il vraiment aucun moyen de permettre aux robots de comprendre l'assimilation alternative? Existe-t-il une manière any d'obtenir le JSON-LD de ma page modèle et de le placer dans un autre chemin d'API, comme le fait déjà si bien la spécification JSON elle-même? Me manque-t-il une énorme raison pour laquelle les moteurs de recherche ont choisi d'exiger que LD mette exclusivement en ligne au lieu de permettre des capacités d'analyse de terminal?

Swordfish · Answer

Cette réponse est en fait assez simple. Les araignées récupèrent une page et traitent cette page et uniquement cette page. Les liens vers d'autres ressources sont mis en file d'attente pour la visite d'une autre araignée. Les moteurs de recherche ignorent les balises de script ayant une source. De par sa conception, Javascript contient NOT des données et les moteurs de recherche ont soif de données ..

Le principal avantage de l'utilisation de json-ld sur itemscope et itemprop est que votre balisage lui-même n'est pas encombré de microdonnées.

Si vous ne souhaitez pas inclure de données "brutes" dans votre page, vous devriez envisager d'utiliser des schémas RFDa. Des schémas peuvent être spécifiés lier le.

Personnellement, j’utilise autant que possible MicroFormats, car j’estime que le format le moins intrusif de tous les formats de microdonnées en tant que propriétés est déguisé en classe CSS. Classis pour lesquels j'attribue un style.