Чи можна вводити мікродані в метатеги?


12

Будь ласка, врахуйте наступний код, позначений атрибутами для надання мікроданих:

<!DOCTYPE html>
<html>
    <head>
        <title>Micro data test - Normal version</title>
    </head>
    <body>
        <div itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Product name</h1>
            <img alt="" itemprop="image" src="http://placehold.it/200x200" />
            <div itemprop="description">This is the product description.</div>
            <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
                <meta content="in_stock" itemprop="availability" />
                <span content="GBP" itemprop="priceCurrency">£</span><span itemprop="price">100.00</span>
            </div>
        </div>
    </body>
</html>

Використання інструменту тестування структурованих даних Google дає позитивні результати.

Це добре в прикладі тесту, проте ми хочемо впровадити мікродані на різних сайтах, структура HTML яких сильно відрізняється. Щоб реалізувати атрибути таким чином, потрібно, щоб хтось вручну редагував розмітку HTML на кожному з сайтів окремо.

Переважно, ми хотіли б мати можливість викликати одну функцію, яка пакує всі мікродані в одному місці; технічно це можливо, використовуючи метатеги наступним чином:

<!DOCTYPE html>
<html>
    <head>
        <title>Micro data test - Meta tag version</title>
    </head>
    <body>
        <meta itemscope itemtype="http://schema.org/Product" itemref="microName microImage microDescription microOffer" />
        <meta id="microName" itemprop="name" content="Product name" />
        <link id="microImage" itemprop="image" href="http://placehold.it/200x200" />
        <meta id="microDescription" itemprop="description" content="This is the product description." />
        <meta id="microOffer" itemprop="offers" itemscope itemtype="http://schema.org/Offer" itemref="microCurrency microPrice microAvail" />
        <meta id="microAvail" itemprop="availability" content="in_stock" />
        <meta id="microCurrency" itemprop="priceCurrency" content="GBP" />
        <meta id="microPrice" itemprop="price" content="100.00" />
        <div>
            <h1>Product name</h1>
            <img alt="" src="http://placehold.it/200x200" />
            <div>This is the product description.</div>
            <div>£100.00</div>
        </div>
    </body>
</html>

Використання інструменту тестування структурованих даних Google дає ті ж позитивні результати, що і перший тест.

Для довідки (ми ніколи цього не робимо на фактичному сайті) Інструмент тестування структурованих даних Google повертає помилку, якщо ви спробуєте передати мікродані, приховані CSS.

Отже, і нормальна, і мета-розмітка дають однакові результати, однак у мене є певні занепокоєння через такі заяви Google і Schema.org:

https://support.google.com/webmasters/answer/146750 зазначено:

Загалом Google використовуватиме лише розмічені дані, видимі користувачеві. Приховані дані будуть ігноровані. Однак, за кількох обставин, може бути корисним забезпечити як машиночитану, так і читану людиною версію вашого вмісту. Наприклад, хоча текстовий рядок "День народження Елвіса" є важливим для багатьох читачів людини, для пошукових систем це не так важливо, як 1935-01-08. Точно так само людські читачі можуть зрозуміти значення символу $, але може бути корисно спеціально сказати пошуковим системам, чи ваші ціни в песо або доларах.

http://schema.org/docs/gs.html повідомляє (стосовно використання метатегів):

Цю техніку слід використовувати економно. Використовуйте мета з вмістом лише для інформації, яка інакше не може бути позначена.

http://schema.org/docs/faq.html#13 зазначено:

Як правило, слід позначати лише той вміст, який видно людям, які відвідують веб-сторінку, а не вміст у прихованих диві або інших прихованих елементах сторінки.

Мої запитання:

  1. Хоча помилки не повертаються, чи не буде нас санкціоновано пошуковими системами за використання метатегів таким чином (тобто дубльований вміст, приховування інформації тощо)?
  2. Якщо це не підходить, чи можете ви запропонувати будь-який спосіб розділити мікродані від фактичних даних або нам доведеться кусати кулю та реалізовувати це в HTML у кожному випадку?

2
Цей матеріал являє собою досить складний балансуючий акт для Google. Навіть якщо сьогодні проблем немає, Google може легко змінити політику. Google заробляє свої гроші, маючи пошукову систему, яка приводить своїх користувачів до найбільш підходящого контенту краще, ніж його конкуренти. Прихований вміст будь-якими способами може підірвати це, тому завжди буде безпечніше розмічати видимий вміст.

@Alohci Так, це я боюся, і немає способу сказати, поки не пізно! Дякую за коментарі, я думаю, що нам, можливо, доведеться просто кусати кулю на цьому і робити це звичайним чином.

Відповіді:


6

Ваш план використання метаданих для мікроданих не є життєздатним. Ось найпоширеніші запитання Google про те, чому він не відображає ваші дані в результатах пошуку :

Чи прихований від користувачів розмічений вміст?

Загалом Google не відображатиме жодного вмісту у розширених фрагментах, який не видно користувачеві. Чи не приховувати вміст , яке ви розмічений для багатих фрагментів з використанням таких методів , як display:none, value-titleабо CSS. Google проігнорує вміст, який не відображається для людей, тому слід позначити текст, який відвідувачі побачать на ваших веб-сторінках.

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

На даний момент Google не штрафує за спробу зловживати багатими фрагментами, окрім як лише вимкнути розширені фрагменти для цього сайту. Мене не здивує, якби Google почав повністю виключати сайти з результатів пошуку, коли Google знайде сайт, намагаючись використати мікродані таким чином, що не відповідає правилам.

Поки ваші метадані, які ви розмічаєте, також видно десь на сторінці, Google навряд чи покаже ваш сайт як зловмисний. Однак їх автоматичні інструменти визначають, коли ви розмічаєте дані у невидимому місці, і вони не відображатимуть їх у результатах пошуку.


Дякую за відповідь. Ви піднімаєте кілька цікавих моментів; здається, що безглуздо впроваджувати мікродані в метатеги, якщо дані не будуть використані!

4

Використання metalink) елементів для Microdata - це добре. Іноді навіть немає розумної альтернативи їй, наприклад, якщо конкретні коди мають бути надані там, де не було б сенсу показувати їх своїм користувачам.

Google навіть використовує metaв деяких своїх прикладах Rich Snippets:

Тож питання полягає в тому, наскільки це занадто багато (якщо взагалі є обмеження)? І я вважаю, що можна припустити, що жорсткої межі немає , це, швидше за все, залежить від різних додаткових факторів.

Однак Google має сенс не відхиляти розмітку Microdata, якщо лише використовується meta/ linkвикористовується. Чому? Оскільки вони також підтримують (а іноді навіть рекомендують ) JSON-LD для надання даних Schema.org, і це складається лише з "прихованого" вмісту (а саме прихованого scriptелемента, що використовується як блок даних ).

І це було б те, що я пропоную у вашому випадку: Якщо ви не хочете додавати структуровані дані, розмічаючи наявні елементи, використовуйте JSON-LD .


Дякуємо за пропозиції. Я погляну на JSON-LD.

1

Я не можу коментувати, чи спрацювало б це в усіх ситуаціях, але ми використовуємо Schema.org таким чином, як ви описуєте - як мета "вміст" на сторінках продукту. Чому? Це просто набагато портативніше і не руйнує теми. Він також дозволяє більш детально контролювати форматування даних, а релевантні дані отримують одразу після <body>(набагато вище згину). Приходять до уваги платформи, що базуються на гаках (або навіть на базі F&R, як vQmod): немає способу безперебійно F&R структурувати в структуру без жорсткого кодування все це.

Ми не помітили жодних штрафних санкцій, Google як і раніше використовує дані, як і раніше розміщує їх у віджетах SERP. У нас все ще є де-небудь дані на сторінці десь, але, що стосується більшої розмітки, вона знаходиться в одному єдиному ієрархічному мета-контейнері, використовуючи, content=""як ваш нижній приклад, лише свою обгорнуту організацію як "надання пропозиції". Тепер не забирайте це занадто далеко - найкраще залишати такі металеві конструктивні елементи, як цикл оглядів, сухарі, основний опис або характеристики. Спробуйте жорстко їх кодувати.

Більшість людей скажуть "не використовуйте content=""метаси", але знову ж таки, більшість людей ніколи цього не пробували. Те ж саме стосується таких речей, як багата розмітка в списках продуктів у категоріях ... так, ми теж порушуємо це правило :) Просто пам’ятайте, що Google не єдина риба в ставку RDF. Те, що говорить G, не є "збити або зламати" за цієї обставини використання стандартних форматів даних таким чином, що цілком прийнятно для решти ставу. Можливо, навіть тому, що сама G міняє свою думку в майбутньому. Він хоче даних вище / понад усе, але він змушує вас кодувати дані нижче / внизу, тоді як мета-атриби ставлять його спереду та в центр, доступною для машини мовою.


Flaggellum note, OpenGraph (OG) та інші роботи працюють аналогічним методом: як метас із вмістом у <head>або <body>. Pinterest любить дані спочатку зі схеми. Картки Twitter працюють аналогічно. І не бійтеся використовувати словник даних для сухарів та частин циклу відгуків, це дійсно.
dhaupin

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