Interpult Studio

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

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

Что такое JavaScript SEO

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 на сайтах

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

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

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

Необходимо точное понимание, где, как и для чего JS используется в шаблоне страницы. От этого зависит, как будет индексироваться контент, не будет ли загрузка вашего сайта намертво «вешать» смартфоны посетителей, не станет ли неоптимизированный JS серьёзной проблемой для быстродействия сайта.

Почему важно контролировать JS на сайте

 

Я хотел использовать эту картинку для обложки, но счёл её слишком шизофренической.

 

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

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

Возможность сканировать сайт

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

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

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

READ  Как SEO может улучшить ваш бизнес?

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

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

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

Статический HTML

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

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

Задержка рендеринга

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

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

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

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

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

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

Как это работает

CSR (Рендеринг на стороне клиента)

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

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

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

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

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

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

В чем состоят проблемы

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

 

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

 

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

READ  Демпинг В Маркетинге - Что Это Такое И Что Делать, Если Конкуренты Демпингуют?

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

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

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

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

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

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

SSR (Серверный рендеринг)

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

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

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

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

Динамический рендеринг

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

 

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

 

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

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

  • Поисковые системы могут сразу просканировать всё важное содержимое в исходном HTML-ответе
  • Простая и быстрая реализация
  • Отладка затруднена.

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

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

Предварительный рендеринг

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

  • Единожды созданная страница обеспечивает высокую производительность и быстродействие

На что обращать особое внимание

Основной контент должен отдаваться поисковым роботам в виде рендера

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

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

Удостоверьтесь в правильности мета в «сыром» HTML

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

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

Canonical (канонические ссылки) в «сыром» HTML

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

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

READ  Гарнитура виртуальной реальности Sony PlayStation VR2 впервые показалась на фото

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

Оформление ссылок

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

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

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

Ссылки должны оформляться в виде статических элементов HTML. Исключение – если вы по каким-то причинам хотите их скрыть.

Lazy-load

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

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

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

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

 

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

 

Общие выводы

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

https://vc.ru/seo/414784-javascript-i-seo-problemy-i-resheniya

от admin