Gdzie jest idealne miejsce w kodzie do używania znaczników Schema.org jako JSON-LD?


9

Gdzie najlepiej umieścić znaczniki Schema.org korzystające z JSON-LD? Niektórzy polecają w środku, <head>ale skrypty również działają wbudowane. W MVC łatwiej byłoby umieścić je w tym samym zakresie, co kontrolery, więc oznacza to wbudowanie blisko ich elementu. Ale JSON-LD może „działać lepiej” jako jeden wielki skrypt / stos w <head>. Po prostu nie jestem pewien idealnej lokalizacji.

Przykładem może być bułka tarta - czy powinienem po prostu umieścić skrypt JSON-LD przed znacznikami okruchów, czy też powinienem przejść przez cały trud załadowania modeli (ponownie), aby zdefiniować je w obszarze tworzenia <head>? Wygląda na to, że byłby hitem wydajności, ale jeśli jest to warte specyfikacji, należy to zrobić.

Oto przykład organizacji w JSON-LD (byłby <head>już dostępny):

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

A oto fragment kodu nawigacyjnego (obecnie znajduje się w innym zakresie, dalej w dół strony w pobliżu wizualnie renderowanych okruchów). Byłoby miło, aby to sobie wyobrazić, jeśli praca jest tego warta:

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

Odpowiedzi:


8

JSON-LD nie obchodzi . Ma to sens, ponieważ dane są takie same, bez względu na to, z którego miejsca w dokumencie zostaną wydobyte.

Z perspektywy HTML powinieneś umieścić go tylko headwtedy, gdy JSON-LD dotyczy twojej strony internetowej lub tego, co reprezentuje twoja strona internetowa, ponieważ headelement jest zdefiniowany tak, aby zawierał metadane dla dokumentu . Ale nie zawsze łatwo jest określić, czy coś liczy się jako metadane, czy nie; Nie martwiłbym się tym zbytnio.


Ma sens w związku z myślą <head> - prawdopodobnie skończy się na opuszczeniu organizacji tam na górze .... myślę, że liczy się ona jako wystarczająco "meta" w tym sensie, że jest na każdej stronie i zapewnia identyfikowalny "tag" na słowo.
dhaupin,

a w headdalszej części, czy dalszy fragment kodu nie blokuje renderowania strony? Zastanawiałem się, czy wcześniej </body>mogło być lepiej z tego powodu
João Pimentel Ferreira

1
@ JoãoPimentelFerreira: Spodziewałbym się, że nie blokuje, ponieważ jest to blok danych, a nie skrypt (oba używają scriptelementu, ale są to technicznie różne przypadki). Przeglądarki mogą całkowicie zignorować dowolny blok danych. Ale nie wiem, co faktycznie robią przeglądarki.
Unor
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.