SEO-рекомендации для SPA-сайтов

Kite. Экспертиза

Содержание

1. Цель документа
2. Основные термины
3. Методология выбора типа рендеринга
4. Обоснования для разработчиков
5. Критичные SEO-элементы
6. Общие рекомендации
7. Проверка и тестирование
8. Мониторинг
9. Инструкции по настройке счетчиков для аналитики

Цель документа

Дать понятную методологию выбора типа пререндера для SPA-сайта, снабдить максимально актуальной и полной информацией по работе с JavaScript-rich сайтами.

Основные термины

JavaScript

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

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

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

Single Page Application (одностраничное приложение)

Web-приложение, работающее на языке JavaScript, компоненты которого (javascript-файлы, модули, css-файлы и т. д.), загружаются единожды на одной странице, а контент подгружается по необходимости.

JS-framework’и и библиотеки

Инструменты для построения динамических веб/мобильных/настольных приложений на языке JavaScript. Например, React, Angular, Vue.

Рендеринг

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

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

Только
Google

Ничего не делаем, выбираем WRS

Нужен Google + Яндекс, небольшой проект

Можно использовать аутсорс

Нужен Google + Яндекс, большой проект

Используем SSR

Обоснования для разработчиков

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

Разработка:

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

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

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

*UPD: С 7 мая 2019 года Googlebot для рендеринга страниц использует последнюю 74 версию. Теперь Googlebot поддерживает более 1000 новых функций, в том числе:
— ES6 и новые функции JavaScript;
— IntersectionObserver для отложенной загрузки;
— API веб компонентов v1.

Технология рендеринга WRS основана на браузере Google Chrome 74

Минусы

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

⸺ Google не действует как настоящий браузер (например, не переходит по ссылкам onclick).

⸺ Оптимизирует свои ресурсы на загрузку — не будет ждать дольше 5 секунд.

⸺ Рендеринг на мобильных устройствах в любом случае займет кучу времени (в зависимости от характеристик аппарата). Например, чтобы обработать 1MB JS на мобильном устройстве Samsung Galaxy S7 нужно около 850 ms, а на менее производительном Nexus 5 уже почти 1700 ms!

Разработка:

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

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

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

Минусы

⸺ Это устаревшая технология, которая отмечена Google как «нежелательная» с 2015 года. Более того, после лета 2018 года Google перестает поддерживать схему.

⸺ Неоднократно появлялись кейсы, когда версия с _escaped_fragment_ просто игнорируется Google в пользу JS-версии. Например, Юрий Хаит на конференции F1.

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

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

Разработка:

Мы можем отдать рендеринг на аутсорс. Сейчас есть разные сервисы, которые предоставляют свои сервера для рендеринга. Например, prerender.io, renderjs.io.

Для рендеринга используется механизм на основе Google Chrome 61, в планах обновление до Google Chrome 67.

Минусы

⸺ Зависимость от внешних ресурсов. Если сервис лагает, придется пройти всю цепочку от фиксирования бага, до общения с поддержкой до его исправления. Это долго, проект в это время не индексируется нормально.

⸺ Дорого на больших объемах. Например, Prerender. io с обновлением кеша раз в сутки — 360 $/месяц (50 тыс. — 100 тыс. страниц).

⸺ Крайне важно! Также использует _escaped_fragment. Планы после 2 кв. 2018 неизвестны.

Update (07.2018):

• Больше не использует _escaped_fragment для демонстрации HTML-версии страницы. На сайте до сих пор устаревшая информация. Боты определяются по User-Agent и им отдается HTML-версия.

• Цена по-прежнему высока для крупных проектов: кроме озвученных на сайте тарифов — рендеринг 2 млн страниц, с обновлением кеша раз в 1−3 дня, стоимость 3,080−9,232 $.

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

Разработка:

Что ж, давайте производить рендеринг на стороне нашего сервера. В большинстве JS-фреймворков есть поддержка пререндера (SSR — Server Side Rendering). Например, React, Angular, Vue.

Минусы

⸺ Нагрузка на сервер.

⸺ Нужен высокий уровень скиллов от команды разработки, сложная задача для внедрения.

⸺ Время отдачи первой версии для бота и клиента. Первый слепок должен отдаваться максимально быстро. Необходимо заморачиваться с кешированием и своевременным обновлением кеша.

⸺ Нужно постоянно мониторить доступность страниц (код ответа сервера), метатеги и крайне желательно сам контент на странице (может сломаться рендер блока с текстом).

⸺ Для безопасной работы нужно любые доработки тестить не на боевом сервере.

!!!Реализация серверного рендера для Angular, React, Vue.

Можем помочь в выборе движка и типа рендеринга, который больше подойдет для вашего проекта

Получить консультацию

Критичные SEO-элементы

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

Стандартные метатеги (Title, Description), подзаголовки (h2-H6), все остальные метатеги (meta robots, canonical и т. д.)

Графическая информация, со всеми метатегами (title, alt и т. д.)

Ссылки на страницах, как внутренние, так и внешние, со всеми атрибутами (например index, follow и т. д.). Ссылки использовать только в формате a href, никаких onclick

Текстовое содержание страницы с используемым форматированием (абзацы, подзаголовки и т. д.). !Важно. Проверяйте, чтобы в подзаголовках, тексте не было комментария кода (часто бывает на ReactJS)

Меню и дополнительные элементы навигации — хлебные крошки, дополнительные блоки со ссылками на разделы, страницы и т. д.

Микроразметка: OG разметка, разметка хлебных крошек, разметка книг, контактов и т. д.

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

Поисковикам необходимо отдавать рендер всей страницы. Каждой отдельной странице — отдельный URL. (Для этого есть компонент роутинга в JS-движке).

НЕ менять структуру URL. Очень большие риски ошибки, которая наложится на все остальное.

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

Необходимо максимально быстро обновлять кеш страницы, если он используется. В идеальном виде — сразу после появления нового контента. Если нет — то на хабовых страницах хотя бы 3—4 раза в сутки. Плюс редакторские материалы дополнительно можно закидывать на принудительный переобход.

Каждая страница должна отдаваться по своему отдельному URL. Не использовать хеш и хешбенг (# и /#!/) в URL — будут проблемы со сканированием. Плохой URL— example.ru/#/first-page, example.ru/#!/first-page. Хороший URL — example.ru/first-page.

Необходимо отслеживать не только состояние ответа сервера (200/404 и т. д.). Главное не забывать про наличие контента на странице. Так как может сломаться пререндер, страница будет 200 OK, но пустая. Есть два варианта — Радар Топвизор (можно использовать разметку нужных блоков) или свой плагин.

Очень внимательно с пагинацией — на страницах пагинации обязательно должны быть ссылки a href на следующие страницы и метатеги rel=»next», rel=»prev».

Все ссылки должны быть формата a href, не использовать onclick.

Должна быть корректная, быстро обновляемая карта сайта.

Проверка и тестирование

Посмотреть как GoogleBot в панели Вебмастера Google.

Инструменты для краулинга — Comparser, ScreamingFrog.

Оператор поиска site: с вхождением точной фразы по странице.

Google Chrome 74 (при использовании WRS).

Мониторинг

Радар Топвизора — ответ сервера, метатеги, контент (с возможностью разметки важных фрагментов кода).

При разметке контента должна быть возможность выделить важные фрагменты кода

Важные страницы в панели Вебмастера Яндекс.

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

Инструкции по настройке счетчиков для аналитики

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

Google — инструкция по настройке счетчика.

Яндекс общая, из неё частная.

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

Что мы предлагаем?

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

Отправить заявку

Оставляйте комментарии

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

Reactjs & SEO — isomorph rendering in latest Chrome browser | by Yury Egorenkov

Мы делали tobox.com почти 1,5 года. Боролись с изоморфностью. Хочу поделиться опытом. (react, webpack, scss, prax) Сделали для себя, с удовольствием пользуемся и хотим поделиться. Будем очень признательны за перепосты и рекомендации.

Видео о том, что такое renderjs и как им пользоваться.

С изоморфностью reactjs приложений пришлось хлебнуть по полной программе. Все хорошо работает, если приложение очень простое. Если есть обращения к базе, и они не тривиальные, т.е. рендерим компоненты, оформляем подписки, отправляем запросы, получаем ответы, редюсим в стейт, обновляем компоненты. Реактивная связка, которая дает гибкость в разработке разлетается на куски при сервер рендеринге. Так же сложности вызывают асинхронные ajax запросы, работа с сокетами, менеджмент подписок-отписок, использование современных возможностей браузера, включая localstorage, geo location и т.д., на сервере их просто нет. Во всех этих случаях необходимо дополнительно работать над разделением кода на сервер-клиент. Изоморфностью не сильно пахнет. Это больше похоже на разработку сервера и клиента отдельно, с перекрывающимися частями, например вьюшками.

Кроме того, SPA имеет большое преимущество в виде статически распространяемых файлов. Т.е. собрали — положили на cdn, cloudflare закэшировал, у клиента закэшировалось — все летает, круто. Если отдельно делать сервер-сайд, то это опять выливается в балансеры, инфраструктуру и т.д.

По сути рендеринг на сервере нужен для двух больших вещей
1. Что бы наше SPA правильно проиндексировали поисковики. Они сейчас JS не выполняют, и видимо, не будут.
2. Что бы наши пользователи могли поделиться нами в соц. сетях и увидеть красивый сниппет, а не заглушку нашего html.

1. Для поискового краулера (бота) скорость получения страниц должна не превышать 3–5 секунд. Мы пробовали использовать prerender.io. Впринципе, хорошое решение. Но есть несколько но. PhantomJS в котором prerender крутит приложение отличается от современных браузеров. Отлаживать достаточно сложно, никакой информации почему не рендерится — нужно догадаться. На тяжелых приложениях (наш tobox.com ~30 запросов на страницу) prerender строил нашу страницу ~> 20 sec. После этого они страницу кэшируют и надеются, что умный краулер вернется через некотрое время посмотреть, не отвис ли сайт и тогда они эту кэшированную страницу ему отдают. Это тоже плохо, хотелось бы все время иметь up-to-date.

2. Вторую задачу, sharing in social networks, в целом можно решить отрендерив на сервере заголовок html с мета тэгами. Но тут опять, код в разных местах, сервер-сайд и т.д.

В общем, мы сделали свое решение и не на радуемся на то, как оно работает для нас. Общая идея такая. Дело в том, что SPA в браузере летает! Клик-switch почти мгновенно. Так почему же мы рендерим его так долго? Мы запустили на сервере настоящий Chrome. Открыли там наше приложение. Написали драйвер и сервис управления и проблема изоморфного рендеринга для нас решилась навсегда. Мы пишем только клиента. Короткая секция в nginx отправляет краулеры в наш сервис, который рендерит и отдает страницы за ~1–2 секунды. Что для поисковиков более чем. Они индексируют нас в несколько потоков, объем получается приличный. Сервис называется http://renderjs.io Если будет интересно, можем подсказать-помочь с подключением.

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

RenderJS Home

renderJS — это библиотека javascript, используемая для создания многократно используемых компонентов HTML5 (называемых гаджетами) для одностраничных веб-приложений.
Он также используется для быстрой интеграции существующих сторонних библиотек в существующие приложения.

Он разработан и поддерживается Nexedi для уменьшения дублирования кода между интерфейсом ERP5 и в качестве основы для приложений в магазинах приложений, таких как OfficeJS.

Определение гаджета

Определение гаджета renderJS состоит из одного файла HTML и его зависимостей JS/CSS, определенных в заголовке DOM.

На это определение ссылается URL документа HTML.

HTML также может содержать ссылку на гаджет интерфейс  URL, который действует как документация.

Минимальный пример:

 
<голова>   
<тело>
Минималистичный гаджет renderJS

 

Загрузка определения гаджета

Когда renderJS загружает новый URL определения, это:

1. получает HTML и анализирует его
2. сохранить копию ТЕЛА, чтобы клонировать его на каждом экземпляре
3. загружает все JS, CSS, определенные в HEAD
4. генерирует методы «класса», определенные . declareMethod и .declareJob

.

Нажмите здесь, чтобы увидеть больше

RenderJS легко настроить и начать работу.

Скачать файлы напрямую:

• RenderJS (последняя версия)
• RSVP.js (пользовательская версия)

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

Поскольку повсеместное написание кода с обратными вызовами часто усложняет сопровождение, было решено полагаться только на шаблон проектирования Promises/A+ для написания кода javascript в Nexedi.

Цель обещания — сделать код читабельным и удобным для сопровождения.

Если вы впервые читаете спецификации promises/A+, возможно, вы упускаете суть обещаний, поэтому прочитайте еще раз.

Мы начали использовать RSVP как реализацию промиса, совместимого с разными браузерами.
Мы исправили его, чтобы реализовать метод отмены для объекта промиса, который позволяет вручную прерывать выполнение промиса. Этот метод отмены не является частью спецификаций promises/A+ и поэтому не будет интегрирован в RSVP.

Такой метод время от времени обсуждается в репозитории обещаний/A+ в других реализациях обещаний или даже внутри нативного обещания Chrome. На данный момент никто не дает ему ту же семантику/спецификацию.

Наша реализация проста и понятна.

Код, основанный на renderJS, должен быть основан на промисе:

• не использовать setTimeout с помощью RSVP.delay
• используйте не addEventListener, а loopEventListener
• используйте не XMLHttpRequest, а jio ajax

Мы добавили новый вид промисов в RSVP.Queue, чтобы разрешить отмену списка цепочек обещаний. Вы должны использовать только Queue и никогда не использовать метод .then , а метод .push 9.0015 вместо этого.

Написание веб-приложения — это не только понимание renderJS. Он также обрабатывает навигацию по URL-адресам, имеет многоразовые гаджеты между проектами, обеспечивает обратную связь в пользовательском интерфейсе, обрабатывает ошибки, пишет тесты и т.  д.
Для этого следуйте курсу обучения OfficeJS.

Ниже приведен список всех методов, предоставляемых RenderJS, за которыми следуют более подробные пояснения в последующих разделах.

API определения гаджета

Все методы возвращают определение гаджета. И поэтому они являются цепными.

Обратный вызов этот контекст является экземпляром гаджета

Что делать?	Сделай это!	Пояснение
Готовый обработчик	rJS(окно).готово(обратный вызов)	Обратный вызов ready запускается автоматически после загрузки всех зависимостей гаджета. Обратный вызов этот контекст является экземпляром гаджета

Нажмите здесь, чтобы увидеть больше

Исходный код RenderJS доступен на GitLab с зеркалом на GitHub.

• Как предотвратить параллельное выполнение с помощью мьютекса
• Всегда проверяйте возвращаемое значение метода
• Не используйте атрибут DOM id в гаджете
• Не используйте глобальные переменные в гаджете

9 0026 Не использовать обещание . prototype.then()

• Никогда не вызывать changeState внешнего гаджета
• Использовать аргументы, совместимые с JSON
• Какие браузеры поддерживает RenderJS

RenderJS — это свободное программное обеспечение, лицензируемое в соответствии с условиями GNU GPL v3 (или более поздней версии). Обоснование см. в разделе лицензирование Nexedi.

Большинство интерфейсных решений, созданных Nexedi, основаны на RenderJS и jIO. Для идей и вдохновения ознакомьтесь со следующими примерами:

• OfficeJS — магазин приложений Office Productivity (клиент чата, диспетчеры задач, различные редакторы).

renderjs-ipyextension — анализ состояния пакетов Python

Всего загрузок за неделю (8)

Популярность по версии

Звезды GitHub

?

Вилки

?

Авторы

-

---

Популярность прямого использования

---

Пакет PyPI renderjs-ipyextension получает в общей сложности
8 загрузок в неделю. Таким образом, мы забили
Уровень популярности renderjs-ipyextension будет ограничен.

На основе статистики проекта из репозитория GitHub для
пакет PyPI renderjs-ipyextension, мы обнаружили, что он
снялся? раз.

Показанные числа загрузок являются средними еженедельными загрузками с
последние 6 недель.

0.0.4
(Последняя)

Угроза безопасности и лицензии для последней версии

Дата выпуска

8 ноября 2016 г.

Прямые уязвимости

• C
• H
• M
• L

9005 2

Косвенные уязвимости

• C
• H
• M
• 902 31 л

Лицензионный риск

• 1

  H

• M
• L

Все уязвимости безопасности принадлежат
производственных зависимостей прямых и косвенных
пакеты.

---

Неразрешающая лицензия

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

---

Политика безопасности
Нет

Мы нашли для вас способ внести свой вклад в проект! Выглядит как
В renderjs-ipyextension отсутствует политика безопасности.

---

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

Защитите свой проект от уязвимостей с помощью Snyk

Частота фиксации

Недоступные данные фиксации

Открытые проблемы

?

Открытый PR

?

Последняя версия

6 лет назад

Последняя фиксация

неизвестный

---

Дальнейший анализ состояния обслуживания renderjs-ipyextension на основе
частота выпуска версий PyPI, активность репозитория,
и другие точки данных определили, что его обслуживание
Неактивный.

Важным сигналом обслуживания проекта для renderjs-ipyextension является
это
не видел никаких новых версий, выпущенных для PyPI в
за последние 12 месяцев и может считаться прекращенным проектом или проектом, который
получает мало внимания со стороны его сопровождающих.

This entry was posted in Популярное