Проверка микроразметки: Валидатор микроразметки — Вебмастер. Справка

Содержание

Валидатор микроразметки — Вебмастер. Справка

В число инструментов Яндекс.Вебмастера входит валидатор семантической разметки. Валидатор поможет убедиться, что метаданные на ваших страницах распознаются корректно. Поддерживаются микроформаты, Schema.org, Open Graph, микроданные HTML и RDFa.

В отличие от других валидаторов разметки (Validator.nu, Structured Data Linter и т. п.) валидатор Яндекса также проверяет соответствие разметки требованиям сервисов Яндекса, учитывая все дополнительные типы и поля данных, введенные нами.

C техническими деталями распознавания разметки можно ознакомиться в статье Как и для чего мы сделали свой валидатор микроразметки.

Чтобы проверить код страницы, введите ее адрес в поле URL документа, или вставьте код ниже. Затем нажмите кнопку Проверить.

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

  1. Ошибки
  2. Предупреждения
Ошибка Описание
Страница не может быть загружена Страница не существует, или недоступна для робота Яндекса
Микроразметка не обнаружена

Валидатор не смог распознать ни одного корневого элемента разметки — из-за того, что разметки нет, или корневые элементы оформлены неверно. Например, в корневом элементе Schema.org пропущен атрибут itemscope.

Неправильно:

<div itemtype="http://schema.org/Movie">

Правильно:

<div itemscope itemtype="http://schema.org/Movie">
Поле <…> отсутствует или пусто

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

Неправильно:

<div itemscope itemtype="http://schema.org/ImageObject">
  <h3 itemprop="name">Винни-Пух</h3>
  <img src="http://example. com/image.png"/>
  <span itemprop="description">Винни-Пух и все-все-все.</span>
</div>

Правильно:

<div itemscope itemtype="http://schema.org/ImageObject">
  <h3 itemprop="name">Винни-Пух</h3>
  <img src="http://example.com/image.png" itemprop="contentUrl"/>
  <span itemprop="description">Винни-Пух и все-все-все.</span>
</div>
Невозможно определить принадлежность данных полей Возможны две причины: поля некорректно размещены; указан лишний атрибут itemprop. Арибуты, относящиеся к микроданным (itemprop, в частности) должны быть размещены внутри элемента, содержащего itemscope (указание на наличие объекта) и itemtype (указание на тип объекта). Подробно
Не выполнено обязательное условие для продуктовых сниппетов Рекомендуем исправить данную ошибку, если вы хотите получить структурированные сниппеты в поисковой выдаче Яндекса
В свойстве content тега meta не может содержаться ссылка Для использования ссылки используйте тег link вместо тега meta
Предупреждение Описание
Значение «…» в поле <…> не является корректным значением

Значение поля не соответствует стандарту. Например, дата в Schema.org должна быть указана в формате ISO 8601, дата в другом формате не распознается корректно.

Неправильно:

<meta itemprop="datePublished" content="2012/07/15">

Правильно:

<meta itemprop="datePublished" content="2012-07-15">
Тип <…> неизвестен по спецификации <…> Указанный тип данных не входит в число стандартных типов формата или в число типов, введенных Яндексом. Убедитесь, что имя типа данных указано верно

В данный момент разметка <…> не может использоваться отдельно от разметки <…>.

Чтобы ваши данные использовались в сервисе <…>, необходимо дополнительно указать поля <…>

Валидатор предупреждает, что разметка корректна, но сервисы Яндекса не смогут использовать извлеченную информацию. Ознакомьтесь с информацией в разделе Введение в schema.org, чтобы правильно дополнить разметку

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

Сведения об образовательной организации — ОмГМУ

Приказ Рособрнадзора от 14.08.2020 №831 «Об утверждении Требований к структуре официального сайта образовательной организации в информационно-телекоммуникационной сети «Интернет» и формату представления информации».

Методические рекомендации представления информации на сайтах ОО — 2020

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

График на 2021 год

Этап Дата проведения Название Особенности проведения
Мероприятия в рамках мониторинга системы образования в соответствии с Приказом Федеральной службы по надзору в сфере образования и науки от 10.06.2019 №796 «Об установлении процедуры, сроков проведения и показателей мониторинга системы образования Федеральной службой по надзору в сфере образования и науки». Для реализации автоматической проверки необходимо наличие на официальном сайте организации микроразметки. При отсутствии микроразметки проверка сайта производится экспертным путем.
1 этап 1 часть 01.07.2021 — 01.08.2021 Организация приёмной кампании 2021 года. Информация о приеме на обучение по программам ординатуры, подлежащая размещению на сайте ОО не позднее 1 апреля Анализируются ОО у которых имеется действующая лицензия по программам ординатуры. Анализ сведений, размещённых на официальных сайтах вузов с помощью сервисов автоматизированной проверки. Контроль «не найденных» по результатам автоматизированной проверки параметров в ручном режиме.
1 этап 2 часть 01.11.2021 — 10.11.2021 Организация приёмной кампании 2022 года. Информация о приеме на обучение по программам бакалавриата, специалитета, магистратуры и подготовки научно-педагогических кадров в аспирантуре, подлежащая размещению на сайте ОО не позднее 1 ноября года, предшествующему приему. Анализ сведений, размещённых на официальных сайтах вузов с помощью сервисов автоматизированной проверки. Контроль «не найденных» по результатам автоматизированной проверки параметров в ручном режиме.
1 этап 3 часть 01.07.2021 — 01.09.2021 Организация приёмной кампании 2021 года. Информация о приеме на обучение по образовательным программам высшего образования, подлежащая размещению на сайте ОО не позднее 1 июня Анализ сведений, размещённых на официальных сайтах вузов с помощью сервисов автоматизированной проверки. Контроль «не найденных» по результатам автоматизированной проверки параметров в ручном режиме.
1 этап 4 часть 01.09.2021 — 01.10.2021 Организация приёмной кампании 2021 года. Информация по организации приемной кампании по образовательным программам высшего образования, подлежащая размещению на сайте ОО позже 1 июня Анализ сведений, размещённых на официальных сайтах вузов с помощью сервисов автоматизированной проверки. Контроль «не найденных» по результатам автоматизированной проверки параметров в ручном режиме.
1 этап 5 часть, 4 этап 01.11.2021 — 05.11.2021 г. Организация приёмной кампании 2021 года. Своевременность и полнота внесения сведений в ФИС ГИА и Приема, ФИС ФРДО и соответствие этих сведений сведениям, представленным на сайте ОО Контроль соблюдения установленного срока внесения сведений. Экспертный контроль соответствия данных в ФИС ГИА и Прием и ФИС ФРДО с данными на сайте ОО.
2 этап 01.06.2021 — 01.07.2021 г. Мониторинг обеспечения доступности получения высшего образования инвалидами и лицами с ОВЗ Анализ сведений, размещённых на официальных сайтах вузов с помощью сервисов автоматизированной проверки. Контроль «не найденных» по результатам автоматизированной проверки параметров в ручном режиме.
3 этап 01.07.2021 — 01.11.2021
Полнота размещения на сайте образовательной организации установленной законодательством информации
Анализ сведений, размещённых на официальных сайтах вузов с помощью сервисов автоматизированной проверки. Контроль «не найденных» по результатам автоматизированной проверки параметров в ручном режиме.
5 этап 05.11.2021 — 06.11.2021 Итоговый мониторинг соблюдения требований законодательства. Расчёт рейтинга ОО по количеству нарушений Сопоставление сведений, размещённых на официальных сайтах вузов и представленных в ФИС ГИА и приёма, в части организации и проведения приёмной кампании. Анализ сведений, представленных в ФРДО. Сведения предоставляются Управлением. Расчет рейтинга.

 

для чего нужны, микроразметка ХК – самостоятельное продвижение сайтов bdbd.ru

Начнем с определения, что же это такое за навигационное меню «Хлебные крошки» (сокращенно ХК) — это полный путь, показывающий в какой категории, находится пользователь. Помимо очевидного удобства для пользователей, это меню также является элементом перелинковки.

Например, если пользователь зашел на страницу «Люстры на кухню», то ХК будут выглядеть следующим образом:

Главная / Каталог / Люстры / Люстры на кухню

Правила формирования навигационного меню «Хлебные крошки»

  • 1. Меню должно содержать полный путь от главной до текущей страницы включительно.
  • 2. С каждого пункта меню, кроме последнего должна быть ссылка на соответствующую страницу.
  • 3. Анкоры в ХК должны включать в себя ключевые слова, но при этом обращайте внимание на спамность.

Например, если на вашем сайте большая вложенность, то не стоит злоупотреблять вхождениями:

Главная / Каталог / Женская одежда / Женские юбки / Кожаные женские юбки / Кожаные женские юбки на молнии

В таком случае лучше оформить так:

Главная / Каталог / Женская одежда / Юбки / Кожаные / Кожаные женские юбки на молнии

  • 4. «Хлебные крошки» должны находиться на каждой странице сайта под основным меню.
  • 5. Они не должны быть яркими и привлекать к себе сильное внимание. Идеальный вариант: небольшой серый шрифт.
  • 6. В ХК можно и даже нужно использовать микроразметку.

Пример правильного оформления ХК

Пример неправильного расположения ХК

Микроразметка хлебных крошек

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

Пример снипета с размеченными ХК

Не будем детально разбираться как именно её делать, вся необходимая информация есть тут: https://schema.org/BreadcrumbList

Проверка микроразметки в Google: https://search.google.com/structured-data/testing-tool/u/0/

Проверка микроразметки в Яндекс: https://webmaster.yandex.ru/tools/microtest/

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

Вывод

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

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

Разметка ​Open Graph: теги, примеры, проверка, картинки

В процессе разработки над нашими проектами, не раз сталкивались с проблемой правильной микроразметки Open Graph. В статье хотим поделиться решением, которое подойдет в 99% случаев.

Для начала ответим на вопрос, что такое разметка Open Graph и зачем она нужна?

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

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

Остается вопрос, но как пользователи делятся публикациями? Разберем часто используемое решения:

Кнопки «Поделиться» на сайте

Этот функционал предлагают несколько сервисов. Например, мы используем Яндекс для русскоговорящих проектов или Addthis для всего остального мира.

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

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

Что бы репост в социальной сети был красивый, надо внедрить микроразметку Open Graph.

Протокол Open Graph от Facebook

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

Говоря проще Open Graph разработали в Facebook для контроля текстово-графического анонса, который формируется при добавлении ссылки в социальную сеть.

Зачем нужен Open Graph?

  1. Пользователь увидит релевантный/интересный/привлекательный текст и нужное изображение, которое настроит веб-мастер.
  2. Сниппет будет выглядеть как пост, который можно разместить в соцсети, а не как ссылка, к которой нужны дополнительное описание и картинка.
  3. Оформленное превью выглядит лучше, а значит улучшает поведенческие факторы, приносит больше кликов.

Разметку Open Graph поддерживают соцсети (ВКонтакте, Facebook, Twitter, Pinterest, Одноклассники) и мессенджеры (Telegram, Skype) и другие.

Разберемся, как настроить разметку Open Graph для страницы.

Теги Open Graph

Протокол Open Graph состоит из мета-тегов, их интегрируют в HTML-код страницы в секцию head.

Основные теги Open Graph

  • og:title — название материала;
  • og:description – описание материала, заполнять не обязательно;
  • og:image – ссылка на картинку, которая должна сопровождать материал;
  • og:type – тип добавляемого материала, например, «website» — для сайта и самая используемая, «article» – статья, «movie» – кино и т.д.;
  • og:url – ссылка на саму веб-страницу, которая добавляется в социальную сеть.

Дополнительные теги Open Graph

  • og:site_name — название сайта;
  • og:locale – язык сайта, необязательные тег;
  • og:image:width – ширина изображения, рекомендуем обязательно использовать, ускоряет скраппинг;
  • og:image:height – высота изображения, рекомендуем обязательно использовать, ускоряет скраппинг.

Дополнительные теги Open Graph для Twitter

  • twitter:creator — ник канала в Twitter, начинается с @;
  • twitter:card – типа карточки «summary», «summary_large_image», «app», or «player».

Обратие внимание, на тот факт, что твиттер просит использовать name, а не property.

<meta name="twitter:creator" content="@PaLPaLyCH">
<meta name="twitter:card" content="summary_large_image">

Пример разметки Open Graph

<meta property="og:type" content="website">
<meta property="og:site_name" content="Студия Палыча">
<meta property="og:url" content="https://palpalych.ru/cases/sites/sajt-hudozhnika">
<meta property="og:locale" content="ru">
<meta name="twitter:creator" content="@PaLPaLyCH">
<meta name="twitter:card" content="summary_large_image">
<meta property="og:title" content="Создан сайт художника">
<meta property="og:description" content="Создан сайт художника, правда не смогли его выложить в Интернет по решению заказчика. ">
<meta property="og:image" content="https://palpalych.ru/storage/app/media/2019/sajt-hudozhnika_soc.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

Этот пример Open Graph самодостаточен для публикации практически во все социальные сети.

Требования к картинке для разметки

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

На хабре рекомендуют изображение в 968×504 пикселя, это меньше минимально рекомендованных Фейсбуком. Зато при таком размере и ратио картинку нигде не кропят, и выглядит она отлично.

Мы используем размер рекомендованный Фейсбуком 1200×630 пикселей.

Где проверить разметку Open Graph?

Тут всё просто. Идем на страницу «Отладки репостов» в Facebook и на страницу Card validator в Twitter. Вставляете вашу ссылку и проверяете.

Да прибудет с вами лайк, шер да репост!

Использование микроразметки Schema org

Дата публикации: 18-09-2018       1680

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

В этой статье мы поможем Вам разобраться в понятии микроразметки и приведем примеры ее кодов с указанием мест их размещения на веб-сайте.

Содержание:

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

Schema org — сервис, размещающий публикации схем микроразметки, понимающих лучшими поисковиками (Google, Яндекс). Здесь под схемой понимаются определенные теги html кода. Видя эти теги, поисковики отыскивают необходимую информацию, имеющуюся на сайте, повышая тем самым поисковую выдачу результативности последнего.

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

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

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

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

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

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

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

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

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

  • div — указывает на начало и конец процесса описания объекта;
  • span — содержит описание свойств объекта словесного представления;
  • time — указывает дату и время. Обязательный атрибут datatime позволяет указывать выбранный тип отображения данных;
  • — применяется при размещении видимых для пользователей ссылок;
  • 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), чтобы избежать дублирования — или кажущегося спамом — структурированной разметки данных и риска снижения рейтинга ваших веб-страниц.

Шаг 1. Оцените текущую разметку структурированных данных (если есть)

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

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

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

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

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

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

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

Шаг 2. Аудит содержимого сайта на предмет возможности поиска

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

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

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

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

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

Шаг 3. Сопоставьте содержимое с типами схем

После того, как вы определите типы контента для разметки, просмотрите документацию 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

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

JSON-LD

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 является предоставление пользователям данных, максимально соответствующих их запросам. Чем больше данных вы собираетесь включить в код, тем выше вероятность того, что вы найдете расширенные результаты поиска.

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

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

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

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

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

Рейтинг

согласно Core Web Vitals

В мае 2020 года Google объявил о запуске нового алгоритма ранжирования Core Web Vitals. Он предусматривает совершенно новый подход к анализу пользовательского опыта, который будет применяться ко всем страницам, начиная с 2021 года.Core Web Vitals объединит в себе все следующие инструменты для анализа эффективности сайтов: Lighthouse, Chrome DevTools, PageSpeed ​​Insights, Search Console’s Speed ​​Report.

Это позволит пользователям одновременно оценить скорость загрузки, уровень интерактивности, визуальную стабильность и общее впечатление от ресурса. Более подробную информацию по этому вопросу можно найти в статье Core Web Vitals. На данный момент новый алгоритм основан на трех ключевых UX-метриках:

.
  1. Largest Contentful Paint (LCP) вычисляет время загрузки и рендеринга содержимого первого экрана.Отображение заголовка, изображения и текстового блока должно занять 2,5 секунды. Для этого необходимо оптимизировать блокировку рендеринга элементов JavaScript, CSS и время ответа сервера. Также необходимо проанализировать скорость рендеринга на стороне клиента.
  2. First Input Delay (FID) измеряет время отклика страницы во время взаимодействия от щелчка по ссылке или кнопке до момента, когда браузер полностью выполнит этот запрос. Оптимальный показатель для этой метрики — 100 миллисекунд.
  3. Cumulative Layout Shift (CLS) оценивает визуальную стабильность того, насколько быстро пользователь получает доступ к основному контенту по шкале от 0 до 1, не отвлекаясь на рекламу, всплывающие окна и виджеты. В идеальном сценарии сдвиг макета со сменой кадров визуальных элементов должен иметь максимальную скорость 0,1.

Проверить, соответствует ли сайт указанным рекомендациям, можно в официальном приложении Web Vitals для Chrome или в Lighthouse 6.0. Для этой цели можно также использовать Page Speed ​​Insights, Отчет о пользовательском опыте Chrome и Google Search Console.

Микроразметка для расширенных сниппетов не влияет на скорость и визуальную стабильность сайта. Однако он играет важную роль в формировании положительного впечатления о ресурсе и позволяет быстрее найти необходимую информацию. Google предупредил, что новые показатели будут постепенно добавляться к базовым Core Web Vitals. Вероятно, одним из инструментов оценки взаимодействия станет Rich Snippet Test Tool.Окончание бета-тестирования практически совпало с анонсом Core Web Vitals.

Как проверить действительность микроразметки

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

В каких случаях Google не отображает контент в поисковой выдаче

Прежде всего, необходимо убедиться, что данные открыты для сканирования и индексации. В остальном требования к структурированным данным довольно просты. В случае нарушения правил Google может снизить позицию сайта в поисковой выдаче или отказаться отображать его в расширенных результатах поиска. Чтобы узнать о примененных санкциях, проверьте отчет «Меры, принятые вручную» в Google Search Console. Вы также можете прочитать соответствующую статью Алгоритмы Google, влияющие на SEO.

  1. Структурированные данные должны соответствовать содержимому страницы.
  2. Метаданные должны быть полностью подкреплены полезной информацией. Запрещается создавать пустую страницу только для разметки.
  3. Недопустимо использование метаданных для описания контента, скрытого от пользователей.
  4. Спам в метаданных и соответствующем содержимом строго запрещен.
  5. Размеченный контент должен быть уникальным, актуальным и не вводить пользователей в заблуждение. Запрещается использовать разметку для пропаганды противоправных действий, насилия или нетерпимости к определенной группе людей.

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

Даже идеально написанные метаданные не могут дать 100% гарантии, что сайт будет отображаться в расширенных фрагментах по каждому запросу. Google SERP формируется индивидуально для каждого поискового пользователя. С учетом типа устройства, геолокации и других данных ваш ресурс может отображаться не в развернутых результатах, а на общей странице результатов поиска как классическая ссылка.

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

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

Искать в Google

В июле 2020 года Google отказался от дальнейшей поддержки инструмента проверки структурированных данных.Некоторое время он будет доступен для использования. Однако уже настоятельно рекомендуется использовать тест Rich Results для проверки разметки. Он унаследовал основные функции инструмента проверки структурированных данных в дополнение к более удобному интерфейсу и расширенной функциональности.

Инструмент тестирования Google Rich Snippet

Rich Results Test успешно прошел стадию бета-тестирования и на сегодняшний день считается одним из самых значимых инструментов для тестирования сайтов, наряду с AMP Test Tool и Mobile-Friendly Test Tool.Необходимо еще раз подчеркнуть важность скорости загрузки сайта. Это ключевой фактор для Core Web Vitals. С помощью этого инструмента можно точно определить, насколько разметка соответствует рекомендациям Google. В чем его преимущества по сравнению с валидаторами предыдущих поколений?

  1. Инструмент проверки схемы Google показывает, какие функции расширенного поиска можно реализовать с помощью вашей разметки. Он также показывает, какие элементы кода заслуживают вашего особого внимания.Инструмент работает со всеми типами структурированных данных, такими как статьи AMP, видео, карусели, рейтинги, летающие страницы, рецепты, хлебные крошки, часто задаваемые вопросы и т. Д.
  2. В зависимости от типа устройств, которым присвоен приоритет, можно выбрать соответствующий агент, например Googlebot для ПК или смартфонов, который устанавливается по умолчанию.
  3. Инструмент синхронизирован с отчетами из Search Console. Исправляя ошибки, можно вносить изменения в код прямо из теста Rich Results.

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

Искать в Google

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

  1. Проблемы с доступом появляются, когда страница закрывается от поисковых роботов файлом robots.txt или страница недоступна по техническим причинам.
  2. Отдельные элементы на странице не загружаются. В предыдущем случае необходимо убедиться, что все данные открыты для пользователей и поисковых роботов. Низкая скорость обработки данных сервером также может быть источником проблем.
  3. Ошибки в синтаксисе недоумевает робот. Они просто не могут определить тип метаданных. Сложности при анализе страниц могут быть связаны с логическими ошибками на верхнем уровне JSON-документов, неверными значениями параметров, пустыми последовательностями и банальными опечатками, например, пропущенными ‘:’, ‘,’ ‘}’, ‘]’, и другие символы.

Поддержка Google

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

Search Console записывает результаты каждого теста Rich Results. Доступ к ним бесплатный, и вы можете еще раз проверить результаты в течение 90 дней, используя соответствующую вкладку. Вы также можете отправить результаты тестирования коллегам или клиентам с помощью кнопки «Поделиться».Подробнее читайте в статье Что такое консоль поиска Google и как используется этот инструмент?

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

Расширения-валидаторы для Google Chrome

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

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

Он поддерживает синтаксис микроданных, RDFa и JSON-LD. Он позволяет проверять сайты с открытым доступом, а также локальные страницы, защищенные паролем. Приложение выделяет ошибки и предупреждения разными цветами. Это дает возможность экспортировать результаты анализа.

SEO МЕТА В 1 КЛИК

Инструмент разметки Google Schema с расширенными функциональными возможностями для работы с HTML, CSS, Google Rich Snippet и PageSpeed.Он позволяет пользователям анализировать практически любые метаданные, полезные для SEO: структуру и иерархическую последовательность заголовков, описаний, URL-адресов (включая канонические), массу ссылок, изображения с ALT и без, файлы robots.txt и карту сайта.

Анализатор структурированных данных OpenLink

Он работает со словарями Microdata, RDFa, JSON-LD, Turtle и др. Помимо Google Chrome, OSDS поддерживается Mozilla Firefox и Opera (в будущем в список будет добавлен Safari).Он позволяет поделиться ссылкой на результаты тестирования, загрузить отчет в облачное хранилище или сохранить его на ПК.

Анализатор структурированных данных OpenLink

META SEO инспектор

Это расширение позволяет пользователям проверять, соответствует ли HTML-код сайта рекомендациям, изложенным в Руководстве Google для веб-мастеров. Если в разметке обнаруживаются ошибки (незаполненные поля, проблемы с синтаксисом, слишком длинный или слишком короткий текст), инспектор META SEO выводит предупреждение и предлагает способы улучшить ситуацию.Помимо анализа структурированных данных, этот плагин позволяет вам проверять настройки канонизации, запретных ссылок и другие свойства, которые влияют на работу сайта, но невидимы для пользователей. Отчет с ошибками и предупреждениями можно экспортировать, загрузить в формате PDF или распечатать.

META SEO инспектор

Вы можете найти больше полезных расширений в статье 50+ лучших бесплатных расширений для SEO для Chrome.

Как проверить свой код JSON-LD на Shopify с помощью инструмента проверки структурированных данных Google

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

Если ваши данные неверны, Google не сможет их прочитать, и вы потеряете все преимущества от их использования.

Это относится к большинству тем Shopify «из коробки». У них есть структурированные данные, но они устарели, неполны и иногда содержат ошибки или нарушают правила Google.

Содержание

Как проверить структурированные данные

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

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

Один совет достаточно важен, и я собираюсь его использовать:

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

1. Выберите свои страницы

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

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

Для каждой страницы ниже откройте новую вкладку или скопируйте полный URL-адрес в документ.

  • Ваша домашняя страница
  • Страница продукта, особенно с вариантами и отзывами
  • Сообщение в блоге (если вы их используете)
  • Любые другие специальные страницы, такие как рецепты приготовления, контакты с нами или сообщения в блоге с видео

2.Валидатор разметки схемы (инструмент тестирования структурированных данных)

После того, как вы собрали свои страницы, вы собираетесь использовать инструмент под названием Schema Markup Validator. Этот инструмент был первоначально создан Google и назывался «Инструмент проверки структурированных данных». В 2021 году Google подарил этот инструмент Schema.org, организации, которая определяет стандарты структурированных данных, которые распространяются на все основные поисковые системы.

По одному введите URL каждой собранной страницы.

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

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

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

3. Хороший отчет

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

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

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

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

4. Плохой отчет с ошибками

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

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

Ошибка в одном наборе данных не повлияет на другие наборы данных, поскольку каждый набор является отдельным. Это означает, что у вас могут быть ошибки в теме вашего Shopify, в то время как приложение, такое как JSON-LD для SEO, предоставляет второй набор безошибочных данных, которые собираются для Rich Results.

Исправление ошибок в JSON-LD может быть трудным и сложным в зависимости от ошибки. JSON-LD использует Schema.org, который, хотя и является хорошо документированным сайтом, в значительной степени является ресурсом документации по API для программистов.

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

Или вы можете сэкономить время и нервы и установить приложение Shopify, такое как JSON-LD для SEO.

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

Советы по тестированию

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

Предупреждения в данных в порядке

Вы можете увидеть предупреждения в своем отчете со структурированными данными. Они отображаются оранжевым цветом и содержат предупреждающее сообщение.

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

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

Предупреждения не повлияют отрицательно на вашу SEO-оптимизацию или результаты поиска.

Ошибки и предупреждения: есть ли проблема?

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

Google — компания, занимающаяся компьютерными науками. Термины «ошибки» и «предупреждения» исходят от инструментов информатики, называемых компиляторами.

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

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

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

Рекомендуется использовать поле aggregateRating. Если возможно, укажите значение.

Вот почему вам не нужно беспокоиться о предупреждениях.

В середине 2019 года Google добавил собственное определение предупреждений о структурированных данных:

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

Сводная информация о товаре Рейтинг по сравнению с полями обзора

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

Существует несколько способов использования набора структурированных данных о продукте.

Для магазинов Shopify используется как «это продукт, который продается в этом магазине».

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

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

В нем указано, сколько людей (клиентов) оставили отзывы и какую среднюю оценку они дали продукту.

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

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

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

Множественные дубликаты одного типа структурированных данных

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

Допускается наличие нескольких наборов данных.

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

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

JSON-LD для SEO использует специальные поля идентификатора, чтобы помочь изолировать данные и помочь вам отличить их от других приложений.Например, его набор данных о продукте заканчивается на # json-ld-for-seo . В этой статье есть полный список используемых идентификаторов.

Есть одно предостережение: в зависимости от данных вам может потребоваться удалить или обновить дубликаты, если вы используете Google Merchant Center. Но если вы не используете эту систему, вы можете игнорировать их.

Получите больше органического поискового трафика для своего магазина Shopify

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

Установите JSON-LD для SEO

Генератор разметки схемы и инструмент тестирования структурированных данных (включая JSON-LD)

Получайте расширенные описания, добавляя структурированные данные на свой сайт

Добавляя JSON-LD, который этот инструмент генерирует на ваши страницы, вы помогаете Google лучше понять их назначение. Упростите для Google понимание ключевых элементов вашей страницы, таких как цена продукта или дата мероприятия. В свою очередь, для получения дополнительной информации Google часто «улучшает» ваше объявление дополнительными функциями.Эти функции могут помочь вам выделиться в многолюдных результатах выдачи и повысить ваш органический CTR.

Куда мне поместить сгенерированный фрагмент JSON-LD?

Ваш фрагмент JSON может быть добавлен в любом месте HTML вашей страницы. Большинство редакторов, таких как HTML-редактор WordPress, имеют режим «Просмотр исходного кода», который позволяет вам напрямую редактировать HTML. Как правило, проще всего разместить фрагмент кода в том месте, где вы его найдете в будущем. Мне нравится помещать код в конце статьи, чтобы его было легко найти.

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


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

Разметка, которую предоставляет наш генератор, упрощает добавление структурированных данных на ваши страницы. Добавляя фрагмент JSON-LD в свой HTML-код, вы помогаете поисковым роботам, таким как Google, точно понимать, о чем ваша страница, включая основные детали, такие как вовлеченные люди, упомянутые организации и организации или другие элементы.

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

Как схема помогает вашему SEO?

Схема

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

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

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

Как проверить правильность структурированных данных

Чтобы убедиться, что ваши структурированные данные могут быть обработаны Google и другими роботами, вы всегда должны использовать инструмент тестирования. Мы предлагаем инструмент тестирования структурированных данных, который поддерживает JSON-LD, Microdata и RDFa, и тестируем на всех типах Schema.org, а не только на те, которые Google выделяет в своем тесте Rich Results.

  1. Чтобы использовать инструмент, просто введите свой URL-адрес или вставьте исходный HTML-код.
  2. Нажмите кнопку, и мы быстро проанализируем ваш контент.
  3. Проверьте результаты, чтобы увидеть, появляются ли ваши структурированные данные. Любые синтаксические ошибки или свойства, не соответствующие спецификациям на Schema.org, будут выделены.

Что на самом деле тестирует инструмент проверки структурированных данных?


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

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

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

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

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

Что такое совокупный рейтинг?

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

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

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

Микроданные

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

RDFa

RDFa или Структура описания ресурсов в атрибутах — это расширение HTML5, аналогичное Microdata. Однако, когда дело доходит до описания вашего контента для поисковых систем, он использует другой набор кодов по сравнению с микроданными. RDFa обычно используется как в заголовке, так и в основной части HTML-страницы.

JSON-LD

Данные, связанные с нотацией объектов JSON-LD или JavaScript — это нотация JavaScript, встроенная в тег

Этот сценарий можно разместить в любом месте раздела или вашего HTML.

Микроданные

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

 

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

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

RDFa

RDFa работает как микроданные. Вы размечаете HTML-элементы на странице, а не предоставляете разметку в одном большом блоке, таком как JSON-LD.Вероятно, это наименее используемый синтаксис схемы, но вы все равно будете время от времени сталкиваться с ним, потому что на нем основаны метатеги Facebook Open Graph.

Вот как та же разметка организации выглядит с использованием RFDa:

 

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

Итак, ничем особо не отличается от Microdata. Но как узнать, что все это верная разметка?

Тестирование структурированных данных

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

Вот что я получаю, когда тестирую фрагмент микроданных:

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

Перед тем, как вы начнете размечать свой контент

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

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

Структурированные данные за пределами вашего веб-сайта

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

Однако не думайте, что вам нужна страница Википедии только потому, что она часто используется в качестве источника для панелей знаний:

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

На самом деле, если у вас нет широкого освещения в СМИ Википедии и Викиданных, ваша панель знаний, вероятно, будет намного проще:

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

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

Заключительные мысли

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

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

Есть вопросы? Напишите мне в Twitter.

12 причин, по которым ваши расширенные сниппеты не отображаются.

Обычные результаты поиска Google состояли из 10 простых синих ссылок и небольшого описания для каждой.

Сегодня поисковая система Google намного более многофункциональна и сложна.

Функции поиска, такие как расширенные фрагменты и избранные фрагменты, отвлекают внимание пользователей Google от простых старых ссылок.

Как с этим бороться?

Убедившись, что на ваших сайтах есть расширенные описания веб-страниц.

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

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

SEO-специалисты могут работать с разработчиками над созданием хорошо структурированных данных на своих страницах.

Google, как и пользователи, любит расширенные описания веб-страниц, особенно в результатах поиска рецептов и продуктов.

Расширенные сниппеты содержат звездочки, разметку рецептов и многое другое.

Они привлекают внимание поисковиков и, как следствие, обычно имеют более высокий рейтинг кликов.

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

Объявление

Продолжить чтение ниже

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

Schema.org - это общий источник словаря, который вы можете использовать с RDFa, Microdata и JSON-LD, чтобы найти новые способы разметки ваших данных.

У Google есть собственные стандарты, основанные на спецификациях Schema.org.

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

Определенно стоит приложить усилия, чтобы выделиться из толпы.

Иногда, тем не менее, вы прикладываете все усилия для поиска релевантных структурированных данных.

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

Ваши сниппеты не обогащены, у вас просто старые голубые ссылки.

Почему?

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

Реклама

Продолжить чтение ниже

1. Расширенные сниппеты - не гарантия

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

Однако это не так.

Google оставляет за собой право отказать в обслуживании ваших структурированных данных.

Кроме того, Google поддерживает только определенные виды структурированных данных. Они не поддерживают все типы схем на schema.org, а расширенные описания доступны только для определенных типов схем.

Типы структурированных данных, поддерживаемые Google:

  • Статья
  • Книга
  • Хлебная крошка
  • Карусель
  • Курс
  • Анализ критиков
  • Набор данных
  • EmployerAggregateRating
  • Расчетная зарплата
  • Событие
  • FAQ
  • Домашняя деятельность
  • Практическое руководство
  • Лицензия на изображение
  • Публикация вакансий
  • Обучение работе
  • Местный бизнес
  • Логотип
  • Фильм
  • Подкаст
  • Продукт
  • Вопросы и ответы
  • Рецепт
  • Обзор фрагмента
  • Окно поиска дополнительных ссылок
  • Программное обеспечение (бета)
  • Speakable
  • Подписка и платный контент
  • Видео

2.Ваши структурированные данные не соответствуют стандартам качества

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

Некоторые стандарты качества, которые Google ожидает от разметки, включают:

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

Дополнительные из этих рекомендаций изложены ниже.

3. Ваши структурированные данные неактуальны или вводят в заблуждение

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

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

Помните, что схема описывает ваш контент для машины.

Есть ли способ, которым машина обнаружит несоответствие между вашей разметкой и вашими страницами?

4.Ваши данные разметки содержат ненормативную лексику

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

Не ругайтесь!

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

5. Разметка структурированных данных сделана неправильно

Это наиболее частая причина, по которой расширенные описания не отображаются на страницах в поисковой выдаче.

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

Реклама

Продолжить чтение ниже

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

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

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

Распространенная ошибка - это неправильное размещение элементов schema.org.

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

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

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

Распространенной ошибкой является преждевременное закрытие узлов HTML.

Еще одна распространенная ошибка при реализации разметки - незакрытые HTML-теги.

Объявление

Продолжить чтение ниже

Каждый тег HTML должен быть открыт, а также закрыт.

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

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

Каждая сущность должна быть выложена с использованием типа itemscope .

Однако для каждой области itemscope требуется один единственный aggregateRating itemprop .

Объявление

Продолжить чтение ниже

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

Кроме того, отсутствие aggregateRating itemprops также запутает Google, так как он будет предоставлять рейтинг только от одного человека, а не от всего коллектива.

6.Вы используете несколько языков разметки

Вы можете использовать словарь Schema.org с различными кодировками, такими как RDFa, Microdata и JSON-LD.

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

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

Это верно, даже если у вас есть два структурированных типа данных на одной странице.

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

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

Реклама

Продолжить чтение ниже

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

7. Вы используете организационную разметку на каждой странице.

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

Джон Мюллер из Google сказал, что не имеет значения, где используется разметка, если она не на каждой странице.

8. Google не считает ваш сайт надежным

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

Убедитесь, что ваш сайт обслуживается через HTTPS, и что вы встраиваете только HTTPS-контент на HTTPS-страницы.

9. У вас несовместимая разметка

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

Посмотрите на свои структурированные данные в режиме просмотра исходного кода и элемента проверки.

Объявление

Продолжить чтение ниже

Отличаются ли структурированные данные?

Могли ли JavaScript возникнуть ошибки или затруднения?

10.Ваш размеченный контент не виден пользователю

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

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

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

11. Google не видит, что ваш контент изменился.

. Важно, чтобы XML-карта сайта содержала атрибут , чтобы сообщить Google, что страницы необходимо переиндексировать.

Вы также можете заставить Google повторно сканировать страницу в инспекторе URL в Search Console.

12. Прошло мало времени

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

Даже в этом случае для отображения результатов расширенного описания веб-страниц может потребоваться больше времени.

Реклама

Продолжить чтение ниже

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

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

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

Эти инструменты включают:

  • Отчеты о состоянии с расширенными результатами.
  • Тест расширенных результатов : этот инструмент тестирования позволяет протестировать страницу или HTML-код, чтобы узнать, поддерживает ли страница расширенные результаты, каковы эти результаты и что нужно исправить в случае возникновения проблемы.
  • Data Highlighter : этот ресурс от Google помогает поисковой системе понимать и обрабатывать разметку, позволяя пользователю выделять и отмечать поля данных с помощью мыши.

Google ранее также поддерживал использование инструмента проверки структурированных данных.

Хотя этот инструмент все еще полезен, Google отказывается от его поддержки в пользу теста Rich Results.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *