Доработка стоматологического шаблона: 58 страниц за 76 дней
Доработка стоматологического шаблона на 58 страниц для запуска новой клиники — 8 шаблонов, 35 страниц услуг, 75 раундов QA за 76 дней и 56 часов.
Скриншоты сделаны автоматическими инструментами — некоторые элементы могли не загрузиться полностью или перекрываться. Для наиболее точного представления открыть действующий сайт →
Переделать сайт на новом стеке. Реализовать по спецификации. Без импровизаций. Передать готовым к переходу.
Клиент (конечный пользователь): Cedar Pearl Dental — стоматологическая клиника в Crestview, FL
Формат сотрудничества: White-label доработка темы для маркетингового агентства из США
Сроки: февраль 2026 · 76 дней · 56 часов · 58 URL · по графику
Подход к доработке темы
58 страниц стоматологического сайта, свёрстанных по Figma агентства на 8 повторно используемых шаблонах в среде Kinsta — 35 страниц услуг, 7 страниц по районам и вспомогательные страницы. 4 URL мы перестроили в середине проекта: изначальная карта сайта назначила им неверный тип шаблона. Перестроить пришлось потому, что два типа шаблонов несут разную иерархию компонентов. Агентству принадлежали Figma и система шаблонов; мы отвечали за постраничное исполнение и цикл QA, который дошёл до более чем 75 отслеженных пунктов перед передачей.
Краткий обзор
| Параметр | Значение |
|---|---|
| Отрасль конечного клиента | Здравоохранение — общая стоматология |
| Конечный клиент | Cedar Pearl Dental (Crestview, FL) |
| Формат сотрудничества | White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса |
| Тип проекта | Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн Figma на Kinsta) |
| Объём | 58 URL — главная, about, страница услуг, 35 страниц услуг, 7 страниц «районы обслуживания», лента блога, контакты и вспомогательные страницы |
| Сроки | 76 дней (18 ноя 2025 – 2 фев 2026), по графику |
| Трудоёмкость | 56 часов — разработка, итерации QA и управление проектом |
| Команда | 6 специалистов |
| Шаблоны | 8 повторно используемых шаблонов, предоставленных агентством, применены на всех 58 страницах |
| Технологии | WordPress · Elementor · Kinsta · постраничный дизайн в Figma · Site Checker (плагин QA xaverPRO) |
| Подход к QA | Более 75 отслеженных пунктов QA, согласованных в системах проверки и журналах задач агентства |
| Раунды проверки | ≈4 раунда проверки за 76 календарных дней |
| Трудоёмкость на задачу | 103 внутренних задачи Redmine · медиана 10 мин / P75 25 мин на задачу |
| Контрольный список запуска | 78 пунктов, согласован перед переключением |
Постановка задачи
Маркетинговое агентство из США передало нам макет Figma для Cedar Pearl Dental и цель развёртывания на своей фирменной системе шаблонов под Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, согласование с клиентом, настройка хостинга, контент-план. Им нужна была команда разработчиков, которая добросовестно перенесёт Figma в шаблон через столько итераций доработки, сколько потребует дизайн.
Задача была чисто исполнительская. Figma — единственный источник истины. Доработать шаблон до соответствия страница за страницей, точка адаптации за точкой адаптации. Возвращать находки QA агентству в общее рабочее пространство; не закрывать их без согласования с агентством.
Агентству нужно было обезопасить себя от подрядчика, который отнёсся бы к сборке новой клиники на 58 страниц как к массовому копированию. С 35 страницами услуг и 7 страницами по районам — все созданы из одного набора шаблонов до того, как у клиники появилась реальная пациентская база, — риск заключался не в самой доработке шаблона, а в том, что заполнители контента, пустые блоки или стандартные изображения могут попасть на страницы, которые поисковые системы проиндексируют до того, как у клиента будут готовы финальные тексты и фотографии.
Стоматологический шаблон в активном использовании обслуживает несколько клиник одновременно; доработки 1 проекта не должны уходить в общий слой, и черновой контент не должен уйти в публикацию. Именно этого агентство и искало, и именно это проверял 75-раундовый цикл QA в этом проекте.
Контекст рисков. Новая стоматологическая клиника, запускающаяся на фирменном шаблоне с 58 сопоставленными URL, не имеет полного набора контента для каждой страницы. Риск в этом проекте заключался в том, чтобы не допустить утечки страниц-заполнителей, пустых галерей и черновых URL на действующий сайт до того, как у клиента появятся изображения, тексты и формулировки политик. Команда, публикующая каждую строку карты сайта как «рабочую», оставляет агентству 404 ошибки, битые ссылки и заглушки заголовков в поисковых индексах.
Суть была в том, что мы сдерживали: страницы без контента были скрыты при запуске, блоки Lorem ipsum удалены, и каждое визуальное расхождение, отмеченное в системе проверки агентства, было согласовано до передачи. Практическим ограничением стал блог, который не удалось запустить совсем — он был скрыт из меню и исключён из карты сайта, потому что у клиники не было ни одного готового поста; это ограничение сохранялось до сдачи проекта.
Как мы это сделали
1. Figma как контракт, шаблон как холст. Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страниц. Наша задача — согласовать их страница за страницей: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны.
Когда агентство позже переназначило несколько URL с шаблона «страница услуг-лендинг» на шаблон «страница услуг» — поскольку изначальное сопоставление в карте сайта назначило неверный тип шаблона — мы перестроили эти страницы, а не вносили исправления в лендинг, потому что 2 шаблона имели разную иерархию компонентов, и наложение исправлений создало бы долг по разметке.
2. Цикл QA в масштабе доработки темы. Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 103 задач, отслеженных в этом проекте, 75 были итерациями QA — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы просматривали, исправляли и возвращали сборку на очередную проверку. Этот объём — не признак нестабильности; именно такой подход отличает шаблонный сайт, выглядящий «приблизительно правильно», от сайта, точно соответствующего дизайну.
Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время.
3. Доработка без расхождения. За время проекта каждое изменение, которое мы вносили в фирменный шаблон — будь то макет страницы, компонент секции или токен стиля, — документировалось относительно Figma. Ни одна доработка не просочилась в общие компоненты шаблона, поэтому работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать.
4. Проверка на разных устройствах. Доработки проверялись в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями текущего раунда, а не весь сайт, — именно так доработка темы остаётся экономной без потери покрытия.
Постраничная проверка типа шаблона — вот что сохранило сборку чистой. 4 страницы получили шаблон-лендинг услуг, хотя нужен был шаблон страницы услуг: у них разная иерархия компонентов, и точечные правки вместо перестройки создали бы долг по разметке на этих URL. Поймать это в ходе QA и перестроить 4 страницы, а не латать их, — вот что здесь было важно.
Контроль качества
QA в этой сборке поймал две категории ошибок контента до передачи. На странице политики конфиденциальности стояло неверное имя клиента — текст Cedar Smiles на странице Cedar Pearl Dental; нашли в первом внутреннем раунде QA. Четыре URL услуг получили шаблон-лендинг услуг, хотя нужен был шаблон страницы услуг; это отметили после сборки и перестроили, а не залатали точечными правками.
QA перед сдачей проходил через Site Checker — категории и порог нулевых ошибок описаны в разделе наш подход к QA. Собственный QA-контур агентства запускался после передачи и заводил замечания в общую очередь для нашего цикла исправлений, пока агентство не подписывало приёмку.
Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись.
Результаты
| Метрика | Результат |
|---|---|
| URL доставлено | 58 — 1 главная, 1 страница услуг, 35 страниц услуг, 7 страниц «районы обслуживания», 2 страницы about, 1 лента блога, 1 контакты и 10 вспомогательных страниц |
| Применено шаблонов | 8 из 8 повторно используемых шаблонов созданы и сопоставлены на 58 страницах (главная, About Us, Area We Serve, Blog Lander, Contact Us, Services Lander, Service Page, Default Template) |
| Контрольный список запуска | 78 пунктов согласованы |
| Отслежено и решено проблем QA / SEO | Более 75 пунктов, согласованных в системах QA и проверки агентства |
| Итераций QA в Redmine | 75 из 103 задач (73%) отслежены на уровне итераций |
| Сроки | 76 дней, доставлено по графику |
| Трудоёмкость | 56 часов при оценке 56 часов — без перерасхода, без расширения объёма |
| Команда | 6 специалистов |
| Передача хостинга | Работает в среде шаблонов Kinsta агентства |
| Состояние страниц при передаче | 58 / 58 URL на тестовой среде возвращали HTTP 200 в аудите карты сайта |
Если коротко: Figma агентства был реализован на их фирменном шаблоне на 58 страницах и 8 шаблонах за 76 календарных дней в рамках оценки в 56 часов.
Процесс
| Этап | Длительность | Результат |
|---|---|---|
| Бриф и оценка | ~3 дня | Figma просмотрен, доступ к шаблону подтверждён, объём согласован |
| Разработка доработки | ~5 недель | Постраничная доработка шаблона под Figma |
| Итерации QA (параллельно) | ~6 недель | 75 раундов QA; каждый закрыт только после согласования с агентством |
| Раунды правок | ~1 неделя | Коррекции после проверки, сокрытие контента, визуальные уточнения |
| Сдача проекта | Финальный день | Сайт запущен на Kinsta |
Разработка и QA выполнялись параллельно — это характерно для доработки темы, где «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования с агентством.
Команда
Команда проекта
- Никита Тумашевич — проверка сборки и поддержка QA
- Павел Сажин — итерации QA и правки
- Анна Полунина — поддержка доработки шаблона и QA
- Тимур Арбаев — итерации QA и поддержка разработчика
- Людмила Травкина — ведущий разработчик (доработка шаблона и перенос Figma в макет)
- Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование)
Управление проектом, дизайн и коммуникация с клиентом оставались на стороне партнёрского агентства на всём протяжении. Конечный клиент нас не видел: все запросы на доработку шли через общий журнал задач агентства, и сама сборка ему напрямую не показывалась. Каждый раунд QA закрывался только после подтверждения рецензентом агентства, что расхождение устранено.
Агентствам с библиотекой шаблонов
Готовый шаблон должен ускорять сдачу. Но отвечать перед клиентом за пустую галерею и заглушку в индексе придётся вам, агентству, — и всплывёт это уже после запуска. У одной клиники это стандартный набор стоматологических страниц; у мультифилиальной сети это бренд-токены, которые перестают расходиться, едва первый филиал поправит цвет. Заготовки с Lorem ipsum уйдут в карту сайта, пустые галереи отдадут 404, а первое же обновление вендорского шаблона тихо сломает оплаченные вами доработки.
Спрашивать подрядчика стоит не «соберёте ли страницы по шаблону», а «как именно вы отделите готовое от неготового и переживёт ли клиентский слой следующее обновление шаблона».
Пришлите исходник шаблона или его ID и спецификацию бренда. Мы разберём, какие страницы рискуют уйти в публикацию пустыми, найдём состояния по умолчанию, способные просочиться как живой контент, и вернём фиксированную смету в часах. Аудит без оплаты.
У вас ещё нет ТЗ? Пришлите описание в один абзац — мы вернёмся с вопросами, которые стоит задать. Прислать описание →
Site Checker запускается до того, как агентство что-либо видит.
Перед передачей каждый сборки в тестовой среде прогоняется через Site Checker — WordPress QA-плагин, который мы разработали и поддерживаем. Это шлюз с нулевой терпимостью к ошибкам: к агентству не уходит ничего с открытыми проблемами. Предупреждения рассматриваются и признаются некритическими; агентство получает чистый старт для своего слоя QA, а не тестовый сайт с известными проблемами в очереди.