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

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

Когда речь заходит о внедрении структурированных данных, многие команды в первую очередь думают о выборе типа Schema, написании JSON-LD и запуске инструментов проверки. Однако на практике проблемы чаще всего возникают не с тем, «как написать», а с тем, «для кого это написано». Если типы страниц определены неправильно, границы контента нестабильны, а источники данных для полей различаются, даже корректная разметка впоследствии может оказаться бесполезной. Особенно это актуально для проектов, объединяющих разработку сайтов и маркетинговые услуги: страницы одновременно должны обеспечивать индексацию и конверсию, а шаблоны, языковые версии, посадочные страницы рекламных кампаний и страницы блога часто работают в одной системе. Если заранее не провести инвентаризацию страниц, внедрение структурированных данных легко превращается в хаотичный процесс.

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

Не спешите внедрять: сначала разделите типы страниц на «подходящие» и «сложные» для разметки

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

На практике рекомендуется сначала разделить страницы на три категории:

• страницы с чёткими границами контента и фиксированными основными полями, например страницы подробного описания товаров и отдельные страницы статей;
• страницы-агрегаторы информации, например страницы категорий, результаты поиска и тематические страницы;
• страницы бренда и функциональные страницы, например главная страница, страницы «О компании», контактов и формы.

Первая категория обычно лучше всего подходит для первоочередного внедрения. Вторая также может быть реализована, но необходимо оценить стабильность логики агрегации. Третью категорию часто переоценивают: многие команды сразу стремятся сделать главную страницу максимально «полной», добавляя на неё Organization, WebSite, Breadcrumb, FAQ, Product и даже Review. Внешне такая страница выглядит насыщенной, однако фактически между её смысловыми элементами может возникать немало конфликтов.

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

Если на сайте есть стандартные страницы подробного описания товаров, именно их следует рассматривать в первую очередь при внедрении структурированных данных. Причина проста: страницы товаров обычно имеют чёткую тематику и достаточно полный набор атрибутов, включая название, изображения, описание, бренд, модель, SKU, цену и статус наличия. Проблема заключается в том, что на многих B2B-сайтах эти поля представлены не полностью.

На сайтах внешнеторговых производственных компаний часто встречается ситуация, когда страница называется «страницей товара», но фактически больше похожа на страницу презентации возможностей. На ней есть только несколько изображений, описание сценария применения и кнопка отправки запроса — без цены, информации о наличии и разделения по конкретным моделям. Разметку в направлении Product для такой страницы использовать можно, но необходимо соблюдать осторожность и не добавлять сведения, которых нет на сайте. Особенно это касается цены, рейтинга и отзывов: если они чётко не отображаются на странице, не рекомендуется заполнять эти поля только ради формальной «полноты».

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

Именно поэтому современные комплексные платформы для создания сайтов и маркетинга связывают поля товаров, поля шаблонов и разметку на внешней части сайта. Для таких платформ, как 易营宝, которые длительное время обслуживают многоязычные корпоративные сайты, B2B-сайты внешнеторговых компаний и трансграничные интернет-магазины, настоящая сложность заключается не в том, поддерживается ли Schema, а в том, можно ли связать данные товаров в панели управления, языковые версии, шаблоны страниц и правила поисковой видимости. При технической оценке рекомендуется сделать проверку «единственности источника полей» обязательным пунктом.

Страницы статей: выглядят простыми, но фактически требуют более продуманной контентной системы

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

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

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

Главную страницу можно размечать, но не следует превращать её в «универсальный контейнер»

Главная страница подходит для размещения информации о бренде и сайте в целом, например разметки Organization или WebSite, но только при условии, что она действительно выполняет роль главной точки входа в бренд. Для сайтов, ориентированных на рекламные кампании или мероприятия, главная страница может быть лишь временной агрегирующей страницей: сегодня она посвящена интернет-магазину, а завтра — специальной подборке новинок. В таких случаях стабильность её полей часто ниже, чем у страницы презентации бренда.

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

Для компаний, занимающихся зарубежным маркетингом, это особенно важно. Недостаточно, чтобы сайт просто «открывался» и «содержал код»: страницы бренда, главная страница, посадочная страница и страница товара выполняют разные роли в поисковой системе. Такие платформы, как 易营宝, одновременно охватывающие создание сайтов, SEO, размещение рекламы и управление многоязычным контентом, лучше подходят для системного управления структурированными данными не из-за большого количества модулей, а потому, что позволяют разделить задачи разных типов страниц и не использовать один шаблон для всех сценариев.

Страницы категорий и агрегаторы: тип, который чаще всего переоценивают

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

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

При технической оценке нужно спрашивать не «поддерживается ли это», а «как это будет поддерживаться»

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

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

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

Некоторые страницы лучше внедрить позже, чем сразу разметить неправильно

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

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

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