![](https://habrastorage.org/webt/_8/pz/fa/_8pzfanz6vtgpjirwd_qnpzojpu.png)
Понимание того, как поисковые системы изучают, рендерят и индексируют веб-страницы, имеет решающее значение для оптимизации сайтов под поисковые системы. По мере изменений в работе поисковых систем (например, 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 использует собственные внутренние эвристики для определения, когда кэшированные ресурсы остаются актуальными, а когда их необходимо обновить.
![](https://habrastorage.org/webt/jn/wj/yt/jnwjytdrla__g1inie1vowrw5y0.png)
Современный процесс индексации 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 часов
![](https://habrastorage.org/webt/6g/0u/ya/6g0uyalsk85re9b7ccsd1tot-mg.png)
Несмотря на то, что некоторые страницы сталкивались со значительными задержками (до ~18 часов в 99-м процентиле), это были всего лишь исключения.
Более того, результаты исследования показали, что 25-й процентиль страниц был отрендерен в течение 4 секунд после первоначального анализа, что ставит под сомнение представление о длительной "очереди" рендеринга.
Мы также наблюдали интересные закономерности, связанные с тем, насколько быстро Google рендерит URL-адреса с параметрами запроса (?param=xyz):
Тип URL | 50-й процентиль | 75-й процентиль | 90-й процентиль |
---|---|---|---|
Все 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-канале ↩
gmtd
Ничего не понял
Всю статью расхваливали возможности Гугла по работе с JS, и тут:
Откуда у CSR взялась оценка "плохо"?
gmtd
И, главное, сразу после:
Тонкие, блин.
Голимая реклама Vercel-а самого себя и своего Next-a