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

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

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

Чтобы разобраться с этими убеждениями, мы объединились с MERJ, ведущей консалтинговой компанией в области SEO и управления данными, и провели эксперименты по изучению поведения поискового бота Google. Мы проанализировали более 100 000 запросов Googlebot на различных сайтах, чтобы протестировать и подтвердить (или опровергнуть) его возможности, связанные с SEO.

Давайте рассмотрим, как эволюционировал рендеринг Google. Затем проанализируем наши выводы относительно реального влияния клиентского JS на современные веб-приложения.

❯ Эволюция возможностей рендеринга Google

За прошедшие годы способность Google изучать и индексировать веб-контент претерпела значительные изменения. Понимание этих изменений важно для осознания текущего состояния SEO для современных веб-приложений.

До 2009 года: ограниченная поддержка JS

На заре поисковых систем Google в основном индексировал статический HTML-контент. Контент, созданный с помощью JS, был почти невидим для поисковых систем, что приводило к необходимости использования статического HTML.

2009–2015: схема AJAX-индексации

Google создал схему AJAX-индексации (AJAX crawling scheme), позволяющую сайтам предоставлять HTML-снимки (HTML snapshots) динамически генерируемого контента. Это было временным решением, требующим от разработчиков создания отдельных, поддающихся индексации версий веб-страниц.

2015–2018: начало выполнения JS

Google начал рендерить страницы с использованием браузера Chrome без графического интерфейса. Значительный шаг вперед. Однако старая версия браузера была ограничена в обработке современных возможностей JS.

2018-настоящее время: современные возможности рендеринга

На данный момент Google использует современную версию Chrome для рендеринга веб-страниц. Ключевые аспекты текущей системы включают:

Универсальный рендеринг: теперь Google старается отрендерить все HTML-страницы, а не только выборочное подмножество.
Актуальный браузер: Googlebot использует последнюю стабильную версию Chrome/Chromium, поддерживающую современные возможности JS.
Рендеринг без сохранения состояния: каждый рендеринг страницы происходит в новой сессии браузера, без сохранения куки или состояний из предыдущих рендерингов. Обычно Google не кликает по элементам на странице, таким как вкладки или баннеры куки.
Экранирование: Google запрещает показывать различный контент пользователям и поисковым системам, чтобы манипулировать рейтингами. Избегайте кода, который изменяет содержимое на основе User-Agent (устройства пользователя). Вместо этого оптимизируйте приложение на основе рендеринга без сохранения состояния для Google и реализуйте персонализацию с помощью методов с сохранением состояния.
Кэширование ресурсов: Google ускоряет рендеринг веб-страниц за счет кэширования ресурсов, что практично для страниц, использующих общие ресурсы, и для повторного рендеринга одной и той же страницы. Вместо использования заголовков HTTP Cache-Control, служба рендеринга веб-сайта Google использует собственные внутренние эвристики для определения, когда кэшированные ресурсы остаются актуальными, а когда их необходимо обновить.

Современный процесс индексации Google выглядит примерно так.

Теперь, когда мы лучше понимаем возможности Google, связанные с SEO, рассмотрим некоторые распространенные мифы.

❯ Методология

Для проверки распространенных мифов мы провели исследование, используя инфраструктуру Vercel и технологию Web Rendering Monitor (WRM) от MERJ. Наш фокус был сосредоточен на сайте nextjs.org с дополнительными данными из monogram.io и basement.io, охватывающими период с 1 по 30 апреля 2024 года.

Сбор данных

На указанные сайты был внедрен специальный промежуточный слой (Edge Middleware), чтобы перехватывать и анализировать запросы от поисковых ботов. Этот слой позволил:

Выявлять и отслеживать запросы от различных поисковых систем и AI-агентов (при этом никакие пользовательские данные не использовались).
Встраивать легковесную JS-библиотеку в HTML-ответы для ботов.

Данная библиотека, срабатывая по завершении рендеринга страницы, отправляла на специальный сервер следующую информацию:

URL страницы
уникальный идентификатор запроса (для сопоставления с серверными логами)
временную отметку завершения рендеринга (рассчитывалась на основе времени получения запроса библиотекой на сервере)

Анализ данных

Сопоставив информацию из серверных логов о первоначальных запросах с данными, полученными от посредника, мы смогли:

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

Объем данных

Основное внимание было уделено данным, полученным от Googlebot, так как это обеспечило нам самую крупную и надежную базу. Анализ охватил свыше 37 000 отрендеренных HTML-страниц, что позволило сформировать прочную основу для дальнейших выводов.

Мы также продолжаем сбор информации об обработке контента другими поисковыми системами, включая AI-агенты наподобие OpenAI и Anthropic, и планируем поделиться этими результатами в будущем.

Далее мы рассмотрим каждый миф, предоставляя при необходимости дополнительные сведения о методологии.

❯ Миф №1. Google не может отрендерить контент, генерируемый JS

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

Исследование

Чтобы проверить способность Google обрабатывать контент, генерируемый с помощью JS, мы сосредоточились на нескольких ключевых аспектах:

Совместимость с JS-фреймворками: мы проанализировали взаимодействие Googlebot с Next.js на основе данных с nextjs.org — сайта, использующего сочетание предварительного рендеринга статического контента, серверного и клиентского рендеринга.
Индексирование динамического контента: мы изучили страницы nextjs.org, загружающие контент асинхронно через вызовы API. Это позволило определить, может ли Googlebot обрабатывать и индексировать контент, отсутствующий в первоначальном HTML-ответе.
Потоковый контент через React Server Components (RSC): аналогично предыдущему пункту, значительная часть nextjs.org построена с использованием Next.js App Router и RSC. Мы отслеживали, как Googlebot обрабатывает и индексирует контент, поступающий на страницу постепенно.
Успешность рендеринга: мы сравнили количество запросов Googlebot в наших серверных логах с количеством успешных сигналов о завершении рендеринга. Это дало представление о доле проиндексированных страниц, которые были полностью отрендерены.

Выводы

Из более чем 100 000 запросов Googlebot на nextjs.org (исключая ошибки и неиндексируемые страницы), 100% HTML-страниц были успешно отрендерены, включая страницы со сложными JS-взаимодействиями.
Весь контент, загружаемый асинхронно через API-вызовы, был успешно проиндексирован, что демонстрирует способность Googlebot обрабатывать динамически загружаемый контент.
Фреймворк Next.js, построенный на React, был полностью отрендерен Googlebot, что подтверждает совместимость бота с современными JS-фреймворками.
Контент, поступающий потоково через RSC, также был полностью отрендерен, что свидетельствует об отсутствии негативного влияния потоковой передачи данных на SEO.
Google пытается отрендерить все HTML-страницы, которые он видит, а не только некоторые страницы с "тяжелым" JS.

❯ Миф №2. Google по-разному обрабатывает страницы, содержащие JS

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

Исследование

Чтобы проверить, действительно ли Google по-разному обрабатывает страницы с JS, мы применили несколько методов:

Тест с CSS @import: мы создали тестовую страницу без JS, но с CSS-файлом, который подключает (@imports) второй CSS-файл (он будет загружен и появится в серверных логах только при разборе первого CSS-файла). Сравнив это поведение со страницами с JS, мы могли проверить, обрабатывает ли Google CSS-файлы по-разному.
Обработка кодов состояния и мета-тегов: мы разработали Next.js-приложение с промежуточным слоем для тестирования различных HTTP-кодов состояния. Анализ был сосредоточен на том, как Google обрабатывает страницы с разными кодами (200, 304, 3xx, 4xx, 5xx) и с мета-тегами noindex. Это помогло понять, обрабатываются ли страницы с интенсивным использованием JS в этих сценариях по-разному.
Анализ сложности JS: мы сравнили рендеринг Google на страницах nextjs.org с разными уровнями сложности JS — от минимального до высокодинамичного с обширным клиентским рендерингом. Также рассчитали и сравнили время между первоначальным анализом и завершенным рендерингом, чтобы определить, влияет ли более сложный JS на продолжительность очередей рендеринга (rendering queues) или время обработки.

Выводы

Наш тест с импортом дополнительного файла CSS подтвердил, что Google успешно рендерит страницы независимо от того, содержат они JS или нет.
Google рендерит все HTML-страницы с кодом состояния 200, независимо от наличия JS. Страницы с кодом 304 рендерятся на основе оригинального контента 200-го кода. Страницы с кодами 3xx, 4xx и 5xx не рендерятся.
Страницы с мета-тегом noindex в исходном HTML не рендерятся, независимо от JS. Удаление тега noindex на клиентской стороне неэффективно для SEO, так как Google не рендерит страницу, если тег присутствует в начальном HTML-ответе.
Мы не обнаружили существенной разницы в эффективности рендеринга Google страниц с различной сложностью JS. На масштабах nextjs.org мы не выявили корреляции между сложностью JS и задержкой рендеринга. Однако более сложный JS на гораздо более крупном сайте может ухудшать эффективность индексации.

❯ Миф №3. Очередь рендеринга и временные задержки существенно влияют на SEO

Многие специалисты по SEO полагают, что страницы с большим объемом JS сталкиваются со значительными задержками индексации из-за очереди рендеринга. Наше исследование дает более четкое представление об этом процессе.

Исследование

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

Задержки рендеринга: мы проанализировали разницу во времени между первоначальным анализом страницы Google и завершением ее рендеринга, используя данные более чем 37 000 страниц на nextjs.org.
Типы URL: мы проанализировали время рендеринга для URL-адресов, содержащих и не содержащих строки запроса (query string), а также для различных разделов nextjs.org (например, /docs, /learn, /showcase).
Шаблоны частоты: мы исследовали, как часто Google повторно рендерит страницы и существуют ли закономерности в частоте рендеринга для различных типов контента.

Выводы

Распределение задержек рендеринга выглядит следующим образом:

50-й процентиль (медиана): 10 секунд.
75-й процентиль: 26 секунд
90-й процентиль: ~3 часа
95-й процентиль: ~6 часов
99-й процентиль: ~18 часов

Несмотря на то, что некоторые страницы сталкивались со значительными задержками (до ~18 часов в 99-м процентиле), это были всего лишь исключения.

Более того, результаты исследования показали, что 25-й процентиль страниц был отрендерен в течение 4 секунд после первоначального анализа, что ставит под сомнение представление о длительной "очереди" рендеринга.

Мы также наблюдали интересные закономерности, связанные с тем, насколько быстро Google рендерит URL-адреса с параметрами запроса (?param=xyz):

Тип URL	50-й процентиль	50-й процентиль	50-й процентиль
Все URL	10 секунд	26 секунд	~3 часа
URL без строки запроса	10 секунд	22 секунд	~2,5 часа
URL со строкой запроса	13 секунд	31 минута	~8,5 часа

Эти данные свидетельствуют о том, что Google по-разному обрабатывает URL-адреса с параметрами запроса, не влияющими на содержимое. Так, на nextjs.org страницы с параметрами ?ref= демонстрировали более длительные задержки рендеринга, особенно на высоких процентилях.

Кроме того, мы заметили, что часто обновляемые разделы, вроде /docs, имели меньшее медианное время рендеринга по сравнению с более статичными разделами. Например, страница /showcase, несмотря на частые ссылки на нее, показывала более длительное время рендеринга, что может указывать на замедление повторного рендеринга Google для статичных страниц.

❯ Миф №4. Сайты с большим количеством JS отличаются более медленной скоростью обнаружения страниц поисковыми ботами

Устойчивое мнение в сообществе SEO специалистов: веб-сайты с большим объемом JS, особенно использующие клиентский рендеринг (CSR), такие как одностраничные приложения (SPA), сталкиваются с более медленным обнаружением страниц поисковой системой Google. Наши исследования опровергают этот миф.

Исследование

Для изучения влияния JS на обнаружение страниц были проведены некоторые тесты:

Сравнили скорость обнаружения ссылок при различных подходах к рендерингу — серверном, статическом и клиентском (на примере nextjs.org).
Протестировали выполнение кода JS, который не используется на странице: мы добавили на страницу /showcase JSON-объект, похожий на полезную нагрузку React Server Component (RSC), содержащий ссылки на новые, ранее неизвестные страницы, чтобы проверить, сможет ли Google обнаруживать ссылки в неиспользуемом JS.
Сравнили время: мы отслеживали, насколько быстро Google индексирует новые страницы, на которые ссылались различными способами: в HTML-ссылках, в клиентском рендеринге и в неиспользуемой полезной нагрузке JS.

Выводы

Google одинаково успешно находит и индексирует ссылки на полностью отрендеренных страницах, вне зависимости от метода рендеринга.
Google способен находить ссылки даже в неотрендеренных данных, таких как полезная нагрузка серверных компонентов React.
Как в исходном, так и в отрендеренном HTML, Google обрабатывает содержимое, определяя строки, похожие на URL-адреса. При этом он использует текущий хост и порт в качестве базы для относительных ссылок. Стоит отметить, что Google не обнаружил закодированный URL (https%3A%2F%2Fwebsite.com) в нашей подобной RSC нагрузке, что свидетельствует о строгом подходе поисковика к разбору ссылок.
Источник и формат ссылки (например, в теге <a> или встроенная в JSON-нагрузку) не влияют на приоритет ее индексирования Google. Приоритет индексирования оставался последовательным, независимо от того, была ли ссылка обнаружена при первичном индексировании или после рендеринга.
Хотя Google эффективно индексирует ссылки на страницах с клиентским рендерингом, страницы с серверным или частичным рендерингом имеют небольшое преимущество в скорости первичного обнаружения.
Google различает процессы обнаружения ссылок и оценки их ценности для ранжирования, последняя происходит после полного рендеринга страницы.
Наличие актуальной карты сайта (sitemap.xml) значительно снижает или устраняет различия в скорости индексации между разными подходами к рендерингу.

❯ Общие выводы и рекомендации

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

Выводы

Совместимость с JS: Google эффективно обрабатывает и индексирует JS-контент, включая сложные одностраничные приложения (SPA), динамически загружаемый контент и потоковые данные.
Единый подход к рендерингу: нет принципиальных различий в том, как Google обрабатывает страницы с большим объемом JS и статические HTML-страницы. Все они проходят процесс рендеринга.
Очередь рендеринга: хотя очередь рендеринга существует, ее влияние менее значимо, чем принято считать. Большинство страниц обрабатываются в считаные минуты, а не в течение дней или недель.
Обнаружение страниц: сайты с большим объемом JS, включая одностраничные приложения (SPA), ничего не теряют в плане их индексации Google.
Своевременность контента: важно добавлять определенные элементы (например, теги noindex) вовремя, поскольку Google может не учесть изменения, вносимые на стороне клиента.
Определение ценности ссылок: Google разграничивает обнаружение ссылок и определение их ценности, при этом последнее происходит после полного рендеринга страницы.
Приоритизация рендеринга: процесс рендеринга Google не строго подчиняется принципу "первым вошел — первым вышел" (first-in-first-out, FIFO). Факторы, такие как "свежесть" контента и частота обновлений, влияют на приоритизацию больше, чем сложность JS.
Производительность рендеринга и краулинговый бюджет: несмотря на способность Google эффективно обрабатывать страницы с большим объемом JS, этот процесс требует больше ресурсов по сравнению со статическими HTML-страницами, как со стороны владельцев сайтов, так и со стороны самого Google. Для крупных сайтов (10 000+ уникальных и часто обновляемых страниц) это может негативно сказываться на бюджете краулинга. Оптимизация производительности приложения и минимизация избыточного JS могут ускорить процесс рендеринга, повысить эффективность анализа и, как следствие, позволить Google индексировать большее количество страниц.

Рекомендации

Активно использовать JS: внедряйте JS-фреймворки для улучшения пользовательского опыта и разработки, но при этом сохраняйте фокус на производительности и следуйте рекомендациям Google по ленивой загрузке.
Обработка ошибок: внедряйте механизмы обработки ошибок в приложениях React для предотвращения сбоев целых страниц из-за ошибок отдельных компонентов.
Ключевые SEO-элементы: используйте серверный рендеринг или статическую генерацию для ключевых SEO-тегов и основного контента, чтобы гарантировать их наличие в начальном HTML-ответе.
Управление ресурсами: убедитесь, что критически важные ресурсы для рендеринга (API, файлы JS, CSS) не заблокированы в robots.txt.
Обновление контента: для контента, требующего быстрой повторной индексации, обеспечьте отражение изменений в серверном HTML, а не только в клиентском JS. Рассмотрите применение инкрементальной статической регенерации, чтобы поддерживать актуальность контента при сохранении оптимальных показателей SEO и производительности.
Внутренние ссылки и структура URL: выстраивайте четкую, логичную систему внутренних ссылок. Используйте реальные HTML-ссылки (<a href="...">) для важных навигационных элементов вместо клиентской JS. Это поможет как пользователям, так и эффективности индексации поисковиками, снижая задержки рендеринга.
Карты сайта: используйте и регулярно обновляйте карты сайта. Для крупных сайтов или сайтов с частыми обновлениями применяйте тег <lastmod> в XML-картах, чтобы направлять процессы анализа и индексации Google. Обновляйте <lastmod> только при существенных изменениях контента.
Мониторинг: воспользуйтесь инструментами Google Search Console — URL Inspection Tool и Rich Results Tool, чтобы оценить, как Googlebot воспринимает и отображает ваши веб-страницы. Отслеживайте статистику анализа, чтобы убедиться в отсутствии неожиданных проблем с выбранной стратегией рендеринга.

❯ Применение полученных знаний

Можно отметить следующие различия между стратегиями рендеринга в контексте возможностей Google:

Возможность	SSG	ISR	SSR	CSR
Эффективность анализа: как быстро и эффективно Google может получать доступ, рендерить и извлекать веб-страницы	Отлично	Отлично	Очень хорошо	Плохо
Обнаружение: процесс обнаружения новых URL для анализа*	Отлично	Отлично	Отлично	Средне
Полнота рендеринга (ошибки, провалы и др.): как точно и полно Google может загружать и обрабатывать веб-страницы без ошибок	Отлично	Отлично	Отлично	Возможен провал**
Время рендеринга: сколько времени занимает полный рендеринг и обработка веб-страниц	Отлично	Отлично	Отлично	Плохо
Оценка структуры ссылок: как Google анализирует ссылки для изучения архитектуры веб-сайта и важности страниц	После рендеринга	После рендеринга	После рендеринга	После рендеринга (ссылки могут отсутствовать при провале рендеринга)
Индексация: процесс хранения и организации контента сайта	Отлично	Отлично	Отлично	Возможен провал индексации при провале рендеринга

* Использование актуальной карты сайта (sitemap.xml) существенно сокращает или даже устраняет различия во времени обнаружения между разными моделями рендеринга.** Согласно нашим исследованиям, рендеринг в Google, как правило, проходит без ошибок. Когда возникают проблемы, они обычно связаны с заблокированными ресурсами, указанными в файле robots.txt, или крайними случаями.

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

В конце концов, скорость загрузки страницы по-прежнему является фактором ранжирования, поскольку система ранжирования пользовательского опыта Google оценивает производительность вашего сайта на основе показателей Core Web Vitals.

Кроме того, скорость загрузки приложения напрямую связана с хорошим пользовательским опытом — каждые 100 мс сэкономленного времени загрузки соответствуют 8% росту конверсии на сайте. Меньшее количество пользователей, покидающих страницу, означает, что Google рассматривает ее как более релевантную. Производительность имеет мультипликативный эффект; миллисекунды важны.

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩

📚 Читайте также:

Frontender`s Spectre

[developedbyed] 6 Database Concepts Your Should Know

Создание Умной Документации на основе Встраиваний OpenAI (Деление на фрагменты, Индексация и Поиск)

Как Google обрабатывает JavaScript в процессе индексации веб-страниц