Наш сайт собран не на конструкторе блоков и не на голой теме, а на связке WordPress и плагина дополнительных полей ACF PRO: контент разложен по типам записей, а вёрстку задают шаблоны. Показываем эту изнанку и разбираем, что она даёт бизнесу и чем за неё приходится платить.
Вопрос "как устроен ваш собственный сайт" нам задают чаще, чем можно было ожидать. Заказчик листает портфолио, видит на десятках страниц похожую по духу, но разную по содержанию вёрстку, и хочет понять, где здесь редактор собирает блоки сам, а где работает готовый шаблон. Ответ проще, чем кажется, но в нём спрятана экономика: сколько будет стоить обычное "просто добавьте раздел" через год после сдачи.
Поля плюс шаблон - в чём разница с конструктором
В конструкторе блоков (Tilda, конструктор Битрикс24 и похожие) страница - набор произвольных секций, которые редактор перетаскивает и настраивает сам. В визуальном редакторе WordPress без дополнительных полей текст и картинки просто набирают в теле записи и форматируют руками. Наш подход третий: у типа контента заранее описана структура - какие поля есть, какого они типа, что обязательно. Редактор видит форму с подписанными полями: заголовок кейса, три цифры результата, галерея, отзыв клиента. Вёрстку из этих полей собирает шаблон, который написали мы: редактор в неё уже не вмешивается.
Разница ощущается сразу, если сравнить редактирование одной и той же страницы кейса в трёх системах. В конструкторе можно случайно сдвинуть блок и сломать сетку. В голом редакторе - забыть закрыть тег и утащить форматирование на соседний абзац. В форме с полями сломать нечего: поле для цифры результата примет только число, а поле для фото до и после - только два изображения.
Что получает бизнес от такой конструкции
Одинаковая вёрстка на всех страницах одного типа. Сотая статья блога выглядит так же аккуратно, как первая, потому что оформление живёт в шаблоне, а не переносится копированием чужого блока с ошибками.
Чистая разметка и скорость страницы. Из формы в HTML попадает ровно то, что нужно, без лишних оберток и инлайн-стилей, которые конструкторы добавляют на каждый блок. Меньше кода - быстрее рендер.
Практически невозможно случайно сломать вёрстку. Редактор не может вставить картинку не того формата туда, где её быть не должно, или удалить структурный элемент вместе с текстом. Максимум, что он испортит, - собственные формулировки в своих полях.
Предсказуемая структурированная разметка для поиска. Раз у кейса всегда есть поле "цифра результата" и поле "период", тема может автоматически завернуть их в микроразметку по правилам Google Search Central без ручной работы над каждой страницей. У конструктора со свободной вёрсткой так стабильно не выходит: структура каждый раз собирается заново, и разметку либо чинят руками, либо не делают вовсе.
Чем за это приходится платить
Каждое новое поле - это работа разработчика. Понадобилось завтра показывать у кейса ещё и видеоотзыв - кто-то должен добавить поле в группу и научить шаблон его выводить. В конструкторе то же самое заказчик делает сам за десять минут, просто перетащив готовый блок.
Собрать нестандартную страницу самостоятельно нельзя. Форма с полями рассчитана на типовой сценарий: ещё одна статья, ещё один кейс, ещё один термин глоссария. Разовая посадочная страница с уникальной структурой под конкретную рекламную кампанию в эту логику не укладывается - её либо верстают отдельно, либо подгоняют под ближайший шаблон.
Зависимость от платного плагина. ACF PRO - не бесплатное расширение, лицензия продлевается ежегодно, и без неё повторяющиеся блоки полей и страницы настроек перестанут редактироваться. Похожий компромисс между удобством и чужим кодом мы разбирали в статье про плагины WordPress: часть функциональности сайта всегда живёт на чужой поддержке.
Как это устроено у нас на практике
У нас шесть своих типов записей: статьи блога, кейсы, отрасли, сравнения систем, термины глоссария и новости. Ещё два справочника-таксономии: рубрика блога и группа терминов глоссария. У каждого типа своя группа полей: у кейса - цифры результата и стек технологий, у сравнения - две колонки характеристик и таблица совокупной стоимости.
Лендинги устроены иначе: это шаблоны страниц с собственным набором полей под конкретный сценарий, например страница услуги с блоками цен, этапов и вопросов-ответов. Какие блоки в неё входят, разбирали в руководстве как разработать корпоративный сайт. Витрины разделов - хабы блога, кейсов, отраслей - отдельные шаблоны архивов плюс общая страница настроек, где задаются заголовок хаба, вводный текст и порядок вывода карточек. Меняется дизайн хаба - меняется один файл шаблона, а не сотня записей внутри него.
Как спроектировать поля, чтобы не переделывать всё через полгода
Прежде чем заводить первое поле, стоит развернуть контент на бумаге: какие типы страниц реально будут, что у них общего и чем они принципиально различаются. Дальше три практических правила.
Группы полей - по типу записи, а не по странице. Если поле нужно и кейсу, и отрасли, оно описывается дважды в двух группах: экономия на общей группе почти всегда через несколько месяцев упирается в то, что смыслы у поля начали расходиться.
Повторяющиеся блоки - для всего, что может стать длиннее. Список этапов работы, галерея, вопросы и ответы - если сегодня их три, а завтра может понадобиться семь, сразу закладывают повторитель, а не поля "этап 1", "этап 2", "этап 3".
Значения по умолчанию - там, где редактор скорее всего оставит поле пустым: если у большинства кейсов один призыв к действию, разумнее зашить его в шаблон, а не требовать заполнять одно и то же поле заново.
Типовые ошибки при проектировании полей
Самая частая - завести сто полей на всякий случай, потому что "может пригодиться". Формы становятся длинными, редактор путается, где заполнять реальный контент, а незанятые поля просто раздувают базу без пользы.
Вторая - спрятать в текстовое поле кусок готовой HTML-вёрстки вместо нормальной структуры. Временное решение почти никогда не остаётся временным: через год такое поле редактирует уже не тот, кто его придумал, и разбирается в чужой разметке вслепую.
Третья - дублировать в отдельных полях то, что уже есть в теле записи, например завести поле "краткое описание", когда первый абзац тела и так можно вытащить программно. Лишнее поле - лишнее место, где текст может разойтись с тем, что реально написано в статье.
Как выглядит работа редактора в такой теме
Открывает запись нужного типа и видит форму с подписанными разделами вместо чистого листа. Заполняет заголовок, лид, основной текст, а затем поля своего типа: у кейса - цифры результата и отзыв, у термина глоссария - определение и связанные термины. Часть полей обязательна и подсвечивается, если пуста, часть опциональна и просто не выводится в вёрстку, если её не заполнили. Сохранить и посмотреть результат можно сразу через предпросмотр, не боясь, что где-то съехала сетка: сетку задаёт шаблон, а не редактор.
Порог входа для нового человека в команде тоже не пять минут, но и не сравним с изучением вёрстки: разобраться в полях обычно занимает один рабочий день, если перед глазами есть уже заполненные примеры.
Кому подходит конструктор, а кому индивидуальная тема
Индивидуальная тема на полях окупается там, где контента много и он однотипный: десятки статей блога, каталог кейсов, отраслевые страницы, растущий глоссарий. Чем больше похожих записей, тем заметнее выигрыш от того, что вёрстку не собирают заново каждый раз.
Для витрины из трёх-пяти страниц, которая почти не меняется после запуска, это избыточное вложение. Здесь честнее посмотреть в сторону готовой темы или конструктора: сравнение платформ 2026 года - в материале про конструкторы сайтов, а более широкий взгляд на выбор системы - в обзоре сравнения CMS. Граница простая: если через год на сайте будет заметно больше страниц, чем сейчас, поля и шаблоны обычно окупаются. Если структура фиксирована и меняться не планирует, переплачивать за архитектуру незачем.
Где заканчивается гибкость и начинается порядок
Поля и шаблоны - это обмен свободы редактирования на предсказуемость результата. Заказчик не может собрать произвольную страницу сам, зато не может и случайно сломать существующую: у обеих сторон компромисса есть цена, и она ложится либо на бюджет разработки, либо на риск кривой вёрстки в проде. Мы выбрали первый вариант, потому что контент у нас растёт годами и однотипных страниц становится больше, а не меньше.
Если предстоит выбор между конструктором, готовой темой и индивидуальной разработкой под свой проект, дешевле сначала прикинуть порядок цифр, чем спорить о подходах абстрактно - в калькуляторе стоимости можно быстро оценить вилку под конкретную задачу.
