От автора: общеизвестно, что SEO приложения — это мутная область в разработке одностраничников (SPA). Разные люди вам ответят по-разному. Кто-то скажет, что сканирование поисковым движком контента, отрендеренного на стороне клиента работает идеально. Кто-то скажет, что все работает хорошо, пока контент синхронизирован, а кто-то скажет, что все вообще плохо работает. Все эти противоречивые советы создают путаницу, и я регулярно слышу вопросы «мое Vue SPA нормально настроено для SEO?» в местах типа Vue.js Developers Facebook group, Vue.js Forums и r/vuejs на Reddit. В этой статье мы оспорим популярные мнения, проведем пару базовых тестов и попробуем сформулировать разумные советы для создания SEO-friendly SPA.
Проблема с контентом, рендер которого проходит на стороне клиента
Стандартная реализация одностраничного приложения обеспечивает «оболочку» страницы для браузера без какого-либо значимого контента. Контент загружается по требованию с сервера по AJAX, после чего добавляется на страницу через JS.
Это позволяет пользователю просматривать «страницы» в SPA без обновления страницы, что, в теории, улучшает UX.
Эта архитектура работает для людей, просматривающих страницу в браузере. А что насчет роботов поисковых движков? Могут ли роботы запускать JS? Если да, будут ли они ждать выполнения AJAX запросов, прежде чем сканировать страницу?
Важно знать эти моменты, так как это определяет, будет ли контент сайта индексироваться поисковыми движками или нет. Также важно, как хорошо контент сайта будет оценен.
Googlebot
Google – лидирующий поисковой движок во всем мире, поэтому наше исследование должно сосредоточиться на Googlebot, роботе поискового движка google.
На заре интернета Googlebot умел сканировать только статичный HTML на странице. В 2014 объявили, что теперь Googlebot будет пытаться рендерить JS перед сканированием.
Google предоставила веб-мастерам инструмент Fetch As Google, помогающий отлаживать проблемы с рендером страниц, измененных через JS. Инструмент показывает скриншот того, что видит Googlebot по указанному URL.
«Распространенное заблуждение, что Googlebot не сканирует асинхронный JS. Миф развенчали в этой статье. Если коротко, то Googlebot ждет минимум 20 секунд завершения асинхронных запросов!»
Как Googlebot видит SPA
Идеальный пример Vue.js SPA — Vue HackerNews Clone 2.0. Это open source проект от команды Vue, демонстрирующий все возможности Vue и эффективных шаблонов проектирования.
Я развернул это приложение на Heroku и прогнал через Fetch As Google. Ниже показано, как Googlebot видит приложение (слева), и как его видит человек (справа). Вроде бы скриншоты одинаковые.
Удаление серверного рендера
Одна из ключевых фишек Vue HackerNews Clone 2.0 – серверный рендер (SSR). То есть в отличие от более простого SPA, контент каждой страницы рендерится на сервере и отправляется в браузер при каждой загрузке страницы, как статичный HTML.
Мы пытаемся понять, как Googlebot видит контент, отрендереный на стороне клиента. Для этого я отключил SSR и запустил тест еще раз:
Имея лишь рендер на стороне клиента, у Googlebot все равно не было проблем с просмотром контента. Я подождал пару дней, чтобы google проиндексировал приложение. И он это сделал:
Но стойте…
Хотя этот тест и развеял все сомнения по поводу контента, отрисованного на стороне клиента, есть пара причин, почему не стоит полностью ему доверять:
Как и все JS движки, Googlebot может ошибаться. Могут возникнуть крайние случаи, когда он не сможет провести рендер страницы
Если страница индексируется, это не значит, что у нее будет высокий рейтинг
Не доверяйте JavaScript
У Googlebot не возникло проблем с рендером Vue HackerNews. Но не стоит думать, что он сможет рендерить весь JS так же безотказно. В 2014 Google заявила, что не дает гарантий на JS рендер, но, похоже, большинство разработчиков просто не заметили этого.
Как и браузер, Googlebot должен обладать JS движком с определенным набором реализованных веб-стандартов и функций ES, а также своими особенностями реализации всего этого.
В этом видео от разработчиков google Addy Osmani и Rob Dodson (вышло в ноябре 2017) говорится, что Googlebot основан на Chrome 41. С тех пор вышло много новых API, и если вы используете одно из них, то, скорее всего, Googlebot не сможет провести рендер и индексацию страницы.
Вы скажете, что это тривиальная задача. Нужно лишь провести код через транспиллер или написать полифил для функций для старых браузеров. Но суть в том, что не нужно слепо добиваться того, чтобы ваше приложение правильно запускалось во всех поисковых роботах, точно так же, как вы не стараетесь сделать так, чтобы приложение правильно запускалось во всех браузерах.
Оптимизация
Не забывайте, что O в SEO расшифровывается как оптимизация. Индексации поисковым движком мало. Нужно, чтобы наши сайты имели хороший рейтинг. Fetch As Google показывает нам, как страница отображается, но не то, как страница выглядит по отношению к конкурентам.
В статье «SEO vs. React: Web Crawlers are Smarter Than You Think», автор которой SEO эксперт Barry Adams, есть интересный комментарий. Он высказался на тему того, как поисковые движки ранжируют SPA:
«Если вы используете React без серверного рендера, робот останавливается на самой первой странице, так как он не видит гиперссылок, по которым можно перейти… Это сильно замедляет сканирование и делает его неэффективным. Поэтому сайты на React (и похожих JS платформах) хуже сканируются google, чем сайты, которые в первую очередь предоставляют роботам чистый HTML… сайты на чистом HTML крайне эффективно сканируются роботами, добавленный и измененный контент сканируется и индексируется намного быстрее, а google на таких сайтах может намного точнее оценить приоритет сканирования отдельных страниц.»
Он не предъявил никаких доказательств, но его высказывание совпадает с философией других определений рейтинга, таких как скорость страницы.
Что делать, если SEO критически важен
Суть в том, что если SEO критичен, нельзя полагаться на клиентский рендер SPA, необходимо быть уверенным, что контент включен в страницы.
Но это не значит, что нужно уходить от архитектуры SPA. Есть две техники: серверный рендер и предварительный рендер. Обе могут помочь вам добиться желаемого.
Серверный рендер
Серверный рендер (SSR) – когда страница рендерится сервером, как часть цикла запроса/ответа на сервер. В Vue.js и других похожих фреймворках это происходит путем выполнения приложения на виртуальном DOM.
Состояние виртуального DOM конвертируется в HTML строку, затем вставляется в страницу перед отправкой клиенту. Как только страница достигает браузера, JS приложение бесшовно накладывает существующий контент.
SSR гарантирует, что страница будет crawler friendly, поскольку ее контент будет завершен независимо от того, как, или даже, если сканер запустит JS.
У SSR есть свои недостатки:
Необходимо проектировать код так, чтобы он был универсальным. Т.е. он должен работать в браузере и на серверном JS окружении. Т.е. любой код, ожидающий браузерных API и объекты типа window, не сработает.
Приложение будет запускаться при каждом запросе к серверу, дополнительно нагружая и замедляя ответы. Кэширование может частично решить эту проблему.
Реализовать SSR сложнее и дольше по времени, для проекта понадобится больше часов на разработку.
Приложение хорошо работает только с Node.js backend. SSR можно реализовать и без Node backend. Например, с помощью PHP расширения v8js, но такие решения сильно ограничены.
Если хотите реализовать серверный рендер в Vue.js SPA, начните с официального руководства: Vue.js Server-Side Rendering Guide. Я тоже написал руководство по реализации SSR на Laravel и Vue.js: Server-Side Rendering With Laravel & Vue.js 2.5.
«Совет: во фреймворках типа Nuxt.js серверный рендер встроен по умолчанию.»
Предварительный рендер
Если по одной из вышеописанных причин вы не можете использовать SSR, есть другой способ – предварительный рендер. При таком подходе вы запускаете браузер в режиме headless в среде разработки, делаете скриншот страницы и подставляете свои HTML файлы с этим скриншотом в ответ сервера.
Концепция почти такая же, как и SSR, только здесь все выполняется до развертывания, а не на реальном сервере. Обычно такой рендер выполняется в headless браузере типа Chrome и его можно вставить в потом создания билда с помощью Webpack, Gulp и т.д.
Плюс предварительного рендера в том, что ему не нужен сервер Node.js, и он не нагружает реальный сервер.
Однако у предварительного рендера есть свои минусы:
Он плохо работает для страниц, показывающих изменяемые данный, например, Vue HackerNews.
Он не подходит для страниц, содержащих пользовательский контент. Например, страница профиля с личными данными. Но эти страницы не так критичны для SEO. Обычно вообще не хотят индексировать страницу профиля.
Каждый роут в приложении придется предварительно рендерить отдельно, что на большом сайте может занять много времени.
Если хотите реализовать предварительный рендер в Vue.js приложении, я написал руководство в блоге: Pre-Render A Vue.js App (With Node Or Laravel)
Совет: пререндер для SEO можно купить как сервис на prerender.io
Заключение
Множество разработчиков думали, что заявление Google в 2014 по JS рендеру, будет решением проблем SEO для SPA контента. На деле же, нет гарантии того, что Googlebot правильно проведет рендер страницы. И даже если он это сделает, он все равно может оценить страницу ниже, чем страницы со статичным HTML.
Мой совет: если хотите использовать архитектуру SPA, реализуйте серверный или предварительный рендер страниц.
Автор: Anthony Gore
Источник: https://vuejsdevelopers.com/
Редакция: Команда webformyself.