Ленивая загрузка картинок съедает ваш трафик из поиска по изображениям

Анатолий Кузнецов

SEO-оптимизатор с 20-летним стажем. Автор блога hozyindachi.ru о продвижении и доработке сайтов.

За 20 лет практики я привык к одному парадоксу: чем сильнее сеошник или разработчик ускоряет сайт, тем чаще он собственными руками отрезает себе целый канал трафика. Речь про ленивую загрузку картинок. Её ставят ради красивых цифр в PageSpeed, ради зелёной зоны в Core Web Vitals, ради того самого «сайт летает». А через два месяца человек открывает Яндекс.Вебмастер и не понимает, почему из поиска по картинкам, который раньше приносил 15–20% визитов, осталась одна десятая. Изображения на сайте есть, глазами всё видно, а робот их будто не замечает.

И знаете, что самое обидное? В большинстве случаев ленивая загрузка тут вообще не виновата. Виновата кривая реализация. Правильный lazy loading и скорость поднимает, и индексацию картинок сохраняет — эти две вещи не враги. Врагом их делает разработчик, который воткнул модный JS-плагин, не понимая, что видит поисковый робот на входе. В этой статье я разберу на пальцах: как устроена ленивая загрузка, почему робот теряет изображения, чем нативный loading=lazy отличается от самописных скриптов и что конкретно проверить, чтобы одновременно и ускориться, и не слить трафик из продвижения сайта картинками.

Сразу оговорюсь: тема технически плотная, но я держу её на языке практика. Никаких «важно оптимизировать изображения». Только то, что я реально вижу на замерах и в логах, когда захожу на очередной проект с просевшими картинками.

Что такое ленивая загрузка и зачем её вообще придумали

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

Выгода очевидна. Первый экран открывается быстрее, потому что браузер не давится десятком тяжёлых JPEG. Экономится трафик мобильного пользователя. Улучшается показатель LCP — время отрисовки самого крупного элемента. Всё это напрямую бьёт в скорость загрузки сайта, а скорость — это и поведенческие, и прямой фактор ранжирования, и банально меньше отказов. Я сам всегда за то, чтобы сайт открывался мгновенно, и на любом проекте начинаю технику именно с веса страницы.

Проблема одна: поисковый робот — это не человек. Он не «прокручивает страницу вниз» в привычном нам смысле. И вот тут начинается вся драма. Механизм, который придумали для удобства живого посетителя, при неаккуратной реализации превращается в стену между вашими картинками и индексом Яндекса.

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

Чтобы понять корень проблемы, надо посмотреть на HTML-код глазами робота. Нормальная картинка выглядит так: <img src=»/foto.jpg» alt=»описание»>. Робот заходит, видит атрибут src, идёт по этому адресу, скачивает файл, читает alt — картинка в индексе. Всё честно.

А теперь смотрим, что делают многие JS-плагины ленивой загрузки. Они превращают код в такое: <img data-src=»/foto.jpg» src=»pixel.gif»>. То есть реальный адрес фотографии прячется в атрибут data-src, а в стандартный src подставляется прозрачный пиксель или заглушка. Настоящую картинку подставляет обратно в src уже JavaScript — в тот момент, когда пользователь долистал до неё. Пока скрипт не отработал, в src болтается пустышка.

И вот вопрос на миллион: а что видит робот, который зашёл на страницу и не выполняет весь JavaScript так же охотно, как браузер живого человека? Правильно — он видит в src прозрачный пиксель. А ваша фотография спрятана в непонятном ему атрибуте data-src, который для индексации картинок официально ничего не значит. Итог: двадцать красивых изображений на странице, а в индекс уходит двадцать одинаковых прозрачных пикселей. Или ничего. Это та же логика, что с любым тяжёлым фронтендом — про неё я подробно писал в материале о влиянии JavaScript на продвижение сайта.

Да, Яндекс и Google научились рендерить JS. Но, во-первых, рендеринг — это отдельная, дорогая и отложенная во времени очередь. Во-вторых, робот не будет эмулировать бесконечный скролл, чтобы «долистать» до вашего подвала и дождаться, пока скрипт подставит картинки. Он видит то, что есть в исходном HTML на момент захода. Нет реального src — считай, нет картинки.

Нативный loading=lazy — то, ради чего можно выкинуть половину плагинов

Несколько лет назад браузеры получили встроенную ленивую загрузку. Выглядит она предельно просто: <img src=»/foto.jpg» alt=»описание» loading=»lazy»>. Обратите внимание — реальный адрес остаётся в атрибуте src. Никаких прозрачных пикселей, никаких data-src, никакого обязательного JavaScript. Браузер сам решает, когда подгрузить картинку, ориентируясь на положение прокрутки. А атрибут loading=»lazy» — это просто инструкция «не спеши с этим файлом».

Разница для индексации — колоссальная. Робот заходит, видит честный src с реальным адресом, видит alt — картинка индексируется как обычная. Ленивость тут заложена на уровне браузера и вообще не мешает поисковику. Вы получаете и скорость, и сохранённый трафик из Яндекс.Картинок. Это тот редкий случай, когда «правильно» ещё и «проще».

Мой практический вывод за последние годы жёсткий: если у вас на сайте стоит тяжёлый JS-плагин ленивой загрузки с подменой src, в 9 из 10 случаев его можно снести и заменить нативным атрибутом loading=»lazy». Скорость не просядет, а часто даже вырастет — вы же выкидываете лишний скрипт, который сам по себе тормозит рендер. А индексация картинок разом чинится. Я так делал на десятках проектов, где вопросы увеличения скорости загрузки сайта на WordPress и потеря картинок шли в одном флаконе.

Сравнение: нативный способ против JS-плагинов

Чтобы не быть голословным, сведу разницу в таблицу. Это то, на что я смотрю в первую очередь, когда захожу на новый сайт с жалобой «картинки выпали из поиска».

Оговорюсь честно: не все JS-решения одинаково плохи. Есть грамотные плагины, которые оставляют реальный src и добавляют ленивость поверх, а не через подмену. И есть кейсы, где без скрипта не обойтись — например, фоновые изображения в CSS или сложные галереи. Но базовое правило простое: если можно обойтись нативным атрибутом — обходитесь. Каждый лишний скрипт на странице — это ещё и потенциальная точка отказа, и лишняя нагрузка, о чём я говорю в разборе внутренней оптимизации сайта по шагам.

Роль атрибута alt: без него даже идеальный lazy бесполезен

Отдельно хочу вбить гвоздь про alt, потому что тут ошибаются даже те, кто с ленивой загрузкой всё сделал правильно. Атрибут alt — это текстовое описание картинки. Именно по нему поисковик понимает, ЧТО изображено на фото и по каким запросам показывать вашу картинку в поиске по изображениям. Нет alt — робот видит файл, но не понимает его смысл. Значит, шансов ранжироваться в Яндекс.Картинках почти нет.

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

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

Как проверить, видит ли робот ваши картинки на самом деле

Теория теорией, но проверять надо руками. Вот мой рабочий чек-лист диагностики — прохожу его на каждом проекте с просевшими картинками.

• Смотрим исходный код без выполнения JS. В браузере это «Просмотр исходного кода страницы» (Ctrl+U), а не «Инспектор». В инспекторе вы видите уже отрендеренный DOM, где скрипт подставил картинки. А Ctrl+U показывает именно то, что пришло роботу. Ищем свои картинки: если в src болтается pixel.gif или base64-заглушка, а реальный адрес в data-src — вот он, ваш диагноз.

• Отключаем JavaScript в браузере и обновляем страницу. Если картинки пропали — робот их тоже, скорее всего, не увидит на входе. Если остались — уже хорошо.

• Проверка URL в Яндекс.Вебмастере. Инструмент показывает, как робот видит страницу и какие ресурсы он с неё забрал. Здесь же смотрим, попали ли изображения в загруженные. Про то, как вообще устроена индексация сайта в поисковых системах, я отдельно расписывал — рекомендую освежить.

• Смотрим динамику в разделе поиска по картинкам. В Метрике и Вебмастере видно долю визитов из поиска по изображениям. Резкий провал после внедрения нового плагина или редизайна — прямая улика.

Ещё один момент, который часто упускают: файл robots.txt. Бывает, что папку с изображениями или папку загрузок случайно закрыли от индексации. Тогда никакой lazy loading не поможет — робот просто не имеет права зайти за картинкой. Проверьте свой файл robots.txt для сайта на предмет запретов на директории с медиа.

Пошагово: как совместить скорость и индексацию картинок

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

1. Проведите аудит текущей реализации. Через Ctrl+U и отключение JS определите, есть ли подмена src. Если реальные адреса на месте — вам повезло, идите сразу к пункту про alt.

2. Уберите подмену src. Если стоит тяжёлый плагин с data-src — либо смените его на решение с честным src, либо перейдите на нативный loading=»lazy». В большинстве CMS это делается настройкой или заменой плагина.

3. Первый экран — без ленивости. Картинки, которые видны сразу при открытии (логотип, главный баннер, первое фото), НЕ вешайте на lazy. Иначе вы, наоборот, замедлите LCP. Ленивость — только для того, что ниже первого экрана.

4. Пропишите человеческие alt. Каждой значимой картинке — своё описание с ключом там, где уместно. Это часть общей работы над тем, как контент влияет на продвижение.

5. Сожмите и переведите изображения в современные форматы. WebP вместо тяжёлых JPEG даёт огромную экономию веса без потери качества. Это ускоряет сайт сильнее, чем любая ленивость.

6. Добавьте sitemap для изображений. Отдельная карта картинок или их включение в основную XML-карту помогает роботу найти и проиндексировать медиа быстрее.

7. Проверьте результат через 2–4 недели. Индексация картинок не мгновенная. Следите за динамикой картиночного трафика в Метрике — если сделали всё правильно, он поползёт вверх.

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

Короткие выводы, которые стоит забрать с собой

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

• Нативный loading=»lazy» почти всегда лучше JS-плагина — он оставляет честный src и не требует скриптов.

• Подмена src на data-src — главный убийца индексации картинок. Проверяется за минуту через Ctrl+U.

• Без alt даже идеально настроенный lazy не даст трафика — робот не поймёт, что на фото.

• Первый экран не грузите лениво — иначе испортите LCP вместо того, чтобы улучшить.

• Скорость и индексация совмещаются — это вопрос грамотной реализации, а не компромисса.

Картиночный поиск — недооценённый канал. Для многих ниш он даёт 10–25% бесплатного целевого трафика, и терять его из-за модного плагина — расточительство. Тем более что чинится это, как правило, за один вечер работы разработчика. Кстати, будущее только усиливает роль правильной разметки картинок: та же продвижение в нейросетях и AI-поиске всё активнее опирается на то, что машина реально «видит» на странице, а не на то, что дорисовал скрипт постфактум.

Хотите, чтобы ваш сайт и летал по скорости, и не терял ни одной картинки из поиска — а не сливал трафик на ровном месте из-за кривого плагина? Я занимаюсь продвижением сайтов в Яндексе уже больше 20 лет и готовлю сайты в том числе под выдачу нейросетей и AI-поиск. Разберу вашу техничку, покажу, где вы теряете позиции и заявки, и как это починить без потери скорости.

Увеличьте позиции и продажи вашего сайта

Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:

01 SEO-аудит сайта 02 SEO-продвижение 03 Создание сайтов 04 SEO-статьи для сайта

Получить консультацию

Остались вопросы по продвижению?

Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.

Связаться со мной →