JavaScript SEO: как избежать ловушек рендеринга на стороне сервера

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

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

Запросить встречу!

Какие существуют виды рендеринга на стороне сервера?

Предварительный рендеринг вашего веб-сайта для Google на вашем сервере (рендеринг на стороне сервера, SSR) — это один из способов убедиться, что ваш веб-сайт JavaScript удобен для Googlbot. Таким образом, вы можете предоставить Google предварительно обработанную HTML-версию своего веб-сайта, в то время как пользователь получит обычную (еще не обработанную) версию браузера.

Однако когда дело доходит до рендеринга на стороне сервера, существуют разные способы рендеринга, как вы можете видеть из следующей диаграммы, которая была любезно предоставлена ​​Google, с некоторыми полезными дополнениями от Яна-Виллема Боббинка.

Существует три основных способа настройки и выполнения рендеринга на стороне сервера:

1. Рендеринг на стороне сервера с динамическим HTML

Рендеринг на стороне сервера создает обработанную HTML-версию каждого URL-адреса по запросу.

2. Статический рендеринг со статическим HTML

По сути, это создает предварительно обработанную (статическую) HTML-версию URL-адреса заранее и сохраняет ее в кеше.

3. Рендеринг на стороне сервера с (ре)гидратацией с помощью динамического HTML и JS/DOM.

Сервер предоставляет статическую HTML-версию URL-адреса, а клиент (браузер и т. д.) уже содержит разметку структурированной объектной модели документа (DOM). Клиент берет это и превращает в динамическую модель DOM, которая может реагировать на изменения на стороне клиента и делает ее более интерактивной.

Google опубликовал отличный обзор рендеринга в Интернете со всеми плюсами и минусами, а также более подробное объяснение, если вам интересно. Но прежде всего, если вам нужна помощь по теме JavaScript SEO или рендеринга на стороне сервера, обязательно свяжитесь с нами здесь, в Searchmetrics Digital Strategies Group.

Связаться!

Подводные камни при рендеринге JavaScript-сайтов через сервер

Недавно мы столкнулись с некоторыми проблемами SSR у одного из наших клиентов. Они запускают свой веб-сайт на Angular JS и отображают его с помощью Rendertron через Headless Chrome.

Они используют статический подход к рендерингу SSR, что означает, что они рендерят страницу и кэшируют отображаемый HTML на сервере (заранее). Кэшированный HTML-код не будет заменен автоматически, но будет основан на логике рендеринга. Ниже приведены пять проблем, с которыми мы столкнулись при работе с этим веб-сайтом. Я делюсь ими с вами здесь, чтобы, если у вас возникнут похожие проблемы, вы поняли, как с ними справиться. Однако это можно рассматривать как незаконченный/расширяемый список.

1. Когда ничего не делаешь

Если вам все равно и вы не обращаете никакого внимания на то, как Google отображает вашу страницу, позвольте мне показать вам, как Google отображает (на самом деле видит) вашу страницу. Это основано на веб-сайте, созданном на основе одностраничного приложения (SPA) с использованием инфраструктуры JavaScript без рендеринга на стороне сервера.

Это не выглядит особенно многообещающе, не так ли? Именно поэтому важно использовать SSR, потому что тогда это выглядит так:

2 . Пагинация

Что делать с разбитыми на страницы страницами, когда дело доходит до рендеринга? Что ж, особенно при публикации, страницы с разбивкой на страницы все еще могут быть полезны для предоставления Google ваших (самых последних) статей, пока Google их сканирует. Если вы посмотрите на свои файлы журналов, вы увидите, как Google обращается к вашей разбивке на страницы, чтобы вы знали, где имеет смысл предоставлять предварительно обработанную версию (Спойлер: вам не нужно предоставлять 399 URL-адресов с обработанной версией). )

Поскольку наш клиент выполняет рендеринг со статическим подходом SSR, он просто визуализирует первую страницу и зеркально отображает кэшированную версию страницы 1 до страницы 10. Без какой-либо отображаемой версии со страницы 11 и далее. Вот два снимка экрана, которые достаточно хорошо показывают проблему, с точно таким же содержанием со страницы 1, которое также представлено на страницах 2-10.

Это означает, что вы предоставляете Google 10 страниц с одинаковым содержанием и статьями. В идеале вы хотите, чтобы Google отображал все страницы как уникальные с правильно разбитыми на страницы статьями.

3 . Обновлять отображаемую версию страниц категорий после публикации новой статьи/продукта

Наш клиент довольно значительно повысил свой рейтинг почти во всех ресурсах Google News, таких как AMP Carousels, Google News Boxes и Mobile News Boxes, за исключением каруселей Publisher. Мы начали исследовать это, и оказалось, что наш клиент не обновлял свою кешированную версию, когда публиковалась новая статья. Мы узнали, что через неделю они обновили кешированную версию основных категорий:

а по подкатегориям даже через месяц.

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

4 . Рендеринг может привести к дублированию контента и неправильной канонизации.

Предоставление предварительно обработанной версии URL-адреса может вызвать системные проблемы. Поскольку наш клиент доставлял предварительно обработанные страницы, каждая со своим собственным URL-адресом, созданным механизмом рендеринга, эти URL-адреса имели параметры «p = 1; render=1» и были полностью индексируемы:

Для этого URL был даже создан новый канонический механизм SSR. Довольно жутковато, да?

В идеале вы хотите исключить эти параметры из сканирования Google.

5 . Изменение заголовка страницы при рендеринге

Мы также обнаружили, что текущие заголовки страниц были обработаны с помощью JavaScript. Это было сделано таким образом, чтобы мета-заголовок HTML всегда отображал название бренда, когда JavaScript был отключен. А когда пользовательский агент не Googlebot, он отображает только заголовок HTML-страницы. См. следующие два примера ниже. Первый показывает URL-адрес с отключенным JavaScript. Второй — тот же URL, но с включенным JavaScript.

Чтобы метаданные всегда отображались правильно, их следует включить в необработанную (JavaScript) версию URL-адреса.

Вывод

Рендеринг на стороне сервера нельзя использовать в качестве шаблонного подхода для рендеринга одностраничных приложений. Особое внимание требуется для статических подходов, когда вы просто предоставляете снимок. Как видно из примера нашего клиента, вам нужно убедиться, что механизм SSR всегда предоставляет актуальную версию URL-адреса, иначе Google не увидит и не сохранит ваши самые последние статьи, и вы будете упустить ценный трафик.

Перед повторным запуском с веб-сайта на основе HTML на платформу на основе JavaScript убедитесь, что рендеринг на стороне сервера включен и всегда работает динамически!

Если у вас возникли проблемы с JavaScript или вы иным образом ищете поддержку в технической оптимизации вашего веб-сайта, то почему бы не назначить необязательную встречу с нашими консультантами Digital Strategies Group и узнать, где они могут вам помочь?

Запросить встречу!