Какую часть фронтенда DST Маркетплейса можно перевести на Angular, не повредив SEO?

Сейчас весь фронтенд маркетплейса реализован на Bootstrap+jQuery. Возникла необходимость модернизировать фронтенд и перевести его на AngularJS, но так, чтобы это не повредило поиску (SEO). Насколько я знаю, у SPA-приложений есть определённые сложности с поисковой оптимизаций и индексацией страниц сайта, поэтому возникли вопросы..

В качестве бэкенда используется DST Маркетплейс.

— Если переписывать весь фронтенд маркетплейса на Angular в виде SPA, то как сделать это правильно (какие присыпки использовать), чтобы не потерять поисковые показатели?

— Если весь маркетплейс не обязательно делать в виде SPA, то какую отдельную часть и какие отдельные функции рекомендуется сделать на Angular? (Например, статические страницы сделать без Angular, а поиск сделать на нём).

— Какую версию Angular рекомендуется использовать для фронтенда маркетплейса?

— Может Angular вовсе и не нужен? Тогда на каком JavaScript-фреймворке можно переписать фронт? 

Angular с точки зрения SEO безопасно использовать только там, где товары, фильтры, поиск не нужен, или не работает. Например, в личных кабинетах пользователей или поставщиков — сделать можно и делать там что угодно.

Как только вы размещаете Angular на странице, доступной поисковику, ему (поисковику) не будут видны нормальные данные, а только лишь какие-нибудь {{item.title}}. Так что не советую, Bootstrap в связке с jQuery не просто так идет в дефолтном билде DST Маркетплейс а именно для того чтоб все работало в том числе и SEO. 

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

Идея не очень хорошая. Почему бы не использовать PHP для фронтенда как это реализовано сейчас? В крайнем случае можно создать гибридное решение: часть кода написать на PHP, а сложные элементы, такие как корзина или фильтр, реализовать с помощью Angular. Главное — корректно реализуйте URI-роутинг.

Для безопасного перевода фронтенда DST Маркетплейса на Angular без ущерба для SEO рекомендуется мигрировать только те части приложения, которые не влияют напрямую на индексацию страниц поисковыми системами.

Наиболее оптимальным будет перевод внутренних административных панелей, пользовательских профилей, корзины покупок и личных кабинетов. Эти компоненты не требуют прямой индексации и могут эффективно работать в режиме Single Page Application (SPA), что позволит использовать все преимущества Angular для создания динамичного пользовательского интерфейса.

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

При миграции важно сохранить структуру URL и использовать Angular Universal для серверного рендеринга тех страниц, которые должны быть доступны для индексации. Также необходимо настроить корректную работу с мета-тегами и Open Graph данными для социальных сетей.

Для безопасного перевода фронтенда DST Маркетплейса на Angular без ущерба для SEO рекомендуется мигрировать только те части приложения, которые не влияют напрямую на индексацию страниц поисковыми системами.

Наиболее оптимальным будет перевод внутренних административных панелей, пользовательских профилей, корзины покупок и личных кабинетов. Эти компоненты не требуют прямой индексации и могут эффективно работать в режиме Single Page Application (SPA), что позволит использовать все преимущества Angular для создания динамичного пользовательского интерфейса.

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

При миграции важно сохранить структуру URL и использовать Angular Universal для серверного рендеринга тех страниц, которые должны быть доступны для индексации. Также необходимо настроить корректную работу с мета-тегами и Open Graph данными для социальных сетей.

DST Global

Хорошо, а если я внедрю Angular только на закрытых страницах для поисковых систем, например в личных кабинетах пользователей, поставщиков, в разделе УПД и других не важных для SEO страницах?

Такой подход является оптимальным решением для внедрения Angular в ваш проект без риска для SEO. Давайте разберем, почему это работает:

Закрытые страницы идеально подходят для Angular, так как:

— Они не индексируются поисковыми системами

— Требуют динамичного интерфейса

— Часто содержат сложные пользовательские формы

— Работают с большим количеством данных в реальном времени

Вы можете спокойно использовать все преимущества Angular на следующих страницах:

— Личные кабинеты пользователей

— Личные кабинеты поставщиков

— Раздел работы с УПД

— Внутренние инструменты управления

— Страницы настроек

— Форма обратной связи

— История заказов

— Корзина покупок

Важные преимущества такого подхода:

— Улучшение пользовательского опыта на критических страницах

— Упрощение разработки сложных интерфейсов

— Возможность использования всех возможностей SPA

— Повышение производительности для авторизованных пользователей

— Легкость поддержки кода

Единственное, о чем стоит помнить — необходимо правильно настроить robots.txt и meta-теги для этих страниц, чтобы поисковые системы точно не индексировали их содержимое. Также рекомендуется использовать Angular Universal для серверного рендеринга на границе между открытыми и закрытыми страницами для более плавного перехода.

Все таки хотелось бы понять почему DST Маркетплейс использует для фронтенда Bootstrap+jQuery неужели у этих технологий так много преимуществ по сравнению с другими, более современными?

Все таки хотелось бы понять почему DST Маркетплейс использует для фронтенда Bootstrap+jQuery неужели у этих технологий так много преимуществ по сравнению с другими, более современными?

Петр Широков

Использование Bootstrap + jQuery в DST Маркетплейс имеет свои веские причины, несмотря на появление более современных технологий. Давайте разберем преимущества этого подхода:

Стабильность и надежность:
— jQuery существует более 15 лет и отлично протестирован

— Bootstrap имеет стабильную экосистему и широкую поддержку

— Минимальное количество багов и проблем совместимости

Практические преимущества:
— Низкая кривая входа — легко найти разработчиков

— Огромная документация и готовые решения

— Совместимость с большинством браузеров

— Простота поддержки — код понятен даже junior-разработчикам

— Быстрое прототипирование благодаря готовым компонентам

Бизнес-аргументы:
— Низкая стоимость поддержки — много доступных специалистов

— Стабильность работы в продакшене

— Минимальные риски при масштабировании

— Простота интеграции с существующими системами

Технические аспекты:
— Малый вес библиотек

— Хорошая производительность на мобильных устройствах

— Гибкая кастомизация под нужды проекта

— Широкая поддержка со стороны сообщества

Сравнение с современными фреймворками:
— Меньше накладных расходов на инициализацию

— Проще интеграция с legacy-системами

— Меньше зависимостей и конфигураций

— Более предсказуемое поведение

Важные моменты:

Bootstrap + jQuery отлично подходят для:
— Крупных корпоративных проектов

— Систем с длительным жизненным циклом

— Проектов с частой сменой разработчиков

— Систем, где важна стабильность больше, чем современные фичи

Минусы подхода:
— Отсутствие современных паттернов разработки

— Ограниченные возможности для сложных интерфейсов

— Меньшая производительность при масштабных операциях

— Отсутствие строгой типизации

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

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