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

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

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

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

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

• Сайты, использующие JS в ограниченном объёме: для оформления небольших интерактивных элементов, анимации, дизайна, всплывающих окон, чатов, скриптов аналитики и т.п. Основной контент таких сайтов выводится в HTML и не зависит от javascript.
• JS-rich сайты, активно использующие JavaScript и AJAX не только для оформления, но и для вывода значительной части основного контента.
  
• SPA (single page application) – одностраничные приложения, работающие исключительно на JavaScript. Такие сайты значительно быстрее традиционных, поскольку не обращаются к серверу для загрузки дополнительного контента: все ресурсы кэшируются в локальном хранилище после первого обращения к серверу. Однако при первичном запросе клиент не получает никакого контента в рамках HTML – только JavaScript.
  

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

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

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

• Диагностика и устранение проблем с ранжированием одностраничных предложений (SPA), построенных на платформах React, Vue, Angular и т.п.
• Улучшение быстродействия и скорости загрузки страниц, использующих JS.
  
• Обеспечение возможности обнаружить страницы сайта на JS с помощью перелинковки.
  

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

• Текстовый контент, выводимый средствами JS
• Формирование адаптивного шаблона сайта для смартфонов
  
• Отложенная загрузка изображений (lazy-load)
  
• Ссылки, реализованные через javascript
  
• Формирование метаданных
  
• Время загрузки страницы
  

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

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

• способность поисковых роботов сканировать ваш сайт;
• возможность поисковых систем извлекать и анализировать контент на сайте;
  
• воспринимаемая пользователем задержка загрузки и отрисовки страниц.
  

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

• Поисковик может счесть, что сайт не адаптирован для мобильных устройств;
• дизайн сайта может быть воспринят как устаревший или непривлекательный;
  
• часть контента может остаться вне поля зрения ПС.
  

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

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

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

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

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

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

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

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

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

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

• Можно встроить JS в HTML. Как минимум, все скрипты должны лежать у вас на сервере, а не в стороннем репозитории;
• Добавить атрибут async в теги (асинхронная загрузка JS);
  
• Отложить загрузку JS, разместив их ниже в HTML (например, не в области HEAD, а в самом низу, перед закрытием тега BODY;
  
• Использовать HTTP/2 с его многопоточностью и асинхронностью.
  

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

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

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

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

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

• Количеством и объёмом загружаемого контента
• Количеством запросов к серверу
  
• оптимизацией кода JS
  

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

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

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

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

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

• Возраст домена и его история
• Предполагаемые объёмы сайта
  
• Пользовательские сигналы
  

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

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

• Серверный рендеринг
• Динамический рендеринг
  
• Предварительный рендеринг
  

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

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

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

• Все важные для поисковых систем элементы доступны сразу, в исходном HTML
  
• SSR обеспечивает быструю первую отрисовку (FCP).
  

Минусы:

• Увеличивается время до получения первого байта (TTFB), поскольку сервер должен сформировать страницу фактически на лету.

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

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

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

Плюсы:

• Поисковые системы могут сразу просканировать всё важное содержимое в исходном 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 выше «линии сгиба». Важно: «линия сгиба» — это не первый экран, как часто думают. В этом плане важно, как сканирует контент поисковый робот, а не посетитель-человек. Рассчитывайте минимум на 2,5-3 экрана, притом с учётом и адаптивной вёрстки для смартфонов.
• Откажитесь от мусора на первом экране. В данном случае речь идёт уже о людях. Первое, на что должен падать взгляд человека – это контент, подтверждающий, что человек попал куда и собирался. Вместо этого его часто встречают какие-то формальные слайдеры с прошлогодними акциями и прочие отходы шаблонного веб-дизайна.
  
• Обеспечьте ссылки на контент ниже «линии сгиба». До появления Web-3.0 с мета-ссылками в рамках баз данных самих поисковых систем ссылки были, есть и будут основным способом перемещения роботов. Если вы озаботитесь ссылками на контент, который не подгружается сразу в рамках «сырого» HTML, вы значительно упростите процессы сканирования и индексирования сайта. И да, в этом случае речь идёт о «якорных» ссылках на заданные фрагменты страницы.
  

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

• При всей привлекательности JS-фреймворков (стильно, модно, молодёжно) перенос сайта на такую платформу может убить вам трафик из поиска. Потратьте время на проектирование и тестирование, и не идите на поводу у хотелок разработчика, которому всего лишь хочется прокачать скиллы в новой для него сфере.
• Используйте дебаггеры: от инструментов панелей вебмастеров и парсеров, умеющих эмулировать поисковых роботов, до простых браузерных плагинов. Отключил JS – и сразу видно хотя бы часть грубых ошибок. Кроме JS, рекомендуется отключать для тестов CSS и «куки» – их также контролируют средства JavaScript.
• Весь основной контент должен выводиться средствами «сырого» HTML, с использованием семантической вёрстки, в рамках первых трёх экранов.
  
• Ссылки на заданный фрагмент страницы, реализуемые через id, официально признаются игнорируемыми, поскольку ведут на одну и ту же страницу. Однако, как показывает практика, ПС всё-таки их используют – просто не всегда. Гарантий нет, но поэкспериментировать точно стоит.
  
• Общее правило: оставьте JS для вывода второстепенного контента, неважного для оценки страницы поисковыми роботами. Метатеги, canonical, основной контент, навигацию выводите средствами HTML. В любом случае: думайте о продвижении заранее, чтобы не переделывать сайт снова.
  
• Если ваша новая страница попала в индекс – не спешите радоваться. Убедитесь, что весь важный контент попал в кэшированную версию. Позиции на выдаче могут резко измениться после вторичного сканирования страницы и изменения её текстовых характеристик, как вверх, так и вниз.

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