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

В SEO‑сообществе сохранилось несколько старых убеждений про SEO и JavaScript:

1. Google не может распознать client‑side JavaScript.

2. Google по‑другому относится к страницам на JavaScript.

3. Очерёдность и время рендеринга существенно влияют на SEO.

4. На сайтах с большим количеством JavaScript страницы открываются медленнее.

Чтобы разобраться с этими утверждениями, Vercel в сотрудничестве с MERJ поэкспериментировали и изучили поведение Google при сканировании JS. Они проанализировали более 100 тыс. операций Googlebot на различных сайтах, чтобы проверить и удостовериться в SEO‑возможностях Google.

Методология исследования

В процессе использовались инфраструктура Vercel и технологии MERJ Web Rendering Monitor (WRM). Исследование проводилось с 1 по 30 апреля 2024 года на сайте nextjs.org с дополнительными данными с сайтов monogram.io и basement.io.

Сбор данных

На этих сайтах для перехвата и анализа запросов от ботов поисковых систем был установлен пользовательский Edge Middleware. Это промежуточное ПО позволило:

• идентифицировать и отслеживать запросы от различных поисковых систем и ИИ‑краулеров. Данные о пользователях в этот запрос не включались;

• вставлять лёгкую библиотеку JavaScript в HTML‑ответы для ботов.

В момент завершения рендеринга страницы библиотека JavaScript отправляла данные на долго работающий сервер, включая:

• URL‑адрес страницы;

• уникальный идентификатор запроса, чтобы сопоставить рендеринг страницы с обычными журналами доступа сервера;

• время завершения рендеринга — вычисляется по времени приёма запроса библиотекой JavaScript на сервере.

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

Сравнивая исходный запрос, содержащийся в журналах доступа к серверу, с данными, отправленными нашим промежуточным ПО на внешний сервер с beacon, мы можем:

• определить, какие страницы были успешно отображены поисковыми системами;

• рассчитать разницу во времени между первоначальным сканированием и завершённым рендерингом;

• проанализировать шаблоны обработки различных типов контента и URL‑адресов.

Объём данных

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

В настоящее время продолжается сбор данных о других поисковых системах, включая ИИ‑провайдеров, таких как OpenAI и Anthropic, и в будущем планируется рассказать о новых результатах.

В следующих разделах рассмотрим каждый миф и при необходимости приведём более подробную статистику.

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

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

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

На заре развития Google индексировал в основном статический HTML‑контент. Контент, созданный на JavaScript, был практически невидим для поисковых систем. Это привело к широкому использованию для SEO‑целей именно статического HTML.

2009–2015 годы: схема сканирования AJAX

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

2015–2018 годы: ранний рендеринг JavaScript

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

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

Сегодня Google использует для рендеринга обновлённую версию Chrome, идущую в ногу с новейшими веб‑технологиями. Ключевые аспекты текущей системы включают:

1. Универсальный рендеринг. Теперь Google пытается отобразить все HTML‑страницы, а не только их часть.

2. Современный браузер. Googlebot использует последнюю стабильную версию Chrome/Chromium, поддерживающую современные функции JS.

3. Stateless‑рендеринг. Каждый рендеринг страницы происходит в новой сессии браузера, не сохраняя cookie‑файлы или состояние предыдущих рендеров. Google, как правило, не переходит по элементам на странице, таким как содержимое вкладок или баннеры с куки.

4. Клоакинг. Google запрещает показывать пользователям и поисковым системам различный контент для манипулирования рейтингом. 

5. Кэширование ассетов. Google ускоряет рендеринг веб‑страниц за счёт кэширования ассетов, а это полезно для страниц с общими ресурсами и для повторных рендерингов одной и той же страницы. 

Вместо использования заголовков HTTP Cache‑Control служба веб‑рендеринга Google применяет собственную внутреннюю эвристику, чтобы определить, насколько свежи кэшированные ассеты и когда их нужно загрузить снова.

Чтобы лучше понять, на что способен Google, давайте рассмотрим некоторые распространённые мифы и то, как они влияют на SEO.

Миф №1: Google не умеет обрабатывать JavaScript‑контент

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

Тестирование идеи

Чтобы проверить способность Google отображать JavaScript‑контент, Vercel и MERJ сосредоточились на трёх ключевых аспектах:

1. Совместимость с JS‑фреймворками. Они проанализировали взаимодействие Googlebot с Next.js, используя данные с сайта nextjs.org, который использует сочетание статического пререндеринга, server‑side и client‑side‑рендеринга.

2. Индексирование динамического контента. Изучили страницы на nextjs.org, загружающие контент асинхронно через обращения к API. Это позволило определить, может ли Googlebot обрабатывать и индексировать контент, не присутствующий в первоначальном HTML‑ответе.

3. Потоковый контент через компоненты React Server Components (RSC). Как и в предыдущем случае, большая часть сайта nextjs.org построена с использованием Next.js App Router и RSC. Хорошо видно, как Googlebot обрабатывает и индексирует контент, постепенно передаваемый на страницу.

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

Результаты

1. Из более чем 100 тыс. запросов Googlebot, проанализированных на nextjs.org без учёта ошибок кода состояния и неиндексируемых страниц, 100% HTML‑страниц были полностью отрендерены, включая страницы со сложными JS‑функциями.

2. Весь контент, загружаемый асинхронно через API‑алгоритмы, был успешно проиндексирован, что демонстрирует способность Googlebot обрабатывать динамически загружаемый контент.

3. Next.js, фреймворк на основе React, был полностью отрендерен Googlebot, подтверждая совместимость с современными JavaScript‑фреймворками.

4. Потоковый контент через RSC также был полностью отрендерен, тем самым подтвердилось, что потоковая передача не оказывает негативного влияния на SEO.

5. Google пытается отобразить практически все HTML‑страницы, которые он сканирует, а не только подгруппу страниц с большим количеством JavaScript.

Миф №2: Google обрабатывает страницы с JavaScript по‑другому, не так, как те, где нет JS

Распространёным заблуждением является то, что Google применяет особые процессы или требования к страницам, содержащим JavaScript. Это исследование в сочетании с официальными заявлениями Google полностью опровергает этот миф.

Тестирование идеи

Чтобы проверить, действительно ли Google по‑разному относится к страницам, содержащим JS, Vercel и MERJ использовали несколько целевых подходов:

1. Тест CSS @import. Они создали тестовую страницу без JavaScript, но с CSS‑файлом, который @imports второй CSS‑файл. Второй файл загружался и отображался в логах сервера только после рендеринга первого CSS‑файла. Сравнивая это поведение со страницей с JS, авторы исследования могли проверить, обрабатывает ли рендерер Google CSS по‑разному с включённым JS и без него.

2. Обработка кода состояния и метатегов. В качестве промежуточного ПО авторы исследования разработали приложение Next.js для тестирования различных кодов состояния HTTP в Google. Анализ был сосредоточен на том, как Google обрабатывает страницы с различными кодами состояния (200, 304, 3xx, 4xx, 5xx) и страницы с метатегами noindex. Это помогло понять, по‑разному ли обрабатываются страницы, содержащие JavaScript, в этих сценариях.

3. Анализ сложности JavaScript. Сравнили поведение Google при рендере страниц с разным уровнем сложности JS на сайте nextjs.org. Сюда вошли страницы с минимальным количеством JS, страницы с умеренным уровнем интерактивности и высокодинамичные страницы с интенсивным client‑side‑рендерингом. В исследовании также рассчитали и сравнили время между первоначальным сканированием и завершённым рендерингом, чтобы понять, приводил ли более сложный JS к увеличению очередей рендеринга или времени обработки.

Результаты

1. Тест CSS @import подтвердил, что Google успешно рендерит страницы как с JS, так и без него.

2. Google отображает все HTML‑страницы со статусом 200 независимо от содержания JS. Страницы со статусом 304 отображаются с использованием содержимого оригинальной страницы со статусом 200. Страницы с другими ошибками 3xx, 4xx и 5xx не отображаются.

Коды ошибок HTTP: полный список ошибок сервера 

3. Страницы с метатегами noindex в исходном HTML‑ответе не отображались независимо от содержания JS. Удаление тегов noindex на стороне клиента неэффективно для SEO‑целей; если страница содержит тег noindex в исходном HTML‑ответе, она не будет отрисована, а JavaScript, удаляющий тег, не будет выполнен.

4. Авторы исследования не увидели существенной разницы в успешности рендеринга Google страниц с разным уровнем сложности JS. В масштабах nextjs.org также не обнаружили корреляции между сложностью JavaScript и задержкой рендеринга. Однако более сложный JS на гораздо более крупном сайте может повлиять на эффективность сканирования.

Миф №3: Очередь рендеринга и время очень важны с точки зрения SEO

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

Тестирование идеи

Чтобы выяснить влияние очерёдности и сроков рендеринга на SEO, проанализировали:

• задержки рендеринга. Авторы исследования изучили разницу во времени между первоначальным сканированием страницы Google и завершением её рендеринга, используя данные более 37 тыс. пар на сайте nextjs.org;

• типы URL. Проанализировали время рендеринга для URL со строками запросов и без них, а также для различных разделов nextjs.org (например, /docs, /learn, /showcase);

• частоту запросов. Проверили, как часто Google пересматривает страницы и есть ли закономерности в частоте рендеринга для разных типов контента.

Результаты

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

• 50‑й процентиль (медиана): 10 секунд

• 75‑й процентиль: 26 секунд

• 90‑й процентиль: ~3 часа

• 95‑й процентиль: ~6 часов

• 99‑й процентиль: ~18 часов

Удивительно, но 25‑й процентиль страниц отображался в течение 4 секунд после первоначального сканирования, что опровергает представление о длинной «очереди».

Хотя на некоторых страницах наблюдались значительные задержки (до ~18 часов в 99‑м процентиле), такие случаи были скорее исключением, чем закономерностью.

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

Миф №4: Сайты, перегруженные JavaScript, медленнее обнаруживаются Google

В SEO‑сообществе существует устойчивое мнение, что сайты с большим количеством JavaScript, особенно те, которые используют клиентский рендеринг (CSR), например одностраничные приложения (SPA), страдают от более медленного обнаружения страниц Google. Благодаря проведённому исследованию появилась новая информация.

Тестирование идеи

Чтобы изучить влияние JavaScript на обнаружение страниц, Vercel и MERJ:

• проанализировали обнаружение ссылок в различных сценариях рендеринга. Сравнивали скорость обнаружения и сканирования Google ссылок на страницах с серверным, статическим и client‑side‑рендерингом на сайте nextjs.org;

• протестировали нерендерируемые нагрузки на JavaScript. На страницу /showcase сайта nextjs.org был добавлен объект JSON, похожий на компонент React Server Component (RSC), содержащий ссылки на новые, ранее не обнаруженные страницы. Так проверили, может ли Google обнаружить ссылки в данных JavaScript, которые не были отображены;

• сравнили время обнаружения. Авторы отслеживали, как быстро Google обнаруживает и сканирует новые страницы, связанные различными способами: стандартные HTML‑ссылки, ссылки в клиентском рендеринге контента и ссылки в нерендерируемых JavaScript‑файлах.

Результаты

1. Google успешно обнаружил и проиндексировал ссылки на полностью отрендеренных страницах независимо от метода рендеринга.

2. Google может обнаруживать ссылки в неотрендеренных JavaScript‑данных на странице, таких как те, что находятся в компонентах сервера React или аналогичных структурах.

3. И в начальном, и в отрендеренном HTML Google обрабатывает контент, идентифицируя строки, которые выглядят как URL, используя текущий хост и порт в качестве основы для относительных URL. 

Google не обнаружил закодированный URL, то есть https%3A%2F%2Fwebsite.com, что говорит о том, что его парсинг ссылок очень строгий.

4. Источник и формат ссылки (например, в теге <a> или встроенный в JSON‑данные) не повлияли на то, как Google приоритизировал сканирование. Приоритет сканирования оставался постоянным независимо от того, был ли URL найден сначала или после рендеринга.

5. Хотя Google успешно обнаруживает ссылки на CSR‑страницах, эти страницы всё же необходимо сначала отрендерить. Страницы, отрендеренные на сервере, или частично предварительно отрендеренные страницы имеют небольшое преимущество в немедленном обнаружении ссылок.

6. Google по‑разному относится к обнаружению ссылок и оценке их ценности. Оценка ценности ссылки для архитектуры сайта и приоритезации сканирования происходит после полного рендеринга страницы.

7. Наличие обновлённой sitemap.xml значительно сокращает, если не устраняет, различия во времени обнаружения между различными паттернами рендеринга.

Что такое sitemap и как её создать 

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

Иследование развенчало несколько распространённых мифов о том, как Google относится к сайтам, перегруженным JavaScript. Вот основные выводы и рекомендации к дальнейшим действиям.

Выводы

1. Google может эффективно обрабатывать и индексировать JavaScript‑контент, включая сложные SPA, динамически загружаемый и потоковый контент.

2. Нет принципиальной разницы в том, как Google обрабатывает страницы, содержащие JavaScript, по сравнению со статическими HTML‑страницами. Все страницы рендерятся.

3. Хотя очередь рендеринга существует, её влияние менее значительно, чем считалось ранее. Большинство страниц обрабатываются в течение нескольких минут, а не дней или недель.

4. Сайты с использованием JavaScript, включая SPA, не страдают от возможностей Google по обнаружению страниц.

5. Время добавления определённых элементов (например, тегов noindex) на страницу имеет решающее значение, поскольку Google может не обрабатывать client‑side‑изменения.

6. Google различает обнаружение ссылок и оценку их ценности. Последняя происходит после полностраничного рендеринга.

7. Процесс рендеринга Google не является строго приоритетным. Такие факторы, как свежесть контента и частота обновлений, влияют на расстановку приоритетов больше, чем сложность JavaScript.

8. Хотя Google может эффективно рендерить страницы с большим количеством JS, этот процесс требует больше ресурсов по сравнению со статическим HTML как для вас, так и для Google. 

Для крупных сайтов (10 тыс.+ уникальных и часто меняющихся страниц) это может повлиять на бюджет сканирования сайта. Если оптимизировать производительность приложения и свести к минимуму ненужный JS, это поможет ускорить процесс рендеринга, повысить эффективность сканирования и, возможно, позволит отрендерить, проиндексировать и просканировать больше ваших страниц.

Как оптимизировать краулинговый бюджет 

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

1. Используйте JavaScript. Свободно используйте JavaScript‑фреймворки для повышения удобства пользователей и разработчиков, но при этом уделяйте первостепенное внимание производительности и руководствуйтесь лучшими рекомендациями Google по отложенной загрузке.

Что такое юзабилити и как его улучшить 

2. Устраняйте ошибки. В приложениях React используйте Error boundaries, чтобы предотвратить полные сбои рендеринга из‑за ошибок отдельных компонентов.

3. Обратите внимание на важные SEO‑элементы. Используйте рендеринг на стороне сервера или статическую генерацию для важнейших SEO‑тегов и релевантного контента, чтобы они обязательно присутствовали в исходном HTML‑ответе.

4. Управляйте ресурсами. Убедитесь, что критические ресурсы для рендеринга (API, файлы JavaScript, файлы CSS) не заблокированы robots.txt.

5. Обновляйте контент. Если контент нуждается в быстрой переиндексации, убедитесь, что изменения отражаются в HTML, отрендеренном на сервере, а не только в JavaScript на стороне клиента. Рассмотрите такие стратегии, как Incremental Static Regeneration, чтобы соблюсти баланс между свежестью контента, SEO и производительностью.

6. Делайте грамотную внутреннюю перелинковку и структуру URL. Создайте чёткую, логичную структуру внутренней перелинковки. Реализуйте важные навигационные ссылки в виде настоящих HTML‑анкорных тегов (<a href="...">), а не навигации на основе JavaScript. Такой подход помогает пользователям в навигации и сканировании поисковыми системами, а также потенциально снижает задержки при рендеринге.

Что такое внутренняя перелинковка и как её сделать 

7. Используйте и регулярно обновляйте карты сайта. Для крупных сайтов или сайтов с частыми обновлениями используйте тег <lastmod> в XML‑карте сайта, чтобы направлять процессы сканирования и индексирования Google. Не забывайте обновлять <lastmod> только при крупных обновлениях контента.

8. Используйте инструмент проверки URL Google Search Console. Он поможет проверить, как Googlebot видит ваши страницы. Следите за статистикой сканирования.

Главное

Как мы уже выяснили, существуют некоторые различия между стратегиями рендеринга, позволяющие по‑разному реализовать возможности Google. Они собраны в таблице:

* Наличие обновлённого sitemap.xml значительно уменьшает, если не устраняет, разницу во времени обнаружения между различными шаблонами рендеринга.

** Как показало исследование, рендеринг в Google обычно не даёт сбоев. А когда это происходит, это часто связано с блокировкой ресурсов в robots.txt или специфическими случаями.

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

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

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

Ещё о JavaScript ⬇️

Что такое JavaScript и как он связан с SEO

JavaScript‑сайты и их индексация 

Рекомендации для JS‑сайтов