Qual è il posto ideale nel codice per utilizzare il markup Schema.org come JSON-LD?


9

Qual è il posto migliore dove inserire il markup Schema.org che utilizza JSON-LD? Alcuni raccomandano all'interno <head>ma anche gli script funzionano in linea. In un MVC sarebbe più semplice inserirli nello stesso ambito dei controller, in modo che significhino in linea vicino al loro elemento. Ma JSON-LD potrebbe "funzionare meglio" come un enorme script / stack nel <head>. Non sono sicuro della posizione ideale, suppongo.

Un esempio potrebbe essere il pangrattato: devo solo mettere lo script JSON-LD prima del markup per le briciole o dovrei affrontare tutti i problemi di caricamento (di nuovo) dei modelli per definirli nell'area che crea il <head>? Sembra che sarebbe un successo prestazionale, ma se ne vale la pena per le specifiche, allora deve essere fatto.

Ecco un esempio di Organizzazione in JSON-LD (questo sarebbe <head>già in):

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

Ed ecco lo snippet breadcrumb (attualmente risiede in un altro ambito, più in basso nella pagina vicino alle briciole rese visivamente). Sarebbe bello avere questo in testa, se ne vale la 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>

Risposte:


8

A JSON-LD non importa . Il che ha senso, perché i dati sono gli stessi, indipendentemente da dove nel documento vengono estratti.

Dal punto di vista HTML, dovresti includerlo solo headse JSON-LD riguarda la tua pagina web o ciò che rappresenta la tua pagina web, poiché l' headelemento è definito per contenere metadati per il documento . Ma non è sempre facile definire se qualcosa conta o meno come metadati; Non mi preoccuperei troppo di questo.


Ha un senso sul pensiero <head> - finirà probabilmente per lasciare l'organizzazione lassù .... penso che contenga abbastanza "meta", nel senso che si trova su ogni singola pagina e fornisce un "tag" identificabile per dire.
Dhaupin,

e nel head, non è un ulteriore pezzo di codice che blocca il rendering della pagina? Mi chiedevo che prima che </body>potesse essere migliore per questo
João Pimentel Ferreira,

1
@ JoãoPimentelFerreira: mi aspetto che non si blocchi, perché è un blocco di dati, non uno script (entrambi utilizzano l' scriptelemento, ma sono casi tecnicamente diversi). I browser potrebbero ignorare totalmente qualsiasi blocco di dati. Ma non so cosa facciano effettivamente i browser.
unor
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.