Оптимизация изображений для SEO: alt, размеры и вес под Core Web Vitals

Оптимизация изображений для SEO — это три простых вещи: осмысленный alt (для поиска по картинкам и доступности), заданные width и height (чтобы страница не «прыгала» при загрузке и не проваливала CLS) и лёгкий вес в современном формате (WebP или AVIF). Всё это влияет и на ранжирование, и на Core Web Vitals, и стоит недорого — если знать, что делать.

Картинки почти всегда самая тяжёлая часть страницы, и при этом про них забывают в первую очередь. На аудитах интернет-магазинов мы регулярно видим одно и то же: сотни товарных фото разом без alt и без размеров. Google такую страницу индексирует, но недобирает контекст, а пользователь видит, как вёрстка дёргается, пока грузятся изображения. Разберу по порядку, что проверяет аудит и как это чинить.

Зачем нужен alt и как его писать

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

«Более 53% главных страниц в мире имеют критические проблемы с отсутствием или некорректным alt. И самое смешное — 45% картинок без alt одновременно являются кликабельными ссылками: для незрячего человека такая ссылка звучит как набор букв, и он не понимает, куда она ведёт».

— Николай Шмичков, подкаст SEOquick про alt-теги

А вот угол, который в 2026-м важнее прежнего. Alt придумали для незрячих людей — но теперь у него появился второй слепой читатель:

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

То есть пустой alt — это не только барьер для человека со скринридером, но и молчание для ChatGPT, Perplexity и Google AI, которые пытаются понять, о чём ваша страница. Как это связано с попаданием в AI-ответы, мы разбирали в гайде по GEO-оптимизации под GPT.

Хороший alt описывает, что на картинке, конкретно и без воды. Формула у Николая простая:

«Идеальный alt отвечает на простой вопрос: как бы я описал эту картинку другу по телефону, чтобы передать её суть? Не "фотография чашки кофе на столе", а "дымящаяся чашка кофе на деревянном столе рядом с открытым блокнотом" — вы даже это уже визуализировали в голове».

Не «изображение», не «фото1234.jpg», не простыня из десяти ключей. Сравните:

Ещё несколько правил из подкаста, которые стоит держать в голове. Уложитесь примерно в 125 символов — большинство скринридеров обрывают чтение на этой отметке. Не начинайте с «изображение», «картинка» или «фото»: робот и так знает, что перед ним картинка, сразу давайте суть. Если изображение работает кнопкой — иконка корзины, лупа поиска, — описывайте её функцию, а не внешний вид: не «иконка увеличительного стекла», а «поиск по сайту». А для графика передайте главный вывод, а не перечисляйте все цифры: «график роста продаж, +25% в третьем квартале» скажет и человеку, и роботу больше, чем сухой список чисел. И оговорка про чисто декоративные картинки (фоновые узоры, разделители, иконки без смысла): у них alt оставляют пустым — alt="" — это сигнал скринридеру «пропусти, тут ничего важного». Поэтому пустой alt — не всегда ошибка; аудит как раз подсвечивает места, где описание реально нужно, но его нет.

Почему width и height убирают скачки вёрстки

Это тот случай, когда два маленьких атрибута напрямую влияют на позиции. Когда у <img> не заданы width и height, браузер до загрузки файла не знает, сколько места под картинку зарезервировать, и отводит ей ноль пикселей. Текст успевает отрисоваться, а потом картинка «приезжает», раздвигает контент — и всё скачет вниз. Пользователь тянется нажать кнопку, а под пальцем уже другой элемент. Именно эти скачки Google меряет метрикой CLS (Cumulative Layout Shift) из набора Core Web Vitals, и хороший показатель — меньше 0,1.

Лечится одной строкой — задать реальные размеры оригинала:

<img src="divan-milano.webp" width="1200" height="800" alt="Красный кожаный диван Milano">

Браузер по этим числам заранее держит место нужной пропорции, и картинка встаёт в него без рывка. В CSS при этом можно спокойно тянуть ширину на 100% — соотношение сторон современный браузер удержит сам. Аудит отмечает такие изображения кодом img-no-dims, и на страницах с десятками фото это самый частый источник плохого CLS.

Вес и форматы: WebP и AVIF вместо тяжёлого JPEG

Тяжёлые картинки бьют по скорости, а скорость — прямой фактор ранжирования и главный вклад в метрику LCP (загрузка основного контента). Самый дешёвый способ разгрузить страницу — сменить формат. По крупному исследованию Google, WebP весит на 25–34% меньше JPEG при том же качестве, а AVIF — примерно на 50% меньше JPEG и ещё на 20–30% легче WebP. Поддержка уже не проблема: WebP понимают около 95% браузеров, AVIF — под 94%, включая Safari.

Практика простая. Для WebP держите качество 75–85, для AVIF хватает 60–70 — визуально это как JPEG на 85, но файл в разы легче. Если хотите отдавать самый лёгкий формат каждому браузеру и не рисковать совместимостью, используйте <picture> с запасным JPEG:

<picture>
  <source srcset="foto.avif" type="image/avif">
  <source srcset="foto.webp" type="image/webp">
  <img src="foto.jpg" width="1200" height="800" alt="...">
</picture>

Браузер сам возьмёт первый формат, который умеет: новые получат AVIF, старые аккуратно откатятся на JPEG.

Ленивая загрузка: полезно, но не для первого экрана

Атрибут loading="lazy" откладывает загрузку картинок, пока пользователь до них не долистает, — и для фото ниже первого экрана это чистая польза: страница стартует быстрее, а Google такую отложенную загрузку прямо поддерживает. Но есть одна ловушка, которая стоит позиций. Нельзя вешать lazy на главную картинку первого экрана — ту, что формирует LCP. По замерам web.dev, ошибочная ленивая загрузка LCP-изображения поднимает LCP на 75-м перцентиле примерно с 2,9 до 3,5 секунды, а это уже провал Core Web Vitals. Правило короткое: всё, что видно сразу при открытии, грузим обычным способом (а LCP-картинке можно добавить fetchpriority="high"), и только фото ниже — lazy.

Частые вопросы

Влияет ли alt на позиции в обычном поиске?
Напрямую по тексту alt сайт в вебе почти не ранжируется, но именно он открывает трафик из поиска по картинкам и помогает Google и AI-системам понять контекст страницы. Плюс это требование доступности, которое Google учитывает косвенно.

Обязательно ли задавать width и height, если размеры уже прописаны в CSS?
Да. CSS применяется позже, чем браузер начинает рисовать страницу, поэтому от скачка вёрстки спасают именно атрибуты в самом теге <img>. CSS при этом никуда не девается — он управляет отображением, а атрибуты резервируют место.

Что выбрать — WebP или AVIF?
AVIF легче и его стоит ставить первым в <picture>, а WebP оставить как более совместимый запасной вариант перед JPEG. На большинстве сайтов достаточно перевести всё в WebP — это уже минус треть веса без возни.

Хотите увидеть, у скольких ваших страниц картинки без alt и без размеров, — прогоните сайт через бесплатный аудит SEOquick: он подсветит коды alt, img-alt-long и img-no-dims постранично. А как ускорить сайт целиком, разбирали в гайде про скорость сайта.