Проверка микроразметки Open Graph: как сайт выглядит в соцсетях и мессенджерах
Когда пользователь отправляет ссылку в социальной сети или мессенджере, платформа обычно формирует карточку: заголовок, описание, изображение и адрес страницы. Источником этих данных часто служат метатеги Open Graph. Если они отсутствуют, противоречат друг другу или недоступны роботу платформы, превью может оказаться пустым, устаревшим либо содержать случайный фрагмент страницы.
Проверка микроразметки open graph нужна не для управления поисковым сниппетом, а для диагностики карточки ссылки при репосте. Это отдельная задача: обычные HTML-элементы title, meta name="description" и заголовок h1 относятся к базовой проверке страницы, тогда как здесь рассматриваются именно свойства og:* и доступность связанных с ними ресурсов.
Как формируется превью ссылки
После публикации URL платформа обращается к странице своим роботом, получает HTML и ищет метатеги в секции <head>. Базовый набор Open Graph выглядит так:
<meta property="og:type" content="website">
<meta property="og:title" content="Название страницы">
<meta property="og:description" content="Краткое описание">
<meta property="og:url" content="https://example.ru/page/">
<meta property="og:image" content="https://example.ru/images/preview.jpg">Платформа может учитывать собственные правила, дополнительные теги и сохранённую ранее копию. Поэтому корректный HTML повышает предсказуемость результата, но не гарантирует полностью одинаковую карточку во всех сервисах. Один мессенджер обрежет длинный заголовок, другой изменит пропорции изображения, а третий временно покажет версию из кеша.
Диагностический алгоритм
1. Проверить публичную доступность URL
Начните с того адреса, который пользователи действительно будут отправлять. Он должен открываться без авторизации, CAPTCHA, обязательных cookie и выполнения действий в интерфейсе. Проверьте итоговый код ответа и цепочку перенаправлений. Если URL возвращает ошибку, зацикливает редиректы или доступен только браузеру с активным JavaScript, робот социальной платформы может не получить исходный HTML.
Важно смотреть именно первоначальный ответ сервера. Если og-теги добавляются только клиентским JavaScript после загрузки страницы, часть роботов их не увидит. Надёжнее отдавать метаданные в готовом HTML.
2. Найти теги Open Graph в head
Откройте исходный код ответа и найдите атрибуты property="og:...". Не ограничивайтесь инспектором DOM: он может показывать элементы, добавленные скриптом уже после загрузки. У каждого основного свойства должно быть непустое значение content. Дубли с разным содержимым создают неоднозначность: платформы не обязаны выбирать один и тот же вариант.
3. Сопоставить значения с проверяемой страницей
og:title и og:description должны описывать конкретный материал, товар или раздел, а не весь сайт. og:url должен указывать на канонический публичный адрес этой страницы. Несоответствие особенно часто возникает в шаблонах, где всем URL назначены заголовок и картинка главной страницы.
4. Проверить изображение отдельно
Скопируйте значение og:image и откройте его как самостоятельный URL. Предпочтителен абсолютный HTTPS-адрес. Сервер должен возвращать само изображение с успешным HTTP-ответом и подходящим Content-Type, например image/jpeg или image/png. Страница ошибки, HTML-заглушка, запрет по User-Agent и защита от внешней загрузки мешают построению карточки.
У изображения должен быть понятный главный объект и безопасные поля по краям: интерфейс платформы может обрезать кадр. Для дополнительного описания ресурса применяют og:image:width, og:image:height, og:image:type и og:image:alt. Эти свойства не исправят недоступный файл, но уменьшают неопределённость при обработке.
5. Сравнить результат в отладчиках платформ
Финальная проверка выполняется инструментом предпросмотра конкретной социальной сети или тестовой отправкой ссылки в нужный мессенджер. Если карточка осталась прежней после исправления HTML, вероятная причина — кеш. Отладчик платформы иногда позволяет запросить страницу повторно. Добавление случайных параметров к рабочему URL стоит использовать осторожно: такой адрес может стать отдельным объектом кеширования и не отражать поведение исходной ссылки.
Что проверять в og-тегах
| Критерий | Корректный результат | Риск при ошибке |
|---|---|---|
og:title |
Непустой и соответствует содержанию URL | Нерелевантный или отсутствующий заголовок |
og:description |
Кратко объясняет содержание без служебного текста | Пустое, обрезанное или случайное описание |
og:url |
Абсолютный адрес текущей канонической страницы | Карточка связывается с другим URL |
og:image |
Абсолютный URL доступного изображения | Нет картинки или выбрана другая иллюстрация |
og:type |
Тип согласован с сущностью, например website или article |
Платформа неверно интерпретирует объект |
| Дубли | Нет конфликтующих значений одного свойства | Непредсказуемый выбор метаданных |
| HTTP-доступность | Страница и изображение доступны роботам без авторизации | Превью не создаётся или не обновляется |
Типовые ошибки и способы локализации
- Одинаковые карточки у всех страниц. Проверьте шаблон генерации: значения могли быть жёстко заданы на уровне сайта или кешироваться без учёта URL.
- В исходном HTML тегов нет, но в инспекторе они видны. Метаданные добавляет JavaScript. Перенесите их формирование на серверную сторону или в этап статической генерации.
- Изображение открывается в браузере, но отсутствует в превью. Сравните ответы для разных User-Agent, проверьте редиректы, сертификат, тип содержимого и правила защиты от хотлинков.
- Показывается старая карточка. Сначала убедитесь, что сервер уже отдаёт новые значения, затем инициируйте повторное сканирование через официальный отладчик платформы.
og:urlведёт на главную. Исправьте генерацию адреса для внутренних страниц и проверьте согласованность с canonical.- В HTML несколько
og:image. Это может быть допустимо, но порядок и обработка зависят от платформы. Если нужен однозначный результат, первой укажите основную доступную иллюстрацию и проверьте фактическое превью. - Текст отображается с HTML-кодом или шаблонными переменными. Проверьте экранирование символов и то, что значения подставлены до отправки ответа.
Границы автоматической проверки
Анализ публичного HTML позволяет обнаружить отсутствие тегов, пустые значения, подозрительные дубли, некорректные URL и проблемы доступности. Однако он не воспроизводит все внутренние правила социальных сетей. Платформа может учитывать размер файла, собственные ограничения форматов, историю сканирования, региональные настройки и кеш.
Также Open Graph не заменяет другие механизмы. Он не определяет заголовок страницы в поисковой выдаче, не исправляет содержание самой страницы и не гарантирует выбор указанного изображения. Визуальная проверка карточки в целевых каналах остаётся обязательным завершающим шагом.
Практический итог
Надёжная проверка состоит из трёх уровней: получить исходный HTML публичного URL, проверить согласованность и доступность значений og:*, затем сравнить карточку в инструментах нужных платформ. Такой порядок помогает отделить ошибку шаблона сайта от блокировки ресурса и от устаревшего кеша социальной сети.
Для первичной диагностики можно запустить бесплатную проверку SiteVisor. Сервис анализирует публичный URL без доступа к CMS и помогает оценить технические, SEO/GEO и конверсионные сигналы страницы. Дополнительные практические материалы по диагностике сайтов собраны в блоге SiteVisor.