Последние сообщения

Постараюсь ответить на все вопросы:

Вопрос №1: На что следует ориентироваться при написании статей на сайт?

Ответ: В первую очередь статья должна полностью отвечать на вопрос пользователя «меньше воды, больше инфы по теме». Если будете писать статьи тупо «для продвижения» вам никакие ВЧ, НЧ и СЧ не помогут выйти в ТОП. Рано или поздно плохие поведенческие факторы (отказы, время на сайте, глубина просмотра и тд.) спустят ваш сайт далеко вниз.

Вопрос №2: Выбирать высокочастотные запросы и писать на такие запросы уникальную статью (для продвижения по запросу в топ) или выбирать среднечастотные запросы и продвигаться по ним?

Ответ: Если большая конкуренция, то в ВЧ запросах вам ловить пока нечего. Работайте на НЧ/СЧ и результат придет.

Вопрос №3: Стоит ли стремиться к продвижению по высокочастотным запросам?

Ответ: Стоит, но не раньше чем через год. Развивайте ресурс, делайте его интересным для людей, набирайте ЕСТЕСТВЕННЫЕ ссылки.

Вопрос №4: Какие моменты на этапе разработки сайта должны быть учтены?

Ответ: Семантическое ядро — фундамент вашего сайта. Анализ конкурентов, делайте сайт не хуже чем у них. Смотрите, что есть у ТОП сайтов, чего нет у вас и тд.

Вопрос №5: На сколько важно иметь на сайте оглавление у каждой статьи и что лучше ещё добавить, для успешного продвижения?

Ответ: Если вы под оглавлением имеете ввиду «Title», то очень важно, так же как и «Description», «H1», «H2, H3, H4, H5, H6» (в порядке важности, желательно что бы в статьях они так и шли по иерархии)… Главное что бы статью было удобно читать и все было разложено по полочкам, ну и содержание в начале каждой статьи. И не забывайте в метатегах разбавлять ключи понятными людям словами, что бы не терялся смысл.

Вопрос №6: Существует ли какой-то набор настроек которые в любом случае должны быть на сайте?

Ответ: Отчасти ответ в «вопросе №4». Не существует, так как алгоритмы поисковиков меняются по несколько раз в году и не когда не знаешь что придумают завтра. Лучший вариант что бы потом не проливать крокодильи слезы, это — см. ответ на Вопрос №1.

Вопрос №7: Как сказывается на SEO продвижении сайта домены типа: category.sitename.ru?

Ответ: Если я правильно понимаю это поддомен. Чаще всего используется для распределения сайта по регионам (moskow.sitename.ru, samara.sitename.ru и тд.) или для форумов и блогов сайта (forum.sitename.ru, blog.sitename.ru и тд.). Живут совершенно своей жизнью и оптимизируются под SEO отдельно от основного домена (sitename.ru). Вес и авторитетность основного домена (ТИЦ, PR и тд) не распространяются на поддомены.

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

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

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

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

Металл Профиль

А какая собственно разница, мы например внедряли в DST Portal стриминговый сервис и видеоканалы, это тоже огромные компоненты, просто пишите длинное ТЗ вместе со своим менеджером и затем создаете много, много прототипов, далее идет разработка. 

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

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Игорь Симонян

Спасибо за ответ, очень подробно расписали, но мне интересно как проходят сами процессы, не обязательно в ДСТ, а вообще как это обычно бывает в целом у всех, для общего так сказать развития и понимания 

Виталий Науменко

Такое дело, тогда уже зависит от команды и выстроенных процессов.

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

Про сами процессы:
Если пишет один человек, проще сначала сделать бекенд, потом писать фронт под готовое апи.
Если пишут два человека, можно создать апи-пустышку с захардкоженными данными, тогда одновременно работать могут начать и фронт и бек специалисты. Ставят такую заглушку, если бекенд делается долго, надо данные откуда-то еще перекачать или еще какие сложности, обычно быстрее сразу просто апи сделать.
В некоторых командах контракт согласовывают бек и фронт вместе (или кто-то главный над ними, который раздает потом задачи).
Иногда на фронте процесс выстроен таким способом, что пишутся тесы (не шутка). Там делаются моки запросов к апи и фронт пилится в отрыве от бекенда. Контракты, разумеется, должны так же совпадать

Имея контракты, можно придумать и архитектуру данных, как все по таблицам распихать, и архитектуру фронта, где как что будет получаться и храниться

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Игорь Симонян

Спасибо за ответ, очень подробно расписали, но мне интересно как проходят сами процессы, не обязательно в ДСТ, а вообще как это обычно бывает в целом у всех, для общего так сказать развития и понимания 

И тут я не совсем понимаю, есть макет и исходя из этого макета backend и придумывает структуру хранения данных в БД, или как оно работает?

Виталий Науменко

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

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Я обычно поднимаю ещё один контейнер с nginx, который слушает порты 80 и 443 на хосте и раскидывает запросы в разные контейнеры по доменам или по локейшенам.

Чтобы не прописывать вручную в hosts домены, когда сервисов много, использую nip.io

Такие же домены назначаю как hostname контейнерам, для единообразия.

А чтобы не писать однотипные конфиги nginx — hub.docker.com/r/jwilder/nginx-proxy/

Для управления самоподписанными сертификатами для разработки есть github.com/FiloSottile/mkcert

Используемые практики:

1. внутренняя зона DNS и внутренний CA для выпуска wildcard сертификатов.
Внешняя DNS зона и Let's encrypt или купленный wildcard сертификат для нее.

>> Frontend работает на localhost:3000.

>> API доступен по адресу localhost:3001.

Эти адреса действуют вне Docker. Внутри контейнера они используют формат «service_name:port». Это позволяет приложениям взаимодействовать друг с другом без обращения к внешним сервисам. Для упрощения можно использовать алиасы в файле docker-compose.yml.

Обратите внимание на этот важный мануал: docs.docker.com/compose/how-tos/networking/.

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

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

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

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