Сайт национального театра с админкой: что было под капотом

Это кейс от первого лица. Меня зовут Чимитдоржи Дарижапов, и в этом материале я разбираю, как делал сайт с собственной админкой для национального театра. Театр здесь я называю нейтрально — «национальный театр», без конкретного имени, потому что суть кейса не в названии, а в подходе: как устроить сайт учреждения культуры так, чтобы он не устаревал на второй неделе после сдачи и не требовал разработчика при каждой правке афиши.

У сайтов учреждений есть общая болезнь. Их запускают красиво, а через месяц афиша на главной показывает спектакли прошлого сезона, в разделе труппы висит актёр, который уже не работает, а новостей нет с открытия. Причина почти всегда одна: обновлять контент технически неудобно, и это ложится на человека, которому некогда. Я поставил себе цель сделать так, чтобы этой болезни не случилось.

Задача

Заказчик — национальный театр, учреждение культуры. Запрос звучал по-человечески просто: нужен сайт, на котором афиша, спектакли, труппа и новости всегда актуальны, и который редакция театра обновляет сама, без обращения к разработчику по каждому поводу.

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

Во-вторых, работать с этой панелью будут не технические специалисты, а сотрудники редакции театра. Для них админка должна быть такой же понятной, как заполнение анкеты: поля подписаны, ничего лишнего, невозможно случайно «сломать» сайт. Если редактору неудобно, он перестанет обновлять контент — и сайт снова устареет.

В-третьих, это сайт учреждения. К нему есть свои требования: он должен быть доступным и корректно открываться на разных устройствах, информация — актуальной, а страницы — быстрыми и находимыми в поиске, потому что зритель ищет афишу и адрес именно через поисковик. Всё это я закладывал в основу, а не приделывал в конце.

Что я сделал

Я сделал сайт вместе с собственной админкой. Не отдельный конструктор и не набор HTML-страниц, которые нужно править руками, а связку: публичный сайт, который видят зрители, и панель управления, в которую заходит редакция театра.

Логика такая. Редактор открывает админку в браузере, видит понятные разделы — афиша, спектакли, труппа, новости — и работает в них как в обычном кабинете. Добавить спектакль в афишу, поставить дату показа, загрузить фотографию сцены, опубликовать новость об открытии сезона — всё это делается через формы, без единой строчки кода. Как только редактор сохраняет изменения, они появляются на сайте.

Публичную часть я собрал так, чтобы она была быстрой и хорошо индексировалась поиском: зритель заходит на страницу афиши и сразу видит актуальные показы по датам, переходит на карточку спектакля, читает описание, видит занятых актёров и может перейти в раздел труппы. Все разделы связаны между собой, поэтому навигация ощущается цельной, а не как набор разрозненных страниц.

Отдельно я продумал разделы. Афиша — это ближайшие показы, выстроенные по датам. Спектакли — репертуар с описаниями и фотографиями. Труппа — актёры театра с фото и информацией. Новости — лента событий театра. Каждый из этих разделов редакция ведёт самостоятельно.

Проект я делал один: от проектирования структуры данных и настройки админки до вёрстки публичной части и запуска. Это дало цельность — вся система продумана как единое целое, без стыков между «фронтендом от одних и бэкендом от других».

Стек и админка

Расскажу про технологии простыми словами — почему именно эти инструменты, а не другие.

Payload CMS 3 — это система управления контентом, на которой построена админка. Я выбрал её, потому что она позволяет гибко описать именно те сущности, которые нужны театру. У обычных шаблонных конструкторов есть жёсткий набор блоков, и театр в них приходится «впихивать». Здесь наоборот: я сам описываю, что такое спектакль, что такое актёр, что такое запись в афише, какие у них поля и как они связаны. В результате редактор видит в панели не абстрактные «страницы», а понятные ему объекты — спектакль, актёр, показ, новость. Это и есть та самая удобная админка под нужные сущности.

Next.js 16 — это основа публичной части сайта, того, что видит зритель. Я выбрал его по двум причинам: скорость и SEO. Скорость — потому что страницы отдаются быстро, а зритель не любит ждать загрузки афиши. SEO — потому что сайт учреждения должен находиться в поиске: человек ищет «афиша театра» или название спектакля, и страница должна быть в выдаче. Next.js хорошо решает обе задачи и аккуратно работает с адресами страниц, что важно для находимости.

PostgreSQL — это база данных, в которой хранится весь контент: спектакли, актёры, даты показов, тексты новостей, ссылки на фотографии. Я выбрал PostgreSQL, потому что это надёжная, проверенная временем база, которая хорошо справляется со связанными данными. А в театральном сайте данные именно связанные: спектакль ссылается на актёров, показ ссылается на спектакль и дату. PostgreSQL держит эти связи без проблем.

Node.js лежит в основе всего — на нём работают и админка, и сайт. Это позволяет держать проект в одной технологической среде, а не собирать зоопарк из разных языков, который сложно поддерживать.

Если свести всё воедино: Payload CMS 3 отвечает за удобную админку под театральные сущности, Next.js 16 — за быструю и находимую в поиске публичную часть, PostgreSQL — за надёжное хранение связанных данных, Node.js — за общую основу. Вместе это даёт систему, в которой редакция спокойно работает, а сайт остаётся быстрым.

Что было сложно

Самым важным и небанальным оказалось спроектировать структуру данных под театр. На первый взгляд кажется, что спектакли, актёры, афиша и новости — это просто четыре раздела. На деле они переплетены. Спектакль связан с актёрами, которые в нём заняты. Афиша связана со спектаклями и с конкретными датами показов. Один спектакль может идти много раз, и каждый показ — это отдельная запись в расписании, но привязанная к той же карточке спектакля. Если эту структуру спроектировать неаккуратно, редактору придётся дублировать информацию вручную, а данные начнут расходиться.

Я потратил время на то, чтобы эти связи были описаны один раз и работали автоматически. Редактор заводит спектакль один раз, а дальше просто добавляет показы с датами — и афиша собирается сама. Отмечает занятых актёров — и на карточке спектакля появляются ссылки на труппу. Это невидимая для зрителя работа, но именно она делает сайт удобным для редакции.

Вторая сложность — удобство для нетехнической редакции. Одно дело — сделать мощную панель, другое — сделать её понятной человеку, который не программист. Я следил за тем, чтобы поля были подписаны по-человечески, чтобы обязательные вещи нельзя было пропустить, чтобы порядок работы был очевидным. Цель простая: редактор не должен звонить разработчику, чтобы опубликовать новость.

Третья сложность — вывод афиши по датам. Афиша — это не просто список спектаклей, это расписание, которое живёт во времени. Ближайшие показы должны быть наверху, прошедшие — уходить, даты — отображаться корректно. Такую логику нужно продумать и аккуратно реализовать, чтобы редактору достаточно было указать дату показа, а всё остальное сайт делал сам.

Четвёртая — медиа. Театр — это визуальное искусство, и на сайте много фотографий: сцены из спектаклей, портреты актёров, кадры с событий. С медиа всегда есть нюансы: загрузка, хранение, аккуратный вывод на разных экранах. Я закладывал работу с фотографиями так, чтобы редактору было достаточно загрузить снимок через админку, а сайт показывал его корректно.

И пятое — требования к сайту учреждения. Доступность, корректная работа на разных устройствах, актуальность информации — это не «приятные бонусы», а базовые ожидания от сайта организации культуры. Я держал их в основе с самого начала.

Что получилось

Получился сайт, который живёт своей жизнью и не требует разработчика для рутины. Редакция театра ведёт афишу и новости сама: заводит спектакли, ставит показы по датам, обновляет состав труппы, публикует новости. Всё это происходит через понятную админку, без обращения ко мне по каждому поводу.

Для зрителя это значит, что на сайте всегда актуальная информация: какие спектакли идут, когда ближайшие показы, кто занят в труппе, что нового в театре. Для театра это значит независимость: сайт перестал быть «замороженным» после сдачи и стал рабочим инструментом, который редакция держит в тонусе своими руками.

Я сознательно не привожу здесь цифр вроде посещаемости или числа спектаклей — в этом кейсе важнее принцип, чем метрики. Качественный результат в том, что сайт актуален и редакция управляет им самостоятельно. Именно это и было задачей.

Если вам близка идея сайта под ключ с собственной админкой, посмотрите ещё один мой разбор — медиа-портал под ключ: там тоже про сайт с редакцией, только для онлайн-СМИ.

Что бы сделал иначе

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

Второе — я бы с первого дня заложил больше внимания на «защиту от неудобства» в админке: подсказки прямо в полях, предпросмотр того, как запись будет выглядеть на сайте, разумные значения по умолчанию. Чем меньше редактору нужно держать в голове, тем стабильнее он ведёт контент. Каждая мелочь удобства окупается тем, что сайт остаётся актуальным.

Третье — по медиа я бы заранее договорился о едином подходе к фотографиям: форматы, ориентация, аккуратные превью. Это снимает половину визуальных нестыковок ещё до того, как они появятся, и экономит время редакции на каждой загрузке.

Четвёртое — про запуск. На сайте учреждения полезно с самого начала думать о том, кто и как будет поддерживать проект дальше: обновления, резервные копии, обучение новых сотрудников редакции. Техническая часть — это половина дела, вторая половина — чтобы система оставалась живой и понятной людям, которые в ней работают. Про выбор исполнителя, который думает об этом заранее, я подробно писал в материале как выбрать подрядчика.

Частые вопросы

Обязательно ли делать свою админку, а не готовую CMS? Не всегда, но для театра удобно, когда структура данных описывает именно его сущности — спектакли, актёров, показы. Готовые универсальные CMS часто заставляют подгонять контент под чужую логику; здесь логика подстроена под театр.

Кто ведёт афишу после запуска? Редакция театра сама — через админку. Разработчик не нужен для повседневного обновления новостей и афиши.

Подходит ли такой подход другим учреждениям культуры? Да, музею, филармонии, дому культуры нужна похожая структура: события, коллектив, новости. Меняются сущности, подход остаётся.

Коротко о главном

Сайт национального театра — это не витрина, которую сдают и забывают, а живая система, где афиша, спектакли, труппа и новости меняются постоянно. Поэтому ключевое решение — не красивая обложка, а удобная админка, в которой редакция ведёт контент сама.

Я собрал такую систему на понятном и надёжном стеке: Payload CMS 3 для гибкой админки под театральные сущности, Next.js 16 для быстрой и находимой в поиске публичной части, PostgreSQL для надёжного хранения связанных данных, Node.js в основе. Самое ценное спрятано в структуре данных — в том, как связаны спектакли, актёры, показы и афиша, — потому что именно это делает работу редакции простой, а сайт актуальным.

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

Если вам нужен сайт учреждения или организации с удобной админкой, в которой ваша команда сможет вести контент сама, — напишите мне, обсудим вашу задачу.