JPEG XL и Google Images: как не потерять видимость изображений

Google Search поддерживает изображения в форматах BMP, GIF, JPEG, PNG, WebP, SVG и AVIF. JPEG XL, который обычно использует расширение .jxl, в официальном перечне Google Search не указан. Для SEO-команды это важнее, чем вопрос поддержки формата отдельным браузером: пользователь может увидеть картинку, а поисковая система — не обработать её как поддерживаемое изображение для Google Images, превью обычного результата или карточки Discover.

Проблема особенно вероятна после автоматической оптимизации медиа в CDN, headless CMS или сборщике сайта. Система может решить, что новый кодек экономит трафик, и заменить им исходник во всех точках: в img src, Open Graph, structured data и sitemap. Внешне страница останется исправной на части устройств, но поисковым системам будет передан URL формата, которого нет в их документированном списке.

Правильная реакция — не запрещать JPEG XL в инфраструктуре, а отделить клиентскую оптимизацию от индексируемого источника. Современный формат можно предлагать совместимым браузерам через <picture>, сохраняя поддерживаемый fallback в обычном <img src> и во всех SEO-сигналах.

В статье Что подтверждает Google Почему браузер и поиск видят страницу по-разному Как устроить безопасный fallback Какой URL передавать в schema и Open Graph Что проверить для Discover Как проверить уже выполненную миграцию Технический чек-лист Когда JPEG XL всё-таки уместен

Что именно подтверждает документация Google

В руководстве по SEO изображений Google перечисляет семь поддерживаемых форматов: BMP, GIF, JPEG, PNG, WebP, SVG и AVIF. Тот же список повторяется на странице индексируемых типов файлов. JPEG XL в нём отсутствует. Это не означает, что страница с таким ресурсом автоматически потеряет позиции, но означает более узкую вещь: не стоит использовать .jxl как единственный индексируемый URL изображения и ожидать от Google документированной обработки.

Google также объясняет, как обнаруживает медиа. Надёжный путь — обычный элемент <img> с адресом в атрибуте src. Изображение внутри <picture> допустимо, однако Google рекомендует всегда оставлять fallback в img src. CSS-фоны не индексируются как изображения. Поэтому визуальный hero, заданный только через background-image, не становится полноценной заменой содержательному <img> даже при корректном отображении.

Расширение файла желательно согласовать с фактическим типом. Если URL заканчивается на .jpg, а сервер отдаёт другой кодек, диагностика усложняется: браузер может разобраться по MIME, а краулер или внешний сервис — обработать ответ иначе. Для стабильной схемы формат, Content-Type, расширение и содержание файла должны совпадать.

Почему поддержка в браузере не равна поддержке в поиске

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

Из-за этого успешный визуальный тест в Chrome или Safari не доказывает готовность к Google Images. Он лишь подтверждает, что одна клиентская конфигурация смогла декодировать файл. Для SEO нужны дополнительные доказательства: поддерживаемый fallback, HTTP 200, доступность для Googlebot, постоянный URL, корректный MIME, ссылка из HTML и согласованные метаданные.

Особенно опасен тест только на одном устройстве. CDN может выполнять content negotiation по Accept и возвращать разные байты по одному адресу. Если кеш не разделён корректно через Vary, один клиент или робот способен получить версию, предназначенную другому. Проще и прозрачнее давать каждому формату отдельный URL и выбирать его через <picture>.

Как устроить безопасный fallback в HTML

Практическая схема начинается с наиболее нового варианта и заканчивается обычным img в формате, который Google документированно поддерживает:

<picture>
  <source type="image/jxl" srcset="/images/report-1600.jxl 1600w">
  <source type="image/avif" srcset="/images/report-1600.avif 1600w">
  <source type="image/webp" srcset="/images/report-1600.webp 1600w">
  <img
    src="/images/report-1600.jpg"
    srcset="/images/report-800.jpg 800w, /images/report-1600.jpg 1600w"
    sizes="(max-width: 800px) 100vw, 1200px"
    width="1600"
    height="900"
    alt="График видимости страниц в Google Images"
  >
</picture>

JPEG XL здесь остаётся улучшением для совместимых клиентов, а не единственной точкой входа. AVIF и WebP тоже необязательны: важен последний img src, который должен отвечать корректно без JavaScript и специальных заголовков браузера. Атрибуты width и height помогают зарезервировать место и уменьшить сдвиги макета, но не заменяют достаточное реальное разрешение файла.

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

Какой URL передавать в schema, Open Graph и sitemap

Google может выбирать предпочитаемое превью из нескольких источников. В документации названы og:image, свойство primaryImageOfPage, а также image у основной сущности, например Article или BlogPosting. Если эти сигналы ведут на разные файлы, выбор становится менее предсказуемым.

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

og:image;
BlogPosting.image или Article.image;
WebPage.primaryImageOfPage, если это свойство применяется;
image sitemap, если он нужен для обнаружения;
видимый <img src> либо один из индексируемых вариантов страницы.

Необязательно указывать все механизмы одновременно. Важнее, чтобы выбранный URL был постоянным, доступным без авторизации, не закрытым robots.txt и не требовал cookie или JavaScript для загрузки. CDN-домен можно использовать, но Google рекомендует подтвердить его в Search Console, чтобы видеть возможные ошибки сканирования.

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

Что отдельно проверить для Google Discover

Discover не требует специальной structured data, однако индексируемость страницы остаётся базовым условием. Google рекомендует релевантные изображения шириной не менее 1200 пикселей, разрешением более 300 000 пикселей, предпочтительно с удобным для ленты соотношением сторон 16:9. Для крупного превью нужен max-image-preview:large либо AMP.

Размер — не единственный критерий. Google советует избегать общего логотипа вместо иллюстрации материала, экстремального соотношения сторон и изображений, перегруженных текстом. Превью должно действительно представлять содержание страницы. В schema или og:image стоит передавать поддерживаемый формат, а не .jxl, даже если внутри <picture> JPEG XL используется как первый вариант.

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

Как проверить сайт, который уже перешёл на JPEG XL

Начните не с обратной массовой конвертации, а с инвентаризации. Сканер сайта должен собрать img src, srcset, <source>, og:image, JSON-LD и image sitemap. Отдельно выгрузите шаблоны CMS и правила CDN: один и тот же ошибочный генератор часто затрагивает тысячи страниц.

Разделите ситуации на три группы:

.jxl используется только как дополнительный <source>, а img src и метаданные ведут на JPEG, WebP или AVIF. Это обычно безопасная архитектура, если fallback отвечает 200.
.jxl стоит в img src, но есть поддерживаемый вариант только в source. Здесь порядок следует изменить: индексируемый fallback должен находиться в обычном img.
JPEG XL — единственный файл и одновременно адрес в Open Graph, schema и sitemap. Такой шаблон имеет наивысший приоритет исправления.

После изменений проверьте не только HTML, но и сетевой ответ без браузерных заголовков. Полезно запросить страницу и изображение обычным HTTP-клиентом, посмотреть код ответа, Content-Type, длину файла, кеширование и перенаправления. Затем убедитесь, что старый URL не остаётся одновременно в sitemap и structured data.

Технический чек-лист для SEO-команды

Для каждого важного шаблона достаточно пройти короткую последовательность:

в исходном HTML существует <img src> с поддерживаемым Google форматом;
основной файл отвечает HTTP 200 и декодируется;
Content-Type соответствует содержимому и расширению;
robots.txt не блокирует каталог изображений;
og:image, schema и image sitemap не ведут только на .jxl;
предпочитаемая картинка релевантна странице и имеет достаточное разрешение;
на мобильном и desktop нет неверного кадрирования или растяжения;
старые URL после миграции либо доступны, либо перенаправлены без цепочки;
CDN не смешивает форматы в одном кеше;
в Search Console и логах отслеживаются ошибки обхода и изменения показов.

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

Когда JPEG XL уместен, а когда лучше выбрать другой формат

JPEG XL можно оставить как дополнительный вариант доставки, если он даёт измеримую экономию, поддерживается целевой аудиторией и не заменяет индексируемый fallback. Такой подход позволяет экспериментировать с производительностью без зависимости SEO от одного нового кодека.

Если команда не готова поддерживать несколько производных файлов, проще выбрать WebP, AVIF или качественно сжатый JPEG — в зависимости от типа изображения и совместимости проекта. Формат не должен оцениваться отдельно от визуального качества, скорости декодирования, стоимости генерации, кеша и стабильности URL.

Главный вывод: SEO-риск создаёт не само наличие .jxl, а ситуация, когда он становится единственным адресом, который получают Google и внешние сервисы. Сохраните поддерживаемый img src, согласуйте метаданные и проверяйте реальные ответы сервера.

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