Повторне використання розмітки Schema.org / Rich Snippets, тобто даних LocalBusiness


11

Я не можу знайти офіційні формулювання, і я сподіваюся, що якийсь Rich Snippets / Гуру схеми може дати мені деяке уявлення про правильне використання повторного контенту, коли мова йде про використання розмітки.

Я будую сайт, який хоче використовувати Schema.org як тип розмітки, і власник хотів би якомога більше використовувати. Назва компанії, телефон та адреса з’являться на кожній сторінці зараз, чи правильно чи навіть корисно використовувати Rich Snippets на кожній сторінці, де відображається ця інформація.

Наприклад, ця інформація відображається у верхньому та нижньому колонтитулі кожної сторінки сайту, а також наводите приклад моєї поточної розмітки, див. Нижче:

<body itemscope itemtype="http://schema.org/LocalBusiness">
<header>
    <a itemprop="url" href="http://www.domain.co.uk/">
        <img itemprop="logo" src="image.png" alt="Company Name Logo" />
    </a>
    <span itemprop="telephone">01202 000 000</span>
</header>
<div> This is where the content will go</div>
<footer>
  <span itemprop="name">Company Name</span>
  <span itemprop="description"> A small little bit about this company</span>
  <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
    <span itemprop="streetAddress">Address Goes here</span>
    <span itemprop="addressLocality">Area Here</span>,
    <span itemprop="addressRegion">Region Here</span>
  </div>
 </footer>
</body> !-- Local Business Schema Now Closed -->

Отже, як ви бачите вище, ця інформація відображатиметься на кожній сторінці. Чи правильно чи погано повторювати використання цієї інформації у форматі Schema.org?


Деякі семантичні розмітки, такі як авторство, призначені для дублювання на декількох сторінках. Я не впевнений, в чому сенс розмітки місцевого бізнесу, чи змінює він спосіб відображення сайту в SERP?
Стівен Остерміллер

1
Ні, але 90% схеми не впливає на SERPS ні в якій різкій формі, і використовуючи цю логіку, це означатиме, що схема є досить марною - тим більше, що вони хочуть її використовувати якомога більше, я не хвилююсь, як довго її не погана практика або негативний seo.
Simon Hayter

Відповіді:


6

Мікродані не мають поняття "сайт"; кожна сторінка окрема. Тому ви повинні включати всі відповідні метадані на кожній сторінці, де відображається відповідний вміст (але лише один раз на кожній сторінці).

  • Придумайте додаток для браузера, який відображає всі пари іменних значень Microdata на бічній панелі: чому користувачеві потрібно відвідувати певну сторінку вашого сайту, щоб побачити метадані на бічній панелі?

  • Подумайте про копіювання та вставлення або перетягування : чому метадані повинні бути включені до буфера обміну лише при копіюванні / перетягуванні вмісту з однієї конкретної сторінки сайту?

  • Подумайте про агента, який пропонує додати місцеву адресу компанії до адресної книги: чому користувачеві потрібно відвідувати одну конкретну сторінку вашого веб-сайту, щоб додати вашу адресу автоматично?


сказано, що "найкраща практика - тримати зосередженість і взагалі використовувати один тип верхнього рівня на даній сторінці". Передача LocalBusiness, Organizationі т.д. , як типи верхнього рівня (через масив верхнього рівня] , здається, суперечить цій ідеї Якщо ми прагнемо до гнізда. LocalBusinessУ більш конкретних типів, наприклад , Articleабо ProductЧи просто пройти кілька типів верхнього рівня як масив?
Ронні Ройстон

1
@RonRoyston: Найкраща практика використання властивостей для підключення елементів, що, як правило, призводить до наявності лише одного елемента верхнього рівня: WebPage- і Organizationє publisher, Article/ Productє і mainEntityт.д.
unor

1

Я вважаю, що розмітка на кожній сторінці нормальна, але я мав би всі екземпляри використовувати загальний URL (сторінку про бізнес) та загальний ідентифікатор (itemid у мікроданих). Це буде сигналом, який свідчить про те, що всі вони стосуються однієї сутності.

Посилана URL-адреса повинна бути сторінкою про бізнес, яка включає набагато більш детальну версію розмітки. Знову ж, використовуючи той самий id, щоб системи могли підключати точки.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.