Если SPA не подходит из-за требований к SEO, можно рассмотреть гибридный подход. Например, использовать SSR (Server-Side Rendering) или статическую генерацию страниц через современные инструменты вроде Next.js или Nuxt.js. Они позволяют рендерить HTML на сервере, сохраняя SEO-дружественность, но при этом дают гибкость в разработке интерфейсов на React/Vue.
В вашем случае, если DST Platform генерирует HTML на бэкенде, можно вынести фронтенд-логику в отдельные модули. Например, оставить базовую разметку в шаблонах DST, а интерактивные элементы (формы, фильтры) реализовать через изолированные JS-компоненты, подгружаемые асинхронно. Это сохранит SEO и упростит поддержку.
Для полного разделения фронтенда и бэкенда можно разработать API на DST Platform (если его нет) и подключить к нему фронтенд на любом фреймворке. Но тогда SSR становится обязательным — иначе поисковики не увидят контент.
DST Global
Отличное решение оптимизации без потери SEO, но я бы посоветовал еще практичный компромисс:
Полный переход на JS-сборку шаблонов без потери SEO возможен только с SSR или статической генерацией, но это потребует серьезных изменений архитектуры. Если задача — минимизировать риски, лучше оставить генерацию HTML на DST Platform, а фронтенд-логику вынести в микросервисы.
Например, можно разделить код :
— Бэкенд (DST + ASP) отвечает за данные, рендеринг базового HTML и API.
— Фронтенд подключается как отдельные JS-бандлы (например, через Webpack) только для интерактива (слайдеры, формы).
Такой подход сохранит SEO (основной контент в HTML) и упростит разработку. Для более глубокой интеграции можно использовать Astro — он позволяет смешивать SSR и статику с островной архитектурой, где JS загружается только для нужных элементов.
Если же хочется современный стек без головной боли с SEO — Next.js с адаптерами под DST API будет лучшим выбором, но потребует переработки шаблонов.