Вводная
После обновления WordPress, темы, конструктора страниц или отдельного плагина сайт может выглядеть полностью рабочим. Главная открывается, кнопки нажимаются, форма визуально отправляется. Но в реальности заявка не доходит до менеджера или не создаётся в CRM. Для бизнеса это неприятнее обычной ошибки 500: внешне всё выглядит нормально, а рекламный трафик тихо сгорает.
Симптомы
Частые признаки: пользователь видит сообщение “отправлено”, а письма нет; CRM не получает лид; Telegram-уведомление не приходит; в консоли браузера появляются JS-ошибки; после включения антиспама форма стала молча отклонять часть отправок; письма уходят с адреса, который не разрешён SPF/DKIM.
Что проверяется
- какой плагин формы отвечает за отправку и не конфликтует ли он с темой
- есть ли ошибки JavaScript при нажатии на кнопку отправки
- какой HTTP-ответ возвращает endpoint формы
- уходит ли письмо через PHP mail или нормальный SMTP
- создаётся ли запись в базе/логах формы
- работают ли reCAPTCHA, nonce, антиспам и rate limit
- принимает ли CRM/webhook данные в нужном формате
Ход исправления
Сначала проверяется фронтовая часть: кнопка, событие отправки, консоль браузера и сетевой запрос. Затем смотрятся логи PHP и веб-сервера, потому что часть ошибок формы не выводится пользователю. После этого проверяется путь доставки: форма → SMTP или webhook → почта/CRM/Telegram. Если проблема в конфликте плагинов, отключается не всё подряд, а только подозрительный участок, чтобы не сломать сайт сильнее.
Нормальный результат
Нормальный результат — это не просто “письмо пришло один раз”. Должна быть повторяемая тестовая отправка, понятный источник заявки, проверенный получатель, лог ошибки и минимальная инструкция: что нельзя обновлять без повторной проверки и где смотреть статус доставки.
Вывод
Форма заявки — это не декоративный блок. Если она ломается, реклама продолжает приводить людей, но сайт перестаёт превращать их в обращения. Поэтому после любого обновления важно проверять не только внешний вид, а весь путь заявки до конечного сервиса.