Как не потерять поисковый трафик, внедряя технологии SPA

Одностраничные приложения (SPA, single page application) быстро становятся стандартом веб-разработки. На эту технологию переводят свои ресурсы такие техногиганты, как Facebook, Google, Яндекс, Mozilla, Netflix. Она подходит для интернет-магазинов, СМИ, корпоративных порталов и большинства других типов сайтов. От лица агентства-интегратора MST сегодня расскажем про достоинства и недостатки этой технологии и разберем несколько кейсов.

SPA — это одностраничный сайт, на котором контент подгружается без перезагрузки страницы, в ответ на какое-либо действие пользователя. У таких сайтов много достоинств:

Конечно, идеальных технологий не существует, и у SPA есть свои минусы.

Перед внедрением любой технологии важно проводить оценку рисков и мероприятия по их минимизации.

Ещё один весомый плюс SPA -- возможность использования PWA. Это плагин плюс набор параметров на сервере, которые добавляют сайту дополнительные функции. Главные из них -- продвинутое кеширование и возможность сохранить сайт как приложение на смартфоне.

Зайдя с мобильного браузера, пользователь увидит предложение «добавить приложение на главный экран» и в дальнейшем сможет работать с ним в оффлайн-режиме. Приложение имеет свой собственный кэш на устройстве, где после первоначальной загрузки хранятся ресурсоемкие элементы (дизайн, статичный контент, офлайн скрипты), что ускоряет дальнейшее взаимодействие с сайтом.

Еще одной важной фишкой является работа форм офлайн. Введенные в форму данные сохраняются и отправляются на сервер при подключении к интернету. Больше не будет обрывов конверсионной воронки из-за слепой зоны в метро или в лифте.

PWA наиболее актуальны для тех компаний, у которых основная масса клиентов активно используют сайт с мобильных устройств.

Самая главная проблема SPA, из-за которой при неправильной реализации можно потерять большую долю органического трафика на сайт, состоит в том, что одностраничные JS-приложения не индексируются большинством поисковых систем. Роботы Яндекса работают на основе устаревшего движка Chromium 41, который не поддерживает технологию CSR (Client-Side Rendering, рендеринг на клиенте). Именно эта технология обеспечивает «сбор» страницы в браузере пользователя. Заходя на сайт, робот поисковой системы видит лишь белый экран.

Выход в том, чтобы проводить рендеринг заранее, до обращения браузера к серверу, напрямую на сервере. Для этого используется технология SSR: Server-Side Rendering, (серверный рендеринг). На сервере эмулируется браузер, поддерживающий CSR, в нём рендерится HTML-страница и отдается в браузер пользователю, а также индексирующему роботу.

К сожалению, при использовании полного SSR существенно снижается скорость загрузки относительно «чистого» CSR. Обеспечить комфортную для пользователей скорость работы сайта поможет только кропотливая работа по разбору страниц на блоки, их анализу и оптимизации.

«Тяжелые» динамичные блоки дизайна можно оставить рендериться на стороне клиента, а самые важные блоки с текстовым контентом и инфографикой нужно максимально облегчить и рендерить на сервере. Внешние скрипты тоже придётся оптимизировать: часть запускать асинхронно, часть кешировать на сервере, какие-то объединить по возможности.

CSS-стили разносятся по разным файлам в зависимости от важности и выстраиваются в очередь загрузки. Для подгрузки изображений первого экрана и другого мультимедиа-контента лучше использовать CDN (сontent delivery network, распределённая сетевая инфраструктура для доставки контента, которая берет на себя оптимизацию доставки файлов), а также подключить сервисы автоматического сжатия изображений по форматам, размерам, качеству и весу.

Для оптимизации остальных изображений лучше использовать технологию lazyload. «Ленивую подгрузку» контента поисковые системы рекомендуют использовать только для контента, который не понадобится пользователю в настоящий момент. Например, если он не доскроллил до конца страницы, изображения в самом низу загружать не требуется. Внедряя технологию, важно соблюдать требования поисковых систем, описанные в документации для разработчиков.

В некоторых случаях можно отдавать пользователям CSR-версию сайта, а роботам поисковых систем -- SSR-версию. Но для использования этого метода нужно провести анализ рисков: мы теряем пользователей устаревших браузеров, пользователей некоторых мобильных приложений; при долгой загрузке сайта в сетях edge или 3g пользователь будет какое-то время видеть пустую страницу. Наконец, могут появиться проблемы с некорректным определением user-agent’ов, в результате чего уже перед поисковым роботом откроется пустая страница.

Поисковики знают о проблемах с SPA-сайтами. И хотя Google утверждает, что научился их индексировать, а у Яндекса есть специальные метки в URL и мета-теги в коде страницы, которые помогают боту узнать о существовании ее HTML-версии, рисковать и полагаться на это пока не рекомендуется. Слишком часто встречались случаи некорректного индексирования материала, даже при соблюдении всех требований поисковых систем.

Сотрудники Яндекса не скрывают, что их поисковые роботы пока так и не подружились с SPA.

Заказчик, представляющий банк «Уралсиб», пришёл к нам с жалобой на падение трафика из поисковых систем почти вдвое после работы предыдущего подрядчика. Их SPA-сайт вообще не индексировался Яндексом, а Google индексировал его с задержками и не полностью. В первую очередь мы настроили серверный рендеринг страниц, продумав баланс между количеством индексируемого контента и скоростью рендеринга.Затем исправили ошибки HTML и CSS-кода, устранили все битые ссылки и 301-редиректы, навели порядок в мета-тегах. Выстроили систему rel=«canonical» на всех html страницах (закрыв дублирующиеся разделы сайта). Настроили главное зеркало сайта и убрали дубли главной страницы. Мы составили семантическое ядро и разработали на основе него новую структуру сайта в виде гигантской mind-карты. Тексты оптимизировали под продвигаемые запросы. Проверили внешние ссылки, избавились от некачественных, договорились о гостевых постах с авторитетными новостными ресурсами. Уже в течение первого месяца работы, после устранения основных проблем удалось не только остановить падение трафика на сайт, но и получить получить рост. Дальнейшие работы вывели сайт на лучшие показатели за все время существования.

У провайдера Дом.ru сложная сеть сайтов и сервисов: 2 основных домена, 54 региональных поддомена и множество технических ресурсов. Сеть построена на нескольких самописных движках на нескольких языках программирования. В ней множество независимых элементов управления, связанных между собой с помощью микросервисов.

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

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

Продвижение сайта мы начали с того, что с нуля собрали семантическое ядро и провели hard-кластеризацию с учетом типа выдачи, геозависимости и коммерциализации. Переработали структуру и все основные разделы сайта под новые типы запросов и создали новые посадочные страницы.

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

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

При очередном обновлении на сайте выключился серверный рендеринг SPA-разделов, что привело к резкому падению органического трафика. Повторная настройка серверного рендеринга на таком огромном количестве страниц заняла бы много времени, поэтому мы решили срочно поднять AMP-версию наиболее трафиковых и конверсионных страниц (по ним уже велись разработки ранее), тем самым спасти контент хотя бы для мобильной версии, закешировав его в ПС. AMP, Accelerated mobile pages -- технология создания облегчённых веб-страниц, которые быстро открываются на мобильном устройстве из кеша Google. Параллельно с работами по возвращению и доработке SSR мы начали разработку инструмента автоматического тестирования корректности рендеринга.

KPI по объему трафика, привлекаемого из органического поиска, был выполнен на 115%. Поисковый трафик вырос на 20% по сравнению с аналогичным периодом прошлого года, при снижении частотности брендовых запросов.