На сайте появляются ошибки: где смотреть error.log и как понять причину

PHP-логи, консоль браузера, вкладка Network, воспроизведение ошибки и безопасное исправление причины.

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

Не чинить то, что ещё не диагностировано

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

Первые проверки без переделки сайта

• Менять небольшими этапами с тестами.
• Создать staging и проверить backup.
• Искать первый fatal в цепочке, а не последние вторичные предупреждения.
• Снять карту темы, плагинов, БД, PHP, cron и интеграций.
• Включить журналирование ошибок без вывода warning посетителю.

Что чаще оказывается источником

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

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

Популярные ложные решения

• лечить CSS сотнями !important
• переписывать без измеримой проблемы
• обновлять всё одновременно
• проверять после релиза только главную

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

Проверка после исправления

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

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