SEO для JavaScript: переконайтеся, що посилання виживають після рендерингу
Google рендерить JavaScript за допомогою актуального Chromium. Проблема рідко полягає в самому рендерингу. Зазвичай посилання так і не стають якорями, а сторінки залежать від стану, якого у краулера немає.
Команда досліджень ArchiLinks ·
Що бачить краулер
Googlebot використовує актуальний Chromium з травня 2019. Це остаточно вирішило питання щодо його здатності запускати сучасний JavaScript.
Практичні ризики залишаються старими: рендеринг відбувається після краулінгу і може бути затриманий, контент за кнопками або вхідними даними ніколи не з'являється, а посилання, створене через обробник onclick на div, не є посиланням. Перш ніж перевіряти беклінки на сторінках сайту, які ви нещодавно перенесли на фронтенд React, переконайтеся, що ці сторінки відображають свій контент у первинній відповіді або в відрендереному HTML.
SSR, SSG, CSR: що змінюється для посилань
| Підхід | Контент у першій відповіді | Внутрішні посилання як якорі | Підходить для |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Так | Так, якщо ви використовуєте справжні якорі | Публічні сторінки з мінливими даними |
| SSG або попереднє рендерингу | Так | Так | Документація, блоги, маркетингові сторінки |
| CSR односторінковий додаток | Ні, порожня оболонка | Тільки після рендерингу | Панелі керування за входом |
| Гібрид (SSR головна, CSR додаток) | Для кожного маршруту | Для кожного маршруту | Більшість продуктів з публічною частиною |
Протестуйте один: первинний HTML проти відрендереного HTML
Якщо ключові посилання з'являються в першій відповіді, питання закрито. Якщо ні, порівняйте з безголовим рендерингом.
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
Звідки беруться зовнішні посилання
Помилка рендерингу ховає ваш контент. Вона не стирає посилання, які інші сайти вже вам надали.
Після перенесення на Next.js, Vite або headless CMS запустіть toppages для хоста та протестуйте 20 найбільш посиланих URL-адрес на статус, канонічний URL та видимий контент. Зробіть це в першу чергу. Якщо сторінка з 40 доменами-посилальниками повертає порожню оболонку або клієнтський 404, виправте це до всього іншого, саме туди переходить ваш авторитет. Сторінка внутрішній проти зовнішнього equity посилань показує, як порівняти цей список із вашими внутрішніми посиланнями, а чек-лист міграції вписує тест у план запуску.
Фреймворки мають менше значення, ніж дисципліна. Express з шаблонним двигуном, тема WordPress та маршрутизатор додатків Next.js можуть обслуговувати доступні для краулінгу посилання. Кожен з них також може дати збій, якщо команда випускає якорі, які існують лише після кліку.
Чек-лист посилань та рендерингу
- Навігація та пагінація використовують
<a href>, а не обробники кліків на інших елементах. - Кожен маршрут повертає справжний код стану. М'які 404 екрани повинні повертати 404.
noindexабо канонічний URL, введений через JavaScript, відповідає тому, що є в відповіді сервера.- Контент резервного варіанту в першій відповіді — це справжня сторінка, а не індикатор завантаження, який Google може проіндексувати.
- Код авторизації не перенаправляє краулерів на публічних маршрутах.
- CSS та JS файли, необхідні для рендерингу, не заблоковані в robots.txt.
- Ліниве завантаження використовує IntersectionObserver або нативні атрибути завантаження, а не події прокрутки.
Читання доказів пошукової консолі
Пошукова консоль відповідає на більшість питань щодо рендерингу, якщо ви запитуєте правильний звіт. Використовуйте Інспектор URL, потім Переглянути відскановану сторінку.
Порівняйте три речі: HTML, який отримав Google, скріншот та ресурси сторінки, які не вдалося завантажити. Сторінка, яка виглядає повною у вашому браузері, але порожньою на скріншоті, зазвичай заблокована помилкою скрипта або забороненим ресурсом, і виправлення полягає у вашій збірці, а не в контенті.
Пам'ятайте про затримку. Зміну, яку ви випустили сьогодні, можна побачити в інструкті інспекції лише після повторного сканування URL Google, що може зайняти кілька днів.
Коли варто використовувати SSR
Публічні сторінки, які мають ранжуватися: так. Панелі керування: ні.
Якщо маршрут має залучати органічний трафік, подавайте контент у першій відповіді. Якщо сторінка знаходиться за паролем, уникайте зайвої складності. Обирайте підхід для кожного маршруту окремо, а не для всього проєкту, і задокументуйте рішення, щоб наступний розробник не скасував його.
- Використовуйте тест Rich Results та URL Inspection для порівняння рендерингу.
- Тестуйте за допомогою інструменту Live Test у Search Console після кожного оновлення фреймворку.
Чи потрібен серверний рендеринг, чи достатньо пре-рендерингу?
Серверний рендеринг є опціональним. Це спосіб забезпечити наявність у першій відповіді того, що потрібно пошуковому краулеру. Багато публічних сайтів досягають цього за допомогою пре-рендерингу, статичної збірки або серверного рендерингу лише для ключових сторінок, залишаючи частину під паролем без змін.
Уявімо, що сторінки продуктів та документація є публічними, а панель керування знаходиться за паролем. Пре-рендеруйте першу групу. Залиште панель керування на стороні клієнта. Тоді публічні сторінки міститимуть свої посилання в першій відповіді, а панель керування може залишатися такою складною, якою вона має бути.
Пре-рендеринг лише головної сторінки
Пре-рендеринг головної сторінки вирішує перше сканування, але залишає всі інші маршрути очікувати завантаження в браузері. Якщо головна сторінка містить посилання на категорії, які рендеряться на стороні клієнта, посилання на цих сторінках все одно залежатимуть від рендерингу. Перевірте кожен шаблон, яким ви володієте, а не лише головну сторінку.
Ведіть короткий список публічних маршрутів із зазначенням методу рендерингу. Цей список допоможе швидше виявити прогалини, ніж звіт про сканування.
Чи змінює серверний рендеринг локальну видимість
Серверний рендеринг може вплинути на швидкість появи першого контенту, що помітно користувачам. Сам по собі він не робить сторінку релевантною для локального запиту. Ці сигнали формуються контентом сторінки, даними бізнесу та посиланнями, що ведуть на неї.
Розглядайте рендеринг як спосіб зробити ці сигнали доступними для краулера, а посилання вимірюйте окремо через API.
Додатки Vite та React, що подають один шаблон
Збірка Vite, яка подає один HTML-шаблон для кожного шляху, перекладає всю роботу на клієнт. Такий додаток все ще може ранжуватися за деякими запитами, але для кожного публічного маршруту потрібен план: пре-рендеринг, серверний рендеринг або усвідомлення втрат із записом цього факту.
Перш ніж перевіряти зовнішні посилання на маршрутах після перебудови, визначте, як кожен публічний маршрут отримує свій контент. Інакше дані про посилання покажуть зовнішні посилання, що ведуть на порожні сторінки.
Перевірка відображення посилань на маршруті
Два тести відповідають на більшість запитань. Сырий відповідь показує те, що отримує краулер до запуску скриптів. Рендеринг DOM показує, що будує браузер після цього. Посилання, яке з’являється лише в другому випадку, все ще є посиланням, але воно залежить від успішності рендерингу.
Читання результату Live Test у Search Console
Запустіть Live Test з інструменту URL Inspection для одного маршруту за раз. Подивіться на рендеринг HTML, а потім на список ресурсів, які не вдалося завантажити. Заблокований скрипт може видалити цілий блок навігації, і сторінка виглядатиме пустою без видимих помилок.
Повторіть тест після оновлення фреймворку, оскільки нові налаштування за замовчуванням можуть змінити порядок рендерингу посилань до або після запуску скриптів. Посібник pages not indexed розповідає, що робити, якщо рендеринг сторінки все ще не індексується.
Коли маршрут рендериться, але контент — це індикатор завантаження
Фоллбек у першій відповіді важливіший, ніж очікують більшість команд. Індикатор завантаження або порожній контейнер означають, що сторінка не містить тексту для краулера в цей момент. Включіть заголовок, вступ та основні посилання в першу відповідь, навіть якщо детальний список завантажиться пізніше.
Фоллбек, який є реальною сторінкою, може залишатися простим. Його єдина задача — утримувати контент, доки завантажиться решта.
Перенесення клієнтського сайту без втрати посилань
Складіть список маршрутів із зовнішніми посиланнями
Запустіть toppages для хоста та запишіть топ-50 URL. Протестуйте ці маршрути першими, до змін у коді, щоб знати, що має зберегти перебудова.
Порівняння сирого та рендерингового виводу
Для кожного маршруту перевірте сирій HTML та рендеринг DOM у старій та новій збірках. Запишіть будь-яке посилання, яке існує в одному варіанті, але відсутнє в іншому.
Заміна обробників кліків на якірні посилання
Перетворіть навігацію на справжні якірні посилання з правильними адресами. Робота над швидкістю може зачекати спринт, тоді як відсутність якіра коштує маршруту його шляху в структуру сайту.
Повторення тесту після випуску
Через тиждень після випуску запустіть Live Test на тих самих маршрутах і порівняйте результати з попередніми. Різниця покаже, де перебудова змінила вивід.
Коди статусу та редиректи в додатку на стороні клієнта
Односпрямований додаток часто показує екран «не знайдено», тоді як сервер повертає статус 200. Google може вважати таку сторінку м’яким 404, і зовнішні посилання, що ведуть на відсутній URL, працюватимуть неефективно. Виправлення має бути на стороні сервера.
Невідомі маршрути, що все ще повертають 200
Повертайте реальний 404 з сервера для будь-якого маршруту, якого не існує, і залишайте екран «не знайдено» в додатку для відвідувачів, які прийшли через клієнтський маршрут. Якщо існує заміна, надішліть 301 замість цього.
Перевірте кілька вигаданих адрес на живому хості після кожного випуску. Важливо читати код відповіді, а не те, що ви бачите в браузері.
Редиректи, що працюють у браузері
Редирект, який спрацьовує після завантаження сторінки (наприклад, через читання параметра URL всередині компонента), відрізняється від серверного редиректу. Краулер може проіндексувати першу відповідь до запуску редиректу. Якщо маршрут змінився назавжди, повертайте 301 з сервера та зберігайте параметри, що змінюють контент. Рецепт redirect map recipe показує, як тестувати ці правила.
