Onde é o local ideal no código para usar a marcação Schema.org como JSON-LD?


9

Onde é o melhor lugar para colocar a marcação Schema.org que usa JSON-LD? Alguns recomendam o interior, <head>mas os scripts também funcionam em linha. Seria mais fácil em um MVC colocá-los no mesmo escopo que os controladores, o que significa em linha próximo ao elemento. Mas o JSON-LD pode "funcionar melhor" como um enorme script / pilha no <head>. Não tenho certeza da localização ideal que suponho.

Exemplo seria migalhas de pão - devo apenas colocar o script JSON-LD antes da marcação para as migalhas, ou devo passar por todo o trabalho de carregar os modelos (novamente) para defini-los na área que cria o <head>? Parece que seria um sucesso de desempenho, mas se vale a pena para as especificações, ele precisa ser feito.

Aqui está um exemplo de organização em JSON-LD (isso já estaria em <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>

E aqui está o trecho da trilha de navegação (atualmente reside em outro escopo, mais abaixo na página, próximo às migalhas visualmente renderizadas). Seria bom ter isso em mente, se o trabalho vale a pena:

<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>

Respostas:


8

JSON-LD não se importa . O que faz sentido, porque os dados são os mesmos, independentemente de onde no documento são extraídos.

Da perspectiva do HTML, você deve apenas incluí-lo no headcaso o JSON-LD seja sobre sua página da web ou sobre o que ela representa, porque o headelemento está definido para conter metadados para o documento . Mas nem sempre é fácil definir se algo conta como metadados ou não; Eu não me preocuparia muito com isso.


Faz sentido sobre o pensamento <head> - provavelmente acabará deixando a organização lá em cima ... acho que conta como "meta" o suficiente no sentido em que está em todas as páginas e fornece uma "tag" identificável por assim dizer.
dhaupin

e no head, não há mais um pedaço de código bloqueando a renderização da página? Eu queria saber que antes o </body>poderia ser melhor por causa disso
João Pimentel Ferreira

11
@ JoãoPimentelFerreira: Eu esperaria que não bloqueie, porque é um bloco de dados, não um script (ambos usam o scriptelemento, mas são casos tecnicamente diferentes). Os navegadores podem ignorar totalmente qualquer bloco de dados. Mas não sei o que os navegadores realmente fazem.
Unor
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.