JavaScript SEO: актуальные сведения и практики

Опубликовано: 26.01.2024

Обновлено: 04.08.2026

JavaScript SEO — это дисциплина на стыке веб-разработки и поисковой оптимизации, которая решает ключевую задачу: как сделать контент, выводимый средствами JavaScript, одинаково доступным для поисковых роботов и пользователей. Традиционные методы SEO, рассчитанные на статический HTML, здесь не работают: контент может подгружаться асинхронно, маршрутизация происходит на клиенте, а интерактивность требует выполнения тяжёлых скриптов. Это порождает целый спектр вызовов — от правильного выбора стратегии рендеринга (SSR, SSG, CSR или гибридных подходов) до контроля над временем загрузки, гидратацией и поведением ботов.

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

Как JS влияет на SEO

Сайты, сделанные либо целиком на JS, либо активно использующие его возможности – это суровая реальность на годы вперед. Изначально разработчики использовали средства JS для увеличения интерактивности сайтов. HTML создаёт каркас. CSS определяет внешний вид. JavaScript позволяет контролировать и изменять HTML и CSS по запросу пользователя: развернуть скрытый текстовый блок, подгрузить дополнительные данные и т.п.

Использование JS влияет на два жизненно важных аспекта вашего веб-сайта:

• Возможность полноценно индексировать контент
• Производительность (скорость загрузки и быстродействие)

Сложность и ресурсоемкость JavaScript усложняет сканирование и индексацию страниц сайта поисковыми системами. Чрезмерное использование средств JS и ошибочные практики могут иметь неприятные последствия для продвижения сайта в поиске.  Поисковые системы просто не могут сразу получить доступ к контенту, а значит – и оценить его.

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

Оптимизация JavaScript необходима, если вы заботитесь о SEO вашего сайта и развитии бизнеса.

JavaScript: плохо или хорошо для SEO

На этот вопрос невозможно ответить однозначно.

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

JavaScript является важной составляющей современных сетевых технологий так же, как HTML и CSS. Благодаря его средствам сайт получает уникальную технологию непрерывного обновления страниц. Вот почему при логической оптимизации JavaScript может предоставить множество преимуществ вашему веб-сайту, особенно связанных с пользовательским опытом (UX).

Например, вы можете использовать сторонние торговые платформы для постоянного обновления обменных курсов в режиме реального времени. Как реализовать подобное без JavaScript? Обновлять данные вручную?

JavaScript может использоваться для создания таких элементов веб-сайта и типов контента, как:

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

и т.п.

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

Экономические аспекты сканирования JS-контента

Когда речь идёт о “краулинговом бюджете” нужно понимать, что понимается буквальный бюджет: деньги, выделяемые поисково-рекламной системой на сканирование и обработку данных из интернета. Рендеринг JS – затратная операция, а любые затраты должны быть обоснованы. Если контент, который получает робот-краулер, не приносит поисковой системе достаточной выгоды, сайт будет неминуемо оценен как недостаточно качественный.

Технически робот может долго ждать ответа сервера, может справиться с достаточно сложной и “тяжелой” версткой, перегруженной неоптимизированными и избыточными скриптами, но для этого поисковой системе нужны особые причины: высокий пользовательский спрос, отсутствие конкуренции, добавочная информационная ценность (UIG). При их отсутствии более вероятный сценарий подразумевает сокращение лимитов на обход сайта и снижение его в ранжировании по этой причине.

Как гуглобот читает и отображает веб-сайты на JavaScript

Итак, JavaScript может усложнить работу поисковым роботам. Вот как это происходит:

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

Между тем, при рендеринге JavaScript многое может произойти не так. Поскольку весь процесс усложняется с использованием JavaScript, надо учитывать следующее:

• Рендеринг JavaScript прямо влияет на лимиты сканирования вашего сайта.
• Анализ, компиляция и запуск файлов JavaScript отнимает временные и вычислительные ресурсы у посетителей сайта.

Мобильный трафик сейчас – это 60-80% всего интернет-трафика. Сколько времени занимает анализ 1 МБ JavaScript на мобильном устройстве?

По данным Сэма Сакконе из Google : Samsung Galaxy S7 может сделать это за ~850 мс, а Nexus 5 — за ~1700 мс. После анализа JavaScript необходимо его скомпилировать и откалибровать, что занимает дополнительное время. Каждая секунда имеет значение.

• Контент веб-сайта с большим количеством JavaScript не может быть проиндексирован до тех пор, пока веб-сайт не будет полностью отрисован.
• Рендеринг JS в настоящий момент проводится позже сканирования HTML. Формально представители Google заявляли о технической задержке в несколько минут. Фактически рендеринг будет проведен только в том случае, если поисковая система выделит на это дополнительные ресурсы – а она может их не выделить вообще.
• Процесс рендеринга может занять больше времени, чем обычно, что влияет на процесс поиска новых ссылок, а значит, и полноценного сканирования сайта.

На веб-сайтах с большим количеством JS Google не может найти ссылки до рендеринга.

Сканирование JavaScript

Использование JavaScript усложняет процесс обхода сайта роботами-краулерами. Почему?

• Неоптимизированный JavaScript может не позволить поисковой системе находить и получать доступ ко всем вашим страницам. Например, благодаря тому, что внутренняя перелинковка будет для поисковых роботов технически недоступна.
• Если робот не получает доступ к основному контенту URL, выводимому средствами JS, он не может понять, о чем страница.
• Роботу Google становится сложнее понять, как ваши страницы связаны между собой.

Есть исследования, доказывающие, что на обход сайта, реализованного средствами JS, требуется в 9 раз больше времени в сравнении с сайтом на чистом HTML. На конкретный объём времени тут влияет множество факторов, но надо понимать, что в любом случае времени потребуется кратно больше.

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

Минимизация ресурсов, затрачиваемых на рендеринг JS – одна из возможностей значительно увеличить краулинговый бюджет.

JS-контент и ИИ-агенты

На 2026 год большинство ИИ-агентов не умеет работать с рендерингом JS. Это означает, что всё, что выводится в браузере, а не получается по запросу сервера в виде HTML-контента, не будет им доступно. Если речь идёт о достаточно сложном контенте (например, коммерческих посадочных страницах, где данные обновляются средствами JS), ChatGPT или Gemini этого не увидит. На что это влияет? – Прежде всего на соответствие разветвленным запросам (query fan-out), которые в коммерческой нише могут подразумевать следующие подзапросы:

• цены на заданный продукт
• возможность сделать заказ
• вывод конкретных топонимов (Москва, Санкт-Петербург и т.п.)

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

В этом контексте требование выводить самые важные данные сразу, на уровне “сырого” HTML становится ещё более важным – и эта важность будет только возрастать по мере того, как ИИ-ассистенты будут становиться частью окружающей реальности.

Рендеринг

Есть несколько возможностей доставки ваших веб-страниц пользователям и системам поиска. Понимание этого момента имеет решающее значение, когда мы вообще говорим о SEO, а не только в контексте работы с JavaScript.

Можно использовать аналогию с кулинарией. Исходный HTML — это просто рецепт. Там есть список ингредиентов и инструкции. Но это вовсе не конечное блюдо.

Конечное блюдо – это DOM, сформированная в браузере конечная страничка после рендеринга каждого запланированного пикселя после полной загрузки.

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

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

Обсуждая, как поисковые системы могут сканировать, отображать и индексировать JavaScript, мы должны учитывать три основные концепции:

• рендеринг на стороне сервера (SSR)
• рендеринг на стороне клиента (CSR)
• инкрементальная статическая регенерация (ISR)

Их необходимо понимать каждому оптимизатору, который имеет дело с JavaScript. Разберем их подробнее.

Серверный рендеринг  (SSR)

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

Обычно у поисковых систем нет никаких проблем с контентом, сформированным средствами SSR. Однако может случиться так, что без руководства по SEO некоторым разработчикам будет сложно правильно реализовать SSR.

Рендеринг на стороне клиента (CSR)

Если используется рендеринг на стороне клиента (CSR), то браузер или поисковый робот получает «сырой» HTML либо с минимумом контента, либо вообще без него. После этого JS асинхронно загружает контент с сервера и обновляет ваш экран.

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

• Какой браузер Google в настоящее время использует для отображения веб-сайтов? Обычно для рендеринга используется постоянно обновленная версия Chromium, известная как «Вечнозеленый Гуглобот». Как правило, этот браузер поддерживает большинство актуальных функций JS, но далеко не все.
• Как другие поисковые системы читают веб-сайты, написанные на JavaScript? Google быстро совершенствует свою технологию обработки и индексации JavaScript, но надо учитывать, что другие поисковые системы и соцсети могут значительно отставать в этом отношении. Для примера, Яндекс научился более-менее полноценно обрабатывать JS только к лету 2022.

Инкрементальная статическая регенерация (ISR)

Инкрементальная статическая регенерация (ISR) — это гибридная стратегия рендеринга, которая объединяет молниеносную скорость статических страниц с гибкостью динамического обновления контента. В отличие от традиционной статической генерации (SSG), где для обновления даже одной страницы требуется полная пересборка всего сайта, ISR позволяет обновлять только те страницы, которые действительно изменились. Это особенно актуально для больших сайтов с тысячами страниц, где полная пересборка может занимать часы.

Механизм работы ISR построен на стратегии “stale-while-revalidate” (устаревшее-пока-пересоздается). Когда пользователь или поисковый робот запрашивает страницу, он мгновенно получает уже готовую закэшированную HTML-версию. Если при этом срок действия кэша истек (например, прошло заданное количество секунд), Next.js в фоновом режиме запускает процесс перегенерации этой конкретной страницы с актуальными данными. Пользователь при этом не испытывает задержек, а обновленная версия становится доступной для следующих посетителей. Обновление можно настроить как по времени (например, каждые 60 секунд), так и по требованию — через API при публикации нового контента в CMS.

Для SEO в 2026 году ISR решает главную дилемму: поисковики любят быстрые, предсказуемые статические страницы с полным HTML-кодом (что улучшает индексацию и Core Web Vitals), но при этом отдают предпочтение свежему контенту. ISR позволяет достичь и того, и другого. Страницы загружаются мгновенно с CDN, что напрямую влияет на такие показатели, как LCP и INP, а поисковые роботы всегда видят актуальную версию, так как перегенерация происходит в фоне, не блокируя ответ сервера.

ISR идеально подходит для сайтов с большим количеством “полустатических” страниц: интернет-магазинов с часто меняющимися ценами и остатками, блогов с регулярными публикациями, новостных порталов или программных SEO-страниц (PSEO), созданных по шаблону. Выбор подходящего интервала ревалидации (revalidate) зависит от того, насколько часто обновляется контент: для новостей это могут быть секунды, для блога — часы, а для справочных материалов — дни. ISR позволяет крупным сайтам оставаться быстрыми, актуальными и видимыми в поисковой выдаче без огромных затрат на инфраструктуру.

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

Что делать, если Google не может отобразить вашу страницу

Google может отобразить вашу страницу неожиданным образом.

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

• Временной лаг после запроса ресурсов не позволил гуглоботу получить все необходимые ресурсы. В реале гуглобот может ждать отклика сервера до 2 минут, так что формально проблема может быть только на уровне «Консоли».
• Во время рендеринга получились какие-то ошибки, либо робот не смог обработать JS.
• Вы блокируете доступ гуглобота к важным ресурсным файлам (включая JS).

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

Двухволновая индексация

В 2018 году представители Google подтвердили, что используют две волны индексации: сначала сканируется и индексируется контент, доступный в первичном «сыром» HTML, и лишь потом, после рендеринга JS – остальная часть контента, по мере выделения вычислительных ресурсов. Всегда – с задержкой.

Обусловлено это было сугубо материальными и техническими причинами, прежде всего – тратой дорогостоящих машинных ресурсов.

Начиная с 2019 было заявлено, что две волны индексации сближаются по времени, хотя и не сливаются. Google по-прежнему не может обеспечить обработку JS в реальном времени. Однако Мартин Сплитт неоднократно намекал или прямо утверждал, что концепция двух волн индексации – это уже слишком грубая и устаревшая метафора для актуальных процессов обработки JS гуглоботом.

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

Иными словами, всё, что попало в индекс, уже прошло рендеринг, в минимальной мере отстоящий по времени от момента сканирования.

Почему у поисковых систем могут возникнуть проблемы с JavaScript

Сканирование JS — непростая задача

В случае использования традиционных HTML-сайтов все просто и понятно, а весь процесс происходит молниеносно (на примере Google):

• Гуглобот загружает HTML-файл.
• Извлекает ссылки из исходного кода и может запросить данные по ним одновременно.
• Загружает файлы CSS.
• Отправляет все загруженные ресурсы в индексатор Google (Caffeine).
• Индексатор вносит страницу в индекс.

Хотя многие веб-сайты сталкиваются с проблемами индексации, даже несмотря на ограниченное использование JavaScript, все дополнительно усложняется, для веб-сайта на JS-фреймворках и с большим объёмом контента, выводимого средствами JS:

• Googlebot загружает HTML-файл.
• Не находит ссылки в исходном коде, поскольку они появляются только после выполнения JS.
• Робот загружает файлы CSS и JS.
• Робот Google должен использовать службу веб-рендеринга Google (часть индексатора, WRS) для анализа, компиляции и выполнения JavaScript.
• WRS извлекает данные из внешнего API, из баз данных и т. д.
• Индексатор может индексировать контент.
• Google может найти новые ссылки и автоматически добавить их роботом Googlebot. В случае с веб-сайтом HTML это второй шаг.

Робот Googlebot не работает как настоящий браузер

Рассмотрим тему веб-рендеринга. Робот Googlebot основан на новейшей версии Chrome. Это означает, что робот Googlebot использует текущую версию браузера для рендеринга страниц. Но это не совсем то же самое.

Гуглобот посещает веб-страницы так же, как пользователь, использующий браузер. Однако робот Googlebot не является обычным текстовым браузером Chrome. Известно, что для сканирования используется и “безголовый” (консольный) Chrome. Есть и другие отличия:

• Робот отклоняет запросы на разрешения (например, на автовоспроизведение видео, получение доступа к камере и т.п.).
• Файлы cookie, локальное и сеансовое хранилища очищаются при загрузке страницы. Если ваш контент основан на файлах cookie или других сохраненных данных, Google не будет его распознавать.
• Браузеры всегда загружают все ресурсы. Гуглобот может этого не делать.

Когда вы пользуетесь Интернетом, ваш браузер (Chrome, Firefox, Opera и т. д.) загружает все ресурсы (такие как изображения, скрипты, таблицы стилей), которые составляют веб-сайт, и собирает их воедино. Однако, поскольку Googlebot работает иначе, чем ваш браузер, его цель — просканировать весь Интернет и получить ценные ресурсы.

Всемирная паутина огромна, поэтому Google оптимизирует работу своих сканеров. Гуглобот иногда не загружает все ресурсы с сервера. Более того, робот Googlebot даже не посещает все страницы, которые ему встречаются.

Алгоритмы Google пытаются определить, необходим ли данный ресурс с точки зрения рендеринга. Если система решит, что ресурс не нужен – он не будет загружен. Google предупреждает об этом веб-мастеров в официальной документации.

• Робот Googlebot и его компонент службы веб-рендеринга (WRS) постоянно анализируют и идентифицируют ресурсы, которые не содержат необходимого содержания страницы и не могут получить такие ресурсы.
• Поскольку робот Googlebot не работает как настоящий браузер, Google может не загружать некоторые из ваших файлов JavaScript. Причина может заключаться в том, что его алгоритмы решили, что в этом нет необходимости с точки зрения рендеринга, или просто из-за проблем с производительностью (т. е. выполнение сценария заняло слишком много времени).
• Кроме того, рендеринг JS со стороны Google по-прежнему замедлен, хотя и стал намного быстрее в сравнении с 2017–2018 годов, когда приходилось ждать недели, пока Google обработает JavaScript).
• Если ваш контент требует, чтобы пользователь щелкнул, прокрутил или выполнил какое-либо другое действие для его загрузки на страницу, он не будет проиндексирован. Поисковые роботы не умеют прокручивать, кликать по кнопкам и выполнять другие действия как человек.
• И последнее, но не менее важное: у рендерера Google есть тайм-ауты. Если рендеринг вашего скрипта займет слишком много времени, Google может его пропустить.

Основные проблемы с обработкой JS

• Закрыт доступ к файлам JS в robots.txt. Если не разрешить доступ, поисковые системы не получат доступа к JS-контенту и не смогут правильно отрисовать адаптивный шаблон. А это значит, что сайт будет сочтен не оптимизированным для мобильных устройств.
• Пагинация, реализованная на JS-ссылках или прокрутке страницы. Роботы ходят по ссылкам, роботы не умеют прокручивать страницу или нажимать на кнопки. Предоставьте роботам полноценные HTML-ссылки на страницы пагинации и контентные блоки, подгружаемые средствами JS.
• Избегайте редиректов, реализуемых средствами JS. Это может быть удобно, но на объёмах вы будете множить проблемы со структурой сайта. Робот должен выполнить JS, чтобы обнаружить редирект. А это означает дополнительные ресурсы, которых может не оказаться. Решайте вопросы редиректов на уровне сервера.
• Откажитесь от подгрузки важного контента средствами AJAX. Если вы используете вкладки – ограничьтесь CSS, чтобы скрыть на время какие-то контентные блоки, уже загруженные с сервера. Робот не умеет кликать на кнопки, и не сможет подгрузить дополнительный контент с сервера.
• Откажитесь от использования динамического рендеринга. Существует практика, когда поисковому роботу предоставляется уже отрисованная версия HTML, а пользовательский браузер должен выполнить рендер самостоятельно. В 2023 году представители Google официально объявили такую практику неодобряемой и предложили предоставлять одну и ту же версию как поисковым роботам, так и посетителям-людям.

Гидратация (hydration) в контексте JavaScript SEO

Гидратация — это процесс, при котором статический HTML-код, полученный с сервера, “оживляется” на клиенте с помощью JavaScript: к DOM-элементам прикрепляются обработчики событий, и страница становится полноценным интерактивным приложением. Сервер отдаёт готовый HTML с контентом (это хорошо для SEO), а затем браузер загружает JavaScript и делает этот контент интерактивным — добавляет кликабельность, анимации, динамические обновления. Это ключевой этап для фреймворков вроде React, Vue, Svelte и Next.js.

Почему гидратация важна для SEO

Гидратация находится на пересечении двух требований:

Требование	Как гидратация помогает
Индексация	Сервер отдаёт готовый HTML, поэтому поисковые роботы видят контент сразу, без выполнения JavaScript
Пользовательский опыт	После гидратации страница становится интерактивной и удобной для пользователей

Без гидратации (чистый CSR — Client-Side Rendering) браузер получает пустой HTML-скелет, и контент появляется только после загрузки и выполнения JavaScript. Это плохо для SEO: поисковики могут не дождаться рендеринга или вообще не выполнить скрипты.

Основные проблемы гидратации для SEO

1. Hydration Mismatch (несоответствие гидратации)

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

• Использование window или localStorage на сервере (их там нет)
• Разные данные на сервере и клиенте (например, разные временные метки)
• Условный рендеринг, зависящий от клиентских условий

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

2. Замедление интерактивности (INP)

Гидратация выполняется в основном потоке браузера и может быть тяжёлой для CPU. Если JavaScript-бандл слишком большой, гидратация задерживается, что ухудшает Interaction to Next Paint (INP) — один из Core Web Vitals.

3. Задержки индексации

Даже если контент виден, большие объёмы JavaScript замедляют полную загрузку страницы. Это может откладывать индексацию новых страниц или обновлений контента.

Стратегии оптимизации гидратации

Прогрессивная гидратация (Progressive Hydration)

Компоненты гидратируются не все сразу, а постепенно, по мере необходимости. Не-critical элементы загружаются лениво (lazy loading). Это сокращает общее время загрузки и ускоряет появление интерактивности.

Частичная гидратация (Partial Hydration) / Архитектура “Островов” (Islands)

Гидратируются только те части страницы, которым действительно нужна интерактивность. Остальной контент остаётся статическим HTML. Такой подход используют фреймворки Astro, Qwik, Marko.

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

• Меньше JavaScript → быстрее загрузка
• Меньше работы для поисковых роботов
• Лучшие показатели Core Web Vitals

Code Splitting и Lazy Loading

Разбивайте JavaScript на небольшие чанки и загружайте только то, что нужно для текущей страницы.

Использование SSR/SSG

Server-Side Rendering (SSR) — сервер отдаёт полностью готовый HTML при каждом запросе.
Static Site Generation (SSG) — HTML генерируется на этапе сборки и отдаётся как статика.

Оба подхода дают поисковикам готовый контент без ожидания JavaScript.

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

Что делать	Чего избегать
Убедитесь, что серверный HTML полностью виден до гидратации	Не полагайтесь только на клиентский рендеринг для важного контента
Используйте onMounted() для кода, зависящего от браузера	Не используйте window или localStorage на сервере
Сериализуйте состояние на сервере и передавайте на клиент	Не генерируйте разные данные на сервере и клиенте
Тестируйте с отключённым JavaScript, чтобы видеть, что видят поисковики	Не перегружайте страницу тяжёлыми JS-бандлами
Проверяйте индексацию через URL Inspection в Search Console и Rich Results Test	Не игнорируйте предупреждения о hydration mismatch в консоли браузера

Гидратация — это мост между SEO-дружественным серверным рендерингом и богатой интерактивностью современных SPA. Сама по себе она не вредит SEO, но неправильная реализация может привести к:

• Индексации сломанных версий страниц
• Замедлению интерактивности
• Задержкам индексации

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

Лучшие практики JavaScript SEO

Итак, мы разобрали, как поисковые системы обрабатывают JavaScript к 2024 году и что изменилось за минувшие годы. Время рассмотреть некоторые из лучших практик, к которым должны стремиться SEO-специалисты и веб-мастера при оптимизации своих веб-сайтов на основе JS.

Лучшие практики JavaScript SEO включают в себя следующее:

• Разрешите поисковым роботам получить доступ ко всему необходимому контенту.
• Правильно реализовать пагинацию.
• Не выводите важные изображения средствами JS.
• Используйте рендеринг на стороне сервера (SSR).
• Оптимизируйте исходный HTML.

Давайте пройдем по этим пунктам более подробно.

Помогите роботам найти весь ваш контент

Поскольку робот Googlebot может сканировать и отображать контент JavaScript, нет причин блокировать ему доступ к ресурсам для подключения и рендеринга.

• Не блокируйте важные файлы JS в файле robots.txt. Добавьте разрешающую директиву Allow, чтобы позволить Google получать доступ, обрабатывать и взаимодействовать с вашим контентом
• Избегайте использования хэшей в URL-адресах, поскольку роботы не просканируют их
• Убедитесь, что поисковики могут увидеть всю вашу информацию в исходном коде страницы. Весь контент должен быть доступен без дополнительного взаимодействия со страницей (например, подгрузкой контента по нажатию кнопки).
• Не используйте перенаправления на уровне JS вместо серверных редиректов (301)

Правильная пагинация

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

В этом случае, поскольку поисковые роботы не умеют прокручивать страницу, они не доберутся до URL-адресов, подгружаемых при “бесконечной прокрутке”.

Многие веб-сайты используют нумерацию страниц, которая зависит от действия пользователя — клика. Кликать поисковые роботы тоже не умеют. Вместо этого следует реализовать нумерацию страниц, используя правильную ссылку <a href>. Единственный правильный способ указать роботу вторую страницу пагинации и найти ссылки на другие страницы – использовать стандартные ссылки <a href>.

Иными словами, просто используйте стандартные ссылки в соответствии с веб-стандартами, никак не связанные с действиями пользователя.

Помните, что стандартная реализация пагинации типа link rel=”next” больше не работает. В марте 2019 представители Google официально сообщили, что больше не применяют эту разметку.

Оптимизируйте вывод изображений

Если изображения являются важной частью вашего бренда (например, представление продуктов на веб-сайтах электронной коммерции), и вы хотите, чтобы их находили и индексировали, вам следует адаптировать их для поисковых систем.
добавьте изображения в соответствии со стандартами Интернета:

• Выводите на страницу изображения с помощью HTML-тега «src»
• Рассмотрите возможность использования встроенной отложенной загрузки изображений на уровне браузера (lazy-loading)

Если вы используете lazy-loading для изображений, убедитесь, что речь идёт только об отложенной отрисовке контента, но не об отложенной загрузке. Все ссылки на картинки и текстовый контент должны присутствовать в исходном HTML без необходимости выполнения JS.

Используйте рендеринг на стороне сервера (SSR)

Рендеринг на стороне сервера позволяет поисковым роботам и пользователям получать полностью обработанную HTML-версию вашего веб-сайта с вашего сервера.

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

Более того, рендеринг на стороне сервера также является рекомендуемым решением для отображения контента JavaScript в Google.

Оптимизируйте исходный HTML

Взгляните на исходный код страницы и DOM (объектную модель документа) и обратите особое внимание на:

• Критически важный для ранжирования контент
• Канонические теги,
• Структурированные данные, микроразметка
• Важные метатеги, такие как meta robots или теги hreflang
• Внутренняя перелинковка, реализуемая средствами JS

Бывает, что JS-контент не определяется визуально, и вы даже не заметите, что он есть. Однако он может изменить ваши метаданные «под капотом» и основной контент, что может привести к серьезным проблемам.

Резюме

Если вы используете JS ограниченно, не для вывода основного контента, то проблемы, как правило, нет. Однако если ваша страница работает как одностраничное приложение, или рендеринг JS кардинально меняет DOM – вопрос требует глубокого анализа.