# Типы записей и поля: как организовать услуги, кейсы и справочники

Источник: https://quicklanding.ru/knowledge/wordpress-content-model/

Как устроить услуги, проекты и справочники в WordPress, чтобы редактор менял данные без копирования одинаковых блоков.

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

## Отделите сущность от её оформления

![Клавиатура ноутбука в цветном освещении](/assets/images/knowledge/wordpress-content-model.webp)

Услуга, проект и статья отличаются по назначению. У проекта есть задача, роль команды и изображения. У услуги состав работ и условия обращения. Общий красивый макет не означает, что им достаточно одного набора полей.

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

## Выберите поля, по которым сайт работает

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

| Сведения | Подход к хранению |
| --- | --- |
| Описание процесса | Редактируемый текст или блоки |
| Отрасль проекта | Согласованный справочник |
| Связанные услуги | Связь с выбранными записями |
| Обложка | Изображение с понятным назначением |
| Частые вопросы | Отдельные пары вопроса и ответа |

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

## Предусмотрите повторное использование

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

Связь проекта с услугой позволяет показать реальный пример без ручного копирования карточки. Редактор выбирает запись, а шаблон выводит её актуальное название и обложку. Если запись скрыта или удалена, публичный блок должен учитывать её состояние.

## Решите, где регистрируются типы записей

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

Это не значит, что данные автоматически удалены. Но сотрудник может перестать видеть нужный раздел и воспринимать ситуацию как потерю материалов. Место регистрации и способ отображения стоит описать в передаче проекта.

## Подготовьте понятную админку

Название поля должно объяснять действие, а не внутренний термин разработчика. Рядом с ценой уточните формат, возле изображения рекомендуемое назначение, у связи способ выбора. Обязательность вводите только там, где без данных публикация действительно некорректна.

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

## Согласуйте расширение заранее

Новые отрасли, дополнительные характеристики и смена шаблона должны иметь понятный путь. Не обещайте бесконечную гибкость без границ. Лучше определить, какие поля сотрудник добавляет самостоятельно, а какие изменения требуют разработки и проверки старых записей.

В QuickLanding можем спроектировать модель услуг, проектов и справочников, затем собрать шаблоны и редактор. Для оценки полезны несколько заполненных примеров и будущие способы отбора. Они покажут, какие сведения нужно структурировать, а какие оставить в свободном тексте.

## Документация и проверка сведений

Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.

- [WordPress: регистрация типов записей](https://developer.wordpress.org/plugins/post-types/registering-custom-post-types/)
- [WordPress: редактор сайта](https://wordpress.org/documentation/article/site-editor/)

## Материалы по соседним задачам

- [Техническое задание на сайт: как описать результат без лишней документации](/knowledge/website-specification/)
- [Блочный редактор или конструктор: как выбирать под задачи команды](/knowledge/wordpress-editor-choice/)
- [Разработка расширений WordPress](/services/development/extensions/wordpress/)

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

### Можно оставить всё обычными страницами?

Да, если объём и связи позволяют удобно работать. Собственные типы записей полезны при самостоятельных сущностях, фильтрах и повторяющихся полях. Их выбирают по процессу редактора, а не ради сложности.

### Нужно ли каждому полю отдельное расширение?

Нет. Важно выбрать согласованный способ хранения и редактирования. Количество плагинов не должно расти вместе с каждым новым параметром. Совместимость и поддержка относятся к архитектуре проекта.

### Что делать с уже заполненными страницами?

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

Автор: Владимир Николаев