Де ідеальне місце в коді для використання розмітки 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> думці - проблема в кінцевому підсумку залишить організацію там .... я думаю, що вона вважається достатньо "мета" в тому сенсі, що її розміщено на кожній сторінці, і надає ідентифікований "тег" за кожним висловом.
dhaupin

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

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