WordPress-сайт для мультифилиальной хирургической стоматологии: 236 URL за 90 дней

Клиент (конечный пользователь): Legacy Oral Surgery — Union City, NJ (консолидированное присутствие нескольких филиалов)
Формат сотрудничества: White-label разработка для маркетингового агентства из США
Сроки: май — август 2025 · 90 дней · 103 часа

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

236 URL на 12 шаблонах, построенных для сведения двух доменов челюстно-лицевой хирургии на Kinsta — таблица Google Sheets содержала 302 строки карты сайта с почасовыми оценками на каждую строку, отслеживающими 103-часовой объём работ, а карта редиректов согласовывала 349 уникальных пар URL с двух приобретённых доменов практик, объединённых в единый новый бренд на legacyoms.com.

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

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

Маркетинговое агентство из США, нанятое группой 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, которого больше не существует, — разработка завершена только когда каждый из этих старых путей ведёт на правильное новое место на legacyoms.com. Исполнитель, считающий «страницы построены» как «консолидация выполнена», перекладывает эту нагрузку по согласованию на агентство — после запуска это дороже и сложнее защитить перед конечным клиентом.

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

1. Двенадцать шаблонов, 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. Спецификация выполнена построчно — включая колонку Hours Estimated. Таблица Google Sheets агентства содержала значение Hours Estimated для каждой строки 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 — закрыт после обеих очередей ошибок. Восемь часов доработок после запуска (правки вёрстки страниц филиалов, обновление QA-таблиц, строки контента) были выполнены в рамках того же соглашения по сопутствующим задачам.

Работа с двумя независимыми источниками редиректов — 288 парами из вкладки Sitemap и 117 строками аудита ссылок из Sheet8 по обоим унаследованным доменам — означала, что дедупликация предшествовала размещению любого редиректа. Перекрёстная проверка добавила 61 чистую новую пару, которых не было ни в одном источнике по отдельности, и выявление их до переключения — это то, что не дало URL предыдущих брендов превратиться в 404 после запуска.

Результаты

Результат в двух словах: два приобретённых домена практик челюстно-лицевой хирургии объединены в единый многофилиальный бренд на 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 для ознакомления с категориями и принципу нулевых ошибок. Собственный слой QA агентства — их инструменты, их процесс — работал после передачи и фиксировал замечания в общую очередь задач для нашего цикла исправлений, пока не подписывали приёмку.

Процесс

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

Команда

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

• Никита Тумашевич — ведущий разработчик: разработка, логика консолидационных редиректов, доработки после запуска
• Павел Сажин — итерации QA, проверка тестовой среды, оценка объёма работ
• Анна Полунина — поддержка разработки на позднем этапе (страницы филиалов, правки вёрстки)
• Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с агентством, согласование)

Проектное управление и коммуникация с конечным клиентом оставались на стороне партнёрского агентства на протяжении всего проекта. Для конечного клиента наша команда оставалась невидимой.

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