От автора: за последние три года, работая в команде SEO в Croud, Нью-Йорк, 60% наших клиентов прошли через определенную форму миграции. Еще ~ 30% перешли с или на SPA (одностраничное приложение), часто используя AJAX (асинхронный Javascript и XML) фреймворк в различной степени.
Любой, кто работает в сфере корпоративного SEO в 2020 году, в какой-то момент столкнется с этим сценарием веб-архитектуры с клиентом. Фреймворки, такие как React, Vue и Angular, упрощают веб-разработку. Это особенно актуально при создании динамических веб-приложений, которые предлагают относительно быструю интерактивность новых запросов (после загрузки исходных библиотек, которые их приводят в действие — хороший пример — Gmail), используя возможности современного браузера для визуализации клиентского кода (JavaScript) ). Затем используются web workers для обслуживания функционала сетевых запросов, для которого не требуется традиционный вызов URL на основе сервера.
Улучшение функционала и возможностей развертывания сопряжено с издержками — в частности SEO. Я сомневаюсь, что любой человек, читающий о SEO, не сталкивался с этим вопросом. Тем не менее, вы можете все еще быть в неведении относительно данной проблематики.
Почему это проблема?
Потерянный органический трафик через потерянные рейтинги в органическом поиске. Это так просто. Веб-разработчики, которые рекомендовали платформы JavaScript (JS), обычно не несут прямой ответственности за долгосрочную коммерческую эффективность. Одной из основных задач SEO в 2020 году должно быть смягчение стратегических ошибок, которые могут возникнуть из-за этого. Органический трафик часто воспринимается как данность и не рассматривается как важный (или контролируемый), и именно здесь возникают проблемы. Существует множество тематических исследований, но один из наших клиентов перешел на гибридную среду Shopify / JS с внутренними ссылками и контентом, отображаемым через JS. В течение следующих 6 месяцев они потеряли трафик на сумму около 8000 долларов в день… около 1,5 миллионов долларов США всего.
В чем проблема?
Есть много проблем. Оптимизаторы итак пытаются справиться с огромным количеством сигналов самого большого коммерческого алгоритма из когда-либо созданных (это Google… если что). Переход от традиционного веб-сайта, представленного сервером (например, Википедия), к современному фреймворку потенциально связан с проблемами SEO. Некоторые из которых:
Сканирование, рендеринг и индексация поисковыми роботами — поисковые роботы, такие как Googlebot, адаптировали свой процесс сканирования для включения рендеринга JavaScript (начиная с 2010 года), чтобы иметь возможность полностью понимать код на AJAX веб-страницах. Мы знаем, что Google становится лучше в понимании сложного JavaScript. Для других поисковых роботов это может быть не так. Но это не просто вопрос понимания. Сканирование всей сети — не простая задача, и даже ресурсы Google ограничены. Они должны решить, стоит ли сканировать и отображать сайт, основываясь на предположениях, которые имеют место задолго до того, как JS мог быть найден и отображен (такие метрики, как предполагаемое количество страниц, история домена, данные WhoI, полномочия домена и т. д.)
Процесс сканирования и рендеринга Google — 2-й этап рендеринга / индексирования (объявлено на Google I / O 2018)
Скорость — одно из самых больших препятствий для приложений AJAX. Google сканирует веб-страницы без кэширования, поэтому эти громоздкие первые загрузки одностраничных приложений могут быть проблематичными. Скорость можно определить разными способами, но в данном случае мы говорим о том, сколько времени требуется для выполнения и критической визуализации всех ресурсов на тяжелой JavaScript странице по сравнению с менее ресурсоемкой HTML-страницей.
Ресурсы и рендеринг. При использовании традиционного серверного кода DOM (объектная модель документа) по сути визуализируется после формирования CSSOM (объектной модели CSS), или, проще говоря, DOM не требует слишком больших дополнительных манипуляций после выборка исходного кода. Есть некоторые предостережения в отношении этого, но можно с уверенностью сказать, что код на стороне клиента (и многочисленные библиотеки / ресурсы, из которых может быть получен код) добавляет повышенную сложность к окончательному DOM, что означает увеличение ресурсов ЦП, требуемых как поисковыми роботами, так и клиентскими устройствами. Это одна из наиболее важных причин, по которым сложная структура JS не будет предпочтительной. Однако об этом часто забывают.
До этого мы исходили из предположения, что эти AJAX страницы были созданы без учета SEO. Это немного несправедливо по отношению к современным агентствам веб-дизайна или разработчикам. Обычно выполняются некоторые действия, чтобы смягчить негативное влияние на SEO (мы рассмотрим их более подробно). Опытные читатели среди нас теперь начнут чувствовать, что они встретились с чем-то знакомым. На эту тему ведутся многочисленные дискуссии по электронной почте между клиентами, разработчиками, проектировщиками и командами SEO, это касается того, затронет ли потенциально миграция органические рейтинги (к сожалению, это часто так).
Проблема заключается в том, что решения по созданию AJAX приложений, которые работают больше как серверный HTML-код для целей SEO, сами по себе ведут к конфликту; в первую очередь это связано с их эффективностью. Как мы проверяем эффективность чего-либо для SEO? Мы должны развернуть и проанализировать изменения SERP. А результаты миграции на JavaScript-фреймворки неоднократно связаны с падением трафика. Ознакомьтесь с еженедельными докладами, приведенными Рабочей группой по JS-сайтам в поиске, которую ведет Джон Мюллер, если вам нужны доказательства.
Давайте рассмотрим некоторые из наиболее распространенных тактик смягчения последствий для SEO, связанных с переходом на AJAX.
Различные решения для смягчения последствий для SEO
1. Универсальный / изоморфный JS
Изоморфный JavaScript, также известный, как Универсальный JavaScript, описывает JS-приложения, которые выполняются как на стороне клиента, так и на стороне сервера, например, <script> и другой доставленный код могут выполнять клиент или сервер — а не только клиент (или только сервер). Как правило, сложные приложения JavaScript будут готовы только для выполнения на стороне клиента (обычно в браузере). Изоморфный Javascript смягчает это. Одно из лучших объяснений, которые я видел (в частности, связанных с Angular JS), дано Андресом Рутником на Medium:
Клиент делает запрос на конкретный URL-адрес сервера приложений.
Сервер передает запрос в сервис рендеринга, который является вашим приложением Angular, работающим в контейнере Node.js. Этот сервис может быть (но не обязательно) на той же машине, что и сервер приложений.
Серверная версия приложения отображает полный HTML и CSS для запрошенного пути и запроса, включая теги <script> для загрузки клиентского приложения Angular.
Браузер получает страницу и может сразу же отобразить содержимое. Клиентское приложение загружается асинхронно и, как только оно будет готово, повторно отображает текущую страницу и заменяет статический HTML-код отображаемым сервером. Теперь веб-сайт ведет себя как SPA для любого взаимодействия. Этот процесс должен быть плавным для пользователя, просматривающего сайт.
Повторимся, после запроса сервер отображает JS, и полный DOM / CSSOM формируется и подается клиенту. Это означает, что для Googlebot и пользователей была предоставлена предварительно обработанная версия страницы. Разница для пользователей заключается в том, что только что обработанные HTML и CSS затем визуализируются, чтобы заменить их динамическим JS, и он может вести себя как SPA, как и предназначалось.
Проблемы с созданием изоморфных веб-страниц / приложений, похоже, состоят в том, что… на самом деле создать их не просто.
2. Динамический рендеринг
Динамический рендеринг — более простая для понимания концепция; это процесс обнаружения агента пользователя, выполняющего запрос к серверу, и маршрутизации правильного кода ответа на основе этого запроса от проверенного бота или пользователя.
Это рекомендуемый Google метод обработки JavaScript для поиска. На рисунке ниже показан весь процесс:
Процесс динамического рендеринга, объясненный Google
Выходные данные — это предварительно обработанная итерация вашего кода для поисковых роботов и тот же AJAX, который всегда предоставлялся пользователям. Google рекомендует для достижения этой цели такое решение, как prerender.io. Это сервис обратного прокси, который предварительно отображает и кэширует страницы. Однако при динамическом рендеринге есть некоторые подводные камни, которые необходимо понимать:
Клоакинг — во всемирной паутине, в которой преобладают HTML и CSS, клоакинг был огромным негативом. Динамический процесс рендеринга для Google является прямым признаком клоакинга. Они прямо говорят: «Предоставление пользователям одного, а нам предоставление другого». Почему это проблема? Google говорит: «Пока ваш динамический рендеринг производит похожий контент, робот Google не будет рассматривать динамический рендеринг как клоакинг». Но что такое похожий контент? Насколько легко было бы добавить для робота Googlebot больше контента, чем предоставляется пользователям, или использовать JS с задержкой для удаления текста для пользователей или манипулирования страницей другим способом, который робот Googlebot вряд ли увидит.
Кэширование. Для сайтов, которые часто меняются, таких как крупные издатели новостей, для которых требуется, чтобы их контент был проиндексирован как можно быстрее, решение для предварительной визуализации может просто не работать. Постоянное добавление и изменение страниц должно быть предварительно обработано почти немедленно, чтобы быть быстрым и эффективным. Минимальное время кэширования на prerender.io — это дни, а не минуты.
Фреймворки сильно отличаются — каждый технический стек отличается, каждая библиотека добавляет новую сложность, и каждая CMS будет справляться с этим по-своему. Решения предварительного рендеринга, такие как prerender.io, не являются универсальными для оптимальной эффективности SEO.
3. CDN создают дополнительные сложности … (или любой обратный прокси-сервер)
Сети доставки контента (такие как Cloudflare) могут создавать дополнительные сложности тестирования, добавляя еще один уровень в сеть обратного прокси. Тестирование решения для динамического рендеринга может быть затруднено, поскольку Cloudflare блокирует неподтвержденные запросы робота Google через обратный поиск DNS. Устранение проблем динамического рендеринга, следовательно, занимает много времени. Роботу Googlebot требуется время, чтобы пересмотреть страницу, а затем сочетание кеша Google и новой консоли поиска, чтобы иметь возможность интерпретировать эти изменения. Инструмент тестирования, оптимизированный под мобильные устройства, от Google является достойным выходом, но вы можете анализировать только одну страницу за раз.
Это минное поле! Итак, что я делаю для оптимальной эффективности SEO?
Думайте умно и планируйте эффективно. К счастью, только относительно небольшое количество элементов дизайна имеют решающее значение для SEO, и многие из них являются элементами в head и / или метаданных. А именно:
Содержимое тегов <head> — <link> и <meta>
Теги заголовков, например, <h1>, <h2> и т. д.
Теги <p> и все остальные тексты
<table>, <ul>, <ol> и все другие HTML-элементы, доступные для сканирования
Ссылки (должны быть тегами <a> с атрибутами href)
Картинки
Каждый из приведенных выше элементов должен обслуживаться без какой-либо визуализации JS, требуемой клиентом. Как только вам требуется рендеринга JS, чтобы получить один из вышеперечисленных элементов, вы ставите под угрозу эффективность в органическом поиске. JavaScript может и должен использоваться для улучшения взаимодействия с пользователем на сайте. Но если он используется для внедрения вышеупомянутых элементов в DOM, тогда у вас проблема, которую необходимо устранить.
Внутренние ссылки часто обуславливают самые серьезные в рамках Javascript проблемы с SEO. Это связано с тем, что иногда вместо тегов <a> используются события onclick, поэтому проблема заключается не только в том, что робот Google выполняет рендеринг JS для формирования ссылок в DOM. Даже после рендеринга JS у нас по-прежнему нет тега <a> для сканирования, поскольку он вообще не используется — вместо него используется событие onclick.
Чтобы считаться действительной, каждая внутренняя ссылка должна быть тегом <a> с атрибутом href, содержащим значение пункта назначения ссылки. Это было подтверждено на Google’s I/O event в прошлом году.
Заключение
Остерегайтесь утверждения «мы можем использовать React / Angular, потому что у нас есть next.js / Angular Universal, поэтому нет проблем». Все должно быть протестировано, и этот процесс тестирования может быть сложным сам по себе. Количество факторов огромно. В качестве характерного примера, что, если клиент переходит с простого HTML-сайта на AJAX-фреймворк? Дополнительная обработка и возможные проблемы с критическими элементами рендеринга на стороне клиента могут вызвать огромные проблемы с SEO. Что, если тот же самый веб-сайт в настоящее время приносит дохода от органического поиска на 10 млн. долл. в месяц? Даже минимальное снижение возможностей сканирования, индексации и производительности может привести к потере значительных денег.
Нельзя избегать современных JS-фреймворков, и это не должно быть целью — часы, сэкономленные во время разработки, сами по себе могут стоить тысячи долларов — но как SEO-специалисты, мы несем ответственность за то, чтобы неукоснительно защищать наиболее важные элементы SEO и гарантировать, что они всегда являются отображаемыми на стороне сервера, в той или иной форме. Предоставьте роботу Google возможность делать как можно меньше работы, чтобы понять ваш контент. Это должно быть целью.
Автор: Anthony Lavall
Источник: https://www.searchenginewatch.com
Редакция: Команда webformyself.