Мое одностраничное приложение дружит с SEO?

Мое одностраничное приложение дружит с SEO?

От создателя: общеизвестно, что SEO приложения — это мутная область в разработке одностраничников (SPA). Различные люди вам ответят по-разному. Кто-то произнесет, что сканирование поисковым движком контента, отрендеренного на стороне клиента работает совершенно. Кто-то скажет, что все работает отлично, пока контент синхронизирован, а кто-то произнесет, что все вообще плохо работает. Все эти противоречивые советы делают путаницу, и я регулярно слышу вопросы «мое Vue SPA нормально настроено для SEO?» в местах типа Vue.js Developers Facebook group, Vue.js Forums и r/vuejs на Reddit. В этой статье мы оспорим пользующиеся популярностью мнения, проведем пару базовых тестов и попробуем сконструировать разумные советы для создания SEO-friendly SPA.

Неувязка с контентом, рендер которого проходит на стороне клиента

Стандартная реализация одностраничного приложения обеспечивает «оболочку» странички для браузера без какого-либо значимого контента. Контент загружается по требованию с сервера по AJAX, после чего добавляется на страничку через JS.

Это позволяет юзеру просматривать «страницы» в SPA без обновления странички, что, в теории, улучшает UX.

Мое одностраничное приложение дружит с SEO?

Эта архитектура работает для людей, разглядывающих страницу в браузере. А что насчет ботов поисковых движков? Могут ли роботы запускать JS? Если да, будут ли они ожидать выполнения AJAX запросов, прежде чем исследовать страницу?

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

Googlebot

Гугл – лидирующий поисковой движок во всем мире, потому наше исследование должно сосредоточиться на Googlebot, боте поискового движка google.

На заре веба Googlebot умел сканировать только статичный HTML на страничке. В 2014 объявили, что теперь Googlebot будет пробовать рендерить JS перед сканированием.

Гугл предоставила веб-мастерам инструмент Fetch As Гугл, помогающий отлаживать проблемы с рендером страничек, измененных через JS. Инструмент показывает снимок экрана того, что видит Googlebot по обозначенному URL.

«Распространенное заблуждение, что Googlebot не сканирует асинхронный JS. Миф развенчали в этой статье. Если кратко, то Googlebot ждет минимум 20 секунд окончания асинхронных запросов!»

Как Googlebot лицезреет SPA

Идеальный пример Vue.js SPA — Vue HackerNews Clone 2.0. Это open source проект от команды Vue, демонстрирующий все способности Vue и эффективных шаблонов проектирования.

Я развернул это приложение на Heroku и прогнал через Fetch As Гугл. Ниже показано, как Googlebot видит приложение (слева), и как его лицезреет человек (справа). Вроде бы скриншоты схожие.

Мое одностраничное приложение дружит с SEO?

Удаление серверного рендера

Одна из главных фишек Vue HackerNews Clone 2.0 – серверный рендер (SSR). То есть в отличие от более обычного SPA, контент каждой страницы рендерится на сервере и отчаливает в браузер при каждой загрузке странички, как статичный HTML.

Мы пытаемся осознать, как Googlebot видит контент, отрендереный на стороне клиента. Для этого я отключил SSR и запустил тест еще раз:

Мое одностраничное приложение дружит с SEO?

Имея только рендер на стороне клиента, у Googlebot все равно не было заморочек с просмотром контента. Я подождал пару дней, чтоб google проиндексировал приложение. И он это сделал:

Мое одностраничное приложение дружит с SEO?

Но стойте…

Несмотря на то что этот тест и развеял все сомнения по поводу контента, отрисованного на стороне клиента, есть пара обстоятельств, почему не стоит полностью ему доверять:

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

Если страничка индексируется, это не значит, что у нее будет высочайший рейтинг

Не доверяйте JavaScript

У Googlebot не появилось проблем с рендером Vue HackerNews. Но не стоит мыслить, что он сможет рендерить весь JS так же безотказно. В 2014 Гугл заявила, что не дает гарантий на JS рендер, но, похоже, большая часть разработчиков просто не заметили этого.

Как и браузер, Googlebot должен владеть JS движком с определенным набором реализованных веб-стандартов и функций ES, а также своими особенностями реализации всего этого.

В этом видео от разработчиков гугл 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

По материалам webformyself.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *