Каскад, именование, design tokens, компоненты и уменьшение количества конфликтующих переопределений.
Запрос «переделать сайт» почти никогда не является техническим заданием. За ним могут скрываться устаревший дизайн, плохая конверсия, медленная работа, неудобная админка, SEO-проблемы или код, который страшно менять.
До начала работ
Рефакторинг я бы начинал с инвентаризации: что уже работает, откуда приходит трафик, какие интеграции завязаны на старый код и какие изменения стали дорогими.
- Оценить стоимость постепенного ремонта против новой разработки.
- Сохранить работающие URL и данные до изменений.
- Сначала определить, что не устраивает: UX, код, скорость, SEO или контент.
- Сохранить SEO URL, аналитику и критические сценарии.
Как я бы прошёл эту задачу
- Сохранить SEO URL, аналитику и критические сценарии.
- После релиза мониторить ошибки, формы, нагрузку и SEO.
- Снять карту темы, плагинов, БД, PHP, cron и интеграций.
- Менять небольшими этапами с тестами.
- Создать staging и проверить backup.
- Разделить быстрые фиксы, рефакторинг и переписывание.
Точки риска по дороге
Рефакторинг нужен не ради красоты кода, а когда архитектура повышает стоимость изменений, вызывает регрессии, нагрузку или мешает бизнесу развивать продукт.
- лечить CSS сотнями !important
- проверять после релиза только главную
- менять URL без SEO-карты
Самая дорогая ошибка — начать с полного переписывания, не сохранив URL, аналитику, формы, данные и рабочие сценарии.
Проверка на реальном сценарии
Перед публикацией я бы повторил не только изменённый шаг, но и соседние сценарии: мобильную версию, формы, аналитику, интеграции и страницы того же шаблона.
- PHP/JS ошибки
- частота регрессий
- время типовой правки
- нагрузка
Когда работу можно считать законченной
После работы должны остаться понятные доступы, зафиксированные изменения и способ повторно проверить результат.
Если эту задачу нужно внедрить, а не только разобрать
Можно собрать план внедрения, проверить зависимости и довести изменение до работающего production-сценария.