Як Google обробляє JavaScript під час процесу індексації

Привіт:) Дослідження MERJ та Vercel для з'ясування принципів рендерингу Google на основі емпіричних даних.

Розуміння того, як пошукові системи сканують, рендерять та індексують веб-сторінки, є важливим для оптимізації сайтів для пошукових систем. Протягом багатьох років, коли такі пошукові системи, як Google, змінюють свої процеси, стає складніше стежити за тим, що працює, а що ні — особливо з JavaScript на стороні клієнта.

Ми помітили, що деякі старі переконання продовжують існувати і викликають у спільноти невизначеність щодо найкращих практик для SEO додатків:

  1. "Google не може рендерити JavaScript на стороні клієнта."
  2. "Google по-іншому обробляє сторінки з JavaScript."
  3. "Черга рендерингу та час значно впливають на SEO."
  4. "Сайти з великою кількістю JavaScript мають повільніше виявлення сторінок."

Щоб розвіяти ці переконання, ми співпрацювали з MERJ, провідною консультаційною компанією в галузі SEO та інженерії даних, щоб провести нові експерименти щодо поведінки сканування Google. Ми проаналізували понад 100 000 звернень Googlebot до різних сайтів, щоб протестувати та підтвердити можливості Google у сфері SEO.

Давайте подивимося, як еволюціонував процес рендерингу Google. Потім дослідимо наші висновки та їхній реальний вплив на сучасні веб-додатки.

до змісту ↑

Еволюція можливостей рендерингу Google

З роками здатність Google сканувати та індексувати веб-контент суттєво змінилася. Розуміння цієї еволюції важливе для розуміння сучасного стану SEO для веб-додатків.

До 2009: обмежена підтримка JavaScript

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

2009–2015: схема сканування AJAX

Google запровадив схему сканування AJAX, яка дозволяла сайтам надавати HTML-знімки динамічно згенерованого контенту. Це було тимчасове рішення, яке вимагало від розробників створювати окремі, скановані версії своїх сторінок.

2015–2018: початковий рендеринг JavaScript

Google почав рендерити сторінки за допомогою "безголового" браузера Chrome (англ. headless Chrome browser), що стало значним кроком вперед. Однак ця стара версія браузера мала обмеження в обробці сучасних функцій JavaScript.

Термін "headless Chrome browser" означає версію браузера Chrome, яка працює без графічного інтерфейсу користувача (без відображення вікон). Це спеціальний режим браузера, який дозволяє виконувати всі ті ж завдання, що і звичайний браузер, але без відкриття вікон на екрані. Такий підхід зазвичай використовується для автоматизації процесів, таких як:

Тестування веб-додатків: "headless" режим дозволяє запускати автоматизовані тести без участі людини, що знижує ресурси, необхідні для тестування.

Сканування та парсинг: Цей режим дозволяє отримувати контент зі сторінок, рендерити JavaScript і обробляти DOM (Document Object Model), що робить його корисним для сканування веб-сайтів або "витягування" даних.

SEO: "Headless Chrome" використовується Google для рендерингу сторінок перед індексацією, особливо тих, що використовують JavaScript для генерації контенту.
Це ефективний спосіб взаємодії з веб-сайтами програмно, оскільки він не потребує візуального представлення, але може виконувати всі стандартні функції браузера.
до змісту ↑

2018–дотепер: сучасні можливості рендерингу

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

  1. Універсальний рендеринг. Google тепер намагається рендерити всі HTML-сторінки, а не лише їх частину.
  2. Оновлений браузер. Googlebot використовує останню стабільну версію Chrome/Chromium, яка підтримує сучасні функції JavaScript.
  3. Безстанний рендеринг. Кожен рендеринг сторінки відбувається у новій сесії браузера, без збереження файлів cookie або стану з попередніх рендерингів. Google зазвичай не взаємодіє з елементами сторінки, такими як вкладки або банери cookie.
  4. Клоакінг. Google забороняє показувати різний контент користувачам і пошуковим системам з метою маніпулювання рейтингами. Уникайте коду, що змінює контент на основі User-Agent. Натомість оптимізуйте безстанний рендеринг вашого додатка для Google, а персоналізацію впроваджуйте за допомогою методів, що зберігають стан.
  5. Кешування ресурсів. Google прискорює рендеринг веб-сторінок за допомогою кешування ресурсів, що корисно для сторінок із спільними ресурсами та для повторного рендерингу однієї й тієї ж сторінки. Замість використання заголовків HTTP Cache-Control, служба рендерингу Google застосовує власні внутрішні евристики для визначення актуальності кешованих ресурсів і необхідності їх повторного завантаження.

Щоб краще зрозуміти, на що здатен Google, давайте розглянемо деякі поширені міфи і те, як вони впливають на SEO.

до змісту ↑

Методологія

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

Збір даних

Ми розмістили на цих сайтах спеціальне проміжне програмне забезпечення Edge Middleware для перехоплення та аналізу запитів від пошукових ботів. Це проміжне ПЗ дозволило нам

  1. Ідентифікувати та відстежувати запити від різних пошукових систем та пошукових роботів зі штучним інтелектом. (Жодні дані користувача не були включені в цей запит).
  2. Вбудовувати легку бібліотеку JavaScript у HTML-відповіді для ботів.

Бібліотека JavaScript, яка запускалася після завершення рендерингу сторінки, відправляла дані назад на сервер, що працює тривалий час, зокрема

  • URL-адресу сторінки;
  • унікальний ідентифікатор запиту (для зіставлення відображення сторінки зі звичайними журналами доступу до сервера);
  • мітка часу завершення рендерингу (розраховується на основі часу отримання запиту бібліотекою JavaScript на сервері).

Аналіз даних

Порівнюючи початковий запит, присутній в журналах доступу до сервера, з даними, надісланими з нашого проміжного програмного забезпечення на зовнішній сервер маяка, ми можемо:

  1. Підтвердити, які сторінки були успішно відображені пошуковими системами.
  2. Розрахувати різницю в часі між початковим скануванням і завершеним рендерингом.
  3. Проаналізувати закономірності обробки різних типів контенту та URL-адрес.

Обсяг даних

Для цієї статті ми в першу чергу зосередилися на даних Googlebot, який надав найбільший і найнадійніший набір даних. Ми проаналізували понад 37 000 відображених HTML-сторінок, зіставлених з парами сервер-маяк, що дало нам надійну вибірку, на основі якої можна робити висновки.

Ми продовжуємо збирати дані про інші пошукові системи, зокрема про постачальників ШІ, таких як OpenAI та Anthropic, і сподіваємося розповісти більше про наші результати в майбутньому.

У наступних розділах ми зануримося в кожен міф, надаючи більш релевантну методологію за необхідності.

до змісту ↑

Міф 1: "Google не може відображати JavaScript-контент"

Цей міф змусив багатьох розробників уникати JS-фреймворків або вдаватися до складних обхідних шляхів для SEO.

Тест

Щоб перевірити здатність Google відображати JavaScript-контент, ми зосередилися на 4-х ключових аспектах:

  1. Сумісність з JS-фреймворками. Ми проаналізували взаємодію Googlebot з Next.js, використовуючи дані з сайту nextjs.org, який використовує поєднання статичного попереднього рендерингу, рендерингу на стороні сервера та рендерингу на стороні клієнта.
  2. Динамічна індексація контенту. Ми дослідили сторінки на nextjs.org, які завантажують контент асинхронно через виклики API. Це дозволило нам визначити, чи може Googlebot обробляти та індексувати вміст, якого немає у початковій HTML-відповіді.
  3. Потокове передавання контенту через React Server Components (RSC). Як і вище, більша частина nextjs.org побудована з використанням маршрутизатора додатків Next.js і RSC. Ми могли бачити, як Googlebot обробляв та індексував контент, що поступово транслювався на сторінку.
  4. Коефіцієнт успішності рендерингу. Ми порівняли кількість запитів Googlebot у логах нашого сервера з кількістю отриманих маячків успішного рендерингу. Це дало нам уявлення про те, який відсоток сканованих сторінок було повністю відрендерено.

Результати

  1. З понад 100 000 запитів 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-сторінки"

Поширеною помилкою є вважати, що Google має окремий процес або критерії для сторінок з високим вмістом JavaScript. Наше дослідження в поєднанні з офіційними заявами Google розвінчує цей міф.

Тест

Щоб перевірити, де Google по-різному ставиться до JS-важких сторінок, ми застосували кілька цілеспрямованих підходів:

  1. Тест з імпортом CSS. Ми створили тестову сторінку без JavaScript, але з файлом CSS, який через @import імпортує другий файл 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, сторінки з помірною інтерактивністю та високодинамічні сторінки з великим обсягом рендерингу на стороні клієнта. Ми також підрахували і порівняли час між початковим скануванням і завершеним рендерингом, щоб побачити, чи призводить більш складний JS до збільшення черги рендерингу або часу обробки.

Результати

  1. Наш тест із @import підтвердив, що Google успішно відображає сторінки як з JS, так і без нього.
  2. Google відображає всі HTML-сторінки зі статусом 200, незалежно від вмісту JS. Сторінки зі статусом 304 відображаються з використанням вмісту початкової сторінки зі статусом 200. Сторінки з іншими помилками 3xx, 4xx і 5xx не відображаються.
  3. Сторінки з мета-тегами noindex у початковій HTML-відповіді не відображалися, незалежно від вмісту JS. Видалення тегів noindex на боці клієнта не є ефективним для цілей SEO; якщо сторінка містить тег noindex у початковій HTML-відповіді, вона не буде відображена, а JavaScript, який видаляє цей тег, не буде виконаний.
  4. Не виявили суттєвої різниці в успішності відображення Google сторінок з різним рівнем складності JS. За шкалою nextjs.org ми також не виявили кореляції між складністю JavaScript та затримкою рендерингу. Однак більш складний JS на значно більшому сайті може вплинути на ефективність сканування.
до змісту ↑

Міф 3: "Черга рендерингу і терміни суттєво впливають на SEO"

Багато SEO-спеціалістів вважають, що сторінки з високим вмістом JavaScript стикаються зі значними затримками в індексації через чергу рендерингу. Наше дослідження дає більш чітке уявлення про цей процес.

Тест

Щоб з'ясувати вплив черги і часу рендерингу на SEO, ми провели дослідження:

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

Результати

Розподіл затримки рендерингу був таким:

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

Дивно, але 25-й процентиль сторінок було відскановано протягом 4 секунд після першого сканування, що спростовує уявлення про довгу "чергу".

Хоча деякі сторінки стикалися зі значними затримками (до ~18 годин у 99-му процентилі), вони були винятком, а не правилом.

Ми також помітили цікаві закономірності, пов'язані з тим, як швидко 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: "Сайти з високим вмістом JavaScript повільніше відкриваються"

У SEO-спільноті існує стійке переконання, що сайти з високим вмістом JavaScript, особливо ті, що покладаються на клієнтський рендеринг (CSR), такі як односторінкові додатки (SPA), страждають від повільнішого відкриття сторінок Google. Наше дослідження надає нові дані про це.

Тест

Щоб дослідити вплив JavaScript на відкриття сторінок, ми:

  1. Проаналізували виявлення посилань у різних сценаріях рендерингу. Ми порівняли, як швидко Google виявив і сканував посилання на сторінках, відрендерених сервером, статично згенерованих і згенерованих клієнтом на nextjs.org.
  2. Тестували невідображене корисне навантаження JavaScript. Ми додали JSON-об'єкт, схожий на React Server Component (RSC), на сторінку /showcase на nextjs.org, що містить посилання на нові, раніше не виявлені сторінки. Це дозволило нам перевірити, чи може Google виявити посилання в даних JavaScript, які не були відрендереними.
  3. Порівняння часу виявлення. Ми відстежували, як швидко Google виявляв і сканував нові сторінки, на які були зроблені посилання різними способами: стандартні HTML-посилання, посилання в клієнтському контенті та посилання в невідображених JavaScript-даних.

Результати

  1. Google успішно виявляє та сканує посилання на повністю відрендерених сторінках, незалежно від методу рендерингу.
  2. Google може знаходити посилання в невідрендерених JavaScript-даних на сторінці, таких як ті, що знаходяться в React Server Components або подібних структурах.
  3. У як початковому, так і відрендереному HTML, Google обробляє контент, ідентифікуючи рядки, які виглядають як URL, використовуючи поточний хост і порт як базу для відносних URL. (Google не виявив закодоване посилання, тобто https%3A%2F%2Fwebsite.com, у нашому RSC-подібному завантаженні, що свідчить про сувору перевірку парсингу посилань.)
  4. Джерело та формат посилання (наприклад, у тегу або вбудоване в JSON) не впливали на те, як Google визначав пріоритетність сканування. Пріоритет сканування залишався постійним, незалежно від того, чи було посилання знайдено під час початкового сканування чи після рендерингу.
  5. Хоча Google успішно виявляє посилання на сторінках з клієнтським рендерингом (CSR), ці сторінки спочатку повинні бути відрендерені. Сторінки, відрендерені на сервері, або частково попередньо відрендерені сторінки мають невелику перевагу в швидкості виявлення посилань.
  6. Google розрізняє виявлення посилань і оцінку їхньої цінності. Оцінка цінності посилання для архітектури сайту та пріоритетності сканування відбувається після повного рендерингу сторінки.
  7. Наявність оновленого файлу sitemap.xml значно зменшує або повністю усуває відмінності у швидкості виявлення між різними методами рендерингу.
до змісту ↑

Загальні висновки та рекомендації

Наше дослідження розвінчало декілька поширених міфів про те, як Google працює з веб-сайтами, що містять багато JavaScript. Ось основні висновки та практичні рекомендації:

Висновки

  1. Сумісність з JavaScript. Google ефективно рендерить й індексує контент JavaScript, включаючи складні SPA, динамічно завантажуваний та потоковий контент.
  2. Єдність рендерингу. Немає принципової різниці в тому, як Google обробляє сторінки з великою кількістю JavaScript порівняно зі статичними HTML-сторінками. Усі сторінки рендеряться.
  3. Реальність черги рендерингу. Хоча черга рендерингу існує, її вплив менш значущий, ніж вважалося раніше. Більшість сторінок рендеряться протягом хвилин, а не днів чи тижнів.
  4. Виявлення сторінок. Сайти з великою кількістю JavaScript, включаючи SPA, не мають суттєвих недоліків у процесі виявлення сторінок Google.
  5. Час контенту. Час, коли певні елементи (наприклад, теги noindex) додаються на сторінку, є вирішальним, оскільки Google може не обробляти зміни на стороні клієнта.
  6. Оцінка цінності посилань. Google розрізняє виявлення посилань та оцінку їхньої цінності. Оцінка відбувається після повного рендерингу сторінки.
  7. Пріоритетність рендерингу. Процес рендерингу Google не завжди працює за принципом "перший прийшов — перший оброблений". Фактори, такі як актуальність контенту та частота оновлень, більше впливають на пріоритетність, ніж складність JavaScript.
  8. Продуктивність рендерингу та бюджет сканування. Хоча Google ефективно рендерить сторінки з великою кількістю JavaScript, цей процес є більш ресурсомістким порівняно зі статичним HTML як для вас, так і для Google. Для великих сайтів (з більш ніж 10 000 унікальних та часто змінюваних сторінок) це може вплинути на бюджет сканування сайту. Оптимізація продуктивності додатків і зменшення непотрібного JavaScript може допомогти прискорити процес рендерингу, підвищити ефективність сканування і, можливо, дозволити більше сторінок бути просканованими, відрендереними та проіндексованими.

Рекомендації

  1. Використовуйте JavaScript. Використовуйте JavaScript-фреймворки для покращення взаємодії з користувачами та розробниками, але надавайте перевагу продуктивності та дотримуйтесь рекомендацій Google щодо відкладеного завантаження.
  2. Обробка помилок. Впроваджуйте межі обробки помилок у React-додатках, щоб уникнути повних збоїв рендерингу через помилки окремих компонентів.
  3. Критичні елементи SEO. Використовуйте рендеринг на стороні сервера або статичну генерацію для критичних SEO-тегів і важливого контенту, щоб забезпечити їх присутність у початковій HTML-відповіді.
  4. Керування ресурсами. Переконайтеся, що критичні ресурси для рендерингу (API, файли JavaScript, CSS) не заблоковані у файлі robots.txt.
  5. Оновлення контенту. Для контенту, який потрібно швидко переіндексувати, переконайтеся, що зміни відображаються у серверному HTML, а не лише в клієнтському JavaScript. Розгляньте стратегії, такі як інкрементальне статичне оновлення (Incremental Static Regeneration), щоб збалансувати актуальність контенту, SEO та продуктивність.
  6. Внутрішні посилання та структура URL. Створіть чітку, логічну внутрішню структуру посилань. Впроваджуйте важливі навігаційні посилання як справжні HTML-теги прив'язок (<a href="...">), а не навігацію на основі JavaScript. Такий підхід допоможе як у навігації користувачів, так і в ефективності сканування пошукових систем, потенційно зменшуючи затримки рендерингу.
  7. Карти сайтів (sitemaps). Використовуйте та регулярно оновлюйте карти сайтів. Для великих сайтів або сайтів із частими оновленнями використовуйте тег <lastmod> у XML-картах сайтів, щоб керувати процесами сканування та індексації Google. Не забувайте оновлювати лише тоді, коли відбувається значне оновлення контенту.
  8. Моніторинг. Використовуйте інструмент перевірки URL у Google Search Console або інструмент Rich Results (https://search.google.com/test/rich-results), щоб перевірити, як Googlebot бачить ваші сторінки. Слідкуйте за статистикою сканування, щоб переконатися, що ваша стратегія рендерингу не спричиняє неочікуваних проблем.
до змісту ↑

Рухаємося вперед з новою інформацією

Як ми вже з'ясували, існують деякі відмінності між стратегіями рендерингу, коли мова йде про можливості Google:

ОсобливістьСтатична генерація сайтів (SSG)Інкрементна статична регенерація (ISR)Рендеринг на стороні сервера (SSR)Рендеринг на стороні клієнта (CSR)
Ефективність сканування. Наскільки швидко та ефективно Google може отримати доступ до веб-сторінок, відобразити їх та витягти.ЧудовоЧудовоДуже добреПогано
Відкриття. Процес пошуку нових URL-адрес для сканування.*ЧудовоЧудовоДуже добреСередньо
Повнота відображення (помилки, збої тощо). Наскільки точно і повно Google може завантажувати і обробляти ваші веб-сторінки без помилок.НадійноНадійноНадійноМоже не спрацювати**
Час рендерингу. Скільки часу потрібно Google для повного рендерингу та обробки веб-сторінок.ЧудовоДуже добреДуже добреПогано
Оцінка посилальної структури. Як Google оцінює посилання, щоб зрозуміти архітектуру сайту та важливість сторінок.Після рендерингуПісля рендерингуПісля рендерингуПісля рендерингу посилання можуть бути відсутніми, якщо рендеринг завершився невдало
Індексація. Процес, за допомогою якого Google зберігає та впорядковує вміст вашого сайту.НадійноНадійноНадійноМоже бути не проіндексовано, якщо рендеринг завершився невдало

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

** Рендеринг у Google зазвичай не дає збоїв, як показало наше дослідження; коли це відбувається, це часто пов'язано із заблокованими ресурсами в robots.txt або специфічними крайніми випадками.

Ці дрібні відмінності існують, але Google швидко знайде та проіндексує ваш сайт незалежно від стратегії рендерингу. Зосередьтеся на створенні ефективних веб-додатків, які приносять користувачам більше користі, ніж турбота про спеціальні пристосування для процесу рендерингу Google.

Зрештою, швидкість сторінки все ще є фактором ранжування, оскільки система ранжування Google оцінює продуктивність вашого сайту на основі показників Google Core Web Vitals.

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

Джерело

Михайло Петров
Михайло Петров

Мене звати Михайло. Я — WordPress-розробник. Створюю візитки, корпоративні сайти, блоги на WordPress.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *