Почему формы на сайте не отправляют заявки

Если форма не отправляет заявку, сайт может внешне выглядеть полностью рабочим. Страница открывается, кнопка нажимается, поля заполняются, пользователь видит сообщение об отправке, а заявка владельцу не приходит. Самый неприятный вариант: проблема длится неделями, рекламный трафик идёт, люди пытаются связаться, а сайт молча складывает обращения в цифровую чёрную дыру.

В WordPress такая проблема встречается часто. Причина может быть в плагине формы, настройках уведомлений, SMTP, почтовом сервере, PHP-функции отправки, спам-фильтрах, reCAPTCHA, конфликте плагинов, ошибке темы или обработчике формы. Важно не паниковать и не начинать хаотично менять всё подряд. Формы, почта и безопасность связаны между собой, поэтому одно «быстрое исправление» может легко сломать отправку окончательно.

У WordPress есть функция wp_mail(), через которую часто отправляются письма. В официальной документации отдельно указано: если функция вернула true, это не значит, что пользователь реально получил письмо, это означает только то, что метод смог обработать запрос без ошибки. То есть «WordPress отправил» и «письмо дошло» — не одно и то же. Очень удобно, конечно. Почти как курьер, который вышел из офиса и дальше его никто не видел.

Как выглядит проблема

Проблема может проявляться по-разному. Иногда пользователь нажимает кнопку, форма крутится и ничего не происходит. Иногда появляется ошибка. Иногда форма пишет «сообщение отправлено», но письмо не приходит. Иногда заявки приходят только с части форм. Иногда письмо приходит владельцу, но не приходит пользователю. Иногда всё работало годами, а после обновления плагина, темы или PHP внезапно перестало.

Если используется Contact Form 7, его FAQ отдельно разделяет причины ошибки отправки: это может быть реальная проблема почтового сервера либо ситуация, когда отправка признана подозрительной как спам. У плагина даже цвет рамки сообщения может указывать на тип проблемы: красный — сбой отправки, оранжевый — подозрение на спам.

Что могло её вызвать

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

Вторая причина — неправильно настроены уведомления формы. Например, в поле получателя указан старый email, ошибка в адресе, пустой recipient, неверное поле From, сломался шаблон письма, не подставляются поля формы или письмо уходит на адрес, который уже не используется.

Третья причина — не настроен SMTP. Для стабильной доставки писем с сайта лучше использовать авторизованную отправку через SMTP или специализированный почтовый сервис. Даже в обсуждениях поддержки WordPress-плагинов типовая рекомендация при проблемах доставки — настроить SMTP, чтобы письма отправлялись авторизованно.

Четвёртая причина — конфликт плагинов, темы или JavaScript. Например, форма отправляется через AJAX, но скрипт ломается из-за оптимизатора, кэша, минификации, отложенной загрузки JS или конфликта с другим плагином. Пользователь видит форму, но отправка не проходит.

Пятая причина — защита от спама. reCAPTCHA, антиспам-плагины, honeypot-поля, firewall или серверные фильтры могут блокировать нормальные заявки. Особенно весело, когда владелец ставит защиту от спама, а потом сайт действительно перестаёт получать спам. И заявки тоже. Победа, но какая-то дорогая.

Шестая причина — проблемы на сервере. Может не работать PHP mail, быть ограничение на отправку, блокировка исходящей почты, ошибки в логах, проблемы с DNS-записями домена, SPF/DKIM/DMARC или репутацией отправителя.

Что проверить безопасно

Сначала сделайте тестовую отправку сами. Заполните форму как обычный пользователь, отправьте заявку, посмотрите сообщение после отправки и проверьте почту, включая папку «Спам». Это простое действие часто сразу показывает, в какой зоне проблема: форма не отправляется, отправляется с ошибкой или отправляется, но письмо не доходит.

Затем проверьте настройки самой формы. Убедитесь, что указан правильный email получателя, нет опечаток, письмо не отправляется на старый адрес, шаблон уведомления не пустой, а поле отправителя не выглядит подозрительно для почтового сервиса.

Если форма показывает успешную отправку, но письмо не приходит, следующий безопасный шаг — проверить доставку через SMTP. Не обязательно сразу менять всё на рабочем сайте. Лучше сначала понять, как сейчас отправляются письма, есть ли SMTP-плагин, какой отправитель используется, совпадает ли домен отправителя с доменом сайта, есть ли ошибки тестовой отправки.

Если форма не отправляется вообще, проверьте, не появилась ли проблема после установки капчи, антиспама, кэша, оптимизации JS или обновления плагина формы. Для WordPress-диагностики официальная документация рекомендует использовать режим отладки, но включение WP_DEBUG может показывать ошибки, предупреждения и notices, поэтому на рабочем сайте это нужно делать аккуратно и лучше с логированием, а не выводом ошибок на экран.

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

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

Чего делать не стоит

Не стоит сразу удалять форму и ставить другой плагин. Иногда проблема не в плагине, а в почтовой отправке, сервере, SMTP, DNS или антиспаме. Новый плагин будет использовать тот же сайт и может столкнуться с той же проблемой. Зато вы получите ещё одну форму, ещё один набор настроек и ещё один повод сказать «теперь вообще ничего не понятно».

Не стоит менять несколько вещей одновременно. Например, обновить плагин, поменять SMTP, включить новую капчу, очистить кэш, сменить тему и переписать шаблон письма. После этого невозможно понять, что помогло или что сломало отправку.

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

Не стоит публиковать ошибки PHP на фронтенде. Если нужно включить отладку, лучше писать ошибки в лог, а не показывать посетителям. И точно не стоит оставлять debug-режим включённым после диагностики.

Когда уже нужна техподдержка

Техподдержка нужна, когда безопасные проверки не помогли или проблема затрагивает реальные заявки. Если форма не работает на коммерческом сайте, это не косметическая ошибка. Это потерянные обращения, рекламный бюджет и доверие пользователей.

Особенно важно подключать специалиста, если нужны доступы к админке, хостингу, почтовому ящику, DNS, SMTP, логам PHP, логам сервера или файлам темы. В этот момент проблема выходит за уровень «проверить галочку в форме» и переходит в техническую диагностику.

Мягкий и правильный вариант — не ждать, пока форма «сама починится», а подключить техническую поддержку сайта. Для такой задачи обычно нужны доступы к WordPress, хостингу или почте, понимание, какая форма сломалась, когда началась проблема и что менялось перед этим.

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