Google Images и Discover пока не поддерживают JPEG XL для превью
Google Images и Discover пока не используют JPEG XL для изображений и превью, несмотря на поддержку формата в Chrome и Firefox. Для поиска стоит оставить резервный файл в поддерживаемом формате.
Google Images и Discover пока не поддерживают JPEG XL для показа изображений и превью, сообщил представитель Google Search Джон Мюллер 15 октября 2026 года. Как пишет Search Engine Journal, разъяснение появилось вскоре после добавления формата в Chrome и Firefox. Для сайта это существенная разница: браузер может открыть .jxl, но этого недостаточно, чтобы рассчитывать на показ файла в поиске изображений или рекомендациях Google.
Браузеры уже принимают формат, поиск — пока нет
JPEG XL появился в Chrome 155, широкое распространение которого Google начал 6 октября после ограниченного выпуска с 23 сентября. Firefox добавил поддержку в версии 158 от 13 октября, Safari — ещё в версии 17 в 2023 году. При этом webstatus.dev оценивает доступность формата как ограниченную; выпуск Edge с его поддержкой в этом трекере не указан.
По оценке команды Chrome, JPEG XL обеспечивает сжатие на 30–50% лучше JPEG, поддерживает сжатие без потерь и HDR. Разработчики советуют тестировать его наряду с AVIF и считают особенно полезным для фотографий, где важны высокая точность изображения или сжатие без потерь. Но возможности формата и поддержка браузеров не означают, что Google использует файлы .jxl для превью.
В документации Google Search перечислены форматы, которые поиск поддерживает в атрибуте src элемента img: BMP, GIF, JPEG, PNG, WebP, SVG и AVIF. JPEG XL среди них нет. Та же семёрка приведена в списке индексируемых типов изображений. По состоянию на 20 октября в журнале изменений документации Search Central не было сообщения о добавлении JPEG XL.
Как сохранить изображения для поиска и Discover
Мюллер пояснил, что JPEG XL можно предлагать браузеру через элемент picture, оставив внутри обычный img. Тогда .jxl будет одним из источников изображения, а в src элемента img можно указать файл формата, который поддерживает Google, например JPEG, WebP или AVIF. По словам Мюллера, схема должна работать для поисковых систем: они могут прочитать img.
Это согласуется с документацией Google: поиск способен найти изображение по src элемента img, даже если тот находится внутри picture. Google советует оставлять резервный адрес в src, поскольку некоторые браузеры и поисковые роботы не поддерживают picture или srcset либо не могут их прочитать. Так новый формат можно испытывать, не превращая его в единственный доступный вариант изображения.
У Discover есть отдельные рекомендации для крупных изображений в превью. Адрес можно указать через разметку schema.org или метатег og:image; эти данные могут влиять на выбор превью в Discover. Если ссылки ведут на .jxl, резервный img на странице сам по себе их не заменит. Для таких адресов разумно выбирать формат из списка, приведённого в документации поиска.
Сроков появления поддержки JPEG XL в Google Images и Discover Мюллер не назвал. История AVIF показывает, что браузер и поиск могут получить поддержку с большим интервалом: Chrome добавил AVIF в августе 2020 года, а Google объявил о его поддержке в Search 30 августа 2024 года. Это не прогноз для JPEG XL, а причина следить за документацией поиска отдельно от выпусков браузеров.
Что это значит для владельцев сайтов
Если сайт рассчитывает на Google Images или превью в Discover, переводить весь каталог только в .jxl пока преждевременно. Проверка того, как фотографии выглядят в Chrome и Firefox, не отвечает на вопрос, какое изображение сможет использовать Google. При внедрении нового формата важно оценивать и страницу, и адреса изображений, передаваемые для превью.
Для магазина это не отвлечённая техническая разница. Покупатель может впервые увидеть фотографию товара до перехода на сайт, а затем сравнить её с другими предложениями. Поэтому решение о формате стоит принимать с учётом не только качества и размера файла, но и каналов, в которых магазин хочет показывать свои товары.
Моё мнение: не стоит делать формат единственной ставкой
Я переношу каталог магазина товаров для дома из таблиц в CMS, поэтому воспринимаю эту новость как вопрос устройства каталога, а не только скорости загрузки. Мне интересно попробовать JPEG XL для фотографий: когда покупатель сравнивает небольшие предметы, детали важны. Но я бы не хотел, чтобы команда загрузила новый формат для всего ассортимента, а затем обнаружила, что для нужных нам превью не осталось подходящих изображений.
Я бы заложил резервный формат в процесс работы с фотографиями сразу. Тогда можно пробовать новое, не связывая видимость товаров с одним техническим решением. Поиск не исчезает: меняются способы, которыми человек впервые встречает товар и получает ответ. Для небольшого магазина возможность спокойно тестировать формат и сохранять привычные каналы важнее, чем одно лишь обещание более сильного сжатия.
Источники
Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.
- Google Images & Discover Previews Don’t Support JPEG XL via @sejournal, @MattGSouthern www.searchenginejournal.com
- JPEG XL Image Format Not Supported By Google Images & Google Discover www.seroundtable.com
владелец магазина товаров для дома
Развиваю на Кипре магазин небольших предметов для дома и наконец переношу каталог из таблиц в нормальную CMS. Хочу связать контент, поиск и продажи так, чтобы команда могла запускать идеи без недель ожидания разработчика.
Все публикации автораПохожие статьи
Chrome добавляет поддержку JPEG XL начиная с версии 155
Начиная с Chrome 155 браузер сможет открывать изображения JPEG XL. Владельцам сайтов рекомендуют сравнить формат с AVIF и учесть поддержку браузеров перед сменой формата файлов.
Вышел Microsoft Edge 155 с поддержкой декодирования JPEG XL
Microsoft выпустила Edge 155 для Windows, macOS и Linux. Браузер получил поддержку декодирования JPEG XL, а обработчики unload теперь не запускаются по умолчанию.
Google добавил совет по индексации страниц для обмена ссылками в руководство по спаму
Google обновил руководство по спаму и объяснил, как управлять индексацией страниц для обмена ссылками, совместной работы и онлайн-инструментов. Если страницу не должны находить через поиск, рекомендуется применять noindex.
Обсуждение 4
Азмат Токтосунов
Добавлю практический нюанс: если отдаёте JXL через <picture>, проверьте, какой URL бот Googlebot получает в HTML, а не только то, что видит браузер. Для изображений, на которые завязаны карточки товара и органический трафик, я бы пока оставил обычный JPEG или WebP доступным без зависимости от выбора формата на стороне клиента.
Дарья Фальк
@azamat.seo, особенно важно проверить это на карточках: у нас изображения товара обновляются силами команды, и лишняя зависимость от выбора формата легко превращается в незаметную проблему с трафиком. Пока оставлю JPEG или WebP основным вариантом, а JXL — только дополнительным.
Ольга Линде
@azamat.seo, а как вы проверяете, какой URL в итоге доступен Googlebot, если в разметке <picture> первым указан JXL, а JPEG или WebP — только в качестве fallback? Не уверен, что по тому, что показывает браузер, можно понять, какой файл получит поисковый робот.
Костас Марку Автор публикации
@olga.linde, в DevTools можно включить эмуляцию Googlebot и посмотреть Network: там будет видно, какие запросы уходят при загрузке страницы. Но для <picture> важнее проверить сам HTML и логику выбора источника: если JXL стоит первым, бот может увидеть этот URL, даже если не умеет обработать формат. Для важных товарных фото я бы не полагался на догадки по браузеру — оставил бы JPEG/WebP отдельным доступным URL и проверил страницу через инструменты проверки Google; это дешевле, чем потом разбираться с просевшими превью 🙂