Динамический сайт нужен, если содержимое страниц или доступные действия зависят от данных и посетителя: например, для каталога, который обновляется из системы учёта, или личного кабинета. Если страницы почти не меняются, начните со статического сайта. До выбора платформы опишите сценарии и источники данных, а перед запуском проверьте их работу.
Когда нужен динамический сайт, а когда хватит статического
Динамический сайт нужен, если содержимое страницы или доступные действия зависят от данных, посетителя либо состояния заказа. Каталог, который обновляется из системы учёта, личный кабинет и форма с передачей заявки в CRM — примеры таких задач. Если страницы почти не меняются, а посетителю достаточно прочитать информацию и связаться с компанией, начните со статического сайта.
Анимация и всплывающее окно не требуют динамического сайта: страница выглядит живой, хотя данные в ней не меняются. Форму на статической странице тоже можно подключить через сервис приёма заявок или отдельный обработчик.
Выбирайте основу сайта по работе с данными, а не по движению элементов на экране.
Представьте каталог, в котором менеджер вручную меняет цены на страницах. Если изменения редки, этот порядок может устраивать команду. Когда цены и остатки поступают из системы учёта, полезнее наладить передачу данных, чем повторять одни и те же правки на сайте.
Какие задачи и функции заложить до выбора технологии
Функции сайта описывают через действия людей, а не через названия модулей. Слово «корзина» оставляет простор для догадок. Фраза «покупатель добавляет товар, видит итоговую сумму и оставляет контакты для доставки» уже задаёт сценарий, который можно проверить. Интернет-магазину нужна корзина, а сайту услуг она ни к чему. Поэтому список функций составляют под задачи проекта.
Для каждого сценария заполните карточку:
- Участник: посетитель, менеджер, редактор или администратор.
- Действие: что человек делает на сайте.
- Данные: откуда они берутся и куда записываются.
- Результат: что человек видит после действия.
- Проверка: как заказчик убедится, что сценарий работает.
Права редактора и администратора входят в требования наравне с действиями посетителя. Кто правит цены, кто видит заявки, кто удаляет страницы? Решите это до разработки, иначе правила придётся придумывать на приёмке.
Для корпоративного сайта со структурой, дизайном, текстами, каталогом и заявками в CRM опишите, кто обновляет каталог, как посетитель отправляет заявку и куда она поступает.
Как работает динамический сайт: страница, сервер и данные
Путь заявки начинается в браузере: посетитель заполняет форму, а сайт отправляет данные на сервер. Сервер проверяет поля, сохраняет запись и при необходимости передаёт её в CRM. После этого посетитель видит подтверждение или сообщение об ошибке. Такой путь удобно нарисовать до разработки — на схеме сразу заметно, где заявка рискует потеряться.
У частей сайта разные роли. HTML и CSS отвечают за разметку и оформление, JavaScript в браузере — за действия на странице. Сервер обрабатывает запрос, база данных хранит записи, а API связывает сайт с внешней системой. Конкретную базу и серверные инструменты выбирают под проект.
Что делать, если CRM не отвечает? Если обращения нельзя терять, предусмотрите сохранение заявки на стороне сайта и отдельную проверку её передачи. Затем покажите посетителю сообщение, соответствующее результату: подтверждать доставку в CRM до её ответа нельзя. Обработку первых обращений можно вынести в чат-бота в Телеграме, но для его заявок тоже нужен понятный путь хранения.
CMS или заказная разработка — как выбрать основу сайта
Для сайта со статьями, каталогом и типовыми формами сначала рассмотрите CMS. Готовые инструменты сокращают объём работы, если они подходят вашим сценариям. Заказную разработку оценивайте отдельно, когда работу сайта определяют нестандартные роли, расчёты или обмен данными между системами. Само наличие CRM ещё не повод писать платформу с нуля: сначала проверьте возможности выбранной CMS.
| Критерий | CMS | Заказная разработка |
|---|---|---|
| Типовые функции | Готовые модули и плагины | Разрабатываются под задачу |
| Нестандартная логика | Требует проверки возможностей платформы и доработок | Проектируется под согласованные сценарии |
| Интеграции | Зависит от платформы и доступных модулей | Проектируются под нужные системы и API |
| Обновления | Проверяют совместимость платформы, модулей и доработок | Поддерживают и обновляют код проекта |
| Поддержка | Следят за платформой и зависимостями | Сопровождают собственный код |
Для каталога, форм и передачи заявок в CRM я бы начал с оценки CMS. Если готовые модули заставляют менять основной рабочий процесс компании, это уже плохая основа: сравните её доработку с заказной разработкой на одних и тех же сценариях.
При смене платформы придётся переносить данные и заново проверять пользовательские пути. Поэтому решение лучше принимать после разбора сценариев, а не по названию системы.
Что подготовить, чтобы оценить сроки и бюджет
Срок и бюджет зависят от функций, состояния данных и объёма интеграций. Число страниц само по себе мало говорит о работе: карточки из подготовленной выгрузки и страница с расчётом стоимости требуют разных усилий. До запроса сметы соберите сценарии, укажите источники данных и покажите, что уже готово. Тогда исполнитель сможет объяснить оценку по составу работ.
Оценку стоит проверять по согласованным сценариям и состоянию данных, а не по числу страниц.
Исполнителю понадобятся перечень страниц и ролей, сценарии, состав каталога, источники контента и сведения о внешних системах. Попросите разложить оценку на проектирование, дизайн, разработку, интеграции, перенос данных, тестирование и запуск.
Объём работ меняется, когда выясняется, что данные не готовы или у пользователей есть дополнительные роли. Разрозненные таблицы каталога сначала придётся привести в порядок. Если обмен с CRM ещё не описан, его нельзя надёжно оценить как готовую задачу.
Зафиксируйте допущения и исключения из объёма. Назначьте ответственных за материалы и согласуйте, как будете обсуждать изменения после начала работ.
Какие результаты принимать на этапах разработки
У каждого этапа разработки должен быть результат, который заказчик способен проверить. Программирование опирается на согласованные сценарии и прототип; проверять каталог без подготовленных данных трудно. Назначьте человека, который принимает решения по содержанию, и того, кто проверяет техническую часть. Иначе замечания появятся только перед запуском, когда исправления затронут уже собранные страницы.
| Этап | Что сдаёт исполнитель | Кто согласует | Критерий приёмки |
|---|---|---|---|
| Анализ задач | Описание целей и сценариев | Владелец проекта | Каждая цель связана со сценарием |
| Требования и структура | Описание функций, карта страниц | Владелец проекта, ответственный за контент | Роли и страницы описаны |
| Прототип | Схемы экранов | Владелец проекта | Сценарии проходятся по схемам без тупиков |
| Дизайн | Макеты основных страниц | Владелец проекта | Макеты соответствуют прототипу |
| Программирование и интеграции | Работающая версия на тестовой среде | Технический специалист заказчика | Сценарии работают, данные доходят до нужных систем |
| Наполнение | Загруженный каталог и тексты | Ответственный за контент | Данные отображаются без ошибок |
| Проверка | Протокол тестирования | Владелец проекта | Дефекты закрыты и перепроверены |
| Запуск | Сайт на рабочем адресе | Владелец проекта | Формы, доступы и копии проверены |
Если после согласования требований меняются роли, данные или интеграции, пересмотрите состав работ и оценку. Порядок таких изменений лучше определить до начала проекта.
Что предусмотреть для хостинга, доступов и резервных копий
До запуска решите, где разместить сайт и кому выдать доступы. Требования CMS или приложения к среде сверяйте с документацией выбранного продукта: важны совместимость программ, базы данных и расширений. Отдельно проверьте, кто управляет доменом и хостингом. Заказчику нужны доступы, с которыми он сохранит контроль над сайтом при смене подрядчика.
Разработчикам, редакторам и администраторам нужны разные права. Редактору не требуется управление сервером, а разработчику — постоянный доступ ко всем рабочим учётным записям. Журнал ошибок поможет разбирать сбои по записям, а не по пересказам пользователей.
Наличие резервной копии ещё не доказывает, что сайт удастся восстановить. Проверьте восстановление на тестовой среде.
Порядок копирования зависит от того, какую потерю данных проект способен выдержать. Для сайта, который принимает заявки, обсудите отдельно хранение обращений и действия при сбое. Если формы собирают сведения о людях, до запуска согласуйте состав полей и порядок работы с данными с юристом под задачи проекта.
Как проверить сайт перед запуском и принять работу
Приёмка по принципу «вроде работает» пропускает ошибки на пути посетителя. Пройдите сценарии, которые согласовали до разработки, и запишите результат каждого. Проверяйте не только успешное действие, но и сбой: неверно заполненную форму, недоступную CRM, отказ при оплате. Так команда увидит, что происходит с данными и какое сообщение получает человек.
| Сценарий | Ожидаемый результат | Проверка ошибки | Статус исправления |
|---|---|---|---|
| Отправка заявки | Заявка поступает по согласованному маршруту, посетитель видит подтверждение | Пустые поля, повторная отправка | Исправлено или ожидает повторной проверки |
| Каталог и фильтры | Товары и цены совпадают с источником данных | Пустой результат фильтра | Исправлено или ожидает повторной проверки |
| Регистрация и роли | Каждая роль видит свои разделы | Попытка открыть чужой раздел | Исправлено или ожидает повторной проверки |
| Оплата, если она есть | Статус заказа соответствует результату платежа | Отказ банка, сбой сервиса | Исправлено или ожидает повторной проверки |
| Сбой внешней системы | Сайт ведёт себя по согласованному сценарию | CRM недоступна | Исправлено или ожидает повторной проверки |
Проверьте отображение на устройствах, которые важны вашей аудитории, и восстановление из резервной копии. У каждого дефекта должен быть ответственный; после исправления повторите проверку.
Тестирование не обещает отсутствия будущих ошибок. Оно помогает не выпускать сайт со сломанными основными сценариями.
Что проверить после запуска
После запуска проверьте рабочие сценарии уже на основном адресе. Отправьте тестовую заявку, откройте важные страницы и убедитесь, что у команды есть доступ к сообщениям об ошибках. Затем переходите к поисковой доступности и скорости: исправная форма ещё не означает, что поисковая система видит нужный текст, а быстрая главная страница ничего не говорит о каталоге.
Справка Яндекс Вебмастера указывает, что с помощью Sitemap можно сообщить Яндексу об актуальной структуре сайта. Проверьте файл Sitemap и статус важных страниц в Вебмастере. Если основной текст создаётся JavaScript, отдельно посмотрите, что доступно без выполнения скриптов. У каталога проверьте адреса, которые образуются при использовании фильтров.
Скорость оценивайте отдельно от индексации. Документация web.dev о Web Vitals описывает LCP, INP и CLS как метрики загрузки, отклика и визуальной стабильности. Выберите страницы для проверки и сравнивайте их после изменений, а не судите обо всём сайте по одному экрану.
Закрепите ответственных за обновления, ошибки, копии и повторную проверку форм. Если сценарии ещё только предстоит реализовать, передайте их на оценку разработки сайта под задачи и интеграции.
Частые вопросы
Ниже — вопросы, которые полезно решить до выбора платформы и передачи сайта в работу. Они касаются возможности начать с простой версии, контроля над размещением и безопасной проверки изменений. Ответы помогут определить границы проекта, но не заменят описания ваших сценариев: именно по ним исполнитель должен оценивать разработку и сдавать результат.
Можно ли начать со статического сайта и добавить динамику позже?
Да, можно начать со статического сайта и добавить динамические функции позже. Для каталога или личного кабинета потребуется отдельно описать данные, права доступа и сценарии. Если такое расширение уже запланировано, обсудите его до выбора основы сайта.
На чьё имя оформлять домен и хостинг?
Заказчику стоит сохранить контроль над доменом и хостингом. Исполнителю можно выдать доступы, необходимые для работы. Это упростит передачу сайта другому подрядчику.
Нужен ли отдельный тестовый сервер?
Нужна среда, где можно проверить изменения и восстановление копии, не затрагивая рабочий сайт. Для небольшого проекта такой средой может быть закрытая копия на том же хостинге, если она отделена от рабочего сайта.
Источники
Ссылки ниже ведут к документации по двум проверкам после запуска: передаче структуры сайта Яндексу и оценке пользовательского восприятия страниц. Они не служат основанием для оценки стоимости проекта или выбора CMS.
