Аудит рендерингу JavaScript: сирий і відрендерений HTML

Перевірка рендерингу: вихідний HTML і відрендерений DOM

Коли використовувати: Переконайтеся, що бачить Googlebot після виконання JavaScript, а не лише в першій відповіді сервера.

Порівняйте вихідний код із відрендереним DOM

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

Почніть із вихідної HTML-відповіді (коду, який повертає сервер). Зафіксуйте, які контент, посилання й метадані є там до виконання будь-якого JavaScript. Потім перегляньте відрендерений DOM після роботи скриптів і порівняйте.

• [URL сторінки] перевірено
• Основний контент є у вихідному HTML?
• Заголовки, текст і дані товарів є у відрендереному DOM?
• Навігація та внутрішні посилання є після рендерингу?
• Title, meta description і canonical є після рендерингу?

Позначайте все, що з'являється лише після виконання JavaScript. Такий контент повністю залежить від успішного рендерингу, тож ризикує найбільше. Кожну розбіжність між вихідним HTML і відрендереним DOM запишіть як проблему для виправлення.

Контент і посилання, доступні для сканування

Коли використовувати: Переконайтеся, що основний контент і навігація використовують справжні посилання, які є в DOM і доступні для сканування.

Справжні посилання й контент у DOM

Пошукові системи переходять за посиланнями через стандартні елементи <a> з атрибутом href, що веде на реальний URL. Посилання, які спрацьовують лише через обробник onclick, кнопку чи span, знаходяться ненадійно. Через це важливі сторінки можуть залишитися непросканованими.

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

• Головна навігація використовує посилання [a href]
• Пагінація та фільтри мають URL, доступні для сканування
• Пов'язані та внутрішні посилання є справжніми анкорами, а не onclick
• Основний контент рендериться в DOM і не схований за взаємодіями

Не покладайтеся на події кліку, нескінченне прокручування без URL пагінації чи контент, який підвантажується лише після дій користувача. Googlebot таких дій не виконує. Якщо контент з'являється тільки після тапу чи прокручування, вважайте його ризикованим і дайте до нього шлях, доступний для сканування. Запишіть, які посилання й розділи проходять перевірку, а яким потрібен справжній href або присутність у DOM.

Індексованість: метадані після рендерингу

Коли використовувати: Виявляйте noindex, canonical чи robots, підставлені через JS, які блокують або збивають індексацію.

Перевіряйте відрендерені метадані, а не лише код

JavaScript може змінювати сигнали індексації, але не завжди так, як ви очікуєте. Якщо JavaScript додає noindex, це може спрацювати. Якщо ж noindex є у вихідному HTML, а JavaScript його потім прибирає, це може не спрацювати: Google може пропустити рендеринг сторінок, що починаються з noindex. Canonical, заданий через JavaScript, має збігатися з тим, що у вихідному HTML.

Для кожного шаблону перегляньте відрендерений DOM і переконайтеся, що сигнали індексації відповідають вашому задуму.

• Robots meta у відрендереному DOM: [index/noindex]
• Тег canonical є один раз і вказує на потрібний URL
• JavaScript не підміняє canonical на інший URL
• Title і meta description після рендерингу мають правильні значення
• Hreflang і структуровані дані є там, де потрібно

Зміни noindex чи canonical через JS ризиковані: Google може взяти вихідне значення, відрендерене або взагалі пропустити рендеринг. Будьте особливо уважні з фреймворками та менеджерами тегів, які переписують елементи head. Якщо директива може відрізнятися у вихідному й відрендереному стані, вважайте це дефектом і задавайте її на сервері. Запишіть відрендерені директиви кожної сторінки та всі розбіжності.

Стратегія рендерингу: CSR, SSR чи SSG

Коли використовувати: Оберіть підхід до рендерингу, з яким контент надійно доступний краулерам.

Обирайте стратегію рендерингу на користь сканованості

Від способу рендерингу залежить, наскільки надійно контент доходить до пошукових систем. Рендеринг у Google відкладений, тому стратегії, що віддають контент уже в початковому HTML, зменшують ризик.

• Рендеринг на клієнті (CSR): браузер збирає сторінку з JavaScript. Контент повністю залежить від успішного рендерингу, тож ризик для індексації найвищий.
• Рендеринг на сервері (SSR): сервер на кожен запит повертає повністю сформований HTML. Контент, посилання й метадані доступні одразу.
• Генерація статичного сайту (SSG) або пререндеринг: HTML збирається заздалегідь або віддається з шару пререндерингу. Контент надійно доступний, а продуктивність висока.

Для сторінок, критичних для SEO, обирайте SSR, SSG або пререндеринг, щоб контент був у початковому HTML. Важкий CSR залиште для розділів за авторизацією або з низькою цінністю для SEO.

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

• Шаблон: [назва]
• Поточний і цільовий метод рендерингу

Вплив JavaScript на продуктивність

Коли використовувати: Зменшіть вагу JS і вартість його виконання, щоб сторінки швидко рендерилися для користувачів і краулерів.

Зменшуйте вартість JavaScript

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

Перевірте, скільки скриптів віддає кожен ключовий шаблон і що вони блокують.

• Знайдено великі або невикористані JavaScript-бандли
• Скрипти, що блокують рендеринг, відкладено або розділено, де можливо
• Критичний контент не чекає на повільне виконання скриптів
• Сторонні скрипти перевірено на вагу й потрібність
• Core Web Vitals переглянуто на ключових шаблонах

Використовуйте розділення коду, прибирайте невикористаний код і завантажуйте некритичні скрипти пізніше, щоб основний контент з'являвся швидко. Ніколи не блокуйте файли JavaScript чи CSS у robots.txt: це заважає Google відрендерити сторінку так, як її бачать користувачі. Запишіть розміри бандлів, ресурси, що блокують рендеринг, і заплановані виправлення для кожного перевіреного шаблону.

Тестування й моніторинг

Коли використовувати: Перевіряйте рендеринг реальними інструментами й стежте за ним у Search Console.

Тестуйте відрендерену сторінку й стежте за нею

Звіряйте виправлення з тим, що Google насправді рендерить. Інструмент перевірки URL (URL Inspection) у Search Console показує відрендерений HTML і знімок просканованої сторінки. Так ви переконаєтеся, що контент, посилання й метадані є після рендерингу.

Проженіть кожен ключовий шаблон через перевірку й збережіть результати.

• Відрендерений HTML у перевірці URL містить основний контент
• Знімок відрендереної сторінки показує очікуваний макет
• Навігація та внутрішні посилання є у відрендереному HTML
• Директиви індексації у відрендереному результаті правильні
• Під час рендерингу немає помилок

Далі переходьте від разових перевірок до постійного моніторингу.

• Стежте за звітами про покриття та індексацію в Search Console
• Повторюйте перевірку після великих змін фреймворку чи шаблонів
• Слідкуйте, чи не випадають сторінки з індексу

Записуйте кожен протестований URL [URL], його статус рендерингу й потрібні подальші дії. Так проблеми виявляться рано, а не після просідання позицій.

Таблиця аудиту: вихідний і відрендерений HTML (для заповнення)

Коли використовувати: Один рядок на шаблон сторінки: вихідні й відрендерені значення для контенту, посилань, title, canonical, robots і статусу, а також помилки консолі та гідратації.

Аудит вихідного й відрендереного HTML

Протестуйте по одному типовому URL на шаблон (головна, категорія, товар, стаття). Вихідний HTML: те, що повертає ваш сервер. Відрендерений HTML: те, що показує інструмент перевірки URL (URL Inspection) або перевірка розширених результатів (Rich Results Test) після виконання JavaScript.

Які помилки записувати

• Помилки консолі під час рендерингу: [повідомлення, файл скрипту]
• Помилки гідратації: [попередження фреймворку, компонент, що змінилося між серверним і клієнтським HTML]
• Заблоковані ресурси: [файли JS чи CSS, заблоковані в robots.txt]

Правило: якщо контент чи посилання є лише в стовпці відрендереного HTML, шаблон залежить від рендерингу. Для сторінок, які мають ранжуватися, надійніше виправлення: рендеринг на сервері або пререндеринг.

Перевірки статусу та soft 404

Коли використовувати: Переконайтеся, що сторінки помилок в односторінковому застосунку повертають справжні помилки, а маршрутизація використовує URL, доступні для сканування.

Перевірки статусу

Односторінкові застосунки часто показують повідомлення «сторінку не знайдено» зі статусом 200. Google називає такі сторінки soft 404. Його посібник із JavaScript пропонує два виправлення: перенаправити на URL, що повертає справжній 404, або додати через JavaScript тег robots з noindex.

Критерій завершення: рядки кожного шаблону збігаються або мають відповідального за виправлення; дата повторної перевірки [дата].

Приклад (вигаданий застосунок рецептів)

Коли використовувати: Заповнений аудит вигаданого сайту рецептів на React із трьома розбіжностями між вихідним і відрендереним HTML.

Приклад: Pantry & Plate

Лише приклад. Компанія, люди, URL і цифри вигадані, щоб показати, як виглядає корисна заповнена версія.

Чому рядок 3 був найважливішим

Шаблон за замовчуванням віддавав noindex, а JavaScript після завантаження змінював його на index. У браузері все виглядало нормально. Але Google може не рендерити сторінку, у вихідному HTML якої стоїть noindex, тож цієї зміни він міг так і не побачити. Значення за замовчуванням прибрали, і проблему вирішено.

Наступний крок

Скористайтеся інструментом Get Source Code of Webpage, щоб побачити вихідний HTML, який отримує краулер, і порівняйте його з відрендереним HTML в інструменті перевірки URL (URL Inspection). Запустіть аудит сайту, щоб знайти проблеми зі статусами та метаданими в усіх шаблонах, і перевіряйте сторінки просто під час перегляду з SEO-розширенням seotools.pro. Якщо вашій команді потрібна допомога з переведенням ключових шаблонів на рендеринг на сервері, перегляньте наші послуги SEO та GEO.