Сайт сломался после обновления WordPress или плагина: порядок действий

Безопасное восстановление: логи, откат, изоляция конфликтующего плагина, резервная копия и staging.

Старый сайт не обязательно выбрасывать. Иногда выгоднее сохранить URL, данные и работающие интеграции, меняя проблемные слои постепенно. В других случаях чистая миграция дешевле спасения legacy.

Сначала зафиксировать симптом

Один и тот же внешний симптом может появляться по разным причинам. Сначала стоит записать конкретный сценарий: URL, устройство, шаг, момент появления и последние изменения.

С чего я бы начал проверку

• Сопоставить активные плагины с реально используемыми функциями.
• Менять небольшими этапами с тестами.
• Перед крупной правкой фиксировать точку возврата.
• Снять карту темы, плагинов, БД, PHP, cron и интеграций.
• Проверить версии PHP, WordPress и критических плагинов на совместимость.

Где обычно находится причина

Рефакторинг я бы начинал с инвентаризации: что уже работает, откуда приходит трафик, какие интеграции завязаны на старый код и какие изменения стали дорогими.

Рефакторинг нужен не ради красоты кода, а когда архитектура повышает стоимость изменений, вызывает регрессии, нагрузку или мешает бизнесу развивать продукт.

Что легко сделать хуже

• менять URL без SEO-карты
• править production без staging
• обновлять всё одновременно
• проверять после релиза только главную

Самая дорогая ошибка — начать с полного переписывания, не сохранив URL, аналитику, формы, данные и рабочие сценарии.

Как понять, что проблема решена

• PHP/JS ошибки
• частота регрессий
• нагрузка
• время типовой правки

Хороший рефакторинг заметен не эффектом, а тем, что сайт перестаёт ломаться от каждой следующей задачи.