Как выбрать CMS для сайта-каталога: WordPress, headless или своя админ-панель?
Когда владелец сайта просит «добавить каталог», я сначала уточняю, кто и как часто будет менять его содержимое. Если разработчик раз в год меняет пару абзацев, полноценная CMS может стоить дороже, чем принесёт пользы. Если сотрудник каждую неделю обновляет услуги, модели техники, характеристики и фотографии, ручные правки сайта быстро становятся узким местом.
В кейсе Jet Service на публичном сайте отдельно представлены услуги, воздушные суда, предложения о продаже и запчасти. Для такого содержания важны не только страницы, но и способ, которым команда обновляет карточки. Кейс Jet Service описывает каталоги и собственную систему управления. Ниже я отделяю подтверждённые особенности проекта от рекомендаций, которые подходят похожим каталогам.
Когда CMS помогает
Обычный сайт из нескольких страниц может жить без отдельной админ-панели. Если тексты меняются редко, а правки всё равно проверяет разработчик, CMS добавляет входы, роли, резервные копии, обновления и ещё одно место, которое надо обслуживать. В этом случае хватит конструктора или статической страницы.
CMS начинает окупаться, когда сотрудники сами и регулярно:
- добавляют и снимают с публикации услуги, товары или объявления;
- правят характеристики в карточках;
- загружают фотографии и документы;
- связывают одну запись с несколькими разделами;
- готовят публикации, которые кто-то должен проверить;
- меняют заголовки и описания индексируемых страниц.
Сначала посчитайте не страницы, а типы данных и действия сотрудников. «Услуга», «модель самолёта», «объявление о продаже» и «запчасть» похожи только тем, что у каждого есть название и картинка. У услуги нужны условия и описание работ. У модели могут быть характеристики и совместимые услуги. У объявления важны состояние предложения и срок его актуальности. У запчасти бывают каталожный номер и совместимость. Если хранить всё в одной универсальной форме с десятками необязательных полей, сотрудники будут путаться, а ошибки станут обычным делом.
CMS не решит задачу, если бизнес-процесс пока не описан. Она не угадает, кому разрешено публиковать, что показывать при отсутствии цены и куда вести устаревшую карточку. Эти правила нужно согласовать до выбора инструмента.
Три варианта и цена сопровождения
Стоимость ниже указана относительно: она зависит от того, кто будет обслуживать сайт, сколько интеграций потребуется и где размещён сервис. Сравнение относится к разработке и сопровождению, а не к фиксированному прайс-листу.
| Подход | Когда подходит | Сопровождение |
|---|---|---|
| WordPress | Страницы, новости и простой каталог | Низкое или среднее; зависит от числа плагинов |
| Strapi / Directus | Отдельный frontend, API и связанные данные | Среднее: CMS и сайт поддерживают отдельно |
| Своя панель | Готовая модель не покрывает процесс | Высокое: вы отвечаете за редактор, права и файлы |
WordPress
WordPress уже даёт редактор страниц и записей, медиабиблиотеку, черновики и роли. Для стандартных записей и страниц WordPress хранит историю изменений. Для собственного типа записи поддержка revisions зависит от параметра supports: её включают при регистрации типа. Это описано в документации register_post_type. Тип каталога можно оформить отдельным типом записи и набором полей. В документации WordPress отдельно описаны собственные типы записей, их возможности и права ролей.
Это разумный выбор, если основу сайта составляют тексты, публикации и несложный каталог, а команда умеет безопасно обновлять WordPress и его расширения. Начальная стоимость обычно ниже, чем у индивидуальной панели: разработчик собирает известные части системы вместо создания редактора с нуля.
Расходы растут, когда в каталог добавляют много плагинов с пересекающимися обязанностями, сложные связи или нестандартную форму. Тогда надо следить за совместимостью, обновлениями и тем, какие роли получили доступ. Сам факт использования WordPress не делает сайт ни безопасным, ни небезопасным: важны настройки, обновления и качество установленных расширений.
Headless CMS
В headless CMS редактор управляет данными в отдельной системе, а публичный сайт получает их через API. Strapi и Directus позволяют описывать типы данных, связи между ними и права доступа. Strapi документирует черновики и публикацию, настройку предпросмотра и поля связей. Directus описывает коллекции, разрешения и версии содержимого.
Такой вариант подходит, если у проекта отдельный frontend на React, Next.js или другом фреймворке, а контент нужно отдавать сайту или ещё одному приложению. Но «headless» не означает «админка появится без настройки». Нужно создать модель, формы редактирования, права, способ загрузки файлов, предварительный просмотр и процесс публикации. При самостоятельном размещении добавятся обновления базы, резервное копирование и обслуживание сервера. Для облачного тарифа расходы зависят от текущих условий конкретного поставщика; лицензии и лимиты стоит проверять перед стартом.
Я бы выбрал headless CMS, когда редакторские функции типовые, но публичный сайт и его интерфейс нужно проектировать отдельно. Если администраторы вынуждены постоянно обращаться к разработчику, потому что форма неудобна, наличие API ничего не исправит.
Собственная админ-панель
Свою панель стоит строить, когда важен конкретный рабочий процесс: например, заявка на добавление запчасти должна проходить проверку специалистом, а потом публиковаться вместе со связанными моделями воздушных судов. Здесь можно сделать интерфейс под реальные действия сотрудников и связать его с уже существующей серверной частью.
За эту свободу платят дважды: сначала разработкой, затем сопровождением. Команда сама должна обеспечить права доступа, загрузку и замену файлов, черновики, восстановление удалённых записей, историю изменений, резервное копирование и безопасные обновления. Если у бизнеса нет бюджета на дальнейшие изменения и поддержку, собственная панель превращается в приложение, которое страшно трогать.
Мой ориентир простой: готовую CMS надо выбирать по совпадению с работой редактора, а не по списку функций на главной странице. Собственную систему имеет смысл делать после того, как команда назвала конкретные обходные пути готовых инструментов и оценила их цену.
Что проверить в административной панели
Редактирование в контексте
Редактор должен открыть раздел «Запчасти», найти запись и сразу увидеть поля, нужные именно ей. Не заставляйте сотрудника искать одну характеристику в общей медиатеке или в настройках страницы. Названия полей должны совпадать с языком команды.
Изображение рядом с карточкой
Медиабиблиотека полезна для повторного использования файлов, но сама по себе не решает загрузку. В форме карточки нужны кнопки «загрузить» и «заменить», понятная выбранная фотография, текстовое описание для доступности и правило, что происходит с изображением после удаления карточки. Для каталога полезно видеть, где файл уже используется, чтобы случайно не удалить нужную фотографию.
Черновик и предпросмотр
Предпросмотр должен открывать конкретную карточку в состоянии черновика. Проверьте, что черновик не становится доступен поисковику и обычным посетителям по постоянному URL. Если редактор заменил изображение, он должен увидеть именно новую версию до публикации.
Права без лишнего доступа
Редактору часто достаточно создавать и менять черновики. Публикацию можно оставить ответственному сотруднику, а управление пользователями и структурой данных оставляют администратору. Назначайте права на действия и типы карточек, а не раздавайте всем роль «полный доступ».
SEO-поля как часть карточки
Для индексируемой страницы нужны человекочитаемый адрес, заголовок и описание, а также понятное поведение при снятии с публикации. При удалении не обязательно навсегда отдавать посетителю ошибку: иногда правильнее сохранить перенаправление на категорию или аналогичную запись. Проверьте, какие URL попадают в sitemap и имеют canonical. Google рекомендует размечать страницу статьи данными автора и дат, если они подходят содержимому, но структурированная разметка сама по себе не обещает расширенный результат поиска.
Связи и история изменений
Связанные записи лучше хранить как связи в модели данных, а не копировать названия в текстовое поле. Тогда изменение модели не требует править несколько карточек вручную. История нужна, если компания должна понимать, кто изменил цену или техническую характеристику, либо быстро вернуть прошлое значение. Если таких требований нет, проверьте хотя бы архивное удаление, резервную копию и понятное восстановление.
Jet Service: что видно в проекте
На публичном сайте Jet Service есть отдельные разделы услуг, воздушных судов, запчастей и предложений о продаже. В портфолио-кейсе также подтверждены страницы статей и вопросов, формы обращений, карточки запчастей с характеристиками, управление контентом и базовые настройки метаданных. Исходный код системы Jet Service в репозитории lend не хранится, поэтому по этим материалам нельзя подтвердить конкретные названия таблиц, все связи или устройство загрузчика изображений.
Отсюда два разных вывода:
- Что подтверждено: каталог разделён по назначению; в кейсе заявлено управление карточками, медиа, порядком и публикацией.
- Рекомендация для похожей модели: услугу можно связать с подходящими моделями. Деталь стоит связать с совместимыми моделями отдельной записью. Объявление о продаже лучше хранить отдельно от постоянной карточки модели, чтобы закрытая продажа не удаляла саму модель.
Например, карточка услуги может содержать обязательные поля и ссылки на связанные записи:
type: service
slug: diagnostics
title: "Диагностика воздушного судна"
summary: Описание услуги
aircraftModelIds:
- model-1
- model-2
image:
url: /media/diagnostics.webp
alt: >-
Осмотр воздушного судна
в ангаре
status: draft
seo:
title: "Диагностика воздушного судна"
description: "Описание и условия услуги"
Это схема для обсуждения, а не выгрузка из Jet Service. В реальной базе вместо копирования URL обычно хранят идентификатор файла, а связи модели и услуги задают средствами CMS или отдельной таблицей.
У каталога есть прямая связь с поисковой индексацией: опубликованная запись создаёт публичную страницу со стабильным адресом, а черновик не должен появляться в sitemap. При снятии с публикации нужно решить, остаётся ли страница доступной, куда перенаправляется старый URL и сохраняются ли внутренние ссылки. Эти правила проверяют до передачи каталога, а не после жалобы на пропавшую страницу.
Минимальная матрица прав
| Действие | Редактор | Публикует | Админ |
|---|---|---|---|
| Черновик | Да | Да | Да |
| Фото | Да | Да | Да |
| Публикация | Нет | Да | Да |
| Удаление | Нет | Нет | Да |
| Роли | Нет | Нет | Да |
«Публикует» означает ответственного за выпуск карточки. «Админ» означает администратора. Это стартовый вариант. Если у сотрудников разные обязанности, ограничьте им доступ к разделам и полям. Проверяйте матрицу под отдельными учётными записями: скрытая кнопка не заменяет проверку прав на сервере.
Чек-лист до начала разработки
- Кто будет добавлять и редактировать записи?
- Какие типы карточек нужны сейчас, а какие могут появиться позже?
- Какие поля обязательны для каждого типа?
- Какие сведения должны быть доступны только сотрудникам?
- Какие записи связываются между собой?
- Может ли одна модель иметь несколько услуг или совместимых деталей?
- Кто создаёт, а кто публикует материал?
- Нужен ли предпросмотр черновика на реальном шаблоне сайта?
- Кто может загружать и удалять файлы?
- Как редактор найдёт фотографию, уже прикреплённую к карточке?
- Нужны ли SEO-заголовок, описание, slug и текст альтернативы изображения?
- Что должен увидеть посетитель после снятия страницы с публикации?
- Нужно ли восстанавливать удалённые карточки?
- Как часто и кем делаются резервные копии?
- Нужен ли журнал изменений и как долго хранить его?
- Какие изменения сотрудник должен уметь сделать без помощи разработчика?
- Кто отвечает за обновление CMS, хостинг и устранение ошибок?
- Какие страницы каталога должны попасть в sitemap и как проверять это после публикации?
Приёмка админки на реальных действиях
Попросите исполнителя показать эти сценарии на тестовых данных:
- Редактор создаёт услугу, сохраняет черновик и не видит её на публичном сайте.
- Ответственный открывает предпросмотр, находит ошибку, возвращает карточку редактору.
- Редактор загружает новое фото и заменяет старое, не перепутав карточку.
- Администратор связывает услугу с двумя моделями и видит эти связи при повторном открытии записи.
- Редактор пробует опубликовать запись без обязательного поля и получает понятное сообщение.
- Ответственный меняет SEO-заголовок, публикует запись и проверяет публичный URL, метаданные и sitemap.
- Администратор архивирует карточку, восстанавливает её и убеждается, что связанные материалы остались целы.
Если все эти действия проходят без доступа разработчика к базе данных, CMS уже решает практическую задачу. Если нет, попросите добавить конкретный недостающий шаг в оценку работ. Для каталога услуг или техники можно обсудить модель на примере Jet Service.