Аудит WordPress перед доработкой: как принять чужой сайт и не сломать рабочую систему

Доработка существующего WordPress-сайта часто сложнее разработки нового блока с нуля. На живом проекте уже есть тема, плагины, интеграции, пользователи, cron-задачи, формы, SEO-настройки и история ручных изменений. Если начать с правки первого найденного файла, легко исправить одну проблему и создать три новых.

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

Когда аудит перед доработкой особенно нужен

• сайт делали несколько разработчиков;
• неизвестно, где находится кастомный код;
• обновления WordPress или плагинов давно не выполнялись;
• после обновлений уже возникали ошибки;
• есть WooCommerce и реальные заказы;
• формы связаны с CRM, Telegram, email или внешними API;
• на сервере работают cron и фоновые процессы;
• нужно менять checkout, личный кабинет или роли пользователей;
• нет отдельного staging-сайта и понятного rollback.

С чего начинается техническая проверка

Первый вопрос — не версия WordPress, а возможность безопасно вернуть сайт в рабочее состояние. До любых изменений нужно понять, где резервные копии, как они создаются и можно ли их восстановить. Наличие архива ещё не означает, что backup пригоден.

Для коммерческого сайта полезно отдельно проверить файлы и базу данных, потому что они меняются с разной скоростью. У WooCommerce база может получить новые заказы уже через минуту после создания копии.

Staging вместо экспериментов на production

Если задача затрагивает PHP, шаблоны, плагины, базу или бизнес-логику, изменения лучше проверять на staging. Тестовая среда должна быть достаточно похожа на production по версии PHP, веб-серверу и настройкам.

При этом staging нельзя бездумно подключать к реальным платёжным webhook, CRM и email-рассылкам. Иначе тестовый заказ может создать настоящую сделку или отправить клиенту служебное письмо.

Тема и дочерняя тема

Нужно понять, используется ли стандартная тема, child theme или полностью кастомная разработка. Частая проблема — изменения прямо в файлах родительской темы. Следующее обновление перезаписывает их, и владелец узнаёт об этом уже после релиза.

Отдельно проверяются шаблоны WooCommerce. Старые overrides могут годами работать без видимой ошибки, а затем конфликтовать с новой версией WooCommerce.

Где искать кастомный код

Кастомизация WordPress может находиться в нескольких местах: functions.php, дочерней теме, MU-плагинах, обычных плагинах, snippets-плагине, custom plugin, Code Snippets, настройках конструктора и даже в серверных cron-скриптах.

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

Плагины: не количество, а зависимости

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

Проверяются версии, поддержка, совместимость с PHP, наличие кастомных правок и способ обновления. Нулевые и модифицированные премиум-плагины — отдельный риск безопасности и поддержки.

WordPress cron и фоновые задачи

На сайте могут работать wp-cron, Action Scheduler, системный cron или внешние webhook. Нужно увидеть расписание и понять, какие процессы изменяют данные.

Для WooCommerce особенно важен Action Scheduler: через него могут выполняться фоновые действия плагинов оплаты, подписок, импорта и интеграций. Если очередь накопилась или регулярно падает, интерфейс сайта может выглядеть нормальным, пока бизнес-процесс уже не работает.

Формы и заявки

Аудит формы не заканчивается тестом «сообщение отправлено». Нужно проследить весь путь: browser → WordPress → обработчик → email/CRM/Telegram → лог. Если внешний сервис вернул ошибку, сайт должен это заметить.

Полезно проверить защиту от повторной отправки, валидацию, spam protection, хранение персональных данных и обработку timeout.

WooCommerce требует отдельного сценария

На интернет-магазине нельзя проверять доработку только визуально. Нужно пройти каталог, карточку, вариации, корзину, checkout, оплату, письма и статусы заказа. Если есть доставка или CRM, тест продолжается после создания заказа.

Изменения в checkout особенно опасны, потому что ошибка может не давать fatal error: пользователь просто не сможет завершить покупку.

База данных и производительность

Полезно посмотреть размер ключевых таблиц, autoload options, transients, Action Scheduler и следы старых плагинов. Большая база не всегда медленная, но неограниченно растущий лог или autoload может заметно увеличивать время каждого запроса.

Также проверяется object cache, page cache, CDN и правила исключений. Иногда «ускорение» ломает динамические страницы магазина или кабинета.

Логи вместо угадывания

Перед исправлением плавающей ошибки нужно настроить наблюдаемость: PHP error log, WordPress debug log в безопасном режиме, логи веб-сервера, WooCommerce logs и логи интеграций. Без этого разработка превращается в серию предположений.

Логи не должны содержать пароли, полные токены и лишние персональные данные. Для критичных интеграций полезен request ID, который связывает событие сайта с записью внешнего сервиса.

Безопасность доступа

Разработчику не нужен пароль владельца от всего хостинга и всех сервисов. Лучше создавать отдельные учётные записи и выдавать минимально нужные права. После завершения работ доступ можно отключить.

Секреты API не следует отправлять в чат и сохранять в репозитории. Они должны находиться в переменных окружения, wp-config.php вне публичного вывода или защищённом secret storage.

Что должно получиться после аудита

Практический результат — короткая карта системы и порядок изменений. В ней фиксируются критичные плагины, точки кастомного кода, интеграции, фоновые задачи, риски обновлений, способ резервного восстановления и тестовые сценарии.

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

Пример порядка безопасной доработки

1. создать проверенную резервную копию;
2. подготовить staging;
3. воспроизвести текущую проблему;
4. найти ответственный код или интеграцию;
5. зафиксировать ожидаемое поведение;
6. внести минимальное изменение;
7. пройти регрессионные сценарии;
8. перенести изменение на production;
9. проверить логи и бизнес-сценарий после релиза;
10. оставить понятный rollback.

Когда достаточно быстрой диагностики

Если проблема локальная — например, сломан один CSS-блок или не работает конкретная кнопка после известного изменения — полный аудит может быть лишним. Но если причина неизвестна, сайт продаёт, принимает заявки или связан с несколькими внешними системами, предварительная проверка обычно экономит больше времени, чем занимает.

Доработка WordPress в A.S Groups

В A.S Groups можно начать именно с технического разбора существующего сайта: определить причину ошибки, зависимости и безопасный вариант изменения. После этого отдельно согласовать конкретную доработку без обязательного большого проекта.

Описание проблем, URL и желаемый результат можно отправить через форму контактов. Подробнее об услуге — на странице доработки WordPress.