Как отделить frontend в проекте с упором на SEO?

Добрый день!

У нас есть информационный сайт с множеством страниц и контента. Основная цель — SEO-продвижение, поэтому использование SPA (Single Page Application) невозможно.

Сейчас сайт написан на DST Platform с элементами ASP который писали уже дополнительно. В view HTML собирается вручную и отправляется браузеру. JS подключается отдельными скриптами для управления функционалом.

Есть ли современные способы перенести сборку шаблонов на JS без потери SEO? Если нет, как правильно отделить фронтенд от бэкенда в этом случае?

Странное утверждение, учитывая, что SPA-сайты без особых проблем можно рендерить на сервере для первоначальной загрузки. Для поисковых систем такой сайт ничем не будет отличаться от любого другого. Если SPA на React, то все подобные проблемы решает NextJS. Для других фреймворков тоже есть готовые решения для SSR (server side rendering).

SPA + SSR полностью решает Вашу проблему. 

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

Если SPA не подходит из-за требований к SEO, можно рассмотреть гибридный подход. Например, использовать SSR (Server-Side Rendering) или статическую генерацию страниц через современные инструменты вроде Next.js или Nuxt.js. Они позволяют рендерить HTML на сервере, сохраняя SEO-дружественность, но при этом дают гибкость в разработке интерфейсов на React/Vue.

В вашем случае, если DST Platform генерирует HTML на бэкенде, можно вынести фронтенд-логику в отдельные модули. Например, оставить базовую разметку в шаблонах DST, а интерактивные элементы (формы, фильтры) реализовать через изолированные JS-компоненты, подгружаемые асинхронно. Это сохранит SEO и упростит поддержку.

Для полного разделения фронтенда и бэкенда можно разработать API на DST Platform (если его нет) и подключить к нему фронтенд на любом фреймворке. Но тогда SSR становится обязательным — иначе поисковики не увидят контент.

Если 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 будет лучшим выбором, но потребует переработки шаблонов.