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

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

1. Google не умеет рендерить клиентский JS.
2. Google по-разному обрабатывает страницы, содержащие JS.
3. Очередь рендеринга и его длительность значительно влияют на SEO.
4. Сайты с большим объемом 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 для рендеринга веб-страниц. Ключевые аспекты текущей системы включают:

1. Универсальный рендеринг: теперь Google старается отрендерить все HTML-страницы, а не только выборочное подмножество.
2. Актуальный браузер: Googlebot использует последнюю стабильную версию Chrome/Chromium, поддерживающую современные возможности JS.
3. Рендеринг без сохранения состояния: каждый рендеринг страницы происходит в новой сессии браузера, без сохранения куки или состояний из предыдущих рендерингов. Обычно Google не кликает по элементам на странице, таким как вкладки или баннеры куки.
4. Экранирование: Google запрещает показывать различный контент пользователям и поисковым системам, чтобы манипулировать рейтингами. Избегайте кода, который изменяет содержимое на основе User-Agent (устройства пользователя). Вместо этого оптимизируйте приложение на основе рендеринга без сохранения состояния для Google и реализуйте персонализацию с помощью методов с сохранением состояния.
5. Кэширование ресурсов: 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), чтобы перехватывать и анализировать запросы от поисковых ботов. Этот слой позволил:

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

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

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

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

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

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

Объем данных

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

---

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

• JavaScript: структуры данных и алгоритмы;
• От Web к Native с React;
• Движок для игры от первого лица в 265 строках Javascript;
• Большое руководство по сетям и шифрованию трафика в Linux;
• Под покровом арабской ночи: Disney's Aladdin.