BDD 2018: SPA+SEO. Как ПС индексируют и ранжируют JavaScript-rich сайты

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

В один прекрасный день звонит маркетолог аль владелец проекта и сообщает чудесную новость: «Ребята, наш брат тут посовещались с разработкой и решили переехать на SPA-сайт для JS-движке ReactJS. Подготовите нам рекомендации?».

Ваши первые мысли, чрез (год) осознания масштаба проблемы (в зависимости от того, сталкивались ваша сестра с JS-сайтами или нет):

• «Блин, ну вот повально же нормально было, зачем?»
• «WTF??»/«Это до этого часа что такое?»

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

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

Яко такое JS-сайты, SPA, React и т.д.

Что же это следовать зверь такой «SPA-сайты» и чем они отличаются с статических сайтов на HTML, динамических на PHP и т.д.

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

JavaScript изначально создавался для того того, чтобы сделать web-страницы «живыми». Программы получи и распишись этом языке называются скриптами. В браузере они подключаются напрямую к HTML и, (как) будто только загружается страничка, тут же выполняются.

JavaScript создан, с тем чтоб сделать веб-страницу интерактивной и максимально интересной в целях пользователей.

Single Page Application в переводе на красноармейский язык означает «одностраничное приложение». Это web-приложение, работающее нате языке JavaScript, компоненты которого (JavaScript-файлы, модули, CSS-файлы и т.д.) загружаются всего один раз на одной странице, а контент подгружается по необходимости.

JS-фреймворки и библиотеки — сие инструменты для построения динамических веб/мобильных/настольных приложений в языке JavaScript.

В чем отличие от статических сайтов

Основа отличие динамических сайтов на JavaScript от статических в часть, что для поисковых систем это до этих пор «магия», которая усложняет индексацию на всех этапах обработки контента.

Визуализация с сайта elephate.com

Нормальный для SPA-сайта HTML-код

Страница полностью строится бери стороне браузера пользователя. Браузер выполняет JavaScript и создает контент получи и распишись лету.

Контент, который видит пользователь, меняется в зависимости с взаимодействия с SPA-сайтом, при этом весь процесс происходит кроме перезагрузки страниц и на одном URL.

Так видит абонент страничку на проекте mybook.ru:

А так для пользователя выглядит правительственный сайт JS-фреймворка React:

И вдруг внезапно. Так видит поисковой кавасаки Google ту же самую страничку:

А так угоду кому) поискового бота Яндекса выглядит официальный сайт JS-фреймворка React:

Краулер ПС устроить такой контент не способен. Нарушается сразу едва основополагающих принципов индексации.

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

Бери последнем пункте стоит остановиться подробнее.

Что насчет JS говорят поисковые системы?

Как думаете, что случится с проектом там переезда на SPA-движок, если ничего не заняться и оставить все как есть?

Как разные JavaScript движки индексируются поисковиками? Основано бери эксперименте, опубликованном на MOZ

Google проиндексирует и обработает большую выпуск контента. Для обработки JavaScript используется механизм получай основе браузера Google Chrome. Правда, со своими особенностями, о которых наш брат еще расскажем.

Но в Рунете есть еще и Яндекс, какой-никакой мы просто не можем игнорировать. Яндекс задолго. Ant. с сих пор обрабатывает динамический контент (JavaScript, AJAX) в порядке эксперимента. Про корректной индексации необходимо наличие полной HTML-копии страницы.

Официальная оповещение из блога Яндекса

Комментарии там же, справка на официальную рекомендацию Яндекса по индексации JS и AJAX

Вотан из самых известных случаев произошел в начале июня — Яндекс перестал индексировать сайты, созданные получи конструкторе Wix, после того как конструктор изменил алгорифм генерации страниц.

По заявлению представителей Яндекса, пока все хорошо и проблем с индексацией сайтов на Wix пропал. Но факт остается фактом. Если вы никак не хотите проблем с индексацией на проекте — нужна статичная HTML-гальвано для Яндекса.

Возвращаясь к вопросу, что произойдет чрез (год) переезда — клиент потеряет трафик и, как следствие, чистые. Хорошо, если у него есть SEO-шники, у которых позволено запросить рекомендации).

Но прежде давайте разберемся, на хрена клиенты выбирают JS-фреймворки, несмотря на возможные проблемы.

С чего клиенты выбирают JS-фреймворки

Несмотря на то, яко для многих крупных проектов переход на JS-сердце — только дань моде, у JS-сайтов есть и настоящие плюсы.

Кухня пользователя

• Скорость. Отсутствие перезагрузки страниц обеспечивает быстрое связь с пользователем. От этого — максимально лояльная проекту слушатели и увеличение количества конверсий.
• Отзывчивый (Responsive) дизайн наместо адаптива. Благодаря этому увеличивается количество устройств и потенциальных пользователей.
• Расширенные внутренние резервы по персонализации контента. Зарегистрированному пользователю можно «собирать» максимально персонализированные страницы и разделы (умные ленты, рекомендации и т.д.).

Бахтарма разработки

• Модульность. Благодаря этой особенности JS-фреймворков становится что ль разделение продукта на компоненты, которые отдаются разным командам разработки. В итоге план собирается как конструктор из кубиков. А сроки разработки сокращаются следовать счет параллельной работы.
• Четкое разделение front-end и back-end команд разработки.
• Широкие потенциал по созданию архитектуры (можно собрать что приятно).
• Проекты проще в разработке — код значительно короче по причине возможности повторного использования компонентов.
• Разные платформы (desktop и mobile приложения) возьми основе одного кода.

Неочевидные плюсы SPA

• Конкурентоспособность для рынке труда. Переход на новую и современную технологию, которая неотложно активно развивается — возможность привлечь лучших разработчиков. Крутые спецы маловыгодный хотят работать с архаичными технологиями. А их присутствие в команде — много раз само по себе толчок к развитию.
• Рефакторинг. Иначе) будет то у вас две версии сайта (основной поддомен исполнение) десктоп-устройств и отдельный для мобильных), и над ними в всякая всячина время работали несколько команд разработки и верстальщиков, заблаговременно или поздно вы столкнетесь с необходимостью делать рефакторинг пользу кого развития проекта. В этом случае JS-фреймворки отличное вотум. Вы сможете объединить все версии на одном коде, какой-никакой значительно легче поддерживать и развивать дальше.

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

Чего же все-таки делать по SEO, если с целью проекта переход на SPA — единственный путь развития с точки зрения маркетинга и продукта?

Варианты рендеринга, плюсы и минусы

Лакомиться очень важный технический термин, который в свете SPA-сайтов нужно взять на заметку и понять. Это понятие «рендеринг». Этот термин — тумблер к успешному индексированию проекта.

Рендеринг — это процесс перевода JS-стих в стандартный HTML-код, понятный для поисковиков.

Т.е. про того, чтобы отдавать поисковому роботу контент в понятном про него виде, обязательно нужно производить рендеринг.

Неоднократно на этапе выбора варианта рендеринга вас ждет общение-баталия с клиентом и командой разработки. На этом этапе имеет большое значение отстоять свою точку зрения — рассказать о том, словно каждый вариант отразится на SEO проекта. Каждую ресурсоемкую задачу нужно четыре обосновать (спойлер: она и правда ресурсоемкая). Скорее просто-напросто, разговор будет происходить так.

WRS — технология обработки JS через Google

Разработка: «Давайте не будем ничего мастерить? У нас хватает других задач. Просто переведем расчет на JS, а поисковики уже сами во всем разберутся. Google — умеет индексировать JS, с через технологии WRS. Вот ссылка на официальный источник Google — разбирайтесь, разик не в курсе».

WRS (web rendering service) — это технология рендеринга, основанная держи обработке JS с помощью браузера Google Chrome (также ее называют CSR — client side rendering, т.е. рендеринг нате стороне клиента).

Когда можно использовать. Если абсолютно забыть про Яндекс (и другие ПС) и делать сайт исполнение) Google. В то же время из этой а ссылки следует, что технология основана на браузере Google Chrome M41. А сие браузер 2015 года, поэтому множество новых возможностей склифосовский проигнорировано и возможна некорректная обработка. Сравнить можно на этом месте.

Минусы:

По официальным заявлениям умеет индексировать JS как Google. Про остальные ПС можно забыть то есть (т. е.) использовать более сложный и опасный метод — подмену числом User-Agent.

• Старый браузер Google Chrome 41 2015 годы.
• Google не действует как настоящий браузер (примем, не переходит по ссылкам onclick).
• Оптимизирует домашние ресурсы на загрузку — не будет ждать длительнее 5 секунд.
• Anti-mobile First. Рендеринг на мобильных устройствах в любом случае займет кучу времени (в зависимости с характеристик аппарата). Например, чтобы обработать 1MB JS на мобильном устройстве Samsung Galaxy S7 нужно ~850ms, а для менее производительном Nexus 5 уже ~1700ms!

Статичная HTML-гальвано + AJAX Crawling Scheme

Разработка: «Нам важен Яндекс. Давайте выискивать другое решение. Например, у Яндекса есть инструкция, в которой предлагается пустить в дело для JS сайтов AJAX Crawling Scheme. Аналогичная указание есть и у Google».

Суть метода — для каждой индексируемой динамической страницы должна составлять статичная HTML-версия на отдельном Url+ ?_escaped_fragment_= в URL. Вот и все нужно использовать метатег в коде динамической страницы, затем) чтоб(ы) сообщить боту о наличии HTML-версии страницы.

Т.е. для того чтобы проиндексировать http://site1.ru/example/, боту нужна лист http://site1.ru/example/?_escaped_fragment_= с идентичным содержимым.

!Получи сегодня это официальная рекомендация от Яндекс за поводу JS и AJAX сайтов.

Минусы:

• Это устаревшая методика, которая отмечена Google как «нежелательная» с 2015 возраст. Более того, после лета 2018 года Google перестает оказывать помощь эту схему.
• Неоднократно появлялись кейсы, когда объяснение с _escaped_fragment_ просто игнорируется Google в пользу JS-версии. Хоть (бы), Юрий Хаит рассказывал о таком на F1.
• Также страдает краулинговый смета, который выделяют поисковые системы на сканирование сайта — поисковому роботу нужно заходить на два URL вместо одного. При большом количестве страниц вкушать вероятность, что поисковой робот не будет злободневно добавлять и обновлять нужный контент.

Когда можно пустить в дело: нежелательно.

Аутсорс сервисы — prerender.io и пр.

Разработка: «Мы можем возвернуть рендеринг на аутсорс. Сейчас есть разные сервисы, которые предоставляют приманка ресурсы (сервера) для обработки JS (рендеринга) и берут получи себя демонстрацию HTML-версии страниц.. Например, prerender.io, renderjs.io».

Минусы:

• Подневольность от внешних ресурсов. Если сервис лагает, придется кончиться всю цепочку от фиксирования бага, общения с поддержкой поперед его исправления. Это долго, проект в это дата не индексируется нормально.
• Дорого на больших объемах. Вот хоть, Prerender.io, с обновлением кэша раз в сутки — 360 $/лунный (серп (50 тыс.—100 тыс. страниц).

Update согласно технологии (июль-август 2018):

• Для рендеринга используется инструмент на основе Google Chrome 61, в ближайших планах анаболизм до Google Chrome 67. Т.е. для рендеринга используется незначительно более современный браузер, чем в технологии WRS.
• Более мало-: неграмотный использует _escaped_fragment для демонстрации HTML-версии страницы. Нате сайте до сих устаревшая информация. Боты определяются после User-Agent и им отдается HTML-версия.
• Фикс по-прежнему высока для крупных проектов: помимо озвученных на сайте тарифов — рендеринг 2 млн страниц с обновлением кэша некогда в 1-3 дня, стоимость — 3,080‒9,232 $.

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

SSR — рендеринг для стороне своих серверов

Разработка: «Что ж, давайте генерировать рендеринг на стороне наших серверов».

SSR (Server Side Rendering) — рендеринг возьми стороне сервера, т.е. обработка JS кода происходит на стороне серверов клиента. Только что не у всех современных JS-фреймворков и библиотек есть компонент пререндера. За примером далеко ходить не нужно, реализация серверного рендера для Angular, React, Vue.

Боты определяются после User-Agent и им отдается статичная HTML-разновидность, пользователю — динамическая (возможны вариации в виде изоморфного JavaScript, а это уже другая история).

Минусы:

• Большая погрузка на сервер.
• Нужен высокий уровень скиллов с команды разработки, сложная задача для внедрения, которая потребует большое метраж часов back-end’а.
• Время отдачи первой версии про бота и клиента. Первый слепок должен отдаваться максимально мгновение ока. Необходимо настраивать кеширование и своевременное обновление кеша.
• Нужно безостановочно мониторить доступность страниц (код ответа сервера), метатеги и экстремально желательно сам контент на странице (может переломиться рендер блока с текстом).
• Для безопасной работы нужно любые нововведения тестить безлюдный (=малолюдный) на боевом сервере.

!Важно. Один из главных плюсов JS-фреймворков — его модульность — становится существенным минусом — переломиться может ЧТО угодно и КОГДА угодно.

Бывают ситуации, нет-нет да и страница отдает корректный 200ОК, но в индексе — бессодержательно (только head и footer), или нет части контента. Может разломаться рендер блока с текстом, рендер на пагинации, рендер комментариев и т.д.

Методика выбора типа рендеринга

Только Google → ничего малограмотный делаем, выбираем WRS

Нужен Google+Яндекс, небольшой программа → можно использовать аутсорс

Нужен Google+Яндекс, осязательный проект → используем SSR

Поведенческие — вишенка на торте

В (то не ясно, что с поведенческими факторами. От языкоблудие «совсем».

Дополнительные настройки счетчиков Метрики и Google Analytics позволяют фиксировать. Ant. распустить перезагрузку страницы и смену URL — из этого считаются метрики глубины просмотра и времени держи странице.

Но насколько корректно все измеряется и учитывается сверху JS-сайтах — не ясно. В любом случае остаются безлюдный (=малолюдный) зафиксированными передвижения мыши по экрану.

Нашей командой запущен опыт, который даст ответ на этот вопрос. Же это будет чуть позже, результатами обязательно поделимся!

Общие рекомендации

• Выбираем артикул рендеринга.
• Отдаем поисковикам рендер всей страницы. Каждой странице — особый URL (для этого есть компонент роутинга в JS-движке).
• Капитан: НЕ менять структуру URL при переезде. Очень старшие риски ошибки, которая наложится на все остальное. Второстепенный стресс для ПС. Если проект создается с нуля — отгрохать всю структуру заранее.
• Кэшируем и обновляем. Чтобы максимально короткий срок отдавать страницу пользователю — используем кэширование. Для снижения нагрузки для сервер кэш можно хранить на CDN.
• Кэш нате листингах/категориях/списках желательно обновлять 3-4 раза в день, либо после появления нового контента. Редакторские материалы есть отправлять на принудительный переобход в ПС.
• Не используем хеш в URL (# и /#!/). Возможны проблемы с индексацией таких URL.

Т.е. безрадостный URL: example.ru/#/first-page, example.ru/#!/first-page, благоприятный URL: example.ru/first-page

• Используем ссылки формата a href, невыгодный onclick. Рекомендация с конференции Google.

• Настраиваем корректный 404 опровержение сервера. Для SPA-сайта это нестандартная, но выполнимая миссия.

P.S. SPA-сайты — тренд в разработке. Не нужно бояться проблем с SEO. Детальная надрочка и своевременная фиксация багов снизит возможные проблемы рядом переезде.

Презентация доклада

Источник: www.seonews.ru