Где в коде идеальное место для использования разметки Schema.org в качестве JSON-LD?


9

Где лучше всего разместить разметку Schema.org, использующую JSON-LD? Некоторые рекомендуют изнутри, <head>но скрипты тоже работают внутри . В MVC было бы проще поместить их в ту же область, что и контроллеры, так что это означает, что они встроены рядом с их элементом. Но JSON-LD может «работать лучше» как один огромный скрипт / стек в <head>. Я просто не уверен в идеальном месте, я полагаю.

Примером могут служить хлебные крошки - я должен просто поставить сценарий JSON-LD перед разметкой для крошек, или мне нужно пройти через все проблемы загрузки моделей (снова), чтобы определить их в области создания <head>? Похоже, это будет удар по производительности, но если оно того стоит для спецификации, то это нужно сделать.

Вот пример организации в JSON-LD (это было бы <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>

А вот фрагмент крошки (в настоящее время находится в другой области, далее вниз по странице рядом с визуально визуализированными крошками). Было бы неплохо получить это в голову, если работа того стоит:

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

Ответы:


8

JSON-LD не волнует . Это имеет смысл, потому что данные одинаковы, независимо от того, откуда в документе они извлекаются.

С точки зрения HTML, вы должны включать его только в том headслучае, если JSON-LD относится к вашей веб-странице или к тому, что представляет ваша веб-страница, поскольку headэлемент определен как содержащий метаданные для документа . Но не всегда легко определить, считается ли что-то метаданными или нет; Я бы не стал сильно беспокоиться об этом.


Имеет смысл в мысли о <head> - в конечном итоге это может привести к тому, что организация останется там наверху ... Я думаю, что она считается достаточно "мета" в том смысле, что она есть на каждой странице и обеспечивает идентифицируемый "тег" для каждого высказывания.
дхаупин

и в head, не является ли дальнейшая часть кода, блокирующая рендеринг страницы? Мне было интересно, что раньше </body>могло быть лучше из-за этого
Жоао Пиментел Феррейра

1
@ JoãoPimentelFerreira: Я ожидаю, что он не блокируется, потому что это блок данных, а не сценарий (оба они используют scriptэлемент, но это технически разные случаи). Браузеры могут полностью игнорировать любой блок данных. Но я не знаю, что на самом деле делают браузеры.
ОООНР
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.