Многие компании, заказывая корпоративный сайт, добавляют: «И админку тоже сделайте». Звучит как мелочь, но на практике часто превращается в конфликт двух наборов требований.
Сайт должен быть красивым, быстрым и индексироваться поисковиками; админ-панель — позволять редактировать контент, смотреть данные и разграничивать права. Оба используют одну модель данных, но обслуживают совершенно разных пользователей. Если планирование хромает, типичный результат такой: сайт выходит первым, в админке меняют одно поле — и весь фронтенд ломается; либо админку доделали, а на сайте обнаружили, что структура контента вообще не совпадает.
В этой статье в порядке реального проекта разбирается планирование разработки сайта с корпоративным сайтом и админ-панелью.
Сначала разделите две линии: логику отображения и логику редактирования
Сайт — это логика отображения, админка — логика редактирования. Эти две линии проектируются отдельно, но используют одну модель данных.
Практический подход: сначала определить модель контента, потом страницы. Например, типичные разделы корпоративного сайта: новости, продукты, кейсы, вакансии. Какие поля в каждом разделе, какие обязательные, какой размер изображений, поддерживается ли мультиязычность — всё это нужно определить до отрисовки страниц.
Подводный камень: не привязывайте админку напрямую к модулям страниц. Во многих проектах админку делают в виде «текст первого экрана главной», «изображение второго экрана главной» — и после редизайна сайта вся админка становится бесполезной. Правильный подход: админка управляет контентом, страница отвечает за представление, а связь между ними — через маппинг полей.
Ещё один камень — права доступа. В админке должно быть как минимум три роли: администратор, редактор, только чтение. В проектах корпоративных сайтов это часто упускают, и только после запуска выясняется, что стажёр может удалять данные.
В сроках уровень данных админки должен быть готов раньше сайта
Надёжный порядок: модель данных → API админки → интерфейс админки → страницы сайта.
Страницы сайта зависят от реальных данных. Если админка ещё не работает, фронтенд вынужден использовать фейковые данные, и на этапе интеграции проблемы посыпятся разом. Сначала дайте админке возможность вводить, изменять и возвращать корректную структуру, потом подключайте сайт — объём переделок будет значительно меньше.
Конкретный пример: компания по аренде оборудования. На сайте нужно показывать список оборудования и онлайн-бронирование, в админке — управлять информацией об оборудовании, записями бронирований и сменой статусов. Если сначала делать сайт, поля формы бронирования и структура записей в админке легко разойдутся: например, сайт принимает «желаемый срок аренды», а админка хранит только «дату начала». Такие проблемы обнаруживаются на интеграции, и для исправления нужно менять базу данных.
Поэтому закладывайте в сроки для админки минимум треть времени как опережающий этап — не относитесь к ней как к приложению к сайту.
Договоритесь об API заранее, не откладывайте до готовности страниц
Сайт и админка связаны через API. Имена полей, типы, пагинацию, коды ошибок лучше зафиксировать в простом документе до начала разработки.
Не нужно ничего формального — достаточно одной таблицы: путь эндпоинта, входные параметры, пример ответа, исключительные ситуации. Этот документ сэкономит массу устных переговоров.
Подводный камень: загрузка изображений. И сайт, и админка работают с изображениями, но требования разные. Сайту нужны сжатие, CDN, ленивая загрузка; админке — оригиналы, обрезка, сортировка. Логику загрузки лучше унифицировать в одном сервисе, а не писать две реализации.
Ещё поиск и фильтрация. Условия фильтрации в админке обычно сложнее, чем на сайте. Если при проектировании API учитывать только сайт, для админки придётся делать отдельный набор запросов. Заранее спроектируйте параметры фильтрации как комбинируемые — это сэкономит время в будущем.
Безопасность и вход администратора нужно продумать отдельно
Админка — самая большая поверхность атаки. Шаг, который часто пропускают в разработке сайтов, — тестирование безопасности админки.
Минимум, что нужно сделать: капча и ограничение неудачных попыток входа в админку; обязательная сложность пароля администратора; проверка прав на уровне API, а не только скрытие меню на фронтенде; журналирование действий.
Если это проект разработки мини-программ или разработки приложений, админке часто приходится обслуживать несколько клиентов, и модель прав становится сложнее. В этом случае рекомендуется разделить админку на «управление контентом» и «управление бизнесом»: первое — для операторов, второе — для бизнес-пользователей, чтобы снизить риск ошибок.
Подводный камень: не используйте одну систему аккаунтов сайта для управления админкой. Пользователи фронтенда и администраторы должны быть в разных таблицах с разной логикой входа.
Критерии приёмки пишите заранее, а не перед запуском
Приёмка сайта: скорость загрузки, адаптивность под мобильные, базовые SEO-параметры (заголовок, описание, структурированные данные). Приёмка админки: три вещи — можно ли полностью ввести данные, корректно ли они отображаются на сайте, правильны ли права.
Рекомендуется составить чек-лист приёмки, где каждый пункт соответствует конкретному проверочному действию. Например: «Добавить новость — она появляется в списке на сайте в течение 1 минуты», «Роль редактора не может удалять данные», «После загрузки изображения на сайте оно отображается размером не более 300 КБ».
Согласовать чек-лист с разработчиками в начале проекта гораздо эффективнее, чем выдвигать требования накануне запуска.
В каких случаях стоит обратиться в MIC Studio
Если в команде нет выделенного бэкенд-разработчика или сайт и админку нужно сдать к одной дате, разумно отдать часть работ на аутсорс. MIC Studio при комплексной разработке корпоративного сайта и админ-панели обычно сначала помогает клиенту проработать модель контента и договорённости по API, а затем переходит к разработке.
Когда стоит к нам обращаться: сайт требует редизайна одновременно с рефакторингом админки; сайты с бизнес-процессами вроде бронирования и записи; проекты, где админка должна обслуживать мини-программу или приложение. Если нужно просто поправить несколько строк текста, полный проектный процесс не нужен.
Три практические рекомендации
Первое: до начала работ напишите одностраничную модель контента — определите разделы, поля, обязательные элементы, и пусть и сайт, и админка следуют ей.
Второе: в сроках сначала запустите уровень данных админки, затем подключайте сайт к реальному API — это уменьшит переделки на интеграции.
Третье: перед запуском проведите проверку безопасности админки и тестирование прав — не ждите инцидента, чтобы что-то исправлять.