Проблемы с продвижением js-сайтов на React в Яндекс и Google - откуда возникают и как их предотвращать

Такое бывает :( Сделали хороший сайт на Javascript, а трафика из поисковых систем нет. Каковы возможные причины и как исправить эту грустную историю? Попробуем разобраться в этом вопросе с точки зрения клиента и, по возможности, без сложных терминов и абревиатур.

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

Делать решили на React (или другом js-фреймворке), потому что “все серьезные проекты делают на нем, он перспективный, гибкий, стильный, мощный. Это будет не сайт, а космический корабль”.

Несколько месяцев проектирования, рисования дизайна, программирования и ваша космическая яхта класса “Люкс” готова. Вы наполняете её последним контентом, разбиваете бутылку шампанского о борт и запускаете в плавание по просторам Интернета.

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

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

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

И ранжировать такой сайт поисковики не хотят.

SEO-специалисты в нашей компании неоднократно сталкивалась с подобными ситуациями на клиентских сайтах и мы знаем с какими проблемами в сайтах на React (и других js-фреймворках) приходится сталкиваться чаще всего.

Также наши Seo-специалисты сопровождают разработку проектов на React, которые делает наша команда разработки grammers.pro.

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

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

Например, на одном из проектов на React мы нашли следующее:

• адреса страниц с карточками товаров имели не ЧПУ вид (вместо /vashsite.ru/nazvanie-tovara URL содержало что-то вроде /vashsite.ru/nazvanie-kategorii/abrakadabra23456789900xyz )
• адреса подкатегорий тоже были не совсем ЧПУ - вместо /vashsite.ru/nazvanie-kategorii/nazvanie-podkategorii/ они формировались как результаты фильтра /vashsite.ru/nazvanie-kategorii?vid-tovara=adaptery - при том, что поисковые системы не любят URL с параметрами (то, что после знака ? )
• отдельные страницы регулярно оказывались недоступны для поисковых роботов (отдавали код 404), но при этом прекрасно открывались в браузере у человека
• время загрузки до первого взаимодействия с сайтом составляло более 10 секунд - это критически важный показатель для успешного SEO-продвижения
• меню каталога не индексировалось поисковыми системами - в результате, у сайта неправильно распределялся ссылочный вес между страницами
• на сайте обнаруживалось огромное количество дублей страниц, а также пустых страниц, не имеющих контента (например, страницы с условиями фильтров, которые не содержали товаров)
• на некоторых страницах большой вложенности появлялся лишний контент (тексты), который “подтягивался” с вышележащих страниц и т.д.

В итоге, сайт сильно проигрывал конкурентам.

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

Также неоднократно на React-сайтах мы сталкивались с такими проблемами:

• ошибки контента при работе с поддоменами - не “подтягиваются” нужные данные (чаще всего метатеги и тексты) по конкретному городу, возникают рудименты контента с основного домена
• для поддоменов не корректно работает карта сайта и robots.txt
• 500-е ошибки (ошибки сервера) при переходе по некоторым ссылкам
• 307 редиректы с поддоменов на основной домен
• отсутствие атрибутов у изображений
• отсутствие возможности сделать мета-теги для отдельных страниц
• подстановка имени поддомена вместо обозначения языка в lang html (характерно для ранних версий Next.js, где не была реализована поддержка поддоменов и мультидоменность решалась через мультиязычность)
• отсутствие указания канонических страниц (rel=canonical)
• разный контент страниц при включенном и выключенном в браузере Javascript
• задержка в публикации изменений на сайте - вносимые в админке изменения отображаются на сайте лишь после перегенерации страниц, что может происходить с задержкой в сутки и более. Это сильно бесит и мешает в работе с контентом.

Это далеко не исчерпывающий список, т.к. на разных проектах состав багов и несоответствий может быть разным.

Но в целом, большинство проблем возникает вокруг четырех факторов:

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

Почему это всё происходит? Есть несколько причин.

Первая причина, характерная для React - это любовь разработчиков к SPA (Single Page Application), а вернее, к CSR (Client Side Rendering). В переводе на русский - весь сайт на React - это всего одна страница, но очень сложная, похожая мобильное приложение - она сперва целиком загружается к вам в браузер, а потом начинает быстро и красиво работать, подтягивая с сервера только отдельные недостающие данные.

SPA и CSR - это действительно классная “фишка” - моментальное обновление контента сайта без перезагрузки страниц, удобные и динамичные интерфейсы в стиле мобильных приложений. SPA удобны для пользователей и относительно просты в разработке. И реактивные фреймворки (к которым относится React) изначально разрабатывались именно в рамках такого подхода.

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

Т.е. у поискового робота есть свое жесткое представление о том, какой должна быть хорошая страница сайта: длинная структурированная “портянка” html, в которой в явном виде прописаны мета-данные и все содержимое - тексты, цены, картинки (и их метаданные), обязательно есть уникальный URL, который вписан в иерархию адресов страниц. Эта страница полностью загружается меньше чем за секунду и роботу доступен всё ее содержимое в один проход.

Вместо этого, SPA и CSR отдают роботу пустую страницу с единственным адресом, на которую магическим образом позже подгружается внутреннее содержимое. Которое таким же “магическим” для робота образом может меняться. Никаких адресов страниц эта схема работы, по умолчанию, вообще не предполагает, хотя их и можно “прикрутить” сверху.

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

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

Есть несколько методов ухода от SPA к многостраничной модели, но тяжелое наследие CSR может преследовать ваш проект очень долго.

Любой js-программист скажет, что проблема номер 1 решается использованием SSR (Server Side Randaring) или SSG (Static Site Generator). Желающие могут более глубоко изучить этот вопрос тут.

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

Задача, кажется, решена - страницы есть, содержание их доступно для роботов, можно выстреливать в ТОП поиска.

Но дьявол, как обычно, кроется в деталях, и переход от динамической отдачи контента к статической генерации как раз и может создавать те проблемы, с которыми мы сталкиваемся на клиентских проектах: динамическое целое SPA-страницы нужно “нарезать” на N-ное количество статических страниц, продумать заранее, на какие изменения системы страница должна реагировать изменением URL, а на какие - нет.

Далеко не всегда разработчики правильно делают эту “нарезку”.

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

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

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

В вашу команду добавляется админ и сложность системы еще более возрастает, так же как и вероятность ошибок.

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

Разработка на фреймворке - это сложная инженерная задача, которая делается в строгом соответствии с ТЗ, их архитектура и функционал должны хорошо продумываться на старте проекта. И у таких проектов очень мало функционала “по умолчанию”. В отличие от готовых CMS, у которых 70% - “по умолчанию” и 30% - уникальной надстройки.

Многие команды при разработке веб-решений уделяют много времени маркетингу и поведению пользователей на сайте, удобству сайта для людей (вспомним CJM, UX/UI и другие волшебные сокращения), а также техническому совершенству кода, отказоустойчивости и нагрузочному тестированию. Это всё действительно важно, ведь они делают красивый и сложный инженерный продукт, а местами - произведение искусства.

Но “SEO-требования” в этом случае часто ограничиваются наличием метатегов и карты сайта.

Поисковые роботы исключаются из числа “целевой аудитории” и то, как роботы будут себя вести на сайте, их CJM (карта пути “клиента”) - не учитывается при разработке. В итоге, при эксплуатации у проекта оказывается много “дыр” в том, как его воспринимают поисковые системы. И здесь сайты, собранные на готовых CMS, могут выигрывать, потому что у них “под капотом” зашито много модулей и плагинов, которые были разработаны под требования SEO-специалистов - даже если вы не учли эти требования в ТЗ, они либо уже реализованы “по умолчанию”, либо их можно реализовать путем небольших доработок.

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

Даже если ваши разработчики используют SCRUM или другую гибкую методологию - она гибка только в плане скорости внедрения новых изменений. Но переделка архитектуры проекта - это в любом случае сложно и не быстро.

Т.е. в случае с фреймворками успешность продвижения нового сайта в поиске оказывается сильно завязана на компетенции в SEO у команд Заказчика и Исполнителя, насколько детально и глубоко они проработали вопрос продвижения на старте проекта. А такая компетенция есть не всегда.

Что же делать?

Самый правильный ответ на вопрос - “Что делать, чтобы решить проблемы с ранжированием сайта” - это “Изначально делать сайт так, чтобы в будущем проблем не возникало” т.е. детально прорабатывать соответствие будущего программного продукта требованиям поисковых систем ДО ТОГО, как начата его разработка. В нашей компании мы добиваемся этого через концепцию SEO-проектирования сайтов.

SEO-проектирование - это разновидность проектных работ, которые производятся ДО, ВО ВРЕМЯ и ПО ЗАВЕРШЕНИИ программных работ. Подробнее о том, как мы его делаем, смотрите вот эту статью.

Оно включает в себя несколько этапов:

• Предварительное SEO-проектирование
• SEO-сопровождение дизайна и разработки
• SEO-приёмка (авторский надзор при запуске)

В инфографике вы можете увидеть состав каждого этапа:

Очень важно, чтобы рекомендации, которые дает SEO-специалист, были учтены в технической документации по проекту. Но так же важно, чтобы сам процесс разработки веб-решения включал в себя SEO-экспертизу и команда понимала важность этих вопросов.

Что это значит:

• включение SEO-специалиста в команду разработки и коммуникацию команды
• регулярные митапы SEO-специалистов и разработчиков
• включение приемки выполненных задач SEO-специалистами как отдельной колонки на вашей доске проекта в Trello (или другом таск-менеджере)
• обязательный технический аудит SEO-специалистами dev-версии сайта перед обновлениями и prod-версии после обновлений сайта
• идентичность данных на dev и prod версиях (включая метаданные) - т.к. SEO - это не только про код, но и про данные и чем больше они различаются на dev и prod - тем сложнее работать SEOшнику
• фокусирование внимания команды на поисковых роботах как одной из разновидностей пользователя приложения - всегда задаем себе вопрос -“Как отреагируют Google и Яндекс на это наше действие?”

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

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

Известно, что "если вы не любите кошек, то вы просто не умеете их готовить". Но нужно ли вам вообще заниматься такой кулинарией? Далеко не для всех проектов применение реактивных фреймворков является оправданным.

Еще в 2019 коллеги из “Сибирикс" опубликовали прекрасную инфографику - какую систему лучше выбрать для какого сайта.

С определенными оговорками она до сих пор актуальна.

Оговорка 1 - не обязательно выбирать 1С-Битрикс, есть и другие хорошие CMS (главное, чтобы ваши разработчики имели большой опыт работы с ними).

Оговорка 2 - за 4 года сегмент SaaS-решений очень сильно прибавил в функционале, и теперь на них можно сделать не только сайт-визитку, но даже простой интернет-магазин с интеграциями (очень хорошее решение предлагает InSales, и даже Tilda сейчас активно развивается в этом направлении).

Но общие выводы не изменились: применение фреймворка для коммерческого сайта актуально, только если у вас:

• Нагруженный e-commerce, сложные личные кабинеты, интернет-стартап, высокие требования к гибкости
• Есть деньги
• У вас и ваших разработчиков достаточно экспертных знаний чтобы влезть в такой проект и по итогу вытащить из него рабочий и эффективный программный продукт.

Сама прекрасная схема выбора “движка” от В.Завертайлова:

Поэтому, прежде чем начинать строить космическую яхту, подумайте, точно ли оно вам надо? Или лучше использовать более простые варианты для создания сайта?

Если вы все таки решились делать ориентированный на SEO проект на React то можете обратиться к нам, в Сайтоник, за его SEO-проектированием. . или продвижением

А наша команда разработки grammers.pro может для вас сделать хороший сайт на Javascript, который точно понравится поисковым системам.

Удачи вам и много посетителей вашим сайтам :).