Успешная проверка разметки Schema не означает, что она соответствует видимому содержимому страницы. В этой статье рассматриваются сопоставление полей и проверка отображения, а также основные моменты проверки структурированного контента, которые помогут техническим специалистам выявлять некорректную разметку, пропущенные данные и несвоевременное обновление сведений.
Чтобы определить, соответствует ли разметка странице, нужно убедиться, что описываемые в ней объект, атрибуты и состояние имеют фактическое подтверждение на текущей странице. При проверке необходимо сверять смысл полей, результат отображения в браузере и цепочку обновления данных, а не только смотреть, сообщает ли инструмент проверки об ошибках.
Сначала определите критерии приемки: что нужно проверить помимо успешного результата инструмента?
При технической оценке следует различать три уровня: корректно ли разбирается код, соответствует ли он требованиям целевой поисковой функции и достоверно ли отражает содержимое страницы. Первые два можно проверить с помощью инструментов, а третий требует подтверждения на самой странице — одной лишь зеленой отметки об успешной проверке недостаточно.
Соответствие не означает, что весь текст должен совпадать дословно. Например, если на странице указано «в наличии», а в разметке используется соответствующее значение перечисления наличия, смысл может быть одинаковым. Но если на странице предлагается «запросить цену», а в разметке указана конкретная цена, которая не опубликована, подтвердить ее будет нечем.
При этом не каждое поле должно отображаться в основном тексте. Например, идентификатор сущности, канонический URL и адрес изображения могут использоваться для технической связи. В первую очередь нужно сверять факты, влияющие на понимание пользователей, и учитывать требования спецификации для соответствующего типа.
Для выборочной проверки сначала выбирайте ключевые шаблоны, например страницы с описанием товаров, статей и компании, а затем проверяйте страницы на разных языках, страницы с акциями, отсутствующими товарами и вариантами продуктов. В записи о проверке указывайте URL, время, условия доступа и проблемные поля — так будет проще воспроизвести проблему и принять исправление.
Составьте карту полей, чтобы каждое утверждение имело подтверждение на странице
Сначала составьте перечень структурированных данных на странице, указав тип сущности, путь к полю, его значение и соответствующее видимое место. На одной странице могут одновременно присутствовать сущности компании, товара и навигационной цепочки — сначала нужно определить, что именно описывает каждая из них.
На странице товара прежде всего проверяйте название, модель, бренд, цену, валюту, наличие и рейтинг; на странице статьи — заголовок, автора и даты; на странице о компании — ее название, контактные данные и адрес. Приоритет полей следует определять с учетом их влияния на бизнес.
Для каждого важного поля фиксируйте «значение в разметке, значение на странице, правило преобразования, результат проверки». Например, если на странице указана цена с учетом налога, структурированные данные должны точно соответствовать этому предложению. Нельзя подставлять цену без налога из внутренней системы и объяснять расхождение лишь различием форматов.
Компаниям, занимающимся внешней торговлей и производством, особенно важно различать товары и услуги. Условия сделки для описания оборудования, услуги по индивидуальной обработке и товара, доступного для прямой покупки, различаются. Сначала определите, что является основным объектом страницы, а затем выберите подходящий тип. Не добавляйте цену только ради улучшения отображения.
Проверяйте результат отображения, а не только исходный код страницы
Во время проверки изучайте и исходный код, полученный от сервера, и страницу после отображения в браузере. Некоторые сайты добавляют разметку с помощью скриптов, а цена или наличие могут обновляться после загрузки страницы. Проверка только на одном этапе может не выявить устаревшие данные или дублирование.
Найдите скрипты структурированных данных с помощью инструментов разработчика браузера и проверьте, не описывают ли несколько модулей один и тот же товар. Тема оформления, плагины и маркетинговые компоненты могут каждый генерировать собственный блок данных. Если цена или название расходятся, выясните источник данных для каждого блока.
Для товаров, данные о которых меняются только после выбора характеристик, отдельно проверьте состояние по умолчанию и ключевые варианты. Модель, изображение, цена и наличие должны относиться к одному и тому же объекту. Если для варианта товара предусмотрен отдельный URL, проверьте также, что при переходе по нему восстанавливается правильное состояние.
Содержимое в раскрывающихся блоках или вкладках не следует автоматически считать невидимым — главное, может ли пользователь получить к нему доступ. Напротив, маркетинговые утверждения, присутствующие только во внутренней системе, переменных скрипта или скрытых элементах, нельзя считать подтверждением того, что этот факт показан на странице.
В первую очередь проверяйте расхождения в ценах, рейтингах и версиях страниц на разных языках
Цены и наличие следует проверять в первую очередь, поскольку они напрямую влияют на решение о покупке. Обратите особое внимание на случаи, когда после завершения акции сохраняется цена со скидкой, товар помечен как доступный после того, как закончился, или при смене региона на странице меняется валюта, а структурированные данные не обновляются.
Для рейтинга нужно проверять, к какому объекту он относится, диапазон оценок, количество отзывов и отображение на странице. Нельзя переносить общий рейтинг компании на отдельный товар или представлять внутреннюю статистику, которая не опубликована, как рейтинг, отображаемый на странице. Для соответствующих функций поиска также предусмотрены отдельные правила применимости.
Страницы на разных языках необходимо проверять по отдельности — одной проверки основной версии сайта недостаточно. Распространенные проблемы: на переведенной странице сохранен старый заголовок, местные контактные данные не обновлены, а для цен на разных рынках используются одни и те же данные. Название бренда может оставаться одинаковым, но фактическая информация должна соответствовать каждой версии.
Даты статей также часто указываются неверно. Даты публикации и изменения должны иметь реальные основания; развертывание шаблона или обновление кэша не должны автоматически считаться обновлением содержимого. Информация об авторе также должна соответствовать фактической подписи — не следует по умолчанию указывать одного и того же не связанного со статьями автора.
Как объединить инструменты и выстроить воспроизводимый процесс проверки?
Сначала проверьте синтаксис и типы с помощью инструмента проверки структурированных данных, затем используйте тест расширенных результатов Google, чтобы проверить поддерживаемые им функции поиска. Эти инструменты охватывают разные аспекты; отсутствие расширенного результата определенного типа не означает, что сам тип недействителен.
Затем вручную проверьте подтверждения на странице в браузере и, если у вас есть необходимые права доступа к сайту, используйте инструмент проверки URL, чтобы посмотреть страницу, полученную или отрисованную поисковой системой. Записывайте время и условия доступа, чтобы не сравнивать результаты для разных регионов или состояний страницы.
Для массовой проверки можно извлечь ключевые поля и настроить правила сравнения с видимыми элементами той же страницы. Для цен необходимо унифицировать десятичные разделители и разделители разрядов, а для наличия — сопоставить значения по смыслу. Динамическое переключение, персонализированное отображение и сложные варианты товаров по-прежнему требуют выборочной проверки вручную.
В записи о проблеме указывайте конкретное место, которое нужно исправить, например привязку полей в шаблоне, дублирующую генерацию плагином или механизм сброса кэша. После исправления повторно получите затронутые URL и проверьте другие страницы, использующие тот же шаблон, чтобы убедиться, что проблема не затронула аналогичные страницы.
Включите проверку соответствия в приемку сайта и его регулярное обслуживание
При приемке распределите проблемы по степени влияния. Ошибки в описании объекта, недостоверные рейтинги и неверные цены следует устранять в первую очередь; необходимость исправления отсутствующих полей нужно оценивать с учетом требований к соответствующему типу. Не следует смешивать «заполнены не все рекомендуемые поля» и «поля содержат недостоверные сведения».
В проектах, объединяющих создание сайтов и маркетинговые услуги, включая зарубежные сайты, созданные на таких платформах, как 易营宝, при оценке важно проверить, используют ли контент и разметка надежный общий источник данных и предусмотрена ли синхронизация после публикации на разных языках и изменения акций.
Оптимизация структурированного контента будет эффективной, если фактические сведения на странице, разметка Schema и процесс обновления согласованы. Включение в приемку сопоставления ключевых полей, проверки отображения и регрессионного тестирования шаблонов поможет постоянно снижать риск недостоверной информации. Однако успешная проверка не гарантирует отображение расширенных результатов в поисковой системе.
