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

Применение микроразметки для сайта помогает улучшить его результативность поисковой выдачи, повышает видимость сайта поисковиками.

Сегодня Schema разметка поддерживается многими поисковыми системами, включая лидеров. Google отдает свои предпочтения только ей.

Месторазмещение микроразметки

Рассмотрим необходимый код программы и место его размещения.

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

При написании микросхемы Schema обязательным является применение трех компонентов (выделены красным цветом). Рассмотрим их:

1. Атрибут itemscope нужен для поисковика. С помощью данного атрибута поисковик понимает начало процесса описания какого-то объекта.
2. За атрибутом itemscope всегда следует атрибут itemtype. Он помогает поисковому роботу определить тип описываемого объекта. В приведенном примере это Movie.
3. Атрибут itemprop помогает описать свойства объекта. К свойствам объекта в приведенном примере относятся: name — название, director — режиссер, genre – жанр.

Кроме рассмотренных компонентов в коде используются и другие теги html разметки. Рассмотрим некоторые из них:

• div — указывает на начало и конец процесса описания объекта;
• span — содержит описание свойств объекта словесного представления;
• time — указывает дату и время. Обязательный атрибут datatime позволяет указывать выбранный тип отображения данных;
• a — применяется при размещении видимых для пользователей ссылок;
• meta — скрывает от глаз пользователей необходимую информацию. Его не применяют для картинок. Многократное его использование при микроразметки гугл не принесет положительных результатов.

На практике микроразметка создается на сайте ruschema.org. Необходимо зайти в раздел «Схемы», выбрать объект описания и указать свойства. Таким образом будет формироваться ваш код программы.

Приведем примерный вид полученного кода:

Особые сервисы Google и Яндекс позволяют проверить микроразметку.

Валидаторы микроразметки

Проверить яндекс микроразметку и микроразметку google помогут специальные сервисы — валидаторы.

Они дают возможность проверить микроразметку, внедренную на ресурсе. Валидаторы проверяют смогут ли поисковые роботы просмотреть структурные данные ресурса.

Валидатор Яндекс.Вебмастер позволяет проверить популярные форматы микроразметки: microdata, schema, микроформаты, OpenGraph, RDFa.

Сервис Google Structured Data Testing Tool просмотрит размеченные данные, проанализирует их и выведет результат.

Отношение числа пользователей, которые выполнили целевые действия на ресурсе, к общему числу посещений называется конверсией.

Для ее повышения многие интрнет-ресурсы прибегают к микроразметке товаров.

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

Сниппер — это небольшой отрывок текста с интернет-ресурса, который нашла поисковая система в качестве описания ссылки при выдаче поискового результата.

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

Семантическая разметка (микроразметка крошек) является необходимой процедурой при повышении конверсии ресурса. Она позволяет пользователям «не рыться» на всем сайте для нахождения определенного вида товара, а увидеть в результатах поиска поисковых машин ссылку на страницу с нужным товаром или услугой.

Польза использования микроразметки

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

Добавить микроразметку можно при помощи нескольких сервисов. В данной статье мы рассмотрели Schema.org, который является на сегодняшний момент самым востребованным.

Рассказать друзьям:

Микроразметка в Яндексе: что это и как ей пользоваться

Что такое микроразметка?

Микроразметка сайта – это семантическая разметка тегов внутри Интернет-ресурса, которая позволяет поисковым система определить важные информационные данные сайта, например, вид товара или услуги, его цвет размер, цену и тд.

Для чего нужна микроразметка?

Микроразметка делает сниппеты сайтов в результате поисковой выдачи более заметными и привлекательными для пользователей. Тем самым позволяет увеличить количество переходов на сайт с поиска на сайт. Проверить правильность написания тегов внутри кода можно с помощью  валидатора микроразметки.

Блок информации с микроразметкой

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

Обычный сниппет

Подробный сниппет

Микроразметка требуется для таких типов контента как:

• ​ видеоролики;
• ​ фильмы;
• ​ обратная связь;
• ​ товары и изделия;
• ​ программы;
• ​ отчеты;
• ​ рецепты;
•  мероприятия;
• ​ рестораны и кафе.

Стандарты микроразметки

Яндекс рекомендует использовать микроразметку Shema.org. Это стандарт семантической разметки, принятый в 2011 г. корпорациями Google, Yahoo и Bing для улучшения структурированности информации на Интернет-ресурсе, передачи ее смысла поисковым роботам. Микроразметка Shema.org — стандарт семантической разметки, благодаря этой разметке, поисковые роботы могут понимать смысл информации на сайте. Он применяет микроданные для семантической разметки документа. Микроданные — это теги, которые употребляются в языке Html5. В микроразметке используются конкретные сущности для разных видов данных и страниц.

Рассмотрим соответствие типов сущностей и контента:

• Обратная связь — Review
• Место — Place
• Товары — Product
• Книга — Book
• Аудио — Audio Object
• Фильм — Movie
• Видео — Video Object
• Картинки — Image Object
• Игры — VideoGame
• Мероприятие — Event
• Ресторан — Restaurant
• Рецепт — Recipe
• Организация — Organization
• Несколько товаров — Aggregate Offer
• Сводный рейтинг — Aggregate Rating
• Мобильные приложения — Mobile Application
• Интернет-программы — Web Application
• Ответы и вопросы — Answer и Question

Как создают микроразметку

Микроразметку прописывают в коде html, применяя при этом 3 главных атрибута: Itemcope, Itemtype, Itemprop. Itemscope — сообщает роботу о том, что микроразметка присутствует. Itemtype служит для описывания вида сущности, Itemprop необходим для сообщения свойства сущности.

Атрибуты Itemcope и Itemtype применяются в паре друг с другом. Специально для атрибута itemprop описывают значения полей. Стандартные значения: image, name, url, description и тд. Остальные поля — специальные, их применение зависит от содержания контента.

Как проверить наличие микроразметки?

Для проверки наличия микроразметки на сайте и ее корректности Яндекс несколько лет назад запустил специальный инструмент в Вэбмастере — валидатор микроразметки. Нужно скопировать адрес страницы или вставить часть кода, если сайт еще не запущен.

После проведения проверки с помощью Валидатора, инструмент выдаст список несоответствий, в который могут входить предупреждения и ошибки. Яндекс выдает расшифровку полученных результатов.

Стоит отметить, что существуют и другие микроразметки: RDFa и OpenGraph.

Необходима настройка микроразметки на сайте?

Мы знаем, как помочь вам решить эту проблему!

Звоните, мы работаем, ежедневно, с 10 до 18.

8 800 200 17 49

Или пишите: [email protected]

В гости пока не приглашаем:)

Всем спасибо за внимание!

Тестирование HTML-верстки

Группы основных проверяемых параметров:

1. Соответствие макету
2. Работа в разных окружениях
3. Проверка на разных разрешениях экрана (проверка десктопной и адаптивных версий)
4. HTML
5. Javascript
6. CSS
7. Фавиконки
8. Шрифты
9. Навигация
10. Заголовки
11. Контент
12. Изображения
13. Ссылки и кнопки
14. Футер
15. Формы

1. Соответствие макету

• Расхождение макета и верстки в пикселях

  Мы используем для этого браузерный плагин PerfectPixel и сайт I love adaptive. Существует также множество других программ и расширений для проверки соответствия верстки и макета.

• Корректный вывод элементов интерфейса в векторном формате

  В идеале, все изображения в элементах интерфейса должны быть в формате svg. Изображения в векторном формате корректно масштабируются на любых разрешениях экранов и типов мониторов.

• Поддержка retina-мониторов

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

• Наличие элементов, выбивающиеся из цветовой гаммы сайта

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

• Наличие элементов с малой контрастностью

  Есть несколько инструментов, позволяющих проверить данный параметр, например Google Lighthouse.

2. Работа в разных окружениях

• Кроссбраузерность

  На этапе разработки проверяем сайт в браузере Chrome. На этапе тестирования необходимо проверить сайт в браузерах, поддержка которых указана в ТЗ проекта.

• Корректная работа на разных устройствах

  Для тестирования на реальных устройствах мы используем сервис lambdatest.com или BrowserStack.

• Корректная работа сайта при различных настройках местоположения пользователя, часового пояса и времени

  Например, отображение попапа при определении города.

• Корректная работа с разной скоростью интернета

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

• Корректная работа при включенном расширением AdBlock в браузере

• Наличие мета-тега <meta http-equiv=»X-UA-Compatible» content=»IE=edge»>

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

• Корректное отображение кнопок, полей ввода, выпадающих списков и радиокнопок на разных устройствах

  Нужно уделять этому внимание, так как устройства могут применять свои стили.

• Корректное отображение сайта с административной панелью CMS

  Административная панель CMS обычно отображается в верхней части сайта и может сдвинуть контент. Стили и скрипты должны учитывать это.

• Корректная настройка встраиваемых карт для тач-устройств

  На тач-устройствах в картах Яндекс и Google желательно отключать zoom карты при скролле, так как пользователь не сможет проскроллить страницу.

• Корректное фиксирование хедера при прокрутке

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

3. Проверка на разных разрешениях экрана (проверка десктопной и адаптивных версий)

• Корректное отображение на всех возможных размерах окна браузера

  Мы проверяем базовое соответствие макету в iloveadaptive.com или с помощью инструментов разработчика Chrome.

• Область нажатия кнопок

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

• Отображение страницы при масштабировании в десктопных браузерах

  Сетка страницы не должна ломаться при масштабировании: элементы интерфейса не должны «залезать» на другие элементы.

• Наличие мета-тега viewport

  Данный мета-тег отвечает за корректное отображение сайта на различных разрешениях экрана. Пример оптимального заполнения данного мета-тега: <meta name=»viewport» content=»width=device-width, initial-scale=1″>.

• Корректная прокрутка страницы при открытых попапах

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

• Корректное отображение плавающих (закрепляемых за прокруткой) элементов

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

• Использование чрезмерно большого количества различных брейкпоинтов для стилей

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

  Мы используем такой набор брейкпоинтов: 414px — 576px — 768px — 992px — 1200px — 1366px.

• Смешивание различных брейкпоинтов для стилей

  Основная часть брейкпоинтов должна «смотреть» в одну сторону: необходимо использовать либо брейкпоинты min-width, либо max-width. Часто на сайтах используется оба вида брейкпоинтов, что приводит к багам на определенных разрешениях экрана. Кроме того, для min-width и max-width должны использоваться разные брейкпоинты, например, если для min-width используется ширина 768px, то для max-width нужно использовать ширину 767px.

• Слишком узкие блоки на маленьких разрешениях экрана

  На разрешениях экрана меньше 500px для контента остаётся совсем мало места, особенно, если есть несколько блоков с отступами, вложенных друг в друга. Если есть два таких блока и у каждого отступ 15px, то с обеих сторон экрана «съедается» 60px. Для таких случаев рекомендуется прижимать эти блоки к краю экрана, чтобы отступ до контента составлял с каждой стороны 15-20px.

• Наличие сломанной вёрстки при изменении размеров экрана

  Часто при изменении размеров экрана должны отрабатывать js-скрипты, отвечающие за корректное отображение верстки при текущем разрешении. Нужно отслеживать, чтобы скрипты отрабатывали не один раз на странице, а каждый раз при изменении размеров экрана.

• Некорректная верстка на мобильных устройствах при показе/скрытии адресной строки

  Высота в CSS на мобильных телефонах вычисляется с учетом адресной строки, поэтому, если необходимо, чтобы высота блока была на всю высоту экрана телефона, лучше это делать с помощью скриптов.

4. HTML

• Валидность HTML

  Незакрытые теги, некорректная вложенность тегов, невалидные атрибуты, синтаксические ошибки, устаревшие технологии и т.п. Для проверки используется валидатор W3C.

• Наличие корректного DOCTYPE

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

• Наличие корректной кодировки

• Наличие тега title и мета-тегов для SEO

  Например, мета-теги с name=»keywords» и name=»description».

• Наличие атрибута lang у тега html

  Например, lang=»ru-RU». Данный атрибут необходим для правильного определения языка страницы поисковыми системами. Кроме того, этот атрибут помогает плагинам-переводчикам понять, предлагать ли перевод страницы.

• Повторяющиеся или некорректные атрибуты id

  Атрибуты id должны начинаться с буквы, а не с числа.

• Наличие пустых и ненужных тегов

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

• Наличие объёмных комментариев в коде

  Во-первых, такие комментарии увеличивают объем страницы, а во-вторых, подобные комментарии видны всем, поэтому это может быть небезопасно. Вместо HTML-комментариев нужно использовать комментарии в PHP.

5. Javascript

• Не должно быть ошибок javascript при работе с сайтом

  Один из самых важных пунктов. Каждая javascript-ошибка может повлечь за собой неработающий или некорректно работающий функционал.

• Скрипты должны быть объединены в один файл и минифицированы

  Уменьшает размер файлов javascript и ускоряет парсинг этих файлов браузером. Также позволяет браузеру делать меньше запросов к серверу. Многие CMS самостоятельно умеют делать подобное, но стоит подробнее ознакомится с их особенностями. Например, Битрикс умеет объединять файлы скриптов в один файл, перемещать их в конец страницы и подключать минифицированные версии файлов (с суффиксом .min). Но битрикс не умеет самостоятельно делать минифицированные версии файлов. Мы минифицируем файлы скриптов с помощью Terser.

• Файл скриптов должен подключаться внизу страницы

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

• Использование кода из неподходящей версии javascript

  Не весь код, написанный на javascript, поддерживается во всех браузерах, поэтому необходимо следить, чтобы все участки кода корректно работали во всех браузерах. Особенно эта проблема относится к браузеру Internet Explorer. Многие плагины напрямую перестали поддерживать работу в этом браузере, и для их корректной работы необходимо ставить полифилы, т.е. небольшие скрипты, позволяющие более новому синтаксису javascript работать в неподдерживаемых браузерах. Совместимость javascript-кода можно проверить на специальном сайте.

• Сторонние скрипты желательно должны иметь атрибуты async и defer

  Речь о скриптах для сбора метрики, либо о сторонних скриптах для функционала, который не критичен при загрузке всей страницы, например Яндекс.карты. Наличие этих атрибутов позволяет браузеру лучше определять приоритет при загрузке ресурсов страницы.

• Наличие устаревших javascript-плагинов

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

• Корректное подключение сторонних библиотек

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

• Некорректная работа плагинов

  Если сторонний плагин популярен и проверен временем, это не значит, что в нём нет багов. Стили сторонних плагинов не должны выделяться на фоне остального сайта, а в работе с данным плагином не должно возникать javascript-ошибок. В данном случае можно или исправить код плагина самому, или найти какой-нибудь форк, где этот баг исправлен, или найти другой подобный плагин, где этой ошибки не будет.

• Наличие непереведенного текста в плагинах

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

• Адекватное отображение сайта при выключенном javascript

  Необходимо, чтобы сайт не «разваливался» при выключенном или еще не загруженном javascript.

• Наличие кода на «боевом» сайте, предназначенного для разработки на тестовом сервере

  Это могут быть различные тестовые функции, вызовы console.log, или вывод лишней информации, не предназначенной для обычных пользователей.

• Корректная инициализация контентных слайдеров

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

6. CSS

• Валидация CSS

  Поиск синтаксических ошибок в стилях, поиск некорректных или устаревших правил. Валидация стилей производится с помощью W3C валидатора CSS.

• Файлы стилей должны быть корректно подключены

  Файлы стилей должны подключаться в head и загружаться перед всем видимым контентом.

• Стили должны быть объединены в один файл и минифицированы

  По аналогии с файлами скриптов, это позволит уменьшить размер файлов стилей.

• Наличие в файлах стилей лишних правил для не поддерживаемых браузеров

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

• Использование контентных тегов для стилизации

  К таким тегам относятся br, b, strong, i, em, p, s. Данные теги необходимо использовать только в контенте, но не в стилизации интерфейса.

• Стилизация элементов по атрибутам name или id

  Эти атрибуты используются программистами и могут быть изменены ими. Для стилизации необходимо использовать классы или data-атрибуты.

• Использование одинаковых цветов, скруглений, отступов, размеров шрифтов

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

• Использование unicode-символов в файлах стилей и скриптов

  Если сайт будет работать в кодировке win-1251, или другой кодировке, отличающейся от UTF-8, то эти символы будут отображаться некорректно.

• Артефакты, возникающие при использовании стилей transform

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

• Дергающиеся и некорректно работающие анимации

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

• Разные стили плавности анимации

  Чтобы сайт смотрелся аккуратнее, все стили transition должны быть с одинаковой длительностью и плавностью. Если на сайте используется transition, то он должен быть у всех анимированных правил.

• Корректное отображение сайта с включенным режимом редактирования в CMS

  Например, в CMS Bitrix включение режима редактирования добавляет на сайт дополнительные оборачивающие теги, что может поломать вёрстку сайта, особенно, если он сверстан с использованием flex.

• Адекватные отступы между блоками контента

  Часто отступы выглядят хорошо на одном разрешении экрана, но на другом становятся или слишком большими, или слишком маленькими. Нужно адаптировать отступы на разных разрешениях экрана. Требуется обсуждение с дизайнером.

• Слишком резкая граница для overflow: hidden

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

• Наличие горизонтальной прокрутки

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

• Большой разброс z-index

  Значения z-index в стилях сайта должны иметь адекватные значения, например от 0 до 100. При корректной верстке должно быть достаточно 5-10 разных значений. Значения с огромными цифрами (например, 100000) ничего не значат, z-index работает по-другому.

7. Фавиконки

• Наличие favicon.ico и фавиконки больших размеров

  В настоящее время браузеры умеют показывать иконку сайта в высоком разрешении, поэтому стоит загружать favicon в размере 32х32px.

• Корректный список подключаемых фавиконок

  Минимальный набор иконок должен составлять favicon.ico (размер 32х32px) для отображения фавиконки в старых браузерах, favicon.svg для отображения фавиконки в новых браузерах, apple-touch-icon-180×180.png для отображения сайта в мобильных телефонах iPhone. В манифесте должы быть указаны пути к фавиконкам с размерами 192х192px и 512х512px для устройств Andriod.

• Наличие manifest.json или manifest.webmanifest

  В этом файле содержится информация, как отображать иконку сайта на разных устройствах, т.к. файл favicon.ico не всегда имеет подходящий размер и формат.

8. Шрифты

• Наличие малоиспользуемых или подключение неиспользуемых на сайте шрифтов

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

• Правильное подключение шрифтов

  Необходимо подключать шрифты в современных форматах (woff2 или woff), они меньше весят и быстрее подгружаются.

• Подключение шрифтов только из локальных источников

  Не рекомендуется подключать шрифты с помощью ссылки на сторонний ресурс, т.к. в таком случае скорость загрузки сайта становится зависимой от скорости загрузки стороннего сайта, не считая тех случаев, если сторонний сайт становится вообще не доступен.

• Предзагрузка шрифтов

  Рекомендуется подключать шрифты до загрузки стилей, чтобы, когда стили прогрузятся, шрифты сразу же отображались корректно.

• Наличие правила font-display для подключаемых шрифтов

  Данное правило указывает на то, как текст должен вести себя, пока шрифт загружается. Корректная установка этого правила позволит тексту отображаться раньше загрузки шрифта.

• Наличие fallback-шрифтов

  Резервные шрифты необходимо указывать на случай, если основной шрифт не удалось загрузить.

• Указание наличия или отсутствия засечек при использовании шрифтов

  В стилях сайта у всех правил для шрифтов должен быть быть указан serif или sans-serif. При невозможности загрузки шрифта, браузер пытается загрузить похожий шрифт, и указание на наличие засечек у шрифта помогает ему точнее найти подобный шрифт.

9. Навигация

• Битые ссылки

  Наличие битых ссылок может критически повлиять на функционал сайта, поэтому этот пункт крайне важен. Проверять на наличие битых ссылок необходимо с помощью специальных инструментов, например, с помощью программы Screaming Frog или бесплатной программы Xenu 2.

• Ссылки, которые ведут на текущую страницу (на главной странице верхний логотип сайта не должен быть ссылкой)

  Считается, что это может негативно повлиять на представление сайта для поисковых систем.

• Корректная верстка меню

  Меню должны быть реализованы через тег nav, внутри которого находятся вложенные ul.

• Корректная верстка «хлебных крошек»

  «Хлебные крошки» должны быть оформлены как меню, при этом последний элемент (текущая страница), не должен быть ссылкой. В идеале, хлебные крошки должны содержать микроразметку.

• Корректное отображение меню при различном количестве пунктов меню

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

• Наличие стилей для индикации текущего элемента в навигации и неактивных элементов

  Например, в слайдерах, если пользователь перешел к последнему слайду, то кнопка «Далее» должна становится неактивной.

10. Заголовки

• Наличие одного тега h2 на странице

  На каждой странице должен быть обязательно ровно один тег h2.

• Семантичность заголовков (должны идти по порядку)

  Не должны более мелкие (например h4, h5) заголовки идти в основном контенте перед более крупными заголовками (h2, h3).

• Правильно настроенные стили и соотношение размеров заголовков

  Заголовки по умолчанию должны выделяться на фоне остального текста, а также размеры заголовков должны соответствовать их уровню (например h2 должен быть самым крупным, h3 поменьше и т.д.).

• Заголовки должны использоваться только в контентной части, например, заголовки страницы

  Теги заголовков не должны использоваться в качестве стилей.

11. Контент

• Стили для контентных элементов должны быть прописаны: параграфы, изображения, обычные и нумерованные списки, таблицы

  Это необходимо делать для того, чтобы после разработки сайта, было удобно размещать на нём разнообразный контент, и не приходилось поправлять стили на каждой новой странице. Корректно должны быть прописаны стили для тегов: ul, ol, li, img, a, a:hover, a:focus, p, h2-h6, table, td, th, strong, em, i, b.

• Блоки сайта не должны расползаться при слишком больших размерах содержимого этих блоков

  Например, такое может происходить, если в блок с небольшой шириной поместить видео с youtube, слишком большую картинку, или таблицу с большим количеством колонок.

• Необходимо тестировать сайт с реалистичными изображениями и текстами

  Если сайт на русском языке, то тестовые тексты должны быть на русском. Тексты и изображения в идеале должны соответствовать тематике сайта. Цветовая гамма изображений также должна подходить, например, если на сайте используются только черно-белые изображения, то такие же должны быть и в верстке макетов.

• Блоки должны корректно отображаться при любом количестве контента внутри них

  В том числе, и с пустым содержимым.

• Проверка орфографии, в том числе и в самом интерфейсе

• Наличие clearfix у контейнеров с элементами со стилями float: left и float: right

  Если такого нет, то при изменении контента, верстка может поломаться.

• Некорректная микроразметка

  Для определения корректности микроразметки нужно использовать специальные сервисы для проверки. Яндекс.Вебмастер умеет проверять несколько популярных форматов микроразметки, рекомендуется использовать его для проверки.

• Корректное отображение валюты

  Все знаки валюты должны быть одинаковыми на сайте, а также отмечены специальным символом, например, символом рубля — ₽.

• Проверка вместимости длинных названий

  Названия не всегда могут помещаться в отведенное для них место, в таком случае нужно или обрезать, или настроить стили так, чтобы вёрстка не ломалась при слишком длинных названиях. Тоже самое относится к элементам с ценами, на боевом сайте цены могут быть длиннее, чем на макетах. Цены и другие числа не должны переносится на новую строку.

• Различная высота элементов в слайдерах

  Например, слайдеры карточек товаров могут содержать элементы различной высоты. Если эти элементы имеют фон или границы, то необходимо выстраивать им одну высоту, чтобы смотрелось аккуратнее.

12. Изображения

• Корректное распределение файлов изображений

  Изображения, не являющиеся интерфейсом сайта, должны лежать отдельно от файлов интерфейса.

• Корректное подключение изображений

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

• Наличие файла спрайтов для изображений интерфейса

  В идеале, все изображения в интерфейсе должны быть в одном svg-спрайте.

• Корректное подключение файла спрайтов

  Спрайты должны находится в отдельном файле и подключаться с помощью тега use. Кроме того, файл спрайтов должен корректно подключаться на старых браузерах. Например, для Internet Explorer необходим дополнительный скрипт для корректного подключения svg-файлов svg4everybody.

• Корректное центрирование изображений в контейнерах

  Если изображение находится внутри контейнера с фиксированными размерами, то его нужно центрировать с помощью flex.

• Некорректное содержимое svg-файлов

  Svg-файлы не должны содержать в себе лишние теги, которые не отображаются в интерфейсе и тормозят загрузку. Svg-файлы должны быть минифицированы.

• Корректные размеры изображений

  Размеры изображений должны точно совпадать с размерами контейнера, в котором они расположены или должны быть увеличены в 2-3 раза для поддержки мониторов retina.

• Корректные стили для изображений

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

• Адаптация изображений под мониторы высокого разрешения

  Под retina-мониторы физический размер изображений должен быть в два а в идеале в 3 раза больше, в зависимости от требований проекта.

• Плохая оптимизация медиа-файлов

  Все медиа-файлы (изображения, видео) должны быть максимально сжаты для оптимального соотношения размер/качество и должны воспроизводится на всех поддерживаемых браузерах.

  Чтобы понять, достаточно ли сжаты изображения на сайте, достаточно проверить эту страницу через сервис Google PageSpeed Insights. Этот сервис укажет, какие изображения недостаточно оптимизированы, и напишет рекомендации, что надо сделать в этом случае. Для пользовательских изображений можно использовать сторонний сервис для сжатия, например https://tinypng.com/ или аналогичный. Для остальных типов медиа файлов нельзя указать конкретные рекомендации, в целом нужно пытаться как можно сильнее уменьшить размеры файлов.

• Отсутствие ленивой загрузки изображений

  Все тяжелые файлы (изображения и видео) должны загружаться отложено, после всего остального контента, а в идеале после того, как пользователь прокрутил до места, где эти файлы находятся.

• Изображения разных пропорций, загруженных в одной галерее

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

• Наличие оптимизации изображений, загружаемых пользователями

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

• Изображение капчи должно центрироваться относительно соседних блоков

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

13. Ссылки и кнопки

• Наличие в ссылках на сторонние сайты атрибута rel=»noopener»

  Этот атрибут необходимо добавлять в целях безопасности, чтобы через сторонние сайты нельзя было получить доступ к основному сайту.

• Выделение интерактивных элементов при наведении и фокусе

  Часто это не показано на макетах сайта и не обговаривается отдельно, но для удобства использования сайта необходимо выделять интерактивные элементы на сайте. Также ссылки должны корректно подсвечиваться при выделении их через tab. Требуется обсуждение с дизайнером.

• Телефоны и электронные почты должны быть прописаны как ссылки

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

• Все нажимаемые области должны иметь cursor: pointer

  Это позволяет пользователю показать, какие элементы на сайте являются интерактивными.

• Наличие атрибутов target=»_blank»

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

• Наличие корректных атрибутов type и role для кнопок и ссылок

  Атрибут type не валиден на тегах <a>, атрибут role=»button» нельзя ставить для ссылок, по которым можно перейти на другую страницу. Часто от этого могут сломаться стили или скрипты.

• Наличие специальных общих классов для кнопок и полей ввода

  Имеются ввиду общие классы типа btn или form-control для того, чтобы можно было применять общие стили для кнопок или полей ввода, а не застиливать каждую кнопку отдельно.

• Стилизация кнопок, полей ввода и чекбоксов без помощи скриптов

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

• Наличие пустых ссылок

  На сайте не должно быть ссылок, которые никуда не ведут, например ссылки с href=»#». Если такой элемент всё же необходим, то нужно использовать button для этого. В крайнем случае, нужно писать href=»javascript:void(0)», чтобы при нажатии на эту ссылку пользователя не прокручивало к началу страницы. Наличие пустых ссылок можно проверить разными программами, мы пользуемся Chrome-расширением Check My Links.

• Ссылки, ведущие на небезопасные ресурсы

  На защищенном сайте (https) не должно быть ссылок на ресурсы, доступные по небезопасному соединению (http). В таком случае весь сайт перестает считаться безопасным.

• Некорректное поведение кнопок на тач-устройствах

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

• Незастиленные ссылки при наведении

  Часто ссылки стилизуют как в макете, но забывают убрать стандартные стили при наведении. Из-за этого, при наведении, ссылка подчеркивается, что не всегда выглядит презентабельно.

• Незастиленные ссылки при фокусе

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

• Наличие неактивных кнопок, на которые можно нажать

  Неактивные элементы должны быть полностью неактивны. На них не должно быть курсора «пальца», и также нужно отключать скрипты, срабатывающие при нажатии этих кнопок.

14. Футер

• Расположение футера, если контента меньше, чем на всю высоту экрана

  Под футером не должно быть пустого пространства.

• Наличие фиксированной высоты у футера

• Отступы перед футером должны быть одинаковые на всех страницах

• Слишком маленький отступ внизу футера

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

15. Формы

• Правильно прописанные заголовки полей (label)

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

• Проверка стилей кнопок и полей ввода

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

• Наличие атрибутов для ограничения длины ввода

• Наличие масок для полей ввода

  Как минимум маски можно поставить на все цифровые поля: телефоны, цены, даты.

• Клиентская валидация полей ввода

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

• Корректные атрибуты type у полей ввода

  Например, для телефонов нужно указывать type=»tel», для email-ов — type=»email» и т.п. В мобильных браузерах это позволяет открывать правильную клавиатуру при фокусе на поле.

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

• Изменение размеров textarea не должно ломать верстку

  Обычно, для этого достаточно запретить изменение размера поля по ширине.

• Различные стили элементов форм в разных браузерах и устройствах

  Для одинакового вида элементов во всех браузерах необходимо сбрасывать стили для элементов форм.

• Наличие уведомления после отправления формы

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

• Корректный вид уведомлений

  Уведомления об отправке форм должны быть в стиле сайта, для этого не должен использоваться стандартный alert.

• Наличие клиентской валидации

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

• Корректный сброс формы после отправки

  Все поля должны очищаться, попапы — закрываться, все классы валидации должны быть сброшены.

• Проверка отправки формы по нажатию Enter

  Деактивация кнопки отправки не гарантирует того, что форму нельзя отправить.

• Корректная работа форм при нажатию кнопки «Назад» в браузере

  При возвращении на страницу с заполненной формой поля формы остаются заполненными, но скрипты для этих форм не воспроизводятся.

• Некорректная повторная отправка форм

  Часто после отправки формы воспроизводятся скрипты, но некорректно сбрасываются после этого. Все формы нужно отправлять повторно.

• Слишком высокие формы в мобильных браузерах

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

Как проверить сайт на предмет структурированных данных и возможностей поиска

Структурированные данные в SEO — часто используемые как синонимы схемы — это способ разметки HTML веб-страницы, чтобы сделать ее содержание более читабельным для поисковых роботов, таких как Google, помогая сканерам понять содержание страницы. Структурированные данные часто позволяют страницам использовать функции поиска (также известные как расширенные результаты).

Хотя люди могут использовать термины «Схема» и «Разметка структурированных данных» как синонимы, между ними есть различия: Схема относится к схеме.org, который предоставляет стандартизированный словарь, который поисковые системы (Google, Bing, Яндекс и т. д.) могут читать и поддерживать.

Существуют и другие словари за пределами Schema.org, которые можно использовать для разметки структурированных данных: microformats.org также предлагает словарь для определения физического местоположения, организации или человека (разметка hCard) или для обзоров продуктов (разметка hReview).

— это результаты, которые добавляют дополнительную информацию или контекст помимо традиционных ссылок, заголовков и метаописаний.Они предназначены для максимально быстрого предоставления ответов на запросы пользователей без необходимости нажимать на результат поиска. Еще одно преимущество функций поиска заключается в том, что они занимают ценное пространство вверху страницы результатов, увеличивая вероятность перехода по ссылкам на вашей странице.

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

В результате разметка структурированных данных (например, с использованием утвержденного словаря из Schema.org) может помочь вашим усилиям по поисковой оптимизации за счет улучшения внешнего вида данной страницы в результатах поиска.

ПРИМЕЧАНИЕ. В этом посте мы ссылаемся на схему.организационная иерархия словарного запаса. Вы можете использовать microformats.org (например, hCard, hReview), поскольку он по-прежнему поддерживается поисковыми системами. Тем не менее, рекомендуется выбирать один словарь вместо другого (например, Schema.org или microformats.org), чтобы избежать дублирования — или кажущегося спамом — структурированной разметки данных и риска снижения рейтинга ваших веб-страниц.

Возможно, на вашем сайте уже реализованы структурированные данные.Вы можете проверить, нашел ли Google эту разметку и есть ли какие-либо ошибки, которые нужно исправить в Google Search Console (GSC).

Исправление ошибок — первоочередная задача любого аудита структурированных данных, поскольку Google может наказывать сайты (с помощью алгоритмических факторов качества или ручных действий), которые используют разметку неправильно или выглядят как спам.

Для начала перейдите в раздел GSC Enhancements ; здесь появится любая обнаруженная разметка структурированных данных.

В этих отчетах вы узнаете, есть ли на ваших страницах с разметкой ошибки (которые следует устранить как можно скорее) или предупреждения (полезные оптимизации).

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

Если вы нажмете на подробную информацию о данном предупреждении, GSC предоставит дополнительную информацию об ошибке, а также список затронутых URL-адресов для дальнейшего изучения.

Если вы хотите проверить свои пересмотренные структурированные данные, вы можете протестировать их с помощью Rich Results Test (RRT) — замены Google для инструмента проверки структурированных данных — который позволяет вам проверять вашу разметку напрямую или проверять заданный URL.

На этом этапе мы ищем просто общие «типы» контента, найденного на вашем сайте, и наличие у этих типов контента подходящей функции поиска, для которой они могут быть оптимизированы.

Например, типичный сайт электронной коммерции / розничной торговли может включать:

• Цена на продукт
  • Рекомендуемая разметка: Продукт
• Видео о продуктах
  • Рекомендуемая разметка: VideoObject
• Обзоры продуктов
  • Рекомендуемая разметка: Обзор
• Редакция / Содержание блога
  • Рекомендуемая разметка: BlogPosting
• Местоположение / Контактная информация
  • Рекомендуемая разметка: LocalBusiness
• Загрузка программного обеспечения / приложения
  • Рекомендуемая разметка: SoftwareApplication

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

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

После того, как вы определите типы контента для разметки, просмотрите документацию Schema.org, чтобы найти все поддерживаемые в настоящее время типы Schema.org. Цель состоит в том, чтобы найти наиболее конкретную разметку, которая точно применима к каждому типу и / или части контента на вашем сайте.

Предполагая, что ваш сайт находится в сфере электронной коммерции или B2B, вы, вероятно, захотите использовать следующие типы разметки:

• Продукт
• Событие — даже если вы не проводите личные мероприятия, вы можете использовать эту разметку для виртуальных сессий и вебинаров
• Организация
• Человек
• Место
• Творческая работа — в этом типе вы найдете Статьи и блогПубликация любого редакционного контента

Эти обширные области должны охватывать большую часть контента на вашем сайте.Однако, если вы не уверены, существует ли более конкретный тип разметки, выполните поиск в Google по определенному типу разметки.

Для создания разметки структурированных данных у вас есть несколько вариантов:

1. Используйте инструмент Google Structured Data Highlighter Helper: предварительное условие требует, чтобы ваш сайт был настроен в Google Search Console.
   • Плюсы:
     1. это инструмент WYSIWYG (то, что вы видите, то и получаете), поэтому создать разметку очень легко.
     2. этот инструмент применяется к «наборам страниц», и, таким образом, его можно создавать по шаблонам и публиковать на нескольких страницах по адресу после
     3. вы можете публиковать свою разметку напрямую через инструмент, поэтому вам не нужно полагаться на разработчика.
   • Минусы:
     1. варианты разметки ограничены, в том числе только: статьи, события, местные предприятия, рестораны, продукты , Программные приложения, фильмы, телесериалы и книги
     2. инструмент работает только на страницах, которые уже были просканированы Google; если вы хотите разметить недавно опубликованную статью или продукт, задержка сканирования может задержать процесс
     3. Ваши размеченные данные будут распознаваться только Google, но не другими поисковыми системами, такими как Bing
2. Используйте разметку структурированных данных Google Helper
   • Плюсы:
     1. размеченные данные распознаются всеми применимыми поисковыми системами (т.е.е. Google и Bing)
     2. генерирует структурированные данные в виде микроданных или JSON-LD.
   • Минусы:
     1. . Как и в случае с помощником по выделению данных, варианты разметки ограничены: статьи, события, местные предприятия, рестораны, продукты, программные приложения , Фильмы, сериалы, книги, наборы данных и вопросы и ответы
     2. в отличие от Highlighter Helper, разработчику необходимо реализовать структурированные данные
3. Сделайте это самостоятельно, используя примеры из схемы.org и проверка вашего кода в RRT.
   • Плюсы:
     1. используйте любую разметку, поддерживаемую Schema.org (по состоянию на октябрь 2020 года существует более 800 типов)
     2. Schema.org предоставляет примеры JSON-LD, микроданных и RDFa всей своей разметки, которые вы можете скопировать и перепрофилировать
     3. вы можете выбрать JSON-LD, микроданные или RDFa
   • Минусы:
     1. Как и в случае с любым новым набором навыков / языком, существует кривая обучения
     2. , которая необходима разработчику для реализации вашей разметки

Примечание: Диспетчер тегов Google не является подходящим способом реализации разметки структурированных данных; любая развернутая вами разметка будет видна после загрузки страницы , что лишает смысла отображение разметки для поисковых роботов.

Как упоминалось ранее, Schema.org предоставляет нам словарь для использования при реализации разметки структурированных данных для вашего контента. Есть несколько способов использования разметки, предоставленной Schema:

Микроданные в разметке схемы — это аннотации, встроенные в HTML данного элемента.

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

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

RDFa в разметке схемы выглядит и реализуется очень похоже на микроданные: с помощью встроенного HTML вы можете определять свойства типов и элементы тегов, такие как изображение продукта, рейтинги, цены и т. Д.Подобно микроданным, RDFa — приемлемый способ разметки ваших веб-страниц. Тем не менее, возможно, сложнее масштабировать до нескольких страниц без использования логических правил для выявления похожих элементов на вашем сайте (подумайте: сотни изображений продуктов, цен, обзоров и т. Д.).

JSON-LD — это третий вариант разметки структурированных данных от Schema.org, который отличается от Microdata и RDFa тем, что отдельные элементы в вашем контенте размечены отдельно от самого контента; JSON-LD — это объект Javascript, который может находиться в тегах или ваших веб-страниц.Поскольку JSON-LD не реализован в элементах HTML, его реализация (и любые последующие обновления) проще путем копирования и вставки в виде отдельного скрипта. Возможно, JSON-LD — «лучшая» кодировка разметки схемы для оптимизаторов поисковых систем, редакторов контента и разработчиков.

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

Инструмент проверки структурированных данных Google Shutters

В своем блоге Google Analytics объявил 2020 год Годом избранных сниппетов. С момента создания Google ее приоритетом было как можно быстрее и точнее находить ответ на любые запросы. В настоящее время миссия поисковой системы реализуется концепцией под названием Zero Click Searches. При этом пользователь получает ответ на вопрос прямо в поисковой выдаче, не переходя на сайт.Реализация этого расширенного поиска стала возможной благодаря богатым сниппетам. Подробнее читайте в статьях Что такое SERP в 2020 году? и что такое Rich Snippets?

Идея использования структурированных данных не нова. В 2011 году представители Google, Yahoo !, и Microsoft внедрили универсальную систему разметки Schema.org. Сегодня более 10 миллионов сайтов используют этот открытый язык структурированных данных на своих веб-страницах и в электронных письмах. Для работы с метаданными можно выбрать один из трех основных форматов: микроданные, RDFa (структура описания ресурсов в атрибутах) или JSON-LD (нотация объектов JavaScript для связанных данных).Словарь Open Graph работает по аналогичному принципу и создает расширенные сниппеты для сообщений в социальных сетях. Facebook не был бы самим собой, если бы не был создан собственный протокол, основанный на RDFa. Вы можете прочитать дополнительную информацию в соответствующей статье Open Graph Meta Tags.

Роль разметки в формировании расширенных результатов поиска продолжает расти. Это означает, что инструменты для работы с кодом также нуждаются в улучшении. В июле 2020 года Google сделал важный шаг. Инструмент проверки структурированных данных был заменен тестом с расширенными результатами.Однако на этом нововведения не заканчиваются. Давайте рассмотрим, какие рекомендации предлагает Google в отношении структурированных данных сегодня, инструменты, которые следует использовать для их проверки, и как это можно связать с новым фактором ранжирования. Также прочтите соответствующую статью Что такое структурированные данные?

Почему важно размещать разметку на сайте

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

Метаданные являются основой семантического поиска, поскольку с их помощью сканеры реагируют не только на ключевые слова, но и на контекст статьи. Alexa, Google Assistant и другие голосовые устройства дают соответствующий ответ в ⅔ случаев, основываясь на информации из микроразметки. Структурированные данные также используются в большинстве алгоритмов машинного обучения и статического анализа.

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

Одним из основных приоритетов Google является предоставление пользователям данных, максимально соответствующих их запросам. Чем больше данных вы собираетесь включить в код, тем выше вероятность того, что вы найдете расширенные результаты поиска.

В свою очередь, пользователям легче воспринимать сниппеты. Они наглядно отображают суть вашего материала, позволяют быстро оценить, будет ли сайт полезен в конкретном случае и стоит ли переходить по ссылке. Прочтите соответствующую статью о том, как оптимизировать избранные фрагменты.

Повышение лояльности клиентов

Расширенные сниппеты делают сайт более заметным на фоне конкурентов. Визуальные блоки привлекают внимание, а ваша задача — максимально заинтересовать пользователей.Помимо основной информации — заголовка, краткого содержания и адреса страницы — во фрагмент можно добавить некоторые интригующие детали, например изображения или видео.

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

Если вы владелец ресторана, укажите в сниппете рейтинг, тип кухни, часы работы и телефон. Дополнительной особенностью может стать календарь выступлений живых коллективов. Пусть ваши потенциальные клиенты узнают самую полезную информацию прямо из поисковой выдачи.

 


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

 

 


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