5 ошибок, которые могут погубить ваш проект на SPA
5 февраля 2022 года в Санкт-Петербурге состоялась очередная встреча клуба SEO-специалистов, вебмастеров и маркетологов SEO CLUB SPB. На конференции наше агентство kite. представляло доклад «5 критических ошибок, которые могут погубить ваш проект на SPA».
Делимся опытом работы с проектами на SPA и объясняем, как исправить часто встречающиеся ошибки.
Что такое SPA?
SPA или Single Page Application (одностраничное приложение) — web-приложение, которое написано на языке JavaScript. Его компоненты — JavaScript-файлы, модули, CSS-файлы — загружаются один раз на одной странице, а контент подгружается по мере необходимости в ходе взаимодействия пользователя с системой. Trello, Gmail, GitHub, Meduza — все это одностраничные приложения.
JavaScript — один из наиболее востребованных языков программирования. Число проектов, которые используют JS-технологии и фреймворки, продолжает расти в геометрической прогрессии.
Преимущества:
☑ Высокая скорость загрузки. SPA загружают весь необходимый код в браузере пользователя, а не на сервере. Поэтому нагрузка на сервер и скорость загрузки сайта остаются минимальными. Когда пользователь совершает действия, данные на странице меняются, а не перезагружаются полностью.
☑ Гибкость пользовательского интерфейса. На единственной веб-странице удобнее создавать динамически обновляемый контент, хранить информацию о сеансе, управлять мультимедиа и анимировать изображения.
☑ Простая разработка. Код для SPA начинают писать с файла file://URL. При этом разработчику не нужен сервер.
Недостаток одностраничных приложений заключается в том, что они нарушают принципы индексации:
- не перезагружают страницы — имеют один URL;
- не содержат контента в пригодном для сканирования виде;
- не индексируются поисковыми системами, за исключением Google.
Чтобы перевести JavaScript-код в понятный поисковикам HTML, используют рендеринг. Поискового бота переадресовывают с SPA-сайта на специальный сервер, где находится статический контент, заранее подготовленный для индексации.
Выбор метода рендеринга зависит от масштабов проекта и поисковых систем, в которых вы планируете его продвигать. Об этом расскажем далее и покажем примеры из наших кейсов.
Ошибки при реализации проектов на SPA:
1. Не рендерится все
На странице отсутствует контент для поисковых роботов, поэтому она не индексируется.
Как проверить, есть ли рендеринг? Зайдите в исходный код страницы (Ctrl + Shift + U) и посмотрите, как он выглядит. В нем должны быть, как минимум, Title, Description и заголовки. Если их нет, сайт не рендерится.
Не путайте исходный код с консолью разработчика, в которой код уже отрендерен.
Что делать, если на SPA-сайте нет рендеринга? Мы в kite. решаем проблему так:
- Совместно с разработчиками выбираем метод рендеринга и показа HTML-версии страницы.
- Составляем требования к наиболее важным для SEO элементам:
- ссылки со всеми атрибутами;
- метатеги и структура заголовков;
- меню и дополнительные элементы навигации;
- графическая информация с метатегами;
- тексты с форматированием;
- микроразметка.
При выборе метода рендеринга отталкиваемся от того, где должна индексироваться страница:
☑ Только в Google → ничего не делаем, оставляем WRS. Это технология рендеринга, основанная на обработке JS с помощью браузера Google Chrome.
Google-бот не умеет действовать, как настоящий пользователь: не скроллит страницы, не кликает по ссылкам. При этом он старается оптимизировать краулинговый бюджет: если время отрисовки первичного HTML превышает 5 секунд, он не проиндексирует страницу.
☑ В Google + Яндексе, небольшой проект до 100 тыс страниц → используем аутсорс-сервисы (например, Prerender.io).
☑ В Google + Яндексе, большой проект → используем SSR (Server Side Rendering). Это рендеринг кода за счет мощностей вашего сервера — «золотой стандарт» в работе со SPA. В большинстве JS-фреймворков предусмотрена поддержка SSR — например, React, Angular и Vue.
2. Не рендерятся блоки с контентом
Может «сломаться» рендеринг чего угодно: метатегов, заголовков, блоков с контентом, пагинации, микроразметки, ссылок в блоках, меню или футере.
Пример: на сайте MyBook отключился рендеринг блока отзывов. Поисковый бот не видел цитаты, заголовки и ссылки. В дополнение к этому отключился блок рендера перелинковки.
Разница в контенте негативно сказалась на ранжировании страниц.
Как понять, что контентные блоки не отдаются в рендер?
☑ Если есть доступ к панели вебмастеров:
Шаг 1: посмотрите код нужной страницы через Google Search Console или Яндекс.Вебмастер, используйте инструмент «Проверка ответа сервера». В блоке «Содержимое страницы» отображаются первые 50 тысяч символов кода. Если нужно, обратитесь в поддержку Яндекс попросите, чтобы они отправили вам полный код страницы.
К сожалению, большой объём страниц с помощью техподдержки проверить не получится, нам удавалось получить до 5 страниц шаблонов в сутки в том, виде, в котором их "видит" поисковой робот Яндекса.
Шаг 2: Проверьте, отображаются ли нужные блоки в HTML-формате. Вручную (в любом блокноте) или через визуализатор кода: он «отрисует» код в таком виде, в каком его получает поисковая система.
☑ Если нет доступа к панели вебмастеров, используйте следующие инструменты. Мы расположили их в порядке убывания точности результатов.
- Валидатор микроразметки Google. Вставьте URL, выберите тип бота, получите код.
- Оператор поиска site. Команда выводит список страниц, которые проиндексированы поисковой системой. Введите точную фразу из интересующего вас блока с оператором «site:». Если текстовый блок был передан в рендеринг, он «подсветится» в Description. Если рендеринга нет, выбранный текст на сайте не будет найден.
Кэш-копия. Посмотрите код страницы в кэш-копии. Обращайте внимание на дату формирования кэш-копии. Кэша может не быть, если был использован метатег robots noarchive.
- Парсеры. Страницу можно отрендерить в любом парсере, например, ScreamingFrog.
- Bertal. Вставьте ссылку, выберите User-Agent, поставьте галочку и получите код. Этот веб-инструмент рекомендует техподдержка Яндекса — они сами пользуются им.
Итак, мы выяснили, какие блоки не отдаются в рендер. Далее составляем список элементов, которые влияют на качество SEO сайта, и указываем их статус — есть рендеринг или нет. Передаем этот список разработчикам — они исправляют ошибки.
3. Некорректные метатеги и переменные в метатегах
Варианты ошибок:
- слетевшие переменные шаблона Title;
- слетевшие Title и Description;
- замена метатегов с одной страницы метатегами с другой.
Во всех этих случаях видимость страниц падает, и они не индексируются.
Столкнувшись с этой проблемой, мы начали вытягивать код страницы через валидатор микроразметки Search Console, Bertal.ru и Яндекс.Вебмастер. Все было нормально до тех пор, пока мы не решили посмотреть кэш-копии по выборке страниц. Там обнаружили баг: на странице про рыбалку в Pompano Beach были метатеги, предназначенные для страницы про рыбалку в Cancun.
Мы сообщили об ошибке разработчикам, и они выяснили, что скрипт, отвечающий за переадресацию страницы, работал некорректно. Мы это исправили, и видимость страницы восстановилась.
4. Блокировка сканирования скриптов в robots.txt
Мы столкнулись с этой проблемой на сайте MyBook.
Часть скриптов были заблокированы, и поисковые роботы Google и Яндекс не видели содержимое страницы.
Решили проблему просто: отключили блокировку скриптов в robots.txt. После этого следили, чтобы никакие скрипты больше не блокировались.
5. Тяжелые скрипты мешают индексации страниц
Важно, чтобы робот имел возможность отрендерить JavaScript и получить первичный HTML-код не более чем за 5 секунд. В противном случае он уйдет, не просканировав страницу.
Пример: мы работали с сервисом по проверке контрагентов 1cont.ru. На момент начала работ у нас была проблема с индексацией: из 20 млн страниц Яндекс проиндексировал 1,2 млн, а Google — всего 70 тысяч.
Мы выписали все скрипты, которые тормозили скорость загрузки страниц, отдали их разработчикам, которые оптимизировали загрузку этих скриптов (часть была сжата, часть загружалась асинхронно, загрузку наименее значимых для отрисовки страниц скриптов отложили до полной отрисовки страницы. Результат: Яндекс проиндексировал 20 млн страниц, а Google — 17 млн.
Важно в процессе оптимизации случайно не снести скрипты метрики и аналитики. Так случилось у нас: в итоге индексация начала расти в геометрической прогрессии, а трафик стоял на месте.
Чтобы выявить объемные скрипты, мы используем сервис Google PageSpeed Insights. Он составляет список скриптов и указывает их размер. Аналоги — GTmetrix.
Чтобы упростить мониторинг скриптов, регулярно проверяйте:
- доступность страниц (код ответа сервера);
- корректность шаблонов метатегов;
- контент на ключевых группах страниц.
Используйте инструмент «Мониторинг важных страниц» в Яндекс.Вебмастере: он умеет отслеживать метатеги, канонические URL и код ответа серверов. Минус — не умеет следить за рендерингом конкретных блоков.
Это умеет делать «Радар» Топвизора. Инструмент показывает ответ сервера, метатеги, контент. В нем можно размечать блоки, и если рендеринг по ним отключится, «Радар» об этом оповестит.
Чек-лист для SEO-специалистов при работе с проектом на SPA
SSR корректно работает на всех страницах и во всех блоках.
В robots.txt нет заблокированных скриптов.
Во всех разделах страницы — корректные шаблоны метатегов.
Все страницы индексируются.
Поисковые боты свободно перемещаются по ссылкам.
Настроен регулярный мониторинг доступности страниц и контента на них.
Настроены счетчики Яндекс.Метрики и Google Analytics.
Выводы
Технология SPA становится всё популярнее, и шанс, что вы с ней встретитесь (особенно, на больших проектах) возрастает с каждым годом. Большие плюсы для разработки и пользователей компенсируют минусы для SEO — отсутствие рендеринга “из коробки” и особое внимание к технической оптимизации.
Есть несколько самых популярных видов рендеринга (подробнее про обоснование типа рендеринга в нашей статье). «Золотым стандартом» является SSR (Server Side Rendering) — обработка JS кода в HTML за счет мощностей вашего сервера.
Самое важное при работе с сайтами на JS: регулярно обращать внимание на кеш страниц в поисковиках и настроить мониторинг корректного рендеринга всех критичных для SEO текстовых блоков блоков.
Очень интересная статья, было приятно читать, все на доступном языке много нового для себя узнала.
В закладки.
"Самое важное при работе с сайтами на JS: регулярно обращать внимание на кеш страниц в поисковиках и настроить мониторинг корректного рендеринга всех критичных для SEO текстовых блоков блоков." - вот это нужно написать большими буквами и на видном месте повесить в каждой компании, которая имеет сайт на JS.
Полезная история про SEO для SPA, отдельная благодарность за чек-лист)
Полезно.
Было бы интересно с живым кейсом ознакомиться - изначальные условия, проблематика, решения и результаты.
Спасибо!
В этой статье то, что наиболее часто встречаем на проектах, с которыми работаем. Также один из проектов, о которых много где рассказывал - mybook.ru. Мы с ними за 4 года работы проходили 2 полные смены стека технологий и там есть кейс и анти-кейс) Расшифровку можно здесь глянуть - https://www.ashmanov.com/education/articles/kak-rabotat-s-spa-saytami-opyt-proekta-mybook/.
А так из относительно нового - ничего нового) Если все сделано корректно с технической точки зрения, все хорошо. Только это бывает очень редко, а со SPA еще и мониторить надо постоянно, потому что какой-нибудь компонент может вдруг перестать рендериться или начнет отдавать боту и браузеру разный контент)
Спасибо!)
На один из кейсов как раз есть ссылочка в статье: https://vc.ru/u/511394-kite-da-ru/127871-kak-uporotsya-v-proekt-i-vypolnit-svoy-zhe-prognoz-na-2-mesyaca-ranshe
Пасиб, проморгал ссылку. Но хотелось бы поновее - за 2-3 года, по моим наблюдениям, даже Яндекс худо-бедно научился с JS работать на базовом уровне, тогда было вообще ни в зуб ногой.
Я со SPA не работал, а хотелось бы на рабочие процессы и вопросы посмотреть.
Тема SPA не сильно раскрыта на просторах рунета, спасибо, что делитесь, это интересно и полезно!
NextJS, серверный рендеринг вместе с Apollo Client и хуками от Apollo - не не слышал. Статья как будто из 2015 года.
Это же не для разработчиков статья. Технически-то много реализуемо, просто в рамках SEO надо такие вещи наперед продумывать и закладывать в проект.
Объясните, пожалуйста, зачем сейчас в РФ уделять какое-либо внимание Google-сервисам? Как по мне, то будет ситуация как с Китаем. Раньше или позже, но или они нас пошлют или мы их. Я сейчас даже деньги клиента не могу вернуть с Гугл Рекламы, что на балансе остались. Ни на почту ни на телефоны они тупо не отвечают. Ну так себе качество сервиса. И за последний месяц очень сильно стала заметна разница в поисковой выдаче между Гугл и Яндекс, если я ищу что-то на территории РФ. В Яндексе более релевантная выдача. Чисто стратегически - зачем цепляться за то и тратить время и деньги, что в скором времени отвалится?
Отвалится или нет - бабушка надвое сказала, а вот то, что это поисковик на смартфонах по дефолту - важно. И во многих смыслах намного более предсказуем в продвижении, когда вы ещё можете что-то спрогнозировать на старте и получить ожидаемый результат.
Виктор, уже перестали модерировать отзывы в Гугл картах в РФ. Тут же писали, кстати. Может уже сосать перестанем и начнем как Китай на ход вперед работать, а не пока петух в жопу клюнет.
Да я-то не возражаю. Но поисковую систему я не создам, и что-то не видать желающих - даже при наличии бюджетов. На "Спутник", надо понимать, денежки выделялись, результат печален.
Отзывы в Гугл блокнули не потому, что что-то там - просто туда болезные из сопредельной страны начали фотки трупов заливать в промышленных масштабах. Это, однако, никак не отменяет факта, что гуглоиды живут "повесточкой", и реально могут прекратить работать с рунетом по отмашке.
И сразу - у меня нет имперских замашек, как привыкли некоторые кричать. Начните что-то своё уже делать. Пока есть возможность создать конкурентные продукты. Раньше, благодаря чиновникам не было. Появился шанс.
Комментарий удален модератором