Lazy load и бесконечная лента: почему половина сайта не в индексе

В каталоге 4 200 товаров. В Яндексе — 190. Владелец магазина третий месяц платит за продвижение и не понимает, почему товары не появляются в поиске: сайт быстрый, тексты написаны, sitemap отдаётся. А причина в одной строчке кода: карточки подгружаются скриптом при прокрутке страницы. Человек листает и видит все 4 200. Робот заходит, получает первые 24 и уходит — он не прокручивает.

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

Две разные технологии, которые путают

Для начала разделим понятия, потому что решения для них разные.

	Lazy load изображений	Бесконечная лента (infinite scroll)
Что откладывается	Загрузка картинок вне экрана	Загрузка новых элементов списка
Есть ли контент в HTML	Да, тег есть, меняется только момент загрузки файла	Нет, элементы создаются скриптом
Риск для индексации	Низкий при верной реализации	Высокий
Что теряется	Трафик из Яндекс.Картинок	Целые страницы каталога или ленты

Ленивая загрузка картинок при правильной реализации почти безопасна и полезна. Бесконечная лента — источник системных проблем. Начнём с более простого случая.

Lazy load изображений: как не потерять картинки

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

Проблема возникает, когда ленивая загрузка реализована через JavaScript с подменой атрибутов:

<!-- ПЛОХО: робот не видит адрес картинки -->
<img data-src="/images/divan.jpg" class="lazy" alt="Диван">

<!-- ХОРОШО: нативная ленивая загрузка -->
<img src="/images/divan.jpg" loading="lazy" alt="Диван угловой Милан"
     width="600" height="400">

В первом варианте настоящий адрес спрятан в нестандартном атрибуте data-src, а в src либо пусто, либо заглушка. Робот, разбирающий HTML, видит заглушку — и изображение не попадает в индекс Яндекс.Картинок. Для интернет-магазинов, где картиночный трафик даёт заметную долю переходов, это прямая потеря. Подробнее — в материале про SEO изображений.

Во втором варианте используется встроенный в браузеры атрибут loading="lazy". Адрес остаётся на своём месте в src, отложенную загрузку обеспечивает сам браузер, никакого JavaScript не требуется. Это правильный способ.

Дополнительные правила:

• Не применяйте lazy load к изображениям в первом экране. Главный баннер, фото товара вверху карточки должны грузиться сразу — иначе вы ухудшаете показатель LCP, один из ключевых в Core Web Vitals.
• Всегда указывайте width и height. Без них страница «прыгает» при загрузке картинок, а это портит показатель сдвига макета.
• Заполняйте alt осмысленно. Это и доступность, и сигнал о содержимом.
• Проверьте, что картинки есть в sitemap или в отдельной карте изображений.

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

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

Робот Яндекса умеет исполнять JavaScript, но это не решает проблему по трём причинам:

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

Третий пункт — ключевой и наименее очевидный. Даже идеально работающая бесконечная лента, где робот каким-то чудом увидел все элементы, не создаёт страниц, которые можно ранжировать. Проблема глубже, чем видимость: она в архитектуре. Смежные сложности разобраны в материале про JavaScript SEO.

Как проверить, что видит робот

Четыре способа, от самого быстрого к самому точному.

Способ 1: исходный код

Откройте страницу каталога и нажмите Ctrl+U — это покажет именно тот HTML, который получает робот при первичном обходе, без выполнения скриптов. Найдите поиском название товара, который находится в середине или в конце списка. Не нашли — робот его тоже не видит.

Способ 2: отключить JavaScript

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

Способ 3: инструменты Вебмастера

Раздел «Инструменты» → «Проверка ответа сервера» покажет содержимое, полученное роботом. Это самый достоверный источник, потому что запрос идёт от лица настоящего робота Яндекса. Возможности раздела описаны в гайде по Яндекс Вебмастеру.

Способ 4: логи сервера

Покажет, какие URL робот реально запрашивал. Если в логах фигурирует только первая страница каталога, а адреса вида ?page=2 отсутствуют — подтверждение диагноза. Методика в статье про анализ логов сервера.

Как сделать правильно: гибридный подход

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

Реализация	Виден ли контент роботу	Удобно ли человеку	Вердикт
Чистая бесконечная лента	Нет	Да	Не применять
Классическая пагинация	Да	Приемлемо	Безопасно, но старомодно
Кнопка «Показать ещё» с обновлением URL	Да	Да	Оптимально
Прокрутка + подмена URL через History API	Да, при верной настройке	Отлично	Оптимально, сложнее в реализации
Серверный рендеринг + прокрутка	Да	Отлично	Лучшее, но дороже всего

Разберём третий вариант, самый практичный по соотношению цены и результата:

1. Страница /catalog/divany/ отдаёт первые 24 товара прямо в HTML.
2. Внизу — кнопка «Показать ещё», которая одновременно является настоящей ссылкой на /catalog/divany/?page=2.
3. При клике скрипт перехватывает переход, подгружает товары и дописывает их к списку — человек остаётся на месте.
4. При этом адрес в строке браузера меняется на ?page=2 через History API.
5. Робот, не исполняющий скрипты, видит обычную ссылку и переходит по ней как по нормальной странице.
6. Страница ?page=2 при прямом заходе отдаёт свои 24 товара в HTML.

Получается конструкция, где человек листает без перезагрузок, а робот обходит обычную пагинацию. Ключевой момент — пункт 2: кнопка должна быть тегом <a> с рабочим href, а не <div onclick>. Робот переходит только по ссылкам.

Настройка пагинации: детали, которые решают

Раз уж пагинация возвращается, её нужно настроить правильно, иначе вы поменяете одну проблему на другую — дубли.

• Каждая страница пагинации канонична сама себе. Массовая канонизация на первую страницу приводит к выпадению товаров со вторых и последующих.
• Title и description различаются: добавляйте «— страница 2» и подобное, чтобы не плодить одинаковые мета-теги.
• Текст категории — только на первой странице. Дублировать его на всех страницах не нужно.
• Ссылки на первую, последнюю и соседние страницы должны быть в HTML — так робот быстрее обходит глубину.
• Не закрывайте пагинацию от индексации. Через неё робот добирается до товаров; закрыв её, вы отрежете каталог.

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

Особый случай: лента новостей и блог

Для блогов и новостных лент бесконечная прокрутка распространена не меньше. Здесь ситуация чуть мягче — статьи обычно имеют собственные адреса и попадают в индекс через sitemap. Но проблема остаётся: лента перестаёт работать как канал распределения веса.

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

Решения:

• Настоящая пагинация ленты со ссылками в HTML.
• Рубрики и теги как дополнительные точки входа.
• Блок «Читайте также» в каждой статье — перекрёстные ссылки между материалами.
• Архив по месяцам или годам для больших блогов.

Эти же приёмы решают более общую задачу распределения веса, описанную в материалах про внутреннюю перелинковку и контент-план для блога.

Что делать, если проблема уже есть

План восстановления для сайта, который годами работал на бесконечной ленте:

Этап	Действие	Срок
1	Диагностика: сколько страниц реально в индексе против общего числа	1 день
2	Внедрение пагинации с настоящими ссылками в HTML	1–2 недели разработки
3	Настройка мета-тегов и канонических адресов страниц пагинации	2–3 дня
4	Обновление sitemap.xml: все страницы каталога и товары	1 день
5	Отправка на переобход, ускорение через IndexNow	1 день
6	Контроль роста числа страниц в индексе	4–8 недель

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

Частые ошибки при исправлении

• Оставить кнопку «Показать ещё» на теге div. Робот по ней не пойдёт — вся работа впустую.
• Сделать пагинацию, но закрыть её в robots.txt. Логика «это же дубли» приводит к тому, что каталог снова невидим.
• Канонизировать все страницы пагинации на первую. Товары со страниц 2+ выпадают из индекса.
• Не проверить результат в исходном коде. Разработчик отчитался, а товары по-прежнему появляются только скриптом.
• Забыть про мобильную версию. Часто на десктопе пагинация есть, а на мобильных осталась прокрутка. Учитывая приоритет мобильной версии при индексации, это обнуляет исправление — см. мобильную оптимизацию.

Вывод

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

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

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