Реализация семантической разметки с GTM [TechSEO Boost]

1. Почему семантическая разметка и структурированные данные? Почти 2018 год. Нам все еще нужен этот...
2. Что нового в мире семантического поиска
3. JSON-LD против встроенной разметки
4. Как реализовать JSON-LD на вашем сайте
5. Реализация статического JSON-LD
6. Реализация динамического JSON-LD
7. Собираем все вместе
8. Что это значит для SEO и маркетологов
9. Решая, как реализовать
10. Аналитика встречает семантическую разметку
11. Это упаковка!

Почему семантическая разметка и структурированные данные?

Почти 2018 год. Нам все еще нужен этот разговор? Структурированные данные больше не являются «приятными»; это так же хорошо, как требование на данный момент. Я бы даже сказал, что наличие некоторой базовой организации и, возможно, разметки хлебобулочных изделий на вашем веб-сайте - это немного больше, чем ставки на столы - наличие этого не дает вам большого преимущества, но отсутствие его означает, что вы не очень серьезно относиться к игре (SEO).

Убедиться в том, что ваш веб-сайт имеет описательные и в то же время лаконичные теги заголовков, - это SEO 101. Никто не станет спорить иначе Мне бы хотелось, чтобы базовые семантически организованные, структурированные данные были добавлены в этот контрольный список. Это основополагающее и необходимое.

Зачем?

SEO в значительной степени сводит к минимуму двусмысленность. Речь идет о конкретных. Специфика превосходит общность каждый раз. SEO - это обеспечение того, чтобы ничего не терялось при переводе между веб-интерфейсом, который мы создаем, и программными приложениями, которые созданы для их переваривания и индексации.

Предоставление хорошо структурированных, семантических данных доступным для поисковых систем (и других веб-приложений) гарантирует отсутствие двусмысленности относительно того, что представляет собой ваш контент или о чем он. Кто не хотел бы этот уровень контроля?

Богатые фрагменты, богатые карты и извлечение сущностей

Все философские аргументы в стороне, семантическая разметка и структурированные данные приносят пользу вам (и сети, если вы заботитесь об этом) конкретными способами. Основные поисковые системы не только продолжают использовать структурированные данные в качестве основы для расширенных фрагментов, но и расширяют сферу применения и области применения. Теперь мы перешли от традиционных фрагментов к Rich Cards. Последние представляют собой переносимые блоки организованных данных, которые могут быть идеально представлены в мобильном контексте. Rich Cards также демонстрирует, насколько хорошо эти данные могут быть организованы для текущего и / или будущего использования в «голосовых» результатах голосового поиска.

И это даже не говоря о извлечении сущностей. Процесс, с помощью которого поисковые системы, такие как Google, могут собирать данные со всей сети, чтобы создать богатую сущность.

Семантическая разметка и структурированные данные дают возможность контролировать или иным образом влиять на то, как все это происходит. Это своего рода большое дело.

Что нового в мире семантического поиска

Как и все в SEO, семантическая разметка и способы, которыми мы можем структурировать данные, постоянно развиваются. Давайте немного поговорим о некоторых захватывающих событиях, которые мы видели в 2017 году.

• Schema.org версии 3.3. В этой версии было внесено много обновлений в словарь Schema.org, но одним из моих любимых изменений стало добавление HowTo. Как Тип сущности - это то, что я долго ждал, чтобы увидеть. Это похоже на проверенный и верный рецепт, но HowTo - это более всеобъемлющее и общее определение, которое можно применять практически ко всем документированным процессам. В дополнение к знакомым свойствам, таким как «prepTime» и «yield», у нас теперь есть такие замечательные вещи, как «оценочная стоимость», «инструмент» (все, что используется в процессе) »и« снабжение »(все, что используется в процессе).
  • Стоит отметить, что версия 3.2, выпущенная ранее в этом году, расширила Курс введите и перенесли связанные свойства с Pending в Schema.org Core. Мы также увидели некоторые большие улучшения Меню введите с этим выпуском.
• Объявления о вакансиях и диапазоны зарплат - материал становится реальным! Это то, от чего я действительно взволнован - передовой опыт поиска, основанный на структурированных данных! Больше информации о Объявления о вакансиях в поиске Google ,
• Обновленные рекомендации Google Merchant Center - Этот пост еще не затрагивал JSON-LD, но это хороший тизер. В настоящее время Google рекомендует использовать JSON-LD в качестве метода структурирования данных о товарах для Merchant Center. Это огромно! Слишком долго маркетологам и веб-мастерам приходилось сталкиваться с необходимостью иметь дело с встроенной разметкой. Именно такие шаги привели команду UpBuild к полностью отказаться от рекомендации встроенной семантической разметки для наших клиентов.
• Структурированные данные подкастов - команда UpBuild любит подкасты, так что это было очень интересно посмотреть. Google собирается предоставлять богатые данные для серий и эпизодов подкастов, и это особенно ориентировано на Google Home. Это довольно много и намекает на то, почему структурированные данные будут становиться все более и более важными. Интересно, что для этого ваши данные должны быть частью RSS-канала (точнее, RSS 2.0); не встроенный или даже JSON-LD. Узнайте больше о структурированных данных Podcast здесь , Это отличный пример того, почему я стараюсь изо всех сил использовать термин «структурированные данные» и минимизирую количество ссылок на «семантическую разметку» - здесь нет разметки! Это 100% структурированные данные, полностью отделенные от любого уровня представления.
• Paywalled Content структурированные данные - я воздержусь от разглагольствования по поводу моего крайнего отвращения к paywalled контенту, но новая спецификация очень интересна для просмотра. В рекомендациях Google по Подписка и Paywalled Content они предоставляют метод для указания не только того, что веб-страница имеет платный доступ, но и для определения того, какой раздел (ы) контента является платным.
• Первые признаки того, что Bing поддерживает JSON-LD. Мы с оптимизмом смотрим на то, как Bing подключается к JSON-LD. Во-первых, потому что это будет здорово за качество их результатов и веб в целом. Два, потому что сейчас мы действительно больше не нужно разбираться со встроенной разметкой ,

Бонус : Будьте в курсе последних новостей в мире структурированных данных, добавив в закладки Аарона Брэдли впечатляюще всеобъемлющий документ, отслеживающий важные события в пространстве.

JSON-LD против встроенной разметки

Мы уже затронули этот вопрос в этом посте, но давайте разберем его немного подробнее, чтобы проиллюстрировать различия между этими двумя методами реализации.

JSON-LD Доставка

• Автономный <скрипт>
• Может содержать любые соответствующие данные, даже данные, не представленные на странице
• Отделен от уровня представления; изменения содержимого не нарушат структуру данных
• Теоретически может быть реализовано без отправки каких-либо запросов на разработку

Встроенная доставка

• Запеченный в исходный код HTML страницы
• Может применяться только к данным, представленным на странице (метатеги являются одним заметным исключением)
• Неразрывно связаны с уровнем представления; изменения содержания почти наверняка нарушат структуру данных
• Не может быть реализовано без серьезных запросов на разработку / изменений кода

Ну, когда ты так говоришь, это кажется довольно простым выбором? JSON-LD полностью.

К сожалению, мы все были обучены использовать встроенные микроданные; Я думаю, что мы можем пережить переход, хотя. Другое соображение заключается в том, что не все поисковые системы созданы для обработки JSON-LD ... пока.

Однако, если недавние результаты, связанные с рендерингом JavaScript в Bing, являются какими-либо признаками, это может вскоре стать проблемой. Если бы вы были заинтересованы в том, чтобы охватить все свои базы, то в 2018 году можно было бы предпочесть реализовать оба стиля, чтобы у вас был запасной вариант для небольших движков, которые еще не поддерживают JSON-LD.

Хотя встроенная разметка хрупкая, у нас есть мощный инструмент под названием ItemRef и ItemId это может помочь преодолеть множество проблем. Но в какой-то момент мы должны спросить себя, стоит ли изгибаться назад для небольших двигателей, стоит дополнительная работа по сравнению с минимальной отдачей, которую мы можем получить. Это решение, которое каждый маркетолог должен принять для себя, но в наши дни мы рекомендуем сосредоточиться только на JSON-LD.

Итак, давайте поговорим о том, как реализовать JSON-LD.

Как реализовать JSON-LD на вашем сайте

Мы начнем с обсуждения того, как реализовать статический (то есть неизменяемый) JSON-LD, а затем перейдем к интересной части: реализации динамического JSON-LD с помощью Google Tag Manager. В этом примере мы будем использовать страницу событий для TechSEO Boost ( посмотреть здесь ) в погоне за богатой картой в Google.

Реализация статического JSON-LD

Это довольно легко сделать, с или без Google Tag Manager. У вас есть три основных варианта.

1. Создайте (или скопируйте) свой статический JSON-LD-скрипт и вручную поместите его в <head> каждой страницы, на которой вы хотите, чтобы он появлялся.
2. Используйте плагин (например, Yoast для SEO), который автоматически генерирует и применяет базовый JSON-LD (поддерживаемые типы ограничены) к ключевым страницам.
3. Используйте Google Tag Manager, чтобы разместить нужный вам JSON-LD именно там, где вам нужно.

Чтобы начать писать свой JSON-LD, Введение Google в структурированные данные или идите прямо к источник на Schema.org ,

Как только ваш JSON-LD будет готов к работе в статической форме, пришло время войти на сайт с помощью GTM. Вам понадобятся два компонента GTM: тег и триггер.

• Тег - Тип: HTML - Имя: {{Тип схемы}} JSON-LD - Содержание: Ваш объект JSON-LD, заключенный в теги <script>
• Триггер - Тип: Просмотр страницы - Имя: {{Имя / Тип страницы}} - Условия: Путь к странице равен / {{your-page}}

Это буквально все, что нужно сделать. Проверьте это в режиме предварительного просмотра, чтобы убедиться, что он запускается, опубликовать, а затем проверить с помощью Google Инструмент тестирования структурированных данных.

Реализация динамического JSON-LD

Статическая реализация хороша для информации, которая является постоянной (то есть статической), но что делать, когда ваши структурированные данные должны отражать информацию в потоке? Возьмите, например, продукты на веб-сайте электронной коммерции или на страницах с подробными сведениями о событиях. Цены могут измениться в любое время. Новые события будут постоянно добавляться с течением времени. Это много постоянного обслуживания JSON-LD.

Чтобы избежать этого, мы бы хотели сделать наш JSON-LD динамическим. У нас есть три основных варианта, которые мы можем использовать для достижения этой цели.

1. Разработайте управляемый CMS JSON-LD, чтобы та же логика, которая управляет сайтом (через CMS), также управляла JSON-LD.
2. Используйте Google Tag Manager, чтобы собрать точки данных на странице и свернуть их в динамически создаваемый тег сценария JSON-LD.
3. Используйте Google Tag Manager в качестве прото-CMS, который будет хранить все наши структурированные точки данных и использовать его для динамического создания тега сценария JSON-LD.
4. Сделайте так, чтобы ваша CMS заполнила dataLayer для предоставления дополнительных (или полных) точек данных для GTM для использования в динамическом теге сценария JSON-LD.

Мы потратим большую часть этого обсуждения на вариант № 2, но мы также коснемся идей, лежащих в основе № 3 и № 4, потому что это может быть хорошим вариантом для некоторых.

Все начинается с того же базового шаблона JSON-LD (из Введение Google в структурированные данные или же Schema.org ) и превращая его в многоразовую оболочку. Чтобы осмыслить это, просто удалите все значения из JSON-LD, которые относятся к конкретному экземпляру сущности. Чтобы создать оболочку сущности «Событие», удалите имя события, его дату, цену билета, докладчика (ов) и т. Д. Все, что может быть изменено для различных событий. Получившийся неполный JSON-LD является основой для нашего динамического тега.

{"@context": "http://schema.org", "@type": "Event", "eventStatus": "http://schema.org/EventScheduled", "name": "", "description ":" "," image ":" "}

Итак, как мы можем получить ценности в этой вещи? Конечно, мы будем использовать потрясающую мощь GTM! Каждый пустой слот в оболочке сущности должен быть заполнен переменной GTM. Это ни в коем случае не полный список, но давайте использовать три точки данных в качестве примеров.

• Изображение события
• Страница регистрации
• Месяц событий

Получение образа события с помощью переменной GTM

GTM - довольно изящный инструмент, и иногда это делает работу такого рода благословенно простой. В этом примере мы хотим иметь возможность получить изображение, связанное с событием, распознавая, что это может быть другое изображение от страницы к странице. Мы можем создать переменную GTM под названием «dataPoint - Event Image» и выбрать тип переменной DOM Element. При этом используется встроенная в GTM возможность найти элемент в объектной модели документа страницы и сохранить информацию об этом элементе DOM в качестве значения переменной. Выбрав CSS Selector в качестве метода выбора, вставив действительный селектор, например «.section-hero img», и указав SRC в качестве имени атрибута, мы каждый раз получаем основное изображение страницы события.

Чтобы узнать, как правильно выбрать селектор CSS, прочитайте замечательный пост Лоры: « Расширения Chrome, которые мы любим: уникальный селектор jQuery «, Обращая особое внимание на Шаг № 2.

Получение URL страницы регистрации с переменной GTM

Во многом таким же образом мы можем использовать тип переменной DOM Element GTM, чтобы получить целевой URL кнопки или призыва к действию. Это будет точка данных, которую мы используем для установки URL предложения для события в сценарии JSON-LD. Для этого мы создадим переменную GTM с именем «dataPoint - Register Page» и снова выберем тип переменной DOM Element. Затем мы выбираем CSS Selector в качестве метода выбора, используем селектор типа «a [title = 'register-now']» и указываем атрибут HREF как то, что мы хотим получить обратно.

Boom. Правильный URL-адрес страницы регистрации каждый раз (при условии, что CTA имеет атрибут заголовка «register-now»).

Получение Месяца Событий с помощью переменной GTM

Использование переменной DOM Element просто царапает поверхность того, что может сделать GTM. Представьте себе сценарий, в котором нужная информация не является легкодоступным атрибутом элемента DOM. Давайте возьмем месяц события в качестве примера; нам понадобится полная дата ISO (YYYY-MM-DD) для нашего JSON-LD, но мы сейчас рассмотрим месяц отдельно. Проблема в том, что у нас редко будет страница события с датой наподобие 2017-11-30, напечатанной на поверхности, чтобы мы могли ее захватить. Нам нужно немного магии JavaScript.

Для этого мы создадим новую переменную GTM, но на этот раз мы будем использовать тип переменной Custom JavaScript. Мы назовем переменную «dataPoint - Event Month». Вот где это весело.

С помощью переменной GTM JavaScript мы можем предоставить пользовательскую функцию JS, которая выполняет сложный JavaScript и возвращает значение, которое мы можем использовать. В приведенном ниже примере мы делаем четыре вещи.

1. Захватывает текст элемента DOM, соответствующего «.event-date», и разбивает его на части с помощью «,» (запятая + пробел) или «» (пробел). Результат для «четверг, 30 ноября 2017 года» будет четыре части (то есть массив с четырьмя значениями).
2. Принимает второе значение массива (индекс 1, поскольку первым является индекс 0) и обрезает его до первых трех букв (чтобы было легче работать с ним позже).
3. Мы создаем ассоциативный массив, который отображает трехбуквенные названия месяцев в их числовые эквиваленты.
4. Мы возвращаем (как значение этой переменной GTM) числовое значение, связанное с трехбуквенным месяцем, который мы вводим в массив «months».

function () {var dateArray = jQuery (". event-date"). text (). split (/, \ s | \ s /); var monthStr = dateArray [1] .substring (0,3); var months = {'Jan': '01', 'Feb': '02', 'Nov': '11'}; вернуть месяцы [monthStr]; }

Промойте и повторите с клонами этой переменной, чтобы получить день и год (немного проще, поскольку мы можем просто вернуть dateArray [2] и dateArray [3], соответственно). Вы даже можете придумать и адаптировать JavaScript выше, чтобы записать полную дату ISO: ГГГГ-ММ-ДД.

Собираем все вместе

Но недостаточно просто поместить имена наших переменных в нашу оболочку сущностей JSON-LD и вызвать ее в течение дня. Если бы мы сделали это, мы обнаружили бы, что вывод GTM не правильно заполняет значения. Мы увидим нечто подобное в нашем теге JSON-LD:

"image": google_tag_manager ["GTM-M3M24C"]. macro ('gtm12')

Это не то, что мы хотим! Для любопытных, это объясняется более подробно в Сообщение Moz Криса Годдарда на эту тему ,

Чтобы преодолеть это, нам нужно написать скрипт, который правильно строит и присоединяет тег скрипта JSON-LD. Вот основной пример того, как это выглядит. Я сломаю это ниже.

(function () {var data = {"@context": "http://schema.org", "@type": "Event", "name": {{dataPoint - Имя события}}, "description": {{dataPoint - Описание события}}, ...} var script = document.createElement ('script'); script.type = "application / ld + json"; script.innerHTML = JSON.stringify (data); документ. getElementsByTagName ('head') [0] .appendChild (script);}) (document);

1. Первая и последняя строка выделяет то, что известно как IIFE - Выражение немедленной функции , (Функция () {}) (документ)

   Главное, что нужно понять, это то, что это изолирует все, что мы делаем (поэтому оно не мешает другим JS на сайте), и сразу же запускает код, как только тег <script> готов.

• Вторая часть (весь блок) является объектом. Тот, который сильно напоминает оболочку JSON-LD, которую мы создали. При прямом использовании, подобном этому, нет большой разницы между Object и обычным JSON-LD, но, когда вы попадаете в более сложные варианты использования, очень важно понимать, что вам нужно работать с этим, как с реальным объектом JavaScript, а не с простая текстовая строка (это определенно не так).
  Например, если вам когда-либо понадобится добавить новые свойства в модель или изменить существующие, вы должны использовать точечную нотацию, например, data.location.address.streetAddress позволит вам добавить свойство схемы streetAddress, которое ранее не существовало. Это полезно, если есть точки данных, которые необходимо добавить, только если они существуют на странице.
  Если это последнее утверждение для вас латинское, поздравляю! Вам, вероятно, не придется беспокоиться об этом. 😉 На этом этапе важно понять, что мы просто строим нашу структуру данных и присваиваем переменные (заключенные в двойные фигурные скобки) в качестве значений.
• Затем наш код создает новый тег <script>, то есть элемент script. Не намного больше на этом этапе.
• Далее мы устанавливаем атрибут type на «application / ld + json». Это будет сигнализировать Google и другим движкам, что это JSON-LD, а не какой-либо старый тег JavaScript.
• Далее (это так здорово), мы устанавливаем innerHTML, т.е. содержимое указанного тега сценария, в полностью сформированный блок JSON-LD, используя JSON.stringify ,
• Наконец, мы выбираем тег <head> на нашей странице и добавляем наш новый скрипт JSON-LD в его конец.

Вы знаете, что мы только что сделали? Мы разместили JSON-LD на сайте, не обращаясь за помощью к команде разработчиков, и теперь мы можем контролировать весь процесс. Для многих маркетологов (как внутри компании, так и со стороны агентства) это огромно.

Да, это действительно работает.

Да, это подтверждает.

Да, это даст вам богатые фрагменты, богатые карты и помощь в извлечении сущностей.

Да, он будет отображаться в структурированных отчетах Google Search Console.

Что это значит для SEO и маркетологов

В конце концов, такой метод открывает мир возможностей. Это дает нам бесконечную гибкость и неограниченные возможности, когда дело доходит до предоставления структурированных данных поисковым системам для усиления SEO. Конечно, есть существенная кривая обучения, с которой нужно считаться, но как только вы преодолеете эту точку, вы станете золотым.

Решая, как реализовать

Несмотря на все преимущества этого метода реализации структурированных данных, это еще не все. Возможно, он вам не подойдет, особенно если у вас есть возможность изменить свой сайт / CMS или у вас есть легкий доступ к ресурсам / времени разработки. Независимо от того, является ли Google вашим основным движком, это еще один вопрос - если многие ваши пользователи лояльны к меньшим движкам, вы можете использовать старомодную встроенную разметку.

Выбор за вами, но я надеюсь, что приведенная ниже схема поможет вам принять правильное решение.

Аналитика встречает семантическую разметку

На TechSEO Boost у нас не было достаточно времени, чтобы поговорить о том, что это может означать для аналитики. Что если мы хотим отследить в рамках Google Analytics, какие из наших страниц содержат какие типы семантических объектов на них? Или что, если бы мы просто хотели использовать эти семантические данные для улучшения нашей аналитической реализации, выходящей за рамки простого сценария отслеживания семантической разметки? Это было основной темой моего поста Семантическая аналитика на Моз. Суть в том, что я пришел к этой идее еще тогда, когда встроенная разметка была единственной игрой в городе.

Используя описанную выше тактику GTM & JSON-LD, сделать то же самое практически невозможно. Зачем? Что мы делаем с GTM, так это добавляем семантическую разметку после факта, потому что семантическая разметка не была чем-то, что мы имели на сайте в первую очередь. Google Tag Manager загружает свой контейнер, захватывает ключевые точки данных и создает наш JSON-LD на лету.

И это именно проблема!

К тому времени, когда это произойдет, мы уже отправили просмотр страницы в Google Analytics. Мы хотим сразу же отслеживать просмотр страницы, чтобы учесть как можно более 100% пользователей нашего сайта; мы не хотим откладывать отслеживание просмотра страницы до тех пор, пока не создадим семантическую разметку JSON-LD или другую разметку, что должно было бы произойти, если бы мы хотели отправить информацию schema.org в GA вместе с этим просмотром страницы.

Но если у нас есть возможности и / или ресурсы для веб-разработки, мы можем выбрать лучший подход. Мы можем использовать dataLayer для питания как нашей семантической JSON-LD, так и нашей семантической аналитики.

Учти это:

dataLayer = [{mainEntity = "Article"}]

Наша CMS (прикладной уровень) будет выводить свойства каждой страницы не в пользовательский HTML (уровень представления), а в промежуточный слой данных. По сути, объект JavaScript, который пользователи не увидят, но с которым GTM специально разработан для работы. Таким образом, мы могли бы указать, что основной сущностью страницы является «Статья», без необходимости распечатывать ее для пользователя.

Оттуда мы можем создать переменную dataLayer прямо в GTM, присвоить ей то же имя, что и у свойства dataLayer, к которому мы хотим получить доступ в коде (например, «mainEntity»), и затем мы можем работать с этим значением любым способом, которым мы хочу.

• Мы можем подать «mainEntity» в GA в качестве пользовательского измерения,
• мы можем использовать «mainEntity» в качестве параметра для группировки контента, и
• мы можем использовать значение «mainEntity» для запуска соответствующего скрипта JSON-LD.

Таким образом, относительно небольшой запрос на разработку делает GTM гораздо более мощным аналитическим инструментом и одновременно позволяет GTM стать вашей действующей JSON-LD CMS.

Конечно, вы можете расширить эту идею еще больше, чтобы вывести дополнительные свойства контента в dataLayer для легкого доступа. Таким образом, вам не придется беспокоиться о том, как много (если таковые имеются) чисток DOM с пользовательскими переменными GTM.

dataLayer = [{mainEntity = "Article", title = "Как выполнить JSON-LD с GTM", author = "Ruth Burr & amp; Mike Arnesen", publishDate = "2017-11-30T13: 20", featuredImage = " https://www.upbuild.io/images/gtm-json.png "}];

В этот момент вы просто увеличиваете число переменных GTM типа dataLayer, чтобы получить эти значения из dataLayer. Перетащите их в свой dynmaic JSON-LD тег, и все готово. Кроме того, вам не нужно углубляться в JavaScript, чтобы соскрести данные со своей страницы.

Это упаковка!

Есть вопросы? Дайте нам знать в комментариях ниже.

Ох, и счастливой оптимизации!

связанные с

Похожие

Комментарии