Доработка стоматологического шаблона: 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 страниц по районам и вспомогательные страницы. Четыре 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 страницами по районам — все созданы из одного набора шаблонов до того, как у клиники появилась реальная пациентская база, — риск заключался не в самой доработке шаблона, а в том, что заполнители контента, пустые блоки или стандартные изображения могут попасть на страницы, которые поисковые системы проиндексируют до того, как у клиента будут готовы финальные тексты и фотографии.
Стоматологический шаблон в активном использовании обслуживает несколько клиник одновременно; доработки одного проекта не должны уходить в общий слой, и черновой контент не должен уйти в публикацию. Именно эту дисциплину агентство искало, и именно её проверял 75-раундовый цикл QA в этом проекте.
Контекст рисков. Новая стоматологическая клиника, запускающаяся на фирменном шаблоне с 58 сопоставленными URL, не имеет полного набора контента для каждой страницы. Риск в этом проекте заключался в том, чтобы не допустить утечки страниц-заполнителей, пустых галерей и черновых URL на действующий сайт до того, как у клиента появятся изображения, тексты и формулировки политик. Команда, публикующая каждую строку карты сайта как «рабочую», оставляет агентству 404 ошибки, битые ссылки и заглушки заголовков в поисковых индексах.
Дисциплина заключалась в том, что мы сдерживали: страницы без контента были скрыты при запуске, блоки Lorem ipsum удалены, и каждое визуальное расхождение, отмеченное в системе проверки агентства, было согласовано до передачи. Практическим ограничением стал блог, который не удалось запустить совсем — он был скрыт из меню и исключён из карты сайта, потому что у клиники не было ни одного готового поста; это ограничение сохранялось до сдачи проекта.
Как мы это сделали
1. Figma как контракт, шаблон как холст. Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страниц. Наша задача — согласовать их страница за страницей: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны.
Когда агентство позже переназначило несколько URL с шаблона «страница услуг-лендинг» на шаблон «страница услуг» — поскольку изначальное сопоставление в карте сайта назначило неверный тип шаблона — мы перестроили эти страницы, а не вносили исправления в лендинг, потому что два шаблона имели разную иерархию компонентов, и наложение исправлений создало бы долг по разметке.
2. Цикл QA в масштабе доработки темы. Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 103 задач, отслеженных в этом проекте, 75 были итерациями QA — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы просматривали, исправляли и возвращали сборку на очередную проверку. Этот объём — не признак нестабильности; именно такой подход отличает шаблонный сайт, выглядящий «приблизительно правильно», от сайта, точно соответствующего дизайну.
Принцип прост: в проекте по доработке темы ценность создаётся именно в цикле QA. Чем короче цикл QA — тем слабее соответствие дизайну, а не более быстрая сдача.
3. Доработка без расхождения. За время проекта каждое изменение, которое мы вносили в фирменный шаблон — будь то макет страницы, компонент секции или токен стиля, — документировалось относительно Figma. Ни одна доработка не просочилась в общие компоненты шаблона, поэтому работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать.
4. Проверка на разных устройствах. Доработки проверялись в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями текущего раунда, а не весь сайт, — именно так доработка темы остаётся эффективной без потери покрытия.
Постраничная проверка типа шаблона — вот что обеспечило чистоту сборки. Четыре страницы были назначены на шаблон-лендинг услуг, хотя требовался шаблон страницы услуг — у них разная иерархия компонентов, и наложение исправлений вместо перестройки создало бы долг по разметке на этих URL. Выявление этого в ходе QA и перестройка четырёх страниц, а не их наложение исправлений, — это дисциплина, которая имела значение.
Контроль качества
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, а не тестовый сайт с известными проблемами в очереди.