Оптимизация изображений для SEO: полный гайд 2026 — от базы до продвинутых техник

Зачем вообще оптимизировать изображения: влияние на SEO и бизнес

Изображения выглядят как визуальный декор, но с точки зрения поисковых систем — это полноценный контент, технический фактор и сигнал качества страницы одновременно. Разберем каждый уровень отдельно.

Как изображения влияют на ранжирование в Яндексе и Google

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

Три механизма влияния изображений на SEO:

• Технический. Тяжелые картинки замедляют страницу и ухудшают Core Web Vitals — Google использует их как сигнал ранжирования с 2021 года. Яндекс учитывает скорость загрузки как фактор качества сайта.
• Контентный. Alt-тексты, имена файлов и окружающий текст помогают поисковому роботу понять тему страницы и повышают ее релевантность запросу.
• Трафиковый. Правильно оптимизированные изображения попадают в Яндекс.Картинки и Google Images — это отдельный канал органического трафика, который многие сайты просто игнорируют.

По данным Web Almanac 2024, 68% мобильных страниц имеют изображение в качестве LCP-элемента — то есть именно картинка определяет скоростной показатель, который видит Google.

Скорость загрузки, Core Web Vitals и их прямая связь с изображениями

Core Web Vitals — это три метрики, которые Google официально включил в алгоритм ранжирования. Две из трех напрямую завязаны на изображения.

LCP (Largest Contentful Paint) — время отрисовки самого крупного видимого элемента страницы. Норма по Google: до 2,5 секунды. Если на первом экране стоит неоптимизированная фотография весом 1,5 МБ в формате JPEG — LCP будет красным.

CLS* (Cumulative Layout Shift) — визуальная стабильность. Если у изображения не заданы атрибуты width и height, браузер не знает, сколько места зарезервировать, и перестраивает верстку прямо на глазах у пользователя. Google штрафует за это.

По данным corewebvitals.io за 2025 год, только 48% мобильных страниц в мире успешно проходят все три теста Core Web Vitals. Это значит, что больше половины сайтов теряют позиции из-за технических проблем — и изображения занимают в этом списке одно из первых мест.

💡 Практика. Проверьте свой сайт прямо сейчас: откройте PageSpeed Insights и введите адрес главной страницы. В разделе «Возможности» почти наверняка окажется пункт про изображения.

Дополнительный органический трафик из поиска по картинкам

Яндекс.Картинки и Google Images — это не второстепенные разделы поисковиков. Для некоторых тематик (интернет-магазины, рецепты, дизайн, недвижимость, медицина) они дают до 20–30% дополнительного органического трафика, если картинки грамотно оптимизированы.

Влияние на поведенческие факторы, конверсию и отказы

Поведенческие факторы — один из ключевых сигналов Яндекса. Если страница грузится медленно, пользователь уходит раньше, чем успевает прочитать хоть строчку.

При росте времени загрузки с 1 до 10 секунд показатель отказов на мобильных устройствах увеличивается на 123%. А ускорение мобильного сайта на 0,1 секунды увеличивает конверсию в среднем на 8%.

Для интернет-магазинов это прямые деньги: медленная карточка товара с неоптимизированными фото = меньше покупок. Для медийного издания — меньше просмотров и ниже RPM рекламы.

Таблица: Что делают неоптимизированные изображения

Какой формат выбрать: JPEG, PNG, WebP, AVIF, SVG — подробное сравнение

JPEG — когда до сих пор уместен

JPEG — это формат-ветеран 1992 года, который все еще занимает 32,4% всех изображений в мировом вебе. Он сдает позиции: по данным Web Almanac 2024, за два года доля JPEG упала на 8 процентных пунктов. Но списывать его в утиль рано.

Когда JPEG оправдан:

• Аудитория сайта использует устаревшие браузеры или специализированные устройства, где WebP не поддерживается
• Изображения не конвертируются автоматически на сервере или через CDN
• Нужен максимально совместимый фоллбэк в <picture>

Главный минус JPEG — сжатие с потерями без возможности сохранить прозрачность. Каждое повторное сохранение деградирует качество. По данным Web Almanac 2024, медианный JPEG весит 2,0 бита на пиксель — это неплохо, но WebP и AVIF эффективнее.

Важно! Если вы до сих пор выгружаете фотографии товаров на сайт прямо из камеры в исходном JPEG — вы, скорее всего, отдаете браузеру файлы весом 3–8 МБ. Это гарантированно красный LCP.

PNG — прозрачность и точность, но ценой размера

PNG — формат без потерь с поддержкой прозрачного фона. Незаменим там, где важна точность каждого пикселя: логотипы, скриншоты интерфейсов, инфографика с четкими границами.

Когда использовать PNG:

• Логотипы, иконки, баннеры с прозрачным фоном (и когда SVG не подходит)
• Скриншоты и иллюстрации с текстом
• Изображения, которые будут дополнительно обрабатываться

Главный минус — большой вес. Несжатый PNG фотографии в 1920×1080 пикселей может весить 2–5 МБ. Именно поэтому PNG нужно либо сжимать через TinyPNG/Squoosh, либо конвертировать в WebP.

WebP — универсальный выбор #CURRENT_YEAR# года

WebP разработан Google в 2010 году и сегодня поддерживается96%+ браузеров , включая Яндекс.Браузер, Chrome, Firefox, Edge и Safari. Это делает его основным рабочим форматом для большинства проектов.

Преимущества WebP:

• Поддерживает и сжатие с потерями (lossy), и без потерь (lossless)
• Сохраняет прозрачность фона, как PNG
• Поддерживает анимацию, как GIF, но значительно легче
• По данным Google, WebP на 25–35% легче сопоставимого по качеству JPEG

То же изображение, которое в JPG весит 254 КБ, в WebP занимает 106 КБ — это экономия 58%. Медианный WebP весит 1,3 бита на пиксель — это лучший результат среди широко распространенных форматов.

AVIF — следующий уровень сжатия

AVIF (AV1 Image File Format) — самый эффективный из доступных форматов. Появился в 2019 году, разработан Alliance for Open Media на базе видеокодека AV1. Google в августе 2024 года официально добавил поддержку AVIF в поиск.

Цифры из практики:

• PNG исходник: 2 100 КБ
• JPG: 254 КБ (12,1% от PNG)
• WebP: 106 КБ (5,0% от PNG)
• AVIF: 82 КБ (3,9% от PNG)

Поддержка в #CURRENT_YEAR# году: по данным caniuse.com, AVIF поддерживается в Chrome 85+, Firefox 93+, Safari 16+, Edge 121+. Это свыше 93% браузеров в мире. AVIF получил статус Baseline 2024 — то есть работает во всех современных браузерах.

Единственный нюанс — декодирование AVIF требует больше вычислительных ресурсов, чем WebP. На слабых устройствах это может добавить несколько миллисекунд к рендерингу. Именно поэтому правильный подход — давать AVIF через <picture> с фоллбэком на WebP.

SVG — вектор для интерфейсных элементов

SVG (Scalable Vector Graphics) — это не растровый, а векторный формат. Описывает изображение математическими формулами, а не пикселями, поэтому масштабируется без потери качества при любом разрешении экрана.

Идеально подходит для:

• Логотипов и фирменной символики
• Иконок в интерфейсе
• Иллюстраций с геометрическими формами
• Анимированных графических элементов через CSS/JS

SEO-плюс SVG: файл можно встроить прямо в HTML-код страницы (inline SVG), тогда поисковый робот прочитает его текстовый контент. Кроме того, SVG хорошо сжимается Gzip/Brotli на сервере — текстовый формат поддается компрессии лучше, чем бинарные растровые файлы.

Доля SVG выросла на 36% за два года — разработчики массово переходят на вектор для иконок вместо PNG/GIF.

GIF — и почему его давно пора заменить

GIF поддерживает только 256 цветов и в #CURRENT_YEAR# году — это устаревший формат почти для любого сценария. Анимированный GIF весит в разы больше, чем то же видео в формате MP4 или WebM. Медианный анимированный GIF потребляет 32,6 бита на пиксель — против 1,3 у WebP.

Совет: если на сайте есть анимированные GIF — замените их на MP4/WebM с атрибутом autoplay muted loop playsinline. Вес уменьшится в 5–10 раз.

Таблица: какой формат изображения выбрать под конкретную задачу

💡 Практика: по умолчанию используйте WebP как основной формат. Там, где хотите максимальной эффективности и аудитория пользуется современными устройствами — добавляйте AVIF через <picture>. Для логотипов и иконок — SVG. JPEG оставьте только как крайний фоллбэк.

Как правильно сжать изображения: методы, степень компрессии и инструменты

Сжатие с потерями (lossy) — максимальный выигрыш в весе

Lossy-сжатие необратимо удаляет часть данных пикселей, которые человеческий глаз в большинстве случаев не замечает. Именно этот метод дает наибольший выигрыш в весе — от 40% до 90% по сравнению с оригиналом.

Применяется для: фотографий, иллюстраций с плавными градиентами, hero-изображений, баннеров и карточек товаров.

Ключевой параметр — уровень качества (quality). Вот проверенные ориентиры:

Ниже quality 70 для JPEG и ниже 60 для WebP начинают проявляться видимые артефакты — характерные квадратные блоки (banding) и замыленные контуры. Это уже неприемлемо ни для пользователя, ни для поисковика: размытые фото товаров на маркетплейсе снижают CTR карточки.

Сжатие без потерь (lossless) — когда важна точность

Lossless-сжатие уменьшает размер файла, не удаляя ни одного пикселя. Файл после распаковки идентичен оригиналу побайтно.

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

Выигрыш в весе скромнее — от 15% до 40%. Поэтому для фотографий lossless почти никогда не оправдан: лучше взять WebP lossy с quality 80 и получить файл в 3 раза легче при незаметной разнице для глаза.

Оптимальный размер изображения в пикселях

Одна из самых частых ошибок — загружать изображение в исходном разрешении 3000×4000 пикселей, когда на сайте оно отображается в блоке 800×600. Браузер все равно скачивает весь файл целиком, а потом масштабирует его «на лету».

Важно! Физический размер изображения в пикселях должен соответствовать максимальному размеру блока на странице × 2 (для Retina-дисплеев).

Практические ориентиры для типичных элементов:

• Hero-изображение, фон на всю ширину: 2400–2560 пикселей в ширину
• Карточка товара (интернет-магазин): 800–1200 пикселей
• Иллюстрация в статье блога: 1200–1600 пикселей
• Превью (thumbnail): 400–600 пикселей
• OG-изображение для соцсетей (ВКонтакте, Telegram): 1200×630 пикселей

Загружать изображения шире 2560 пикселей для веба почти никогда не нужно. Даже на 4K-мониторах большинство CMS ограничивает ширину контентной колонки 1200–1600 CSS-пикселями.

Как удалить EXIF-метаданные и зачем

Каждое фото с камеры или смартфона несет в себе скрытый груз — EXIF-метаданные*: модель камеры, настройки экспозиции, GPS-координаты съемки, дата и время, данные о программном обеспечении. Для веба это лишний вес — от 20 до 200 КБ на файл в зависимости от камеры и наличия ICC-профиля.

Удаление EXIF-данных перед публикацией — обязательный шаг по двум причинам:

• Снижает вес файла без малейшей потери визуального качества
• Устраняет риск утечки геолокации (актуально для фото из офиса, склада, частного дома)

Большинство инструментов из следующего раздела удаляют EXIF автоматически. Если нужно сделать это вручную — используйте Squoosh или ImageOptim.

Инструменты для ручного сжатия

Squoosh — браузерный инструмент от Google, бесплатный и без регистрации. Позволяет сравнивать оригинал и сжатую версию в реальном времени, конвертировать между форматами, настраивать quality и удалять метаданные. Поддерживает WebP, AVIF, MozJPEG, OxiPNG. Идеален для ручной работы с конкретным файлом.

TinyPNG / TinyJPG — онлайн-сервис, работает через drag-and-drop. Использует умный lossy-алгоритм для PNG и JPEG. Бесплатно — до 20 файлов за раз, платный API — для автоматизации. Один из самых популярных инструментов среди контент-менеджеров.

ImageOptim — десктопное приложение для macOS, полностью бесплатное. Применяет сразу несколько алгоритмов сжатия (MozJPEG, pngcrush, Zopfli, SVGO) и выбирает лучший результат. Работает без потерь по умолчанию, но можно включить lossy-режим.

Плагины для WordPress: сравнение

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

Совет: ShortPixel или EWWW. ShortPixel дает лучшее облачное сжатие — особенно с AVIF. EWWW — лучший выбор, если важна приватность или нет денег на подписку: обрабатывает файлы локально на сервере без лимитов.

Автоматизация для крупных сайтов

Для интернет-магазинов с тысячами товарных фотографий ручной или плагинный подход не работает. Здесь нужен автоматизированный пайплайн.

Три рабочих подхода:

• Image CDN с трансформацией на лету. Сервисы Cloudinary, Imgix или Bunny.net принимают оригинальный файл и отдают пользователю автоматически оптимизированную версию в нужном формате и размере через URL-параметры. Например: image.cdn.ru/photo.jpg?format=avif&width=800&quality=80. Браузер получает AVIF, а в базе хранится один оригинальный файл.
• CI/CD-пайплайн. При деплое сайта автоматически запускается скрипт сжатия (через sharp, imagemin или libvips), который обрабатывает все новые файлы перед публикацией.
• Вебхук при загрузке. Загруженный файл автоматически отправляется на обработку во внешний сервис (ShortPixel API, TinyPNG API), сжатая версия заменяет оригинал.

💡 Практика. Откройте пять самых тяжелых страниц сайта через PageSpeed Insights. Найдите раздел «Правильный размер изображений» и «Изображения в современных форматах». Это и есть ваш приоритетный список для сжатия — начинайте именно с него.

Имя файла изображения — недооцененный SEO-фактор

Имя файла — первое, что видит поисковый робот, когда находит изображение на странице. Еще до того, как он прочитает alt-текст и проанализирует окружающий контент. Google прямо указывает в официальной документации: «Когда возможно, используйте короткие, но описательные имена файлов. Например, my-new-black-kitten.jpg лучше, чем IMG00023.JPG»

Почему поисковики читают filename и как это работает

Имя файла — это URL изображения. А URL, содержащий осмысленные слова, дает поисковому роботу дополнительный сигнал о теме картинки и страницы. Этот сигнал слабее, чем alt-текст или окружающий контент, но в совокупности с остальными факторами влияет на ранжирование в поиске по картинкам.

Яндекс при индексировании изображения также обращает внимание на название файла — оно должно содержать ключевое слово и отражать суть картинки. Особенно это важно для Яндекс.Картинок, где конкуренция за позиции часто определяется именно связкой «имя файла + alt».

Правила составления правильного имени файла

Принцип один: имя файла должен понять человек, не видя самого изображения.

Три обязательных правила:

• Слова разделяются дефисом, не нижним подчеркиванием и не слитно. Google трактует дефис как пробел между словами, нижнее подчеркивание — как их склейку. Файл krasnyy-divAN-ot-prodavca.jpg читается как три слова. Файл krasnyy_divan_ot_prodavca.jpg — как одно.
• Только латиница или транслитерация, без кириллицы. Кириллические символы в URL кодируются в %D0%BA%D1%80%D0%B0%D1%81%D0%BD%D1%8B%D0%B9 — это нечитаемая строка для робота и источник технических ошибок в sitemap.
• Ключевое слово — в начало, вспомогательные слова — в конец. krossovki-adidas-ultra-boost.jpg, а не foto-tovarov-krossovki-adidas.jpg.

Типичные ошибки в именах файлов

Разберем то, что встречается почти на каждом сайте при аудите:

Как организовать структуру папок для изображений

Для сайтов с большими каталогами (интернет-магазин, фотопортфолио, медиаплатформа) структура папок — это тоже SEO-сигнал. Логичный путь /images/mebel/kresla/kreslo-borg-chyornoye.webp лучше, чем /wp-content/uploads/2024/03/34521.webp.

Практические рекомендации:

• Разбивайте изображения по категориям, а не только по датам загрузки
• Используйте те же ключевые слова в названиях папок, что и в структуре URL страниц
• Следите за тем, чтобы при смене CMS или хостинга пути к изображениям не менялись — это 404-ошибки и потеря позиций в поиске по картинкам

Alt-тег и title изображения: как писать правильно — с примерами

Alt-атрибут* — самый весомый SEO-сигнал из всех атрибутов изображения. Google использует alt-текст вместе с алгоритмами компьютерного зрения и содержимым страницы, чтобы понять тему картинки. Яндекс — аналогично.

Что такое атрибут alt и зачем он нужен поисковикам и пользователям

Alt (от англ. alternative text) — это текстовое описание изображения внутри тега <img>. Он выполняет три функции одновременно:

• Для поисковых роботов — текстовый контекст, который помогает понять тему картинки и страницы
• Для пользователей — отображается вместо изображения, если оно не загрузилось (медленный интернет, ошибка сервера)
• Для доступности (a11y) — скринридеры зачитывают alt вслух людям с нарушениями зрения

Важно! Компьютерное зрение Google уже умеет распознать, что на фото изображена кружка. Но алгоритм не узнает, что это «Термокружка Contigo Autoseal 470 мл синяя», пока вы не укажете это в alt. ИИ определяет объект — alt задает его бизнес-контекст.

Разница между alt и title

Их часто путают или заполняют одинаково — это ошибка.

Title изображения — вспомогательный атрибут. Его заполнение полезно для UX (пользователь видит подсказку при наведении), но как SEO-фактор он значительно слабее alt. Заполнять title стоит, когда изображение несет дополнительный контекст, который не вошел в alt. Если такого контекста нет — можно не заполнять.

Формула написания alt-текста

Простая рабочая формула: что изображено + ключевой контекст страницы + конкретика.

Что нельзя делать: три главных запрета

1. Keyword stuffing в alt. Google прямо называет это спамом и может применить фильтр к странице:

<!-- Так делать нельзя -->

<img src="dog.jpg" alt="щенок собака купить щенка недорого

     щенки лабрадора ретривер продажа питомник Москва">

1. Слова «фото», «изображение», «картинка» в alt. Робот на уровне HTML-кода уже знает, что перед ним тег <img>. Скринридер добавляет слово «изображение» сам. Эти слова — балласт.
2. Одинаковые alt у всех изображений на странице. На страницах каталога с 20 карточками товара у каждой картинки должен быть уникальный alt. Автоматически генерируйте его из названия товара + артикул + цвет.

Alt для декоративных изображений — правило доступности

Если изображение служит только визуальным оформлением и не несет смысловой нагрузки — разделитель, фоновый паттерн, иконка рядом с уже подписанной кнопкой — alt должен быть пустым (alt=""), но обязательно присутствовать в коде.

Отсутствие атрибута alt вообще — грубая ошибка. Скринридер прочитает пользователю техническое имя файла вслух: «icon-search-final-v2.svg». Это нарушение стандарта WCAG и технический минус в аудитах Google Lighthouse.

💡 Практика. Откройте в Screaming Frog или любом SEO-краулере отчет по изображениям. Отфильтруйте картинки с пустым alt и картинки, у которых alt совпадает с именем файла — это ваши первоочередные задачи на ближайший спринт.

Технические настройки загрузки изображений: lazy loading, preload, fetchpriority

Правильный формат и сжатие — это работа с файлом. Технические настройки загрузки — это работа с тем, как браузер расставляет приоритеты между ресурсами. Разница в LCP может составлять 1–2 секунды только от правильной расстановки четырех атрибутов в HTML-коде.

Lazy loading — отложенная загрузка изображений ниже экрана

Браузер по умолчанию загружает все изображения на странице сразу — и те, что видны пользователю, и те, что находятся за пределами экрана. Это расходует трафик и задерживает загрузку критичных ресурсов.

Браузер откладывает загрузку картинки до момента, когда пользователь прокручивает страницу и изображение приближается к видимой области. Атрибут поддерживается во всех современных браузерах без JavaScript и без дополнительных библиотек.

По данным Web Almanac 2024, нативный lazy loading используется уже на 35% всех сайтов — и это число продолжает расти. Технология введена в браузерах с 2019–2020 годов и сегодня является стандартной практикой.

Важно! loading="lazy" ставится на все изображения, которые не попадают в первый экран — карточки товаров в каталоге, иллюстрации в теле статьи, галереи внизу страницы.

Почему нельзя ставить lazy loading на LCP-изображение

По данным Web Almanac 2024, в 2024 году 16% мобильных сайтов по-прежнему использовали lazy loading на главном изображении страницы (LCP-элементе). В 2022 году таких сайтов было 18% — прогресс есть, но медленный.

Вот что происходит, когда loading="lazy" стоит на hero-картинке:

1. Браузер начинает сканировать HTML и находит тег <img loading="lazy">
2. Он откладывает загрузку — ждет, пока изображение «приблизится» к viewport
3. Затем браузер понимает, что картинка уже в зоне видимости, и начинает загрузку
4. Но эта задержка уже добавила сотни миллисекунд к LCP

Важно! Если изображение видно пользователю без прокрутки — никакого loading="lazy".

fetchpriority=“high” и preload: как сказать браузеру загрузить главное изображение первым

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

Атрибут fetchpriority="high"* прямо говорит браузеру: этот ресурс нужен немедленно, грузи его в первую очередь.

Etsy зафиксировал ускорение LCP на 4% только за счет добавления fetchpriority="high". Для крупного e-commerce — это миллионы рублей дополнительной выручки.

<link rel="preload">нужен как дополнительный инструмент для случаев, когда LCP-изображение загружается через CSS background или его URL формируется динамически.

Разница между fetchpriority и preload:

• fetchpriority="high" на теге <img> — повышает приоритет уже найденного браузером ресурса
• <link rel="preload"> в <head> — позволяет начать загрузку ресурса еще до того, как браузер дошел до тега <img> в теле страницы

Для максимального эффекта используют оба вместе.

CLS и почему нужно всегда указывать width и height

CLS (Cumulative Layout Shift) — это прыжок верстки на экране в момент, когда браузер внезапно узнает размер изображения после его загрузки. Пользователь читает текст, страница резко смещается вниз — кнопка, на которую он целился, уходит вниз. Это раздражает и фиксируется как высокий CLS.

Причина — отсутствие атрибутов width и height у тега <img>

Когда width и height заданы, браузер рассчитывает соотношение сторон и резервирует нужное место в верстке еще до загрузки файла. Никаких прыжков.

Количество страниц с явно заданными размерами изображений растет — это один из немногих показателей с устойчивой положительной динамикой.

Важно! Значения width и height в HTML должны соответствовать реальным пропорциям изображения, а не его отображаемому размеру на странице. Масштабирование управляется через CSS — например width: 100%; height: auto;. HTML-атрибуты нужны только для резервирования места.

Атрибут decoding=“async” — ускоряем декодирование

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

Атрибут decoding="async" переносит декодирование в фоновый поток, не блокируя рендеринг страницы.

Важно! На LCP-изображении decoding="async" может дать обратный эффект. Асинхронное декодирование означает, что браузер может начать рендерить страницу раньше — до того, как LCP-картинка готова к показу. Это добавляет задержку к метрике Element Render Delay. Поэтому decoding="async" рекомендуется только для изображений ниже первого экрана.

Таблица: Атрибуты для разных позиций изображений

💡 Практика. Откройте DevTools → вкладка Network → отфильтруйте по типу Img. Посмотрите на колонку Priority. Если ваше главное изображение загружается с приоритетом Low или Medium — добавьте fetchpriority="high". Это одно из самых быстрых улучшений LCP, доступных без технической переработки сайта.

Адаптивные изображения: srcset, sizes и тег <picture>

Один сервер — миллион экранов. Смартфон с дисплеем 390 px и 4K-монитор 3840 px запрашивают одну страницу. Если отдать всем один файл 2400 px — мобильный пользователь скачивает втрое больше нужного. Если отдать файл 390 px — на десктопе получим мыло. Решение: адаптивные изображения через srcset, sizes и тег <picture>.

Медианная ошибка в атрибуте sizes — +43 % на десктопе и +16 % на мобайле: браузер скачивает файл крупнее нужного. До 25 % десктопных страниц теряют впустую от 180 KB до 1 MB из-за некорректного sizes.

Как работает srcset с дескрипторами ширины (w)

Атрибут srcset сообщает браузеру реальную ширину каждого варианта файла. Атрибут sizes говорит браузеру, какую ширину займет блок с изображением при данном viewport. Браузер сам выбирает подходящий файл — с учетом DPR (плотности пикселей) и скорости соединения.

Разберем sizes построчно:

• (max-width: 600px) 100vw — на экранах до 600 px картинка занимает всю ширину viewport.
• (max-width: 1200px) 50vw — на экранах 600–1200 px занимает половину.
• 800px — на широких экранах фиксированно 800 px.

Типичная ошибка — написать sizes="100vw" для всех случаев. Тогда браузер на десктопе 1920 px скачает файл 1920×DPR = 3840 px вместо нужных 800 px.

Retina и высокоплотные экраны

Retina (DPR 2×) и AMOLED (DPR 3×) ждут пикселей в 2–3 раза больше CSS-размера. Правило простое: готовьте изображение в 2× от максимального CSS-размера. Карточка товара 400 CSS px → физический файл 800 px. Благодаря сжатию AVIF/WebP файл 800 px в AVIF весит столько же, сколько JPEG 400 px — обмена не происходит.

Для иконок и логотипов используйте SVG — он масштабируется бесконечно без потерь качества и не требует Retina-вариантов.

Тег <picture>: art direction и смена формата

<picture> решает две задачи: подача разных форматов (AVIF → WebP → JPEG) и смена кадрирования под разные экраны (art direction). Браузер читает <source> сверху вниз и берет первый подходящий.

Тег <img> внутри <picture> обязателен — именно в него пишутся alt, width, height, loading и fetchpriority. SEO-атрибуты браузер и поисковики считывают с <img>, а не с <source>.

Art direction: разное кадрирование для разных экранов

Горизонтальный баннер 1200×400 плохо смотрится на телефоне — объект съеживается. С <picture> можно отдать мобильным пользователям квадратный кроп.

Быстрая шпаргалка: сколько вариантов готовить

Автоматизация: чтобы не делать руками

Генерировать 4 размера × 3 формата = 12 файлов на одно изображение вручную нереально. Варианты автоматизации:

• WordPress: плагины Imagify, ShortPixel и EWWW генерируют WebP/AVIF-варианты автоматически при загрузке и подставляют srcset в HTML.
• Image CDN* (Cloudinary, Imgix, Bunny Optimizer): трансформация «на лету» по параметрам URL — ?width=800&format=avif&quality=75. Исходник один — CDN отдает нужный вариант каждому браузеру.
• CI/CD: Sharp (Node.js) или libvips в pipeline при деплое. Один раз настроили — забыли.
• Nuxt Image / Next.js <Image>: компоненты из коробки генерируют srcset и выбирают формат автоматически.

💡 Практика. Откройте DevTools → вкладка Network → фильтр «Img». Колонка «Size» должна показывать файлы, соразмерные реальному CSS-блоку, а не исходники в 3–5 МБ. Для аудита всего сайта используйте Lighthouse: пункт «Правильный размер изображений» покажет страницы с оверсайзными картинками и потенциальную экономию в KB.

CDN и кэширование изображений

Допустим, вы сжали все картинки, перевели их в WebP и настроили srcset. Страница все равно грузится 3–4 секунды для пользователя из Новосибирска — потому что сервер стоит в Москве, а физическое расстояние дает дополнительные 60–100 мс на каждый запрос. Это именно та задача, которую решает CDN.

Что такое Image CDN и чем отличается от обычного CDN

Обычный CDN кэширует файлы на серверах по всему миру и отдает ближайшую копию. Image CDN делает то же самое, но дополнительно трансформирует изображение прямо в момент запроса: меняет формат на WebP/AVIF, подрезает до нужной ширины, сжимает под устройство. На сервер хранится один оригинал, а CDN отдает каждому браузеру нужный вариант.

По данным независимого обзора, ситуация следующая:

💡 Что выбрать на практике. Для большинства сайтов — блогов, интернет-магазинов, корпоративных страниц — оптимальный выбор BunnyCDN: плоская плата $9,50/мес за Optimizer плюс $0,01/ГБ трафика для Европы и Северной Америки. Итого для сайта с 50 ГБ месячного трафика изображений — около $10. Если нужны AVIF, загрузка файлов через API и медиабиблиотека — ImageKit. Если уже используете Cloudflare и каталог небольшой — Cloudflare Images.

Трансформация on-the-fly: как это работает

После подключения Image CDN исходный URL изображения заменяется на CDN-ссылку с параметрами. Браузер запрашивает нужный размер и формат — CDN генерирует вариант и кэширует его для следующих запросов.

Один оригинальный файл — неограниченное количество вариантов. Параметры f_auto / f-auto означают, что CDN сам выберет лучший формат для браузера: AVIF для Chrome, WebP для остальных современных, JPEG для устаревших.

Кэширование: правильные заголовки

CDN сам кэширует трансформированные варианты, но браузерное кэширование — отдельная настройка. Без нее пользователь при каждом визите снова скачивает картинку с CDN-сервера.

Правило для статических изображений: задавайте длинный max-age и используйте cache-busting через имя файла.

Директива immutable сообщает браузеру: файл никогда не изменится, не нужно даже отправлять условный запрос. При обновлении изображения меняйте имя файла — например, добавляйте хэш: product-v2-8a3f.webp. Это и есть cache-busting.

Заголовок Vary: Accept

Если вы отдаете WebP и JPEG с одного URL (через серверное определение браузера), добавьте заголовок Vary: Accept. Иначе прокси-серверы и CDN могут закэшировать WebP-вариант и раздавать его браузерам, которые не умеют его читать.

Большинство Image CDN выставляют этот заголовок автоматически — но если настраиваете server-side конвертацию вручную, проверьте это через DevTools → вкладка Network → заголовки ответа.

Нужен ли CDN для российских сайтов

Крупные российские CDN-провайдеры — CDNVIDEO, MWS CDN (Ростелеком), G-Core Labs, Selectel CDN. Они размещают серверы в Москве, Санкт-Петербурге, Новосибирске, Екатеринбурге — что критично для снижения TTFB для российской аудитории.

Если ваша аудитория преимущественно в России, приоритет — именно провайдер с точками присутствия в РФ. Для международных проектов BunnyCDN, Cloudflare или ImageKit будут лучше по глобальному охвату.

💡 Практика. Откройте DevTools → вкладка Network → нажмите на любое изображение → проверьте:

• Заголовок Cache-Control — должен содержать max-age=31536000.
• Заголовок Content-Type — должен быть image/webp или image/avif, если Image CDN активен.
• Колонка «Size» — если написано (from disk cache) или (from memory cache), кэш работает.

Микроразметка изображений: Schema.org, Open Graph и Twitter Cards

Микроразметка не влияет напрямую на позиции, но меняет то, как страница выглядит в поиске, соцсетях и мессенджерах. Правильно размеченное изображение получает бейджи в Google Images, красивую карточку при шаринге в VK и Telegram, и попадает в AI Overviews. Без разметки Google выбирает картинку для превью самостоятельно — и часто ошибается.

Schema.org ImageObject: как помочь Google понять главное изображение

Google использует два свойства Schema.org для определения ключевой картинки страницы: primaryImageOfPage и image внутри типа страницы (Article, Product, Recipe и др.). Об этом прямо написано в документации Google Search Central.

Минимальный набор полей для ImageObject*:

• url — абсолютный адрес изображения.
• width и height — размеры в пикселях.
• caption — подпись (помогает в Google Discover).
• name — краткое название.
• author — автор/правообладатель (опционально).

Для товаров Google умеет показывать бейджи в Google Images — плашки «Товар», «Рецепт», «Видео» прямо поверх миниатюры. Это увеличивает CTR из поиска по картинкам. Бейдж появляется автоматически, если разметка Product или Recipe корректна и изображение соответствует товару/блюду на странице.

Open Graph: как ваша страница выглядит в VK, Telegram и других соцсетях

Open Graph — протокол, который стал стандартом для всех соцсетей и мессенджеров. Когда пользователь делится ссылкой в VK, Telegram или Одноклассниках, платформа читает OG-теги и строит превью.

Без OG-разметки VK и Telegram сами ищут изображение на странице — и нередко берут логотип, иконку или первую попавшуюся картинку.

Требования к OG-изображению по платформам:

Важно! OG-изображение лучше хранить в формате JPEG или WebP. AVIF пока поддерживается не везде — VK, например, может не показать его корректно. Используйте JPEG 1200×630 px весом до 200 KB как универсальный вариант.

Как проверить разметку

Три инструмента, которые стоит использовать вместе:

• Google Rich Results Test — search.google.com/test/rich-results — проверяет Schema.org и показывает, какие богатые сниппеты доступны.
• VK Debugger — vk.com/dev/pages.getVersion — отображает, как ссылка выглядит при шаринге в VK.
• Facebook* Sharing Debugger — стандартный инструмент для проверки OG-тегов, заодно подходит для диагностики Telegram.

*Признан экстремистской организацией и запрещен на территории РФ.

Что важно запомнить

• primaryImageOfPage в Schema.org помогает Google выбрать нужное изображение для превью в поиске и Google Discover.
• og:image управляет превью в VK, Telegram, Одноклассниках.
• Разметка Product и Recipe дает бейджи в Google Images — это бесплатный способ повысить CTR.
• OG-изображение лучше хранить отдельно от оригинала — фиксированный файл 1200×630 JPEG не нужно перегенерировать при каждом обновлении страницы.
• Если на сайте CMS (WordPress, Tilda, 1С-Битрикс), OG и Schema.org настраиваются через плагины: Yoast SEO, RankMath, SEO Framework — без написания кода вручную.

Image Sitemap и индексация в Яндекс.Картинках и Google Images

Поисковые роботы находят изображения двумя способами: следуя по ссылкам в HTML-коде страниц или читая sitemap. Первый путь работает для большинства обычных картинок. Второй незаменим, если изображения подгружаются через JavaScript, CDN или лежат на поддомене — тогда без sitemap они могут просто не попасть в индекс.

Зачем нужен image sitemap

Image sitemap помогает в трех случаях:

• Изображения загружаются через JavaScript или lazy loading — бот может не дождаться рендера.
• Картинки лежат на CDN-поддомене (например, img.example.ru) — домен не подтвержден в Search Console.
• На странице больше 1 000 изображений — браузерный обход может не охватить все.

Для Яндекс.Картинок sitemap также ускоряет попадание новых изображений в индекс, особенно у сайтов с частыми обновлениями: новостных порталов, маркетплейсов, фотостоков.

Формат XML: минимально необходимый набор полей

Google официально поддерживает только один обязательный тег внутри <image:image> — это <image:loc>. Все остальные теги (<image:caption>, <image:title>, <image:geo_location>, <image:license>) были объявлены устаревшими в мае 2022 года и больше не обрабатываются. Не тратьте время на их заполнение.

Лимит: в одном блоке <url> допускается до 1 000 тегов <image:image>. Если изображений больше — разбивайте на несколько sitemap-файлов и объединяйте через sitemap index.

Важный нюанс с CDN

Если изображения отдаются с другого домена или поддомена (например, https://img.example.ru или https://cdn.cloudinary.com/mysite/...), этот домен нужно отдельно подтвердить в Google Search Console. Иначе Google проигнорирует такие URL в sitemap. Пошаговый порядок действий:

1. Откройте Google Search Console → «Добавить ресурс».
2. Выберите тип «Префикс URL» и введите домен CDN.
3. Подтвердите права — добавьте HTML-тег или DNS-запись.
4. После подтверждения добавьте CDN-домен в image sitemap.

Как подключить image sitemap к robots.txt

Укажите путь к sitemap в файле robots.txt — оба поисковика читают этот файл при первом обходе.

Если используете единый sitemap, можно не создавать отдельный файл для изображений — достаточно добавить <image:image> теги в существующие <url> блоки основного sitemap.

Как отправить sitemap в Google Search Console и Яндекс.Вебмастер

В Google Search Console:

1. Откройте раздел «Индексирование» → «Файлы Sitemap».
2. Введите URL файла — например, https://example.ru/image-sitemap.xml.
3. Нажмите «Отправить».
4. Через 1–7 дней в разделе появится статус обработки и количество обнаруженных изображений.

В Яндекс.Вебмастере:

1. Перейдите в «Индексирование» → «Файлы Sitemap».
2. Добавьте URL sitemap вручную или убедитесь, что он уже указан в robots.txt — Яндекс подхватит его автоматически при обходе.

Что блокирует индексацию изображений: частые ошибки

Проблема с индексацией чаще всего вызвана не отсутствием sitemap, а запретом в robots.txt. Проверьте три вещи:

• Директива Disallow: /images/ — она запрещает боту заходить в папку с картинками.
• Директива Disallow: /wp-content/uploads/ — стандартная папка WordPress, случайно закрытая от индексации.
• Заголовок X-Robots-Tag: noindex на CDN-сервере — некоторые CDN по умолчанию ставят этот заголовок на статические файлы.

Проверить, доступна ли конкретная картинка боту, можно в Google Search Console: «Инспекция URL» → введите прямой URL изображения → «Проверить».

Трафик из Яндекс.Картинок и Google Images: что реально работает

Попасть в индекс — это только первый шаг. Чтобы изображение ранжировалось по запросам, важны три вещи:

• Релевантность контексту страницы. Поисковик понимает тему картинки не только по alt-тексту, но и по заголовкам страницы, окружающему тексту и имени файла. Картинка «Рюкзак для похода» на странице о рюкзаках ранжируется лучше, чем та же картинка на странице о кроссовках.
• Уникальность. Стоковые фотографии, которые используют тысячи сайтов, практически не ранжируются в поиске по картинкам — алгоритм отдает предпочтение оригинальным изображениям. Авторские фото, инфографика, скриншоты с реальными данными — вот что дает трафик.
• Качество посадочной страницы. Google Images при клике показывает страницу-источник. Если страница медленная, нерелевантная или плохо ранжируется в текстовом поиске — картинка тоже получает меньше показов.

Автоматизация: инструменты для генерации image sitemap

Создавать sitemap вручную имеет смысл только для небольших сайтов. Для остальных:

• WordPress: плагины Yoast SEO, RankMath и XML Sitemap Generator автоматически включают изображения из медиабиблиотеки и контента страниц в sitemap.
• Screaming Frog SEO Spider: при сканировании сайта автоматически обнаруживает все изображения и может экспортировать image sitemap.
• Кастомные CMS: используйте библиотеки вроде sitemap (Node.js) или python-sitemap для программной генерации с включением изображений.

Аудит и типичные ошибки: полный чек-лист оптимизации изображений

Большинство проблем с изображениями не видны глазом — они прячутся в HTTP-заголовках, атрибутах и размерах файлов. Регулярный аудит занимает 30–60 минут, но экономит часы работы в PageSpeed и баллы в Core Web Vitals.

Инструменты для аудита: что и чем проверять

Четыре инструмента закрывают 95 % задач:

• PageSpeed Insights — анализирует конкретную страницу, показывает пункты «Правильный размер изображений», «Изображения в современных форматах», «Отложенная загрузка изображений за пределами экрана», «Элемент LCP». Бесплатно, без регистрации.
• Screaming Frog SEO Spider — сканирует весь сайт, вкладка «Images» показывает: отсутствие alt-текста, пустой alt, alt длиннее 100 символов, битые изображения (4xx), размер файла, размеры (width/height). Бесплатная версия — до 500 URL.
• Google Search Console — раздел «Индексирование» → «Страницы» помогает найти страницы, где изображения заблокированы через robots.txt или недоступны боту.
• Ahrefs / Semrush Site Audit — в отчете «Issues» есть специальный раздел по изображениям: битые картинки, отсутствие alt, oversized images, отсутствие width/height.

10 самых частых ошибок и как их исправить

1. Оверсайзные изображения (самая массовая проблема)

Загрузка оригинального файла 3–5 МБ при блоке в 400 CSS-пикселей. PageSpeed называет это «Правильный размер изображений» и показывает потенциальную экономию в KB.

Как исправить: отдавайте изображение шириной максимум в 2× от CSS-блока. Карточка товара 400 px → файл 800 px. Используйте srcset для разных размеров экрана.

2. Устаревшие форматы: JPEG и PNG вместо WebP/AVIF

JPEG занимает 32,4 % от всех изображений, PNG — 28,4 %, WebP — только 12 %. Больше половины сайтов все еще не используют современные форматы.

Как исправить: переведите все фотографии в WebP (минимум) или AVIF+WebP через <picture>. Для WordPress — плагины ShortPixel, EWWW или Imagify.

3. Отсутствие или пустой alt-текст

У 45 % изображений alt-атрибут отсутствует. Это одновременно SEO-ошибка и нарушение стандарта доступности WCAG.

Как исправить: в Screaming Frog перейдите на вкладку «Images» → фильтр «Missing Alt Text» и «Alt Text». Для декоративных картинок — alt="", для смысловых — осмысленное описание 3–15 слов.

4. Lazy loading на LCP-изображении

Самая дорогая ошибка с точки зрения Core Web Vitals. LCP-элемент с loading="lazy" откладывает загрузку главной картинки страницы — LCP растет на сотни миллисекунд. 16 % мобильных страниц до сих пор совершают эту ошибку.

Как исправить: уберите loading="lazy" с первого изображения в viewport. Добавьте fetchpriority="high" на hero-изображение.

5. Отсутствие атрибутов width и height

Без явных размеров браузер не резервирует место под картинку — страница «прыгает» при загрузке (CLS). Google штрафует за это через Core Web Vitals.

Как исправить: всегда прописывайте реальные width и height в теге <img>. В Screaming Frog — фильтр «Missing Width» и «Missing Height» на вкладке Images.

6. Битые изображения (404)

Изображения, которые возвращают 4xx, не отображаются у пользователей и создают негативный UX. Это напрямую ухудшает пользовательский опыт и косвенно влияет на ранжирование.

Как исправить: в Screaming Frog — фильтр «Response Codes» → «4xx» на вкладке Images. В Ahrefs Site Audit — отчет «Broken Images». Исправьте URL или загрузите файлы обратно.

7. Изображения в CSS background вместо <img> для контентных картинок

CSS-фоны не индексируются поисковиками и не дают alt-текст. Если изображение несет смысловую нагрузку — оно должно быть в <img>.

Как исправить: перенесите контентные изображения из CSS в HTML <img>. CSS background оставьте только для декоративных элементов.

8. Дублирующиеся alt-тексты в каталоге

Интернет-магазины с тысячами карточек товара часто используют один шаблон alt = «Фото товара» или alt = название категории. Для поисковика это выглядит как дублированный контент.

Как исправить: генерируйте alt динамически: «{Название товара}, {цвет}, {артикул}» — например, «Рюкзак Osprey Stratos 36, синий, OS-STR36-BL».

9. Некорректный атрибут sizes в srcset

Медианная ошибка в sizes — +43 % на десктопе. Браузер скачивает файл крупнее нужного, хотя набор вариантов в srcset правильный.

Как исправить: проверьте sizes в DevTools: при каждом breakpoint браузер должен скачивать именно тот вариант, который соответствует реальному блоку. Используйте инструмент RespImageLint для автоматической проверки.

10 EXIF-данные не удалены

Необработанные фотографии с камеры содержат EXIF: GPS-координаты, данные камеры, превью — это лишние 20–200 КБ на файл.

Как исправить: удаляйте EXIF при экспорте через Squoosh, ImageOptim или автоматически через плагин (ShortPixel, Imagify это делают по умолчанию).

Сводный чек-лист аудита изображений

Как расставить приоритеты

Начните с красных пунктов — они напрямую влияют на LCP, CLS и Core Web Vitals, а значит, на ранжирование в Google. Красные пункты обычно дают ощутимый прирост баллов PageSpeed за 1–2 дня работы. Желтые — это следующий спринт, зеленые — финальная полировка.

Запускайте Screaming Frog и PageSpeed Insights после каждого крупного обновления сайта: смена темы WordPress, редизайн, новая версия CMS — все это регулярно «ломает» настройки изображений, которые были выставлены до этого.

Специфика оптимизации по типам сайтов

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

Интернет-магазины

Для e-commerce изображения — это не иллюстрация, а инструмент продажи. Пользователь не может потрогать товар, поэтому фотографии частично выполняют эту функцию. Одновременно карточки товаров — самая частая точка SEO-проблем с изображениями: тысячи страниц с одинаковым шаблоном alt-текстов, оверсайзными фото и дубликатами.

Формат и размеры. Карточка товара: основное фото 800×800 px (квадрат, фон белый — стандарт Ozon и Wildberries для собственного сайта). Галерея: 4–8 фото по 800–1200 px. При передаче через srcset — варианты 400, 800 и 1200 px в WebP/AVIF. Превью в каталоге: 300–400 px.

Alt-тексты в каталоге. Главная ошибка — шаблон «Фото товара» или пустой alt на тысячах карточек. Генерируйте alt динамически из атрибутов товара:

alt="{Название товара}, {цвет/размер}, {артикул}"

Пример: alt="Кроссовки Nike Air Max 90, белые, размер 42, арт. CQ2560-100". Это одновременно дает уникальный alt, помогает поиску по картинкам и улучшает доступность.

Schema.org Product. Каждая карточка должна содержать разметку Product с полем image — это открывает путь к бейджам «Товар» в Google Images и rich snippets с ценой и рейтингом в текстовой выдаче.

Zoom и 360°. Если используете zoom или 360-просмотр, убедитесь, что основное фото грузится первым через <img> с fetchpriority="high", а скрипты zoom не блокируют рендер страницы.

Приоритет: LCP на карточке — почти всегда главное фото товара. Убедитесь, что оно не lazy-loaded, имеет fetchpriority="high" и весит не больше 150–200 KB в WebP.

Блоги и медиа

Для блогов изображения решают три задачи: улучшают поведенческие факторы (время на странице), дают трафик из поиска по картинкам и попадают в Google Discover.

Google Discover — отдельная история. Для показа в Discover изображение должно быть шириной не менее 1200 px и указано в og:image или через primaryImageOfPage в Schema.org. Маленькие или стоковые картинки сокращают охват в Discover — Google прямо это указывает в рекомендациях.

Обложка статьи. Минимум 1200×630 px для OG и Google Discover. Используйте авторские иллюстрации или уникальные фото — стоковые изображения, которые встречаются на тысячах сайтов, хуже ранжируются в поиске по картинкам.

Иллюстрации внутри текста. Для скриншотов, схем, графиков — WebP (lossless). Подписывайте через <figcaption>: это дополнительный текстовый контекст для поисковика и помощь слабовидящим.

Инфографика. Если инфографика создана в векторном редакторе (Figma, Illustrator) — экспортируйте в SVG: масштабируется бесконечно, хорошо сжимается gzip. Для сложных растровых инфографик — WebP с lossless-сжатием. Добавляйте подробное описание в <figcaption> или соседний блок текста: поисковик читает не картинку, а текст вокруг нее.

Лендинги

На лендинге каждые 100 мс — деньги. Конверсионная страница с плохим LCP теряет пользователей еще до того, как они увидят оффер. Здесь оптимизация изображений — это напрямую оптимизация выручки.

Hero-изображение — абсолютный приоритет. Это почти всегда LCP-элемент. Чек-лист для hero:

• Формат: AVIF → WebP → JPEG через <picture>.
• Размеры: 2400 px ширина для десктопа, 800 px для мобайла — через srcset.
• Вес: не более 200 KB в WebP, 120 KB в AVIF.
• Атрибуты: fetchpriority="high", без loading="lazy", с реальными width и height.
• Предзагрузка: <link rel="preload" as="image" href="hero.avif" type="image/avif" fetchpriority="high"> в <head>.

Остальные изображения. Все, что ниже первого экрана — loading="lazy". Блоки с отзывами, фотографии команды, иконки преимуществ — WebP, размер под CSS-блок. Иконки и логотипы — SVG.

Фоновые изображения через CSS. Если hero реализован через background-image в CSS, а не через <img>, поисковик его не индексирует и fetchpriority не работает. Для лендингов, где нужна индексация — переведите hero на <img>. Для декоративных фонов — CSS-подход допустим.

Новостные сайты и медиапорталы

Скорость публикации и автоматизация — ключевые требования. Редакторы не должны думать об оптимизации при каждой загрузке фото.

Автоматизация на уровне CMS. Настройте автоматическую конвертацию и сжатие при загрузке изображений: плагин на WordPress, хук в 1С-Битрикс, CDN с on-the-fly трансформацией. Редактор загружает оригинал — система сама создает WebP, AVIF, нужные размеры и прописывает srcset.

Турбо-страницы Яндекса. Для новостных сайтов с высокой долей мобильного трафика — подключите Турбо-страницы Яндекса. Они автоматически оптимизируют изображения и отдают облегченную версию страницы. Изображения в Турбо-страницах обрабатываются Яндексом — оригинал загружается на сервер Яндекса и оптимизируется автоматически.

AMP (Google). Для попадания в «карусель» Google News — изображение в AMP-статье должно быть минимум 1200×800 px и указано в <amp-img> с корректными width, height и layout="responsive".

Обложки для Google Discover. Каждая статья должна иметь уникальное фото шириной от 1200 px, указанное в og:image. Редакционный стандарт: не брать стоковые фото, которые уже использовались на других сайтах — Discover отдает предпочтение уникальным изображениям.

Архивы и CDN. Новостные порталы накапливают десятки тысяч изображений. Без Image CDN (Cloudinary, BunnyCDN, G-Core Labs для российских проектов) сервер быстро становится узким местом. Настройте origin pull и долгосрочное кэширование — большинство архивных фото никогда не меняются.

Сравнительная таблица приоритетов по типам сайтов

FAQ: ответы на самые частые вопросы

Нужно ли заполнять alt для каждой картинки на сайте?

Да, но не всегда текстом. У каждого тега <img> должен быть атрибут alt. Если картинка декоративная (фоновый паттерн, разделитель, иконка без функции) — alt="". Если изображение несет смысловую нагрузку — пишите краткое описание 3–15 слов. Браузеры для слабовидящих при отсутствии alt зачитывают имя файла — пользователь слышит что-то вроде «img_0042_final_v2.jpg», что бессмысленно.

WebP или AVIF — что выбрать в #CURRENT_YEAR# году?

Используйте оба через тег <picture>: AVIF для современных браузеров (Chrome 85+, Firefox 93+, Safari 16+, Edge 121+) и WebP как запасной вариант. WebP поддерживают 96 % браузеров, AVIF — более 93 %. При одинаковом качестве AVIF весит на 30–50 % меньше WebP, а WebP — на 25–35 % меньше JPEG. Если CMS или хостинг не поддерживает AVIF — используйте WebP, это уже огромный выигрыш по сравнению с JPEG.

Как быстро провести массовую оптимизацию изображений на большом сайте?

Три подхода в зависимости от масштаба. Для WordPress — установите плагин ShortPixel или EWWW Image Optimizer: они автоматически пережимут и сконвертируют в WebP всю медиабиблиотеку в фоновом режиме. Для произвольного сайта — подключите Image CDN (BunnyCDN Optimizer, Cloudinary, ImageKit): они трансформируют изображения on-the-fly без изменения исходников. Для разовой задачи — используйте Squoosh CLI или Sharp в скрипте для пакетной обработки. Начинайте с самых тяжелых страниц — PageSpeed Insights покажет, где потери максимальны.

Почему у меня плохой LCP, хотя изображение маленькое по весу?

Вес — не единственная причина высокого LCP. Частые причины: изображение загружается через JavaScript или CSS background — Googlebot не видит его заранее и не приоритизирует. Другая причина — изображение стоит после сторонних скриптов, которые блокируют рендер. Третья — loading="lazy" на hero-картинке. Проверьте в DevTools: Elements → найдите LCP-элемент → убедитесь, что на нем стоит fetchpriority="high" и нет loading="lazy". Добавьте <link rel="preload" as="image"> в <head> для CSS-фонов.

Нужен ли отдельный image sitemap или достаточно добавить картинки в основной?

Можно и так, и так — Google принимает оба варианта. Если у вас уже есть sitemap.xml, просто добавьте в него теги <image:image> для каждой страницы. Отдельный image sitemap удобнее, когда изображений много (тысячи) или они живут на CDN-поддомене, который нужно подтвердить отдельно в Google Search Console. Яндекс.Вебмастер принимает тот же формат.

Влияет ли CSS background-image на SEO?

Прямо — нет. Google не индексирует изображения, подключенные через CSS, и не читает alt-текст (его там нет). Если картинка несет смысловую нагрузку — переведите ее в <img> с alt-атрибутом. CSS background оставьте для декоративных элементов: паттернов, градиентов, фоновых текстур.

Мнение эксперта

— Александр Апраксин, совладелец и генеральный директор digital-агентства MWI (входит в ТОП-10 Рейтинга Рунета). Автор книги «50 способов увеличения продаж интернет-магазина». Ведущий подкаста «Маркетологи», автор Telegram-канала Апраксин Pro Бизнес. Практик с 15+ годами опыта в digital и eCommerce. Сайт компании: mwi.me.

Визуальный поиск перестал быть нишевой историей. По данным imageseo.io, в #CURRENT_YEAR# году Google Lens обрабатывает около 12 миллиардов визуальных запросов в месяц — это примерно 20 % всего трафика Google. Google Images обеспечивает 22 % от всех веб-поисков, а визуальный поиск растет на 30 % ежегодно.

Параллельно Яндекс развивает поиск с Алисой и AI Overviews — интеграцию, где изображения с правильной микроразметкой ImageObject и primaryImageOfPage попадают в ответы нейросети напрямую. Что это означает для практики? Оптимизация изображений — это комплексная работа на пересечении технической скорости (Core Web Vitals), семантической релевантности (alt, имя файла, контекст) и структурированных данных (Schema.org, Open Graph). Сайты, которые делают все это системно, получают трафик из трех каналов одновременно: текстовый поиск, поиск по картинкам и визуальный поиск через Google Lens и Яндекс.

Изображения перестали быть вторичным элементом SEO-стратегии. Для e-commerce, медиа и любого визуально-ориентированного бизнеса они становятся самостоятельным каналом привлечения аудитории. И конкуренция в этом канале пока значительно ниже, чем в текстовом поиске — именно потому, что большинство команд до сих пор ограничиваются базовым сжатием и забытыми alt-текстами.

Заключение

За этот гайд мы прошли полный путь: от выбора формата и настройки srcset до image sitemap, микроразметки и специфики по типам сайтов. Если свести все к одному абзацу: конвертируйте изображения в WebP/AVIF, сжимайте до разумного веса, прописывайте осмысленные alt-тексты, не ленайте-лоудьте hero-картинку и подайте image sitemap — это даст ощутимый прирост скорости, позиций и трафика из поиска по картинкам.

Оптимизация изображений — один из немногих SEO-инструментов, где результат виден быстро и измеримо: PageSpeed Insights покажет прирост баллов, Google Search Console — рост показов из Images, а Яндекс.Вебмастер — новые страницы в индексе.

Не откладывайте. Откройте PageSpeed Insights прямо сейчас, введите URL своей главной страницы и посмотрите раздел «Возможности». С высокой вероятностью там окажутся пункты про изображения — это и есть ваш список задач на ближайший спринт.

Начните с трех шагов: переведите изображения в WebP, добавьте fetchpriority="high" на hero, проверьте alt-тексты через Screaming Frog. Остальное — итерации.

Термины и сноски

Alt-тег (атрибут alt) — текстовое описание изображения в атрибуте alt тега <img>. Читается поисковыми роботами и скринридерами. Обязателен для всех смысловых изображений.

* CDN (Content Delivery Network) — сеть серверов, распределенных географически. Отдает файлы с ближайшего к пользователю сервера, снижая задержку. Image CDN дополнительно трансформирует изображения on-the-fly.

* CLS (Cumulative Layout Shift) — метрика Core Web Vitals, измеряющая визуальную стабильность страницы. Изображения без атрибутов width и height вызывают «прыжки» контента и повышают CLS.

* Core Web Vitals — набор метрик Google для оценки пользовательского опыта: LCP (скорость загрузки), INP (интерактивность), CLS (стабильность). Используются как ранжирующий сигнал с 2021 года.

* EXIF (Exchangeable Image File Format) — метаданные, встроенные в файл изображения: GPS-координаты, модель камеры, дата съемки, настройки экспозиции. Увеличивают вес файла на 20–200 KB, рекомендуется удалять перед публикацией.

* fetchpriority — HTML-атрибут, управляющий приоритетом загрузки ресурса браузером. Значение high используется на LCP-изображении для ускорения его загрузки.

* ImageObject — тип Schema.org для описания изображения в структурированных данных. Включает свойства url, width, height, caption. Помогает Google правильно выбрать главное изображение страницы.

Категория вопроса

Что мы можем предложить?