¿Dónde está el lugar ideal en el código para usar el marcado Schema.org como JSON-LD?


9

¿Dónde está el mejor lugar para colocar el marcado Schema.org que usa JSON-LD? Algunos recomiendan adentro, <head>pero los scripts también funcionan en línea. Sería más fácil en un MVC ponerlos en el mismo alcance que los controladores, por lo que eso significa en línea cerca de su elemento. Pero JSON-LD puede "funcionar mejor" como un gran script / stack en el <head>. No estoy seguro de la ubicación ideal, supongo.

El ejemplo sería migas de pan. ¿Debería simplemente colocar el script JSON-LD antes del marcado de las migas, o debería pasar por todos los problemas de cargar los modelos (nuevamente) para definirlos en el área que crea <head>? Parece que sería un éxito en el rendimiento, pero si vale la pena por la especificación, entonces debe hacerse.

Aquí hay un ejemplo de Organización en JSON-LD (esto ya estaría en <head>):

<script type="application/ld+json"> {
"@context" : "http://schema.org",
"@type" : "Organization",
"name" : "A Huge Corporation",
"url" : "http://www.example.com",
"logo" : "http://www.example.com/huge-corporation.png",
"founder" : "Humanz",
"foundingDate" : "1268",
"sameAs" : "http://plus.google.com/111111111111111111111",
"contactPoint" : {
    "@type" : "ContactPoint",
    "contactType" : "Customer Service",
    "telephone" : "+1-888-888-8888",
    "faxNumber" : "+1-777-777-7777",
    "contactOption" : "TollFree",
    "areaServed" : "US",
    "availableLanguage" : "English",
    "email" : "dude@example.com"
},
"hasPos" : {
    "@type" : "Place",
    "name" : "The Branch or Store",
    "photo" : "http://www.example.com/store.png",
    "hasMap" : {
        "@type" : "Map",
        "url" : "https://maps.google.com/maps?q=feed_me_a_map"
    },
    "address" : {
        "@type" : "PostalAddress",
        "name" : "The Branch or Store",
        "streetAddress" : "1547 Main Street",
        "addressLocality" : "Beverly Hills",
        "addressRegion" : "CA",
        "postalCode" : "90210",
        "addressCountry" : "United States"
    }
}}
</script>

Y aquí está el fragmento de pan rallado (actualmente reside en otro ámbito, más abajo en la página cerca de las migas visualmente visualizadas). Sería bueno tener esto en mente, si el trabajo lo vale:

<script type="application/ld+json"> {
"@context" : "http://schema.org",
"@type" : "Breadcrumblist",
"itemListElement" : [
    {
    "@type" : "ListItem",
    "position" : 1,
    "item" : {
        "@id" : "http:www.example.com",
        "name" : "Home"
        }
    },
    {
    "@type" : "ListItem",
    "position" : 2,
    "item" : {
        "@id" : "http:www.example.com/widgets",
        "name" : "Widgets"
        }
    },
    {
    "@type" : "ListItem",
    "position" : 3,
    "item" : {
        "@id" : "http:www.example.com/widgets/green",
        "name" : "Green Widgets"
        }
    }
]}
</script>

Respuestas:


8

A JSON-LD no le importa . Lo cual tiene sentido, porque los datos son los mismos, sin importar de qué parte del documento se extraigan.

Desde la perspectiva del HTML, solo debe incluirlo headsi el JSON-LD trata sobre su página web o sobre lo que representa su página web, porque el headelemento está definido para contener metadatos para el documento . Pero no siempre es fácil definir si algo cuenta como metadatos o no; No me preocuparía demasiado por esto.


Tiene sentido sobre el pensamiento <head> - probablemente terminará dejando la organización allí ... creo que cuenta como "meta" lo suficiente en el sentido de que está en cada página y proporciona una "etiqueta" identificable por decir.
dhaupin

y en el head, ¿no hay otra pieza de código que bloquee la representación de la página? Me preguntaba que antes </body>podría ser mejor por eso
João Pimentel Ferreira

1
@ JoãoPimentelFerreira: esperaría que no se bloquee, porque es un bloque de datos, no un script (ambos usan el scriptelemento, pero son casos técnicamente diferentes). Los navegadores podrían ignorar totalmente cualquier bloque de datos. Pero no sé qué hacen realmente los navegadores.
hasta
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.