Индексация сайта на JavaScript: чтобы поисковик видел то же, что человек

Выполняет, но в два прохода. Первый забирает разметку, второй ставит адрес в очередь на выполнение сценариев и срок этой очереди не публикуется. На сайте из десятка страниц разницу вы не заметите; в нескольких тысячах она превращается в месяцы, в течение которых часть каталога просто не существует для выдачи. Вторая часть ответа важнее: Google – не единственный читатель. Bing, агенты ассистентов, парсеры маркетплейсов и сервисы, строящие предварительный просмотр ссылки в мессенджере, в основном сценарии не выполняют вообще.

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

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

Спросить страницу дважды – как браузер и как поисковый агент – и положить ответы рядом. В измеренном нами сайте клиники браузер получает оболочку на 3,0 КБ, у которой нет ни заголовка, ни описания, а поисковый бот – собранный документ на 126 КБ. Деталь, сбивающая с толку: боту при этом соответствуют быстрее, чем браузеру — 145 мс против 198 мс, потому что готовый документ уже лежит, а оболочку еще нужно собрать. Из браузера все выглядит безупречно, и именно поэтому проблему находят поздно.

Часто да, но не всегда. Этот статус означает, что бот адрес забрал и решил пока не класть в индекс. Причины две большие группы: в ответе не было контента (это наш случай) или контент был, но выглядит слишком похожим на соседние страницы или слишком пустым по существу. Различается это за минуту: посмотрите в инструменте проверки URL, что видел бот. Если там оболочка без текста – вопрос к рендерингу. Если текст есть, а индексации нет – вопрос уже к контенту, и это другая услуга.

Влияет на возможность не на результат. Агенты читают то, что отдано в разметке сразу; если там пусто, вас процитировать нечем. Но никаких обещаний по поводу упоминаний мы не даем: правил отбора не публикует ни один вендор, гарантий нет ни у кого, а объем переходов оттуда пока мал по сравнению с обычным поиском. Это работа на опережение с неизвестной отдачей, и мы говорим о ней именно так. Отдельно о блокировке тренировочных агентов: оно не убирает ваш контент из уже обученных моделей.

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

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