4 трудности JavaScript, которые мешают в продвижении сайта | Статьи SEOnews

4 трудности JavaScript, которые мешают в продвижении сайта | Статьи SEOnews
Дмитрий Лебедев Старший SEO-аналитик KINETICA javascript (дальше JS) употребляют для того, чтоб добавить сайту больше способностей, прирастить скорость его работы, сделать ресурс более симпатичным и комфортным за счет прибавления обыкновенных нам частей – слайдеров, аккордеонов, комфортных скроллов и анимации. По сути, скрипт отвечает за всю красу и находится безусловно на всех сайтах. 

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

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

Уязвимые места мы выявляем на аудите или вижене. Для начала мы определяем, к какому из 3-х типов по размеру применения JS относится сайт: 

  1. Сайты-SPA на базе JS. При всей красе сайта – это самый проблемный для SEO вариант. Тут нет перезагрузки страничек, весь контент меняется за счет JS, а поисковики могут не постоянно корректно его регистрировать. 
  2. Сайты, выводящие SEO-значимый контент с поддержкою JS. Контент, означаемый для поисковиков, выводится при участии юзера (раскрытии перечня) . Метод просит кропотливой проработки JS SEO, чтоб боты таковой контент проиндексировали. 
  3. Сайты, ограниченно использующие JS (для дизайна, анимации, творения всплывающих окон) . Главная часть контента таковых страничек выводится в HTML без роли JS. Заморочек с индексацией практически не возникает. 

Определив тип сайта и собрав всю информацию, мы создаем техническое задание на доработку JS. 

Время от времени исправления незначимые, но посещает, что сайту требуется суровая доработка. К примеру, ежели это SPA-сайт (1-ый тип) , то, вероятно, будет одно мажорное решение по рендеру страничек и напротив – ежели JS употребляется в наименьшем объеме (2-й и 3-й типы) , то будет много точечных правок. 

А сейчас переходим к конкретно к дилеммам и их решениям. 

Неувязка 1. Поисковики не видят главный контент 

Решение: добавьте контент в «сырой» HTML или используйте другой подход к рендерингу. 

Часть контента может не индексироваться ПС из-за применения JS, а означает, страничка, по факту содержащая ответ на интент юзера, будет слабо расценена роботом. 

К примеру, вы сделали при поддержки JS на сайте блок FAQ, для раскрытия которого требуется событие юзера. Боты увидят вопросцы «Как живо творцы могут посодействовать с решением задач?», «Как выбрать творца?» и иные, но не увидят ответы, потому что юзер может раскрыть перечень нажатием клавиши. Из-за этого часть страницы не попадет в индекс и будет ужаснее ранжироваться. 

Пример выпадающего перечня, сделанного при поддержки JS 

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

Добавив ответы на вопросцы в «сырой» HTML, мы даем понять боту, что на страничке FAQ юзер сумеет узреть ответы. Так, даже без рендера страницы, поисковая система сумеет узреть содержимое блоков и учесть его в ранжировании сайта. 

Это самый обычный вариант, который подходит не во всех вариантах. Ежели ситуация не осмелится прибавлением контента в «сырой» HTML, нужно выбрать другой метод рендеринга. Мы выделяем три более знаменитых подхода: 

Заглавие подхода

Особенности

Рендеринг на стороне сервера

Юзер раскрывает сайт и получает от сервера или кусок готовой страницы, а следом оставшуюся часть, или страницу полностью.

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

Сервер распознает, кто конкретно исполняет запрос к сайту. Ежели его делает юзер, рендеринг страницы делает браузер без роли сервера. Ежели поисковый бот — сервер посылает ему готовую страницу HTML.

Гибридный рендеринг

Контент и все главные элементы страницы формируются сходу на стороне сервера, а элементы второго порядка, не действующие напрямую на ранжирование, отрисовываются на стороне юзера.

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

Неувязка 2. Поисковики не видят ссылки 

Решение: оформляйте ссылки в виде статических частей HTML, чтоб ПС могли вас найти. 

Ссылки так же, как и контент, юзер и бот ПС воспринимают по-разному. В первом случае ссылка – это то, на что можнож кликнуть. Тогда как во 2-м – это особый тег < a >, в каком обязаны содержаться атрибут HREF и информация о ссылке. 

javascript дозволяет из хоть какого элемента сделать «псевдоссылки» с внедрением тегов < div > и < span >. Смотрятся они как ссылки, но такими не являются.  

Юзеру благовидно и комфортно, а ПС не может такие ссылки найти, потому что их нет в «сыром» HTML. Это означает, бот не сумеет узреть новейшие страницы, оценить ассортимент, проанализировать пользовательские сигналы и расставить ценности. 

Боты не переходят по ссылке не видят контент -> страничка не индексируется -> юзеры не знают о ее существовании, потому что не могут перейти на нее из выдачи -> вы проигрываете. 

Мы советуем применять ссылки с атрибутом href и атрибутом описания (анкором) . Это дозволяет организовать перелинковку для страничек, которую увидят не совсем лишь юзеры, но и поисковые системы. Технически это смотрится так: 

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

Для того чтоб фильтр в каталоге активизировался, юзеру нужно было выбрать свойства и надавить клавишу «Применить», другими словами итоговая страничка раскрывалась опосля событий юзера. 

Сам фильтр работал без сбоев, но из-за того что появление обновленных страничек требовало событий самого юзера, боты не могли их просканировать. В итоге отфильтрованных страничек не было в индексе обеих поисковых систем. 

Другими словами, ежели юзер вводил название категории в поиск – к примеру, «кофе 3 в 1 жокей», он не видел в выдаче страницу с данной категорией. 

Поисковая выдача по запросу листинга 

Мы посоветовали на страничке каталога в свойство каждого фильтра (Тип кофе, Помол и иные) добавить ссылки на страницы этого фильтра. Другими словами чтоб в каждом теге фильтра бот увидел ссылку, по которой можнож перейти и поглядеть информацию. 

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

Страницы с категориями возникли в выдаче ПС 

А внутренний вес, передаваемый с родительских категорий, показал значимость этих страничек. Это позволило прирастить покрытие запросов и расширить запросный индекс. Сейчас на конкретные запросы юзеров есть подходящие посадочные страницы. 

Неувязка 3. Поисковики не видят главные элементы из-за отложенной загрузки 

Решение: не используйте lazy-load для всего означаемого контента. 

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

Чем это превосходно:

  • забота о юзерах с низким лимитом интернет-трафика – он будет расходоваться по мере загрузки картинок. Необыкновенно lazy-load актуален сайтам со стоковыми изображениями;
  • ускорение загрузки страниц. Юзеру будет показываться сходу 1-ый экран заместо рендера всей страницы. А пока он прочитает 1-ый экран, загрузится все другое. 

Googlebot поддерживает метод отложенной загрузки (lazy-load) , но, в отличие от юзера, не «прокручивает» страницы сайта при индексировании. Заместо этого Googlebot просто удлиняет виртуальное окно просмотра (видимую область) . 

Как юзеры и Googlebot видят контент на рабочем столе и мобайле 

Как следствие, поисковый бот не «видит» контент, который еще лишь обязан загрузиться. При иных одинаковых критериях это может плохо воздействовать на ранжирование, желая юзер не будет испытывать никаких проблем с просмотром. 

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

Допустим, у вас интернет-магазин одежды 1-го бренда. У вас маленький ассортимент и соперничаете вы с мультибрендовыми магазинами. В данном варианте карточки продуктов – самый главный фактор в ранжировании, потому поисковый бот непременно обязан их узреть. 

Ежели карточек 50, означает, он обязан узреть все 50. А при использовании отложенной загрузки бот увидит лишь то количество, которое находится в видимой доли экрана. 

Что советуем мы: 

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

Загрузка главной инфы без lazy-load дозволит боту узреть карточки продуктов (заглавие, описание и т.д.) , не видя при всем этом рисунки. 

Неувязка 4. Юзер длинно ожидает загрузку страницы и уходит, не дождавшись 

Решение: оптимизируйте код javascript и CSS для ускорения загрузки страничек. 

В 1-ые несколько секунд опосля перехода на сайт юзер обязан узреть контент. Чем прытче это случится, тем лучше – он усвоит, что остальной контент быстро подгрузится и он сумеет выучить страницу. Мы теснее ведали, как сделать так, чтоб юзер зашел на сайт не возвратился в выдачу. 

Тут есть одно «но». Юзер еще может подождать загрузки страницы (все зависит от его терпения) , а у бота время ожидания заложено методом. Ежели страничка не успела прогрузиться и бот увидел порожней экран, означает, он не будет подозревать, что на страничке обязан быть контент.  

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

Что советуем мы: 

  1. Добавьте главный JS-код в HTML. Сюда относится контент первого экрана с информацией, которую юзер может прочесть без прокрутки экрана вниз. 
  2. Отложите некритичный JS-код, пока главной контент не будет отрисован ботом. Сюда относится контент футера, который необязательно загружать в самом начале. Главнее отдать отрисовать боту контент первого экрана. 

А что в итоге 

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

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

Добавить комментарий

Нам важно знать ваше мнение. Оставьте свой отзыв или ответ

Комментариев 0

Обновления на форуме