Сайт медицинской клиники на Drupal CMS: кейс-конструктор — врачи, услуги, филиалы и цены без хаоса

Почему клиника — идеальный профиль для Drupal

Меня зовут Евгений Семёнов, я технический директор ITfresh — мы занимаемся IT-аутсорсингом для московских компаний до пятидесяти рабочих мест и держим собственные серверы в дата-центре МТС. Эта статья — прикладной кейс для верхнего сегмента наших клиентов: как на Drupal CMS собирается сайт многопрофильной медицинской клиники так, чтобы он не превратился в кашу из сотен несвязанных страниц. Сразу оговорюсь: та же самая модель один в один переносится на юридическую фирму и на учебный центр — в конце статьи я покажу, как именно, поэтому читайте, даже если медицина к вам отношения не имеет.

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

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

Проектируем контент-модель до первого клика

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

Главное правило проектирования, которое экономит потом месяцы: если какие-то данные повторяются в двух местах — это не копипаст, а ссылка на отдельную сущность. Врач ведёт приём в двух филиалах? Мы не пишем его карточку дважды — мы связываем одну карточку врача с двумя филиалами. Цена услуги отличается по адресам? Это не пять страниц услуги, а одно поле «цены по филиалам» с несколькими значениями.

Специализации мы выносим не в текстовое поле, а в таксономию — справочник, который редактируется в одном месте. Появилось новое направление, «флебология», — добавили термин в справочник, и он тут же доступен для привязки к врачам и услугам, с автоматической страницей-рубрикой в придачу. Фотографии врачей и обложки статей живут в медиатеке (Media): одну и ту же картинку можно переиспользовать, у неё есть alt-текст для доступности и SEO, а замена файла обновляет его везде, где он показан. Всё это — про то, чтобы данные не дублировались и правились в одной точке.

Как связи превращаются в автоматические страницы

Дальше начинается магия, ради которой всё и затевалось. Механизм Views в Drupal позволяет без единой строки кода собрать динамическую страницу из связанных сущностей. Хотите страницу «все кардиологи, ведущие приём в филиале на Юго-Западной»? Вы не создаёте её руками. Вы описываете правило: «показать всех врачей, у кого специализация = кардиология и филиал = Юго-Западная». Страница собирается сама и обновляется автоматически: пришёл новый кардиолог в этот филиал — он появился в списке без вмешательства человека. Уволился — исчез. Таких страниц-срезов на сайте клиники десятки, и все они живут без ручной поддержки.

Собираем на рецептах Drupal CMS: хронометраж реальной сборки

Здесь произошла главная перемена 2025–2026 годов. Раньше «сделать сайт на Drupal» означало недели ручной настройки базовых вещей: медиатеки, SEO, форм, ролей. Теперь есть дистрибутив Drupal CMS (актуальная версия 2.0 вышла в июне 2026 года на ядре Drupal 11) с механизмом рецептов — Recipes. Рецепт — это готовый набор конфигурации, который одной командой ставит и настраивает целый функциональный блок. Расскажу, как выглядит хронометраж реальной сборки сайта клиники.

• Первый день — базовый сайт из рецептов. Ставим Drupal CMS, применяем рецепты: страницы и новости, SEO-набор (метатеги, карта сайта), продвинутая медиатека, формы, управление согласиями на cookies. К вечеру первого дня есть работающий каркас сайта с админкой, поиском и аналитикой из коробки.
• Второй–третий день — кастомные типы. Создаём типы «Врач», «Услуга», «Филиал» с их полями, настраиваем таксономию специализаций, собираем ключевые Views: списки врачей, каталог услуг, страницы филиалов. Это уже ручная работа, но не программирование — почти всё делается в интерфейсе.
• Дальше — темизация. Вот это самая долгая часть. Натянуть на структуру фирменный дизайн клиники, адаптив, анимации — здесь и уходит основное время проекта.

Сравните это с классической разработкой той же задачи году в 2020-м, когда каждый из этих блоков собирался руками с нуля. Разница — в разы. Именно рецепты и инструменты вроде Project Browser и встроенных AI-помощников по сборке сделали Drupal доступным для проектов, которые раньше уходили на конструкторы просто из-за сроков.

Что именно приезжает в Drupal CMS «из коробки» и почему это экономит недели: продуманная медиатека с автоматическим ресайзом изображений под разные форматы; SEO-набор с метатегами и картой сайта; управление согласиями на cookies, что для сайта с формами и аналитикой обязательно; встроенный поиск; аналитика. Раньше каждый из этих пунктов был отдельной задачей на подбор модуля, установку и настройку. Теперь это один применённый рецепт. Project Browser, в свою очередь, позволяет искать и ставить дополнительные модули прямо из админки, не спускаясь в консоль, — это заметно ускоряет донастройку под конкретную клинику.

Права доступа: регистратура, маркетолог, главврач

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

Ключевой инструмент здесь — Content Moderation, модуль рабочих процессов из ядра. Он выстраивает цепочку состояний: черновик → на проверке → опубликовано. Контент-менеджер готовит акцию и отправляет на проверку, но опубликовать её может только главврач. При этом ведётся журнал ревизий — кто, что и когда менял, с возможностью откатиться к прошлой версии. Это не платная надстройка, а штатная возможность.

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

Цены и расписание из 1С: чтобы сайт не врал

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

Механизм — Migrate API, конвейер импорта Drupal. По расписанию из 1С выгружается прайс, и конвейер обновляет на сайте только те позиции, которые реально изменились, благодаря отслеживанию изменений (track_changes). Не перезаписывает всё подряд, а точечно правит подорожавшее. Цены по филиалам ложатся в мультизначное поле услуги — одна услуга, несколько цен по адресам.

# фрагмент идеи Migrate-конвейера (YAML)
source:
  plugin: url               # выгрузка прайса из 1С
  track_changes: true       # обновляем только изменившиеся позиции
process:
  title: naimenovanie
  field_price_branch: cena_po_filialam
destination:
  plugin: 'entity:node'
  default_bundle: usluga

С расписанием врачей сложнее, и здесь я даю клиентам честный совет. Если есть медицинская информационная система (МИС) с API — тянем расписание из неё так же, как цены. Если надёжного источника нет — не надо имитировать актуальное расписание руками. Лучше честная кнопка «уточните время приёма по телефону», чем красивая табличка, которая устарела вчера. Неточное расписание на сайте клиники хуже, чем его отсутствие: пациент приедет к врачу, которого сегодня нет, и виноват будет сайт.

Запись на приём и 152-ФЗ: формы с персональными данными

Форма записи на приём собирает как минимум ФИО и телефон — а это персональные данные, и работать с ними надо по закону. Техническую часть комплаенса мы закрываем на уровне сайта и инфраструктуры. Форму строим на модуле Webform, и обязательный набор такой:

• чекбокс согласия на обработку персональных данных — без галочки форма не отправляется;
• опубликованная на сайте политика обработки персональных данных со ссылкой из формы;
• хранение заявок на сервере, физически расположенном в России, — наши площадки в дата-центре МТС это требование закрывают;
• передача заявки в CRM или МИС только по защищённому каналу, а не открытым письмом.

SEO для локального медицинского спроса

Приятный побочный эффект структурированного контента: он превращается в SEO почти без дополнительных усилий. Когда данные лежат в полях, а не в сплошном тексте, из них автоматически собирается разметка Schema.org — типы Physician для врачей, MedicalClinic для организации, Service для услуг. Поисковик понимает, что перед ним врач с такой-то специализацией в такой-то клинике, а не просто страница с буквами.

• Посадочные «услуга + район» генерируются через Views под локальный спрос: «УЗИ на Юго-Западной», «приём кардиолога в Митино». Это ровно те запросы, по которым люди ищут клинику рядом с домом.
• Шаблоны метатегов на тип контента (модуль Metatag) — заголовок и описание страницы врача формируются по шаблону автоматически, не надо прописывать вручную сорок раз.
• Карта сайта (Simple XML Sitemap) обновляется сама при добавлении контента.

И важный момент про медицинскую тематику: поисковые системы относят её к категории, где особенно важны экспертность и достоверность (принцип E-E-A-T). Подробные страницы врачей с реальными регалиями, образованием, стажем и фотографией — это не украшение сайта, а прямой ранжирующий сигнал. Структурированная контент-модель Drupal здесь работает на продвижение сама по себе.

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

Бюджет и сроки против альтернатив

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

Конструктор соблазняет ценой и скоростью, но у него есть потолок, в который клиника с тремя филиалами упирается к концу первого года: нет связей между сущностями, нет нормального разграничения прав, нет автоматической синхронизации с 1С. И тогда встаёт стоимость переделки — а это, по сути, второй проект поверх первого. На горизонте трёх лет (вход плюс сопровождение плюс вероятная переделка) конструктор оказывается не самым дешёвым вариантом, а самым дорогим для растущего бизнеса.

Когда всё же брать конструктор? Мой честный ответ: если филиал один, врачей пять, а бюджет нулевой — конструктора хватит, и городить Drupal ради визитки не нужно. Drupal CMS начинает окупаться там, где появляется структура: несколько филиалов, десятки услуг, цены из учётной системы, разные роли редакторов. Ровно тот профиль, с которого мы начали статью.

Переносим модель на юрфирму: что меняется

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

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

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