Красивый сайт на JavaScript, который робот видит пустой страницей

Красивый сайт на JavaScript, который робот видит пустой страницей, — самая незаметная из дорогих проблем: для человека всё переливается анимациями и мгновенно подгружает карточки, а поисковая система получает голый контейнер с парой скриптов. Заказчик открывает — работает. Дизайнер гордится. Трафика из поиска нет, и полгода никто не может объяснить почему.

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

Что такое клиентский рендеринг

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

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

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

Почему робот действительно видит пустоту

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

Обход идёт в две волны. Сначала робот забирает исходный ответ сервера. Если там пусто, страница отправляется в очередь на отрисовку. Вторая волна наступает позже — иногда через дни, иногда через недели, а на больших сайтах может не наступить вовсе, потому что отрисовка ресурсоёмка и очередь бесконечна.

Бюджет обхода конечен. На каждый сайт выделяется ограниченный объём ресурсов. Страница, которую нужно ещё и собрать, стоит дороже обычной в разы. Чем больше сайт, тем меньше документов успевает пройти вторую волну.

Ошибка скрипта равна пустой странице. Если при выполнении что-то пошло не так — не ответил источник данных, скрипт упал на неподдерживаемой конструкции, истёк таймаут, — робот не увидит ничего. У человека при этом всё может работать, потому что его браузер новее и терпеливее.

Подробнее об этом — в статье «Проверка мобильной версии: что видит робот, открывая сайт с телефона».

Разные системы ведут себя по-разному. Для аудитории в России ориентироваться нужно в первую очередь на поведение отечественного поиска, а он клиентский рендеринг переваривает заметно осторожнее. Полагаться на то, что «где-то это работает», нельзя: работает там, где не ваша аудитория.

Помогу с продвижением: раскрутка сайта белыми методами — вывожу сайты в топ Яндекса белыми методами.

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

Что теряется, кроме текста

Отсутствие текста — самое очевидное, но не единственное следствие. Вместе с ним пропадает всё остальное.

• Ссылки. Если навигация собирается скриптом, робот не видит путей вглубь сайта. Внутренние разделы становятся недостижимыми, и весь каталог существует только для человека.
• Заголовки и описания страниц. Когда они подставляются скриптом после загрузки, в первом ответе стоит одно и то же значение для всех адресов — обычно название приложения. В выдаче это выглядит как сотни одинаковых строчек.
• Структурированные данные. Разметка цен, отзывов и характеристик, добавляемая динамически, чаще всего не учитывается, и расширенный вид в выдаче не появляется.
• Изображения. Отложенная загрузка, реализованная только через скрипт без обычной разметки, приводит к тому, что картинок для поиска не существует.
• Скорость по метрикам. Появление основного содержимого сдвигается на время выполнения скриптов, и показатели скорости ухудшаются даже там, где сайт субъективно быстрый.

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

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

1. Отключите выполнение скриптов в браузере и откройте свою страницу. То, что осталось на экране, примерно и есть то, с чем работает первая волна обхода. Пусто — диагноз поставлен.
2. Посмотрите исходный код страницы — именно исходный, а не итоговое состояние в инструментах разработчика. Найдите в нём поиском любой абзац своего текста и заголовок страницы. Не нашлись — их нет в ответе сервера.
3. Проверьте страницу через инструмент проверки в панели вебмастера. Он показывает содержимое так, как его получил робот, и это самый честный ответ.
4. Сравните число страниц на сайте с числом страниц в индексе. Разрыв в разы при исправной карте сайта — типичный признак проблем с отрисовкой.
5. Поищите в выдаче фрагмент своего текста в кавычках. Если система не находит текст, который на сайте точно есть, значит, она его не получила.
6. Проверьте, одинаковые ли заголовки у разных страниц в выдаче. Одинаковые — заголовки подставляются скриптом.

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

Способы решения и их цена

Вариантов несколько, и выбор зависит от того, что за сайт и на каком этапе он находится.

Способ	Как работает	Кому подходит
Серверный рендеринг	Сервер собирает готовую разметку и отдаёт её сразу, скрипт «оживляет» страницу после загрузки	Проекты с часто меняющимися данными: каталоги, личные кабинеты, витрины
Предварительная сборка страниц	Все страницы собираются заранее и лежат готовыми файлами	Сайты с редко меняющимся содержимым: услуги, блог, документация
Пререндер для роботов	Отдельный сервис собирает страницу и отдаёт готовую версию роботу	Быстрая заплатка на существующем приложении, когда переделка невозможна
Гибридный подход	Важные для поиска разделы собираются на сервере, интерфейсные части — в браузере	Большинство коммерческих проектов: разумный компромисс
Обычная разметка для контента	Текст и ссылки присутствуют в исходном ответе, скрипты добавляют интерактив поверх	Новые проекты — самый дешёвый вариант, если решить это на старте

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

Тему разбирал отдельно: «Сделали красивый сайт на Tilda — а Яндекс его в упор не видит».

Что делать, если сайт уже сделан

Ситуация типичная: приложение написано, деньги потрачены, переписывать никто не даст. Порядок действий такой.

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

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

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

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

Шаг пятый — договориться о регламенте. Дальше правило простое: любая новая функциональность проверяется на первый ответ сервера до выкатки. Иначе через полгода вы вернётесь в ту же точку с новыми разделами.

Как ставить задачу разработчику

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

Смежный материал по теме — «Робот видит ваш сайт совсем не таким, как вы: разрыв между картинкой в браузере и реальностью».

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

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

Каждый пункт этого списка проверяется за минуту и не допускает толкований. Именно поэтому его стоит включать в приёмку: спор «индексируется или нет» превращается в проверку по семи строчкам.

Частые ошибки при переходе на серверную сборку

Переход сам по себе проблему не решает, если сделать его невнимательно. Вот на чём спотыкаются чаще всего.

• Разное содержимое на сервере и в браузере. Сервер собрал одно, скрипт после загрузки перерисовал другое. Робот индексирует первое, человек видит второе, и сигналы расходятся.
• Заголовки страниц остались динамическими. Разметка собирается на сервере, а заголовок и описание по-прежнему подставляются скриптом. Половина проблемы остаётся.
• Потеря адресов при переезде. Структура адресов меняется, старые не переадресуются, накопленная история обнуляется. Это отдельная большая потеря, не связанная со скриптами.
• Ответ сервера двести на несуществующих страницах. Приложение отдаёт «всё в порядке» вместо ошибки, и в индекс уходят тысячи пустых адресов.
• Медленный сервер вместо медленного браузера. Сборка на сервере без кэширования превращает скорость ответа в новое узкое место.
• Отсутствие проверки после выкатки. Никто не смотрит на первый ответ после релиза, и регресс замечают через месяцы.

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

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

Как объяснить это разработчику, если он утверждает, что всё индексируется? Не спорьте словами, покажите факты. Откройте исходный код страницы и попробуйте найти в нём свой текст. Покажите разрыв между числом страниц и числом документов в индексе. Приведите результат проверки в панели вебмастера. Это проверяемые вещи, и после них дискуссия обычно заканчивается.

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

Через сколько после исправления вернётся трафик? Сначала растёт число страниц в индексе — это видно в течение двух-четырёх недель. Затем появляются показы по запросам, до которых сайт раньше не доходил. Позиции и трафик подтягиваются в течение двух-трёх месяцев, потому что документам нужно накопить историю. Мгновенного эффекта не будет, но динамика проиндексированных страниц покажет, что дело пошло, уже через месяц.

Что делать, если бюджета на переделку нет вообще? Начните с бесплатного: превратите поддельные переходы в настоящие ссылки, задайте уникальные заголовки и описания хотя бы на серверном уровне, проверьте, что каждая важная страница открывается по прямому адресу и отдаёт корректный ответ. Эти три вещи не требуют смены архитектуры и закрывают заметную часть проблемы. Полноценное решение планируйте на следующий этап развития сайта.

Коротко

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

Если не уверены, что именно видит робот на вашем сайте, и хотите понять, во что обойдётся исправление, приходите на SEO-консультацию: посмотрим первый ответ сервера по ключевым шаблонам, оценим масштаб потерь и составим список правок в порядке отдачи.