Vue.js и SEO: как оптимизировать реактивные сайты для поисковых систем и ботов

Реактивные JavaScript-фреймворки (такие как React, Vue.js и Angular) в последнее время очень популярны, и неудивительно, что они используются во все большем количестве веб-сайтов и приложений благодаря их гибкости, модульности и простоте автоматизированного тестирования.

Эти фреймворки позволяют достичь новых, ранее немыслимых вещей на веб-сайте или в приложении, но как они работают с точки зрения SEO? Индексируются ли страницы, созданные с помощью этих фреймворков, Google? Поскольку в этих фреймворках все или большая часть рендеринга страницы выполняется в JavaScript (а HTML-код, загружаемый ботами, в основном пуст), кажется, что они не подходят, если вы хотите, чтобы ваши веб-сайты индексировались в поисковиками или вообще парсится ботами.

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

Некоторая предыстория проблемы

Как работает индексация

Чтобы ваш веб-сайт был проиндексирован Google, он должен быть просканирован Googlebot (программное обеспечение для автоматической индексации, которое посещает ваш веб-сайт и сохраняет содержимое страниц в своем индексе) по ссылкам на каждой странице. Робот Googlebot также ищет на веб-сайтах специальные XML-файлы Sitemap, чтобы найти страницы, на которые могут быть неправильные ссылки с вашего общедоступного сайта, и получить дополнительную информацию о том, как часто меняются страницы на веб-сайте и когда они изменялись в последний раз.

Немного истории

Еще несколько лет назад (до 2009 года) Google индексировал содержимое HTML-кода веб-сайта, исключая весь контент, созданный с помощью JavaScript. Было общеизвестно, что важные ссылки и контент не должны быть написаны с помощью JavaScript, поскольку он не будет проиндексирован Google, и это может привести к штрафу для веб-сайта, поскольку Google может посчитать его «поддельным контентом», как если бы владелец веб-сайта пытался показать пользователям что-то отличное от того, что было показано поисковым системам и попытаться обмануть последних.

Например, мошенники очень часто помещали много оптимизированного для SEO контента в HTML и скрывали его в JavaScript. Google всегда предостерегал от такой практики:

«Предоставление роботу Googlebot контента, отличного от того, который мог бы увидеть обычный пользователь, считается маскировкой и противоречит нашим рекомендациям для веб-мастеров».

Вас могут оштрафовать за это. В некоторых случаях вас могут оштрафовать за предоставление разного контента разным пользовательским агентам на стороне сервера, а также за переключение контента через JavaScript после загрузки страницы. Я думаю, это показывает нам, что Google уже давно индексирует веб-сайты, выполняющие JavaScript — по крайней мере, ради сравнения окончательного HTML-кода веб-сайта (после выполнения JavaScript) и необработанного HTML-кода, который он анализировал для своих индексов. Но робот Googlebot не выполнял JavaScript все время, и Google не использовал контент, созданный с помощью JavaScript, для индексации.

Затем, учитывая более широкое использование AJAX для доставки динамического контента на веб-сайты, Google предложил «схему сканирования AJAX», чтобы помочь пользователям индексировать веб-сайты на основе AJAX. Это было очень сложно; в основном требовалось, чтобы веб-сайт производил рендеринг страниц с включенным контентом AJAX. По запросу Google сервер предоставит версию страницы со всем (или большей частью) контентом, который был бы динамически сгенерирован с помощью JavaScript, включенным в HTML-страницу — предварительно обработанным в виде HTML-снимка контента. Этот процесс предоставления решения на стороне сервера контента, который (для всех других целей) предназначался для создания на стороне клиента, подразумевал, что те, кто хотел, чтобы сайт, который в значительной степени зависел от JavaScript, индексировался в Google, должны были пройти через множество технические хлопоты.

Например, если содержимое, прочитанное AJAX, поступает из внешней веб-службы, необходимо дублировать те же вызовы веб-службы на стороне сервера и создавать на стороне сервера тот же HTML-код, который был бы создан на стороне клиента с помощью JavaScript — или, по крайней мере, очень похожий. Это было очень сложно, потому что до появления Node.js требовалось хотя бы частично дублировать одну и ту же логику рендеринга на двух разных языках программирования: JavaScript для интерфейса и PHP, Java, Python, Ruby и т. д. бэкэнд. Это называется « рендеринг на стороне сервера », и это может привести к аду обслуживания: если вы вносили важные изменения в способ рендеринга контента во внешнем интерфейсе, вам приходилось дублировать эти изменения в бэкэнде.

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

Google (со своей схемой сканирования AJAX) также гарантировал, что вы избежите штрафов из-за того, что в этом случае вы отдавали разный контент роботу Google и пользователю. Однако с 2015 года Google отказался от этой практики, опубликовав официальное сообщение в блоге, в котором менеджерам веб-сайтов сообщалось следующее:

«Сегодня, если вы не блокируете Googlebot сканирование ваших файлов JavaScript или CSS, мы обычно можем отображать и понимать ваши веб-страницы так же, как современные браузеры».

Это говорит нам не о том, что робот Googlebot внезапно приобрел способность выполнять JavaScript при индексировании веб-страниц, поскольку мы знаем, что он делал это в течение очень долгого времени (по крайней мере, для проверки на поддельный контент и мошенничество). Вместо этого нам сказали, что результат выполнения JavaScript будет проиндексирован и использован в поисковой выдаче.

Похоже, это означает, что нам больше не нужно беспокоиться о предоставлении Google HTML, отображаемого на стороне сервера. Тем не менее, мы видим всевозможные инструменты для рендеринга на стороне сервера и предварительного рендеринга, доступные для фреймворков JavaScript, кажется, это не так. Кроме того, при работе с SEO-агентствами над крупными проектами предварительный рендеринг считается обязательным. Почему?

Как Google на самом деле индексирует страницы, созданные с помощью интерфейсных фреймворков?

Эксперимент

Чтобы увидеть, что Google на самом деле индексирует на веб-сайтах, созданных с помощью внешней среды, я провел небольшой эксперимент. Он не охватывает все варианты использования, но, по крайней мере, позволяет узнать больше о поведении Google. Я создал небольшой веб-сайт с помощью Vue.js, и разные части текста отображались по-разному.

Содержание веб-сайта взято из описания книги Дэвида Фостера Уоллеса «Бесконечная шутка» в Infinite Jest Wiki ( спасибо, ребята! ). Есть пара вводных текстов для всей книги и список персонажей с их индивидуальной биографией:

• Некоторый текст в статическом HTML, за пределами основного контейнера Vue.js;
• Некоторый текст визуализируется Vue.js немедленно, потому что он содержится в переменных, которые уже присутствуют в коде приложения: они определены в объекте data компонента;
• #Некоторый текст визуализируется Vue.js из объекта data , но с задержкой в ​​300 мс;
• Биографии персонажей взяты из набора остальных API, которые я специально создал с помощью Sandbox. Поскольку я предполагал, что Google выполнит код веб-сайта и остановится через некоторое время, чтобы сделать снимок текущего состояния страницы, я установил для каждой веб-службы ответ с возрастающей задержкой, первая с 0 мс, вторая с 300 мс, третья с 600мс и так далее до 2700мс.

Биография каждого персонажа укорочена и содержит ссылку на подстраницу, которая доступна только через Vue.js (URL-адреса генерируются Vue.js с использованием API истории), но не на стороне сервера (если вы вызываете URL-адрес страницу напрямую, вы не получите ответа от сервера), чтобы проверить, были ли они проиндексированы. Я предположил, что они не будут проиндексированы, поскольку они не являются правильными ссылками, которые отображаются на стороне сервера, и Google не может напрямую направлять пользователей на эти ссылки. Но я просто хотел проверить.

Я опубликовал этот небольшой тестовый сайт на своих страницах Github и запросил индексацию — взгляните.

Результаты, достижения

Результаты эксперимента (относительно главной страницы) следующие:

• Содержимое, которое уже находится в статическом HTML-содержимом, индексируется Google (что довольно очевидно);
• Содержимое, создаваемое Vue в режиме реального времени, всегда индексируется Google;
• Содержимое, сгенерированное Vue, но отрендеренное через 300 мс, также индексируется;
• Содержимое, поступающее из веб-службы, с некоторой задержкой может быть проиндексировано, но не всегда. Я проверял индексацию страницы Google в разные моменты, и контент, который был вставлен последним (через пару секунд), иногда индексировался, иногда нет. Контент, который отображается довольно быстро, в большинстве случаев индексируется, даже если он исходит из асинхронного вызова внешней веб-службы. Это зависит от того, есть ли у Google бюджет рендеринга для каждой страницы и сайта, который зависит от его внутренних алгоритмов, и он может сильно различаться в зависимости от рейтинга вашего сайта и текущего состояния очереди рендеринга Googlebot. Таким образом, вы не можете полагаться на то, что контент, поступающий из внешних веб-сервисов, будет проиндексирован;
• Подстраницы (поскольку они недоступны по прямой ссылке) не индексируются должным образом.

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

Конкурентное SEO

Итак, контент проиндексирован , но этот эксперимент не говорит нам: будет ли контент ранжироваться на конкурентной основе? Предпочтет ли Google веб-сайт со статическим содержанием динамически создаваемому веб-сайту? Это не простой вопрос.

По своему опыту могу сказать, что динамически генерируемый контент может занимать первые позиции в поисковой выдаче. Я работал над веб-сайтом новой модели крупной автомобильной компании, запуская новый веб-сайт с новым доменом третьего уровня. Сайт был полностью сгенерирован с помощью Vue.js — с очень небольшим количеством контента в статическом HTML, кроме тегов <title> и meta .

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

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

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

Из-за сжатых сроков и нехватки времени, отведенного на проект, мы собирались опубликовать сайт без пререндеринга.

Анимированный текст

Что Google не индексирует, так это сильно анимированный текст. Сайт одной из компаний, с которыми я работаю, Rabbit Hole Consulting, содержит множество текстовых анимаций, которые выполняются во время прокрутки страницы и требуют, чтобы текст был разбит на несколько фрагментов по разным тегам.

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

Ни один из текстов в этих разделах сайта не индексируется Google. Чтобы заставить Google показывать что-то значимое в поисковой выдаче, мы добавили статический текст в нижний колонтитул под контактной формой, и этот контент отображается как часть контента страницы в поисковой выдаче.

Текст в нижнем колонтитуле индексируется и отображается в поисковой выдаче, хотя он не сразу виден пользователям, если они не прокрутят страницу вниз и не нажмут кнопку «Вопросы», чтобы открыть контактную форму. Это подтверждает мое мнение о том, что контент действительно индексируется, даже если он не отображается пользователю сразу, если он быстро отображается в HTML, а не отображается по запросу или после большой задержки.

Как насчет предварительного рендеринга?

Итак, к чему вся эта суета по поводу предварительного рендеринга — будь то на стороне сервера или во время компиляции проекта? Это действительно необходимо? Хотя некоторые фреймворки, такие как Nuxt, значительно упрощают выполнение, это все равно не пикник, так что выбор, настраивать его или нет, не из легких.

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

Кроме того, у меня нет доказательств различий в ранжировании между статическим и динамически генерируемым контентом. Для этого может потребоваться еще один эксперимент. Я думаю, что весьма вероятно, что если контент поступает из внешней веб-службы и не загружается сразу, это может повлиять на восприятие Google производительности вашего сайта, что является очень важным фактором для ранжирования.

Рекомендуемая литература : Как мобильный веб-дизайн влияет на локальный поиск (и что с этим делать)

Другие соображения

Совместимость

До недавнего времени Googlebot использовал довольно старую версию Chromium (проект с открытым исходным кодом, на котором основан Google Chrome), а именно версию 41. Это означало, что некоторые последние функции JavaScript или CSS не могли корректно отображаться Google (например, IntersectionObserver, синтаксис ES6 и так далее).

Google недавно объявил, что в настоящее время использует последнюю версию Chromium (74 на момент написания статьи) в Googlebot, и эта версия будет регулярно обновляться. Тот факт, что Google использовал Chromium 41, мог иметь серьезные последствия для сайтов, которые решили игнорировать совместимость с IE11 и другими старыми браузерами.

Вы можете увидеть сравнение поддержки функций Chromium 41 и Chromium 74 здесь, однако, если ваш сайт уже заполнил отсутствующие функции, чтобы оставаться совместимым со старыми браузерами, проблем не должно было быть.

Всегда используйте полифиллы , поскольку вы никогда не знаете, какой браузер не поддерживает функции, которые вы считаете обычными. Например, Safari не поддерживал важную и очень полезную новую функцию, такую ​​как IntersectionObserver, до версии 12.1, которая вышла в марте 2019 года.

Ошибки JavaScript

Если вы полагаетесь на то, что робот Googlebot выполняет ваш JavaScript-код для рендеринга жизненно важного контента, то следует любой ценой избегать серьезных ошибок JavaScript, которые могут помешать рендерингу контента. Хотя боты могут анализировать и индексировать HTML-код, который не является абсолютно допустимым (хотя всегда предпочтительнее иметь действительный HTML-код на любом сайте!), если есть ошибка JavaScript, которая препятствует загрузке некоторого контента , Google никак не сможет проиндексировать его. этот контент.

В любом случае, если вы полагаетесь на JavaScript для отображения жизненно важного контента для ваших конечных пользователей, то вполне вероятно, что у вас уже есть обширные модульные тесты для проверки блокирующих ошибок любого рода. Однако имейте в виду, что ошибки Javascript могут возникать по непредсказуемым сценариям, например, в случае неправильной обработки ошибок в ответах API.

Лучше иметь некоторое программное обеспечение для проверки ошибок в реальном времени (такое как Sentry или LogRocket), которое предупредит вас о любых крайних ошибках, которые вы можете не обнаружить во время модульного или ручного тестирования. Это усложняет использование JavaScript для SEO-контента.

Другие поисковые системы

Другие поисковые системы не так хорошо работают с динамическим контентом, как Google. Bing вообще не индексирует динамический контент, как и DuckDuckGo или Baidu. Вероятно, этим поисковым системам не хватает ресурсов и вычислительной мощности, которыми Google обладает в избытке.

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

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

Другие боты

Помните, что ваш сайт будут посещать и другие боты. Наиболее важными примерами являются Twitter, Facebook и другие боты социальных сетей, которым необходимо получать метаинформацию о ваших страницах , чтобы показать предварительный просмотр вашей страницы, когда на нее ссылаются их пользователи. Эти боты не будут индексировать динамический контент и будут отображать только метаинформацию, которую они находят в статическом HTML. Это приводит нас к следующему соображению.

Подстраницы

Если ваш сайт является так называемым «одностраничным веб-сайтом» и весь соответствующий контент расположен в одном основном HTML-коде, у вас не возникнет проблем с индексацией этого контента Google. Однако, если вам нужно, чтобы Google проиндексировал и отобразил какую-либо дополнительную страницу на веб-сайте, вам все равно нужно будет создать статический HTML для каждой из них, даже если вы полагаетесь на свою JavaScript Framework для проверки текущего URL-адреса и предоставления соответствующего контента для размещения. на этой странице. Мой совет в этом случае — создавать серверные (или статические) страницы, которые, по крайней мере, содержат правильный тег title и метаописание/информацию.

Выводы

Выводы, к которым я пришел, изучая эту статью, следующие:

1. Однако если вы ориентируетесь только на Google, использование предварительного рендеринга не обязательно для полной индексации вашего сайта:
2. Вы не должны полагаться на сторонние веб-сервисы для контента, который необходимо проиндексировать, особенно если они не отвечают быстро.
3. Контент, который вы сразу вставляете в свой HTML с помощью рендеринга Vue.js, индексируется, но вы не должны использовать анимированный текст или текст, который вставляется в DOM после действий пользователя, таких как прокрутка и т. д.
4. Убедитесь, что вы тестируете ошибки JavaScript, так как они могут привести к тому, что целые страницы/разделы не будут проиндексированы, или ваш сайт вообще не будет проиндексирован.
5. Если на вашем сайте несколько страниц , вам все равно потребуется некоторая логика для создания страниц, которые, опираясь на ту же систему внешнего интерфейса, что и домашняя страница, могут быть проиндексированы Google как отдельные URL-адреса.
6. Если вам нужно иметь разные описания и изображения для предварительного просмотра для социальных сетей на разных страницах, вам также необходимо решить эту проблему либо на стороне сервера, либо путем компиляции статических страниц для каждого URL-адреса.
7. Если вам нужно, чтобы ваш сайт работал в поисковых системах, отличных от Google , вам обязательно потребуется какой-либо предварительный рендеринг.