76-страничный сайт для семейной стоматологии на WordPress за 130 дней

Клиент (конечный пользователь): David Eskow, DDS Family Dentistry — Olney, MD
Формат сотрудничества: White-label разработка для маркетингового агентства из США
Сроки: фев – июл 2025 · 130 дней · 57 часов на разработку и фазы исправлений и обратной связи

Подход к разработке

76 страниц новой разработки на Elementor для семейной стоматологической практики в Мэриленде, выполненной по 96-строчному экспорту Screaming Frog — оригинальный сайт был доступен только через VPN, поэтому экспорт послужил эталоном соответствия контента для каждой страницы. Агентство вело две параллельные дорожки QA и 49-пунктный контрольный список запуска — все закрыты до публикации сайта на WP Engine.

96-строчный экспорт оригинального сайта задавал направление с первой задачи, а структура двух очередей задач QA — отдельный трек очереди задач SEO и трек очереди задач аккаунт-менеджера — гарантировала, что и технические требования агентства, и клиентские критерии качества были выполнены до запуска сайта.

Краткий обзор

Постановка задачи

Маркетинговое агентство из США, нанятое 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 и очередь задач аккаунт-менеджера — до принятия сайта агентством.

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

Разработка, которая проходит визуальную проверку, но незаметно отошла от эталона Screaming Frog, требует той же доработки, что и разработка с пропущенными страницами. Две параллельные очереди задач QA — одна для SEO-слоя, другая для клиентской проверки аккаунт-менеджером — гарантируют, что оба критерия точности закрываются до контрольного списка.

Как мы это сделали

1. Десять шаблонов, 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. ТЗ соблюдено строка за строкой — с экспортом оригинального сайта как эталоном контента. Таблица Google Sheets агентства содержала структуру Hours Estimated для основных задач разработки: 41 ч на основную задачу, 9 ч на управление проектом и учёт часов на раунды контента и исправлений. таблица Google Sheets также включала вкладку с экспортом оригинального сайта — 96-строчный экспорт Screaming Frog — с H1 и метаданными для каждой индексируемой страницы существующего сайта.

Эта вкладка служила целевым эталоном: H1 и meta description каждой перестроенной страницы должны были соответствовать экспорту, если агентство не меняло их явно. Мы решили привязывать каждую страницу к данным экспорта, а не опираться только на описания из таблицы Google Sheets — потому что при разработке на том же домене без миграции URL основной риск — это расхождение контента, которое выглядит корректно при визуальной проверке, но всплывает неделями позже во время сверки QA агентством.

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

3. Корпус профилей сотрудников — 11 страниц из контента агентства. Шаблон Doctor Page был самой глубокой частью разработки раздела команды: 11 профилей, охватывающих врачей, гигиенистов, сертифицированных ассистентов стоматолога и менеджера практики. Каждый профиль требовал индивидуального контента, предоставленного агентством. В середине работы поступили новые изображения клиентов, которые были интегрированы в продакшен в рамках отдельной задачи по обновлению, что потребовало пересмотра главной страницы и нескольких профилей после первоначального прохода QA.

4. Контент-обновления и правки на тестовую среду — без срыва сроков. Две отдельные задачи по контенту поступили в середине работы: раунд обновления контента с новыми текстами для страниц услуг по таблице сверки Screaming Frog, собранной агентством, и раунд правок на тестовую среду с мелкими текстовыми корректировками и исправлениями вёрстки.

Обе были приняты как отдельные задачи Redmine с учётом часов и отрабатывались параллельно с очередями задач QA. Раунд live-fix — срочные исправления после запуска, отмеченные клиентом — также был отработан и закрыт до завершения очереди задач аккаунт-менеджера.

5. Двухдорожечный QA — оба направления закрыты до сдачи. Задачи отслеживались в двух отдельных вкладках очередей задач со стороны агентства: очередь задач SEO (14 строк, все выполнены до сдачи) и очередь задач аккаунт-менеджера (14 строк, все выполнены до сдачи).

49-строчный контрольный список запуска, охватывающий колонки Дизайн (совместимость браузеров, фавикон, изображения и видео), Функциональность (битые ссылки, навигация, формы, соцсети) и Контент (перенос страниц, meta, структурированные данные, карта сайта), был согласован на этапах Pre-Migration и Post-Migration до запуска в продакшен.

96-строчный экспорт Screaming Frog объединял оба направления QA. Оригинальный сайт был доступен только через VPN во время разработки — вкладка экспорта была единственным надёжным эталоном для каждой страницы — поэтому привязка H1 и meta description к её данным до открытия любой из очередей задач означала, что и SEO-трек, и AM-трек проверяли по одному и тому же эталону, а не по тому, как страница выглядела в данный момент.

Результаты

Контроль качества

Нагрузка QA в этой разработке легла на две параллельные очереди задач со стороны агентства — 14 строк очереди задач SEO и 14 строк очереди задач аккаунт-менеджера — плюс 49-пунктный контрольный список запуска, охватывающий Дизайн, Функциональность и Контент на этапах Pre-Migration и Post-Migration; все три закрыты до нуля перед публикацией на WP Engine.

QA перед сдачей проводился через Site Checker — см. наш подход к QA по категориям и критерию принцип нулевых ошибок. Собственный слой QA агентства — их инструменты, их процесс — работал после сдачи, и выявленные вопросы попадали в общую очередь задач для нашего цикла исправлений до их согласования.

Процесс

Этапы пересекаются — обновления контента и раунды live-fix поступали, пока очереди задач QA были ещё открыты, поэтому календарь составил 130 дней, а не сумму отдельных этапов.

Команда

Команда проекта

• Никита Тумашевич — ведущий разработчик на этапах разработки, интеграции контента и исправлений
• Павел Сажин — управление проектом и итерации QA
• Анна Полунина — поддержка разработчика по обновлению контента, правкам на тестовую среду и раундам QA
• Евгений Карпов — поддержка разработчика на раунде live-fix и обновлении изображений
• Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с агентством, согласование)

Управление проектом со стороны агентства и коммуникация с конечным клиентом оставались за партнёрским агентством на всём протяжении. Наша команда была невидима для конечного клиента.

Агентствам, заказывающим разработку WordPress