JavaScript и SEO: проблемы и решения

Если ваш сайт активно использует JavaScript, это может стать серьёзной проблемой для продвижения. Как показывает практика, техническое SEO до сих пор остаётся тёмным лесом даже для оптимизаторов. И напрасно: возможность поисковых роботов сканировать и индексировать контент — это база, без который сайт никогда не будет иметь высоких позиций.

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

JavaScript SEO — это отрасль технического SEO, связанная с оптимизацией сайтов, основанных на JavaScript или просто активно его использующих. Как показывают данные статистики, JS активно используют 97% всех современных сайтов.

Можно условно разделить все современные сайты на три основные категории:

Последний сайт без JS из тех, что я видел, был «Библиотекой Мошкова», и было это примерно 25 лет назад. Даже если ваш сайт сделан примерно в прошлом веке – он так или иначе уже использует JavaScript. Если же он сделан недавно – он использует JS активно. А если вы используете конструкторы сайтов, или ваш сайт сделан на Angular JS, React или Vue – это может быть проблемой. Так исторически сложилось, что сайты чаще всего разрабатывают без участия SEO-специалистов, а критерии качества у разработчиков свои. А вам потом с этим сайтом как-то жить.

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

Но оптимизация сканирования и индексации сайтов на JS – не единственная сфера применения JavaScript SEO. Вот другие задачи этого направления технической оптимизации:

Современные разработчики сайтов уже пытаются любую проблему решить с помощью JS, даже те, что могут быть решены более простыми традиционными средствами HTML и CSS. В ряде случаев это напрямую влияет на SEO. Вот основные моменты, на которые нужно обращать внимание:

Уровни сложности проблем меняются в зависимости от способа использования JavaScript на сайте: есть большая разница между добавлением анимации на статические страницы и формированием DOM средствами JavaScript в случае SPA-сайтов.

Вот три основные причины обратить внимание на JavaScript на вашем сайте:

Если поисковая система не может сканировать JS, то ей не будет понятно, как работает ваш сайт, и она не увидит то, что увидит посетитель-человек. На что это влияет? –

Вы должны понимать, что именно доступно поисковикам, а также определить, какие файлы поисковым роботам не нужны и не важны. В этом отношении крайне важно обратить внимание на настройки файла robots.txt.

Известно, что поисковые системы используют «безголовый» просмотр для сканирования DOM, чтобы лучше понять UI и доступность контента на странице. Иными словами: поисковые системы могут обрабатывать JS и использовать DOM вместо HTML.

С другой стороны, в ряде случаев ПС не могут полноценно работать с JS – и это проблема, с которой нужно обязательно разобраться. И здесь есть несколько важных нюансов:

Чтобы избежать возможных проблем с рендерингом JS, можно отдавать поисковым роботам статический HTML с полной отрисовкой страницы, какой её должен получить посетитель. Да, официально этот способ не одобряется ПС. Однако в ряде случаев это единственный вариант: если ПС не в состоянии просканировать ваш контент, лучше отдать им статику, чем вообще ничего.

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

Когда браузер получает HTML-документ и начинает создавать DOM, большинство ресурсов загружается по мере их появления в HTML-документе. Если где-то в самом начале есть запрос на какой-то огромный файл, браузер сначала должен загрузить его, прежде чем продолжит загружать всё остальное.

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

Если в коде есть обращение к второстепенным ресурсам, в том числе – JS, они будут тормозить загрузку.

Решений несколько:

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

Вы переходите по URL. Браузер отправляет запрос на сервер. Если всё в порядке - сервер отправляет соответствующий HTML-документ. Этот документ содержит ссылки на внешние ресурсные файлы: картинки, CSS и JS. Обнаружив такие ссылки, браузер отправляет дополнительные запросы на сервер, чтобы загрузить эти файлы.

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

Начиная с какого-то момента страница уже станет доступной посетителю, потом – интерактивной, потом загрузится полностью (браузер перестанет отправлять запросы к серверу до каких-то действий со стороны посетителя). Количество и характер запросов, а также процессы рендеринга JavaScript напрямую влияют на время загрузки и время, необходимое до получения интерактивных возможностей страницы.

Быстродействие по типу CSR определяется множеством факторов:

Многое здесь определяется качеством разработки и оптимизацией используемого шаблона. Например, разработчики тем и плагинов для WordPress редко стесняют себя ограничениями в подключении тонн библиотек JS – просто на всякий случай.

Поисковые системы сканируют страницу в два захода. На первом сканируется исходный код, до выполнения подгружаемых JS. Если исходный код не содержит большей части основного контента, поисковик просто не поймёт, о чём эта страница. Чтобы полноценно просканировать страницу, он должен задействовать дополнительные вычислительные ресурсы и «отрисовать» страницу по результатам выполнения JavaScript. Далеко не факт, что этот процесс пройдёт быстро - он может занять недели. Собственно, не факт, что поисковая система вообще дойдёт до этого процесса, если не получит важные сигналы о необходимости этого.

Причина проста: интернет разрастается очень быстро, и поисковым системам не хватает ресурсов чтобы сканировать всё подряд.

Как следствие – страницы с большой зависимостью от выполнения JavaScript индексируются намного медленнее статических HTML-страниц. Но это ещё полбеды: если поисковая система при первичном сканировании «сырого» html сочтёт его маловажным, «тонким» или дублирующим другую страницу контентом, полноценного рендеринга может и вовсе не быть. А значит, в индекс не попадёт важный контент, который мог бы обеспечить вам более высокие позиции в поиске.

Что влияет на решение ПС, будет ли страница (и сайт) просканирована с полным рендерингом?

И, разумеется, способность ПС в принципе понимать используемые библиотеки JS без чрезмерного расхода ресурсов.

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

Серверный рендеринг – это процесс рендеринга страниц перед отправкой их клиенту, с формированием страницы на стороне сервера.

Процесс происходит в режиме реального времени, код JS выполняется после начальной загрузки.

Плюсы этого способа:

Минусы:

В случае использования динамического рендеринга сервер по-разному отвечает на полученные запросы в зависимости от того, от кого эти запросы исходят. Поисковый робот получает готовый HTML, посетитель-человек получит рендеринг в своём браузере.

Этот способ не рассматривается как постоянное решение, использовать его рекомендуют только временно.

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

Плюсы:

Минусы:

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

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

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

Плюсы:

Минусы:

Если при первичном сканировании поисковый робот не увидит важного контента, он сочтёт страницу неважной или некачественной, и рендерить контент, выводимый через JavaScript уже не будет, – как минимум, без дополнительных усилий с вашей стороны.

Обеспечьте доступ поисковых роботов к полной странице с обработанным HTML. Не рассчитывайте на то, что робот справится с вашими JS: может быть, справится, а может быть – нет. Возможно, что даже и не попытается.

Убедитесь, что все метатеги в «сыром» HTML совпадают с метатегами в рендере. Это касается тайтлов, мета-описаний, а также meta для роботов. Плохо, если важные указания для поисковых роботов выводятся только через JS – например, робот не сразу поймёт, что страничка не должна пойти в индекс. Это чревато напрасным расходом лимита на обходы, индексацией ненужного – и только для того, чтобы потом это ненужное деиндексировать.

Примечание. Этим отличаются сайты на WordPress: до сих пор все SEO-настройки в нём доступны в основном через плагины, а плагины используют JS.

Исходный html должен содержать ровно те же указания на каноническую страницу, что будут и в обработанной версии.

По утверждению представителей Google, гуглобот обрабатывает rel="canonical" только для первоначально отсканированной версии страницы. Если канонические адреса будут внедрены на страницы только через JS, гуглобот узнает о них слишком поздно, и до этого момента может просканировать тонны мусорных страничек. Вы потратите лимиты на обход совершенно впустую.

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

Что такое ссылка для разработчика? – Это нечто, где можно кликнуть и получить какой-то результат: перейти на какой-то URL, например. И неважно, как это реализовано. Тот же javascript позволяет из любого элемента сделать подобие ссылки. Это так и называется – «псевдоссылка».

Что такое ссылка с точки зрения поисковых систем? – это тег A с атрибутом HREF и описательным текстом, содержащим информацию о ссылке. Оптимально – в анкоре. Ссылка выполняет роль предиката, объединяющего субъект (страницу-донор) с объектом (страницей-акцептором).

О влиянии ссылок на ранжирование говорить здесь не буду. Важно понять: ссылки – это не просто навигация: если поисковая система не обрабатывает ваши «ссылки» как нужно, это проблема. Ссылки используются для оценки важности URL, его связи с другими узлами графа. Поисковые роботы используют ссылки, чтобы обнаруживать новые страницы, оценивать ассортимент, анализировать пользовательские сигналы, расставлять приоритеты. И если ПС не видит ссылки и не может по ним переходить – вы теряете, вы проигрываете.

Сама по себе идея постепенной подгрузки выглядит красиво. Незачем тратить время и ресурсы на то, до чего посетитель ещё не добрался – или и не доберется. Если на вашем сайте реализована «ленивая подгрузка» изображений (lazy-load) с помощью JS, это также может негативно сказываться на сканировании сайта.

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

Стоп, а как быть с картинками? Ведь lazy-load чаще всего используется именно по отношению к ним. – А тут всё просто. Если картинка – важная часть контента, размещайте её без всякой ленивой подгрузки, в соответствии с веб-стандартами. Медиа-мусор типа стоковых картинок или мемасиков можно размещать как угодно – это не иллюстрации, и никакой добавочной ценности вашему контенту не добавят.

PS Статья успела несколько устареть. Обновлять и добавлять контент по этой теме буду здесь: "JavaScript SEO: актуальные сведения и практики".