# xaver.ru — полный корпус Сгенерировано xaver-llms-txt v1.0.5 · 2026-07-12T08:20:20Z Источник: https://xaver.ru/ --- url: https://xaver.ru/case/sib-cert-ai-recognition-discovery/ title: Прошли аналитическую фазу и собрали ИИ-прототип для сертификационного центра type: case_study date: 2026-07-12T04:28:50+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Сертификационный центр попросил автоматизировать выпуск деклараций ТР ЕАЭС. За два месяца мы изучили их ручной процесс, собрали работающий прототип распознавания и письменно ответили на техническую проверку из двух десятков вопросов. Кейс о том, как выглядит разбор регламентного процесса и почему он полезен клиенту, даже если разработка так и не началась. Руководитель компании знает эту боль изнутри: выпуск декларации держится на человеке. Менеджер вручную заносит заявку из карточки компании, техотдел собирает пакет документов по шаблонам, сверяет данные глазами, вручную заполняет реквизиты. Масштабировать это наймом — дорого и хрупко. Заказчик пришёл с прямым запросом: можно ли посадить сюда ИИ. Мы не стали продавать «ИИ под ключ». На ИИ заранее не скажешь, что сработает, пока не соберёшь и не прогонишь на реальных документах. Поэтому сперва вникли в процесс и собрали прототип на реальных пакетах. Показали границы: где ИИ снимет рутину, а где может подвести. Клиенту отдали факты для решения. ## Сводка Отрасль Сертификация продукции, декларации ТР ТС / ЕАЭС Конечный клиент Компания в сфере сертификации, под код-именем Формат сотрудничества Предпроектный анализ: аудит процесса + прототип, без подписанного договора на разработку Тип проекта ИИ-автоматизация выпуска деклараций: распознавание документов, автозаполнение, подсказчик ТН ВЭД / ТР ТС Период Октябрь — декабрь 2025 Часы Аналитический этап — 16 ч. Прототип собран за свой счёт. Оценка первого этапа разработки ~150 ч не согласована. Команда Антон Херсун (руководитель проекта) и аналитик-разработчик, ведущий разбор с первого дня Статус Прототип сдан, клиент увидел результаты распознавания. Полный проект не запущен по решению заказчика. ## Что нас попросили Заказчик выпускает декларации и сертификаты соответствия под ТР ТС / ЕАЭС: ДС, СС, протоколы испытаний, договоры уполномоченного лица. Всё это готовится вручную в их CRM, по шаблонам, силами двух отделов. Запрос звучал широко — «внедрить ИИ в работу», а по сути распадался на 3 задачи: распознать входящие документы клиента, автозаполнить шаблоны декларации и договора, подсказать код ТН ВЭД и нужный технический регламент. ## Что тут на самом деле сложно Сложность не в модели, а в процессе, которого нет на бумаге. Мы разобрали его по реальным сделкам в их CRM, по учебным видео и по закадровым записям работы менеджеров. Картина вышла такая. Приёмная сторона получает письмо, часто без заполненной заявки, и вручную заносит данные заявителя из карточки компании: наименование, ИНН, ОГРН, адрес. Техотдел берёт заявку из воронки, определяет применимый регламент (например, ТР ТС 010 для навесного оборудования), сопоставляет код ТН ВЭД с группой продукции и собирает по шаблонам пакет документов — макет декларации, договор уполномоченного лица, сопроводительные материалы. Каждый документ потом вручную сверяют с исходной заявкой поле за полем. Ручной ввод, сборка по шаблонам, множественные сверки. Каждый шаг — место, где ИИ может либо снять рутину, либо тихо подвести: документ уходит в госреестр, ошибка стоит дорого. Поэтому первым делом мы искали не «где красиво показать ИИ», а «где он не ошибётся». ## Как мы это сделали Взяли доступ наблюдателя в их CRM и прошли шесть сделок и лидов — от письма клиента до готового пакета документов. Разобрали учебные материалы и записи работы обоих отделов. Собрали схему формирования документа: какое поле откуда берётся. Это и есть та самая аналитическая фаза. Не созвон на час, а разбор по первичным документам, после которого понимаешь процесс лучше, чем он описан у самого заказчика. Дальше — прототип. За несколько вечеров подняли на своей инфраструктуре веб-форму заявки с ИИ-распознаванием входящих документов, прогнали на реальных пакетах и отдали заказчику ссылку с логином. Он увидел результаты распознавания вживую; собственный тест у него в тот раз не прошёл — ИИ-сервис был выключен, запускали повторно. Прототип сразу обнажил и сильные места, и границы: где модель уверенно вытаскивает данные, а где нужны дообучение и ручная проверка. Параллельно закрыли техническую проверку. Заказчик прислал два десятка вопросов разом: бизнес-логика, обработка персональных данных и 152-ФЗ, выбор моделей, архитектура, база данных, безопасность, права на результат, метрики приёмки. Мы ответили письменно, по пунктам. Отдельно проработали интеграцию с госсистемами — как декларации уходят во ФГИС Росаккредитации через «Синтез» и личный кабинет на Госуслугах, что нужно для подключения к СМЭВ3, нужна ли сертификация ПО. И под санкционный риск сразу предложили российский контур: GigaChat вместо западных моделей, отрасль достаточно стандартизирована, чтобы подход не поменялся. ## Развилка и честный статус Дальше проект встал — и это часть кейса, а не сноска. Заказчик тянул с решением: то добавлял пласт требований (сертификация ПО под ФГИС), то заново прощупывал нашу компетентность, то откладывал ответ о сроках запуска. К декабрю выяснилось, что параллельно он собирал информацию сам и пришёл к выводу, что ему сначала нужен бизнес-аналитик — описать процессы и требования. То есть наш анализ лёг в основу его собственных решений. Мы сделали прямой ход. На запрос «двигаемся к реализации или останавливаем» поставили вопрос ребром: чем дольше тянется пауза, тем больше контекста теряется из памяти. А когда стало ясно, что до нового года проект не стартует, попросили оплатить аналитический этап — 16 часов разбора, которые уже работают на клиента. Заказчик ответил вежливым отказом: детального плана мы, мол, не согласовывали, а значит это «знакомство с проектом и коммерческое предложение, не более того». Свою часть недооценки мы тоже видим. Объём оказался больше, чем мы ожидали: рассчитывали за короткий срок снять всю цепочку знаний о процессе, а пришлось погружаться глубже, и здесь мы недоглядели. Пошли на это сознательно: ИИ — сфера новая, и опыт в ней стоит набрать, даже если часть работы ложится на нас. Но одно дело — вложиться в опыт по своему решению, и совсем другое, когда задним числом видишь, что бесплатным стал не пробный прототип, а глубокое погружение в чужой процесс. Так проходит граница между бесплатным прототипом и платным анализом, и на этом проекте мы её нащупали. Прототип за свой счёт остаётся нашим правилом. Но глубокое погружение в чужой регламентный процесс — это инженерная работа, и на следующем таком проекте она станет отдельным оплачиваемым этапом на входе, а не выяснится задним числом. ## Что заказчик получил Что Как это выглядит на практике Прототип до большой траты ИИ-распознавание документов собрано и отдано на тест прежде, чем зашёл разговор про полный бюджет Карта собственного процесса Регламент выпуска декларации разобран по реальным сделкам и записям — точнее, чем он описан внутри Ответы на техническую проверку Два десятка вопросов по 152-ФЗ, архитектуре, моделям и правам — письменно, по пунктам Проработанная интеграция с госсистемами ФГИС, СМЭВ3, «Синтез», вопрос сертификации ПО — разобрано до кода Честная граница ИИ Где распознавание надёжно, а где нужна ручная проверка — заказчик увидел на результатах прогона по реальным пакетам, а не на слайдах ## Команда - **Антон Херсун, Xaver Pro**: руководитель проекта. Аудит процесса, оценки в фиксированных часах, прототип, переговоры с заказчиком про экономику и границы. - **Аналитик-разработчик** вёл разбор CRM, собирал схему процесса и прототип распознавания. Одно направление ведёт один человек — решение опирается на знание всей картины, а не на догадки. ## Скриншоты и материалы _Не применимо для публикации: прототип поднимался на нашей инфраструктуре под тесты заказчика, продуктового интерфейса под код-именем не показываем._ > Если у вас регламентный процесс, который держится на людях и шаблонах, и вы думаете про ИИ, но не хотите платить за «решение под ключ» вслепую — покажите его нам. Разберём процесс, соберём прототип на ваших документах и честно скажем, где ИИ снимет рутину, а где только подведёт. **Первичная оценка бесплатна.** [Запросить разбор процесса →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-contractor-who-talks-you-out/ title: Подрядчик, который отговаривает: 9 эпизодов за 2 года type: case_study date: 2026-06-07T13:49:38+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Самый дорогой риск абонентки — не аварии. Аварии видно. Дорого другое: подрядчик, которому выгодно находить себе работу. Часы оплачиваются, неиспользованные сгорают, а проверять обоснованность каждой задачи у клиента нет ни времени, ни экспертизы: за экспертизой он и пришёл. Снаружи честного подрядчика от «находчивого» не отличить: оба отвечают быстро, оба присылают счета вовремя. Отличие живёт в истории переписки. Этот кейс не про один проект, а про сквозную линию из 9 эпизодов за 24 месяца: мы отговаривали клиента от работ, на которых заработали бы. Каждый эпизод оставил след: задачу в трекере или сообщение в чате. Сумм в кейсе нет ни одной, и это принципиально: деньги здесь показаны только поведением. ## Сводка Отрасль клиента digital-агентство (веб-студия) Клиент анонимизирован — «Медиастудия», Россия **Формат сотрудничества** **абонентская DevOps-поддержка, договор ИП↔ИП, прямой клиент** Тип проекта мета-кейс: модель отношений на длинной абонентке Объём работ ~14 серверов в обслуживании, 96 задач в трекере за период **Дата проекта** **10 июн 2024 – 28 фев 2026 (628 дней — диапазон эпизодов)** Трудозатраты помесячная абонентка с минимальным объёмом; отдельные эпизоды кейса — от 0.25 ч Команда 3 специалиста (инженер-сисадмин · инженер точечно · руководитель проекта) Технологический стек ISPmanager · Bitrix · MySQL/MariaDB · nginx · Zabbix · Redmine **Сдано** **клиент передал бюро конечного заказчика на прямой контракт и рекомендовал бюро третьей компании** ## Что было У агентства парк из ~14 серверов: GitLab, облако, мониторинг, панель и пачка клиентских сайтов, в основном Bitrix. Мы зашли в мае 2024-го, после ухода прежнего админа, на классическую абонентку: минимальный месячный объём, неиспользованные часы сгорают, внеплановые задачи оплачиваются сверху. Экономика такого договора толкает подрядчика в одну сторону: чем больше задач «найдёшь», тем больше счёт. Клиент это понимает не хуже нас. Первые месяцы любой абонентки уходят на проверку, кого он на самом деле нанял. Ниже — что эта проверка показала, эпизод за эпизодом. ## 9 эпизодов **1. Клиент сам приносит большой проект — мы закрываем его за 0.25 часа.** Июнь 2024. Клиент ставит задачу: проработать переход на управление инфраструктурой как кодом (IaC), выдать план и стоимость. Готовый бюджет, прямой запрос, бери и оценивай. Инженер отвечает из практики: ISPmanager стандартизации поддаётся очень плохо, ставить и настраивать его всё равно придётся вручную. Зато бэкапы панель разворачивает сама. Решающим аргументом стало время: «с учётом времени обновления ДНС — которое длится часы — нет особого смысла за большие деньги изобретать что-то. т.е. пока ДНС обновится, уже всё развернётся». Вместо проекта — совет без счёта: разнести сервер бэкапов и боевой ЦОД по разным хостерам. Ответ клиента в задаче: «понял. тут больше нет вопросов». В трудозатратах: 0.25 часа. **2. «Выиграем копейки».** Июль 2024. Заходит речь о том, чтобы дожать nginx-кэш на Yii-бэкенде клиентского сайта. Часы тюнинга были бы наши. Инженер режет тему сам: «это явно надолго и выиграем копейки. Не стоит, помоему». И вместо кэша отдаёт разработчикам клиента рекомендации уровня приложения. **3. Счёт в минус себе.** Октябрь 2024, контракт на 10 часов в месяц. В отчёте за месяц: по факту трудозатрат было 4.5 часа — «недоработали». Цифра не с потолка: сумма записей в трекере сходится с чатом до четверти часа. **4. «50 единиц потерялись — в следующем месяце доплачу».** Расхождение в учёте бюро нашло само и само же объявило в чате клиента, не дожидаясь акта сверки. Учёт часов при этом открыт постоянно: бот бюро отвечает на запрос трудозатрат прямо в общем чате. **5. «Торопиться не надо».** Декабрь 2024 – январь 2025. Переговоры о крупном проекте для заказчика клиента: созвон, 2 инженера, проработка архитектуры. В январе — отбой, заказчик не потянул бюджет. Реакция бюро в чате: «торопиться не надо». Без дожима, без «специальных условий до конца недели». **6. Два честных варианта цены и право выбрать дешёвый.** Март 2025. Dev-серверу клиентского проекта нужен PHP 8.1, ОС старая. Инженер выдаёт оба пути с честной ценой в часах. Быстрый: временная лицензия панели и переключение версии — час работы. Правильный: новый сервер с поддерживаемой ОС и перенос — от 3 часов, база 30 ГБ и 80 ГБ файлов, «БД не быстро заливаются, такого размера». Клиент выбрал дешёвый. Бюро зафиксировало риск (сервер всё равно предстоит обновлять) и не настаивало. **7. «Может, не надо ничего чистить?»** Август 2025. Прилетает задача на расчистку диска: оплачиваемая, согласованная, можно молча сделать. Инженер сначала смотрит скриншоты: «места почти половина по скринам — может не надо ничего чистить?» Задача не состоялась. **8. Память не докидываем без диагноза.** Ноябрь 2024. У клиента привычный рефлекс на тормозящий сервер: «просто докинуть памяти». Инженер останавливает: «не факт что поможет, без выяснения причины, что за процесс и почему сожрал». Расширение железа — самая лёгкая продажа в поддержке, потому что её не нужно обосновывать. Мы обосновываем: сначала причина, потом железо. **9. «Верните половину памяти».** Февраль 2026, кризис в сезон продаж у магазина конечного клиента: под нагрузкой серверу добавили ресурсов, память выросла с 24 до 64 ГБ. Кризис прошёл, и инженер сам пишет: «память пусть обратно вдвое урезают до 32G… если всё ровно — пусть вернут как было». Клиент платит хостеру меньше. Инициатива — подрядчика, которому за неё никто не платит. ## Хронология Период Эпизоды июнь–июль 2024 отказ от IaC за 0.25 ч; «выиграем копейки» октябрь–ноябрь 2024 «недоработали» в счёте; «не докидывать памяти без причины» декабрь 2024 – январь 2025 «торопиться не надо» на сорвавшихся переговорах март 2025 два варианта цены, клиент выбрал дешёвый август 2025 – январь 2026 «может не надо ничего чистить?»; «50 единиц потерялись — доплачу» февраль 2026 «верните половину памяти» _Эпизоды распределены по 24 месяцам обычной работы: между ними шли ежемесячные обновления, инциденты и плановые задачи. Линия отказов сквозная, а не разовая акция в начале контракта._ ## Результаты Метрика Значение Задокументированных отказов от оплачиваемых работ 9 за 24 месяца (06.2024 – 02.2026) Самый быстрый «отказ от проекта» 0.25 ч — задача про IaC закрыта одним обоснованием Счёт в минус себе 4.5 ч при контрактных 10 ч/мес, в отчёте — «недоработали» Передача конечного клиента на прямой контракт бюро ноябрь 2024, по инициативе владельца агентства Рекомендация бюро третьей компании август 2024: «я тут хочу порекомендовать вас в качестве девопсов» Длительность отношений 24+ месяца, договор продлевается Итог этой проверки выглядел так. В ноябре 2024-го владелец агентства сам предложил: «хотим этого клиента передать вам на прямой контракт. Возьмёте?» Для рынка субподряда это исключение: субподрядчика от конечного клиента обычно прячут, а не знакомят с ним напрямую. Ещё раньше, в августе, тот же владелец рекомендовал бюро знакомой компании как DevOps-подрядчика. Рекомендация и переданный контракт — единственная «выручка» этого кейса, и она оказалась больше всех часов, от которых мы отказались. ## Команда - **Инженер-сисадмин (бюро)**: основной поток задач; автор большинства отказов из этого кейса - **Инженер (бюро)**: точечные подключения (пресейл, консилиумы по железу и БД) - **Антон Херсун, Xaver Pro** — руководитель проекта > Выбираете DevOps-подрядчика на абонентку и хотите понять, кого нанимаете на самом деле? Начните так же, как клиент из этого кейса: с небольшой проверки. Пришлите бриф или текущую техническую документацию — мы посмотрим, выделим узкие места, вернёмся с фиксированной оценкой в часах. Если что-то из задуманного делать не стоит, скажем об этом первыми. Разговор бесплатный. [Обсудить сопровождение →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-monitoring-before-humans-70-incidents-24-months/ title: ~70 инцидентов за 24 месяца: бот замечает раньше людей type: case_study date: 2026-06-07T13:49:38+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Сайт падает ночью — это не гипотеза, а расписание. За два года на этом парке кончались диски, ядро убивало базы данных, у хостера отказывала система хранения, истекали домены, а однажды завис сам сервер мониторинга. Вопрос никогда не стоял «упадёт ли». Вопрос стоял иначе: кто узнает первым — дежурный инженер или клиент, у которого не открылась корзина. Этот кейс о том, как поток аварий превращается в управляемую рутину. Бот пишет в чат, инженер оказывается в системе через 1–9 минут, типовой инцидент закрывается за 7–50 минут, и каждый эпизод оседает строкой трудозатрат в трекере. Формальных гарантий по времени реакции в договоре нет, но цифры есть. ## Сводка Отрасль конечного клиента digital-агентство; клиентские интернет-магазины, в основном на Битрикс Конечный клиент «Медиастудия» (код-имя), Россия **Формат сотрудничества** **абонентская поддержка: чат — оперативка, Redmine — фиксация и часы** Тип проекта мониторинг и реакция на инциденты как постоянный процесс Объём работ ~14 серверов в Zabbix; ~70 инцидентов за 24 месяца, ~30 — с точным хронометражем **Дата проекта** **4 июня 2024 – 1 июня 2026 (727 дней); процесс продолжается** Трудозатраты по месячным задачам «реакции на мониторинг», типовой эпизод 0.25–2 ч; разнородный поток в одну цифру не сводим Команда 3 специалиста (инженер-сисадмин · второй инженер точечно · руководитель проекта) Технологический стек Zabbix 6.4 · Telegram-бот · ISPmanager · nginx · Apache httpd · MySQL/MariaDB · CentOS 7 / AlmaLinux / Ubuntu **Сдано** **бот замечает первым в большинстве инцидентов; реакция 1–9 минут; типовое восстановление 7–50 минут; сам мониторинг перенесён на новый сервер за 2 часа — ровно по оценке** ## Постановка задачи До договора парк выглядел так: 12 VDS, прошлый администратор ушёл, «раз-два в неделю что-нибудь стабильно падает». Zabbix у студии уже стоял и исправно слал по 1–12 алертов в день — в пустоту. Смотреть их было некому, реагировать — тем более. Мониторинг существовал, а реакции не существовало. Запрос клиента простой и жёсткий: узнавать о падениях раньше своих заказчиков и по каждому алерту видеть, кто и что с ним сделал и сколько это заняло. Не «поставьте нам красивые графики», а «сделайте так, чтобы аварии переставали быть сюрпризом». Что здесь сложного с точки зрения покупателя кейса: мониторинг — это инструмент, который умирает от собственного шума. Сотый проигнорированный алерт ничем не отличается от выключенного Zabbix, и почти у каждой студии он именно так и стоит — установлен, настроен, проигнорирован. О падениях по-прежнему сообщают клиенты. Задача была не «внедрить мониторинг», а построить вокруг него дисциплину реакции. И удержать её 24 месяца подряд: на чужом парке, без штатного дежурного, без бюджета на круглосуточную смену. ## Как мы это сделали **1. Критические алерты — в общий рабочий чат, а не в отдельную консоль.** В июне 2024 бот Zabbix подключён прямо в чат с клиентом, состав алертов согласовали сразу: «ок, давайте пока критические». Падение и реакцию на него обе стороны видят одновременно, в одной ленте. Спрятать инцидент невозможно, да и незачем: скорость реакции стала публичной метрикой, которую клиент проверяет каждый день, просто читая чат. **2. Месячная задача «реакции на мониторинг» — весь поток аварий на учёте.** С июля 2024 по июнь 2026 в трекере каждый месяц живёт одна задача-контейнер. Каждый рестарт, чистка диска, разбор ночного алерта записывается туда отдельной трудозатратой с комментарием: типовой эпизод стоит 0.25–0.5 ч. Первая такая задача закрылась с 0.75 ч на два эпизода. Аварии перестали быть «бесплатной паникой» и стали учётной единицей: клиент платит абонентку и видит, из чего она состоит, до строки. **3. Алерт-гигиена: алерт обязан означать действие.** Когда диск, хронически забитый на 95%, сыпал десятками сообщений «меньше 5% места», порог снизили до 3%: уведомление приходит, когда пора действовать, а не когда «как обычно». Когда поток сообщений начал мешать самой работе, бюро попросило клиента почистить состав: «сейчас заббикс больше мешает нам тут чем помогает» — «Оставил только критические, остальные отключил». Шумный мониторинг умирает первым. Этот живёт третий год. **4. Мониторим сам мониторинг.** 8 октября 2024 все серверы парка разом «потеряли» агентов: Zabbix-сервер самовольно обновился до 6.4.19. Агенты вернулись за 13 минут, автообновление отключено той же ночью: мониторинг не имеет права обновлять сам себя в случайный момент. В декабре 2025 история серьёзнее: старый ARM-сервер мониторинга начал зависать на 4–8 часов, то есть оставлять весь парк без глаз, а хостер переносить виртуалку отказался. Оценка бюро: «часа два». Вечером 29 декабря база и настройки переехали на новый сервер — ровно 2 часа по трекеру, с переносом IP, чтобы агенты не заметили переезда. Утром от клиента: «По первым проверкам — вроде все работает, спасибо!» **5. Дыры признаём письменно — и закрываем.** 30 декабря 2024 сайт, которого не было на мониторинге, пролежал 4.5 часа, пока менеджер клиента не написал вручную; инженер поднял его за 10 минут с момента обращения, после чего сайт встал на мониторинг, а на сервер добавили недостающий syslog. 18 августа 2025 агент сервера бэкапов молчал 20.5 часов: алерт был, его пропустили. В чате — честное «чё-то я пропустил алерт», починка за 7 минут: на сервере сам собой запустился firewalld с единственным разрешённым портом ssh, файрвол снесли. Пропуск, признанный и закрытый за 7 минут, работает на доверие сильнее, чем красивая статистика без единого признания. ## Инциденты и реакция Три показательных эпизода из ~30 задокументированных: Дата Что упало Кто заметил Восстановление 20.02.2025 общий сервер завис, не пингуется бот — за 20 мин до клиента ~22 мин (сбой на стороне хостера) 26.11.2024 хранилище 3 ТБ: диск забит под 100% бот, сразу 3–4 мин 27.01.2025 упала БД интернет-магазина менеджер клиента, взято за 1 мин ~28 мин Закономерность одна. Бот ловит первым почти всё; люди клиента приносят ночные эпизоды и то, что в мониторинг ещё не попало. Дальше работает один и тот же контур: инженер в системе за минуты, диагноз вслух в чате, починка — трудозатратой в месячную задачу. А каждое «почему упало» превращается в настройку, чтобы не упало снова: лимиты процессов, ватчдоги, пороги, явные таймауты вместо дефолтов. Честности ради — потолок у формата есть. Без круглосуточной смены ночной алерт иногда ждёт утра: самые длинные простои периода (4.5–8 часов) пришлись на ночные серии и на сайты, которых в мониторинге ещё не было. Инфраструктура самой студии дольше ~3 часов не лежала ни разу. ## Результаты Метрика Значение Инцидентов за 24 месяца ~70, из них ~30 с точным хронометражем Кто замечает первым бот — в большинстве случаев Реакция инженера 1–9 минут от алерта или обращения Восстановление типового инцидента 7–50 минут Перенос самого Zabbix на новый сервер 2 часа — ровно по предварительной оценке Ложный массовый алерт (автообновление Zabbix) разобран за 13 минут, причина устранена той же ночью Пропущенный алерт (единственный признанный) закрыт за 7 минут после эскалации Фон до старта «раз-два в неделю что-нибудь стабильно падает» Простыми словами: студия с парком из ~14 серверов два года живёт без сюрпризов от собственной инфраструктуры. Падения случаются: на дешёвых VPS с Битрикс-магазинами они неизбежны. Изменилось то, что о них первым сообщает бот, а не разгневанный заказчик, и то, что у каждого падения есть время реакции, причина и вывод, записанные в трекер. ## Команда - **Инженер-сисадмин (бюро)** — первая линия: реакция на алерты, диагностика, ватчдоги, перенос Zabbix - **Инженер (бюро, точечно)** — подключение на консилиумы и параллельные инциденты - **Антон Херсун, Xaver Pro** — руководитель проекта: процесс, эскалации, разбор спорных эпизодов > Если ваш Zabbix шлёт алерты в пустоту, а о падениях первыми сообщают заказчики — пришлите бриф или текущую техническую документацию. Мы посмотрим, выделим узкие места, вернёмся с фиксированной оценкой в часах. Первичная оценка бесплатна. [Настроить мониторинг →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-bitrix-season-crisis-2-days-4-root-causes/ title: Кризис в сезон продаж: два дня, четыре причины type: case_study date: 2026-06-07T13:49:38+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Аварии редко выбирают удобное время, а эта выбрала худшее: у конечного клиента, Битрикс-магазина спецодежды, сезон продаж. Самое тяжёлое в таких инцидентах не нагрузка и не работа до ночи. Самое тяжёлое — когда причина не одна. Чинишь очевидное, сайт оживает на час и снова ложится: значит, под первой проблемой лежит вторая. Здесь их оказалось четыре. ## Коротко Отрасль конечного клиента розничная и оптовая торговля спецодеждой и СИЗ Конечный клиент Битрикс-магазин (анонимизирован), VDS у стороннего хостера **Формат сотрудничества** **white-label техподдержка для веб-студии, абонентка** Тип проекта аварийная диагностика и стабилизация боевого сервера в сезон продаж Объём работ боевая VDS: 18 CPU / 24 ГБ RAM на старте кризиса, обмен заказами с 1С **Дата проекта** **25 фев 2026 – 27 фев 2026 (3 дня)** Трудозатраты 11.25 ч за февраль на этот сайт; из них 6.5 ч — два пиковых дня Команда 1 инженер-сисадмин (бюро), руководитель проекта на эскалации Технологический стек 1С-Битрикс · MySQL · nginx + Apache · CentOS 7.8 · ispmanager **Сдано** **сайт в штатном режиме, скрипт автобана дежурит, половину докупленной памяти сами предложили вернуть** ## Постановка задачи Студия ведёт сайты своих заказчиков, мы ведём её серверы: мониторинг, ежемесячные обновления, инциденты. Магазин спецодежды — один из самых нагруженных объектов: тяжёлый Битрикс, большая база, регулярный обмен заказами с 1С из облака заказчика. Сервер — чужая VDS на CentOS 7.8 с панелью ispmanager, и в феврале у магазина сезон. Запрос пришёл буднично. 25 февраля в 16:36 мониторинг зафиксировал: главная не отвечает дольше 60 секунд. Менеджер студии в чате: «чекните плиз, а то сайт сдох». Дальше — двое суток, в которые сайт то лежал, то полз: страница каталога открывалась 20–30 секунд, товар добавлялся в корзину за 6–8 секунд вместо полутора. К вечеру второго дня студия сказала прямо, чего это стоит: «6 ч проблем сегодня с сайтом, это максимально вредит бизнесу. И клиент мне наяривает каждые полчаса». Опасность тут одна — причин несколько, и все на чужом железе. Хостер на жалобы отвечает «с нашей стороны проблем не наблюдается», при добавлении ресурсов статистика виртуальной машины обнуляется: графиков «до» просто нет. Каждая исправленная причина даёт час тишины, и если остановиться на первой — завтра всё повторится, а доверие клиента к студии уже подорвано. Поэтому копали до конца списка. К вечеру первого дня закрыли две причины из четырёх, к вечеру второго — нашли последнюю и отбили атаку. ## Четыре причины **1. Антивирус, который никто не просил.** В свежеобновлённой панели «какая-то добрая личность включила ImunifyAV». Антивирус молотил очередь проверок десятками процессов, каждый держал до половины ядра CPU. Выяснять, на чём именно он клинит, в разгар сезона некогда: процессы убиты, панель остановлена, чтобы не перезапускала очередь заново. Разбор полётов оставили на потом, сначала — сайт. **2. Опечатка в одну цифру.** В конфиге MySQL стояло `sort_buffer_size = 2M` вместо 32M: «вероятно ошибка, просто 3 в начале удалили». Для большой базы под тяжёлым движком это означало сортировки через диск на ровном месте. Цифру вернули — «вроде полегче стало». Полегче, но не хорошо: список причин на этом не закончился. **3. Диски.** База пилила диск даже после исправления конфига, а после переноса ВМ на другой гипервизор стало хуже: нагрузка меньше — тормоза сильнее. Хостер проблему не признал, поэтому аргументировали сравнением: на собственном гипервизоре бюро IOPS на чтение сопоставимы, на запись — в 100 раз выше, и это при 107 работающих виртуалках и загрузке дисков 10–20%. Рекомендация заказчику зафиксирована: NVMe и/или память, чтобы база целиком жила в кэше. **4. DDoS, который легко пропустить.** Не тысячи запросов в секунду, по которым атаку видно из космоса, а 500–600 открытых и молчащих соединений на 443-й порт. Ни байта данных, просто заняты слоты веб-сервера. Честная оценка инженера в чате: «в своё оправдание скажу, что такое вижу второй раз в жизни: обычно это более явно, не 500–600 соединений, а тысячи». Именно эта причина объясняла главную загадку двух дней: почему сайт ложится снова после каждого исправления. ## Автобан за вечер Готовый анти-DDoS-сервис потребовал бы согласований, смены DNS и часов ожидания, которых в сезон нет. Вместо этого инженер написал скрипт под конкретную сигнатуру атаки: больше 5 одновременных соединений на 443-й порт, по которым не передано ни байта, — бан на 300 секунд. Белый список — офис конечного клиента и облако с 1С. Первая версия была грубее, и это честная часть истории. Бан вручную, всех скопом — и под раздачу попали свои: менеджер студии, проверявшая сайт в нескольких браузерах разом, и IP-адреса облака, через которое идёт обмен заказами. Полчаса «то заблокировано, то разблокировано», и только потом скрипт с исключениями. Сработало. К 19:45 банлист опустел: атакующий понял, что соединения умирают через пять минут, и отвалился. 27 февраля пришла последняя жалоба: обрывы обмена 1С из облака. Проверяли методом исключения слоёв: банлист пуст → сервер пингует облако → в access-логе 200-е ответы на запросы 1С → файрволл остановлен для чистоты эксперимента → контрольный ребут, 2–3 минуты простоя, согласованные в чате за минуту. После ребута обрывы прекратились. За два дня кризиса в настройках, правленных на ходу, могло остаться что-то лишнее, и перезагрузка сняла вопрос. ## После спада Самая показательная реплика кризиса прозвучала, когда всё уже работало. Конечный клиент докупил 6 CPU и 40 ГБ памяти, а инженер бюро в тот же вечер написал: «память пусть обратно вдвое урезают, до 32G. Процы пока я бы так оставил, понаблюдать день-два — если всё ровно, тоже пусть вернут 18 как было». Мы зарабатываем на часах работы, а не на чужом железе: оставить заказчику лишние расходы было бы проще, но нечестно. Студия решила понаблюдать неделю и передала рекомендацию клиенту. Что ещё осталось после кризиса: - точечный тюнинг MySQL по итогам диагностики самого Битрикса — по тем параметрам, которые он сам помечает как узкие; - работающая ротация логов, с перепроверкой на следующий день: первый прогон «не сработал, хотя лог утверждал обратное»; - письменно зафиксированные долги: CentOS 7.8 сильно устарел, диски надо менять на NVMe, а MySQL «вдумчиво потюнить, а не на скорую руку поправить явные ошибки». ## Результаты Метрика Значение Активный кризис 2 дня (25–26 февраля), хвост с обменом 1С — 27 февраля Причин найдено и закрыто 4: антивирус панели · опечатка в конфиге БД · деградация дисков · вялотекущий DDoS Ресурсы сервера заказчик докупил память и CPU — половину памяти мы сами предложили вернуть, когда кризис прошёл Трудозатраты за февраль на сайт 11.25 ч по трекеру, из них 6.5 ч — два пиковых дня Если коротко: магазин вернулся к прежней скорости ещё в сезон, скрипт автобана остался дежурить на сервере, а из докупленных ресурсов половину мы сами предложили вернуть. Список долгов сервера (диски, ОС, глубокий тюнинг БД) передан заказчику письменно, без нагнетания и без «давайте всё переделаем». ## Команда - **Инженер-сисадмин (бюро)** — диагностика, восстановление, скрипт автобана, вся работа на сервере - **Антон Херсун, Xaver Pro — руководитель проекта** > Если ваш магазин ложится в самый сезон, а причин, похоже, больше одной — пришлите бриф или текущую техническую документацию. Мы посмотрим, выделим узкие места, вернёмся с фиксированной оценкой в часах. Срочный разбор бесплатный. [Разобрать аварию →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-mysql-indexes-bitrix-filter-3500x/ title: Два индекса MySQL — фильтр быстрее в 3500 раз за один час type: case_study date: 2026-06-07T13:49:38+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Тяжёлый Битрикс-каталог умирает предсказуемо. Умный фильтр строит запросы к таблице свойств на сотни тысяч строк, подходящих индексов нет, CPU уходит в полку. Снаружи это выглядит как атака. Иногда это и есть атака — но её не разглядеть, пока выключен access-лог. В этом кейсе сошлись обе причины сразу, и обе закрылись за один оплаченный час. ## Сводка Отрасль конечного клиента интернет-торговля (магазин на 1С-Битрикс) Конечный клиент интернет-магазин в соседней стране (название под NDA) **Формат сотрудничества** **абонентская DevOps-поддержка digital-студии; этот сервер — вне её парка, работа по запросу** Тип проекта аварийная диагностика производительности MySQL Объём работ включение access-лога nginx · профилирование запросов · 2 индекса MySQL **Дата проекта** **30 окт 2025 (1 день)** Трудозатраты 1 ч из 1 ч оценки Команда 3 специалиста (инженер · инженер-сисадмин · руководитель проекта) Технологический стек 1С-Битрикс · MySQL · nginx · Apache httpd · CentOS 7 **Сдано** **запросы фильтра: с 15–30 с до менее секунды; атакуемый раздел найден по включённому логу** ## Постановка задачи Днём 30 октября менеджер студии пишет в чат поддержки: «можете чекнуть сайт — оч долго грузится или вообще не открывается». Речь про Битрикс-магазин конечного клиента в соседней стране. Сервер старый, на CentOS 7, в парк студии не входит: бюро касается его только по прямому запросу. Руководитель направления студии заглянул на сервер сам и упёрся в стену. База выедает процессор, а смотреть не во что: access-лог nginx час как не пополняется, в логе httpd вместо реальных адресов посетителей — адрес прокси. Основной инженер бюро по этому направлению ответил честно: «Я в дороге, вечером только…» Для магазина «вечером» — потерянный день продаж. В 13:07 студия спросила: «кто-то может глянуть?» В 13:13 руководитель проекта бюро подключил второго инженера. В 13:20 тот уже запрашивал доступы: час с минутой от первого сообщения менеджера. ## Что в этом сложного Страшный сценарий для агентства, отвечающего перед конечным клиентом, выглядит ровно так: единственный инженер подрядчика едет в поезде, магазин лежит, сервер чужой. Ни мониторинга, ни истории конфигурации, ни даже root-пароля MySQL под рукой. Пароль пришлось сбрасывать по ходу. Диагностика начинается вслепую: логи выключены, и тяжёлый легитимный трафик не отличить от атаки. Подрядчик из одного человека в такой день бессилен, каким бы сильным этот человек ни был. Бюро закрывает это преемственностью внутри команды: направление ведёт один инженер, но на эскалации в течение часа в дело вступает второй. ## Как мы это сделали **1. Включили access-лог nginx.** Лог оказался выключен, причём в конфиге стоял комментарий, что это стандартная настройка Битрикса. Экономия дискового ввода-вывода? Может быть. Слепота при любом инциденте? Гарантированно. Инженер вернул строку `access_log /var/log/nginx/access.log common;` в `nginx.conf`. Эта строчка сыграет в кейсе дважды. **2. Нашли виновника в плане запроса.** Профилирование MySQL показало: фильтр по брендам гоняет запросы к `b_iblock_element_property`, стандартной таблице свойств Битрикса, в которой здесь лежало 530 тысяч записей. Подходящего индекса не было. Стоимость запроса по оптимизатору — 538 080, время выполнения 15–30 секунд. Несколько таких запросов параллельно, и CPU держится на 90–100%. **3. Добавили два индекса.** ``` `-- поиск по свойству бренда ALTER TABLE b_iblock_element_property ADD INDEX idx_brand_opt (IBLOCK_PROPERTY_ID, VALUE(10)); -- связь разделов и элементов ALTER TABLE b_iblock_section_element ADD INDEX idx_section_element_opt (IBLOCK_SECTION_ID, IBLOCK_ELEMENT_ID);` ``` `VALUE` в таблице свойств — текстовое поле, поэтому индекс префиксный: первых десяти символов хватает для селективности по бренду, а индекс остаётся компактным. Стоимость запроса упала с 538 080 до 154 — в 3500 раз. Время выполнения: меньше секунды. **4. Честно сказали: CPU всё ещё высокий.** Запросы ускорились, а нагрузка не ушла. Анализ трафика показал поток, похожий на легитимный; признаков DDoS инженер не увидел и предложил добавить серверу 2 ядра. **5. И тут второй раз сработал включённый лог.** Руководитель направления студии, получив наконец живой access-лог и наводку «весь шум — вокруг брендов», сам нашёл аномалию: основной трафик шёл на раздел `/brands`, на который нет ни одной ссылки на сайте. Заблокировал раздел — процессор пришёл в норму. Из чата: «Похоже все таки на атаку… Заблокировал его, ЦП пришло в норму. Спасибо за наводку с брендами, и что починили логи». Дополнительные ядра не понадобились. Вывод «DDoS не обнаружен» оказался преждевременным. Это честная часть истории. Но рабочий лог плюс найденный вектор по брендам дали студии ровно ту зацепку, по которой она через 26 минут после нашего отчёта закрыла атаку своими руками. От первого сообщения менеджера до «ЦП пришло в норму» — 3 часа 10 минут календарных. В трекере 1.0 часа: столько инженер реально провёл на сервере, и ровно столько стояло в оценке. ## Результаты Метрика До После Стоимость запроса фильтра (оптимизатор MySQL) 538 080 154 Время запроса фильтра брендов 15–30 с менее 1 с Загрузка CPU 90–100% норма — после блокировки `/brands` клиентом access-лог nginx выключен («дефолт Битрикса») включён, остаётся для анализа Подключение второго инженера — в течение часа от первого сообщения Трудозатраты — 1.0 ч по трекеру (оценка 1.0 ч) Простыми словами: магазин снова открывается меньше чем за секунду, сервер видит свой трафик, а у студии в руках инструмент, которым она в тот же день сама закрыла атаку. Расширение сервера, которое уже ушло на согласование, не потребовалось. ## Команда - **инженер (бюро)** — диагностика MySQL, индексы, access-лог; подключился по эскалации - **инженер-сисадмин (бюро)** — основной инженер направления; в день инцидента в дороге, вернулся к вечеру - **Антон Херсун, Xaver Pro** — руководитель проекта; эскалация на второго инженера за 10 минут > Если каталог на Битриксе встаёт под фильтрами или нагрузка на CPU не объясняется трафиком — пришлите описание симптомов. Посмотрим планы запросов, назовём узкое место и вернёмся с фиксированной оценкой в часах. Разбор планов запросов бесплатный. [Ускорить каталог →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-nextcloud-migration-400gb-infected/ title: Перенос заражённого NextCloud: 400 ГБ без докера за 7 часов type: case_study date: 2026-06-07T13:49:37+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Внутреннее файловое хранилище — инфраструктура-невидимка. Пока оно живо, о нём не вспоминают: разработчики заливают туда дампы сайтов, скрипты бэкапов кладут архивы, все при деле. Вспоминают, когда хранилище начинает падать. У переноса такого сервиса всегда два встречных требования: данных много, окно простоя маленькое. Здесь добавилось третье. На старом сервере жил зловред, которого нельзя было взять с собой. ## Проект одним взглядом Отрасль конечного клиента digital-агентство / веб-студия Конечный клиент студия с парком из 12+ VDS, Россия (под NDA) **Формат сотрудничества** **абонентская DevOps-поддержка, прямой договор** Тип проекта перенос внутреннего облака NextCloud с заражённого сервера на чистый Объём работ ~400 ГБ файлов + база + все учётные записи; обновление через 5 мажорных версий **Дата проекта** **10 июн 2024 – 4 сен 2024 (86 дней; активный перенос — ночные окна 23 авг – 2 сен)** Трудозатраты 7 ч по трекеру; ещё 6 ч — сопровождение до версии 32 в 2024–2025 Команда 2 специалиста (инженер-сисадмин · руководитель проекта) Технологический стек NextCloud 24→29 · PHP · MySQL (utf8mb4) · occ CLI · Zabbix **Сдано** **облако на новом сервере без докера, NextCloud 29, домен переключён, бэкапы и планировщик перенастроены, старый сервер выведен** ## Постановка задачи Облако NextCloud у студии — рабочий инструмент, а не архив. Туда ежедневно заливаются свежие бэкапы клиентских сайтов, чтобы разработчики могли развернуть любой проект локально. И на этом же сервере поселился вирус, которого прошлый администратор «не смог выкорчевать»: процессы периодически съедали ЦП, облако уходило в недоступность, рабочая практика свелась к «перезапускаем VDS и обычно норм». Однажды после такого перезапуска облако вернулось пятисотой ошибкой. Запрос клиент сформулировал сам, прямо в задаче трекера: бороться с вирусом «долго, больно и дорого», проще развернуть на новом сервере последнюю версию NextCloud и перенести туда пользователей и файлы. Два жёстких условия. Первое: без докера. По словам бывшего админа, зараза залетела именно через контейнеры. Второе, дословно: «Главное чтобы вирусняк не перекочевал на новый сервер вместе с файлами». Самое неприятное в таких переносах — не объём, а сочетание. 400 ГБ на канале в 11 МБ/с — это 11 часов копирования, и всё это время хранилищем кто-то хочет пользоваться. Выключить облако на сутки нельзя: разработчики останутся без развёртывания проектов. Скопировать «наживую» и переключить тоже нельзя: потеряются файлы, залитые во время копирования. А притащить вместе с данными старый исполняемый код — значит перевезти и вирус, ради избавления от которого всё затевалось. Любой из трёх промахов превращает плановую работу в инцидент. ## Как мы это сделали **1. Новый сервер вместо лечения. Мы сами это рекомендовали, а не расписались в бессилии.** Выкорчёвывать зловреда из работающей системы можно бесконечно: часы уходят, а гарантии, что вычистили всё, нет. Чистый сервер с переносом данных стоит предсказуемо и закрывает вопрос целиком. Пока клиент покупал сервер, старый дотянули костылём. В системный скрипт добавили автоматическое убийство процессов `find`, когда их накапливалось больше пяти: именно они загоняли сервер в высокий load average. 15 минут работы, и облако дожило до переноса без аварий по вине вируса. **2. Со старого сервера — только данные, ни байта кода.** На новом сервере NextCloud развернули прямо в систему, из чистого дистрибутива последней версии: без контейнеров, на обычном PHP с MySQL (база пересоздана с нуля, utf8mb4). Со старой машины переехали ровно три вещи: директория `data`, `config.php` и дамп базы. Исполняемый код, главный подозреваемый в заражении, на новый сервер не попал вовсе. **3. Ночные окна вместо «большого переключения».** Копирование 400 ГБ запустили вечером после согласования; самое длинное окно — 11 ч 56 мин, и эта цифра была названа клиенту заранее, вместе с арифметикой: 11 МБ/с × 400 ГБ ≈ 11 часов. К 8 утра старое облако включалось обратно. Днём разработчики работали как обычно. Финальную синхронизацию базы провели отдельным вечером, после чего старое облако перевели в режим обслуживания, чтобы база не расходилась, пока команда переезжает на новый адрес. **4. Ступенчатое обновление 24 → 25 → 26 → 27 → 28 → 29.** План «поставим последнюю версию и подсунем старую базу» разбился о факт: NextCloud не обновляется с перескоком мажорных версий. Выяснили на месте, перестроились за вечер: прошли все 5 ступеней через `occ` из консоли, с проверкой клиента после первой. На версиях 28/29 платформа отключила 8 несовместимых приложений (calendar, contacts, deck, groupfolders, notes и другие). Полный список мы сразу отправили клиенту, не дожидаясь вопросов. Проверка с той стороны: «Доступы сохранились, файлы отображаются, скачиваются». **5. Root у разработчиков отобрали — взамен дали ровно одну команду.** После переноса клиент попросил убрать у разработчиков root-доступ к облачному серверу. Сделали отдельного пользователя с правами только на одну папку данных и sudo-обёртку, которая запускает единственную команду: `occ files:scan` по конкретному пути. Скрипты заливки бэкапов работают, доступа к чужим файлам и к дереву NextCloud нет. 1,5 часа, закрыто за два дня. ## Результаты Метрика Значение Перенесено данных ~400 ГБ + база + все учётные записи Версия NextCloud 24 → 29 за один заход; в сопровождении — до 32 Простой в рабочие часы ночные окна по согласованию; к 8 утра облако включалось Самое длинное окно 11 ч 56 мин (плановое, цифра названа заранее) Часы по трекеру 7 ч — перенос; 1,5 ч — доступ без root; 4,5 ч — обновления до 32 Контроль после переноса проверка клиентом: учётки на месте, файлы открываются и скачиваются Вирус остался на старом сервере; сервер погашен и списан Если коротко: облако переехало на чистый сервер, поднялось на 5 мажорных версий и продолжило работать днём всё время переноса. Зловред остался на старой машине. Её подержали неделю выключенной на случай, если что-то забыли, и снесли. С тех пор облако живёт без докера и обновляется штатно. Хвост сопровождения — отдельная часть истории. В марте 2025 обновление до 31-й версии потребовало поднять PHP с 8.2 до 8.3; веб-обновлялка падала на стадии бэкапа, так что прошли через консоль в согласованные выходные. По пути отвалились тема оформления и один плагин кэша. Оба факта клиент узнал из отчёта, а не из жалоб пользователей. Там же — фраза, которую редко услышишь от подрядчика, закрывающего задачу: «stable — это 30 версия, 31 — это beta, так что учтите, возможны странности». В октябре 2025 облако доехало до 32-й. Итого с момента переноса: 24 → 32, без потерь и без авралов. ## Процесс Фаза Когда Результат Диагноз и костыль 10–13 июн 2024 старый сервер стабилизирован до переноса: авто-убийство лишних `find` (0,25 ч) Подготовка нового сервера 23 авг чистый дистрибутив NextCloud, без докера (0,5 ч) Ночное копирование 26–27 авг 400 ГБ перенесены за ночь, днём облако работало (1,5 ч) Перенос БД, обновление до 25 27–28 авг облако живёт на новом сервере, клиент проверил файлы и доступы (1,5 ч) Обновление до 29 29 авг 4 мажорные версии за вечер, отчёт об отключённых приложениях (1 ч) Финиш 31 авг – 4 сен бэкапы, почта, планировщик, сертификат, переключение домена, старый сервер в shutdown (2,25 ч) Хвост сопровождения сен 2024 – дек 2025 доступ без root для разработчиков; обновления 29→30→31→32 (6 ч) _Между постановкой задачи (10 июня) и активным переносом прошло два месяца: клиент покупал сервер и согласовывал приоритеты, старое облако в это время держал наш костыль. Сумма часов меньше календаря, потому что вся работа шла короткими ночными и вечерними окнами вокруг живого сервиса._ ## Команда - инженер-сисадмин (бюро) — перенос, ступенчатые обновления, sudo-доступ, сопровождение до версии 32 - руководитель проекта (бюро) — согласование окон, контроль часов в трекере - на стороне клиента — руководитель направления: проверка после переноса, DNS, приоритеты > Если у вас тоже живёт сервис, который страшно трогать (заражённый, отставший на несколько мажорных версий или работающий в режиме «перезапустили и норм»), пришлите бриф или текущую техническую документацию. Мы прикинем объёмы, каналы и окна переноса и вернёмся с фиксированной оценкой в часах. Оценка переноса бесплатна. [Обсудить перенос →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-server-park-audit-12-vds-first-month/ title: Чужой парк из 12 VDS: аудит за 6 часов, порядок за месяц type: case_study date: 2026-06-07T13:49:37+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Самое опасное в чужом парке серверов — не то, что в нём сломано. Сломанное видно. Опасно то, о чём никто не помнит: правило фаервола, добавленное «на ходу» и не сохранённое, swap, вписанный в fstab с ошибкой, самописный конфиг nginx, который живёт только в голове ушедшего админа. Поэтому приём парка мы начинаем не с починки, а с описи — и только потом трогаем боевое. Этот кейс — про первый месяц такой работы: как незнакомые 12 VDS со стабильным фоном аварий стали парком, где у каждого сервера есть страница в wiki, у каждой работы согласованное окно, а у мониторинга — человек, который на него отвечает. ## Снапшот Отрасль конечного клиента digital-агентство, разработка интернет-магазинов на Битрикс Конечный клиент веб-студия «Медиастудия», Россия **Формат сотрудничества** **прямой контракт ИП↔ИП: 3 месяца с пролонгацией, подписан по ЭДО** Тип проекта приём парка на поддержку: аудит, первая волна наведения порядка, постановка процесса Объём работ 12 VDS, из них 4 под внутренние сервисы студии (GitLab, облако, бэкапы, мониторинг) **Дата проекта** **4 июн 2024 – 26 июл 2024 (53 дня)** Трудозатраты 11,25 ч по пяти задачам трекера Команда 3 специалиста (руководитель проекта · инженер-сисадмин · инженер) Технологический стек CentOS 7 / Ubuntu · ISPmanager · MariaDB 10.4 · nginx · Apache httpd · Zabbix 6.4 · fail2ban **Сдано** **аудит всех 12 VDS с wiki-описаниями, обновлённый парк, мониторинг в общем чате, регулярный цикл обновлений как процесс** ## Постановка задачи К нам пришла веб-студия: Битрикс, немного Laravel, десятки клиентских сайтов и 12 VDS у одного хостера. Прежний админ ушёл, документации нет. Запрос техлид сформулировал честно: «Условно раз или два в неделю что-нибудь стабильно падает или ломается. То база решит сама перезапуститься по какому-то там своему таймеру, то озу закончится, то боты на сайт придут». Свой Zabbix у студии был и выдавал от 1 до 12 алертов в день. Хотели четыре вещи, и мы приводим их в формулировке клиента: наладить стабильность, оперативнее реагировать на проблемы, регулярно ставить обновления безопасности, выполнять серверные работы по запросу. Выбирали из трёх компаний. Решение дозрело ещё до договора: у студии упала сеть на железном сервере, и мы откликнулись за минуты. Клиент успел починить сам, поправив MAC-адрес, и написал в чат: «можно мне к вам лучше?» Через неделю договор ушёл по ЭДО. У техлида студии при такой передаче два страха, и оба обоснованны. Первый: подрядчик начнёт «наводить порядок» широкими мазками и уронит боевые магазины, которые годами работали на недокументированных костылях. Второй, противоположный: подрядчик утонет в аудите и месяцами не сделает ничего осязаемого. Балансировать пришлось на живом парке, где каждая перезагрузка по определению лотерея: никто ещё не знает, что именно на этом сервере не переживёт ребут. ## Как мы это сделали **1. Аудит со счётчиком времени, а не «исследование».** Прошли все серверы по списку: примерно 30 минут на машину, 6 часов на парк. Оценку скорректировали публично, прямо по ходу работ: после шести описанных серверов стало ясно, что в исходные 4 часа не уложимся. На каждый сервер завели страницу в wiki, на выходе собрали документ рекомендаций: swap, единый лог, fail2ban, бэкапы. Дальше клиент сам нарезал из этого документа задачи в трекере — каждая ссылается на аудит, ничего не делается «по памяти». **2. Чужой мониторинг вместо своего.** У студии уже был Zabbix: строить параллельный означало бы потратить часы и получить два источника правды. Вместо этого бот клиента подключили в общий рабочий чат и сразу договорились об алерт-гигиене: только важные и критические триггеры, и только по серверам, а не по каждому сайту. Иначе один упавший сервер с полусотней сайтов засыпает чат полусотней сообщений. «Ок, давайте пока критические». С этого дня аварии и реакции на них видят обе стороны, в одном месте, с отметками времени. **3. Обновление парка как процедура, а не подвиг.** Клиент исходил из получаса на сервер и предлагал резать парк на группы: иначе 6 часов, весь месячный бюджет. Мы предложили другое: согласованное окно, на связи дежурный с доступом к консоли хостера («при обновлении всегда есть шанс, что сервер не вернётся из ребута») и весь парк за один заход. Десять серверов из согласованного списка обновили за 1,75 часа; облако сознательно не трогали до переноса, а GitLab обновлял другой инженер в рамках отдельной задачи. В задачу легли выгрузки обновлённых пакетов по каждому серверу: MariaDB, zabbix-agent, ядро. Заодно обновление вскрыло на центральном сервере PHP 7.2 с истёкшим сроком поддержки (с ноября 2020). Риск зафиксировали письменно. **4. Первая волна порядка — точечно, по рекомендациям аудита.** Swap добавили везде, где его не было, и везде одинаково, по одному и тому же пути. А вот от переразметки в отдельный раздел отказались вместе с клиентом: это VDS, загрузиться с live-cd не выйдет, и файла достаточно. На всех серверах с панелью собрали единый access-лог nginx, сохранив логи пользователей по их сайтам: теперь ботов и DDoS видно одним tail. Самое благодарное — магазин, где БД раньше падала «по два-три раза в день»: нашёлся swap, вписанный в fstab с ошибкой и не подключавшийся после ребута, буфер MySQL срезали с 4 до 3 ГБ под реальную базу около 3 ГБ, а наполовину настроенный nginx-кэш довели и поставили TTL в одну минуту: «тут задача именно всплески сгладить, а не всё закэшировать». Девять дней наблюдения, ни одного падения — задачу закрыли. **5. Процесс — с первого месяца, по живым прецедентам.** Правила не писали заранее — их фиксировали после первого же столкновения. Низкоприоритетная задача съела часы, нужные на обновления? Договорились: работы идут строго по приоритету клиента или по согласованию, а сделанное вне плана можно перенести в следующий счёт. Redmine неудобен для обсуждений? Чат — для обсуждения, трекер — для фиксации факта, оценки и часов; задачи после обсуждения заводим мы, с пометкой клиента «согласовано». Антивирусный скан клиентского пользователя 20 минут грузил CPU всем соседям? Предложили внести в договор право убивать процессы, мешающие другим клиентам: эту практику принесли с собственного хостинга. К концу июля клиент попросил главное: «чтобы мне не нужно было самому вспоминать, что нам нужно обновить серваки». Завели регулярную ежемесячную задачу — с тех пор обновления идут циклами, без напоминаний. ## Что пошло не так Без этого раздела кейс был бы неправдой. При настройке единого лога инженер затёр правленные вручную nginx-конфиги с проксированием, и статика одного сервиса начала отдавать 404. Клиент заметил минут через десять, ещё примерно столько же ушло на починку. Дальше — работа над причиной, а не над симптомом: эти конфиги внесли в wiki, проверили, что панель бэкапит весь /etc (полностью раз в неделю, изменения ежедневно). Второй эпизод поймал сам мониторинг: после ребута один сервер пропал из Zabbix на 7 минут. Правило фаервола на порт агента когда-то добавили «на ходу» и не сохранили — перезагрузка его стёрла. Оба случая — ровно те мины, ради которых чужой парк сначала описывают и только потом перезагружают. Был и эпизод подлиннее: вечером после обновления центральный сервер держал LA выше 10, и около двух часов обе команды вместе искали виновника. Им оказался «призрачный» node-процесс давно удалённого с диска проекта: он жил в памяти до ребута, а после перезагрузки пытался стартовать заново и грузил CPU. Попутно базе подняли innodb_buffer_pool с 1 до 1,5 ГБ, а клиент сделал свой вывод: разносить проекты по разным пользователям. ## Результаты Метрика Значение Аудит парка 12 VDS, ~30 мин на сервер, 6 ч по трекеру, wiki-страница на каждый сервер Обновление парка 10 серверов за 1,75 ч — против 6 ч, которые закладывал клиент из расчёта 0,5 ч/сервер Вскрытые риски PHP 7.2 на центральном сервере (поддержка кончилась в 2020) — зафиксирован письменно БД проблемного магазина падала «по два-три раза в день» → 0 падений за 9 дней наблюдения, задача закрыта Мониторинг алерты Zabbix в общий чат: важные + критические, посерверно Процесс регулярная ежемесячная задача на обновления + правило приоритетов + право убивать процессы-вредители в договоре Трудозатраты периода 11,25 ч по трекеру Если коротко: за первый месяц незнакомый парк стал описанным, обновлённым и наблюдаемым. Фон «раз-два в неделю что-нибудь стабильно падает» не исчез по волшебству (боты никуда не делись, впереди ещё были переносы и миграции), но каждое падение теперь видели бот и инженер, а не клиент по жалобе конечного заказчика. И главное, у обновлений, перезагрузок и правок конфигов появился ритуал: окно, дежурный, отчёт. ## Процесс Фаза Длительность Результат Знакомство и договор 07.05 – 03.06 выбор из трёх подрядчиков, договор ИП↔ИП на 3 месяца с пролонгацией, ЭДО Аудит и мониторинг 04.06 – 06.06 12 VDS описаны в wiki, документ рекомендаций, Zabbix-бот в общем чате Первая волна порядка 10.06 – 20.06 парк обновлён за один заход, swap и единый лог везде, БД магазина стабилизирована Постановка процесса 14.06 – 26.07 правило приоритетов, фиксация задач в трекере, регулярная задача на ежемесячные обновления _Фазы перекрываются: правила процесса рождались из инцидентов первой волны, а договорённость о регулярных обновлениях созрела к концу июля, поэтому сумма фаз не равна календарю._ ## Команда - **Инженер-сисадмин (бюро)** — аудит, обновление парка, swap, единый лог, стабилизация БД - **Инженер (бюро)** — аудит, оценки, постановка процесса - **Антон Херсун, Xaver Pro** — руководитель проекта > Если вам достался парк серверов без документации и без прежнего админа — пришлите список машин и то, что о них известно. Мы посмотрим, выделим узкие места и вернёмся с фиксированной оценкой в часах. Аудит парка бесплатный. [Прислать список серверов →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-gitlab-15-to-18-two-years-zero-loss/ title: GitLab: с 15.4 до 18.11 за два года без потерь данных type: case_study date: 2026-06-07T13:49:37+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Самое тревожное в GitLab на своём сервере — не сами обновления, а то, что лежит внутри: вся кодовая база компании, все клиентские проекты, вся история. Обновлять страшно, поэтому инстансы годами стоят на старых версиях и копят уязвимости. У студии GitLab застрял на 15.4: к лету 2024 это было уже две мажорные версии назад. Мы провели его через цепочку обязательных промежуточных релизов и две миграции PostgreSQL за 5 часов, а потом два года держали на свежих патчах: критические — в день выхода. За это время случился один ночной отказ. О нём ниже, без купюр. ## Сводка Отрасль конечного клиента digital-агентство, разработка сайтов Конечный клиент «Медиастудия» (код-имя), Россия **Формат сотрудничества** **абонентская DevOps-поддержка парка из ~14 серверов** Тип проекта сопровождение GitLab на своём сервере: большая миграция + регулярные и срочные обновления Объём работ цепочка 15.4.2 → 17.2.1 с PostgreSQL 12 → 14; далее 9+ обновлений, из них 3 критических security-патча **Дата проекта** **10 июн 2024 – 29 мая 2026 (718 дней)** Трудозатраты ~10 ч за два года (большая миграция — 5 ч) Команда 3 специалиста (инженер · инженер-сисадмин · руководитель проекта) Технологический стек GitLab EE · PostgreSQL · CentOS 7 · AlmaLinux · Ubuntu 24 · Zabbix **Сдано** **GitLab 18.11.4, PostgreSQL 14.11, ноль потерянных репозиториев за весь период** ## Постановка задачи Студия ведёт десятки клиентских проектов, и весь код живёт в собственном GitLab на отдельном VDS. К моменту нашего захода на поддержку инстанс стоял на версии 15.4.2. Формулировка клиента в трекере: «установлен gitlab, который давно уже не обновлялся. Необходимо обновить его до последней версии, чтобы уменьшить риски взлома». Запрос простой на словах и неудобный на деле: обновить до последней версии, не останавливая работу. Разработчики пушат каждый день, поэтому любые окна — только после 18:00 по Москве или в выходные, с предупреждением команды. Что здесь на кону, любой техдиректор понимает без перевода: GitLab — это не сервис, который «полежит и поднимется». Это кодовая база агентства целиком. Прыгать с 15.4 сразу на актуальную версию GitLab не умеет: нужно пройти цепочку обязательных промежуточных релизов. По пути дважды мигрирует PostgreSQL: 12 → 13 → 14. Каждый шаг — это перезапуски, миграции схемы БД и шанс получить инстанс, который больше не стартует. Тестовой копии нет: репетировать негде, ошибаться нельзя. ## Как мы это сделали **1. Маршрут вместо прыжка.** Сначала разведка: `gitlab-rake gitlab:check`, сверка с официальным upgrade path, вопросы клиенту про раннеры и интеграции (своих CI-раннеров проект не держал — минус один риск). План зафиксирован в трекере до начала работ: промежуточные точки 15.4.6 → 15.11.13 → 16.x → 17.2.1, миграции PostgreSQL на заранее известных шагах. Клиент подтвердил объём письменно: «обновляемся до последней доступной версии, включая postgres». **2. Две страховки, не одна.** Перед стартом — бэкап встроенным инструментарием GitLab: 12 ГБ, плюс снапшот виртуалки у хостера. Вылезла деталь: в панели хостера нашлась галочка снапшота, но не нашлась кнопка отката. Выяснили это «на берегу», а не в момент аварии. Первый, самый рискованный переход сознательно перенесли на окно побольше: «перестрахуюсь. А то вдруг не апнется». Заодно настроили зеркало пакетов, чтобы обновления ставились без сюрпризов от недоступных репозиториев. **3. Проверка данных глазами клиента на каждом шаге.** После каждой ступени мы просили команду проверить то, что важно ей: вход, создание проекта, git pull и push. Инженер честно предупредил, что тоньше всего будет на переходе с 15-й ветки на 16-ю. Ответ клиента после первых ступеней: «жалоб по работе с гитлабом пока ни от кого не было». Простои на перезапусках укладывались в 1–3 минуты, мониторинг фиксировал каждый. **4. Security-патчи — в день выхода, по нашей инициативе.** Дальше пошла рутина, и в ней главное — скорость. 17.3.3: задачу завели и закрыли в один день, 0.5 ч. 17.4.2: «критическое. там прям сообщение в гите лезет что срочно обновитесь». Согласовали окно после 18:00, вечером готово, 0.25 ч. 17.7.7: «ибо уязвимости», 0.5 ч. Все три раза клиент не просил: бюро само мониторит анонсы и приходит с готовым предложением. Плановые версии (17.5.1, 17.6.1, 17.7.6) ехали в составе ежемесячных циклов обновления парка. **5. Потолок — письменно, заранее, с вариантами.** В марте 2025 инженер зафиксировал прямо в задаче: «ни 17.8 ни 17.9 под 7 центос — нет. когда 17.7.x кончатся — надо будет смотреть в сторону конвертации в 8-9 AlmaLinux или новый сервер подымать». Никакого нагнетания, просто факт с развилкой и временем подумать. В ноябре добавили референс из практики: у другого клиента бюро та же конфигурация, конвертация в Alma с обновлением GitLab заняла 4 часа через 4 обязательные промежуточные точки. ## Ночь, когда сервер не вернулся из ребута Ещё в июле 2024, договариваясь о регламенте обновлений, инженер написал клиенту: «при обновлении всегда есть шанс, что сервер не вернётся из ребута». Поэтому на каждое окно нужен дежурный с доступом к консоли. Полтора года спустя фраза сработала буквально. Ночь на 29 января 2026, плановое окно ежемесячного обновления. Инженер решает заодно закрыть долг по GitLab: конвертация CentOS 7 → AlmaLinux 8, поверх неё — обновление до актуальной версии. Хронология по чату (время московское): - **03:29.** Мониторинг: главная GitLab не отвечает, «No route to host». - **03:50.** Инженер в чате: «сервер из перезагрузки не вернулся… требуется доступ к консоли или хотя бы скрин». И сразу следом: «дёргать ребуты/ресеты не надо». - **03:55.** Руководитель направления (клиент) уже у консоли: диск заполнен под завязку. Инженер: «я ж смотрел — 20 гиг свободных было», и df из истории команд это подтверждает. Место съела сама конвертация. - **03:57.** Решение: Ctrl-Alt-Del через консоль, без жёсткого ресета. - **03:58.** Сервер поднялся, GitLab отвечает. От первого алерта до восстановления — 29 минут. Данные целы, конвертация не прошла, GitLab остался на прежней версии. Ежемесячное обновление остальных серверов инженер доделал той же ночью, к 04:22. А дальше — разбор, и он важнее самой аварии. Клиент резонно спросил: «мы ж не договаривались ещё на конвертацию». Выяснилось, что согласование развалилось на цитировании в чате: инженер спрашивал про обновление GitLab, клиент отвечал «принято, спасибо» на реплику, которую читал как напоминание о ежемесячном цикле. Никто не соврал: стороны прочли один диалог по-разному. Инженер закрыл тему без оправданий: «понял, буду выражаться яснее». Клиент — зеркально: «лучше явно писать, о чём речь». Стоимость урока: 29 минут ночного простоя и 1.5 ч работ. С тех пор рискованные работы называются в чате своими именами, а не угадываются из контекста. ## Финал: переезд — силами клиента, сопровождение — наше Конвертацию на месте после той ночи больше не пробовали: победил вариант с новым сервером. В апреле 2026 команда клиента сама перенесла GitLab на свежий сервер с Ubuntu 24 и обновила его. Это их работа, и мы её себе не приписываем. Показательно другое: за два года совместной эксплуатации клиентская команда насмотрелась на процесс настолько, что провела переезд без нас. Мы продолжили сопровождение уже на новой площадке и в мае 2026 обновили GitLab до 18.11.4 за 0.75 ч, в общем цикле с остальным парком. ## Результаты Метрика Значение Версия GitLab 15.4.2-ee → 18.11.4 PostgreSQL 12.10 → 14.11 (две миграции по пути) Большая миграция 15.4 → 17.2 5 ч работ, плановые окна по 1–3 мин Критические security-патчи 3 за период, каждый в день выхода, 0.25–0.5 ч Инцидент за два года 1 (конвертация ОС), восстановление за 29 мин, данные целы Потери репозиториев / данных 0 — жалоб от разработчиков не зафиксировано ни на одном шаге Трудозатраты на GitLab за весь период ~10 ч Если коротко: система, на которую два года боялись смотреть, прошла через две мажорные версии, две миграции БД, три срочных патча и один честно разобранный отказ — и каждый рабочий день разработчики студии пушили код как обычно. ## Процесс Фаза Период Результат Разведка и план миграции июнь 2024 upgrade path зафиксирован в трекере, объём согласован письменно Большая миграция 15.4.2 → 17.2.1 июль 2024 пройдена ступенями за 5 ч, PostgreSQL 12 → 14, проверки клиентом на каждом шаге Регулярные + срочные обновления сентябрь 2024 – декабрь 2025 17.3.3 → 17.7.7; критические патчи в день выхода; потолок CentOS 7 зафиксирован письменно Инцидент конвертации ОС январь 2026 восстановление за 29 мин, разбор коммуникации, отказ от конвертации на месте Переезд на Ubuntu 24 апрель 2026 выполнен силами клиента; бюро — сопровождение на новой площадке Текущее состояние май 2026 GitLab 18.11.4, в общем цикле ежемесячных обновлений _Фазы перекрываются с остальной абонентской поддержкой: GitLab — одно из направлений внутри общей абонентки, а не отдельный контракт._ ## Команда - **Инженер (бюро):** большая миграция 15.4 → 17.2, миграции PostgreSQL - **Инженер-сисадмин (бюро):** регулярные и срочные обновления, инцидент и восстановление - **Антон Херсун, Xaver Pro** — руководитель проекта > Если ваш self-hosted GitLab тоже застрял на версии, которую страшно трогать, — напишите, какая стоит сейчас и на какой ОС. Мы сверим upgrade path, найдём узкие места вроде миграций PostgreSQL и потолка дистрибутива, вернёмся с фиксированной оценкой в часах. Разбор плана обновления бесплатный. [Разморозить GitLab →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/startmedia-broken-xlsx-crlf-two-byte-diagnosis/ title: Диагностика на два байта: баг семи месяцев за один вечер type: case_study date: 2026-06-07T13:49:37+00:00 case_industry: Межотраслевые case_type: Серверное сопровождение case_practice: engineering --- Есть класс багов, которые живут месяцами именно потому, что они ничьи. Разработчики смотрят в код: код чистый. Админы смотрят в сервер: сервер отдаёт файлы как положено. Баг сидит на стыке и пересиживает обоих. Здесь таким стыком оказались два байта. ## Сводка Отрасль конечного клиента детский отдых: сайт лагеря с онлайн-заказом путёвок Конечный клиент клиент студии; админка отчётов по сменам **Формат сотрудничества** **абонентская DevOps-поддержка студии: трекер + общий чат** Тип проекта диагностика прикладного бага на стыке кода и сервера Объём работ 1 сервис отчётов (Yii 2 / PHP 7.4), 1 сервер (nginx + Apache) **Дата проекта** **5 сен 2024 – 11 сен 2024 (6 дней)** Трудозатраты 1 ч по трекеру Команда 2 специалиста (инженер-сисадмин · руководитель проекта) Технологический стек Yii 2 · PHP 7.4 · nginx · Apache · dd / xxd / file **Сдано** **причина найдена за вечер: 2 лишних байта CRLF из кода; обходная отдача файлов работает с 11.09.2024** ## Постановка задачи В начале 2024 года студия перевезла сайты своего клиента, детского лагеря, с чужого хостинга на собственный сервер. После переезда в админке заказов сломалась одна функция: отчёты по сменам. Кнопка «сгенерировать документ» отдаёт Excel-файл, который не открывается. Тот же отчёт, сохранённый на диск сервера и забранный по FTP, открывается без единой ошибки. Запрос пришёл словами клиента, без прикрас: «Мы в коде не нашли никаких проблем, и складывается впечатление, что он портится где-то в момент скачивания в браузер. То ли nginx его коверкает при отдаче, то ли ещё чего. Сможете посмотреть, проанализировать?» К этому моменту проблема тянулась с февраля — семь месяцев. Сотрудникам лагеря выдали FTP-доступ, и отчёты они забирали вручную с сервера. Жить можно, работать неудобно. ## Что в этом сложного Такой баг дорог не часами работы, а тем, сколько он висит. Он не роняет сайт, поэтому никогда не попадёт в очередь срочных аварий. Разработчики проверили свою зону и честно ничего не нашли; на старом хостинге тот же код работал, значит «виноват сервер»; админ смотрит на сервер: сервер штатный. Каждый прав, а файл битый. Из этой точки у студии обычно два пути: переписывать выгрузку наугад или возить отчёты по FTP вечно. Тому, кто платит за поддержку, нужен третий: локализовать виновный слой за конечное, заранее понятное время. ## Как мы это сделали **1. Сначала факт, потом гипотезы.** Взяли два экземпляра одного отчёта: скачанный браузером и его близнец с диска сервера. Скачанный оказался на 2 байта длиннее. Отрезали эти 2 байта через `dd ... bs=1 skip=2` — и «битый» файл открылся. Утилита `file` подтвердила: усечённая копия — `Microsoft Excel 2007+`, оригинал — безликая `data`. Сами байты вытащили и посмотрели в `xxd`: `0d0a`. Это CRLF, перевод строки. Формулировка задачи сжалась с «где-то что-то портится» до «кто-то дописывает rn перед телом файла». **2. Слой-виновник искали контрольными отдачами, а не спорами.** Гипотезу про nginx (сжатие, правка ответа) инженер снял сразу, по опыту: ничего подобного nginx с телом ответа не делает, что и подтвердилось дальше. С Apache — та же история. Решающих тестов было два. Тот же код отдачи на соседнем проекте этого же сервера, но на PHP 8.2, вернул файл целым. А простой PHP-скрипт в три строки, который забирает готовый XLSX с диска и отдаёт его мимо фреймворка, вернул целый файл с той же самой площадки. Диск чист, веб-серверы чисты, PHP чист. Остался один подозреваемый — цепочка отдачи Yii. **3. Серия «не сработало» — тоже результат.** Параллельно разработчики студии проверяли точечные гипотезы. MIME-тип `application/zip` вместо xlsx — мимо. Слэш в `Content-Disposition` (полный путь вместо имени файла; нашли попутно, поправили): имя при скачивании стало нормальным, файл всё ещё битый. `sendFile()` вообще без ручных заголовков: битый. `auto_detect_line_endings` в настройках PHP — мимо. Каждый промах сужал круг: дело не в заголовках и не в конфигурации, CRLF впрыскивается где-то между отправкой заголовков и телом файла. **4. Решение выбрали по цене вопроса.** Можно было копать внутренности фреймворка на PHP 7.4 в поисках строчки, которая печатает лишний перевод строки. Вместо этого инженер предложил обход: отдельный скрипт-прокладка вне Yii, который по идентификатору забирает готовый файл с диска и отдаёт его браузеру, а интерфейс выдаёт ссылку на прокладку. И назвал вещи своими именами: «костыль, да. но работать будет». Через 5 дней разработчики подтвердили в чате: «Костылик рабочий))». Отчёты снова скачиваются из админки, FTP-карусель закончилась. ## Инциденты и реакция Простой — ноль. Диагностика шла на работающей админке: эксперименты гоняли на тестовой смене, не трогая боевые заказы, а выданный для проверки доступ инженер вернул в тот же день, сам напомнив: «доступ в админку можно убирать». Деструктивных действий на сервере не было вовсе: вся побайтовая хирургия делалась на копиях файлов. ## Результаты Метрика Значение Возраст проблемы к моменту обращения ~7 месяцев (с февраля 2024) Время до локализации слоя-виновника один вечер: взято в работу в 15:30, к 18:39 виновник определён Трудозатраты по трекеру 1 ч Физический размер дефекта 2 байта (`0d0a`, CRLF) перед телом XLSX Исключено слоёв диск → nginx → Apache → версия PHP → фреймворк Статус обходная отдача в работе с 11.09.2024, подтверждена разработчиками Простыми словами: семь месяцев сервис отдавал нечитаемые отчёты, и никто не мог сказать, чья это проблема. За один вечер вопрос закрылся: испорченные файлы отличаются от здоровых ровно двумя байтами, дописывает их код, а не сервер, и пока разработчики решают, чинить ли цепочку отдачи фреймворка, отчёты скачиваются через прокладку. У клиента студии снова работает админка. У студии — аргументированный ответ, что чинить дальше. ## Команда - **инженер-сисадмин (бюро)** — побайтовая диагностика, исключение слоёв, схема обходной отдачи - **руководитель проекта (бюро)** — параллельные гипотезы (сжатие nginx, `auto_detect_line_endings`), координация с разработчиками студии Проверки внутри кода вели разработчики на стороне клиента: диагностика шла в четыре руки, в одном чате, в один вечер. Антон Херсун, Xaver Pro — руководитель проекта. > Похожая история — файл «портится непонятно где», а сервис месяцами живёт на обходном пути? Пришлите описание симптомов. Посмотрим, назовём виновный слой и вернёмся с оценкой в часах. Разбор — бесплатно. [Запросить разбор →](https://xaver.ru/contact/) --- url: https://xaver.ru/case/analitiksert-server-support-2021-2026/ title: Серверное сопровождение как услуга: 4,5 года инфраструктуры под растущим B2B-продуктом type: case_study date: 2026-06-07T08:29:24+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Когда у заказчика нет своего сисадмина, серверы обычно живут по принципу «пока гром не грянет»: о железе вспоминают в день, когда база перестала помещаться в тариф, и решают уже в аварийном режиме. Осенью 2021-го платформа «Аналитика сертификатов» целиком помещалась на одном общем хостинге. К 2026 году это связка из основного сервера, отдельного сервера под ClickHouse, дочернего сервера вычислений и фермы парсинг-машин, с ежедневными бэкапами в S3 и мониторингом, который сам пишет в рабочий чат. Между этими двумя точками — ни одного переезда «на вырост»: каждый новый сервер появлялся, когда продукт упирался в потолок, и проходил короткое согласование с заказчиком. Этот кейс о том, как бюро держит серверы так, что клиент про них почти не думает. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Серверное сопровождение как услуга: ёмкость, бэкапы, мониторинг, аварийная реакция, профилактика** Тип проекта Инфраструктура внутренней B2B-платформы на всём жизненном цикле **Длительность** **октябрь 2021 — июнь 2026 (4,5 года без перерыва)** Эволюция Один общий хостинг (2021) → основной сервер + сервер ClickHouse + сервер вычислений + ферма парсинг-VPS (2026) Бэкапы От еженедельной выгрузки на FTP до ежедневных дампов всей базы в S3, пять копий Команда Антон Херсун (руководитель), инфраструктурная команда Технологический стек Linux, MySQL/MariaDB, ClickHouse, Redis, nginx + PHP-FPM, Grafana, S3 ## Постановка задачи Своего системного администратора у заказчика нет, и нанимать его под один продукт не имело смысла. При этом продукт живёт на серверах целиком: база, которая со временем перестала помещаться в прежние тарифы, ночные сборы данных из реестров, экспорты на миллионы строк, десятки активных пользователей каждый день. Упадёт сервер — встанет всё. Серверная часть с первого дня была зоной ответственности бюро: выбрать тариф, следить за местом и нагрузкой, делать бэкапы, поднимать упавшее, вовремя предлагать апгрейд. Требование к этой работе проще всего сформулировать от обратного: заказчик занимается продуктом и продажами, а про серверы вспоминает только в момент согласования очередного шага. Второе ограничение — деньги. Расходы на инфраструктуру согласуются, мощности «про запас» никому не нужны. Значит, каждый апгрейд должен опираться на цифры: упали, выросли, перестали помещаться. ## Как мы это сделали **1. Ёмкость добавлялась по факту, маленькими шагами.** Первые полтора года весь продукт жил на одном общем хостинге — и этого хватало. В марте 2023-го серия падений показала, что аналитика упирается в ресурсы: за ночь серверу добавили 8 ГБ оперативной памяти и ядро процессора, после чего «аналитик наконец не отваливается». В начале 2024-го разговор об апгрейде начался с вопроса заказчику «у вас увеличилось количество активных пользователей?», а через три недели закончился коротким «давайте увеличим» — счётчик к тому моменту показал 66 активных пользователей за день. Хостер потребовал проводить миграцию с полной остановкой, поэтому её поставили на день, когда никто не работает. В мае 2024-го аналитическая база ClickHouse переехала на отдельный сервер, чтобы тяжёлые запросы не толкались с продакшеном. Ещё раньше под тяжёлые преобразования данных появился дочерний сервер вычислений (подробности в кейсе об аналитике и отчётах). Точку в этой эволюции поставил январь 2026-го: переезд платформы на тариф «Премиум» с диском 200 ГБ. **2. Парсинг получил собственную ферму.** Летом 2022-го российские реестры закрылись от европейских прокси, и привычная схема сбора данных умерла за выходные. Дорогие прокси-сервисы покупать не стали. Бюро развернуло мини-ферму из дешёвых российских VPS: парсер работает с этих машин, а основной сервер разгружен. К ноябрю 2022-го ферма по отдельному ТЗ оформилась в три машины и переварила реестр аккредитованных лиц на 30 тысяч записей. Абонентская плата за мини-серверы с тех пор идёт отдельной строкой в ежемесячном счёте, и заказчик видит, из чего складывается его инфраструктура. **3. Бэкапы росли вместе с базой.** Весной 2022-го появилась первая система: автоматический еженедельный бэкап всей базы с выгрузкой на FTP — «если в базе происходят необратимые изменения или кто-то что-то удаляет по неосторожности». Когда дампы ClickHouse перестали помещаться на диск, под них согласовали сетевой HDD. К концу 2025-го схема доросла до ежедневных дампов всей базы в S3-хранилище с хранением пяти последних копий. Мотивация в чате сформулирована без канцелярита: «потерять такое сокровище во время сбоев было бы обидно». **4. Мониторинг сам сообщает о проблемах.** С июня 2025-го оба главных сервера наблюдаются в Grafana, а бот с алертами добавлен прямо в рабочий Telegram-чат заказчика. Сигнал вида «свободного места на диске меньше 3%» приходит туда же, где обсуждаются задачи, и обе стороны видят его одновременно. Раньше первым датчиком были жалобы пользователей, теперь автоматика чаще успевает первой. **5. Авария закрывается за часы.** В июле 2022-го у хостера упал DNS, и региональные офисы потеряли доступ к платформе. Через час после жалобы пользователи получили запасной вход — аварийный реверс-прокси через резервный сервер бюро, с честной пометкой «так делать не очень правильно, но в критичных случаях пойдёт». В январе 2023-го отвалился Redis: восстановили за полчаса. В ноябре 2023-го панель хостинга при смене параметров сервера сбросила настройки, и аналитика «умерла у всех»; подъём занял две минуты от сообщения, а причину закрыли системно: подняли таймауты PHP и nginx до 600 секунд под долгие поисковые запросы. В августе 2025-го посреди ночного сбора «база самоубилась и чудом восстановилась» — зависший парсер подняли за ночь, а сам инцидент стал аргументом для переезда на более мощный сервер, который заказчик наутро подтвердил словами «давайте планировать». **6. Правила вместо повторного тушения.** В мае 2022-го пользовательские экспорты распухли до десяти гигабайт, и место на диске кончилось в ноль. После чистки появилось правило, согласованное с заказчиком: экспорты хранятся три месяца, дальше удаляются. С апреля 2025-го профилактика оформлена в отдельный серверный абонемент обслуживания и защиты со счётом раз в квартал: регулярная проверка, обновление ПО, аудит. Сюжет о защите серверов, заражении криптомайнером и большой миграции января 2026-го вынесен в отдельный кейс о безопасности. ## Результаты Метрика Значение Непрерывность 4,5 года сопровождения; ни одна инфраструктурная авария не стоила продукту больше ночи Эволюция ёмкости Один общий хостинг → основной сервер, сервер ClickHouse, сервер вычислений, ферма парсинг-VPS Скорость аварийной реакции Redis за полчаса; подъём аналитики за две минуты; обход падения DNS хостера за час; восстановление после сбоя базы за ночь Бэкапы От еженедельной выгрузки на FTP до ежедневных дампов всей базы в S3, пять копий Мониторинг Grafana по двум главным серверам, алерты в рабочий чат заказчика За 4,5 года продукт вырос в разы по данным и пользователям, а инфраструктура шла за ним маленькими обоснованными шагами: ни одного апгрейда впрок, ни одного счёта за мощности, без которых можно было обойтись. Заказчик за всё это время ни разу не разбирался с серверами сам — каждое решение приходило к нему уже в виде короткого предложения с цифрами, на которое достаточно ответить «давайте». ## Процесс и хронология Период Что происходило с инфраструктурой 2021–2022 Весь продукт на одном общем хостинге; еженедельные бэкапы базы на FTP; после переполнения диска правило хранения экспортов 3 месяца 2022 Мини-ферма российских VPS под парсинг после блокировки европейских прокси; ферма из трёх машин по отдельному ТЗ; аварийный реверс-прокси при падении DNS хостера 2023 Кризис мощностей и ночной апгрейд (8 ГБ ОЗУ, +1 ядро); дочерний сервер вычислений; таймауты 600 секунд после инцидента с панелью хостинга 2024 Апгрейд тарифа под рост до 66 активных пользователей в день, миграция в нерабочий день; отдельный сервер под ClickHouse 2025 Серверный абонемент обслуживания и защиты поквартально; Grafana и алерты в рабочий чат; сетевой HDD под бэкапы ClickHouse; подъём базы за ночь и решение о переезде; ежедневные дампы всей базы в S3 2026 Переезд платформы на тариф «Премиум» с диском 200 ГБ (миграция описана в кейсе о безопасности) ## Команда - **Антон Херсун, Xaver Pro**, руководитель: серверная архитектура, согласование апгрейдов с заказчиком, аварийная координация. - **Инфраструктурная команда**: мониторинг, бэкапы, профилактика и обновления под руководством Антона. - Разработчики направлений (аналитическая панель, виджеты и парсеры) опираются на эту инфраструктуру: им достаются серверы, на которых код просто работает. Серверное направление все 4,5 года остаётся в одних руках. Когда у хостера падает DNS или ночью сбоит база, человеку, который это чинит, не нужно восстанавливать контекст — он сам эту инфраструктуру собирал, шаг за шагом. ## Скриншоты и материалы _Для этого кейса не критично: его суть в модели сопровождения и непрерывности, а не в визуальной составляющей._ > Если ваш сервер последний раз апгрейдили, когда он упал, а бэкап проверяли ещё раньше, пришлите конфигурацию. Скажем, что в ней не переживёт рост нагрузки вдвое, какие копии реально восстановимы и с чего начать мониторинг. Разбор ничего не стоит. [Прислать конфигурацию сервера →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-monthly-retainer-support/ title: Сопровождение B2B-платформы по абонементу: 4,5 года непрерывной работы, парсер как основа сервиса type: case_study date: 2026-06-07T08:29:24+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Платформа «Аналитика сертификатов» живёт за счёт чужих данных: она собирает сведения из государственных реестров России, Киргизии, Казахстана, Беларуси. Реестры регулярно меняют структуру, вводят лимиты, блокируют сбор, переезжают на новую инфраструктуру. Стоит парсингу встать — и через неделю аналитика устаревает, а вместе с ней дешевеет весь продукт. Заказчик сформулировал приоритет рано и коротко: «парсер — основа». Абонемент построен вокруг того, чтобы эта основа не падала. С первого ТЗ в октябре 2021-го и до сегодняшнего дня платформа ни разу не оставалась без присмотра. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение по абонементу: бесперебойный парсинг, мелкие доработки, реакция на инциденты, серверная защита, бэкапы** Тип проекта Непрерывная поддержка внутренней B2B-платформы **Длительность отношений** **октябрь 2021 — июнь 2026 (4,5 года без перерыва)** Что покрывает абонемент Работоспособность парсинга, накопленная мелочёвка, инцидент-реакция, мониторинг, серверный абонемент защиты, бэкапы Документированный поток мелких пакетов около 90 часов по 6 ТЗ-допзадач (2022–2023), плюс поток отдельных мини-правок Команда Антон Херсун (руководитель), разработчик аналитической панели, разработчик виджетов и парсеров, инфраструктурная команда Технологический стек Laravel + Horizon, ClickHouse, MySQL/MariaDB, ротация прокси, перебор номеров, Grafana-мониторинг, бэкапы в S3 ## Постановка задачи Большие ТЗ в этом проекте оформляются отдельно: платформа, отчёты, шаблоны, виджеты, архитектура базы. Но рядом с крупными задачами всегда течёт мелочь, из которой ТЗ не собрать. Реестр-источник сменил формат — парсер нужно подправить за ночь. Пользователь просит кнопку или новую сортировку: час работы. Внешний администратор портала по ошибке стёр интеграцию, и виджет надо поднимать немедленно. Сервер под нагрузкой, диск заполняется, пора апгрейдить тариф. Если каждую такую мелочь оформлять отдельным заказом, накладные расходы на документы и счета съедят больше, чем сама работа. Если копить молча и в конце месяца выставить «было всякое разное на много часов», заказчик перестанет доверять смете. Абонемент закрывает обе крайности: предсказуемая ежемесячная подписка покрывает фон, а всё, что выходит за неё, фиксируется явными часами. Главное, что заказчик покупает по абонементу, — уверенность. Парсинг работает каждый день, а любой сбой будет закрыт быстро, без отдельных переговоров на каждый случай. ## Как мы это сделали **1. Парсинг под постоянным присмотром.** За четыре с половиной года источники ломались десятки раз, и почти каждый случай закрывался в рамках абонемента, без отдельного ТЗ. Европейские прокси перестали пускать к российским реестрам — собрали мини-ферму российских серверов. Киргизия закрыла публичный реестр — перешли на сбор перебором номеров от последних известных. Федеральная служба сменила инфраструктуру и забанила парсер-машины: систему переписали на несколько машин в два потока с ротацией прокси. Переезд Казахстана на новый реестр обернулся сбором из 46 источников, а новогодние блокировки в Беларуси обошли через рабочий прокси с последующим досбором. Платформа всего этого почти не замечает: заделка успевает раньше, чем устаревают данные. **2. Мелочёвка копится и закрывается пакетом.** Договорённость по абонементу простая: одиночный час не превращается в отдельный счёт. В ноябре 2025-го заказчик попросил мелкую кнопку на час работы, и решение было такое: «подождём ещё немного, чего-нибудь появится на неделе, можно к концу периода всё саккумулировать или сделать в счёт аванса». Так уходит лишняя бюрократия. При этом часть мелких ролей и правок закрывается в день обращения: мини-роль «Сотрудник ТО+» была готова через несколько часов после запроса, а пакет июньских допзадач закрыли за день. **3. Дисциплина явной сметы там, где объём растёт.** Когда мелочи в 2022–2023 годах стали стабильным потоком, мы оформили его как ежемесячные пакеты допзадач: один документ `тзNN_допзадачи_<месяц>_<год>` с пронумерованными пунктами и общей оценкой. Суффикс `_согласован` в имени файла означает, что версия прошла обсуждение и зафиксирована; новые запросы идут уже в следующий пакет. Шесть таких пакетов дали около 90 согласованных часов — и ни одного спора по смете. Побочный эффект оказался полезным: повторяющийся тип запроса виден сразу и вырастает в отдельное крупное направление. Так случилось с парсингом иностранных реестров. **4. Реакция на инциденты за минуты и за ночь.** Скорость ответа и есть то, ради чего держат абонемент. Внешний администратор портала случайно стёр интеграцию виджета, заказчик потерял доступ в админку — на восстановление всей работоспособности ушло около двадцати минут от первого сообщения. Когда база «самоубилась и чудом восстановилась» посередине ночного сбора, парсер был поднят к утру, а сам инцидент стал поводом переехать на более мощный сервер. Бывало и тяжелее: после заражения сервера троян-майнером работы по очистке заняли втрое больше планового времени, и заказчик получил по итогам письменный отчёт об инциденте с разбором причин. **5. Защита нагрузки и уборка за пользователями.** Аналитики выгружали отчёты на миллионы строк и этим клали сервер. Ответ остался в продукте навсегда: ежедневная автоочистка экспортов старше 3 месяцев плюс лимит на размер выгрузки. Сюда же входят серверная защита и обслуживание отдельным абонементом со счётом поквартально, внешний мониторинг с алертами прямо в рабочий чат и бэкапы, которые за время проекта выросли от еженедельной выгрузки базы на FTP до ежедневного дампа всей базы в объектное хранилище. ## Результаты Метрика Значение Длительность непрерывного сопровождения 4,5 года (октябрь 2021 — июнь 2026) Бесперебойность парсинга Десятки смен формата и блокировок источников закрыты в рамках абонемента, без длительных простоев продукта Скорость инцидент-реакции Восстановление виджета за ~20 минут; подъём базы за ночь; письменный отчёт по инцидентам Документированный поток мелких пакетов ~90 часов по 6 ТЗ-допзадач, без споров по смете Защита и сохранность Серверный абонемент защиты, автоочистка экспортов и лимиты, бэкапы от еженедельных до ежедневных в S3 Продукт жив на 5-м году 66–79 активных пользователей еженедельно (статистика входов, весна 2026), нагрузка ровная, без признаков затухания Главный результат одной цифрой не выражается. За четыре с половиной года продукт ни разу не остался без поддержки, парсинг пережил каждую смену правил у источников, а заказчик ни разу не получил счёт-сюрприз: фон закрывает абонемент, всё сверх него идёт явными согласованными часами. ## Процесс и хронология Период Что закрывал абонемент 2021–2022 Старт сопровождения; еженедельные бэкапы базы; мини-ферма российских серверов после блокировки европейских прокси 2022–2023 Шесть ежемесячных пакетов допзадач (~90 ч); апгрейды сервера под рост нагрузки 2023 Бан парсер-машин источника — переписанная многопоточная система, 100% актуальность периода 2024 Переход реестров на сбор перебором; автоочистка экспортов и лимиты после перегрузки сервера; адаптация под смену инфраструктуры источников 2025 Серверный абонемент защиты (поквартально); внешний мониторинг с алертами; восстановление виджета за 20 минут; подъём базы за ночь; новый реестр Казахстана 2025–2026 Ежедневные бэкапы в S3; миграция на более мощный тариф; обход новогодних блокировок; перестройка сбора под новые лимиты реестра РФ ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта, постановка сметы по абонементу, инцидент-координация, инфраструктура. - **Разработчик аналитической панели** ведёт это направление с первого дня и до сегодня; любой модуль, написанный несколько лет назад, дорабатывается тем же человеком. - **Разработчик виджетов и парсеров** закрывает мелкие правки по своим зонам; часть последних работ по парсингу подхватил именно он. - **Инфраструктурная команда**: серверы, защита, мониторинг и бэкапы под руководством Антона. Принцип сопровождения простой: кто написал модуль, тот и закрывает по нему мелочи и инциденты. Состав по направлениям не менялся годами, поэтому контекст не приходится передавать заново при каждом обращении. Для абонемента это и есть главная ценность: за любой запрос берётся человек, который уже знает эту часть системы изнутри. ## Скриншоты и материалы _Для этого кейса не критично: его суть в модели сопровождения и непрерывности, а не в визуальной составляющей._ > Если у вашего продукта есть «основа», которая не должна падать, парсер, интеграция, ночной сбор данных, и при этом постоянно течёт мелочёвка, которая не складывается в большие ТЗ, поговорим. Покажем, как держать это одним абонементом: предсказуемый фон, явные часы сверху и реакция на инциденты за минуты. За разбор денег не берём. [Обсудить абонемент →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-prototypes-and-discovery/ title: Как мы работаем: прототип до счёта, оценка экономики, честный статус задачи type: case_study date: 2026-06-07T08:29:24+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Руководителю, который заказывает разработку, знакома эта механика: любая идея превращается в счёт, а сработала она или нет, выясняется потом, когда деньги уже потрачены. На платформе «Аналитика сертификатов» механика другая. За годы сопровождения через нас прошли десятки заказов: реализованные, отложенные, отвергнутые. Этот кейс не про один продукт, а про то, как принимается решение «делать, не делать или сначала проверить» и как мы помогаем клиенту посчитать, стоит ли затея своих денег, ещё до первого счёта. Эпизодов накопилось достаточно, чтобы показать метод на фактах, а не на лозунгах. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение: поток заказов, каждый проходит через оценку и согласование** Тип проекта Метод работы бюро: прототип до счёта, оценка экономики, помощь с выбором, честный статус Что показываем Девять задокументированных эпизодов из истории проекта, где решение «делать / не делать / сначала проверить» принималось вместе с заказчиком **Период** **С октября 2021 по сегодня** Трудозатраты Не выносим: кейс про подход, а не про объём конкретной задачи Команда Антон Херсун (руководитель проекта, оценки и прототипы) и разработчик аналитической панели, ведущий направление с первого дня **Статус** **Сотрудничество длится, поток заказов открыт** ## Метод вместо прайс-листа Когда задача звучит впервые, мы не тянемся за калькулятором. Сначала — три вопроса. Жизнеспособна ли затея технически? Сходится ли экономика для клиента? И можно ли проверить идею малой кровью, прежде чем вкладываться целиком? Разговор об оценке и сроках начинается после ответов, не раньше. Ниже четыре приёма, из которых складывается этот метод, и реальные эпизоды на каждый. ## Прототип за свой счёт, прежде чем предлагать большую трату Самая дорогая ошибка в заказной разработке — оплатить полную реализацию идеи, которая на практике не взлетит. Поэтому крупные затеи мы стараемся пощупать прототипом раньше, чем заводим разговор про бюджет. В июне 2024 года интерес заказчика к искусственному интеллекту только зрел («как-то внедрить в работу ИИ»), и мы по своей инициативе собрали рабочий прототип. За один вечер на сервере поднялся ИИ-аналитик, принимавший запросы к базе сертификатов на естественном языке. Заказчику ушло короткое сообщение: «Запустил прототип искусственного интеллекта на сервере», плюс логин, пароль и примеры обращений. Доступ отдали бесплатно, для тестов и обкатки. Когда прототип захотели показать партнёрам, мы держали его живым, а потом честно прикрыли, «чтобы ресурсы не потреблял». Прототип сразу обнажил и реальную стоимость затеи, и её слабые места: модель путала оператор сравнения, дообучение на частных вопросах ещё впереди, серверная база под такое стоит серьёзных денег. Заказчик пощупал всё это сам, а не выслушал от нас на словах. Большой заказ так и не оформили, но решение принимал клиент, глядя на работающую вещь. (Сам прототип ИИ-аналитика разобран в отдельном кейсе.) Тот же приём сработал в 2026 году на системе ценообразования для Битрикс24. Мы разобрали данные из выгрузки заказчика, собрали прототип на своей инфраструктуре и отдали ссылку с короткой просьбой: посмотрите, как работает, пишите, что добавить, что убрать, удобно ли расположение. Логику проговорили явно: «Собираю ваши пожелания, вношу в прототип. После утверждения прототипа оцениваем финально». Прототип устроил — и только тогда мы перешли к общей оценке. ## Развилка «полная или демо» как третий вариант Между «сделать всё целиком» и «не делать ничего» почти всегда есть третий путь — проверить идею на урезанном объёме. Мы стараемся предлагать его явно. Когда в 2022 году обсуждался Telegram-бот для быстрых ответов менеджерам, мы подготовили не одну смету, а две: полную версию и демо. Из демо целиком убрали самый дорогой этап (лингвистический разбор запросов) и связь с техническим отделом, оставили минимальный диалог на одной учётной записи. Смысл развилки: за меньший объём заказчик проверяет саму механику, прежде чем вкладываться в полную сборку. До боевого запуска бот в итоге не дошёл, согласование на стороне клиента застряло, но выбор был осознанный — с понятной границей между «попробовать» и «сделать как надо». (Подробности по боту вынесены в отдельный кейс.) ## Помощь посчитать экономику и право сказать «не делаем» Иногда самое полезное, что подрядчик может сделать для клиента, — помочь ему отказаться от затеи раньше, чем она съест деньги. Весной 2026 года по той самой системе ценообразования мы довели прототип до состояния, на котором заказчик смог посчитать экономику вместе с партнёрами. Вердикт партнёров вышел отрицательным, и заказчик сформулировал прямо: для нас одних проект выходит слишком накладным, по прайсу стоп. Важна здесь не остановка сама по себе, а то, что считать было на чём: прототип и оценка уже лежали на столе. Мы тут же предложили вариант, при котором проект не умирает, — доделать за свой счёт и включить стоимость в абонентскую плату, тем более что такая система может пригодиться и другим. Решение осталось за клиентом. Та же честность работает и в обратную сторону, когда экономика не сходится у нас на глазах ещё до сметы. По одной из доработок конструктора документов заказчик хотел, чтобы при смене основной даты автоматически пересчитывались даты испытаний. Мы даже не стали выносить её в ТЗ: «казалось бы штучка простая, но в реализации стоит как феррари». Новые теги, связи между ними, учёт красных дней календаря — около 30 часов работы ради удобства, которое того не стоило. Отговорили. ## Не брать деньги за нежизнеспособное Самый показательный эпизод связан с проверкой статусов документов. К 2025 году речь шла о массовой сверке статусов по более чем ста тысячам деклараций. Заказчик был готов оформлять ТЗ и платить, но мы притормозили сами: решение виделось одно — построить тестовый стенд с многопоточным парсингом через прокси и неделю-другую смотреть, выживет ли оно на полном объёме документов. Принцип держали прямо: > Увидим признаки жизнеспособности — продолжим ТЗ. Не увидим — не станем его расписывать и брать деньги за то, что проживёт неделю и умрёт. ТЗ не оформляли и счёт не выставляли, пока не появилась уверенность, что продукт переживёт собственный запуск. К той же категории относится диагностика, которая сэкономила клиенту покупку сервера. Поиск по реестру у пользователей тормозил, и логичная реакция напрашивалась сама: нарастить мощность железа. Мы сначала разобрались в причине. Люди искали ОГРН с параметром «содержит», а такой поиск идёт мимо индекса: база перебирает строки подряд, проверяя вхождение в каждую. Тот же запрос с параметром «равно» опирается на индекс и отрабатывал за миллисекунду. Вывод мы сформулировали прямо: вопрос не в мощностях и не в новом сервере, достаточно поправить то, что обнаружено. Сервер покупать не пришлось. Туда же относится отказ от пакетной конвертации документов в PDF. Идея исходила от заказчика, но конвертация давала косяки нумерации страниц — а это документ, который менеджер не глядя отправит в работу. Мы предложили прогнать десяток файлов на тест, и заказчик отказался сам: если уже вылезают такие косяки, смысла нет. Не берёмся за то, что испортит результат. ## Честный статус: что доработка, а что просто настройка Метод работает и на мелочах. Однажды заказчик принял за платную доработку «выдачу свежих номеров», а на деле у одной лаборатории просто не была выставлена галочка использования дат при бронировании. Мы так и написали: зайдите в раздел шаблонов, поставьте флажок, сохраните. Настройка, а не задача — и счёт за неё не появился. Обратная сторона той же честности — фиксация рисков на своей стороне. По одному из заказов на улучшение парсинга смета была около 56 часов, а по факту вышло 156: первый метод сбора оказался нерабочим, пришлось переделывать. Реакция была короткой: «это мои риски, посмотрим в целом на результат». Оценка дана в фиксированных часах, поэтому перерасход остался на исполнителе, а не лёг на клиента. ## Что из этого получает клиент Что Как это выглядит на практике Прототип до большой траты ИИ-аналитик и система ценообразования собраны и отданы на тест прежде, чем зашёл разговор про полный бюджет Развилка вместо «всё или ничего» По Telegram-боту подготовлены две оценки: полная и демо, с понятной границей Помощь посчитать экономику По системе ценообразования заказчик с партнёрами оценил и принял решение не делать, имея на руках прототип и расчёт Защита от лишних трат Отговорили от автопересчёта дат («стоит как феррари»), от покупки сервера (дело было в операторе поиска), от конвертации в PDF Честный статус задачи «Свежие номера» оказались настройкой и не стали платной задачей; перерасход по парсингу зафиксирован как риск исполнителя ## Команда - **Антон Херсун, Xaver Pro**: руководитель проекта. Прототипы, оценки в фиксированных часах, диагностика, разговор с заказчиком про экономику и приоритеты. - **Разработчик аналитической панели** ведёт это направление с первого дня и до сегодня. Любой модуль, написанный годы назад, дорабатывается тем же человеком, поэтому решение «делать или не делать» опирается на знание всей системы, а не на догадки. ## Скриншоты и материалы _Не применимо: кейс про метод работы, отдельного продуктового интерфейса у него нет._ > Если у вас есть идея, в которой вы сами не уверены, и не хочется платить за полную реализацию вслепую, покажите. Скажем честно, жизнеспособно ли это технически, как проверить её прототипом за минимальный объём и где экономика может не сойтись. Первичная оценка бесплатна. [Запросить оценку идеи →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-docmarket-mvp-2026/ title: DocMarket — минимальная версия сервиса самостоятельной продажи выгрузок type: case_study date: 2026-06-07T08:29:23+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Когда услуга продаётся вручную, масштаб упирается в людей: менеджер сам выгружает данные, сам выставляет счёт, сам отправляет результат. Хотите обслуживать в десять раз больше клиентов — нанимайте в десять раз больше менеджеров. Либо переводите услугу на самообслуживание. DocMarket задуман как этот второй путь: ручная услуга превращается в отдельный сайт с автоматической оплатой и личным кабинетом. ## Сводка Отрасль Сертификация продукции, B2B-логистика Конечный клиент «Аналитика сертификатов» (новый продукт в линейке) **Формат сотрудничества** **Прямой ТЗ под отдельностоящий новый продукт** Тип проекта Минимальная версия веб-сервиса самостоятельной продажи выгрузок данных из реестров сертификации Объём минимальной версии Регистрация, личный кабинет с реквизитами, предварительная фильтрация со скрытыми чувствительными полями, оплата по счёту и картой, промокоды, автоматическая выдача результата, уведомления, интеграция с основной базой платформы на чтение **Дата проекта** **19 марта 2026 — на согласовании у заказчика** Трудозатраты **не оцифрованы** — в ТЗ заложен этап аналитики, после которого выставляются часы Команда Антон Херсун (руководитель проекта). Исполнитель определяется — рассматриваем разработчика основной платформы и разработчика виджетов/парсеров, выбор зависит от того, как ляжет техническая интеграция Технологический стек Отдельный веб-сервис (вероятно Laravel, как остальное) · интеграция с основной базой на чтение · собственная БД пользователей и заказов · эквайринг и оплата по счёту · личный кабинет с регистрацией по телефону и почте **Состояние** **Финальное ТЗ (`tz37_docmarket_mvp_final.docx`) передано 26.03.2026; заказчик взял на согласование, дальнейшего хода в переписке нет** ## Постановка задачи У клиента уже работает ручная услуга: менеджеры выгружают данные из реестров сертификации для российских логистов. Логисты используют чужие документы сертификации по номеру без доверенности, и это легально по постановлению. Спрос есть и подтверждён на отраслевой выставке логистов. Проблема в другом: у разных менеджеров разные критерии выгрузки и разные цены. Контролировать такое сложно, масштабировать — ещё сложнее. DocMarket собирается как отдельностоящий веб-сервис, который автоматизирует процесс. Формат заказчик обозначил сразу: не полноценная платформа целиком, а минимальная рабочая версия с возможностью расширения. Ядро минимальной версии: - Регистрация по телефону или почте с подтверждением. - Личный кабинет: профиль, реквизиты компании, история покупок с повторным скачиванием. - Предварительная фильтрация по реестрам с **ограниченной видимостью** результата, доступная без авторизации, чтобы привлекать клиентов. - Оплата на сайте: по счёту для юрлиц и ИП, картой для физлиц; промокоды. - Автоматическая выдача полной выгрузки после подтверждения оплаты, уведомления в кабинете и на почту. **Что в этом сложного.** Самое уязвимое место самообслуживания поверх реестровых выгрузок: показать клиенту достаточно, чтобы он понял ценность, и не дать достаточно, чтобы он нашёл данные сам. Покажешь в предпросмотре полные номера и даты, и клиент уйдёт искать в открытый реестр, ничего не купив. Скроешь всё, и он не поймёт, что внутри, и не оплатит. Баланс «показать структуру, скрыть идентификаторы» — центральное продуктовое решение, а не технический патч, и согласовать его с заказчиком надо до начала разработки. ## Как мы это сделали (на текущем этапе) **1. Финальное ТЗ как итог созвона с заказчиком 19 марта 2026.** Устные договорённости теряются за неделю, поэтому формат «созвон → концепт → ТЗ» мы держим жёстко. Заказчик сначала прислал концепт-документ (`Проект - DocMarket.docx`), созвон прошёл в Телемосте, и за неделю после него собрали финальное ТЗ (`tz37_docmarket_mvp_final.docx`, передано 26.03.2026). Запись встречи — единственный способ через месяц вспомнить, почему в ТЗ вошло именно это, а не другое. Дисциплина простая: концепт фиксируем на бумаге, обсуждаем голосом, сводим в одно ТЗ, а не «давайте начнём кодить». **2. Граница минимальной версии прочерчена сознательно.** В концепте заказчик описал «идеальную» выгрузку: документ должен быть серийным, действующим по дате, по статусу в национальном реестре (КГ, КЗ, Беларусь), по статусу в реестре ЕАЭС (`pub.fsa.gov.ru/reaec/conformityDoc`) и по законодательству, а последнее вообще живёт только в постановлениях на бумаге и заносится вручную. Пять условий — это пять разных источников и онлайн-проверок. В минимальной версии оставили два автоматических фильтра: только серийные документы и только действующие по дате. Три проверки статусов уехали во вторую очередь. Так минимальная версия получает рабочий продукт без зависимости от живых внешних реестров, а тяжёлая часть переезжает в следующий этап. Это решение про объём, а не про «сделаем всё сразу». **3. Ограничение видимости в предпросмотре: продуктовое решение, заложенное в архитектуру.** В ТЗ зафиксировано прямо: в предпросмотре номер документа скрыт полностью, от дат остаётся только год, остальные критичные поля помечены «скрыто» или размыты. Конкретный перечень скрываемых полей заказчик определяет на этапе проектирования. Принципиально здесь одно: размытие нельзя «добавить потом». Оно влияет на структуру запросов к базе и на шаблоны рендеринга, поэтому закладывается в архитектуру с самого начала. **4. Личный кабинет с реквизитами компании под выставление счетов.** Бухгалтерия покупателей-логистов не проведёт оплату без счёта с реквизитами: для юрлица это условие сделки, а не удобство. Поэтому в кабинете лежит профиль компании и кнопка «скачать счёт» по любой покупке, а сам счёт собирается автоматически из реквизитов кабинета. **5. Не оцениваем часы, пока не пройдёт этап аналитики.** Строка часов в плане работ оставлена пустой, и это намеренно. DocMarket подключается к основной базе платформы, которая четвёртый год в продакшене, и интеграция идёт строго на чтение: отдельный сайт не должен уметь что-то записать или сломать на проде. Как безопасно выдать такой доступ — решит первый этап аналитики. Второй риск честно вынесен в само ТЗ: сроки подключения эквайринга плавают, потому что у банков разные процедуры тестового и боевого доступа. Называть финальную смету до проработки этих развилок было бы гаданием. ## Результаты (текущее состояние) Метрика Значение Часы **не оцифрованы** — в плане работ заложен этап аналитики, после которого выставляется оценка ТЗ Финальная версия `tz37_docmarket_mvp_final.docx`, передана 26.03.2026 Статус На стороне заказчика на согласовании; сборка не начата Артефакты Концепт `Проект - DocMarket.docx`, созвон в Телемосте 19.03.2026, финальное ТЗ Что есть на сегодня: концепт прошёл цикл «концепт → созвон → финальное ТЗ» с письменной фиксацией каждого шага, минимальная версия отделена от перспективной части, опасные места интеграции названы заранее. Дальше идёт этап аналитики под интеграцию с основной базой, после него оценка часов и старт сборки. Решение остаётся за заказчиком. ## Процесс и хронология Этап Период Результат Концепт от заказчика 19 марта 2026 `Проект - DocMarket.docx` Созвон с заказчиком 19 марта 2026 Обсуждение в Телемосте, запись Финальное ТЗ 19–26 марта 2026 `tz37_docmarket_mvp_final.docx` Этап аналитики не начат Анализ БД, схема фильтров, перечень скрываемых полей, оценка часов Сборка минимальной версии не начата По согласованному плану ## Команда - **Антон Херсун, Xaver Pro**: руководитель проекта, формализация ТЗ, разметка границы минимальной версии - **Исполнитель определяется.** Рассматриваем двоих: разработчика основной платформы (он знает базу аналитики изнутри, что снижает риск рядом сломать что-то на проде) и разработчика виджетов/парсеров (если DocMarket окажется ближе по архитектуре к Битрикс-интеграциям). Выбор после этапа аналитики и проработки интеграции с основной базой. ## Скриншоты и материалы _Пока пусто: минимальная версия не реализована._ > Если планируете перевод ручной B2B-услуги в самообслуживание, поделимся методикой работы по этапам: «концепт → встреча → финальное ТЗ» с письменной фиксацией каждого шага. Покажем, какие развилки бывают между «показать ценность» и «отдать всё». Разбор бесплатный. [Автоматизировать ручную услугу →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-security-devops-migration-2026/ title: От атаки к укреплению и миграции: безопасность и инфраструктура B2B-платформы в 2025–2026 type: case_study date: 2026-06-07T08:29:23+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- В апреле 2025 на сервере клиента нашёлся `xmrig`, спрятанный за подменённой системной библиотекой `libsystemd-shared`. Рядом — контейнер с открытым Docker API без аутентификации и больше сотни лишних слоёв в overlay2. Майнера прибили за ночь, по итогам выходных написали отчёт об инциденте. Но история началась раньше: ещё в январе 2025 вирус на сервере ClickHouse заставил срочно переезжать. Дальше — история входов с белым списком IP (она сразу поймала реальную утечку доступов), контроль экспортов и плановая миграция инфраструктуры в январе 2026, с документацией на сто с лишним страниц. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение + реагирование на инцидент + проектная миграция** Тип проекта Реакция на два инцидента, ТЗ системного укрепления, миграция инфраструктуры Объём работ Реагирование на инциденты (rootkit, майнер); расследование и отчёт; ТЗ безопасности (мониторинг доступа, роли, контроль экспортов) + срочный срез; перенос на новый сервер под ISPManager **Дата проекта** **28 января 2025 — 29 января 2026 (около года)** Трудозатраты Срочный срез безопасности (10 ч, реализован за день); миграция и реагирование считались отдельно Команда Антон Херсун (руководитель) и инфраструктурное подразделение Xaver Pro; систему ролей и прав вёл наш профильный разработчик Технологический стек Docker (очистка) · ClickHouse + репликатор · ISPManager · Laravel **Сдано** **Сервер очищен от rootkit и майнера, поставлены история входов и белый список IP (поймали передачу доступов третьим лицам), инфраструктура перенесена на новый сервер с полной документацией** ## Постановка задачи Внутренняя платформа клиента из аналитической панели выросла в систему, которой пользуются десятки людей со стороны заказчика и его партнёров. Чем заметнее система, тем больше желающих присмотреться к чужим мощностям и чужим данным. За год проявились обе угрозы. 28 января 2025 года на сервере, где развёрнут ClickHouse, завёлся вирус и начал грузить систему. Причина оказалась банальной: сервер давно не обновлялся и накопил уязвимости. На ту субботу мы спланировали и выполнили срочный комплекс: временно вернули поиск документов на MySQL, перенесли всё на новый сервер, проверили работоспособность и предложили план регулярной профилактики, чтобы такое не повторялось. Повторилось в апреле. 8 апреля пользователи стали жаловаться, что виджет долго отвечает. К ночи стало понятно: сервер ClickHouse на Timeweb взломан через **открытый Docker API**, и на нём добывают криптовалюту. Злоумышленник создал привилегированный контейнер с монтированием корневой файловой системы хоста, выполнил команды под root, установил скрытый майнер `xmrig` и **подменил системную библиотеку** `libsystemd-shared` версией с сигнатурой `HEUR:Rootkit.Linux.Processhider` — чтобы майнер не был виден в `ps` и `top`. **Что в этом сложного.** Для внутренней B2B-платформы самое опасное не отказ, а тихая компрометация. Шифровальщик виден сразу: бизнес встаёт. Майнер с rootkit может месяцами выжирать процессор и маскироваться от стандартных инструментов. Когда его наконец находят, у владельца возникает вопрос «а что ещё могли получить?» — и без подготовленной инфраструктуры ответа на него нет. Удалением файлов тут не отделаешься. Нужен постоянный мониторинг, чтобы следующий инцидент не обнаружился случайно, и нужно видеть, кто и откуда входит. А на случай, когда сервер всё-таки придётся пересоздавать, должна лежать свежая копия данных. ## Как мы это сделали **Реагирование на апрельский инцидент.** Майнера и rootkit прибили за ночь, работоспособность восстановили к утру следующего дня; на случай скрытых изменений наготове была свежая резервная копия сервера. За выходные провели полное расследование: подменённая системная библиотека, скрытый майнер, **больше сотни неиспользуемых слоёв в `/var/lib/docker/overlay2`** — следы работы атакующего. Удалили, восстановили оригинальную библиотеку, закрыли точку входа, ротировали ключи. Всё зафиксировали во внутреннем отчёте об инциденте и передали клиенту. Месяц по защите вышел дороже планового бюджета, 15 часов вместо 5. Мы предупредили об этом сразу и закрыли остаток из других периодов абонемента: это наши риски, а не сюрприз в счёте. **Что выросло из инцидента.** После апреля серверную рутину (мониторинг с алертами, резервные копии, плановые апгрейды серверов) перевели в формат регулярного серверного сопровождения — об этом у нас отдельный кейс. Для сюжета безопасности из неё важен один эффект: с июня 2025 алерты по нагрузке и диску приходят прямо в рабочий чат, и следующую аномалию первой увидит автоматика, а не пользователи, у которых что-то начало тормозить. **ТЗ безопасности: почему мы намеренно его раздробили.** В ноябре 2025 заказчик пришёл с запросом по контролю доступов на портал. Мы оформили полное техническое задание с оценкой и сами же честно сказали: объём вышел больше, чем хотелось бы для одного захода. Самый тяжёлый блок — контроль множественных одновременных сессий с привязкой к устройству или городу: в стандартном функционале такого нет, без переписывания авторизации не обойтись. Вместо того чтобы тянуть большой блок целиком, мы предложили вырезать из него то, что нужно закрыть сейчас, и отдельным маленьким срочным ТЗ на 10 часов сделать это немедленно. Срочное и полное развели специально: иначе срочное никогда не доходит до сдачи. **Почему детектор подозрительной активности нельзя строить на IP.** В обсуждении ТЗ всплыл нюанс из практики клиента: у большинства пользователей IP динамический, меняется за день-неделю, и в логах это выглядит так, будто человек заходит с сотни адресов. Поэтому эвристику подозрительной активности правильно строить на связке «отпечаток устройства плюс локация (страна, город)», а не на голом IP. И ещё: закрытый браузер не завершает сессию, поэтому лимит одновременных сессий обязан корректно переживать ситуацию «забыл выйти и зашёл с другого устройства» — нужно ждать таймаута. Эти оговорки и есть причина, по которой полноценный контроль сессий стоит дороже и вынесен из срочного среза. **История входов и белый список IP: что они сразу показали.** Срочный срез профильный разработчик по правам и ролям сделал за день. Появилось меню «История входов»: каждый вход пользователя пишется в таблицу с IP и виден администратору. В редакторе пользователя появилось поле белого списка IP и галочка «пускать только с разрешённых адресов»; отдельная колонка общих адресов на уровне компании, чтобы не вбивать один и тот же серверный IP каждому; роль суперадмина не ограничивается; для массовой простановки и снятия ограничений добавлены отдельные права доступа. Результат не заставил себя ждать: по истории входов заказчик зафиксировал реальные факты передачи доступов третьим лицам и начал внутреннее расследование. Инструмент окупился в первые же дни — показал то, чего без него вообще не было видно. **Роли и контроль экспортов.** Следом доработали систему прав: добавили роли под реальные потребности и закрыли правами доступа экспорт отчётов (общих, отдельных, мультиотчётов и базы новых участников рынка), а заодно копирование данных из таблиц «выделить-скопировать». Мы честно предупредили: защита от копирования поверхностная, кто умеет читать ответ сервера в консоли браузера, всё равно достанет данные. Для отсева очевидных утечек этого достаточно, и клиент сознательно выбрал этот уровень. Для аналитической платформы экспорт и копирование — главный канал возможной утечки, поэтому контроль над ними важнее, чем кажется. **Миграция на новый сервер (январь 2026), с полной документацией.** К январю 2026 основной сервер упёрся в лимиты: алерты по диску шли постоянно. Подобрали тариф с запасом (200 ГБ, панель ISPManager) и зафиксировали исходное состояние сервера: версию панели и ядра, набор аддонов (антивирус по расписанию, мониторинг, файловый менеджер, конструктор сайтов), лимиты доменов и срок лицензии. 20 января подготовили документ миграции на сто с лишним страниц и передали в техподдержку хостера: перенос шёл по этому документу и под контролем. 24 января в 9:00 по Москве остановили основной сервер и начали перенос; 25 января закончили, прогнали проверки, заодно ускорили таблицу деклараций в ClickHouse. Старый сервер не удаляли сразу: несколько дней наблюдали, что ошибок нет и парсинг работает штатно, и только 29 января отключили и удалили его. Одна оговорка: сервер с ClickHouse, репликатором и S3-дампером остался независимой машиной, в миграцию он не входил и продолжил работать. ## Результаты Метрика Значение Реагирование на инциденты Два инцидента (январь и апрель 2025) закрыты; майнер и rootkit удалены, отчёт зафиксирован Скорость восстановления Майнер прибит за ночь, работоспособность восстановлена к утру Контроль доступа История входов + белый список IP (10 ч, реализован за день); сразу выявлены факты передачи доступов третьим лицам Контроль утечек Права доступа на экспорт отчётов и базы новых участников рынка, ограничение копирования из таблиц Миграция инфраструктуры 24–25.01.2026, плановая, по документации на сто с лишним страниц; старый сервер удалён 29.01 Календарь 28 января 2025 — 29 января 2026 После двух инцидентов сервер очищен, точки входа закрыты. Контроль доступа из теоретического стал рабочим: история входов и белый список IP в первые же дни показали реальную утечку доступов. Экспорт и копирование данных закрыты правами доступа. В январе 2026 платформа переехала на сервер с запасом мощности — по подробной документации и без потери данных. ## Процесс и хронология Этап Период Результат Инцидент на сервере ClickHouse 28 января 2025 Срочный перенос, временный возврат поиска на MySQL, план профилактики Инцидент: компрометация через Docker API 8 апреля 2025 Майнер и rootkit найдены и удалены за ночь Отчёт об инциденте 14 апреля 2025 Расследование за выходные, документ передан клиенту ТЗ безопасности (полное) ноябрь 2025 Оценка показала большой объём → решили раздробить Срочный срез безопасности 18–19 ноября 2025 История входов + белый список IP за день; поймали утечку доступов Роли и контроль экспортов ноябрь 2025 Пермишны на экспорт и копирование, новые роли Подготовка миграции 16–20 января 2026 Аналитика сервера, документ миграции Миграция на новый сервер 24–29 января 2026 Перенос, проверки, удаление старого сервера ## Команда - **Антон Херсун, Xaver Pro**, руководитель: координация реагирования на инциденты, формализация отчёта, согласование ТЗ безопасности, управление миграцией. - **Инфраструктурное подразделение**, отдельная команда по серверной поддержке внутри Xaver Pro. На них очистка сервера после инцидента и миграция на новый сервер. Серверная работа и разработка панели — разные дисциплины, поэтому и команда специализированная. - **Разработчик прав и ролей** сделал срочный срез безопасности (история входов, белый список IP, права доступа на экспорт и копирование). Систему доступа на платформе ведёт профильный человек, а не общий пул. ## Скриншоты и материалы _Будут добавлены отдельным проходом: нужны скриншоты мониторинга, истории входов и схема «до и после» инфраструктуры, прошедшие обработку приватности._ > Если на сервере что-то странное (необъяснимая нагрузка CPU, неизвестные контейнеры, незнакомые процессы), пришлите вывод `ps aux`, `docker ps -a` и логи последней недели. Скажем, искать ли криптомайнер и rootkit или это просто кривой конфиг. Срочный разбор бесплатный. [Проверить сервер →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-foreign-registries-parsing-kg-kz-by/ title: Парсинг трёх государственных реестров сертификации (KG/KZ/BY): около 260 часов на очередях Laravel type: case_study date: 2026-06-07T08:29:23+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Иностранный государственный реестр сертификации ничего вам не должен. Сегодня он отдаёт данные, завтра меняет URL, закрывает публичный список, ставит геоблокировку, обновляет формат или банит все ваши машины разом — и предупреждать никто не будет. У внутренней аналитической платформы выбор простой: либо устойчивый парсер на очередях, с ротацией прокси и инкрементальной сборкой, либо аналитика по этому реестру встаёт через неделю, и узнаёте вы об этом по тишине в логах. ## Сводка Отрасль конечного клиента Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» — внутренняя платформа группы компаний **Формат сотрудничества** **Регулярное сопровождение — поток заказов по мере появления новых реестров и изменения старых источников** Тип проекта Длительная серия работ по парсингу иностранных государственных реестров сертификации (Киргизия, Казахстан, Беларусь) Объём работ Девять заказов по парсингу, плюс поддержка существующих парсеров и панель управления сбором **Дата проекта** **ноябрь 2022 — продолжается, больше трёх лет активной работы** Трудозатраты **около 260 часов** по согласованным сметам; фактический объём выше за счёт мелких доработок без отдельной сметы Команда Антон Херсун (руководитель проекта; принял парсинг как легаси, разобрал и перевёл на современную архитектуру руками сам), затем передал разработчику виджетов и парсеров, который ведёт направление с тех пор Технологический стек Laravel 5.5.50 · Laravel Horizon · очереди и задания · Redis · Docker · ClickHouse · собственная система ротации HTTPS-прокси со случайными User-Agent **Сдано** **Парсеры трёх национальных реестров (KG/KZ/BY), панель управления сбором, автоматическая инкрементальная сборка по расписанию и по требованию** ## Постановка задачи Платформа работает с государственными реестрами сертификации соответствия продукции: публичные данные о выданных декларациях и сертификатах. Источники находятся на государственных сайтах Киргизии, Казахстана и Беларуси, параллельно идёт сбор по российскому реестру. Полноценного публичного API нет ни у одного. Где-то API с авторизацией по токену неизвестного времени жизни, где-то только веб-интерфейс с порядковым перебором номеров, где-то источник регулярно меняет структуру ответа или вовсе закрывает публичный доступ. У клиента уже работал старый парсер, написанный до нас. Часть работала, часть нет, и понять, где именно падало, было невозможно: логов почти не было, сбор по Казахстану держался «на коленке» и при каждом бане его нагоняли вручную. Антон сел за исходники, разобрался, что сохранять и что переписывать, и постепенно перевёл всё на единую архитектуру: задания Laravel, очереди под Horizon, собственная ротация прокси. Только после этого передал направление коллеге. Заказчик ставил последовательные заказы по мере появления новых источников или изменения старых: - ноябрь 2022: ферма парсинга из трёх серверов, обход блокировок Казахстана, автоматический перепарсинг - начало 2024: парсинг киргизских деклараций перебором после закрытия публичного реестра, затем сертификаты КГ по матрице вероятностей стран - 2024: переписанный белорусский реестр, доработки парсера KZ - 2025: панель управления сбором и подключение общего реестра ЕАЭС, переход на новый казахстанский реестр через API - конец 2025: буферная таблица для документов без номера, доработка полей KZ, акты идентификации **Что в этом сложного.** Источник меняется без предупреждения, и каждое изменение стоит платформе данных. Киргизия закрыла публичный список — пришлось переходить на перебор номеров. ФСА в пятницу вечером забанил все парсер-машины разом; за выходные систему переписали в несколько потоков через прокси и догнали стопроцентную актуальность месяца. Казахстан переехал на новый реестр с токенной авторизацией, и старый парсер по веб-странице больше не работал. Беларусь ввела геоблокировку, под которую попал даже белорусский прокси. Российский реестр выставил лимит в 20 страниц на запрос. И так каждый год. Поэтому архитектуру с самого начала строили под смену источника: способ получения данных может меняться сколько угодно, а схема хранения и накопленные данные остаются. ## Как мы это сделали **1. Парсер не cron-скрипт, а очередь Laravel под Horizon.** Bash с cron отвергли сразу: нет retry, нет мониторинга, нельзя запустить сбор конкретного органа по запросу. Собственная job-система на Python тоже отпала — дубль уже существующего Laravel-стека. Логику сбора вынесли в задания Laravel; поверх работает Horizon как менеджер очередей, под ним Redis. Очередь даёт перезапуск при падении воркера, постановку парсера конкретного органа по требованию, не дожидаясь расписания, и общую панель Horizon вместо разрозненного мониторинга. Новый парсер — это один новый job-класс. **2. Инкрементальность через «следующий ожидаемый номер», а не пересканирование диапазона.** Структура номера киргизской декларации фиксирована: `ЕАЭС KG417/049.Д.0006245`, где `KG417/049.Д.` задаёт статический код органа сертификации, а `0006245` отсчитывает порядковый номер с шагом 1. Сканировать весь диапазон каждый день незачем: по каждому органу храним последний собранный номер и проверяем только следующие 10–20 значений, величина шага настраиваемая. Число запросов к источнику падает на два порядка — а с ним и риск бана. Если у органа случается разрыв нумерации или меняется формат, в панели можно вручную задать номер для старта перебора. **3. Сертификаты: перебор по номеру и по стране.** С декларациями всё линейно, а у сертификатов КГ в номер зашит код страны производства (`ЕАЭС KG417/044.CN.02.02191`, где `CN` обозначает Китай), и его не вычислить по порядку. Поэтому по каждому из 28 органов считаем отдельную матрицу вероятностей стран и сортируем от самой частой к редкой. От последнего известного номера парсер пробегает страны по матрице; если не нашёл, увеличивает номер на единицу и повторяет — до десяти раз. До конца списка стран дело доходит редко, так что лишних запросов почти нет. Часть органов ведёт номера неаккуратно: то точка, то слеш, то пропадает пробел после `KG`. Таких собираем в общем порядке без матрицы, а мусорные документы отбраковываем. **4. Собственная система ротации HTTPS-прокси со случайными User-Agent.** Сторонние прокси-сервисы отвергли: дорого, зависимость от поставщика и нестабильность на российских источниках. Сделали внутреннюю систему: пул HTTPS-прокси с проверкой работоспособности, случайный прокси на каждый запрос, временное исключение «токсичных» (получивших 403 или 429), периодическая ротация User-Agent. Эту систему переиспользуют все парсеры KG, KZ, BY. Когда в конце 2023-го ФСА забанил все машины, именно на ней за выходные подняли схему из четырёх машин по два потока через прокси и вернули полную актуальность декабря. Когда позже понадобилась авторизация через прокси для нового казахстанского API — система подхватила без правок. **5. Адаптация под смену API без переписывания приёмника.** Казахстан перешёл на новый реестр с API `techreg.gov.kz/Synergy/rest/api/` и авторизацией по токену в заголовке. Доступ оказался защищён слабо: публичные документы отдавались при простой проверке роли. Этим мы и воспользовались: объём работ оценили в 50 часов. Поля нового источника легли в существующую таблицу базы без миграции схемы; обёртка задания осталась прежней, менялся только источник внутри. На старте сбор по 46 источникам прошёл за десяток секунд, в очередь встало около 32 тысяч документов. Старый парсер KZ работал параллельно — дедупликация не давала задвоить документы. А вот отладка нового источника растянулась на несколько месяцев: путаница БИН и кода ОКПО (различали по длине строки), дубли, форматы дат, поля НПА. **6. Отложенная обработка документов без номера (14 ч).** Бывает, что документ опубликован в реестре, а поле номера пустое: номер появляется через несколько часов или дней. Сохранять такой документ без номера нельзя — потом его не связать с реальной декларацией. Сделали буферную таблицу: документ без номера лежит до 5 дней с проверкой каждые 12 часов; если за 5 дней номер не появился, переносим в основную таблицу с пометкой. Требование неочевидное, но для качества данных критичное. **7. Пропуск уже собранных номеров при переборе.** Эту тонкость заметили уже в эксплуатации: дубликат считался «ненайденным» документом, и десять дублей подряд ошибочно обрывали перебор. Логику поправили: если номер уже есть в базе, поиск по нему не запускаем и сразу переходим к следующему, а счётчик «пустых» на уже известных документах не растёт. ## Результаты Метрика Значение Объём работ по согласованным сметам **около 260 часов** Реестры в эксплуатации **3 страны (KG, KZ, BY), параллельно — российский реестр** Архитектурный стек парсеров Laravel 5.5.50 · Horizon · Redis · Docker · ClickHouse · собственная ротация HTTPS-прокси Эффект новой системы по КГ **+6400 сертификатов** с 1 января 2025, **72.6%** найдено через общий реестр ЕАЭС Запуск нового KZ-реестра **46 источников, ~32 тыс. документов** в очереди на старте Ритм сбора по расписанию (от ежечасного до раз в несколько часов) **плюс запуск по требованию** Календарь работ **ноябрь 2022 → продолжается, больше трёх лет** Три национальных парсера, общая Laravel-обёртка над Horizon, буферная таблица для документов без номера и панель, где заказчик включает страны и органы. Никакой обвязки сверх этого нет. У каждого парсера своя логика получения данных: порядковый перебор номеров, перебор с матрицей стран, API с токеном, классический скрейпинг с прокси-ротацией. За три года ни один парсер не переписали с нуля — каждый дорос до сегодняшнего вида через цепочку заказов, на инфраструктуре предыдущих. ## Процесс и хронология Этап Период Результат Ферма парсинга и обход блокировок ноябрь 2022 три VPS, автоперепарсинг, мониторинг; парсинг полностью на стороне команды Переход КГ на перебор номеров начало 2024 Декларации каждые 4 часа через 10 прокси (~7300 шт.); затем сертификаты по матрице стран, 28 органов Разовые и расширения 2024 Разовый сбор по `eokno.gov.kz`; переписанный белорусский реестр (30 ч), доработки KZ Панель управления и общий реестр ЕАЭС первая половина 2025 панель управления сбором, общий реестр как источник номеров Новый KZ-источник через API вторая половина 2025 переход на API `techreg.gov.kz` с авторизацией по токену Доработка качества данных конец 2025 поля KZ, буфер отложенных номеров, акты идентификации Обход блокировок и лимитов конец 2025 — 2026 Беларусь ввела блокировку (обошли за два дня, досбор с 1 ноября); РФ-реестр ввёл лимит 20 страниц (перешли на почасовой сбор с добором) _Все заказы соединены через общую базу и общую систему ротации прокси. Каждый новый заказ переиспользует инфраструктуру предыдущих._ ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта, формализация ТЗ, архитектурные решения по парсерам. Парсинг **разбирал руками сам**: принял частично работающий легаси без единого подхода, изучил, переработал и перевёл на современную архитектуру — задания Laravel под Horizon, инкрементальный перебор номеров, собственная ротация прокси. Случай для нас редкий, когда руководитель проекта закрывает сборку руками, но без этого передавать кому-то спутанный легаси было нельзя. - **Разработчик виджетов и парсеров** принял уже переработанное направление от Антона и ведёт его с тех пор. На нём парсеры KG/KZ/BY на новой архитектуре, панель управления сбором, переход на новый KZ-источник через API, буферная таблица отложенных номеров, акты идентификации. Преемственность внутри направления сохраняется: любой парсер, написанный год назад, дорабатывается тем же человеком. ## Скриншоты и материалы _Будут добавлены отдельным проходом. Возможные кандидаты: интерфейс панели управления сбором (статистика по странам производства, флажок «активен для перебора», предполагаемый следующий номер), панель очередей, упрощённая схема архитектуры задания-парсера._ > Если ваш парсер вчера встал и об этом узнали по тишине в логах, пришлите код. Скажем, где он течёт, какие куски стоит вынести в очередь и какой минимальный мониторинг ставить, чтобы тишина не повторилась. Смотрим бесплатно. [Прислать парсер на разбор →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-bitrix24-widget-and-apps/ title: Виджеты и приложения для Битрикс24: аналитика контрагента прямо в карточке CRM type: case_study date: 2026-06-07T08:29:23+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Менеджер открывает в Битрикс24 карточку лида и хочет понять, с кем имеет дело: сколько у контрагента сертификатов и деклараций, по каким техническим регламентам, какая динамика. Идти за этим в отдельную аналитическую систему он не станет — если переключение занимает больше 10 секунд, продажа пойдёт без контекста. Мы встроили аналитику прямо в карточки Лидов, Сделок и Компаний. Главное решение приняли на старте: встройка в чужом портале ломается на любом крупном обновлении Битрикса, поэтому в самой встройке логики нет, весь поиск и агрегация живут на нашем сервере. Жизнь проверила схему дважды. Когда внешний администратор случайно стёр интеграцию, виджет вернули примерно за 20 минут; когда Битрикс изменил отдачу данных и виджет слёг на всех коробках разом, починили в тот же день. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение — серия ТЗ по виджетам и приложениям в Битрикс24** Тип проекта Виджет в карточках CRM, который показывает аналитику сертификации по контрагенту, и серверный сервис поиска под ним Объём работ Виджет в Лидах, Сделках и Компаниях; вторая версия виджета с кэшированием и мониторингом; модуль ответственности по делам; раскатка на несколько коробок Битрикс24 **Дата проекта** **Виджет в amoCRM — 2022, перенос на Битрикс24 — с конца 2024, далее продолжается** Трудозатраты **больше 143 часов** подтверждённых смет (133 ч виджет v1 + 10 ч модуль ответственности; объём v2 в часах не оцифрован) Команда Антон Херсун (руководитель проекта; виджет v1 делал сам), затем направление принял разработчик виджетов и парсеров — он ведёт v2 и далее Технологический стек REST API Битрикс24 · встраивание в карточки CRM · серверная часть на Laravel · поиск по шести реестрам через ClickHouse · несколько коробок **Сдано** **Виджет в трёх разделах CRM на нескольких коробках, вторая версия виджета, модуль ответственности по делам. Обмен статусами с 1С остался на стадии предложения, продукт «Прайс» остановлен на стороне заказчика** ## Постановка задачи Клиент живёт в Битрикс24 как в основном CRM-инструменте: лиды, сделки, компании. У каждой компании-контрагента в карточке есть поле ОГРН, БИН или ИНН, и по этому идентификатору внутренняя аналитическая платформа поднимает данные: сколько у компании выданных сертификатов и деклараций, по каким реестрам, какая динамика. Менеджеру всё это нужно внутри Битрикс24, а не в отдельном окне. История виджета началась раньше Битрикса. В 2022 году мы сделали такой же виджет для amoCRM: документы по ИНН/ОГРН прямо в карточке плюс подписка на уведомления о новых документах. Когда в 2023-м клиент решил уходить с amoCRM на Битрикс24, amoCRM-виджет отключили, а перенос на новый портал заказчик оформил отдельным ТЗ. Дальше задачи приходили постепенно: - октябрь 2023: концепт CRM-приложения для Битрикс24 (оценка 160–220 ч), старт несколько раз сдвигался и в итоге свернулся в более узкий виджет - ноябрь 2024: ТЗ на виджет в Лидах, Сделках и Компаниях (133 ч) - ноябрь 2024: предложение по обмену статусами документов с 1С, заказчик решил отложить - август–сентябрь 2025: вторая версия виджета, «большое ТЗ» - сентябрь 2025: модуль ответственности по делам (10 ч) - весна 2026: предложение продукта «Система Прайс» для Битрикс24, остановлено партнёрами заказчика Перед стартом виджета v1 заказчик передал условие партнёров: начинать при предоплате 50%, остаток после сдачи. Договорились без споров: предоплата пришла 26 декабря 2024, разработку запланировали на январь. **Что в этом сложного.** Встройка живёт в чужом портале — он обновляется без вашего ведома, и у клиента таких порталов несколько. Виджет в карточке лида ломается на любом крупном обновлении Битрикса или REST API. Дважды это и случилось: один раз внешний администратор портала случайно стёр интеграцию целиком, другой раз виджет разом перестал работать на всех коробках после изменения на стороне Битрикса. Держи мы бизнес-логику внутри встройки, каждый такой случай оборачивался бы днями простоя менеджеров. Поэтому архитектуру сразу развели на два слоя: тонкая встройка отвечает только за показ страницы, вся логика поиска и агрегации работает на нашем сервере. ## Как мы это сделали **1. Серверная часть у нас, виджет как тонкая встройка.** Виджет в Битрикс24 принимает информацию об открытой карточке, забирает значение поля ОГРН и шлёт запрос к нашему сервису на Laravel. Поиск по реестрам, агрегация, формирование выдачи — всё это живёт на стороне Laravel, виджет показывает уже готовую страницу. Если Битрикс24 поменяет API встроек, переделывать придётся только тонкую встройку, а не сервис. **2. Один сервис на три раздела CRM.** В основном ТЗ (133 ч) виджет встраивается в три места портала: карточку Лида, Сделки и Компании. Идентификатор контрагента в каждом случае берётся по-своему: из карточки Компании напрямую, из Сделки через связанную компанию, из Лида из собственного поля (у лидов оно своё, и лид должен быть привязан к компании). Сервису неважно, откуда пришёл идентификатор: на выходе одна и та же страница с аналитикой. Вместо трёх отдельных виджетов получился один сервис. **3. Поиск по шести реестрам через ClickHouse: 300 мс на запрос.** По одному ОГРН виджет ищет сразу в шести таблицах: сертификаты и декларации РФ, сертификаты и декларации Киргизии, реестр Казахстана и реестр Беларуси. На обычной базе при выросших объёмах такой поиск занимал секунды. Мы подключили ClickHouse, и поиск стал укладываться в диапазон от 300 мс до 1 секунды даже на самом тяжёлом российском реестре; формирование выдачи добавляет ещё пару секунд. Сотня менеджеров может искать одновременно без задержек. На случай аварии хранилища поставили переключатель: ClickHouse недоступен — виджет мгновенно откатывается на обычную базу и продолжает работать. **4. Постановка дел: подсчёт новых документов и уведомления.** Менеджер может подписать карточку контрагента на отслеживание. Каждые 2 часа система пересчитывает новые документы по подписанным ИНН и раз в 2,5 часа ставит «дела» — задачи-уведомления в соответствующие лиды, сделки и компании. Так менеджер узнаёт о новом сертификате контрагента, не открывая карточку специально. **5. Вторая версия как переосмысление, а не патч («большое ТЗ»).** К v2 подписок накопилось столько, что прежний механизм перестал справляться: 13 тысяч ИНН на отслеживании не успевали обработаться за отведённые 2 часа, и постановка дел молча отваливалась. Сначала временно растянули интервал, потом сели за полноценный пересмотр. В «большое ТЗ» вошли починка постановки дел под выросшую нагрузку, поддержка нескольких ОГРН в одной сущности, архивация подписок уволенных сотрудников, кэширование (карточка не ходит в базу повторно, если данные не менялись) и отдельный мониторинг обработки ОГРН. Втискивать всё это в мелкое обновление даже не пробовали: такие задачи всегда выходят втрое дороже по часам. Кэширование докатили ночью к 25 сентября 2025. **6. Модуль ответственности по делам отдельным ТЗ (10 ч).** Возник вопрос: на кого ставить дело-уведомление — на ответственного за сущность или на сотрудника, который подписал карточку? И что делать, если ответственного нет или система не даёт его назначить. Логику «ставим ответственному, при невозможности пользователю, на лету» вынесли в отдельный модуль на 10 часов: пусть живёт независимо от ядра виджета и настраивается как в коробке, так и в самом виджете. Выкатили 29 сентября 2025, сверху повесили статистику в мониторинге. ## Результаты Метрика Значение Подтверждённые сметы **больше 143 часов** (133 ч v1 + 10 ч модуль ответственности) Точек встраивания в Битрикс24 3 (Лиды, Сделки, Компании) Реестров в одном поиске 6 (РФ серт/декл, КГ серт/декл, КЗ, Беларусь) Скорость поиска после ClickHouse 300 мс — 1 секунда вместо нескольких секунд Версии виджета v1 и v2 («большое ТЗ») Коробок Битрикс24 несколько, виджет раскатан на все Под тонкой встройкой в Битрикс24 живёт сервис на Laravel: бизнес-логики в самой встройке нет, она отдаёт готовую страницу. Один сервис обслуживает три раздела CRM. Поиск по шести реестрам уложился в 300 мс благодаря ClickHouse, с откатом на обычную базу при аварии. Вторая версия закрыла накопленную нагрузку на постановку дел и добавила кэширование. Модуль ответственности оформлен отдельно и настраивается на каждой коробке. ## Процесс и хронология Этап Период Результат Виджет в amoCRM (предшественник) 2022 Документы по ИНН/ОГРН + уведомления в amoCRM Концепт CRM-приложения Битрикс24 октябрь 2023 оценка 160–220 ч, свернулся в виджет Виджет v1 в трёх разделах ноябрь 2024 → март 2025 133 ч, боевой запуск 3 февраля 2025, принят 12 марта 2025 Обмен статусами с 1С ноябрь 2024 предложение, отложено заказчиком Виджет v2 («большое ТЗ») август–сентябрь 2025 готово 25 сентября 2025 Модуль ответственности по делам сентябрь 2025 10 ч, выкат 29 сентября 2025 Система Прайс для Битрикс24 весна 2026 Прототип, остановлено партнёрами заказчика ## Инциденты и реакция Виджет в чужом портале проверяется не в спокойном режиме, а в авариях. Два случая показали, зачем логика вынесена на наш сервер. **Интеграцию стёрли — восстановили примерно за 20 минут.** В августе 2025 внешний администратор портала по неосторожности удалил интеграцию виджета, заодно сбив client id и secret. От сообщения «у нас пропал виджет» до подтверждения полной работоспособности прошло около 20 минут: подняли резервную копию настроечных таблиц, поправили ключи в базе, переподключили приложение. Подписки на ОГРН при этом не слетели. По следам случая дописали в документацию короткий регламент восстановления. **Виджет упал на всех коробках сразу.** В декабре 2025 Битрикс перестал отдавать данные так, как отдавал раньше, и виджет одновременно слёг на всех коробках клиента. Переустановка приложения через штатную кнопку вернула работу — оставшуюся 500-ю ошибку добили в тот же день. Причина была на стороне Битрикса и затронула все порталы разом — ровно тот класс проблем, ради которого бизнес-логику и держат вне встройки. ## Что предлагали, но не делали Честные статусы тоже часть работы. Обмен статусами документов между 1С и платформой мы оценили ещё в 2024-м, но заказчик решил отложить. Когда в 2025-м к идее вернулись уже на объёме около 107 тысяч деклараций, мы намеренно не оформляли ТЗ до теста жизнеспособности, и задача так и осталась на стадии проверки. Браузерное расширение как способ обойти ограничения Битрикса на установку приложений (показывать виджет по ИНН на любом сайте) предложили в 2024-м — идея зависла. Продукт «Система Прайс» для Битрикс24 довели до прототипа, но партнёры заказчика его не поддержали, и проект остановили на их стороне. ## Команда - **Антон Херсун, Xaver Pro** — руководитель проекта, проектирование контракта «виджет ↔ сервис». Виджет v1 (133 ч) делал сам. Для нас это редкий случай, когда руководитель проекта закрывает сборку руками: сперва нужно было понять механику Битрикс24 изнутри, и только потом рисовать архитектуру. - **Разработчик виджетов и парсеров** — принял направление Битрикс к моменту v2 и ведёт его дальше (вторую версию и последующие доработки). Преемственность внутри направления сохраняется: задачи по виджету идут через одного и того же человека. Аналитическую панель ведёт другой разработчик, здесь своя специализация по интеграциям и парсерам. ## Скриншоты и материалы _Будут добавлены отдельным проходом: скриншот виджета внутри карточки Сделки после обработки приватности конкретных компаний._ > Если ваш виджет в Битрикс24 ломается на каждом обновлении портала, нам это знакомо. Покажите код и список «упало в этом релизе», ответим, что стоит вынести на сервер, чтобы обновления портала не роняли виджет. Разбор бесплатный. [Разобрать виджет в Битрикс24 →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-ai-integration-2024-2025/ title: ИИ-аналитик для базы деклараций: рабочий прототип, который мы собрали за свой счёт type: case_study date: 2026-06-07T08:29:23+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- У клиента к лету 2024-го накопилась большая база документов из реестров сертификации: декларации, сертификаты, история по заявителям и продукции. Незадолго до этого мы перенесли самые тяжёлые таблицы в ClickHouse — и поиск, который раньше занимал минуты, стал отвечать за несколько секунд. Логичный следующий вопрос от заказчика: а можно ли «прикрутить сюда ИИ». Отвечать презентацией мы не стали. Вместо этого собрали прототип и выложили его на тестовый сервер, чтобы заказчик потрогал руками. Идея простая: оператор пишет запрос человеческим языком, а модель сама превращает его в выборку из базы деклараций. Работа шла по инициативе бюро и за наш счёт — чтобы разговор о бюджете крутился вокруг живого результата, а не вокруг красивых слайдов. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **R&D-прототип по инициативе бюро, за свой счёт** Тип проекта Запросы к базе деклараций на естественном языке поверх существующей платформы Объём работ Сборка прототипа, обучение модели на реальных вопросах, демо на тестовом сервере, обкатка с заказчиком Трудозатраты Без согласованной сметы — исследовательская работа бюро Команда Прототип собрал Антон Херсун; исполнитель на продакшен-версию не назначался Технологический стек Laravel-платформа · ClickHouse · обучаемая LLM на отдельном GPU-сервере · веб-интерфейс запросов **Статус** **Зависло на уровне демо: модель показала результат, заказ на доведение до продакшена не оформлен** ## Запрос клиента У заказчика была рабочая аналитическая платформа и большой массив структурированных данных. Запрос звучал расплывчато, как это обычно и бывает: «внедрить в работу компании ИИ, чат-джипити» — отдельно в отдел продаж, отдельно в технический отдел. Конкретики под этим не было, и это нормально на старте. Мы начали с честного встречного вопроса: какую именно функциональность хочется получить и куда её встраивать — в портал аналитики, виджетом в CRM или чат-ботом в мессенджере. Для технического отдела заготовка у нас к тому моменту уже была, так что проще всего было продвинуть разговор, показав её в деле. ## Что мы сделали **1. Собрали прототип и дали к нему доступ.** Выложили рабочую версию на тестовый сервер с логином для заказчика. Оператор пишет вопрос обычными словами, модель строит по нему выборку из базы деклараций и возвращает таблицу. К демо приложили PDF с примерами реальных обращений, чтобы заказчик видел границы возможного, а не отрепетированный сценарий. **2. Обучили модель на реальных вопросах.** Это не «подключили API, и заработало». Модель обучаемая: чтобы она понимала живой язык операторов, её надо дообучать на конкретных формулировках. Мы загрузили в неё то, что собрали за месяц тестирования, и доучивали прямо по ходу демо. Показательный эпизод из переписки: фразу «текущий месяц» модель сначала не понимала вовсе — встроенного знания о сегодняшней дате у неё нет. Около часа ушло на то, чтобы научить её обращаться с датами; после этого она корректно отрабатывала формулировки вроде «документы с датой больше первого июня» и сама показывала, что декларации на лифты поступают каждый день. К концу обкатки прототип вытягивал и довольно сложные составные запросы: взять город, заявителя и число его документов, оставить только тех, кто ввозил определённую категорию товара, добавить дату последней регистрации, отсортировать по числу документов, схлопнуть «ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ» до «ООО» и привести даты к нужному формату. Всё это — одной фразой на русском, без SQL. **3. Честно показали, где модель ошибается.** Главная инженерная мысль такого продукта: модель **ошибается уверенно**. В демо она ставила строгое равенство там, где нужен был поиск по вхождению, путала колонки и начинала тянуть данные из адреса заявителя вместо нужного поля. Иногда с ней буквально приходилось торговаться, чтобы получить корректную выборку. Если не держать режим «модель предлагает, человек проверяет» и не дообучать её на частных случаях, такой инструмент быстро превращается в источник правдоподобной ерунды. Мы закладывали это в разговор с самого начала, а не оставляли на «потом разберёмся». **4. Очертили, что нужно для продакшена.** Демо упиралось в честные ограничения. Модели не хватало памяти между запросами: вопрос «персики, Москва», а следом «а теперь аналитику по ним» она не связывала в один контекст — это уже отдельный, более продвинутый уровень. Для боевой версии требовался отдельный мощный сервер и человек, который постоянно дообучает модель, как ученика: «даты я ему час учил». Мы честно проговорили, что здесь много исследовательской работы и экспериментов, результат заранее не гарантирован, и закладывать его в бюджет надо мелкими шагами, а не одной крупной строкой «ИИ-функционал». ## Как это восприняли Реакция шла ровно так, как и должна идти на сыром R&D. Первый прогон заказчик описал прямо: «интересная современная штука, пока выдаёт чушь конечно». Часть «чуши» оказалась несовпадением ожиданий: он спрашивал про сертификаты, а под капотом была только база деклараций. После пары итераций дообучения тон сменился: «сложные запросы решает», «прикольно получилось». Ещё через несколько недель, когда выборки довели до того, что хотелось видеть, оценка стала совсем короткой — «круто». Заказчик даже захотел показать прототип партнёрам. Мы на время снова открыли доступ к тестовому серверу (между демо его гасили, чтобы не жёг ресурсы) и предупредили: без короткой инструкции модель и партнёрам может наговорить лишнего. ## Результат Что получили Значение Рабочее демо Запрос к базе деклараций обычными словами вместо SQL, на живых данных Карта возможного Что модель уже умеет, где уверенно ошибается, чего ей не хватает Требования к продакшену Отдельный сервер, человек-тренер, режим «ИИ предлагает — оператор подтверждает», бюджет мелкими шагами Статус заказа Зависло на уровне демо: продакшен-версию заказчик не заказал, исполнитель не назначался Главный итог здесь не запущенная фича, а снятые иллюзии и работающая точка отсчёта. Заказчик увидел, на что технология реально способна на его данных и за сколько это придётся доводить. Тема осталась в проработке: спустя год, в августе 2025-го, мы отдельно искали готовые решения под чат-бота к этой задаче — и честно сообщили, что ничего достаточно зрелого под их специфику не нашли. Поэтому собственный прототип так и остаётся самым близким к цели вариантом. Для нас это нормальный режим работы: мы готовы вложить собственное время в AI-эксперимент, чтобы у клиента был не слайд, а то, что можно потрогать, и трезвое решение о бюджете. ## Команда - **Антон Херсун, Xaver Pro**: собрал прототип, обучал модель на реальных вопросах, провёл демо и обкатку с заказчиком ИИ-направление остаётся на стадии прототипа: отдельный исполнитель на продакшен-версию не назначался, заказ не оформлен. R&D мы вели за свой счёт. ## Скриншоты и материалы _Прототип на закрытом тестовом сервере, публичных артефактов нет._ > Думаете «прикрутить ИИ» к своей базе или процессам, но не уверены, где он окупится, а где станет дорогой игрушкой? Соберём прототип на ваших данных, покажем, что реально работает, а где модель уверенно врёт, и поможем понять, сколько закладывать в бюджет. Первичный разбор бесплатный. [Собрать AI-прототип →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-analytics-and-reports/ title: От ручного Excel к встроенной аналитике: 356 часов отчётов для B2B-платформы type: case_study date: 2026-06-07T08:29:21+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Сотрудники заказчика каждый месяц выгружали из платформы сырые данные и сводили статистику в Excel руками. Фактически это полставки оператора, причём каждый сводит по-своему. Мы перенесли эту работу внутрь платформы — пять ТЗ, 356 часов. Самым трудным в ней оказались не графики и не фильтры, а дисциплина справочников: пока десяток написаний одного техрегламента не сведён к одному классу, автоматическая группировка выдаёт мусор вместо отчёта. ## Сводка Отрасль конечного клиента Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение — поток пронумерованных ТЗ по аналитической функциональности** Тип проекта Перенос ручной сводки из Excel во встроенную аналитику B2B-платформы Объём работ Модуль запросника, группировщик статистики, гео-фильтры с разбором адресов, общий слой фильтров, годовой график с мастер-справочником **Дата проекта** **IV квартал 2021 — основной блок закрыт к 2023, годовой график обслуживается по сей день** Трудозатраты **356 часов** по ТЗ (agreed/billed) Команда Антон Херсун (руководитель проекта) и разработчик аналитической панели — он ведёт это направление с первого дня и до сегодня Технологический стек Laravel · Sencha 6 grid · конструктор табличных данных из ядра · MariaDB-агрегации · дочерний сервер вычислений **Сдано** **Запросник (65 ч), группировщик статистики (90 ч), гео-фильтры и разбор адресов (100 ч), фильтры общего отчёта + новости (16 ч), годовой график с мастер-справочником (85 ч)** ## Постановка задачи У сотрудников клиента была отлаженная Excel-практика: раз в период выгрузить из платформы сырые данные, перенести в файлы фиксированной структуры и собрать статистику — сколько документов выдал каждый орган сертификации, как они распределяются по техническим регламентам и классам продукции. Платформа этой аналитики не давала. В ТЗ на статистику так и написано: «На основании данных, которые мы выгружаем, мы вручную в Эксель формируем статистику за период». Заказчик ставил ТЗ кусочками: сначала группировщик по простым метрикам, потом гео-фильтры с разбором адресов, потом фильтры общего отчёта с новостями, под конец — годовой график с мастер-справочником классификации продукции. **Что в этом сложного.** Слабое место таких отчётов — справочники. Из реестров данные приходят в разнобой: один и тот же технический регламент пишется десятком способов («ТР ТС 021/2011», «о пищевой продукции», «ТР ТС 022/2011 в части маркировки»). Сотрудник в Excel схлопывает их в одну строку «Пищевая продукция», потому что считает руками и держит соответствие в голове. Для базы же это разные значения, и автоматическая группировка по ним рассыпается. С адресами та же беда: в реестрах они лежат как попало, один город записан в нескольких стилях, у части документов нет даже индекса. Поэтому в центре кейса не диаграммы и не фильтры, а две вещи поскучнее: мастер-справочник классификации и нормализация адресов. Без них отчёты так и остались бы ручными. ## Как мы это сделали **1. Опирались на конструктор табличных данных из ядра, а не строили отдельный отчётный движок.** Конструктор встроен в изначальное ядро платформы (см. кейс «Original platform build»): оператор настраивает колонки и группировки прямо в интерфейсе. Все аналитические ТЗ выросли из него. Мы добавляли новые группы полей (технический регламент, тип объекта декларирования, географию), а не писали отдельный код под каждый отчёт. За счёт этого каждое следующее ТЗ обходилось дешевле предыдущего. **2. Группировщик статистики (90 ч): первый шаг от Excel внутрь платформы.** В платформе появился раздел «Аналитика» с меню «группировщик» и типами отчётов вроде «декларации ТР ТС — по заявителю». Первый рабочий отчёт показали через неделю после старта, ещё через 2 недели модуль открыли всем пользователям. По ходу работы логику группировки пришлось переработать — 30 часов сверх ТЗ, и они остались на нашей стороне. С этого момента ежемесячная сводка перестала жить в Excel-файлах. **3. Гео-фильтры и разбор адресов (100 ч): там, где сортировка по адресу не сводилась.** Заказчик хотел фильтровать отчёты по дате, региону и городу. Простой текстовый фильтр по адресу цеплял любые совпадения, как `%like%` в Excel, и выдавал мусор: адреса в исходной базе записаны как попало. Решили разбирать адрес на составляющие по почтовому индексу — через базу индексов Почты России и сервис DaData, доли копейки за запрос. Индекс даёт устойчивый ключ там, где текстовое написание плывёт. Документы без индекса ищутся по-старому, текстом. Типовая для нас история: внешний источник отдаёт грязные данные, и нормализация стоит дороже самого фильтра. **4. Фильтры общего отчёта и новости (16 ч): за 3 дня.** В отдельных отчётах фильтры настраивались, а в общем — нет: там один набор фильтров на все таблицы. Заказчик попросил добавить туда фильтры по федеральному округу, заявителю, ОГРН и ТР ТС, плюс блок новостей на главной. Сложность была не в интерфейсе, а в КГ-таблице: под некоторые фильтры пришлось дописывать отдельный код, потому что схема «одно поле — одна таблица в поиске» эти случаи не покрывала. Собрали, протестировали с разработчиком и сдали за 3 дня от согласования. **5. Годовой график документов и мастер-справочник (85 ч): отговорили заказчика от чужой системы.** Заказчик хотел графики по декларациям и сертификатам за год, и здесь была развилка. Можно было поднять Grafana: мы развернули её на отдельном сервере ради проверки и построили первые простые графики; вышло бы часов на 70–80. Можно было написать собственный модуль аналитики документов внутри платформы, около 100 часов. Grafana мы заказчику не предложили: своих компетенций в ней на тот момент не хватало, чтобы гарантировать результат и сроки. Честнее было собрать модуль в существующей аналитике, где мы отвечаем за всё. На нём и договорились. Технически задача упиралась в нагрузку: годовые агрегации по всему массиву кладут основной сервер. Подняли дочерний сервер, настроили пересылку данных туда и предварительную обработку — скрипты готовят таблицы так, чтобы запросы выполнялись с приемлемой скоростью. Параллельно закрыли исходную проблему справочников, ради которой всё затевалось: мастер-справочник классификации. Администратор настраивает таблицу соответствия «исходное поле из базы → укрупнённый класс», и десяток формулировок про пищевую продукцию (029/2012, 021/2011, 022/2011 и прочие) сводится к одному классу «Пищевая продукция». Без этого справочника группировка по реальным данным разваливается. ТЗ закрыли с перерасходом по часам; перерасход остался на нашей стороне, не на счёте заказчика. **6. Модуль запросника (65 ч): сделали по ТЗ, концепция у заказчика не сложилась.** Запросник работает как конструктор запросов: подбор продукции по сводной ТР ТС / ТН ВЭД с множественным выбором кодов. Формы и базу на ~26 тысяч позиций сдали в срок. Дальше встал вопрос наполнения, и заказчик написал прямо: «как его наполнить, голову ломаем, идей почти нет». Применения концепции так и не нашлось. Мы предложили закрыть ТЗ, а не держать его в подвешенном состоянии; сам конструктор остался в системе и переиспользуется в других отчётах. Модуль сдан по ТЗ — продуктовая идея под него у заказчика не выкристаллизовалась. ## Результаты Метрика Значение Часы по ТЗ **356 часов** (65 + 90 + 100 + 16 + 85) ТЗ в аналитическом блоке 5 пронумерованных заказов Что заместили Ручную ежемесячную Excel-сводку аналитики сотрудниками Архитектурное переиспользование Все ТЗ опираются на конструктор табличных данных из ядра Ключевой момент Мастер-справочник классификации + нормализация адресов — без них аналитика по реальным данным разваливалась Встроенная аналитика закрыла прежний ручной цикл. Ежемесячную сводку теперь собирает группировщик, а не сотрудник в Excel. Гео-фильтры работают на грязных адресах за счёт нормализации по индексу, общий слой фильтров накрывает все таблицы, годовой график считается на дочернем сервере и основной не трогает. Мастер-справочник превращает разнобой формулировок из реестров в осмысленные классы. График живёт и обслуживается тем же разработчиком по сей день: в начале 2026-го заказчик написал, что график «не хочет показывать 2026 год», и это поправили в рамках сопровождения. ## Процесс и хронология Этап Период Результат Модуль запросника IV кв. 2021 — фев. 2022 65 ч — конструктор запросов; концепция наполнения у заказчика не сложилась Группировщик статистики дек. 2021 90 ч — первый отчёт за неделю, открыт всем через две, +30 ч переработки сверх ТЗ Гео-фильтры и разбор адресов янв. 2022 100 ч — фильтр дата/регион/город, нормализация адресов по индексу + DaData Фильтры общего отчёта + новости июль 2022 16 ч — фед. округ, заявитель, ОГРН, ТР ТС; реализовано за 3 дня Годовой график с мастер-справочником фев. — апр. 2023 85 ч — собственный модуль вместо Grafana, дочерний сервер, мастер-справочник; закрыт с перерасходом за наш счёт Что заказчик решил не делать, мы тоже зафиксировали: апгрейд годового отчёта (середина 2023) завис на этапе просчёта, формального ТЗ не появилось; мульти-выбор нескольких федеральных округов в общем отчёте (декабрь 2023) оценили в 10 часов, заказчик отложил. ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта: требования к мастер-справочнику, формализация фильтров, развилка «Grafana или собственный модуль», инфраструктура дочернего сервера вычислений - **Разработчик аналитической панели**: серверная и клиентская части аналитических модулей. Конструктор табличных данных, группировщик, запросник и годовой график написаны в рамках одного направления, которое ведётся с 2021 года. Любой модуль, написанный годы назад, дорабатывает тот же человек: годовой график правится по сей день. ## Скриншоты и материалы _Будут добавлены отдельным проходом._ > Если ваши отчёты до сих пор собираются вручную в Excel из выгрузок CRM или платформы, пришлите три самых частых типа. Скажем, во что выйдет перенести их внутрь системы и где высвободится первая полставка. Разбор ничего не стоит. [Перенести отчёты в систему →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-original-platform-build-q4-2021-2022/ title: Ядро административной B2B-платформы за 342 часа: Laravel 8 и Sencha 6 type: case_study date: 2026-06-07T08:29:21+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Платформу с нуля можно завалить двумя способами. Гнать ядро ради скорости — и на третьем-четвёртом заказе доработок начнётся переписывание. Вылизывать архитектуру без оглядки на сроки — и заказчик перестанет понимать, за что платит, а проект забуксует на старте. Мы развели эти риски на уровне договоров: их было два. Первый закрывал ядро, второй добавлял модули, и с самого старта действовало правило «ядро не торопить ради модулей». С даты первого договора до сдачи платформы прошло 152 дня. На этом ядре потом выросло всё остальное: за следующие четыре с лишним года через тот же чат прошло несколько десятков заказов и ТЗ, и ни один не потребовал переписать ядро. ## Сводка Отрасль конечного клиента Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» — группа компаний, внутренняя платформа **Формат сотрудничества** **Прямая разработка по ТЗ, два последовательных договора** Тип проекта Административная B2B-платформа аналитики рынка сертификации, написанная с нуля на замену старой системе Объём работ Внутренний административный интерфейс над государственными реестрами аккредитованных лиц, деклараций и сертификатов соответствия; заложен под несколько стран ЕАЭС **Дата проекта** **17 сентября 2021 — 15 февраля 2022 (152 дня)** Трудозатраты **342 часа** (170 ч ядро + 172 ч модули) Команда Антон Херсун (руководитель проекта) и разработчик аналитической панели — он ведёт это направление с первого дня и до сегодня Технологический стек Laravel 8 · PHP 8 · Sencha 6 (ExtJS) · MariaDB · модульная архитектура **Сдано** **Работающее ядро и шесть модулей на замену старой версии аналитика, которую закрыли в марте 2022. На этом ядре за следующие годы выпустили несколько десятков итераций доработок.** ## Постановка задачи Заказчик работает с рынком сертификации продукции. У него уже была система аналитики, заточенная под узкий набор данных, и её решили закрыть. Понадобилась новая платформа, которая держала бы государственные реестры с разными структурами данных в одной аналитической среде и развивалась годами, а не до первого крупного изменения. ТЗ заказчик расписал по функциональным разделам: «Аккредитованные лица», «Декларации ТР ТС», «Сертификаты соответствия» и так далее. Платформа задумывалась как внутренний административный интерфейс: без публичной части, без внешнего API, доступ только сотрудникам группы. **Что в этом сложного.** Риск при найме партнёра под разработку с нуля простой: через полгода ядро упирается в архитектурные ограничения, и платить приходится второй раз — за то, что недавно приняли в эксплуатацию. В момент подписания ТЗ заказчик ещё не знает, какие из перечисленных разделов через год станут центральными, а какие отвалятся. Поэтому ядро мы делали с расчётом на десятую итерацию, а не на первую: каждый раздел сделан как самостоятельная единица, общий код между разделами не писали, а точки приёмки развели отдельно на ядро и на модули. ## Как мы это сделали **1. Два договора вместо одного: сначала ядро, потом модули.** Договор №1 от 17 сентября 2021 закрывал только ядро: серверная часть на Laravel 8 и PHP 8 (80 ч) и клиентская часть на Sencha 6 (90 ч), итого 170 ч. Договор №2 от 22 сентября добавлял модули поверх ядра: конструктор табличных данных, подключение существующих баз, выгрузку в Excel, фильтрацию-поиск-группировку, архивирование, документирование кода (172 ч). У бюджета появились две точки приёмки: заказчик увидел работающее ядро, и только после этого пошли модули. **2. Sencha 6 (ExtJS) для административной части, а не React.** «Почему не React?» — этот вопрос в 2021-м мы слышали чаще всего. Потому что речь об административном интерфейсе с тяжёлыми таблицами на сотни тысяч строк: Sencha grid держит их из коробки, а на React пришлось бы наращивать обвес из сторонних библиотек. Вторая причина — заявленный срок поддержки: на 2021 год у Sencha 6 он был семь и более лет, для внутреннего B2B-инструмента это весомее модности стека. К 2026 году выбор себя оправдал: интерфейс ни разу не переписывали по «технологическим» причинам, только расширяли под новые модули. **3. Каждый раздел как самостоятельный модуль, без общего кода между реестрами.** Реестров несколько, и у каждого своя структура полей. Если связать их общим кодом, любая правка под один реестр ломает соседний. Поэтому сделали иначе: один общий конструктор табличного отображения и отдельный конфиг полей для каждого раздела. Добавить новый реестр — это новый конфиг и, при необходимости, отдельный парсер источника; в общий код залезать не нужно. Решение окупилось не раз. Когда через год понадобился модуль «Аккредитованные лица» примерно на 30 тысяч записей, он подключился как новый раздел, без правок ядра. **4. Документирование кода как отдельная строка в смете на 10 часов.** В Договоре №2 есть явная строка «Документирование программного кода — 10 ч». На проектах с нуля это редкость: документацию обычно сдвигают на «потом», а оно так и не наступает. Здесь её внесли в объём работ и сдали по приёмке вместе с остальным. Для заказчика это страховка на случай смены разработчика: направление с первого дня ведёт один человек, но если когда-нибудь придётся передавать, будет с чего начать. **5. Конструктор полей вместо жёстко прописанного списка в коде.** Главное архитектурное решение модульной части, 40 часов в смете: администратор сам выбирает поля для отображения, подробного просмотра, выгрузки и поиска и привязывает таблицы к разделам меню. Без конструктора каждое изменение списка полей оборачивалось бы правкой кода и выкаткой новой версии; с ним настройка идёт через интерфейс, без перезапуска. Тот же конструктор позже лёг в основу всех табличных отчётов и групповой статистики, которые наращивались поверх платформы в следующие месяцы. ## Что показала первая зима эксплуатации Старую систему не выключили в день сдачи. Её гасили постепенно, по мере того как новая платформа забирала на себя данные, и окончательно вход в старый аналитик закрыли в начале марта 2022 года, когда заказчик подтвердил, что нужды в нём больше нет. Осторожность себя оправдала. В январе 2022-го при переносе исторических данных всплыл дефект старой схемы хранения: даты когда-то копировались по неправильному алгоритму, и у порядка 26 тысяч записей за 2018 год день превратился в год. Источник правки в старой системе было уже не найти. Разобрали алгоритм, исправили испорченные записи, а исторический пласт, который заказчику в общей таблице был не нужен, увели в архив. Здесь и пригодился модуль архивирования из Договора №2: данные не удаляются и не теряются, а уходят в отдельный слой. В новой платформе даты с самого начала лежат как даты, без копировальных схем, так что повтор инцидента исключён. Тогда же на платформе появились первые заказы поверх ядра, и не все они «взлетели». Один из ранних модулей, поиск продукции по сводным кодам ТР ТС и ТН ВЭД, мы сделали полностью: собрали базу примерно на 26 тысяч позиций, подняли формы поиска, сдали по акту — а применения заказчик ему в работе так и не нашёл. Вместо того чтобы дорабатывать впустую за оставшиеся в ТЗ часы, мы сами предложили закрыть направление и пустить остаток на полезную мелочь: честный статус «сделано, но не нашло применения» дороже, чем закрытый акт ради акта. Идея при этом не умерла. В 2023-м заказчик вернулся к ней с модулем «предложки», где сотрудники подают запросы-предложения со статусами и перепиской; ТЗ проработали и одобрили, но запуск заказчик отложил, и статус этой ветки прежний: одобрено, не запущено. ## Результаты Метрика Значение Часы по ТЗ **170 ч (ядро) + 172 ч (модули) = 342 ч** Календарь 17.09.2021 — 15.02.2022 · около 5 месяцев · 152 дня Команда 2 специалиста Модули в ядре конструктор таблиц, подключение баз, выгрузка в Excel, фильтрация-поиск-группировка, архивирование, документирование Замена старой системы старый аналитик погашен постепенно и закрыт в марте 2022, с переносом и чисткой исторических данных Развитие после сдачи **несколько десятков заказов и ТЗ за следующие четыре с лишним года — без переписывания ядра** Что получилось: административная B2B-платформа с собственным конструктором табличных данных, модульной архитектурой по реестрам, выгрузкой в Excel и системой архивирования. На этом ядре за следующие годы выросло несколько крупных направлений: парсинг иностранных реестров, аналитика и групповая статистика, конструктор шаблонных документов, интеграции с amoCRM и Битрикс24. ## Процесс и хронология Этап Когда Результат Исследование задачи, ТЗ на ядро сентябрь 2021 Договор №1 подписан 17.09.2021, ТЗ зафиксировано, выбран стек Сборка ядра сентябрь–октябрь 2021 Серверная часть на Laravel, клиентская часть на Sencha 6 (170 ч) ТЗ на модули, параллельный старт 22.09.2021 Договор №2 подписан до завершения ядра, чтобы команда не простаивала Сборка модулей осень 2021 — зима 2022 6 модулей по плану (172 ч) Первые заказы поверх ядра декабрь 2021 — февраль 2022 Групповая статистика открыта пользователям 17.12.2021; доп. функционал отчётов на тесте 20.01.2022 Перенос данных, исправление дат январь 2022 Дефект старой схемы дат локализован и исправлен, исторический пласт уведён в архив Приёмка и замена старой системы февраль–март 2022 Платформа принята, старый аналитик закрыт окончательно _Договор №2 подписан до завершения ядра, чтобы этапы шли внахлёст и команда не простаивала между ними. Разница между суммой рабочих этапов и 152 календарными днями — это ритм согласований у заказчика и обычные праздничные паузы._ ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта, архитектор, формализация ТЗ, работа с заказчиком - **Разработчик аналитической панели**: ведёт основную платформу с первого дня и до сегодня. Кто написал модуль в 2021-м, тот его и правит сейчас. Любая доработка спустя годы остаётся в руках того же человека, без передачи кода между людьми. ## Скриншоты и материалы _Будут добавлены отдельным проходом после согласования с заказчиком: внутренний интерфейс требует обработки приватности перед публикацией._ > Если планируете сборку B2B-аналитики с нуля и не уверены, что выбрать в стеке, пришлите бриф и список интеграций. Скажем, где можно сэкономить на стандартных модулях и где придётся писать руками. Разбор бесплатный. [Обсудить сборку аналитики →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-amocrm-integration/ title: Виджет аналитики сертификации в amoCRM: документы по ИНН/ОГРН и подписки за месяц type: case_study date: 2026-06-07T08:29:21+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- У клиента два рабочих инструмента: amoCRM как основное окно менеджеров по продажам и наша платформа, которая закрывает внутреннюю аналитику по сертификации продукции. Без интеграции менеджер живёт в двух окнах: в одном карточка сделки, в другом аналитика по контрагенту, и ИНН или ОГРН он вручную носит из первого во второе. Виджет должен был свести эти окна в одно. Сделали то, что согласовали и закрыли актом: виджет в карточке плюс движок подписок-уведомлений. Несколько расширений к виджету просчитали в часах, но заказчик в работу их так и не отдал — в кейсе показываем и их. Через 2 года клиент решил не продлевать amoCRM и перейти на Битрикс24, и виджет штатно вывели из эксплуатации. Честная развязка: интеграция прожила ровно столько, сколько прожила сама CRM на стороне клиента. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение — интеграция amoCRM с внутренней платформой** Тип проекта Виджет аналитики в карточке amoCRM + подписки-уведомления об отслеживаемых контрагентах Объём работ ТЗ: виджет и движок уведомлений (45 ч, сдано). Расширения — синхронизация базы заявителей (80 ч) и сводка «дата последнего документа» (26 ч) — оценены, но в работу не отданы **Дата проекта** **Август 2022 (запуск) — июнь 2024 (вывод из эксплуатации при переезде на Битрикс24)** Трудозатраты **45 часов по ТЗ** (сданная часть) Команда Антон Херсун (руководитель проекта) и разработчик аналитической панели — интеграцию amoCRM он ведёт с первого дня Технологический стек API amoCRM · сервер на Laravel · пользовательский виджет amoCRM · движок подписок и уведомлений **Сдано** **Виджет в карточке amoCRM (поиск аналитики по ИНН/ОГРН), движок подписок и уведомлений о новых документах по отслеживаемым контрагентам** ## Постановка задачи Менеджер открывает карточку сделки в amoCRM. Чтобы понять, сколько у компании сертификатов и деклараций и по каким техрегламентам, ему нужно идти в другое окно и копировать туда ИНН или ОГРН. Раз в день это терпимо, 30 раз в день — уже нет. Развилка, которая определила архитектуру, вылезла из переписки сразу. Изначально предлагали показывать сводку в правой колонке amoCRM, в штатных виджетах, но там мало места: полноценная аналитика туда не помещается. Поэтому остановились на отдельном виджете — он распознаёт поле ИНН/ОГРН в карточке и выводит всплывающее окно с данными из нашей платформы. Второй пласт задачи: не разовый просмотр, а отслеживание. Менеджеру важно узнавать, когда у отслеживаемой компании появляется новый документ, а не просто смотреть текущую картину. Это уже не виджет, а подписка: набор «пользователь — ИНН», мониторинг новых документов по этим ИНН и доставка уведомлений в amoCRM и на почту аккаунта. Был и третий запрос, от стороны заказчика: показывать дату последнего документа прямо в списке сделок, по всем ~30 тысячам карточек, не заходя внутрь. Его просчитали отдельно, об этом ниже. **Что в этом сложного.** Сам виджет в amoCRM несложно написать. Сложно заставить его работать каждый день без падения, когда amoCRM меняет правила доступа к своему API, а портал на стороне клиента живёт своей жизнью. Например, amoCRM по соображениям безопасности отказывается сообщать виджету, какой именно пользователь сейчас работает в системе. Это ограничение приходится закладывать в саму модель подписок: кто увидит иконку у ИНН, кто получит всплывающее уведомление, а кто прочитает его только в общем списке. Не проговоришь этого заранее — и менеджеры решат, что «уведомления не приходят», хотя они приходят. ## Как мы это сделали **1. Тонкий виджет: вся логика на нашей стороне.** Виджет в карточке делает минимум: вытаскивает ИНН или ОГРН и отправляет запрос на наш сервер на Laravel. Сервер ходит во внутреннюю платформу, собирает аналитику по контрагенту (количество сертификатов и деклараций, технические регламенты, динамику) и возвращает готовую страницу. В самом amoCRM бизнес-логика не живёт вообще — только встройка. Решение сознательное: любое обновление CRM ломает то, что лежит у неё внутри, поэтому внутри должно лежать как можно меньше. Перед открытием бывает небольшая задержка, пока виджет ждёт ответа от базы. Отдельно учли особенность данных: в киргизских реестрах у контрагента прописан только ИНН, в российских стоит ОГРН, но по сути это один и тот же идентификатор. Сервер ищет компанию и в российских, и в киргизских таблицах. **2. Окно, которое не должно мешать работе в CRM.** Виджет показывает окно поверх карточки, и оно конкурирует за экран с самим amoCRM. По обратной связи от менеджеров за первую же неделю окно научили менять размер, свободно ездить по экрану, запоминать размер при следующем открытии и сворачиваться в строку, чтобы не закрывать работу со сделкой. Мелочь, но без неё виджетом просто перестают пользоваться. **3. Движок подписок: набор «пользователь — ИНН».** Поверх просмотра построили отслеживание. Менеджер оформляет подписку на контрагента по его ИНН, и пара «пользователь — ИНН» в системе единственная: если тот же ИНН попытаются отследить из другой сделки, система это поймет и предупредит, а не заведёт молчаливый дубль. Раз в сутки движок сверяет отслеживаемые ИНН с новыми документами в платформе. Появился документ — уведомление уходит ответственному менеджеру и внутрь amoCRM, и на почту аккаунта, а по клику из него менеджер проваливается в нужную сделку. **4. Две версии за месяц, с честным предупреждением о простоях.** Первую версию виджета, ещё без уведомлений, запустили 8 августа 2022. Систему уведомлений доделывали ещё 2 недели и 23 августа переключили amoCRM с первой версии на вторую. Переключались вживую, на рабочем портале, поэтому заранее предупредили заказчика: пока идёт миграция версии, возможны временные сбои, а тестовые уведомления в этот период не настоящие. Работу приняли и закрыли актом 2 сентября 2022, нареканий на уведомления не было. **5. Где упёрлись в ограничение amoCRM.** В день переключения на вторую версию у части пользователей виджет перестал открываться. Разобрались быстро. Часть клиентов ходила на старый адрес, это лечилось обновлением страницы, но корневая причина сидела глубже: виджет спрашивал у amoCRM по `api v4 users`, какой пользователь сидит в системе, а amoCRM отвечал «узнавать запрещено». Это не баг, а политика платформы, и модель уведомлений пришлось строить вокруг неё: пользователь, который сейчас в системе под своим логином, видит иконку у ИНН и всплывающее уведомление, остальные читают то же самое в общем разделе уведомлений amoCRM. ## Что осталось в статусе оценённого Не всё, что обсуждали по этой интеграции, дошло до запуска. Два расширения просчитали в часах и отдали заказчику на решение — на нём они и остались. Показываем их честно, потому что дисциплина «оценка → согласование → работа» действует в обе стороны: если заказчик не согласовал, работа не стартует. **Дата последнего документа в списке сделок (26 ч, не запущено).** Сторона заказчика хотела видеть дату последнего оформленного документа прямо в канбан-списке amoCRM, по всем ~30 тысячам сделок: менеджер выбирает компанию для проработки, не открывая карточку. Решение спроектировали без виджета. В карточке заводится отдельное поле «дата последнего документа», скрипт получает через API amoCRM список всех активных сделок, подключает их к мониторингу дат по ИНН и раз в сутки обновляет карточки через тот же API. Риск отметили отдельно: ещё надо проверить, как amoCRM вообще даст обновлять 30 тысяч карточек за проход. Оценка вышла в 26 часов. Ответ заказчика: «Подумаем». На этом задача и остановилась. **Синхронизация базы заявителей с amoCRM (80 ч, зависло на согласовании).** Самостоятельное ТЗ: выгружать заявителей из нашей платформы в amoCRM как сделки, разложенные по воронкам («Заявители», «Производители РФ», «КЗ», «ДФО»), с отсечкой компаний, у которых меньше 3 документов за 2 месяца, чтобы в CRM не сыпался шум. Оценили в 80 часов, оформили план и дополнения. До запуска дело не дошло: согласование затянулось, да и часть команды в тот период переезжала, так что старт всё время сдвигался. ТЗ так и осталось согласуемым. ## Инцидент: 404 на казахстанском портале Через 9 месяцев после запуска, в мае 2023, прилетела жалоба: виджет тормозит, а на казахстанском портале на любой карточке отдаёт 404 — при этом в России всё работает. География подсказала направление. Виджет кодирует данные аккаунта, из которого идёт запрос, и для конкретного казахстанского аккаунта части этих данных не хватало, отсюда и 404 ровно на этом портале. Запросили доступ к проблемному аккаунту, посмотрели, чего не хватает в кодировании, и поправили. Российские порталы не трогали: проблема была локальной, в одном аккаунте. ## Развязка: уход с amoCRM на другую CRM История интеграции закончилась не поломкой, а сменой платформы у клиента. В мае 2024 заказчик решил не продлевать amoCRM с 29 мая. Раз CRM уходит, уходит и всё, что к ней привязано: в июне мы предложили отключить виджет и его серверную обработку, чтобы не держать живой код под мёртвой системой, и 21 июня 2024 виджет вывели из эксплуатации. Аналитику в карточках клиент при этом не потерял. Направление переехало на Битрикс24, и тот же принцип «тонкий виджет, логика на нашем сервере» лёг в основу нового виджета уже под Битрикс — это отдельная история и отдельный кейс. Здесь важно другое: интеграция с amoCRM отработала свой срок и закрыта чисто, без брошенного кода и зависших процессов на чужом портале. ## Результаты Метрика Значение Сдано по ТЗ Виджет аналитики в карточке + движок подписок-уведомлений, **45 ч** Время запуска v1 — 8 августа 2022, v2 с уведомлениями — 23 августа, закрыто актом — 2 сентября 2022 Точки встраивания Карточка сделки amoCRM (поиск аналитики по ИНН/ОГРН), уведомления в amoCRM и на почту аккаунта Оценено, но не запущено Дата последнего документа по списку (~30 тыс. сделок, 26 ч); синхронизация базы заявителей по воронкам (80 ч) Инцидент и реакция 404 у казахстанского аккаунта (05.2023) — диагностирован как нехватка данных в кодировании аккаунта, исправлен Вывод из эксплуатации amoCRM не продлён с 29.05.2024, виджет штатно отключён 21.06.2024, направление переехало на Битрикс24 ## Процесс и хронология Этап Период Результат ТЗ и оценка виджета июль 2022 План и цена по ТЗ (45 ч) Запуск виджета v1 август 2022 Поиск аналитики по ИНН/ОГРН в карточке Движок уведомлений, v2 август 2022 Подписки по ИНН, уведомления в amoCRM и на почту аккаунта Приёмка сентябрь 2022 Акт по ТЗ Расширения (оценены) август–сентябрь 2022 «Дата последнего документа» и синхронизация базы — не запущены Инцидент 404 (КЗ) май 2023 Исправление кодирования данных аккаунта Вывод из эксплуатации июнь 2024 Отключение виджета при переезде на Битрикс24 ## Команда - **Антон Херсун, Xaver Pro** — руководитель проекта: проектирование виджета и модели подписок, согласование ограничений amoCRM, запуск версий вживую на рабочем портале, разбор инцидента и вывод из эксплуатации. - **Разработчик аналитической панели** — серверная часть на Laravel: агрегация аналитики по контрагенту, движок подписок и доставка уведомлений. Интеграция amoCRM относится к направлению аналитической панели, и ведёт его этот разработчик с первого дня. Контекст «как устроен поиск по ИНН/ОГРН на нашей стороне» держит тот же человек, что пишет правки, поэтому передавать его между людьми не приходится. ## Скриншоты и материалы _Будут добавлены отдельным проходом._ > Если ваш amoCRM и внутренняя аналитика разъезжаются по разным окнам, и менеджеры вручную переносят ОГРН, пришлите выгрузку базы. Посмотрим, какие связки можно поднять без переезда инфраструктуры. За разбор денег не берём. [Связать amoCRM и аналитику →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-certification-templates-automation/ title: Шаблоны сертификационных документов: конструктор на тэговой разметке type: case_study date: 2026-06-07T08:29:21+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Сотрудник сертцентра открывает шестой за утро docx-протокол испытаний и в шестой раз вбивает одни и те же реквизиты заявителя, продукции, изготовителя. Каждый шаблон лежал отдельным Word-файлом, заполнение шло ручным переносом. Мы свели десятки разрозненных docx в один конструктор внутри аналитической платформы — и новый шаблон теперь заводит сам оператор, без программиста. В сертификационном бизнесе протокол испытаний, декларация о соответствии, акт идентификации заполняются по фиксированной форме: сотрудник подставляет данные конкретной продукции. У клиента таких форм было 70–100 под разные категории продукции и технические регламенты. Сгенерировать docx умеет любая библиотека. Сложность в другом: сделать так, чтобы добавление сто первого шаблона не упиралось в очередь к разработчику. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение — серия ТЗ по модулю шаблонов (2022–2025)** Тип проекта Конструктор шаблонных документов внутри B2B-платформы аналитики Объём работ Импорт docx-шаблонов с тэговой разметкой, генерация с пулом номеров и случайными значениями, доп-файлы лабораторий, шаблоны без печатей, права по компаниям **Дата проекта** **2022 — основной модуль, далее точечные доработки до 2025** Трудозатраты **более 300 часов** согласованных по ТЗ (тэговый конструктор — 160 ч; пул номеров и статистика — 65 ч; документы без печатей — 40 ч; и серия доработок) Команда Антон Херсун (руководитель проекта) и разработчик аналитической панели — он ведёт это направление с первого дня и до сегодня Технологический стек Laravel · Sencha 6 · docx с тэговой разметкой · xlsm как внешний источник **Сдано** **Модуль импорта и хранения шаблонов, генерация через тэговую разметку, пул номеров с бронированием, случайные значения в полях испытаний, доп-файлы лабораторий, шаблоны без печатей, разграничение по компаниям и ролям** ## Постановка задачи Сотрудники клиента работают с тремя типами шаблонных документов: протоколы испытаний, декларации о соответствии, акты идентификации продукции. По каждому типу в обороте десятки шаблонов под разные категории продукции и регламенты — заказчик называл цифру 70–100. Раньше каждый шаблон был отдельным docx: сотрудник открывал нужный и заполнял руками, а копии нужной версии расползались по компьютерам. Заказчик хотел централизованное хранилище шаблонов внутри уже работающей у него платформы аналитики, с поиском по типу и названию, и чтобы система сама генерировала документ из данных заявителя. Главный вопрос он задал прямо на старте: насколько реально дать сотрудникам **самостоятельно** добавлять новые шаблоны в конструктор? Этот вопрос и стал осью всего проекта. **Что в этом сложного.** Самое уязвимое в шаблонной автоматизации не генерация docx, а то, что через год у программиста копится очередь «добавьте ещё один шаблон». Если каждая форма требует правок кода, модуль превращается в узкое место. Поэтому контракт между оператором и системой мы заложили в саму разметку документа: оператор размечает Word-файл тэгами и сам же его загружает. ## Как мы это сделали **1. Тэговая разметка в docx как контракт между оператором и системой.** Центральное решение модуля (160 ч): оператор берёт обычный Word-документ и проставляет в нём тэги вида `{{поле}}` там, где должны встать данные. Одинаковый текст помечается одинаковым тэгом. При генерации система разбирает разметку, строит форму ввода и подставляет значения. Строковых тэгов в одном шаблоне может быть сколько угодно — хоть тысяча. Новый шаблон загружается через интерфейс как обычный размеченный docx: программист пишет генератор один раз — оператор добавляет формы сколько угодно раз. Уже имеющиеся 70 документов мы сознательно не размечали за клиента. Где какое поле подставить, знают только его сотрудники, и они по мере работы разметили шаблоны сами. **2. Случайные значения в полях испытаний.** В протоколах испытаний часть числовых полей содержит результаты измерений в допустимых границах. Чтобы сотрудник не выдумывал эти числа вручную для каждого документа, в разметку заложили генерацию случайных значений прямо в такие поля при создании документа, а позже добавили и повторную перегенерацию на готовом документе. По описанию мелочь. По факту она экономит время на каждом протоколе. **3. Пул номеров с бронированием (65 ч).** Каждый документ должен получить свой регистрационный номер из заранее заданного диапазона. Сделали пул номеров: оператор пополняет его сам, номер бронируется за документом, у каждой компании пул свой. Здесь же всплыла тонкость, которую разобрали заранее. Автоматически подставить номер по тэгу нельзя: в разных шаблонах это поле называется по-разному, и система не понимает, куда вставлять. Предложили два пути: отдельный тэг под номер либо кнопку бронирования с ручной вставкой. Заказчик выбрал тот, который не ломал свободу разметки. Дату бронирования привязали к часовому поясу, и позже это помогло корректно фильтровать документы по дате брони. **4. Доп-файл лаборатории при генерации.** У лаборатории-исполнителя испытаний свои реквизиты, печать, аккредитационный номер. Сделали так: когда при генерации выбрана лаборатория, рядом с основным документом формируется второй файл по тексту, заданному для этой лаборатории, и все тэги шаблона применяются к обоим файлам. Нет текста — нет второго файла. Есть у лаборатории и флаг «учитывать даты при бронировании», который влияет на подсчёт остатка номеров. **5. Шаблоны без печатей и подписей для черновиков (40 ч).** Сотрудники часто отправляют клиенту черновик протокола на согласование, а черновик не должен нести печати и подписи. Раньше пришлось бы держать два комплекта шаблонов. Вместо этого ввели генерацию второго файла без печатей и массовое скачивание таких документов по списку: один комплект шаблонов закрывает и финальные документы, и черновики. **6. Права по компаниям и роли.** По шаблонам у клиента работали две компании, и шаблоны одной не должны были попадаться на глаза другой. Завели у пользователя принадлежность к компании, у администратора — справочник компаний, и шаблоны стали видны только внутри своей. К этому добавились отдельные роли доступа к разделу шаблонов: «Сотрудник ТО», «Руководитель ТО», позже «менеджер и шаблоны». А когда заказчик попросил разделить сотрудников по компаниям ещё до того, как под это оформили отдельное ТЗ, мы сделали доработку бонусом, зачётом в уже оплаченный заказ. ## Дисциплина процесса Модуль рос не одним куском, а серией ТЗ с честной оценкой по каждому. Как мы относимся к чужому бюджету, лучше любого описания показывает пара эпизодов. Заказчик хотел тэг дат с автопересчётом: при смене основной даты сами пересчитываются даты испытаний, с учётом красных дней производственного календаря. Мы оценили работу примерно в 30 часов и сами же отговорили: «штучка простая на вид, но в реализации стоит как феррари». В ТЗ её даже не стали описывать — чтобы не закладывать в смету заведомо невыгодный пункт. Отдельно заказчик просил генерировать документы сразу в Word и PDF, архивом. Мы прогнали тестовые шаблоны и показали, что конвертер не от самого Word даёт расхождения: лишние разрывы страниц, мелкие смещения. Вывод дали прямой: менеджер не глядя отправит кривой PDF в работу. От задачи отказались — хотя могли её взять. И ещё мельче, но в ту же сторону. В одном из ТЗ заказчик попросил «выдачу свежих номеров»; мы разобрались и ответили, что это не доработка, а невыставленная галка в настройках лаборатории — её достаточно включить. Платить тут было не за что. ## Результаты Метрика Значение Часы по ТЗ **более 300 часов** согласованных Заказы Серия ТЗ по модулю шаблонов + точечные доработки Самообслуживание оператора Новые шаблоны размечаются и загружаются через интерфейс, без программиста Случаи документов Протоколы, декларации, акты идентификации, доп-файлы лабораторий, черновики без печатей Нумерация Пул номеров с бронированием, отдельный под каждую компанию Разграничение Шаблоны по компаниям, роли доступа к разделу Что получилось: тэговая разметка прямо в docx работает как единый контракт между человеком и системой, и именно она снимает основную часть очереди «допилите ещё один шаблон». Регистрацию документов закрывает пул номеров с бронированием. Спецслучаи (доп-файл лаборатории, черновики без печатей) живут поверх одного тела шаблона, а случайные значения в полях испытаний убирают ручной ввод чисел. ## Процесс и хронология Этап Период Результат Модуль импорта и хранения шаблонов, тэговая разметка, случайные значения I–II квартал 2022 160 ч Пул номеров с бронированием + инструменты статистики лето 2022 65 ч Доп-файл лаборатории при генерации август 2022 точечная доработка Доработки: импорт, комментарии, копирование с бронью январь 2023 пакет доработок Шаблоны без печатей и подписей май 2023 40 ч «Мои документы»: поиск и смена шаблона с автозаполнением июль 2023 точечная доработка Уведомление об остатке номеров август 2023 точечная доработка Прорабатывалось: автозаполнение из внешнего Excel 2025 приостановлено заказчиком В 2025-м заказчик предложил автозаполнять шаблоны из того же Excel-файла фиксированной структуры, который сотрудники уже используют в другой программе, чтобы вводить данные один раз. Мы разобрали формат файла и логику привязки полей к тэгам, но запуск заказчик поставил на паузу из-за внутренней реформации техотдела. Идея проработана и готова к запуску — когда у клиента вернётся приоритет. ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта: формат тэгов, разметочный контракт, оценки и согласование ТЗ. - **Разработчик аналитической панели**: серверная и клиентская части модуля шаблонов. Он ведёт это направление с первого дня и до сегодня: модуль 2022 года и доработки 2023–2025 делал один и тот же человек. Правки сегодня вносит тот, кто писал этот код несколько лет назад, и никаких «наследники не разобрались». ## Скриншоты и материалы _Будут добавлены отдельным проходом. Нужны примеры размеченного docx и сгенерированных документов после обработки приватности конкретных названий продукции._ > Если в вашем сертцентре одни и те же реквизиты вбивают в шесть шаблонов подряд, а правка одной формы занимает день, покажите три шаблона и пример отчёта. Оценим, во что выйдет перенести генерацию внутрь системы. Оценка бесплатная. [Прислать шаблоны на расчёт →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-telegram-bot/ title: Telegram-бот для аналитической платформы: ТЗ, две версии оценки, прототип type: case_study date: 2026-06-07T08:29:21+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Менеджер сидит на встрече, в руке телефон, в телефоне открыт Telegram. Клиент спрашивает: «По какому регламенту наш продукт сертифицируется?» Идея была проста: пусть в этом же Telegram отвечает бот — сразу, пока менеджер ещё разговаривает с клиентом. Мы написали ТЗ с двумя вариантами оценки, согласование застряло, и в продакшен бот не вышел. Ниже — почему так получилось и что от этого ТЗ осталось. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение — отдельный ТЗ с двумя вариантами оценки** Тип проекта Прототип Telegram-бота как канала связи менеджера с базой данных платформы и техническим отделом Объём работ ТЗ с двумя вариантами оценки: полная версия (поэтапный диалог, морфологический разбор, идентификация с уточнениями, связь с техотделом) и демо (упрощённый диалог) **Дата проекта** **Июль–сентябрь 2022 — ТЗ и обсчёт подготовлены; согласование застряло** Трудозатраты **Не выставлялись.** В смете план-цены зафиксированы две оценки (полная и демо), но согласования и сборки не было Команда Антон Херсун (руководитель проекта; написал ТЗ и обсчёт). Разработчик не назначался. Технологический стек (планировался) Telegram Bot API · сервер на Laravel · лингвистический и морфологический разбор · интеграция с аналитической базой **Статус** **Прототип. ТЗ подготовлено, в продакшен не вышло.** ## Постановка задачи Менеджеру в переговорке или на встрече нужен быстрый ответ: есть ли сертификат на такой-то продукт, какой технический регламент, какой тип объекта (серийный, партия, единичное изделие). В платформе этот ответ есть, но залезать в админ-интерфейс посреди разговора неудобно. А Telegram уже открыт: в нём менеджер и общается с клиентом. Идею обсудили со стороной заказчика, после чего мы написали ТЗ и обсчёт. В чате это зафиксировано коротко: «Готово ТЗ и обсчёт по чатботу» (2022-07-04). В спецификацию заложили 5 свойств бота: 1. **Пошаговые запросы.** Бот собирает данные не одним сообщением, а по шагам. Сначала развилка: идти от наименования товара или от регламента. Дальше уточнения наименования, области применения и типа. 2. **Лингвистическая нормализация.** Если пользователь ввёл «металическая», а в базе лежит «Металлическая», система должна сопоставить и вернуть нужное значение. В ТЗ это отдельный этап: «по запросу „Армотура“ система скорректирует ошибку и найдёт всё по „Арматура“». 3. **Идентификация с уточнениями.** Если наименование «Упаковка пищевой контейнер» пересекается с несколькими записями, бот выдаёт меню выбора («Упаковка пищевой продукции», «Упаковка парфюмерной продукции», «Упаковка игрушек для детей», «Хранение пищевой продукции в домашних условиях», «Упаковка прочей продукции») и **спрашивает**, а не угадывает. 4. **Несколько регламентов на один продукт.** Продукция может сертифицироваться сразу по нескольким регламентам: бытовой холодильник требует сертификата по ТР ТС 004 и 020 плюс декларации ТР ТС 037. Бот должен вернуть полный набор со схемами, а не один документ. 5. **Связь с техническим отделом.** Если менеджер не знает наименования, запрос уходит в личный чат специалиста техотдела. Ответ возвращается в бота и записывается в базу. То есть бот читает справочник наименований и заодно пополняет его руками техотдела. **Что в этом сложного.** Главный риск B2B-чат-бота — доверие к ответам. Стоит боту хотя бы раз вернуть ответ из другой категории продукции, потому что наименование «похоже», и менеджер перестанет ему верить, вернётся в привычный админ-интерфейс. Поэтому базовый принцип, заложенный в ТЗ: бот не угадывает, а уточняет. Медленнее, зато правильно. Бот, который один раз выдал не тот регламент, страшнее бота, который переспросил лишний раз. ## Что мы зафиксировали в ТЗ **1. Пошаговый диалог вместо одного длинного запроса.** Менеджер пишет боту, бот ведёт по шагам и на каждом проверяет ввод. В ТЗ прописаны оба сценария целиком: от наименования («Уточните наименование продукта» → «Уточните область применения» → готовый ответ с документом и схемой) и от регламента. Пользователю не нужно собирать весь запрос в одну фразу — бот сам доведёт его до ответа. **2. Нормализация: «металическая» = «Металлическая».** Планировали библиотеку лингвистического и морфологического разбора: она приводит варианты с опечатками и разной морфологией к канонической форме из базы. Без неё пользователь набирал бы с ошибками и получал «не найдено» — классическая беда поиска по справочнику. В смете это отдельный этап на 20 часов: морфологический разбор стоит дороже остального диалога и в полной версии вынесен в самостоятельный блок. **3. Уточнение области применения через выбор из списка.** Когда наименование совпадает с несколькими записями, бот отдаёт меню кнопок, и пользователь выбирает нужное. Уточнение идёт шаг за шагом, без угадывания. Тот же приём для типа объекта: бытовое или промышленное назначение влияет на схему сертификации. **4. Растущая база наименований через техотдел.** Сценарий «менеджер не знает наименование» не упирается в тупик: запрос уходит специалисту, ответ пишется обратно в базу — и в следующий раз бот ответит сам. Статичный справочник так со временем превращается в базу знаний, которую техотдел пополняет по ходу обычной работы. **5. Демо как отдельный объём.** В ТЗ заложены два варианта оценки. Демо сводится к урезанному диалогу: одна учётная запись менеджера, без связи с техотделом и **без лингвистического разбора вообще**. Из сметы убран весь этап морфологии, срезаны часы на ядро и сценарии. Расчёт простой: заказчик сначала проверяет саму механику бота на ограниченном сценарии, а уже потом решает про полную версию. Развилка «полная или демо» — третий вариант между «всё» и «ничего». **6. Одна учётная запись на каждой стороне в первой итерации.** В ТЗ так и написано: в первой итерации — одна учётная запись Telegram у менеджера и одна у специалиста техотдела. Это снимает с прототипа целый пласт сложности с правами и сессиями. Многопользовательская модель уходит в следующую итерацию. ## Две оценки в смете В смете план-цены ТЗ разложено на этапы, и по этой раскладке видно, чем демо отличается от полной версии. Этап Полная версия Демо Ядро чат-бота есть есть, в урезанном объёме Интеграция с базой платформы есть есть Лингвистический и морфологический разбор есть **убран целиком** Разработка сценариев полный набор сокращённый Связь с техотделом есть **убрана** Оценка по смете полная (~3 недели) демо (~1,5 недели) Числа в часах остались в самих файлах сметы, но это была именно оценка под согласование. Ни счёта, ни акта по ТЗ не выставлялось, поэтому в кейс выносим не трудозатраты, а саму логику: где проходит граница между «попробовать» и «сделать как надо». ## Почему в продакшен не вышло ТЗ и обсчёт были готовы 4 июля 2022 — дальше всё упёрлось в согласование на стороне заказчика. В сентябре он сформулировал это прямо: «По чат-боту пока медленно идёт согласование. Но думаю, в итоге мы дойдём до его реализации» (2022-09-02). Не дошли. Параллельно шли задачи, которые согласовывались быстрее: виджет для amoCRM с документами по ИНН/ОГРН, доработки общего отчёта, дальше таблица аккредитованных лиц и ферма парсинга. Бюджет и внимание уходили туда. К Telegram-боту возвращались разговором, но в текущий объём работ так и не включили. Тема всплывала ещё дважды. В 2024-м мы делали прототип ИИ-аналитика: запросы к базе на естественном языке закрыли ту же боль с другой стороны (это отдельный кейс). А в августе 2025-го, спустя 3 года после ТЗ, к идее бота вернулись снова: «по чат-боту делал поиск готовых решений, пока ничего нормального не нашёл». Идея живёт, а проработанное ТЗ так и лежит. ## Результаты (на сегодня) Метрика Значение Статус **Прототип. В продакшен не вышел.** Артефакты ТЗ с двумя вариантами оценки (полная и демо), сценарии диалога, обсчёт по этапам Заказы 1 отдельный ТЗ Что зафиксировано Архитектура диалога, перечень свойств, граница демо/полной версии, раскладка по этапам Что не сделано Разработка. Согласование застряло, заказ не открыли. ## Команда - **Антон Херсун, Xaver Pro**: руководитель проекта, написание ТЗ и обсчёт в двух вариантах - **Разработчик не назначался.** ТЗ остался на стадии оценки: согласование на стороне заказчика не завершилось, заказ в работу не открывали. ## Скриншоты и материалы _Не применимо: прототип, продакшен-интерфейса нет._ > Если у вас ТЗ, которое полгода лежит без движения, но всё ещё кажется полезным, покажите. Скажем, что в нём устарело, что можно поднять за минимальный объём как прототип и стоит ли его вообще размораживать. Первичная оценка бесплатна. [Разморозить ТЗ →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-russian-registry-parsing-core/ title: Парсинг российского реестра сертификатов и деклараций (ФСА): инженерная живучесть к враждебному источнику type: case_study date: 2026-06-07T08:29:21+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Вся платформа стоит на одном источнике, которым нельзя управлять. Государственный реестр деклараций и сертификатов отдаёт данные так, как сегодня захотел его сервер: вчера по дате находилась тысяча документов, сегодня вдруг десять миллионов; в пятницу прокси работали, в субботу все машины в бане; в декабре сменилась серверная инфраструктура, и парсер замолчал. А клиентская аналитика обязана оставаться полной и свежей — при любой погоде на той стороне. Заказчик сформулировал коротко: парсер — это основа. Этот кейс про то, как держать основу живой, когда источник четыре года подряд меняется, банит и ломается. ## Сводка Отрасль конечного клиента Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» — внутренняя платформа группы компаний **Формат сотрудничества** **Регулярное сопровождение — ядро платформы, поток реакций на изменения внешнего источника** Тип проекта Парсер российского реестра деклараций и сертификатов (ФСА / Росаккредитация) как исходный движок всей системы Объём работ Приём легаси-движка, перевод на современную архитектуру, многолетняя поддержка и реакция на инциденты источника **Дата проекта** **ноябрь 2021 — продолжается, больше четырёх лет** Трудозатраты Ферма парсинга оформлена в составе пакета ТЗ; основной объём идёт через абонентское сопровождение и реакцию на инциденты Команда Антон Херсун (руководитель проекта; принял парсинг как легаси, разобрал и перевёл на очереди Laravel руками сам), направление поддерживается внутри команды; последние заказы по парсингу частично подхватил разработчик виджетов и парсеров Технологический стек Laravel 5.5.50 · Laravel Horizon · очереди и задания · Redis · Docker · ClickHouse · собственная система ротации HTTPS-прокси · мини-ферма недорогих российских серверов **Сдано** **Парсер реестра ФСА на очередях, инкрементальное возобновление с места обрыва, посуточная статистика сбора, авто-реакция на сбои** ## Постановка задачи Платформа живёт на публичных данных российского реестра: декларации соответствия и сертификаты, которые ФСА выкладывает в открытый доступ. Полноценного публичного API нет. Есть веб-выдача по дате: парсер спрашивает у неё «дай все документы за такое-то число» и разбирает ответ постранично. Источник государственный, его поведение никто со стороны не контролирует, и менять это поведение он может в любой день без предупреждения. К нам этот движок пришёл как чужой код. До команды парсингом занимался сторонний разработчик, и работал он на ручном приводе: что-то собиралось, что-то отваливалось, а понять, где именно встало, было нельзя — нормальной статистики просто не было. В ноябре 2021 года заказчик отказался от прежней схемы и передал парсинг команде целиком. Антон сразу обозначил план: переписать всю систему на полную автоматику и добавить посуточную статистику, сколько и где спарсилось, что не спарсилось, что отвалилось или попало в бан, чтобы реагировать оперативно и быть в курсе. Передавать направление дальше внутри команды стали только после того, как легаси разобрали руками и перевели на единую архитектуру. ## Что в этом сложного Сложность не в том, чтобы разобрать HTML. Сложность в том, что противоположная сторона ведёт себя как живой противник, хотя злого умысла за ней нет. За четыре года реестр успел: начать отдавать «десять миллионов сертификатов» на любой запрос и подвесить этим наши сервисы; закрыться от заграничных прокси; забанить все парсер-машины разом в пятницу вечером; умереть посреди прохода по страницам и тихо недодать половину деклараций; сменить серверную инфраструктуру так, что старый парсер замолчал; и под конец выставить жёсткий лимит выдачи — двадцать страниц на запрос. Каждое из этих изменений по отдельности останавливает сбор, и узнать о нём можно либо по тишине в логах, либо по жалобе аналитика, что данные за неделю не обновились. Поэтому архитектуру строили вокруг одного принципа: способ получения данных можно менять сколько угодно, а накопленная база и схема хранения остаются целыми. ## Как мы это сделали **1. Парсер на очередях Laravel под Horizon, а не cron-скрипт.** Логику сбора вынесли в задания Laravel; поверх работает Horizon как менеджер очередей, под ним Redis. Очередь даёт перезапуск задания при падении, пересбор конкретного периода по требованию без ожидания расписания и общую панель вместо разрозненного мониторинга. Когда реестр недодаёт документы, в очередь просто ставится повторный прогон нужного месяца — и видно, как остаток тает от десятков тысяч к нулю. **2. Инкрементальный сбор с возобновлением ровно с места обрыва.** Парсер каждый день забирает документы по одной дате. Сайт-донор регулярно умирает посреди прохода по страницам: после трёх неудачных попыток скрипт останавливается, и если обрыв пришёлся на середину, остаток в базу не попадает. Чтобы это не превращалось в тихую потерю данных, состояние прохода сохраняется, и пересбор подхватывает с прерванного места, а не сканирует диапазон заново. Дыра, через которую утекали декларации, закрылась; нагрузка на источник заодно снизилась. **3. Посуточная статистика сбора как ранний детектор.** С первого дня к парсеру прикручена статистика по дням: сколько документов на сайте, сколько в базе, чего не хватает. Именно она ловит аномалии раньше клиента. Подозрительно ровное и маленькое число деклараций за июль сразу выдало потерю данных; расхождение «в базе столько, на сайте столько» показывает отставание в реальном времени. Без этой панели каждый инцидент источника оборачивался бы неделей слепоты. **4. Собственная ротация HTTPS-прокси плюс мини-ферма дешёвых серверов.** Когда российские ресурсы закрылись от заграничных прокси, европейские каналы отвалились, и парсер с основного сервера пополз еле-еле. Решение собрали из недорогих российских машин: подняли дополнительные серверы по символической цене, настроили на них парсер и распределили нагрузку — заодно разгрузили основной сервер. Поверх работает собственная система ротации HTTPS-прокси с временным исключением забаненных адресов. Она же потом вытащила сбор из самого тяжёлого бана. **5. Ферма парсинга и автоматический переобход.** Осенью 2022 года разрозненные машины свели в единую ферму и оформили её отдельным ТЗ: три VPS, обход блокировок, автоматический перепарсинг после сбоев и детальный мониторинг. Оно шло в одном пакете с соседней задачей, поэтому отдельной цифры по нему в кейсе нет. Смысл фермы простой: бан или падение одной машины больше не останавливает сбор — очередь перераспределяется, переобход запускается сам. ## Инциденты и реакция Главная ценность движка проверяется не в спокойные недели, а в дни, когда источник ломается. Хроника по российскому реестру за четыре года выглядит так. **Апрель 2022. «Десять миллионов сертификатов».** Реестр на любой запрос по дате стал отвечать, что нашлось 10 000 000 сертификатов. Парсер верил: шагал по первым страницам, собирал реальные документы, а дальше уходил в бесконечную пустоту искать записи, которых нет. Сервисы от этого сошли с ума, и пользователи перестали входить в систему. Поставили заплатку: проход ограничили первой сотней страниц — на практике этого хватает, чтобы собрать все существующие записи и не блуждать по пустым. **Июнь 2022. Закрытие от заграничных прокси.** РФ-ресурсы перестали пускать запросы из-за рубежа, парсер встал. За выходные подняли мини-ферму российских серверов и вернули сбор; за май собрались все сертификаты и декларации, июнь догнали следом. **Июль 2023. Тихая потеря деклараций.** Аналитик заметил подозрительно ровное и маленькое число деклараций. Причина — сайт-донор умирает посреди прохода: иногда отдаёт по пятьдесят тысяч деклараций одним разом, а потом падает. С этого началась долгая работа над устойчивостью возобновления. **Декабрь 2023. Бан всех машин.** Вечером в пятницу на сервисе деклараций забанили все парсер-машины разом. За выходные систему парсинга переписали в несколько потоков на новой системе прокси: четыре машины, по два потока через прокси на каждой. По декабрю вышли на стопроцентную актуальность — и дальше темп держали уже на новой схеме. **Октябрь 2024. Источник замолчал.** Декларации и сертификаты почти неделю не отдавали данные, при этом сайт руками открывался нормально. Антон нашёл изменение на стороне сервера ФСА, отредактировал парсер под него и запустил снова. **Декабрь 2024. Смена инфраструктуры.** Реестр сменил серверную инфраструктуру на новую, и старый парсер к ней не адаптировался. Парсер переделали под новый источник; в очередь на пересбор встало 23 тысячи документов. **Март 2026. Лимит двадцать страниц.** Реестр ввёл жёсткое ограничение: не больше двадцати страниц по сто документов, то есть тысяча строк на запрос. Старый принцип «забрать всё за дату одним проходом» перестал работать. Собрали новый алгоритм: раз в час перебираем свежие документы до упора в лимит, ловим ошибку конца выдачи, а недостающее добираем вариативным перебором по фильтрам. Пропавшие дни дособрали следом. Между крупными событиями шла мелкая адаптация. Когда в реестре появилось новое поле «Лицо, принявшее декларацию», его добавили в сбор без переписывания приёмника. А запрос заказчика собирать в сертификатах все технические регламенты вскрыл старую особенность легаси-парсера: из документа он брал лишь первую запись ТР ТС. Пересбор затрагивал порядка 259 тысяч сертификатов, и без отдельного ТЗ от заказчика эта задача осталась в ожидании. В том же режиме живёт план подключения нового реестра REAEC, открытого в 2026 году: план на 13 часов подготовили за день после запроса, старт остался за заказчиком. ## Результаты Метрика Значение Роль в системе **Исходный движок платформы; на нём держится вся аналитика по РФ** Архитектурный стек Laravel 5.5.50 · Horizon · Redis · Docker · ClickHouse · собственная ротация HTTPS-прокси · мини-ферма серверов Крупных инцидентов источника отработано **семь за четыре года** (бан, смена инфраструктуры, лимит выдачи, аномалии выдачи) и серия мелких адаптаций Скорость реакции на бан (12.2023) **за выходные** переписана схема на 4 машины × 2 потока, 100% актуализации декабря Скорость реакции на смену инфраструктуры (12.2024) парсер переделан, очередь пересбора **23 тыс. документов** Реакция на лимит выдачи (03.2026) новый алгоритм почасового сбора с добором, досбор пропавших дней Календарь работ **ноябрь 2021 → продолжается, больше четырёх лет** Движок ни разу не переписывался с нуля целиком. Он рос от чужого легаси к сегодняшней архитектуре через цепочку инцидентов, и каждый раз менялась только та часть, что упёрлась в новое поведение источника: то проход по страницам, то транспорт через прокси, то алгоритм обхода лимита. Схема хранения и накопленные за годы данные при этом оставались на месте. Эта же инфраструктура очередей и ротации прокси позже легла в основу парсеров иностранных реестров, но российский движок был первым — и остаётся ядром. ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта, архитектурные решения по парсеру, формализация ТЗ. Российский парсинг **разбирал руками сам**: принял чужой легаси без нормальной статистики и автоматики, изучил, переписал на полную автоматику с посуточным мониторингом и перевёл на очереди Laravel под Horizon с собственной ротацией прокси. Случай для нас редкий, когда руководитель проекта закрывает сборку руками, но передавать спутанный легаси кому-то, не разобрав его лично, было нельзя. - **Разработчик виджетов и парсеров** подхватил часть последних заказов по парсингу, когда направление уже стояло на современной архитектуре. Преемственность держится внутри команды: модуль, написанный годы назад, дорабатывает человек изнутри направления, а не «новый человек с нуля». ## Скриншоты и материалы _Будут добавлены отдельным проходом. Возможные кандидаты: панель посуточной статистики сбора (документов на сайте против базы), панель очередей Horizon, упрощённая схема задания-парсера с возобновлением прохода._ > Если ваш бизнес зависит от одного внешнего источника данных, который вы не контролируете, пришлите описание схемы сбора. Скажем, что в ней сломается первым при бане или смене источника и какая страховка стоит дешевле всего. Смотрим бесплатно. [Прислать схему сбора →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/analitiksert-registries-and-db-architecture/ title: Реестры и архитектура базы: диагностика вместо апгрейда сервера и поиск за 3–4 секунды вместо минут type: case_study date: 2026-06-07T06:35:09+00:00 case_industry: Сертификация и соответствие case_type: Заказная разработка case_practice: engineering --- Аналитические платформы стареют одинаково: данных больше, запросов больше, отклик длиннее. У заказчика поиск по реестрам уходил в минуты, и очевидное решение лежало на поверхности — сервер помощнее. Мы не спешили его покупать. Сначала разобрались, что именно тормозит, обкатали гипотезу на тестовом стенде, и дело оказалось не в железе. Тормозил оператор «содержит»: поиск вхождения подстроки идёт мимо индекса, полным перебором миллионов строк, пока парсер каждую секунду дописывает в ту же таблицу. Тот же запрос через «равно» отрабатывал за миллисекунду. Можно было отделаться правкой на 5 часов, но нагрузка росла структурно, поэтому вместо нового сервера базу развели на два контура: оперативный MySQL и аналитическую реплику на ClickHouse. Поиск теперь занимает 3–4 секунды вместо минут. ## Сводка Отрасль Сертификация продукции, B2B-аналитика рынка Конечный клиент «Аналитика сертификатов» **Формат сотрудничества** **Регулярное сопровождение — реестры, целостность данных и архитектура базы** Тип проекта Подключение справочных реестров, диагностика производительности и переделка архитектуры базы под рост нагрузки Объём работ Реестр аккредитованных лиц с приватными списками по компаниям; база новых участников рынка на ClickHouse + BI; развод базы на MySQL и аналитическую реплику ClickHouse через контейнер-репликатор; восстановление целостности дат; разбор инцидентов с экспортами **Дата проекта** **январь 2022 — июнь 2024** Трудозатраты **~253 часа по ТЗ** (80 — аккредитованные лица · 100 — база новых участников · 73 — архитектура базы), не считая абонентских часов на инциденты Команда Антон Херсун (руководитель проекта) и разработчик аналитической панели — он ведёт направление БД и реестров с первого дня и до сегодня Технологический стек MySQL (основная) · ClickHouse (аналитическая реплика) · контейнер-репликатор · Laravel · Sencha/ExtJS · Rocket BI и технические панели мониторинга **Сдано** **Двухсерверная архитектура: основная MySQL и аналитическая реплика на ClickHouse с инкрементальным репликатором. Поиск по тяжёлым таблицам — 3–4 секунды вместо минут под SLA «20 потребителей в минуту, отклик до 10 секунд, запас по росту 2–3×». В продакшене с 5 июня 2024.** ## Постановка задачи К 2024 году платформа упёрлась в предел одной MySQL-базы, на которой работала с самого начала. Поиск по декларациям ТР ТС РФ «совсем плохо работал», по словам заказчика: по любому столбцу искал долго и в большинстве случаев отдавал ошибку. Первая реакция понятная — нужен сервер мощнее. Прежде чем считать новое железо, мы посмотрели, на чём именно теряется время. Оказалось, часть пользователей ищет ОГРН с оператором «содержит». Такой поиск идёт мимо индекса: базе приходится перебирать строки подряд, проверяя вхождение подстроки в каждую. Тот же поиск с оператором «равно» опирается на индекс и отрабатывает за миллисекунду. Мы написали заказчику прямо: дело не в мощностях и не в новом сервере, а в том, как формируются запросы. Исправление оценили в 5 часов: поставить по умолчанию оператор «равно» на колонки ОГРН. Заказчик уточнил картину, и она оказалась жёстче. По большинству текстовых полей оператор «содержит» нужен по делу, да и после переноса CRM-виджета на Битрикс24 число запросов через него вырастет кратно — пользователей станет заметно больше. Структурная нагрузка на тяжёлые таблицы будет расти независимо от того, как ищут люди. Так задача переехала с «ускорить запрос» на «вынести аналитическую нагрузку с оперативной базы». В отдельном ТЗ заказчик зафиксировал требования цифрами: - беспрерывный доступ при 20 потребителях в минуту, - отклик не более 10 секунд, - архитектура должна допускать рост числа пользователей в 2–3 раза, - CRM-виджет должен отдавать данные без задержек. **Что в этом сложного.** Переоптимизировать так же легко, как недооптимизировать. Перейти на ClickHouse целиком значит переписать половину Laravel-кода и потерять транзакционность ORM. Оставить всё на MySQL и тянуть индексами не выход: через полгода начнётся то же самое, материализованные представления конфликтуют с непрерывной записью парсера, а read-реплика MySQL не спасает, потому что нагрузка на запись тоже растёт. Поэтому выбрали промежуточную схему: оперативные операции (запись парсера, транзакции) остаются в MySQL, аналитика и тяжёлый поиск уходят в реплику на ClickHouse, между ними контейнер-репликатор. Цена компромисса — задержка данных в аналитике на считанные минуты от записи. Для B2B-аналитики приемлемо. ## Как мы это сделали **1. Сначала диагностика, потом архитектура.** Вслепую архитектуру не переделывают. Сначала мы нашли причину тормозов (оператор «содержит», который идёт мимо индекса), назвали её заказчику и предложили обойтись малой кровью: правкой оператора по умолчанию. К переделке перешли, только когда выяснилось: структурная нагрузка будет расти при любом операторе. Эксперименты с новой структурой шли на тестовом стенде, домашнем сервере: «если успешно, предложу решение». Через сутки исследование завершилось положительно, тестовый контур подключили к одному руту, чтобы заказчик сам пощупал скорость, и только потом расписали ТЗ и стоимость. **2. Двухсерверная архитектура: MySQL основной и реплика на ClickHouse (73 ч по ТЗ).** Основной сервер (4 ядра, 8 ГБ оперативной памяти, 80 ГБ диска) держит MySQL с парсерами. Второстепенный (8 ядер, 12 ГБ, 100 ГБ) отдан под контейнер-репликатор и ClickHouse — базу, заточенную под быстрое чтение и поиск. Репликатор инкрементально переносит на второстепенный сервер четыре самые массивные таблицы (две по РФ и две по реестрам ЕАЭС), синхронизация раз в час. Один инженерный нюанс мы проговорили с заказчиком заранее: таблица добавляется в репликатор вручную и только если в ней есть числовой идентификатор `ID`. По нему репликатор понимает, сколько новых записей появилось, и забирает только их. Ограничение сознательное: четыре тяжёлые таблицы получают высокую скорость, остальные работают на прежнем механизме, а новую таблицу можно переключить на ClickHouse «галочкой», когда понадобится. **3. Поиск с минут до 3–4 секунд.** На тех же четырёх таблицах средний запрос стал занимать 3–4 секунды вместо прежних минут. Заказчик подтвердил: «отклик действительно очень быстрый, и поиск работает корректно». Побочные эффекты вылезли по дороге: новая база оказалась чувствительна к регистру и оставляла служебные символы в строках — и то, и другое вычистили до выката. Решение ушло в продакшен 5 июня 2024 года. Бонусом ClickHouse дал статистику запросов по таблицам, которой на MySQL не было: видно, что и как ищут пользователи. **4. Реестр аккредитованных лиц с приватными списками по компаниям (80 ч по ТЗ).** Источник: Росаккредитация, реестр аккредитованных лиц, порядка 30 тысяч записей. Парсинг по тому же принципу, что и документов; полный переобход справочника идёт еженедельно, чтобы ловить изменения. Поверх общего справочника заказчик попросил редактируемый список «нужных» аккредитованных лиц — отдельный для каждой компании клиента, без доступа между компаниями. Это разграничение видимости на уровне строки. Приватные списки пересобираются каждую ночь, и одна компания не видит отметок другой. Модуль сдан 23–30 ноября 2022 года. **5. База новых участников рынка на ClickHouse, за год до основной миграции (2023, 100 ч по ТЗ).** Отдельная задача: находить заявителей, которые впервые появились в реестрах, чтобы менеджеры могли их прозвонить. Цель не аналитическая: база для обзвона. Наивный путь отвергли сразу: гонять на каждый новый документ поиск по всей базе по его ОГРН парализовало бы и аналитику, и CRM на часы, потому что документы приходят почти непрерывно. Вместо этого собрали ту самую схему, которая через год станет основной. Вся база инкрементально перетекает на параллельный сервер с ClickHouse, запрос группирует документы по ОГРН и смотрит дату первого появления: если старых документов ноль, ОГРН считается новым участником. Для отчётов поставили BI-надстройку (Rocket BI). По сути это был боевой прототип двухсерверной архитектуры — к моменту основного ТЗ мы уже знали, что связка репликатор + ClickHouse работает на этих данных. Модуль выкатили досрочно, закрыли в сентябре 2023 года. **6. Целостность данных как часть архитектуры.** Быстрый поиск бесполезен, если в таблицах мусор. Ещё в январе 2022 года разобрали историю «сломанных дат»: около 26 тысяч записей за 2018 год хранили испорченные даты — день превратился в год из-за старого алгоритма, который когда-то копировал даты в базу неправильно. Хранение перевели на штатный тип «дата», без алгоритмов копирования. Не перенёсшиеся значения восстановили вручную. Старые данные за 2017–2018 годы (около 170 тысяч записей) отправили в архив, и таблица заодно стала компактнее и быстрее. Позже, в 2024-м, нашли источник дублей в базе новых участников: дубли появлялись, когда у документа не удавалось определить страну. Исправление на будущее: нет страны — считаем Россией. Нашли 20+ тысяч исторических дублей и предложили заказчику честно: обработать их около 16 часов либо оставить как есть, зная природу. Заказчик выбрал оставить, раз новых дублей больше не возникает. Корень проблемы (отсутствие адреса) он держал под отдельное ТЗ. ## Результаты Метрика Значение Поиск по тяжёлым таблицам **3–4 секунды вместо минут** Целевой SLA **20 потребителей в минуту · отклик до 10 секунд · запас по росту 2–3×** Архитектура Основная MySQL (запись парсера, транзакции) + аналитическая реплика ClickHouse (поиск, аналитика) · контейнер-репликатор, синхронизация раз в час Конфигурация серверов Основной (4 ядра, 8 ГБ, 80 ГБ) + второстепенный (8 ядер, 12 ГБ, 100 ГБ) Реестр аккредитованных лиц ~30 тыс. записей · еженедельный полный переобход · приватные списки по компаниям, пересборка ежедневно База новых участников Инкрементальная репликация в ClickHouse + Rocket BI; боевой прототип архитектуры за год до основной миграции Восстановление целостности ~26 тыс. испорченных дат исправлено, ~170 тыс. устаревших записей в архив Продакшен 5 июня 2024 Эксплуатация спустя 2 года (06.2026) **102 активных пользователя за 2 месяца, отклик не просел** (разбивка — в тексте ниже) Что получилось: основная MySQL обслуживает запись парсера и транзакции, реплика на ClickHouse берёт тяжёлый поиск и аналитику, между ними круглосуточно работает инкрементальный репликатор. Поиск по четырём самым массивным таблицам ускорился с минут до 3–4 секунд. Видимость реестра аккредитованных лиц разнесена по компаниям клиента на уровне приложения. База новых участников живёт в отдельном контуре и не мешает основной работе. Архитектура держит требуемый SLA с заявленным запасом по росту. Результаты мы ощутили и сразу, и через 2 года. Статистика входов за апрель–июнь 2026: в системе 167 учётных записей, за 2 месяца активны 102 пользователя, еженедельно работают 66–79 человек, и эта цифра не проседает ни на одной из 9 недель. Ядро из примерно 55 сотрудников работает в системе регулярно, самые активные заходят по 10–12 раз в день. Архитектура, рассчитанная по ТЗ на рост нагрузки в 2–3 раза, держит этот режим без деградации отклика. ## Процесс и хронология Этап Период Результат Восстановление целостности дат январь 2022 ~26 тыс. записей исправлено, ~170 тыс. в архив Реестр аккредитованных лиц октябрь–ноябрь 2022 80 ч по ТЗ База новых участников рынка (ClickHouse + BI) июль–сентябрь 2023 100 ч по ТЗ Диагностика «содержит» и инцидент с экспортами январь–март 2024 Найдена истинная причина тормозов; введён лимит и автоочистка экспортов Переделка архитектуры базы (MySQL + ClickHouse) май–июнь 2024 73 ч по ТЗ, продакшен 05.06.2024 Исправление дублей в базе новых участников октябрь 2024 Исправление на будущее; чистку истории заказчик отложил ## Команда - **Антон Херсун, Xaver Pro**, руководитель проекта: диагностика производительности, выбор двухсерверной схемы, формализация SLA, ТЗ и согласование - **Разработчик аналитической панели**: модуль связи платформы с ClickHouse, конфигуратор, работа с репликатором. Он ведёт направление БД и реестров с первого дня и до сегодня: подключение справочных реестров 2022 года, прототип на ClickHouse 2023-го и переезд аналитики на ClickHouse 2024-го вёл один человек. Знает все исходные схемы и историю запросов. - **Инфраструктурная команда** под лидом Антона: серверы, репликатор, мониторинг и восстановление после аварий хостинга. ## Скриншоты и материалы _Будут добавлены отдельным проходом: схема архитектуры «парсер → MySQL → репликатор → ClickHouse → виджет», панель статистики запросов._ > Если ваша MySQL умирает под одним отчётом, и при этом туда же пишет парсер — пришлите EXPLAIN самого долгого запроса и схему. Скажем, что развести по двум серверам, а что лечится оператором и индексом. Разбор ничего не стоит. [Прислать запрос и схему →](https://xaver.ru/contact/) --- --- url: https://xaver.ru/case/xaver-internal-build-story-103-days/ title: Внутренний кейс: конвейер на 107 проектов и деплой, который не трогает боевой сайт type: case_study date: 2026-05-23T00:30:00+00:00 case_industry: Внутренние проекты нашего бюро case_type: Другое case_practice: wordpress --- ## Кейс про нашу собственную систему Этот кейс — про наш собственный проект: [xaverPRO](https://xaver.ru/) и xaver.ru, двуязычное портфолио из 107 кейсов на каждом языке. Мы собрали его себе тем же конвейером и с той же дисциплиной, что и клиентские сайты. История не про хронологию и не про «как прошли эти месяцы». Она про систему. Сложную задачу — собрать сотню проектов из трекера, нормализовать, перевести, проверить и опубликовать на двух языках — мы разложили на звенья, выстроили из них конвейер и каждое звено довели до рабочего состояния. В этом и есть наша работа: взять сложную задачу, разобрать её на части, собрать под неё конвейер и отвечать за результат на выходе. Свой сайт — просто задача, которую мы поставили себе сами. Дальше — разбор системы по звеньям. ## Краткий обзор Поле Значение Тип проекта Внутренний проект — двуязычный сайт-портфолио бюро **Формат сотрудничества** **Для собственного использования** Целевой покупатель [xaverPRO](https://xaver.ru/): SEO/маркетинговые агентства США/Великобритании/ОАЭ · xaver.ru: русскоязычные студии и CTO в РФ, СНГ, ОАЭ и на Кипре Объём работ 107 опубликованных кейсов · 22 страницы · 5 эссе · 7 отраслевых страниц · 5 опорных страниц — на каждом из двух языков **Дата проекта** **09.02.2026 – 22.05.2026 (103 дня)** Активная разработка ~35 дней (между фундаментом и основной работой 2 месяца паузы) Трудозатраты ~400 часов Команда 4: Антон Херсун + Claude Opus 4.7 (оркестратор) + Claude Sonnet 4.6 (субагенты) + DeepSeek v4 Pro/Flash через OpenCode Технологический стек WordPress 6.9 · Astra free 4.13 + дочерняя тема `xaver-pro` · PHP 8.4-fpm-alpine · MariaDB 11.4 · Redis · nginx · Rank Math · конвейер деплоя на shell-скриптах · Python-инструментарий обработки кейсов **Сдано** **Два рабочих сайта ([xaverPRO](https://xaver.ru/) EN + xaver.ru RU), 107 опубликованных кейсов на каждом, единая тема на серверном PHP-рендере, схема деплоя, обновляющая только контент, ~30 Python-скриптов и ~12 Claude-навыков** Коммитов 823 в ветке `feature/ai-importer` Версий темы v0.1.0 → v1.0.458 (458 синхронных шагов) ## Конвейер в одну схему Любую сложную задачу мы начинаем одинаково: раскладываем на звенья и смотрим, как данные текут от одного к другому. Вот эта задача в одной схеме — пять звеньев, данные идут в одну сторону, от трекера задач к двум готовым сайтам. Каждое звено делает свою работу и передаёт следующему. Конвейер: от источников данных до двух боевых сайтов 1. **Источник правды — Redmine.** История задач, часов и статусов 112 проектов уходит в JSON. Дальше — детерминированный разбор: тип работы, согласованные часы, состав команды. `build_matrix.py` разложил все 112 проектов по приоритету за 47 секунд: 52 в первую очередь, 54 во вторую, 6 в отказ. 2. **Извлечение контекста — Rocket.Chat.** Из тысяч, а то и десятков тысяч сообщений по проекту фильтр оставляет десяток по делу. Здесь же мы наступили на первые грабли: набор регулярных выражений понимал только английский и выдавал 25 сигналов там, где их было за сотню. Почти вся переписка шла на русском. Двуязычный словарь поднял охват до 100+ на проект. 3. **Нормализация и генерация — LLM.** DeepSeek v4 и Claude-субагенты собирают markdown-черновик по жёсткому шаблону под тип работы: Rebuild, Build, Templated, Refresh, Redesign, Other. Шаблон — это не творческое задание, а контракт: какие секции, в каком порядке, с какими обязательными полями. 4. **Контроль качества — Python.** `verify_draft.py`, 48 проверок: есть ли согласованные часы, жив ли URL, не сполз ли текст в шаблон, не утекли ли учётные данные. Скрипт чистки секретов нашёл и вырезал 19 фрагментов уже в первом кейсе: пароли из чатов, ссылки на тестовые среды, личные аккаунты. Поверх — четыре линтера русского текста. 5. **Доставка — пакетный деплой контента.** Атомарная транзакция, три прохода перезаписи URL, восьмиступенчатая проверка, изоляция первичных ключей. Один скрипт, один источник конфигурации на оба сайта. Это вся система. Дальше — каждое звено по отдельности: где оно упёрлось в свой предел и как мы довели его до рабочего состояния. Начнём с последнего, доставки: именно оно решает, попадёт ли работа на боевой сайт целой. ## Звено доставки: деплой, который не трогает боевой сайт Самое тревожное в передаче деплоя подрядчику — что очередное обновление контента затрёт то, что живёт только на боевом сайте: активные плагины, настройки SEO, флаги индексации. Один такой деплой — и после каждой синхронизации кто-то руками поднимает конфигурацию обратно. Для агентства это не теория, а простой вопрос: пускать ли вообще подрядчика к боевому сайту клиента. Спецификация у этого звена жёсткая: трогать только посты, метаданные, термины и таксономии — и больше ничего. Таблица `wp_options` с настройками Rank Math и списком плагинов остаётся нетронутой. Логика простая: контент и конфигурация живут в разных ритмах. Контент меняется каждый день, конфигурация — редко и осознанно. Смешать их в одном деплое значит каждый раз рисковать конфигурацией ради контента. Первый подход к этому не дотягивал. Точечный SQL-дамп под нужные типы постов сработал бы для одного деплоя, но следующий снова потребовал бы разбора данных и нового дампа под них. Точечные файлы выбросили, написали единый скрипт с предсказуемой логикой — и сразу увидели риск конфликта первичных ключей. Вот в чём он. На боевом сайте в таблице постов живут не только наши записи: тот же Flamingo, хранилище заявок Contact Form 7, складывает свои в ту же таблицу, что и редакционный контент. Деплой, который перезаписывает посты по их номерам, рано или поздно встретит чужую запись на «своём» номере. Лечить такое постфактум — плохая стратегия для того, что ходит на боевой сайт. Поэтому конфликт мы убрали по построению, а не понадеялись на низкую вероятность. Редакционный контент занял номера 1–999 999. Данные боевого сайта (Flamingo и прочие плагины, что копят свои записи в работе) уехали в диапазон от 1 000 000, а автоинкремент таблицы постов прибили к 1 001 000. Пересечься этим диапазонам больше негде. Конфликт стал не «маловероятным», а невозможным. Финальный прогон прошёл чисто: 1,7 МБ атомарного SQL, 107 кейсов, 7 канонических таксономий за один проход. Два контрольных повтора той же ночью уложились в 2 минуты каждый, оба зелёные, второй уже слал в Telegram отчёт по каждой стадии. Та же схема тянет оба языка. Все различия между сайтами (путь на VPS, системный пользователь, префикс таблиц, URL, FPM-пул) собраны в одном файле `_targets.sh` с переключателем `TARGET=en|ru`. Скрипты деплоя подключают его как зависимость. Добавить третий сайт — одна строка, а не правки в пяти местах. ## Проблема масштабирования: 17 минут → 18 секунд 17 минут на полный реимпорт 107 кейсов. 20 вызовов `docker exec` на каждый: тело поста, метаданные, главная картинка, мобильная, таксономии. Мы терпели это 2 недели. Зря. На 20 постах ещё терпимо, на 107 — стоп-машина: правишь 1 кейс, ждёшь 3 минуты ради него 1. Рефакторинг свёл двадцать вызовов к одному. `wp eval-file` выполняет PHP-скрипт прямо в контексте WordPress: все правки кейса в одном скрипте, переданном через смонтированную папку, без копирований внутрь контейнера. Плюс пул потоков по числу задач. 17 минут стали 18 секундами. В 54 раза. Число 54 у нас стало нарицательным, и не потому, что красивое. Дело не в самих 17 минутах: один-два реимпорта в день они спокойно выдерживали. 18 секунд изменили не скорость задачи, а саму форму работы: реимпорт стал бесплатным, регрессию видно в момент её появления, итерация перестала стоить времени. Здесь весь принцип, по которому росла эта машина: инструмент рождается из боли, а не из плана. Первый кейс мы прошли руками, шаг за шагом. Иначе все автоматизации встали бы на непроверенной методике. Потом ту же методику прогнали через 5 проектов параллельными агентами. Потом появился `build_matrix.py`, разложивший 112 проектов за один прогон. Потом `verify_draft.py` с 48 проверками, потому что агенты ошибались в предсказуемых местах. Каждый инструмент — ответ на узкое место, которое вскрыл предыдущий шаг. ## Текст как код: четыре линтера и трёхэтапный аудит Качество текста у нас — инженерная задача с тестами, а не вопрос вкуса. 214 кейсов на двух языках глазами после каждого прогона автоматизации не вычитать. Поэтому проверки оформлены как код. Один пример, с которого всё началось. На первом прогоне линтер поймал 398 кальк. Каталог запрещённых форм с тех пор дорос до 8 000 строк правил. ``` `# .claude/skills/ru-translation-quality/anti_patterns.json "aggregate_matched_calque": { "rule_class": "calques_forbidden", "severity": "error", "patterns": [ "агрегат сошёлся", "сумма сошлась в согласованные", "итог сошёлся в N часов" ], "suggested": "→ «итоговый объём уложился в согласованные N часов»", "source": "EN-калька с «the aggregate came in at the agreed N hours»" }` ``` До правила и после: ``` `Агрегат сошёлся в согласованные 78 часов проекта. Итоговый объём уложился в согласованные 78 часов проекта.` ``` Грамматика чистая в обоих. Но первый вариант по-русски не звучит: неодушевлённое существительное действует в нём по английской модели. Регулярное выражение этого не видит. Каталог из 8 000 правил — видит. Линтеров четыре, и каждый закрывает свой пласт: 1. **Лексический — англицизмы и кальки-слова.** По каталогу из 8 000 правил. Ловит «продакшен», транслитерации вроде «абонементной поддержки» и сотни им подобных. 2. **Грамматический — на Natasha и pymorphy3.** Ловит рассогласование прилагательного с существительным по роду и подлежащего с глаголом прошедшего времени. Это побочка массовых замен: меняешь существительное на форму другого рода, а согласованные с ним слова остаются от старой. Руками это ловится только чтением, линтером — за секунду на весь корпус. 3. **Кросс-языковой — сверяет бренды и имена.** Между EN- и RU-версией кейса, через фонетику плюс расстояние Левенштейна. «Vista Family Eyecare» должно остаться латиницей, а не стать «Виста Фэмили Айкэр». Заодно линтер вскрыл артефакт извлечения: в 2 кейсах среди нашей команды оказался человек, которого в ней не было, — сотрудник агентства-заказчика, общавшийся с нами в общем чате. Алгоритм принял его за своего. Убрали. 4. **Индекс имён команды.** Канонический EN- и RU-вариант на каждого из 11 человек, без смешения латиницы и кириллицы. Но главное мы поняли позже: чистый линтер не означает чистый текст. Линтер закрывает уровень слов. На уровне фразы остаются кальки, которые регулярка не возьмёт в принципе: неодушевлённый субъект по английской модели («the aggregate came in» → «сумма сошлась»), английская метафора без русского эквивалента («client build has a visible victim»), глагол со словарным переводом, но чужим употреблением («timeline accommodates 170 hours», где календарный срок «вмещает» часы). Грамматика чистая, линтер молчит — а носитель спотыкается уже на чтении вслух. Отсюда трёхэтапный аудит, который стал стандартом: 1. **Этап 1 — дешёвая быстрая модель.** DeepSeek Flash, ~6 минут на кейс, доли цента. Механические артефакты, согласование, простые англицизмы: всё, что проскочило мимо первого линтера. 2. **Этап 2 — Claude Sonnet.** Дороже и медленнее, зато видит структурные кальки: перевод, верный по словам и калькированный по конструкции, падежи в именах собственных, смешение регистров, причастную кашу. 3. **Этап 3 — ручное чтение от начала кейса до конца.** На одной партии этот проход поймал 22 ошибки, которые модель не увидела или поправила по-своему неверно. Правило закрепили: третий этап — это чтение целиком, а не просмотр правок второго. И ещё одна дисциплина: «критик сказал — значит надо» не работает. Часть замечаний — ложные срабатывания. «Таксономия услуг» — устоявшийся русский IT-термин, технический директор его знает. «QA-тестирование» — тавтология: QA и есть тестирование, и принять такую правку было бы ошибкой. Каждое замечание мы сверяем с правилами проекта. Автоматически не принимается ничьё мнение: ни критика, ни линтера. Последнее слово — за человеком. Инструменты подсказывают, но не решают. ## i18n: контент в коде, не в базе План русской версии был наивным: открыть страницы в админке, перевести, сохранить. Через час выяснилось, что план не работает. Страницы [xaverPRO](https://xaver.ru/) не хранят контент в базе вообще — в теле поста ноль слов. Весь текст рендерится из PHP-шаблонов темы, и каждая строка обёрнута в gettext (`__()`, `_e()`). По-инженерному это правильно. Контент в коде версионируется в Git вместе с темой, не уплывает в базу, не теряется при миграциях. И отсюда главное следствие: деплой кода и деплой контента разъехались. Перевод — это не правка записей в WordPress, а работа с файлом `.po`: строки собираются в шаблон, переводчик переводит, компилятор делает бинарный `.mo`, WordPress на лету подменяет язык. В каталоге `ru_RU.po` собрано 1719 строк. Цена решения: «просто перевести в админке» уже нельзя. Зато 2 сайта живут на одной кодовой базе, и обновление темы едет на оба одним деплоем кода, отдельным от деплоя контента. Выгода эту цену перевешивает. ## Управление техдолгом: где мы остановились Лучшее — не всегда максимальное. Зрелость команды видна не в том, что она выжимает каждую метрику до максимума, а в том, что она знает, где остановиться, и фиксирует границу — чтобы следующий разработчик не бился в ту же стену. **Мобильный PageSpeed 100, которого нет.** На больших экранах сайт держал 100. Мобильный замер на 99, и один балл выглядел как последняя миля. Техника известная: выделить критический CSS, встроить в HTML, остальное грузить асинхронно. Перед боем мы построили страховку, стенд визуальной регрессии: съёмка через Playwright на 28 URL в 5 контрольных точках, сравнение пар снимков тремя алгоритмами (перцепционный и дифференциальный хэш, индекс структурного сходства), разбивка на плитки. Калибровка дала 0 расхождений из 140 пар. Инструмент извлечения вынул 28 КБ критического CSS из 262 — разумная доля. Деплой тут же вскрыл несовместимость, которой раньше никто не замечал. Шапка грузит шрифт по стратегии `font-display: optional`, а окно его загрузки держится на блокирующем отрисовку CSS. Встраиваешь критический CSS — и парсинг становится мгновенным: окно схлопывается, браузер берёт запасной шрифт, заголовок переносится на 2 строки, а стабильность компоновки прыгает с 0,021 до 0,174. Повторили на 2 прогонах в тёплом кэше. Закономерность, не случайность. Быстрая мобильная отрисовка и нулевой сдвиг вёрстки оказались взаимоисключающими при текущей шрифтовой архитектуре. Порядком загрузки это не лечится — нужна перестройка шрифтов целиком, отдельная задача с риском сломать остальное. Решение: оставить мобильный 99 со стабильностью в зелёной зоне. Это устойчивый оптимум, а не компромисс. Границу мы измерили, записали в дизайн-кит, POC сохранили в архиве. Ломать боевой сайт ради цифры 100 в чужом отчёте мы не стали. Настоящие 100/100/100/100 на больших экранах пришли с другой стороны: мы убрали из очереди 2 неиспользуемых JavaScript-файла родительской темы Astra, и блокировка отрисовки упала с ~70 мс до нуля. Цифру не подгоняли — выкинули лишнее. **Консолидация — тоже дизайн, и часто более глубокий, чем новые элементы.** За месяц `overrides.css` распух почти до 9 000 строк, и около 40% дублировалось между пространствами имён под 5 типов кейсов. Симптомы видно глазом: «бровь» над заголовком 10 пикселей на одной странице услуг и 11 на другой, 2 страницы без переменной фона, длинное тире, нарисованное дважды символом в тексте и CSS-псевдоэлементом. Заменили на универсальные компоненты `.xpro-*`: 1 `.xpro-hero` вместо 5, 1 `.xpro-cta-band` на все CTA, постраничный модификатор перекрывает только акцент. 8 фаз закрыли за одну сессию: половинчатая консолидация даёт половинчатый эффект, и обходные решения возвращаются. Видимая часть результата — минус 242 строки; реальная сложность упала сильнее. 7 отраслевых хабов теперь работают на одном шаблоне вместо 7 почти одинаковых копий. Масштабируемость — это не когда у вас много страниц. Это когда новую можно добавить, не трогая старые. ## Граница: мы не делаем SEO Скажем прямо: SEO-продвижение мы не продаём. Но фундамент разработки строго ложится под требования современных поисковых алгоритмов — иначе сайт на 200 страниц просто не виден. Это часть инженерной работы, а не отдельная услуга, и границу эту мы держим открыто. Как мы относимся к SEO-советам, лучше всего показывает один эпизод — и он неприятный. Первую версию плана оптимизации мы прогнали через четыре независимые проверки с выборкой из актуальной литературы. Четыре тактики, каждая поданная как «прогрессивная практика», на проверке оказались способом активно угробить выдачу: - тип `CaseStudy` в разметке Schema.org: такого типа не существует, разметка невидима для сниппетов; - тасовка 5–6 структурных блоков ради «уникальности»: ровно тот маркер, по которому Google помечает контент как машинный; - накрутка даты модификации без реальных правок: «дата-стаффинг», за который с 2023 года прилетает ручной фильтр; - автоперелинковка по совпадению сущностей 3 и более раз: топология ссылочной фермы. План v1 отвергли целиком. v2 оставил только то, что работает на алгоритмах 2024–2025: разметку Person и Organization, согласованность сигналов между страницами, осмысленный якорный текст вместо «click here», Article на кейсах, «отпечатки опыта» (концепция E-E-A-T) — абзац с реальной проблемой и предложение с обоснованием решения в каждом кейсе. Вывод тут не про SEO, а про метод. Любой совет из открытых источников проходит у нас один фильтр — работает ли это сегодня или за это прилетает санкция? SEO меняется быстрее, чем устаревают руководства «как сделать SEO». Тот же фильтр мы держим на любой внешний совет, не только на поисковый. ## Что мы построили и не стали использовать Честный кейс показывает не только победы. Первые 6 дней мы поднимали MCP-федерацию из 219 инструментов — три сервера под одной точкой доступа с токеном (71 + 3 + 145). Работа чистая: ресурсные лимиты Docker, переиспользование соединений через keep-alive после того, как системный сторож памяти в первый же вечер начал убивать процессы, замена тяжёлой темы на лёгкую Astra ради экономии памяти. А потом она не пригодилась. Когда в апреле пошла настоящая работа, все операции с админкой поехали через `mcp-ssh` — он оказался кратно быстрее. Федерация так и осталась стоять: рабочая, нетронутая, в стороне от критического пути. Вывод мы записали честно: хорошая инфраструктура не требует, чтобы её использовали. Иногда правильно построенный узел оказывается не той осью, вокруг которой пойдёт работа. И это нормальный исход, а не списанные впустую часы. Важно вовремя это увидеть и не тащить мёртвый канал в основную схему только потому, что он уже построен. ## Принципы, которые остались Это правила не про наш сайт, а про то, как мы берёмся за любую систему — на вашей задаче они работают так же. - **Инструмент строится по боли, а не по плану.** Сначала руками, потом автоматизация, потом доработка под проблему, которую вскрыла сама автоматизация. - **Чистый линтер не означает чистый текст.** Машина ловит слова, человек — структуру. Три прохода аудита, а не два. - **Контент и конфигурация живут в разных слоях.** Деплой, который их смешивает, рано или поздно затрёт настройки боевого сайта. - **Границу честнее измерить, чем обойти.** Мобильный 99 с зелёным CLS лучше, чем 100 ценой прыгающей вёрстки — и про это есть запись в дизайн-ките. - **Решение остаётся за человеком.** Ни критик, ни линтер, ни модель не принимаются на веру. ## Если у вас аналогичная задача > Вы видели, как мы разобрали свою задачу. Если у вас есть своя — сложный сайт, конвейер контента, система из нескольких звеньев, которую надо собрать и довести до результата, — пришлите текущий стек: какая CMS, какие источники данных, как организован деплой. Посмотрим, выделим узкие места, вернём фиксированную оценку в часах. Аудит бесплатный. [Запросить аудит ТЗ →](https://xaver.ru/contact/) --- ## Числовое приложение ### Объём работы - **Календарь:** 09.02.2026 → 22.05.2026 = **103 дня** (из них ~35 дней активной работы; 2 месяца паузы между фундаментом и основной работой) - **Коммитов:** 823 в `feature/ai-importer` - **Веток:** 5 (основная плюс четыре тематические: миграция темы, генерация кейсов, AI-импортёр, федерация шлюза) - **Плановых документов закрыто:** 106 в `plan/done/` - **Документации в `docs/`:** ~25 файлов (дизайн-кит, инструкция по деплою, маркетинговые материалы) ### Контент - **Опубликованных кейсов:** 107 RU + 107 EN = **214 case_study** на обоих сайтах - **Статических страниц:** 22 RU + 22 EN = 44 - **Эссе-инсайтов:** 5 RU + 5 EN = 10 - **Страниц по отраслям:** 7 RU + 7 EN = 14 - **Опорных страниц (типы кейсов):** 5 RU + 5 EN = 10 - **Покрытие 112 Redmine-проектов:** 100% (52 высокого приоритета + 54 публикуемых + 6 на пропуск; проект №23 разделён на 23.1 и 23.2) - **Каталог i18n темы:** 1719 строк в `ru_RU.po` ### Инструментарий - `cases/scripts/`: 30+ Python-скриптов (build_matrix, verify, wp_import, translate, audit, sync, redact, fetch_sheet и др.) - `scripts/deploy/`: 8+ shell-скриптов (`full_deploy.sh`, `content_deploy*.sh`, `_targets.sh`, verify, profile и др.) - Тема `xaver-pro/`: ~60 PHP-файлов, серверный рендер, 11 шаблонов страниц + 5 шаблонов одиночных кейсов + универсальные компоненты `.xpro-*` - Линтеры русского текста: лексический (`anglicism_lint.py`), грамматический (`agreement_lint.py`, Natasha + pymorphy3), кросс-языковой (`cross_language_ner_check.py`) ### Деплой и масштаб - **Реимпорт корпуса:** 17 минут → 18 секунд (ускорение в 54 раза) - **Диапазоны первичных ключей:** редакционный контент 1–999 999, данные боевого сайта от 1 000 000 - **PageSpeed на запуске [xaverPRO](https://xaver.ru/):** 66 → 99/99/100/100 (WebP-конвертация 2 235 файлов, −86,6% веса изображений) - **OpenCode на DeepSeek:** ~190 атомарных единиц за 5+ раундов, суммарная стоимость ~$2–4 --- url: https://xaver.ru/case/white-label-wordpress-build-legal-78h-44-days/ title: Новая разработка сайта юридической фирмы по травмам и несчастным случаям — 17 страниц за 44 дня type: case_study date: 2026-02-27T09:34:19+00:00 case_industry: Юридические услуги case_type: Разработка case_practice: wordpress --- ## Подход к разработке 17 страниц на 9 шаблонах по прототипу в Figma — с hero-анимацией набора текста и каруселью вердиктов. Главную запустили первой в рамках бюджета 15 часов, пока контент для внутренних страниц ещё дописывался. Оставшиеся 16 страниц собрали под задерживающийся контент — без поломки дизайн-сетки и без выхода за построчные часовые оценки. ## Краткий обзор Поле Значение Индустрия клиента Юридические услуги — Травмы и несчастные случаи Конечный клиент Big Joe Law (Los Angeles, CA) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка WordPress на Elementor, в среде Kinsta, с вёрсткой по дизайну в Figma Объём работ **17 URL** — главная, о нас, лендинг практик, 8 отдельных страниц практик, результаты, лендинг блога, шаблон отдельной записи блога, контакты, политика конфиденциальности Сроки 44 дня (27 мая – 10 июл 2025), по графику Трудозатраты **78 часов** при оценке 78 часов — без перерасхода Команда 6 специалистов (47 ч разработка · 11 ч QA · 25 ч PM и правки — PM-распределение оправдано для сборки с главной страницы в первую очередь при параллельной подготовке контента) Шаблоны **9 активных шаблонов** из стандартной библиотеки юридических шаблонов агентства (Homepage, About Us, Practice Area Lander, Individual Practice Area Page, Results, Blog Lander, Individual Blog, Contact Us, Default Template) Технический стек WordPress · Elementor Pro · Kinsta · Rank Math · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) **Сдано** **17 URL построены на 9 шаблонах, очередь задач SEO из 83 строк + очередь задач CX из 34 строк проработаны, контрольный список запуска из 29 пунктов закрыт** **Ритм работ** 82 задачи от агентства · 81 закрыта к передаче, 1 в QA (35-дневный активный период, 2025-07-02 – 2025-08-05) **Раунды проверки** ≈8 раундов проверки за 44 календарных дня **Контрольный список запуска** 29 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США, ведущее проект Big Joe Law — юридической фирмы по травмам и несчастным случаям в Лос-Анджелесе — передало нам библиотеку дизайнов Figma, таблицу Google Sheets с отслеживанием прогресса, доступы к тестовой среде Kinsta и поэтапный бриф: сначала собрать главную страницу, пока контент для внутренних страниц готовится параллельно. Конструктор страниц — Elementor; контактные формы настраивались в рамках сборки. Агентство владело дизайном, контент-стратегией, SEO и отношениями с клиентом. Наш объём работ заключался в том, чтобы построить каждую страницу в точности по Figma, настроить контактные формы, реализовать фильтрацию блога по категориям и проработать две параллельные очереди задач QA до принятия сайта агентством. Задача была поэтапной. Этап 1: собрать главную страницу (15 часов) по прототипу в Figma, включая hero-анимацию набора текста и карусель вердиктов. Этап 2: собрать оставшиеся внутренние страницы — о нас, лендинг практик, 8 отдельных страниц практик, результаты, лендинг блога и шаблон отдельной записи, контакты и политику конфиденциальности — после утверждения контента и дизайна. Контент этих страниц находился в Google Документах агентства — вне таблицы. Поэтому каждая внутренняя страница требовала сверки 2 источников, а не сборки по единой спецификации; перед наложением шаблона добавлялся отдельный этап подготовки контента в тестовой среде. На всём протяжении: не выходить на прямой контакт с конечным клиентом; возвращать неясности агентству; не импровизировать описания практик, адвокатскую квалификацию или язык результатов. > **Контекст рисков.** Когда сборка сайта юридической фирмы начинается с главной страницы, а контент для практик ещё дописывается, реальный риск — шаблонная система, которая не может принять восемь отдельных страниц практик, поступающих партиями — каждая со своим юрисдикционным контентом, формулировками категорий дел и указанием адвокатов — без поломки дизайн-сетки или необходимости постраничной переработки. Подрядчик, собирающий сайт для калифорнийской практики по травмам и несчастным случаям, не пишет контент, не решает, какие практики перечислены и как они описаны, и не выносит суждений о языке страницы результатов. Что подрядчик действительно контролирует — структурную точность: каждая страница практики в sitemap должна существовать и быть доступной, навигация должна отражать реальный объём услуг фирмы, а шаблонная система должна выдерживать поступающий с опозданием контент без поломки дизайн-сетки. Агентство подстраховывалось от подрядчика, который посчитал бы сборку «готовой» со сдачей главной, оставив шаблонную систему внутренних страниц неспособной собрать реальный контент, когда он поступит. ## Как мы это сделали **1. 9 шаблонов, 17 страниц, один процесс сборки — сначала главная, затем внутренние страницы.** Страницы Big Joe Law распределились по библиотеке юридических шаблонов агентства: Homepage (1), About Us (1), Practice Area Lander (1), Individual Practice Area Page (8 — personal injury, car accidents, truck accidents, motorcycle accidents, bicycle accidents, slip and fall, dog bites, rideshare accidents), Results (1), Blog Lander (1), Individual Blog (1), Contact Us (1) и Default Template для политики конфиденциальности. Главная страница собрана первой по прототипу в Figma; внутренние страницы последовали во втором этапе, когда контент был готов. Каждую страницу построили на назначенном шаблоне из строки sitemap; ни одной страницы не делали вручную вне шаблонной системы. **2. Спецификация выполнена строка-в-строку, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Самый большой бюджет получила главная (15 часов с учётом итерации QA); 8 отдельных страниц практик — фиксированную ставку каждая. Итог уложился в согласованные 78 часов проекта. Принцип прост: карта сайта с дизайном — это контракт. Задача команды разработки — сдать в рамках согласованной сметы, а не открывать разговор о ценообразовании заново страница за страницей. **3. Точность переноса дизайна из Figma в Elementor на сборке, начинающейся с главной страницы.** Исходный дизайн представлял собой файл Figma с прототипом, включающим анимацию набора текста, карусель вердиктов и индивидуальную секцию наград. Мы построили шаблон главной страницы в соответствии с сеткой Figma, отступами и спецификацией взаимодействия до того, как начали любой шаблон внутренних страниц — чтобы язык дизайна, заданный на главной, наследовался внутренними страницами без постраничной переработки. Когда дизайны внутренних страниц поступили, мы построили их на той же библиотеке компонентов Elementor, что дало визуальное единообразие на всех 17 страницах. **4. Два параллельных цикла QA, закрытых до запуска.** Задачи отслеживались в двух очередях задач агентства — очередь задач SEO (83 строки, охватывающие meta titles, H1-заголовки, структуру URL, внутренние ссылки и адаптивное поведение) и очередь задач CX (34 строки, охватывающие соответствие Figma, единообразие шрифтов, качество изображений и функциональность форм). Обе очереди прорабатывали параллельно на финальном этапе QA. Контрольный список запуска из 29 пунктов — Design, Functionality, Pre-Migration, Post-Migration — подписан после закрытия обеих очередей. Скролл-анимации прототипа в Figma не воспроизводились в Elementor без поломки при обратном скролле. Мы назвали это явно: передать замысел штатными эффектами прокрутки Elementor, а не воспроизводить прототип кадр-в-кадр. Это решение на этапе главной страницы означало, что сборка внутренних страниц не застряла в ожидании анимационного решения, которое Elementor не мог надёжно обеспечить. ## Результаты Метрика Результат URL построено **17** на 9 шаблонах (1 Homepage · 1 About Us · 1 Practice Area Lander · 8 Individual Practice Area Pages · 1 Results · 1 Blog Lander · 1 Individual Blog · 1 Contact Us · 1 Default Template) Шаблонов применено **9 / 9** из стандартной библиотеки юридических шаблонов агентства Очередь задач SEO **83 строки** проработано (макет, meta, ссылки, адаптивность) Очередь задач CX **34 строки** проработано (соответствие Figma, шрифты, изображения, формы) Контрольный список запуска **29 пунктов** согласованы — Design / Functionality / Pre-Migration / Post-Migration Сроки **44 дня** (27 мая – 10 июл 2025), по графику Трудозатраты **78 ч / 78 ч оценка** — без перерасхода, без расширения объёма Передача Сайт запущен на Kinsta, `https://callbigjoe.com/` возвращает HTTP 200 Статус сайта, проверено 2026-04 Сайт в работе, отдаёт 200 при свежей проверке Результат, если просто: сборка юридического сайта агентства на 17 URL запущена на 9 шаблонах в среде Kinsta, в рамках оценённого бюджета 78 часов. Две очереди задач QA (SEO + CX) доведены до приёмки агентством, и контрольный список запуска подписан до выкладки сайта в работу. ## Контроль качества QA после запуска выявил две категории исправлений: сообщение проверки контактной формы отображалось красным текстом на красном фоне hero-блока — нечитаемо, и при отправке выезжало за край экрана — и комментарий разработчика на русском языке (`// Проверяем, появились ли новые элементы поиска`), оставленный в отрендеренном DOM страницы `/car-accidents/`, обнаруженный контент-сканом агентства и удалённый до согласования с агентством (Redmine #969, #937). QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу нулевых ошибок. Свой проверочный контур агентства выполнялся после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до момента согласования с агентством. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Дизайны Figma рассмотрены, объём главной страницы согласован на 15 ч, полный объём — на 78 ч Сборка главной страницы ~1 неделя Главная страница собрана по прототипу в Figma, включая анимацию набора текста и карусель вердиктов Сборка внутренних страниц ~2 недели 16 оставшихся URL построены на 8 шаблонах; фильтрация блога по категориям настроена; формы сконфигурированы Финальный QA (SEO + CX) ~2 недели Очередь задач SEO (83 строки) и очередь задач CX (34 строки) проработаны параллельно Контрольный список запуска + доставка финальные ~2 дня Контрольный список из 29 пунктов согласован; сайт запущен на Kinsta _Сборка внутренних страниц началась до полного закрытия финального QA главной страницы, поэтому календарный срок — 44 дня, а не сумма последовательных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (сборка главной страницы, шаблоны внутренних страниц, согласование Figma) - **Павел Сажин** — итерации QA и исправления - **Тимур Арбаев** — итерации QA и проверка перед передачей - **Анна Полунина** — поддержка разработки на поздних этапах (обновления контента, коррекции очередей задач) - **Людмила Травкина** — проход QA и координация проверки перед передачей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались на стороне агентства-партнёра на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > На сайте юридической практики шаблоны страниц услуг закладываются до готовности контента. У этой практики — несколько направлений с разной юрисдикцией; у других — одна услуга с единственной посадочной страницей. Вы рискуете: URL-таксономия зафиксируется слишком рано — новая практика не впишется. Структурированная разметка слетит на импорте — расширенные результаты пропадут из аудит-панелей. Шаблонная система не вместит поступившие списки адвокатов — вёрстка сломается. И вам придётся объяснять клиенту, почему страницы практик отображаются некорректно. Подрядчику стоит задавать не вопрос «соберёте ли страницы услуг?», а вопрос «как именно вы построите таксономию URL, чтобы новая практика вставала без миграции и без потери структурированной разметки?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сопоставим предложенную URL-архитектуру с перечнем практик, проверим устойчивость шаблонов к реальной длине контента и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/build-7-dental-templates-staging/ title: Сборка 7 стоматологических шаблонов WordPress, из Figma в Elementor — 170 часов, 30 дней type: case_study date: 2026-02-23T10:01:44+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 7 изолированных стоматологических шаблонов из Figma в Elementor — 170 часов за 30 дней для внутренней библиотеки шаблонов маркетингового агентства из США. 6 дизайнов в Figma и 1 в Adobe XD из 3 файлов; каждый шаблон размещался на собственном инстансе WordPress на FastPanel, собранном по своему дизайн-файлу до назначения какого-либо клиентского проекта. Этот кейс — описание такого проекта: 170 часов на семь стоматологических шаблонов, каждый из которых был собран из Figma (шесть дизайнов) или Adobe XD (один дизайн) на изолированных инстансах WordPress и сдан менее чем за месяц. ## Краткий обзор Параметр Значение Отрасль клиента Медицина — Стоматология (внутренняя библиотека шаблонов агентства) Клиент Нет — это внутренний проект для собственной системы шаблонов агентства **Тип проекта** **Внутренняя разработка библиотеки шаблонов WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта 7 отдельных сборок шаблонов Elementor Pro на изолированных тестовых инстансах WordPress Объём работ **7 шаблонов** — Шаблоны 1–4 из 2 файлов Figma (дизайн Copy, предоставленный агентством) + Adobe XD; Шаблоны 5–7 из третьего файла Figma (набор HOMEPAGE-DESIGNS агентства). Каждый шаблон включает: главную страницу, страницу услуг, контактную страницу, общие шапку и подвал. Адаптивность (большие экраны + мобильные + планшет) для каждого шаблона. Срок 30 дней (10 дек 2024 – 9 янв 2025), все шаблоны сданы до рождественских каникул Затраты **170 часов** на 7 шаблонов — диапазон от 20 ч (Шаблоны 4 и 5) до 32 ч (Шаблон 2) Команда 5 специалистов Источник дизайна Figma (6 шаблонов) · Adobe XD (Шаблон 4) — пошаблонные дизайн-файлы от дизайнеров агентства Технологии WordPress · Elementor Pro · тема Hello Elementor · Gravity Forms · FastPanel (серверное окружение) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **7 изолированных инстансов WordPress собраны, проверены QA и утверждены агентством до рождественского срока** **Раунды проверки** ≈1 раунд проверки за 30 дней ## Постановка задачи Маркетинговое агентство из США ведёт фирменную библиотеку стоматологических шаблонов: когда подписывается новый клиент из стоматологической ниши, агентство выбирает один из существующих шаблонов и начинается доработка темы. Расширение библиотеки означает сборку нового шаблона на свежем, изолированном инстансе WordPress — без клиентского контента, без работающего сайта, без публичной аудитории — и его проверку на соответствие дизайн-спецификации агентства перед добавлением в каталог. В декабре 2024 агентство запросило расширение своей библиотеки стоматологических шаблонов на 7 шаблонов. 6 дизайнов были предоставлены в 2 файлах Figma (5 от ведущего дизайнера агентства, 1 от второго дизайнера в общем файле Figma, HOMEPAGE-DESIGNS); седьмой поступил в Adobe XD. Объём на каждый шаблон: главная страница, 1 страница услуг, 1 контактная страница, общие шапка и подвал — все адаптивные. Техническим заданием был дизайн-файл; агентство проверяло собранный шаблон на соответствие Figma перед утверждением. Первые 4 шаблона были сгруппированы в начальную задачу оценки. Оставшиеся 3 были добавлены в середине проекта по мере освобождения ресурсов команды и поступления дизайнов. Все 7 велись параллельно на общем серверном окружении FastPanel. > **Контекст рисков.** Расширение библиотеки шаблонов имеет другую модель отказа, чем сборка клиентского сайта. В клиентских проектах срыв сроков бьёт по конкретному бизнесу: агентству приходится объяснять конкретной практике, почему запуск откладывается. Отказ библиотеки шаблонов более коварен: шаблон выглядит примерно правильно, но искажает Figma в компонентах, которые рецензент агентства вряд ли заметит — до тех пор, пока на реальном клиентском сайте уже не началась доработка темы, и в этот момент цена ошибки умножается на каждый проект, использовавший этот шаблон. Собрать шаблон точно по дизайну с первого раза, до того как его увидит хотя бы 1 клиент, в этом и состоит весь смысл при работе с такими типами проектов. ## Как мы это сделали **1. 7 шаблонов, 7 изолированных инстансов — 1 координированная сборка.** Каждый шаблон размещался на собственной установке WordPress на сервере FastPanel агентства: отдельная админка WordPress, отдельный лицензионный инстанс Gravity Forms, отдельное окружение Elementor. Изолированные инстансы мы выбрали вместо общей мультисайтовой сети: межшаблонный дрейф настроек в едином окружении Elementor умножил бы нагрузку на пошаблонную проверку на 7 различных сборок. Шаблоны 1–4 собрали первыми, а Шаблоны 5, 6 и 7 добавили через 6 дней после старта — отдельной задачей на оценку. Никита Тумашевич выполнял сборку всех 7 шаблонов; Павел Сажин координировал QA-итерации, а Тимур Арбаев проводил проверку шаблонов 1, 3 и 6, а также оценку второй партии. **2. Пошаблонная оценка, привязанная к сложности дизайна.** Прежде чем написать хотя бы одну строку Elementor, Никита проанализировал все семь дизайнов и подготовил пошаблонные оценки: Шаблон 2 на 32 часа (главная 17 ч + услуги 5 ч + контакты 6 ч + шапка/подвал 5 ч), Шаблон 3 на 25 часов (два сложных слайдера, блок текста с показать/скрыть, 2 часа на адаптивность), Шаблон 1 на 28 часов (главная 16 ч + страница услуг 3 ч + контакты 3 ч + шапка/подвал 6 ч), Шаблон 4 на 20 часов (сложный макет главной с вложенными скруглёнными секциями). Шаблоны 5, 6 и 7 получили оценки 20 ч, 22 ч и 23 ч соответственно после того, как Figma HOMEPAGE-DESIGNS стала доступна. Все семь оценок утвердили до начала сборки — ни одни часы не пересматривались в процессе. **3. Согласование доступа к Figma, затем сборка.** Два из шести дизайнов Figma изначально были ограничены — дизайнер агентства не открыл права на экспорт, то есть команда могла просматривать, но не скачивать ресурсы. Проблему доступа решили в течение рабочего дня: PM агентства связался с дизайнером, тот открыл права на экспорт, и сборка этих шаблонов продолжилась в обычном режиме. 1 шаблон (Шаблон 4) пришёл в Adobe XD, а не Figma; команда собирала по макету XD с изображениями-заполнителями там, где стоковые ресурсы Adobe были заблокированы лицензией XD (стоковые изображения в дизайнах XD не скачиваются по умолчанию — команда подставила изображения-заполнители, как было указано, с заменой на реальные изображения при клиентской доработке). **4. QA-циклы по каждому шаблону перед утверждением агентством.** Каждый шаблон проходил по одной и той же схеме передачи: сборка → внутренний QA (Никита проверяет свою работу) → уведомление о проверке Антону Херсуну → проверка Антоном с конкретными замечаниями (например, Шаблон 2: положение логотипного текста в шапке требовало корректировки; Шаблон 4: аномалия макета со скруглёнными секциями потребовала исправления вложенности контейнера) → доработка → утверждение. Пошаблонные заметки проверки мы передавали через ссылки Google Docs, по одному документу на шаблон, что давало агентству структурированный артефакт утверждения для добавления в каталог. Шаблоны 1, 2, 3, 4 перешли в статус «Решено» в период с 18 по 21 декабря; Шаблоны 5, 6, 7 последовали за ними с 23 по 27 декабря — все до рождественского закрытия. 7 шаблонов за 30 дней — каждый прошёл 1 и ту же последовательность: оценка по сложности дизайна → сборка → внутреннее утверждение «Проверено, на отправку» → документ проверки в Google Docs, переданный агентству для каталога. Именно эта пошаблонная разбивка не дала 7 параллельным сборкам слиться в одну неразрешимую очередь проверки в конце. ## Контроль качества Пошаблонная проверка выявила проблемы целостности макета на трёх из семи инстансов до того, как агентство увидело хотя бы один из них — текстовый элемент футера, сместившийся влево в Шаблоне 2; контейнер со скруглёнными секциями, не полностью вложенный в Шаблоне 4; и область наведения кнопки половинной ширины в Шаблоне 5 — каждый был исправлен и подтверждён по Figma до передачи пошаблонного документа утверждения в Google Docs. Предварительный QA проводился через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Собственный QA агентства выполнялся после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до момента утверждения. ## Результаты Метрика Результат Шаблонов собрано **7** — Стоматологические шаблоны 1–7, каждый на изолированном инстансе WordPress Источников дизайна **Figma** (6 шаблонов в 2 файлах Figma) + **Adobe XD** (1 шаблон) Диапазон часов на шаблон **20–32 ч** — Шаблоны 4 и 5 по 20 ч (более лёгкие композиции главной); Шаблон 2 на 32 ч (самый тяжёлый, 17 ч только главная) Общие затраты **170 ч** при оценке 170 ч — без перерасхода ни по одному шаблону Адаптивность Большие экраны · планшет · мобильные для каждого шаблона Пошаблонное утверждение **7 / 7** документов проверки Google Docs подготовлены, получено утверждение агентства Все шаблоны сданы к **27 декабря 2024** — до рождественского срока агентства Все задачи формально закрыты **9 января 2025** Срок **30 дней** (10 дек 2024 – 9 янв 2025), сдано по графику Прод-URL Нет — шаблоны работают на внутренних тестовых поддоменах агентства; это не публичный клиентский сайт ## Процесс Этап Длительность Результат Оценка — Шаблоны 1–4 2 дня (10–11 дек) Подготовлена пошаблонная разбивка часов; выставлено 105 ч на первую партию Оценка — Шаблоны 5–7 1 день (16 дек) Вторая партия оценена после появления Figma HOMEPAGE-DESIGNS; добавлено 65 ч Сборка — все 7 шаблонов параллельно ~10 дней (12–23 дек) Инстансы WordPress развёрнуты на FastPanel; на каждый установлены Elementor Pro + Hello Elementor + Gravity Forms; сборка велась пошаблонно, Никита ведущий, Анна поддерживала Шаблоны 5–7 Согласование доступа Figma ~1 день (середина дек) Открыты права экспорта для ограниченной Figma; изображения-заполнители для заблокированных лицензией XD ресурсов QA и утверждение агентством по шаблонам Непрерывно (18–27 дек) Пошаблонная проверка → конкретные замечания → цикл доработки → документ утверждения Google Docs; все 7 сданы к 27 дек Формальное закрытие 9 янв 2025 Все задачи Redmine закрыты как Completed; оплата подтверждена _Этапы сборки пересекались — Шаблоны 1–4 уже были в QA к моменту, когда Шаблоны 5–7 только входили в разработку, поэтому 30 календарных дней вместили более 170 часов работы за счёт параллельных потоков._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик всех 7 шаблонов; основная интерпретация Figma и реализация в Elementor - **Павел Сажин** — управление проектом и QA-итерации - **Тимур Арбаев** — проверка шаблонов и обратная связь по Шаблонам 1, 3 и 6, а также оценка второй партии; проверка соответствия дизайна перед передачей агентству - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, цикл пошаблонного утверждения) Управление проектом со стороны агентства и дизайн-решения оставались за партнёрским агентством на всём протяжении работ. Наша команда была невидима для конечного клиента (в этом проекте конечного клиента не было — результатом был сам шаблон). ## Агентствам, заказывающим разработку WordPress > На сайте стоматологической клиники таксономия услуг формирует каждый URL и граф разметки. У этой практики — группа из нескольких направлений: эстетика, восстановление, хирургия; у других — узкопрофильная клиника или детская сеть. Новые страницы процедур, добавленные после запуска, наследуют URL-схему, которая не растёт вместе с бизнесом. Страницы-фильтры услуг выпадут из индекса, когда редакторы переставят таксономию. Разметка процедур слетит при выкладке темы — расширенные результаты пропадут из ваших отчётов. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы выстроите таксономию и разметку, чтобы новые направления не создавали провалов в ранжировании?» Пришлите текущую рабочую таблицу сборки, черновик карты сайта или дизайн-файлы. Мы разберём план URL и каталог услуг, найдём, где новые процедуры вызовут структурные конфликты, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-spine-surgery-70h-90-days/ title: Сборка WordPress для практики хирургии позвоночника — 10 шаблонов type: case_study date: 2026-02-15T23:40:20+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке Новая сборка WordPress из Adobe XD для практики хирургии позвоночника в Tampa — 10 шаблонов, ~70 часов за ~90 дней, Elementor на WP Engine. Основной структурной нагрузкой стала URL-таксономия заболеваний и методов лечения: два контентных направления под общим префиксом с единым фильтруемым лендингом, где черновики скрыты из каталога до появления контента. ## Краткий обзор Параметр Значение Отрасль клиента Медицина — хирургия позвоночника / минимально инвазивная хирургия Клиент Endoscopic Spine Florida (Tampa, FL) — практика двух хирургов позвоночника **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая сборка WordPress из макетов Adobe XD, на WP Engine с Elementor, с последующим этапом доработок по обратной связи перед запуском Объём работ **Многошаблонный сайт** — Главная, О нас, Команда, Страница врача (×2), Лендинг заболеваний и методов лечения (с фильтруемой таксономией), Шаблон заболевания, Шаблон лечения, Лендинг блога, Пост блога, Финансирование и страховка, FAQ, Контакты, Запись на приём, Гостиница рядом, плюс вспомогательные страницы Срок ~90 дней (декабрь 2024 – конец февраля 2025), сдано по графику Затраты **~70 часов** при оценке ~70 часов — без перерасхода Команда 4 специалиста (с упором на разработку, что уместно для сборки с большим объёмом контента и индивидуальной таксономией URL) Шаблоны **10 переиспользуемых шаблонов** — О нас, Блог, Страница врача, Шаблон заболевания, Шаблон лечения, Лендинг заболеваний и методов лечения, Лендинг блога, Финансирование, FAQ, Контакты — по библиотеке медицинских сайтов агентства Технологии WordPress · Elementor Pro · WP Engine · Rank Math · Custom Permalinks plugin · Site Checker ([xaverPRO](https://xaver.ru/) QA плагин) **Результат** **Новый сайт хирургии позвоночника на 10 шаблонах; URL-таксономия `/conditions-treatments/` с фильтруемым лендингом; очередь правок доведена до приёмки агентством; предзапускной QA закрыт до перехода** **Раунды проверки** ≈7 раундов проверки за 90 дней ## Постановка задачи Маркетинговое агентство из США, нанятое практикой двух хирургов позвоночника в Tampa, передало нам файлы дизайна Adobe XD — набор для большого экрана, набор для внутренних страниц и набор для мобильных устройств — вместе со сводной таблицей всех изменений URL и распределения контента. Сборка размещалась на окружении WP Engine; конструктор страниц — Elementor Pro; SEO-плагин — Rank Math. Агентство спроектировало сайт вокруг двух сертифицированных хирургов позвоночника, Dr. Aaron Smith (DO, FACOS) и Dr. Scott Glickman, и структурировало таксономию услуг вокруг двух контентных направлений: заболеваний позвоночника (диагнозы, с которыми пациент может обратиться) и хирургических методов лечения (минимально инвазивные и эндоскопические процедуры, которые выполняет практика). Объём сборки определялся файлами Adobe XD и параллельной таблицей отслеживания, в которой были указаны структура URL, назначение шаблонов и этапы поставки контента. Основная задача — построить все страницы на 10 шаблонах, включая фильтруемый лендинг заболеваний и методов лечения с фильтрацией по категории, а затем пройти этап согласований после сборки: корректировка URL, добавление контента, предзапускные правки и загрузка мета-заголовков и описаний на весь сайт перед запуском. На всём протяжении работ не выходить на прямой контакт с конечным клиентом; передавать все неясности агентству; не импровизировать с медицинскими текстами и названиями процедур. > **Контекст рисков.** Сайт практики хирургии позвоночника содержит две взаимосвязанные таксономии — заболевания и методы лечения, — которые отображаются на один и тот же URL-префикс, но представляют разные точки входа для пациента. Построение на стандартных типах записей WordPress даёт плоские URL (`/herniated-discs/`), когда спецификация агентства требует вложенных путей (`/conditions-treatments/herniated-discs/`). Стандартная система типов записей WordPress не может формировать вложенные URL для произвольных типов записей без плагина постоянных ссылок; ошибка в этом механизме незаметно ломает фильтруемый лендинг и все внутренние ссылки, использующие правильный путь. Кроме того, не все страницы заболеваний и методов лечения были готовы с контентом к запуску — эти страницы должны были существовать в CMS, но не отображаться как черновики в фильтре на работающем сайте. Предзапускной QA был критическим барьером: агентство готовилось передать сайт клиенту, и любой сбой в логике фильтра или неопубликованная запись всплыли бы при первой же приёмке клиентом. ## Как мы это сделали **1. 10 шаблонов, многотрековая контентная архитектура, единый процесс сборки.** Библиотека медицинских сайтов агентства предоставила 10 шаблонов, распределённых по сайту: Главная, О нас, Страница врача (применён дважды — по одному на каждого хирурга), Команда, Лендинг заболеваний и методов лечения, Шаблон заболевания (по одному на каждое заболевание: грыжа диска, дегенеративное заболевание диска, стеноз позвоночника, сколиоз, ишиас и другие), Шаблон лечения (по одному на каждую процедуру: эндоскопическая дискэктомия, задний спондилодез и фиксация, передняя шейная дискэктомия и артропластика, замена шейного искусственного диска, минимально инвазивная хирургия позвоночника и другие), Лендинг блога, Пост блога, Финансирование и страховка, FAQ, Контакты, Запись на приём и вспомогательные страницы по умолчанию. Каждую страницу собрали на назначенном шаблоне из дизайна Adobe XD; ни одну не делали вручную вне шаблонной системы. **2. URL-архитектура для таксономии заболеваний и методов лечения.** Спецификация агентства требовала, чтобы все записи заболеваний и методов лечения отображались по адресу `/conditions-treatments//` — структура URL, которую стандартные записи WordPress не могут обеспечить для произвольного типа записей. Решением стала реализация плагина Custom Permalinks — выбранного вместо произвольного типа записей с правилами перезаписи, поскольку разделение на заболевания и методы лечения было скорее различием в категориях контента, а не структурным изменением модели контента, и CPT добавил бы сложность без улучшения поведения фильтра — каждой записи назначили постоянный URL под требуемый путь. Фильтруемый лендинг работал на метках категорий (заболевание/лечение), так что URL с GET-параметром (`/conditions-treatments/?category=conditions`) разрешался и оставался индексируемым. Кроме того, лендинг был настроен таким образом, чтобы скрывать кнопку «Подробнее» и ссылку на страницу для записей без опубликованного контента — агентство указало, что не все заболевания и методы лечения будут иметь тексты к моменту запуска, и такие записи не должны содержать работающих ссылок до наполнения контентом. **3. Наполнение контентом и проверка точности по всему сайту.** После начальной сборки шаблонов агентство выдало серию дополнений: посты блога по темам SI Joint Education, Herniated Nucleus Pulposus, Minimally Invasive Spine Surgery и Sciatica; дополнительные записи заболеваний и методов лечения в таксономии; корректировку URL-путей согласно таблице агентства; исправление адреса и контактных данных (обновлённый адрес практики: 11603 Sheldon Road, Tampa, FL 33626; исправление номеров телефона по всему сайту); страницу гостиницы рядом для иногородних пациентов; а также загрузку мета-заголовков и описаний на весь сайт из отдельной таблицы агентства. Сканирование тестовой среды на предмет Lorem ipsum выявило тексты-заполнители на страницах блога, About и заболеваний и методов лечения — все заменили до передачи. **4. Предзапускной QA закрыт по очереди правок.** На финальном этапе перед запуском агентство предоставило очередь предзапускных правок: очистка черновиков блога, реструктуризация шаблона страницы врача (перестройка блока доктора как внутреннего шаблона Elementor вместо жёстко закодированного макета), исправление кликабельности навигации (родительские пункты меню не вели на свои страницы), согласование ссылок на соцсети в футере и очистка sitemap для разделов блога и FAQ. QA был отмечен руководителем проекта как срочный: агентство готовилось передать сайт конечному клиенту, и все правки должны были закрыться до презентации. Никита Тумашевич разобрал очередь правок; Анна Полунина провела проверку; очередь правок и предзапускной контрольный список закрылись до даты сдачи агентства. Именно реализация Custom Permalinks для `/conditions-treatments/` и заставила таксономию работать. Без постоянной ссылки на каждую запись фильтруемый лендинг не отдавал бы индексируемый URL с GET-параметром — логика фильтрации по категориям зависела от корректного разрешения структуры URL раньше, чем мог пройти любой другой QA-цикл. ## Контроль качества Нагрузка QA для этой сборки была наибольшей по двум категориям: сканирование Lorem ipsum по всему сайту очистило все тексты-заполнители на страницах, в записях и в данных Elementor до передачи; а флаг загрязнения sitemap — записи заболеваний и методов лечения отображались в `/post-sitemap.xml` вместо отдельной карты произвольного типа — был обнаружен и исправлен до предзапускной проверки агентства. Предварительный QA проводился через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Свой контроль на стороне агентства шёл после передачи и сбрасывал замечания в общую очередь правок для нашего цикла исправлений, пока агентство не подписало приёмку. ## Результаты Метрика Результат Сайт собран Новый сайт WordPress на WP Engine для практики двух хирургов позвоночника Шаблоны применены **10** из библиотеки медицинских шаблонов агентства — About, Blog, Doctor Page, Condition Template, Treatment Template, Conditions & Treatments lander, Blog Lander, Financing, FAQs, Contact Us URL-таксономия `/conditions-treatments//` через плагин Custom Permalinks; фильтруемый лендинг с URL через GET-параметр категории Наполнение контентом Добавлены посты блога и дополнительные записи заболеваний и методов лечения; Lorem ipsum удалён по всему сайту; мета-заголовки и описания загружены для всех опубликованных страниц Очередь правок Предзапускная очередь правок доведена до приёмки агентством к дате передачи конечному клиенту Срок ~90 дней (декабрь 2024 – февраль 2025), сдано по графику Затраты **~70 ч** при оценке ~70 ч — без перерасхода **Статус сайта** Работает на WP Engine, открывается по адресу https://endoscopicspinefl.com/ — проверено в апреле 2026. Если коротко: сайт агентства для практики хирургии позвоночника сдан на WP Engine на 10 шаблонах, с таксономией заболеваний и методов лечения, которая закрыла требуемую URL-архитектуру и фильтруемый лендинг. Очередь правок закрыта до презентации конечному клиенту. Без перерасхода по оценке ~70 часов. ## Процесс Этап Длительность Результат ТЗ и оценка ~1 неделя (ноя 2024) Файлы Adobe XD проанализированы, структура URL уточнена, согласован объём из 10 шаблонов и оценка ~60 ч; старт назначен на 2 дек 2024 Сборка — шаблоны и страницы ~2 недели (дек 2024) Главная и 5 внутренних страниц собраны в первом проходе; Команда, страницы врачей, шаблоны заболеваний и методов лечения и остальные внутренние страницы завершены; реализована архитектура URL `/conditions-treatments/` Наполнение контентом и согласование URL ~3 недели (дек 2024 – янв 2025) Добавлены записи таксономии заболеваний и методов лечения; скорректированы пути URL по таблице агентства; заполнены дополнительные контентные страницы (About, Financing, FAQs, Contact); создана страница гостиницы рядом; адрес и номер телефона исправлены по всему сайту Предзапускной QA и очередь правок ~3 недели (фев 2025) Сканирование Lorem ipsum; загрузка постов блога; загрузка мета-заголовков и описаний; блок доктора перестроен во внутренний шаблон; исправлена кликабельность навигации; согласованы ссылки на соцсети в футере; очередь правок закрыта до даты передачи конечному клиенту Сдача Конец фев 2025 Сайт опубликован на рабочем домене _Этапы пересекаются — наполнение контентом и согласование URL начались, пока остальные внутренние страницы ещё строились, поэтому календарный срок составил ~90 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на этапах сборки, реализации таксономии и доработок по обратной связи - **Анна Полунина** — QA-проверка и проверка точности контента - **Евгений Карпов** — поддержка разработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, утверждение) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении работ. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте специализированной медицинской практики таксономия услуг задаёт URL-архитектуру. У этой практики — заболевания позвоночника и хирургические методы лечения; у других — диагнозы и консервативные подходы. Структуру URL легко поломать незаметно: фильтруемый лендинг перестанет индексироваться, черновики проявятся в каталоге, вложенные пути не разрешатся. Поэтому подрядчику стоит задавать не вопрос «соберёте ли страницы», а вопрос «как именно вы построите таксономию». Пришлите рабочую таблицу проекта или макеты. Мы посмотрим архитектуру, отметим узкие места и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-oral-surgery-103h-90-days/ title: WordPress-сайт для мультифилиальной хирургической стоматологии: 236 URL за 90 дней type: case_study date: 2026-02-13T13:29:59+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 236 URL на 12 шаблонах, построенных для сведения двух доменов челюстно-лицевой хирургии на Kinsta — таблица Google Sheets содержала 302 строки карты сайта, объём по строкам мы оценили сами — 103 часа работ, а карта редиректов согласовывала 349 уникальных пар URL с двух приобретённых доменов практик, объединённых в единый новый бренд на legacyoms.com. ## Краткий обзор Поле Значение Отрасль клиента Медицина — хирургическая стоматология (группа филиалов) Конечный клиент Legacy Oral Surgery (Union City, NJ — также Elizabeth, NJ — под консолидированным брендом `legacyoms.com`) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Консолидационная разработка для нескольких филиалов на Elementor и Kinsta — два домена приобретённых практик объединены в единый WordPress-сайт под новым брендом Объём работ **236 уникальных URL** — 1 главная, 1 о нас, 1 лендинг услуг, 88 страниц услуг, 4 профиля врачей, 1 контакты, 1 лендинг филиалов, 1 хаб пациента, 1 лендинг эстетики, 1 лендинг блога, 128 записей блога, 10 вспомогательных страниц на стандартном шаблоне — все на `legacyoms.com` с путями `/union-city/` и `/elizabeth/` Сроки 90 дней (20 мая — 18 августа 2025), сдано в срок Трудозатраты **103 часа** при смете 103 часа — без перерасхода Команда 4 специалиста (75 ч разработка · 10 ч QA · 10 ч PM · 8 ч доработки после запуска) Шаблоны **12 переиспользуемых шаблонов** — стандартная стоматологическая библиотека агентства, расширенная под консолидационную модель (Patient Hub, Aesthetic Lander, Locations Lander) Технологии WordPress · Elementor · Kinsta · Figma (дизайн-источник) · собственная логика филиалов/редиректов · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **236 URL построено, 349 уникальных пар редиректов согласовано с двух унаследованных доменов, 29 пунктов контрольного списка запуска закрыто, 107 / 152 задач SEO и 50 / 55 задач AM выполнены до запуска** **Рабочий ритм** 152 задачи от агентства · все закрыты к передаче (31 день активной работы, 2025-06-09 — 2025-07-09) **Раунды проверки** ≈4 раунда проверки за 90-дневный период **Контрольный список запуска** 29 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США, нанятое группой Legacy Oral Surgery по мере того как она объединяла две приобретённые практики — ранее работавшие на `unioncityoralsurgerygroup.com` и `elizabethoralsurgerygroup.com` — под единым новым брендом на `legacyoms.com`, передало нам таблицу Google Sheets с картой сайта на 302 строки, библиотекой из 12 шаблонов в Figma, контрольным списком запуска на 29 пунктов и предварительно заполненной очередью задач. Разработка велась на Kinsta агентства; конструктор страниц — Elementor; дизайн-источник — Figma. Задача представляла собой однофазную разработку с мультисточниковым хвостом редиректов. Сначала построить 236 уникальных URL — лендинги, услуги, врачи, филиалы, хаб пациента, корпус блога, плюс вспомогательные страницы на стандартном шаблоне — в 12 стандартных шаблонов агентства. Затем согласовать внутренние ссылки и 301-сопоставление двух унаследованных доменов с вкладками редиректов таблицы Google Sheets, параллельно закрыть очереди задач SEO и аккаунт-менеджера и подписать контрольный список запуска до переключения. На протяжении всего проекта оставаться вне контура коммуникации с конечным клиентом, возвращать неясности агентству и не импровизировать дизайнерские или SEO-решения. > **Контекст рисков.** Консолидация двух приобретённых практик в единый бренд держится на карте редиректов, а не на наполнении страниц. Риск агентства в такой разработке конкретен: партнёр-разработчик, который делает чистые страницы на новом домене, но оставляет URL-набор предыдущих брендов висеть. Два унаследованных домена, каждый со своей топологией ссылок, своей историей индексации, своими пациентами, сохранившими закладки на URL, которого больше не существует, — разработка завершена только когда каждый из этих старых путей ведёт на правильное новое место на `legacyoms.com`. Исполнитель, считающий «страницы построены» как «консолидация выполнена», перекладывает эту нагрузку по согласованию на агентство — после запуска это дороже и сложнее защитить перед конечным клиентом. ## Как мы это сделали **1. 12 шаблонов, 236 страниц, один процесс разработки.** Страницы Legacy распределились по стандартной стоматологической библиотеке шаблонов агентства с тремя дополнениями под консолидационную модель: Home, About, Services Lander, Service Page (самый тяжёлый — 88 страниц услуг), Doctor Profile (4 врача), Contact Us, Locations Lander (многофилиальный индекс), Patient Hub, Aesthetic Lander, Blog Lander, Blog (второй по объёму — 128 записей блога) и Default Template, закрывший 10 вспомогательных страниц. Мы расширили библиотеку тремя дополнительными шаблонами, а не строили консолидационные страницы вне шаблонной системы — так каждый филиал, хаб и лендинг унаследовал ту же библиотеку компонентов, что и основные брендовые страницы. Каждая страница строилась на назначенном шаблоне из строки карты сайта; ни одну страницу не верстали вручную вне системы шаблонов, а корпус блога из 128 записей мигрировали строка за строкой тем же процессом, что и структурные страницы. **2. Спецификация выполнена построчно, в рамках согласованной сметы.** Карту сайта на 302 строки дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Дальше реализовали строго по этой смете. Распределение бюджета соответствовало распределению работ: 13 ч на шаблон Home (самая тяжёлая страница), суммарно 89,5 ч на 128 записей шаблона Blog (в основном время импорта контента, не индивидуальная вёрстка), 19,8 ч на 88 страниц услуг и небольшой фиксированный бюджет на каждый Doctor Profile и Default-страницу. Смета разработки на 75 часов была суммой строк затронутых разработкой страниц; оставшиеся 28 ч покрывали QA, управление проектом и доработки после запуска. Принцип тот же, что и в любой предварительно оценённой разработке: таблица Google Sheets — это контракт, и задача команды разработки — уложиться в согласованную смету, а не открывать обсуждение ценообразования заново на каждой странице. В сведении нескольких филиалов на 236 URL эта строгость важнее, а не наоборот, потому что цена перерасхода хотя бы по одной строке — это цена двух обратных стресс-тестов, а не одного. **3. Согласование внутренних редиректов по 349 уникальным парам URL с двух унаследованных доменов.** Работа с редиректами велась из двух вкладок таблицы Google Sheets. Вкладка Sitemap содержала флаг Redirect-After-Launch и колонку статуса для каждой строки legacy → `legacyoms.com`; это дало **288 уникальных пар**. Отдельная вкладка карты редиректов (Sheet8) содержала аудит ссылок в теле страниц с обоих доменов — `elizabethoralsurgerygroup.com` (60 строк) и `www.unioncityoralsurgerygroup.com` (57 строк) — по одной строке на каждую гиперссылку со старым путём, обнаруженную в просканированном контенте. Поскольку вкладка аудита была безымянной, а сопоставление редиректов поступило из двух независимых источников вместо предварительно согласованного списка, наша команда вручную перепроверила каждую строку аудита ссылок по живым legacy-сайтам — чтобы выявить пары, где просканированный URL больше не разрешается или целевой адрес был обновлён в карте сайта таблицы Google Sheets. После дедупликации относительно вкладки Sitemap вкладка карты редиректов добавила **61 чистую новую пару**, что в сумме дало **349 уникальных пар URL-к-URL**. Все 290 редиректов со стороны карты сайта были закрыты со статусом `✅ Redirect OK` до передачи; аудит ссылок в теле страниц прогнали через ту же таблицу редиректов, так что каждый старый URL — будь то на уровне страницы или внутри тела другой страницы — вёл на своё новое место на `legacyoms.com`. **4. Два параллельных контура QA, один контрольный список запуска.** Задачи отслеживались в двух очередях задач на стороне агентства — основная очередь ошибок (152 строки, приоритеты `01. Highest` — `04. Low`, формировались командой разработки и AM совместно) и отдельная очередь ошибок AM (55 строк, целевая проверка тестовой среды от аккаунт-менеджера с отметками на скриншотах). Из этих 207 пунктов **107 / 152** закрыты как Completed в основной очереди ошибок (40 ушли в QA, 3 To Do на момент запуска, 2 Info-Needed в ожидании конечного клиента) и **50 / 55** закрыты как Completed в очереди ошибок AM (3 To Do, 1 Info-Needed, 1 в QA). Контрольный список запуска на 29 строк — колонки Design, Functionality, Pre-Migration, Post-Migration — закрыт после обеих очередей ошибок. 8 часов доработок после запуска (правки вёрстки страниц филиалов, обновление QA-таблиц, строки контента) были выполнены в рамках того же соглашения по сопутствующим задачам. Работа с двумя независимыми источниками редиректов — 288 парами из вкладки Sitemap и 117 строками аудита ссылок из Sheet8 по обоим унаследованным доменам — означала, что дедупликация предшествовала размещению любого редиректа. Перекрёстная проверка добавила 61 чистую новую пару, которых не было ни в одном источнике по отдельности, и выявление их до переключения — это то, что не дало URL предыдущих брендов превратиться в 404 после запуска. ## Результаты Метрика Результат Построено URL **236** уникальных URL на 12 шаблонах (1 Home · 1 About · 1 Services Lander · 88 Service Pages · 4 Doctor Profiles · 1 Contact · 1 Locations Lander · 1 Patient Hub · 1 Aesthetic Lander · 1 Blog Lander · 128 записей Blog · 10 вспомогательных страниц Default-шаблона) Применено шаблонов **12 / 12** из расширенной стоматологической библиотеки агентства Согласовано пар редиректов **349** уникальных пар с двух унаследованных доменов (`unioncityoralsurgerygroup.com` + `elizabethoralsurgerygroup.com`) закрыто в таблицах редиректов Очередь ошибок **107 / 152** закрыто как Completed; 40 в QA, 3 To Do, 2 Info-Needed на момент запуска Очередь ошибок аккаунт-менеджера **50 / 55** закрыто как Completed; 3 To Do, 1 в QA, 1 Info-Needed на момент запуска Контрольный список запуска **29 пунктов** согласовано по разделам Design / Functionality / Pre-Migration / Post-Migration Сроки **90 дней** от старта до последней доработки после запуска, сдано в срок Трудозатраты **103 ч / смета 103 ч** — без перерасхода, без расширения объёма **Статус сайта** Работает на Kinsta, открывается по адресу https://legacyoms.com/union-city/ — проверено в апреле 2026. Если коротко: два приобретённых домена практик челюстно-лицевой хирургии объединены в единый многофилиальный бренд на Kinsta агентства в рамках сметы на 103 часа. 236 уникальных URL выпущено на 12 шаблонах, 349 пар редиректов согласовано по обоим предшествующим доменам, две очереди задач QA проработаны до уровней приемлемости агентства и контрольный список запуска закрыт до переключения. ## Контроль качества Гигиена URL-структуры несла основную нагрузку предварительного QA на этой консолидационной разработке — очередь ошибок открывалась директивой 01. Urgent на поиск и замену обоих унаследованных доменов («Don’t forget about www version too»), подкреплённой 21 задачей High-priority, помечавшей ссылки в теле страниц, всё ещё ведущие на старый сайт, и 20 находками 404 High-priority на страницах блога и услуг; всё было исправлено до выхода тестовой среды. Предварительное QA проводилось через **Site Checker** — см. наш [подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Контроль на стороне агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений, пока не подписывали приёмку. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица Google Sheets изучена, построчные часы подтверждены по 302 строкам карты сайта, 103 ч согласованы Фаза разработки (страницы + шаблоны) ~5 недель Все 236 уникальных URL построены на 12 шаблонах; 152-строчная очередь ошибок и 55-строчная очередь ошибок AM открыты к тестовой среде Согласование редиректов + контуры QA ~3 недели 349 уникальных пар редиректов закрыты по двум унаследованным доменам; обе очереди задач QA проработаны до уровней приемлемости агентства Контрольный список запуска + запуск ~1 неделя 29 пунктов контрольного списка согласовано; переключение; сайт запущен Доработки после запуска ~3 недели Обновления структуры страниц филиалов, ведение QA-таблиц, правки строк контента в рамках того же соглашения (~8 часов) _Этапы пересекаются — работа по согласованию редиректов началась до закрытия всех пунктов QA фазы разработки, а доработки после запуска шли параллельно с окном приёмки агентством конечного клиента. 90-дневный календарь отражает это пересечение, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик: разработка, логика консолидационных редиректов, доработки после запуска - **Павел Сажин** — итерации QA, проверка тестовой среды, оценка объёма работ - **Анна Полунина** — поддержка разработки на позднем этапе (страницы филиалов, правки вёрстки) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Проектное управление и коммуникация с конечным клиентом оставались на стороне партнёрского агентства на протяжении всего проекта. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте хирургической стоматологии URL-структуру задаёт таксономия услуг. У этой практики — хирургические вмешательства и состояния; у других — общая стоматология и эстетика. Риски тихие. Новая услуга, добавленная на шестой месяц, не впишется в URL-схему. Страницы-фильтры по категориям услуг выпадают из индекса после миграции. Структурированная разметка слетает на импорте — расширенные результаты, которые агентство отслеживало, пропадают за ночь. Подрядчику стоит задавать не «соберёте ли страницы?», а «как вы построите таксономию, которая сохранит индекс и разметку?» Пришлите рабочую таблицу сборки, черновик карты сайта или ваши макеты. Мы пройдём по URL-плану относительно вашего инвентаря позиций и подсветим, где новая услуга сломает таксономию. Затем вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-pediatric-dental-45-pages-20-days/ title: Ребилд сайта детской стоматологии на 45 страниц — сдан по ТЗ за 20 дней type: case_study date: 2026-02-07T02:17:05+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 45 URL, два направления пациентов под одним брендом — Little Bytes Pediatric Dentistry обслуживает детские стоматологические и ортодонтические приёмы на едином домене. Ребилд должен был сохранять визуальное и функциональное различие между двумя направлениями на каждой странице — ограничение, которое таблица Google Sheets агентства не могла полностью предвидеть на этапе ТЗ, что добавило 21 час проверки в три раунда. Агентство владело стратегией; мы — исполнением. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — детская стоматология / ортодонтия Конечный клиент Little Bytes Pediatric Dentistry (детская стоматологическая и ортодонтическая практика, Palo Alto, CA) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг Kinsta Объём Полный ребилд сайта — детские стоматологические услуги, ортодонтические услуги, команды врачей, ресурсы для пациентов Сроки ~20 дней (август 2025), по графику Затраты 37 ч основная сборка (по смете) + 21 ч послерелизные задачи — всего 58 ч на проект Команда 5 специалистов (~28 ч разработка · QA · PM) Техстек WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Сверка контента оригинал-ребилд пройдена перед сдачей — нет пропущенного текста, битых внутренних ссылок, структурных расхождений **Сдано** **45 URL мигрированы, все возвращают HTTP 200 на тестовой среде перед переключением; полный набор страниц детской стоматологии и ортодонтии перестроен по ТЗ** **Раунды проверки** ≈3 раунда проверки в течение 20-дневного календарного окна ## Постановка задачи Маркетинговое агентство из США, нанятое Little Bytes Pediatric Dentistry — двухспециализированной детской стоматологической и ортодонтической практикой в Palo Alto, CA — привлекло нас для ребилда существующего сайта с нуля на Elementor Pro. ТЗ требовало сохранить каждый URL с соответствующим редиректом, перенести все meta title и описания, и перестроить полную двухспециализированную структуру услуг (детская стоматология и ортодонтия) как единый сайт. Двухнаправленная архитектура услуг — где детская стоматология и ортодонтия делят бренд, но ведут разные пути пациентов — была несущей: дизайн агентства визуально различал два направления, и наша сборка должна была соблюдать это различие на каждом уровне страниц. Задача была точной. Работать из таблицы Google Sheets агентства; реализовать каждую строку как написано; оставаться вне клиентского контура на всём протяжении. Тестовая среда работала на Kinsta. Риск, от которого агентство страховалось, был специфичен для двухспециализированного детского ребилда: родитель пациента, переходя на страницу услуги, ожидает увидеть контент детской стоматологии, а не ортодонтии, и наоборот. Ребилд, который выдаёт правильный визуал, но направляет не тот CTA или форму не в то направление, ломается молча — сайт выглядит нормально, но запрос на приём уходит не в ту специализацию. Таблица Google Sheets не выявила все пограничные сценарии взаимодействия направлений на этапе ТЗ — расхождения в SEO, пробелы в интеграции форм, рассинхрон контента всплыли только после первой сдачи и потребовали 21 час дополнительной проверки в три раунда Redmine, прежде чем целостность каждого направления была подтверждена. > **Контекст рисков.** Сайт детской стоматологии и ортодонтии обслуживает два разных направления пациентов — семьи, ищущие плановый детский приём, и семьи, ищущие ортодонтическую консультацию — под одним брендом. При переключении каждый URL страницы услуг, каждый meta title, каждая интеграция формы должна корректно отрабатывать для обоих направлений одновременно. Ребилд, который правильно выглядит, но направляет форму консультации не туда или замещает URL детской услуги ортодонтическим, даёт сайт, проходящий визуальный QA, но подводящий родителей в момент попытки записи. Проблема невидна до первого неверно направленного запроса на приём. ## Как мы это сделали **1. Сборка от шаблонов для двух направлений услуг.** Вместо того чтобы перестраивать каждую страницу независимо, мы перевели структуру существующего сайта в переиспользуемые шаблоны Elementor Pro, покрывающие оба направления — детскую стоматологию и ортодонтию. Детское направление (чистки, герметизация фиссур, фторирование, пульпотомии, реставрации) и ортодонтическое направление (раннее лечение Phase 1, традиционные брекеты, керамические брекеты, элайнеры, ретейнеры) — каждое требовало своей шаблонной обработки. Не потому, что дизайн структурно различался, а потому что маршрутизация CTA, интеграции форм и тексты для родителей на каждом направлении должны были оставаться привязанными к своему направлению в ребилде. Один шаблон страницы услуг обслуживал оба направления; различие держалось на слое контента и блоках CTA для каждого направления. **2. ТЗ выполнено строка в строку из таблицы агентства.** Агентство передало нам таблицу Google Sheets с полным реестром URL (45 URL тестовой среды, все возвращают HTTP 200), meta title и описания для каждого, и предзапускной контрольный список. Мы реализовали каждую строку как написано. Объём в часах по каждой странице мы оценили сами и зафиксировали в таблице до старта — и относились к этому ТЗ как к утверждённому бюджету, а не к приблизительной оценке. Где в таблице было значение — оно попало на новый сайт. Где его не было — мы подсветили это агентству. Никаких «творческих интерпретаций» не ушло в релиз. Принцип здесь прост: при ребилде ТЗ — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. **3. Проверка через обход, а не «на глаз».** Перед переключением DNS мы запустили параллельный обход оригинального сайта и тестового ребилда. Коды статуса, битые ссылки, цепочки редиректов, целостность мета-тегов — каждое расхождение сверяли с ТЗ агентства. Двухнаправленная структура услуг получила дополнительную проверку: каждая страница детских услуг и каждая страница ортодонтических услуг проверялась индивидуально на корректность интеграции форм и маршрутизации CTA. Второй обход подтвердил, что все внутренние ссылки разрешаются на рабочем домене после переключения. **4. Запускной контрольный список — закрыт перед сдачей.** Контрольный список покрывал точность дизайна, функциональность, корректность контента, SEO-настройки, адаптивность и клиентские интеграции по обоим направлениям. Ничего не уходило в релиз, пока не проверят и не согласуют каждую строку. QA на разных устройствах прошёл на нескольких разрешениях экрана, включая портретную и альбомную ориентацию мобильных — критическая проверка для детской практики, где родители часто ищут информацию и записываются на приём с телефона. Напряжение двухспециализированного ребилда в том, что оба направления делят один домен, но не могут делить CTA или форму. Проверка через обход сайта решила это: каждая страница детских и каждая страница ортодонтических услуг проверялась индивидуально на корректную интеграцию форм и маршрутизацию перед переключением — предзапускная проверка также выявила скрипт подмены номера телефона на исходном домене, поэтому в ребилде везде использовался настоящий «зашитый» номер. ## Результаты Метрика Результат Точность ТЗ — URL **45 / 45** контентных URL мигрированы, все возвращают HTTP 200 на тестовой среде перед переключением Точность ТЗ — метаданные **45 / 45** meta title и описаний установлены, как указано в ТЗ Точность ТЗ — шаблоны Полная система шаблонов построена и применена к обоим направлениям услуг Запускной контрольный список Все пункты контрольного списка проверены и закрыты перед переключением Сроки **~20 дней**, сдано по графику Затраты **58.2 ч** по всем задачам — основная сборка в рамках сметы; дополнительные послерелизные задачи обработаны в рамках отношений с агентством Проверка адаптивности QA на разных устройствах подтверждён на больших и мобильных экранах Внутренний QA Все задачи в рамках ответственности агентства проверены и решены перед сдачей **Статус сайта** Опубликован на Kinsta: [littlebytes.dental](https://www.littlebytes.dental/) Результат, если коротко: ТЗ агентства было выполнено как написано — по обоим направлениям услуг (детская стоматология и ортодонтия), в рамках оценённых часов, в запланированное окно переключения. Сайт опубликован и проиндексирован. ## Контроль качества Сверка контента с оригинальным сайтом выявила скрипт подмены номера телефона на рабочем домене — ребилд требовал настоящий «зашитый» номер (tel:+16503229837), а не наследование динамической подстановки оригинала — а проход по очереди правок SEO после релиза обнаружил, что canonical URL всё ещё указывает на тестовый домен. QA перед сдачей прошёл через **Site Checker** — см. [наш подход к QA](/site-checker/) с категориями и порогом нулевых ошибок. Внутренний контур проверки агентства работал после сдачи и поднимал замечания в общую очередь правок для нашего цикла исправлений до их подтверждения. ## Процесс Этап Длительность Результат Бриф и оценка 1 день ТЗ агентства проанализировано; оценка в 37.2 ч согласована Разработка ~13 дней Полный сайт перестроен на шаблонах Elementor Pro; реализована двухнаправленная структура услуг Внутренний QA и проверка 2 дня Раунды QA по этапам сборки; все задачи агентства проверены Проверка ТЗ 1 день Мета-теги и редиректы сверены с таблицей Сдача и переключение DNS 1 день Сайт на Kinsta, без простоя _Этапы пересекались (QA шёл параллельно финальной разработке), поэтому календарный срок ~20 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и двухнаправленная система шаблонов) - **Павел Сажин** — QA (раунды по этапам сборки, проверка адаптивности) - **Анна Полунина** — поддержка разработки и QA перестроенных страниц - **Людмила Травкина** — поддержка разработки (исправления из очереди правок и реализация контента) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на всём протяжении переключения и миграции. Все решения по сохранению URL, стратегии редиректов и двухнаправленной архитектуре услуг принадлежали агентству; нашей ролью была точность реализации переданного ТЗ. ## Агентствам, заказывающим ребилд WordPress > На ребилде детской стоматологии с ортодонтией главный структурный риск — потерять при переключении два разных пути пациента: плановый приём и ортодонтическую консультацию. Эта практика — модель с двумя путями, обслуживающая семьи под одним брендом; у других это детская клиника с одним путём, но несколькими точками. Отказы здесь молчаливые: карта редиректов уводит семьи на чужую форму записи. Meta title сталкиваются между путями услуг. Разметка, что приводит новых пациентов на приём, гаснет в поиске. Подрядчику стоит задавать не вопрос «соберёте ли миграцию?», а вопрос «как вы защитите карту редиректов от пересечений между путями?» Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы сверим ваш реестр URL с планом ребилда, отметим связи, что пересекают два пути пациента, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-27-page-69-days/ title: Доработка стоматологического шаблона — 27 страниц, 69 дней type: case_study date: 2026-02-01T20:05:47+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 27 страниц стоматологического шаблона Glowing от агентства, доработанных для клиники в Johns Creek — объём уточнялся в процессе разработки, когда агентство расширило ТЗ до полной карты сайта и добавило миграцию 20+ унаследованных страниц. Оба расширения поступили уже после запуска первого спринта; каждое было оформлено как отдельная задача со своей QA-очередью, что позволило не сбивать запуск основного шаблона, параллельно координируя инфраструктуру для корейской локализации. ## Краткий обзор Отрасль клиента Стоматология **Формат сотрудничества** White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса Тип проекта Доработка темы Объём 27 доработанных страниц + миграция 20+ унаследованных страниц на WordPress-сайте, размещённом на Kinsta Сроки 25 ноя 2025 – 02 фев 2026 (~69 дней) Затраты 55.42 ч (оценка) Команда 4 — Антон Херсун (руководитель проекта), Павел Сажин, Тимур Арбаев, Наталия Богатель Шаблоны 92 переиспользуемых шаблона в библиотеке агентства, применённых на 27 доработанных страницах Технологии WordPress · Kinsta · Elementor · Gravity Forms · GTranslate · Weave SMS · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** 471 отслеженная задача согласована (235 SEO + 236 CX) по 78-пунктному контрольному списку запуска **Сдано** Запущено на Kinsta; ожидается финальный контент клиента (корейские переводы в работе) **Ритм коммуникации** 3 задачи от агентства · 1 из 3 закрыта к моменту сдачи **Раунды проверки** ≈5 раундов проверки за 69-дневный календарный период **Контрольный список запуска** 78 пунктов, согласованы перед переключением ## Постановка задачи Бриф агентства представлял собой пакет макетов в Figma, наложенный на их существующую библиотеку стоматологических шаблонов, размещённую на Kinsta, с поддержкой двуязычности (английский — корейский). Стоматологической клинике в Johns Creek, Georgia, требовалась полная доработка темы: каждый цвет, фото и строка текста заменены в соответствии с дизайн-системой агентства, при этом базовые компоненты шаблона остались нетронутыми. Изначальный объём охватывал часть карты сайта — бюджет был пересчитан, когда агентство подтвердило 27 доработанных страниц плюс 20+ унаследованных страниц, ни одна из этих цифр не фигурировала в первоначальной оценке. > **Контекст рисков.** Риск, от которого страховалось агентство, — дестабилизация уже запущенной доработки темы из-за расширения объёма. Два незапланированных расширения поступили после запуска первого спринта — волна создания 27 страниц и миграция 20+ унаследованных страниц — ни одно из них не покрывалось исходной оценкой. Опасность была не просто в перерасходе часов; спешная доработка могла затронуть общие компоненты шаблона и ухудшить качество других стоматологических сайтов, использующих тот же шаблон. Стратегия снижения рисков заключалась в оформлении каждого расширения как отдельной задачи со своей QA-очередью, что позволило не сбивать запуск основного шаблона. ## Как мы это сделали 1. **Figma как контракт, шаблон как холст** Агентство предоставило поэкранные макеты в Figma и карту сайта на 98 строк. Мы рассматривали файл Figma как контракт, а шаблон — как холст: каждое отклонение от стандартных настроек шаблона мы документировали относительно соответствующего фрейма Figma, так что причину любого изменения можно было восстановить в процессе QA и исправлений. 2. **QA-цикл в масштабе доработки темы** Доработка темы создаёт больше QA-поверхности, чем разработка с нуля — каждое стандартное значение шаблона, отличающееся от дизайна в Figma, — потенциальная проблема. Таблица Google Sheets агентства отслеживала 235 SEO-задач и 236 CX-задач по 78-пунктному контрольному списку запуска. Наш цикл исправлений обрабатывал их параллельно с разработкой, а не как проверку после сборки. Работать с QA параллельно разработке, а не после, — значит разбираться с проблемами там же, где они возникли, не теряя нити. 3. **Доработка без дрейфа** Все изменения под клиента мы держали в переопределениях для конкретного клиента. Общие компоненты шаблонов агентства — хедеры, футеры, глобальные стили — не трогали. Это сохраняло библиотеку шаблонов чистой для других стоматологических клиентов агентства и делало откаты предсказуемыми. 4. **Проверка на разных устройствах** Проверяли в разных разрешениях — большой экран, планшет, мобильные. Проблемы вёрстки, вызванные нестандартными пропорциями изображений или расположением переключателя двуязычности, ловили до сдачи. Два расширения объёма поступили в процессе разработки — волна создания 27 страниц и миграция более 20 унаследованных страниц — после запуска первого спринта. Каждое оформили отдельной последующей задачей со своей QA-очередью, а не растворили в текущей разработке. Такая последовательность позволила не сбивать запуск основного шаблона и не допустить утечки клиентских изменений в общие компоненты шаблона. ## Результаты Результат Детали Сдано URL 27 доработанных страниц на Kinsta + 20+ унаследованных страниц Применено шаблонов 92 определения шаблонов в библиотеке агентства; подмножество применено по карте сайта Контрольный список запуска 78 пунктов согласованы по категориям: дизайн, функциональность, контент, SEO, адаптивность QA / SEO-задачи отслежены + решены 471 отслеженная задача согласована (235 SEO + 236 CX) Сроки ~69 дней (ноя 2025 – фев 2026) Затраты 55.42 ч оценка; выполнено в рамках бюджета Команда Антон Херсун (руководитель проекта), Павел Сажин, Тимур Арбаев, Наталия Богатель Передача хостинга Kinsta тестовая среда → рабочая среда; переключение DNS под управлением агентства ## Контроль качества Проверка перед сдачей Site Checker на 27-страничной стоматологической сборке выявила замечания по трём категориям: отсутствующий H1 на главной странице (`Welcome to Johns Creek Dental Associates`), неверное значение в поле site-name RankMath и вложенная страница услуги (`/dental-implants/full-mouth-implants/`), незаметно перенаправлявшая на родительскую — все три закрыты до того, как агентство увидело сборку в тестовой среде. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Свой проверочный контур агентства работал после сдачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до окончательного согласования. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблонов агентства не изменялись. ## Процесс Этап Что происходит Длительность 1. Бриф и оценка Проверка Figma, сопоставление шаблонов, согласование оценки часов ~3 дня 2. Доработка Постраничная реализация Figma → шаблон ~30 дней 3. QA-итерации (параллельно) Site Checker (перед сдачей) + согласование очереди задач агентства ~25 дней 4. Раунды исправлений Триаж очереди задач, аудит дрейфа шаблона, регрессионные проверки ~8 дней 5. Сдача Передача на Kinsta, согласование агентством, переключение DNS ~3 дня _Этапы 2 и 3 выполнялись параллельно — проблемы QA выявлялись и исправлялись, пока доработка ещё продолжалась, а не после завершения разработки._ ## Команда - **Антон Херсун** — руководитель проекта, оценка и координация с агентством - **Павел Сажин** — доработка темы и реализация Figma → Elementor - **Тимур Арбаев** — QA-итерации, раунды исправлений и проверка на разных устройствах - **Наталия Богатель** — интеграция контента и поддержка согласования контрольного списка Агентство оставалось публичным подрядчиком на всём протяжении; вся коммуникация с клиентом, право собственности на дизайн и администрирование хостинга оставались за рамками работ по доработке. ## Агентствам с библиотекой шаблонов > Собирая сайт для стоматологической клиники на общем шаблоне, агентство рискует, что доработки под этого клиента дестабилизируют все остальные проекты на том же шаблоне. У этой практики — одна клиника с типовым набором услуг; у других — сеть клиник с единым брендом на том же шаблоне. Если подрядчик не изолирует доработки, дочерняя тема сломается при следующем обновлении родительского шаблона, ACF-поля разойдутся между проектами, а редакторский интерфейс запутает сотрудников клиента. Подрядчику стоит задавать не вопрос «дорабатываете ли вы шаблон?», а вопрос «как именно вы изолируете доработки, чтобы следующее обновление шаблона не сломало их?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы проверим, как доработки отделены от родительского шаблона, найдём места, где поля разойдутся между проектами, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-22-page-pediatric-dental-114-days/ title: Доработка темы детской стоматологии: 22 страницы за 114 дней type: case_study date: 2026-01-30T01:49:49+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 22 страницы частной детской стоматологической практики, реализованные по пошаблонным макетам Figma — каждый из 10 шаблонов имел собственный узел дизайна в проекте Figma «Dr. Matt Savage» — плюс B2B-форма направления для врачей, добавленная в середине проекта вообще без макета в Figma. Агентство провело предварительный аудит дизайна — 117 замечаний по SEO и вёрстке — перед передачей нам; мы выполнили сборку на Kinsta и провели цикл QA через 8 раундов проверки. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Сфера клиента Медицина — Детская стоматология Конечный клиент Main Street Pediatric Dentistry of Belmont (Belmont, NC) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса в сфере здравоохранения** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **22 страницы** — главная, лендинг услуг, 12 страниц услуг, «О нас», страница врача, лендинг блога, 2 поста блога, контакты, страховка, форма направления, а также служебные страницы (политика конфиденциальности, условия использования, отказ от ответственности) — Default Template Сроки 114 дней (31 июля – 22 ноября 2025), по графику Затраты ~64 часа — основная разработка, разработка формы направления, QA и исправления, управление проектом Команда 4 специалиста Шаблоны **10 повторно используемых шаблонов** на 22 страницах — Service Page применён 12 раз для дерева детских стоматологических услуг Технологии WordPress · Elementor · Kinsta хостинг · Постраничный дизайн в Figma · Gravity Forms · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **99+ отслеженных замечаний SEO и CX** согласованы по двум очередям агентства и контрольному списку запуска из 76 пунктов **Интенсивность коммуникации** 36 замечаний от агентства · все закрыты к моменту передачи (активный период 68 дней, 2025-08-09 – 2025-10-15) **Раунды проверки** ≈8 раундов за 114-дневный календарный период **Контрольный список запуска** 76 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн в Figma для Main Street Pediatric Dentistry of Belmont и доступ к своей фирменной шаблонной системе на Kinsta. Агентство уже выполнило подготовительную работу: сбор требований клиента, проектирование, подготовку контента через постраничные Google Docs и настройку хостинга. Им нужна была команда разработки, которая точно перенесёт макеты Figma в шаблон и выдержит цикл QA через любое количество раундов проверки, которое потребует практика. Объём — 22 страницы для детской стоматологии доктора Мэтта Сэвиджа, сертифицированного детского стоматолога из Belmont, Северная Каролина. Дерево услуг охватывало 12 стандартных процедур детской стоматологии — осмотры, чистка, герметизация фиссур, фторирование, неотложная помощь, пломбирование, седация, рентген, ранняя ортодонтия, белые коронки, стоматология для особых потребностей и страница первого визита — каждая доработана под шаблон Service Page агентства. Отдельно согласованная страница формы направления для врачей (B2B-канал для направляющих докторов) была добавлена в середине проекта как самостоятельная задача со своей формой Gravity Forms. Риск, который агентство держало в голове, связан с лицом практики: это частнопрактикующий врач, а не групповая. Биографическая страница доктора Сэвиджа, профессиональное фото и сертификаты — единственный сигнал доверия на всём сайте. Ошибка с фото, заглушка в биографии или контактная форма с незаполненным адресом email на момент проверки клиентом — это не косметика. Это вся страница привлечения пациентов без главного элемента. Цикл QA на сборке для одного врача обязан держать страницу доктора и контактную форму как самые рисковые модули, а не как вспомогательные страницы низкой сложности. > **Контекст рисков.** На сайте частнопрактикующего врача страница врача и контактная форма несут всю нагрузку привлечения пациентов — у практики нет второго доктора, чтобы распределить бремя доверия, и нет альтернативного контактного пути, если адрес формы указан неверно. Заглушка фото или незаполненный email в форме на момент проверки клиентом — не косметический дефект; это одновременный отказ основного сигнала доверия и первичного конверсионного пути. Контроль качества в этой разработке существовал в значительной степени для того, чтобы ни один из этих элементов не дошёл до клиента в незавершённом состоянии. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Дизайн в Figma был спецификацией. Фирменный шаблон агентства предоставлял структурный скелет. Страница за страницей мы сверяли одно с другим — там, где настройки шаблона по умолчанию совпадали с Figma, мы их оставляли; где дизайн требовал отклонения, мы дорабатывали. В частности, с начертанием шрифтов: Figma задавала насыщенность 450 для заголовков, которую переменный шрифт в вебе воспроизводит приблизительно — это потребовало постраничной проверки соответствия дизайну, а не механического копирования числового значения. Ни одно дизайн-решение не принималось на нашей стороне; Figma оставалась источником истины для каждого визуального элемента. **2. Детская стоматология одного врача, один набор шаблонов.** В отличие от парной практики «стоматология + ортодонтия», этот сайт обслуживает одну специальность под именем одного доктора. Шаблон Service Page был применён 12 раз по дереву детских стоматологических услуг — каждая страница доработана со своим текстом, изображениями и единообразным CTA «Записать ребёнка на консультацию». Страница врача несла полный вес профессиональной репутации доктора Сэвиджа: сертификаты, образование, обучение в UNC Chapel Hill, подход к детскому приёму. В середине проекта присланное фото потребовало замены (изначально было другое изображение); решили это отдельной задачей до отправки ссылки клиенту. Email практики для доставки форм Gravity Forms также не был доступен на момент сборки — его отслеживали и применили, как только агентство получило его от клиента. **3. Цикл QA в масштабе доработки темы.** Агентство вело две параллельные очереди правок: очередь SEO (63 активных пункта, 60 закрыто как Completed на момент передачи; 2 в работе, 1 требуется информация) и очередь CX (36 активных пунктов, 33 закрыто как Completed; 3 в QA). Замечания CX включали глобальную корректировку названия бренда («Main Street Dentistry» → «Main Street Pediatric Dentistry of Belmont» — применено глобально), удаление контента со страниц фторирования и стоматологических процедур по запросу клиента, настройку модального попапа для объявления о контактах практики и уточнения типографики по дереву услуг. За этими отслеженными пунктами стояло 29 задач Redmine — основной цикл разработки, отдельная сборка формы направления и множественные раунды исправлений и QA с августа по ноябрь. **4. Доработка без отклонений.** Все клиентские изменения в Elementor оставались в пределах инстанса практики; общие компоненты шаблона агентства не модифицировались. Глобальные правки (добавить «Of Belmont» в название бренда в шапке и подвале, ссылку на номер телефона в шапке, карусель карточек услуг на мобильных) мы вносили через глобальный контекст Elementor самого клиента, а не правкой общих библиотечных компонентов. **5. Проверка на разных устройствах.** Каждый раунд QA охватывал поведение мобильной карусели в сетке услуг, отображение контактной формы и попапа на разных разрешениях — форма и попап являются основными конверсионными путями на сайте частного практикующего врача, где родителю нужно связаться с практикой со смартфона. На сборке для частного практикующего врача всё давление сосредоточено в слое доверия: фото при предклиентской проверке оказалось не тем и было заменено отдельной задачей; email для контактной формы не был доступен на момент сборки и отслеживался до получения. Ни один из этих элементов не дошёл до клиента незавершённым — на сайте, где страница доктора и единственный контактный путь несут всю нагрузку привлечения пациентов, такой порядок работы не обсуждается. ## Контроль качества Наибольшая нагрузка QA в этой сборке пришлась на уровень идентичности частного практикующего врача: фото на странице доктора было не тем на предклиентской проверке (Redmine #1217) и заменено до отправки ссылки; email практики для контактной формы не был доступен на момент сборки, отслеживался в #996 «Add Doctor Images & Emails» и применён после получения агентством — ни один элемент не дошёл до клиента незавершённым. QA перед передачей проходило через **Site Checker** — см. [наш подход к QA](/site-checker/) — с категориями и порогом нулевых ошибок. Контроль на стороне агентства работал после передачи и вносил замечания в общую очередь правок для нашего цикла исправлений до их согласования. Все доработки оставались в переопределениях конкретного клиента; общие компоненты шаблона агентства не модифицировались. ## Результаты Метрика Результат Страниц сдано **22** — Service Page ×12, главная ×1, «О нас» ×1, страница врача ×1, лендинг услуг ×1, лендинг блога ×1, блог ×2, контакты ×1, страховка ×1, форма направления ×1 (индивидуальная Gravity Forms), Default Template ×1 Шаблонов применено **10 из 10** шаблонов на 22 страницах Контрольный список запуска **76 пунктов** — Design / Functionality / Pre-Migration / Post-Migration Замечаний QA отслежено и закрыто **99+ пунктов** — очередь правок SEO (63 активных, 60 Completed) и очередь правок CX (36 активных, 33 Completed) Форма направления Самостоятельная страница с формой Gravity Forms, разработана и проверена как отдельный модуль Сроки **114 дней** (31 июля – 22 ноября 2025), сдано по графику Затраты **~64 часа** при оценке ~64 часов — без перерасхода Команда **4 специалиста** Хостинг при передаче Работает в шаблонном окружении агентства на Kinsta по адресу `mainstpediatricdentistry.com` Если коротко: дизайн агентства в Figma реализован в их фирменном шаблоне на 22 страницах и 10 шаблонах за 114 календарных дней, в рамках согласованного бюджета, с двумя очередями QA (SEO + CX), проработанными до уровня приемлемости агентства, и контрольным списком запуска из 76 пунктов, согласованным до выхода сайта на рабочий домен. ## Процесс Этап Длительность Результат Бриф и оценка ~2 недели Figma изучена, доступ к шаблону подтверждён, объём согласован; назначены постраничные Google Docs как источник контента Разработка доработки ~3 недели Доработка 22 страниц в тестовой среде Kinsta; открыты первые строки очереди правок Разработка формы направления ~1 неделя (параллельно) Страница Dr. Referral Form как самостоятельный модуль на Gravity Forms Итерации QA ~8 недель 99+ пунктов по очередям SEO + CX отслежены и закрыты; фото заменено; email для форм применён после получения; обработаны раунды обратной связи клиента Страница врача и контактные данные Постоянно в ходе QA Фото заменено; email получателя применён ко всем формам и попапу; название бренда скорректировано глобально Контрольный список запуска и сдача Финальные ~2 недели Контрольный список из 76 пунктов согласован; переключение на рабочий домен `mainstpediatricdentistry.com` _Разработка и QA шли параллельно на всём протяжении — типично для доработки темы, где «фаза QA» не закрывается чисто; цикл работает, пока агентство и клиент не подпишут._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (доработка темы, перенос Figma в макет, итерации QA) - **Павел Сажин** — контроль QA и надзор за раундами исправлений - **Тимур Арбаев** — поддержка разработчика на поздних раундах исправлений и QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороной агентства, согласование) Агентство владело дизайном, коммуникацией с клиентом и циклом проверки с доктором Сэвиджем; каждый раунд исправлений проходил триаж через общую очередь агентства и выпускался только после согласования с проверяющим со стороны агентства. Наша команда всё время работала в тестовой среде Kinsta; переключение на рабочий домен было решением агентства. ## Агентствам с библиотекой шаблонов > На сборке по шаблону граница между общим шаблоном и доработками вашего клиента — там, где живёт риск. Для одиночной клиники детской стоматологии шаблон настраивается один раз. Для сети из нескольких клиник тот же шаблон должен нести разные страницы врачей, местные телефоны и отдельные списки страховок. Переопределения в дочерней теме молча ломаются, когда поставщик шаблона выпускает обновление. Схема полей ACF расходится между вашими доработками и значениями по умолчанию от автора шаблона — поля, которые рисовались в тестовой среде, перестают рисоваться в бою. Бренд-токены не доходят до жёстко прошитых запасных значений — смена цвета, согласованная на главной, так и не применяется к страницам архива. Вопрос подрядчику перед стартом — не «соберёте ли на нашем шаблоне?», а «как вы изолируете доработки клиентского слоя, чтобы они пережили следующее обновление шаблона?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы сверим границу шаблона с вашей спецификацией, укажем, где доработки столкнутся со следующим обновлением шаблона, и вернём фиксированную смету в часах. Без оплаты, со сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-oral-surgery-43h-26-days/ title: Разработка сайта для хирургической стоматологии на WordPress — 65 URL за 26 дней type: case_study date: 2026-01-24T23:03:44+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 65 страниц по 9 шаблонам хирургической стоматологии за 26 дней, 1 024 битые ссылки проверены и устранены на тестовой среде до того, как агентство мигрировало сайт на рабочий домен. Мы отвечали за соблюдение шаблонов и устранение битых ссылок; агентство — за карту сайта и коммуникацию с клиентом. 43 часа от брифа до передачи, никаких перерасходов, никаких доработок после миграции. ## Краткий обзор Поле Значение Сфера деятельности клиента Медицина — Хирургическая стоматология и имплантология Конечный клиент Warren Oral Surgery and Dental Implant Center (Warren, NJ) **Формат сотрудничества** **White-label — разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка на WordPress с Elementor на собственной тестовой среде, передана под миграцию на рабочий домен Объём работ **65 URL** — главная, 11 услуг по имплантации, 11 страниц процедур и удаления зубов мудрости, 4 страницы врачей, блог-лендинг + 11 постов, контакты, о нас, 6 вспомогательных страниц на стандартном шаблоне и раздел для пациентов Сроки 26 дней (6 фев – 4 мар 2025), сдано в срок Затраты **43 часа** при оценке 43 часа — без перерасхода Команда 3 специалиста (разработчик · QA · руководитель проекта) Шаблоны **9 переиспользуемых шаблонов** — стандартная библиотека агентства для хирургической стоматологии Техстек WordPress · Elementor · mmm-web.com тестовая среда · Yoast · Screaming Frog · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Результат** **65 URL построено, очередь из 9 задач закрыта (7 Выполнено), 49 пунктов контрольного списка готово, аудит битых ссылок пройден** **Динамика задач** 9 задач от агентства · 7 из 9 закрыты к моменту передачи **Раунды проверки** ≈3 раунда за 26 календарных дней **Контрольный список запуска** 49 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое клиникой Warren Oral Surgery and Dental Implant Center (Warren, NJ), передало нам таблицу Google Sheets с картой сайта на 92 строки, каталогом из 9 шаблонов, контрольным списком запуска на 49 пунктов и заранее заполненной очередью задач. Разработка велась на собственной тестовой инфраструктуре агентства `warrenoral.mmm-web.com`; конструктор страниц — Elementor; рабочий домен — `warrenoralsurgery.com` со структурой URL, сохранённой с исходного сайта. Задача заключалась в том, чтобы сверстать все страницы по карте сайта согласно назначенным шаблонам, закрыть очередь задач до приёмки агентством, провести аудит битых ссылок на тестовой среде и подготовить контрольный список запуска на 49 пунктов до того, как агентство выполнит миграцию на рабочий домен. Коммуникация с клиентом оставалась на стороне агентства; мы возвращали неясности их команде и не импровизировали с назначениями шаблонов или контентными решениями. > **Контекст рисков.** На проекте для хирургической практики агентство беспокоится не о том, умеет ли разработчик собирать страницы, — а о том, достаточно ли чиста тестовая среда, чтобы мигрировать без сюрпризов после запуска. Пациенты, ищущие имплантолога или удаление зуба мудрости, готовы записаться сразу и почти не прощают сломанных форм или отсутствующих страниц. Сайт должен быть проверен до миграции на рабочий домен, а не после. Наша задача заключалась в том, чтобы закрыть каждый открытый пункт очереди задач, подготовить тестовую среду, прошедшую полную проверку битых ссылок, и сдать контрольный список в состоянии, готовом к согласованию, — чтобы день миграции стал выполнением, а не авралом. ## Как мы это сделали **1. 9 шаблонов, 65 страниц, один процесс сборки.** Страницы Warren были распределены по библиотеке шаблонов агентства для хирургической стоматологии: главная, блог-лендинг, блог (11 перенесённых постов), страница услуг (самая объёмная — 11 подстраниц имплантации плюс 11 страниц процедур и удаления зубов мудрости), страницы врачей (4 хирурга), контакты, о нас и стандартный шаблон для вспомогательных страниц, включая разделы для пациентов и юридическую информацию. Каждая страница строилась по назначению шаблона из карты сайта; ни одна страница не была сделана вручную вне системы шаблонов. Поскольку на старте у агентства ещё не было хостинговых учётных данных, мы развернули сайт на своём сервере, чтобы не задерживаться, — готовая сборка позже была перенесена на тестовую среду агентства для формального QA. **2. Спецификация выполнена в рамках согласованной сметы.** Карту сайта на 92 строки и шаблоны дало агентство; объём в часах мы оценили сами и зафиксировали до старта. Дальше держались сметы строго: итог совпал с оговорёнными 43 часами — без пересмотров по ходу и без расширения объёма. **3. Аудит битых ссылок проведён до передачи тестовой среды.** Сканирование Screaming Frog выявило 1 024 экземпляра битых ссылок по всему сайту — из-за сочетания отсутствующих страниц и неперенаправленных путей со старого сайта. Команда проработала вкладку аудита, исправила исходящие ссылки для каждого исходного URL и подготовила тестовую среду с закрытым списком битых ссылок до того, как агентство выполнило миграцию на рабочий домен. **4. Двухтрековый QA-цикл, очередь задач закрыта.** Задачи отслеживались во вкладке «Issues Backlog» агентства (9 строк, приоритеты от низкого (Low) до срочного (Urgent)). 7 пунктов закрыты как «Выполнено» до передачи; оставшиеся 2 оставались в работе по задачам, зависящим от решений конечного клиента (продление чата и статус платёжной формы). Контрольный список запуска на 49 пунктов — дизайн, функциональность, контент, SEO и аналитика — был полностью заполнен до согласования тестовой среды. Тот факт, что учётные данные хостинга агентства ещё не были получены к началу работ, стал вынуждающим ограничением — мы сначала построили на своём сервере, а затем перенесли готовую сборку. Такой порядок позволил провести полную очистку 1 024 битых ссылок на тестовой среде до того, как агентство приступило к миграции, так что день миграции стал операцией копирования, а не сеансом отладки. ## Результаты Метрика Результат Построено URL **65** по 9 шаблонам (1 главная · 1 лендинг блога · 11 постов · 11 страниц услуг имплантации · 11 страниц процедур / удаления зубов мудрости · 4 страницы врачей · 1 контакты · 1 о нас · 6 вспомогательных страниц на стандартном шаблоне) Использовано шаблонов **9 / 9** из стандартной библиотеки агентства для хирургической стоматологии Аудит битых ссылок **1 024 экземпляра** проверено на тестовой среде; устранены до миграции на рабочий домен Очередь задач **7 / 9** закрыты как «Выполнено»; 2 оставались в работе (зависимости от решений клиента) Контрольный список запуска **49 пунктов** подготовлено по разделам дизайн / функциональность / контент / SEO и аналитика Сроки **26 дней**, сдано в срок Затраты **43 ч / 43 ч оценка** — без перерасхода, без расширения объёма **Статус сайта** Работает, открывается по адресу https://www.warrenoralsurgery.com/ — проверено в апреле 2026. Если коротко: разработка на 65 URL сдана на 9 шаблонах на тестовой среде, в рамках оговорённого бюджета в 43 часа, с устранёнными битыми ссылками и списком задач, отработанным до приёмки агентством перед миграцией. ## Контроль качества Этап QA охватывал три типа экранов, целостность ссылок, теги H1–H6, заголовки и мета-теги, а также точность миграции контента — были обнаружены и устранены пропуски H1 на главной и на `/dental-implants/`, неактивные иконки соцсетей в подвале, смешанный HTTP-контент видео и отсутствующая страница неотложной стоматологической помощи. Всё исправлено до передачи тестовой среды агентству. Предварительное QA проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порог нулевых ошибок. Свой контроль на стороне агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица изучена, объём оценён, 43 ч согласованы Разработка (страницы + шаблоны) ~2 недели Все 65 URL построены по 9 шаблонам на тестовой среде; очередь задач открыта QA и аудит битых ссылок ~1 неделя Аудит битых ссылок пройден, 7/9 задач закрыты, контрольный список подготовлен Передача тестовой среды Финальный день Тестовая среда сдана; агентство выполнило миграцию на рабочий домен _QA и разработка шли параллельно — проверка битых ссылок началась одновременно с завершением последних страниц, поэтому календарь составил 26 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик, сборка и реализация шаблонов - **Анна Полунина** — этап QA и проверка контрольного списка запуска - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались на стороне партнёрского агентства на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте хирургической стоматологии каталог операций — это не только навигация: он задаёт URL-архитектуру, граф структурированной разметки и позиции, которые агентство выстроило в выдаче. У этой практики — узкая специализация на имплантологии и реабилитации; у других — ортодонтия и профилактика с широкой линейкой услуг. Новый вид операции через полгода не впишется в URL-схему. Структурированная разметка слетит на импорте — расширенные результаты пропадут из панелей. Страницы с фильтрацией, группирующие операции по показаниям, выпадут из индекса. Спрашивайте подрядчика не «соберёте ли каталог?». Спрашивайте «как именно вы построите таксономию, чтобы следующая услуга встала без миграции и без потери позиций?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим URL-план с вашими ранжирующимися страницами, отметим места, где архитектура будет спорить с вами на шестом месяце, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-22-page-dental-183-days/ title: Доработка темы: 22 страницы, 183 дня type: case_study date: 2026-01-22T15:24:28+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 22 страницы на 11 шаблонах, свёрстанных по Figma на стоматологическом шаблоне WP Engine — первичная сборка завершена, QA от агентства пройден, сайт запущен. Затем переименование категории поменяло slug с `/service/` на `/services/`, и «многие ссылки на `/service/` стали выдавать 404». Исправление на рабочем сайте, доступном пациентам, потребовало трёх контролируемых раундов QA в декабре 2025 — январе 2026: каждый раз — обновление slug, проверка навигации, подвала и CTA на страницах, затем ожидание согласования агентством перед следующим раундом. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. Изменение URL-структуры после запуска — согласованное уже после первичной сдачи — потребовало контролируемого повторного захода без сбоев на уже опубликованном сайте. ## Краткий обзор Поле Значение Индустрия клиента Стоматология — косметическая + общая Конечный клиент Heart of Hingham Dental (Hingham, MA) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + дизайн по Figma на страницу, хостинг WP Engine) Объём **22 URL** — главная, о клинике, врач, контакты, первый визит, услуги (лендинг), **10 страниц услуг** (общая стоматология, косметическая стоматология, Invisalign, комплексные осмотры, пломбирование, коронки на имплантах, виниры, дизайн улыбки, керамические коронки, керамические мосты), блог (лендинг), галерея улыбок, условия, политика конфиденциальности, отказ от ответственности Сроки 183 дня (17 июл 2025 – 16 янв 2026), в срок Затраты 69 часов — разработка, итерации QA и управление проектом Команда 6 специалистов Шаблоны **11 переиспользуемых шаблонов** предоставлены агентством, применены на 22 страницах Технологии WordPress · Elementor · WP Engine хостинг · дизайн по Figma на страницу · AutoQA агентства (проверка ссылок / email) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **324+ отслеженных SEO + CX проблем** согласованы в очереди задач агентства, 73-пунктный контрольный список запуска **Интенсивность** 125 задач от агентства · все закрыты к сдаче (77 активных дней, 2025-08-08 – 2025-10-23) **Раунды проверки** ≈11 раундов проверки за 183 календарных дня **Контрольный список запуска** 73 пункта, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США предоставило дизайн в Figma для Heart of Hingham Dental и доступ к своей брендированной системе шаблонов на WP Engine. Агентство согласовало с клиентом направление дизайна, конфигурацию хостинга и карту сайта в Google Sheets с назначением контента и шаблонов для каждой страницы. Наша задача — доработать шаблон под Figma на 22 страницах, используя документацию агентства как источник контента, и поддерживать цикл исправлений до полного подписания. Задача была понятной: реализовать Figma, фиксировать пробелы в контенте вместо того чтобы импровизировать — агентство сразу предупредило, что на большинстве страниц услуг нет фотографий и нужны заглушки, пока команда link-building не подберёт нормальные снимки, — и возвращать каждый раунд исправлений в очередь задач агентства до полного закрытия. Работы растянулись дольше, чем предполагал объём, — но причина не в расширении объёма работ: после первичного запуска клиника попросила изменить структуру URL, и это было согласовано уже после сдачи. URL стоматологической клиники — не просто адреса; это узлы, от которых зависят внутренняя навигация, карта сайта и уже проиндексированные страницы. Менять их после запуска можно только в строгой последовательности: новые slug в живом окружении, обновление навигации на новые пути, проверка карты сайта и логики редиректов — без осиротевших ссылок, видимых пациентам. Изменение структуры URL добавило три раунда QA после релиза — в декабре 2025 и январе 2026, каждый был проверен и закрыт до финального подписания работ. Именно поэтому агентство оставило нас на всю реструктуризацию URL, а не делало это самостоятельно: смена slug может обновить страницу, но пропустить ссылку в навигации, или редирект корректно работает в шапке, но не срабатывает в подвале или CTA блога. Когда пациенты приходят на запись через закладки или из локального поиска, битая ссылка на рабочем сайте — это не задача тестовой среды. > **Контекст рисков.** Изменение URL после запуска на живом стоматологическом сайте имеет конкретный тихий сбой: смена slug доходит до страницы, но пропускает ссылку в подвале, CTA на странице или перекрёстную ссылку в блоге — осиротевшие пути остаются видны пациентам в рабочей навигации, а не в тестовой среде. Агентство оставило нас на всю реструктуризацию URL, а не делало это самостоятельно, именно чтобы избежать частичного обновления: каждая навигационная поверхность должна была быть проверена на чистоту в каждом из трёх раундов QA после релиза — до закрытия работ. ## Как мы это сделали 1. **Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страницы. Наша задача — свести их постранично: там, где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовала отклонения — дорабатывали. Ни одно дизайн-решение не исходило от нас. 2. **Заглушки на страницах с неполным контентом — по единому правилу.** Карта сайта агентства указывала, что большинство страниц услуг содержат контент, подготовленный AI, а не фотографии от клиники. Оставлять пустые блоки вёрстки в тестовой среде — значит засорять проверку. Вместо этого каждая страница с неполным контентом получила стандартную заглушку из библиотеки ресурсов шаблона. Единый подход держал тестовую среду чистой, пока агентство параллельно подбирало финальные изображения. Каждую заглушку отметили в комментариях к карте сайта, чтобы команда link-building могла расставить замены по приоритету. 3. **Цикл QA с большой очередью задач.** Из 30 задач Redmine 15 имели метку QA. Помимо Redmine, общая очередь задач агентства накопила 189 SEO-замечаний и 135 CX-замечаний — всего 324+ пункта, согласованных в 73-пунктном контрольном списке запуска. Такой объём для сайта из 22 страниц отражает уровень вовлечённости конечного клиента: Heart of Hingham Dental отправлял обратную связь напрямую через инструмент визуального аннотирования, а агентство провело тщательный цикл проверки после передачи. Каждый пункт очереди задач был обработан и закрыт до согласования; ни одна категория не была частично согласована и отложена. 4. **Контролируемая реструктуризация URL после запуска.** Изменение структуры URL — отслеженное по 4 задачам Redmine в декабре 2025 и январе 2026 — потребовало изменения slug страниц на живом окружении WP Engine, обновления всей внутренней навигации и проверки полной карты ссылок сайта на каждом раунде QA. Три раунда QA после релиза подтвердили, что новая структура URL согласована в навигации главной страницы, ссылках подвала, CTA на страницах и перекрёстных ссылках блога до финального закрытия. 5. **Доработка без отклонений.** Каждое изменение в брендированном шаблоне — включая правки URL после запуска — мы вносили через переопределения под каждого клиента. Общие компоненты шаблона агентства не трогали ни на одном этапе, включая пострелизный. 6. **Проверка на разных устройствах.** Доработки и изменения URL после релиза проверялись на Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах на всём протяжении работ. Реструктуризация URL после релиза прошла три раунда QA в декабре 2025 и январе 2026 — каждый подтверждал, что смена slug с `/service/` на `/services/` дошла до навигации, ссылок подвала, CTA на страницах и перекрёстных ссылок блога на рабочем сайте. Стандарт тот же, что и при первичной сборке: ничего не закрывается, пока карта ссылок не чиста. ## Контроль качества Контрольный список QA перед сдачей для этой работы включал отдельную проверку единообразия завершающих слешей по всем 22 URL — и когда переименование категории после релиза поменяло `/service/` на `/services/`, изменение slug выявило битые внутренние ссылки по всему сайту (Redmine #1239: «many links to /service/ now became 404»), которые были исправлены в раундах QA реструктуризации URL до закрытия работ. QA перед сдачей прошёл через **Site Checker** — см. [наш подход к QA](/site-checker/) для списка категорий и принципа нулевых ошибок. Внутренний контур проверки агентства работал после передачи и поднимал проблемы в общую очередь задач для нашего цикла исправлений до окончательного согласования. Доработки оставались в рамках переопределений под каждого клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL доставлено **22** — 1 главная, 1 о клинике, 1 врач, 1 контакты, 1 первый визит, 1 услуги (лендинг), 10 страниц услуг (общая стоматология, косметическая стоматология, Invisalign, осмотры, пломбирование, коронки на имплантах, виниры, дизайн улыбки, керамические коронки, керамические мосты), 1 блог (лендинг), 1 галерея улыбок, 3 юридические страницы Шаблонов применено **11 из 11** переиспользуемых шаблонов собраны и сопоставлены (включая уникальный шаблон First Time / New Patient агентства) Контрольный список запуска **73 пункта** согласованы QA / SEO + CX проблем отслежено и решено **324+** пункта согласованы в двух вкладках очереди задач агентства (189 SEO + 135 CX) Итераций QA в Redmine **15 из 30 задач (50%)** отслежены на уровне итераций Реструктуризация URL после релиза **4 дополнительных задачи Redmine** в декабре 2025 – январе 2026, все проверены QA и закрыты Сроки **183 дня**, сдано в срок Затраты **69 часов** — без перерасхода, без расползания объёма работ Команда **6 специалистов** Передача хостинга Работает на окружении шаблона WP Engine агентства Здоровье страниц при сдаче Все 22 URL в тестовой среде подтверждены; реструктуризация URL после релиза проверена на чистоту ссылок до финального закрытия Если коротко: Figma агентства реализована на их брендированном шаблоне на 22 страницах и 11 шаблонах, выдержана через очередь задач QA из 324+ пунктов и реструктуризацию URL после релиза, за 183 календарных дня, в рамках оценки в 69 часов. ## Процесс Фаза Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к шаблону подтверждён, стратегия заглушек контента согласована Разработка доработок ~2 недели Постраничная доработка шаблона; заглушки на страницах с неполным контентом по единому правилу Итерации QA (параллельно) ~12 недель 15 раундов QA зафиксировано; 324+ пункта очереди задач согласовано Реструктуризация URL после релиза ~6 недель (дек–янв) 4 задачи Redmine за 3 раунда QA; структура URL изменена, навигация проверена на живом Финальное подписание янв 2026 Все пункты закрыты; сайт подтверждён чистым по ссылкам в новой структуре URL _Разработка и QA шли параллельно — это характерно для работ по доработке темы, где ни одна «фаза QA» не закрывается чисто; цикл идёт непрерывно, пока агентство не подпишет работы._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона и приведение макетов Figma к шаблону, реструктуризация URL после релиза) - **Павел Сажин** — ведущий QA (проверка очереди задач, координация проверки после релиза) - **Анна Полунина** — поддержка доработки темы и QA - **Тимур Арбаев** — поддержка разработки на средних раундах доработки - **Людмила Травкина** — разработчик (сборка страниц услуг, реализация заглушек контента) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, координация работ после релиза) Агентство поддерживало отношения с конечным клиентом на всём протяжении. Конечный клиент нас не видел: все запросы — включая изменение структуры URL после запуска — координировались через общую очередь задач агентства, без прямого взаимодействия с клиникой. ## Агентствам с библиотекой шаблонов > При сборке сайта стоматологической клиники на готовом шаблоне главный риск для агентства-заказчика — исчезновение границы между общей библиотекой блоков и клиентским слоем. У одиночной клиники переопределений немного: бренд-токены и пара своих полей. У стоматологической сети из нескольких точек — отдельные типы записей и брендирование под каждый филиал. Сбои здесь тихие: обновление родительской темы перезаписывает ваши правки в дочерней теме, форма обратной связи перестаёт отправлять письма без единой ошибки в логе, а правка бренд-цветов в кастомайзере не доходит до жёстко прописанных секций в шапке и подвале. Подрядчику стоит задавать не «соберёте ли вы сайт из шаблона», а «как именно вы изолируете клиентские доработки так, чтобы обновления родительской темы не задели согласованные макеты?» Пришлите исходник шаблона (или ID темы) и спецификацию бренда. Мы проверим, как ваши доработки завязаны на родительскую тему, и найдём узлы, где обновление сломает согласованные доработки. Без оплаты, вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-59-page-periodontics-66-days/ title: Доработка темы для пародонтологии: 59 страниц за 66 дней type: case_study date: 2026-01-14T03:15:06+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 59 страниц пародонтологической клиники с дентальными имплантами — по прототипу Figma «DENTAL HOMEPAGE DESIGN» агентства, через 10 шаблонов, с AI-сгенерированным контентом взамен всего существующего наполнения клиента. Причина: клиент не владел правами на перенос старого контента. Агентство задало дизайн-референс и предоставило контент; наша зона ответственности — постраничное наложение шаблонов и цикл QA через четыре раунда проверки в тестовой среде WP Engine. На сайте пародонтологии и дентальных имплантов это особенно заметно. У хирургической специализированной клиники таксономия услуг, под которую типовой стоматологический шаблон изначально не рассчитан: лазерные процедуры, костная пластика, снятие зубных отложений и сглаживание корней, удлинение коронковой части зуба, полные реконструкции зубного ряда на имплантах. Это совсем не те структуры контента, что плановая чистка или пломбирование. Агентство приняло нестандартное решение: вместо переноса существующего контента клиента был заказан новый AI-сгенерированный контент для всего сайта. Каждая страница — это совершенно новое размещение контента: Figma как дизайн-референс, свежий текст как наполнение, шаблон как структурный контейнер. ## Краткий обзор Поле Значение Отрасль клиента Медицина — пародонтология и дентальные импланты Конечный клиент Middlesex Periodontics & Dental Implants (East Brunswick, NJ) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный стоматологический шаблон агентства + постраничные макеты Figma на WP Engine) Объём **59 URL** — главная, 24 страницы услуг (лазерные процедуры, пародонтологические процедуры, дентальные импланты, костная пластика, сопутствующие специальные страницы), 3 страницы «О нас», 1 страница врача, 1 контактная страница, 28 страниц информации для пациентов и сопутствующих материалов Сроки 66 дней (19 фев – 26 апр 2025), в срок Затраты 54 часа — 32 ч разработка · 14 ч QA и циклы исправлений · 8 ч PM Команда 6 специалистов Шаблоны **10 переиспользуемых шаблонов**, предоставленных агентством, применённых на 59 страницах Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine hosting · Yoast · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **41+ замечание**, разобранное в очереди правок агентства, с контрольным списком запуска на 48 пунктов **Интенсивность коммуникации** 41 замечание от агентства · все закрыты к моменту передачи (активный период 12 дней, 2025-03-21 – 2025-04-01) **Раунды проверки** ≈4 раунда проверки за 66 календарных дней **Контрольный список запуска** 48 пунктов, согласован перед переключением ## Постановка задачи Middlesex Periodontics & Dental Implants — специализированная пародонтологическая клиника в East Brunswick, New Jersey, под руководством доктора Daniel Reich. Практика охватывает пародонтологические операции, дентальные импланты, лазерные процедуры и полную реконструкцию зубного ряда — клинический объём, выходящий далеко за рамки меню услуг общей стоматологии. Маркетинговое агентство из США управляло редизайном сайта: в их зоне ответственности были дизайн (прототип Figma для главной страницы и шаблоны внутренних страниц), контент-стратегия (AI-сгенерированный контент, поскольку клиент не имел прав на перенос существующего сайта), хостинг WP Engine и отношения с клиентом. В нашу задачу входила доработка стоматологической системы шаблонов агентства под макеты Figma и наполнение каждой страницы новым контентом. Таблица Google Sheets содержала 65 строк карты сайта: 4 редиректа и 2 удаления — итого 59 активных страниц для сборки по 10 шаблонам. Нам предстояло перенести прототип Figma «Dental Homepage Design» на главную и шаблоны внутренних страниц, вставить AI-сгенерированный контент, устранить проблемы с формами и навигацией, которые всплыли в проверочных раундах агентства, и закрыть очередь правок до запуска сайта. Дизайн, утверждение контента, коммуникация с клиентом и SEO-стратегия оставались на стороне агентства. > **Контекст рисков.** Сложность доработки с полной заменой контента в том, что каждую страницу можно выставить по Figma и вставленному тексту, но проверить против живого источника нечем. На обычном проекте по доработке темы команда сравнивает действующий сайт со сборкой на тестовой среде — и сразу видит неверно вставленный текст или не тот блок; здесь контент был написан с нуля, а дизайн существовал только в Figma. Доработка, при которой контент оказался в неверном разделе шаблона — или макет правильный, но нет клиентских изображений и контактных данных, переданных агентством — на тестовой среде внешне не провалится. Единственным барьером были цикл QA агентства и наши раунды исправлений. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Прототип Figma определял дизайн главной страницы и CSS-референс для всех внутренних страниц — цвета, шрифты, размер текста, фоновое оформление, навигационную панель и структуру подвала. Брендированный стоматологический шаблон агентства служил структурным контейнером. Наша задача была согласовать одно с другим: там, где настройки шаблона по умолчанию совпадали с Figma, мы их оставляли; где прототип требовал отклонений — дорабатывали. Ни одно дизайн-решение не исходило от нас. Когда Figma стала временно недоступна (проблема доступности платформы), команда сохранила локальный экспорт, чтобы не останавливать сборку и не создавать пробелов. **2. QA в масштабе специализированной стоматологии.** Качественная доработка темы идёт раундами, а не одним проходом. За проект мы вели 14 задач в Redmine и разобрали 41+ пункт в очереди правок агентства — отмечали и исправляли структуру навигации, hero-секцию, наполнение отзывов, маршрутизацию контактных форм, замену изображений, размещение контента, целостность ссылок. Эти замечания — тот самый разрыв между «шаблон применён» и «шаблон совпадает с Figma и контентом клиента». Здесь и проходит граница между шаблонным сайтом, который выглядит «примерно правильно», и тем, что агентство готово подписать. **3. Специализированная лексика на 10 шаблонах.** Таксономия услуг клиники охватывает пародонтологические операции, дентальные импланты, лазерные процедуры (LANAP, LAPIP), костную пластику и подразделы для пациентов: финансирование, страховка, формы. Библиотека шаблонов агентства включала 10 вариантов: главная, «О нас» (применён 3 раза — история клиники, команда, сотрудники), страница врача, страница услуги (24 раза — самый нагруженный шаблон), контакты, шаблон по умолчанию (28 вспомогательных страниц), плюс шаблон «Smile Gallery» для предоставленных клиентом фотографий «до и после». Каждый шаблон применялся по строке карты сайта; ни одна страница не была создана вне системы шаблонов. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах. Каждый раунд QA охватывал страницы, затронутые корректировками конкретного раунда, без полного перепрохода сайта — это поддерживало эффективность цикла без потери покрытия на любой точке адаптации. Именно подход «Figma как контракт» удержал сборку, когда платформа Figma стала временно недоступна в середине проекта. Команда экспортировала локальную копию вместо паузы, и разработка пошла дальше по этому референсу — через четыре раунда проверки и 41 пункт очереди правок агентство подписало сайт, который соответствовал тому, что Figma задала с самого начала. ## Контроль качества Очередь правок по этому проекту насчитывала 41 пункт за 12 дней активной проверки. Категории: целостность URL (ошибки 404 и некликабельные телефоны с адресами), контраст на мобильных (текст мобильного меню сливался с фоном), размещение контента (ответы FAQ на главной дублировались во всех блоках). Каждое замечание поймали до передачи сборки агентству. QA перед передачей шёл через **Site Checker** — см. [нашу методику проверки](/site-checker/) с перечнем категорий и порогом нулевых ошибок. Проверка на стороне агентства шла после передачи и вносила замечания в общую очередь правок для нашего цикла исправлений, пока агентство не согласовало результат. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблонов агентства не изменялись. ## Результаты Метрика Результат URL доставлено **59** — страница услуги (24) · шаблон по умолчанию (28) · «О нас» (3) · главная (1) · страница врача (1) · контакты (1) · обработаны редиректом (4 по карте сайта, не построены как страницы) Шаблонов применено **10 из 10** переиспользуемых шаблонов из библиотеки агентства Контрольный список запуска **48 пунктов** согласовано Очередь задач **38 / 41** закрыто как Completed; 3 в QA на момент передачи Итерации QA в Redmine **14 из 14 задач** отслежено, все закрыты или согласованы Сроки **66 дней** (19 фев – 26 апр 2025), доставлено в срок Затраты **54 часа** при оценке ~54 часа — без перерасхода Команда **6 специалистов** Хостинг Развёрнут на WP Engine; работает на eastbrunswickperio.com **Статус сайта** Работает по адресу https://www.eastbrunswickperio.com/ — проверено в апреле 2026 Если коротко: Figma агентства реализовали на их брендированном стоматологическом шаблоне — 59 страниц, 10 шаблонов, 66 календарных дней, в рамках оценённых часов. Очередь правок — запись разрыва между первым проходом и финальным состоянием — закрыта на 38 из 41 пункта (статус Completed) до запуска. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Figma получена, таблица Google Sheets с AI-контентом проверена, доступ к шаблонам подтверждён, объём и часы согласованы Первичная доработка ~3 недели Постраничное применение шаблонов, дизайн главной воспроизведён по Figma, AI-контент интегрирован Итерации QA (параллельно) ~4 недели Открыта очередь правок; отслежено 14 задач Redmine; замены изображений, навигация, маршрутизация форм и корректировки макетов применялись раунд за раундом Интеграция контента и правок клиента ~2 недели (параллельно) Изображения и правки текста от клиента приняты без отклонения шаблонов Сдача финальный день Сайт запущен на WP Engine, eastbrunswickperio.com, HTTP 200 подтверждён _Разработка и QA велись параллельно на всём протяжении — это характерно для доработки темы: цикл проверки агентства открывает новые пункты очереди правок по мере закрытия предыдущих. 66 календарных дней отражают пересекающиеся проходы, а не последовательные этапы._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и приведение Figma к макетам) - **Павел Сажин** — управление проектом и итерации QA - **Анна Полунина** — итерации QA, интеграция правок клиента, циклы исправлений - **Людмила Травкина** — обновление контента, корректировки навигации и форм - **Наталия Богатель** — QA и координация проекта - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, дизайн, утверждение контента и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. Запросы на доработку шли через задачи Redmine и общую очередь правок агентства; каждый раунд закрывался только после согласования с проверяющим со стороны агентства. ## Агентствам с библиотекой шаблонов > На сайте стоматологической практики с фокусом на имплантацию доработка готового шаблона требует строгого разделения клиентского кода и родительской темы. У этой практики — развёрнутые статьи о протоколах и реабилитации; у других — короткие описания профилактики. Если разделения нет, ваши доработки рассыплются при первом апдейте шаблона. ACF-схема перестанет совпадать с логикой автора — редактор сломается. Бренд-токены не дойдут до части страниц, и они вернутся к демо-оформлению. Подрядчику стоит задавать не вопрос «соберёте ли на шаблоне», а вопрос «как именно вы изолируете клиентский слой от обновлений родительской темы?» Пришлите исходник шаблона (или его ID в репозитории) и ваш фирменный стиль. Мы покажем, где ваши доработки конфликтуют с ядром темы и где их сломает следующее обновление шаблона, и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-63-urls-19-days/ title: Ребилд стоматологического сайта на WordPress (63 URL), строго по ТЗ за 19 дней type: case_study date: 2026-01-11T18:20:15+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 63 URL по 6 шаблонам, сданные строго по спецификации из таблицы. Ребилд сайта семейной стоматологической клиники в Рино включал библиотеку обучающих материалов для пациентов: её AJAX-фильтр по категориям встроенными средствами конструктора страниц собрать было нельзя. Мы написали динамический блок с нуля поверх слоя данных Elementor и сдали все 63 URL за 19 дней, в рамках сметы на 82 часа, без перерасхода. Этот кейс — описание одного такого ребилда: агентство отвечало за стратегию, мы — за реализацию. Он фиксирует и то, что часто проявляется в ребилдах такого масштаба: сотрудничество не всегда заканчивается на запуске. После сдачи сайта агентство продолжало работать с нами ещё 13 месяцев — доработки, обновление сайта и разработка шаблонного дизайна. Долгосрочное сотрудничество стало возможным именно благодаря дисциплине сборки. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — семейная и косметическая стоматология Конечный клиент White Pine Family Dental (Reno, NV) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг WP Engine Объём Полный сайт — 63 URL по 6 шаблонам: главная, о нас/команда, услуги (реставрация, профилактика, косметология), информация для пациентов, блог, контакты Сроки 19 дней (12 дек 2024 — 31 дек 2024), по графику Трудозатраты 82 часа при смете 82 часа — без перерасхода на этапе ребилда Команда 5 специалистов (62 ч разработка · 20 ч динамический контент · остальное QA и управление) Технологии WordPress · Elementor Pro · WP Engine · Rank Math · ACF · Screaming Frog · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) Проверка контента Сравнение оригинального и нового контента пройдено перед сдачей — нет пропущенного текста, битых внутренних ссылок, структурных расхождений **Результат** **ТЗ выполнено строка за строкой — 63 URL восстановлены, 6 шаблонов применены, контрольный список запуска из 49 пунктов закрыт, 65 ошибок QA устранены** Продолжение сотрудничества Доработки на протяжении 13 месяцев — динамический контент, битые ссылки, правки по дизайну, обновление сайта и разработка шаблонного дизайна — каждая дозированным спринтом в тех же отношениях с агентством **Интенсивность** 53 задачи от агентства · все закрыты к сдаче **Раунды проверки** ≈10 раундов проверки за 19 календарных дней **Контрольный список запуска** 49 пунктов, согласованы перед запуском ## Постановка задачи У агентства был постоянный клиент — стоматологическая клиника семейной и косметической стоматологии в Рино, Невада, — чей существующий сайт на WordPress требовал полного ребилда на Elementor Pro. Агентство уже выполнило стратегическую работу: таблица Google Sheets, в которой каждый текущий URL сопоставлен с новым путём, каждый meta title перенесён, полный список шаблонов и контрольный список запуска из 49 пунктов, охватывающий проверку до и после миграции. Существующая структура URL в основном сохранялась: из 63 URL только 4 требовали настройки редиректов — остальные были восстановлены на тех же слагах. Бриф агентства включал явное требование по динамическому контенту: библиотека обучающих материалов для пациентов с загрузкой постов с фильтрацией по категориям, реализованная как собственный блок HTML/CSS/JS. Встроенные инструменты контента Elementor не могли обеспечить загрузку с фильтрацией по категориям, которую требовало ТЗ — библиотеку пришлось разрабатывать вручную с помощью встроенных CSS и JavaScript, загружая контент из специальных постов через AJAX. Наша задача состояла в том, чтобы перестроить весь сайт, реализовать динамический контент и передать его готовым к запуску. Риск здесь был не в сложной миграции — структура URL была стабильной. Риск был в другом: подрядчик точно перестроит страницы, но упустит интеграцию динамического контента или сломает фильтр библиотеки обучающих материалов при переезде из тестовой среды в боевую. Канал привлечения для семейной стоматологии — локальный поиск; ребилд, который сохраняет URL, но ломает работу с контентом, всё равно роняет поисковую видимость клиники. > **Контекст рисков.** Когда ребилд сохраняет архитектуру URL, но заменяет базовый стек — те же слагы, новая сборка Elementor, новые динамические функции — режим отказа невидим при поверхностной проверке. Главная загружается, контактная форма работает, страницы услуг рендерятся. Но фильтр категорий в библиотеке обучающих материалов может не загружать правильные посты после запуска. Meta title может сдвинуться на одно слово. «Хлебные крошки» могут ссылаться на тестовый домен. Это не катастрофические отказы; это скрытое ухудшение, которое проявляется только когда пациент переходит из поисковой выдачи и видит не тот контент. Агентство хеджировало именно это: разработчик, который проверяет видимые страницы, но не динамическое поведение под ними. ## Как мы это сделали **1. Сборка на основе шаблонов.** Вместо того чтобы перестраивать 63 URL по одному, мы свели их к шести переиспользуемым шаблонам и разместили каждый URL в соответствующем шаблоне: - **Главная** — основная точка входа клиники - **О нас / Страница врача** — биографии команды и главного стоматолога - **Страница услуги** — самый тяжёлый шаблон, применён к 38 URL услуг и лечения, охватывающих реставрационную стоматологию (протезы, импланты, коронки), профилактический уход (лечение дёсен, осмотры) и косметическую стоматологию (Botox, Invisalign, отбеливание, виниры) - **Блог** — архив контента и шаблон отдельного поста - **Стандартный шаблон** — страницы информации для пациентов, юридические страницы и вспомогательный контент - **Контакты** — страница конверсии 6 шаблонов — и весь сайт сдан. Будущие правки со стороны агентства живут в одном месте на каждый тип страницы. У клиента уже был действующий сайт, поэтому проект начался со структурного выбора: собирать на тестовой копии или править черновики прямо на боевом. Мы выбрали полноценную тестовую среду на WP Engine — боевой сайт оставался нетронутым во время сборки, а запуск стал единым событием, когда все шаблоны прошли проверку. **2. ТЗ выполнено строка за строкой, из таблицы агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для перестройки с целевым путём, каждый meta title и описание для сохранения, каждое назначение шаблона и контрольный список запуска из 49 пунктов. Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где его не было — мы отметили это для агентства. Никаких «творческих интерпретаций» не было. Принцип здесь прост: при ребилде ТЗ — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. **3. Проверка на основе обхода, а не «на глаз».** До переключения DNS мы запустили Screaming Frog на действующем сайте и тестовой сборке параллельно. Коды статуса, битые ссылки, цепочки редиректов, различия в мета-тегах — каждое расхождение сверяли с ТЗ агентства. 4 строки редиректов проверили индивидуально: каждый старый путь вёл на правильный новый адрес без цепочек и коллизий. Второй обход после запуска подтвердил, что все внутренние ссылки разрешаются на рабочем домене. **4. 65 ошибок QA, все закрыты до сдачи.** Журнал ошибок агентства вёл две волны проверок: исходную очередь правок (12 из 13 закрыто) и текущую, открытую уже в период последующего сотрудничества (53 из 53 закрыто). Замечания шли от расхождений в формулировках H1 и битых ссылок в блоге до правки ширины макета и поведения мобильного слайдера. Проверка на разных устройствах — Chrome, Firefox, Safari, Edge — и на шести разрешениях (1920 / 1280 / 1024 / iPad / мобильная вертикаль / мобильная горизонталь). Работа в рамках лимита в 82 часа означала, что реализацию динамического контента нужно было решить на раннем этапе — Elementor не мог обеспечить библиотеку обучающих материалов с фильтрацией по категориям, поэтому команда написала AJAX-блок с нуля до того, как финальные страницы были в разработке. Принятие этого решения на первой неделе, а не при сдаче, позволило сохранить 19-дневный срок. ## Результаты Метрика Результат Соответствие ТЗ — URL восстановлены **63 / 63** URL восстановлены на тех же слагах, как указано в ТЗ Соответствие ТЗ — редиректы **4 / 4** редиректа реализованы как 301 Соответствие ТЗ — шаблоны **6 / 6** шаблонов разработаны и применены на всём сайте Контрольный список запуска **49 пунктов** проверены и согласованы перед запуском Очередь правок QA (исходная) **12 / 13** закрыты как Completed Очередь правок QA (текущая) **53 / 53** закрыты как Completed Динамический контент Библиотека обучающих материалов для пациентов с загрузкой постов с фильтрацией по категориям реализована и проверена Сроки (этап ребилда) **19 дней**, сдано по графику Трудозатраты (этап ребилда) **82 ч / 82 ч** смета — без перерасхода на ребилде Проверка адаптивности Ноль проблем с вёрсткой на 4 браузерах × 6 типах экранов Внутреннее QA Все пункты из очереди агентства закрыты до сдачи Сдача Сайт запущен на WP Engine в запланированный день переключения, без простоя Статус сайта, проверено 2026-04 Сайт в работе, отдаёт 200 по свежей проверке Продолжение сотрудничества Доработки на протяжении 13 месяцев — правки динамического контента, обновления дизайна, обновление сайта и разработка шаблонного дизайна — каждая дозированным спринтом в тех же отношениях с агентством Если коротко: ТЗ агентства было выполнено как написано, в рамках указанных часов, в запланированный день запуска. Отношения продолжились 13 месяцев не потому, что сборку латали постфактум, а потому что она выдержала проверку после запуска. ## Контроль качества Сравнение с оригинальным сайтом выявило две проблемы, которые поверхностная проверка пропустила бы: перепутанная буква в слаге (`/patient-information/sheduling/` вместо `/scheduling/`) и битая кнопка записи, якорь которой указывал на `#about-adress` вместо правильного раздела контактной страницы — обе найдены и исправлены до того, как агентство увидело тестовую сборку. QA перед сдачей проходило через **Site Checker** — категории и порог нулевых ошибок см. в [нашем подходе к QA](/site-checker/). Внутренний контур проверки агентства работал уже после сдачи и складывал замечания в общую очередь правок, которую мы закрывали до согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день ТЗ агентства просмотрено; 82 ч оценены и согласованы Разработка ~13 дней Весь сайт перестроен по 6 шаблонам на тестовой среде WP Engine; реализован блок динамического контента Внутреннее QA и проверка 3 дня 65 ошибок из очереди задач агентства в две волны; все закрыты Проверка ТЗ 1 день Meta и редиректы сверены с таблицей; обход подтверждён Сдача и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Этапы пересекались (QA шёл параллельно с поздней разработкой), поэтому календарный срок — 19 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта, система шаблонов и динамический контент) - **Наталия Богатель** — разработчик (footer, страница команды и обновления в рамках последующего сотрудничества) - **Павел Сажин** — QA и реализация исправлений после запуска - **Тимур Арбаев** — разработчик (разработка шаблонного дизайна и раунды доработок) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на протяжении всего запуска и миграции. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль заключалась в точности реализации переданного ТЗ. ## Агентствам, заказывающим ребилд WordPress > На стоматологическом ребилде поисковую ценность несёт инвентарь контента, а не дизайн. Одна клиника на одну точку приёма с глубокой библиотекой материалов для пациентов или сеть на несколько кабинетов с общими страницами врачей — риски по сути одни. Мета-заголовки сдвинутся без предупреждения. Фильтры контента перестанут подтягивать нужные статьи. «Хлебные крошки» и разметка сошлются на тестовую среду. Связки форм с вашей CRM отвалятся молча. Подрядчику стоит задавать не вопрос «соберёте ли страницы заново?», а вопрос «как именно вы сохраните карту мета-данных, логику фильтров и связки форм?» Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим карту мета-данных, прогоним динамические фильтры и вернём фиксированную смету в часах. Аудит за наш счёт, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-21-page-dental-38-days/ title: Доработка темы для стоматологии — 21 страница за 38 дней type: case_study date: 2026-01-04T19:36:58+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 21 страница стоматологической темы доработана по Figma агентства — 6 шаблонов применены для практики в Pensacola, которая меняла бренд прямо во время сборки. Новое название практики, новый логотип, новые цвета бренда и поздно поступившее Hero-изображение: каждый брендовый элемент мы заменили в середине сборки, по той же Figma, не трогая общую структуру шаблона. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология — общая практика Конечный клиент Coastal Cosmetic & Family Dentistry (Pensacola, Florida) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка WordPress-шаблона (фирменный шаблон агентства + дизайн по Figma для каждой страницы, на WP Engine) Объём работ **21 URL** — главная, лендинг услуг, **7 страниц услуг**, о враче, наша команда, галерея улыбок, новым пациентам, отзывы, контакты, запись на приём и вспомогательные страницы Сроки 38 дней (17 янв. – 26 февр. 2025), в срок Трудозатраты 43 часа — разработка, QA-итерации и управление проектом Команда 7 специалистов Шаблоны **6 переиспользуемых шаблонов**, предоставленных агентством, применены по всем 21 странице Технологический стек WordPress · Elementor · WP Engine · дизайн по Figma для каждой страницы · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **20 отслеживаемых задач** разобраны в очереди задач агентства по 48-пунктному контрольному списку запуска **Ритм взаимодействия** 20 задач, поставленных агентством · все закрыты к сдаче (активный период 14 дней: 04.04.2025 – 17.04.2025) **Раунды проверки** ≈5 раундов за 38 календарных дней **Контрольный список запуска** 48 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн в Figma для Coastal Cosmetic & Family Dentistry и площадку для развёртывания — свою фирменную шаблонную систему на WP Engine. Агентство уже сделало всё на своей стороне: согласовало требования с клиентом, провело аудит дизайна, настроило хостинг, подготовило контент. Нужна была команда разработки, которая точно перенесёт Figma на шаблон и будет держать QA-цикл открытым столько, сколько нужно процессу проверки агентства. В задачу была вписана дополнительная неопределённость: практика меняла бренд прямо в процессе работы. Название, состав врачей, логотип и цвета — всё изменилось, пока доработка темы уже шла. Агентство хотело избежать ситуации, когда подрядчик жёстко зашьёт старый бренд в структуру шаблона, а потом выставит счёт за переделку. При шаблонной сборке ребрендинг — это не поверхностная замена текста: он задевает каждую страницу с названием практики, каждую биографию врача, каждое размещение логотипа, каждый цветовой токен, привязанный к дизайн-системе шаблона. Тут требовалась аккуратность: брендовые элементы меняются, а шаблонный слой под ними не дестабилизируется. Ради этого агентство и нанимало нас — и именно это проверяла очередь из 20 задач на проекте. > **Контекст рисков.** Когда доработка темы идёт параллельно с активным ребрендингом — новое название практики, новый состав врачей, новый логотип, новые цветовые токены — типичный сценарий отказа: команда жёстко зашивает старый бренд в структуру шаблона, а затем выставляет счёт за обратную переделку. Агентство нанимало разработку, способную поглотить эволюцию бренда на лету: брендовые элементы заменяются без дестабилизации шаблонного слоя под ними, и ни одна итерация не оплачивается дважды. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Фирменный шаблон — базовой структурой страниц. Наша задача — согласовать их страница за страницей: где стандартная раскладка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения, мы дорабатывали. Никакие дизайн-решения не исходили от нас. Каждое расхождение мы обрабатывали индивидуально, а не перестраивали шаблон целиком под Figma, — потому что сохранение общей шаблонной структуры агентства позволяло поглотить ребрендинг без дестабилизации компонентов на будущих сайтах. **2. Ребрендинг в середине сборки — без перестройки шаблона.** В середине работы изменилось название практики, уточнился состав врачей, поступили новые брендовые активы (логотип, цвета, фотографии сотрудников) — партиями. Каждое изменение вносилось по Figma, а не как внеплановая правка. Когда Hero-изображение главной, слоган и фото врачей поступили с опозданием, они были встроены в существующую доработку без изменения общих компонентов шаблона. Сборка поглотила ребрендинг, а не была перестроена из-за него. **3. QA-цикл в масштабе доработки темы.** Качественная доработка темы — это не «собрал один раз, проверил один раз». Это «собрал, проверил, поправил, проверил, поправил». Из 23 задач на проекте **14 пришлись на проверки и правки** — отдельные раунды, где агентство отмечало расхождения с дизайном или обновления контента, мы их разбирали, правили и возвращали сборку на новую проверку. Для 21-страничного проекта с активным ребрендингом это нормальный объём итераций. Именно это отделяет шаблонный сайт, который выглядит «примерно так», от сайта, который точно совпадает с дизайном. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без отклонений.** Каждое изменение фирменного шаблона — будь то раскладка страницы, компонент секции или стилевой токен — документировалось относительно Figma. Ни одна доработка не «протекла» в общие компоненты шаблона, то есть работа над этим проектом не ухудшила шаблон для следующего сайта. **5. Проверка на разных устройствах.** Доработки мы проверяли в Chrome, Firefox, Safari и Edge на компьютере, планшете и мобильных экранах — стандартный набор точек адаптации агентства. Каждый раунд проверки покрывал страницы, затронутые расхождениями этого раунда, а не весь сайт — так шаблонная сборка остаётся быстрой и ничего не теряет в покрытии. Название практики, состав врачей, логотип и Hero-изображение — всё изменилось, пока сборка была на тестовой среде. Каждую замену мы встроили по Figma, не трогая общие компоненты шаблона: расположение Dr. Yee было перестроено, слоган обновлён до «Brighter Smiles, Beachside Comfort», брендовые токены применены повторно. Структура шаблона устояла. ## Контроль качества Проверка перед сдачей выловила лишний пробел в телефонной ссылке и убрала сторонние копирайт-футеры, зашитые в шаблон, — затем проход визуального сравнения и обход ссылок прошли все 21 страницу перед отправкой агентству. Перед сдачей проверка шла через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Собственный QA агентства работал уже после передачи и заносил замечания в общую очередь задач для нашего цикла правок, пока агентство не согласует результат. Доработки остались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не были изменены. ## Результаты Метрика Результат URL сдано **21** — 1 главная, 1 лендинг услуг, 7 страниц услуг, 1 о враче, 1 наша команда, 1 галерея улыбок, 1 новым пациентам, 1 отзывы, 1 контакты, 1 запись на приём и 5 вспомогательных страниц Шаблонов применено **6 из 6** переиспользуемых шаблонов разработаны и сопоставлены по 21 странице (главная, О нас, страница врача, страница услуги, блог, стандартный шаблон) Контрольный список запуска **48 пунктов** согласовано QA / SEO задач отслежено и закрыто **20** задач разобраны на вкладке очереди задач агентства QA-итераций в Redmine **14 из 23 задач** отслежены на уровне итераций Сроки **38 дней**, сдано в срок Трудозатраты **43 часа** — без перерасхода, без расширения объёма Команда **7 специалистов** Хостинг Запущено на шаблонном окружении WP Engine агентства Если коротко: Figma агентства мы реализовали на их фирменном шаблоне — 21 страница, 6 шаблонов, 38 календарных дней, в рамках 43-часовой оценки — включая ребрендинг в середине сборки, который доработка вписала в себя без переделки. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Figma изучена, доступ к шаблону подтверждён, объём согласован Разработка доработки ~3 недели Постраничная доработка шаблона под Figma QA-итерации (параллельно) ~2 недели 14 раундов QA и правок; каждый закрыт только после согласования с агентством Интеграция брендовых активов ~1 неделя Логотип, цвета, фото врачей и биографии сотрудников встроены в рабочую сборку Сдача финальный день Сайт запущен на WP Engine _Разработка и QA шли параллельно — это характерно для доработки темы, где «этап QA» не закрывается раз и навсегда; цикл работает непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и сопоставление Figma с раскладкой) - **Павел Сажин** — управление проектом и QA-итерации - **Анна Полунина** — QA-итерации и правки контента/раскладки - **Евгений Карпов** — поддержка разработки - **Наталия Богатель** — QA и координация проекта - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом со стороны агентства оставались у партнёра на протяжении всего проекта. Конечный клиент нас не видел: запросы на доработку шли через общую очередь задач агентства, и сборка ему не показывалась. Каждый раунд закрывался только после согласования с проверяющим со стороны агентства. ## Агентствам с библиотекой шаблонов > Вы боитесь, что клиент сменит бренд через полгода — и подрядчик зашьёт старый логотип так глубоко в шаблон, что новый не доедет до всех страниц, цвета разойдутся между компонентами, а смена названия выльется в переделку через дочернюю тему. На фирменной шаблонной системе именно это и проверяет ребрендинг на лету: насколько чисто шаблонный слой принимает новый бренд, не ломая клиентских настроек. Мы держим клиентские правки в переопределениях, а общий слой шаблона не трогаем — поэтому новый логотип и цвета встают на все страницы разом, а следующий ребрендинг не превращается в аудит всего сайта. На этом проекте бренд сменился прямо в середине сборки, и сборка приняла его без единой повторной оплаты. Пришлите исходник шаблона или его ID и спецификацию бренда. Мы найдём, где в шаблон зашиты брендовые элементы, покажем, где следующая правка бренда потребует лишней работы, и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-oral-surgery-115h-109-days/ title: 34-страничная WordPress-разработка для оральной хирургии за 109 дней type: case_study date: 2026-01-03T00:12:25+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 34 страницы WordPress-сайта оральной хирургии на 10 брендированных шаблонах, выполненных в две фазы для маркетингового агентства из США. Первый проход создал каждую страницу по карте сайта агентства; второй — фаза доработки дизайна по шаблонам — согласовал 305 уникальных пар редиректов внутренних ссылок и закрыл два списка правок QA. Весь проект на 115 часов закрылся за 109 дней без перерасхода. ## Краткий обзор Поле Значение Отрасль конечного клиента Здравоохранение — оральная хирургия и дентальные имплантаты Конечный клиент Peninsula Oral Surgery and Implants (Torrance, CA) **Формат сотрудничества** **White-label WordPress-разработка для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта WordPress-разработка с Elementor на WP Engine, с последующей фазой доработки дизайна по шаблонам Объём работ **34 URL** — главная, лендинг услуг, 15 страниц услуг, 3 страницы врачей, контакты, о нас, галерея улыбок, лендинг блога + пост, плюс 13 страниц на стандартном шаблоне Сроки 109 дней (19 мар – 5 июл 2025), выполнено по графику Трудозатраты **115 ч** при оценке в 115 ч — без перерасхода Команда 4 специалиста (34 ч разработка · 28 ч QA · 53 ч PM · распределение по обеим фазам) Шаблоны **10 многоразовых шаблонов** — стандартная библиотека стоматологических шаблонов агентства Технологический стек WordPress · Elementor · Gravity Forms · WP Engine · Rank Math · ACF · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Выполнено** **34 URL построено, 305 пар редиректов внутренних ссылок согласовано, контрольный список запуска из 29 пунктов закрыт, список правок SEO на 50 строк доведён до 44 Completed** **Ритм взаимодействия** 50 задач, поставленных агентством · все закрыты к передаче (активный период 13 дней, 2025-05-12 – 2025-05-24) **Раунды проверки** ≈9 раундов проверки за 109 календарных дней **Контрольный список запуска** 29 пунктов, согласованы перед переносом на рабочий сервер ## Постановка задачи Маркетинговое агентство из США, работающее с Peninsula Oral Surgery and Implants — клиникой оральной хирургии и дентальных имплантатов в Torrance — передало нам таблицу Google Sheets с полной картой URL, каталогом шаблонов, контрольным списком запуска и заранее заполненным списком правок. Разработка велась в существующей среде WP Engine агентства; конструктор страниц — Elementor; формы — Gravity Forms. Задача была поэтапной. Сначала — создать все 34 страницы по 10 стандартным шаблонам агентства. Затем, во второй фазе, которую агентство называет «Доработка дизайна по шаблонам» (Templated Design Development), — принять постраничные расхождения с дизайном, согласовать оставшиеся SEO-вопросы и закрыть список правок QA аккаунт-менеджера. На протяжении всего проекта оставаться вне прямого контакта с конечным клиентом, выносить неясности на уровень агентства, не принимать самостоятельно дизайнерских или SEO-решений. > **Контекст рисков.** При двухфазной разработке главная проблема агентства — не в том, можно ли построить страницы, а в том, останется ли партнёр по разработке до конца фазы согласования. Разработка создаёт новый раздел сайта, который увидят пациенты; обещание агентства клиенту держится на нём. Риск не в написании кода для 34 страниц по спецификации шаблона — он в передаче сайта, у которого вторая фаза не закрыта, и в обнаружении того, что партнёр считал завершение первого прохода финишной чертой. Бриф этого проекта был построен именно вокруг этой проблемы: две явные фазы, два списка правок QA, один бюджет в фиксированных часах, покрывающий обе. ## Как мы это сделали **1. 10 шаблонов, 34 страницы, единый процесс разработки.** Страницы Peninsula были распределены по стандартной библиотеке стоматологических шаблонов агентства: Главная, О нас, Контакты, Лендинг услуг, Страница услуги (самая трудозатратная — 15 страниц услуг, которые были структурно слишком разнообразны для единого шаблона вёрстки и требовали отдельных групп полей ACF для каждого типа процедуры), Страница врача (3 врача), Галерея улыбок, Лендинг блога, Блог и стандартный запасной шаблон, под который попали 13 вспомогательных страниц (страхование, финансирование, формы для пациентов, политики). Каждая страница строилась по назначенному шаблону из строки карты сайта; ни одна страница не создавалась вручную вне шаблонной системы. Мы использовали ACF Conditional Logic совместно с Elementor, чтобы подставлять правильную вёрстку полей для каждой процедуры внутри общего шаблона страницы услуги, не создавая отдельных шаблонов страниц для каждого типа. **2. Спецификация выполнялась строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой странице мы оценили сами и зафиксировали до старта. Дальше держались сметы строго: общий объём уложился в договорённые 115 часов на проект. Коротко: карта сайта с дизайном — это контракт. Задача команды разработки — уложиться в согласованную смету, а не пересматривать стоимость по каждой странице отдельно. **3. Согласование редиректов внутренних ссылок для 305 уникальных пар URL.** Аудит внутренних ссылок выявил сотни гиперссылок со старыми путями, встроенных в текст страниц. Мы согласовали **305 уникальных пар URL** во вкладке таблицы Google Sheets «Links-with-Redirects» — каждая пара сопоставляла путь в тестовой среде с финальной целью на рабочем сервере и проверялась по таблице редиректов. Все строки закрыты со статусом `Fixed` до передачи. **4. Два параллельных QA-цикла, закрытых до запуска.** Задачи отслеживались в двух вкладках агентства — список правок SEO (50 строк, приоритеты от Low до Urgent) и QA-обзор тестовой среды аккаунт-менеджера (29 строк, со скриншотами из тестовой среды). Из этих 79 позиций 71 была закрыта как Completed до запуска; остаток — ожидание уточнений от конечного клиента. Контрольный список запуска из 29 строк — колонки Design, Functionality, Pre-Migration, Post-Migration — был закрыт следом за обоими списками правок. Двухфазная структура — первый проход разработки с последующей доработкой дизайна по шаблонам — означала, что постраничная смета должна была выдержать обе фазы, а не только первую. Именно тот же построчный подход при обработке 305 пар редиректов и двух списков правок QA во второй фазе не позволил проекту пересмотреть стоимость в момент начала работ по согласованию. ## Результаты Метрика Итог Построено URL **34** на 10 шаблонах (1 Главная · 1 Лендинг услуг · 15 Страниц услуг · 3 Страницы врачей · 1 Контакты · 13 Вспомогательных страниц на стандартном шаблоне) Применено шаблонов **10 / 10** из стандартной стоматологической библиотеки агентства Согласовано пар редиректов внутренних ссылок **305** уникальных пар закрыты со статусом `Fixed` во вкладке Links-with-Redirects Список правок SEO **44 / 50** закрыто как Completed; 5 в QA, 1 Info-Needed Список правок QA аккаунт-менеджера **27 / 29** закрыто как Completed; 1 в QA, 1 Info-Needed Контрольный список запуска **29 пунктов** согласованы по разделам Design / Functionality / Pre-Migration / Post-Migration Сроки **109 дней** в двух фазах, выполнено по графику Трудозатраты **115 ч / оценка 115 ч** — без перерасхода, без расширения объёма **Статус сайта** Работает на WP Engine, открывается по адресу https://www.peninsulaos.com/ — проверено в апреле 2026. Если коротко: 34-URL разработка агентства запущена на 10 шаблонах в среде WP Engine в рамках договорённого бюджета 115 часов. Два списка правок QA доведены до уровня приёмки агентством, контрольный список запуска закрыт до переноса на рабочий сервер. ## Контроль качества На этой разработке QA-нагрузку определяло дублирование стоковых изображений: список правок SEO зафиксировал находку с высоким приоритетом о дубликатах изображений по всему сайту, срочную проблему со сломанной вёрсткой на странице дентальных имплантатов, отсутствующий завершающий слэш в ссылке на главную страницу и 3 страницы процедур, возвращающие нежелательные редиректы — всё это было обнаружено в тестовой среде и устранено до того, как агентство увидело разработку. QA перед передачей выполнялся через **Site Checker** — категории и порог нулевых ошибок описаны в [нашем подходе к QA](/site-checker/). Контур проверки агентства запускался после передачи и вносил оставшиеся вопросы в общую очередь правок для нашего цикла исправлений вплоть до согласования с агентством. ## Процесс Фаза Продолжительность Результат Бриф и оценка ~1 неделя таблица Google Sheets проверена, часы по строкам подтверждены, 115 ч согласованы Фаза разработки (страницы + шаблоны) ~6 недель Все 34 страницы построены по 10 шаблонам; открыты список правок SEO (50 строк) и список правок QA аккаунт-менеджера (29 строк) Доработка дизайна по шаблонам ~4 недели Постраничные расхождения с дизайном согласованы, оба списка правок QA доведены до уровня приёмки агентством Согласование ссылок + контрольный список ~1 неделя 305 редиректов внутренних ссылок закрыты; контрольный список запуска из 29 пунктов согласован Передача финальный день Сайт запущен на WP Engine _Фазы пересекаются — фаза доработки дизайна по шаблонам началась до того, как все QA-позиции фазы разработки были закрыты, поэтому календарный срок составил 109 дней, а не сумму отдельных фаз._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик на обеих фазах — разработки и доработки дизайна по шаблонам - **Павел Сажин** — итерации QA и исправления - **Никита Тумашевич** — поддержка разработки на этапе доработки и согласования ссылок - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и клиент-ориентированная коммуникация оставались за партнёрским агентством на протяжении всего проекта. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте оральной хирургии каталог процедур задаёт не только навигацию — на нём держатся URL-архитектура, граф структурированной разметки и позиции, которые вы уже выстроили в выдаче. У этой практики один хирург и узкий набор процедур; у вашего клиента это может быть многопрофильный центр с большим портфелем. Сходство обманчиво, а риски тихие. Через полгода вы добавляете новую услугу — и она не встаёт в утверждённую URL-схему. На импорте слетает структурированная разметка, и расширенные результаты пропадают из вашей панели аудита. Формы записи, подключённые чужой командой, перестают отправлять заявки — без единой ошибки на экране. Поэтому подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы построите таксономию, чтобы следующая услуга встала без перестройки URL?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим URL-план с вашими ранжированными страницами, покажем, где через полгода всё упрётся, и вернём фиксированную смету в часах. Разбор бесплатный, отвечаем за каждый пункт. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-16-page-dental-112-days/ title: Доработка стоматологического шаблона на 16 страниц за 112 дней type: case_study date: 2025-12-28T01:45:48+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 16 страниц, свёрстанных по стоматологическому шаблону агентства на основе макетов Figma от Cedar Smiles — главная страница, 2 лендинга услуг, 4 страницы услуг, страницы «О нас», биография врача и страницы конверсии пациентов (страховка, финансирование, абонемент) на 12 переиспользуемых шаблонах на Kinsta. Агентству принадлежали макеты Figma; нам — вёрстка и QA. Отклонение от стандартных настроек шаблона запускало цикл согласования — поэтому 45 из 62 отслеживаемых задач были итерациями QA, а не разработкой. ## Краткий обзор Поле Значение Отрасль клиента Медицина — общая стоматология Клиент Cedar Smiles Dental (стоматологическая клиника в США, Somerset, NJ) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + индивидуальные макеты Figma на Kinsta) Объём **16 URL** — главная, лендинг услуг, **4 страницы услуг** (профилактика, реставрация, косметология, экстренная помощь), 2 страницы «О нас», биография врача, контакты, страховка, финансирование, абонемент и 3 вспомогательные страницы (отзывы, доступность, политика конфиденциальности) Срок 112 дней (3 окт 2025 — 24 янв 2026), по графику Затраты 48 часов — разработка, итерации QA и управление проектом Команда 4 специалиста Шаблоны **12 переиспользуемых шаблонов**, предоставленных агентством, применённых на всех 16 страницах Технологии WordPress · Elementor · Kinsta · макеты Figma для каждой страницы · AutoQA агентства (проверки ссылок, email, контента AI) · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **470+ отслеженных проблем SEO + CX**, согласованных в очереди задач агентства по контрольному списку запуска из 74 пункта **Ритм взаимодействия** 3 задачи от агентства · 2 из 3 закрыты к передаче **Раунды проверки** ≈8 раундов проверки за 112 календарных дней **Контрольный список запуска** 74 пункта, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макеты Figma для Cedar Smiles Dental и среду развёртывания на своей брендированной системе шаблонов на Kinsta. Агентство уже выполнило подготовительную работу: сбор требований клиента, дизайн-аудит, настройку хостинга и подготовку контента через Google Docs для каждой страницы. Некоторые типы материалов поступили с ограничениями по формату — иконки разделов пришли в растровых форматах, которые нельзя было перекрасить под палитру шаблона, поэтому в дело пошёл набор иконок, отрисованный в Figma, — а некоторые страницы услуг в карте сайта были помечены как выходящие за рамки (услуги, которые клиент ещё не оказывал на момент разработки). Агентству нужна была команда разработки, которая точно перенесёт макеты Figma на шаблон и будет поддерживать цикл QA столько, сколько потребует процесс проверки агентства. Задача была чисто исполнительской и точной. Figma — единственный источник истины. Дорабатывать шаблон под неё страница за страницей. Фиксировать расхождения в общей очереди задач. Возвращать каждую итерацию только после того, как проверяющий со стороны агентства подтвердит, что расхождение устранено. Объём в 16 страниц был точкой входа; 112 дней и 45 раундов QA потребовалось, чтобы закрыть проект. Сайт стоматологической клиники — это не буклет. Страницы страховки, финансирования и абонемента напрямую приносят клинике пациентов и деньги. Агентству нужен был партнёр по доработке, который не отнесётся к 16-страничной разработке как к лёгкой задаче. В этом проекте четыре основные страницы услуг несли в карте сайта вложенную архитектуру подуслуг, а три вспомогательные страницы вели потоки конверсии пациентов, где неправильный логотип, неверно направленная форма или смещённый CTA становились бы вашей ответственностью после передачи. Агентство страховалось не от объёма, а от неточности. Партнёр, который бросает итерации, когда сайт выглядит «примерно правильно», оставляет агентству каждую ошибку на странице, от которой напрямую зависит приток пациентов. 45 итераций QA и более 470 отслеженных пунктов очереди задач — это и есть та тщательность, что держала риск под контролем. > **Контекст рисков.** Страницы конверсии стоматологической клиники — приём страховки, варианты финансирования, абонемент — не рекламные тексты. Они напрямую приносят пациентов, и неверно направленная форма или неправильный логотип здесь создают ответственность после передачи, которую агентство уже не отыграет назад. В такой небольшой разработке на 16 страниц нет защитного эффекта больших чисел: каждая страница весит непропорционально много, и партнёр, бросающий итерации на «примерно правильно», оставляет агентству каждую ошибку на странице, которую пациент просматривает перед записью. 45 итераций QA и более 470 отслеженных пунктов очереди задач — не накладные расходы, а та тщательность, что держала риск под контролем. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача была согласовать их страница за страницей: где стандартная раскладка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения, мы дорабатывали. Никакие дизайнерские решения не исходили от нас. Подход с копированием шаблона — дублирование брендированного шаблона агентства и его доработка под каждого клиента, а не создание каждого сайта с нуля — был устоявшейся моделью поставки агентства. Он ускорял создание страниц в рамках 16 URL, но возлагал всю ответственность за корректность на постраничную доработку: каждое отклонение от Figma, которое шаблон не поддерживал, приходилось вручную согласовывать в цикле QA, поэтому 45 из 62 отслеживаемых задач были итерациями. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрал раз, проверил раз». Это «собрал, QA, поправил, QA, поправил». Из 62 задач, отслеженных в этом проекте, **45 были итерациями QA** — отдельными раундами, где агентство отмечало расхождения с дизайном, мы проверяли, исправляли и возвращали сборку на повторную проверку. За этими раундами стояло гораздо более масштабное согласование: агентство отслеживало **более 470 пунктов в двух вкладках очереди задач** (236 находок SEO и 236 находок CX). Такой объём — не признак нестабильности; именно это отделяет сайт на шаблоне, который выглядит «примерно так», от того, что точно соответствует дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без распространения.** Каждое изменение в брендированном шаблоне — будь то раскладка страницы, компонент секции или токен стиля — мы документировали относительно Figma. Блоки логотипов страховок, секции виджета финансирования и карточки абонемента дорабатывали в рамках конкретных страниц. Ни одна доработка не распространилась на общие компоненты шаблона агентства, а значит изменения этого проекта не затронули ни один другой сайт, построенный на том же шаблоне. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями дизайна в этом раунде, а не весь сайт — так сборка на шаблоне остаётся экономной без потери покрытия. Ограничение по иконкам в формате, отличном от SVG, определило первое решение: иконки разделов поступили в растровых форматах, которые нельзя было перекрасить под палитру шаблона, поэтому вместо них использовался набор иконок, отрисованный в Figma — замена, которая должна была одинаково держаться на трёх доходных страницах (страховка, финансирование, абонемент) без расхождений в вёрстке. Благодаря этому решению 45 итераций QA ушли на точность дизайна, а не на споры о форматах. ## Контроль качества Плагин Feedback Plugin агентства зафиксировал ошибку навигации в выпадающем меню главной страницы — пункт меню отображался как «#2233 (NO TITLE)» вместо заголовка страницы — и битые ссылки на страницах «О нас» и «Наша команда»; обе проблемы были внесены в Redmine, прошли циклы исправлений и закрыты до согласования акта агентством. QA перед передачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу нулевых ошибок. Собственный QA-контур агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до момента их подписания. Доработки остались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не были изменены. ## Результаты Метрика Результат URL поставлено **16** — 1 главная, 1 лендинг услуг, 4 страницы услуг, 2 страницы «О нас», 1 биография врача, 1 контакты, 1 страховка, 1 финансирование, 1 абонемент и 3 вспомогательные страницы (отзывы, доступность, политика конфиденциальности) Шаблонов применено **12 из 12** переиспользуемых шаблонов разработано и сопоставлено по 16 страницам Контрольный список запуска **74 пункта** согласовано Проблем QA / SEO + CX отслежено **470+** пунктов согласовано в двух вкладках очереди задач агентства (236 SEO + 236 CX) Итераций QA в Redmine **45 из 62 задач (73%)** отслежено на уровне итераций Срок **112 дней**, поставлено по графику Затраты **48 часов** — без перерасхода, без расширения объёма Команда **4 специалиста** Хостинг при передаче Запущен в среде шаблонов Kinsta агентства Здоровье страниц при передаче **16 / 16** URL тестовой среды вернули HTTP 200 в аудите карты сайта Если коротко: макеты Figma агентства легли на их брендированный шаблон — 16 страниц, 12 шаблонов, 112 календарных дней, в рамках оценки в 48 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma проверена, доступ к шаблону подтверждён, объём согласован Разработка доработок ~4 недели Постраничная доработка шаблона под Figma; созданы страницы услуг и специализированные страницы Итерации QA (параллельно) ~12 недель Зафиксировано 45 раундов QA; каждый закрыт только после согласования с агентством Раунды исправлений ~1 неделя Коррекции после проверки, доработки блока страховки, обновления меню Сдача последний день Сайт запущен на Kinsta _Разработка и QA выполнялись параллельно — это характерно для доработки темы, где нет чёткого закрытия «фазы QA»; цикл работает непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (доработка темы и перенос макетов Figma в вёрстку) - **Павел Сажин** — итерации QA и исправления - **Тимур Арбаев** — поддержка разработки на поздних раундах доработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство управляло отношениями с конечным клиентом на всём протяжении проекта. Все запросы на доработку проходили через общее рабочее пространство агентства; Cedar Smiles Dental с нашей командой напрямую не работала. Каждый итерационный раунд выпускался только после того, как проверяющий со стороны агентства подтверждал соответствие изменений макетам Figma. ## Агентствам с библиотекой шаблонов > При шаблонной разработке сайта стоматологии граница между вашими доработками и кодом темы — зона ответственности агентства, которую нельзя делегировать автору. У этой клиники — взрослая практика с процедурами и записью онлайн; у других — сетевая стоматология с общим брендом и разными локациями. Если эту границу не контролировать, доработки в дочерней теме сломаются при первом обновлении шаблона. ACF-поля для фиксации страховок разойдутся с основной структурой после патча. Токены бренд-системы перестанут доходить до страниц с жёсткими цветами шаблона. Подрядчику стоит задавать не вопрос «сделаете ли сайт на этом шаблоне?», а вопрос «как именно вы переживёте следующее обновление шаблона без потери наших настроек?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы пройдёмся по дочерней теме и ACF-полям, отметим точки, где обновление шаблона сломает ваши доработки, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-veterinary-43h-32-days/ title: 28-страничная разработка ветеринарного сайта на WordPress за 32 дня type: case_study date: 2025-12-25T06:33:24+00:00 case_industry: Ветеринария case_type: Разработка case_practice: wordpress --- ## Подход к разработке 28 страниц ветеринарного сайта на WordPress — из макетов Figma и спецификации контента в Google Docs — без существующего сайта для сверки, без обхода прежней версии, с которым можно было бы сравнить. Каждый шаблон, блок контента и URL сверяли с дизайн-файлом; объём, который мы оценили построчно, уложился в 43 часа за 32 дня. ## Краткий обзор Поле Значение Отрасль конечного клиента Ветеринария — практика домашних животных Конечный клиент Stonebridge Veterinary Wellness (Roseville, CA) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor Pro на WP Engine — с нуля, без существующего сайта Объём **28 URL** — 20 завершённых страниц + 8 редиректов (главная, о нас, 4 страницы врачей, команда, блог, контакты, новым клиентам, лендинг услуг, 6 страниц услуг, отзывы, условия, конфиденциальность) Сроки 32 дня (25 марта – 26 апреля 2025), сдано в срок Затраты **43 часа** при оценке в 43 часа — без перерасхода Команда 3 специалиста (Павел Сажин — ведущий разработчик и QA; Анна Полунина — поддержка разработки; Антон Херсун — руководитель проекта) Шаблоны **9 переиспользуемых шаблонов** — Главная, О нас, Лендинг услуг, Страница услуги, Страница врача, Лендинг блога, Контакты, Стандартный шаблон, плюс один вспомогательный Стек технологий WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **28 URL в 9 шаблонах, 20 страниц ядра сайта + 8 редиректов, закрыт контрольный список запуска на 29 пунктов, обработаны очередь правок и AM QA** **Ритм работы** 20 правок от агентства · все закрыты к передаче (19 активных дней, 2025-03-30 – 2025-04-17) **Раунды проверки** ≈1 раунд проверки за 32 календарных дня **Контрольный список запуска** 29 пунктов, согласовано перед переключением ## Постановка задачи Stonebridge Veterinary Wellness — ветеринарная практика домашних животных в Roseville, California — многопрофильная, с несколькими врачами, полным спектром услуг: профилактика, хирургия, стоматология, обезболивание, неотложная помощь и транспортировка животных. Маркетинговое агентство из США, специализирующееся на сайтах для локального бизнеса, привлекло нас для создания первого сайта практики на WP Engine с использованием Elementor Pro. Ситуация с самого начала была greenfield: без существующего сайта, без готового фронтенда для референса, без базы обходных данных. Бриф агентства состоял из дизайн-файла Figma, общего Google Docs с контентом постранично и карты сайта в таблице Google Sheets на 28 URL. Объём в часах по строкам мы оценили сами. Агентство отвечало за дизайн, контент-стратегию и отношения с клиентом. Мы отвечали за разработку: настройку окружения WP Engine, создание каждого URL по назначенному шаблону, подключение Gravity Forms, настройку мета-полей Yoast по значениям из таблицы Google Sheets, а также последующие QA и доработки. Задача была прямой. Построить все 28 URL в 9 стандартных шаблонах агентства. Следовать макетам Figma и документу с контентом строка в строку. Держаться согласованной сметы — она и есть контракт. Неясности возвращать агентству; не импровизировать с дизайном или SEO. Там, где спецификация агентства умалчивала, — отметить, а не додумывать. > **Контекст рисков.** При разработке с нуля риск агентства не в том, можно ли построить страницы, — а в том, соответствуют ли построенные страницы дизайн-референсу достаточно точно, чтобы клиент увидел то, что утверждал. Без готового фронтенда для проверки каждый выбор шаблона, каждый блок контента, каждое решение по URL становится необратимым, если команда разработки не заметит отклонение до передачи. Риск — ошибка интерпретации: в Figma одни отступы, в сборщике — другие; в документе с контентом указана одна иерархия заголовков, шаблон применяет другую. Агентство искало команду, которая будет относиться к Figma как к контракту, а не как к приблизительному референсу. Документы с контентом для некоторых описаний услуг оказались длиннее, чем позволяли шаблоны, что потребовало итеративной обрезки в нескольких раундах проверки с клиентом, прежде чем страницы сохранили свою дизайн-структуру. ## Как мы это сделали **1. 9 шаблонов, 28 URL, один процесс разработки.** Страницы Stonebridge распределились по стандартной библиотеке шаблонов локального бизнеса агентства: Главная, О нас, Лендинг услуг, Страница услуги (применена 6 раз — стоматология животных, транспортировка, профилактика, хирургия, обезболивание, неотложная помощь), Страница врача (4 врача), Лендинг блога, Контакты и Стандартный шаблон, который охватил 6 вспомогательных страниц (новым клиентам, отзывы, условия, конфиденциальность и 2 служебных). Каждую страницу строили по назначенному шаблону из строки карты сайта; ни одной страницы не создавали вручную вне системы шаблонов. **2. Спецификация выполнена строка в строку, в рамках согласованной сметы.** Объём в часах по каждой строке карты сайта мы оценили сами и зафиксировали до старта — 14,7 часов на основную разработку, остальное на управление, QA и доработки. Уложились в согласованный бюджет 43 часа. Коротко: при разработке с заранее оценённой картой сайта таблица — это контракт. Задача команды разработки — уложиться в согласованную смету, а не пересматривать цену страница за страницей. **3. Пути редиректов подготовлены для будущего расширения.** В карте сайта были предусмотрены восемь путей редиректов — устаревшие URL и альтернативные пути, которые агентство планировало обработать после запуска. Мы сопоставили каждый в колонке редиректов таблицы Google Sheets, подтвердили чистые ответы 404 на тестовой среде (где не существовало исходного адреса) и оставили таблицу редиректов готовой к DNS-переключению агентства. Мы выбрали подготовку редиректов на этапе разработки, а не сопоставление постфактум после запуска, чтобы таблица была чистой к моменту запуска домена. **4. Два параллельных контура QA, закрытых до передачи.** Задачи отслеживались в двух вкладках агентства — очередь правок (20 строк, 18 завершено, 2 к выполнению) и AM QA тестовой среды (50 строк, 31 завершено, 18 на проверке, 1 к выполнению). Контрольный список запуска на 29 пунктов — Дизайн, Функциональность, Этап до миграции и Домен — закрыли после обработки обеих очередей. Спецификация контента превысила возможности шаблона страницы услуг: несколько описаний оказались настолько длинными, что для их размещения пришлось подрезать текст в нескольких раундах проверки с клиентом, прежде чем страницы сохранили свою вёрстку. Мы заложили это ограничение в порядок работ, а не оставили на потом, как замечание QA, — и две параллельные очереди не накопились к моменту передачи. ## Результаты Метрика Результат Построено URL **20** завершённых страниц в 9 шаблонах + **8** редиректов Применено шаблонов **9 / 9** из стандартной библиотеки локального бизнеса агентства Очередь правок **18 / 20** завершено; 2 к выполнению Очередь AM QA **31 / 50** завершено; 18 на проверке, 1 к выполнению Контрольный список запуска **29 пунктов** по разделам Дизайн / Функциональность / Этап до миграции / Домен Сроки **32 дня** (разработка + QA + доработки), сдано в срок Затраты **43 ч / 43 ч по оценке** — без перерасхода, без расширения объёма **Статус сайта** Сайт запущен на WP Engine: https://stonebridgevetwellness.com/ — проверено апрель 2026. Если коротко: 28-URL разработка с нуля сдана в 9 шаблонах на WP Engine, в рамках бюджета в 43 часа. Два контура QA отработаны до уровня, приемлемого для агентства, и контрольный список запуска закрыт до передачи. ## Контроль качества QA-проверка AM на тестовой среде выявила две нерабочие ссылки: заглушку «Directions» в подвале и контактной боковой панели, которая вела в никуда (элемент-заглушка из Figma, так и не привязанный к рабочему URL), и якорь «Contact» на странице с биографией врача, который не вызывал навигацию. Оба отметили в очереди правок в таблице и исправили до передачи. QA перед передачей проводили через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Контроль на стороне агентства шёл после передачи и фиксировал замечания в общей очереди для нашего цикла исправлений, пока агентство не подписывало приёмку. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Таблица Google Sheets проанализирована, построчные часы подтверждены, Figma и документы с контентом изучены, согласовано 43 ч Разработка (страницы + шаблоны) ~12 дней Все 28 URL построены в 9 шаблонах на WP Engine на тестовой среде AM QA + очередь правок ~14 дней Два параллельных контура QA отработаны; контрольный список на 29 пунктов продвинут Доработки + финальная сдача ~3 дня Оставшиеся задачи решены; сайт сдан на тестовую среду агентства _Этапы перекрываются — контур AM QA начался до закрытия всех задач этапа разработки, поэтому календарный срок составляет 32 дня, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Павел Сажин** — ведущий разработчик и QA (разработка, реализация шаблонов, обработка очереди правок) - **Анна Полунина** — поддержка разработки и интеграция контента - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На разработке с нуля вы несёте главный риск: готовый сайт не совпадёт с дизайн-референсом — а клиент впервые видит его уже на передаче. У клиники с одним адресом и фиксированным набором услуг контент должен лечь в вёрстку точно. У сети с несколькими адресами и переменными описаниями тот же набор шаблонов должен растягиваться без переполнения. Если этого не контролировать, длинный текст ломает вёрстку, отступы и иерархия плывут от раунда к раунду, а сданный сайт тихо расходится с тем, что клиент утвердил. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы удержите дизайн в сборке, чтобы клиент увидел ровно то, что утверждал?» Пришлите рабочую таблицу сборки, черновик карты сайта или дизайн-файлы. Мы сверим перечень контента с вашим планом шаблонов, покажем, где рамки вёрстки переполнятся или отступы поплывут, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-oral-surgery-35h-58-days/ title: 63-страничный сайт челюстно-лицевой хирургии на WordPress за 58 дней type: case_study date: 2025-12-18T17:06:54+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 63-страничный сайт челюстно-лицевой хирургии, таксономия процедур глубиной в три уровня, переданный команде разработки вместе с таблицей Google Sheets на 70 строк и шестью секционными редиректами. Предпусковой список агентства выявил расхождения мета-тегов на глубине подпроцедур и ошибки 404 на хирургических страницах, на которые ведут ссылки направляющих врачей. Команда разработки должна была закрыть эти вопросы до переключения DNS — а не отправить их в очередь правок агентства уже после запуска. ## Краткий обзор Параметр Значение Сфера клиента Медицина — челюстно-лицевая хирургия Клиент St. Augustine Oral & Facial Surgical Center (St. Augustine, FL) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor на WP Engine, одноэтапная с предпусковой сверкой Объём **63 завершённых URL** — главная, хаб процедур + 33 страницы процедур и подпроцедур, хаб информации для пациентов + 8 страниц, хаб хирургических инструкций + 6 страниц, раздел косметических процедур лица + 9 страниц, раздел «О нас» + 2 страницы, контакты, дисклеймер Сроки 58 дней (25 янв – 24 мар 2025), выполнено в срок Затраты **35 часов** при оценке 35 часов — без перерасхода Команда 3 специалиста (Никита Тумашевич · Людмила Травкина · Евгений Карпов + Антон Херсун, руководитель проекта) Шаблоны **1 основа шаблонов** — Original Design, применён общесайтово к существующей структуре Технологии WordPress · Elementor · Gravity Forms · WP Engine · Rank Math · Header Footer Code Manager · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **63 URL построены, 6 пар внутренних редиректов реализованы, контрольный список запуска на 49 пунктов закрыт, предпусковые замечания закрыты до передачи** **Ритм взаимодействия** 2 задачи от агентства · все закрыты к моменту передачи (1 день активного периода, 03.04.2025 – 03.04.2025) **Раунды проверки** ≈2 раунда за 58 дней **Контрольный список запуска** 49 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое St. Augustine Oral & Facial Surgical Center — флоридской практикой, предлагающей челюстно-лицевую хирургию, дентальную имплантацию, костную пластику, хирургию челюсти и косметические процедуры лица — передало нам таблицу Google Sheets с картой URL на 70 строк, флагами секционных редиректов, контрольным списком запуска и Elementor, установленным на тестовой среде WP Engine. Вкладка Template таблицы Google Sheets содержала единственный источник шаблона — Original Design — указывая на то, что разработка была достоверной реконструкцией существующей структуры сайта, а не созданием с чистого листа. Плагином форм был Gravity Forms; SEO-плагином — Rank Math (агентство подтвердило активную лицензию в ходе предпусковой фазы). Задача: достоверно воссоздать все 63 страницы по существующему набору URL floridafacedoc.com, реализовать шесть секционных редиректов, которые ведут корни разделов на первую дочернюю страницу с контентом (например `/contact-us/` → `/contact-us/contact-information-office-map/`, `/surgical-instructions/` → `/surgical-instructions/before-anesthesia/`), и закрыть предпусковой список до согласования агентством переключения DNS. Дизайн, контент, SEO-стратегия и общение с клиентом оставались за агентством на всём протяжении. > **Контекст рисков.** Набор URL сайта челюстно-лицевой хирургии необычно глубок. Только таксономия процедур насчитывает три уровня: `/procedures/` → `/procedures/dental-implants/` → `/procedures/dental-implants/teeth-in-an-hour/`. Предпусковой список, который выявляет расхождения мета-тегов на уровне подпроцедур, — не мелкое неудобство. Это сигнал агентства: отдельные URL хирургических процедур, на которые регулярно ссылаются направляющие врачи из других клиник, должны совпасть со спецификацией опубликованного сайта до того, как на новую сборку придёт хоть один посетитель. Риск, от которого агентство страховалось, такой: команда соберёт структуру страниц точно, но оставит мета-слой и редиректы на потом, уже после запуска. Тогда проверка агентства превращается в аврал вместо спокойной финальной сверки. Таблица Google Sheets отслеживала 70 URL на уровне страниц, но мета-слой подпроцедур — отдельные страницы хирургических инструкций и подпроцедур — с опубликованным сайтом автоматически не сверялся. Предпусковой список (Redmine #222) поймал эти расхождения до переключения и закрыл пробел, который первый проход сборки по одной карте сайта обнаружить не мог. ## Как мы это сделали **1. 1 источник шаблона, 63 страницы, общесайтовая структурная точность.** Сайт St. Augustine Oral & Facial Surgical Center состоит из 6 разделов верхнего уровня, каждый со своей страницей-хабом и подстраницами: Процедуры (34 URL, охватывающие хирургические импланты, костную пластику, зубы мудрости, хирургию челюсти, расстройства ВНЧС, апноэ сна, ретенированные клыки, плазму, обогащённую тромбоцитами, и лицевую травму), Информация для пациентов (9 URL, охватывающие регистрацию, страховку, первый визит, финансовую политику, видео и конфиденциальность), Хирургические инструкции (7 URL, охватывающие подготовку к анестезии, удаление, имплантацию и обнажение ретенированного зуба), Косметические процедуры лица (10 URL, охватывающие подтяжку лица, ринопластику, гениопластику, подтяжку бровей, блефаропластику, Botox и 4 подстраницы косметических наполнителей), и О нас (2 URL для биографии врача и страницы персонала), плюс главная, контакты и дисклеймер. Все 63 завершённых URL мы построили на шаблоне Original Design и привели в соответствие со структурой опубликованного сайта. **2. Спецификация выполнена строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта — суммарно 35 часов. Дальше держались сметы строго: итог уложился в неё. Коротко: карта сайта с дизайном — это контракт. Задача команды разработчиков — уложиться в согласованную смету, а не открывать обсуждение цены страница за страницей. **3. Шесть пар секционных редиректов, все сопоставлены до запуска.** Таблица Google Sheets отметила шесть путей разделов для 301 редиректа: родительские страницы-хабы для контактов, информации о пациентах, о нас, хирургических инструкций, лицевых процедур и косметических наполнителей — каждая перенаправляет на свою первую дочернюю страницу с контентом. Это пути, которые пациенты и направляющие врачи чаще всего сохраняют в закладках на корне раздела. Все шесть пар реализовали в тестовой среде и сверили по таблице редиректов ещё до открытия предпускового списка. Отдельной вкладки редиректов в таблице Google Sheets не было — правила записали прямо в колонке Action карты сайта, с комментариями к целевым страницам. Так каждое решение по маршрутизации оставалось в одной строке с исходным путём, а не уезжало на второй лист, который легко расходится с картой сайта. **4. Предпусковой список проработан до согласования агентством.** Вторая задача Redmine — Pre Launch (#222) — вскрыла расхождения мета-тегов между тестовой средой и опубликованным сайтом на подстраницах хирургических процедур, ошибки 404 на 2 процедурных страницах (ретенированные клыки, ретенированные зубы мудрости), пропавшую ссылку на кнопке регистрации пациента на главной и неверные видео-вставки на 2 страницах процедур, которые открывали чужую форму согласия. Rank Math установили и настроили в ходе этого прохода. Каждый пункт предпускового списка закрыли до того, как агентство передало сайт на переключение DNS. Контрольный список запуска — колонки Дизайн, Функциональность, До миграции, После миграции — закрыли следом за предпусковым проходом. Предпусковой список (Redmine #222) вскрыл пробелы, которые по одной карте сайта предсказать нельзя: расхождения мета на глубине подпроцедур, ошибки 404 на двух хирургических страницах и сбои видео-вставок, заметные только при сверке тестовой среды с опубликованным сайтом. Все пять категорий закрыли до переключения DNS — и проверка на стороне агентства стала спокойной финальной сверкой, а не авралом. ## Контроль качества Предпусковой список агентства (Redmine #222) вскрыл 5 категорий замечаний до переключения DNS: расхождения мета на глубине подпроцедур (`/procedures/wisdom-teeth/impacted-wisdom-teeth/`), ошибки 404 на 2 хирургических страницах, пропавшую ссылку на кнопке регистрации пациента, неустановленный Rank Math и неверные видео-вставки на 2 страницах процедур — всё закрыли через полный цикл «проверили → отдали → согласовали». До сдачи мы прогоняли проверку через **Site Checker** — категории и порог нулевых ошибок описаны в [нашем подходе к QA](/site-checker/). Своя проверка агентства шла уже после передачи и складывала замечания в общую очередь правок, которую мы закрывали до финального согласования. ## Результаты Метрика Результат Разработано URL **63** по шести разделам: Процедуры (34 · хаб + подпроцедуры) · Информация для пациентов (9) · Хирургические инструкции (7) · Косметические процедуры лица (10) · О нас (2) · Основные страницы (главная, контакты, дисклеймер) Применено шаблонов **1 / 1** — Original Design, применён общесайтово Реализовано пар секционных редиректов **6** — пути разделов сведены в первые дочерние подстраницы в разделах Контакты, Информация о пациентах, О нас, Хирургические инструкции, Лицевые процедуры и Косметические наполнители Предпусковой список проблем Все несоответствия мета-тегов, ошибки 404, битые кнопки и несоответствия видео-вставок решены до DNS-переключения Контрольный список запуска **49 пунктов** согласованы по категориям Дизайн / Функциональность / До миграции / После миграции Сроки **58 дней** (25 янв – 24 мар 2025), выполнено в срок Затраты **35 ч / оценка 35 ч** — без перерасхода, без расширения объёма **Статус сайта** Работает на WP Engine, открывается по адресу https://www.floridafacedoc.com/ — проверено в апреле 2026. Если коротко: сайт челюстно-лицевой хирургии на 63 URL для агентства мы сдали в бюджете 35 часов — с шестью реализованными секционными редиректами и всеми предпусковыми вопросами, закрытыми до того, как агентство передало сайт на переключение DNS. ## Процесс Этап Длительность Результат Бриф и оценка ~1 день таблица Google Sheets проверена, построчные часы подтверждены, оценка 35 ч согласована Разработка (страницы + шаблоны) ~3 недели Все 63 URL построены по структуре Original Design на тестовой среде WP Engine; Elementor и Gravity Forms установлены и настроены Предпусковая сверка ~2 недели Проход по мета-тегам всех подстраниц процедур, исправление 404, реализация пар редиректов, установка Rank Math, коррекция видео-вставок Контрольный список запуска + сдача ~1 неделя Контрольный список на 49 пунктов согласован; сайт передан на DNS-переключение; сайт выведен в работу _Этапы перекрываются — реализация редиректов и предпусковой мета-проход шли параллельно с финальными строками сборки, поэтому календарный срок в 58 дней короче, чем предполагает последовательное чтение списка этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик, этапы разработки и предпусковой сверки - **Людмила Травкина** — поддержка разработки, сборка страниц и миграция контента - **Евгений Карпов** — QA, проверка ссылок и тестовой среды - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и общение с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > Новая сборка для клиники челюстно-лицевой хирургии закладывает URL-каркас на три уровня вложенности — от него зависит metadata, индексация, ссылки направляющих врачей. У этой практики — сложные многоэтапные операции и реабилитация; у других — амбулаторная стоматология и диагностика. Риски тихие: таксономия зафиксируется на старте, и новая процедура на шестом месяце не впишется в архитектуру; цепочка редиректов потеряет строки; мета-слой разойдётся с рабочим сайтом, и вы узнаете об этом от клиента, а не от подрядчика. Вам стоит спрашивать подрядчика не «соберёте ли страницы?», а «как именно вы выстроите таксономию, чтобы мета-слой и редиректы не повисли в очереди задач?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы пройдёмся по вашей карте и мета-плану, отметим, где таксономия будет спорить с архитектурой на шестом месяце, и вернём фиксированную смету в часах. Аудит — бесплатно. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-44-page-dental-40-days/ title: Доработка стоматологического шаблона на 44 страницы за 40 дней type: case_study date: 2025-12-16T05:39:31+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 44 страницы стоматологической практики, свёрстанные на 10-шаблонной системе Figma — 25 страниц услуг, лендинг услуг, биография врача и Smile Gallery, отложенная до готовности контента — всё в рамках оценки в 22 часа. Агентство передало Figma как контракт; мы отвечали за постраничную реализацию и QA: 290+ отслеживаемых пунктов SEO и CX согласованы в таблице агентства до утверждения на переключении. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Индустрия конечного клиента Стоматология — общая Конечный клиент Irmo Dentistry (Irmo, SC) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **44 URL** — 1 главная, 1 лендинг услуг, **25 страниц услуг**, 1 биография врача, 1 о нас + 4 подстраницы, 1 лендинг блога, 1 контакты, 1 smile gallery (скрыта) и 7 вспомогательных страниц Сроки 40 дней (6 авг – 15 сен 2025), в срок Трудозатраты 22 часа — разработка, QA-итерации и управление проектом Команда 4 специалиста Шаблоны **10 переиспользуемых шаблонов**, предоставленных агентством, все применены на 44 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **290+ отслеживаемых пунктов QA** согласованы по двум вкладкам очереди правок агентства (105 SEO + 186 CX) и 30-пунктному контрольному списку запуска **Ритм работы** 104 задачи от агентства — все закрыты к моменту сдачи (активный период 20 дней, 2025-08-14 – 2025-09-02) **Раунды проверки** ≈3 раунда проверки за 40 календарных дней **Контрольный список запуска** 30 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн Figma для Irmo Dentistry и площадку для развёртывания в своей брендированной системе шаблонов на Kinsta. Агентство уже сделало подготовительную работу: аудит дизайна, одобрение клиента, настройка хостинга, контент-план. Нужна была команда разработки, которая точно приведёт Figma к шаблону — через столько итераций, сколько потребует дизайн. Задача была чисто исполнительская. Figma — единственный источник истины. Доработать шаблон под неё страница за страницей, разрешение за разрешением. Замечания QA возвращать агентству в общем пространстве задач; не закрывать без его согласования. Агентство хотело исключить подрядчика, который отнёсся бы к переносу 44 страниц как к массовому копированию. У практики уже был действующий сайт со сложившейся структурой URL для пациентов; переход на брендированную систему шаблонов агентства означал сохранение каждого URL, скрытие незавершённых страниц и строгий QA по 290+ отслеживаемым пунктам — всё в рамках бюджета в 22 часа. > **Контекст рисков.** У практики уже был действующий сайт со сложившейся структурой URL для пациентов. Переход на брендированную систему шаблонов агентства означал перенос 44 существующих URL — каждый с реальным трафиком и историей в поисковом индексе — на новую структуру шаблонов без потери страниц, поломки slug или утечки незавершённого контента. При бюджете всего в 22 часа риск был не только в самом переносе, но и в том, чтобы удержать строгий QA при минимальных часах: каждый URL нужно было сохранить, Smile Gallery придержать до готовности контента, а 291 отслеживаемый пункт по SEO и CX согласовать до сдачи. Несколько разделов, зависимых от контента — страница биографий команды врачей, отзывы пациентов и Smile Gallery — вышли с плейсхолдерами или были явно скрыты при запуске: клиент не успел собрать материалы к срокам разработки. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача была согласовать их страница за страницей — где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовала отклонения, мы дорабатывали. Никаких дизайнерских решений с нашей стороны мы не принимали. Мы выбрали подход «шаблонные умолчания в первую очередь» вместо постраничной индивидуальной разработки, потому что бюджет в 22 часа не позволял индивидуальный дизайн на каждом URL — доработку зарезервировали для страниц, где Figma явно расходилась со структурой шаблона. **2. QA-цикл в масштабе доработки темы.** Чистая доработка шаблона — это не «собрать один раз, проверить один раз». Это «собрать, QA, поправить, QA, поправить». Агентство отследило **290+ пунктов в двух вкладках очереди правок** (105 SEO-замечаний и 186 CX-замечаний), и большинство из них были закрыты через общий цикл исправлений до сдачи. Такой объём — не признак нестабильности; именно он отделяет шаблонный сайт, который выглядит «примерно правильно», от сайта, который точно соответствует дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без дрейфа.** На протяжении проекта каждое изменение в брендированном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Ни одна правка не ушла в общие компоненты шаблона, а значит, работа по этому проекту не испортила шаблон для следующего сайта, который будет его использовать. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на больших экранах, планшетах и мобильных устройствах — стандартный набор разрешений агентства. Каждый QA-раунд охватывал страницы, затронутые дизайнерскими изменениями этого раунда, а не весь сайт — так работа с шаблоном остаётся быстрой без потери покрытия. 44 URL за 40 дней, причём с 8-го дня агентство попросило работать в приоритете реального времени. Уложиться в оценку 22 часа означало применять шаблонные умолчания везде, где Figma явно не требовала отклонения, — усилия по доработке резервировались для страниц, где дизайн расходился, а не распределялись равномерно. Именно это позволило удержать QA-цикл на 3 раундах вместо обычных 15. ## Контроль качества Внутреннее QA в процессе разработки выявило две проблемы до сдачи на тестовую среду: несогласованность структуры URL (у половины URL карты сайта отсутствовали завершающие слеши — отмечено в чате, «Со слешем все делаем», и весь список из 44 URL был исправлен) и ошибка с языком контента на странице биографии врача (неправильные местоимения из плейсхолдера шаблона, обнаружены по CX-очереди правок, строка 83, и исправлены до сдачи). QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) с категориями и порогом нулевых ошибок. Свой контроль на стороне агентства выполнялся после сдачи и выводил замечания в общую очередь правок для нашего цикла исправлений до окончательного согласования. Доработки оставались в слое клиентских переопределений; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **44** — 1 главная, 1 лендинг услуг, 25 страниц услуг, 1 биография врача, 1 о нас + 4 подстраницы, 1 лендинг блога, 1 контакты, 1 smile gallery (скрыта) и 7 вспомогательных страниц Шаблонов применено **10 из 10** переиспользуемых шаблонов построены и сопоставлены с 44 страницами (Homepage, About Us, Blog Lander, Blog, Doctor Page, Services Lander, Service Page, Default Template, Contact Us, Smile Gallery) Контрольный список запуска **30 пунктов** согласованы SEO / CX задач отслежено и решено **290+** пунктов согласованы по двум вкладкам очереди правок агентства (105 SEO + 186 CX) Сроки **40 дней**, сдано в срок Трудозатраты **22 часа** при оценке 22 часа — никакого перерасхода, никакого расползания объёма Команда **4 специалиста** Сдача хостинга Опубликован в шаблонной среде Kinsta агентства Здоровье страниц при сдаче **43 / 43** активных URL тестовой среды возвращали HTTP 200 в аудите карты сайта; 1 страница явно скрыта Если коротко: Figma агентства была реализована на их брендированном шаблоне на 44 страницах и 10 шаблонах, за 40 календарных дней, в рамках оценки в 22 часа. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Figma проверена, доступ к шаблону подтверждён, объём согласован Разработка доработки ~3 недели Постраничная доработка шаблона под Figma; URL существующего сайта перенесены QA-итерации (текущие) ~3 недели Пункты очереди правок агентства согласованы; каждый закрыт только после согласования агентством Раунды исправлений ~1 неделя Постпроверочные коррекции и настройка скрытых страниц Сдача финальный день Сайт запущен на Kinsta _Разработка и QA выполнялись параллельно — это характерно для работы по доработке темы, где ни один «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и приведение Figma к макетам) - **Павел Сажин** — QA-итерации и согласование очереди правок - **Анна Полунина** — поддержка разработчика в раундах доработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел: все запросы на доработку шли через общую очередь правок агентства, и сама разработка ему напрямую не показывалась. Каждый QA-раунд закрывался только после того, как проверяющий со стороны агентства подтверждал, что расхождение устранено. ## Агентствам с библиотекой шаблонов > Граница между общим слоем и клиентским — то, на чём брендированная система шаблонов живёт или ломается. Эта практика — стоматология в одной точке, заезжающая в шаблон; у других это сеть клиник с общим брендом. Без строгого QA клиентские доработки затрёт при следующем обновлении шаблона. Пробелы в контенте выпустят на боевой домен страницы-плейсхолдеры. Брендовые токены перестанут передаваться, как только клиент впервые поправит цвет. Прежде чем подписываться, спрашивайте не «соберёте ли страницу?», а «как вы изолируете клиентские доработки, чтобы они пережили обновления шаблона?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы сопоставим точки клиентской доработки со схемой шаблона, отметим, где брендовые токены могут поплыть, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-57h-130-days/ title: 76-страничный сайт для семейной стоматологии на WordPress за 130 дней type: case_study date: 2025-12-08T06:21:27+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 76 страниц нового сайта на Elementor для семейной стоматологической практики в Мэриленде, собранных по 96-строчному экспорту Screaming Frog — оригинальный сайт был доступен только через VPN, поэтому экспорт стал эталоном соответствия контента для каждой страницы. Агентство вело два параллельных направления QA и 49-пунктный контрольный список запуска. Всё закрыли до публикации сайта на WP Engine. 96-строчный экспорт оригинала задавал направление с первой задачи. Структура из двух очередей правок QA — отдельная очередь по SEO и очередь аккаунт-менеджера — гарантировала, что и технические требования агентства, и его планка качества перед клиентом закрыты до запуска сайта. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина (Стоматология — семейная и общая) Конечный клиент David Eskow, DDS Family Dentistry (Olney, MD) **Формат сотрудничества** **White-label разработка на WordPress для американского маркетингового агентства, специализирующегося на сайтах для локального бизнеса** Тип проекта Новый сайт на WordPress с Elementor на WP Engine, с эталонным экспортом оригинального сайта и QA по двум очередям Объём **76 URL** — главная, о нас, контакты, 4 лендинга услуг, 24 страницы услуг, 11 страниц профилей сотрудников, блог-лендинг, 17 постов блога, 7 страниц категорий блога, 9 стандартных шаблонных страниц Сроки 130 дней (25 фев – 5 июл 2025), сдано в срок Затраты **56,5 часов** при оценке 57 ч — без перерасхода Команда 5 специалистов (41 ч разработка · 7 ч контент и исправления · 9 ч PM · 0 ч отдельный QA — QA включён в задачи разработки и исправлений) Шаблоны **10 повторно используемых шаблонов** — стандартная стоматологическая библиотека агентства: About Us, Blog, Blog Category, Blog Lander, Contact Us, Default Template, Doctor Page, Homepage, Service Page, Services Lander Технологии WordPress · Elementor · Gravity Forms · WP Engine · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) **Результат** **76 URL собраны по 10 шаблонам, очередь правок SEO: 14/14 закрыты, очередь аккаунт-менеджера: 14/14 закрыты, 49-строчный контрольный список запуска согласован** **Ритм взаимодействия** 14 правок от агентства · все закрыты к сдаче (36 дней активной работы, 2025-05-05 – 2025-06-09) **Раунды проверки** ≈5 раундов за 130-дневное окно **Контрольный список запуска** 49 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое David Eskow, DDS — солидной семейной стоматологической практикой в Olney, MD, предлагающей косметические, профилактические, восстановительные и специализированные услуги — передало нам таблицу Google Sheets с полной картой URL, экспорт Screaming Frog оригинального сайта как эталонную вкладку, каталог шаблонов, контрольный список запуска и предварительно заполненные очереди задач QA. Сайт собирали в их среде WP Engine; конструктор страниц — Elementor; формы — через Gravity Forms. Таблица Google Sheets включала 8 вкладок, в том числе отдельную вкладку с экспортом оригинального сайта (SF) — 96-строчный экспорт Screaming Frog с H1, метаданными и структурными сигналами для каждой страницы существующего сайта. Вкладка экспорта стала прагматичной заменой прямого доступа: оригинальный сайт во время работы был закрыт по региону, поэтому команда опиралась не на браузер, а на этот экспорт как на главный источник точности контента на уровне страниц. Задача: собрать 76 URL по 10 стандартным шаблонам, сверяя каждую страницу с экспортом Screaming Frog как с эталоном контента, заполнить 11 профилей сотрудников материалами от агентства, перенести 17 постов блога на новую структуру шаблонов, добавить присланные агентством обновления на страницах услуг и отработать две отдельные очереди QA — очередь по SEO и очередь аккаунт-менеджера — до приёмки сайта агентством. На всём протяжении не выходить на прямой контакт с конечным клиентом; возвращать неясные вопросы агентству; не импровизировать с контентом, фотографиями или навигационными решениями. > **Контекст рисков.** Когда семейная стоматологическая практика пересобирает сайт на том же домене с той же структурой URL, риски тоньше, чем при миграции: карты редиректов нет, но есть эталон контента, которому нужно соответствовать. Вложения агентства в QA зависят от точности воссоздания оригинальных страниц — верный H1, верные meta description, верный текст страниц услуг, верные списки сотрудников. Сайт, который прошёл визуальную проверку, но незаметно отошёл от эталона Screaming Frog, требует той же доработки, что и сайт с пропущенными страницами. Две параллельные очереди QA — одна по SEO, другая по клиентской проверке аккаунт-менеджером — закрывают оба критерия точности раньше, чем контрольный список. ## Как мы это сделали **1. 10 шаблонов, 76 страниц, один процесс сборки.** Страницы David Eskow охватывали всю стоматологическую библиотеку шаблонов агентства: Homepage, About Us, Contact Us, Services Lander (4 страницы — косметическая, профилактическая, восстановительная и специализированная стоматология), Service Page (24 отдельных страницы услуг), Doctor Page (11 страниц профилей сотрудников — врачи, гигиенисты и вспомогательный персонал), Blog Lander, Blog (17 постов), Blog Category (7 страниц категорий) и Default Template (9 вспомогательных страниц — ресурсы для пациентов, страховка, варианты оплаты, политика конфиденциальности). Каждая страница строилась на назначенном шаблоне из строки карты сайта; ни одна страница не создавалась вручную вне системы шаблонов. **2. ТЗ соблюдено строка за строкой — с экспортом оригинала как эталоном контента.** Объём в часах мы оценили сами — основная сборка плюс управление проектом и раунды контента и исправлений — и зафиксировали до старта. Карту сайта дало агентство; та же таблица включала вкладку с экспортом оригинала — 96-строчный экспорт Screaming Frog — с H1 и метаданными для каждой индексируемой страницы существующего сайта. Эта вкладка стала целевым эталоном: H1 и meta description каждой пересобранной страницы должны были совпадать с экспортом, если агентство не меняло их явно. Мы привязывали каждую страницу к данным экспорта, а не опирались только на описания из таблицы — потому что на сборке в том же домене без миграции URL главный риск тут такой: расхождение контента выглядит корректно при визуальной проверке, но всплывает недели спустя во время сверки QA на стороне агентства. Коротко: на сборке в том же домене эталон экспорта так же обязателен, как и оценка часов. Команда, которая собирает страницы, но игнорирует экспорт, выдаёт сайт, который выглядит правильно, но не проходит QA агентства по точности контента. **3. Корпус профилей сотрудников — 11 страниц на материалах агентства.** Шаблон Doctor Page оказался самой объёмной частью раздела команды: 11 профилей — врачи, гигиенисты, сертифицированные ассистенты стоматолога и менеджер практики. Под каждый профиль агентство давало собственный материал. В середине работы поступили новые фотографии клиента; их добавили на опубликованный сайт отдельной задачей по обновлению, и из-за этого после первого прохода QA пришлось вернуться к главной странице и нескольким профилям. **4. Обновления контента и правки на тестовой среде — без срыва сроков.** Две отдельные задачи по контенту пришли в середине работы: раунд обновления текстов на страницах услуг по таблице сверки Screaming Frog, собранной агентством, и раунд правок на тестовой среде — мелкие текстовые корректировки и исправления вёрстки. Обе провели как отдельные задачи Redmine с учётом часов, параллельно с очередями QA. Раунд срочных исправлений после запуска, отмеченных клиентом, тоже отработали и закрыли до того, как закрылась очередь аккаунт-менеджера. **5. QA по двум очередям — обе закрыты до сдачи.** Задачи вели в двух отдельных вкладках на стороне агентства: очередь по SEO (14 строк, все закрыты до сдачи) и очередь аккаунт-менеджера (14 строк, все закрыты до сдачи). 49-строчный контрольный список запуска — колонки «Дизайн» (совместимость браузеров, фавикон, изображения и видео), «Функциональность» (битые ссылки, навигация, формы, соцсети) и «Контент» (перенос страниц, meta, структурированные данные, карта сайта) — согласовали на этапах Pre-Migration и Post-Migration до запуска в работу. 96-строчный экспорт Screaming Frog держал обе очереди QA вместе. Во время работы оригинальный сайт был доступен только через VPN, и вкладка экспорта оставалась единственным надёжным эталоном для каждой страницы. Поэтому, привязав H1 и meta description к её данным ещё до того, как открылась хоть одна очередь, мы добились, что и очередь по SEO, и очередь аккаунт-менеджера проверяли по одному эталону, а не по тому, как страница выглядела в моменте. ## Результаты Метрика Результат URL собрано **76** по 10 шаблонам (1 Homepage · 1 About Us · 1 Contact Us · 4 Services Landers · 24 Service Pages · 11 Doctor Pages · 1 Blog Lander · 17 Blog Posts · 7 Blog Category Pages · 9 Default Template) Шаблонов применено **10 / 10** из стандартной стоматологической библиотеки агентства Очередь по SEO **14 / 14** закрыты Очередь аккаунт-менеджера **14 / 14** закрыты Контрольный список запуска **49 строк** согласованы по «Дизайну» / «Функциональности» / «Контенту», Pre-Migration и Post-Migration Точность контента 96-строчный экспорт Screaming Frog оригинала держали как эталон H1 и meta на всём протяжении сборки Сроки **130 дней** (25 фев – 5 июл 2025), по графику Затраты **56,5 ч / оценка 57 ч** — без перерасхода, без расползания объёма Сдача Сайт запущен на WP Engine, `https://www.myolneydentist.com/` отдаёт HTTP 200 Статус сайта, проверено 2026-04 Сайт работает, отдаёт 200 по свежей проверке ## Контроль качества Нагрузка QA на этой сборке легла на две параллельные очереди со стороны агентства — 14 строк по SEO и 14 строк аккаунт-менеджера — плюс 49-пунктный контрольный список запуска по «Дизайну», «Функциональности» и «Контенту» на этапах Pre-Migration и Post-Migration. Все три свели к нулю перед публикацией на WP Engine. QA перед сдачей проходил через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Свой проверочный контур агентства шёл после сдачи; найденные замечания попадали в общую очередь, и мы отрабатывали их в цикле исправлений до согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблицу разобрали, экспорт оригинала учли, объём оценили, 57 ч согласовали Сборка (страницы + шаблоны) ~3 недели Все 76 URL собраны по 10 шаблонам на тестовой среде; обе очереди QA открыты Обновление контента + правки на тестовой среде ~4 недели (параллельно с QA) Контент страниц услуг получен и интегрирован; раунды правок на тестовой среде; новые фотографии клиента добавлены на опубликованный сайт Сверка QA (очереди SEO + аккаунт-менеджера) ~7 недель Обе очереди отработаны параллельно; раунд срочных исправлений закрыт; проверка аккаунт-менеджера принята Контрольный список запуска + сдача Финальная неделя 49 строк согласованы; запуск в работу на WP Engine _Этапы пересекаются — обновления контента и срочные исправления приходили, пока очереди QA были ещё открыты, поэтому календарь занял 130 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на этапах разработки, интеграции контента и исправлений - **Павел Сажин** — управление проектом и итерации QA - **Анна Полунина** — поддержка разработчика по обновлению контента, правкам на тестовую среду и раундам QA - **Евгений Карпов** — поддержка разработчика на раунде live-fix и обновлении изображений - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > Вы отвечаете перед клиентом за позиции в поиске, а на сборке стоматологического сайта таксономия услуг и врачей задаёт не только навигацию — от неё зависят URL-архитектура и граф схемы, на которых держится ваша отчётность. У этой практики — одна клиника общего профиля; у других — сеть DSO, сводящая несколько унаследованных брендов под один домен. Риски тихие. Новое направление на шестом месяце не впишется в схему URL. Страницы с фильтром по врачам выпадут из индекса после миграции. Схема, на которую опираются ваши панели аудита, молча слетит на импорте. Мы строим таксономию так, чтобы следующее направление встало без миграции, фильтр по врачам остался в индексе, а схема пережила импорт. Поэтому подрядчику стоит задавать не вопрос «соберёте ли вы страницы?», а вопрос «как именно вы построите таксономию, чтобы следующее направление встало без миграции URL?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим URL-план с вашим набором ранжирующихся страниц, отметим места, которые ломаются при добавлении нового направления, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-eye-care-60h-59-days/ title: Новая разработка сайта офтальмологии: 21 страница на WordPress за 59 дней type: case_study date: 2025-12-05T04:15:29+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 21 страница офтальмологического сайта на WordPress в пяти брендированных шаблонах — AI-контент, полностью заменивший оригинальные тексты, и дизайнерское ТЗ: вёрстка подстраниц должна была читаться как свежий дизайн, а не как визуальная копия. Собрали на WP Engine за 60 часов в течение 59 дней, все 34 пункта очереди правок агентства закрыли до передачи. Риск, от которого страхуется агентство, — подрядчик, который верстает страницы аккуратно, но оставляет миграцию недоделанной: URL-слаги незаметно изменились; внутренние ссылки ведут на домен тестовой среды; контактные данные NAP (название практики, адрес, телефон) по-разному оформлены на разных страницах. В офтальмологии, где пациенты находят оптометриста в первую очередь через локальный поиск, такие незаметные расхождения — не косметика: они снижают видимость практики в поиске, и ни одной видимой ошибки в вёрстке при этом нет. Офтальмологический сайт на WordPress собрали на WP Engine и брендированной системе шаблонов агентства, с AI-контентом вместо оригинала, и уложились в смету по часам. ## Краткий обзор Поле Значение Отрасль клиента Медицина — офтальмология / оптометрия Конечный клиент Karan’s Vision Center (независимая оптометрическая практика) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новый сайт (замена контента на существующей структуре URL, WP Engine, система шаблонов агентства) Объём **21 URL** — главная, о практике, страницы врачей, посадочная услуг, 11 страниц услуг, страницы брендов, технологии, местоположения, юридические страницы Сроки 59 дней (26 фев – 26 апр 2025), по графику Трудозатраты 60 часов Команда 4 специалиста Шаблоны **5 шаблонов** из стандартной библиотеки агентства, применённых на 21 странице (Service Page, Homepage, About Us, Default Template, Brands) Технологии WordPress · Elementor · WP Engine hosting · AI-контент · Rank Math · Site Checker ([xaverPRO](https://xaver.ru/) QA-плагин) **Подход к QA** **34 пункта очереди правок закрыты** (100%) в единой вкладке очереди агентства плюс 46-пунктный контрольный список запуска **Ритм работы** 34 правки от агентства · все закрыты к передаче (активная фаза 21 день, 2025-03-20 – 2025-04-09) **Раунды проверки** ≈2 раунда проверки в 59-дневном календарном окне **Контрольный список запуска** 46 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США пересобирало сайт Karan’s Vision Center — независимой оптометрической практики — на своей брендированной системе шаблонов на WP Engine. Существующую структуру URL сохраняли; контент заменяли новым, написанным ИИ. Агентство передало нам структуру сайта и трекер работ, Google Sheets с новым контентом по каждой странице, доступы к тестовой среде на WP Engine и документ с заметками дизайнера — визуальными правками, которые делали новую сборку отличимой от исходной вёрстки. Нам нужно было собрать каждую страницу, внести дизайн-изменения и сдать сайт, который агентство прогонит через свой контрольный список QA и передаст клиенту. В бриф агентства входила прямая оговорка про отличие вёрстки: внутренние страницы должны были отличаться от исходного сайта практики настолько, чтобы их нельзя было счесть прямой копией. Это условие шло параллельно с заменой контента — мы собирали новые страницы, а не мигрировали старые, и шаблон должен был читаться как свежий дизайн при той же структуре URL. Риски сайта офтальмологии завязаны на непрерывности локального поиска. Канал привлечения оптометрической практики — почти целиком локальный поиск: запросы вроде «eye doctor near me» или «Karan’s Vision Center» ведут на конкретные URL-слаги, и контактные данные на этих страницах должны совпадать с Google Business Profile. Сборка, которая незаметно меняет `/service/dry-eye-therapy/` на `/services/dry-eye/`, ломает URL, на который полагается аудитория практики. Сборка, в которой на двух из 11 страниц услуг стоит неверный номер телефона, создаёт несогласованность NAP — локальные поисковые алгоритмы читают это как сигнал проблемы. Наш проход QA перед передачей — проверка основных настроек, аудит структуры URL и вычитка языка контента — закрывал именно эти пробелы до того, как запускался QA на стороне агентства. > **Контекст рисков.** Для независимой оптометрической практики, чей канал привлечения — почти целиком локальный поиск, риск сборки не визуальный, а тихое искажение данных: слаг незаметно изменился; номер телефона по-разному оформлен на 11 страницах услуг; каноникал ведёт на тестовую среду вместо опубликованного сайта. Ни одна из этих проблем не видна в браузере, и все они подрывают присутствие практики в локальном поиске после запуска — без единого индикатора вроде сломанной страницы. ## Как мы это сделали **1. Шаблоны и страницы — пересборка набора URL.** Мы собрали 21 страницу на 5 шаблонах: Service Page применили 11 раз по стандартной таксономии услуг офтальмологии (осмотры зрения для взрослых и пожилых, детские осмотры зрения, контактные линзы, осмотры при диабете, терапия сухого глаза, неотложная помощь, диагностика заболеваний глаз, консультация по лазерной хирургии, контроль миопии, нейролинзы, optilight), плюс Homepage, About Us, Brands и Default Template. Таксономия услуг соответствует стандартному набору офтальмологии — тем же категориям, по которым пациенты ищут независимые оптометрические практики. **2. Новый контент, новый дизайн — тот же набор URL.** Контент на каждой странице был новым: написанные ИИ тексты от агентства загружали постранично в шаблон, сохраняя существующие URL-слаги. Параллельно с заменой контента заметки дизайнера предписывали визуальные правки, чтобы новая сборка отличалась от исходной вёрстки — структура подстраниц, Hero и секционные макеты, оформление изображений. Обе операции шли на одних и тех же страницах одновременно, и держать точность контента в связке с дизайн-изменениями — это и была координационная задача на стороне разработки. **3. Цикл правок и обратной связи до согласования.** После первой сборки агентство открывало раунды обратной связи от клиента и проверяющего через общую очередь. Каждый раунд собирал точность контента (фотографии врачей, контактные данные, поведение виджета отзывов), правки вёрстки и межблочных отступов, постраничные дизайн-правки. **34 пункта очереди закрыты на 100%** — каждую отслеженную правку решили до передачи. Ритм правок повторял процесс агентства: отдельные записи в списке изменений в трекере Google Sheets, проверка аккаунт-менеджером, передача нам на реализацию, подтверждение QA перед закрытием. Там, где клиент просил поменять видимый текст в формулировках местоположения — повторяющееся «in Knoxville» в заголовках страниц услуг, — мы оставили H1 с полным указанием города ради непрерывности локального поиска и увели видимый текст в подзаголовок, а не вырезали ключевой контент со страницы. **4. Проверка набора URL для локального поиска перед передачей.** Перед передачей мы прогнали проход QA через Site Checker — основные настройки, контент и SEO (мета-заголовки, слаги, каноникалы), структуру URL, вычитку языка контента по страницам и меню, скриншоты в нескольких разрешениях. Для офтальмологической практики важнее всего для непрерывности локального поиска именно они: согласованность слагов, точность текстов рядом с NAP (формат названия практики, адрес, телефон) и корректность каноникалов. Проход подтвердил, что сборка чистая, ещё до того, как после передачи запускался QA на стороне агентства. Условие отличить вёрстку прямо спорило с требованием сохранить H1 для локального поиска. Чтобы дизайн подстраниц стал достаточно отличим от работы предыдущего подрядчика, пришлось менять структуру каждой страницы; а чтобы оставить «Dry Eye Therapy in Knoxville» в H1 — а не в визуально более чистой усечённой форме, которую предлагал дизайн, — мы не трогали элемент, от которого зависело ранжирование в локальном поиске. Оба условия должны были держаться на одних и тех же страницах одновременно. ## Контроль качества QA перед передачей подтвердил, что структура URL и H1 сохранены на всех 11 страницах услуг — включая H1 с указанием города «Dry Eye Therapy in Knoxville», который команда осознанно оставила ради непрерывности локального поиска, — и поймал битую внутреннюю ссылку на `/our-technology/`, ведущую на несуществующий слаг `/digital-eye-strain/`; её исправили до того, как агентство увидело сборку. QA перед передачей прошёл через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Собственный QA агентства шёл после передачи и вносил замечания в общую очередь, которую мы отрабатывали в цикле исправлений до окончательного согласования. ## Результаты Метрика Результат Создано URL **21** — 1 главная, 1 о практике, 11 страниц услуг по стандартной таксономии офтальмологии, 2 страницы брендов, 1 страница технологии, 1 страница местоположения, 4 юридические / служебные страницы Применено шаблонов **5 из 5** шаблонов стандартной библиотеки агентства (Service Page ×11, Default Template ×6, Brands ×2, Homepage ×1, About Us ×1) Очередь правок **34 / 34 пункта закрыто** (100%) Контрольный список запуска **46 пунктов** по категориям Design / Functionality / SEO / Responsive / DNS Сроки **59 дней**, сдано по графику Трудозатраты **60 часов** Команда **4 специалиста** Хостинг Собрано и сдано на тестовой среде WP Engine, перенесено на основной домен Статус сайта Сайт запущен на karnsvision.com — подтверждён 200 OK на момент написания кейса Если коротко: 21 страница на 5 шаблонах, загружен AI-контент, вёрстка отличается от исходного сайта, 34 пункта очереди закрыты, 46 пунктов контрольного списка запуска согласованы — за 59 дней, в рамках 60 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Структуру сайта разобрали, доступ к тестовой среде подтвердили, объём согласовали (26 фев – 3 мар) Сборка ~3 недели 21 страница с новым контентом и дизайн-правками (3 мар – 24 мар) QA и раунды правок ~4 недели Заметки дизайнера, правки клиента, изменения вёрстки; 34 пункта очереди доведены до 100% (24 мар – 9 апр) Постзапускная проверка ~2 недели Одна правка после запуска; очередь проверена и закрыта (9 апр – 26 апр) ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (сборка, загрузка контента, дизайн-правки) - **Владимир Козлов** — разработчик (вёрстка подстраниц, загрузка контента, дизайн-изменения) - **Людмила Травкина / Павел Сажин** — QA-проверка и подписание этапов - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, коммуникация с клиентом и право последнего слова по дизайну оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента; все запросы на правки приходили через общий список изменений агентства, и каждый раунд уходил на следующий этап только после согласования с проверяющим агентства. ## Агентствам, заказывающим разработку WordPress > На сайте оптометрической практики, собранном под локальный поиск, позиции живут не только в дизайне — они в схеме разметки, в цитированиях по каталогам и в URL-архитектуре. У этой практики — одна клиника, чей поток заявок держится на чистом следе NAP и единственной карточке в Google Картах; у других — сеть офтальмологических клиник, сводящая бренд по десяткам локальных каталожных профилей. В беду заказчика загоняют тихие сбои. Формат телефона разъезжается по страницам услуг и ломает структурированные данные, которые вы отслеживаете для Local Pack. Схема слетает на импорте — расширенные результаты пропадают из ваших панелей отслеживания. Интеграция формы молча отказывает, и данные о заявках перестают приходить — без видимой ошибки. Мы строим таксономию так, чтобы выигрыши агентства в локальном поиске пережили запуск. Поэтому подрядчику стоит задавать не вопрос «соберёте ли вы страницы?», а вопрос «как именно вы выстроите таксономию, чтобы эти выигрыши не потерялись на запуске?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим URL-план с моделью данных локального поиска, отметим места, где следующая услуга ломает архитектуру или где молча сдвигается схема, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-27-page-holistic-pediatric-dental-118-days/ title: Доработка темы для детской стоматологии — 27 страниц type: case_study date: 2025-12-01T10:29:53+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 29 из 42 задач Redmine на этом проекте детской стоматологии на 27 страниц несли суффикс -qa — индивидуальные раунды проверки, где агентство отмечало расхождения с дизайном, мы исправляли, и раунд закрывался только после согласования. Окно в 118 дней длилось с сентября 2025 по январь 2026; QA-итерации шли параллельно с разработкой на всём протяжении, а не как финальная фаза. Site Checker (проверка 4.3.4) зафиксировал кириллическую С в тексте кнопки CALL NOW — унаследована из общего шаблона агентства; устранено до сдачи. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — детская стоматология Конечный клиент Wellness Pediatric Dentistry (San Antonio, TX) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального здравоохранения** Тип проекта Доработка темы WordPress (брендированный шаблон агентства «Luminous» + постраничный дизайн в Figma на Kinsta) Объём **27 URL** — главная, лендинг услуг, 12 страниц услуг (детская стоматология, профилактика, восстановление, особые потребности, седация, дыхательные пути), о клинике, биография врача, страницы оплаты и страховки, блог, галерея улыбок, юридические страницы Сроки 118 дней (20 сен. 2025 – 16 янв. 2026), по графику Затраты 71 час — распределён между разработкой шаблона, QA-итерациями, циклами исправлений и управлением проектом Команда 4 специалиста Шаблоны **14 переиспользуемых шаблонов** от агентства (набор DENTAL), применённых на всех 27 страницах Технологии WordPress · Elementor · Kinsta hosting · Постраничный дизайн в Figma · Archy self-booking · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **73+ отслеженных SEO + CX проблем** сверены в очереди задач агентства с двумя вкладками в рамках контрольного списка запуска на 73 пунктов **Ритм работы** **73 проблемы от агентства · 71 из 73 закрыта к сдаче (активный период 45 дней, 2025-10-01 – 2025-11-14)** **Раунды проверки** **≈8 раундов проверки в рамках 118-дневного календарного окна** **Контрольный список запуска** **73 пунктов, согласованы перед переключением** ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Wellness Pediatric Dentistry и доступ к своему брендированному шаблону «Luminous» на Kinsta. Агентство уже сделало подготовительную работу: карту сайта с документацией контента по каждой странице, брендовые материалы, контакты и доступы, соцсети клиента привязаны. Наша задача — дорабатывать шаблон страница за страницей по Figma, пока агентство не подпишет каждый раунд. У клиники было одно ключевое требование к контенту, которое пронизывало весь набор страниц: Wellness Pediatric Dentistry позиционирует себя как первую холистическую детскую практику в San Antonio, построенную на подходе без фтора, биосовместимых материалах и ортодонтии с фокусом на дыхательные пути. Figma агентства передавала этот голос на каждой странице услуг. В контексте шаблона это означает, что страница о седативной стоматологии читается иначе, чем страница об ортодонтии дыхательных путей: другой регистр для аудитории родителей, другой язык описания лечения, другая формулировка следующего шага. Добиться, чтобы шаблон держал регистр каждой страницы и не давал тону перетекать на соседние, — это не стилистика. Так мы удерживаем язык под обещание практики. Риск, от которого агентство страховалось, характерен для практик с нестандартной клинической философией: клиника, которая привлекает родителей именно как практика без фтора и с биосовместимыми материалами, потеряет эту аудиторию в тот момент, когда на странице услуг появится обезличенный стоматологический текст. На общем шаблоне, где «Страница услуг» используется для 12 страниц, это уже не 1 неверная страница — это одна и та же ошибка в текстах, тихо расходящаяся по всему дереву услуг. > **Контекст рисков.** Холистическая детская практика строит базу пациентов на родителях, которые нашли её именно потому, что это не обычный стоматологический кабинет. Позиция — без фтора, биосовместимые материалы, фокус на дыхательные пути — это несущий маркетинговый текст, а не брендовый оттенок. На шаблоне «Страница услуг», который использовался двенадцать раз в рамках одной лестницы услуг, один обезличенный стоматологический блок, переживший раунд QA, искажает не одну страницу — он сигнализирует родителям, что философия клиники — это декларация на словах, а не реальный стандарт работы. Единый язык на этом проекте — не вопрос текстовых предпочтений. Это механизм, который держит ключевое обещание практики на каждой странице. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон «Luminous» агентства — базовой структурой страниц. Наша задача была сопоставить их страница за страницей: где стандартная разметка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны. Для практики, чей визуальный тон должен считываться как тёплый и вызывающий доверие у родителей — не скатываясь ни в клиническую холодность, ни в обратную крайность, обезличенно-дружескую стоматологическую теплоту, — правило «без импровизации» было ограничением, которое удерживало каждую страницу честной. **2. Языковая гигиена страниц услуг.** Шаблон «Страница услуг» применили двенадцать раз в рамках одной лестницы детских стоматологических услуг — профилактика, восстановление, седация, особые потребности, ортодонтия дыхательных путей, неотложная помощь. Каждая страница несла свой регистр копирайтинга и свой путь CTA. Страница о герметиках ведёт родителей к «записаться на приём»; страница об ортодонтии дыхательных путей — к консультационному пути. На общем шаблоне риск в том, что текстовая строка, надпись на кнопке CTA или встроенная форма из контекста 1 страницы перекочует на соседнюю в ходе QA и циклов исправлений. Отслеживать, какие элементы локальны для страницы, а какие глобальны для шаблона, — это и была основная работа в каждой итерации доработки. Часть позиций в очереди задач агентства по CX и SEO была именно такими поправками в текстах — найденными в цикле проверки, а не при запуске. **3. Цикл QA в масштабе доработки темы.** Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, QA, скорректировать, QA, скорректировать». На этом проекте **29 из 42 задач Redmine были QA-итерациями** (суффикс «-qa») — индивидуальные раунды, где агентство отмечало расхождения в дизайне, мы проверяли, исправляли и возвращали сборку на подписание. За этими раундами шла более глубокая сверка: агентство вело **73+ позиции в двух вкладках очереди задач** (SEO и CX), которые мы прорабатывали параллельно с ритмом Redmine, пока агентство не закрыло очередь к релизу. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без расползания.** Каждое изменение брендированного шаблона — разметки, секционного компонента или стилевого токена — документировалось относительно Figma. Ни одна доработка не просочилась в общие компоненты шаблона, а значит, работа над этим проектом оставила шаблонную систему агентства нетронутой для следующей клиники, которую она будет обслуживать. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах. Каждый раунд QA покрывал страницы, затронутые расхождениями в дизайне данного раунда, а не весь сайт — именно так сборка на шаблоне остаётся экономной без потери покрытия. Двенадцать применений шаблона «Страница услуг» означали, что в каждом раунде QA нужно было понимать, какие контентные элементы локальны для страницы, а какие глобальны для шаблона: страница о герметиках и страница об ортодонтии дыхательных путей имеют одинаковую структуру, но несут совершенно разные регистры текстов и пути CTA. Не дать этим регистрам перемешаться — вот что на самом деле защищал ритм итераций, а не только визуальное соответствие. ## Контроль качества Site Checker (проверка 4.3.4) выявил кириллический символ в тексте кнопки «CALL NOW» — кириллическая С вместо латинской C, унаследованная из общего шаблона агентства; устранено до сдачи. Отдельный проход по галерее улыбок зафиксировал AI-изображения-заполнители и заголовок «your headline goes here», всё ещё активные — страница была скрыта до готовности реального контента. QA перед сдачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу нулевых ошибок. Свой контроль на стороне агентства работал после сдачи, направляя проблемы в общую очередь задач для нашего цикла исправлений до согласования. Доработки остались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. AutoQA (Content-AI проверка включена) — под управлением агентства — был настроен на этом проекте. Content-AI проход выполнялся после сдачи как часть процесса согласования с агентством. ## Результаты Метрика Результат URL доставлено **27** — 1 главная, 1 лендинг услуг, 12 страниц услуг, 1 биография врача, 1 о клинике, 1 контакты, 5 страниц оплаты и страховки, 1 лендинг блога, 1 пост блога, 1 галерея улыбок, 3 юридических страницы Шаблонов применено **14 из 14** шаблонов из набора DENTAL агентства применены на 27 страницах (Страница услуг, Главная, О нас, Страница врача, Контакты, Лендинг услуг, Лендинг блога, Блог, Галерея улыбок, Финансирование, Страховка, План оплаты/Членство, Платёжная политика, Условия/Конфиденциальность/Отказ) Контрольный список запуска **73 пунктов** согласованы QA / SEO / CX проблем отслежено и закрыто **73+** позиции сверены в двух вкладках очереди задач агентства QA-итераций Redmine **29 из 42 задач (69%)** отслежены на уровне итераций Сроки **118 дней**, доставлено по графику Затраты **71 час** Команда **4 специалиста** Передача хостинга Запущено в шаблонной среде Kinsta агентства, затем перенесено на домен клиента Здоровье страниц на момент сдачи **27 / 27** URL из карты сайта возвращали HTTP 200 в аудите тестовой среды Статус в работе Сайт запущен на wellnesspediatricdentistry.com — проверен 200 OK на момент написания этого кейса Результат простыми словами: Figma агентства была реализована на их брендированном шаблоне «Luminous» на 27 страницах и 14 шаблонах за 118 календарных дней в рамках бюджета в 71 час. ## Процесс Фаза Длительность Результат Бриф и оценка ~1 неделя Figma проверен, доступ к шаблону подтверждён, объём согласован (20 сен – 29 сен) Разработка доработок ~5 недель Постраничная доработка шаблона под Figma; построена лестница детских стоматологических услуг QA-итерации (параллельно) ~10 недель 29 отдельных раундов QA; каждый закрыт только после согласования с агентством Циклы исправлений ~3 недели Коррекции после проверки, включая сверку очереди задач и обновление кнопок и встроенных виджетов Задачи после переноса ~3 недели Финальная сверка очереди задач QA и дополнения после запуска (янв. 2026) _Разработка и QA шли параллельно на всём протяжении — это характерно для доработки темы, где никакая «фаза QA» не закрывается чисто; цикл идёт непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Евгений Карпов** — ведущий разработчик (доработка темы и сопоставление Figma с разметкой) - **Никита Тумашевич** — поддержка разработчика и исправления после запуска - **Павел Сажин / Тимур Арбаев** — QA-итерации и проходы подписания по раундам - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Партнёрское агентство сохраняло авторство дизайна, отношения с клиентом, источники контента и конфигурацию хостинга на всём протяжении. Наша команда никогда не общалась напрямую с Wellness Pediatric Dentistry — все запросы шли через общую очередь задач агентства, и каждый цикл исправлений передавался на следующий этап только после согласования с проверяющим агентства. ## Агентствам с библиотекой шаблонов > На сайте холистической детской стоматологии позиционирование — не декорация, а основной канал привлечения. У этой практики — авторские протоколы без фтора и язык для родителей; у других — набор услуг и типовые заголовки. На переиспользованном шаблоне риски тихие. Блоки «Страница услуг» разойдутся с мета-тайтлами, доработки пропадут при следующем обновлении темы, а контент на внутренних страницах перестанет звучать как единая философия. И узнаёте вы это от клиента, а не от подрядчика. Подрядчику стоит задавать не вопрос «соберёте ли на шаблоне», а вопрос «как именно вы изолируете наш контентный слой от обновлений темы и сохраните философию бренда на каждом блоке?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы проверим, где слои шаблона будут спорить с вашим контентом, и подсветим блоки, которые слетят при первом обновлении темы. Вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-orthopedic-spine-63h-66-days/ title: Сборка WordPress для ортопедии и хирургии позвоночника на 85 страниц за 66 дней type: case_study date: 2025-11-26T06:55:58+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 85 страниц новой сборки на Elementor для многопрофильной ортопедической практики в Нью-Джерси — 80 старых PHP-путей сопоставили с постоянными ссылками WordPress, две опечатки в slug’ах филиалов поймали при проверке редиректов перед запуском, форму записи Gravity Forms на 7 получателей собрали с нуля. Очередь правок агентства на 29 пунктов и контрольный список запуска на 46 пунктов закрыли до запуска сайта на WP Engine. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Ортопедия и хирургия позвоночника Клиент Oasis Orthopedic & Spine (Нью-Джерси, 11 клиник) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Сборка WordPress с Elementor Pro на WP Engine, с последующим этапом согласования правок Объём **85 URL** — главная, 25 страниц лечения, 25 страниц состояний, 12 страниц услуг, 4 страницы врачей, 10 страниц филиалов, каталог филиалов, каталог лечения, блог + 3 записи, 2 страницы о нас и вспомогательные страницы на шаблоне по умолчанию Сроки 66 дней (4 мар – 10 май 2025), сдано в срок Затраты **63 часа** при оценке в 63 часа — без перерасхода Команда 4 специалиста (распределение с акцентом на разработку, соответствующее сборке с объёмом контента и согласованием редиректов) Шаблоны **11 многоразовых шаблонов** — стандартная библиотека медицинских шаблонов агентства Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Rank Math · WP Rocket · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **85 URL собрано на 11 шаблонах, 80 пар старых редиректов сведено, контрольный список запуска на 46 пунктов закрыт, 27 из 29 пунктов очереди правок выполнено** **Динамика проекта** 28 задач от агентства · все закрыты к передаче (активный период 1 день, 2025-04-10) **Раунды проверки** ≈5 раундов на 66-дневном календарном окне **Контрольный список запуска** 46 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство, нанятое Oasis Orthopedic & Spine — практикой в Нью-Джерси с одиннадцатью клиниками и четырьмя сертифицированными хирургами — передало нам Google Sheets таблицу с полной картой URL, каталогом шаблонов, обходом Screaming Frog старого PHP-сайта, контрольным списком запуска и заранее заполненной очередью правок. Сборка размещалась в их среде WP Engine; конструктором страниц был Elementor Pro; формами — Gravity Forms. Карта сайта содержала две колонки URL: старые пути `.php` на прежнем сайте и новые постоянные ссылки WordPress, которые предстояло собрать. Задача: собрать все 85 страниц по библиотеке шаблонов агентства, свести 80 старых URL, которым нужен редирект со старого набора PHP-путей на новые постоянные ссылки WordPress, и отработать очередь правок до приёмки сайта агентством. На всём протяжении оставаться вне контура общения с конечным клиентом, выносить неясности агентству, не импровизировать с медицинским контентом или навигационной иерархией. > **Контекст рисков.** Практика ортопедии и хирургии позвоночника живёт в локальном поиске. Пациенты не ищут «спондилодез» абстрактно — они ищут «хирург-ортопед рядом со мной» или «врач-ортопед Perth Amboy» и попадают на конкретные URL, которые практика накапливала годами. Когда сборка заменяет наследуемый PHP-сайт новой архитектурой URL WordPress, риск не в том, выглядят ли новые страницы корректно; риск в том, будут ли 80 наследуемых путей, которые Google проиндексировал, всё ещё разрешаться. Подрядчик, который строит чистые страницы, но относится к согласованию редиректов как к второстепенной задаче, сдаёт сайт, который выглядит готовым, но молча теряет поисковую видимость с первого дня. Бриф этого проекта был структурирован вокруг именно этой проблемы: карта сайта включала обход Screaming Frog, колонку редиректов и очередь задач после запуска — ещё до того, как была построена первая страница. ## Как мы это сделали **1. 11 шаблонов, 85 страниц, один процесс сборки.** Страницы Oasis распределились по медицинской библиотеке шаблонов агентства: главная, страница лечения (25 процедур, включая спондилодез, дискэктомию, нервные блокады), страница состояний (25 состояний, включая боль в голеностопе и стопе, костные шпоры, травму при ДТП), страница услуг (12 услуг), страница врача (4 хирурга), страница филиала (10 филиалов — Glen Rock, Plainfield, Jersey City, Elizabeth, Perth Amboy, West New York, East Orange, Summit, Clifton, Union), каталог филиалов, каталог лечения, блог + записи, страница о нас и шаблон по умолчанию для вспомогательных страниц. Каждую страницу построили на назначенном шаблоне из строки карты сайта; ни одной страницы не собирали вручную вне системы шаблонов. **2. Сведение редиректов старых URL по 80 парам.** Обход Screaming Frog старого PHP-сайта выявил 80 путей `.php`, которым нужен постоянный редирект на новые ссылки WordPress. Мы свели каждую пару в карте сайта — старый путь на новую постоянную ссылку — и проверили таблицу редиректов по аудиту агентства. Все 80 пар закрыли до передачи; ещё 67 старых URL пометили на удаление, а не на редирект, и таблица редиректов это отразила. **3. Цикл правок до согласования.** После первичной сборки агентство открыло раунды обратной связи от клиента и проверяющего через общую очередь правок. Задача #384 (исправление ошибок перед запуском) охватывала QA перед запуском: метаданные, выравнивание слайдера и битые ссылки. Задача #436 (обратная связь клиента) касалась отсутствующих описаний под заголовками страниц услуг и центровки точек слайдера. Задача #415 (очередь правок Селены) вела послесборочные задачи, включая настройку плагина Rank Math Instant Indexing и подключение уведомлений форм. Задача #438 (обновление информации веб-форм) потребовала собрать с нуля сложную конфигурацию Gravity Forms с несколькими уведомлениями — 7 адресов получателей для маршрутизации записей. На странице филиалов нужна была карта Google Maps, но для API-ключа требовался платёжный метод, зарегистрированный в США, которого у команды тогда не было; мы развернули карту с временным ключом разработчика, чтобы не останавливать сборку, пока агентство заводило собственный платёжный профиль. Очередь правок на 29 строк закрыли на 27 выполненных; остаток — ожидание информации от клиента. **4. Проверка перед передачей под локальный поиск.** Перед передачей мы прогнали предварительное QA через Site Checker — основные настройки, контент и SEO-составляющую (мета-заголовки, slug’и, canonical), структуру URL, вычитку языка контента по страницам и меню, скриншоты на нескольких разрешениях. Для многопрофильной ортопедической практики важнее всего для непрерывности локального поиска именно эти категории: согласованность slug’ов, точность NAP-данных (формат названия практики, адрес, телефон на 10 страницах филиалов) и корректность canonical. Проверка подтвердила, что сборка чиста до запуска собственного контура проверки агентства. Таблица редиректов должна была быть верной прежде всего остального. Две опечатки в slug’ах филиалов — `/locations/perth-amboys/` и `/locations/plainfields/` — мы поймали в ходе QA на тестовой среде и исправили до начала цикла проверки агентства, а не после. На многопрофильной ортопедической сборке сломанный редирект на странице локации — не визуальный дефект; это сбой локального поиска, который может незаметно длиться неделями. ## Результаты Метрика Результат URL построено **85** на 11 шаблонах (25 страниц лечения · 25 страниц состояний · 12 страниц услуг · 4 страницы врачей · 10 страниц филиалов · 1 каталог филиалов · 1 каталог лечения · 1 главная · 1 блог · 3 записи блога · 2 страницы о нас · вспомогательные страницы по умолчанию) Применено шаблонов **11 / 11** из стандартной библиотеки медицинских шаблонов агентства Сведено пар редиректов **80** уникальных пар со старых путей `.php` на новые постоянные ссылки WordPress Очередь правок **27 / 29** закрыто как выполненные; 1 ожидание информации Контрольный список запуска **46 пунктов** согласовано по разделам Дизайн / Функциональность / Перед миграцией / После миграции Сроки **66 дней** (4 мар – 10 май 2025), сдано в срок Затраты **63 ч / оценка 63 ч** — без перерасхода, без расширения объёма Статус сайта Опубликован на WP Engine, `https://www.oasismed.com/` — проверено в апреле 2026, HTTP 200 Результат, если коротко: сборка агентства на 85 URL сдана на 11 шаблонах в среде WP Engine, в рамках сметы на 63 часа. Восемьдесят старых URL сопоставили с новыми постоянными ссылками WordPress, очередь правок отработали до уровня приёмки агентством, контрольный список запуска закрыли до переключения. ## Контроль качества QA перед запуском на этой сборке поймало две опечатки в slug’ах филиалов — `/locations/perth-amboys/` и `/locations/plainfields/`, — которые привели бы к сломанным редиректам на рабочем сайте, и свело сбой рендеринга слайдера Elementor к кэшированию на уровне виджетов; мы исправили его, отключив кэш на всех затронутых страницах услуг до передачи. Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Внутренний контроль агентства запускался после передачи и сводил замечания в общую очередь правок до их утверждения. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица изучена, учётные данные для тестовой среды подтверждены, 63 ч оценено и согласовано Этап сборки (страницы + шаблоны) ~3 недели Все 85 URL построены на 11 шаблонах на тестовой среде; обход Screaming Frog изучен для сопоставления редиректов Сведение редиректов + исправления перед запуском ~2 недели 80 пар старых редиректов закрыто; очередь правок открыта и отработана Цикл правок (обратная связь клиента + сборка формы) ~2 недели Пункты обратной связи клиента решены; конфигурация Gravity Forms с несколькими уведомлениями собрана и протестирована Доработки после запуска ~1 неделя Задачи из очереди решены на опубликованном сайте; таблица редиректов проверена в работе _Этапы пересекаются — сведение редиректов началось до того, как закрылись все страницы этапа сборки, а цикл правок шёл параллельно финальным QA-раундам, поэтому календарный срок — 66 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик сборки, согласования редиректов и конфигурации форм - **Анна Полунина** — разработчик и QA по исправлениям перед запуском и задачам из очереди - **Павел Сажин** — QA-итерации и проверка исправлений - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались у партнёрского агентства на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > Боитесь, что добавите новое направление через полгода — а оно не встанет в URL-схему без переезда всего сайта? На сайте ортопедии и хирургии позвоночника таксономия задаёт не только навигацию: на ней держатся URL-архитектура, граф структурированной разметки и позиции, которые агентство уже заработало. У этой практики одна специализация с двумя ветками — хирургия и консервативное лечение; у других — мультифилиальные ортопедические группы по позвоночнику, суставам и спортивной медицине. Опасны тихие сценарии: новая специализация на шестой месяц не вписывается в шаблон URL; разметка слетает на импорте, и расширенные сниппеты пропадают; страницы-фильтры по состояниям перестают выводить рабочие пути для пациентов. Спрашивать подрядчика стоит не «соберёте ли страницы?», а «как именно вы построите таксономию, чтобы следующая специализация или филиал встали без миграции?». Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы пройдём URL-план по вашему списку ранжируемых страниц, сверим разметку и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-25-page-dental-103-days/ title: Доработка темы для стоматологии — 25 страниц за 103 дня type: case_study date: 2025-11-21T15:15:06+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 25 страниц на 10 связанных с Figma шаблонах, на стоматологической теме Kinsta — 12 из них на одном шаблоне страницы услуг, каждая со своим контентом, изображениями и CTA. Посреди работы контур проверки агентства поймал разнобой в жирности абзацев на всех 12 страницах услуг и дублирующиеся мета-описания на каждой; оба дефекта требовали системного прохода, а не точечной правки по странице. Такова цена точности, когда 1 шаблон применяешь 12 раз: проверку соответствия проходишь тоже 12 раз. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает раунды QA или отходит от дизайн-системы шаблона, хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Индустрия конечного клиента Здравоохранение — Общая стоматология Конечный клиент Centergate Family Dentistry (стоматологическая клиника в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированная тема агентства + постраничный дизайн в Figma, хостинг Kinsta) Объём работ **25 URL** — главная, о нас, лендинг услуг, **12 страниц услуг**, страница врача, галерея улыбок, контакты, лендинг блога + пост и 5 вспомогательных страниц (FAQ, финансовая информация, формы, команда, запись на приём) Срок 103 дня (14 июл – 25 окт 2025), в срок Затраты 55 часов — 25 ч разработка · 15 ч PM · 10 ч QA · 5 ч правки Команда 5 специалистов Шаблоны **10 повторно используемых шаблонов** от агентства, применённых на всех 25 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн из Figma · AutoQA агентства · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **300+ сверенных замечаний SEO + CX** в общей очереди агентства, по контрольному списку запуска из 73 пунктов **Интенсивность взаимодействия** 60 замечаний от агентства · все закрыты к передаче (36 дней активной работы, 2025-08-05 – 2025-09-09) **Раунды проверки** ≈7 раундов за 103 календарных дня **Контрольный список запуска** 73 пункта, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам дизайн Figma для Centergate Family Dentistry и цель развёртывания на своей брендированной теме, размещённой на Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, сбор требований клиента, настройку хостинга и подготовку контента через Google Docs для каждой страницы услуг. Им требовалась команда разработки, которая аккуратно перенесёт Figma на тему и выдержит цикл QA столько, сколько идёт проверка со стороны агентства. Задача была чёткой по исполнению: доработать тему до соответствия Figma постранично, передавать замечания в общую очередь и возвращать каждую итерацию только после того, как проверяющий со стороны агентства подтвердит, что расхождение устранено. В объём на 25 страниц входили 12 страниц услуг — каждая со своим фреймом Figma, блоком контента и изображениями — и все на одном базовом шаблоне страницы услуг. Часть фреймов Figma задавала визуальные эффекты, которые шаблон не мог воспроизвести напрямую; потребовались решения на CSS — например, наложения с backdrop-filter там, где у компонентов шаблона готового аналога не было. Главный риск, когда 1 шаблон применяешь 12 раз, — не громкий сбой, а накопительный дрейф. Третья страница услуг совпадает с Figma, но к восьмой отступы уже съехали, блок CTA сместился, а соотношение сторон изображения незаметно поменялось. Подрядчик, который воспринимает повторное применение шаблона как «скопировал и подправил», а не «доработал и проверил», сдаёт агентству сайт: в целом выглядит правильно, а расходится в деталях, заметных пациентам. Очередь на 305 пунктов по этому проекту — запись той самой тщательности, выдержанной страница за страницей. > **Контекст рисков.** Когда 1 шаблон страницы услуг применяется 12 раз в рамках одной клиники, риск — не драматический сбой, а накопительный дрейф. Третья итерация совпадает с Figma; к восьмой отступы уже съехали, блок CTA сместился, а соотношение сторон изображения незаметно поменялось. Подрядчик, который воспринимает повторное применение шаблона как «скопировал и подправил», а не «доработал и проверил», сдаёт агентству сайт, который на первый взгляд выглядит правильно, но расходится в деталях, которые пациенты и проверяющие замечают при внимательном просмотре. ## Как мы это сделали **1. Figma как контракт, тема как холст.** Файл Figma был спецификацией дизайна. Брендированная тема — базовой структурой страниц. Наша задача была согласовать их постранично: где стандартная вёрстка темы совпадала с Figma, мы её сохраняли; где Figma требовала отклонения — дорабатывали. Никакие дизайнерские решения не исходили от нас. **2. Цикл QA в масштабе доработки темы.** Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Агентство вело **305 пунктов в двух вкладках очереди** (186 замечаний SEO и 119 CX), из которых 85 были отмечены выполненными на момент передачи. Каждый раунд был проверкой — по странице или по всему сайту, — где агентство отмечало расхождения с дизайном, мы их разбирали, исправляли и возвращали сборку на следующий проход. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без дрейфа.** Каждое изменение, которое мы вносили в брендированную тему — будь то вёрстка страницы, компонент секции или стилевой токен — документировалось относительно референса из Figma. Ни одна доработка не «просочилась» в общие компоненты темы, то есть работа по этому проекту не ухудшила тему для следующего сайта, который будет её использовать. Когда полупрозрачные наложения или другие эффекты выходили за пределы штатных возможностей темы, команда реализовывала их через CSS, а не просила агентство менять Figma — замысел дизайна сохранялся без лишнего круга согласований. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями данного раунда, а не весь сайт — именно так шаблонная сборка остаётся экономной без потери покрытия. 1 шаблон, применённый 12 раз, означал, что проверку соответствия нужно пройти тоже 12 раз. Когда CX-проверка агентства поймала дрейф жирности абзацев на всех 12 страницах услуг, потребовался 1 системный прогон — а не 12 отдельных правок. Это оборотная сторона шаблонного подхода: объём проверки растёт пропорционально числу повторений, и нагрузку на QA нельзя занижать. ## Контроль качества QA на этой сборке несло нагрузку повторения шаблона напрямую: CX-проверка агентства поймала дрейф жирности абзацев на всех 12 страницах услуг, а SEO-вкладка зафиксировала ошибку иерархии H-тегов на главной. Контрольный список из 73 пунктов перед передачей — включая согласованность слешей и коды статусов — согласовали пункт за пунктом, прежде чем хоть 1 страница покинула тестовую среду. Предпередаточная проверка прошла через **Site Checker** — категории и порог нулевых ошибок см. в [наш подход к QA](/site-checker/). Свой контроль на стороне агентства работал после передачи и заносил замечания в общую очередь для нашего цикла правок, пока агентство их не утвердит. Доработки оставались в переопределениях на уровне клиента; общие компоненты темы агентства не менялись. ## Результаты Метрика Результат URL сдано **25** — 1 главная, 1 лендинг услуг, 12 страниц услуг, 1 страница врача, 1 галерея улыбок, 1 о нас, 1 контакты, 1 лендинг блога + 1 пост блога и 5 вспомогательных страниц Шаблонов применено **10 из 10** повторно используемых шаблонов собрано и развёрнуто на 25 страницах (главная, о нас, лендинг услуг, страница услуг, галерея улыбок, страница врача, контакты, лендинг блога, блог, стандартный шаблон) Контрольный список запуска **73 пунктов** согласованы QA / SEO + CX дефектов отслежено и устранено **305+** пунктов согласовано в двух вкладках очереди задач агентства (186 SEO + 119 CX), 85 отмечены как выполненные на момент передачи Срок **103 дня**, сдано в срок Затраты **55 часов** — без перерасхода, без расширения объёма Команда **5 специалистов** Передача хостинга Опубликовано в среде брендированной темы на Kinsta агентства Состояние страниц на момент передачи **25 / 25** URL тестовой среды вернули HTTP 200 в аудите карты сайта Если коротко: Figma агентства реализовали на их брендированной теме — 25 страниц, 10 шаблонов, 103 календарных дня, в рамках оценки в 55 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к теме подтверждён, объём согласован Разработка доработок ~6 недель Постраничная доработка темы до соответствия Figma; разработаны страницы услуг и вспомогательные страницы Итерации QA (параллельно) ~8 недель Множество раундов QA зафиксировано; каждый закрыт только после согласования агентством Раунды правок ~2 недели Коррекция после проверки, обновление контента, добавление изображений Сдача финальный день Сайт запущен на Kinsta _Разработка и QA шли параллельно — это характерно для доработки темы: отдельной «фазы QA», которая закрывается начисто, здесь нет, цикл идёт непрерывно, пока агентство не согласует результат._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и перенос Figma в вёрстку) - **Павел Сажин** — итерации QA и правки - **Анна Полунина** — поддержка разработки по контенту и изображениям - **Тимур Арбаев** — поддержка разработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство всё время держало отношения с конечным клиентом на себе. Все запросы на доработку шли через общую очередь агентства; Centergate Family Dentistry с нашей командой напрямую не работала. Каждый раунд итераций выпускали только после того, как проверяющий со стороны агентства подтвердит, что изменения соответствуют спецификации. ## Агентствам с библиотекой шаблонов > На брендированном шаблоне разрыв между макетом и опубликованной страницей растёт с каждым повторным использованием. У этой клиники — одна точка; у других — сеть филиалов, где тот же шаблон разворачивают с локализованным текстом. Отступы расходятся между копиями: третья страница совпадает со спецификацией, а на восьмой поля уже незаметно съехали. Блоки CTA ломают выравнивание: панель записи стоит ровно на первых версиях и проваливается ниже сгиба на поздних. Соотношения сторон у картинок меняются без флага на проверку: фото врача обрезается криво, когда шаблон по-разному тянет контейнеры по набору услуг. Вопрос подрядчику перед стартом не в том, «соберёте ли вы по шаблону», а в том, как именно вы сверите каждую копию с брендбуком. Пришлите исходник шаблона или его ID и спецификацию бренда. Мы пройдём каждую копию по спецификации, покажем, где согласованность гарантированно поедет, и вернём смету в фиксированных часах. Разбор — бесплатно; смета приходит в часах, а не вилкой. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-46-page-83-days/ title: Доработка шаблона для стоматологии в Лас-Вегасе — 46 страниц, 83 дня type: case_study date: 2025-11-17T21:37:41+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 46 страниц стоматологического шаблона Luminous, доработанного по макетам Figma для стоматологической клиники общего профиля в Лас-Вегасе — 10 шаблонов, 43 часа, 83 календарных дня. Ключевым ограничением стало параллельное управление: 37 дополнительных страниц, развёрнутых в тестовой среде в процессе разработки, должны были оставаться в неиндексируемом состоянии, пока шла активная сдача, а повторяющиеся остатки spa-текста из общей базы шаблона потребовали четырёх отдельных раундов исправлений после первичной сдачи. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — общая стоматология Конечный клиент Haven Dental — Dr. Thomas Hsieh (стоматологическая клиника, Las Vegas, NV) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка шаблона WordPress (шаблон Luminous агентства + постраничный дизайн Figma на Kinsta) Объём работ **46 активных URL** — главная, о нас, биография врача, наша команда, технологии, отзывы, районы обслуживания, галерея улыбок, варианты оплаты, контакты, блог (лента + 1 статья), **32 страницы услуг** по 5 категориям стоматологии (косметическая, неотложная, профилактическая, восстановительная, хирургия) + 1 корпоративная подстраница Скрытые страницы 37 дополнительных страниц, развёрнутых в тестовой среде, но скрытых для наполнения контентом после запуска Сроки 83 дня (30 авг — 22 ноя 2025), в срок Затраты 43 часа на разработку, итерации QA, управление проектом и раунды исправлений после запуска Команда 4 специалиста Шаблоны **10 переиспользуемых шаблонов**, предоставленных агентством, применённых ко всем активным страницам Технологии WordPress · Elementor · Kinsta · Постраничный дизайн из Figma · AutoQA агентства (проверки ссылок / email / контента AI) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **272+ отслеженных SEO + CX проблем**, согласованных в очереди задач агентства через 30-пунктный контрольный список запуска **Интенсивность работ** 144 задачи, поднятых агентством · все закрыты к моменту сдачи (активный период 53 дня, 2025-09-01 – 2025-10-23) **Раунды проверки** ≈5 раундов проверки за 83 календарных дня **Контрольный список запуска** 30 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США привлекло нас для доработки своего стоматологического шаблона Luminous под Haven Dental — клинику по адресу 9375 S. Rainbow Blvd. в Лас-Вегасе, штат Невада, под руководством Dr. Thomas Hsieh. Агентство вело вышестоящие работы: дизайн в Figma, среду хостинга Kinsta, координацию контента с клиникой и структуру поэтапного развёртывания. Наша роль ограничивалась разработкой и QA. Объём работ оказался одним из крупнейших среди проектов по доработке темы в нашем портфолио. Архитектура услуг сайта охватывала пять категорий стоматологии — косметическая стоматология, неотложная стоматология, профилактическая стоматология, восстановительная стоматология и хирургия — каждая со своей лендинговой страницей и множеством подстраниц. Тридцать два из 46 активных URL были страницами услуг, построенными на едином шаблоне Service Page, каждая с индивидуальным контентом и изображениями. Ещё 37 страниц были развёрнуты в тестовой среде, но скрыты до наполнения контентом после запуска; они требовали аккуратного управления, чтобы избежать преждевременной индексации. Главная сложность в таком масштабе — не объём, а проблема остаточного контента. Крупная сборка по доработке темы из общей базы имеет предсказуемые сбои: скопированный текст-заполнитель, попадающий в живые страницы, стилистические несоответствия из исходного шаблона, контактные данные или формулировки услуг, перекочевавшие из другой клиники. В проекте Haven Dental очередь задач агентства фиксировала снова и снова одни и те же типы таких находок в нескольких раундах — ошибки контента, невидимые на этапе разработки, но всплывающие при редакторской проверке. Цикл QA существовал именно для того, чтобы выявлять и закрывать эти пункты до согласования, и 272+ строки очереди задач показывают, сколько такой работы здесь потребовалось. Отдельная категория — формулировки в стиле spa, унаследованные от копирайтинга предыдущей отрасли шаблона — потребовала четырёх отдельных раундов исправлений после запуска: это ограничение, характерное для крупной доработки шаблона, где текст страниц пишется не нами. > **Контекст рисков.** Сборка 46-страничного стоматологического сайта из общей базы шаблона — с 32 страницами услуг на единой структуре Service Page и 37 дополнительными страницами в тестовой среде — имеет предсказуемый сценарий отказа: проблема остаточного контента. Тестовые отзывы, стилистика spa, неверное название клиники, несовпадающие контактные данные — ни одно из этого не видно на первом проходе разработки по отдельной странице, и ни одно не вызывает ошибку CMS. Они проявляются только при редакторской проверке рабочего сайта целиком. В таком масштабе одного непроверенного раунда достаточно, чтобы запустить сборку, где половина страниц услуг читается как другая клиника. 272+ строки очереди задач на Haven Dental — это цена правильного подхода. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Брендированный шаблон Luminous — базовой структурой страниц. Наша задача заключалась в постраничном согласовании обоих источников: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовала отклонения, мы дорабатывали. Никаких дизайн-решений с нашей стороны не принималось. Мы выбрали клиентские переопределения вместо модификации общего шаблона Luminous, потому что прямое изменение затронуло бы все остальные сайты клиентов агентства, построенные на той же базе. **2. Параллельное управление скрытыми страницами и активной сдачей.** Карта сайта Haven Dental содержала 83 строки: 46 активных URL для запуска и 37 отмеченных как скрытые («Page Hidden») в ожидании контента от клиники. Управление обоими наборами в одной среде Kinsta требовало поддерживать скрытые страницы в чистом, неиндексируемом состоянии на всём протяжении разработки — развёрнутыми, но подавленными — чтобы запуск активных страниц не был загрязнён черновиками ожидающих страниц. Агентство отметило несколько ошибок, связанных со скрытыми страницами, в очереди задач SEO во время QA, подтвердив, что пассивный подход к скрытым страницам (просто не публиковать их) недостаточен; требовалось активное управление статусами на протяжении всего проекта. **3. Цикл QA в масштабе доработки темы.** Чистая доработка шаблона — это не «построил один раз, проверил один раз». Это «строим, QA, правим, QA, правим». Очередь задач агентства отслеживала 145 SEO-проблем и 127 CX-проблем — 272 строки в двух очередях задач — через 30-пунктный контрольный список запуска. Проблемы охватывали всю редакторскую поверхность: отсутствующие или тестовые контактные данные (email, соцсети, текст hero), несоответствия таксономии услуг из шаблона, текст с тоном spa вместо регистра стоматологической клиники и тестовые отзывы, сохранившиеся в живых страницах. Каждая категория требовала точечного исправления без случайного переноса изменений на страницы, где исходный текст был верным. Коротко: на доработке шаблона именно в QA-цикле создаётся ценность. Более короткий цикл — более слабое соответствие Figma и выше вероятность, что остатки шаблона уйдут в рабочие страницы. **4. Доработка без дрейфа.** Каждое изменение шаблона Luminous ограничивалось клиентскими переопределениями. Общая структура шаблона не модифицировалась. Доработка Haven Dental не изменила поведение шаблона ни на одном другом сайте Kinsta, использующем базу Luminous. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах. Каждый раунд QA был направлен на страницы, затронутые текущим набором изменений, а не на полную карту из 83 URL — покрытие без избыточных циклов проверки. Работа с 37 неиндексируемыми страницами-заглушками параллельно с активной сдачей 46 страниц означала, что последовательность должна быть продуманной: подавление и проверка скрытых страниц до запуска, исправление spa-текста в четырёх отдельных раундах вместо одного финального прохода. Именно порядок здесь и решал — активный набор запустился чистым, потому что скрытый оставался под контролем. ## Контроль качества Доминирующей нагрузкой QA на этом проекте были остатки spa-текста из общей базы шаблона — агентство поднимало отдельные задачи «Replace SPA-LIKE Copy» (3 строки, Redmine #1097) и «Final Spa Removal» (#1206) в нескольких раундах, а отдельная задача перед запуском отмечала пустые скрытые страницы, которые «будут проиндексированы вскоре после запуска» (#1197) — все решены до запуска. Предпусковое QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/): список категорий и порог нулевых ошибок. Внутренний контроль агентства проходил после сдачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их согласования. Доработки оставались в клиентских переопределениях; общие компоненты шаблона агентства не модифицировались. ## Результаты Метрика Результат URL сдано **46 активных** — главная, 32 страницы услуг по 5 категориям стоматологии, 9 вспомогательных страниц, лента блога + статья Скрытых страниц **37** страниц развёрнуто в тестовой среде и скрыто для наполнения контентом после запуска Шаблонов применено **10 из 10** переиспользуемых шаблонов построено и сопоставлено с 46 активными страницами Контрольный список запуска **30 пунктов** согласовано QA / SEO + CX проблемы отслежены и решены **272+** пункта согласованы в двух вкладках очереди задач агентства Сроки **83 дня**, сдано в срок Затраты **43 часа** на разработку, QA, PM и раунды исправлений после запуска Команда **4 специалиста** Хостинг при сдаче Запущен в среде шаблона Luminous на Kinsta агентства Если коротко: Figma агентства реализована на их брендированном шаблоне Luminous — 46 активных страниц, 10 шаблонов, 37 дополнительных страниц в управляемом скрытом состоянии для наполнения после запуска, за 83 календарных дня. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Figma проверена, доступ к шаблону Luminous подтверждён, объём согласован Разработка доработки ~2 недели Постраничная доработка шаблона; параллельное управление скрытыми страницами Итерации QA (параллельно) ~4 недели 272+ пункта в очереди задач; подписание агентством после первичной сдачи Раунды исправлений после запуска ~6 недель Исправления точности контента (удаление spa-текста, тестового текста, обновление изображений и данных) — отдельные задачи в Redmine до ноября 2025 Сдача ноябрь 2025 Сайт запущен на Kinsta; финальное подписание QA завершено _Разработка и QA шли параллельно на всём протяжении. Послезапусковые раунды закрывали остатки контента, которые проявляются только при полной редакторской проверке рабочего сайта — нормальный ритм для крупного проекта по доработке темы, где 37 скрытых страниц ждут контента, а в рабочем наборе — 32 страницы услуг._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (доработка шаблона, сопоставление Figma с макетом, координация исправлений после запуска) - **Павел Сажин** — QA (сверка очереди задач, проверка соответствия дизайну, раунды исправлений) - **Тимур Арбаев** — поддержка QA (дополнительные раунды QA, обновление изображений и данных) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, приёмка, QA уровня xaver) Агентство вело дизайн, контент, коммуникацию с клиентом и хостинг — всё это оставалось на стороне агентства, вне нашей зоны работ. Конечный клиент нас не видел. Задачи поступали через общую очередь задач агентства; ни одна задача не отмечалась выполненной без подписи проверяющего со стороны агентства по каждому пункту. ## Агентствам с библиотекой шаблонов > Сборка на готовом шаблоне прячет риск в зазоре между общим кодом и локальным контентом клиента. У этой практики — один кабинет, настроенный один раз; у других — сеть филиалов, где общий шаблон делят разные практики. Риски тихие: доработки дочерней темы растворятся при первом обновлении родительского шаблона. Привязки индивидуальных полей разойдутся и начнут подменять контент между сайтами. Цвета бренда перестанут обновляться, и половина сайта останется на старой палитре. Подрядчику стоит задавать не вопрос «соберёте ли сайт из шаблона?», а вопрос «как вы ограничите клиентские переопределения, чтобы они пережили обновление?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы сопоставим ваши переопределения со стандартными настройками шаблона, отметим места, которые сбросятся при следующем релизе, и вернём фиксированную смету в часах. Аудит без оплаты, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-multi-page-redesign-pediatric-dental-87-days/ title: Детский стоматологический редизайн — 3 страницы, через черновик type: case_study date: 2025-11-13T11:22:52+00:00 case_industry: Здравоохранение case_type: Редизайн case_practice: wordpress --- ## Подход к редизайну Действующий сайт клиники на Divi, 3 страницы перерисовываем через черновик — и на первом же проходе по главной странице изменение стиля просочилось в общий глобальный хедер и сломало все страницы домена. Сайт откатили на предыдущий день за 15 минут; каждую следующую страницу собирали в клонированном тестовом окружении. Работа через черновик была требованием агентства; сборка сначала в тестовой среде стала нашей — этого потребовало то, как глобальная область видимости Divi ведёт себя на рабочем сайте детской стоматологии. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Детская стоматология Конечный клиент Guadalupe Kids Dental (детская стоматологическая клиника, Seguin, TX) **Формат сотрудничества** **White-label многостраничный редизайн для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Многостраничный редизайн с переносом дизайна из Figma в Divi — сборка через черновик, публикация страницы после проверки агентства Объём работ **3 страницы** — Главная, New Patients (`/new-patients/`), Special Needs (`/special-kids/`) Сроки ~87 дней (февраль – май 2025) Трудозатраты **~43 часа** на все страницы и QA — сборка по дизайну · раунды QA · обновление URL и метаданных Команда 5 специалистов (разработчик · разработчик+QA · QA · PM) Передача дизайна Брифы Figma на каждую страницу (собственность агентства; URL дизайнов не раскрыты) Конструктор страниц Divi (Elegant Themes) — существующий конструктор сайта; замена не производилась Технический стек WordPress · Divi · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) **Режим сборки** **Через черновик** — каждая страница создавалась как черновик WordPress, публиковалась на целевой URL после проверки агентства **Сдано** **3 страницы на целевых URL — `/` (главная), `/new-patients/`, `/special-kids/` — проверка агентства пройдена перед каждой публикацией** **Раунды проверки** ≈4 раунда проверки за 87 календарных дней ## Постановка задачи Маркетинговое агентство из США, ведущее проект Guadalupe Kids Dental — детской стоматологической клиники в Seguin, TX — привлекло нас для обновления дизайна 3 страниц по макетам Figma, которые передавались итеративно. Сайт клиники работал на Divi, и агентство чётко обозначило, что работа ведётся в его рамках, без внедрения новой зависимости от другого конструктора. Пациенты детской стоматологии — дети; родители, записывающие их на приём, взаимодействуют с сайтом целенаправленно и по делу — запись на регулярные чистки, изучение вариантов седации, поиск страницы Special Needs для ребёнка с особыми потребностями. Каждая из перерабатываемых страниц была точкой входа для одного из этих сценариев. Модель работы агентства на этом проекте была итеративной: сначала главная, затем New Patients, затем Special Needs — каждая сдавалась последовательно, по своему макету Figma, и утверждалась независимо перед публикацией. Работа через черновик была ожидаемой моделью поставки на всём протяжении. Сайт был в работе и принимал записи; ни одна страница не должна была публиковаться в процессе сборки, и ни одно изменение не должно было затрагивать общие глобальные компоненты — хедер, футер или глобальные стили темы — без явного подтверждения. Задача на каждой странице была одинаковой: точно воспроизвести Figma в Divi, собрать в черновике, провести внутреннее QA на большом экране и мобильных устройствах, передать на проверку агентству и опубликовать только после утверждения. Оставаться вне контура коммуникации с конечным клиентом на всём протяжении. > **Контекст рисков.** Divi — это конструктор страниц с глобальной областью видимости: его настройки темы и система глобальных модулей означают, что стиль, применённый при редактировании страницы, может незаметно унаследоваться в хедер или футер сайта — на всех страницах рабочего домена. В отличие от архитектуры Elementor с областью виджетов, глобальные контейнеры Divi всегда соседствуют с холстом страницы. На первом проходе сборки главной страницы правило стиля неожиданно распространилось в общий хедер, вызвав поломку вёрстки на всём сайте. Команда заметила это до передачи агентству, откатила сайт на бекап предыдущего дня и пересобрала главную страницу в клонированном тестовом окружении. Все последующие редизайны страниц на этом проекте выполнялись сначала на тестовом клоне, с проверкой глобальной области видимости до того, как какие-либо изменения касались рабочего сайта. Гибкость Divi реальна; так же реален и объём, который она открывает, когда процесс сборки не выстроен под неё. ## Как мы это сделали **1. Пересборка главной страницы на клонированном тестовом окружении после инцидента с глобальной областью видимости.** Первый проход сборки обновлённой главной страницы мы вели прямо на рабочем сайте через Divi. В ходе этого прохода изменение стиля модуля Divi распространилось в общий глобальный хедер — затронув все страницы сайта, а не только перерабатываемую главную. Сайт откатили на подтверждённо чистый бекап. С этого момента сборка главной страницы продолжилась на клонированном тестовом окружении, а основной сайт оставался нетронутым до полной проверки редизайна в изоляции. Готовый черновик главной страницы затем вывели в работу и опубликовали только после того, как проверка агентства подтвердила его чистоту. Это была не мелкая корректировка процесса — она определила подход к оставшимся 2 страницам. Каждую задачу редизайна на этом проекте мы вели по принципу сборки на тестовой среде, считая глобальную область видимости Divi ограничением, а не допущением. **2. Страница New Patients — сборка черновика по Figma, адаптивная вёрстка без мобильных макетов.** Страница New Patients (`/new-patients/`) была второй задачей редизайна со своим собственным брифом Figma. В брифе не было макетов для мобильных устройств; адаптивную вёрстку делали по стандартным точкам адаптации Divi и по требованиям агентства к мобильным раскладкам. Страница создавалась как черновик WordPress и была доступна только вошедшим администраторам в процессе разработки. QA на большом экране и планшете выявило несколько правок вёрстки — масштаб заголовков, размер кнопок и поведение на точке адаптации 1024 px — до передачи страницы на проверку агентству. Агентство проверило черновик и утвердило его к публикации с небольшими финальными правками перед запуском. **3. Страница Special Needs — итеративная сборка с изоляцией черновика и дисциплиной публикации URL.** Редизайн страницы Special Needs имел особое ограничение: у клиники уже была опубликованная страница по другому slug (`/special-needs-new/` в процессе разработки, заменяющая опубликованную `/special-kids/`). Черновик разработки держали на отдельном slug на всём протяжении сборки и QA — намеренная изоляция черновика, чтобы переработанная и существующая опубликованная страница могли ужиться без сбоев в работе последней. После прохождения QA задача публикации включала установку URL новой страницы как `/special-kids/`, перевод старой страницы в статус черновика и подтверждение соответствия Title, Description и slug спецификации. Попытка обновить Divi Builder в ходе этой задачи упёрлась в проверку аутентификации Elegant Themes — двухфакторная аутентификация для новых устройств заблокировала обновление, и решать пришлось внешними средствами. Страницу опубликовали после подтверждения корректности URL и метаданных. **4. Координированное QA на разных форматах экрана конструктора страниц и мобильных устройств.** Для каждой страницы заводили отдельную задачу QA (отдельно от задачи сборки), назначенную на Павла Сажина. QA охватывало большой экран и мобильные устройства, рендеринг модулей Divi на стандартных точках адаптации, а также работу форм и загружаемых ресурсов — страница Special Needs содержала загружаемые формы, перенесённые с предыдущей версии страницы. Рендеринг для мобильных устройств получил дополнительное внимание на каждой странице, учитывая, что родители, записывающие детей к стоматологу, активно пользуются мобильными устройствами. Для каждой страницы раунды QA проводились до передачи агентству; правки после проверки агентства отслеживались через задачу сборки. Сборка главной страницы на рабочем сайте привела к тому, что общий хедер впитал стили с холста новой страницы — все страницы сайта сломались. У нас было 15 минут, мы откатились на предыдущий день и пересобрали в клонированном окружении. Протокол работы в тестовой среде, который покрывал все последующие страницы на этом проекте, появился именно из-за этого инцидента. ## Контроль качества Проход сборки главной страницы на этом проекте выявил регрессию на рабочем сайте до того, как хотя бы 1 страница дошла до агентства — изменение стиля модуля Divi распространилось в общий глобальный хедер, загрязнив все страницы сайта; сайт был откачен на бекап предыдущего дня, и все последующие сборки выполнялись в клонированном тестовом окружении для сдерживания глобальной области видимости Divi. QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Приёмочный контур агентства выполнялся после передачи и сводил замечания в общую очередь правок для нашего цикла исправлений, пока агентство не подписало приёмку. ## Результаты Метрика Результат Страниц переработано **3** — Главная, New Patients (`/new-patients/`), Special Needs (`/special-kids/`) Режим сборки **Через черновик** — каждая страница создавалась как черновик WordPress, публиковалась только после проверки агентства Инцидент глобальной области видимости Поломка хедера на всём сайте обнаружена до передачи; сайт откачен; последующая работа — в тестовой среде Дисциплина публикации URL URL `/special-kids/` и метаданные подтверждены перед публикацией; старая страница переведена в черновик Покрытие QA Большой экран + мобильные на всех 3 страницах; планшетная точка адаптации (1024 px) отдельно проработана на New Patients Сроки **~87 дней** (февраль – май 2025) — итеративный, постраничный ритм поставки Трудозатраты **~43 часа** на сборку, QA и задачи по URL/метаданным Команда 5 специалистов — без отдельного аналитика, без лида по дизайну (собственность агентства) Статус сайта, проверено 2026-04 [seguinkidsdental.com](https://seguinkidsdental.com/) работает, HTTP 200 ## Процесс Этап Длительность Результат Получение Figma-брифа главной + оценка ~1 неделя (фев 2025) Дизайн рассмотрен; Divi подтверждён как существующий конструктор; ограничения глобальной области видимости отмечены Сборка главной — пересборка в тестовом окружении ~2 недели (фев–мар 2025) Главная собрана на тестовом клоне после инцидента с глобальной областью видимости; выведена в работу после отката; проверка агентства в ожидании Сборка New Patients + QA ~2 недели (апр 2025) New Patients собрана как черновик, адаптивное QA завершено, передано агентству; незначительные правки; опубликована Сборка Special Needs + QA ~2 недели (апр–май 2025) Special Needs собрана как черновик на отдельном slug, QA завершено; проблема аутентификации Divi решена внешними средствами Публикация URL + финальные метаданные ~1 неделя (май 2025) URL `/special-kids/` назначен, старая страница переведена в черновик, Title/Description подтверждены; проект закрыт _Этапы на этом проекте последовательны — каждая страница завершалась и утверждалась до начала следующей. Итеративный ритм был явным предпочтением агентства для этого клиента._ ## Команда **Команда проекта** - **Никита Тумашевич** — сборка главной страницы (Divi, пересборка в тестовом окружении), сборка New Patients, сборка Special Needs - **Павел Сажин** — QA всех 3 страниц (большой экран и мобильные, рендеринг модулей Divi, функциональность форм) - **Анна Полунина** — поддержка реализации и QA - **Людмила Травкина** — реализация редизайна главной (первый проход и пересборка); адаптивная вёрстка New Patients - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, координация аутентификации Divi, финальное подписание публикации) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне агентства-партнёра на всём протяжении. Наша команда была невидима для конечного клиента. Все дизайн-решения — макеты Figma, контент страниц, загружаемые ресурсы на странице Special Needs — были ответственностью агентства. Мы получали бриф Figma, реализовывали его в Divi и возвращали черновик на проверку. ## Агентствам, заказывающим редизайн WordPress > При редизайне детской стоматологии визуальная цельность, которую ждут семьи, держится на том, чтобы каждое изменение оставалось в своих границах. У этой практики — один детский кабинет; у других — детская сеть с несколькими филиалами, где одна правка может задеть все страницы. Риски редизайна тихие: новые раскладки заложат длину текста, которая разойдётся с реальным контентом клиники, и карточки услуг сломаются уже при загрузке. URL изменятся без редирект-карты и молча растеряют позиции, которые наработало агентство. Старые типы страниц обойдёт новая система стилей — сайдбары и архивы останутся в прежнем оформлении. Подрядчику стоит задавать не «перерисуете ли страницы?», а «как вы сохраните структуру URL и справитесь с расхождением по длине контента?» Пришлите макеты или текущий перечень URL. Мы сверим дизайн с реальной длиной вашего контента и существующими типами страниц, найдём пропуски в редиректах и вернём смету в фиксированных часах. Аудит за счёт нашей стороны, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-39-pages-14-days/ title: Ребилд сайта стоматологии на 39 страниц со 113 редиректами — white-label WordPress за 14 дней type: case_study date: 2025-11-06T21:32:35+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Ребилд сайта стоматологической клиники на 39 страниц — со списком редиректов из 113 записей, втрое превышающей количество страниц. Предыдущий сайт генерировал вложенную иерархию URL, которую агентство решило «сплющить» в плоские пути. Мы перестроили каждую контентную страницу и реализовали каждый редирект по карте сайта агентства строка за строкой — сдали за 14 дней при 46 часах работы, без перерасхода. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — общая и косметическая стоматология Конечный клиент Brilliant Dental Care (общая и косметическая стоматология) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Kinsta (та же CMS) Объём Полный ребилд сайта — 39 контентных URL мигрированы в чистую плоскую архитектуру, реализовано 113 редиректов Сроки 14 дней (2–16 июня 2025), по графику Затраты 46 часов при оценке в 46 часов — без перерасхода Команда 5 специалистов (Евгений Карпов — разработчик; Никита Тумашевич — ведущий QA; Павел Сажин — QA и исправления; Антон Херсун — руководитель проекта) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Разница контента оригинал-ребилд устранена до передачи — ни одного пропущенного текста, ни одной битой внутренней ссылки, ни одного структурного расхождения **Сдано** **ТЗ соблюдено строка за строкой — 30 контентных URL перестроены в плоскую архитектуру, 113 редиректов реализованы по спецификации, 29 задач из очереди SEO и CX закрыты, 30-пунктный контрольный список запуска выполнен** **Ритм взаимодействия** 27 задач от агентства · все закрыты к моменту передачи (активный период — 29 дней, 16.06.2025–14.07.2025) **Раунды проверки** ≈3 раунда проверки в рамках 14-дневного окна **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи Агентство вело клиента из сферы стоматологии на постоянной основе; сайту клиента на WordPress требовался ребилд на новом стеке Kinsta. Исходный сайт накопил архитектурный долг: страницы услуг находились в разделе `/services/`, страницы врачей и офиса — в `/our-office/`, информация для пациентов — в `/patient-resource/`, страницы технологий — в `/technology/`. ТЗ на ребилд предписывало свернуть все эти разделы в плоскую структуру URL — каждая страница услуги получает путь верхнего уровня — с сохранением существующего домена. Одна эта реструктуризация породила основную таблицу редиректов. Но прежняя платформа также создала второй слой составных URL-артефактов: пути вида `/implants/privacy-notice`, `/digital-cone-beam-scan/services/cerec`, где к слегам услуг были прицеплены ссылки из подвала и карты сайта — так возникло ещё 70+ путей, которые необходимо было корректно разрешать. Спецификация охватила оба слоя. Наша задача — реализовать их оба в полном объёме. Агентство также использовало интеграцию со сторонним планировщиком (adit.com), встроенную на страницу записи на приём. Это была не стандартная контактная форма Gravity Forms — это был JavaScript-виджет, привязанный к домену, для инициализации которого требовалось внести действующий домен клиента в список разрешённых платформы. Эта зависимость была зафиксирована в очереди задач и решена после переключения на действующий домен. > **Контекст рисков.** Когда ребилд «сплющивает» вложенную структуру URL, список редиректов оказывается пропорционально больше объёма контента — в данном случае 113 редиректов на 39 контентных страниц. Ошибка кроется не в самих страницах плоской структуры, а в длинном хвосте составных путей, сгенерированных внутренней перелинковкой и навигационной логикой предыдущего сайта. Пациент, добавивший в закладки `/services/implants`, поисковый индекс, просканировавший `/our-office/meet-the-doctor`, ссылка в подвале, автоматически дописывающая `/privacy-notice` к любому слегу страницы, — всем этим путям требовался явно указанный пункт назначения. Пропущенная запись незаметна на тестовой среде и проявляется как 404 на рабочем сайте, после переключения, на трафике, которого агентство не могло ожидать. ## Как мы это сделали **1. Сборка на основе шаблона.** Карта сайта агентства содержала все 39 контентных URL. Вместо того чтобы строить страницы по отдельности, мы создали единый шаблон страницы — «Original Template» — и применили его единообразно к главной, страницам услуг, служебным страницам и блогу, следуя референс-дизайну исходного сайта. Плоская архитектура сделала систему шаблонов чистой: 1 страница биографии врача, 1 страница команды, 1 формат страницы услуги — применён к 24 страницам стоматологических услуг и технологий. **2. ТЗ соблюдено строка за строкой, по таблице агентства.** Таблица Google Sheets агентства содержала полную карту URL — 39 строк контента и 113 строк редиректов, каждая с текущим путём, новым путём и колонкой проверки Redirect OK. Мы реализовали каждую строку как написано. Там, где редирект был помечен как «Redirect OK» в столбце статуса таблицы, мы подтвердили, что в тестовой среде он разрешается так же. Две строки с пометкой «wrong redirect» на путях технологического подраздела — выявили на QA, отметили для агентства и исправили. Виджет планировщика на странице `/book-an-appointment/` породил зависимость от регистрации домена: платформа adit.com требовала внесения действующего домена в список разрешённых для корректной инициализации встраиваемого элемента. Это не ошибка разработки — домены тестовой среды невозможно зарегистрировать заранее. Проблему задокументировали, сообщили и решили после переключения. **3. Проверка на основе обхода, а не «на глаз выглядит нормально».** Перед передачей тестовой среды мы прогнали Screaming Frog как по исходному сайту, так и по ребилду на тестовой среде. Коды статуса, цепочки редиректов, соответствие мета-тегов, битые ссылки — каждое расхождение сверено со спецификацией. 24 задачи из очереди SEO и 5 задач из очереди CX, открытые QA-командой агентства 16 июня, мы закрыли до цикла поддержки в июле. **4. Контрольный список запуска на 30 пунктов, закрыт до передачи.** Пять категорий: дизайн, функциональность, контент, SEO и аналитика, адаптивность и прочие пункты по сайту. Каждую точку адаптации проверили — ребилд везде на относительных единицах размеров, что, по подтверждению QA-проверки, дало чистую адаптивную вёрстку на настольном экране, ноутбуке, планшете и мобильных. Ничего не сдавали, пока не согласовали контрольный список. Карта редиректов была готова раньше всего остального — 113 записей необходимо было нанести на карту и разместить на тестовой среде до того, как QA могла подтвердить корректное разрешение хотя бы одной контентной страницы. В этом и заключался подход. Проход по таблице Google Sheets строка за строкой, со сверкой каждой ячейки «Redirect OK» с результатами обхода тестовой среды, означал, что сборка контента велась на проверенном фундаменте, а не догоняла пропущенные редиректы при переключении. ## Результаты Метрика Результат Точность по ТЗ — контентные URL **39 / 39** контентных страниц сданы в плоской архитектуре Точность по ТЗ — редиректы **113 / 113** редиректов реализованы по спецификации Очередь задач SEO **24 / 24** задачи закрыты Очередь задач CX **5 / 5** задач решены Контрольный список запуска **30 / 30** пунктов согласованы до передачи Сроки **14 дней**, сдано по графику Затраты **46 ч / 46 ч** по оценке — без перерасхода, без расширения объёма Проверка адаптивности Ноль проблем с вёрсткой на проверенных настольных, ноутбучных, планшетных и мобильных устройствах После запуска 19-дневный обзор после запуска (июль–август 2025) — мелкие правки, без регрессий Статус сайта, проверено 04.2026 [brilliantdentalcare.com](https://brilliantdentalcare.com/) работает в штатном режиме Карта редиректов агентства — охватывающая и запланированную архитектурную реструктуризацию, и наследие составных путей предыдущей платформы — встала на боевом сайте без пропусков. ## Контроль качества Предварительное QA запустило сравнение обходов Screaming Frog ребилда на тестовой среде с оригиналом, сверив соответствие URL, заголовков и мета-описаний по всем 39 контентным страницам и 113 редиректам — сравнение выявило две строки редиректов на путях технологического подраздела, где разрешение на тестовой среде не соответствовало заявленному пункту назначения; обе исправлены до того, как агентство увидело сборку. Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и пороге нулевых ошибок. Свой контроль на стороне агентства запускался после передачи и сводил замечания в общую очередь правок для нашего цикла исправлений до момента согласования с агентством. ## Процесс Этап Длительность Результат Бриф и оценка 2 дня ТЗ агентства проанализировано; оценка 46 ч согласована; объём 113 редиректов подтверждён Разработка ~10 дней 39 контентных страниц построены в плоской архитектуре; 113 редиректов реализованы Внутреннее QA и проверка ~2 дня Проверка обходом завершена; 2 расхождения в редиректах по таблице Google Sheets отмечены и исправлены Проверка по ТЗ 1 день Соответствие мета-тегов и редиректов сверено; 30-пунктный контрольный список закрыт Сдача и передача на тестовую среду 1 день Ребилд сдан на тестовую среду Kinsta; очередь задач открыта агентством в день передачи После запуска 19 дней Мелкие правки по замечаниям агентства решены; интеграция виджета планировщика подтверждена на действующем домене _Фазы разработки и QA шли параллельно в последние дни сборки, сжав календарь до 14 дней._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий QA (проверка тестовой среды, проверки на основе обхода) - **Павел Сажин** — исправления по QA и проверка передачи - **Анна Полунина** — поддержка разработки и QA по перестроенным страницам - **Евгений Карпов** — разработчик (полная сборка сайта, система шаблонов, реализация редиректов) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, координация очереди задач) Агентство оставалось публичным подрядчиком на протяжении всего проекта; конечный клиент нас не видел — от сборки в тестовой среде до правок после запуска. Решения по реструктуризации URL, стратегия редиректов и требования к интеграции платформы планирования оставались на усмотрение агентства; наша роль заключалась в реализации ТЗ в том виде, в каком оно было предоставлено, и в отметке каждого расхождения для агентства вместо самостоятельного исправления. ## Агентствам, заказывающим ребилд WordPress > На ребилде стоматологической практики структурный риск — это карта редиректов: пропущенный маршрут оборачивается 404 на том трафике, на который агентство рассчитывает. Здесь это сетевая клиника с филиалами и глубокими путями услуг; в другом проекте — кабинет в одном офисе с сайтом-визиткой. Старые URL, на которых агентство наработало позиции, после переключения отдадут 404. Страницы услуг из закладок выпадут из индекса. Пути в подвале, порождённые навигацией, погаснут. Подрядчику стоит задавать не вопрос «сможете ли сделать ребилд?», а вопрос «как именно вы добьётесь, что каждый старый URL разрешается после переключения?» Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы бесплатно разберём вашу карту редиректов, отметим записи, где пункт назначения неоднозначен или отсутствует, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-51h-53-days/ title: Новая разработка стоматологического сайта на WordPress (86 страниц) за 53 дня type: case_study date: 2025-11-01T17:50:29+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 86 страниц новой разработки на WordPress с Elementor: повторили существующий сайт стоматологической клиники и сверили все 86 URL по базе из трёх обходов Screaming Frog — оригинал, тестовая среда и рабочий домен — перед запуском. Сдали за 53 дня при 51 часе, в рамках построчной сметы таблицы на 50 часов; контрольный список из 49 пунктов закрыт, очередь правок агентства проработана до приёмки перед сдачей. Этот кейс — описание такой разработки-копирования, выполненной для маркетингового агентства из США в сегменте общей стоматологии. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — общая стоматология Конечный клиент Sopris Smiles (Englewood, CO) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка на WordPress с Elementor на WP Engine — один индивидуальный шаблон дизайна, копирующий существующий сайт Объём **86 URL** — главная, 22 страницы услуг, 2 страницы «О нас», технология, отзывы, новые пациенты, финансирование, FAQ, контакты, 50 постов блога, плюс 4 страницы пагинации блога Сроки 53 дня (3 янв – 25 фев 2025), сдано по графику Трудозатраты **51 час** при смете 50 часов — без перерасхода Команда 3 специалиста (Людмила Травкина · ведущий разработчик, Никита Тумашевич · QA и исправления, Антон Херсун · руководитель проекта) Шаблоны **1 собственный шаблон** — фреймворк Original Design агентства Технологии WordPress · Elementor · Gravity Forms · WP Engine · Rank Math · Screaming Frog · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Результат** **86 URL разработаны на одном собственном шаблоне агентства, база Screaming Frog сверена с оригинальным сайтом, контрольный список запуска из 49 пунктов закрыт, 7 / 14 пунктов очереди правок доведены до Completed** **Интенсивность** 13 задач от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈4 раунда проверки за 53 календарных дня **Контрольный список запуска** 49 пунктов, согласованы перед запуском ## Постановка задачи Маркетинговое агентство из США, работающее с Sopris Smiles — клиникой общей стоматологии в Энглвуде, Колорадо, — передало нам таблицу Google Sheets с полной картой сайта, обходом Screaming Frog оригинального сайта и контрольным списком запуска из 49 пунктов. Существующий сайт находился на внешнем хостинге; новая разработка размещалась на тестовой среде WP Engine. Page builder — Elementor; формы — Gravity Forms. Задача заключалась в том, чтобы повторить все 86 URL в новом окружении, сохранив оригинальный дизайн-язык, мета-данные и структуру контента, и затем закрывать очередь правок агентства, пока разработка не совпадёт с оригиналом попиксельно и по обходу. Риск, от которого агентство страховалось, был не в том, можно ли разработать 86 страниц — а в том, будет ли партнёр-разработчик относиться к исходному сайту как к точному ТЗ. Существующий сайт — одновременно источник истины и носитель собственных ошибок. Агентству нужен был партнёр, который скопирует то, что правильно, выявит то, что сломано, и исправит это без внесения новых расхождений. Бриф исходил именно из этой задачи: построчная карта сайта, база Screaming Frog и поэтапный цикл исправлений после первого прохода. > **Контекст рисков.** При разработке, копирующей существующий сайт, оригинал — это ТЗ, но он также может быть источником унаследованных дефектов. Например, страница чистки зубов на оригинальном сайте содержала контент об элайнерах, который был неверен в течение неизвестного периода. Партнёр-разработчик, копирующий без проверки, воспроизводит эти ошибки незаметно. Риск не в создании страниц; риск в создании страниц, которые точно копируют ошибки, которые агентство не намеревалось сохранять. Предсказуемость важнее изобретательности — это означает проверку оригинала перед копированием. Исходный сайт в работе не был доступен для прямого редактирования — у команды не было доступа для исправления его ошибок контента, пока новая разработка не оказалась на тестовой среде — поэтому унаследованные дефекты приходилось каталогизировать в процессе разработки и исправлять в цикле доработки и исправлений. ## Как мы это сделали **1. Один собственный шаблон, 86 страниц, один процесс копирования.** Весь сайт Sopris Smiles мы разработали на шаблоне Original Design агентства — едином фреймворке, применённом ко всем 86 URL. Карта сайта назначала шаблон каждой строке: 22 страницы услуг, 50 постов блога, главная, страницы «О нас», технология, отзывы, финансирование, FAQ, контакты и страницы пагинации блога. Ни одной страницы не делали вручную вне системы шаблонов. **2. ТЗ выполнено строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Сумма составила согласованные 50 часов на основную разработку, с минимальным добавлением на цикл исправлений. Коротко: при разработке с предварительно оценённой картой сайта таблица — это контракт. Задача команды разработки — уложиться в согласованную смету, а не открывать заново разговор о цене страница за страницей. **3. Сравнение с базой Screaming Frog по оригиналу, тестовой среде и рабочему домену.** В таблице были три вкладки обхода Screaming Frog — оригинальный сайт, тестовая среда и новый рабочий домен — плюс вкладка Compare Meta, сопоставляющая старые и новые заголовки. Мы использовали эти базы, чтобы проверить, что каждый URL, заголовок и meta description с оригинального сайта учтены в новой разработке. Там, где оригинал уже содержал ошибки — например, страница чистки зубов с контентом об элайнерах, — мы выносили несоответствие в очередь правок, а не копировали вслепую. Мы выбрали проверку на основе обхода, а не ручную постраничную проверку, потому что сравнение Screaming Frog по трём окружениям — оригинал, тестовая среда и рабочий домен — обеспечивало документируемую проверку соответствия всех 86 URL, которую было бы непрактично воспроизводить вручную. **4. QA в два потока, закрытый через цикл доработки и исправлений.** Задачи отслеживались во вкладке очереди правок агентства (14 строк, приоритеты от Medium до Urgent, охватывающие favicon, мета-данные, очистку футера, загрузку видео, структуру H1 блога, единые правила слешей и исправления слагов). Из этих 14 пунктов 7 закрыты как Completed до первой сдачи; оставшиеся — включая несоответствия meta title и отсутствующую страницу блога — мы решили уже после сдачи, в цикле доработки и исправлений, который отслеживали в Redmine. Контрольный список запуска из 49 пунктов — дизайн, функциональность, контент, SEO и аналитика, адаптивность и разное — закрылся по обоим направлениям. Запуск Screaming Frog последовательно на всех трёх окружениях — оригинал, тестовая среда, рабочий домен — до эскалации любого спора о контенте означал, что каждое расхождение документируемо. Страница чистки зубов с контентом об элайнерах была в архиве с самого начала; знание этого превратило исправление в переименование URL, а не в оспариваемое переписывание. Именно порядок обхода не позволил циклу доработки и исправлений превратиться в переговоры. ## Результаты Метрика Результат URL разработано **86** на 1 собственном шаблоне агентства (1 главная · 22 страницы услуг · 2 страницы «О нас» · 1 технология · 1 отзывы · 1 новые пациенты · 1 финансирование · 1 FAQ · 1 контакты · 1 лендинг блога · 4 пагинации блога · 50 постов блога) Шаблонов применено **1 / 1** — собственный шаблон Original Design агентства Проверка по базе Screaming Frog Оригинальный сайт, тестовая среда и рабочий домен просканированы и сравнены; вкладка Compare Meta использована для проверки заголовков по 33 URL Очередь правок **7 / 14** закрыты как Completed; оставшиеся пункты решены через цикл доработки и исправлений после сдачи Контрольный список запуска **49 пунктов** согласованы по категориям: дизайн / функциональность / контент / SEO и аналитика / адаптивность / разное Сроки **53 дня** (основная разработка + цикл доработки и исправлений), сдано по графику Трудозатраты **51 ч / 50 ч** смета — без перерасхода, без расширения объёма **Статус сайта** В работе на WP Engine: `https://www.soprissmiles.com/` — проверено в апреле 2026. Если коротко: 86 URL новой разработки для агентства сданы на одном шаблоне в рамках сметы на 50 часов. База Screaming Frog подтвердила соответствие оригинальному сайту, очередь правок и цикл доработки закрыты до приёмки агентством, контрольный список запуска согласован до выхода сайта на рабочий домен. ## Контроль качества Проверка перед сдачей ссылок — запущенная с приоритетом Urgent — проанализировала все 86 URL в сборке на тестовой среде и выявила HTTP-ссылки, всё ещё указывающие на хост тестовой среды, и некорректный tel: href, где отображаемый номер (303-761-2999) не совпадал со значением href (303-781-4440); оба исправлены до того, как сборка покинула тестовую среду. Проверку перед сдачей вёл **Site Checker** — см. [наш подход к QA](/site-checker/) с категориями и порогом нулевых ошибок. Агентство проверяло отдельно уже после сдачи и записывало замечания в общую очередь правок, которую мы закрывали до их согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Таблица проверена, база Screaming Frog подтверждена, 50 ч оценены и согласованы Разработка (страницы + шаблон) ~3 недели Все 86 URL разработаны на шаблоне Original Design на тестовой среде WP Engine Цикл доработки и исправлений ~4 недели Пункты очереди правок, несоответствия meta title и расхождения контента решены через раунды проверки агентства Проверка обходом + контрольный список ~1 неделя Сравнение старого и нового сайта Screaming Frog завершено; контрольный список запуска из 49 пунктов согласован Сдача Финальные дни Сайт запущен на WP Engine _Этапы пересекались — цикл доработки и исправлений начался до полного закрытия проверки обходом, поэтому календарный срок составляет 53 дня, а не сумму последовательных этапов._ ## Команда **Команда проекта** - **Людмила Травкина** — ведущий разработчик на этапах разработки и цикла доработки и исправлений - **Никита Тумашевич** — итерации QA, исправления и закрытие очереди правок - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом и коммуникация с клиентом со стороны агентства оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На новой сборке сайта стоматологической практики структурный риск для агентства-заказчика — не срок: риск в том, что дефекты исходного сайта перейдут в новый продукт без вашего ведома. У этой практики профиль простой — приём и косметическая стоматология в одной точке; у других сеть с несколькими адресами и отдельными хирургическими направлениями. Если разработчик берётся без аудита ТЗ: устаревшее описание услуги появится на нескольких страницах нового сайта — клиент заметит рассинхрон, разбираться придётся вам; таксономия закрепится по старому списку услуг и не примет правок; заработанные позиции исходного сайта не перенесутся, потому что их никто не разметил под новую структуру. Подрядчику стоит задавать не вопрос «соберёте ли страницы по нашему макету?», а вопрос «как именно вы проверите, что каждый блок нового сайта не переносит ошибки исходного ТЗ, которые мы сами не заметили?» Пришлите адрес действующего сайта, макеты или черновик карты сайта. Мы проведём аудит вашего ТЗ и исходного сайта — отдельно выпишем все скрытые несоответствия контента, разметки и архитектуры, которые могут тихо переехать в финальную сборку. Вернём фиксированную смету в часах. Аудит ничего не стоит — смета приходит в часах, не в диапазоне. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-65-page-dental-41-days/ title: Доработка темы для многопрофильной стоматологии на 65 страниц за 41 день type: case_study date: 2025-10-31T04:37:23+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 65 страниц доработки темы многопрофильной стоматологии на Template 6 агентства плюс 25 реструктуризаций URL услуг — с плоских устаревших путей в пятиветвевую таксономию подспециальностей. Работа по архитектуре URL шла отдельной параллельной задачей в Redmine — #165, проверка ссылок, — и мы закрыли её независимо до основной передачи: неверно настроенный редирект на любом из 25 перемещений обрушил бы устоявшиеся поисковые пути пациентов. ## Краткий обзор Параметр Значение Сфера клиента Медицина — многопрофильная стоматология общего профиля Клиент Dental Associates of Jersey City (Jersey City, NJ) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (Template 6 агентства на WP Engine) Объём **65 страниц** — главная, страница услуг, 42 страницы услуг, 22 вспомогательные страницы (о нас, контакты, запись, галерея, персонал, образовательные ресурсы); плюс 132 унаследованных поста блога перенесены Сроки 41 день (23 янв – 5 мар 2025), в срок Затраты 40 часов — разработка, QA-итерации и управление проектом Команда 6 специалистов Шаблоны **5 переиспользуемых шаблонов** — Главная, Страница услуги, О нас, Блог и шаблон по умолчанию — применены на 65 страниц Технологии WordPress · Elementor · WP Engine · Rank Math SEO · Gravity Forms · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **Контрольный список запуска на 45 пунктов** согласован по этапам до и после миграции; после запуска — правки на согласование бренд-цветов и правки контента от клиента **Ритм взаимодействия** 5 задач от агентства · 3 из 5 закрыты к моменту передачи **Раунды проверки** ≈3 раунда за 41 день **Контрольный список запуска** 45 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам площадку на WP Engine и свою конфигурацию Template 6 для Dental Associates of Jersey City. Свою часть агентство уже сделало — согласовало дизайн, настроило хостинг, подготовило контент-план. Нужна была команда разработки, которая точно перенесёт шаблон по спецификации агентства на сайт заметно крупнее и сложнее, чем типичная однопрофильная стоматология. Dental Associates of Jersey City работает по пяти клиническим направлениям — общая стоматология, пародонтология, эндодонтия, ортодонтия и косметическая стоматология — каждое со своими подстраницами процедур. Старый сайт накапливал эти страницы годами под плоскими slug верхнего уровня (`/arestin`, `/biopsy`, `/bridges`, `/crowns` и так далее). Шаблон агентства требовал перестроить эти URL в дерево подспециальностей: `/periodontic/periodontal-disease/arestin/`, `/dental-implants/bridges/`, `/endodontic/apicoectomy-surgery/` и так далее — всего 25 затронутых страниц. Задача была чисто исполнительская. Применить шаблон, перестроить URL, отработать контрольный список запуска на 45 пунктов и заводить находки QA в общее пространство задач агентства. Не закрывать без подтверждения. > **Контекст рисков.** Многопрофильная практика с живой базой пациентов и 25 устаревшими URL, переезжающими из плоских путей в таксономию подспециальностей, несёт характерный риск: реструктуризация выглядит правильно на тестовой среде, но тихо теряет покрытие редиректами на путях, которые постоянная аудитория давно сохранила в закладках или на которые уже ссылаются сторонние каталоги. Страница `/bridges`, корректно перенаправляющая на `/dental-implants/bridges/` в тестовой среде, сломается, если редирект неверно настроен при DNS-переключении — или если внутренние ссылки по-прежнему ведут на старый slug. При 25 изменениях URL по пяти ветвям подспециальностей — пародонтология, эндодонтия, ортодонтия, дентальная имплантация, косметическая стоматология — пропустить редирект или оставить старую внутреннюю ссылку было вполне реально. От этого риска агентство и страховалось, для этого мы и завели задачу проверки ссылок и полное сравнение обходов Screaming Frog, зафиксированные в контрольном списке. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Template 6 агентства задавал базовую структуру страниц. Наша задача — доработать его под спецификацию агентства страница за страницей: где стандартный макет шаблона совпадал со спецификацией, мы его оставляли; где спецификация требовала отклонения, мы дорабатывали. Никакие дизайнерские решения не исходили от нас. **2. Реструктуризация URL как полноценный результат.** Перестройка 25 URL страниц услуг из плоских путей в пятиветвевую таксономию подспециальностей — это не косметика, а структурный фундамент нового сайта. Каждой затронутой странице нужен был и новый целевой URL, и редирект со старого slug. Реструктуризацию URL мы вели отдельным направлением, не объединяя её с доработкой шаблона в одну задачу сборки: каждый перенаправленный путь требовал отдельной проверки — неверно настроенный редирект на любом из 25 перестроенных URL обрушил бы сложившееся поисковое присутствие практики. Проверку ссылок мы вели параллельно основной разработке и держали карту внутренних ссылок согласованной до передачи, а не правили её после запуска. **3. QA-цикл в масштабе доработки темы.** Качественная доработка темы — это не «собрал один раз, проверил один раз». За время проекта контрольный список запуска на 45 пунктов охватывал совместимость браузеров, целостность навигации, уведомления контактных форм, отображение изображений и видео, точность мета-данных, сравнение обходов Screaming Frog с исходным сайтом, проверку редиректов и адаптивность на разных форматах экрана. Список проходили в два этапа — до и после миграции — и каждый пункт подписывали отдельно, прежде чем разрешить запуск сайта. Первую передачу мы выполнили с бренд-цветами, заданными постранично, а не глобально: до того как запланировали общесайтовое развёртывание, шаблон дорабатывали под PPC-посадочную страницу. Этот пробел всплыл после запуска — отдельной задачей: раскатать цвет по всем 65 страницам. **4. Исправления после запуска.** После первой передачи агентство завело через общий список правок две новые задачи: коррекцию бренд-цвета на отдельной странице, которая разрослась до общесайтового обновления цветов, и сводный список клиентских правок контента (обновления данных о врачах, замены фотографий, поведение галереи, точность часов работы, рекламные тексты). Каждый раунд закрывали только после того, как рецензент агентства подтверждал, что исправление готово. **5. Проверка на разных устройствах.** Доработки проходили QA в Chrome, Firefox, Safari и Edge на больших экранах, планшетах и мобильных форматах. Каждый QA-раунд охватывал страницы, затронутые изменениями этого раунда, — так сборка с большим числом страниц остаётся управляемой без потери покрытия. Параллельная задача проверки ссылок и держала в безопасности 25 перемещений URL. По ходу разработки стало ясно: покрытие редиректами требует собственного направления, не смешанного с основной задачей сборки. Поэтому проверку ссылок вели отдельным направлением, параллельно, и закрыли её независимо до передачи. Без этого разделения неверно настроенный редирект на любой из пяти ветвей подспециальностей всплыл бы как исправление после запуска, а не как предварительная проверка. ## Контроль качества До сдачи QA держался на целостности URL — 25 перемещений из плоских во вложенные пути по пяти ветвям подспециальностей шли отдельной параллельной задачей Redmine (#165, проверка ссылок), чтобы подтвердить каждую цепочку до передачи. Общесайтовый пробел бренд-цветов (шаблон изначально развернули в одностраничном PPC-режиме) всплыл после передачи при проверке со стороны агентства и прошёл через цикл исправлений. До сдачи QA проходил через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Внутренний контроль агентства работал после передачи и заводил замечания в общий список правок для нашего цикла исправлений до окончательного согласования. Доработки оставались в клиентских переопределениях; общие компоненты шаблона агентства мы не трогали. Дополнительные проверки, зафиксированные в контрольном списке таблицы Google Sheets: - Обход Screaming Frog исходного сайта сохранён как базовая эталонная копия - Обход Screaming Frog тестовой среды сравнён с исходным для подтверждения URL страниц/постов, title-тегов и meta-описаний - Внутренние ссылки проверены после DNS-переключения (URL тестовой среды заменены на рабочий домен) - Настройки Rank Math SEO проверены - Скрипты Google Analytics / Tag Manager подтверждены на месте ## Результаты Метрика Результат Сдано страниц **65** — 1 главная, 1 страница услуг, 42 страницы услуг, 22 вспомогательные страницы (о нас, контакты, запись, галерея, персонал, образовательные ресурсы, отзывы) Перенесено постов блога **132** поста блога перенесены в шаблон Блога агентства с сохранением URL Применено шаблонов **5 из 5** — Главная, Страница услуги, О нас, Блог, шаблон по умолчанию Реструктуризаций URL **25** перемещений из плоских во вложенные пути по пяти ветвям подспециальностей, каждое с покрытием редиректами Контрольный список запуска **45 пунктов** согласованы (этапы до и после миграции) Сроки **41 день** (23 янв – 5 мар 2025), выполнено в срок Затраты **40 часов** при базовой оценке 36 ч + 4 ч исправлений после запуска Команда **6 специалистов** Передача хостинга Запущено на WP Engine Если коротко: Template 6 агентства мы применили на 65 страницах для пятипрофильной стоматологии, перенесли 132 унаследованных поста блога с сохранением URL, перестроили 25 URL страниц услуг из плоских путей в таксономию подспециальностей и закрыли проект за 41 день при общих затратах 40 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Доступ к шаблону подтверждён, объём реструктуризации URL согласован, оценка 36 ч Доработка темы + реструктуризация URL ~2 недели Постраничная доработка темы; 25 перемещений URL с картой редиректов; задача проверки ссылок выполнена параллельно QA и контрольный список запуска ~1 неделя Контрольный список на 45 пунктов выполнен (до и после миграции); сравнение обходов Screaming Frog; аудит внутренних ссылок Сдача (первоначальная передача) День 22 (14.02.2025) Сайт закрыт как решённый в Redmine; агентство получило сборку Исправления после запуска ~3 недели Обновление бренд-цветов по всем страницам; коррекция данных о врачах и фотографий; исправления галереи и часов работы _Разработка и QA шли параллельно на всём протяжении — задача проверки ссылок была открыта как отдельная задача Redmine и закрыта независимо до передачи основной задачи._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы, реструктуризация URL, сопоставление Figma с макетом) - **Анна Полунина** — разработчик (QA-итерации, проверка дизайна, подбор изображений) - **Евгений Карпов** — разработчик (поддержка QA, проверка ссылок) - **Алексей Мелков** — поддержка внедрения - **Наталия Богатель** — разработчик (правки контента после запуска) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, общение со стороны агентства, согласование) Управление проектом, дизайн, хостинг и общение с клиентом всё это время оставались за партнёрским агентством. Конечный клиент нас не видел: все запросы на доработку приходили через общий список правок агентства, и сама разработка ему напрямую не показывалась. Каждый раунд исправлений закрывали только после того, как рецензент со стороны агентства подтверждал устранение замечаний. ## Агентствам с библиотекой шаблонов > Граница между общим слоем шаблона и слоем клиентских доработок — вот где у агентства живёт риск сдачи. У этой практики это многопрофильная группа под единым набором шаблонов; у кого-то — один кабинет с правками на уровне отдельных страниц. Риски тихие: доработки в дочерней теме отвалятся на следующем обновлении от поставщика шаблона, ACF-схемы разойдутся и общие модули исчезнут, бренд-токены перестанут попадать в захардкоженные запасные значения. Подрядчику стоит задавать не вопрос «соберёте ли на брендированном шаблоне?», а вопрос «как именно вы проверите границу слоёв, чтобы клиентские доработки пережили следующее обновление». Пришлите исходник шаблона (или его ID) и бренд-спецификацию. Мы разметим слой доработок, сверим схемы полей и вернём фиксированную смету в часах. Аудит бесплатный, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-22-page-orthodontics-295-days/ title: Доработка темы для ортодонтической клиники — 22 страницы type: case_study date: 2025-10-22T17:38:39+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 22 страницы новой ортодонтической клиники, собранные из Figma агентства поверх их стоматологического шаблона — без предшествующего сайта, без готового списка URL, только Figma как отправная точка для QA. Агентство передало дизайн-спецификацию; мы выполнили постраничную доработку темы, 8 шаблонов наложены на таксономию услуг, охватывающую пути пациентов-подростков и взрослых. Главное — точное соответствие Figma без отступления от общих компонентов шаблона. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает раунды QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Ортодонтия Конечный клиент McCullum Orthodontics (Dr. Heather McCullum, Jeffersonville, IN) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн Figma на WP Engine) Объём работ **22 URL** — главная, о нас, биография врача, лендинг услуг, 8 страниц услуг, лендинг финансирования + 2 подстраницы, контакты, блог, thank-you, 404, юридические страницы Сроки 295 дней (13 мая 2025 – 2 фев 2026), по графику Трудозатраты 58 часов — разработка, итерации QA и управление проектом Команда 4 специалиста Шаблоны **10 переиспользуемых шаблонов** в библиотеке агентства, **8 применены** на 22 страницах Технический стек WordPress · Elementor · WP Engine · постраничный дизайн в Figma · Gravity Forms · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) **Подход к QA** **102 отслеженных пункта** сверены в очереди задач агентства (50 SEO + 52 CX) с контрольным списком запуска из 30 пунктов **Ритм работ** 49 задач от агентства · все закрыты к передаче (119-дневный активный период, 2025-06-02 – 2025-09-28) **Раунды проверки** ≈15 раундов проверки за 295 календарных дней **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн Figma для McCullum Orthodontics — ортодонтической клиники в Jeffersonville, IN, предлагающей брекеты, прозрачные элайнеры, раннее вмешательство, ретейнеры и отбеливание зубов — и цель развёртывания на их брендированной шаблонной системе на WP Engine. У клиники не было существующего сайта; это была полностью новая разработка. Агентство уже выполнило подготовительную работу: аудит дизайна, утверждение клиентом, настройка хостинга, контент-план. Им нужна была команда разработки, которая точно наложила бы Figma на шаблон, через столько итераций доработки, сколько потребует дизайн. Задача была чисто исполнительская. Figma — единственный источник истины. Доработать шаблон страница за страницей, точка адаптации за точкой адаптации. Все находки QA выносить в общее пространство задач; не закрывать без согласования агентства. > **Контекст рисков.** Ортодонтическая клиника, запускающая первый сайт, не имеет живого якоря для регрессионной проверки — единственная точка отсчёта для QA — файл Figma. Риск, который хеджировало агентство, тоньше, чем при сломанной миграции: на новом сайте каждое умолчание шаблона, которое Figma явно не переопределила, становится первым впечатлением пациента. Ортодонтия охватывает две принципиально разные психологии пациента — раннее вмешательство у подростков (нёбные расширители, пространственные держатели) и элективное выравнивание у взрослых (прозрачные элайнеры, отбеливание). Шаблон, изначально сделанный для общей стоматологии, это разделение не учитывает автоматически. Главным в проекте было удержать таксономию услуг последовательной в рамках структуры шаблона — пока команда контента агентства наполняла сайт после передачи. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Брендированный шаблон — базовой структурой страниц. Нашей задачей было согласовать их страница за страницей — где макет шаблона по умолчанию совпадал с Figma, мы его оставляли; где Figma требовала отклонения, мы дорабатывали. Никакие дизайн-решения не исходили от нас. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрал один раз, проверил один раз». Это «собрал, QA, поправил, QA, поправил». За время проекта мы отследили 15+ итераций QA в Redmine и сверили 102 пункта в общей очереди задач агентства: в отдельных раундах агентство отмечало расхождения с дизайном, отсутствующие изображения и неточности контента, а мы проверяли, исправляли и возвращали сборку на новую проверку. Такой объём — не признак нестабильности; именно он отделяет сайт на шаблоне, который выглядит «примерно правильно», от того, что точно соответствует дизайну. 295-дневный календарь складывался из ритма проверки и утверждения на стороне агентства между раундами, а не из объёма разработки: чистое время сборки составило около 58 часов, но каждый пакет на QA ждал внутреннего цикла агентства, прежде чем следующая итерация могла закрыться. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без расползания.** Каждое изменение в брендированном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно референса из Figma. Ни одна доработка не «протекла» в общие компоненты шаблона, то есть работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных форматах экрана. Каждый раунд QA покрывал страницы, затронутые расхождениями с дизайном данного раунда, а не весь сайт — именно так сборка на шаблоне остаётся экономной без потери покрытия. Мы взяли за основу шаблонную систему агентства, а не строили страницы с нуля: так держится единообразие дизайна в рамках таксономии услуг клиники — ортодонтия охватывает и подростковые, и взрослые типы пациентов, — и при этом каждая правка должна была остаться в клиентских переопределениях, чтобы не загрязнять библиотеку шаблонов для следующих проектов. Figma не была статичным документом. Цвета обновились в середине проекта после утверждения клиентом, баннер и прототип главной пересматривались в январе 2026 — всё в рамках той же оценки. Именно то, что каждую правку мы воспринимали как новую итерацию, а не как расширение объёма, и позволило 295-дневному проекту двигаться без пересогласования часов. ## Контроль качества На новой ортодонтической сборке без предшествующего списка URL QA перед передачей выявило две прослеживаемые находки: правило завершающего слеша в URL, применённое к каждой внутренней ссылке на всех 22 страницах, и перепутанную типографику на главной — шрифты заголовка и подзаголовка стояли наоборот относительно всех остальных страниц сборки. Обе всплыли в финальном закрытии QA из 2 пунктов перед согласованием. QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу нулевых ошибок. Внутренний контур проверки агентства выполнялся после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их согласования. Доработки остались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не были изменены. ## Результаты Метрика Результат URL сдано **22** — главная, о нас, биография врача, лендинг услуг, 8 страниц услуг, лендинг финансирования + 2 подстраницы, контакты, блог, thank-you, 404, юридические страницы Шаблонов применено **8 из 10** переиспользуемых шаблонов построено и наложено на 22 страницы Контрольный список запуска **30 пунктов** согласованы QA / задачи отслежены и решены **102** пункта сверены в очереди задач агентства (50 SEO + 52 CX) Итерации QA в Redmine **15+ из 23 задач** отслежены на уровне итераций Сроки **295 дней**, сдано по графику Трудозатраты **58 часов** при оценке 58 часов — без перерасхода, без расширения объёма Команда **4 специалиста** Передача хостинга Сдано на тестовую среду WP Engine агентства; переключение собственного домена управлялось агентством Состояние страниц при передаче **22 / 22** тестовые URL предоставлены и возвращают HTTP 200 Если коротко: Figma агентства реализована поверх их брендированного шаблона на 22 страницах и 8 шаблонах, за 295 календарных дней, в рамках оценки в 58 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Figma рассмотрена, доступ к шаблону подтверждён, объём согласован Разработка доработок ~2 недели Постраничная доработка темы для соответствия Figma Итерации QA (параллельно) ~38 недель 15+ раундов QA зафиксировано; каждый закрыт только после согласования агентством Раунды исправлений ~2 недели Коррекции после проверки, обновления баннера и прототипа Доставка финальный день Сайт на тестовой среде WP Engine, готов к наполнению контентом агентством и переключению DNS _Разработка и QA шли параллельно — это характерно для работы по доработке темы, где ни одна «фаза QA» не закрывается чисто; цикл идёт непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Павел Сажин** — итерации QA и исправления - **Тимур Арбаев** — итерации QA и поддержка разработчика - **Наталия Богатель** — ведущий разработчик (доработка темы и наложение Figma на макеты) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне агентства-партнёра на всём протяжении. Конечный клиент нас не видел: запросы на доработку шли через общую очередь задач агентства, и сборка ему не показывалась. Каждый раунд закрывался только после согласования проверяющего со стороны агентства. ## Агентствам с библиотекой шаблонов > На брендированном шаблоне для ортодонтической клиники первое впечатление пациента достаётся тем умолчаниям, которые дизайн-файл не переопределил. У этой практики — подростки на раннем вмешательстве и взрослые на элективном выравнивании; у другого клиента — сайт под один сегмент, где шаблон ложится без отдельной работы над таксономией. Тихие риски: таксономия шаблона по умолчанию сольёт оба потока аудитории; переопределения в дочерней теме откатятся на следующем обновлении поставщика; редакторы наполнят страницы, чья структура уже разошлась с дизайн-файлом. Подрядчику стоит задавать не вопрос «сможете ли работать внутри этого шаблона?», а вопрос «как именно вы построите таксономию, чтобы потоки подростков и взрослых остались разведены внутри структуры шаблона по умолчанию?» Пришлите ID шаблона и спецификацию бренда. Мы сверим умолчания шаблона с вашей картой пути пациента, отметим переопределения, которые вступят в конфликт с обновлением поставщика, и вернём фиксированную смету в часах. Разбор бесплатный, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-homepage-redesign-legal-adobe-xd-59-hours/ title: Редизайн главной страницы юридического сайта — Adobe XD в WordPress type: case_study date: 2025-10-20T05:46:58+00:00 case_industry: Юридические услуги case_type: Редизайн case_practice: wordpress --- ## Подход к редизайну 1 макет Adobe XD для главной страницы юридической практики из США, который мы развернули на 2 смежные практики под одним агентством — Dale Rose Law и Rose Knows Law. Каждая жила на собственной тестовой среде WP Engine, каждую проверяли и утверждали отдельно, и только потом публиковали. Бриф звучал так: переделать главную, а затем подогнать цветовую палитру и шрифты под весь сайт. На страницах услуг Dale Rose всплыло ограничение: тексты были привязаны к 1 городу. Мы не стали переписывать их втихую — вынесли вопрос агентству. ## Краткий обзор Параметр Значение Отрасль клиента Юридические услуги Клиент Rose Knows Law (юридическая практика в США) **Формат сотрудничества** **White-label редизайн главной страницы и сопутствующая разработка для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Редизайн главной страницы из Adobe XD в WordPress — сборка на тестовой среде, публикация после утверждения агентством; плюс изменения меню и доработки очереди задач для той же практики Объём работ **1 редизайн главной страницы** — полный редизайн по макету Adobe XD агентства, сборка в WordPress на тестовой среде, запуск после утверждения агентством; плюс 9 сопутствующих задач: навигация меню, доработки очереди задач, контентные страницы и обновления WordPress для Rose Knows Law и смежной практики (Dale Rose Law) под тем же агентством Срок ~4 месяца (ноя 2024 – мар 2025), в ритме агентства Затраты **~59 часов** — ~40 ч редизайн главной (Dale Rose Law) · ~13 ч изменения Rose Knows Law (меню, очередь задач, редизайн главной, дополнительные страницы) · ~6 ч управление и обновления Команда 5 специалистов (разработчик + QA + руководитель проекта) Передача дизайна Макет Adobe XD (собственность агентства; URL дизайна не раскрывается) — утверждённое ТЗ явно требовало применить новый дизайн к существующему сайту Технологии WordPress · Elementor · Gravity Forms · Rank Math SEO · WP Engine · Site Checker ([xaverPRO](https://xaver.ru/) QA плагин) **Режим сборки** **Сборка на тестовой среде** — новая главная страница собрана на тестовой среде WP Engine параллельно с работающим сайтом, без промежуточной публикации **Результат** **Редизайн главной страницы сдан по спецификации, обновлена навигация меню, доработана очередь задач, добавлены контентные страницы, сайт опубликован на roseknowslaw.com** **Раунды проверки** ≈8 раундов проверки за 120 дней ## Постановка задачи Маркетинговое агентство из США, нанятое юридической практикой Rose Knows Law, искало партнёра-разработчика для редизайна главной страницы и выполнения ряда сопутствующих изменений. Задача поступила в двух потоках: редизайн главной страницы для смежной юридической практики (Dale Rose Law) на основе утверждённого макета Adobe XD и набор текущих изменений для самой Rose Knows Law — улучшения навигации меню, редизайн главной страницы, доработка очереди задач и дополнительные страницы. Явные ограничения: редизайн главной страницы сначала собирается на тестовой среде и не публикуется до проверки и утверждения агентством; изменения навигации меню должны были корректно работать на большом экране и мобильных устройствах без нарушения существующей структуры сайта. На смежной практике (Dale Rose Law) проявилось ограничение: старый контент страниц услуг был написан специально для одного местоположения (McKinney) и не мог быть автоматически адаптирован для отображения по нескольким регионам в рамках существующей архитектуры шаблонов — тексты старого сайта были привязаны к конкретному адресу на уровне содержимого страниц, а не таксономии. Мы передали архитектурное ограничение агентству, вместо того чтобы переписывать контент за рамками ТЗ. Задача была сформулирована лаконично: воспроизвести Adobe XD в WordPress/Elementor; сдать сборку на тестовой среде; доработать очередь задач; обновить навигацию; добавить контентные страницы по запросу; не выходить на прямой контакт с конечным клиентом на всём протяжении проекта. > **Контекст рисков.** Главная страница юридической практики несёт более высокую цену ошибки, чем большинство сайтов локального бизнеса. Каждый визуальный элемент на экране — имена адвокатов, направления практики, контактные призывы к действию — соседствует с юридически чувствительным материалом. Редизайн никогда не публиковался до тех пор, пока агентство не проверило сборку на тестовой среде; в каждый момент разработки работающая главная страница была либо неизменённым оригиналом, либо полностью проверенной новой версией, но никогда — недоработанным гибридом. Сборка на тестовой среде здесь — не процедура ради галочки, а рабочий барьер: он держит агентство в стороне от аварии на работающем сайте юридического клиента. _Смежную практику (Dale Rose Law) вели по той же модели: 40-часовой редизайн главной собрали на отдельной тестовой среде, агентство его проверило и опубликовало только после утверждения. У обеих практик было 1 агентство и 1 команда, но каждая получила собственную тестовую среду и собственный этап проверки._ ## Как мы это сделали **1. Из Adobe XD в WordPress, сборка на тестовой среде.** Главную страницу собрали целиком в WordPress/Elementor по утверждённым макетам Adobe XD — hero, секции услуг, профили адвокатов, контактный блок, футер. Поскольку Elementor уже был установлен на сайте, сборка вписалась в существующую тему и глобальную систему стилей без внедрения нового конструктора страниц. **2. Сборка на тестовой среде, не на рабочем сайте.** Новую главную развернули на тестовой среде WP Engine рядом с существующей рабочей версией. Каждый цикл QA гоняли на тестовой среде до запуска. Это операционная мера предосторожности, специально запрошенная агентством для данного типа проекта и отрасли клиента — юридическая практика не может позволить себе полусобранную главную страницу, попавшую в публичный доступ в середине QA. Принцип здесь прост: при редизайне главной страницы юридического сайта команда разработки по умолчанию работает через тестовую среду. Сайт стоматологии или ресторана может позволить себе запуск без полной проверки; юридическая фирма — нет. **3. Редизайн навигации меню — большой экран и мобильные устройства.** Отдельная задача была посвящена структуре навигации: увеличение размера текста на большом экране, внедрение выпадающих меню на мобильных устройствах и удобство меню на обоих типах экранов. Разработчик предложил всплывающее боковое меню вместо стандартной горизонтальной панели, поскольку набор юридических направлений охватывал несколько регионов и стандартный шаблон выходил за границы экрана; агентство подтвердило подход до реализации. Мобильное выпадающее меню сделали отдельно — переключателем, а не постоянной панелью в стиле большого экрана — глубина навигации сайта делала стандартный подход непрактичным для маленького экрана. **4. Доработка очереди и контентные страницы.** Агентство передало нам список вопросов в Google Sheets для Rose Knows Law. Команда разобрала список, провела триаж и закрыла каждый пункт через отслеживаемые задачи Redmine. Отдельной задачей добавили страницу биографии адвоката для смежной практики — на существующих изображениях сайта и предоставленных текстах. **5. Внутренний QA перед передачей агентству.** QA гоняли на больших и мобильных экранах — он выявил типичные артефакты переноса из XD в Elementor (поведение отступов, цели ссылок, подключение форм, адаптивность меню). Затем агентство проверило сборку на тестовой среде и дало финальные замечания перед публикацией. Старые тексты страниц услуг смежной практики были написаны для одного города — McKinney — и новый дизайн не устранял это ограничение автоматически. Мы передали структурное ограничение агентству, не переписывая контент за рамками ТЗ; визуальный редизайн сдали в чистом виде, а решение по текстам осталось за агентством. ## Контроль качества Сборка главной страницы Dale Rose на тестовой среде WP Engine была переведена во внутренний статус «Проверено, на отправку» 26 февраля 2025 до того, как агентство увидело сборку; работающая главная страница оставалась нетронутой на всём протяжении работ, и задача была закрыта только после подтверждения агентством. Предварительный QA проводился через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Собственный QA агентства выполнялся после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до момента утверждения. ## Результаты Метрика Результат Редизайн главной страницы Сдан — Adobe XD реализован в Elementor, заменив предыдущую главную страницу (Dale Rose Law) Редизайн главной страницы (Rose Knows Law) Сдан — главная страница переработана по ТЗ агентства **Режим сборки** **Сборка на тестовой среде** — новая главная страница собрана на тестовой среде WP Engine параллельно с работающим сайтом, без промежуточной публикации Навигация меню Переработана — увеличен размер текста на большом экране, реализованы мобильные выпадающие списки, для большого набора пунктов применено всплывающее боковое меню Доработка очереди Список вопросов из Google Sheets разобран и закрыт через отслеживаемые задачи Redmine Контентные страницы Добавлена 1 страница биографии адвоката (Adam Rose) для смежной практики Обновления WordPress 2 задачи обновлений закрыты **Срок** **~4 месяца** (ноя 2024 – мар 2025), сдано в темпе агентства **Затраты** **~59 часов** — ~40 ч редизайн главной · ~13 ч изменения Rose Knows Law · ~6 ч управление и обновления **Команда** 4 специалиста — без отдельного аналитика, без дизайн-лида (дизайн на стороне агентства), без SEO-лида (миграция не требовалась) **Статус сайта** Работает, открывается по адресу https://roseknowslaw.com/ — проверено в апреле 2026. Результат, если кратко: макет агентства в Adobe XD был реализован в Elementor на тестовой среде, прошёл внутреннюю проверку и проверку агентства, и был опубликован — вместе с обновлением навигации меню, доработкой очереди задач и добавлением контентных страниц — за ~4 месяца и около 59 часов работы. ## Процесс Этап Длительность Результат ТЗ и оценка ~1 неделя Adobe XD проанализирован, Elementor подтверждён, согласована модель сборки на тестовой среде Сборка главной (тестовая среда) ~3 недели Полная главная страница реализована в Elementor на тестовой среде WP Engine (Dale Rose Law) Изменения Rose Knows Law ~6 недель Обновлена навигация меню, доработана очередь задач, выполнен редизайн главной, добавлены страницы Внутренний QA ~1 неделя Проверка на больших и мобильных экранах; мелкие дефекты найдены и исправлены Запуск ~1 неделя Страницы опубликованы; выполнена проверка после запуска _Этапы пересекаются — изменения Rose Knows Law велись параллельно со сборкой главной Dale Rose Law, а доработка очереди задач шла одновременно с редизайном навигации. Это характерно для многопоточного проекта, где цикл QA идёт непрерывно, а не строго последовательными фазами._ ## Команда **Команда проекта** - **Никита Тумашевич** — сборка главной страницы в Elementor по Adobe XD; редизайн навигации меню - **Павел Сажин** — управление проектом и QA-итерации - **Анна Полунина** — поддержка реализации и QA - **Владимир Козлов** — доработка очереди задач и дополнительные страницы для Rose Knows Law - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, утверждение, координация QA) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении работ. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим редизайн WordPress > При редизайне юридического сайта правка 1 шаблона может незаметно сломать вёрстку всех страниц, которые его делят, — а на сайте, где репутация под лицензией, сломанная страница тянет за собой регуляторные последствия. У 1 практики это адвокат-одиночка, где каждый пиксель на счету; у другой — сеть юридических кабинетов с общей библиотекой бренда. Поломки вылезают уже после запуска: слаги меняются без карты редиректов, и страницы, которые агентство вывело в топ, пропадают из поиска. Сетки компонентов рассчитаны на длину текста, которой у клиента нет, — биографии адвокатов и карточки направлений обрезаются. Цвет и шрифты разъезжаются неравномерно: главная уже в новом виде, а архивы и сайдбары остаются на старой палитре. Вопрос не «переделаете ли главную?», а «как вы защитите карту редиректов, зафиксируете каскад стилей и проверите сетку на реальном тексте?» Пришлите макеты и текущий перечень URL. Мы проверим библиотеку компонентов на несовпадение по длине текста, проследим каскад типографики по всем шаблонам и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-refresh-dental-endo-6-tickets-83-days/ title: Обновление дизайна сайта эндодонтии — 6 задач за 83 дня type: case_study date: 2025-10-14T23:07:22+00:00 case_industry: Здравоохранение case_type: Обновление дизайна case_practice: wordpress --- ## Подход к обновлению 6 задач за 83 дня для эндодонтической практики из США — редизайн главной на тестовой среде WP Engine, где был доступен Elementor Pro, с последующей выкладкой в работу, где его не было. Шапку, подвал и главную пришлось собрать заново по тестовой сборке, а не перенести напрямую. Работали от черновика к запуску в ритме согласований агентства: дизайн в марте, реализация в мае, три микроправки в июне. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Стоматология (Эндодонтия) Клиент Burien Endodontics (эндодонтическая практика в США) **Формат сотрудничества** **White-label рабочий процесс обновления дизайна и поддержки для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Обновление дизайна рабочего сайта — редизайн главной на тестовой среде, перенос в работу, обновления изображений, исправления ошибок, запросы изменений UI Объём **6 задач** — редизайн главной из Figma, проверка QA, исправление ошибок, редактирование изображений, выкладка в работу, исправления после миграции Сроки 83 дня (27 мар – 18 июн 2025), в ритме агентства Затраты **~19 часов на 6 задач** Команда 6 специалистов — разработчик + QA + руководитель проекта; без отдельного аналитика (не требуется для обновления дизайна такого масштаба) Шаблоны Главная построена на существующей системе стоматологических шаблонов агентства; новых шаблонов не добавлялось Технологии WordPress · Elementor · Elementor Pro · Gravity Forms · Rank Math SEO · Redirection · WP Engine · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **Обновление дизайна главной запущено в работу, 6 задач закрыто, подвал и навигация проверены на единообразие, сайт возвращает HTTP 200** **Раунды проверки** ≈4 раунда на 83-дневном календарном окне ## Постановка задачи Маркетинговое агентство, нанятое Burien Endodontics — эндодонтической практикой в районе Burien, WA — нуждалось в партнёре-разработчике для обновления дизайна главной страницы практики и выполнения небольшого набора последующих изменений. Редизайн главной был утверждён в Figma и требовал реализации на тестовой среде, проверки и публикации без простоев и сбоев для пациентов. После запуска главной в работу проект продолжился как устойчивый поток мелких запросов изменений — исправление ошибки из документа клиента, замена hero-изображения, замена фото врача и набор доработок после миграции (исправление телефонной ссылки, очистка меню, исправление наложения на адаптивной вёрстке, маршрутизация ссылки View All). Каждый запрос изменений создавался в Redmine, разрабатывался на тестовой среде или напрямую в работе и закрывался через согласование агентством. Задача формулируется просто, но требует дисциплины: освежить главную по утверждённому Figma, аккуратно вывести в работу и обработать последующие задачи один за другим, не дестабилизируя сайт. > **Контекст рисков.** На сайте эндодонтической практики главная страница — это страница с наибольшим трафиком и основной канал привлечения пациентов. Она уже проиндексирована для локального поиска, уже получает прямой трафик из сетей рекомендаций, уже маршрутизирует запросы на запись. Обновление дизайна главной — замена hero-изображения, изменение размера логотипа при прокрутке, реструктуризация секций — несёт концентрированный риск: сломанная ссылка записи, неверно направленный номер телефона или наложение на адаптивной вёрстке при 1280 px означают, что потенциальный пациент уйдёт, даже не увидев обновлённый дизайн. Ценность здесь — не сам редизайн. Она в том, чтобы обновить самую ответственную страницу и не внести регрессий, которые практика обнаружит по пропущенным звонкам на запись. У проекта не было таблицы или структурированной спецификации; каждая последующая задача оценивалась по краткому описанию, а не по предварительно согласованной очереди задач, поэтому каждое изменение несло риск выявления недокументированных требований в ритме ответа агентства, а не по фиксированной карте сайта. ## Контроль качества Проверка на тестовой среде при обновлении главной выявила регрессию анимации логотипа на мобильном: сжатие при прокрутке работало на больших экранах, но ломалось на смартфонах. Поймали на проверке и исправили ещё до выкладки страницы в работу. Проверка после миграции вскрыла 3 микропроблемы, среди них правка ссылки в меню навигации, — всё до согласования агентством. Проверку перед закрытием задач прогоняли через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Приёмочный контур агентства запускался после передачи и складывал замечания в общую очередь правок, и так до согласования каждой задачи. ## Как мы это сделали **1. Редизайн главной по Figma на тестовой среде.** Агентство предоставило утверждённый Figma-фрейм для новой главной. Владимир Козлов реализовал редизайн на тестовой среде WP Engine — hero-секция, поведение сжатия логотипа при прокрутке, обновлённый подвал и обновлённая навигация — с привязкой каждого элемента к спецификации в Figma. Правки шли только в тестовой среде до согласования агентством. Мы выбрали подход «сначала тестовая среда» вместо правок прямо на опубликованном сайте, потому что частично обновлённая главная, видимая поисковым системам в процессе сборки, показала бы пациентам несогласованный посыл бренда на основном канале привлечения пациентов практики. **2. Проверка перед публикацией.** Павел Сажин прогнал QA на тестовой главной — соответствие Figma, адаптивная вёрстка, анимация логотипа, единообразие навигации — прежде чем страницу допустили к выкладке в работу. Принцип: обновление рабочего сайта не выводится в работу, пока агентство не проверит и не утвердит сборку на тестовой среде. **3. Запуск в работу и дисциплина после миграции.** После согласования с агентством главную вывели в работу. Отдельная задача отслеживала саму миграцию — тестовая среда → опубликованный сайт — с контрольным списком проверки, охватывающим единообразие шапки/подвала, функциональность навигации и маршрутизацию форм. После миграции набор мелких исправлений закрылся чисто: наложение на адаптивной вёрстке при 1280 px в секции «A Step Above the Rest», неверная ссылка tel: в подвале, дублированный пункт меню «Home» и ссылка View All, направленная на правильный лендинг эндодонтии. **4. Дисциплина запросов изменений — 6 задач за 83 дня.** Задачи поступали через Redmine в ритме агентства — «Исправить ошибки согласно документу», «Редактирование изображения — Burien Endodontics | Обновление дизайна сайта», «Выполнить запуск боевого домена», «Перенести на боевой домен и решить проблемы». Каждую задачу оценивали, разрабатывали, прогоняли через внутреннюю проверку Site Checker, возвращали агентству и закрывали по их согласованию. В среднем на задачу уходило около 3 часов — характерный профиль небольшого обновления, где редизайн главной несёт основную нагрузку, а остальные правки точечные. Работа без Elementor Pro на рабочем сайте означала, что шапку, подвал и главную нельзя было перенести напрямую с тестовой среды — команда перестроила каждый элемент вручную по эталону тестовой среды, а не импортировала его. Это ограничение дало более чистую рабочую сборку: каждый элемент был повторно проверен на соответствие спецификации в Figma при пересборке, а не считался перенесённым корректно. ## Результаты Метрика Результат Запросов изменений сдано **6 задач** закрыто за 83 дня Обновление дизайна главной Запущено — главная по Figma выведена с тестовой среды в работу Новых изображений Hero-изображение и фото врача заменены по утверждённым агентством ресурсам Проверка Site Checker Порог нулевых ошибок — прогон перед закрытием каждой задачи Исправления после миграции 4 пункта закрыто: наложение адаптивной вёрстки, телефонная ссылка в подвале, очистка меню, маршрутизация View All Сроки **83 дня**, сдано в ритме агентства Затраты **~19 часов** всего на 6 задач Передача Сайт работает на [burienendo.com](https://burienendo.com/), HTTP 200, шапка и подвал единообразны Если коротко: редизайн главной от агентства собрали на тестовой среде, проверили, опубликовали и дополнили набором мелких правок — каждую закрыли по отдельности через проверку Site Checker и согласование агентством, за 83 календарных дня. ## Процесс Этап Длительность Результат Первичный бриф и оценка ~1 неделя Figma изучена; тестовая среда подтверждена; объём главной согласован Редизайн главной (тестовая среда) ~2 недели Полная главная реализована в Elementor Pro на тестовой среде WP Engine QA + проверка агентства ~1 неделя Главная на тестовой среде проверена на соответствие Figma; согласование агентством получено Публикация ~1 неделя Главная выведена в работу; контрольный список миграции выполнен Поток запросов изменений ~10 недель 5 последующих задач обработали и закрыли по одной; каждую — через проверку Site Checker перед закрытием и согласование агентством после передачи _Этапы пересекаются — запросы изменений продолжали поступать после выхода главной в работу, а раунд исправлений после миграции шёл параллельно с собственной QA-проверкой агентства. Это пересечение характерно для работы по обновлению дизайна._ ## Команда **Команда проекта** - **Никита Тумашевич** — разработчик правок изображений и исправлений ошибок - **Павел Сажин** — QA на проверке тестовой среды и проверка после миграции - **Анна Полунина** — поддержка реализации и QA - **Владимир Козлов** — разработчик редизайна главной и последующих изменений - **Евгений Карпов** — поддержка разработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, утверждение дизайна и коммуникация с клиентом оставались у партнёрского агентства на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим обновление WordPress > Редизайн эндодонтического сайта выглядит простым, пока правки не дойдут до клинических страниц, на которых держатся ваши позиции. Дальше начинается тихая беда: цвет и типографика расходятся по сайту неравномерно — шапка уже новая, а страницы хирургических услуг всё ещё в старой палитре. 3 мелкие задачи разрастаются в полноценный редизайн, как только визуальные правки вскрывают пробелы в архитектуре информации. Поэтому перед стартом важно спросить подрядчика не «обновите ли вы дизайн?», а «как вы удержите объём и прокатите смену палитры так, чтобы ни одна страница не осталась на старой?» Пришлите нам очередь задач или трекер по правкам, которые задумали. Мы сверим объём с текущей таксономией сайта, отметим задачи, которые расползутся неравномерно или вскроют пробелы поглубже, и вернём смету с фиксированными часами. Бесплатно, с фиксированной оценкой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-134-urls-14-days/ title: Ребилд стоматологического сайта на 134 URL: выполнено по ТЗ за 14 дней type: case_study date: 2025-10-11T03:38:30+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 34 структурные страницы и 100 записей блога стоматологической практики — ребилд на 11 шаблонов по макетам Figma. 134 URL перенесены, проверены и сданы за 14 дней без единого часа переработки. Агентству принадлежали карта сайта и список редиректов; нам — постраничная реализация и завершающий слеш на каждом URL, как требовало ТЗ. ## Краткий обзор Поле Значение Сфера деятельности конечного клиента Медицина — общая стоматология Конечный клиент Lotus Dental Associates (Fort Mill, SC) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro на Kinsta Объём Полный сайт — 34 структурные страницы + 100 записей блога перенесены Срок 14 дней (4–18 июня 2025), по графику Затраты 31 час при оценке в 31 час — без переработок Команда 4 специалиста (24 ч разработка · 4 ч QA · 3 ч PM) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) QA-плагин) Проверка контента Сверка контента оригинала и ребилда пройдена перед сдачей — без пропусков текста, битых внутренних ссылок и структурных расхождений **Результат** **ТЗ выполнено построчно — 134 URL перенесены, 11 шаблонов, контрольный список запуска на 30 пунктов** **Интенсивность коммуникации** 105 задач от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈4 раунда проверки за 14-дневное окно **Контрольный список запуска** 30 пунктов, согласованы до переключения DNS ## Постановка задачи У агентства был стоматологический клиент на абонентском обслуживании — практика общей стоматологии в Fort Mill, SC, — чей существующий сайт на WordPress нуждался в ребилде на Kinsta с современной системой шаблонов. Агентство уже выполнило стратегическую работу: таблица Google Sheets с картой каждого текущего URL на новый путь, все мета-заголовки и описания для переноса, полный список шаблонов и контрольный список запуска, охватывающий проверки до и после миграции. Задача была конкретной. Взять ТЗ как есть; пересобрать сайт на Elementor Pro; вернуть готовым к переключению. Не выходить на прямой контакт с клиентом. Реализовать SEO-решения как написано. Уложиться в указанные часы. Одно измерение ТЗ делало этот ребилд сложнее, чем предполагало количество страниц: сайт содержал архив блога из 100 записей в дополнение к 34 структурным страницам, причём 86 старых URL были помечены на удаление, а 16 URL требовали изменения путей. Каждое удаление и каждая перестройка требовали отдельного редиректа. ТЗ покрывало всё это. Наша задача состояла в том, чтобы реализовать каждую строку в точности как написано. > **Контекст рисков.** Когда ребилд переносит архив контента из 100 записей блога вместе с 30+ структурными страницами, риск не в сборке страниц — он в непрерывности URL. Один пропущенный редирект на записи блога, у которой уже есть входящие ссылки или репосты в соцсетях, разрывает путь читателя, не показывая ошибку на самом новом сайте. ТЗ агентства покрывало 86 удалений устаревших страниц и 16 перестроек URL; наша задача была убедиться, что каждый из них ведёт ровно туда, куда указано в таблице. ## Как мы это сделали **1. Сборка через шаблоны.** Вместо того чтобы пересобирать 134 URL по одному, мы свели их к 11 переиспользуемым шаблонам и разместили каждую страницу в соответствующем: - **Главная, О нас, Контакты** — брендообразующие страницы - **Лендинг услуг** — управляет каталогом услуг - **Страница услуги** — один переиспользуемый шаблон для всех 26 отдельных страниц услуг - **Страница врача** — био главного стоматолога - **Лендинг блога + Запись блога** — архив контента и шаблон отдельной записи (100 постов) - **Стандартный шаблон** — вспомогательные страницы (заявление о доступности, политика конфиденциальности) - **Запись на приём** — конверсионная страница - **Галерея улыбок** — шаблон «до/после» для конкретной практики 11 шаблонов — весь сайт готов. Будущие правки со стороны агентства живут в одном месте на тип страницы. **2. ТЗ выполнено построчно, из таблицы агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для переноса с целевым путём, каждый мета-заголовок и описание для переноса, каждое назначение шаблона, каждую клиент-специфичную интеграцию. Мы реализовали каждую строку как написано. Где в таблице было значение — это значение оказалось на новом сайте. Где его не было — мы вернули вопрос агентству. Никаких «творческих интерпретаций» не было. Коротко: при ребилде ТЗ — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка через обход, а не «на глаз нормально».** Перед переключением DNS мы параллельно прогнали Screaming Frog по старому боевому сайту и по сборке в тестовой среде. Коды статуса, битые ссылки, цепочки редиректов, расхождения в мета-тегах — каждое расхождение сверено с ТЗ агентства. Миграция 100 записей блога означала проверку непрерывности пермалинков по всему архиву, а не только на главной и страницах услуг. Второй обход после запуска подтвердил, что все внутренние ссылки работают на действующем домене. **4. Контрольный список запуска на 30 пунктов, закрытый до сдачи.** Семь категорий: Дизайн, Функциональность, Контент, SEO и аналитика, Адаптивность, клиент-специфичные интеграции и перенос DNS на Kinsta. Ничего не было сдано, пока каждая строка не была согласована. QA на разных устройствах — Chrome / Firefox / Safari / Edge на шести типах экранов (1920 / 1280 / 1024 / iPad / мобильная портретная / мобильная альбомная). Правило завершающего слеша на каждой внутренней ссылке — «Всегда слэши на конце, если их нет, должен быть редирект» по правилам агентства — было ограничением, которое упорядочивало миграцию 100 записей блога прежде, чем можно было закрыть визуальную итерацию. Редиректы для 86 удалений и 16 перестроек нужно было выверить до конца — только тогда сборку можно было назвать чистой. ## Результаты Метрика Результат Точность по ТЗ — URL перенесены **134 / 134** страниц и записей перенесены, как указано Точность по ТЗ — изменения путей **16 / 16** перестроек URL выполнены как указано Точность по ТЗ — удаление устаревших **86 / 86** устаревших URL обработаны по карте удаления агентства Точность по ТЗ — шаблоны **11 / 11** шаблонов созданы и применены на всём сайте Контрольный список запуска **30 пунктов** согласованы до переключения Срок **14 дней**, выполнено по графику Затраты **31 ч / 31 ч** оценка — без переработок, без расширения объёма Проверка адаптивности Ноль проблем с вёрсткой на 4 браузерах × 6 типах экранов Внутреннее QA Все задачи в рамках агентства закрыты до сдачи Сдача Сайт запущен на Kinsta в запланированный день, без простоя **Статус сайта** Работает, открывается по адресу https://www.lotusdentalassociates.com/. Если коротко: ТЗ агентства выполнено как написано, в рамках указанных часов, в запланированный день переключения. ## Контроль качества QA перед сдачей выявило две категории на тестовой среде: нарушение правила завершающего слеша на внутренних ссылках лендинга услуг — помечено как High Bug и исправлено до проверки агентства — и страница политики конфиденциальности, скопированная с другой практики, с неверной юрисдикцией (Калифорния вместо Южной Каролины) и сторонним email; обе проблемы исправлены в рамках очистки контента. QA перед сдачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) о категориях и пороге нулевых ошибок. Внутренний контроль агентства работал после сдачи и сводил замечания в общую очередь правок для нашего цикла исправлений, пока агентство не подписывало приёмку. ## Процесс Этап Длительность Результат Бриф и оценка 1 день ТЗ агентства проанализировано; 31 ч оценено и согласовано Разработка ~10 дней Полный сайт пересобран на 11 шаблонах; 100 записей блога перенесены Внутреннее QA и проверка 2 дня Задачи по SEO и CX обработаны; вся работа в рамках агентства закрыта Проверка ТЗ 1 день Мета-теги и редиректы сверены с таблицей; обход подтверждён Сдача и переключение DNS 1 день Сайт запущен на Kinsta, без простоя _Этапы пересекались (QA шёл параллельно с завершающей разработкой), поэтому календарный срок — 14 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (сборка всего сайта, система шаблонов, миграция блога) - **Павел Сажин** — исправления по QA и решение проблем после запуска - **Анна Полунина** — поддержка разработки структурных страниц и архива блога - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, подписание приёмки) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на протяжении всего переключения и миграции. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль заключалась в точности реализации того ТЗ, которое они предоставили. ## Агентствам, заказывающим ребилд WordPress > При white-label ребилде на ваше агентство ложится каждая деталь непрерывности. Здесь это 1 сайт практики с глубоким архивом обучающего блога; в другом проекте — сетевая группа клиник, у которой надо обновить страницы врачей по десятку офисов. И там, и там работу подтачивают одни и те же тихие сбои: пропущенный редирект роняет ранжированную страницу в 404; мета-заголовки молча сбрасываются к стандартным настройкам темы, и сниппеты в выдаче меняются за ночь; разметка, на которую опиралась отчётность агентства, пропадает на импорте. Подрядчику стоит задавать не вопрос «справитесь ли с переносом?», а вопрос «как именно вы проверите, что каждый URL, мета-заголовок и узел разметки переживёт переключение?» Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим ваш текущий список URL с планом ребилда, отметим строки, где рвётся непрерывность, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-24-page-70-days/ title: Шаблон сайта стоматологии на 24 страницы — миграция URL блога type: case_study date: 2025-10-05T19:02:43+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 24 страницы для стоматологической практики из Reno, свёрстанные по макетам Figma на 10 переиспользуемых шаблонах поверх брендированного шаблона на Kinsta — плюс перестройка URL блога: лендинг перенесён с `/about/our-blog/` на `/blog/`, вместе с 2 проиндексированными постами. После запуска проверка точности контента выявила тексты, искажающие реальный перечень услуг клиники; исправить распределённые по сайту строки и не внести при этом новые противоречия — вот к чему был подчинён цикл QA. ## Краткий обзор Поле Значение Индустрия клиента Медицина — общая стоматология Клиент Futch Dental (стоматологическая практика, Reno, NV) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка шаблона WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **24 URL** — главная, about, биография врача, лендинг услуг, **10 страниц услуг**, 4 стандартные страницы (новые пациенты, технологии, отзывы, галерея офиса), галерея «до/после», контакты, лендинг блога + 2 поста Миграция URL Лендинг блога перемещён `/about/our-blog/` → `/blog/`; 2 существующих поста перенесены в `/blog/` Сроки ~70 дней (май – июль 2025), в срок Трудозатраты 49 часов: разработка, итерации QA, PM, правки после запуска Команда 3 специалиста Шаблоны **10 переиспользуемых шаблонов** от агентства — все применены на 24 страницах Стек технологий WordPress · Elementor · Kinsta · Постраничные макеты Figma · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **74+ отслеженных SEO- и CX-проблем** согласовано в очереди задач агентства, контрольный список запуска на 29 пунктов **Ритм работ** 73 задачи от агентства · все закрыты к сдаче (43 активных дня, 2025-05-30 – 2025-07-11) **Раунды проверки** ≈5 раундов за 70 календарных дней **Контрольный список запуска** 29 пунктов, согласованы перед переходом ## Постановка задачи Маркетинговое агентство из США передало нам дизайн-макеты Figma для Futch Dental и доступ к своему брендированному шаблону на Kinsta. Агентство выполнило предварительную работу: сбор требований клиента, подготовку макетов в Figma, подбор контента и настройку хостинга. От нас требовалось точное исполнение — перенести дизайн из Figma на шаблон страница за страницей, а затем отработать очередь задач агентства до согласования. Проект охватывал 24 URL полного сайта клиники — главная, страницы услуг по основным направлениям Futch Dental (неотложная стоматология, Invisalign, импланты, коронки, пломбирование, лечение корневых каналов, протезирование, отбеливание, косметическая стоматология, ночные каппы), вспомогательные страницы (новые пациенты, технологии, отзывы, галерея офиса, галерея «до/после»), биография врача, about, контакты и блог. Параллельно с доработкой шаблона потребовалась реструктуризация URL блога: существующий лендинг блога находился по адресу `/about/our-blog/` и должен был переехать на `/blog/`, а два существующих поста — мигрировать с корневых slug-адресов в поддиректорию `/blog/`. Специфический риск этого проекта проявился на этапе проверки точности контента после запуска. Первичное QA агентства сняло структурные вопросы и вопросы соответствия дизайну, а второй раунд выявил контент, не отражающий реальные услуги клиники: маркетинговые тексты, преувеличивающие возможность лечения за один визит, формулировки FAQ по Invisalign, способные ввести пациентов в заблуждение, и упоминание круглосуточной справочной службы, которую клиника больше не предоставляет. Для стоматологической практики на локальном рынке текст, искажающий реальный спектр услуг, — это удар по доверию, а не просто замечание QA. Внести правки чисто — по повторяющимся на нескольких страницах строкам и по конкретным страницам услуг — значило точно определить границу каждой правки, чтобы, закрывая одно противоречие, не открывать новое. > **Контекст рисков.** Для стоматологической практики на локальном рынке текст, искажающий реальный спектр услуг, — это удар по доверию, а не просто замечание QA. После того как структурное QA сняло вопросы соответствия дизайну, второй раунд выявил контент, преувеличивающий возможность лечения в один день, формулировки FAQ по Invisalign, способные ввести пациентов в заблуждение, и упоминание круглосуточной справочной службы, которую клиника больше не предоставляет. Риск раунда правок контента после сдачи — распространение: исправление одного вхождения распределённой строки без исправления остальных или слишком узкое определение границ правки, приводящее к новому противоречию при закрытии старого. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Брендированный шаблон — базовой структурой страниц. Наша задача заключалась в том, чтобы свести их страница за страницей: там, где стандартная вёрстка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонений — вносили изменения. Никаких дизайн-решений с нашей стороны не принималось. **2. Перестройка URL блога параллельно с доработкой шаблона.** Проект Futch Dental не был разработкой с нуля — у клиники существовал блог с постами, проиндексированными по корневым slug-адресам, которые требовалось перенести в поддиректорию `/blog/`. Спецификация карты сайта от агентства предусматривала перенос этих страниц под `/blog/` в соответствии с новой архитектурой навигации. Перестройка URL шла параллельно с доработкой шаблона: поверх в остальном чисто шаблонной задачи добавился слой редиректов и навигационных ссылок. Лендинг блога и существующие посты мы сопоставили с соответствующими шаблонами (Blog Lander и Blog) и перед сдачей проверили в тестовой среде — HTTP 200 на всех. **3. Цикл QA в масштабе доработки шаблона.** Чистая доработка шаблона — это не «собрал один раз, проверил один раз». Это «собрал, проверил, поправил, проверил, поправил». В этом проекте отслеживалось 74+ пунктов в очередях задач SEO- и CX-проблем агентства — причём только очередь задач SEO содержала 74 строки — плюс контрольный список запуска на 29 пунктов. Одни задачи были исправлениями соответствия дизайну (дублирующиеся заголовки на странице косметической стоматологии, избыточные блоки CTA на страницах услуг, отсутствующая навигационная ссылка для лендинга блога); другие, обработанные в раундах после запуска, требовали переписывания конкретных текстовых строк в соответствии с реальным спектром услуг клиники. Структурное QA — соответствие дизайну, корректность HTML — не проверяет, насколько точно контент описывает реальные услуги клиники; для этого нужна предметная экспертиза, которую инструменты не дают. Каждую такую правку мы вели как отдельную задачу на конкретную строку: сквозную замену «same day treatment», полное удаление раздела о стеклоиономерных пломбах, переписывание FAQ по Invisalign под реальные параметры лечения. Мы делали это так, а не одним массовым переписыванием контента, потому что неточности были разных типов — повторяющиеся по сайту фразы и утверждения на отдельных страницах, и каждое нужно было проверить отдельно перед согласованием. Коротко: при доработке шаблона ценность создаётся именно в цикле QA. Чем короче цикл, тем слабее соответствие — либо макетам Figma, либо реальной информации клиники. **4. Доработка без расползания.** Каждое изменение, которое мы вносили в брендированный шаблон агентства, документировалось относительно референса Figma. Ни одна доработка не «протекла» в общие компоненты шаблона. Проект был закрыт с изолированными клиентскими переопределениями и нетронутым общим слоем шаблона. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на компьютере, планшете и мобильных устройствах. Каждый раунд QA был направлен на страницы, затронутые изменениями этого раунда, а не на весь сайт — так покрытие остаётся плотным, не теряя в широте. Точность контента — вот на чём держался этот проект. Структурное QA было пройдено при первичной сдаче; раунд после запуска выявил то, что инструменты не ловят, — тексты, искажающие реальные услуги клиники. Каждая правка выполнялась как отдельная задача в Redmine и проверялась перед закрытием, потому что исправление, вносящее новое противоречие при закрытии старого, сделало бы раунд бессмысленным. ## Контроль качества Последующая проверка выявила 3 ошибки точности, которые структурное QA не ловит: фраза «same day treatment», встречавшаяся на страницах FAQ и неотложной стоматологии (клиника может записать на приём в день обращения, но не провести полное лечение за один визит); текст FAQ по Invisalign с неклиническими формулировками и неверной длительностью ношения капп; и раздел о стеклоиономерных пломбах для услуги, которую клиника не предоставляет — каждая исправлена как отдельная задача. QA до сдачи проходило через **Site Checker** — см. [наш подход к QA](/site-checker/) о категориях проверки и принципе нулевых ошибок. Свой контроль на стороне агентства работал после сдачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их согласования. Доработки остались в клиентских переопределениях; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат Передано URL **24** — главная, 10 страниц услуг, биография врача, 2 страницы about, 4 стандартные страницы, галерея «до/после», контакты, лендинг блога + 2 поста Миграция URL блога Лендинг блога и 2 существующих поста перенесены на путь `/blog/` — HTTP 200 подтверждён для всех Применено шаблонов **10 из 10** переиспользуемых шаблонов собрано и сопоставлено на 24 страницах Контрольный список запуска **29 пунктов** согласовано Отслежено и решено задач QA/SEO **74+** пункта согласовано в очередях задач SEO и CX агентства Правки контента после запуска Глобальные замены строк + постраничные исправления контента выполнены как отдельные задачи в Redmine до июля 2025 Сроки ~**70 дней**, сдано в срок Трудозатраты **49 часов** на разработку, QA, PM и раунды правок после запуска Команда **3 специалиста** Хостинг Запущено на шаблонном окружении Kinsta агентства Состояние страниц при сдаче **24 / 24** URL на тестовой среде возвращали HTTP 200 по аудиту карты сайта Если коротко: макеты агентства из Figma были реализованы на их брендированном шаблоне на 24 страницах и 10 шаблонах, с реструктуризацией URL блога, за примерно 70 календарных дней, в рамках оценённых часов. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Figma проверена, доступ к шаблону подтверждён, объём согласован — оценка 27 ч разработки + 10 ч QA Доработка шаблона ~2 недели Постраничная доработка шаблона под Figma; включена реструктуризация URL блога Итерации QA (параллельно) ~4 недели 74+ пункта очереди задач зафиксировано и решено; подписание агентством при первичной сдаче Правки контента после запуска ~6 недель Исправления точности контента (замена текста, корректировка перечня услуг) выполнены как отдельные задачи Сдача июль 2025 Сайт запущен на Kinsta; журнал правок после запуска закрыт _Разработка и QA выполнялись параллельно — характерно для доработки шаблона, где ни один этап QA не закрывается окончательно; цикл продолжается до согласования с агентством. Раунды после запуска касались точности контента — вопросы, которые проявились только после полной редакционной проверки уже запущенного сайта._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона, сопоставление Figma с вёрсткой, реструктуризация URL блога) - **Павел Сажин** — ведущий QA (проверка очереди задач, проверка соответствия дизайну, раунды правок) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, координация после запуска, согласование) Дизайн, контент, коммуникация с клиентом и настройка хостинга оставались полностью на стороне агентства. Конечный клиент нас не видел. Запросы поступали через общую систему задач агентства; ничего не переходило в статус «done», пока проверяющий со стороны агентства не подтверждал. ## Агентствам с библиотекой шаблонов > На сайте стоматологической практики общие блоки несут контент, который повторяется по страницам, — и каждая такая строка становится уязвимостью для агентства, которое за сайт расписывается. У этой клиники — один бренд и один офис; у другого клиента — сеть на десятки филиалов, где 1 шаблон обслуживает каждый сайт. Сбои тихие: правка про лечение за один визит на одной странице остаётся жить на другой; обновление шаблона от поставщика без предупреждения затирает вашу разметку; правка после сдачи закрывает 1 неточность и открывает новую — а отвечает за каждый зазор агентство. Подрядчику стоит задавать не вопрос «соберёте ли сайт на шаблоне?», а вопрос «как именно вы отследите каждое вхождение общего блока, чтобы поздняя правка дошла до всех страниц?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы разберём слой общего контента, найдём каждое вхождение каждого распределённого блока, покажем, где переопределения уязвимы к следующему обновлению шаблона, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-24-page-dental-78-days/ title: Доработка 24 страниц стоматологического шаблона за 78 дней type: case_study date: 2025-10-04T01:33:41+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 24 страницы сайта Church Family Dentistry свёрстаны по макетам агентства в Figma на шаблоне Luminous — 19 сданы, 5 отложены из-за отсутствия изображений и текстов политик. Агентство владело макетом и сроками контента; мы отвечали за постраничное согласование в шести раундах QA, выявив сломанную карту сайта, hero-изображение в base64 и скачки заголовков, которые Site Checker зафиксировал до выхода сборки с тестовой среды. ## Краткий обзор Параметр Значение Сфера деятельности клиента Медицина — общая и косметическая стоматология Конечный клиент Church Family Dentistry and Cosmetics (Dr. Will Church, Durham, NC) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma, хостинг Kinsta) Объём **24 URL** — 19 запущены при сдаче, 5 отложены до получения контента клиента (Smile Gallery, пост в блог, страницы Payment Policy, Insurance, Financing) Сроки 78 дней (19 сен – 6 дек 2025), по графику Трудозатраты 67 часов — разработка, итерации QA и управление проектом Команда 6 специалистов Шаблоны **16 переиспользуемых шаблонов** предоставлены агентством, все применены на 24 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **76+ отслеженных SEO-проблем** согласованы в очереди задач агентства, 30-пунктный контрольный список запуска (вкладка CX для этого проекта не заполнялась) **Интенсивность взаимодействия** 76 вопросов от агентства · все закрыты к моменту сдачи (22 активных дня, 2025-10-22 – 2025-11-12) **Раунды проверки** ≈6 раундов на протяжении 78 календарных дней **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Church Family Dentistry and Cosmetics и доступ к своей брендированной шаблонной системе на Kinsta. Агентство уже сделало подготовительную работу: аудит дизайна, согласование с клиентом, настройку хостинга, контент-план. Нужна была команда разработки, которая точно перенесёт Figma на шаблон — через столько итераций доработки, сколько потребует дизайн. Задача была чисто исполнительская. Figma — единственный источник истины. Дорабатывать шаблон под Figma постранично, на каждой точке адаптации. Замечания QA возвращать агентству в общее рабочее пространство; не закрывать без его согласования. Агентству нужно было застраховаться от подрядчика, который правит общие компоненты шаблона, чтобы уложиться в срок, — такое упрощение незаметно, пока то же «исправление» не ломает сайт другого клиента на том же шаблоне. Стоматологический шаблон в активном использовании одновременно обслуживает несколько практик; доработка 1 проекта не должна уходить в общий слой. Именно это правило агентство и оплачивало, и именно его проверяли 20 QA-итераций по этому проекту. > **Контекст рисков.** Новая стоматологическая практика, запускающаяся на брендированном шаблоне, редко приходит с полным набором контента. Риск этого проекта был не в доработке шаблона — а в том, чтобы страницы-заглушки, пустые галереи и черновые URL не просочились на действующий сайт до того, как клиент предоставит изображения, тексты и политики. Команда, которая публикует каждую строку карты сайта, оставляет агентству 404, битые ссылки и заглушки в поисковых индексах. Мы держали под контролем именно то, что не пошло в публикацию: 5 страниц без контента скрыли при запуске, блоки Lorem ipsum убрали, а каждое визуальное расхождение согласовали через систему превью агентства до сдачи. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача — согласовать их постранично: где стандартная раскладка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения, мы дорабатывали. Никаких дизайн-решений с нашей стороны. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». За время проекта мы провели 20 QA-итераций в Redmine и согласовали 76+ позиций в общей очереди задач агентства — в каждом раунде агентство отмечало расхождения в дизайне, недостающие изображения и неточности контента; мы проверяли, исправляли и возвращали сборку на следующую проверку. Такой объём говорит не о нестабильности. Так и работает порядок, что отделяет сайт на шаблоне, выглядящий «примерно так», от сайта, который точно соответствует дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без дрейфа.** Каждое изменение брендированного шаблона — будь то раскладка страницы, компонент секции или стилевой токен — мы документировали относительно Figma. Ни одна доработка не «протекла» в общие компоненты шаблона; работа по этому проекту не ухудшила шаблон для следующего сайта. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах. Каждый раунд QA охватывал страницы, затронутые изменениями дизайна в этом раунде, а не весь сайт — так шаблонная сборка идёт без потери покрытия и не раздувает часы. Именно цикл QA и дал соответствие Figma. Двадцать итераций, 76+ отслеженных позиций и предсдаточная проверка, которая поймала hero-изображение в base64, зашитое в код шаблона, и полностью сломанную карту сайта — ничего этого не было бы без дисциплины «собрал — проверил — исправил — вернул», пока проверяющий со стороны агентства не подтверждал приёмку. ## Контроль качества QA перед сдачей обнаружило URL `/local/`, который Rank Math SEO PRO незаметно добавил в карту сайта (установлен автоматически, не входил в ТЗ), и указало на PNG-иконки, которые будут выглядеть размыто на экранах с высокой плотностью пикселей — обе проблемы решены до того, как агентство увидело сборку на тестовой среде. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Внутренний контроль агентства работал после сдачи и фиксировал замечания в общей очереди задач для нашего цикла исправлений до окончательного согласования. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **24** — 19 запущены при сдаче, 5 отложены до получения контента клиента Шаблонов применено **16 из 16** переиспользуемых шаблонов построены и распределены по 24 страницам Контрольный список запуска **30 пунктов** согласованы QA / SEO-проблем отслежено и решено **76+** позиций согласовано в SEO-очереди задач агентства (вкладка CX для этого проекта не заполнялась) QA-итераций в Redmine **20 из 28 задач (71%)** отслежены на уровне итераций Сроки **78 дней**, сдано по графику Трудозатраты **67 часов** при оценке 67 часов — без перерасхода, без расширения объёма Команда **6 специалистов** Размещение Запущено в шаблонной среде агентства на Kinsta Состояние страниц при сдаче **19 / 24** URL тестовой среды вернули HTTP 200 в аудите карты сайта (5 отложены) Результат, коротко: Figma агентства была реализована на их брендированном шаблоне на 24 страницах и 16 шаблонах за 78 календарных дней в пределах оценки в 67 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma просмотрена, доступ к шаблону подтверждён, объём согласован Разработка доработок ~5 недель Постраничная доработка шаблона под Figma QA-итерации (параллельно) ~6 недель 20 раундов QA; каждый закрыт только после согласования агентством Раунды исправлений ~2 недели Коррекции после проверки, отложенный контент, визуальные доработки Сдача финальный день Сайт запущен на Kinsta _Разработка и QA велись параллельно — это характерно для доработки темы, где ни один «этап QA» не закрывается полностью; цикл продолжается до согласования агентством._ ## Команда **Команда проекта** - **Павел Сажин** — итерации QA и исправления - **Анна Полунина** — поддержка доработки шаблона и QA - **Евгений Карпов** — ведущий разработчик (доработка шаблона, перенос Figma в раскладку) - **Владимир Козлов** — поддержка разработки - **Тимур Арбаев** — итерации QA и поддержка разработчика - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались за агентством на всём протяжении. Наша команда была невидима для конечного клиента. Запросы на доработку поступали через общую очередь задач агентства; ничего из сборки не было видно конечному клиенту. Каждый раунд закрывался только после того, как проверяющий со стороны агентства подтверждал приёмку. ## Агентствам с библиотекой шаблонов > Сайт стоматологической практики на готовом шаблоне несёт риск не в доработках, а в контроле наполнения. У этой практики — запуск без полного контента; у других — деплой после утверждения всех страниц. Если процесс не выстроен, страницы-заглушки уходят в индекс, пустые галереи отображаются как битые ссылки, а черновики засоряют карту сайта. Подрядчику стоит задавать не вопрос «запуститесь ли в срок», а вопрос «как именно вы не допустите незавершённые страницы в публикацию?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы проверим, как ваши доработки отделены от родительской темы, оценим риски при обновлениях и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-24-live-dental-98-url-scaffold-100-days/ title: Каркас стоматологического шаблона на 98 URL для новой клиники type: case_study date: 2025-09-25T15:51:34+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы Девяносто восемь URL, запланированных в таблице Google Sheets агентства для новой стоматологической клиники на двух врачей в Луизиане — 24 с подтверждённым контентом, 74 в виде каркаса, ожидающего наполнения. Все страницы доработаны на основе шаблона Luminous агентства в соответствии с постраничным дизайном Figma на Kinsta. Для клиники, которая ещё не приняла ни одного пациента, архитектурные решения, принятые во время сборки, стали основой будущей SEO-работы агентства. Каждый URL из таблицы Google Sheets был построен по плану, включая геолокационные поддиректории. Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Параметр Значение Сфера деятельности конечного клиента Медицина — общая и косметическая стоматология Конечный клиент Maison Dental Studio (Youngsville, LA) — Dr. Kaleb Murray и Dr. Sam Mullen **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта WordPress доработка темы (шаблон Luminous dental template агентства + постраничный дизайн в Figma на Kinsta) Объём работ **98 URL всего** — 24 готовых страницы с контентом на момент передачи; 74 URL в каркасе (подстраницы услуг, геолокационные директории) — структура шаблона готова к наполнению контентом Готовых страниц на момент передачи **24 страницы** — главная, о нас, 2 биографии врачей, команда, галерея улыбок, технологии, регионы обслуживания, блог, контакты, варианты оплаты и финансирование, 9 страниц услуг Сроки 100 дней (12 сен – 21 дек 2025), по графику Трудозатраты 64 часа на разработку, QA, управление проектом и раунды исправлений Команда 5 специалистов Шаблоны **10 повторно используемых шаблонов** из системы Luminous dental template агентства, применённых на всём сайте (главная · о нас · страница врача · страница услуги · стандартный шаблон · контакты · галерея улыбок · блог · статья блога · страница услуг) Технологии WordPress · Elementor · Kinsta · дизайн в Figma · AutoQA агентства (проверки ссылок, почты, контента AI) · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **127+ отслеженных SEO- и CX-проблем** сведены в очереди агентства по контрольному списку запуска из 78 пунктов; 5 геолокационных поддиректорий услуг структурированы под будущее наполнение **Интенсивность взаимодействия** 101 задача от агентства · все закрыты к моменту передачи (33 активных дня, 2025-10-01 – 2025-11-02) **Раунды проверки** ≈7 раундов проверки за 100 календарных дней **Контрольный список запуска** 78 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США настроило тестовую среду на Kinsta с предустановленным шаблоном Luminous dental template и предоставило дизайн главной страницы в Figma, а также структурированную таблицу Google Sheets для Maison Dental Studio — новой клиники на двух врачей, открывающейся в Youngsville, Луизиана. Dr. Kaleb Murray и Dr. Sam Mullen — каждому требовалась отдельная страница врача. Агентство также указало фотогалерею «до и после», многофилиальную архитектуру услуг, охватывающую пять окрестных населённых пунктов (Broussard, Lafayette, Milton, New Iberia, Woodlawn), и ряд разделов услуг: общая стоматология, косметическая, реставрационная, пародонтология и хирургическая стоматология. Агентство спланировало полную структуру URL в таблице Google Sheets до начала разработки. Задача состояла в том, чтобы доработать шаблон Luminous в соответствии с макетами Figma, построить полный каркас URL для всех 98 запланированных страниц, передать 24 страницы с подтверждённым контентом на момент сдачи, а остальные 74 подстраницы услуг и геолокационные страницы структурировать как готовые к наполнению экземпляры шаблонов. Контент на эти страницы агентство планировало добавить в последующих раундах. Таблица Google Sheets предусматривала раздел отзывов пациентов в карте сайта, но на момент сборки у клиники ещё не было отзывов — эта страница была построена как экземпляр шаблона и отложена до появления контента после запуска. Это ограничение, присущее созданию сайта для клиники, которая ещё не начала приём пациентов. У сайта новой клиники — особый структурный риск, которого нет при редизайне или миграции. Готового контента нет, и каждое архитектурное решение, принятое при доработке темы, становится фундаментом, на котором агентство потом строит SEO. Для агентства вопрос конкретный: будет ли команда разработки точно следовать запланированной структуре URL из таблицы Google Sheets — даже для страниц без контента — или упростит архитектуру ради экономии объёма работ. Упростить — значит переделывать SEO-структуру позже, когда редиректы и миграции контента стоят в разы дороже. Все 98 URL из таблицы Google Sheets мы построили по плану, включая геолокационные поддиректории, — независимо от того, был ли контент на момент сдачи. > **Контекст рисков.** У новой клиники нет унаследованного набора URL, который нужно сохранять, а это значит, что архитектурные решения первой сборки дорого обойдутся при последующих изменениях. Для сайта с пятью геолокационными директориями услуг, каждая со своими подстраницами, возникает соблазн пропустить пустые страницы и построить их, когда появится контент. Такой подход сбрасывает счётчик индексации для каждого отложенного URL — агентству придётся перестраивать структуру, настраивать редиректы и заново индексировать страницы при наполнении контентом, вместо того чтобы запуститься на уже готовом к поиску наборе URL. 98-URL-структура Maison Dental Studio была спланирована в таблице Google Sheets до начала разработки. Полное её построение, включая 74 страницы в ожидании контента, не оставалось на усмотрение — это было архитектурное обязательство, от которого зависела будущая SEO-работа агентства. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Шаблон Luminous задавал брендированную структуру. Макет главной страницы в Figma был визуальной спецификацией. Там, где Figma требовала определённых макетов — включая блок двух врачей, фотогалерею «до и после» и геолокационные разделы услуг — мы строили их на основе существующих компонентов шаблона, дорабатывая на уровне конкретного клиента, а не модифицируя общие элементы шаблона. **2. 2 профиля врачей на одном шаблоне.** Шаблон страницы врача Maison Dental Studio был применён и для Dr. Kaleb Murray, и для Dr. Sam Mullen — каждый со своими данными, фотографиями и биографией. Таблица Google Sheets агентства включала отдельный Google Doc для страницы каждого врача. В ходе QA выяснилось, что на одной странице стояла чужая фотография — показывался не тот врач. Ошибку поймали и исправили до сдачи в обычном цикле очереди задач. **3. Каркас как приоритет для будущей архитектуры URL.** 74 из 98 запланированных страниц не имели контента клиента на момент сборки — таблица Google Sheets агентства явно это отметила, и записи в чате подтверждают, что команда выявила и зафиксировала каждый пробел в CX-очереди задач, а не создавала страницы-заглушки молча. Пять геолокационных директорий услуг (Broussard, Lafayette, Milton, New Iberia, Woodlawn — каждая с пятью подстраницами услуг) построили точно по URL из карты сайта, включая 15 внутренних редиректов, которые направляли начальный трафик в ожидании наполнения контентом. Откладывание 74 страниц на потом означало бы реструктуризацию URL с редиректами в момент наполнения контентом — и сброс счётчика индексации для каждой такой страницы. Мы построили полный каркас сразу, чтобы SEO-архитектура агентства оказалась готова с первого дня и не требовала переделки при добавлении контента. **4. Цикл QA в масштабе доработки темы.** Из 23 задач, отслеживаемых в Redmine, 15 были итерациями QA — отдельными раундами, в которых агентство отмечало расхождения в дизайне и контенте по очередям задач SEO и CX. Общая очередь задач насчитывала 127+ пунктов: SEO-задачи (удаление логотипа, обработка раздела отзывов, отсутствующие изображения, точность meta-title, структура URL) и CX-задачи (несоответствие контента и дизайна на странице блога, решения по макету контактов, корректность фотографий врачей, скрытие разделов без подтверждённого контента). Каждый раунд закрывался только после подтверждения решения проверяющим со стороны агентства. **5. Проверка на разных устройствах.** QA охватывало большие экраны, планшеты и мобильные устройства для каждой затронутой страницы в каждом раунде. Отклонение в типографике от Figma (заголовок 96 px, слишком крупный для рабочего сайта) было выявлено в ходе QA и скорректировано с участием агентства. Макет страницы контактов был доработан в ходе прямого диалога разработчика и QA для решения проблемы композиции формы и изображения. Смещения макета на мобильных устройствах (выявленные после запуска) были устранены через отдельные задачи по исправлению. Для клиники без готового контента каркас и был основной работой, а не отдельным этапом. Все 74 страницы без контента построены по URL из карты сайта до появления какого-либо наполнения — SEO-архитектура агентства с первого дня на месте, без переделки при добавлении контента. ## Контроль качества Site Checker нашёл остаток от шаблона в контактном блоке Luminous dental template — калифорнийский адрес-заполнитель с кириллическим URL Google Карт; на любой странице, унаследовавшей этот блок, он дал бы битые ссылки. Разработчик подтвердил, что блок не используется, и удалил его до передачи. QA перед передачей прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) с перечнем категорий и порогом нулевых ошибок. Собственный QA-контур агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до момента их подписания. Доработки оставались в переопределениях на уровне клиента; общие компоненты шаблона Luminous агентства не модифицировались. Проверки AutoQA (ссылки, почта, контент через AI) — под управлением агентства — работали на этом проекте согласно вкладке AutoQA Setup в таблице Google Sheets. ## Результаты Параметр Результат Готовых URL на момент передачи **24** — главная · о нас · 2 биографии врачей · команда · галерея улыбок · технологии · регионы обслуживания · блог · контакты · варианты оплаты и финансирование · 9 страниц услуг Полный каркас URL построен **98 URL** — все запланированные страницы построены по спецификации, включая 74 страницы в ожидании контента Геолокационная структура услуг **5 директорий × 5 подстраниц услуг** (Broussard · Lafayette · Milton · New Iberia · Woodlawn) построены по спецификации карты сайта Применённые шаблоны **10 из 10** шаблонов Luminous dental template применены на сайте Контрольный список запуска **78 пунктов** на этапах разработки и QA Задачи QA/SEO отслежено и решено **127+** пунктов согласовано (101 SEO + 26 CX) по вкладкам очереди задач агентства Итерации QA в Redmine **15 из 23 задач** отслежено на уровне итераций Сроки **100 дней**, выполнено по графику Трудозатраты **64 часа** на разработку, QA и исправления — в рамках оценки Команда **5 специалистов** Хостинг Запущен в шаблонной среде агентства на Kinsta Если коротко: макеты Figma агентства реализованы на базе Luminous dental template; полная архитектура на 98 URL построена по плану таблицы Google Sheets; 24 страницы были переданы с подтверждённым контентом; оставшийся каркас на 74 страницы чист и готов к наполнению — за 100 календарных дней, в рамках сметы по часам. ## Процесс Этап Длительность Результат Бриф и оценка ~5 дней (12–17 сен) Figma изучена, доступ к Kinsta подтверждён, объём согласован (17 ч оценка на начальную сборку) Доработка темы — первичная сборка ~1 неделя (17–26 сен) 24 страницы с контентом построены; каркас на 98 URL структурирован; биографии врачей, галерея, геодиректории построены Итерации QA — раунд 1 (параллельно) ~1 неделя (22–30 сен) Агентство отметило 127+ пунктов SEO и CX; проверка, исправления изображений, правки макета выполнены Передача агентству 30 сен Сайт передан агентству на проверку Раунды исправлений — окт–ноя 2025 ~6 недель Пункты таблицы, отсутствующие изображения, предрелизные исправления, 15 подзадач QA закрыто Финальное исправление — смещение макета ноя–дек 2025 Проблема смещения макета на мобильных устройствах решена в четырёх подзадачах QA; финальное закрытие 21 дек _Разработка и QA велись параллельно на всём протяжении проекта — цикл очереди задач от первоначальной передачи до финального подписания занял почти 3 месяца, что характерно для сборки сайта новой клиники, где наполнение контентом и утверждение дизайна происходят поэтапно._ ## Команда **Команда проекта** - **Евгений Карпов** — ведущий разработчик (доработка темы, привязка макетов Figma, начальная сборка) - **Тимур Арбаев** — руководитель QA (раунды проверки, управление очередью задач, контроль подписания) - **Павел Сажин** — итерации QA и раунды исправлений - **Никита Тумашевич** — разработчик (координация команды на этом проекте) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Дизайн, контент-стратегия, отношения с клиентом и хостинг-инфраструктура оставались в ведении агентства на всём протяжении проекта. Команда разработки не имела прямого контакта с Maison Dental Studio. Задачи направлялись через общую очередь задач агентства, и каждый раунд закрывался только после утверждения проверяющим со стороны агентства. ## Агентствам с библиотекой шаблонов > На сайте стоматологической практики, собранном из шаблона, граница между общим слоем и клиентскими правками — самое уязвимое место. У этой практики — одна клиника с типовым списком услуг; у других — сеть филиалов, где каждый диктует свои блоки, контентные макеты и редакторские роли. Если границу не выстроить на старте, доработки развалятся при первом же обновлении родительского шаблона. Редакторский интерфейс для сотрудников клиента перестанет быть понятным — часть функций окажется недоступна в админке. Подрядчику стоит задавать не вопрос «сверстаете ли макеты на этом шаблоне?», а вопрос «как именно вы отделите наш слой переопределений от ядра, чтобы следующее обновление не удалило проделанную работу?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы проверим, как ваши доработки уживаются с ядром шаблона, и подсветим места, где следующее обновление их сломает. Вернём фиксированную смету в часах. Без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-prosthodontics-84h-70-days/ title: 60-страничный сайт стоматологической ортопедии на WordPress за 70 дней type: case_study date: 2025-09-23T17:11:23+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке Более 60 страниц сайта стоматологической ортопедии на WordPress, свёрстанного по дизайн-референсу из Webflow: каждый URL тестовой среды сверяли с визуальной спецификацией агентства, каждую вкладку обхода Screaming Frog держали за структурный контракт. Точность совпадения двух платформ была на нас: проверка по дизайну и проверка по данным обхода шли параллельно все 84 часа и 70 дней — так агентство могло отстоять перед своим клиентом и визуальное соответствие, и целостность опубликованного сайта. ## Краткий обзор Параметр Значение Сфера клиента Медицина — стоматология (ортопедия) Клиент Ocean Breeze Prosthodontics (Delray Beach, FL) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor на WP Engine, с соответствием дизайн-референсу из Webflow Объём **60+ URL** — главная, о нас, биографии врачей, страница услуг, страницы ортопедических и косметических услуг, галерея улыбок, лендинг блога + посты, контакты, политика конфиденциальности и вспомогательные страницы по умолчанию Сроки 70 дней (1 фев – 11 апр 2025), выполнено в срок Затраты **84 часа** (61 ч основная разработка + 23 ч исправления и работы после запуска) Команда 5 специалистов (ведущий разработчик + разработчик поздней фазы + QA + QA после запуска + руководитель проекта) Шаблоны **10 переиспользуемых шаблонов** — стандартная библиотека стоматологических шаблонов агентства Технологии WordPress · Elementor · WP Engine · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **60+ URL построены по 10 шаблонам, контрольный список запуска на 48 пунктов закрыт, 7 из 27 пунктов очереди правок по соответствию дизайну отмечены как выполненные, 22 редиректа отсутствующих страниц сопоставлены, 23 проблемы с H1 решены, 1 ошибка 404 исправлена, 2 битые ссылки закрыты** **Ритм взаимодействия** 27 задач от агентства · все закрыты к моменту передачи **Раунды проверки** ≈3 раунда за 70 дней **Контрольный список запуска** 48 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Ocean Breeze Prosthodontics — практикой в Delray Beach, специализирующейся на ортопедическом лечении, косметической стоматологии и дентальной имплантации — передало нам таблицу Google Sheets с полной картой URL, дизайн-референсом из Webflow (wond-obp.webflow.io), каталогом шаблонов, контрольным списком запуска на 48 пунктов и экспортами обхода Screaming Frog исходного сайта. Разработка велась на их окружении WP Engine; конструктором страниц был Elementor. Агентство владело стратегией, контентом, дизайном в Webflow и общением с клиентом. Мы отвечали за исполнение: применение шаблонов, сборку страниц, точное соответствие дизайну и QA на основе обхода. Задача: воссоздать существующий список URL практики на WordPress + Elementor, обеспечить постраничное соответствие референсу из Webflow, проработать хвост исправлений и закрыть контрольный список запуска. Затем, после запуска, исследовать ошибки 404, исправить ссылки на изображения в блоге и устранить несоответствия H1, выявленные сравнением данных обхода. > **Контекст рисков.** Когда новый сайт заменяет работающий на том же домене, агентство рискует не тем, получится ли собрать страницы, — а тем, сохранит ли замена структурные сигналы, которые старый сайт уже заработал. Подрядчик, который аккуратно собирает страницы WordPress, но оставляет расхождения H1, ошибки 404 на отсутствующих страницах и битые внутренние ссылки, разом приносит победу по дизайну и поражение по SEO. Бриф проекта строился именно вокруг этого: дизайн-референс из Webflow — визуальный контракт, вкладки обхода Screaming Frog (H1 issues, Missing pages, 404, Broken links) — структурный. Оба нужно было закрыть, чтобы агентство отстояло сборку перед своим клиентом. Webflow-референс включал страницы — галерею улыбок, несколько разделов услуг, — которым на работающем сайте не было контента-пары: эти строки нельзя было собрать ни из 1 источника, и для них понадобился отдельный раунд уточнений с агентством. ## Как мы это сделали **1. 10 шаблонов, 60+ URL, единый процесс сборки.** Страницы Ocean Breeze распределились по стандартной библиотеке стоматологических шаблонов агентства: Главная, О нас, Страница врача, Страница услуг, Страница услуги (самая объёмная — охватывает ортопедическое лечение, косметическую стоматологию, общую стоматологию и пародонтологические услуги), Галерея улыбок, Лендинг блога, Страница блога, Контакты, Политика конфиденциальности и шаблон по умолчанию для вспомогательных страниц. Каждую страницу собирали по назначенному шаблону из строки карты сайта; ни одну не верстали вручную в обход шаблонной системы. Там, где дизайн Webflow и контент работающего сайта расходились — разная структура заголовков, отсутствующие разделы, страницы, что были в одном источнике, но не в другом, — команда брала за основу контент работающего сайта и максимально точно подгоняла под него дизайн-спецификацию, а неразрешимые расхождения отдавала агентству, не угадывая и не дублируя контент. **2. Спецификация выполнена строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Дальше держались сметы строго: в сумме проект уложился в согласованный 61 час на основную разработку. Коротко: карта сайта с дизайном — это контракт. Задача команды разработчиков — уложиться в согласованную смету, а не открывать обсуждение цены страница за страницей. **3. Проверка по дизайн-референсу Webflow.** Вкладка очереди правок по соответствию дизайну в таблице Google Sheets держала 27 пунктов, каждый сравнивал URL тестовой среды с его референсной страницей в Webflow: «Page should be formatted to this — https://wond-obp.webflow.io/services/…» Семь из них проверили и закрыли как Completed по ходу разработки; остальные ушли в хвост исправлений. Отдельно вкладки из Screaming Frog — H1 issue (23 строки), Missing pages (22 строки), 404 (1 строка) и Broken links (2 строки) — давали структурный слой проверки, идущий параллельно с очередью правок по дизайну. **4. Проверка по данным обхода после запуска и цикл исправлений.** После запуска агентство дало нам ещё ряд задач: изображения в блоге, которые ссылались на исходный сайт, а не на новое окружение (поправили — заново выгрузили и заново подвязали медиа), неверные заголовки H1 на части страниц (выправили по резервной копии исходного сайта) и пачку кодов 404 из колонки STATUS CODE таблицы Google Sheets (разобрали и закрыли). Контрольный список запуска на 48 пунктов — Дизайн, Функциональность, До миграции, После миграции — закрыли вслед за циклами проверки и на этапе разработки, и после запуска. Спецификация Webflow задавала структурную цель; работающий сайт давал контент — и при сборке на стыке двух платформ эти источники полностью не сходятся никогда. На 9 страницах услуг, где они расходились — другой порядок блоков, пропавшие разделы, — мы держали за основу контент работающего сайта и подтягивали структуру Webflow настолько, насколько он позволял, а неразрешимые пробелы отдавали агентству, а не угадывали. ## Результаты Метрика Результат Разработано URL **60+** по 10 шаблонам (главная · о нас · страницы врачей · страница услуг · страницы ортопедических / косметических / общих / пародонтологических услуг · галерея улыбок · лендинг блога · посты блога · контакты · политика конфиденциальности · вспомогательные страницы) Применено шаблонов **10 / 10** из стандартной библиотеки стоматологических шаблонов агентства Очередь задач по соответствию дизайну **7 / 27** закрыты как Completed в ходе разработки и QA-хвоста Контрольный список запуска **48 пунктов** согласованы по категориям Дизайн / Функциональность / До миграции / После миграции H1-проблемы решены **23** страницы блога и контента исправлены по резервной копии исходного сайта Редиректы отсутствующих страниц сопоставлены **22** пары старый → новый URL задокументированы и решены 404 исправлено **1** ошибка 404 на посте блога закрыта Битые ссылки закрыты **2** внутренние битые ссылки исправлены Сроки **70 дней** (1 фев – 11 апр 2025), выполнено в срок Затраты **84 ч** (61 ч основная разработка + 23 ч исправления и работы после запуска) **Статус сайта** Работает на WP Engine, открывается по адресу https://oceanbreezeprosthodontics.com/ — проверено в апреле 2026. Если коротко: сайт стоматологической ортопедии для агентства мы сдали по 10 шаблонам на WP Engine, в рамках часового бюджета. Проверка по дизайн-референсу и проверка по обходу Screaming Frog шли параллельно через хвост исправлений, а вопросы после запуска закрыли до финальной сдачи. ## Контроль качества До сдачи проверку вели по шести категориям — адаптивность (desktop/tablet/mobile), целостность ссылок, теги H1–H6, title и мета-теги, точность миграции контента и полный архив ссылок — по нашей QA-спецификации. После передачи обход агентства нашёл изображения блога, всё ещё указывающие на исходный домен, и строки STATUS CODE 404 в таблице Google Sheets — и то, и другое мы поправили в своём цикле. До сдачи мы прогоняли проверку через **Site Checker** — категории и порог нулевых ошибок описаны в [нашем подходе к QA](/site-checker/). Своя проверка агентства шла уже после передачи и складывала замечания в общую очередь правок, которую мы закрывали до финального согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя таблица Google Sheets проверена, референс Webflow изучен, построчные часы подтверждены, оценка 61 ч на основную разработку согласована Разработка (страницы + шаблоны) ~2 недели Все 60+ URL построены по 10 шаблонам на тестовой среде WP Engine; открыта очередь задач по соответствию дизайну Хвост исправлений ~4 недели Раунды QA по соответствию формату Webflow, коррекция H1, сопоставление отсутствующих страниц, исправление 404 и битых ссылок; контрольный список продвигался Исправления после запуска + проверка обхода ~3 недели Переприкрепление изображений блога, коррекция заголовков H1 по резервной копии исходного сайта, исследование 404, финальное закрытие контрольного списка _Этапы перекрываются — хвост исправлений начался до закрытия всех пунктов QA этапа разработки, а исправления после запуска шли параллельно с финальными пунктами контрольного списка, поэтому календарный срок составляет 70 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на этапах разработки и исправлений - **Наталия Богатель** — разработчик на поздней фазе доработки, обновлений галереи улыбок и исправлений после запуска - **Павел Сажин** — QA-итерации и исправления - **Анна Полунина** — QA после запуска и проверка - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и общение с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте стоматологической ортопедической практики таксономия процедур задаёт URL-архитектуру, граф структурированной разметки и позиции, которые агентство выстроило в выдаче. У этой практики — протезирование, имплантация и реставрация; у других — терапия, хирургия и ортодонтия. Риски тихие. Новая услуга на шестом месяце не впишется в URL-схему. Структурированная разметка процедур слетит на импорте. Внутренняя перелинковка между базовыми страницами и подвидами услуг разорвётся. Подрядчику стоит задать не вопрос «соберёте ли страницы?», а вопрос «как именно вы построите таксономию, чтобы следующая услуга встала без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим вашу таксономию с ранжированными страницами, оценим, выдержит ли архитектура добавление новых услуг, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-multi-location-17-days/ title: Многофилиальный стоматологический ребилд, сданный по спецификации за 17 дней type: case_study date: 2025-09-18T05:39:18+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 45 часов разработки за 17 дней для стоматологической практики с 2 клиниками в Чикаго — 2 площадки филиалов, 2 набора ссылок на запись Dentrix Ascend и карта сайта, которая разрослась по ходу сборки, когда агентство выложило URL блога и подстраницы филиалов, которых не было в исходном трекере. Мы собирали по спецификации в том виде, в каком она устаканивалась, откладывали неопределённое и подтверждали каждый пробел в объёме до того, как трогать код. Этот кейс — описание одного такого ребилда, где стратегия была за агентством, а исполнение — за нами. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — Семейная стоматология Конечный клиент Sonrisa Family Dental (многофилиальная практика, Chicago, IL: Little Village — Pulaski · Little Village — Esperanza Health Center) **Формат сотрудничества** **White-label WordPress разработка для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта WordPress ребилд на Elementor Pro, хостинг WP Engine Объём работ Полный сайт — услуги, страницы филиалов, интеграция записи, ресурсы для пациентов Сроки 17 дней (28 апр – 15 мая 2025), по графику Трудозатраты 65 часов при оценке 65 часов — без перерасхода Команда 3 специалиста (45 ч разработка · 10 ч PM · 10 ч QA) Технологии WordPress · Elementor Pro · WP Engine · Dentrix Ascend · Gravity Forms · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) QA-плагин) Проверка контента Сверка контента между старым и новым сайтом пройдена перед сдачей — нет пропущенного контента, нет битых ссылок, нет структурных расхождений **Результат** **Спецификация выполнена строка за строкой — полный ребилд сайта, ссылки на запись для каждой локации, контрольный список запуска выполнен** **Раунды проверки** ≈8 раундов за 17-дневное окно ## Постановка задачи У агентства был постоянный стоматологический клиент с двумя клиниками в Чикаго — практика, обслуживающая испаноязычные сообщества в районе Little Village под именем Sonrisa Family Dental. Существующий сайт требовал полного ребилда на WordPress с хостингом на WP Engine. Агентство выполнило стратегическую работу: таблица Google Sheets под названием «Website Redesign Progress Tracker», содержащая все URL для миграции, все meta title для переноса и контрольный список запуска. Задача была конкретной. Взять спецификацию как есть; выполнить ребилд сайта на Elementor Pro; вернуть готовым к переключению. Не выходить на прямой контакт с клиентом. Внедрить SEO-решения как указано. Уложиться в согласованные часы. Одна сторона этого ребилда добавляла объёма, которого нет у клиники с единственным адресом: сайт должен был одновременно обслуживать два разных адреса. Запись — через прямые ссылки Dentrix Ascend — у каждого филиала вела в свою систему приёма. Каждая ссылка филиала должна была вести в нужную клинику. Привяжешь к кнопке записи не тот параметр Dentrix Ascend — и пациент попадёт в форму, которая направит его в другую клинику. Спецификация уточнялась и по ходу сборки: исходная таблица не включала лендинги услуг (`/services/`), филиалов (`/locations/`) и блога/библиотеки (`/library/`). Агентство уже по ходу решило, какие из них включить, какие отложить, а какие реализовать как есть. Мы держали паузу до этого подтверждения, а не додумывали намерение. Никаких творческих решений с нашей стороны — каждый структурный выбор оставался за агентством. > **Контекст рисков.** Многофилиальная стоматологическая практика, обслуживающая определённое сообщество, несёт иные риски при ребилде, чем однолокационная общая практика. Процесс записи — не один путь конверсии, а два, по одному на клинику. Каждая ссылка Dentrix Ascend содержит идентификатор пациента конкретного сайта — привяжите не тот идентификатор к адресу не той клиники, и сайт будет визуально работать, но направлять пациентов не в ту очередь записи. Сбой не обнаружится на QA (кнопка срабатывает, форма загружается) и проявится только когда пациент придёт в клинику, где о нём нет записи. Проверка интеграции записи по каждой локации, в соответствии со спецификацией, не опциональна. ## Как мы это сделали **1. Сборка на шаблонах.** Вместо того чтобы пересобирать каждую страницу по отдельности, мы построили систему шаблонов под семейную стоматологию с двумя филиалами: - **Главная страница** и **Контакты** — входные и конверсионные страницы - **Лендинг услуг + страница услуги** — таксономия услуг, обеспечивающая все отдельные страницы лечения - **Страница филиала** — отдельный шаблон под несколько адресов, на котором держались обе клиники (адрес Pulaski; адрес Esperanza Health Center), у каждой — своя ссылка на запись Dentrix Ascend - **О нас, Лендинг блога, Стандартный шаблон** — вспомогательные страницы по спецификации Шаблон филиала был несущим элементом: он должен был держать точную NAP-информацию (адрес, телефон, ссылка на карты) по каждой клинике отдельно, с правильной вставкой записи для каждого филиала. **2. Спецификация выполнена строка за строкой, по таблице агентства.** Агентство дало таблицу Google Sheets со всеми URL для миграции, всеми требованиями к метаданным и контрольным списком запуска. Мы реализовали каждую строку как указано. Когда в исходной спецификации нашлись пробелы — три лендинга (`/locations/`, `/services/`, `/library/`), которых ещё не было в карте сайта, — мы вынесли это агентству и придержали эти страницы до явных указаний. Лендинг услуг собрали; лендинг библиотеки отложили по указанию агентства. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не толковать его по-своему. **3. Проверка обходом, а не «на глаз».** Перед переключением DNS мы прогнали Screaming Frog параллельно на действующем сайте и тестовой сборке. Коды ответа, цепочки редиректов, как открываются внутренние ссылки — каждое расхождение сверяли со спецификацией агентства. Особое внимание — ссылкам на запись: URL Dentrix Ascend каждого филиала сверяли с параметрами из брифа. Второй обход после запуска подтвердил, что все внутренние ссылки открываются на опубликованном сайте. **4. Контрольный список запуска закрыт перед сдачей.** Контрольный список агентства охватывал проверку перед миграцией по всем категориям: дизайн, функциональность, контент, SEO и аналитика, адаптивность, проверка интеграций (запись Dentrix по филиалам, маршрутизация писем Gravity Forms, перенос GA/GTM) и DNS-миграция на WP Engine. QA на разных устройствах: Chrome / Firefox / Safari / Edge и шесть разрешений (1920 / 1280 / 1024 / iPad / мобильная портретная / мобильная альбомная). Здесь сработала одна вещь — держать паузу там, где в спецификации были пробелы. Трёх лендингов — `/locations/`, `/library/`, `/services/` — по ходу сборки не было в исходной таблице; мы вынесли это агентству и ничего на этих страницах не строили до указаний. Ссылки на запись шли по тому же правилу: параметр Dentrix Ascend каждого филиала сверяли со спецификацией до привязки, а не достраивали из контекста. ## Результаты Метрика Результат Верность спецификации — сборка Полный сайт перестроен по спецификации — все страницы, все мета-данные, все интеграции как указано Верность спецификации — интеграция записи Ссылки на запись Dentrix Ascend по филиалам сверены со спецификацией — маршруты Pulaski и Esperanza Health Center подтверждены Верность спецификации — редиректы Все требования к редиректам из таблицы реализованы как 301 Сроки **17 дней**, сдано по графику Трудозатраты **65 ч / 65 ч** — без перерасхода, без расширения объёма Проверка адаптивности Ноль проблем с вёрсткой на 4 браузерах × 6 разрешениях Внутренний QA Все задачи из объёма агентства закрыты перед сдачей **Статус сайта** Работает на WP Engine по адресу https://sonrisafamilydental.com/. Продолжение сотрудничества Улучшения после запуска, включая редизайн главной страницы — каждый этап сдан в дополнительных спринтах в рамках тех же отношений с агентством Если коротко: спецификация агентства была выполнена как написано, в согласованные часы, в запланированный день переключения. ## Контроль качества Сверка на расхождения поймала две перевёрнутые URL-пары — страницы по адресу `/invisalign/services/`, тогда как все остальные в этом разделе шли по `/services/invisalign/`, — а ссылки на запись Dentrix Ascend по филиалам сверили с двумя разными параметрами `pid` из брифа (`ASC2000000000958` для Pulaski, `ASC2000000000895` для Esperanza Health Center) до того, как сборка ушла из тестовой среды. QA перед сдачей проводился через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Свой проверочный контур агентства шёл после сдачи, и найденные проблемы попадали в общую очередь правок для нашего цикла исправлений до их утверждения. ## Процесс Фаза Длительность Результат Бриф и оценка 1 день Спецификация агентства изучена; 65 ч согласовано Разработка ~12 дней Полный сайт перестроен через шаблоны на тестовой среде WP Engine Внутренний QA и проверка 2 дня Задачи из очереди разобраны; ссылки на запись по филиалам проверены Проверка спецификации 1 день Редиректы, мета-данные, интеграции записи сверены с таблицей Сдача и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Фазы пересекались (QA шёл параллельно завершающей разработке), поэтому календарный срок — 17 дней, а не сумма отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Павел Сажин** — QA и реализация исправлений после запуска - **Анна Полунина** — координация проекта, сверка объёма работ с таблицей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, утверждение) Конечный клиент нас не видел на протяжении всей работы. Все решения о том, какие страницы создавать, какие локации включать, какие ссылки на запись использовать и как обрабатывать страницы, отсутствовавшие в исходной спецификации, полностью принадлежали агентству — мы общались через агентство, а не напрямую со стоматологической клиникой. ## Агентствам, заказывающим ребилд WordPress > На ребилде сети филиалов запись завязана на конкретный адрес клиники: у этой практики — несколько филиалов с раздельными потоками записи, у других — одна клиника с единственной воронкой. Сбой тихий: пациент жмёт ссылку филиала и попадает не в ту очередь приёма. Карта редиректов теряет строки — ранжируемые агентством страницы филиалов отдают 404. Разметка по каждой клинике слетает на импорте — расширенные сниппеты исчезают. Вопрос не в том, «соберёте ли заново», а в том, как именно вы проверите путь записи каждого филиала до переключения. Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы проверим поток записи по каждому филиалу, пройдём каждую строку редиректов и вернём смету в фиксированных часах. Без оплаты, со сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-40h-39-days/ title: Доработка стоматологической темы — 39 дней, 40 часов, поэтапный запуск в Joplin MO type: case_study date: 2025-09-14T04:32:34+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 19 страниц из 84-URL стоматологической карты сайта, доработанные по шаблону «Glowing» агентства на Kinsta, с указанным в Figma шрифтом Adobe Typekit (EB Garamond), интеграция которого не была предусмотрена в ТЗ. Вопрос закрыли в первую неделю, до начала доработки страниц. Остальные 65 URL карты сайта остаются достраиваемыми на том же фундаменте: каждое изменение в предрелизном наборе живёт внутри клиентского слоя переопределений, без правок общих компонентов шаблона агентства. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая стоматология Конечный клиент Northside Family Dentistry (Joplin, MO) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный стоматологический шаблон «Glowing» агентства + постраничный дизайн в Figma на Kinsta) Объём **Предрелизный набор** — главная, о нас, лендинг услуг, **8 страниц категорий услуг**, страница врача, контакты, информационный хаб для пациентов, лендинг зон обслуживания; выделено из 84-URL карты полного сайта Сроки 39 дней (19 дек 2025 – 27 янв 2026), в срок Трудоёмкость 40 часов — разработка, итерации QA и управление проектом Команда 4 специалиста Шаблоны **7 переиспользуемых шаблонов**, применённых к предрелизному набору страниц: Главная, О нас, Лендинг услуг, Страница услуги, Стандартный шаблон, Контакты, Зона обслуживания Техстек WordPress · Elementor · Kinsta · постраничный дизайн из Figma · интеграция шрифта Adobe Typekit · AutoQA агентства (телефон / ссылки / email / Content AI / визуальные проверки) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **45+ отслеживаемых замечаний проверки агентства**, занесённых в общую очередь задач в рамках контрольного списка запуска из 78 пунктов **Ритм взаимодействия** 3 задачи от агентства · 1 из 3 закрыта к моменту передачи **Раунды проверки** ≈5 раундов проверки за 39 календарных дней **Контрольный список запуска** 78 пунктов, согласованы перед переходом ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Northside Family Dentistry — частной клиники общего профиля в Joplin, Missouri — вместе с правами развёртывания на их брендированном стоматологическом шаблоне на Kinsta. Агентство уже выполнило подготовительную работу: исследование клиента, утверждение дизайна, контент-план, настройку хостинга и 84-URL карту сайта, отражающую полное запланированное веб-присутствие клиники. Что агентству требовалось от нас — доработка для запуска предрелизного набора с сохранением структуры сайта, изначально спроектированной для расширения. Задача состояла из 2 частей. Первая: взять Figma агентства и стоматологический шаблон «Glowing» и согласовать их постранично для подмножества страниц, отмеченных агентством и клиентом для первого релиза. Вторая: сделать это, не затронув шаблон таким образом, чтобы потребовалась переделка при добавлении оставшихся 65 страниц. Предрелизный набор — не упрощённая версия полной разработки; это та же строгость, что и в полной разработке, только на меньшем объёме, с дополнительным ограничением: всё, что осталось за рамками, должно без проблем достраиваться на том же фундаменте. Агентство страховалось от ситуации, когда подрядчик воспринимает частичный объём как приглашение к упрощениям. Стоматологический шаблон, активно используемый в нескольких клиниках, содержит общие компоненты — заголовки, подвалы, элементы навигации, стили кнопок, — на которых держатся все обслуживаемые им сайты. Подрядчик, меняющий общие компоненты ради того, чтобы 1 проект совпал с Figma, портит их для всех остальных клиник на том же шаблоне. При поэтапной сборке риск удваивается: упрощения, невидимые в предрелизном наборе, вылезут конфликтами и откатами дизайна при запуске второй фазы. Агентство нанимало нас именно за то, чтобы держать доработки строго в клиентском слое переопределений: соответствие Figma, ноль изменений в общих компонентах. > **Контекст рисков.** Поэтапный релиз на 84-URL таксономии — не меньший проект; это та же строгость, что и в полном проекте, только на частичном объёме, с дополнительным ограничением: каждое решение первой фазы либо оставляет путь к фазе 2 открытым, либо закрывает его. Подрядчик, трогающий общие компоненты шаблона ради того, чтобы 1 страница совпала с Figma, подрывает фундамент для оставшихся 65 страниц ещё до того, как они будут спланированы. Упрощения невидимы в предрелизном наборе; они вылезут конфликтами и откатами дизайна, как только начнётся фаза два. Агентство наняло нас именно за то, чтобы все доработки первой фазы остались строго в клиентском слое переопределений — тогда расширение можно строить на чистом фундаменте. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Стоматологический шаблон «Glowing» — каркасом страницы. Для каждой страницы предрелизного объёма мы сравнивали Figma со стандартным выводом шаблона и дорабатывали только там, где они расходились — каждое изменение внутри слоя переопределений клиента, ничего в общих компонентах шаблона. Никакие дизайн-решения не исходили от нас. Там, где Figma задавала элементы макета, не поддерживаемые напрямую существующим набором компонентов шаблона — например, нестандартные структуры Hero-секций — мы выбирали чистую разметку Elementor вместо шаблонных или ACF-полей, чтобы доработка оставалась внутри слоя переопределений без изменения общих компонентов шаблона агентства. **2. Разрешение шрифта и ресурсов на старте.** Дизайн в Figma использовал лицензированный шрифт Adobe Typekit (EB Garamond), не входивший в стандартную поставку шаблона. До начала доработки мы решили вопрос встраивания шрифта — запросили CSS-код Typekit у агентства и подтвердили доступность полного набора начертаний, требуемых дизайном. Начать доработку до подтверждения шрифта означало бы протащить визуальное расхождение через все последующие раунды QA. Решение вопроса в первые дни сжало цикл итераций. **3. Цикл проверки в масштабе доработки темы.** Чистая доработка не делается по принципу «собрал один раз, проверил один раз». Это «собрал, проверил, поправил, проверил, поправил». Агентство отслеживало **45+ отдельных замечаний** в общей очереди задач — отдельные мелкие вопросы: от привязки кнопок и выравнивания макета до точности meta-title и мобильной адаптивности — каждый пункт требовал исправления, выкладки на тестовый сервер и нового подтверждения агентства перед закрытием. За этими 45 пунктами стояли 40 подзадач итераций проверки, отслеживаемых в Redmine. Объём — свидетельство точности, а не нестабильности. Коротко: на шаблоне ценность даёт именно цикл проверки. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без дрейфа.** Каждое отклонение от стандарта шаблона — макеты страниц, компоненты секций, токены стилей, встраивание шрифтов, варианты кнопок — мы укладывали строго в слой переопределений клиента. Общие компоненты шаблона «Glowing» агентства не трогали. Предрелизный сайт и страницы второй фазы расширения будут использовать один и тот же фундамент шаблона, потому что ни одно упрощение в фазе один его не затронуло. **5. Проверка на разных устройствах.** Доработки проверяли на большом экране, планшете и мобильных устройствах. Мобильные проблемы — включая сбой раскладки кнопок на узких экранах, потребовавший точечного CSS-исправления — выявляли и устраняли в цикле проверки до передачи. Каждый раунд охватывал страницы, затронутые изменениями этого раунда, а не весь сайт; именно так поэтапная сборка остаётся экономной без потери покрытия. Шрифт нужно было подтвердить в первую очередь. Встраивание Adobe Typekit отсутствовало и в Figma, и в ТЗ — закрытый в первые дни вопрос означал, что каждый последующий раунд проверял фактический дизайн, а не визуальную замену. С подтверждённым фундаментом 40 раундов проверки за 39 дней фиксировали каждое изменение чисто в слое переопределений шаблона «Glowing», без касания общих компонентов. ## Контроль качества Hero-секции были построены без ACF-полей шаблона — решение принято в первые дни разработки, чтобы изолировать переопределения клиента от общих компонентов шаблона «Glowing»; мобильную регрессию кнопки («Button looks OFF on mobile») поймали и устранили в финальном раунде QA перед передачей. Проверку перед передачей вели через **Site Checker** — см. [наш подход к проверке](/site-checker/) по категориям и порогу нулевых ошибок. Собственная проверка агентства запускалась после передачи и вносила замечания в общую очередь правок для нашего цикла исправлений до окончательного согласования. Доработки оставались в переопределениях клиента; общие компоненты шаблона агентства не модифицировались. ## Результаты Метрика Результат Предрелизные страницы сданы **Главная, О нас, Лендинг услуг, 8 страниц категорий услуг, страница врача, Контакты, информационный хаб для пациентов (финансирование, страховка, членство, формы новых пациентов, скидки ветеранам), лендинг зон обслуживания** Применено шаблонов **7 из 15 стоматологических шаблонов** библиотеки агентства, применённых к предрелизному объёму (фаза два добавит оставшиеся 8 по мере масштабирования количества страниц) Карта полного сайта **84 URL** по всей таксономии услуг клиники — фундамент доработки оставлен чистым для расширения Контрольный список запуска **78 пунктов** — 78 согласованы на момент выгрузки Замечания проверки в очереди задач **45+ замечаний агентства** зарегистрировано и устранено; 40 подзадач итераций проверки отслежено в Redmine Сроки **39 дней** (19 дек 2025 – 27 янв 2026), сдано в срок Трудоёмкость **40 часов** — без перерасхода, без расширения объёма Команда **4 специалиста** Передача хостинга Работает в шаблонной среде Kinsta агентства Состояние страниц при передаче Страницы тестового сервера возвращали HTTP 200 по всему предрелизному объёму Если коротко: Figma агентства реализована на стоматологическом шаблоне «Glowing» для предрелизного набора страниц за 39 календарных дней, в рамках оценки 40 часов — при этом 65-страничное расширение фазы два остаётся достраиваемым с того же чистого фундамента. ## Процесс Фаза Длительность Результат ТЗ и оценка ~3 дня Figma проверена, доступ к шаблону подтверждён, объём (предрелизный vs полная карта сайта) согласован Разрешение ресурсов первая неделя Встраивание шрифта Adobe Typekit подтверждено и интегрировано до начала доработки Разработка доработок ~3 недели Постраничная доработка шаблона под Figma для предрелизного набора Итерации проверки (параллельно) ~3 недели 40 раундов проверки в Redmine + 45 замечаний в очереди задач агентства; каждый пункт закрыт только после согласования агентством Сдача финальный день Предрелизный сайт запущен на Kinsta _Разработка и проверка шли параллельно — это характерно для доработки тем, где ни одна «фаза проверки» не закрывается чисто; цикл идёт непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (доработка шаблона и приведение макетов Figma) - **Тимур Арбаев** — QA и поддержка разработчика в раундах доработки - **Павел Сажин** — итерации QA и коммуникация по проекту - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство управляло отношениями с конечным клиентом, дизайном в Figma, контент-планом и хостингом. Наша команда работала полностью «за кулисами» агентства — запросы на доработку поступали через общую очередь задач, Northside Family Dentistry о нас не знала, и каждая итерация закрывалась только после того, как проверяющий со стороны агентства подтверждал, что исправление выполнено по спецификации. ## Агентствам с библиотекой шаблонов > Сборка на готовом шаблоне для стоматологического сайта — это не быстрый старт, а риск, что доработки не переживут обновления. У этой практики — один кабинет; у других — сетевая стоматология с единым брендом. Доработки в дочерней теме сломаются при первом апдейте. ACF-поля для услуг разъедутся между клиентским слоем и канонической схемой. Администратор не добавит новую страницу: часть блоков спрятана в коде, и он их не найдёт. Подрядчику стоит задавать не вопрос «соберёте ли сайт на шаблоне?», а вопрос «как именно вы гарантируете, что доработки устоят перед обновлением?» Пришлите исходник шаблона, его ID или макеты. Мы проверим, где ваши доработки конфликтуют с родительским кодом, и отметим блоки, которые сломаются при апдейте. Вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-veterinary-16-days/ title: Ребилд WordPress для ветеринарной клиники — Divi на Elementor за 16 дней type: case_study date: 2025-09-10T01:34:36+00:00 case_industry: Ветеринария case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 85 страниц ветеринарного сайта на Divi и Kinsta перестроены по ТЗ из таблицы Google Sheets агентства за 16 дней. Исходный сайт работал на платной теме Divi, чьи иконочные шрифты были невидны в инспекторе браузера; каждую Divi-зависимость — систему иконок, счётчики лайтбоксов, стили форм — нужно было выявить, согласовать с агентством и подтвердить до сдачи, а не после. ## Краткий обзор Поле Значение Отрасль конечного клиента Ветеринария — клиника для домашних животных Конечный клиент Fish Creek Animal Hospital (клиника для домашних животных, Montgomery, TX) **Формат сотрудничества** **White-label WordPress-разработка для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress — Divi → Elementor Pro, хостинг Kinsta Объём Весь сайт — услуги, биографии врачей, формы для пациентов (включая загрузку файлов), запись на приём Срок 16 дней (17 сен – 2 окт 2025), по графику Трудозатраты ~63 часа при оценке ~63 часа — без перерасхода Команда 4 специалиста (~32 ч разработка · QA-раунды · PM) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Разница контента «оригинал / ребилд» проверена до сдачи — ни одного пропущенного фрагмента, ни одной битой внутренней ссылки, ни одного структурного расхождения **Сдано** **85 страниц, 85 мета-заголовков, 10 шаблонов из набора VET-шаблонов агентства (один DENTAL-шаблон адаптирован для галереи пациентов), 8 редиректов — все тестовые URL отдавали HTTP 200 до переключения** **Ритм коммуникации** 3 задачи от агентства — все закрыты к моменту сдачи (активная фаза: 1 день, 2025-10-05 – 2025-10-05) **Раунды проверки** ≈5 раундов в течение 16 календарных дней **Контрольный список запуска** 78 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Fish Creek Animal Hospital — ветеринарной клиникой в Montgomery, TX — привлекло нас для перестройки существующего сайта с нуля на Elementor Pro. Исходный сайт работал на Divi (Elegant Themes), и агентство хотело перенести его на более поддерживаемый современный стек, на хостинге Kinsta. Задача: перестроить каждую страницу в соответствии с оригиналом, реализовать все интеграции, уложиться в оценённые часы и передать проект готовым к переключению DNS. Оставаться вне поля зрения конечного клиента на всём протяжении. Задача была поставлена точно. Работать по карте сайта из таблицы Google Sheets агентства; воспроизвести вёрстку Divi на Elementor Pro; реализовать формы записи клиники, включая загрузку медицинских файлов пациентами; соблюдать ТЗ построчно. Там, где детали реализации исходной темы были проприетарными — например, собственный иконочный шрифт Divi — найти функционально равноценные аналоги и подтвердить до отправки. Никаких импровизаций без согласования. Риск, от которого агентство страховалось, был характерен для данного формата работы: сайт на Divi использует собственную систему иконок, подход к построению страниц и хуки на уровне темы, которые не переносятся на Elementor Pro прозрачно. Типичный сценарий отказа при смене CMS — не пропущенная страница, а виджет, который выглядел нормально в тестовой среде, но на деле был резервной отрисовкой Divi, незаметной до переключения DNS. Именно этот разрыв и нужно было закрыть команде, выполняющей аккуратный ребилд. > **Контекст рисков.** Когда ветеринарная клиника меняет CMS, каждая форма загрузки медицинских записей, каждый уже знакомый клиентам путь записи на приём, каждая страница услуг, уже ранжирующаяся в локальном поиске, становится потенциальной жертвой неточной сборки. Риск проявляется не в момент запуска — он всплывает через неделю, когда поле загрузки файлов не принимает нужные форматы или мобильная вёрстка разваливается на телефоне в приёмной. Ребилд, совпадающий визуально, — необходимое, но не достаточное условие; он должен совпадать с функциональным ТЗ постранично, а затем пройти QA под нагрузкой. ## Как мы это сделали **1. Сборка через шаблоны.** Вместо того чтобы перестраивать каждую страницу по отдельности, мы сопоставили структуру исходного сайта с 10 шаблонами Elementor Pro, покрывающими все типы контента: - Главная, О нас, Контакты и запасной шаблон Default - **Лендинг услуг + Страница услуги** — основная структура клинических предложений - **Страница врача** — отдельные страницы с биографиями врачей - **Лендинг блога + Запись блога** — архив постов и отдельная запись - **Галерея пациентов** — страница с фотогалереей питомцев (находится по адресу `/pet-gallery/`, создана на стандартном шаблоне галереи агентства, адаптированном из стоматологического контекста для ветеринарии) 10 шаблонов, 85 страниц. Будущие правки — в одном месте на тип страницы. **2. ТЗ соблюдено построчно, из таблицы агентства.** Агентство предоставило таблицу Google Sheets — 10 вкладок, покрывающих полный перечень URL, назначение шаблонов, информацию о клиенте, настройки и контрольный список запуска из 78 пунктов с этапами до и после переключения. Мы реализовали каждую строку как указано. Divi-специфичные элементы исходного сайта — в первую очередь иконочный шрифт Divi, использовавшийся для маркеров категорий услуг — потребовали явного согласования. Вместо замены на усмотрение разработчика, мы установили источник (Elegant Icon Font от Elegant Themes, публично доступный), подтвердили соответствие с агентством и реализовали корректно на Elementor Pro. Никакое «похоже, сойдёт» не было отправлено без согласования агентством. Коротко: при ребилде со сменой CMS спецификация весит больше, чем при ребилде в рамках той же CMS, потому что ничего не переносится автоматически. Команда, импровизирующая вокруг ТЗ, теряет не один редирект. Она теряет целую категорию Divi-специфичных соглашений, которые были незаметны ровно до того момента, как перестали быть незаметными. **3. Проверка через обход, а не «на глаз нормально».** До переключения DNS тестовый сайт проверили относительно исходного рабочего: коды статуса, внутренние ссылки, интеграции форм, согласованность контента между страницами. Форму загрузки файлов пациентами — ответственный элемент для ветеринарной клиники, где владельцам нужно отправлять медицинские документы перед приёмом — протестировали сквозным образом, с реальными отправками. QA-раунд подтвердил, что мультиформная вёрстка (с разными типами форм на разных страницах) отображается единообразно по всему сайту. **4. 2 прохода QA до сдачи.** Внутреннее QA провели 2 разработчика — Тимур Арбаев дважды (на разных этапах сборки) — на больших экранах и мобильных устройствах. Второй проход QA фокусировался на точности ребилда и устранил оставшиеся пиксельные расхождения до сдачи. Иконочный шрифт Divi стал зависимостью, определившей профиль риска этого ребилда. Оригинал использовал собственную систему иконок Elegant Themes — недоступную через инспектор браузера — поэтому вместо замены наугад мы отследили её до публичного Elegant Icon Font, подтвердили с агентством и реализовали точно. Это одно решение закрыло разрыв между сайтом, который выглядит перестроенным, и сайтом, который действительно перестроен. ## Результаты Метрика Результат Миграция CMS Divi (Elegant Themes) → Elementor Pro — полный сайт, все типы страниц Точность по ТЗ — страницы **85 / 85** страниц, отдающих HTTP 200 в тестовой среде до переключения Точность по ТЗ — мета-заголовки **85 / 85** мета-заголовков и описаний перенесены из оригинала в ребилд Точность по ТЗ — шаблоны **10 шаблонов** создано и применено на всём сайте (9 из набора VET-шаблонов агентства плюс галерея пациентов на адаптированном стоматологическом шаблоне) Точность по ТЗ — редиректы **8 правил редиректов** реализовано согласно ТЗ Точность по ТЗ — формы Все формы записи, включая загрузку файлов, реализованы и протестированы сквозным образом Точность по ТЗ — иконки Иконочный шрифт Divi заменён на Elegant Icon Font, подтверждён с агентством до реализации QA-раунды 2 внутренних раунда (Тимур Арбаев) — все замечания зафиксированы и исправлены до сдачи Срок **16 дней**, сдано по графику Трудозатраты **~63 ч** — без перерасхода, без расползания объёма Проверка адаптивности QA на большом экране и мобильных устройствах **Статус сайта** Работает на Kinsta, открывается по адресу https://fishcreekanimalhospital.com/. Если коротко: ТЗ агентства реализовано как указано, в рамках оценённых часов, в согласованное окно переключения. Сборка перевела полный сайт ветеринарной клиники с Divi на Elementor Pro без функциональной деградации. ## Контроль качества Сверка контента Site Checker относительно оригинального Divi-сайта выявила лишние H3, добавленные при сборке на Elementor, у которых не было аналогов в исходной структуре заголовков, а проверка `elementor_colors` отметила ненастроенные цвета по умолчанию в настройках Elementor; разработчик проверил их относительно настроенной глобальной палитры и пометил как некритичные, сохранив принцип нулевых ошибок чистым. QA перед сдачей прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и принципа нулевых ошибок. Свой проверочный контур агентства работал после сдачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до получения согласования. ## Процесс Фаза Длительность Результат Бриф и оценка 1 день ТЗ агентства проанализировано; оценка ~63 ч согласована Разработка ~10 дней Полный сайт перестроен на шаблонах Elementor Pro; иконочный шрифт Divi согласован Внутренний QA, раунд 1 1 день Тимур Арбаев — первый проход QA, замечания зафиксированы Исправления и QA, раунд 2 ~2 дня Замечания устранены; второй проход QA подтвердил точность Сдача и передача тестовой среды 1 день тестовая среда на Kinsta сдана, готова к переключению _Фазы пересекаются — QA начался параллельно с завершающей стадией разработки, поэтому календарный срок составил 16 дней, а не сумму отдельных фаз._ ## Команда **Команда проекта** - **Павел Сажин** — управление проектом и QA-итерации - **Тимур Арбаев** — QA (два раунда на разных этапах сборки) - **Наталия Богатель** — ведущий разработчик (полная сборка сайта, миграция Divi → Elementor, система шаблонов) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Партнёрское агентство оставалось публичным подрядчиком на всём протяжении. Конечный клиент нас не видел на каждом этапе, включая проверку тестовой среды и координацию переключения DNS. Все решения по структуре URL и назначению контента принадлежали агентству; наша роль заключалась в точности реализации предоставленного ТЗ. ## Агентствам, заказывающим ребилд WordPress > При ребилде сайта ветеринарной клиники каждый старый URL, каждая страница услуг и каждая функциональная сцена — запись на приём, форма загрузки документов — могут тихо сломать трафик и конверсии, которые агентство выстроило для клиента. У этой практики — один филиал с общей ветеринарией и простой записью по телефону; у других — сетевая практика с разными филиалами, онлайн-записью, интеграцией с CRM и локальными SEO-страницами. Если подрядчик неаккуратен, старые URL отдадут 404, а позиции упадут; форма загрузки файлов не примет нужные форматы; мобильная запись на приём сломается — всё тихо, через неделю после запуска. Подрядчику стоит задавать не вопрос «сделаете ли ребилд?», а вопрос «как именно вы сохраните карту редиректов и проверите каждый функциональный сценарий до переключения?» Пришлите адрес действующего сайта, черновик карты редиректов (если есть) или макеты. Мы оценим риски для URL и ключевых сценариев, покажем, что может сломаться после запуска, и вернём фиксированную смету в часах. Бесплатно, без обязательств с любой стороны. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-57h-40-days/ title: Новая разработка стоматологического сайта (38 страниц) на WordPress за 40 дней type: case_study date: 2025-09-02T18:42:25+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 38 страниц сайта стоматологической практики мы собрали по одному индивидуальному макету — без библиотечных шаблонов. По ходу работы агентство добавило в объём 68 редиректов блоговых записей; сборка вместила это расширение, не сдвинув ни 40-дневный срок, ни 57-часовой бюджет. Очередь из 40 задач мы прорабатывали параллельно, в 4 раунда проверки; 45 задач от агентства закрыли до сдачи проекта. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Стоматология Конечный клиент Center for Advanced Dentistry (San Jose, CA) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка WordPress с Elementor на хостинге Plesk, затем хвост правок и обратной связи Объём **38 URL** — главная, о нас, услуги (лендинг), 17 страниц услуг, 3 страницы врачей/сотрудников, ресурсы для пациентов, галерея улыбок, лендинг блога и 12 вспомогательных страниц Срок 40 дней (20 янв – 2 мар 2025), сдано в срок Трудоёмкость **57 часов** при оценке 57 часов — без перерасхода Команда 4 специалиста (с упором на разработку; доля PM адекватна для однофазного проекта с хвостом правок) Шаблоны **1 шаблон индивидуального дизайна** — Original Design агентства, применённый к каждой странице Стек WordPress · Elementor · хостинг Plesk · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **38 URL собрано, 68 пар редиректов блога согласовано, контрольный список согласован по разделам Дизайн / Функциональность / Контент / SEO / Адаптивность, очередь из 40 задач закрыта** **Ритм взаимодействия** 45 задач, поднятых агентством · все закрыты к сдаче (активная фаза 16 дней, 2025-02-03 – 2025-02-18) **Раунды проверки** ≈4 раунда за 40 календарных дней **Контрольный список запуска** 49 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Center for Advanced Dentistry — стоматологической практикой общего и косметического профиля в San Jose — передало нам таблицу Google Sheets с полной картой URL, спецификацией индивидуального дизайна, контрольным списком запуска и заранее заполненной очередью задач. Разработка велась на хостинге Plesk под управлением агентства; конструктор страниц — Elementor. Источник дизайна — собственный Original Design агентства, а не библиотека шаблонов. Задача: собрать все 38 страниц по индивидуальному дизайну, перенести 25 записей блога, согласовать 68 редиректов блоговых записей на страницы услуг и лендинги, настроить меню и контактные формы, проработать очередь задач и замечания аккаунт-менеджера по результатам проверки тестовой среды до момента, пока агентство не примет сайт. При этом не выходить на прямой контакт с конечным клиентом; возвращать неясные вопросы агентству; не импровизировать с дизайном, навигацией или CTA. > **Контекст рисков.** Разработка по индивидуальному дизайну — не заполнение шаблона. Дизайн агентства — это контракт, и каждая страница должна ему соответствовать. Риск не в скорости сборки страниц, а в отклонении от дизайн-источника: изображение hero на два пикселя ниже, размер плитки на пару пикселей, мобильное меню, которое не закрывается чисто. На 38-страничном стоматологическом сайте такие отклонения накапливаются. Риск агентства — партнёр-разработчик, который считает «страницы собраны» равнозначным «дизайн соблюдён», а это разные задачи. Предсказуемость важнее изобретательности. ## Как мы это сделали **1. Один индивидуальный дизайн, 38 страниц, один процесс сборки.** Все страницы Center for Advanced Dentistry мы построили на шаблоне Original Design агентства: главная, о нас, лендинг услуг, 17 отдельных страниц услуг (от профилактической стоматологии до имплантации All-on-4), 3 страницы врачей и сотрудников (Meet the Dentists, Dr. Lim, Dr. Perez, Meet the Team), галерея улыбок, лендинг блога, ресурсы для пациентов (For Patients, Post-Op Instructions, FAQ, Refer a Patient) и 12 вспомогательных страниц (Contact, Reviews, Video Testimonials, Sitemap, Privacy Policy и другие). Каждую страницу мы собирали по строке дизайна в карте сайта; ни одна не делалась вручную вне дизайн-системы. **2. Спецификация соблюдена построчно, в рамках согласованной сметы.** Карту URL и дизайн-источник дало агентство; объём в часах по каждой странице мы оценили сами и зафиксировали до старта. Дальше держались этой сметы строго: суммарно проект уложился в согласованные 57 часов, без перерасхода и расширения объёма. Принцип здесь прост: карта сайта с дизайном — это контракт. Задача команды разработки — уложиться в согласованную смету, а не переоткрывать цену страница за страницей. **3. Согласование редиректов блога по 68 уникальным парам URL.** В наследуемом блоге практики было почти 100 записей. Аудит агентства выявил 68 записей, подлежащих удалению и редиректу на соответствующие страницы услуг или лендинг блога. Мы согласовали **68 уникальных пар URL-к-URL** во вкладке RemoveRedirect Blogs — каждая пара была сопоставлена от наследуемого пути блога к конечному целевому адресу и проверена по таблице редиректов. Все строки закрыты до сдачи проекта. **3б. SEO-метаданные перенесены вручную — SEO-плагин не был установлен.** Контрольный список таблицы Google Sheets явно отмечал «No Yoast, RankMath», поэтому мета-заголовки и мета-описания копировались с действующего сайта на каждую новую страницу вручную, а не вытягивались из базы данных плагина. **4. Два параллельных контура QA, закрытых до запуска.** Задачи отслеживались в двух параллельных потоках — очередь задач таблицы Google Sheets (46 строк, 40 закрыто) и проверка тестовой среды аккаунт-менеджером (отслеживалась в отдельном QA-документе и закрыта до сдачи). Контрольный список запуска из 49 пунктов — колонки Дизайн, Функциональность, Контент, SEO и Аналитика, Адаптивность, Домены и DNS — был согласован по применимым категориям до запуска сайта. 40-дневный график выдержали потому, что три потока шли параллельно — 38 страниц по индивидуальному дизайну, 68 пар редиректов и очередь задач в две дорожки. Каждый поток закрывался независимо в рамках общего бюджета 57 часов, поэтому хвост правок вписал расширение редиректов без сдвига сроков и без пересмотра оценки. ## Результаты Метрика Результат URL собрано **38** по 1 шаблону индивидуального дизайна (1 главная · 1 о нас · 1 лендинг услуг · 17 страниц услуг · 3 страницы врачей/сотрудников · 1 галерея улыбок · 1 лендинг блога · 12 вспомогательных страниц) Шаблонов применено **1 / 1** — Original Design агентства применён к каждой странице Пар редиректов блога согласовано **68** уникальных пар закрыто во вкладке RemoveRedirect Blogs Очередь задач **40 из 45** закрыто; 5 в статусе To Do Очередь задач QA аккаунт-менеджера Закрыта — отслеживалась в отдельном документе проверки тестовой среды и проработана до принятия агентством Контрольный список запуска **49 пунктов** согласовано Срок **40 дней** (20 янв – 2 мар 2025), по графику Трудоёмкость **57 ч / оценка 57 ч** — без перерасхода, без расползания объёма **Статус сайта** Работает по адресу https://www.sanjosedentist.com/ — проверено в апреле 2026 Результат, если коротко: 38-страничная разработка по индивидуальному дизайну для агентства сдана на WordPress-окружении Plesk в рамках согласованного бюджета 57 часов. Очередь задач проработана до уровня принятия агентством, цикл QA аккаунт-менеджера закрыт, контрольный список запуска согласован до перехода. ## Контроль качества Проверка на этом проекте разобрала два конкретных случая: пакет из 68 редиректов импортировали без ведущих слешей — и `/blog/highly-recommended-dental-treatments/` уходил на двойной путь, в 404, вместо `/blog/`; а проверка метаданных нашла, что мета-заголовки, мета-описания и h-теги на 38 страницах не совпадают с исходным сайтом. Обе проблемы мы исправили до того, как агентство получило доступ к тестовой среде. Перед сдачей проверка шла через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Собственный QA агентства работал уже после передачи и заносил замечания в общую очередь задач для нашего цикла правок, пока агентство не согласует результат. ## Процесс Фаза Длительность Результат Бриф и оценка ~1 неделя Документ изучен, построчные часы подтверждены, 57 ч согласованы Фаза разработки (страницы + шаблоны) ~3 недели Все 38 URL собраны по Original Design на тестовой среде; открыта очередь задач Согласование редиректов блога ~1 неделя 68 уникальных пар редиректов блога сопоставлены и закрыты Фаза согласования (очередь задач + QA AM) ~2 недели Обе очереди задач прорабатывались параллельно через раунды проверки тестовой среды; 40/46 задач закрыто; QA AM закрыто Контрольный список запуска + сдача финальная неделя Контрольный список из 49 пунктов согласован; сайт переведён на рабочий хостинг _Фазы пересекаются — работа над редиректами началась до закрытия всех пунктов QA фазы разработки, поэтому календарь составляет 40 дней, а не сумму отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на фазах разработки и согласования - **Анна Полунина** — поддержка разработчика на поздних раундах исправлений и настройке контента блога - **Евгений Карпов** — итерации QA и проверка тестовой среды - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > Вы вложились в позиции в локальной выдаче, а через полгода клиент просит новую услугу — и она не встаёт в URL-схему, со страниц врачей слетает разметка адреса, фильтр по услугам ломается. На сайте стоматологии именно таксономия услуг и филиалов держит URL-структуру, граф разметки и позиции, которые вы выстроили; она хрупкая, и сбои тихие — их замечаешь, когда позиции уже просели. Мы проектируем таксономию так, чтобы следующая специальность и новый филиал встали без пересборки: единая схема URL, разметка привязана к шаблону страницы, а не к отдельным записям. У этой практики — одна специализация и два филиала; будь у вас сеть на несколько специальностей с общей воронкой записи, мы разложили бы её на той же схеме. За результат отвечаем мы. Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим URL-таксономию с вашим набором ранжируемых страниц, отметим пробелы в разметке, которые стоят позиций в локальной выдаче, и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-26-page-dental-21-days/ title: Доработка стоматологической темы на 26 страниц за 21 день type: case_study date: 2025-08-28T19:04:15+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 25 внутренних страниц новой стоматологической клиники в Salisbury, NC, собранных по неполному Figma — дизайн главной не был готов на старте, поэтому агентство отложило его и попросило сначала собрать внутренние страницы. Шестнадцать переиспользуемых шаблонов на 26 страниц, 78-позиционный контрольный список перед передачей, 21 день всего, ~12 часов разработки. Главным было пройти полный цикл QA в минимально возможном объёме, без трактовки малого количества часов как разрешения пропускать этапы. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — общая стоматология Конечный клиент Trident Smiles (новая стоматологическая клиника, Salisbury, NC) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **26 URL** — главная (отложена), о нас, лендинг услуг, **11 страниц услуг**, страница врача, лендинг блога + пост, контакты, галерея улыбок и 6 политик / платёжных страниц Сроки 21 день (26 дек 2025 – 16 янв 2026), в срок Трудоёмкость ~12 часов — разработка, итерации QA и управление проектом Команда 3 специалиста Шаблоны **16 переиспользуемых шаблонов** от агентства, применённых ко всем 26 страницам Техстек WordPress · Elementor · Kinsta · постраничный дизайн из Figma · Rank Math · AutoQA агентства (ссылки / email / Content AI / визуальные проверки) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **78-позиционный контрольный список запуска**, согласованный с протоколом проверки перед передачей агентства **Раунды проверки** ≈2 раунда проверки за 21 календарный день **Контрольный список запуска** 78 пунктов, согласовано перед передачей ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Trident Smiles и цель развёртывания на их брендированной системе шаблонов на Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, настройку хостинга, контент-план. Что им требовалось — команда разработки, которая достоверно перенесёт Figma на шаблон и передаст страницы для наполнения контентом. Условия были жёсткими. Дизайн главной страницы и цветовая схема ещё не были готовы, поэтому агентство попросило отложить главную и сначала собрать внутренние страницы — те, что могли уйти контент-команде, пока главная оставалась в дизайне. 26 страниц нужно было сдать достаточно быстро, чтобы контентный конвейер не встал. Агентству нужно было защититься от студии, которая восприняла бы заказ на ~12 часов как «спешку» — пропуск документации шаблона, пропуск проверки перекрёстных ссылок или оставление плейсхолдеров на страницах политик, потому что «нет времени». Стоматологический шаблон в активном использовании обслуживает несколько клиник одновременно; правки под один проект не должны уходить в общий слой. И эта строгость не уменьшается вместе с оценкой часов. > **Контекст рисков.** Новой стоматологической клинике в Salisbury, NC нужно было собрать страницы услуг до того, как дизайн главной будет готов — поэтапная передача, где страницы сначала уходят контент-команде агентства, а главная последует позже. В процессе разработки агентство упростило пять слагов страниц услуг, убрав гео-суффиксы `-salisbury` до более коротких путей. Риск заключался не в объёме редиректов — у клиники не было унаследованного трафика — а в строгой работе с внутренними ссылками: каждую ссылку в меню, хлебную крошку и перекрёстную ссылку нужно было согласовать с новыми слагами до передачи части сайта. Студия, которая обновляет карту сайта, но пропускает пункт меню, оставляет агентству битые пути на сайте, у которого нет существующей аудитории, чтобы поглотить ошибку. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страницы. Наша задача заключалась в постраничном согласовании: где стандартный макет шаблона совпадал с Figma — оставляли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не исходили от нас. **2. Цикл QA в масштабе доработки темы.** Даже на заказе в ~12 часов цикл QA — это то, где создаётся ценность. 78-позиционный контрольный список запуска агентства задавал условия передачи: коды статуса, точность номера телефона, структура URL, согласованность завершающих слешей, уведомления контактной формы, визуальные проверки при 1920 px и на мобильных устройствах, чистота текстового контента. Каждый пункт закрывали до того, как сборка уходила на финальную проверку агентства. **3. Доработка без дрейфа.** В ходе проекта каждое изменение брендированного шаблона — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Ни одна правка не ушла в общие компоненты шаблона; значит, работа по этому проекту не ухудшила шаблон для следующего сайта, который он будет обслуживать. **4. Проверка на разных устройствах.** Доработки проверялись на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждая страница проверялась при 1920 px, 1280 px и на мобильных устройствах, с вниманием к размеру заголовка, поведению мобильного меню и целям касания элементов форм. На лёгком заказе такое покрытие — не роскошь; это разница между сайтом, который выглядит правильно, и сайтом, который просто выглядит собранным. Главная не была готова на старте, а пять слагов услуг упростили в середине проекта. Оба вопроса закрыли без остановки контентного конвейера: внутренние страницы собраны и переданы, пока главная оставалась в дизайне; каждая ссылка меню и перекрёстная ссылка согласована с новыми слагами до выхода частичного сайта со стенда. Новая клиника без унаследованного трафика не может позволить себе битую внутреннюю ссылку при запуске. ## Контроль качества QA перед передачей выявило 404 на подстранице `/cosmetic-dentist-salisbury/invisalign/` и отметило ненастроенное уведомление контактной формы до того, как агентство увидело сборку — та же проверка подтвердила согласованность завершающих слешей и согласование ссылок меню по пяти упрощённым слагам страниц услуг, выполненным в середине проекта. QA перед передачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу нулевых ошибок. Свой контроль на стороне агентства выполнялся после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их утверждения. Доработки оставались в переопределениях клиента; общие компоненты шаблона агентства не модифицировались. Критерии приёмки AutoQA (телефон / ссылки / email / Content-AI / визуальные) — под управлением агентства — были настроены на этом проекте. Проход AutoQA агентства выполнялся после передачи как часть их процесса согласования. ## Результаты Метрика Результат URL сдано **26** — 1 главная (отложена), 1 о нас, 1 лендинг услуг, 11 страниц услуг, 1 страница врача, 1 лендинг блога, 1 пост блога, 1 контакты, 1 галерея улыбок и 6 страниц политик / платежей / юридических Применено шаблонов **16 из 16** переиспользуемых шаблонов, собрано и применено ко всем 26 страницам Контрольный список запуска **78 пунктов**, согласовано с протоколом агентства Согласовано изменений URL **5** упрощений слагов страниц услуг (удаление суффиксов `-salisbury`) с обновлёнными ссылками меню и внутренними ссылками Сроки **21 день**, сдано в срок Трудоёмкость **~12 часов** — без перерасхода, без расширения объёма Команда **3 специалиста** Передача хостинга Стенд в среде шаблонов Kinsta агентства Если коротко: Figma агентства легла на их брендированный шаблон — 26 страниц, 16 шаблонов, 21 календарный день, оценка ~12 часов. Главную придержали до второй фазы передачи, пока не утвердили дизайн. ## Процесс Фаза Длительность Результат ТЗ и оценка ~1 день Figma проверена, доступ к шаблону подтверждён, объём согласован, включая отсрочку главной Разработка доработок ~2 недели Постраничная доработка шаблона под Figma; изменения слагов согласованы Итерации QA (параллельно) ~2 недели Проверка контрольного списка; каждый пункт закрыт перед передачей агентству Раунды исправлений ~2 дня Пострецензентские правки и согласование ссылок Сдача поэтапно Внутренние страницы переданы для наполнения контентом; главная отложена до второй фазы _Разработка и QA выполнялись параллельно — это характерно для доработки тем, где ни одна «фаза QA» не закрывается чисто; цикл идёт непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона и приведение макетов Figma) - **Павел Сажин** — итерации QA, оценка и проверка контрольного списка - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались у партнёрского агентства на всём протяжении. Конечный клиент нас не видел: все запросы на доработку шли через общую очередь задач агентства, и сама разработка Trident Smiles напрямую не показывалась. Каждый раунд QA закрывался только после того, как рецензент агентства подтверждал, что изменение выполнено. ## Агентствам с библиотекой шаблонов > Вы отвечаете за сайт перед клиентом, но граница между общими шаблонами и слоем правок под клиента решает, останется ли он стабильным. У одиночного стоматологического офиса правки локальны; у сети с общей системой они расходятся по десяткам страниц. Настройки, заданные на ранних фазах, молча затираются, когда подгружается канонический шаблон. Динамическая навигация рассчитана на готовую карту сайта — а поэтапная смена слагов оставляет пункты меню, ведущие на несуществующие пути. Правки слоя клиента уходят от спецификации, как только обновляется библиотека шаблонов. Подрядчику стоит задавать не вопрос «соберёте ли на шаблоне?», а вопрос «как вы ограничите правки под клиента, чтобы они пережили поэтапную передачу?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы пройдём по динамическим допущениям шаблона относительно вашего объёма, отметим правки, которые расползутся или сломаются при поэтапной сборке, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-72-pages-18-days/ title: Ребилд стоматологического сайта на WordPress (72 страницы), строго по ТЗ за 18 дней type: case_study date: 2025-08-23T17:11:28+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 72 страницы сайта стоматологической клиники, восстановленные как индивидуальные визуальные копии — каждая страница соответствует оригинальному дизайну, не свёрнута в общие шаблоны — в рамках 18-дневного спринта на WP Engine. Агентство владело картой URL и спецификацией мета-данных; наша команда воспроизвела каждую страницу блок за блоком, сравнивая сборку в тестовой среде с оригиналом через инструмент визуального сравнения перед запуском. Этот кейс — описание одного такого ребилда: агентство владело стратегией, мы — исполнением. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина (стоматология) Конечный клиент Pharr Road Dentistry (Dr. Keya Patel и Dr. Paul McDonald DDS, Atlanta, GA) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг WP Engine Объём 72 URL перенесены как индивидуальные копии оригинального дизайна, с 17 страницами специализированных услуг, архивом блога и интеграцией записи Сроки 18-дневная основная сборка (27 дек 2024 — 14 янв 2025), с циклом исправлений и доработок до марта 2025 Трудозатраты 58 часов — без расширения объёма относительно исходного ТЗ Команда 2 специалиста (46 ч разработка · 12 ч PM) Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) Проверка контента Сравнение оригинального и нового контента пройдено перед сдачей — нет пропущенного текста, битых внутренних ссылок, структурных расхождений **Результат** **ТЗ выполнено строка за строкой — 71 редирект, 71 meta title, 70 meta description, 45 пунктов контрольного списка запуска** Продолжение сотрудничества 7 дополнительных раундов доработок на протяжении 10 недель — исправления главной, очистка 404, задачи перед запуском, обновления ссылок записи, фото сотрудников и корректировки виджетов — каждый в рамках аддитивных спринтов в тех же отношениях с агентством **Интенсивность** 12 задач от агентства · 11 из 12 закрыты к моменту сдачи (74 дня активной работы, 2025-01-13 – 2025-03-27) **Раунды проверки** ≈4 раунда проверки **Контрольный список запуска** 45 пунктов, согласованы перед запуском ## Постановка задачи У Pharr Road Dentistry был существующий сайт на WordPress с широким спектром специализаций — семнадцать страниц услуг, охватывающих всё от зубных имплантов и Invisalign до стоматологии сна и лечения TMJ — плюс активно обновляемый архив блога и интегрированная запись на приём. Агентство уже подготовило карту сайта, провело аудит мета-данных и определило требования к воспроизведению дизайна. Нашей задачей было выполнить ребилд сайта на WP Engine как визуальную копию оригинала, страница за страницей, без сведения индивидуальной вёрстки в общие шаблоны. ТЗ, которое мы получили, было таблицей Google Sheets с шестью вкладками: полная карта сайта с сопоставлением старых URL и новых путей в тестовой среде, повторяющиеся блоки контента, справочник шаблонов, настройки, контрольный список запуска из 45 пунктов и очередь правок. Нам требовалось оставаться вне взаимодействия с клиентом, воспроизвести каждое дизайнерское решение как указано и сообщать агентству о любых несоответствиях в данных. Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на протяжении всего запуска и миграции. Риск, который агентство хотело снять, был не в потере SEO — с этим они справились сами. Риск заключался в разработчике, который относится к ребилду как к разовому запуску, упуская накопление устаревших данных после переключения: неверные номера телефонов в футерах, пустые кнопки, никуда не ведущие, оставшиеся сторонние копирайты, архивные страницы, засоряющие обход. На сайте с семьюдесятью 2 страницами и длинным циклом исправлений после запуска настоящее испытание — не то, загружается ли главная страница в первый день. > **Контекст рисков.** При ребилде такого масштаба зона риска не закрывается на запуске — она простирается на последующие недели, когда пограничные случаи, прошедшие запуск незамеченными, начинают проявляться: устаревшие сторонние интеграции, изображения с 404 на второстепенных страницах, ссылки на систему записи, которая больше не используется клиникой. Риск — не сам запуск, а накопленный шум, остающийся после него: неверные номера телефонов в футерах, пустые кнопки, никуда не ведущие, сторонние копирайты, которые следовало удалить, архивные страницы, засоряющие обход. Каждый из них проявился в реальных раундах исправлений после запуска для этого проекта — устаревшие ссылки записи, сторонний копирайт в футере и нелинкованные иконки соцсетей потребовали отдельных задач на очистку вне исходной карты сайта. На сайте с десятками страниц услуг и последующим сотрудничеством на месяцы настоящее испытание — не то, загружается ли главная, а то, корректна ли каждая страница 3 месяца спустя. Агентство наняло нас, потому что ребилд должен был оставаться чистым под длительным вниманием. ## Как мы это сделали **1. Дизайн-точное воспроизведение, страница за страницей.** Исходный сайт имел индивидуальный дизайн-язык, который агентство хотело сохранить точно — не шаблонизировать, не переосмысливать. Вместо того чтобы сводить вёрстку в переиспользуемые шаблоны, мы восстановили все 72 страницы как индивидуальные визуальные копии, соответствующие оригинальному дизайну блок за блоком: - **Главная** — hero, сигналы доверия и обзор услуг - **Страницы специализированных услуг** — 17 индивидуальных страниц лечения (импланты, виниры, Invisalign, седативная стоматология и другие) - **Страница отзывов** — интеграция отзывов пациентов - **Архив блога и посты** — сетка статей и индивидуальные макеты постов - **Контактная страница** — расположение, форма и интеграция записи 72 страницы, каждая воспроизведена в соответствии с оригиналом. Будущие правки дизайна со стороны агентства управляются постранично, сохраняя индивидуальный визуальный облик каждой страницы. **2. ТЗ выполнено строка за строкой, из таблицы агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции с целевым путём, каждый meta title и описание для переноса, каждое дизайн-назначение, каждую клиентскую интеграцию (CallRail, Google Analytics 4, reCAPTCHA, live chat, NitroPack, проверка копирайта в футере). Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где его не было — мы отметили это для агентства. Никаких «творческих интерпретаций» не было. Коротко: при ребилде ТЗ — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль заключалась в точности реализации переданного ТЗ. **3. Проверка на основе обхода, а не «на глаз».** До переключения DNS мы запустили Screaming Frog на исходном рабочем сайте и сборке в тестовой среде параллельно. Коды статуса, битые ссылки, цепочки редиректов, различия в мета-тегах — каждое расхождение сверяли с ТЗ агентства. Второй обход после запуска подтвердил, что все внутренние ссылки разрешаются на рабочем домене. Обход также выявил ~800 посторонних архивных страниц — их вычистили из индекса перед сдачей. **4. 45 пунктов контрольного списка запуска, закрыты до сдачи.** Семь категорий: дизайн, функциональность, контент, SEO и аналитика, адаптивность, клиентские интеграции и 7-шаговая миграция домена и DNS на WP Engine. Ничего не сдавалось, пока каждый пункт не был согласован. QA на разных устройствах на Chrome / Firefox / Safari / Edge и шести разрешениях (1920 / 1280 / 1024 / iPad / мобильная вертикаль / мобильная горизонталь). 9 задач за 74 дня — основная сборка плюс обновления ссылок записи, очистка 404, исправления главной и фото сотрудников, каждая в своём спринте в рамках тех же отношений с агентством. Регулярный цикл доработок означал, что дефекты, проявившиеся в работе, имели чёткий путь к исправлению, а не переговоры о том, входят ли они в объём работ. ## Результаты Метрика Результат Соответствие ТЗ — редиректы **71 / 72** URL контента перенаправлены, как указано в ТЗ Соответствие ТЗ — мета-данные **71 / 72** meta title и **70 / 72** meta description установлены, как указано в ТЗ Соответствие ТЗ — шаблоны **Оригинальный дизайн** воспроизведён на всех 72 страницах Контрольный список запуска **45 / 45** пунктов согласованы перед запуском Сроки **18-дневная основная сборка**, с последующими доработками до марта 2025 Трудозатраты **58 ч** — без расширения объёма относительно исходного ТЗ Проверка адаптивности Ноль проблем с вёрсткой на 4 браузерах × 6 разрешениях Внутреннее QA Все задачи в рамках агентства закрыты до сдачи (12 из 12 отмечены; 0 осталось) Сдача Сайт запущен на WP Engine, без простоя Статус сайта Опубликован на WP Engine: [pharrroaddentistry.com](https://www.pharrroaddentistry.com/) Продолжение сотрудничества 7 дополнительных раундов доработок на протяжении 10 недель — исправления главной, очистка 404, задачи перед запуском, обновления ссылок записи, фото сотрудников и корректировки виджетов — каждый в рамках аддитивных спринтов в тех же отношениях с агентством Если коротко: ТЗ агентства было выполнено как написано, в рамках указанных часов, все задачи в рамках агентства закрыты. Год спустя сборка всё ещё в работе. ## Контроль качества Сравнение всех 70 URL — оригинал с тестовой средой — выявило две категории дефектов до того, как агентство увидело сборку: несоответствия слагов (`/services/` вместо оригинального префикса `/specialty/`) и сторонняя строка копирайта (`© Copyright 2025 GrowthPlug, Inc`) в футере, которой не было на оригинальном сайте — удалена до сдачи. QA перед сдачей проходило через **Site Checker** — см. [наш подход к QA](/site-checker/) для ознакомления с категориями и порогом нулевых ошибок. Собственный QA-контур агентства работал после сдачи и сводил замечания в общую очередь правок для нашего цикла исправлений до финального согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день ТЗ агентства просмотрено; 58 ч оценены и согласованы Разработка ~12 дней Весь сайт восстановлен как 72 индивидуальные копии страниц Внутреннее QA и проверка ~4 дня 13 задач зафиксированы; все работы в рамках агентства закрыты Проверка ТЗ 1 день Meta и редиректы сверены с таблицей Сдача и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Этапы пересекались (QA шёл параллельно с поздней разработкой), поэтому календарный срок — 18 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и воспроизведение дизайна) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом и SEO-стратегия со стороны агентства оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим ребилд WordPress > Стоматологический сайт — это работающая инфраструктура: запись, таксономия услуг, контакты, по которым принимают пациентов. У этой практики — несколько кабинетов с общей CRM; у других — сетевая структура с независимыми филиалами и брендированным колл-центром. Тихие риски при переносе: карта редиректов потеряет строки — страницы с накопленным весом уйдут в 404. Мета-заголовки и описания перепишутся новой темой — сниппеты в выдаче изменятся за ночь. Схема записи на приём сломается на страницах, которые за агентством не закреплены. Подрядчику стоит задавать не вопрос «сможете ли пересобрать сайт», а вопрос «как именно вы сохраните видимость каждой страницы и работоспособность записи после переноса?» Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим планируемую архитектуру с вашим текущим инвентарём URL и требованиями CRM и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-58h-53-days/ title: Новая разработка сайта стоматологии на 62 страницы за 53 дня type: case_study date: 2025-08-19T04:34:41+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 62 страницы новой разработки WordPress для стоматологической клиники на пяти брендированных шаблонах — 21 пост блога, 26 сервисных страниц — где ключевой особенностью работы была не вёрстка страниц, а реструктуризация URL-путей. 46 унаследованных путей в `/procedures/` и `/about/blog/` были приведены к новой иерархии и проверены в тестовой среде построчно — согласование, которое таблица Google Sheets агентства не предусматривала отдельной вкладкой с редиректами. 58 часов, 53 дня, без перерасхода. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология Конечный клиент Roman Dental Arts (Hackensack, NJ) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах локального бизнеса** Тип проекта Новая разработка WordPress на Elementor, WP Engine, с реструктуризацией URL-путей и миграцией контента блога Объём работ **62 URL** — главная, 4 страницы «О нас», 26 сервисных страниц (косметическая / реставрационная / семейная / челюстно-лицевая / имплантология), 21 пост блога, 10 страниц базового шаблона (ресурсы для пациентов, контакты, отзывы и т.д.) Сроки 53 дня (18 мар – 10 мая 2025), сдано в срок Трудозатраты **58 часов** при оценке в 58 часов — без перерасхода Команда 5 специалистов (35 ч разработка · 10 ч QA · 4 ч PM · 9 ч контент и добавление процедур) Шаблоны **5 переиспользуемых шаблонов** — Homepage, About Us, Service Page, Blog, Default Template Технологии WordPress · Elementor · Gravity Forms · WP Engine · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **62 URL свёрстаны по 5 шаблонам, согласованы 46 уникальных пар URL-путей, список правок 9/9 закрыт как Completed, контрольный список из 29 пунктов согласован** **Ритм работ** 9 задач от агентства · все закрыты к сдаче (1 активный день, 2025-04-07) **Раунды проверки** ≈4 раунда проверки за 53 календарных дня **Контрольный список запуска** 29 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Roman Dental Arts — стоматологической клиникой полного цикла в Hackensack, специализирующейся на косметической, реставрационной, семейной, челюстно-лицевой стоматологии и имплантологии — передало нам таблицу Google Sheets с полной картой URL, каталогом шаблонов, контрольным списком запуска и заранее заполненной очередью ошибок. Разработка велась в их окружении WP Engine, конструктор страниц — Elementor, формы — Gravity Forms. Задача: сверстать 62 URL по 5 стандартным шаблонам, реструктурировать URL-пути, объединив прежние иерархии `/procedures/` и `/about/blog/` в более плоские и чистые пути, перенести 21 пост блога на новую структуру путей и отработать список правок агентства до момента приёмки сайта. Незадолго до запуска агентство передало запрос клиента на новый контент по процедурам для дополнительного набора сервисных страниц — контент-блок, поступивший уже в процессе работы, с привязкой к дате запуска. На протяжении всего проекта — оставаться вне прямого контакта с конечным клиентом; возвращать неясные вопросы агентству; не принимать решений по контенту, навигации или структуре URL самостоятельно. > **Контекст рисков.** Стоматологическая клиника с устоявшимся архивом блога и глубокой таксономией услуг несёт SEO-вес, распределённый по десяткам URL. Риск агентства в такой разработке — не главная страница и не сервисные лендинги, а 46 пар URL, где старый и новый пути различаются: `/procedures/cosmetic-dentistry/veneers/` превращается в `/cosmetic-dentistry/veneers/`, `/about/blog/post-slug/` — в `/blog/post-slug/`. Каждую из этих пар нужно довести до закрытого состояния до запуска сайта. Партнёр-разработчик, для которого согласование путей — техническая деталь в документации, а не контрольная точка сдачи, рискует передать агентству сайт, где SEO-вес унаследованных URL незаметно исчез. В таблице Google Sheets не было отдельной вкладки для отслеживания редиректов — каждую из 46 пар URL-путей пришлось проверять в тестовой среде построчно, а не переносить массово из таблицы редиректов. ## Как мы это сделали **1. 5 шаблонов, 62 страницы, один процесс разработки.** Страницы Roman Dental Arts распределились по компактной, чётко определённой библиотеке шаблонов: Homepage, About Us (4 страницы — основная информация, знакомство с врачами, знакомство с командой и тур по офису), Service Page (26 отдельных сервисных страниц по пяти категориям услуг), Blog (21 перенесённый пост) и Default Template (10 вспомогательных страниц — ресурсы для пациентов, отзывы, контакты, запись на приём и т.д.). Каждая страница свёрстана по назначенному шаблону из строки карты сайта; ни одна страница не делалась вручную вне системы шаблонов. **2. Спецификация соблюдена построчно, в рамках согласованной сметы.** Объём в часах по каждой строке карты сайта мы оценили сами и зафиксировали до старта. Корпус блога из 21 поста был ключевой строкой: миграция контента блога и согласование путей при реструктуризации `/about/blog/` → `/blog/` определяли бюджет разработки для этого шаблона в большей степени, чем предполагает количество постов. Сервисные страницы оценивались меньшим количеством часов на страницу после утверждения базового шаблона. Коротко: карта сайта с дизайном — это контракт. Задача команды разработки — уложиться в согласованную смету, а не переоценивать строку блога после того, как миграция выявила количество постов с отсылками к устаревшим путям. Мы решили взять сложность миграции блога на себя в рамках согласованных почасовых оценок и не запрашивать переоценку: пересмотр согласованной карты сайта в середине разработки сдвинул бы давление сроков на дату запуска агентства. **3. Согласование URL-путей по 46 уникальным парам.** Карта сайта содержала 62 строки в статусе Completed. Из них 46 пар имели различающиеся значения Current URL и New URL — отражая решение агентства упростить иерархию `/procedures/` и объединить архив `/about/blog/`. Мы сопоставили каждый исходный путь с целевым, настроили редиректы внутренних ссылок и проверили каждую пару в таблице Google Sheets до сдачи. Все 46 пар доведены до закрытого статуса до закрытия контрольного списка запуска. **4. Контент процедур, добавленный в процессе работы, интегрирован без сдвига сроков.** На позднем этапе работ агентство передало запрос на новый контент по процедурам для дополнительных сервисных страниц — некоторые из них уже были свёрстаны и находились в очереди QA. Задача по контенту была открыта как отдельная задача Redmine, отслеживалась с собственными часами и интегрирована на действующей тестовой среде параллельным потоком к очереди QA. Страницы, получившие новый контент, возвращены в очередь QA для повторной проверки. Дата запуска сохранена. **5. Список правок и проверка перед запуском закрыты до запуска.** Задачи отслеживались в списке правок агентства (9 строк, все закрыты до запуска) и во вкладке финального QA аккаунт-менеджера. Контрольный список из 29 пунктов — колонки Design, Functionality, Content, Pre-Migration и Post-Migration — согласован до публикации сайта. Проверка перед запуском подтвердила готовность сайта к финальному согласованию с аккаунт-менеджером агентства перед переключением. Конфликт путей блога — посты с датированными URL в /about/blog/ в исходной версии, упрощение до /blog/ в новой разработке — не имел отдельной вкладки редиректов для массового переноса; каждую из 46 пар пришлось проверять в тестовой среде в колонке Action карты сайта до закрытия контрольного списка. Именно эта построчная проверка сохранила SEO-вес URL-путей при сдаче. ## Результаты Метрика Результат URL свёрстано **62** по 5 шаблонам (1 Homepage · 4 About Us · 26 Service Pages · 21 Blog Posts · 10 Default Template) Шаблонов применено **5 / 5** из стандартной библиотеки шаблонов агентства для стоматологии Пар URL-путей согласовано **46** уникальных пар закрыто (старый путь → новый путь, отслежено в колонке Action карты сайта) Список правок **9 / 9** закрыт как Completed QA аккаунт-менеджера (тестовая среда) Проверка перед запуском выполнена и согласована Контрольный список запуска **контрольный список из 29 пунктов** согласован по разделам Design / Functionality / Content / Pre-Migration / Post-Migration Сроки **53 дня** (18 мар – 10 мая 2025), сдано в срок Трудозатраты **58 ч / оценка 58 ч** — без перерасхода, без расширения объёма Передача Сайт запущен на WP Engine, `https://www.romansmiles.com/` Статус сайта, проверено 04.2026 Сайт в работе (под Cloudflare, подтверждено: сайт активен и отдаёт контент через браузер) ## Контроль качества В ходе предварительной QA-проверки перед сдачей был обнаружен структурный дефект — дублирующийся H1 в блоке «Related Procedures» на шаблонах сервисных страниц: заголовок блока был размечен как второй `

` вместо `
`, проблема уровня шаблона, которая затронула бы все сервисные страницы стоматологической таксономии. Предварительная QA-проверка проводилась через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и правилом нулевых ошибок. Внутренний контур проверки агентства выполнялся после сдачи, и выявленные вопросы попадали в общую очередь для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица Google Sheets проверена, пары URL-путей подсчитаны, объём оценён, согласовано 58 ч Разработка (страницы + шаблоны) ~3 недели Все 62 URL свёрстаны по 5 шаблонам в тестовой среде; настроены редиректы путей; открыт список правок Миграция блога + согласование путей ~2 недели (параллельно) 21 пост блога перенесён; 46 пар URL-путей отслежены до разрешения; обновлены внутренние ссылки Интеграция контента (страницы процедур) ~1 неделя (параллельно) Новый контент процедур получен и интегрирован; затронутые страницы возвращены в QA Проверка перед запуском + контрольный список Финальные дни список правок 9/9 закрыт; контрольный список из 29 пунктов согласован; AM проверил и принял _Этапы пересекаются — миграция блога и согласование путей велись параллельно с разработкой сервисных страниц, поэтому календарный срок составляет 53 дня, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (разработка, миграция блога, этапы исправлений) - **Павел Сажин** — управление проектом и QA-итерации - **Анна Полунина** — поддержка разработчика (интеграция контента сервисных страниц и QA-раунды) - **Алексей Мелков** — поддержка внедрения - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Проектное управление со стороны агентства и коммуникация с конечным клиентом оставались за партнёрским агентством на всём протяжении работ. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте стоматологической практики каталог услуг задаёт не только навигацию — на нём держатся URL-архитектура, граф структурированной разметки и позиции, которые вы уже выстроили в выдаче. У этой практики одна клиника с общей и косметической стоматологией; у вашего клиента это может быть сеть из нескольких филиалов под общим брендом. Риски тихие. Зафиксируете URL-схему слишком рано — и новый филиал через полгода в неё не встанет, а страницы-фильтры по категориям выпадают из индекса и уносят с собой органические позиции. На импорте слетает структурированная разметка, и расширенные результаты, на которые опираются ваши панели аудита, пропадают. Поэтому подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы построите таксономию и разметку, чтобы следующий филиал или процедура встали без перестройки?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим URL-план с вашими ранжированными страницами, покажем, где разметка вступит в конфликт с импортом, и вернём фиксированную смету в часах. Разбор бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-31-page-implant-dentistry-123-days/ title: Доработка темы для имплантологии и ортопедической стоматологии type: case_study date: 2025-08-16T22:28:00+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 31 страница доработки темы для имплантологии и ортопедии — шаблон агентства #3, постраничная спецификация в Figma на Kinsta, Service Page применён 13 раз для хирургических процедур (импланты, All-On-4, реставрации полного рта) наряду с общей стоматологией. Шрифты Adobe Typekit нужно было отдельно запросить до начала сборки. 420+ позиций в очереди задач — это главный контрольный рубеж; весь смысл был в том, чтобы страницы хирургической специализации визуально не сливались с общестоматологическими в рамках единой шаблонной структуры. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — Стоматология (имплантология и ортопедия) Конечный клиент Premier Implant & Denture Center (Garden City, GA) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **31 URL** — главная, о нас, лендинг услуг, **13 страниц услуг** (импланты, All-On-4, реставрации полного рта, хирургия полости рта, восстановительная стоматология и общие стоматологические услуги), галерея улыбок, технология, контакты, лендинг блога и вспомогательные страницы Сроки 123 дня (22 июля – 22 ноября 2025), по графику Затраты ~73 часа по оценке — разработка, итерации QA и управление проектом Команда 6 специалистов Шаблоны **10 переиспользуемых шаблонов** предоставлены агентством, все применены к 31 странице Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · постраничный дизайн Figma · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **420+ отслеженных задач SEO + CX** сверены в очереди задач агентства, контрольный список запуска на 73 пункта **Ритм взаимодействия** 66 задач от агентства · все закрыты к моменту передачи (активный период — 85 дней, 07.08.2025–30.10.2025) **Раунды проверки** ≈9 раундов проверки в рамках 123-дневного окна **Контрольный список запуска** 73 пункта, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн в Figma для Premier Implant & Denture Center и цель развёртывания на их фирменной системе шаблонов на Kinsta. Агентство уже выполнило предварительную работу: требования клиента, аудит дизайна, настройку хостинга и подготовку контента через Google Docs на страницу. Что им было нужно — команда разработки, которая корректно перенесёт Figma на шаблон и выдержит цикл QA столько, сколько потребует процесс проверки агентства. Клиника под руководством Dr. William Verillo обслуживает район Саванны с клиническим охватом, разделённым на два отчётливых уровня услуг: дорогостоящая хирургическая и восстановительная работа (зубные импланты, All-On-4, реставрации полного рта, хирургия полости рта) наряду с рутинной общей стоматологией (осмотры, пломбы, коронки, удаления). Система шаблонов агентства была построена для обслуживания обоих — единый шаблон Service Page, применённый 13 раз по сайту, с доработкой под каждую процедуру по тексту, изображениям и вёрстке. Объём был открытым — не как в фиксированном ребилде, где заранее известен каждый шаг. Доработать шаблон под Figma страница за страницей. Фиксировать замечания в общую очередь задач. Возвращать каждую итерацию только после того, как проверяющий со стороны агентства подтвердил, что расхождение устранено. > **Контекст рисков.** Главная опасность при двухуровневой доработке стоматологического шаблона — не в том, чтобы собрать страницы, а в том, что шаблон сотрёт различие между специализированной и рутинной помощью. Когда один Service Page работает и для имплантации, и для общей стоматологии, одинаковый ритм вёрстки, плотность изображений и тональность CTA на обоих уровнях ослабляют позиционирование специализации клиники. Агентству нужен был партнёр, который сохранит структурную целостность шаблона и при этом добьётся, чтобы страницы имплантационного уровня читались как контент хирургической специализации, а не как общестоматологический. Команда, которая обращается со всеми страницами услуг как с взаимозаменяемыми, рискует превратить ортопедическую клинику в образ семейного стоматолога — потеря доверия, которую клиент агентства почувствует в потоке обращений пациентов, а не в логах сборки. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страницы. Наша задача — согласовать их страница за страницей: где стандартная вёрстка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не исходили с нашей стороны. **2. Двухуровневая архитектура услуг на едином наборе шаблонов.** Таксономия услуг клиники разделяется на два уровня: хирургический/восстановительный (импланты, All-On-4, реставрации полного рта, хирургия полости рта) и общий/профилактический (осмотры, пломбы, коронки, удаления). Шаблон Service Page агентства был применён 13 раз на обоих уровнях. Наша доработка обеспечила сохранение каждым уровнем своего отчётливого тона — хирургические страницы несли детальное описание процедур и CTA в рамке специалиста; страницы общей стоматологии — доступность и семейный уход. Шаблон давал структуру; доработка контента и изображений — различие уровней. **3. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «построил один раз, проверил один раз». Это «построил, QA, исправил, QA, исправил». Из 29 задач, отслеженных на этом проекте, **16 были итерациями QA** — отдельными раундами, где агентство отмечало расхождения дизайна, мы проверяли, исправляли и возвращали сборку на очередную проверку. За этими раундами стояло гораздо более масштабное согласование: агентство отслеживало **420+ позиций в двух вкладках очереди задач** (213 задач SEO и 210 CX), большинство из которых было отмечено как выполненные к моменту передачи. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без расхождения.** Каждое изменение в фирменном шаблоне — будь то вёрстка страницы, компонент секции или стилевой токен — мы документировали относительно референса из Figma. Ни одна доработка не «протекла» в общие компоненты шаблона, то есть работа этого проекта не ухудшила шаблон для следующего сайта, который будет на нём построен. **5. Проверка на разных устройствах.** Доработки проверялись на Chrome, Firefox, Safari и Edge на настольных, планшетных и мобильных устройствах. Каждый раунд QA покрывал страницы, затронутые расхождениями дизайна этого раунда, а не весь сайт — так сборка по шаблону остаётся экономной по усилиям без потери покрытия. Именно цикл QA держал двухуровневое различие. Из 29 задач Redmine 16 были отдельными итерациями QA — раундами, где агентство фиксировало расхождения с дизайном, мы проверяли, правили и возвращали сборку на следующий проход. Без этого устойчивого цикла по 420+ позициям различие между страницами имплантации и страницами общей стоматологии на единой шаблонной структуре стёрлось бы в единообразную вёрстку. ## Контроль качества QA тестовой среды из 31 страницы выявило две проблемы со структурой URL до передачи — опечатку в слеге на странице профиля врача (`/dr-william-verrillo` вместо корректного `/dr-william-verillo`) и незаменённый текст-заполнитель на `/meet-the-team/`, помеченный для полного просмотра контента — обе решены до того, как агентство увидело сборку. Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям с нулевым порогом ошибок. Приёмочный контур агентства запускался после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до окончательного согласования. Доработки оставались в переопределениях для данного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сданы **31** — 1 главная, 1 лендинг услуг, 13 страниц услуг, 1 о нас, 1 контакты, 1 лендинг блога, 1 пост блога, 1 галерея улыбок и 11 вспомогательных страниц (запись, технология, отзывы, галерея офиса, новые пациенты, знакомство с командой, профиль врача, конфиденциальность, условия, страховка, финансы) Шаблоны применены **10 из 10** переиспользуемых шаблонов из библиотеки агентства (Homepage, About Us, Services Lander, Service Page, Contact Us, Blog Lander, Blog, Smile Gallery, Default Template, Doctor Page) Контрольный список запуска **73 пункта** согласованы Задачи QA / SEO + CX отслежены и решены **420+** позиций сверены в двух вкладках очереди задач агентства (213 SEO + 210 CX) Итерации QA в Redmine **16 из 29 задач (55%)** отслежены на уровне итераций Сроки **123 дня**, сдано по графику Затраты **~73 часа** по оценке на весь проект — без перерасхода, без расширения объёма Команда **6 специалистов** Передача хостинга Работает в шаблонном окружении агентства на Kinsta Здоровье страниц при передаче **31 / 31** URL тестовой среды возвращали HTTP 200 при аудите карты сайта Если коротко: Figma агентства реализована на их фирменном шаблоне на 31 странице и 10 шаблонах за 123 календарных дня в рамках оценочных часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma проанализирована, доступ к шаблону подтверждён, объём согласован Разработка доработок ~5 недель Постраничная доработка шаблона для соответствия Figma; страницы двух уровней услуг построены Итерации QA (параллельно) ~10 недель 16 раундов QA зафиксировано; каждый закрыт только после согласования агентства Раунды исправлений ~3 недели Правки после проверки, правки контента, замена изображений-заглушек Сдача финальный день Сайт работает на Kinsta _Разработка и QA шли параллельно — это характерно для доработки темы, где никакая «фаза QA» не закрывается чисто; цикл идёт непрерывно до согласования агентства._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и перенос Figma в вёрстку) - **Павел Сажин** — итерации QA и координация проекта - **Анна Полунина** — поддержка разработчика по доработке и контентным раундам - **Евгений Карпов** — поддержка разработки - **Тимур Арбаев** — QA и раунды исправлений - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство удерживало отношения с конечным клиентом на протяжении всего проекта. Все запросы на доработку проходили через общую очередь задач агентства; Premier Implant & Denture Center с нашей командой напрямую не работал. Каждый итерационный раунд выпускался только после того, как проверяющий со стороны агентства подтверждал, что изменения приведены в соответствие с ТЗ. ## Агентствам с библиотекой шаблонов > На сайте имплантологической клиники с десятком процедур именно шаблон диктует, как подаётся каждый тип процедуры, — и потом эту архитектуру тяжело гнуть. У этой практики направлений много: хирургические пути и категории реставраций; у других — одна процедура и один тип страницы. Когда иерархия типов страниц схлопывается в один общий шаблон, модули обучения пациентов ломают библиотеку компонентов, а CTA на консультацию ведёт не к тому типу приёма. Агентство узнаёт о сбое по обращениям пациентов, а не по журналу аудита. Поэтому подрядчику стоит задавать не вопрос «соберёте ли на шаблоне?», а вопрос «как именно вы разложите иерархию типов страниц так, чтобы тянуть контент под каждую процедуру и не сломать шаблон?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы пройдёмся по иерархии типов страниц против ваших типов контента, проверим библиотеку компонентов на пробелы в модулях обучения пациентов — и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-professional-services-48h-165-days/ title: Новая разработка на WordPress для CPA-консалтинга (23 страницы) за 165 дней type: case_study date: 2025-08-14T00:47:48+00:00 case_industry: Профессиональные услуги case_type: Разработка case_practice: wordpress --- ## Подход к разработке 23 страницы новой разработки на WordPress для CPA-консалтинговой фирмы уже стояли на тестовой среде, когда агентство передало указание клиента: сменить дизайн и контент под beachcpafirm.com — другой референс-сайт, запрошенный в середине работ. Мы повторили его, не тронув карту URL, переписали заимствованный контент и провели полную смену бренда с Ascend Dental CPAs на SBDP, уложившись в исходную смету на 48 часов. Этот кейс — описание такой разработки: CPA-консалтинговая фирма для стоматологических клиник, выполненная для маркетингового агентства из США в сегменте профессиональных услуг. ## Краткий обзор Поле Значение Индустрия конечного клиента Профессиональные услуги — CPA и финансовый консалтинг для стоматологических клиник Конечный клиент Ascend Dental CPAs (Jacksonville Beach, FL) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка на WordPress с Elementor на WP Engine, со сменой референс-сайта и сменой бренда Объём **23 URL** — главная, лендинг What We Do, 9 страниц услуг, Who We Are / Core Values, лендинг Key Team Members, 5 био-страниц партнёров, раздел Resources, контакты, плюс посты блога, добавленные после карты сайта Сроки 165 дней (3 янв – 18 июн 2025), сдано поэтапно Трудозатраты **48 часов** по смете — без перерасхода Команда 4 специалиста (распределение с упором на разработку, соответствующее разработке со сменой референса и согласованием контента) Шаблоны **6 переиспользуемых шаблонов** — главная, о нас, страница услуги, био сотрудника, блог, стандартный Технологии WordPress · Elementor · Gravity Forms · WP Engine · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Результат** **23 URL разработаны по 6 шаблонам, 3 пары редиректов согласованы, контрольный список из 49 пунктов отслежен, очередь правок 4/4 закрыта как Completed, смена референса на BeachCPA Firm принята, полная смена бренда с Ascend на SBDP выполнена** **Интенсивность** 4 задачи от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈8 раундов проверки за 165 календарных дней **Контрольный список запуска** 49 пунктов, согласованы перед запуском ## Постановка задачи Маркетинговое агентство из США, работающее с Ascend Dental CPAs — CPA- и финансовой консалтинговой фирмой в Jacksonville Beach, обслуживающей стоматологические клиники, — передало нам таблицу Google Sheets с полной картой URL, каталогом шаблонов, контрольным списком запуска из 49 пунктов и заранее заполненной очередью правок. Разработка велась на их окружении WP Engine; конструктор страниц — Elementor; формы — Gravity Forms. Задача была поэтапной. Сначала — разработать существующую структуру сайта фирмы — 23 URL по 6 стандартным шаблонам — на тестовой среде WP Engine агентства. Затем, в середине разработки, агентство передало указание клиента: сменить дизайн и архитектуру контента на другой референс-сайт (BeachCPA Firm), добавить посты блога и дополнительные страницы из контента, предоставленного агентством, и в конце выполнить замену бренда на всём сайте с «Ascend Dental CPA» на «SBDP» на каждой странице, в каждом меню и в каждом слое данных Elementor. На всём протяжении — не выходить на прямой контакт с конечным клиентом; передавать неясности агентству; не импровизировать с дизайном, контентом или CTA. > **Контекст рисков.** При white-label разработке для фирмы профессиональных услуг направление клиента может измениться после того, как первый вариант уже на тестовой среде. Риск не в том, сможет ли команда разработки скопировать новый референс-сайт; риск в том, сможет ли она принять полную смену референс-сайта — скопировать структуру и контент другой фирмы — и затем выполнить систематическую смену бренда с одного названия на другое, отследив каждый экземпляр прежнего названия на страницах, в меню, в слоях данных Elementor и в копирайте футера, чтобы после сдачи не осталось следов. Это не переделка, а работа с объёмом, который изменился в процессе. Кроме того, таблица не была полной картой — колонка Template была пуста для каждой строки карты сайта, так что выбор шаблона приходилось определять по структуре URL и типу страницы, а не по готовому назначению. ## Как мы это сделали **1. 6 шаблонов, 23 страницы, один процесс сборки.** Страницы Ascend Dental CPAs были распределены по библиотеке шаблонов агентства: главная, о нас / ценности, страница услуги (самая объёмная — 9 страниц услуг в разделе What We Do), био сотрудника (5 страниц партнёров и сотрудников), блог (лендинг + шаблон поста) и стандартный шаблон для вспомогательных страниц. Каждую страницу мы разработали на назначенном шаблоне из строки карты сайта; ни одной страницы не делали вручную вне системы шаблонов. **2. ТЗ выполнено строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта — суммарно 19,5 часа на исходную карту сайта. Дальше держались сметы строго. Принцип: карта сайта с дизайном — это контракт. Задача команды разработки — уложиться в согласованную смету, а не открывать заново разговор о цене, когда агентство добавляет фазу смены референса. **3. Смена референс-сайта в середине разработки принята без нарушения базовой структуры.** Ближе к концу работ агентство указало переключиться на BeachCPA Firm как новый референс для дизайна и контента. Задача включала копирование макета главной страницы референса, добавление постов блога и страниц из контента агентства в Google Drive и настройку новой навигации без поломки существующей архитектуры URL. Мы сохранили структуру URL карты сайта, наложив новый референсный дизайн, так что редиректы, внутренние ссылки и пункты контрольного списка остались валидными при смене референса. **4. Систематическая смена бренда на всех страницах сайта.** После смены референса агентство запросило полную замену «Ascend Dental CPA» и «Ascend» на «SBDP» — новое название фирмы — на всём сайте. Мы отследили каждый экземпляр на страницах, в меню навигации, в слоях данных Elementor, в копирайте футера и ссылках ресурсов, затем провели внутренний QA-проход, чтобы подтвердить отсутствие остаточного бренда перед возвратом сайта агентству. Смена бренда стала завершающей дисциплиной. В задаче QA был перечислен каждый слой — копирайт футера, страницы Who We Are и Core Values, названия пунктов навигации, текст контактной страницы — потому что CPA-фирма в процессе смены названия не может опубликовать сайт с остаточным брендом где бы то ни было на нём. Выполнение этого как программного прохода по всем 23 страницам, а не ручной проверки, позволило проверить сдачу независимо. ## Результаты Метрика Результат URL разработано **23** по 6 шаблонам (1 главная · 1 лендинг What We Do · 9 страниц услуг · 1 Who We Are / Core Values · 1 лендинг Key Team Members · 5 био-страниц сотрудников · 1 раздел Resources · 1 контакты · плюс посты блога, добавленные после карты сайта) Шаблонов применено **6 / 6** из стандартной библиотеки шаблонов агентства Пар редиректов согласовано **3** отдельные пары указаны в карте сайта (главная, лендинг What We Do, лендинг Resources) Очередь правок **4 / 4** закрыты как Completed (цвет шрифта, атрибуция в футере, meta title, ссылки кнопок) Контрольный список запуска **49 пунктов** отслежены по категориям: дизайн / функциональность / контент / SEO и аналитика / адаптивность / разное / домен и DNS Смена объёма Копирование референс-сайта (главная BeachCPA Firm), добавление блога и страниц, переписывание контента для устранения заимствований — всё принято в середине разработки без превышения бюджета Смена бренда Замена «Ascend Dental CPA» / «Ascend» на «SBDP» на всех страницах, в меню, данных Elementor и копирайте футера Сроки **165 дней** (3 янв – 18 июн 2025), сдано поэтапно Трудозатраты **48 ч / 48 ч** смета — без перерасхода, без расширения объёма Сдача Сайт запущен на WP Engine, `https://sbdpcpa.com/` — под новым брендом SBDP, внедрённым в рамках работ **Статус сайта** В работе на WP Engine: `https://sbdpcpa.com/` — проверено в апреле 2026. Если коротко: 23 URL новой разработки для агентства сданы по 6 шаблонам на WP Engine, в рамках сметы на 48 часов. Смена референс-сайта в середине разработки принята, посты блога и страницы добавлены из контента агентства, заимствованный контент переписан, и полная смена бренда с Ascend на SBDP выполнена до того, как к проверке подключилось агентство после сдачи. ## Контроль качества Завершающей задачей QA в этом проекте была проверка смены бренда: на ~350 страницах на тестовой среде Павел выполнил программное сканирование заголовков, meta, H1–H2 и основного текста, чтобы выявить каждый оставшийся экземпляр «Ascend» или «Ascend Dental CPA» до того, как сайт покинул наши руки — обнаружив остаточные вхождения на страницах карьеры, в тексте ценностей и на страницах услуг, которые постраничная проверка пропустила бы. Проверку перед сдачей вёл **Site Checker** — см. [наш подход к QA](/site-checker/) с категориями и порогом нулевых ошибок. Агентство проверяло отдельно уже после сдачи и записывало замечания в общую очередь правок, которую мы закрывали до финального согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица проверена, построчные часы подтверждены, 48 ч оценены и согласованы Разработка (страницы + шаблоны) ~3 недели Все 23 URL разработаны по 6 шаблонам на тестовой среде WP Engine; открыты контрольный список на 49 пунктов и очередь правок из 4 строк Смена референс-сайта ~2 недели (параллельно с QA) Главная BeachCPA Firm скопирована, посты блога и страницы добавлены из контента агентства, заимствования устранены Смена бренда + QA ~3 недели Замена «Ascend» → «SBDP» на всём сайте выполнена; очередь правок закрыта; пункты контрольного списка проверены Согласование + сдача Финальные недели Оставшиеся технические вопросы и исправления карты сайта решены; сайт передан агентству _Этапы пересекались — смена референс-сайта и смена бренда выполнялись параллельно с текущим QA и проверкой контрольного списка, поэтому календарный срок составляет 165 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на всех этапах: исходная разработка, смена референс-сайта и смена бренда - **Наталия Богатель** — копирование главной страницы и приведение дизайна к BeachCPA Firm - **Павел Сажин** — итерации QA, проверка контента и проверка смены бренда - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом и коммуникация с клиентом со стороны агентства оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > Когда вы заказываете сборку WordPress для консалтинговой компании, работающей со стоматологическими клиниками, структурный риск не в коде, а в направлении: клиент может поменять бренд или сместить фокус после того, как тестовая среда уже готова. У этой фирмы профиль узкий — консалтинг только для стоматологии; у других одна фирма тянет аудит, налоги и консалтинг под одним брендом. Три сценария тихого отказа: старое название останется в слоях Elementor и футере — клиент заметит при запуске; новое направление услуг не ляжет в URL-структуру без перестройки — позиции просядут; разметка по нескольким партнёрам слетит при импорте — расширенные результаты пропадут из панелей, которые ваше агентство уже выстроило. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы зачистите старые следы бренда и построите таксономию, которая примет смену направления без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы пройдёмся по вашей карте, подсветим точки, где бренд или структура зафиксируются слишком рано, и вернём фиксированную смету в часах. Аудит бесплатный, смета приходит в часах, не в диапазоне. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-pediatric-dental-26h-portland/ title: Ребилд сайта детской стоматологии — канонизация, Portland type: case_study date: 2025-08-08T10:03:44+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Сайт детской стоматологии без ортодонтии в Portland мы пересобрали из единственной таблицы правок — без отдельной карты сайта. Ключевым требованием была канонизация URL, а не структура страниц. Каждая страница должна была принудительно вести редирект с трейлинг-слешем, а блог практики по адресу `/portland-pediatric-dental-blog/` — сохранить свой трёхсегментный путь. Без этих двух правил поисковые системы индексировали бы дублирующиеся версии каждого URL, а возвращающиеся родители попадали бы на битые пути. Агентство владело стратегией; мы — исполнением. ## Краткий обзор Параметр Значение Сфера клиента Медицина — детская стоматология Клиент Pine Tree Pediatric Dentistry (детская стоматология без ортодонтии, Portland, OR) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на WP Engine Объём Полный ребилд сайта — услуги детской стоматологии, ресурсы для пациентов, блог, контактные формы, интеграция GTM Сроки ~8 дней основная разработка (23–30 янв 2025); правки из списка дорабатывали до 27 фев 2025 Затраты 26 часов при оценке — без перерасхода Команда 3 специалиста (~20 ч разработка · 4 ч QA · 2 ч PM) Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Header Footer Code Manager · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Разница оригинал-ребилд проверена до передачи — отсутствие пропущенного контента, битых внутренних ссылок и структурных расхождений **Результат** **Полный ребилд сайта по спецификации; канонический редирект с трейлинг-слешем применён на всём сайте; пути поддиректории блога сохранены; интеграция GTM через Header Footer Code Manager; все пункты из списка правок закрыты до согласования агентством** **Раунды проверки** ≈4 раунда за 8 дней ## Постановка задачи Маркетинговое агентство из США, нанятое Pine Tree Pediatric Dentistry — детской стоматологией без ортодонтии в Portland, OR — привлекло нас для ребилда существующего сайта на Elementor Pro. Практика обслуживает только детей, с единой структурой услуг: профилактика, восстановительное лечение, седативная стоматология, стоматология для особых потребностей, послеоперационные инструкции и рекомендации к первому визиту. В отличие от практик, ведущих параллельно ортодонтию и детскую стоматологию, здесь один маршрут пациента — родитель записывает ребёнка, проходит по единому пути услуг и заполняет один набор контактных форм. Простая структура услуг делала технические требования жёстче, а не мягче: каждый URL должен был вести себя одинаково, каждая внутренняя ссылка — корректно открываться, а аналитика — работать с первой же загрузки страницы после переключения. Задача была точной. Работать по спецификации агентства и списку правок; выполнять каждую строку как написано; не выходить на прямой контакт с клиентом всё это время. Спецификацию агентство передало одной таблицей правок — без отдельной карты сайта, карты шаблонов или перечня страниц. Полную структуру страниц пришлось восстанавливать из задач и переписки в чате, а не сверять с формальной таблицей. Так был устроен бриф — это не наш выбор по процессу. Тестовая среда работала на WP Engine. Агентство страховалось от ошибок канонизации URL, характерных для этого ребилда: посты блога практики лежали в трёхсегментном пути (`/portland-pediatric-dental-blog/`), и каждый URL на сайте должен был перенаправляться с трейлинг-слешем. Без этих двух правил поисковые роботы индексировали бы каждую страницу в двух вариантах, а родители, переходящие по старым закладкам, попадали бы на битые пути. > **Контекст рисков.** Сайт детской стоматологии на локальном рынке обслуживает родителей, которые ищут стоматолога для своего ребёнка — часто в условиях временного давления. Структура URL сайта входит в профиль практики в локальном поиске: блог в `/portland-pediatric-dental-blog/` накапливает ссылки и закладки со временем. Ребилд, который корректно переносит контент, но оставляет `example.com/page` и `example.com/page/` открытыми как два отдельных URL, отдаёт поисковым системам сигнал дублированного контента, а возвращающемуся посетителю — разное поведение по одной ссылке. При визуальной проверке тестовой среды этот сбой не виден — оба пути загружают страницу, — но проявляется при каждом обходе после запуска. Мы устранили это до переключения, а не после: в этом и было ключевое требование. ## Как мы это сделали **1. Сборка от шаблонов по структуре детских услуг.** Структура услуг сайта повторяла шаблон детской стоматологии без ортодонтии: страница-витрина услуг вела к отдельным страницам по каждому клиническому направлению (профилактика, восстановительное лечение, седативная стоматология, стоматология для особых потребностей, послеоперационный уход), а рядом — страницы первого визита и форм для пациентов. У каждой страницы услуги — одна структура: описание процедуры, рекомендации для родителей и контактная форма, уходящая в практику. Блог в собственной поддиректории практики `/portland-pediatric-dental-blog/` мы пересобрали с тем же путём, чтобы сохранить ссылки с прежних публикаций. **2. Канонизация трейлинг-слеша на всём сайте.** Спецификация агентства требовала, чтобы все страницы — статические и динамические — открывались только с трейлинг-слешем, а все варианты без слеша перенаправлялись на каноническую форму со слешем. Мы сделали это через настройки постоянных ссылок WordPress и правила редиректов, применив их последовательно к страницам услуг, постам блога и архиву блога. Это сняло проблему дублирования URL до запуска и убрало последующие артефакты в обходе. **3. Спецификация выполнена строка за строкой, по таблице агентства.** Список правок агентства фиксировал каждый пробел в контенте и функциональности относительно исходного сайта. Незавершённые блоки — включая страницу седативной стоматологии, на которой отсутствовали разделы из оригинала, — мы привели в соответствие с оригиналом. Страницу послеоперационных инструкций с кнопкой загрузки PDF, которого в оригинале ещё не было, мы отметили и передали агентству, а не тихо пропустили. Пункты услуг, пришедшие без ссылок на отдельные страницы, мы нашли и исправили. Ни один пробел не закрыли по догадке. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не достраивать его на догадках. **4. Интеграция GTM через Header Footer Code Manager, подтверждена до передачи.** Агентство требовало перенести скрипт Google Tag Manager с исходного рабочего сайта и поставить его через плагин Header Footer Code Manager. Плагин на тестовой среде стоял, но сам скрипт GTM ещё не был подключён — пробел, незаметный при визуальной QA-проверке, который тихо обрушил бы сбор аналитики практики с первой же сессии после переключения. Мы проверили интеграцию на работоспособность до того, как сборка ушла в очередь проверки агентства. Header Footer Code Manager взяли вместо встраивания в тему: он держит все сторонние скрипты в одном месте — правки переживают обновления темы, и агентство может проверять или менять размещения, не трогая код. Принудительный трейлинг-слеш и путь `/portland-pediatric-dental-blog/` нужно было подтвердить до передачи — при визуальной QA их не видно, но они проявились бы при каждом обходе и в каждой закладке возвращающегося родителя после переключения. Снять дублирование URL до запуска и поймать хост тестовой среды в футерной ссылке раньше, чем его увидит агентство, — вот для чего нужен был внутренний QA-раунд. ## Результаты Метрика Результат Точность спецификации — структура услуг Полная структура детских услуг восстановлена по спецификации; все страницы услуг и ресурсов для пациентов сданы Точность спецификации — паритет контента Страница седативной стоматологии восстановлена с добавлением недостающих разделов; все остальные страницы соответствуют исходной структуре Канонизация трейлинг-слеша Применена на всём сайте — страницы услуг, посты блога и архив блога используют редирект с трейлинг-слешем Поддиректория блога Структура пути `/portland-pediatric-dental-blog/` сохранена при ребилде Интеграция GTM Скрипт Google Tag Manager развёрнут через Header Footer Code Manager, подтверждён до передачи Ссылки на услуги Пункты страниц услуг связаны с отдельными страницами услуг Сроки Основная разработка ~8 дней (23–30 янв 2025); все пункты очереди задач решены к 27 фев 2025 Затраты **26 часов** при оценке — без перерасхода, без расширения объёма Адаптивность QA на разных устройствах подтверждён для большого экрана и мобильных **Статус сайта** Работает на WP Engine, открывается по адресу https://www.pinetreepediatricdentistry.com/. Если коротко: спецификацию агентства мы выполнили как написано по всей структуре детских услуг, уложились в согласованные часы, и все пункты из списка правок закрыли до утверждения. Сайт работает. ## Контроль качества Внутренняя проверка ссылок нашла кнопку в футере, которая вела на хост тестовой среды вместо опубликованного пути `your-first-visit` — битый URL, незаметный при визуальной проверке. А сверка паритета показала, что каждая страница открывалась и с трейлинг-слешем, и без него — тот самый сигнал дублированного контента, ради которого и писалась спецификация агентства. Оба дефекта мы исправили до передачи. До сдачи QA проходил через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Свой проверочный контур агентства работал после передачи и заводил замечания в общий список правок для нашего цикла исправлений до согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день Спецификация агентства проверена; оценка 26 ч согласована Разработка ~8 дней Полный ребилд сайта на тестовой среде WP Engine; реализована единая структура услуг; применены правила трейлинг-слеша Внутреннее QA и проверка 2 дня Проработан список правок; исправлены ссылки на услуги, паритет контента седативной стоматологии, интеграция GTM Проверка спецификации 1 день Паритет контента и канонизация URL подтверждены по спецификации Сдача и DNS-переключение 1 день Сайт запущен на WP Engine, без простоев _Этапы перекрываются (QA шёл параллельно с поздней разработкой), поэтому календарный срок — примерно 35 дней от открытия проекта до финального согласования списка правок, при том что основная разработка завершилась за первые 8 дней._ ## Команда **Команда проекта** - **Евгений Карпов** — ведущий разработчик (полный ребилд сайта, система шаблонов, канонизация трейлинг-слеша) - **Анна Полунина** — очередь задач QA и исправление ссылок на страницы услуг - **Никита Тумашевич** — координация QA и маршрутизация задач - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, общение со стороны агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел всё переключение и раунды исправлений после сдачи. Все решения по структуре URL, стратегии редиректов и архитектуре страниц услуг принадлежали агентству; наша роль — точно исполнить поставленную ими спецификацию. ## Агентствам, заказывающим ребилд WordPress > Ребилд сайта детской стоматологии ставит под удар URL-архитектуру, которая уже приносит трафик и ссылки. У этой практики — один филиал с блогом о детской гигиене; у сетевой клиники это каталог процедур и страницы врачей. Не настроишь редиректы — старые адреса начнут отдавать 404 и закладки родителей уйдут в никуда. Не зафиксируешь правила слеша — Google увидит дубли одной и той же страницы. Перезапишутся мета-теги при импорте — пропадут размеченные сниппеты, которые держат практику в выдаче. Подрядчику стоит задавать не вопрос «перенесёте ли вы сайт?», а вопрос «как именно вы зафиксируете правила URL и закроете каждую строку редиректов». Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы прогоним ваш сайт на дубли путей, проверим карту редиректов под нагрузкой и отметим разметку, которую после миграции придётся восстанавливать вручную. Смету в часах вернём за несколько часов, аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-47-page-pediatric-dental-106-days/ title: Доработка темы детской стоматологии: 47 страниц за 106 дней type: case_study date: 2025-08-05T02:24:05+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы Клиника с двумя направлениями — 28 страниц услуг, разделённых между детской стоматологией и ортодонтией, — дорабатывалась на основе системы из 7 шаблонов Figma. Опечатка в номере телефона кочевала по тестовой среде с первого дня. Два расходящихся пути пациента на одном шаблоне — и каждая постраничная проверка становилась критической: аудит AutoQA поймал переставленную цифру (281-172-70511), разошедшуюся по всем 47 страницам, ещё до того, как агентство согласовало работу. Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — детская стоматология и ортодонтия Конечный клиент House of Smiles Pediatric Dentistry and Orthodontics (Cypress, TX) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального медицинского бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн Figma на Kinsta) Объём работ **47 URL** — главная, страница услуг, **28 страниц услуг** (разделённых между детской стоматологией и ортодонтией), о нас, страница врача, контакты, плюс 14 вспомогательных страниц (юридические, служебные, запись на приём) Срок 106 дней (8 авг – 22 ноя 2025), в срок Трудоёмкость 74 часа — распределены между разработкой темы, итерациями QA, исправлениями и управлением проектом Команда 4 специалиста Шаблоны **7 переиспользуемых шаблонов**, предоставленных агентством, применённых на всех 47 страницах Технологический стек WordPress · Elementor · хостинг Kinsta · постраничный дизайн на основе Figma · AutoQA агентства (проверка телефона / ссылок / email / контента AI) · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **Более 175 отслеженных SEO + DEV + CX-проблем** согласованы в очереди правок агентства с тремя вкладками в рамках контрольного списка запуска из 78 пунктов **Динамика взаимодействия** 6 задач от агентства · все закрыты к передаче (активный период 1 день, 2025-09-12 – 2025-09-12) **Раунды проверки** ≈8 раундов проверки за 106 календарных дней **Контрольный список запуска** 78 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн Figma для House of Smiles и цель развёртывания на своей брендированной шаблонной системе под Kinsta. Агентство уже выполнило подготовительную работу: форму с требованиями клиента, аудит дизайна, настройку хостинга, контент-план и подготовку Google Docs для каждой страницы. Им нужна была команда разработчиков, которая точно перенесёт Figma на шаблон, пройдя через столько итераций доработки, сколько потребуется для соответствия дизайну. Задача была чисто исполнительской — с педиатрической спецификой. Стоматологические и ортодонтические клиники ведут две отдельные ветви услуг на одном сайте: дерево общей детской стоматологии (чистка, герметизация, пульпотомия, неотложная помощь) и дерево ортодонтии (раннее лечение, традиционные и керамические брекеты, элайнеры, ретейнеры). Обе ветви должны быть доступны с одного шаблона, ни одна не должна перевешивать другую, и обе должны читаться как дружелюбные к детям, вызывающие доверие у родителей и профессионально убедительные — тональные решения, которые агентство уже приняло в Figma. Риск, от которого агентство страховалось, особенно характерен для практик с двумя направлениями: шаблон страницы услуг используется 28 раз в обеих ветвях, а это значит, что строка CTA или метка формы, правильно применённая на стороне педиатрии, может незаметно перекочевать на сторону ортодонтии, если доработка неточна. Кнопка «записаться на приём», появившаяся на странице ортодонтического лечения вместо «записаться на консультацию», — это не ошибка стилизации: она направляет неверный путь пациента в неверный момент конверсии. Такая ошибка в контенте не обнаруживается при визуальной проверке QA; она требует целенаправленной постраничной проверки каждого элемента шаблона, содержащего текст для пациента. > **Контекст рисков.** Сайт с 2 направлениями (детская стоматология и ортодонтия) использует 1 шаблон для 28 страниц услуг — но пути пациента расходятся на каждом CTA. Кнопка «записаться на приём» на странице детской герметизации верна; та же строка на странице ортодонтического лечения направляет не того пациента не на тот шаг. Такая ошибка невидима для визуальной проверки QA и проявляется только когда кто-то читает текст шаблона на каждой странице в контексте её ветви. Постраничная проверка CTA здесь не опция: её сделала необходимой 28-кратная переиспользуемость шаблона. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страницы. Наша задача — согласовать их постранично: где шаблон совпадал с Figma, мы его оставляли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не принимались на нашей стороне. Для педиатрического сайта, который должен быть визуально тёплым, но не инфантильным, и ортодонтического сайта, который должен быть клинически убедительным, но не холодным, — это правило «без импровизации» было критичным: каждое тональное решение уже было принято в Figma. **2. Две ветви услуг, один набор шаблонов.** Детская стоматология и ортодонтия получили свои поддеревья услуг под общим разделом услуг. Один и тот же шаблон страницы услуг использовался 28 раз в обеих ветвях — с адаптацией под специфику направления: текст, изображения и правильный CTA для следующего шага (страница герметизации ведёт к «записаться на приём»; страница ортодонтического лечения — к «записаться на консультацию»). Правильно расставить эти CTA на 28 страницах — задача уровня QA по шаблону, а не деталь стилизации. Несколько позиций в очереди задач CX агентства были исправлениями неверных CTA; цикл QA существовал именно для их выявления. **3. Цикл QA в масштабе доработки темы.** Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, QA, поправить, QA, поправить». Из 24 задач, отслеженных в этом проекте, **14 были отдельными итерациями QA** (суффикс «-qa» в названии задачи) — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы проверяли, исправляли и возвращали сборку на новую проверку. За этими раундами стояла гораздо более масштабная работа: агентство отследило **более 175 позиций в трёх вкладках очереди задач** (SEO, DEV и CX), крупнейшая из которых (DEV, 120 позиций) была проведена нами до завершения и QA. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. Клиент не успел подготовить контент в темп со сборкой: несколько страниц попали в тестовую среду с плейсхолдерами и без изображений — заметки практики ещё не были собраны в нужный вид. Эти пробелы закрылись через тот же 14-раундовый цикл QA, а не стали причиной задержки сборки. **4. Доработка без отклонений.** Каждое изменение в брендированном шаблоне — будь то макет страницы, компонент секции или стилевой токен — мы документировали относительно Figma. Ни одна доработка не «протекла» в общие компоненты шаблона, то есть работа над этим проектом не ухудшила шаблон для следующего сайта. Мы выбрали постраничные переопределения вместо изменения общих компонентов, потому что сохранение целостности шаблона для следующего клиента агентства было важнее маржинального выигрыша в скорости от правки базового слоя напрямую. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на больших экранах, планшетах и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA покрывал страницы, затронутые расхождениями в этом раунде, а не весь сайт — так сборка по шаблону остаётся экономной без потери полноты покрытия. Цикл QA — вот что сделало соответствие Figma достижимым в масштабе 47 страниц. Четырнадцать отдельных итераций — каждая требовала утверждения агентством перед переходом к следующей — удерживали сборку в соответствии с дизайном на каждом этапе, включая аудит номеров телефона, выявивший `281-172-70511`, разошедшийся по всем 47 страницам до того, как агентство увидело финальную сборку в тестовой среде. ## Контроль качества Site Checker выявил две проблемы с контентом до того, как агентство увидело финальную сборку: номер факса (281-727-0512) отображался вместо основного номера (281-727-0511) в нескольких блоках — обнаружено аудитом номеров — а кириллический текст из правки в середине сборки просочился на опубликованную главную и его пришлось удалить перед передачей. Предрелизное QA проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Приёмочный контур агентства работал после передачи и фиксировал замечания в общей очереди задач для нашего цикла исправлений до их согласования. Доработки остались в клиентских переопределениях; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **47** — 1 главная, 1 страница услуг, 28 страниц услуг (в ветвях детской стоматологии и ортодонтии), 1 страница врача, 1 о нас, 1 контакты, 14 вспомогательных страниц Шаблонов применено **7 из 7** переиспользуемых шаблонов построено и сопоставлено на 47 страницах (главная, страница услуг, страница услуги, о нас, страница врача, контакты, стандартный шаблон) Контрольный список запуска **78 пунктов** согласовано QA / SEO / DEV / CX проблем отслежено + решено **Более 175** позиций согласовано в трёх вкладках очереди задач агентства (SEO 6, DEV 120, CX 49) Итерации QA в Redmine **14 из 24 задач (58 %)** отслежено на уровне итераций Срок **106 дней**, сдано в срок Трудоёмкость **74 часа** при оценке 74 часа — без перерасхода, без расползания объёма Команда **4 специалиста** Передача хостинга Запущен в шаблонной среде Kinsta агентства, затем перенесён на рабочий домен клиента Состояние страниц при передаче **47 / 47** URL карты сайта вернули HTTP 200 при аудите тестовой среды Статус сайта Сайт запущен: houseofsmileshtx.com — подтверждён 200 OK на момент составления кейса Если коротко: Figma агентства была реализована на их брендированном шаблоне на 47 страницах и 7 шаблонах за 106 календарных дней в рамках оценки в 74 часа. ## Процесс Этап Длительность Результат Бриф и оценка ~9 дней Figma проанализирована, доступ к шаблону подтверждён, объём работ согласован (8 авг – 17 авг) Разработка доработки ~6 недель Постраничная доработка темы под Figma; построены обе ветви — педиатрическая и ортодонтическая Итерации QA (параллельно) ~6 недель Задокументировано 14 отдельных раундов QA; каждый закрыт только после утверждения агентством Раунды исправлений ~2 недели Корректировки после проверки, включая проход «Список изменений клиента» и «Проверка и дополнение заметок клиента» Задачи после релиза ~2 недели Финальное согласование очереди задач QA, очередь задач после релиза закрыта (22 ноя) _Разработка и QA шли параллельно — это характерно для доработки темы: никакой «этап QA» не закрывается чисто; цикл работает непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и перенос Figma в макеты) - **Павел Сажин** — итерации QA и раунды исправлений - **Тимур Арбаев** — поддержка разработки на поздних раундах доработки и задачи после релиза - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, утверждение) Партнёрское агентство вело управление проектом, контроль дизайна, сбор контента и отношения с конечным клиентом от начала до конца. House of Smiles никогда не взаимодействовали с нашей командой — сборка двигалась через общую очередь задач агентства, и каждый раунд переходил к следующему только после утверждения их проверяющим. ## Агентствам с библиотекой шаблонов > Вы запускаете типовую систему на 2 клинические специальности — и боитесь, что постраничные детали тихо уведут пациента не туда. У этой практики это детская стоматология и ортодонтия в одном бренде; у других — 1 специальность, где один процесс ложится на один шаблон. Кнопка призыва отправит не тот тип пациента не в то отделение. Текст страницы услуги смешает формулировки обеих специальностей. А обновление шаблона у поставщика без предупреждения сотрёт постраничные доработки. Спрашивать стоит не «справитесь ли вы со сборкой по шаблону», а «как вы сохраните постраничные CTA для каждого пути пациента». Пришлите нам исходник шаблона или его ID и спецификацию бренда. Мы пройдём каждую страницу против целевого пути её пациента, отметим CTA и формулировки, которые бьют мимо, и вернём фиксированную смету в часах. Это берём на себя мы. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-oral-surgery-71h-33-days/ title: 46-страничная разработка сайта хирургической стоматологии на WordPress за 33 дня type: case_study date: 2025-07-28T00:34:57+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 46-страничный сайт хирургической стоматологии на WordPress, бриф к которому агентство открыло прямым предупреждением: «много изменений URL, редиректов и удалений». Предыдущий сайт за годы накопил расхождения в URL по двум филиалам; 12 пар редиректов, 10 строк с изменениями URL и 4 устаревшие страницы нужно было свести с новой дизайн-спецификацией Adobe XD до того, как закроется контрольный список запуска. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — хирургическая и челюстно-лицевая стоматология Конечный клиент Goodove Oral Surgery (Virginia Beach, VA & Chesapeake, VA) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor на WP Engine, согласована с дизайн-источником Adobe XD Объём **46 URL** — главная, о нас, знакомство с врачами (2), лендинг услуг, 9 страниц услуг, хаб информации для пациентов, направляющим врачам, лендинг блога, контакты (с 2 подстраницами филиалов), 27 вспомогательных страниц на стандартном шаблоне Сроки 33 дня (7 апреля – 10 мая 2025), сдано в срок; последующие доработки до конца лета Затраты **71 час** при оценке в 71 час — без перерасхода Команда 6 специалистов (38 ч разработка · 11 ч QA · 10 ч PM · 12 ч доработки) Шаблоны **10 переиспользуемых шаблонов** — стандартная библиотека шаблонов локального бизнеса агентства Стек технологий WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Несколько филиалов Virginia Beach · Chesapeake; контактные страницы, телефоны и виджеты отзывов TrustIndex для каждого филиала **Сдано** **46 URL построено, 12 пар редиректов сведено, контрольный список запуска на 30 пунктов закрыт, 82 / 86 пунктов очереди задач доведено до Completed** **Ритм работы** 85 задач от агентства · все закрыты к передаче (108 активных дней, 2025-04-28 – 2025-08-13) **Раунды проверки** ≈7 раундов проверки за 33 календарных дня **Контрольный список запуска** 30 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США, нанятое Goodove Oral Surgery — практикой челюстно-лицевой хирургии из Virginia Beach с вторым филиалом в Chesapeake — передало нам таблицу Google Sheets с полной картой URL, библиотекой дизайнов Adobe XD, контрольным списком запуска и заранее заполненной очередью задач. Разработку мы вели в их среде WP Engine; конструктор страниц — Elementor; формы — Gravity Forms. В таблице Google Sheets было прямое предупреждение агентства: предыдущий сайт за годы накопил расхождения в URL, и новый должен был свести каждый изменившийся путь, каждую удалённую страницу и каждое перемещённое описание услуги. Задача: собрать все 46 страниц по библиотеке шаблонов агентства, свести карту редиректов со старой структуры URL на новую, настроить контактные данные и виджеты отзывов для каждого филиала (Virginia Beach и Chesapeake) и довести очередь задач до уровня, приемлемого для агентства, перед передачей. Дизайн, контент, SEO-стратегия и коммуникация с клиентом оставались за агентством. В очереди задач агентства висело 15+ пунктов, всплывших уже после сборки в ходе QA, — ссылки, правки вёрстки, размещение контента, — и каждый требовал возврата в тестовую среду и свежей проверки агентства перед закрытием. > **Контекст рисков.** Сайт практики с двумя филиалами требует строгой работы с редиректами, какой нет у однолокационного сайта. Пациенты, сохранившие в закладках старую контактную страницу Virginia Beach, направляющие врачи, ссылающиеся на конкретный URL с хирургическими инструкциями, и поисковые результаты, проиндексировавшие старые поддомены отзывов, — все должны попасть в правильное место на новом сайте. Агентство страховалось от разработчика, который собирает точные страницы, но относится к таблице редиректов как к мелочи на потом. На сборке, где само агентство отметило «много изменений URL, редиректов и удалений», этот риск не теоретический — это центральное операционное ограничение. ## Как мы это сделали **1. 10 шаблонов, 46 страниц, один процесс сборки.** Страницы Goodove легли на стандартную библиотеку шаблонов локального бизнеса агентства: Главная (1), О нас (1), Страница врача (2 — доктор Scott Goodove и коллега), Лендинг услуг (1), Страница услуги (9 — импланты, зубы мудрости, удаление, костная пластика, обнажение ретинированных зубов, оральная патология, дисфункция ВНЧС, лицевая травма, предпротезная хирургия), Хаб информации для пациентов (1), Направляющим врачам (1), Лендинг блога (1), Контакты (1, с подстраницами Virginia Beach и Chesapeake) и Стандартный шаблон, охвативший 27 вспомогательных страниц (дисклеймер, полезные ссылки, вакансии, отдельные страницы хирургических инструкций и контент по филиалам). Каждую страницу мы собирали по назначенному шаблону из строки карты сайта; ни одну страницу не делали вручную вне системы шаблонов. **2. Спецификация выполнена строка в строку, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта — главная получила самый крупный бюджет, 27 вспомогательных страниц на стандартном шаблоне самый малый. Общий объём уложился в согласованные 71 час на проект. Коротко: карта сайта с дизайном — это контракт. Задача команды разработки — уложиться в согласованную смету, а не открывать заново разговор о цене страница за страницей. Мы собрали каждую страницу, что была и в карте сайта таблицы Google Sheets, и в дизайн-файлах Adobe XD, — даже те, что строки карты сайта явно не зафиксировали, — потому что прошлые проекты показали: чего нет в карте сайта, того ещё может ждать агентство. **3. Сведение редиректов по 12 уникальным парам URL.** Во вкладке карты сайта стояли явные флаги действий: Redirect, Delete или Build. Мы свели **12 пар редиректов** со старых URL на новые адреса — пути информации для пациентов собрали воедино, подстраницы отзывов схлопнули в один лендинг отзывов, страницы хирургических инструкций перенесли в единый хаб. Все редиректы мы проверили в тестовой среде до передачи. **4. Очередь задач доведена до уровня, приемлемого для агентства, до запуска.** Задачи шли в одной вкладке очереди задач агентства — 86 строк: точность вёрстки, поведение на мобильных, точность контента, интеграция виджетов и согласованность данных по филиалам. Из этих 86 пунктов **82 закрыты как Completed** до запуска; 1 оставался в QA, 1 ждал информации от конечного клиента, 1 агентство перенесло как To Do. Контрольный список запуска на 30 пунктов — Дизайн, Функциональность, До миграции, После миграции — закрыли следом за очередью задач. Порядок сборки задала карта редиректов. Вводная от Павла прямо просила: «очень внимательно и подробно рассмотрите редиректы» — ещё до того, как оценили хотя бы одну страницу. С таким ограничением 12 пар редиректов мы свели в тестовой среде до того, как открылся контрольный список запуска, а не после его закрытия. ## Результаты Метрика Результат Построено URL **46** в 10 шаблонах (1 Главная · 1 О нас · 2 Страницы врача · 1 Лендинг услуг · 9 Страниц услуг · 1 Хаб информации для пациентов · 1 Направляющим врачам · 1 Лендинг блога · 1 Контакты с 2 подстраницами филиалов · 27 вспомогательных страниц на стандартном шаблоне) Применено шаблонов **10 / 10** из стандартной библиотеки локального бизнеса агентства Пар редиректов сведено **12** уникальных пар со старых URL на новые Очередь задач **82 / 86** закрыто как Completed; 1 в QA, 1 Info-Needed, 1 To Do Контрольный список запуска **30 пунктов** согласовано по разделам Дизайн / Функциональность / До миграции / После миграции Сроки **33 дня** на начальную сборку, сдано в срок Затраты **71 ч / 71 ч по оценке** — без перерасхода, без расширения объёма Статус сайта Опубликован на WP Engine, `https://www.myoralsurgeon.com/` — HTTP 200, проверено в апреле 2026 Если коротко: сайт хирургической стоматологии на 46 URL мы сдали на 10 шаблонах в среде WP Engine, уложившись в смету 71 час. Карта редиректов на 12 пар свела старые URL, очередь задач доведена до уровня, приемлемого для агентства, а контрольный список запуска закрыт до того, как домен вышел в работу. ## Контроль качества Когда внутренний QA-проход прошёл по очереди задач, выяснилось: часть пунктов отметили как Completed ещё до того, как QA реально провели. Проверка URL сразу же вскрыла 404 высокого приоритета на `/disclaimer/` и сломанную карту сайта по процедурам — обе мы исправили до того, как показали тестовую среду агентству. QA перед передачей мы прогоняли через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Свой контроль на стороне агентства шёл после передачи и заносил замечания в общую очередь задач для нашего цикла исправлений, пока агентство не подписывало результат. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица Google Sheets изучена, дизайны Adobe XD подтверждены, построчные часы проверены, согласован 71 ч Сборка (страницы + шаблоны) ~2 недели Все 46 URL собраны на 10 шаблонах; оба филиала подключены с контактными данными и виджетами отзывов Сведение редиректов ~3 дня 12 пар редиректов сопоставлены и проверены; 4 устаревшие страницы отмечены к удалению QA и доработки ~1 неделя Очередь задач из 86 строк доведена до 82 Completed; применены правки вёрстки, мобильной версии и виджетов Контрольный список запуска + сдача последние ~2 дня Подписан контрольный список на 30 пунктов; сайт запущен на WP Engine _Сборка и сведение редиректов шли параллельно со второй недели; QA-хвост начался до того, как закрылись все задачи этапа сборки, — поэтому в календаре 33 дня, а не сумма последовательных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — проверка сборки и поддержка QA - **Павел Сажин** — итерации QA и исправления - **Анна Полунина** — поддержка разработчика на поздних этапах обновления контента и коррекции очереди задач - **Лиза** — выборочные проверки QA со стороны менеджера - **Людмила Травкина** — ведущий разработчик по разработке, согласованию редиректов и интеграции виджетов - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте хирургической стоматологии таксономия услуг решает больше, чем структуру URL: на ней держатся ранжирование и разметка, которые сдаёте вашему клиенту вы. У этой практики — хирургические процедуры и состояния; у других — общая стоматология и эстетические направления. Поломки тут тихие: новая процедура, добавленная на шестом месяце, не ляжет в таксономию без миграции; страницы фильтра по услугам выпадут из индекса; разметку для расширенных результатов срежет при импорте. Поэтому спрашивайте подрядчика не «соберёте ли страницы?», а «как именно вы построите таксономию, чтобы новые процедуры вставали без миграции?» Пришлите текущую рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим таксономию с каталогом процедур вашего клиента, отметим точки, где расширение сломает структуру, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. Крайние — мы. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-pediatric-dental-29-pages-21-days/ title: Ребилд сайта детской стоматологии на 29 страниц за 21 день type: case_study date: 2025-07-24T22:32:47+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 29 страниц ребилда на Elementor Pro на Kinsta для частной детской стоматологической практики — 15 шаблонов, одна лестница услуг, единый путь пациента от профилактики до экстренной помощи. Агентство предоставило карту URL, каждый мета-заголовок и 74-пунктный контрольный список запуска в Google Sheets; мы выполнили каждую строку по спецификации через всю структуру детских стоматологических услуг, не выходя на прямой контакт с клиентом на всём протяжении. ## Краткий обзор Поле Значение Индустрия конечного клиента Стоматология — детская Конечный клиент Pediatric Dentistry of San Jose (детская стоматологическая практика, San Jose, CA) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress с Elementor Pro на Kinsta Объём Полный ребилд сайта — детские стоматологические услуги, команда, ресурсы для пациентов, блог, контактные формы Сроки ~21 день (30 июл – 20 авг 2025) для основного ребилда; задачи после релиза закрыты к 2 сен; проверка Viktor завершена к 9 окт, в срок Трудозатраты ~63 часа при оценке — без перерасхода Команда 4 специалиста (~40 ч разработки · 10 ч QA · 10 ч PM) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) Проверка контентного паритета Разница оригинал-ребилд устранена до сдачи — отсутствующий контент, битые внутренние ссылки, структурный дрейф исключены **Сдано** **29 URL восстановлены по спецификации; 15 шаблонов; 74-пунктный контрольный список запуска; все задачи в рамках агентства закрыты до сдачи** **Ритм работы** 23 задачи от агентства — все закрыты к моменту сдачи (активный период 1 день, 2025-08-27 – 2025-08-27) **Раунды проверки** ≈5 раундов проверки за 21 календарный день **Контрольный список запуска** 74 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Pediatric Dentistry of San Jose — частной детской стоматологической практикой в San Jose, CA — привлекло нас для ребилда существующего сайта с нуля на Elementor Pro. Спецификация требовала сохранить каждый URL с идентичным контентом, перенести каждый мета-заголовок и описание и восстановить полную структуру детских стоматологических услуг как единый сайт. В отличие от двойных детско-ортодонтических практик, ведущих две лестницы (стоматология и ортодонтия), эта практика — чисто детская стоматология: один путь пациента, одна лестница услуг, один набор форм записи. Разработка должна была соблюдать эту однолестничную структуру на каждом уровне страницы. Задача была точной. Работать по таблице Google Sheets агентства; реализовывать каждую строку как написано; не выходить на прямой контакт с клиентом на всём протяжении. Тестовая среда работала на Kinsta. Риск, от которого агентство страховалось, был специфичен для детского ребилда с очень большой QA-очередью задач: сайт, который проходит визуальное QA, но запускается с битыми ссылками в подвале, съехавшими мобильными заголовками или внутренними таксономическими страницами, случайно открытыми для внешнего доступа — те проблемы, которые невидимы на скриншоте тестовой среды, но сразу заметны родителю, выбирающему стоматолога для ребёнка. > **Контекст рисков.** Сайт детской стоматологии обслуживает родителей, которые ищут помощь для своих детей в условиях цейтнота — плановый осмотр или срочный случай. При переключении каждый URL страницы услуг, каждый мета-заголовок, каждая интеграция формы должны работать корректно. Ребилд, который правильно делает главную, но оставляет сломанный мобильный заголовок, тёмный текст на тёмном фоне в блоге или внутреннюю таксономическую страницу, открытую для поисковиков, даёт сайт, который выглядит готовым, но подводит родителей сразу после перехода с главной. Проблема невидима на скриншоте тестовой среды, но очевидна пользователю. Последующая независимая проверка подтвердила, что эти риски были конкретными: шесть критических front-end проблем — битые ссылки в подвале, съехавшие мобильный и заголовок для большого экрана, тёмный текст на тёмном фоне, открытые внутренние таксономические страницы и кнопка на главной, ссылающаяся сама на себя — потребовали отдельного раунда исправлений после основной сдачи. ## Как мы это сделали **1. Шаблонно-ориентированная разработка для детской стоматологической лестницы.** Вместо того чтобы восстанавливать каждую страницу независимо, мы сопоставили структуру существующего сайта с переиспользуемыми шаблонами Elementor Pro, покрывающими всю детскую стоматологическую лестницу: - Главная, О нас, Контакты и Default Template как запасной - **Services Lander + Service Page** — основная структура клинических услуг детской стоматологии - **Doctor Page** — биография главного детского стоматолога - **Blog Lander + Blog** — архив и шаблоны отдельных постов - **Smile Gallery** — стоматологический макет «до/после» - **Privacy Policy, Terms of Conditions, Disclaimer** — юридические шаблоны 15 шаблонов, 29 страниц. Будущие правки со стороны агентства живут в одном месте для каждого типа страницы. **2. Спецификация выполнена строка за строкой, из таблицы агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для восстановления, каждый мета-заголовок и описание для переноса, каждый шаблон и 74-пунктный контрольный список запуска. Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где не было — мы сообщили агентству. Никаких «творческих интерпретаций» мы не запускали. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка на основе обхода, а не «на глаз нормально».** Перед переключением DNS мы запустили Screaming Frog на исходном сайте и тестовой среде ребилда параллельно. Коды статусов, битые ссылки, целостность мета-тегов — каждое расхождение сверяли со спецификацией агентства. Второй обход подтвердил, что каждая внутренняя ссылка разрешается на рабочем домене после переключения. **4. 74-пунктный контрольный список запуска, закрытый до сдачи.** Контрольный список охватывал точность дизайна, функциональность, корректность контента, SEO-настройки, адаптивность и специфические интеграции клиента. Ничего не запускали, пока не проверили и не согласовали каждую строку. QA на разных устройствах шло на нескольких размерах экрана, включая мобильные в портретной и альбомной ориентации — критическая проверка для детской практики, где родители часто ищут и записываются на приём с мобильных устройств. Проверка Viktor выявила шесть конкретных критических проблем — битые ссылки в подвале, сломанный мобильный заголовок, съехавший заголовок на большом экране, тёмный текст на тёмном фоне в блоге, открытые внутренние таксономические страницы, кнопка CTA на главной, ссылающаяся сама на себя — каждая решена в отдельном раунде исправлений и согласована до закрытия сдачи. Проверка обходом перед переключением выявила структурные проблемы; раунд проверки после релиза выявил видимые проблемы. ## Результаты Метрика Результат Точность спецификации — URL **29 / 29** контентных URL восстановлены, все возвращают HTTP 200 на тестовой среде до переключения Точность спецификации — мета-данные **29 / 29** мета-заголовков и описаний размещены, как указано Точность спецификации — шаблоны **15 / 15** шаблонов построены и применены на всём сайте Контрольный список запуска **74 / 74** пунктов проверено и закрыто до переключения Сроки **~21 день** для основного ребилда, сдано в срок; задачи после релиза закрыты к 2 сен; проверка Viktor завершена к 9 окт Трудозатраты **~63 ч** при оценке — без перерасхода, без расползания объёма Адаптивная проверка QA на разных устройствах подтверждено на больших и мобильных экранах Внутреннее QA Все задачи в рамках агентства проверены и решены до сдачи **Статус сайта** Работает на Kinsta по адресу https://www.dds4kids.com/. Если коротко: спецификация агентства была реализована как написано по всей детской стоматологической лестнице услуг, в рамках указанных часов, в запланированное окно переключения. Сайт остаётся в работе и проиндексирован. ## Контроль качества Проверка после релиза агентства выявила шесть конкретных критических проблем в рабочей сборке — битые ссылки в подвале, сломанный мобильный заголовок, заголовок для большого экрана со съехавшим вертикальным меню, тёмный текст на тёмном фоне в блоге, внутренние таксономические страницы, открытые для внешнего доступа, и кнопка CTA на главной, ссылающаяся сама на себя — каждая задокументирована дословно в общем баг-репорте и решена в отдельном раунде исправлений. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) для категорий и принципа нулевых ошибок. Собственный QA-контур агентства выполнялся после сдачи и фиксировал замечания в общую очередь для нашего цикла исправлений до их подтверждения. ## Процесс Этап Длительность Результат Бриф и оценка 1 день Спецификация агентства проверена; ~40 ч основной разработки оценено и согласовано Разработка ~13 дней Полный сайт восстановлен на 15 шаблонах на тестовой среде Kinsta Внутреннее QA и проверка 2 дня Задачи SEO, DEV и CX закрыты; все работы в рамках агентства завершены Проверка спецификации 1 день Мета-данные и редиректы сверены с таблицей; обход подтверждён Сдача и переключение DNS 1 день Сайт запущен на Kinsta, без простоев _Этапы накладываются (QA выполнялось параллельно с поздней разработкой), поэтому календарный срок ~21 день, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Павел Сажин** — QA и реализация исправлений после релиза - **Тимур Арбаев** — проверка дизайн-сборки и QA перед сдачей - **Наталия Богатель** — ведущий разработчик (полный ребилд сайта и система шаблонов) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на всём протяжении переключения и миграции. Все решения по сохранению URL, назначению контента и структуре страниц услуг принадлежали агентству; наша роль заключалась в точности реализации переданной спецификации. ## Агентствам, заказывающим ребилд WordPress > При ребилде сайта детской стоматологии момент переключения решает всё: работа подрядчика либо сохраняет то, что выстроило агентство, либо тихо это рушит. У этой практики одна клиника в одном городе; у других — сеть детских клиник под общим брендом. После запуска проблемы становятся видны. Редирект, который должен был перенаправить старый URL, отдаст 404. Мета-заголовки без предупреждения сменятся на стандартные значения темы. Внутренние якорные ссылки оборвутся, когда вступит в силу новая структура страниц. Спрашивать стоит не «сможете ли вы сделать ребилд», а «как вы убережёте карту редиректов и мета-заголовки». Пришлите нам адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы проверим ваш список URL на риск редиректов, отметим мета-заголовки, которым грозит подмена, и вернём фиксированную смету в часах. Проверка бесплатная, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-99-page-dental-60-days/ title: Доработка стоматологического шаблона: 99 страниц за 60 дней type: case_study date: 2025-07-19T17:40:47+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 99 URL, размещённых по 10 шаблонам агентства — унаследованный стоматологический сайт на `.html` ссылках перенесён на свежий WP Engine, Figma на каждую страницу как дизайн-контракт. Миграция URL выполнена первой: чистая структура ссылок, карта редиректов, аудит отсутствующих страниц. В середине проекта клиент отметил, что тестовая среда выглядит «непривлекательно, контент размещён непрофессионально» — дизайн-система размылась при переносе. Вторая половина работ была посвящена восстановлению этой точности в соответствии с шаблоном, прежде чем 49-пунктный контрольный список можно было закрыть. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует дизайн, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Параметр Значение Отрасль клиента Медицина — общая стоматология Клиент Grand Oaks Dentistry (стоматологическая клиника в США, Austin, TX) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + дизайн на каждую страницу на WP Engine) Объём **99 URL** — главная, лендинг услуг, страницы услуг, страница врача, персонал, отзывы, страховка/финансы, записи в блог и вспомогательные страницы Срок 60 дней (6 фев – 7 апр 2025), в срок Трудозатраты 61 час — разработка, QA-итерации, правки и управление проектом Команда 6 специалистов Шаблоны **10 переиспользуемых шаблонов**, предоставленных агентством, применённых на 99 страницах Технологии WordPress · Elementor · WP Engine · дизайн в Figma на каждую страницу · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **9 отслеженных задач**, согласованных в очереди задач агентства, по 49-пунктному контрольному списку запуска **Интенсивность коммуникации** 9 задач от агентства — все закрыты к моменту передачи **Раунды проверки** ≈4 раунда проверки за 60 календарных дней **Контрольный список запуска** 49 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США поставило задачу: перенести старый сайт Grand Oaks Dentistry на их брендированную систему шаблонов на WP Engine — сохранив контент, метаданные и структуру URL — и привести бренд клиники к дизайн-языку нового шаблона. Предварительную работу агентство уже сделало: требования клиента, выбор шаблона, настройка хостинга, подготовка контента. Нужна была команда, которая проведёт миграцию точно и пройдёт столько раундов QA, сколько потребует дизайн-соответствие. Начальная сборка шла по плану. Потом клиент посмотрел тестовый сайт и высказал замечание, которое перестроило всю вторую половину работ: сайт выглядит не так профессионально, как шаблон, который он выбрал. Дело было не в функциональности — страницы грузились, ссылки работали, контент стоял на месте. Дело было в визуальной точности. Визуальное обещание шаблона — интервалы, иерархия типографики, обработка изображений, согласованность цвета — размылось при переносе контента. Агентство боялось подрядчика, который воспринимает доработку темы как перенос контента: переложил текст и картинки из точки А в точку Б — и не спрашивает, выглядит ли результат как шаблон, за который заплатил клиент. Шаблон — это дизайн-система, не контейнер. Риск, от которого агентство страховалось, — тихая деградация этой системы при миграции. > **Контекст рисков.** Миграция шаблона, которая переносит контент точно, но теряет дизайн-систему в процессе, сдаёт сайт функционально полный, но визуально неверный. Сбой здесь эстетический, не функциональный: страницы грузятся, ссылки работают, контент на месте — но интервалы, иерархия типографики и согласованность цвета, ради которых шаблон покупался, размыты. Агентство страховалось от команды, которая воспринимает доработку темы как перевозку контента, а не исполнение дизайн-системы. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Дизайн-референсы агентства и брендированный шаблон — 2 источника истины. Наша задача — свести их постранично: там, где стандартный макет шаблона совпадал с дизайн-замыслом, мы его оставляли; где старый контент требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны. **2. QA-цикл в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, скорректировать, проверить, скорректировать». На этом проекте QA-цикл прошёл через формальный этап проверки (адаптивность, аудит ссылок, мета-теги, корректность контента), потом клиентский раунд правок для восстановления визуальной точности шаблона, потом правки уже после переноса на рабочий хостинг — до закрытия всех замечаний по тестовой среде. Каждый раунд фиксировался отдельной задачей в Redmine и закрывался только после согласования с агентством. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без расхождения.** Каждое изменение в брендированном шаблоне — будь то макет страницы, компонент секции или стилевой токен — ограничивалось слоем переопределений под конкретного клиента. Ни одна правка не ушла в общие компоненты шаблона — работа над этим проектом не затронула шаблон для следующего сайта. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах. Каждый QA-раунд охватывал страницы, затронутые правками этого раунда, а не весь сайт — именно так шаблонная сборка остаётся экономной без потери покрытия. Проблема была в том, что сайт функционально работал — страницы грузились, ссылки работали, контент стоял на месте — но потерял интервалы и согласованность цвета, ради которых выбирали шаблон. Восстановление — это второй проход по затронутым страницам, каждая сверялась с дизайн-референсом агентства, прежде чем исправленная сборка уходила обратно на QA. ## Контроль качества Внутренний этап QA выполнил проверку по контрольному списку — заголовки, title и мета-теги, ссылки, адаптивная вёрстка на большом экране и мобильных устройствах — до первой сдачи. Когда агентство отметило, что сборка отошла от визуального обещания шаблона, второй проход перед сдачей выполнил те же проверки на исправленных страницах, чтобы подтвердить восстановление точности дизайна до того, как агентство увидело исправленную сборку. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порог нулевых ошибок. Внутренний контур проверки агентства выполнялся после сдачи и выявлял задачи, которые попадали в общую очередь задач для нашего цикла исправлений до момента их подписания. Доработки оставались в слое переопределений клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL доставлено **99** — главная, лендинг услуг, страницы услуг, страница врача, персонал, отзывы, страховка/финансы, записи в блог и вспомогательные страницы Шаблонов применено **10 из 10** переиспользуемых шаблонов собраны и сопоставлены с 99 страницами (главная, лендинг услуг, страница услуги, «О нас», страница врача, «Контакты», лендинг блога, блог, Smile Gallery, стандартный шаблон) Контрольный список запуска **49 пунктов** согласованы Задачи QA / SEO отслежены и решены **9** задач согласованы в очереди задач агентства QA-итерации в Redmine **5 из 13 задач** отслежены на уровне итераций (этап QA, клиентские правки, исправления в очереди задач, обновление отзывов, доработка после запуска) Срок **60 дней**, выполнено в срок Трудозатраты **61 час** — без перерасхода, без расширения объёма Команда **6 специалистов** Передача хостинга Запущен на шаблонном окружении WP Engine агентства Здоровье страниц при сдаче **URL тестовой среды вернули HTTP 200** при аудите sitemap Если коротко: шаблон агентства был доработан на 99 страницах и 10 шаблонах за 60 календарных дней в рамках оценки в 61 час. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Figma изучена, доступ к шаблону подтверждён, объём согласован (оценка 45 часов) Разработка доработки ~2 недели Постраничная миграция контента и доработка темы QA-итерации (параллельно) ~2 недели Этап QA + раунд клиентских правок для восстановления визуального качества шаблона Раунды исправлений ~3 недели Правки после запуска, сверка метаданных, исправление редиректов, срочная доработка Сдача проекта последний день Сайт запущен на WP Engine _Разработка и QA выполнялись параллельно — это характерно для работ по доработке темы, где ни один «этап QA» не закрывается полностью; цикл идёт непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и выполнение миграции) - **Павел Сажин** — управление проектом и QA-итерации - **Анна Полунина** — QA-итерации и восстановление визуального качества шаблона - **Евгений Карпов** — поддержка разработчика на ранних раундах доработки - **Наталия Богатель** — QA и координация проекта - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, приёмка) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне агентства-партнёра на протяжении всего проекта. Конечный клиент нас не видел: все запросы на доработку шли через общую очередь задач агентства, и сборка ему напрямую не показывалась. Каждый раунд закрывался только после того, как проверяющий со стороны агентства подтверждал, что изменения выполнены в соответствии со спецификацией. ## Агентствам с библиотекой шаблонов > Брендированный шаблон — это дизайн-система, а не просто тема. Агентство в неё вкладывается, и подрядчик обязан эту инвестицию беречь. У этой практики — косметическая и реставрационная стоматология; у других — детская клиника или сеть с единым брендом и несколькими адресами. Риски конкретны: следующее обновление родительского шаблона сломает ваши доработки в дочерней теме; бренд-токены из настроек темы плохо лягут в жёстко прописанные запасные значения; ACF-схема разойдётся между ядром шаблона и вашими доработками, и редакторский интерфейс перестанет работать у сотрудников клиники. Спрашивайте подрядчика не «соберёте ли на шаблоне?». Спрашивайте «как именно вы построите клиентский слой, чтобы обновления родительской темы не трогали доработки?» Пришлите исходник шаблона или его ID и спецификацию бренда вашего клиента. Мы сверим клиентский слой с родительской схемой, покажем, где следующее обновление сломает ваши доработки, и вернём фиксированную смету в часах. Аудит без оплаты; смета приходит в часах, не диапазоном. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/agency-template-library-build-multi-vertical/ title: Библиотека из 17 шаблонов на WordPress — Стоматология и Ветеринария type: case_study date: 2025-07-16T13:31:16+00:00 case_industry: Межотраслевые case_type: Разработка case_practice: wordpress --- ## Подход к разработке 17 шаблонов — 15 стоматологических, 2 ветеринарных — построены по поточному заказу за 14 месяцев для маркетингового агентства из США, ведущего национальный сервис стоматологических сайтов. Каждый шаблон попадал в действующую библиотеку, уже активно используемую в работе; дефект, допущенный в любом шаблоне, распространялся вперёд на каждый клиентский проект, основанный на нём. Главным было точно воспроизвести макет в Figma на изолированных инстансах и — с Q4 2025 — прогнать каждый шаблон через трёхуровневую внутреннюю цепочку QA перед попаданием в каталог. ## Краткий обзор Параметр Значение Отрасль конечного клиента Мультивертикальная — Стоматология + Ветеринария (внутренняя библиотека шаблонов агентства) Конечный клиент Нет — это долгосрочный внутренний проект для собственной системы шаблонов агентства **Тип проекта** **Долгосрочная разработка библиотеки шаблонов на WordPress для маркетингового агентства из США, ведущего национальный white-label сервис стоматологических и медицинских сайтов** Тип проекта 17 изолированных сборок шаблонов на Elementor Pro в тестовых инстансах WordPress под управлением агентства Объём **15 стоматологических шаблонов** (Шаблоны 1–4, 6–10, 12–17) + **2 ветеринарных шаблона** (Vet Templates 1 и 2). Структура каждого шаблона: главная, внутренние страницы услуг, контакты, страница врача, лендинг блога, блог, финансирование и шаблон по умолчанию. Адаптивность (desktop · tablet · mobile) для каждого шаблона. Сроки 14 месяцев (декабрь 2024 – февраль 2026) — поточная сдача, а не единовременный спринт Трудозатраты **~430 часов** на основные задачи разработки, раунды итераций дизайна и структурированную цепочку QA, введённую в Q4 2025 Команда 4 основных специалиста в течение проекта Источник дизайна Figma на каждый шаблон — предоставлялась дизайн-командой агентства по мере заказа шаблонов Технологический стек WordPress · Elementor Pro · Hello Elementor · Gravity Forms · FastPanel (серверное окружение) · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Результат** **17 изолированных инстансов шаблонов на WordPress — разработано, проитерировано, проверено QA и передано в библиотеку развёртывания агентства** ## Постановка задачи Маркетинговое агентство из США ведёт национальный white-label сервис сайтов для стоматологических и медицинских практик. Когда новый клиент-практика подключается, агентство выбирает шаблон из своей библиотеки, и начинается проект по доработке темы. Библиотека — это продукт агентства, исходный актив, от которого происходит каждый клиентский проект. Её поддержка и расширение требуют партнёра по разработке, способного работать на постоянной многомесячной основе, поставляя новые шаблоны в ритме заказа агентства, а не в рамках одного контрактного спринта. В декабре 2024 года библиотека шаблонов агентства насчитывала семь стоматологических шаблонов, созданных в предыдущем проекте. Библиотеку требовалось расширить: добавить новые визуальные направления в стоматологии, развить внутренние страницы за пределами существующих главных и — на втором году — новый ветеринарный сегмент для обслуживания той части клиентов, чьи практики лечат домашних животных. Агентство привлекло нас как долгосрочного партнёра по разработке шаблонов. Модель заказа была поточной: новые шаблоны выдавались по мере завершения дизайн-командой агентства файлов Figma, обычно со сроком от 2 до 4 недель на шаблон. Каждый шаблон был отдельной задачей в Redmine; итерации дизайна и цепочка QA порождали подзадачи к родительской задаче шаблона. > **Контекст рисков** — Работа над библиотекой шаблонов несёт в себе режим отказа, структурно отличный от сборки для одного клиента. Когда дефект попадает в клиентский проект, его воздействие ограничено этой практикой. Когда дефект закладывается в библиотечный шаблон, он становится молчаливым пассивом в каталоге: любой будущий клиентский проект, выбравший этот шаблон, наследует ошибку в момент начала доработки темы, а не в момент сборки шаблона. Цена растёт с каждой последующей доработкой. Риск здесь не в том, что «этот шаблон неверен», а в том, что «каждый сайт, построенный на этом шаблоне, неверен, пока кто-то это не обнаружит». Эта динамика накопления дефектов — ошибки, незаметно размножающиеся на нереализованный будущий объём клиентов, — задаёт ту планку качества, которая уместна для такого рода проектов. Точная сборка с первого раза и выявление расхождений до попадания шаблона в библиотеку — единственный барьер, который держит. ## Как мы это сделали **1. Поточный заказ пятнадцати стоматологических и двух ветеринарных шаблонов.** Каждый шаблон запускался отдельной задачей в Redmine, когда агентство выдавало дизайн-файл в Figma. Поточный, поочерёдный ритм означал, что команда не могла пакетно оптимизировать работу между шаблонами: каждый новый Figma приходил со своим сроком, и выгадать на последовательной отладке было нельзя. Несколько файлов Figma были переданы с неполными дизайн-заметками для внутренних страниц — заметно на сборке Dental Template 16, где команде пришлось запросить у агентства завершение незакрытых дизайн-комментариев до продолжения работы. Шаблоны 1–4 и 6–7 начались с разработки внутренних страниц в начале 2025 года (задачи в окне февраль–апрель), расширяя шаблоны, которые до этого существовали только как главные страницы. Стоматологические шаблоны 8, 9 и 10 последовали в окне апрель–июль; шаблоны 12–17 были заказаны в период июль–декабрь 2025 года. Ветеринарные шаблоны 1 и 2 были введены в декабре 2025 и феврале 2026 года, расширяя библиотеку во второй отраслевой сегмент. Каждый шаблон занимал собственную установку WordPress — отдельный админ-доступ, отдельное окружение Elementor, отдельный инстанс Gravity Forms — осознанный выбор изолированной архитектуры вместо общего мультисайта, чтобы сборка одного шаблона не могла затронуть другой и дефект в одном инстансе не мог незаметно распространиться на последующую клиентскую работу библиотеки. **2. Разработка внутренних страниц как основная единица сборки.** Ранняя фаза проекта была сосредоточена на добавлении внутренних страниц к шаблонам, существовавшим только как главные страницы. Это был структурный пробел в библиотеке: без полного набора внутренних страниц (страницы услуг, контакты, врач, блог, финансирование, шаблон по умолчанию) разработчики агентства не могли надёжно собрать полноценный клиентский сайт из шаблона. Систематически, для каждого шаблона по очереди, команда проходила стандартную структуру из 10 страниц: Главная · О нас · Страница врача · Лендинг услуг · Страница услуги · Лендинг блога · Блог · Финансирование · Контакты · Шаблон по умолчанию. Каждая страница должна была точно соответствовать Figma на уровне компонентов — не только основная вёрстка, но и масштабирование типографики, поведение кнопок, мобильные точки адаптации и любые специфичные для шаблона компоненты (например, собственные варианты слайдеров, иконки, вложенность секций). **3. Раунды дизайн-итераций при обновлении агентством Figma.** Для шаблонов 2, 4, 6 и 7 агентство выпускало обновлённые файлы Figma после первоначальной сборки — изменения в вёрстке главной, состояниях наведения кнопок или пропорциях секций на основе замечаний проверяющих. Это порождало выделенные задачи итерационных раундов (помеченные в Redmine как «Iteration 2. Design updates for Template #N»). Подход был тот же: работать по обновлённому Figma на уровне компонентов, проверять изменения относительно предыдущей сборки, закрывать раунд. Эта модель — сборка → проверка агентства → обновление дизайна → доработка — отражает реальный жизненный цикл библиотеки шаблонов: дизайн эволюционирует по мере того, как агентство калибрует, что продаётся, и библиотека должна отслеживать эти изменения, не накапливая постоянного расхождения между спецификацией Figma и развёрнутым шаблоном. **4. Систематическая цепочка QA на каждый шаблон, формализованная в Q4 2025.** По мере того как библиотека выросла за пределы 10 шаблонов и начали появляться более трудоёмкие стоматологические шаблоны (шаблоны 13–17 требовали от 7 до 35 часов на сборку), агентство формализовало свой процесс проверки в структурированную трёхуровневую цепочку QA. Каждая сборка шаблона, прошедшая внутреннюю проверку разработчика, передавалась специалисту по QA (Тимур Арбаев), который создавал выделенную подзадачу в Redmine со своими находками. Правки Тимура затем проверялись и подтверждались вторым проверяющим (Павел Сажин), прежде чем задача переходила в статус «отправлено, ожидание ответа» — финальный этап до добавления агентством шаблона в живую библиотеку. Свидетельство в Redmine — шаблон именования QA-подзадач: каждая содержит имя проверяющего и метку даты (например, «Dental Template 16 — Тимур-20260112-qa», «Dental Template 16 — Павел-20251226-qa», «Dental Template 16 — xaver-20260115-qa»). Для самых сложных шаблонов в финальном квартале эта цепочка QA порождала три отдельные подзадачи на шаблон — по одной на проверяющего — с полным циклом сборки, отметок, исправлений и повторного прохода, документированным в каждой. Это не издержки, а механизм, которым библиотечный шаблон заслуживает своё место в рабочем каталоге. **5. Ветеринарный сегмент: новая структура страниц, иная лексика.** Когда агентство заказало Vet Templates 1 и 2 в конце 2025 и начале 2026 года, подход к сборке был идентичен стоматологическому, но структура страниц и лексика начинались с нуля. Ветеринарные шаблоны требуют страницу врача, где представлены ветеринары, а не стоматологи, лендинг услуг, соответствующий уходу за домашними животными, и структуру страницы по умолчанию, избегающую любой стоматологической лексики. Оба шаблона были построены по дизайну Figma, предоставленному агентством, с тем же стандартным набором из 10 страниц — базовая структура страниц едина для всех вертикалей; меняется только формулировка, соответствующая каждой из них. Только Vet Template 2 имел оценку в 30 часов с собственной трёхуровневой цепочкой QA-проверки. Семнадцать шаблонов за четырнадцать месяцев, каждый на отдельном инстансе WordPress — изоляция была структурной гарантией. Дефект, обнаруженный на одном шаблоне, оставался ограниченным; он не мог распространиться на другую сборку, уже ведущуюся или уже находящуюся в библиотеке. ## Контроль качества QA перед сдачей в этом проекте библиотеки шаблонов проводилось по цепочке проверки на каждый шаблон — проверка разработчика, затем выделенный QA-проход с задачей в Redmine на шаблон, затем подтверждающая проверка — прежде чем каждый шаблон маркировался как готовый для библиотеки агентства. QA перед сдачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Контроль на стороне агентства проводился после передачи и сводил замечания в общую очередь правок для нашего цикла исправлений до их финального утверждения. ## Результаты Метрика Результат Стоматологических шаблонов разработано **15** — Шаблоны 1–4, 6–10, 12–17, каждый на изолированном инстансе WordPress Ветеринарных шаблонов разработано **2** — Vet Templates 1 и 2, расширение во второй отраслевой сегмент Всего шаблонов в библиотеке **17** — мультивертикальная (стоматология + ветеринария) Стандартный набор страниц на шаблон **10 страниц** — Главная · О нас · Страница врача · Лендинг услуг · Страница услуги · Лендинг блога · Блог · Финансирование · Контакты · Шаблон по умолчанию Раунды дизайн-итераций **4** стоматологических шаблона получили раунды обновления дизайна «Iteration 2» (Шаблоны 2, 4, 6, 7) — обновления Figma, транслированные обратно в развёрнутый инстанс Цепочка QA на шаблон (Q4 2025) **Трёхуровневая структурированная проверка** — внутреннее разработчика → QA-подзадача Тимур Арбаев → подтверждение Павел Сажин — задокументировано в Redmine для каждого шаблона в финальном квартале Общие трудозатраты **~430 ч** на разработку, итерации, цепочку QA и кросс-вертикальный объём Сроки **14 месяцев** (декабрь 2024 – февраль 2026) — устойчивая поточная сдача Рабочий URL Нет — шаблоны находятся в тестовых инстансах агентства (закрытые), не являются публичными клиентскими сайтами Статус библиотеки Все подтверждённые шаблоны доступны в библиотеке развёртывания агентства; последние шаблоны — на финальном QA или ожидают ответа агентства ## Процесс Этап Продолжительность Результат Настройка каталога библиотеки и ранняя разработка внутренних страниц (Шаблоны 1–4, 6–7) дек 2024 – апр 2025 Существовавшие шаблоны на базе главных страниц расширены полной 10-страничной внутренней структурой; шаблоны 2, 4, 6, 7 получили по раунду дизайн-итерации после проверки агентства Расширение середины библиотеки — новые стоматологические шаблоны (8, 9, 10, 12, 13) апр 2025 – сен 2025 Пять новых стоматологических шаблонов, построенных по Figma, охватывающих новые визуальные направления; Шаблон 10 также прошёл раунд доработок по обратной связи агентства Расширение поздней фазы — шаблоны высокой сложности (14, 15, 16, 17) сен 2025 – янв 2026 Четыре крупных стоматологических шаблона (7–35 ч каждый) построены и пропущены через структурированную цепочку QA Q4; трёхуровневая проверка на шаблон задокументирована в Redmine Ветеринарный сегмент — Vet Templates 1 и 2 дек 2025 – фев 2026 2 шаблона для практик лечения домашних животных, построенных по Figma; Vet Template 2 завершён с трёхуровневой цепочкой QA; Vet Template 1 разрешён и подтверждён Формализация цепочки QA (действует с Q4 2025) окт 2025 – фев 2026 Трёхуровневая цепочка QA (разработчик · Тимур · Павел) стандартизирована для всех новых и дорабатываемых шаблонов; след из подзадач Redmine на каждый шаблон установлен _Этапы пересекались — новые шаблоны заказывались, пока предыдущие находились на QA или в итерационных раундах. 14-месячный календарный охват отражает устойчивую параллельную работу, а не последовательную очередь._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик библиотеки шаблонов; основная интерпретация Figma и реализация на Elementor для большинства стоматологических и ветеринарных шаблонов - **Тимур Арбаев** — специалист по QA; выпускал структурированные QA-подзадачи на шаблон с находками и поддерживал циклы повторного прохода до подтверждения шаблонов - **Павел Сажин** — проверяющий второй ступени; финальное утверждение QA перед передачей шаблонов агентству - **Анна Полунина** — поддержка реализации и QA по отдельным шаблонам, особенно на ранних этапах - **Наталия Богатель** — разработчик Vet Template 1 - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта; оценка, коммуникация с аккаунт-менеджером агентства, управление ритмом заказа и финальная передача каждого шаблона Управление проектом со стороны агентства, производство дизайна и принятие решений по клиентам оставались за партнёрским агентством на протяжении всего проекта. Конечных клиентов в этом проекте не было — результатом была сама библиотека. ## Агентствам, заказывающим разработку WordPress > На мультивертикальном сайте для здравоохранения каждая практика — стоматология и ветеринария — требует отдельной модели контента и таксономии URL. У одних заказчиков — одна практика с единственным типом услуг; у других — две разные вертикали на одной платформе. Риски тихие: новая стоматологическая услуга не впишется в URL из-за конфликта с ветеринарной таксономией, фильтры смешают страницы разных специальностей, структурированная разметка слетит на импорте — расширенные результаты пропадут из отчётов агентства. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы изолируете модели контента для каждой вертикали в единой таксономии?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы проверим URL-план на конфликты между вертикалями, отметим узкие места и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-veterinary-17-pages-13-days/ title: Ребилд ветеринарного WordPress-сайта: 17 страниц, 13 дней, строго по спецификации — White-label для агентства из США type: case_study date: 2025-07-15T19:04:29+00:00 case_industry: Ветеринария case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Ребилд 17-страничного сайта для бренда ветеринарного коучинга и консалтинга — не сайт клиники, а B2B-платформа, обслуживающая многофилиальные ветеринарные практики в шести регионах США. Пять гео-лендингов были исключены из объёма в процессе оценки, когда агентство подтвердило отсутствие дизайнов — контракт сузился до ребилда того, что уже существовало на старом сайте, со сроком в 13 дней. ## Краткий обзор Поле Значение Индустрия конечного клиента Ветеринария — B2B-коучинг и консалтинг для ветеринарных клиник Конечный клиент Veterinary Mastery (фирма ветеринарного коучинга, многофилиальная) **Формат сотрудничества** **White-label WordPress ребилд для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг WP Engine Объём Весь сайт — главная, блог, «О нас», контакты, биографии коучей, лендинг электронной книги, отзывы, страницы услуг Сроки 13 дней (7–20 мая 2025), по графику Трудозатраты 42,7 часа — основной ребилд (20 ч разработка · 10 ч QA · 10 ч PM) в рамках оценки; последующие доработки — в рамках тех же отношений с агентством Команда 5 специалистов (Анна Полунина — ведущий разработчик · Павел Сажин — QA · Антон Херсун — PM) Технологический стек WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) Проверка паритета контента Сверка контента оригинала и ребилда пройдена до передачи — ни пропущенного текста, ни битых внутренних ссылок, ни структурных расхождений **Результат** **Спецификация выполнена построчно — 17 исходных страниц перестроены, 8 шаблонов применены, 20+ задач QA закрыты, ни одного редиректа смены путей** Последующая работа 5 дополнительных гео-страниц услуг построены в июле–августе 2025, плюс решение проблем на рабочем сайте и закрытие очереди задач по контенту — всё в рамках тех же отношений с агентством **Интенсивность взаимодействия** 21 задача от агентства · 20 из 21 закрыты к моменту передачи (22-дневный активный период, 17.07–07.08.2025) **Раунды проверки** ≈6 раундов проверки за 13 календарных дней **Контрольный список запуска** 29 пунктов, согласованы перед переключением ## Постановка задачи У агентства был постоянный клиент — Veterinary Mastery, фирма ветеринарного коучинга и консалтинга, обслуживающая владельцев практик в нескольких городах США, — чей существующий WordPress-сайт нуждался в ребилде на современном, поддерживаемом стеке. Агентство уже проделало подготовительную работу: таблица Google Sheets со всеми URL для ребилда, назначениями шаблонов, URL тестовой среды и контрольным списком запуска, организованным по семи категориям. Задача была конкретной. Взять спецификацию как есть; выполнить ребилд сайта на Elementor Pro; сохранить каждый существующий URL (ребилд в той же CMS — никаких изменений путей); вернуть готовым к переключению на WP Engine. Оставаться вне клиентского контура. Внедрить SEO-решения как написано. Уложиться в оценённые часы. Риск, от которого агентство хотело застраховаться, был не в разрыве CMS — платформа оставалась WordPress — а в студии, которая тихо импровизировала бы вокруг брифа: пропущенная гео-страница, кнопка CTA, ведущая на уже несуществующую страницу, биография коуча, потерявшая H1, архив блога, отошедший от исходной вёрстки. > **Контекст рисков.** Фирма ветеринарного коучинга не продаёт продукты — она продаёт экспертизу, и её сайт — это основная поверхность генерации лидов. Каждый URL гео-страницы, ранжирующийся по запросу «ветеринарный консультант [город]», каждый путь скачивания электронной книги, захватывающий email владельца практики, каждая страница биографии коуча, формирующая доверие — всё это активы, приносящие доход. При ребилде в той же CMS видимый риск невелик: URL остаются теми же, платформа остаётся той же. Невидимый риск — это расхождение контента: пропущенная гео-страница, кнопка CTA, ведущая в никуда, скачивание электронной книги, ломающееся после переключения, биография коуча, потерявшая H1. Каждый случай по отдельности объясним; вместе они разрушают воронку лидогенерации, на которую агентство поставило свою репутацию. ## Как мы это сделали **1. Сборка на основе шаблонов.** Вместо того чтобы перестраивать 17 страниц по одной, мы свели их к восьми переиспользуемым шаблонам и разместили каждую страницу в соответствующем шаблоне: - Главная, «О нас», «Контакты» и запасной Default Template - **Блог (лента) + запись блога** — архив и отдельные посты - **Service Page** — применён к странице локации Utah и впоследствии расширен на пять дополнительных гео-страниц - **Doctor Page** — отдельные страницы биографий коучей (Brianne и Laura) 8 шаблонов, 17 исходных страниц готовы. Будущие правки со стороны агентства живут в одном месте на тип страницы. **2. Спецификация выполнена построчно, по таблице агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для ребилда с назначением шаблона и каждый URL тестовой среды. Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где его не было — например, страница goldenticket, существовавшая на исходном сайте, но изначально не отражённая в ребилде — мы сообщили об этом агентству, подтвердили требование и добавили. Никаких «творческих интерпретаций» не попало в итоговую сборку. Принцип здесь прост: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка на основе обхода, а не «на глаз нормально».** Перед переключением DNS мы прогнали Screaming Frog параллельно по исходному рабочему сайту и по тестовой сборке. Коды статусов, битые ссылки, согласованность внутренних ссылок, различия мета-тегов — каждое расхождение сверяли со спецификацией агентства. Второй обход после запуска подтвердил, что каждая внутренняя ссылка работает на действующем домене. **4. Контрольный список запуска по семи категориям, закрыт до передачи.** Design, Functionality, Content, SEO & Analytics, Responsive, клиентские интеграции и миграция Domain & DNS на WP Engine. Ничего не уходило в работу, пока не согласуют каждую строку. QA на разных устройствах на Chrome / Firefox / Safari / Edge и шести форматах экрана (1920 / 1280 / 1024 / iPad / портретный и альбомный мобильный). Контактную форму проверили по всей цепочке — с реальной отправкой на email клиента. Исключение пяти неспроектированных гео-страниц на этапе оценки означало, что 13-дневный контракт был ограничен ещё до того, как пошла первая строка кода — агентство подтвердило, что существует на старом сайте, мы перестроили именно это, а расширение вернулось в виде чистого постоянного заказа в июле. Этот порядок сохранился: никакого расползания объёма в окне ребилда, пять новых страниц Service Page в последующей работе, использующих тот же шаблон без изменений. ## Результаты Метрика Результат Точность по спецификации — страницы **17 / 17** оригинальных URL контента, отдающих HTTP 200 на тестовую среду до переключения Точность по спецификации — шаблоны **8 / 8** шаблонов построено и применено на всём сайте Точность по спецификации — редиректы **0 редиректов смены путей** потребовалось (ребилд с теми же URL) Контрольный список запуска Пункты по 7 категориям согласованы до переключения Сроки **13 дней**, сдано по графику Трудозатраты **42,7 ч** всего, основной ребилд и последующие доработки — без перерасхода, без расползания объёма Адаптивность Ноль проблем с вёрсткой на 4 браузерах × 6 форматах экрана Внутреннее QA Все задачи в рамках агентства закрыты до передачи (20+ из 20+ отмеченных; остальные были заблокированы клиентом или вне объёма агентства) Передача Сайт запущен на WP Engine в запланированный день переключения, без простоя Статус сайта [veterinarymastery.com](https://www.veterinarymastery.com/) работает и индексируется Google Если коротко: спецификация агентства была реализована как написано, в рамках оценённых часов, в запланированный день переключения. Спустя 11 месяцев сборка продолжает работать. ## Контроль качества QA перед передачей на тестовой сборке выявил CTA в шапке сайта, ведущий на /goldenticket — страницу, существовавшую на исходном сайте, но не включённую в спецификацию ребилда; расхождение было отмечено для агентства, подтверждено и перестроено до передачи. QA перед передачей проводился через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Внутренний контроль агентства работал после передачи и заносил замечания в общую очередь задач для нашего цикла исправлений, пока они не подписывали. ## Процесс Фаза Длительность Результат Бриф и оценка 1 день Спецификация агентства изучена; 20 ч основного ребилда оценено и согласовано Разработка ~5 дней Весь сайт перестроен на 8 шаблонах Внутреннее QA и проверка 2 дня Зарегистрировано 20+ задач; вся работа в рамках агентства закрыта Проверка спецификации 1 день Соответствие страниц и шаблонов сверено с таблицей Передача и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Фазы пересекаются (QA шло параллельно с поздней разработкой), поэтому календарный срок — 13 дней, а не сумма отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — проверка сборки и поддержка QA - **Павел Сажин** — исправления QA и внедрение мета-данных - **Анна Полунина** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Людмила Травкина** — QA-проход и координация проверки перед передачей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на всём протяжении переключения и миграции. Все решения о сохранении URL и назначении контента принадлежали агентству; нашей ролью была точность реализации по переданной ими спецификации. ## Агентствам, заказывающим ребилд WordPress > Сайт ветеринарного коучинга генерирует лиды через контент. У этой практики — воронка через подписку на контент (гео-страницы, руководства); у других — разовая продажа диагностики. Тихая ошибка при ребилде: гео-страница отдаёт 404, лид-магнит не доходит до CRM агентства, структурированная разметка на странице эксперта пропадает — расширенные результаты выпадают из аудит-панелей. Подрядчику стоит задавать не вопрос «сохраните ли контент?», а вопрос «как именно проверите, что каждый лид-актив продолжает приносить конверсию после переноса?» Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Проверим, что редиректы покрывают все ранжирующиеся страницы, ни одна лид-воронка не разорвана, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-14h-46-days/ title: Компактная доработка стоматологического шаблона за 46 дней, ~14 часов type: case_study date: 2025-07-08T23:43:16+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы Доработка стоматологического шаблона за 14 часов в условиях недельного срока в праздничный период. Бриф Павла от 18 декабря: «до среды 24 числа надо успеть + 2 дня на проверку». Проверка началась в тот же день и шла через Рождество и 26 декабря. Главным оказалось выявить стилевые расхождения внутри самой Figma: Тимур зафиксировал 23 декабря «6 секций подряд — в каждой у тайтла свой стиль». Семь раундов проверки через праздничный период — без длинного списка правок после сдачи. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология — общая практика Конечный клиент Brown Dental (общая стоматологическая практика, Atlanta, GA) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка WordPress-шаблона (брендированный шаблон агентства «dental-template10» + дизайн в Figma на уровне страниц, Kinsta) Объём работ Главная, лендинг услуг, страницы услуг, биография врача, контакты, галерея улыбок и вспомогательные страницы — доработка по постраничному референсу из Figma агентства Сроки 46 дней (19 дек 2025 – 2 фев 2026), по графику: компактная основная доработка + 7 последовательных раундов проверки QA Трудозатраты **~14 часов** суммарно — 6,8 ч основная доработка + ~7 ч на раунды QA и итерации исправлений Команда 5 специалистов (разработка + QA + управление проектом) Шаблоны Брендированный шаблон агентства «dental-template10», применённый на дорабатываемых страницах с дизайном в Figma на уровне страниц Технологический стек WordPress · Elementor · хостинг Kinsta · дизайн в Figma на уровне страниц · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **7 последовательных раундов проверки** (под руководством Павла, Тимура, xaver-ops) за праздничный период — первый проход 18 декабря, финальный — 24 января **Раунды проверки** ≈4 раунда проверки за 46 календарных дней **Контрольный список запуска** 78 пунктов, согласованы перед переходом на рабочий сервер ## Постановка задачи У агентства был постоянный стоматологический клиент в Atlanta — Brown Dental, общая стоматологическая практика — и поступил запрос на доработку по брендированному шаблону агентства «dental-template10». Постраничный референс из Figma был предоставлен; наша задача — дорабатывать шаблон на тестовом сервере Kinsta по этому референсу и провести его через цикл проверки агентства до финального запуска. Задача была конкретна в части доработки темы: не изменять общие компоненты шаблона, дорабатывать только переопределения для конкретного сайта, следовать дизайну в Figma на каждой странице, возвращать сайт через цикл проверки агентства на согласование. Не выходить на прямой контакт с клиентом на протяжении всего проекта. Запросы на доработку, уточнения по дизайну и отношения с конечным клиентом остаются за агентством. Окно для доработки составляло одну неделю до первого прохода проверки 18 декабря — слишком сжато для устранения расхождений Figma на уровне шаблона, поэтому сборка продолжилась с базой «dental-template10» как есть. > **Контекст рисков.** График работ по этому проекту был компактным и пришёлся на праздничный период. Первый проход прошёл 18 декабря; цикл QA шёл через 26 декабря и 1 января вплоть до финального прохода 24 января. Специфический риск сжатого расписания на небольшой доработке темы — не охват (все страницы были собраны), а **стилевой дрейф внутри самого референса из Figma**: когда несколько секций подряд несут слегка разные варианты оформления заголовков, ритмы межсекционных отступов или разные регистры H2, торопливая доработка воспроизведёт этот дрейф дословно. Выявлять стилевые расхождения внутри Figma в процессе сборки, сообщать о них агентству и устранять их в середине спринта — это другая работа, нежели построчное соответствие Figma. На проекте с праздничным ритмом, где проверяющий QA работает в таких же жёстких дедлайнах, команда разработки несёт нагрузку по проверке стилевой целостности. Доработка, которая точно воспроизводит несогласованную Figma, — уже не доработка, а копирование. ## Как мы это сделали **1. Постраничная доработка по Figma агентства.** Сборка прорабатывала брендированный шаблон агентства «dental-template10» — доработка главной, лендинга услуг, отдельных страниц услуг, биографии врача, галереи улыбок, контактов и вспомогательных страниц по постраничному референсу из Figma. Доработка велась через переопределения для конкретного сайта; общие компоненты шаблона не затрагивались, что сохраняло целостность системы шаблонов для других практик на том же шаблоне. **2. Выявление стилевого дрейфа в середине спринта.** В процессе сборки всплыло несколько мест, где идущие подряд секции Figma несли несогласованные варианты оформления — разные стили заголовков в рамках единого визуального ритма, смешанные регистры H2 в последовательных секциях, расхождения в отступах, которые при просмотре на большом экране читались бы как явный дрейф. Каждое из них было поднято перед агентством для принятия решения по Figma, а не устранено самостоятельно — потому что самостоятельное исправление с угадыванием предпочтительного решения агентства грозило переделкой, если исходный замысел агентства был другим. А у семираундового цикла QA не было места для прохода переделки. **3. Семираундовый последовательный цикл проверки за праздничный период.** Ритм проверки был необычно плотным для масштаба проекта: первоначальный проход под руководством Павла 18 декабря, перекрёстная проверка xaver-ops 19 декабря, повторная проверка Павла 26 декабря (день после Рождества), проход Тимура в тот же день для широкого охвата, проход xaver-ops 26 декабря как третьего проверяющего, проход 1 января для подтверждения внедрения праздничных исправлений и финальный проход 24 января перед согласованием агентством. Каждый раунд давал список расхождений по Figma; ничего не закрывалось, пока следующий раунд не подтверждал, что исправления предыдущего раунда внедрены без появления новых расхождений. **4. Сжатый график — за счёт плотного взаимодействия с агентством.** Очередь правок после запуска осталась короткой — плотный ритм проверки поглотил исправления, которые на проекте с более длинным расписанием могли бы всплыть как задачи после запуска. Лучшее тому свидетельство здесь — плотность цикла проверки (7 раундов за 46-дневное окно) и отсутствие длинного хвоста после запуска; проект закрылся по сжатому графику агентства, а не перешёл в цикл исправлений после сдачи. Семь раундов проверки за 38 дней — первый 18 декабря, последний 24 января — каждый проход подтверждал внедрение исправлений предыдущего раунда до того, как следующий проверяющий открывал сайт. Именно плотный ритм поглотил исправления; цикла правок после сдачи не было, потому что в условиях срока, который должен был пройти через Рождество, места для него просто не оставалось. ## Контроль качества Проход Тимура 23 декабря выявил ключевую находку проекта: «6 секций подряд — в каждой у тайтла свой стиль» — шесть идущих подряд секций Figma с разным оформлением заголовков; исправления шли через Рождество и закрылись финальным проходом Тимура 26 декабря. Проверку перед передачей вели через **Site Checker** — категории и порог нулевых ошибок описаны в [нашем подходе к проверке](/site-checker/). Проверка со стороны агентства запускалась после передачи и вносила оставшиеся вопросы в общую очередь правок для нашего цикла исправлений вплоть до согласования. Доработки остались в клиентских переопределениях; общие компоненты шаблона агентства мы не трогали. ## Результаты Метрика Итог Сроки **46 дней** (19 дек 2025 – 2 фев 2026) — основная доработка + 7 раундов QA + финальное подписание агентством, всё по графику в праздничный период Трудозатраты **~14 часов** суммарно — 6,8 ч основная доработка + ~7 ч на раунды QA и итерации исправлений (один из самых компактных проектов доработки темы в корпусе) Плотность цикла проверки **7 последовательных раундов проверки** за 38 дней — перекрёстная проверка Павел + Тимур + xaver-ops 18 дек, 19 дек, 26 дек, 26 дек, 26 дек, 1 янв и 24 янв Выявление стилевого дрейфа Несогласованные варианты оформления заголовков и отступов между секциями внутри Figma выявлены в процессе сборки, переданы агентству и устранены до следующего раунда проверки Хвост после запуска Минимальный — плотный ритм проверки поглотил исправления внутри окна проекта; длинного цикла правок после согласования не было Проверка на разных устройствах Доработка проверена на больших экранах и мобильных устройствах в ходе цикла проверки **Статус сайта** Работает на Kinsta, открывается по адресу http://browndentalatl.com/. Если коротко: компактная доработка стоматологического шаблона прошла через плотный цикл проверки в праздничный период без перехода в длинный список правок после сдачи. Работа в сжатом графике — главная особенность этого проекта. ## Процесс Фаза Продолжительность Результат Бриф и проверка шаблона ~1–2 дня Figma агентства + dental-template10 проверены; подготовлен постраничный список доработок Основная доработка ~5–7 дней Страницы доработаны по Figma; стилевые расхождения подняты в середине спринта Внутренняя проверка — раунд 1 18 дек Проход под руководством Павла Внутренняя проверка — раунд 2 19 дек Перекрёстная проверка xaver-ops Внутренняя проверка — раунд 3 26 дек Повторная проверка Павла Внутренняя проверка — раунд 4 26 дек Проход Тимура для широкого охвата Внутренняя проверка — раунд 5 26 дек Проход xaver-ops как третьего проверяющего Внутренняя проверка — раунд 6 1 янв Проверка исправлений праздничного периода Внутренняя проверка — раунд 7 24 янв Финальный проход перед согласованием агентством Передача агентству конец января Сайт доставлен на тестовый сервер для проверки агентством ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик - **Павел Сажин** — руководитель QA (раунды 1, 3 — первоначальный проход и повторная проверка 26 декабря) и поддержка разработки при итерациях исправлений - **Анна Полунина** — поддержка доработки темы и QA - **Тимур Арбаев** — поддержка QA (раунд 4 для широкого охвата, проверка в праздничный период) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороны агентства, координация подписания, проходы QA xaver-ops в раундах 2, 5, 6, 7) Управление проектом со стороны агентства, дизайн, подбор контента и взаимодействие с конечным клиентом оставались за партнёрским агентством на протяжении всего проекта. Brown Dental с нашей командой напрямую не работал. Все запросы на доработку поступали через общую очередь задач агентства; о сборке конечный клиент ничего не видел. ## Агентствам с библиотекой шаблонов > На сайте стоматологической клиники, построенном на готовом WordPress-шаблоне, граница между доработками и ядром темы — главная точка отказа для агентства-заказчика. У этой практики — частный кабинет с единым перечнем услуг; у других — сетевая организация с разными филиалами и специализациями. Если подрядчик не выверит эту границу, доработки слетят при первом обновлении темы — клиент потеряет согласованные правки. Редакторский интерфейс окажется неочевидным: менеджеры не смогут добавить новую страницу без разработчика. Стилевые расхождения между разделами станут заметны при беглом просмотре. Подрядчику стоит задавать не вопрос «соберёте ли все страницы по макетам?», а вопрос «как именно вы переживёте следующее обновление шаблона?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы проверим, как ваши доработки уживаются с ядром, подсветим риски при будущих обновлениях и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-refresh-dental-57-tickets-73-days/ title: Продолжение обновления дизайна — 57 задач, 73 дня, стоматология type: case_study date: 2025-07-05T00:25:41+00:00 case_industry: Здравоохранение case_type: Обновление дизайна case_practice: wordpress --- ## Подход к обновлению 57 задач за 73 дня для обновления дизайна сайта стоматологической клиники, которое было уже в процессе — обновлённая главная страница агентства была опубликована, но хедер и футер не распространились на остальные 33 страницы, четыре новые сервисные страницы ждали утверждённых макетов в Figma, а очередь запросов на изменения уже начала формироваться. С первого дня параллельно велись три рабочих потока: распространение, создание новых страниц и обработка очереди запросов — каждый из них пропускался через Site Checker перед закрытием задачи. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология — общая практика Конечный клиент Evergreen Grace Dental Care (стоматологическая клиника в США) **Формат сотрудничества** **White-label продолжение обновления дизайна для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Продолжение обновления дизайна — распространение хедера/футера, 4 новые сервисные страницы из Figma, очередь запросов на изменения Объём работ **57 задач** — распространение дизайна (хедер/футер на 34 URL), 4 новые сервисные страницы (Clear Aligners · Veneers · Teeth Whitening · Endodontics), а также очередь запросов (исправления галереи, ссылки для записи, отступы, меню, логотип Instagram в футере) Сроки 73 дня (9 окт – 20 дек 2025), по графику агентства Трудозатраты **~23 ч на 57 задач — в среднем меньше часа на задачу** Команда 5 специалистов — ротация через разработку, QA и PM; без выделенного лида (характерно для продолжений) Шаблоны Страницы создавались в рамках существующей системы шаблонов агентства (34 URL проверено; добавлено 4 новые страницы) Технологический стек WordPress · Elementor · WP Engine · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) · AutoQA агентства (телефон · ссылки · контактный email · Content-AI · визуальная проверка OpenAI на 1920 / 1280 / мобильных) **Ритм работы** **57 задач — хедер / футер распространены на 34 URL, 4 новые сервисные страницы запущены из Figma, очередь запросов отработана; 78-пунктный QA-контрольный список перед закрытием каждой задачи** **Ритм взаимодействия** 11 задач, поставленных агентством · 9 из 11 закрыты к передаче **Раунды проверки** ≈5 раундов проверки за 73 календарных дня **Контрольный список запуска** 78 пунктов, согласованы перед переходом на рабочий сервер ## Постановка задачи К началу нашей работы агентство уже опубликовало обновлённую главную страницу для Evergreen Grace Dental Care. Бриф открывался именно этим фактом: _«Мы уже опубликовали обновлённую главную страницу… Но нужно проверить, распространились ли хедер и футер на остальные страницы»_. Дизайн главной был готов — наша задача была в том, что идёт после неё. Параллельно нужно было решить 3 задачи. Во-первых, новый хедер и футер должны были распространиться на оставшиеся 33 страницы: в карте сайта агентства числилось 34 URL, и только главная полностью получила обновление дизайна. Во-вторых, 4 новые сервисные страницы нужно было создать по утверждённым макетам в Figma и документам с контентом в Google Drive — Clear Aligners, Veneers, Teeth Whitening, Endodontics — с использованием существующего шаблона сервисной страницы агентства. В-третьих, очередь запросов на изменения уже начала формироваться: ошибки ссылок в галерее, дубликаты изображений, обновление ссылки для записи, корректировка отступов, расположение логотипа Instagram в футере, добавления в меню. Задача была не в единовременной передаче с датой запуска. Задача была в ритме: отрабатывать три параллельных потока без пересечений, проводить каждое изменение через QA перед закрытием задачи и сохранять систему шаблонов агентства в неприкосновенности. > **Контекст рисков — три рабочих потока, один рабочий источник дохода** Продолжение обновления дизайна операционно сложнее, чем чистое обновление дизайна, потому что распространение дизайна, создание новых страниц и очередь запросов идут одновременно, а не последовательно. Действующий сайт уже проиндексирован, уже конвертирует, уже принимает пациентов с первого дня — и продолжает это делать через все 57 последующих задач. При чистом обновлении дизайна есть единый момент смены дизайна; при продолжении каждая задача — это своя точка контроля. Хедер, который корректно распространился на 30 страниц, но нарушил вёрстку на 31-й, — это регрессия, которую агентство не может себе позволить. Ценность не в количестве задач. Она в том, чтобы провести три параллельных потока на действующем сайте и не допустить ни одной регрессии. ## Контроль качества Запись в Redmine содержит 41 подзадачу с суффиксом -qa — по одной на каждую рабочую задачу, формируемый перед возвратом задачи агентству — сгруппированных по шести последовательным счетам (#24–#29), чтобы сверка часов и задач проходила по каждому счёту отдельно, а не единожды в конце. QA перед закрытием задачи выполнялся через **Site Checker** — категории и принцип нулевого допуска по сбоям описаны в [нашей QA-методике](/site-checker/). QA-слой агентства запускался после передачи и вносил оставшиеся вопросы в общую очередь задач для нашего цикла исправлений вплоть до согласования каждой задачи. ## Как мы это сделали **1. Распространение хедера / футера на 34 URL карты сайта.** Вкладка Website Sitemap агентства содержала 34 URL с назначенными шаблонами (Homepage · Services Lander × 9 · Service Page × 23 · About Us). Обновление дизайна применили только к главной; мы проверили положение хедера и футера на каждом из оставшихся URL, раскатали обновлённый дизайн по всему сайту и зафиксировали для агентства страницы, потребовавшие ручного отклонения. Ограничение типично для продолжений: часть сайта уже трогал предыдущий разработчик, и граница между «изменённым» и «неизменённым» была не всегда чёткой — правило команды: не трогать ничего, о чём агентство не просило. **2. Четыре новые сервисные страницы по макетам Figma и документам с контентом.** Агентство предоставило утверждённые макеты Figma для каждой новой сервисной страницы и папку Google Drive с документами с контентом. Мы перенесли их в существующий шаблон сервисной страницы агентства — Clear Aligners, Veneers, Teeth Whitening, Endodontics — сохраняя каждую страницу в черновике до момента выхода агентства в меню. Мы выбрали путь шаблона, а не индивидуальных макетов, потому что сайт уже работал на 34 URL в рамках системы шаблонов агентства, и отклонение в структуре страниц нарушило бы визуальную целостность по всей карте сайта. В процессе создания выявилось ограничение: документы с контентом и макеты Figma охватывали вёрстку и текст, но не содержали изображений для новых сервисных страниц, а мета-описания отсутствовали на каждой черновой странице — и то и другое приходилось брать с исходного сайта и вставлять вручную перед тем, как страница могла выйти из статуса черновика. **3. Очередь запросов на изменения — параллельно с потоками дизайна и создания страниц.** Запросы поступали через Redmine, пока работа по распространению и новым страницам ещё шла: «Ссылка в галерее не работает (запрос на изменение)», «Дубликаты изображений (запрос на изменение)», «Логотип Instagram в футере», «Обновление ссылки для записи», «Слишком большие отступы». Каждую задачу прорабатывали, разрабатывали, прогоняли через внутренний QA в Site Checker, возвращали агентству и закрывали по его согласованию. Именно переплетение потоков отличает продолжение от чистого обновления дизайна — очередь не ждала завершения распространения дизайна или создания новых страниц. **4. Двухуровневый QA — Site Checker перед закрытием задачи + AutoQA агентства после передачи.** Каждая задача, независимо от потока, проходила через Site Checker перед закрытием: нулевой допуск по сбоям в базовых настройках, SEO-составляющей контента, структуре URL, очистке языка контента на страницах, публикациях, данных Elementor, меню и виджетах, а также скриншоты в нескольких разрешениях. AutoQA-слой агентства затем запускался после передачи — проверка телефонов · ссылок · контактного email · Content-AI · визуальная проверка OpenAI в трёх форматах экрана — и вносил оставшиеся вопросы в общую очередь задач SEO + CX для нашего цикла исправлений. 78-пунктный контрольный список запуска / QA отрабатывался по каждому пакету изменений перед принятием агентством. Четыре потока — распространение хедера/футера, новые сервисные страницы по спецификации, очередь запросов и QA каждой задачи — работают параллельно, потому что именно такова форма продолжения обновления дизайна. Дисциплина в том, чтобы не дать им пересечься. ## Результаты Метрика Итог Выполненные запросы на изменения **57 задач** закрыто за 73 дня Новые сервисные страницы **4** — Clear Aligners, Veneers, Teeth Whitening, Endodontics (созданы по Figma + документам агентства) Страниц, проверенных на распространение хедера/футера **34 URL** в карте сайта агентства Контрольная точка проверки Site Checker Перед закрытием каждой задачи, нулевой допуск по сбоям Покрытие AutoQA Проверка телефонов · ссылок · контактного email · Content-AI · визуальная проверка OpenAI в 3 форматах экрана (под управлением агентства) Контрольный список запуска / QA **78 пунктов** по разделам Development / Main и проверка после изменений Закрытые вкладки очереди задач 2 — очередь ошибок SEO + очередь ошибок CX, большинство позиций закрыты до передачи агентству Сроки **73 дня**, выполнено по графику агентства Трудозатраты **~23 ч** суммарно по 57 задачам — в среднем менее 25 минут на задачу **Статус сайта** Работает, открывается по адресу https://www.evergreengracedental.com/. Если коротко: дизайн распространён на 34 URL, четыре новые сервисные страницы запущены из утверждённых макетов Figma, 57 запросов на изменения проведены от постановки до закрытия — всё это по трём параллельным рабочим потокам за 73 календарных дня, каждая задача прошла индивидуально через Site Checker перед закрытием. ## Процесс Фаза Продолжительность Результат Первоначальный бриф + проработка объёма ~1 неделя Объём продолжения зафиксирован: пробел хедера/футера на 34 URL, 4 новые страницы из Figma, открытая очередь запросов Распространение дизайна ~2 недели Хедер и футер применены ко всем 34 URL; отклонения по страницам зафиксированы для агентства Пакет новых сервисных страниц ~3 недели Clear Aligners · Veneers · Teeth Whitening · Endodontics созданы в черновиках из Figma; согласована последовательность запуска Ритм обработки запросов ~6 недель (параллельно) Небольшие задачи проходили отбор и закрывались по одной; каждая — через QA Site Checker перед закрытием и подписание агентства после передачи Финальный проход перед запуском ~1 неделя Добавления в меню проверены на рабочем сайте; единообразие футера и галереи подтверждено по всему сайту _Фазы сильно пересекаются — очередь запросов была активна с первой недели, а задачи распространения дизайна продолжали поступать в период создания новых страниц. Такая параллельная форма характерна для продолжений, где три потока идут одновременно, а не последовательно._ ## Команда **Команда проекта** - **Никита Тумашевич** — разработка основных задач обновления дизайна - **Павел Сажин** — разработка + QA по запросам на изменения - **Тимур Арбаев** — разработка + QA по новым страницам и запросам на изменения - **Людмила Травкина** — связь со стороны агентства / клиентский куратор - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, согласование дизайна и коммуникация с конечным клиентом оставались за партнёрским агентством на протяжении всего проекта. Наша команда оставалась невидимой для конечного клиента. ## Агентствам, заказывающим обновление WordPress > Обновление сайта стоматологии — работа с визуальным референсом, где риск для вас не в качестве вёрстки, а в удержании объёма работ. У этой практики — гигиена и терапия с типовыми страницами; у других — ортодонтия и имплантация с динамическими калькуляторами. Риски тихие: мелкие правки выйдут за рамки рефреша, новая палитра не дойдёт до архивных страниц, границы задачи сотрутся для вашей команды. Подрядчику стоит задавать не вопрос «сможете ли сверстать макеты?», а вопрос «как именно вы удержите объём работ задачи, чтобы рефреш не перерос в перестройку архитектуры?» Пришлите таск-трекер или список правок, которые планируете. Мы пройдёмся по каждой задаче, выявим, где рефреш незаметно перейдёт в полноценную доработку, и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/agency-cta-system-q3-rollout/ title: Кросс-шаблонное развёртывание CTA — инициатива Q3 2025 type: case_study date: 2025-07-02T12:17:54+00:00 case_industry: Внутренние проекты агентств case_type: Другое case_practice: wordpress --- ## Подход к проекту 25 дней, 2 CTA-компонента — Slim Banner на каждой главной странице и Hero Buttons во всех Hero-секциях — развёрнуты на всей стоматологической библиотеке шаблонов агентства, пока собственный разработчик агентства обрабатывал тот же список с противоположного конца. Состав работ расширился в середине проекта: 10 дополнительных сайтов добавлены и выделены в трекере. Pop-up CTA был заморожен до начала работ, оставив 2 компонента с самого старта. 3 последовательных прохода QA закрывали каждый пакет, прежде чем он считался завершённым. Каждый сайт в этой библиотеке — вариация на тему. Какие-то примут новый функционал чисто. На других уже что-то стоит в этом слоте — старая версия компонента, локальная доработка, ограничение конкретного сайта, отмеченное только в комментарии к таблице. Дело здесь не в скорости. Нужно понять, где шаблон ложится единообразно, а где остановиться и эскалировать — не оставив ни спецификацию недописанной, ни отдельный сайт сломанным. Этот кейс описывает одно такое развёртывание — единую CTA-систему, развёрнутую на стоматологической библиотеке шаблонов маркетингового агентства из США в рамках квартальной продуктовой инициативы Q3 2025. ## Краткий обзор Поле Значение Конечный клиент Маркетинговое агентство из США, специализирующееся на сайтах для локального бизнеса — внутренняя продуктовая инициатива **Тип проекта** **Развёртывание функционала для одной из внутренних подкоманд агентства на всей стоматологической библиотеке шаблонов WordPress агентства** Тип проекта Кросс-шаблонное развёртывание функционала — CTA-система (Slim Banner · Hero Buttons) на всех сайтах библиотеки на Elementor Состав работ **Единое развёртывание CTA на всех сайтах библиотеки шаблонов агентства на Elementor** — Slim Banner над шапкой главной страницы + Hero Button CTA на всех страницах; текст и маршрутизация предоставлены агентством через таблицу; сайты не на Elementor задокументированы и пропущены Сроки **25 дней** (13 октября – 7 ноября 2025) — активная сборка 13 октября – 3 ноября; финальный QA и приёмка 7 ноября Трудозатраты **~26 ч всего** (25 ч реализации + 1,27 ч на 3 подзадачи QA) — учёт работ структурирован как 1 основная задача + 3 выделенных прохода QA Команда Людмила Травкина (ведущий разработчик), Павел Сажин (QA — два выделенных прохода), Антон Херсун (проход QA 3 + надзор за проектом) Технологический стек WordPress · Elementor Pro · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) · Google Sheets трекер CTA-текстов · Google Docs SOP + видеоинструкции **Результат** **CTA-система единообразно внедрена на всей библиотеке шаблонов агентства на Elementor; отклонения по сайтам задокументированы; 3 выделенных прохода QA завершены; инициатива Q3 Rock закрыта по графику** ## Постановка задачи Одна из внутренних подкоманд агентства — команда, отвечающая за поддержку и развитие стоматологической библиотеки шаблонов сайтов агентства — провела квартальную продуктовую инициативу в Q3 2025. Инициатива («Q3 Rock» в плановой лексике агентства — обозначение квартального приоритета, поставляемого отдельным блоком работ) предусматривала развёртывание единой CTA-системы на всех сайтах библиотеки на Elementor. Агентство передало спецификацию в двух артефактах: трекер Google Sheets с текстами CTA (надписи на кнопках, текст slim banner, целевые URL) для каждого сайта и Google Docs SOP с сопровождающими видеоинструкциями, записанными продуктовой командой агентства. Состав работ охватывал два CTA-компонента: Slim Banner, размещаемый над шапкой главной страницы (со ссылками, как правило, на страницы о страховании или аналогичные целевые страницы), и Hero Buttons, размещаемые во всех Hero-секциях страниц (со ссылками на системы бронирования или контактные страницы, в зависимости от практики). Третий компонент — Pop-up CTA — был включён в первоначальную спецификацию, но заморожен агентством до начала реализации, ограничив развёртывание двумя третями от изначально запланированной CTA-зоны. Целью внедрения были все сайты библиотеки на Elementor; сайты не на Elementor подлежали документированию и пропуску, без модификаций. Эта задача выходит за рамки модели работы «на одного клиента», по которой построена большая часть портфеля. Здесь нет 1 конечного клиента, нет рабочего URL для проверки после сдачи. Эта работа — поддержка инфраструктуры собственной библиотеки шаблонов агентства — тот тип инициативы, который поддерживает согласованность большого портфеля управляемых сайтов без необходимости запуска отдельных проектных задач под каждый сайт. > **Контекст рисков — единообразное развёртывание функционала на разошедшейся библиотеке шаблонов** Библиотека шаблонов, обслуживающая десятки живых клиентских сайтов на протяжении месяцев, накапливает дрейф. Каждое клиентское взаимодействие оставляет свои следы — индивидуально настроенную область шапки, slim banner, добавленный под конкретную кампанию с другим текстом, Hero-секцию, построенную вне стандартного шаблона Elementor. Развернуть новый CTA-компонент «на всех сайтах» в такой среде — не операция пакетной вставки. Это требует чтения состояния каждого сайта перед вмешательством, оценки применимости спецификации, передачи расхождений обратно агентству и единообразного применения только там, где состояние шаблона действительно это поддерживает. Риск, от которого агентство страхуется — не медленная поставка, а разработчик, который применяет спецификацию механически и либо ломает существующий CTA, либо создаёт видимое расхождение на сайте, которое увидит конечный клиент. Этот риск ортогонален рискам, характерным для индивидуальных ребилдов или доработок темы; он возникает из накопленного разнообразия поддерживаемой библиотеки, а не из сложности отдельного сайта. ## Контроль качества QA перед сдачей проходил через **Site Checker** — WordPress-плагин, который мы разработали и поддерживаем — по категориям, применимым к этой задаче: базовые настройки, контент и SEO-аспекты, структура URL, очистка контента и языка на страницах, записях, данных Elementor, меню и виджетах, а также снимки экранов на разных разрешениях. Порог нулевых ошибок перед сдачей; предупреждения рассмотрены и признаны неблокирующими. Собственный QA-слой агентства прошёл после передачи и зафиксировал замечания в очереди задач для нашего цикла исправлений до приёмки агентством. ## Как мы это сделали **1. Первичная обработка спецификации и настройка доступа.** Агентство предоставило трекер CTA-текстов в Google Sheets и Google Docs SOP с видеоинструкциями. Трекер перечислял сайты по доменам с требуемым текстом Slim Banner, надписями Hero Button и целевыми URL. Доступ к админке WordPress каждого сайта извлекался из хранилища учётных данных агентства. Сайты, к которым не удалось получить доступ немедленно, ставились в очередь на запрос учётных данных до начала работ — никакие модификации не выполнялись без подтверждённого доступа на руках. **2. По-сайтовое внедрение CTA с отслеживанием отклонений.** Разработчик обрабатывал трекер построчно, применяя Slim Banner к главной странице каждого сайта и Hero Buttons ко всем Hero-секциям. Если на сайте уже присутствовал Slim Banner — размещённый либо собственным разработчиком агентства, либо в рамках предыдущей кампании — расхождение фиксировалось в колонке комментариев трекера, а не затиралось молча. Такой подход — документирование отклонений вместо нормализации — был осознанным выбором: команда могла бы принудительно применить новый текст CTA единообразно, но это затёрло бы специфичные для конкретного сайта доработки, уже прошедшие проверку и одобрение клиентами агентства. Сохранение существующего CTA видимым в трекере оставляло за агентством редакционный контроль над тем, какие сайты получат обновлённый текст, а какие сохранят прежние сообщения. Принятые в агентстве соглашения по комментированию в трекере (галочки в колонке E для завершённых сайтов, примечания по проблемным сайтам) соблюдались на протяжении всей работы, чтобы разработчик агентства, обрабатывавший тот же пакет с противоположного конца списка, видел, какие именно сайты обработаны, а по каким остались открытые вопросы. **3. Обработка сайтов не на Elementor.** Часть сайтов библиотеки была построена не на Elementor. Согласно спецификации, они были задокументированы и пропущены — без модификаций. Примечания в трекере делали эти исключения видимыми для агентства без необходимости отдельного коммуникационного прохода. **4. Три выделенных прохода QA с итеративным закрытием пакетов.** Развёртывание не использовало единый проход QA в конце задачи. Вместо этого три отдельных задачи QA создавались в Redmine по мере продвижения работ пакетами — Павел Сажин выполнил два прохода (25 октября и 3 ноября) по мере завершения пакетов реализации; Антон Херсун выполнил третий проход (7 ноября). Эта поэтапная модель QA соответствовала пакетной структуре развёртывания: агентство добавляло сайты в трекер в середине проекта по мере завершения начального пакета, поэтому QA проводился по завершённым наборам, а не ждал завершения всего списка. Каждый проход действовал как порог нулевых ошибок перед тем, как сайты считались завершёнными. Напряжение в развёртывании на всю библиотеку — это перезапись: наложение нового текста поверх специфичной для конкретного сайта доработки без возможности отследить. Дисциплиной был сам трекер: каждое отклонение зафиксировано в колонке комментариев, галочки в колонке E — только на подтверждённо завершённых сайтах, никаких молчаливых перезаписей. Агентство видело, по каким именно сайтам остались открытые вопросы при проверке каждого пакета. ## Результаты Метрика Результат Развёрнутая CTA-система **Slim Banner (главная страница) + Hero Buttons (все страницы)** единообразно внедрены на всей стоматологической библиотеке шаблонов агентства на Elementor Сайты не на Elementor Задокументированы и переданы агентству — исключены согласно спецификации Обработка отклонений Расхождения по сайтам (существующие баннеры с отличающимся текстом) зафиксированы в трекере CTA; молчаливых перезаписей — ноль Завершённые проходы QA **3 выделенные подзадачи QA** — 2 от Павла Сажина, 1 от Антона Херсуна — поэтапно, по пакетам реализации Сроки 13 октября – 3 ноября 2025 (активная сборка); финальный QA принят 7 ноября 2025 Трудозатраты **~26 ч** — 25 ч реализации + 1,27 ч на 3 прохода QA Квартальная инициатива **Q3 2025 Rock закрыта** — CTA-система поставлена в рамках квартального продуктового цикла агентства Передача Без внешнего рабочего URL — внутренняя задача агентства; статус развёртывания задокументирован в трекере CTA-текстов агентства Если коротко: квартальная продуктовая инициатива агентства выполнена — единая CTA-система развёрнута на библиотеке шаблонов на Elementor, отклонения по сайтам зафиксированы открыто, исключения не на Elementor задокументированы, три поэтапных прохода QA подтвердили качество перед приёмкой каждого пакета. ## Процесс Этап Длительность Результат Обработка спецификации + настройка доступа 13–14 октября SOP, видеоинструкции и трекер CTA-текстов изучены; учётные данные сайтов получены; состав работ подтверждён Реализация пакета 1 ~1 неделя (14–22 октября) Начальный набор сайтов обработан; галочки и комментарии трекера актуализированы; вопросы эскалированы агентству Реализация пакета 2 (расширенный список) ~1 неделя (22–25 октября) Агентство добавило 10 дополнительных сайтов в середине проекта (выделены в трекере); второй пакет завершён Проход QA 1 (Павел Сажин, 25 октября) 0,97 ч Первый завершённый пакет проверен и принят Пакет 3 + завершение ~1 неделя (25 октября – 3 ноября) Оставшиеся сайты обработаны; неразрешённые комментарии трекера закрыты Проход QA 2 (Павел Сажин, 3 ноября) 0,1 ч Второй пакет проверен; статус установлен в «ожидание ответа» Проход QA 3 (Антон Херсун, 7 ноября) 0,2 ч Финальный проход; все позиции подтверждены; счёт выставлен _Агентство расширило список сайтов в середине проекта — добавляя пакеты по мере расчистки начального набора — что является характерной формой развёртывания на всю библиотеку: состав работ ограничен библиотекой, но точное количество выявляется инкрементально по мере аудита библиотеки._ ## Команда **Команда проекта** - **Людмила Травкина** — ведущий разработчик, внедрение CTA на всех сайтах на Elementor - **Павел Сажин** — QA, два выделенных прохода (проверки закрытия пакетов) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — проход QA 3, надзор за проектом, оценка, выставление счётов Управление проектом со стороны агентства, стратегия CTA-текстов и коммуникация с клиентами оставались за партнёрским агентством и его внутренней подкомандой на протяжении всего проекта. Конечные клиенты, на чьих сайтах было внедрено обновление CTA, не знали о передаче работ субподрядчику. ## Агентствам с продуктовыми задачами > Библиотека шаблонов для портфолио — это внутренний продукт: изменение в ядре должно прийти на все сайты, не сломав доработки. У вашей практики — десяток развёртываний с синхронизацией из единого источника; у других — каждый проект живёт своей веткой. Если не выстроено управление версиями, обновление токена разъедет дизайн на половине клиентов, хотфикс через дочернюю тему потеряется при синхронизации, а компоненты каталога разойдутся в несовместимые версии. Подрядчику стоит задавать не вопрос «соберёте ли компонент», а вопрос «как именно обновление в ядре доходит до каждого развёртывания, не затирая клиентские слои?» Пришлите рабочую таблицу проекта или макеты. Мы проверим архитектуру на расхождение между базовыми компонентами и клиентскими доработками, укажем места, где синхронизация разорвёт версию, и вернём фиксированную смету в часах. Аудит за счёт нашей стороны; обязательств после нет. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-day-spa-138h-103-days/ title: 47 URL, многофилиальный WordPress-сайт дневного спа за 103 дня type: case_study date: 2025-06-29T10:42:30+00:00 case_industry: Велнес case_type: Разработка case_practice: wordpress --- ## Подход к разработке Wellness-сайт на 47 URL для дневного спа с тремя филиалами в Орегоне — где конверсионным примитивом была не одна контактная форма, а схема бронирования 33 процедуры × 3 филиала со ссылками Square Appointments на каждую услугу. Агентство на тестовой среде заметило, что все кнопки «Book Now» вели на общий список услуг филиала, а не на конкретную процедуру — потребовалась перелинковка каждой процедуры, чтобы гость, листая меню услуг, попадал на правильный Square-виджет. ## Краткий обзор Поле Значение Индустрия конечного клиента Wellness — дневное спа (многофилиальный) Конечный клиент Radiant Day Spa (Bend · Sisters · Jacksonville, Oregon) **Формат сотрудничества** **White-label WordPress-сайт для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Однофазный WordPress-сайт на Kinsta с схемой бронирования Square Appointments для трёх филиалов в центральном Орегоне Объём **47 уникальных URL** по 49 строкам карты сайта — главная, лендинг меню услуг, 33 страницы процедур (каждая с пометкой о филиалах, где она доступна), 4 страницы филиалов, 3 страницы About по филиалам, 3 страницы Reviews по филиалам, блог-лендинг + блог, программа лояльности Многофилиальность Bend · Sisters · Jacksonville (Oregon); механизм маршрутизации: флаг доступности процедуры по филиалам (BD / SS / JV), всплывающий выбор для процедур в двух-трёх филиалах и прямой виджет для однофилиальных Срок 103 дня (5 сен – 17 дек 2025), сдано в срок Трудозатраты **138 часов** при оценке 138 часов — без перерасхода Команда 5 специалистов (45 ч разработка · 77 ч тестирование · 15 ч проектное управление · 1 ч поздние правки — высокая доля QA для новой разработки, оправданная длинным хвостом согласования многофилиальной логики, а не типовым дизайн-проходом) Шаблоны **9 применённых шаблонов** из 14-шаблонной библиотеки агентства — Homepage, Services Lander (лендинг меню услуг), Service Page, Location, About Us, Reviews, Blog Lander, Blog, Loyalty Program. Шаблон Doctor Page не применялся — на сайте дневного спа нет врачей. Технологии WordPress · Kinsta · Rank Math Pro · WP Rocket · Square Appointments (виджет бронирования, один на филиал) · Figma (дизайн-макеты) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **47 уникальных URL на 9 шаблонах, многофилиальная схема бронирования с виджетами Square Appointments по филиалам, 24 из 30 пунктов контрольного списка запуска согласовано, две QA-очереди задач (очередь ошибок DEV: 26/49 Completed; очередь ошибок CX: 19/51 Completed/closed) параллельно отработаны в длинном хвосте клиентской обратной связи** **Динамика взаимодействия** 49 задач от агентства · 46 из 49 закрыты к передаче (26 активных дней, 2025-10-11 – 2025-11-05) **Раунды проверки** ≈7 раундов за 103 календарных дня **Контрольный список запуска** 24 из 30 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США, нанятое Radiant Day Spa — Wellness-практикой с тремя филиалами в центральном Орегоне (Bend, Sisters и Jacksonville) — передало нам таблицу Google Sheets с картой сайта на 49 строк (47 уникальных URL), 14-шаблонную библиотеку в Figma, контрольный список запуска на 30 строк с колонками Development / Pre-Launch / Both, вкладку AutoQA Setup для проверки тестовой среды и две пустые вкладки очередей задач (DEV — для задач разработчиков, CX — для клиентского опыта). Сайт разворачивался в среде Kinsta агентства; SEO — Rank Math Pro; производительность — WP Rocket; а конверсионный примитив — то, ради чего посетитель заходит на сайт, — набор виджетов Square Appointments, по одному на филиал. Figma содержала дизайн главной и страниц процедур. Задача была однофазной разработкой с длинным хвостом согласования: построить все 47 URL в 9 шаблонах агентства; реализовать многофилиальную логику бронирования так, чтобы кнопка «Book Now» каждой процедуры вела на правильный виджет (прямая ссылка для услуг, доступных только в одном из Bend / Sisters / Jacksonville, и всплывающий выбор для услуг в 2-3 филиалах); затем, в течение нескольких недель на тестовой среде, параллельно отработать очереди задач DEV и CX и закрыть контрольный список запуска. Стратегия, тексты, меню услуг, голос бренда и коммуникация с клиентом оставались за агентством. Наша задача — исполнение: шаблоны, вёрстка страниц, логика бронирования, подход к QA, никакой импровизации в текстах или дизайне. > **Контекст рисков.** Сайт дневного спа зарабатывает на бронировании: гость листает меню процедур, выбирает филиал и попадает в календарь Square — без смены вкладки, неверного перехода и незагрузившегося попапа. Три филиала утраивают число точек входа, а доступность процедур по разным филиалам ещё умножает их. Риск, от которого агентство страховалось white-label-партнёром, был не в том, сможет ли кто-то собрать страницы на Kinsta, а в том, приведёт ли запись на уже запущенном сайте гостя из Sisters, нажавшего «Book Now» на процедуре в Sisters и Bend, к правильному виджету Square — без того, чтобы агентство или конечный клиент держали эту логику в голове. Главный риск разработки — непрерывность записи при работе по нескольким филиалам; бриф был составлен так, чтобы именно это стало основной задачей, а не примечанием на полях. Это была новая разработка «с нуля», без унаследованных URL и без миграции. Здесь нет «состояния до», которое можно сравнить, нет позиций в выдаче, которые нужно сохранить, нет карты редиректов. Есть таблица Google Sheets, которую составило агентство, есть тестовая среда, которую мы построили по ней, и есть сайт, выведенный в работу. ## Как мы это сделали **1. 9 шаблонов, 47 URL, один процесс.** URL Radiant Day Spa распределились по 9 из 14 стандартных шаблонов агентства: Homepage (1), Services Lander — лендинг меню услуг (1), Service Page (33 — самый объёмный, по одному на процедуру), Location (4), About Us (3 — по одному на филиал), Reviews (3 — по одному на филиал), Blog Lander (1), Blog (1), Loyalty Program (1). Каждый URL был построен на назначенном шаблоне по строке карты сайта; ничего не делалось вручную вне шаблонной системы. В библиотеке агентства есть также шаблон Doctor Page — уместный на медицинском сайте, но не на сайте дневного спа, где конверсионные страницы — это меню процедур, а не профили специалистов, — и мы его не применяли. **2. Согласованная смета как контракт.** Карту сайта (вкладка Sitemap) дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Сумма строк давала оценку разработки; проектная оценка в 138 часов включала её плюс бюджеты на QA, проектное управление и согласование после тестовой среды. И то, и другое сошлось с фактическими затратами. Дисциплина здесь простая: на разработке с предварительно оценённой картой сайта задача команды — уложиться в согласованную смету, а не переоткрывать ценообразование страницу за страницей. Мы выдержали цифры и сообщали о сюрпризах агентству, а не закрывали их за счёт следующей строки. **3. Многофилиальная схема бронирования.** Это была ключевая индивидуальная разработка в проекте. Каждая из 33 процедур содержала флаг доступности по филиалам — BD (Bend), SS (Sisters), JV (Jacksonville) или их комбинацию. Механизм «Book Now» работал по-разному: для услуги в одном филиале — прямая ссылка на Square-виджет этого филиала; для двух-трёх филиалов — всплывающий выбор с вариантом для каждого, и каждый вариант с собственным Square-кодом. Мы реализовали матрицу один раз по спецификации агентства, вывели её в шаблон Service Page через небольшой набор произвольных полей, привязанных к флагам BD/SS/JV, и затем отстаивали её через обе QA-очереди задач, пока агентство добавляло, удаляло и перемаркировало процедуры в длинном хвосте. Мы выбрали подход с произвольными полями, а не отдельные страницы для каждой процедуры по филиалам, потому что таблица Google Sheets содержала 33 процедуры с пересекающимися флагами — хранение каждой процедуры на одном URL с маршрутизацией в произвольных полях удержало количество шаблонов на уровне 9, а не умножило его на число филиалов, предлагающих каждую услугу. Виджет бронирования — Square Appointments — находится в строке «Технологии» раздела «Краткий обзор» не случайно: на Wellness-сайте это конверсионный примитив, как Gravity Forms на медицинском сайте. **4. Два параллельных QA-цикла через длинный хвост обратной связи на тестовой среде.** Задачи отслеживались в двух очередях задач агентства: очередь задач разработки (вкладка «Ошибки DEV») — для задач, влияющих на разработку (регрессии вёрстки, битые ссылки, отсутствующие строки контента, замены изображений, пограничные случаи схемы бронирования по мере их выявления). Очередь задач CX (вкладка «Ошибки CX») — для задач на стороне аккаунта агентства (правки текстов, запросы на замену изображений, коррекция голоса бренда, контентные запросы по филиалам, направляемые конечному клиенту). Из 49 DEV-задач 26 закрыты как Completed; 10 в QA (ожидают подтверждения агентства или конечного клиента), 9 To Do, 3 In Progress, 1 зависла на Info Needed к моменту передачи. Из 51 CX-задачи 19 закрыты как Completed (ещё 1 отмечена как закрытая); 15 в QA, 3 To Do, 1 In Progress, 13 на Info Needed в ожидании решений агентства или конечного клиента. Контрольный список запуска на 30 строк — Development / Pre-Launch / Both — закрыт на 24 согласованных пунктах за обеими очередями, а оставшиеся 6 пунктов сами зависели от тех же ожиданий Info Needed. Задача #1222 — «Логика Book Now» — стоила 14 часов при оценке 4 часа, перерасход в 3,5 раза, который показывает, где на самом деле была нагрузка проекта. Согласование схемы бронирования, а не вёрстка страниц, потребовало основного времени; две параллельные QA-очереди, шедшие рядом 103 дня, держали все остальные правки на виду, а не прятали их в тихую очередь. ## Результаты Метрика Результат Разработано URL **47 уникальных URL** на 9 шаблонах (1 Homepage · 1 Services Lander · 33 Service Page · 4 Location · 3 About Us · 3 Reviews · 1 Blog Lander · 1 Blog · 1 Loyalty Program) Применено шаблонов **9 / 14** из стандартной библиотеки агентства для локального бизнеса — только те, которые реально потребовались по карте сайта; шаблон Doctor Page обоснованно отсутствует на сайте дневного спа Многофилиальная схема бронирования 33 процедуры × 3 филиала (BD / SS / JV) с виджетами Square Appointments по филиалам, всплывающим выбором для двух- и трёхфилиальных процедур и прямым виджетом для однофилиальных Очередь задач DEV (вкладка «Ошибки DEV») **26 / 49** закрыты как Completed; 10 в QA, 9 To Do, 3 In Progress, 1 Info Needed Очередь задач CX (вкладка «Ошибки CX») **19 / 51** закрыты как Completed/closed; 15 в QA, 3 To Do, 1 In Progress, 13 Info Needed (в ожидании решений агентства или конечного клиента) Контрольный список запуска **24 из 30** пунктов согласовано по колонкам Development / Pre-Launch / Both; оставшиеся шесть привязаны к тем же ожиданиям статуса «Info Needed» во вкладке CX Срок **103 дня** (5 сен – 17 дек 2025), сдано в срок Трудозатраты **138 ч / 138 ч оценка** — без перерасхода, без расширения объёма **Статус сайта** Работает на Kinsta, открывается по адресу https://www.everberadiant.com/ — проверено в апреле 2026. Результат, если коротко: 47-URL многофилиальный сайт дневного спа для агентства сдан на 9 шаблонах на Kinsta в рамках бюджета 138 часов. Две QA-очереди задач работали параллельно через длинный хвост согласования; 45 из 100 заведённых задач закрыты как Completed до окончания нашей работы, остальные разделены между текущим QA и ожиданиями статуса «Info Needed» решений агентства или конечного клиента. Контрольный список запуска закрыт на 24 из 30 согласованных пунктов; сайт выведен в работу в конце 103-дневного окна. ## Контроль качества Перед первой проверкой агентства на исходной сборке был запущен Site Checker — QA показал открытые замечания («надо чекера и исправить косяки», чат #963, 2025-09-23) — а проход агентства после передачи затем выявил #1222, показавшую, что все кнопки «Book Now» в матрице из 33 процедур вели на общий список услуг филиала в Square, а не на URL конкретной процедуры. QA перед сдачей прошёл через **Site Checker** — см. [наш подход к QA](/site-checker/) с категориями и порогом нулевых ошибок. Собственный QA агентства работал после передачи и добавлял задачи в общую очередь задач для нашего цикла исправлений до согласования. ## Процесс Фаза Длительность Результат Бриф и оценка ~1 неделя Таблица Google Sheets проанализирована, построчные часы подтверждены по вкладке Sitemap (49 строк), оценка 138 ч согласована Фаза разработки (URL + шаблоны) ~5 недель Все 47 URL построены на 9 шаблонах в тестовой среде на Kinsta; первые DEV-задачи открыты по тестовой среде Многофилиальная схема бронирования ~2 недели (параллельно) Матрица 33 процедуры × 3 филиала реализована через виджеты Square Appointments по филиалам плюс всплывающий выбор; защищалась через правки во вкладке CX Хвост согласования (DEV + CX QA) ~6 недель Обе очереди задач отработаны параллельно; приоритетные CX-задачи (замена изображений, правки текстов, регрессии мобильной вёрстки, пограничные случаи схемы бронирования) закрыты в первую очередь Контрольный список запуска + сдача последняя ~1 неделя Контрольный список на 30 строк согласован на 24 пунктах; переключение; сайт в работе: `https://www.everberadiant.com/` _Фазы значительно перекрываются — работа над схемой бронирования началась до завершения первого прохода по всем Service Page, а хвост согласования DEV/CX шёл параллельно с ними, поэтому 103 календарных дня существенно меньше суммы длительностей отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик в фазе сборки и реализации многофилиальной схемы бронирования - **Павел Сажин** — QA-итерации и правки в обеих очередях задач DEV и CX - **Тимур Арбаев** — поддержка QA, основная ответственность за длинный хвост согласования (крупнейший QA-вклад в проекте) - **Людмила Травкина** — QA-проход и координация до сдачи проверки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Проектное управление со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. Тексты меню услуг, голос бренда, расположение филиалов и продуктовые решения по потоку бронирования — за агентством; реализация этих решений в многофилиальном WordPress-сайте — за нами. ## Агентствам, заказывающим разработку WordPress > На сайте дневного спа меню процедур держит на себе URL-архитектуру, навигацию и разметку, от которой зависят локальные позиции. У этой практики — одна локация со стандартным меню процедур; у других — сети филиалов с пакетами по локациям и сезонными предложениями. Риски тихие: новая процедура, добавленная в середине года, не ляжет в существующий URL-шаблон; фильтруемые страницы перестают получать поисковый трафик после переноса контента; разметку срезает при импорте — и расширенные результаты пропадают из ежемесячного аудита агентства. Спросите подрядчика не «соберёте ли страницы процедур?», а «как именно вы выстроите иерархию услуг, чтобы следующая категория встала без поломки существующих URL?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы примерим таксономию к вашему списку процедур, отметим, где структура заставит всё пересобирать при добавлении новых услуг, и вернём фиксированную смету в часах. Бесплатно, со сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-oral-surgery-26h-63-days/ title: Доработка 35-страничного шаблона для хирургической стоматологии за 63 дня type: case_study date: 2025-06-24T23:25:05+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы Главная страница — по макету Figma, все остальные 34 страницы шаблонов с приведением цветовой гаммы. И затем — передача контент-команде. Бриф агентства для Greenwich Oral & Maxillofacial Surgery разделил работу на 2 явных уровня: 1 страница строится строго по монохромному дизайну Figma (#000000 и #ffffff, текстуры удалены из базовой dental-template10), остальные страницы 35-страничного сайта — с приведением цветовой гаммы и структурно готовы, чтобы контент-команда могла наполнять URL, не дожидаясь нас. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — хирургическая стоматология Конечный клиент Greenwich Oral & Maxillofacial Surgery (Greenwich, CT) **Формат сотрудничества** **White-label доработка темы WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы на Elementor на Kinsta — главная по макету Figma, все страницы шаблонов с приведением цветовой гаммы и наполнены Объём **35 URL** — главная (по Figma), 14 страниц услуг, 7 страниц врачей, 2 страницы контактов / направлений, 1 лендинг услуг, 1 «О нас», 1 «Страховка», 1 «Политика конфиденциальности», 1 «Технологии», а также вспомогательные страницы шаблона по умолчанию Сроки 63 дня (28 окт 2025 – 16 янв 2026), выполнено в рамках основной доработки и раундов исправлений после запуска Затраты **~26 часов** — основная доработка (12,5 ч) и итерации исправлений после запуска (~13,5 ч по учётным подзадачам) Команда 4 специалиста (ведущий разработчик · ведущий QA · разработчик поддержки · руководитель проекта) Шаблоны **9 переиспользуемых шаблонов** — библиотека dental-template10 агентства, применённая к таксономии услуг хирургической стоматологии Техстек WordPress · Elementor · Kinsta · Figma (источник дизайна главной) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **35 страниц доработаны и наполнены, контрольный список из 78 пунктов закрыт, 471 отслеженная проблема в очередях задач SEO + CX, раунды исправлений после запуска завершены** **Ритм согласования** 3 задачи от агентства · 1 из 3 закрыта к моменту передачи **Раунды проверки** ≈5 раундов проверки за 63 календарных дня **Контрольный список запуска** 78 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Greenwich Oral & Maxillofacial Surgery — группой челюстно-лицевой хирургии с одним офисом в Greenwich, CT — открыло нам доступ к своей системе dental-template10 на Kinsta и передало файл дизайна Figma для главной страницы. Среда разработки — собственный тестовый домен агентства на Kinsta; конструктор страниц — чистый Elementor, без ACF: все страницы услуг и врачей собраны напрямую в блочном редакторе. Задача делилась на 2 части. Первая: собрать главную строго по макету Figma — монохромная цветовая схема (чёрный и белый с акцентами бренда клиники), липкий хедер, анимации при наведении. Вторая: перенести брендовые цвета и типографику из Figma на все существующие страницы шаблонов — услуги, врачи, контакты, направления — и заполнить каждую заглушками или актуальным контентом клиники там, где он был доступен. После нашей сдачи наполнение URL переходило к контент-команде. Такое разделение — главная по Figma плюс цветовой проход по библиотеке шаблонов, контент потом — было сознательным решением по очерёдности работ: оно ограничивало фазу доработки и давало контент-команде возможность работать со страницами самостоятельно, как только структурная и визуальная основа встала на место. > **Контекст рисков.** Риск агентства при доработке шаблона — в их общей системе: изменение общих компонентов шаблона вместо переопределений на уровне клиента тихо расходится по всем остальным сайтам на том же шаблоне. Монохромный дизайн Greenwich — палитра, резко выбивавшаяся из тёплых тонов dental-template10 по умолчанию, — делала этот риск вполне осязаемым. Цветовой проход должен был оставаться в клиентских переопределениях, а каждую текстуру или фоновое изображение из базового шаблона — убрать и заменить тёмно-серыми изображениями клиники. Доработка без расползания правок по общему слою — вот за что мы отвечаем. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Figma агентства для главной определяла каждое структурное решение: раскладка hero-секции, порядок блоков, монохромная цветовая схема, типографика. Мы не принимали дизайн-решений от себя и не подставляли элементы агентства по умолчанию. Там, где Figma молчала — например, зазор липкого хедера над hero, — неоднозначность снималась в прямом чате с ведущим QA, решение документировалось до продолжения работы. Система dental-template10 была холстом. Перед Figma-проходом мы восстановили главную из базового dental-template10: предыдущий контент клиента был вставлен напрямую в тестовую среду и повредил структуру шаблона. Чистая основа дала возможность воплощать макет системно, а не латать по ходу. **2. Проход по цветам и типографике по всем страницам шаблонов.** Инструкция агентства была чёткой: нанести палитру бренда на все страницы шаблонов и открыть их на сайте, чтобы контент-команда могла начинать заполнять URL. Базовые текстуры dental-template10 противоречили монохромному направлению Greenwich — мы убрали их и заменили тёмно-серым hero-изображением с главной там, где нужны были декоративные фоны. Типографику привели к Figma на всех типах страниц. **3. Таксономия услуг хирургической стоматологии, корректно спроектированная.** Структура услуг клиники отражает специфику челюстно-лицевой хирургии: зубные импланты (включая full-arch варианты), операции в полости рта, ортогнатическая хирургия и лечение ВНЧС, неотложные состояния, оральная патология и направления для врачей. Четыре изменения URL и 19 редиректов в карте сайта агентства — перемещение устаревших коротких URL типа `/wisdom-teeth/` во вложенные пути типа `/oral-maxillofacial-surgery/wisdom-tooth-removal/` — согласовали с картой сайта до передачи. Раздел страниц врачей охватывал четырёх активных хирургов плюс статус Partner Emeritus для уходящего на пенсию хирурга, все страницы наполнены публично доступной биографической информацией клиники. **4. Цикл QA в масштабе доработки шаблона.** Система AutoQA агентства с двойной очередью задач отслеживала 471 проблему: SEO-очередь (234 строки) и CX-очередь (235 строк). После сдачи серия адресных раундов исправлений закрыла проблемы вёрстки, добавление контактной формы и замену иконок — по запросам команды проверки агентства. Каждый раунд назначали, прогоняли через QA и закрывали прежде, чем открыть следующий. Контрольный список запуска из 78 пунктов закрыли до финальной передачи рабочего сайта контент-команде. Среди того, что вскрыли постсдаточные раунды, — остатки шаблона, мимо которых прошёл первый цветовой проход: ссылка в футере с заглушкой предыдущего клиента и элементы общих шаблонов, потребовавшие клиентских переопределений сверх палитры Figma. Шаблон был повреждён контентом предыдущего клиента, вставленным напрямую в тестовую среду. Восстановление из базового dental-template10 стало предусловием для системной реализации Figma — без него пришлось бы латать на ходу. Как только чистая основа встала, монохромная палитра, замена текстур и структура URL ложились без конфликтов. ## Результаты Метрика Результат Доработано страниц **35** на 9 шаблонах (1 главная · 14 страниц услуг · 7 страниц врачей · 2 контакта / направления · 1 лендинг услуг · 1 «О нас» · 1 «Страховка» · 1 «Политика конфиденциальности» · 1 «Технологии» + страницы шаблона по умолчанию) Применено шаблонов **9 / 9** из библиотеки dental-template10 агентства Изменения структуры URL **4 изменения URL + 19 редиректов** согласованы с картой сайта до передачи Очередь задач SEO **235 строк** в очереди задач SEO агентства Очередь задач CX **236 строк** в очереди задач CX агентства Контрольный список запуска **78 пунктов** согласованы Сроки **63 дня** (основная доработка + итерации после запуска), сдано после согласования с агентством Затраты **~26 часов** — основная доработка и раунды исправлений после запуска **Статус сайта** Работает на Kinsta, открывается по адресу https://www.greenwichoralsurgery.com/ — проверено в апреле 2026. Если коротко: агентство получило 35-страничный сайт хирургической стоматологии — главная по макету Figma, все страницы шаблонов с приведённой цветовой гаммой и очищенные от текстур под бренд клиники, страницы врачей и услуг наполнены, готово для контент-команды без зависших структурных исправлений. ## Контроль качества QA до передачи поймал текстуры базового шаблона, проступавшие сквозь оформление: в dental-template10 по умолчанию стояли бежевые фоновые текстуры, конфликтовавшие с монохромным брифом. Каждую убрали и, где требовался декоративный фон, заменили тёмно-серым hero-изображением — по заметке QA (чат #1353, Тимур, 2025-11-04). QA до передачи проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) — по категориям и с принципом нулевых ошибок. Контроль на стороне агентства работал после передачи и фиксировал замечания в очередь задач для нашего цикла исправлений до окончательного согласования. Все доработки остались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не были изменены. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Объём работ определён: Figma-главная + проход по цветам по шаблонам; оценка 12,5 ч согласована Главная страница (Figma) ~4 дня Главная построена по макету Figma; липкий хедер, монохромная палитра, анимации при наведении Проход по цветам и типографике шаблонов ~3 дня (параллельно) Все страницы шаблонов с приведением цветов; текстуры удалены; страницы врачей и услуг наполнены Внутренний QA и проверка в тестовой среде ~2 дня Павел Сажин — первый проход QA; Тимур Арбаев — второй проход QA; исправления внесены Передача тестовой среды + QA агентства ~7 дней Сайт передан агентству; открыт цикл AutoQA и ручной проверки Раунды исправлений после запуска (3 цикла) ~6 недель Вёрстка, добавление формы, замена иконок — каждый в отдельном направлении с закрытием по QA Финальное исправление + подпись янв 2026 Обновление био врача, финальное исправление вёрстки; согласование агентством _QA и разработка шли параллельно — очередь задач агентства после передачи открылась, пока запросы на исправления после запуска всё ещё прорабатывались, поэтому календарный охват составил 63 дня, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик, реализация Figma и проход по цветам по шаблонам - **Тимур Арбаев** — ведущий QA и разработчик поддержки на этапах QA и исправлений - **Павел Сажин** — разработчик поддержки и QA, первичный обзор шаблонов - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Проектное управление со стороны агентства и коммуникация с клиентом оставались на партнёрском агентстве на всём протяжении. Конечный клиент нас не видел. ## Агентствам с библиотекой шаблонов > Сборка на готовом шаблоне для хирургической стоматологии несёт скрытый риск: доработки, которые вы внесёте под протоколы клиента, могут сломаться при первом обновлении темы. У этой практики — многоэтапные протоколы имплантации и несколько редакторов; у других — плоские услуги без подкатегорий. Если шаблон не адаптировать, вы обнаружите, что навигация по услугам перестанет работать, поля ACF для этапов операции пропадут из редактора, а фирменная цветовая схема не применится к архивным страницам. Поэтому подрядчику стоит задавать не вопрос «соберёте ли сайт на этом шаблоне?», а вопрос «как именно вы изолируете доработки от обновлений родительской темы?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы проверим, где дочерняя тема уязвима для апдейтов, и укажем, какие редакторские блоки сломаются при следующем обновлении. Вернём фиксированную смету в часах. Бесплатно, без обязательств с любой стороны. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-61-pages-29-days/ title: Ребилд сайта стоматологии на WordPress: 61 страница за 29 дней type: case_study date: 2025-06-22T03:29:38+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 61 URL стоматологической клиники, свёрнутые в 8 шаблонов Elementor Pro по спецификации из восьми вкладок Google Sheets — карта сайта, назначение шаблонов, резервная копия мета-данных, контрольный список запуска. За агентством — стратегия и карта URL; за нами — постраничное исполнение и проверка миграции, за 29 дней и 69 часов. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина (Стоматология) Конечный клиент Naylor Family Dental (Dr. Naylor DDS, Las Vegas, NV) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress с Elementor Pro на WP Engine Объём 61 URL мигрированы в 8 переиспользуемых шаблонов, включая иерархию услуг, ресурсы для пациентов и архив блога Сроки 29 дней (19 июня – 17 июля 2025) Затраты 69 часов — без расширения объёма относительно исходного ТЗ Команда 4 специалиста (38 ч разработка · 15 ч PM · 10 ч QA · 6 ч исправления) Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Разница контента оригинал-ребилд устранена до передачи — ни одного пропущенного текста, ни одной битой внутренней ссылки, ни одного структурного расхождения **Сдано** **ТЗ соблюдено строка за строкой — 56 редиректов, 52 записи мета-данных сверены, 8 шаблонов, 30 пунктов контрольного списка запуска** Продолжение работы 4 дополнительных раунда доработок в течение следующих 6 недель — проверка очереди задач, скрытие страниц, реализация SEO-задач, финальная проверка — каждый поставлен дополнительными спринтами в рамках тех же отношений с агентством **Ритм взаимодействия** 85 задач от агентства · все закрыты к моменту передачи **Раунды проверки** ≈5 раундов проверки **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи Naylor Family Dental владел существующим сайтом на WordPress с глубокой иерархией услуг — косметическая стоматология, семейная стоматология, хирургия полости рта, зубные импланты, восстановительная стоматология — каждый раздел с лендингами-родителями и дочерними страницами услуг. Агентство уже подготовило полную карту миграции URL, спроектировало систему шаблонов и провело аудит мета-данных. Наша задача — выполнить ребилд сайта на WP Engine, шаблон за шаблоном и URL за URL, без визуального расхождения и нарушения архитектуры услуг. Полученное ТЗ — это таблица Google Sheets с восемью вкладками: полная карта сайта с текущими и целевыми URL, назначения шаблонов, резервная копия мета-данных, карта AI-контента, справочник настроек, разделённая очередь задач (SEO и CX) и контрольный список запуска на 30 пунктов. От нас требовалось не выходить на прямой контакт с клиентом, реализовать каждое SEO-решение как написано и сдать в рамках согласованных часов. Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на протяжении всего переключения и миграции. Агентство страховалось не от провала SEO — с этим они справлялись сами. Опасность была в подрядчике, который тихо начнёт импровизировать по ходу ТЗ: применит не тот шаблон на странице услуги, пропустит редирект в посте блога, переиначит отступы на виджете. На сайте с 8 шаблонами и 61 URL одно мелкое отклонение расходится быстро. > **Контекст рисков.** План миграции агентства перестраивал всё пространство имён услуг Naylor: 34 страницы перемещались из плоской таксономии `/services/` в 5 категориальных иерархий (`/cosmetic-dentistry/`, `/family-dentistry/`, `/dental-implants-center/`, `/oral-surgery/`, `/restorative-dentistry/`), каждая со своей цепочкой редиректов — то есть 1 страница услуги, ошибочно отнесённая в неверную категорию, одновременно ломала и редирект, и новую архитектуру URL. Риск — расхождение шаблонов: один неверно назначенный шаблон распространяется на каждую страницу услуги, каждый пост блога, каждый лендинг. На стоматологическом сайте с виджетами для пациентов и многоуровневой иерархией услуг это расхождение видно посетителю раньше, чем аналитике. Агентство наняло нас, потому что ребилд должен был быть поточечно точным, а не просто функциональным. ## Как мы это сделали **1. Сборка на основе шаблонов.** Вместо того чтобы перестраивать 61 страницу по одной, мы свели их к 8 переиспользуемым шаблонам и разместили каждую страницу в соответствующем: - **Homepage** — hero, обзор услуг и сигналы доверия - **Services Lander** — введение в категорию-родитель с навигацией по дочерним страницам - **Service Page** — детальное описание услуги со структурированными блоками контента - **About Us** — история клиники и представление команды - **Contact Us** — расположение, форма и интеграция записи - **Blog Lander** — архив статей с фильтрацией по категориям - **Blog** — шаблон отдельного поста с мета-информацией об авторе и дате - **Default Template** — общие страницы (политика конфиденциальности, ресурсы для пациентов) - **Smile Gallery** — визуальная презентация кейсов «до/после» 8 шаблонов — и весь сайт построен. Будущие правки со стороны агентства живут в одном месте на тип страницы. **2. ТЗ соблюдено строка за строкой, по таблице агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции с целевым путём, каждый мета-заголовок и описание для переноса, каждое назначение шаблона, каждая интеграция под клиента (скрипт CallRail, reCAPTCHA на формах, ссылки на соцсети, проверка фавикона). Мы реализовали каждую строку как написано. Где в таблице было значение — это значение попало на новый сайт. Где его не было — мы отметили это для агентства. Никаких «творческих интерпретаций» мы не сдавали. В таблице Google Sheets также были перечислены несколько страниц с назначенными шаблонами и целевыми URL, но без предоставленного клиентом контента — очередь задач пометила их как пробелы со стороны контента (закреплено за контент-командой агентства, а не за нашим объёмом разработки). Мы вернули их агентству, а не стали писать текст-заполнитель: это легло бы редакционным грузом за рамками контракта, где наша зона — точность по ТЗ. Коротко: на ребилде ТЗ — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль — точность исполнения предоставленного ТЗ. **3. Проверка на основе обхода, а не «на глаз выглядит нормально».** Перед переключением DNS мы параллельно прогнали Screaming Frog на действующем сайте и в тестовой среде ребилда. Коды статуса, битые ссылки, цепочки редиректов, различия в мета-тегах — каждое расхождение сверено с ТЗ агентства. Второй обход после запуска подтвердил, что каждая внутренняя ссылка корректно разрешается на действующем домене. **4. Контрольный список запуска на 30 пунктов, закрыт до передачи.** Семь категорий: дизайн, функциональность, контент, SEO и аналитика, адаптивность, интеграции под клиента и 7-шаговая миграция домена и DNS на WP Engine. Ничего не сдавали, пока не согласовали каждую строку. QA на разных устройствах на Chrome / Firefox / Safari / Edge и шести разрешениях экрана (1920 / 1280 / 1024 / iPad / портретная / альбомная ориентация на мобильных). Плоская таксономия `/services/`, уходящая в пять категориальных иерархий — `/cosmetic-dentistry/`, `/family-dentistry/`, `/dental-implants-center/`, `/oral-surgery/`, `/restorative-dentistry/` — это узел, который сборка должна была развязать в первую очередь. Каждому родителю — своя цепочка редиректов; дочерние страницы нужно было разложить по верным иерархиям прежде, чем запускать любую визуальную проверку. ## Результаты Метрика Результат Точность по ТЗ — редиректы **56 / 61** контентных URL перенаправлены, как указано Точность по ТЗ — мета-данные **52 / 52** записи мета-данных сверены с обходом исходного сайта — отсутствующие страницы или 404 отмечены для агентства Точность по ТЗ — шаблоны **8 / 8** шаблонов построены и применены на всём сайте Контрольный список запуска **30 / 30** пунктов согласованы до переключения Сроки **29 дней**, основной объём завершён Затраты **69 ч** — без расширения объёма относительно исходного ТЗ Проверка адаптивности Ноль проблем с вёрсткой на 4 браузерах × 6 разрешений экрана Внутреннее QA Все задачи в рамках объёма агентства закрыты до передачи (85 из 85 отмечены; 0 осталось) Статус сайта Опубликован на WP Engine: [naylorfamilydental.com](https://www.naylorfamilydental.com/) Продолжение работы 4 дополнительных раунда доработок в течение следующих 6 недель — проверка очереди задач, скрытие страниц, реализация SEO-задач, финальная проверка — каждый поставлен дополнительными спринтами в рамках тех же отношений с агентством Если коротко: ТЗ агентства было реализовано как написано, в рамках согласованных часов, со всеми задачами в рамках объёма агентства закрытыми. 9 месяцев спустя сайт по-прежнему работает. ## Контроль качества Предварительное QA запустило параллельную сверку контента — исходный сайт и тестовая среда ребилда — и выявило битую внутреннюю ссылку на `/dental-implants-center/implant-preparation/`, вызванную пропущенным слешем в href; тот же проход отметил страницы с уведомлением-заглушкой («На этой странице отсутствует основной контент»), которые были переведены в черновик до переключения. Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Собственный QA-контур агентства запускался после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день ТЗ агентства проанализировано; оценка 69 ч согласована Разработка ~20 дней Весь сайт перестроен по 8 шаблонам Внутреннее QA и проверка ~6 дней 85 задач зафиксировано; все в рамках объёма агентства закрыты Проверка по ТЗ 1 день Соответствие мета-тегов и редиректов сверено с таблицей Сдача и переключение DNS 1 день Сайт работает на WP Engine, без простоя _Фазы перекрываются (QA шло параллельно с поздней разработкой), поэтому календарная длительность — 29 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Павел Сажин** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Никита Тумашевич** — разработчик (координация команды на этом проекте) - **Наталия Богатель** — исправления по QA и реализация мета-данных - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Проектное управление и SEO-стратегия со стороны агентства оставались за партнёрским агентством на протяжении всего проекта. Конечный клиент нас не видел. ## Агентствам, заказывающим ребилд WordPress > Когда ребилд перекраивает структуру услуг, самый высокий риск несут карта редиректов и архитектура шаблонов. Здесь это была клиника одной локации; у вас может быть многофилиальная сеть, сводящая каталоги услуг под один бренд. Пропущенная строка редиректа отправляет высокоранжируемую страницу услуги в 404. Сбитый шаблон молча перезатирает мета-заголовки и описания, которые вы отслеживали, — и сниппеты в выдаче меняются за ночь. Структурированная разметка, потерянная при импорте, роняет расширенные результаты из вашей панели аудита. Спрашивать партнёра стоит не «сможете мигрировать?», а «как вы защитите карту редиректов и удержите единство шаблонов?» Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим карту редиректов с вашим текущим перечнем URL, разберём архитектуру шаблонов и работу с мета-данными и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-53-page-dental-138-days/ title: Доработка стоматологического шаблона на 53 страницы за 138 дней type: case_study date: 2025-06-17T11:35:18+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 53 страницы стоматологического шаблона — 43 экземпляра страницы услуг по шести категориям процедур на хостинге Kinsta по спецификации Figma. Два нестандартных шрифта, Avenir LT Pro и Stolzl, пришлось приобретать через Adobe Typekit до начала разработки. Более 550 отслеживаемых пунктов в очереди задач агентства задавали направление каждому QA-проходу; главным было удержать каждое изменение в слое клиентских переопределений — отдельно от общей базы шаблона. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая работает в отрыве от Figma или считает очередь задач шумом, а не сигналом, оставляет агентству QA-долг — и разбираться с ним теперь агентству. ## Краткий обзор Поле Значение Индустрия конечного клиента Стоматология — общая, косметическая и имплантология Конечный клиент A1 Dental (Dr. Mila Poznyak, Cumming, GA) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **53 URL** — главная, биография врача, о нас, лендинг услуг, лендинг зон обслуживания, лендинг блога, контакты, страховка и финансирование, 3 юридические страницы, и **43 страницы услуг** по разделам косметической, неотложной, семейной, профилактической, восстановительной стоматологии, седации и TMJ Сроки 138 дней (4 авг – 20 дек 2025), в срок Трудозатраты 61 час — разработка, QA-итерации, внедрение редиректов и управление проектом Команда 5 специалистов Шаблоны **10 переиспользуемых шаблонов**, предоставленных агентством, применённых на 53 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · пользовательские шрифты (Avenir LT Pro, Stolzl) · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **550+ отслеживаемых пунктов SEO + CX**, согласованных в очереди задач агентства по 75-пунктному контрольному списку запуска **Ритм работы** 169 задач от агентства — все закрыты к моменту сдачи (активный период 339 дней, 2024-11-24 – 2025-10-28) **Раунды проверки** ≈10 раундов проверки за 138 календарных дней **Контрольный список запуска** 75 пунктов, согласован до переключения ## Постановка задачи Агентство из США передало нам дизайн Figma для A1 Dental и доступ к своей брендированной системе шаблонов на Kinsta. Подготовительная работа уже была сделана: аудит дизайна, одобрение клиента, настройка хостинга, контент-план через Google Docs для каждой страницы. Наша роль — взять шаблон агентства, рабочую систему, которая обслуживает несколько стоматологических практик, и точно привести его к Figma: страница за страницей, точка адаптации за точкой адаптации. Практика — небольшой частный стоматологический кабинет в Cumming, GA, с широким спектром услуг: косметика (Invisalign, виниры), имплантологическая реставрация, профилактика и семейная стоматология, а также новые методики — лечение кариеса Curodont без сверления и пьезохирургия. 53-страничный объём отражает эту широту: агентство выстроило таксономию услуг с шестью основными категориями (косметическая, неотложная, семейная, профилактическая, восстановительная стоматология, седация и TMJ) и наполнило каждую отдельными страницами процедур. Шаблон страницы услуги — доминирующий: применён 43 раза по всей карте сайта. Агентство также задало два нестандартных шрифта — Avenir LT Pro и Stolzl, — которых нет в системных наборах; их нужно было приобрести до начала разработки. Главный риск, который агентство хотело исключить, — команда, которая дорабатывает клиентский шаблон, не соблюдая жёсткую границу между клиентскими переопределениями и общими компонентами шаблона. Стоматологический шаблон, обслуживающий несколько практик одновременно, не может допустить, чтобы правки под один проект ушли в общий слой: агентство обнаружит это лишь тогда, когда сломается сайт другого клиента, — а не при сдаче. Главное, ради чего нас взяли, — изоляция: каждое изменение строго в слое клиентских переопределений, ничего не затрагивает общую базу. > **Контекст рисков.** Работа не закрылась на первичной сдаче. После того как тестовая среда была одобрена и домен перешёл в рабочий режим, потребовалась реструктуризация дерева URL услуг: страницы, запущенные по пути `/services/`, нужно было перевести на городские пути `/cumming/` в соответствии с локальной SEO-стратегией агентства. Применять такую карту редиректов на действующем сайте — не то же самое, что на тестовой среде: каждый неудавшийся 301, каждая страница, которой нет в исходной карте сайта, но которая есть в меню, каждая жёстко прописанная внутренняя ссылка на старую структуру — всё это регрессия на рабочем сайте. Риск был не в том, чтобы написать редиректы. Риск был в пробелах инвентаризации: обход сайта выявил страницы услуг, которые присутствовали в меню, но отсутствовали в исходной карте сайта из таблицы Google Sheets, — значит, карту редиректов нельзя было сгенерировать механически из одной таблицы. Эти пробелы нужно было выявить, согласовать с агентством и нанести на карту до того, как применять слой редиректов. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma агентства был спецификацией дизайна. Брендированный стоматологический шаблон — базовой структурой страниц. Мы выбрали доработку на основе шаблона вместо создания каждой страницы с нуля, потому что система шаблонов агентства уже предоставляла проверенные в работе закономерности для каждого типа страниц — работа заключалась в точной адаптации, а не в создании с нуля. Наша задача была согласовать 2 источника: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовала отклонения — настройки типографики с использованием пользовательских шрифтов Avenir LT Pro и Stolzl, изменения макета на лендингах услуг, конфигурации контент-блоков на страницу — мы дорабатывали на уровне клиентских переопределений. Никаких дизайнерских решений с нашей стороны мы не принимали. **2. Таксономия услуг в масштабе.** 43 из 53 страниц использовали шаблон страницы услуги, каждая требовала индивидуального согласования Figma с шаблоном. Категории услуг были иерархическими — лендинги категорий (косметическая, неотложная, семейная, профилактическая, восстановительная стоматология) имели от четырёх до восьми дочерних страниц процедур, каждая со своим фреймом в Figma и конфигурацией контент-блоков. Согласованность во всей иерархии — единообразие заголовков, расположение изображений, формулировки CTA и интеграция форм — держалась на аккуратной разработке, а не на творчестве. **3. QA-цикл в масштабе доработки темы.** Чистая доработка шаблона — это не «собрать один раз, проверить один раз». За 138 дней агентство отследило 550+ пунктов в двух вкладках очереди задач (289 SEO-замечаний и 261 CX-замечание) по 75-пунктному контрольному списку запуска. Каждый раунд — обновление внутренних ссылок по таблице Google Sheets, обратная связь от клиента, замена плейсхолдеров на предоставленный контент — возвращался агентству только после того, как закрывали пункты предыдущего раунда. Объём отслеживаемых пунктов — это свидетельство тщательной работы, а не признак нестабильности. **4. Реструктуризация URL после релиза.** После первичного запуска агентство инициировало полную реструктуризацию URL: дерево услуг на `a1dentalclinic.com/services/` следовало перенести на `a1dentalclinic.com/cumming/` для поддержки локального поиска по городу. Внедрение включало настройку путей `/cumming/` для каждой страницы услуг и процедур, написание соответствующих правил 301-редиректов со старых путей `/services/`, а также устранение пробелов инвентаризации — страниц, которые уже работали под старой структурой, но отсутствовали в исходной карте сайта из таблицы Google Sheets, что потребовало ручного выявления и координации с агентством до применения слоя редиректов. Это вели на рабочем сайте: инструменты QA агентства проверяли корректность редиректов после каждого пакета изменений. **5. Проверка на разных устройствах.** Site Checker выполнял захват скриншотов на нескольких разрешениях для каждой страницы перед первичной сдачей и повторно после завершения реструктуризации URL. Рендеринг шрифтов Avenir LT Pro и Stolzl — оба несистемных — проверялся на мобильных, планшетных и больших экранах; крайние случаи загрузки пользовательских шрифтов (fallback-рендеринг, FOUT при промахе кэша) были подтверждены как неблокирующие перед сдачей. ## Контроль качества 75-пунктный контрольный список запуска агентства выявил 3 страницы услуг, возвращавших 404 при проверке статус-кодов перед сдачей; пост-релизная реструктуризация URL добавила второй QA-проход через таблицу редиректов с формулами, где каждый путь `/services/` помечался красным до разрешения — страницы из рабочего меню, отсутствовавшие в исходной карте сайта, выявлялись вручную и наносились на карту до применения слоя редиректов. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Внутренний контроль агентства выполнялся после сдачи и фиксировал замечания в общую очередь для нашего цикла исправлений до окончательного согласования. Доработки оставались в слое клиентских переопределений; общие компоненты шаблона агентства не изменялись. ## Результаты - **53 URL сдано** — главная, биография врача, о нас, страховка и финансирование, 3 юридические страницы, лендинг блога, лендинг зон обслуживания, контакты и 43 страницы услуг по 6 основным категориям стоматологии - **10 переиспользуемых шаблонов** применены ко всем страницам, все в пределах слоя клиентских переопределений - **550+ отслеживаемых пунктов QA** по SEO и CX очередям задач согласованы по 75-пунктному контрольному списку запуска - **Реструктуризация URL после релиза** выполнена: полная карта редиректов `/services/` → `/cumming/` внедрена на рабочем сайте с нулевой регрессией, подтверждённой агентством - **138 дней · 61 час** — разработка, QA-итерации, внедрение редиректов и управление проектом, в срок - Хостинг: Kinsta (управляется агентством); пользовательские шрифты (Avenir LT Pro, Stolzl) интегрированы без проблем с fallback-рендерингом ## Процесс Этап Длительность Результат Оценка объёма и доступ к шаблону Дни 1–4 (4–8 авг) Оценка согласована (61 ч), требования к пользовательским шрифтам выявлены, разработка начата Первичная разработка — шаблон к Figma Дни 5–30 (8 авг – 3 сен) Базовые страницы доработаны; запросы на изменения дизайна включены как change request по процессу агентства QA-итерации — SEO и CX очереди задач Дни 30–95 (3 сен – 26 окт) 550+ пунктов очереди задач отслежены и согласованы; несколько раундов проверки агентства; обновления контента и внутренних ссылок Закрытие очереди задач и сдача Дни 95–95 (26 окт – 7 ноя) Финальная проверка SEO и CX очередей задач завершена; сдача подтверждена Реструктуризация URL после релиза Дни 122–138 (4 дек – 20 дек) Полная карта редиректов `/services/` → `/cumming/` на рабочем сайте; пробелы инвентаризации устранены; слой редиректов проверен QA Примечание: QA и разработка выполнялись параллельно с этапа 3 — исправления со стороны разработчиков и циклы проверки агентства накладывались на протяжении всей работы. ## Команда Выполнено white-label — дизайн, хостинг, подбор контента и коммуникация с клиентом оставались за рамками нашей работы. Роль Специалист Ведущий разработчик Никита Тумашевич QA Павел Сажин QA и внедрение редиректов Тимур Арбаев Проверка очереди задач и координация после релиза Евгений Карпов Поддержка разработки и QA Анна Полунина Управление проектом Антон Херсун ## Агентствам с библиотекой шаблонов > В брендированной системе шаблонов риск живёт на границе между клиентскими переопределениями и общим слоем шаблона. У этой практики — сеть стоматологических клиник с переопределениями под каждый город; у других — один кабинет с переопределениями под отдельные услуги. Когда автор шаблона выкатывает обновление, ваши переопределения ломаются молча. Макеты клиента съезжают, и агентство этого не ловит. Схемы полей расходятся между вашими доработками и схемой автора шаблона. Контент ложится не в те блоки, редакторские сценарии встают. Библиотека блоков прячет от клиента редакторские элементы управления, и он не может вести контент по своим городам без разработчика. Подрядчику стоит задавать не вопрос «соберёте ли по макетам», а вопрос «как именно вы изолируете переопределения, чтобы они пережили обновления, не дали схемам разойтись и оставили редактор доступным клиенту?» Пришлите исходник шаблона, его ID и спецификацию бренда. Мы наложим клиентские переопределения на структуру шаблона и укажем места, которые сломаются на следующем обновлении или закроют клиенту доступ. Аудит ничего не стоит — смета приходит в часах, не диапазоном. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-82-urls-17-days/ title: Ребилд стоматологического сайта на WordPress (82 URL) строго по спецификации за 17 дней type: case_study date: 2025-06-14T12:29:22+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 82 URL на 15 шаблонах Elementor Pro, перестроенных с Webflow на WordPress для многофилиальной стоматологической практики в Pittsburgh (PA) — 59 изменений путей перенаправлены, 27 пунктов SEO-контроля закрыты до передачи. Агентство дало карту сайта, карту редиректов и почасовой бюджет на каждый URL; мы взяли на себя реализацию по всей цепочке платформ, проверку обходом и дисциплину следования спецификации. Сдано за 17 дней, 89 часов, без перерасхода. Работа не всегда заканчивается на переключении. После запуска сайта агентство продолжило сотрудничество — ещё шесть раундов доработок. Дисциплина сборки — вот что сделало это продолжение возможным. ## Краткий обзор Поле Значение Индустрия клиента Стоматология — общая, косметическая и восстановительная Конечный клиент South Hills Dental Arts (многофилиальная практика в районе South Hills, Pittsburgh: McMurray · Sewickley · Upper St. Clair) **Формат сотрудничества** **White-label сборка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Webflow → WordPress ребилд на WP Engine, конструктор страниц Elementor Pro Объём работ Весь сайт — 15 шаблонов: главная, услуги, филиалы, Meet Our Team (40 человек), блог, галерея улыбок, карьера Сроки 17 дней (29 апр – 15 мая 2025), по графику Трудоёмкость 89 часов при оценке 89 часов — без перерасхода на этапе ребилда Команда 6 специалистов (69 ч разработка · 10 ч QA · 10 ч PM на ребилде; ещё 24 ч на последующих раундах доработок) Технологии WordPress · Elementor Pro · WP Engine · Screaming Frog · Header Footer Code Manager · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Сверка старого сайта и ребилда пройдена перед передачей — ни пропущенного текста, ни битых внутренних ссылок, ни структурных расхождений **Результат** **Спецификация выполнена построчно — 82 URL перенесены, 59 изменений путей перенаправлены, 15 шаблонов создано, 27 пунктов SEO-контроля закрыто до согласования** Продолжение сотрудничества 6 раундов доработок в течение следующих 6 месяцев — редизайн главной, правки дизайна, восстановление меню, аудит шаблонов — каждый в отдельных спринтах в рамках тех же отношений с агентством Интенсивность работы 27 задач от агентства · все закрыты к моменту передачи (19 дней активной работы, 2025-05-18 – 2025-06-05) Раунды проверки ≈9 раундов Контрольный список запуска 29 пунктов, согласован до переключения ## Постановка задачи У агентства был давний клиент — стоматологическая практика, чей сайт стоял на Webflow и чей бизнес его перерос: сеть в 3 районах Pittsburgh, галерея Meet Our Team на 40 человек, 10 страниц услуг и блог. Структуру URL уже проаудировали и подготовили таблицу Google Sheets: каждый URL для миграции, каждое изменение пути для редиректа, шаблон, к которому относится URL, мета-заголовки для сохранения и контрольный список запуска с колонками до и после миграции. Объём в часах по строкам мы оценили сами и зафиксировали до старта. Задача была конкретной. Взять таблицу как есть; собрать сайт заново на Elementor Pro под WP Engine; сохранить целостность URL при переходе с Webflow на WordPress; вернуть сайт готовым к переключению. Не выходить на прямой контакт с клиентом. Реализовать SEO-решения как записано. Уложиться в указанные часы. Риск здесь был структурным, а не только процедурным. У сети с сорока биографиями сотрудников и миграцией CMS между платформами набор для расхождений куда шире, чем у ребилда одного врача с WordPress на WordPress. Изменение пути на странице одного филиала ложится на конкретный редирект в таблице — пропусти редирект или чуть ошибись в пути назначения, и указанный агентством 301 превратится в 404, который обнаружит конечный клиент. Отсутствующая страница биографии в шаблоне команды — видимый пробел для пациента или направившего врача. Спецификация была плотной; допуск на импровизацию — нулевой. > **Контекст рисков.** Миграция между платформами — с Webflow на WordPress — несёт категорию риска, которой нет при ребилде в рамках той же CMS: две платформы по-разному обрабатывают структуру URL, цепочки редиректов и разрешение внутренних ссылок на серверном уровне. Агентство зафиксировало каждое изменение пути и каждый редирект в таблице. Наша задача была не оспаривать эту карту, а гарантировать, что после переключения DNS каждая запись на карте отрабатывает ровно так, как указано — без петель редиректов, без коллизий цепочек, без дублирования завершающих слешей, оставшихся от Webflow. Тип отказа — не падение сайта, а незаметная поломка, которая проходит поверхностную проверку и всплывает в обходе через 6 недель. ## Как мы это сделали **1. Сборка через шаблоны.** Вместо того чтобы перестраивать 82 URL по одному, мы свели их к 15 переиспользуемым шаблонам и разместили каждый URL в соответствующем шаблоне: - Главная, О нас, Контакты и запасной Default - **Лендинг услуг + единый шаблон страницы услуги**, обслуживающий 10 услуг (реставрация, экстренная помощь, косметический Botox, элайнеры, импланты, полная реконструкция рта, рецессия дёсен, седация, TMJ, виниры) - **Шаблон страницы филиала** — многофилиальный макет для трёх точек в районе South Hills, Pittsburgh - **Шаблон Meet The Team** — высокообъёмный шаблон биографий, вмещающий 40 индивидуальных URL сотрудников - **Лендинг блога + шаблон статьи**, обслуживающие 17 записей - **Smile Gallery** — стоматологический макет «до/после» - **Careers**, **Privacy Policy**, **Sitemap**, **Doctor Page** — полноценные шаблоны, а не вариации Default 15 шаблонов — весь сайт сдан. Будущие правки на стороне агентства живут в одном месте на тип страницы — особенно шаблоны команды и филиалов, где согласованность 40 биографий и 3 адресов и есть дисциплина. **2. Спецификация выполнена построчно, в рамках согласованной сметы.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции с целевым путём, каждый мета-заголовок для сохранения, назначение шаблона, вкладка Settings с URL сайта и картой сайта, а также контрольный список запуска из 6 категорий. Объём в часах по URL мы оценили сами. Мы реализовали каждую строку как написано. Где в таблице было значение — оно попадало на новый сайт. Где его не было — пять URL биографий сотрудников, которые удалили и которых в таблице не было, — мы сообщили об этом агентству, а не импровизировали. Никаких «творческих интерпретаций» в публикацию не ушло. Принцип здесь прост: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка обходом, а не «на глаз».** До переключения DNS контрольный список запуска требовал прогнать Screaming Frog по исходному сайту на Webflow и по сборке в тестовой среде на WordPress. После переключения второй обход — уже после миграции — мы загрузили обратно в таблицу отдельной вкладкой: 85 URL просканированы, 80 вернули HTTP 200, 3 намеренных 301-редиректа, 2 404, соотнесённых с известными причинами (1 URL со старой опечаткой и 1 страница услуги вне объёма работ). Коды статусов, цепочки редиректов и расхождения в мета-заголовках — всё сверено со спецификацией. Затем — очистка внутренних ссылок: цепочку редиректов www / non-www исправили с двух переходов (307 + 301) на единый 301, дублирование завершающего слеша устранили на серверном уровне, остаток категориального редиректа от Webflow убрали. **4. 27 пунктов SEO-контроля, все закрыты до передачи.** Вкладка очереди правок агентства начиналась с 27 пунктов, найденных при их проверке тестовой среды — расхождения в формулировках H1, неработающее видео в записи блога, правки ширины макета на 1024 px и 1280 px, поведение слайдера на мобильных, отсутствующие сотрудники на странице /meet-our-team и несколько SEO-пунктов под Pittsburgh. 9 пунктов высокого приоритета, 18 среднего — каждый закрыт и отмечен как Completed до согласования. QA на разных устройствах в Chrome / Firefox / Safari / Edge и на 4 разрешениях (1920 / 1280 / 1024 / мобильный портрет). Сам контрольный список запуска охватывал 6 категорий до миграции плюс 9-шаговый под-список Domain & DNS для переключения на WP Engine. Дисциплина, скреплявшая 17-дневный спринт, — это контрольный обход: не визуальная проверка, а обход Screaming Frog исходного Webflow до переключения и второй обход опубликованной WordPress-сборки, загруженный обратно в таблицу агентства. Именно эта последовательность доказала, что 59 цепочек редиректов и дублирование завершающего слеша корректны до согласования, а не вскрылись при обходе через 6 недель. ## Результаты Метрика Результат Точность спецификации — перенесённые URL **82 / 82** URL перенесены с Webflow на WordPress, как указано Точность спецификации — редиректы путей **59 / 59** изменений URL реализованы как 301-редиректы Точность спецификации — шаблоны **15 / 15** шаблонов создано и применено на всём сайте Очередь задач SEO **27 / 27** пунктов закрыты, статус Completed (9 High, 18 Medium) Обход после миграции **80 / 85** URL на HTTP 200 на рабочем домене; 3 намеренных 301; 2 соотнесённых 404 (историческая опечатка + услуга вне объёма) Сроки (этап ребилда) **17 дней**, сдано по графику Трудоёмкость (этап ребилда) **89 ч / 89 ч** — без перерасхода Адаптивная проверка Проблемы слайдера и ширины макета на 1024 / 1280 / мобильных решены до согласования Внутреннее QA Все 27 пунктов очереди правок агентства закрыты до передачи; очередь аккаунт-менеджера пуста Статус сайта Работает на WP Engine: [southhillsdentalarts.com](https://www.southhillsdentalarts.com/). Продолжение сотрудничества 6 раундов доработок в течение следующих 6 месяцев — редизайн главной, правки дизайна, восстановление меню, аудит шаблонов — каждый в отдельных спринтах в рамках тех же отношений с агентством Если коротко: спецификация агентства реализована как написано, в рамках указанных часов, в запланированный день переключения. Отношения продолжились, потому что сборка держала форму после запуска, а не потому что её дорабатывали постфактум. ## Контроль качества Проверка перед сдачей прошла раньше, чем агентство увидело тестовую среду, и выявила пропущенный пробел в перестроенном H1 (вместо «Your Trusted Local Dentist» было «Your Trusted LocalDentist»), сквозное дублирование завершающего слеша, из-за которого каждая страница открывалась по двум адресам, и 307-редирект на non-www корне, который должен был быть единым 301. Проверку перед сдачей прогнали через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Собственная проверка агентства работала после передачи и заносила замечания в общую очередь правок для нашего цикла исправлений до согласования. ## Процесс Фаза Длительность Результат Бриф и оценка 6 дней Таблица проверена; объём по URL сведён в единое обязательство на 89 ч Разработка ~10 дней 82 URL перестроены на 15 шаблонах в тестовой среде на WP Engine Внутреннее QA и проверка 3 дня 27 пунктов очереди правок SEO заведены агентством; все закрыты Проверка спецификации 1 день Обходы Screaming Frog до и после миграции; исправления цепочек редиректов и завершающих слешей Запуск и переключение DNS 1 день Сайт запущен на WP Engine, без простоя; обход после миграции загружен обратно в таблицу _Фазы пересекаются (QA шло параллельно с завершающей разработкой), поэтому календарный срок составляет 17 дней, а не сумму отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Людмила Травкина** — разработчик (главная страница и высокообъёмные шаблоны, последующие доработки) - **Тимур Арбаев** — разработчик (итерации главной страницы и аудит шаблонов, последующие доработки) - **Павел Сажин** — QA и реализация исправлений после запуска - **Анна Полунина** — координация проекта, сверка объёма с таблицей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом и SEO-стратегия оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел ни на первом переключении, ни в каждом последующем раунде доработок. Каждое решение о структуре URL, целях редиректов и последовательности миграции принадлежало агентству — мы реализовали эти решения в точности как указано. ## Агентствам, заказывающим ребилд WordPress > Тяжелее всего ребилд стоматологического сайта бьёт там, где ваши локальные позиции пересекаются со сменой платформы. У этой практики — одна клиника общей стоматологии; у других — сети под управлением DSO с общей системой бренда. Строка редиректа, выпавшая из карты, роняет в 404 страницу услуги, что стояла на первой выдаче. Мета-заголовки и описания под локальный поиск тихо перетирает новая тема. Разметка стоматологических процедур слетает на импорте, и расширенные сниппеты, что отслеживала ваша SEO-аналитика, перестают показываться. Подрядчику по ребилду стоит задавать не вопрос «спланируете ли редиректы?», а вопрос «как вы проверите каждое сопоставление путей до переключения?» Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы проверим вашу карту редиректов и опись контента, покажем строки, где 404 или потеря разметки вероятнее всего, и вернём фиксированную смету в часах. Проверка бесплатна. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-30-page-dental-56-days/ title: Доработка стоматологического шаблона на 30 страниц за 56 дней type: case_study date: 2025-06-07T05:13:42+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 30 URL и 10 шаблонов агентства для новой стоматологической клиники в Cary, NC — без наследуемого сайта, контент написан с нуля по Google Docs для каждой страницы. Прежде чем начать клиентскую работу, мы завершили незаконченные общие страницы шаблона 7 — спроектировали и собрали недостающие макеты, затем выполнили доработку под клиента. Такая последовательность — доведение шаблона до готовности перед клиентской работой — означала, что 16-задачный 56-дневный проект оставил общий шаблон агентства прочнее, чем он был до начала. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. История из 16 задач ниже — проект, где сам шаблон нужно было довести до готовности, прежде чем браться за доработку под клиента. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Общая стоматология Клиент Sunrise Dental Cary (Cary, NC) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на WP Engine) Объём **~30 URL** — главная, лендинг услуг, страницы услуг, карточки врачей, блог, фотогалерея, VIP-членство, контакты и вспомогательные страницы (ориентир объёма от агентства) Сроки 56 дней (14 фев – 11 апр 2025), в срок Затрачено 46 часов — разработка, QA-итерации и управление проектом Команда 4 специалиста Шаблоны **~10 многоразовых шаблонов** от агентства, применённых на всём сайте Технологии WordPress · Elementor · WP Engine · Постраничный дизайн в Figma · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **16 отдельных задач** учтено на всём проекте, каждая закрыта после подтверждения агентства **Раунды проверки** ≈2 раунда на 56-дневном календарном окне ## Постановка задачи Маркетинговое агентство из США передало нам дизайн в Figma для Sunrise Dental Cary и площадку развёртывания — свою брендированную систему шаблонов на WP Engine. Клиника была новой: никакого старого сайта, архива контента или прежней URL-структуры. Агентство уже сделало всё на своей стороне — аудит дизайна, согласование с клиентом, настройку хостинга, подготовку контента в Google Docs для каждой страницы. Нужна была команда разработки, которая точно перенесёт Figma на шаблон и выдержит быстрый ритм итераций. Задача была чисто исполнительская. Figma — единственный источник истины. Дорабатывать шаблон страница за страницей. Возвращать каждую итерацию только после того, как проверяющий со стороны агентства подтвердит, что расхождение устранено. Главный риск проекта был не в дрейфе при доработке, а в накопленном долге от работы с неполным шаблоном. Брендированный шаблон 7, назначенный на этот проект, имел незавершённые страницы на старте — команде пришлось сначала довести общий слой до готовности, прежде чем браться за клиентскую работу. Подрядчик, который пропускает завершение шаблона ради срока, передаёт тот же долг каждому следующему сайту на этом шаблоне. Агентство наняло нас именно за то, чтобы сначала закрыть общий слой, а потом делать доработку чисто — и 56-дневная, 16-задачная история поставки это подтверждает. > **Контекст рисков.** Новая стоматологическая клиника, запускающаяся на брендированном шаблоне с ~30 URL и без готового контента, сталкивается с двойным пробелом: сам шаблон может быть неполным, а клиенту не с чем сравнивать при QA. Риск этого проекта был в этапе завершения шаблона — незавершённые общие страницы требовали проектирования и сборки до начала клиентской доработки, и любой компромисс на этом этапе молча распространился бы на все будущие клиники, использующие тот же шаблон. Подход здесь был структурным: сначала завершить шаблон, затем дорабатывать без отклонений, чтобы общий актив агентства стал сильнее после этого проекта, чем до него. ## Как мы это сделали **1. Завершение шаблона перед доработкой под клиента.** Брендированный шаблон агентства содержал незавершённые страницы на момент старта проекта. Мы завершили недостающие дизайны и макеты шаблона в первую очередь — построив общие компоненты, которые агентство сможет переиспользовать на будущих сайтах, — прежде чем приступать к работе под конкретного клиента. Мы выбрали эту последовательность — завершение шаблона перед клиентской работой — вместо того чтобы строить в обход пробелов, потому что неполный общий слой распространил бы дизайн-несоответствия на все будущие сайты агентства на этом шаблоне. Это означало, что фактический объём включал как доведение шаблона до готовности, так и клиентскую доработку, причём работа над шаблоном принесла пользу каждому последующему проекту на том же шаблоне. **2. Figma как контракт, шаблон как холст.** После завершения шаблона файл Figma стал спецификацией дизайна, а брендированный шаблон — базовой структурой страниц. Наша задача была согласовать их страница за страницей — где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовала отклонения, мы вносили изменения. Никакие дизайнерские решения не исходили от нас. **3. QA-цикл в масштабе доработки темы.** Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». За время проекта мы зафиксировали **16 отдельных задач** в Redmine — каждый целенаправленный раунд, в котором агентство отмечало расхождения с дизайном, правки контента или исправления шаблона, которые мы проверяли, исправляли и возвращали на подтверждение. Задачи охватывали размещение логотипа и форматирование секции услуг, обновления мобильной версии, добавление фото врачей, создание страницы команды и внедрение клиентских правок. Такой объём — не признак нестабильности; именно это отделяет шаблонный сайт, выглядящий «примерно правильно», от того, который точно соответствует дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без отклонений.** Каждое изменение в брендированном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Ни одна правка не «протекла» в общие компоненты шаблона, что означает, что работа этого проекта не ухудшила шаблон для следующего сайта. Шаблон 7 поступил неполным — общие страницы незавершённые, клиентская работа невозможна до завершения общего слоя. Мы закончили недостающие дизайны и макеты в первую очередь, затем сделали доработку под Sunrise Dental, не перенося пробел вперёд. Каждый сайт, который агентство позже запустило на этом шаблоне, получил исправление, а не долг. ## Контроль качества QA-проверка агентства на этом проекте выявила два пробела в сборке на тестовой среде до того, как клиент увидел сайт: баннер услуг вытягивал записи блога из шаблонных настроек по умолчанию вместо списка услуг, и отсутствовала заглушка вкладки для второго врача, хотя био-блок был готов — оба отметили и исправили до клиентской передачи. Предварительное QA проведено через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Собственный QA-контур агентства запускался после сдачи и фиксировал замечания в очередь задач до их подтверждения. Доработки остались в клиентских переопределениях; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **~30** — главная, лендинг услуг, страницы услуг, карточки врачей, блог, фотогалерея, VIP-членство, контакты и вспомогательные страницы (ориентир объёма от агентства) Применено шаблонов **~10** многоразовых шаблонов, сопоставленных по сайту Задач в Redmine **16** отдельных задач зафиксировано и закрыто после согласования агентством Сроки **56 дней**, сдано в срок Затраты **46 часов** при оценке в 46 часов — без перерасхода, без расширения объёма Команда **4 специалиста** Хостинг Работает в среде шаблонов агентства на WP Engine Здоровье страниц при сдаче Все URL тестовой среды вернули HTTP 200 Если коротко: Figma агентства была реализована на их брендированном шаблоне на ~30 страницах и ~10 шаблонах за 56 календарных дней в рамках оценки в 46 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к шаблону подтверждён, объём согласован Завершение шаблона ~1 неделя Недостающие страницы шаблона спроектированы и собраны Разработка доработки темы ~3 недели Постраничная доработка темы под Figma QA-итерации (параллельно) ~3 недели 16 задач зафиксировано; каждая закрыта только после согласования агентством Раунды исправлений ~1 неделя Коррекции после проверки, мобильные обновления, правки клиента Сдача финальный день Сайт запущен на WP Engine _Разработка и QA шли параллельно — это характерно для работы по доработке темы, где «этап QA» не закрывается чисто; цикл работает непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы, сопоставление Figma с макетом, внедрение форм) - **Анна Полунина** — поддержка дизайна и компоновки (завершение страниц шаблона, внедрение клиентских изменений) - **Людмила Травкина** — QA-итерации, обновления мобильной версии, сборка страниц команды - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались у партнёрского агентства на всём протяжении. Конечный клиент нас не видел: все запросы на правки шли через общую очередь задач агентства, и сборка ему напрямую не показывалась. Каждая задача закрывалась только после того, как проверяющий со стороны агентства подтверждал, что расхождение устранено. ## Агентствам с библиотекой шаблонов > На брендированном шаблоне общий актив — это фундамент. У этой стоматологической практики — одна клиника, запускающаяся на масштабируемом шаблоне; у других — сеть филиалов, которая держит единообразие сайтов на том же шаблоне. Риски тихие: правки цвета перестают расходиться по сайту, как только клиент трогает кастомайзер; переопределения дочерней темы ломаются на следующем обновлении шаблона; а сотрудник без навыков разработки не может просто добавить страницу с новой процедурой — редактор отказывает. Подрядчику стоит задавать не вопрос «соберёте ли сайт по нашему шаблону?», а вопрос «как вы разнесёте клиентские правки, чтобы общий шаблон пережил следующее обновление?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы пройдёмся по слоям доработок, отметим переопределения, которые сломаются на следующем релизе, и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-legal-78h-22-days/ title: Разработка сайта юридической фирмы из Пенсильвании на 26 страниц за 22 дня type: case_study date: 2025-06-04T10:09:24+00:00 case_industry: Юридические услуги case_type: Разработка case_practice: wordpress --- ## Подход к разработке Сайт юридической фирмы из Пенсильвании на 26 страниц под парный файл дизайна Figma — 10 шаблонов Elementor на Kinsta, покрывающих практики по травмам, несчастным случаям и компенсациям работникам: от 14 отдельных страниц практик до структуры лендингов по 2 направлениям. Контрольный список запуска из 78 пунктов и 2 очереди QA не были формальностью: они шли параллельно с хвостом исправлений контента, в который вошла сверка адвокатских регалий до согласования с агентством. ## Краткий обзор Параметр Значение Сфера деятельности конечного клиента Юридические услуги — травмы, несчастные случаи и компенсации работникам Конечный клиент Lerner, Steinberg & Associates (Feasterville-Trevose, PA) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка WordPress на Elementor и Kinsta, за которой следует длинный хвост согласования исправлений и обратной связи Объём **26 URL** — главная, 2 лендинга практик, 14 отдельных страниц практик, страница адвоката, о нас, отзывы, результаты дел, лендинг блога, контакты, политика конфиденциальности, условия Сроки 22 дня (16 сен – 8 окт 2025) для основной разработки; хвост исправлений и обратной связи до дек 2025 Трудозатраты **78 часов** при оценке 78 часов — без перерасхода Команда 6 специалистов (37 ч разработка · 20 ч QA · 15 ч на управление проектом + хвост исправлений — упор на QA оправдан для проекта, где всё держится на точности контента) Шаблоны **10 переиспользуемых шаблонов** — стандартная библиотека юридических шаблонов агентства (Homepage, Practice Area Lander, Individ. Practice Area Page, Lawyer Profile Page, About Us, Blog Lander, Contact Us, Default Template, Privacy Policy, Terms of Conditions) Технологии WordPress · Elementor · ACF · Kinsta · Gravity Forms · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Сдано** **26 URL разработаны на 10 шаблонах, 43 пункта SEO-очереди отработаны, 78-пунктный контрольный список закрыт, 32 QA-задачи + 12 задач исправления контента решены в хвосте** **Ритм работы** 44 задачи от агентства · 42 из 44 закрыты к моменту сдачи (активный период 24 дня, 2025-10-11 – 2025-11-03) **Раунды проверки** ≈6 раундов проверки за 22 календарных дня **Контрольный список запуска** 78 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Lerner, Steinberg & Associates — пенсильванской фирмой по травмам, несчастным случаям и компенсациям работникам, обслуживающей клиентов по всему штату — передало нам файл Figma дизайна, таблицу Google Sheets с полной картой URL, каталог шаблонов, контрольный список запуска и предварительно заполненные очереди задач. Разработка велась в их среде Kinsta; конструктор страниц — Elementor с ACF для структурированного контента; контактные формы — через Gravity Forms. Вкладка Templates в таблице Google Sheets содержала библиотеку LEGAL: Practice Area Lander, Individ. Practice Area Page, Lawyer Profile Page, About Us, Blog Lander, Contact Us и вспомогательные юридические страницы. Задача: разработать все 26 страниц по юридической библиотеке шаблонов агентства — сопоставить каждый URL индивидуальной практики с назначенным шаблоном из строки карты сайта — и отработать SEO-очередь задач и длинный хвост исправлений и обратной связи до принятия сайта агентством. На всём протяжении не выходить на прямой контакт с конечным клиентом; выносить неясности обратно агентству; не импровизировать описания практик, адвокатские регалии или навигационную иерархию. Исходные данные агентства содержали расхождения в контенте — разный стаж у одних и тех же адвокатов, по-разному оформленные разделы Education, почти одинаковые записи в результатах дел. Команда разработки могла их выявить, но не редактировать: тексты практик и адвокатские регалии были вне объёма контракта на разработку. > **Контекст рисков.** Когда QA агентства нашло три противоречащих друг другу значения стажа на главной и страницах биографий адвокатов — 51, 32 и «более 33 лет» в разных разделах — и отметило, что разделы Education у двух адвокатов оформлены по-разному, риск стал конкретным: опубликованный сайт несёт сведения, которые фирма не подтверждала. Подрядчик, который строит пенсильванский сайт по травмам и несчастным случаям, не пишет контент, не решает, какие практики перечислять и как их описывать, не судит о формулировках результатов дел и заявленном стаже. За что подрядчик отвечает — это структурная точность: каждый адвокат из карты сайта появляется на сайте с верной ролью, каждая страница практики существует и открывается, навигация отражает реальный набор услуг фирмы. Когда QA агентства находит расхождения в контенте — разный стаж на разных страницах, по-разному оформленные разделы образования, заглушку вместо текста в результатах — на кону опубликованный сайт со сведениями, которые фирма не одобряла. Аккуратно закрыть эти правки до сдачи — вот дисциплина, которая здесь решает. ## Как мы это сделали **1. 10 шаблонов, 26 страниц, один процесс разработки.** Страницы Lerner, Steinberg & Associates распределены по библиотеке юридических шаблонов агентства: Homepage (1), Practice Area Lander (2 — травмы и несчастные случаи, компенсации работникам), Individ. Practice Area Page (14 — самый тяжёлый шаблон, покрывающий ДТП, грузовые ДТП, мотоциклетные ДТП, падения, укусы собак, врачебную ошибку, противоправное причинение смерти, ответственность за территорию, наезды на пешеходов, велосипедные ДТП, строительные травмы, травмы от повторяющихся нагрузок, профессиональные заболевания и отказы по искам), Lawyer Profile Page (1), About Us (1), Blog Lander (1), Contact Us (1), Default Template (3 — отзывы, результаты дел и пост блога), плюс Privacy Policy и Terms of Conditions. Каждую страницу создали на назначенном шаблоне из строки карты сайта; ни одной не собирали вручную вне системы шаблонов. **2. Спецификация выполнена строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Дальше держались сметы, а не переоценивали отдельные страницы по ходу: заранее согласованная смета — договорное обязательство, и пересмотр цены постранично подорвал бы фиксированный бюджет в часах. В сумме проект уложился в согласованные 78 часов. Принцип прост: карта сайта с дизайном — это контракт. Дело команды — уложиться в согласованную смету, а не возвращаться к торгу о цене на каждой странице. **3. Хвост исправлений и обратной связи до согласования.** После первичной разработки агентство открыло раунды проверки через индивидуальные задачи — 12 задач по исправлению контента и дизайна плюс 32 записи QA-отслеживания. Каждый раунд охватывал и точность контента (единообразие разделов образования адвокатов, согласованность стажа, тексты FAQ и результатов), и правки макета и отступов, и доработки дизайна на уровне страниц. SEO-очередь задач из 43 пунктов отрабатывали параллельно. Все отслеживаемые задачи решили в хвосте до согласования агентством. **4. Два параллельных QA-цикла, закрыты до запуска.** Задачи отслеживались в двух очередях задач на стороне агентства — очередь SEO (43 строки с описаниями, 29 Completed) и очередь CX (2 строки с описаниями, 1 Completed). Пункты SEO-очереди задач охватывали точность мета-заголовков, согласованность H1 и единообразие контента на 14 страницах практик. 78-пунктный контрольный список запуска — категории Design, Functionality, Content, SEO, Responsive и DNS — закрылся после обеих очередей задач. Когда QA агентства отметило три противоречащих значения стажа и два по-разному оформленных раздела Education, команда разработки могла выявить каждое расхождение, но не внести правки — это ограничение и задало хвост. Закрыть эти задачи через цикл исправлений и обратной связи, раунд за раундом, — вот чего на самом деле потребовала 22-дневная разработка. ## Результаты Метрика Результат URL разработано **26** на 10 шаблонах (1 Homepage · 2 Practice Area Landers · 14 Individ. Practice Area Pages · 1 Lawyer Profile · 1 About Us · 1 Blog Lander · 1 Contact · 3 Default Template · 1 Privacy Policy · 1 Terms of Conditions) Шаблонов применено **10 / 10** из стандартной библиотеки юридических шаблонов агентства SEO-очередь задач **29 / 43** с описаниями закрыты (Completed); остальные — Info-Needed или в QA на момент выгрузки данных CX-очередь задач **1 / 2** с описаниями закрыта (Completed) Контрольный список запуска **78 пунктов** согласованы по категориям Design / Functionality / Content / SEO / Responsive / DNS Хвост исправления контента 12 индивидуальных задач по исправлению контента и дизайна решены; 32 записи QA-отслеживания закрыты в хвосте Сроки **22 дня** для основной разработки; хвост исправлений и обратной связи до дек 2025 Трудозатраты **78 ч / 78 ч оценка** — без перерасхода, без расползания объёма **Статус сайта** Опубликован на Kinsta по адресу https://injuryinpa.com/ — проверено в апреле 2026. Если коротко: разработка на 26 URL сдана на 10 шаблонах в среде Kinsta, в рамках заявленного бюджета 78 часов. Две очереди QA отработаны до уровня, который агентство приняло, контрольный список запуска закрыт до переключения. ## Контроль качества QA перед сдачей прогнало Site Checker по всем 26 URL. Контент здесь подтягивался в шаблоны Elementor через поля ACF, и плагин поначалу видел на каждой странице отсутствующий H1 и пустое тело; метод проверки контента переписали на рендеринг всей страницы — после этого проход прошёл начисто. QA перед сдачей прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) с перечнем категорий и порогом нулевых ошибок. Контроль на стороне агентства работал после сдачи и выводил замечания в общую очередь для нашего цикла исправлений, пока агентство не согласовало результат. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Файл Figma проверен, строки таблицы Google Sheets подтверждены, 78 ч оценено и согласовано Фаза разработки (страницы + шаблоны) ~2 недели Все 26 URL созданы на 10 шаблонах на тестовой среде Kinsta; SEO-очередь задач открыта Хвост исправлений и обратной связи ~10 недель Точность контента, дизайнерские доработки, единообразие секций адвокатов; 12 задач исправлений + 32 записи QA-отслеживания решены Контрольный список запуска + сдача финальная неделя 78-пунктный контрольный список согласован; сайт запущен на Kinsta _Этапы накладываются — хвост исправлений и обратной связи начался до закрытия всех пунктов QA фазы разработки, поэтому календарный срок превышает сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — проверка разработки и поддержка QA - **Павел Сажин** — QA-итерации и исправления - **Анна Полунина** — поддержка реализации и QA - **Тимур Арбаев** — поддержка разработчика на поздней доработке и корректировках контента - **Людмила Травкина** — ведущий разработчик на этапах разработки и обратной связи - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > На сайте юридической фирмы таксономия практик задаёт URL-архитектуру, иерархию контента и позиции в выдаче, за которые отвечает агентство. У фирмы по травмам и компенсациям таксономия идёт по типам исков; у фирмы общей практики — по областям права. Риски тихие: схему URL зашьют слишком рано — новая подпрактика, добавленная на шестом месяце, в архитектуру не впишется. Интеграции форм, заведённые другой командой, откажут без единой ошибки. Структурированная разметка пропадёт при импорте и заберёт расширенные сниппеты из панелей аудита агентства. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы выстроите таксономию, чтобы новые разделы добавлялись без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или файлы дизайна. Мы пройдём по вашей структуре практик и плану URL, отметим, где таксономия может зашиться слишком рано, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-two-doctor-76-days/ title: Доработка стоматологического шаблона для двух врачей за 76 дней type: case_study date: 2025-05-28T16:05:17+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 11 шаблонов секций DENTAL из брендированной библиотеки агентства, два экземпляра страницы Doctor Page для отдельно аккредитованных врачей — каждый доработан на уровне страницы, общая структура шаблона при этом не тронута. Figma — контракт, шаблон — холст. Одна ранняя сложность: Proxima Nova пришла без лицензии в середине спринта. По рекомендации Тимура команда заменила её визуально контрастным шрифтом-заглушкой — так при QA каждая затронутая страница оставалась заметной, пока не придёт лицензированный шрифт. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология — общая и семейная практика Конечный клиент Marina Pointe Dental (Dr. Alejandro Nieves, DMD и Dr. Bhavya Paranthaman, DMD, Panama City, FL) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка WordPress-шаблона (брендированный шаблон агентства + дизайн в Figma на уровне страниц, Kinsta) Объём работ **~20 URL запускаемого этапа** — главная, «О нас», 2 страницы с биографиями врачей, лендинг услуг, 5+ страниц услуг, контакты, страница неотложной помощи, политика оплаты, вспомогательные страницы; ~24 страницы «После релиза» отложены на следующую фазу Сроки 76 дней (25 ноября 2025 – 9 февраля 2026), по графику Трудозатраты 59 часов — разработка · итерации QA · PM · раунды исправлений после запуска Команда 5 специалистов Шаблоны **11 шаблонов секций DENTAL** из мультиотраслевой библиотеки шаблонов агентства, применённых на страницах запускаемого этапа Технологический стек WordPress · Elementor · хостинг Kinsta · дизайн в Figma на уровне страниц · AutoQA агентства (проверки Links / Email / Content AI) · TrustIndex (виджет отзывов) · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **68 задач Redmine по QA** на этапах разработки, итераций QA и раундов исправлений после запуска; плюс 472 строки в двух вкладках очереди задач агентства (SEO и CX) **Динамика взаимодействия** 4 задачи от агентства · 3 из 4 закрыты к передаче **Раунды проверки** ≈6 раундов проверки за 76 календарных дней **Контрольный список запуска** 78 пунктов, согласованы перед переходом на рабочий сервер ## Постановка задачи Маркетинговое агентство из США передало дизайн в Figma для Marina Pointe Dental и площадку развёртывания — их брендированную систему шаблонов в среде Kinsta. У клиники была структурная особенность, которой нет на типичном сайте с одним врачом: два отдельно аккредитованных врача — Dr. Alejandro Nieves, DMD и Dr. Bhavya Paranthaman, DMD — каждому полагалась своя страница Doctor Page в системе шаблонов по пути `/about/`. Figma агентства отразила оба профиля по отдельности. Карта сайта тоже делилась на два слоя: запускаемый этап — главная, ключевые услуги и информационные страницы, отмеченные зелёным в таблице агентства, — и уровень «После релиза», включавший подстраницы услуг, страницы зон охвата и страницу услуг на испанском языке (`/panama-city/servicios-dentales/`), отложенные на следующую фазу. Наш объём — только зелёные страницы; отложенный уровень был зафиксирован в таблице, но в рамках этого проекта не разрабатывался. Задача была исполнительской. Figma — единственный источник истины. Дорабатывать брендированный шаблон страница за страницей, точка адаптации за точкой адаптации. Передавать находки QA через общую рабочую область агентства — конечный клиент о ходе разработки не знает. Выносить перед агентством вопросы, а не принимать дизайнерские решения. Рано возникла типографическая проблема, которая хорошо показала, какой выдержки требует такой формат работы. Спецификация агентства предусматривала Proxima Nova как основной шрифт — лицензированный, который клиент ещё не передал к началу разработки. Вместо того чтобы остановить работу или подобрать визуально похожую замену, незаметную при беглом просмотре, команда поставила шрифт-заглушку с заметным контрастом: любая страница без нужного шрифта сразу бросалась в глаза при QA. Нужный шрифт пришёл в середине спринта и был применён глобально через систему глобальных стилей Elementor. > **Контекст рисков.** Доработка темы для практики с двумя врачами несёт конкретный риск, которого нет при работе с одним врачом: шаблон Doctor Page должен содержать двух разных специалистов — каждый со своими данными об аккредитации, биографией, фото и URL — так, чтобы данные одного врача не попали на страницу другого, а общие компоненты шаблона не получили специфические для этого сайта переопределения, которые затронут других клиентов на том же шаблоне. Каждая страница Doctor Page — это отдельный экземпляр с отдельным контентом, но обе работают на одном шаблоне. Любая небрежная глобальная правка макета шаблона Doctor Page одновременно распространяется на оба профиля. Главное здесь — изоляция на уровне страниц: дорабатывается контент каждого конкретного врача, а не структура шаблона. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma агентства был дизайнерской спецификацией. Брендированный шаблон — базовой структурой страниц. Наша задача — согласовать их страница за страницей: где стандартный макет шаблона совпадал с Figma, мы его сохраняли; где Figma требовала отклонения, мы дорабатывали на уровне страницы. Никаких дизайнерских решений с нашей стороны. Два экземпляра страниц Doctor Page собрали по путям `/about/meet-dr-alejandro-nieves/` и `/about/meet-dr-patricia/` — каждый со своим фото, данными об аккредитации и биографией, при сохранении целостности общей структуры шаблона Doctor Page. Figma агентства охватила оба профиля; мы реализовали оба под нужный контент, данные врачей при этом не пересекались. **2. Цикл QA в масштабах доработки темы.** Чистая доработка темы — это не «сделать раз, проверить раз». Из 68 задач, отслеживаемых в Redmine по этому проекту, большинство составляли итерации QA — отдельные раунды, в которых агентство фиксировало расхождения с дизайном, а мы проверяли, исправляли и возвращали сборку на повторный проход. Объём отражает ожидаемый масштаб работ по согласованию Figma с шаблоном, а не нестабильность. На этом проекте всплыли разные вопросы: геометрия макета (сломанные секции, выравнивание шапки, центровка кнопок), типы полей форм, иноязычный текст в секции страницы, замена изображений на 2 страницах врачей. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без дрейфа.** Каждое изменение брендированного шаблона — будь то макет страницы, компонент секции или токен стиля — мы держали в переопределениях страниц конкретного клиента. Общие компоненты шаблона агентства не трогали. Это важно, поскольку библиотека шаблонов агентства охватывает несколько отраслей (Dental, Legal, Veterinary и другие, видимые в каталоге шаблонов в таблице); дрейф с одного проекта не должен затрагивать сайт другого клиента на том же шаблоне. Страница Emergency Dentist потребовала отдельного внимания в цикле QA — агентство указало, что её структура должна отличаться от стандартного макета страницы услуги, и по ней прошло несколько раундов исправлений с отдельной задачей в Redmine. **4. Управление объёмом работ на границе карты сайта.** В таблице агентства явно разграничивались страницы «запускаемого этапа» (зелёные) и страницы «После релиза». Мы разработали только зелёные страницы и держали отложенный уровень за пределами объёма. Поддержание этой границы требовало активных усилий в ходе QA: когда проверяющий QA отметил, что в процессе проекта часть страниц была добавлена в зелёный список без соответствующего обсуждения объёма, команда вернула вопрос агентству для принятия решения по объёму, а не приняла работу в объём без согласования. Коротко: отложенный объём определяет агентство, а не разработчик. **5. Проверка на разных устройствах.** Все доработки прошли QA в Chrome, Firefox, Safari и Edge на устройствах: большом экране, планшете и телефоне — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями с дизайном в этом раунде, — так покрытие держалось без полного повторного тестирования всего сайта при каждой итерации. В сборке с двумя врачами было одно структурное противоречие: два специалиста, два пути, один общий шаблон. Удержала его доработка каждой страницы Doctor Page на уровне страницы, без вмешательства в общую структуру. Шрифт-заглушка вместо Proxima Nova подтвердил подход: контрастная замена по рекомендации Тимура держала каждую затронутую страницу на виду — она не ускользала мимо проверки. ## Результаты Метрика Итог Доставленные URL (запускаемый этап) **~20** страниц запускаемого этапа доработаны по Figma, включая главную, два профиля врачей, услуги, страницу неотложной помощи, контакты и вспомогательные страницы Применённые шаблоны **11 шаблонов секций DENTAL** из брендированной библиотеки агентства, применённых на страницах запускаемого этапа Контрольный список запуска **78 пункта** проверено и согласовано Отслеживаемые и решённые проблемы QA / SEO **472 строки** в двух вкладках очереди задач агентства (SEO и CX) Задачи Redmine по QA **68 задач** на этапах разработки, итераций QA и раундов исправлений после запуска Сроки **76 дней** (25 ноября 2025 – 9 февраля 2026), сдано по графику Трудозатраты **59 часов** при оценке в 59 часов — без перерасхода Команда **5 специалистов** Сборка с двумя врачами Обе страницы профилей врачей доставлены с уникальным контентом для каждого; структура общего шаблона сохранена Отложенный объём Уровень «После релиза» (~24 URL, включая подстраницы услуг, страницы зон охвата и испаноязычные страницы) аккуратно выведен из объёма и оставлен для следующей фазы Передача на хостинг Опубликован в шаблонной среде Kinsta агентства Если коротко: Figma агентства реализована по их брендированному шаблону на страницах запускаемого этапа — включая сборку с двумя профилями врачей — за 76 календарных дней, в рамках оценки 59 часов. ## Контроль качества QA этой сборки выявил две отдельные категории остатков шаблона до передачи: иноязычный текст на странице блога (отмечен агентством в очереди задач как «Remove this text — it’s not english»), а также слишком большие изображения в формате base64, встроенные в HTML главной страницы (~314 КБ в двух встроенных SVG), из-за которых инструмент создания скриншотов давал сбой — они были заменены оптимизированными PNG- и WebP-ресурсами. QA перед передачей проводили через **Site Checker** — категории проверок и порог нулевых ошибок описаны в [нашей QA-методике](/site-checker/). Контур проверки агентства запускался после передачи и вносил оставшиеся вопросы в общую очередь для нашего цикла исправлений, пока агентство не согласовало результат. Доработки остались в переопределениях страниц конкретного клиента; общие компоненты шаблона DENTAL агентства не изменялись. ## Процесс Фаза Продолжительность Результат Бриф и оценка ~3 дня Figma проверена, доступ к шаблону подтверждён, объём и зелёные страницы согласованы Координация по шрифту ~1 неделя Лицензия Proxima Nova доставлена в середине спринта; заглушка использовалась до получения Разработка доработок ~4 недели Постраничная доработка шаблона по Figma для URL запускаемого этапа Итерации QA (непрерывно) ~4 недели Зарегистрировано 68 задач Redmine; каждый раунд исправлений проверялся агентством перед закрытием Управление границей объёма непрерывно Уровень «После релиза» оставался вне объёма на протяжении всего проекта Сдача и передача последняя неделя Сайт запущен на Kinsta; критерии приёмки AutoQA агентства пройдены _Разработка и QA шли параллельно — характерная особенность работы по доработке темы, где «фаза QA» не закрывается чисто; цикл продолжается до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и приведение макета в соответствие с Figma) - **Анна Полунина** — поддержка дизайна и разработки (координация дизайна, раунды QA) - **Тимур Арбаев** — руководитель QA (внутренняя проверка, проверка исправлений) - **Павел Сажин** — управление проектом и итерации QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороны агентства, согласование) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались за партнёрским агентством на протяжении всего проекта. Конечный клиент нас не видел: все запросы на доработку шли через общую очередь задач агентства, без прямого контакта с нашей командой. Каждый раунд QA закрывался только после подтверждения проверяющим со стороны агентства, что расхождение устранено. ## Агентствам с библиотекой шаблонов > Сборка сайта стоматологической практики на готовом шаблоне профилей врачей несёт риск: общий макет страницы, а контент каждого специалиста уникален. У этой практики — несколько врачей на одном типе страницы; у других — один врач или уникальная структура под каждого. Шаблон сломается незаметно: глобальная правка макета применится сразу ко всем профилям, локальные переопределения для одного врача затронут остальных, а уникальные данные (аккредитация, биография) перепутаются между страницами. Подрядчику стоит задавать не вопрос «соберёте ли страницы врачей», а вопрос «как именно изолируете контент каждого врача, не меняя общий шаблон». Пришлите исходник шаблона, макеты или описание структуры записей. Мы пройдёмся по архитектуре шаблона, проверим изоляцию данных и готовность к обновлениям и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-veterinary-20h-47-days/ title: Разработка 25-страничного сайта ветеринарной клиники на WordPress за 47 дней type: case_study date: 2025-05-23T19:45:57+00:00 case_industry: Ветеринария case_type: Разработка case_practice: wordpress --- ## Подход к разработке 25 страниц ветеринарного сайта, разработанных по живому фронтенду — предыдущий подрядчик отказался сотрудничать: нет доступа к админке, нет экспорта темы, нет выгрузки контента. Агентство предоставило карту сайта на 9 шаблонов с задачей повторить живой фронтенд; трансфер домена должен был завершиться после разработки. Мы восстановили тайтлы страниц, H1 и мета-описания по тому, что отображал браузер, по ходу дела исправили пакет URL-слегов, вызывавших 301, и сдали работу за 20 часов на протяжении 47 дней. ## Краткий обзор Поле Значение Индустрия конечного клиента Ветеринария — практика мелких домашних животных Конечный клиент Montclair Veterinary Associates (Montclair, NJ) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка WordPress на WP Engine — Elementor Pro, новый стек, повторяющий живой фронтенд Объём работ **25 URL** — главная, о нас, лендинг услуг, 13 страниц услуг, галерея, контакты, страница врача/команды, лендинг блога, плюс 5 вспомогательных страниц на шаблоне Default Template Сроки 47 дней (25 Feb – 13 Apr 2025), сдано в срок Затраты **20 часов** при оценке 20 часов — без перерасхода Команда 4 специалиста Шаблоны **9 повторно используемых шаблонов** — Service Page (применён 13 раз), Default Template (6 раз), и 7 одноразовых типов страниц (главная, о нас, лендинг услуг, галерея, лендинг блога, контакты, страница врача) Технологии WordPress · Elementor Pro · WP Engine · Yoast · Gravity Forms · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Результат** **25 URL разработано на 9 шаблонах, 48-пунктный контрольный список запуска закрыт, очередь правок отработана, URL-слеги скорректированы** **Ритм работы с агентством** 3 задачи от агентства — все закрыты к моменту передачи **Раунды проверки** ≈4 раунда проверки за 47 календарных дней **Контрольный список запуска** 48 пунктов, согласован перед переключением ## Постановка задачи Montclair Veterinary Associates — локальная ветеринарная клиника мелких домашних животных в Montclair, New Jersey — практика одного врача, предлагающая полный спектр профилактической помощи, диагностики, хирургии, чистки зубов и специализированных услуг, включая витамины для животных, лечебные корма и линейки продуктов CBD/hemp. Маркетинговое агентство из США, специализирующееся на сайтах для локального бизнеса, привлекло нас к разработке нового сайта клиники на WordPress на WP Engine с использованием Elementor Pro. Ситуация с самого начала была операционно необычной: предыдущий подрядчик владел и сайтом, и хостингом и отказался предоставлять исходные файлы, экспорт темы или доступ к админке. Бриф агентства был чёток — построить новый сайт, максимально точно повторяющий живой фронтенд, используя карту сайта на 25 URL из таблицы Google Sheets как спецификацию. Агентство отвечало за дизайн, контент-стратегию и отношения с клиентом. Мы отвечали за разработку: настройку окружения WP Engine, создание каждого URL по назначенному шаблону, подключение контактной формы, настройку мета-полей Yoast согласно значениям в таблице Google Sheets и исправление проблемы с URL-слегами после разработки до передачи. Аудит URL в процессе разработки выявил, что несколько слегов страниц услуг содержали суффикс `-montclair-nj` с исходного сайта, что создавало цепочки 301 редиректов между URL на тестовой среде и их целевыми путями. Бриф агентства требовал чистых URL с ответом 200 на тестовой среде до трансфера домена; наша команда исправила несоответствие слегов на всех затронутых страницах, очистила объектный кеш WP Engine и подтвердила чистые ответы, прежде чем задача была помечена как готовая к проверке агентством. > **Контекст рисков.** Разработка сайта без доступа к админке оригинала означает, что единственный канонический референс — это живой фронтенд: тайтлы, H1, мета-описания, изображения и структура навигации, восстановленные по тому, что отображает браузер, а не по тому, что экспортировала CMS. Когда трансфер домена позже завершится и новый сайт заработает по тому же URL, любое расхождение между тем, что фронтенд показывал на момент разработки, и тем, что исходная CMS на самом деле содержала — скрытая страница, альтернативное мета-описание, услуга в статусе черновика, ещё не опубликованная — станет регрессией на уже работающем сайте. Агентство подстраховывалось от этого разрыва: команда разработки, которая проверяет только то, что может увидеть, вместо той, что задаёт правильные вопросы о том, чего не видно. ## Как мы это сделали **1. 9 шаблонов, 25 страниц, один процесс разработки.** Карта сайта в таблице Google Sheets содержала колонку Template для каждого URL. Service Page была рабочей лошадкой — 13 страниц услуг для животных, включая чистку зубов, диетическое консультирование, собственную лабораторию, хирургию мягких тканей, стерилизацию и кастрацию, чипирование, ультрасонографию, линейки продуктов CBD и hemp, лечебные корма и рецептурные препараты. Помимо дерева услуг: главная страница, страница «о нас», лендинг услуг, галерея, контакты, страница врача/команды, лендинг блога, страница отзывов, форма для новых клиентов и три вспомогательные страницы (заявление о доступности, запись на приём, политика конфиденциальности). Каждый URL построен по назначенному шаблону; ни одна страница не отклонялась от назначенной строки шаблона. **2. Спецификация выполнена построчно, в рамках согласованной сметы.** Объём в часах по каждой строке карты сайта мы оценили сами и зафиксировали до старта — 13,05 ч на основную разработку, остальное на управление, коррекцию URL и доработки из очереди правок. Мы уложились в согласованный бюджет 20 часов. Команда решила оценить в 20 часов, а не в сумму по таблице Google Sheets — разница в 7 часов была сознательным запасом на известный риск работы без доступа к админке: аудит слегов в процессе или неожиданная задача из очереди правок потребуют запаса, чтобы решить их без переоценки. **3. Коррекция URL-слегов перед передачей.** Проверка в процессе разработки выявила закономерность: несколько страниц услуг содержали суффикс `-montclair-nj` в слегах (например `/pet-dental-care-cleaning-montclair-nj/`), создавая цепочки 301 редиректов между URL на тестовой среде и целевыми путями. Колонка New URL в таблице Google Sheets содержала правильные чистые слеги; мы обновили все затронутые страницы, очистили кеш WP Engine и подтвердили ответы HTTP 200 на всех исправленных путях перед отправкой задачи на передачу. **4. Очередь правок и закрытие контрольного списка запуска.** Проверка на тестовой среде выявила дополнительные пункты: коррекцию мета-тайтлов (тайтл главной на тестовой среде отличался от целевого в таблице Google Sheets), отсутствующий H1 на странице About Us, форматирование выпадающего меню для соответствия архивному оригиналу и несколько несоответствий в формате мета-тайтлов. Все пункты были обработаны и закрыты через задачу по ошибкам до финальной сдачи. Контрольный список запуска на 48 пунктов — охватывающий фазы Design, Functionality, Pre-Migration и Domain and DNS — был проработан для разблокировки трансфера домена. Разработка без доступа к админке диктовала порядок работ: сначала разработать по фронтенду, отображаемому в браузере, затем провести аудит слегов, затем закрыть очередь правок — и только после этого можно было завершить трансфер домена на чистом стеке. Коррекция суффикса `-montclair-nj` была не исправлением после разработки; она была частью того, что требовало ограничение. ## Контроль качества QA перед передачей выявило, что каждая страница услуг унаследовала суффикс `-montclair-nj` в слеге с исходного сайта, создавая цепочки 301 редиректов против целевых чистых URL из таблицы Google Sheets — суффикс был удалён со всех затронутых страниц, а кеш WP Engine очищен, прежде чем каждый URL был подтверждён как чистый 200. QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) — категории и порог нулевых ошибок. Контроль на стороне агентства работал после передачи и фиксировал замечания в общую очередь правок для нашего цикла исправлений до их согласования. ## Результаты Метрика Результат URL разработано **25** на 9 шаблонах (Service Page ×13, Default Template ×6, Homepage ×1, About Us ×1, Services Lander ×1, Gallery ×1, Blog Lander ×1, Contact Us ×1, Doctor Page ×1) Шаблонов применено **9 / 9** из стандартной библиотеки агентства для локального бизнеса Коррекция URL-слегов Все слеги страниц услуг исправлены на целевые с ответом 200 до трансфера домена Очередь правок Мета-тайтлы, H1, форматирование меню и навигация исправлены к моменту передачи Контрольный список запуска **48 пунктов** по категориям Design / Functionality / Pre-Migration / Domain and DNS Сроки **47 дней** (25 Feb – 13 Apr 2025), сдано в срок Затраты **20 ч / оценка 20 ч** — без перерасхода, без расползания объёма Передача Сайт работает на WP Engine на рабочем домене, отдаёт HTTP 200 Статус сайта, проверено 2026-04 Боевой домен работает, отдаёт 200 по свежей проверке Результат: сайт ветеринарной клиники на 25 URL, разработанный по фронтенду на стеке WP Engine + Elementor Pro, с исправленными слегами URL и закрытыми задачами из очереди правок — переданный в состоянии, готовом к завершению трансфера домена. ## Процесс Фаза Длительность Результат Бриф и оценка ~1 неделя таблица Google Sheets рассмотрена, тестовая среда настроена на WP Engine, оценка 20 ч согласована Разработка ~2 недели Все 25 URL разработаны на 9 шаблонах; открыта очередь правок Коррекция URL-слегов ~1 день Слеги с 301-цепочками выявлены, исправлены, кеш очищен, ответы 200 подтверждены Очередь правок и контрольный список ~2 недели Мета-тайтлы, H1, навигация и меню исправлены; проработан 48-пунктный контрольный список Трансфер домена и DNS Финальные дни Трансфер домена завершён; сайт работает в рабочем режиме _Фазы разработки и очередь правок перекрывались в последние 2 недели — задача коррекции URL-слегов выполнялась параллельно с основной проверкой разработки, поэтому календарные 47 дней превышают сумму последовательных фаз._ ## Команда **Команда проекта** - **Владимир Козлов** — ведущий разработчик (разработка, коррекция URL, доработки из очереди правок) - **Павел Сажин** — QA и проверка разработки - **Никита Тумашевич** — координация проекта, оценка, контроль разработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, коммуникация с клиентом и логистика трансфера домена оставались на партнёрском агентстве на протяжении всего проекта. Наша команда работала на тестовой среде; агентство управляло сроками переключения и этапами согласования с клиентом. ## Агентствам, заказывающим разработку WordPress > Сборка сайта для сети ветеринарных клиник ставит на кон вашу репутацию: каждый элемент — от таксономии до структурированной разметки — должен соответствовать ожиданиям вашего клиента. У этой сети — многопрофильные центры с диагностикой и хирургией; у других — одиночные приёмы без филиальной структуры. И если подрядчик не продумал архитектуру, проблемы всплывают после запуска. Новый филиал не впишется в иерархию URL. Страницы с фильтрацией по услугам выпадут из индекса. Структурированная разметка ветеринарной практики слетит на импорте — расширенные результаты исчезнут из ваших отчётов. Подрядчику стоит задавать не вопрос «соберёте ли вы сайт?», а «как именно вы построите таксономию, чтобы следующее направление встало без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы проверим, как таксономия выдержит рост сети, найдём URL-риски и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-39h-38-days/ title: Сфокусированная разработка стоматологического сайта WordPress на действующем сайте — 39 часов type: case_study date: 2025-05-21T21:45:33+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 11 шаблонов, 18 перестроек URL и действующий сайт на WP Engine, который не мог упасть — сфокусированная разработка для стоматологии, сданная за 38 дней и 39 часов маркетинговому агентству из США. Новые страницы услуг, страницы врачей и «О нас» собрали на защищённых паролем тестовых URL с noindex, пока существующий сайт продолжал обслуживать пациентов, и каждый старый путь услуги сверили по контрольному списку запуска из 30 пунктов до индексации. ## Краткий обзор Параметр Значение Сфера деятельности клиента Медицина — общая стоматология Конечный клиент Northern Westchester Dental Care (Yorktown Heights, NY) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка WordPress с Elementor на WP Engine, выполненная на существующем сайте клиента с защищёнными паролем тестовыми URL Объём **Сфокусированная разработка** — новые страницы услуг, страницы врачей и «О нас» созданы на тестовых URL с noindex; 18 существующих URL услуг реструктурированы и перенаправлены; весь сайт отслеживался по 126 URL в карте сайта Сроки 38 дней (30 сен – 7 ноя 2025), с последующим обновлением дизайна 2 страниц; сдано по графику Трудозатраты **39 часов** при оценке 39 часов — без перерасхода Команда 5 специалистов Шаблоны **11 переиспользуемых шаблонов** — стандартная библиотека стоматологических шаблонов агентства Технологии WordPress · Elementor · WP Engine · Rank Math · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **Новые страницы услуг, страницы врачей и «О нас» на тестовых URL; 18 пар редиректов согласованы; контрольный список запуска из 30 пунктов закрыт; 34/46 очереди правок SEO + 1/3 очереди правок CX выполнены** **Интенсивность взаимодействия** 46 вопросов от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈7 раундов проверки на протяжении 38 календарных дней **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Northern Westchester Dental Care — стоматологической практикой общего профиля в Yorktown Heights, New York — передало нам таблицу Google Sheets с полной инвентаризацией сайта, каталогом шаблонов, контрольным списком запуска и предзаполненными очередями правок SEO и CX. Главная страница практики уже была запущена на их окружении WP Engine; конструктор страниц — Elementor. Исходный контент для страниц врачей был скудным — ограниченный биографический текст на каждого специалиста, поэтому описания направлений практики использовались во всех профилях врачей как заполнитель, с заменой после получения от агентства расширенных материалов. Задача заключалась в создании остальных ключевых страниц (страница услуг, страницы врачей и «О нас») на защищённых паролем тестовых URL с noindex в существующей установке WordPress, согласовании 18 изменений URL со старой структуры путей услуг на новую, основанную на локациях, и проработке обеих очередей правок QA до приёмки сайта агентством. > **Контекст рисков.** Когда разработка затрагивает действующий сайт, риск агентства не в том, удастся ли собрать новые страницы — а в том, отнесётся ли подрядчик к действующему сайту как к хрупкому. Ошибка в настройке редиректа на работающем стоматологическом сайте не выдаёт себя строкой в логе ошибок; она выдаёт себя, когда пациент жмёт старую закладку и попадает на 404. Риск не в том, чтобы написать страницы, а в том, чтобы написать их на работающем хосте, не сломав URL, которые уже знают пациенты и поисковые системы. Бриф этого проекта строился именно вокруг этого: защищённые паролем тестовые URL, карта редиректов на 18 строк и две очереди правок QA, сверенные до индексации любой новой страницы. ## Как мы это сделали **1. 11 шаблонов, сфокусированный объём, один процесс на действующем сайте.** Стандартная библиотека стоматологических шаблонов агентства включала Homepage, About Us, Services Lander, Service Page, Doctor Page, Blog Lander, Blog, Smile Gallery, Contact Us и Default Template. Объём разработки был намеренно узким: создать новые страницы услуг, страницы врачей и «О нас» на тестовых URL с noindex в существующей установке WordPress, назначив им шаблоны из строк карты сайта. Ни одной страницы не создавали вручную вне шаблонной системы. Разработка на защищённых паролем тестовых URL внутри рабочей установки — вместо отдельной тестовой среды — позволила избежать накладных расходов на миграцию с тестовой среды в рабочую для сфокусированной сборки из 3 страниц, ценой более строгой дисциплины редиректов на существующем списке URL. **2. Реструктуризация URL с дисциплиной редиректов по 18 уникальным парам.** Карта сайта содержала 18 строк «URL Change» — существующие страницы услуг перемещались с путей `/services/` на пути `/yorktown-heights/`. Мы согласовали каждую пару «старый → новый» в таблице редиректов и проверили соответствие на сайте клиента. Все 18 пар закрыли до индексации новых страниц. **3. Цикл исправлений и обратной связи на рабочей поверхности.** После начальной разработки агентство открыло раунды обратной связи через общую очередь правок. Задача #1230 (Review & Prioritize Backlog) и #1240 (Review Google Sheet Issues) охватывали предзапусковое QA по мета-данным, стилям кнопок, блокам FAQ и пробелам в контенте. Задача #1246 (Refresh 2 pages) — последующее обновление дизайна 2 страниц по локациям. Очередь правок SEO из 46 строк закрыта на 34 Completed (10 After Release, 1 To Do, 1 in QA); очередь правок CX из 3 строк закрыта на 1 Completed. **4. Проверка перед сдачей на сайте, который не мог упасть.** Перед сдачей мы выполнили проход QA перед сдачей через Site Checker — основные настройки, контент и SEO-покрытие, структура URL, очистка content-language по страницам и меню, скриншоты на нескольких устройствах. Для разработки на существующем сайте клиента важнее всего именно эти категории: корректность редиректов, согласованность слагов и точность мета-данных на обоих наборах URL — старом и новом. Проход подтвердил чистоту сборки до запуска собственного контура проверки агентства. Разработка на защищённых паролем тестовых URL внутри рабочей установки WP Engine — вместо отдельной тестовой среды — означала, что 18 пар редиректов нужно было проверить до индексации новых страниц, а не после. Этот порядок был ограничением. Цикл исправлений и обратной связи работал на основе уже чистого списка редиректов, поэтому очередь правок закрылась без регрессии URL после сдачи. ## Результаты Метрика Результат Новых страниц создано **Страница услуг (1) · Страницы врачей (несколько) · О нас (1)** на тестовых URL с noindex внутри существующего сайта клиента Шаблонов применено **11 / 11** из стандартной стоматологической библиотеки агентства Пар редиректов URL согласовано **18** уникальных пар со старых путей `/services/` на новые пути `/yorktown-heights/` Очередь правок SEO **34 / 46** закрыто как Completed; 10 After Release, 1 To Do, 1 in QA Очередь правок CX **1 / 3** закрыто как Completed; 1 In progress, 1 Info-Needed Контрольный список запуска **30 пунктов** согласованы по категориям Design / Functionality / Content / Pre-Migration / Post-Migration Сроки **38 дней** основная разработка (30 сен – 7 ноя 2025), с последующим обновлением дизайна 2 страниц Трудозатраты **39 ч / оценка 39 ч** — без перерасхода, без расширения объёма Сдача Сайт запущен на WP Engine, `https://www.nwdentist.com/` возвращает HTTP 200 Состояние сайта, проверено 2026-04 Сайт в работе, отвечает 200 — проверено в апреле 2026 Если коротко: агентство получило новые страницы на действующем окружении WP Engine, в пределах сметы в 39 часов. Восемнадцать старых URL перенаправили на новые постоянные ссылки, обе очереди правок QA проработали до уровня приёмки агентством, контрольный список запуска закрыли до индексации новых страниц. ## Контроль качества Внутреннее QA выявило две проблемы до сдачи: блок кириллицы в библиотеке шаблонов Elementor на этом англоязычном стоматологическом сайте (чат #1084, 2025-10-13 — очистка content-language) и несоответствие номера телефона в CTA-кнопках, где номер в футере и href кнопки вели на разные номера (чат #1246, 2025-10-28 — точность контента) — обе проблемы решены до того, как агентство увидело сборку. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порог нулевых ошибок. Приёмочный контур агентства работал после сдачи и вносил замечания в общую очередь правок для нашего цикла исправлений до согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня таблица Google Sheets просмотрена, доступ к тестовой среде подтверждён, 39 ч согласованы Разработка (новые страницы на тестовых URL) ~2 недели Страницы услуг, врачей и «О нас» созданы на тестовых URL с noindex; 18 пар редиректов URL согласованы Цикл исправлений ~2 недели Очереди правок SEO и CX проработаны параллельно; стили кнопок, блоки FAQ и пробелы в контенте устранены Последующее обновление дизайна 2 страниц ~1 неделя 2 страницы по локациям освежены по обратной связи от агентства Контрольный список запуска + сдача финальные дни Контрольный список из 30 пунктов согласован; новые страницы запущены в индекс _Этапы перекрываются — цикл исправлений начался до закрытия последних задач этапа разработки, поэтому календарный срок составляет 38 дней, а не сумму последовательных этапов._ ## Команда **Команда проекта** - **Павел Сажин** — итерации QA и исправления - **Анна Полунина** — поддержка реализации и QA - **Тимур Арбаев** — QA по проверке очереди правок и проверка обновления дизайна - **Людмила Травкина** — ведущий разработчик по разработке, согласованию редиректов и обновлению дизайна - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > На сайте стоматологической сети таксономия услуг и локаций задаёт структуру URL, от которой зависят ваши позиции в выдаче. У этой практики — сеть с отдельным каталогом услуг на каждый адрес; у других — один кабинет с единым списком услуг. Риски тихие: новая услуга на шестом месяце не впишется в URL-схему. Разметка Schema пропадёт при импорте и заберёт с собой расширенные результаты в выдаче. Страницы-фильтры по локациям выпадут из индекса. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы построите таксономию, чтобы следующая услуга встала без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим ваш URL-план с инвентарём ранжируемых страниц и отметим места, которые выстрелят на шестом месяце. Вернём смету с фиксированными часами. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-43-page-dental-89-days/ title: Доработка темы: 43 страницы для стоматологии за 89 дней type: case_study date: 2025-05-18T04:02:58+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 43 страницы нового сайта Ranieri Dentistry, реализованные по макетам Figma агентства на шаблоне Luminous — сборка до открытия, без существующего сайта и без номера телефона, с открытием в Bonita Springs, Florida в апреле 2026. Figma была единственным референсом; 16 шаблонов нужно было передать контент-команде в середине разработки, притом что QA параллельно шло по очереди задач из 472 пунктов. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая стоматология Конечный клиент Ranieri Dentistry — д-р Tanner Ranieri (Bonita Springs, Florida) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства Luminous + постраничные макеты Figma на Kinsta) Объём **43 URL** — главная, о нас, услуги, **26 страниц услуг** по пяти категориям (профилактика, терапия / общая, косметология, ортодонтия, неотложная помощь, холистика), страница врача, блог, галерея улыбок, контакты и 8 вспомогательных страниц (membership, финансирование, страховка, политики) Срок 89 дней (5 ноя 2025 – 2 фев 2026), в срок Затраты 53 часа — 23 ч разработка · 30 ч QA и циклы исправлений Команда 6 специалистов Шаблоны **16 переиспользуемых шаблонов** от агентства, все применены на 43 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · AutoQA агентства (телефон / ссылки / email / Content AI / визуальные проверки) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **472 отслеженных SEO + UX проблемы** согласованы в очереди задач агентства, контрольный список запуска из 74 пунктов **Ритм взаимодействия** 3 обращения от агентства · 1 закрыто до сдачи (1 открыто · 1 отложено) **Раунды проверки** ≈6 раундов **Контрольный список запуска** 74 пункта, согласован до переключения ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Ranieri Dentistry и цель — брендированный шаблон Luminous на Kinsta. Практика д-ра Tanner Ranieri готовилась к открытию в Bonita Springs, Florida: сайт нужно было собрать и подготовить к запуску до апреля 2026, без существующего сайта в качестве ориентира. Дизайн, контентный процесс и отношения с клиентом оставались у агентства. Наша задача: реализовать главную по Figma, распространить дизайн на все шаблоны страниц и поднять полную карту сайта из 43 URL — чтобы контент-команда агентства могла параллельно наполнять страницы, пока разработка ещё шла. Задача делилась на 2 уровня. Первый: собрать главную и по одному шаблону каждого типа — сигнал контент-команде начинать параллельную работу. Второй: довести до QA-чистого состояния полную таксономию услуг — 26 страниц по профилактике, терапии, косметологии, ортодонтии, неотложной помощи и холистике — к моменту запуска. Агентство вело всё в общей очереди задач; каждый пункт возвращался к нам на раунд исправлений и повторную проверку перед закрытием. Сборка до открытия устроена иначе, чем ребилд. При ребилде боевой сайт — это якорь: пропущенная страница или расхождение в контенте видны как отклонение от известной базы. При первом запуске базы нет — Figma единственный референс, и любой вопрос о соответствии дизайна упирается в «совпадает ли это с макетом, а не с предыдущим сайтом». Несовпадающий набор иконок, hero-изображение, отходящее от макета, шапка без фиксации при прокрутке — ничто из этого не всплывёт само по себе. Всё выходит только через цикл QA. В этом проекте AutoQA агентства (включавшая визуальную проверку через модель OpenAI на экранах 1920, 1280 и в эмуляции мобильных) добавила второй слой контроля визуального соответствия — он есть далеко не на каждом проекте типа «доработка темы». Очередь из 472 пунктов отражает именно такой QA-процесс: откалиброванный под первый запуск без предшествующего сайта для привязки. > **Контекст рисков.** Сборка до открытия не имеет рабочего сайта, который служил бы якорем для QA. При ребилде пропущенный элемент или расхождение в контенте видны как отклонение от известной базы. При первом запуске базы нет — Figma единственный референс, и любой вопрос о соответствии дизайна упирается в «совпадает ли это с макетом, а не с предыдущим сайтом практики». Цикл QA здесь — единственная защита: несовпадающий набор иконок, hero-изображение, отклоняющееся от спецификации, или шапка без фиксации при прокрутке остаются невидимыми, пока кто-то в цикле проверки их не найдёт. Таксономия из 43 страниц для практики, которая ещё не открылась — где сайт должен быть готов до апреля 2026 — не терпит урезанного прохода QA. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Figma для главной — цель сборки. Шаблон Luminous — холст. Первая сдача: главная по Figma, шрифты и стили разведены на все шаблоны через глобальную дизайн-систему. После утверждения главной на каждый шаблон собиралась одна репрезентативная страница — сигнал контент-команде начинать параллельную работу. Дизайн-решений мы не принимали. **2. Параллельный каркас шаблонов и передача контент-команде.** Агентство задало разделённый рабочий процесс: собрать шаблоны, передать контент-команде, продолжать сборку полного сайта параллельно. Шесть технических URL (membership, финансовая информация, страховка, политика конфиденциальности, условия использования, отказ от ответственности) требовали простого вторичного шаблона — hero-блок и текст на всю ширину. Структура несложная, но это была сознательно очерченная граница объёма, а не «доделаем потом». Каркас ушёл в той же волне, что и основные шаблоны, — чтобы работа контент-команды не зависела от порядка разработки. **3. Цикл QA в масштабе доработки темы.** 87 задач в Redmine, 472 строки в очереди агентства (236 SEO и 236 UX) — цикл QA на этом проекте был одновременно широким по охвату и детальным по фокусу. Повторяющиеся классы проблем: наборы иконок, не совпадавшие с Figma; hero-изображения, отходившие от дизайн-спецификации; шапка без фиксации при прокрутке; битые или отсутствующие ссылки; отсутствующие ресурсы клиента — фото врача, номер телефона, список страховок, — которые нужно было трактовать как намеренные заглушки, а не ошибки. Каждый пункт проходил триаж: одни закрывались сразу, другие откладывались до поступления ресурсов клиента, третьи закрывались через промежуточные состояния-заглушки — и каждый считался закрытым только после того, как проверяющий со стороны агентства подтверждал устранение замечания. **4. Доработка без дрейфа.** При всём объёме задач каждая правка оставалась в клиентских переопределениях Elementor. Общие компоненты шаблона Luminous не трогали. Ranieri Dentistry — не последний сайт, который агентство поднимет на этом шаблоне; 43 страницы для неё не должны вносить регрессии в общий слой, которые проявятся у следующего клиента. **5. Проверка на разных устройствах.** AutoQA агентства включала визуальную проверку на экранах 1920, 1280 и в эмуляции iPhone 15 — более тщательный контроль визуального соответствия, чем стандартные аудиты ссылок и email по отдельности. Наш Site Checker перед сдачей подтверждал корректность отображения на всех размерах экрана; последующие визуальные проверки агентства выявляли оставшиеся расхождения с макетом для цикла исправлений. Проблемы с контрастностью текста на фоне, обнаруженные ближе к концу проекта — текст сливался с hero-изображениями на отдельных блоках, — были прослежены до вёрсточных решений, которые проявлялись только на определённой ширине экрана, и закрыты в финальных раундах. Рабочего сайта не было, поэтому Figma оставалась единственным якорем QA — без базы для регрессионных проверок, без готовой страницы для сравнения. Это условие определяло всё: сборка должна была быть достаточно точной, чтобы цикл QA мог поймать несовпадающую иконку, незагрузившийся шрифт, шапку без фиксации при прокрутке. Очередь из 472 пунктов — это цена удержания такого стандарта на 43 страницах сайта, которого раньше не существовало. ## Контроль качества До сдачи QA в этом проекте не имел живого референса для привязки — Figma была единственным ориентиром, и цикл исправлений выявил именно то, что предсказывает такой контекст: изображение в hero, отклонявшееся от дизайн-спецификации (Redmine #2014), неверные наборы иконок на страницах услуг (#2017), шапка, не фиксировавшаяся при прокрутке (#2018), и контрастность текста на hero, потребовавшая трёх отдельных раундов исправлений. До сдачи QA выполнялся через **Site Checker** — см. [наш подход к QA](/site-checker/) с категориями и порогом нулевых ошибок. Внутренний контроль агентства работал после передачи и собирал замечания в общую очередь правок для нашего цикла исправлений вплоть до окончательного согласования. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **43** — 1 главная, 1 страница услуг, 26 страниц услуг, 1 страница врача, 1 о нас, 1 блог, 1 галерея улыбок, 1 контакты и 10 вспомогательных страниц (membership, финансирование, страховка, политики) Шаблонов применено **16 из 16** переиспользуемых шаблонов построено и развёрнуто на 43 страницах Контрольный список запуска **74 пункта** согласовано Проблем QA / SEO отслежено и решено **472** пункта согласовано в двух вкладках очереди задач агентства (236 SEO и 236 UX) Итераций QA в Redmine **62 из 87 задач (71 %)** отслежено на уровне итераций QA Срок **89 дней**, сдано в срок до открытия практики в апреле 2026 Затраты **53 часа** на разработку, QA и циклы исправлений Команда **4 специалиста** Хостинг Развёрнуто в среде шаблона Kinsta агентства Здоровье страниц при сдаче **37 из 43** URL на тестовой среде вернули HTTP 200 при аудите карты сайта (6 страниц ожидали контента на момент снимка) Если коротко: макет Figma агентства реализован на шаблоне Luminous на 43 страницах и 16 шаблонах за 89 календарных дней, в рамках оценки в 53 часа — и сдан до того, как практика, ещё не открывшаяся для пациентов, начала работу. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к шаблону подтверждён, объём согласован в 20 ч ядра Главная + каркас шаблонов ~1,5 недели Главная построена по Figma; по одной странице на шаблон передано контент-команде Доработка полного сайта ~3 недели Все 43 страницы реализованы на 16 шаблонах Итерации QA (параллельно) ~6 недель 62 раунда QA зафиксировано; каждый закрыт только после согласования агентством Интеграция ресурсов и финальные правки ~2 недели Фото врача, исправления иконок, правки контрастности, состояния-заполнители урегулированы _Разработка и QA шли параллельно — это характерно для доработки темы, где нет чёткой «фазы QA», закрывающейся однократно; цикл работает непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Евгений Карпов** — ведущий разработчик (сборка главной страницы, доработка полного сайта) - **Никита Тумашевич** — поддержка разработки (финальные правки и исправления иконок) - **Павел Сажин** — итерации QA и триаж проблем - **Тимур Арбаев** — раунды проверки QA - **Анна Полунина** — поддержка реализации и QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн, подготовка контента и коммуникация с конечным клиентом оставались в партнёрском агентстве на всём протяжении. Каждый запрос на доработку поступал через общую очередь задач агентства; конечный клиент нас не видел. Раунды QA закрывались только после того, как проверяющий со стороны агентства подтверждал устранение каждого замечания. ## Агентствам с библиотекой шаблонов > Когда агентство собирает сайт на готовом шаблоне, ключевой риск — потерять контроль над доработками при обновлении родительской темы. У этой практики — один филиал и стандартный набор услуг; у других — многофилиальная стоматологическая группа на общей бренд-системе. Тихие сбои начинаются уже после запуска: токены бренд-системы перестают подтягиваться в жёстко прописанные запасные значения, стоит клиенту поменять цвет; панель редактора ломается для нетехнического персонала, когда блок спрятан за отдельным кодом; доработки в дочерней теме тихо отваливаются при первом же обновлении от автора шаблона. Подрядчику стоит задавать не вопрос «соберёте ли сайт на шаблоне?», а вопрос «как именно вы защитите доработки при следующем обновлении?» Пришлите спецификацию текущего шаблона или макеты. Мы посмотрим, как устроены переопределения, отметим места, где очередное обновление шаблона молча перезапишет работу клиента, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-26-page-dental-59-days/ title: Доработка темы для стоматологии: 26 страниц за 59 дней type: case_study date: 2025-05-10T01:44:01+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 26 страниц доработки темы стоматологической клиники: 10 типов страниц шаблона Luminous — 13 страниц услуг по направлениям косметической и семейной стоматологии, 2 страницы врачей, галерея улыбок и вспомогательные страницы. Всё реализовано по постраничным макетам Figma на WP Engine. Агентство подготовило контент для каждой страницы из существующего сайта клиники и новых материалов; задача заключалась в точном следовании макетам Figma на обоих направлениях, не допуская отклонений в структуре из-за решений по наполнению. Шаблонная доработка даёт скорость и единообразие — но только если доработку вести строго. Команда, которая вольно трактует Figma, пропускает раунды QA или отходит от дизайн-системы шаблона, работает хуже, чем если бы собирала с нуля. ## Краткий обзор Поле Значение Сфера деятельности клиента Медицина — Стоматология (косметическая + семейная) Клиент SmilePro Dental (Dearborn, MI) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на WP Engine) Объём **26 URL** — главная, страница услуг, **13 страниц услуг** по направлениям косметической и семейной стоматологии, страницы врачей (2), «О нас», галерея улыбок, контакты, спецпредложения, адрес, блог, страховка, финансирование Сроки 59 дней (1 мая – 29 июня 2025), в срок Затраты 69 ч — разработка, итерации QA, управление проектом Команда 5 специалистов Шаблоны **10 переиспользуемых шаблонов** предоставлены агентством, применены на всех 26 страницах Технологии WordPress · Elementor · WP Engine hosting · дизайн по Figma · AutoQA агентства (проверка ссылок / email) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **78+ отслеженных проблем SEO и CX** согласованы в очереди задач агентства, 29 пунктов в контрольном списке запуска **Интенсивность** 78 задач от агентства · все закрыты к передаче (34 дня активной работы, 16.05.2025 – 18.06.2025) **Раунды проверки** ≈5 раундов за 59 календарных дней **Контрольный список запуска** 29 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало дизайн Figma для SmilePro Dental и доступ к своей брендированной шаблонной системе на WP Engine. Агентство подготовило sitemap силами SEO-команды, совместно с клиентом определило новое направление дизайна на основе шаблона Luminous и подготовило документацию по контенту для каждой страницы. Figma была авторитетной спецификацией дизайна — нам нужно было доработать шаблон строго по ней. Сборка из 26 страниц: часть контента брали с существующего сайта клиники, часть писалась заново. Агентство чётко обозначило, чего ждёт от исполнения: точно наложить шаблон на каждый макет Figma, фиксировать любые расхождения в контенте — не заполнять их наугад, — и вести цикл исправлений до тех пор, пока каждый пункт очереди задач не будет закрыт. Документация по контенту от агентства не всегда совпадала со структурой блоков Figma: блок, задуманный как карта с контактами, был передан с многострочным текстом под другими заголовками, а некоторые блоки на тестовой среде не имели аналогов ни в шаблоне, ни в Figma. Каждое такое расхождение нужно было отмечать и решать через общую очередь задач агентства, а не интерпретировать самостоятельно. Агентство знало о риске, который тихо ломает единообразие шаблонной сборки: контент из разных источников. У SmilePro Dental был действующий сайт с материалами, сгруппированными по старой структуре навигации — косметическая стоматология, семейная стоматология, общие услуги. Новая Figma перекладывала этот контент в шаблонную систему агентства с новыми структурами страниц и другой визуальной иерархией. Команда, которая переносит контент со старого сайта в новые блоки шаблона без сверки с Figma, закладывает структурные несоответствия, которые выплывут только на QA. У этого клиента были конкретные изображения из собственного архива и готовая галерея пациентов — поэтому сопоставление контента не было предварительным шагом: оно шло параллельно с доработкой на каждом раунде исправлений. > **Контекст рисков.** Когда контент стоматологической клиники разделён между старым сайтом и новыми документами агентства, а новый шаблон раскладывает его по направлениям косметической и семейной стоматологии с разной визуальной иерархией — типовой сбой выглядит так: блоки контента со старого сайта не вписываются в новые секции по Figma; расхождения между двумя направлениями обнаруживаются только на QA; цикл исправлений затягивается, потому что происхождение каждого блока не было зафиксировано до начала разработки. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача заключалась в постраничном согласовании: где стандартная раскладка шаблона совпадала с Figma, мы её сохраняли; где Figma требовала отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны. **2. Сопоставление источников контента перед разработкой.** Страницы услуг SmilePro Dental делились на две категории: страницы, контент для которых поступал из структурированных документов агентства, и страницы, источником которых был существующий сайт клиники. Перед разработкой по каждой странице мы подтверждали происхождение контента: существующий сверяли со структурой блоков Figma, расхождения отмечали агентству, а не забивали стандартным текстом шаблона. Разделение на косметическую и семейную стоматологию в таксономии услуг клиники диктовало это правило: блок контента, работающий на странице косметической стоматологии (виниры, импланты, отбеливание), не подходил бы для страницы семейной стоматологии (коронки, мосты, эндодонтия) без соответствующей адаптации. **3. Цикл QA по направлениям косметической и семейной стоматологии.** В общей очереди задач агентства накопилось 78+ пунктов по категориям SEO и CX, согласованных по 29-пунктовому контрольному списку запуска. После передачи QA агентства отмечало проблемы с meta, изображениями и блоками контента в обоих направлениях; каждый раунд закрывался только после подтверждения проверяющего со стороны агентства. Двухтрековая структура услуг означала, что исправление на одной странице косметической стоматологии нужно было проверить на единообразие по всем страницам этого направления — регрессия, которую легко упустить в сборке из 13 страниц услуг 2 разных типов. **4. Доработка без дрейфа.** Каждое изменение брендированного шаблона — расположение, компонент секции, стилевой токен — применялось в слое переопределений под конкретного клиента. Общий шаблон Luminous агентства не модифицировался. Это важно в мультитенантной среде WP Engine, где другие клиники работают на той же базе: двухтрековая доработка SmilePro Dental не затронула общие компоненты шаблона. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на компьютере, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд охватывал только страницы, затронутые изменениями этого раунда, что позволяло держать циклы короткими даже при полной очереди задач. На протяжении всего проекта то и дело возникал контент, структура которого расходилась с Figma: блок карты с контактами, где агентство прислало длинный текст, — и секция FAQ, которую пришлось убрать в процессе. Каждое расхождение уходило в общую очередь задач, а не решалось на своё усмотрение — именно это удержало оба направления, косметическое и семейное, в согласованном состоянии на протяжении пяти раундов QA. ## Контроль качества Блок карты с контактами на тестовой среде содержал длинный текст там, где в Figma был CTA — так было построено по документам агентства, поэтому несоответствие выявилось на первом же проходе QA, а не ушло в передачу; задача SEO QA также отметила неоднозначность с дублированием URL в строке 9 общей очереди задач, для разрешения которой потребовались уточнения от агентства. QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Контроль на стороне агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до согласования. Доработки оставались в клиентских переопределениях; общие компоненты шаблона агентства не модифицировались. ## Результаты Метрика Результат URL сдано **26** — 1 главная, 1 страница услуг, 13 страниц услуг (косметическая: импланты, виниры, бондинг, Invisalign, Invisalign vs брекеты, отбеливание; семейная: эндодонтия, профилактика, мосты, коронки; + спецпредложения, страховка, финансирование), 2 страницы врачей, 1 «О нас», 1 контакты, 1 галерея улыбок, 1 блог, 1 страница адреса Шаблонов применено **10 из 10** переиспользуемых шаблонов собраны и сопоставлены для 26 страниц Контрольный список запуска **29 пунктов** согласовано Проблем QA / SEO / CX отслежено и решено **78+** пунктов согласовано в двух вкладках очереди задач агентства Итерации QA в Redmine **2 из 10 задач** формально отмечены QA; раунды исправлений продолжались до закрытия задачи после запуска Сроки **59 дней**, сдано в срок Затраты **69 ч** — без перерасхода, без расширения объёма Команда **5 специалистов** Хостинг Работает в среде шаблонов WP Engine агентства Здоровье страниц при передаче Sitemap тестовой среды подтверждён по всем 26 URL перед передачей Если коротко: Figma агентства реализована в их брендированном шаблоне на 26 страницах и 10 шаблонах за 59 календарных дней, в рамках оценки в 69 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma рассмотрена, доступ к шаблону подтверждён, согласованы sitemap и стратегия источников контента Доработка ~2 недели Постраничная доработка шаблона; направления косметической и семейной стоматологии разрабатывались параллельно Итерации QA (параллельно) ~5 недель Очередь задач агентства сокращена до нуля по 78+ пунктам SEO и CX Раунды исправлений ~1 неделя Коррекции после передачи: обновление изображения на главной, правки вкладок CX Сдача последний день Сайт запущен на WP Engine _Разработка и QA шли параллельно — это характерно для доработки темы: ни один «этап QA» не закрывается окончательно; цикл идёт непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и сопоставление макетов Figma с шаблоном) - **Павел Сажин** — ведущий QA (проверка очереди задач, координация с агентством) - **Анна Полунина** — поддержка доработки темы и QA - **Евгений Карпов** — разработчик (доработки SEO QA, исправления CX после передачи) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство поддерживало отношения с конечным клиентом на всём протяжении. Все запросы на доработку поступали через общую очередь задач агентства; SmilePro Dental не взаимодействовала с нашей командой напрямую. Каждый раунд исправлений выпускался только после подтверждения проверяющего агентства, что изменения соответствуют спецификации. ## Агентствам с библиотекой шаблонов > Брендированная шаблонная система обещает единообразие. Раньше всего оно ломается на границе между стандартами шаблона и переопределениями клиентского слоя. У этой клиники 1 кабинет с шаблоном под косметическую и семейную стоматологию; у других — сеть клиник с 1 шаблоном на десяток самостоятельных брендов. Риски: обновление шаблона тихо затирает собственные раскладки блоков, перенесённый контент попадает не в то направление услуг, а правки нетехнических сотрудников ломают наследование шаблона. Подрядчику стоит задавать не вопрос «соберёте ли вы страницы из шаблона», а вопрос «как именно вы ограничите переопределения клиентского слоя, чтобы следующее обновление их не снесло». Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы сверим ваши переопределения с правилами отображения шаблона, укажем точки, где обновление тихо их откатит, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-homepage-redesign-legal-elementor-31-days/ title: Редизайн главной страницы для юридической фирмы — Figma в Elementor Pro type: case_study date: 2025-05-05T00:33:13+00:00 case_industry: Юридические услуги case_type: Редизайн case_practice: wordpress --- ## Подход к редизайну Редизайн главной страницы из Figma в Elementor Pro на сайте с WPBakery: страницу собрали в черновике и не публиковали, пока её не согласовал руководитель агентства. Бриф был однозначен — Elementor Pro, разработка в черновике. Сложность всплыла, когда новый глобальный хедер и футер Elementor применили ко всему сайту: Elementor погасил стили WPBakery и ненадолго уронил сайт. Мы восстановили резервную копию, устранили конфликт и заново раскатили глобальные хедер и футер — уже до проверки агентством. ## Краткий обзор Поле Значение Отрасль конечного клиента Юридические услуги — травмы и несчастные случаи Конечный клиент The Stein Law Group (юридическая практика по делам о травмах и несчастных случаях, NY metro) **Формат сотрудничества** **White-label редизайн главной страницы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Редизайн главной страницы Figma в Elementor Pro — собран в черновике, опубликован после проверки руководителем агентства Объём работ **1 главная страница** — полный редизайн по Figma агентства, создан в WordPress-черновике, запущен после раунда проверки руководителем агентства Сроки 31 день (20 ноя – 20 дек 2025), по графику Трудозатраты **~15 ч** — ~7,7 ч разработка · ~7,7 ч QA в 2 раунда · остаток на реализацию после проверки Команда 4 специалиста (разработка + QA + руководитель проекта) Передача дизайна макет в Figma (принадлежит агентству; URL дизайна не публикуется) — в согласованном брифе явно требовались Elementor Pro и доставка в черновике Технологический стек WordPress · Elementor Pro · существующий WordPress-хостинг агентства · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Режим разработки** **Сначала черновик** — новая главная страница создавалась как WordPress-черновик параллельно с действующим сайтом, без публичного показа в процессе **Выполнено** **Редизайн главной страницы передан по спецификации, один раунд замечаний руководителя агентства реализован и запущен, сайт работает на thesteinlawgroup.com** **Раунды проверки** ≈3 раунда проверки за 31 календарный день ## Постановка задачи Маркетинговое агентство из США, работающее с The Stein Law Group — юридической практикой по делам о травмах и несчастных случаях в NY metro — передало нам новый дизайн главной страницы в Figma с двумя явными ограничениями: реализация должна быть в Elementor Pro (уже установлен на сайте клиента), а разработка должна выполняться в черновике, а не на рабочей главной странице. Обоснование было прямым. Юридические фирмы крайне чувствительны к правкам на действующем сайте: случайный сдвиг в формулировках исков, описании результатов дел или дисклеймерах создаёт юридические и репутационные риски, которых у стоматологической практики нет. Агентство хотело, чтобы дизайн собрали параллельно с действующим сайтом, проверили внутри, а затем ещё раз проверил руководитель агентства — до любой публикации. Задача была чёткой: воспроизвести Figma в Elementor Pro, сдать черновик, отработать раунд замечаний руководителя агентства по финальной проверке и опубликовать страницу только после её подписи. Всё это — не выходя на прямой контакт с конечным клиентом. > **Контекст рисков.** На главной странице юридической фирмы цена каждого пикселя необычно высока. Каждое утверждение на экране — описание результатов дел, язык юрисдикции, дисклеймеры о рекламе адвокатских услуг — несёт юридическую нагрузку. Редизайн ни разу не уходил в публикацию, пока руководитель агентства его не проверил и не подписал. В любой момент разработки на действующем сайте стояла либо неизменённая исходная версия, либо полностью проверенная новая — наполовину готового гибрида не было никогда. Работа через черновик здесь не процессная вежливость, а контрактно значимый порог, который защищает агентство от инцидента на сайте постоянного юридического клиента. ## Как мы это сделали **1. Figma в Elementor Pro, сначала черновик.** Главную страницу полностью создали в Elementor Pro по утверждённым макетам Figma — hero-блок, разделы услуг, отзывы, призыв к действию с контактами, футер. Поскольку Elementor Pro уже был установлен на сайте, разработка встроилась в существующую тему и систему глобальных стилей без добавления нового конструктора страниц. **2. В черновике, не в публикации.** Новую главную страницу разместили как WordPress-черновик параллельно с действующей главной. Каждый QA-проход шёл по черновику вплоть до запуска. Эту защитную меру агентство запросило специально для такого типа проекта и такой отрасли клиента: юридическая практика не может позволить, чтобы наполовину готовая главная попала в публикацию посреди QA. Принцип прост: при редизайне главной страницы юридической фирмы команда разработки по умолчанию работает через черновик. Стоматологический или ресторанный сайт терпит публикацию без полной проверки; юридическая фирма — нет. **3. 2 внутренних раунда QA до передачи агентству.** QA провели трое разработчиков — Павел, Тимур и Антон — на большом экране и на мобильных, выловив обычные артефакты переноса Figma в Elementor: Elementor Pro отрисовывает часть отступов иначе, чем автоматическая раскладка Figma; цели ссылок требовали проверки; блок формы нужно было подключить к Gravity Forms. **4. Раунд после проверки — замечания руководителя, затем запуск.** После проверки агентства руководитель передала конкретный набор замечаний по черновику. Их реализовали в отдельной задаче-продолжении («Implement Linda’s Comment & Launch Page»), и страницу опубликовали после финального согласования с агентством. Ещё 1 раунд QA с 3 разработчиками проверил состояние после запуска. Главным источником сложности стал конфликт конструкторов страниц: глобальный хедер и футер Elementor Pro, применённые ко всему сайту, погасили стили WPBakery и ненадолго уронили сайт. Резервную копию мы восстановили сразу, конфликт устранили отдельно, а раскатку запустили повторно — уже чисто. Новая главная ни разу не висела черновиком на наполовину рабочем сайте, поэтому инцидент закрылся раньше, чем агентство его увидело. ## Контроль качества QA перед передачей поймал, что черновик новой главной случайно опубликовали — вопреки явному требованию брифа держать страницу в WordPress-черновике и закрытой от индексации. Страницу сразу вернули в статус черновика до проверки агентством. Виджет отзывов Trustindex по ходу разработки тоже ломал вёрстку — поправили в том же QA-проходе. QA перед передачей проходил через **Site Checker** — категории и порог нулевых ошибок описаны в разделе [наш подход к QA](/site-checker/). Контур проверки агентства запускался после передачи и заводил оставшиеся вопросы в общую очередь правок для нашего цикла исправлений, пока агентство не подписывало приёмку. ## Результаты Метрика Итог Редизайн главной страницы Выполнен — Figma реализована в Elementor Pro, заменив предыдущую главную страницу Режим разработки **Сначала черновик** — новая главная страница создана как WordPress-черновик параллельно с действующим сайтом, без публичного показа в процессе Раунды QA **2 внутренних + 1 после запуска** — Павел, Тимур и Антон прошли большой экран + мобильные устройства в каждом раунде Проверка после сдачи 1 раунд — замечания руководителя реализованы в задаче «Implement Linda’s Comment & Launch Page»; запущено после согласования с агентством Сроки **31 день** (20 ноя – 20 дек 2025), выполнено по графику Трудозатраты **~15 ч** — примерно поровну разработка и QA, характерный профиль для редизайна одной страницы Команда 4 специалиста — без отдельного аналитика, без дизайн-лида (принадлежит агентству), без SEO-лида (объём миграции отсутствует) **Статус сайта** Работает, открывается по адресу https://thesteinlawgroup.com/ — проверено в апреле 2026. Если коротко: Figma агентства реализована в Elementor Pro в черновике, проверена дважды внутренней командой, доработана один раз по замечаниям руководителя агентства и опубликована — всё это за 31 календарный день и около 15 часов работы. ## Процесс Фаза Продолжительность Результат Бриф и оценка ~2 дня Figma проверена, Elementor Pro подтверждён, модель доставки в черновике согласована Разработка главной страницы (черновик) ~1 неделя Полная главная страница реализована в Elementor Pro в WordPress-черновике Внутренний раунд QA 1 ~2 дня Павел + Тимур + Антон против большого экрана + мобильных устройств; артефакты зафиксированы Проверка после сдачи — замечания руководителя ~1 неделя Замечания руководителя агентства зафиксированы; задача на реализацию открыта и закрыта Запуск + раунд QA 2 ~1 неделя Страница опубликована; QA после запуска с 3 разработчиками закрыт _Фазы пересекаются — QA начался до того, как черновик был функционально завершён, а раунд проверки после сдачи был открыт в тот же день, когда закрылся первый внутренний QA. Это характерно для небольших редизайнов, где QA-цикл работает непрерывно, а не в отдельной фазе._ ## Команда **Команда проекта** - **Никита Тумашевич** — разработка главной страницы в Elementor Pro по Figma - **Павел Сажин** — QA в обоих раундах и поддержка реализации после проверки - **Тимур Арбаев** — QA в обоих раундах и поддержка реализации после проверки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, координация после проверки, согласование) Управление проектом, дизайн и коммуникация с клиентом со стороны агентства оставались за партнёрским агентством на протяжении всего проекта. Наша команда оставалась невидимой для конечного клиента. Замечания руководителя агентства по итогам проверки были переданы нам, реализованы и возвращены на её подписание. ## Агентствам, заказывающим редизайн WordPress > При редизайне сайта юридической фирмы реальный риск для вас, агентства, — черновик с несогласованными формулировками по делам, который доезжает до боевого URL. У одной практики это страницы конкретных дел с дисклеймерами; у другой — общая база урегулированных исков на несколько адвокатов. Сбои тихие и конкретные: черновик уходит из тестовой среды неутверждённым; визуальные токены обновляют хедер, а архивы практик остаются на старой палитре; новые карточки рассчитаны на текст, который не совпадает с реальными дисклеймерами клиента, — и страница ломается уже на опубликованном сайте. Спрашивать подрядчика стоит не «успеете ли обновить интерфейс», а «как именно вы закроете каждый переход страницы, чтобы ни один неутверждённый черновик не вышел на публичный URL». Пришлите макеты и текущий перечень URL. Мы наложим новые раскладки на страницы, которые реально ранжируются, найдём места, где предположения редизайна расходятся с опубликованным контентом, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-81-pages-19-days/ title: Ребилд WordPress-сайта стоматологической клиники — 81 страница, поставлена по спецификации за 19 дней type: case_study date: 2025-05-01T19:48:58+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 81 страница стоматологического сайта на WordPress, сведённая в 10 шаблонов и собранная строка за строкой по таблице Google Sheets агентства: каждый URL перенесли, каждый мета-заголовок сохранили, каждый 301-редирект реализовали. Сборку поставили за 19 дней в рамках 50 часов, краулером сверив новый сайт с исходным до переключения DNS. Год спустя сайт продолжает работать и обслуживает ту же практику в Porterville, Калифорния. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология — общая и эстетическая практика Конечный клиент Live Oak Dental (Dr. Richard Hardt DDS, Porterville, CA) **Формат сотрудничества** **White-label WordPress-ребилд для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта WordPress-ребилд с Elementor Pro на WP Engine Объём работ Весь сайт — услуги, биографии врачей, блог, галерея улыбок Сроки 19 дней (24 февр. – 15 марта 2025), в срок Трудозатраты 50 часов при оценке 50 часов — без перерасхода Команда 3 специалиста (40 ч разработка · 5 ч PM · 4 ч правки · 1 ч внедрение SEO) Технологический стек WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) Сверка контента Разницу исходника и ребилда устранили до передачи: пропавшего текста, битых внутренних ссылок и структурных расхождений не нашли **Поставка** **Спецификация выполнена строка за строкой — 80 редиректов, 81 мета-заголовок, 45-пунктный контрольный список запуска** **Ритм взаимодействия** 12 задач, поставленных агентством · 11 из 12 закрыты к передаче **Раунды проверки** ≈2 раунда проверки за 19 календарных дней **Контрольный список запуска** 45 пунктов, согласованы до переключения ## Постановка задачи У агентства был постоянный клиент — стоматологическая практика, чей действующий WordPress-сайт нуждался в ребилде: современный конструктор страниц, надёжные формы, аккуратная система шаблонов. Агентство уже провело подготовительную работу: таблица Google Sheets содержала каждый URL для переноса, каждый мета-заголовок и мета-описание для сохранения, каждый шаблон для реализации и 45-пунктный контрольный список до- и послемиграционного запуска. Задача была конкретной. Принять спецификацию как данность; пересобрать сайт на Elementor Pro; вернуть готовым к переключению. Оставаться вне клиентской коммуникации. Реализовать SEO-решения так, как написано. Уложиться в заявленные часы. Риск, от которого агентство страховалось, — не обрушение SEO: с этим они разобрались самостоятельно. Риск был в том, чтобы не отдать сборку команде, которая будет молча импровизировать вместо следования брифу: пропущенный редирект, переинтерпретированный шаблон, «незначительная» правка мета-заголовка, перерасход бюджета, сдвиг даты запуска. > **Контекст рисков.** Когда сайт работающей стоматологической практики меняет платформу — даже при ребилде внутри той же CMS — каждый URL, уже находящийся в индексе, каждая внутренняя ссылка, по которой ходят пациенты, каждый редирект, тщательно прописанный агентством, становится потенциальной жертвой команды разработчиков, которая импровизирует вместо того, чтобы исполнять. Режим отказа здесь не катастрофический — он тихий. Пропущенный редирект. Мета-заголовок, слегка перефразированный. Форма, переподключённая иначе. Каждый из этих моментов защищаем по отдельности; вместе они разрушают спецификацию, на которую агентство поставило репутацию. ## Как мы это сделали **1. Сборка по шаблонному принципу.** Вместо того чтобы пересобирать 81 страницу по одной, мы свели их в десять переиспользуемых шаблонов и уложили каждую страницу в них: - Главная, О нас, Контакты и шаблон Default как запасной - **Лендинг услуг + единый шаблон страницы услуги**, обеспечивающий 20 страниц услуг по четырём категориям (профилактическая, восстановительная, эстетическая, стоматология повышенной сложности) - **Страница врача** — индивидуальные биографические страницы - **Лендинг блога + Пост блога** — шаблоны - **Галерея улыбок** — специализированный шаблон «до/после» для практики 10 шаблонов — и весь сайт собран. Будущие правки на стороне агентства живут в одном месте для каждого типа страниц. **2. Спецификация выполнена строка за строкой — по таблице агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для переноса с целевым путём, каждый мета-заголовок и мета-описание для переноса, каждое назначение шаблона, каждая клиентская интеграция (GA / GA4 / GTM, reCAPTCHA, кеш Nitropack). Мы реализовали каждую строку так, как написано. Где в таблице было значение — оно появлялось на новом сайте. Где не было — мы возвращали вопрос агентству. Никаких «творческих интерпретаций» в поставку не попало. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработчиков — защищать этот контракт, а не редактировать его. **3. Сверка краулером, а не «на глаз».** До переключения DNS мы прогнали Screaming Frog по действующему сайту и по сборке на тестовой среде одновременно. Статус-коды, битые ссылки, цепочки редиректов, расхождения мета-тегов — каждое расхождение сверили с таблицей агентства. Повторный прогон после запуска подтвердил: каждая внутренняя ссылка открывается на рабочем домене. **4. 45-пунктный контрольный список запуска, закрытый до передачи.** Семь категорий: дизайн, функциональность, контент, SEO и аналитика, адаптивность, клиентские интеграции и 12-шаговая миграция Domain & DNS на WP Engine. Ничего не отдавали, пока не согласовали каждую строку. Кросс-браузерный QA на Chrome / Firefox / Safari / Edge и шести форматах экрана (1920 / 1280 / 1024 / iPad / мобильный вертикально / мобильный горизонтально). Контактная форма (Gravity Forms) протестирована сквозным сценарием с реальной отправкой. Сжатые 19 дней означали, что проверку мета-данных пришлось вынести в отдельный формальный проход, а не оставлять на потом. Каждый мета-заголовок и мета-описание сверяли с исходником — посты блога без описаний находили и заполняли, регистр сохраняли по спецификации агентства — прежде чем сборка уходила на переключение DNS. В 19 дней уложились, потому что проверку мета вели параллельно с финальным QA, а не после него. ## Результаты Метрика Итог Соответствие спецификации — редиректы **80 / 80** URL контента перенаправлены, как указано Соответствие спецификации — мета-данные **81 / 81** мета-заголовок и мета-описание размещены, как указано Соответствие спецификации — шаблоны **10 / 10** шаблонов собраны и применены по всему сайту Контрольный список запуска **45 / 45** пунктов согласованы до переключения Сроки **19 дней**, поставлено в срок Трудозатраты **50 ч / 50 ч** оценки — без перерасхода, без расширения объёма Адаптивная проверка Ноль проблем с вёрсткой в 4 браузерах × 6 форматах экрана Внутренний QA Все задачи в зоне ответственности агентства закрыты до передачи (6 из 12 выявлено; 6 заблокированы конечным клиентом или вне зоны агентства) **Статус сайта** Работает на WP Engine, открывается по адресу https://www.drhardt.com/. Если коротко: спецификацию агентства собрали так, как написано, в рамках заявленных часов, в запланированный день переключения. Год спустя сайт продолжает работать. ## Контроль качества Сверка перед сдачей выявила отсутствующие мета-описания в постах блога и расхождения мета-заголовков по всем страницам — оба пункта зафиксировали как приоритетные в очереди правок и устранили отдельным проходом, прежде чем агентство увидело финальную сборку на тестовой среде. QA перед сдачей шёл через **Site Checker** — категории и порог нулевых ошибок описаны в [нашей методике проверки](/site-checker/). Проверка на стороне агентства шла после сдачи и вносила оставшиеся вопросы в общую очередь правок, пока агентство не согласовало результат. ## Процесс Фаза Продолжительность Результат Бриф и оценка 1 день Спецификация агентства изучена; 50 ч согласованы Разработка ~13 дней Весь сайт пересобран по 10 шаблонам Внутренний QA и проверка 2 дня 12 задач зафиксированы; вся работа в зоне агентства закрыта Проверка спецификации 1 день Соответствие мета и редиректов сверено с таблицей Поставка и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Фазы пересекаются (QA шёл параллельно с поздней разработкой), поэтому суммарный срок — 19 дней, а не сумма отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Павел Сажин** — QA-правки и внедрение мета-данных - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на протяжении всего переключения и миграции. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль — точное исполнение поставленной ими спецификации. ## Агентствам, заказывающим ребилд WordPress > Ребилд сайта стоматологической практики — это не смена дизайна, а перенос редиректов, позиций и конверсий, которые агентство выстроило в выдаче. У этой практики — локальная стоматология с одним адресом; у других — сеть на несколько адресов с единой CRM. Риски тихие: в карте редиректов потеряются строки — старые URL, под которые вы выстроили позиции, начнут отдавать 404. Мета-заголовки и описания тихо перепишутся новой темой — сниппеты в выдаче меняются за ночь. Готовая интеграция с CRM-стеком агентства сломается — форма записи не отправит лид, а вы узнаете постфактум. Вам стоит задавать не вопрос «выполните ли ребилд», а вопрос «как именно вы удержите редиректы, мета-поля и готовые интеграции от тихой поломки при переходе?» Пришлите адрес действующего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим план ребилда с текущей схемой: найдём строки, где редиректы выпадут, мета-поля перепишутся, а интеграции сломаются. Вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-38-page-dental-112-days/ title: Доработка темы для стоматологии: 38 страниц — 112 дней type: case_study date: 2025-04-29T01:38:31+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 38 страниц доработки темы для стоматологической клиники — 40 дизайн-макетов страниц: 10 сервисных страниц, охватывающих общую, косметическую, восстановительную стоматологию, импланты, элайнеры, детскую стоматологию, неотложную помощь, пародонтологию, терапию сна и ВНЧС — все созданы по постраничным макетам Figma на Kinsta с собственной типографикой бренда (QUENTIN cursive, ALTONE print). Агентство подготовило контент для каждой страницы; половина страниц поступила с пробелами, которые обнаружились на первом QA-обзоре — потребовался повторный проход, прежде чем очередь правок удалось закрыть. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. Доработка темы по Figma агентства, где главным индикатором качества стал длинный хвост раундов исправлений, а не первоначальная сборка. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — общая стоматология Конечный клиент Maple Glen Modern Dentistry (стоматологическая клиника в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированная тема агентства + постраничный дизайн Figma на Kinsta) Объём **38 URL** — главная, лендинг услуг, 10 страниц услуг, лендинг новых пациентов, 3 страницы для новых пациентов, галерея улыбок, блог, отзывы, контактный лендинг, 2 контактные страницы и 16 вспомогательных страниц Сроки 112 дней (13 июня – 3 окт 2025), по графику Затраты труда 55 часов — разработка, QA-итерации и управление проектом Команда 6 специалистов Шаблон Брендированная система тем агентства, доработанная под все 38 страниц Технологии WordPress · Elementor · Kinsta хостинг · постраничный дизайн в Figma · очередь правок агентства · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **240+ отслеженных SEO и CX проблем**, согласованных в очереди правок агентства по 30-позиционному контрольному списку запуска **Режим работы** 83 задачи от агентства · 78 из 83 закрыты к передаче (активная фаза 109 дней, 2025-06-30 – 2025-10-16) **Раунды проверки** ≈11 раундов проверки за 112 календарных дней **Контрольный список запуска** 30 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам дизайн Figma для Maple Glen Modern Dentistry и цель развёртывания на своей брендированной системе тем на Kinsta. Агентство уже выполнило вышестоящую работу: приёмку клиента, аудит дизайна, сбор контента через Google Docs для каждой страницы, настройку хостинга. Им нужен был партнёр-разработчик, который доработает тему в точном соответствии с Figma и выдержит цикл обратной связи на всём протяжении процесса проверки агентства. Объём был понятен, сроки — открыты: 38 страниц с полной таксономией услуг стоматологической клиники, каждая со своим макетом Figma, доработанная в системе тем агентства и возвращаемая на проверку раунд за раундом. Оценка в 55 часов покрывала сборку; 112 дней ушли на проверки и правки. Агентству нужно было избежать не единичного срыва поставки, а ситуации, когда команда делает первоначальную доработку и после этого перестаёт выходить на связь по длинному хвосту правок. Шаблонная сборка из 38 страниц с очередью правок на 240 пунктов за один проход не сдаётся; нужна команда, которая вернётся на шестой раунд замены изображений, на девятый раунд корректировки виджетов и на финальный проход на 2 пункта через 2 месяца после первой сдачи. Именно эта устойчивая доступность — а не первоначальная сборка — защищает отношения агентства с клиентом и гарантирует, что очередь правок закроется, а не застрянет. Агентство решило опубликовать сайт как черновик с заглушками на страницах, ожидающих контент от клиента (биографии команды и отзывы), а не задерживать цикл запуска ради полного пакета контента — последовательное решение, позволившее разделить сроки сборки и готовность контента. > **Контекст рисков.** Сборка на 38 страниц с 240+ отслеженными проблемами за 112 дней — это не риск завершения, а риск отклика. Слабое место не в том, что команда строит не то; слабое место в том, что команда правильно делает первоначальную доработку, а затем с каждым месяцем всё дольше возвращает раунды исправлений. Агентство, у которого после первой сдачи зависла очередь правок, отвечает за этот пробел перед своим клиентом. 10 QA-итераций, зафиксированных на этом проекте, отражают устойчивое взаимодействие, а не нестабильность. Не все пункты очереди правок удалось разрешить в рамках сотрудничества — несколько строк CX, касающихся PDF-форм, полей формы записи и маршрутизации email контактной формы, были отложены как улучшения после запуска, поскольку соответствующие данные или одобрение клиента ещё не были доступны на момент передачи. ## Как мы это сделали **1. Figma как контракт, тема как холст.** Файл Figma был дизайн-спецификацией. Брендированная тема — базовой структурой страниц. Наша задача была согласовать их постранично — где стандартный макет темы совпадал с Figma, мы его оставляли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не исходили от нас. **2. QA-цикл в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, исправить, проверить, исправить». Из 14 задач, отслеженных на этом проекте, 10 были QA или итерациями исправлений — отдельные раунды, где агентство отмечало расхождения в дизайне, пробелы в контенте или пункты очереди правок, мы проверяли, исправляли и возвращали сборку на очередную проверку. За этими раундами стояло гораздо более масштабное согласование: агентство отследило 240+ пунктов в двух вкладках очереди правок (83 SEO-замечания и 159 CX-замечаний), из которых 235 были отмечены как выполненные к моменту передачи. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без расползания.** Каждое изменение в брендированной теме — будь то макет страницы, компонент секции или стилевой токен — мы документировали относительно Figma. Ни одна доработка не проникла в общие компоненты темы — это значит, что работа по данному проекту не ухудшила тему для следующего сайта. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных — стандартный набор точек адаптации агентства. Каждый QA-раунд охватывал страницы, затронутые дизайн-расхождениями данного раунда, а не весь сайт — так сборка на шаблоне остаётся экономной, не теряя покрытия. 10 QA-раундов за 112 дней, каждый закрывался только после подтверждения агентства перед открытием следующего прохода. Именно этот ритм — а не первоначальная сборка — обеспечил движение 240+ пунктов очереди правок: ничего не считалось решённым, пока агентство не подтверждало, что означает: проект завершился без остаточной очереди, которую агентству пришлось бы разгребать самостоятельно. ## Контроль качества Предварительный QA на первоначальной сборке выявил схему URL с двойным слешем (`//services/general-dentistry`), доступную на сайте тестовой среды — sitemap агентства использовал пути с одинарным слешем, поэтому вариант с двойным слешем был отмечен, исследован и задокументирован до первой передачи с указанием решения в журнале исправлений. Предварительный QA проводился через **Site Checker** — см. [наш подход к QA](/site-checker/) и порог нулевых ошибок. Приёмочный контур агентства проводился после передачи и фиксировал замечания в общую очередь правок для нашего цикла исправлений до их согласования. Доработки оставались в файлах настроек конкретного клиента; общие компоненты темы агентства не модифицировались. ## Результаты Метрика Результат URL сдано **38** — 1 главная, 1 лендинг услуг, 10 страниц услуг, 1 лендинг новых пациентов, 3 страницы для новых пациентов, 1 галерея улыбок, 1 блог, 1 страница отзывов, 1 контактный лендинг, 2 контактные страницы и 16 вспомогательных страниц Контрольный список запуска **30 пунктов** согласованы QA / SEO + CX проблемы отслежены и решены **240+** пунктов согласовано в двух вкладках очереди правок агентства (83 SEO + 159 CX), 235 отмечены как выполненные при передаче QA-итерации Redmine **10 из 14 задач** отслежены на уровне итераций Сроки **112 дней**, сдано по графику Затраты труда **55 часов** при оценке 55 часов — без перерасхода, без расползания объёма Команда **6 специалистов** Хостинг Запущен в среде темы агентства на Kinsta Состояние страниц при передаче **33 / 33** отслеженных URL тестовой среды вернули HTTP 200 в аудите sitemap Если коротко: Figma агентства реализована в их брендированной теме на 38 страницах, за 112 календарных дней, в рамках оценки в 55 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma проверена, доступ к теме подтверждён, объём согласован Разработка доработок ~2 недели Постраничная доработка темы под Figma QA-итерации (параллельно) ~14 недель 10 QA-раундов; каждый закрыт только после согласования агентством Раунды исправлений ~2 недели Коррекции после проверки, замена изображений, обновление виджетов Сдача финальный день Сайт запущен на Kinsta _Разработка и QA шли параллельно — это характерно для работы по доработке темы, где ни один «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и сопоставление Figma с макетом) - **Павел Сажин** — QA-итерации и исправления - **Анна Полунина** — разработчик (раунды доработки и внедрение исправлений) - **Евгений Карпов** — поддержка разработки - **Тимур Арбаев** — проверка соответствия дизайна и предварительный QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороны агентства, согласование) Агентство управляло всеми взаимодействиями с клиентом. Maple Glen Modern Dentistry с нашей командой напрямую не работала — каждый запрос шёл через общую очередь правок агентства, и сама сборка конечному клиенту не показывалась. Каждый раунд закрывался только после согласования ответственного за проверку со стороны агентства. ## Агентствам с библиотекой шаблонов > В сборке стоматологического сайта на брендированном шаблоне структурный риск сидит в общем слое, но болит у агентства скорость отклика. Для одиночной клиники шаблон — стартовая площадка. Для сети с несколькими локациями, которая обвешивает его собственными страницами, — обуза в поддержке. Следующее обновление родительского шаблона сломает доработки дочерней темы. Редактор начнёт сбоить у сотрудников, которые ведут собственные типы записей. Циклы правок растянутся, и зависшую очередь агентство понесёт перед клиентом. Подрядчику стоит задавать не вопрос «настроите ли шаблон», а вопрос «как именно вы выстроите слой доработок, чтобы следующее обновление не обнулило проект, а циклы правок оставались предсказуемыми?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы сопоставим слой доработок со структурой шаблона, отметим, где будущие обновления угрожают вашим правкам, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-26-page-dental-82-days/ title: Доработка темы для сайта стоматологии — 26 страниц за 82 дня type: case_study date: 2025-04-23T17:58:47+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 26 страниц Floss Lincoln Park мы собирали в два действия: сначала развернули каркас шаблона, затем пересчитали оценку, когда брендинг и тексты пришли 17 дней спустя. Первая фаза заложила архитектуру; вторая — интегрировала контент, написанный без оглядки на секционную структуру шаблона. 82 дня, 5 шаблонов и 93 пункта QA показывают, сколько работы уходит на то, чтобы свести независимо написанный контент-бриф с уже опубликованным шаблоном и не дать ему «поплыть». Доработка шаблона даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует дизайн, пропускает проверки или отходит от дизайн-системы шаблона, хуже, чем сборка с нуля. Два действия: каркас собран до того, как появился контент, потом пересчитан и наполнен, когда пришли брендинг и тексты. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая стоматология Конечный клиент Floss Lincoln Park (стоматологическая клиника в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства на WP Engine) Объём **26 URL** — главная, страховка, платёжная политика, формы для пациентов, новым пациентам, контакты, знакомство с врачами и 18 страниц услуг Сроки 82 дня (28 марта – 18 июня 2025), в срок Затраты 24 часа — разработка, итерации QA и управление проектом Команда 3 специалиста Шаблоны **5 переиспользуемых шаблонов** от агентства, все применены на 26 страницах Стек технологий WordPress · Elementor · WP Engine hosting · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **93+ отслеженных пункта SEO + AM**, сведённых в очереди задач агентства по контрольному списку запуска из 29 пунктов **Ритм работы** 64 задачи от агентства · все закрыты к передаче (5 активных дней, 2025-04-25 – 2025-04-29) **Раунды проверки** ≈4 раунда проверки за 82 календарных дня **Контрольный список запуска** 29 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам бриф на доработку темы для Floss Lincoln Park — новой стоматологической клиники, начинающей с нуля. Агентство ещё работало над брендингом и логотипом клиента, когда началась разработка, а контент сайта должен был поступить в процессе сборки. Первоначальный объём — настройка каркаса шаблона; вторая фаза — наполнение страниц после поступления контента. Порядок работы здесь иной, чем на ребилде с фиксированным объёмом. Сначала собрать костяк шаблона. Дождаться контента. Пересчитать оценку. Наполнить страницы. Пройти QA. 26 страниц были точкой входа; настоящая работа — удержать шаблон от смещения при интеграции брендинга и текстов, которых ещё не было в момент первого коммита. Оценка по строкам карты сайта имела ограничение: дизайн-файлы включали разделы — например, блог, — которых не было в первоначальном объёме таблицы Google Sheets, и их шаблоны вышли за рамки исходного постраничного бюджета. Агентству было важно не нарваться на подрядчика, для которого «шаблон скопирован» = «готово». В доработке для новой практики — без рабочего сайта для регрессионной сверки и без готового контента — сборка закрыта только тогда, когда каждая страница точна, каждая заглушка убрана и каждый пункт QA сведён. Команда, которая останавливается, когда шаблон выглядит «примерно правильно», оставляет агентству очередь правок, разгребать которую теперь им. 93 пункта в этом проекте — не признак переделок, а след тщательной проверки. > **Контекст рисков.** Доработка темы для новой практики идёт в два этапа: сначала каркас, потом контент. Риск не в самом копировании шаблона — он в том, что происходит, когда брендинг, тексты и цветовая гамма приходят уже после того, как каркас запущен. Команда, которая просто вставляет контент в слоты-заполнители, рискует незаметно сломать компоненты шаблона, уйти от дизайн-системы или оставить осиротевшие страницы — созданные под каркас, но так и не наполненные. Главным в этом проекте было пересчитать объём при поступлении контента, интегрировать каждый элемент без дрейфа шаблона и закрыть полную очередь задач до передачи. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Дизайн-направление агентства и брендированный шаблон были источником истины. Наша задача — согласовать их страница за страницей: где стандартная вёрстка шаблона совпадала с дизайном, мы её оставляли; где дизайн требовал отклонения, мы дорабатывали. Ни одно дизайн-решение не исходило от нас. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «построить один раз, проверить один раз». Это «построить, QA, скорректировать, QA, скорректировать». Из 11 задач, отслеженных в этом проекте, **3 были итерациями QA** — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы проверяли, исправляли и возвращали сборку на новую проверку. За этими раундами стояло гораздо более масштабное сведение: агентство вело **93+ пункта в двух вкладках очереди задач** (65 находок SEO и 28 находок AM), и все мы проверили и закрыли через общий цикл исправлений. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без смещения.** Каждое изменение, которое мы вносили в брендированный шаблон — будь то вёрстка страницы, компонент секции или стилевой токен, — мы фиксировали по дизайн-референсу. Ни одна доработка не ушла в общие компоненты шаблона агентства, поэтому изменения этого проекта не затронули ни один другой сайт на том же шаблоне. **4. Проверка на разных устройствах.** Доработки мы проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных — стандартный набор точек адаптации агентства. Каждый раунд QA покрывал страницы, затронутые расхождениями с дизайном в этом раунде, а не весь сайт, — так доработка шаблона остаётся выгодной без потери покрытия. Объём мы держали по строкам карты сайта из таблицы Google Sheets, а не по полному набору дизайн-файлов: незапланированные страницы выносили отдельными задачами, потому что карта сайта была контрактом между агентством и командой разработки. Контент пришёл уже после сборки каркаса, и это само задало порядок: сначала заложить костяк шаблона по оценке в 4 часа, дождаться контент-брифа агентства, пересчитать в 11 часов, когда он пришёл. Этот порядок не случаен: интегрировать брендинг и тексты в готовый каркас, не дав шаблону «поплыть», дороже именно тогда, когда контент написан без оглядки на секционную структуру шаблона. ## Контроль качества Три находки QA прошли цикл исправлений в этом проекте: дублирующиеся мета-теги description (Rank Math отдавал один, глобальная настройка Elementor — второй) мы поймали и свели к одному; четыре карты сайта Rank Math (страницы, блог, услуги, врачи/FAQ) сократили до двух, которые требовались агентству; а 404, появившиеся после чистки URL в середине проекта, закрыли так — каждая страница, где сняли суффикс -info, получила 301-редирект до запуска. QA перед передачей мы прогоняли через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Внутренний контроль агентства шёл после передачи и заносил замечания в общую очередь задач для нашего цикла исправлений, пока агентство не подписывало результат. Доработки остались в переопределениях конкретного клиента; общие компоненты шаблона агентства мы не трогали. ## Результаты Метрика Результат Сдано URL **26** — 1 главная, 18 страниц услуг, 1 о нас, 1 контакты, 1 новым пациентам, 1 формы для пациентов, 1 страховка, 1 платёжная политика и 1 блог Применено шаблонов **5 из 5** переиспользуемых шаблонов построены и сопоставлены на 26 страницах (Главная, Стандартный шаблон, О нас, Страница услуги, Блог) Контрольный список запуска **29 пунктов** согласовано Пункты QA / SEO + AM отслежено и закрыто **93+** сведено по двум вкладкам очереди задач агентства (65 SEO + 28 AM) Итерации QA в Redmine **3 из 11 задач (27%)** отслежены на уровне итераций Сроки **82 дня**, сдано в срок Затраты **24 часа** при оценке в 24 часа — без перерасхода, без расширения объёма Команда **3 специалиста** Хостинг Запущено на WP Engine окружении шаблонов агентства Состояние страниц при передаче **26 / 26** URL в тестовой среде возвращали HTTP 200 при аудите карты сайта Если коротко: шаблон агентства мы доработали на 26 страницах и 5 шаблонах за 82 календарных дня, уложившись в оценку 24 часа. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Шаблон изучен, объём согласован, разработка каркаса спланирована Разработка каркаса ~2 недели Костяк шаблона построен до поступления контента Интеграция контента и переоценка ~4 недели Переоценено в 11 часов при поступлении контента; страницы наполнены Итерации QA (параллельно) ~4 недели 3 раунда QA зафиксировано; 93+ пункта очереди задач сведены Сдача финальный день Сайт запущен на WP Engine _Разработка и QA шли параллельно — так и устроена доработка темы, где этап QA не закрывается чисто: цикл идёт непрерывно, пока агентство не подпишет результат._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и интеграция контента) - **Анна Полунина** — разработчик (переоценка и поддержка фазы контента) - **Павел Сажин** — итерации QA и исправления - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство вело отношения с конечным клиентом на всём протяжении. Все запросы на доработку проходили через общую очередь задач агентства; Floss Lincoln Park не взаимодействовал с нашей командой напрямую. Каждая итерация выпускалась только после того, как проверяющий со стороны агентства подтверждал, что изменения соответствуют спецификации. ## Агентствам с библиотекой шаблонов > Система брендированных шаблонов держит каркас отдельно от бренд-слоя практики — и здесь у вас тихо ломаются именно бренд-настройки. У этой практики — одна клиника с собственным бренд-набором; у других — сеть DSO, где единый бренд держится строго на десятках сайтов. Поломки незаметные: обновление шаблона от поставщика молча затирает бренд-правки, которые ваш клиент уже утвердил; бренд-токены перестают расходиться по сайту в первый же раз, когда цвет меняют в кастомайзере; редакторы не находят блоки шаблона, потому что система собрана под разработчиков, а не под контент-команду. Поэтому спрашивайте подрядчика не «соберёте ли шаблон?», а «как вы зафиксируете бренд-токены, чтобы следующее обновление их не сбросило?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы пройдём настройку токенов по вашему фирменному стилю, покажем точки, которые штатное обновление перезапишет, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. Крайние — мы. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-dental-32h-64-days/ title: Доработка стоматологической темы за 64 дня, ~32 часа type: case_study date: 2025-04-16T16:10:00+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы Постраничный Figma как контракт для стоматологической клиники в Bellevue — главная, услуги, карточка врача, галерея улыбок и контакты, адаптированные внутри брендированной стоматологической темы агентства в среде Kinsta. Конкретная проверка для этого проекта: секция галереи «до и после», которую Figma предусматривала, но клиника ещё не предоставила фотографии. Задача была — аккуратно скрыть секцию, не выкатывать неработающую кнопку и вернуться к ней в очереди правок после релиза, когда контент поступит. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — общая и косметическая стоматология Конечный клиент Lifetime Smiles Bellevue (клиника общей и косметической стоматологии, Bellevue, NE) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированная стоматологическая тема агентства + постраничный дизайн в Figma на Kinsta) Объём Главная, лендинг услуг, страницы услуг, карточка врача, контакты, галерея улыбок и вспомогательные страницы — адаптированы по постраничному Figma агентства; секцию галереи «до и после» согласовали через очередь правок, так как фотографии клиента к запуску не поступили Сроки 64 дня (1 декабря 2025 – 2 февраля 2026), по графику: основная доработка + 4 внутренних раунда QA + закрытие очереди задач после релиза Трудозатраты **~32 часа** всего — 9,6 ч основная доработка + 4 раунда QA-проверки (кросс-проверки Павел + Тимур + xaver-ops) + ~14 ч закрытие очереди правок после релиза по отдельным исправлениям CTA, OG-тегов, положения адреса и списка услуг Команда 6 специалистов (разработка + QA + управление проектами) Шаблон Брендированная стоматологическая тема агентства, применённая к адаптированным страницам с постраничным дизайном в Figma Технологии WordPress · Elementor · Kinsta · Figma-driven дизайн · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **4 отдельных внутренних раунда QA** (под руководством Павел, затем Тимур, затем xaver-ops) с последующим согласованием пост-релизных правок в рамках отношений с агентством **Динамика взаимодействия** 3 задачи от агентства · 2 из 3 закрыты к моменту передачи **Раунды проверки** ≈4 раунда проверки за 64 календарных дня **Контрольный список запуска** 78 пунктов, согласован перед переключением ## Постановка задачи У агентства был постоянный стоматологический клиент в Bellevue, NE — клиника общей и косметической стоматологии под брендом Lifetime Smiles Bellevue. Агентству принадлежала стоматологическая тема; наша задача — постранично адаптировать тему под дизайн в Figma конкретного клиента и передать сайт на тестовую среду Kinsta, готовый к циклу проверки агентства и последующему переходу на рабочий сервер. Задача была конкретной, типичной для работы с агентскими темами: взять тему как отправную точку, не трогать общие компоненты темы, вносить только переопределения для конкретного сайта, следовать дизайну в Figma на каждой странице и выносить всё недостающее через общую очередь задач агентства, а не принимать решения самостоятельно. На прямой контакт с конечным клиентом не выходить. Запросы на доработку, уточнения по дизайну и отношения с конечным клиентом — полностью за агентством. > **Контекст рисков.** Риск, специфичный для этого проекта, — отсутствие контента на момент доработки. Figma предусматривала секцию галереи «до и после» на главной с привязкой фотографий. Клиника не передала набор снимков к моменту адаптации темы. Первый импульс студии при таком пробеле — поставить секцию-заглушку и считать доработку закрытой. Но заглушка с неработающей кнопкой бросается в глаза на запуске куда сильнее, чем аккуратно принятое структурное решение заранее. Мы поступили наоборот: сообщили агентству о пробеле, согласовали обработку (скрыть секцию, сохранить целостность макета) и вернулись к ней в очереди правок после релиза, когда поступил контент. Доработка, которая выкатывает сломанную секцию только потому, что спецификация её предусматривала, — это не выдержка, а слепое следование шаблону. ## Как мы это сделали **1. Постраничная доработка по Figma агентства.** Работа велась внутри брендированной стоматологической темы агентства — главная, лендинг услуг, отдельные страницы услуг, карточка врача, галерея улыбок, контакты и вспомогательные страницы — с применением постраничного дизайна в Figma как авторитетного референса. Там, где стандартная структура темы расходилась с Figma (положение номера телефона, размещение CTA, порядок списка услуг на главной), вносились переопределения для конкретного сайта без изменения общих компонентов темы, которые используются для других клиник на той же системе шаблонов. **2. Координация контентных пробелов через очередь правок.** Когда секция галереи «до и после» из Figma столкнулась с отсутствием фотографий, мы аккуратно скрыли её, а не выкатили с неработающим CTA. Общая система задач агентства вела координацию — не как блокер разработки, а как пункт структурной полноты, к которому нужно вернуться, когда поступят фотографии клиента. Тот же подход применялся к нескольким менее значимым элементам, где дизайн агентства предусматривал контент, который клиника ещё не согласовала: уточнение положения адреса, порядок списка услуг на главной, исправление названия сайта в OG-теге. **3. Четыре раунда внутреннего QA перед согласованием.** QA-проход прошёл через четыре отдельных раунда: проход под руководством Павел 6 декабря, кросс-проверка xaver-ops в тот же день, перепроверка Павел 10 декабря и финальный проход xaver-ops 20 декабря перед передачей агентству. Каждый раунд формировал список разбора по Figma; ничего не закрывалось, пока следующий раунд QA не подтверждал, что исправления предыдущего внесены аккуратно и не дали новых отклонений. **4. Закрытие очереди правок после релиза внутри отношений.** После передачи агентству через общую очередь вернулась последовательность точечных правок: отсутствие названия сайта в OG-теге, несоответствие основной кнопки CTA Figma-шаблону, неверное положение номера телефона и адреса, неполный список услуг на главной, ненастроенная ссылка CTA в галерее «до и после». Каждую правку оценили, исправили, прогнали через внутреннюю проверку и передали на подписание проверяющему со стороны агентства. Хвост после релиза и есть свидетельство выдержки: структурную полноту сохранили на запуске за счёт аккуратного удержания пробелов, а сами пробелы закрыли через отношения, а не через видимые регрессии. Удержание секции галереи «до и после» на запуске — вместо выкатки неработающего CTA, пока фотографии клиента не поступили — стало решающим фактором качества проекта. Задача #2788 («Get before & after photos: Button not linked») оставалась в очереди агентства до поступления контента; секцию открыли заново только когда материалы были готовы. Эта выдержка сохранила качество передачи по всем остальным страницам. ## Контроль качества Первый QA-проход 6 декабря выявил проблему читаемости прилипающей шапки — заголовок был полупрозрачным при скролле и «нечитабельный в залипшем состоянии» — исправлено до передачи; ещё 3 задачи от агентства после запуска (site name в RankMath OG-теге, отступы основной кнопки CTA относительно Figma, позиционирование телефона и адреса в шапке) закрыты через общую очередь задач. QA перед сдачей выполняли через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Внутренний контроль агентства работал после передачи и фиксировал замечания в общую очередь для нашего цикла исправлений, пока агентство не согласовало результат. Доработки оставались в переопределениях конкретного клиента; общие компоненты темы агентства не модифицировались. ## Результаты Метрика Результат Сроки **64 дня** (1 декабря 2025 – 2 февраля 2026) — основная доработка + 4 раунда QA + закрытие очереди правок после релиза, всё по графику Трудозатраты **~32 часа** всего — 9,6 ч основная доработка + ~14 ч исправления после релиза + QA-кросс-проверки Цикл QA **4 внутренних раунда QA** перед согласованием агентства — кросс-проверка Павел, Тимур и xaver-ops Правки после релиза Название сайта в OG-теге, выравнивание CTA по Figma, положение телефона и адреса, список услуг на главной, ссылка CTA в галерее «до и после» — каждую отдельно оценили, исправили и проверили Обработка контентных пробелов Секцию галереи «до и после» аккуратно удержали на запуске (неработающий CTA не выкатили); завели в очередь, чтобы вернуться к ней при поступлении контента через очередь правок агентства QA на больших экранах и мобильных устройствах Доработку проверили на большом экране и мобильных устройствах в цикле QA **Статус сайта** Работает на Kinsta, открывается по адресу https://lifetimesmilesbellevue.com/. Если коротко: подход к доработке темы агентства мы выдержали от начала до конца. Точность по Figma, обработка контентных пробелов и закрытие правок после релиза — всё проходило через отношения с агентством; клиника напрямую с нашей командой не взаимодействовала. ## Процесс Этап Длительность Результат Бриф и проверка темы ~1-2 дня Figma агентства и тема изучены; подготовлен постраничный список доработок Основная доработка ~2 недели Страницы адаптированы по Figma; контентные пробелы вынесены в очередь правок Внутренний QA — раунд 1 6 декабря QA-проход под руководством Павел; кросс-проверка xaver-ops в тот же день Внутренний QA — раунд 2 10 декабря Перепроверка Павел исправлений раунда 1 Внутренний QA — раунд 3 20 декабря Финальный проход xaver-ops перед передачей агентству Передача агентству Конец декабря Сайт доставлен на тестовую среду для проверки агентства Закрытие очереди правок после релиза январь – начало февраля Исправления OG-тега, CTA, адреса, списка услуг, CTA галереи заведены в очередь и закрыты по отдельности ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и вёрстка по Figma) - **Павел Сажин** — ведущий QA (раунды 1 и 2, координация проверки после релиза) - **Анна Полунина** — поддержка разработки (контентные обновления, раунды исправлений после релиза) - **Тимур Арбаев** — поддержка QA на всех раундах - **Людмила Травкина** — QA-проход и координация проверки перед сдачей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование передачи) Управление проектом со стороны агентства, дизайн, подбор контента и отношения с конечным клиентом оставались у партнёрского агентства на всём протяжении. Lifetime Smiles Bellevue с нашей командой напрямую не работала. Все запросы на доработку и задачи после релиза поступали через общую очередь задач агентства; конечный клиент процесса разработки не видел. ## Агентствам с библиотекой шаблонов > В сборке на родительском шаблоне для стоматологии граница между клиентскими переопределениями и кодом шаблона не видна до запуска. У этой практики — семейная стоматология с типовым набором услуг; у других — ортодонтическая сеть на едином шаблоне с десятком филиалов. Если подрядчик не выстроит строгий слой переопределений, доработки в дочерней теме сломаются при первом же обновлении родительского шаблона. ACF-схема разойдётся с канонической версией автора. Бренд-токены перестанут дотягиваться до зашитых значений по умолчанию после смены цвета в кастомайзере — и вы будете разбираться с клиентом, почему на сайте разнобой. Подрядчику стоит задавать не вопрос «соберёте ли шаблон», а вопрос «как именно вы ограничите клиентский слой, чтобы апдейты шаблона не ломали доработки?» Пришлите ID и версию родительского шаблона, черновик дочерней темы или макеты. Мы проверим схему переопределений на устойчивость к обновлениям, сверим ACF-привязки с канонической схемой и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-rappaport-officite-migration-18-days/ title: Ребилд стоматологического SaaS на WordPress: 33 часа за 18 дней type: case_study date: 2025-04-11T17:25:21+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Стоматологическая практика переезжала с SaaS-платформы Officite на WordPress + Elementor Pro. Прежняя платформа плодила автоматические пути к статьям, которых не видно в обычной карте сайта, а политика конфиденциальности лежала только в виде PDF. За 18 дней и 33 часа разработки мы перебрали старые адреса в поисках скрытых путей, перенесли политику конфиденциальности в полноценную страницу и сдали ребилд строго по ТЗ агентства, без перерасхода. ## Краткий обзор Поле Значение Отрасль клиента Стоматология Клиент Rappaport Dental **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress: миграция с SaaS-платформы для стоматологии на WordPress + Elementor Pro на WP Engine Объём Весь сайт — услуги, о нас, контакты, политика конфиденциальности (перенесена из PDF), редиректы для путей, сгенерированных SaaS Сроки 18 дней (9–26 мая 2025), без задержек Затраты 33 часа разработки при оценке 33 часа — без перерасхода Команда 5 специалистов (разработка · QA · правки контента · PM) Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Сверка контента Контент оригинала и ребилда сверены до сдачи — ничего не потеряно, ссылки целы, структура совпадает **Сдано** **ТЗ выполнено строка в строку — редиректы, мета-заголовки, страница политики конфиденциальности, чистка SaaS-путей, контрольный список запуска** **Раунды проверки** ≈5 раундов на протяжении 18 календарных дней ## Постановка задачи Rappaport Dental работал на проприетарной SaaS-платформе для стоматологической индустрии — управляемый хостинг со встроенной системой контента для стоматологий. Агентству требовалось перенести сайт на стандартный стек WordPress для большей редакционной свободы и долгосрочной управляемости SEO. В отличие от миграции между CMS, переход со стоматологического SaaS на WordPress — однонаправленный процесс: URL-соглашения старой платформы, структуры контента и автоматически генерируемые пути не ложатся чисто на WordPress-слаги. Таблица Google Sheets агентства содержала каждый целевой URL, каждый мета-заголовок и описание, назначение шаблонов и стратегию редиректов для путей наследия. Также требовалась конвертация специфического контента: политика конфиденциальности практики существовала только как PDF на старой платформе и нуждалась в перестройке в полноценную страницу WordPress до запуска. Все решения о том, какие старые адреса сохранять, перенаправлять или выводить из работы, принадлежали агентству. Наша задача — точно повторить их ТЗ. Агентство закрывало не абстрактный риск карты редиректов, а вполне конкретный для переезда со стоматологического SaaS: такая платформа плодит структурированные пути под библиотеки статей, архивы категорий и разделы специализированного контента, которым в WordPress нет ровни. Попади любой из этих автогенерированных путей в индекс и не окажись он в ТЗ на редиректы — обход агентства упёрся бы в пробел. Поэтому мы заведомо считали набор адресов SaaS-платформы враждебным, а не простым: исходили из того, что существуют пути, которых в обычном экспорте карты сайта не видно. > **Контекст рисков.** SaaS-платформы для стоматологии, подобные той, с которой мигрировал Rappaport Dental, генерируют URL-структуры, не охватываемые стандартной проверкой sitemap — пути архивов статей, категорийные слагы и секции контента, созданные провайдером, могут накапливаться в индексе, не появляясь в колонке sitemap агентства. Сценарий сбоя при переключении — не сломанная главная, а обнаруженный при обходе кластер 4xx-путей, которые никто не предусмотрел в ТЗ. Корректная обработка этого ребилда требовала активного аудита URL-поверхности наследия на предмет автоматически сгенерированных путей, их передачи агентству до переключения и подтверждения: входят ли они в объём редиректов или выводятся из эксплуатации. ## Как мы это сделали **1. Сборка на основе шаблонов.** Весь сайт был собран на едином наборе шаблонов, применённых ко всем типам контента: - Главная, О нас, Контакты и универсальный запасной шаблон - **Лендинг услуг + шаблон страницы услуги** — покрытие всего каталога лечения практики - **Страница политики конфиденциальности** — преобразована из PDF старой платформы в полноценную страницу WordPress с навигационным контентом - Шаблоны для блога и общего контента Шаблоны покрывали каждый тип контента из таблицы. Все будущие правки вносятся в одном месте на тип страницы. **2. ТЗ выполнено строка в строку, по таблице агентства.** Таблица содержала каждый целевой URL вместе с редиректом со старого пути, каждый мета-заголовок и описание, каждое назначение шаблона. Мы повторили каждую строку как написано. Где таблица задавала редирект — мы его настроили. Где путь, сгенерированный SaaS, явно выводили из объёма — например, старые пути архивов статей, для которых агентство решило редиректы не делать, — мы подтвердили решение о выводе, а не гадали. Коротко: при ребилде ТЗ — это обязательство агентства перед клиентом. Наша задача — не переосмыслить его, а выполнить без отклонений. **3. Проверка обходом.** До переключения DNS Screaming Frog прошёл одновременно по стенду ребилда и старой SaaS-платформе. Статус-коды, цепочки редиректов, расхождения в мета-тегах и любые пути, найденные при обходе старого сайта, но отсутствующие в ТЗ агентства, — всё сверено до переключения. Контент страницы политики конфиденциальности сверили с исходным PDF. Повторный обход после запуска подтвердил, что внутренние ссылки работают на опубликованном домене. **4. Контрольный список запуска, закрыт до сдачи.** Точность дизайна, работа форм, точность контента, SEO и аналитика, адаптивность, порядок миграции DNS на WP Engine — всё закрыто до сдачи. Проверка на разных устройствах в Chrome, Firefox, Safari и Edge на нескольких ширинах экрана. Сначала надо было перебрать адреса SaaS, и только потом браться за сборку, — поэтому ТЗ на редиректы появилось первым. Путь архива статей без контента — не в карте сайта агентства, не в их ТЗ — всплыл при этом разборе; объём вывода мы подтвердили с агентством до переключения. Разработка опиралась на проверенный набор адресов, а не на карту сайта, которую мы считали полной. ## Результаты Метрика Результат Точность ТЗ — редиректы Все указанные агентством старые пути перенаправлены; автогенерированные SaaS-пути вне ТЗ подтверждены как выведенные Точность ТЗ — мета-данные Все мета-заголовки и описания проставлены согласно ТЗ Точность ТЗ — шаблоны Система шаблонов построена и применена на всём сайте Точность ТЗ — политика конфиденциальности Старый PDF перенесён в полноценную страницу WordPress Сроки **18 дней**, сдано по графику Трудоёмкость **33 ч / 33 ч** оценки разработки — без перерасхода, без расширения объёма Проверка адаптивности Ноль проблем с отображением на 4 браузерах × 6 разрешениях Внутреннее QA Все вопросы по объёму агентства закрыты до сдачи; после релиза раунд QA агентства добавил правки контента и ссылок в отдельном спринте Статус сайта Опубликован на WP Engine: [rappdental.com](https://www.rappdental.com/). Если коротко: ТЗ агентства на миграцию выполнено как написано, в запланированный день переключения, и весь набор адресов старого сайта сверили с ТЗ до сдачи. ## Контроль качества В ходе QA перед сдачей плагин Site Checker выявил путь архива статей SaaS (`/articles/dear_doctor/category/47365`) с нестандартным слагом и без контента — именно тот класс автоматически сгенерированных путей, о котором предупреждал бриф (они не отображаются в стандартном экспорте sitemap). Параллельный проход QA подтвердил, что редиректы ещё не активны на тестовой среде. Оба вопроса решили до сдачи. QA перед сдачей шло через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Свой контур проверки у агентства шёл после сдачи и передавал вопросы в общую очередь правок для нашего цикла исправлений, пока агентство не подписало приёмку. ## Процесс Фаза Длительность Результат Бриф и оценка 3 дня ТЗ агентства изучено; адреса SaaS перебраны; оценка 33 ч согласована Разработка ~10 дней Весь сайт перестроен; политика конфиденциальности перенесена из PDF; карта редиректов настроена Внутреннее QA и проверка 3 дня Вопросы зафиксированы; разбор путей SaaS завершён; все работы по ТЗ приняты Проверка ТЗ 1 день Meta, редиректы и контент страниц сверены с таблицей Сдача и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Фазы перекрываются (QA шёл параллельно с поздней разработкой), поэтому календарный срок — 18 дней, а не сумма фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта, система шаблонов, реализация редиректов) - **Павел Сажин**, [xaverPRO](https://xaver.ru/) — QA и контроль доставки - **Анна Полунина** — поддержка реализации и QA по всем страницам ребилда - **Евгений Карпов** — правки контента и QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, приёмка) Все решения по сохранению адресов и стратегии редиректов принадлежали агентству; наша роль — точно повторить их ТЗ. Публичным подрядчиком оставалось агентство; конечный клиент нас не видел. ## Агентствам, заказывающим ребилд WordPress > На ребилде стоматологического сайта вы боитесь одного: после переезда часть старых адресов тихо отвалится. У одной практики структура контента разрастается внутри SaaS, плодя сотни путей вне карты сайта; у других каждую страницу заводят вручную и держат в карте сайта. Соберёте редиректы только по очевидным адресам — автогенерированные пути отвалятся молча. Сайт просядет в индексе, клиент заметит падение трафика на второй неделе, и вы будете разбираться в аналитике без готового списка старых адресов. Подрядчику стоит задавать не вопрос «сможете ли переехать», а вопрос «как именно вы найдёте все старые адреса, включая те, которых не видно в карте сайта?» Мы перебираем старый сайт сами и за результат отвечаем: пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты — мы пройдём по сайту, найдём адреса-артефакты, которых не ловит обычный аудит, и подсветим, какие из них войдут в миграцию. Вернём фиксированную смету в часах. Аудит — без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-legal-66h-116-days/ title: WordPress-сайт юридической фирмы на 112 страниц за 116 дней type: case_study date: 2025-04-07T07:00:18+00:00 case_industry: Юридические услуги case_type: Разработка case_practice: wordpress --- ## Подход к разработке 112 URL на 9 шаблонах, свёрстанных по макетам Figma для большого экрана и мобильных устройств — 83 из этих страниц на одном шаблоне Individual Practice Areas, применённом по разу для каждой практики, подпрактики и юрисдикции на всём дереве услуг. Агентство предоставило библиотеку шаблонов, карту сайта и почасовую оценку; мы сопоставили каждый URL с назначенным шаблоном и уложились в бюджет 66 часов на всём 116-дневном цикле разработки и правок. ## Краткий обзор Поле Значение Отрасль клиента Юриспруденция — травмы и несчастные случаи, трудовое право, защита DWI, врачебная халатность, иммиграция Конечный клиент Jae Lee Law (New Jersey) **Формат сотрудничества** **White-label WordPress build для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта WordPress build с Elementor на Kinsta с последующей фазой правок Объём **112 URL** — главная, лендинги практик (округа Bergen, Hudson, Passaic), страницы отдельных практик (83 страницы на 11 направлениях), страницы адвокатов (4), about (3), результаты дел, контакты, блог (10 постов + лендинг), дисклеймер, политика конфиденциальности и служебные страницы Сроки 116 дней (5 июня – 29 сентября 2025), по плану Трудоёмкость **66 часов** при оценке 66 часов — без перерасхода Команда 4 специалиста (46 ч разработка · 10 ч QA · 10 ч PM — перекос в разработку оправдан для однофазной разработки с большим объёмом контента) Шаблоны **9 активных шаблонов** из стандартной библиотеки агентства для юридической сферы (Attorney Page, Practice Areas, Individual Practice Areas, About Us, Blog, Blog Lander, Homepage, Contact, Default Template) Технологии WordPress · Elementor · Gravity Forms · Kinsta · Rank Math · GTranslate · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) **Результат** **112 URL построено на 9 шаблонах, SEO-вкладка закрыта 35/35, CX-вкладка — 24/25 (закрыто или в QA)** **Динамика** 35 задач от агентства · все закрыты к моменту сдачи (активная фаза 42 дня, 2025-06-20 – 2025-07-31) **Раунды проверки** ≈5 раундов **Контрольный список запуска** 30 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США, нанятое Jae Lee Law — юридической фирмой из New Jersey, специализирующейся на травмах, несчастных случаях и трудовом праве и обслуживающей клиентов в округах Bergen, Hudson и Passaic — передало нам таблицу Google Sheets с полной картой URL, каталогом шаблонов, контрольным списком запуска и предзаполненными очередями задач. Разработка велась на их окружении Kinsta; конструктор страниц — Elementor; контактные формы — через Gravity Forms. Вкладка Template в таблице содержала библиотеку раздела LEGAL: Attorney Page, Practice Areas lander, Individual Practice Areas, About Us, Blog, Blog Lander, Homepage, Contact, Default Template, Results и служебные страницы с политиками. Задача: построить все 112 страниц по библиотеке шаблонов агентства — сопоставив каждый URL отдельной практики с назначенным шаблоном из строки карты сайта — и отработать две параллельных очереди задач QA (SEO-трек и CX-трек), пока агентство не примет сайт. На всём протяжении не выходить на прямой контакт с конечным клиентом; неясности возвращать в агентство; не импровизировать с описаниями практик, квалификацией адвокатов или навигационной иерархией. > **Контекст рисков.** Сайты юридических фирм подчиняются правилам рекламы адвокатских услуг, которые различаются от штата к штату. Партнёр-разработчик, создающий сайт по травмам и несчастным случаям в New Jersey, не пишет тексты, не решает, какие практики перечислять и как их описывать, и не оценивает формулировки результатов дел. Что разработчик действительно контролирует — структурная точность: каждая страница в карте сайта должна быть построена на назначенном шаблоне, каждая страница практики должна существовать и быть доступной, а навигация должна отражать согласованный объём. Когда в процессе разработки через очередь задач QA агентства поступают изменения карты сайта или контента, возникает риск, что сайт будет запущен с битыми ссылками, страницами-сиротами или несогласованной навигацией. Аккуратно закрыть такие пункты до сдачи — вот дисциплина разработки, которая здесь и решает. Дополнительным ограничением в этом проекте была готовность контента: несколько CTA и локализованных секций страниц практик на момент разработки не имели готовых текстов и были помечены в SEO-вкладке для добавления после запуска — чтобы не задерживать цикл разработки. Это следствие того, что процесс подготовки контента агентства работал параллельно с разработкой, а не опережал её. ## Как мы это сделали **1. 9 шаблонов, 112 страниц, один процесс.** Страницы Jae Lee Law распределились по библиотеке шаблонов агентства: Homepage, Attorney Page (применён четыре раза — по разу на каждого адвоката в исходной карте сайта), Practice Areas lander (применён на уровне округов Bergen, Hudson, Passaic и на основной странице `/practice-areas/` — всего 4 раза) и самый объёмный — Individual Practice Areas, применённый 83 раза по всему дереву практик фирмы: травмы и несчастные случаи, ДТП, строительные травмы, ответственность за состояние помещений, ответственность за продукцию, трудовое право, врачебная халатность, защита DWI/DUI, халатность в домах престарелых, а также локализованные страницы по округам. Каждая страница построена на назначенном шаблоне; ни одна не создавалась вручную вне системы шаблонов. **2. Спецификация соблюдена построчно, в рамках согласованной сметы.** Объём в часах по каждой строке мы оценили сами и зафиксировали до старта. 83 страницы Individual Practice Areas шли по минимальной ставке за страницу — это закономерность импорта контента агентства: каждая страница получает применение шаблона и наполнение из существующих материалов агентства. В сумме проект уложился в согласованные 66 часов. **3. Два параллельных QA-цикла, закрытых до запуска.** Агентство разделило QA на отдельные SEO- и CX-направления, а не свело в один список — потому что SEO-замечания команда разработки могла закрыть сама (мета-заголовки, иерархия навигации, перенаправления), тогда как CX-пункты часто требовали согласования со стороны агентства или утверждения клиента. Замечания отслеживались в двух вкладках агентства — Issues Backlog(SEO) (35 строк, все Completed) и Issues Backlog(CX) (25 строк, 24 Completed, 1 in QA на момент выгрузки данных). Первые строки SEO-вкладки касались иерархии навигации и соответствия Figma на главной; первые строки CX-вкладки охватывали структурные правки карты сайта и настройку контактной формы. Контрольный список запуска на 30 пунктов — Design, Functionality, Pre-Migration, Post-Migration — вёлся параллельно с обеими очередями правок. H1 поставили с нулевым размером шрифта под макет Figma — обходное решение, оставившее главную без рабочего заголовка для SEO-инструментов. Это замечание, а также типы записей результатов дел, помеченные как публично индексируемые, прошли цикл исправлений до согласования. Ни то, ни другое не потребовало изменения объёма работ; оба требовали, чтобы их нашёл QA-раунд. ## Результаты Метрика Результат Построено URL **112** на 9 шаблонах (83 Individual Practice Areas · 10 постов блога + лендинг · 4 Attorney Pages · 4 Practice Areas lander · 3 About Us · 1 Homepage · 1 Case Results · 1 Contact · 4 служебных страницы) Задействовано шаблонов **9 / 9** из стандартной библиотеки шаблонов агентства SEO-вкладка **35 / 35** закрыто как Completed CX-вкладка **24 / 25** закрыто как Completed; 1 in QA на момент выгрузки Контрольный список запуска **Контрольный список на 30 пунктов**: Design, Functionality, Pre-Migration, Post-Migration Мультиязычный слой Настроен плагин GTranslate для доступа на испанском — распространённое требование для юридических практик New Jersey, обслуживающих испаноязычные сообщества Сроки **116 дней** (5 июня – 29 сентября 2025), по плану Трудоёмкость **66 ч / 66 ч оценка** — без перерасхода, без расширения объёма Статус сайта Работает на Kinsta по адресу https://www.jaeleelaw.com/ — проверено в апреле 2026 ## Контроль качества Последующий раунд проверки агентства выявил две структурные проблемы, которые прошли через общий цикл исправлений: H1 на главной был установлен с нулевым размером шрифта — обходное решение для соответствия Figma, оставившее страницу без рабочего заголовка для SEO-инструментов, — а внутренний тип записей `case-results` был публично доступен и индексируем, что потребовало обработки `noindex` для каждой записи перед запуском. QA перед сдачей прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Внутренний контур проверки агентства работал после сдачи и выявлял замечания, которые поступали в общую очередь задач для нашего цикла исправлений до окончательного согласования. ## Процесс Фаза Длительность Результат Бриф и оценка ~1 неделя Таблица проанализирована, объём по строкам оценён, согласовано 66 ч Разработка (страницы + шаблоны) ~2 недели Все 112 URL построены на 9 шаблонах на тестовой среде; открыты обе очереди задач QA Контентные раунды + мультиязычность ~4 недели (параллельно с QA) GTranslate настроен на испанский; контентные раунды по CX-страницам; структурные изменения от агентства приняты через стандартный QA-цикл Фаза сверки QA (SEO + CX) ~8 недель SEO-вкладка закрыта 35/35; CX-вкладка закрыта 24/25; контрольный список пройден по Design / Functionality / Pre-Migration Доработки после запуска Финальные ~4 недели Проверка дизайна главной, CSS-правки, исправления отображения Elementor loop-item _Фазы пересекаются — контентные раунды и структурные изменения шли параллельно с QA-раундами, поэтому календарная длительность составила 116 дней, а не сумму отдельных фаз._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик на этапах разработки и правок - **Никита Тумашевич** — поддержка разработки на поздних этапах (CSS- и Elementor-правки) - **Павел Сажин** — QA-итерации - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороны агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим разработку WordPress > На сайте юридической фирмы таксономия практик задаёт граф структурированной разметки и позиции, которые SEO-кампания агентства уже заняла. Сайт практики по травмам в одном городе живёт в одной плоскости; фирме с несколькими городами, травмами и трудовым правом архитектура должна гнуться, не ломаясь. Стоит дописать практику в середине проекта — и таксономия не растягивается: разметка, собранная под первое направление, рассыпается на втором, а связки формы с CRM теряют отслеженные контакты. Всё тихо, всё за счёт агентства. Подрядчику стоит задавать не вопрос «соберёте ли страницы», а вопрос «как именно вы спроектируете таксономию и разметку так, чтобы они пережили следующую практику?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы пройдёмся по плану таксономии против ваших целей по практикам и отметим, где разметка может рассыпаться. Вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-50h-31-days/ title: 21-страничная разработка сайта стоматологии на WordPress за 31 день type: case_study date: 2025-04-03T00:45:22+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 21 страница сайта стоматологической практики на WordPress — из макетов Figma в Elementor, по карте сайта из таблицы Google Sheets, где у каждой строки была своя оценка в часах. Каркас подняли до того, как пришёл весь контент: так не остаётся щели, в которую менее осторожный подрядчик сложил бы структуру. Дальше — хвост интеграции контента и проверка в два контура. Всё уложилось в 50 часов за 31 день. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая стоматология Конечный клиент Songbird Dental Studio (Crawfordville, FL) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor на WP Engine, вёрстка из макетов Figma Объём **21 URL** — главная, о нас, страница врача, лендинг блога, блог, контакты, лендинг услуг, 8 страниц услуг, галерея улыбок, страница нового пациента, страница стоматологических технологий, страница благодарности, страница 404 Сроки 31 день (26 марта – 26 апреля 2025), сдано в срок Затраты **50 часов** при оценке в 50 часов — без перерасхода Команда 5 специалистов (распределение с акцентом на разработку, что оправдано для вёрстки из Figma в Elementor с интеграцией контента) Шаблоны **13 переиспользуемых шаблонов** — стандартная библиотека стоматологических шаблонов агентства Стек технологий WordPress · Elementor · Gravity Forms · WP Engine · Rank Math · WP Rocket · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **21 URL в 13 шаблонах; очередь SEO — 40 из 48 задач закрыто (Completed); очередь аккаунт-менеджера — 19 из 20 закрыто (Completed); закрыто 29 пунктов контрольного списка** **Ритм работы** 47 задач от агентства · 46 из 47 закрыто к передаче (57 активных дней, 2025-04-09 – 2025-06-04) **Раунды проверки** ≈8 раундов проверки за 31 календарный день **Контрольный список запуска** 29 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США, нанятое Songbird Dental Studio — стоматологической клиникой общего профиля в Crawfordville, Florida — передало нам таблицу Google Sheets с полной картой сайта, макетами Figma для главной и внутренних страниц, каталогом шаблонов, контрольным списком запуска и предзаполненными очередями задач SEO и аккаунт-менеджера. Разработка велась на их окружении WP Engine; конструктор страниц — Elementor; формы — Gravity Forms. Задача: построить все 21 страницу по библиотеке шаблонов агентства, сверстать макеты Figma в Elementor, интегрировать контент по мере его поступления от клиента, настроить формы и обработать обе очереди задач QA до тех пор, пока агентство не примет сайт. Дизайн, контент-стратегия, SEO-стратегия и коммуникация с клиентом оставались за агентством. > **Контекст рисков.** Новая разработка для практики с неполным контентом на старте несёт специфический риск: разработчик может упростить архитектуру URL под текущий скудный контент или оставить страницы с текстом-заполнителем, который, по мнению агентства, будет помечен. Агентство искало разработчика, который построит полный каркас из 21 URL ровно так, как указано в карте сайта, — каждую страницу услуг, каждый шаблон, каждую цель формы, — и будет считать отсутствие контента блокировкой со стороны агентства, а не поводом сокращать объём. Согласованная смета была контрактом; наша задача — уложиться в неё, не сокращая структуру. Изображения от агентства поставлялись в несжатых JPG (200–500 КБ каждое), потребовавших пакетного преобразования в WEBP и повторной загрузки на все страницы до закрытия контрольного списка производительности. ## Как мы это сделали **1. Тринадцать шаблонов, 21 страница, один процесс — по макетам из Figma.** 21 страница сайта распределилась по стандартной библиотеке шаблонов агентства: Главная (1), О нас (2 — страница практики + биография врача), Лендинг блога (1), Блог (1), Контакты (1), Лендинг услуг (1), Страница услуги (8 — отбеливание зубов, стоматология под седацией, импланты, осмотры, виниры, удаление, протезы, косметическая стоматология, общая стоматология, восстановительная стоматология), Галерея улыбок (1), Новый пациент (1), Технологии (1) и Стандартный шаблон (2 — страница благодарности + 404). Каждую страницу мы сопоставили со своим шаблоном из строки карты сайта ещё до того, как написали первую строку Elementor. **2. Структурное сопоставление Figma → Elementor, а не визуальное копирование.** Исходный дизайн был прототипом Figma, а не статическим макетом. Мы рано выявили структурные примитивы — иерархию заголовков, отступы секций, мобильные точки адаптации — и подтвердили, что итоговый вывод соответствует спецификации Figma, прежде чем страница покидала тестовую среду. **3. Согласованная смета как контракт.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Дальше держались сметы строго: не вскрывали ценообразование заново, когда в контенте появлялись пробелы, — этот выбор сохранил агентству модель фиксированной стоимости. По проекту в целом уложились в согласованные 50 часов. **4. Два контура QA, отработанные до запуска.** Задачи вели в двух очередях агентства: очередь SEO (48 строк, приоритеты от Low до High) и очередь аккаунт-менеджера (20 строк, со скриншотами по тестовой сборке). Из 48 позиций SEO 40 закрыли как Completed до запуска; 5 остались в To Do, 1 — контрольная точка после выхода сайта, 1 — In progress. Из 20 позиций аккаунт-менеджера закрыли 19. Контрольный список запуска на 29 пунктов — Дизайн, Функциональность, Контент, До миграции, После миграции — закрыли последним, после обеих очередей. Объём работ удерживала согласованная смета. Когда контент пришёл с задержкой и страницы-заполнители выглядели кандидатами на вычёркивание, именно она осталась контрактом, сохранившим в разработке каждый URL, — и по итогу мы уложились ровно в согласованные 50 часов. ## Результаты Метрика Результат Построено URL **21** — Главная (1) · О нас (2) · Страница врача (1) · Лендинг блога (1) · Блог (1) · Контакты (1) · Лендинг услуг (1) · Страница услуги (8) · Галерея улыбок (1) · Новый пациент (1) · Технологии (1) · Стандартный шаблон (2) Применено шаблонов **13 / 13** из стандартной стоматологической библиотеки агентства Контрольный список запуска **29 пунктов** согласовано по разделам Дизайн / Функциональность / Контент / До миграции / После миграции Очередь задач SEO **40 / 48** закрыто как Completed; 5 To Do, 1 контрольная точка после выхода сайта, 1 In progress Очередь задач аккаунт-менеджера **19 / 20** закрыто как Completed Сроки **31 день** (26 марта – 26 апреля 2025), сдано в срок Затраты **50 ч / 50 ч по оценке** — без перерасхода, без расширения объёма Статус сайта Работает на WP Engine — [songbirddentalstudio.com](https://songbirddentalstudio.com/), HTTP 200, проверено в апреле 2026 Если коротко: 21 URL в 13 шаблонах на WP Engine, в рамках согласованного бюджета в 50 часов. Две очереди правок QA (SEO + аккаунт-менеджер) отработали до уровня, приемлемого для агентства, а контрольный список запуска закрыли до выхода домена. ## Контроль качества Проверка перед передачей на 21-страничной сборке на тестовой среде вскрыла две категории проблем: внутренний QA-скрипт проверил статусы страниц, метаданные, ссылки и структуру заголовков по всей карте сайта, а ручной аудит изображений нашёл присланные агентством JPG по 200–500 КБ каждый — их пакетно перегнали в WEBP, и только после этого закрылся контрольный список производительности. Проверку перед передачей прогоняли через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Собственный QA-контур агентства запускался после передачи и складывал замечания в общую очередь правок для нашего цикла исправлений, и так до финального согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Макеты Figma проанализированы, строки карты сайта подтверждены, объём оценён, согласовано 50 ч Разработка (страницы + шаблоны) ~2 недели 21 страница в 13 шаблонах; выполнено сопоставление Figma → Elementor; открыта очередь задач SEO Интеграция контента + QA ~1 неделя Контент клиента интегрирован по мере поступления; обе очереди задач QA велись параллельно; очередь задач аккаунт-менеджера закрыта на 19/20 Контрольный список запуска + сдача последние ~3 дня Подписан контрольный список на 29 пунктов; сайт запущен на WP Engine _Разработка и QA велись параллельно со второй недели; этап интеграции контента начался до закрытия всех задач этапа разработки — поэтому календарь составляет 31 день, а не сумму последовательных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — поддержка разработчика на этапах интеграции контента и исправлений в очереди задач - **Павел Сажин** — итерации QA и исправления - **Анна Полунина** — поддержка внедрения и QA - **Людмила Травкина** — ведущий разработчик, сопоставление Figma → Elementor и полная разработка в обеих фазах - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел: вся обратная связь по QA шла через общую очередь задач, и внутренняя кухня разработки до него не доходила. ## Агентствам, заказывающим разработку WordPress > В разработке стоматологического сайта именно архитектура услуг задаёт схему URL, граф структурированной разметки и позиции, за которые отвечает агентство. У этой практики — одиночная клиника с узким набором услуг; у других — сеть с несколькими адресами и перекрёстными направлениями. Риски сидят внутри самой архитектуры: разметка слетит на импорте, страницы-фильтры услуг выпадут из индекса, а новая линейка лечения на шестой месяц потребует полной миграции. Поэтому перед стартом важно спросить подрядчика не «соберёте ли вы страницы?», а «как именно вы сохраните разметку и сделаете таксономию достаточно гибкой под следующую услугу клиента?» Пришлите нам рабочую таблицу сборки, черновик карты сайта или дизайн-файлы. Мы пройдём по плану против ваших ранжируемых страниц, найдём риски по разметке и таксономии и вернём смету с фиксированными часами. Бесплатный разбор, фиксированная оценка в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-29-page-eye-care-151-days/ title: 29-страничная доработка темы для офтальмологии за 151 день type: case_study date: 2025-03-29T15:54:40+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 29 страниц оптометрической клиники на шаблонной системе Kinsta, приведённых к макетам Figma агентства на 10 шаблонах — с сохранением URL как базового ограничения для частной практики, чьи пациенты годами пользовались одними и теми же страницами лечения синдрома сухого глаза и ухода за зрением. Агентство владело дизайном и списком редиректов; мы отвечали за постраничную реализацию, цикл QA по более чем 107 отслеженным пунктам SEO и CX и за приёмку на тестовой среде, которая подтверждала: каждый адрес для пациента цел перед сдачей. ## Краткий обзор Параметр Значение Индустрия клиента Офтальмология — оптометрия (частная практика) Клиент Advanced Eye Care Professionals (Lakeville, MN) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **29 URL** — главная, лендинг лечения сухого глаза + подстраницы, лендинг товаров для зрения + страницы услуг, «О нас», карточка врача, контакты, ресурсы для пациентов, информация о страховке, лендинг блога и вспомогательные страницы Сроки 151 день (4 сентября 2025 – 2 февраля 2026), в срок Трудозатраты 73 часа — разработка, QA-итерации и управление проектом Команда 6 специалистов Шаблоны **10 повторно используемых шаблонов**, все применены на 29 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · агентская AutoQA (проверки Links / Email / Content AI) · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **Более 107 отслеженных задач SEO + CX** согласовано в очереди правок агентства в рамках контрольного списка запуска из 78 пунктов **Динамика взаимодействия** 57 задач от агентства — все закрыты к сдаче (активная фаза 28 дней, 24.09.2025 – 21.10.2025) **Раунды проверки** ≈9 раундов проверки за 151 календарный день **Контрольный список запуска** 78 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам дизайн в Figma для Advanced Eye Care Professionals и цель развёртывания на своей фирменной шаблонной системе на Kinsta. Агентство уже выполнило подготовительную работу: постраничные контент-документы в Google Docs, подробную карту сайта с привязкой старых URL к новой структуре шаблонов и Figma, в которой дизайн-система агентства была применена к стандартной таксономии услуг офтальмологической вертикали. Им нужна была команда, которая аккуратно перенесёт этот Figma на шаблон и сохранит каждый URL, которым пользовались пациенты клиники. Сохранение URL — это не техническая деталь для офтальмологического проекта, а критерий приёмки. Advanced Eye Care Professionals годами накапливала аудиторию пациентов в Lakeville: люди, которые ищут лечение сухого глаза, комплексную проверку зрения, контактные линзы или детскую офтальмологию, возвращаются по URL из закладок или найденным через поиск. Доработка темы, которая молча переименовывает slug (`/vision-care-products/contacts/` → новый путь, `/dry-eye-treatment/optilight-for-dry-eye-treatment/` исчезает), не регистрируется как ошибка в CMS — она выдаёт 404, когда пациент в следующий раз открывает сохранённую ссылку. Агентство хотело исключить именно этот сценарий: команда, которая перекраивает URL-структуру ради редакторского удобства, не считая каждый slug обязательством перед пациентом. Таксономия офтальмологических услуг на этом сайте — лечение сухого глаза (с подстраницами OptiLight и TearCare), комплексные проверки зрения, контактные линзы, неотложная помощь, лечение заболеваний глаз (катаракта, диабетическая ретинопатия, глаукома, AMD), контроль миопии, линзы и оправы, детская офтальмология и InfantSEE — это стандартный набор вертикали. Страница врача Amy M. Rudser, O.D. — основательницы клиники и главного оптометриста — располагалась по пути `/about-us/doctors-staff/`, который клиника держала годами. Сохранить этот путь, как и каждый URL услуги, нужно было до сдачи — это была обязательная проверка на тестовой среде. > **Контекст рисков.** У состоявшейся оптометрической клиники есть совокупность URL, которыми её пациенты пользуются годами — страницы лечения сухого глаза в закладках, сохранённые пути записи на приём, результаты локального поиска, указывающие на slug, которые клиника не выбирала, но от которых не может легко отказаться. Доработка темы, которая незаметно переименовывает или перестраивает эти slug для редакторского удобства, не регистрируется как ошибка в CMS. Она регистрируется как 404, когда пациент в следующий раз переходит по сохранённой ссылке. Для Advanced Eye Care Professionals контракт на URL перед пациентами охватывал не только главную страницу, но и каждую подстраницу услуг в многоуровневой таксономии — а также путь к карточке врача, которым пациенты пользовались с момента открытия клиники. Отношение к каждому slug как к обязательству, а не как к значению по умолчанию, было базовым требованием перед началом любой другой работы по доработке. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Фирменный шаблон был базовой структурой страниц. Наша задача заключалась в постраничном согласовании: где стандартный макет шаблона совпадал с Figma — мы его оставляли; где Figma требовала отклонения (лендинг лечения сухого глаза со специализированными блоками контента, секция записи на приём на странице ресурсов для пациентов, сетка логотипов страховых компаний на странице информации о страховке) — мы дорабатывали. Никакие дизайн-решения не исходили с нашей стороны. **2. Целостность URL как требование к доработке.** На офтальмологическом проекте с существующей аудиторией пациентов карта сайта — это не просто инвентаризация контента, а контракт на URL. Конечный slug каждой страницы был подтверждён относительно старого сайта и сохранён в новой структуре шаблона. Вкладка карты сайта в таблице Google Sheets содержала параллельно старые и тестовые URL; QA на любой странице, где они расходились, было критической задачей, а не стилистическим замечанием. Проверка контента и SEO в нашем Site Checker перед сдачей — мета-заголовки, проверка slug, canonical-настройки — и подтверждала целостность URL перед отправкой. **3. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 125 задач, отслеженных в этом проекте, **88 были QA-итерациями** — отдельными раундами, где агентство отмечало расхождения дизайна и контента, мы проверяли, исправляли и возвращали сборку на очередную проверку. Агентство отследило **более 107 пунктов в двух вкладках очереди правок** (57 находок SEO и 50 находок CX), согласованных в общем рабочем пространстве до окончательного утверждения. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. Попутно цикл выявил ограничение: агентство предоставило контент-документы не для всех страниц из карты сайта; там, где пробелы всплывали в очереди правок, мы брали недостающий текст напрямую с рабочего сайта клиники, а не блокировали очередь в ожидании документов, которые могли не прийти в рамках итерационного окна. **4. Доработка без дрейфа.** Каждое изменение, которое мы вносили в фирменный шаблон — будь то макет страницы, компонент секции или токен стиля — документировалось относительно Figma. Макеты карточек врача, секции форм для пациентов, блоки логотипов страховых компаний и структуры контента подстраниц сухого глаза дорабатывались в рамках страницы, а не применялись как переопределения на уровне шаблона — мы выбрали доработку в рамках страницы, потому что общие компоненты шаблона агентства повторно используются на множестве сайтов клиентов, и переопределение общего компонента для одного проекта изменило бы базовый макет для всех последующих сборок, наследующих его. Никакие изменения не проникли в общие компоненты шаблона агентства; следующий сайт офтальмологии, построенный на этом шаблоне, не унаследует никаких побочных эффектов от доработок этого проекта. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями дизайна в этом раунде, а не весь сайт — именно так доработка на шаблоне остаётся экономной без потери покрытия. Главное противоречие этого проекта — между стандартными настройками шаблона и slug, годами стоявшими в результатах поиска. Мы сверяли каждый финальный URL с двумя параллельными колонками таблицы Google Sheets — старые URL против тестовых — страница за страницей. В финальной предзапускной проверке агентство обнаружило, что XML-карта сайта недоступна: это исправление закрыли до переключения — последний барьер, который должен был пройти контракт на URL. ## Контроль качества Страница информации о страховке стала центром нагрузки QA в этом проекте — очередь правок агентства зафиксировала 31 пункт по страховке: удаление целых секций, переписывание FAQ, исправление логотипов страховых компаний и замену заголовков и текста абзацев. Финальная предзапускная проверка агентства также выявила недоступность XML-карты сайта (Redmine #1223) — её исправили и закрыли перед переключением. QA перед сдачей шёл через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Внутренний контур проверки агентства шёл после сдачи, и найденные проблемы попадали в общую очередь правок для нашего цикла исправлений, пока агентство не подписало приёмку. Доработки остались в переопределениях конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **29** — 1 главная, 1 лендинг лечения сухого глаза, 2 подстраницы сухого глаза, 1 лендинг товаров для зрения, 9 страниц услуг, 1 лендинг заболеваний глаз + 4 подстраницы заболеваний, 1 «О нас», 1 карточка врача, 1 контакты, 1 лендинг ресурсов для пациентов, 1 страница информации о страховке, 1 лендинг блога и вспомогательные страницы Задействовано шаблонов **10 из 10** повторно используемых шаблонов создано и применено на 29 страницах (главная, О нас, Страница врача, Контакты, Страница услуги, Лендинг услуг, Лендинг блога, Стандартный шаблон, Лендинг пациентов, Страница пациента) Контрольный список запуска **78 пунктов** согласовано QA / задач SEO + CX отслежено и решено **Более 107** пунктов согласовано в двух вкладках очереди правок агентства (57 SEO + 50 CX) QA-итераций в Redmine **88 из 125 задач (70%)** отслежено на уровне итераций Сроки **151 день**, сдано в срок Трудозатраты **73 часа** — без перерасхода, без расширения объёма Команда **4 специалиста** Хостинг Работает в шаблонной среде Kinsta агентства Состояние страниц при сдаче URL рабочего сайта возвращает HTTP 200 по данным независимой проверки (25.04.2026) Если коротко: Figma агентства реализован на их фирменном шаблоне на 29 страницах и 10 шаблонах за 151 календарный день в рамках оценки в 73 часа — с сохранением каждого адреса предыдущего сайта, важного для пациента. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Figma изучен, доступ к шаблону подтверждён, согласован объём карты сайта и сохранения URL Разработка доработок ~3 недели Постраничная доработка шаблона под Figma; построена таксономия сухого глаза и страниц услуг QA-итерации (параллельно) ~14 недель Зафиксировано 88 раундов QA; каждый закрыт только после согласования с агентством Раунды исправлений ~4 недели Коррекции после проверки: пункты меню, контент страховки, размещение CTA записи Сдача Финальный день Сайт запущен на Kinsta; агентство подтвердило готовность к публикации _Разработка и QA выполнялись параллельно — это характерно для работы по доработке тем, где ни одна «фаза QA» не закрывается чисто; цикл работает непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик - **Павел Сажин** — QA-итерации и исправления - **Анна Полунина** — поддержка доработки шаблона и QA - **Евгений Карпов** — разработчик (доработка шаблона и приведение Figma к макетам) - **Тимур Арбаев** — поддержка разработчика и QA-проверки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн-решения и отношения с конечным клиентом со стороны агентства оставались за партнёрским агентством от начала до конца. Advanced Eye Care Professionals не взаимодействовала с нашей командой — каждый запрос на доработку и подписание проходил через общую очередь правок агентства. Ни один раунд не закрывался, пока проверяющий со стороны агентства не подтверждал его. ## Агентствам с библиотекой шаблонов > На фирменной системе шаблонов клиентские доработки лежат поверх общего исходника, который может измениться без предупреждения. У этой практики — частная оптометрия с сервисными страницами в закладках у пациентов; у других — сеть оптик с локальными переопределениями поверх центрального бренда. Когда поставщик шаблона выкатит обновление, ваши собственные URL-схемы откатятся и пациенты упрутся в 404. Токены бренд-системы перестанут доходить до жёстко прописанных запасных значений, и дизайн поплывёт от страницы к странице. А команда клиента не сможет вести контент, если половина библиотеки блоков спрятана за кодом. Подрядчику стоит задавать не вопрос «настроите ли шаблон», а вопрос «как именно вы удержите клиентские доработки на месте при обновлении шаблона». Пришлите исходник шаблона или спецификацию бренда и черновик объёма доработок. Пройдём по вашему плану вместе, отметим места, где обновление шаблона способно тихо что-то сломать, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-41-page-dental-rebrand-47-days/ title: Доработка стоматологического шаблона на 41 страницу за 47 дней type: case_study date: 2025-03-27T13:13:06+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы Сайт Dentistry on Main Street — 41 страница на брендированном шаблоне агентства, на WP Engine. Контент перенесли с купленного сайта ESI Dentistry; все упоминания прежнего бренда, адреса и сотрудников заменили до запуска. Агентство спросило, хватит ли автозамены текста. Не хватит: мета-заголовки, биографии врачей, контактные email и адреса в тексте требовали ручной проверки. Структура из 11 шаблонов была простой — работа была в слое очистки. Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Без неё выигрыш исчезает: вольная трактовка Figma, пропущенные этапы QA, отход от дизайн-системы шаблона — и проще было бы собрать с нуля. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Общая стоматология Клиент Dentistry on Main Street (New Port Richey, FL) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на WP Engine) Объём **41 URL** — главная, о нас, страница услуг, **16 страниц услуг**, 3 биографии врачей, финансовые страницы, блог + записи, контакты и вспомогательные страницы Сроки 47 дней (19 фев – 7 апр 2025), в срок Затрачено 47 часов — разработка, QA-итерации и управление проектом Команда 4 специалиста Шаблоны **11 многоразовых шаблонов** от агентства, применённых на 41 странице Технологии WordPress · Elementor · WP Engine · Постраничный дизайн в Figma · Виджет записи FlexBook · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **25+ задач** согласовано в очереди задач агентства, 49-пунктный контрольный список запуска **Динамика проекта** 24 задачи от агентства · все закрыты к сдаче (активный период 1 день, 2025-03-20) **Раунды проверки** ≈1 раунд на 47-дневном календарном окне **Контрольный список запуска** 49 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам дизайн Dentistry on Main Street в Figma и площадку для развёртывания — свой брендированный шаблон на WP Engine. Клиника незадолго до этого купила филиал в New Port Richey у другой стоматологической группы и проводила ребрендинг под именем Dentistry on Main Street. Подготовительную работу агентство уже сделало: аудит дизайна, согласование с клиентом, настройку хостинга, выгрузку контента со старого сайта. Нужна была команда разработки, которая точно перенесёт Figma на шаблон, мигрирует старый контент и вычистит все упоминания прежнего бренда до запуска. Задача была чисто исполнительская и срочная. Figma — единственный источник истины. Дорабатывать шаблон под неё страница за страницей. Перенести контент со старого сайта, но при этом найти и заменить каждое вхождение старого названия бренда и убрать любые адреса за пределами New Port Richey. Все находки QA возвращать агентству в общем пространстве задач и не закрывать без его согласования. Агентство хотело избежать подрядчика, который проведёт ребрендинговую миграцию простым копированием с заменой. Нас спросили, можно ли прогнать по всему перенесённому контенту скрипт автозамены. Поверхностный текст он бы заменил — но не поймал бы каждое упоминание старого бренда, зависящее от контекста: мета-заголовки, email-адреса, Instagram-аккаунты, адреса в тексте — каждое требовало ручной проверки. Автозамену мы сделали первым проходом, а затем вручную выверили каждое вхождение на всех страницах — всего их 41. Старого контента было 41 страница — услуги, биографии врачей, финансовые страницы, записи блога, — и на каждой имя прежнего бренда, адреса и метаданные. Риск был не в самой доработке шаблона, а в том, что хотя бы одно устаревшее упоминание уйдёт в публикацию. Стоматологии, выходящей под новым брендом, нельзя допустить ни мета-заголовок на главной с именем предшественника, ни биографию врача с неверным городом. Именно за эту дисциплину агентство и платило — и именно её проверяла очередь из 25 QA-задач на проекте. > **Контекст рисков.** Это была не разработка с нуля, а ребрендинг сайта купленного конкурента. Клиент приобрёл филиал в New Port Richey, и старый контент — страницы услуг, биографии врачей — нужно было перенести на новый брендированный шаблон под именем Dentistry on Main Street. Риск проекта был в слое очистки: каждое вхождение старого названия бренда, каждый адрес за пределами New Port Richey, каждую устаревшую биографию врача и телефон нужно было найти и заменить на 41 странице до запуска. Один пропущенный мета-заголовок или абзац на странице услуг сорвал бы ребрендинг — а по этому сайту пациенты сверяют, та ли это клиника. Главным здесь было то, что мы убрали и заменили, а не только построили. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача была согласовать их страница за страницей — где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовала отклонения, мы вносили правки. Никакие дизайнерские решения не исходили от нас. **2. QA-цикл в масштабе доработки темы.** Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 13 задач, отслеженных на этом проекте, **9 были QA или итерациями исправлений** — отдельные раунды, в которых агентство отмечало расхождения с дизайном, несоответствия контента или проблемы очистки ребрендинга, мы проверяли, исправляли и возвращали сборку на повторную проверку. Такое число итераций — не признак нестабильности. Так и отделяется шаблонный сайт, который выглядит «примерно так», от сайта, который точно соответствует дизайну и брифу на ребрендинг. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Правки без отклонений.** За время проекта каждое изменение в брендированном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Каждую правку мы держали на её отдельной странице и не трогали общие таблицы стилей шаблона или его общие компоненты. Причина простая: тот же брендированный шаблон обслуживал другие сайты в портфеле агентства — правка на уровне шаблона тихо разошлась бы по тем сборкам. Ни одна правка не ушла в общие компоненты: работа этого проекта не ухудшила шаблон для следующего сайта. **4. Проверка на разных устройствах.** Изменения проверялись в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый QA-раунд охватывал страницы, затронутые расхождениями дизайна данного раунда, а не весь сайт, — именно так шаблонная сборка остаётся экономной без потери покрытия. Ограничением был не срок, а граница объёма: 41 страница на миграцию и очистку, адреса Tampa и упоминания ESI — убрать до запуска любой страницы. Из-за этой границы аудит контента шёл первым, до доработки шаблона. Это и сделало 9-раундный QA-цикл управляемым: каждый раунд проверял набор правок, а не перепроверял, не просочилось ли упоминание бренда-предшественника. ## Операционная целостность при сдаче QA этой ребрендинговой миграции прошёл по четырём категориям, которые мы вели в общей таблице: очистка бренда (старый адрес ESI `courtney@esidentistry.com` в футере, текст пятничных часов со ссылкой на предшественника), пять сломанных редиректов `/locations/`, дублированные meta description на семи перенесённых страницах и параметры URL `/?service=`, которые агентство попросило убрать до запуска. Предварительный QA шёл через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Собственный QA агентства запускался после сдачи и заводил замечания в общую очередь правок, которую мы закрывали до их финального согласования. Все правки остались в клиентских переопределениях; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **41** — сопоставлены с наследуемого сайта, страницы Tampa исключены по объёму ребрендинга Применено шаблонов **11 из 11** многоразовых шаблонов собраны и сопоставлены на 41 странице (главная, о нас, блог, запись блога, страница врача, страница услуг, страница услуги, шаблон по умолчанию, контакты, галерея улыбок) Контрольный список запуска **49 пунктов** согласованы QA / SEO задач отслежено и решено **25+** позиций согласовано в очереди задач агентства QA-итераций в Redmine **9 из 13 задач (69 %)** отслежено на уровне итераций Сроки **47 дней**, сдано в срок Затраты **47 часов** при оценке в 47 часов — без перерасхода, без расширения объёма Команда **4 специалиста** Хостинг Работает в среде шаблонов агентства на WP Engine Очистка ребрендинга Полный поиск и замена упоминаний бренда-предшественника и обновление адресов по всему перенесённому контенту Результат, если кратко: Figma агентства была реализована на их брендированном шаблоне на 41 странице и 11 шаблонах за 47 календарных дней в рамках оценки в 47 часов — с миграцией и очисткой наследуемого контента под новый бренд. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дней Figma изучена, доступ к шаблону подтверждён, объём наследуемого контента согласован Постраничная доработка ~2 недели Постраничная доработка темы под Figma; миграция наследуемого контента и первичная очистка бренда QA-итерации (параллельно) ~2 недели 9 раундов QA и исправлений зафиксировано; каждый закрыт только после согласования агентством Раунды исправлений ~2,5 недели Коррекции после запуска, исправления из очереди задач, уточнение цветов и финальные правки клиента Сдача финальный день Сайт запущен на WP Engine _Разработка и QA шли параллельно — это характерно для работы по доработке темы, где «этап QA» не закрывается чисто; цикл работает непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и сопоставление Figma с макетом) - **Анна Полунина** — разработчик (доработка страниц, миграция контента и стоковые изображения) - **Наталия Богатель** — разработчик (финальные изменения, внедрение дизайн-правок, исправления из очереди задач) - **Павел Сажин** — QA-итерации и проверка исправлений - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались у партнёрского агентства на всём протяжении. Наша команда была невидима для конечного клиента. Все запросы на доработку поступали через общую очередь задач агентства; ничто из сборки не было видно конечному клиенту напрямую. Каждый QA-раунд закрывался только после того, как проверяющий со стороны агентства подтверждал, что расхождение устранено. ## Агентствам с библиотекой шаблонов > На сборке по брендированному шаблону сроки ваших доработок диктует владелец шаблона. У этой практики — одна клиника, которая берёт шаблон как есть; у других — сеть с несколькими локациями, наследующая весь стек контента. Переопределения в дочерней теме ломаются, когда поставщик выкатывает обновление; бренд-токены перестают доходить до жёстко прописанных значений; старая схема слетает при импорте. Вопрос не «соберёте ли по шаблону?», а «как именно вы изолируете правки от следующего обновления шаблона и защитите контент, который уже в выдаче?» Пришлите исходник шаблона или его идентификатор и бренд-гайд. Мы проследим, как ваши переопределения сходятся со схемой поставщика, покажем, где передача контента требует особого внимания, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-54-page-dental-84-days/ title: Доработка темы для стоматологии: 54 страницы за 84 дня type: case_study date: 2025-03-21T09:36:33+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 54 страницы сайта стоматологической практики полного спектра в Austin — доработка шаблона dental-template6 от агентства по макетам Figma, покрывающим 10 шаблонов страниц: лендинг услуг, 39 страниц услуг по семи подспециальностям, карточка врача, ресурсы для пациентов и контакты. Клиент предоставил контент, написанный под оригинальный шаблон, а не под Figma, поэтому для каждой страницы требовалось согласовать то, что дизайн запрашивает, с тем, что предполагает копирайтинг — и этот единообразный подход применялся на всех 39 страницах услуг. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Индустрия клиента Медицина — общая и специализированная стоматология Конечный клиент Dentaire Dental (Austin, TX) **Формат сотрудничества** **White-label — доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн в Figma, хостинг Kinsta) Объём **54 URL** — главная, о нас, лендинг услуг, **39 страниц услуг** по 7 подспециальностям, карточка врача, ресурсы для пациентов (6 страниц), контакты, лендинг блога Сроки 84 дня (15 авг – 7 ноя 2025), в срок Трудозатраты 70 часов — разработка, QA-итерации и управление проектом Команда 6 специалистов Шаблоны **10 переиспользуемых шаблонов**, предоставленных агентством, все применены на 54 страницах Технологии WordPress · Elementor · Хостинг Kinsta · Постраничный дизайн в Figma · AutoQA агентства (проверка ссылок/email) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **142+ отслеженных SEO-проблем** плюс 67 пунктов обратной связи клиента, согласованных по контрольному списку запуска из 77 пунктов **Динамика работы** 79 задач от агентства · 78 из 79 закрыты к моменту сдачи (активная фаза 31 день, 2025-09-12 – 2025-10-12) **Раунды проверки** ≈6 раундов проверки за 84 календарных дня **Контрольный список запуска** 77 пунктов, согласованы до запуска ## Постановка задачи Маркетинговое агентство из США предоставило дизайн Figma для Dentaire Dental и доступ к своей фирменной системе шаблонов на Kinsta. Агентство выполнило предварительную подготовку: согласованный с клиентом дизайн, настройку хостинга и карту сайта в Google Sheets с назначением шаблонов по страницам и ссылками на контент. Наша задача — взять Figma как единственный источник истины, постранично наложить её на шаблон и держать цикл проверки открытым до согласования. Задача была чисто исполнительской: каждое отклонение от стандарта шаблона — точно по Figma, по 10 шаблонам применённым 54 раза, без дизайн-решений с нашей стороны. Конкретный риск, который агентство стремилось предотвратить, — разрастание объёма из-за масштаба и широты. Dentaire Dental — это не узкоспециализированный стоматологический кабинет; он охватывает семейную стоматологию, профилактику, косметические процедуры, реставрацию, ортодонтию, хирургию полости рта, специализированные услуги, стоматологические технологии и неотложную помощь — 39 страниц услуг, организованных в 7 подспециализаций под одним лендингом услуг. На сайте с таким количеством тематически сгруппированных страниц услуг, каждая из которых использует один и тот же шаблон страницы услуги, но требует своего сопоставления контента, команда, применяющая вариации уровня шаблона непоследовательно, создаёт фрагментированный результат, где страницы одной подспециализации выглядят проработанными, а другой — как заполнители. Агентство выбрало нас за подход — применить одинаковый стандарт доработки ко всем 39 страницам единообразно — от самой узкой страницы услуги до самого широкого лендинга подспециализации. > **Контекст рисков.** При 39 страницах услуг по 7 подспециализациям, построенным на одном и том же шаблоне страницы услуги, зон, где постраничные переопределения могут незаметно просачиваться в общий слой шаблона, больше, чем на стандартном стоматологическом сайте. Доработка, правильно применённая к ветке Cosmetic, но случайно затрагивающая общий компонент, а не слой конкретного клиента, загрязняет каждую подспециализацию, которая его наследует — и на сайте из 54 страниц это загрязнение может не проявиться до нескольких QA-раундов. Соблюдение границы постраничных переопределений на всех 39 применениях, ветка за веткой, — вот конкретный подход, которого требовала эта работа. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Фирменный шаблон — базовой структурой страницы. Наша задача заключалась в том, чтобы постранично согласовать их: там, где стандартная вёрстка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения, мы дорабатывали. Никаких дизайн-решений с нашей стороны. **2. Таксономия подспециализаций — спроецирована, а не угадана.** 39 страниц услуг Dentaire Dental — это не плоский список, а таксономия из семи ветвей (Family, Preventive, Cosmetic, Restorative, Orthodontic, Oral Surgery, Specialty, Emergency, Technology). Карта сайта задавала структуру; наша задача — сделать так, чтобы каждое вхождение шаблона страницы услуги было единообразным внутри своей ветки, а переход от одной подспециализации к другой ощущался непрерывным, а не лоскутным. H1, мета-структура и расположение контентных блоков каждой страницы были взяты из Figma агентства и ссылок на контент — не интерпретированы. Когда предоставленный контент не совпадал со структурой блоков Figma, расхождение отмечалось для решения агентством, а не закрывалось предположением. **3. QA-цикл в масштабе мультиспециализации.** Из 40 задач, отслеживаемых в Redmine, 24 имели метку QA — отдельные раунды, где агентство отмечало расхождения с дизайном или изменения по запросу клиента, мы исправляли и возвращали на проверку. Помимо Redmine, общая очередь задач агентства накопила 142+ SEO-замечания по контрольному списку запуска из 77 пунктов, плюс отдельный слой комментариев с 67 пунктами, отправленными напрямую конечным клиентом через инструмент визуального аннотирования. Оба канала замыкались на один цикл исправлений — ничего не накапливалось без обработки. Работа шла по двум потокам: структурированные задачи Redmine под управлением агентства и свободные визуальные аннотации напрямую от клиента. Их приоритеты иногда расходились; то, что выходило за рамки исходной Figma, уходило в постзапускную очередь агентства, а не исправлялось в процессе сборки. **4. Доработка без дрейфа.** Каждое изменение, которое мы вносили в фирменный шаблон — макет страницы, компонент секции или стилевой токен — оставалось в пределах переопределений для данного клиента. Шаблон страницы услуги, применённый 39 раз, оставался единообразным на всём сайте, потому что ни одна доработка не вносила правки в общий компонент вместо послойного переопределения. У шаблона, обрабатывающего 39 страниц услуг по семи подспециализациям, больше зон, где постраничные переопределения могут незаметно просочиться в общую логику шаблона; соблюдение границы на каждой итерации — это тот подход, который покупало агентство. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый QA-раунд покрывал страницы, затронутые изменениями этого раунда, вместо повторного аудита всех 54 страниц — именно так крупная доработка темы остаётся экономной без потери покрытия. Клиент предоставил копирайтинг, написанный под оригинальный шаблон, а не под Figma, поэтому каждая страница, столкнувшаяся с этим расхождением, требовала решения: отметить и ждать решения агентства или закрыть предположением. Мы отмечали каждое. Именно это — отмечать расхождения, а не интерпретировать — позволило сохранить единообразие 39 страниц услуг по всем семи ветвям подспециализаций без накопления редакционного дрейфа в процессе сборки. ## Контроль качества QA на этой сборке выявило две категории проблем до сдачи: контент, предоставленный клиентом, был написан под оригинальный шаблон, а не под Figma — расхождения по 54 страницам отмечены и согласованы до проверки агентством — и og:locale был установлен на GB вместо US, обнаружено в SEO-контрольном списке и исправлено до сдачи. Предпусковое QA проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) для списка категорий и порога нулевых ошибок. Контроль на стороне агентства работал после сдачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до получения согласования. Доработки остались в переопределениях для данного клиента; общие компоненты шаблона агентства не были изменены. ## Результаты Метрика Результат URL сдано **54** — 1 главная, 1 лендинг услуг, 39 страниц услуг по 7 подспециальностям, 1 карточка врача, 1 о нас, 1 контакты, 1 лендинг блога, 6 страниц ресурсов для пациентов, 1 галерея улыбок Шаблонов применено **10 из 10** переиспользуемых шаблонов построено и сопоставлено на 54 страницах Контрольный список запуска **77 пунктов** согласовано QA/SEO-проблем отслежено и решено **142+** пунктов из SEO-очереди задач плюс 67 аннотаций обратной связи клиента, согласованных в Google Sheets агентства QA-итерации в Redmine **24 из 40 задач (60%)** отслежено на уровне итераций Сроки **84 дня**, сдано в срок Трудозатраты **70 часов** — без перерасхода, без расширения объёма Команда **6 специалистов** Хостинг при сдаче Работает в шаблонном окружении агентства на Kinsta Здоровье страниц при сдаче **53 / 54** URL на тестовой среде вернули HTTP 200; 1 редирект обработан по инструкции агентства Если коротко: Figma агентства была реализована на их фирменном шаблоне на 54 страницах и 10 шаблонах за 84 календарных дня в рамках оценки в 70 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к шаблону подтверждён, объём и структура таксономии согласованы Разработка доработок ~4 недели Постраничная доработка темы; все 7 ветвей подспециализаций построены по Figma QA-итерации (параллельно) ~8 недель 24 QA-раунда зафиксировано в Redmine; очередь задач агентства + цикл обратной связи клиента работали параллельно Раунды исправлений ~2 недели 142+ пунктов из SEO-очереди задач и 67 комментариев обратной связи обработаны Сдача финальный день Сайт запущен на Kinsta _Разработка и QA шли параллельно — это характерно для работы по доработке темы, где нет чёткого закрытия «фазы QA»; цикл работает непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (первичная доработка темы и сопоставление Figma с вёрсткой) - **Павел Сажин** — ведущий QA (итерационные раунды, проверка очереди задач агентства, координация согласования) - **Анна Полунина** — поддержка доработки темы и QA - **Тимур Арбаев** — поддержка разработки на поздних раундах доработки - **Людмила Травкина** — разработчик (основное выполнение сборки по всем 54 страницам и мультиспециализационным веткам) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Все запросы на доработку от конечного клиента поступали к нам через общую систему проверки агентства. Конечный клиент нас не видел. Каждый QA-раунд выпускался только после того, как проверяющий со стороны агентства подтверждал, что изменения соответствуют спецификации. ## Агентствам с библиотекой шаблонов > На фирменном шаблоне структурный риск 1 — граница между общим слоем шаблона и переопределениями конкретного клиента. У этой практики переопределения растягиваются по страницам услуг одного кабинета; у других это сеть клиник DSO под единым брендом, где 1 шаблон обслуживает совершенно разные клиники. Переопределения в дочерней теме ломаются, когда поставщик шаблона выпускает обновление. Клиентский слой расходится с канонической схемой шаблона — новые поля специализации перестают наполнять архивные виды, на которые опирается агентство. Бренд-токены перестают доходить до скрытых жёстко прописанных значений, как только клиент впервые меняет цвет в кастомайзере. Подрядчику стоит задавать не вопрос «развернёте ли вы шаблон?», а вопрос «как именно вы ограничите клиентский слой, чтобы следующее обновление шаблона его незаметно не сломало?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы прогоним его по штатному набору модулей поставщика шаблона, найдём, где ваши доработки задевают общую схему, и вернём фиксированную смету в часах. Аудит без оплаты, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-pediatric-dental-85h-120-days/ title: 43-страничный сайт детской стоматологии на WordPress за 120 дней type: case_study date: 2025-03-17T21:25:27+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 43 страницы сайта детской стоматологии под жёсткий срок отключения: старый сайт уходил в офлайн 31 января. Первый этап мы сдали по индивидуальному дизайну за 10 дней. Когда выяснилось, что этот дизайн принадлежит сторонней студии, а не агентству, проект перешёл в фазу доработки темы: все 43 URL перенесли в шаблонную систему агентства, не увеличивая бюджет в 85 часов. ## Краткий обзор Параметр Значение Сфера клиента Медицина — детская стоматология Клиент Little Roots Pediatric Dental (Westbury, NY) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor Pro на WP Engine, индивидуальный дизайн, затем этап доработки темы Объём **43 URL** — главная, о нас, 2 страницы врачей, страница услуг, 4 страницы услуг, страница лечения, 22 страницы лечения, адреса, контакты, первый визит, страховка, абонемент, акции и вспомогательные страницы Сроки 120 дней (11 янв – 10 мая 2025), выполнено в срок Затраты **85 часов** при оценке 85 часов — без перерасхода Команда 5 специалистов (41 ч разработка · 25 ч доработка темы · 5 ч PM · остальное — раунды исправлений и QA) Шаблоны **Индивидуальная дизайн-система** — макеты по типам страниц на 43 URL (главная, страница услуг, страницы лечения, био врачей и вспомогательные страницы) Технологии WordPress · Elementor Pro · WP Engine · Yoast · виджеты записи ZocDoc · NitroPack · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **43 URL построены по индивидуальной дизайн-системе, контрольный список запуска на 49 пунктов закрыт, очередь ошибок + Design issues + Meta issues проработаны, два QA-направления закрыты до передачи** **Ритм взаимодействия** 8 задач от агентства · все закрыты к моменту передачи **Раунды проверки** ≈8 раундов за 120 дней **Контрольный список запуска** 49 пунктов, согласованы до переключения ## Постановка задачи Little Roots Pediatric Dental — это детская стоматология с двумя врачами в Westbury, New York, обслуживающая детей по всему округу Nassau. Маркетинговое агентство из США, специализирующееся на сайтах для локального бизнеса, управляло проектом: за ним были индивидуальный дизайн, контент-стратегия, хостинг на WP Engine и отношения с клиентом. В нашу зону ответственности входила разработка полноценного сайта на 43 URL в WordPress с Elementor Pro, интеграция виджета записи ZocDoc, внедрение мета-полей Yoast согласно значениям из таблицы Google Sheets и передача готового к работе сайта. Таблица Google Sheets структурировала проект по 43 активным URL, привязанным к единой индивидуальной дизайн-системе. Объём по строкам карты сайта мы оценили сами — в сумме 52 часа на основную разработку. Задача была разбита на этапы: сначала построить все страницы по этому дизайну; затем, во втором этапе — который агентство называет «Templated Design Development» — принять постраничные расхождения с дизайном, согласовать мета-вопросы и проработать очередь ошибок. Дизайн, контент, SEO-стратегия и общение с клиентом оставались на стороне агентства. > **Контекст рисков.** Сайт детской стоматологии работает одновременно с двумя аудиториями: родителем, который записывается на приём, и ребёнком, который будет сидеть в кресле. Агентство искало партнёра-разработчика, который сохранит понятный родителям тон общения и точность клинической информации на 22 страницах лечения, 4 страницах услуг и 2 страницах биографий врачей. Разработка, при которой страницы «выглядят правильно», но не проверен тон для родителей и не протестирована маршрутизация виджета ZocDoc, может выдать сайт, который запутает первого же органического посетителя. Риск не в том, чтобы сверстать 43 страницы; он в том, чтобы передать сайт, второй этап которого не закрыт, а партнёр-разработчик воспринял первый запуск как финишную черту. Дополнительное ограничение возникло после начальной разработки: дизайн принадлежал сторонней студии, а не агентству, поэтому дизайн-систему нельзя было перенести в этап Templated Design Development без лицензионных переговоров. ## Как мы это сделали **1. Индивидуальная дизайн-система, 43 страницы, единый процесс сборки.** 43 страницы сайта распределились по макетам разных типов из дизайна агентства: Главная (1), О нас (1), Страница врача (2 — Dr. Jessica Barzideh DMD и Dr. Sunaina Vohra DMD), Страница услуг (1), Страница услуги (4 — неотложная, восстановительная, профилактическая и седативная стоматология), Страница лечения (1), Страница лечения (22 отдельные детские процедуры), Адреса (1 + место для записи) и вспомогательные страницы (первый визит, страховка, абонемент, акции, контакты и технические страницы). Каждую страницу мы сопоставили со своей дизайн-спецификацией из строки sitemap до того, как написали хотя бы одну строку Elementor. Когда в ходе начальной разработки выяснилось, что дизайн принадлежит сторонней студии, этап Templated Design Development перенёс сайт в стандартную библиотеку шаблонов агентства — это оказалось быстрее, чем лицензионные переговоры с первоначальным владельцем, при этом оставшиеся 43 страницы шли по графику. **2. Спецификация исполнена строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта — главная получила больший бюджет, страницы лечения стандартный. В сумме проект уложился в согласованные 85 часов. Коротко: в разработке с предварительно оценённым sitemap таблица Google Sheets — это контракт. Задача команды разработчиков — уложиться в согласованную смету, а не открывать обсуждение цены страница за страницей. **3. Два параллельных QA-контура, закрытых до запуска.** Вопросы отслеживались в нескольких вкладках очереди задач на стороне агентства: очередь ошибок (9 строк), Design issues (1 строка) и Meta issues (77 строк). Из 87 отслеживаемых пунктов критически важные решили до запуска; остальные распределили по приоритетам и обработали в рамках этапа доработки темы. Контрольный список запуска на 49 пунктов — охватывающий дизайн, функциональность, контент и SEO — закрыли после обеих очередей задач. **4. Интеграция виджета записи ZocDoc и работа с гео-страницами.** На сайте установлен виджет записи ZocDoc для онлайн-бронирования — конверсионный примитив для детской практики, где родительская срочность высока. В ходе разработки виджет мы проверили на соответствие профилю практики в ZocDoc, чтобы запросы на приём направлялись в правильный филиал Westbury. Позже, уже на поддержке, мы добавили гео-страницы для соседних городов округа Nassau (Albertson, Garden City, East Meadow, Jericho, Hicksville и других) — это расширило охват в локальном поиске, не ломая исходную структуру URL. Срок 31 января означал, что первый этап нужно сдать за 10 дней — из-за этого порядка проблема с лицензией на дизайн всплыла после запуска, а не до него. Этап доработки темы вместил эту находку без пересмотра бюджета: почасовые оценки из исходной таблицы напрямую перенеслись в фазу согласования. ## Контроль качества QA перед сдачей на этапе начальной разработки прогнал проверку ссылок: она выявила битые HTTPS-ссылки по всему дереву из 43 URL и повторяющийся дефект slug на страницах услуг — «постоянно буквы не хватает» — это исправили до того, как тестовая среда попала к агентству. QA на этапе доработки темы затем поймал сломанное мобильное меню при первом открытии — поправили до закрытия этапа. QA перед сдачей проходил через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Собственный контур QA агентства работал после передачи и заводил замечания в общую очередь правок для нашего цикла исправлений, пока агентство не подтверждало готовность. ## Результаты Метрика Результат Разработано URL **43** — Главная (1) · О нас (1) · Страница врача (2) · Страница услуг (1) · Страница услуги (4) · Страница лечения (1) · Страница лечения (22) · Адреса и вспомогательные страницы (11) Дизайн-система **Индивидуальный дизайн**, применён ко всем 43 URL, макеты по типам страниц согласно спецификации агентства Контрольный список запуска **49 пунктов** согласованы по категориям Дизайн / Функциональность / Контент / SEO Очередь ошибок **2 / 9** выполнено к моменту передачи; остальные распределены и решены в рамках этапа доработки темы Meta issues **77 строк** просмотрены и проработаны в фазе согласования Сроки **120 дней** на два этапа, выполнено в срок Затраты **85 ч / оценка 85 ч** — без перерасхода, без расширения объёма Команда **5 специалистов** **Статус сайта** Работает на WP Engine, открывается по адресу https://www.littlerootspediatricdental.com/ — проверено в апреле 2026. Если коротко: 43 URL по индивидуальной дизайн-системе на WP Engine, в рамках согласованного бюджета 85 часов. Обе QA-очереди задач были проработаны до уровня приемки агентством, и контрольный список запуска был закрыт до выкладки сайта в работу. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя таблица Google Sheets проверена, построчные часы подтверждены, оценка 85 ч согласована Разработка (страницы + шаблоны) ~5 недель Все 43 страницы построены по индивидуальной дизайн-системе; открыты вкладки очереди ошибок и Meta issues Доработка темы ~4 недели Постраничные расхождения с дизайном согласованы, обе QA-очереди задач проработаны до уровня приемки агентством Контрольный список запуска + исправления после запуска финальные ~2 недели Контрольный список на 49 пунктов согласован; применены раунды исправлений после запуска Сдача финальный день Сайт запущен на littlerootspediatricdental.com, HTTP 200 подтверждён _Разработка и QA шли параллельно с третьей недели; этап доработки темы начался до закрытия всех пунктов QA основного этапа — поэтому календарь составляет 120 дней, а не сумму последовательных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на этапах разработки и доработки темы - **Павел Сажин** — управление проектом и QA-итерации - **Анна Полунина** — координация проекта, подтверждение объёма и проверка очереди задач - **Алексей Шалагин** — QA-итерации и работа с мета-данными - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и общение с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте детской стоматологии за внешними страницами стоит таксономия URL, от которой зависят и позиции, и запись на приём. У этой практики один кабинет с детским направлением; у других — сетевая стоматология под единым брендом. Через полгода клиент добавляет новую услугу, и она не встаёт в зафиксированную URL-схему. После миграции контента страницы-фильтры выпадают из индекса. На импорте слетает структурированная разметка — и расширенные результаты пропадают из выдачи. Подрядчику стоит спрашивать не «сверстаете ли страницы». Спрашивать стоит: «как именно вы построите таксономию, чтобы новая услуга встала без миграции, а формы не отвалились молча на интеграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы пройдём таксономию против дорожной карты услуг клиента, проверим, что структурированная разметка и фильтры переживут изменения, и вернём фиксированную смету в часах. Бесплатно, с твёрдой сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-32-page-airway-dental-55-days/ title: Доработка стоматологического шаблона (дыхательные пути): 32 страницы за 55 дней type: case_study date: 2025-03-11T11:21:54+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 32 страницы ортодонтической клиники (дыхательные пути), доработанные по Figma на шаблоне агентства «Luminous» — 12 шаблонов, 17 часов, 55 дней. В середине разработки агентство изменило архитектуру URL с `/services/service-name/` на плоские `//` для SEO; каждую внутреннюю ссылку, пункт меню и плитку страницы услуг на 32-страничном сайте пришлось перепроверить до передачи. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. 32 страницы за 17 часов: из-за плотности решений по гигиене страниц и перестройки URL в середине разработки именно цикл QA удерживал сдачу. ## Краткий обзор Параметр Значение Отрасль конечного клиента Здравоохранение — стоматология (ортодонтия дыхательных путей) Конечный клиент The Holistic Airway Dentist (стоматологическая клиника в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн Figma на Kinsta) Объём **32 активных URL** — главная, страница услуг, 13 страниц ортодонтии и услуг по дыхательным путям, галерея улыбок, 8 страниц страховок, финансирование, about us, лента блога, контакты и вспомогательные страницы (6 дополнительных страниц скрыты: дубликаты, заполнители и черновые URL) Сроки 55 дней (26 окт – 20 дек 2025), по графику Трудоёмкость 17 часов — разработка, итерации QA и управление проектом Команда 4 специалиста Шаблоны **12 повторно используемых шаблонов**, предоставленных агентством, применены на 32 активных страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **12 задач обратной связи от агентства** плюс последующие раунды QA, согласованные в контрольном списке из 78 пунктов **Раунды проверки** ≈4 раунда проверки за 55 календарных дней **Контрольный список запуска** 78 пунктов, согласован перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для The Holistic Airway Dentist и цель развёртывания на своей фирменной системе шаблонов под Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, согласование с клиентом, настройка хостинга, контент-план. Им нужна была команда разработчиков, которая добросовестно перенесёт Figma в шаблон через столько итераций доработки, сколько потребует дизайн. Задача была чисто исполнительской. Figma — единственный источник истины. Дорабатывать шаблон под неё страница за страницей, точка адаптации за точкой адаптации. Все находки QA возвращать агентству в общее пространство задач и не закрывать без его согласования. Агентству нужно было обезопасить себя от подрядчика, который отнёсся бы к компактному проекту на 17 часов как к «быстрой правке главной». Изначальный запрос был одиночной доработкой главной, но карта сайта выявила 32 URL — включая 13 страниц ортодонтии и услуг по дыхательным путям, 8 страниц страховок и галерею улыбок. В шаблонной сборке даже небольшой объём быстро разрастается: каждая страница услуг использует тот же шаблон, но требует собственных текстов, изображений и CTA по Figma. Команда, остановившаяся на главной, оставляет агентству наполовину доработанный сайт, где стандартные настройки шаблона уходят на страницы, видимые пациентам. 46 задач, отслеженных в этом проекте — большинство из них по гигиене страниц и QA, — это запись той работы, что здесь была нужна, чтобы этого не допустить. > **Контекст рисков.** В середине разработки агентство изменило архитектуру URL: страницы услуг должны были переехать с `/services/service-name/` на плоские `//` для SEO. В рабочей сборке, где внутренние ссылки уже были подключены, это было не простым изменением редиректов — потребовалась сквозная проверка ссылок по всему сайту для обновления каждого адреса до передачи. Риск в этом проекте заключался в том, что структурное изменение в середине разработки породит битые внутренние ссылки, осиротевшие пути `/services/` и несогласованную навигацию на 32 страницах. Главным было постранично проверить реструктуризацию: каждый пункт меню, плитка страницы услуг и внутренняя перекрёстная ссылка проверялись на соответствие новому плоскому URL, а страницы-дубликаты и заполнители сдерживались, чтобы они никогда не попали на опубликованные URL. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страниц. Наша задача заключалась в постраничном согласовании двух: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Система обратной связи агентства сгенерировала 12 параллельных задач за один раунд проверки — каждая задача по конкретной странице: черновые ссылки на страницах страховок, дублирующиеся галереи улыбок, страницы-заполнители блога, стандартные страницы шаблона, которые нужно было скрыть, и секции FAQ, которые пришлось удалить. Каждую задачу мы решали и возвращали агентству на подтверждение перед следующим раундом. Этот объём — не признак нестабильности; именно это отличает шаблонный сайт, выглядящий «приблизительно правильно», от сайта, точно соответствующего дизайну. **3. Доработка без расхождения.** За время проекта каждое изменение в фирменном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Ни одна доработка не утекла в общие компоненты шаблона, поэтому работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями текущего раунда, а не весь сайт, — именно так доработка темы остаётся экономной без потери покрытия. Изменение URL в середине разработки — пути `/services/` были уплощены до коротких адресов после подключения внутренних ссылок — стало ограничением, определившим финальный раунд QA. Для его разрешения потребовалась сквозная проверка ссылок по всему сайту: каждый пункт меню, плитка страницы услуг и внутренняя перекрёстная ссылка проверены на соответствие новой структуре URL до вывода любой страницы из тестовой среды. 6 страниц оставались скрытыми до завершения этой проверки. ## Контроль качества QA перед сдачей выявило черновые ссылки на страницах страховок — проверка агентства отметила страницу Humana и указала проверить все 8 страниц страховок, — а также стандартные секции FAQ из шаблона, попавшие на 3 страницы, и страницы-дубликаты, требующие сокрытия, всё в дополнение к проверке ссылок после реструктуризации URL, запущенной в середине разработки, когда пути `/services/` были уплощены до коротких адресов. QA перед сдачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Контроль на стороне агентства запускался после передачи и фиксировал замечания в общем журнале для нашего цикла исправлений до их согласования. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL доставлено **32 активных** — 1 главная, 1 страница услуг, 13 страниц ортодонтии и услуг по дыхательным путям, 1 галерея улыбок, 8 страниц страховок, 1 финансирование, 1 about us, 1 лента блога, 1 контакты и 4 вспомогательных страницы (6 дополнительных страниц скрыты как дубликаты, заполнители или черновые URL) Применено шаблонов **12 из 12** повторно используемых шаблонов созданы и сопоставлены на 32 активных страницах (главная, Services Lander, Service Page, Smile Gallery, Financing, Insurance, About Us, Doctor Page, Blog Lander, Contact Us, Privacy Policy, Default Template) Контрольный список запуска **78 пунктов** согласованы Отслежено и решено задач обратной связи агентства **12 задач** из первичного раунда проверки плюс последующие раунды QA, все согласованы Отслежено задач Redmine **46 задач** Сроки **55 дней**, доставлено по графику Трудоёмкость **17 часов** — без перерасхода, без расширения объёма Команда **4 специалиста** Передача хостинга Работает в среде шаблонов Kinsta агентства Состояние страниц при передаче **32 / 32** активных URL на тестовой среде возвращали HTTP 200 в аудите карты сайта Если коротко: Figma агентства был реализован на их фирменном шаблоне на 32 активных страницах и 12 шаблонах за 55 календарных дней в рамках оценки в 17 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma просмотрен, доступ к шаблону подтверждён, объём согласован Разработка доработки ~3 недели Доработка главной и шаблонов страниц услуг под Figma; созданы страницы страховок и финансирования Итерации QA (параллельно) ~3 недели 12 задач обратной связи агентства плюс последующие раунды; каждый закрыт только после согласования с агентством Раунды правок ~1 неделя Сквозная проверка ссылок по всему сайту после реструктуризации URL, удаление дубликатов страниц, очистка заполнителей Сдача проекта Финальный день Сайт размещён на Kinsta _Разработка и QA выполнялись параллельно — это характерно для доработки темы, где «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона и перенос Figma в макет) - **Павел Сажин** — итерации QA и правки - **Тимур Арбаев** — поддержка разработчика и QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороной агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне партнёрского агентства на всём протяжении. Конечный клиент нас не видел: все запросы на доработку шли через общий журнал задач агентства, и сама сборка ему напрямую не показывалась. Каждый раунд QA закрывался только после подтверждения рецензентом агентства, что расхождение устранено. ## Агентствам с библиотекой шаблонов > В фирменной системе шаблонов общий слой и клиентские переопределения образуют незаметный разлом. У этой клиники — одна точка с собственным брендом на шаблоне; у других — сеть из нескольких филиалов, где общий шаблон растянут на разных провайдеров. Дочерняя тема сломается, когда поставщик шаблона выпустит очередное обновление. Токены цвета бренда перестанут расходиться по сайту после первой правки клиента в настройщике. Контент-команда упрётся в стену, когда блоки спрячут за кодом. Подрядчику стоит задавать не вопрос «соберёте ли на готовом шаблоне?», а вопрос «как именно сохраните клиентские переопределения целыми при обновлениях шаблона?» Пришлите исходник шаблона (или его ID) и спецификацию бренда. Мы пройдёмся по слою дочерней темы, найдём переопределения, которые не переживут следующее обновление поставщика, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-42-page-dental-79-days/ title: Доработка темы для стоматологической клиники — 42 страницы за 79 дней type: case_study date: 2025-03-06T18:11:40+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 42 страницы стоматологической практики в Colorado, собранных из фирменного шаблона dental-template12 агентства с четырьмя лицензированными гарнитурами — Helvetica Neue, Proxima Nova, Brandon Grotesque и Magister — которые пришлось найти до того, как сборка могла совпасть с Figma. QA-проход выявил контент из другой практики, оставшийся в шаблоне и обнаруженный на критичных для запуска страницах; очистка и закрытие 120 зафиксированных задач по 79-пунктному контрольному списку — вот что потребовало 79-дневного взаимодействия. Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Поле Значение Отрасль конечного клиента Стоматология — общая практика Конечный клиент Rivers Dentistry (стоматологическая практика в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка WordPress-шаблона (фирменный шаблон агентства + дизайн по Figma для каждой страницы, на Kinsta) Объём работ **42 URL** — главная, О нас, лендинг услуг, **23 страницы услуг**, биография врача, контакты, лендинг блога + шаблон поста, галерея улыбок Сроки 79 дней (19 авг. – 6 нояб. 2025), в срок Трудозатраты 103 часа — 41 ч разработка · 43 ч QA-итерации · 15 ч PM · 4 ч правки Команда 4 специалиста Шаблоны **11 переиспользуемых шаблонов**, предоставленных агентством, применены по всем 42 страницам Технологический стек WordPress · Elementor · Kinsta · дизайн по Figma для каждой страницы · AutoQA агентства (проверки ссылок / email / Content AI) · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Подход к QA** **120+ отслеживаемых SEO + CX задач** разобраны в очереди задач агентства по 79-пунктному контрольному списку запуска **Ритм взаимодействия** 120 задач, поставленных агентством · 118 из 120 закрыты к сдаче (активный период 18 дней: 12.10.2025 – 29.10.2025) **Раунды проверки** ≈7 раундов проверки за 79 календарных дней **Контрольный список запуска** 79 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам дизайн в Figma для Rivers Dentistry и цель развёртывания — их фирменную шаблонную систему на Kinsta. Агентство уже выполнило работу на предыдущих этапах: аудит дизайна, утверждение клиентом, настройка хостинга, план контента. Им нужна была команда разработчиков, которая точно наложит Figma на шаблон — через любое количество итераций доработки, какого потребует дизайн. Задача была чисто исполнительская. Figma — единственный источник истины. Дорабатывать шаблон под Figma постранично, на каждой точке адаптации. Возвращать QA-замечания агентству в общее рабочее пространство; не закрывать их без согласования с агентством. Риск, который агентство хотело исключить, — команда разработчиков, которая изменяет общие компоненты шаблона ради соблюдения срока. Такой обходной путь выглядит незаметным, пока агентство не обнаружит, что то же «исправление» деградировало сайт другого клиента, работающего на том же шаблоне. Стоматологический шаблон в активном использовании обслуживает несколько практик одновременно; доработка для одного проекта не может проникнуть в общий слой. Именно эту дисциплину нанимало агентство — и именно для её подтверждения был выстроен 41-раундовый QA-цикл в этом проекте. > **Контекст рисков.** Стоматологический шаблон, активно используемый несколькими клиентами, не принадлежит ни одному конкретному проекту. Команда разработчиков, изменяющая общий компонент ради соблюдения срока по Rivers Dentistry, поставляет не только проблему Rivers Dentistry — она поставляет тихую деградацию каждой другой практике, чей сайт наследует этот компонент. Этот сбой не появляется в QA-проходе самого проекта; он появляется через несколько недель, на сайте другого клиента, когда агентство уже перешло к следующему. Держать доработки строго в пределах клиентских переопределений — единственный способ защитить и шаблонные инвестиции агентства, и клиентов, которые от них зависят. ## Как мы это сделали **1. Figma как контракт, шаблон как канва.** Файл Figma был спецификацией дизайна. Фирменный шаблон — базовой структурой страниц. Наша задача — свести их воедино страница за страницей: где стандартная вёрстка шаблона совпадала с Figma, мы её сохраняли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не принимались с нашей стороны. Мы использовали клиентские переопределения, не изменяя общие компоненты шаблона, — поскольку шаблон одновременно обслуживал несколько практик, изменение общего слоя распространялось бы незаметно на других клиентов того же шаблона. **2. QA-цикл на масштабе доработки темы.** Чистая доработка темы — это не «собрал один раз, проверил один раз». Это «собрал, QA, поправил, QA, поправил». Из 58 задач, отслеживавшихся в этом проекте, **41 — QA-итерации**: отдельные раунды, в которых агентство отмечало расхождения в дизайне, мы разбирали их, исправляли и возвращали сборку на следующую проверку. Такой объём — не признак нестабильности; именно это отличает шаблонный сайт, выглядящий «примерно правильно», от сайта, совпадающего с дизайном. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. Обратная сторона — QA-часы могут превысить часы разработки: 43 из 103 часов проекта ушло на итерации — потому что каждое отклонение от общего шаблона требовало согласования агентства прежде, чем задача могла закрыться. **3. Доработка без дрейфа.** На протяжении всего проекта каждое изменение, вносимое нами в фирменный шаблон — будь то вёрстка страницы, секционный компонент или стилевой токен — документировалось относительно референса в Figma. Ни одна доработка не «утекала» в общие компоненты шаблона, что означает: работа этого проекта не деградировала шаблон для следующего сайта, который будет на нём работать. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на компьютере, планшете и мобильных экранах — стандартный набор точек адаптации агентства. Каждый QA-раунд охватывал страницы, затронутые расхождениями данного раунда, а не весь сайт, — так доработка темы остаётся экономной, не теряя охвата. Постраничный диф по Figma — вот что держало весь процесс вместе. Без него расхождения в дизайне накапливались бы за 41 раунд проверки, а не выявлялись на уровне страниц — и у агентства не было бы надёжного способа убедиться, что доработка не просочилась в общий слой шаблона. ## Контроль качества QA перед сдачей устранил два вида проблем: контентные заглушки (lorem-текст на /new-patients и /technology, а также общий для сайта пробел в замене изображений-заглушек на страницах услуг) и проход по завершающим слешам после обнаружения отсутствующих финальных слешей во внутренних ссылках на `/about` и `/dr-connor-rivers` (Redmine #1008: «Too many issues incl lorem placeholders and links too claude»); 99 из 120 пунктов очереди задач SEO закрыты к сдаче. QA перед сдачей выполнялся через **Site Checker** — категории и порог нулевых ошибок описаны в [нашем подходе к QA](/site-checker/). Контур проверки агентства запускался после сдачи и вносил оставшиеся вопросы в общую очередь задач для нашего цикла правок вплоть до их согласования. Доработки оставались в клиентских переопределениях; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Итог Поставленные URL **42** — 1 главная, 1 лендинг услуг, 23 страницы услуг, 1 биография врача, 1 О нас, 1 контакты и 14 вспомогательных страниц Применённые шаблоны **11 из 11** переиспользуемых шаблонов собраны и применены по 42 страницам Контрольный список запуска **79 пунктов** согласованы Зафиксированные и разобранные QA / SEO задачи **120+** пунктов устранены по двум вкладкам очереди задач агентства (SEO и CX) QA-итерации в Redmine **41 из 58 задач (71%)** отслеживались на уровне итерации Сроки **79 дней**, поставлено в срок Трудозатраты **103 часа** при оценке 103 часа — без перерасхода, без расширения объёма Команда **4 специалиста** Передача на хостинг Запущено в шаблонной среде Kinsta агентства Состояние страниц при сдаче **40 / 40** URL тестовой среды вернули HTTP 200 при аудите карты сайта Если коротко: Figma агентства реализована по их фирменному шаблону на 42 страницах и 11 шаблонах за 79 календарных дней в рамках оценки в 103 часа. ## Процесс Фаза Продолжительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к шаблону подтверждён, объём согласован Разработка доработки ~5 недель Постраничная доработка шаблона по Figma QA-итерации (непрерывные) ~5 недель 41 QA-раунд зафиксирован; каждый закрывался только по согласованию агентства Раунды правок ~1 неделя 4 ч на постпроверочные исправления Поставка последний день Сайт запущен на Kinsta _Разработка и QA шли параллельно — это характерно для доработки темы, где «фаза QA» не закрывается чётко; цикл идёт непрерывно до тех пор, пока агентство не подпишет результат._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона и наложение вёрстки по Figma) - **Павел Сажин** — QA-итерации и правки - **Тимур Арбаев** — поддержка разработки в поздних раундах доработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом на стороне агентства оставались у партнёрского агентства на протяжении всего проекта. Наша команда оставалась невидимой для конечного клиента. Все запросы на доработку поступали через общую очередь задач агентства, и ничто из сборки не открывалось конечному клиенту напрямую. Каждый QA-раунд закрывался только после того, как проверяющий со стороны агентства подтверждал устранение расхождения. ## Агентствам с библиотекой шаблонов > На фирменном шаблоне общий слой компонентов несёт отложенный риск. У этой практики — версия шаблона для сети клиник с единым брендом; у других — отдельная сборка под одну клинику на универсальном шаблоне. Правка общего модуля под одного клиента незаметно изменит все остальные сайты, которые его используют. Следующее обновление шаблона откатит доработки, которые не были изолированы. Бренд-токены перестанут доходить до сайта, как только клиент поменяет цвет. Подрядчику стоит задавать не вопрос «сможете ли вы настроить шаблон под нас?», а вопрос «как именно вы запрёте каждое переопределение, чтобы оно затронуло только нужного клиента?» Пришлите спецификацию бренда и ID шаблона. Мы сверим исходник шаблона с вашими требованиями к бренду, найдём риски переопределений и вернём фиксированную смету в часах. Аудит без оплаты, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-21-page-orthodontics-43-days/ title: Доработка ортодонтического шаблона: 21 страница за 43 дня type: case_study date: 2025-03-03T21:08:33+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 21 страница доработки ортодонтического шаблона на фирменном шаблоне агентства «Glowing» — 11 страниц услуг и лечения, каждая со своим набором иконок и трёхцветной комбинацией в Figma, 39 часов, 43 дня. Агентство своевременно указало, что стандартный набор иконок шаблона повторяется без изменений на каждой странице услуг; решением стала проработка каждого фрейма Figma постранично с применением требуемых дизайном иконок и цветовых вариаций. ## Краткий обзор Параметр Значение Отрасль конечного клиента Здравоохранение — ортодонтия Конечный клиент ABM Orthodontics (Clearwater, FL) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн Figma на Kinsta) Объём **21 URL** — главная, about, биография врача, **11 страниц услуг/лечения**, страховка, финансирование, членство, контакты и политики Сроки 43 дня (18 ноя – 30 дек 2025), по графику Трудоёмкость 39 часов — разработка, итерации QA и управление проектом Команда 4 специалиста Шаблоны **10 фирменных шаблонов агентства**, применены на 21 странице Технологии WordPress · Elementor · Kinsta · Gravity Forms · Rank Math · постраничный дизайн Figma · AutoQA агентства (Links / Email / Content AI / visual checks) · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **Более 470 отслеженных проблем SEO + CX**, согласованных в журнале задач агентства, 78 пунктов в контрольном списке запуска **Ритм взаимодействия** 3 задачи от агентства · 2 из 3 закрыты к моменту передачи **Раунды проверки** ≈5 раундов проверки за 43 календарных дня **Контрольный список запуска** 78 пунктов, согласован перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для ABM Orthodontics и цель развёртывания на своей фирменной системе шаблонов под Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, согласование с клиентом, настройка хостинга, контент-план. Им нужна была команда разработчиков, которая добросовестно перенесёт Figma в шаблон через столько итераций доработки, сколько потребует дизайн. Задача была чисто исполнительская. Figma — единственный источник истины. Доработать шаблон до соответствия страница за страницей, точка адаптации за точкой адаптации. Передавать результаты QA обратно агентству в общее рабочее пространство; не закрывать их без согласования с агентством. Агентству нужно было обезопасить себя от подрядчика, который отнёсся бы к ортодонтической доработке шаблона как к массовому заполнению. Сайт ортодонтии с 11 различными страницами услуг и лечения — каждая описывает свою процедуру, каждая со своим фреймом Figma — не может выглядеть как копипаст. Когда один и тот же набор иконок повторяется на каждой странице услуг и одна цветовая палитра сливается в монотонность, клиника теряет визуальную убедительность, которую дизайн агентства был призван создать. Именно этого агентство и искало, и именно это проверял 51-раундовый цикл QA в этом проекте. > **Контекст рисков.** Компактный ортодонтический сайт на общем стоматологическом шаблоне сталкивается с риском визуальной унификации, которого нет у более крупного стоматологического сайта: когда одинаковые иконки и стандартные цветовые наборы повторяются на 11 страницах услуг и лечения, клиника выглядит шаблонной, а не доработанной. Figma в этом проекте задавала постраничную вариацию иконок — отдельные наборы и трёхцветные комбинации для каждой услуги, — поэтому цикл QA должен был проверять визуальную дифференциацию на уровне компонентов, а не только точность макета. Команда, пропускающая этот шаг, сдаёт сайт, который воспринимается как взаимозаменяемый с любой другой клиникой на том же шаблоне, — а это противоположно тому, что задумывалось инвестициями агентства в дизайн. Дополнительным ограничением стала готовность контента: несколько страниц услуг были запущены с некликабельными заглушками кнопок, поскольку финальные тексты и интеграция записи агентства ещё не были готовы — это ограничение отслеживалось через BugHerd и было устранено в двух последующих раундах QA. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страниц. Наша задача — согласовать их страница за страницей: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны. Мы выбрали строгое следование Figma вместо интерпретации дизайна относительно стандартных настроек шаблона, потому что постраничная палитра иконок и цветов была ключевым отличием на 11 страницах услуг — использование стандартного набора иконок шаблона привело бы к визуальной унификации всех страниц, что было прямо противоположно цели инвестиций агентства в постраничные фреймы Figma. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 81 задачи, отслеженных в этом проекте, **51 были итерациями QA** — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы просматривали, исправляли и возвращали сборку на очередную проверку. За этими раундами стояла гораздо более масштабная сверка: агентство отслеживало **более 470 пунктов в двух журналах задач** (235 находок SEO и 236 находок CX). Этот объём — не признак нестабильности; именно это отличает шаблонный сайт, выглядящий «приблизительно правильно», от сайта, точно соответствующего дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без расхождения.** За время проекта каждое изменение в фирменном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Ни одна доработка не «просочилась» в общие компоненты шаблона, поэтому работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями текущего раунда, а не весь сайт, — так доработка темы идёт без лишних затрат и без потери покрытия. 51 раунд QA за 43 дня, каждый проверяющий постраничную точность иконок и цветов относительно фрейма Figma, а не трактующий страницы услуг как взаимозаменяемые. Такой темп — более одной итерации в календарный день в среднем — требовался спецификацией постраничной дифференциации; без него инвестиции агентства в 11 различных фреймов Figma остались бы невидимыми при запуске. ## Контроль качества QA перед сдачей в этом проекте было сосредоточено на двух категориях: расхождения визуальной точности (повторяющиеся наборы иконок на страницах услуг, где Figma задавал постраничную вариацию — Redmine #2121) и проверки SEO (неверное имя сайта в Rank Math — #2122); обе прошли через несколько раундов закрытия перед утверждением сборки. QA перед сдачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) для категорий и порога нулевых ошибок. Приёмочный контур агентства работал после передачи и заносил замечания в общую очередь правок для нашего цикла исправлений, пока агентство не согласовывало результат. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL доставлено **21** — 1 главная, 1 about, 1 биография врача, 11 страниц услуг/лечения, 1 страховка, 1 финансирование, 1 членство, 1 контакты и 3 страницы политик Применено шаблонов **10 из 10** фирменных шаблонов агентства созданы и сопоставлены на 21 странице (главная, About Us, Doctor Page, Service Page, Services Lander, Insurance, Financing, Payment Plan / Membership, Practice Area Lander, Individ. Practice Area Page) Контрольный список запуска **78 пунктов** согласованы Отслежено и решено проблем QA / SEO + CX **Более 470** пунктов, согласованных в двух журналах задач агентства (235 SEO + 236 CX) Итераций QA в Redmine **51 из 81 задачи (63%)** отслежены на уровне итераций Сроки **43 дня**, доставлено по графику Трудоёмкость **39 часов** при оценке 39 часов — без перерасхода, без расширения объёма Команда **4 специалиста** Передача хостинга Работает в среде шаблонов Kinsta агентства Состояние страниц при передаче **21 / 21** завершённых URL возвращали HTTP 200 в аудите карты сайта Если коротко: мы собрали Figma агентства на их фирменном шаблоне — 21 страница, 10 шаблонов, 43 календарных дня, в рамках оценки в 39 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~2 дня Figma просмотрен, доступ к шаблону подтверждён, объём согласован Разработка доработки ~1 неделя Постраничная доработка шаблона под Figma Итерации QA (параллельно) ~4 недели 51 раунд QA; каждый закрыт только после согласования с агентством Раунды правок ~1 неделя Коррекции после проверки, обновления иконок, уточнение отступов Сдача проекта Финальный день Сайт запущен на Kinsta _Разработка и QA выполнялись параллельно — это характерно для доработки темы, где «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (доработка шаблона и перенос Figma в макет) - **Павел Сажин** — итерации QA и правки - **Тимур Арбаев** — итерации QA и поддержка разработчика - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне партнёрского агентства на всём протяжении. Конечный клиент нас не видел: все запросы на доработку шли через общий журнал задач агентства, и сборка ему напрямую не показывалась. Каждый раунд QA закрывался только после подтверждения рецензентом агентства, что расхождение устранено. ## Агентствам с библиотекой шаблонов > На компактном ортодонтическом сайте, собранном на стоматологическом шаблоне, главный риск — визуальная унификация. У этой клиники — постраничная вариация иконок и трёхцветные комбинации; у многопрофильной стоматологии — единый набор блоков. Границу слоёв легко стереть: доработки в дочерней теме ломаются при следующем обновлении шаблона, а отдельные токены палитры так и не пробиваются сквозь жёстко зашитые значения по умолчанию. Подрядчику стоит задавать не вопрос «соберёте ли страницы по шаблону?», а вопрос «как именно вы защитите доработки от обновлений авторского слоя?» Пришлите исходник шаблона или его ID и макеты. Мы проверим, где бренд-токены пересекаются с авторскими слоями, оценим уязвимость к обновлениям и без оплаты вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-pediatric-dental-153h-389-days/ title: Новая разработка на WordPress для детской стоматологии (29 страниц) за 389 дней type: case_study date: 2025-02-28T11:50:21+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 68 задач за 389 дней для детской стоматологической клиники с тремя филиалами: разработка 29 страниц на Elementor в январе 2025, три цикла обновления дизайна в мае, июне и июле и редизайн 15 страниц в сентябре — всё на одном шаблоне Original Design на WP Engine. Одна и та же команда вела весь проект 153 часа и закрывала каждый этап через проверку агентства, без переоценки между этапами. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — детская стоматология Конечный клиент All Kids Pediatric (Charlotte, NC — Arrowood · Plaza Midwood · Indian Trail) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка на WordPress с Elementor на WP Engine, с последующими циклами обновления дизайна и редизайна Объём **29 URL** — главная, знакомство с врачами, знакомство с командой, 11 страниц услуг (детская стоматология, профилактика, осмотры, фторирование, герметизация, распространённые процедуры, экстренные случаи, удаление, пломбирование, седация, цифровые рентгенограммы), 3 страницы филиалов, запись на приём, формы для пациентов, отзывы, оплата счёта, плюс вспомогательные страницы (наши отличия, экологичность, визит в клинику, тур по клинике, финансовая информация, FAQ, опрос после приёма, приведи друга) Сроки 389 дней (9 янв 2025 – 2 фев 2026), сдано по графику на всех этапах Трудозатраты **153 часа** при смете 153 часа — без перерасхода Команда 7 специалистов Шаблоны **1 шаблон** — Original Design агентства, применён на всех 29 страницах Технологии WordPress · Elementor · WP Engine · встраивания Square Appointments · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) **Результат** **29 URL разработаны, контрольный список запуска из 49 пунктов закрыт, 13/14 пунктов очереди задач доведены до Completed, три цикла обновления дизайна + один редизайн 15 страниц выполнены** **Интенсивность** 13 задач от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈21 раунд проверки за 389 календарных дней **Контрольный список запуска** 49 пунктов, согласованы перед запуском ## Постановка задачи All Kids Pediatric — детская стоматологическая клиника в Шарлотт, Северная Каролина, с тремя офисами, обслуживающими детей и семьи по всему региону. Маркетинговое агентство из США, специализирующееся на сайтах для локального бизнеса, вело весь проект: они владели дизайном, контент-стратегией, хостингом на WP Engine и отношениями с клиентом. Нашей задачей было разработать исходный сайт, затем поддерживать его через циклы обновления дизайна и редизайн в середине года — оставаясь невидимыми для конечного клиента на всём протяжении. Таблица структурировала проект по 29 активным URL, сопоставленным с шаблоном Original Design агентства. Объём по строкам карты сайта мы оценили сами: примерно 17 часов прямой работы над страницами, остальные часы — на управление проектом, QA, три цикла обновления дизайна и редизайн 15 страниц. Задача: разработать все страницы, подключить форму записи на приём, обработать meta и H1 по карте сайта, проработать очередь задач и закрыть контрольный список запуска перед сдачей каждого этапа. Дизайн, контент, SEO-стратегия и коммуникация с клиентом оставались за агентством. > **Контекст рисков.** Сайт детской стоматологической клиники должен говорить с двумя аудиториями одновременно: родителями, принимающими решения о записи, и детьми, которые увидят сайт до визита. Агентство нанимало разработчика, который сохранит точность информации для родителей (страховка, финансы, адреса филиалов, запись на приём) по всем трём офисам, сохраняя дружественный детям тон, заданный дизайном агентства. Более глубокий риск — преемственность: разработчик, который сдаёт исходную разработку и затем становится недоступен, когда агентству нужно обновление дизайна через полгода, вынуждает агентство заново вводить в курс дела новую команду. 389-дневный период этого проекта — с циклами обновления дизайна в мае, июне и июле и редизайном в сентябре — доказательство того, что агентству не пришлось этого делать. Та же модель долгого сотрудничества ввела ограничение, которого не было при исходной разработке: во время майского обновления дизайна работа непосредственно на рабочем окружении вызвала конфликты стилей Elementor и визуальные регрессии, которые пришлось решать в том же спринте, а не изолировать в отдельном процессе. ## Как мы это сделали **1. 1 шаблон, 29 страниц, один процесс — разработано для клиники с 3 филиалами.** 29 страниц сайта мы распределили по шаблону Original Design агентства: главная, 2 страницы команды (знакомство с врачами, знакомство с командой), 11 страниц услуг, охватывающих полный спектр детской стоматологии, 3 страницы филиалов (Arrowood, Plaza Midwood, Indian Trail), страница записи на приём и набор страниц для родителей (формы пациентов, финансовая информация, FAQ, тур по клинике, отзывы). Каждую страницу мы сопоставили с шаблоном из строки карты сайта до начала разработки. **2. Дисциплина многофилиальности на одном шаблоне.** Все три филиала используют один и тот же шаблон Original Design, но требуют отдельных блоков адресов, встроенных карт и локальной маршрутизации телефонов. Страницы филиалов — и ссылки на конкретные филиалы в формах контактов и записи — мы разработали так, чтобы родитель, ищущий офис Plaza Midwood, попадал на правильную страницу с правильным адресом и путём записи. Встраивания Square Appointments мы настроили по филиалам, чтобы запросы на приём направлялись в правильный планировщик офиса. **3. ТЗ выполнено строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Дальше держались сметы строго: итог уложился в согласованные часы на каждом этапе. Принцип здесь прост: при разработке с предварительно оценённой картой сайта таблица — это контракт. Задача команды разработки — уложиться в согласованную смету, а не открывать заново разговор о цене страница за страницей. **4. Три цикла обновления дизайна и редизайн 15 страниц — всё в рамках долгосрочного сотрудничества.** После завершения исходной разработки в январе агентство вернулось с работой по обновлению дизайна в мае (20 часов), июне (8 часов) и июле (4,3 часа) — обновления контента, замена изображений и корректировки шаблонов. В сентябре этап редизайна 15 страниц (18,5 часов, включая QA) переработал значительную часть сайта по обновлённому ТЗ дизайна. Все этапы отслеживались в том же проекте Redmine, выполнялись той же командой и закрывались через тот же цикл QA. Когда виджет отзывов TrustIndex на странице отзывов после редизайна выдал ошибку сервера 403 при сохранении, мы зарезервировали область-заполнитель и закрыли разработку страницы — виджет интегрировали в более позднем раунде исправлений, не блокируя весь этап редизайна. Правки напрямую в рабочей среде WP Engine во время майского обновления дизайна выявили конфликты стилей Elementor, которые пришлось решать внутри того же спринта — элементы выпадали, стили переопределяли друг друга. Сентябрьский редизайн решил эту проблему иначе: каждая страница разрабатывалась в черновиках, проверялась по Figma перед публикацией, так что опубликованный сайт оставался нетронутым до утверждения страницы агентством. Урок мая окупился в сентябре. ## Контроль качества Проверки перед сдачей по 29 URL охватывали проверку соответствия таблице по каждой строке карты сайта, целостность ссылок (разметка телефонных `tel:` и пути PDF в формах пациентов — обнаружены и исправлены), единообразие слешей по всем 29 URL и выравнивание данных Elementor на 7 страницах услуг, которые отклонились от общего шаблона в ходе промежуточного спринта правок. QA перед сдачей проходило через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Собственный контур QA агентства работал после сдачи и заводил замечания в очередь правок для нашего цикла исправлений, пока агентство не подтверждало готовность. ## Результаты Метрика Результат URL разработано **29** — 1 главная, 2 страницы команды, 11 страниц услуг, 3 страницы филиалов, 1 запись на приём, 1 формы пациентов, 1 отзывы, 1 оплата счёта и 8 вспомогательных страниц Шаблонов применено **1 / 1** из стандартной библиотеки агентства (Original Design применён на всех 29 страницах) Контрольный список запуска **49 пунктов** согласованы по категориям: дизайн / функциональность / контент / SEO Очередь задач **13 / 14** закрыты как Completed Циклов обновления дизайна выполнено **3** цикла обновления дизайна (май, июнь, июль) + **1** редизайн 15 страниц (сентябрь) Сроки **389 дней** на исходную разработку + обновление дизайна + редизайн, сдано по графику Трудозатраты **153 ч / 153 ч** смета — без перерасхода, без расширения объёма Команда **7 специалистов** Сдача Сайт запущен на WP Engine; `https://www.akasmiles.com/` отдаёт HTTP 200 Статус сайта, проверено 2026-04 Сайт в работе, повторно проверен в апреле 2026 Если коротко: 29 URL новой разработки для детской стоматологии сданы на WP Engine в рамках сметы, и та же команда поддерживала сайт через три цикла обновления дизайна и редизайн 15 страниц следующие 11 месяцев — агентству не пришлось заново вводить в курс дела нового разработчика. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица проверена, доступ к тестовой среде подтверждён, объём 29 страниц и структура 3 филиалов согласованы Разработка (страницы + шаблоны) ~2 недели Все 29 страниц разработаны на шаблоне Original Design; открыта очередь задач QA после запуска и закрытие очереди задач ~2 недели Очередь задач проработана до 13/14 Completed; контрольный список запуска из 49 пунктов согласован Циклы обновления дизайна ~3 месяца (май – июль) Три цикла обновления дизайна выполнены: обновления контента, замена изображений, корректировки шаблонов Редизайн 15 страниц ~3 недели (сентябрь) Этап редизайна спланирован, разработан и пройден QA Постоянная поддержка до фев 2026 Раунды исправлений и мелкие корректировки по мере поступления запросов агентства _Этапы пересекались на практике — циклы обновления дизайна планировались и запускались без полной переоценки, поэтому календарный срок составляет 389 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — проверка разработки и QA на начальном этапе - **Павел Сажин** — ведущий разработчик на этапах исходной разработки, циклов обновления дизайна и редизайна - **Анна Полунина** — поддержка реализации и QA - **Евгений Карпов** — поддержка разработки на этапах обновления дизайна и редизайна - **Тимур Арбаев** — сверка дизайна и разработки, QA перед сдачей - **Наталия Богатель** — QA и координация проекта - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом и коммуникация с клиентом со стороны агентства оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. Все запросы на изменения из этапов обновления дизайна и редизайна поступали через тот же канал общей очереди задач, что и исходная разработка. ## Агентствам, заказывающим разработку WordPress > На сайте детской стоматологической клиники таксономия и контент должны говорить с двумя аудиториями сразу. У этой практики — родители, принимающие решение о записи, и дети, которые видят сайт до визита. У других — только взрослые пациенты. Если архитектура не держит этот разрыв, риски тихие. Новая услуга через полгода не вписывается в URL-схему. Структурированная разметка для нескольких офисов слетает при обновлении контента. Редакторский процесс рассчитан на одного автора — у клиента их три, и правки начинают конфликтовать. Подрядчику стоит задавать не вопрос «сможете ли собрать сайт?». А вопрос: «как именно вы построите таксономию и контент-слой? Так, чтобы следующий офис встал без миграции, а структурированная разметка выдержала первое обновление дизайна?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы сверим вашу таксономию и URL-архитектуру с ранжирующимися страницами. Проверим, выдержит ли структурированная разметка расширение на новый офис, и вернём фиксированную смету в часах. Бесплатно, без обязательств с любой стороны. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-egg-donor-agency-40h-19-days/ title: Сборка WordPress для агентства доноров яйцеклеток на 19 страниц за 19 дней type: case_study date: 2025-02-22T07:46:08+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 19 страниц сборки WordPress в сфере репродуктивной медицины на библиотеку из 6 шаблонов на WP Engine, сдали за 40 часов и 19 дней. Спецификация агентства делила сайт на 2 аудитории — путь донора на `/egg-donor/` и путь будущих родителей на `/parents/` — с независимым отслеживанием конверсий по каждой кнопке, чтобы агентство могло мерить каждый CTA без пересечения. ## Краткий обзор Поле Значение Индустрия клиента Репродуктивная медицина — агентство доноров яйцеклеток Клиент Signature Egg Donors (New York & Connecticut) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Сборка с миграцией контента, Elementor на WP Engine Объём **19 URL** — главная, о нас, контакты, блог, 2 страницы услуг (/egg-donor/, /parents/), 13 записей блога перенесено с `/post/` на `/blog/` Сроки 19 дней (19 мар – 7 апр 2025), сдано в срок Затраты **40 часов** (18 ч разработка · 10 ч QA · 12 ч PM) Команда 6 специалистов по разработке, QA и управлению проектом Шаблоны **6 в работе** из библиотеки агентства на 10 шаблонов (главная · о нас · страница услуг · контакты · блог · запись блога) Технологии WordPress · Elementor · Gravity Forms · WP Engine · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Сдано** **19 URL собрано, путь блога перенесён с `/post/` на `/blog/`, отслеживание конверсий по каждой кнопке на 2 страницах услуг, очередь правок на 20 пунктов закрыта, QA-проверка AM на 2 пункта пройдена, контрольный список запуска согласован** **Динамика проекта** 22 задачи от агентства · все закрыты к передаче (активный период 14 дней, 2025-04-05 – 2025-04-18) **Раунды проверки** ≈5 раундов на 19-дневном календарном окне **Контрольный список запуска** 29 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство, нанятое Signature Egg Donors — агентством доноров яйцеклеток в Нью-Йорке и Коннектикуте, которое работает с двумя разными группами людей, — передало нам Google Sheets таблицу с полной картой сайта, каталогом шаблонов, контрольным списком запуска и технической спецификацией проекта. Сборка размещалась на WP Engine; конструктором страниц был Elementor; контактная форма работала на Gravity Forms. Контент-архитектуру агентства для этого клиента намеренно разделили на два параллельных направления: страница `/egg-donor/` для потенциальных доноров яйцеклеток и страница `/parents/` для будущих родителей. Оба направления уже жили на исходном сайте под разными URL (`/for-donors` и `/for-donors-1`). В бриф сборки входил перенос обоих на чистые постоянные URL и настройка отслеживания конверсий по каждой кнопке, чтобы каждый призыв к действию на каждой странице мерился отдельно. Через весь проект шла и третья линия: на сайте было 13 записей блога, которые предстояло перенести с плоского пути `/post/` в поддиректорию `/blog/`, сохранив метаданные и заголовки в каждой записи. > **Контекст рисков.** Сайт с двумя аудиториями несёт конверсионный риск, которого нет у однотрекового сайта. Путь предполагаемого родителя и путь донора яйцеклеток разделяют один домен, но ведут к разным призывам к действию, разным назначениям Gravity Forms и разным хукам отслеживания. Сборка, которая правильно настраивает CTA донора и неправильно — CTA предполагаемого родителя, или перепутывает идентификаторы отслеживания кнопок, будет выглядеть завершённой при визуальной проверке, но молча направит половину конверсионной поверхности сайта не по адресу. Техническая спецификация агентства явно указывала это, ссылаясь на отдельные URL отслеживания для каждого аудиторного пути. Доставить каждый путь к правильному адресу отслеживания, с правильной конечной точкой формы — это было ключевым требованием этого проекта. ## Как мы это сделали **1. 6 шаблонов, 19 страниц, один процесс сборки.** Библиотека шаблонов агентства содержит 10 стандартных шаблонов. Для этого клиента применили 6: главная (1 страница), о нас (1), страница услуг (2 — по одной на аудиторию), контакты (1), блог (1) и запись блога (13 постов). Оставшиеся 4 шаблона — страница врача, шаблон по умолчанию, каталог услуг и отзывы — были под рукой, но не пошли в дело; карта сайта клиента их не требовала. Каждую страницу собрали на назначенном ей шаблоне из строки карты сайта в таблице. **2. Спецификация выполнена строка за строкой, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждому URL мы оценили сами и зафиксировали до старта. Больше всего получила главная: у неё насыщенный видео-макет со встроенным MP4-героем и навигацией, которая раскрывается при прокрутке, — поведение перенесли с исходного сайта. MP4 тормозил прокрутку на тестовой среде, и его пришлось сжать, прежде чем раскрытие при прокрутке совпало с оригиналом. Обе страницы услуг получили отдельные часы на видео-фоны и отслеживание конверсий. Мы уложились в бюджет каждой строки; объём сошёлся на 18 часах разработки при оценке в 18 часов. **3. Миграция URL для двух аудиторий и отслеживание конверсий по каждой кнопке.** Исходный сайт держал два пути услуг на несогласованных между собой slug’ах (`/for-donors` и `/for-donors-1`). Новая сборка вывела их на `/egg-donor/` и `/parents/` — постоянные, понятные, различимые. Мы выбрали отслеживание кнопок через shortcode, а не отдельный плагин аналитики: спецификация агентства требовала отслеживания по URL для каждой аудитории в рамках общего шаблона Elementor. По технической спецификации каждой странице настроили своё отслеживание кнопок, чтобы аналитика агентства различала события CTA на пути донора и на пути будущего родителя без пересечения. **4. Миграция пути блога: 13 постов с `/post/` на `/blog/`.** Исходный сайт организовывал записи под плоским путём `/post/`. Новая сборка перенесла каждую запись в поддиректорию `/blog/`, сохранила исходные заголовки H1 и метаданные и подтвердила паритет URL на тестовой среде по обходу Screaming Frog исходного сайта перед передачей. **5. Два QA-цикла, закрытых до запуска.** Задачи вели в двух вкладках очереди правок агентства. Очередь правок (22 строки) собралась после собственного QA-прохода агентства: правки meta description на 3 страницах, исправления адаптивной вёрстки на мобильных, коррекция структуры заголовков блога, подключение ленты Instagram и набор мелких стилевых правок. 20 пунктов закрыли как выполненные; один остался в ожидании информации (вопрос по поведению меню — подтвердили, что оно совпадает с исходным сайтом); один отложили до будущего SEO-бюджета. QA-проверка аккаунт-менеджера (2 пункта — размер футера и число строк H1 на странице донора) закрыта на 2 из 2 выполненных. Контрольный список запуска по разделам «Дизайн», «Функциональность», «Контент», «SEO и аналитика», «Адаптивность» согласован полностью. Отслеживание по каждой кнопке через shortcode держало всю архитектуру конверсий. Спецификация требовала измерять CTA по URL для каждой аудитории в рамках общего шаблона Elementor — плагин слил бы два набора отслеживания в один. Shortcode оставили `/egg-donor/` и `/parents/` аналитически различимыми, не разводя шаблон. ## Контроль качества QA на этой сборке прошло по двум категориям: целостность конверсионного пути (идентификаторы отслеживания кнопок подтвердили как различные для `/egg-donor/` и `/parents/`, уведомления Gravity Forms настроили на info@signaturedonors.com) и структурная точность (число строк H1 на `/egg-donor/` исправили на одну строку, размер футера привели к спецификации — оба пункта из проверки тестовой среды аккаунт-менеджером, оба закрыли как выполненные до передачи). Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Свой контроль на стороне агентства запускался после передачи и сводил замечания в общую очередь правок до финального согласования. ## Результаты Метрика Результат URL собрано **19** на 6 шаблонах (1 главная · 1 о нас · 2 страницы услуг · 1 контакты · 1 блог · 13 записей блога) Применено шаблонов **6 из 10** из стандартной библиотеки агентства Миграция пути блога **13 записей** перенесено с `/post/` на `/blog/` с сохранением метаданных и заголовков Маршрутизация URL для двух аудиторий `/egg-donor/` и `/parents/` — своё отслеживание кнопок на каждой странице Выполнение очереди правок **20 / 22** выполнено; 1 ожидание информации (паритет подтверждён), 1 отложено Выполнение QA-очереди AM **2 / 2** выполнено Контрольный список запуска Согласован по разделам Дизайн / Функциональность / Контент / SEO и аналитика / Адаптивность Сроки **19 дней** (19 мар – 7 апр 2025), сдано в срок Затраты **40 ч** (18 ч разработка · 10 ч QA · 12 ч PM) при оценке в 40 ч — без перерасхода Статус сайта Опубликован на WP Engine, `https://www.signaturedonors.com/` — проверено в апреле 2026, HTTP 200 ## Процесс Этап Длительность Результат Бриф + оценка 19–27 мар 2025 Карта сайта изучена, оценка часов (18 ч разработки) подтверждена PM; спецификация таблицы принята Этап сборки 27–30 мар 2025 19 URL собрано; миграция блога завершена; отслеживание по двум аудиториям интегрировано; проблемы адаптивности видео-макета решены QA — раунд разработки 30 мар – 5 апр 2025 Предварительное QA через Site Checker; очередь правок заполнена и отработана (20 пунктов закрыто) QA агентства + исправления 31 мар – 13 апр 2025 QA тестовой среды AM (2 пункта) закрыто; второй проход очереди правок (структура блога, лента Instagram, адаптивность) закрыт; контрольный список запуска согласован Сдача 7 апр 2025 Боевой домен запущен на `signaturedonors.com`; всё оплачено, всё закрыто Сборка и этапы QA пересекались — задачи выявлялись 31 марта, пока оставшаяся разработка шла параллельно. Это стандартная форма «один этап + хвост» для 19-дневного проекта. ## Команда Маркетинговое агентство из США управляло отношениями с клиентом и руководило всеми контентными и дизайнерскими решениями. Конечный клиент нас не видел на всём протяжении. - **Никита Тумашевич** — координация задач и внутреннее QA - **Павел Сажин** — QA и проверка перед передачей - **Анна Полунина** — поддержка реализации и QA - **Тимур Арбаев** — проверка дизайна и QA перед передачей - **Людмила Травкина** — ведущий разработчик - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Вся клиентская коммуникация и контентные решения оставались у агентства. Мы не писали тексты и не принимали дизайнерских решений самостоятельно. ## Агентствам, заказывающим разработку WordPress > Боитесь, что новый партнёр на четвёртый месяц не встанет в URL-схему, а половина заявок утечёт не в ту автоматизацию? На сайте донорского агентства таксономия обслуживает две аудитории под одной крышей. У этой практики одна база и два портала; у других — сеть клиник с общим пулом доноров. Опасны тихие сценарии: новое партнёрство на четвёртый месяц не вписывается в шаблон URL; фильтры поиска доноров перестают выводить уже ранжируемые страницы; заявки из портала реципиентов молча уходят не в ту автоматизацию. Спрашивать подрядчика стоит не «соберёте ли оба портала?», а «как таксономия удержит поисковые страницы целыми, когда подключится новый партнёр?». Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы пройдём URL-план по сценариям обращений, сверим логику фильтров с вашим списком ранжируемых страниц и вернём фиксированную смету в часах. Проверка бесплатна; смета приходит в часах, без вилки. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-cpa-80h-94-days/ title: Разработка на WordPress для CPA-консалтинга: 8 шаблонов, 94 дня type: case_study date: 2025-02-19T18:55:35+00:00 case_industry: Профессиональные услуги case_type: Разработка case_practice: wordpress --- ## Подход к разработке 41 страница WordPress-разработки для CPA-консалтинга по заказу маркетингового агентства из США — и указание клиента в процессе работы убрать с сайта все упоминания стоматологической практики. Языковая чистка затронула главную страницу, страницы услуг, навигационные метки и данные Elementor в несколько раундов QA — и была поглощена в рамках объёма в 80 часов без пересмотра бюджета. CPA-консалтинговая фирма для стоматологических практик, выполненная для маркетингового агентства из США в сегменте профессиональных услуг. ## Краткий обзор Поле Значение Отрасль конечного клиента Профессиональные услуги — CPA и финансовый консалтинг для стоматологических практик Конечный клиент SBDP CPA / Ascend Dental Group (Jacksonville Beach, FL) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Разработка на WordPress с Elementor на WP Engine с последующим этапом доработок и согласований Объём **41 URL** — главная, команда, миссия, блог (лента), шаблон поста, контакты, страницы услуг (What We Do), плюс 30 отдельных страниц сотрудников в шаблоне Default Сроки 94 дня (4 сен – 7 дек 2025), сдано в срок Трудоёмкость **80 часов** при оценке 80 часов — без перерасхода Команда 5 специалистов (35 ч разработка · 30 ч QA · 15 ч PM — баланс PM/QA адекватен для однофазной разработки с корректировкой объёма и этапом доработок) Шаблоны **8 переиспользуемых шаблонов** — стандартная библиотека шаблонов агентства для профессиональных услуг Технологии WordPress · Elementor · Gravity Forms · WP Engine · Rank Math · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **41 URL на 8 шаблонах, 60/68 очереди задач SEO закрыто как Completed, 20/21 очереди задач CX закрыто как Completed** **Интенсивность работы** 68 задач от агентства · все закрыты к моменту передачи (39 активных дней, 2025-09-27 – 2025-11-04) **Раунды проверки** ≈7 раундов **Контрольный список запуска** 54 из 74 пунктов, согласованы перед запуском ## Постановка задачи Маркетинговое агентство из США, нанятое SBDP CPA — CPA- и финансовой консалтинговой фирмой из Jacksonville Beach, обслуживающей стоматологические практики и работающей под брендом Ascend Dental Group, — передало нам таблицу Google Sheets с полной картой URL, каталогом шаблонов, контрольным списком запуска и предварительно заполненными очередями задач. Разработка велась в их окружении WP Engine; конструктор страниц — Elementor; формы — через Gravity Forms. Задача: создать 41 URL на 8 стандартных шаблонах, настроить меню и социальные ссылки, заполнить биографии сотрудников из контента, предоставленного агентством, и обработать две параллельных очереди задач QA — очередь задач SEO и очередь задач CX — пока агентство не примет сайт. На протяжении всего проекта оставаться вне контура прямого общения с конечным клиентом; выносить неоднозначные вопросы на агентство; не принимать самостоятельных решений по контенту, навигации или CTA. > **Контекст рисков.** Сайт CPA-консалтинговой фирмы — это, прежде всего, витрина компетенций. Партнёры и сотрудники указаны поимённо с должностями и ролями; страницы услуг содержат позиционирующие формулировки, отличающие фирму от бухгалтеров общей практики. Риск агентства в такой разработке — не качество кода, а партнёр-разработчик, для которого объём работ зафиксирован раз и навсегда. Когда позиционирование клиента меняется в процессе разработки — в данном случае сдвиг от стоматологической терминологии к более широким формулировкам профессиональных услуг — партнёр-разработчик должен принимать это изменение без остановки работы. Изменения языка контента на живой тестовой среде требуют такой же тщательности, как и структурные: каждое упоминание прежнего позиционирования нужно найти на страницах, в навигации и данных Elementor, прежде чем правка считается завершённой. Это не переделка — так и выглядит аккуратная сдача. Сложность была в том, что исходное стоматологическое позиционирование пропитало не только тексты страниц, но и навигационные метки, заголовки постов в блоге и структурированные поля данных Elementor — поэтому согласование представляло собой аудит каждого экземпляра, а не массовую замену, и задача Redmine, отслеживающая эту работу (#1412), прошла через пять подзадач QA, прежде чем агентство приняло правку. ## Как мы это сделали **1. 8 шаблонов, 41 страница, один процесс разработки.** Страницы SBDP CPA были распределены по библиотеке шаблонов агентства для профессиональных услуг: Homepage, Team (список партнёров и сотрудников), Core Values + Mission, Blog Lander, Blog (шаблон поста), Contact Us, What We Do (лендинг услуг с подстраницами Accounting, Accounts Receivable и Cash Flow Management), а также Default Template, вместивший 30 отдельных страниц с биографиями сотрудников. Каждая страница создавалась на назначенном шаблоне из строки карты сайта; ни одна страница не была свёрстана вручную вне шаблонной системы. **2. Спецификация выполнена построчно, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Ключевой строкой был блог: импорт контента и настройка шаблонов блога определяли бюджет разработки сильнее, чем можно предположить по числу страниц, — та же закономерность, что и в других проектах с большим объёмом контента. импорт контента и настройка шаблонов блога определяли бюджет разработки в большей степени, чем можно предположить по количеству страниц, повторяя закономерность, наблюдаемую в других проектах с большим объёмом контента. Коротко: в проекте с предварительно оценённой картой сайта таблица Google Sheets — это контракт. Задача команды разработки — уложиться в согласованную смету, а не возобновлять обсуждение цены, когда строка с большим объёмом контента занимает больше календарного времени, чем простая страница. Мы приняли оценку блога в 22 часа — непропорциональную одной строке карты сайта — без пересмотра, потому что в модели фиксированной цены партнёр-разработчик сам держит отклонения по отдельным строкам, а не пересматривает оценки на ходу. **3. Смена позиционирования поглощена в процессе без перерасхода бюджета.** Ближе к завершению проекта агентство передало указание клиента: убрать все упоминания стоматологической практики из текстов сайта и заменить их на более общие деловые формулировки. Задача не была поверхностной — исходный контент позиционировал фирму как специалистов по бухгалтерии для стоматологических практик, и эта терминология распространилась на главную страницу, страницы услуг, заголовки постов в блоге и слои данных Elementor. Мы отследили каждый случай, применили согласованные замены и провели полный внутренний раунд QA, прежде чем вернуть задачу агентству. Задача прошла два цикла QA, прежде чем агентство приняло правку. **4. Два параллельных контура QA, закрыты перед запуском.** Задачи отслеживались в двух вкладках очереди задач агентства — очередь задач SEO (68 строк) и очередь задач CX (21 строка). Из 68 SEO-пунктов 60 закрыты как Completed; 5 оставались в статусе To Do и 3 — Info Needed на дату экспорта данных. Все 21 CX-пункт достигли статуса Completed или QA-accepted. Контрольный список запуска на 74 строки охватывал фазы Development/Main, Development/Pre-Launch и Development/Post-Launch; 54 пункта были отмечены как Done до передачи. Смена языка — удаление упоминаний стоматологической практики со страниц, из навигации и данных Elementor — потребовала аудита каждого экземпляра, а не массовой замены; исходное позиционирование пропитало больше поверхностей, чем можно охватить 1 фразой. 4 цикла QA за 3 дня закрыли задачу. Проект уложился в оценку 80 часов, потому что смену направления мы отработали в рамках сдачи, а не превратили в повод пересмотреть бюджет. ## Результаты Метрика Результат Создано URL **41** на 8 шаблонах (1 Homepage · 1 Team · 1 Core Values + Mission · 1 Blog Lander · 1 шаблон поста · 1 Contact · 3 страницы услуг What We Do · 30 биографий сотрудников в Default + 2 поста в блоге) Использовано шаблонов **8 / 8** из стандартной библиотеки агентства для профессиональных услуг Очередь задач SEO **60 / 68** закрыто как Completed; 5 To Do, 3 Info Needed на дату экспорта Очередь задач CX **20 / 21** закрыто как Completed; 1 in QA на дату экспорта Контрольный список запуска **54 из 74 пунктов** согласованы по фазам Development/Main, Pre-Launch и Post-Launch Смена позиционирования Очистка языка контента на страницах, в навигации, данных Elementor и заголовках блога — поглощена без перерасхода бюджета Сроки **94 дня** (4 сен – 7 дек 2025), по графику Трудоёмкость **80 ч / 80 ч оценка** — без перерасхода, без расширения объёма **Статус сайта** Работает на WP Engine по адресу https://sbdpcpa.com/ — проверено в апреле 2026. ## Контроль качества Задача #1412 по смене позиционирования — удаление упоминаний стоматологической практики с главной страницы, страниц услуг и из данных Elementor в пользу общих деловых формулировок — прошла через четыре последовательных подзадачи QA, прежде чем языковая чистка взяла порог нулевых ошибок. Этот цикл уместился в отдельное QA-направление на 12 ч, которое шло параллельно основному потоку разработки на 22 ч. QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу нулевых ошибок. Приёмочный контур агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их окончательной приёмки. ## Процесс Фаза Длительность Результат Бриф и оценка ~1 неделя таблица Google Sheets проверена, построчные часы подтверждены, согласована оценка 80 ч Разработка (страницы + шаблоны) ~3 недели Все 41 URL созданы на 8 шаблонах на тестовой среде; открыты обе очереди задач QA Смена позиционирования — языковая чистка ~2 недели (параллельно с QA) Стоматологическая терминология заменена на деловые формулировки на страницах, в навигации, данных Elementor и заголовках блога; два цикла QA до приёмки Этап согласования QA (очереди задач SEO + CX) ~5 недель Обе очереди задач обработаны через раунды проверок в тестовой среде; 60/68 SEO + 20/21 CX до Completed Контрольный список запуска + сдача Финальная неделя 54 из 74 пунктов контрольного списка согласованы; сайт запущен на WP Engine _Фазы пересекаются — работа по языковой чистке шла параллельно с очередью задач QA, поэтому календарный срок составляет 94 дня, а не сумму отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на этапах разработки и согласования - **Тимур Арбаев** — итерации QA и исправления - **Анна Полунина** — поддержка разработчика на поздних раундах исправлений и настройка контента блога - **Павел Сажин** — управление проектом и итерации QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, приёмка) Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались за партнёрским агентством на протяжении всего проекта. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте консалтинговой компании таксономия услуг задаёт URL-архитектуру и фильтрацию. У этой практики — услуги для стоматологических клиник, сгруппированные по бизнес-процессам; у других — таксономия по отраслям или типам консультаций. Если подрядчик не заложит запас гибкости, фильтруемые страницы выпадут из индекса, черновики уйдут в выдачу, а вложенные адреса перестанут открываться. Спросите подрядчика не «соберёте ли страницы?», а «как именно вы заложите гибкость в таксономию, чтобы следующий сегмент услуг встал без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или макеты. Мы проверим таксономию против вашего плана расширения услуг и вернём фиксированную смету в часах. Аудит ничего не стоит — смета приходит в часах, не в диапазоне. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-veterinary-115-urls-16-days/ title: Ребилд сайта ветеринарии на WordPress: 115 URL за 16 дней по ТЗ type: case_study date: 2025-02-10T22:10:40+00:00 case_industry: Ветеринария case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 115 URL, 66 редиректов с изменением путей, 12 шаблонов и контрольный список запуска на 74 пункта — ребилд Venetian Pet Hospital поступил в виде таблицы Google Sheets от маркетингового агентства из США и был сдан по ТЗ за 16 дней. Каждый редирект — задокументированная зависимость: 53 URL страниц услуг и 11 записей блога реструктурированы, каждый из них критичен для конверсионных путей ветеринарной клиники. ## Краткий обзор Поле Значение Индустрия конечного клиента Ветеринария — клиника домашних животных Конечный клиент Venetian Pet Hospital (ветеринарная клиника полного цикла, Stockton, CA) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress с Elementor Pro на Kinsta Объём Полный сайт — услуги, биографии команды, ресурсы по здоровью животных, блог, формы с загрузкой файлов, видеогалерея Сроки ~16 дней (28 июля – 12 августа 2025) для основного ребилда; очередь задач проверки закрыта к 21 августа, по графику Затраты ~63 часа по оценке — без перерасхода Команда 4 специалиста (~43 ч разработка · 10 ч QA · 10 ч PM) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Разница контента оригинал-ребилд устранена до передачи — ни одного пропущенного текста, ни одной битой внутренней ссылки, ни одного структурного расхождения **Сдано** **ТЗ соблюдено строка за строкой — 115 URL, 66 редиректов с изменением путей, 12 шаблонов, контрольный список запуска на 74 пункта** **Ритм взаимодействия** 36 задач от агентства · все закрыты к моменту передачи **Раунды проверки** ≈2 раунда проверки в рамках 16-дневного окна **Контрольный список запуска** 74 пункта, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США, работающее с Venetian Pet Hospital — ветеринарной клиникой домашних животных в Stockton, CA, — привлекло нас для ребилда существующего сайта на Elementor Pro на Kinsta. Агентство уже выполнило стратегическую работу: таблица Google Sheets с картой 115 URL, 66 изменений путей с 301 редиректами, все подлежащие сохранению мета-заголовки и описания, полный список шаблонов и контрольный список запуска на 74 пункта. Задача была конкретной. Взять таблицу агентства как данность; выполнить ребилд сайта на Elementor Pro; реализовать каждый редирект точно по карте; передать готовым к переключению. Оставаться вне контура связи с клиентом. Реализовать SEO-решения как написано. Сдать в рамках согласованных часов. На сайте-доноре были пробелы в контенте — страницы услуг с разреженным текстом и частично пустыми секциями, которые таблица агентства не могла охватить; где в таблице не было значения, мы отмечали, а не заполняли. Объём миграции на этом ребилде составил 66 редиректов с изменением путей: 53 URL страниц услуг и 11 записей блога реструктурированы, плюс путь к форме записи — каждый из них задокументированная зависимость в таблице агентства, каждый критичен для конверсионных путей ветеринарной клиники. Риск — подрядчик, который тихо «округлит углы» этой миграции: один пропущенный редирект, один путь с несовпадением по слешу, одна форма, указывающая на legacy URL. На ветеринарном сайте битый редирект теряет не просто посетителя — он теряет владельца животного, пытающегося попасть на форму записи или страницу загрузки медицинских карт. > **Контекст рисков.** Ребилд с 66 редиректами с изменением путей — это сложная миграция: каждый legacy-URL блога, каждая страница услуги, каждый ресурс по здоровью животных должен попасть на корректный новый путь без цепочек и коллизий. Ошибка не в отсутствующей странице — это редирект, который выглядит корректно в браузере, но разрешается в 404 при обходе, или URL формы, всё ещё указывающий на старый путь и выдающий ошибку без предупреждения, когда владелец отправляет карту своего животного. Агентству нужна была команда, которая относится к карте редиректов как к несущей конструкции, а не украшению. ## Как мы это сделали **1. Сборка на основе шаблонов.** Вместо того чтобы перестраивать 115 страниц по одной, мы свели их к двенадцати переиспользуемым шаблонам и разместили каждую страницу в соответствующем: - Homepage, About Us, Contact Us и Default Template запасной - **Services Lander + Service Page** — единый переиспользуемый шаблон для 53 отдельных страниц услуг и здоровья животных - **Blog Lander + Blog** — архив постов и шаблон отдельного поста для 11 записей блога - **Gallery** — страница фотогалереи клиники - **Video Gallery + Video Page** — галерея видеоресурсов и отдельные страницы видео - **Forms** — шаблон для страниц с формами (запись на приём, загрузка медицинских карт) 12 шаблонов — 115 страниц сданы. Будущие правки со стороны агентства живут в одном месте на тип страницы. **2. ТЗ соблюдено строка за строкой, по таблице агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции с целевым путём, каждый мета-заголовок и описание для переноса, каждое назначение шаблона. Объём в часах по строкам мы оценили сами; дальше реализовали каждую строку как написано. Где таблица указывала 301 редирект с legacy-пути, редирект реализовали точно по спецификации — без сокращений по слешам, без предположения, что «достаточно близко» сработает корректно. Где в таблице было значение — это значение попало на новый сайт. Где его не было — мы отметили это для агентства. Никаких «творческих интерпретаций» мы не сдавали. Коротко: на ребилде ТЗ — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. **3. Проверка на основе обхода, а не «на глаз выглядит нормально».** Перед переключением DNS мы параллельно прогнали Screaming Frog на действующем исходном сайте и в тестовой среде ребилда. Коды статуса, битые ссылки, цепочки редиректов, различия в мета-тегах — каждое расхождение сверено с ТЗ агентства. При 66 редиректах с изменением путей точность назначения проверяли индивидуально: legacy-URL блога, перенаправляющий на `/blog/slug/`, не должен «уплывать» на `/blog/`. Второй обход после запуска подтвердил, что каждая внутренняя ссылка корректно разрешается на действующем домене. **4. Контрольный список запуска на 74 пункта, закрыт до передачи.** Восемь категорий: разработка / основное, коды статуса, редиректы, контент, SEO и аналитика, адаптивность, клиент-специфичные интеграции и проверка после релиза. Ничего не сдавали, пока не согласовали каждую строку. QA на разных устройствах на Chrome / Firefox / Safari / Edge и множестве типов экранов, включая мобильную портретную и альбомную ориентацию. Карта сайта тестовой среды содержала пути с двойным слешем, которые по-разному разрешались под CDN — незаметное расхождение, проходящее проверку в браузере, но сбоящее при обходе. Мы отметили расхождение для агентства и согласовали все затронутые строки до переключения. На миграции с 66 редиректами одна неразрешённая неоднозначность пути — не мелкая проблема; это битый конверсионный путь, на который натыкается владелец животного при попытке попасть на форму записи. ## Результаты Метрика Результат Точность по ТЗ — URL мигрированы **115 / 115** URL перестроены и возвращают HTTP 200 в тестовой среде до переключения Точность по ТЗ — редиректы **66 / 66** редиректов с изменением путей реализованы как 301, по спецификации Точность по ТЗ — шаблоны **12 / 12** шаблонов построены и применены на всём сайте Контрольный список запуска **74 / 74** пунктов проверены и утверждены до переключения Сроки **~16 дней** для основного ребилда, сдано по графику; очередь задач проверки закрыта к 21 августа Затраты **~63 ч** по оценке — без перерасхода, без расширения объёма Проверка адаптивности QA на разных устройствах подтверждён на настольных и мобильных устройствах Внутреннее QA Вся очередь задач в рамках объёма агентства выполнена до передачи Статус сайта [venetianpethospital.com](https://venetianpethospital.com/) работает на Kinsta и возвращает HTTP 200 Если коротко: ТЗ агентства было реализовано как написано, в рамках согласованных часов, в запланированный день переключения. Сайт ветеринарной клиники на 115 страниц с 66 редиректами мигрирован без расхождения редиректов и функциональных регрессий. ## Контроль качества Предварительное QA выявило две проблемы до передачи: орфографическую ошибку в главном меню (Ceterinary Medicine исправлено на Veterinary Medicine) и проблему с форматом href в тел:ссылках на контактных страницах, где пробел между схемой и номером препятствовал разрешению ссылки — обе закрыты до того, как агентство увидело тестовую среду. Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Свой проверочный контур агентства запускался после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день ТЗ агентства проанализировано; ~43 ч на основной ребилд согласованы Разработка ~10 дней Весь сайт перестроен по 12 шаблонам; 66 редиректов реализованы Внутреннее QA и проверка 2 дня Очередь задач SEO и CX выполнена; все пункты в рамках объёма агентства закрыты Проверка по ТЗ 1 день Цели редиректов и мета-данные сверены с таблицей; обход подтверждён Сдача и переключение DNS 1 день Сайт работает на Kinsta, без простоя _Фазы перекрываются (QA шло параллельно с поздней разработкой), поэтому календарная длительность — ~16 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта, система шаблонов и реализация редиректов) - **Павел Сажин** — QA и реализация исправлений после релиза - **Анна Полунина** — поддержка разработки и QA по перестроенным страницам - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороной агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на протяжении всего переключения и миграции. Все решения по сохранению URL, стратегии редиректов и назначению шаблонов принадлежали агентству; наша роль — точность исполнения предоставленного ТЗ. ## Агентствам, заказывающим ребилд WordPress > На ребилде карта редиректов и преемственность мета-тегов держат на себе те позиции, которые агентство уже заработало. У этой практики структура путей несущая — многолетний блог о здоровье животных и разветвлённый каталог услуг; у плоского сайта карта редиректов почти декоративна. Стоит отнестись к несущей карте как к декоративной — и URL, по которым агентство ранжируется, после переключения отдадут 404. Мета-заголовки и описания тихо перезапишутся — сниппеты в выдаче поменяются за одну ночь. Пути форм и файлов, оставшиеся на старой архитектуре, начнут терять заявки без всякой ошибки. Подрядчику стоит задавать не вопрос «сделаете ли редиректы?», а вопрос «как именно вы сверите каждый URL, мета-заголовок и путь формы ещё до первой строки кода шаблона?» Пришлите адрес действующего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим каждый путь с вашими данными по позициям, найдём редиректы и мета-теги, которые нужно защитить, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-lp-redesign-leadership-consulting-elementor-8-days/ title: Лендинг консалтинга для руководителей за 8 дней — из Figma в Elementor Pro type: case_study date: 2025-02-06T22:34:16+00:00 case_industry: Профессиональные услуги case_type: Другое case_practice: wordpress --- ## Подход к проекту Одностраничный лендинг на свежей установке WordPress, заменяющий существующий сайт на Squarespace за 8 дней — из Figma в Elementor Pro на WP Engine, с Gravity Forms и шестью якорными секциями, корректно работающими на мобильных устройствах и большом экране. Ключевое ограничение поставки — точность: на сайте из одного URL якорная навигация несёт всю UX-архитектуру — ошибочная цель не имеет запаса прочности. ## Краткий обзор Поле Значение Индустрия конечного клиента Профессиональный консалтинг — коучинг для руководителей Конечный клиент Kazoo Leadership (коучинг и консалтинг для руководителей) **Формат сотрудничества** **White-label сборка лендинга для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Из Figma в Elementor Pro — одностраничный лендинг на WP Engine, заменяющий существующий сайт клиента на Squarespace Объём **1 лендинг** — полная реализация Figma на новой установке WordPress; якорная навигация по шести именованным секциям; интеграция контактной формы Gravity Forms Сроки 8 дней (18–26 июня 2025), по графику Затраты **~17 часов** — ~14 ч сборка и правки · ~3 ч QA Команда 3 специалиста (разработчик + QA + руководитель проекта) Передача дизайна дизайн в Figma (принадлежит агентству; URL дизайна не раскрыт) — бриф требовал Elementor Pro и Gravity Forms на новой тестовой среде WP Engine Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Режим сборки** **Сначала черновик на тестовой среде** — страница собрана и проверена на тестовом инстансе WP Engine; не переносилась на действующий сайт до согласования QA **Сдано** **Одностраничный лендинг сдан по ТЗ — Figma реализована в Elementor Pro, якорная навигация по 6 секциям, форма направляется клиенту, сайт работает на kazooleadership.com** **Раунды проверки** ≈1 раунд проверки ## Постановка задачи Маркетинговое агентство из США, работающее с Kazoo Leadership — практикой коучинга и консалтинга для руководителей, — нуждалось в новом лендинге на основе готового дизайна в Figma с развёртыванием на домене клиента. Существующий сайт работал на Squarespace; бриф агентства предусматривал свежую установку WordPress на WP Engine со стеком Elementor Pro и Gravity Forms. Без миграции страниц, без карты редиректов, без предыдущей установки WordPress — чистая сборка на пустом инстансе WordPress. Формат 1 страницы означал, что страница должна делать всё: представить руководителя (David Hopkins), описать спектр услуг, обозначить критерии идеального партнёра, показать отзывы и принимать заявки — всё в виде одностраничного сайта с прокруткой и переходами по секциям. Figma специфицировала 6 якорных целей (About David, Services, Ideal Practice Partners, Testimonials, Contact) плюс навигационный элемент перехода по темам, который должен был корректно отрабатывать по каждой. Бриф был однозначным: воспроизвести Figma в Elementor Pro на новом тестовом инстансе WP Engine; настроить Gravity Forms на email клиента; сделать якорную навигацию рабочей и точной до пикселя на мобильных устройствах и большом экране; сдать, когда QA пройдено. > **Контекст рисков.** На одностраничном лендинге якорная навигация — не вспомогательная функция, а вся UX-архитектура сайта. Каждая именованная секция — одновременно и контент, и пункт назначения: посетитель, следующий по меню перехода агентства, должен оказаться именно там, где предусмотрено дизайном. На одностраничном сайте нет запаса в виде корректно адресованной подстраницы; сломанный или неверно названный якорь разрушает структуру, которую агентство спроектировало для каждого посетителя с любого канала. В сочетании со сменой платформы с Squarespace на WordPress эта сборка несла требование к точности, которого обычно нет при доработке темы: каждая якорная цель, каждая мобильная точка адаптации и каждый маршрут формы должны были пройти проверку по ТЗ до публикации страницы. ## Как мы это сделали **1. Из Figma в Elementor Pro на чистой установке WordPress.** Никита Тумашевич собрал полный лендинг по утверждённой Figma на тестовом инстансе WP Engine, выделенном под проект. Elementor Pro и Gravity Forms установили до начала сборки; лендинг был единственным URL на установке WordPress, что сохраняло среду сборки чистой, а область проверки QA — минимальной. **2. Реализация якорной навигации по шести именованным секциям.** Figma специфицировала навигационное меню перехода по темам с шестью именованными пунктами назначения. Каждая секция требовала соответствующей якорной цели в Elementor — точно обозначенной по дизайн-спецификации — со списком перехода, корректно работающим как на большом экране, так и на мобильных устройствах. В Elementor это реализуется прямо, но требует явного QA: якорь, выглядящий корректно на полной ширине большого экрана, может незаметно отработать некорректно на мобильных, где высота секции меняется. Первый проход QA выявил якорь, который ещё не был подключён к контактной секции; второй проход подтвердил корректную работу всех шести после исправления. **3. Соответствие Figma на всех разрешениях экрана.** QA-проверка по Figma выявила несколько расхождений вёрстки, характерных для переноса из Figma в Elementor Pro: секция hero отображалась с уменьшенной шириной относительно full-bleed замысла дизайна; межбуквенное расстояние в типографике, которое стандартные настройки Elementor не воспроизводили; и мобильная вёрстка со сжатыми секциями, требовавшая корректировки точки адаптации. Павел Сажин задокументировал каждое расхождение с референс-скриншотами; Никита применил исправления до того, как QA передали на согласование агентству. **4. Маршрутизация формы и проверка перед передачей.** Gravity Forms настроили на email клиента для контактной секции в нижней части страницы. QA перед передачей подтвердило маршрутизацию формы, все якорные переходы и страницу на трёх типах экранов до того, как тестовую среду представили агентству для проверки. Якорь контактной кнопки был исправлением, завершившим сборку. Первый проход QA Павла отметил все 5 целей меню перехода как неподключённые; Никита подключил их; второй проход 2 дня спустя выявил кнопку контакта — не в меню, но доступную из каждого CTA на странице. На сайте из 1 URL каждый якорь либо работает корректно, либо ломает единственную навигационную структуру страницы. ## Контроль качества QA этого одностраничного лендинга прошло два прохода — первый выявил сломанную мобильную вёрстку на малых ширинах экрана и все пять целей меню перехода как неподключённые; второй проход после исправлений Никиты выявил дополнительный якорь контактной кнопки до того, как сборка была представлена агентству. Предварительное QA прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принципу «ноль ошибок». Контроль на стороне агентства запускался после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до окончательного согласования. ## Результаты Метрика Результат Сборка лендинга Сдан — Figma реализована в Elementor Pro на чистой установке WordPress на WP Engine Режим сборки **Сначала черновик на тестовой среде** — страница собрана и проверена на тестовом инстансе WP Engine; выпущена в работу после согласования с агентством Объём 1 лендинг · 6 секций с якорями · интеграция контактной формы Gravity Forms Раунды QA Внутренний QA-проход Павла Сажина по Figma и трём типам экранов; исправления Никиты; второй раунд пройден до передачи Сроки **8 дней** (18–26 июня 2025), по графику Затраты **~17 часов** — 14 ч сборка и правки · 3 ч QA Команда 3 специалиста — без отдельного аналитика, без дизайн-лида (принадлежит агентству), без SEO-лида (нет объёма миграции) Статус сайта, проверено 04.2026 [kazooleadership.com](https://www.kazooleadership.com/) работает, возвращает HTTP 200 по свежей проверке Если коротко: одностраничный лендинг был построен по Figma на свежей установке WordPress, проверен на точность якорей и соответствие вёрстки на всех разрешениях экрана, с настроенной маршрутизацией формы и передан агентству на утверждение за восемь календарных дней и семнадцать часов работы. ## Процесс Этап Длительность Результат Бриф и оценка 1 день Figma проанализирована, тестовая среда WP Engine настроена, Elementor Pro и Gravity Forms установлены Сборка лендинга (тестовая среда) ~4 дня Полный одностраничный лендинг реализован в Elementor Pro; все 6 секций, якорные цели и блок формы построены Внутреннее QA ~1 день Павел Сажин по Figma и трём типам экранов; расхождения вёрстки и отсутствующие якоря задокументированы Правки ~1 день Никита применил коррективы вёрстки — hero на полную ширину, межбуквенное расстояние, мобильная точка адаптации, подключён якорь контакта Финальная проверка + передача ~1 день Все шесть якорей проверены; маршрутизация формы подтверждена; страница одобрена для проверки и согласования с агентством _На одностраничном проекте цикл правок замыкается быстро — каждое исправление изолировано в известной секции Elementor, а не распределено по многостраничному дереву шаблонов. QA и правки шли как один непрерывный проход в последний день перед передачей._ ## Команда **Команда проекта** - **Никита Тумашевич** — сборка лендинга в Elementor Pro по Figma; правки вёрстки и реализация якорей - **Павел Сажин** — QA по Figma и типам экранов; направление правок; согласование перед передачей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, настройка тестовой среды, координация согласований) Проектное управление, дизайн и коммуникация с клиентом со стороны агентства оставались за партнёрским агентством на протяжении всего проекта. Наша команда была невидима для конечного клиента. Бриф, Figma и все замечания поступали через агентство; клиент получил готовую страницу. ## Агентствам с продуктовыми задачами > На сайте коуча якоря держат всю воронку: внешние ссылки, реклама и письма агентства ведут посетителя прямиком в конкретную секцию. У этой практики — одностраничный лендинг с личным брендом и программой; у других — многостраничный портал с вебинарами, кейсами и корпоративными программами. Если подрядчик возьмётся неаккуратно, якорная ссылка из рекламного объявления поведёт посетителя в пустую секцию. Мобильный блок с формой записи окажется за границей видимости. Партнёрские обратные ссылки, которые агентство выстраивало месяцами, перестанут вести на нужный контент. Агентству придётся объяснять коучу, почему лиды не доходят. Подрядчику стоит задавать не вопрос «соберёте ли одностраничник?», а вопрос «как именно вы зафиксируете якоря, чтобы они совпадали с нашими маршрутами после сборки и правок?» Пришлите макеты или рабочую таблицу проекта. Мы пройдём по каждому маршруту ваших кампаний. Сверим его с якорной картой после сборки и отметим расхождения для всех каналов. Вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-dental-website-redesign-figma-elementor-54-days/ title: Редизайн сайта стоматологии за 54 дня — из Figma в Elementor Pro type: case_study date: 2025-02-03T07:21:22+00:00 case_industry: Здравоохранение case_type: Редизайн case_practice: wordpress --- ## Подход к редизайну 10 шаблонов страниц из Figma наложили на 102 страницы сайта стоматологической практики из Fort Lauderdale — и до сдачи вычистили все упоминания прежнего позиционирования практики «Boutique & Spa». Страницы уже лежали на сервере тестовой среды; задача была наложить дизайн и зафиксировать пробелы в контенте, а не собирать с нуля. Наша роль — точность по Figma на каждом шаблоне и полная зачистка наследия бренда до того, как агентство запустит сайт. ## Краткий обзор Параметр Значение Отрасль клиента Медицина — общая стоматология Клиент DG Dental (Dr. Dory Green, Fort Lauderdale, FL) **Формат сотрудничества** **White-label редизайн сайта стоматологии для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип работы Полный редизайн сайта из Figma в Elementor Pro — применён ко всем шаблонам страниц Объём **~102 страницы** — главная, О нас, Услуги (лендинг + отдельные страницы услуг), Блог (лендинг + посты), Контакты, Финансирование/Страховка, Биография врача, Галерея результатов Сроки 54 дня (28 мар – 21 мая 2025), по графику Затраты времени **~68 часов** — разработка по 10 типам шаблонов, интеграция контента, QA-раунды, правки после сдачи Команда 3 специалиста (ведущий разработчик + ведущий QA + руководитель проекта) Передача дизайна Макеты Figma (принадлежат агентству; URL Figma не раскрываются — интеллектуальная собственность агентства) — 10 макетов страниц + главная Технологии WordPress · Elementor Pro · хостинг WordPress агентства · Site Checker ([xaverPRO](https://xaver.ru/) QA-плагин) **Режим разработки** **Соответствие Figma** — каждый тип шаблона создан по референсу Figma; контент для каждой страницы предоставлен агентством **Результат** **Полный редизайн сайта стоматологической практики по спецификации Figma — 10 шаблонов, ~102 страницы, размещён на сервере агентства и готов к запуску** **Раунды проверки** ≈4 раунда проверки за 54 календарных дня ## Постановка задачи Маркетинговое агентство из США, ведущее стоматологического клиента — практику Dr. Dory Green в районе Fort Lauderdale — нуждалось в редизайне существующего сайта на WordPress в соответствии с новым брифом Figma. Бриф охватывал весь сайт: главную страницу, все страницы услуг, страницу «О нас» с подстраницей биографии врача, лендинг блога и шаблон поста, страницу финансирования и страховки, а также галерею результатов. Всего 10 различных типов макетов страниц, применённых примерно на 100 страницах. Агентство уже перенесло существующий контент в тестовую среду на своём сервере. Нашей задачей было применить дизайн Figma к каждой странице — проверить наличие контента, применить дизайн и отметить пробелы. Бриф также требовал удалить прежний брендинг, утративший актуальность: практика отказывалась от прежнего позиционирования «Boutique & Spa», и все остаточные упоминания этого бренда нужно было удалить по всему сайту до сдачи. Задача была сформулирована чётко: воспроизвести Figma по всем типам страниц, разложить предоставленный контент согласно Google Docs агентства, подтвердить, что все страницы на месте и оформлены верно, и сдать агентству для запуска. Не выходить на прямой контакт с конечным клиентом. Оставаться невидимой частью реализации. > **Контекст рисков.** Полный редизайн стоматологического сайта в тестовой среде текущего клиента несёт иной профиль рисков, чем сборка с нуля. Страницы уже существуют; контент уже на месте. Сломается не отсутствующая страница, а неправильно наложенный элемент дизайна, который незаметно расползётся по 40 страницам услуг, прежде чем кто-то его заметит, — или упоминание прежнего бренда, пережившее редизайн и всплывающее при поиске по имени пациента. Агентство защищает от этого одно: проверяем каждый шаблон, сверяем каждую страницу с контентом, находим и удаляем каждое упоминание старого бренда до сдачи. ## Как мы это сделали **1. Из Figma в Elementor Pro, шаблон за шаблоном.** Главную и каждый из 10 типов шаблонов собрали в Elementor Pro по утверждённым макетам Figma. Никита Тумашевич вёл разработку, последовательно проходя каждый тип шаблона — макет услуг, макет блога, биографию врача, галерею результатов, контакты и страницу финансирования — после чего перешёл к этапу наложения контента на каждую страницу. Поскольку Elementor Pro уже был установлен в тестовой среде, разработка вписалась в существующую инфраструктуру без внедрения новых зависимостей. Бриф Figma был единственным референсом для визуальных решений; интерпретация объёма работ не потребовалась. **2. Интеграция контента по Google Docs агентства.** Агентство предоставило контент для каждой страницы в Google Docs — по одному документу на тип шаблона, с описанием текстов, заголовков и структуры CTA для каждой страницы. Контент разместили в нужных блоках Elementor по дизайну. Страницы услуг потребовали больше ручных решений, чем остальные — исходный сайт был набором длинных статей, а Figma вводила отдельные секции контента («Об услуге», «Как это работает», «Преимущества»). Контент по этим секциям разнесли вручную, все неясности помечали до сдачи. **3. Зачистка наследия бренда.** Практика находилась в процессе ребрендинга, отходя от прежнего позиционирования «Boutique & Spa». Это потребовало прохода по всему сайту, чтобы удалить упоминания прежнего бренда — в текстах страниц, ссылках в блоге и в любом другом видимом месте, где мог сохраниться старый бренд. Эта работа отслеживалась в QA-таблице агентства и была завершена до финальной сдачи. **4. QA-раунды перед сдачей агентству.** Внутренний QA проводил Павел Сажин — проверка каждого типа шаблона на соответствие Figma и подтверждение корректности назначения контента по страницам. Вкладка QA в Google Sheets агентства отслеживала открытые вопросы по приоритетам. В рамках основного проекта решались только вопросы высокого приоритета; уточнения с низким приоритетом продолжались в дополнительных правках после первичной сдачи. Перераспределение 40+ страниц услуг из формата длинных статей в трёхсекционный макет Figma — «Об услуге», «Как это работает», «Преимущества» — потребовало больше всего внимания на проекте. Применить шаблон было просто; распределить контент по правильным блокам, не теряя текст и не перегружая секции — вот на что ушли часы разработки. ## Контроль качества В этом проекте нагрузка QA пришлась на структуру URL и зачистку наследия бренда: QA перед сдачей выявил, что все 102 страницы доступны как со слешем, так и без — общесайтовые редиректы настроены до сдачи — а также циклический редирект по ссылке с логотипа на главной; проход по контенту удалил все упоминания «Boutique & Spa» со страниц, постов и меню согласно QA-контрольному списку агентства. QA перед сдачей проводился через **Site Checker** — см. [наш подход к QA](/site-checker/) о категориях и пороге нулевых ошибок. Внутренний контур проверки агентства работал после сдачи и сводил замечания в общую очередь правок для нашего цикла исправлений, пока агентство не подписало приёмку. ## Результаты Метрика Результат Редизайн сайта Выполнен — Figma наложена в Elementor Pro на все ~102 страницы и 10 типов шаблонов Режим разработки **Соответствие Figma** — все визуальные решения в рамках брифа; отклонения согласовывались с агентством до реализации Шаблоны **10 типов шаблонов** — главная, О нас, лендинг услуг, страница услуги, лендинг блога, пост блога, контакты, финансирование/страховка, биография врача, галерея результатов Зачистка наследия бренда Все упоминания «Boutique & Spa» удалены по всему сайту согласно QA-контрольному списку агентства QA-раунды Внутренний QA от Павла Сажина — все вопросы высокого приоритета решены до сдачи Сроки **54 дня** (28 мар – 21 мая 2025), по графику Затраты времени **~68 часов** — распределено между реализацией дизайна, интеграцией контента, QA и правками после сдачи Команда 3 специалиста — без отдельного аналитика, без дизайн-лида (на стороне агентства), без SEO-лида (миграция не входила в объём) Сдача Размещён на сервере агентства, готов к запуску под контролем агентства Если коротко: Figma агентства наложена на все типы страниц стоматологического сайта, прежнее позиционирование бренда удалено, все вопросы QA высокого приоритета решены, сайт размещён в тестовой среде и готов к запуску силами агентства. ## Этапы Этап Длительность Результат Бриф и оценка ~3 дня Figma проанализирована, перечень страниц подтверждён (102 URL), Elementor Pro подтверждён Реализация дизайна ~2 недели Все 10 типов шаблонов созданы по Figma; контент наложен из Google Docs агентства Внутренний QA ~1 неделя Павел Сажин проверил все типы шаблонов; вопросы высокого приоритета зафиксированы и решены Зачистка наследия бренда + правки контента ~1 неделя Упоминания Boutique & Spa удалены; правки контента по запросу агентства внесены Дополнительные правки после сдачи ~3 недели Правки по QA-таблице агентства — вопросы низкого приоритета и уточнения контента _Этапы пересекались — QA шёл параллельно с интеграцией контента на поздних стадиях, а дополнительные правки после сдачи обрабатывались одновременно с проверкой со стороны агентства. Календарные 54 дня отражают полный цикл проекта от открытия до закрытия последней задачи._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная реализация дизайна сайта, система шаблонов, сборка из Figma в Elementor) - **Павел Сажин** — QA и координация проекта (внутренние QA-раунды, коммуникация с агентством, отслеживание задач) - **Анна Полунина** — поддержка разработки и QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, согласование с агентством) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне партнёрского агентства на всём протяжении проекта. Конечный клиент нас не видел. Все дизайн-решения принадлежали агентству; наша роль заключалась в точности Figma на каждой странице и каждом типе шаблона. ## Агентствам, заказывающим редизайн WordPress > При редизайне стоматологического сайта страницы уже существуют. Риск не в пропавшей странице, а в визуальной поломке, которая незаметно расползается по шаблонам. У этой практики — сеть кабинетов с общими профилями врачей; у других — один кабинет. Сценарии тихие: токен старого бренда обойдёт виджеты в архиве, а строка с врачом всплывёт на странице, которую редизайн пропустил. Подрядчику стоит задавать не «перерисуете ли страницы?», а «как вы прогоните шаблоны по всем страницам и поймаете упоминания старого бренда?» Пришлите макеты и текущий перечень URL. Мы сверим зазор между вашей библиотекой компонентов и живыми страницами, найдём упоминания старого бренда, которые редизайн может пропустить, и вернём смету в фиксированных часах. Аудит за счёт нашей стороны, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-amazing-smiles-las-vegas-20-days/ title: Ребилд стоматологического сайта в Лас-Вегасе — срок остановки платформы, 20 дней type: case_study date: 2025-01-28T21:33:59+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Ребилд за 20 дней с жёстким сроком остановки платформы — стоматологическая managed-hosting платформа клиента прекращала работу 1 июня 2025, продлить срок было нельзя. Мы уложились в оценку 44,2 часа, вынесли раздел библиотеки за рамки объёма по указанию агентства, исправили дублирующиеся метаданные, перешедшие со старой платформы, и передали проект в окно проверки агентства до даты остановки. ## Краткий обзор Поле Значение Индустрия конечного клиента Стоматология Конечный клиент Amazing Smiles Dentistry (Las Vegas, NV) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress со стоматологической managed-hosting платформы на WordPress + Elementor Pro на WP Engine Объём работ Полный сайт — услуги, страницы врачей и команды, раздел библиотеки исключён, контактные формы, внедрение метаданных Срок 20 дней (30 апр — 20 мая 2025), по графику с жёстким внешним сроком Трудозатраты 44,2 часа при оценке 44,2 часа — без перерасхода Команда 4 специалиста (разработка · QA · контент · PM) Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Rank Math Pro · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка контента Сверка контента старого сайта и ребилда пройдена перед сдачей — ни одной потери текста, ни одной битой внутренней ссылки, ни одного структурного отклонения **Сдано** **ТЗ выполнено построчно — редиректы, мета-теги, граница объёма по разделу библиотеки соблюдена, оценка в 44,2 часа выдержана** **Раунды проверки** ≈3 раунда проверки в рамках 20-дневного календарного окна ## Постановка задачи Amazing Smiles Dentistry стоял на стоматологической managed-hosting платформе, обслуживание которой прекращалось. У агентства была точная дата — остановка платформы, — и требовалось полностью завершить ребилд WordPress и запустить сайт до этой даты. Срок продлить было нельзя; затянись разработка — клиент остался бы без работающего сайта. Таблица Google Sheets агентства держала каждый URL для переноса, каждый редирект, каждый мета-тег и описание. Один структурный вопрос требовал явно очертить границы: на старой платформе был раздел `/library/` с десятками подстраниц учебного контента по стоматологии — в карту сайта агентства они не входили. Решение, переносить эти подстраницы или исключить, принадлежало агентству, а не нам. Мы подтвердили границу объёма, исключили подстраницы библиотеки по указанию и завели входящие ссылки на раздел в карту редиректов. В спецификацию входила и проверка метаданных: на этапе QA нашлись дубли H1 и мета-описаний, перешедшие со старой платформы. Их исправили по таблице Google Sheets перед сдачей. Ставка здесь была выше, чем в типичном ребилде. Срыв срока на проекте без запасной платформы — не неудобство, а период полного отсутствия сайта. Агентству нужна была команда, которая выдержит оценку, выдержит сроки и не допустит расползания объёма, съедающего оставшееся время. > **Контекст рисков.** Внешнее ограничение в этом проекте было категоричным: унаследованная хостинг-платформа прекращала работу в дату, которую агентство не могло изменить. Каждый час перерасхода сужал окно для QA агентства перед запуском. Обычный риск ребилда — потеря позиций из-за пропущенного редиректа — тоже присутствовал, но был второстепенным. Первостепенным риском был перерасход, который сжал бы окно согласования агентства до такой степени, что клиент запустил бы сайт с непроверенной работой — или не запустил бы вовсе. Точное соблюдение оценки в 44,2 часа было не вопросом удобства, а условием, сделавшим возможной упорядоченную сдачу. ## Как мы это сделали **1. Сборка на основе шаблонов.** Весь сайт был свёрстан в единый набор шаблонов: — Главная, О нас, Контакты и универсальный шаблон по умолчанию — **Шаблон страницы услуг + шаблон отдельной услуги**, покрывающие весь каталог лечения клиники — **Шаблоны страниц врачей и команды** для биографий специалистов — Универсальные шаблоны контента для остальных страниц Явная граница объёма: подстраницы раздела `/library/` со старой платформы мы согласовали с агентством как лежащие вне объёма работ до начала разработки. Входящие ссылки на этот раздел завели в карту редиректов, а не переносили страницы. **2. ТЗ выполнено построчно, из таблицы агентства.** Каждый целевой URL, каждый редирект, каждый мета-тег и описание взяты из таблицы Google Sheets. Дубли метаданных, найденные при QA — одинаковый текст H1 на нескольких страницах услуг, перешедший с шаблонной системы старой платформы, — мы пометили и исправили по постраничным указаниям таблицы перед сдачей. Где таблица задавала значение, это значение попадало на новый сайт. Коротко: спецификация — это договор. Когда старая платформа занесла в данные аномалии контента (дубли заголовков, дубли описаний, шаблонный текст-заполнитель), исправить их — значит внимательнее прочитать таблицу, а не импровизировать с правками. **3. Проверка обходом, а не «на вид нормально».** До переключения DNS мы прогнали Screaming Frog и по тестовой версии ребилда, и по старой платформе. Коды статуса, цепочки редиректов, соответствие мета-тегов — каждое расхождение сверяли с таблицей. Исключение раздела библиотеки проверили: ни один путь подстраниц библиотеки не остался действующим URL на новом сайте, а карта редиректов покрывала основной вход в раздел. Повторный обход после запуска подтвердил, что внутренние ссылки работают на опубликованном домене. **4. Контрольный список запуска, закрыт перед сдачей.** Дизайн, функциональность, точность контента, SEO и аналитика, адаптивный вывод и миграция DNS на WP Engine — всё закрыто перед сдачей. Жёсткие сроки диктовала остановка платформы; контрольный список сжали, но не сократили. Жёсткий срок остановки платформы означал, что спецификацию надо прочитать до сборки первой страницы — порядок был не произвольным. Оценку в 44,2 часа выдержали, потому что карту редиректов и исправления метаданных сверили по таблице до переключения DNS, и у агентства осталось полное окно проверки до 1 июня. ## Результаты Метрика Результат Соответствие ТЗ — редиректы Все указанные агентством URL перенаправлены; граница раздела библиотеки соблюдена Соответствие ТЗ — метаданные Все мета-теги и описания установлены по спецификации; дублирующиеся метаданные исправлены по таблице Google Sheets Соответствие ТЗ — шаблоны Полная система шаблонов собрана и применена на всём сайте Граница объёма Подстраницы библиотеки корректно исключены; основной вход в раздел библиотеки обработан в карте редиректов Срок **20 дней**, сдано по графику — до даты остановки платформы Трудозатраты **44,2 ч / 44,2 ч** оценка — без перерасхода, без расползания объёма Проверка адаптивности Ноль проблем вёрстки в 4 браузерах × 6 разрешениях Внутреннее QA Все задачи в рамках объёма агентства закрыты до сдачи; после релиза проверка агентства добрала доработку контента в отдельном спринте Статус сайта Работает на WP Engine: [amazingsmilelv.com](https://amazingsmilelv.com/). Если коротко: спецификация агентства выполнена как написано, в рамках согласованных часов, до даты остановки платформы. Оценка выдержана; окно сдачи сохранено. ## Контроль качества На проверке перед сдачей нашлись дубли мета-описаний, перешедшие со старой платформы на страницах услуг (подтвердили вручную по каждой странице), и ошибочный noindex на подстраницах Invisalign. Обе проблемы исправили по таблице Google Sheets до того, как тестовая сборка ушла из наших рук. Проверку перед сдачей прогнали через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Собственная проверка агентства работала после сдачи и заносила замечания в общую очередь правок для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка 4 дня Спецификация агентства изучена; граница объёма по разделу библиотеки подтверждена; оценка 44,2 ч согласована Разработка ~12 дней Полный ребилд сайта по всем шаблонам; раздел библиотеки исключён по спецификации Внутреннее QA и проверка 2 дня Дублирующиеся метаданные исправлены; все работы в рамках объёма агентства завершены до сдачи Проверка спецификации 1 день Метаданные, редиректы и границы объёма сверены с таблицей Google Sheets Сдача и переключение DNS 1 день Сайт запущен на WP Engine без простоев — до даты остановки платформы _Этапы пересекались (QA шёл параллельно с завершающей разработкой), поэтому календарный срок составил 20 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** — **Никита Тумашевич** — ведущий разработчик (полная сборка сайта, система шаблонов, реализация редиректов) — **Анна Полунина** — поддержка разработки и оценка — **Евгений Карпов** — контентное QA и исправление метаданных — **Павел Сажин**, [xaverPRO](https://xaver.ru/) — QA и контроль сдачи — **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с агентством, согласование) Все решения по сохранению URL, стратегии редиректов и границам объёма принадлежали агентству; наша роль — точно реализовать переданную спецификацию. Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на всём протяжении проекта. ## Агентствам, заказывающим ребилд WordPress > При ребилде стоматологического сайта с жёстким внешним сроком вы несёте главный риск — расписание. У этой практики — одна клиника общей стоматологии, поток новых пациентов держится на видимости в локальной выдаче; у других — сеть под управлением DSO, где та же базовая копия живёт под разными доменами. Карта редиректов потеряет строку, и старая посадочная вернёт 404 вместо передачи ссылочного веса. Разметка процедур слетит на импорте, и расширенные сниппеты, на которые вы рассчитываете, исчезнут. Фиксированная дата переключения сожмёт ваше окно проверки, и непроверенная работа уйдёт в запуск. Подрядчику стоит задавать не вопрос «успеете ли в срок?», а вопрос «как именно вы выдержите расписание и не дадите карте редиректов и разметке слететь при переносе?» Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы пройдём ТЗ миграции по вашему списку ранжирующихся страниц, покажем строки редиректов и разметки, которые украдут ваше окно проверки, и вернём фиксированную смету в часах. Бесплатно, со сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-80-urls-19-days/ title: Ребилд стоматологического сайта на WordPress — 80 URL за 19 дней, white-label доставка type: case_study date: 2025-01-24T00:31:46+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 80 URL перенесли с плоских .html-файлов на вложенные WordPress-permalink’и через 10 шаблонов за 19 дней — карта URL, список редиректов и контрольный список запуска были за агентством. Каждый старый путь должен был вести на правильный новый адрес категории, а не на любой ответ 200. Из-за этого проверку редиректов пришлось ставить раньше визуального QA: каждый путь перепроверяли по старому сайту через Screaming Frog до того, как агентство закрывало приёмку. Проект нёс структурный риск, которого нет у ребилда с сохранением путей: старый сайт держался на плоских `.html`-файлах, а новый раскладывал все услуги во вложенные permalink’и категорий. Каждый старый URL должен был вести на правильный новый адрес — не на любой ответ 200, а на конкретный путь категории, указанный агентством. ## Краткий обзор Поле Значение Индустрия клиента Медицина — Общая, косметическая и восстановительная стоматология Конечный клиент Distinctive Dentistry by Mullens & Nguyen (Dr. Richard Mullens & Dr. James Nguyen, Jacksonville, FL) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг WP Engine Объём работ Весь сайт — 80 URL мигрированы с плоских `.html`-путей на вложенные WordPress-permalink’и через 10 шаблонов Сроки 19 дней (7 мая – 26 мая 2025), по графику Трудозатраты 74 часа при оценке 74 часа — без перерасхода Команда 4 специалиста (51 ч разработка · 10 ч QA · 10 ч PM · 3 ч добавление блога) Технический стек WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) Проверка контентного паритета Сравнение оригинального и нового контента выполнено до передачи — нет пропущенного контента, нет битых внутренних ссылок, нет структурных расхождений **Сдано** **Спецификация выполнена строка за строкой — 80 URL мигрировано, 10 шаблонов построено, редиректы при смене путей реализованы, контрольный список запуска из 29 пунктов закрыт** Последующая работа Добавление страницы блога и 2 раунда правок в течение следующих 2 месяцев — каждый в дополнительных спринтах в рамках тех же отношений с агентством **Ритм работ** 85 задач, поднятых агентством · все закрыты к моменту передачи **Раунды проверки** ≈5 раундов проверки за 19 календарных дней **Контрольный список запуска** 29 пунктов, согласованы до переключения ## Постановка задачи У агентства был постоянный клиент — стоматологическая клиника в Jacksonville, Florida, с тремя врачами (общая, косметическая и восстановительная стоматология), чей сайт работал на плоских `.html`-файлах, без современного конструктора страниц и системы шаблонов. Агентство выполнило стратегическую работу: таблица Google Sheets с картой каждого текущего `.html` URL на новый WordPress-permalink, каждым meta title для переноса, каждым назначением шаблона и контрольным списком запуска из 29 пунктов. Задача была конкретной. Взять таблицу как есть; выполнить ребилд сайта на Elementor Pro на WP Engine; перенести каждый URL со старого плоского пути на новую вложенную структуру категорий; вернуть готовым к переключению. Оставаться вне контура общения с клиентом. Реализовать SEO-решения как написано. Уложиться в согласованные часы. Структурный риск был в перестройке URL. Старый сайт держал страницы как одноуровневые `.html`-файлы — `/dentures.html`, `/dental-crowns.html`, `/teeth-whitening.html`. Новый вкладывал каждую услугу под её категорию — `/general-dentistry/dentures/`, `/cosmetic-dentistry/dental-crowns/`, `/cosmetic-dentistry/teeth-whitening/`. 2 страницы убрали целиком (`/dermal-fillers.html`; у `/childrens-dentistry.html` путь сменили на `/pediatric-dentistry/`). За каждой из этих 80 строк стояло обязательство по редиректу, и спецификация агентства называла точный адрес для каждой. > **Контекст рисков.** Когда ребилд перестраивает архитектуру URL — переходя от плоских `.html`-файлов к вложенным permalink’ам категорий WordPress — точность редиректов становится несущей конструкцией, в отличие от ребилда с сохранением структуры. Пропущенный редирект на странице услуги не даёт видимой ошибки на главной; он даёт 404 пациенту, перешедшему по существующей обратной ссылке или закладке. Сбой тихий, накопительный и обнаруживается только при обходе. Агентство подстраховывалось от подрядчика, который считает, что «сайт грузится» = «миграция завершена». ## Как мы это сделали **1. Сборка на шаблонах.** Вместо того чтобы пересобирать 80 URL по одному, мы свели их к десяти переиспользуемым шаблонам и разложили каждый URL по своему: - **Homepage, About Us, Contact Us** — брендовые и конверсионные страницы - **Services Lander + Service Page** — самый тяжёлый шаблон, обслуживающий все страницы отдельных услуг по категориям General Dentistry, Cosmetic Dentistry, Restorative Dentistry, Emergency Dentistry, Sedation Dentistry и Pediatric Dentistry - **Doctor Page** — отдельные страницы биографий Dr. James Nguyen, Dr. Jonathan B. Petrie и Dr. Richard Mullens - **Blog Lander + Blog** — архив контента и шаблон отдельной записи - **Smile Gallery** — макет «до/после» для данной клиники - **Default Template** — вспомогательные страницы (районы обслуживания, ресурсы для пациентов, политики) 10 шаблонов — весь сайт сдан. Будущие правки на стороне агентства живут в одном месте на каждый тип страницы. **2. Спецификация выполнена строка за строкой, по таблице агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции со старым `.html`-путём и новым WordPress-permalink’ом, каждый meta title и description для переноса, каждое назначение шаблона, каждую клиентскую интеграцию (перенос GA, маршрутизация Gravity Forms, reCAPTCHA). Мы реализовали каждую строку как написано. Где в таблице было значение — оно попадало на новый сайт. Где нет — две убранные страницы и три отметки «нужен контент» — мы возвращали вопрос агентству, а не импровизировали. Никаких «творческих трактовок» не ушло. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не править его. **3. Проверка обходом, а не «на вид нормально».** Перед переключением DNS мы прогнали Screaming Frog на старом опубликованном сайте и тестовой сборке параллельно. Коды ответа, битые ссылки, цепочки редиректов, расхождения в мета-тегах — каждое расхождение сверяли со спецификацией агентства. Особое внимание — редиректам при смене путей: редирект с `/tooth-colored-fillings.html` на `/restorative-dentistry/fillings/` не должен сползать на `/restorative-dentistry/`. Второй обход после запуска подтвердил, что все внутренние ссылки открываются на рабочем домене. **4. Контрольный список запуска из 29 пунктов, закрыт до передачи.** Семь категорий: Design, Functionality, Content, SEO & Analytics, Responsive, клиентские интеграции, миграция Domain & DNS на WP Engine. Ничего не сдавали, пока не согласовали каждый пункт. QA на разных устройствах на Chrome / Firefox / Safari / Edge и шести форматах экрана (1920 / 1280 / 1024 / iPad / мобильная вертикальная / мобильная горизонтальная). Контактную форму (Gravity Forms) проверили по всей цепочке, реальной отправкой. Перестройка 80 URL из плоских `.html`-файлов во вложенные permalink’и категорий означала, что проверка редиректов должна была закрыться до того, как визуальное QA вообще началось: именно смена пути, а не визуальная работа, была местом, где ошибка стоила бы агентству дорого. Каждый старый путь зафиксировали в таблице, перепроверили через Screaming Frog на исходном сайте и сверили со спецификацией до того, как тестовая сборка ушла на приёмку агентству. ## Результаты Метрика Результат Точность спецификации — URL мигрировано **80 / 80** URL мигрировано с плоских `.html`-путей на вложенные WordPress-permalink’и, как указано в спецификации Точность спецификации — редиректы при смене путей Все редиректы перестройки категорий реализованы как 301 со старых `.html`-путей Точность спецификации — шаблоны **10 / 10** шаблонов построено и применено на всём сайте Контрольный список запуска **29 / 29** пунктов согласованы до переключения Сроки **19 дней**, сдано по графику Трудозатраты **74 ч / 74 ч** оценка — без перерасхода, без расширения объёма Адаптивная проверка Ноль проблем с вёрсткой на 4 браузерах × 6 разрешениях Внутреннее QA Все задачи из объёма агентства закрыты до передачи **Статус сайта** Работает на WP Engine по адресу https://www.rcmdds.com/. Последующая работа Добавление страницы блога и 2 раунда правок в течение следующих 2 месяцев — каждый в дополнительных спринтах в рамках тех же отношений с агентством Если коротко: спецификация агентства выполнена как написано, в рамках оценённых часов, в запланированный день переключения. Год спустя сборка всё ещё в работе. ## Контроль качества Внутренний QA поймал, что сборка использует абсолютную ширину в пикселях на всём сайте — на 1024 px, планшете и мобильных вёрстка схлопывалась разом, — плюс невидимый H1 на страницах услуг; оба дефекта исправили в отдельном 10-часовом QA-проходе (Redmine #618) до передачи тестовой сборки, со снимками на разных разрешениях, подтверждающими, что каждое разрешение отображается чисто относительно оригинала. QA перед сдачей проводился через **Site Checker** — см. [наш подход к QA](/site-checker/): категории и порог нулевых ошибок. Собственный QA агентства шёл после передачи и складывал замечания в общую очередь правок для нашего цикла исправлений до их согласования. ## Процесс Этап Длительность Результат Бриф и оценка 2 дня Спецификация агентства рассмотрена; оценка 74 ч согласована Разработка ~14 дней 80 URL перестроены через 10 шаблонов на тестовой среде WP Engine Внутреннее QA и проверка 2 дня Задачи от агентства зафиксированы; все работы в рамках агентства закрыты Проверка спецификации 1 день Редиректы перестройки URL сверены с таблицей; обход подтверждён Доставка и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Этапы пересекаются (QA шёл параллельно с поздней разработкой), поэтому календарный срок — 19 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Павел Сажин** — правки QA и реализация метаданных - **Анна Полунина** — координация проекта, сверка объёма с таблицей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на всём протяжении переключения и миграции. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль заключалась в точности реализации их спецификации. ## Агентствам, заказывающим ребилд WordPress > Когда ребилд меняет структуру URL, карта редиректов становится единственной точкой непрерывности SEO. У этой практики — одна клиника общего профиля, у других — сеть филиалов, сводящая микросайты в единую структуру. Карта пропустит строку — старая обратная ссылка попадёт на 404. Новая тема перепишет meta description — сниппеты в выдаче сменятся без предупреждения. Разметка не переживёт переключение — Knowledge Panel погаснет. Вопрос не в том, «сделаете ли ребилд», а в том, как именно вы сопоставите каждый старый URL и сохраните meta и разметку до запуска. Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы сверим план редиректов с реальным списком URL, проверим пробелы по meta и разметке и вернём смету в фиксированных часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-23-urls-18-days/ title: Ребилд стоматологического сайта на WordPress: 23 URL по спецификации за 18 дней type: case_study date: 2025-01-21T00:02:47+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 23 URL ребилда сайта косметической стоматологии мы свернули в 9 шаблонов Elementor Pro по спецификации, которая разделила одну страницу «The Office» на четыре отдельных адреса и перестроила плоскую структуру услуг во вложенные категории. Агентству принадлежала стратегия и контрольный список запуска; нам — постраничная реализация за 18 дней и 66 часов. ## Краткий обзор Поле Значение Индустрия конечного клиента Здравоохранение — общая, косметическая и восстановительная стоматология Конечный клиент LALUME Dental Studio (Newport Beach, CA) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг Kinsta Объём работ Полный сайт — услуги, биография врача, страница опыта, блог, ресурсы для пациентов (формы, страховка, финансирование) Сроки 18 дней (24 июл – 11 авг 2025), по графику Затраты 66 часов при оценке 66 часов — без перерасхода Команда 6 специалистов (46 ч разработка · 10 ч PM · 10 ч QA) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Adobe Typekit · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка идентичности контента Сравнение контента оригинала и ребилда пройдено перед передачей — нет пропущенного текста, битых внутренних ссылок, структурных расхождений **Результат** **Спецификация выполнена строка за строкой — 23 URL перенесены, 9 шаблонов, контрольный список запуска на 75 пунктов** **Динамика взаимодействия** 37 задач от агентства · все закрыты к передаче (42 дня активного периода, 2025-08-16 – 2025-09-26) **Раунды проверки** ≈9 раундов проверки за 18 календарных дней **Контрольный список запуска** 75 пунктов, согласовано перед переключением DNS ## Постановка задачи У агентства был давний стоматологический клиент — бутиковая студия косметической и восстановительной стоматологии в Newport Beach, Калифорния, чей существующий сайт нуждался в ребилде на WordPress с хостингом на Kinsta. Агентство уже проделало стратегическую работу: таблица Google Sheets с соответствием каждого текущего URL новому пути, мета-заголовки и описания для переноса, полный список шаблонов и контрольный список запуска, покрывающий проверку до и после миграции. Задача была конкретной. Взять спецификацию как есть; пересобрать сайт на Elementor Pro; вернуть готовым к переключению DNS. Не выходить на прямой контакт с клиентом. Внедрить SEO-решения как предписано. Уложиться в оговоренные часы. Одно структурное решение в спецификации оказалось сложнее, чем казалось на первый взгляд: существующий сайт организовывал услуги по плоскому пути `/services/slug`, а ребилд перестраивал их во вложенные категории (`/cosmetic-dentistry/botox/`, `/restorative-dentistry/dental-implants/` и так далее). Кроме того, одна существующая страница «The Office» разделялась на четыре отдельных — Forms, Insurance, Financing и отдельная страница опыта. Каждое разделение и каждое изменение пути несли свои редиректы и требования к мета-данным. Спецификация покрывала всё это. Наша задача — реализовать каждую строку в точности как написано. > **Контекст рисков.** Когда ребилд меняет архитектуру URL — переводит страницы услуг с плоского пути на дерево вложенных категорий и разделяет одну страницу на несколько — карта редиректов становится несущей конструкцией, в отличие от ребилда с той же структурой. Каждый старый путь должен вести на правильный новый URL без цепочек и коллизий. Риск не в том, что страница отсутствует; риск в том, что редирект слегка неверен — ведёт на страницу категории вместо услуги, или отдаёт 404, потому что новый путь указан с завершающим слешем, а редирект его не нормализует. Ошибка проходит визуальную проверку и обнаруживается только при обходе. ## Как мы это сделали **1. Сборка через шаблоны.** Вместо того чтобы перестраивать 23 URL по одному, мы свели их в 9 переиспользуемых шаблонов и разместили каждую страницу в соответствующем: - **Главная, Контакты, О нас («The Experience»)** — страницы, формирующие бренд - **Страница-лендинг услуг** — несёт три лендинга категорий (Cosmetic, Preventive, Restorative Dentistry) - **Страница услуги** — единый переиспользуемый шаблон для всех 10 страниц услуг: Botox, Dental Crowns, Dental Implants, Emergency Dentistry, Invisalign, Sedation Options, Smile Design, Teeth Whitening, TMJ Treatment, Veneers - **Страница врача** — биография основного стоматолога - **Лендинг блога + Статья** — архив контента и шаблон отдельной записи - **Стандартный шаблон** — 4 страницы ресурсов для пациентов (Forms, Insurance, Financing, Privacy Policy) 9 шаблонов — готовый сайт. Таксономия услуг — косметическая, профилактическая, восстановительная — теперь отражена в структуре URL и доступна через систему шаблонов. **2. Спецификация выполнена строка за строкой, из таблицы агентства.** Агентство передало нам Google Sheets таблицу: каждый URL для миграции с новым путём, каждый мета-заголовок и описание для новых страниц, назначение шаблонов, вкладку Settings с URL сайта и тестовой среды, и контрольный список запуска. Мы реализовали каждую строку как написано. Там, где нужны были новые мета-данные для четырёх вновь созданных страниц (Forms, Insurance, Financing и исправленный редирект со старого пути `/contact`), агентство предоставило текст прямо во вкладке очереди правок SEO, и мы применили его в точности. Принцип прост: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка через обход, а не «на глаз нормально».** Перед переключением DNS мы прогнали Screaming Frog по старому рабочему сайту и тестовой среде ребилда параллельно. Каждый URL из sitemap проверялся на ожидаемый статус-код — 200 на новых страницах, 301 с наследуемых путей. Реструктуризация во вложенные категории означала, что адреса редиректов проверялись не только на статус, но и на точность назначения: редирект с `/services/invisalign` на `/cosmetic-dentistry/invisalign/` не должен уводить на `/cosmetic-dentistry/`. Второй обход после запуска подтвердил, что все внутренние ссылки разрешаются на рабочем домене. **4. Контрольный список запуска на 75 пунктов, закрыт до передачи.** Восемь категорий: статус-коды, редиректы, структура URL, контент, SEO и аналитика, адаптивность, интеграции под клиента (Gravity Forms с маршрутизацией email на `hello@lalumedental.com`, перенос Google Tag Manager, лицензирование шрифтов Adobe Typekit) и миграция DNS на Kinsta. QA на разных устройствах на Chrome / Firefox / Safari / Edge и шести типах экранов (1920 / 1280 / 1024 / iPad / портретный и альбомный мобильный). Работа по спецификации, которая разделяла одну существующую страницу на четыре адреса, означала, что карту редиректов нужно было решить до любой визуальной сборки — порядок задавал всю последовательность. Каждый старый якорный путь (`/the-office#forms`, `#insurance`, `#financing`) требовал подтверждённого адреса назначения до записи редиректа; каждый новый адрес назначения — подтверждённого URL до настройки дерева внутренних ссылок. Реструктуризация диктовала последовательность, а не график. ## Результаты Метрика Результат Точность спецификации — URL перенесены **23 / 23** страницы перенесены из старой структуры URL в новую, как указано Точность спецификации — изменения путей Все редиректы вложенной категориальной реструктуризации реализованы как 301 с наследуемых путей Точность спецификации — шаблоны **9 / 9** шаблонов созданы и применены на всём сайте Контрольный список запуска **75 пунктов** проверены и согласованы перед переключением Сроки **18 дней**, сдано по графику Затраты **66 ч / 66 ч** оценка — без перерасхода, без расширения объёма Проверка адаптивности Ноль проблем вёрстки на 4 браузерах × 6 типах экранов Внутреннее QA Все задачи из очереди агентства закрыты до передачи **Статус сайта** Работает на Kinsta по адресу https://www.lalumedental.com/ Если коротко: спецификация агентства выполнена как написано, в рамках согласованных часов, в запланированный день переключения. ## Контроль качества Внутренняя сверка контента перестроенной страницы /the-experience выявила расхождение в порядке секций относительно оригинала — секции были переупорядочены, а не перестроены по спецификации — и исправлено до передачи; затем финальная проверка агентства обнаружила несоответствие номера телефона, где шапка сайта на большом экране и мобильный аккордеон показывали разные номера — исправлено на всём сайте до переключения. QA перед передачей прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и порога нулевых ошибок. Собственный QA-контур агентства работал после передачи и фиксировал замечания в общую очередь правок для нашего цикла исправлений до их согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день Спецификация агентства изучена; оценка 66 ч согласована Разработка ~14 дней Полный сайт перестроен на 9 шаблонах в тестовой среде Kinsta Внутреннее QA и проверка 2 дня Правки из очередей SEO и CX обработаны; вся работа в рамках агентства закрыта Проверка спецификации 1 день Редиректы реструктуризации URL сверены с таблицей; обход подтверждён Сдача и переключение DNS 1 день Сайт запущен на Kinsta, без простоев _Этапы пересекаются (QA шёл параллельно с поздней разработкой), поэтому календарный срок — 18 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Павел Сажин** — QA и реализация исправлений после запуска - **Анна Полунина** — поддержка разработки и QA по перестроенным страницам - **Тимур Арбаев** — сверка дизайна со сборкой и QA перед передачей - **Людмила Травкина** — QA и координация проверки перед передачей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация со стороной агентства, согласование) Агентство оставалось публичным подрядчиком на всём протяжении; наша команда оставалась невидимой для конечного клиента с начала работ до переключения. Решения по архитектуре URL — какие пути создавать, как настраивать редиректы для старой структуры, какую страницу на сколько адресов разделить — все принадлежали агентству. Мы реализовали эти решения в точности как указано. ## Агентствам, заказывающим ребилд WordPress > Карта редиректов, которая выглядит верной в превью, — главный риск агентства-заказчика. Для одиночной клиники косметической стоматологии, переезжающей с плоского индекса во вложенные каталоги, риск в том, что одна строка выпала из карты соответствий. Для сети из нескольких клиник, объединяющей страницы, риск — цепочка редиректов на уровне домена. Сценарии отказа одни и те же: пропущенная строка роняет ранжированные URL в 404. Мета-заголовки тихо меняются вместе с новой темой. Структурированная разметка пропадает из истории аудита при импорте. Вопрос перед стартом — не «сделаете ли ребилд?», а «как вы перенесёте каждый URL, по которому я ранжируюсь, на его новое место?» Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы пройдём карту редиректов по вашему индексу ранжируемых страниц, отметим каждую цепочку, грозящую мягким 404, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-33-page-dental-tongue-tie-94-days/ title: Доработка темы для стоматологии и уздечки языка: 33 страницы, 94 дня type: case_study date: 2025-01-14T21:02:00+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 33 страницы доработки стоматологического шаблона по постраничным макетам Figma — клиника совмещает общую стоматологию с разделом процедур по уздечке языка, всё на 10-шаблонном наборе агентства на Kinsta. 15 страниц общих стоматологических услуг и 4 подстраницы процедур с разбивкой по возрасту сидят на одном шаблоне Service Page, но наполнение у них разное. Принять раздел процедур за вариант стоматологических услуг — QA это не отловит, а вот после запуска вылезет содержательной проблемой. ## Краткий обзор Поле Значение Отрасль клиента Медицина — общая стоматология со специализацией по уздечке языка / уздечке губы Клиент Charleston Dental and Tongue Tie (стоматологическая клиника в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma на Kinsta) Объём **33 URL** — главная, о клинике, лендинг услуг, **15 страниц общих стоматологических услуг**, **4 страницы процедур по уздечке языка и губы**, биография врача, лендинг блога, контакты и вспомогательные страницы Сроки 94 дня (26 июн – 28 сен 2025), в срок Затраты 57 часов — 24,5 ч разработка · 10 ч QA · 15 ч PM · 7,5 ч контент и правки Команда 5 специалистов Шаблоны **10 готовых шаблонов** от агентства, все применены на 33 страницах Технологии WordPress · Elementor · Kinsta хостинг · Постраничный дизайн из Figma · AutoQA агентства (проверки Links / Email / Content AI) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **120+ отслеженных SEO + CX проблем** согласованы в очереди задач агентства, включая 30-пунктный контрольный список запуска **Ритм работы** 90 задач от агентства · все закрыты к моменту передачи (41 активный день, 2025-07-18 — 2025-08-27) **Раунды проверки** ≈10 раундов **Контрольный список запуска** 30 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макеты Figma для Charleston Dental and Tongue Tie и цель развёртывания на своей брендированной системе шаблонов на Kinsta. Клиника предлагает как общую стоматологическую помощь, так и специализированные процедуры по уздечке языка и уздечке губы — сочетание, которое встречается реже, чем сайт общей стоматологии, и создало двойную структуру контента, которую агентству нужно было корректно отобразить в шаблоне. Работа выше по цепочке оставалась за агентством: дизайн, утверждение клиентом, планирование контента и хостинг. Наша задача — воплотить Figma в их шаблоне. Задача была технически чёткой: Figma — единственный источник истины, каждая страница собирается под неё, сайт возвращается агентству только после того, как все расхождения с дизайном закрыты в общем рабочем пространстве. Помимо основной разработки, в объём входили страница блога, пост о френэктомии, подстраница «Знакомство с врачами» и раунд обновлений контента и изображений, продливший сделку до сентября. Что агентству нужно было предотвратить — структурную проблему, специфичную для набора услуг этой клиники. Раздел специализации по уздечке языка — это не вторая вкладка на лендинге услуг; у него есть собственная посадочная страница и подстраницы по возрастным группам (младенцы, малыши и дети постарше, взрослые), каждая со своим содержанием, отличным от соседних общих стоматологических услуг. Риск при шаблонной разработке в том, что общий шаблон Service Page трактует всё одинаково: разработчик, полагающийся на стандартные настройки шаблона, может создать страницы, которые визуально совпадают с Figma на главной, но незаметно сплющивают иерархию контента раздела процедур до того же шаблона, что и страница чистки зубов. Агентство наняло нас не просто ради результата, а ради того, чтобы это различие не стёрлось. Доработка должна была сохранить структурное различие между общими стоматологическими услугами и разделом процедур — используя тот же набор шаблонов, не стирая содержательного различия между ними. > **Контекст рисков.** Раздел специализации по уздечке языка — это не расширение лендинга стоматологических услуг; у него есть собственная посадочная страница и подстраницы по возрастным группам, каждая со своим назначением и аудиторией. Риск при шаблонной разработке в том, что общий шаблон Service Page сплющивает всё в одинаковую раскладку: разработчик, полагающийся на стандартные настройки шаблона, может создать страницы, которые визуально совпадают с Figma на главной, но незаметно сводят иерархию контента раздела процедур к тому же шаблону, что и страница чистки зубов. Такое структурное схлопывание не проявилось бы как сбой QA; оно проявилось бы как содержательная проблема после запуска. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Figma была источником истины на всём протяжении. Брендированный шаблон был холстом. Для каждой из 33 страниц вопрос был один: соответствует ли данный фрейм Figma стандартным настройкам шаблона или требует постраничной доработки? Там, где шаблон подходил, мы его оставляли. Там, где Figma требовала отклонения, мы дорабатывали — включая посадочную страницу процедур по уздечке языка, которая структурно находится между лендингом услуг и страницей услуги и требовала собственной обработки в рамках параметров шаблона Service Page. **2. Два раздела услуг, один набор шаблонов.** На сайте 15 страниц общих стоматологических услуг и рядом 4 страницы процедур по уздечке языка и губы. Все 19 стоят на шаблоне Service Page. Удержать их различие — задача редакционная и структурная: общие стоматологические страницы идут по стандартной схеме сервисных страниц агентства; у страниц процедур есть подстраницы по возрастным группам (младенцы, малыши и дети постарше, взрослые) с блоками контента и якорной навигацией — тот же шаблон, другая контентная форма. Раздел процедур пришлось вести не как вариант стоматологических услуг, а как отдельную контентную архитектуру поверх общего слоя шаблона. **3. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрал один раз, проверил один раз». Проект накопил более 120 позиций в рабочем пространстве очереди задач агентства — отдельные раунды QA, в которых агентство отмечало расхождения с дизайном, мы проверяли, исправляли и возвращали сборку. Примечательное в этом цикле: обработка Hero-секций (все Hero-секции в Figma отображаются как чёрно-белые градиентные наложения; стандартные настройки шаблона не совпадали; исправлением стал CSS-подход с наложением градиента), исправление маршрутизации якорных ссылок в разделе отзывов на главной (ссылка требовала полного абсолютного URL с путём страницы и якорем, а не просто фрагмента) и итеративные проходы по размерам изображений в рамках задачи команды по контенту и изображениям. Каждый проход добавлял точности; ни один не откатывал предыдущую работу. **4. Доработка без дрейфа.** Каждое изменение мы держали в пределах реализации для конкретного клиента. Общие компоненты шаблонов агентства не трогали ни разу. Адаптации раздела процедур по уздечке языка жили в постраничных переопределениях Elementor, а не в общем слое шаблона. Следующий сайт, работающий на этом шаблоне, не будет знать, что через него прошли 33 страницы индивидуальной реализации. **5. Проверка на разных устройствах.** Доработки проверяли на большом экране, планшете и мобильных. Работа по размерам изображений и наложению градиента из цикла QA по своей природе охватывает все типы экранов — каждое изменение раскладки запускало повторную проверку на разных устройствах перед закрытием раунда. QA-проход финальной задачи по обновлению контента включал проверку изменений контента на всём сайте, охватившую все затронутые страницы перед передачей. Постоянным ограничением в ходе QA было отсутствие у клиники профессиональных портретов команды — блок команды на главной и страница «Знакомство с командой» были построены без оригинальных фотографий, с заглушками-силуэтами, пока агентство не найдёт снимки или не решит совсем убрать фото команды из этих разделов. Постраничные переопределения Elementor — а не правки в слое шаблона — были выбраны сознательно: тронь общий шаблон, и доработки под уздечку языка — навигация по возрастным группам, процедурные блоки контента — окажутся в каждом следующем сайте агентства на той же базе. Следующий клиент это не заказывал. Суть напряжения простая: раздел процедур по уздечке языка — не расширение стоматологических услуг. Его подстраницы по возрастным группам несут другое содержательное назначение. Свалить их в ту же схему — не ошибка QA, а проблема после запуска. Решение: отдельная контентная архитектура внутри того же шаблона, переопределения Elementor на уровне страниц — общий слой агентства не тронут. ## Контроль качества Перед сдачей QA выявило две проблемы: каждая Hero-секция требовала CSS-исправления с наложением градиента для соответствия чёрно-белой обработке в Figma — стандартные настройки шаблона не применяли наложение цветового режима; а якорь отзывов на главной изначально был задан как простой фрагмент (`#reviews`), тогда как правильная форма требовала полного абсолютного URL с путём страницы — обнаружено до того, как агентство приступило к проверке сборки. QA перед сдачей проходило через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Свой проверочный контур агентства проходил после передачи и фиксировал замечания в очередь задач для нашего цикла исправлений до момента их подписи. Доработки остались в переопределениях для конкретного клиента; общие компоненты шаблонов агентства не изменялись. ## Результаты Метрика Результат URL сдано **33** — 1 главная, 1 лендинг услуг, 1 лендинг процедур по уздечке языка, 15 страниц общих стоматологических услуг, 4 подстраницы процедур по уздечке языка, 1 биография врача, 1 о клинике, 1 лендинг блога, 1 пост блога, 1 контакты и вспомогательные страницы Шаблонов применено **10 из 10** готовых шаблонов построены и сопоставлены по 33 страницам Контрольный список запуска **30 пунктов** согласованы QA / SEO проблем отслежено и решено **120+** позиций согласованы по двум вкладкам очереди задач агентства (SEO и CX) Итераций QA в Redmine **2 выделенных задачи QA** плюс множественные раунды исправлений в очереди задач разработки Сроки **94 дня**, сдано в срок Затраты **57 часов** — разработка, QA, управление проектом и контентные раунды Команда **5 специалистов** Передача хостинга Запущен в шаблонном окружении агентства на Kinsta Здоровье страниц при передаче **33 / 33** URL тестовой среды вернули HTTP 200 в аудите карты сайта Если коротко: Figma агентства была реализована на их брендированном шаблоне на 33 страницах и 10 шаблонах — включая специализированный раздел процедур, потребовавший структурного различения внутри общего шаблона — за 94 календарных дня, в рамках оценки в 57 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к шаблону подтверждён, объём согласован в 24,5 ч ядра Доработка ~1 неделя Постраничная доработка шаблона для соответствия Figma, включая архитектуру раздела процедур по уздечке языка Итерации QA (параллельно) ~6 недель Более 120 позиций в очереди задач; каждый раунд закрывался только после согласования с агентством Контент и изображения ~3 недели Страница блога, пост блога, подбор изображений, проход по точности контента Правки после запуска ~1 неделя Обновление контактных данных, финальное согласование контента _Разработка и QA шли параллельно — это характерно для доработки темы, где «фаза QA» не закрывается чисто; цикл работает непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы, сопоставление Figma с шаблоном, контентные раунды) - **Анна Полунина** — координация проекта (управление контентом, продвижение задач, связь с агентством) - **Павел Сажин** — итерации QA и исправления - **Тимур Арбаев** — поддержка QA и финальный проход по контактным данным - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне агентства-партнёра на всём протяжении. Наша команда работала как невидимый партнёр по разработке агентства. Все запросы на доработку поступали через рабочее пространство агентства; конечный клиент напрямую с нами не взаимодействовал. Каждый раунд QA закрывался только после подтверждения проверяющего со стороны агентства, что расхождение устранено. ## Агентствам с библиотекой шаблонов > На шаблонном стоматологическом сайте общая раскладка страниц исходит из того, что любая услуга влезает в один и тот же контейнер. Здесь это был стоматолог одной локации, добавивший специализированную процедуру; у вас может быть многофилиальная сеть с разными каталогами на одном бренд-шаблоне. Тихие отказы: доработки в дочерней теме слетают на следующем обновлении поставщика, схемы полей расходятся с эталоном, права редактора ломаются для сотрудников без навыков разработки. И каждый — отдельная заявка, которую разгребает агентство. Спрашивать подрядчика стоит не «сможете расширить шаблон?», а «как вы пропишете переопределения, чтобы схемы пережили обновления и редактор у клиента работал?» Пришлите исходник шаблона или его ID и спецификацию бренда. Мы сверим схемы полей с вашими страницами, найдём, где переопределения конфликтуют с поставщиком и где ломаются права редактора, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-dental-website-redesign-elementor-60h/ title: Редизайн сайта стоматологии — многостраничный, из Adobe XD в Elementor Pro type: case_study date: 2025-01-11T04:51:15+00:00 case_industry: Здравоохранение case_type: Редизайн case_practice: wordpress --- ## Подход к редизайну Редизайн стоматологической клиники, который начинался как одна задача на главную страницу — 2 файла Adobe XD, 1 для главной, второй для дополнительных страниц, — и вырос до 15 страниц и 12 последующих задач за 4 месяца. Дополнения поступали по одному: галерея результатов, тексты страниц услуг из папки Google Drive, обновления H1 и мета-тегов из вкладки таблицы. Мы вели все 16 задач как один непрерывный проект, а не как набор разрозненных запросов. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая стоматология Конечный клиент Club K Dental (стоматологическая клиника, Missouri) **Формат сотрудничества** **White-label редизайн сайта стоматологии для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Многостраничный редизайн из Adobe XD в Elementor Pro Объём **~15+ страниц** — главная, о нас, блог, контакты, страница врача, финансирование, лендинг услуг, отдельные страницы услуг, ваш первый визит, стоматологические технологии, новый пациент, галерея результатов, ресурсы для пациентов, а также последующие добавления контента Сроки Основная разработка: ~25 дней (1–26 апреля 2025); полный проект с дополнениями: ~124 дня (апрель – август 2025) Затраты **~60 часов** — разработка, QA и добавления контента после запуска по 16 задачам Команда 3 специалиста (ведущий разработчик + QA + руководитель проекта) Передача дизайна Макеты Adobe XD (собственность агентства; URL не раскрыты — интеллектуальная собственность агентства) Стек технологий WordPress · Elementor Pro · WP Engine · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Режим разработки** **В соответствии с дизайном** — каждая страница строилась по референсу Adobe XD; контент на страницу предоставлялся агентством **Сдано** **Полный редизайн сайта стоматологической клиники, запущен на clubkdental.com — главная, страницы услуг, галерея результатов и постоянные правки клиента по 16 задачам** **Раунды проверки** ≈9 раундов проверки за 25 календарных дней ## Постановка задачи Маркетинговое агентство из США, ведущее стоматологического клиента в Missouri, нуждалось в редизайне существующего сайта на WordPress в соответствии с новым брифом Adobe XD. Бриф охватывал главную страницу и полный набор вспомогательных страниц: о нас с биографией врача, лендинг блога, контакты, страницу финансирования, лендинг стоматологических услуг с отдельными подстраницами, страницу первого визита, страницу стоматологических технологий, страницу нового пациента и раздел ресурсов для пациентов. Агентство также планировало галерею результатов с фотографиями «до и после» лечения. Тестовая среда уже была развёрнута на WP Engine. Наша задача — построить каждую страницу в Elementor Pro по утверждённым макетам Adobe XD, интегрировать контент, предоставленный агентством через Google Docs, и сохранять единообразие по мере расширения объёма дополнениями после запуска. Задача была краткой: соответствовать дизайну на каждой странице, оставаться вне контура коммуникации с конечным клиентом и рассматривать каждый новый запрос как часть того же проекта, а не как отдельную задачу. > **Контекст рисков.** Редизайн, который начинается как задача на одну страницу и незаметно вбирает в себя полный объём работ по всему сайту, несёт специфический риск: не в том, что какая-то 1 страница не удастся, а в том, что пятнадцатая страница отклонится от дизайн-языка первой. Когда агентство заказывает «главную страницу», а задача превращается в многостраничное обновление дизайна, разработчик, рассматривающий каждую новую страницу как отдельную задачу, рискует получить разнобой в отступах, типографике и размещении CTA по всему сайту. Защищает 1: вести проект как единое целое — та же команда, тот же исходный файл, одна и та же проверка на каждой задаче, будь то главная страница или добавление контента по профилактической стоматологии 3 месяца спустя. ## Как мы это сделали **1. Из Adobe XD в Elementor Pro, страница за страницей.** Главную и каждую вспомогательную страницу построили в Elementor Pro по утверждённым макетам Adobe XD. Наталия Богатель вела основную разработку, последовательно работая над главной, страницей о нас, лендингом услуг, контактами и страницей финансирования. Никита Тумашевич занимался дополнительными страницами — отдельными страницами услуг, галереей результатов с фотографиями «до и после» и добавлениями контента после запуска из папок Google Drive агентства. Поскольку Elementor Pro уже был установлен на тестовом сайте WP Engine, разработка вписалась в существующую инфраструктуру без внедрения новых зависимостей. **2. Интеграция контента по документам агентства.** Агентство предоставляло контент для страниц в Google Docs и Google Sheets — по одному документу на тип страницы, с текстами, заголовками и структурой CTA. Текст переносили в нужные блоки Elementor по дизайну. Больше всего внимания потребовали отдельные страницы услуг — каждая несла свой процедурный текст (удаление амальгамы, озонотерапия, CEREC-коронки за один день, цельнокерамические импланты, чистка без фтора), который нужно было единообразно отформатировать в рамках одного шаблона страницы услуги. Агентство предоставило контент не сразу — тексты отдельных страниц услуг поступали в разных документах и загрузках папок через последовательные задачи Redmine, что потребовало нескольких проходов интеграции, а не однократного внесения. **3. Добавления контента после запуска в рамках того же проекта.** После сдачи основной главной и вспомогательных страниц в конце апреля агентство продолжало запрашивать дополнения: недостающие блоки контента, галерею результатов с десятью фотографиями «до и после», контент страниц услуг из общей папки, обновления H1 и мета-описаний из вкладки Google Sheets, правки клиента и корректировки sitemap XML. Вместо открытия нового проекта каждый запрос отслеживался как последующая задача в том же проекте Redmine — 12 дополнительных задач сверх изначальных четырёх, — что обеспечивало перенос контекста того же разработчика и QA. **4. Раунды QA перед каждой передачей.** Внутреннее QA проводил Павел Сажин по каждой задаче перед её переходом в статус «Sent, awaiting response». Охват проверки расширялся по мере роста сайта: ранние задачи фокусировались на соответствии главной страницы Adobe XD, тогда как поздние проверяли, что новый контент страниц услуг соответствует существующему шаблону, галерея результатов корректно отображается на разных устройствах и изменения sitemap XML не ломают рабочий индекс. 16 задач за 124 дня, каждая проходившая через одну и ту же контрольную точку проверки: «На тест», затем проверка Павел, затем «Проверено, на отправку» перед передачей агентству. Именно этот порядок сохранил пятнадцатую страницу в едином стиле с первой: тот же референсный файл, тот же объём проверки, будь то разработка главной в апреле или добавление контента по профилактической стоматологии в августе. ## Контроль качества На этой тестовой сборке QA проводилось по каждой задаче перед её переходом в «Sent, awaiting response» — две основные задачи (#444 главная, #445 дополнительные страницы) прошли через явную контрольную точку проверки QA, причём структура URL и маршрутизация постоянных ссылок для подстраниц `/dental-services/` были проверены по карте сайта агентства до закрытия этих задач 26 апреля. QA перед передачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) с описанием категорий и принципа нулевых ошибок. Собственный QA агентства проводился после передачи и фиксировал замечания в очередь задач для нашего цикла исправлений до окончательного согласования. ## Результаты Метрика Результат Редизайн сайта Выполнен — Adobe XD применён в Elementor Pro на главной и всех вспомогательных страницах Режим разработки **В соответствии с дизайном** — ни одного визуального решения за пределами брифа; отклонения согласовывались с агентством до реализации Сдано страниц **~15+ страниц** — главная, о нас, блог, контакты, страница врача, финансирование, лендинг услуг, отдельные страницы услуг, первый визит, стоматологические технологии, новый пациент, галерея результатов, ресурсы для пациентов, а также последующие дополнения Дополнения после запуска Галерея результатов с фотографиями «до и после», контент страниц услуг из папок агентства, обновления H1/тайтлов/мета, правки клиента, корректировки sitemap XML Раунды QA Внутреннее QA Павел Сажин по каждой задаче перед передачей Сроки Основная разработка: **~25 дней** (1–26 апреля 2025); полный проект: **~124 дня** (апрель – август 2025) Затраты **~60 часов** — распределены между реализацией дизайна, интеграцией контента, QA и дополнениями после запуска Команда 3 специалиста — без отдельного аналитика, без дизайн-лида (на стороне агентства), без SEO-лида (миграции не было) Статус сайта, проверено 2025-06 [clubkdental.com](https://clubkdental.com/) работает, возвращает HTTP 200 Результат кратко: бриф Adobe XD агентства был применён ко всем типам страниц стоматологического сайта, галерея результатов построена и наполнена, все добавления контента после запуска интегрированы, сайт работает и отвечает по подтверждённому URL. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Adobe XD изучен, состав страниц подтверждён, Elementor Pro и WP Engine тестовая среда проверены Основная разработка ~3 недели Главная и все вспомогательные страницы построены по Adobe XD; постраничный контент внесён по документам агентства Внутреннее QA и передача ~1 неделя QA-проход Павел Сажин по всем основным страницам; задачи зафиксированы и решены до передачи агентству Дополнения после запуска ~3 месяца Галерея результатов, контент страниц услуг, обновления мета, правки клиента, корректировки sitemap — отслеживались как последующие задачи в рамках того же проекта _Этапы перекрываются — дополнения после запуска начались, пока основное QA ещё закрывалось, и проект вёлся как единый непрерывный процесс, а не дискретная передача с перезапуском. Календарь в 124 дня отражает полный период от открытия первой задачи до закрытия последней._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (главная и основные страницы, разработка в Elementor Pro, добавления контента после запуска) - **Никита Тумашевич** — дополнительные страницы и контент услуг (отдельные страницы услуг, галерея результатов, контент из папок агентства) - **Павел Сажин** — QA и координация проекта (внутренние QA-раунды по каждой задаче, коммуникация с агентством, отслеживание задач) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, согласование с агентством, координация по 16 задачам) Управление проектом со стороны агентства, дизайн и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента. Все дизайн-решения принимались агентством; наша роль — точность воспроизведения дизайна на каждой странице и единообразная обработка каждого последующего дополнения. ## Агентствам, заказывающим редизайн WordPress > Редизайн сайта стоматологической практики несёт риск не на главной странице — он накапливается к пятнадцатой. У этой практики — премиальная эстетическая стоматология; у других — сетевая DSO-практика со страховыми отчётами. Риски тихие: дизайн-язык главной не доходит до карточки имплантологии, типографика раздела профилактики расходится с визуалом хирургии, CTA-блоки на страницах услуг живут без общего каскада правок. Поэтому подрядчику стоит задавать не вопрос «сделаете ли редизайн главной страницы», а вопрос «как именно вы удержите визуальный порядок на всём сайте — от профилактики до ортодонтии». Пришлите макеты или текущий перечень URL. Мы сверим новый визуал с текущей информационной архитектурой, отметим страницы, где дизайн-язык рискует сломаться на контенте, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-37-page-pediatric-dental-50-days/ title: Доработка детского стоматологического шаблона: 37 страниц за 50 дней type: case_study date: 2025-01-05T12:26:42+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 37 URL доработки детского стоматологического шаблона — главная, 5 страниц услуг для Chastain, двуязычная версия на испанском и 4 вспомогательные страницы, свёрстанные по текстовому макету Figma, — собраны на 16 шаблонах агентства за 27 часов. Макет Figma принадлежал агентству; мы держали каждый повторно используемый шаблон страницы услуг точным для каждого филиала и языковой версии и готовили текстовый макет для вспомогательных страниц, которые существующий набор шаблонов не покрывал. ## Краткий обзор Параметр Значение Отрасль конечного клиента Здравоохранение — детская стоматология Конечный клиент Children’s Dentistry of Georgia (Chastain, GA) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса в сфере здравоохранения** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн Figma на Kinsta) Объём **37 URL** — главная, страница услуг, 20+ страниц услуг (детская стоматология, профилактика, восстановление, седация, неотложная помощь, по районам), about, биография врача, контакты, блог (лента + пост), страницы оплаты и страховки, испаноязычная страница, юридические страницы Сроки 50 дней (10 ноя – 30 дек 2025), по графику Трудоёмкость 27 часов — разбиты на разработку шаблонов, итерации QA, правки и управление проектом Команда 4 специалиста Шаблоны **16 повторно используемых шаблонов**, предоставленных агентством, применены на всех 37 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · Yoast SEO · Gravity Forms · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Подход к QA** **235 + 236 строк** в журналах SEO и CX агентства; 78 пунктов в контрольном списке запуска **Ритм взаимодействия** 3 задачи от агентства · 2 из 3 закрыты к моменту передачи **Раунды проверки** ≈4 раунда проверки за 50 календарных дней **Контрольный список запуска** 78 пунктов, согласован перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Children’s Dentistry of Georgia и цель развёртывания на своей фирменной системе шаблонов под Kinsta. Агентство уже выполнило подготовительную работу: карта сайта с описанием контента по страницам, бренд-материалы, контакты и учётные записи, ссылки на социальные профили клиента. Мы дорабатывали шаблон страница за страницей под Figma, пока агентство не подтверждало каждый раунд. Клиника — детский стоматологический сайт одного врача: один доктор, без ортодонтического направления, но со структурой из нескольких филиалов, что необычно для компактного проекта. В карте сайта из Google Sheets указаны страницы для двух основных филиалов (Chastain и Kennesaw), трёх районных страниц услуг (Buckhead, Sandy Springs, North Buckhead) и испаноязычная страница. Все они используют один и тот же шаблон страницы услуг. При проекте на 27 часов риск — не визуальное расхождение, а языковой контент и адресные данные филиала, которые могут утечь между однотипными страницами шаблона. Адрес Chastain или английский CTA, попавшие на испанскую страницу, — это скрытая ошибка, которую не выявит проверка точек адаптации. Агентство наняло нас, чтобы предотвратить это. Дополнительным ограничением стало то, что несколько вспомогательных страниц — способы оплаты, политика конфиденциальности, условия обслуживания — требовали макета, которого не было в существующем наборе шаблонов, а на вкладке Content в Google Sheets для большинства страниц были пустые строки с текстом, поэтому контент приходилось получать отдельно из редакционного процесса агентства, а не из единого документа. > **Контекст рисков.** 20 с лишним страниц, использующих 1 шаблон страницы услуг — для 2 основных филиалов, 3 районных URL и испаноязычной версии, — превращают преимущество повторного использования шаблона в риск утечки. Адрес Chastain, попавший на страницу Kennesaw, или английский CTA на испанской странице — это скрытая ошибка: она проходит визуальную проверку, проходит проверку ссылок и обнаруживается только когда родитель или пациент читает неверный контент. В компактном проекте на 27 часов именно отслеживание того, какие элементы локальны для страницы, а какие глобальны для шаблона, на каждой из этих страниц и отделяет чистую сборку от проблем с точностью контента. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страниц. Наша задача заключалась в постраничном согласовании двух: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны. Для детского сайта, который должен выглядеть тёплым и вызывать доверие у родителей, это правило «без импровизаций» держало каждую страницу честной. **2. Несколько филиалов и языков на повторно используемом шаблоне.** Шаблон страницы услуг применили более чем на 20 страницах — страницы филиала Chastain, страницы филиала Kennesaw, районные страницы и испаноязычная страница. Каждая требовала своего названия филиала, контекста услуги и языкового регистра. Отслеживание того, какие элементы локальны для страницы, а какие глобальны для шаблона, было основной работой в каждой итерации доработки. Таблица Google Sheets агентства прямо указывала на необходимость дополнительного текстового шаблона для вспомогательных страниц (способы оплаты, политика конфиденциальности, услуги, условия), который мы подготовили, не затрагивая общие компоненты шаблона. Мы выбрали минимальный текстовый макет для этих страниц вместо адаптации шаблона страницы услуг, потому что навязывание многосекционного дизайна страницам без структурированного контента добавило бы ненужной сложности и увеличило риск визуальной несостыковки со стандартным поведением системы шаблонов при последующих сборках. **3. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 9 задач, отслеженных в этом проекте, **7 были названы итерациями QA** — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы просматривали, исправляли и возвращали сборку на очередную проверку. Даже в компактном проекте на 27 часов плотность цикла была высокой: агентство отслеживало элементы в двух журналах задач (SEO и CX), которые мы прорабатывали параллельно с ритмом Redmine. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без расхождения.** Каждое изменение в фирменном шаблоне — будь то макет страницы, компонент секции или токен стиля — мы документировали относительно Figma. Ни одна доработка не просочилась в общие компоненты шаблона, поэтому работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями текущего раунда, а не весь сайт, — так доработка темы идёт без лишних затрат и без потери покрытия. Отслеживание того, какие элементы локальны для страницы, а какие глобальны для шаблона, на более чем 20 страницах 1 шаблона услуг — именно это и дало точность сборки. Агентство само это подтвердило: их рецензент обнаружил неверное имя врача в подвале страницы — именно так выглядит утечка контента через шаблон, она не видна до тех пор, пока кто-то не прочитает чужие данные на своей странице. ## Контроль качества QA на протяжении 7 итерационных раундов выявлял проблемы на уровне шаблона до каждого согласования с агентством — сборка проходила структурированный цикл проверки на каждом из 37 URL, и каждый раунд закрывался только после подтверждения агентством, что расхождение устранено. QA перед сдачей проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) для категорий и порога нулевых ошибок. Внутренний контур проверки агентства работал после передачи и заносил замечания в общую очередь правок для нашего цикла исправлений, пока агентство не согласовывало результат. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL доставлено **37** — 1 главная, 1 страница услуг, 20+ страниц услуг (детская стоматология по Chastain, Kennesaw и районам), 1 биография врача, 1 about, 1 контакты, 1 лента блога, 1 пост блога, 2 страницы оплаты/страховки, 1 испаноязычная страница, 3 юридические страницы Применено шаблонов **16 из 16** повторно используемых шаблонов созданы и сопоставлены на 37 страницах Контрольный список запуска **78 пунктов** Отслежено строк QA / SEO / CX **235 + 236** строк в двух журналах задач агентства Итераций QA в Redmine **7 из 9 задач (78%)** отслежены на уровне итераций Сроки **50 дней**, доставлено по графику Трудоёмкость **27 часов** — без перерасхода, без расширения объёма Команда **4 специалиста** Передача хостинга Работает в среде шаблонов Kinsta агентства, затем перенесён на рабочий домен клиента Статус рабочего сайта Сайт работает на childrensdentistryofga.com — подтверждён 200 OK на момент написания кейса Если коротко: мы собрали Figma агентства на их фирменном шаблоне — 37 сопоставленных URL, 16 шаблонов, 50 календарных дней, в рамках оценки в 27 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma просмотрен, доступ к шаблону подтверждён, объём согласован (10–13 ноя) Разработка доработки ~1 неделя Постраничная доработка шаблона под Figma; созданы начальные страницы Итерации QA (параллельно) ~4 недели 7 отдельных раундов QA; каждый закрыт только после согласования с агентством Раунды правок ~2 недели Коррекции после проверки, включая выравнивание слайдера логотипов и обновления страниц Закрытие после релиза ~1 неделя Финальная сверка журнала, выставление счёта и оплата (30 дек) _Разработка и QA выполнялись параллельно — это характерно для доработки темы, где «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования с агентством._ ## Команда **Команда проекта** - **Наталия Богатель** — разработчик (доработка шаблона и исправление компонентов) - **Павел Сажин** — итерации QA и раунды согласования - **Тимур Арбаев** — поддержка разработчика на раундах доработки и правках QA - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Партнёрское агентство управляло проектом, владело дизайном, отвечало за контент и поддерживало отношения с конечным клиентом от начала до конца. Children’s Dentistry of Georgia с нашей командой напрямую не работала — сборка проходила через общий журнал задач агентства, и каждый раунд переходил к следующему только после согласования их рецензентом. ## Агентствам с библиотекой шаблонов > 1 шаблон страницы услуг на несколько филиалов и языковых версий легко превращается в источник перепутанного контента. У этой клиники — общий каркас с локальным наполнением; у других — отдельная вёрстка каждой страницы. Стоит ослабить контроль — и кнопка остаётся на языке оригинала, а адрес одного филиала всплывает на странице другого. Подрядчику стоит задавать не вопрос «сможете ли переиспользовать шаблон», а вопрос «как именно вы изолируете контент каждого филиала и языковой версии друг от друга». Пришлите исходник шаблона или его ID и спецификацию бренда. Мы проверим, как контентный слой каждого филиала отделён от других в шаблоне, и без оплаты вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-multi-location-361-urls-24-days/ title: Ребилд WordPress для стоматологии с двумя филиалами на 361 страницу type: case_study date: 2025-01-04T00:54:44+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 361 страница ребилда стоматологического сайта с несколькими филиалами на Elementor Pro — два филиала, 14 переиспользуемых шаблонов и спецификация миграции со 117 редиректами, сданная по 74-пунктному контрольному списку за 24 дня. Агентство отвечало за карту URL и таблицу редиректов; мы — за постраничную реализацию и проверку обходом перед переключением. ## Краткий обзор Поле Значение Индустрия конечного клиента Стоматология — общая, косметическая и восстановительная Конечный клиент Smile Craft Dental (Redwood City, CA · Sunnyvale, CA) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress с Elementor Pro на Kinsta Объём Полный ребилд сайта по двум филиалам — 361 URL, 7 биографий врачей, услуги, блог, ресурсы для пациентов, smile gallery Сроки 24 дня (1–25 сен 2025) Трудозатраты ~125 часов по спецификации таблицы Google Sheets агентства Команда 6 специалистов (ведущий разработчик · 3 QA · PM) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) Проверка контентного паритета Разница оригинал-ребилд устранена до сдачи — отсутствующий контент, битые внутренние ссылки, структурный дрейф исключены **Сдано** **Спецификация выполнена строка за строкой — 117 редиректов, 361 URL перенесён, 14 шаблонов, 74-пунктный контрольный список запуска** Постоянное сотрудничество Раунды исправлений после релиза и мониторинг плагина обратной связи за окт–дек 2025 — выполнено дополнительными спринтами в рамках тех же отношений с агентством **Ритм работы** 34 задачи от агентства — все закрыты к моменту сдачи (активный период 29 дней, 2025-09-26 – 2025-10-24) **Раунды проверки** ≈8 раундов проверки за 24 календарных дня **Контрольный список запуска** 74 пункта, согласован до переключения ## Постановка задачи У агентства был постоянный стоматологический клиент — Smile Craft Dental, практика с двумя филиалами в Redwood City и Sunnyvale, CA — чей существующий сайт нуждался в ребилде на WordPress на Kinsta. Агентство выполнило стратегическую работу: таблица Google Sheets с картой каждого URL для миграции, каждым мета-заголовком и описанием для сохранения, полным списком шаблонов и 74-пунктным контрольным списком запуска, охватывающим проверку до и после релиза. Задача была конкретной. Принять спецификацию как данность; восстановить сайт на Elementor Pro; вернуть готовым к переключению. Остаться вне клиентского контура. Реализовать SEO-решения как написано. Одно структурное решение сделало этот ребилд более требовательным, чем миграция с сохранением структуры: практика ведёт два филиала, каждый со своим поддеревом страниц услуг. Таблица Google Sheets содержала отдельные пути URL для Redwood City и Sunnyvale по адресам `/redwood-city/` и `/sunnyvale/`, со 117 редиректами со старой структуры URL на новую. Кроме того, практика указывает семь врачей, каждому из которых требовалась отдельная страница биографии. Спецификация охватывала каждое изменение пути и каждое назначение шаблона. Наша задача была реализовать каждую строку точно как написано. > **Контекст рисков.** Ребилд с 361 URL по двум филиалам и семи врачам — уже не миграция, а сведение нескольких витрин местного поиска в одну. Риск не в одном пропущенном редиректе, а в системной неверной маршрутизации страниц услуг по филиалам или в шаблоне биографии врача, который не масштабируется на семь специалистов. Каждый филиал имеет свою таксономию услуг, свои контактные данные, свою маршрутизацию локального телефона. Редирект, ведущий на лендинг не того филиала, или страница врача, наследующая номер телефона не того города, проходит визуальную проверку и даёт сбой только когда пациент звонит не в тот офис. ## Как мы это сделали **1. Шаблонно-ориентированная разработка.** Вместо восстановления 361 страницы по одной — что размножило бы возможные ошибки на два филиала с отдельными поддеревьями услуг — мы свели их в 14 переиспользуемых шаблонов и разместили каждую страницу внутри них: - **Homepage, Contact Us, About Us, Office Tour** — брендообразующие страницы - **Services Lander** — отдаёт страницы категорий услуг по филиалам для Redwood City и Sunnyvale - **Service Page** — один переиспользуемый шаблон для всех страниц услуг по обоим филиалам (косметическая стоматология, восстановительная, общая, неотложная, ортодонтия, детская стоматология и др.) - **Doctor Page** — применён ко всем семи биографиям врачей (Amy Nguyen DDS, J Janice Chou DDS, Gregory Ding DDS, Rita Huang DDS, Nazak Noorian DDS, Nehal Shah DMD, Victoria Goh DDS) - **Blog Lander + Blog** — архив контента и шаблон отдельных постов - **Smile Gallery** — фотогалерея практики «до/после» - **Patient Resources** — Финансирование, Страховка, План оплаты / Членство, Платёжная политика - **Default Template** — политика конфиденциальности, карта сайта и запасные страницы 14 шаблонов, весь сайт сдан. Будущие правки со стороны агентства живут в одном месте на тип страницы. **2. Спецификация выполнена строка за строкой, из таблицы агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции с целевым путём, каждый мета-заголовок и описание для переноса, каждый шаблон, каждая клиентская интеграция (Google Analytics, Gravity Forms с email-маршрутизацией на `info@mysmilecraft.com`, конфигурация Yoast SEO). Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где не было — мы сообщили агентству. Никаких «творческих интерпретаций» мы не применяли. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка на основе обхода, а не «на глаз нормально».** Перед переключением DNS мы запустили Screaming Frog на старом сайте и тестовой среде ребилда параллельно. Коды статусов, битые ссылки, цепочки редиректов, различия мета-тегов — каждое расхождение сверяли со спецификацией агентства. 117 редиректов из вкладки редиректов таблицы Google Sheets мы проверили адрес за адресом: старый путь `/redwood-city-ca/cosmetic-dental-services/` должен был вести на `/redwood-city/cosmetic-dentistry/`, а не на эквивалент в Sunnyvale. Второй обход после запуска подтвердил, что каждая внутренняя ссылка разрешается на рабочем домене. **4. 74-пунктный контрольный список запуска, закрытый до сдачи.** 8 категорий: коды статусов, редиректы, структура URL, контент, SEO и аналитика, адаптивность, клиентские интеграции и домен и DNS миграция на Kinsta. QA на разных устройствах на Chrome / Firefox / Safari / Edge и шести типах экранов (1920 / 1280 / 1024 / iPad / мобильная портретная / мобильная альбомная). 8 раундов проверки за 24 дня, каждый возвращал агентству согласованный URL тестовой среды без сюрпризов при публикации. Пораундный порядок — шаблоны зафиксированы первыми, редиректы проверены обходом, пункты контрольного списка очищены перед следующей партией — означал, что к восьмому раунду не осталось открытых структурных проблем, только детали контента, которые агентство уже занесло в очередь правок. ## Результаты Метрика Результат Точность спецификации — URL **361 / 361** страниц перенесены из старой структуры URL в новую, как указано Точность спецификации — редиректы **117 / 117** редиректов реализованы, как указано Точность спецификации — шаблоны **14 / 14** шаблонов построены и применены на всём сайте Контрольный список запуска **74 / 74** пункта проверены и утверждены до переключения Сроки **24 дня**, от старта работ до сдачи Трудозатраты **~125 часов** по спецификации таблицы Google Sheets агентства Адаптивная проверка Ноль проблем с макетом на 4 браузерах × 6 типах экранов Внутреннее QA Все задачи в рамках агентства решены до сдачи **Статус сайта** Работает на Kinsta по адресу https://www.mysmilecraft.com/. Постоянное сотрудничество Раунды доработки после релиза окт–дек 2025 — изменения URL по SEO, проверка очереди задач, исправления после выхода в работу, мониторинг плагина обратной связи — каждый выполнен дополнительными спринтами в рамках тех же отношений с агентством Если коротко: спецификация агентства была реализована как написано, в рамках указанных часов, в день переключения. Хвост сотрудничества на следующие 3 месяца подтверждает, что сборка держала форму под вниманием после релиза. ## Контроль качества QA-проход на тестовой среде запустил Site Checker — который выявил битые телефонные ссылки на страницах филиалов, обнаружил отсутствующий URL при обходе и отсутствующие H1-теги на `/office-tour/` и нескольких страницах стоматологических услуг — каждое замечание зафиксировано в общую очередь задач и решено до отправки сборки. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) для категорий и порога нулевых ошибок. Свой контроль на стороне агентства работал после сдачи и выводил замечания в общую очередь правок для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день Спецификация агентства проверена; ~125 ч указано в таблице Google Sheets и согласовано Разработка ~18 дней Полный сайт восстановлен на 14 шаблонах на тестовой среде Kinsta Внутреннее QA и проверка 3 дня Задачи решены; все работы в рамках агентства завершены Проверка спецификации 1 день Мета-данные и редиректы сверены с таблицей; обход подтверждён Сдача и переключение DNS 1 день Сайт работает на Kinsta, без простоев _Этапы накладываются (QA выполнялось параллельно с поздней разработкой), поэтому календарный срок 24 дня, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полный ребилд сайта и система шаблонов) - **Павел Сажин** — QA и реализация исправлений - **Анна Полунина** — поддержка реализации и QA по восстановленным страницам - **Тимур Арбаев** — QA и раунды исправлений после релиза - **Людмила Травкина** — QA, переход в работу и мониторинг плагина обратной связи - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, общение со стороной агентства, согласование) Агентство оставалось публичным подрядчиком на всём протяжении; конечный клиент нас не видел от старта до переключения. Решения по архитектуре URL — какие пути создать, как настраивать редиректы со старой структуры, какой филиал получает какое поддерево услуг — все принадлежали агентству. Мы реализовали эти решения точно как указано. ## Агентствам, заказывающим ребилд WordPress > На ребилде сайта стоматологической сети с несколькими филиалами карта редиректов решает, удержит ли агентство местные позиции, которые оно набирало месяцами. У этой практики — несколько филиалов и врачей, чьи страницы услуг и биографий сводятся в один сайт; у других это 1 кабинет, переезжающий с плоского сайта-визитки. Маршрутизация ломается так, что на тестовой среде всё выглядит исправно. Лендинг филиала не получает свой редирект и выпадает из местной выдачи. Шаблон врача подтягивает чужой телефон — звонок пациента тихо уходит не в тот офис. Редирект страницы услуги путает филиалы и отправляет рекламный трафик на чужую форму записи. Спросите подрядчика не «сможете ли вы перенаправить старый сайт», а «как вы проложите каждый URL по филиалам, не разбросав местную видимость». Пришлите текущий и целевой список URL — или адрес тестовой среды и черновую карту редиректов. Мы сверим каждый путь с вашей структурой филиалов и покажем, где маршрутизация может тихо сломаться. Затем вернём фиксированную смету в часах. Аудит без оплаты, смета в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-27-page-dental-177-days/ title: Доработка стоматологической темы: 27 страниц за 177 дней type: case_study date: 2024-12-28T19:04:45+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 27 страниц за 177 дней доработки стоматологической темы на WP Engine — до согласования с агентством в Redmine зафиксировано 27 раундов QA. Восемь страниц услуг добавили в ходе разработки без контентной документации: их собирали по стандартной теме, а пробелы заносили в очередь правок на последующие раунды. Приоритетную правку прозрачности SVG-иконок закрыли только после пяти циклов QA. Сайт был небольшим. Удерживать точность на каждой итерации — небольшой задачей не было. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая стоматология Конечный клиент Pauley Family Dentistry (стоматологическая клиника в США) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированная тема агентства + постраничный дизайн в Figma на WP Engine) Объём **27 URL** — главная, лендинг услуг, **16 страниц услуг**, страница врача, «О нас», контакты, лендинг блога и вспомогательные страницы (способы оплаты, страховка, финансирование) Сроки 177 дней (26 июня — 20 декабря 2025), в срок Затраты 77 часов — разработка, итерации QA и управление проектом Команда 5 специалистов Шаблоны **8 переиспользуемых шаблонов**, предоставленных агентством, применённых на 27 страницах Технологии WordPress · Elementor · WP Engine хостинг · постраничный дизайн в Figma · AutoQA агентства (проверки ссылок, email, контента AI) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **330+ сверенных замечаний SEO + CX** в общей очереди агентства, по контрольному списку запуска из 30 пунктов **Интенсивность взаимодействия** 220 замечаний от агентства · все закрыты к передаче (125 дней активной работы, 2025-07-13 — 2025-11-14) **Раунды проверки** ≈13 раундов за 177 календарных дней **Контрольный список запуска** 30 пунктов, согласованы перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Pauley Family Dentistry и цель развёртывания на своей брендированной системе тем на WP Engine. Агентство уже выполнило подготовительную работу: сбор требований клиента, аудит дизайна, настройку хостинга и подготовку контента через Google Docs для каждой страницы. Что им требовалось — команда разработки, которая аккуратно перенесёт макет Figma на тему и выдержит цикл QA столько, сколько потребуется для утверждения агентством. Задача была открыта по объёму так, как не бывает на пересборке с фиксированными границами. Figma — единственный источник истины, страница за страницей. Расхождения — обратно в общую очередь. Итерацию возвращали агентству только после того, как их проверяющий подтвердил, что расхождение закрыто. 27 страниц — это точка входа; 177 дней и 330+ зафиксированных замечаний — то, что понадобилось, чтобы её закрыть. Часть страниц добавили в карту сайта посреди разработки, без контентной документации: их собирали по стандарту темы, а пробелы заносили в очередь на следующие раунды. Агентству нужно было защититься от подрядчика, для которого «готово» значит «собрано». В доработке темы с 16 страницами услуг — у каждой свой фрейм в Figma, своя компоновка блоков контента и своё отклонение от стандартного шаблона — сборка завершена только тогда, когда каждая страница совпадает с дизайном на всех точках адаптации и каждый пункт QA закрыт. Команда, которая перестаёт итерировать, едва сайт выглядит «примерно правильно», оставляет агентству очередь правок, которую теперь разгребать ему. 330 пунктов в очереди этого проекта — не признак переделок, а запись тщательной работы. На страницах услуг стоматологии стоят логотипы страховых, виджеты способов оплаты и текст для пациентов, который обязан быть точным; цикл QA здесь не проверяет точность, а её создаёт. > **Контекст рисков.** Сборка из 27 страниц с 16 страницами услуг несёт не строительный риск — а риск итераций. Сценарий отказа — команда разработки, для которой «готово» означает «построено»: первичная доработка сдаётся, сайт выглядит примерно правильно на первой проверке, и отзывчивость команды падает по мере роста очереди задач агентства. За 177 дней и 27 задокументированных раундов QA ценность проекта была не в первичной сборке — а в готовности команды вернуться на двадцать седьмой круг с той же точностью, что и на первом. ## Как мы это сделали **1. Figma как контракт, тема как холст.** Файл Figma был спецификацией дизайна. Брендированная тема — базовой структурой страниц. Наша задача была согласовать их страница за страницей — там, где стандартная раскладка темы совпадала с Figma, мы её сохраняли; где Figma требовала отклонения, мы дорабатывали. Никакие дизайн-решения не исходили от нас. **2. Цикл QA в масштабе доработки темы.** Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 48 задач этого проекта **27 были раундами QA** — отдельными проходами, где агентство отмечало расхождения с дизайном, мы их разбирали, исправляли и возвращали сборку на следующую проверку. За этими раундами стояла куда более крупная сверка: агентство вело **330+ пунктов в двух вкладках очереди** (220 замечаний SEO и 110 CX), из которых 279 были отмечены выполненными к передаче. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без распространения.** Каждое изменение в брендированной теме — будь то макет страницы, секция-компонент или стилевой токен — мы фиксировали относительно Figma. Блоки логотипов страховых, секции виджетов оплаты, карточки с биографией врача — всё дорабатывалось в пределах конкретной страницы. Ни одна доработка не ушла в общие компоненты темы агентства, а значит, изменения этого проекта не затронули ни один другой сайт на той же теме. Вместо того чтобы вставать в ожидании ещё не переданных материалов, страницы собирали по стандартной теме, а пробелы в контенте заносили в очередь на следующие раунды. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями этого раунда, а не весь сайт; так доработка темы остаётся экономной, не теряя покрытия. 27 раундов QA за 125 дней активной работы, каждый возвращали только после того, как агентство подтвердит, что расхождение устранено. Одну приоритетную правку — прозрачность SVG-иконок — закрыли лишь после пяти отдельных раундов. Этот темп держался до последней задачи: не ради экономии, а потому что работа этого требовала. ## Контроль качества Первая внутренняя проверка на первичной сборке поймала отсутствующий favicon, отсутствующий логотип и сбой шрифтов на всём сайте: интеграция Adobe Fonts (Typekit) не загрузилась, и заголовки на всех 27 страницах остались нечитаемыми. Всё это нашли до того, как сборка попала к агентству. Предпередаточная проверка прошла через **Site Checker** — категории и порог нулевых ошибок см. в [наш подход к QA](/site-checker/). Внутренний контроль агентства работал после передачи и заносил замечания в общую очередь для нашего цикла правок, пока агентство не согласовало результат. Доработки оставались в переопределениях для конкретного клиента; общие компоненты темы агентства не менялись. ## Результаты Метрика Результат Страниц сдано **27** — 1 главная, 1 лендинг услуг, 16 страниц услуг, 1 страница врача, 1 «О нас», 1 контакты, 1 лендинг блога и 5 вспомогательных страниц (способы оплаты, страховка, финансирование, условия, членство) Шаблонов применено **8 из 8** переиспользуемых шаблонов построено и распределено по 27 страницам (главная, лендинг услуг, страница услуг, «О нас», страница врача, контакты, лендинг блога, стандартный шаблон) Контрольный список запуска **30 пунктов** согласовано Отслежено и решено задач QA / SEO + CX **330+** пунктов сверено в двух вкладках очереди задач агентства (220 SEO + 110 CX), 279 отмечено как выполненные при передаче Итераций QA в Redmine **27 из 48 задач (56%)** отслежены на уровне итераций Сроки **177 дней**, сдано в срок Затраты **77 часов** — без перерасхода, без расширения объёма Команда **5 специалистов** Передача хостинга Опубликовано в среде брендированной темы на WP Engine агентства Состояние страниц при передаче **27 / 27** URL тестовой среды вернули HTTP 200 в аудите карты сайта Если коротко: Figma агентства реализовали на их брендированной теме — 27 страниц, 8 шаблонов, 177 календарных дней, в рамках оценки в 77 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к теме подтверждён, объём согласован Разработка доработок ~6 недель Постраничная доработка темы для соответствия Figma; страницы услуг и специализаций собраны Итерации QA (параллельно) ~20 недель 27 раундов QA зафиксировано; каждый закрыт только после согласования с агентством Раунды исправлений ~2 недели Коррекции после проверки, обновление иконок, уточнение блоков страховых Сдача финальный день Сайт запущен на WP Engine _Разработка и QA шли параллельно — это характерно для доработки темы: отдельный «этап QA» здесь не закрывается начисто, цикл идёт непрерывно, пока агентство не согласует результат._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка темы и перенос макетов Figma) - **Павел Сажин** — итерации QA и исправления - **Анна Полунина** — поддержка доработки темы и QA - **Тимур Арбаев** — поддержка разработчика на поздних раундах доработки - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство всё время держало отношения с конечным клиентом на себе. Все запросы на доработку шли через общую очередь агентства; Pauley Family Dentistry с нашей командой напрямую не работала. Каждую итерацию выпускали только после того, как проверяющий со стороны агентства подтвердит, что изменения соответствуют спецификации. ## Агентствам с библиотекой шаблонов > На брендированном шаблоне ваш риск — на границе между общим слоем шаблона и правками под конкретного клиента. У этой клиники — одна точка и типовой набор услуг; у других — сеть филиалов, наследующих общую систему шаблонов. Если граница размыта, клиент меняет один цвет — и токены бренда перестают разноситься по сайту. Обновление родительского шаблона тихо откатывает месяц работы над дочерней темой. Библиотека блоков в редакторе наполовину спрятана, и без звонка вашему разработчику клиент не соберёт даже лендинг услуги. Вопрос не в том, «соберёте ли вы страницы по шаблону», а в том, как вы разметите правки, чтобы клиентский слой пережил следующее обновление шаблона. Пришлите исходник шаблона, его ID или спецификацию бренда. Мы разберём границу между системой шаблона и вашими доработками, покажем точки, где обновление от поставщика шаблона откатит вашу работу, и вернём смету в фиксированных часах. Разбор — бесплатно, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-legal-331-urls-149-days/ title: Ребилд юридического сайта на WordPress — 331 URL за 149 дней строго по спецификации type: case_study date: 2024-12-23T05:14:39+00:00 case_industry: Юридические услуги case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Сайт юридической фирмы с 331 URL мигрирует с плоских .html-путей на вложенную архитектуру чистых URL — 176 профилей компаний по асбесту, 121 городская страница по мезотелиоме и 883 редиректа записей блога, которые нужно согласовать на 10 шаблонах Adobe XD. Ребилд сдан за 149 дней и 100 часов разработки, с каждым закартированным редиректом, каждым шаблоном, применённым по спецификации, и всеми 58 пунктами очереди задач SEO, закрытыми до согласования агентством. ## Краткий обзор Поле Значение Индустрия клиента Юридические услуги — Мезотелиома, Асбест, Травмы и несчастные случаи Конечный клиент Throneberry Law Group (по всей территории США) **Формат сотрудничества** **White-label сборка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг WP Engine Объём работ **331 URL контента мигрировано** с устаревших `.html`-путей на чистые вложенные URL, плюс **883 редиректа записей блога** согласовано; 10 шаблонов построено и применено Сроки 149 дней (14 мая – 10 окт 2025), по графику Трудозатраты **100 часов** при оценке 100 часов — без перерасхода Команда 3 специалиста (Наталия Богатель — ведущий разработчик · Павел Сажин — QA и миграция контента · Антон Херсун — руководитель проекта) Шаблоны **10 шаблонов** из юридической дизайн-библиотеки агентства (About Throneberry, Asbestos, Mesothelioma, Veterans, Attorney, Location Template, Results, Contact Us, Blog Lander, Article Template) Технический стек WordPress · Elementor Pro · Gravity Forms · WP Engine · Rank Math · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) Проверка контентного паритета Сравнение оригинального и нового контента выполнено до передачи — нет пропущенного контента, нет битых внутренних ссылок, нет структурных расхождений **Сдано** **Спецификация выполнена строка-в-строку — 331 URL мигрировано, 883 редиректа закартированы, 58/58 пунктов очереди задач SEO закрыто, контрольный список запуска из 30 пунктов согласован** **Ритм работ** 58 задач от агентства · все закрыты к передаче (43-дневный активный период, 2025-06-10 – 2025-07-22) **Раунды проверки** ≈6 раундов проверки за 149 календарных дней **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи У агентства был постоянный юридический клиент — Throneberry Law Group, общенациональная практика по мезотелиоме и вреду от асбеста — чей существующий сайт на WordPress требовал полного ребилда. Старый сайт работал на плоских `.html` URL на сотнях городских страниц по мезотелиоме, профилях компаний по асбесту по штатам и обширном архиве блога. Задача от агентства заключалась в миграции всего контента на чистую вложенную архитектуру URL на Elementor Pro, с каждым старым путём, перенаправляющим на новый адрес. Агентство передало нам таблицу Google Sheets, содержащую каждый URL для миграции с целевым путём, каждый шаблон, каждый meta title и description для переноса, контрольный список запуска из 30 пунктов и предзаполненные очереди задач. Сборка выполнялась в их окружении WP Engine; контактные формы работали через Gravity Forms; SEO управлялось с Rank Math. Нашей задачей было выполнить спецификацию как написано — наложить 331 URL контента на 10 шаблонов, согласовать 883 редиректа записей блога и закрыть обе очереди задач QA до передачи. Риск, от которого агентство подстраховывалось, был не в коллапсе SEO — с этим они справились бы сами. Риск был в том, чтобы передать сборку подрядчику, который тихо импровизирует в обход брифа: пропущенный редирект на городской целевой странице, не тот шаблон на профиле компании, перерасход бюджета на объёме в 331 URL, сдвиг окна запуска на чувствительном к срокам юридическом маркетинговом календаре. > **Контекст рисков.** В практике по мезотелиоме и асбесту каждый входящий запрос несёт вес, отличный от большинства других юридических вертикалей — городская целевая страница или контактная форма — это уже начало первичного разговора с потенциальным клиентом, где ставки для ищущего высоки. Ребилд 331 URL контента и согласование 883 редиректов записей блога с устаревших плоских `.html`-структур на вложенные чистые URL несёт составной риск: каждый редирект — потенциальный разрыв в высоконамеренном и чувствительном ко времени пути клиента. Пропущенный редирект на городской странице по мезотелиоме или профиле компании по асбесту теряет не только SEO-вес — он теряет потенциального клиента в момент, когда тот ищет юридическую помощь. ## Как мы это сделали **1. 10 шаблонов, 331 страница, один процесс сборки.** Страницы Throneberry Law Group распределились по библиотеке юридических шаблонов агентства: About Throneberry (10 страниц — о нас, отзывы, ресурсы, FAQ и поддерживающий контент), Asbestos (176 страниц — профили отдельных компаний), Mesothelioma (121 страница — городские страницы по штатам), Veterans (10 страниц), Contact Us (8 страниц), плюс Attorney, Location Template, Results, Blog Lander и Article Template. Каждую страницу построили на назначенном шаблоне; ни одной страницы не делали вручную вне шаблонной системы. Мы использовали библиотеку юридических шаблонов агентства на всех 331 URL, а не создавали отдельные макеты страниц, потому что единообразие на основе шаблонов означало, что архитектура URL сайта оставалась предсказуемой на 176 профилях компаний по асбесту и 121 городской странице по мезотелиоме, делая карту редиректов проверяемой по спецификации агентства. **2. Спецификация выполнена строка-в-строку, из таблицы агентства.** Агентство передало нам таблицу Google Sheets с картой Current URL → New URL для каждой страницы. Где на старом сайте было `abex-corporation.html`, спецификация требовала `asbestos-companies/abex-corporation/`. Где на старом сайте были плоские страницы по штатам, спецификация требовала вложенных путей `mesothelioma-lawyer/california/los-angeles/`. Мы реализовали каждую строку как написано. Объём в часах мы оценили сами и зафиксировали до старта — 46,5 часов на 331 строку перестройки URL — и итог уложился в согласованные ~100 часов проекта. Принцип прост: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защитить этот контракт, а не редактировать его. **3. Проверка обходом, а не «на вид нормально».** Перед переключением DNS мы прогнали Screaming Frog на исходном сайте и тестовой сборке параллельно. Коды статусов, битые ссылки, цепочки редиректов, расхождения в мета-тегах — каждое расхождение сверено со спецификацией агентства. Вкладка SEO Meta Data таблицы содержала 746 строк с title, description и H1 для каждого URL; вкладка SEO Optimizations содержала 403 строки уточнённого meta-контента. Обе реализовали строка за строкой. Второй обход после запуска подтвердил, что все внутренние ссылки разрешаются на рабочем домене. Каждый из 883 редиректов записей блога был вручную проверенной строкой в sitemap агентства — пропущенный редирект на городской странице по мезотелиоме или профиле компании по асбесту потерял бы не только ссылочный вес, но и потенциального клиента в момент поиска юридического представительства, поэтому ни одна карта редиректов не автоматизировалась без прохода согласования. **4. Контрольный список запуска из 30 пунктов, закрыт до передачи.** Семь категорий: Дизайн, Функциональность, Контент, SEO и аналитика, Адаптивность, Прочее / Под клиента и Домен и DNS. Ничего не сдавали, пока не согласовали каждый пункт. QA на разных устройствах на Chrome / Firefox / Safari / Edge и пяти форматах экрана (1920 / 1280 / 1024 / iPad / портретный мобильный). Контрольный список явно требовал сравнения обхода Screaming Frog между исходным сайтом и сборкой на тестовой среде, проверки редиректов после релиза и подтверждения, что все формы отправляются корректно с reCAPTCHA. Работа строка за строкой из таблицы карты сайта агентства означала, что структура slug должна быть корректна до миграции контента, а meta — до переключения; порядок диктовался картой редиректов, а не произвольным решением. Комментарий Павла после импорта, когда 377 страниц были выложены на тестовую среду: «для такого сайта — правок минимум» — для сайта такого масштаба это звучало как окупаемость дисциплины. ## Результаты Метрика Результат Точность спецификации — URL мигрировано **331 / 331** URL контента мигрированы с устаревших `.html`-путей на чистые вложенные URL, как указано в спецификации Точность спецификации — редиректы **883 / 883** редиректа записей блога и смены путей закартированы и проверены Точность спецификации — шаблоны **10 / 10** шаблонов построено и применено на всём сайте Очередь задач SEO **58 / 58** закрыты как Completed Очередь задач AM **5 / 11** закрыты как Completed; 6 остались To Do на момент экспорта (клиентская сторона или вне рамок агентства) Контрольный список запуска **30 пунктов** согласованы — Дизайн / Функциональность / Контент / SEO и аналитика / Адаптивность / Прочее / Домен и DNS Сроки **149 дней** (14 мая – 10 окт 2025), сдано по графику Трудозатраты **100 ч / 100 ч оценка** — без перерасхода, без расширения объёма Адаптивная проверка Ноль проблем с вёрсткой на 4 браузерах × 5 форматов экрана Передача Сайт запущен на WP Engine в запланированный день переключения, без простоя Статус сайта, проверено 2026-04 Сайт в работе, отдаёт 200 при свежей проверке Результат, если просто: ребилд на 331 URL запущен на 10 шаблонах на окружении WP Engine, в рамках оценённых часов, в запланированный день переключения. 883 редиректа закартированы и проверены, 58 пунктов очереди задач SEO закрыты, контрольный список запуска согласован до передачи. ## Контроль качества Проверка паритета на всех 377 страницах тестовой среды перед передачей выявила 6 страниц с отсутствующими или неверными slug — исправлено до того, как агентство увидело сборку; meta-контент на каждой странице брался из таблицы спецификации агентства, потому что, как было отмечено в процессе сборки, всё, что отклоняется от спецификации, не пройдёт QA. QA до передачи проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Приёмочный контур агентства выполнялся после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Спецификация агентства рассмотрена; ~100 ч согласованы Разработка (страницы + шаблоны + контент) ~5 недель 331 URL построены на 10 шаблонах; миграция контента; обе очереди задач QA открыты Очередь задач SEO + проверка AM ~8 недель 58/58 пунктов SEO закрыты; очередь задач AM рассмотрена; meta titles / descriptions / H1 обновлены по спецификации SEO Meta Data на 746 строк Контрольный список запуска + проверка редиректов ~3 недели Контрольный список из 30 пунктов закрыт; 883 редиректа проверены; обход Screaming Frog сравнён После запуска ~8 недель Обновления макета меню, интеграция Asana, дополнительные раунды обратной связи _Этапы пересекаются (проверка очереди задач SEO шла параллельно с поздней разработкой и последующими доработками), поэтому календарный срок — 149 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (сборка, реализация шаблонов и доработки после запуска) - **Павел Сажин** — итерации QA, миграция контента и закрытие очередей задач - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и SEO-стратегия оставались на стороне агентства-партнёра на всём протяжении. Наша команда была невидима для конечного клиента. ## Агентствам, заказывающим ребилд WordPress > Для агентства, заказывающего ребилд сайта юридической практики по травмам и несчастным случаям, главный структурный риск — потерять карту редиректов и контент в момент переключение. У этой практики — мезотелиома и асбестоз, где каждый запрос имеет высокую ставку; у других — общие юридические консультации с широкой воронкой. Риски тихие: старый редирект оборвёт рекламную кампанию из соцсетей, на перезаписи слетит структурированная разметка, а контактная форма потеряет данные об источнике перехода. Подрядчику стоит задавать не вопрос «сделаете ли ребилд?», а вопрос «как именно сохраните карту редиректов и структурированную разметку при миграции?» Пришлите адрес текущего сайта, черновик карты редиректов или макеты. Мы проверим карту на полноту, сверим её с текущим индексом, проверим структурированную разметку на выпадение. Вернём фиксированную смету в часах. Аудит ничего не стоит — смета приходит в часах, не в диапазоне. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-53-page-eye-care-108-days/ title: Доработка темы для оптометрии: 53 страницы за 108 дней type: case_study date: 2024-12-21T14:56:22+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 53 страницы оптометрической клиники, доработанные под макеты агентства в Figma на их стоматологическом шаблоне WP Engine, плюс 264 блога импортировано под шаблоном записи и 300 редиректов загружено через CSV — всё сдано за 108 дней. Миграция блога была обязательством по сохранности URL: 404 на /blog/nearsighted-farsighted/ был обнаружен и закрыт до того, как сборка покинула наши руки. Доработка и миграция шли параллельно в одном шестираундовом цикле QA. Шаблонная доработка даёт скорость и единообразие — но только если работать строго. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Параметр Значение Отрасль конечного клиента Офтальмология / оптометрия (частная практика) Конечный клиент Vision Source Mandan (Mandan, Северная Дакота) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (фирменный шаблон агентства + постраничные макеты Figma на WP Engine) Объём **53 URL** — 1 главная, 1 страница услуг, 9 страниц услуг, 8 страниц «О нас» / врачей, 1 контакты, 1 страница блога, плюс **264 блога** импортировано под тем же шаблоном Сроки 108 дней (16 мая – 2 сентября 2025), без срывов Затраты 119 часов — 96 ч разработка · 10 ч итерации QA · 10 ч PM · 4 ч правки после проверки Команда 5 специалистов Шаблоны **9 переиспользуемых шаблонов** (Главная, О нас, Страница врача, Контакты, Страница услуги, Каталог услуг, Блог, Запись блога, Стандартный шаблон) — все применены к 53 доработанным страницам Технологии WordPress · Elementor · WP Engine · постраничный дизайн в Figma · рабочее пространство QA агентства · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **160+ отслеженных SEO + CX проблем** согласовано в очереди задач агентства (112 SEO + 48 CX) по 29-пунктному контрольному списку запуска **Динамика сотрудничества** 109 задач от агентства · все закрыты к сдаче (53 дня активной фазы, 2025-06-22 – 2025-08-13) **Раунды проверки** ≈6 раундов проверки за 108 календарных дней **Контрольный список запуска** 29 пунктов, согласовано перед переключением ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Vision Source Mandan и цель развёртывания на своей фирменной системе шаблонов WP Engine. Агентство уже выполнило предшествующую работу: аудит дизайна, согласование с клиентом, настройку хостинга и постраничный контент-план, привязанный к существующему сайту, который нужно было перенести целиком. Что им требовалось — команда разработчиков, которая точно перенесёт Figma на шаблон, а затем переместит каждую запись блога и каждую унаследованную страницу без потери URL-структуры, на которую полагались пациенты клиники в поиске информации об уходе за зрением. Задача была чисто исполнительская, с миграционной составляющей. Figma — единственный источник истины. Доработать шаблон под неё страница за страницей, точка адаптации за точкой адаптации, с сохранением навигационных конвенций оптометрии: категории услуг по зрению сгруппированы по стандартной таксономии вертикали, отдельные биографии врачей на ссылаемых подстраницах, корректно выведены онлайн-оплата и формы для пациентов. И перенести блог — 264 записи — под шаблоном записи, не потеряв ни одной записи. Агентство страховалось от двух сценариев сразу: подрядчик, который вольно трактует Figma вместо точного соответствия, и — с учётом миграции блога — тот, кто относится к числу записей как к галочке, а не как к обязательству за каждый URL. Оптометрическая клиника зависит от локального поиска для привлечения пациентов; любой слаг, который незаметно меняется при миграции — поломка, которая не проявляется в CMS, но теряет URL, добавленный пациентом в закладки. Проверка контента и SEO-аспектов в нашем QA-проходе перед сдачей была тем рубежом в тестовой среде, который выявил эти проблемы до сдачи. > **Контекст рисков.** Оптометрическая клиника зависит от локального поиска для привлечения пациентов, а это означает, что 264 блога, перенесённые в эту сборку, были не задачей по миграции контента — это было обязательством по сохранности URL. Слаг, который незаметно меняется при миграции, не вызывает ошибки в CMS и не заметен на основном сайте; он проявляется только как потерянный сигнал ранжирования или сломанная закладка. Агентство страховалось от двух сценариев: подрядчик, который вольно трактует Figma вместо точного соответствия, и тот, кто относится к числу записей как к галочке, а не несёт ответственности за каждый URL. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Фирменный шаблон — базовой структурой страниц. Наша задача была согласовать их страница за страницей — там, где стандартная раскладка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения (раскладки плиток услуг по уходу за зрением, карточки врачей, блоки контента об оправах и линзах), мы дорабатывали. Никаких дизайн-решений с нашей стороны не принималось. **2. Цикл QA в масштабе доработки темы.** Чистая доработка темы — это не «собрали раз, проверили раз». Это «собрали, QA, поправили, QA, поправили». Агентство отслеживало 160 отдельных проблем в двух вкладках очереди задач общего рабочего пространства — 112 SEO-находок и 48 CX-находок — каждая из которых была назначена, обработана, при необходимости снабжена скриншотом и закрыта только после подтверждения агентства. Такой объём — не признак нестабильности; именно это отличает сайт на шаблоне, выглядящий «примерно правильно», от сайта, соответствующего дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без отклонений.** Каждое изменение в фирменном шаблоне — будь то раскладка страницы, компонент секции или стилевой токен — мы документировали относительно референса Figma. Страницы категорий услуг по уходу за зрением, профильные карточки врачей, виджеты онлайн-оплаты и раскладки форм для пациентов дорабатывали в рамках конкретной страницы, а не в общем шаблоне. Работа над этим проектом не ухудшила шаблон для следующего сайта, который он будет обслуживать. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на компьютере, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA покрывал страницы, затронутые дизайн-расхождением этого раунда, плюс выборку импортированных записей блога для подтверждения, что шаблон записи корректен на всех типах экранов. Миграция блога и доработка по Figma шли как параллельные направления QA — 264 записи для проверки по URL, 53 страницы для проверки соответствия дизайну. Мы чётко разделили эти два направления: миграция блога закрывалась через импорт CSV с 300 редиректами и постраничный проход, что не давало ей смешиваться с циклом QA по дизайну. Каждое направление учитывалось отдельно; ни одно не поглощало другое. ## Контроль качества Нагрузка QA на этом проекте была обусловлена миграцией блога: потребовалось импортировать 300 редиректов для сохранения целостности слагов, 404 на `/blog/nearsighted-farsighted/` был выявлен и отмечен во внутреннем QA-проходе, а артефакты кодировки (символы hash) были обнаружены в метаданных импортированных записей — все три проблемы решены до того, как сборка покинула наши руки. QA перед сдачей проходило через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Собственный QA-контур агентства работал после сдачи и фиксировал замечания в общую очередь задач для нашего цикла правок до их согласования. Доработки оставались в переопределениях конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **53** доработанные страницы — 1 главная, 1 страница услуг, 9 страниц услуг, 8 страниц «О нас» / врачей, 1 контакты, 1 страница блога и 32 вспомогательные страницы на стандартном шаблоне Блогов импортировано **264** записи перенесены под импортированным шаблоном блога (сохранность URL — без заявления об SEO-ценности) Шаблонов применено **9** переиспользуемых шаблонов из каталога агентства, распределённых по 53 страницам и шаблону записи Контрольный список запуска **29 пунктов** согласовано по направлениям «Дизайн», «Функциональность», «Предмиграция» и «Постмиграция» QA / SEO проблем отслежено и решено **160** позиций согласовано по двум вкладкам очереди задач агентства (112 SEO + 48 CX, 154 закрыто к сдаче) Сроки **108 дней**, сдано без срывов Затраты **119 часов** при оценке в 119 часов — без перерасхода, без расползания объёма Команда **5 специалистов** Хостинг Запущено в шаблонной среде WP Engine агентства Состояние страницы при сдаче URL рабочего сайта возвращает HTTP 200 при независимой проверке (данное окружение, 2026-04-24) Если коротко: макеты Figma агентства были реализованы на их фирменном шаблоне на 53 страницах и 9 шаблонах, с 264 записями блога, импортированными под шаблоном записи, за 108 календарных дней, в рамках оценки в 119 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Figma проанализирована, доступ к шаблону подтверждён, объём карты сайта и миграции 264 блогов определён Доработка ~6 недель Постраничная доработка шаблона под Figma; импорт блога и привязка шаблона Итерации QA (параллельно) ~6 недель 160 проблем по очередям задач SEO и CX выявлено, обработано, согласовано Раунды правок ~1 неделя Поздние правки клиента — страница акций, замена изображений, уточнения текста Сдача день запуска Сайт запущен на WP Engine; подпись готовности от агентства _Разработка и QA шли параллельно — это характерно для работы по доработке темы, где «фаза QA» не закрывается чисто; цикл работает непрерывно до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона и приведение макетов Figma к раскладке) - **Павел Сажин** — итерации QA и правки - **Анна Полунина** — координация и подготовка контента со стороны миграции - **Лиза** — выборочные проверки QA со стороны управления - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Партнёрское агентство сохраняло полное владение управлением проектом, дизайн-решениями и отношениями с конечным клиентом на всём протяжении. Конечный клиент нас не видел: каждый запрос и подпись проходили через общую очередь задач агентства, и ни один раунд не помечался закрытым, пока проверяющий со стороны агентства не подтверждал это. ## Агентствам с библиотекой шаблонов > Вы боитесь, что после доработки шаблона клиентские правки разъедутся с библиотекой, и при первом обновлении от поставщика шаблона всё посыплется. Опасное место здесь — граница между общим слоем шаблона и переопределениями на стороне клиента. У этой клиники — насыщенный блог, который держит локальную выдачу; у других — статичный набор услуг, который проверяют по одним макетам. Контент блога, перенесённый со старого сайта, незаметно меняет собственные слаги и роняет страницы из индекса. Клиентские переопределения ломаются при первом же обновлении шаблона от поставщика. А редакторы клиента находят пропавшие блоки за слоем кода — и заводят на агентство запросы в поддержку. Подрядчику стоит задавать не «соберёте ли вы шаблоны?», а «как вы защитите клиентские правки, когда поставщик обновит шаблон?» Пришлите исходник или ID шаблона и спецификацию бренда. Мы сверим спецификацию шаблона с правками вашего клиента и подсветим переопределения, которые сломаются при следующем обновлении. Вернём фиксированную смету в часах. Бесплатно, со сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-44-pages-27-days/ title: Ребилд сайта общей стоматологии на 44 страницы — сдан за 27 дней точно по ТЗ type: case_study date: 2024-12-14T14:06:57+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 44 страницы ребилда на WordPress, размещённого на Kinsta, для стоматологической практики общей и косметической стоматологии с двумя филиалами в Трофи-Клаб и Лас-Колинас, Техас — 12 шаблонов, 11 редиректов и отдельная вкладка в таблице Google Sheets, где 55 страниц опубликованного сайта и тестовой среды сверялись заголовок за заголовком: каждый H1, H2 и инлайновый span-тег. Сравнение Htags выявило 30 расхождений в структуре заголовков ещё до проверки агентства; каждое исправили до передачи тестовой среды. ## Краткий обзор Поле Значение Отрасль клиента Медицина — общая и косметическая стоматология Конечный клиент Complete Dentistry (Dr. David Crumpton DDS, Trophy Club & Las Colinas, TX) **Формат сотрудничества** **White-label ребилд WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor, хостинг Kinsta Объём работ **44 URL перестроено** — 1 главная, 1 «О нас», 1 страница врача, 3 лендинга услуг, 21 страница услуг, 3 поста блога, лендинг блога, контакты, 11 служебных страниц на стандартном шаблоне — плюс 11 редиректов и 2 изменения URL Сроки 27 дней основной ребилд (19 авг — 15 сен 2025); работы после запуска продолжались до янв 2026 Затраты **~61 час** основной ребилд; **~68 часов** общий объём с учётом исправления хедера после запуска и добавления страницы страховки Команда 5 специалистов (31 ч разработка · 10 ч QA · 15 ч PM · 2,8 ч исправления после запуска) Технологии WordPress · Elementor · Kinsta · Yoast · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) Проверка контента Сверка контента исходного и нового сайта пройдена до передачи — ни одной пропущенной секции, ни одной битой внутренней ссылки, ни одного структурного отклонения **Результат** **44 URL перестроены по ТЗ, 11 редиректов проверены, соответствие H1 подтверждено на 44 страницах, 37 строк очереди задач DEV закрыты, контрольный список запуска из 75 пунктов согласован** **Ритм работы** 37 задач от агентства · все закрыты к моменту передачи (21 день активной работы, 2025-09-04 – 2025-09-24) **Раунды проверки** ≈8 раундов в течение 159 календарных дней **Контрольный список запуска** 75 пунктов, согласован до публикации ## Постановка задачи Маркетинговое агентство из США, нанятое Complete Dentistry — стоматологической практикой общей и косметической стоматологии под руководством Dr. David Crumpton DDS, работающей из двух филиалов в Техасе (Трофи-Клаб и Лас-Колинас), — передало нам таблицу Google Sheets с картой URL на 56 строк, каталогом из 12 шаблонов, контрольным списком запуска на 75 пунктов и заранее заполненной очередью задач в трёх направлениях (DEV, SEO, CX). Среда ребилда — тестовая среда агентства на Kinsta; конструктор страниц — Elementor; целевой рабочий адрес — `completedentistrytx.com` с преимущественно сохранённой структурой URL. Задача — ребилд один-в-один: реализовать каждую страницу по назначенному шаблону из карты сайта, сохранить исходные заголовки и структуру контента в точности как на рабочем сайте, настроить 11 редиректов и 2 изменения URL по спецификации карты сайта и закрыть очередь задач DEV по критериям агентства до передачи тестовой среды. Клиентские решения — копирайтинг, структура меню, контактные данные, контекст изображений — оставались за агентством. Мы выявляли неоднозначности и не импровизировали. > **Контекст рисков.** Структура заголовков у рабочего сайта была функционально продуманной: H1-теги с инлайновыми HTML-спанами для двухстрочного отображения на большом экране и однострочного на мобильных, с небольшим `` для указания города. Перестройка в Elementor рискует потерять эту структуру — разработчик, который верстает заголовок визуально, но использует `
` вместо исходной span-структуры, создаёт страницу, похожую внешне, но структурно отличающуюся от оригинала. Выделенная вкладка Htags Live vs тестовая среда — 99 строк, отслеживающих содержимое заголовков на 55 страницах в обеих средах — делала любое такое структурное расхождение видимым ещё до того, как агентство открывало свою проверку. Тридцать расхождений на уровне заголовков было выявлено в этом сравнении; каждое исправлено до передачи. Именно такая проверка и ускоряет раунд QA. ## Как мы это сделали **1. 12 шаблонов, 44 страницы, один процесс ребилда.** Страницы Complete Dentistry распределялись по стандартной библиотеке стоматологических шаблонов агентства: Главная, О нас, Страница врача (ведущий стоматолог Dr. David Crumpton), Лендинги услуг (3 — косметическая, реставрационная, общая), Страницы услуг (самая объёмная категория — 21 страница, включая smile makeover, виниры, композитный бондинг, импланты, реконструкцию полной дуги, ортодонтию и общие процедуры), Лендинг блога, Блог (3 поста), Контакты, Страховка, Политика конфиденциальности, Условия использования и стандартный шаблон для служебных страниц. Каждая страница строилась по назначению шаблона из строки карты сайта; ни одна страница не версталась вручную вне шаблонной системы. **2. ТЗ исполнено построчно — включая структуру заголовков.** Там, где заголовки оригинального сайта содержали инлайновый HTML (``, ``, CSS-классы управления типографикой), мы воспроизводили эту структуру в сборке Elementor. Вкладка Htags Live vs тестовая среда в таблице Google Sheets обеспечивала эту проверку: она показывала сырое содержимое заголовков (не только видимый текст) на обоих адресах — опубликованном и тестовом. Мы использовали сравнение Htags, а не визуальный осмотр, потому что расхождение структуры заголовков в Elementor (разметка заменена на `
`, спаны схлопнуты) проходит превью в браузере, но сразу видно при сравнении сырого содержимого. Из 55 сравнённых страниц 30 показали расхождения в структуре заголовков в начальной сборке — различия в разметке, артефакты пробелов, случай с неверным контентом, перенесённым с другой страницы услуги. Все 30 были исправлены до передачи. **3. Одиннадцать редиректов и два изменения URL реализованы по спецификации.** Карта сайта содержала 11 строк редиректов (в основном схлопывание подстраниц в консолидированные пути — например, `/about-us/meet-the-dentists/` перенаправляется на `/about-us/`) и 2 изменения URL (перемещение профиля врача с `/about-us/meet-the-dentists/meet-dr-david-crumpton/` на плоский путь `/about-us/dr-david-crumpton/`). Всё реализовано и проверено по колонке статус-кодов карты сайта до передачи. **4. Очередь задач в трёх направлениях закрыта до согласования тестовой среды.** Задачи велись в трёх направлениях со стороны агентства. Очередь задач DEV (37 реальных строк) включала баги и запросы изменений с нашей стороны: исправления ссылок с трейлинг-слешем, текст заголовков форм, неанглийские комментарии в коде, точность кропа изображений, ошибки в подсчёте H1, видимость хедера и очистку меню. Очередь задач SEO (25 активных строк — 5 выполнено, 17 в QA, 3 в работе) и очередь задач CX (6 активных строк в QA) были направлениями проверки агентства после передачи. Контрольный список запуска из 75 пунктов — статус-коды, редиректы, структура URL, контактные формы, вёрстка, мобильная адаптивность, контент, SEO — согласован до того, как агентство перенесло сайт на рабочий адрес. Именно сравнение Htags Live vs тестовая среда здесь и решало. Тридцать расхождений в структуре заголовков — различия разметки, артефакты пробелов, перенос неверного контента с соседней страницы услуги — были видны при сравнении до того, как агентство открыло проверку. Визуальная проверка сама по себе их бы не выявила; сравнение сырого контента справилось, и поэтому раунд QA прошёл быстро, как только агентство приступило к проверке. ## Результаты Показатель Результат Страниц перестроено **44** по 12 шаблонам (1 Главная · 1 О нас · 1 Врач · 3 Лендинга услуг · 21 Страница услуг · 1 Лендинг блога · 3 Поста блога · 1 Контакты · 11 Служебных страниц) Использовано шаблонов **12** из стандартной стоматологической библиотеки агентства Реализовано редиректов **11 редиректов + 2 изменения URL** по спецификации карты сайта Проверка заголовков **55 страниц** сверены: опубликованный сайт и тестовая среда; 30 расхождений выявлено и исправлено до передачи Очередь задач DEV **37 / 37** реальных строк закрыты как выполненные Очередь задач SEO **25 активных строк** (управлялись агентством после передачи) — 5 выполнено, 17 в QA, 3 в работе на момент выгрузки Очередь задач CX **6 активных строк** (управлялись агентством после передачи) — в QA Контрольный список запуска **75 пунктов** согласовано по разделам: разработка / вёрстка / мобильная адаптивность / контент / SEO Сроки ребилда **27 дней** (19 авг — 15 сен 2025), сдано по графику Затраты на ребилд **~61 час** (31 ч разработка · 10 ч QA · 15 ч PM · 5 ч проверки и исправления очереди задач) Работы после запуска Исправление хедера + добавление страницы страховки · окт 2025 – янв 2026 **Статус сайта** Работает, открывается по адресу https://www.completedentistrytx.com/ — проверено в апреле 2026. Если коротко: агентство получило 44-страничный ребилд на Kinsta с проверкой структуры заголовков страница за страницей относительно оригинального сайта, все редиректы и изменения URL применены по ТЗ, очередь задач DEV очищена до миграции. Работы после запуска включали исправление хедера и добавление новой страницы страховки в рамках тех же отношений с агентством. ## Контроль качества QA до передачи выявило две проблемы кодовой гигиены на этой сборке: русскоязычные комментарии в двух скриптах footer.php — обнаружены и удалены до передачи тестовой среды — и несоответствие контейнера заголовка на главной странице, где два элемента были помещены внутрь контейнера H1 вместо исходной структуры с одним span-элементом — выявлено сравнением Htags по 55 страницам. QA до передачи выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/): список категорий и порог нулевых ошибок. Свой проверочный контур агентства запускался после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до момента их согласования. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя таблица Google Sheets изучена, карта сайта подтверждена, выставлена смета на 56 ч разработки + QA + PM Фаза сборки (страницы + шаблоны) ~2 недели Все 44 URL перестроены; редиректы настроены; первичное сравнение заголовков проверено QA и закрытие очереди задач ~1 неделя 37 строк очереди задач DEV закрыты; 30 расхождений заголовков исправлены; контрольный список согласован Передача тестовой среды 15 сен 2025 Тестовая среда сдана; агентство начало послесдаточную проверку SEO + CX Исправление хедера после запуска окт 2025 CSS прилипающей шапки и корректировка видимости логотипа на всех страницах Добавление страницы страховки дек 2025 – янв 2026 Новая страница страховки добавлена в рамках сохранённого контракта _QA и сборка шли параллельно — сравнение заголовков началось, пока дорабатывались последние страницы услуг, поэтому сроки заняли 27 дней, а не последовательные фазы._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик, реализация шаблонов и настройка редиректов - **Павел Сажин** — ведущий QA и проверка очереди задач; исправление хедера после запуска - **Анна Полунина** — поддержка разработки и QA перестроенных страниц - **Тимур Арбаев** — поддержка QA в раундах исправлений после запуска - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта, управление, коммуникация с аккаунт-менеджером агентства и координация очереди задач Проектное управление со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим ребилд WordPress > При ребилде сайта именно карта редиректов решает, перенесётся ли накопленная вами SEO-ценность. У этой практики — стоматология с двумя филиалами и отдельными URL под услуги; у других — один кабинет с плоскими лендингами. Старые адреса, на которые опираются пациенты и поисковики, после переезда отдают 404. Мета-заголовки и описания, которые вы кропотливо собирали, исчезают или переписываются. Внутренние ссылки рвутся, когда меняется архитектура. Подрядчику стоит задавать не вопрос «перенесёте ли сайт?», а вопрос «как именно вы проверите карту редиректов?» Пришлите адрес текущего сайта, черновик карты редиректов (если он есть) или макеты. Мы сверим текущую структуру URL с целевой архитектурой, отметим каждый пробел, из-за которого вы потеряете уже ранжируемую страницу, и вернём фиксированную смету в часах. Бесплатно, со сметой в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-35-page-dental-127-days/ title: Доработка 35 страниц стоматологического шаблона за 127 дней type: case_study date: 2024-12-12T00:40:36+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 35 страниц с глубокой таксономией имплантатов и протезов — полная дуга, одиночные, множественные, протезы, костные трансплантаты, синус-лифтинг, удаления — свёрстаны на шаблоне Sparkling по макету Figma, который покрывал не все 35. В середине проекта агентство запросило полное удаление ACF-обвязки, и четыре подстраницы услуг (All-on-4, All-on-X, гибридные протезы, имплантация в день обращения) были добавлены со специально написанным контентом. Мы собрали 12 страниц по Figma; 23 остались в черновике до получения контента клиента. ## Краткий обзор Параметр Значение Сфера деятельности клиента Медицина — стоматология (протезирование и имплантология) Конечный клиент Revive Dentures and Implants (Dr. Robert Long, Durham, NC) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma, хостинг Kinsta) Объём **35 URL сверстаны** — 12 собраны по Figma и в QA при сдаче, 23 отложены до получения контента клиента или свёрстаны с настройками шаблона по умолчанию Сроки 127 дней (29 сен 2025 – 2 фев 2026), по графику Трудозатраты 60 часов — разработка, итерации QA и управление проектом Команда 4 специалиста Шаблоны **11 переиспользуемых шаблонов** в библиотеке агентства, **9 применены** на 35 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · Gravity Forms · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **54+ отслеженных SEO-проблем** согласованы в очереди задач агентства, 30-пунктный контрольный список запуска (вкладка CX для этого проекта частично заполнена) **Интенсивность взаимодействия** 3 вопроса от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈8 раундов на протяжении 127 календарных дней **Контрольный список запуска** 30 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало нам макет Figma для Revive Dentures and Implants — протезно-ортопедической практики в Durham, NC, предлагающей имплантацию полной дуги, одиночные и множественные имплантаты, протезы, костную пластику и седацию — и доступ к своей брендированной шаблонной системе на Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, согласование с клиентом, настройку хостинга, контент-план. Им требовалась команда разработки, которая точно перенесёт Figma на шаблон, через столько итераций доработки, сколько потребует дизайн. Задача была чисто исполнительской. Figma — единственный источник истины. Дорабатывать шаблон под неё страница за страницей. Передавать замечания QA обратно агентству в общее рабочее пространство; не закрывать их без его согласования. > **Контекст рисков.** Сайт ортопедической практики держится на визуальной убедительности — пациенты, оценивающие реставрацию полной дуги, замечают несоответствие насыщенности шрифта и кадрирование hero-изображения так же, как заметили бы неряшливую приёмную. Риск, от которого страховалось агентство, был не только в неполном контенте (23 из 35 страниц не имели контента клиента на момент запуска) — но в расхождении между дизайном в Figma и настройками шаблона по умолчанию, которое проявится на каждой странице, где спецификация дизайна и контентный документ не полностью пересекались. Доработка стоматологического шаблона для услуг по имплантации и протезированию означает согласование глубоких сервисных таксономий — All-on-4, All-on-X, гибридные протезы, синус-лифтинг — с шаблоном, созданным для общей стоматологии, не позволяя стандартным настройкам шаблона диктовать путь пациента. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача — согласовать их постранично: где стандартная раскладка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения, мы дорабатывали. Никаких дизайн-решений с нашей стороны. **2. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». За время проекта мы провели 20+ QA-итераций в Redmine и согласовали 54+ позиции в общей очереди задач агентства — по каждому раунду агентство отмечало расхождения в дизайне, отсутствующие изображения и неточности контента; мы просматривали, исправляли и возвращали сборку на повторную проверку. Такой объём — не признак нестабильности; именно это отделяет сайт на шаблоне, который выглядит «примерно так», от того, что точно соответствует дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **3. Доработка без дрейфа.** Каждое изменение брендированного шаблона — будь то раскладка страницы, компонент секции или стилевой токен — мы документировали относительно Figma. Ни одна доработка не «протекла» в общие компоненты шаблона; работа по этому проекту не ухудшила шаблон для следующего сайта. **4. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах. Каждый раунд QA охватывал страницы, затронутые изменениями дизайна в этом раунде, а не весь сайт — так шаблонная сборка остаётся экономной без потери покрытия. Работа над запросом на удаление ACF-обвязки в середине проекта — агентство попросило заменить все шаблоны ACF на штатные страницы Elementor до сдачи — означала, что каждую страницу, собранную по исходной спецификации, пришлось перестроить с нуля. Это ограничение, поглощённое в рамках 127-дневного окна без продления сроков, позволило сохранить оценку в 60 часов. ## Контроль качества QA перед сдачей при переносе Figma на шаблон выявило два конкретных расхождения: несоответствие насыщенности шрифта (Figma указывала 700, но браузер рендерил тяжелее — скорректировано до 600 во всех заголовках) и CSS на уровне виджетов Elementor, который пропадал при адаптивной проверке — обе проблемы решены до того, как сборка достигла агентства. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порог нулевых ошибок. Внутренний контур проверки агентства работал после сдачи и фиксировал замечания в общей очереди задач для нашего цикла исправлений до согласования. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. ## Результаты Метрика Результат URL сдано **35 сверстано** — 12 собраны по Figma и в QA при сдаче, 23 отложены до получения контента клиента или свёрстаны с настройками шаблона по умолчанию Шаблонов применено **9 из 11** переиспользуемых шаблонов построены и распределены по 35 страницам Контрольный список запуска **30 пунктов** согласованы QA / SEO-проблем отслежено и решено **54+** позиции согласованы в SEO-очереди задач агентства (вкладка CX для этого проекта частично заполнена) QA-итераций в Redmine **20+ из 88 задач** отслежены на уровне итераций Сроки **127 дней**, сдано по графику Трудозатраты **60 часов** при оценке 60 часов — без перерасхода, без расширения объёма Команда **4 специалиста** Размещение Запущено в шаблонном окружении агентства на Kinsta Состояние страниц при сдаче **12 / 35** страниц с полным контентом в QA; остальные свёрстаны или отложены Если коротко: Figma агентства была реализована на их брендированном шаблоне на 35 страницах и 9 шаблонах за 127 календарных дней в пределах оценки в 60 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~3 дня Figma просмотрена, доступ к шаблону подтверждён, объём согласован Разработка доработок ~4 недели Постраничная доработка шаблона под Figma QA-итерации (параллельно) ~12 недель 20+ раундов QA; каждый закрыт только после согласования агентством Раунды исправлений ~2 недели Коррекции после проверки, отложенный контент, визуальные доработки Сдача финальный день Сайт запущен на Kinsta _Разработка и QA велись параллельно — это характерно для доработки темы, где ни один «этап QA» не закрывается полностью; цикл продолжается до согласования агентством._ ## Команда **Команда проекта** - **Наталия Богатель** — ведущий разработчик (доработка шаблона, перенос Figma в раскладку) - **Павел Сажин** — итерации QA и исправления - **Тимур Арбаев** — итерации QA и поддержка разработчика - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались за агентством на всём протяжении. Конечный клиент нас не видел: запросы на доработку шли через общую очередь задач агентства, и внутренняя сборка до него не доходила. Каждый раунд закрывался только после того, как проверяющий со стороны агентства подтверждал приёмку. ## Агентствам с библиотекой шаблонов > Вы боитесь не вёрстки, а того, что клиент поправит один цвет — и правка не разойдётся по сайту: страницы услуг останутся в старой палитре. А когда издатель шаблона выпустит обновление, ваши доработки сломаются без предупреждения, и лендинг вдруг начнёт отдавать ошибки. На сайте узкой стоматологии всё, что видит и чему доверяет пациент, решает слой шаблона: у этой практики — ортопедия и имплантация, где шаблон не был рассчитан на такую глубину услуг; у других — обычный каталог услуг, который ложится в исходную структуру шаблона. Подрядчику стоит задавать не вопрос «соберёте ли страницы по макетам», а вопрос «как вы сохраните эти доработки целыми, когда шаблон обновится?» Пришлите исходник или ID шаблона и ваш фирменный стиль. Мы сверим умолчания шаблона с вашим дизайном, отметим каждое место, где шаблон переопределит ваш бренд, и вернём смету с фиксированными часами. Сверка бесплатна; смету пришлём в часах, без диапазона. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-46-page-dental-blog-migration-42-days/ title: 46-страничная доработка стоматологической темы + миграция 145 постов блога type: case_study date: 2024-12-03T15:15:46+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 46 страниц брендированной стоматологической темы агентства, доработанных по макетам Figma для каждой страницы, плюс 145 унаследованных постов блога, перенесённых в шаблон Blog Post агентства — всё на WP Engine за 42 дня. В тестовой среде обнаружились контентные артефакты от предыдущих развёртываний темы: комментарии разработчиков на кириллице в коде слайдера и Lorem ipsum в данных виджетов Elementor. И то, и другое было выявлено и очищено до сдачи агентству. Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. Профиль QA ниже показывает, какой дисциплины это требует. ## Краткий обзор Поле Значение Отрасль конечного клиента Медицина — общая и косметическая стоматология Конечный клиент Drs. Chin and Pharar Dentistry (Las Vegas, Summerlin, NV) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированная тема агентства + постраничные макеты Figma на WP Engine) Объём **46 URL** — главная, 3 страницы «О нас», 30 услуг, 10 служебных страниц (формы пациентов, сберегательный план, FAQ, финансы, отзывы, подкасты, запись на приём, конфиденциальность), контакты, лендинг блога Перенесено постов блога **145** постов, перенесённых в шаблон Blog Post агентства (только сохранение URL — без претензий на перенос SEO-веса) Срок 42 дня (11 фев – 25 мар 2025), по графику Трудозатраты 62 часа на разработку, QA, управление проектом и циклы исправлений Команда 5 специалистов Шаблоны **7 переиспользуемых шаблонов** от агентства, все применены на 46 страницах (Homepage · About Us · Service Page · Default Template · Contact Us · Blog Lander · Blog) Технологии WordPress · Elementor · WP Engine · макеты в Figma для каждой страницы · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** Пункты очереди задач согласованы (структура URL, Lorem-ipsum, качество изображений, мобильное выравнивание) по контрольному списку из 49 пунктов; структура 301-редиректов на 36 URL тестовой среды **График взаимодействия** 6 задач от агентства · все закрыты к моменту сдачи (1 день активной фазы, 2025-04-01) **Раунды проверки** ≈4 раунда проверки за 42 календарных дня **Контрольный список запуска** 49 пунктов, согласован до переключения ## Постановка задачи Маркетинговое агентство из США открыло нам доступ к тестовой среде на WP Engine с уже развёрнутой брендированной стоматологической темой и постраничными макетами Figma для Drs. Chin and Pharar Dentistry. Работу по онбордингу клиента, сбору контента и настройке хостинга агентство уже закрыло само. Нам предстояло: довести тему до Figma, перенести 145 старых постов блога в шаблон Blog Post агентства и сдать сайт готовым к QA агентства и проверке клиента. Задача была чёткой: следовать Figma, сохранить структуру URL, зафиксированную агентством во вкладке Sitemap таблицы Google Sheets, и любые расхождения выносить в общую очередь задач агентства — не закрывать в одностороннем порядке. Агентству нужно было защитить целостность темы на всех стоматологических клиниках, которые её используют. Эта защита держится на дисциплине разработки: клиентские доработки должны оставаться в слое переопределений под конкретного клиента. Если изменение стиля попадёт в общий компонент — оно тихо разойдётся по всем остальным сайтам на той же теме. Кроме изоляции темы, на проекте был второй класс риска: тема, поработавшая у нескольких клиентов, накапливает артефакты — шаблонный текст, URL из стадии разработки и, в этом случае, языковые элементы из среды разработки темы, которые нужно вычистить из каждого клиентского развёртывания до сдачи. Проход Site Checker по всем данным Elementor, меню и виджетам подтвердил: тестовая среда чиста от этих артефактов, прежде чем мы вернули сборку агентству. > **Контекст рисков.** Брендированная тема, обслуживающая несколько стоматологических клиник, несёт в каждое новое развёртывание два класса риска: клиентские доработки, попадающие в общие компоненты и тихо расходящиеся по всем остальным клиникам на той же базе, — и накопившиеся артефакты: шаблонный текст, URL из стадии разработки, языковые остатки, которые не всегда видны при беглом осмотре в браузере. Оба риска были живы на этом проекте, и оба потребовали отдельной проверки перед сдачей. ## Как мы это сделали **1. Figma как контракт, тема как холст.** Файл Figma — спецификация дизайна. Брендированная тема агентства — базовая структура страниц. Наша задача — свести их страница за страницей: где стандартный макет темы совпадал с Figma, мы его оставляли; где Figma требовала отклонения — дорабатывали на клиентском уровне. Никаких дизайн-решений с нашей стороны. **2. Миграция блога в масштабе параллельно с доработкой темы.** Перенести 145 старых постов блога в шаблон Blog Post агентства — это не механический копипаст. Каждый пост должен лечь с сохранением URL по карте сайта агентства, с корректными метаданными и рабочими внутренними ссылками. Параллельное ведение миграции и доработки 46 страниц означало: любые решения по структуре URL основного сайта должны были учитывать, как будет разрешаться архив блога. Вкладка Sitemap в Google Sheets вела 198 строк — 46 страниц и 145 постов блога, плюс лист 301-редиректов на 36 сопоставлений, где структура тестовой среды должна была перенаправлять старые пути на нужные адреса. **3. Очистка артефактов как обязательная проверка.** Стоматологическая тема, поработавшая на нескольких клиниках, накапливает следы предыдущих развёртываний: шаблонный текст, сторонние изображения и иногда контент из среды разработки — правильный для внутреннего процесса сборки, но неприемлемый для конкретного клиента. На этом проекте QA-проход нашёл Lorem ipsum в компоненте слайдера и языковые остатки, пришедшие из общего слоя компонентов темы. Всё это было вычищено до сдачи — не выписано в задачу и не оставлено агентству, — потому что языковые проблемы в данных виджетов Elementor не всегда видны при беглом осмотре в браузере. Проход Site Checker прошёлся по страницам, постам, данным Elementor, меню и виджетам и подтвердил: тестовая сборка чиста. **4. QA-цикл через общую очередь задач агентства.** После начальной сборки QA шло через общую очередь задач агентства: агентство фиксировало расхождения по дизайну, проблемы с URL, замечания по качеству изображений и несоответствия мобильного выравнивания для нашего цикла исправлений. Единообразие завершающих слешей в URL оказалось одним из замечаний, потребовавших системного исправления по всей тестовой среде: спецификация карты сайта агентства не предполагала завершающих слешей на целевых внутренних ссылках, а начальная сборка их добавила. Исправлено и подтверждено до сдачи агентству. **5. Проверка на разных устройствах.** Каждый QA-раунд охватывал адаптивное поведение на большом экране, планшете и мобильных устройствах. Шаблон страниц услуг — применённый на 30 страницах — получил больше всего итераций: Figma содержала постраничные изображения и варианты секций, которые нужно было точно согласовать с адаптивными настройками темы. Постраничное сравнение с Figma и стало главной дисциплиной. 46 страниц на 7 шаблонах дали агентству единую базу для QA; кириллические комментарии в коде слайдера — пришедшие из общего слоя темы — проявились только потому, что проверка шла компонент за компонентом, а не по страницам целиком. ## Контроль качества QA выявило две проблемы до сдачи: кириллические комментарии в коде слайдера на главной — перенесённые из общего слоя темы и очищенные до того, как агентство увидело сборку, — и URL с завершающими слешами, не соответствующими спецификации карты сайта агентства, исправленные по всему сайту на 46 страницах тестовой среды. QA перед сдачей прошло через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Приёмочный контур агентства прошёл после сдачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений до их согласования. Доработки остались в переопределениях для каждого клиента; общие компоненты темы агентства не изменялись. ## Результаты Метрика Результат URL доставлено **46** — 1 главная · 3 страницы «О нас» · 30 услуг · 10 служебных · 1 контакты · 1 лендинг блога Перенесено постов блога **145** постов в шаблон Blog Post агентства с сохранением URL Применено шаблонов **7 из 7** переиспользуемых шаблонов собраны и распределены по 46 страницам Контрольный список запуска **49 пунктов** согласовано Решено проблем QA Единообразие завершающих слешей, Lorem ipsum, качество изображений, мобильное выравнивание — всё исправлено до сдачи Структура 301-редиректов **36 редиректов** отслежено и подтверждено во вкладке 301 таблицы Google Sheets Срок **42 дня**, доставлено по графику Трудозатраты **62 часа** на разработку, QA и исправления — в рамках оценки Команда **5 специалистов** Хостинг Запущено в среде темы WP Engine агентства Суть результата: Figma агентства была реализована на их брендированной теме — 46 страниц и 7 шаблонов, 145 унаследованных постов блога перенесены параллельно, за 42 календарных дня, в рамках оценённых часов — и сборка была чиста от языковых артефактов контента до сдачи. ## Процесс Фаза Длительность Результат Бриф и оценка ~3 дня Figma изучена, доступ к WP Engine тестовой среде подтверждён, объём согласован (оценка 50 ч) Доработка темы + миграция блога ~1 неделя 46 страниц доработано по Figma; 145 постов блога перенесено в шаблон Blog Post Итерации QA (параллельно) ~2 недели Проблемы из очереди задач агентства рассмотрены; структура URL, шаблонный текст, качество изображений исправлены Циклы исправлений ~1 неделя Мобильное выравнивание, корректировка размеров изображений, добавление контента на поздних этапах Сдача март 2025 Сайт подтверждён чистым на тестовой среде; передан агентству для финальной проверки _Разработка и QA выполнялись параллельно — характерно для работ по доработке темы, где итерации продолжаются от первой сданной страницы до финального согласования с агентством._ ## Команда **Команда проекта** - **Владимир Козлов** — ведущий разработчик (доработка темы, вёрстка по Figma, миграция блога) - **Никита Тумашевич** — разработчик (продолжение сборки после ведущей фазы Владимира Козлова) - **Анна Полунина** — этап QA и проверка очереди задач - **Наталия Богатель** — циклы исправлений и добавление контента на поздних этапах - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Дизайн агентства, хостинговая инфраструктура, контент-стратегия и отношения с клиентом оставались за рамками нашего участия на всём протяжении. Наша команда не имела прямого контакта с Drs. Chin and Pharar Dentistry. Запросы на доработку направлялись через общую очередь задач агентства; каждый раунд закрывался только после подтверждения исправления проверяющим со стороны агентства. ## Агентствам с библиотекой шаблонов > Для агентства, разворачивающего типовой шаблон под стоматологическую сеть, главный структурный риск — проектные доработки просачиваются в общие компоненты и переносятся на все остальные развёртывания. У этой сети — единая брендированная тема для всех филиалов; у других — независимые проекты на отдельных установках того же шаблона. Если не выстроить границу, доработки дочерней темы сломаются при первом же обновлении родительского шаблона автором. ACF-схема разойдётся — ваша команда потеряет управление структурой услуг на редакторском уровне. Контентные артефакты из стадии сборки — служебные URL, шаблонный текст — останутся в базе и проявятся только на аудите вашим клиентом. Подрядчику стоит задавать не «развернёте ли шаблон», а «как именно вы исключите просачивание доработок в общий код и контентного мусора в базу?» Пришлите исходник шаблона или его ID и спецификацию бренда текущей практики. Мы пройдёмся по ACF-схеме на расхождение с канонической структурой, найдём места, где клиентский слой пересекается с общим кодом, и отловим контентные артефакты. Вернём фиксированную смету в часах на изоляцию доработок. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-brightworks-17-days/ title: Ребилд стоматологического сайта на двух врачей — 64 часа за 17 дней type: case_study date: 2024-12-03T07:50:07+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду WordPress-ребилд стоматологического сайта на двух врачей: отдельные страницы-био для Dr. Preston Shurley и Patrice Robbins стояли рядом со страницами услуг, и каждая была своим типом контента — поэтому полнота шаблонов на каждом URL и стала главным ограничением. Полный ребилд на Elementor Pro мы сдали за 17 дней и 64 часа; проверка по каждому типу контента вскрыла обе страницы врачей в старом оформлении — это мы закрыли отдельным спринтом. Этот кейс — запись одного из таких ребилдов: агентство держало стратегию, мы — исполнение. ## Краткий обзор Поле Значение Отрасль конечного клиента Здравоохранение — общая стоматология Конечный клиент Brightworks Dentistry (Dr. Preston Shurley и Patrice Robbins) **Формат сотрудничества** **White-label WordPress-разработка для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress на Elementor Pro, хостинг WP Engine Объём работ Весь сайт — услуги, командные страницы для нескольких врачей, блог, контактные формы, PDF-загрузки Срок 17 дней (27 дек 2024 — 13 янв 2025), по графику Трудоёмкость 64 часа при оценке в 64 часа — без перерасхода Команда 5 специалистов (разработка · QA-исправления · PM) Техстек WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker ([xaverPRO](https://xaver.ru/) плагин QA) Проверка контентного паритета Сверка контента исходного и нового сайта перед сдачей — ни одного пропущенного фрагмента, ни одной битой внутренней ссылки, ни одного структурного отклонения **Сдано** **ТЗ исполнено строка-в-строку — редиректы, мета-заголовки, библиотека PDF, командные страницы для нескольких врачей, контрольный список запуска на 48 пунктов** **Раунды проверки** ≈2 раунда проверки в пределах 17-дневного календарного окна ## Постановка задачи Brightworks Dentistry — стоматологический кабинет с двумя практикующими специалистами. Агентство управляло веб-присутствием клиники и нуждалось в перестройке существующего WordPress-сайта на современном стеке Elementor Pro — более строгие шаблоны, надёжная интеграция Gravity Forms и библиотека PDF для загрузки, которая была приделана к старому сайту через обходные решения. Ребилд был проектом внутри той же CMS (WordPress → WordPress), что на бумаге выглядит проще, чем миграция на другую платформу. Агентство передало нам таблицу Google Sheets, охватывающую каждый URL для миграции, каждый мета-заголовок и описание для сохранения, каждый шаблон для применения и подробный контрольный список запуска. Задача была точной: исполнить ТЗ как написано, не выходить на прямой контакт с клиентом, уложиться в оценённые часы. На связи с клиентом всё время оставался руководитель проекта со стороны агентства. Мы работали внутри их системы координации. Агентство страховалось не от потери позиций в выдаче — SEO они вели сами и уже всё проработали. Риск заключался в передаче многодокторского ребилда команде разработки, которая относится к проекту внутри той же CMS как к малозначительной задаче. Ребилды внутри одной CMS несут специфический сценарий отказа: поскольку целевая платформа знакома, команда, работающая по наитию, может незаметно изменить мета-заголовок, перенаправить форму или пропустить редирект, который выглядит неважным. На однодокторском сайте одна пропущенная страница — это одна пропущенная страница. На сайте с двумя врачами, каждый из которых имеет отдельные био-страницы и командные страницы, на которые пациенты заходят напрямую, частичное применение шаблонов — менее заметный, но не менее разрушительный результат. > **Контекст рисков.** Ребилд внутри одной CMS на сайте с двумя врачами создаёт специфическую слепую зону: био-страницы специалистов — `/team/dr-preston-shurley/` и `/team/patrice-robbins/` — имеют собственный тип контента, и проход сборки, который покрывает страницы услуг без явного шаблонирования каждой докторской страницы, оставляет эти URL в оформлении старого сайта — визуально целыми на Screaming Frog-сканировании, но неверно. Dr. Shurley и Patrice Robbins имели отдельные командные страницы, которые входили в число наиболее посещаемых не-услуговых URL на старом сайте — таких, которыми пациенты делятся с членами семьи и на которые попадают направляющие специалисты. Ребилд, который корректно применяет новые шаблоны к страницам услуг, но оставляет био-страницы специалистов в старом оформлении, не выглядит сломанным при общесайтовом сканировании; он всплывает на этапе QA агентства, вызывая незапланированный корректирующий спринт. Это была не гипотеза — во время QA со стороны аккаунт-менеджера агентства обе докторские страницы всё ещё несли старый шаблон, что было зафиксировано как отдельная задача на исправление до переключения. Главным здесь было рассматривать каждый тип контента, а не только высокотрафиковый, как входящий в объём полного применения шаблонов. ## Как мы это сделали **1. Сборка через шаблоны.** Вместо восстановления всего сайта страница за страницей мы свернули его в переиспользуемые шаблоны, применённые ко всем типам контента: - Главная, О нас, Контакты и запасной Default - **Лендинг услуг + шаблон страницы услуг**, обслуживающий весь каталог услуг - **Шаблон страницы Врачи/Команда**, применённый к каждому специалисту — Dr. Shurley и Patrice Robbins, каждый с отдельной, единообразно оформленной био-страницей - **Шаблон блога** для текущего контента - **Страница библиотеки PDF** — загружаемые учебные материалы для пациентов, интегрированные непосредственно в структуру страниц, а не как внешние ссылки Шаблоны покрывали каждый тип контента. Будущие правки живут в одном месте на тип страницы. Мы выбрали шаблоны вместо сборки постранично, потому что структура с двумя специалистами и отдельными био-страницами делала межстраничную согласованность ключевым ограничением — ограничением, на которое постраничная спецификация агентства неявно опиралась, но которое явно не защищала. **2. ТЗ исполнено строка в строку, из таблицы агентства.** Таблица Google Sheets от агентства содержала каждый URL, каждый мета-заголовок и описание, каждое назначение шаблона и каждую заметку по интеграции — включая размещение PDF-файлов и цели Gravity Forms. Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где его не было — мы сообщили агентству. Никаких творческих интерпретаций не попало на сайт. Коротко: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. **3. Проверка через обход, а не «на глаз вроде нормально».** До переключения DNS мы прогнали Screaming Frog на старом рабочем сайте и сборке в тестовой среде параллельно. Коды статусов, битые ссылки, цепочки редиректов, различия в мета-тегах — каждое отклонение сверялось со спецификацией агентства. Второе сканирование после запуска подтвердило, что каждая внутренняя ссылка разрешается на рабочем домене. Сравнение также подтвердило, что пути загрузки PDF настроены корректно и био-страницы специалистов находятся на новом шаблоне. **4. Контрольный список запуска на 48 пунктов, закрыт до сдачи.** Категории охватывали точность дизайна, функциональность (формы, загрузки, навигация), точность контента, SEO и аналитику, адаптивный вывод на шести типах экранов и последовательность миграции домена и DNS на WP Engine. QA на разных устройствах гоняли в Chrome, Firefox, Safari и Edge. Ничего не уходило на сайт, пока не согласуют каждую строку. Именно шаблон страницы Врачи/Команда не дал структуре с двумя специалистами расколоться по типам контента. Без явного шаблона на каждую био-страницу эти URL остаются в оформлении старого сайта после того, как все страницы услуг получают новый дизайн — именно это и всплыло на этапе QA аккаунт-менеджера агентства — оба URL ушли в отдельную правку до переключения. Шаблонизировать каждый тип контента, а не только высокотрафиковый, — ограничение, которое спецификация подразумевала, но явно не устанавливала. ## Результаты Метрика Итог Точность спецификации — редиректы Все старые URL перенаправлены как указано Точность спецификации — мета-данные Все мета-заголовки и описания размещены как указано Точность спецификации — шаблоны Полная система шаблонов собрана и применена на всём сайте, включая страницы специалистов Точность спецификации — библиотека PDF Учебные PDF для пациентов загружены и корректно связаны на соответствующих страницах Контрольный список запуска 48 / 48 пунктов согласованы до переключения Срок **17 дней**, сдано по графику Трудоёмкость **64 ч / 64 ч** — без перерасхода, без расширения объёма Проверка адаптивности Ноль проблем с отображением на 4 браузерах × 6 типах экранов Внутреннее QA Все задачи в рамках агентства закрыты до сдачи; правки форм и ссылок на отзывы, всплывшие на QA агентства уже после запуска, закрыты отдельным спринтом Сдача Сайт запущен на WP Engine в запланированный день переключения, без простоя **Статус сайта** Работает, открывается по адресу https://www.brightworksdentistry.com/. Если коротко: ТЗ агентства мы исполнили как написано, в рамках оценённых часов, в запланированный день переключения. Отдельный спринт после QA агентства, прошедшего уже после запуска, закрыл оставшиеся пункты — сборка держала форму на всём протяжении. ## Контроль качества Сверка различий между старым сайтом и сборкой в тестовой среде выявила, что `/team/dr-preston-shurley/` и `/team/patrice-robbins/` всё ещё отображали дизайн старого сайта — каждая другая страница получила новый шаблон, только эти два URL выпали — и оба были зафиксированы как отдельная задача на исправление до переключения. QA перед сдачей прошло через **Site Checker** — категории и порог нулевых ошибок см. в [нашем подходе к QA](/site-checker/). Приёмочный контур агентства работал уже после сдачи и складывал замечания в общую очередь правок, которую мы закрывали до согласования. ## Процесс Этап Длительность Результат Бриф и оценка 1 день Спецификация агентства проверена; оценено и согласовано 64 ч Разработка ~12 дней Полный сайт перестроен по всем шаблонам, включая био-страницы специалистов Внутреннее QA и проверка 3 дня Вопросы зафиксированы; все работы в рамках агентства очищены до сдачи Проверка спецификации 1 день Meta, редиректы и пути PDF сверены с таблицей Доставка и переключение DNS 1 день Сайт запущен на WP Engine, без простоя _Этапы пересекаются (QA шёл параллельно с поздней разработкой), поэтому календарный срок составляет 17 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов, включая командные страницы нескольких врачей) - **Анна Полунина** — поддержка реализации и QA по перестроенным страницам - **Алексей Мелков** — поддержка реализации - **Иван** — разработчик поддержки (повторяющиеся блоки и дублирование страниц) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и SEO-стратегия оставались за партнёрским агентством на всём протяжении. Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на каждом этапе сборки и переключения. ## Агентствам, заказывающим ребилд WordPress > На ребилде в той же CMS структурная ловушка — охватить шаблоном каждый тип контента. У этой клиники это био-страницы врачей как отдельный тип записей; у других — сеть кабинетов под одним брендом. Ловушку трудно заметить. Вторичные страницы — био специалистов, библиотеки материалов — уедут в боевую среду на старых стилях. С них слетит разметка, и расширенные сниппеты, которые собрало агентство, пропадут из выдачи. Новые командные страницы, добавленные на втором месяце, не подхватят макет. Подрядчику стоит задавать не вопрос «соберёте ли страницы заново?», а вопрос «как именно вы охватите шаблоном каждый тип контента?» Пришлите адрес текущего сайта или макеты. Мы сверим инвентарь вашего контента с объёмом ребилда, найдём страницы, которые втихую уедут на старых шаблонах, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-dental-63h-140-days/ title: Разработка 27-страничного сайта стоматологии с несколькими филиалами на WordPress за 140 дней type: case_study date: 2024-11-27T07:55:22+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 27-страничный сайт стоматологии с несколькими филиалами по макетам Figma — две клиники под одним брендом, один домен, свои номера телефонов у каждого филиала. Кнопка звонка, которая на мобильном звонила только в один офис, — потерянная точка конверсии, а не мелкая неточность. Работа заняла 63 часа за 140 дней и шла по двум параллельным очередям QA — 75 SEO-замечаний от агентства и 29 пунктов по CX. ## Краткий обзор Параметр Значение Отрасль конечного клиента Стоматология Конечный клиент Alta Dental Group (Irvine, CA — два офиса) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка WordPress с Elementor на WP Engine, с этапом исправлений и согласования Объём **27 URL** — главная, о нас (2 страницы), контакты, услуги (лендинг), 17 страниц услуг, 4 страницы врачей, страница филиала, а также страница страхования, добавленная в процессе работы Сроки 140 дней (12 мая – 29 сен 2025), основная разработка и QA завершены в срок Трудоёмкость **63 часа** из запланированных 63 — без перерасхода Команда 5 специалистов (36 ч разработка · 12 ч QA · 10 ч PM · 5 ч контент и исправления) Шаблоны **9 переиспользуемых шаблонов** — стандартная библиотека шаблонов агентства для стоматологии (About Us, Blog, Blog Lander, Contact Us, Default, Doctor Page, Homepage, Service Page, Services Lander, Smile Gallery) Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Screaming Frog · Site Checker (плагин QA [xaverPRO](https://xaver.ru/)) **Результат** **27 URL на 7 активных шаблонах; 73/75 SEO-замечаний закрыто как Completed; 26/29 CX-замечаний закрыто как Completed; согласован контрольный список запуска из 29 пунктов** **Ритм взаимодействия** 75 замечаний от агентства · все закрыты к сдаче (85 активных дней, 2025-05-28 – 2025-08-20) **Раунды проверки** ≈10 раундов за 140 календарных дней **Контрольный список запуска** 29 пунктов, согласован до выхода в работу ## Постановка задачи Маркетинговое агентство из США, нанятое Alta Dental Group — стоматологической практикой с несколькими филиалами в Irvine, работающей под единым брендом — передало таблицу Google Sheets с полной картой URL, дизайн-файл Figma, каталог шаблонов, контрольный список запуска и предзаполненные QA-очереди задач. Разработка велась на их окружении WP Engine; конструктор страниц — Elementor; формы — Gravity Forms. Дизайн Figma содержал полную спецификацию бренда, включая анимацию перехода при прокрутке, которую клиент отметил ещё до начала разработки. Задача: собрать 27 URL по стандартной библиотеке шаблонов агентства для стоматологии, применить дизайн-спецификацию Figma ко всем страницам, наполнить страницы услуг контентом от агентства и отработать две параллельные очереди QA — SEO и CX — до приёмки сайта агентством. При этом не выходить на прямой контакт с конечным клиентом; спорное возвращать агентству; не импровизировать с контентом, навигацией или распределением звонков по филиалам. > **Контекст рисков.** Когда стоматологическая группа ведёт два офиса на одном домене, контактный слой должен корректно обслуживать оба филиала. Риск для агентства в такой разработке — не количество страниц, а детальная работа после их сдачи: мобильная кнопка звонка, требующая всплывающего окна выбора офиса вместо жёстко заданного номера; пачка контента для страниц услуг, поступившая с опозданием и требующая интеграции без нарушения уже запущенных в QA страниц; страница страхования, добавленная в навигацию после утверждения исходной карты сайта. Это не расширение объёма, а нормальная форма разработки для нескольких филиалов, требующая подрядчика, который доводит такие задачи до закрытия, а не считает первый проход финишной чертой. ## Как мы это сделали **1. 9 шаблонов, 27 страниц, единый процесс сборки.** Страницы Alta Dental Group распределились по стандартной библиотеке шаблонов агентства для стоматологии: Homepage, About Us (2 страницы — лендинг команды и дополнительная страница о нас), Contact Us, Services Lander, Service Page (17 отдельных страниц услуг, включая неотложную стоматологию, зубные импланты, эстетическую стоматологию, костную пластику и специализированные процедуры), Doctor Page (4 страницы врачей), Location и Default Template для страницы страхования, добавленной в процессе работы. Каждая страница построена на назначенном шаблоне из карты сайта; ни одна страница не создавалась вручную вне системы шаблонов. **2. Спецификация соблюдена построчно, в рамках согласованной сметы.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Самой трудоёмкой строкой была главная — она отражала спецификацию анимации; страницы услуг шли заметно легче после того, как сформирован начальный корпус контента. Мы реализовали всё в рамках этих значений. 12-часовая строка главной страницы была ключевой: дизайн Figma содержал анимации перехода при прокрутке, отмеченные клиентом, и их корректная реализация в стеке Elementor потребовала дополнительных итераций, которые бюджет строки предусматривал. Коротко: при разработке с заранее оценённой картой сайта таблица — это контракт. Задача команды — уложиться в согласованную смету, а не открывать заново разговор о цене, когда сложная страница требует больше календарного времени, чем стандартная шаблонная. **3. Пачки контента для страниц услуг приняли в процессе работы.** Исходная карта сайта несла ориентировочные оценки для страниц услуг в ожидании контента от агентства. В ходе работы поступили две пачки — сначала частичный набор, на котором собрали первые страницы услуг, затем вторая пачка, ради которой пришлось снова открывать готовые страницы и встраивать контент. Обе пачки приняли через отдельные задачи Redmine, отработали без роста бюджета, и каждая изменённая страница вернулась в очередь QA на повторную проверку перед приёмкой агентством. Поздний контент мы приняли в рамках исходной оценки, а не запрашивали продление сроков: бюджет закладывался под итеративную правку клиента — переносить сроки на каждую поставку контента значило бы подорвать модель фиксированных часов, которую выбрало агентство. **4. Распределение звонков по двум филиалам проверили при сдаче.** Ближе к концу проекта очередь QA выявила сбой маршрутизации: мобильная кнопка звонка по умолчанию вела на номер только одного офиса. Правка была не косметической — пришлось встроить в мобильную навигацию всплывающее окно выбора офиса, такое же, как в модальном окне «Call Us» на большом экране. Задача прошла два цикла QA до приёмки агентством, а страница страхования, добавленная в меню в тот же момент, закрылась в том же проходе QA. **5. Два параллельных цикла QA, закрытых до запуска.** Замечания отслеживали в двух очередях агентства — SEO (75 строк) и CX (29 строк). Из 75 SEO-пунктов 73 закрыты как Completed до выгрузки данных; 1 остался Info Needed и 1 — To Do, в ожидании ответа от агентства. Из 29 CX-пунктов 26 закрыты как Completed; 1 был In Progress и 2 — Info Needed на момент выгрузки. Контрольный список запуска из 29 строк — колонки Design, Functionality, Content, Pre-Migration, Post-Migration — согласован до выхода в работу. 12-часовая строка главной — самая трудоёмкая в карте сайта, со спецификацией анимации перехода при прокрутке — задала темп всей разработки: сначала решаем самую сложную страницу, затем принимаем пачки контента под страницы услуг в рамках оставшихся строк. Именно этот порядок позволил закрыть две поставки контента и правку распределения звонков по двум офисам в рамках исходной оценки в 63 часа. ## Результаты Метрика Результат Построено URL **27** на 7 активных шаблонах (1 Homepage · 2 About Us · 1 Contact Us · 1 Services Lander · 17 Service Pages · 4 Doctor Pages · 1 Location) Применено шаблонов **7 из 9** из стандартной библиотеки агентства для стоматологии (Smile Gallery и Blog Lander есть в библиотеке, но не в активной карте сайта) Очередь SEO **73 / 75** закрыто как Completed; 1 Info Needed, 1 To Do (ждут ответа агентства) Очередь CX **26 / 29** закрыто как Completed; 1 In Progress, 2 Info Needed (ждут ответа агентства) Контрольный список запуска **29 строк** — согласован по разделам Design / Functionality / Content / Pre-Migration / Post-Migration Распределение звонков Мобильное всплывающее окно для двух офисов проверено и принято через два цикла QA Сроки **140 дней** (12 мая – 29 сен 2025), основная разработка завершена в срок Трудоёмкость **63 ч из 63 запланированных** — без перерасхода, без расширения объёма Статус сайта, проверено 2026-04 Опубликован на WP Engine; боевой домен работает (Cloudflare отдаёт 403 на серверные запросы, в браузере открывается и отдаёт контент) ## Контроль качества Строка 30 очереди CX несла самую острую находку по маршрутизации за весь проект: мобильная кнопка звонка в правом верхнем углу была привязана только к одному офису. Пришлось сделать всплывающее окно выбора офиса и связать его с тем же модальным окном «Call Us», что уже работало на большом экране, — иначе пациенты звонили бы не в тот офис. QA перед сдачей шло через **Site Checker** — см. [наш подход к QA](/site-checker/): категории проверок и порог нулевых ошибок. Свой контур проверки у агентства шёл после сдачи и складывал замечания в общую очередь правок для нашего цикла исправлений, пока агентство не подписало приёмку. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Таблица изучена, дизайн Figma оценён, построчные часы утверждены, согласовано 63 ч Разработка (страницы + шаблоны) ~3 недели Все 27 URL собраны на 7 активных шаблонах в тестовой среде; открыты обе очереди QA Интеграция контента ~3 недели (параллельно с QA) Получены и встроены две пачки контента для страниц услуг; изменённые страницы возвращены в QA Согласование по QA (очереди SEO + CX) ~6 недель Обе очереди отработаны; распределение звонков по двум офисам проверено; страница страхования добавлена и закрыта Контрольный список запуска + сдача Последняя неделя 29 строк контрольного списка согласованы; сайт выведен в работу на WP Engine _Этапы пересекаются — пачки контента поступали во время первого QA-прохода, поэтому календарная длительность составила 140 дней, а не сумма отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик на этапах разработки и исправлений - **Павел Сажин** — управление проектом и QA-итерации - **Анна Полунина** — поддержка разработчика по интеграции контента страниц услуг и QA-раундам - **Тимур Арбаев** — QA-итерации и исправления - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались у партнёрского агентства на всём протяжении. Конечный клиент нас не видел. ## Агентствам, заказывающим разработку WordPress > На сайте стоматологической практики каталог услуг держит на себе всю выдачу, которую агентство выстроило: он задаёт URL-архитектуру и граф структурированной разметки. У этой практики профиль смешанный — общая стоматология и специализированные процедуры; у других чисто общая стоматология или узкоспециализированные центры. Боитесь вы тихих сбоев: новая услуга на шестом месяце не впишется в URL-схему, страницы с фильтрами перестанут отдавать то, что уже ранжируется, разметка слетит на импорте. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как именно вы построите таксономию, чтобы следующий вид услуг встал без миграции?» Мы закладываем таксономию так, чтобы за неё отвечать: пришлите рабочую таблицу сборки, черновик карты сайта или макеты — мы проверим, выдержит ли она добавление услуг и не выпадут ли страницы с фильтрами из индекса. Вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-58-page-dental-76-days/ title: Доработка стоматологического шаблона: 58 страниц за 76 дней type: case_study date: 2024-11-19T20:53:44+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 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](https://xaver.ru/)) **Подход к QA** **Более 75 отслеженных пунктов QA**, согласованных в системах проверки и журналах задач агентства **Раунды проверки** ≈4 раунда проверки за 76 календарных дней **Контрольный список запуска** 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](/site-checker/). Собственный 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](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом, дизайн и коммуникация с клиентом оставались на стороне партнёрского агентства на всём протяжении. Конечный клиент нас не видел: все запросы на доработку шли через общий журнал задач агентства, и сама сборка ему напрямую не показывалась. Каждый раунд QA закрывался только после подтверждения рецензентом агентства, что расхождение устранено. ## Агентствам с библиотекой шаблонов > Готовый шаблон должен ускорять сдачу. Но отвечать перед клиентом за пустую галерею и заглушку в индексе придётся вам, агентству, — и всплывёт это уже после запуска. У одной клиники это стандартный набор стоматологических страниц; у мультифилиальной сети это бренд-токены, которые перестают расходиться, едва первый филиал поправит цвет. Заготовки с Lorem ipsum уйдут в карту сайта, пустые галереи отдадут 404, а первое же обновление вендорского шаблона тихо сломает оплаченные вами доработки. Спрашивать подрядчика стоит не «соберёте ли страницы по шаблону», а «как именно вы отделите готовое от неготового и переживёт ли клиентский слой следующее обновление шаблона». Пришлите исходник шаблона или его ID и спецификацию бренда. Мы разберём, какие страницы рискуют уйти в публикацию пустыми, найдём состояния по умолчанию, способные просочиться как живой контент, и вернём фиксированную смету в часах. Аудит без оплаты. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-template-customisation-33-page-vascular-91-days/ title: Доработка 33 страниц сосудистого шаблона за 91 день type: case_study date: 2024-11-17T06:04:55+00:00 case_industry: Здравоохранение case_type: Шаблонная разработка case_practice: wordpress --- ## Подход к доработке темы 33 страницы для Veinology NJ свёрстаны на шаблоне Glowing — четырёхфилиальная сосудистая клиника в северном Нью-Джерси, где страницы Location и Areas We Serve не имели аналогов шаблона в исходной системе. Агентство передало нам Figma и предзаполненные страницы ACF, которые пришлось мигрировать в Elementor до начала доработки, увеличив оценку с 17,5 ч до 25 ч в процессе. Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля. ## Краткий обзор Параметр Значение Сфера деятельности клиента Медицина — сосудистая хирургия / флебология Конечный клиент Veinology NJ (Paramus, Ridgewood, Fair Lawn, Glen Rock, NJ) **Формат сотрудничества** **White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Доработка темы WordPress (брендированный шаблон агентства + постраничный дизайн в Figma, хостинг Kinsta) Объём **33 URL** — 1 главная, 2 страницы услуг, 14 страниц услуг/заболеваний, 4 страницы филиалов, 1 страница зон обслуживания, 1 страница врача, 1 «О нас», 1 контакты, 1 страница блога, 1 пост, 5 вспомогательных страниц Сроки 91 день (3 ноя 2025 – 2 фев 2026), по графику Трудозатраты 86 часов — разработка, итерации QA и управление проектом Команда 7 специалистов Шаблоны **11 переиспользуемых шаблонов** предоставлены агентством, все применены на 33 страницах Технологии WordPress · Elementor · Kinsta · постраничный дизайн в Figma · AutoQA агентства (Links / Email / Content AI / визуальные проверки) · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Подход к QA** **470+ отслеженных проблем SEO + CX** согласованы в очереди задач агентства (235 SEO + 236 CX) по контрольному списку запуска из 78 пунктов **Интенсивность взаимодействия** 9 вопросов от агентства · 8 из 9 закрыты к моменту сдачи (1 активный день, 2025-11-14) **Раунды проверки** ≈5 раундов на протяжении 91 календарного дня **Контрольный список запуска** 78 пунктов, согласованы до переключения ## Постановка задачи Маркетинговое агентство из США передало дизайн Figma для Veinology NJ и доступ к своей брендированной шаблонной системе на Kinsta. Агентство выполнило подготовительную работу: согласованный с клиентом дизайн, настройка хостинга и Google Sheets карта сайта с постраничным назначением шаблонов и ссылками на контент. Наша задача — взять Figma как единственный источник истины, перенести её на шаблон страницу за страницей для четырёхфилиальной сосудистой клиники и поддерживать цикл проверки столько, сколько потребуется для подписания. Задача была чисто исполнительской. Привести каждое отклонение от стандартных настроек шаблона к точному соответствию Figma — на 11 шаблонах, применённых 33 раза, без каких-либо дизайн-решений с нашей стороны. Таксономия услуг клиники охватывает заболевания вен (сосудистые звёздочки, варикозное расширение вен, хроническое венозное заболевание, венозная недостаточность, тромбоз глубоких вен, синдром беспокойных ног, отёк ног, боль в ногах, тяжесть в ногах) и методы лечения (радиочастотная абляция, EVLT-лазерная терапия, склеротерапия, косметическая склеротерапия, удаление сосудистых звёздочек) — все свёрстаны на отдельных страницах услуг с URL-структурой с привязкой к адресу офиса. Конкретным риском, которым управляло агентство, был дрейф между филиалами. На сайте с четырьмя офисами — Paramus, Ridgewood, Fair Lawn и Glen Rock — каждый использует один и тот же набор шаблонов, но требует уникальных адресных блоков, локальной маршрутизации телефонов и изображений для каждого офиса. Команда, применяющая доработки шаблона непоследовательно, создаёт фрагментированный результат, где страницы одного офиса выглядят качественно, а другого — как заглушки. В медицинской практике, где пациенты выбирают специалиста на основе близости и сигналов доверия, эта непоследовательность — проблема конверсии, а не косметики. Агентство наняло команду, которая держит один стандарт доработки на всех 33 страницах — от главной до самой глубокой страницы заболевания. > **Контекст рисков.** Четыре офиса, использующие один набор шаблонов, создают проблему единообразия, которую не видно по количеству страниц. Paramus, Ridgewood, Fair Lawn и Glen Rock — каждому нужен собственный адресный блок, маршрутизация телефонов и локальные изображения. Команда, которая применяет эти доработки по офисам с неравномерным подходом, создаёт сайт, где один офис выглядит готовым, а другой — как заглушка. В сосудистой практике, где пациенты выбирают врача по близости и доверию, эта неравномерность — проблема конверсии. Усугубляющий риск — загрязнение шаблона: доработка, просочившаяся из правки конкретного офиса в общий компонент, ломает все остальные практики на этом шаблоне. Агентство наняло нас, чтобы не допустить ни одного из этих сбоев ни на одной из 33 страниц. ## Как мы это сделали **1. Figma как контракт, шаблон как холст.** Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страниц. Наша задача — согласовать их постранично: где стандартная раскладка шаблона совпадала с Figma, мы её оставляли; где Figma требовала отклонения (hero-изображения для конкретного офиса, контентные блоки для конкретного заболевания, карточки врачей), мы дорабатывали. Никаких дизайн-решений с нашей стороны. Несколько страниц агентство создало заранее в своей ACF-структуре до передачи проекта нам; их перепривязка к доработкам в рамках страниц Elementor, а не перестройка из общего шаблона, добавила подготовительный аудит, не учтённый в начальной оценке. **2. Единообразие по нескольким офисам, один набор шаблонов.** Четыре офиса Veinology NJ — каждый со своей посадочной страницей и адресным блоком в общем шаблоне. Страницы филиалов — Paramus, Ridgewood, Fair Lawn, Glen Rock — построили на одном шаблоне Location, но с разным локальным контентом: адрес, телефон, встроенная карта и фотографии офиса. Страница Areas We Serve объединила четыре локации в единую географическую рамку. Размещение доработок по локациям в слое переопределений для конкретной страницы, а не в общем шаблоне, означало, что изменение одного города не просачивалось в другие. **3. Цикл QA в масштабе доработки темы.** Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Агентство отслеживало 470 отдельных проблем в двух вкладках очереди задач общего рабочего пространства — 235 SEO и 236 CX — каждую назначали, обрабатывали и закрывали только после согласования агентством. Такой объём — не признак нестабильности; именно это отличает сайт на шаблоне, выглядящий «приблизительно правильно», от того, что точно соответствует дизайну. Коротко: на шаблоне ценность даёт именно цикл QA. Кто срезает циклы ради скорости — теряет точность, а не время. **4. Доработка без дрейфа.** Каждое изменение брендированного шаблона — будь то раскладка страницы, компонент секции или стилевой токен — мы документировали относительно Figma. Контентные блоки страниц заболеваний, виджеты адресных блоков и карточки врачей дорабатывали в рамках страницы, а не в общем шаблоне. Мы выбрали доработку в рамках страницы вместо переопределений общего шаблона, потому что шаблонная система агентства обслуживала несколько клиентских сайтов; изменение общего слоя для одной сосудистой клиники распространило бы несвязанные изменения дизайна на следующую сборку на этом шаблоне. Работа по этому проекту не ухудшила шаблон для следующего сайта. **5. Проверка на разных устройствах.** Доработки проверяли в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые изменениями дизайна в этом раунде, а не весь сайт — так шаблонная сборка остаётся экономной без потери покрытия. Несколько страниц услуг были собраны в ACF ещё до передачи проекта нам; перепривязка их к доработкам на уровне страниц Elementor — вместо общих компонентов шаблона — добавила предварительный аудит, не включённый в начальную оценку. Именно этот проход удержал переопределения по офисам в нужных границах: когда каждая страница оказалась в области Elementor, Paramus, Ridgewood, Fair Lawn и Glen Rock получили независимые адресные блоки, маршрутизацию телефонов и локальные изображения без затрагивания общего слоя. ## Контроль качества Три замечания QA на этом проекте: Google Maps на страницах филиалов разрешались как `США` (кириллица) — обнаружено на страницах Fair Lawn и Paramus, исправлено на всех четырёх офисах; название сайта в RankMath всё ещё читалось как `dental-template10` из исходного шаблона, обновлено до запуска; и тонкое начертание текста на нескольких страницах заболеваний отклонилось от Figma, согласовано общесайтовым проходом. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и принцип нулевых ошибок. Свой контроль на стороне агентства работал после сдачи и фиксировал замечания в общей очереди задач для нашего цикла исправлений до окончательного согласования. Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись. Критерии приёмки AutoQA (Phone-Number / Links / Email / Content-AI / визуальные) — под управлением агентства — были настроены на этом проекте и запускались после сдачи как часть процесса согласования агентства. ## Результаты Метрика Результат URL сдано **33** — 1 главная, 2 страницы услуг, 14 страниц заболеваний/лечения, 4 страницы филиалов, 1 страница зон обслуживания, 1 страница врача, 1 «О нас», 1 контакты, 1 страница блога, 1 пост и 5 вспомогательных страниц Шаблонов применено **11 из 11** переиспользуемых шаблонов построены и распределены по 33 страницам Контрольный список запуска **78 пунктов** согласованы QA / SEO + CX-проблем отслежено и решено **470+** позиций согласовано по двум вкладкам очереди задач агентства (235 SEO + 236 CX) QA-итераций в Redmine **111 из 167 задач (66%)** отслежены на уровне итераций Сроки **91 день**, сдано по графику Трудозатраты **86 часов** — без перерасхода, без расширения объёма Команда **7 специалистов** Размещение Запущено в шаблонной среде агентства на Kinsta Состояние страниц при сдаче URL рабочего сайта возвращает HTTP 200 по независимой проверке Результат, коротко: Figma агентства была реализована на их брендированном шаблоне на 33 страницах и 11 шаблонах за 91 календарный день в пределах оценки в 86 часов. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Figma просмотрена, доступ к шаблону подтверждён, объём для нескольких городов согласован Разработка доработок ~4 недели Постраничная доработка шаблона; все 14 страниц заболеваний и 4 страницы филиалов собраны по Figma QA-итерации (параллельно) ~7 недель 470+ проблем по очередям задач SEO и CX заведены, обработаны, согласованы Раунды исправлений ~2 недели Коррекции после проверки, доработки контента по офисам, замена изображений Сдача финальный день Сайт запущен на Kinsta _Разработка и QA велись параллельно — это характерно для доработки темы, где ни один «этап QA» не закрывается полностью; цикл продолжается до согласования агентством._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (доработка шаблона, перенос Figma в раскладку) - **Павел Сажин** — итерации QA и исправления - **Анна Полунина** — поддержка доработки шаблона и QA - **Евгений Карпов** — поддержка разработки - **Тимур Арбаев** — поддержка разработчика по доработке страниц филиалов и поздние раунды - **Людмила Травкина** — проход QA и координация проверки перед сдачей - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Партнёрское агентство сохраняло полное владение управлением проектом, дизайн-решениями и отношениями с конечным клиентом на всём протяжении. Сборка была невидима для Veinology NJ — каждый запрос и подпись проходили через общую очередь задач агентства, и ни один раунд не закрывался до подтверждения их проверяющего. ## Агентствам с библиотекой шаблонов > Библиотека шаблонов для сети сосудистых центров ускоряет разработку, но создаёт риск: локальная доработка для одного филиала может просочиться в общий компонент. У этой практики — несколько отделений с собственными адресами и телефонами; у других — единая локация с общей контактной информацией. Если не изолировать доработки, правка для одного офиса сломает все страницы на шаблоне. Неравномерное QA оставит один филиал с актуальными данными, а остальные — со старыми, и контактные формы начнут уводить заявки не в то отделение. Подрядчику стоит задавать не вопрос «соберёте ли вы страницы по шаблону?», а вопрос «как именно вы изолируете локализацию для каждого филиала, не затронув общий слой?» Пришлите исходник шаблона (или его ID), спецификацию бренда и макеты. Мы проверим изоляцию доработок, найдём места, где доработка одного филиала может затронуть другие, и вернём фиксированную смету в часах. Аудит бесплатный. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-114-pages-37-days/ title: Ребилд стоматологического сайта WordPress на 114 страниц, сданный по спецификации за 37 дней type: case_study date: 2024-11-14T04:33:05+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду Ребилд стоматологического сайта на 114 страниц, сданный за 37 дней и 54 часа по карте сайта маркетингового агентства из США — 14 шаблонов, 29 реструктуризаций URL, 2 редиректа и контрольный список запуска из 78 пунктов, закрытый до сдачи. Анимация шапки исходного сайта багала с самого начала; команда перестроила её как аккуратный аккордеон и привела текст к единому начертанию, не перенося дрейф форматирования с исходника. ## Краткий обзор Параметр Значение Сфера деятельности клиента Медицина — общая и косметическая стоматология Конечный клиент Peak City Family Dentistry (семейная и косметическая стоматология, Apex, NC) **Формат сотрудничества** **White-label разработка WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Ребилд WordPress с Elementor Pro на Kinsta Объём Полный ребилд сайта — 114 URL перенесены с исходного на новый стек с реструктуризацией URL Сроки 37 дней (30 окт – 6 дек 2025), по графику Трудозатраты 54 часа при оценке 54 часа — без перерасхода Команда 4 специалиста (Никита Тумашевич — ведущий разработчик; Тимур Арбаев — QA; Павел Сажин — QA и исправления; Антон Херсун — руководитель проекта) Технологии WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) Проверка соответствия контента Сверка «оригинал и ребилд» пройдена до сдачи — ни одной пропущенной копии, ни одной битой внутренней ссылки, ни одного структурного дрейфа **Сдано** **Спецификация выполнена строка в строку — 114 URL перестроены, 29 изменений URL применены, 2 редиректа реализованы, 14 шаблонов использованы, контрольный список запуска из 78 пунктов закрыт** **Интенсивность взаимодействия** 3 вопроса от агентства · все закрыты к моменту сдачи **Раунды проверки** ≈4 раунда на протяжении 37 календарных дней **Контрольный список запуска** 78 пунктов, согласованы до переключения ## Постановка задачи У агентства был клиент — стоматологическая практика, — чей существующий сайт WordPress нуждался в ребилде: современный конструктор страниц, надёжные формы, аккуратная система шаблонов и более чистая структура URL. Агентство уже выполнило подготовительную работу: таблица Google Sheets с каждым URL для миграции, каждым назначением шаблона, каждым изменением URL и правилом редиректа, а также контрольный список запуска из 78 пунктов для этапов перед миграцией и после неё. Задача была конкретной. Взять спецификацию как есть; выполнить ребилд сайта на Elementor Pro; реализовать все интеграции; вернуть готовым к управляемому агентством переключению. Оставаться вне клиентского контура. Реализовывать SEO-решения как написано. Уложиться в согласованные часы. Для практики с двумя врачами, проходящей поэтапный ребилд — URL одного врача реструктурирован в объёме работ, второй отложен на этап после запуска — реальным риском для агентства была команда, которая отклоняется от спецификации: «незначительная» правка URL врача, шаблон, применённый не к тому типу страницы, редирект, пропущенный потому что казался необязательным. Риск заключался в передаче сборки подрядчику, который будет тихо импровизировать в обход брифа: пропущенный редирект, переинтерпретированный шаблон, «незначительная» правка мета-заголовка, перерасход бюджета, сдвиг окна запуска. В сумме на 114 страницах даже небольшие отклонения превращаются в крупную регрессию. > **Контекст рисков.** Когда переключение ребилда отложено — исходный сайт остаётся запущенным, а новая сборка ждёт на тестовой среде — сбой незаметен при сдаче. Он проявляется позже, когда агентство переключает DNS и реальный трафик попадает на URL, проверенные только изолированно. Изменение URL, корректное в таблице Google Sheets, встречается с закладкой пользователя. Мета-описание, совпадавшее на тестовой среде, расходится с оригиналом при реальной индексации. Риск не в самом ребилде — риск в том, что ребилд незаметно ломает при переключении DNS. ## Как мы это сделали **1. Шаблон-ориентированная сборка.** Вместо перестройки 114 страниц по одной мы свели их к 14 переиспользуемым шаблонам и разместили каждую страницу в соответствующем шаблоне: - Homepage, About Us, Contact Us и Default (16 страниц) - **Services Lander + Service Page** — основная структура клинических услуг, применена 23 раза по направлениям preventive, cosmetic, restorative и specialty dentistry - **Doctor Page** — индивидуальные страницы врачей (2 врача) - **Blog Lander + Blog** — архив постов и отдельные записи (63 поста, 1 страница архива) - **Smile Gallery** — шаблон «до/после» для данной практики - **Financing, Insurance, Payment Policy, Terms of Conditions, Payment Plan / Membership** — страницы операционной деятельности практики 14 шаблонов, 114 страниц сданы. Будущие правки на стороне агентства живут в одном месте на тип страницы. **2. Спецификация выполнена строка в строку, из таблицы агентства.** Агентство передало таблицу Google Sheets: каждый URL для миграции с целевым путём, каждое назначение шаблона, каждое изменение URL (29 строк), каждое правило редиректа (2 строки), каждое указание на удаление (2 строки) и 15 пунктов после запуска. Мы реализовали каждую строку как написано. Где в таблице было значение — оно попало на новый сайт. Где не было — мы сообщили агентству. Никаких «творческих интерпретаций» в сборку не пошло. Коротко: на ребилде спецификация — это контракт между агентством и его клиентом. Работа команды разработки — защищать этот контракт, а не редактировать его. **3. Проверка на основе обхода, а не «на глаз нормально».** До сдачи тестовой среды мы прогнали Screaming Frog на исходном рабочем сайте и сборке на тестовой среде параллельно. Статус-коды, битые ссылки, цепочки редиректов, расхождения мета-тегов — каждое отклонение сверено со спецификацией агентства. Контрольный список запуска из 78 пунктов — Design, Functionality, Content, SEO & Analytics, Responsive, интеграции под клиента и Domain & DNS — закрыт после проверки обходом. **4. Контрольный список запуска на 78 пункта, закрыт до сдачи.** Семь категорий, покрывающих все поверхности, которые могут регрессировать при переключении: точность дизайна, функциональность, точность контента, SEO и аналитика, адаптивность, интеграции под клиента и раздел миграции Domain & DNS. Ничего не сдавали, пока не согласовали каждую строку. QA на разных устройствах в Chrome / Firefox / Safari / Edge на шести разрешениях. Решение с аккордеоном — вот где внимание к детали и сыграло. В исходной анимации шапки была встроенная ошибка — трёхуровневая логика подменю, проявившаяся на первом же проходе QA и не имевшая простого решения в Elementor. Вместо переноса сломанного взаимодействия мы перестроили его как чистый аккордеон — и защитили спецификацию тем, что не воспроизвели ошибку оригинала. ## Результаты Метрика Результат Соответствие спецификации — URL перестроено **114 / 114** контентных URL возвращают HTTP 200 на тестовой среде до сдачи Соответствие спецификации — изменения URL **29 / 29** строк изменения URL реализованы как указано Соответствие спецификации — редиректы **2 / 2** правила редиректов реализованы как указано Соответствие спецификации — шаблоны **14 / 14** шаблонов созданы и применены на всём сайте Контрольный список запуска **78 / 78** пунктов согласованы до сдачи Сроки **37 дней**, сдано по графику Трудозатраты **54 ч / 54 ч** оценка — без перерасхода, без расширения объёма Адаптивная проверка Ноль проблем с отображением на 4 браузерах × 6 разрешениях Внутреннее QA Все вопросы в рамках агентства закрыты до сдачи (3 SEO + 3 CX; остальные — задачи под управлением агентства после запуска) Сдача Ребилд сдан на тестовую среду агентства на Kinsta, готов к управляемому переключению Состояние сайта, проверено 2026-04 Исходный сайт [peakcitydentistry.com](https://www.peakcitydentistry.com/) ещё запущен; ребилд на тестовой среде ожидает переключение от агентства Если коротко: спецификация агентства реализована как написано, в пределах согласованных часов, в запланированную дату сдачи. Ребилд находится на тестовой среде Kinsta, проверен и готов к переключению. ## Контроль качества Аудит ссылок Site Checker выявил общесайтовую проблему внутренних ссылок до сдачи — каждая страница сборки содержала ссылку на `/page/dental-specialties/`, которая теперь вела как 301 на `/cosmetic-dentistry/`, отмечено по всей сборке на тестовой среде до того, как агентство её увидело, и направлено на исправление. QA перед сдачей выполнялось через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порог нулевых ошибок. Свой проверочный контур агентства работал после сдачи и собирал замечания в общую очередь правок для нашего цикла исправлений до окончательного согласования. ## Процесс Этап Длительность Результат Бриф и оценка 2 дня Спецификация агентства просмотрена; 54 ч согласованы Разработка ~18 дней Весь сайт перестроен на 14 шаблонах; 29 изменений URL и 2 редиректа реализованы Внутреннее QA и проверка ~10 дней 6 задач заведены и закрыты; проверка обходом завершена Проверка спецификации 2 дня Мета и редиректы сверены с таблицей; контрольный список из 78 пунктов закрыт Сдача и передача на тестовую среду 1 день Ребилд сдан на тестовую среду Kinsta, готов к управляемому переключению _Этапы перекрываются (QA шёл параллельно с завершением разработки), поэтому календарный срок составляет 37 дней, а не сумму отдельных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Тимур Арбаев** — раунды QA и проверка точности ребилда - **Павел Сажин** — исправления QA и реализация мета-данных - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Агентство оставалось публичным подрядчиком; конечный клиент нас не видел на всём протяжении планирования переключения и проверки тестовой среды. Все решения по сохранению URL и стратегии редиректов принадлежали агентству; наша роль — точность исполнения поставленной спецификации. ## Агентствам, заказывающим ребилд WordPress > Заказывая ребилд стоматологического сайта, ваше агентство принимает риск, который незаметен на тестовой среде — он проявится при переключении DNS. У этой практики — сложная таксономия услуг и врачей со сложившимися URL; у других — плоский каталог страниц. Три сценария, за которые вам придётся отвечать перед клиентом: в карте редиректов потеряются строки — старые URL, под которые вы выстроили позиции, после переключения отдают 404; мета-заголовки и описания тихо переписаны — сниппеты в выдаче меняются без вашего ведома; внутренние якорные ссылки ломаются — новая архитектура обрезает навигационные пути, по которым ходит трафик. Подрядчику по ребилду стоит задавать не вопрос «сделаете ли перенос?», а вопрос «как именно вы сверите полный инвентарь URL и мета-тегов до переключения трафика?» Пришлите адрес текущего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим ваш текущий ранжированный набор URL с будущей структурой, найдём строки, которые отвалятся при переключении, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-rebuild-dental-sugar-land-20-days/ title: Ребилд стоматологического сайта на 31 URL с миграцией путей блога type: case_study date: 2024-11-08T21:49:13+00:00 case_industry: Здравоохранение case_type: Ребилд case_practice: wordpress --- ## Подход к ребилду 31 URL на 15 шаблонах Elementor Pro, собранные по спецификации в Google Sheets, которая перенесла двенадцать постов блога с корневых путей в поддиректорию `/blog/` — каждый старый URL требовал соответствующего 301 редиректа. Агентство предоставило карту URL и список редиректов; мы взяли на себя выполнение по каждому шаблону, внутренний раунд QA и проверку миграции. Сдали за 20 дней, 49 часов, без превышения. ## Краткий обзор Поле Значение Индустрия конечного клиента Медицина — Семейная стоматология Конечный клиент Oasis Dental (Dr. Sagar Amin, DDS, Sugar Land, TX) **Формат сотрудничества** **White-label WordPress ребилд для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта WordPress ребилд с Elementor Pro на WP Engine Объём работ Полный сайт — главная, о нас, команда, биография врача, 7 страниц услуг, блог (12 постов перенесены в `/blog/`), контакты, галерея улыбок, membership, спецпредложение для новых пациентов, политика конфиденциальности Сроки 20 дней (14 апр – 4 мая 2025), по графику Трудозатраты 49 часов при оценке в 49 часов — без превышения Команда 5 специалистов Технологии WordPress · Elementor Pro · WP Engine · Yoast · TrustIndex (виджет отзывов) · Screaming Frog · Site Checker (QA-плагин [xaverPRO](https://xaver.ru/)) Проверка контента на соответствие Сравнение контента оригинал-ребилд пройдено перед передачей — нет пропущенного текста, нет битых внутренних ссылок, нет структурных расхождений **Сдано** **ТЗ выполнено построчно — 31 URL на 15 шаблонах, реструктуризация URL блога, контрольный список запуска на 29 пунктов** **Динамика сотрудничества** 13 задач от агентства · все закрыты к передаче (16 дней активной работы, 2025-05-01 – 2025-05-16) **Раунды проверки** ≈3 раунда проверки за 20 календарных дней **Контрольный список запуска** 29 пунктов, согласовано перед переходом ## Постановка задачи У маркетингового агентства из США был стоматологический клиент на абонентском обслуживании — семейная практика в Sugar Land, TX, с одним ведущим стоматологом и мультисервисным предложением (Cosmetic Dentistry, General Dentistry, Implant Dentistry, Preventative Dental Care, Sedation Dentistry, Laser Dentistry, Emergency Dental Care и Invisalign) — чей существующий сайт на WordPress требовал ребилда на WP Engine. Агентство выполнило подготовительную работу: карту сайта, охватывающую каждый существующий URL и его целевой путь, список шаблонов, мета-заголовки и описания для каждой страницы, а также контрольный список запуска, организованный по категориям: дизайн, функциональность, контент и SEO-проверка. Один структурный выбор в таблице Google Sheets оказался более значимым, чем казалось на первый взгляд. Существующие посты блога практики находились на корневых путях (например, `/expert-tips-for-preventing-cavities/`, `/how-to-avoid-gum-disease/` и так далее). Спецификация ребилда перенесла все двенадцать в поддиректорию `/blog/`. Каждый старый путь поста требовал соответствующего 301 редиректа на новый адрес `/blog/slug/`. Лендинг блога и путь `/meet-the-doctor/` также были отмечены в спецификации для коррекции URL. Адаптивная вёрстка исходного сайта — особенно на мобильных устройствах и планшетах — накопила достаточно проблем с отступами и точками адаптации, что сохранять её было нецелесообразно; эти экраны были перестроены с нуля под фирменный стиль практики, а не перенесены с оригинального сайта. > **Контекст рисков.** Когда ребилд переносит структуру URL блога с корневых слагов в поддиректорию `/blog/`, каждая существующая внешняя ссылка, каждая закладка и каждый проиндексированный путь в поисковых системах указывают на старые корневые URL. Редирект, который тихо срабатывает неверно — выдавая цепочку 301 с двойным проходом через главную или пропуская нормализацию слеша в конце — проходит визуальную проверку и обнаруживается только при обходе или всплеске 404 после запуска. Спецификация покрывала полный список миграции; наша работа заключалась в том, чтобы закрыть разрыв между «в спецификации указан редирект» и «сервер отдаёт 301 на правильный адрес». ## Как мы это сделали **1. Сборка на основе шаблонов.** Вместо того чтобы перестраивать 31 URL по одному, мы свели их к 15 переиспользуемым шаблонам и разместили каждую страницу в них: - **Главная** — главная конверсионная страница, со встроенной картой, заглушкой виджета отзывов и ссылками на адрес - **О нас** — история и ценности практики - **Команда** — сетка команды (URL перестроен с устаревшего hash-fragment пути на чистый `/meet-the-team/`) - **Страница врача** — биография ведущего стоматолога (Dr. Sagar Amin, DDS) - **Лендинг услуг** — точка входа в категорию - **Страница услуги** — единый переиспользуемый шаблон для 7 страниц услуг: Cosmetic Dentistry, Emergency Dental Care, General Dentistry, Implant Dentistry, Invisalign, Laser Dentistry, Preventative Dental Care и Sedation Dentistry - **Лендинг блога** — архив (`/blog/`) - **Блог** — шаблон отдельного поста (12 постов, все перенесены в поддиректорию `/blog/`) - **Контакты** — страница контактов с формой обратной связи - **Галерея улыбок** — фотогалерея пациентов (`/gallery/`) - **Membership-страница** — обзор плана membership - **Спецпредложение для новых пациентов** — промо-страница - **Политика конфиденциальности** — стандартная юридическая страница - **Стандартный шаблон** — вспомогательные страницы 15 шаблонов — весь сайт сдан. Будущие правки со стороны агентства живут в одном месте на каждый тип страницы. **2. ТЗ выполнено построчно, из таблицы агентства.** Агентство передало нам таблицу Google Sheets: каждый URL для миграции с новым путём, каждый мета-заголовок и описание, назначение каждого шаблона и вкладку Settings с URL сайта и тестовой среды. Мы реализовали каждую строку как написано. Миграция блога в особенности требовала точности: двенадцать слагов постов получили префикс `/blog/`, а колонка Action в таблице Google Sheets помечала каждый как «URL Change». Мы реализовали редиректы в точности как указано — без интерпретации, без перенаправлений. Принцип прост: при ребилде спецификация — это контракт между агентством и его клиентом. Задача команды разработки — защищать этот контракт, а не редактировать его. **3. Проверка обходом, а не «на глаз нормально».** Перед передачей мы запустили Screaming Frog на тестовой среде ребилда. Каждый URL из карты сайта проверили на ожидаемый статус-код. Миграция блога проверялась не просто на наличие редиректа, а на точность назначения — каждый редирект `/old-slug` должен чисто разрешаться в `/blog/old-slug`, а не проходить цепочкой через главную или падать в 404. Одну ссылку на пост, ведущую на несуществующую запись, поймали на внутренней проверке и исправили до передачи сборки агентству. Обход после передачи подтвердил, что все внутренние ссылки корректно разрешаются на рабочем сайте. **4. Контрольный список запуска на 29 пунктов, закрыт до передачи.** Четыре категории: дизайн, функциональность, контент и SEO & Analytics. QA на разных устройствах — Chrome, Firefox, Safari и Edge на шести экранах (1920 / 1280 / 1024 / iPad / портретный и альбомный мобильный). QA-команда агентства провела параллельную проверку и выявила небольшую очередь задач с дополнительными пунктами — коррекция H1 на всём сайте, включение страниц услуг в карту сайта в Rank Math, встраивание карты Google Maps в футер и мобильные отступы — все были решены в раунде исправлений до запуска сайта. **5. Раунд исправлений после передачи — интеграция TrustIndex.** После запуска агентство заказало дополнение на одну задачу: реализацию блока отзывов TrustIndex на главной странице и странице спецпредложения для новых пациентов. Виджет интегрировали отдельной отслеживаемой задачей, приняли в течение недели. Миграция URL блога задавала порядок работ: карту редиректов нужно было подтвердить до завершения визуальной сборки, потому что тихий отказ редиректа проходит визуальную проверку и обнаруживается только при обходе. Запуск Screaming Frog до передачи — не для формальности, а по полной спецификации на 31 URL — был той самой проверкой, которая закрыла разрыв между «в спецификации указан 301» и «сервер его отдаёт». ## Результаты Метрика Результат Точность ТЗ — миграция URL **31 / 31** страниц и постов перенесены на указанные пути Точность ТЗ — реструктуризация блога 12 постов блога перенесены с корневого уровня в поддиректорию `/blog/` с 301 редиректами Точность ТЗ — шаблоны **15 / 15** шаблонов созданы и применены на всём сайте Контрольный список запуска **29 пунктов** проверены и согласованы перед переходом Очередь задач QA агентства 13 пунктов отслежены и решены в общей очереди задач (вкладки SEO + AM QA) Сроки **20 дней**, сдано по графику Трудозатраты **49 ч / 49 ч** по оценке — без превышения, без расширения объёма Проверка адаптивности Ноль проблем с вёрсткой на 4 браузерах × 6 экранах Дополнение после запуска Виджет отзывов TrustIndex интегрирован на главную и страницу спецпредложения для новых пациентов в течение 1 недели **Статус сайта** Работает на WP Engine, открывается по адресу https://www.oasisdentaltx.com/. Если коротко: спецификация агентства реализована как написано, структура URL блога перенесена без битых путей, а сотрудничество завершено по графику в рамках согласованных часов. ## Контроль качества Внутреннее QA на тестовой среде выявило один пост блога, ведущий на несуществующую запись, в ходе миграции 12 постов с корня в `/blog/` и пометило его до передачи сборки; проверка таблицы Google Sheets агентства затем выявила ошибки H1 на всех страницах и пять несоответствий URL-путей карте сайта — все помечены высоким приоритетом и закрыты до перехода. QA до передачи проводилось через **Site Checker** — см. [наш подход к QA](/site-checker/) о категориях и пороге нулевых ошибок. Собственный QA-контур агентства работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений, пока они не подписали приёмку. ## Процесс Фаза Длительность Результат Бриф и оценка 1 день Спецификация агентства рассмотрена; оценка 49 ч согласована Разработка ~14 дней Полный сайт перестроен на 15 шаблонах на тестовой среде WP Engine Внутреннее QA и проверка 3 дня Миграция URL блога проверена; пункты очереди задач QA агентства обработаны Проверка ТЗ 1 день URL-редиректы сверены с таблицей; обход подтверждён Сдача и DNS-переход 1 день Сайт запущен на WP Engine, без простоев Дополнение после запуска ~1 неделя Виджет TrustIndex интегрирован и принят _Фазы перекрываются (QA шёл параллельно с завершающей разработкой), поэтому календарный срок — 20 дней, а не сумма отдельных фаз._ ## Команда **Команда проекта** - **Никита Тумашевич** — разработчик (интеграция TrustIndex после запуска) - **Павел Сажин** — QA и коммуникация с агентством - **Анна Полунина** — поддержка разработки и QA по страницам ребилда - **Людмила Травкина** — ведущий разработчик (полная сборка сайта и система шаблонов) - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, приёмка) Агентство оставалось публичным подрядчиком на всём протяжении; наша команда оставалась невидимой для конечного клиента. Решения по архитектуре URL — какие пути создавать, как настраивать редиректы слагов блога, какой контент переносить — принадлежали агентству. Мы реализовали эти решения в точности как указано. ## Агентствам, заказывающим ребилд WordPress > При ребилде стоматологического сайта архитектура переезжает под новую крышу — а рейтинги двигаются вместе с ней. У этой стоматологии один кабинет; у других — сеть клиник с общей системой бренда. Мета-заголовки и описания, которые вы выверяли, новая тема тихо перепишет — сниппеты в выдаче поменяются за ночь. Разметка ваших медицинских специализаций не перенесётся, и расширенные сниппеты, которые вы выстроили, пропадут из Google. Старые страницы для пациентов вместо переадресации упрутся в 404 — заработанный трафик просто оборвётся. Подрядчику стоит задавать не вопрос «перенаправите ли адреса?», а вопрос «как именно вы сохраните каждую точку входа — от редиректов до структурированной разметки — после переключения?» Пришлите адрес действующего сайта, черновик карты редиректов (если есть) или макеты. Мы сверим старые URL с новыми маршрутами, найдём каждую страницу, где редиректы, мета или разметка оставят вам провал в выдаче, и вернём фиксированную смету в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/case/white-label-wordpress-build-pediatric-dental-51h-75-days/ title: 31 страница детской стоматологии на WordPress за 75 дней type: case_study date: 2024-11-04T14:05:18+00:00 case_industry: Здравоохранение case_type: Разработка case_practice: wordpress --- ## Подход к разработке 31 страница сайта детской стоматологии и ортодонтии, перенесённая из тестовой среды Webflow в WordPress, — 6 шаблонов, структурное сопоставление 2 движков рендеринга, а не визуальное копирование. H1 на 19 страницах услуг был собран из 2 вложенных `div`-элементов в Webflow; его воспроизведение в Elementor потребовало явного SEO-узла шириной 0px плюс видимый заголовок на каждой странице — иначе мета-заголовок незаметно разошёлся бы с указанным в карте сайта. На сайте детской стоматологии и ортодонтии такая структурная точность возрастает: две линейки услуг (общая детская стоматология и ортодонтическое лечение детей, подростков и взрослых) работают на одном шаблоне страницы услуг, и каждая линейка ведёт к своему CTA и своей форме. Перенос, который выглядит правильно визуально, но оставляет CTA для записи на консультацию на странице детской чистки — или наоборот, — не заявит о себе ни в одном логе сборки. ## Краткий обзор Параметр Значение Индустрия конечного клиента Медицина — детская стоматология и ортодонтия Конечный клиент ChildSmiles OC (Fullerton, CA) **Формат сотрудничества** **White-label разработка на WordPress для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса** Тип проекта Новая разработка на WordPress с Elementor на WP Engine, перенос из тестовой среды Webflow Объём **31 URL** — главная, о нас, 2 страницы врачей, блог, 19 страниц услуг (разделены на линейки детской стоматологии и ортодонтии), контакты, рекомендации, программа лояльности, ресурсы для родителей, первый визит, страница благодарности, политика конфиденциальности Сроки 75 дней (24 марта – 7 июня 2025), сдано в срок Трудоёмкость **51 час** по смете на 51 час — без перерасхода Команда 4 специалиста (27 ч разработка · 10 ч QA · 10 ч PM · 4 ч исправления — объём QA и исправлений адекватен для переноса из Webflow в WP с двухуровневой архитектурой услуг) Шаблоны **6 переиспользуемых шаблонов** — главная, о нас, блог, страница врача, страница услуги, стандартный шаблон Технологии WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Site Checker (плагин QA от [xaverPRO](https://xaver.ru/)) **Результат** **31 URL в 6 шаблонах, контрольный список запуска из 29 пунктов закрыт, 45/60 задач SEO + 6/8 задач AM выполнены к моменту передачи** **Интенсивность взаимодействия** 60 правок от агентства — все закрыты к передаче (20 дней активной работы, 2025-04-20 – 2025-05-09) **Раунды проверки** ≈3 раунда за 75 календарных дней **Контрольный список запуска** 29 пунктов, согласован до переключения ## Постановка задачи ChildSmiles OC — это детская стоматологическая и ортодонтическая клиника в Fullerton, California. Она принимает детей по общей стоматологии и пациентов всех возрастов по ортодонтии. Маркетинговое агентство из США, специализирующееся на сайтах для локального бизнеса, управляло проектом: они владели дизайном (сайт в Webflow служил визуальным ориентиром), контент-стратегией, настройками хостинга на WP Engine и отношениями с клиентом. Наша задача состояла в том, чтобы взять дизайн из Webflow, реализовать его в WordPress с Elementor и передать готовый к запуску сайт, совпадающий с исходным дизайном на каждой странице и в каждой точке адаптации. Таблица Google Sheets структурировала проект на 31 активный URL (24 запланированные сборки плюс 7 страниц, скрытых в окне первого запуска), привязанных к 6 шаблонам из стандартной библиотеки агентства. Объём по каждой строке карты сайта мы оценили сами — в сумме 51 час. Задача: собрать все страницы, подключить формы к правильным email-адресам, корректно выставить мета-теги и H1 по требованиям из карты сайта, отработать две очереди задач QA и закрыть контрольный список запуска до передачи. Дизайн, контент, SEO-стратегия и коммуникация с клиентом оставались за агентством. > **Контекст рисков** — Детская стоматология и ортодонтия ведут два пути пациента на одном сайте и в одном наборе шаблонов. Агентство искало партнёра-разработчика, который сохранит структурное разделение двух линеек услуг. Перенос из Webflow в WordPress, при котором страницы «выглядят правильно» без проверки структурной карты, может выдать сайт, который даст сбой на первом органическом клике. ## Как мы это сделали **1. 6 шаблонов, 31 страница, один процесс — сборка из исходного дизайна в Webflow.** 31 активную страницу мы разнесли по стандартной библиотеке шаблонов агентства: главная (1), о нас (1), страница врача (2 — по одному на каждого специалиста), блог (1), страница услуг (самая объёмная — 19 страниц, включая обе линейки) и стандартный шаблон для вспомогательных страниц (контакты, программа лояльности, ресурсы для родителей, первый визит, рекомендации, благодарность, политика конфиденциальности). Каждую страницу сопоставили её шаблону из строки карты сайта — ещё до первой строки кода Elementor. **2. Структурное сопоставление Webflow и Elementor, а не визуальное копирование.** Исходный дизайн представлял собой сайт в Webflow (тестовая среда), а не файл Figma. Webflow и Elementor выражают одинаково выглядящие макеты разными структурными примитивами — в данном случае H1 на нескольких страницах услуг был собран из двух вложенных `div`-элементов в Webflow (приём, который невозможно воспроизвести простым виджетом заголовка Elementor без расхождения с SEO-требованиями). Мы выявили эти структурные различия на раннем этапе, явно их задокументировали и подтвердили, что отображаемый H1 совпадает с колонкой постраничных SEO-метаданных из таблицы Google Sheets, прежде чем страница покидала тестовую среду. Мы выбрали явное пошаговое структурное сопоставление, а не визуальное сравнение, потому что расхождение между Webflow и Elementor было невидимо при просмотре скриншотов, но моментально обнаруживалось при аудите SEO-данных. На сайте с двумя линейками услуг, где каждая страница услуг через H1 влияла на мета-заголовок, незаметное расхождение не заявило бы о себе до запуска. **3. Согласованная смета как контракт.** Карту сайта дало агентство; объём в часах по каждой строке мы оценили сами и зафиксировали до старта. Наша задача — уложиться в смету без пересмотра по ходу. Общая сумма составила согласованный 51 час. **4. Два контура QA, отработаны до запуска.** Правки отслеживали в двух очередях на стороне агентства: очередь правок SEO (60 строк, приоритеты от низкого до высокого) и очередь правок AM (8 строк). Из 60 SEO-пунктов 45 закрыли как выполненные до запуска; 10 оставались в QA в ожидании подписи; 1 требовал уточнения. Все 6 применимых пунктов AM закрыли как выполненные. Контрольный список запуска из 29 пунктов — дизайн, функциональность, контент и SEO — закрылся после обеих очередей. Сборка H1 из 2 вложенных div-элементов в Webflow — приём, формирующий заголовок на 19 страницах услуг, — стала структурным разрывом, вокруг которого держалась вся остальная сборка. Мы подтвердили верную интерпретацию H1 до того, как написали хотя бы 1 шаблон Elementor, — и в очередях правок QA не появилось ни одного структурного исправления; после передачи всплыли только правки макета и контента. ## Контроль качества Нагрузка QA разделилась на две категории — структура URL и карта H1: очередь правок AM выявила непоследовательные завершающие слеши в дереве URL до переключения, а чат по сборке вскрыл сборку H1 из двух вложенных div-элементов в Webflow («слепили они H1 из 2-х Div»), потребовавшую явного SEO-узла шириной 0px плюс видимого заголовка ACF на всех 19 страницах услуг. QA перед передачей проводили через **Site Checker** — см. [наш подход к QA](/site-checker/) по категориям и порогу нулевых ошибок. Свой проверочный контур агентства шёл после передачи, и замечания попадали в общую очередь для нашего цикла исправлений, пока агентство не подписывало приёмку. ## Результаты Метрика Результат Собрано URL **31** — главная (1) · о нас (1) · страница врача (2) · страница услуг (19) · блог (1) · стандартный шаблон (7) Применено шаблонов **6 / 6** из стандартной библиотеки агентства Контрольный список запуска **29 пунктов** согласовано по разделам «Дизайн / Функциональность / Контент / SEO» Очередь правок SEO **45 / 60** закрыто как выполненные; 10 в QA; 1 требовал уточнения Очередь правок AM **6 / 8** закрыто как выполненные; 2 в QA Сроки **75 дней** (24 марта – 7 июня 2025), сдано в срок Трудоёмкость **51 ч / смета 51 ч** — без перерасхода, без расширения объёма Команда **4 специалиста** **Статус сайта** Работает на WP Engine, открывается по адресу https://childsmilesoc.com/ — проверено в апреле 2026. Если коротко: 31 URL в 6 шаблонах на WP Engine в рамках согласованного бюджета в 51 час. Две очереди правок QA (SEO + AM) отработаны до уровня приёмки агентством, контрольный список запуска закрыт до переключения домена. ## Процесс Этап Длительность Результат Бриф и оценка ~1 неделя Тестовая среда Webflow проверена, строки карты сайта подтверждены, объём оценён, смета 51 ч согласована Этап сборки (страницы + шаблоны) ~3 недели 31 страница собрана в 6 шаблонах; выполнено структурное сопоставление Webflow; открыта очередь правок SEO QA и цикл исправлений и обратной связи ~4 недели Две очереди правок QA отрабатывались параллельно; структурные исправления Webflow-Elementor решены по каждой задаче Контрольный список запуска + поддержка после запуска последние ~2 недели Контрольный список из 29 пунктов согласован; сайт запущен; исправления после запуска применены Сдача последний день Боевой домен на childsmilesoc.com, HTTP 200 подтверждён _Сборка и QA шли параллельно с третьей недели; цикл исправлений начался до закрытия последних задач этапа сборки — поэтому календарь составляет 75 дней, а не сумму последовательных этапов._ ## Команда **Команда проекта** - **Никита Тумашевич** — проверка сборки и поддержка QA - **Павел Сажин** — итерации QA и исправления - **Владимир Козлов** — ведущий разработчик, сопоставление Webflow-Elementor и полная сборка на обоих этапах - **Наталия Богатель** — поддержка разработчика на этапе исправлений после запуска и корректировок очереди правок - **Антон Херсун**, [xaverPRO](https://xaver.ru/) — руководитель проекта (оценка, коммуникация с аккаунт-менеджером агентства, согласование) Управление проектом со стороны агентства и коммуникация с клиентом оставались за партнёрским агентством на всём протяжении проекта. Конечный клиент нас не видел: вся обратная связь по QA шла через общую очередь правок, и внутренняя кухня сборки до него не доходила. ## Агентствам, заказывающим разработку WordPress > На сайте детской стоматологии каталог услуг задаёт план URL, граф разметки и уже набранные позиции. У этой практики один адрес и детская стоматология; у других — сеть ортодонтических клиник с несколькими адресами. Риски тихие. Новая линейка услуг на шестой месяц не впишется в шаблон URL. Разметка врачей пропадёт при импорте. Страница каталога с фильтрами перестанет отдавать страницы, которые уже ранжируются. Подрядчику стоит задавать не вопрос «соберёте ли страницы?», а вопрос «как таксономия растянется под новую линейку услуг без миграции?» Пришлите рабочую таблицу сборки, черновик карты сайта или дизайн-файлы. Мы сверим ваш план URL с перечнем ранжируемых страниц, отметим места, которые позже выйдут боком, и вернём фиксированную смету в часах. Аудит без оплаты, смета — в часах. [Запросить аудит ТЗ →](/contact/) --- url: https://xaver.ru/insights/the-pre-handoff-gate-we-should-have-had-on-day-one/ title: Год агентство ловило то, что должны были ловить мы. type: insight date: 2026-02-08T02:50:33+00:00 --- ## Не архитектура — мелочи, которые стыдно сдавать У агентства есть свой QA: после нашей сдачи, на тестовой среде, до того как что-то уйдёт клиенту. Делают они это хорошо. И первый год партнёрства их QA находил что-нибудь в каждом нашем проекте. Не страшное. Не разваленную вёрстку, не сломанные формы, не пропавшие страницы. Это мы ловили сами, до того как что-либо уходило из наших рук. Агентство раз за разом находило другой слой: каждая ошибка по отдельности — пустяк, но вместе они говорят, насколько внимательно команда вычитала свою работу. Телефон обычным текстом, без ссылки `tel:`. Внутренняя ссылка на старый домен клиента вместо нового. Серый силуэт из стандартного шаблона в блоке «Наша команда». Заголовок строчными буквами. Разработчик скопировал его из брифа, а не из согласованного стиля. Пункт меню, всё ещё названный «Sample Page», потому что эта уборка была в списке и выпала из него на финальном рывке. Поправить любую из них. Меньше минуты, если знаешь, где смотреть. Так что дело было не в правках. Дело было в том, _кто_ их находит. Находило агентство — и каждый раз после сдачи. То есть каждый проект, который мы помечали готовым и отдавали на тестовую среду, нёс горстку видимых, легко устранимых ошибок, и рецензент агентства натыкался на них в первые 10 минут. Каждый раз. «Они продолжают присылать нам что-то недоделанное». Вывод напрашивается сам. Мы и сами приходили к нему изнутри. И нам было неловко. ## Что на самом деле происходило Разработчик, который 2 недели строит сайт, к концу уже не видит его ясно. Это не про нехватку навыка. Это обычное свойство человека. Когда долго смотришь на незаконченную работу, перестаёшь видеть её свежим взглядом. Разработчик, открывавший главную 200+ раз за 2 недели, картинку-заглушку уже не замечает: она стала частью обстановки, и взгляд проскакивает мимо к тому, что он сейчас на самом деле проверяет. Свежий рецензент видит её сразу. > Тот, кто сделал сайт, и тот, кто видит его впервые, смотрят на разные сайты. Пиксели одни и те же, но опыт за плечами совершенно _разный_. — Рабочая заметка · 2024 Обычный ответ на это: контрольный список перед сдачей — выписать то, что чаще всего упускают, и пройтись по нему. Контрольные списки работают, но до известного предела. Предел наступает, когда список длинный, проект авральный, а уставший разработчик начинает отмечать пункты по памяти, а не по факту. «Телефоны: да, сделал». Не сделал. Или сделал на 3 страницах, а на 4-й пропустил. Но галочка стоит. Документ стоит ровно столько, сколько внимания уделяют его чтению. А в конце 2-недельного спринта внимания уже не остаётся. Нам нужно было что-то, что от внимания разработчика вообще не зависит: само, по списку, проверяет известные типы ошибок и не даёт сдать проект, если их находит. Без разницы, насколько разработчик устал и что он помнит. ## Как мы сделали барьер Мы написали плагин для WordPress. Внутреннее имя: Site Checker. Перед тем как ссылка на тестовую среду уйдёт агентству, он прогоняет по всему сайту набор проверок и выдаёт отчёт «прошёл / не прошёл». Хоть одна непройденная проверка: сдача заблокирована. Состав проверок менялся от версии к версии, но в устоявшемся виде это около 48 правил в 6 группах: ``` `# Site Checker — категории проверок (упрощённо) phone_format: rule: все номера телефонов должны использовать tel:+1XXXXXXXXXX scope: все страницы, все виджеты, шапка, подвал fail_on: номера в обычном тексте, tel: без кода страны internal_links: rule: нет ссылок на предыдущие домены клиента или домены-заглушки scope: все страницы, навигационные меню, подвал fail_on: внешние href, не являющиеся намеренными исходящими ссылками content_language: rule: нет кириллических символов в опубликованном контенте scope: весь отображаемый текст, метки виджетов, значения своих полей fail_on: любой кириллический символ за пределами строк wp-admin UI placeholder_assets: rule: нет неизменённых изображений-заглушек из шаблона scope: использование медиатеки на опубликованных страницах fail_on: известные имена файлов-заглушек, известные размеры заглушек без alt-текста page_titles: rule: регистр заголовков соответствует соглашению сайта (Title Case) scope: элементы H1 и H2 на всех опубликованных страницах fail_on: заголовки полностью в нижнем регистре, непоследовательная капитализация внутри страницы standard_pages: rule: образцовая страница WordPress и дефолтный пост «Hello world!» удалены scope: все страницы и записи fail_on: slug "sample-page", slug "hello-world" присутствует и опубликован` ``` Правило про кириллицу нужно пояснить. Наши разработчики пишут внутренние заметки по-русски — само по себе это не проблема, внутреннее остаётся внутренним. Проблема — копипаст. Разработчик пишет рабочую заметку по-русски, вставляет кусок куда-нибудь как временную затычку и забывает заменить перед сдачей. На сайте с Elementor этот кусок может осесть в сериализованном поле виджета, где в редакторе его сразу не видно: на странице он показывается — но только если попасть в нужную область просмотра на нужной глубине прокрутки. Агентство поймало это на двух сайтах. Оба раза русский текст сидел в подписи виджета, которую клиент рано или поздно увидел бы; один — прямо в блоке контактов. Мы добавили правило. Теперь Site Checker проверяет на кириллицу весь выводимый текст, включая сериализованные поля Elementor. Он находит то, что глазами пропустишь. ## Что изменил барьер В первом квартале после запуска Site Checker замечаний агентства по мелочам соглашений стало резко меньше. Не до нуля. QA агентства идёт по более широкому фронту, чем наш: точность контента, соответствие бренду, требования со стороны клиента, которых мы целиком не видим. Эти замечания шли и дальше — и правильно. Но десятиминутные находки — телефоны обычным текстом, картинки-заглушки, образцовые страницы практически прекратились. Изменилось не только количество. Изменился сам характер рецензии. Раньше она почти всегда начиналась с мелочей: соглашения, форматирование, вычистка. С Site Checker этот слой исчезал из обсуждения. Рецензенты сразу переходили к содержательной части, потому что база уже была в порядке. Разработчику, которого мы подключили в середине спринта, мы дали ссылку на отчёт Site Checker вместо устного пересказа правил. Для ввода в курс дела этот отчёт оказался чище всего, что мы писали раньше. Он был про реальное состояние того сайта, который человеку предстояло доделать. «2 непройденные проверки: телефоны на странице контактов и один H2 строчными буквами в блоке услуг». Полезнее любого общего контрольного списка: говорит ровно, куда смотреть. > Новому разработчику Site Checker говорит, что не так с _этим_ сайтом. Не что вообще обычно бывает не так — а что не так с тем конкретным, который ему сдавать. — Рабочая заметка · 2025 Но самое стойкое изменение — в том, с каким настроем агентство берёт входящие проекты. До Site Checker рабочее допущение было примерно такое: «разработчик сделал что мог — готовимся ловить огрехи по соглашениям». Настрой на придирчивую вычитку. После нескольких чистых сдач подряд допущение сменилось: «база будет в порядке: сразу к содержательной рецензии». Этот сдвиг ценнее любой отдельной правки: время рецензии уходит на то, что видят только они, не на то, что должны были поймать мы. ## Чего барьер не делает Site Checker не заменяет QA агентства. Он и не должен. QA агентства закрывает то, что мы проверить не можем: соответствует ли контент реальному бизнесу клиента, в стиле ли бренда картинки, есть ли в структуре страницы смысл с точки зрения целей кампании, нет ли проблем с доступностью под конкретную аудиторию. Ничего из этого в нашем барьере нет. Всё это — их зона. Site Checker: структурный барьер для узкой, чётко очерченной категории: ошибок, которые неловко сдавать, которые явно относятся к нашему слою работы и которые надёжно проверяются программой. И только. Граница тут важнее, чем кажется. Барьер, который пытается охватить слишком много, становится медленным, хрупким, и его начинают обходить. Если в набор проверок попадает каждый пограничный случай и каждое разовое суждение, отчёт переполняется ложными срабатываниями, и разработчики перестают его читать. Барьер, который делает одно дело и делает его хорошо, заставляет доверять своему сигналу. Поэтому мы устояли перед соблазном проверять контекст. «Соответствует ли главный баннер фирменному стилю клиента?». Такую проверку мы написать не можем. «Есть ли на странице контактов телефон без формата tel:?». Такую можем. Первое оставляем людям, пишем только второе. ## Когда барьер выключать Есть стадии, где барьер надо обходить. Раннее прототипирование, показ прототипов клиенту, исследовательские ветки, где цель: разобраться, а не сдать: гонять строгий барьер здесь контрпродуктивно. В прототипе картинки-заглушки и должны быть. В прототипе и не должно быть финальных телефонов. Мы отключаем Site Checker в средах, помеченных как прототип, и снова включаем в момент, когда проект готовят к сдаче на тестовую среду. Флаг ручной: разработчики могут его снять и сами понимают, когда это уместно. Барьер: не способ контроля, а способ держать дисциплину. Команде важно эту разницу не терять. Механизм работает, только пока команда в него верит. Барьер, который ощущается помехой, обходят. Барьер, который ощущается полезным инструментом, используют. Нам удаётся держать его во второй категории ровно потому, что мы дисциплинированы в том, что в него входит: только проверки, которые явно наши; только правила с задокументированной причиной; только провалы, которые разработчик признаёт настоящими. ## Урок для агентства Если вы работаете с подрядчиками-разработчиками, спрашивать надо не «делают ли они QA?» — ответ всегда «да, в какой-то форме». Правильнее спросить: «кто чем владеет и на каком этапе у каждого срабатывает свой барьер?» Подрядчик, который перед сдачей бегло смотрит глазами и считает дело сделанным, по сути просит ваш QA быть последним рубежом против структурных ошибок. Ваши рецензенты их найдут. Найдут — и поправят, или пришлют замечания, или просто привыкнут их ждать. Любой из исходов чего-то стоит: в отдельном проекте этого не видно, а на масштабе портфеля набегает заметно. Подрядчик с собственным барьером перед сдачей (пусть даже простым) приходит к вам с другим предложением: «Базу мы уже вычистили. Ваша рецензия может начинаться сразу со слоя, который важен». Это другие рабочие отношения, и куда более разумная трата внимания вашей команды. Урок для агентства Барьеру не нужно быть сложным, чтобы приносить пользу. Контрольный список, который реально соблюдают, лучше инструмента, который иногда обходят. Десять автопроверок, которые надёжно срабатывают, лучше 40 пунктов, которые в конце спринта пробегают по диагонали. Дело не в сложности — дело в надёжности. Неловкие ошибки (картинки-заглушки, телефоны обычным текстом, образцовые страницы) не говорят о том, что команде всё равно. Они говорят о том, что команда не выстроила процесс так, чтобы ловить их до отправки. А выстроить его недорого: первая версия Site Checker — 200 строк PHP. Отдача (меньше нагрузки на рецензию и лучше рабочие отношения) проявилась уже в первом квартале. Будь у нас этот барьер с первого дня, весь первый год прошёл бы иначе. --- url: https://xaver.ru/insights/why-we-started-syncing-with-the-agency-team/ title: Менеджеры переносят всё. Кроме одного. type: insight date: 2026-01-16T20:01:01+00:00 --- ## 9 месяцев, 50 сайтов, ноль созвонов К весне-лету 2025 года мы шли с маркетинговым агентством из США уже 9 месяцев. За это время сдали около 50 сайтов на WordPress — по локальному бизнесу: стоматологии, юристы, ветеринары, оптометристы. Все собирались по одному и тому же шаблонному стеку: Astra Pro плюс Elementor Pro, агентский набор пресетов. Между нашей командой разработчиков и разработчиками агентства за эти 9 месяцев не прошло ни одного прямого разговора. Всё шло через слой менеджеров: задача в Redmine — комментарий в Google Docs — пометка в шаблонной таблице — другая задача. Решения долетали точно. Менеджеры с обеих сторон знали свою работу. Ничего не терялось. Кроме одного. И это одно копилось тихо. ## Что копилось Мелкие ошибки. Поодиночке — пустяк: где-то отступ на мобильных разошёлся с соседним блоком; иногда CTA-кнопка наследовала цвет из чужого пресета; на одном из сайтов заголовок секции вышел в body-типографии. Ни одна из них не была блокером сдачи. Каждую агентство ловило при своей проверке, заводило отдельной задачей, мы её закрывали за 10 минут. Цикл шёл. Только одна и та же ошибка повторялась в каждой третьей-четвёртой сборке. Тот отступ под мобильным — снова. Цвет CTA-кнопки, унаследованный из чужого пресета. И заголовок секции в той же body-типографии, четвёртый раз за месяц. Менеджер передавал её как новый дефект — для него и был новый: новая сборка, новая задача, новое исправление. Что эту самую ошибку мы починили на сайте 3 недели назад, в системе задач не помечено. Это и есть то, что асинхронный канал переносит хуже всего. Он переносит **факт** ошибки. **Источник** ошибки в нём не помещается: чтобы его увидеть, нужно держать в голове 20 предыдущих сборок и сказать «погоди, это уже был раз четвёртый — где-то в нашей сборочной заготовке оно зашито». Этого менеджер сделать не может. Этого вообще никто кроме разработчика, который сидит в этих сборках каждый день, сделать не может. ## Первый созвон Случился он не как итог большого решения, а как раз потому, что один из наших разработчиков как-то в чате обронил: «знакомый отступ снова». Мы сели — наши 2 и 2 с агентской стороны. Без аккаунт-менеджеров. На 40 минут. Повестка была одна: пройти по последним 10 сайтам и для каждой повторяющейся мелкой ошибки найти, **откуда она берётся**. Не «как мы её правим в этой конкретной задаче» — это мы уже знали. **Где в процессе она появляется в первый раз**, и что нужно поменять, чтобы она не появлялась ни на следующем сайте, ни через сайт, ни через десять. К концу 40 минут у нас был список из 7 источников. 6 из них — наши: базовый пресет Astra, который мы не заметили что чуть отличается от агентского; одна шаблонная PHP-вставка, копированная из старой сборки и тащащая старый CSS-namespace; способ заводить мобильные точки адаптации, который у нас и у агентства разъезжался на одну точку адаптации. 7-й — общий: ни у нас, ни у них не было одного описания того, какие именно блоки в типовой странице обязательны, а какие опциональны. 7 источников за 40 минут. До этого мы их вылавливали по одной задаче в неделю, 9 месяцев подряд. ## Что изменилось Не скорость сборки. Скорость не сильно поменялась — мы и до этого собирали быстро. Поменялось **количество новых задач из-за повторяющихся мелочей**: оно упало почти в ноль через 2 следующие сборки. Не потому что мы стали внимательнее, а потому что закрытые источники физически перестали порождать ту ошибку. Поменялось и второе — у партнёрства появился канал, через который разработчики могли проговорить «как», когда оно техническое настолько, что менеджер его не переведёт. Пользовались им редко, как и было задумано: примерно раз в месяц-полтора, перед следующей крупной сборкой. Но он был — и это меняло то, с чем обе стороны входили в работу ещё до её старта. > Решение менеджер перенесёт. Источник ошибки — нет: он не помещается в формат задачи. О нём разработчики говорят _напрямую_, или он копится месяцами. — Рабочая заметка · 2025 ## Что из этого следует Это не выпад против асинхронной работы. Мы по-прежнему ведём проекты в основном через задачи и комментарии — асинхрон ищется по истории, ведёт летопись, работает через любые часовые пояса. Менять это мы не собираемся. Вывод точнее. Асинхронный канал с менеджерами посередине отлично переносит решения и плохо переносит **источники повторяющихся ошибок**. Их видит только тот, кто сидит в коде каждый день — и видит он их, когда говорит с другим таким же. Менеджер этого разговора провести не может, потому что для этого разговора у языка управления проектами просто нет слов. Если вы маркетинговое агентство, ведущее WordPress-разработку через подрядчика целиком асинхронно, и за последние полгода у вас в трекере появлялась дважды одна и та же мелкая ошибка от разных задач — стоит спросить себя не о том, работают ли задачи. Скорее всего, работают. Вопрос в другом: говорили ли хоть раз ваши разработчики с разработчиками подрядчика про то, **откуда** эта ошибка приходит — или вы по 20-му разу её правите и закрываете задачу. Как проверить у себя Откройте трекер за последние 6 месяцев. Сгруппируйте закрытые задачи не по сайту, а по характеру ошибки. Если одна и та же мелочь встречается в 3+ сборках — вы только что нашли источник, который иначе будет жить в системе ещё 9 месяцев. Нам стоило завести этот созвон раньше. Не завели, потому что казалось — он не должен быть нужен: хорошая документация, выстроенный процесс, опытные менеджеры закроют всё. Обычно и закрывают. Но ровно на повторяющихся мелочах — не закрывают; и пока люди, которые делают работу, не окажутся в одной комнате на 40 минут, ничто вам об этом не скажет. --- url: https://xaver.ru/insights/when-scope-arrives-after-the-build-has-started/ title: Объём может вырасти уже в ходе сборки. Что мы с этим сделали. type: insight date: 2025-12-24T03:59:59+00:00 --- За последние 2 года мы раз за разом упирались в одну и ту же проблему. И каждый раз она приходила с новой стороны. Сборка сайта педиатрической клиники: мы были в середине работы по индивидуальному дизайну, когда агентство выяснило, что исходный дизайн принадлежит третьей стороне и для этого клиента не лицензирован. Перешли на шаблон из библиотеки агентства. Решение разумное, но появилось оно уже после того, как под оригинальный дизайн были приняты ключевые технические решения. Многопрофильный стоматологический проект для взрослых: сайт уже стоял в тестовой среде, когда агентство передало директиву клиента: полная замена бренда на каждой странице плюс смена дизайна и контентного ориентира. Не мелкая правка, а пересборка всей логики подачи сайта. Шаблонная сборка wellness-клиники: работа началась раньше, чем появился бриф на тексты. К моменту, когда бриф пришёл, структура страниц уже была собрана по раннему пониманию задачи, и чтобы вписать настоящий контент, пришлось пересматривать смету и аккуратно выстраивать порядок работ, чтобы ничего не поехало. И ещё один многопрофильный стоматологический проект: посреди спринта прилетели 2 незапланированных расширения объёма — ни одного не было в исходной таблице. Проекты разные. Закономерность одна. Агентство передаёт новую вводную: где-то клиент сменил курс, иногда всплывал вопрос с правами, в одном из случаев запоздал бриф. И разработка, которая шла ровно, теперь должна вобрать работу, которую никто не оценивал и в объём не вносил. Вопрос ни разу не стоял так: справимся ли мы с изменением. Справимся. Вопрос был другой: если провести его неформально, исходная смета незаметно расползётся, в разработку уйдут неоплаченные часы, и всплывёт всё это только при счёте — разрывом между тем, что согласовали, и тем, что сделали. Вот в чём проблема: не в самом изменении объёма, а в том, что его проводят неформально. Правило, к которому мы пришли Решение, к которому мы пришли, простое: любой незапланированный объём — отдельной задачей. Каждый новый пакет работ — смена дизайна, зачистка бренда по всем страницам, перестройка контента, незапланированное расширение — получает свою задачу в Redmine прежде, чем в неё уйдёт хотя бы час. У задачи своя оценка, по той же детализации, что и исходная таблица. Свой проход QA. В текущей разработке она не растворяется. Это даёт сразу 3 вещи. Исходная смета защищена от тихого размывания новой работой: счёт в конце отражает то, что согласовали, плюс дополнения отдельной строкой. Общие компоненты шаблонов и принятые технические решения защищены от давления спешной вставки: её надо встроить, не расшатав то, что уже стоит в тестовой среде. И у агентства остаётся ясный учёт того, что добавили в объём и почему. Это нужно и для их внутренней отчётности, и для разговора с клиентом о стоимости. Агентства, с которыми мы работаем плотно, этот ответ уже знают наизусть: короткая пауза, новая задача, оценка, согласование, и только потом работа. Да, это один лишний шаг. И именно он означает, что проект никогда не заканчивается счётом-сюрпризом, который никто не может объяснить. Если изменение объёма оформлено отдельной задачей, это просто ещё один этап разработки. Если его провели тихо, это проблема. Она копится незаметно — пока в один момент не перестаёт быть незаметной. --- url: https://xaver.ru/insights/draft-first-is-not-a-courtesy/ title: Сначала черновик — не любезность, а дисциплина. type: insight date: 2025-12-16T14:55:30+00:00 --- 2 случая. Разные проекты. Один и тот же вывод. Первый — редизайн главной страницы юридической фирмы. Бриф был чёткий: собрать новую главную в WordPress как черновик, закрыть от индексации и ждать согласования агентства, прежде чем публиковать хоть одну страницу. Обычная схема для юридических клиентов: каждое слово на главной (как поданы результаты дел, формулировки про юрисдикцию, оговорки про рекламу адвокатских услуг) имеет правовой вес. На QA перед сдачей мы увидели, что страница случайно опубликована. Она была уже в открытом доступе. Откатили сразу; агентство ещё не присылало свою проверку, так что провисела она недолго. Но мы прокрутили в голове сценарий: задержись цикл проверки агентства на пару дней, недоделанная главная юридической фирмы попала бы в индекс ещё до того, как её увидел хоть кто-то с правом согласования. Второй — многостраничный редизайн стоматологии. В начале сборки главной разработчик правил Divi-модуль этой страницы. Но модуль тянул из глобальной области шаблона, и правка разошлась по всему боевому домену. Сломались все страницы. Спасла резервная копия 15-минутной давности (её и применили): восстановились меньше чем за час. Но с этого момента вся работа на проекте шла из клонированной тестовой среды, полностью отрезанной от боевого домена. 2 случая. 2 разных способа сломаться. Общее одно: допущение, что работать на опубликованном WordPress-сайте, пусть и аккуратно, для клиента из регулируемой отрасли несёт приемлемый риск. Это не так. После этих 2 проектов «сначала черновик» перешло из негласного предпочтения в явный протокол, прописанный в Redmine: для всех редизайнов в регулируемых отраслях. Проверка результата руководителем агентства стала отдельным обязательным согласованием прямо в задаче. Не беглый просмотр, а зафиксированное событие с датой и записью, до того как хоть одна страница уйдёт из черновика в публикацию. Работа из тестовой среды стала обязательной на любом проекте, где глобальная область конструктора может разнести правку по боевому домену без шага подтверждения. Это стоит денег: время на тестовую среду, лишний раунд согласования с фиксацией, дополнительная координация. Всю долгую сборку нужно держать черновые страницы в том же направлении, что и опубликованный сайт. Эта цена не издержки, а то, за что вы берёте деньги. Для юридической фирмы, медицинской практики, любого клиента из регулируемой сферы главная страница не маркетинговый материал, который можно поправить уже после публикации. Это публичное заявление, и у него есть правовой вес. Подрядчику, который правит сайт прямо в опубликованном Elementor или Divi (каким бы сильным он ни был), достаточно одной случайной правки в глобальных стилях, чтобы наружу ушло то, что юристы клиента ещё не согласовали. Этот барьер не замедляет работу над сайтом: для регулируемой отрасли он её обязательная часть. Что спросить подрядчика Если у вашего нынешнего подрядчика нет формального протокола «сначала черновик» для редизайнов в регулируемых отраслях — об этом стоит спросить ещё до старта следующего проекта. --- url: https://xaver.ru/insights/the-first-year-was-chaos/ title: Первый год был хаосом. Потом мы всё записали. type: insight date: 2025-11-10T14:10:02+00:00 --- ## Три сборки одного агентства — и ни одна не похожа на другую В самом начале, пока ничего из этого не было записано, сайты одного и того же агентства собирались тремя разными способами. Один разработчик ставил Elementor Forms — они уже были в макете. Другой менял их на Gravity Forms. Третий не трогал то, что есть, по принципу «работает — не лезь». Это было самое начало: стандарта не было ещё ни у нас, ни у агентства. Три разные сборки, три разных поведения форм, три разные ветки обсуждения по одному и тому же вопросу. И это было ещё самое простое из разногласий. Был ещё вопрос, какие единицы CSS брать. Удалять ли страницу-образец WordPress в первый же день или оставить. Писать заголовки с каждого слова с большой буквы — Title Case (`Personal Injury`) — или только с первого, sentence case (`Personal injury`). Нужна ли hero-блоку главной своя точка адаптации или хватит стандартных точек адаптации Elementor. Ставить ли плагин кэширования на WP Engine. (У WP Engine кэш встроенный. Плагин его удваивает. В первые полгода это в команде знали не все.) У каждого вопроса был один правильный ответ. И в начале по нескольку неправильных, одновременно работающих на разных сайтах. Замечало это и агентство. Всплывало нечасто (пару раз за всё время), но разговор всегда шёл по одному сценарию: _этот сайт делает X, предыдущий делал Y; можно свести к одному?_ И, честно говоря, своего стандарта у агентства тоже не было. Ту самую одну колею мы в итоге выбрали вместе. Указать на одну колею мы и не могли: её ещё не существовало. Каждый разработчик пришёл к своему набору решений по умолчанию: отчасти из привычки, отчасти подсмотрев, как уже сделано в проекте, отчасти из догадок о том, чего хочет агентство. Ни один набор не сходился с другими. В результате качество, технически приемлемое на каждом отдельном сайте и заметно разнородное по всему портфелю. Это и была боль. Лечилась она не обучением, а тем, что мы это записали. ## Что значит «записать» на самом деле Когда у команды разнобой на выходе, первым делом тянет назначить встречу. Собрать всех, пройтись по правилам, договориться, идти дальше. Мы пробовали. Работает неделю. Ко второй неделе половина договорённостей растворяется обратно в «ну, на этом проекте я подумал…», а другая распадается на конкурирующие толкования. > Встреча — это течение. Документ — _закреплённая точка_. — Рабочая заметка · 2024 Сдвинуло дело другое: медленно накопленное письменное руководство. По одному правилу за раз, и каждое привязано к реальному конфликту, который стоил реального времени. В первой версии было 5 правил. В нынешней — больше 30. Почти каждое восходит к конкретному моменту трения, который мы больше не хотели повторять. Нынешняя внутренняя версия документа начинается так: ``` `# xpro · WordPress build conventions # v17 — 2026-04-30 stack: page-builder: elementor-pro-only forms: gravity-forms # не Elementor Forms seo: rank-math caching: none # у WP Engine встроенный кэш hosting: wp-engine-standard # среда, предоставленная агентством content: heading-case: title-case # "Personal Injury", не "Personal injury" h1-per-page: 1 units: px-only # без vw, без clamp без обоснования breakpoints: elementor-defaults # свои точки адаптации отключены phone-numbers: format: tel:+1XXXXXXXXXX always-clickable: true always-include-country: true` ``` За каждой строкой стоит закрытый спор. На большинство ушло по проекту. Несколько примеров со скрытой историей каждого: **«Всю вёрстку — на Elementor Pro.»** Мы всё собираем на Elementor — на нашей стороне это никогда особо не обсуждалось. Правило всё равно записано: «очевидно для нас» не равно «зафиксировано». Не раз сборка выглядела так, будто её делали двумя разными способами. И если размотать, разнобой шёл из того, как проект настроили _до_ того, как он попал к нам, а не из того, что разработчик посреди работы менял конструктор. Записанное правило сделало ожидание явным, а не подразумеваемым: и для нас, и для агентства. **«Только Gravity Forms. Elementor Forms не использовать.»** На Gravity Forms у агентства уже была налажена доставка писем, нужная им условная логика и интеграции с аналитикой, которые собирали данные в их отчётность. Elementor Forms — вполне нормальный плагин для проекта другого рода. Но на этих проектах смешивать оба означало: у одних форм есть аналитика, у других нет; у одних защита от спама, у других нет. И агентству приходилось выяснять это заново на каждом новом сайте. Правило не про то, какой плагин лучше. Оно про то, чтобы у одного вопроса не было двух ответов. **«У WP Engine кэш встроенный. Плагины кэширования не ставить.»** Это стоило 4 часов отладки на тестовой среде, которая после деплоя упорно отдавала старые ресурсы. Причина: плагин кэширования, поставленный по привычке, поверх собственного слоя кэша WP Engine. Два кэша наперегонки. Лечение: снять плагин. Правило: в следующий раз его не ставить. **«Телефоны — в формате `tel:+1XXXXXXXXXX`. Код страны — всегда.»** Какое-то время телефоны попадали на страницы вразнобой: где-то обычным текстом без ссылки `tel:`, иногда без кода страны, в части случаев правильно. Номер обычным текстом не вызовет набор, когда посетитель нажмёт на него на телефоне. Проблемой был именно разнобой, а не какой-то один способ вывода. Лечение: выбрать один формат и держать его всегда. Правило: эти несколько символов, записанные так, чтобы вопрос больше не открывался. **«Заголовки и пункты меню — Title Case, каждое слово с большой.»** Деталь, которая кажется придиркой, пока не отсмотришь стопку сайтов за неделю. На одних `Personal Injury`, на других `Personal injury`. Оба варианта по-своему защитимы. Вместе они не защитимы никак. Мы просто упустили это из виду. Ничьим осознанным решением это не было, поэтому закрыть это могло только записанное правило. **«Только пиксели. Никаких `vw` и `clamp` без явной необходимости.»** Похоже на ограничение творчества. Это не оно: это правило про предсказуемость. Сайт, собранный на `clamp` и `vw`, нормально выглядит на мониторе разработчика, и непредсказуем во всём остальном. Проверяющие агентства сидели на разных ноутбуках, планшетах и внешних экранах с разным масштабированием. Пиксельная вёрстка у всех одинаковая. Вёрстка на адаптивных единицах — это несколько разных вёрсток. Правило не про вкус в CSS. Оно про то, чтобы проверяющий видел тот же сайт, что мы собрали. **«Один `

` на страницу. Соблюдать иерархию заголовков.»** Агентство раз за разом отмечало одно и то же: страницы с более чем одним `

`. Так выходило, потому что разработчик ставил hero-виджет, настроенный как `

`, потом заголовок секции — тоже `

`, потому что визуально так выглядело правильно. Браузеру всё равно, аудиту — нет. Правило не про теорию SEO. Оно про то, чтобы не переделывать иерархию заголовков каждый раз, когда на это укажут. **«Свои точки адаптации Elementor отключить. Только стандартные.»** Это пришло из рассогласования, а не из одного инцидента. Мы тестировали сборки на одном наборе точек адаптации, агентство проверяло на другом. То, что у нас выглядело правильно, у них выглядело сломанным, и наоборот, притом что по сути никто не был неправ. Лечение было не в споре, чьи точки адаптации лучше, а в том, чтобы согласовать один общий набор, а остальное отключить. Стандартные точки адаптации задокументированы, предсказуемы и одинаковы по обе стороны проверки. Можно продолжать. Есть правила, какие шрифты грузить через TypeKit, а какие никогда не заливать вручную. Какие записи карты сайта включать, какие подавлять. Как помечать `target="_blank"` на исходящих ссылках. Удалять страницу-образец WordPress в первый же день. UpdraftPlus — только на время разработки. Ни одно из них не хитрое. Все — закрытые. ## Что изменилось, когда документ появился Чего мы не предвидели — это где на самом деле оказалась выгода. Не столько на нашей стороне. На стороне агентства. До документа агентству приходилось проверять наши сборки медленным способом: открывать страницы, сверять правила вручную, заново разбирать одни и те же вопросы на каждом новом сайте — потому что нельзя было считать, что любые две сборки согласованы. После документа сборки стали достаточно единообразными, чтобы агентство перестало это делать. Они опирались на автоматическую проверку, которая показывала, если что-то не так, и реагировали на отмеченное, вместо того чтобы каждый раз вручную пересматривать правила с нуля. В этом и вся история того, что изменилось: нагрузка по проверкам ушла с агентства. Не потому, что нам стали больше доверять вообще, а потому что единообразие проверяемо, а разнобой нет. Записанный стандарт и сделал сборки проверяемыми в принципе. ## Урок для агентства Если вы маркетинговое агентство, которое отдаёт WordPress-разработку на подряд — одной студии или нескольким, отсутствие письменного руководства — это налог, который вы платите каждую неделю. Налогом вы его не видите. Вы видите «обычную цену работы с разработчиками». Это не обычная цена. Это цена того, что каждый разработчик заново изобретает правила вашего портфеля, а вы потом гасите получившийся разнобой временем своих проверяющих. Два практических наблюдения с нашей стороны. **Первое.** Руководству не нужно быть идеальным, чтобы начать. 5 правил, записанных и согласованных, сэкономят в первый же месяц больше времени, чем документ из 50 правил, который писали полгода. Начните с конфликтов, которые уже были. Добавляйте правило каждый раз, когда всплывает новый. За год наберётся что-то серьёзное. За два — будете удивляться, как работали без него. **Второе.** Оценивая нового подрядчика, спросите, есть ли у него такой документ — не маркетинговая бумажка, а рабочий внутренний стандарт. Подрядчик, который может дать вам руководство, которым реально пользуется, — это подрядчик, чьи сборки будут предсказуемы от проекта к проекту. Подрядчик, который не может, предлагает вам свой первый год хаоса как ваш первый год надзора за ним. Эту цену можно принять (иногда подрядчик того стоит). Но цена реальна, и стоит понимать, что вы её платите. Первый год работы без правил неизбежен в первый раз. Во второй — это уже выбор. Мы выбрали записать правила. Большая часть того, что мы как бюро делаем сейчас, выросла из этого одного решения.