Размер изображения Open Graph: один файл для всех платформ

Одно изображение размером 1200 на 630 пикселей, в PNG или JPEG, весом менее примерно 1 МБ, с важным содержимым внутри центральной области 1080 на 600. Этот файл корректно отображается на Facebook, LinkedIn, X, в Slack, Discord, WhatsApp и iMessage - и это весь ответ на вопрос о размере изображения Open Graph почти для любого сайта.

Размеры - это самая простая часть. Обычно ломается не она. Ломается текст, который стоит слишком близко к краю, обрезаемому одной из платформ, изображение, которое никогда не обновляется, потому что краулер закешировал старую версию месяцы назад, или карточка, которая отрисовывается вообще без картинки, потому что файл весил 4 МБ на медленном источнике. Вопрос о размере OG-изображения на самом деле состоит из трёх вопросов, и только один из них про пиксели. Это руководство рассматривает технические требования, безопасную зону, поведение кеширования, из-за которого людям кажется, что их теги неверны, и то, как разрешаются превью, когда предметом публикации становится короткая ссылка. Если ваше превью отсутствует полностью, а не просто плохо обрезано, превью ссылки не отображается - это руководство по диагностике.

Размер, и почему именно такой

Соотношение 1.91:1 пришло из карточки ссылок Facebook и закрепилось, потому что все остальные приняли совместимый макет вместо того, чтобы изобретать свой. Сам протокол Open Graph вообще ничего не говорит о пикселях; он определяет og:image как URL и оставляет отрисовку на усмотрение потребителя - именно поэтому вокруг одного удобного размера сложился фактический стандарт.

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

Безопасная зона, о которой никто не упоминает

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

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

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

Теги вокруг изображения

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

<meta property="og:image" content="https://example.com/og/spring-launch.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta
  property="og:image:alt"
  content="Spring launch: 30 percent off through May"
/>
<meta name="twitter:card" content="summary_large_image" />

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

Почему ваше новое изображение не отображается

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

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

• Принудите повторное сканирование с помощью собственного инструмента платформы: Facebook Sharing Debugger и LinkedIn Post Inspector получают страницу заново по запросу.
• Опубликуйте изображение под новым именем файла - это другой URL, а значит, для него вообще нет записи в кеше. Это самый надёжный способ.
• Измените сам URL, которым делитесь, - это тривиально просто, когда вы делитесь короткой ссылкой, которую контролируете, а не постоянным адресом страницы.

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

Превью, когда вы делитесь короткой ссылкой

У короткой ссылки нет собственных тегов Open Graph, и они ей не нужны. Краулер следует по перенаправлению, попадает на страницу назначения и строит карточку из тегов там - это значит, что сокращённый URL наследует то превью, которое есть у целевой страницы. Если карточка неверна, значит неверны теги на странице назначения.

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

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

Чеклист, который стоит сохранить

• 1200 на 630, PNG или JPEG, менее 1 МБ, абсолютный HTTPS URL. Это и есть всё решение по размеру OG-изображения.
• Ничего важного за пределами центральной области 1080 на 600, никаких тонких рамок.
• og:image:width, og:image:height и og:image:alt присутствуют.
• twitter:card со значением summary_large_image, если хотите большую карточку на X.
• Новое изображение, новое имя файла, затем повторное сканирование - прежде чем что-либо анонсировать.

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

Читайте серию опорных статей

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

Другие материалы в блоге

• Превью ссылки не отображается? Причины и способы исправления
• Как сократить ссылку для X (Twitter): что делает с ней t.co
• Как отслеживать ссылки в социальных сетях: переходы по каналам
• Что такое брендированная ссылка и почему она лучше конвертирует
• Как перенаправить URL: шесть способов и когда какой уместен
• Короткие ссылки на собственном домене: DNS, TLS и edge